Tema 2: Mecanismos y

arquitecturas de red para la

provisión de QoS
 Objetivos
● Conocer los principales mecanismos de
provisión de calidad de servicio, así como sus
parámetros.
● Conocer la arquitectura IntServ
● Conocer la arquitectura DiffServ
● Conocer MPLS
 Contenido

● Mecanismos de provisión de QoS

● Arquitectura de Servicios Integrados (IntServ)
● Arquitectura de Servicios Diferenciados
(DiffServ)
● Conmutación multiprotocolo basado en
etiquetas (MPLS)
2.1. Problemas de la actual arquitectura
best-effort

- La filosofía de la IP es que la red debe ser lo más

simple posible, con las funciones mínimas para que los
dispositivos de los extremos puedan comunicarse. Es
decir, conectividad.
- La función básica de IP es entregar los paquetes de
un origen a un destino si existe algún camino entre
ellos, en un periodo de tiempo razonable, suponiendo
que los extremos podrán asumir este retardo. Esta es
la base de la arquitectura de mejor intento
(best-effort).
 2.1. Problemas de la actual arquitectura
best-effort
La red IP, por tanto, no garantiza la entrega de los paquetes enviados.

- Para garantizar esta entrega en una red IP, son los extremos quienes tienen que
implementar los mecanismos necesarios (Ej. TCP). Los nodos intermedios no
mantienen estados sobre las conexiones.

- La red tampoco ofrece mecanismos para asegurar equidad entre el tráfico de

distintos puntos finales.

- El encaminamiento del camino más corto utilizado en Internet utiliza métricas

no relacionadas con parámetros significativos para la QoS. Y aún en ese caso,
dada la naturaleza dinámica de la red, no son lo suficientemente precisos.

- La red IP no ofrece una cota para el retardo extremo a extremo (latencia) ni la

variación de retardo entre paquetes con los mismos origen y destino (jitter), no son
predecibles.
2.1. Problemas de la actual arquitectura
best-effort

- Las deficiencias de IP pueden resumirse en:

- Los encaminadores dan una respuesta temporal no predecible a la
congestión transitoria.
- No ofrece distinto tratamiento a distintas clases de tráfico.
- No es capaz de admitir peticiones dinámicas de provisión de QoS.
- Tiene una capacidad limitada para monitorizar el uso de los
recursos de red.

- Para ofrecer mecanismos que permitan obtener una QoS solicitada, es

necesario centrarse en dos aspectos básicos:
- El tratamiento a los encaminadores los distintos tipos de tráfico
durante la congesión.
- Cómo lo encaminadores aprovechan las características de QoS de
sus enlaces.
2.1. Problemas de la actual arquitectura
best-effort

- No es suficiente con añadir trato diferenciado a los distintos tipos de

tráfico. Se requiere también abordar las tareas de:
- Señalización, para solicitar extremo a extremo una QoS
determinada.
- Contabilidad del uso de los recursos de red. Esta faceta incluye
autenticar las solicitudes y monitorizar el uso de los recursos (para
controlar y para ajustarse a las demandas del usuario).
2.2. Mecanismos de provisión de QoS

- La calidad de servicio observada extremo a extremo es fruto de la

concatenación de la QoS ofrecida por cada salto que compone la ruta
desde origen a destino.

- Gran parte de la impredecibilidad y tratamiento sin clases de las

pérdidas y retardos en la actual red IP se debe al comportamiento de los
encaminadores en situaciones de congestión (colas FIFO,
generalmente).
Enlaces de Enlaces
entrada de salida
2.2. Mecanismos de provisión de QoS

-La necesidad de “proteger” un tráfico de otro se traduce en satisfacer los

siguientes requisitos:

- QoS por salto. Son el mínimo elemento controlable para ofrecer

QoS. Deben aprovechar las características de sus enlaces. Además,
permitiría predecir el servicio que se le puede brindar a una clase de
tráfico determinada.

- Ingeniería de tráfico y encaminamiento. Utilización de múltiples

caminos alternativos, etc.

- Señalización. Protocolos para definir y establecer la QoS que se

ofrecerá en la red.
2.3.1. Procesamiento de paquetes por salto en
un encaminador genérico (sin QoS)

- Elementos:

- Distintas interfaces de entrada y de salida.

- Una máquina de reenvío. Según la dirección IP destino, lo

reenvía a la interfaz correspondiente.

