Кратко

  • RFC 1953 отдавал нижестоящей стороне управление метками, принимаемыми в одном направлении канала. Она посылала Redirect вверх, но получатель мог проигнорировать часть или все предложения, не отправляя подтверждение.
  • Связь потока и метки была арендой: одинаковый Redirect обновлял срок, другая метка для того же потока отменяла ускорение и возвращала состояние по умолчанию, а несогласованные с adjacency сообщения отбрасывались.
  • Для предложения короткого пути квитанция не требовалась, а для освобождения метки был нужен Reclaim Ack. При этом RFC прямо не рассматривал безопасность, поэтому instance и checksum не были криптографической аутентификацией.

Пакет после истечения таймера

Предыдущий пакет прошёл по ATM с короткой меткой и вызвал сохранённое решение. Перед следующим lifetime истёк. Специальной связи больше нет, но поток не лишился пути: пакет снова обрабатывается обычным IP-маршрутизатором.

В этом возврате видна иерархия системы. Быстрый путь зависел от уже сделанного маршрутного выбора. Маршрут не зависел от оптимизации. Поэтому потеря состояния меняла цену обработки, а не смысл трафика.

Документ Ipsilon Flow Management Protocol Specification for IPv4 Version 1.0 вышел в мае 1996 года со статусом Informational. В примечании IESG сказано, что это частный протокол, не созданный рабочей группой IETF, не относящийся к standards track и не обязательно прошедший характерную для него широкую проверку.

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

Поток создавался классификатором

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

В версии 1 были нулевой тип, TCP/UDP-тип с адресами, протоколом и портами и более грубый тип без портов и части полей. Это ключ пересылки, не удостоверение личности. Он не подтверждал пользователя, приложение, владельца или право на политику.

Метка сжимала ранее сохранённое решение. Короткое число имело смысл только пока оба соседа держали совместимый контекст. После перезапуска или смены peer то же значение могло ссылаться на прошлую жизнь канала.

Поэтому redirection предшествовала синхронизация adjacency. Sender Instance менялся после возвращения канала или узла, выбирался уникальным в недавнем прошлом и не мог быть нулём. Peer Instance и Peer Identity отражали представление о соседе. Номер redirection рос по модулю 2^32 и сбрасывался вместе с каналом.

До состояния ESTAB сообщения перенаправления отправлять было нельзя. Получатель сравнивал адрес источника, sender instance и peer instance с сохранёнными значениями и отбрасывал несоответствие. Это граница старого состояния, не криптографическая аутентификация. Security Considerations честно ограничивался утверждением, что вопросы безопасности не обсуждаются.

Получатель выбирал число, отправитель — действие

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

Ресурс распределял его локальный хозяин, однако предложение не становилось обязанностью. Получатель мог проигнорировать любой элемент Redirect или все сразу. Ack не существовало. Наличие сообщения доказывало просьбу, но не установку связи, пересылку с меткой или доставку.

Label Range сообщал включительные минимум и максимум, доступные локальному каналу. Это свидетельство возможностей, а не глобальный реестр. Одинаковое число на другом канале или в обратном направлении могло означать иное.

Так полномочие оставалось рядом с последствиями. Нижестоящая сторона знала свой ресурс приёма; вышестоящая контролировала изменения своих исходящих пакетов. Координация не отменяла право сказать «нет».

При расхождении выигрывал обычный путь

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

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

Именно это делает механизм обратимым. Истечение, перезапуск, пропуск последовательности, старая инстанция, другой сосед или конфликт привязки могли свести систему к общему способу пересылки. Медленный путь обязан был оставаться исполняемым.

RFC 1954 отобразил IFMP-метки на ATM VPI/VCI. В некоторых форматах перенаправленного потока опускались повторяющиеся IPv4-поля, а в одном типе — начальные поля портов TCP/UDP. Информация не исчезала, а переходила в общее состояние. Управление и путь по умолчанию сохраняли базовую инкапсуляцию.

Предложение без квитанции, освобождение с квитанцией

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

Поэтому каждый Reclaim после выполнения получал Reclaim Ack. Даже неизвестный поток требовал ответа. Если известный поток был связан с другой меткой, получатель снимал реальную связь и сообщал действительно освобождённое значение. По возможности Ack ждал отправки очереди, ещё использующей метку.

Подтверждение доказывало ограниченный переход: в IFMP-состоянии соседей поток отвязан, метка свободна. Оно не удостоверяло каждую физическую очередь или конечную доставку. Но оно не позволяло принять намерение освободить за готовность назначить заново.

Улучшение может создаваться спекулятивно, если отказ безопасен. Разрушительное повторное использование идентификатора требует свидетельства завершения. В этой асимметрии заключён общий урок IFMP.

Сходство механизмов не доказывает родословную

IFMP принадлежал к попыткам соединить IP-решение с ATM-коммутацией. RFC 1987 описывал GSMP как асимметричную связь, где master-controller устанавливал соединения в switch, управлял портами и собирал статистику. Современный ему Tag Switching тоже разделял control и forwarding и допускал топологическое распределение.

Позднейшие архитектура MPLS и LDP показывают, что локальные привязки меток, классы эквивалентности и разделение плоскостей образовали устойчивое семейство. Они не доказывают, что каждый механизм непосредственно произошёл от IFMP. Сравнение вопросов допустимо, линейная легенда — нет.

Надёжный исторический остаток — вопросы: кто управляет коротким идентификатором, кто предлагает его использовать, кто вправе отказаться, когда умирает состояние, что остаётся при расхождении и какое свидетельство разрешает перераспределение?

Написанный знак и выполненная пересылка

Принцип первичности работающего кода Хэн Лу разделяет доказательства. Redirect в документе задаёт возможность. Захваченное сообщение доказывает предложение. Запись в таблице может подтвердить хранение. Только наблюдаемое поведение пакета показывает исполнение. Символ не равен результату.

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

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

Коммутатор предложил короткий путь. Маршрутизатор мог отказаться. Возможность отказа оставляла ускорение над маршрутом, а не вместо него.

Источники и границы

Статус подтверждает карточка RFC 1953, механику — текст RFC 1953. Реализация ATM ограничена RFC 1954, контекст базовой инкапсуляции даёт RFC 1483. Контроль коммутатора сопоставлен по карточке RFC 1987. Без утверждения прямой причинности сравниваются RFC 2105 о Tag Switching, RFC 3031 об MPLS и RFC 5036 об LDP. Аналитические рамки взяты из Running-Code Primacy, Minimum Initial Specification и Reality Layers.

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