Diseño Redes

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

Diseño de red
 Hemos visto
 transport, network, & link layers
 Not bad!
 So how does all this come together to help
create a network?

Network Design
 Ok, that’s not a small question – we’ll 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.

Objetivo del diseño de red
 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
Objetivo del diseño de red
 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?

Fases del diseño
 Designing a network is
typically broken into three
sections:
 Determine requirements
 Define the overall
architecture
 Choose technology and
specific devices
(McCabe, 2003)

Metodología de sistema
 There’s 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
Dos principios
 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

Dos principios jerarquía e
interconexión
Distribución
(McCabe, 2003)

Adelante
 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

¿Los requerimientos? Que
aburrido
 Yes, determining the requirements for a
network probably isn’t 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
Requerimientos
 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 we’ve
chosen is ‘just right’ (Southey, 1837)
 Is that $2 million network backbone really enough
to meet our needs?
 How do we know $500,000 wouldn’t have been
good enough?
Requerimientos
 Part of this process is managing the
customer’s expectations
 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

Requerimientos
 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 environment
 How do these need to interact?
 What does the rest of the organization
expect from the network?
Requerimientos
 Consider how devices communicate
Images from (McCabe, 2003)

unless noted otherwise
Requerimientos
 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
Requerimientos
 Service requirements
could include the
QoS (quality of
service) guarantees
(Intserv, Diffserv,
etc.)
 This connects to
network management
monitoring of network
performance

Requerimientos
 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

Análisis de requerimientos
 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)
Análisis de requerimientos
 Requirements can come from many aspects
of the network system
 User Requirements
 Application Requirements
 Device Requirements
 Network Requirements
 Other Requirements

Requerimientos de usuario
 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?
 What’s my budget?

Requerimientos de aplicación
 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?
 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 (OAM&P) – DNS, SMTP, SNMP
 Client-server – ERP, SCM, CRM
 Where are the
apps located?
 Are some only
used in certain
locations?

 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.
 Specialized
devices are
often location-
specific

Requerimientos de
dispositivos
 We want an understanding of the device’s
performance – its ability to process data from
the network
 Device I/O rates
 Delay time for performing a given app function

Requerimientos de
dispositivos
 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
efficiency)
 OS performance (effectiveness of the protocol
stack and APIs)
 Device driver performance
Requerimientos de
dispositivos
 The device
locations are also
critical
 Often generic
devices can be
grouped by their
quantity
 Servers and
specialized stuff are
shown individually
Requerimientos de red
 Network requirements (sounds kinda
redundant) are the requirements for
interacting with the existing network(s) and
network management concerns
 Most networks have to integrate into an
existing network, and plan for the future
evolution of the network

 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 components
 Performance constraints – existing network could
limit performance of the new one
 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 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?

 Security Effect/ Probability User Devices Servers Network Software Services Data
analysis can Unauthorized Access B/A B/B C/B A/B B/C A/B
include the Unauthorized Disclosure B/C B/B C/C A/B B/C A/B
severity Denial of Service B/B B/B B/B B/B B/B D/D
(effect) of Theft A/D B/D B/D A/B C/C A/B
an attack, Corruption A/C B/C C/C A/B D/D A/B
and its Viruses B/B B/B B/B B/B B/C D/D
probability Physical Damage A/D B/C C/C D/D D/D D/D
of Effect: Probability:
A: Destructive C: Disruptive A: Certain C: Likely

occurrence
B: Disabling D: No Impact B: Unlikely D: Impossible

Otros requerimientos
 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?
 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 costs
 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
 Enterprise requirements typically include
integration of your network with existing
standards for voice, data, or other protocols

Mapeo de requerimientos y
especificaciones
 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)
especificaciones
 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 Specification
ID/Name Date Type Description Gathered/Derived Locations Status Priority

especificaciones
 Requirements
Mapping can
show graphically
where stuff is,
what kind of
apps are used,
and existing
connectivity

Proceso de análisis de
requerimientos
 So, how do we
determine what the
requirements are for
our network?
 Collect requirements
service metrics, and
delays to help
develop and
map requirements
Recolectar y listar
requerimientos
 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 sites

Condiciones iniciales
 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

Condiciones iniciales
 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

