Universidad de Mendoza

Transcripción

1 Universidad de Mendoza Facultad de Ingeniería Tesis de Maestría en Teleinformática Controlador de Ancho de Banda Ing. Diego Fernando Navarro Directores de Tesis: Magister Ing. Hugo Etchegoyen Ing. Osvaldo Rosso Mendoza, Noviembre de 2005

2 Agradecimientos Quiero agradecerle especialmente a Claudia mi esposa por su continuo aliento, comprensión, compañía y amor. A mi Familia, en especial a mis padres Raúl y Kitty por haberme educado y dado siempre todo para llegar a realizar mis metas. A Jjo por su compañerismo, humildad y entrega en todos los proyectos que hemos compartido. A Alfredo, Carlos y Salvador por confiar en mí, en mi trabajo y ayudar a desarrollarme como alumno, docente y persona. A Silice S.A. y a todo el grupo humano que lo compone por permitir y ayudar a que este trabajo se desarrolle y divulgue. A la empresa ITC S.A. por contribuir con su requerimiento a la construcción de este proyecto y en particular a Sergio Lorenzo por su paciencia y aporte a la estabilidad del desarrollo aquí expuesto. 2/124

3 Índice de contenido 1. Resumen Introducción La Internet Hoy Simplicidad de Estado Equidad Aplicaciones de próxima generación Componentes de QoS Una jerarquía de Redes Comportamiento predecible por salto Congestión transitoria, latencia, jitter y pérdida Clasificación, Encolado y Scheduling Comportamiento predecible borde a borde Modelos Extremo y Núcleo Modelado y Vigilancia Marcado y Reordenamiento Ruteo Borde a Borde El ruteo basado en QoS Señalización Políticas, autenticación y facturación Un router genérico Modelos de Red borde a borde Evolución de QoS y modelos extremo a extremo Modelos de QoS IntServ DiffServ MPLS Conmutación multiprotocolo por etiqueta Control de Tráfico en Linux Introducción Terminología Elementos del Control de Tráfico Disciplinas de cola simples, sin clases pfifo_fast /124

4 Token Bucket Filter Stochastic Fairness Queueing ESFQ, Extended Stochastic Fair Queuing RED (Random Early Detection) Disciplinas de colas classfull DSMARK HTB (Hierarchical Token Bucket) [HTBLUG] Compartiendo el enlace Jerarquía de compartición Velocidad Techo Ráfagas Priorizando la compartición del ancho de banda Implementación Introducción Arquitectura general Funcionamiento y detalle de componentes de la Arquitectura Aspectos Importantes del Diseño Implementación de la Arquitectura Daemon (sheiper-server) Interfaz de Administración Web Funcionalidades Login/Logout Gestión de Tráfico Clientes Redes Servicios Eventos Backup Parámetros Usuarios Controlador Casos de Aplicación ITC S.A /124

5 Universidad de Mendoza Conclusiones /124

6 1. Resumen En la actualidad la gran mayoría de las organizaciones posee algún tipo de enlace a Internet. Ese enlace es provisto por un ISP (Internet Service Provider Proveedor de Servicios de Internet) que presta el servicio en base a un abono por algún nivel de servicio pautado con el cliente (generalmente asociado a una cantidad de ancho de banda). En la organización seguramente el enlace en poco tiempo se encuentre saturado y muchos usuarios estén descontentos, aún cuando la capacidad del enlace sea la adecuada, debido a que algunos usuarios monopolizan el uso del enlace. Probablemente el ISP llegue al cliente con alguna tecnología de última milla que supera en capacidad al ancho de banda contratado por el cliente. Si el cliente tiene acceso a Internet a la velocidad de la última milla terminará recibiendo mucho más de lo que ha contratado, seguramente a expensas de que otro cliente perciba una degradación en el servicio contratado. Ambos problemas son similares solo que se encuentran en puntos distintos de la cadena de conectividad. Tanto la organización como el ISP requieren de una herramienta que permita realizar una asignación adecuada del ancho de banda seguramente por debajo de la velocidad de la tecnología física de red. Esta herramienta puede ser un hardware específico, de ser así se requerirá de un dispositivo por cada cliente a controlar. O como alternativa se puede utilizar algún software que realice la asignación adecuada. Este trabajo trata específicamente sobre el problema antes planteado y presenta un software que ha sido desarrollado y corre sobre herramientas de software libre. El software implementa un Controlador de Ancho de Banda que a través del uso de algoritmos ampliamente difundidos realiza una distribución justa del ancho de banda disponible y permite asignar a clientes conectados a él servicios específicos (de downstream y upstream) con un ancho de banda mínimo garantizado y un máximo configurable. Durante el trayecto del trabajo se desarrollará en detalle la problemática, los modelos, estándares y las soluciones de lo que en la actualidad se conoce 6/124

7 como QoS (Quality Of Service) sobre redes IP de mejor esfuerzo. En particular se detallarán las herramientas que posee el sistema operativo GNU/Linux para implementar QoS y al final se presentará el desarrollo completo del controlador de ancho de banda. El software aquí presentado es un producto existente de la empresa en la que trabajo denominado Sheiper, esta tesis se ha elaborado en base al mismo, el cual fue desarrollado en forma conjunta con el Ing. Juan José Ciarlante. Originalmente se desarrolló como una solución a los requerimientos planteados por un ISP de la provincia de Mendoza, ITC SA, que brinda servicios de acceso a Internet y se puso en funcionamiento a finales del año 2003 cuando la empresa poseía un enlace a Internet de 5 Mbit. En la actualidad la empresa sigue utilizando Sheiper como su software de control de ancho de banda y posee tres controladores montados cada uno sobre un enlace a Internet de 22 Mbits c/u. A parte de la empresa ITC, el controlador se encuentra en funcionamiento en otro ISP de la provincia de San Juan desde finales de 2004 y en la Universidad de Mendoza desde comienzos de 2004, entre otros. A partir de la presentación de este trabajo el software será contribuido a la comunidad de software libre y liberado bajo licencia GNU/GPL disponible en 7/124