- Una máquina de gestión. En caso de congestión, se puede

decidir descartar el paquete recibido. Además ejecuta los protocolos
de encaminamiento necesarios para construir su base de
información de reenvío (FIB).
2.3.2. Procesamiento de paquetes por salto en
un encaminador con CQS
- CQS: Clasificador, encolado y planificador.

- Además de los elementos del encaminador general, se añaden las fases

de:

- Clasificación y consulta de la FIB (Forwarding Information Base)

para identificar la identidad del paquete y su interfaz de destino.

- Verificación de conformidad y marcado, para actuar en caso de

que el paquete no haya llegado en el periodo adecuado.

- Encolado y planificación, para reenviar el paquete según las reglas

de compartición de enlace o de conformado de tráfico, o descartarlo
según la política de descarte en caso de congestión.
 2.3.3. Elementos para la provisión de QoS

- Clasificador. Identifica a qué clase pertenece un paquete.

- Colas por clase de tráfico. Cada cola define su comportamiento de
descarte.
- Planificador. Teniendo en cuenta las características del enlace de
salida, puede decidir el orden de servicio de cada paquete en las colas.
- Conformación de tráfico (traffic shaping): para poder predecir el
servicio que se le dará a un flujo concreto, es necesario limitar el máximo
ancho de banda que ese tráfico consumirá. Un planificador que realice
conformado de tráfico limitará el periodo de salida mínimo y máximo entre
paquetes de un mismo flujo.
- Verificación de conformidad (policing): cuando llegan demasiados
paquetes que se ajustan a los límites definidos por el conformado, se
descartan.
Para controlar la llegada a ráfagas de los paquetes, habitualmente se
especifica un valor L (tolerancia a ráfagas) y un valor T que define la tasa
permitida. Supone la existencia de conexiones TCP.
2.3.3.1. Clasificación de paquetes

- Para llevar a cabo la clasificación, lo más sencillo es mantener N bits en

la cabecera de los paquetes, con lo que se pueden identificar hasta 2 N
clases diferentes. Ese campo sería la clave de clasificación.

- Las claves se comparan con un conjunto de reglas de clasificación,

especificadas para cada clase o comportamiento que el encaminador
debe llevar a cabo.

- Otra posibilidad consiste en utilizar varios campos del paquete para

realizar la clasificación (clasificación multicampo, MF). Por ejemplo, se
pueden definir flujos si se utilizan los campos de IP origen/destino, tipo de
protocolo y puertos origen y destino.

- La fase de clasificación determina los posteriores pasos en el

encaminador.
2.3.3.1. Clasificación de paquetes
Claves de clasificación.

- La clasificación multicampo permite llevar a cabo la clasificación por

flujos de aplicaciones, a partir de las direcciones IP origen/destino, las
puertos origen/destino, y el tipo de protocolo (TCP/UDP).

- EN IPv4, las direcciones IP se encuentran en una posición fija de la

cabecera. Sin embargo, los puertos pueden aparecer en posiciones
distintas dependiendo del tamaño (variable) de la cabecera.
Además, en caso de fragmentar el datagrama IPv4, sólo el primer
fragmento mantendría los puertos origen y destino.

- En IPv6, los puertos y protocolo pueden aparecer en distintas posiciones

debido a las cabeceras dinámicas que utiliza.
Para aliviar este problema, se introduce el campo etiqueta de flujo
(20 bits). IP origen + etiqueta de flujo permite identificar flujos, definidos
en el origen.

- La clasificación multicampo puede contemplar también el campo DSCP.

Las reglas de clasificación pueden ser estrictas o definir rangos.
2.3.3.1. Clasificación de paquetes
Claves de clasificación. Ej.:

IPv4

IPv6
2.3.3.1. Clasificación de paquetes

Claves de clasificación.

- En IPv4 existe un campo de 8 bits, ToS (RFC 1349), como clave:

|P P P| T T T T | X |

- Se descompone en dos subcampos:

- Prioridad relativa (“P”, 3 bits)
- Tipo de servicio (“T”,4 bits). Indica qué tipo de reenvío o
encaminamiento requiere el datagrama. Sus valores pueden ser:
- 1000 minimizar el retardo.
- 0100 Maximizar el throughtput.
- 0010 Maximizar la fiabilidad.
- 0001 minimizar el coste (monetario).
- 0000 servicio ordinario.
2.3.3.1. Clasificación de paquetes

