Network Analysis and Design: Requirement Analysis Guidelines

Components of the Network Analysis and Design (NAD) Process

• Systems and Network Services

  • Service characterization.

• A Systems Approach to Network Design

  • Understanding and identifying requirements for Users, Applications, Hosts, and Networks.

  • Gathering requirements, determining service metrics, and assessing performance.

• Requirement Analysis

  • Characterizing behavior.

  • Setting performance thresholds and levels.

• Flow Analysis

  • Identifying data sources and sinks.

  • Analyzing flow models, boundaries, distribution, and specifications.

• Logical Design

  • Technology choice.

  • Interconnection mechanisms.

  • Network management and security.

• Physical Design

  • Cable plant design options.

  • Network equipment placement.

• Addressing and Routing

  • Producing network diagrams and diagramming worksheets.

  • Establishing routing flow.

  • Developing addressing and routing strategies.

The Process Model for Requirement Analysis

• Step 1: Gather Requirements

  • Develop an Applications Map.

  • Establish Flow Boundaries.

• Step 2: Develop Service Metrics

  • Identify Network Management Variables.

  • Integrate Network Management and Security into the design.

• Step 3: Characterizing Behavior

  • Identify User/Application Performance Modifiers.

  • Make Technology Choices for the design.

• Step 4: Develop Performance Thresholds

• Step 5: Distinguishing between Service Requirements

  • Identify Application Types and Groups.

  • Utilize guidelines to distinguish services.

Step 1: Gather Requirements - Initial Conditions and Scope

• Determining Initial Conditions

  • The Type of Design Project: Is it a new network design, a modification/upgrading of an existing network, an analysis of a current design, or a network designed specifically to allow outsourcing of Network Operation, Administration, and Maintenance (OAM)?

  • The Scope of the Design: Defined by size, distance, and the number of sites and their respective locations.

  • Other Influences: Includes design goals, political influences, funding limitations, and organizational constraints.

• Business-Related Information Preparation

  • Before meeting with clients, collect information on: products produced, services supplied, financial viability, customers, suppliers, competitors, and competitive advantages.

• Determining Scope Specifics

  • Small Scope Example: Allowing sales people to access a network via a Virtual Private Network (VPN).

  • Large Scope Example: An entire redesign of an enterprise network.

  • Information to learn: Number of sites to be added, needs at each site, number of users to be added, and number of servers to be added.

Step 1: Gather Requirements - Security and Organizational Structure

• Security Policy Integration

  • Obtain a copy of the existing security policy.

  • Analyze how the policy affects the new design and vice versa.

  • Evaluate if the policy is too strict to allow the network designer to function effectively.

  • Cataloging Network Assets: Identify assets that security should protect, including hardware, software, applications, data, intellectual property, trade secrets, and company reputation.

• Working with Users

  • Relationship Management: Understand that customers may not always be cooperative or know exactly what they want. Building a relationship is essential.

  • Organization Chart: Obtain a copy to understand the general organization structure, which suggests specific users and geographical locations to account for.

  • Project Goals: Get a concise statement on the problem to be solved, how technology will help business success, and what defines project success.

  • Discover Biases: Identify if the client prefers certain companies/products, avoids specific technologies, or if there is friction between departments (e.g., data vs. voice teams).

• Listing and Mapping Requirements

  • Create tables for User, Application, Host, Network, and Functional requirements.

  • Develop Applications Map: Based on Application Requirements, create a map showing where specific applications are expected to be used.

  • Application Focus: Determine the behavior of applications on the network, focusing specifically on Layer 7 (Application Layer).

Step 2: Developing Service Metrics

• The Role of Service Metrics

  • Essential when system elements are outside the control of the administrator (e.g., service providers or outsourcing agents) to ensure contract compliance.

  • Metrics should be decided at the beginning and vary based on environment and equipment.

  • Metrics are actual measurable variables or derived from them (Configurable, Measurable, Verifiable).

