Кратко

  • RFC 3474 предложил CALL_ID, постоянный в течение жизни ASON Call, в вариантах для области оператора и для глобальной уникальности.
  • Этот ID обозначал отношение; Connections, состояние RSVP, локальные метки, установленные ресурсы, физический сигнал, трафик и услуга оставались отдельными фактами.

Запись может пережить маршрут, который ей приписывали. В марте 2003 года RFC 3474 показал это на уровне управляющей плоскости ASON. Документ имел статус Informational, а не Internet Standard. Он предлагал расширения GMPLS RSVP-TE для soft permanent connections, разделения Call и Connection, восстановления после перезапуска и новых ошибок. Сам по себе он не подтверждает внедрение в сети какого-либо оператора.

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

CALL_ID связывал сообщения с одним отношением. Глобальная форма объединяла код страны ISO, код оператора ITU, подконтрольный организации код точки доступа, адрес исходного LSR и локальный идентификатор. Последний имел 64 бита и должен был оставаться постоянным всю жизнь Call.

Несколько пространств имён создавали впечатление сильной гарантии. Но гарантировалось различение, а не работоспособность. CALL_ID не резервировал длину волны, не программировал кросс-коннект, не создавал оптический сигнал и не доставлял пакеты. Если адрес LSR имел смысл только внутри оператора, операторская форма не становилась глобально уникальной лишь благодаря структуре.

Граница полномочий при выдаче была явной. Первый пользователь мог передать нулевой CALL_ID. Первый сетевой узел назначал новое значение либо проверял уже ненулевое. Транзитные узлы передавали его без изменений, даже не понимая расширение ASON. Path, Resv, PathTear, PathErr и Notify могли нести одну ссылку. Непрерывность ссылки помогала корреляции, но не делала состояние Connections одинаковым.

В базовой модели Call обычно имел одну или несколько Connections. При восстановлении break-before-make их число временно могло стать нулевым: старый путь уже снят, новый ещё не создан. Call и CALL_ID продолжали существовать. Панель, считающая наличие Call признаком активного канала, скрыла бы именно этот разрыв.

Необязательная полная модель разделения говорила ещё яснее. CALL_OPS позволял установить или синхронизировать Call без одновременного создания Connection. В устойчивом состоянии допускались ноль, одна или много Connections. Ноль был не ошибкой логики, а нормальным выражением разных жизненных циклов отношения и связности.

SPC_LABEL показывал подобную границу. Для soft permanent connection объект связывал постоянно настроенный входной сегмент с коммутируемым, однако способ связи оставался локальной политикой вне документа. Через подсети без GMPLS метки имели локальный смысл для управляющего узла и могли задаваться вручную или обнаруживаться заранее. Корректное локальное соответствие не подтверждало сквозной физический путь.

После перезапуска сведения могли прийти из постоянного хранилища, вывода о состоянии соседа или команды управления. Восстановленный CALL_ID доказывал память об отношении. Он не доказывал согласие соседа, завершение RSVP, сохранение аппаратной настройки, сигнал или услугу.

Notify также не сливал уровни. Одно уведомление могло содержать сессии нескольких Calls. Конверт сообщения, личность Call и состояние каждой Connection требовали связи между собой, но не были одним фактом.

Позднейшие документы следует читать по хронологии. RFC 4139 уточнил применимость и требования ASON. RFC 4974, вышедший в 2007 году как Standards Track, определил более полные процедуры и прямо указал: Call сам не предоставляет трафиковую связность и может иметь ноль, одну или много Connections. RFC 6004 развил UNI-атрибуты. Это история уточнения, а не обратное повышение статуса предложения 2003 года.

Подход Heng Lu разделяет символ, решение и эксплуатационную реальность. CALL_ID — символ координации. Допуск Call и сигнализация Connection — решения разных органов. Запрограммированные ресурсы, физический сигнал, двусторонний трафик и результат приложения — наблюдения. Общий ключ связывает их, но не передаёт доказательную силу с одного слоя на другой.

Надёжная история поэтому хранит назначившего CALL_ID, форму, область уникальности, контекст исходного адреса, начало и окончание Call. Каждая Connection получает собственный ID, интервал связи, RSVP-сообщения, происхождение меток, ресурсы и демонтаж. Затем к измеренному объекту присоединяются сигнал, трафик и услуга. Только так непрерывность отношения не превращается в выдуманную непрерывность канала.

Источники