Requirement Analysis Concepts in Network Analysis and Design

Components of the Network Analysis and Design (NAD) Process

• The NAD process is a systematic approach to network design that involves several phases and components:
  • Systems and Network Services: Includes characterizing services.
  • Requirement Analysis: Involves identifying user, application, host, and network requirements. It includes gathering requirements, determining service metrics and performance, characterizing behavior, and setting performance thresholds and levels.
  • Flow Analysis: Involves identifying data sources and sinks, flow models, boundaries, distributions, and specifications.
  • Logical Design: This phase focuses on technology choice and interconnection mechanisms.
  • Physical Design: Involves cable plant design options and the placement of network equipment.
  • Addressing and Routing: Includes establishing network diagrams and worksheets, establishing routing flows, and developing addressing and routing strategies.

Introduction to Requirement Analysis (RA)

• Definition: RA is the foundational process of identifying, gathering, and understanding system requirements and characteristics. It involves developing thresholds for performance and determining specified services.
• RA Scope: To perform a successful RA, a designer must understand:
  • The design environment.
  • How to identify and gather system requirements.
  • How to develop performance thresholds to distinguish between high-performance and low-performance services.
  • User needs and their related application needs.
  • The probable behavior of the network under design.
• Advantages for Network Designers:
  • Network Behavior Knowledge: Helps the designer better understand how the network being designed will behave.
  • Performance Insight: Provides data on response times for both normal and peak traffic volumes.
  • Objective Decision-Making: Ensures the designer is informed when selecting network technologies.
  • Proper Sizing: Allows for the accurate sizing of networks and their individual components.
• Strategic Goal Implementation:
  • Selection of technologies and services based on objective needs.
  • Ability to match interconnection strategies to the relevant network services.
  • Understanding exactly where and how to apply services within the network infrastructure.

Outputs of Requirement Analysis

• Requirement Specification: A series of worksheets that list all requirements gathered for the system design. These help map out requirements, determine dependencies, and apply reference levels to distinguish performance tiers.
• Application Map: A visual representation showing the location dependencies between applications. This document is a critical input used for Flow Analysis.

User Requirements

• User requirements represent the highest layer of the generic system model. They represent the general need for quick and reliable access and transfer of information.
• Key Characteristics:
  • Timeliness: The user's ability to access, transfer, or modify information within a tolerable time frame. This is often measured as end-to-end or round-trip delay.
  • Interactivity: The response time of the system when interacting with a human being. The primary measure is round-trip delay.
  • Reliability: Availability from the user's perspective. It requires a mix of performance characteristics, reliability, delay, and capacity.
  • Quality: The user's perception of presentation, including audio, video, data display, menu responsiveness, and intuitiveness.
  • Adaptability: The system's ability to change to match changing needs (e.g., mobility, distance-independence, constraint-free computing).
  • Security: The guarantee of the integrity (accuracy and authenticity) of information and physical resources.
  • Affordability: An essential non-technical requirement. The network must deliver cost-effective solutions that the user can afford to purchase.
• Translation: User requirements are translated into performance requirements for the Host and Network, specifically into:
  • Reliability
  • Capacity
  • Delay

Historical Context and Growth of Requirements

• Early Internet: Historically, only basic connectivity and data transfer between hosts were required. There were no strict delay requirements.
• Private Networks: These were often engineered for strict requirements, usually by sacrificing load (providing excess capacity) or interoperability.
• Modern Requirements: Nowadays, there is a heavy emphasis on both User Requirements (timeliness, interactivity, etc.) and Performance Requirements (reliability, capacity, delay).
• Real-Time Definition: Often used to describe the need for strict delay tolerance. In a vague sense, it means "as fast as possible."

Application Requirements and Delay Types

• The Application component serves as the interface to the User and Host components, mapping user and performance requirements to the software level.
• Performance Requirement Metrics:
  • Delay: The time difference in the transfer and processing of information. Sources include propagation, transmission, queuing, processing, and routing. Total delay optimization is more important than focusing on individual sources.
  • Reliability: The system's ability to provide deterministic and accurate delivery. Low reliability leads to loss of revenue, unrecoverable information (telemetry), or loss of life (healthcare monitoring).
  • Capacity: Applications like voice or non-buffered video (controlled rate applications) require stable capacity guarantees (minimum, peak, or sustained capacity).
