Aiuba João Momade Omar

Momed Sujai Caimo

Ndaikeza Fabrice

Protocolos de Reserva e de Recursos

Universidade Rovuma

Campus de Nacala-Porto

2021
 Aiuba João Momade Omar

Momed Sujai Caimo

Ndaikeza Fabrice

Protocolos de Reserva e de Recursos

Trabalho de pesquisa de carácter avaliativo na

cadeira de Redes Multisserviço no curso de
Licenciatura em Informática-Redes a ser entregue
ao departamento de Turismo. Lecionada pelo
decente: Celestino Rapouso

Universidade Rovuma

Campus de Nacala-Porto

2021
Indices
1. Introdução................................................................................................................................. 4

2. Protocolo de Reserva de Recursos ........................................................................................... 5

2.1. RSVP Principais características ........................................................................................ 5

2.2. Modelo de reserva de recursos – Análise ......................................................................... 6

2.3. Reserva de recursos – Descrição....................................................................................... 6

2.3.1. Exemplo de reserva de recurso .................................................................................. 7

2.4. Parâmetros de tráfego e de QoS – FlowSpec .................................................................... 8

2.5. Controlled-Load Servic..................................................................................................... 9

2.6. Guaranteed Service (Serviço Garantido) .......................................................................... 9

2.7. Análise do modelo .......................................................................................................... 10

2.8. IntServ e outros modelos ................................................................................................ 11

3. Conclusão ............................................................................................................................... 12

4. Bibliografia............................................................................................................................. 13
 1. Introdução

O presente trabalho que tem como tema Protocolos de Reserva e de Recursos (RSVP) é um
componente chefe de um novo tipo de Internet sendo desenvolvido, conhecido como serviço
integrado de Internet (Internet Integrated Service). A ideia geral é aprimorar a Internet para
suportar transmissão de dados em tempo real. O RSVP é um protocolo de sinalização do nível de
transporte para reservar recursos das redes IP não fiáveis.

Um protocolo de sinalização é utilizado pelas aplicações (hosts) para informar ou solicitar à rede
sua necessidade de qualidade de serviço (QoS). Na internet e outras redes, QoS é a conceito de
que taxas de transmissão, taxas de erros e outras características podem ser medidas, melhoradas
e, até certo ponto, garantidas com antecedência. Além disso, os protocolos de sinalização
permitem também que os equipamentos de rede (Roteadores) possam trocar informações no
sentido de cooperarem visando a garantia da qualidade de serviço aceita pela rede.

O presente trabalho apresenta a seguinte estrutura de elaboração de um trabalho de pesquisa, de

acordo com as regras de elaboração, introdução, desenvolvimento, conclusão e referências
bibliográficas.
 2. Protocolo de Reserva de Recursos
O RSVP foi proposto em 1993 e adoptado como protocolo de reserva de recursos na arquitectura
de Serviços Integrados (RFC 2205). É também usado na arquitectura DiffServ, na negociação de
contratos entre clientes e fornecedores de serviços (SLA – Service Level Agreement). É usado,
com extensões, na arquitetura MPLS para distribuição de etiquetas (labels) associadas a LSPs e
para estabelecer rotas explícitas sujeitas a restrições.

O RSVP é um protocolo de sinalização usado por emissores, receptores e routers para reservar
recursos na rede e para manter a informação de estado associada.

O RSVP permite a reserva de recursos em cada nó da rede mas não realiza funções de
Encaminhamento, Controlo de Admissão ou Escalonamento de Pacotes, implementados por
outros componentes da arquitetura. Os pedidos de reserva de recursos têm de ser validados face
aos recursos disponíveis (Controlo de Admissão) e permissões de carácter administrativo (Policy
Control) (Ruela, 2005-06)

2.1. RSVP Principais características

 É um protocolo de sinalização:
 Não é um protocolo de encaminhamento, mas interactua com protocolos de
encaminhamento
 Pode necessitar de um protocolo de encaminhamento que descubra rotas sujeitas a
restrições de QoS.
 Foi concebido para aplicações multicast, sendo unicast um caso particular» A reserva de
recursos é da iniciativa dos receptores (receiver initiated);
 A reserva é realizada por fluxo (isto é, a rede não agrega os fluxos que lhe são
submetidos para efeito de reserva e atribuição de recursos no seu interior) e tem um
carácter temporário;
 A sinalização (reserva de recursos) é feita para fluxos unidireccionais (simplex);
 Transporta parâmetros relativos a QoS e políticas (FlowSpec, FilterSpec):
 Não impõe qualquer tipo de política administrativa ou de controlo de admissão
  Permite configurar os classificadores de pacotes, mas não realiza escalonamento
(Ruela, 2005-06)

