Diffserv: Servicios Diferenciados

Monografa de Evaluacin de Performance en Redes de Telecomunicaciones

Adrin Delfino Sebastin Rivero

1. INTRODUCCIN
La palabra Calidad de Servicio (QoS), ha sido frecuentemente usada con una variedad de significados diferentes. Nosotros la usaremos para describir un grupo de parmetros mensurables, como ser retardo, throughput y tasa de prdidas que pueden estar adjuntados a algn subgrupo identificable de paquetes de IP, a travs de un cierto dominio.

1.1 Trasfondo: hacia una calidad de servicio amigable en Internet

El sistema telefnico es bastante diferente de la Internet. El sistema telefnico, al menos en su forma elctrica pura original, tena un simple problema de congestin y un requerimiento igualmente simple de calidad de servicio. El problema de congestin era que deba haber un camino elctrico reservado disponible entre dos terminales; lo cual es un estado binario. El problema de la calidad era que ste camino deba tener un ancho de banda y ganancia adecuados y ruido suficientemente bajo para poder transmitir una seal de voz legible. Hoy en da sigue siendo cierto que un camino reservado y cierto grado de calidad, son las dos caractersticas definitorias de una llamada telefnica estndar. 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 extraas circunstancias, a pesar que en la mayora de los casos son constantes durante la sesin. Al mismo tiempo, los paquetes son de tamao variable, tpicamente entre 20 y 4000 bytes. La llegada de paquetes a los enlaces de una red es tanto aleatoria como en rfagas. Lo anterior implica que an cuando la tasa promedio de trfico sea chica, largas rfagas arbitrarias de trfico a velocidad mxima de hardware son de esperarse. Perodos de congestin son por lo tanto comunes en la Internet, resultando en prdida de paquetes como en jitter. Medidas realizadas muestran que el patrn dominante de trfico es caracterizado por cortas sesiones con muchos paquetes por cada una. En resumen, la Internet no tiene un requerimiento de calidad de servicio estndar ni un modelo analtico trazable de trfico. Las tendencias en Internet hoy en da son caracterizadas por un fuerte crecimiento, por procurar ofrecer servicios diversos sobre la red y por buscar simplificar la operacin y la gestin. La Internet de hoy se compone de una compleja interconexin de dominios de redes, algunos bajo las mismas entidades administrativas y otros bajo distintas entidades administrativas. Actualmente, la mayora de estos dominios tienen mas capacidad disponible en sus interiores y ms 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.

Monografa de Ev. de Performance:Diffserv

1.2 Acercamientos previos

Precedencia IP y TOS: En el diseo original de IP, un byte conocido como octeto de
tipo de servicio fue reservado en la cabecera de cada paquete. Contena 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 reciba el peor tratado y 7 el mejor. El tipo de servicio se identificaba como bajo retardo, alto throughput y alta confiabilidad. Lamentablemente no haba una arquitectura de marco de trabajo en donde emplear este octeto de tipo de servicio y por ende ninguna explicacin de cmo estas propiedades podan ser implementadas. En la prctica 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 nmero pequeo de tipos de trfico. ST: El Protocolo de Flujo de Internet, fue un intento de acomodar flujos de trfico en tiempo real en paralelo con trfico TCP/IP, agregando un segundo protocolo orientado a la conexin, 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 travs de Internet, que necesitan una especfica calidad de servicio. Requiere de un mdulo en cada router IP a lo largo de la trayectoria, que reserva recursos para cada sesin y entonces se asegura que cada paquete de datos en trnsito 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 sesin no se inicia. Una de las desventajas es que necesita de nuevo software tanto en el envo 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 mayora de las principales conexiones ISP, llevando millones de paquetes por segundo, el overhead por paquete en la implementacin de los chequeos necesarios y administracin de los recursos se cree ser ampliamente inaceptable. Aparte, en IntServ, el Sistema Autnomo o los lmites del proveedor son esencialmente invisibles. En general, el fracaso de IntServ se debe principalmente a que en tomo un camino en donde deja atrs las races del xito de IP y adopt la nocin de que QoS significa conexiones. El modelo orientado a la conexin 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 homogneo administrativamente.

Monografa de Ev. de Performance:Diffserv

1.3 Un acercamiento ms nuevo

Ms recientemente, la IETF ha tenido otro acercamiento: los Servicios Diferenciales (DiffServ). DiffServ se basa en un marco de trabajo arquitectnico 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 travs 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 construccin de QoS antes que los servicios, reconociendo la necesidad de mecanismos altamente escalables con un mnimo impacto en los elementos de los caminos donde van los datos de los routers del ncleo, los cuales manejan enlaces de multi-gigabits. Finalmente, a diferencia de ST o IntServ, evita la creacin de informacin de estado a lo largo del camino de cada flujo de trfico individual.

En dominios no capaces DS: las fuentes de trfico y nodos intermedios en un dominio no DS pueden emplear acondicionadores de trfico para pre-marcar el trfico antes de que llegue al ingreso de un dominio DS inferior. De esta manera las polticas locales para clasificacin y marcado pueden ser canceladas. En nodos DS interiores: aunque la arquitectura bsica asume que las funciones de clasificacin y condicionamiento estn 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 descripcin observada externamente del comportamiento de envo de un nodo DS aplicada a un behavior agregate DS en particular. Comportamiento de envo es un concepto general en este concepto. tiles distinciones de comportamiento son principalmente observadas cuando mltiples 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 ms simple de un PHB es uno que garantiza una mnima localizacin 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 trfico. Un PHB ligeramente ms complicado sera garantizar un alojamiento de ancho de banda mnima de un porcentaje X del enlace, con un reparto proporcional justo de cualquier exceso de capacidad del enlace. Los PHB pueden ser especificados en trminos de su prioridad de recursos relativa a otros PHBs, o en termino de sus caractersticas relativas de trfico observable. Monografa de Ev. de Performance:Diffserv 3

Estos PHBs pueden ser usados como bloques de construccin 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 trminos de la caractersticas de comportamiento relevantes a las polticas de provisionamiento de servicios, y no en trminos de mecanismos de implementacin particulares. Es probable que ms 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 cdigo DS en un paquete recibido. PHBs estndares tienen un cdigo recomendado. Sin embargo, el espacio total de cdigo es mas largo que el espacio disponible para los cdigos recomendados para los PHBs estndar, y el campo DS deja provisiones para mapeos configurables localmente. Todos los cdigos deben ser mapeados a algn PHB, y en ausencia de alguna poltica local, los cdigos que no estn mapeados a un PHB estndar, deben ser mapeados a un PHB por defecto. Alojamiento de recursos de la red La implementacin, configuracin , operacin y administracin 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 polticas de provisionamiento de servicios de los dominios. La configuracin e interaccin entre acondicionadores de trfico y nodos interiores, debe ser manejada por el control administrativo del dominio y puede requerir control operacional a travs 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 PHBs estndares. Se define un nodo de legado como un caso especial de un nodo no capaz de soportar DS, que implementa clasificacin de precedencia y envo IPv4 tal como esta definido en los RFC791 y RFC1812, pero que es de cualquier forma no capaz de soportar DS. Una distincin 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 envo impredecibles para paquetes con cdigos DS con valores distintos de cero.

