Provisión Incremental de QoS Basada en Network Brokers

Transcripción

1 Provisión Incremental de QoS Basada en Network Brokers Alfonso Gazo Cervero, José Luis González Sánchez Área de Ingeniería Telemática. Departamento de Informática. Universidad de Extremadura Escuela Politécnica de Cáceres. Av/ Universidad s/n Cáceres Teléfono: Fax: {agazo,jlgs}@unex.es Resumen La provisión de garantías QoS obliga a que la red sea capaz de tener en cuenta los recursos disponibles, de realizar decisiones de control de admisión y acceso y de controlar el comportamiento de los flujos. Además las aplicaciones deben indicar a la red qué recursos requieren. Cuando esta provisión debe realizarse sobre una red no orientada a conexión como Internet, la no existencia de información de estado de flujo en los router dificulta la integración de mecanismos de control orientado a flujo. Si bien las propuestas realizadas hasta el momento para la provisión de garantías QoS sobre Internet difieren significativamente, comparten en la mayoría de los casos una característica común: requieren que todos los router de la red sean modificados para permitir la provisión de QoS extremo a extremo. Sin embargo, parece razonable considerar este requerimiento lo suficientemente elevado para que, en caso de asumirse, tan sólo pueda satisfacerse a largo plazo. En este trabajo proponemos una alternativa basada en Diff- Serv en la que tan sólo resulta necesaria la incorporación de mecanismos de provisión de QoS en un subconjunto de router de la red. De un modo más específico, nuestro modelo garantiza el cumplimiento de los requerimientos de QoS siempre que exista una ruta operativa en la que todos los router intermedios incorporen ciertos mecanismos para la provisión de QoS. En esta propuesta ubicamos en cada dominio de encaminamiento un agente responsable de la realización del control de acceso así como del gobierno de los parámetros relacionados con la provisión de QoS en los router de la red. 1. Introducción Desde la especificación de IntServ se ha intentado incorporar una arquitectura que permitiera ofrecer QoS sobre Internet. Es deseable que Internet se utilice como una infraestructura común para soportar tanto la comunicación en tiempo real como la que no es en tiempo real. Se podría construir una infraestructura totalmente nueva para los servicios en tiempo real, de forma paralela, dejando Internet tal y como está actualmente. Sin embargo, se perderían las ventajas significativas de la compartición estadística entre los tráficos en tiempo real y no tiempo real, además de convertirse en algo más complejo de construir y administrar que una infraestructura común.

2 2 A. Gazo, J.L. González-Sánchez Sin embargo, el tamaño actual de Internet provoca que la modificación de su arquitectura para poder ofrecer QoS esté lejos de ser una tarea sencilla. Cada AS tiene su propia configuración hardware y software sobre la que no siempre se puede actuar para incorporar extensiones a los protocolos soportados y/o configurados. Por diversos motivos, existirán organizaciones que, siendo responsables de uno o varios AS, decidan migrar su arquitectura hacia una arquitectura que pueda proporcionar QoS, mientras otras postpongan esta decisión. El hecho de que no se realice una implantación completa de la nueva arquitectura en Internet provoca que no se puedan ofrecer garantías estrictas relativas a la obtención de QoS, aunque sí se proporcionen garantías estadísticas bajo ciertas restricciones. Bajo el prisma de DiffServ, la situación no es necesariamente mejor, ya que aunque los requerimientos para la implantación de una arquitectura Diff- Serv en un AS parecen inferiores a los de la implantación de una arquitectura IntServ, no dejan de existir unos requisitos mínimos que muchos AS actualmente no alcanzan. Nuestra premisa de partida consiste en que el requisito de migrar completamente toda la arquitectura de Internet para poder ofrecer garantías de QoS a los usuarios resulta inaceptable. Las propuestas relacionadas con la arquitectura Internet2 QBone [1,2] todavía están lejos de llegar a los usuarios finales, que actualmente demandan de la red la obtención de QoS. Las aplicaciones se encuentran en este sentido por delante de los servicios que la red puede ofrecer. En este trabajo proponemos una alternativa basada en DiffServ en la que tan sólo resulta necesaria la incorporación de mecanismos de provisión de QoS en un subconjunto de router de la red. De un modo más específico, nuestro modelo garantiza el cumplimiento de los requerimientos de QoS siempre que exista una ruta operativa en la que todos los router intermedios incorporen ciertos mecanismos para la provisión de QoS. En esta propuesta ubicamos en cada dominio de encaminamiento un agente responsable de la realización del control de acceso así como del gobierno de los parámetros relacionados con la provisión de QoS en los router de la red. La arquitectura basada en un agente para proporcionar QoS mediante Diff- Serv no es nueva, ya que fue presentada en [3]. En ella, se denomina Bandwidth Broker (BB) al agente encargado de establecer en los router las políticas de control necesarias para la provisión de QoS. El BB establece en los router del borde del dominio las funciones de clasificación y planificación, y en los router del núcleo las funciones de planificación. Además también pue-