• Reliability Metrics

  • Availability: Expressed as percent uptime ($$ uptime) or downtime.

  • Recoverability or Stability:

    • $MTBF$ (Mean Time Between Failure).

    • $MTBSO$ (Mean Time Between Service Outage).

    • $MTTR$ (Mean Time To Repair).

  • Error and Loss Rates:

    • $BER$ (Bit Error Rate).

    • $CLR$ (Cell Loss Ratio).

    • $CMR$ (Cell Misinsertion Ratio).

    • Frame and Packet Loss Rates.

• Capacity Metrics

  • Data Rates:

    • $PDR$ (Peak Data Rate - best case).

    • $SDR$ (Sustained Data Rate - typical).

    • $MDR$ (Minimum Data Rate - worst case).

  • Data Size: Includes burst size and duration.

• Delay Metrics

  • Delay Types: End-to-End, Round Trip, System Delay, Latency.

  • Delay Variation: Also known as jitter.

  • Timeliness.

Step 2: Specifics of Reliability and Availability

• Availability Calculations

  • Can be expressed as a percentage over various periods (year, month, week, day, hour).

  • Example: A network up for $165$ hours in a $168$-hour week has an availability of $\frac{165}{168} \times 100 = 98.21\%$.

  • "Five Nines" availability refers to $99.999\%$.

• Availability Downtime Table

  • $99.70\%$:: $1577$ min/year, $30$ min/week, $4.32$ min/day, $0.18$ min/hour.

  • $99.90\%$:: $526$ min/year, $10$ min/week, $1.44$ min/day, $0.06$ min/hour.

  • $99.95\%$:: $263$ min/year, $5$ min/week, $0.72$ min/day, $0.03$ min/hour.

  • $99.98\%$:: $105$ min/year, $2$ min/week, $0.29$ min/day, $0.012$ min/hour.

  • $99.999\%$:: $5$ min/year, $0.10$ min/week, $0.01$ min/day, $0.0006$ min/hour.

• Formula for Availability:

  • $Availability = \frac{MTBF}{MTBF + MTTR}$

  • Example: If $MTBF = 4000\,\text{hours}$ and $MTTR = 1\,\text{hour}$, then $Availability = \frac{4000}{4001} = 99.98\%$.

Step 2: Specifics of Capacity, Efficiency, and Delay

• Capacity vs. Throughput

  • Bandwidth: The data carrying capacity of a circuit (bits per second).

  • Throughput: The quantity of error-free data transmitted per unit of time (bps, Bps, or pps).

  • Goodput: Application-layer throughput of user bytes (ignoring protocol headers).

• Efficiency

  • How much overhead is required to deliver data.

  • Large frames are more efficient but risk higher data loss if damaged.

• Delay - User Perspective

  • Response Time: Function of the application and equipment. Users expect visual response and interaction within $100\,\text{ms}$ to $200\,\text{ms}$.

• Delay - Engineer Perspective

  • Propagation Delay: Signals travel at roughly $\frac{2}{3} c$ (speed of light) in cable.

  • Transmission Delay (Serialization Delay): Time to put data on the line. (e.g., $1024\,\text{byte}$ packet on a $1.544\,\text{Mbps}$ T1 line takes about $5\,\text{ms}$).

  • Packet-switching and Queuing Delay.

• Queuing Delay Formula and Example

  • Number of packets in a queue increases exponentially as utilization increases.

  • Example Calculation:

    • $5$ users, each offering $10\,\text{packets/sec}$.

    • Packet length = $1024\,\text{bits}$.

    • WAN circuit = $56\,\text{Kbps}$.

    • $\text{Load} = 5 \times 10 \times 1024 = 51,200\,\text{bps}$.

    • $\text{Utilization} = \frac{51,200}{56,000} = 91.4\%$.

    • $\text{Avg. Packets in Queue} = \frac{0.914}{1 - 0.914} = 10.63\,\text{packets}$.

• Delay Variation (Jitter)

  • Variation in average delay. Voice/Video are intolerant of jitter.

  • Heuristic for jitter: $1\%$ to $2\%$ of end-to-end delay.

Step 3: Characterizing Behavior

