Achim Greser: Der Führer privat

Num framework para serviços integrados [Wroclawski97, ShenkerI97, ShenkerII97, ShenkerIII97] a primeira função é fornecida pelos serviços de controlo da qualidade de serviço. A segunda função pode ser provida de várias maneiras, mas é frequentemente implementada por um protocolo de reserva de recursos como o RSVP [Braden97]. A reserva de recursos demonstrou ser uma solução válida para prover com QoS o tráfego multicast [Fourmaux98]. Em [Pullen99] pode encontrar-se um modelo de simulação com RSVP para tráfego multicast.

O RSVP foi projectado para ser usado com uma grande variedade de controlos de qualidade de serviços [Mankin97], e estas funções de controlo são desenvolvidas para serem usadas por uma grande variedade de mecanismos de configuração, associados às várias plataformas existentes (sistemas operativos e máquinas de arquitecturas específicas), devido a isto existe uma separação lógica entre as duas especificações. O RSVP adequa-se igualmente às comunicações multicast.

Quando diferentes membros do mesmo grupo multicast se filiam, nem todos dispõem das mesmas condições de acesso, pelo que nem todos poderão ser servidos com a mesma QoS [Wittman01]. Deste modo é incontornável o processo de multicast heterogéneo, onde cada receptor poderá requerer individualmente uma QoS determinada. Reforce-se que o RSVP está focalizado na sinalização, ou seja não providencia data streams heterogéneas. Se a solução passasse por aí então teríamos de recorrer a redes activas [Wittman98].

O esquema da Figura 21 pretende representar as componentes do processo de reserva de recursos para um grupo multicast heterogéneo.

A responsabilidade de modelar a quantidade de informação para cada receptor, mediante as suas limitações estará a cargo dos routers intermediários, assim será possível que um membro do grupo receba 5 fps enquanto que outro recebe da mesma sessão 25 fps.

5.5.1.1 Funcionamento do protocolo RSVP

O RSVP provê um procedimento, iniciado pelo receptor, para a reserva de recursos para um fluxo de dados com vários destinos (multicast) ou com apenas um destino (unicast). Este protocolo é usado para requerer uma qualidade de serviço específica, de uma rede de computadores, para o fluxo de dados de uma aplicação particular. O RSVP também é usado pelos encaminhadores para atender a pedidos de qualidade de serviço em todos os nodos que compõem caminho do fluxo, estabelecendo e mantendo este estado. Os pedidos RSVP vão desencadear uma negociação com cada nodo que faz parte do caminho dos dados, para que os recursos necessários sejam devidamente reservados.

A reserva de QoS é feita na ordem reversa [Liu98], ou seja, dos receptores ao transmissor. Essa solicitação de reserva repete-se até que chegue ao transmissor ou encontre um router com as mesmas necessidades. Tais reservas são implementadas através de dois tipos de mensagens: PATH e RESV (ver Figura 21).

• PATH: mensagens enviadas periodicamente pelo transmissor ao endereço

multicast. Contém a especificação de fluxo (formato de dados, endereço fonte,

porta fonte) e características de tráfego. Essa informação é utilizada pelos receptores para determinar o caminho de retorno ao transmissor e determinar quais os recursos que devem ser reservados. Os receptores devem pertencer ao grupo multicast a fim de receber mensagens PATH;

• RESV: mensagens geradas pelos receptores contendo parâmetros de reserva, como especificação de fluxo e de filtro. O filtro determina que pacotes no fluxo de dados devem ser usados no classificador de pacotes. A especificação de fluxo é usada no escalonador, que procura satisfazer a necessidade do receptor.

O RSVP precisa da cooperação de outros protocolos para funcionar, um desses protocolos é o RTP (Real Time Protocol) (ver Anexo I), orientado ao transporte de tráfego multimédia.

Em resumo, o RSVP tem os seguintes atributos:

Ÿ faz reserva de recursos quer para , fluxos unicast e aplicações multicast; Ÿ é simplex, i.e., só faz reservas para o fluxo de dados numa direcção;

Ÿ o RSVP é orientado ao receptor, pois é este que inicia e mantêm a reserva de recursos usadas por um determinado fluxo;

Ÿ mantém um soft-state (estado que carece de actualização frequente) nos routers e demais máquinas da rede, provendo suporte para mudanças dinâmicas nos membros de um grupo multicast e adaptação automática a mudanças na estrutura de routing;

Ÿ o RSVP não é um protocolo de encaminhamento, depende dos protocolos de

routing actuais (ver Anexo I), suporta endereçamentos IPv4 e IPv6;

Ÿ o RSVP transporta e mantêm parâmetros de controlo de tráfego e controlo de segurança na forma de "dados opacos" (inacessíveis);

Ÿ provê uma série de modelos ou estilos de reservas para atender a uma grande variedade de aplicações;

Ÿ provê um operação transparente através de routers que não o suportem;

Ÿ possui escalabilidade limitada, a solução pode passar por agregação de reservas (RFC 3175).

5.5.1.2 Estabelecimento de sessões multicast com RSVP

Ao nível de aplicação, uma sessão de cooperação está associada à utilização de um dado media. No caso dos dispositivos de informação utilizarem fluxos hierárquicos, à sessão de cooperação vão corresponder tantas sessões de transferência de informação quantos os sub-fluxos que constituem o fluxo hierárquico. Cada sessão de transferência é identificada por um endereço multicast X (identificador da sessão de cooperação) e por um porto de valor par Y.

Ao nível do sistema de comunicações, por cada sessão de transferência têm de ser estabelecidas:

Ÿ uma sessão RTP, constituída por uma parte de dados e uma de controlo. A sessão RTP é identificada pelo mesmo endereço multicast(X) + porto(Y) que lhe é passado pelo interface, sendo este endereço atribuído à transferência de dados. A transferência de informação de controlo é identificada pelo mesmo endereço

multicast e pela porta com o número ímpar Y+1.

Ÿ duas sessões RSVP, uma referente à reserva dos recursos necessários à transmissão dos dados (multicast(X) + porto(Y)) e outra referente à reserva de recursos de controlo (multicast(X) + porto(Y+1)). A qualidade do serviço associada a uma sessão de dados é fornecida pela aplicação. No que se refere à sessão de controlo, esta apenas apresenta requisitos de qualidade referentes à largura de banda a disponibilizar para a transferência de dados de controlo.

No caso de uma videoconferência multicast, deverão ser criadas duas sessões RTP (áudio+vídeo), e para cada uma delas, mais duas sessões RSVP [Mendes98] (ver Figura 22).

Figura 22 - Relação entre os conceitos de sessão [Mendes98].

Suportar um elevado número de reservas RSVP, ou sessões, pode significar um impacto negativo no desempenho dos routers [Ferguson98], portanto, a escalabilidade vê-se afectada. Consequentemente, na maioria das aplicações que requerem QoS, tem

de haver uma solução de compromisso na utilização dos recursos com mecanismos de obtenção de QoS.

São necessários mecanismos de segurança para verificar quem vai ter acesso ao serviço "de primeira classe", e no caso de conflito de requisitos, quem obterá os recursos? Como serão estabelecidas prioridades? Quem controlará este esquema? O RSVP ainda está em desenvolvimento para dar respostas a estas e outras questões.

Complementos e extensões do RSVP podem ser consultados nos RFCs: 2206, 2207, 2210, 2745 e 2746.