Diffserv: Servicios Diferenciados

Transcripción

1 Diffserv: Servicios Diferenciados Monografía de Evaluación de Performance en Redes de Telecomunicaciones Adrián Delfino Sebastián Rivero

2 1. INTRODUCCIÓN La palabra Calidad de Servicio (QoS), ha sido frecuentemente usada con una variedad de significados diferentes. Nosotros la usaremos para describir un grupo de parámetros mensurables, como ser retardo, throughput y tasa de pérdidas que pueden estar adjuntados a algún subgrupo identificable de paquetes de IP, a través de un cierto dominio. 1.1 Trasfondo: hacia una calidad de servicio amigable en Internet El sistema telefónico es bastante diferente de la Internet. El sistema telefónico, al menos en su forma eléctrica pura original, tenía un simple problema de congestión y un requerimiento igualmente simple de calidad de servicio. El problema de congestión era que debía haber un camino eléctrico reservado disponible entre dos terminales; lo cual es un estado binario. El problema de la calidad era que éste camino debía tener un ancho de banda y ganancia adecuados y ruido suficientemente bajo para poder transmitir una señal de voz legible. Hoy en día sigue siendo cierto que un camino reservado y cierto grado de calidad, son las dos características definitorias de una llamada telefónica estándar. En Internet no hay requerimiento de un camino reservado de la fuente al destino. Los caminos son determinados por tablas de ruteo en cada salto, y pueden variar debido a extrañas circunstancias, a pesar que en la mayoría de los casos son constantes durante la sesión. Al mismo tiempo, los paquetes son de tamaño variable, típicamente entre 20 y 4000 bytes. La llegada de paquetes a los enlaces de una red es tanto aleatoria como en ráfagas. Lo anterior implica que aún cuando la tasa promedio de tráfico sea chica, largas ráfagas arbitrarias de tráfico a velocidad máxima de hardware son de esperarse. Períodos de congestión son por lo tanto comunes en la Internet, resultando en pérdida de paquetes como en jitter. Medidas realizadas muestran que el patrón dominante de tráfico es caracterizado por cortas sesiones con muchos paquetes por cada una. En resumen, la Internet no tiene un requerimiento de calidad de servicio estándar ni un modelo analítico trazable de tráfico. Las tendencias en Internet hoy en día son caracterizadas por un fuerte crecimiento, por procurar ofrecer servicios diversos sobre la red y por buscar simplificar la operación y la gestión. La Internet de hoy se compone de una compleja interconexión de dominios de redes, algunos bajo las mismas entidades administrativas y otros bajo distintas entidades administrativas. Actualmente, la mayoría de estos dominios tienen mas capacidad disponible en sus interiores y más limitada en sus bordes. Pero esto no se espera siga así indefinidamente, ya que la Internet ha sido objeto de continuos cambios y los ha sobrellevado al permanecer fiel a sus principios originales que la hacen escalable. Monografía de Ev. de Performance:Diffserv 1

3 1.2 Acercamientos previos Precedencia IP y TOS: En el diseño original de IP, un byte conocido como octeto de tipo de servicio fue reservado en la cabecera de cada paquete. Contenía dos importantes campos: 3 bits correspondientes al valor de precedencia y 3 bits de tipo de servicio (TOS). La precedencia fue un intento de una marcador de prioridad, donde 0 recibía el peor tratado y 7 el mejor. El tipo de servicio se identificaba como bajo retardo, alto throughput y alta confiabilidad. Lamentablemente no había una arquitectura de marco de trabajo en donde emplear este octeto de tipo de servicio y por ende ninguna explicación de cómo estas propiedades podían ser implementadas. En la práctica los bits de TOS han sido de poco uso y en general ignorados. SNA: La Arquitectura de Sistemas de Red ha distinguido varias clases de servicios. Este tipo de acercamiento, sin embargo, funciona solo dentro del contexto de una red manejada en forma muy apretada con recursos cuidadosamente asignados para un número pequeño de tipos de tráfico. ST: El Protocolo de Flujo de Internet, fue un intento de acomodar flujos de tráfico en tiempo real en paralelo con tráfico TCP/IP, agregando un segundo protocolo orientado a la conexión, en paralelo con IP. Fracasó en el intento de crecer fuera de una comunidad experimental. Servicios Integrados (IntServ): Especifica un mecanismo para soportar sesiones de punta a punta a través de Internet, que necesitan una específica calidad de servicio. Requiere de un módulo en cada router IP a lo largo de la trayectoria, que reserva recursos para cada sesión y entonces se asegura que cada paquete de datos en tránsito sea chequeado para ver qué recursos le corresponden recibir. Estas reservaciones son pedidas usando un protocolo de reserva de recursos conocido como RSPV. Si la solicitud de RSPV falla, entonces la sesión no se inicia. Una de las desventajas es que necesita de nuevo software tanto en el envío de paquetes y en el control de todos los routers a lo largo del camino de la red concerniente. Otra desventaja es que si fuera usado en la mayoría de las principales conexiones ISP, llevando millones de paquetes por segundo, el overhead por paquete en la implementación de los chequeos necesarios y administración de los recursos se cree ser ampliamente inaceptable. Aparte, en IntServ, el Sistema Autónomo o los límites del proveedor son esencialmente invisibles. En general, el fracaso de IntServ se debe principalmente a que en tomo un camino en donde deja atrás las raíces del éxito de IP y adoptó la noción de que QoS significa conexiones. El modelo orientado a la conexión no puede ser usado para traer una QoS viable de punta a punta a la Internet, por asumir un modelo de la Internet que es homogéneo administrativamente. Monografía de Ev. de Performance:Diffserv 2