Claves de clasificación.

- En la arquitectura de Servicios Diferenciados, se reinterpreta el campo

de ToS de IPv4 para ofrecer mayor variedad en el tipo de reglas de
encolado y planificación (RFC 2474).
- El campo ToS queda ahora como:

|DDDDDD|XX|

- Punto de Código de Servicio Diferenciado (DSCP), (“D”, 6 bits). Esta

aproximación permite hasta 64 diferentes tipos de servicio.
2.3.3.1. Clasificación de paquetes

Claves de clasificación.

- En IPv6 existe también un campo de 8 bits (tipo de clase, TC) como

clave de clasificación.

|SSSSSS|EC|

- Se descompone en dos subcampos:

- Etiqueta para servicios diferenciados (6 bits).

- Notificación explícita de congestión (2 bits).
2.3.5. Conformación de tráfico
El mecanismo más extendido utilizado para regular la tasa con la que se
permite a un flujo inyectar paquetes en la red es el del cubo horadado
(leaky bucket).

Su funcionamiento se basa en suponer un cubo con capacidad de un

máximo de b testigos. Estos se introducen en el cubo con una tasa de r
testigos por unidad de tiempo. Para que un paquete sea retransmitido, es
necesario eliminar un testigo del cubo.
Tasa de generación de testigos: “r”
Capacidad del cubo: “b” Cubo
testigos horadado
Cola de
espera

Entrada Salida
2.3.5. Conformación de tráfico

El cubo horadado permite:

- Limitar el número máximo de paquetes enviados

“instantáneamente” a la red, debido a que en un instante sólo
puede haber b testigos disponibles, con lo que sólo se pueden
retransmitir b paquetes de una vez.

- Limitar la tasa de retransmisión: en un intervalo de tiempo t

sólo se pueden enviar t·r+b paquetes.
2.3.6. Verificación de conformidad
- La tarea de verificación de conformidad consiste en comprobar si
una clase de tráfico cumple con su perfil de tráfico. Este perfil de
tráfico define la velocidad de llegada de los paquetes o el número
máximo de paquetes que pueden llegar dado un intervalo de tiempo.

- Para medir este perfil, tanto en la conformación del tráfico como en

la verificación, se puede utilizar el cubo horadado. Cada paquete
será considerado como que sigue el perfil si hay algún token
disponible en el cubo. En caso contrario, será descartado o marcado,
según la política del encaminador.

- La conformación puede llevarse a cabo por paquete o por octetos

(bytes), ya que los datagramas IP tienen un tamaño variable.

- Además, se pueden utilizar perfiles por niveles, para dar aplicar

distintas medidas según el grado de conformidad con su perfil.
2.3.7. Marcado de paquetes

Aunque útil, el descarte debido a la verificación de la

conformidad no es la mejor opción para suavizar las características
del tráfico en los extremos de la red.

El marcado de paquetes que sobrepasan los umbrales

definidos, permite que en caso de ausencia de congestión, la clase
de tráfico marcado pueda utilizar más ancho de banda.

A la hora de descartar paquetes, tendrán prioridad de descarte

los que hayan sido marcados.
2.3.8. Planificación de paquetes
- En un encaminador con arquitectura CQS, cada interfaz mantiene
un planificador para seleccionar qué cola (clase) servir cada vez.

- El planificador puede realizar conformación de la tasa de envío

(rate shaping) modificando la frecuencia de servicio a una clase
(cola) dada.

- La conformación de la tasa de envío permite acotar el

comportamiento de una clase determinada. Modifica las
características temporales de una clase.

- De esta manera, la agregación de los distintos flujos, que saldrían

a ráfagas, se suaviza, evitando posibles descartes en
encaminadores posteriores.
2.3.8.1. Planificadores simples

- Siguen una secuencia de servicio predecible.

- Prioridad estricta. Cada cola se sirve si no hay ninguna de mayor

prioridad ocupada. Permite utilizar colas de para tráfico de bajo retardo.

- Round Robin. Se selecciona en orden cada cola. Es posible asignar

varios turnos a la misma cola.
2.3.8.2. Planificadores adaptativos
- Dado que los paquetes tienen un tamaño diferente, para mantener la
tasa de bits es necesario adaptar la planificación de las colas
dinámicamente.

- RR deficitario. El turno de cada cola está activo mientras no se