• Application Service Characteristics:
  • Mission Critical: Requires specified/high reliability (e.g., banking systems, airline reservations, healthcare monitoring).
  • Controlled Rate: Requires specified minimum capacity (e.g., non-buffered video, tele-services).
  • Real-Time (Interactive): Requires specified delay (e.g., $FTP$, web applications, email).
• Delay Categorization:
  • Real-Time: Strictest timing requirements; information is worthless if it arrives late. The destination does not wait (e.g., video stream).
  • Non-Real Time: Destination will wait within reason based on timeouts.
    • Interactive: Assumes a timing relationship while active; "as fast as possible" (e.g., $Telnet$, $FTP$, Client-Server).
    • Asynchronous: Time-insensitive; no timing relationship or timing is outside the session bounds (e.g., email, batch jobs).
  • Burst versus Bulk:
    • Burst: Frequent and quick interaction with the user.
    • Bulk: User provides substantial time for the application to process large amounts of information.

Typical Application Groups

1. Command and Control / Telemetry: Data links remote entities (e.g., spacecraft, sensors). Requires high performance in delay and reliability.
2. Visualization: $2D$ and $3D$ visualization, virtual reality. Requires high capacity and low delay.
3. Distributed Computing: Using many networked computers (from $LAN$ to $WAN$) for tasks. Performance depends on the task granularity.
4. Web Access, Development, and Use: Remote host and info retrieval. Delay sensitive but generally not considered "high performance."
5. Bulk Data Transport: Large data amounts with limited interactivity (e.g., $FTP$).
6. Tele*Service: Simultaneous audio/video/data (e.g., telemedicine, teleconferencing). Performance is application-dependent.
7. Operations, Administration, and Management (OAM): Network monitoring, $DNS$, $SMTP$. Generally requires high reliability.

Host Requirements

• Host Types:
  • Generic Computing Devices: $PCs$, $Macs$, $UNIX$ Workstations.
  • Servers: Provide services to one or more clients.
  • Specialized Equipment: Location-dependent; varies from rendering devices to wind tunnels or hyperbaric chambers.
• Performance Characteristics: Measured via storage performance (seek times), $CPU$ performance, memory access times, bus capacity (arbitration mechanisms), and $OS$/device driver performance.
• Location Information: Helps determine relationships between Users, Applications, and Networks; essential for determining flow characteristics and requirements for outsourcing.

Network Requirements

• Existing Network: Requirements of current users, apps, and hosts must be captured, including location, interoperability, traffic patterns, and network layer services (addressing/naming).
• Future / Migration: Must consider scaling, interoperability at boundaries, and identifying constraints on the new design based on existing infrastructure.

Functional Requirements

• Network Management: Tasks include monitoring for event notification, monitoring for metrics and planning, network configuration, and troubleshooting.
  • Monitoring Methods: Instrumentation via protocols ($SNMP$, $SNMPv2$, $CMIP$, $CMOT$), end-to-end tools ($Ping$, $Tracert$, $Tcpdump$), and direct access ($Telnet$, $FTP$, Console).
  • Sets of Characteristics: Monitoring can be In-band vs. Out-of-Band and Centralized vs. Distributed.
• Security: Requirements may be Government-specified ($DOD$, $DOE$), Company-specified, or User-specified.
• Financial: Level of funding available.
  • Non-Recurring Costs: Building the network, design, deployment, hardware/software, initial installation.
  • Recurring Costs: Tasks and items replaced on a periodic basis.
• Enterprise: Integration with common infrastructure (phone, fax, voice, video) on common coaxial-based hardware.

Requirement Analysis Templates

• User Requirements Template: Includes location, number of users, expected growth (after $1$, $2$, or $3$ years), and expectations for timeliness, interactivity, and security.
• Application Requirements Template: Categorizes applications (Mission-critical, Controlled-rate, Real-time, Best-effort) and maps their locations.
• Host Requirements Template: Describes the type of host, performance specs (disk, $CPU$, $RAM$), and location/quantity data.
• Network Requirements Template: Documents existing network scaling, interoperability, performance issues, and layer/service support issues.
• Functional Requirements Template: Covers management (monitoring methods, in-band vs. out-band), security, and funding levels.