Кратко

  • RFC 3332 поднял границу адаптации выше MTP3. Сигнальный шлюз завершал MTP2 и MTP3, а сообщения ISUP, SCCP и других пользователей передавал IP-приложению, выбранному по Routing Key. Routing Context служил коротким именем правила.
  • Принятая регистрация, состояние ASP ACTIVE и доступность назначения SS7 были независимыми свидетельствами. Ни одно не подтверждало остальные. В 2006 году RFC 4666 заменил RFC 3332, поэтому текст 2002 года важен как история архитектуры.

Приложению достался не канал, а область ответственности

В M2UA из RFC 3331 физическое звено и MTP2 оставались на шлюзе, а удалённый MTP3 пользовался их границей через Interface Identifier. M3UA провёл разрез выше. Шлюз завершал и MTP3, предоставляя удалённым приложениям сервис его пользователей — прежде всего ISUP и SCCP.

Приложение больше не управляло конкретной линией. Оно отвечало за класс сигнализации. Шлюзу требовалось посмотреть на SS7-поля и решить, какому логическому Application Server принадлежит сообщение.

Routing Key описывал класс через индикатор услуги, коды пункта назначения и отправления, диапазон цепей или номер подсистемы SCCP. Один Application Server обслуживал один ключ, а ASP выполняли его работу. Routing Context позволял ссылаться на сложное описание компактным значением.

Так маршрут стал ещё и административной политикой: сообщения с такими признаками относятся к такому сервису. Протокол надёжно исполнял политику, но не мог доказать, что оператор задал её верно.

Успешная регистрация не была правом собственности

Ключ можно было настроить заранее или зарегистрировать протокольно. Если SGP принимал запрос и возвращал Context, это доказывало факт принятия. Оно не доказывало полномочия заявителя на point code, отсутствие пересечений, правильность диапазона или доступность назначения.

Network Appearance показывал локальность идентификаторов. Одинаковый point code мог использоваться в разных SS7-сетях. Appearance задавал нужное пространство, но не становился глобальным удостоверением и не подтверждал владение.

Для проверки нужны все поля ключа, Appearance, запрос и ответ, полученный Context, версия конфигурации и основание разрешения. Context в пакете — всего лишь ссылка. Если карта соответствий потеряна, номер не раскрывает смысл.

Особенно коварен слишком широкий ключ. Пакеты доходят, процесс отвечает, транспортные метрики зелёные. Но корректные по формату сообщения поступают чужому экземпляру приложения. Это не отказ доставки, а ошибка управления, которую доступность маскирует.

Три состояния не складывались в одну истину

SCTP описывал ассоциацию и потоки. ASP-DOWN, ASP-INACTIVE и ASP-ACTIVE описывали готовность процесса; состояния AS и режимы Override, Loadshare, Broadcast определяли распределение. Они не сообщали, доступно ли каждое SS7-назначение внутри ключа.

Для сети существовали SSNM-сообщения. DUNA означал недоступность, DAVA — доступность, SCON — перегрузку, DUPU — недоступность пользовательской части, DAUD — запрос состояния. При нескольких SGP M3UA хранил статус отдельных маршрутов и выводил из них общий статус назначения.

Поэтому рабочая ассоциация, ACTIVE-процесс и DUNA для выбранного назначения могли быть одновременно истинны. Первое относилось к транспорту, второе к праву процесса принимать класс трафика, третье к сети SS7. Единый индикатор здоровья стирал объяснение.

DAVA тоже имел границу. Он отражал наблюдаемую доступность в конкретный момент, но не доказывал успешный звонок ISUP или завершённую транзакцию SCCP. Результат требовал ответа, ошибки или тайм-аута верхнего протокола.

Переключение переносило трафик, но не обязательно знание

Несколько ASP могли обслуживать один AS, а приложение — работать через несколько шлюзов. После отказа новый процесс активировался для прежнего Context. Однако стабильность имени не гарантировала свежесть сведений о назначениях.

Новый ASP мог пропустить DUNA. Сохранившаяся ассоциация могла вести к SGP, у которого изменился набор маршрутов. Ответ DAUD мог устареть ещё до выпуска очереди. Восстановление требовало сверить членство ключа, разрешение, режим, состояние по каждому SGP, перегрузку и restart.

Loadshare усиливал ошибочную политику. Несколько процессов не исправляли широкий ключ, а увеличивали производительность неправильного отбора. Доступность программ и качество сетевого знания приходилось измерять отдельно.

У RFC тоже есть временная граница

RFC 3332 вышел в сентябре 2002 года. RFC 4666 в сентябре 2006 года явно объявил его устаревшим. Первый документ остаётся первичным источником для истории модели, а современные нормативные детали принадлежат преемнику. Статус документа — часть происхождения факта.

RFC 2719 задаёт SIGTRAN-архитектуру, RFC 9260 — нынешнюю основу SCTP, RFC 3788 — аспекты безопасности, RFC 4165 помогает отличить M2PA. Реестры IANA подтверждают выделение классов и идентификаторов, но не внедрение, трафик, владение, исправность или соответствие.

Защищённый транспорт не делает политику правильной. Аутентифицированный узел может не иметь права на диапазон, а одобренная конфигурация может содержать ошибку. Идентичность, полномочие, выбор и доступность требуют разных доказательств.

Четыре квитанции вместо одного зелёного огня

Квитанция выбора содержит Key, Appearance, Context и происхождение конфигурации. Квитанция приложения — ассоциацию, ASP/AS, режим и активных участников. Сетевая квитанция — SGP, маршрут, SSNM, перегрузку и restart. Квитанция результата — ответ, ошибку или истечение ISUP/SCCP.

Ключ отвечал, кому передать сообщение. Он не отвечал, можно ли достигнуть назначения и завершилась ли операция. Историческая ценность RFC 3332 именно в разделении этих вопросов. Объединить их снова — значит выдать политику отбора за состояние сети.

Источники