Resumo

  • O BACP resolvia pedidos simultâneos; o BAP exigia resposta antes da ação; uma indicação separada registrava o resultado da chamada e a intenção de tentar de novo.
  • Request-Ack comprovava comando válido e recebido, não enlace ou tráfego. O datagrama BAP inteiro precisava ficar sem compressão e sem criptografia para a interceptação por adaptadores ISDN.

Há uma diferença operacional entre “pode ligar” e “a linha entrou no bundle”. O RFC 2125 construiu seu controle de banda ao redor dessa diferença.

O RFC 1990 já explicava como vários enlaces PPP transportavam um fluxo Multilink. O RFC 2125 acrescentou BACP e BAP para controlar quantos membros participavam. O registro do RFC Editor e o registro PPP da IANA preservam o status e os números atribuídos.

Um desempate limitado

A opção obrigatória Favored-Peer fazia cada lado negociar um Magic-Number não zero. Se ambos enviassem ao mesmo tempo pedidos da mesma classe, prevalecia o menor valor. Valores iguais eram rejeitados para nova escolha.

O resultado eliminava uma corrida. Não autenticava identidade, não avaliava o algoritmo de utilização e não declarava quem possuía autoridade econômica sobre a linha.

A resposta vinha antes do resultado

Quem pretendia originar o enlace enviava Call-Request; quem queria que o par ligasse enviava Callback-Request. Todo Request ou Indication precisava receber Response antes da ação. Request-Ack aceitava o comando; Request-Nak adiava; Request-Rej indicava falta de suporte; Request-Full-Nak mostrava que o bundle alcançara um limite.

Depois de cada tentativa, o agente enviava Call-Status-Indication. Uma falha registrava se haveria nova tentativa, e cada repetição exigia outro resultado. A indicação usava o Identifier do pedido original. A ligação documental era forte, mas não transformava permissão e execução no mesmo evento.

A sequência verificável era: BACP aberto; desempate; pedido aceito; chamada concluída; entrada ou saída do membro com LCP; fragmentos Multilink observados; efeito de aplicação. Um registro inicial não autorizava afirmar todos os posteriores.

Um enlace podia ser necessário para lados diferentes

O protocolo deixou cada implementação escolher como observar utilização. Quando a remoção vinha dessa medição, era obrigatório consultar o par por Link-Drop-Query. A resposta considerava a observação local e não podia depender apenas do tráfego recebido. O enlace permanecia ativo enquanto qualquer lado que o monitorava ainda precisasse dele.

Se o motivo era um recurso local — por exemplo, liberar porta física ou canal B — a implementação usava diretamente Terminate-Request do LCP. Esgotar as tentativas sem resposta também podia levar à remoção forçada. O desenho separava otimização cooperativa de necessidade física local.

Retransmissões mantinham o mesmo Identifier para que uma resposta perdida não criasse uma operação aparentemente nova. Pacotes BAP deveriam ter prioridade sobre dados: o pedido que aumenta banda pode surgir justamente quando o caminho já está congestionado.

O adaptador precisava ler o controle

Alguns terminais ISDN administravam Multilink para clientes que desconheciam o protocolo. O datagrama BAP inteiro, por isso, não podia ser comprimido nem criptografado. Compressões negociadas de campos PPP continuavam possíveis. A seção de segurança apenas informava que questões de segurança não eram discutidas.

Logo, um BACP aberto, um Ack ou um Call-Status positivo não provam sigilo, identidade, consentimento, estabilidade de banda ou entrega de aplicação.

Os textos de Lu Heng sobre primazia do código em execução, especificação inicial mínima e camadas de realidade são aqui uma lente moderna declarada. O contrato comum pode ser estreito, as heurísticas permanecem locais e permissão simbólica não substitui consequência executada.

Fontes