3 Provisión Incremental de QoS Basada en Network Brokers 3 de implementar funciones de control de acceso y puede coordinar y negociar automáticamente la provisión de QoS con BB de dominios adyacentes. En nuestra propuesta, extendemos la funcionalidad descrita para un BB, en los siguientes aspectos: a) mantenimiento de una topología QoS superpuesta a best-effort, b) captura y procesamiento de la información del IGP, c) tratamiento de estadísticas de tráfico obtenidas desde los ER para obtención de la matriz de tráfico y d) negociación de capacidades QoS con dominios adyacentes. De este modo, pasamos a denominar Network Broker (NB) al agente BB extendido con la nueva funcionalidad. 2. Una Topología QoS Superpuesta a Best-Effort El tráfico best-effort y el tráfico QoS coexisten en muchas de las redes en el mundo real. Teniendo en cuenta que una de las tareas del encaminamiento es maximizar la eficiencia de los recursos, para una red en la que coexistan ambos tipos de tráfico, esta eficiencia se mide mediante dos objetivos. Por un lado, maximizar el número de flujos QoS que pueden admitirse en una red. Esto es equivalente a minimizar el call-blocking ratio en caso de que se apliquen mecanismos de control de admisión. Por otro, optimizar tanto throughput como responsiveness del tráfico best-effort. Ambos objetivos pueden resultar contradictorios, ya que mientras que el primer objetivo tan sólo tiene en cuenta el tráfico QoS, el segundo objetivo tan sólo tiene en cuenta el tráfico best-effort. Por último, ambos tipos de tráfico pueden tener distribuciones muy diferentes. Si se realizan reservas de recursos para la provisión de QoS, el tráfico QoS no se verá afectado por el tráfico best-effort. Sin embargo, si se sobreestiman estas reservas, el tráfico best-effort verá reducido el troughput disponible. Por ejemplo, pueden existir enlaces con tráfico QoS bajo y tráfico best-effort alto. Para muchos algoritmos de encaminamiento QoSR, estos enlaces se consideran buenos candidatos para dirigir el tráfico QoS a través de ellos. Al aumentar el tráfico QoS sobre estos enlaces, el tráfico best-effort se ve inevitablemente afectado ya que los router congestionados a lo largo de esta ruta descartarán los paquetes del tráfico best-effort en beneficio del tráfico QoS. Para el caso de Internet, parece razonable que la implantación de provisión de QoS debería presentar un impacto negativo mínimo sobre el rendimiento actual del tráfico best-effort. De lo contrario, quizá una buena parte de los Proveedores de Servicios de Internet y los carrier no estarían dispuestos a asumir el coste de la implantación sobre sus sitemas autónomos best-effort funcionales.

4 4 A. Gazo, J.L. González-Sánchez La arquitectura actual de Internet no ofrece ninguna garantía con respecto a los parámetros de QoS, salvo la entrega fiable. Partimos entonces de que cualquier modificación de la arquitectura que permita a Internet ofrecer una garantía mayor será considerado un avance, pero sólo si no repercute negativamente sobre el rendimiento actual de la red. Por ello, en este trabajo se parte de las siguientes premisas: Incorporar mecanismos que permitan negociar la QoS obtenida desde la red. Si la red no puede ofrecer los requerimientos de QoS mínimos aceptables por el cliente, debe indicárselo rechazando la negociación [4]. Que la incorporación de estos mecanismos tenga un impacto negativo mínimo sobre el rendimiento de la arquitectura actual. Los tráficos best-effort y QoS deben coexistir, no estar enfrentados. Que la incorporación de estos mecanismos tenga un impacto mínimo sobre cambios de configuración de la equipación actual, proporcionando mecanismos de configuración automática allí donde puedan estar disponibles. Que las pilas de protocolos best-effort no se vean modificadas en ninguno de los elementos de la red. El fin último es proporcionar QoS a los clientes que lo solicitan y lo contratan. En caso de que pueda encontrarse algún modo de proporcionar esta QoS, hacerlo. Si los parámetros de QoS son inaceptables, el cliente no se encontrará con un caso diferente al actual funcionamiento de Internet, que no realiza ninguna garantía con respecto a estos parámetros. Si es imposible garantizar los parámetros de QoS incluso con estos nuevos mecanismos, tampoco se habrá llegado a una situación peor a la actual. De este modo, Los usuarios se verán beneficiados de las ventajas que supone la posibilidad de contratar una conexión QoS. El ISP tiene garantizada una ventaja competitiva con respecto al resto de ISP que no ofrezcan un servicio QoS. Los carrier que oferten un servicio QoS acabarán manejando más volumen de tráfico, ya que a través de ellos seguirá circulando tráfico besteffort y adicionalmente, todo el tráfico de las conexiones QoS que los carrier de la competencia pierden por no ofertar QoS. Este incremento en el volumen de tráfico supondrá, de forma directa o indirecta [5], un aumento en sus beneficios. Para ello, en nuestra propuesta realizamos una separación del plano QoS del plano best-effort, de modo que sólo se solapen en los mecanismos de control