2.2. Modelo de reserva de recursos – Análise

 A reserva de recursos é da iniciativa do (s) receptor (es):

 Esta opção foi determinada pela necessidade de suportar aplicações multicast e

receptores heterogéneos, que podem ter capacidades e portanto requisitos
diferentes
 Nestas condições, a reserva de recursos iniciada pelo(s) receptor(es) é mais
facilmente escalável do que reservas iniciadas pelo emissor
 A reserva é unidirecional e por fluxo
 Requer que cada router no percurso de dados mantenha informação do estado das
reservas por fluxo

 O modelo de reserva é do tipo soft state

 As reservas são mantidas temporariamente, sendo eliminadas se não forem

refrescadas (actualizadas) regularmente pelos receptores (por exemplo, a
intervalos de 30 s)
 Este modelo (soft state) é mais robusto do que o modelo usado em ATM, que é do
tipo hard state, uma vez que não é necessário remover explicitamente as reservas

 A sinalização é realizada em dois passos (Ruela, 2005-06)

2.3. Reserva de recursos – Descrição

Os emissores enviam periodicamente mensagens PATH, com endereços unicast ou multicast, as

mensagens PATH incluem um TSpec e um Sender Template (que contém o formato dos dados e
o endereço e a porta de origem) para fornecer aos receptores informação sobre as características
do tráfego e do (s) emissor (es), possibilitando assim reservas compatíveis com a natureza do
emissor e os requisitos a satisfazer – São usadas para a descoberta de rotas e para instalação nos
routers de informação de estado relativa a rotas (o que permite que as mensagens de reserva
sejam enviadas pelo mesmo percurso, em sentido inverso)

Os receptores solicitam a reserva de recursos em mensagens RESV, enviadas pelo percurso

inverso do das mensagens PATH:

 As mensagens RESV incluem um Flow Descriptor (FlowSpec e Filter Spec)

 O FlowSpec é constituído por um TSpec, idêntico ao do emissor, e por um RSpec
 O FilterSpec (idêntico ao Sender Template) inclui informação para configurar os
classificadores de pacotes
 As reservas sinalizadas por múltiplos receptores de uma mesma sessão pode ser agregada
(consolidada) nos routers intermédios até ao emissor.

RSVP – Sinalização em dois passos

(Ruela, 2005-06)

2.3.1. Exemplo de reserva de recurso

 Os receptores associam-se previamente a uma sessão multicast (cujo endereço é

divulgado)
 As mensagens Caminho propagam-se na árvore multicast mantida pelos routers
 As reservas solicitadas pelos receptores são independentes (podendo ser diferentes, de
acordo com as características e os requisitos de cada um) e propagam-se em sentido
inverso na árvore
 Cada router deverá consolidar as reservas recebidas nos ramos, considerando o valor mais
elevado para o troço seguinte no percurso até ao emissor

(Ruela, 2005-06)

2.4. Parâmetros de tráfego e de QoS – FlowSpec

 O FlowSpec contém informação que caracteriza o tráfego a submeter à rede (TSpec) e o

serviço pretendido com QoS associada (RSpec) e é usado para reservar recursos e
parameterizar os escalonadores
 TSpec inclui os seguintes parâmetros:

 p – peak rate
 r – token bucket rate
 b – bucket size
 M – maximum datagram size
 m – minimum policed unit
  RSpec é apenas especificado para o serviço Garantido e inclui:

 R – service rate (deve ser superior ou igual a r)

 S – delay slack; representa o atraso adicional aceitável, relativamente ao que seria
obtido com reserva igual a R; S = 0 significa que deve ser reservada largura de
banda igual a R, enquanto S> 0 significa que pode ser reservada uma largura de
banda inferior a R que cumpra o atraso tolerado. (Ruela, 2005-06)

2.5. Controlled-Load Servic

Aplicações que se adaptam a perdas ou atrasos ocasionais têm um desempenho aceitável mesmo
quando usam um serviço best effort, desde que não ocorra congestionamento. O objectivo do
Serviço de Carga Controlada é emular o serviço best effort que se obteria numa rede pouco
carregada, isto é, o desempenho deve ser praticamente independente da carga, não se
deteriorando de forma percetível com o aumento da carga.

Esta caracterização é intencionalmente imprecisa e significa que este serviço não oferece
garantias quantitativas firmes, mas apenas que – uma percentagem muito elevada de pacotes é
entregue com sucesso – o atraso sofrido pela maior parte dos pacotes submetidos em
conformidade com o contrato (TSpec) não excede de forma significativa o atraso mínimo que se
obteria com a rede pouco carregada.

