Кратко

  • RFC 2383 связал один переход ST2+ с одним виртуальным каналом ATM и развёл пользовательскую, управляющую и служебную плоскости. Зарезервированный тракт данных и путь, по которому пришло извещение о его отказе, оставались разными объектами доказательства.
  • Поскольку правила восстановления ST2+ были неясны и неполны, а несколько агентов могли одновременно увидеть отказ ATM, спецификация потребовала NoRecover. Явный отказ оказался надёжнее обещания, которое две реализации поняли бы по-разному.

Можно зарезервировать пропускную способность, но не зарезервировать возвращение после аварии.

Эту границу провёл RFC 2383, опубликованный в августе 1998 года как информационная спецификация переноса ST2+ через ATM UNI 3.1. Сопоставление было строгим: один переход ST2+ обслуживал один виртуальный канал ATM; канал не делили с другими переходами, а переход не раскладывали по нескольким каналам. У абстрактного запроса ресурсов появлялся конкретный носитель.

Однако восстановление не получило такой же определённости. Реализация должна была выбрать NoRecover в CONNECT. Если отправитель запрашивал иное, получатель отвечал REFUSE с причиной NoRecover. Документ не называл это частично поддерживаемым автоматическим восстановлением и не выдавал извещение ATM за недостающую семантику ST2+. Восстановление потока объявлялось неподдерживаемым и переходило в ведение приложения.

Это решение важно именно потому, что система уже располагала множеством элементов, похожих на восстановление. ATM могла сообщить о падении соединения. Агенты ST2+ обменивались SCMP. FlowSpec резервировал ресурсы по переходам. Новый виртуальный канал можно было создать. Но эти факты не назначали единственного инициатора, не подавляли одновременные попытки, не связывали замену с исходным потоком и не доказывали приемлемого результата для приложения.

Один переход — один VC, но не одна истина

RFC 2383 разделял пользовательскую плоскость, плоскость управления и служебное управление. Данные ST2+ шли по ATM-соединению перехода. Агенты передавали SCMP по управляющему пути. Локальные механизмы выбирали адрес, создавали канал и наблюдали его состояние.

Эти плоскости не обязаны были сходиться в одной трассе. Спецификация не закрепляла отдельный VC для SCMP: реализация могла повторно использовать канал IPv4 либо создать выделенный канал управления ST2+. Данные и SCMP одного потока должны были следовать одному направлению маршрутизации ST2+, но путь IPv4 к тому же IP-адресу мог иметь обратное направление. Управление могло оставаться доступным при разрыве зарезервированного канала данных — или отказать независимо от него.

Поэтому индикатор «сеть доступна» почти ничего не сообщает без названия объекта. Пакет IPv4 нашёл маршрут? SCMP дошёл до агента? Коммутатор ATM хранит состояние вызова? Пользовательские данные проходят именно через нужный VC? Каждое утверждение относится к своему слою и не сертифицирует соседние.

Правило одного VC на переход делало улику конкретной, но и локальной. Такой канал был носителем данного участка. Полный поток состоял из нескольких участков, каналов и агентов. Исчезновение одного VC точно отмечало место разрыва, но не давало ему полномочия собрать весь поток заново.

Обнаружение отказа не стало координацией восстановления

Функцию HELLO для ST2+ поверх ATM разрешалось не поддерживать: предполагалось, что ATM достаточно хорошо сообщает о неисправности соединения. Но данные и SCMP могли идти по разным VC. Результат проверки на одном пути не устанавливал состояние другого.

При восстановлении это различие становилось опаснее. RFC 1819 описывал восстановление ST2+, однако RFC 2383 счёл его неясным и неполным для данной среды. ATM могла известить всех затронутых участников. Несколько агентов ST2+ тогда замечали одну неисправность почти одновременно.

Если каждый действовал самостоятельно, начиналась гонка. Один агент освобождал старое состояние, пока другой строил новое; возникали конкурирующие запасные сегменты; нижележащая часть потока могла присоединиться не к той попытке. События отказа было мало. Требовались правило выбора полномочного агента, общая идентичность восстановления, порядок действий и отдельные подтверждения обнаружения, освобождения, нового допуска, сборки переходов и принятия приложением.

RFC 2383 не определял такой договор между реализациями. Поэтому NoRecover точно обозначал отсутствующую поверхность управления. Коммутатор мог правдиво сказать, что VC исчез. Агент мог правдиво подтвердить получение сигнала. Новый канал мог правдиво сообщить об успешном допуске. Приложение всё равно могло получить разрыв, дубликат либо вообще не получить ожидаемый поток.

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

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