4 1.3 Un acercamiento más nuevo Más recientemente, la IETF ha tenido otro acercamiento: los Servicios Diferenciales (DiffServ). DiffServ se basa en un marco de trabajo arquitectónico que reconoce la entidad relevante para servicios garantidos efectivos en la Internet es el dominio administrativo de un único operador de red. Entonces el modelo esta orientado hacia un servicio borde a borde a través de un dominio único, con un apropiado Acuerdo de Nivel (Level Agreement, LA) que se asume esta en su lugar en los bordes del dominio. El énfasis ha sido en desarrollar bloques de construcción de QoS antes que los servicios, reconociendo la necesidad de mecanismos altamente escalables con un mínimo impacto en los elementos de los caminos donde van los datos de los routers del núcleo, los cuales manejan enlaces de multi-gigabits. Finalmente, a diferencia de ST o IntServ, evita la creación de información de estado a lo largo del camino de cada flujo de tráfico individual. En dominios no capaces DS: las fuentes de tráfico y nodos intermedios en un dominio no DS pueden emplear acondicionadores de tráfico para pre-marcar el tráfico antes de que llegue al ingreso de un dominio DS inferior. De esta manera las políticas locales para clasificación y marcado pueden ser canceladas. En nodos DS interiores: aunque la arquitectura básica asume que las funciones de clasificación y condicionamiento están localizadas solo en los nodos frontera de ingreso y egreso de la red, el despliegue de estas funciones en el interior de la red no se descarta. Comportamientos en cada salto Un per-hop behavior (PHB) es una descripción observada externamente del comportamiento de envío de un nodo DS aplicada a un behavior agregate DS en particular. Comportamiento de envío es un concepto general en este concepto. Útiles distinciones de comportamiento son principalmente observadas cuando múltiples agregados de comportamiento compiten por recursos de buffer y ancho de banda en un nodo. El PHB es el medio por el cual un nodo aloja recursos a los agregados de comportamiento. El ejemplo más simple de un PHB es uno que garantiza una mínima localización de ancho de banda de un porcentaje X del enlace a un BA (sobre un intervalo razonable de tiempo). Este PHB puede ser medido en forma justa y simple, bajo una variedad de condiciones de competencia de tráfico. Un PHB ligeramente más complicado sería garantizar un alojamiento de ancho de banda mínima de un porcentaje X del enlace, con un reparto proporcional justo de cualquier exceso de capacidad del enlace. Los PHB pueden ser especificados en términos de su prioridad de recursos relativa a otros PHB s, o en termino de sus características relativas de tráfico observable. Monografía de Ev. de Performance:Diffserv 3

5 Estos PHB s pueden ser usados como bloques de construcción para alojar recursos y deben ser especificados como un grupo (grupo PHB) para lograr consistencia. Un PHB único, definido aparte, es un caso especial de un grupo PHB. Los PHB son implementados en nodos por medio de algunos mecanismos de manejo de buffer y despachado de paquetes. Son definidos en términos de la características de comportamiento relevantes a las políticas de provisionamiento de servicios, y no en términos de mecanismos de implementación particulares. Es probable que más de un grupo PHB sea implementado en un nodo y sea utilizado dentro de un dominio. Un PHB es seleccionado en un nodo por medio del mapeado del código DS en un paquete recibido. PHB s estándares tienen un código recomendado. Sin embargo, el espacio total de código es mas largo que el espacio disponible para los códigos recomendados para los PHB s estándar, y el campo DS deja provisiones para mapeos configurables localmente. Todos los códigos deben ser mapeados a algún PHB, y en ausencia de alguna política local, los códigos que no están mapeados a un PHB estándar, deben ser mapeados a un PHB por defecto. Alojamiento de recursos de la red La implementación, configuración, operación y administración de los grupos PHB soportados en los nodos de un dominio DS deben efectivamente particionar los recursos de esos enlaces de nodos e inter-nodos, entre BA, en concordancia con las políticas de provisionamiento de servicios de los dominios. La configuración e interacción entre acondicionadores de tráfico y nodos interiores, debe ser manejada por el control administrativo del dominio y puede requerir control operacional a través de protocolos y una entidad de control. 1.4 Interoperabilidad con nodos no DS capaces Se define un nodo no capaz de soportar Servicios Diferenciales, como cualquier nodo que no interpreta el campo DS y/o no implementa algunos o todos de los PHB s estándares. Se define un nodo de legado como un caso especial de un nodo no capaz de soportar DS, que implementa clasificación de precedencia y envío IPv4 tal como esta definido en los RFC791 y RFC1812, pero que es de cualquier forma no capaz de soportar DS. Una distinción clave entre el nodo de legado y el no capaz de soportar DS es que el nodo de legado puede o no interpretar los bits 3-6 del octeto TOS tal como se define en el RFC1349. Los nodos que no son capaces de soportar DS y que no son nodos de legado pueden exhibir comportamientos de envío impredecibles para paquetes con códigos DS con valores distintos de cero. Monografía de Ev. de Performance:Diffserv 4

6 Consideraciones multicast Los paquetes multicast que entran en un dominio DS por un nodo de ingreso pueden tomar simultáneamente múltiples caminos a través de algunos segmentos del dominio debido a la replicación multicast de paquetes. En esta manera ellos consumen más recursos de red que los paquetes unicast. Puede ser dificultoso el proveer garantías cuantitativas de servicio a transmisores multicast. Es más, puede ser necesario reservar códigos y PHB s para uso exclusivo de tráfico unicast, para proveer de una aislamiento de recursos del tráfico multicast. Monografía de Ev. de Performance:Diffserv 5