Monografa de Ev. de Performance:Diffserv

Consideraciones multicast Los paquetes multicast que entran en un dominio DS por un nodo de ingreso pueden tomar simultneamente mltiples caminos a travs de algunos segmentos del dominio debido a la replicacin multicast de paquetes. En esta manera ellos consumen ms recursos de red que los paquetes unicast. Puede ser dificultoso el proveer garantas cuantitativas de servicio a transmisores multicast. Es ms, puede ser necesario reservar cdigos y PHBs para uso exclusivo de trfico unicast, para proveer de una aislamiento de recursos del trfico multicast.

Monografa de Ev. de Performance:Diffserv

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 ms 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 ncleo de la red. Slo miran el header, buscan en la tabla de ruteo y definen el next hop. Si llegase a ocurrir congestin, 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 prdida de datos, como es el caso de servicios de voz y video en tiempo real. Hay una convergencia de servicios no tradicionales: telefona, radio, televisin, video conferencia, etc; los cuales tienen otras exigencias. Una solucin se podra pensar es agregar ms ancho de banda, pero esto no es suficiente, ya que el trfico es tpicamente en rfagas, produciendo congestiones temporales y retardos y prdidas. 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 trfico 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 funcin 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 trfico de la clase en particular que se encuentra manejando.

Monografa de Ev. de Performance:Diffserv

Hace una dcada atrs aproximadamente, la llegada del trfico de paquetes de voz y video motiv traer ciertos intentos de distintos niveles de servicio al trfico de paquetes. La premisa de estos hacer acercamientos es la misma de hoy en da: que se trfico es, debido a mediciones realizadas, ms importante y debe ser tratado por ende acorde. Ms recientemente, razones econmicas han surgido para diferenciar el trfico; Internet se ha puesto mucho ms en uso y se ha convertido en una misin crtica para ciertas compaas. Cuando existan mtodos viables para diferenciar el trfico en redes IP, ISP (Internet Service Providers) podrn ofrecer servicios con objetivos de performance especficos y un arreglo de servicios con un costo que ir ligado a la calidad. Lo que es ms, con una til QoS IP disponible en la Internet general, ms comunicaciones migrarn hacia la Internet. La clave para una red multiservicio es el poder diferenciar trfico tanto en el tratamiento del envo (Fowarding) *como por las reglas aplicadas al trfico. Las mayores aplicaciones iniciales que se esperan son: 1) el distinguir la importancia del trfico 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 lneas 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 ms obvia es como un servicio que un usuario final (end-user) solicita, ya sea directa o indirectamente, cuantificado en la mquina 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 medicin. 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 conexin telefnica o una sesin de video entre dos puntos finales es el problema de QoS de la red de inters para mucha gente y han habido muchos intentos de asociar cierta QoS a determinada aplicacin, 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 trfico que pueden no ser aparentemente cuantificables para un usuario final, pero si para el administrador de la red. A pesar de la usual asociacin con mejor servicio, QoS puede ser usada por administradores de red para limitar ciertos tipos de trfico en una red. Las caractersticas intrnsecas del trfico de ciertas aplicaciones y sus requerimientos varan enormemente. Actualmente, el patrn de trfico dominante es el siguiente: cortas sesiones con un puado de paquetes en cada direccin. Por ende, un flujo de Internet no
Fowarding: es el envo de paquetes IP por parte del router a travs del puerto de salida de acuerdo con el Header del paquete y a la tabla de ruteo.
*

Monografa de Ev. de Performance:Diffserv

puede en general ser caracterizado como una llamada donde los costos de establecimiento son aceptables debidos a la duracin de la llamada. Por el contrario, los costos de establecimiento necesitan ser minimizados o eliminados. En la prctica, tenemos una mezcla de trficos con caractersticas diferentes y an as cada router en la red trata a todos los paquetes de la misma manera. Esta situacin puede llevar a los Proveedores de Servicios de Internet (ISP) a identificar un requerimiento para tratar el trfico de distintos suscriptores de acuerdo a una poltica especfica. 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 estndar de TCP. Una solucin de red bsica de QoS podra ser el reforzar algn tipo de acceso equitativo bajo congestin. En resumen, pensar en QoS en una manera nica o para una nica aplicacin 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 debera ser decisin del usuario basndose 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 trfico 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 trfico, donde el tipo de trfico puede ser determinado de una manera flexible.

2.3 Quin decide cules paquetes reciben una QoS especfica?

Tal como se dijo anteriormente, no se debe atar aplicaciones particulares a particulares niveles de QoS. Esto nos lleva a la pregunta de ver quin se encarga de decidir cules paquetes reciben cierta QoS especfica. Una posibilidad es permitir a los usuarios finales marcar sus propios paquetes para decidir qu recibe la mejor QoS. Esto es claramente imprctico ya que quizs los deseos del usuario pueden no reflejar los deseos de la organizacin 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 ms, 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 mnimo, un mtodo de solicitud de servicio y de conceder o negar, debe estar en lugar. Algn agente debe estar en la red para implementar el servicio concedido. QoS debe ser alocada de manera de reflejar las polticas y prioridades de la organizacin que esta pagando por los recursos de la red que estn siendo alocados. Cada nueva peticin por QoS debe ser evaluada bajo la luz tanto de la poltica como de la asignacin actual de manera de que los niveles de QoS sean cumplidos. La QoS debe reflejar la poltica local. La Internet y sus redes que la componen estn hechas de entidades administrativas independientes o dominios, comnmente llamados nubes. Las nubes pueden ser diferentes dominios o regiones dentro de un dominio que requieren diferente trato.

Monografa de Ev. de Performance:Diffserv

ISP: Internet Service Provider AS: Sistema Autnomo

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 travs de medios de clasificacin, encolamiento de paquetes en forma separada como resultado de la clasificacin, 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 nmero de maneras en que los paquetes pueden ser tratados en el camino de envo es limitado. El agregar flujos individuales de acuerdo a su trato comn en el envo, lleva a una reduccin de estados y complejidad. El costo de esto es que las reglas de agregado deben ser explcitas 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 Cmo 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, cmo crear servicios QoS de punta a punta?. Una solucin ha sido un acercamiento orientado a la conexin. Ac un camino en particular es establecido entre dos puntos finales de una conversacin 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 conexin es rechazada. Como la Internet no es un dominio administrativamente homogneo, 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 estn compuestas de diversas nubes administrativas y tecnolgicas. Mientras las decisiones de la colocacin de los recursos son tomadas dentro de cada nube, lo que

