Кратко

  • Промежуточный ST-II agent мог подтвердить CONNECT, согласовать локальный идентификатор и попытаться зарезервировать ресурсы до решения целевого приложения.
  • Отдельный ACCEPT возвращал к источнику FlowSpec, фактически накопленный на конкретной ветви, а не неизменённое исходное пожелание.
  • Для нескольких целей источник собирал отдельные результаты и сводил параметры; принятый control state всё ещё не доказывал доставку пакетов или полезный результат.

Сначала создавалось дерево

RFC 1190 вышел в октябре 1990 года и описал Experimental Internet Stream Protocol Version 2, ST-II. Это был Limited-Use Experimental Protocol, а не Internet Standard. Карточка RFC Editor и запись IETF Datatracker отмечают последующую замену на RFC 1819, но не свидетельствуют о действующем потоке или всеобщем внедрении.

ST-II находился на Internet layer рядом с IP. Он не считал каждую data packet независимой. Перед передачей протокол строил направленное simplex-дерево от одного origin к одной или нескольким targets. Поток включал пути, выделенные ресурсы и состояние в каждом участвующем agent.

Сложность setup покупала дешёвый forwarding позже. TargetList делилась по ветвям, routing выбирал next hop, контрольные автоматы связывались локальными идентификаторами, а короткий HID указывал состояние для data packet. Работа действительно совершалась — только ещё не тем субъектом, который решал участие приложения.

HID-APPROVE замыкал одну связь

Получив CONNECT, промежуточный agent быстро отвечал ACK, HID-REJECT или HID-APPROVE, если не видел ошибки. Hop Identifier служил локальным сокращением для пересылки. После ответа узел мог вызвать routing, выделить ресурсы и передать новые CONNECT дальше.

Положительное сообщение доказывало, что соседняя пара приняла конкретный handle для своей связи. Оно не доказывало существование следующего пути, доступность дальних ресурсов или желание процесса на target. Владелец локальной таблицы не становился представителем приложения.

Global Name потока, TargetList ветви, local HID и SAP верхнего протокола также имели разные области. Ни один из них сам по себе не был человеческой идентичностью или полномочием.

Желаемая FlowSpec менялась, предел сохранялся

Origin указывал в FlowSpec Desired и Limits. Desired описывал желаемый сервис. Limits задавал нижнюю границу, которую промежуточные и целевые agents не имели права ослабить. Если одна сеть давала меньше bandwidth, добавляла delay или требовала меньший PDU, agent обновлял Desired до полученного результата и продолжал setup, пока Limits соблюдались.

Список ресурсов включал forwarding information, производительность packet switch, buffers, network bandwidth и multicast identifiers. RFC 1190 не определял единый способ резервирования во всех нижележащих сетях. Документ прямо признавал: немногие сети тогда предоставляли reservation, а ни одна известная авторам не охватывала весь перечень.

Значит, запись о резерве должна содержать agent, локального владельца ресурса, ветвь, target, запрос, полученное значение, время и возможность preemption. Булево «reserved» вне этих координат ложно расширяет локальный факт.

Target видел уже изменённое предложение

На целевой машине host agent завершал HID negotiation и показывал указанному процессу Name, FlowSpec, Options, Group и application selector. Приложение могло принять предложение, отказаться либо уменьшить желаемый уровень сервиса.

Только после этого появлялся ACCEPT или REFUSE. Ответ получал новый Reference, а LnkReference связывал его с прежним CONNECT. Каждый промежуточный узел проверял соответствие, подтверждал приём ближайшему соседу и передавал новый ответ в обратную сторону.

Так протокол оставлял решения их владельцам. Routing выбирал путь. Resource manager решал локальную аллокацию. Соседи утверждали handle. Приложение принимало участие. Origin оценивал, годится ли вернувшийся набор условий. Раннее «да» не поглощало последующие veto.

У каждого листа был собственный ответ

При нескольких targets источник ожидал ACCEPT, REFUSE или error от каждой. Результат одной ветви можно было сообщить приложению сразу, но весь setup завершался только после ответов всех целей и окончания переговоров об идентификаторах.

Вернувшиеся FlowSpec могли противоречить друг другу. Один path поддерживал крупные пакеты с низкой частотой, другой — небольшие с высокой. Origin мог удалить target, прекратить поток либо создать второй. Затем CHANGE освобождал ресурсы выше фактически выбранного общего режима.

Поэтому ACCEPT от B был фактом о B и его path. Он не говорил за C, D и не доказывал, что origin уже принял условия B. Aggregate state возникал отдельным решением.

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

Сам ACCEPT должен был надёжно подняться к origin. Если после повторов upstream ACK не приходил, agent отправлял REFUSE к источнику и DISCONNECT к цели. Поток с более высоким precedence мог вытеснить ресурсы после установки. NOTIFY сообщал новую, меньшую гарантию; неудачный CHANGE мог частично изменить reserve и потребовать recovery.

ST также не предоставлял security services самостоятельно. ACCEPT не удостоверял человека, организационное поручение или право выставить счёт. И даже полный setup не показывал, что data packet дошла, голос был декодирован, видео показано или участник получил ожидаемое качество.

Следующая версия убрала именно локальный HID

RFC 1819 пересмотрел эксперимент в 1995 году как ST2+. RFC Editor и Datatracker хранят публикационные записи. Примечание IESG подчёркивает, что ни новая, ни старая версия не была Internet Standard и не рассматривалась на этот статус.

ST2+ сохранил цепочку CONNECT, ACK, local resource manager, решение target и обратный ACCEPT. Но HID был удалён: сложность мешала interoperability. Исчезли и subset implementations, поскольку разрешение реализовать часть протокола не обеспечило совместимой общей способности.

Локальный идентификатор оказался заменяемым, а право целевого приложения на решение — нет. История ревизии сама разделяет wire format, implementation capability, reserve и consent.

Более ранний RFC 1077 уже ставил высокоскоростную сеть шире пропускной способности среды. Поздние RFC 1633 и RFC 2212 определили иные поверхности reservation и guaranteed service. Они дают контраст, но не доказывают прямое происхождение, внедрение ST-II или результат.

Источники