7 2. Motivaciones del uso de DiffServ 2.1 Por qué necesitamos QoS en las redes IP? Las redes IP reparten paquetes con un tipo de servicio conocido como best effort (BE), lo cual equivale a lo más posible, lo antes posible. Los paquetes con este tipo de servicio tienen la misma expectativa de tratamiento a medida que transitan la red. Se caracteriza porque la complejidad se encuentra en los host de las puntas, siendo tontos los routers del núcleo de la red. Sólo miran el header, buscan en la tabla de ruteo y definen el next hop. Si llegase a ocurrir congestión, se retardan o descartan los paquetes. Esto hace muy escalable la red. Es suficiente para aplicaciones como mail, ftp y websurfing, pero no para otras aplicaciones que no toleran retardos variables o pérdida de datos, como es el caso de servicios de voz y video en tiempo real. Hay una convergencia de servicios no tradicionales: telefonía, radio, televisión, video conferencia, etc; los cuales tienen otras exigencias. Una solución se podría pensar es agregar más ancho de banda, pero esto no es suficiente, ya que el tráfico es típicamente en ráfagas, produciendo congestiones temporales y retardos y pérdidas. Por lo tanto la clave esta en dotar a Internet de una mayor inteligencia, por medio de mecanismos para obtener QoS. El objetivo de la calidad de servicio en una red es cuantificar el tratamiento que un paquete debe esperar a medida que circula por la red. El objetivo de una QoS diferenciada, es el dar a ciertos paquetes un mejor trato y a otros un peor trato. Hay que tener en cuenta que QoS no puede crear ancho de banda adicional, sino que debe manejar el tráfico de manera que el ancho de banda disponible soporte los requerimientos de un amplio rango de aplicaciones que la performance actual de BE no puede soportar. Fig.1: Diagrama de latencia en función del B.W para diversas aplicaciones. Los proveedores de servicios en general publican un Acuerdo del Nivel de Servicio (SLA) para sus servicios, que contiene los niveles de calidad mensurables que un cliente espera del tráfico de la clase en particular que se encuentra manejando. Monografía de Ev. de Performance:Diffserv 6

8 Hace una década atrás aproximadamente, la llegada del tráfico de paquetes de voz y video motivó traer ciertos intentos de distintos niveles de servicio al tráfico de paquetes. La premisa de estos hacer acercamientos es la misma de hoy en día: que ése tráfico es, debido a mediciones realizadas, más importante y debe ser tratado por ende acorde. Más recientemente, razones económicas han surgido para diferenciar el tráfico; Internet se ha puesto mucho más en uso y se ha convertido en una misión crítica para ciertas compañías. Cuando existan métodos viables para diferenciar el tráfico en redes IP, ISP (Internet Service Providers) podrán ofrecer servicios con objetivos de performance específicos y un arreglo de servicios con un costo que irá ligado a la calidad. Lo que es más, con una útil QoS IP disponible en la Internet general, más comunicaciones migrarán hacia la Internet. La clave para una red multiservicio es el poder diferenciar tráfico tanto en el tratamiento del envío ( Fowarding ) * como por las reglas aplicadas al tráfico. Las mayores aplicaciones iniciales que se esperan son: 1) el distinguir la importancia del tráfico dentro de una nube de red, 2) el permitir una buena calidad de voz sobre redes IP, y 3) permitir a los proveedores de servicios el vender servicios que compitan con líneas alquiladas. 2.2 Qué aplicaciones deben mejorar la QoS? La respuesta fundamentalmente recae en la arquitectura. Hay dos maneras importantes de mirar a la QoS. La más obvia es como un servicio que un usuario final (end-user) solicita, ya sea directa o indirectamente, cuantificado en la máquina del usuario final. En este caso es posible en general para el usuario el determinar si el objetivo de la QoS se cumple, por simple medición. Por ejemplo, un usuario inicia una llamada de voz sobre IP y espera que sea legible. Desde el punto de vista del humano, la calidad de la llamada es subjetiva, pero mediciones objetivas de la tasa de paquetes, el retardo, jitter, etc, son necesarias para una llamada legible y deben ser suministradas por la red. El permitir tener una conexión telefónica o una sesión de video entre dos puntos finales es el problema de QoS de la red de interés para mucha gente y han habido muchos intentos de asociar cierta QoS a determinada aplicación, en particular voz y video. Esto limita innecesariamente la utilidad y extensibilidad de QoS. La segunda manera de mirar a la QoS es desde el punto de vista del administrador de la red. En este caso hay objetivos administrativos para diferentes tipos de tráfico que pueden no ser aparentemente cuantificables para un usuario final, pero si para el administrador de la red. A pesar de la usual asociación con mejor servicio, QoS puede ser usada por administradores de red para limitar ciertos tipos de tráfico en una red. Las características intrínsecas del tráfico de ciertas aplicaciones y sus requerimientos varían enormemente. Actualmente, el patrón de tráfico dominante es el siguiente: cortas sesiones con un puñado de paquetes en cada dirección. Por ende, un flujo de Internet no * Fowarding: es el envío de paquetes IP por parte del router a través del puerto de salida de acuerdo con el Header del paquete y a la tabla de ruteo. Monografía de Ev. de Performance:Diffserv 7

9 puede en general ser caracterizado como una llamada donde los costos de establecimiento son aceptables debidos a la duración de la llamada. Por el contrario, los costos de establecimiento necesitan ser minimizados o eliminados. En la práctica, tenemos una mezcla de tráficos con características diferentes y aún así cada router en la red trata a todos los paquetes de la misma manera. Esta situación puede llevar a los Proveedores de Servicios de Internet (ISP) a identificar un requerimiento para tratar el tráfico de distintos suscriptores de acuerdo a una política específica. En la ausencia de otros acuerdos contractuales, todos los suscriptores deben esperar recibir un trozo justo de los recursos disponibles, pero esto no es garantido por el comportamiento estándar de TCP. Una solución de red básica de QoS podría ser el reforzar algún tipo de acceso equitativo bajo congestión. En resumen, pensar en QoS en una manera única o para una única aplicación es un mal enfoque. Aunque voz y video se pueden beneficiar y sacar ventaja de QoS, ambas aplicaciones funcionan en la Internet de best-effort y cuando en necesaria la QoS debería ser decisión del usuario basándose en el costo-beneficio. Esto se debe a que lo que puede ser no necesario para uno puede ser necesario para otros. Por ende, no se debe asumir sobre qué tipo de tráfico va a requerir mejor o peor trato, sino que se debe enfocar en construir un marco de trabajo donde sea posible entregar diferentes tratos a diferentes tipos de tráfico, donde el tipo de tráfico puede ser determinado de una manera flexible. 2.3 Quién decide cuáles paquetes reciben una QoS específica? Tal como se dijo anteriormente, no se debe atar aplicaciones particulares a particulares niveles de QoS. Esto nos lleva a la pregunta de ver quién se encarga de decidir cuáles paquetes reciben cierta QoS específica. Una posibilidad es permitir a los usuarios finales marcar sus propios paquetes para decidir qué recibe la mejor QoS. Esto es claramente impráctico ya que quizás los deseos del usuario pueden no reflejar los deseos de la organización que paga por la red, y el usuario final no tiene una manera de saber si el modelo de uso de la red actual puede o no manejar paquetes adicionales de ese nivel de QoS. Es más, un usuario final puede no saber qué tipo de QoS es apropiada para, por ejemplo, una llamada de voz vs. una transferencia de archivos. Como mínimo, un método de solicitud de servicio y de conceder o negar, debe estar en lugar. Algún agente debe estar en la red para implementar el servicio concedido. QoS debe ser alocada de manera de reflejar las políticas y prioridades de la organización que esta pagando por los recursos de la red que están siendo alocados. Cada nueva petición por QoS debe ser evaluada bajo la luz tanto de la política como de la asignación actual de manera de que los niveles de QoS sean cumplidos. La QoS debe reflejar la política local. La Internet y sus redes que la componen están hechas de entidades administrativas independientes o dominios, comúnmente llamados nubes. Las nubes pueden ser diferentes dominios o regiones dentro de un dominio que requieren diferente trato. Monografía de Ev. de Performance:Diffserv 8