Monografa de Ev. de Performance:Diffserv

importa fuera de cada una de ellas es solamente el comportamiento a travs de los bordes de los vecinos inmediatos. El trfico de paquetes es clasificado en agregados de trfico basndose en las reglas locales y las caractersticas de los agregados de trfico 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 nmero pequeo de agregados con envo diferencial, el trfico de paquetes que cruza los bordes o lmites necesita solo ser clasificado, monitoreado y medido en este nmero pequeo de agregados, por lo que slo una pequea 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 ms escalable y ameno al control de la poltica local. El modelo de crear servicios a partir de acuerdos bilaterales de redes contiguas, refleja la estructura de la Internet de hoy da, donde la conectividad de punta a punta es creada a partir de acuerdos bilaterales entre los dueos 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 organizacin 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.

Monografa de Ev. de Performance:Diffserv

10

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 envo en cada salto. Sofisticada clasificacin, marcado, poltica y operaciones de acondicionamiento necesitan slo ser implementadas en los bordes de la red o en los hosts. Esta arquitectura logra escalabilidad al implementar un complejas funciones de clasificacin y condicionamiento slo en los nodos del borde de la red, y aplicando conductas por salto a los agregados del trfico que han sido apropiadamente marcados usando el campo DS en las cabeceras de IPv4 o IPv6. Es mantenida una distincin entre: el servicio provisto a un agregado de trfico, 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 implementacin particulares del nodo que realizan un comportamiento por salto. Esta arquitectura slo provee servicio diferenciado en una direccin del flujo de trfico y es por ende asimtrica. Antes de proseguir y entrar en detalle con el funcionamiento de DiffServ y el anlisis de sus componentes, vamos a introducir una breve terminologa para as se puede entender con ms claridad lo expuesto ms adelante.

3.1 Terminologa
Behavior Aggregate (BA, tambin llamado a veces agregado de trfico, TA) : es una
coleccin de paquetes con el mismo DSCP (DiffServ Code Point) atravesando un enlace en una direccin.

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 coleccin de paquetes con el mismo cdigo DS, cruzando
un enlace en una direccin particular.

cdigo DS: un valor especfico de la porcin DSCP del campo DS, usado para
seleccionar un PHB.

DS-compliant: capaz de soportar funciones y comportamientos de servicios

diferenciados.

Monografa de Ev. de Performance:Diffserv

11

dominio DS: un dominio capaz de tener DS; un conjunto contiguo de nodos que operan
con un conjunto comn de polticas de provisionamiento de servicios y definiciones PHB. nodo de egreso DS: un nodo DS lmite en su rol de manejar trfico a medida que ste deja el dominio DS.

nodo de ingreso DS: un nodo DS lmite es su rol de manejar trfico a medida que ste
entra al domino DS.

nodo interior DS: un nodo DS que no es un nodo DS lmite. campo DS: es el octeto TOS de la cabecera de IPv4 o el octeto de la Clase de Trfico
de IPv6. Los bits del campo DSCP contienen el DS codepoint, mientras que los restantes bits no estn en uso (se ampliar este tema ms adelante).

Dropping: es el proceso de descartar paquetes basndose en reglas especficas;

polticas.

Marking (marcado): es el proceso de seteo del DS codepoint en un paquete, basndose

en reglas definidas; pre-marcado y re-marcado.

Metering (mediciones): es el proceso de medir las propiedades temporales de una

corriente de trfico seleccionada por un clasificador (classifier).

Microflow (microflujo): es un conjunto de datos, enviados unidireccionalmente entre dos aplicaciones, nicamente identificado por una quntupla: 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
trfico va a recibir de borde a borde de un dominio DiffServ.

Per-Hop-Behavior (PHB): define el tratamiento en cada nodo. Es una descripcin del

comportamiento de reenvo observado exteriormente; puede ser implementado por distintos mecanismos.

Policing: el proceso de descarte de paquetes dentro de un arroyo de trfico 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 envo que un cliente debe recibir.

Shaping (conformador): el proceso de retardar paquetes dentro de un flujo de trfico,

haciendo que conforme cierto perfil de trfico ya definido.

Traffic Conditioner (acondicionador de trfico): una entidad que realiza las

funciones de condicionamiento del trfico y que puede contener medidores, marcadores, droppers y conformadores. Estn tpicamente dispuestos en nodos de borde solamente.

Monografa de Ev. de Performance:Diffserv

12

Traffic Conditioning Agreement (TCA): un acuerdo especificando reglas de clasificacin y perfiles de trfico correspondientes, y mediciones, marcado, descarte y/o reglas de conformacin que son aplicables a los arroyos de trfico seleccionados por el clasificador.

3.2 Requerimientos
La historia de Internet ha sido de un completo crecimiento en cuanto al nmero 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 polticas, extendiendo una red punta a punta o una red particular o debe permitir el desacoplamiento del servicio de la aplicacin 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 trfico y provisionamiento de servicios de comportamientos de envo implementados en los nodos del ncleo de la red o no debe depender de la aplicacin de sealizacin salto a salto o debe requerir solo una pequea cantidad de comportamientos de envo, cuya complejidad de implementacin no domine el costo de un dispositivo de red o debe utilizar solo estado de clasificacin de agregados dentro del ncleo de la red o debe permitir interoperabilidad razonable con nodos de red no DS capaces o debe permitir implementaciones de clasificacin de paquetes simples en nodos del ncleo de la red o debe evitar estados por microflujos o por clientes dentro de los nodos del ncleo o debe acomodar despliegue incremental

3.3 Modelo arquitectnico de los Servicios Diferenciados

Las redes IP estn compuestas de nubes, regiones de relativa homogeneidad en trminos del control administrativo, tecnologa, ancho de banda. Determinando dnde terminan las nubes y las fronteras, nosotros determinamos dnde administrar los recursos y dnde el control es aplicado, para asegurarse que la poltica se lleva a cabo. Dentro de una nube, es posible sacar ventaja de la uniformidad dentro de su frontera, al agregar flujos de trfico individuales en un nmero limitado de agregados de trfico, donde cada uno tendr un distinto trato de envo. Por lo tanto, el trfico 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

Monografa de Ev. de Performance:Diffserv

13

