Fonctionnalités à proposer aux utilisateurs

A arquitectura IntServ [Braden94] foi desenvolvida com o objectivo de obter modelos de serviço superiores ao actual modelo de melhor esforço, através da reserva de recursos para cada fluxo de tráfego de acordo com as suas características. Com IntServ é possível manter o modelo de datagrama usado nas redes baseadas em IP e, simultaneamente, suportar aplicações em tempo real através da reserva de recursos e da diferenciação do tráfego de cada utilizador e/ou serviço.

Nestas arquitecturas presume-se que o processo de reserva de recursos é efectuado após se ter definido o percurso do fluxo, em que este é definido por outros protocolos. A reserva de recursos para um fluxo de tráfego consiste em vários passos: (1) a aplicação especifica o fluxo, isto é, indica quais as características de tráfego e os requisitos de QdS do fluxo; (2) o pedido de reserva é enviado para a rede; (3) cada router ao receber o pedido decide, através de um algoritmo de controle de admissão, se existem recursos suficientes para aceitar este fluxo com as características pretendidas. Quando a reserva é efectuada e bem sucedida, a informação acerca do fluxo e do seu estado de reserva é colocada numa tabela de reserva de recursos existente nos routers. Esta informação vai ser posteriormente utilizada quando o router receber pacotes correspondentes a este fluxo de tráfego. Os pacotes são identificados e colocados na respectiva fila de espera, e o escalonador de pacotes atribui recursos para os diferentes fluxos de acordo com a informação de reserva de cada um deles.

Para criar uma reserva de recursos para um fluxo em cada elemento da rede ao longo do percurso definido, é necessário um protocolo de estabelecimento de reservas para instalar o estado de reserva do fluxo. Este protocolo distribui a informação sobre as características do fluxo e os seus requisitos de QdS em cada nó ao longo do percurso, para que possa ser determinado em cada elemento da rede se o novo pedido de reserva pode ou não ser aceite. O protocolo de sinalização utilizado na arquitectura IntServ é o RSVP (resource ReSerVation Protocol) [Zhang93]. O RSVP inclui mecanismos que permitem fazer o “refrescamento” da reserva. Deste modo, o RSVP adapta-se automaticamente a alterações nas rotas definidas.

Antes de uma reserva ser aceite, esta tem de passar o teste do controle de admissão em cada nó da rede. As reservas só podem ser aceites se existirem recursos disponíveis em cada ligação. O controle de admissão pode ser baseado nos parâmetros dos fluxos, por exemplo nos parâmetros do leaky bucket , ou baseado em medidas da carga de tráfego da rede. A primeira hipótese torna-se difícil de implementar quando o tráfego não tem um modelo bem definido e apresenta grandes variações ao longo do tempo. A segunda hipótese é mais pesada em termos de carga computacional, pois é necessário, repetidamente, monitorizar a quantidade de tráfego em cada ligação.

Para além de manter o processo de reserva de recursos cada nó, ao receber um novo pacote, necessita de, em tempo real, identificar o fluxo a que este pertence, e consequentemente, decidir para que fila de espera o deve encaminhar. No contexto IntServ, a identificação é efectuada através de 5 campos do cabeçalho do pacote IP: endereços IP da origem e destino, identificação do protocolo, e portos de origem e destino. Depois de se identificar a que fluxo pertencem os pacotes, o escalonador decide a ordem pela qual eles são servidos.

A interacção entre estas funções implementadas nos nós de uma rede IntServ é ilustrada na Figura 3-3.

Agente de Activação da Reserva Agente de Encaminhamento Controle de Admissão Classificador (Identificação do Fluxo) Tabela de Reservas de Recursos Escalonador Escalonador ... Entrada de Pacotes Saída de Pacotes

Figura 3- 3 : Modelo de referência IntServ.

3.4.1.1 Modelos de serviço

Os modelos de serviço descrevem, por um lado, os serviços que os utilizadores podem utilizar na rede e, por outro lado, os compromissos de garantia de recursos que a rede pode oferecer. Na arquitectura IntServ, além do serviço de melhor esforço, existem dois outros modelos de serviço: serviço garantido e serviço de carga controlada. Antes da apresentação destes serviços, serão primeiro descritos os parâmetros utilizados na especificação dos fluxos, que incluem a caracterização do tráfego e dos requisitos de QdS. Os parâmetros que definem o fluxo de tráfego serão designados de parâmetros de descrição do tráfego; os parâmetros que definem os requisitos de QdS serão designados de parâmetros de especificação do serviço. Estes parâmetros serão detalhados na secção seguinte.

