Кратко

  • Транспортный провайдер видел только up и down, тогда как DSLCP различал Down, Coming Up, Up, Going Down, Bring Down и Bring Up, сохраняя незавершённые и развёрнутые намерения.
  • Release из Up отправлял teardown контроллеру и переводил машину в Going Down, но провайдер получал down сразу, без ожидания результата контроллера.
  • Локальный teardown всегда считался успешным; даже отсутствие у контроллера подходящей транзакции вело к продолжению «как при успехе». Это правило не доказывало состояние цепи, высвобождение ресурса, прекращение оплаты или результат данных.

Поздний ответ не обязан быть ложным

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

RFC 1307 был опубликован в марте 1992 года со статусом Experimental для дальнейших исследований, не как Internet Standard. Он описывал Dynamically Switched Link Control Protocol, созданный в проекте Cray Research. Протокол позволял хосту управлять известными ему нижестоящими сетевыми линиями и скрывал от транспортного провайдера различия переключающего оборудования. Это описание экспериментальной архитектуры, не журнал современной сети.

Экономика задавала ритм. Каналы с коммутацией цепей обычно держали разъединёнными, потому что постоянное соединение стоило дорого. Транспортный провайдер распознавал начало и конец транспортного сеанса и мог попросить линию включить или освободить. Отдельный link controller занимался аппаратными и административными деталями. Запрос на услугу, управляющая транзакция и действие над цепью с самого начала принадлежали разным участникам.

Будущую линию заказывали по уже существующей сети

До любой транзакции DSLCP между хостом и контроллером должен был существовать сетевой путь. Команды могли идти как IP- или UDP-дейтаграммы. Надёжный транспорт протокол не требовал.

Значит, управляющее сообщение и управляемая линия не были одной связью. По первой просили подготовить вторую. Доставка команды не подтверждала готовность данных, а таймаут ответа не устанавливал физическое состояние. Это различие становится особенно важным, когда повторы порождают несколько правдоподобных откликов на одно намерение.

Сообщение несло 16-битный идентификатор, два 32-битных адреса конечных точек, функцию, состояние события и произвольное тело, значимое для контроллера. Транзакцию предполагалось узнавать по идентификатору вместе с обоими адресами. Сам номер не был глобально уникальным удостоверением, линией, сеансом или человеком.

Event status также не имел самостоятельного абсолютного смысла. Он описывал управляемую линию относительно последнего function request. Чтобы понять setup succeeded или teardown failed, нужны функция, пара адресов, открытая транзакция, момент и состояние машины. Выдернутый статус теряет вопрос, на который отвечал.

Словарь событий включал успех и неудачу setup, успех и неудачу teardown, а также асинхронный network down. Функций при этом было две — bring up и bring down. Такая симметрия названий не означала одинаковой семантики: один ответ сообщал исход запрошенного включения, другой мог быть поглощён локальным правилом освобождения. Даже произвольное тело сообщения оставалось текстом, значимым для конкретного контроллера, а не стандартизованным доказательством движения аппаратуры.

Шесть состояний удерживали три времени

Для транспортного провайдера линия была только up или down. Внутри DSLCP существовали Down, Coming Up, Up, Going Down, Bring Down и Bring Up. Они одновременно удерживали прошлое — уже отправленную команду, настоящее — ожидаемый ответ и будущее — последнюю волю пользователя.

Coming Up означал незавершённый setup, Going Down — незавершённый teardown. Bring Down появлялся, если release приходил во время setup. Bring Up — если новый connect приходил во время teardown. Это не дополнительные степени физической линии, а состояния управления противоречивыми по времени действиями.

Когда release застигал Coming Up, DSLCP не мог извлечь команду setup из сети. Он переходил в Bring Down. После успешного setup машина немедленно посылала teardown и оказывалась в Going Down. Пользовательская цель уже была «выключить», хотя контроллер только что честно завершил «включить».

Обратная последовательность начиналась с connect в Going Down. Машина переходила в Bring Up, принимала завершение teardown и затем снова отправляла setup. Текущая цель не переписывала прошлое; она планировала компенсацию после его окончания. Благодаря этому задержка превращалась в управляемую очередь, а не в необъяснимый скачок одного флага.

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