determinar el trato de envo 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 decisin de poltica especfica sobre QoS es implementada, es por medio de la clasificacin, monitoreo, marcado, poltica y otros condicionamientos del trfico 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, sindolo, solamente los agregados de comportamiento. DiffServ utiliza el trfico agregado como su unidad fundamental de trfico, mas que como una corriente. Un campo de 6 bits en cada paquete identifica su agregado de trfico (BA) en el centro de la red y por ende, el trato de envo que cada paquete en el agregado va a recibir, sin importar a que microflujo ste pertenezca. ). Cada BA es identificado por una nico cdigo DS. Dentro del ncleo de la red, los paquetes son enviados de acuerdo al comportamiento por salto asociado al cdigo DS. En el borde de la red, ms estado de paquetes debe ser guardado al marcar ms campos de paquetes; por lo tanto, los agregados del interior podran estar hechos de paquetes de varios clientes, y ser condicionados y politizados diferente en el borde, pero con la misma expectativa de trato de envo una vez pasado el borde. Los routers dentro del dominio van a ser configurados para tratar a cada agregado de trfico en forma diferente: en un dominio que reconoce a N agregados, los routers sern cada uno capaz de tener N comportamientos de envo diferente, uno apropiado para cada agregado.

3.4 Separacin del control y envo

En el envo IP, la conectividad es lograda por la interaccin de dos componentes: la parte del envo del paquete y la parte del ruteo. El envo 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 trnsito y otras polticas as como tambin el mantener registro de las fallas de ruta. Un servicio es una descripcin de todo el trato que el trfico de un cliente recibe a travs de un dominio administrativo particular, a travs de un conjunto de dominios interconectados o de punta a punta. Las descripciones del servicio dentro de un dominio, son cubiertas por una poltica administrativa que es aplicada a la construccin y concatenacin de los agregados de trfico. Los TA son descriptos por un conjunto particular de reglas, en concordancia con un trato especfico de envo configurado de una manera particular.

3.5 Definiendo las primitivas del camino de envo

3.5.1 Requerimientos bsicos. La clasificacin saca corriente de paquetes. La poltica se encarga de asegurar que el comportamiento cumpla con las reglas que gobiernan la corriente de paquetes. El marcado propaga informacin sobre el agregado corriente abajo. PHBs de envo son generalmente implementados por colas de paquetes. Y el encolamiento asla una

Monografa de Ev. de Performance:Diffserv

14

corriente de trfico de otra. (Estos conceptos sern analizados con ms detalle ms adelante en este texto). 3.5.2 Marcado de DiffServ. Cada paquete IP lleva un byte llamado octeto de Tipo de Servicio (TOS octet). Es una caracterstica poco utilizada de IP. En la nueva versin 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 Trfico 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 patrn especfico de bits llamado cdigo DS, usado para indicar cmo cada router debe tratar al paquete. Para enfatizar el hecho de que ninguna informacin de sesin se necesita guardar, este tratamiento es conocido como Per-Hop Behavior (PHB). El octeto luce as:

Monografa de Ev. de Performance:Diffserv

15

Fig. 4: Aspecto del octeto TOS.

El campo de 6 bits contiene hasta 64 diferentes valores binarios. Los cdigos extra restantes dejan espacio para innovacin y optimizaciones operacionales locales. El marcado puede ocurrir en dos lugares: la fuente original de trfico, como ser un servidor web, marca el trfico. Esto tiene la ventaja de que el clasificador pude tener conocimiento explcito de la aplicacin en uso y puede por consecuencia marcar paquetes de una manera dependiente de la aplicacin. un router, como el primer router que el trfico encuentra, clasifica y marca el trfico. Esto tiene la ventaja de que no se necesita ningn cambio a servidores, pero requiere de alguna inteligencia extra en los routers.

3.5.3 Usando la marca. Cuando un paquete entra en un router, la lgica de ruteo selecciona su puerto de salida y el valor DSCP es usado para conducir el paquete a una cola especfica o tratamiento especfico 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 PHBs estndares 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 congestin y prdida son completamente descontroladas). Class selector behavior. Ac, siete valores DSCP funcionan desde el 001000 al 111000 y son especficos para seleccionar hasta siete comportamientos, cada uno de los cuales tiene una mayor probabilidad de un envo a tiempo que su predecesor. Expedited Forwarding behavior(EF). El valor recomendado es 101110. La tasa de partida del trfico EF debe igualar o superar una tasa configurable. EF intenta permitir la creacin 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 vaca. Assured Forwarding (AF) behavior.* Consiste en tres sub-comportamientos, AF1, AF2, AF3. Cuando la red est congestionada, los paquetes marcados con el DSCP para AF1 tienen la menor probabilidad de ser descartados por cualquier

ste es el PHB elegido para las simulaciones realizadas en ste trabajo.

Monografa de Ev. de Performance:Diffserv

16

router y los paquetes marcados para AF2 la ms alta. En general, hay N clases independientes con M niveles de descarte dentro de cada clase. Lo ms comn es N= 4 y M= 3. A cada clase se le deben asignar una mnima cantidad de recursos, pudiendo obtener ms si es que hay exceso.

3.5.4

El dominio de los Servicios Diferenciados

Un dominio DS es un conjunto de nodos DS que operan con una poltica de provisionamiento de servicios comn y con un conjunto de grupos PHB implementados en cada nodo. Esta formado por nodos DS de frontera que clasifican y posiblemente condicionen el trfico entrante para asegurarse que los paquetes que transitan el dominio estn apropiadamente marcados para seleccionar un PHB de los grupos PHB que son soportados dentro del dominio. Los nodos seleccionan el comportamiento de envo basndose en su cdigo DS, y lo hacen asociando ste valor a unos de los PHB soportados. La inclusin 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 ms redes bajo la misma administracin.

Fig. 5: Modelo de red donde se aprecian nodos interiores y de frontera.

3.5.5 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 basndose en el cdigo DS, sino, puede resultar en un comportamiento impredecible. Los nodos DS de frontera puede que sean requeridos para performar funciones de

Monografa de Ev. de Performance:Diffserv

17

