Resumo

  • O RFC 1294, Standards Track de janeiro de 1992, descreve encapsulamento multiprotocolo para tráfego roteado e em ponte sobre Frame Relay. Quando há mais de um método, é preciso saber previamente qual circuito virtual carrega qual método, e a técnica só pode ser usada em VC explicitamente configurado.
  • NLPID e SNAP permitem interpretar a PDU recebida. Não configuram o VC, não demonstram acordo entre os extremos e não provam aceitação, encaminhamento, entrega ou resultado de serviço.

O RFC 1294 — Multiprotocol Interconnect over Frame Relay preserva uma diferença que uma leitura apressada de cabeçalhos costuma apagar. Há informação dentro de um quadro para que o destinatário escolha a interpretação da carga. Há também uma decisão anterior que limita qual método de encapsulamento pode ser usado em determinado circuito virtual. A primeira torna uma PDU legível. A segunda é uma condição de operação do VC. Nenhuma nasce automaticamente da outra.

O RFC exige uma moldura Q.922 Annex A e informação que identifique o protocolo ou encapsulamento da PDU. NLPID pode apontar diretamente a um protocolo. Se o protocolo não tem um NLPID próprio, uma forma roteada usa NLPID 0x80, OUI 00-00-00 e o EtherType; para um datagrama IP, pode ser usado NLPID 0xCC. As estações devem aceitar tanto a forma NLPID como a forma SNAP para pacotes roteados.

Isso define a capacidade de leitura. O abstract fixa outra responsabilidade: sistemas capazes de transportar esta e outras encapsulações precisam conhecer previamente quais VC levam cada método, e a encapsulação só deve ser usada sobre VC explicitamente configurados. Um analisador pode reconhecer a etiqueta. Ele não transforma a etiqueta no registro que autorizou o método naquele circuito.

DLCI era referência local, não uma política inteira

Um grupo Frame Relay pode ter malha completa ou parcial. Cada circuito virtual tem um Data Link Connection Identifier em cada interface, e o RFC diz que, na maioria dos casos, o DLCI tem significado estritamente local nessa interface. O número é útil para a relação local sem ser uma identidade global do caminho.

O documento mostra também que o DLCI pode mudar durante a travessia da rede: o valor que o emissor põe no cabeçalho pode não ser o valor que o receptor vê em sua interface. Assim, uma captura com um DLCI estabelece uma observação local e datada. Não estabelece nome do par, atribuição de encapsulamento, política de provedor, configuração vigente nem resultado da comunicação.

Essa distinção é importante para auditoria. Quando um único número de DLCI sobrevive no ticket ou no painel, há a tentação de fazer dele a história de toda a conexão. Faltam pelo menos a interface, a atribuição VC-método, o momento, o estado dos extremos e a observação posterior de processamento. O RFC não entrega esses fatos dentro do número.

O identificador guiava o parser, não concedia acesso ao VC

O valor de controle normal é UI 0x03, salvo negociação diferente. O preenchimento usado para alinhamento deve ser zero. NLPID 0x00 é inválido nesta encapsulação porque não se distingue do preenchimento e não tem significado relevante ali. A etiqueta só cumpre sua função quando sua fronteira estrutural é reconhecível.

Para quadros em ponte, NLPID 0x80 anuncia SNAP; OUI 00-80-C2 identifica o contexto 802.1; e o PID informa a forma do cabeçalho MAC e se o FCS original foi preservado. Esses valores dizem como interpretar o quadro. Não autenticam o quadro original, não garantem que uma ponte encaminhou algo, não demonstram uma política comum nem provam que uma LAN recebeu a carga.

Por isso, “o cabeçalho indicava Ethernet em ponte” não equivale a “Ethernet foi encaminhada”. Tampouco equivale a “este VC era configurado para tal serviço”. A primeira frase trata de formato; a segunda, de uma ação; a terceira, de uma alocação anterior. Usar a primeira como prova das demais torna um campo de despacho em autoridade operacional.

XID negociava um conjunto pequeno de parâmetros

O Exchange Identification opcional, XID, pode negociar na inicialização do circuito N201, T200 e K. Sem XID, esses valores devem ser configurados estaticamente por acordo mútuo dos extremos DLC ou adotar os padrões de Q.922. Uma estação que suporte XID deve responder a um XID recebido; se o máximo remoto for menor, ela reduz antes o máximo usado no DLC local.

XID é um bom exemplo de acordo com objeto nomeado. Ele trata de parâmetros de enlace específicos. Não elimina a regra independente sobre qual encapsulamento pertence a qual VC, nem prova que a PDU posterior foi aceita, roteada ou entregue. A existência de uma troca não é uma procuração para todas as condições vizinhas.

O que importa é a sequência de registros

Uma leitura reproduzível separa interface e DLCI local, atribuição efetiva VC-encapsulamento, acordo XID ou estático, bytes Q.922, decodificação NLPID/SNAP, ação do receptor e evidência posterior. A captura confirma os bytes que ela contém. A política confirma a permissão que registra. Um contador posterior confirma, no máximo, um evento que ele mede. As afirmações não devem saltar de uma coluna para a próxima.

O valor histórico do RFC 1294 está em tornar a multiplexação inteligível sem fingir que inteligibilidade é governo. O quadro pode trazer a chave de leitura. O circuito precisa de uma alocação explícita. O que acontecer depois continua sendo um fato distinto, com evidência própria.

Fontes e limites de evidência

A fonte é RFC 1294 — Multiprotocol Interconnect over Frame Relay. Ela sustenta o status de janeiro de 1992, a configuração explícita, a localidade de DLCI, Q.922, NLPID/SNAP, as formas roteada e em ponte e o papel limitado de XID. Não sustenta um VC atual, operadora, par remoto, configuração efetiva, proteção de segurança, encaminhamento, entrega ou resultado de serviço.