Sei sulla pagina 1di 36

Practicas Pre Profesionales II UPAO

METODOLOGIA DE DISEÑO DE RED TOP DOWN

Historia de la Metodología TOP DOWN


El diseño de red top-down es una disciplina que creció del éxito de la programación
de software estructurado y el análisis de sistemas estructurados. El objetivo principal
del análisis de sistemas estructurado es representar más exacto las necesidades de
los usuarios, que a menudo son lamentablemente ignoradas. Otro objetivo es hacer
el proyecto manejable dividiéndolo en módulos que pueden ser más fácil de
mantener y cambiar.

El diseño de red top-down es una metodología para diseñar redes que comienza en las
capas superiores del modelo de referencia de OSI antes de mover a las capas
inferiores. Esto se concentra en aplicaciones, sesiones, y transporte de datos antes de
la selección de routers, switches, y medios que funcionan en las capas inferiores.

El proceso de diseño de red top-down incluye exploración divisional y estructuras de


grupo para encontrar la gente para quien la red proporcionará servicios y de quien usted
debería conseguir la información valiosa para hacer que el diseño tenga éxito.

El diseño de red top-down es también iterativo. Para evitar ser atascado en detalles
demasiado rápido, es importante conseguir primero una vista total de los requerimientos
de un cliente. Más tarde, más detalle puede ser juntado en comportamiento de
protocolo, exigencias de escalabilidad, preferencias de tecnología, etcétera. El diseño
de red top-down reconoce que el modelo lógico y el diseño físico pueden cambiarse
cuando más información es juntada.

Como la metodología top-down es iterativa, un acercamiento top-down deja a un


diseñador de red ponerse "en un cuadro grande" primero y luego moverse en espiral
hacia abajo segun exigencias técnicas detalladas y especificaciones.

Los Sistemas de Cisco recomiendan un acercamiento modular con su modelo jerárquico


de tres capas. Este modelo divide redes en nucleo, distribución, y capas de acceso. La
Arquitectura Segura de Cisco para Empresas (SAFE) y compuesto de un Modelo de
Red de Empresa, son también aproximaciones modulares para el diseño de la red.

Con un acercamiento estructurado diseñamos la red, cada módulo es diseñado por


separado, aún con relación a otros módulos. Todos los módulos son diseñados usando
un acercamiento top-down que se concentra en los requerimientos,
Practicas Pre Profesionales II UPAO

aplicaciones, y una estructura lógica antes de la selección de dispositivos físicos y


productos que se implementara en el diseño.

Fase I: Identificando objetivos y necesidades del cliente


Parte 1. Análisis de los objetivos y limitaciones del negocio

Los objetivos y limitaciones incluyen la capacidad de correr las aplicaciones de red que
reune los objetivos comerciales corporativos, y la necesidad de trabajar dentro de
restricciones comerciales, como paquete, personal limitado que esta conectado a una
red, y márgenes de tiempo cortos.

El comprender los objetivos comerciales y sus restricciones de sus clientes es un


aspecto crítico del diseño de red. Armado con un análisis cuidadoso de los objetivos
comerciales de su cliente, usted puede proponer un diseño de red que contara con la
aprobación de su cliente.

El entendimiento de la estructura corporativa también le ayudará a reconocer la


jerarquía de dirección. Uno de sus primeros objetivos en las etapas tempranas del
diseño de un proyecto de red debe determinar quiénes son los funcionarios con poder
de decisión. ¿Quién tendrá las autoridades para aceptar o rechazar su propuesta de
diseño de red?

Además del análisis de objetivos comerciales y determinación de la necesidad de su


cliente de apoyar aplicaciones nuevas y existentes, es importante analizar cualquier
restricción comercial que afectará su diseño de red.

Si usted tiene en mente cambios de estrategias comerciales y gestión de redes de


empresa discutido en las secciones anteriores, se hace posible poner una lista de los
objetivos comerciales en el diseño de alguna red típica:
Aumento de ingresos y ganancia.
Aumento de Cuota de mercado.
Expansión de nuevos mercados.
Aumente ventajas competitivas sobre compañías en el mismo mercado.
Reduzca gastos.
Aumente la productividad de empleado.
Acorte ciclos de desarrollo de producto.
Use la fabricación justo a tiempo.
Plan alrededor de escaseces componentes.
Ofrezca nuevos servicios de cliente.
Ofrezca el mejor soporte de cliente.
Practicas Pre Profesionales II UPAO

Abra la red a componentes claves (perspectivas, inversionistas, clientes, socios de


negocio, proveedores, y empleados).

Construya relaciones y accesibilidad de información a un nuevo nivel, como una


base para un modelo organizacional de red.

Evite la interrupción comercial causada por problemas de seguridad de red.

Evite la interrupción comercial causada por desastres naturales y poco naturales

Modernice tecnologías anticuadas.

Reduzca los gastos de telecomunicaciones y red , incluso elevado asociado con


redes separadas para voz, datos, y vídeo

Parte 2. Análisis de los objetivos y limitaciones técnicas

En este parte trata de dar algunos alcances para analizar las metas técnicas de los clientes
para implementar una nueva red o actualizar una existente. Conociendo las metas técnicas
de nuestros clientes podremos recomendar nuevas tecnologías que al implementarlas
cumplan con sus expectativas.

Los típicos objetivos técnicos son adaptabilidad, disponibilidad, funcionalidad, seguridad,


manejabilidad, utilidad, adaptabilidad, y factibilidad.

Uno de los principales objetivos de este capitulo es poder conversar con sus clientes en
términos que ambos puedan entender.

Escalabilidad
La escalabilidad se refiere de cuanto es capaz de dar soporte al crecimiento del diseño de la
red. Uno de los principales objetivos para muchas empresas es que su red sea altamente
escalable, especialmente las empresas grandes que normalmente tienen un crecimiento
rápido tanto en usuarios, aplicaciones y conexiones de red. El diseño de red que usted
propone a un cliente debería ser capaz de adaptarse a aumentos del uso de red y el
alcance.

Disponibilidad
La disponibilidad se refiere a todo el tiempo que una red está disponible a usuarios y es a
menudo una meta difícil de alcanzar para los que diseñan la red, ésta puede ser expresada
en porcentajes por año, mes, semana, día u hora comparado con tiempo total del periodo.La
palabra disponibilidad puede ser mal entendida por los usuarios para lo que se debe ser
muy cuidadoso en explicar en que consiste la disponibilidad de la red para ello se puede
usar la palabra fiabilidad que se refiere a varios factores, como la exactitud,
Practicas Pre Profesionales II UPAO

rangos de error, estabilidad, y la cantidad de tiempo entre fracasos lo que refleja la


disponibilidad de la red.

Disponibilidad también lo asocian con la redundancia que no es un objetivo para el diseño


de red, mas bien es una solución, se refiere que se duplica los enlaces a la red para reducir
tiempos lo que permite continuidad después de fallas o desastres.

Disponibilidad esta asociada también con la resistencia que significa cuanto estrés puede
manejar la red con rapidez, que la red pueda manejar los problemas incluyendo los de
seguridad, brechas, desastres naturales y no naturales, errores humanos, fallas del
hardware o software.

Performance
Cuando se analiza los requerimientos técnicos para el diseño de la red, se puede convencer
a los clientes para aceptar la performance de la red, incluyendo rendimiento, exactitud,
eficacia, tardanza, y tiempo de respuesta.

Analizar el estado actual de la red puede ayudar a ver que cambios se podrían realizar para
que mejore la performance de la red. Las metas de la performance de la red están bastante
ligada con las metas de la escalabilidad.

Seguridad
El diseño de la seguridad es uno de los aspectos más importantes en el diseño de red
empresarial. Al incrementar las amenazas tanto dentro como fuera de la red de la empresa
se debe tener reglas y tecnologías de seguridad actualizadas e incorruptibles. Las metas
más deseadas de muchas empresas es que los problemas de seguridad no afecten a la
habilidad de conducir los negocios de la empresa, osea que si se presentara algún tipo de
problema la empresa debe ser capaz de seguir con sus actividades normales.

La primera tarea para el diseño de la seguridad es planificar. Lo que significa que debemos
reconocer las partes más vulnerables de la red, analizando los riesgos y encontrando
requerimientos.

Como es el caso de la mayoría de las exigencias técnicas de diseño, alcanzando objetivos


de seguridad significa hacer compensaciones. Las puestas en práctica de seguridad pueden
aumentar el costo de despliegue y funcionamiento de la red, también puede afectar la
productividad de usuarios, sobre todo si se dificulta el modo de trabajo para proteger
recursos y datos. La Seguridad también puede afectar la redundancia del diseño de red por
ejemplo si el tráfico pasa por dispositivos de cifrado.
Practicas Pre Profesionales II UPAO

Manejabilidad (Administración)
Cada cliente tiene objetivos y una forma de administrar la red diferente. Algunos clientes
tienen metas claras de cómo administrar la red y otras metas menos específicas. Si su
cliente tiene proyectos definidos, debe asegurarse que se documenten, porque usted tendrá
que referirse a los proyectos seleccionando el equipo. En algunos casos, el equipo tiene que
ser excluido porque esto no soporta la administración de funciones que el cliente requiere.

La administración de la red debe ser simplificada. Simplificarlos en paquetes de funciones


de administración se entienden fácilmente y usados por administradores de red. Durante la
reunión de inicial de exigencias técnicas para el diseño o actualización de una red, se puede
usar la terminología ISO para simplificar la discusión de las metas de los administradores de
red con sus clientes, de la siguiente manera:

· Administración de funcionamiento. Analizar el tráfico y el comportamiento de


