Кратко

  • RFC 1954 превращал уже принятую привязку IFMP в ATM VPI/VCI и один из трёх форматов полезной нагрузки AAL-5. Неперенаправленный IPv4 и сами сообщения IFMP оставались на канале по умолчанию VPI 0, VCI 15.
  • Ячейка на маркированном VC подтверждает выбор интерфейса в конкретной точке и моменте. Она не подтверждает сборку всей PDU, доставку, идентичность, полномочие, реальное внедрение или прямую генеалогию MPLS.

Пусть анализатор получил целую полезную нагрузку, но потерял запись о Flow Type. Для Type 0 первые биты обозначают Version и IHL. Для Type 1 те же позиции уже принадлежат Total Length. Байты пришли без ошибки, однако их смысл потерян.

Именно так работает компромисс RFC 1954: повторяющиеся сведения убираются из каждого пакета и помещаются в общее состояние. Быстрее становится передача; дороже становится утрата контекста.

Канал по умолчанию остаётся опорой

RFC 1953 описывает предшествующее решение. Нижестоящий узел предлагает верхнему соседу временную привязку потока к метке. Получатель вправе игнорировать Redirect. Истечение срока или конфликт возвращают поток к состоянию по умолчанию.

RFC 1954 задаёт ATM-представление принятого решения. На VPI 0, VCI 15 используется LLC/SNAP из RFC 1483: восьмиоктетный префикс определяет IPv4, затем следует полный датаграмм в CPCS-PDU AAL-5. MTU IPv4 равен 1500.

Управляющие сообщения IFMP обязаны идти тем же путём. Поэтому средство согласования не зависит от специализированного VC, который оно создаёт. До Redirect, после его окончания и при отказе остаётся общая самодостаточная форма.

Кроме 0/15 документ выделяет только 0/0 для неназначенной ячейки. OAM, бит CLP и ячейки ABR RM не используются. Их наличие в трассе ATM не доказывает работу RFC 1954.

Метка превращается в адрес канала

Младшие 16 бит Label составляют VCI, следующие 12 — VPI, старшие четыре зарезервированы. Если линия не поддерживает полную ширину, неиспользуемые старшие биты равны нулю. Зарезервированные биты отправитель обнуляет, а получатель игнорирует.

Значение служит локальному выбору VC. Оно не является именем пользователя, сервиса или глобального пути. Для интерпретации нужны порт, направление, поколение соседства, срок привязки и Flow Type. Та же пара VPI/VCI в другой точке может означать другое.

Отдельно существует состояние коммутатора. GSMP из RFC 1987 даёт контроллеру возможность создавать и удалять ATM-соединения, управлять портами и получать статистику. RFC 1954 определяет байты на выбранном VC. Принятая привязка IFMP не доказывает программирование коммутатора, а созданное соединение не доказывает правильный формат IPv4.

Три типа требуют трёх способов восстановления

Flow Type 0 убирает только LLC/SNAP. Полный датаграмм IPv4 начинается с первого октета полезной нагрузки; MTU остаётся 1500. Контекст VC сообщает протокол, но IP-заголовок остаётся целым.

Flow Type 1 не передаёт 16 октетов: Version, IHL, TOS, TTL, Protocol, оба адреса и первые четыре октета после IP-заголовка. Для TCP/UDP это порты. Остаются Total Length, Identification, флаги, Fragment Offset, Checksum и данные. MTU исходного датаграмма равен 1484.

Flow Type 2 не передаёт десять октетов исходного IPv4-заголовка: Version/IHL, TTL и оба адреса. Взамен формат вставляет два октета Reserved, поэтому чистое сокращение составляет восемь октетов, а MTU — 1492. TOS, Protocol и четыре октета после заголовка сохраняются.

Оба сжатых формата сохраняют Total Length до удаления полей. Checksum передаётся так, словно TTL был нулём. Это соглашение для восстановления изменяемого по хопам заголовка, а не подпись и не доказательство происхождения.

Угадать тип по длине нельзя. AAL-5 добавляет от нуля до 47 октетов заполнения и восьмиоктетный трейлер; длины данных и фрагментов различны. Грамматику задаёт актуальная привязка VC к Flow Type. Устаревшее состояние способно неверно истолковать безошибочные байты.

Наблюдение ячейки — только первый шаг

Одна CPCS-PDU AAL-5 занимает несколько ATM-ячеек. Увиденная ячейка показывает, что передающий интерфейс выбрал VPI/VCI. Она не показывает, что все ячейки дошли и трейлер был принят.

Даже после полной сборки остаются восстановление полей, проверка IPv4, следующее решение маршрутизации, удалённый приём и действие приложения. RFC 1954 прямо не обсуждает безопасность. Label не удостоверяет отправителя, Checksum не является подписью, VC не выдаёт разрешение.

Журнал доказательств должен разнести получение Redirect, принятие, актуальность, конфигурацию коммутатора, отправку на VC, завершение AAL-5, восстановление IP, следующий хоп и конечный результат. Иначе слово «маркированный» поглотит все возможные места отказа.

Общий словарь не создаёт родословную

Позднее RFC 2105 описал Tag Switching, RFC 3031 — архитектуру MPLS, а RFC 5036 — LDP и ATM-механизмы меток. Общие черты очевидны: подготовленное состояние и короткие значения для плоскости передачи. Но сходство не доказывает причинное наследование.

RFC 1954 имеет статус Informational, фиксирует частный протокол и не является продуктом рабочей группы IETF. В нём нет доказательств широкого внедрения, производительности, совместимости или переноса кода. Для исторической связи нужны проектные архивы, реализации, свидетельства авторов и эксплуатационные данные.

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

Ячейка несла метку. Надёжно она сообщала только одно: этот интерфейс в этот момент выбрал этот VC и эту грамматику полезной нагрузки.

Источники