O Protocolo RSVP e o Desempenho de Aplicações Multimídia

Ana Luísa Pereira Schmidt <luisa@nc-rj.rnp.br>

Rede Nacional de Ensino e Pesquisa (RNP)

Introdução
RSVP
Controle de tráfego
Conclusão
Referências bibliográficas
Sites relacionados

Este artigo mostra um resumo do trabalho de tese de mestrado sob o título ``Análise de Qualidade de Serviço para Aplicações de Tempo Real Utilizando Reserva de Recursos na Internet''[11], apresentada em setembro de 1999.

O objetivo foi o estudo e a configuração de um ambiente com Qualidade de Serviço (QoS) e a execução de diversos experimentos. Foram criadas duas aplicações multimídia (vídeo e voz) e observado o comportamento de parâmetros que expressam a QoS, como jitter e perda de pacotes para essas aplicações. Os experimentos utilizaram o gerenciador de recursos proposto pelo IETF[1] para uso na Internet, o RSVP[2,3,4], e o módulo de controle de tráfego ALTQ[7,8], traçando comparações de forma a averiguar melhoras ou não nos parâmetros obtidos.

Este documento foi dividido em duas partes. Nessa edição, uma visão da proposta e revisão do protocolo RSVP foram apresentadas.

No próximo número, continuaremos com a descrição dos aplicativos desenvolvidos, bem como alguns resultados que ilustram os parâmetros de QoS na recepção, tendo a transmissão sofrido influências de um ambiente com carga (artificial) elevada.

Introdução

Com o desenvolvimento de aplicações de tempo real (onde o parâmetro tempo é um requisito importante) e multicast (i.e. transmissão de uma fonte para vários destinos ou de várias fontes para vários destinos), foi necessário desenvolver mecanismos para que a sub-rede de comunicação pudesse prestar um serviço com uma QoS diferenciada, uma vez que essas aplicações como vídeo e voz exigem uma qualidade mínima em termos de parâmetros temporais (como atraso e jitter) e capacidade efetiva de transmissão (como largura de banda).

Surgiu, então, uma proposta nova para redes chamada de Serviços Integrados para Redes de Pacotes: ISPN[1] (do termo em inglês Integrated Services Packet Network). Na metodologia proposta pelo IETF (Internet Engineering Task Force), cada aplicação que necessite de uma QoS para seus pacotes, deve informar as condições que julge necessárias ou imprescindíveis para que isso se concretize.

Mecanismos de controle de admissão e escalonamento de pacotes tornaram-se importantes para que os roteadores mantenham uma dinâmica dos recursos mais equilibrada, de forma que todas as aplicações tenham iguais oportunidades de realizar suas comunicações.

O controle de admissão implementa um algoritmo que garante ou nega os recursos, mantendo a carga da rede em níveis aceitáveis para todos os usuários. Esse controle é realizado na entrada da rede. O escalonamento de pacotes, por sua vez, utiliza-se de algoritmos que decidem em que ordem devem ser enviados os pacotes que estejam aguardando transmissão, de acordo com a prioridade definida pela aplicação, localizando-se sempre na saída.

Fez-se necessário também a existência de um protocolo de gerência de recursos, de forma a requisitar e reservar em um determinado caminho, a QoS requerida pelas aplicações, estando estas em ambiente ponto-a-ponto ou multicast. Como recursos mais comumente utilizados para a gerência, podemos citar a largura de banda desejada pela aplicação, o controle de tamanho de buffers (para comportar possíveis rajadas), etc.

A utilização de um gerenciador de recursos no contexto da rede é importante à medida que implementa mecanismos para o tratamento particularizado do tráfego (seja ele interativo ou não). Para tráfegos que possuam características comuns em termos de parâmetros de QoS, o compartilhamento de recursos torna-se factível. Caso não haja possibilidade de compartilhamento, torna-se possível adotar políticas diferenciadas para cada fluxo. O RSVP[2,3,4] (ReSerVation Protocol) foi escolhido para os testes por ser um padrão proposto pelo IETF para Internet.

A fim de realizar o controle em cada ponto, é necessária a presença de mecanismos de controle de tráfego. No contexto deste trabalho, usamos o software ALTQ[7,8], que foi desenvolvido para máquinas com sistema operacional FreeBSD e que possui interface com o RSVP. O ALTQ implementa mecanismos de escalonamento de pacotes, de classificação de fluxos de tráfego e de controle de admissão.