aplicación para optimizar una red, quedar en acuerdos de nivel de servicio, y el plan
para la extensión
· Administración de defecto. Descubrir, aislar y corregir de problemas; reportando los
problemas a usuarios finales y gerentes.
· Administración de configuración. Control, funcionamiento, identificación, y recolectar
datos de dispositivos de administración
· Administración de Seguridad. Supervisión y pruebas de seguridad y política de
protección, manteniendo y distribuyendo contraseñas y otra autenticación e
información de autorización, llaves de cifrado directivas, y adhesión de revisión a
política de seguridad.
· Administración de la contabilidad. Contabilizar el uso de la red para asignar gastos
para conectar una red a usuarios y/o plan para cambios de exigencias de capacidad

Parte 3. Graficando la Red Existente

Esto se basa en una ejecución en un mapa de una red y aprendiendo la localización de la


mayoría de los dispositivos y segmentos en el trabajo de la red y identificando algunos
métodos establecidos para el direccionamiento y nombramiento y también archivando,
investigando los cables físicos, reservas que son muy importante en la característica de la
infraestructura de la red.

Ejecución de un Mapa de Red


Para la mayoría de los diseñadores de red; la interconexión de dispositivos y segmentar de
la red es un buen camino para comenzar la compresión del flujo circulatorio.
Practicas Pre Profesionales II UPAO

El objetivo es obtener un mapa ya implementado de la red, algunos diseños de los clientes


pueden tener mapas para un nuevo y mejor diseño de la red.

Herramientas para la Ejecución de un Mapa de Red


Para ejecutar un mapa de la existencia de la red, deberíamos invertir en una buena
herramienta de diagrama de red. Tales como:
Visio Corporations.
Visio Profesional.
Visio Profesional Ships.

Algunas compañías ofrecen esquematizar automáticamente el descubrimiento de la red


existente, usando el siguiente software:
Pinpoint Software’s ClickNet Professional.
NetSuite Development.
Net Suite Advanced Professional Design.
NetSuite Professional Audit (similar ClickNet).

¿Que debería Incluir en un Mapa de Red?


Usando las herramientas mencionadas deberá desarrollar un mapa de red en la cual
deberá contener lo siguiente:
o Conexiones WAN entre países y ciudades.
o Edificios y pisos, y posibilidades cuartos y casetas.
o Conexiones WAN y LAN entre edificios y entre campos.
o Una indicación de la capa de datos (WAN, LANS).
o El Número de servicios proveedor de WANS.
o La localización de las líneas y interruptores, aunque no es necesario en el eje y centro.
o La localización y alcance de redes virtuales (VPN’s), que conecta los servicios de los
proveedor WAN.
o La localización de las principales estructuras.
o La localización de las mayores estaciones de ejecución de la red.
o La localización y alcance de algunas LAN’s Virtuales (VLAN’s).
o La topología de algunos sistemas de seguridad Firewall.
o La localización de algunos sistemas de dial- in y dial out.
o Algunas indicaciones de donde residen algunas estaciones de trabajo, aunque no
necesariamente la localización explicita de cada estación de trabajo.
Practicas Pre Profesionales II UPAO

Caracterizando el Direccionamiento y el Nombramiento de la Red


La infraestructura lógica de la red envuelve documentar cualquier estrategia que su cliente
tiene para el direccionamiento y nombramiento de la red.
Cuando dibuje los detalles de los mapas de la red, deberá incluir los sites, routers,
segmentos de la red y servicios.

Usted tiene que investigar el direccionamiento de la capa de red que usa, el esquema de
direccionamiento que usa su cliente puede influenciar en la habilidad de adaptar su
nuevo diseño de red a los objetivos, aquí definirá el mejor método de direccionamiento
que se pueda usar para su diseño de red. Entre los cuales tenemos:
Subnetting.
Variable Lenght Subnet Masking (VLSM).
Supernetting o Aggregations.
Summarization.
Estos métodos se explicaran más adelante cuando se seleccione el protocolo y
direccionamiento de red.

Caracterizando el Cableado y el Medio


Es importante comprender el cableado y la instalación eléctricos del diseño de la red con el
objetivo de identificar posibles y potenciales problemas. Si es posible usted deberá
documentar el tipo de cableado que usa, la distancia ya que esta información ayudara a
determinar la Tecnología de la capa de enlace basado en las restricciones de distancia.

Cuando el diseño del cableado esta en exploración, determine cuales son los equipos y los
cables que están etiquetado en la red existente.

Por ejemplo: la red de un edificio debería archivar las conexiones de un número de cable y
el tipo de instalación que esta en uso en la red.

Probablemente la instalación entre los edificios es unos de los sgtes:


Single –mode fiber
Multi –mode fiber
Shielded twisted pair (STP)

UTP categoría 5
Cable coaxial
Microondas
Radiofrecuencia.
Láser
Infrarrojo
Practicas Pre Profesionales II UPAO

Supervisando la Arquitectura Ambiental y Restricciones


Cuando esta investigando el cableado hay que poner mucha atención en los problemas
ambientales con la posibilidad de que el cableado podría pasar muy cerca donde haya
lugares propensos a inundarse, cerca de las carreteras donde el tráfico de los vehículos
podría quebrar los cables, calefacciones, etc.

Este seguro que no tenga ningún problema legal a la hora de tender un cableado, por
ejemplo al cruzar un cableado por una calle donde tenga que romper pistas.

Cuando construya preste atención a la arquitectura si este afecta la implementación de


su diseño, este seguro que la arquitectura puede soportar el diseño tales como:
Aire acondicionado.
Calefacción.
Ventilación.
Protección de interferencias electromagnéticas.
Puertas que no estén cerradas, etc.

Supervisando el buen Funcionamiento de la Red existente


Estudiar el performance de una red existente te da una línea básica dimensional para poder
medir y compara el performance del nuevo diseño de red propuesto el cual le ayudara a
demostrar a su cliente cuan mejor es su diseño en performance una vez implementado.

Si la red es muy grande para estudiar todos sus segmentos, preste mayor atención en la red
de backbone antigua y las nuevas áreas que se conectan así como redes que se integran al
backbone.

Por ejemplo capturar la circulación la red con un analizador de protocolo como parte de tu
análisis de la línea básica, podría identificar cuales de los protocolos están realmente
trabajando en la red y no contar con la creencia de los clientes (ethereal).

Analizando la Performance precisa de la Red


Poder identificar la performance precisa de una red no es tarea fácil. Una de las tareas es
seleccionar el tiempo para hacer estos análisis para poder determinar el momento exacto
para poder realizarlo y determinar los problemas que presenta la red durante los periodos
altos de tráfico, etc.