Со своей стороны провайдер обладал другой важной записью: числом активных транспортных сеансов, из которого возникала потребность в линии. Это число могло объяснить, почему появился очередной connect или release, но не заменить идентификатор транзакции DSLCP. Два запроса от пользователей, одна агрегированная потребность провайдера и одна команда контроллеру — не одна и та же сущность. Если их слить, разворот намерения будет выглядеть как дрожание линии, хотя физика могла просто исполнять последовательные команды.

Слово down означало завершение обязательства перед вызывающим

Для setup DSLCP сообщал провайдеру, успешно или неуспешно выполнен конкретный запрос. Для teardown интерфейс был намеренно мягче: провайдер мог считать его успешным, потому что DSLCP всегда возвращал на release успех.

Из состояния Up это создавало явный разрыв во времени. DSLCP отправлял teardown, переходил в Going Down и сразу уведомлял транспортный слой, что линия down. Он не ждал подтверждения контроллера. Внешний флаг закрывал локальное обязательство, пока внутреннее действие оставалось незавершённым.

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

Повтор менял значение порядка

Ненадёжный управляющий транспорт требовал таймаутов и повторной отправки. Авторы использовали в своей среде пять секунд и три повтора, оговаривая необходимость адаптации. Эти параметры были локальными; общим свойством оставалась возможность дублей, неожиданных ответов и перестановки сообщений.

Если setup succeeded приходил, когда DSLCP уже Down, RFC связывал это с повторными запросами и изменённым порядком пакетов. Машина отвечала компенсирующим teardown. Успех мог точно описывать завершившуюся операцию и одновременно быть непригодным как инструкция для текущего состояния.

То же происходило в Bring Down: поздний успех setup запускал teardown и переход в Going Down. История содержала оба события. Фраза «в итоге down» не даёт права утверждать, что setup никогда не состоялся. Именно промежуточный успех мог сделать компенсирующее выключение необходимым.

Teardown succeeded в состоянии Up создавал обратное несоответствие. RFC говорил, что произошла какая-то ошибка. Консервативный вариант — опустить соединение и восстановить синхронизацию; также допускалось, что сообщение можно проигнорировать. Наличие двух возможных реакций честно сохраняло неопределённость: ответ не позволял однозначно восстановить состояние цепи.

Отсутствующая запись контроллера не восстанавливала прошлое

В Up ответ teardown failed означал, что контроллер получил неверную транзакцию и не нашёл записи для сочетания идентификатора и конечных адресов. DSLCP должен был продолжить так, как если бы запрос завершился успешно.

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

Отдельным событием был asynchronous network down. Контроллер мог сам сообщить о падении сети. В Coming Up, Bring Up или Up DSLCP переходил в Down и уведомлял провайдера. Это не host release и не teardown success. Три разные причины могли дать одинаковую внешнюю картину, поэтому происхождение события важнее последнего значения.

В документе не было обещания безопасности

Security Considerations прямо сообщал, что вопросы безопасности не обсуждаются. Идентификаторы, адреса и строки контроллера нельзя на основании RFC считать аутентифицированными, авторизованными, целостными или конфиденциальными. Протокол также не доказывал доставку транспортных данных и результат приложения.

Граница с опубликованной статьёй о RFC 1306 проходит не по номеру, а по механизму. RFC 1306 принадлежали поиск маршрута, внешний запрос активации, отсутствие данных у незавершённой цепи, route aliases и отдельный таймер до первого байта. Здесь предметом служат шесть состояний RFC 1307, разворот намерения, безусловный локальный успех release, неизвестная транзакция и переставленные ответы.

Источник и пределы доказательства

Материал опирается только на RFC 1307, выпущенный в марте 1992 года как Experimental RFC для дальнейшего исследования. Он подтверждает формат сообщений, состояния, повторы, реакции и границы интерфейса. Он не подтверждает реальный контроллер, цепь или обмен, безопасность, высвобождение ёмкости, прекращение оплаты, передачу данных или итог приложения.