Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
Hay dos problemas relacionados con el control de admisión. Primero, ¿cómo encontrar un
algoritmo que pueda decidir si un determinado paquete es conforme o no, y segundo, qué hacer
con los paquetes no conformes? La mayoría de los algoritmos de control de admisión se basan
en el sistema de cubo de testigos (véase el párrafo 6.5.1.1).
Existen diferentes tipos de filtros que pueden ayudar a clasificar los paquetes no conformes, y
cada uno de ellos tiene diferentes efectos en el tráfico (ver Figura 6.10):
Figura 6.10 Formación y vigilancia del tráfico de usuarios. (a) Cuando se forma el tráfico, no se
caen los paquetes, pero algunos de ellos pueden ser retrasados. (B) Cuando el tráfico es vigilado,
nunca se retrasa, pero algunos paquetes pueden caerse.
Policers son filtros que descartan todos los paquetes no conformes, debido a eso la
información original no se conserva por completo, pero la temporización no se ve
afectada, por lo que los paquetes no se retrasan. Los policers están adaptados a
aplicaciones tolerantes a errores que tienen estrictas restricciones de tiempo, por
ejemplo VoIP o aplicaciones de vídeo interactivo.
Shapers (formadores) trabajan casi de la misma manera que los policers, pero no
descartan paquetes. El tráfico no conforme se almacena en un buffer y se retrasa hasta
que se puede enviar sin alterar el acuerdo SLA o comprometer recursos de red. Los
shapers conservan toda la información que se envió, pero modifican el tiempo, por lo
que pueden causar problemas para las comunicaciones interactivas en tiempo real.
Markers (marcadores) pueden utilizarse para tratar paquetes no conformes (ver párrafo
6.3). En lugar de eliminar o retrasar paquetes no conformes, se entregan con baja
prioridad o "mejor esfuerzo".
Policers, shapers y markers se pueden combinar para obtener filtros más complejos que tienen
propiedades muy interesantes. Por ejemplo, podría haber un filtro de control de admisión que
actúe como un policer en situaciones donde el SLA es fuertemente alterado, pero en el caso de
alteraciones eventuales o no persistentes, el filtro envía paquetes no conformes - sin garantías
de QoS , por supuesto.
Figura 6.11 Token bucket utilizados en el control de admisión: (a) Token bucket que funciona
como un policer. (B) Token bucket trabajando como shaper.
El (srTCM) policer es obtenido por encadenamiento de dos simples token bucket policers
(Ver Figura 6.12). Los tokens llenan el bucket principal hasta que alcancen la capacidad dada por
el Committed Burst Size (CBS), a una tasa dada por el Committed Information Rate (CIR). Los
tokens adicionales en el bucket principal no se ignoran, pero se usan para rellenar un bucket
secundario hasta que alcancen la capacidad dada por el parámetro Excess Burst Size (EBS).
Figura 6.12 Marcador de tres colores de una tasa simple.
El tráfico que pasa a través del primer bucket (tráfico verde) se entrega con la QoS acordada con
el proveedor de servicios, pero cualquier tráfico que pasa a través del bucket secundario (tráfico
amarillo) suele ser reclasificado y entregado como tráfico de mejor esfuerzo, se le da una baja
prioridad. El tráfico no conforme (tráfico rojo) es eliminado.
El srTCM puede ser considerado como una versión más sofisticada de la simple token bucket
policer. Algunos tráficos no conformes que serían eliminados se pueden recuperar usando
srTCM.
El algoritmo (trTCM) es una versión modificada del srTCM que incluye un nuevo parámetro de
configuración, el Excess Information Rate (EIR). La diferencia entre los dos es que con trTCM, el
exceso de tokens del bucket principal no se utiliza para llenar el bucket secundario, pero el
bucket secundario se llena con un nuevo flujo de token a una velocidad dada por el parámetro
EIR (véase la figura 6.13) .
En la práctica, la única diferencia importante es que el trTCM permite un control más preciso
del tráfico amarillo mediante el parámetro EIR.
Las redes de conmutación de circuitos clásicas pueden aceptar un número límite de llamadas
simultáneas. Si se excede ese número, la red no estará disponible para las nuevas llamadas. Los
llamantes existentes no notan ningún cambio en la calidad del servicio. Cuando la red no está
disponible se dice que está bloqueada.
En redes tradicionales de conmutación de paquetes, la situación es diferente. Cuando la carga
de tráfico es pequeña, estas redes siguen siendo predecibles y proporcionan un buen
rendimiento. Pero el QoS se degrada rápidamente cuando hay más carga de tráfico.
Las tecnologías basadas en VC, por ejemplo ATM, pueden proporcionar potencialmente el
mismo nivel de servicio que cualquier otra red de conmutación de circuitos, manteniendo al
mismo tiempo una alta flexibilidad. Los CV también tienen algunas desventajas, porque
necesitan:
Las redes IP no están orientadas a circuitos debido a razones de diseño. Estas redes entregan
toda la información necesaria a su destino en el encabezado del paquete, estos paquetes se
llaman datagramas. Las redes de conmutación de paquetes basadas en datagramas son simples
y escalables, pero no son la mejor solución posible para transportar voz y vídeo.
Cuando los usuarios de una red IP necesitan comunicaciones orientadas a la conexión, utilizan
TCP, en donde presenta reordenamiento de paquetes, detección de errores, re-transmisión de
paquetes con error, control de flujo y otras características, pero no puede establecer ningún VC
en la red. Las conexiones TCP residen en el equipo del usuario final. La red no es consciente de
ellos. Las comunicaciones orientadas a la conexión a través de la red IP serían deseables, pero
esto no es posible sin cambiar el diseño fundamental del protocolo IP. Actualmente existen dos
opciones principales para ofrecer una transmisión orientada a circuitos sobre IP:
Figura 6.14 Cómo actúa la gestión de recursos: (a) Sin gestión de recursos, todos los usuarios
experimentan degradación en sus aplicaciones siempre que hay congestión en la red. (b) Si
se utiliza la gestión de la congestión, sólo algunos abonados no
permiten enviar datos, pero los demás no se ven afectados.
En una red de conmutación de paquetes, un enlace se congestiona cada vez que la cantidad de
tráfico inyectado excede su capacidad de transmisión. La primera consecuencia de esto es que
el exceso de paquetes necesita ser almacenados en buffer. Esto puede dañar la QoS de las
comunicaciones multimedia en tiempo real. Si la congestión es severa, los búferes pueden estar
sobrecargados y causar la pérdida de paquetes, dañando los datos como las comunicaciones
multimedia. El correcto marcado de paquetes y la programación ayudan a hacer frente a
cualquier daño causado por los retrasos de cola. La diferenciación del tráfico está relacionada
con el control de la congestión. Para hacer frente a los efectos de la pérdida de paquetes, es
necesario implementar políticas de eliminación de paquetes (PDP) para elementos de red. Las
características ideales de un buen PDP son:
Eficiencia. Un buen PDP debe mantener alta la utilización de la red. Eliminar paquetes
fragmentados podría reducir la eficiencia. ATM fragmenta los datagramas IP antes de
transmitirlos, pero no hay mecanismo para recuperar una celda ATM perdida de error.
Esto hace necesario solicitar la transmisión de todo el datagrama IP en el destino. Los
fragmentos que llegan sin errores no son utilizables, pero desperdician los recursos de
transmisión. Para evitar este problema, el PDP para las celdas ATM debe ser consciente
de la fragmentación de los paquetes IP y de la caída de celdas, problemas similares
ocurren a nivel de flujo. Algunos flujos pueden no ser utilizables, si algunos paquetes se
pierden, por lo que tiene sentido caer flujos enteros. Para el caso particular de TCP, un
PDP que no considera conexiones TCP puede causar subutilización de red. Una sola
pérdida de paquetes en un flujo TCP provocaría la activación del mecanismo de evitación
de congestión TCP y TCP reduciría la velocidad de transmisión para esa conexión. Si esto
sucede a muchas conexiones TCP al mismo tiempo, puede conducir a la subutilización
de la red (problema de sincronización global). Siguiendo el mismo razonamiento, tendría
sentido descartar primero los paquetes que han atravesado un número menor de saltos.
Equidad. No debe haber más flujos privilegiados que los permitidos por el proveedor de
servicios. Además, todos los flujos deben tener las mismas posibilidades estadísticas de
ser transmitidos sin pérdida de paquetes. Si la "injusticia" es decidida por el proveedor
de servicios, debería ser posible controlar el nivel de "injusticia".
Simplicidad. Como los elementos de la red suelen cambiar el tráfico a tasas altas, es
necesario tener un PDP tan simple como sea posible. Hay un equilibrio entre eficiencia
y simplicidad mientras más eficiente e inteligente sea un PDP, más complejo es.
Escalabilidad. Los PDP deben prepararse para el crecimiento rápido de las redes
actuales. La escalabilidad tiende a ser un problema para aquellos PDP que almacenan
información de conexión.
La caída de la cola (DT) es el más simple, pero no siempre el mejor PDP. Acepta paquetes cuando
hay espacio en el búfer y cuando no, elimina todos los paquetes entrantes.
El DT PDP es muy escalable, porque es simple, pero tiene algunos problemas de eficiencia y
equidad. Aunque el DT puede ser aceptado en redes con cargas muy ligeras, no se recomienda
cuando se espera alto nivel de utilización. De hecho, se ha demostrado que en este caso el DT
puede cerrar completamente el sistema.
El DT está sesgado en contra de los flujos con poca cantidad de tráfico, y algunos flujos de alta
tasa tienden a obtener la mayor parte de los recursos del sistema. El DT PDP no toma paquetes
fragmentados o flujo de paquetes. Los grandes paquetes tienen una probabilidad menor de
pasar a través del policer que los mensajes cortos cuando están fragmentados. Además, se ha
demostrado que el protocolo TCP presenta un bajo rendimiento cuando se utiliza DT.
Se ha propuesto el PDP de Descarte de Paquetes Parciales (PPD) para las redes ATM, para
mejorar el rendimiento del DT. La mejora consiste en que el PPD tiene que soltar un fragmento
de paquete, además descarta todos los fragmentos posteriores que pertenecen al mismo
paquete. Esto ahorra espacio de almacenamiento para otros paquetes, pero algunos fragmentos
que no son utilizables todavía se reenvían. En promedio, se entrega una mitad de los fragmentos
inutilizables, lo que significa que es posible mejorar aún más este PDP.
El PDP de Early Packet Discard (EPD) es una mejora alternativa para el DT en redes ATM. El buffer
con EPD no acepta más paquetes cuando supera un cierto umbral configurable. Sin embargo,
los fragmentos de los paquetes ya aceptados antes de superar el umbral se ponen en cola.
El EPD es tan complejo como el PPD. Este PDP almacena información en todos los fragmentos
en cola. En términos de rendimiento, se ha demostrado que la EDP es mejor que PPD en la
mayoría de las circunstancias. Por supuesto, EPD y PPD se pueden utilizar al mismo tiempo para
mejorar aún más el rendimiento.
Hay muchas extensiones y personalizaciones del EPD para diferentes propósitos; Por ejemplo,
para tratar con conexiones TCP o para mejorar la imparcialidad.
El PDP de RED está diseñado para trabajar con IP. No necesita almacenar ninguna información
de estado de flujo, y colabora con el mecanismo de control de congestión TCP.
RED parte la cola de almacenamiento en 3 regiones definidas por dos umbrales, 𝑇𝑙𝑜𝑤 y 𝑇ℎ𝑖𝑔ℎ . El
RED tiene un comportamiento diferente dependiendo de la longitud de la cola (ver Figura 6.15).
Región verde. RED opera en esta región si la cola es más corta que 𝑇𝑙𝑜𝑤 . En este caso,
todos los paquetes entrantes son aceptados.
Región amarilla. Esta región se define entre 𝑇𝑙𝑜𝑤 y 𝑇ℎ𝑖𝑔ℎ . Cuando RED está operando
en esta región, un paquete entrante se descarta al azar con una probabilidad de 𝑃𝑎 .
Región roja. RED funciona en esta región si la cola es más amplia que 𝑇ℎ𝑖𝑔ℎ . En este
caso, todos los paquetes entrantes se eliminan.
Figura 6.15 Probabilidad de caída de paquetes en una cola con RED PDP como una función de la
longitud media de la cola.
RED evita la caída de paquetes de muchas conexiones TCP al mismo tiempo, además ayuda a
resolver el problema de "subutilización" que es causado por la sincronización global.
RED ponderado (WRED) es una variación del algoritmo RED que tiene en cuenta las prioridades
relativas de los diferentes paquetes. El algoritmo comienza a descartar paquetes de baja
prioridad antes de descartar paquetes con mayor prioridad.
Figura 6.16 Una posible implementación del WRED. Cuando el algoritmo está trabajando en la
región A, todos los paquetes son aceptados. En la región B, los paquetes marcados con 1 pueden
ser eliminados. En la región C, los paquetes marcados con 2 también pueden ser eliminados. En
la región D, las tres clases posibles (1, 2 y 3) pueden ser eliminadas. Finalmente, en la región E,
no se aceptan nuevos paquetes