hayan enviado los bytes pendientes para cumplir la tasa media deseada.

- Encolado equitativo (FQ) y encolado equitativo ponderado

(WFQ). Se recalcula la secuencia de turnos para dar servicio al que
menos se acerque a su tasa mínima. Se puede ponderar cada cola para
utilizar un porcentaje dado de la tasa compartida.
 2.3.9. Gestión de colas
- El gestor de colas se encarga de establecer y mantener las colas en
el encaminador. Sus funciones básicas son:

- Añadir un paquete a la cola correspondiente.

- Descartar el paquete si la cola está completa.
- Sacar de la cola a un paquete cuando lo solicite el planificador.
- Monitorizar (opcionalmente) el nivel de ocupación de la cola,
manteniéndolo bajo mediante el descarte o el marcado de los
paquetes. Esta gestión activa de la cola se lleva a cabo para
reducir el retardo de encolado, y tener capacidad de absorber
ráfagas de tráfico.

- Para evitar la reordenación de los paquetes marcados, se

recomienda que estos sean introducidos en las colas de su misma
clase, y descartados según el criterio del gestor activo de la cola.
2.3.9. Gestión de colas
- La reducción del nivel de ocupación de las colas las puede llevar a cabo
el gestor de colas mediante dos mecanismos, los cuales ofrecen a los
protocolos de transporte una retroalimentación del problema:

- Señalización en banda. Mediante la notificación explícita de

congestión Se le indica a los extremos que deben ejecutar sus
mecanismos de control de congestión. Para ello, se utilizan los dos bits
del campo de ToS no utilizados por DSCP:

|DDDDDD|EC|
E: (ECT, indica si los extremos reconocen el bit CE)
C: (CE, el encaminador anuncia que se acerca a la congestión).

- Descartado de paquetes. Descartado de paquetes de la cabecera

de la cola.
2.3.9.1. Gestión de colas. Detección temprana
- Para prevenir la congestión, se pueden tomar medidas mediante la
gestión de colas. Ejemplo.: la detección temprana aleatoria (RED):

- RED monitoriza la ocupación de la cola.

- Con el nivel de ocupación aumenta la probabilidad de ejecutar el
mecanismo de control de congestión.
- La ocupación media se calcula con la llegada de cada paquetes
como:
Qmedia=(1-Wq) x Qmedia + Qinstantáneo x Wq

- Si Qmedia < umbral_mínimo, no se descarta ningún paquete.

- Si umbral_mínimo < Qmedia < umbral_máximo, se descartan
con probabilidad creciente.
- Si umbra_máximo < Qmedia, se descarta con probabilidad 1.
2.3.9.1. Gestión de colas. Detección temprana
Evoluciones de RED:

- Puede darse un comportamiento diferente dependiendo del flujo,

definiendo distintos umbrales para las distintas clases (RED ponderado,
weighted RED).
- Una clase de RED Ponderado es RED conformado/no conformado
(RIO, RED IN/OUT).
- RED adaptativo (ARED) modifica de forma dinámica la máxima
probabilidad de pérdida (inferior a 1) según el número de flujos TCP
existentes.
- RED por flujo ( FRED, Flow RED), para proteger a flujos frágiles frente
a flujos que se recuperan rápidamente (y los que no tienen control de
congestión), se define un umbral mínimo de ocupación para todos los
flujos, y un nivel máximo. Si el paquete pertenece a un flujo con menor
ocupación que el umbral, se acepta siempre, y si se pasa del umbral
máximo, se descarta siempre. En otro caso, se sigue con el criterio de
descarte de RED.
2.3.10. Reordenación de paquetes.

Aunque la red IP no garantiza que los datagramas lleguen

ordenados, los protocolos extremo a extremo suelen manejar
con dificultad estas situaciones. Por ello, la reordenación de
paquetes que han sido marcados (con menor prioridad) y los
conformados, es una tarea deseable en estos esquemas.
2.3.11. Encaminamiento con QoS

Para el encaminamiento con QoS se consideran distintas métricas

(costes de los enlaces) al construir las tablas de encaminamiento.

- Se crean distintos árboles de camino más corto para distintas

métricas (retardo, ancho de banda, etc).
- Cada paquete se reenvía consultando la tabla dependiendo de la
clase de tráfico y sus requisitos.

Este esquema presenta los siguientes problemas:

