Introduction

1. Introduction By Dr. Shadi Masadeh 1

2. Overview of Network Analysis, Architecture, and Design Network analysis entails learning what users, their applications, and devices need from the network (Figure 1.2). It is also about understanding network behavior under various situations. Network analysis also defines, determines, and describes relationships among users, applications, devices, and networks. In the process, network analysis provides the foundation for all the architecture and design decisions to follow. The purpose of network analysis is twofold: first, to listen to users and understand their needs; and second, to understand the system.

3. Overview of Network Analysis, Architecture, and Design

4. Model for Network Analysis, Architecture, and Design • Network analysis, architecture, and design are similar to other engineeringprocesses in that they address the following areas: • Defining the problems to be addressed• Establishing and managing customer expectations• Monitoring the existing network, system, and its environment• Analyzing data• Developing a set of options to solve problems• Evaluating and optimizing options based on various trade-offs• Selecting one or more options• Planning the implementation

5. A Systems Methodology • Systems methodology : means viewing the network that you are architecting and designing, along with a subset of its environment (everything that the network interacts with or impacts), as a system • Users • Applications • Devices. • Associated with this system are sets of services (levels of performance and function) • When a network is viewed as part of a system that provides services, the systems • methodology works quite well for a variety of networks, from small and simple • to large, complex networks. • It helps in determining, defining, and describing the important characteristics and capabilities of your network.

6. System Description • A system is a set of components that work together to support or provide connectivity, • communications, and services to users of the system. • Users: network and computer support personnel, as well as developers and customers of that corporation’s product • Applications: may be specific to a particular user, customer or group, generic to a customer base, or generic across the entire network. • Devices: can be subdivided by class to show specialized functions, such as storage, computing, or application servers, or an individual device may be subdivided to show its operating system (OS), device drivers, peripheral hardware, or application programming interface (API). • Networks.: different size, types of networks.

7. System Description

8. System Description

9. System Description

10. Service Description • The concept of network services build upon the (IETF),( Internet Engineering Task Force ) perspective for IP networks. • In general, Network services are sets of network capabilities that can be configured and managed within the network and between networks. • Network services, are defined as levels of performance and function in the network. We can look at this from two perspectives as: • Sets of services being offered by the network to the rest of the system (the devices, applications, and users) or • Sets of requirements from the network that are expected by the users, applications, or devices. • Levels of performance are described by the performance characteristics capacity, delay, and RMA (reliability, maintainability, and availability), • Levels of functions are described as security, accounting, billing, scheduling, and management (and others).

11. Service Description

12. Service Characteristics • Characteristics of services that are requested from the network can also be considered requirements for that network. • Examples of service characteristics: • Estimates of capacity requirements based on qualitative information about the network • Elaborate listings of various capacity, delay, and RMA requirements, per user, application, and/or device, • Requirements for security, manageability, usability, flexibility • And others.

13. Service Characteristics • Effective services must be described and provisioned end-to-end at all network components • “End-to-end” does not necessarily mean only from one user’s device to another user’s device. It may be defined between networks, from users to servers, or between specialized devices (Figure 1.23). • When services are not provisioned end-to-end, some components may not be capable of supporting them, and thus the services will fail

14. Service Characteristics

15. Service Characteristics • Services need to be configurable, measurable, and verifiable within the system to ensure that end users, applications, and devices are getting the services they have requested. • Services are also likely to be hierarchical within the system, with different service types and mechanisms applied at each layer in the hierarchy. • Figure 1.24 shows a (QoS) hierarchy that focuses on bulk traffic transport in the core of the network while placing specific services at the access network close to the end users, applications, and devices.

16. Service Characteristics

17. Service Levels • Service characteristics can be grouped together to form one or more service levels for the network: • To make service provisioning easier in that you can • configure, manage, account, and bill for a group of service characteristics (service level) instead of a number of individual characteristics. • For example, a service level (e.g., premium) may combine capacity (e.g., 1.5 Mb/s) and reliability (as 99.99% uptime). • Service levels are also helpful in billing and accounting. • This is a service provider view of the network, where services are offered to customers (users) for a fee.

18. Service Levels • There are many ways to describe service levels: • Levels of capacity • Classes of service (CoSs), which combine delay and capacity characteristics • IP types of service (ToSs) • Qualities of service (QoSs), which prioritize traffic for traffic conditioning functions • Combinations of the aforementioned mechanisms • Custom service levels, based on groups of individual service characteristics.