8 2. Introducción El concepto subyacente en este trabajo son la problemática, las motivaciones y las necesidades actuales que llevan a tener que implementar un control de ancho de banda ya sea en organismos o en empresas proveedoras de servicios de comunicaciones. Como marco referencial del presente trabajo se desarrollará la problemática de la Red IP en perspectiva a la provisión de QoS, conjuntamente con los mecanismos y soluciones para este tipo de nivel de servicio sobre tecnología de redes IP. Utilizando los conceptos y estándares actuales se desarrollará un controlador de ancho de banda (de borde) que permita definir "curvas" de tráfico (en función del tiempo) a las que deberían ajustarse los flujos de datos. Entre los objetivos del presente trabajo se encuentran los siguientes: Desarrollar la problemática y los mecanismos existentes para poder modelar un servicio con QoS sobre una red de Mejor Esfuerzo como son las redes IP. Presentar el estado del arte de los algoritmos y mecanismos actuales disponibles para el control de ancho de banda sobre enlaces de datos en Linux. Integrar y desarrollar software de administración para implementar un controlador de ancho de banda utilizando Sistema Operativo Linux y herramientas de Software Libre. 8/124

9 3. La Internet Hoy El siguiente capítulo ha sido realizado tomando textos de [QOSIPNW] Antes de embarcarnos en una investigación de QoS (Quality of Service-Calidad de Servicio) de la Internet, es necesario realizar un repaso sobre el estado del networking sobre IP (Internet Protocol) y las aplicaciones que están guiando su evolución. Uno de los axiomas fundamentales del networking de IP es que la red tiene que ser los más simple que sea posible proveyendo el conjunto mínimo de funciones que permita que los bordes inteligentes puedan comunicarse. Esta filosofía es un poco contraria a la de los proveedores de telecomunicaciones tradicionales, donde sus redes son inteligentes de manera tal que los dispositivos utilizados por los usuarios finales, sean extremadamente simples (por ejemplo el teléfono). La proliferación de la plataforma PC, utilizada como dispositivo final inteligente, ha sido una de las razones más importante del éxito de Internet en la década de los 90 (en contraste con todo el esfuerzo de la industria tradicional de telecomunicaciones para desarrollar e introducir sus propios servicios de red digitales). La función mínima de la simple red IP era la conectividad esto es, la entrega de paquetes de datos desde una fuente a un destino en un período de tiempo razonable si es que existía un camino entre ambos puntos. La definición de período de tiempo razonable podía variar entre milisegundos o segundos, y en última instancia no había garantía que todos los paquetes enviados puedan llegar al destino. De esta manera, todos asumían que los dispositivos de borde inteligentes y las aplicaciones que ellos soportaban, de alguna manera se las arreglarían. Este principio era, y es, la definición de una red que hace el mejor esfuerzo (Best Effort network). Hasta la red más simple requiere de cierto grado de inteligencia interna para poder encontrar los caminos adecuados entre una fuente y un destino en este caso los protocolos de ruteo de IP. Si bien es cierto que podemos pensar que los protocolos de ruteo IP pueden adaptarse dinámicamente frente a desastres naturales, guerras o cambios de configuraciones, hoy existe una fuerte demanda 9/124

10 para que las redes IP extiendan sus funcionalidades mínimas para incluir más que simple conectividad. Las aplicaciones que utilizan flujos de tiempo real o interactividad están imponíendole a la red necesidades de tiempos de respuestas rápidos y predecibles. Los clientes que utilizan redes IP están demandando garantías de ancho de banda. Las nuevas aplicaciones necesitan una red que provea lineas de tiempo y previsibilidad como características principales Simplicidad de Estado Dado que la definición de servicios es tan simple, una red IP elimina mucha de la complejidad interna asociada con las telecomunicaciones tradicionales. En redes tradicionales, la señalización establece información de estado a lo largo de todo el camino extremo a extremo para asegurar que los componentes internos de la red puedan reconocer y manejar de manera apropiada el tráfico de datos que será realizado. Con una red IP de mejor esfuerzo, no se requiere señalización de extremo a extremo los puntos finales simplemente se conectan a la red y comienzan a enviar paquetes. La filosofía de IP es desacoplar el borde inteligente de la red simple. Esta práctica significa minimizar la interacción entre cualquier punto final (endpoint) y el estado interno de la red. La señalización de usuario final(end user) y ponerle atención a las fluctuaciones del estado de la red, tradicionalmente han sido considerado como cosas malas en el mundo.ip En un nivel filosófico, este comportamiento debilita el desacoplamiento borde/red. En un nivel práctico, mantener información de estados consume memoria en cada ruteador (router), y cambiar la información de estado regularmente consume CPU en cada router. Los cambios regulares en la información de estado están generalmente asociados con comunicación de señalización extra entre los routers, consumiendo ancho de banda que de otra manera estaría disponible para cursar paquetes de usuarios Equidad La red simple tradicionalmente no ha incluido ningún mecanismo para asegurar que los recursos son compartidos de manera equitativa entre los puntos finales. 10/124

