Кратко

  • LLC/SNAP позволял нескольким протоколам делить один ATM VC, потому что каждый PDU нёс метку типа. При VC-мультиплексировании один канал соответствовал одному протоколу, а общей метки в payload не было.
  • Экономия служебных байтов переносила смысл в конфигурацию PVC или сигнализацию SVC. Успешная сборка AAL5 подтверждала оболочку, но не правильную привязку, разбор верхним уровнем или результат приложения.

«Необходимо» не означало «достаточно»

RFC 2684, сменивший RFC 1483 в 1999 году, сохранил две схемы. LLC обычно сокращал число VC в многопротокольной среде. VC-мультиплексирование сокращало накладные расходы на PDU. Но приложение к документу отдельно предупреждало: одной инкапсуляции обычно недостаточно для маршрутизации и мостовой передачи.

Эта граница заложена в RFC 1483. При LLC перед PDU стоял IEEE 802.2 заголовок, иногда SNAP. Для не-ISO протоколов AA-AA-03, OUI и PID/EtherType задавали тип; IP обозначался 0x0800. Каждый PDU приносил собственную подсказку, поэтому несколько протоколов могли делить VC.

При VC-мультиплексировании общей метки не было. Тип определялся не payload, а самим каналом; каждому протоколу требовался отдельный VC. Карточка RFC 1483 описывает два метода, а карточка RFC 2684 фиксирует нормативную замену, не доказывая исчезновение старых реализаций.

Для мостовых PDU LLC/SNAP сообщал ещё и тип исходной среды и сохранение FCS. Поэтому правильная длина и CRC AAL5 подтверждали внешнюю сборку, но не давали всех данных для восстановления внутреннего кадра.

Сэкономленные байты превратились в зависимость

VC-мультиплексирование убирало повторяющийся заголовок и могло уменьшить число ATM-ячеек для некоторых размеров. Но связь «этот VC означает этот протокол» требовала хранения на обоих концах. Для PVC её задавали вручную; для SVC согласовывали при установлении вызова.

Ошибка метки LLC/SNAP могла быть локальной для одного PDU. Ошибка привязки VC могла систематически направлять весь поток корректно собранных PDU не тому анализатору. Спецификация формата не была наблюдением за таблицами конкретной сети.

RFC 1755 определил выбор через B-LLI. Вызывающая сторона предлагала варианты, вызываемая выбирала поддерживаемый или освобождала вызов. Официальная карточка называет документ руководством по сигнализации IP over ATM. Но SETUP и CONNECT оставались свидетельствами управления, а не последующей доставки.

Базовый вариант не стал телеметрией

RFC 2225 сделал LLC/SNAP вариантом по умолчанию для Classical IP и ATMARP при отсутствии другого знания или соглашения. Карточка RFC 2225 помещает это правило в стабильную основу совместимости.

Тот же документ отмечал: тип AAL на PVC задаётся администрацией, на SVC сообщается при установлении, а не несётся заголовком каждой ячейки. AAL5 сохранял порядок и обнаруживал ошибки, но был негарантированным сервисом; повторную передачу обеспечивали верхние уровни.

RFC 2364 использовал обе схемы для PPP. Тип VC согласовывался неявно через provisioning/control plane, а LLC указывал его явно в каждом PDU. Карточка RFC 2364 задаёт контекст соединения точка-точка. Даже аутентификация PPP-сеанса не защищала автоматически другие LLC-потоки того же VC.

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

Источники