19. Service Levels • In Figure 1.25 service offerings, requests, and metrics are shown applied to the system. In this example a demarcation of services is shown between the device and network components. Depending on the service requirement or characteristic, however, demarcation may also be between the device and application components.

20. System Components and Network Services Network services are derived from requirements at each of the components in the system. There can be user requirements, application requirements, device requirements, and (existing) network requirements. User requirements, which are the most subjective and general, are refined and expanded by requirements from the application component, which are in turn refined and expanded by the device and network components. Thus, requirements filter down from user to application to device to network, resulting in a set of specific requirements that can be configured and managed in the network devices themselves. This results in a service offering that is end-to-end, consisting of service characteristics that are configured in each network device in the path (e.g., routers, switches, hubs).

21. System Components and Network Services

22. Services Requests and Requirements • Services Requests and Requirements Categorized as: • Best-effort service means that there is no control over how the network will satisfy the service • Guaranteed service is the opposite of best-effort service. Where best-effort service is unpredictable and unreliable, guaranteed service must be predictable and reliable to such a degree • These are predictable services, which require some degree of predictability (more than best effort) yet do not require the accountability of a guaranteed service.

23. Call Admission Control Services Requests and Requirements

24. Service Metrics • For service performance requirements and characteristics to be useful, they must be configurable, measurable, and verifiable within the system. • Therefore, we will describe performance requirements and characteristics in terms of service metrics, which are intended to be configurable and measurable.

25. Performance Characteristics • Capacity is a measure of the system’s ability to transfer information (voice, data, video, or combinations of these). Several terms are associated with capacity, such as bandwidth, throughput. • Delay is the time difference in transmitting a single unit of information (bit, byte, cell, frame, or packet) from source to destination. • There are also various sources of delay, such as propagation, transmission, queuing, and processing. • Delay may be measured in one direction (end-to-end) and both directions (round-trip). • Another measure of delay incorporates device and application processing, taking into account the time to complete a task. As the size of a task increases, the application processing times • Response time, termed here latency, may yield important information about the behavior of the application and the network. • Jitter Delay variation, which is the change in delay over time. • Together, delay (end-to-end and round-trip), latency, and delay variation help describe network behavior.

26. Performance Characteristics • RMA :reliability maintainability and availability. • Reliability is a statistical indicator of the frequency of failure of the network and its components and represents the unscheduled outages of service. • Maintainability is a statistical measure of the time to restore the system to fully operational status after it has experienced a fault. • Availability (also known as operational availability) is the relationship between the frequency of mission-critical failures and the time to restore service.

27. End of Chapter 1

28. Requirements Analysis By Dr. Shadi Masadeh 28

29. Requirements Analysis Chapter Objectives Learn about gathering and managing user, application, device, and network requirements. Setting and managing your customer’s expectations about the network. Determining the variables to measure (service metrics) and how to make measurements. Developing performance requirements for capacity, delay, and RMA, including developing performance thresholds and limits. Discuss predictable and guaranteed performance requirements and their importance Mapping requirements to geographic locations, in preparation for traffic flow analysis.

30. The Requirements Analysis Process

31. Requirements Analysis • Gathering and Listing Requirements • Service requirements are gathered and developed with initial conditions on the architecture and design, with input from: • Users • Administration, • Management • Then refined by applying experience and knowledge about the analysis process. • Determining Initial Conditions • Initial conditions consist of: • the type of network project, • the scope of the architecture and design, • initial architecture/design goals, • any outside forces acting on the network.

32. Requirements Analysis • Determining Initial Conditions (continued) • Type of Network Project • New network • Modification of an existing network • Analysis of network problems • Outsourcing • Consolidation • Upgrade • Scope of Network Project • Network size • Number of sites • Distance between sites

33. Requirements Analysis • Initial Architecture/Design Goals • Upgrade technology/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

34. Requirements Analysis Setting Customer Expectations Customers’ definition of the problem, and their expectations, is quite correct. Customers’ expectations need to be adjusted somewhat. And there may be times when you find that their expectations and your expectations are so far apart that it is better not to continue on that project

35. Requirements Analysis Working with users • A key trade-off is the amount of time spent versus the quality of information gathered. • Working with your users, administration, and management, not just developing a network “in the dark.” • Applications have to be designed to work across the network; and devices must be chosen with the system in mind. • Therefore, it is important not to take a hit-and-run approach

36. Developing Service Metrics Developing Service Metrics We will develop and use performance thresholds and limits to distinguish between low and high performance, and also use performance characteristics to identify predictable and guaranteed performance levels Service metrics are either actual measurable quantities in the network or are derived from measured quantities The types of service metrics depend on your design and the types of equipment (network devices) you implement in your network