- Cada encaminador debe mantener distintas tablas, y cada paquete
un identificador para seleccionar la tabla correspondiente.
- Existe una sobrecarga adicional del protocolo de encaminamiento,
pues hace falta mantener una instancia por cada tabla, y ejecutar el
algoritmo para cada tabla y cada vez que se produzca un cambio.
- Algunas de las métricas son muy dinámicas, por lo que habría que
recalcular los caminos más cortos frecuentemente.
2.4. Ingeniería de tráfico y control explícito de
rutas

Distintas rutas pueden compartir enlaces y

encaminadores susceptibles de congestión, por lo que
establecer rutas alternativas permitiría balancear la
carga y obtener un mejor rendimiento global de la red.

La ingeniería de tráfico consiste en establecer rutas

distintas a las del del camino más corto para optimizar el
uso de la infrastructura de enlaces y encaminadores.
2.4. Ingeniería de tráfico y control explícito de
rutas
Existen distintas opciones para realizar control explícito de rutas:

- Opción de encaminamiento desde la fuente: procesado poco

eficiente de las cabeceras IP de encaminamiento explícito.

- Tablas de encaminamiento con varios parámetros de las

cabeceras: por ejemplo, la IP origen. Pero no es aplicable en todos los
entornos.

- Túneles IP. Se utiliza el encapsulado IP para forzar una ruta

concreta.

- MPLS (MultiProtocol Label Switching). Los paquetes son

etiquetados y reenviados por encaminadores MPLS según unas rutas
preconstruidas por etiquetas (LSP, Label Switched Path). Usa cabeceras
de 4 bytes.
2.5. Modelos de red
- Los anteriores esquemas se deben implementar en el marco de
un modelo de red.
- Los más representativos:
- Servicios integrados (IntServ, IS).
- Servicios diferenciados (DiffServ, DS).
- Multiprotocol Label Switching (MPLS).

- Comparten algunos conceptos:

- en la red existen encaminadores fronterizos (que aceptan el
tráfico de los sistemas finales) y encaminadores centrales
(interconectan el núcleo y los nodos del borde).
- Los nodos fronterizos llevan a cabo las tareas de conformado,
marcado y control de admisión.
- Los nodos centrales dan un trato diferenciado a paquetes de
distintas clases para afrontar los periodos de congestión.
2.5.1. Servicios Integrados (RFC 1633)
- Desarrollada por la IETF, este entorno garantiza la provisión de
calidad de servicio a aplicaciones individuales. Cada sesión debe
indicar la especificación de reserva (Rspec) y la especificación del
tráfico a generar (Tspec) antes de comenzar. Si cada encaminador
tiene recursos suficientes, los reserva para dicha sesión y se
admite la llamada.

- IntServ define dos clases de aplicaciones:

- Aplicaciones de tiempo real con requisitos estrictos de ancho

de banda y latencia.
- Aplicaciones convencionales, para las que los usuarios desean
que la red les ofrezca un comportamiento similar al de la red sin
mucha carga.
2.5.1. Servicios Integrados (RFC 1633)
- En este modelo IntServ, la red es una concatenación de
elementos de red (sistema final, encaminador o enlace). Hay tres
tipos de elementos de red:

- Elemento de red habilitado para QoS.

- Elemento de red QoS-aware.
- Elemento de red sin capacidades para QoS.

- Para llevar a cabo el control de admisión, es necesario que la

fuente describa el tráfico que va a generar.
2.5.1.1. Clases de servicios básicos IntServ
- Servicio de calidad garantizada (GS, RFC 2212). Este servicio
ofrece un límite superior para los retardos de espera en cola. La
aplicación ofrece una caracterización de su tráfico (mediante los
parámetros de tasa media y ráfaga máxima), y la red le devuelve cuál es
la latencia que puede garantizarle.

- Servicio de carga controlada (CL, RFC 2211). En este caso se

garantiza a la sesión que el porcentaje de datagramas descartados y el
retardo de espera en cola será similar al experimentado en una red sin
carga.

EL tráfico es servido como si estuviera en una red sin congestión o

demasiada carga.
- Un alto porcentaje de paquetes serán transmitidos
correctamente.
- Un alto porcentaje de paquetes exhibirá un retardo similar.
2.5.1.2. Señalización IntServ: RSVP
- En el caso de disponer de mecanismos para QoS por salto, aún
es necesario proveer de algún mecanismo para coordinar los
comportamientos reales de cada camino.