11 En efecto, la aplicación del principio extremo a extremo ha concluido en que TCP es la fuente principal de equidad dentro de la Internet actual. El algoritmo de control de flujo con ventanas de TCP se ajusta dinámicamente para asegurar que está utilizando tanto ancho de banda como le es posible antes de comenzar a perder paquetes. Cada conexión TCP interpreta la pérdida de paquetes como si hubiera congestión en algún lugar dentro de la red, y en respuesta baja la velocidad con la que transmite. Aún pensando que todos los puntos finales son independientes, existe una expectativa que si todos corren algoritmos de TCP de control de flujo similares, cada uno conseguirá una buena transmisión y la capacidad de la red será compartida de manera equitativa. No obstante, este enfoque tiene un talón de Aquiles importante deja la equidad de la red en manos de los extremos finales. Esto podría ser aceptable cuando una sola organización controla la red y el software que corren en cada punto final. Pero en el mundo real, cualquiera puede modificar el software corriendo en los puntos finales para crear un TCP más agresivo, o para apagar el control de flujo completamente. La Internet ha visto ya ejemplos de sistemas operativos populares con parches para este mismo fin. El efecto es que la persona que lo utiliza ve una performance excelente a expensa de los TCP's de otros que se están reservando de poder transmitir. Rápidamente, más personas desarrollan TCP's agresivos, o escriben sus aplicaciones para utilizar UDP en primer lugar (UDP no tiene control de flujo). Desde una buena perspectiva de negocios, no se puede dejar el control del uso de los recursos de la red en los puntos finales. Esta es una de las razones fundamentales por la cual los proveedores de servicios están buscando mecanismos basados en la red para controlar los flujos de tráficos extremo a extremo, independientemente de lo que cada extremo final quiera utilizar Aplicaciones de próxima generación Claramente las técnicas existentes no necesitarían cambiar si estuvieran cubriendo las demandas actuales. Los crecimientos en la capacitad de transportar paquetes en bruto pueden satisfacer los grandes volúmenes de tráfico de o Web. Pero existen nuevas aplicaciones que han capturado la imaginación del público. Han 11/124

12 aparecido servicios de tiempo real de video o audio y la gente quiere acceso a este tipo de aplicaciones pero de manera más estable. Servicios interactivos de telefonía IP necesitan delays bajos y predecibles. Y los proveedores comerciales de servicios están buscando la manera de compartir su infraestructura de routers IP a través de múltiples clientes, garantizando que el tráfico de ningún cliente afecte el servicio de los otros. Todos estos factores están conduciendo la demanda por una nueva red IP con un núcleo más inteligente que antes. 12/124

13 4. Componentes de QoS El siguiente capítulo ha sido realizado tomando textos de [QOSIPNW] Sin importar el tamaño o el alcance de una red IP, la calidad de servicio observada se construye de la concatenación de QoS borde a borde provista por cada dominio a través del cual pasa el tráfico. Finalmente, la calidad de servicio extremo a extremo depende de las características de QoS de cada salto individual en una ruta dada. Mucha de la imprevisibilidad, la pérdida de paquetes o el jitter (variación en la cantidad de latencia entre paquetes de datos recibidos) de los servicios IP se debe a la manera en la que los router del modelo mejor esfuerzo manejan las congestiones transitorias internas. Si un puerto en particular se vuelve el punto focal para dos o mas flujos de datos (streams) de tráfico entrante, un router de mejor esfuerzo simplemente utiliza un encolado primero que entra primero que sale (FIFO) sobre el enlace de salida. El encolado introduce latencia (latency) o demora (delay) y la potencial pérdida de paquetes si la cola se desborda. Cuando el patrón del tráfico es del tipo impulsivo o por ráfagas (bursts), la latencia inducida por el encolado varía de manera impredecible de paquete a paquete manifestándose ella misma como jitter en los flujos de tráficos afectados. Las redes IP (de empresas, acceso y backbone) están siendo utilizadas para llevar tráfico perteneciente a una creciente cantidad de clientes con requerimientos diversos, por ejemplo, Telefonía IP, VPN's, transferencia de datos masivas, y ecommerce de misión crítica. Cada cliente realiza requerimientos únicos en referencia a cierto nivel de servicio o previsibilidad, aún en presencia de congestiones transitorias debidas a otros tráficos que atraviesan la red. La demanda de una protección relativa o absoluta de otro tráfico en algún segmento de la red en particular se aplica tanto a redes LAN de alta velocidad, como a una red basada en enlaces T1 o E1 privados, acceso discado (dialups) o redes de acceso ISDN, o Redes Troncales (backbones) de alta capacidad tipo OC-48/STM16. Esta demanda conlleva a tres requerimientos técnicos: QoS por Salto: El elemento controlable mas pequeño dentro de la red es el nodo (router o switch) unido por dos o más enlaces. Estos nodos deben estar basados en una arquitectura que permita aplicar encolado 13/124