10 ISP: Internet Service Provider AS: Sistema Autónomo Fig.2: Un esquema de la Arquitectura de Internet 2.4 Qué mecanismos primitivos requiere la red? Debido a lo que implica la QoS, la infraestructura de la red debe ser capaz de distinguir paquetes a través de medios de clasificación, encolamiento de paquetes en forma separada como resultado de la clasificación, despachador de paquetes en las colas para implementar el trato diferencial, así como proveer de medios de medida, monitoreo y acondicionamiento de las corrientes de paquetes para cumplir con los requerimientos de diferentes niveles de QoS. Hay varios flujos de paquetes que requieren diferentes tratos de QoS, pero el número de maneras en que los paquetes pueden ser tratados en el camino de envío es limitado. El agregar flujos individuales de acuerdo a su trato común en el envío, lleva a una reducción de estados y complejidad. El costo de esto es que las reglas de agregado deben ser explícitas y deben conducir a comportamientos sensibles tanto para los agregados como para los flujos individuales que los componen. Este problema es simplificado bastante si el tipo de QoS ofrecido a los flujos individuales se agrega con facilidad. 2.5 Cómo pueden los servicios de punta a punta ser construidos en una Internet de borde-a-borde (edge-to-edge)? Hemos visto que el acceso a QoS debe ser alocado en un nivel local, siguiendo las pautas administrativas de control. Como no todas las conexiones empiezan y terminan en el mismo dominio administrativo, cómo crear servicios QoS de punta a punta?. Una solución ha sido un acercamiento orientado a la conexión. Acá un camino en particular es establecido entre dos puntos finales de una conversación de datos y los recursos son reservados a lo largo de este camino. Si los recursos no se encuentran disponibles a lo largo del camino entero, la conexión es rechazada. Como la Internet no es un dominio administrativamente homogéneo, esto viola cada principio en que fue construido la red IP. La IP QoS debe calzar en la Internet y ser escalable. Si no son conexiones, entonces qué?. Un acercamiento amistoso toma en cuenta que las redes están compuestas de diversas nubes administrativas y tecnológicas. Mientras las decisiones de la colocación de los recursos son tomadas dentro de cada nube, lo que Monografía de Ev. de Performance:Diffserv 9

11 importa fuera de cada una de ellas es solamente el comportamiento a través de los bordes de los vecinos inmediatos. El tráfico de paquetes es clasificado en agregados de tráfico basándose en las reglas locales y las características de los agregados de tráfico son chequeadas en los bordes de la red. Donde nosotros cruzamos un borde, algunas reglas son necesarias sobre lo que aceptamos de afuera y lo que podemos mandar afuera. Los bordes pueden ser programados con estas reglas. Si cada nube tiene clasificada todas sus peticiones de QoS en un número pequeño de agregados con envío diferencial, el tráfico de paquetes que cruza los bordes o límites necesita solo ser clasificado, monitoreado y medido en este número pequeño de agregados, por lo que sólo una pequeña cantidad de estados es necesaria. Este enfoque mueve casi todo el trabajo a los bordes de las nubes y deja solo estados pertinentes al flujo de paquetes dos nubes cualesquiera (acuerdos bilaterales), siendo más escalable y ameno al control de la política local. El modelo de crear servicios a partir de acuerdos bilaterales de redes contiguas, refleja la estructura de la Internet de hoy día, donde la conectividad de punta a punta es creada a partir de acuerdos bilaterales entre los dueños de las nubes que los paquetes atraviesan para llegar al destino fuera de sus nubes originales. Si las nubes son parte de una red de organización única, los acuerdos de borde se esperan sean bastante simples de implementar. Si las nubes pertenecen a distintas organizaciones, se espera que el establecimiento de los modelos sea extendido para manejar la QoS. Monografía de Ev. de Performance:Diffserv 10