5 Provisión Incremental de QoS Basada en Network Brokers 5 de la ruta de datos. El solapamiento en estos mecanismos de control es necesario desde el momento en que resulta imprescindible limitar los recursos destinados al tráfico best-effort en aquellos router donde coexista tráfico QoS y tráfico best-effort. Las funciones de encaminamiento QoS, reserva de recursos, control de acceso y clasificación de tráfico quedan en el plano QoS. Las funciones de encaminamiento best-effort quedan en el plano best-effort (cuadro 1), utilizando los mismos protocolos que existían en el AS funcional. Plano best-effort Plano QoS Encaminamiento X (*) X (**) Control ruta de datos X X Control de acceso X Reserva de recursos X (*) Según IGP best-effort en el AS (**) Según algoritmo QoSR específico para el plano QoS Cuadro 1. Funciones de los planos best-effort y QoS La pertenencia de un router a un AS equivale a la pertenencia del mismo al plano best-effort. La pertenencia de un router al plano QoS viene dada por el cumplimiento de los siguientes requirimientos: 1. Si es un router del núcleo de la red (Core Router): a) Que el router sea capaz de utilizar bases de datos de encaminamiento diferentes en función del campo DSCP. b) Que el router sea capaz de aplicar mecanismos de planificación de paquetes. 2. Si es un router del borde de la red (Edge Router): a) Que el router sea capaz de utilizar bases de datos de encaminamiento diferentes en función del campo DSCP. b) Que el router sea capaz de aplicar mecanismos de marcado de paquetes. c) Que el router sea capaz de aplicar mecanismos de planificación de paquetes. El plano QoS está compuesto, además de por los router que forman parte de él, por un agente ubicado en el AS encargado de la realización de las siguientes funciones:

6 6 A. Gazo, J.L. González-Sánchez Establecer en los router las políticas de control de la ruta de datos necesarias para la provisión de QoS. El agente establece en los router del borde del dominio las funciones de clasificación y planificación, y en los router del núcleo las funciones de planificación. Realiza el control de acceso. Los usuarios deben haber negociado los parámetros QoS que requieren de la red previamente al establecimiento de conexiones. Para el caso de la provisión de un servicio QoS, si el usuario no ha requerido el servicio o los parámetros no han sido aceptados, las conexiones sólo podrán establecerse en modo best-effort. Es responsabilidad del plano best-effort el control de acceso en este modo. Mantenimiento de la topología QoS superpuesta a best-effort. El mantenimiento de esta topología implica, por el carácter centralizado de la aproximación, el cómputo de los parámetros de clasificación y planificación de tráfico en la ruta de datos, así como el cómputo de los costes para los enlaces del AS en el plano QoS. Captura y procesamiento de la información del IGP. Con objeto de mantener la topología QoS superpuesta, el agente debe conocer cuál es la topología en el plano best-effort. Para ello, será destino de la información del protocolo de control de encaminamiento del AS. Tratamiento de estadísticas de tráfico obtenidas desde los ER para obtención de la matriz de tráfico. El tratamiento de estas estadísticas, junto con la base de datos de SLA y la información topológica, permite al agente realizar el cómputo de los parámetros de aprovisionamiento de recursos en la red para los planos QoS y best-effort. Negociación de capacidades QoS con dominios adyacentes. Puesto que la aproximación de este trabajo permite la coexistencia de AS con capacidad de provisión de QoS y de AS sin esta capacidad, los AS QoS deberán conocer, de sus AS adyacentes, cuáles son los que permiten la provisión de QoS. Coordinar y negociar automáticamente la provisión de QoS con dominios adyacentes. En función del tráfico observado en el AS, y disponiendo de la información de qué AS adyacentes permiten la provisión de QoS, el agente podría solicitar el establecimiento de nuevos parámetros para la provisión de QoS desde dominios adyacentes Topología QoS Superpuesta Intra-Dominio Para la provisión de QoS extremo a extremo, el primer paso es la provisión de QoS intra-dominio. Si bien la propuesta de topología QoS superpuesta

7 Provisión Incremental de QoS Basada en Network Brokers 7 presentada en este trabajo es aplicable a otros protocolos de encaminamiento, nos centraremos en el caso de Open Shortest Path Firts (OSPF) [6]. El protocolo OSPF es un protocolo de pasarela interior (IGP) que pertenece a la familia de los protocolos de encaminamiento de estado de enlace. Además del conjunto de mecanismos proporcionados por OSPF para realizar un encaminamiento best-effort, también se proporciona la posibilidad de utilizar bases de datos de estado de enlace seleccionables en función del campo TOS de IPv4. A pesar de que el encaminamiento basado en TOS se ha eliminado recientemente de la especificación de OSPF debido a la escasa implantación del mismo, para asegurar la compatibilidad hacia atrás, los router todavía son capaces de informar de las métricas específicas asociadas a los TOS en los LSA. Esto proporciona la posibilidad de probar el encaminamiento QoS como una extensión de las características estándar de TOS en OSPF. De hecho, en [7], se recoge uno de los primeros trabajos que utilizan el campo TOS para seleccionar la utilización de un algoritmo de encaminamiento QoSR en paquetes que tuvieran un valor TOS diferente de cero. El algoritmo de encaminamiento presentado es Widest-Shortest Path (WSP), que para OSPF que utiliza los 16 bits proporcionados para la representación de la métrica codificando el ancho de banda disponible en cada enlace. En el mismo trabajo se propone el mismo tipo de codificación para representar el retardo. Con respecto al mantenimiento de una topología QoS superpuesta a besteffort, el agente del plano QoS es responsable del mantenimiento de un grafo donde se han eliminado todos aquellos router que no disponen de las capacidades necesarias para la provisión de parámetros QoS (por ejemplo, si no disponen de la posibilidad de diferenciar el encaminamiento QoS del besteffort o no disponen de políticas de planificación de paquetes que permitan realizar reservas para las clases no-best-effort). Para la construcción y mantenimiento del grafo se utiliza la información de encaminamiento obtenida a partir del IGP. Una vez conocida la topología best-effort, el agente consulta las capacidades QoS de los router directamente mediante un protocolo de señalización, eliminando del grafo todos aquellos que no dispongan de dichas capacidades. En la figura 1 se muestra un ejemplo de una topología QoS superpuesta sobre un AS, donde uno de los router del núcleo (CR3) no soporta los requerimientos para permanecer en el plano QoS. En el plano QoS, se propone la implementación de la función de cálculo de costes en el agente. Los motivos para acometer esta ubicación son principalmente dos. Por un lado el hecho de que el agente va a disponer de un

