Resumo

  • O RFC 3033 atribuiu significados de Internet ao Generic Identifier da Q.2941 e ao User-to-user Signaling da Q.2957, distinguindo identificadores de sessão, recursos e dados de protocolos de configuração.
  • Um valor correto era insumo de coordenação, não recibo de execução: estabelecer o novo VC, interpretar a chamada, avisar a camada IP e mover a sessão continuavam sendo eventos próprios.

Há um instante em que toda a descrição simbólica está pronta e quase nada do resultado está provado. O SETUP contém a tupla da sessão. O equipamento chamado sabe qual fluxo interessa. Mesmo assim, a conversa pode permanecer multiplexada no VC padrão, porque o novo circuito ainda não foi confirmado e a camada IP ainda não alterou seu estado.

Publicado em janeiro de 2001 como Proposed Standard, o RFC 3033 fez uma atribuição estreita em dois elementos opcionais da sinalização B-ISDN. Chamou essa atribuição de estrutura indispensável para sessões longas e sensíveis a QoS sobre ATM, mas advertiu que ela talvez não especificasse o protocolo completo capaz de produzir interoperabilidade. A distinção entre vocabulário e procedimento era explícita desde o início.

O movimento dependia de uma sequência

No exemplo de sessão longa, o tráfego começa em um VC padrão compartilhado. Um roteador detecta que a sessão persistirá e solicita outro VC. Só depois de o novo VC ser estabelecido com sucesso a sessão deve ser transferida.

No lado chamado, a entidade de sinalização B-ISDN precisa reconhecer que a chamada recebida corresponde a uma sessão de Internet e comunicar esse fato à entidade IP. A mudança é feita pela camada IP. O identificador oferece um referente comum para a conversa entre camadas; não detecta o fluxo, não estabelece a chamada, não entrega a notificação e não reprograma o encaminhamento.

Assim, “identificador recebido”, “VC estabelecido”, “sessão movida” e “pacotes observados no novo caminho” são evidências diferentes. Um painel que avance diretamente do primeiro ao último transforma um nome em autoridade operacional.

Identificador e informação do usuário tinham recipientes distintos

O Generic Identifier da Q.2941 servia para transferir identificadores entre planos de controle. A rede ATM podia examinar seu conteúdo, e um elemento podia conter vários identificadores tipados. O UUS da Q.2957 levava informação do usuário através dos planos de controle, sem inspeção do conteúdo pela rede. As regras de exceção e interfuncionamento também eram diferentes. Os limites eram 63 octetos no primeiro e 133 no segundo.

Transferência “transparente” queria dizer que um elemento sem erro de codificação podia atravessar a rede segundo as regras de sinalização. Não queria dizer que os extremos concordavam com a semântica, que o remetente estava autenticado ou que a operação solicitada havia ocorrido. Integridade de transporte não era confirmação de estado.

A tipagem tornava a afirmação legível e limitada

Os valores de aplicação 0x03, 0x04, 0x05 e 0x06 correspondiam a IPv4, ST2+, IPv6 e MPLS. O tipo 0x01 representava Session e 0x02, Resource; havia ainda espaço para atribuições da IANA e 0xFE para usos experimentais ou organizacionais.

A sessão IPv4 ocupava 13 octetos, com endereços, protocolo e portas. A versão IPv6 ocupava 37. Ambas eram destinadas a reservas explícitas; associações com curingas precisariam de outro tipo. O VCID de MPLS aparecia como recurso de quatro octetos. O tipo dizia como ler os bytes, mas não dizia que a reserva correspondente existia.

O próprio documento preservou ambiguidades não resolvidas. Não definiu a ordem de vários identificadores, o significado de repetições do mesmo tipo nem o de um elemento vazio. Quando SETUP ou ADD PARTY levava Generic Identifier, CONNECT ou ADD PARTY ACK deveria devolver ao menos um, mas não necessariamente o mesmo. Isso habilitava uma negociação; não especificava seu procedimento detalhado.

Uma rede sem suporte também podia liberar a chamada, remover apenas o elemento ou descartar a mensagem. Uma atribuição registrada só estabiliza a interpretação do valor que chega. Ela não força cada intermediário a carregá-lo.

Transportar RSVP não concedia a reserva

No UUS, o discriminador 0x06 indicava protocolo ou aplicação de Internet, e 0x02 identificava uma mensagem RSVP. Resv podia acompanhar SETUP, ResvConf acompanhar CONNECT, e ResvErr ou ResvTear aparecer em RELEASE. O protocolo de reserva passava a viajar perto da sinalização de chamada.

O RFC comparou um procedimento sequencial, no qual a configuração seguia por um VC e os estados eram estabelecidos em etapas, com outro simultâneo, no qual a mensagem entrava na sinalização B-ISDN. A simultaneidade podia simplificar admissão e temporizadores, mas não atendia pelo menos ao caso de PVC. Por isso os dois modelos precisavam ser considerados.

Uma mensagem Resv transportada não prova que a admissão passou. Um CONNECT não comprova a instalação de QoS em todas as camadas. Um VC ativo não comprova que o fluxo o utiliza. A decisão de reserva, o circuito, o estado IP, os contadores e a experiência da aplicação são fatos próprios.

A especificação não escondeu o que faltava

Agregação de sessões, curingas, flow label do IPv6 e classes de tráfego permaneceram abertos. Reservar faixas para a IANA criava capacidade de governança; não demonstrava futuras atribuições ou uso. A seção de segurança admitia que um número chamador verificado pela rede poderia contribuir para autenticação, mas não transformava o identificador da sessão em credencial.

O aprendizado histórico não depende de saber quanto ATM foi implantado. Ele está na separação entre referência e realidade. Um espaço de nomes permite que sistemas independentes falem do mesmo objeto. Ainda é preciso executar o protocolo, observar o estado e confirmar o tráfego. O RFC 3033 nomeou bem o sujeito e se recusou a fingir que o nome já tinha feito o trabalho.

Fontes

Lu Heng não escreveu nem endossou o RFC 3033, as recomendações da ITU-T ou os RFCs contextuais. Seus ensaios são usados como lentes analíticas declaradas.