INFO 331 Computer Networking Technology II - PowerPoint PPT Presentation


PPT – INFO 331 Computer Networking Technology II PowerPoint presentation | free to view - id: 8f266-Y2E0Y


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation

INFO 331 Computer Networking Technology II


Computer Networking Technology II. Network Design Intro. Glenn Booker. INFO 331. Network Design ... Changes in technology or media at the interfaces between ... – PowerPoint PPT presentation

Number of Views:84
Avg rating:3.0/5.0
Slides: 133
Provided by: users3


Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: INFO 331 Computer Networking Technology II

INFO 331Computer Networking Technology II
  • Network Design Intro
  • Glenn Booker

Network Design
  • Through the Kurose text weve covered
  • The application, transport, network, link
  • Wireless and multimedia technologies
  • Security
  • Network management
  • Not bad!
  • So how does all this come together to help create
    a network?

Network Design
  • Ok, thats not a small question well just
    tickle the surface (not even scratch!)
  • Main resources for this section are
  • McCabe, James D. (2003). Network Analysis,
    Architecture Design (2nd Ed.). San Francisco
    Morgan Kaufmann Publishers. Chapters 1-5, 10
  • Teare, Diane. (2004). CCDA Self-Study Designing
    for Cisco Internetworking Solutions (DESGN).
    Indianapolis Cisco Press.

Network Design Objective
  • Ultimately, our network design must answer some
    pretty basic questions
  • What stuff do we get for the network?
  • How do we connect it all?
  • How do we have to configure it to work right?
  • Traditionally this meant mostly capacity planning
    having enough bandwidth to keep data moving
  • May be effective, but result in over engineering

Network Design Objective
  • And while some uses of the network will need a
    lot of bandwidth (multimedia), we may also need
    to address
  • Security
  • Considering both internal and external threats
  • Possible wireless connectivity
  • Reliability and/or availability
  • Like speed for a car, how much are you willing
    to afford?

Network Design Phases
  • Designing a network is typically broken into
    three sections
  • Determine requirements
  • Define the overall architecture
  • Choose technology and specific devices

(McCabe, 2003)
Systems Methodology
  • Theres lots of room for refining these sections
    (Teare, 2004)
  • Identify customer requirements
  • Characterize the existing network
  • Design topology
  • Plan the implementation
  • Build a pilot network
  • Document the design
  • Implement the design, and monitor its use

Two Main Principles
  • For a network design to work well, we need to
    balance between
  • Hierarchy how much network traffic flows
    connect in tiers of organization
  • Like tiers on an org chart, hierarchy provides
    separation and structure for the network
  • Interconnectivity offsets hierarchy by allowing
    connections between levels of the design, often
    to improve performance between them

Two Main Principles
(McCabe, 2003)
Plan Ahead!
  • The 80/20 rule applies here
  • 80 of the cost of a network is its operation
    and support
  • Only 20 is the cost of designing and
    implementing it
  • So plan for easy operation, maintenance, and
    upgrade of the network

Requirements? Booooring!
  • Yes, determining the requirements for a network
    probably isnt as much fun as shopping for really
    expensive hardware
  • And that may be why many networks are poorly
    designed no one bothered to think through
    their requirements!
  • Many people will jump to a specific technology or
    hardware solution, without fully considering
    other options the obvious solution may not be
    the best one

  • We need to develop the low level design and the
    higher level architecture, and understand the
    environment in which they operate
  • We also need to prove that the design weve
    chosen is just right (Southey, 1837)
  • Is that 2 million network backbone really enough
    to meet our needs?
  • How do we know 500,000 wouldnt have been good

  • Part of this process is managing the customers
  • They may expect a much simpler or more expensive
    solution than is really needed
  • Showing analysis of different design options,
    technologies, or architectures can help prove
    you have the best solution

  • We need to use a systems approach for
    understanding the network
  • The system goes far beyond the network hardware,
    software, etc.
  • Also includes understanding the users,
    applications or services, and external
  • How do these need to interact?
  • What does the rest of the organization expect
    from the network?

  • Consider how devices communicate

