Кратко

  • RFC 1294, стандартный RFC января 1992 года, описывает многопротокольное соединение маршрутизируемого и мостируемого трафика через Frame Relay. Когда применяются несколько методов, концы должны заранее знать, какой виртуальный канал несёт каждый из них; инкапсуляция используется лишь на VC, явно настроенном для неё.
  • Метки NLPID и SNAP позволяют выбрать разбор конкретной PDU. Они не настраивают VC и не доказывают согласие сторон, приём, мостирование, маршрутизацию, доставку или результат сервиса.

RFC 1294 — Multiprotocol Interconnect over Frame Relay полезно читать как небольшое, но строгое распределение полномочий. Увидев узнаваемый заголовок, наблюдатель легко делает лишний шаг: раз протокол можно назвать, значит канал уже предназначен для него. Документ такой вывод не разрешает. Он требует, чтобы соответствие метода инкапсуляции виртуальному каналу было известно заранее; сам кадр при этом несёт сведения, нужные для интерпретации полезной нагрузки. Первый факт относится к политике канала, второй — к синтаксису PDU.

RFC 1294 помещает все протоколы в кадр Q.922 Annex A. Следующий протокол может быть назван непосредственно через NLPID. Для маршрутизируемого протокола без собственного NLPID используется NLPID 0x80, затем OUI 00-00-00 и EtherType; для IP возможен NLPID 0xCC. Станция должна принимать для маршрутизируемых пакетов и форму NLPID, и форму SNAP. Это требование о способности прочитать обе формы, а не лицензия посылать любую из них по каждому VC.

У кадра была карточка разбора, у канала — отдельная запись допуска

Представим диспетчерскую, в которой на контейнере лежит карточка с описанием содержимого, а в журнале линии отдельно отмечено, какой вид контейнера допускается на конкретном направлении. Карточка помогает кладовщику выбрать способ вскрытия. Она не меняет журнал линии. В этой метафоре NLPID/SNAP — карточка PDU, а заранее заданное соответствие метода VC — журнал допуска. RFC 1294 не даёт одной записи подменять другую.

Такое различие заметно именно тогда, когда инфраструктура общая. Frame Relay может образовывать полную или частичную сетку. Виртуальный канал обозначается на каждом интерфейсе идентификатором DLCI, но документ подчёркивает, что в большинстве случаев DLCI имеет строго локальное значение. Значение из захвата полезно как привязка к определённому интерфейсу и моменту. Оно не становится глобальным именем удалённого участника или исчерпывающим описанием канала.

Кроме того, при прохождении сети DLCI может быть переписан. Число в передающем заголовке и число, удобное принимающей стороне, способны быть разными местными представлениями одного соединения. Поэтому сохранённый DLCI сам по себе не доказывает, кто был контрагентом, какая политика действовала, какой метод был разрешён или была ли PDU успешно передана. Он доказывает только наблюдение определённого поля в определённой точке, если точка и время действительно записаны.

Метка выбирала анализатор, но не создавала политику канала

При обычных условиях значение управления — UI 0x03. Байты выравнивания должны быть нулевыми. NLPID 0x00 в этой инкапсуляции недопустим: его нельзя отличить от заполнения и он не несёт здесь полезного значения. Уже этот узкий запрет показывает, что метка работает внутри заданной структуры, а не поверх всякого контекста.

Для мостируемого трафика NLPID 0x80 сообщает о SNAP; OUI 00-80-C2 указывает на контекст 802.1, а PID различает форму MAC-заголовка и вопрос сохранения исходной FCS. Это точные признаки формата. Они не заверяют происхождение исходного LAN-кадра, не подтверждают реальное мостирование, не устанавливают общую политику концов и не удостоверяют появление пакета в другой сети.

Фраза «заголовок имел форму, используемую для мостируемого кадра» относится к байтам. Фраза «кадр был промостирован» относится к обработке. Фраза «этот VC был настроен для такой инкапсуляции» относится к предварительному условию. Один и тот же захват может помочь поставить первую фразу; он не заменяет доказательства для двух остальных.

XID не был общим подтверждением всего, что происходит на VC

При инициализации канала Frame Relay механизм Exchange Identification, XID, может согласовывать N201, T200 и K. Если XID не используется, значения должны быть заданы взаимной статической конфигурацией конечных точек DLC или оставаться значениями Q.922. Станция, поддерживающая XID, должна отвечать на XID-кадр. Если удалённый максимум кадра меньше, локальная станция обязана уменьшить применяемый на этом DLC размер до ответа.

Это настоящий и конкретный механизм согласования параметров. Его точность важнее соблазнительной, но неверной интерпретации любого обмена как всеобъемлющего подтверждения. XID не назначает сам по себе способ инкапсуляции VC, не превращает наблюдаемую PDU в допустимую и не доказывает последующую маршрутизацию или доступность услуги.

Хорошая запись сохраняет границы между наблюдением и выводом

Проверяемое расследование хранит раздельно: интерфейс и локальный DLCI; действовавшее в этот момент назначение VC; статические параметры или обмен XID; необработанные байты Q.922; результат разбора NLPID/SNAP; действие принимающей стороны; и независимое свидетельство более позднего результата. Захват подтверждает видимые байты. Запись политики подтверждает зафиксированное условие допуска. Ни один из этих источников автоматически не производит доказательство следующего звена.

Именно поэтому RFC 1294 важен не только как каталог инкапсуляций. Он разрешает общей транспортной среде нести несколько грамматик, не превращая распознавание грамматики в власть над условиями канала. Кадр объясняет, как его читать. Конфигурация VC отвечает, можно ли этот метод здесь использовать. Событие после чтения требует собственной записи.

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

Источник — RFC 1294 — Multiprotocol Interconnect over Frame Relay. Он подтверждает статус и дату документа, требование явной конфигурации, локальный характер DLCI, Q.922/NLPID/SNAP, различение маршрутизируемой и мостируемой инкапсуляции и ограниченный механизм XID. Он не подтверждает действующий VC, оператора, участника, актуальную конфигурацию, безопасность, пересылку, доставку или итог услуги.