condicionamiento de trfico tal como se define en un acuerdo de condicionamiento de trfico (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 cdigos por ejemplo (Ver Fig.8). Si un host no acta como nodo de frontera, entonces el nodo DS topolgicamente ms cercano a este host, acta como el nodo DS de frontera para el trfico de ese host. 3.5.6 Nodos de Ingreso y Egreso:

Los nodos de frontera actan tanto como nodos DS de ingreso y egreso para el trfico de distintas direcciones. 3.5.7 Regin de Servicios Diferenciados

Es un conjunto de uno o ms dominios DS contiguos. Los dominios DS en una regin DS pueden soportar distintos grupos PHB internamente y diferentes cdigos. Sin embargo, para permitir servicios que se expanden a travs de los dominios, los dominios DS contiguos deben cada uno establecer un SLA entre ellos que define cierta TCA, para especificar cmo el transito del trfico de un dominio DS a otro es condicionado en la frontera entre los dos dominios DS.

Fig.6: Modelo de red donde apreciar interaccin entre dominios DS a travs de los SLAs.

3.6 Clasificacin y condicionamiento de trfico

El SLA puede especificar la clasificacin del trfico y las reglas de re-marcado, as como perfiles de trfico y acciones a las corrientes de trfico que son dentro o fuera del perfil (in-out profile). El TCA entre dominios deriva del SLA. La poltica de clasificacin de paquetes identifica el subconjunto de trfico que puede llegar a recibir un servicio diferenciado, al ser condicionado y/o mapeado a uno o ms BA. El condicionamiento de trfico performa la medicin, conformacin, poltica y/o remarcado para asegurarse que el trfico entrante al dominio DS respeta las reglas especificadas en el TCA.

Monografa de Ev. de Performance:Diffserv

18

3.6.1 Clasificadores Definimos dos tipos de clasificadores. El clasificador BA clasifica paquetes basado en el cdigo DS solamente. El clasificador MF (Multi-Field) selecciona paquetes basado en el valor de una combinacin de uno o ms campos de cabecera, como dir. de origen, dir. destino, campo DS, protocolo ID, puertos origen y destino, entre otra informacin. El clasificador debe autentificar la informacin que usa para clasificar el paquete.

Fig.7: Arquitectura de un nodo exterior.

3.6.2 Perfiles de trfico Especifica las propiedades temporales de una corriente de trfico 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 cdigo DS X deben ser medidos con medidor de balde con fichas con tasa r y de tamao 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 ningn otro procesamiento o marcado o remarcado. Los paquetes fuera de perfil pueden ser encolados hasta que estn dentro del perfil (conformados), desechados (poltica) o remarcados con un cdigo nuevo (re-marcado). Hay que hacer notar que el perfil de trfico es un componente opcional de un TCA. 3.6.3 Acondicionadores de trfico Puede contener los siguientes elementos: medidor, marcador, conformador y despachador. Una corriente de trfico es seleccionada por un clasificador. Un medidor es usado para medir la corriente de trfico en base a un perfil de trfico. El estado del medidor respecto a un paquete en particular puede ser usado para afectar el marcado, despacho, o accin de conformacin.

Monografa de Ev. de Performance:Diffserv

19

Cuando los paquetes salen del acondicionador de trfico de un nodo DS frontera, el cdigo 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 trfico especificado en el TCA. Pasa informacin de estado a otras funciones de condicionamiento para tomar cierta accin para cada paquete tanto dentro como fuera de perfil. Marcador: setean el campo DS con un cdigo particular, agregando el paquete marcado a un behavior agregate DS particular. Puede que marque todos los paquetes que son dirigidos a l con un cdigo particular o puede estar configurado para marcar un paquete a un cdigo de un grupo de cdigos usados para seleccionar un PHB en un grupo PHB. Cuando el marcador cambia el cdigo en un paquete, se dice haber remarcado el paquete. Conformador: Retardan uno o todos los paquetes de una corriente de trfico de manera de que la corriente cumpla con el perfil de trfico estipulado. Usualmente tiene un buffer de tamao 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 trfico de manera de que la corriente cumpla con el perfil de trfico estipulado. Este proceso es conocido como poltica. Un despachador puede ser implementado como un caso especial de un conformador, si ponemos el tamao del buffer del conformador igual a 0 (o muy pocos) paquetes.

Fig.8: Arquitectura de nodos interiores.

3.6.4 Ubicacin de los acondicionadores de trfico o clasificadores MF Los acondicionadores de trfico estn 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 trfico que recibe un servicio particular. El trfico originado del dominio fuente a travs de una frontera puede ser marcado por las fuentes de trfico directamente o por medio de nodos intermediarios antes de que dejen el domino origen. Esto se conoce como pre-marcado.

Monografa de Ev. de Performance:Diffserv

20

Por ejemplo, supongamos una compaa que tiene la poltica 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 cdigo 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 trfico y marcar los paquetes CEO con el cdigo DS correcto. Hay ciertas ventajas en el hecho de marcar paquetes cerca de la fuente / origen de trfico. Primero, una fuente de trfico puede ms fcilmente tomar en cuenta las preferencias de las aplicaciones en el momento de decidir qu paquetes deben recibir mejor tratamiento de envo. Adems, la clasificacin de paquetes es ms simple antes que el trfico ha sido agregado con paquetes de otras fuentes, ya que el nmero de reglas de clasificacin que deben ser aplicadas dentro de un nodo nico es reducido. El nodo frontera del dominio fuente debe tambin monitorear la conformancia con el TCA, as como aplicar poltica, conformado, o pre-marcado de paquetes segn se necesite. En los nodos frontera de un dominio DS: El SLA entre dominios debe especificar cul tiene la responsabilidad de mapear las corrientes de trfico 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 trfico entrante puede no conformar con el TCA y debe estar preparado para reforzar el TCA de acuerdo a la poltica local. Cuando los paquetes son pre-marcados y condicionados en un dominio de corriente superior, una clasificacin 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 trfico necesarias en el trfico entrante.

3.7 Opciones del plano de control

3.7.1 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 cmo son tratados en el cuello de botella de la nube. Decisiones de control que pueden ser ms fcilmente expresadas en una base por nube, pueden ser desarrolladas ms tempranamente y ahorrar un montn de trabajo innecesario, comparado con un el intento de un diseo de un sistema completo basado en caminos reservados orientados a la conexin. Acercamientos orientados a la conexin pueden existir dentro de una nube: ATM, MPLS, RSPV/Intserv, pero un acercamiento totalmente orientado a la conexin para QoS no es razonable para futuros servicios punta a punta.

Monografa de Ev. de Performance:Diffserv

21

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, ms que en cada router, y hace posible el confinar estado por flujo a slo los routers frontera. Cada organizacin debe tener completa responsabilidad por el alojamiento de los recursos de trfico dentro de su dominio. As, la arquitectura de alojamiento est hecha de acuerdos a travs de las fronteras como la cantidad de cada agregado de trfico que le ser permitido pasar. 3.7.3 Ejemplo de QoS basado en nubes: Cuando una aplicacin en una red quiere un mejor nivel de QoS y la aplicacin has sido ya determinada como una aplicacin merecedora hay ciertas consideraciones a tener en cuenta. Primero, si la fuente y destino estn ambas en la misma red, la decisin de conceder o negar la peticin depende solo de recursos dentro de sa red. El tomar esta decisin depende solo de Me (ve dibujo). El pedir por QoS puede ser explcito o implcito. Si la aplicacin tiene un punto final que no es local, la decisin de conceder o negar la peticin 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 lmites compartidos. Si el otro punto final est en Far Away, entonces la peticin debe caer dentro de los lmites 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 PDBs: estructurando los agregados para cumplir con las expectativas
La IETF adopt la frase per domain behavior (PDB) para capturar la nocin de una descripcin precisa, incluyendo parmetros cuantitativos, del servicio provisto a un cierto agregado de trfico entre los bordes de un dominio de red de servicios diferenciados dado.

Monografa de Ev. de Performance:Diffserv

22

Un agregado de trfico (TA) es formalmente definido como una coleccin de paquetes con un cdigo DiffServ que mapea al mismo PHB, usualmente en un dominio DiffServ o algn subconjunto de un dominio DiffServ, por ejemplo, dentro de una nube de red nica. Dentro de una nube, un TA puede ser nicamente identificado por su DSCP. Cada PDB tiene, atributos mensurables y cuantificables que pueden ser usados para describir que pasa a sus paquetes a medida que entran y cruzan el dominio DS. Los atributos del PDB pueden ser absolutos o estticos y pueden ser parametrizados por propiedades de la red. Un amplio rango de medidas es posible. En general sern expresadas como lmites (por ej. decir que no ms del 0.1% de los paquetes sern descartados cuando se midan sobre un cualquier perodo mayor a T) o porcentajes (por ej. decir que el 70% de los paquetes repartidos van a ver un retardo menor a d mseg y 30% uno menor a 2.d mseg) ms que como valores absolutos.

3.9 Consideraciones para el alojamiento y configuracin

3.9.1 Funcionalidad del plano de control: Un agregado de trfico PDB particular puede ser visto como la porcin del camino de envo de un servicio borde a borde, mientras del plano de control sera usado para configurar las tablas de QoS en cada router para producir el TA correcto. El plano de control consiste de entidades que pueden producir mensajes de configuracin basados en informacin sobre la poltica y el estado de la red. El PHB en el interior de una nube de red no se espera que cambie frecuentemente. El objetivo de los DS es el compartir en forma controlada el ancho de banda de ciertas organizaciones de Internet. El etiquetado independiente por parte de los individuos es simple de implementar pero no es suficiente ya que es irrazonable el esperar que todos los individuos sepan todas las prioridades de sus organizaciones, usos actuales de la red y siempre marcar su trfico acorde a esto. Por lo tanto, la arquitectura requiere agentes para alojar y controlar la comparticin. Los alojadores tienen dos responsabilidades. La primera es el repartir las colocaciones del trfico de la nube e instalar sus routers de borde o lmites. La segunda es el administrar los mensajes, si los hay, que son mandados a travs de los bordes a regiones adyacentes. 3.9.2 Componentes generales: Host: puede ser dividido en una aplicacin y una componente de transferencia de datos. Un host pide permiso para mandar y manda (y recibe) paquetes para un TA particular. El host siempre manda sus datos al router borde. 3.9.3 La nube de red: La red tiene la responsabilidad de alojar la nube. En el manejo de peticiones, debe poder determinar el nivel de autoridad del solicitante. Dos componentes clave son el alojador y el router borde (edge router) como mecanismo de refuerzo.

Monografa de Ev. de Performance:Diffserv

23

1) Alojador: recibe peticiones y genera una respuesta y/o configuracin. Puede ser una entidad nica o una coleccin de entidades. Tiene la responsabilidad de parcelar los totales de nube, de cada BA, al configurar los routers borde. 2) Router borde: debe ser capaz de ser configurado para clasificar y pilitizar los flujos en BA. Su rango de capabilidades puede variar algo. En general va a necesitar saber cmo enviar un mensaje de peticin al dispositivo que est realizando el alojamiento. Un host servidor puede participar en estos mecanismos de una manera similar a un router borde, o puede cooperar muy cercanamente con un router borde, para asegurarse que TA reciban la QoS apropiada al final de su camino de red desde o hacia el servidor. Peticin: Los solicitantes incluyen hosts, aplicaciones, usuarios, administradores de red/sistema, y seales de confianza. Una peticin se espera contenga tal informacin como tasa y perodo de tiempo cuando la peticin va a ser servida.