Images from (McCabe, 2003) unless noted otherwise
  • What services are expected from the network?
  • Typical performance levels might include
    capacity, delay time, reliability
  • Providing 1.5 Mb/s peak capacity to a remote user
  • Guaranteeing a maximum round-trip delay of 100 ms
    to servers in a server farm
  • Functions include security, accounting,
    scheduling, management
  • Defining a security or privacy level for a group
    of users or an organization

  • Service requirements could include the QoS
    (quality of service) guarantees (ATM, Intserv,
    Diffserv, etc.)
  • This connects to network management monitoring of
    network performance

  • Capacity refers to the ability to transfer data
  • Bandwidth is the theoretical capacity of some
    part of the network
  • Throughput is the actual capacity, which is less
    than the bandwidth, due to protocol overhead,
    network delays, etc.
  • Kind of like hard drive actual capacity is always
    less than advertised, due to formatting

Requirements Analysis
  • Given these concepts, how do we describe
    requirements for a network?
  • Need a process to filter or classify requirements
  • Network requirements (often have high, medium,
    low priorities)
  • Future requirements (planned upgrades)
  • Rejected requirements (remember for future ref.)
  • Informational requirements (ideas, not required)

Requirements Analysis
  • Requirements can come from many aspects of the
    network system
  • User Requirements
  • Application Requirements
  • Device Requirements
  • Network Requirements
  • Other Requirements

User Requirements
  • User requirements are often qualitative and very
    high level
  • What is fast enough for download? System
    response (RTT)?
  • How good does video need to be?
  • Whats my budget?

Application Requirements
  • What types of apps are we using?
  • Mission-critical
  • Rate-critical
  • Real-time and/or interactive
  • How sensitive are apps to RMA (reliability,
    maintainability, availability)?
  • What capacity is needed?
  • What delay time is acceptable?

Application Requirements
  • What groups of apps are being used?
  • Telemetry/command and control - remote devices
  • Visualization and simulation
  • Distributed computing
  • Web development, access, and use
  • Bulk data transport FTP
  • Teleservice VOIP, teleconference
  • Operations, admin, maintenance, and provisioning
  • Client-server ERP, SCM, CRM

Application Requirements
  • Where are the apps located?
  • Are some only used in certain locations?

Device Requirements
  • What kinds of devices are on your network?
  • Generic computing devices include normal PCs,
    Macs, laptops, handheld computers, workstations
  • Servers include all flavors of server file,
    print, app/computation, and backup
  • Specialized devices include extreme servers
    (supercomputers, massively parallel servers),
    data collection systems (POS terminals),
    industry-specific devices, networked devices
    (cameras, tools), stoplights, ATMs, etc.

Device Requirements
  • Specialized devices are often location-specific

Device Requirements
  • We want an understanding of the devices
    performance its ability to process data from
    the network
  • Device I/O rates
  • Delay time for performing a given app function