12 3. La arquitectura de los Servicios Diferenciados (DiffServ) En esta arquitectura, los paquetes son clasificados y marcados para recibir un trato particular en cuanto al envío en cada salto. Sofisticada clasificación, marcado, política y operaciones de acondicionamiento necesitan sólo ser implementadas en los bordes de la red o en los hosts. Esta arquitectura logra escalabilidad al implementar un complejas funciones de clasificación y condicionamiento sólo en los nodos del borde de la red, y aplicando conductas por salto a los agregados del tráfico que han sido apropiadamente marcados usando el campo DS en las cabeceras de IPv4 o IPv6. Es mantenida una distinción entre: el servicio provisto a un agregado de tráfico, las funciones de condicionamiento y los comportamientos por salto, usados para realizar los servicios, el valor del campo DS, usado para marcar paquetes para seleccionar el comportamiento en cada salto, y los mecanismos de implementación particulares del nodo que realizan un comportamiento por salto. Esta arquitectura sólo provee servicio diferenciado en una dirección del flujo de tráfico y es por ende asimétrica. Antes de proseguir y entrar en detalle con el funcionamiento de DiffServ y el análisis de sus componentes, vamos a introducir una breve terminología para así se puede entender con más claridad lo expuesto más adelante. 3.1 Terminología Behavior Aggregate (BA, también llamado a veces agregado de tráfico, TA) : es una colección de paquetes con el mismo DSCP (DiffServ Code Point) atravesando un enlace en una dirección. BA classifier: es un clasificador que selecciona paquetes basado solo en el contenido del campo de DS. Enlace de frontera: es un enlace que conecta los nodos de borde de dos dominios. DS behavior agregate: una colección de paquetes con el mismo código DS, cruzando un enlace en una dirección particular. código DS: un valor específico de la porción DSCP del campo DS, usado para seleccionar un PHB. DS-compliant: capaz de soportar funciones y comportamientos de servicios diferenciados. Monografía de Ev. de Performance:Diffserv 11

13 dominio DS: un dominio capaz de tener DS; un conjunto contiguo de nodos que operan con un conjunto común de políticas de provisionamiento de servicios y definiciones PHB. nodo de egreso DS: un nodo DS límite en su rol de manejar tráfico a medida que éste deja el dominio DS. nodo de ingreso DS: un nodo DS límite es su rol de manejar tráfico a medida que éste entra al domino DS. nodo interior DS: un nodo DS que no es un nodo DS límite. campo DS: es el octeto TOS de la cabecera de IPv4 o el octeto de la Clase de Tráfico de IPv6. Los bits del campo DSCP contienen el DS codepoint, mientras que los restantes bits no están en uso (se ampliará este tema más adelante). Dropping: es el proceso de descartar paquetes basándose en reglas específicas; políticas. Marking (marcado): es el proceso de seteo del DS codepoint en un paquete, basándose en reglas definidas; pre-marcado y re-marcado. Metering (mediciones): es el proceso de medir las propiedades temporales de una corriente de tráfico seleccionada por un clasificador (classifier). Microflow (microflujo): es un conjunto de datos, enviados unidireccionalmente entre dos aplicaciones, únicamente identificado por una quíntupla: protocolo de transporte, IP origen, IP destino, puerto origen y puerto destino. Per-Domain-Behavior (PDB): se define como el trato esperado que un agregado de tráfico va a recibir de borde a borde de un dominio DiffServ. Per-Hop-Behavior (PHB): define el tratamiento en cada nodo. Es una descripción del comportamiento de reenvío observado exteriormente; puede ser implementado por distintos mecanismos. Policing: el proceso de descarte de paquetes dentro de un arroyo de tráfico en concordancia con el estado de un correspondiente medidor (meter) cumpliendo un determinado perfil. Acuerdo del Nivel de Servicio (SLA): un contrato de servicio entre un cliente y un proveedor de servicio que especifica el servicio de envío que un cliente debe recibir. Shaping (conformador): el proceso de retardar paquetes dentro de un flujo de tráfico, haciendo que conforme cierto perfil de tráfico ya definido. Traffic Conditioner (acondicionador de tráfico): una entidad que realiza las funciones de condicionamiento del tráfico y que puede contener medidores, marcadores, droppers y conformadores. Están típicamente dispuestos en nodos de borde solamente. Monografía de Ev. de Performance:Diffserv 12

14 Traffic Conditioning Agreement (TCA): un acuerdo especificando reglas de clasificación y perfiles de tráfico correspondientes, y mediciones, marcado, descarte y/o reglas de conformación que son aplicables a los arroyos de tráfico seleccionados por el clasificador. 3.2 Requerimientos La historia de Internet ha sido de un completo crecimiento en cuanto al número de hosts, la gran variedad de aplicaciones y la capacidad de la infraestructura de la red. Por lo tanto, una arquitectura escalable para servicios diferenciados debe permitir acomodar este continuo crecimiento. Los siguientes requerimientos fueron identificados y ubicados en esta arquitectura: o debe acomodar una amplia variedad de servicios y proveer políticas, extendiendo una red punta a punta o una red particular o debe permitir el desacoplamiento del servicio de la aplicación particular en uso o debe trabajar con aplicaciones existentes sin la necesidad de cambios en interfaces de aplicaciones programables o debe desacoplar las funciones de condicionamiento de tráfico y provisionamiento de servicios de comportamientos de envío implementados en los nodos del núcleo de la red o no debe depender de la aplicación de señalización salto a salto o debe requerir solo una pequeña cantidad de comportamientos de envío, cuya complejidad de implementación no domine el costo de un dispositivo de red o debe utilizar solo estado de clasificación de agregados dentro del núcleo de la red o debe permitir interoperabilidad razonable con nodos de red no DS capaces o debe permitir implementaciones de clasificación de paquetes simples en nodos del núcleo de la red o debe evitar estados por microflujos o por clientes dentro de los nodos del núcleo o debe acomodar despliegue incremental 3.3 Modelo arquitectónico de los Servicios Diferenciados Las redes IP están compuestas de nubes, regiones de relativa homogeneidad en términos del control administrativo, tecnología, ancho de banda. Determinando dónde terminan las nubes y las fronteras, nosotros determinamos dónde administrar los recursos y dónde el control es aplicado, para asegurarse que la política se lleva a cabo. Dentro de una nube, es posible sacar ventaja de la uniformidad dentro de su frontera, al agregar flujos de tráfico individuales en un número limitado de agregados de tráfico, donde cada uno tendrá un distinto trato de envío. Por lo tanto, el tráfico entrante a la red es clasificado y posiblemente condicionado en los bordes de la red, y asignado a diferentes behavior aggregates (BA). Dentro de una nube, todo lo que es importante sobre un paquete para Monografía de Ev. de Performance:Diffserv 13

