Para haver garantia de qualidade de serviço, é necessário um protocolo que permita a
reserva de recursos na Rede. Por recurso, no estudo de redes de computadores, entendem-
se largura disponível de banda e tamanho do buffer dos roteadores. RSVP, apesar de
remeter ao famoso Répondez S'il Vous Plaît, significa Resource Reservation Protocol, também
chamado de protocolo de sinalização, e é um protocolo criado para atender os objetivos
citados logo acima.
Paradigmas
Uma observação se faz necessária: para implementar o RSVP, deve haver um software
RSVP rodando em cada um dos receptores, remetentes e roteadores da rede.
É importante ressaltar que o RSVP não determina ou indica como a rede deve fornecer a
largura de banda demandada; ele somente permite a declaração da reserva, por parte das
aplicações.
Um terceiro ponto a se considerar é o fato de que o RSVP não é um protocolo de
roteamento – ele não determina caminhos para os pacotes. Por esse motivo, o RSVP deve
agir em conjunção o com um protocolo de roteamento que indique o caminho entre
roteadores.
Funcionamento
Os receptores enviam uma mensagem de reserva à árvore multicast no sentido
ascendente (das folhas para a raiz), especificando a taxa de transmissão desejada para os
pacotes provenientes da fonte. Quando um roteador recebe a mensagem, se regula para
atender aquela solicitação, e repassa a mensagem de reserva para o próximo roteador na
corrente ascendente.
A mensagem de reserva deve ser respondida, porém. Caso os enlaces descendentes da
árvore multicast não suportarem a banda reservada, o roteador deve negar a reserva,
enviando uma mensagem de erro aos receptores. Esse processo é chamado de teste de
aceitação. Apesar do mencionado acima, o protocolo RSVP não é o responsável por guiar tais
testes, porém, parte do pressuposto que os roteadores da rede podem realizar esse tipo de
teste, e está preparado para lidar com essa feature também.
As mensagens RSVP são carregadas sobre o protocolo IP. Em outras palavras, a mensagem
é posicionada no campo de informação do datagrama IP.
MPLS e RSVP
E o que isso tem a ver com MPLS? Vamos supor que os roteadores suportem tanto o RSVP
quanto o MPLS. Poderíamos então associar fluxos de RSVP a rótulos. Para isso, os rótulos
serão atribuídos pelo próprio protocolo RSVP.
O funcionamento é o seguinte: a mensagem “Path” do RSVP é incrementada do objeto
LABEL_REQUEST, que após ser carregado até o destino, é respondido pelo incremento LABEL
que será feito a mensagem “Resv”. Assim o pedido de rótulos é feito do emissor ao receptor,
e os rótulos são efetivamente atribuídos no sentido receptor- >emissor (conforme explicado
na seção Arquitetura)
Para conseguir integrar as características de QoS, possibilitadas pelas rotas explícitas do
MPLS, ao RSVP, é adicionado ao “Path” o objeto EXPLICIT_ROUTE. Tal objeto é constituído
pelo caminho previamente calculado, devido as requisitos de QoS, direcionando “Path” e
alocando os rótulos.
Dessa forma, com a combinação de RSVP e MPLS, é possível ter um grande controle da
qualidade de serviço, já que os LSPs feitos pela rede terão também acesso aos benefícios
provenientes da capacidade de reserva do protocolo RSVP.
Desvantagens
Apesar de todos os benefícios, o RSVP não foi universalmente adotado. Primeiro
porque exigia que cada roteador no caminho suportasse os mecanismos RSVP de sinalização,
e até mesmo uma implementação de fila de prioridades. Em segundo lugar, também exigia
equipamentos nas bordas da rede que pudessem iniciar e responder a pedidos RSVP. No
final das contas, a demanda pelos benefícios que poderiam ser trazidos pelo uso do
protocolo não era grande o suficiente para justificar o update de toda uma infra- estrutura de
hardwares de rede.