Usuario y cliente
 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 there’s a big gap!
 Working with users is important, to know how
they use the network and what problems they
find important
 Surveys, phone calls, personal meetings, and/or
group discussions could be used
Usuario y cliente
 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
clarification
 Highly variable, inconsistent requirements
 Unrealistic expectations from the customer
 Measure application performance using
existing network (if possible) or a test bed
Manejo de requerimientos
 The requirements you develop need to be
tracked and managed, just like any system’s
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 network
Métricas de servicio
 Service metrics are characteristics measured
or derived from the network
 Metrics must be configurable, measurable, and
verifiable
 RMA metrics might include
 Reliability – mean time between failures (MTBFs)
and mean time between mission critical failures
(MTBCFs)
 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
include
 Ping, pathchar, traceroute, TCPdump
 Packet capture utilities: Ethereal, Sniffer, and Etherpeak
 Then summarize the metrics collection approach
Service Metric Where Metric Will Be Measured in System Measurement Method
1 LAN Delay Between NM Device and Each Router in LAN Ping
2 WAN Delay 1 Between NM Device and Local Router Interface to WAN Ping
3 WAN Delay 2 Between NM Device and Remote Router Interface to WAN Ping
4 LAN Packet Loss At Each Local Router SNMP

Caracterizando el entorno
 Next we can analyze how users and apps
use the existing network
 We could use simulations or models to
assess network behavior
 That’s 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
Caracterizando el entorno
 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
Requerimientos de fiabilidad,
manejabilidad y disponibilidad
 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)

 Availability relates failures to repair time
 Scheduled maintenance time doesn’t count
against availability
 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
 Thresholds and limits can be defined for RMA
measures
 MTBF is typically a couple thousand hours
 MTTR may be a few hours
 Different parts of the system may have
different requirements

Requerimientos de retraso
 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 reply

 INTD and
HRT help
distinguish
burst from
bulk apps

Delay Requirements
 End-to-end and round-trip delays can be
network requirements
 We’ve 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

Requerimientos de capacidad
 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 it’s available), versus those
that MUST use a lot
Tasas de datos
 Data rates for an app can be measured at
many levels of the protocols
 App, network, etc.
 Most TCP apps will take what’s 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
performance
Necesidades típicas
Application Average Completion Average Data
Time (Seconds) Size (Bytes)
Distributed Computing 103 107
(Batch Mode)
Web Transactions 10 5x104
Database 2–5 103

Entries/Queries
Payroll Entries 10 102
Teleconference 103 105

Necesidades típicas
 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 desired
 Low- and high-performance realms are
completely subjective – there are no industry
or generic numbers to set them apart
Rendimiento suplemental
 Other non-functional requirements can be
important to a network
 Operational Suitability is making sure your
customer can operate the network once it’s
running
 How often are manual network adjustments
needed?
 How often does network configuration change?
 How much monitoring is automated?
Sostenibilidad operacional
 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 description
Soportabilidad
 Can the network’s 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

Soportabilidad
 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)
Supportability
 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
problems
Supportability
 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?
Supportability
 All of this produces a concept for support of
a network
 Important to state assumptions about the
knowledge, skills, and availability of support
personnel
 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)
Supportability
Level Tools and Test Corrective Preventive
Equipment Maintenance Maintenance
Organizational Common tools Day-to-day Monitoring

Operator consoles monitoring performance Minor
and controls Troubleshooting on-site cleaning and
Inexpensive special Fault isolation adjustments
tools Reconfiguring
system
Intermediate Special or expensive On-site repair of Major on-site
portable tools with offline equipment upgrades
limited use Supplement
operators
Depot Equipment to Overhaul and Scheduled overhaul
refurbish refurbishment or disassembly of
components LRUs

Confianza
 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

Límites específicos
ambientales
 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, it’s not critical to your customer

Análisis de flujo
 The requirements map is a great place to
start analysis of flows in your network
 We don’t 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
Análisis de flujo
Flow Characteristics
 Later, flows can be Capacity (e.g., Bandwidth)

Delay (e.g., Latency)
broken down into Performance
Requirements Reliability (e.g., Availability)
subnet or link level Quality of Service Levels
flows Importance/ Business/Enterprise/Provider
Priority
 A key purpose of flow Levels Political