15 determinar el trato de envío es saber a qué agregado pertenece, siendo posible confiar en una marca puesta en el paquete para indicar su agregado. La forma en que una decisión de política específica sobre QoS es implementada, es por medio de la clasificación, monitoreo, marcado, política y otros condicionamientos del tráfico del paquete en las fronteras de las nubes, luego de los cuales los paquetes reciben un trato uniforme dentro de las nubes. Casi todo el trabajo es confinado al borde de las nubes. Las reglas para alojar recursos deben no ser visibles fuera de la nube, siéndolo, solamente los agregados de comportamiento. DiffServ utiliza el tráfico agregado como su unidad fundamental de tráfico, mas que como una corriente. Un campo de 6 bits en cada paquete identifica su agregado de tráfico (BA) en el centro de la red y por ende, el trato de envío que cada paquete en el agregado va a recibir, sin importar a que microflujo éste pertenezca. ). Cada BA es identificado por una único código DS. Dentro del núcleo de la red, los paquetes son enviados de acuerdo al comportamiento por salto asociado al código DS. En el borde de la red, más estado de paquetes debe ser guardado al marcar más campos de paquetes; por lo tanto, los agregados del interior podrían estar hechos de paquetes de varios clientes, y ser condicionados y politizados diferente en el borde, pero con la misma expectativa de trato de envío una vez pasado el borde. Los routers dentro del dominio van a ser configurados para tratar a cada agregado de tráfico en forma diferente: en un dominio que reconoce a N agregados, los routers serán cada uno capaz de tener N comportamientos de envío diferente, uno apropiado para cada agregado. 3.4 Separación del control y envío En el envío IP, la conectividad es lograda por la interacción de dos componentes: la parte del envío del paquete y la parte del ruteo. El envío usa la cabecera del paquete para encontrar una tabla de ruteo que determine la interfase de salida del paquete. El ruteo setea las entradas en esa tabla y puede necesitar reflejar un rango de tránsito y otras políticas así como también el mantener registro de las fallas de ruta. Un servicio es una descripción de todo el trato que el tráfico de un cliente recibe a través de un dominio administrativo particular, a través de un conjunto de dominios interconectados o de punta a punta. Las descripciones del servicio dentro de un dominio, son cubiertas por una política administrativa que es aplicada a la construcción y concatenación de los agregados de tráfico. Los TA son descriptos por un conjunto particular de reglas, en concordancia con un trato específico de envío configurado de una manera particular. 3.5 Definiendo las primitivas del camino de envío Requerimientos básicos. La clasificación saca corriente de paquetes. La política se encarga de asegurar que el comportamiento cumpla con las reglas que gobiernan la corriente de paquetes. El marcado propaga información sobre el agregado corriente abajo. PHB s de envío son generalmente implementados por colas de paquetes. Y el encolamiento aísla una Monografía de Ev. de Performance:Diffserv 14

16 corriente de tráfico de otra. (Estos conceptos serán analizados con más detalle más adelante en este texto) Marcado de DiffServ. Cada paquete IP lleva un byte llamado octeto de Tipo de Servicio (TOS octet). Es una característica poco utilizada de IP. En la nueva versión 6 de IP de 128 bits, hay un byte equivalente llamado octeto de Clase de Servicio. (a) (b) Fig. 3: (a) Campo DS - campo TOS de IPv4 ; (b) Campo DS Campo de Clase de Tráfico de IPv6. La primer tarea del grupo de DiffServ fue re-especificar este byte. Este campo de 6 bits es conocido como el campo de los Servicios Diferenciados y es marcado con un patrón específico de bits llamado código DS, usado para indicar cómo cada router debe tratar al paquete. Para enfatizar el hecho de que ninguna información de sesión se necesita guardar, este tratamiento es conocido como Per-Hop Behavior (PHB). El octeto luce así: Monografía de Ev. de Performance:Diffserv 15

17 Fig. 4: Aspecto del octeto TOS. El campo de 6 bits contiene hasta 64 diferentes valores binarios. Los códigos extra restantes dejan espacio para innovación y optimizaciones operacionales locales. El marcado puede ocurrir en dos lugares: la fuente original de tráfico, como ser un servidor web, marca el tráfico. Esto tiene la ventaja de que el clasificador pude tener conocimiento explícito de la aplicación en uso y puede por consecuencia marcar paquetes de una manera dependiente de la aplicación. un router, como el primer router que el tráfico encuentra, clasifica y marca el tráfico. Esto tiene la ventaja de que no se necesita ningún cambio a servidores, pero requiere de alguna inteligencia extra en los routers Usando la marca. Cuando un paquete entra en un router, la lógica de ruteo selecciona su puerto de salida y el valor DSCP es usado para conducir el paquete a una cola específica o tratamiento específico en ése puerto. El PHB particular es configurado por un mecanismo administrador de red, seteando la tabla de comportamiento de QoS dentro del router. Los PHB s estándares son hasta ahora los siguientes: Default behavior. Acá el valor de DSCP es cero y el servicio esperado es exactamente el servicio por defecto de la Internet de hoy (por ej. la congestión y pérdida son completamente descontroladas). Class selector behavior. Acá, siete valores DSCP funcionan desde el al y son específicos para seleccionar hasta siete comportamientos, cada uno de los cuales tiene una mayor probabilidad de un envío a tiempo que su predecesor. Expedited Forwarding behavior(ef). El valor recomendado es La tasa de partida del tráfico EF debe igualar o superar una tasa configurable. EF intenta permitir la creación de servicios en tiempo real con una tasa de throughput configurable. El objetivo es que el flujo agregado vea siempre o casi siempre, la cola vacía. Assured Forwarding (AF) behavior. * Consiste en tres sub-comportamientos, AF 1, AF 2, AF 3. Cuando la red está congestionada, los paquetes marcados con el DSCP para AF 1 tienen la menor probabilidad de ser descartados por cualquier * Éste es el PHB elegido para las simulaciones realizadas en éste trabajo. Monografía de Ev. de Performance:Diffserv 16