Los problemas de la red no son usualmente causados por los envíos de malas estructuras
de tramas. En el caso token ring (La red Token-Ring es una implementación del standard
IEEE 802.5, en el cual se distingue más por su método de transmitir la
Practicas Pre Profesionales II UPAO

información que por la forma en que se conectan las computadoras., el problema


usualmente esta por estación y problema de cable, en el caso de ethernet, es un difícil
precisar la causa del problema.

Algunos clientes no reconocen el valor de estudiar las redes existentes antes del diseño y la
implementación. Los clientes generalmente se avocan por un diseño rápido por lo cual
puede hacer difícil poder dar marcha atrás y insistir en tiempo para desarrollar la
performance precisa de la red existente. Un buen entendimiento de los objetivos técnicos y
de negocio del cliente pueden ayudar a decidir que cantidad de tráfico deberá analizar en la
red.

Analizando la Disponibilidad de la Red


Para documentar características de disponibilidad de la red existente, junte cualquier
estadística que el cliente tiene durante el tiempo medio entre fallas (MTBF) y tiempo medio
de reparación (MTTR) para las redes en conjunto así como segmentos de red principales.
Compare estas estadísticas con la información en la que usted se ha juntado en MTBF y
objetivos MTTR, ¿Espera el cliente que su nuevo diseño aumente MTBF y disminuya
MTTR? ¿Son los objetivos del cliente consideración realista del estado corriente de la red?

Diríjase a los ingenieros de red y técnicos sobre las causas de los períodos más recientes y
más perjudiciales del tiempo de indisponibilidad.

Interpretando como un investigador forense, trate de conseguir muchos lados a la historia. A


veces los mitos se desarrollan sobre lo que causó una interrupción de red. (Usted puede
conseguir por lo general una vista más exacta de causas de problema de ingenieros y
técnicos que de usuarios y gerentes.) Puede usar esta Tabla Nro. 01 para documentar.

Tabla Nro. 01 Caracterizar la Disponibilidad de la Red


Practicas Pre Profesionales II UPAO

Analizando la Utilización de la Red


Utilización de red es una medida de cuanta ancho de banda está en el uso durante un
intervalo de tiempo específico. La utilización es comúnmente especificada como un
porcentaje de capacidad. Si un instrumento que supervisa la red dice que la utilización de
red en un segmento de Fast Ethernet es el 70%, por ejemplo, este significa que el 70% de la
capacidad 100-Mbps está en el uso, hecho un promedio sobre un margen de tiempo
especificado o ventana.

Diferentes instrumentos usan diferente promedio de ventanas para calcular la utilización de


red. Algunos instrumentos dejan al usuario cambiar la ventana. La utilización de un intervalo
largo puede ser útil para reducir la cantidad de datos estadísticos que deben ser analizados,
pero la granularidad es sacrificada.

Figura Nro. 09. Analizando la Utilización de la Red

Utilización del Ancho de Banda por Protocolo


El desarrollo de una performance preciso de la performance de red también debería incluir
la utilización de medición del tráfico de broadcast contra el tráfico unicast, y por cada
protocolo principal. Algunos protocolos envían excesivo tráfico de broadcast, que puede
degradar seriamente la performance, sobre todo en redes switchadas.

Para medir la utilización del ancho de banda por protocolo, coloque un analizador de
protocolo en cada segmento de la red principal y llena una tabla como la mostrada en la
figura. Si el analizador soporta porcentajes relativos y absolutos, especifique el ancho de
banda usada por protocolos en comparación al total de ancho de banda en uso. Uso relativo
especifica cuanto ancho de banda es usada por protocolo en comparación con el ancho de
banda total actualmente en uso en el segmento. Uso absoluto especifica cuanta ancho de
banda es usada por protocolo en comparación con la capacidad total del segmento (por
ejemplo, en comparación con 100 Mbps en Fast Ethernet).
Practicas Pre Profesionales II UPAO

Tabla Nro. 02 Utilización del Ancho de Banda por Protocolo

Análisis de la Exactitud de Red


Usted puede usar a un probador BER (también llamado BERT) en líneas seriales para
probar el número de bits dañados comparados a los totales de bits.

Con redes por paquete switchados, hace más sentido de medir el paquete (packer) de
errores porque un paquete entero es considerado malo si un solo bit es cambiado o
descartado. En redes por paquete switchados, una estación de envío calcula un ciclo de
redundancia CRC basado en los bits del paquete. La estación de envío reemplaza el valor
del CRC en el paquete. Una estación de recepción determina si el bit ha sido cambiado
entonces descarta el paquete y vuelve a calcular el CRC otra vez y comparando el resultado
con el CRC del paquete. Un paquete con CRC malo es descartado y debe ser transmitido de
nuevo por el remitente. Por lo general un protocolo de capa superior tiene el trabajo de
transmitir de nuevo los paquetes que no se ha reconocidos.

Un analizador de protocolo puede comprobar el CRC en los paquetes recibidos. Como la


parte de su análisis de performance preciso, usted debería rastrear el número de paquetes
recibidos con CRC malo cada hora o cada dos días. Como es normal los errores aumentan
con la utilización, errores de documento como una función del número de bytes vistos por el
instrumento de escucha. Un umbral de regla básica bueno para considerar errores malsanos
es que una red no debería tener más de un paquete malo por megabyte de datos. (Errores
calculados este camino le deja simular una serie BERT. Simplemente el cálculo de un
porcentaje de paquetes malos comparados con paquetes buenos nos explica el tamaño de
paquete y de ahí no da una indicación buena de cuantos trozos realmente se han dañados).

Además del rastreo de errores de capa de enlace de datos, como errores CRC, un análisis
del performance preciso debería incluir la información en problemas de capa superior. Un
analizador de protocolo que incluye un sistema experto, como WildPackets EtherPeek NX
analizador de red, se apresura la identificación de problemas de capa
Practicas Pre Profesionales II UPAO

superior por automáticamente generando diagnósticos y síntomas para conversaciones de


red y aplicaciones.

La exactitud también debería incluir una medida de paquetes perdidos. Usted puede medir
paquetes perdidos midiendo el tiempo de respuesta.

Enviando paquetes para medir cuanto tiempo este toma para recibir una respuesta,
documente cualquier paquete que no recibe una respuesta, probablemente porque la
petición o la respuesta fue perdido. Correlacione la información sobre paquetes perdidos con
otras medidas de interpretación para determinar si los paquetes perdidos indican una
necesidad de aumentar el ancho de banda, para disminuir errores CRC, o mejorar
dispositivos de funcionamiento entre redes. Usted también puede medir paquetes perdidos
mirando la estadística guardada por gestores de tráfico en el número de paquetes
descartados de colas de salida o entrada.

Analizando la Eficiencia de la Red


La utilización de ancho de banda es optimizada para la eficacia cuando las aplicaciones y
los protocolos son configurados para enviar cantidades grandes de datos por paquete, así
minimizando el número de paquete y tardanzas de ida y vuelta requeridas para una
transacción. El número de paquetes por transacción también puede ser minimizado si el
receptor es configurado con una ventana grande que lo permite aceptar paquetes múltiples
antes de que esto debiera enviar un reconocimiento.

Cambiando la transmisión y recepción del tamaño de buffer- paquete de los clientes y los
servidores pueden causar la eficacia mejorada por paquete recibido en la ventana. El
aumento de la unidad de transmisión máxima (MTU) en interfaces del router también puede
mejorar la eficacia.

Por otra parte, el aumento del MTU es a veces necesario en interfaces del router de
aquellos que usan túneles. Los problemas pueden ocurrir cuando una cabecera
suplementario es añadido por el túnel hace que el paquete sean más grandes que falta
MTU. Un síntoma típico de este problema es que los usuarios pueden ping y Telnet, pero no
usar el Protocolo de Transferencia de Hipertexto (HTTP), FTP, y otros protocolos que usan
los paquetes grandes. Una solución es aumentar el MTU en el interfaz del router.

Para determinar si los objetivos de su cliente para la eficacia de red son realistas, usted
debería usar un analizador de protocolo para examinar los tamaños de los paquetes que se
usa en la red. Muchos analizadores de protocolo le dejan tabla de salida como el que se
especifica en la figura 3.7
Practicas Pre Profesionales II UPAO

Figura Nro. 10. Graficando el Tamaño de los Paquetes del Backbone

Analizar la Tardanza y Tiempo de Respuesta


Para verificar que la performance de un nuevo diseño de red se encuentra dentro de las
exigencias de un cliente, es importante medir el tiempo de respuesta entre dispositivos de
red antes y después de que un nuevo diseño de red es puesto en práctica. El tiempo de
respuesta puede ser medido por muchos caminos. Usando un analizador de protocolo,
usted puede mirar la cantidad de tiempo entre paquetes y conseguir una estimación del
tiempo de respuesta en la capa de enlace de datos, capa de transporte, y capa de
aplicación. (Este es una estimación porque los tiempos de llegada de paquete en un
analizador sólo pueden acercarse tiempos de llegada de paquete en estaciones finales.)
Un modo más común de medir tiempo de respuesta es enviar paquetes de ping y medir el
tiempo de ida y vuelta (RTT) para enviar una petición y recibir una respuesta. Midiendo RTT,
usted también puede medir la variación RTT. Medidas las variaciones son importantes para
aplicaciones que no pueden tolerar muchas variaciones (por ejemplo, voz y aplicaciones de
vídeo). Usted también puede documentar cualquier pérdida de paquetes. Usted puede usar
una tabla para documentar estas medidas ver figura:

Tabla Nro. 03 Medida del Tiempo de Respuesta


Practicas Pre Profesionales II UPAO

El Chequeo del estado de los Routers principales, Switches, y Firewalls


El paso final en la caracterización de las redes existentes debe comprobar el
comportamiento de los dispositivos de funcionamiento entre redes en las redes. Este incluye
routers e switches que unen capas de una topología jerárquica, routers de backbone e
switches, y firewalls que tendrán los papeles más significativos en su nuevo diseño de red.
No es necesario comprobar cada switch de LAN, sólo los switches principales, routers, y
firewalls.

La comprobación del comportamiento y la salud de un dispositivo de funcionamiento entre


redes incluye la determinación que ocupado el dispositivo es (utilización de CPU), cuantos
paquetes esto ha tratado, cuantos paquetes esto se ha perdido, y el estado de los buffer y
colas. Su método para tasar la salud de un dispositivo de funcionamiento entre redes
depende del vendedor y la arquitectura del dispositivo.

Parte 4. Caracterizando un diseño de trafico de red

Este sección describe las técnicas para caracterizar el flujo de tráfico, el volumen de tráfico,
y el comportamiento de protocolo. Las técnicas incluyen el reconocimiento de tráfico fuente y
almacenaje de datos, documentar las aplicaciones y uso el de protocolo, y evaluar del tráfico
de red causado por protocolos comunes.

El la sección anterior se habló de la caracterización de la red existente en términos de su


estructura e interpretación. Como el análisis de la situación existente es un paso importante
en un acercamiento de análisis de sistemas para diseñar, este sección se habla de la
caracterización de la red existente en términos de flujo de tráfico. Esta sección también
cubre nuevas exigencias de diseño de red, añadiendo los dos primeras secciones que
cubrieron objetivos de diseño comerciales y técnicos. Esta sección reenfoca en exigencias
de diseño y describe exigencias en términos de flujo de tráfico, carga, y comportamiento; y
calidad de servicio (QoS) exigencias.

Caracterizando el Flujo de Trafico

La caracterización del flujo de tráfico implica identificar fuentes y destinos del tráfico de red y
analizar la dirección y la simetría de datos que viajan entre fuentes y destinos. En algunas
aplicaciones, el flujo es bidireccional y simétrico. (Ambos finales del flujo envían el tráfico en
aproximadamente el mismo precio.) En otras aplicaciones, el flujo es bidireccional y
asimétrico. Las estaciones de cliente envían pequeñas preguntas y los servidores envían
grandes corrientes de datos. Los broadcast de una aplicación, el flujo es unidireccional y
asimétrico. Esta sección habla de la caracterización de la dirección y
Practicas Pre Profesionales II UPAO

la simetría del flujo de tráfico en una red existente y análisis del flujo para nuevas
aplicaciones de red.

La Identificación de las Principales Fuentes de Tráfico y Almacenamiento


Para entender el flujo de tráfico de red, usted debería identificar primero comunidades de
usuario y almacenamiento de datos para las aplicaciones existentes.

A comunidad de usuario es un grupo de trabajadores que usan una aplicación particular o


un grupo de aplicaciones. Una comunidad de usuario puede ser un departamento
corporativo o un grupo de departamentos. Sin embargo, en muchos ambientes, el uso de
aplicación cruza muchos departamentos. Cuando más corporaciones usan la dirección de la
matriz y forman equipos virtuales para completar un proyecto, se hace más necesario
caracterizar comunidades de usuario por aplicación y uso de protocolo más bien que por el
límite de departamentos.

Para documentar comunidades de usuario, pida a su cliente ayudarle a llenar un formulario


de Comunidades de Usuario mostrada en la Tabla Nro. 04. Para la columna de posición de
la figura, los nombres de posición de uso que usted ya documentó en un mapa. Para
aplicaciones, nombres de aplicación de uso en los cuales usted ya documentó en los
formularios de Aplicaciones de Red.

Tabla Nro. 04 Comunidades de Usuarios

Además de la documentación de comunidades de usuario, caracterizando el flujo de tráfico


también requiere que usted documente los principales almacenamiento de datos. Un
almacenamiento de datos (a veces llamaba a colector de datos) es un área en una red
donde los datos de capa de aplicación residen. Un almacenamiento de datos puede ser un
servidor, un grupo de servidores, una red de área de almacenaje (SAN), un ordenador
central, una unidad de reserva de cinta, una biblioteca de vídeo digital, o cualquier
dispositivo o componente de un red donde las cantidades grandes de datos son
almacenadas. Para ayudarle a documentar los principales almacenamiento de datos, pida a
su cliente ayudarle a llenar el siguiente formulario. Para la Posición, la Aplicación, y las
columnas de Comunidad de Usuario, usa nombres que usted ya documentó en un mapa y
otras cartas.
Practicas Pre Profesionales II UPAO

Tabla Nro. 05 Formulario de Almacenamiento de Datos

Documentar el Flujo de Tráfico en la Red Existente


La documentación del flujo de tráfico implica identificar y caracterizar flujos de tráfico
individuales entre fuentes de tráfico y almacenes. Los flujos de tráfico se han hecho
recientemente un tema caliente para la discusión en la comunidad de Internet. Mucho
progreso está siendo hecho en la definición de flujos, medición de comportamiento de flujo,
y permiso de una estación final de especificar los requerimientos de performance por flujo.

Para entender mejor el comportamiento de flujo de tráfico, usted puede leer la Petición de
Comentarios (RFC) 2722, "Medida de Flujo de Tráfico: Arquitectura." El RFC 2722 describe
una arquitectura para la medida y reportaje de flujos de tráfico de red, y habla como la
arquitectura está relacionada con una arquitectura de flujo de tráfico total para el intranet y el
Internet.

La medición del comportamiento de flujo de tráfico puede ayudar a un diseñador de red a


determinar qué trafico de routers deberían ser peer en los protocolos de encaminamiento
que usan un sistema peering, como el Border Gateway Protocol (BGP). La medición del
comportamiento de flujo de tráfico también puede ayudar a los diseñadores de la red y
debran hacer lo siguiente:
· Caracterice el comportamiento de redes existentes.
· Plan de desarrollo y extensión de la red.
· Cuantifique la performance de la red.
· Verifice la calidad del servicio de red.
· Asigne el uso de aplicaciones y usuarios de la red .

Un flujo individual de tráfico de red puede ser definido como protocolo e información de
aplicación transmitida entre entidades que se comunican durante una sesión sola. Un flujo
tiene atributos como dirección, simetría, caminos de enrutamiento, opciones de
enrutamiento, número de paquetes, número de bytes, y se dirige el flujo hacia una dirección
final. Una entidad que se comunica puede ser un sistema de final (host), una red, o un
sistema autónomo.
Practicas Pre Profesionales II UPAO

El método más simple para caracterizar el tamaño de un flujo es medir el número de


Kilobytes o Mbytes por segundo entre entidades que se comunican. Para caracterizar el
tamaño de un flujo, use un analizador de protocolo o conecte a la red el sistema de dirección
para registrar la carga entre fuentes importantes y destinos. Los instrumentos de Cisco para
caracterizar flujos de tráfico incluyen Cisco FlowCollector y el Analizador de Datos, que
están basados en el Cisco NetFlow la tecnología.

Usted puede usar el formulario siguiente descirto para documentar información sobre la
dirección y volumen de flujos de tráfico. El objetivo es documentar los Kilobytes o Mbytes
por segundo entre pares de sistemas autónomos, redes, hosts, y aplicaciones.

Para conseguir la información para llenar los formularios, coloque un dispositivo que
monitoree el core de la red y déjele coleccionar datos por uno o dos días. Para conseguir la
información para llenar la columna de Path, usted puede encender la opción de grabar-ruta
de registro en una red de IP. La opción de ruta de registro tiene algunas desventajas, sin
embargo. Esto no apoya redes muy grandes y es a menudo minusválido para razones de
seguridad. Usted también puede estimar el path mirando la tabla de encaminamiento y
análizando el tráfico de red en multiples segmentos.

Tabla Nro. 06 Flujo de Tráfico en la Red Existente

La Caracterización de Tipos de Flujo de Tráfico para Nuevas Aplicaciones de Red


Como mencionado, un flujo de red puede ser caracterizado por su dirección y simetría. La
dirección especifica si los datos viajan en ambas direcciones o en sólo una dirección. La
dirección también especifica el camino que un flujo toma cuando esto viaja de la fuente al
destino por una de las redes. La simetría describe si el flujo tiende a tener alta performance
o requerimientos de QoS en una dirección que en la otra dirección. Muchas aplicaciones de
red tienen requerimientos diferentes en cada dirección. Algunas tecnologías de transmisión
como la Línea de Suscriptor Digital Asimétrica (ADSL), son fundamentalmente asimétricas.

Una técnica buena para caracterizar flujo de tráfico de red debe clasificar aplicaciones que
soportan una de los tipos de flujo conocidos:
Practicas Pre Profesionales II UPAO

· Flujo de tráfico de terminal/host.


· Flujo de tráfico de cliente/servidor.
· Flujo de tráfico Punto a Punto.
· Flujo de tráfico de servidor/servidor.
· Flujo de tráfico de cálculo distribuido.

En su libro “Análisis de Red, Arquitectura, y Diseño”, Segunda Edición, James D. McCabe


hace un trabajo excelente de caracterización de los distintos modelos de flujo.

Flujo de Tráfico de Terminal/host


El tráfico de terminal/host es por lo general asimétrico. El terminal envía unos caracteres y el
host envía muchos caracteres. El Telnet es un ejemplo de una aplicación que genera el
tráfico de terminal/host. Por defecto detrás de Telnet consiste en que el terminal envía un
simple paquete cada vez que el usuario escribe un carácter. El host devuelve caracteres
múltiples, según lo que el usuario escribió. Como una ilustración, considere el principio de
una sesión Telnet que comienza con el usuario que escribe su nombre. Una vez que el host
recibe cada paquete para los caracteres del nombre, el host devuelve un paquete de
mensaje de regreso (como la Contraseña Requerida).

Flujo de Tráfico de Cliente/Servidor


El tráfico de cliente/servidor es el mejor tipo de flujo conocido y el más extensamente usado.
Los servidores son generalmente poderosas computadoras dedicadas a administrar el
almacenaje de disco, impresoras, u otros recursos de red. Los clientes son ordenadores
personales o estaciones de trabajo en las cuales los usuarios dirigen aplicaciones. Los
clientes confían en servidores para el acceso a recursos, como almacenaje, periféricos,
software de aplicación, y poder de procesamiento.

Los clientes envían preguntas y peticiones a un servidor. El servidor responde con datos o el
permiso para el cliente para enviar datos. El flujo es por lo general bidireccional y asimétrico.
Las peticiones del cliente son típicamente pequeños paquetes, excepto cuando escribe
datos al servidor, en cuyo caso ellos son más grandes. Las respuestas del servidor son de
un rango de 64 bytes a 1500 bytes o más, dependiendo del tamaño maximo del paquete.

En un ambiente TCP/IP, muchas aplicaciones son puestas en práctica de una manera de


cliente/servidor, aunque las aplicaciones fueran inventadas antes de que el modelo de
cliente/servidor fuera inventado. Por ejemplo, el Protocolo de Transferencia de Archivos
(FTP) tiene un lado de servidor y cliente. Los clientes de FTP usan aplicaciones de FTP para
dirigirse a servidores de FTP.
Estos días, el Protocolo de Transferencia de Hipertexto (HTTP) es probablemente el
protocolo de cliente/servidor el más extensamente usado. Los clientes usan una
Practicas Pre Profesionales II UPAO

aplicación de navegador de web, como Netscape, para poder conectarse con el servidor
web. El flujo es bidireccional y asimétrico. Cada sesión a menudo dura sólo unos segundos
porque los usuarios tienden a saltar de un sitio Web al otro.

Flujo de Tráfico Punto a Punto


Con el flujo tráfico punto a punto, el flujo es por lo general bidireccional y simétrico. Las
entidades que se comunican transmiten cantidades aproximadamente iguales de la
información. No hay ninguna jerarquía.

Cada dispositivo es considerado tan importante el uno como el otro, y ningún dispositivo
tiene considerablemente más datos que el otro dispositivo. En pequeños ambientes de LAN,
loa administradores de red a menudo establecen las configuraciones con los ordenadores
personales en un punto a punto de modo que cada uno pueda tener acceso a datos de cada
uno e impresoras. No hay ningún servidor de archivo central o servidor de impresora. Otro
ejemplo de punto a punto el ambiente es preparado para multiusuarios UNIX o host donde
los usuarios establecen FTP, Telnet, HTTP, y sesiones de Sistema de Archivos de Red
entre host.

Cada host actúa tanto como cliente y como servidor. Hay muchos flujos en ambas
direcciones.

Recientemente las aplicaciones punto a punto para descargar música, videos, y software
han ganado la popularidad. Cada usuario publica la música u otro material y permite que
otros usuarios en el Internet descarguen los datos. Este es considerado tráfico punto a
punto porque cada usuario actúa tanto como distribuidor y consumidor de datos. El flujo de
tráfico es bidireccional y simétrico. La mayor parte de empresas y muchas redes de
universidad rechazan este tipo de tráfico punto a punto por dos motivos. Primero, esto
puede causar una cantidad excesiva del tráfico, y, segundo, el material publicado es a
menudo copyright por alguien además de la persona que lo publica.

Un otro ejemplo de aplicación punto a punto es una reunión de negocios entre la gente de
una empresa en sitios remotos usando equipos de videoconferencia. En una reunión, cada
asistente puede comunicar tantos datos como son necesarios en cualquier momento. Todos
los sitios tienen las mismas exigencias QoS. Una reunión es diferente para cada situación
donde la videoconferencia es usada para diseminar la información. Con la diseminación de
información, como una clase de formación o un discurso por un presidente corporativo a
empleados, la mayor parte de los datos fluyen del sitio central. Unas preguntas son
permitidas de los sitios remotos. La diseminación de información es por lo general puesta en
práctica usando un modelo de cliente/servidor.
Practicas Pre Profesionales II UPAO

Flujo de Tráfico de Servidor/Servidor


El tráfico de servidor/servidor incluye transmisiones entre servidores y transmisiones entre
manejo de aplicaciones. Los servidores se dirigen a otros servidores para implementar los
servicios de directorio, una cahe pesadamente usa datos, los mirrow de datos para equilibrio
de carga y redundancia, backup de datos, y disponibilidad de broadcast de servicio.

Los servidores manejan las aplicaciones por algunos mismos motivos, sino también hacer
cumplir políticas de seguridad y actualizar datos de dirección de red. Con el tráfico de red de
servidor/servidor, el flujo es generalmente bidireccional. La simetría del flujo depende de la
aplicación. Con la mayor parte de aplicaciones de servidor/servidor, el flujo es simétrico,
pero en algunos casos esto es heredado de servidores, con algunos servidores que envían
y y almacenan más datos que otros.

Flujo de Tráfico de Cálculo Distribuido


La informática distribuida se refiere a aplicaciones que requieren múltiples nodos que
trabajan y realizan cálculos juntos para completar un trabajo.

Algunas tareas de modelos complejos no pueden ser llevadas a cabo en un margen de


tiempo razonable a menos que múltiples computadoras traten datos y dirijan algoritmos
simultáneamente. Los efectos especiales para películas a menudo son desarrollados y
calculados en un ambiente distribuido. La informática distribuida también es usada en la
industria de semiconductor para calcular las necesidades extremas del diseño y verificación
de un microchip, y en la industria de defensa para proporcionar ingeniería y simulaciones
militares.

Con algunas aplicaciones de cálculo distribuidas, el manejador de tarea dice a los nodos de
cálculo que hacer en una base infrecuente, causando poco flujo de tráfico. Con otras
aplicaciones, hay comunicación frecuente entre el manejador de tarea y los nodos de
cálculo.

La Documentación de Flujo de Tráfico para Aplicaciones Nuevas y Existentes de la


Red
Para documentar el flujo de tráfico para nuevo (y existentes) de aplicaciones de red,
caracterice el tipo de flujo para cada aplicación y ponga las comunidades de usuario en una
lista y los almacenes de datos que tienen que ver con aplicaciones. Usted puede usar este
formulario:
Practicas Pre Profesionales II UPAO

Tabla Nro. 07 Flujo de Tráfico para Aplicaciones Nuevas y Existentes

Caracterización de Carga de Tráfico


Para seleccionar topologías apropiadas y tecnologías para encontrar los objetivos de un
cliente, es importante caracterizar la carga de tráfico con el flujo de tráfico. La
caracterización de la carga de tráfico puede ayudarle a diseñar redes con la capacidad de
uso local suficiente y flujos de redes.

A causa de muchos factores implicados en la caracterización del tráfico de red, las


estimaciones de carga de tráfico con poca probabilidad serán precisas. El objetivo es evitar
simplemente un diseño que tiene cualquier cuello de botella crítico. Para evitar cuellos de
botella, usted puede investigar modelos de uso de aplicación, tiempos ociosos entre
paquetes y sesiones, tamaños de paquetes, y otros patrones de tráfico behaviorísticos para
protocolos de sistema y aplicación.

Otro acercamiento a la evitación de cuellos de botella debe lanzar simplemente cantidades


grandes de ancho de banda en el problema. Una interpretación estricta de principios de
análisis de sistemas no aprobaría tal acercamiento, pero el ancho de banda es barato estos
días. El ancho de banda de LAN es muy barato. No hay simplemente ninguna excusa para
no usar Fast Ethernet (o mejor) en todas las nuevas estaciones de trabajo e switches, y la
mayor parte de organizaciones también pueden permitirse a usar Gigabit Ethernet en switch
a switch y switch a servidor. El ancho de banda WAN es todavía cara en algunas partes del
mundo, incluso áreas rurales de los Estados Unidos. Pero en muchas partes de los Estados
Unidos y el resto del mundo, el ancho de banda ha sido sobre aprovisionada y no está hasta
cerca de ser sobre utilizado.

El Cálculo de Carga de Tráfico Teórica


La carga de tráfico (a veces llamado carga ofrecida) es la suma de todos los nodos de red
de datos que estan listo para transmitir en un tiempo particular. Un objetivo general para la
mayor parte de diseños de red es que la capacidad de red debería ser más que
Practicas Pre Profesionales II UPAO

adecuada de manejar la carga de tráfico. El desafío debe determinar si la capacidad


propuesta para un nuevo diseño de red es suficiente para manejar la carga potencial.

En su libro Redes de Área Locales y Metropolitanas, Guillermo Stallings proporciona


algunos cálculos atrás el-desarrollo para la carga de tráfico calculadora. El Stallings indica
que usted puede hacer un cálculo elemental basado simplemente en el número de la
transmisión de estaciones, como rápidamente cada estación genera mensajes, y el tamaño
de mensajes. Por ejemplo, para una red con una capacidad propuesta de 1 Mbps, si 1000
estaciones envían paquetes de 1000 bits cada segundo, entonces la carga ofrecida iguala la
capacidad. Aunque Stallings se refiriera a la capacidad de un LAN, capacidad podría
referirse a la capacidad de una WAN, una entera red o las partes de una rede, o la el trafico
de la placa madre de un switch o router.

En general, para contar si la capacidad es suficiente, sólo unos parámetros son necesarios:
· El número de estaciones.
· El tiempo medio que una estación es ociosa entre el envío de paquetes.
· El tiempo requerido transmitir un mensaje una vez el acceso medio es ganado.

Estudiando tiempos ociosos y tamaño de los paquetes con un analizador de protocolo, y


estimando el número de estaciones, usted puede determinar si la capacidad propuesta es
suficiente.

Si usted investiga tipos de flujo de tráfico, como hablado antes en este capítulo, usted puede
desarrollar estimaciones más precisas de la carga.

En vez de asumir que todas las estaciones tienen calidades similares que generan carga,
usted puede asumir que las estaciones usando una aplicación particular tienen calidades
similares que generan carga. Las asunciones pueden ser hechas sobre tamaño de paquete
y tiempo ocioso para una aplicación después de que usted ha clasificado el tipo de flujo y ha
identificado los protocolos usado por la aplicación.

Para una aplicación de cliente/servidor, el tiempo ocioso para el servidor depende del
número de clientes que usan al servidor, y la arquitectura y las características de
interpretación del servidor (velocidad de acceso de disco, velocidad de acceso de RAM,
caching mecanismos, etcétera).

Estudiando el tráfico de red de servidores con un analizador de protocolo, usted puede


estimar un tiempo ocioso medio.
Practicas Pre Profesionales II UPAO

El tiempo ocioso en el lado de cliente depende en parte de la acción de usuario, el que


significa que es imposible predecir exactamente el tiempo ocioso. Sin embargo, usted puede
hacer estimaciones del tiempo ocioso estudiando el tráfico con un analizador de protocolo y
usando escrituras para simular acciones de usuario en el peor de los caso, o usando un
instrumento de modelado de red.

Después de que usted ha identificado la carga de tráfico aproximada para un flujo de


aplicación, usted puede estimar la carga total para una aplicación multiplicando la carga
para el flujo por el número de dispositivos que usan la aplicación. La investigación que usted
hace en el tamaño de comunidades de usuario y el número (de servidores) de almacen de
datos puede ayudarle a calcular una exigencia del ancho de banda agregada aproximada
para cada aplicación.

La documentación de la posición de comunidades de usuario y almacenes de datos, en las


cuales usted hizo el formulario, puede ayudarle a entender la cantidad de tráfico que fluirá
de un segmento al otro. Este puede ayudar en la selección de tecnologías de columna
vertebral y dispositivos de funcionamiento entre redes.

Estimando la carga de tráfico, además de la investigación de tiempos ociosos entre


paquetes, tamaños de paquetes, y comportamiento de flujo, usted también debería
investigar modelos de uso de aplicación y exigencias QoS. Algunas aplicaciones son usadas
con poca frecuencia, pero requieren una cantidad grande del ancho de banda cuando ellos
son usados.

Documentación de Patrones de uso de Aplicación


El primer paso en la documentación de modelos de uso de aplicación debe identificar
comunidades de usuario, el número de usuarios en las comunidades, y las aplicaciones que
emplean los usuarios. Este paso, que fue cubierto ya antes en esta sección, puede ayudarle
a identificar el número total de usuarios para cada aplicación.

Además de la identificación del número total de usuarios para cada aplicación, usted
también debería documentar la información siguiente:
· La frecuencia de sesiones de aplicación (el número de sesiones por día, semana,
mes o independientemente del período de tiempo es apropiado).
· La longitud de una sesión de aplicación media.
· El número de usuarios simultáneo de una aplicación.

Armado con la información en la frecuencia y la longitud de sesiones, y el número de


sesiones simultáneas, usted puede predecir más exactamente la exigencia de ancho de
Practicas Pre Profesionales II UPAO

banda agregada para todos los usuarios de una aplicación. Si no es práctico investigar
estos detalles, usted puede hacer algunas conclusiones:
· Usted puede asumir que el número de usuarios de una aplicación es igual al número
de usuarios simultáneos.
· Usted puede asumir que todas las aplicaciones son usadas todo el tiempo de modo
que su cálculo de ancho de banda sea un caso pico de estimación (máxima).
· Usted puede asumir que cada usuario abre sólo una sesión y que una sesión dura
todo el día hasta que el usuario cierre la aplicación al final de día.

Refinando Estimaciones de Carga de Tráfico causada por Aplicaciones


Para refinar la estimación de requerimientos de aplicación ancho de banda, usted tiene que
investigar el tamaño de objetos de datos enviados por aplicaciones, la sobrecarga causada
por capas de protocolo, y cualquier carga adicional causada por la inicialización de
aplicación. (Algunas aplicaciones envían mucho más tráfico durante la inicialización que
durante la operación estable.)

Como las aplicaciones y los usuarios varían extensamente en el comportamiento, es difícil


estimar exactamente el tamaño medio de objetos de datos que los usuarios transfieren el
uno al otro y a servidores. (La respuesta de ingeniería verdadera a la mayor parte de
preguntas relacionadas para conectar a la red tráfico es "esto depende.") el cuadro siguiente
proporciona algunas estimaciones para tamaños de objeto que usted puede usar haciendo
cálculos atrás de la carga de tráfico de aplicación, pero recordar que el cuadro
proporcionado no toma el lugar de un análisis cuidadoso del comportamiento de aplicación
actual.

Tabla Nro. 08 Tamaño Aproximado de Objetos de Transferencia de Aplicaciones a


través de redes
Practicas Pre Profesionales II UPAO

La Estimación de Sobrecarga de Tráfico para Varios Protocolos


La sección anterior habló de la caracterización de la carga de tráfico de aplicación mirando
el tamaño de objetos de datos que las aplicaciones transfieren a través de redes. Para
caracterizar completamente el comportamiento de aplicación, usted debería investigar qué
protocolos usa una aplicación. Una vez que usted sabe los protocolos, usted puede calcular
la carga de tráfico más exactamente añadiendo el tamaño de cabecera de protocolo al
tamaño de objetos de datos.

Tabla Nro. 09 de Sobrecarga de Tráfico para varios Protocolos

La Estimación de Carga de Tráfico Causada por Inicialización de Sesión y Estación de


Trabajo
Según las aplicaciones y protocolos que usa una estación de trabajo, la inicialización de
estación de trabajo puede causar una carga en redes debido al número de paquetes y, en
algunos casos, el número de paquetes de broadcast. Aunque este se haga menos de un
problema cuando el ancho de banda de red se ha hecho con estaciones de trabajo con
CPUs rápidas y baratas, que hará de modo que el procesamiento transmitido no sea una
preocupación.

La Estimación de Carga de Tráfico Causada por Protocolos de Enrutamiento


En este punto en el proceso de diseño de red, usted no podría haber seleccionado
protocolos de encaminamiento para el nuevo diseño de red, pero usted debería haber
identificado protocolos de encaminamiento que corren en la red existente. Ayudarle a
caracterizar tráfico de red causado por protocolos de enrutamiento, Tabla le mostrara la
Practicas Pre Profesionales II UPAO

cantidad de ancho de banda usada por herencia de protocolos de enrutamiento


vector-distancia.

Tabla Nro. 10 Ancho de banda Usada por Herencia de Protocolos de enrutamiento

Un router envía largas tablas de enrutamiento de vector-distancia que cada minuto puede
usar un porcentaje significativo del ancho de banda de la WAN. Como el protocolo de
encaminamiento limita el número de rutas por paquete, en redes grandes, un router de
tráfico envía paquetes múltiples para enviar la tabla entera.

Los nuevos protocolos de encaminamiento, como OSPF y EIGRP, usan ancho de banda
muy pequeña. En caso de OSPF, su preocupación principal debería ser la cantidad de
ancho de banda consumida por los paquetes de sincronización de base de datos que los
routers de tráfico envían cada 30 minutos. Subdividiendo una red de OSPF en áreas y
usando la ruta sumarizada, este tráfico puede ser minimizado. Otro tráfico de sincronización
de base de datos, es el único tráfico que OSPF envía después de la inicialización es
pequeño paquete Hello cada 10 segundos.

El EIGRP también envía paquetes Hello, pero con más frecuencia que OSPF (cada 5
segundos). Por otra parte, EIGRP no envía ninguna actualización de ruta periódica o
paquetes de sincronización de base de datos. Esto sólo envía actualizaciones de ruta
cuando hay cambios en la topología.

Caracterización del Comportamiento del Tráfico


Seleccionar una apropiada solución de diseño de red, usted tiene que entender el protocolo
y el comportamiento de las aplicaciones además de flujos de tráfico y carga. Por ejemplo,
para seleccionar topologías apropiada de LAN, usted tiene que investigar el nivel del tráfico
de broadcast en la LAN. Para aprovisionar la capacidad adecuada para LAN y WAN, usted
tiene que chequear la utilización extra de ancho de banda causada por protocolos
ineficientes y tamaños de paquetes no óptimos o retransmisión de temporizadores.
Practicas Pre Profesionales II UPAO

Comportamiento de Broadcast/Multicast
Un paquete de broadcast que va a todas las estaciones de red en un LAN. En la capa de
enlace de datos, la dirección de destino de un paquete de broadcast es FF:FF:FF:FF:FF:FF
(todos 1s en el binario). A paquete de multicast es un paquete que va a un subconjunto de
estaciones. Por ejemplo, un paquete destinado a 01:00:0C:CC:CC:CC va a routers de
tráfico Cisco e switches que dirigen el Protocolo de Descubrimiento Cisco (CDP) en un LAN.

Los dispositivos de capa 2 , como switches y bridge, envian los paquetes de broadcast y
multicast a todos los puertos. El envió de paquetes de broadcast y multicast puede ser un
problema de escalabilidad para grandes edificaciones de (switches o bridge) redes. Un
router no envia tráfico de broadcast o multicast. Todos los dispositivos en un lado de un
router son considerados la parte de un solo dominio de bradcast.

Además de la inclusión de routers en el diseño de una red disminuira el transporte de


broadcast, usted también puede limitar el tamaño de un dominio de broadcast poniendo en
práctica LAN virtuales (VLANs). Tecnología de VLAN, que en la sección, "El diseño de una
Topología de Red," habla más detalladamente, permite que un administrador de red
subdivida a usuarios en subredes asociando puertos del switch con uno o varios VLANs.
Aunque un VLAN pueda atravesar muchos switches, el tráfico de broadcast dentro de un
VLAN no es transmitido fuera del VLAN.

Demasiados paquetes de broadcast pueden abrumar estaciones finales, switches, y routers.


Es importante que usted investigue el nivel del tráfico de broadcast en su diseño propuesto y
limite el número de estaciones en un simple dominio de broadcast. El término radiación de
broadcast a menudo es usado para describir el efecto de broadcast que se extienden del
remitente a todos los dispositivos en un dominio de broadcast. La radiación de broadcast
puede degradar la performance en estaciones de red.

La tarjeta de interfaz de red (NIC) con una estación de red pasa broadcast y multicast
relevantes a la CPU de la estación. Algunos NICs pasan todas las multicast a la CPU, aun
cuando las multicast no son relevantes, porque las NICs no tienen el software de conductor
que es más selectivo. El software de conductor inteligente puede decir una NIC que
multicast pasa a la CPU. Lamentablemente, no todos los conductores tienen esta
inteligencia. Las CPUs en las estaciones de red se hacen abrumadas tratando de procesar
niveles altos de broadcast y multicast. Si más del 20 por ciento del tráfico de red es
broadcast o multicast, la red tiene que ser segmentada usando routers o VLANs.

Otra causa posible del pesado tráfico de broadcast es la tormenta de broadcast causada por
intermitencias en la red o estaciones de red caídas. Por ejemplo, una máscara de
Practicas Pre Profesionales II UPAO

subred de mal asignada puede hacer que una estación envíe paquetes de ARP
innecesariamente porque la estación no se distingue correctamente entre estación y direcciones
de broadcast, haciéndolo enviar ARPs para direcciones de broadcast.

En general, sin embargo, el tráfico de broadcast es necesario e inevitable. El encaminamiento y


la conmutación de protocolos usan broadcast y multicast para compartir la información sobre la
topología de la red. Los servidores envían broadcast y multicast para anunciar sus servicios. Los
protocolos de escritorio como AppleTalk, NetWare, NetBIOS, y TCP/IP requieren de paquetes de
broadcast y multicast para encontrar los servicios y chequear para la autenticarse de direcciones
y nombres.

Cuando diseñamos una topología de red, se cubrirá en secciones mas adelante mas
detalladamente, mostramos una tabla de recomendaciones para limitar el número de estaciones
en un dominio de broadcast solo basada en el protocolo (s) de escritorio en uso.

Tabla Nro. 11 Tamaño Máximo en un Dominio de Broadcast

Eficacia de Red
La caracterización del comportamiento de tráfico de red requiere la ganancia de un entendimiento
de la eficacia de las nuevas aplicaciones de red. Eficacia se refiere a si las aplicaciones y los
protocolos usan el ancho de banda con eficacia. La eficacia es afectada por el tamaño del
paquete, la interacción de protocolos usados por una aplicación, windowing y control de flujo, y
mecanismos de recuperación de error.

Tamaño del Paquete


Usando un tamaño de paquete que es el máximo apoyo para el medio en uso tiene un impacto
positivo en la performance de red para aplicaciones de bulk. Para aplicaciones de transferencia
de archivo, en particular, usted debería usar la unidad máxima de transmisión más grande
posible (MTU). Según las pilas de protocolo que su cliente
Practicas Pre Profesionales II UPAO
usará en el nuevo diseño de red, el MTU puede ser configurado para algunas aplicaciones.

En un ambiente IP, usted debería evitar aumentar el MTU más de lo soportado, evitar la
fragmentación y reensamblación de paquetes. Cuando los dispositivos al final de los nodos
o routers tienen que fragmentar y volver a reensamblar paquetes, la performance se
degrada.

Los sistemas operativos modernos soportan el descubrimiento del MTU. Con el


descubrimiento MTU, el software puede descubrir dinámicamente y usar el tamaño más
grande del paquete que cruzará la red sin requerir la fragmentación. El descubrimiento de
MTU generalmente trabaja, pero hay algunos problemas con ello como mencionamos en el
"Análisis de Eficacia de Red".

Interacción de Protocolo
La ineficiencia en redes no es causada sólo por pequeños tamaños de paquetes. La
ineficiencia también es causada por la interacción de protocolos y la no correcta
configuración de temporizadores de reconocimiento y otros parámetros.

Windowing y Control de Flujo


Para entender realmente el tráfico de red, usted tiene que entender el control de flujo y
windowing. Un dispositivo TCP/IP, por ejemplo, envía segmentos (paquetes) de datos en
secuencia rápida, sin esperar un reconocimiento, hasta que su envío de ventana ha sido
agotado. Una estación envía la ventana está basado en el recipiente que reciba la ventana.
El estado del recipiente en cada paquete TCP determina cuantos datos está listo para
recibir. Este total puede variar de unos bytes hasta 65,535 bytes. El recipiente de ventana
está basado en cuanta memoria el receptor tiene y que tan rápido procesa los datos
recibidos. Usted puede optimizar la eficacia de red aumentando la memoria y el poder de
CPU en las estaciones finales, el cual pueden causar ventanas de recipiente grande.

Algunas aplicaciones TCP/IP corren encima de UDP, y no TCP. En este caso, no


hay ningún control de flujo o el control de flujo es manejado en la sesión o capa de
aplicación. Mostramos una lista para determinar qué protocolos están basados en
TCP y qué protocolos están basados en UDP:
· Protocolo de transferencia de archivos (FTP): Puerto de TCP 20 (datos) y puerto
TCP 21 (control).
· Telnet: Puerto de TCP 23.
· Protocolo de Transferencia Postal Simple (SMTP): Puerto de TCP 25.
Practicas Pre Profesionales II UPAO

· Protocolo de Transferencia de Hipertexto (HTTP): Puerto de TCP 80.


· Protocolo de Dirección de Red Simple (SNMP): Puertos de UDP 161 y 162.
· Sistema de Nombre de Esfera (DNS): Puerto de UDP 53.
· Protocolo de Transferencia de Archivos Trivial (TFTP): Puerto de UDP 69.
· Servidor de DHCP: Puerto de UDP 67.
· Cliente de DHCP: Puerto de UDP 68.
· Llamada de Procedimiento Remota (RPC): Puerto de UDP 111

Mecanismos de Recuperación de error


Los mecanismos de recuperación de error mal diseñados pueden gastar el ancho de banda.
Por ejemplo, si un protocolo retransmite de nuevo datos muy rápidamente sin esperar un
periodo de tiempo para recibir un reconocimiento, este puede causar la degradación del
performance para el resto de la red debido al ancho de banda usada.

Los protocolos de baja conexión por lo general no ponen en práctica la recuperación de


error. Mayormente en la capa de enlace de datos y los protocolos de capa de red son de
baja conexión. Algunos protocolos de capa de transporte, como UDP, son de baja conexión.

Los mecanismos de recuperación de error para protocolos orientados por conexión varían.
TCP implementa un algoritmo de nuevo de retransmisión adaptable, el que significa que el
ratio de nuevas retransmisiones se reduce cuando la red esta congestionada, el cual
optimiza el uso del ancho de banda.

Las nuevos implementaciones TCP también ponen en práctica ACK selectivo (SACK), esta
descrito en el RFC 2018. Sin el SACK, esta predispuesto al error, los altos caminos de
tardanza pueden experimentar que el rendimiento baje debido al camino que TCP reconoce
datos. Los reconocimientos de TCP (ACKs) son acumulativos hasta el punto donde un
problema ocurre. Si los segmentos pierden el número de ACK es uno más que el número
del último byte que fue recibido antes de la pérdida, aun si más segmentos llegaran después
de la pérdida. No hay ningún camino para el receptor para recibir algún reporte de un
agujero en los datos recibidos. Este hace que el remitente espere un tiempo de ida y vuelta
para averiguar sobre cada segmento perdido, o retransmita de nuevo innecesariamente
segmentos que el recipiente puede haber recibido correctamente.

Con el mecanismo de SACK, el recipiente TCP rellena el campo de opción de SACK en la


cabecera TCP para informar al remitente de los bloques no contiguos de datos que han sido
recibidos. El remitente puede retransmitir de nuevo entonces sólo los segmentos ausentes.
RFC 2018 define una opción TCP para rellenar los números de
Practicas Pre Profesionales II UPAO

secuencia recibida para bloques y otra opción TCP para informar al recipiente durante el
apretón de manos de tres caminos que el host soporta SACK.

Caracterizando los Requerimientos de Calidad de Servicio


El análisis de los requerimientos de tráfico de red no es completamente tan simple como
identificando flujos, midiendo la carga para flujos, y caracterizando el comportamiento de
tráfico como de broadcast y de comportamiento error. Usted también tiene que caracterizar
los requerimientos QoS para aplicaciones.

Sólo conociendo los requerimientos de carga (ancho de banda) para una aplicación no es
suficiente. Usted también tiene que conocer si los requerimientos son flexibles o inflexibles.
Algunas aplicaciones siguen trabajando (aunque despacio) cuando el ancho de banda no es
suficiente. Otras aplicaciones, como voz y aplicaciones de vídeo, son dadas inútiles si un
cierto nivel del ancho de banda no está disponible. Además, si usted tiene una mezcla de
aplicaciones flexibles e inflexibles en una red, usted tiene que determinar si es práctico
tomar prestada el ancho de banda de la aplicación flexible para guardar el funcionamiento
de aplicación inflexible.

La voz es también inflexible en cuanto a la tardanza. La voz es también sensible a la pérdida


de paquete, que resulta en recorte de periódico de voz y se salta. Sin la configuración
apropiada en toda la red de QoS, la pérdida puede ocurrir debido a enlaces congestionados
y un pobre buffer de paquetes y manejo de dirección de cola en los routers.

Siguiendo esta sección siguiente que analiza los requerimientos de QoS usando ATM e
Internet la técnica Engineering Task Force (IETF). El objetivo de estas secciones es
introducirle en la terminología del ATM y IETF que los ingenieros usan para clasificar el
tráfico y especificar los requerimientos de QoS por clases de tráfico. Aunque el material sea
muy altamente técnico y detallado, esto debería darle alguna idea fundamental sobre la
clasificación de los tipos de aplicaciones que jugarán una parte en su diseño de red y estar
preparado para futuros capítulos que cubren estrategias de diseño y optimización de redes
que pueden encontrar las necesidades de varias aplicaciones.

Calidad de ATM de Especificaciones de Servicio


En su documento "Especificación del Manejo de Trafico la Versión 4.1” el Forum de ATM
hace un trabajo excelente de clasificar los tipos de servicio que una red puede ofrecer para
soportar diferentes clases de aplicaciones. Incluso si su cliente no tiene ningunos proyectos
de usar la tecnología del Modo de Transferencia Asincrónico (ATM), la terminología del Foro
de ATM es todavía provechosa porque esto identifica los diferentes parámetros que las
clases de aplicaciones deben especificar para solicitar un
Practicas Pre Profesionales II UPAO

cierto tipo del servicio de red. Estos parámetros incluyen tardanza y variación del tamaño de
tardanza, pérdida de datos, y picos de tráfico máximo, sostenible, y mínimos. Aunque usted
debiera sustituir la palabra celda con paquete en algunos casos, las definiciones de Foro de
ATM pueden ayudarle a clasificar aplicaciones en cualquier red, hasta redes que no son
ATM.

El Foro de ATM define seis categorías de servicio, cada uno de las cuales es descrito más
detalladamente en esta sección:
· Velocidad binaria constante (CBR)
· Velocidad binaria variable de tiempo real (rt-VBR)
· Velocidad binaria variable no tiempo real (nrt-VBR)
· Velocidad binaria no especificada (UBR)
· Velocidad binaria disponible (ABR)
· Precio de marco garantizado (GFR)

Para cada categoría de servicio, el Foro de ATM especifica un juego de parámetros para
describir tanto tráfico presente en la red como el QoS requerido de la red. El Foro de ATM
también define mecanismos de control de tráfico que la red puede usar para encontrar
objetivos QoS. La red puede implementar tales mecanismos de conexión de control de
admisión y asignación de recurso diferentes para cada categoría de servicio.

Las categorías de servicio son distinguidas al comienzo siendo tiempo real o tiempo no real.
El CBR y rt-VBR son categorías de servicio de tiempo real. Las aplicaciones de tiempo real,
como voz y aplicaciones de vídeo, requieren la variación de tardanza y tardanza
fuertemente obligada. Las aplicaciones en tiempo no real, como cliente/servidor y
aplicaciones de datos de terminal/host, no requieren la tardanza fuertemente obligada y
retrasan la variación. El Nrt-VBR, UBR, ABR, y GFR son categorías de servicio tiempo no
real.

Categoría de Servicio de Velocidad Binaria Constante


Cuando CBR es usado, unos recursos de reservas de red del final del sistema de la fuente y
pregunta por una garantía QoS negociado es asegurado a todas las celdas mientras las
celdas se conforman a las pruebas de conformidad relevantes. La fuente puede emitir
celdas en el pico de celda máximo (PCR) en cualquier momento y para cualquier duración y
los compromisos QoS deberían pertenecer. El CBR es usado por aplicaciones que
necesitan la capacidad de solicitar que una cantidad estática del ancho de banda estuviera
continuamente disponible durante una conexión de por vida. La cantidad de ancho de banda
que una conexión requiere es especificada por el valor de PCR.
Practicas Pre Profesionales II UPAO

El servicio de CBR intenta soportar aplicaciones de tiempo real que requieren la variación de
tardanza fuertemente obligada (por ejemplo, la voz, el vídeo, y la emulación de circuitos),
pero no es restringido a estas aplicaciones. La fuente puede emitir celdas debajo de PCR
negociado o ser silenciosa durante períodos del tiempo. Se asume que celdas que son
retrasadas más allá del valor especificado por la tardanza de transferencia de parámetros de
celdas máxima (maxCTD) son del valor considerablemente reducido a la aplicación.

Categoría de Servicio de Velocidad Binaria Variable Tiempo no real


La categoría de servicio nrt-VBR es requerida para aplicaciones de tiempo no real que
tienen características de tráfico bursty. El servicio es caracterizado en términos de PCR,
SCR, y MBS. Para celdas que son transferidas dentro del contrato de tráfico, la aplicación
espera una proporción baja de pérdida de celdas (CLR). El servicio de nrt-VBR puede

Servicio de Control de Carga


El Servicio de control-Carga es definido en RFC 2211 y provee a un cliente un flujo de datos
con QoS que se aproxima al QoS este mismo flujo recibiría una descarga en la red. El
control de admisión es aplicado a los requisitos de servicio solicitado y es recibido aun
cuando la red esta sobrecargada.

El Servicio de Control-Carga es requerido para aplicaciones que son muy sensibles a


condiciones sobrecargadas, como aplicaciones de tiempo real.

Estas aplicaciones trabajan bien en redes descargadas, pero degradan rápidamente en


redes sobrecargadas. Un servicio, como el Control-Carga que imita redes descargadas sirve
estos tipos de aplicaciones bien.

Asumiendo que la red funciona correctamente, un servicio de control-carga esta solicitando


de la aplicación puede asumir lo siguiente:
· Un alto porcentaje de paquetes transmitidos será recepcionados con éxito al final
de los nodos de la red. (El porcentaje de paquetes que no es entregado con éxito
debe aproximarse al índice de errores de paquete básico del medio de transmisión.)
· La tardanza de tránsito experimentada por un porcentaje muy alto de los paquetes
entregados no excederá el mínimo transmitido en la tardanza experimentada por
cualquier paquete con éxito entregado. (Esta tardanza de tránsito mínima incluye la
tardanza de velocidad de luz más el tiempo de procesamiento fijo en routers y otros
dispositivos de comunicaciones a lo largo del camino.)
Practicas Pre Profesionales II UPAO

El servicio de control-carga no acepta o hace el uso de valores objetivo específicos para


parámetros como tardanza o pérdida. En cambio, la aceptación de una petición del servicio
de control-carga implica un compromiso por el nodo de red para proveer el requester del
servicio estrechamente equivalente con esto proporcionado a incontrolado (mejor esfuerzo)
tráfico en condiciones ligeramente cargadas.

Un nodo de red que acepta una petición del servicio de control-carga debe usar funciones
de control de admisión para asegurar que los recursos adecuados están disponibles para
manejar el nivel solicitado del tráfico, como definido por las solicitudes TSpec . Los recursos
incluyen el ancho de banda del, router o el espacio del bufer-puerto del switch, y la
capacidad computacional del motor que avanza el paquete.

Servicio Garantizado
El RFC 2212 describe el comportamiento requerido del nodo de red llamado a entregar un
servicio garantizado esta características garantiza tanto la tardanza como ancho de banda.
El servicio garantizado proporciona la firma (matemáticamente probable) en la tardanzas de
punta a punta que hacen cola paquete. Esto no intenta minimizar la inquietud y no está
preocupado por reparar la tardanza, como la tardanza de transmisión. (Reparar la tardanza
es una propiedad del camino elegido, que es determinado por el mecanismo de sistema,
como RSVP.)

El servicio garantizado garantiza que los paquetes llegarán dentro del plazo de entrega
garantizado y no serán descartado debidos a desbordamientos, condición de que el tráfico
del flujo es conformado por TSpec. Una serie de nodos de red que ponen en práctica la
implementación del RFC 2212 esta asegura un nivel de ancho de banda, cuando es usado
por un flujo regulado, produce un servicio salto-tardanza sin la pérdida de cola (asumiendo
que no falla ningún componentes de red o cambios de la encaminamiento durante la vida
del flujo).

El servicio garantizado es requerido para aplicaciones que necesitan una garantía que un
paquete no llegará más tarde que un cierto tiempo después de que fue transmitido por su
fuente. Por ejemplo, algunas aplicaciones de repetición de audio y de vídeo son intolerantes
de un paquete que llega después de su tiempo de repetición esperado. Las aplicaciones que
tienen exigencias de tiempo real también pueden usar el servicio garantizado.

El ratio es medido en bytes de datagramas IP por segundo, y puede extenderse de 1 byte


por segundo a tan grande como 40 TB por segundo (el ancho de banda teórica máxima de
solo un hilo de fibra). El tamaño del paquete puede extenderse de 1 byte a 250 GB. El rango
de valores es intencionadamente grande para tener en cuenta futuras
Practicas Pre Profesionales II UPAO

anchos de banda. El rango no intenta implicar tanto a un nodo de red tiene que soportar el
rango de la red entera.

La expectativa del grupo de funcionamiento de Servicios Integrado consiste en que un


revelador de software puede usar RFCs relevante para desarrollar aplicaciones inteligentes
que pueden poner exactamente el ratio de paquete y el tamaño. Una aplicación por lo
general puede estimar exactamente la tardanza esperada que hace cola que el servicio
garantizado proporcionará. Si la tardanza es más grande que esperado, la aplicación puede
modificar su paquete simbólico para conseguir una tardanza inferior.

Como un diseñador de red, no le visitarán generalmente para estimar ratios de paquete


simbólico y tamaños. Por otra parte, usted debería reconocer qué necesidad de aplicaciones
garantizada el servicio y tienen alguna idea de su comportamiento de falta y si una
reconfiguración del comportamiento de falta es posible. Si una aplicación puede solicitar el
ancho de banda de terabytes por segundo, usted tiene que saber este debido al efecto
negativo que esto podría tener en otras aplicaciones.

Documentación Requerimientos de QoS


Usted debería trabajar con su cliente para clasificar cada aplicación de red en una categoría
de servicio. Una vez que usted ha clasificado la aplicación, usted debería rellenar "la
columna" de Requerimientos de QoS en la Tabla Nro. 07

Si su cliente tiene aplicaciones que pueden ser caracterizadas como necesitando la


controla-carga o el servicio garantizado, usted puede usar aquellos términos rellenando "la
columna" de Requerimientos de QoS. Si su cliente planea usar el ATM, usted puede usar la
terminología del Foro de ATM para categorías de servicio. Incluso si su cliente no planea
usar el ATM o IETF QoS, usted todavía puede usar el Foro de ATM o la terminología de
grupo de funcionamiento de Servicios Integrada. Otra alternativa debe usar simplemente los
términos inflexible y flexible. Inflexible es una palabra genérica para describir cualquier
aplicación que tiene exigencias específicas para ancho de banda constante, tardanza,
variación de tardanza, exactitud, y rendimiento. Flexible, por otra parte, es un término
genérico para aplicaciones que simplemente esperan que la red haga el un mejor esfuerzo
para encontrar los requerimientos. Muchas aplicaciones no multimedia tienen requerimientos
de QoS flexibles.

Para aplicaciones de voz, usted debería hacer más de una entrada en Tabla Nro. 07 debido
a los requerimientos diferentes de flujo de control de llamada y la corriente de audio. El flujo
de control de llamada, se usa para establecer llamadas perdidas, no tiene coacciones de
tardanza estrictas, pero esto requiere una alta disponibilidad de red y
Practicas Pre Profesionales II UPAO

puede haber un requerimiento GoS que debería ser especificada. Para la corriente de voz,
la clasificación QoS debería ser puesta en una lista usando el término de ATM o el término
de IETF servicio garantizado.

Resumen de Identificando objetivos y necesidades del cliente


En este punto en el proceso de diseño de red, usted ha identificado las aplicaciones de red
de un cliente y los requerimientos técnicas para un diseño de red que puede apoyar las
aplicaciones.

Este resume, "Identificando las Necesidades de Su Cliente y Objetivos." La Fase de análisis


de requerimientos es la fase más importante en el diseño red de la metodología top down.
La ganancia de un entendimiento sólido de los requerimientos de su cliente le ayuda a
seleccionar tecnologías que encuentran los criterios de un cliente para el éxito.

Usted debería ser capaz ahora de analizar los objetivos comerciales y técnicos de un cliente
y estar listo a comenzar a desarrollar un diseño de red lógico y físico. "Diseño de Red
Lógico," que diseñan una topología de red lógica, desarrollando el direccionamiento de capa
de red y nombramiento del modelo, selección de switches y de protocolos de enrutamiento,
y planificación de seguridad de red y estrategias de dirección.

Potrebbero piacerti anche