Monografa de Ev. de Performance:Diffserv

24

4. PHB Expedited Forwarding (EF)

Los nodos de red que implementan Servicios Diferenciados, usan un cdigo en la cabecera IP para seleccionar un PHB, como el tratamiento de envo especfico para se paquete. El EF PHB puede ser usado para construir un servicio punta a punta de bajas prdidas, baja latencia, bajo jitter (colas muy pequeas) y/o ancho de banda asegurado, a travs de dominios DS. Tambin recibe por ello el nombre de Servicio Premium. Este servicio aparece en los puntos finales como una conexin punta a punta o una lnea virtual alquilada. Se caracteriza por no ofrecer garantas cuantitativas. Prdidas, latencia y jitter son todos debidos a las experiencias de las colas de trfico mientras transitan la red. Por lo tanto, el proveer bajas prdidas, latencia y jitter para algunos agregados de trfico, significa asegurarse que el agregado no vea ninguna (o muy chicas) cola. Las colas se incrementan cuando la tasa de trfico entrante excede la tasa de salida en algn nodo. El crear este servicio tiene dos partes: 1. Configurar los nodos de manera que el agregado tenga una tasa mnima de salida bien definida. (Bien definida significa independiente del estado dinmico del nodo, en particular de la intensidad de otro trfico en el nodo.) 2. Acondicionar el agregado tal que su tasa de llegada en cualquier nodo sea siempre menor que la tasa de salida mnima configurada para se nodo.

Descripcin del EF PHB:

Es un tratamiento de envo para un agregado de trfico particular donde la tasa de salida de los paquetes del agregado de cualquier nodo DS debe ser igual o superior a una tasa configurable. El trfico EF debe recibir sta tasa independientemente de la intensidad de cualquier otro trfico que est intentando transitar el nodo. La tasa mnima configurable debe seteada por un administrador de red.

Mecanismos de ejemplo para implementar el EF PHB:

Varios tipos de mecanismos despachadores de cola pueden ser empleados para repartir el comportamiento de envo descrito anteriormente. Una simple cola con prioridad dar el comportamiento apropiado siempre y cuando no halla una cola con prioridad superior que pueda apropiarse el EF por ms de un tiempo de paquete a la tasa configurable. Otra implementacin posible es con un despachador CQB que de una prioridad de cola EF por encima de la tasa configurable.

Mutabilidad:
Los paquetes marcados con un EF PHB, pueden ser remarcados en un borde de un dominio DS solo si pasan a ser cdigos que satisfagan el EF PHB.

Monografa de Ev. de Performance:Diffserv

25

Entubado:
Cuando los paquetes EF son entubados, los paquetes entubados deben estar marcados como EF.