18 router y los paquetes marcados para AF 2 la más alta. En general, hay N clases independientes con M niveles de descarte dentro de cada clase. Lo más común es N= 4 y M= 3. A cada clase se le deben asignar una mínima cantidad de recursos, pudiendo obtener más si es que hay exceso El dominio de los Servicios Diferenciados Un dominio DS es un conjunto de nodos DS que operan con una política de provisionamiento de servicios común y con un conjunto de grupos PHB implementados en cada nodo. Esta formado por nodos DS de frontera que clasifican y posiblemente condicionen el tráfico entrante para asegurarse que los paquetes que transitan el dominio estén apropiadamente marcados para seleccionar un PHB de los grupos PHB que son soportados dentro del dominio. Los nodos seleccionan el comportamiento de envío basándose en su código DS, y lo hacen asociando éste valor a unos de los PHB soportados. La inclusión de nodos que nos soportan DS dentro de un dominio DS puede resultar en una performance impredecible y puede impedir la habilidad de satisfacer el acuerdo del nivel de servicio (SLA). Un dominio DS consiste en general de una o más redes bajo la misma administración. Fig. 5: Modelo de red donde se aprecian nodos interiores y de frontera Nodos DS de frontera e interiores: Los nodos DS de frontera interconectan el dominio DS con otros dominios que pueden o no soportar DS. Los nodos interiores solo conectan con otros nodos interiores o de frontera dentro del mismo dominio DS. Ambos tipos de nodos deben ser capaces de aplicar el PHB apropiado a los paquetes basándose en el código DS, sino, puede resultar en un comportamiento impredecible. Los nodos DS de frontera puede que sean requeridos para performar funciones de Monografía de Ev. de Performance:Diffserv 17

19 condicionamiento de tráfico tal como se define en un acuerdo de condicionamiento de tráfico (TCA) entre su dominio DS y el dominio contiguo al cual conectan (Ver Fig.7). Los nodos DS interiores deben poder performar re-marcado de códigos por ejemplo (Ver Fig.8). Si un host no actúa como nodo de frontera, entonces el nodo DS topológicamente más cercano a este host, actúa como el nodo DS de frontera para el tráfico de ese host Nodos de Ingreso y Egreso: Los nodos de frontera actúan tanto como nodos DS de ingreso y egreso para el tráfico de distintas direcciones Región de Servicios Diferenciados Es un conjunto de uno o más dominios DS contiguos. Los dominios DS en una región DS pueden soportar distintos grupos PHB internamente y diferentes códigos. Sin embargo, para permitir servicios que se expanden a través de los dominios, los dominios DS contiguos deben cada uno establecer un SLA entre ellos que define cierta TCA, para especificar cómo el transito del tráfico de un dominio DS a otro es condicionado en la frontera entre los dos dominios DS. Fig.6: Modelo de red donde apreciar interacción entre dominios DS a través de los SLA s. 3.6 Clasificación y condicionamiento de tráfico El SLA puede especificar la clasificación del tráfico y las reglas de re-marcado, así como perfiles de tráfico y acciones a las corrientes de tráfico que son dentro o fuera del perfil (in-out profile). El TCA entre dominios deriva del SLA. La política de clasificación de paquetes identifica el subconjunto de tráfico que puede llegar a recibir un servicio diferenciado, al ser condicionado y/o mapeado a uno o más BA. El condicionamiento de tráfico performa la medición, conformación, política y/o remarcado para asegurarse que el tráfico entrante al dominio DS respeta las reglas especificadas en el TCA. Monografía de Ev. de Performance:Diffserv 18

20 3.6.1 Clasificadores Definimos dos tipos de clasificadores. El clasificador BA clasifica paquetes basado en el código DS solamente. El clasificador MF (Multi-Field) selecciona paquetes basado en el valor de una combinación de uno o más campos de cabecera, como dir. de origen, dir. destino, campo DS, protocolo ID, puertos origen y destino, entre otra información. El clasificador debe autentificar la información que usa para clasificar el paquete. Fig.7: Arquitectura de un nodo exterior Perfiles de tráfico Especifica las propiedades temporales de una corriente de tráfico seleccionada por el clasificador. Provee de reglas para determinar si un paquete está dentro o fuera del perfil. Por ejemplo, un perfil basado en una cubeta con fichas puede parecer así: codepoint=x, use token-bucket r, b El perfil anterior indica que todos los paquetes marcados con un código DS X deben ser medidos con medidor de balde con fichas con tasa r y de tamaño b. En este caso los paquetes fuera del perfil son los que arriban cuando hay insuficientes fichas disponibles en el balde. Diferentes acciones de condicionamiento pueden ser aplicadas a los paquetes dentro y fuera del perfil. Los paquetes dentro del perfil pueden ser mandados sin ningún otro procesamiento o marcado o remarcado. Los paquetes fuera de perfil pueden ser encolados hasta que estén dentro del perfil (conformados), desechados (política) o remarcados con un código nuevo (re-marcado). Hay que hacer notar que el perfil de tráfico es un componente opcional de un TCA Acondicionadores de tráfico Puede contener los siguientes elementos: medidor, marcador, conformador y despachador. Una corriente de tráfico es seleccionada por un clasificador. Un medidor es usado para medir la corriente de tráfico en base a un perfil de tráfico. El estado del medidor respecto a un paquete en particular puede ser usado para afectar el marcado, despacho, o acción de conformación. Monografía de Ev. de Performance:Diffserv 19

