Перейти к содержанию

6LoWPAN

Заголовок IPv6 — 40 байт, а в радиокадре IEEE 802.15.4 всего 127 байт вместе со служебными полями. Чтобы IPv6 вообще заработал на датчиках с батарейкой, между радио и IP вставили слой, который сжимает заголовки до нескольких байт и режет пакеты на фрагменты. Этот слой и называется 6LoWPAN.

Обновлено Редакция GAW

Содержание

6LoWPAN (IPv6 over Low-Power Wireless Personal Area Networks) — адаптационный слой между IEEE 802.15.4 и IPv6, описанный в RFC 4944 и дополненный сжатием из RFC 6282. Он решает одну задачу: протащить пакеты IPv6, для которых канал обязан поддерживать MTU 1280 октетов, через радиокадр длиной 127 октетов. Для этого слой сжимает заголовки IPv6 и UDP, фрагментирует большие пакеты и задаёт, как строить адреса из идентификаторов 802.15.4.

Почему без него нельзя

ЧтоОктетовИсточник
PHY-пакет 802.15.4, максимум (aMaxPHYPacketSize)127RFC 4944 разд. 4
Накладные расходы кадра MAC, максимум25разд. 4
Остаётся на уровне MAC102разд. 4
Защита канала AES-CCM-32 / -64 / -1289 / 13 / 21разд. 4
Остаётся при AES-CCM-12881разд. 4
Заголовок IPv6 + UDP без сжатия40 + 8разд. 4
Остаётся данных33разд. 4

RFC 4944 заключает, что сжатие заголовков «почти неизбежно», а фрагментация обязательна ради MTU 1280 (разд. 4). Пакеты IPv6 передаются только в кадрах данных, желательно с подтверждением (разд. 2).

Сжатие заголовков

Первый вариант, HC1 из RFC 4944, сжимал типичный заголовок IPv6 между link-local адресами до 2 октетов, но требовал передавать 64 бита идентификатора для любого маршрутизируемого адреса и все 128 бит для multicast. RFC 6282 (разд. 2) заменил его на LOWPAN_IPHC: 13 бит кодирования, из которых 5 лежат в байте dispatch, плюс контексты для префиксов всей сети. Итог (разд. 3):

  • обмен внутри канала — заголовок IPv6 сжимается до 2 октетов;
  • маршрутизация через несколько переходов — до 7 октетов: dispatch, IPHC, Hop Limit и по 2 октета на адреса;
  • Hop Limit либо передаётся целиком, либо кодируется двумя битами как 1, 64 или 255 (разд. 3.1.1);
  • порты UDP из диапазона 0xf0b0…0xf0bf сжимаются до 4 бит — это всего 16 незарезервированных портов, и RFC советует защищать содержимое, например кодом MIC (разд. 4.3.1).

Прикладные протоколы для таких сетей живут поверх UDP, например CoAP.

Фрагментация

Если пакет не влезает в кадр, его режут на фрагменты, кратные 8 октетам (кроме последнего). Первый фрагмент несёт заголовок из 4 октетов — тип 11000, datagram_size (11 бит, размер всей датаграммы до сжатия) и datagram_tag (16 бит); последующие — 5 октетов с добавлением datagram_offset в единицах по 8 октетов (разд. 5.3). Приёмник собирает пакет по адресам отправителя и получателя, размеру и тегу и ждёт не больше 60 с. Заголовки, не поместившиеся в первый фрагмент, сжимать нельзя (RFC 6282 разд. 2). На уровне IPv6 канал при этом выглядит как обычный с MTU 1280, и Path MTU Discovery здесь ни при чём.

Адреса

Идентификатор интерфейса берётся из EUI-64 радиочипа или, при 16-битном коротком адресе, из псевдоадреса «PAN ID : 0 : короткий адрес» с битом U/L = 0; префикс для SLAAC обязан быть длиной 64 бита (разд. 6). Link-local адрес — FE80::/64 плюс этот идентификатор (разд. 7). Маршруты между узлами, которые друг друга не слышат, строит RPL. Место 802.15.4 среди других радиоинтерфейсов — в обзоре беспроводных интерфейсов; в Zephyr стек 802.15.4 работает только с IPv6, то есть всегда через 6LoWPAN.

Частые вопросы

Сколько байт данных помещается в один кадр 6LoWPAN?

По RFC 4944 (разд. 4) из 127 октетов PHY-пакета до 25 уходит на кадр MAC — остаётся 102, и до 21 — на защиту AES-CCM-128, остаётся 81. Несжатый заголовок IPv6 (40) и UDP (8) оставили бы 33 октета данных. Поэтому заголовки сжимают: с IPHC заголовок IPv6 при обмене в пределах канала занимает 2 октета (RFC 6282 разд. 3), и под данные остаётся на несколько десятков байт больше (наш расчёт).