14 (queueing) y scheduling (scheduling) diferenciado en cada salto y ser capaz de utilizar las características de QoS de los enlaces inter nodos. Ruteo e ingeniería de tráfico: Cuando existen múltiples caminos dentro de la red, distribuir el tráfico entre todos esos caminos puede reducir la carga promedio y las ráfagas dentro de cada uno de esos caminos. Esta práctica mejora la calidad de servicio aparente de la red porque cada router se ve menos obligado a descartar o desestabilizar paquetes. Se requieren mecanismos para descubrir e imponer a veces el reenvío por el camino no mas corto. Señalización y aprovisionamiento: De nada sirve tener mecanismos de QoS o de reenvío por un camino que no es el mas corto si no se pueden gestionar. Una solución práctica requiere algún grado de distribución automática de parámetros de QoS o de restricciones de ingeniería de tráfico a todos los nodos en la red. Cuando un cliente cambia sus requerimientos de QoS es necesario poder distribuirlos Una jerarquía de Redes Cualquier red que tomemos en cuenta está construida de una jerarquía de componentes. Cualquier camino desde un punto a otro esta formado de una concatenación de caminos más cortos (saltos [hops]) al mismo nivel. Un camino a un nivel N se vuelve un salto en un camino de nivel N+1. Tomemos la capa IP como punto de referencia: esta hecha de routers actuando como puntos de conmutación para los paquetes IP y enlaces que mueven los paquetes IP entre los routers. Cada enlace es un único salto en IP, pero el enlace en si mismo puede estar hecho por un número de nodos y saltos a su nivel. El enlace puede ser una única Ethernet, un segmento de una Ethernet conmutada, un túnel IP, una conexión virtual de ATM. En el caso de una Ethernet conmutada, pueden existir uno o más conmutadores (switchs) ethernet entre los dos routers. Los túneles IP usan una sola red IP para actuar como un enlace para otra red IP ( o a veces la misma red cuando cierto tipo de tráfico es necesario esconderlo de algunas secciones de la red). Una conexión virtual ATM (VC - Virtual Channel: Un término genérico usado para describir el 14/124

15 transporte unidireccional de celdas ATM asociadas por un valor de identificador común único [DACOMCOM]) provee un servicio extremo a extremo entre los extremos del VC, pero en realidad este VC puede atravesar muchos conmutadores ATM en su camino. El QoS entre dos puntos depende de los routers y las características de QoS del enlace entre esos dos puntos. Claramente el transporte de paquetes entre router se construye con las características de QoS de cada enlace. Si la tecnología del enlace no provee QoS controlable, los routers pueden hacer muy poco para compensarlo porque dependen de cada enlace para proveer una conectividad predecible entre routers. Sin embargo, en presencia de tecnologías de enlaces con QoS, el comportamiento de los routers hace o rompe la disponibilidad de QoS a nivel IP. La estratificación es recursiva. Por ejemplo, las características de QoS de un VC ATM depende de cuan predecible son los enlaces entre los conmutadores ATM tanto como en los conmutadores mismos. Un VC ATM puede extenderse a lo largo de varios conmutadores ATM utilizando circuitos SDH o SONET para el transporte de celdas entre los conmutadores. Los circuitos SDH o SONET están hechos de varios saltos a través de varios anillos y multiplexores. Finalmente, los circuitos SONET o SDH pueden estar multiplexados sobre una misma fibra óptica con otros circuitos totalmente independientes usando diferentes longitudes de onda que utilizan multiplexación por división de longitud de onda (WDM), una tecnología de fibra óptica que permite simular múltiples fibras ópticas virtuales sobre el mismo segmento físico de fibra. La Internet agrega una complejidad adicional al modelo ya que muchos de los caminos extremo a extremo no se encuentra dentro de la misma red IP y muy probablemente se extiendan sobre múltiples redes IP independientemente administradas, cada uno con sus propias políticas y características de QoS. Cuando solo se espera el mejor esfuerzo no es necesario preocuparse por las redes intermediaras a lo largo del camino, ya que su política de routeo permite el reenvío de tráfico. Sin embargo, para soportar QoS extremo a extremo, es necesario saber más acerca del comportamiento dinámico de la red. No es necesario conocer como cada red cubre sus objetivos de QoS. Es suficiente con 15/124

16 caracterizar a cada red en términos de la latencia, jitter y probabilidad de pérdida de paquetes que puede ser impuesta al tráfico. Dado que la red de una persona es el enlace de otra, la noción de QoS extremo a extremo debe ser generalizada a QoS borde a borde. La QoS alcanzada desde un extremo a otro de la red se construye con la concatenación de redes con sus propias características de QoS borde a borde, y cada uno de los caminos dentro de cada red se construye con enlaces que pueden ser redes en si mismas, de nuevo caracterizadas con sus propias capacidades de QoS borde a borde. La habilidad de caracterizar el comportamiento de QoS borde a borde de una red depende de la habilidad de caracterizar y controlar el comportamiento de los enlaces y los nodos a nivel de red Comportamiento predecible por salto El objetivo en un ambiente con Qos es proveer un servicio de entrega predecible para cierto tipo o clases de tráfico independientemente de otro tráfico que este fluyendo a través de la red en cualquier momento. Una forma alternativa de este objetivo es pensar en una solución de red IP multiservicio donde el tráfico tradicional de ráfagas pueda compartir la misma infraestructura (routers, switches, y enlaces) con tráfico que posee requerimientos más estrictos de latencia, jitter, ancho de banda o pérdida de paquetes. Sin importar si uno se focaliza en redes de acceso, para empresas o de backbone (o alguna combinación de todas), el camino extremo a extremo que recorren los paquetes de un solo usuario está formado por una secuencia de routers y enlaces. Entonces, la atención debe ser puesta sobre el comportamiento del reenvío de paquetes dinámico de los routers. Un router tradicional se centra sobre donde debe reenviar los paquetes (realizando la decisión de reenvío sobre la dirección de destino de cada paquete y la tabla de ruteo), los routers de redes IP con QoS deben poseer un control de cuando deben enviar los paquetes. Es necesario ver más de cerca aquellos elementos que afectan cuando los paquetes son reenviados Congestión transitoria, latencia, jitter y pérdida Cada router es el punto controlable más pequeño donde convergen o divergen decenas, centenas y miles flujos de paquetes no relacionados. En la mayoría de 16/124

17 las redes de datos, el tráfico arriba en ráfagas que fluctúan. En algunas ocasiones, el arribo de ráfagas simultaneas sobre múltiples enlaces, los cuales están destinados al mismo enlace de salida (que tiene una capacidad finita), pone al router en una situación donde tiene más paquetes de los que inmediatamente puede enviar. Por ejemplo, el tráfico convergente de múltiples enlaces Ethernet de 100Mbit/s puede exceder muy fácilmente la capacidad de un enlace WAN OC-3/STM-1 de 155Mbits. Para poder lidiar con estas situaciones, todos los routers poseen colas internas (buffers) dentro de las cuales el router almacena los paquetes que se exceden hasta que puedan ser enviados. Bajo estas circunstancias los paquetes que intentan atravesar el router experimentan demoras adicionales. Este router se dice que esta sufriendo una congestión transitoria. La demora experimentada por un paquete de extremo a extremo es una combinación de las demoras de transmisión de cada enlace y las demoras experimentadas en el procesamiento por cada router. La demora que contribuyen tecnologías de enlaces como SONET o SDH, lineas punto a punto, o circuitos ATM virtuales, son muy predecibles dado su diseño. Sin embargo, la demora que contribuye cada router por el almacenamiento en sus colas por situaciones de congestión, no es predecible. Fluctúa con los cambios en los patrones de congestión, generalmente variando de un momento a otro aún para los paquetes que tienen el mismo destino. Esta componente fluctuante de la demora extremo a extremo generalmente se conoce como jitter. Otro tema es la pérdida de paquetes. Dado que los routers tienen una capacidad de almacenamiento finita, si se lo somete a una congestión sostenida esta puede llevar que se saturen las colas. Cuando llegan paquetes, y la capacidad de almacenamiento se encuentra agotada, estos deben ser descartados hasta que haya espacio disponible en las colas. Claramente, tenemos un problema. Un router tradicional tiene solo una sola cola para cada punto de congestión y no existen mecanismos para aislar diferentes clases o tipos de tráfico de los efectos del tráfico que está atravesando el router. 17/124