8 8 A. Gazo, J.L. González-Sánchez Figura 1. Topología QoS Superpuesta conocimiento preciso de los flujos de tráfico que atraviesan el AS -tal y como se expondrá a continuación-, facilitando por tanto la optimización de la función de encaminamiento QoS. Por otro lado, esta ubicación también permite minimizar el impacto sobre los requerimientos de los router del AS, ya que no deben implementar un protocolo de encaminamiento adicional a BE, sino que basta con la mera selección de la base de datos de estado de enlace adecuada para realizar el reenvío de los paquetes. Con respecto a la función de encaminamiento en el plano QoS -utilizando OSPF en el plano best-effort-, el único requerimiento que deben cumplir los router para pertenecer al plano QoS es la posibilidad de selección de base de datos de estado de enlace. Esta capacidad se recoge en su especificación [6] como un requerimiento Topología QoS Superpuesta Inter-Dominio Una vez que se disponen de los mecanismos para la provisión de QoS en el intra-dominio, el siguiente paso es determinar si esta provisión debe extenderse también al inter-dominio. En [8] se argumenta que la mayoría de ISP importantes disponen de peerings directos entre ellos, bien públicos o privados. Por ello para los clientes que utilicen estos ISP, los flujos de aplicación atravesarán como mucho dos ISP diferentes, así que no resulta necesario utilizar mecanismos para elegir los mejores ISP intermedios. En lugar de ello, el

9 Provisión Incremental de QoS Basada en Network Brokers 9 único requerimiento consistiría en la selección correcta del egress router de forma que no se congestione. Sin embargo, los estudios presentados en [9], basados en experiencias empíricas, concluyen que incluso utilizando encaminamiento no basado en restricciones sino basado en la búsqueda de los caminos más cortos, el número de AS que atraviesa un flujo de aplicación se encuentra entre 3 y 4 para más del 70 % de los casos. Por ello, resulta necesario la búsqueda de rutas que necesariamente atraviesen AS que sean capaces de proporcionar QoS. Para abordar los aspectos relacionados con el encaminamiento inter-dominio basado en restricciones es necesario conocer la organización lógica de los AS en Internet. Según se concluye en [5, 10], los pares de AS se relacionan generalmente mediante pares cliente/proveedor o bien mediante peer/peer, de forma que se puede establecer una clasificación de AS del siguiente modo: AS cliente. Cuando un AS tan sólo dispone de una conexión a otro AS (figura 2a). AS de tránsito. Cuando un AS dispone de dos o más conexiones a otros AS y transporta tanto el tráfico local como el de tránsito entre los AS a los que se encuentra conectado. Es el caso típico de un ISP o de un carrier (figura 2a). AS Multi-homing. Un AS es un Multi-homing AS (AS A) cuando este AS está conectado con al menos dos AS de proveedores diferentes (AS B y AS C). Habitualmente, en esta configuración, el AS A utiliza el AS de uno de los proveedores como la conexión primaria a Internet, pasando a utilizar un AS de proveedor diferente si la conexión primaria se interrumpe (figura 2b). También puede utilizarse este esquema para realizar un equilibro de carga a través de los AS B y C. En cualquier caso, el AS A no permite la comunicación entre los AS B y C a través de él. Tal y como se concluye en [11], cuanto más cerca están los AS del núcleo de la red, el porcentaje de AS Multi-homing aumenta. De hecho, en este mismo estudio se concluye que más del 73 % de los clientes conectados a proveedores en el núcleo disponen de Multi-homing AS. Igualmente se aprecia una evolución ascendente en el porcentaje de AS Multi-homing en el tiempo. Por último, más del 61 % de los AS presentes actualmente en Internet son Multi-homing. Precisamente en las conclusiones expuestas con respecto a la organización actual de los AS Multi-homing en Internet encontramos uno de los escenarios de clara aplicación de nuestro trabajo, tanto en el caso de que el AS

10 10 A. Gazo, J.L. González-Sánchez AS Cliente ER IR IR AS Proveedor AS Cliente ER AS = Autonomous System ER = Egress Router IR = Ingress Router (a) AS cliente y AS proveedor ER IR AS Proveedor ER AS Multihoming IR AS Proveedor (b) AS Multihoming Figura 2. Clasificación de AS en función del tránsito de tráfico