Device Requirements
  • Performance results from many factors
  • Storage performance, that is, flash, disk drive,
    or tape performance
  • Processor (CPU) performance
  • Memory performance (access times)
  • Bus performance (bus capacity and arbitration
  • OS performance (effectiveness of the protocol
    stack and APIs)
  • Device driver performance

Device Requirements
  • The device locations are also critical
  • Often generic devices can be grouped by their
  • Servers and specialized stuff are shown

Network Requirements
  • Network requirements (sounds kinda redundant) are
    the requirements for interacting with the
    existing network(s) and network management
  • Most networks have to integrate into an existing
    network, and plan for the future evolution of the

Network Requirements
  • Issues with network integration include
  • Scaling dependencies how will the size of the
    existing network affect the new one?
  • Will the existing network change structure, or
    just add on a new wing?
  • Location dependencies interaction between old
    and new networks could change the location of key
  • Performance constraints existing network could
    limit performance of the new one

Network Requirements
  • Network, system, and support service dependencies
  • Addressing, security, routing protocols and
    network management can all be affected by the
    existing network
  • Interoperability dependencies
  • Changes in technology or media at the interfaces
    between networks need to be accounted for, as
    well as QoS guarantees, if any
  • Network obsolescence do protocols or
    technologies become obsolete during transition?

Network Requirements
  • Network management and security issues need to be
    addressed throughout development
  • How will the network be monitored for events?
  • Monitoring for network performance?
  • What is the hierarchy for management data flow?
  • Network configuration?
  • Troubleshoot support?

Network Requirements
  • Security analysis can include the severity
    (effect) of an attack, and its probability of

Other Requirements
  • Requirements can come from other outside sources
    your customer, legal requirements, larger scale
    organization (enterprise) requirements, etc.
  • Additional requirements can include
  • Operational suitability how well can the
    customer configure and monitor the system?
  • Supportability how well can the customer
    maintain the system?

Other Requirements
  • Confidence what is the data loss rate when the
    system is running at its required throughput?
  • Financial requirements can include not only the
    initial system cost, but also ongoing maintenance
  • System architecture may be altered to remain
    within cost constraints
  • This is a good reason to present the customer
    with design choices, so they see the impact of
    cost versus performance

Other Requirements
  • Enterprise requirements typically include
    integration of your network with existing
    standards for voice, data, or other protocols

Requirements Spec and Map
  • A requirements specification is a document which
    summarizes the requirements for (here) a network
  • Often it becomes a contractual obligation, so
    assumptions, estimates, etc. should be carefully
    spelled out
  • Requirements are classified by Status, as noted
    earlier (core/current, future, rejected, or
    informational requirement)

Requirements Spec and Map
  • Priority can provide additional numeric
    distinction within a given Status (typically on
    a 1-3 or 1-5 scale)
  • Sources for Gathering requirements can be
    identified, or give basis for Deriving it
  • Type is user, app, device, network or other

Requirements Spec and Map
  • Requirements Mapping can show graphically where
    stuff is, what kind of apps are used, and
    existing connectivity

Requirements Analysis Process
  • So, how do we determine what the requirements are
    for our network?
  • Collect requirements service metrics, and delays
    to help develop and map requirements

Gather and List Requirements
  • A great starting point is the very beginning
  • What initial conditions are you facing?
  • What type of project is this?
  • New network, Modifying an existing network,
    Analysis of network problems, Outsourcing,
    Consolidation, Upgrade
  • What is the overall scope of the project?
  • Network size, Number of sites, Distance between

Initial Conditions
  • Why is the network being designed? What are the
    goals for its architecture design?
  • Upgrade technology and/or 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

Initial Conditions
  • What project constraints are there?
  • Funding, organizations involved, existing
    network, facility limitations, schedule,
    political, etc.
  • Are users receptive to the new network?
  • Are user needs homogeneous, or are there multiple
    tiers of performance needs?
  • The former is easier to handle, of course

Customer and User
  • Customer expectations need to be set quickly
  • What order of magnitude is the project, and does
    that match what they thought?
  • Better to find out early on if theres a big gap!
  • Working with users is important, to know how they
    use the network and what problems they find
  • Surveys, phone calls, personal meetings, and/or
    group discussions could be used

Customer and User
  • Look for red flags in early discussions
  • Abuse of the term "real-time"
  • Availability as solely a percentage (99.99)
  • "High performance" without verification or
  • Highly variable, inconsistent requirements
  • Unrealistic expectations from the customer
  • Measure application performance using existing
    network (if possible) or a test bed

Requirements Management
  • The requirements you develop need to be tracked
    and managed, just like any systems requirements
  • Identify requirements by some form of ID and
    short name
  • Need a tool to track requirements, their status,
    changes, sources, etc.
  • Map location of apps and devices of the existing

Service Metrics
  • Service metrics are characteristics measured or
    derived from the network
  • Metrics must be configurable, measurable, and
  • RMA metrics might include
  • Reliability mean time between failures (MTBFs)
    and mean time between mission critical failures
  • Maintainability mean time to repair (MTTR)
  • Availability MTBF, MTBCF, and MTTR

Service Metrics
  • Related RMA metrics include
  • Uptime and downtime (percentage 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
  • Service metrics for capacity include
  • Data rates peak data rate, sustained data rate,
    and minimum data rate
  • Data sizes burst sizes and durations

Service Metrics
  • Service metrics for delay include
  • End-to-end or round-trip delay
  • Latency
  • Delay variation
  • SNMP or CMIP (Common Management Information
    Protocol) can be used to configure these metrics,
    which are kept in the Management Information
    Base (MIB)

Service Metrics
  • MIB Variables often used as service metrics
  • Bytes in/out (per interface)
  • IP packets in/out (per interface)
  • Dropped ICMP messages per time per interface
  • Service-level agreement (SLA) metrics (per user)
  • Capacity limit
  • Burst tolerance
  • Delay
  • Downtime

Metrics Tools
  • Tools for making service metric measurements
  • Ping, pathchar, traceroute, TCPdump
  • Packet capture utilities Ethereal, Sniffer, and
  • Then summarize the metrics collection approach

Characterizing Behavior
  • Next we can analyze how users and apps use the
    existing network
  • We could use simulations or models to assess
    network behavior
  • Thats way beyond the scope here!
  • User behavior is looking for patterns in how
    people use apps
  • How many users, how frequently, how long per
    session, how much data they use

Characterizing Behavior
  • Application behavior includes looking at how each
    app uses the network
  • Communication between client/server parts
  • Multicast or broadcast transmissions how often,
    how big
  • Focus on the most critical apps (mission
    critical, real time, interactive, etc.)
  • Models can be simple or complex, as project size
    and time constraints dictate

RMA Requirements
  • Reliability is a common measurement
  • Mean time between mission critical failure
    (MTBCF) focuses on failures during certain time
    periods, excluding planned down times
  • Mean time between failure (MTBF) includes failure
    at any time
  • Maintainability is typically captured with mean
    time to repair (MTTR)

RMA Requirements
  • Availability relates failures to repair time
  • Scheduled maintenance time doesnt count against
  • Uptime and downtime measure those percentages
    when the system is up or down
  • The upper practical limit is 99.999 uptime,
    which is 5.3 minutes of downtime per year
  • Uptime of 99.99 is fairly common
  • How many events occur is also important

RMA Requirements
  • Thresholds and limits can be defined for RMA
  • MTBF is typically a couple thousand hours
  • MTTR may be a few hours
  • Different parts of the system may have different

Delay Requirements
  • Various delays can have a strong impact on
    network requirements
  • Interaction delay (INTD) is how long a user will
    wait for a response from the system
  • Human response time (HRT) is when a system delay
    becomes noticable to a user
  • Network propagation delay is how long it takes
    for a command to cross the network and get the

Delay Requirements
  • INTD and HRT help distinguish burst from bulk apps

Delay Requirements
  • End-to-end and round-trip delays can be network
  • Weve used ping to get RTT (round trip time)
  • Delay variation can be defined for multimedia
    apps typically is 1-2 of end-to-end delay

Capacity Requirements
  • Much of the needed capacity of a network derives
    from key applications that are especially intense
    in such areas
  • Peak data rate
  • Minimum acceptable data rate
  • Sustained (long term) data rate
  • We need to distinguish apps that CAN use a lot of
    capacity (if its available), versus those that
    MUST use a lot

Data Rates
  • Data rates for an app can be measured at many
    levels of the protocols
  • App, network, etc.
  • Most TCP apps will take whats available, but
    back off when the network gets crowded (why?)
  • Often we may need to identify where the
    performance bottleneck is located
  • It helps to get a rough idea of typical app

Typical App Capacity Needs
Data Rates
  • Sometimes a range of values is more helpful
  • Processing credit card info might take 5-10
    seconds, and require 100-1000 bytes of data
  • Multimedia rates are well known, and depend on
    the protocol and level of compression and quality
  • Low- and high-performance realms are completely
    subjective there are no industry or generic
    numbers to set them apart

Supplemental Performance
  • Other non-functional requirements can be
    important to a network
  • Operational Suitability is making sure your
    customer can operate the network once its
  • How often are manual network adjustments needed?
  • How often does network configuration change?
  • How much monitoring is automated?

Operational Suitability
  • How many shifts of operators will there be?
  • How well trained are the network operators?
  • How often will hardware changes be needed?
  • What hardware can the operators change?
  • What level of component is an operator expected
    to be able to change? Chip, board, rack unit,
    entire rack? (Line-Replaceable Unit, LRU)
  • All of this can result in a Concept of Operations

  • Can the networks level of performance be
    sustained over time?
  • Is affected by
  • RMA of the architecture and design
  • Workforce, including training and staffing levels
  • System procedures and technical documentation
  • Tools, both ordinary and special
  • Spare and repair parts

  • Maintenance of a system expects
  • Components are located where they can be
    maintained without affecting the rest of the
    system much
  • Spare parts are supplied to allow replacement of
    failed and soon-failed components
  • Reliability can be formally modeled with
    reliability block diagrams (RBDs) or failure mode
    and effect analysis (FMECA)

  • Workforce should be equivalent to the ones being
    replaced or at least as cheap overall
  • Documentation typically includes
  • Technical documentation of the system
    configuration, design, parts, etc.
  • Maintenance procedures describe routine actions
  • Casualty or corrective procedures describe how
    to troubleshoot, debug, or otherwise fix basic

  • Tools and test equipment describe what tools are
    needed to maintain the system
  • How are faults detected?
  • How is performance being monitored?
  • What capabilities will be available to remotely
    diagnose, reconfigure, or reset components?
  • Stuff breaks and wears out, so spare parts are
    needed to improve availability
  • How much are you will to invest in parts?

  • All of this produces a concept for support of a
  • Important to state assumptions about the
    knowledge, skills, and availability of support
  • Spares are an ongoing investment the customer
    needs to be aware of their cost
  • Often results in at least three tiers of support
    (onsite, central maintenance, and vendor)

  • Confidence is the ability of a network to provide
    throughput at an acceptable error or loss rate
  • Often thought of at the device or link level,
    but can also be considered end-to-end
  • Measure by percent of traffic lost during a given
    time period (e.g. 2 loss up to 1 min)
  • Ping might be used to measure losses

Environment-specific Limits
  • What constitutes acceptable performance depends
    wildly on the industry or particular environment
    of the network
  • High-performance devices often drive the
    acceptable thresholds or limits
  • Also consider if predictable or guaranteed
    performance is important
  • May lead to high QoS requirements, since best
    effort may not be good enough

Map and Spec
  • Then, as mentioned earlier, map out the
    requirements, and write them in a specification
  • Make sure you and your customer are in agreement
    on the needs of the network
  • Prioritize requirements, so if something has to
    give, its not critical to your customer

Flow Analysis
  • The requirements map is a great place to start
    analysis of flows in your network
  • We dont want to model EVERY traffic (data) flow,
    just the important ones
  • A traffic flow describes data movement, e.g.
  • Source and/or destination addresses
  • Type of information
  • Directionality (bidirectional or unidirectional)
  • Other aspects, such as QoS needs

Flow Analysis
  • Later, flows can be broken down into subnet or
    link level flows
  • A key purpose of flow analysis is to understand
    the balance between hierarchy and
    interconnectivity needed

Flow Analysis
  • Flows can be individual, or grouped into
  • Flows can be critical (and often drive
    architecture and design)

Flow Analysis
  • The requirements spec should be able to define
    flows by user, app, device, network
  • Looks for important flows by application,
    location, user type, device, type of function
    (multimedia, mission critical)
  • Define capacity (Kbps or Mbps), delay
    requirements (ms), reliability requirement ()
  • Map flows geographically

Flow Analysis
Consolidate Flows
Data Sources and Sinks
  • Look for devices (servers, special devices) which
    generate lots of data (sources) or take in a lot
    of data (sinks)
  • Consider also WHEN the flows occur are there
    specific times that are critical?
  • Consider worst-case and normal-usage scenarios

Flow Models
  • Model the flows using common examples
  • Peer-to-peer
  • Client-server
  • Hierarchical client-server
  • Distributed computing
  • These models differ in directionality (or lack
    thereof), hierarchy, and interconnectivity

Peer-to-Peer Flow Model
  • All users or apps are equal
  • Flows are all critical or none are
  • Flows are all equivalent (have same specification)

Client-Server Flow Model
  • Requests are small data amounts compared to
    responses, so these flows are asymmetric toward
    the clients
  • ERP, video editing, and web apps often follow
    this model

Hierarchical Client-Server
Distributed Computing
  • Behavior varies inverse client-server,
    peer-to-peer, hybrid, etc.

Flow Prioritization
  • Flows are typically prioritized based on many
    factors, only a couple of which are technical
  • Capacity, delay, RMA, and/or QoS requirements
  • Security requirements
  • Number of users or apps affected by each flow
  • Business or political objectives, and the impact
    of the flow on the customers business
  • Who pays for it!

Flow Specification
  • Like the requirements, the flows can be
    summarized in a specification of some kind
  • Critical for identifying priorities, in case
    everyone cant be happy with your design
  • Balancing flow requirements can be done with a
    flowspec algorithm
  • Best effort algorithms only consider capacity
  • Predictable flow reqts consider capacity, delay,
    and RMA
  • Guaranteed flow reqts are treated separately

Network Architecture
  • Now that we FINALLY have requirements and flows
    defined, we can consider how all this will affect
    the architecture of our network
  • The architecture of a house needs many views to
    understand not only the exterior appearance, but
    also where the wires run, where the pipes are,
    ductwork for heating and cooling, etc.
  • Similarly, we need several views of a network

Network Architecture
  • Avoid thinking of just the physical components of
    a network (routers, hubs, etc.)
  • Think of the functions its performing
    (addressing, routing, security, network
    management, performance) as an integral part of
    the components
  • E.g. routing or switching can be affected by
  • So think of functional entities, not just HW

Network Architecture
  • Measure network success by how well user, app,
    and device reqts are met functionally
  • Also connects easier to traffic flows
  • And scales well to large networks
  • Each function will be defined by a component
    architecture combine them to get the overall
    reference architecture
  • See house analogy a couple slides back

Network Architecture
  • The design of a network is more detailed,
    technology- and location-specific description
    than its architecture
  • Component architectures describe the hardware and
    software mechanisms needed to make a type of
    function work
  • Each component is sort of a subsystem so well
    need to understand how they work together

Network Functions
  • The key functions are
  • Addressing and routing
  • Network management
  • Performance
  • Security
  • Functions may also include storage and
    infrastructure, but well focus on other ones
  • Making this work may require trade-offs!

Basic Design Rules Regions
  • Divide the network into regions, based on similar
    traffic flows
  • Edges (access regions) are where flows start or
  • Distribution regions are where flows collect and
    terminate (app or storage servers)
  • Core (backbone) regions let collections of flows
    pass through
  • External interfaces (DMZs) collect flows leaving
    or entering the network from outside

  • Addressing applies MAC or IP addresses for
  • Routing establishes connectivity within and
    between networks
  • This component architecture defines how user and
    management flows are forwarded, and how hierarchy
    interconnectivity are balanced in subnets

  • Mechanisms for this architecture could be
  • Addressing subnetting, supernetting, dynamic vs
    private addressing, VLANs, IP v4 versus v6, NAT
  • Routing CIDR, mobile IP, multicast, and various
    routing protocols (BGP, RIP, etc.), establish
    routing policies
  • Notice at the architecture level were just
    choosing the types of mechanisms, not deciding
    exact structures

Network Management Arch.
  • This decides how the network will be monitored
    and managed
  • Types of mechanisms include
  • Monitoring, instrumentation, configuration,
    security management components, does mgmt data
    flow in band or out?, how centralized is mgmt?,
    mgmt capacity needs, duplicate mgmt mechanisms,
    MIB selection

Performance Architecture
  • This component defines how network performance
    will be established and managed
  • Defines how network resources are allocated to
    users, apps, and devices
  • Capacity planning, traffic engineering, QoS,
    access control, SLAs, policies, resource mgmt
  • Balances end-to-end vs per-link prioritization
  • DiffServ vs IntServ

Security Architecture
  • How do you protect system resources and data from
    theft, damage, DoS, and unauthorized access?
  • VPN, encryption, firewalls, routing filters, NAT
  • Threat analysis, physical vs app security
  • Define security zones (cells) for different
    levels of security
  • Affects how other architectural components can
    interact with each other

Reference Architecture
  • All these components need to be reconciled with
    each other
  • Can add key reqts and chosen mechanisms to flow
  • Prioritize mechanisms and how they interact
  • The Reference Architecture is the collection of
    all the component architectures

Reference Architecture
  • Reqts dictate which components are favored, if

Architectural Models
  • Models for network architecture can be based on
    topology, flow, or functionality
  • Generally more than one model is needed
  • Often start with topology model and add other(s)
  • Topology models are mainly
  • The WAN/MAN/LAN model basic hierarchical
  • The core/distribution/access model think of
    getting videos from CNN

Topology Models
Flow Models
  • Weve already seen these (slides 84-87)
  • Peer-to-peer
  • Client-server
  • Hierarchical client-server
  • Distributed-computing

Functionality Models
  • These models focus on supporting key functions in
    the network
  • Service-provider like an ISP
  • Intranet/Extranet focus on security and privacy
  • Single-tier/Multi-tier Performance where flows
    indicate different levels of performance needs
  • End-to-end Models where a single flow is
    critical to understand and fulfill
  • These all require knowing location data

Functionality Models
  • Service provider and intranet/ extranet models

Functionality Models
  • No cartoon for single- or multi-tier model could
    be a combination of the others
  • End-to-end model

Applying Models
  • The flow and functional models overlap in focus
    with the core/distribution/access model

System Architecture
  • The network (reference) architecture connects to
    the rest of the organization
  • Related components and functions may include
    storage, clients and servers, databases, etc.
  • How much detail outside of networking you include
    is up to the context of your problem

Selecting Technologies
  • After the types of mechanisms in the reference
    architecture have been selected, we can start
    choosing more specific design technologies for
    our network
  • This is where most people start network design
  • Technologies need to be consistent with the goals
    of the network
  • What is most important cost, capacity, QoS,
    security, manageability?

Selecting Technologies
  • The goals may be different in different parts of
    the network
  • Consider having a primary goal and one or more
    secondary goals
  • Consider graphs to show tradeoffs
  • Based on the flow requirements, how do you
    evaluate candidate technologies?
  • RMA, capacity, cost, performance, supportability,
    etc. can be your basis for judging technologies

Selecting Technologies
  • Consider a car-buying analogy if youre buying a
    car, you might consider many characteristics to
    make your choice
  • Cost, performance, appearance, safety, comfort,
    load capacity, handling, reputation, reliability,
  • Here we look to the flowspec and reference
    architecture for the relative importance of each
    desirable characteristic

Selecting Technologies
  • Consider also design and configuration issues for
    technology, not just price-vs-performance
  • For example, many older technologies have
    built-in ARP capability
  • Ethernet, Token Ring, and FDDI all do this
  • But newer non-broadcast multiple access (NBMA)
    technologies dont have this
  • ATM, frame relay, SMDS, HiPPI

Selecting Technologies
  • As a result, using NBMA technologies requires
    separate support for broadcast and multicast
  • Also consider how autonomous systems (ASs) are
    being formed and managed
  • What kinds of connections are maintained in the
  • Stateless, hard state, or soft state
  • Connections require more work from the network

Technology Functions
  • What features and functions will each technology
    offer to users, apps, and devices?
  • Does it depend on the local infrastructure?
  • Are flows asymmetric, like Web access?
  • HFC and DSL both take advantage of this
  • Are there distance limitations?
  • Affects delay time, buffering, reliability needs,
    and HW

Performance Upgrades
  • How easily can your design be upgraded?
  • Generally focus on capacity, but delay and RMA
    may be affected too
  • For examples, SONET optical carrier (OC) levels
    can be easily upped in capacity for ATM or HiPPI
  • SONET Level Rate
  • OC-3 155.52 Mb/s
  • OC-12 622 Mb/s
  • OC-48 2.488 Gb/s
  • OC-192 9.953 Gb/s
  • OC-768 39.812 Gb/s

Performance Upgrades
Flow Considerations
  • The flow spec should help tell which flows have
    similar requirements, and which need special
    consideration for performance, capacity, or other
  • Find backbone flows, which collect smaller flows
  • Capacity planning is based on estimating usage,
    to compare against available technologies
  • Service planning also compares levels of service

Guidelines for Tech Eval
  • Use combined capacities for best-effort flows
    (generic Internet), and RMA, capacity, and/or
    delay requirements for predictable or guaranteed
  • Guideline 1 If predictable and/or guaranteed
    requirements are listed in the flow specification
    (service plan), then either the technology or a
    combination of technology and supporting
    protocols or mechanisms must support these
    requirements. This guideline restricts the
    selection of candidate technologies to those that
    can support predictable and/or guaranteed

Guidelines for Tech Eval
  • For examples which are technology-dependent, for
    predictable service
  • Quality-of-service levels in ATM
  • Committed information rate levels in frame relay
  • Differentiated service or integrated service
    levels in IP
  • Guaranteed service gets even messier!

Guidelines for Tech Eval
  • Guideline 2 When best-effort, predictable,
    and/or guaranteed capacities are listed in the
    flow specification, the selection of technology
    may also be based on capacity planning for each
    flow. Capacity planning uses the combined
    capacities from the flow specification to select
    candidate technologies, comparing the scalability
    of each technology to capacity and growth
    expectations for the network.

Guidelines for Tech Eval
  • Specific flows in the flow spec can be mapped to
    the best technology solution
  • Constraints in terms of RMA, delay, cost or QoS
    can be used to eliminate technologies
  • Interaction with existing networks needs to be
    checked for possible conflicts
  • Facility or other large scale issues may need to
    be addressed too

Segmenting the Network
  • Now that we have nailed down technology choices,
    we can address the detailed structure of the
    network how its segmented
  • Segmenting focuses technology selection
  • We could do it by geography, groups of users
    (even virtual), or flow hierarchy
  • Groups of users could belong to different
    organizations would that be a problem for
    security or privacy?

Segmenting the Network
  • A geographic example of segmenting

Segmenting the Network
  • A user-based view of segmenting

Segmenting the Network
  • A flow hierarchy-based example

Segmenting the Network
  • Segments can include defining broadcast domains,
    collision domains, or the scope of autonomous
    systems (ASs)
  • Really large networks can be segmented by the
    type of functions and features involved in each
    segment (WAN, MAN, LAN, specialized equipment
    areas, core business areas, etc.)

Segmenting the Network
  • Segmenting by types of function and feature

Black Box Method
  • Once segments have been defined, we can view each
    segment as black box(es)
  • Know inputs and outputs, and dont worry about
    the inner details yet
  • A segment could have several black boxes

Black Box Method
  • Then for each black box, determine the exact
    technology needs within it
  • This lets us hide irrelevant information, and
    focus our technology decisions on critical info
  • Naturally we dont want to have all technology
    decisions made in a vacuum, or wildly different
    or incompatible technologies may be chosen
  • Common sense should prevail!

  • Network design needs to understand and balance
    requirements from network users, applications,
    devices, and the external environment
  • Flow analysis helps capture capacity, delay, QoS,
    reliability, and other critical aspects
  • Then technology choices can be made based on
    segmenting the network by geography, user, flow
    spec, or functions provided