18 Las fluctuaciones de los tráficos no relacionados que pasan a través de una cola compartida en cada punto de congestión interna es probable que tenga una gran influencia sobre la latencia, jitter y pérdida de paquetes de cada flujo. Algunos tipos de tráfico (por ejemplo, conexiones TCP que transportan s) toleran mejor las demoras que las pérdidas de paquetes, lo cual sugiere que tener grandes colas es lo ideal. Sin embargo, otros tipos de tráficos por ejemplo, en una comunicación UDP transportando video o audio streaming es preferible que los paquetes sean descartados a que sean mantenidos demasiado tiempo en la red, lo cual sugiere que colas pequeñas serían mejores. Consideremos un escenario donde los paquetes llegan por cada interfaz de entrada del router a una velocidad máxima de Y1 hasta Yn paquetes por segundos. El enlace saliente extrae paquetes de la cola a X paquetes por segundo. Si tomamos la velocidad total de entrada como Y, la suma de (Y1 + Y Yn). Cuando Y es menor que X, los paquetes no tienen que esperar en la cola. Sin embargo, es más que probable que Y puede dar ráfagas por encima de X, en este caso la cola ve un crecimiento en su tamaño. El número de paquetes (P) en la cola después de un intervalo (T) es expresado como P=T x (Y X). Un paquete que llega en un tiempo T y encuentra que la cola esta parcialmente llena experiencia una demora adicional de X x P segundos (porque el paquete debe esperar que la cola drene a X paquetes por segundos). Si un paquete llega cuando la cola está llena (P = L, el espacio disponible en la cola), el paquete no tiene donde ir y es tirado. El jitter viene del hecho que los componentes de Y son de ráfagas y no correlacionados. La descripción anterior también se mantiene si se expresa la velocidad de entrada y salida en bits por segundo y el espacio disponible en la cola en bits (o bytes). Si los paquetes tienen un tamaño fijo, existe una relación simple entre las dos formas de expresión. Sin embargo, en ambientes IP típicos los paquetes no son de tamaño fijo, agregando mas variaciones a la relación entre la velocidad de salida, el número de paquetes demorados y la demora experimentada por esos paquetes. La demora también puede ser una función de la tecnología de la red subyacente por ejemplo, el esquema de BackOff de ethernet (procedimiento de retroceso exponencial binario mediante el cual el emisor espera un lapso aleatorio para transmitir cuando hay una colisión, después de la primera colisión esperará el doble de tiempo, después de la segunda 4 veces ese 18/124

19 tiempo). Sin embargo, el backoff en Ethernet se presenta como una imprevisibilidad del enlace Clasificación, Encolado y Scheduling Entonces que se necesita para mejorar. Las características de demora, jitter, y pérdida de paquetes de una red IP dada, en ultima instancia se resumen a las características de QoS de los enlaces y la dinámica de la utilización y administración de las colas dentro de cada router. Si la carga de la red supera la velocidad del servicio, una sola cola en cada punto de congestión no es suficiente. En lugar de esto, se necesita una cola para cada clase de tráfico identificable y así a esta cola poder aplicarle características independientes de demora, jitter y pérdida de paquetes. Cada una de estas colas debe tener su propia política para descartar paquetes (por ejemplo diferentes transferencias por encima de las cuales los paquetes son descartados aleatoria o determinísticamente). Por supuesto, tener múltiples colas por cada interfaz de salida es inútil si no se posee un mecanismo para asignar los paquetes a la cola correcta. Se requiere un método de clasificación por encima del tradicional. Finalmente, las colas deben compartir la capacidad finita que posee el enlace de salida. Este requerimiento implica un mecanismo adicional de scheduling (poder fijar un orden y tiempo de salida a los paquetes) para intercalar paquetes de cada cola, y así, controlar el acceso al enlace de salida de manera controlable y predecible. Para los contenidos de este trabajo, los requerimientos antes planteados pueden resumirse en una declaración: Las redes con QoS requieren de routers que puedan Clasificar, Encolar y Temporizar (Classify, Queue, Schedule) cualquier tipo de tráfico que sea necesario. A todos los routers que cumplan estos requerimientos los llamaremos "basados en arquitecturas CQS" o simplemente "routers CQS" Comportamiento predecible borde a borde Como se dijo antes, un servicio extremo a extremo se construye con la concatenación y estratificación de comportamientos borde a borde y por salto. Los operadores de Redes, centrados en las capacidades borde a borde de sus redes, tienen un rango de posibilidades para mezclar y hacer trabajar en conjunto comportamientos por salto. A través de los años han emergido varios esquemas 19/124

20 de solución, cada uno reflejando conjuntos diferentes de presunciones y compromisos en lo que respecta a las capacidades de CQS y de ruteo de los routers dentro de la red. La primera y más importante observación es que los diseñadores de la red se enfrentan a una disyuntiva entre la cantidad de clases de tráfico que pueden ser transportadas por sus redes y el número de clases de tráfico que las arquitecturas de CQS de sus routers pueden manejar. Algunas soluciones se basan en arquitecturas distribuidas de borde núcleo, donde el núcleo está compuesto por routers rápidos con limitadas capacidades de CQS y los bordes son más lentos pero con avanzadas capacidades de CQS. Una segunda observación es que los algoritmos de ruteo existentes (por camino más corto) actualmente en la Internet no son los más óptimos o los necesarios para diferentes clases de tráfico que atraviesan una malla arbitraria de routers y enlaces. Una sola métrica puede no ser la apropiada para todo el tráfico que atraviesa una sección particular de la red. Adicionalmente, el paradigma de reenvío basado en el destino hace muy dificultoso poder forzar que algún subconjunto del tráfico sea encaminado por un camino alternativo que no sea el más corto Modelos Extremo y Núcleo Ya sea en hardware o en software, el diseño de una buena arquitectura de CQS no es generalmente algo trivial. En muchas implementaciones de software, la poca disponibilidad de procesamiento, hace muy difícil el poder introducir clasificación, manejo de colas y temporización sin afectar la performance global del dispositivo o caja. Las implementaciones de hardware han empezado a ser de uso común y hasta hace poco el diseño de una implementación de CQS para IP cerrada en un hardware era demasiado riesgosa comercialmente. El modelo borde y núcleo permite poner routers de núcleo por hardware (preparados para mayor velocidad) dejando el procesamiento complejo a los routers basados en software (más lentos) en los extremos. Los routers de borde pueden estar preparados para clasificar y encolar independientemente cientos o miles de colas de tráfico, mientras que para los routers de núcleo se asume que tendrán un manejo limitado 20/124

