Resumo

  • Compartilhar o VC economizava circuitos e tempo de estabelecimento, mas expunha as atualizações RSVP ao descarte provocado por dados não conformes.
  • Um VC de sinalização separado criava outro contrato de tráfego, não uma garantia de serviço: admissão, transporte, renovação do estado e tratamento dos dados continuavam sendo provas distintas.

A decisão parecia econômica em todas as camadas. RSVP mantinha uma reserva enviando PATH e RESV periodicamente. ATM transportava pacotes em circuitos virtuais sujeitos a contratos de tráfego. Levar o controle junto dos dados dispensava um circuito extra e a espera para estabelecê-lo.

O equilíbrio mudava quando os dados ultrapassavam o contrato. O descarte de tráfego não conforme podia atingir também a mensagem RSVP que renovaria o estado. Perdas ocasionais faziam parte da tolerância do protocolo. Perdas persistentes podiam deixar o estado expirar, remover o VC de QoS e iniciar sua criação de novo. A opção feita para reduzir sinalização podia gerar um ciclo adicional de sinalização.

Estado flexível precisava de chegada dentro do prazo

A RFC 2205 definiu o estado RSVP como soft state. PATH e RESV criavam e atualizavam esse estado; sem atualização correspondente antes do cleanup timeout, ele era apagado. A regra acompanhava rotas e grupos multicast mutáveis e removia registros antigos mesmo sem uma transação de encerramento perfeita.

A repetição tolerava o acidente, não a privação prolongada. Por isso a RFC 2205 recomendava largura de banda mínima para proteger mensagens RSVP contra perdas por congestionamento.

Um registro de envio provava somente a emissão. Ainda era necessário conhecer o VC selecionado, seu contrato, o resultado de admissão, a travessia do segmento ATM, o instante da recepção e o novo vencimento. Um VC podia estar ativo com estado RSVP expirado. O estado podia existir sem um VC de dados admitido. Nenhuma dessas condições, isolada ou em conjunto, provava o resultado na aplicação.

Quatro opções redesenhavam o domínio de falha

A RFC 2382 organizou quatro famílias: controle no mesmo VC dos dados; um VC RSVP paralelo para cada reserva; um VC de sinalização ponto a multiponto compartilhado por sessões com a mesma entrada e o mesmo conjunto de saídas; ou vários VC ponto a ponto multiplexados entre sessões.

O modelo compartilhado reduzia o total de VC e evitava a latência de criar um circuito adicional antes de PATH. Em troca, submetia o controle ao tratamento do VC de dados. A RFC alertou que dados não conformes podiam causar perda de sinalização e que perda excessiva levaria a repetidas desmontagens e reconstruções de VC de QoS.

Usar o caminho best effort separava o controle da não conformidade do VC de QoS, mas não do congestionamento ATM. A RFC 2382 recomendava uma classe preferencial. Priorizar RSVP no escalonador IP antes da entrada em ATM era uma hipótese promissora, porém difícil e ainda aberta a estudo.

O VC dedicado comprava isolamento por meio de um contrato próprio. Mensagens de controle conformes não seriam descartadas pela violação cometida pelos dados no outro circuito. O preço aparecia em dobro no número mínimo de VC, mais sinalização ATM e mais latência de estabelecimento.

Multiplexação exigia contexto histórico

Um VC ponto a multiponto só agrupava naturalmente sessões enquanto entrada e conjunto de saídas fossem idênticos. Mudanças de membros obrigavam a procurar outro VC, criar um novo, modificar o atual ou continuar transmitindo para uma saída que já não precisava do tráfego.

A economia dependia, portanto, da topologia e do padrão real de comunicações. VC ponto a ponto duradouros no núcleo podiam amortizar estabelecimento e aproveitar canais reversos, mas sua quantidade continuava ligada aos nós participantes. Reutilizar um VC best effort economizava mais uma conexão enquanto aumentava a chance de perder mensagens.

O recibo precisava acompanhar a decisão. Em circuito dedicado, mensagem, VC e contrato podiam ser ligados diretamente. Em circuito multiplexado, também eram indispensáveis o mapa de sessões e o conjunto de saídas válido naquele instante. Sem isso, um inventário não revelava quais reservas dependiam da falha.

QoS demais podia impedir o próprio controle

Reservar uma QoS grande para sinalização não era resposta gratuita. Mensagens RSVP eram pouco frequentes, tipicamente a cada trinta segundos; uma alocação relativamente pequena deveria atender. Pedir muito podia fazer o VC de controle ser recusado quando os recursos eram escassos.

O fallback best effort repetia o dilema. Se a chamada QoS falhava porque a rede ATM estava congestionada, a mensagem de fallback atravessaria a mesma rede com proteção menor. A opção de fallback não era recibo de entrega.

A RFC 1755 já buscava evitar connection thrashing na gestão de conexões. A RFC 2382 revelou outro caminho para a instabilidade: perda no transporte de controle, expiração do soft state, desmontagem do serviço e mais trabalho para reconstruí-lo.

Uma cadeia verificável incluía gerar a mensagem, escolher VC e tratamento, admitir o circuito, atravessar ATM, atualizar o estado dentro do prazo, manter o VC de dados e observar o serviço. Uma etapa bem-sucedida não herdava a seguinte.

A RFC 2382 não escolheu uma topologia universal. Ela permitiu comparar compartilhamento, separação e multiplexação sem apagar seus custos e evidências diferentes. O mínimo era que o caminho responsável por manter o estado permanecesse protegido o bastante, observável e ligado de forma honesta ao estado que dizia sustentar.