Уровень адаптации ATM 5

12.03.2021

Уровень адаптации ATM 5 (AAL5) (англ. ATM Adaptation Layer 5) - это уровень адаптации ATM используемый для передачи пакетов переменной длины размером до 65 535 октетов по сети с асинхронным режимом передачи (ATM).

В отличие от большинства сетевых фреймов, которые размещают управляющую информацию в заголовке, AAL5 помещает управляющую информацию в 8-октетный трейлер (footer) в конце пакета. Трейлер AAL5 содержит 16-битовое поле, 32-битовую проверку циклически избыточным кодом (CRC) и два 8-битовых поля, помеченных UU и CPI, которые в настоящее время не используются.

Каждый пакет AAL5 разделяется на целое число ячеек ATM и повторно собирается в пакет перед доставкой на принимающий хост. Этот процесс называется сегментацией и сборкой (см. ниже). Последняя ячейка содержит "заполнение", чтобы гарантировать, что весь пакет кратен 48 октетам. Конечная ячейка содержит до 40 октетов данных с последующим заполнением байтов и 8-октетным трейлером. Другими словами, AAL5 помещает трейлер в последние 8 октетов конечной ячейки, где его можно найти, не зная длины пакета. Конечная ячейка идентифицируется битом в заголовке ATM (см. ниже), и трейлер всегда находится в последних 8 октетах этой ячейки.

Сходимость, сегментация и повторная сборка

Когда приложение передает данные через соединение ATM с помощью AAL5, хост доставляет блок данных в интерфейс AAL5. AAL5 генерирует трейлер, делит информацию на 48 октетов и передает каждую часть по сети ATM в одной ячейке. На приемной стороне соединения AAL5 повторно собирает входящие ячейки в пакет, проверяет CRC для обеспечения правильного поступления всех частей и передает результирующий блок данных в программу хоста. Процесс разделения блока данных на ячейки и их перегруппировки известен как сегментация и повторная сборка ATM (SAR).

Отделяя функции сегментации и повторной сборки от переноса ячеек, AAL5 следует принципу разделения на слои. Уровень передачи ячеек ATM классифицируется как "машина-машина", поскольку принцип разделения на уровни применяется от одной машины к другой (например, между хостом и коммутатором или между двумя коммутаторами). Уровень AAL5 классифицируется как "сквозной", поскольку принцип многоуровневого хранения применяется от источника к адресату - AAL5 представляет принимающее программное обеспечение с данными в точно таких же блоках размера, как приложение, переданное AAL5 на передающем конце.

AAL5 на принимающей стороне знает, сколько ячеек содержит пакет, потому что отправляющий AAL5 использует бит низкого порядка поля "ТИП ПОЛЕЗНОЙ НАГРУЗКИ" заголовка ячейки ATM, чтобы пометить конечную ячейку в пакете. Этот конечный заголовок ячейки можно рассматривать как "сквозной бит". Таким образом, принимающий AAL5 собирает входящие ячейки до тех пор, пока не найдет ячейки с установленным битом конца пакета. Стандарты ATM используют термин "конвергенция" для описания механизмов, которые распознают конец пакета. Хотя AAL5 использует один бит в заголовке ячейки для сходимости, другие протоколы уровня адаптации ATM свободны в использовании других механизмов сходимости.

Тип пакета и мультиплексирование

В трейлер AAL5 не включено поле типа. Таким образом, фрейм AAL5 не идентифицирует его содержание. Это означает, что либо два хоста на концах виртуального канала должны априори договориться о том, что канал будет использоваться для одного конкретного протокола. (Например, канал будет использоваться только для передачи IP-дейтаграмм), Или два хоста на концах виртуального канала должны априори согласиться с тем, что некоторые октеты области данных будут зарезервированы для использования в качестве поля типа, чтобы отличать пакеты, содержащие данные одного протокола, от пакетов, содержащих данные другого протокола.

RFC 2684, Multiprotocol Encapsulation over ATM, описывает два механизма инкапсуляции для сетевого трафика которые реализуют эти схемы.

Первая схема, в которой хосты согласовывают высокоуровневый протокол для данного канала, упоминается в RFC 2684 как "VC Multiplexing". Преимущество состоит в том, что он не требует дополнительной информации в пакете, что минимизирует передаваемые служебные данные. Например, если хосты соглашаются на передачу IP, отправитель может передать каждую дейтаграмму непосредственно AAL5 для отправки. Кроме самой дейтаграммы и трейлера AAL5 ничего не нужно посылать. Главный недостаток такой схемы заключается в дублировании виртуальных каналов: хост должен создать отдельный виртуальный канал для каждого протокола высокого уровня, если используется более одного протокола. Поскольку большинство операторов связи взимают плату за каждый виртуальный канал, заказчики стараются избегать использования нескольких каналов, поскольку это приводит к ненужным затратам.

Вторая схема, в которой хосты используют один виртуальный канал для нескольких протоколов, в RFC 2684 называется "LLC Encapsulation". Стандарты предполагают, что хосты должны использовать стандартный заголовок IEEE 802.2 Logical link control (LLC), за которым при необходимости следует заголовок протокола доступа к подсети (SNAP). Преимущество схемы в разрешении всего трафика по одному и тому же каналу. Недостатоки второй схемы в том, что каждый пакет должен содержать октеты, которые идентифицируют тип протокола, что добавляет служебные данные, а так же пакеты из всех протоколов перемещаются с одинаковой задержкой и приоритетом.

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

Инкапсуляция дейтаграмм и размер IP MTU

Интернет протокол (IP) может использовать AAL5 в сочетании с одной из схем инкапсуляции, описанных в RFC 2684, для передачи дейтаграмм по сети ATM, как указано в RFC 2225. Перед отправкой данных виртуальное канал (PVC или SVC) должен быть подключен к хосту назначения, и оба конца должны согласиться использовать AAL5 в канале. Для передачи дейтаграммы отправитель передает ее в AAL5 вместе с VPI/VCI, идентифицирующим схему. AAL5 генерирует трейлер, разделяет дейтаграмму на ячейки и передает ячейки по сети. На приемной стороне AAL5 повторно их собирает, проверяет CRC, чтобы убедиться, что биты не потеряны или повреждены, извлекает дейтаграмму и передает ее на уровень IP.

AAL5 использует 16-битное поле длины, что позволяет посылать октеты 65 535 (216 − 1) в одном пакете. Однако RFC 2225 ("Classic IP and ARP over ATM") определяет MTU по умолчанию, равный 9180 октетов на дейтаграмму, так что, если хосты на обоих концах виртуального канала не согласуют больший MTU, дейтаграммы IP, превышающие 9180 октетов, будут фрагментированы.

Структура фрейма AAL5

Фрейм AAL5 состоит из полезной нагрузки (payload), дополнения и прицепа длиной, кратной 48 октетам (т.е. размеру полезной нагрузки ATM). На приведенной ниже диаграмме показано, как полезная нагрузка заполняется перед 8-октетным трейлером, чтобы сделать весь фрейм кратным 48 октетам. Этот фрейм будет проходить процесс сегментации перед передачей по сети ATM.

*Неиспользуемые поля