21 de colas. Un número de colas limitadas en el núcleo conlleva a un nuevo requerimiento para los routers de borde y es que estos deben ser capaces de suavizar las ráfagas del tráfico que está entrando a la red. En las discusiones anteriores con respecto al control de QoS por salto, las clases de tráfico individuales tenían permitido ser completamente impredecibles, asumiendo que sería posible aislarlas adecuadamente y temporizarlas en cada punto de congestión. En el modelo borde inteligente/núcleo bobo es requisito que el aislamiento sea hecho en los bordes, no se hace en el núcleo. Múltiples clases de tráfico pueden encontrarse sumadas dentro de la misma cola compartida dentro de un router de núcleo. El potencial de interferencia mutua es alto a menos que la red imponga algún nivel de previsibilidad antes que el tráfico llegue a los routers de núcleo. La solución es que los routers de los bordes se encarguen de manipular las características temporales de cada clase de tráfico antes que entren al núcleo. El modelo de Servicios Diferenciados (Differentiated Services- DiffServ) de la IETF (Internet Engineering Task Force Grupo de Trabajo en Ingeniería de Internet) es un ejemplo Modelado y Vigilancia El objetivo primario de una arquitectura CQS es el de proteger el tráfico en cada cola de las ráfagas del tráfico en otras. En un esquema por salto, está claro que, para dar el apropiado aislamiento todo el tráfico sensible a QoS, un scheduler necesita garantizar solamente un cierto intervalo para el peor caso ( o un ancho de banda mínimo). Si hay capacidad ociosa disponible, es de esperar que el comportamiento de un buen scheduler sea el de dar esa capacidad a las colas que tienen paquetes esperando por ser enviados. Sin embargo, desde una perspectiva completa de la red está práctica no es siempre deseable. Simplemente vaciando una cola lo más rápido que la velocidad de la línea de salida permite (en ausencia de tráfico de otras colas) puede incrementar las ráfagas percibidas por los routers que se encuentran más abajo en el camino. Como resultado, se puede presentar un problema serio si los routers que se encuentran más abajo en el camino no poseen la misma granularidad que el router local. Adicionalmente, los proveedores de 21/124

22 servicio pueden querer limitar la tasa de transferencia máxima a la que un cliente puede enviar paquetes a través de la red. Si un cliente frecuentemente tiene más ancho de banda que su mínimo garantizado (quizás porque la red es nueva o esta subutilizada) surge una cuestión de percepción: El cliente comienza a asociar la performance típica con lo que esta pagando. Si la capacidad de repuesto siempre se achica, el cliente recibirá una performance de borde a borde cercana al mínimo garantizado. Sin embargo, el cliente simplemente percibe que el servicio se ha degradado y se queja. Administrar las expectativas de los clientes es una parte importante del negocio, y en este caso pueden usarse herramientas tecnológicas para poner un tope de manera preferencial. Introduciendo un límite superior al ancho de banda máximo (o un intervalo mínimo entre paquetes) disponible para una clase de tráfico se denomina modelado de tráfico (traffic shaping). Un scheduler con modelado (shapping scheduler) se configura para proveer un intervalo mínimo de servicio (el tiempo entre que se quitan paquetes de la misma cola) y un intervalo máximo de servicio (para garantizar un límite de demora o ancho de banda mínimo). Los paquetes que llegan en un intervalo entre paquetes mas corto que el permitido por el scheduler son encolados hasta su transmisión, suavizando la ráfaga original. Una manera simple de un modelador scheduler (shaping scheduler) se lo conoce generalmente como balde agujereado [leaky bucket], porque no importa que tan rápido lleguen los paquetes solo pueden escapar del balde a una tasa fija). El modelado no es una función simple de introducir dentro de un router de mejor esfuerzo porque esta función parte de la base que existe una arquitectura de CQS apropiada. Aunque no muy elegante, una solución alternativa es la de introducir un comportamiento de descarte de paquetes que sea sensible a las ráfagas de tráfico excedente de una clase. Cuando muchos paquetes lleguen en un intervalo muy corto, los paquetes simplemente son descartados. Este proceso se conoce como vigilancia [policing]. La vigilancia puede ser implementada sin colas ni scheduleres, aunque típicamente necesita alguna forma de clasificación para diferenciar las diferentes reglas de vigilancia impuestas a cada clase de tráfico. En su forma más simple, cada clase de tráfico posee un contador asociado. El contador es incrementado regularmente cada T segundos y decrementado cuando 22/124