Сеть умела предоставить новый путь, но не знала, образуют ли старый и новый пути одну корректную операцию. Потому успешной установки заменяющего VC недостаточно для статуса «восстановлено». Нужно связать уведомление об отказе, идентификаторы старого и нового каналов, освобождение резерва, пересборку состояния ST2+, сквозную идентичность потока и подтверждение приложения.

Здесь особенно полезна предложенная Heng Lu оптика слоёв реальности. Физическая линия, вызов ATM, состояние агента ST2+, обмен SCMP, сессия приложения и наблюдаемый пользователем результат соседствуют, но не совпадают. Сведение их к одному зелёному индикатору делает панель яснее ценой различий, от которых зависит истинность заявления. Право назвать систему восстановленной получает владелец панели, а последствия потери или повтора несёт другой участник.

Направление установки было вопросом политики

Ещё до отказа соединение требовало инициатора. Для коммутируемых виртуальных каналов RFC 2383 разрешал выбирать сторону, начинающую ATM-соединение, по эксплуатационной либо расчётной политике. Это направление не зависело от ориентации отправитель—получатель при построении потока ST2+.

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

У отображения FlowSpec в параметры ATM тоже была жёсткая граница. Характеристики трафика и качество обслуживания переводились с опорой на модели RFC 2211 и RFC 2212 и сигнализацию RFC 1755. UNI 3.1 не позволяла менять QoS установленного соединения. Поддерживаемое изменение FlowSpec, требующее иных ресурсов, означало освобождение старых ATM-соединений и создание новых.

Это не изменение значения на месте, а передача ответственности между двумя распределениями ресурсов. Когда остановится старый канал, когда допустят новый и что сохранится при неудаче, зависело от реализации и политики. RFC задавал отображение и необходимость пересоздания, но не публиковал измерений без потерь и не доказывал непрерывность приложения.

Эта тема не повторяет историю RFC 2380. Там главным был reduced reservation и граница обязательства между старым и новым распределением при изменении резерва. У RFC 2383 иной собственный вопрос: что делать, когда несколько агентов видят отказ ATM, а полный порядок восстановления отсутствует.

Явный отказ тоже обеспечивает совместимость

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

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

С точки зрения минимальной начальной спецификации Heng Lu, это дисциплинированная неполнота. Не следует заполнять непроверенную область словами, похожими на гарантии. Нужно определить совместное ядро, локализовать частное решение и оставить работающему коду возможность доказать более сильный договор. Адресация, выделенный VC, установка и отображение ресурсов входили в ядро; восстановление потока — нет.

Чтобы обоснованно убрать NoRecover, одной новой редакции недостаточно. Нужны испытания, где несколько агентов одновременно получают один сигнал ATM, выбирают единственную власть, подавляют дубли, учитывают старый резерв, устанавливают замену, присоединяют её к правильному потоку и возвращают приложению однозначный исход. Следует терять управляющие сообщения, менять направления и независимо отключать VC данных и контроля.

RFC 2383 таких результатов не заявлял. Его информационный статус ограничивает и исторический вывод: это спецификация протокола, не обзор внедрений. История IETF Datatracker подтверждает путь документа, а не массовое использование.

Безопасность защищала лишь одно ребро

Раздел безопасности также был узким. Минимальные расширения ATM и исправления не должны были ослаблять ST2+ или UNI 3.1. Проверенный номер вызывающей стороны, предоставленный сетью, мог внести вклад в аутентификацию.

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

Нельзя выводить из документа факт внедрения конкретным оператором, достижение задержки, восстановление реальной аварии или выбор инициатора по определённому тарифу. Для этого нужны эксплуатационные записи.

Зато RFC надёжно установил различие: резервирование ресурсов, обнаружение отказа, доступность управления, реконструкция и успех приложения — пять разных заявлений. Первые три могут быть истинны без четвёртого, а инфраструктура может быть перестроена без пятого. В 1998 году RFC 2383 сохранил эту честность одним флагом: NoRecover.

Он не запрещал действия после отказа. Он запрещал сети обещать завершённое восстановление до появления общей власти, порядка и итогового подтверждения. Канал резервировал ресурсы. Агенты узнавали о разрыве. Смысл нового начала оставался у приложения.

Источники