ERRADO.

O protocolo RSVP (Resource Reservation Protocol) foi projetado para fornecer Qualidade de Serviço (QoS) em redes IP, permitindo que as aplicações reservem recursos de rede para garantir um nível de desempenho específico. No entanto, o RSVP enfrenta problemas de escalabilidade em redes com muitos nós devido à necessidade de manter estados de reserva de recursos em cada nó da rede. Protocolos mais modernos, como o DiffServ (Differentiated Services), foram desenvolvidos para superar esses desafios de escalabilidade.

O protocolo RSVP (Resource Reservation Protocol) é um protocolo de comunicação digital que permite a reserva de recursos em uma rede. Ele é usado para estabelecer e manter a qualidade de serviço (QoS) para fluxos de dados. 

• O RSVP é usado por roteadores e hosts para: 
• Fazer reservas de recursos para fluxos de dados
• Solicitar ou entregar níveis de QoS
• Definir como os aplicativos podem reservar e liberar recursos
• Otimizar o uso da largura de banda
• Evitar congestionamento
• O RSVP é compatível com os protocolos de roteamento IPv4 e IPv6. Ele pode ser usado em conjunto com o ATM e é uma solução para aplicações multimídia. 

O RSVP é ideal para redes pequenas ou aplicações críticas, pois garante reserva de recursos. Mas não escala bem para redes grandes.

O DiffServ é a melhor escolha para redes de grande escala, pois classifica pacotes sem exigir reserva de recursos individuais, garantindo maior escalabilidade.

JUSTIFICATIVA CESPE - Errado. O RSVP tem muitas limitações que evitam que ele seja usado universalmente na Internet. Em um cenário de pior caso para redes que usem o RSVP, um roteador de núcleo deve gerenciar milhares de reservas RSVP e enfileirar cada fluxo de acordo com aquela reserva. Os problemas de escalabilidade que cercam o RSVP o relegam às fronteiras da rede e forçam o uso de outras ferramentas de QoS no núcleo da rede.

-O que é o RSVP?

• RSVP (Resource Reservation Protocol) é um protocolo de sinalização.
• Foi projetado para reservar recursos em uma rede IP, garantindo Qualidade de Serviço (QoS).
• Ele permite que aplicações solicitem largura de banda garantida, atraso máximo, etc., antes de enviar os dados.

-RSVP e Escalabilidade:

• Embora o RSVP seja útil para garantir QoS, ele não escala bem em redes com muitos nós e fluxos simultâneos.
• Isso acontece porque ele exige que cada roteador no caminho mantenha estado de sessão para cada fluxo de dados — o que sobrecarrega a rede à medida que o número de sessões aumenta.
• Por isso, o RSVP é considerado pouco escalável e não é adequado para ambientes com altíssima densidade de tráfego e nós (como a Internet pública).

-Conclusão:

A afirmação está errada porque o RSVP não resolve o problema da escalabilidade. Na verdade, ele introduz problemas de escalabilidade devido à sua necessidade de manter o estado de cada fluxo de dados nos roteadores.

Exemplos de questões do Cebraspe (ADAPTADA) sobre o protocolo RSVP e Qualidade de Serviço (QoS), com comentários para entender como a banca cobra esse assunto:

1- O protocolo RSVP é utilizado para sinalizar a necessidade de reserva de recursos para fluxos de dados em redes IP e, por isso, é considerado adequado para ambientes de alta escalabilidade.

Gabarito: Errado

Comentário: RSVP realiza reserva de recursos para cada fluxo, o que implica manutenção de estado em cada roteador do caminho. Isso prejudica a escalabilidade, não o contrário.

2- O protocolo RSVP trabalha em conjunto com mecanismos de QoS para garantir parâmetros como largura de banda e atraso máximo em redes IP.

Gabarito: Certo

Comentário: Correto. O RSVP é um protocolo de sinalização, usado para solicitar QoS (como delay, jitter e banda garantida) entre origem e destino.

3- Em redes IP, a QoS pode ser implementada por meio de modelos como IntServ, que utiliza o RSVP para sinalização e reserva de recursos.

Gabarito: Certo

Comentário: Exato. O modelo Integrated Services (IntServ) usa o RSVP para garantir QoS fim a fim, com reservas explícitas de recursos para cada fluxo.

RESUMO:

• RSVP = protocolo de sinalização para reserva de recursos.
• Funciona com o modelo IntServ.
• Problema: exige estado por fluxo → baixa escalabilidade.
• Alternativa mais escalável: DiffServ, que trata pacotes por classes, sem estado por fluxo.

Fonte: Chatgpt