Infobalt’03 Seminaras Sisteminis tinklų planavimo metodas bei reikalavimų analizės rolė (nuo meno link inžinerijos) Prof.DrTech. Algirdas Pakštas London Metropolitan University Department of Computing, Communications Technology and Mathematics a.pakstas@londonmet.ac.uk, a.pakstas@ieee.org Infobalt 2003, Vilnius, 2003m. spalio 23d. ©2003 Algirdas Pakštas Sisteminis tinklų planavimo metodas bei reikalavimų analizės rolė (nuo meno link inžinerijos) 1 Abstract: Tutorial looks at the problem of network planning when network is considered not as collection of separate components but as a system. Tutorial consists of two parts. The first part of the Tutorial is devoted to the general overview of the network analysis and design processes. Network services and services-based networking are discussed. Systems and network services are presented with more details. Especial attention is devoted to characterizing of services including discussion on service requests, service offerings, service performance requirements, service metrics, as well as reservations and deadline scheduling. The second part of the Tutorial is focusing on the concepts of requirement analysis. Description of the background for requirement analysis is followed by the discussions on User Requirements, Application Requirements (types of applications, reliability, capacity, delay, application groups), Host Requirements (types of host and equipment, performance characteristics, location information), and Network Requirements (existing networks and migration, functional requirements, financial requirements, enterprise requirements). ©2003 Algirdas Pakštas Sisteminis tinklų planavimo metodas bei reikalavimų analizės rolė (nuo meno link inžinerijos) 2 Biography: Prof. Algirdas Pakstas received his M.Sc. in Radiophysics and Electronics in 1980 from the Irkutsk State University, Ph.D. in Systems Programming in 1987 from the Institute of Control Sciences. Currently he is with the London Metropolitan University, Department of Computing, Communications Technology and Mathematics where he is doing research in the area of Communications Software Engineering and is teaching courses "Network Planning and Management" and "Computer Systems and Networks". He is active in the IEEE Communications Society Technical Committees on Enterprise Networking, Communications Software and Multimedia Communications. He has published 3 research monographs (2 authored and 1 edited) and more than 140 other publications. He is a Senior Member of the IEEE and a Member of the ACM and the New York Academy of Sciences. He is currently a member of the Editorial Boards of the following journals and magazines: IEEE Communications Magazine, Cybernetics and Systems Analysis, Journal of Information and Organizational Sciences. ©2003 Algirdas Pakštas Sisteminis tinklų planavimo metodas bei reikalavimų analizės rolė (nuo meno link inžinerijos) 3 PART 1: OUTLINE A Systems Approach to Network Design Introduction - Traditional Network Design The Analysis and Design Processes Network Services and Services-Based Networking Systems and Network Services Systems Network Services Characterizing Services Service Requests Service Offerings Service Performance Requirements Service Metrics Reservations and Deadline Scheduling ©2003 Algirdas Pakštas Sisteminis tinklų planavimo metodas bei reikalavimų analizės rolė (nuo meno link inžinerijos) 4 Introduction - Traditional Network Design • A kind of art – Evaluating and choosing network technologies – Knowing how technologies, services and protocols work – Experience in what works and what does not ©2003 Algirdas Pakštas Sisteminis tinklų planavimo metodas bei reikalavimų analizės rolė (nuo meno link inžinerijos) 5 Introduction - Traditional Network Design • As in other types of art – Success greatly depends on the person(s) who is/are doing it – Designs are rarely reproducible • Traditional network design is based on developing a set of pragmatic rules e.g. • “80/20 rule” • “bridge when you can, route when you must” • “throw bandwidth at the problem” ©2003 Algirdas Pakštas Sisteminis tinklų planavimo metodas bei reikalavimų analizės rolė (nuo meno link inžinerijos) 6 Introduction - Traditional Network Design • It was focusing primarily on capacity planning • Pragmatic rules worked well with limited choice of technologies, interconnection strategies, routing protocols • Times have changed – We must adapt design process to the variety of options – Many new types of services can be offered to the users – Additionally to the capacity planning we need to consider optimization of the delay in the network – Providing reliability is more than just redundant paths in the network or resilient routing prtocols ©2003 Algirdas Pakštas Sisteminis tinklų planavimo metodas bei reikalavimų analizės rolė (nuo meno link inžinerijos) 7 The Analysis and Design Processes • Network analysis and design is a combination of – Design goals – Trade-offs • Balance between architecture and function • Design goals could be such as – Minimizing network costs – Maximizing performance • Trade-offs – Cost vs. performance – Simplicity vs. function – Many ways to achieve design goals - rarely single “right” one • There are often many wrong ways... ©2003 Algirdas Pakštas Sisteminis tinklų planavimo metodas bei reikalavimų analizės rolė (nuo meno link inžinerijos) 8 The Analysis and Design Processes • Components of the Analysis and Design Processes (listed consequently): – The Systems Approach to Design – Requirement Analysis – Flow Analysis – Logical Design – Physical Design – Addressing and Routing ©2003 Algirdas Pakštas Sisteminis tinklų planavimo metodas bei reikalavimų analizės rolė (nuo meno link inžinerijos) 9 Network Services and Services-Based Networking • There has been significant effort to define and specify “services” in the ISO/OSI model • It is a new approach to looking at networking from the services prospective in the IP-world • “Services-Based Networking is the concept of developing network designs that take into account network services and service support” ©2003 Algirdas Pakštas Sisteminis tinklų planavimo metodas bei reikalavimų analizės rolė (nuo meno link inžinerijos) 10 Network Services and Services-Based Networking Generations of the network services Generation Time Frame Capability First 1960s-mid-1980s Basic connectivity/ interoperability Second mid-1980sPerformance (IP early/mid-1990s forwarding rates) Third (current) mid-to-late 1990s Network Services (levels of network performance and function) Fourth 2000-2010 Self-configuration/ administration ©2003 Algirdas Pakštas Sisteminis tinklų planavimo metodas bei reikalavimų analizės rolė (nuo meno link inžinerijos) 11 Systems and Network Services: Systems “A network system is the set of components that work together to support or provide connectivity, communications, and network services to users of the system” Generic components of a System | User | | User | |Application| |Application| | Host | ! Host | ------------------|------(Network)-----| ©2003 Algirdas Pakštas Sisteminis tinklų planavimo metodas bei reikalavimų analizės rolė (nuo meno link inžinerijos) 12 Systems and Network Services: Systems Traditional View of a System ----------------------| Host | | Host | ----------------------|----- (Network) ---| Network design have focused on providing connectivity between hosts Systems were described as the set (host,network) and typically did not consider the users or applications Thus, there is a need to define more precisely the set (user, application, host, network) Sometime definitions of the “host” and the “network” are not very much obvious ©2003 Algirdas Pakštas Sisteminis tinklų planavimo metodas bei reikalavimų analizės rolė (nuo meno link inžinerijos) 13 Systems and Network Services: Interfaces and Boundaries If the components are known then thethe boundary condition between them can be set and therefore the interfaces Example: User User Application Application Host Host Display Parameters User Interface API, QoS, ToS Drivers, Interfaces Network ©2003 Algirdas Pakštas Sisteminis tinklų planavimo metodas bei reikalavimų analizės rolė (nuo meno link inžinerijos) 14 Systems and Network Services: ATM in Network Backbone Example: The picture below is showing the ATM as a backbone technology | User | |Application | | User | |Application | | Host | | Host | ------------------\-------(x) NETWORK (x)--------| \--[atmX]---[atmX] --/ Here (x) - Router [atmX] - ATM Switch Here the ATM environment is isolated from the hosts, applications and users by the routers ©2003 Algirdas Pakštas Sisteminis tinklų planavimo metodas bei reikalavimų analizės rolė (nuo meno link inžinerijos) 15 Systems and Network Services: “Native” ATM Network Example: The picture below is showing a “native” ATM network in which ATM is integrated into the host side [User] [User] [Application] [Application] --------------------------------(ATM)--------------------------------- [ATM Specific API] [ATM Specific API] [ATM Device Driver] [ATM Device Driver] \ [atmX]-[atmX]-[atmX]-[atmX]/ Here [atmX] - ATM Switch Here the ATM is integrated into the host and will interface directly with the applicaions The system is best described as as the set (user,application, ATM-specific API, ATM device driver, network) ©2003 Algirdas Pakštas Sisteminis tinklų planavimo metodas bei reikalavimų analizės rolė (nuo meno link inžinerijos) 16 Systems and Network Services: Services • According to the IETF and ATM Forum – Network Services are sets of network capabilities that can be configured and managed within the network – Network Services are defined • as levels of performance and function that are offered by the network, host, and/or application, to the rest of the system, • or as sets of requirements that are expected from the network by the end user, application, or host ©2003 Algirdas Pakštas Sisteminis tinklų planavimo metodas bei reikalavimų analizės rolė (nuo meno link inžinerijos) 17 Systems and Network Services: Services • Levels of performance are described by the performance characteristics, e.g. – capacity – delay – reliability • Functions include – – – – – security accounting billing scheduling management ©2003 Algirdas Pakštas Sisteminis tinklų planavimo metodas bei reikalavimų analizės rolė (nuo meno link inžinerijos) 18 Systems and Network Services: Services • Network services: groups of characteristics and levels Service Characteristics Characteristic A \ Characteristic B }-> Service Level Characteristic C / Level A \ … / Level B }-> Network Service | Level C / Description for Design V … / Characteristics used to configure services in network and as service metrics to measure and verify services ©2003 Algirdas Pakštas Sisteminis tinklų planavimo metodas bei reikalavimų analizės rolė (nuo meno link inžinerijos) 19 Systems and Network Services: Service Characteristics Service characteristics = Individual network performance and functional parameters Service offering - by the network to the system Service request - from the network by users, applications, or hosts Service requirements = characteristics that are used to gauge the system’s need for services ©2003 Algirdas Pakštas Sisteminis tinklų planavimo metodas bei reikalavimų analizės rolė (nuo meno link inžinerijos) 20 Systems and Network Services: Service Characteristics Service characteristics and requirements are useful in the network analysis and design processes: In configuring services in network elements (routers, switches, host operating systems) In providing input into the network design Need to be described and provisioned end-toend, at all components between end users, applications and hosts Service may fail if some components are not capable to support it! ©2003 Algirdas Pakštas Sisteminis tinklų planavimo metodas bei reikalavimų analizės rolė (nuo meno link inžinerijos) 21 Systems and Network Services: Service Levels Service requirements or characteristics are grouped together to describe service levels Easier to configure, measure and verify service level instead of a number of individual service characteristics Helpful in service accounting and billing Service levels can be described with the help of Committed Information Rates (CIRs) Classes of Services (CoSs) Types of Services (ToSs) Qualities of Services (QoSs) Custom service levels based on groups of individual service characteristics depending on technology, protocol, etc. ©2003 Algirdas Pakštas Sisteminis tinklų planavimo metodas bei reikalavimų analizės rolė (nuo meno link inžinerijos) 22 Characterizing Services Service Requests Service Offerings Service Performance Requirements Service Metrics Reservations and Deadline Scheduling ©2003 Algirdas Pakštas Sisteminis tinklų planavimo metodas bei reikalavimų analizės rolė (nuo meno link inžinerijos) 23 Characterizing Services Service Requests Can be distinguished by the degree of predictability: Best-effort (e.g. best-effort delivery) Specified, i.e. deterministic and guaranteed ©2003 Algirdas Pakštas Sisteminis tinklų planavimo metodas bei reikalavimų analizės rolė (nuo meno link inžinerijos) 24 Characterizing Services Service Requests Best-effort: No control over how network will satisfy the service request No guarantees are presented Network is not obligated to do more than try Indicates that the rest of the system (user, application, host) will need to adapt to the state of the network at any given time ©2003 Algirdas Pakštas Sisteminis tinklų planavimo metodas bei reikalavimų analizės rolė (nuo meno link inžinerijos) 25 Characterizing Services Service Requests Best-effort: Expected service for such requests is unpredictable and variable Such service requests Either have no performance requirements for the network Or the requirements are nonspecific Consequently service requests are not tuned to any specific user or application (i.e. very much universal, generally oriented) ©2003 Algirdas Pakštas Sisteminis tinklų planavimo metodas bei reikalavimų analizės rolė (nuo meno link inžinerijos) 26 Characterizing Services Service Requests Specified service requests Are based on some knowledge of or control over the state of the system Have more stringent service requirements (i.e. deterministic and guaranteed) than best-effort To support a deterministic service request by the network the service requirements of the request must be measurable and verifiable Need for the service metrics ©2003 Algirdas Pakštas Sisteminis tinklų planavimo metodas bei reikalavimų analizės rolė (nuo meno link inžinerijos) 27 Characterizing Services Service Requests Specified service requests EXAMPLE: If service request is made for capacity to be 4-10 Mb/s Then there must be Way to translate these service requirements into a service offering from the network Way to measure and/or to derive these capacity characteristics from the network Statistical method to control the information flow and the network to keep this service between the targeted 4-10 Mb/s ©2003 Algirdas Pakštas Sisteminis tinklų planavimo metodas bei reikalavimų analizės rolė (nuo meno link inžinerijos) 28 Characterizing Services Service Requests Specified service requests Service performance requirements are usually grouped into service levels Service levels can be the same as specified service requests And also can be closely related to well-known service offerings from the network such as ATM QoS SMDS CoS ... ©2003 Algirdas Pakštas Sisteminis tinklų planavimo metodas bei reikalavimų analizės rolė (nuo meno link inžinerijos) 29 Characterizing Services Service Requests Specified service requests Mapping Service Levels to Service Offerings: Service Request Service Performance Requirements Service Levels (Groups of Requirements) | | | Service Metrics -------------------------------------------------| | | SMDS CoS ATM QoS Frame Relay CIR Service Performance Characteristics Service Offering SMDS CoS - Switched Multimegabit Data Service Classes of Service ATM QoS - Asynchronous Transfer Mode Quality of Service CIR - Committed Information Rates ©2003 Algirdas Pakštas Sisteminis tinklų planavimo metodas bei reikalavimų analizės rolė (nuo meno link inžinerijos) 30 Characterizing Services Service Offerings Similarly to the Service Requests the Service Offerings are also grouped as: Best-effort Specified ©2003 Algirdas Pakštas Sisteminis tinklų planavimo metodas bei reikalavimų analizės rolė (nuo meno link inžinerijos) 31 Characterizing Services Service Offerings Best-effort Internet is a good example Best-effort service offering is compatible with the best-effort service request EXAMPLE: File transfer (via FTP) occurs over IP FTP uses TCP which via sliding window flow control mechanism adapts to the current state of the network it is operating over Service requirement from FTP over TCP is best-effort Service offering from the Internet is best effort During the FTP session the performance characteristics of the IP network and transport method (TCP) are constantly adapted ©2003 Algirdas Pakštas Sisteminis tinklų planavimo metodas bei reikalavimų analizės rolė (nuo meno link inžinerijos) 32 Characterizing Services Service Offerings Specified (deterministic and guaranteed) service offerings are: Predictable, bounded, or guaranteed Specified refers to the network’s ability to offer a measurable and verifiable service Can be low- or high-performance Specified service does not imply high performance Similarly, ISO 900x quality assurance standards can not guarantee you a GOOD THING but just a SPECIFIED QUALITY whatever they mean by it!!! ©2003 Algirdas Pakštas Sisteminis tinklų planavimo metodas bei reikalavimų analizės rolė (nuo meno link inžinerijos) 33 Characterizing Services Service Offerings EXAMPLE of Specified Service : Network to support real-time telemetry data Design goal would be the ability to specify endto-end delay and have the network to satisfy this delay request For example, a service request may be for an end-toend delay of 25ms, with a delay variation of 400s This would form the request and the service level (i.e. QoS level) that needs to be supported by the network The network would then be designed to provide a specified service offering at a QoS level of 25ms endto-end delay and 400s delay variation The delay and delay variation would then be measured and verified with service metrics (using tools such as ping or tcpdump, or with custom one) ©2003 Algirdas Pakštas Sisteminis tinklų planavimo metodas bei reikalavimų analizės rolė (nuo meno link inžinerijos) 34 Characterizing Services Service Offerings Service Requests and Offerings Service Request | | Best-Effort Deterministic/Guaranteed | | | Service Performance Characteristics/Levels | | | | Service Metrics -------------------------------------------------------| | | | | Service Performance Characteristics/Levels | | Best-effort Deterministic/Guaranteed | | Service Offering ©2003 Algirdas Pakštas Sisteminis tinklų planavimo metodas bei reikalavimų analizės rolė (nuo meno link inžinerijos) 35 Characterizing Services Service Performance Requirements Service Performance Requirements Reliability, Capacity and Delay are related to each other Reliability: Definition by the J.D.McCabe: “Reliability is a measure of the system’s ability to provide deterministic and accurate delivery of information...” – IT CAN BE ARGUED THAT RELIABILITY IS ONLY THE GUARANTEE OF ACCURACY WITH NO TIME CONSTRAINTS – DIFFERENT DEFINITION OF RELIABLITY MAY LEAD TO BUILDING DIFFERENT CONCEPTS WHICH BETTER REFLECT A REAL WORLD VIEW TO THE SYSTEM’S DESIGN ©2003 Algirdas Pakštas Sisteminis tinklų planavimo metodas bei reikalavimų analizės rolė (nuo meno link inžinerijos) 36 Characterizing Services Service Performance Requirements Capacity “It is a measure of the system’s ability to transfer information” This term is often used intechangeably with bandwidth, throughput and goodput Bandwidth is sometime described as theoretical capacity what is not strictly correct (remember Nyquist’s and Shannon’s equations?) Throughput is the realizable capacity of the system or its components or elements SONET OC-3c circuit is designed to achieve data rate 155.52 Mb/s = 3x51.84 Mb/s (i.e. 3xOC-1 circuits) Practically achievable throughput is ~80-128 Mb/s ©2003 Algirdas Pakštas Sisteminis tinklų planavimo metodas bei reikalavimų analizės rolė (nuo meno link inžinerijos) 37 Characterizing Services Service Performance Requirements Delay “It is a measure of the time which is taken for the transmission of the single unit of information (bit, byte, cell, frame, packet) across the system” Often used are propagation, transmission, queueing, and processing delays End-to-end and round-trip delays are useful measurements Delay represents microscopic view of network behaviour Latency can be defined as an overall delay caused by the application processing and task completion times Latency represents macroscopic view of network behaviour ©2003 Algirdas Pakštas Sisteminis tinklų planavimo metodas bei reikalavimų analizės rolė (nuo meno link inžinerijos) 38 Characterizing Services Service Performance Requirements Performance Envelops Useful for visualizing the regions of performance in which the network will be expected to operate Service performance requirements can be mapped from the applications onto such environments in order to show relative performance of each application EXAMPLES: 2-D Service Performance Envelop describing Capacity, Data Size and End-to-end Delay 3-D Service Performance Envelop including Reliability ©2003 Algirdas Pakštas Sisteminis tinklų planavimo metodas bei reikalavimų analizės rolė (nuo meno link inžinerijos) 39 Characterizing Services Service Performance Requirements 2-D Service Performance Envelop describing Capacity, Data Size and End-to-end Delay ©2003 Algirdas Pakštas Sisteminis tinklų planavimo metodas bei reikalavimų analizės rolė (nuo meno link inžinerijos) 40 Characterizing Services Service Performance Requirements 3-D Service Performance Envelop including Reliability Note low-performance and high-performance regions! ©2003 Algirdas Pakštas Sisteminis tinklų planavimo metodas bei reikalavimų analizės rolė (nuo meno link inžinerijos) 41 Characterizing Services Service Metrics Service metrics are intended to be measurable Can be used to establish reference levels (a combination of service metrics for reliability, capacity and delay) for service performance 3 types of reference levels: Service thresholds Service boundaries Service guarantees ©2003 Algirdas Pakštas Sisteminis tinklų planavimo metodas bei reikalavimų analizės rolė (nuo meno link inžinerijos) 42 Characterizing Services Service Metrics Service thresholds - discriminators used on applications to distinguish between highperformance and low-performance service Service boundaries - combinations of lowand/or high-performance levels used to predict a service level for an application Service guarantees - strict performance levels. If they are not met it may cause some type of action from the system (such as policing) ©2003 Algirdas Pakštas Sisteminis tinklų planavimo metodas bei reikalavimų analizės rolė (nuo meno link inžinerijos) 43 Characterizing Services Service Metrics Reference levels are described in terms of service metrics for the system EXAMPLE: System using SNMP has MIB variables for each network element We may choose: A reference level of the amount of the capacity being utilized A service metric of the number of bytes in or out of each interface of the network elements MIB variables of ifInOctets and ifOutOctets ©2003 Algirdas Pakštas Sisteminis tinklų planavimo metodas bei reikalavimų analizės rolė (nuo meno link inžinerijos) 44 Characterizing Services Service Metrics Example of Reference Levels-Service Thresholds Threshold | App3 App6 | App5 App2 App1 | App4 --------------------|---------------> Service Low Capacity | High Capacity Threshold Expected/Predicted Application Capacities ©2003 Algirdas Pakštas Sisteminis tinklų planavimo metodas bei reikalavimų analizės rolė (nuo meno link inžinerijos) 45 Characterizing Services Service Metrics Example of Reference Levels Boundaries and Guarantees ©2003 Algirdas Pakštas Sisteminis tinklų planavimo metodas bei reikalavimų analizės rolė (nuo meno link inžinerijos) 46 Characterizing Services Reservations and Deadline Scheduling Some applications may be operating in real-time Session may be not active until time T Resources for this application are not required until time T and can be used for something else Application may have a deadline when all tasks must be completed May need prioritizing of the use of network resources for this application ©2003 Algirdas Pakštas Sisteminis tinklų planavimo metodas bei reikalavimų analizės rolė (nuo meno link inžinerijos) 47 Conclusions for PART 1 It is very important to take a system’s approach to network design System = (user, application, host, network) System is offering services to the end users/customers In order to implement services and and achieve their characteristics we need to quantify requirements Requirements Analysis is the next step in the network analysis process: To gather, analyze, and understand the requirements from the system ©2003 Algirdas Pakštas Sisteminis tinklų planavimo metodas bei reikalavimų analizės rolė (nuo meno link inžinerijos) 48 PART 2: OUTLINE Requirements Analysis: Concepts Background for Requirement Analysis User Requirements Application Requirements Types of Applications Reliability Capacity Delay Application Groups Host Requirements Types of Host and Equipment Performance Characteristics Location Information Network Requirements Existing Networks and Migration Functional Requirements Financial Requirements Enterprise Requirements ©2003 Algirdas Pakštas Sisteminis tinklų planavimo metodas bei reikalavimų analizės rolė (nuo meno link inžinerijos) 49 Background for Requirement Analysis Requirement Analysis helps to understand design environment Consists of Identifying, gathering, and understanding system requirements and their characteristics Developing thresholds for performance to distinguish between low- and high-performance services Determining specified services for the network Requirement Analysis is fundamental to the network design process but is often overlooked or ignored ©2003 Algirdas Pakštas Sisteminis tinklų planavimo metodas bei reikalavimų analizės rolė (nuo meno link inžinerijos) 50 Background for Requirement Analysis Gathering requirements means talking to users and network personnel and interpreting the results Each user has its own set of requirements Network personnel are often distanced from the users and do not have clear idea of what users want or need Thus it is a difficult part of the design process Not doing it may lead to the solutions which are not those which the users and applications may need ©2003 Algirdas Pakštas Sisteminis tinklų planavimo metodas bei reikalavimų analizės rolė (nuo meno link inžinerijos) 51 Background for Requirement Analysis EXAMPLES: Design is based on a particular technology, typically on the most comfortable for the designer Design is based on a particular vendor… This happens due to the budget constraints and deadlines which are forcing to use familiar, easy to apply technologies Problem is that such designs are not objective Familiar technologies, protocols or vendors may be poor choices for that particular environment ©2003 Algirdas Pakštas Sisteminis tinklų planavimo metodas bei reikalavimų analizės rolė (nuo meno link inžinerijos) 52 Background for Requirement Analysis The results of the Requirement Analysis are Requirements Specification Application Map Requirements Specification is a series of worksheets that list the requirements gathered for the design Application Map shows the location dependencies between applications Will be used for Flow Analysis ©2003 Algirdas Pakštas Sisteminis tinklų planavimo metodas bei reikalavimų analizės rolė (nuo meno link inžinerijos) 53 User Requirements The user component of the generic system and the interface: [ User ] [ User ] /Timeliness ---------------------------------------< Interactivity [Application] [Application] \Reliability [ Host ] [ Host ] ------------------\----(Network)-----/ Quality Adaptability Security Affordability User Numbers User Locations Expected Growth ©2003 Algirdas Pakštas Sisteminis tinklų planavimo metodas bei reikalavimų analizės rolė (nuo meno link inžinerijos) 54 User Requirements Timeliness “Timeliness is a requirement that the user is able to access, transfer, or modify information within a tolerable time frame” What is “tolerable” depends on the user’s perception of the delay in the system EXAMPLES-delays that network will need to provide: User wants to download files from a server and complete each transfer in 10 minutes User wants to receive video frames every 30ms End-to-end or round-trip delay is important measurement ©2003 Algirdas Pakštas Sisteminis tinklų planavimo metodas bei reikalavimų analizės rolė (nuo meno link inžinerijos) 55 User Requirements Interactivity Similar to “timeliness” but focuses on a response time from the system or network Interactivity is to be looked as an indication of the response time which are on the order of the human response times “Interactivity is a measure of the response time of the system when it is required to actively interact with a human” The round-trip delay is a measure of the interactivity ©2003 Algirdas Pakštas Sisteminis tinklų planavimo metodas bei reikalavimų analizės rolė (nuo meno link inžinerijos) 56 User Requirements Reliability From the user prospective it is a requirement for constantly available service Possibility to have access to system resources a very high percentage of time Consistent level of service to the user in terms of network performance Thus, reliability as requirement is closely related to the performance characteristic reliability where delay and capacity are also important ©2003 Algirdas Pakštas Sisteminis tinklų planavimo metodas bei reikalavimų analizės rolė (nuo meno link inžinerijos) 57 User Requirements Quality Refers to the quality of the presentation to the user Perception of audio, video and/or data displays EXAMPLE: Providing videoconferencing, videofeeds and telephony It is possible to do it on the Internet! But other technologies can provide much better presentation quality It is often not sufficient to provide just a capability over a network Measures of quality should include all the performance characteristics ©2003 Algirdas Pakštas Sisteminis tinklų planavimo metodas bei reikalavimų analizės rolė (nuo meno link inžinerijos) 58 User Requirements Adaptability “It is ability of the system to adapt to the user’s changing needs” EXAMPLES: Distance-independence Relying on the network Coupling to the logical servers and decoupling from the physical - it does not matter where the servers are as long as users can get services As a result user may lose a part of his rights - the ability to know where the job was executed Mobility Mobile computing, access to the services and resources from any location via portable computers and ad-hoc access to the network Adaptability must be reflected in the system design ©2003 Algirdas Pakštas Sisteminis tinklų planavimo metodas bei reikalavimų analizės rolė (nuo meno link inžinerijos) 59 User Requirements Security It is a requirement to guarantee Integrity (accuracy and authenticity) of the user’s information and physical resources Access to the user’s and system resources Security is probably closest to the performance characteristic reliability It impacts capacity and delay ©2003 Algirdas Pakštas Sisteminis tinklų planavimo metodas bei reikalavimų analizės rolė (nuo meno link inžinerijos) 60 User Requirements Affordability It is the last general user requirement “We would like to have it but how much does it cost?” Not technical but will impact the network design! We have to look at the user/customer budget Are design costs too expensive to implement? How cost and funding are tied to users or groups of users? Funding should be discussed as a system-wide requirement from the overall budget perspective ©2003 Algirdas Pakštas Sisteminis tinklų planavimo metodas bei reikalavimų analizės rolė (nuo meno link inžinerijos) 61 Application Requirements We will look at Types of Applications Reliability Capacity Delay Application Groups [ User ] [ User ] [Application] [Application] [ Host ] [ Host ] ------------------\----(Network)-----/ ©2003 Algirdas Pakštas Sisteminis tinklų planavimo metodas bei reikalavimų analizės rolė (nuo meno link inžinerijos) 62 Application Requirements Types of Applications Service and service performance requirements of the applications can be characterized as: Mission-critical applications Deterministic and/or guaranteed reliability Controlled-rate applications Specified capacity Real-time/interactive applications Specified delay ©2003 Algirdas Pakštas Sisteminis tinklų planavimo metodas bei reikalavimų analizės rolė (nuo meno link inžinerijos) 63 Application Requirements Types of Applications User Service and Performance Requirements Timeliness \_________________ / DELAY Interactivity / \ Reliability \ / Quality \__________________/ RELIABILITY Adaptability / \ Security / \ Affordability \ / User Numbers \_____________/ CAPACITY User Locations / \ Expected Growth / \ ©2003 Algirdas Pakštas Sisteminis tinklų planavimo metodas bei reikalavimų analizės rolė (nuo meno link inžinerijos) 64 Application Requirements Reliability Reliability can be subjective but some applications must maintain high reliability in order to function Loss of reliability can result in Loss of revenue or customers Typical application: transaction/money dependant, investment banking or airline reservation system Unrecoverable information or situation Telemetry processing and teleconferencing applications Loss of sensitive data Customer ID/billing and intelligence-gathering applications Loss of life Transportation or health-care monitoring applications QUESTION: Can the Best-Effort System be at all suitable for the mission-critical applications? ©2003 Algirdas Pakštas Sisteminis tinklų planavimo metodas bei reikalavimų analizės rolė (nuo meno link inžinerijos) 65 Application Requirements Capacity Could be required by the applications having well understood amount of capacity EXAMPLE: Controlled-rate applications Voice, non-buffered video, some teleservice applications May require to define: Thresholds Bounds Guarantees on minimum capacity Peak capacity Sustained capacity Can be tied to the end-to-end delay of the network ©2003 Algirdas Pakštas Sisteminis tinklų planavimo metodas bei reikalavimų analizės rolė (nuo meno link inžinerijos) 66 Application Requirements Delay Optimizing the total (end-to-end and roundtrip) delay is the most important for the application service Need for “better than the best-effort” services Applications with delay requirements are migrating to the Internet or IP intranets Applications previously dedicated to a single user/host are used via Internet/intranet Term “real-time” describes the need for strict delay tolerance ©2003 Algirdas Pakštas Sisteminis tinklų planavimo metodas bei reikalavimų analizės rolė (nuo meno link inžinerijos) 67 Application Requirements Delay Real-time applications Have the most strict timing relationship between source and destination Timers are set for the receipt of information If information is received after the timers expire it is considered worthless and is dropped Does not mean that information has to be transferred within predefined time, rather Delay boundaries (and, hopefully, consequences) are understood by source and destination Destination does not wait beyond this boundary EXAMPLE: Video playback - delay beyond the playback timer can cause blank parts in frames ©2003 Algirdas Pakštas Sisteminis tinklų planavimo metodas bei reikalavimų analizės rolė (nuo meno link inžinerijos) 68 Application Requirements Delay Non-real-time applications Various end-to-end delay requirements Destination will wait until the information is received (defined by the timers in applications and hosts) Majority of the applications are non-real-time Can be Interactive Asynchronous ©2003 Algirdas Pakštas Sisteminis tinklų planavimo metodas bei reikalavimų analizės rolė (nuo meno link inžinerijos) 69 Application Requirements Delay Interactive applications Assume timing relationship between source and destination Typical applications: telnet, FTP, Web Asynchronous applications Intensive to time Assumes no timing relationship EXAMPLE: E-mail Can be Burst Bulk ©2003 Algirdas Pakštas Sisteminis tinklų planavimo metodas bei reikalavimų analizės rolė (nuo meno link inžinerijos) 70 Application Requirements Delay Application Delay Types Real Time| Non-Real-Time | / \ |Interactive |Asynchronous | / \ | |Burst | Bulk |Time-Intensive -------------------------------------Telemetry|Telnet| FTP |E-mail Processing ©2003 Algirdas Pakštas Sisteminis tinklų planavimo metodas bei reikalavimų analizės rolė (nuo meno link inžinerijos) 71 Application Requirements Application Groups It is useful to group together the applications with similar performance characteristics Helps in mapping performance characteristics Helps in gathering requirements Groups may have some overlap… EXAMPLES of the groups are discussed below ©2003 Algirdas Pakštas Sisteminis tinklų planavimo metodas bei reikalavimų analizės rolė (nuo meno link inžinerijos) 72 Application Requirements Application Groups Command and control/telemetry applications Information is transmitted between remote objects Characterized as having high-performance delay and reliability Possibly mission-critical and/or real-time applications Visualization applications Viewing and manipulation of 2-D, 3-D and VR objects Characterized as having high-performance capacity and delay Possibly real-time and/or controlled-rate applications ©2003 Algirdas Pakštas Sisteminis tinklų planavimo metodas bei reikalavimų analizės rolė (nuo meno link inžinerijos) 73 Application Requirements Application Groups Distributed computing applications Different variants of the processor coupling Share the same local bus Co-located at the same LAN (computing cluster) Distributed across LAN, MAN, and WAN boundaries Degree of distribution/parallelism is also determined by the granularity of the task Characterized as having high performance delay Possibly being interactive applications ©2003 Algirdas Pakštas Sisteminis tinklų planavimo metodas bei reikalavimų analizės rolė (nuo meno link inžinerijos) 74 Application Requirements Application Groups Applications for Web access, development and use Involves accessing remote host and downloading/uploading information Web-sessions are Interactive Amounts of information are small Characterized as being delay-sensitive but NOT highperformance ©2003 Algirdas Pakštas Sisteminis tinklų planavimo metodas bei reikalavimų analizės rolė (nuo meno link inžinerijos) 75 Application Requirements Application Groups Bulk data transport Typically file transfer (FTP) Optimization of the data transfer rate at the expense of interactivity Characterized as being not high-performance Tele-service applications Teleconferencing, telemedicine, teleseminars,… Simultaneous delivering of mixture of the data, voice, and video to the groups of people at various locations EXAMPLE: Multicast backbone (mbone) on the Internet Characterized as having high-performance capacity, delay, and/or reliability, depending on ©2003 Algirdas Pakštas 76 application Sisteminis tinklų planavimo metodas bei reikalavimų analizės rolė (nuo meno link inžinerijos) Application Requirements Application Groups Operations, administration, and maintenance (OAM) applications Needed for proper functioning and operation of the network Domain name service (DNS) Mail service/SMTP News services/NNTP Address resolution service (ARP) Network monitoring and management Network security Systems accounting Generally requires high reliability ©2003 Algirdas Pakštas Sisteminis tinklų planavimo metodas bei reikalavimų analizės rolė (nuo meno link inžinerijos) 77 Application Requirements Application Groups Application Component Interface to System [ User ] [ User ] /Application | | / Group [Application] [Application] / Application -----------------------------------------< Type [ Host ] [ Host ] | Application ------------------| Performance \----(Network)-----/ | Characteristics |Application | Locations ©2003 Algirdas Pakštas Sisteminis tinklų planavimo metodas bei reikalavimų analizės rolė (nuo meno link inžinerijos) 78 Host Requirements Host Component of the Generic System [ User ] [ User ] | | [Application] [Application] | | [ Host ] [ Host ] ------------------\----(Network)-----/ We will look at Types of Host and Equipment Performance Characteristics Location Information ©2003 Algirdas Pakštas Sisteminis tinklų planavimo metodas bei reikalavimų analizės rolė (nuo meno link inžinerijos) 79 Host Requirements Types of Host and Equipment Generic computing devices Dos-, Windows-based PCs, Macs, Unix workstations, etc. Form access points into the network for [single] user Important from end-to-end perspective Tend to be overlooked Creates “last foot” problem in systems performance ©2003 Algirdas Pakštas Sisteminis tinklų planavimo metodas bei reikalavimų analizės rolė (nuo meno link inžinerijos) 80 Host Requirements Types of Host and Equipment Servers More powerful Computing servers, storage servers, application servers, etc. Also have requirements for “last foot” performance Requirements specific to the server’s role Specialized Equipment Supercomputers, mainframes, parallel or distributed computing systems, sensors, data acquisition devices, etc. Tends to be location-dependent ©2003 Algirdas Pakštas Sisteminis tinklų planavimo metodas bei reikalavimų analizės rolė (nuo meno link inžinerijos) 81 Host Requirements Types of Host and Equipment Specialized Equipment Tends to be Location-Dependent ©2003 Algirdas Pakštas Sisteminis tinklų planavimo metodas bei reikalavimų analizės rolė (nuo meno link inžinerijos) 82 Host Requirements Performance Characteristics Performance of the components impacts the overall performance of the server/host Operating System Processing Memory System Bus Network Interface Disk Drive ©2003 Algirdas Pakštas Sisteminis tinklų planavimo metodas bei reikalavimų analizės rolė (nuo meno link inžinerijos) Other Peripherals 83 Host Requirements Performance Characteristics Performance of the components end-to-end in the host is important Storage performance Disk-drive seek time Tape performance Processor (CPU) performance Memory performance Access time System bus performance Capacity and arbitration mechanisms Effectiveness of Software Driver OS (effectiveness of the protocol stack) Number of memory copies in the protocol stack Cost of execution of a given OS API ©2003 Algirdas Pakštas Sisteminis tinklų planavimo metodas bei reikalavimų analizės rolė (nuo meno link inžinerijos) 84 Host Requirements Location Information Helps to determine Relationships between components Flow characteristics Particularly important In the outsourcing of system components or functions In the consolidation of organizations, components or functions In the relocation of system components or functions within an organization ©2003 Algirdas Pakštas Sisteminis tinklų planavimo metodas bei reikalavimų analizės rolė (nuo meno link inžinerijos) 85 Host Requirements System Components can have Location Dependencies ©2003 Algirdas Pakštas Sisteminis tinklų planavimo metodas bei reikalavimų analizės rolė (nuo meno link inžinerijos) 86 Host Requirements Summary of the Host/Network Interface Host Component Interface to System [ User ] [ User ] /Types of | | / Hosts and [Application] [Application] / Equipment | | / [ Host ] [ Host ] / Location ------------------- / Information ---------|----------------------|------< \----(Network)----/ \ Host/Equipment \ \ Performance Characteristics ©2003 Algirdas Pakštas Sisteminis tinklų planavimo metodas bei reikalavimų analizės rolė (nuo meno link inžinerijos) 87 Network Requirements Existing Networks and Migration Functional Requirements Financial Requirements Enterprise Requirements ©2003 Algirdas Pakštas Sisteminis tinklų planavimo metodas bei reikalavimų analizės rolė (nuo meno link inžinerijos) 88 Network Requirements Existing Networks and Migration Network Component Interface to System [ User ] [ User ] /-Scaling | | / [Application] [Application] / -Interoperability | | / [ Host ] [ Host ] / -Location Information ------------------/ | | / -Network Services ( Network )--< :…....(<Existing Network> )...: \ -Support Services : / : \ :...<Existing Network>…....: \ -Network Performance \ Characteristics ©2003 Algirdas Pakštas Sisteminis tinklų planavimo metodas bei reikalavimų analizės rolė (nuo meno link inžinerijos) 89 Network Requirements Functional Requirements Requirements for Network Management and Security Categories of network management tasks Monitoring (automatic?) For event notification (frequent snapshot of the system) For metrics and planning (large archives) Actions (manual?) Network configuration Troubleshooting Monitoring: Obtaining values for network management parameters from network elements Processing the data Visualization Archiving the data ©2003 Algirdas Pakštas Sisteminis tinklų planavimo metodas bei reikalavimų analizės rolė (nuo meno link inžinerijos) 90 Network Requirements Functional Requirements General Network Management Requirements Monitoring methods Instrumentation methods Protocols (SNMP, SNMPv2/v3, CMIP, RMON) Parameter lists (MIBs) Monitoring tools Direct access The characteristics sets for monitoring In-band vs. out-of-band monitoring Centralized vs. distributed monitoring Performance requirements ©2003 Algirdas Pakštas Sisteminis tinklų planavimo metodas bei reikalavimų analizės rolė (nuo meno link inžinerijos) 91 Network Requirements Functional Requirements Developing a security plan for the network: User requirements Security policies Risk analysis User Requirements for Security Government specified requirements: MoD/DoD/DoE... Organization-specified security requirements End-user-specified security requirements May be applied to Users/User groups Projects Specific types of data (also how data are generated, transferred, processed and stored) ©2003 Algirdas Pakštas Sisteminis tinklų planavimo metodas bei reikalavimų analizės rolė (nuo meno link inžinerijos) 92 Network Requirements Financial Requirements Level of funding for implementing network design is system-wide requirement Funding is associated with Overall cost limit Recurring components Expected to occur or be replaced/upgraded periodically Operations, administrations and maintenance, costs from service providers, provisions for network modification Non-recurring components - building of the network Network design Network deployment Hardware/Software components Initial installation or establishment of any services from service providers ©2003 Algirdas Pakštas Sisteminis tinklų planavimo metodas bei reikalavimų analizės rolė (nuo meno link inžinerijos) 93 Network Requirements Enterprise Requirements Enterprises need transfer of Phone/voice FAX Video Enterprise environment presumes integration of such services into a common transmission infrastructure ©2003 Algirdas Pakštas Sisteminis tinklų planavimo metodas bei reikalavimų analizės rolė (nuo meno link inžinerijos) 94 Requirement Analysis Conclusions The Process Model for Requirement Analysis ©2003 Algirdas Pakštas Sisteminis tinklų planavimo metodas bei reikalavimų analizės rolė (nuo meno link inžinerijos) 95 Bibliography • James D. McCabe: “Practical Computer Network Analysis and Design”, Morgan Kaufmann Publishers, San Francisco, USA, 1998. ISBN 1-55860-498-7 • Algirdas Pakštas: Raspredelennye programmnye konfiguracii: Analiz i razrabotka (“Distributed Software Configurations: Analysis and Development”), Mokslas, Vilnius, 1989. ISBN 5-420-00637-5 ©2003 Algirdas Pakštas Sisteminis tinklų planavimo metodas bei reikalavimų analizės rolė (nuo meno link inžinerijos) 96