Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
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 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.
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.
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.
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
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.
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.
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.
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.
UTP categoría 5
Cable coaxial
Microondas
Radiofrecuencia.
Láser
Infrarrojo
Practicas Pre Profesionales II UPAO
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.
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).
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
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.
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.
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
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.
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
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.
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
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.
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.
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.
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
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.
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
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.
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.
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
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.
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.
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.
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).
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
anchos de banda. El rango no intenta implicar tanto a un nodo de red tiene que soportar el
rango de la red entera.
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.
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.