analysis is to Directionality
understand the balance Common Sets of Users,

Applications, Devices
between hierarchy and Scheduling (e.g., Time-of-
Other Day)
interconnectivity Protocols Used
needed Addresses/Ports
Security/Privacy Requirements
Análisis de flujo
 Flows can be
individual, or
grouped into
composites
 Flows can be
critical (and
often drive
architecture
and design)
Análisis de flujo
 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

Análisis de flujo

Flujo consolidado

Fuentes de datos y drenadores
 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

Modelos de flujo
 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

Computación distribuida
 Behavior varies – inverse client-server,
peer-to-peer,
hybrid, etc.

Priorización de flujo
 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 customer’s business
 Who pays for it!

Especificaciones de flujo
 Like the requirements, the flows can be
summarized in a specification of some kind
 Critical for identifying priorities, in case
everyone can’t be happy with your design
 Balancing flow requirements can be done
with a flowspec algorithm
 Best effort algorithms only consider capacity
 Predictable flow req’ts consider capacity, delay,
and RMA
 Guaranteed flow req’ts are treated separately
Arquitectura de red
 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
Arquitectura de red
 Avoid thinking of just the physical
components of a network (routers, hubs, etc.)
 Think of the functions it’s performing
(addressing, routing, security, network
management, performance) as an integral
part of the components
 E.g. routing or switching can be affected by
security
 So think of functional entities, not just HW
Arquitectura de red
 Measure network success by how well user,
app, and device req’ts 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

Arquitectura de red
 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 we’ll
need to understand how they work together

Funciones de red
 The key functions are
 Addressing and routing
 Network management
 Performance
 Security
 Functions may also include storage and
infrastructure, but we’ll focus on other ones
 Making this work may require trade-offs!

Regla de diseño básica:
regiones
 Divide the network into regions, based on
similar traffic flows
 Edges (access regions) are where flows start
or stop
 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

Direccionamiento/enrutamiento
 Addressing applies MAC or IP addresses
for devices
 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

Direccionamiento/enrutamiento
 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 we’re just
choosing the types of mechanisms, not
deciding exact structures
Arquitectura de manejo de red
 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

Architecture de rendimiento
 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

Arquitectura de seguridad
 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

Arquitectura de referencia
 All these components need to be reconciled
with each other
 Can add key req’ts and chosen mechanisms to
flow diagram
 Prioritize mechanisms and how they interact
 The Reference Architecture is the collection
of all the component architectures

Arquitectura de referencia
 Req’ts
dictate
which
components
are favored,
if any

Modelos de arquitectura
 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
structure
 The core/distribution/access model – think of
getting videos from CNN
Modelos de topología

Modelos de flujo
 We’ve already seen these (slides 84-87)
 Peer-to-peer
 Client-server
 Hierarchical client-server
 Distributed-computing

Modelos funcionales
 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
Modelos funcionales
 Service provider
and intranet/
extranet models

Modelos funcionales
 No cartoon for single- or multi-tier model;
could be a combination of the others
 End-to-end model

Aplicando modelos
 The flow and functional models overlap in
focus with the core/distribution/access model

Arquitectura del sistema
 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

Seleccionar tecnologías
 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…?
 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

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

 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 don’t have this
 ATM, frame relay, SMDS, HiPPI

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

Funciones de la tecnología
 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

Actualizaciones de
rendimiento
 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
Actualiaciones de rendimiento
Technology Maximum Capacity Maximum Throughput
Ethernet 10 Mb/s 3–9 Mb/s
100 Mb/s 80–95 Mb/s
1 Gb/s 700–980 Mb/s
Token Ring 4 Mb/s 4 Mb/s
16 Mb/s 16 Mb/s
100 Mb/s 80–100 Mb/s
ATM
T3 45 Mb/s 34 Mb/s
OC-3c 155 Mb/s 120–135 Mb/s
OC-48 2.5 Gb/s 2.1–2.35 Gb/s
HiPPI 800 Mb/s 350–750 Mb/s

1.6 Gb/s 0.5–1.4 Gb/s
6.4 Gb/s 1.8–6 Gb/s
Frame relay 45 Mb/s 45 Mb/s
ADSL Up to 1.5 Mb/s, depending on service level Up to 1.5 Mb/s, depending on service level