21 Cuando los paquetes salen del acondicionador de tráfico de un nodo DS frontera, el código DS de cada paquete debe setearse a un valor apropiado. Componentes del acondicionador: Medidor: miden las propiedades temporales de la corriente de paquetes seleccionada por el clasificador en base a un perfil de tráfico especificado en el TCA. Pasa información de estado a otras funciones de condicionamiento para tomar cierta acción para cada paquete tanto dentro como fuera de perfil. Marcador: setean el campo DS con un código particular, agregando el paquete marcado a un behavior agregate DS particular. Puede que marque todos los paquetes que son dirigidos a él con un código particular o puede estar configurado para marcar un paquete a un código de un grupo de códigos usados para seleccionar un PHB en un grupo PHB. Cuando el marcador cambia el código en un paquete, se dice haber remarcado el paquete. Conformador: Retardan uno o todos los paquetes de una corriente de tráfico de manera de que la corriente cumpla con el perfil de tráfico estipulado. Usualmente tiene un buffer de tamaño finito y los paquetes pueden ser descartados si no hay suficiente espacio de buffer para aguantar a los paquetes retrasados. Despachador: Descartan algunos o todos los paquetes en una corriente de tráfico de manera de que la corriente cumpla con el perfil de tráfico estipulado. Este proceso es conocido como política. Un despachador puede ser implementado como un caso especial de un conformador, si ponemos el tamaño del buffer del conformador igual a 0 (o muy pocos) paquetes. Fig.8: Arquitectura de nodos interiores Ubicación de los acondicionadores de tráfico o clasificadores MF Los acondicionadores de tráfico están usualmente localizados dentro de los nodos de frontera de ingreso y egreso. Dentro del dominio origen: se lo define como el dominio que contiene el nodo que origina el tráfico que recibe un servicio particular. El tráfico originado del dominio fuente a través de una frontera puede ser marcado por las fuentes de tráfico directamente o por medio de nodos intermediarios antes de que dejen el domino origen. Esto se conoce como pre-marcado. Monografía de Ev. de Performance:Diffserv 20

22 Por ejemplo, supongamos una compañía que tiene la política de que los paquetes CEO deben tener prioridad alta. El usuario CEO puede marcar el campo DS de todos los paquetes de salida con un código DS que indique ese grado de prioridad alto o, alternativamente, el router del primer salto, que está directamente conectado al host de CEO, puede clasificar el tráfico y marcar los paquetes CEO con el código DS correcto. Hay ciertas ventajas en el hecho de marcar paquetes cerca de la fuente / origen de tráfico. Primero, una fuente de tráfico puede más fácilmente tomar en cuenta las preferencias de las aplicaciones en el momento de decidir qué paquetes deben recibir mejor tratamiento de envío. Además, la clasificación de paquetes es más simple antes que el tráfico ha sido agregado con paquetes de otras fuentes, ya que el número de reglas de clasificación que deben ser aplicadas dentro de un nodo único es reducido. El nodo frontera del dominio fuente debe también monitorear la conformancia con el TCA, así como aplicar política, conformado, o pre-marcado de paquetes según se necesite. En los nodos frontera de un dominio DS: El SLA entre dominios debe especificar cuál tiene la responsabilidad de mapear las corrientes de tráfico a agregados de comportamiento DS y condicionar esos agregados en conformancia con el apropiado TCA. Sin embargo, un nodo de ingreso debe asumir que el tráfico entrante puede no conformar con el TCA y debe estar preparado para reforzar el TCA de acuerdo a la política local. Cuando los paquetes son pre-marcados y condicionados en un dominio de corriente superior, una clasificación y condicionamiento potencialmente menores necesitan ser soportados en el dominio DS de corriente inferior. Si un nodo de ingreso esta conectado a un dominio superior no capaz de DS, el nodo de ingreso DS debe poder cumplir con todas las funciones de condicionamiento de tráfico necesarias en el tráfico entrante. 3.7 Opciones del plano de control Control de QoS en una base de nubes: Una premisa de DiffServ es que es posible controlar los recursos en una nube base que por cada nodo o camino único. Puede haber solo un router en una nube que use la marca de DS y en ése caso los paquetes de la nube son marcados por cómo son tratados en el cuello de botella de la nube. Decisiones de control que pueden ser más fácilmente expresadas en una base por nube, pueden ser desarrolladas más tempranamente y ahorrar un montón de trabajo innecesario, comparado con un el intento de un diseño de un sistema completo basado en caminos reservados orientados a la conexión. Acercamientos orientados a la conexión pueden existir dentro de una nube: ATM, MPLS, RSPV/Intserv, pero un acercamiento totalmente orientado a la conexión para QoS no es razonable para futuros servicios punta a punta. Monografía de Ev. de Performance:Diffserv 21

23 3.7.2 Conectando nubes de red: Cada nube solo necesita establecer relaciones de confianza limitada con nubes adyacentes. Esto hace posible el guardar estado en una base de dominio administrativo, más que en cada router, y hace posible el confinar estado por flujo a sólo los routers frontera. Cada organización debe tener completa responsabilidad por el alojamiento de los recursos de tráfico dentro de su dominio. Así, la arquitectura de alojamiento está hecha de acuerdos a través de las fronteras como la cantidad de cada agregado de tráfico que le será permitido pasar Ejemplo de QoS basado en nubes: Cuando una aplicación en una red quiere un mejor nivel de QoS y la aplicación has sido ya determinada como una aplicación merecedora hay ciertas consideraciones a tener en cuenta. Primero, si la fuente y destino están ambas en la misma red, la decisión de conceder o negar la petición depende solo de recursos dentro de ésa red. El tomar esta decisión depende solo de Me (ve dibujo). El pedir por QoS puede ser explícito o implícito. Si la aplicación tiene un punto final que no es local, la decisión de conceder o negar la petición debe considerar los recursos que son compartidos entre Me y la siguiente nube de red en el camino al otro punto final. Si el otro punto final está NOT-ME-1, entonces es un simple tema de quedarse dentro de sus límites compartidos. Si el otro punto final está en Far Away, entonces la petición debe caer dentro de los límites compartidos por ME y Not-me-2, mientras Not-me-2 debe decidir si hay suficientes recursos para Far Hawai. Fig.9: Ejemplo de una Internet de nubes. Diferentes conjuntos de reglas pueden aplicarse a diferentes nubes interiores. 3.8 PDB s: estructurando los agregados para cumplir con las expectativas La IETF adoptó la frase per domain behavior (PDB) para capturar la noción de una descripción precisa, incluyendo parámetros cuantitativos, del servicio provisto a un cierto agregado de tráfico entre los bordes de un dominio de red de servicios diferenciados dado. Monografía de Ev. de Performance:Diffserv 22