- En IntServ, la señalización desempeña las siguientes tareas:

- Negociación (control de admisión).

- Configuración (para configurar los elementos de red
intermedios para ofrecer el servicio requerido por la aplicación).

- El protocolo de señalización adoptado es el protocolo de reserva

RSVP (ReSerVation Protocol).
2.5.1.2. Señalización IntServ: RSVP
- Las fuentes emiten periódicamente mensajes PATH hacia los
receptores. Incluye los objetos SENDER_TSPEC (descripción de
tráfico) y ADSPEC (modificado en cada salto).

- Los receptores responden con mensajes RESV. Incluye el objeto

FLOWSPEC (describiendo la calidad deseada).

- Para iniciar una reserva, el origen envía un mensaje PATH.

- ADSPEC indica cuál es la clase de servicio apropiada, y puede ser
modificada por cada elemento de red intermedio según las
restricciones existentes.
- ADSPEC contiene un campo “bits de discontinuidad” (“break bits”)
que indican si existen elementos sin capacidades QoS en la ruta.
- El receptor construye su FLOWSPEC seleccionando el servicio e
identificando los parámetros requeridos para efectuar la reserva.
2.5.1.2. Señalización IntServ: RSVP
SENDER_TSPEC caracteriza a la fuente mediante:

- cubo horadado con tasa r y capacidad b (en octetos, hasta 250 GB).

- tasa de datos pico p (de 1 octeto/s a 40 TB/s).

- unidad mínima de verificado de conformidad m. Si algún paquete

tienen un tamaño inferior a m, se le asigna este tamaño a la hora de
usarlo en el cubo horadado.

- Tamaño máximo de paquete M, indica la longitud del mayor paquete

que podrá enviar la fuente. ADSPEC incluirá por salto el mínimo MTU, y el
receptor responderá en su FLOWSPEC que el mayor paquete a recibir
debe ser inferior que el menor MTU de la ruta.
2.5.1.2. Señalización IntServ: RSVP
- El receptor puede solicitar el servicio CL o GS si la especificación
ADSPEC informa de que en la ruta se puede ofrecer ese servicio.

- Parámetros del servicio de carga controlada:

- FLOWSPEC responderá con los parámetros especificados en en
mensaje PATH.
- La caracterización del cubo horadado define el tráfico que el receptor
espera recibir.
- M será el menor MTU de la ruta.
- Si el valor de m es mayor que el especificado, existen más
posibilidades de que sea admitido, pero aumenta la probabilidad de
descartar más paquetes (los de tamaño inferior).
- Los encaminadores intermedios realizarán conformado, verificación
de conformidad, etc. según los parámetros indicados en FLOWSPEC.
2.5.1.2. Señalización IntServ: RSVP
- Parámetros del servicio de servicio garantizado:
- Parámetros m, M, r, b, p.
- R (octetos/s) indica cuál será la tasa ofrecida dentro de un límite de
tiempo. Es igual o superior a r.
- S (ms) indica cuál será la desviación de los retardos con respecto al
límite de lantencia.
- S=Dreq - ((b + Ctot)/R + Dtot)
- Dreq: retardo requerido por la aplicación.
- Dtot: retardo total introducido por cada elemento de red.
- Ctot: tasa total de cada elemento de red.

- La respuesta RESV será procesada por los elementos de red, llevando

a cabo control de admisión si fuera necesario.
2.5.1.2. Señalización IntServ: RSVP
- RSVP no lleva a cabo una selección de ruta ni utiliza
encaminamiento con QoS.
- Las reservas se llevan a cabo en la ruta del camino más corto, ya
que:

- Sin modificar el comportamiento del “siguiente salto”, no se

puede forzar un camino diferente.

- Aún no se adoptan protocolos de encaminamiento con QoS

entre dominios.
2.5.1.3. Requisitos de los encaminadores IntServ
- Clasificación multicampo.
- Varias colas, una por flujo, y al menos una para tráfico no
conformado o de mejor esfuerzo.
- Medición del tráfico mediante cubos horadados.
- Marcado de paquetes/descarte, conformación y
verificación de conformidad.
- Capa de gestión que soporte RSVP.
2.5.2. Servicios Diferenciados (RFC 2475)
- Se reduce la complejidad de la arquitectura, desplazando las
tareas de clasificación, conformado, verificación y marcado en los
encaminadores de acceso.

