Sie sind auf Seite 1von 23

DIFFSERV 1. INTRODUCCION 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. 2. DESARROLLO 2.2. TRASFONDO 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. 2.1.1. 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. 2.1.2. UN ACERCAMIENTO MAS 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. 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 internodos, 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. 2.1.3. 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. 2.1.4. 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. 2.2. MOTIVACIONES DEL USO DEL DIFFSERV 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.

2.2.1. QUE APLICACIONES DEBE 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. 2.2.2. 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.

2.2.3. 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.2.4. COMO PUEDEN LOS SERVICIOS DE PUNTA A PUNTA SER CONSTRUIDOS EN UNA INTERNET DE BORDE A BORDE? 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. 2.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 sa lto, 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. 2.3.1. TERMINOLOGIA 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. 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 remarcado. 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. 2.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: - Debe acomodar una amplia variedad de servicios y proveer polticas, extendiendo una red punta a punta o una red particular. - 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. - 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. No debe depender de la aplicacin de sealizacin salto a salto. - Debe requerir solo una pequea cantidad de comportamientos de envo, cuya complejidad de implementacin no domine el costo de un dispositivo de red. - Debe utilizar solo estado de clasificacin de agregados dentro del ncleo de la red. - Debe permitir interoperabilidad razonable con nodos de red no DS capaces. - Debe permitir implementaciones de clasificacin de paquetes simples en nodos del ncleo de la red. - Debe evitar estados por microflujos o por clientes dentro de los nodos del ncleo o debe acomodar despliegue incremental. 2.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 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. 2.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. 2.3.5. Definiendo las primitivas del camino de envo 2.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 corriente de trfico de otra. (Estos conceptos sern analizados con ms detalle ms adelante en este texto). 2.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.

2.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 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. 2.3.6. 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.

2.3.7. 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 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. Los nodos DS interiores deben poder performar re-marcado de cdigos. 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. 2.3.8. 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.

2.3.9. 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. 2.3.9.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.

2.3.9.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. 2.3.9.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. 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.

2.3.10. Opciones del plano de control 2.3.10.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. 2.3.10.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. 2.3.10.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 Notme-2, mientras Not-me-2 debe decidir si hay suficientes recursos para Far Hawai.

2.3.11. Consideraciones para el alojamiento y configuracin 2.3.11.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. 2.3.11.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. 2.3.11.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. 2.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. 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. 2.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 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

3.

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.

Das könnte Ihnen auch gefallen