Análisis de la Calidad de Servicio por Medio del Modelo Diferencial

Análisis de la Calidad de Servicio por Medio del Modelo Diferencial
Gabriel Gerónimo Castillo1, Everth H. Rocha Trejo 1
1
Instituto de Electrónica y Computación
Universidad Tecnológica de la Mixteca
Huajuapan de León, Oaxaca, México.
Tel. (01) 95353-20214 Fax (01) 95353-20399
{gcgero, everth}@nuyoo.utm.mx
menciona la aplicación de QoS en hosts y routers, y
se presentan algunas conclusiones.
Abstract
Este artículo realiza un análisis de la Calidad de
Servicio (QoS) desde el punto de vista de los
servicios proporcionados por los protocolos de
Internet IPv4 e IPv6. Analiza los servicios
diferenciales que ofrece IP por medio de los campos
de Tipo de Servicio (ToS) y Clase de Trafico (TC) y
finaliza mencionando como aplicar QoS en los hosts y
los routers.
1. Introducción
La Calidad de Servicio (QoS) se puede definir como
el conjunto de calidades relacionadas con los
servicios que deben percibir los usuarios, donde los
usuarios pueden ser humanos o programas de
aplicación.
Los requerimientos de calidad varían dependiendo de
los usuarios y los servicios solicitados. En las redes
IP la entrega de los paquetes se puede llevar minutos
o eventualmente horas, como es el caso de la
obtención de un archivo. Al navegar en la web o al
solicitar acceso a una base de datos remota la
tolerancia podrá ser de segundos pero no de minutos.
En aplicaciones demandantes tales como sesiones
de chat o voz y video en tiempo real solo se toleran
retardos de fracciones de segundos para satisfacer
los requerimientos humanos, y algo también muy
importante es el orden de llegada de los paquetes.
La QoS se puede aplicar en los hosts y los routers
explotando los campos de los encabezados IPv4 e
IPv6. En este artículo se analizarán estos campos y la
forma en la cual brindan un servicio diferencial. Las
secciones de este artículo se encargan de analizar el
campo de tipo de servicio de IPv4, los campos de
etiqueta de flujo y clase de tráfico de IPv6, se
2. Protocolo de Internet versión 4
Actualmente se están utilizando dos versiones del
protocolo de Internet, la versión 4 (IPv4) llamada
comúnmente IP y la versión 6 llamada IPv6. En IPv4
la transmisión de bloques de datos llamados
datagramas, tiene un cierto formato de encabezado
que contiene en forma generar cuatro puntos clave a
considerar para proporcionar un servicio: tipo de
servicio, tiempo de vida, opciones y suma de
verificación [1]. Los cuatro puntos son importantes,
pero el que se analizará por ser el que brinda la
calidad de servicio es el campo tipo de servicio.
2.1 Tipo de Servicio
El campo Tipo de Servicio en el datagrama IPv4 tiene
una longitud de 8 bits, y se encuentra subdividido en
6 subcampos [2], como se muestra en la fig. 1.
Los tres bits del subcampo Precedencia especifican la
importancia o prioridad del datagrama y los siguientes
4 bits indican el tipo de servicio (ToS) deseado. Los
valores de precedencia definidos para IP [3] que
pueden aparecer en este subcampo se muestran la
tabla I, estos valores permiten indicar al emisor la
importancia del datagrama.
0
1
2
3
4
Precedencia
D
T
5
R
6
7
C
Sin
Uso
Figura 1. Subcampos del campo Tipo de Servicio.
3. Protocolo de Internet versión 6
TABLA I.
NIVEL DE PRECEDENCIA IP
Valor de
Precedencia
IP
000
001
010
011
100
101
110
111
Nombre descriptivo
Normal o Rutinario
Prioritario
Inmediato
Urgente
Muy urgente
ECP
(Emergency
Processing) /Critico
Control entre redes
Control de red
Call
Los bits D, T, R y C especifican el tipo de transporte
deseado para el datagrama. Hablando sobre estos
bits, [4] define solamente tres bits: D, T y R; es decir,
del bit 3 al 5 de la fig. 1 e incluye el bit 6 al subcampo
de Sin Uso. Las razones por la cual se colocan los
cuatro bits: D, T, R y C, se encuentran documentadas
en [2] apartado B.2, una de estas razones es la de
minimizar el costo monetario en el envío de los
datagramas.
Cuando el bit D se encuentra activo solicita un
procesamiento con mínimo retardo, el bit T solicita un
máximo desempeño, el bit R solicita una máxima
confiabilidad, y el bit C un mínimo costo monetario.
Cuando estos bits se encuentran inactivos se esta
especificando un trato normal para el datagrama.
Cabe hacer notar que los valores de los bits no
pueden ser utilizados simultáneamente, de hecho los
algoritmos de ToS eligen el “mejor” de ellos cuando
existe más de un bit activo [5], por lo tanto, la
recomendación es utilizar sólo uno de estos bits.
Ahora bien, algunos datagramas TCP y UDP
necesitan un trato especial (dependiendo de la
aplicación), pero ¿qué pasa con los mensajes ICMP?
Al tener dos niveles de encapsulado y necesitar de IP
para viajar por la red también presentan el campo
ToS. Estos mensajes ICMP se pueden clasificar en
tres tipos, los mensajes de error, los mensajes de
solicitud y los mensajes de réplicas. Los mensajes de
error son enviados siempre con el servicio normal, es
decir, 0000; los mensajes de solicitud pueden ser
enviados con cualquier valor en el ToS, dependiendo
de la aplicación que envíe el mensaje, y los mensajes
de replicas son enviados con el mismo valor que
recibieron en su correspondiente mensaje de
solicitud.
Existen dos principales desventajas de IPv4 sobre el
IPv6, una de ellas es la suma de verificación la cual
era calculada por cada nodo en el cual pasaba el
paquete, ahora IPv6 no realiza esto, dado que los
protocolos de nivel alto tienen su propio mecanismo
de control de suma de verificación, por lo que no hay
que gastar tiempo realizando esta suma. Una
segunda desventaja en IPv4 es el procesamiento del
campo de opciones en cada router por el que pasa el
paquete, ahora en IPv6, los routers solo procesan la
información necesaria, dado que esto se encuentra
listado en el orden de los encabezados de extensión.
Aunque la ventaja más evidente de IPv6 es el espacio
de direcciones que crece de 232 a 2128, existen más
características importantes que se pueden observar
directamente en los campos que desaparecen en el
formato de IPv4 (fig. 2, campos en gris), y dan como
resultado el formato que se muestra en la fig. 3. Al
utilizar este nuevo formato se aprecian las siguientes
características: un mayor espacio de direcciones,
calidad de servicio (campo Clase de tráfico),
clasificación de servicio (campo de Etiqueta de flujo),
multicast, anycast, paquetes eficientes y extensibles
(Encabezados de extensión), mayor carga útil,
enrutamiento eficiente (Encabezado de ruta), entre
otras. Lo que se analiza en este artículo es la manera
de brindar QoS, así que en las siguientes secciones
veremos los campos Clase de tráfico y Etiqueta de
flujo.
0
4
Versión
8
HLen
Tipo de
Servicio
Identificación
Tiempo de Vida
16
20
24
31
Longitud Total del
Datagrama
Banderas Desplazamiento
del Fragmento
Protocolo Suma de Verificación del
Encabezado
Dirección IP Origen
Dirección IP Destino
Opciones IP
Relleno
Figura 2. Encabezado IPv4 que muestra que campos
se modifican y cuales desaparecen.
0
4
8
12
Versión Clase de
Tráfico
Longitud de Carga Útil
16
20
24
31
Etiqueta de Flujo
Siguiente
Encabezado
Límite de
Saltos
Dirección IP Origen
Dirección IP Destino
Figura 3. Encabezado IPv6.
3.1 QoS en IPv6
El protocolo de Internet IPv6 proporciona QoS por
medio de los campos de Etiqueta de Flujo y Clase de
Tráfico. Al introducir el campo de Etiqueta de Flujo,
IPv6 tiene la intención de clasificar los paquetes de
acuerdo a su destino y a su servicio.
3.1.1 Etiqueta de flujo
Los 20 bits del campo Etiqueta de Flujo puede ser
usado por la fuente para etiquetar la secuencia de
paquetes para los cuales se requiere un trato especial
por los routers IPv6, tales como un servicio de calidad
diferente de la normal o algún servicio de tiempo real.
La naturaleza de este trato especial debe ser cubierta
por los routers por medio de un protocolo de control,
tal como el Protocolo de Reservación de Fuente
(RSVP-RFC 2205), o por la misma información de la
etiqueta de los paquetes, por ejemplo, la opción
Salto-a-Salto. Los hosts y los routers que no realizan
un etiquetado de flujo fijan el campo a cero cuando
originan un paquete, pasan el campo sin realizar
cambios cuando les llega un paquete e ignoran el
campo cuando reciben un paquete. La etiqueta de
flujo asignada es elegida de forma seudo aleatoria y
uniforme en el rango de 1 a FFFFF hexadecimal [6].
De esta manera se pasa de la forma tradicional de las
quíntuplas <dirección fuente, dirección destino, puerto
fuente, puerto destino, protocolo de transporte> para
identificar un flujo a una tripleta <la dirección fuente,
la dirección destino, la etiqueta de flujo> haciendo
más eficiente el flujo en IPv6.
3.1.2 Clase de Tráfico
El campo Clase de Tráfico (TC) de 8 bits es usado
por los nodos y/o routers para identificar y distinguir
los paquetes enviados con clases diferentes o
prioritarias. Los valores que pueden tomar estos bits
dependen de los nodos que envían los paquetes, el
valor por omisión en este campo es de cero.
En el RFC 2460 no se define en forma particular la
semántica del byte TC, aplazando esto para colocarlo
en el trabajo dentro del área de Servicio Diferencial.
De esta forma el Servicio Diferencial involucra el trato
de los paquetes por medio del campo ToS de IPv4 y
el campo TC de IPv6.
4. Servicio diferencial
Uno de los problemas que presenta el ToS es el
manejo del tráfico diferencial, solo permite una
relativa prioridad, es decir, los paquetes con prioridad
7 son transmitidos antes de los de prioridad 6, y así
sucesivamente, de esta manera se esta consumiendo
el 50% de los bits de ToS para enrutar con QoS [7].
Estos problemas son evitados por medio de tipos de
encolados de paquetes y esquemas de reglas que se
pueden indicar con el campo de Servicio Diferencial
(los mismos 8 bits de ToS o TC).
Los servicios diferenciales son un conjunto de
tecnologías por medio de las cuales los proveedores
de servicios de red pueden ofrecer distintos niveles
de QoS para diferentes clientes y tráfico de
información. Conforme el paquete viaja a su destino
los routers en su paso lo tratan de diferentes formas,
a esto se le conoce como el PHB (Per-Hop
Behaviour). Este PHB es indicado en el DSCP
(Diffserv Code-Point) dentro del encabezado de cada
paquete.
Las definiciones del campo ToS de IPv4 y el campo
TC de IPv6 es reemplazado por el campo DS
(Differentiated Services). Como se muestra en la fig. 4
se utilizan seis bits de este campo como puntos de
códigos (DSCP) para seleccionar el PHB de un
paquete en cada nodo. Dos bits no son utilizados se
reservan para usos futuros y son ignorados por los
nodos por donde pasa el paquete.
La pregunta que se tiene ahora es: ¿qué valores
puede contener el campo DSCP?, y además, ¿estos
valores coinciden con los de ToS?, o ¿los nodos a
quien le harán caso?.
El valor por default de DS es 000000 lo cual es
compatible para el campo ToS, pero faltan 63 códigos
más que se deben de tratar. Estos 64 códigos se
dividen en 3 clases, mostradas en la tabla II, donde x
puede ser 1 ó 0. Como se puede observar en los
valores del Servicio diferencial los primeros bits del
código contienen xxx con lo que se garantiza la
coexistencia del valor de Precedencia de IPv4.
0
1
2
3
4
5
DSCP- Differentiated services codepoint
6
7
Sin
USO
Figura 4. Campo de Servicios Diferenciales.
TABLA II.
CLASES EN EL CAMPO DSCP
Clase
1
2
3
Código
xxxxx0
xxxx11
xxxx01
Política de asignación
Acción estándar
Uso local o experimental
Uso local o experimental o
utilizada como la clase 1 si
esta es agotada
Los valores de DSCP estándares son de la forma
xyzab0, donde xyz pueden ser (para que coincidan
con el campo de Precedencia de IPv4) 001, 010, 011
ó 100 y ab es 01, 10 ó 11.
Ahora bien, lo que resta es saber como llevar a cabo
la QoS en los hosts o routers de la red. Para esto se
presenta en la siguiente sección herramientas que
permiten realizar QoS en los hosts y los comandos
que se necesitan aplicar en un router (Cisco) para
brindar servicios diferenciales.
5. Aplicando QoS en hosts y routers
En esta sección se habla de los hosts con sistema
operativo Linux y de los routers Cisco con IOS 12.2.
El control de tráfico y la QoS en Linux en pocas
palabras es limitar el tráfico en una interfaz de red. El
control del tráfico en Linux se realiza por medio de
clases, estas clases van a depender del tipo de
necesidad que se desee. Los paquetes solo
necesitan ser clasificados si se quiere diferenciar
unos de otros. En Linux la QoS es posible gracias a
las herramientas IPROUTE2 y NETFILTER.
IPROUTE2 proporciona el comando tc que permite
manipular las disciplinas de colas y el uso de filtros
para asignarle prioridad al tráfico. Por otro lado,
NETFILTER permite el uso de marcado (mark), para
indicar en forma sencilla la manera de dar prioridad a
los paquetes.
La disciplina más usada y por defecto en Linux es
pfifo_fast, aquí ningún paquete recibe un tratamiento
especial. Esta cola tiene tres bandas o clases con
prioridades, la prioridad 0 es de mayor prioridad que 1
y 1 que 2. El kernel toma en cuenta el ToS e inserta
los paquetes de mínimo retardo en la banda 0 [8]. En
la tabla III se muestran los valores de ToS y las
bandas donde se colocan los paquetes.
Las disciplinas son un conjunto de algoritmos para
indicar a donde van los paquetes, ya sea a un
dispositivo o a una clase. Las más comunes en Linux
son CBQ (Class Based Queues), PRIO (Priority), SFQ
(Stochastic Fairness Queueing) y TBF (Token Bucket
Flow), todas configurables con la herramienta tc.
Veamos ahora como se implementa QoS en un
router. El software de QoS en el IOS del router Cisco
soporta tres tipos de modelos de servicio: Servicios
de mejor esfuerzo, Servicios Integrados y Servicios
Diferenciales [9]. Bajo el modelo de Servicios
Diferenciales las redes brindan la entrega de servicios
basados en la QoS especificada por cada paquete
por medio del DSCP.
Para configurar y habilitar características QoS en el
router se deben de colocar un conjunto de comandos
en línea. Estos comandos son los siguientes: creación
de una clase de tráfico (comando class-map),
creación de una política de tráfico (comando policymap), aplicar una política de tráfico a una interfaz
(comando service-policy), y de forma opcional,
verificar la configuración (comando show policymap).
TABLA III.
VALORES DE ToS Y SUS CORRESPONDIENTES
BANDAS
Banda
Significado
Prioridad en
ToS
el kernel de
(bits
Linux
3 - 6)
0000
Servicio normal 0 Mejor
1
esfuerzo
0001
Mínimo costo
1 Relleno
2
monetario
(mcm)
0 Mejor
1
0010
Máxima
esfuerzo
confiabilidad
(mc)
0011
mcm + mc
0 Mejor
1
esfuerzo
0100
Máximo
2 En masa
2
desempeño
(md)
0101
0110
0111
1000
1001
1010
1011
1100
1101
1110
1111
mm + md
mc + md
mcm + mc + md
Mínimo retardo
(mr)
mcm + mr
mc + mr
mcm + mc + mr
md + mr
mcm + md + mr
mc + md + mr
mcm + mc + md
+ mr
2 En masa
2 En masa
2 En masa
6 Interactivo
2
2
2
0
6 Interactivo
6 Interactivo
6 Interactivo
4 Int. en masa
4 Int. en masa
4 Int. en masa
4 Int. en masa
0
0
0
1
1
1
1
Si no se configura la QoS en el router los paquetes
son tratados con la clase por default. Esta clase por
default no tiene características de QoS habilitadas,
así que todos los paquetes se colocan en una cola
FIFO y son reenviados por el mismo ancho de banda.
6. Conclusiones
Lo que se concluye en este artículo es, si se desea
dar prioridad a los paquetes se debe manipular el
campo ToS o los campos de Clase de Tráfico y
Etiqueta de Flujo por medio de alguna aplicación que
se comunique con el kernel del sistema o
directamente se debe manipular para asignar dicha
prioridad. Los campos de Etiqueta de Flujo, Clase de
Tráfico, o el campo de Servicio Diferencial, junto con
las disciplinas y clases de calidad de servicio son una
importante área de investigación, para encontrar sus
ventajas, desventajas o adaptaciones para ser
utilizados con los diferentes flujos de información que
se pueden enviar en la red.
Referencias
[1] M. León, “Quality of Service of the Internet Protocols”, en
International Symposium on Advanced Distributed System,
ISADS’02, Noviembre 2002.
[2] P. Almquist, "Type of Service in the Internet Protocol
Suite", RFC 1349, Julio 1992.
[3] W. W. Barns, "Precedence and Priority Access
Implementation for Department of Defense Data Networks",
Reporte Tecnico MTR-91W00029, The Mitre Corporation,
McLean, Virginia, USA, Julio 1991.
[4] J. Postel, "Internet Protocol", RFC 791, Septiembre
1981.
[5] J. Reynolds and J. Postel, "Assigned Numbers", RFC
1060, Marzo 1990.
[6] C. Partridge, “Using the Flow Label Field in IPv6”, RFC
1809, Junio 1995.
[7] G. Armitage, “Quality of service in IP networks”, 1a. ed.,
Ed. MTP, Abril 2000, pp. 68-73.
[8] B. Hubert, “Enrutamiento avanzado y control de tráfico
en Linux”, Netherlabs BV, Julio 2003, pp. 40-73. [Online]
http://www.gulic.org/comos/LARTC/lartc.pdf
[9] Corporate Headquarters, “Cisco IOS Quality of Service
Solutions Configuration Guide”, Cisco System, Inc., 2001,
pp. 373-411. [Online] http://www.cisco.com/univercd/cc/td
/doc/product/software/ios122/122cgcr/fqos_c/qcfbook.pdf