Network Architecture Analysis and Design-1 PDF

Network Analysis Architecture & Design Eng. Roain AL-Roainy “True collaboration isn’t throwing designs over the wall. It’s designers, engineers, and the rest of the team sharing the responsibility to build a quality Network. People use the Internet more and more every d...

Network Analysis Architecture & Design Eng. Roain AL-Roainy “True collaboration isn’t throwing designs over the wall. It’s designers, engineers, and the rest of the team sharing the responsibility to build a quality Network. People use the Internet more and more every day. They use the Internet for research, shopping, airline reservations, checking the latest news and weather, and so on.” 1  Eng. Roain AL-Roainy Contents: Part I Identifying Your Customer’s Needs and Goals : 1.Chapter 1 Analyzing Business Goals and Constraints 2.Chapter 2 Analyzing Technical Goals and Tradeoffs 3.Chapter 3 Characterizing the Existing Internetwork 4.Chapter 4 Characterizing Network Traffic Part II Logical Network Design : 1.Chapter 5 Designing a Network Topology 2.Chapter 6 Designing Models for Addressing and Numbering 3.Chapter 7 Selecting Switching and Routing Protocols 4.Chapter 8 Developing Network Security Strategies 5.Chapter 9 Developing Network Management Strategies 2  Eng. Roain AL-Roainy Network Analysis Architecture & Design Analyzing Business Goals and Constraints Lecture 1 3  Eng. Roain AL-Roainy Using a Structured Network Design Process Top-down network design is a discipline that grew out of the success of structured software programming and structured systems analysis. The main goal of structured systems analysis is to more accurately represent users’ needs, which unfortunately often are ignored or misrepresented. Another goal is to make the project manageable by dividing it into modules that can be more easily maintained and changed. 4  Eng. Roain AL-Roainy Using a Structured Network Design Process Structured systems analysis has the following characteristics: The system is designed in a top-down sequence. During the design project, several techniques and models can be used to characterize the existing system, determine new user requirements, and propose a structure for the future system. A focus is placed on data flow, data types, and processes that access or change the data. 5  Eng. Roain AL-Roainy Using a Structured Network Design Process Structured systems analysis has the following characteristics: A focus is placed on understanding the location and needs of user communities that access or change data and processes. A logical model is developed before the physical model. The logical model represents the basic building blocks, divided by function, and the structure of the system. The physical model represents devices and specific technologies and implementations. Specifications are derived from the requirements gathered at the beginning of the top-down sequence. 6  Eng. Roain AL-Roainy Systems Development Life Cycles Systems analysis students are familiar with the concept that typical systems are developed and continue to exist over a period of time, often called a systems development life cycle. Many systems analysis books use the acronym SDLC to refer to the system’s life cycle, which might sound strange to older networking students who know SDLC as Synchronous Data Link Control. 7  Eng. Roain AL-Roainy Systems Development Life Cycles 8  Eng. Roain AL-Roainy Systems Development Life Cycles 1.Analyze requirements: In this phase, the network analyst interviews users and technical personnel to gain an understanding of the business and technical goals for a new or enhanced system. The task of characterizing the existing network, including the logical and physical topology and network performance, follows. The last step in this phase is to analyze current and future network traffic, including traffic flow and load, protocol behavior, and quality of service (QoS) requirements. 9  Eng. Roain AL-Roainy Systems Development Life Cycles evelop the logical design: This phase deals with a logical topology for the new or enhanced network, network layer addressing, naming, and switching and routing protocols. Logical design also includes security planning, network management design, and the initial investigation into which service providers can meet WAN and remote access requirements. 10  Eng. Roain AL-Roainy Systems Development Life Cycles evelop the physical design: During the physical design phase, specific technologies and products that realize the logical design are selected. Also, the investigation into service providers, which began during the logical design phase, must be completed during this phase. 11  Eng. Roain AL-Roainy Systems Development Life Cycles 4.Test, optimize, and document the design: The final steps in top-down network design are to write and implement a test plan, build a prototype or pilot, optimize the network design, and document your work with a network design proposal. 12  Eng. Roain AL-Roainy Plan Design Implement Operate Optimize (PDIOO) Network Life Cycle Cisco documentation refers to the Plan Design Implement Operate Optimize (PDIOO) set of phases for the life cycle of a network. It doesn’t matter which life cycle you use, as long as you realize that network design should be accomplished in a structured, planned, modular fashion, and that feedback from the users of the operational network should be fed back into new network projects to enhance or redesign the network. 13  Eng. Roain AL-Roainy Plan Design Implement Operate Optimize (PDIOO) 14  Eng. Roain AL-Roainy Plan Design Implement Operate Optimize (PDIOO) The PDIOO life cycle includes the following steps: Plan: Network requirements are identified in this phase. This phase also includes an analysis of areas where the network will be installed and an identification of users who will require network services. 15  Eng. Roain AL-Roainy Plan Design Implement Operate Optimize (PDIOO) The PDIOO life cycle includes the following steps: Design: In this phase, the network designers accomplish the bulk of the logical and physical design, according to requirements gathered during the plan phase. 16  Eng. Roain AL-Roainy Plan Design Implement Operate Optimize (PDIOO) The PDIOO life cycle includes the following steps: Implement: After the design has been approved, implementation begins. The network is built according to the design specifications. Implementation also serves to verify the design. 17  Eng. Roain AL-Roainy Plan Design Implement Operate Optimize (PDIOO) The PDIOO life cycle includes the following steps: Operate: Operation is the final test of the effectiveness of the design. The network is monitored during this phase for performance problems and any faults to provide input into the optimize phase of the network life cycle. 18  Eng. Roain AL-Roainy Plan Design Implement Operate Optimize (PDIOO) The PDIOO life cycle includes the following steps: Optimize: The optimize phase is based on proactive network management that identifies and resolves problems before network disruptions arise. The optimize phase may lead to a network redesign if too many problems arise because of design errors or as network performance degrades over time as actual use and capabilities diverge. 19  Eng. Roain AL-Roainy Plan Design Implement Operate Optimize (PDIOO) The PDIOO life cycle includes the following steps: “Redesign can also be required when requirements change significantly.” 20  Eng. Roain AL-Roainy Network Analysis Architecture & Design Analyzing Business Goals and Constraints Lecture 2 21  Eng. Roain AL-Roainy Model for Network Analysis, Architecture, and Design Network analysis, architecture, and design are similar to other engineering processes in that they address the following areas: 1.Defining the problems to be addressed. 2.Establishing and managing customer expectations. 3.Monitoring the existing network, system, and its environment. 22  Eng. Roain AL-Roainy Model for Network Analysis, Architecture, and Design 4. Analyzing data. 5. Developing a set of options to solve problems. 6. Evaluating and optimizing options based on various trade-offs. 7. Selecting one or more options 8. Planning the implementation 23  Eng. Roain AL-Roainy Model for Network Analysis, Architecture, and Design Example : Once, in performing an analysis on a customer’s metropolitan-area network (MAN), I realized that the problem was not what the customers thought. They thought that the technology chosen at that time, switched multimegabit data service (SMDS), and the routing protocol (OSPF) were not working properly together. However, the problem actually was that the network personnel had forgotten to connect any of their LANs to the MAN. Of course, when they ran tests from one LAN to another, no data were being passed. It was an easy problem to fix, but a lot of work was spent changing the customer’s view on the problem and expectations of what needed to be done. The customer originally wanted to change vendors for the routing equipment and replace the SMDS service. Eventually, they were convinced that the equipment and service were fine and that the problem was internal to the organization. Although SMDS is not widely available anymore, its behavior as a non-broadcast multiple-access (NBMA) technology is similar to other currently available technologies. 24  Eng. Roain AL-Roainy Systems Development Life Cycles 1.Analyze: Study the current system. What system can do? Identify the improvement. 25  Eng. Roain AL-Roainy Systems Development Life Cycles 1.Analyze: Define requirement: 1. Requirements determination: Functional : process, information. Nonfunctional : performance, security, policies. 26  Eng. Roain AL-Roainy Systems Development Life Cycles 1.Analyze: Define requirement: 2. Requirements Definition : Business req. User req. Software req. Software characteristics. System req. 27  Eng. Roain AL-Roainy Systems Development Life Cycles 1.Analyze: Define requirement: 3. Information Gathering: Interview. Questioners. Observations. Document Analysis. Flow charts, forms, Policies, roles, catalogs, reports. 28  Eng. Roain AL-Roainy Systems Development Life Cycles 1.Analyze: Define requirement: 4. Problems analysis: Root cause analysis. Duration analysis. Costing analysis. Technology analysis. 29  Eng. Roain AL-Roainy Systems Development Life Cycles ogical design: Performance. Topology or Architectural : 1. LAN, WAN, CAN. 2. Core, distributed, Access. Addressing & Routing. Security. Management. 30  Eng. Roain AL-Roainy Systems Development Life Cycles  design: Physically determine the devices and the most appropriate type based on the requirements analysis and cost determination. 31  Eng. Roain AL-Roainy Systems Development Life Cycles 4.Test, optimize: Implement plans in reality or in simulation programs. Monitor performance. Define a backup and disaster recovery plan. 32  Eng. Roain AL-Roainy Factors Effect Network Design:- In network design, several factors come into play, especially when considering capacity, delay, reliability, maintainability, and availability. 1.Capacity: This refers to the ability of the network to handle traffic. It includes the following components: Bandwidth: The maximum rate of data transfer across the network, typically measured in bits per second (bps). It sets an upper limit on the capacity of the network. Throughput: The actual amount of data successfully transferred over the network. It is usually less than bandwidth due to overhead, interference, and other factors. Data Rate: The speed at which data is transmitted, often expressed as a ratio of bits per second. Higher data rates are desirable but depend on the network's hardware and protocols. 33  Eng. Roain AL-Roainy Factors Effect Network Design:- 2. Delay: Delay refers to the time it takes for data to travel from source to destination. It is influenced by: Congestion Control: Mechanisms that prevent excessive data from overwhelming network resources, reducing delay due to congestion. Flow Control: Ensures that the sender does not overwhelm the receiver with too much data, helping to manage delay by balancing load. Latency Control: Techniques to minimize the time delay (latency) in the network. Latency is influenced by distance, propagation speed, and the number of intermediate devices. 34  Eng. Roain AL-Roainy Factors Effect Network Design:- 3. Reliability: Refers to the network’s ability to deliver data accurately and consistently. It includes error detection and correction, ensuring that data reaches its destination without corruption or loss. 4. Maintainability: The ease with which the network can be maintained, repaired, or upgraded. Good network design allows for scalability, troubleshooting, and the quick replacement of faulty components to minimize downtime. 35  Eng. Roain AL-Roainy Factors Effect Network Design:- 5.Availability: Refers to the network’s readiness to serve users at all times. High availability ensures that the network is operational and accessible when needed, often achieved through redundancy, failover mechanisms, and robust network design. Each of these factors plays a critical role in optimizing network Design performance, ensuring smooth communication, and meeting service- level agreements (SLAs). Balancing these components is key to achieving an efficient and reliable network. 36  Eng. Roain AL-Roainy Characteristics of a network architecture and design Key characteristics of a network architecture and design that affect the post implementation costs include: Network and system reliability. Network and system maintainability. Training of the operators to stay within operational constraints. Quality of the staff required to perform maintenance actions. 37  Eng. Roain AL-Roainy Characteristics of a network architecture and design Some examples of key network architecture/design decisions that affect these characteristics include: Degree of diversity of critical-path components in network architecture/design. Quality of network components selected for installation. Location and accessibility of components requiring frequent maintenance. Implementation of built-in test equipment and monitoring techniques. 38  Eng. Roain AL-Roainy Network Analysis Architecture & Design Characterizing the Existing Internetwork Lecture 3 39  Eng. Roain AL-Roainy Requirements Analysis: Concepts Requirements: Requirements are descriptions of the network functions and performance needed in order for the network to successfully support its users, applications, and devices (and thus the success of the network project). 40  Eng. Roain AL-Roainy Requirements Analysis: Concepts User Requirements: In the model of system components in our generic system, the user component is at the highest layer. The term user represents primarily the end users of the system but can be expanded to include everyone involved in the system, such as network and system administrators and management. User requirements comprise the set of requirements that is gathered or derived from user input and represent what is needed by users to successfully accomplish their tasks on the system. Typically, when gathering requirements, everyone involved with that network is considered a potential user. 41  Eng. Roain AL-Roainy Requirements Analysis: Concepts User Requirements: 42  Eng. Roain AL-Roainy Requirements Analysis: Concepts User Requirements: 43  Eng. Roain AL-Roainy Requirements Analysis: Concepts Application requirements : The application component interfaces with the user and device components and is a key part of the requirements analysis. Application requirements are requirements that are determined from application information, experience, or testing, and represent what is needed by applications to successfully operate on the system. 44  Eng. Roain AL-Roainy Requirements Analysis: Concepts Application requirements : 45  Eng. Roain AL-Roainy Requirements Analysis: Concepts Devices requirements : We now turn to the requirements of devices that the network will support, particularly the types of devices, their performance characteristics, and their location information. As you will see, this information builds on the user and application requirements discussed earlier to begin to provide a comprehensive picture of system needs. 46  Eng. Roain AL-Roainy Requirements Analysis: Concepts Devices requirements : 47  Eng. Roain AL-Roainy Requirements Analysis: Concepts Network requirements : Most network architectures/designs today need to incorporate existing networks. Few networks today are built entirely from scratch. This includes system upgrades, such as adding a new application to the system, migrating to a new or different technology or protocol, or upgrading the network infrastructure, and the expansion or reduction of a system’s size or scope. 48  Eng. Roain AL-Roainy Requirements Analysis: Concepts Network Requirements: 49  Eng. Roain AL-Roainy Requirements Analysis: Concepts Network requirements : Scaling dependencies. The existing network can impact how the planned network will scale. For example, how will the addition of the new network to the existing network change the size and scope of the system? Will the change be dramatic, as in growing from a LAN to a WAN, or will the change be within the LAN/MAN/WAN boundaries of the existing network? Location dependencies. Depending on how the new networks interface with or incorporate the existing network, or how the network modifications are done, the locations and/or concentrations of other components of the system are likely to change. This will show up when we develop flows later in the analysis process. 50  Eng. Roain AL-Roainy Requirements Analysis: Concepts Network requirements : Performance constraints. The overall performance of the system will be affected by our architecture and design for the expected network (or network modification), how it interacts with the existing network, and its performance levels. Since the performance of the existing network will impact overall system performance, its performance characteristics should be integrated into the performance requirements of the planned network. Since the existing network is already in place, it is usually possible to measure the performance of this network. Thus, while the performance of the expected network is based on a best estimate, the performance of the existing network (and potential performance impacts) can be better understood. 51  Eng. Roain AL-Roainy Requirements Analysis: Concepts Network requirements : Network, system, and support service dependencies. These include network addressing strategies, security, choices and configurations of routing protocols, and naming strategies, while support services include systemwide security, accounting, and monitoring and management. Current and planned requirements for each of these should be considered. 52  Eng. Roain AL-Roainy Requirements Analysis: Concepts Network requirements : Network obsolescence. Even though there may be parts of the existing network that will be integrated into the planned network, these parts, including network devices, protocols, and software, may become obsolete during the life cycle of your new network. Whenever possible, you should note that parts of the network that will be integrated into the planned network, yet are near the end of their usefulness, will need to be transitioned out of the planned network. In addition, requirements for the users, applications, and devices of the existing network must be considered as part of the system being built, and their requirements analysis done along with the analysis for new parts of the system. 53  Eng. Roain AL-Roainy Requirements Analysis: Concepts Other Requirements : Supplemental Performance Requirements. Financial Requirements. Enterprise Requirements 54  Eng. Roain AL-Roainy Requirements Analysis: Concepts Example : Requirements Analysis for a Company LAN. A first attempt was made to gather requirements for building a LAN network. The results were as follows: 1. 150 users (60 engineers, 15HR and Finance, 30 Manufacturing, 10 Management, 30 Sales/Marketing, 5 Other). 2. Each area in the building must support Fast Ethernet connections to the backbone. 3. Database, Visualization, Manufacturing, and Payroll applications are considered mission- critical for this company. 4. Inventory application (INV1) for manufacturing requirements not determined at this time. 5. Database application (DB1) requires a minimum of 150 Kb/s, per session. 6. Engineering users have workstations with GigE NICs. 7. Visualization application (VIS1) for finance requires up to 40 Mb/s capacity and 100 ms round-trip delay. 8. Payroll application (PAY1) requires 100% uptime (while in operation) between finance and outside payroll company. 9. Company must be kept secure from Internet attacks. 10. Company requires a minimum of T1 access to Internet. 11. Current network will be completely replaced, so there are no requirements from existing network. 12. Other general applications: mail, word processing, internal and external Web access. 55  Eng. Roain AL-Roainy Requirements Analysis: Concepts Example : Requirements Analysis for a Company LAN. 56  Eng. Roain AL-Roainy Requirements Analysis: Concepts Example : Requirements Analysis for a Company LAN. 57  Eng. Roain AL-Roainy Network Analysis Architecture & Design Characterizing Network Traffic Lecture 4 58  Eng. Roain AL-Roainy Flow Analysis Flow: Flows (also known as traffic flows or data flows) are sets of network traffic (application, protocol, and control information) that have common attributes, such as source/destination address, type of information, directionality, or other end-to- end information. Information within a flow is transmitted during a single session of an application. Flows are end-to-end, between source and destination applications / devices / users. Since they can be identified by their end-to-end information, they can be directly linked to an application, device, or network, or associated with an end user. We can also examine flows on a link-by-link or network-by-network basis. This is useful when we want to combine flow requirements at the network or network-element levels. 59  Eng. Roain AL-Roainy Common Flow Characteristics 60  Eng. Roain AL-Roainy Common Flow Characteristics 61  Eng. Roain AL-Roainy types of flows individual flow : An individual flow is the flow for a single session of an application. An individual flow is the basic unit of traffic flows in this book; they are either considered individually or combined into a composite flow. When an individual flow has guaranteed requirements, those requirements are usually left with the individual flow and are not consolidated with other requirements or flows into a composite flow. This is done so that the flow’s guaranteed requirements can be treated separately from the rest of the flows. Individual flows are derived directly from the requirements specification, or are estimated from our best knowledge about the application, users, devices, and their locations. 62  Eng. Roain AL-Roainy types of flows composite flow : A composite flow is a combination of requirements from multiple applications, or of individual flows, that share a common link, path, or network. Most flows in a network are composites 63  Eng. Roain AL-Roainy Identifying and Developing Flows The process for identifying and developing flows consists of identifying one or more applications and/or devices that you believe will generate and/or terminate traffic flows. Once you have chosen which applications and devices to focus on, you use their requirements from the requirements specification and their locations from the requirements map. Based on how and where each application and device is used, you may be able to determine which devices generate flows and which devices terminate flows (flow sources and sinks). Some common flow models are provided in Section 4.6 to help you with this process. Once you have identified each flow and determined its composition and location, you combine the performance requirements of flows into a flow specification. 64  Eng. Roain AL-Roainy Identifying and Developing Flows 65  Eng. Roain AL-Roainy Identifying and Developing Flows From an application perspective, some common approaches to identifying flows include: Focusing on a particular application, application group, device, or function (e.g., videoconferencing or storage). Developing a “profile” of common or selected applications that can be applied across a user population. Choosing the top N (e.g., 3, 5, 10, etc.) applications to be applied across the entire network.. 66  Eng. Roain AL-Roainy Identifying and Developing Flows From an application perspective, some common approaches to identifying flows include: Focusing on a particular application, application group, device, or function (e.g., videoconferencing or storage). Developing a “profile” of common or selected applications that can be applied across a user population. Choosing the top N (e.g., 3, 5, 10, etc.) applications to be applied across the entire network.. 67  Eng. Roain AL-Roainy Data Sources and Sinks Data sources and sinks can help provide directionality to flows. 68  Eng. Roain AL-Roainy Data Sources and Sinks Data source: generates a traffic flow. Some examples of data sources are devices that do a lot of computing or processing and generate large amounts of information, such as computing servers, mainframes, parallel systems, or computing clusters. Other (specialized) devices, like cameras, video production equipment, application servers, and medical instruments, do not necessarily do a lot of computing (in the traditional sense) but can still generate a lot of data, video, and audio that will be transmitted on the network 69  Eng. Roain AL-Roainy Data Sources and Sinks Data source: generates a traffic flow. 70  Eng. Roain AL-Roainy Data Sources and Sinks Data sink: terminates a traffic flow. A good example of a data sink is a data storage or archival device. This may be a single device, acting as a front end for groups of disks or tape devices. Devices that manipulate or display large quantities of information, such as video editing or display devices, also act as data sinks 71  Eng. Roain AL-Roainy Data Sources and Sinks Data sink: terminates a traffic flow. 72  Eng. Roain AL-Roainy Flow Models Flow models can also be useful to help quickly identify and categorize flows in an environment, so that we may easily recognize its flow characteristics. In this way they are like application groups, Flow models that we examine are: Peer-to-peer Client–server Hierarchical client–server Distributed computing 73  Eng. Roain AL-Roainy Flow Models Peer-to-Peer: is one where the users and applications are fairly consistent in their flow behaviors throughout the network. They are, in effect, peers, in that they act at the same level in the hierarchy. Since they (users and/or applications) are fairly consistent, their flows are also fairly consistent. Thus, we can consider the flows in a peer-to-peer flow model to be equivalent. This has two important implications: We cannot distinguish between flows in this model. Therefore, either all of the flows or none of the flows is critical. Since the flows are equivalent, they can be described by a single specification (e.g., profile).74  Eng. Roain AL-Roainy Flow Models Peer-to-Peer: 75  Eng. Roain AL-Roainy Flow Models client–server : The client–server flow model is currently the most generally applicable model. This model has both directionality and hierarchy. Flows in this model are bidirectional, between clients and the server, in the form of requests and responses. This flow model is client–server in that the flows are asymmetric and hierarchically focused toward the client. Thus, requests tend to be small relative to responses. Depending on the type of application, the flows may be considered almost unidirectional, from the server to the clients. 76  Eng. Roain AL-Roainy Flow Models Client–Server : 77  Eng. Roain AL-Roainy Flow Models Hierarchical Client–Server : 78  Eng. Roain AL-Roainy Flow Models Distributed-Computing: The distributed- computing flow model, is the most specialized of the flow models. A distributed-computing flow model can have the inverse of the characteristics of the client–server flow model, or a hybrid of peer- to-peer and client–server flow models. In this model, flows may be primarily between a task manager and its computing devices (like a client– server model) or between the computing devices (like a peer-to-peer model). The type of model depends on how the distributed computing is done. The important characteristics of this model are that the flows can be client–server but are reversed in direction, and that the computing devices may have strict performance requirements. 79  Eng. Roain AL-Roainy Flow Models Distributed-Computing: 80  Eng. Roain AL-Roainy Flowspec Algorithm Flowspecs are used to combine performance requirements of multiple applications for a composite flow or multiple flows in a section of a path. The flowspec algorithm is a mechanism to combine these performance requirements (capacity, delay) for flows in such a way as to describe the optimal composite performance for that flow or group of flows. The flowspec algorithm applies the following rules: 1. Best-effort flows consist only of capacity requirements; therefore, only capacities are used in best-effort calculations. 2. For flows with predictable requirements we use all available performance requirements (capacity, delay) in the calculations. Performance requirements are combined for each characteristic so as to maximize the overall performance of each flow. 3. For flows with guaranteed requirements we list each individual requirement (as an individual flow), not combining them with other requirements. 81  Eng. Roain AL-Roainy Network Analysis Architecture & Design Designing a Network Topology Lecture 5 82  Eng. Roain AL-Roainy Architectural Models In developing the architecture for your network there are several architectural models that you can use as a starting point, either as the foundation of your architecture or to build upon what you already have. Three types of architectural models are presented here: topological models, which are based on a geographical or topological arrangement and are often used as starting points in the development of the network architecture; flow-based models, which take particular advantage of traffic flows from the flow specification; and functional models, which focus on one or more functions or features planned for in the network. 83  Eng. Roain AL-Roainy Architectural Models Topological Models: There are two popular topological models: the LAN/MAN/WAN and Access/Distribution/Core models. The LAN/MAN/WAN architectural model is simple and intuitive and is based on the geographical and/or topological separation of networks. Its important feature is that, by concentrating on LAN/MAN/WAN boundaries, it focuses on the features and requirements of those boundaries, and on compartmentalizing functions, service, performance, and features of the network along those boundaries. 84  Eng. Roain AL-Roainy Architectural Models Topological Models: Both the LAN/MAN/WAN model and the Access/Distribution/Core model indicate as well the degree of hierarchy intended for the network. Either model can be collapsed to show fewer than three levels or expanded to show as many levels as necessary. For example, the LAN/MAN/WAN model is often used as a LAN/WAN model, or the LAN component is separated into campus, buildings, or even floors. 85  Eng. Roain AL-Roainy Architectural Models Topological Models: The Access/Distribution/Core architectural model has some similarities to and differences from the LAN/MAN/WAN model. It is similar to the LAN/MAN/WAN model in that it compartmentalizes some functions, service, performance, and features of the network, although not to the degree of the LAN/MAN/WAN model. The Access/Distribution/Core model, however, focuses on function instead of location. A characteristic of this model that is important to note is that it can be used to reflect the behavior of the network at its access ,distribution ,and core areas. 86  Eng. Roain AL-Roainy Architectural Models Topological Models: The access area is closest to the users and their applications and is where most traffic flows are sourced and sinked. Thus, flows and requirements can be treated on an individual basis more easily than in the distribution and core areas. The distribution area can also source and sink flows, but they are more likely to be to or from multiple-user devices, such as servers or specialized devices. Few users are normally directly connected to the distribution area. As such, this area is often used to consolidate flows. As we will see, performance mechanisms that support individual and combined flows can both be used here. The core of the network is used for bulk transport of traffic, and flows are not usually sourced or sinked at the core. Thus, any view of individual flows is lost at the core, unless specifically planned for (as with flows that have guaranteed requirements). 87  Eng. Roain AL-Roainy Architectural Models Topological Models: Both the LAN/MAN/WAN and Access/Distribution/Core models are used as starting points in the network architecture, as both are intuitive and easy to apply. They can be restrictive, however, in that they place strict boundaries between areas. When applying these models, therefore, keep in mind that you may have to be creative in how you define each area, so that it fits the requirements for that area. 88  Eng. Roain AL-Roainy Architectural Models Flow-Based Models: Flow-based architectural models are based on their counterparts, the flow models discussed in Chapter 4. If you used these models during the flow analysis, it may be easy to apply them here. While each model has the features of its flow counterpart, it also has architectural features that were not discussed in the flow models. The flow-based models we present are peer-to- peer, client–server, hierarchical client–server, and distributed computing. 89  Eng. Roain AL-Roainy Architectural Models Flow-Based Models: The peer-to-peer architectural model is based on the peer-to-peer flow model, where the users and applications are fairly consistent in their flow behaviors throughout the network. The important characteristics of this model are in the architectural features, flows, function, features, and services. Since the users and applications in this model are consistent throughout the network, there are no obvious locations for architectural features. This pushes the functions, features, and services toward the edge of the network, close to users and their devices, and also makes flows end-to-end, between users and their devices. This resembles the Core portion of the Access/Distribution/Core model. 90  Eng. Roain AL-Roainy Architectural Models Flow-Based Models: The client–server architectural model also follows its flow model, but in this case there are obvious locations for architectural features—in particular, where flows combine. Therefore, functions, features, and services are focused at server locations, the interfaces to client LANs, and client–server flows, The characteristics of the client–server model also apply to the hierarchical client–server architectural model. In addition to the functions, features, and services being focused at server locations and client–server flows, they are also focused at the server–server flows. 91  Eng. Roain AL-Roainy Architectural Models Flow-Based Models: In the distributed-computing architectural model the data sources and sinks are obvious locations for architectural features. Flow-based models, like the topological models, are intuitive and can be easy to apply. Since they are associated with flows, they should map well to any flow maps you created as part of the requirements analysis process. These models are fairly general, and you may have to modify them to fit the specific requirements of your network. 92  Eng. Roain AL-Roainy Architectural Models Functional Models: Functional architectural models focus on supporting particular functions in the network. In this section we present service-provider, intranet/extranet, single-/multi-tiered performance, and end- to-end models. 93  Eng. Roain AL-Roainy Architectural Models Functional Models: The service-provider architectural model is based on service-provider functions, focusing on privacy and security, service delivery to customers (users), and billing. In this model, interactions between providers (the networks) and with users are compartmentalized. While this model represents a service-provider architecture, many enterprise networks are evolving to this model, applying it across organizations, departments, and buildings. 94  Eng. Roain AL-Roainy Architectural Models Functional Models: The intranet/extranet architectural model focuses on security and privacy, including the separation of users, devices, and applications based on secure access. Note that in this model there can be several levels of hierarchy (security/privacy). 95  Eng. Roain AL-Roainy Architectural Models Functional Models: The single-/multi-tiered performance architectural model focuses on identifying networks or parts of a network as having a single tier of performance, multiple tiers of performance, or having components of both. This model is based on results from the requirements and flow analyses, where single- and multi-tiered performance is determined. Recall that for multi-tiered performance, multiple applications, devices, and users can drive the network architecture and design, in terms of performance, while single-tier performance focuses on supporting (usually a majority of) applications, devices, and users that have a consistent set of performance requirements. These have two very different sets of architectural requirements. 96  Eng. Roain AL-Roainy Architectural Models Functional Models: the end-to-end architectural model focuses on all components in the end-to-end path of a traffic flow. This model is most closely aligned to the flow-based perspective of networking. 97  Eng. Roain AL-Roainy Architectural Models Functional Models: Functional models are the most difficult to apply to a network, in that you must understand where each function will be located. For example, to apply the end-to-end model you first have to define where end-to-end is for each set of users, applications, or devices that will be a part of end-to-end. An advantage of using such models is that they are likely to be the most closely related to the requirements you developed during the requirements analysis process. 98  Eng. Roain AL-Roainy Network Analysis Architecture & Design Performance Architecture Lecture 6 99  Eng. Roain AL-Roainy Performance Architecture The performance architecture describes how user, application, device, and (existing) network requirements for performance (capacity, delay, and RMA [reliability, maintainability, and availability]) will be met within the planned network. Developing requirements for performance is a key part of the analysis process, and this component architecture is where they are supported. The performance architecture is the newest of the component architectures, and it is rapidly evolving to include many new mechanisms to achieve network performance. 100  Eng. Roain AL-Roainy Performance Architecture Performance: is the set of levels for capacity, delay, and RMA in a network. It is usually desirable to optimize these levels, either for all (user, application, and device) traffic flows in the network, or for one or more sets of traffic flows, basedm on groups of users, applications, and/or devices. 101  Eng. Roain AL-Roainy Performance Architecture An important part of developing this architecture is determining the performance goals for your network: Improve the overall performance of the network (e.g., to improve response times and throughput to all users, regardless of where they are and what they are doing) Support a particular group or groups of users or applications, maybe new or planned applications Control resource allocation for accounting, billing, and/or management purposes 102  Eng. Roain AL-Roainy Developing Goals for Performance We need to ensure that the performance mechanisms we incorporate into the architecture are necessary and sufficient to achieve the performance goals for that network. Therefore, toward developing this architecture, we should answer the following questions: 1. Are performance mechanisms necessary for this network? 2.What are we trying to solve, add, or differentiate by adding performance mechanisms to this network? 3.Are performance mechanisms sufficient for this network? 103  Eng. Roain AL-Roainy Developing Goals for Performance There should be information in the requirements and flow analyses that can help in determining the need for performance mechanisms in a network. Some requirements include: Clearly different sets of network performance requirements, per user, group, application, device, and/or flow Requirements to bill and account for network service 104  Eng. Roain AL-Roainy Developing Goals for Performance Some common problems that are addressed by the performance architecture include: Improving the overall performance of a network Improving the performance to select users, applications, and/or devices Changing the network from a cost center to profitability Merging multiple traffic types over a common network infrastructure Differentiating (and possibly charging) customers for multiple levels of service 105  Eng. Roain AL-Roainy Performance Mechanisms 1.Quality of Service, or QoS, is determining, setting, and acting upon priority levels for traffic flows. QoS is usually associated with IP but is used here to define a class of mechanisms that provision and apply priority levels in multiple layers in the network. This class includes IP QoS (including MPLS), type of service (ToS), and Frame Relay committed information rate (CIR). In this section we focus on IP QoS. 106  Eng. Roain AL-Roainy Performance Mechanisms For IP-based traffic, there are two standard types of QoS: differentiated services (DiffServ, or DS) and integrated services (IntServ, or IS), intended to support two views of network service. DiffServ approaches QoS from the perspective of aggregating traffic flows on a per-hop basis based on traffic behavior. IntServ approaches QoS from the perspective of supporting traffic flows on an individual, end-to-end basis. 107  Eng. Roain AL-Roainy Performance Mechanisms 108  Eng. Roain AL-Roainy Performance Mechanisms 2.Prioritization is the process of determining which user, application, device, flow, or connection gets service ahead of others, or gets a higher level of service. Prioritization is necessary as there will be competition between traffic flows for network resources. With a limited amount of resources available in any network, prioritization determines who gets resources first, and how much they get. 109  Eng. Roain AL-Roainy Performance Mechanisms 3. Traffic Management: Priority levels determine the relative importance and urgency of traffic flows and how each traffic flow will be handled within the network. Traffic management consists of admission control and traffic conditioning. Admission control is the ability to refuse access to network resources. Traffic conditioning is a set of mechanisms that modify (increase or decrease) performance to traffic flows, as a precursor to scheduling. 110  Eng. Roain AL-Roainy Performance Mechanisms 4. Scheduling: Once traffic has been prioritized and conditioned, it is forwarded to one or more output queues for transmission onto the network. Scheduling is the mechanism that determines the order in which traffic is processed for transmission. Scheduling uses priority levels to determine which traffic flows get processed first and most often. Scheduling is applied at network devices throughout a network. In most network devices, such as switches and routers, scheduling is provided through network management, or as part of the QoS implementation in that device. 111  Eng. Roain AL-Roainy Performance Mechanisms 5. Queuing is storing IP packets within a network device while they wait for processing. There may be several locations where packets are stored (queues) within a network device, for each type of processing that the device is performing on each packet (e.g., holding packets received from the network, processing for QoS, holding packets for transmission onto the network). 112  Eng. Roain AL-Roainy Performance Mechanisms 6. Service-level agreements, or SLAs, are (typically) formal contracts between a provider and user that define the terms of the provider’s responsibility to the user and the type and extent of accountability if those responsibilities are not met. While SLAs have traditionally been contracts between various service providers (e.g., ISPs) and their customers, this concept can also be applied to the enterprise environment. In fact, the notion of customer and provider is becoming more common in enterprise networks, as they evolve from treating networks as mere infrastructure (cost-center approach) to treating them as centers for providing services to their customers 113 (users).  Eng. Roain AL-Roainy Performance Mechanisms 114  Eng. Roain AL-Roainy Performance Mechanisms There are two common ways to apply SLAs within a network. First, an SLA can be an agreement between network management/administration and its customers (the network users). Second, an SLA can be used to define the levels of services required from third-party service providers (e.g., cable plant providers, xSPs) for the network. 115  Eng. Roain AL-Roainy Performance Mechanisms 116  Eng. Roain AL-Roainy Performance Mechanisms 7.Policies are formal or informal sets of high- level statements and rules about how network resources (and, therefore, performance) are to be allocated among users. They are used to create and manage one or more performance objectives. Policies complete the framework of performance for a network by coupling the high-level (e.g., management) view of how the network should perform, with mechanisms to implement performance at the network devices (QoS) and feedback loops with users (SLAs) 117  Eng. Roain AL-Roainy Performance Mechanisms 118  Eng. Roain AL-Roainy Network Analysis Architecture & Design MidExam Lecture 7 119  Eng. Roain AL-Roainy Network Analysis Architecture & Design Developing Network Security Strategies Lecture 8 120  Eng. Roain AL-Roainy Developing Network Security 9.3Developing a Security and Privacy Plan 9.4 Security and Privacy Administration 9.4.1 Threat Analysis 9.4.2 Policies and Procedures 9.5 Security and Privacy Mechanisms 9.5.1 Physical Security and Awareness 9.5.2 Protocol and Application Security 9.5.3 Encryption/Decryption 9.5.4 Network Perimeter Security 9.5.5 Remote Access Security 9.6 Architectural Considerations 9.6.1 Evaluation of Security Mechanisms 9.6.2 Internal Relationships 9.6.3 External Relationships 121