Многопротокольная инкапсуляция через ATM определена в RFC 2684. Он определяет два механизма для идентификации протокола, переносимого в кадрах уровня адаптации ATM 5 (AAL5). Он заменяет RFC 1483, стандартный протокол доступа к каналу данных, поддерживаемый модемами DSL .
RFC 2684 описывает два механизма инкапсуляции сетевого трафика: мультиплексирование виртуальных каналов и инкапсуляция LLC . Любой из этих механизмов передает блоки данных протокола с маршрутизацией или мостом , а модемы DSL часто включают настройку мостового соединения RFC 1483. Это отличается от других «режимов моста», обычно встречающихся в комбинированных модемах DSL и маршрутизаторах , которые отключают маршрутизаторную часть модема DSL.
В мультиплексировании VC (VC-MUX) хосты согласовывают протокол высокого уровня для данного канала . Его преимущество состоит в том, что он не требует дополнительной информации в пакете , что минимизирует накладные расходы. Например, если хосты соглашаются передавать IP , отправитель может передать каждую дейтаграмму непосредственно в AAL5 для передачи; ничего не нужно отправлять, кроме дейтаграммы и трейлера AAL5. Главный недостаток такой схемы заключается в дублировании виртуальных каналов : хост должен создать отдельный виртуальный канал для каждого протокола высокого уровня, если используется более одного протокола. Поскольку большинство операторов связи взимают плату за каждый виртуальный канал, клиенты стараются избегать использования нескольких каналов, поскольку это увеличивает ненужные затраты.
В инкапсуляции LLC хосты используют один виртуальный канал для нескольких протоколов. Это дает преимущество в том, что весь трафик разрешается по одному и тому же каналу, но недостатком является требование, чтобы каждый пакет содержал октеты , идентифицирующие тип протокола, что увеличивает накладные расходы. У схемы также есть недостаток, заключающийся в том, что пакеты из всех протоколов перемещаются с одинаковой задержкой и приоритетом.
RFC 2684 указывает, что хосты могут выбирать между двумя методами использования AAL5. И отправитель, и получатель должны договориться о том, как будет использоваться канал, и соглашение может включать ручную настройку. Кроме того, стандарты предполагают, что, когда хосты выбирают включение информации о типе в пакет, они должны использовать стандартный заголовок IEEE 802.2 Logical Link Control (LLC), за которым при необходимости следует заголовок протокола доступа к подсети (SNAP).
Трейлер AAL5 не включает поле типа . Таким образом, кадр AAL5 не самоидентифицируется. Это означает , что либо два хост на концах виртуального канала должен согласные априорно , что схема будет использоваться для одного конкретного протокола (например, схема будет использоваться только для отправки IP - дейтаграмма), или два хоста на концах виртуальной цепи должны согласовать априорно , что некоторые октета области данных будут зарезервированы для использования в качестве поля типа различать пакеты , содержащие данные одного протокола от пакетов , содержащих данные другого протокола.