Consideraciones de Seguridad:
Para protegerse de ataques de rechazos de servicios, el borde de un dominio DS debe estrictamente aplicar la poltica a todos los paquetes marcados EF, de manera de asegurar la tasa negociada con los dominios bordes superiores. (Esta tasa debe ser menor o igual que la tasa de EF PHB configurada.) Los paquetes en exceso de la tasa negociada deben ser descartados. Si dos dominios adyacentes no han negociado una tasa EF, el domino inferior debe usar una tasa igual a 0. (como ser tirar todos los paquetes marcados como EF). Como el servicio premium de punta a punta construido del EF PHB, requiere que el dominio superior (o corriente arriba) conforme y aplique una poltica sobre el trfico EF marcado para encontrar la tasa negociada con el dominio inferior (o corriente abajo), el policer del domino inferior nunca debe dejar paquetes desechados. Asi, estos descartes deben ser anotados como posibles violaciones de seguridad.

Monografa de Ev. de Performance:Diffserv

26

5. PHB: Assured Forwarding

El PHB Assured Forwarding (AF) est basado en el assured service (AS) , en el que: Se asegura que el trfico conforme al perfil contratado para un flujo ser entregado sin prdidas con probabilidad muy alta, an en caso de congestin Se permite exceder el perfil, pero con la comprensin de que el trfico 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 PHB Assured Forwarding [RFC 2597] permite ofrecer distintos niveles de garanta de entrega o de calidad relativa para paquetes IP. Para esto se definen N clases AF tal que a cada clase AF se le reservan ciertos recursos (buffer y ancho de banda ) en cada uno de los nodos DS, de forma que los retardos y/o prdidas de una clase sean siempre inferiores a los de una clase de menor prioridad. Dentro de cada clase, los paquetes se pueden clasificar a su vez en M categoras de preferencia de descarte (dependiendo del marcado en la frontera).En caso de congestin la preferencia de descarte determina la importancia relativa del paquete dentro de la clase.Actualmente N=4 y M=3 son definidos para uso general.Un paquete que pertenezca a una clase AF i y tenga una preferencia de descarte j es marcado con el cdigo Afij. En un nodo DS el nivel de garanta 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 congestin en la clase AF, la precedencia de descarte del paquete

Una clase AF tambin puede ser configurada para recibir ms recursos que los mnimos previstos cuando hay exceso de recursos en otras clases AF o de otros grupos PHB.

Acondicionador de trfico
Tpicamente, en la frontera de un dominio se controlar y monitorizar la cantidad de trfico de cada clase AF que entra o sale del dominio. El control de trfico puede implicar retardo, descarte, aumento o disminucin de la precedencia de descarte y Monografa de Ev. de Performance:Diffserv 27

reasignacin a otra clase AF .No se debe realizar ninguna accin que implique desordenar los paquetes de un microflujo

Comportamiento de los paquetes en la cola y descarte de paquetes

La implementacin debe minimizar las congestiones de larga duracin en cada clase AF, pero permitiendo congestiones transitorias causadas por rfagas.Esto requiere un algoritmo de manejo de cola activo.Un ejemplo de algoritmo es Random Early Drop (RED). La respuesta a las congestiones de larga duracin tiene que ser el descarte de paquetes y la respuesta a las congestiones transitorias debe ser la de poner en la cola los paquetes.La respuesta a la congestin debe ser gradual y no abrupta , para permitir a todo el sistema llegar aun punto estable de operacin.Una manera de hacer esto es con RED. RED se basa en el descarte aleatorio de paquetes tras la deteccin temprana de la congestin, una vez superado un umbral del tamao medio de la cola.

Algoritmo RED
A la llegada de un paquete se estima el tamao medio de la cola de slida Q Si Q < minth Funcionamiento normal: Almacenamiento del paquete Si minth < Q < maxth Evitar congestin: El paquete se descarta con prob. creciente linealmente con Q: Pdrop=Pmax*(Q minth)/(maxthminth) Si Q >maxth Congestin: Se descarta el paquete

Monografa de Ev. de Performance:Diffserv

28

Una variante muy usada es RIO (RED IN/OUT), que usa RED con dos niveles de precedencia de descarte (dos conjuntos de parmetros), uno para paquetes IN y otro para OUT (maxOUT < minIN ). Variantes de RIO:

RIO-C (RIO Coupled): La probabilidad de descartar un paquete out-of profile est basado en el tamao promedio de todas las colas virtuales; mientras que la probabilidad de descartar un paquete in-profile est basada solamente en el tamao promedio de su cola virtual. RIO-D (RIO De-coupled): La probabilidad de descartar un paquete out-of profile est basado en el tamao promedio de su cola virtual

Monografa de Ev. de Performance:Diffserv

29

6. Simulaciones
En esta parte del trabajo vamos a realizar simulaciones en el Ns~2 para comparar la performance de una cierta red cuando hay un cuello de botella al que le llegan tres tipos de trfico: VoIP FTP-TCP CBR-UDP

En una primera parte estudiaremos la performance de la red al ofrecer estos servicios midiendo ciertos parmetros importantes en cada uno de los trficos cuando en la red no se implementa diffserv , en la segunda parte estudiaremos la performance pero con diffserv ya implementando. Se configur la red de la siguiente manera :

n0-R0 2Mb 15mseg n1-R0 2Mb 15mseg n2-R0 2.5Mb 15mseg R0-R1 4Mb 15mseg R1-R2 1Mb 10mseg R2-n5 2Mb 60mseg R2-n6 2Mb 60mseg

Monografa de Ev. de Performance:Diffserv

30

Trfico
VoIP

El modelo de trfico se puede describir como un proceso on-off.Durante la conversacin cada participante est o bien hablando o bien en silencio. Hemos simulado este trfico de manera que los perodos de actividad y silencio son generados con una variable aleatoria con distribucin exponencial.El valor medio de esta variable es igual a T_on durante los perodos de actividad y a T_off en los perodos de silencio.La siguiente figura muestra un ejemplo grfico de este modelo.

En nuestro caso T_on= 250 mseg y T_off= 150 mseg y el trfico va del nodo 1 al nodo 5. Los paquetes de VoIP deben recibir un trato especial ya que es muy sensible a retardos y necesita un ancho de banda garantizado.Entonces es necesario ofrecer cierta QoS de manera de poder disminuir el retardo en las colas. FTP-TCP

Del nodo 2 al nodo 6 .En este tipo de trfico lo que importa es ofrecer un servicio de manera de aumentar el troughput , o sea el ancho de banda disponible. CBR-UDP

Del nodo 0 al nodo 5 En este tipo de trfico lo que importa es ofrecer un servicio de manera de minimizar al nmero de paquetes prdidos.

Monografa de Ev. de Performance:Diffserv

31

Primera Parte
Simulacin sin Diffserv Grficas: 1- Retardo de ida: VoIP 2- Throughput FTP-TCP 3- Paquetes prdidos CBR-UDP

Monografa de Ev. de Performance:Diffserv