• Usage Pattern Estimation

  • $A_i$: Application usage.

  • $N_i$: Total number of users.

  • $f_i$: Frequency of usage (sessions/user day).

  • $D_i$: Duration/Length of average session.

  • $n_i$: Number of simultaneous user sessions.

  • Usage Estimate: $A_i \approx n_i \times f_i \times D_i\,\text{seconds per day}$.

• Application Behavior Factors

  • Data sizes processed.

  • Frequency and time duration of network passes.

  • Traffic flow characteristics (directions: client to server, vice versa).

  • Degree of multicasting (one-to-one, one-to-many, many-to-many).

• Characterizing Existing Internetwork

  • Infrastructure/Structure: Modularity, hierarchy, topology, physical structure, addressing, wiring.

  • Health: Performance, availability, bandwidth utilization, accuracy, efficiency, response time, and status of major devices (routers, switches, firewalls).

• Management Tools

  • Protocols: SNMP (Simple Network Management Protocol) and CMIP (Common Management Information Protocol).

  • MIBS: Management Information Bases (generic and enterprise-specific variables like RMON/RMON 2 and AToM).

  • Common Tools: Ping (round trip delay/packet loss) and Pathchar (extended ping for round trip delay and per-link capacity).

Step 4: Develop Performance Thresholds

• Threshold Criteria

  • General vs. Environment-Specific Thresholds.

  • Used to distinguish between best-effort, specified, and low/high performance services.

• Service Category Definitions

  • Best-Effort: No guarantees on speed or delivery. Treated equally (e.g., standard web/email). Analogy: Regular postal mail.

  • Specified: Guaranteed performance (min bandwidth, max delay). Prioritized traffic (e.g., VoIP). Analogy: Express courier.

  • Low/High Performance: Refers to quality of service. High-performance has dedicated resources and low latency (e.g., financial transactions). Analogy: Regular lane vs. express toll road.

• Determining Reliability Thresholds

  • General Threshold: $99.9\%$.

  • Lower than $99.9\% = \text{LOW Performance}$.

  • Higher than $99.9\% = \text{HIGH Performance}$.

  • Operational levels: $95\%$ (test systems only), $99.95\%$ (typical), $99.98\%$ (mission-critical), $99.99\%$ (state-of-the-art mission-critical).

• Recoverability Metrics:

  • $MTBF$/$MTBSO$: Frequency of failure.

  • $MTTR$: Duration of loss of function.

Delay Requirements and Thresholds

• Interaction Delay (INTD): Time a user is willing to wait during an interactive session. Typical range: $10$ to $30\,\text{seconds}$.

• Human Response Time (HRT): Perception boundary of delay. Threshold is approx $100\,\text{ms}$. Below this, users do not notice delay.

• Network Propagation Delay (NPD): Signal speed limit (lower bound to interactivity).

• Responsiveness Metrics

  • $RTT$ (Round Trip Time): Measured via ping.

  • $TCT$ (Task Completion Time): Time to perform work between user interactions.

  • Heuristic Equations:

    • $\text{System Responsiveness} = \frac{HRT}{TCT}$ when $\frac{HRT}{RTT} \ge 1$

    • $\text{System Responsiveness} = \frac{HRT}{RTT \times TCT}$ when \frac{HRT}{RTT} < 1

  • Example: $RTT = 100\,\text{ms}$, $TCT = 10\,\text{s}$, $HRT = 100\,\text{ms}$. Result is $10$ (Interactive-Burst). Values < 3 are Interactive-Bulk.

• Burstiness: $\frac{PDR}{SDR}$. Minimum value is $1$.

Step 5: Distinguishing Between Service Requirements

• Identification Guidelines

  1. Identify applications with obvious specified service requirements.

  2. Identify Type Applications: Mission-critical, real-time, or controlled rate access.

  3. Group applications by type.

• Specified Services Details

  • Deterministic Services: Use boundaries to approximate high/low performance for capacity planning.

  • Guaranteed Services: Enforcement mechanisms ensure performance characteristics are met.

• Final Result: A listing of application types and services used to create a Performance Envelope. Those not identified in early steps are likely "Best Effort."