3.4.1.1.1 Especificação dos fluxos

A especificação dos fluxos é como que um contrato de serviço entre o utilizador e a rede, no qual se descreve o fluxo de tráfego que será enviado e os serviços e recursos que a rede se compromete a fornecer. Se o utilizador, por exemplo, envia mais tráfego do que o contratado, a rede não poderá cumprir o nível de QdS esperado. Normalmente, o tráfego é modificado antes de entrar na rede para garantir que está de acordo com o perfil definido. Na arquitectura IntServ, o tráfego é descrito através dos parâmetros (b, p) do leaky bucket.

Para uma aplicação pedir um serviço tem de especificar à rede os parâmetros de descrição do tráfego e de especificação do serviço.

Os parâmetros de descrição do tráfego incluem os parâmetros do leaky bucket, a taxa de pico, e os comprimentos máximo e mínimo dos pacotes.

Os parâmetros de especificação do serviço dependem do tipo de serviço, da sua sensibilidade a atrasos e a perda de pacotes. Os parâmetros normalmente utilizados são a largura de banda mínima (que será garantida por algoritmos de escalonamento de pacotes, por exemplo, o WFQ), o atraso (que pode ser especificado como atraso médio ou atraso máximo), variações no atraso, e o rácio de perdas de pacotes.

3.4.1.1.2 Serviço garantido

O serviço garantido [Shenker97] é um serviço que fornece garantias estritas de largura de banda e limites bem definidos para os atrasos extremo-a-extremo nas filas de espera. É a classe de serviço que pode oferecer melhores garantias de qualidade de serviço, devendo ser usada em aplicações que requeiram elevadas garantias ao nível de largura de banda e atrasos. O comportamento extremo -a-extremo de um percurso onde são transportados serviços garantidos pode ser equiparado a um circuito virtual com largura de banda garantida.

Os fluxos de tráfego devem estar de acordo com os parâmetros do leaky bucket em todos os períodos de tempo em que o fluxo está activo. Se não estiverem de acordo, os seus pacotes são policiados e reformatados antes de entrarem na rede. Os pacotes que não estiverem de acordo com o perfil de tráfego são tratados como pacotes do serviço de melhor esforço, e podem também ser marcados com uma prioridade elevada de descarte em caso de congestão da rede. Numa arquitectura IntServ, o policiamento é feito à entrada de cada domínio.

3.4.1.1.3 Serviço de carga controlada

Para algumas aplicações menos exigentes, um modelo de serviço garantido não é apropriado porque, além de dar garantias estritas não necessárias, diminui em muito a utilização da rede pelo facto de os recursos terem de ser reservados para o pior caso. Para essas aplicações menos exigentes, é preferível um modelo de serviço com menores

tem um comportamento semelhante ao de um serviço de melho r esforço numa rede que não se encontra congestionada, ou em que o nível de congestionamento é muito baixo.

Este modelo de serviço possibilita a multiplexagem estatística entre os diversos fluxos de tráfego. Assim, a determinação dos recursos que se encontram disponíveis para decidir a aceitação ou rejeição de um novo fluxo pode ser feita, por exemplo, em função da taxa máxima agregada medida em intervalos de tempo anteriores, relativa a todos os fluxos pertencentes a este modelo de serviço. Deste modo, como o controle de admissão é realizado com base em medidas efectuadas em intervalos de tempo anteriores, este serviço permite a existência de aumentos pontuais nas perdas e atrasos do tráfego processado de acordo com esse modelo. No entanto, num serviço de carga controlada, a probabilidade de existência destes eventos deve ser baixa. Também neste modelo, o tráfego fora do perfil é tratado como pertencente ao modelo de melhor esforço.

3.4.1.2 RSVP

Ao contrário do modelo de melhor esforço, nos modelos de serviço garantido e de carga controlada definidos pela arquitectura IntServ, antes de uma aplicação começar a transmitir tráfego para a rede, tem de iniciar um pedido de reserva de recursos e obter uma resposta positiva por parte de todos os elementos da rede. O protocolo de reserva de recursos desenvolvido pelo IETF e usado pela arquitectura IntServ é o RSVP [Zhang93, Braden97]. Os utilizadores usam o protocolo para comunicar à rede as características de tráfego e os requisitos de QdS dos serviços, e os nós da rede usam-no para estabelecer o estado de reserva ao longo do percurso dos fluxos.

