Para RSVP se han especificado formalmente dos clases de calidad de servicio: servicio garantizado y el servicio de carga controlada.
2.3.1. Servicio Garantizado
Esta calidad de servicio esta destinada para aplicaciones con requerimientos exigentes de tiempo real. Esta calidad asegura: un ancho de banda, un límite en el retraso y ninguna pérdida en las colas
Para esta clase de servicio un flujo se describe usando un modelo token bucket y dada esta descripción , cualquier elemento de la red calcula varios parámetros describiendo como va a manejar los datos del flujo. Combinando los parámetros de todos los elementos que el flujo debe recorrer se calcula el retardo máximo que se produce en el flujo.
El retardo extremo a extremo que sufre un paquete esta compuesto por dos componentes de naturaleza diferente: el “retardo fijo”(retardos de transmisión,etc) y el “retardo de encolamiento”. El retardo fijo es una propiedad de la ruta seleccionada, el cual no se determina por el servicio garantizado(guaranteed). El servicio garantizado determina exclusivamente el retardo de encolamiento, el cual es función del tamaño del token bucket (b) y de la tasa de transferencia de datos(o ancho de banda R) que la aplicación solicite.
El servicio garantizado no controla ni el retardo mínimo ni el retardo medio de los datagramas, solo controla el retardo máximo de encolamiento, es decir el limite máximo del retardo que sufre un paquete desde el momento que es entregado en un nodo hasta el momento en que es enviado al siguiente nodo. Para el calculo del retardo máximo de un datagrama, deberá sumarse la latencia de la ruta que seguirá al retardo máximo de encolamiento(este termino se calcula en la siguiente sección) .
2.3.1.1. Información característica
Una petición de servicio garantizado debe contener la especificación del trafico(mediante un Tspec) y la especificación del servicio requerido(mediante un
Rspec). Una nueva petición se acepta si existen suficientes recursos. Una petición para
aumentar el Tspec o Rspec de un flujo ya aceptado se toma como una nueva petición. Una petición que reduzca el Tspec o Rspec de un flujo ya aceptado será aceptada siempre.
El Tspec contiene los parámetros b,r,p,m y M definidos previamente en el modelo de trafico token bucket.
El Rspec tiene la forma de una tasa de transferencia R y un termino de relajación(slack
term) S. La tasa de transferencia R se mide en bytes de datagrama IP por segundo,
mientras que el término S se mide en microsegundos, y define la diferencia entre el retardo deseado y el que se obtiene de hacer una reserva de nivel R.
La siguiente tabla resume los elementos de Tspec y Rspec. Tabla 5. Parámetros de Tspec y Rspec
Parámetro Tspec Descripción Unidad
p Tasa pico del flujo Bytes/s
b Tamaño del cubo(bucket dept) Bytes
r Tasa de transmisión del cubo(token bucket rate) Bytes/s
m Tamaño mínimo de un paquete Bytes
M Tamaño máximo de un paquete Bytes
Parámetro Rspec
R Ancho de banda Bytes/s
S Slack term: Diferencia entre el retraso deseado y el obtenido usando una reserva de ancho de banda R.
µs
2.3.1.2. Requerimientos en cada elemento de la red
Cada elemento de red debe asegurar que el servicio para un flujo con tasa de transferencia R será aproximadamente el mismo que el que se obtendría de una línea dedicada de ancho de banda R entre el origen y el destino.
Cada enrutador caracteriza el servicio garantizado para un flujo determinado, asignando un ancho de banda R, y un espacio de memoria B, que representa los recursos que el flujo puede consumir, lo que significa que existe un ancho de banda R entre el emisor y el receptor. Para un servicio que siga el modelo de flujo perfecto con un cubo de capacidad b y tasa r(token bucket: ver capitulo Calidad de servicio, Sección 1.4.3.1) se puede calcular el limite de retraso como b/R siempre que R sea mayor que r.
Para permitir desviaciones,normalmente se añaden dos términos de error C y D; con lo que el limite del retraso se convierte en b/R + C/R + D. Estos errores normalmente representan un retraso debido a paquetes de su propia cola o a imprecisiones propias del planificador.
C: Término de error dependiente de la tasa de transferencia. Representa el retardo que un datagrama del flujo experimentara como consecuencia de los parámetros de transferencia del flujo. Un ejemplo para hacer necesario este tiempo seria la necesidad de serializar un datagrama dividido en celdas ATM. En la practica representa cuanto se aleja el servicio real de un servicio bit a bit. Este termino de error se mide en bytes
D: Termino de error independiente de la tasa de transferencia. Representa el peor caso
de variación del tiempo de tiempo de transito a través del enrutador. Este termino de error se mide en microsegundos.
Con el servicio garantizado se introduce una variable p denominada la tasa pico del flujo(ver modelo token bucket en el capitulo de calidad de servicio de este documento), que reduce los limites del retraso. Además debemos considerar el efecto de la partición en paquetes en el flujo, considerando el tamaño máximo del paquete M ( se mide en bytes y estará de acuerdo con la especificación del flujo).
2.3.1.3. Limite del retardo extremo a extremo
Tal como se define en la tesis de Enrique Hernandez(Reserva eficiente de recursos en redes de tiempo real, Enero 2001,capitulo 2, pagina 43) y en diferentes documentos relacionados con el modelo Intserv, para un flujo que atraviesa N nodos podemos acotar el retardo de cada paquete con la siguiente expresión(todos los parámetros de la expresión ya han sido mencionados y hacen relación al modelo token bucket y a la cantidad R: porción del ancho de banda del enlace que el flujo necesita, medido en bytes de datagramas IP por segundo).
(
)(
)
(
)
(
)
tot totD
R
C
M
r
p
R
R
p
M
b
t
+
+
+
−
−
−
=
Re
en el caso que p>=R>=r(
)
tot totD
R
C
M
t=
+
+
Re
En el caso de que R>=p>=r.En la formula
C
tot yD
tot representan la sumatoria de los términos de error C y D de cada enrutador de la ruta.Para que este retraso, tal como se define acá se cumpla es necesario que el trafico entrante este conforme al algoritmo token bucket, es decir el trafico esta limitado por la ecuación
min[pt,b+rt]
.Cada enrutador necesita ser informado de las características del tráfico(Tspec) y del flujo con las características de las reservas realizadas (Rspec). Además necesita los términos
C
sum yD
sum que representan la suma de los términos C y D de cada enrutador presente en la ruta de los datos, desde el origen hasta llegar a el.Para utilizar este esquema, los enrutadores tienen que aproximarse al modelo de flujo. Para ello se pueden utilizar varios algoritmos de planificación como el WFQ(mencionado en la sección 1.4.7.4 de este documento), Jitter EDD y Virtual Clock, siendo el mas utilizado el primero de ellos.
Usando el planificador WFQ los valores de
C
iyD
i se calculan de la siguiente manera: iD
es igual al MTU del enlace dividido por el ancho de banda del enlace, con la condición de que M debe ser menor que el mínimo MTU de la ruta. El valor deC
i se asume que es M para considerar la fragmentación en paquetes y contabiliza la posibilidad de que un nuevo paquete llegue justo en el momento en que se comienza a enviar un paquete del máximo tamaño aceptado en el enlace de salida(MTU
i) con un ancho de banda del enlace (AB
i).Por tanto:
∑
∑
=
=
i i i totAB
MTU
D
D
C
tot=
∑
C
i=
∑
M
Respecto al tamaño del buffer que se debe reservar en los nodos el valor se calcula como b+ Csum+Dsum*r , donde Csum y Dsum son la suma de todos los parámetros Ci y Di
anteriores al nodo.
Cuando un receptor genera un RSpec para un mensaje de reserva con servicio garantizado debe incluir un termino de relajacion S (Slack term), que indica la diferencia en el retardo que existe entre el que se obtiene con la reserva de un ancho de banda R, y el retardo que la aplicación realmente necesita.
En muchos casos la adición de un Slack Term correcto en un mensaje de reserva hace que la reserva pueda instalarse ( a diferencia de la misma reserva con este término a 0). Este término de relajación da una gran flexibilidad a los enrutadores del camino, ya que permite que adecuen sus reservas a las necesidades reales de la aplicación. Un nodo intermedio puede utilizar una cierta cantidad de slack disponible (Si) para reducir
la reserva local.
Un ejemplo de aplicaciones que requerirían esta clase de servicios son las videoconferencias H.323, que están diseñadas para correr sobre ISDN o ATM, pero igualmente se encuentran en internet y en muchas intranets basadas en IP. La codificacion H.323 es a una tasa constante o aproximadamente constante y requiere que una tasa de transporte constante este disponible en una red de conmutación de circuitos(como ATM). IP, por su naturaleza, en cambio es un red de conmutación de paquetes y adolece de la falta de mecanismos para soportar una tasa de servicio constante para el flujo de datos de una aplicación dada. A través del servicio garantizado, RSVP permite una tasa de servicio constante en una red de conmutación de paquetes (como IP), para este tipo de aplicaciones.
2.3.2. Servicio de carga controlada
Para esta clase de servicio no hay una firme garantía de que se cumpla el servicio requerido. En este caso se puede indicar un Tspec( Especificación del trafico: usualmente el modelo token bucket) para la Qos requerida, aunque no es necesario incluir el parámetro de tasa pico p. Si el flujo se acepta, el enrutador intenta ofrecer un servicio equivalente a un flujo “best-effort” en una red ligeramente cargada. La diferencia crucial es que el flujo no se deteriora aunque aumente la carga de la red. Este tipo de servicio cumple con su propósito utilizando recursos mínimos, lo que permite a las implementaciones utilizar los recursos de red en una forma extremadamente eficiente. El servicio de carga controlada se adapta bien para aplicaciones “blandas” de tiempo real o aplicaciones de audio/vídeo que se recuperan adecuadamente de la pérdida ocasional de frames o cuadros.