32

El retardo de ida es aproximadamente 100 mseg ( suma de los retardos de los links).De la primera grfica se ve que hay paquetes con retardos de hasta 300 mseg ( aceptable < 150 mseg ) esto se debe al retardo que sufren los paquetes en la cola debido al tratamiento no-diferenciado.Con respecto al throughput vemos que oscila , debido a que el protocolo TCP detecta la congestin y baja su tamao de ventana. La cantidad total de paquetes CBR-UDP prdidos durante la simulacin fue de 48.

Monografa de Ev. de Performance:Diffserv

33

Segunda parte: Diffserv

Se implementaron 3 clases independientes (una para cada trfico) con 2 niveles de descarte para cada clase.

Policy Table(3):
Flow (0 to 5): Token Bucket policer, initial code point 10, CIR 1000000.0 bps, CBS 4000.0 bytes. Flow (2 to 6): Token Bucket policer, initial code point 20, CIR 350000.0 bps, CBS 4000.0 bytes. Flow (1 to 5): Token Bucket policer, initial code point 30, CIR 250000.0 bps, CBS 4000.0 bytes.

Monografa de Ev. de Performance:Diffserv

34

Policer Table:
Token Bucket policer code point 10 is policed to code point 11. Token Bucket policer code point 20 is policed to code point 21. Token Bucket policer code point 30 is policed to code point 31.
Exp: El trfico VoIP tiene el cdigo 10 (cola fsica 1 , cola virtual 0) y si no cumple con la poltica es degradada, y se le asigna en cdigo 11 (cola fsica 1 , cola virtual 1) dnde la probabilidad de descarte es mucho mayor. En la primera simulacin se estudia la performance cuando el despachador es del tipo PQ y en la segunda cuando el despachador es del tipo WRR. En todas las simulaciones se estudia como vara la cantidad de paquetes descartados cuando se utilizan las dos variantes de RIO: RIO-C , RIO-D

Cola Prioritaria (PQ)

Da prioridad estricta al trfico importante asegurando un servicio rpido en cada punto de la red.La desventaja que tiene este mecanismo es que puede dejar de servicio a trfico menos priritario. En esta simulacin se le da la mayor prioridad a VoIP de manera de disiminuir al mnimo posible el tiempo de espera en la cola.En segundo lugar se le da prioridad al trfico TCP de manera de obtener un throughput aceptable y el trfico menos priritario es el UDP. Como se ve en la primera grfica , el retardo (VoIP) oscila entre valores de 0.104 y 0.114 segundos lo que demuestra el trato prioritario que se les da a estos paquetes ya que no pierden tiempo en la cola ,llegan y son despachados enseguida.De la segunda grfica vemos que el throughput aumento y que ya empieza a oscilar alrededor de un valor estable.La desventaja de todo esto es que se descartaron alrededor del 74 % de los paquetes CBR-UDP , o sea lo deja casi sin sevicio.

Monografa de Ev. de Performance:Diffserv

35

Grficas:

Monografa de Ev. de Performance:Diffserv

36

Packets Statistics RIO-D ======================================= CP TotPkts TxPkts ldrops edrops -- ---------------------All 11230 10029 1183 18 10 6433 6433 0 0 20 1557 1557 0 0 21 1639 1623 0 16 30 1253 328 923 2 31 348 88 260 0 Packets Statistics RIO-C ======================================= CP TotPkts TxPkts ldrops edrops -- ---------------------All 10600 9805 734 61 10 6342 6342 0 0 20 1416 1416 0 0 21 1241 1194 18 29 30 1253 776 473 4 31 348 77 243 28 Obs: ldrops son los paquetes descartados debido al cuello de botella. edrops (early drops) descarte temprano de paqutes por el algoritmo RED

Monografa de Ev. de Performance:Diffserv

37

Una manera de disminuir la cantidad de paquetes prdidos sin disminuir el retardo de VoIP es la de mantener las prioridades pero limitar el ancho de banda disponible al trfico TCP.

Monografa de Ev. de Performance:Diffserv

38

Como se ve en las grficas el retardo no cambia , baja el throughput y oscila alrededor de el valor que se lmito el ancho de banda.La cantidad de paquetes descartados bajo al 22% .Cuanto ms lmite el ancho de banda menos paquetes descartados voy a tener.

Monografa de Ev. de Performance:Diffserv

39

Weighted Round Robin (WRR)

El despachador WRR distribuye ancho de banda entre sus clases usando el esquema de weighted round robin. Todas las clases que tengan suficiente demanda obtendrn un ancho de banda proporcional a los pesos asociados con las clases. Se puede calcular el ancho de banda efectivo (in Mbps) para una cola en particular usando la siguiente frmula (W/S) x B = n Mbps, donde, W WRR peso de la cola S Suma de todos los pesos de las colas

B Ancho de banda en Mbps n Ancho de banda efectivo en Mbps

Resultados para VoIP= 50% del ancho de banda TCP=30% UDP=20%

Monografa de Ev. de Performance:Diffserv

40

Monografa de Ev. de Performance:Diffserv

41

Packets Statistics RIO-D ======================================= CP TotPkts TxPkts ldrops edrops -- ---------------------All 5206 5189 0 17 10 613 613 0 0 20 1619 1619 0 0 21 1723 1706 0 17 30 1251 1251 0 0 Packets Statistics RIO-C ======================================= CP TotPkts TxPkts ldrops edrops -- ---------------------All 4678 4631 22 25 10 617 617 0 0 20 1488 1488 0 0 21 1322 1275 22 25 30 1251 1251 0 0 Como se esperaba el retardo aumento (ero igual vara entre valores aceptables )debido a que ya no es tan priritario este servicio.De la segunda grfuca se ve que el throughput disminuyo y se perdieron algunos paquetes pero el servico sigue siendo mucho mejor que en el caso que no se implemento diffserv.De la tercera grfica se ve que en este caso no se perdieron paquetes , lo que permitira aumentar un poco el peso (porcentaje del ancho de banda) del servicio de VoIP de manera de bajar el retardo

7. Conclusiones
En este trabajo se realiz un estudio de la arquitectura de servicios diferenciados y se hicieron simulaciones en el Ns~2.Se simulo una pequea red con un cuello de botella al que le llegaban tres tipos de trfico con distintos requerimientos de calidad de servicio.Se implemento el PHB AF (modificado) y se estudio como se afectaban los servicios al variar el tipo de despachador : PQ y WRR Con el despachador del tipo prioritario se logr minimizar el retardo de VoIP , pero se dejo sin servicio el trfico CBR-UDP .Con el despachador WRR se reparti el ancho de banda de manera de lograr tener un retardo bajo , un througput alto y que no se perdieran paquetes.

Monografa de Ev. de Performance:Diffserv

42