Resumo

  • RFC 3020 definiu quatro classes de ativação para um bundle MFR: um enlace, todos, um número configurado ou uma regra específica da implementação.
  • O estado up confirmava que a classe escolhida fora satisfeita; não confirmava capacidade plena, ausência de erro de reordenação nem recebimento útil no destino.

Restava um circuito de quatro. O serviço de supervisão marcou o conjunto como disponível.

Essa conclusão podia estar perfeitamente de acordo com RFC 3020. A classe de ativação A, valor padrão, exigia que pelo menos um bundle link estivesse operacionalmente up. O bundle lógico voltava a subir mesmo que três quartos da infraestrutura permanecessem indisponíveis.

O erro começaria apenas se alguém traduzisse “atingiu o mínimo configurado” como “recuperou o serviço contratado”.

Publicado em dezembro de 2000, RFC 3020 especificou uma MIB para monitorar e controlar Multilink Frame Relay em UNI e NNI. A função descrita por FRF.16 agrupava enlaces físicos, fazia inverse multiplexing de frames e apresentava o bundle à camada Q.922 como uma única interface.

O documento registrou uma verdade que atravessou gerações de tecnologia: a saúde de um agregado depende de quem definiu o mínimo, quais membros entram no cálculo e que resultado o agente decidiu publicar.

O bundle tinha identidade própria

Cada membro físico aparecia na Interface MIB com um ifIndex. O bundle também aparecia, pois era uma interface lógica para a camada superior. A tabela específica de MFR, porém, era indexada por mfrBundleIndex.

O gerente escolhia o índice MFR ao criar a linha; o agente escolhia o ifIndex. Tabelas faziam o mapeamento nos dois sentidos. Guardar apenas um identificador quebrava a ligação entre configuração específica, estado genérico e contadores.

A criação mostrava a mesma divisão. Um SET createAndGo em mfrBundleRowStatus criava o bundle e levava o agente a criar a interface correspondente. A implementação podia oferecer createAndWait. Um membro usava o ifIndex da interface física e precisava apontar para um bundle existente em mfrBundleLinkConfigBundleIndex; sem isso, ficava notReady.

Uma linha ativa era recibo de configuração. Ainda não era recibo de negociação do membro, ativação do agregado ou entrega de frames.

Quatro políticas cabiam no mesmo campo up

mfrBundleActivationClass controlava a ativação.

Na classe A, ao menos um enlace precisava estar up. Na classe B, todos. Na classe C, o número mínimo vinha de mfrBundleThreshold. A classe D era customizada e específica da implementação. A era o padrão.

Para classe C, alcançar o limiar tornava o bundle operacionalmente ativo; cair abaixo o desativava. Quando o limiar não era aplicável, o objeto retornava -1. Na classe D, seu uso dependia do produto.

Os traps do bundle reproduziam esse cálculo. LinkUp acompanhava a transição de ifOperStatus quando havia membros suficientes segundo classe e limiar. LinkDown surgia quando o número passava a ser insuficiente.

Quatro membros ilustram a diferença. Classe A fica verde com um. Classe B continua vermelha com três. Classe C com limiar dois muda o estado no segundo membro; o terceiro e o quarto aumentam capacidade sem alterar o bit. Classe D não pode ser reconstituída sem documentação e versão do código.

Uma série histórica apenas de up/down apaga a política que produziu a série. A evidência completa inclui classe, limiar, membros configurados, membros ativos e época da configuração.

Membro ativo, largura disponível e throughput eram fatos distintos

RFC 3020 publicou separadamente a quantidade configurada e a quantidade ativa de links, além da largura de banda disponível do bundle.

Isso impedia que up fosse sinônimo de população completa. Também impedia, conceitualmente, que largura disponível fosse tratada como throughput obtido. A medida do agente não trazia carga oferecida, janela de observação, congestionamento, retransmissões, confirmação remota ou resultado de aplicação.

O bundle precisava lidar com diferença de atraso e ordem. Por isso a MIB incluía fragmentação, tamanho máximo de fragmento, tamanho de sequência, diferença máxima de delay e round-trip delay por membro.

Conectividade mínima e capacidade comprometida podiam coexistir como dois objetivos. Um único semáforo não era suficiente para ambos.

Um incremento não significava um frame perdido

mfrBundleResequencingErrors contava eventos de erro, não frames. RFC 3020 explicou: se chegassem as sequências 56, 59 e 60 e o receptor julgasse 57 e 58 perdidas, o contador subiria uma unidade.

Logo, um delta de um comprovava um evento registrado, mas podia envolver várias perdas. Um contador estável tampouco comprovava entrega perfeita sem informação sobre reset, wrap, reinício, lacuna de coleta e falhas fora daquele objeto.

Outros contadores por link tratavam de frames de controle inválidos, expiração de timer, suspeita de loopback, sequência inesperada e incompatibilidade de nomes. O estado do membro vinha da máquina de estados FRF.16, não de um simples carrier físico.

O trap de mismatch comparava nomes locais configurados e nomes remotos informados. O próprio RFC observava que valores configurados podiam ter sido produzidos automaticamente. O alerta demonstrava desacordo entre visões, sem decidir sozinho se a causa era local, remota, automática ou obsoleta.

Esses dados podiam provar degradação em um bundle ainda verde. Não provavam o que uma aplicação recebeu.

Relaxar a política podia gerar o próximo linkUp

Classe, limiar, timers, fragmentação e sequência tinham acesso máximo read-create. Linhas de bundle e membro podiam ser criadas, alteradas ou removidas, e o gerente podia escolher a associação do link.

O máximo do schema não obrigava toda implementação a permitir escrita. As regras de conformidade admitiam acesso mínimo read-only para vários objetos, mas exigiam que o valor efetivo fosse reportado. Definição, capacidade implementada e autorização do usuário não eram a mesma evidência.

Onde SET era possível, reduzir o limiar de três para dois mudava a avaliação sem reparar nenhum circuito. O novo up estava certo em relação à nova regra. Um relatório que o chamasse de recuperação física estaria errado.

A seção de segurança advertia que SET desprotegido podia prejudicar operações. SNMPv1, mesmo em rede protegida por IPsec, não controlava quais principais tinham direito de ler, alterar, criar ou excluir objetos. RFC 3020 recomendou USM e VACM do SNMPv3 e atribuiu ao operador a configuração correta.

Autenticação provava a identidade do gerente. Autorização delimitava sua permissão. Nenhuma provava que o limiar servia ao compromisso com o cliente.

Proposed Standard não era censo de uso

RFC 3020 foi publicado como Proposed Standard. RFC 9141 o atualizou somente para substituir referências ao serviço FTP aposentado do IETF. A semântica de ativação permaneceu.

As fontes estabelecem o desenho da MIB, não implantação, suporte de produto, incidente, disponibilidade medida ou entrega comercial. Este texto não faz essas alegações.

Reality Layers, de Lu Heng, separa linha, política, estado dos membros, interface agregada, integridade dos frames e resultado no destino. Running-Code Primacy é indispensável para a classe D, explicitamente definida pela implementação. Minimum Initial Specification explica por que uma superfície limitada podia ser útil sem fingir ser observação fim a fim.

São lentes declaradas. Lu Heng não escreveu nem endossou RFC 3020.

O verde significava: esta regra, aplicada a esta população de links nesta época, retornou suficiente. Capacidade, integridade e resultado começavam em outros recibos.

Fontes