Visando investigar o comportamento de aplicações multimídia nesse ambiente, serão traçadas comparações entre o funcionamento dessas aplicações com e sem reserva de recursos. Com este trabalho, poderemos avaliar o impacto do uso do protocolo de reserva de recursos RSVP, juntamente com seu módulo de controle de tráfego (ALTQ) na QoS fornecida às aplicações. Assim como foi realizado para um ambiente próprio, imaginamos que o ambiente possa ser estendido à toda Internet levando um controle diferenciado aos demais pontos da rede.

RSVP

ARQUITETURA

É um protocolo desenvolvido para permitir que as aplicações requisitem diferentes QoS para seus fluxos de dados. Para isso, dois pré-requisitos devem ser observados:

Elementos de redes, tais como roteadores, devem adequar-se aos mecanismos de controle de qualidade de serviço para garantir a entrega dos pacotes de dados;
A aplicação deve estar capacitada a fornecer os parâmetros ideais de QoS.

O RSVP não é um protocolo de roteamento, trabalhando em conjunto com este. É usado por uma aplicação para requisitar uma qualidade de serviço específica da rede. O protocolo atua tanto em máquinas do usuário quanto em roteadores, responsabilizando-se, nesse caso, a estabelecer e manter as condições para o serviço requisitado. O diagrama esquemático pode ser visto na figura 1.

Figura 1: RSVP em Máquinas do Usuário e Roteadores.

O RSVP negocia a reserva de recursos em um único sentido de cada vez, ou seja, de forma simplex.. Com isso, ele trata distintamente receptores e transmissores, operando juntamente com a camada de transporte.

O RSVP não realiza transporte de dados, sendo apenas um protocolo de controle e atuando no mesmo nível de outros protocolos como o ICMP (Internet Control Message Protocol), o IGMP (Internet Group Management Protocol) ou protocolos de roteamento, conforme mostrado no desenho esquemático da figura 2. O gerenciamento ocorre no início da comunicação, sendo reiniciado de tempos em tempos. Caberá ao receptor a responsabilidade em requisitar uma QoS específica. O protocolo RSVP foi feito de forma a garantir que as arquiteturas mais antigas sejam compatíveis com o novo sistema, através do encapsulamento de seus pacotes de controle.

Figura 2: Camada de Atuação do Protocolo RSVP

A fim de melhor ilustrar o funcionamento do protocolo, a sessão seguinte foi organizada, contendo os principais conceitos que serão utilizadas ao longo do texto.

DEFINIÇÃO DE CONCEITOS BÁSICOS

Sessão

O protocolo RSVP define como sessão todo enlace de comunicação pelo qual se relacionam as camadas de transporte de todos os participantes da comunicação, podendo ser ponto-a-ponto ou multicast. Cada sessão é tratada independentemente. O conceito de sessão é propositalmente genérico, pois uma sessão pode ser estabelecida baseando-se em valores de QoS diferentes daqueles requisitados pelo receptor inicialmente. Tal fato deve-se à liberdade que o gerenciador possui em unir recursos ao longo do caminho de dados da aplicação, sempre tendo o melhor aproveitamento dos recursos como objetivo. Ao efetuar essa política, os valores de QoS requisitados poderão sofrer alterações, desde que essas não acarretem perda de qualidade para uma comunicação já estabelecida.

Soft-state

O protocolo RSVP é baseado na noção de soft-state. Este termo foi inicialmente proposto por [5], definindo o ``estado'' que um determinado elemento, pertencente ao percurso de dados de um determinado par fonte-destino, se encontra quando uma reserva está estabelecida. O início do soft-state ocorre quando uma mensagem de reserva é recebida e realizada no elemento; este estado é periodicamente realimentado pelos receptores. Ao invés de entregar à rede a responsabilidade em detectar e responder a falhas, o RSVP delega aos receptores o trabalho de reenviar periodicamente suas requisições de serviços. Caso uma falha ocorra, somente uma nova requisição do serviço restabelecerá o soft-state nos roteadores.

MENSAGENS

Uma série de mensagens (ou objetos do RSVP) devem ser trocadas entre as aplicações e os elementos de rede para corretamente requisitar a qualidade de serviço para uma determinada sessão.

Após a definição da sessão, serão trocadas mensagens de controle RSVP. As mensagens RSVP fundamentais são RESV e PATH. Cada uma deverá explicitamente requisitar a QoS através de objetos descritores do tráfego e filtros. Dependendo do serviço de QoS, esses objetos possuirão alterações a fim de comportar os diversos parâmetros de interesse [4].