23 un paquete (que pertenece a la clase) es reenviado. Si llega un paquete para ser transmitido cuando el contador está en cero, el paquete es descartado en ese lugar. Cuando no se están transmitiendo paquetes, el contador incrementa hasta un límite fijo L. El efecto neto es que cuando llegue un flujo de paquetes con un intervalo promedio entre paquetes de T segundos (o mayor) pasen sin ser tocados. Sin embargo, si llega una ráfaga de más de L paquetes en menos de T segundos, el contador llega a cero y los paquetes adicionales son descartados. El valor de L afecta la tolerancia a las ráfagas de la función de vigilancia, y T configura la tasa por la cual por debajo el tráfico esta asegurado. Esta práctica es una forma severa, aunque efectiva, de modificar las ráfagas de tráfico desde el router con vigilancia hacia adelante. La utilidad de la vigilancia se basa en asumir que la mayoría del tráfico de ráfaga se origina en aplicaciones que están utilizando protocolos adaptativos extremo a extremo, como TCP. La pérdida de paquetes se asume como un indicador de congestión transitoria, y TCP reacciona bajando la tasa a la que inyecta paquetes dentro de la red. La vigilancia permite que los operadores de red falsifiquen congestiones transitorias para una clase de tráfico particular antes que esta realmente ocurra. Aún si la clase de tráfico no está utilizando un protocolo de transporte adaptativo extremo a extremo, la vigilancia protege al resto de la red ya que continua descartando los paquetes que exceden los parámetros permitidos. El modelado y la vigilancia son dos herramientas extremadamente útiles para los diseñadores de red que se enfrentan con tener que balancear el numero de clases de tráfico que mueven sus redes y el número de clases de tráfico que sus arquitecturas de CQS pueden manejar. Básicamente el asunto es que se puede permitir que las clases de tráfico sean impredecibles solo si se pueden aislar adecuadamente en cada potencial punto de congestión. Si no es posible este aislamiento, se debe imponer cierto nivel de previsibilidad antes del potencial punto de congestión. En el modelo borde inteligente/núcleo bobo, la solución es que cada router de borde de manera preventiva modele y/o vigile las clases de tráfico individuales antes que estas entren en el núcleo, con el objetivo de imponer un orden general, suavidad, y 23/124

24 previsibilidad dentro de cada clase de tráfico (y, por lo tanto, la suma de todas esas clases de tráfico). El modelado también puede ser muy útil en la salida de una red en aquellas situaciones donde la vigilancia de la próxima red puede ser más nociva Marcado y Reordenamiento Si bien el modelado puede ser una solución sofisticada para suavizar el tráfico de ráfagas, la vigilancia simple es un instrumento severo. Se han introducido algunas variaciones para suavizar el efecto de la vigilancia en los routers de borde. Un nodo que este haciendo vigilancia puede elegir solamente marcar los paquetes (en vez de descartarlos inmediatamente) si exceden un límite de ráfaga. Los routers que se encuentran mas adelante en el camino del paquete tratan a estos con menor prioridad que los que se encuentran sin marcas. Si ocurre una congestión transitoria que comienza a llenar las colas de alguno de los routers que se encuentran en el camino, estos routers pueden comenzar a descartar los paquetes marcados antes de comenzar a tirar los paquetes que no tienen marcas. Se pueden aplicar refinamientos a este comportamiento de manera que el nodo original que esta haciendo vigilancia puede implementar un conjunto de límites de ráfagas, si un paquete excede el límite inferior de ráfagas, los paquetes subsiguientes comienzan a ser marcados y se los transmite, si la ráfaga continua y excede el límite superior los paquetes son descartados. Alternativamente, el nodo que esta haciendo vigilancia puede implementar múltiples niveles de tasas de arribo promedio, una tasa baja para la cual los paquetes son reenviados sin marcar, una tasa intermedia para la cual los paquetes son marcados y reenviados y una tasa alta para la cual los paquetes por encima de esta tasa directamente son descartados. El impacto en la red de núcleo es mas suave que el que hubiera tenido un mecanismo de vigilancia simple, porque muchos de los paquetes que estaban en una ráfaga serán marcados en vez de descartarlos. La ventaja de este esquema es que, frente a la ausencia de congestión en otro punto de la red, este tráfico en particular puede utilizar más el ancho de banda disponible. Pueden inventarse muchos algoritmos para proveer múltiples niveles de marcado y para cálculos de 24/124

25 tasas de transferencia. Sin embargo, los diseñadores de red que planeen utilizar marcado de tráfico en los bordes deben seleccionar correctamente los routers de núcleo. El punto central de preocupación es el reordenamiento de los paquetes marcados relativo a los paquetes no marcados dentro de una misma clase de tráfico. Esta situación puede ocurrir si el router de núcleo utiliza dos colas separadas para diferenciar entre los paquetes marcados y los paquetes no marcados de una misma clase de tráfico. Dado que los paquetes marcados son de baja prioridad, una implementación puede elegir reflejar esta prioridad relativa asignando más ancho de banda del scheduler a la cola que almacena los paquetes no marcados. Como consecuencia un paquete marcado que llegue antes que un paquete no marcado (pertenecientes a la misma clase de tráfico) puede que sea programado para ser enviado después que un paquete no marcado (o viceversa). Asumiendo que el paquete marcado puede completar su camino hasta el destino, la aplicación en el destino percibe que el tráfico contiene paquetes fuera de orden. Dado que la especificación de IP no preve que los paquetes sean reordenados por la red, esta práctica debería evitarse porque la mayoría de los protocolos extremo a extremo no manejan esta situación de manera eficiente. En redes donde el marcado tiene como objetivo incrementar la probabilidad de descarte de los paquetes, la solución no es muy difícil. Inicialmente se deja que los routers de núcleo ignoren las marcas de la vigilancia cuando los paquetes son clasificados en las colas, asegurando que todos los paquetes en una clase de tráfico sean colocados en una cola independientemente de su prioridad de descarte. Luego se modifica el nivel de descarte de paquetes para esa cola en función de si el paquete esta marcado o no. El algoritmo de descarte de paquetes del router de núcleo, así, se activa de manera más agresiva para los paquetes marcados y de esta manera se logra el comportamiento deseado de borde a borde Ruteo Borde a Borde No hay ninguna restricción en como se conectan los enlaces y los routers para formar una red IP. Los mecanismos de Internet de ruteo por camino mas corto se basan en asumir que la topología de la red rara vez se mantiene estática y debe ser monitorizada dinámicamente. En cualquier red realista, cada router puede tener 25/124

