El control de admisión se utiliza con frecuencia en los bordes de la red, pero también son

aplicables a elementos intermedios de la red. Cuando se aplica el control de admisión a los

elementos intermedios de la red, se denomina generalmente modelado de tráfico o poleo de
tráfico. Modelado o poleo, por ejemplo, pueden utilizarse para separar las redes que pertenecen
a diferentes operadores. La gestión de recursos requiere compatibilidad entre los protocolos de
reserva en todos los elementos de red utilizados, y los operadores tienen que llegar a un acuerdo
sobre cómo reservar recursos entre sí.

6.5.1 Control de Admisión

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.

6.5.1.1 The Token Bucket

La mayoría de los algoritmos de control de admisión se basan en el sistema de token bucket.

Estos algoritmos incluyen un bucket conceptual, de tamaño S, que está lleno de tokens a una
tasa configurable. Cada paquete toma un token del bucket antes de que pueda ser enviado. Si
hay tokens disponibles, el paquete puede ser entregado, pero si el bucket está vacío, el paquete
necesita ser tratado de alguna manera, y ahí depende del tipo de filtro que se está utilizando:
Los policers dejan paquetes cuando no hay Tokens, los markers vuelven a clasificarlos, y los
shapers los almacenan en un buffer hasta que más tokens estén disponibles (vea la Figura 6.11).
Un bucket puede almacenar tokens S al máximo. Cuando el bucket está lleno, no puede recibir
más tokens, por lo que cualquier token adicional se descarta.

El algoritmo token bucket es simple, y claramente separa los paquetes conformes y no

conformes. Pone límites para la cantidad de datos que entran en la red durante un intervalo de
tiempo especificado. Tiene una propiedad muy fácil de utilizar para asegurar de que el retraso
de los flujos que están conformados y vigilados se mantenga dentro de los límites previamente
definidos. Con esto brindamos servicios garantizados en redes de conmutación de paquetes (ver
párrafo
7.2.1.1).

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.

6.5.1.2 Marcador de tres colores de una tasa simple (srTCM).

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.

6.5.1.3 Marcador tres colores de tasa doble. (trTCM)

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) .

Figura 6.13 Marcador de tres colores de tasa doble.

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.

6.5.2 Gestión de recursos

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.

Para muchas aplicaciones de audio y video, la degradación continua del rendimiento no es

aceptable. Para estas aplicaciones, sería mejor tener el comportamiento de una red de
conmutación de circuitos y la flexibilidad de una red de conmutación de paquetes.

Las redes de conmutación de circuitos pueden establecer conexiones de extremo a extremo,

aunque algunas tecnologías de conmutación de paquetes pueden hacer lo mismo. Pero mientras
que las tecnologías de conmutación de circuitos proporcionan conexiones físicas de extremo a
extremo, los circuitos proporcionados por las tecnologías de conmutación de paquetes son
virtuales (circuitos virtuales, VC): tratan de emular las propiedades de los circuitos físicos.

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:

 Un protocolo de gestión de recursos para establecer y liberar conexiones. Por lo general,

estos protocolos son complejos y consumen ancho de banda.
 Para almacenar información de estado de flujo en nodos intermedios. Esto significa que
es necesario añadir complejidad a los elementos de red añadiendo más memoria y
tiempo de procesamiento para administrar la información de conexión.
 Perder el tiempo estableciendo conexiones. El tiempo perdido en establecer una
conexión significa retraso adicional.

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:

1. Protocolo de reserva (RSVP) es el más importante de todos los protocolos de gestión

de recursos propuestos para IP. Es un componente importante de la arquitectura de
servicios integrados (IS) propuesta para redes IP. Esta arquitectura convierte IP en una
tecnología orientada a la conexión. Para ser eficiente, el RSVP necesita ser apoyado por
todos los elementos de la red, y no sólo por el equipo del usuario final. Tanto RSVP como
IS requieren una nueva generación de enrutadores IP.
2. MPLS es una tecnología de conmutación basada en etiquetas llevadas entre los
encabezados de capa 2 y 3 que aceleran la conmutación de datagramas IP. MPLS se
puede utilizar para proveer QoS en redes IP. Una de las razones es que MPLS soporta un
tipo especial de conexiones llamadas Label-Switched Paths (LSP). La configuración y
desmontaje de LSP se basa en un protocolo de administración de recursos, usualmente
 el Protocolo de Distribución de Etiquetas (LDP), pero también se puede usar RSVP con
la extensión apropiada para MPLS.

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.

RSVP y MPLS tienen un inconveniente en común: se basan en un protocolo de gestión de

recursos complejo. Cómo gestionar las conexiones IP sin un protocolo de este tipo sigue siendo
una cuestión abierta.

6.6 CONTROL Y RECUPERACIÓN DE LA CONGESTIÓN

El control de la congestión es el conjunto de técnicas que se ocupan de la congestión una vez

que se ha detectado en la red y su objetivo es minimizar los daños en las comunicaciones.

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.

6.6.1 Caída de cola

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.

6.6.2 Descarte parcial de paquetes

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 PPD necesita almacenar información sobre paquetes con fragmentos previamente

descartados. Esta información de estado agrega complejidad a este PDP. Esto no es un gran
problema para ATM, porque la tabla de conexión de los conmutadores ATM se puede ampliar
fácilmente para almacenar la información necesaria para el PPD.

6.6.3 Descarte anticipado de paquetes

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.

6.6.4 Detección anticipada aleatoria (RED)

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.

En realidad, la región operativa no depende directamente del valor instantáneo de la longitud

de la cola. Una versión promedio, Q, para evitar cambiar la región de operación con demasiada
frecuencia. La probabilidad de que paquete este en la región amarilla depende de dos factores:

1. Longitud media de la cola: Ha medida que la longitud de la cola se aproxima a 𝑇ℎ𝑖𝑔ℎ ,

aumenta la probabilidad de caída.
2. Contador: Cada vez que un paquete se pone en cola, el contador incrementa. Este
contador se restablece cuando un paquete se descarta. Los valores altos del contador
aumentan la probabilidad de que los paquetes se descarguen. En otras palabras,
cuantos más altos son los valores, más probable es que los paquetes se caigan.

La probabilidad de caída se calcula por medio de la siguiente fórmula:

𝑃𝑏
𝑃𝑎 = 𝑒𝑞. 6.3
1 − 𝑐𝑜𝑢𝑛𝑡𝑒𝑟 ∙ 𝑇𝑙𝑜𝑤
Donde 𝑃𝑏 es:
𝑄 − 𝑇𝑙𝑜𝑤
𝑃𝑏 = 𝑃𝑚á𝑥 ∙ 𝑒𝑞. 6.4
𝑇ℎ𝑖𝑔ℎ − 𝑇𝑙𝑜𝑤
La elección de los valores correctos para 𝑇𝑙𝑜𝑤 y 𝑇ℎ𝑖𝑔ℎ es importante, 𝑇ℎ𝑖𝑔ℎ está relacionada con
el retardo máximo para un paquete, y es especialmente importante en las comunicaciones en
tiempo real. Para 𝑇𝑙𝑜𝑤 que es demasiado pequeño puede afectar la calidad del tráfico de datos.

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