37. Developing Service Metrics • Service metrics for RMA include: • Reliability, in terms of mean time between failures (MTBF) and mean time between mission-critical failures (MTBCF) • Maintainability, in terms of mean time to repair (MTTR) • Availability, in terms of MTBF, MTBCF, MTTR • Optionally, uptime and downtime (as a percent 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

38. Developing Service Metrics • Service metrics for capacity include: • Data rates, in terms of peak data rate (PDR), sustained data rate (SDR), and minimum data rate (MDR) • Data sizes, including burst sizes and durations • Service metrics for delay include: • End-to-end or round-trip delay • Latency • Delay variation

39. Developing Service Metrics • Examples of variables used as service metrics include: • Bytes in/out (per interface) • IP packets in/out (per interface) • Dropped Internet control message protocol (ICMP) messages/unit time (per interface) • Service-level agreement (SLA) metrics (per user) • Capacity limit • Burst tolerance • Delay • Downtime

40. Measurement Tools • Management protocols and MIBs • Commonly available tools to help measure service metrics: • Ping (available in TCP/IP releases), which roughly measures round-trip delays between selected sources and destinations in the network. • Pathchar (available from ee.lbl.gov), which combines round-trip delay and per-link capacity measurements with path traces, as does another popular utility traceroute. • TCPdump to analyze TCP traffic . • There are also proprietary, enterprise, and technology-specific tools:

41. Measurement Tools

42. Characterizing Behavior User Behavior • How users of the system will apply applications. • Logic here is that we can develop a rule of thumb for scaling the expected performance of the network by examining user and application behavior • Simple usage patterns can include: • User work times and durations • For each application the total number of users • The frequency that a user is expected to have an application session running (usually as number of sessions per user, per day) • How long an average application session will last (usually on the order of minutes) • An estimate of the expected number of simultaneous user sessions for thatapplication.

43. Characterizing Behavior • Estimating the frequency and duration of application sessions and the number of simultaneous sessions allows you to apply a modifier to the performance requirement for each application User Behavior

44. Characterizing Behavior Application Behavior • Consider the data sizes that the application will be processingand passing across the network • The frequency and time duration for data to be passed across the network; • Flow directions (e.g., from client to server); and any requirements for multicasting (including broadcasts). • Simple model: one session of an application active at any time. • Another model: apply statistical formulas to the usage pattern and application behavior.

45. Developing RMA Requirements Reliability: Reliability is a statistical indicator of the frequency of failure of the network and its. • Measures of reliability • Mean time between mission-critical failure (MTBCF), usually expressed in hours. • Mean time between failure (MTBF), which considers all failures, regardless of their significance at the time of failure, and is a conservative approximation, useful in simple systems.

46. Developing RMA Requirements Maintainability: Maintainability is a statistical measure of thetime to restore the system to fully operational status, once it has experienced a fault. • Measures of reliability • Mean time to repair (MTTR). • Repairing a system failure consists of several stages • Detection, isolation of the failure to a component that can be replaced, • The time required to deliver the necessary parts to the location of the failed component (logistics time), • The time to actually replace the component, test it, and restore full service. • MTTR usually assumes the logistics time is zero; this is an assumption, which is invalid if a component must be replaced to restore service but takes days to obtain.

47. Developing RMA Requirements Availability: Availability (also known as operational availability) is the relationship between the frequency of mission-critical failure and the time to restore service. • Measures of availability: A = MTBCF/MTBCF+MTTR or A = MTBF/MTBF+MTTR • Where: • A is availability. • mean time between mission-critical failures (MTBCF) • Mean time to repair (MTTR). • mean time between failure (MTBF)

48. Developing RMA Requirements • Uptime and Downtime • A common measure of availability is expressed in terms of percent of uptime or downtime. • For example, a request for proposal (RFP) from a potential customer may state a required uptime of 99.999% (commonly known as “five nines”) measured per week, month, or year, based on the total amount of time for that period. • Uptime is when the system (applications, devices, networks) is available to the user • By available, we mean the range from having basic connectivity to actually being able to run applications across the network. • Downtime can range from being unable to connect across the network, to having connectivity but with loss rates high enough (or capacity low enough) that applications do not function properly.

49. Developing RMA Requirements Uptime and Downtime Figure 3.10 below shows some commonly used availability percentages (as percent of uptime), ranging from 99% to 99.999%.