O emissor especifica um TSpec (não é necessário indicar o peak rate), não sendo especificado um
RSpec; a rede limita a quantidade máxima de tráfego deste tipo (Controlo de Admissão) e
escalona-o numa classe separada.

A rede verifica a conformidade do tráfego caracterizado pelo TSpec; tráfego não conforme é
enviado como best effort. (Ruela, 2005-06)

2.6. Guaranteed Service (Serviço Garantido)

O Serviço Garantido oferece garantias estritas para aplicações com requisitos de tempo real:
Largura de banda garantida, atraso extremo-a-extremo majorado (e controlado passo a passo);
não é especificado pelo utilizador, mas pelo serviço no momento em que é invocado, ausência de
perdas de pacotes conformes nas filas de espera dos routers. Os recursos são reservados por
fluxo, com base num Flowspec (TSpec e RSpec); se o pedido for aceite, cada router ao longo do
percurso reserva uma largura de banda R e um número de buffers B para o fluxo

Os valores Ctot e Dtot representam a soma de termos C e D que devem ser considerados em cada
router ao longo do percurso e que dependem, entre outros, do algoritmo de escalonamento, da
largura de banda e do atraso de propagação da ligação física com o próximo router e do tamanho
máximo dos pacotes do fluxo. (Ruela, 2005-06)

2.7. Análise do modelo

As principais vantagens apontadas ao modelo IntServ, por comparação com o modelo de QoS
ATM, são a robustez (soft state) e a escalabilidade do mecanismo de reserva de recursos (iniciada
pelos receptores).

As reservas iniciadas pelo (s) receptor(es) têm algumas limitações: Requerem instalação e
manutenção de informação sobre rotas nos routers, As reservas são unidirecionais, o que obriga a
duplicar os procedimentos no caso de serviços com tráfego bidirecional, e requrem dois passos.

Para além disso, o modelo tem limitações de escalabilidade, que põem em causa a sua viabilidade
em redes de grande dimensão, devido ao facto de a reserva de recursos ser temporária e orientada
a fluxos individuais:

 É necessário processar um elevado número de mensagens de sinalização e manter em

cada router informação de estado por fluxo e realizar o seu refrescamento periódico,
 É necessário Classificar, Policiar e Escalonar pacotes por fluxo e invocar Controlo de
Admissão de cada vez que é feito um pedido de reserva de recursos – O tráfego de
sinalização pode consumir recursos de transmissão significativos

O modelo de Serviços Diferenciados (DiffServ), baseado em princípios diferentes dos adoptados

no modelo IntServ, procura ultrapassar algumas destas limitações. (e, 2000)
 2.8. IntServ e outros modelos
O modelo IntServ (associado ao protocolo RSVP) foi desenvolvido para providenciar garantias
de QoS extremo-a-extremo assumindo uma arquitectura homogénea de QoS (modelo single-tier).
A necessidade de suportar QoS através de múltiplas redes independentes, baseadas em diferentes
tecnologias e modelos de QoS requer a distinção entre sinalização no mesmo domínio e entre
domínios (modelo two-tier) – Um exemplo é o suporte de IntServ sobre DiffServ (IntServ over
DiffServ). Mais do que soluções alternativas, os modelos IntServ e DiffServ podem ser vistos
como complementares, com âmbitos de aplicação específicos.

Foram propostas soluções alternativas ou extensões ao RSVP para ultrapassar algumas das
limitações identificadas – Protocolos baseados em reservas iniciadas pelo emissor – Agregação
de reservas (Aggregate RSVP), com aplicação em IntServ over DiffServ. Actualmente está em
discussão no IETF um novo modelo de sinalização designado por NSIS (Next Steps in Signaling)
adequado para os novos cenários de redes de comunicação de 4ª Geração (4G). (e, 2000)
 3. Conclusão

Com término de trabalho tivemos conclusão de que os protocolos de reserva tem grande
importância e também tem as suas desvantagens (elevada de informação de estado nos nós),
alterando o cenário normal de desatribuição de recursos pelos utilizadores e aplicações.

Portanto ele usa técnicas intermediárias de diferenciação de trafego como prioridades,

codificações hierárquica. Onde em casos de congestão a informação básica terá mais hipóteses de
alcançar os receptores, e congestão de pacotes os prioritários são eliminados não prejudicial.
 4. Bibliografia
e, M. R. (24 de Novembro de 2000). UFPR. Obtido de
http://www.cricte2004.eletrica.ufpr.br/edu/anterior/cd00/trab/rsvp/
Ruela, J. (2005-06). Qualidade de servico em Redes IP. Rio de Janeiro.

RSVP Resource ReserVation Protocol. Nortel Networks. Disponível em:

www3.nortelnetworks.com/WhitePapers/rsvp/wprsvpte.htm.