26 más de una interfaz de salida por la cual puede enviar un paquete, el rol de los protocolos de ruteo es establecer una sola interfaz por la cual se debería enviar el paquete. Para poder hacer que los cálculos sean realizables, la elección de la interfaz apropiada se realiza con algoritmos controlados por una sola métrica para determinar el camino más corto. Sin embargo, han surgido dos inconvenientes importantes cuando se trata de utilizar estos mismos mecanismos para soportar QoS. Primero está el argumento de que una sola métrica puede no ser apropiada para todo el tráfico que atraviesa una sección particular de la red. Segundo, el paradigma de reenvío basado en el destino hace difícil forzar que un subconjunto del tráfico sea encaminado por un camino distinto al más corto El ruteo basado en QoS Los protocolos de ruteo basado en QoS intentan tomar múltiples métricas para construir las tablas de reenvío. Estos protocolos han sido estudiados por años y generalmente se han desarrollado tomando como condición inicial que la red está construida en base a routers IP de mejor esfuerzo. Comenzando con esta condición inicial, el ruteo basado en una sola métrica presenta una serie de limitaciones cuando se lo trata de utilizar para cubrir las demandas de QoS en un ambiente multiservicio. Se puede considerar una métrica como un tipo de costo donde cada enlace (hop) tiene un costo asociado. El protocolo de ruteo intenta buscar caminos que tengan el menor costo hacia todos los destinos posibles. Sin embargo, estos costos no pueden representar los intereses y necesidades de todos los tipos de tráfico. Podría representar la latencia de un enlace, su ancho de banda disponible, su probabilidad de pérdida de paquetes, o quizás el gasto de enviar paquetes sobre ese enlace? Seleccione uno. Terminará encontrando que para algún tráfico la selección es apropiada mientras que para otros es un desperdicio de recursos. Por ejemplo, considere una red donde la latencia es la métrica. Seguramente el camino más corto ahora satisface las necesidades de las aplicaciones que tienen requerimientos de tiempo real muy ajustados. Pero esas aplicaciones no están solas. La red generalmente está siendo utilizada por aplicaciones 26/124

27 tradicionalmente de ráfagas que no se preocupan por la latencia. El tráfico de estas (otras) aplicaciones también sigue el camino más corto por la latencia mínima, sumándose a la carga que tienen los routers de mejor esfuerzo a lo largo del camino. Un efecto colateral desafortunado es que el tráfico de ráfagas consume el mismo espacio de colas que esta destinado al tráfico de tiempo real, incrementando el jitter y la latencia promedio experimentada por el tráfico que atraviesa los routers. Este enfoque también afecta la precisión de los costos de latencia que los protocolos de ruteo usan para determinar el camino más corto. El ruteo basado en QoS crea árboles de múltiples caminos mas cortos, cubriendo la topología actual de routers y enlaces con cada árbol utilizando diferentes combinaciones de parámetros como métricas de enlaces. El objetivo es minimizar la coexistencia innecesaria de tráficos con diferentes requerimientos de QoS dentro de los mismos routers. Los paquetes que tienen requerimientos de latencia son reenviados utilizando el árbol que tiene la latencia como métrica. Los paquetes que no tienen requerimientos de tiempo real pueden tener un árbol diferente (construido con una métrica para minimizar el costo financiero de ese camino). Existen varias consideraciones con la implementación del ruteo basado en QoS: Cada router necesita tener múltiples tablas de ruteo (o algo funcionalmente equivalente) sobre las cuales realizar la búsqueda del próximo destino de cada paquete, una para cada tipo de árbol de camino mas corto. Se utilizan campos adicionales en la cabecera del paquete para seleccionar uno de los posibles próximos saltos asociados con la dirección de destino del paquete. Esta situación complica el diseño del motor de búsqueda del próximo salto. Esto genera un incremento en el uso de procesador (CPU) del router, ya que debe soportar una instancia de cada protocolo para cada árbol de camino mas corto. Este requerimiento genera un incremento en el tiempo que le toma converger a los protocolos de ruteo (de cada router en una red) cuando se presenta una transición en la red. El tiempo de convergencia se incrementa si se requiere que el protocolo de ruteo calcule los árboles en base a múltiples métricas simultáneamente. Métricas tales como la latencia o el ancho de banda disponible son altamente 27/124

28 dependientes del tráfico que fluye en cada instante por la red. Un árbol de camino más corto que se construye con valores de latencia configurados de manera estática se vuelve completamente obsoleto cuando el tráfico comienza a atravesar la red. La alternativa, de actualizar el costo de cada enlace con mediciones de tiempo real, representa una pesadilla de teoría de control cada actualización del costo puede resultar en recalcular todos los árboles de camino más corto asociados, lo cual lleva a una sobrecarga de procesamiento continua sobre todos los routers. Resulta interesante ver que el desarrollo de routers con arquitectura de CQS de alguna manera reduce la necesidad de ruteo basado en QoS. Por ejemplo, considerando el ejemplo donde la métrica de costeo era la latencia. Ahora consideremos que cada router tiene al menos dos colas por interfaz de salida, una para el tráfico que es sensible a la latencia y otra para el resto del tráfico. Todo el tráfico es ruteado por caminos de la más baja latencia. Asumiendo que los routers clasifican de manera correcta el tráfico en las dos colas, el servicio que tiene el tráfico sensible a la latencia es independiente de las ráfagas que tiene todo el resto del tráfico. Así, cualquier protocolo de ruteo convencional de una sola métrica, cuando se utiliza con routers de arquitectura CQS, pueden soportar múltiples niveles diferentes de servicio. La condición principal de esto es que exista suficiente capacidad a lo largo del único árbol para proveer un servicio adecuado a todos los participantes Señalización Asumiendo que es posible proveer encolado diferencial y scheduling en cada salto de la red y que se pudiera controlar de manera apropiada la capa de enlace, resulta necesario tener los mecanismos para poder establecer y modificar el comportamiento de la red. Este tema requiere de la coordinación de los comportamientos a lo largo de cada camino. Este proceso se conoce generalmente como señalización el hecho de informarle a cada salto a lo largo de un camino (o caminos) como reconocer el tráfico para el 28/124