Resumo

  • No RFC 3332, o gateway encerrava MTP2 e MTP3 e estendia aos aplicativos IP o serviço de usuário MTP3. Routing Key descrevia qual tráfego pertencia a um Application Server; Routing Context identificava essa regra nas mensagens.
  • Registro aceito, ASP ativo e destino SS7 disponível eram comprovantes distintos. Um não validava os demais. O RFC 4666 tornou o RFC 3332 obsoleto em 2006, delimitando-o como documento histórico.

A unidade de propriedade deixou de ser o enlace

O contraste com M2UA ajuda a enxergar a mudança. No RFC 3331, MTP1 e MTP2 permaneciam junto ao enlace físico no Signalling Gateway; MTP3, remoto, operava aquela fronteira por um Interface Identifier. No M3UA do RFC 3332, o corte subiu. O gateway também encerrava MTP3 e entregava ao domínio IP mensagens de seus usuários, como ISUP e SCCP.

A aplicação remota já não recebia o controle de uma linha específica. Recebia uma classe de sinalização. Para saber qual processo devia tratar cada mensagem, o gateway precisava de uma política que observasse atributos SS7 e determinasse a responsabilidade.

Routing Key era essa política. Podia combinar indicador de serviço, códigos de ponto de destino e origem, faixa de circuitos ou subsistema SCCP. Um Application Server lógico correspondia à chave; seus ASPs executavam o trabalho. Routing Context transformava a descrição em um identificador compacto para o protocolo.

A mudança tornou a infraestrutura mais programável. Também criou uma nova forma de erro: a política podia estar errada e ser executada sem nenhuma falha de transporte. O caminho IP entregava a mensagem exatamente onde a tabela mandava; era a tabela que descrevia o mundo errado.

O aceite do gateway não criava legitimidade

Uma Routing Key podia ser provisionada ou registrada dinamicamente. Quando o SGP aceitava REG REQ e devolvia sucesso, havia prova de que o pedido fora aceito naquele contexto. Não havia prova automática de que o solicitante tinha autoridade sobre os point codes, de que a faixa não se sobrepunha a outra ou de que a configuração fora aprovada.

Network Appearance qualificava códigos reutilizados em redes SS7 diferentes. Ela resolvia ambiguidade local, não estabelecia uma identidade universal. Da mesma forma, Routing Context era significativo entre pares coordenados. Fora do mapa de configuração, o número não dizia que tráfego representava.

Um recibo de seleção completo precisa guardar todos os campos da chave, Network Appearance, pedido e resposta, contexto resultante, versão e origem da configuração. Sem isso, o operador vê o resultado da política sem conseguir auditar sua causa.

Chaves abrangentes são atraentes porque reduzem regras. O custo aparece no raio de falha. Uma faixa excessiva pode entregar chamadas de domínios distintos ao mesmo serviço. Como associação e aplicação continuam saudáveis, a anomalia pode surgir apenas nos estados de chamada ou nas respostas de banco de dados.

Três planos podiam discordar honestamente

SCTP descrevia associação e streams. O controle ASP distinguia DOWN, INACTIVE e ACTIVE; estados de Application Server e modos Override, Loadshare e Broadcast decidiam a distribuição. Esse plano respondia quem estava apto a receber o tráfego selecionado. Não respondia se o destino SS7 estava alcançável.

Os avisos SSNM cuidavam do plano de rede. DUNA indicava destino indisponível, DAVA seu retorno, SCON congestionamento, DUPU indisponibilidade de parte de usuário e DAUD permitia auditoria. Com vários SGPs, M3UA acompanhava cada rota e derivava uma visão consolidada do destino.

Assim, associação UP, ASP ACTIVE e destino DUNA podem coexistir. O transporte está disponível; a aplicação está apta; a rede de sinalização não oferece caminho para aquele destino. Um painel que transforma tudo em verde ou vermelho perde a capacidade de dizer qual camada falhou.

DAVA também não prova desfecho. Ele relata disponibilidade observada, não que uma chamada ISUP completou ou uma transação SCCP chegou ao consumidor final. A resposta do protocolo de usuário constitui um quarto recibo.

Redundância não sincronizava conhecimento por magia

Vários ASPs podiam servir uma AS, e um ASP podia alcançar vários gateways. Na falha, outro processo assumia a chave. A continuidade do Routing Context facilitava a troca, mas não garantia que o novo membro conhecia o último estado das rotas.

Um ASP recém-ativado podia ter perdido um DUNA. Uma associação persistente podia levar a um SGP cujo conjunto de rotas mudara. Uma resposta de DAUD podia envelhecer antes da liberação da fila. A retomada exigia reconciliar associação à chave, autorização, modo, estado por SGP, congestionamento e restart.

Loadshare ainda amplificava uma política ruim. Distribuir uma chave larga entre mais processos aumenta a capacidade de executar a seleção errada. Disponibilidade de software e qualidade da decisão são métricas independentes.

O próprio RFC tinha limite temporal

O RFC 3332 foi publicado em setembro de 2002. Em setembro de 2006, o RFC 4666 o tornou explicitamente obsoleto. O texto antigo continua sendo fonte primária para a arquitetura inicial; detalhes normativos atuais pertencem ao sucessor. Ocultar essa sucessão produz uma falsa atualidade.

O RFC 2719 explica o quadro SIGTRAN, o RFC 9260 é a base SCTP atual, o RFC 3788 trata de segurança e o RFC 4165 diferencia M2PA. Registros IANA demonstram que classes e identificadores foram atribuídos. Não demonstram uso atual, volume, propriedade, saúde nem conformidade.

Proteção de transporte tampouco valida política. Um par autenticado pode pedir uma faixa para a qual não possui autorização, e uma configuração autorizada pode conter erro. Identidade, permissão, seleção e alcance precisam de evidência própria.

Quatro recibos evitam uma conclusão fácil demais

O primeiro recibo descreve seleção: chave, aparência, contexto e proveniência. O segundo descreve aplicação: associação, ASP/AS, modo e membros ativos. O terceiro descreve rede: gateway, rota, SSNM, congestionamento e restart. O quarto descreve resultado: confirmação, erro ou expiração de ISUP/SCCP.

A chave respondia quem deveria tratar a mensagem. Não respondia se o destino estava acessível nem se a operação terminara. A importância histórica do RFC 3332 está em ter exposto essas verdades separadas. Reduzi-las a um único estado apaga justamente a disciplina que tornou o sistema distribuído explicável.

Fontes