Resumo

  • A RFC 3038 tratou do descompasso entre o VPI/VCI ATM, um rótulo local que podia ser reescrito no próximo salto, e a necessidade de dois ATM-LSR vizinhos identificarem a mesma conexão virtual nos anúncios LDP.
  • No procedimento ponto a ponto em banda, PROPOSE não era acordo. Um ACK correspondente e a posterior mensagem LDP REQUEST completavam a troca de três mensagens antes de o mapeamento carregar o VCID.

Uma conexão, nomes locais diferentes

Em janeiro de 2001, o conjunto de padrões MPLS buscava usar comutadores ATM como roteadores de comutação por rótulo. O hardware já encaminhava células consultando VPI e VCI, mas esses campos normalmente nomeavam o trecho local. Um comutador podia substituí-los ao encaminhar para o enlace seguinte. Assim, o valor que um vizinho LDP observava não era necessariamente uma identidade persistente da conexão virtual que ambos precisavam coordenar.

A RFC 3038 acrescentou uma segunda identidade, o Virtual Connection Identifier (VCID). A propriedade essencial é que as duas pontas associem o mesmo VC ao mesmo VCID. Isso não substitui os rótulos VPI/VCI usados no plano de dados nem cria um número global para toda a rede ATM. O identificador permite que ATM-LSR adjacentes associem seus rótulos locais de entrada ou saída a uma referência comum e a levem às mensagens LDP.

A ordem dos fatos importa. O procedimento parte de um VC já estabelecido por sinalização ou gerenciamento. A notificação não cria a conexão ATM: alinha o modo como os dois vizinhos a reconhecem. Só depois vêm a requisição e o mapeamento LDP. Estabelecer o VC, atribuir o rótulo local, associá-lo ao VCID, distribuir um mapeamento e transportar tráfego são evidências diferentes. Nenhuma delas, isoladamente, comprova que uma aplicação recebeu dados.

Por que o ACK não encerrava a troca

Para um VC ponto a ponto em banda, o nó upstream escolhia o VCID e enviava VCID PROPOSE, com um identificador de mensagem, pelo circuito recém-estabelecido. Cada ponta associava o VCID ao seu rótulo local. O downstream respondia com ACK contendo o VCID e o identificador recebidos; o upstream precisava conferir ambos e retransmitir a proposta caso o ACK esperado não chegasse.

Depois do ACK, o upstream enviava uma LDP REQUEST com o identificador da mensagem. O downstream tratava a requisição como evidência de que o upstream havia recebido o ACK. A RFC 3038 explica a necessidade dos três passos porque PROPOSE é transmitido de forma não confiável. O downstream pode saber que enviou a confirmação, mas não que o outro lado a recebeu. Até REQUEST chegar, deve descartar no VC os pacotes que não sejam o próprio VCID PROPOSE.

Com a troca concluída, o LDP Mapping pode carregar o VCID no Label TLV. Isso estabelece uma associação de plano de controle entre vizinhos; não é um recibo de sucesso de aplicação, não confirma cada comutador de um caminho mais longo e não demonstra que houve tráfego de usuário.

O tipo de conexão altera o procedimento

A RFC 3038 não impõe a mesma notificação a todo enlace. Uma conexão ponto a ponto transparente, com o mesmo VPI/VCI nas duas pontas, não precisa dela. Um Virtual Path pode usar notificação em banda ou o procedimento VPID; no caso restrito de um único VP até o vizinho, o VCI comum pode bastar. Um PVC usa o procedimento em banda. Para SVC, a sinalização pode transportar o VCID em um campo amplo o bastante, usar um campo temporário menor ou recorrer à mensagem em banda.

A direção também conta. A ponta upstream inicia a notificação. Uma conexão bidirecional requer uma troca em cada direção; uma unidirecional só precisa daquela permitida. Portanto, «a mesma conexão» não é uma identidade global automaticamente conhecida por toda a nuvem ATM: é uma relação que os vizinhos relevantes estabelecem par a par.

A opção do campo pequeno evidencia a diferença entre correlação temporária e associação duradoura. O campo de usuário específico BLLI podia identificar provisoriamente o circuito durante a sinalização. Seu valor não podia ser reutilizado por outra transação incompleta com o mesmo vizinho; depois de a associação VCID se completar, o BLLI podia voltar a ser usado. Em um caso multiponto, BLLI era único no emissor, não no receptor, que também precisava do endereço ATM de origem. Um recurso temporário escasso só podia ser liberado depois de uma transição verificável.

A notificação VPID oferece outra alternativa para Virtual Paths: formar o VCID a partir do VPID e do VCI, dispensando uma negociação individual para cada VC. O multiponto aparece como uso futuro, e o documento diz que o LDP então vigente não suportava multicast. Um comutador sem VC-merge talvez tivesse de dividir temporariamente um LSP ativo para enviar a mensagem em banda ao incluir uma nova folha, com possíveis efeitos de desempenho e QoS. São limitações descritas pela norma, não medições de implantação.

Um limite histórico que vale preservar

A RFC 3033, publicada no mesmo mês, definiu identificadores tipados para sessões e recursos na sinalização ATM. Ela trata de outro objeto: o VCID da RFC 3038 associa rótulos locais entre vizinhos LDP depois de estabelecido o VC. As FEC da RFC 3036 e a arquitetura MPLS geral são outras camadas. Agrupar tudo sob a palavra «identificador» confundiria estabelecimento, classificação, encaminhamento por salto e entrega.

O RFC Editor lista hoje a RFC 3038 como Proposed Standard e indica que a RFC 7274 a atualiza. Esta última trata da alocação e retirada de rótulos MPLS de propósito especial e atualiza o uso antigo de «reserved label»; isso não revoga a negociação de VCID. Nenhum dos documentos nomeia implementações implantadas, quantifica adoção ou relata testes de interoperabilidade. A conclusão sustentada é mais modesta: quando o rótulo ATM podia ser local a um salto, o controle MPLS precisava de uma identidade comum aos vizinhos, e a especificação tornou esse acordo observável por meio de uma troca explícita.

Fontes

Os textos de Heng Lu são indicados apenas como lentes analíticas; Lu não escreveu nem endossou a RFC 3038.