Provisión de QoS en IP Asignatura: Redes de Banda Ancha Curso 2006/2007 Profesor: J. Carlos López Ardao
Exposición del problema El modelo de servicio extremo a extremo ofrecido por IP es best-effort (BE) los paquetes IP son indistinguibles unos de otros y todos reciben el mismo trato por parte de la red Aplicaciones tradicionales de Internet (Web, FTP, e-mail, Telnet) son orientadas a datos: Tolerantes a retardos, pero no a pérdidas (también llamado tráfico elástico por su capacidad para adaptarse al BW disponible) Servicio BE de IP junto con fiabilidad extremo a extremo de TCP resulta adecuado Sin embargo, nuevas aplicaciones multimedia (audio/vídeo e interactivas en general) son aplicaciones de tiempo real (tolerantes a pérdidas pero no a retardos, los datos poseen un plazo de entrega) Necesidad de garantías sobre el servicio, que se traduce en la necesidad de distinguir los paquetes y darles tratamientos diferenciados
Limitaciones del best-effort Retardo extremo a extremo Especialmente crítico en aplicaciones audio interactivas como telefonía o videoconferencia. Retardos > 400 ms. pueden dañar la interactividad de la conversación seriamente, por lo que suelen implicar descartes en el receptor. Variación del retardo (jitter) Datos multimedia son generados a tasa constante y deben ser reproducidos de la misma forma Necesidad de eliminar el jitter introduciendo un retardo artificial (búfer), suficientemente pequeño para no contribuir mucho al retardo extremo a extremo, pero suficientemente grande para que la mayoría de paquetes sean recibidos antes de su instante de reproducción.
Escenario aplicación multimedia T D r muestras o tramas/sg. T C r muestras o tramas/sg. Desempaquetador Decodificador T D Codificador Empaquetador T RED RED T B Búfer recepción T playout(0) = T 0 = T 0 + T C + T RED + T B + T D T i = T i-1 + 1/r
Limitaciones del best-effort Pérdidas Una ventaja del tráfico multimedia es su tolerancia a pérdidas (tasas < 2% suelen pasar inadvertidas) Estas pérdidas podrían eliminarse con TCP, pero La estrategia de retransmisión implica retardos que son habitualmente inaceptables El control de congestión en TCP implica reducción de tasa en emisión tras pérdidas sólo aceptable para tráfico elástico (del tipo VBR-nrt o ABR) Por ello, el protocolo usado es UDP (SSC no fiable) Para paliar los efectos en caso de pérdidas elevadas se usan distintas técnicas no excluyentes que permiten elevar el umbral permisible de pérdidas incluso hasta el 20%, dependiendo de la codificación: FEC (redundancia) Interleaving para paliar efectos de ráfagas de pérdidas. Incrementa el retardo. Ocultación de pérdidas (Loss concealing) en el receptor: Repetición, interpolación y predicción.
Calidad de servicio (Quality of Service QoS) Un mecanismo de provisión de QoS facilita un medio para distinguir paquetes y tratarlos de forma diferente De forma más general, el objetivo de la provisión de QoS es dar soporte a servicios que posean necesidades específicas: Ancho de banda Latencia (retardo extremo a extremo) Jitter (variaciones de la latencia) Pérdidas La provisión de QoS permitirá el despliegue sobre Internet de nuevas aplicaciones y oportunidades de negocio
Principios de la provisión de QoS I. Para cada flujo, las fuentes declaran su patrón de tráfico y los requisitos de QoS II. El marcado y clasificación permite a un router distinguir paquetes III. Las fuentes deben conformar (shape) su patrón de tráfico al declarado y la red debe monitorizar IV. (police) su cumplimiento Los flujos o clases de tráfico deben aislarse para evitar interferencias en las QoS, pero siempre mediante un uso lo más eficiente posible de los recursos de la red (BW y búferes) Mecanismos de planificación/asignación de recursos V. Se necesita un mecanismo de control de admisión: Admitir o rechazar un flujo si la QoS solicitada no puede ser satisfecha sin comprometer la de otros flujos ya aceptados.
Diagrama de bloques funcional La implementación de provisión de QoS en los routers de una red IP consta de dos fases: Distinción de paquetes: Clasificación: Agrupar en clases paquetes según algún criterio o regla Marcado: Código en cabecera. Interclase e intraclase Típicamente el marcado está relacionado con la función de Monitorización de tráfico, que implica una medición y posterior marcado/remarcado en función de ésta. También relacionado se halla el Conformado de tráfico a la salida para cumplir un SLA, que será monitorizado en el siguiente router Tratamiento diferenciado: planificación de recursos: búfer (AQM) y BW Clasificación de paquetes Monitorización tráfico Marcado/ remarcado Conformado de tráfico (shaping) Active Queue Management (AQM) Planificación de BW Router IP
Patrón de tráfico: Token Bucket Las fuentes deben conformar (shape) su patrón de tráfico según el declarado en el SLA. La red monitorizará (police) su cumplimiento Un patrón de tráfico se declara mediante una especificación Token Bucket(ρ,, C): C Cada paquete debe obtener un testigo equivalente en tamaño (bytes) para poder ser enviado. Los testigos se generan a tasa cte. ρ bps. y se acumulan en un bucket de tamaño C bytes. Parámetros de tráfico: CIR (Comitted Information Rate): Tasa sostenible garantizada a largo plazo. Equivalente conceptualmente al SCR de ATM PIR (Peak Information Rate): Tasa de pico. Equivalente conceptualmente al PCR de ATM PBS/CBS (Peak/Comitted Burst Size): Tamaño de ráfaga de pico y sostenible, usados respectivamente como tamaños de bucket en conformadores TB para PIR y CIR. CBS es conceptualmente equivalente al BT de ATM
Conformación con Token Bucket Para conformar una fuente CBR se usa un regulador TB(PIR, PBS). Típicamente PBS poseerá un valor pequeño. Para conformar una fuente VBR se usan dos reguladores TB en serie Uno para regular la tasa de pico TB(PIR, PBS) Otro, a continuación, para regular la tasa sostenible TB(CIR, CBS) CBS nos permite controlar la duración máxima permitida de una ráfaga a tasa PIR: T MÁX = CBS / (PIR - CIR)
Monitorización Marcadores Las funciones de monitorización de un flujo implican realizar medidas para verificar su conformidad. En función de los resultados de las mediciones, los paquetes son marcados según varias categorías, típicamente denominadas colores. Por ello, suele hablarse de marcadores o algoritmos de marcado. Se comenzó usando 2 colores (verde/rojo) para distinguir el tráfico conforme del no conforme (equiv. al IN/OUT de ATM), pero hoy es mucho más habitual el uso adicional de un tercer color (amarillo) que ofrece una mayor flexibilidad en cuanto al tratamiento posterior: Habitualmente el tráfico claramente no conforme (rojo) es descartado En cambio, el tráfico no conforme por poco (amarillo), típicamente es: Conformado, es decir, retardado para que cumpla el patrón acordado Remarcado con una prioridad inferior al conforme (verde)
Marcadores Token-Bucket: srtcm El marcador de tipotoken-bucket más simple es el GCRA usado en ATM, que marca ROJO los paquetes que no encontrasen testigos en el bucket equivalente, y VERDE en caso contrario. El algoritmo single rate Three Color Marker (srtcm - RFC 2697) usa dos buckets C y E, ambos con tasa CIR, y capacidades CBS y EBS (Excess Burst Size), de forma que el E sólo se rellena de testigos cuando C está lleno: Inicialmente ambos buckets están llenos Si un paquete halla suficientes testigos en el bucket C, los toma y se marca VERDE, si no si hay suficientes testigos en el bucket E, los toma y se marca AMARILLO, si no el paquete se marca ROJO, pero no toma testigo alguno. srtcm es útil cuando, además de la tasa CIR, la longitud de la ráfaga, y no la PIR, es relevante al servicio.
Marcadores Token-Bucket: trtcm Cuando se desea monitorizar ambas tasas, CIR y PIR, se usa el marcador two rate TCM (trtcm - RFC 2698). Se usan dos buckets P y C, con tasas PIR y CIR, y capacidades PBS y CBS: Un paquete que no halle suficientes testigos en el bucket P se marca ROJO, sin tomar testigo alguno. Si hubiese suficientes en P tomaría éstos, y en ese caso: Si no hubiese suficientes testigos en el bucket C, se marcaría como AMARILLO, sin tomar testigos de C Si hubiese suficientes testigos en el bucket C, los tomaría y se marcaría como VERDE
Marcador TSW-TCM Un marcador TSW-TCM (RFC 2859) usa un estimador de la tasa media sobre el tráfico recibido en una ventana temporal. Es un estimador de tipo TSW (Time-Sliding Window) Con la llegada de cada paquete se estima la tasa media R y, según su valor, se asigna el color al paquete: Si R CIR Paquete VERDE Si CIR < R PIR P A = (R CIR) / R Paquete AMARILLO con probabilidad P A (creciente con R) Paquete VERDE con probabilidad 1-P A Si R > PIR P R = (R PIR)/R y P A = (PIR CIR)/R Paquete ROJO con probabilidad P R (creciente con R) Paquete AMARILLO con probabilidad P A (decreciente con R) Paquete VERDE con probabilidad 1-(P R + P A ) El uso de una función de marcado probabilística resulta beneficioso para los flujos TCP ya que reduce la probabilidad de descartar múltiples paquetes de una ventana de envío TCP. Importantes trabajos de investigación recomiendan que el tamaño de la ventana para un flujo TCP sea igual al RTT (Round Trip Time) del flujo. En el caso de agregación de flujos, TCP o UDP, un valor de 1 seg. parece adecuado.
Planificación de búfer (AQM) Los mecanismos de planificación de búfer reciben también el nombre de mecanismos de gestión activa de cola (Active Queue Management - AQM) En ausencia de un mecanismo AQM en un router IP, todos los paquetes que llegan a un búfer lleno se descartan de forma indiscriminada, mecanismo que se denomina tail drop Sincronización global en TCP Solución: descarte no indiscriminado Se han propuesto diversos mecanismos de gestión de cola basados en en prioridades/clases: PBS (Partial Buffer Sharing): Un nodo con memoria B bytes y N umbrales 0 < B 1 < B 2 <... < B N = B descartará el tráfico de la clase i si la memoria ocupada es superior a B i bytes PushOut: Las celdas de mayor prioridad expulsan a las de menor prioridad cuando el búfer se llena
El algoritmo RED El mecanismo AQM más ampliamente usado es RED (Random Early Drop), basado en Descarte aleatorio de paquetes (para evitar la sincronización global en TCP) Tras detección temprana de la congestión (una vez superado un umbral del tamaño medio de la cola) Funcionamiento: A la llegada de un paquete se estima el tamaño medio Q de la cola de salida Q i+1 = Q i *a + q*(1 a) Si Q < min th Funcionamiento normal: Almacenamiento del paquete Si min th Q < max th Evitar congestión: El paquete se descarta con una probabilidad creciente linealmente con Q: P drop =P max *(Q min th )/(max th min th ) Si Q max th Congestión: Se descarta el paquete El comportamiento de RED viene determinado por el conjunto de parámetros (min th, max th, P max ). Se recomienda que max th sea dos o tres veces min th. Valores típicos de P max se hallan entre 0.01 y 0.2
Variantes de RED Una variante muy usada es RIO (RED IN/OUT), que usa RED con dos niveles de precedencia de descarte (dos conjuntos de parámetros), uno para paquetes IN y otro para OUT (max OUT < min IN ). En el cálculo de Q IN sólo se contabilizan los paquetes IN, mientras en el cálculo de Q OUT se contabilizan todos (IN y OUT) De la misma forma, se pueden usar tres conjuntos de parámetros (3 niveles de precedencia) cuando se usa un marcador de tres colores
Explicit Congestion Notification ECN El mecanismo de control de congestión actualmente usado por TCP, basado en el control del flujo, tiene dos serios inconvenientes: Adolece del problema de la sincronización global La indicación de congestión es generada localmente (sin participar la red) y de forma implícita (tras no recibir ACKs) Actualmente se está empezando a usar el mecanismo ECN, basado igualmente en el control del flujo, pero donde la notificación sea generada por la red (los routers IP) y sea una indicación explícita de la congestión. El mecanismo es similar al usado en ATM con el bit EFCI. En ECN, los routers IP usan el mismo mecanismo de detección temprana de congestión de RED. La diferencia radica en que cuando RED descartaría un paquete, en ECN se reenvía pero se notifica la congestión a la fuente TCP de forma explícita.
Planificación de BW Estos mecanismos de planificación se usan para decidir cuál será el próximo paquete a enviar sobre un enlace dado. FIFO y PQ (Priority Queueing) no garantizan BW mínimo ni equidad en su asignación Disciplinas basadas en GPS (Generalized Processor Sharing) Dadas N colas con pesos w i para un enlace de capacidad C, GPS reparte este BW entre todas las colas no vacías de forma proporcional al peso, de forma que en cada instante la tasa de servicio para una cola no vacía i es exactamente R j = C. (w j / k no vacía w k ) GPS es un algoritmo ideal, imposible de implementar, dado que asume que el servidor puede atender simultáneamente todas las colas no vacías (a una tasa de servicio R j ) y que el tráfico es fluido, cuando en un sistema realista sólo se puede atender una cola cada vez (a tasa máxima C) y el tráfico consta de paquetes de longitud variable. Todas las aproximaciones hacen uso de un reparto en Round-Robin
WFQ (Weighted Fair Queueing) WFQ es la aproximación de GPS más ampliamente usada WFQ emula un servidor GPS de referencia, eligiendo, en cada instante en que el servidor queda libre, aquel paquete que primero terminase servicio en el servidor GPS de referencia si no llegasen paquetes posteriormente. WFQ presenta diferencias de funcionamiento frente a GPS. Típicamente favorece a las colas con mayor peso Se pueden anidar 2 niveles de WFQ CBQ (Class-Based Queueing) Se consideran clases de tráfico y se usa un WFQ entre clases. Cada clase i posee un peso W i Dentro de cada clase se distinguen colas o flujos. Cada cola j de la clase i posee un peso relativo w ij (típicamente son iguales y el ancho de banda de cada clase se reparte equitativamente entre los flujos activos) El peso absoluto de una cola o flujo individual es W ij = W i x w ij
TB y GPS (WFQ): Retardo acotado Suposiciones caso ideal: Flujo fluido conformado con Token Bucket(C, ρ) Todos los routers para dicho flujo usan GPS y garantizan BW mínimo R>ρ Peor caso: nos encontramos con el bucket lleno Retardo máximo en primer router = C/R Siguientes routers: Dado que la tasa de salida (R) es siempre mayor que la de entrada (ρ ) Retardo = 0 Retardo máx. extremo a extremo T MAX C/R Si consideramos WFQ y un flujo con paquetes de tamaño máx. m (M en la red), H saltos y R j velocidad de tx. en cada enlace j [Parekh 92]: T MAX C R ( H + 1) m R + H j= 1 M R j
Servicios integrados (IntServ) IntServ es una arquitectura propuesta para Internet en el seno de IETF, con el objetivo de dar garantías QoS a sesiones de aplicación individuales (flujos), basándose en: Reserva de recursos Control de admisión Procedimiento: Un flujo declara su patrón de tráfico (TSpec [RFC 2210]) y QoS deseada (RSpec [RFC 2215]), enviados a cada router atravesado mediante un protocolo de señalización (como RSVP) Cada router verifica si dispone de recursos suficientes, reservándolos en caso afirmativo y rechazando la sesión en caso negativo.
IntServ : Clases de servicio La arquitectura IntServ define dos clases de servicio básicas: Servicio garantizado [RFC 2212]: Para aplicaciones de tiempo real que necesitan garantías cuantitativas firmes de QoS. Servicio de carga controlada [RFC 2211]: Para aplicaciones elásticas, incluso de tiempo real, como las que se han diseñado para la Internet actual, que son relativamente tolerantes a retardos pero muy sensitivas a congestión. El servicio es cualitativamente bueno (pérdidas y retardos bajos) pero no se dan garantías cuantitativas.
IntServ : Servicio garantizado Un flujo se caracteriza por un Token Bucket (ρ, C) que solicita la reserva (vía RSVP) de una tasa de transmisión garantizada R>ρ. Tal garantía se implementa habitualmente en los routers mediante WFQ, que, como vimos, implica un retardo en cola extremo a extremo acotado. Basado en esta información, cada router usa control de admisión para decidir si se acepta el flujo, en cuyo caso el router debe monitorizar el patrón de tráfico (a los flujos no conformes se les dará servicio best-effort)
IntServ : Servicio carga controlada La QoS recibida será similar cualitativamente a la que se recibiría de una red best-effort poco cargada (pérdidas casi nulas y retardos bajos). Debido a esta definición tan vaga de QoS, este servicio requiere menos complejidad que el garantizado. Como en el servicio garantizado, el flujo debe facilitar una especificación Token Bucket que debe ser monitorizada por la red. Una implementación plausible sería tratar todo el tráfico de este tipo como un único flujo al que se garantiza conjuntamente un BW mediante WFQ, usando adicionalmente control de admisión para limitar la cantidad total de tráfico de este tipo.
Tipos de servicio en IntServ Servicio Características Similitud con ATM Garantizado Garantiza un caudal mínimo y un retardo máximo Cada router del trayecto debe dar garantías A veces no puede implementarse por limitaciones del medio físico (Ej. Medios Compartidos) CBR y VBRrt Carga controlada Calidad similar a la de una red de datagramas poco cargada Se supone que el retardo es bajo, pero no se dan garantías VBR-nrt y ABR Best-effort Ninguna garantía UBR
Reparto de recursos en IntServ Best Effort Caudal Carga controlada Garantizado Tiempo
RSVP (ReSerVation Protocol) RSVP [Zhang 93; RFC 2205] es el protocolo de señalización usado en IntServ para permitir a las aplicaciones establecer y liberar reservas de recursos en Internet (típicamente BW), de forma similar a como se hace en las clásicas redes orientadas a conexión Características principales de RSVP: Permite reservas de recursos sobre árboles multicast (el unicast se trata como una degeneración del multicast), adaptándose dinámicamente a cambios de rutas y de configuración de grupos. En oposición a la filosofía clásica, el receptor inicia y mantiene una reserva para cada flujo de datos. En el caso bidireccional debe ser realizada por cada extremo. También a diferencia del esquema clásico (hard state), las reservas en los routers son mantenidas sólo durante un tiempo, debiendo ser refrescadas por los receptores (soft state), lo que además permite que éstas sean adaptativos. Permite la convivencia con routers que no implementan RSVP (tanto IPv4 como IPv6) y que, por tanto, sólo ofrecen el clásico servicio BE. Prevé distintos estilos de reserva, permitiendo que las reservas multicast que confluyen en un router puedan fusionarse si se desea.
Qué no es RSVP? RSVP no especifica la forma en que la red debe garantizar el BW reservado RSVP no es un protocolo de encaminamiento, ni decide sobre qué enlaces se deben hacer las reservas. Depende de un protocolo de encaminamiento subyacente que decide las rutas unicast o árboles multicast a usar. RSVP no define tests de admisión pero supone que los routers implementan alguno y que puede interactuar con ellos para continuar con el proceso de reserva o para comunicar el rechazo al receptor.
RSVP: Mecanismo de reserva El emisor envía un mensaje PATH que contiene su TSpec a un destino unicast o a un grupo multicast. Los routers añaden su dirección IP al mensaje PATH antes de reenviarlo y aprenden cuál es su router upstream (hacia arriba) El receptor responderá al mensaje PATH con un mensaje RESV que contiene la TSpec del emisor y la RSpec (típicamente BW) deseada. Este mensaje recorrerá el camino inverso al PATH a través de una ruta unicast o de un árbol multicast. Cada router, si acepta la reserva, le asigna los recursos necesarios hacia abajo y reenvía upstream una nueva reserva que depende del estilo de reserva usado (compartición o no de recursos entre emisores), y que puede suponer la fusión de varias reservas downstream. Para actualizar las rutas ante eventuales fallos se envían mensajes PATH cada cierto tiempo ( 30 segs.), desencadenando el envío por parte de los receptores de nuevos mensajes RESV para mantener la reserva o realizar otra por la nueva ruta. En este último caso, las reservas antiguas serán liberadas tras vencer la temporización.
RSVP: Mecanismo de reserva Los mensajes RSVP son enviados salto a salto entre routers RSVP mediante túneles a través de IP (protocolo=46) Si una reserva es rechazada, debe enviarse un mensaje ResvError hacia arriba en el árbol para deshacer las reservas ya realizadas. Habitualmente los receptores de una sesión multicast son heterogéneos (distintas tasas de recepción). Por ello, se han popularizado los codificadores multicapa, que permiten codificar los flujos de audio y vídeo en capas a distintas tasas. El emisor sólo debe conocer la tasa máxima de sus receptores y enviar tráfico a dicha tasa a través del árbol multicast
RSVP: Mecanismo de reserva Emisor PATH R RESV (1 M) (fusión) R RESV (1 M) R Receptor A R RESV (100 K) Receptor B
Inconvenientes de IntServ Escalabilidad: La reserva de recursos mediante RSVP y el mantenimiento del estado de cada flujo que atraviesa un router resulta muy poco eficiente si el número de flujos es muy elevado (más de 250.000 en uno troncal) Flexibilidad: IntServ no permite definir clases de servicio cualitativamente distintas (p. ej., la clase A recibiría un trato preferente sobre la B) que, entre otras ventajas, permitiría que la tarificación resultase mucho más sencilla e intuitiva que la realizada en base a requisitos cuantitativos.
Problema de escalabilidad de RSVP Estos routers han de mantener información sobre muchos flujos y por tanto mucha información de estado Core de Internet
Problemas de IntServ/RSVP Los fabricantes de routers no han desarrollado implementaciones eficientes de RSVP, debido al elevado costo que supone la implementación HW de las funciones de mantenimiento de la información de estado A pesar de todo, RSVP/IntServ puede desempeñar un papel en la red de acceso, donde los enlaces son de baja capacidad y los routers soportan pocos flujos Recientemente ha resurgido el interés por RSVP por su aplicación en MPLS y funciones de ingeniería de tráfico. En estos casos, el número de flujos no suele ser muy grande
RFCs sobre IntServ/RSVP RFC 1633 (6/1994): Integrated Services in the Internet Architecture: an Overview RFC 2205 (9/1997): RSVP Version 1 Functional Specification RFC 2206 (9/1997): RSVP MIB using SMIv2 RFC 2207 (9/1997): RSVP Extensions for IPSEC Data Flows RFC 2208 (9/1997): RSVP Version 1 Applicability Statement Some Guidelines on Deployment RFC 2209 (9/1997): RSVP Version 1 Message Processing Rules RFC 2210 (9/1997): The Use of RSVP with IETF Integrated Services RFC 2211 (9/1997): Servicio de carga controlada RFC 2212 (9/1997): Servicio Garantizado RFC 2213 (9/1997): Integrated Services Management Information Base Using SMIv2 RFC 2214 (9/1997): Integrated Services MIB Guaranteed Service Extensions using SMIv2 RFC 2215 (9/1997): General Characterization Parameters for Integrated Services RFC 2379 (8/1998): RSVP over ATM Implementation Guidelines RFC 2380 (8/1998): RSVP over ATM Implementation Requirements RFC 2382 (8/1998): A Framework for Integrated Services and RSVP over ATM RFC 2490 (1/1999): A Simulation Model for IP Multicast with RSVP RFC 2688 (9/1997): Integrated Services Mappings for Low Speed Networks RFC 2689 (9/1999): Providing Integrated Services over Low-bitrate Links RFC 2745 (1/2000): RSVP Diagnostic Messages RFC 2746 (1/2000): RSVP Operation over IP Tunnels RFC 2747 (1/2000): RSVP Cryptographic Authentication RFC 2748 (1/2000): The COPS (Common Open Policy Service) Protocol RFC 2749 (1/2000): COPS usage for RSVP RFC 2750 (1/2000): RSVP Extensions for Policy Control RFC 2752 (1/2000): Identity Representation for RSVP RFC 2814 (5/2000): Subnet Bandwidth Manager (para RSVP Admis. Ctrl) RFC 2815 (5/2000): Integrated Service Mappings on IEEE 802 Networks RFC 2816 (5/2000): A Framework for Integrated Services Over Shared and Switched IEEE 802 LAN Technologies RFC 2872 (6/2000): Appl. and Sub Appl. Ident. Policy Elem. for RSVP RFC 2961 (4/2001): RSVP Refresh Overhead Reduction Extensions RFC 2996 (11/2000): Format of the RSVP DCLASS Object RFC 2998 (11/2000): A Framework for Integarted Services Operation over Diffserv Networks RFC 3006 (11/2000): Integrated Services in the Presence of Compressible Flows RFC 3097 (4/2001): RSVP Cryptographic Authentication RFC 3175 (9/2001): Aggregation of RSVP for IPv4 and IPv6 Reservations RFC 3182 (10/2001): Identity Representation for RSVP RFC 3209 (12/2001): RSVP-TE: Extensions to RSVP for LSP Tunnels RFC 3210 (12/2001): Applicability Statement for Extensions to RSVP for LSP-Tunnels
Servicios diferenciados (DiffServ) DiffServ [RFC 2475] resuelve los problemas de IntServ fijando el número de posibles categorías de servicio, siendo por tanto independiente del número de flujos o usuarios; y de complejidad constante Así, en vez de distinguir flujos individuales, en DiffServ se clasifican los paquetes en clases a la entrada de la red (o dominio), donde se marcan adecuadamente. Posteriormente, los routers tratan cada paquete según su clase ofreciendo servicio diferenciado por clase (comportamiento agregado) DiffServ se basa únicamente en el marcado de paquetes. No hay reserva de recursos por flujo, no hay protocolo de señalización, no hay información de estado en los routers (se halla contenida en los paquetes) Aunque las garantías QoS no son tan severas como en IntServ, en muchos casos se consideran suficientes Una de las principales características de DiffServ es la distinción entre la frontera (edge) y el núcleo (core) de un dominio DS: En la frontera Marcado y Clasificación de paquetes y monitorización (medida + marcado/remarcado) En núcleo Reenvío (forwarding) de paquetes mediante la asignación de recursos por clase (búfer + BW)
DiffServ: La frontera (I) Los nodos frontera son aquellos que suponen la entrada/salida a/de un dominio DS y, por tanto, son los que se interconectan con otros dominios y con los hosts Aunque son funcionalmente muy similares, se suele distinguir entre los routers periféricos o de acceso (que dan servicio a los clientes finales) y los frontera (que interconectan dominios) En la frontera de un dominio se define el contrato de servicio (Service Level Agreement SLA) que el cliente espera recibir del proveedor. Este contrato incluye también el perfil de tráfico del usuario (Traffic Conditioning Agreement TCA), que típicamente consistirá en una descripción Token-bucket En los routers frontera, los paquetes IP son clasificados y marcados en el octeto DS de IPv6 (TOS en IPv4) [RFC 2474]. La clasificación en un router frontera se hace en base a ciertos campos de su cabecera: dirs. IP, puertos, protocolo, etiqueta de flujo (IPv6), campo DS, interfaz de entrada, etc.
DiffServ: La frontera (II) Tasa A Paquetes usuario Clasificación y marcado basado en clases. Dos tipos de marcado: Marcado interclase: paquetes de clases diferentes son marcados de forma diferente Marcado intraclase: la porción conforme (IN) del flujo se marca de forma diferente a la no conforme DiffServ sólo facilita la arquitectura marco para la provisión de QoS DiffServ no especifica cómo se realiza la clasificación o el marcado, ni qué acciones se deben tomar en caso de incumplimiento del patrón de tráfico (marcado intraclase, conformación, descarte,...) B
Campo DS (RFC 2474) Campo DS DSCP ECN DSCP: Differentiated Services CodePoint. Seis bits que indican el tratamiento que debe recibir este paquete en los routers ECN: Campo inicialmente reservado para usos futuros, usado actualmente de forma experimental para el mecanismo ECN de control de congestión El campo DS, con igual longitud y formato que en IPv4, se coloca en IPv6 sustituyendo al campo prioridad (de 4 bits) y a los cuatro primeros bits del campo etiqueta de flujo que se reduce de 24 a 20 bits
Aparición del campo DS en IPv4 e IPv6 IPv4 Antes Precedencia D T R C X IPv4 e IPv6 Ahora DSCP ECN IPv6 Antes Prioridad Etiq.. de Flujo (1-4) Los tres primeros bits se interpretan como prioridad en todos los casos por compatibilidad con muchos routers
Campo DSCP 6 bits = 64 codepoints (categorías de tráfico) diferentes. De momento se han dividido en 3 grupos: Codepoint cccdd0 xxxx11 xxxx01 Valores 32 16 16 Uso Estándar Local/experimental Reservado En el grupo estándar los tres primeros bits (ccc) indican la clase, y los dos siguientes (dd) se usan para marcado intraclase (mayor o menor precedencia de descarte)
DiffServ: El núcleo (core) Los routers DS interiores a un dominio tratan a los paquetes salto a salto y sólo en base a su clase. Es lo que se denomina Per-Hop Behavior (PHB) Un PHB es una descripción del comportamiento de envío externamente observable (medible) en un nodo DS, aplicado a una clase en particular Un router no DS aplicará el mismo PHB (es decir, best-effort) a todo el tráfico (clase única) DiffServ distingue claramente entre el PHB y su implementación: mientras se mantenga el criterio de diferencia de prestaciones observable, DiffServ permite implementar cualquier mecanismo de asignación de recursos para lograrlo El grupo de trabajo DiffServ en IETF ha definido dos PHBs: Expedited Forwarding (EF) [RFC 2598] Assured Forwarding (AF) [RFC 2597]
DiffServ: EF PHB El PHB Expedited Forwarding (EF) [RFC 2598] ofrece un SLA que, básicamente, garantiza un BW mínimo El valor DSCP es 101110 EF está pensado para aplicaciones que Requieran retardos, pérdidas y/o jitter muy bajos (colas muy pequeñas), de forma equivalente a un servicio VBR-rt de ATM. También recibe el nombre de servicio Premium. No se dan garantías cuantitativas para tasa de perdidas, retardo o jitter Requieran una tasa de pico garantizada (equivalente a CBR). Desde el punto de vista de las aplicaciones se trata de una especie de conexión punto a punto o línea virtual alquilada
Implementación de EF PHB Este servicio no se implementa mediante la reserva estática de BW como en IntServ (en DiffServ no se usa un protocolo de reserva como RSVP), sino que se implementa de forma más eficiente garantizando que la tasa de salida en cualquier enlace de la ruta es mayor o igual que la tasa de entrada, en cualquier intervalo de tiempo. Ello implica: Configurar los routers para asignar el BW suficiente a todo el tráfico de esta clase (p.ej, mediante WFQ), o asignándole prioridad máxima (si se usa PQ) Monitorizar en la frontera la tasa de pico de todos los flujos EF, y conformar (retardando o descartando) el tráfico OUT Usar control de admisión. Una aproximación simple, pero conservativa, sería garantizar que la suma de las tasas de todos los flujos EF entrantes a un dominio fuese menor que el BW mínimo reservado para EF en cualquier enlace del dominio.
DiffServ -Assured Service El PHB Assured Forwarding (AF) está basado en el assured service (AS) Características principales de AS: Se asegura que el tráfico conforme al perfil contratado para un flujo será entregado sin pérdidas con probabilidad muy alta, aún en caso de congestión Se permite exceder el perfil, pero con la comprensión de que el tráfico en exceso no será entregado con una probabilidad tan alta Se garantiza la secuencialidad dentro de cada flujo, independientemente de que los paquetes sean conformes o no EL AF-PHB ofrece hasta 4 niveles de servicio preferencial del tipo AS sin fijar garantías (no hay SLA). Podría compararse con la categoría VBR-nrt
DiffServ: AF PHB El PHB Assured Forwarding (AF) [RFC 2597] permite ofrecer distintos niveles de garantía de entrega o de calidad relativa: Se definen 4 clases y se asegura un trato diferenciado entre ellas, pero no se garantizan caudales, retardos, etc. No obstante, el ISP puede ofrecer la contratación de distintos caudales por clase Se puede asignar una cantidad de recursos (BW y búferes) diferente a cada clase, pero cada router debe garantizar que el nivel de servicio ofrecido a cada clase sea siempre superior al de una clase de menor prioridad Dentro de cada clase, los paquetes se pueden clasificar a su vez en hasta tres categorías de preferencia de descarte (dependiendo del marcado en la frontera), que recibirán tratamiento diferenciado según otros tantos algoritmos de tipo RED El nivel de garantía de entrega de un paquete IP dependerá de: Los recursos asignados a su clase AF La carga actual de la clase AF En caso de congestión en la clase AF, la precedencia de descarte del paquete La monitorización en la frontera de un dominio puede determinar si se realiza conformación (retardo/descarte) o si se remarcan los paquetes (aumento de la precedencia de descarte)
Codepoints del Servicio AF (RFC2597) Menor probabilidad de descarte Precedencia de descarte dd Mayor probabilidad de descarte Clase ccc Baja 01 Media 10 Alta 11 Mayor prioridad 4 100 10001 10010 10011 3 011 01101 01110 01111 2 010 01001 01010 01011 Menor prioridad 1 001 00101 00110 00111
Otros codepoints Las clases 111 y 110 están reservadas para paquetes de control de la red y protocolos de routing El DSCP 000000 es por defecto el servicio Best Effort sin prioridad. Otros DSCP de la clase 000 pueden usarse para servicios Best Effort con prioridad (también usados hoy en día)
Tipos de servicio en DiffServ Servicio EF-PHB o Premium AF-PHB BE con prioridad BE sin prioridad Es el que da más garantías. Equivale a una línea dedicada Garantiza Caudal Tasa de pérdidas, retardo y jitter muy bajos Valor 101110 en DSCP Características Asegura un trato preferente, pero sin fijar garantías (no hay SLA) Se definen cuatro clases y en cada una tres niveles de descarte de paquetes Sin garantías, pero obtendrá trato preferente frente a best-effort sin prioridad Sin garantías, obtiene sólo los restos Equivalencia en ATM CBR y VBR-rt VBR-nrt ABR UBR
Reparto de recursos en DiffServ BE sin prioridad Caudal BE con prioridad AF-PHB EF-PHB o Premium Tiempo
DiffServ: Implementaciones Una posible implementación de los PHBs EF, AF y BE es mediante WFQ o PQ Lo más habitual es usar PQ entre PHBs y WFQ entre las clases AF Para garantizar cierto BW al servicio BE, podría introducirse también en el WFQ considerándolo como una clase AF más (la menos prioritaria) o como la AF1 con mayor probabilidad de descarte (color rojo) Si las pérdidas bajas no son un objetivo, puede implementarse un servicio de bajo retardo sobre AF- PHB, sin necesidad de recurrir al EF PHB, estableciendo para ello un tamaño de búfer pequeño para una clase AF
Cola EF Cola AF 4 PQ Cola AF 3 Cola AF 2 Cola AF 1 WFQ WFQ/ PQ Línea de salida Cola BE
El Bandwidth Broker (BB) en DiffServ La información necesaria para monitorizar y gestionar los recursos de red disponibles en un dominio DS es mantenida para dicho dominio por un agente servidor denominado el Bandwidth Broker (BB) El BB se encarga de decisiones de control de admisión, gestión de los recursos de red, configurar los routers periféricos y frontera Los clientes en los routers intercambian información con el servidor mediante el protocolo BBTP (Bandwidth Broker Transport Protocol) El BB puede intercambiar información con otros BB de otras redes (dominios). Los ISPs pueden acordar políticas de intercambio mutuo
Arquitectura DiffServ Origen Bandwidth Brokers (control de admisión, gestión de recursos, configuración de routers) Destino BB BB AS ISP 1 AS ISP 2 Routers core Routers core Router periférico (clasificación, marcado y monitorización) Router frontera saliente (conformar agregados) Router frontera entrante (clasificación, marcado y monitorización de agregados)
RFCs Diffserv RFC 2430 (10/1998): A Provider Architecture for DiffServ and Traffic Eng. RFC 2474 (12/1998): Definition of the DS field in the IPv4 and IPv6 Headers RFC 2475 (12/1998): An Architecture for Differentiated Service RFC 2597 (6/1999): Servicio Expedited Forwarding RFC 2598 (6/1999): Servicio Assured Forwarding RFC 2638 (7/1999): A Two-bit DiffServ Architecture for the Internet RFC 2963 (10/2000): A Rate Adaptive Shaper for Differentiated Services RFC 2983 (10/2000) Differentiated Services and Tunnels RFC 3086 (4/2001): Def. of DiffServ Per Domain Behaviors & Rules for Spec. RFC 3270 (5/2002): MPLS Support of DiffServ RFC 3287 (7/2002): Remote Monitoring MIB Extensions for DiffServ RFC 3289 (5/2002): Management Information Base for the DiffServ Architect.
IntServ vs DiffServ Aunque IntServ fue desarrollado con anterioridad, DiffServ se ha extendido más DiffServ permite agregar flujos el modelo es escalable. Debido a estas diferencias muchos fabricantes de routers implementan versiones eficientes de DiffServ, pero no de IntServ. Actualmente, muchos ISP implementan DiffServ. Qbone (red expermiental de QoS en Internet 2) utiliza el modelo DiffServ.
IntServ vs DiffServ RSVP/IntServ Información por flujo en cada router Problemas de escalabilidad Énfasis en multicast BB DiffServ BB Cada red tiene un BB que gestiona sus recursos Recursos controlados en acceso a la red Paquetes clasificados por categorías Enfocado a tráfico agregado, no a flujos
Combinación de RSVP y DiffServ RSVP DiffServ RSVP RSVP RSVP En la periferia de la red el uso de RSVP no plantea problemas y puede ser necesaria la reserva estricta de recursos En este caso, el router que conecta con el core traducirá la petición al servicio DiffServ más parecido.