Resumo

  • PROPOSE e PROPOSE ACK permitiam aos dois vizinhos identificar e testar um Dedicated-VC; somente a troca posterior de OFFER e READY associava a ele um fluxo de endereços IPv4 de origem e destino.
  • A associação podia ser recusada, renovada ou removida. Nenhuma dessas mensagens comprovava entrega ponta a ponta, capacidade permanente, QoS ou benefício econômico.

O espaço entre o ACK e o READY

O roteador a montante escolhia primeiro um Dedicated-VC e enviava nele uma mensagem PROPOSE com um VCID e o endereço IP de destino do vizinho a jusante. O PROPOSE ACK retornava pelo Default-VC, que também servia ao encaminhamento IP convencional salto a salto. A troca dava aos dois nós uma referência comum ao circuito e confirmava que ele e o vizinho funcionavam. Mas não identificava o fluxo que viajaria ali.

Para isso, vinha OFFER pelo Default-VC, trazendo VCID, flow-ID e o intervalo de renovação desejado. O vizinho respondia READY pelo mesmo canal quando aceitava receber aquele fluxo no circuito dedicado. Receber um ACK da primeira etapa, portanto, não antecipava a aceitação da segunda. E enviar a oferta sem obter READY não autorizava a conclusão de que o vizinho estava pronto. O RFC 2129 desenhou uma relação entre pares adjacentes, não uma negociação indivisível de toda a Internet.

O memorando foi publicado como Informational, sem criar um padrão de Internet. No seu exemplo de três roteadores, a negociação entre o segundo e o terceiro ocorria independentemente daquela entre o primeiro e o segundo. O Default-VC preservava o processamento normal de IP; para um fluxo selecionado, o Dedicated-VC permitia a um roteador de comutação de células encaminhar por identificador de conexão de enlace sem reexaminar cada cabeçalho IP. A aceleração em um salto não governava todos os saltos nem substituía uma prova de entrega.

Reservar antes ou esperar pelo sinal

O acionamento do cut-through era uma decisão local, exemplificada por identificadores de porta TCP/UDP para sessões longas ou com muitos pacotes. Um nó podia manter circuitos preparados numa lista de não usados e ativar um rapidamente; isso consumia recursos de VC antes de haver demanda. Ou podia estabelecer um novo circuito por sinalização ATM quando surgisse a necessidade, poupando a reserva ociosa e acrescentando latência de criação. O RFC deixou a escolha ao nó, ponderando recursos e responsividade, sem apresentar um cálculo de poupança observada.

O flow-ID então definido continha apenas endereços IPv4 de origem e destino; não era o flow label de IPv6. O VCID identificava a conexão entre vizinhos mesmo se os valores locais de VPI/VCI diferissem nas pontas. Esses nomes não certificavam a identidade da origem. Fluxos agregados, multicast, sinalização de QoS em IP e IPv6 apareciam como melhorias futuras, não como recursos entregues pelo texto.

Uma associação que precisa continuar merecendo confiança

Uma proposta podia ser recusada por política, tipo de VCID desconhecido ou falta de recursos. Uma oferta ainda podia esbarrar num VCID ou tipo de flow-ID desconhecido, política de fluxo, intervalo de renovação não suportado ou recursos indisponíveis. O montante retransmitia se não houvesse resposta; a recomendação era liberar o circuito após cinco retransmissões sem o retorno esperado. O protocolo não transformava silêncio em permissão.

Quando o circuito recebia pacotes, o vizinho a jusante enviava READY periodicamente. Sem pacotes, deixava de enviá-lo. O montante apagava a associação entre flow-ID e VCID depois de um prazo sem renovação; o jusante também apagava seu estado após um prazo maior sem receber pacotes, inclusive diante de falha silenciosa do outro lado. Os dois, seis e vinte minutos sugeridos no documento eram parâmetros recomendados, não um SLA. REMOVE/REMOVE ACK e a liberação via sinalização ATM eram caminhos adicionais, conforme a configuração da conexão.

Daí a utilidade histórica de distinguir evidências: gatilho, circuito selecionado, ACK, READY e renovação posterior atestam etapas diferentes. Não provam origem autenticada, acordo em todos os saltos, entrega ao destino, capacidade estável, QoS ou retorno financeiro. O RFC 2098 trata da arquitetura de bypass vizinha; o RFC 2129 mostra a reconciliação permanente entre vizinhos de que um atalho depende. A luz acesa numa conexão não substitui o estado que precisa ser mantido.

Fontes