Resumo

  • A RFC 2379 recomendou que mensagens de controle RSVP viajassem pelo caminho de dados de melhor esforço já existente, mesmo quando essas mensagens levariam à criação de circuitos virtuais ATM separados com parâmetros de qualidade de serviço.
  • PATH ou RESV, estado RSVP, decisão de admissão, VC configurado e desempenho observado são comprovantes sucessivos; nenhum deles prova sozinho toda a cadeia.

Pedir garantia por um caminho que não a prometia

RSVP servia para solicitar reserva de recursos. ATM podia criar circuitos virtuais com características explícitas de serviço. Ainda assim, a RFC 2379 não exigiu primeiro um canal protegido para a sinalização. Em unicast, as mensagens usariam o VC empregado para alcançar o destino; em multicast, o caminho que já levava tráfego de melhor esforço ao grupo.

A razão era a economia de circuitos. Antes de estabelecer uma sessão e iniciar uma reserva, algum caminho ordinário precisava existir. Reutilizá-lo para controle evitava manter VCs adicionais apenas para pedir outros VCs. O plano de controle, portanto, podia solicitar um serviço mais forte enquanto atravessava um transporte mais fraco.

O texto não transformou melhor esforço em garantia por definição. Admitiu que um VC desse tipo talvez não oferecesse toda a confiabilidade desejada pelo RSVP. A tolerância vinha da forma temporal do protocolo: as reservas eram estado temporário, renovado periodicamente. A perda de um pacote não precisava eliminar a sincronização, pois uma atualização posterior poderia conservar ou reconstruir o estado.

Isso não tornava a perda irrelevante. O significado de uma mensagem perdida dependia das atualizações seguintes, da expiração, da admissão e da sobrevivência do circuito. Do mesmo modo, uma mensagem enviada não provava que a reserva já existia. A confiabilidade pertencia ao processo no tempo.

Uma reserva, um VC independente

ATM favorecia agregação. Em teoria, várias sessões RSVP poderiam compartilhar circuitos e economizar recursos. Em 1998, porém, essa agregação ainda era objeto de pesquisa. A recomendação foi usar um VC independente para cada reserva RSVP.

Essa prudência deixava a transformação auditável. Uma sessão RSVP não era um circuito ATM. Era necessário mapear a reserva para parâmetros ATM, decidir a admissão, criar ou escolher o VC e classificar o tráfego. A presença do circuito, por sua vez, ainda não demonstrava que os pacotes tinham recebido o tratamento solicitado.

Os documentos companheiros distribuíram o trabalho. A RFC 2380 definiu requisitos de implementação; a RFC 2381 mapeou os serviços controlled-load e guaranteed de Integrated Services para ATM; a RFC 2382 ofereceu o quadro geral. A divisão impedia que um único sinal representasse o sucesso de todas as etapas.

O atalho herdava o destino

Atalhos ATM podiam atravessar limites de sub-redes IP lógicas, criando caminhos assimétricos para PATH e RESV. A RFC 2379 usou mecanismos RSVP já existentes—o objeto NHOP e o encaminhamento de mensagens que chegassem pela interface errada—para acomodar a assimetria.

A regra mais importante definia quem escolhia o ponto final. Um atalho QoS não deveria descobrir seu destino de forma independente. Se o tráfego de melhor esforço já tivesse criado um atalho, o VC QoS acionado pelo RSVP deveria terminar no mesmo ponto. No modelo recomendado, sem atalho de melhor esforço tampouco haveria atalho QoS entre sub-redes.

Isso não impedia VCs QoS salto a salto. A restrição era de procedência: o contexto de encaminhamento comum fazia a escolha inicial e a construção QoS a seguia. O circuito novo provava uma configuração, não o êxito retroativo da descoberta, da admissão ou da entrega.

Multicast não aceitava uma única forma

Numa sessão multicast, receptores podiam pedir níveis diferentes de QoS ou nenhum. O quadro companheiro descreveu modelos plenamente heterogêneo, heterogêneo limitado, homogêneo e homogêneo modificado. A RFC 2379 não declarou um modelo universal; exigiu pelo menos heterogeneidade limitada ou homogeneidade modificada e preferiu ambos com uma forma de seleção.

Essa cautela também é parte da história. A boa prática não apagou diferenças operacionais para produzir um diagrama limpo. Definiu um mínimo viável e preservou a diversidade dos receptores como algo observável.

Quatro comprovantes diferentes

Uma leitura segura separa quatro registros: o caminho de melhor esforço que transportou controle; o estado RSVP e suas renovações; o resultado de admissão e o VC ATM configurado; e os contadores ou observações da aplicação que revelam o serviço recebido.

PATH enviado não é RESV recebido. RESV não é admissão. VC ativo não é classificação correta. Um rótulo QoS não é medição de atraso, perda ou entrega. A arquitetura ligava essas camadas sem torná-las equivalentes.