Кратко
- Обмен
PROPOSEиPROPOSE ACKпроверял Dedicated-VC и давал соседям общий VCID. Только последующиеOFFERиREADYсвязывали с ним поток по IPv4-адресам источника и назначения. - Связь была локальной и временной: возможны отказ, потеря сообщения и истечение срока. Она не доказывала сквозную доставку, устойчивую ёмкость или качество обслуживания.
Между двумя ответами
Вышестоящий узел сначала выбирал Dedicated-VC и передавал по нему PROPOSE с идентификатором VCID и целевым IP-адресом нижестоящего соседа. Согласившись, сосед возвращал PROPOSE ACK по Default-VC — пути, который оставался для обычной пересылки IP-пакетов от узла к узлу. Оба конца теперь могли назвать одно и то же соединение; процедура заодно проверяла работоспособность канала и соседа. Но она ещё не называла поток, который по нему пойдёт.
Затем по Default-VC посылали OFFER с VCID, flow-ID и интервалом для будущих обновлений. Ответ READY по тому же обычному пути означал, что сосед принял предложение и может получать этот поток через выделенное соединение. Отправленное предложение нельзя выдавать за полученный ответ, а первый ACK — за второй. RFC 2129 ограничивал эту договорённость парой соседей. В примере из трёх маршрутизаторов следующий участок устанавливался независимо.
Документ относился к категории Informational и не задавал стандарт Интернета. FANP описывал сопоставление IP-потока с соединением канального уровня. Default-VC сохранял обычную обработку IP. Для выбранного потока совместимый коммутирующий маршрутизатор мог пересылать ячейки по канальному идентификатору, не разбирая заново IP-заголовок в этой точке. Локальное ускорение не превращалось в обязательство всей сети и не отменяло необходимости отдельного состояния на других участках.
Быстрее включить или меньше держать про запас
Запуск зависел от местной политики. В качестве примера RFC называл номера портов TCP/UDP для долгих или интенсивных сеансов. Узел мог взять заранее созданный VC из списка свободных: меньше ожидания при большем расходе резервируемых ресурсов. Либо установить его по мере надобности через сигнализацию ATM: меньше простаивающих соединений, но требуется время на создание. Экономический и технический баланс оставался местным решением, а не доказанным эффектом конкретной коммерческой сети.
Обозначения также имели узкий смысл. Тогдашний flow-ID содержал только IPv4-адреса источника и назначения; это не метка потока IPv6. VCID позволял распознать соединение соседей, даже если значения VPI/VCI на двух концах различались. Ни одна метка не удостоверяла происхождение трафика. Агрегированные потоки, multicast, сигнализация QoS на уровне IP и поддержка IPv6 были отнесены к будущим улучшениям.
Состояние, которое надо возобновлять
Сосед мог отвергнуть PROPOSE из-за политики, неизвестного типа VCID или нехватки ресурсов. OFFER отдельно мог получить отказ из-за неизвестного VCID или типа flow-ID, неприемлемого потока либо интервала обновления. Когда ожидаемый ответ не приходил, отправитель повторял запрос; после рекомендованных пяти повторов без ответа выбранное соединение следовало освободить. Молчание не считалось согласием.
Пока по Dedicated-VC приходили пакеты, нижестоящий узел периодически отправлял READY. При отсутствии пакетов он прекращал обновления. Вышестоящий узел удалял сопоставление flow-ID и VCID после своего периода ожидания; нижестоящий чистил запись после более долгой паузы, в том числе при тихом отказе партнёра. Две, шесть и двадцать минут в документе — рекомендованные примеры, не универсальная гарантия. В зависимости от вида VC существовали также явные REMOVE/REMOVE ACK или освобождение через ATM-сигнализацию.
Поэтому триггер, выбранный канал, первый ACK, затем READY и очередное обновление следует хранить как разные свидетельства. Они не устанавливают подлинность источника, согласованность каждого участка, получение пакета адресатом, стабильную ёмкость, QoS или экономическую выгоду. RFC 2098 описывал соседний контекст архитектуры обхода обычной обработки; RFC 2129 раскрывал постоянную сверку между соседями, без которой короткий путь не остаётся достоверным.
Источники
- RFC 2129, спецификация FANP, прежде всего разделы 2–5.
- Карточка RFC 2129 в RFC Editor о дате и статусе.
- RFC 2098 как отдельный архитектурный контекст.
Обзор для участников
Подробный контекст профиля
Войдите с подходящим уровнем подписки, чтобы открыть полный обзор и примечания к источникам.
Только для Стратегического сообщества
Стратегическое сообщество
Открыто всем читателям. Вступите и войдите, чтобы открыть обзоры профилей.
Вступить в Стратегическое сообществоТолько для Альянса лидеров
Альянс лидеров
Для проверенных владельцев IP-активов и руководителей. Войдите, чтобы открыть обзоры Альянса.
Вступить в Альянс лидеров