11 Provisión Incremental de QoS Basada en Network Brokers 11 pertenezca a un cliente o a un proveedor. En este caso, el AS dispone de conectividad mediante varios proveedores. Si suponemos que alguno de estos proveedores oferta QoS, los equipos del AS Multi-homing podrán negociar automáticamente el establecimiento de rutas QoS a través de los proveedores que dispongan de una arquitectura capaz de garantizar conexiones QoS. Las conexiones no-qos podrán encaminarse bien por los carrier que ofertan QoS o bien por los que no (figura 3). El hecho de que, para la provisión de QoS, SLA ER ER IR Tráfico QoS+BE AS Proveedor (soporta QoS) AS Multihoming Tráfico BE IR AS Proveedor (no soporta QoS) Figura 3. El AS Multi-homing puede enviar tráfico QoS a través del proveedor que lo soporta, y tráfico best-effort a través de cualquiera no sea necesaria la implantación completa en todos los nodos de Internet se vuelve bajo este escenario una característica especialmente ventajosa. En cualquier caso, el agente del plano QoS en un dominio debe conocer cuáles son los dominios adyacentes que soportan la provisión de QoS. Para ello, se propone la utilización del campo de descripción de capacidades en el protocolo de pasarela exterior BGP, tal y como se especifica en [12]. En cualquier caso, también podría considerarse la utilización de mecanismos de señalización entre agentes de dominios adyacentes para intercambiar esta información. 3. Network Broker Bajo DiffServ, uno de los aspectos que son objeto de un trabajo de investigación intenso en la actualidad es la asignación y control del ancho de banda

12 12 A. Gazo, J.L. González-Sánchez dentro de un dominio Diffserv de forma que se satisfagan los objetivos de la organización. Un posible enfoque es hacer que los usuarios individualmente decidan qué servicio utilizar, pero este enfoque no es probable que sirva para alcanzar los objetivos deseados. Otro enfoque es tener un agente por cada dominio, llamado negociador de ancho de banda (Bandwidth Broker o BB), que registra la asignación actual de tráfico a varios servidores y trata solicitudes nuevas de servicio de acuerdo con las políticas de la organización y el estado actual de la asignación de tráfico [3]. Un BB gestiona el ancho de banda en un dominio de forma que: Es responsable no solamente de la asignación de tráfico a las diferentes clases de servicio dentro del dominio, sino también de establecer los clasificadores de paquetes y los contadores en los dispositivos de encaminamiento en los bordes de la red. El BB mantiene una base de datos de vigilancia que especifica a qué usuarios se les permite solicitar qué servicios en qué instantes de tiempo. El BB autentifica primero cada solicitador y después decide si hay suficiente ancho de banda para satisfacer la solicitud de servicio particular. El BB también mantiene acuerdos bilaterales con otros BB en dominios vecinos. Para flujos para los que el servicio solicitado tiene un destino en un dominio diferente, el BB comprueba si el flujo solicitado conforma la asignación predispuesta a través de alguno de los dominios adyacentes. El BB informa entonces al BB vecino apropiado para que trate este flujo nuevo. El BB vecino configura entonces su edge router para tratar el flujo de paquetes asignado. Este enfoque de acuerdo bilateral se ve como un medio viable de alcanzar acuerdos en el intercambio de tráfico DS a través de varios dominios. Se anticipa, al menos inicialmente, que la preasignación estática de ancho de banda en los acuerdos bilaterales será predominante. Sin embargo, se observa que los BB son capaces de tratar un amplio rango de granularidad en los acuerdos bilaterales hasta llegar al establecimiento dinámico de acuerdos bilaterales por flujo. Todavía existen decisiones de diseño abiertas en la arquitectura de los BB en DiffServ. Algunas implementaciones han sido propuestas y analizadas en [13 18], aunque en la mayoría de los casos no se llega a una especificación completa de la funcionalidad del BB para dar cumplimiento a las características antes expuesta. En nuestra propuesta, tal y como se expuso en el apartado anterior, extendemos la funcionalidad descrita para un BB, en los siguientes aspectos:

13 Provisión Incremental de QoS Basada en Network Brokers Mantenimiento de una topología QoS superpuesta a best-effort. 2. Captura y procesamiento de la información del IGP. 3. Tratamiento de estadísticas de tráfico obtenidas desde los ER para obtención de la matriz de tráfico. 4. Negociación de capacidades QoS con dominios adyacentes. De este modo, pasamos a denominar Network Broker (NB) al agente BB extendido con la nueva funcionalidad. Para incorporar la funcionalidad descrita, el NB está diseñado según se muestra en la figura 4. Figura 4. Componentes del Network Broker Los componentes presentes en el NB son los siguientes: Base de datos de usuarios. Se utiliza para el control de acceso para permitir el establecimiento o modificación de los acuerdos de provisión de