- Esto permite implementar encaminadores centrales más rápidos.

- Se necesita mantener menos información de estado para
señalización.

- Los nodos fronterizos establecen el DSCP de los datagramas a

partir de la clasificación multicampo, obteniendo sólo unas cuantas
clases agregadas.

- DiffServ define comportamientos por salto (PHB), bloques

funcionales que permiten construir servicios extremo a extremo.
Los administradores de red serán los encargados de combinar
dichos bloques para ofrecer servicios concretos.
2.5.2. Servicios Diferenciados (RFC 2475)
- Una red donde se utilicen las mismas reglas de clasificado y
mecanismos DiffServ se llama dominio DiffServ.

- Los nodos que rodean un dominio Diffserv se denominan nodos

fronterizos DS. Los nodos de entrada son los nodos de ingreso DS, y
los de salida, nodos de egreso DS.

- Los nodos centrales de un dominio se denominan nodos interiores DS.

- El acondicionamiento de tráfico se realiza en los nodos de ingreso, y

consiste en establecer el DSCP según la clasificación MF, conformado de
tráfico, marcado/descartado, según el acuerdo de acondicionamiento
de tráfico (TCA).

- Los flujos individuales de aplicación se denominan microflujos. Varios

microflujos compartirán el mismo DSCP (Agregado de comportamiento
DS).
2.5.2.1. Comportamientos por salto (PHB)
- Especifican el comportamiento de encolado, gestión de colas y
planificación.
- No especifican la técnica a utilizar para obtener dicho
comportamiento.
- Los PHB que definen comportamientos muy parecidos se
denominan grupos de PHB.
- Cada DSCP identifica un PHB.

- Códigos DSCP:
1: xxxxx0: Estandarizados por la IANA
2: XXX11:Uso local
3: XXX01: Uso local/extensión para uso de códigos
estandarizados.

- 000000: código DSCP por defecto, para tráfico de mejor intento

(best effort).
2.5.2.1. Comportamientos por salto (PHB)
- Para proporcionar compatibilidad con el campo ToS de IPv4, se
reservan los 3 primeros bits de DSCP YYYxx0 (selector de clase).

- Los tres primeros bits (YYY) corresponden a los bits del campo
ToS.

- Los paquetes con diferente selector de clase deben tratarse de

forma independiente.

- Los paquetes con selectores de mayor prioridad deben reenviarse

con preferencia a los de selectores de menor prioridad.
2.5.2.2. Clases de servicios DiffServ
Los comportamientos por salto actualmente propuestos son:
PHB expedito y PHB de envío asegurado.

- PHB de envío expedito (EF, RFC 2598). Para una clase dada,
se especifica la tasa de salida mínima que debe obtener,
independientemente del tráfico que llegue al encaminador, que
debe ser igual o mayor que el de entrada.
- El comportamiento observado es el de que las colas se
encontraran vacías o con baja ocupación.
- Requiere:
- Conformar el tráfico a la entrada del dominio.
- Configurar el planificador para superar la tasa de llegada
del agregado, sin que le afecte el tráfico no EF.
- Indicado para aplicaciones que requieran baja probabilidad de
pérdidas, de retardo y jitter.
2.5.2.2. Clases de servicios DiffServ
Los comportamientos por salto actualmente propuestos son:
PHB expedito y PHB de envío asegurado.

- PHB de envío asegurado (AF, RFC 2597). Define un grupo de

PHB.
- DSCP se divide en clase de servicio (“x x x”) y
precedencia de descarte (“y y”):
|xxxyy0|
- La notación: PHB AFxy se refiere a la clase de servicio “x”
con precedencia “y”.
- Para no reordenar paquetes, diferentes servicios deben
utilizar diferentes colas, y los paquetes de un flujo deben insertarse
en la misma cola.
2.5.2.3. Consideraciones para DiffServ
- En el encaminador de ingreso (entre dominio DS y no
DS, o entre dos dominios DS) se lleva a cabo el
Acondicionamiento de tráfico

- Es necesario aplicar una política de verificación de

conformidad agresiva y sobredimensionar el núcleo de la
red.

- Existen problemas de compatibilidad con protocolos

existentes (Ej. TCP).

- IntServ y DiffServ pueden desplegarse de forma

cooperativa. IntServ se aplicaría para acceder a la red
DiffServ.