As reservas efectuadas são unidireccionais, sendo por isso necessário, numa comunicação bidireccional, que os dois extremos da comunicação estabeleçam a reserva nas duas direcções. Os estados de reserva de cada fluxo presentes nos nós da rede ao longo de um percurso são designados de soft state, devido ao facto de estes estados terem um tempo de vida associado. Se não forem enviadas mensagens de refrescamento (refresh) periodicamente, o estado do fluxo é automaticamente apagado. Deste modo, o RSVP adapta-se facilmente a alterações das rotas definidas.

3.4.1.2.1 Mensagens RSVP

O RSVP tem vários tipos de mensagens: PATH, RESV, PATHErr, RESVErr, PATHTear e RESVTear. A mensagem PATH instala o “estado do percurso” em cada nó do percurso.

Este “estado do percurso” inclui, pelo menos, o endereço IP do nó anterior, que será utilizado para encaminhar a mensagem RESV no sentido oposto. A mensagem PATH contém também a descrição do tráfego que será gerado pela origem. A mensagem RESV é uma mensagem de pedido de recursos que inclui informação sobre o fluxo de tráfego e QdS especificada. A mensagem PATHErr/RESVErr é uma mensagem enviada quando se encontra uma situação de erro no processamento da mensagem. A mensagem PATHTear/RESVTear remove os estados de encaminhamento e de reserva previamente estabelecidos nos nós.

3.4.1.2.2 Modo de operação

O RSVP funciona da seguinte forma (Figura 3-4): (1) o utilizador origem envia uma mensagem PATH ao utilizador destino com as características de tráfego e os requisitos de QdS, e cada nó ao longo do percurso retransmite a mensagem para o nó que se lhe segue em direcção ao destino. A mensagem PATH é marcada com o endereço de cada nó que atravessa, para que este seja armazenado no nó seguinte. (2) Após receber a mensagem PATH, o receptor envia uma mensagem RESV de pedido de reserva de recursos para o fluxo. Cada nó ao longo do percurso pode aceitar ou rejeitar o pedido consoante existam ou não recursos disponíveis. Se o pedido é rejeitado num nó, este envia uma mensagem de erro ao receptor e o processo de sinalização é terminado. Se a reserva é aceite, é reservada largura de banda para o fluxo. Após receber uma mensagem RESV com sucesso, a origem pode iniciar a transmissão de pacotes ao longo do percurso que contém a largura de banda reservada.

PATH

Origem Destino

PATH

PATH

RESV RESV RESV

3.4.1.3 Análise da arquitectura IntServ

A arquitectura IntServ permite transformar a rede Internet actual numa rede com mecanismos de suporte de QdS e de diferenciação do tratamento associado a cada serviço. No entanto, esta arquitectura apresenta um conjunto de limitações:

? O processo de criação de uma reserva para cada fluxo é um processo moroso que apenas faz sentido em sessões cuja duração seja relativamente elevada. As aplicações baseadas na WWW (World Wide Web) são dominantes hoje em dia, e a maior parte do tráfego Web é resultante de sessões de pequena duração.

? Cada nó da rede tem de manter armazenado o estado de cada fluxo. No caso de redes de núcleo, o número de fluxos pode ser muito elevado e as tabelas de armazenamento tornam-se demasiado grandes para que cada nó as possa suportar.

? Cada nó da rede tem de implementar classificação por fluxo, através da inspecção dos cinco elementos do cabeçalho IP, e da procura desses cinco elementos na tabela de armazenamento. Além disso, o escalonamento de pacotes é também efectuado por fluxo. Mais uma vez, com milhares de fluxos activos em cada nó, pode ser complicado efectuar estas operações a elevados débitos e em tempo real.

Por estas razões, a arquitectura IntServ é de muito difícil implementação em redes de núcleo. Nas redes de acesso os problemas são atenuados porque o número de fluxos activos em cada nó pode ser muito inferior.

No sentido de fornecer suporte de QdS às redes de núcleo, o IETF definiu uma nova arquitectura, a arquitectura DiffServ que limita as funcionalidades de QdS a mecanismos de tratamento diferenciado de classes de serviço em função de acordos de nível de serviço (Service Level Agreement - SLA). Deste modo, esta arquitectura é de fácil implementação tanto em redes de acesso como de núcleo.