14 14 A. Gazo, J.L. González-Sánchez parámetros QoS, por lo que está directamente relacionada con la base de datos de SLA. Base de datos de topología de red. Contiene la siguiente información: Los identificación, ubicación y características de los router del AS. Las interfaces de red de los router del AS y sus características. El estado de los enlaces. Base de datos de SLA. Contiene los SLA establecidos entre los usuarios del dominio y el operador de red. También contiene los SLA establecidos entre el dominio y sus adyacentes. Base de datos de matriz de tráfico. Contiene los datos obtenidos acerca de la matriz de tráfico desde los ER del dominio, y sirve, junto con la base de datos de SLA y la de topología de red, para poder establecer los parámetros de control de tráfico en la ruta de datos. Interfaz con el operador de red. En aquellas alteraciones de la base de datos de SLA en las que se requiera de intervención humana, el NB proporciona una interfaz para que el operador de red supervise y apruebe dichas alteraciones. Estas alteraciones vendrán ocasionadas por peticiones que lleguen al NB por parte de los usuarios, requiriendo la intervención humana para la aprobación o supervisión de aquellas alteraciones que no puedan estar contemplados en una política automatizada de provisión de QoS en la organización. Por ejemplo, es posible que el establecimiento inicial de un SLA requiera de intervención humana desde el momento en el que exista un procedimiento administrativo para la firma de un contrato de servicio. Sin embargo, un usuario podría reducir las exigencias de QoS en un momento dado y esto podría estar contemplado en una política automatizada de forma que no se requiriera la intervención de un operador humano. Interfaz con el usuario. A través de esta interfaz, el usuario puede solicitar el establecimiento de un nuevo SLA o la alteración de uno ya existente. Interfaces para la configuración y control de los router del AS. Ésta configuración y control puede realizarse mediante diferentes mecanismos: RSVP [19], donde no se utilizan todos los mecanismos descritos en su especificación, sino tan sólo aquellos de señalización de reservas mediante mensajes RESV. A través de estos mensajes, el BB indica directamente al router correspondiente las características de las reservas para cada uno de los niveles de servicio en el contexto del pro-

15 Provisión Incremental de QoS Basada en Network Brokers 15 pio router. A este conjunto de características se le denomina Per-Hop Behavior (PHB) 1. COPS [21], un protocolo basado en TCP que utiliza un modelo cliente/servidor basado en los siguientes elementos 2 : El PEP (Policy Enforcement Point) es una entidad donde se aplican las políticas establecidas. Generalmente el PEP será un router o un gateway ubicado en una frontera del AS. El PDP (Policy Decision Point) es el responsable de la obtención de las reglas a aplicar y de la generación de decisiones de acuerdo con las peticiones recibidas desde el PEP. El PDP actúa por tanto como servidor para el PEP. Por sus características, reside BB del AS. SNMP [23], incorporado en la mayoría de los router, puede permitir el control del router por parte del BB para establecer los parámetros de clasificación y planificación de paquetes en caso de que el router no soporte otros protocolos como RSVP o COPS. Telnet/SSH. Si el router no dispusiera de capacidad de ser controlado mediante COPS o RSVP y su agente SNMP no implementara el MIB correspondiente para el establecimiento de los parámetros de clasificación y planificación de paquetes, el BB todavía podría controlar el router mediante mecanismos Telnet/SSH para el acceso al CLI (Command Line Interface) que, en cualquier caso, sería propietarios y debería disponerse de un plugin específico para el control Control de los Mecanismos de la Ruta de Datos El NB es el responsable de generar e indicar los parámetros clasificación a todos los ER del plano QoS. También debe generar e indicar los parámetros de planificación a todos los router del plano QoS. Para poder determinar estos parámetros de forma óptima, sería necesario conocer de un modo preciso la matriz de tráfico que atraviesa el dominio. Esta es precisamente la aproximación propuesta, describiéndose en el apartado 3.4 la forma en la que el NB 1 Según la definición de [20], un PHB es una descripción del comportamiento de reenvío que un nodo DS aplica a una colección de paquetes con un mismo DSCP. En general, el comportamiento observable de un PHB puede depender de ciertas restricciones relacionadas con las características de tráfico de los flujos asociados directamente con él, pero también de las características de otros flujos que atraviesen el nodo. 2 En caso de utilizar un control basado en COPS, los router además deben conocer la localización del BB en el AS. Esta localización del BB desde los router puede estar preconfigurada (mediante SNMP o Telnet/SSH) o bien puede realizarse automáticamente mediante SLP (Sevice Location Protocol) [22].

16 16 A. Gazo, J.L. González-Sánchez llega a adquirir este conocimiento. Del mismo modo, y debido a la aproximación centralizada de la función de asignación de costes a los enlaces para la realización del encaminamiento, el NB debe también conocer la topología del AS en el que se encuentran. Esta información la obtienen de la Base de Datos de Topología de Red. Por último, con respecto a la asignación de parámetros para los mecanismos de control de la ruta de datos, es necesario conocer los parámetros QoS que se garantizan a los usuarios, para tenerlos en cuenta a la hora de realizar las reservas de recursos en cada uno de los router. Por tanto, la obtención de los parámetros de mecanismos de la ruta de datos se obtiene a partir de la información que se refleja en la figura 5. Figura 5. Obtención de los parámetros a aplicar para el control de los mecanismos de la ruta de datos 3.2. Mantenimiento de la Topología QoS Superpuesta Otra de las funciones del NB es el mantenimiento de la topología QoS superpuesta. Por un lado, el mantenimiento de la topología QoS superpuesta implica la capacidad de determinar, por parte del NB, si un router es elegible para formar parte o no del plano QoS. Para ello, y utilizando las interfaces de configuración y control disponibles, el NB debe solicitar al router la indicación del cumplimiento de los requerimientos para la pertenencia al plano QoS. Partiendo del conocimiento de la topología QoS superpuesta, el NB asigna directamente los costes de los enlaces en los router presentes en dicha

