RSVP

       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.