Documentos de Académico
Documentos de Profesional
Documentos de Cultura
DiffServ IntServ
DiffServ IntServ
do nivel de prioridad Los routers van agregando las demandas de los usuarios y propagndolas por el trayecto Esto le da al usuario una confianza razonable de conseguir la QoS solicitada
Pueden coexistir
IntServ (Integrated Services) Lleva como filosofa la reserva de recursos, cada router del trayecto ha de tomar nota y efectuar la reserva solicitada Caractersticas RFC 1633 : Integrated Services in the Internet Architecture : an Overview Para cada flujo (puede ser agregado) reserva recursos en todo el camino Soporta control de admisin, llevada a cabo en cada salto Orientado a conexin Requiere un protocolo de sealizacin que soporten todos los routers No requiere modificar los protocolos existentes Clasificacin por flujo empleando las direcciones IP, puertos y protocolo (5 valores)
Servicios Mejor Esfuerzo (Best Effort) Servicio de control de carga (Controlled load service) RFC 2211 : Specification of the Controlled-Load Network Element Service Prcticamente sin prdidas Servicios Garantizados (Guaranteed service) RFC 2212 : Specification of Guaranteed Quality of Service Garantas de Band Width Sin prdidas en buffers
Sealizacin (Signaling) Requisitos: Debe poderse usar en redes IP Emplear tablas de rutas existentes Reaccionar ante cambios de rutas Soportar multicast Flujos que se agregan en rbol Pequea sobrecarga Pocos mensajes y pequeos Modular y fcil de extender Mltiples protocolos o sistemas de gestin se podran plantear para ofrecer este servicio
Resultados: RFC 2205 : Resource ReSerVation Protocol (RSVP) Version 1 Functional Specification No sirve para calcular el camino (no es un routing protocol)
RSVP Directamente sobre IP (protocolo 46) Reservas unidireccionales: bidireccional requiere dos reservas Soporte de multicast: puede agregar reservas en el sentido hacia la fuente del rbol de distribucin multicast Las reservas las inicia el receptor del flujo lo cual ayuda en esa agregacin al ascender en el rbol
RSVP : Path RSVP no es un protocolo de encaminamiento No decide el camino que debe llevar el flujo Los datos seguirn el camino unicast/multicast decidido por otros protocolos El mensaje RSVP de reserva (Resv) seguira as el camino indicado por las tablas de rutas
Si las rutas son asimtricas los datos y la reserva no siguen el mismo camino: reserva hecha por donde no van los datos ! Para resolverlo hay otro tipo de mensaje (Path) que enva la fuente
RSVP : Path El mensaje Path lo enva la fuente y sigue la ruta calculada por los protocolos de encaminamiento El mensaje Path sigue el mismo camino que seguirn los datos Este mensaje establece un estado en los routers que soportan RSVP en el camino El mensaje Resv emplea ese estado para seguir el camino inverso Si no hay recursos suficientes falla la reserva Falla incluso si existe otro camino que s disponga de recursos El estado es un soft state lo cual quiere decir que se elimina si no se refresca Los mensajes Path y Resv se envan de forma peridica para mantener el estado instalado
RSVP: states Actualizaciones peridicas refrescan el estado Se libera al dejar de recibir actualizaciones Permite adaptarse ante cambios en la topologa Permite adaptarse ante cambios en los miembros de un rbol de distribucin multicast Alternativa (no soportada): Hard state Se mantiene hasta liberarlo explcitamente Requiere algoritmo ante errores
RSVP : Parametrizacin Una reserva consiste viene dada por un flow descriptor Un flow descriptor est compuesto por un filter spec y un flow spec filterspec (Filter specification) Determina qu paquetes forman el flujo Flujo identificado en base a IPs + puertos + protocolo
Permite configurar el clasificador flowspec (Flow specification) Especifica la QoS deseada y permite configurar el planificador Emplea dos parmetros numricos TSpec (Traffic specification) Descripcin del trfico Parmetros de un tocken bucket por el que pasa el trfico Mean rate, tocken bucket depth, max rate, max packet length RSpec (Service Request specification) Requisitos de QoS impuestos a la red BW, retardo, probabilidad de prdida
RSVP e IntServ RFC 2210 : The Use of RSVP with IETF Integrated Services Se especifica el contenido de los parmetros de QoS que llevan los mensajes de RSVP para hacer reservas IntServ RSVP SENDER_TSPEC objects: Viaja en mensaje Path Sender TSpec : descripcin del trfico generada por el emisor Emplea para ello parmetros de token bucket RSVP ADSPEC objects: Viaja en mensaje Path Contienen informacin modificada por los nodos de la red sobre la disponibilidad de servicio en el camino RSVP FLOWSPEC objects: Viaje en mensaje Resv Receiver TSpec : descripcin del trfico dada por receptor Receiver RSpec : reserva solicitada por receptor Puede cambiar en la red debido a mergings
Ejemplo de reserva unicast La fuente de los datos enva mensaje Path conteniendo objetos:
Sender Template : describe los paquetes para poder clasificarlos (IPs, puertos) SENDER_TSPEC : descripcin del trfico y por tanto recursos necesarios ADSPEC PHOP: Previous Hop, direccin IP suya Direccin IP origen de la fuente y destino del receptor
Ejemplo de reserva unicast El paquete IP lleva la opcin IP Router Alert (RFC 2113) para que los routers no simplemente conmuten el paquete El router instala el estado que incluye la direccin IP del nodo upstream (PHOP) Modifica el ADSPEC segn sus capacidades y recursos de QoS Reenva en funcin de direccin IP destino del paquete IP (receptor final) y su tabla de rutas Objeto PHOP pasa a ser la direccin IP del interfaz por el que reenva
Ejemplo de reserva unicast El paquete IP lleva la opcin IP Router Alert (RFC 2113) para que los routers no simplemente conmuten el paquete El router instala el estado que incluye la direccin IP del nodo upstream (PHOP) Modifica el ADSPEC segn sus capacidades y recursos de QoS Reenva en funcin de direccin IP destino del paquete IP (receptor final) y su tabla de rutas Objeto PHOP pasa a ser la direccin IP del interfaz por el que reenva Si un router no soporta RSVP reenva el paquete como un paquete IP normal y corriente
Ejemplo de reserva unicast Los routers que soporten RSVP repiten el proceso: El router instala el estado que incluye la direccin IP del nodo upstream (PHOP) Modifica el ADSPEC segn sus capacidades y recursos de QoS Reenva en funcin de direccin IP destino del paquete IP (receptor final) y su tabla de rutas Objeto PHOP pasa a ser la direccin IP del interfaz por el que reenva
Ejemplo de reserva unicast Hasta llegar el paquete al que ser el receptor del flujo de datos Ahora ya est instalado un soft state en todos los routers del camino que soporten RSVP Eso va a permitir al mensaje Resv seguir el camino inverso An no hay reserva hecha El SENDER_TSPEC no ha sido modificado y con eso la aplicacin conoce las caractersticas del flujo El ADSPEC contiene la descripcin de la QoS que podra ofrecer el camino La aplicacin receptora podra emplear el ADSPEC para decidir el tipo de reserva a hacer (por ejemplo si va a poder pedir un vdeo SD o HD)
Ejemplo de reserva unicast El receptor de los datos enva mensaje Resv conteniendo objetos: RECEIVER_TSPEC : descripcin de la cantidad de trfico para la que es la reserva (con parmetros de token bucket) y del tipo (GS, CL, BE) FILTERSPEC FLOWSPEC : RECEIVER_TSPEC : descripcin de la cantidad de trfico para la que es la reserva (con parmetros de token bucket) y del tipo (GS, CL, BE) RSPEC : existe solo para la clase Controlled Load e indica la reserva a hacer Direccin IP origen la del receptor de los datos, IP destino la del primer router RSVP en el camino (vena en el PHOP) : parmetros para clasificar a los paquetes de este flujo
(srcIP+dstIP+srcPort+dstPort+protocol)
Ejemplo de reserva unicast Routers con soporte para RSVP aplican polticas para decidir si aceptan la reserva solicitada Se emplea control de admisin para decidir si hay recursos suficientes Si ambos tienen xito: Se instala clasificador basado en el FILTERSPEC Se reservan recursos en el planificador del enlace por el que llega el Resv basados en el FLOWSPEC Puede tener que hacer merging con otras solicitudes y que se modifiquen los parmetros de la reserva upstream Si no hay errores enva el Resv upstream empleando la informacin de estado almacenada para que siga el camino inverso al del Path Direccin IP origen del router que enva, IP destino la del siguiente router RSVP upstream (valor que se guard del PHOP)
Ejemplo de reserva unicast Routers con soporte para RSVP aplican polticas para decidir si aceptan la reserva solicitada Se emplea control de admisin para decidir si hay recursos suficientes Si ambos tienen xito: Se instala clasificador basado en el FILTERSPEC Se reservan recursos en el planificador del enlace por el que llega el Resv basados en el FLOWSPEC Puede tener que hacer merging con otras solicitudes y que se modifiquen los parmetros de la reserva upstream Si no hay errores enva el Resv upstream empleando la informacin de estado almacenada para que siga el camino inverso al del Path Direccin IP origen del router que enva, IP destino la del siguiente router RSVP upstream (valor que se guard del PHOP) Los routers que no soportan RSVP reenva el paquete IP con normalidad
Ejemplo de reserva unicast Routers con soporte para RSVP aplican polticas para decidir si aceptan la reserva solicitada Se emplea control de admisin para decidir si hay recursos suficientes Si ambos tienen xito: Se instala clasificador basado en el FILTERSPEC Se reservan recursos en el planificador del enlace por el que llega el Resv basados en el FLOWSPEC Puede tener que hacer merging con otras solicitudes y que se modifiquen los parmetros de la reserva upstream Si no hay errores enva el Resv upstream empleando la informacin de estado almacenada para que siga el camino inverso al del Path Direccin IP origen del router que enva, IP destino la del siguiente router RSVP upstream (valor que se guard del PHOP) Los routers que no soportan RSVP reenva el paquete IP con normalidad Los que s lo soportan repiten el proceso de verificacin y reserva ()
Ejemplo de reserva unicast La fuente recibe el Resv y conoce la reserva que se ha hecho
Ejemplo de reserva unicast La fuente recibe el Resv y conoce la reserva que se ha hecho El mensaje puede solicitar una confirmacin (ResvConf hacia el receptor)
Ejemplo de reserva unicast La fuente recibe el Resv y conoce la reserva que se ha hecho El mensaje puede solicitar una confirmacin (ResvConf hacia el receptor) Para mantener el soft state se envan peridicamente de nuevo los mensajes Path y Resv Los enva cada nodo, no extremo a extremo
Ejemplo de reserva unicast La fuente recibe el Resv y conoce la reserva que se ha hecho El mensaje puede solicitar una confirmacin (ResvConf hacia el receptor) Para mantener el soft state se envan peridicamente de nuevo los mensajes Path y Resv Los enva cada nodo, no extremo a extremo Emisor o receptor pueden liberar la reserva enviando un PathTear o un ResvTear respectivamente
Uso de RSVP Est bastante implementado Pero no est muy extendido su uso en redes IP Hay muchas dudas sobre la escalabilidad de la solucin al requerir procesado por flujo Hay modificaciones que mejoran la escalabilidad reduciendo por ejemplo los mensajes de refresco Tambin requiere intervencin de la aplicacin lo cual la vuelve ms compleja API complicado
Paquete RSVP
IntServ over DiffServ RFC 2998 : A Framework for Integrated Services Operation over Diffserv Networks Se plantea cmo interconectar dominios IntServ a travs de dominios DiffServ Paquetes de una reserva GS deberan marcarse para emplear el PHB EF Paquetes de una reserva CL podran marcarse para emplear un PHB AF Control de admisin en la regin DiffServ? Opciones: a. Los routers del dominio DiffServ ignoran los mensajes RSVP: el dominio debe ser capaz de soportar todo el trfico recibido b. CAC en la frontera: router frontera ve los Resv y conoce los flujos que atraviesan el dominio DS; hace con eso CAC
c. CAC en cada salto del dominio DS: routers DS entienden RSVP como para hacer CAC aunque su plano de datos sigue siendo DS
RSVP-TE RFC 3209 : RSVP-TE: Extensions to RSVP for LSP Tunnels Muy extendido en combinacin con MPLS/GMPLS RSVP-TE permite especificar el camino en vez de dejarlo en manos del IGP Establece MPLS LSPs, incluyendo el intercambio de etiquetas Permite reservas bidireccionales
DiffServ: Los paquetes se marcan a la entrada de la red DiffServ, segun diferentes categorias o clases. Entre diferentes clases se establecen diferentes parametros de QoS. En una misma clase se agregan diferentes flujos que recibiran el mismo tratamiento de QoS.
IntServ (RSVP): antes de utilizar la red es necesario solicitar una reserva de recursos a lo largo de todo el camino por el que circularan los paquetes, desde el origen al destino. Se obtiene una garanta de que se va a conseguir cierta QoS.
Diffserv Busca ofrecer clases de servicio cualitativas con un comportamiento particularizado para cada clase, como si cada una tuviese un medio de transmisin en exclusiva. Escalabilidad: Con funciones simples en el ncleo de la red y relativamente complejas en los routers de frontera o en los terminales. La sealizacin empleada en redes de conmutacin de circuitos como la red telefnica requiere mantener informacin de estado en el router para cada flujo No permite el escalado si existen muchos flujos
La arquitectura Differentiated Services (DiffServ) del IETF no define clases de servicios concretas sino que ofrece componentes funcionales que permiten construir clases de servicio.
Marcado del trfico DiffServ en la cabecera IPv4 Los paquetes se marcan en el campo de 8 bits Type of Service (ToS) de IPv4
Marcado del trfico DiffServ en la cabecera IPv6 Los paquetes se marcan en el campo de 8 bits Type of Service (ToS) de IPv6
Marcado del trfico DiffServ: campo DSCP Se usan 6 bits para identificar Differentiated Service Code Point (DSCP) que determinan el comportamiento por salto (PHB, Per-Hop Behavior) que recibir el paquete en los routers de la red DiffServ. Quedan los 2 bits menos significativos del campo ToS que no se usan para DiffServ, sino para la notificacin de congestin (Explicit Congestin Notification, ECN). ECN es utilizado conjuntamente por los extremos de una conexin TCP y los routers intermedios que usan la disciplina de cola RED, Random Early Detection.
Ilustracin 3: DSCP + ECN Fuente: Departamento de Sistemas Telemticos y Computacin (GSyC). Universidad Rey Juan Carlos
INTSERV El marcado y vigilancia de paquetes, el aislamiento de trfico y la planificacin en el nivel de enlace pueden proporcionar una clase de servicio con mejor rendimiento que otra. Con ciertas disciplinas de planificacin como la planificacin con prioridad, las clases de trfico inferiores son prcticamente invisibles" para la clase de trfico con prioridad ms alta
Con un dimensionamiento apropiado de la red, la clase de servicio de ms alta prioridad puede conseguir tasas de prdida de paquetes y retardos extremadamente bajos Pero, puede la red garantizar que un flujo activo determinado de alta prioridad continuar recibiendo dicho servicio independientemente de la congestin la red? NO! No hay que olvidar que ningn mecanismo puede multiplicar el ancho de banda ms all de la capacidad de cada enlace. Trabajo del IETF entre 1995 y 1997 Desarrollaron especificaciones para un conjunto de clases de servicio diseadas para satisfacer los requisitos de diferentes clases de aplicaciones. Para ofrecer QoS, IntServ se basa en un modelo de reserva de recursos por flujo en todo el trayecto que siguen los paquetes de dicho flujo. Un flujo queda identificado por la direccin IP origen, la direccin IP destino, el protocolo de nivel de transporte y opcionalmente el puerto destino. La aplicacin es responsable de gestionar la reserva de recursos en la red. SERVICIO GARANTIZADO Para aplicaciones no elsticas que requieren que un paquete nunca se descarte y no llegue tarde La red debe garantizar que el mximo retardo que cualquier paquete puede experimentar tiene un valor especificado La aplicacin puede entonces planificar cundo comenzar a reproducir despus de empezar a recibir datos de un flujo multimedia que va siendo almacenado localmente antes de comenzar la reproduccin Anlogo a EF (expedited forwarding) de DiffServ.
SERVICIO DE CARGA CONTROLADA Para aplicaciones elsticas que toleran retardos. Estas aplicaciones funcionan bien en redes poco congestionadas, reajustando cunto bufering realizan antes de comenzar a reproducir adaptativamente segn los retardos observados dinmicamente Emula una red poco cargada aunque haya congestin.
Cmo?
Con WFQ se aisla el trfico y con control de admisin se limita la cantidad de trfico de tipo controlled load Anlogo a AF (assured forwarding) de DiffServ.
Mecanismos de IntServ Flowspec: Se necesita un servicio para comunicar a la red el tipo de servicio requerido por cada aplicacin o Puede ser Cualitativamente (ej. "quiero controlled load') o o cuantitativamente (quiero retardo mximo de lOOms") Control de admisin: la red tiene que decidir si puede o no proporcionar el servicio requerido Protocolo de reserva de recursos (RSVP): las aplicaciones que generan el trfico y los elementos de la red tienen que intercambiar informacin como peticiones de servicio, flowspecs y el resultado de las decisiones de control de admisin (llamado sealizacin en redes de conmutacin de circuitos) Disciplinas de planificacin: los routers tienen que cumplir los requisitos especificados en los flowspec Flowspec Dos partes diferenciadas: TSpec (Traffic Specification): describe las caractersticas del trfico del flujo que se va a enviar usando la abstraccin de la cubeta con fichas (token bucket). RSpec (Request Specification): servicio que se requiere de la red. Ej. Controlled load Service". Para Guaranteed Service" hay que especificar el lmite del retardo.
DiffServ vs IntServ Aislamiento del trfico: o DiffServ: por clase de trfico, agregado de varios flujos. o IntServ: por flujo, Ambito de QoS: o DiffServ: dentro del dominio o IntServ: entre origen y destino
Complejidad en la configuracijn: o DiffServ: configuracin realizada a largo plazo para cada categora, de forma esttica. o IntServ: configuracin realizada por flujo, en el momento en el que se necesita, de forma dinmica. Existen mensajes de sealizacin entre los rotures.
Escalabilidad: o DiffServ: en los rotures frontera se mantiene informacin para cada flujo o agregados de flujos, en los rotures del ncleo se mantiene informacin por cada clase. o IntServ: cada router mantiene informacin de estado por cada flujo.