17 Provisión Incremental de QoS Basada en Network Brokers 17 topología, consiguiendo de este modo la utilización de rutas que pueden ser diferentes a las rutas best-effort incluso para un mismo origen y destino. Para el caso de un dominio OSPF proponemos la utilización de al menos una base de datos de estado de enlace adicional a la utilizada para el encaminamiento best-effort, realizando una correspondencia entre el campo DSCP de los paquetes y la base de datos de estado de enlace seleccionada, tal y como se muestra en la figura 6. Una ventaja importante de este método es que la existencia de bases de datos de estado de enlace seleccionables se encuentra presente en OSPF desde su primera versión, por lo que tampoco es necesaria la modificación del IGP en este punto. Figura 6. Correspondencia entre DSCP y bases de datos de estado de enlace El mantenimiento de la topología QoS superpuesta también implica la monitorización del estado de los enlaces de la red ya que, en caso de un fallo prolongado de un conjunto de ellos, podría ser necesario el recálculo de los costes asociados a los enlaces del dominio para equilibrar la distribución de tráfico QoS en el dominio adaptándolo a la nueva situación. En cualquier caso, también puede ser necesario realizar este recálculo de costes en caso de que ocurran variaciones significativas con respecto a los requerimientos QoS solicitados por los usuarios o bien con respecto a los SLA negociados con los dominios adyacentes. En cualquiera de los dos casos, estas variaciones se realizan a través del NB, y debe ser este elemento el que determine si es necesario el recálculo o no. Debe tenerse en cuenta que la aproximación propuesta, donde el NB establece los costes de los enlaces, pero no indica a los router las rutas a seguir para cada flujo, permite un cierto nivel de autonomía a los router del plano QoS, que ante fallos en los enlaces seguirán enviando la información sobre la ruta operativa del plano QoS de menor coste Procedimiento de Descubrimiento Para que el NB pueda incorporar la información topológica en sus bases de datos, se establece que el NB sea capaz de interpretar la información del

18 18 A. Gazo, J.L. González-Sánchez protocolo IGP del plano best-effort. Este procedimiento de descubrimiento evita la alteración de un protocolo IGP que ya se puede encontrar operativo en un dominio. Además, para la obtención de las características de los router y de sus enlaces, deberá utilizarse alguno de los mecanismos de configuración y control descritos anteriormente Conocimiento de la Matriz de Tráfico Combinando la información almacenada en la base de datos de SLA con la información topológica obtenida desde el IGP, puede determinarse al menos uno de los extremos de los flujos enviados conforme a cada SLA. En algunos casos el SLA podría incluso permitir determinar ambos extremos, como por ejemplo al establecer un túnel VPN, donde podrían especificarse los dos extremos del túnel. Por lo tanto, si bien esta información puede ayudar a la hora de establecer los parámetros de planificación, construir los parámetros de planificación únicamente con dicha información puede llevar a resultados que no sean óptimos en la red, debido a un conocimiento impreciso de la forma en la que los flujos atravesarán el dominio. Por ello se propone la incorporación de mecanismos de recogida de estadísticas de tráfico en los ER que, al ser enviados al NB, permitan que éste pueda optimizar las reservas realizadas para las clases de tráfico en cada uno de los router con capacidades QoS. Realmente, esta recogida de información no tiene que implementarse como una incorporación de funcionalidad específica para dar cumplimiento a la propuesta presentada en este trabajo. En lugar de ello, se puede utilizar la especificación RMON [24], implantada ampliamente entre los dispositivos comerciales actuales. Mediante RMON, el acceso a la matriz de tráfico se realiza a través del OID mib-2.rmon.matrix Negociación QoS Inter-Dominio El establecimiento de un plano QoS y la negociación de parámetros interdominio son todavía aspectos que requieren de investigación ulterior. Si bien se contemplan diferentes aproximaciones, todas ellas parten de que el NB debe conocer si los dominios adyacentes proporcionan capacidad de provisión de QoS. Además deben definirse los mecanismos de señalización para la solicitud de establecimiento de parámetros para conexiones QoS entre dominios adyacentes.