Зачем 6LoWPAN фрагментация, если есть сжатие?

IPv6 требует, чтобы любой канал передавал пакет 1280 октетов, и RFC 4944 (разд. 4) объявляет для 802.15.4 именно такой MTU. Кадр 127 байт столько не вмещает, поэтому пакеты крупнее кадра режутся на фрагменты кратные 8 октетам: первый несёт 4-байтовый заголовок с размером датаграммы и тегом, остальные — 5-байтовый с добавлением смещения (разд. 5.3). Сборку ждут не больше 60 с. Авторы ожидают, что при сжатии большинство прикладных пакетов уместится в один кадр, а фрагменты понадобятся для редких больших обменов вроде настройки.

Чем RFC 6282 отличается от RFC 4944?

RFC 4944 задаёт всё: кадр, адреса, фрагментацию и первое сжатие HC1. RFC 6282 заменяет только раздел 10 — сжатие: вместо HC1 вводит LOWPAN_IPHC с контекстами, которое сжимает и глобальные, и multicast-адреса, а HC1 передавать больше не следует (разд. 2). RFC 6282 добавляет сжатие Hop Limit до значений 1, 64 и 255 и позволяет опускать контрольную сумму UDP; сжатие портов 0xf0b0–0xf0bf до 4 бит унаследовано от RFC 4944 (разд. 4.3.1).

Источники

  1. IETF. G. Montenegro, N. Kushalnagar, J. Hui, D. Culler. Transmission of IPv6 Packets over IEEE 802.15.4 Networks. RFC 4944, September 2007 — разд. 1: формат кадра, link-local и автоконфигурируемые адреса, адаптационный слой, так как IPv6 требует пакеты много больше кадра 802.15.4; разд. 2: пакеты IPv6 — только в кадрах данных, рекомендуется с подтверждением; разд. 4: MTU для IPv6 поверх 802.15.4 — 1280 октетов; максимальный PHY-пакет 127 октетов (aMaxPHYPacketSize), накладные расходы кадра до 25 (aMaxFrameOverhead) → 102 октета на уровне MAC; защита канального уровня забирает ещё 9, 13 или 21 октет (AES-CCM-32/64/128) → 81 октет; за вычетом заголовка IPv6 40 октетов остаётся 41, за вычетом UDP 8 — 33 октета данных; отсюда обязательность фрагментации и сжатия; разд. 5.3: пакет, не влезающий в кадр, делится на фрагменты, все, кроме последнего, кратны 8 октетам; заголовок первого фрагмента — 11000, datagram_size 11 бит, datagram_tag 16 бит; последующих — 11100, size, tag и datagram_offset 8 бит в единицах по 8 октетов; таймаут сборки не больше 60 с; разд. 6: идентификатор интерфейса из EUI-64 устройства или из 16-битного короткого адреса через псевдоадрес PAN:0:short с битом U/L = 0, префикс для SLAAC — ровно 64 бита; разд. 7: link-local = FE80::/64 + идентификатор; разд. 10.1: сжатие HC1 — типичный заголовок IPv6 до 2 октетов (кодирование HC1 и Hop Limit), в полном виде передаётся только Hop Limit
  2. IETF. J. Hui, P. Thubert. Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks. RFC 6282, September 2011 — разд. 1: MTU 802.15.4 127 байт, около 80 октетов полезной нагрузки MAC при включённой защите, скорость канала 250 кбит/с и ниже; HC1 требует 64 бита IID in-line и полные 128 бит для multicast; разд. 2: IPHC заменяет разд. 10 RFC 4944, реализация HC1 не рекомендуется, передавать HC1 не следует; заголовки, не влезшие в первый фрагмент, сжимать нельзя; разд. 3: LOWPAN_IPHC занимает 13 бит, 5 из них в dispatch; в лучшем случае заголовок IPv6 сжимается до 2 октетов при link-local обмене, при маршрутизации через несколько переходов — до 7 (dispatch, IPHC, Hop Limit, по 2 октета адресов), Hop Limit не сжимается, так как уменьшается на каждом переходе; разд. 3.1.1: HLIM 01/10/11 — Hop Limit 1, 64, 255; разд. 4.3.1: порты UDP 0xf0b0…0xf0bf сжимаются до 4 бит — сжатие без состояния, унаследованное от RFC 4944; диапазон не зарезервирован, 16 портов, рекомендуется защищать содержимое, например MIC; разд. 1: новое по сравнению с RFC 4944 — возможность опускать контрольную сумму UDP при наличии MIC верхнего уровня
  3. Zephyr Project. Zephyr Project Documentation (latest): Networking — Overview — Supported Features: сжатие заголовков 6LoWPAN для сетей IEEE 802.15.4 (RFC 4944); IEEE 802.15.4 — только IPv6
Страница помогла?

Нашли ошибку? ·

Смотрите также