Cosideraciones de flujo
 The flow spec should help tell which flows
have similar requirements, and which need
special consideration for performance,
capacity, or other needs
 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 needed

Guias para evaluación técnica
 Use combined capacities for best-effort flows
(generic Internet), and RMA, capacity, and/or delay
requirements for predictable or guaranteed services
 Guideline 1:Usar tecnologías que soporten
requerimientos predecibles o garantizados
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
requirements.
Guias para evaluación técnica
 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

Segmentar la red
 Now that we have nailed down technology
choices, we can address the detailed
structure of the network – how it’s 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?
Segmentar la red
 A geographic example of segmenting

Segmentar la red
 A user-based view of segmenting

Segmentar la red
 A flow hierarchy-based example

Segmentar la red
 Segments can include defining broadcast
domains, collision domains, or the scope of
autonomous systems (AS’s)
 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.)

Segmentar la red
 Segmenting by types of function and feature

Método de la caja negra
 Once segments have been defined, we can
view each segment as black box(es)
 Know inputs and outputs, and don’t worry about
the inner details yet
 A segment could have several black boxes

Método de la caja negra
 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 don’t want to have all
technology decisions made in a vacuum, or
wildly different or incompatible technologies
may be chosen
 Common sense should prevail!
Resumen
 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
Trabajar en equipo tiempo
40m
Cuales son los requerimientos
Cuales son las restricciones
¿Hace análisis de riesgos?
Cuales son las necesidades del usuario,
aplicac, de red
¿Cuales son los flujos?, estime los flujos
¿Que arquitectura se propone?
como elabora el diseño, lo valida con el usuario
¿que tecnologías usa?

Diseño Redes

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Diseño Redes

Hochgeladen von

Copyright:

Verfügbare Formate

INFO 331

INFO 331 Network Design 1

INFO 331 Network Design 2

INFO 331 Network Design 3

INFO 331 Network Design 5

INFO 331 Network Design 6

INFO 331 Network Design 8

INFO 331 Network Design 9

INFO 331 Network Design 10

INFO 331 Network Design 13

Images from (McCabe, 2003)

INFO 331 Network Design 17

INFO 331 Network Design 18

INFO 331 Network Design 20

INFO 331 Network Design 21

INFO 331 Network Design 24

INFO 331 Network Design 26

INFO 331 Network Design 27

INFO 331 Network Design 30

INFO 331 Network Design 32

INFO 331 Network Design 33

severity Denial of Service B/B B/B B/B B/B B/B D/D

(effect) of Theft A/D B/D B/D A/B C/C A/B

an attack, Corruption A/C B/C C/C A/B D/D A/B

and its Viruses B/B B/B B/B B/B B/C D/D

probability Physical Damage A/D B/C C/C D/D D/D D/D

A: Destructive C: Disruptive A: Certain C: Likely

INFO 331 Network Design 34

INFO 331 Network Design 37

ID/Name Date Type Description Gathered/Derived Locations Status Priority

INFO 331 Network Design 39

INFO 331 Network Design 40

INFO 331 Network Design 42

INFO 331 Network Design 43

INFO 331 Network Design 44

INFO 331 Network Design 50

Service Metric Where Metric Will Be Measured in System Measurement Method

1 LAN Delay Between NM Device and Each Router in LAN Ping

4 LAN Packet Loss At Each Local Router SNMP

INFO 331 Network Design 52

INFO 331 Network Design 55

INFO 331 Network Design 57

INFO 331 Network Design 58

INFO 331 Network Design 59

INFO 331 Network Design 60

Database 2–5 103

Teleconference 103 105

INFO 331 Network Design 63

INFO 331 Network Design 67

Organizational Common tools Day-to-day Monitoring

INFO 331 Network Design 72

INFO 331 Network Design 73

INFO 331 Network Design 75

 Later, flows can be Capacity (e.g., Bandwidth)

understand the balance Common Sets of Users,

INFO 331 Network Design 79

INFO 331 Network Design 80

INFO 331 Network Design 81

INFO 331 Network Design 82

INFO 331 Network Design 83

INFO 331 Network Design 84

INFO 331 Network Design 85

INFO 331 Network Design 86

INFO 331 Network Design 87