A mensagem PATH, enviada pelo transmissor, é propagada pelo caminho ponto-a-ponto ou multicast, seguindo a rota informada pelos mecanismos de encaminhamento até os receptores. Um elemento no caminho dos dados, ao receber um PATH, criará um estado chamado PATH state . As mensagens deste tipo armazenam o estado de cada nó por onde ela transitou.

A mensagem RESV, enviada pelo receptor, contém um descritor de fluxo, definindo a QoS aceita pelo receptor em função daquela pedida pela mensagem PATH.

Mediante à troca dessas mensagens, o protocolo toma uma série de decisões, como por exemplo, aceitar ou não um novo fluxo, criando um ambiente para que os recursos sejam reservados. Cada parâmetro utilizado para a requisitar a QoS está representado nas mensagens do RSVP.

Através da análise dos parâmetros trazidos pelos objetos RSVP, algumas simplificações podem ser feitas, de forma a agrupar fluxos distintos de uma mesma sessão que possuam características comuns. Tal tarefa, apesar da complexidade, proporciona, quando é possível, uma economia dos recursos utilizados, principalmente em termos de largura de banda. Para que isso possa ocorrer, é essencial a utilização dos estilos de reserva, assunto que será abordado em seguir.

ESTILOS DE RESERVA

Uma requisição de reserva inclui, além da QoS desejada, a opção sobre o estilo de reserva. Através dos estilos, o protocolo RSVP apresenta uma forma mais elaborada de tratar os recursos disponíveis sobre seu controle, tornando possível uma economia dos mesmos se assim permitirem os elementos envolvidos no processo. A necessidade dos estilos de reserva é mais evidente quando em presença de uma comunicação multicast. Como exemplo, ao invés de reservar recursos para cada palestrante em uma teleconferência, uma única reserva compartilhada pode ser estabelecida de tal forma que os recursos sejam suficientes para atender a todos os participantes. Todo o grupo multicast, contido em uma única sessão, compartilharia uma única reserva.

Existem três estilos definidos:

Reservas compartilhadas, no caso dos estilhos SE e WF, são próprias para aquelas aplicações multicast em que múltiplas fontes não podem, ou não precisam, transmitir simultaneamente. Áudio é um exemplo, uma vez que um número limitado de pessoas fala ao mesmo tempo. Por outro lado, o estilo FF, que cria reservas distintas para o tráfego entre diferentes transmissores, é apropriado para sinais de vídeo, por exigirem mais banda.

MODELO DE RESERVA

Vejamos um cenário simples, ponto-a-ponto, em que todos os elementos compreendam o protocolo RSVP. Em cada nó roteador, além do gerenciador de recursos, responsável pela reserva, existem módulos de controle de tráfego e policiamento que auxiliam o RSVP na tarefa de reservar os recursos requisitados, baseados no esquema da figura 1. Como pré-requisito, uma sessão RSVP deverá ser instalada.

Seja T1 uma máquina que contém uma aplicação que tenha requisitos de QoS, R1 outra máquina que receberá dados dessa aplicação e G roteadores intermediários. A aplicação em T1, para iniciar sua transmissão, envia uma mensagem de controle chamada de mensagem de caminho (ou path message ou PATH), que seguirá seu caminho, pelos diversos roteadores até chegar em R1, conforme figura 3. A mensagem PATH contém um cabeçalho RSVP e todas as informações sobre o tráfego que a aplicação em T1 espera gerar, i.e, valores para os parâmetros de QoS. A cada roteador G existente entre T1 e R1, será criado um estado chamado de PATH state.

Figura 3: Mensagem PATH Seguindo de T1 a R1.

Ao chegar em R1, este analisa as informações contidas em PATH e seleciona os parâmetros de reserva desejados, montando a mensagem de reserva (ou reservation message ou RESV). Por onde passar, a RESV provocará nos roteadores um estado chamado SOFT state , até chegar de volta em T1, informando-o sobre as condições dos parâmetros de QoS da reserva realizada por R1 e propriedades do caminho entre ambos, como é mostrado na figura 4.

Figura 4: Reserva entre R1 e T1, Criando o Soft State nos Elementos Intermediários.

Caso multicast:

No caso de comunicação multicast, um membro, digamos R1, envia uma mensagem IGMP para juntar-se ao grupo multicast. Sendo aceito no grupo, receberá mensagens de PATH contendo informações quanto ao cenário atual no qual se encontra a rede em termos dos parâmetros de QoS. Concordando em fazer parte daquela sessão RSVP, o membro passará a registrar o PATH-state. Ao ser requisitada comunicação por um transmissor ou conjunto de transmissores, este membro então enviará uma mensagem de RESV para reservar os recursos ao longo do caminho, traçado pelo encaminhamento, de volta até os transmissores, conforme o exemplo acima, ilustrado nas figuras 3 e 4. A reserva seria realizada segundo o estilo de reserva escolhido pelo receptor e conforme as possibilidades de composição dos parâmetros de QoS em cada nó do caminho entre R1 e T1, sendo o resultado entregue a T1. Dependendo do resultado, T1 poderá decidir manter a comunicação ou não.

Pelo modelo de reserva criado, é o receptor o responsável por requisitar a QoS desejada. O protocolo RSVP se encarrega de passar essa informação para todos os nós (ou roteadores) no caminho reverso, até chegar ao transmissor, mantendo o ``Soft state''. Em cada nó intermediário ou roteador, o processo RSVP comunica-se com dois módulos de decisão: o de controle de admissão e o de policiamento.

A requisição de reserva que um nó receptor envia para o nó transmissor pode variar da requisição inicial recebida por duas razões:

Os nós intermediários não puderam fornecer a QoS desejada;
As reservas para um mesmo transmissor, ou conjunto de transmissores, de diferentes ramos da árvore multicast, conforme o estilo de reserva requisitado, podem ser agrupadas. Logo, quando um nó receptor envia para o seu transmissor os valores de recursos desejados ao longo do caminho, estes são combinados em cada nó de acordo com a regra estabelecida para cada parâmetro (por exemplo, no caso da largura de banda, apenas a maior banda ao longo do caminho é fornecida a todos os participantes).

Controle de tráfego

Além das propriedades específicas que os protocolos de encaminhamento devem fornecer para a realização da reserva em rede, outras funções devem ser utilizadas para se chegar ao objetivo de conseguir e manter a qualidade de serviço requisitada pelas aplicações. Conforme mostrado na figura 1, o RSVP atua em conjunto com outros módulos, ditos de controle de tráfego, a saber: escalonador de pacotes, classificador de pacotes e controle de admissão. Estes atuam tanto nos elementos finais (transmissores e receptores) quanto nos roteadores ao longo do caminho. A seguir foram destacadas as principais características dos módulos de controle de tráfego.

ESCALONAMENTO DE PACOTES

A função básica do escalonamento é implementar uma política para servir os pacotes na fila de saída. O esquema mais comumente utilizado é o FIFO (do inglês, First In First Out). Nele, os pacotes são servidos estritamente na ordem de chegada. Entre os muitos esquemas propostos, talvez o mais simples seja um esquema de prioridades, onde o pacote que tenha maior prioridade seja servido em primeiro lugar. Um problema inerente a essa solução é que na presença de pacotes de alta prioridade, aqueles que não possuem nenhum tipo de privilégio podem ser atrasados em muito no seu trajeto. Maiores informações sobre escalonamento podem ser encontrados em [9].

Pode-se citar o esquema de Weight Fair Queueing ou WFQ que conseguiria uma alocação mais igualitária, distribuindo pesos aos diversos fluxos de saída. Outro mecanismo de escalonamento que podemos citar é o esquema que trabalha com classes: CBQ[6] (do termo Class Based Queue). Nele, os pacotes dos diversos fluxos são enquadrados em diversas classes, organizadas de forma a criar um esquema de prioridades entre os fluxos de dados da saída.

Ambos os tipos de escalonamentos estão implementados no pacote ALTQ utilizado em conjunto com o RSVP. Maiores informações podem ser conseguidas em [7,8].

CONTROLE DE ADMISSÃO

O controle de admissão implementa um algoritmo de decisão que um roteador ou uma máquina utiliza para determinar se um novo fluxo de dados poderá ser aceito ou não. A decisão deverá ser tomada de forma a não comprometer os fluxos previamente aceitos pelo roteador. O controle de admissão é evocado em cada ponto para fazer uma decisão simples: aceitar ou rejeitar, no momento que a requisição do fluxo chega a esse ponto.