19 Provisión Incremental de QoS Basada en Network Brokers Conclusiones En este trabajo presentamos una propuesta de arquitectura para una provisión incremental de QoS basada en Network Brokers. Su diseño está orientado a permitir el establecimiento de garantías QoS para los flujos de aplicación incluso en el caso de que no todos los elementos de la red permitan la asignación de restricciones QoS. Por un lado, en el intra-dominio, para el establecimiento de garantías QoS a los clientes basta con que exista al menos una ruta desde el ingress router hasta el egress router correspondiente de modo que los elementos de red atravesados permitan el establecimiento de mecanismos de clasificación y planificación de paquetes. El NB del dominio es el responsable de las actuaciones orientadas a que los paquetes que conforman el tráfico QoS sigan las rutas con restricciones QoS establecidas, así como del establecimiento de estas restricciones. Por otro lado, en el inter-dominio, se pueden establecer garantías QoS si existe al menos una ruta en la que todos los AS atravesados disponen de capacidad de provisión de QoS. Puesto que todo AS que permita la provisión de garantías QoS debe disponer de un NB, esto permite que los NB de los AS adyacentes puedan intercambiar información para el establecimiento de rutas QoS a través de ellos, ignorando los AS sin capacidad de provisión de QoS. Este escenario resulta especialmente atractivo para el caso de los clientes que disponen de conectividad mediante más de un proveedor (formando un AS Multihoming), que corresponde con más del 61 % de los AS en Internet. Si alguno de los proveedores dispone de capacidad de provisión QoS, en un AS Multihoming el tráfico QoS se puede dirigir a través de estos proveedores, mientras que el tráfico best-effort se puede dirigir a través de cualquier proveedor, disponga de capacidad para la provisión de QoS o no. 5. Trabajos Futuros En la actualidad, la investigación en torno a la provisión de QoS basada en DiffServ lleva a la integración de DiffServ con MPLS como una opción de especial relevancia. Por ello, como línea de trabajo actual estamos estudiando la integración de la propuesta con las tecnologías tanto MPLS como OSPF. De hecho, como decisión de diseño partimos de que el NB debe permitir la interoperabilidad con otros NB que pueden encontrarse en dominios en los que el IGP no sea el mismo

20 20 A. Gazo, J.L. González-Sánchez Referencias 1. Teitelbaum, B.: QBone architecture (v1.0). Internet2 QoS Working Group Draft (1999) 2. Teitelbaum, B., Geib, R.: Internet 2 QBone: a test bed for differentiated services. In: INET 99. (1999) 3. Nichols, K., Jacobson, V., Zhang, L.: A two-bit differentiated services architecture for the Internet. IETF RFC 2638 (1999) 4. Crawley, E., Nair, R., Jajagopalan, B., Sandick, H.: A framework for QoS-based routing in the Internet. IETF RFC 2386 (1998) 5. Huston, G.: Interconnection, peering, and settlements. In: INET 99. (1999) 6. Moy, J.: OSPF version 2. IETF RFC 2328 (1998) 7. G. Apostolopoulos and D. Williams and S. Kamat and R. Guerin and A. Orda and T. Przygienda: QoS Routing Mechanisms and OSPF Extensions. IETF RFC 2676 (Experimental) (1999) 8. Xiao, X.: Providing Quality of Service in the Internet. PhD thesis, Department of Computer Science and Engineering, Michigan State University (2000) 9. Magoni, D., Pansiot, J.J.: Analysis of the autonomous system network topology. ACM SIGCOMM Computer Communication Review 31 (2001) Alaettinoglu, C.: Scalable router configuration for the Internet. In: 1996 International Conference on Networking Protocols. (1996) 11. Ge, Z., Figueiredo, D., Jaiswal, S., Gao, L.: On the hierarchical structure of the logical Internet graph. In: SPIE ITCOM. (2001) 12. Chandra, R., Scudder, J.: Capabilities advertisement with BGP-4. IETF RFC 3392 (2002) 13. of Technology, B.C.I.: Ca*net ii differentiated services: bandwidth broker high level design (1998) 14. Günter, M., Braun, T.: Evaluation of bandwidth broker signalling. In: Proc. of IEEE 7th International Conference on Network Protocols. (1999) Khalil, I., Braun, T.: Implementation of a bandwidth broker for dynamic end-to-end capacity reservation over multiple diffserv domains. Lecture Notes in Computer Science 2216 (2001) 160?? 16. Stiller, B., Braun, T., Günter, M., Plattner, B.: The cati project: charging and accounting technology for the internet. In: Proc. of 4th European Conference: Multimedia Applications, Services and Techniques. (1999) Rajan, R., Verma, D., Kamat, S., Felstaine, E., Herzog, S.: A policy framework for integrated and differentiated services in the Internet. IEEE Network Magazine 13 (1999) Terzis, A., Ogawa, J., Tsui, S., Wang, L., Zhang, L.: A prototype implementation of the twotier architecture for differentiated services. 5th IEEE Real-Time Technology and Applications Symposium (RTAS99) (1999) 19. Braden, R., Zhang, L., Berson, S., Herzog, S., Jamin, S.: Resource reservation protocol (RSVP). IETF RFC 2205 (1997) 20. Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., Weiss, W.: An architecture for differentiated services. IETF RFC 2475 (1998) 21. Durham, D., Boyle, J., Cohen, R., Herzog, S., Rajan, R., Sastry, A.: The COPS (Common Open Policy Service) protocol. IETF RFC 2748 (2000) 22. Guttman, E., Perkins, C., Veizades, J., Day, M.: Service Location Protocol, version 2. IETF RFC 2608 (1999) 23. Baker, F., Chan, K., Smith, A.: Management information base for the differentiated services architecture. IETF RFC 3289 (2002) 24. S. Waldbusser: Remote Network Monitoring Management Information Base. IETF RFC 2819 (2000)