O ALTQ implementou uma das formas mais simples de controle de admissão. Caso a nova requisição tenha uma largura de banda que possa ser servida, esta será aceita; caso contrário, descartada.

CLASSIFICADOR DE PACOTES

A discussão acima sobre escalonamento e controle de admissão presumem que os pacotes de uma sessão foram classificados de acordo com algum critério de reserva.

No caso de existir um outro fluxo com a mesma classificação, estes, caso o estilo da reserva permita, serão unidos; ou esta nova seqüência de pacotes deverá ser tratada de forma específica. Um pré-requisito faz-se necessário então: uma forma de classificação dos pacotes. A seleção é feita, geralmente, olhando-se exclusivamente o endereço de destino dos pacotes. Com a introdução de requisitos de QoS, maiores informações são necessárias para a realização dessa tarefa.

Em uma rede que implementa circuitos virtuais, a QoS do fluxo é conhecida no momento do estabelecimento da conexão. Todos os pacotes subseqüentes deste fluxo serão identificados pelo número do circuito virtual, o que torna mais fácil a classificação dos pacotes. Outro método, é permitir ao módulo classificador identificar mais campos da área de cabeçalho dos pacotes, tais como endereço da fonte, porta e número do protocolo. Uma determinada seqüência de vídeo, por exemplo, poderia ser reconhecida por uma porta particular. Aprofundando tal busca, poderíamos obter um método onde seria possível permitir a investigação mais rigorosa dos pacotes, talvez até a área de dados, a fim de identificar alguma característica da aplicação.

Conclusão

O presente artigo fez um estudo mais aprofundado sobre o gerenciador de recursos RSVP, recomendado como padrão para a utilização na Internet pelo IETF.

Embora o surgimento do RSVP tenha vindo atender uma necessidade na proposta de serviços integrados para redes de pacotes (ISPN), sua utilização através de Serviços Diferenciados também é estudada[10], razão da importância do entendimento do protocolo.

Juntamente com a descrição do módulo de gerenciamento que atua na camada de Internet, também uma descrição do módulo de controle de tráfego foi incluída, ressaltando a importância de sua atuação para a obtenção de prioridades diferenciadas para os tráfegos de aplicações multimídia.

Referências bibliográficas

[1] R. Braden, D. Clark, S. Shenker, Integrated Services in the Internet Architecture: an Overview, RFC 1633, julho 1994.

[2]L. Zhang, S. Deering, D. Estrin, S. Shenker, D. Zappala, ``RSVP: A New Resource ReSerVation Protocol'', IEEE Network, pp. 8-17, setembro 1993.

[3] B. Braden, L. Zhang, S. Berson, S. Herzog, S. Jamin, Resource ReSerVation Protocol - Version 1 Functional Specification, setembro 1997, http://www.isi.edu/div7/rsvp/rsvp.html .

[4] J. Wroclawski, The use of RSVP with IETF Integrated Services, Internet-Draft, outubro 1996.

[5] D. Clark, ``The Design Philosophy of the DARPA Internet Protocols'', Proceedings of ACM SIGCOMM' 88, agosto 1988.

[6] S.Floyd, V. Jacobson, ``Link-sharing and Resource Management Models for Packet Network'', IEEE/ACM Transactions on Networking, vol. 3 No. 4, agosto 1995.

[7] K. Cho, ``A Framework for Alternate Queueing: Towards Traffic Management by PC-UNIX Based Routers'', Proceedings of USENIX 1998, Annual Conference, New Orleans LA, June 1998.

[8] K. Cho, ALTQ - TIPS.txt, draft contido no pacote ALTQv.1.1.3.

[9] H. Zhang, ``Services Disciplines for Guaranteed Performance Service in Packet-Switching Networks'', Proceedings of the IEEE, 83(10), outubro 1995.

[10] S. Berson e S. Vincent, ``Aggregation of Internet Integrated Services State'', Procceedings of JWQoS, Maio 1998.

[11] Ana L.P.Schmidt. ``Análise de Qualidade de Serviço para Aplicações de Tempo Real Utilizando Reserva de Recursos na Internet'', Tese de Mestrado, UFRJ, Setembro 1999.

Sites relacionados

IP QoS Page: http://qos.ittc.ukans.edu/

Class-Based Queueing (CBQ): http://www.aciri.org/floyd/cbq.html

ALTQ: http://www.csl.sony.co.jp/person/kjc/programs.html

Testes usando CBQ: http://corn.eos.nasa.gov/notebooks/ip-0007.html