Энциклопедия сетевых протоколов

Internet Engineering Task Force (IETF)                     J. Chroboczek
Request for Comments: 8966             IRIF, University of Paris-Diderot
Obsoletes: 6126, 7557                                        D. Schinazi
Category: Standards Track                                     Google LLC
ISSN: 2070-1721                                             January 2021

The Babel Routing Protocol

Протокол маршрутизации Babel

PDF

Аннотация

Babel представляет собой протокол маршрутизации на основе вектора удаленности (distance-vector) с предотвращением петель, который устойчив к отказам и эффективен как в кабельных, так и в беспроводных сетях. Документ описывает протокол маршрутизации Babel и отменяет RFC 6126 и RFC 7557.

Статус документа

Документ относится к категории Internet Standards Track.

Документ является результатом работы IETF¹ и представляет согласованный взгляд сообщества IETF. Документ прошел открытое обсуждение и был одобрен для публикации IESG². Дополнительную информацию о стандартах Internet можно найти в разделе 2 в RFC 7841.

Информация о текущем статусе документа, найденных ошибках и способах обратной связи доступна по ссылке https://www.rfc-editor.org/info/rfc8966.

Авторские права

Copyright (c) 2021. Авторские права принадлежат IETF Trust и лицам, указанным в качестве авторов документа. Все права защищены.

К документу применимы права и ограничения, указанные в BCP 78 и IETF Trust Legal Provisions и относящиеся к документам IETF (http://trustee.ietf.org/license-info), на момент публикации данного документа. Прочтите упомянутые документы внимательно. Фрагменты программного кода, включённые в этот документ, распространяются в соответствии с упрощённой лицензией BSD, как указано в параграфе 4.e документа IETF Trust Legal Provisions, без каких-либо гарантий (как указано в Simplified BSD License).

1. Введение

Протокол маршрутизации Babel на основе вектора удаленности с предотвращением петель предназначен для отказоустойчивой и эффективной маршрутизации для сетей, использующих префиксы и плоскую маршрутизацию (многосвязные сети — mesh), как в сравнительно стабильных проводных системах, так и в очень динамичных беспроводных сетях. Этот документ описывает протокол маршрутизации Babel и отменяет [RFC6126] и [RFC7557].

1.1. Свойства

Основным свойством, которое делает протокол Babel подходящим для нестабильных сетей, является то, что он, в отличие от простых протоколов на основе вектора удаленности [RIP], строго ограничивает частоту и продолжительность аномалий маршрутизации, таких как петли и «черные дыры» в процессе схождения маршрутов. Даже после обнаружения перемещения элемента (mobility event) сеть Babel обычно остается свободной от петель. После такого события Babel быстро пересчитывает конфигурацию, которая не содержит петель и сохраняет связность, но не обязательно является оптимальной. Эта операция во многих случаях даже не требует обмена пакетами. Затем Babel выполняет медленную процедуру схождения (может занимать минуты) для получения оптимальной конфигурации. Это достигается за счет использования упорядоченных маршрутов — метода, впервые примененного в маршрутизации Destination-Sequenced Distance-Vector (упорядоченные по адресатам векторы удаленности) [DSDV].

Более точно, протокол Babel имеет перечисленные ниже свойства:

• когда каждый префикс исходит лишь от одного маршрутизатора, в протоколе Babel не возникает петель;

• когда один префикс исходит от нескольких маршрутизаторов, Babel может иногда создавать временные маршрутные петли, которые исчезают за время, пропорциональное диаметру петли, и больше никогда (до произвольного момента сбора мусора (garbage-collection или GC)) вовлеченные маршрутизаторы не будут попадать в петлю для того же префикса;

• в предположении ограниченной частоты потери пакетов, любые черные дыры, которые могут возникать в результате перемещения элемента, будут устраняться в срок, пропорциональный диаметру сети.

Babel обеспечивает оценку качества каналов и поддерживает достаточно произвольную метрику. При соответствующей настройке Babel может реализовать маршрутизацию по кратчайшему пути (shortest-path) или использовать метрику, например, на основе числа теряемых пакетов.

Узлы Babel устанавливают связи между собой даже при настройке с разными параметрами. Например, мобильный узел с небольшой батареей, может использовать большие временные интервалы (сообщения hello, обновления и т. п.), нежели узел с питанием от электросети. И наоборот, узел с высоким уровнем мобильности может сократить временные интервалы. Возможность создавать такие неоднородные сети делают протокол Babel адаптируемым к работе в неуправляемых и беспроводных средах.

Babel является гибридным протоколом маршрутизации в том смысле, что он может передавать маршруты для разных протоколов сетевого уровня (IPv4 и IPv6), независимо от протокола, используемого для передачи пакетов Babel.

1.2. Ограничения

Протоколу Babel присущи два ограничения, делающие его непригодным в некоторых средах. Во-первых, протокол Babel основан на периодическом обновлении таблиц маршрутизации вместо использования надежного транспорта, что ведет к росту служебного трафика в больших стабильных сетях по сравнению с протоколами, которые передают обновления лишь при наличии изменений. Для таких сетей больше подходят такие протоколы как OSPF [OSPF], IS-IS [IS-IS] или EIGRP³ [EIGRP].

Во-вторых, если не реализован второй алгоритм, описанный в параграфе 3.5.4, Babel устанавливает время удержания при удалении префикса. Хотя это время не применяется к удаляемому префиксу и поэтому не препятствует быстрому схождению после восстановления префикса, оно применимо для более коротких префиксов, которые охватывает удаленный. Это может сделать реализации Babel, не поддерживающие необязательный алгоритм, описанный в параграфе 3.5.4, не подходящими для сетей с автоматическим агрегированием префиксов.

1.3. Уровни требований

Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не нужно (SHALL NOT), следует (SHOULD), не следует (SHOULD NOT), рекомендуется (RECOMMENDED), не рекомендуется (NOT RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе должны интерпретироваться в соответствии с BCP 14 [RFC2119] [RFC8174] тогда и только тогда, когда они набраны заглавными буквами, как показано здесь.

2. Концептуальное описание протокола

Babel является протоколом на основе вектора удаленности с предотвращением петель. Он основан на алгоритме Беллмана-Форда (Bellman-Ford), как известный протокол RIP [RIP], но включает множество усовершенствований, предотвращающих возникновение петель или быстро устраняющих петли без их повторного появления.

Концептуально алгоритма Bellman-Ford выполняется параллельно для каждого источника маршрутной информации (получателя трафика данных). Далее источник обозначается S с напоминанием, что алгоритм выполняется параллельно для всех источников.

2.1. Стоимость, метрика, соседство

Для каждой пары смежных узлов A и B протокол Babel рассчитывает абстрактное значение, называемое стоимостью канала от A к B и обозначаемое C(A, B). Для данного маршрута между любыми двумя (не обязательно смежными) узлами метрикой маршрута будет сумма стоимости всех каналов на пути. Цель алгоритма маршрутизации заключается в расчете для каждого S дерева маршрутов в S с минимальной метрикой.

Стоимость и метрика не обязаны быть целыми числами. В общем случае это могут быть любые числовые значения, удовлетворяющие двум достаточно общим условиям параграфа 3.5.2.

Узел Babel периодически передает сообщения Hello всем своим соседям, а также периодически передает сообщения IHU (I Heard You — я вас слышу) каждому соседу, от которого недавно получено сообщение Hello. На основе информации из сообщений Hello и IHU от соседа B узел A рассчитывает стоимость C(A, B) для канала от A до B.

2.2. Алгоритм Беллмана-Форда

Каждый узел A поддерживает две части данных — оценку расстояния до S — D(A) и следующий маршрутизатор в направлении S — NH(A). Исходно D(S) = 0, D(A) бесконечная, а NH(A) не определен.

Периодически каждый узел B передает всем своим соседям обновление маршрутов в сообщении, содержащем D(B). Когда сосед A узла B получает обновление маршрутов, он проверяет, выбран ли B его следующим интервалом. Если это так, в качестве NH(A) указывается B, а для D(A) устанавливается C(A, B) + D(B). В противном случае A сравнивает C(A, B) + D(B) с текущим значением D(A). Если это значение меньше, полученное обновление анонсирует лучший маршрут по сравнению с выбранным и в качестве NH(A) устанавливается B, а D(A) получает значение C(A, B) + D(B).

Возможен ряд усовершенствований этого алгоритма и они применяются в протоколе Babel. В частности скорость схождения может быть увеличена за счет отправки в дополнение к обычным плановым обновлениям не запланированных «триггерных обновлений» при обнаружении существенных изменений в топологии. Кроме того, узел может поддерживать множество дополнительных маршрутов, которые были анонсированы соседями, отличными от выбранного им соседа, и которые могут применяться сразу же, если произойдет отказ выбранного соседа.

2.3. Временные петли в Bellman-Ford

Хорошо известно, что естественное применение алгоритма Bellman-Ford к распределенной маршрутизации может вызывать временные петли после изменения топологии. Рассмотрим пример, показанный на рисунке.

         B
      1 /|
   1   / |
S --- A  |1
       \ |
      1 \|
         C

После схождения будет D(B) = D(C) = 2 и NH(B) = NH(C) = A.

Предположим, что на канале между S возник отказ, как показано на рисунке.

         B
      1 /|
       / |
S     A  |1
       \ |
      1 \|
         C

При обнаружении этого отказа узел A сменит следующий интервал на B (который продолжает анонсировать маршрут к S с метрикой 2), анонсирует метрику 3, а затем — новый маршрут с метрикой 3. Этот процесс смены выбранных соседей и увеличения их метрики продолжается, пока метрика не станет «бесконечной» (значение превысит все другие метрики, которые протокол маршрутизации способен передавать).

2.4. Условия осуществимости

Алгоритм Bellman-Ford очень устойчив к отказам и его свойства сходимости сохраняются при задержке маршрутизаторами получения маршрутов или отбрасывании некоторых обновлений. Маршрутизаторы Babel отбрасывают полученные анонсы маршрутов, пока они не уверены, что восприятие маршрута не создаст петли. Более формально, определяется условие, когда анонсы маршрутов, известные как «условие осуществимости» (feasibility condition), гарантируют отсутствие маршрутных петель, где все маршрутизаторы игнорируют обновления, не соответствующие условию осуществимости. Фактически, это возвращает алгоритм Bellman-Ford в семейство алгоритмов маршрутизации, параметризуемых условием выполнимости.

Возможно много разных условий выполнимости. Например, BGP можно представить как протокол на основе вектора удаленности с (достаточно радикальным) условием осуществимости — обновления воспринимаются лишь при условии, что номер автономной системы принимающего узла не включен в атрибут AS_PATH этого обновления (отметим, что условие выполнимости в BGP не гарантирует отсутствие временных микропетель в процессе схождения).

Другой пример условия выполнимости применяется в протоколе маршрутизации DSDV [DSDV], а также в протоколе AODV⁴ [RFC3561] и основан на наблюдении, что маршрутные петли могут возникать лишь после переключения маршрутизатора на маршрут, метрика которого больше выбранного ранее маршрута. Поэтому можно считать маршрута выполнимым, когда его метрика на локальном узле будет не больше метрики выбранного с маршрута, т. е. анонс с метрикой D(B) воспринимается узлом A, когда C(A, B) + D(B) <= D(A). Если все маршрутизаторы следуют этому ограничению, метрика на каждом маршрутизаторе не возрастает и всегда сохраняется следующий инвариант: если A выбрал B как следующий интервал, то D(B) < D(A), что означает отсутствие петель в графе пересылки.

Babel использует более тонкое условие выполнимости, выведенное из EIGRP [DUAL]. Для маршрутизатора A, определяется дистанция выполнимости (достижимости) A FD(A), как меньшая из метрик, анонсируемая A для S любому из своих соседей. Обновление переданное соседом B считается выполнимым, если анонсируемая узлом B метрика D(B) строго меньше дистанции достижимости A, т. е. D(B) < FD(A).

Легко видеть, что это условие не более ограничительно по сравнению с DSDV. Предположим, что узел A выполняет условие достижимости DSDV. Тогда D(A) не возрастает и в любой момент D(A) <= FD(A). Далее предположим, что A получает соответствующее условию DSDV обновление с анонсом метрики D(B). Поскольку обновление соответствует DSDV, C(A, B) + D(B) <= D(A), следовательно D(B) < D(A), а, поскольку D(A) <= FD(A), то и D(B) < FD(A). Чтобы увидеть, что это меньшее ограничение, рассмотрим приведенный ниже рисунок, где A выбрал маршрут через B и D(A) = FD(A) = 2. Поскольку D(C) = 1 < FD(A), маршрут через C достижим для A, хотя его метрика C(A, C) + D(C) = 5 больше чем для выбранного в данный момент маршрута.

   B
1 / \ 1
 /   \
S     A
 \   /
1 \ / 4
   C

Чтобы показать, что условие выполнимости сохраняет гарантию отсутствия петель, напомним, что с тот момент, когда A воспринимает обновление от B, анонсируемая B метрика D(B) не меньше FD(B), поскольку она меньше FD(A), в этот момент FD(B) < FD(A). Поскольку это свойство сохраняется, когда A передает обновления и выбирает другой следующий интервал, это будет верно всегда и гарантирует отсутствие петель в графе пересылки.

2.5. Решение проблемы истощения — нумерованные маршруты

Обычно определенное выше условие осуществимости вызывает истощение (starvation), когда у маршрутизатора не остается доступных маршрутов. Рассмотрим показанную на рисунке ситуацию, где A и B выбрали прямой маршрут к S.

   A
1 /|        D(A) = 1
 / |       FD(A) = 1
S  |1
 \ |        D(B) = 2
2 \|       FD(B) = 2
   B

Предположим, что канал между A и S оказался разорван.

   A
   |
   |       FD(A) = 1
S  |1
 \ |        D(B) = 2
2 \|       FD(B) = 2
   B

Единственный маршрут от A до S, проходящий через B, не является осуществимым и страдает от ложного истощения. В этот момент все субдерево, страдающее от истощения, должно быть сброшено, что, по сути, и делает EIGRP при выполнении глобальной синхронизации всех маршрутов в истощенном субдереве («активная» фаза EIGRP).

Babel менее резко реагирует на истощение, используя нумерованные маршруты, введенные в DSDV и адаптированные AODV. В дополнение к метрике каждый маршрут имеет порядковый номер, который является неубывающим целым числом, распространяемым через сеть без изменения и инкрементируемым лишь источником. Пара (s, m), где s — порядковый номер, а m — метрика, называется дистанцией (расстоянием).

Полученное обновление выполнимо если оно новее дистанции достижимости, поддерживаемой принимающим узлом или столь же свежее и его метрика строго меньше. Более формально, если FD(A) = (s, m), обновление с дистанцией (s’, m’) выполнимо, если s’ > s или s = s’ и m’ < m.

Предположим, что S имеет порядковый номер 137. Тогда приведенный выше рисунок примет вид

      A
      |
      |       FD(A) = (137, 1)
   S  |1
    \ |        D(B) = (137, 2)
   2 \|       FD(B) = (137, 2)
      B

После того, как S увеличит свой порядковый номер и новый номер будет распространен узлу B, мы получим

   A
   |
   |       FD(A) = (137, 1)
S  |1
 \ |        D(B) = (138, 2)
2 \|       FD(B) = (138, 2)
   B

И маршрут через B становится выполнимым.

Отметим, что порядковые номера используются для определения достижимости, но они не применяются при выборе маршрутов. Узел игнорирует порядковые номера в процессе определения лучшего маршрута к данному адресату (параграф 3.6). Иное поведение вызвало бы осцилляции маршрутов при распространении порядкового номера через сеть и могло бы даже создать постоянные «черные дыры» с экзотической метрикой.

2.6. Запросы

В DSDV порядковый номер источника увеличивается периодически. Маршрут становится выполнимым после того, как источник увеличит свой порядковый номер и распространит новое значение через сеть, что в общем случае может потребовать значительного времени.

Babel использует другой подход. Когда узел обнаруживает, что он страдает от потенциально ложного истощения, этот узел передает явный запрос источнику для получения нового порядкового номера. Этот запрос пересылается поэтапно (hop by hop) к источнику, независимо от условия выполнимости. При получении запроса источник увеличивает свой порядковый номер и в широковещательном режиме передает обновление, которое пересылается запросившему узлу.

Отметим, что после изменения топологии сети не все такие запросы в общем случае будут попадать к источнику, поскольку некоторые будут отправлены через каналы, которые в данный момент разорваны. Однако, если сеть все еще подключена, хотя бы один из страдающих от ложного истощения узлов имеет (невыполнимый) маршрут к источнику. Поэтому при отсутствии потери пакетов хотя бы один запрос попадет к источнику. Для компенсации потери пакетов запросы могут повторяться несколько раз.

Поскольку запросы пересылаются независимо от условий выполнимости, они могут в общем случае попасть в петлю пересылки, которой можно избежать, детектируя дубликаты пересылаемых запросов.

2.7. Префикс от нескольких маршрутизаторов

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

Поскольку синхронизация порядковых номеров между маршрутизаторами проблематична, Babel считает маршруты к одному префиксу разными сущностями, когда они приходят от разных маршрутизаторов. Каждый анонс маршрутов содержит router-id создавшего его маршрутизатора, а дистанции выполнимости поддерживаются не на уровне префикса, а на уровне источника, который представляет собой пару (router-id — префикс). Фактически Babel гарантирует отсутствие петель в графе пересылки для каждого источника. Поскольку объединение множества ациклических графов не всегда является ациклическим, Babel не гарантирует отсутствия петель в случае происхождения префикса от нескольких маршрутизаторов, но любые петли устраняются на время, пропорциональное диаметру петли, когда обновление «обойдет петлю».

Рассмотрим показанную ниже топологию, где узел A выбрал маршрут по умолчанию через S, а B — через S’.

           1     1     1
::/0 -- S --- A --- B --- S' -- ::/0

Предположим, что одновременно отказали оба принятых по умолчанию маршрута. В этом случае ничто не мешает узлу A переключиться на B, а B — одновременно переключиться на A. Однако, как только A успешно анонсирует новый маршрут узлу B, маршрут через A станет невыполнимым для B. И наоборот, как только B анонсирует свой маршрут через A, маршрут через B станет невыполнимым для A.

Фактически петля исчезает не позднее прохождения маршрутной информации через нее. Поскольку этот процесс может быть задержан потерей пакетов, Babel прилагает некоторые усилия для обеспечения гарантированной доставки обновлений после смены router-id (параграф 3.7.2).

Кроме того, после анонсирования маршрутизаторами двух маршрутов оба источника будут в их таблицах источников, что предотвратит их повторное попадание в маршрутную петлю, включающую маршруты от S и S’ (вплоть до времени источника GC, для которого, если позволяет память, можно устанавливать произвольно большое значение).

2.8. Перекрывающиеся префиксы

В предыдущем обсуждении предполагалось, что префиксы разъединены (не перекрываются) как в случае плоской (многосвязной — mesh) маршрутизации. Однако на практике префиксы могут перекрываться, например, принятый по умолчанию маршрут перекрывается со всеми маршрутами в сети.

После отказа маршрута в общем случае некорректно переключаться на маршрут, включающий отказавший. Рассмотрим показанный на рисунке пример.

           1     1
::/0 -- A --- B --- C

Предположим, что узел C отказал. Если B пересылает пакеты для C по принятому по умолчанию маршруту, возникнет петля, которая будет сохраняться, пока A не узнает об отсутствии у B прямого маршрута к C. Узел B избегает этой ловушки, устанавливая «невыполнимый» маршрут после вызванного отказом пропадания маршрута. Этот маршрут поддерживается, пока не будет гарантии, что утраченный маршрут отменен всеми соседями B (параграф 3.5.4).

3. Работа протокола

Каждый узел Babel (speaker) имеет свой идентификатор (router-id) — произвольную стороку размером 8 октетов, которая предполагается уникальной в домене маршрутизации. Идентификаторы могут выделяться, например, случайным образом или выводиться из адресов канального уровня. Кодирование протокола становиться чуть более компактным при выделении router-id в стиле присвоения идентификаторов узлов IPv6 (см. описание флага R в параграфе 4.6.9.).

3.1. Передача и прием сообщений

Пакеты протокола Babel передаются в теле дейтаграмм UDP (раздел 4). Каждый пакет Babel может содержать множество (возможно пустое) TLV, большинство из которых могут включать суб-TLV.

Трафик управления Babel может передаваться по протоколу IPv6 или IPv4, а префиксы любого семейства адресов могут анонсироваться через любой протокол. Таким образом, имеется по меньшей мере две модели естественного развртывания — использование исключительно IPv6 для всего трафика управления или работа двух разных экземпляров протокола, по одному для каждого семейства адресов. Рекомендуется применять исключительное использование IPv6 для всего управляющего трафика, поскольку одновременное применение двух протоколов удваивает трафик, предназначенный для обнаружения соседей и оценки качества каналов.

Адресом отправителя пакетов Babel всегда является индивидуальный адрес (link-local в случае IPv6). Пакеты Babel могут передаваться по стандартному (link-local) групповому или индивидуальному (link-local) адресу. При обычной работе узел Babel передает своим соседям групповые и индивидуальные пакеты.

За исключением подтверждений, все Babel TLV могут передаваться по групповому или индивидуальному адресу и семантика TLV от этого не зависит. Поэтому узлу Babel не требуется определять адрес получателя в принятом пакете для его интерпретации.

К передаваемым узлом Babel пакетам могут применяться произвольные вариации задержки (jitter). Исходящие TLV буферизуются и их следует передавать со случайной задержкой. Это преследует две цели — избежать синхронизации узлов Babel в сети [JITTER] и обеспечить возможность объединения множества TLV в один пакет.

Максимальная задержка TLV может зависеть от TLV. Когда описание протокола указывает срочность TLV (параграфы 3.7.2 и 3.8.1), такие TLV должны передаваться в течение короткого времени, называемого тайм-аутом срочности (urgent timeout), рекомендуемые значения тайм-аута приведены в Приложении B. Когда TLV регулируется тайм-аутом, заданным в предшествующем TLV, как в случае подтверждений (параграф 4.6.4), обновлений (параграф 3.7) и IHU (параграф 3.4.2), TLV должны передаваться достаточно быстро, чтобы уложиться в указанное время (с небольшим запасом на задержку распространения). В остальных случаях TLV следует отправлять в течение половины интервала Multicast Hello.

Для предотвращения отбрасывания пакетов (отправителем или получателем) следует вносить задержку между последовательными пакетами с одного интерфейса с учетом ограничений, указанных выше. Однако следует отметить, что задержка может препятствовать возможности агрегирования пакетов для некоторых канальных технологий (например, IEEE 802.11 [IEEE802.11]).

3.2. Структуры данных

В этом параграфе описаны структуры данных, поддерживаемые каждым узлом Babel. Это концептуальное описание и узлы Babel могут применять иные структуры данных, обеспечивающие соответствие результирующего протокола данному документу. Например, вместо поддержки одной таблицы, содержащей выбранные и резервные (fallback) маршруты, как описано в параграфе 3.2.6, реализация может использовать две разных таблицы для выбранных и резервных маршрутов.

3.2.1. Арифметика порядковых номеров

Порядковые номера (seqno) включаются во многие структуры данных Babel и интерпретируются как целые числа с модулем 2¹⁶. Используемая в этом документе арифметика порядковых номеров описана ниже.

Для данного порядкового номера s и неотрицательного целого числа n сумма s и n определяется выражением

      s + n (по модулю 216) = (s + n) MOD 2^(16)

или его эквивалентом

      s + n (по модулю 216) = (s + n) AND 65535

где MOD операция деления по модулю, дающая неотрицательное целое число, а AND — побитовое пересечение (И). Для двух порядковых номеров s и s’ отношение s меньше s’ (s < s’) определяется выражением

      s < s' (по модулю 216), когда 0 < ((s' - s) MOD 2^(16)) < 32768

или его эквивалентом

      s < s' (по модулю 216), когда s /= s' и ((s' - s) AND 32768) = 0.

3.2.2. Порядковый номер узла

Порядковый номер узла — это 16-битовое целое число, включаемое в обновления, передаваемые для маршрутов, исходящих из этого узла.

Узлы инкрементируют свой порядковый номер (модуль 2¹⁶) при получении запроса на новый номер (параграф 3.8.1.2). Узлам не следует инкрементировать свой порядковый номер спонтанно, поскольку увеличение seqno снижает вероятность того, что другие узлы будут иметь выполнимые альтернативные маршруты при отказе выбранных ими маршрутов.

3.2.3. Таблица интерфейсов

Таблица интерфейсов содержит список всех интерфейсов, на которых узел использует протокол Babel. Каждая запись таблицы включает порядковый номер исходящего Multicast Hello (16-битовое целое число, которое передается в каждом Multicast Hello TLV на этом интерфейсе и инкрементируется с модулем 2¹⁶ при передаче Multicast Hello). Отметим, что порядковый номер Multicast Hello не связан с порядковым номером узла.

С каждой записью в таблице интерфейсов связано два таймера. Таймер периодических сообщений Multicast Hello управляет плановой отправкой пакетов Multicast Hello и IHU (параграф 3.4). Таймер периодических обновлений (Update) управляет периодической отправкой маршрутных обновлений (параграф 3.7.1). Рекомендуемые значения для таймеров приведены в Приложении B.

3.2.4. Таблица соседей

Таблица соседей содержит список всех смежных интерфейсов, от которых недавно были получены пакеты Babel. Таблица индексируется по парам (интерфейс — адрес) и каждая запись содержит:

• интерфейс локального узла, через который доступен этот сосед;

• адрес интерфейса соседа;

• историю недавно принятых пакетов Multicast Hello от этого соседа (это может быть, например, последовательность из n битов с небольшим n, указывающая какие из последних n сообщений hello от данного соседа были приняты локальным узлом);

• история недавно полученных сообщений Unicast Hello от этого соседа;

• значение «стоимости передачи» из последнего пакета IHU, полученного от этого соседа, или шестнадцатеричное значение FFFF (бесконечность), если истек таймер IHU для данного соседа;

• ожидаемый порядковый номер Multicast Hello от этого соседа (целое число с модулем 2¹⁶);

• ожидаемый порядковый номер Unicast Hello от этого соседа (целое число с модулем 2¹⁶);

• порядковый номер исходящего Unicast Hello для этого соседа (целое число с модулем 2¹⁶), передаваемый в каждом Unicast Hello TLV и инкрементируемый (модуль 2¹⁶) при отправке Unicast Hello (отметим, что номер исходящего Unicast Hello для соседа отличается от номера исходящего Multicast Hello для интерфейса).

С каждой записью таблицы связано три таймера — Multicast Hello, задающий интервал, передаваемый в плановых Multicast Hello TLV от этого соседа, Unicast Hello с интервалом из плановых Unicast Hello TLV и IHU со значением, кратным (в несколько раз) интервалу из IHU TLV (см. Приложение B).

Отметим, что таблица соседей индексируется по адресам IP, а не router-id, поскольку смежность существует между интерфейсами, а не узлами. Поэтому два узла с несколькими интерфейсами могут иметь несколько отношений смежности, что часто возникает в беспроводных сетях, где участвуют узлы с несколькими радио-модулями.

3.2.5. Таблица источников

Таблица источников служит для записи дистанций выполнимости (feasibility distance) и индексируется триплетами (prefix, plen, router-id). Каждая запись таблицы включает:

• префикс (prefix, plen), где plen указывает размер префикса в битах, применимый к этой записи;

• router-id маршрутизатора, от которого исходит этот префикс;

• пару (seqno, metric), указывающую дистанцию выполнимости для этого источника.

С каждой записью связан таймер «сборки мусора» (garbage-collection), имеющий значение порядка минут и сбрасываемый в соответствии с параграфом 3.7.3.

3.2.6. Таблица маршрутов

Таблица маршрутов содержит известные узлу маршруты и индексируется триплетом (prefix, plen, neighbour). Каждая запись таблицы включает:

• источник (prefix, plen, router-id) для которого анонсирован этот маршрут;

• сосед neighbour (запись в таблице соседей), анонсировавший этот маршрут;

• метрика, с которой маршрут анонсирован соседом, или шестнадцатеричное значение FFFF (бесконечность) для недавно утраченного маршрута;

• порядковый номер, с которым маршрут анонсирован;

• адрес next-hop для этого маршрута;

• флаг, указывающий выбор маршрута, т. е. его использование для пересылки и анонсирование.

С каждой записью связан таймер срока действия маршрута. Инициализация и сброс таймера описаны в параграфе 3.5.3.

Отметим, что с каждым маршрутом связаны две разных пары (seqno, metric), одна из которых указывает дистанцию (протяженность) маршрута в таблице, другая — дистанцию выполнимости, которая хранится в таблице источников и используется для всех маршрутов с данным источником.

3.2.7. Таблица ожидающих запросов порядковых номеров

Таблица ожидающих запросов seqno содержит список запросов порядкового номера, которые передал локальный узел (порождены локально или пересланы), но ответы еще не были получены. Таблица индексируется триплетом (prefix, plen, router-id) и каждая запись содержит:

• prefix, plen, router-id и seqno из запроса;

• сосед, для которого пересылался запрос (при наличии);

• небольшое целое число, указывающее повторов, если запрос не был выполнен.

С каждой записбю связан таймер, управляющий повтором запроса и сроком его действия.

3.3. Подтверждения и запросы подтверждений

Узел Babel может запросить у соседа явного подтверждения приема отправленного тому пакета. Хотя использование подтверждений не обязательно, каждый узел Babel должен поддерживать возможность ответа на такие запросы.

Подтверждения должны передаваться по индивидуальному адресу, но запросы могут отправляться как на индивидуальные, так и на групповые адреса. В последнем случае отвечают все получившие запрос узлы.

Передача запросов на подтверждение определяется локальной политикой. Простейшая стратегия — никогда не запрашивать подтверждений и полагаться на периодические обновления в качестве гарантии того, что все доступные маршруты в конечном итоге распространяются по всему домену маршрутизации. Для повышения скорости схождения и снижения объема трафика управления запросы подтверждения могут служить для надежной отправки срочных обновлений (параграф 3.7.2) и отзывов (параграф 3.5.4), особенно при небольшом числе соседей на данном интерфейсе. Поскольку протокол Babel разработан для корректной работы при потере пакетов в ненадежных средах, отправка всех пакетов с запросом подтверждения не обязательна и не рекомендуется, поскольку подтверждения создают дополнительный трафик и могут вызывать дополнительный обмен ARP (Address Resolution Protocol) или ND (Neighbour Discovery).

3.4. Нахождение соседей

Нахождение соседей (neighbour acquisition) — процесс, с помощью которого узел Babel определяет набор соседей, слышимых через каждый из его интерфейсов и устанавливает двухстороннюю достижимость (доступность). В ненадежных средах обнаружение соседей дополнительно обеспечивает статистику, которая может быть полезна при расчете качества каналов.

До того как узел Babel сможет обмениваться маршрутными данными с соседом, он должен создать для этого соседа запись в своей таблице соседей. Когда это следует делать, определяет реализация и приемлемые стратегии включают создание записи при получении любого пакета Babel или при анализе Hello TLV. Для экономии системных ресурсов реализации следует отбрасывать записи, которые не используются слишком долго. Приемлемой стратегией является отбрасывание соседей по тайм-ауту или при пустой истории соответствующих сообщений Hello (см. Приложение A.2).

3.4.1. Определение обратной достижимости

Каждый узел Babel регулярно или не регулярно передает своим соседям Hello TLV для индикации свое активности. В каждом Hello TLV содержится увеличивающийся (модуль 2¹⁶) порядковый номер и верхняя граница интервала отправки следующего Hello того же типа (см. ниже). Если установлен интервал 0, Hello TLV не указывает нового «обещания». При этом интервал из предыдущего Hello того же типа остается в силе для следующего Hello (если недавнее сообщение Hello нужного типа было получено в момент t0 и включало интервал i, прежнее обещание передать Hello до момента t0 + i остается в силе). Сообщения Hello считаются «плановыми», если они включают отличный от 0 интервал.

Имеется два типа Hello — Multicast Hello, использующие счетчик Hello на уровне интерфейса (Multicast Hello seqno), и Unicast Hello со счетчиком для соседа (Unicast Hello seqno). Сообщения Multicast Hello с данным seqno должны передаваться всем соседям на данном интерфейсе путем отправки по групповому адресу или по индивидуальным адресам каждого соседа (т. е. название Multicast Hello является не совсем точным). Unicast Hello с данным given обычно следует передавать лишь одному соседу (по индивидуальному адресу), поскольку порядковые номера для разных соседей в общем случае не синхронизированы.

Multicast Hello, переданные по групповому адресу могут служить для обнаружения соседей. Узлу следует передавать периодические (плановые) Multicast Hellos, если обнаружение соседей не выполняется вне протокола Babel. Узел может передавать Unicast Hello или неплановые Hello любого типа по любой причине, например для снижения группового трафика или повышения надежности на каналах со слабой поддержкой групповой адресации.

Узел может передать плановое сообщение Hello заранее, а также может изменить запланированный интервал Hello. Интервал Hello можно сократить в любой момент, а также можно увеличить непосредственно перед отправкой Hello TLV, но не следует увеличивать в другие моменты (эквивалентно, узлу следует передать плановые Hello сразу после увеличения интервала Hello).

Что делать с полученными Hello TLV и какую статистику для них поддерживать, определяет локальная реализация. Обычно узлы поддерживают тот или иной тип истории недавно принятых Hello. Пример подходящего алгоритма представлен в Приложении A.1.

После приема Hello или определения его пропуска узел пересчитывает стоимость ассоциации (параграф 3.4.3) и запускает процедуру выбора маршрута (параграф 3.6).

3.4.2. Двухстороннее определение достижимости

Для организации двухсторонней доступности каждый узел периодически передает IHU TLV (я вас слышу) каждому из своих соседей. Поскольку IHU содержат явный интервал, их можно передавать реже, чем Hello для снижения уровня маршрутного трафика в плотных сетях. В частности, их следует передавать реже Hello на каналах с незначительными потерями. Хотя IHU концептуально являются индивидуальными, их можно передавать по групповому адресу, чтобы избежать лишних обменой ARP или Neighbour Discovery и агрегировать множество IHU в один пакет.

В дополнение к периодическим IHU узел может в любой момент передать неплановый пакет IHU. Узел также может в любой момент снизить интервал IHU и может увеличить этот интервал непосредственно перед отправкой IHU, но не следует увеличивать интервал в другие моменты (эквивалентно, узлу следует передавать дополнительные IHU сразу после увеличения интервала Hello).

В каждом IHU TLV содержатся две части данных — rxcost для канала (стоимость приема) с точки зрения отправителя, используемое соседом для расчета стоимости канала (параграф 3.4.3), и интервал между периодическими пакетами IHU. Принявший IHU узел устанавливает значение txcost (стоимость передачи), поддерживаемое в таблице соседей, в соответствии со значением в IHU и сбрасывает таймер IHU, связанный с данным соседом, до значения кратного (в несколько раз) интервалу, полученному в IHU (см. Приложение B). По истечении таймера IHU для соседского txcost устанавливается бесконечное значение.

После обновления соседского txcost принимающий узел пересчитывает стоимость для соседа (параграф 3.4.3) и запускает процедуру выбора маршрута (параграф 3.6).

3.4.3. Расчет стоимости

Стоимость канала к соседу (neighbourship association) рассчитывается по значениям из таблицы соседей, где хранится статистика приема Hello и значения txcost, рассчитанные из пакетов IHU.

Для каждого соседа узел Babel рассчитывает значения, называемое rxcost. Оно обычно выводится из статистики Hello, которая может комбинироваться с другими данными, такими как статистика канального уровня. Значение rxcost передается соседу в каждом IHU.

Поскольку узлы не обязательно передают периодические Unicast Hello, но обычно передают Multicast Hello (параграф 3.4.1), узлу следует использовать алгоритм, который дает конечное значение rxcost, когда имеются лишь Multicast Hello, если не требуется взаимодействие лишь с узлами, которые передают только Multicast Hello.

Использование txcost и rxcost при расчете стоимости канала определяется локальными правилами. Для корректности работы Babel должны выполняться приведенные ниже условия:

• значение стоимости всегда положительно;

• если недавно не было принято Hello TLV любого типа, стоимость будет бесконечной;

• если txcost имеет бесконечное значение, стоимость будет бесконечной.

Рекомендуемая стратегия расчета стоимости канал приведена в Приложении A.2.

3.5. Поддержка таблицы маршрутизации

Концептуально обновления Babel задает квинтет (prefix, plen, router-id, seqno, metric), где (prefix, plen) — префикс для маршрута, router-id — идентификатор маршрутизатора, создавшего обновление, seqno — не уменьшающееся целое число (модуль 2¹⁶) — порядковый номер маршрутизатора-источника, metric — анонсируемая метрика.

Перед восприятием обновления оно проверяется на предмет выполнимости (параграф 3.5.1), что обеспечивает предотвращение маршрутных петель. Если условие осуществимости не выполняется, обновление игнорируется или маршрут не выбирается, как описано в параграфе 3.5.3. Если условие выполнимости обеспечено, обновление не может создать маршрутную петлю.

3.5.1. Условие осуществимости

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

Дистанция выполнимости задается парой (seqno, metric), где seqno — целое число с модулем 2¹⁶, а метрика — положительное целое число. Дистанции сравниваются лексикографически с инвертированием номера — дистанция (seqno, metric) считается строго лучше (seqno’, metric’), что записывается в форме

      (seqno, metric) < (seqno', metric')

когда

      seqno > seqno' или (seqno = seqno' и metric < metric')

где порядковые номера сравниваются по модулю 2¹⁶.

С данным источником (prefix, plen, router-id) дистанция выполнимости узла для этого источника будет минимальной (в соответствии с определенным выше порядком) среди дистанций из всех конечных обновлений, когда-либо переданных этим узлом для префикса (prefix, plen) и данного router-id. Дистанции выполнимости хранятся в таблице источников, как описано в параграфе 3.7.3.

Принятое обновление выполнимо, если оно является отзывом (метрика имеет шестнадцатеричное значение FFFF) или анонсируемая дистанция строго лучше (в соответствии с приведенным выше определением) дистанции выполнимости для соответствующего источника. Точнее говоря, анонс маршрута в (prefix, plen, router-id, seqno, metric) выполним, при выполнении одного из приведенных ниже условий:

• метрика конечна;

• нет записи с таблице источников с индексом (prefix, plen, router-id);

• в таблице источников имеется запись (prefix, plen, router-id, seqno’, metric’) и выполняется одно из условий:

  • seqno’ < seqno;

  • seqno = seqno’ и metric < metric’.

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

3.5.2. Расчет метрики

Метрика маршрута рассчитывается из метрики, анонсированной соседом, и стоимости канала к соседу. Подобно расчету стоимости, вычисление метрики определяется локальной политикой. Используемая Babel функция расчета метрики M(c, m) по локально рассчитанной стоимости канала c и анонсированной соседом метрике m должна лишь соответствовать двум условиям:

• если стоимость c бесконечная, M(c, m) также бесконечна;

• функция M является строго монотонной, M(c, m) > m.

Кроме того, для метрики следует выполнять условие

   если m <= m', то M(c, m) <= M(c, m')

Хотя строгая монотонность функции важна для целостности сети (иначе могут возникать сохраняющиеся петли), второе условие (дистрибутивность слева) не так важно и при его нарушении Babel все равно обеспечивает схождение беспетлевой конфигурации, но может не обеспечиваться глобальной оптимизации (фактически такой оптимизации может просто не существовать).

Приведенные выше условия легко выполняются при использовании аддитивной метрики, т. е. при определении M(c, m) = c + m. Поскольку аддитивная метрика полезна для многий вариантов расчета стоимости, рекомендуется применять ее по умолчанию. В Приложении C описаны методы, позволяющие менять значения той или иной метрики без риска возникновения маршрутных петель.

3.5.3. Получение маршрутов

Когда узел Babel получает обновление (prefix, plen, router-id, seqno, metric) от соседа neigh, он проверяет наличие в таблице маршрутов записи с индексом (prefix, plen, neigh). Если такой записи нет, выполняются следующие операции:

• если обновление невыполнимо, его можно игнорировать;

• если метрика бесконечна (обновление служит отзывом неизвестного маршрута), обновление игнорируется;

• в остальных случаях в таблицу маршрутов включается новая запись с индексом (prefix, plen, neigh), источником (prefix, plen, router-id), порядковым номером seqno и анонсируемой метрикой из обновления.

Если запись имеется в таблице, выполняются следующие операции:

• если запись выбрана, обновление невыполнимо и router-id в обновлении совпадает с идентификатором маршрутизатора в записи, эту запись можно игнорировать;

• в остальных случаях порядковый номер записи, анонсируемая метрика, метрика и router-id одновляются, даже когда для таймера срока действия маршрута установлено значение кратное (в несколько раз) интервалу, включенному в обновление (см. Приложение B). Если обновление невыполнимо, запись (невыполнимая) должна незамедлительно стать не выбранной. Если обновление вызвало смену router-id в записи, должно быть передано своевременное уведомление (возможно отзыв), как указано в параграфе 3.7.2.

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

При срабатывании таймера срока действия маршрута поведение за висит от конечности метрики маршрута. Если метрика конечна, для нее устанавливается бесконечное значение и таймер сбрасывается. Если же метрика уже является бесконечной, маршрут удаляется из таблицы.

После обновления таблицы маршрутов запускается процедура выбора (параграф 3.6).

3.5.4. Время удержания

Когда префикс P отзывается (поскольку все маршруты стали невыполнимыми или имеют бесконечную метрику в результате завершения срока действия или по иной причине) и доступен более короткий префикс P’, охватывающий P, в общем случае P’ не может применяться для маршрутизации пакетов в P без риска появления петли (параграф 2.8).

Для предотвращения этой проблемы при отзыве префикса P поддерживается запись таблицы маршрутов с бесконечной метрикой, как описано в параграфе 3.5.3. Пока запись поддерживается, пакеты с адресом из P недопустимо пересылать по маршруту с более коротким префиксом. Запись удаляется из таблицы, как только будут получено обновление для P с конечной метрикой и выбран соответствующий маршрут. Если такого обновления не ожидается, бесконечную метрику следует поддерживать по меньшей мере до того момента, пока не будет гарантии, что ни один сосед не выбрал текущий узел в качестве следующего интервала (next-hop) для префикса P. Это можно сделать любым из двух способов:

• дождаться завершения срока действия маршрута по таймеру (параграф 3.5.3);

• передать отзыв с запросом подтверждения (параграф 3.3) каждому доступному соседу, который явно не отозвал префикс P, и дождаться всех подтверждений.

Первый вариант проще и гарантирует, что в этот момент для всех маршрутов к префиксу P, указывающих на текущий узел, срок действия закончился. Однако, поскольку срок действия может быть достаточно большим (несколько минут), такое решение препятствует автоматическому агрегированию, создавая ложные «черные дыры» для агрегированных маршрутов. Рекомендуется применять второй вариант, поскольку он значительно сокращает время недоступности префикса при наличии агрегированных маршрутов.

3.6. Выбор маршрута

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

Протокол Babel поддерживает гибкие правила выбора маршрутов, при этом должны обеспечиваться два свойства:

• маршруты с бесконечной метрикой (отозванные маршруты) никогда не выбираются;

• невыполнимые маршруты никогда на выбираются.

Узлы Babel с разными правилами выбора могут взаимодействовать и не будут создавать петель при выполнении этих условий.

При выборе маршрутов недопустим учет порядковых номеров и недопустимо отдавать предпочтение маршруту с большим (более новым) seqno. Отказ от этого будет приводить к осцилляциям маршрутов при распространении нового номера по сети и может вызывать сохраняющиеся «черные дыры», если используемая метрика не дистрибутивна слева (параграф 3.5.2).

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

Для предотвращения такой нестабильности в стратегию выбора маршрута следует включать гистерезис, т. е. учитывать историю маршрута и менять выбранный маршрут на другой, если тот был лучше в течение некоторого времени. Рекомендуемый алгоритм гистерезиса представлен в Приложении A.3.

После выбора маршрута передаются триггерные уведомления (параграф 3.7.2) и запросы (параграф 3.8.2).

3.7. Передача обновлений

Узел Babel анонсирует соседям свой набор выбранных маршрутов. Обычно это выполняется путем отправки одного или множества групповых пакетов с Update TLV через все подключенные интерфейсы. Однако для канальных технологий, где групповая передача менее эффективна по сравнению с индивидуальной, можно передавать множество копий индивидуальных пакетов, особенно при небольшом числе соседей.

Кроме того, для надежного и своевременного устранения «черных дыр» узел Babel может передавать отзывы (обновления с бесконечной метрикой) для недавно отозванных префиксов. Если обновление предназначено для маршрута, внесенного в домен Babel локальным узлом (например, оно содержит адрес локального интерфейса, префикс подключенной напрямую сети или префикс из другого протокола маршрутизации), в качестве router-id указывается идентификатор локального маршрутизатора, для метрики указывается произвольное конечное значение (обычно 0) и включается порядковый номер локального маршрутизатора.

Если обновление предназначено для маршрута от другого узла Babel, router-id и порядковый номер берутся из записи таблицы маршрутов, а метрика рассчитывается в соответствии с параграфом 3.5.2.

3.7.1. Периодические обновления

Каждый узел Babel должен анонсировать каждый из выбранных маршрутов на каждом интерфейсе хотя бы один раз в каждый интервал Update. Поскольку в Babel не возникает проблем от маршрутных петель (не требуется «счет до бесконечности») и протокол основан на триггерных обновлениях (параграф 3.7.2), полная передача маршрутов происходит достаточно редко (интервалы предложены в Приложении B).

3.7.2. Триггерные обновления

В дополнение к периодическим обновлениям узлы Babel передают неплановые (триггерные) обновления для информирования своих соседей о существенных изменениях в топологии сети.

Изменение router-id в выбранном маршруте для данного префикса может служить индикацией образующейся петли, поэтому при каждой смене router-id для данного адресата узел должен передать обновление как срочный блок TLV (см. параграф 3.1). Кроме того, следует предпринять разумные попытки обеспечить получение этого обновления всеми соседями.

Для этого есть две стратегии. Если число соседей невелико, разумно передать обновление с запросом подтверждения, которое будет повторяться несколько раз, пока все соседи не подтвердят прием пакета. При большом числе соседей такой запрос подтверждений может вызвать ощутимый трафик и более предпочтительным вариантом может оказаться простое повторение обновления несколько раз (скажем, 3 для беспроводных сетей или 2 для кабельных). Недопустимо передавать больше 5 копий и их следует разделять небольшим интервалом (параграф 3.1).

Отзыв маршрута вызывает меньше беспокойства — если он придет не всем соседям, может возникнуть «черная дыра», которая, в отличие от петли, не представляет опасности для целостности сети. При отзыве маршрута узлу следует передать триггерное обновление, а также следует предпринять разумные попытки доставить его всем соседям.

Узел может передавать триггерное уведомление при существенном изменении метрики для данного префикса в результате получения обновления, изменения стоимости канала или выбора другого следующего узла (next-hop). Узлу не следует передавать триггерные обновления по иным причинам, таким как незначительные флуктуации метрики маршрутов, смене next-hop без существенного изменения метрики маршрута или распространении нового порядкового номера (за исключением выполнения запроса, как указано в параграфе 3.8).

3.7.3. Поддержка дистанций достижимости

Перед отправкой обновления (prefix, plen, router-id, seqno, metric) с конечной метрикой (т. е. не отзыва) узел Babel обновляет дистанцию выполнимости в таблице источников, как описано ниже.

Если в таблице источников нет записи с индексом (prefix, plen, router-id), создается запись со значениями(prefix, plen, router-id, seqno, metric). Если имеется запись (prefix, plen, router-id, seqno’, metric’) она обновляется:

• если seqno > seqno’, устанавливается seqno’ := seqno, metric’ := metric;

• если seqno = seqno’ и metric’ > metric, устанавливается metric’ := metric;

• в остальных случаях ничего не меняется.

Для записи сбрасывается таймер сборки мусора. Отметим, что дистанция выполнимости не обновляется и таймер сборки мусора не сбрасывается при отправке отзыва маршрута (обновления с бесконечной метрикой).

По завершении отсчета таймера сборки мусора запись удаляется из таблицы источников.

3.7.4. Расщепление горизонта

При работе в транзитивной топологии с симметричными каналами (например, соединения «точка-точка» или проводная ЛВС, такая как Ethernet) узлу Babel следует использовать оптимизацию, называемую «расщеплением горизонта» (split horizon). При использовании ее на данном интерфейсе маршрутные обновления для префикса P не передаются на интерфейс, через который был получен выбранных маршрут в направлении префикса P.

Расщепление горизонта не следует применять на интерфейсе, пока нет уверенности в симметрии и транзитивности. В частности, этот метод не применим к децентрализованным беспроводным канальным технологиям (например, IEEE 802.11 в режиме ad hoc), когда маршрутные обновления передаются по групповым адресам.

3.8. Явные запросы

При обычной работе таблица маршрутов узла заполняется из плановых и триггерных обновлений от соседей. Однако в некоторых обстоятельствах узел может передавать явные запросы для ресинхронизации с источником после перемещения (mobility event) или для предотвращения ненужного завершения срока действия маршрута.

Протокол Babel поддерживает два типа явных запросов — запрос маршрута, который возвращает обновление для данного префикса, и запрос порядкового номера для обновления номера у данного префикса. Первый тип запросов не пересылается, запросы второго типа пересылаются, если получатель не может выполнить запрос.

3.8.1. Обработка запросов

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

3.8.1.1. Запросы маршрутов

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

При получении шаблонного запроса маршрута узлу следует возвращать полный дамп таблицы маршрутов. При этом следует ограничивать скорость отправки, особенно для групповой передачи.

3.8.1.2. Запросы порядковых номеров

При получении запроса seqno для данного router-id и порядкового номера узел ищет в своей таблице маршрутов выбранную запись для данного префикса. Если такая запись присутствует и имеет конечную метрику, а значения router-id различаются или эти значения совпадают, но порядковый номер записи не меньше (по модулю 2¹⁶) запрошенного порядкового номера, узел должен передать обновление для данного префикса. Если router-id совпадают, но запрошенный порядковый номер больше (по модулю 2¹⁶) чем в записи для маршрута, узел сравнивает router-id со своим идентификатором. При совпадении узел увеличивает свой порядковый номер на 1 (по модулю 2¹⁶) и передает обновления. Узлу недопустимо увеличивать своей номер больше чем на 1 в ответ на один запрос seqno.

Если router-id в запросе не совпадает с идентификатором узла, принявший запрос узел проверяет поле Hop Count в запросе. Если поле имеет значение не меньше 2 и узел анонсирует префикс своим соседям, он выбирает соседа для пересылки тому запроса, как указано ниже.

• Если узел имеет один или несколько выполнимых маршрутов в направлении запрошенного префикса, где next-hop не является запросившим узлом, он должен переслать запрос слудующему маршрутизатору (next-hop).

• В остальных случаях, если узел имеет один или несколько (невыполнимых) маршрутов к запрошенному префиксу, где next-hop не является запросившим узлом, ему следует переслать этот запрос следующему маршрутизатору на одном из таких маршрутов.

Для фактической пересылки запроса узел декрементирует счетчик интервалов (hop count) и передает запрос по индивидуальному адресу выбранного соседа. Запрос следует пересылать как срочный TLV (параграф 3.1).

Узлу следует поддерживать список недавно пересланных запросов seqno и пересылать отклики на них (обновление с достаточно большим для удовлетворения запроса seqno) как срочные TLV (параграф 3.1). Узлу следует сравнивать каждый входящий запрос seqno со списком недавно пересылавшихся запросов seqno во избежание избыточной пересылки (т. е. он недавно пересылал запрос с тем же префиксом, prefix, router-id и не меньшим seqno по модулю 2¹⁶).

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

3.8.2. Передача запросов

Узел Babel может отправлять запросы маршрутов и порядковых номеров по групповым и индивидуальным адресам. Отправка запросов требуется лишь в одном случае (параграф 3.8.2.1).

3.8.2.1. Предотвращение истощения

Когда маршрут отозван или закончился срок его действия, узел Babel обычно переключается на другой выполнимый маршрут для того же префикса. Однако в некоторых случаях таких маршрутов может не оказаться. Узел, потерявший все выполнимые маршруты к данному адресату, но имеющий невыполнимые маршруты к нему с не истекшим сроком действия, должен отправить запрос seqno. Если нет даже таких маршрутов, узел все равно может передать запрос seqno. В поле router-id такого запроса указывается router-id из потерянного маршрута, а запрашиваемым номером является значение из таблицы источников, увеличенное на 1. Запрос включает счетчик интервалов, который служит «механизмом последней надежды» (last-resort) для гарантии сохранения узла в сети и может включать любое значение, превышающее диаметр сети (значение 64 приемлемо по умолчанию).

Если узел имет какие-либо (невыполнимые) маршруты к нужному адресату, он должен передать запрос хотя бы одному из соседей next-hop, анонсировавших эти маршруты, и следует передать его всем. В любом случае узел может передать запрос любому другому соседу независимо от анонсирования им нужного маршрута. Простой стратегией реализации будет безусловная отправка группового запроса через все интерфейсы.

Похожие запросы могут быть переданы другими узлами, на которые повлияла потеря маршрута. Если сеть остается соединенной и предполагается отсутствие потерь, хотя бы один из таких запросов будет переслан источнику и маршрут будет анонсирован с новым порядковым номером (в результате подавления дубликатов лишь малое число таких запросов достигнет источника). Для компенсации потери пакетов узлу следует повторить запрос несколько раз, если не появилось выполнимого маршрута в течение короткого времени (см. Приложение B) Однако при значительной потере пакетов могут пропасть все такие запросы. В этом случае получение нового порядкового номера обеспечит описанный в следующем параграфе механизм.

3.8.2.2. Работа с невыполнимыми обновлениями

Когда метрика маршрута увеличивается, узел может получить невыполнимое обновление для маршрута, который выбран. Как указано в параграфе 3.5.1, узел может игнорировать обновление или отменить выбор маршрута.

Для предотвращения ложного завершения срока действия маршрута, ставшего невыполнимым, узлу следует передать индивидуальный запрос seqno при получении невыполнимого обновления для выбранного маршрута. Порядковый номер для запроса рассчитывается по таблице источников, как указано в параграфе 3.8.2.1.

Поскольку расчет метрики не обязательно совпадает (по времени) с задержкой распространения обновлений, узел может получить невыполнимое обновление от не выбранного в данный момент соседа, который предпочтительней выбранного маршрута (т. е. имеет меньшую метрику). В таком случае узлу следует передать индивидуальный запрос seqno соседу, анонсировавшему предпочтительное обновление.

3.8.2.3. Предотвращение завершения срока действия маршрутов

При нормальной работе таймер срока действия маршрута не срабатывает никогда, поскольку время удержания маршрута рассчитывается на основе явного интервала из Update TLV и обновления (возможно отзывы) должны поступать своевременно, чтобы избежать завершения срока действия маршрута.

Однако при наличии потерь пакетов может случиться так, что обновление не будет получено в течение срока ожидания и срок действия маршрута закончится. Для предотвращения таких ситуаций узлу Babel, незадолго до завершения срока действия маршрута, следует передать индивидуальный запрос маршрута анонсировавшему его соседу. Поскольку узлы всегда передают обновление или отзыв в ответ на запрос точного (не шаблонного) маршрута (параграф 3.8.1.1), это обычно ведет к обновлению или отзыву маршрута.

4. Кодирование протокола

Пакет Babel должен передаваться как тело дейтаграммы UDP со значением счетчика интервалов сетевого уровня (hop count) 1 по общеизвестному групповому адресу протокола IPv4 или IPv6 (для IPv6 это адреса link-local). Для потов UDP отправителя и получателя должен указываться общеизвестный номер. Пакеты Babel должны игнорироваться, если адресом отправителя не является адрес IPv6 link-local или адрес IPv4, относящийся к локальной сети, а в качестве порта не указан общеизвестный порт Babel. Пакеты могут игнорироваться, если для получателя указан глобальный (маршрутизируемый) адрес IPv6.

Для минимизации числа передаваемых пакетов и предотвращения фрагментации на нижележащих уровнях узлу Babel следует использовать пакеты максимального размера, вплоть для MTU выходного интерфейса с учетом заголовков нижележащего уровня (28 октетов для UDP по протоколу IPv4 и 48 октетов для UDP по протоколу IPv6). Недопустимо передавать пакеты, размер которых превышает большее из значений MTU выходного интерфейса (с учетом нижележащих заголовков) или 512 октетов. В любом случае размер пакета не может быть больше 2¹⁶ — 1 с учетом заголовков нижележащего уровня. Каждый узел Babel должен поддерживать прием пакетов размером до большего из значений MTU приемного интерфейса с учетом заголовков нижележащего уровня или 512 октетов. Недопустимо передавать пакеты Babel в джамбограммах IPv6 [RFC2675].

4.1. Типы данных

4.1.1. Представление целых чисел

Многооктетные поля, представляющие целые числа начинаются со старшего октета (формат Big-Endian [IEN137], называемый также сетевым порядком байтов). Базовый протокол использует лишь значения без знака. Если расширению потребуются числа со знаком, оно должно будет задать кодирование (например, дополнение до 2).

4.1.2. Интервалы

Относительные значения времени указываются 16-битовыми числами в сотых долях секунды (centisecond). Это позволяет задать интервалы приблизительно до 11 минут с шагом 10 мсек., что должно быть достаточно для всех применений Babel (см. Прилжение B).

4.1.3. Идентификаторы маршрутизаторов

Идентификатор router-id представляет собой произвольной значение размером 8 октетов. Недопустимо использовать для router-id значения, содержащие только нули (шестнадцатеричное 0000000000000000) или только единицы (шестнадцатеричное FFFFFFFFFFFFFFFF).

4.1.4. Адреса

Поскольку основная работа протокола выполняется с адресами, поддерживается несколько типов их кодирования. Кроме того, в Update TLV может опускаться маска подсети при передаче множества адресов в одном пакете, это называется сжатием адресов (параграф 4.6.9). Варианты кодирования адресов приведены ниже.

AE 0

Шаблонный адрес (строка октетов размером 0).

AE 1

Адрес IPv4 (до 4 октетов).

AE 2

Адрес IPv6 с поддержкой сжатия (до 16 октетов).

AE 3

Адрес IPv6 link-local без сжатия (8 октетов, предполагается префикс fe80::/64).

Семейством адресов, связанным с форматом представления является IPv4 или IPv6. Семейство не определено для AE 0, IPv4 для AE 1 и IPv6 для AE 2 и AE 3.

4.1.5. Префиксы

Сетевые префиксы кодируются как адреса, но хранятся с минимальным числом октетов, достаточным для записи значимых битов (до размера префикса).

4.2. Формат пакетов

Пакет Babel состоит из 4-октетного заголовка, за которым следует набор TLV (тело пакета) и может следовать еще один набор TLV (трейлер).Формат является расширяемым (см. Приложение D).

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Magic     |    Version    |        Body length            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Packet Body...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
|         Packet Trailer...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

Magic

Тщательно подобранное произвольное значение 42 (десятичное). Пакеты, в которых первый октет имеет другое значение должны игнорироваться.

Version

Этот документ задает версию 2 протокола Babel. Пакеты, в которых второй октет имеет другое значение должны игнорироваться.

Body length

Размер следующего за заголовком тела пакета (без учета полей Magic, Version, Body length, а также трейлера) в октетах.

Packet Body

Тело пакета, представляющее собой последовательность TLV.

Packet Trailer

Трейлер пакета, содержащий последовательность TLV.

Телом и трейлером пакета служат цепочки TLV. Обычно TLV помещаются в тело пакета, а трейлеры применяются лишь для особых TLV, которые не требуют криптографической защиты. При анализе трейлера получатель должен игнорировать все TLV, в определениях которых явно не указана возможность размещения в трейлере. Из числа определенных в документе TLV таковыми являются лишь Pad1 и PadN. Поскольку эти TLV в любом случае игнорируются, реализация может полностью игнорировать трейлер, даже не анализируя его, пока не используется расширений, определяющих другие TLV для включения в трейлер.

4.3. Формат TLV

Все TLV, за исключением Pad1, имеют показанную на рисунке структуру.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |    Length     |     Payload...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

Type

Тип TLV.

Length

Размер тела в октетах без учета полей Type и Length.

Payload

Данные TLV (payload), которые представляют собой тело, а в некоторых случаях — набор суб-TLV.

TLV неизвестного типа должны игнорироваться.

4.4. Формат суб-TLV

В заголовке каждого TLV явно указывается размер, однако большинство TLV являются самозавершающими в том смысле, что можно определить размер без явного обращения к полю Length. Если TLV имеет самозавершающий формат, пространство между естественным размером TLV и значением в поле Length может применяться для включения sub-TLV.

Структура суб-TLV не отличается от структры TLV и, кроме Pad1, все суб-TLV имеют показанный ниже формат.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |    Length     |     Body...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

Type

Тип суб-TLV.

Length

Размер тела в октетах без учета полей Type и Length.

Body

Тело суб-TLV, интерпретация которого зависит от типа суб-TLV и типа содержащего его TLV.

Старший бит типа суб-TLV (шестнадцатеричное значение 80) называется битом обязательности (mandatory). Иными словами, типы суб-TLV от 128 до 255 включают этот бит, который определяет обработку неизвестных суб-TLV. При сброшенном бите неизвестный суб-TLV целиком должен игнорироваться, а остальная часть TLV обрабатывается нормально. Если бит установлен, должен целиком игнорироваться блок TLV (за исключением обновления состояния анализатора с помощью Router-Id, Next Hop, Update TLV, как указано в следующем параграфе).

4.5. Состояние анализатора и кодирование обновлений

В больших сетях основную часть трафика Babel составляют обновления, поэтому были применены способы их эффективного кодирования. Включаемые в обновление данные концептуально разделены на 3 части (параграф 3.5):

• префикс, порядковый номер и метрика содержатся в самих Update TLV (параграф 4.6.9);

• router-id берется из Router-Id TLV, предшествующего Update TLV и может использоваться несколькими Update TLV (параграф 4.6.7);

• следующий интервал (next-hop) берется из адреса отправителя пакета сетевого уровня, содержащего пакет Babel, или из явного Next Hop TLV (параграф 4.6.8).

В дополнение к этому в Update TLV можно опускать префикс анонсируемого префикса, который извлекается из предшествующего Update TLV с тем же семейством адресов (IPv4 или IPv6). Кроме того, в особом случае совпадения router-id с идентификатором интерфейса в адресе IPv6 можно опустить Router-Id TLV и вывести значение router-id из младших битов анонсируемого префикса (параграф 4.6.9).

Для реализации этих методов сокращения в Babel применяется анализатор с учетом состояния, позволяющий TLV ссылаться на данные предыдущего TLV. Состояние анализатора включает указанные ниже данные.

• Принятый по умолчанию префикс для каждой кодировки адреса с возможностью сжатия. Префикс не определен в начале пакета и обновляется каждым Update TLV с флагом Prefix (параграф 4.6.9).

• Текущий следующий интервал пересылки (next-hop) для каждого семейства адресов (IPv4 или IPv6). Это адрес отправителя в содержащем обновление пакете для совпадающего семейства адресов в начале пакета, обновляемый каждым Next Hop TLV (параграф 4.6.8);

• Текущее значение router-id. Значение не определено в начале пакета и обновляется каждым Router-Id TLV (параграф 4.6.7) и Update TLV с флагом Router-Id.

Поскольку состояние анализатора должно быть идентичным в реализациях, оно обновляется до проверки обязательности суб-TLV. Анализ TLV должен обновлять состояние анализатора, даже если в ином случае TLV игнорируется из-за наличия неизвестного обязательного суб-TLV или по иной причине.

Ни один из меняющих состояние анализатора TLV не разрешается включать в трейлер пакета, поэтому для анализа трейлеров реализация может использовать отдельный анализатор без учета состояний.

4.6. Специальные TLV

4.6.1. Заполнение Pad1

 0
 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|   Type = 0    |
+-+-+-+-+-+-+-+-+

Type

Значение 0 указывает Pad1 TLV.

Такие TLV игнорируются при получении и могут включаться в трейлер пакета.

4.6.2. Заполнение PadN

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Type = 1   |    Length     |      MBZ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

Type

Значение 1 указывает PadN TLV.

Length

Размер тела в октетах без учета полей Type и Length.

MBZ

Должно иметь значение 0, устанавливаемое при передаче.

Такие TLV игнорируются при получении и могут включаться в трейлер пакета.

4.6.3. Запрос подтверждения

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Type = 2   |    Length     |          Reserved             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Opaque            |          Interval             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

TLV запрашивает у получателя отправку Acknowledgment TLV в течение заданного полем Interval времени.

Type

Значение 2 указывает Acknowledgment Request TLV.

Length

Размер тела в октетах без учета полей Type и Length.

Reserved

Устанавливается 0 при передаче и должно игнорироваться при получении.

Opaque

Произвольное значение, возвращаемое в Acknowledgment TLV.

Interval

Интервал времени в сотых долях секунды (centisecond), по истечении которого отправитель сочтет пакет потерянным. Установка значения 0 недопустима. Получатель должен передать Acknowledgment TLV до истечения заданного интервала (с запасом на время доставки).

TLV относится к самозавершающим и может включать суб-TLV.

4.6.4. Подтверждение

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Type = 3   |    Length     |           Opaque              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

TLV передается узлом в ответ на получение Acknowledgment Request TLV.

Type

Значение 3 указывает Acknowledgment TLV.

Length

Размер тела в октетах без учета полей Type и Length.

Opaque

Значение поля Opaque из Acknowledgment Request, вызвавшего это подтверждение.

Поскольку значения Opaque не уникальны в глобальном масштабе, этот блок TLV должен передаваться по индивидуальному адресу.

TLV относится к самозавершающим и может включать суб-TLV.

4.6.5. Hello

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Type = 4   |    Length     |            Flags              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            Seqno              |          Interval             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

TLV для обнаружения соседей и определения стоимости приема от соседа.

Type

Значение 4 указывает Hello TLV.

Length

Размер тела в октетах без учета полей Type и Length.

Flags

Биты флагов, задающие обработку данного TLV (см. ниже).

Seqno

При установленном флаге Unicast это будет значение порядкового номера Unicast Hello передающего узла для этого соседа. Иначе это будет исходящим порядковым номером Multicast Hello для данного интерфейса.

Interval

Ненулевое значение задает верхнюю границу (в сотых долях секунды) времени, по истечение которого передающих узел будет повторять плановое сообщение Hello TLV с таким же флагом Unicast. Нулевое значение указывает неплановое сообщение Hello, которое не включает данных о времени передачи других Hello.

Формат поля Flags показан на рисунке.

 0                   1
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|X|X|X|X|X|X|X|X|X|X|X|X|X|X|X|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

U (Unicast)

Флаг (шестнадцатеричное значение 8000), установка которого указывает Unicast Hello, сброс — Multicast Hello.

X

Все остальные биты должны иметь значение 0 при отправке и игнорируются при получении.

При каждой отправке сообщения Hello должно инкрементиваться значение соответствующего счетчика seqno. Поскольку все Multicast Hello используют общий счетчик seqno для интерфейса на узле, если флаг Unicast сброшен, TLV должен передаваться всем соседям на этом канале, что можно обеспечить отправкой по групповому адресу или передачей групповых пакетов по индивидуальным адресам всех доступных соседей. И наоборот, при установленном флаге Unicast этот блок TLV должен передаваться одному соседу по индивидуальному адресу. Во избежание существенного снижения снижения качества канала не следует передавать несколько Hello TLV в одном пакете.

TLV относится к самозавершающим и может включать суб-TLV.

4.6.6. IHU

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Type = 5   |    Length     |       AE      |    Reserved   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            Rxcost             |          Interval             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       Address...
+-+-+-+-+-+-+-+-+-+-+-+-

IHU TLV (я слышу вас) служит для подтверждения двухсторонней доступности и передачи стоимости отправки в канал.

Type

Значение 5 указывает IHU TLV.

Length

Размер тела в октетах без учета полей Type и Length.

AE

Вариант кодирования поля Address (в большинстве случаев 1 или 3). В качестве оптимизации можно применять 0, если TLV передается по индивидуальному адресу, ассоциация организована по каналу «точка-точка» или двухсторонняя доступность устанавливается средствами другого протокола (вне Babel).

Reserved

Устанавливается 0 при передаче и должно игнорироваться при получении.

Rxcost

Значение rxcost, соответствующее передающему узлу интерфейса, адрес которого указан в поле Address. Шестнадцатеричное значени FFFF (бесконечность) указывает недоступность интерфейса.

Interval

Верхняя граница времени по истечении которого предающий узел будет повторять IHU (в сотых долях секнды). Значение 0 недопустимо. Принимающий узел использует это значение для расчета времени удержания данной симметричной ассоциации (связи).

Address

Адрес получателя в формате, заданном полем AE. Сжатие адреса не допускается.

Концептуально IHU адресуется одному соседу. Однако IHU TLV включают явный адрес получателя и могут передаваться по групповому адресу, что позволяет объединить IHU для нескольких соседей в один пакет, избавляя от необходимости использовать обмен ARP или Neighbour Discovery, когда сосед не участвует в трафике данных.

IHU TLV с неизвестным значением в поле AE должны игнорироваться.

TLV относится к самозавершающим и может включать суб-TLV.

4.6.7. Router-Id

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Type = 6   |    Length     |          Reserved             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                           Router-Id                           +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Router-Id TLV устанавливает значение router-id, которое предполагается следующими Update TLV, как указано в параграфе 4.5. TLV задает router-id даже при наличии в нем неизвестного обязательного суб-TLV.

Type

Значение 6 указывает Router-Id TLV.

Length

Размер тела в октетах без учета полей Type и Length.

Reserved

Устанавливается 0 при передаче и должно игнорироваться при получении.

Router-Id

Значение router-id для маршрутов, анонсируемых в последующих Update TLV. Недопустимы значения, содержащие только 0 или только 1.

TLV относится к самозавершающим и может включать суб-TLV.

4.6.8. Следующий интервал

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Type = 7   |    Length     |      AE       |   Reserved    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       Next hop...
+-+-+-+-+-+-+-+-+-+-+-+-

Next Hop TLV задает адрес следующего интервала (next-hop) для данного семейтсва адресов (IPv4 или IPv6), которые предполагается следующими Update TLV, как указано в параграфе 4.5. TLV задает следующий интервал для последующих Update TLV даже при наличии в нем неизвестного обязательного суб-TLV.

Type

Значение 7 указывает Next Hop TLV.

Length

Размер тела в октетах без учета полей Type и Length.

AE

Вариант кодирования поля Address. Следует задавать 1 (IPv4) или 3 (IPv6 link-local), недопустимо указывать 0.

Reserved

Устанавливается 0 при передаче и должно игнорироваться при получении.

Next hop

Адрес next-hop, анонсируемый последующими Update TLV для этого семейства адресов.

Когда семейство адресов соответствует протоколу сетевого уровня, который передает пакет, Next Hop TLV не требуется и адрес следующего интервала при отсутствии Next Hop TLV берется из адреса отправителя пакета.

Next Hop TLV с неизвестным значением в поле AE должны игнорироваться.

TLV относится к самозавершающим и может включать суб-TLV.

4.6.9. Обновление

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Type = 8   |    Length     |       AE      |    Flags      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Plen      |    Omitted    |            Interval           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Seqno             |            Metric             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Prefix...
+-+-+-+-+-+-+-+-+-+-+-+-

Update TLV анонсирует или отзывает маршрут. В качестве оптимизации может дополнительно устанавливать новое подразумеваемое значение router-id и принятого по умолчанию префикса, как указано в параграфе 4.5.

Type

Значение 8 указывает Update TLV.

Length

Размер тела в октетах без учета полей Type и Length.

AE

Вариант кодирования поля Prefix.

Flags

Биты флагов, задающие обработку данного TLV (см. ниже).

Plen

Размер анонсируемого префикса в битах. В случае AE 3 (IPv6 link-local) поле Omitted должно иметь значение 0.

Omitted

Число октетов, опускаемых в начале анонсируемого префикса, которые следует брать из предшествующего Update TLV для того же семейства адресов при установленном флаге Prefix.

Interval

Верхняя граница интервала, по истечение которого передающий узел будет отправлять новое обновление для данного префикса (в сотых долях секунды). Значение 0 недопустимо. Принимающий узел использует это значение для расчета времени удержания записи в таблице маршрутов. Шестнадцатеричное значение FFFF (бесконечность) говорит, что это обновление не будет повторяться без запроса (параграф 3.8.2.3).

Seqno

Порядковый номер инициатора для данного обновления.

Metric

Метрика маршрута. Шестнадцатеричное значение FFFF (бесконечность) указывает отзыв маршрута.

Prefix

Анонсируемый префикс размером (Plen/8 — Omitted) с округлением в большую сторону.

Формат поля Flags показан на рисунке.

 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|P|R|X|X|X|X|X|X|
+-+-+-+-+-+-+-+-+

P (Prefix)

Флаг (шестнадцатеричное значение 8000), установка которого указывает, что данный Update TLV задает новый префикс для последующих Update TLV в пакете с тем же кодированием адресов. Значение устанавливается даже при наличии в данном TLV неизвестного обязательного суб-TLV.

R (Router-Id)

Флаг (шестнадцатеричное значение 4000), установка которого указывает, что данный TLV задает новое значение принятого по умолчанию router-id для этого TLV и Update TLV в пакете с тем же кодированием адресов. Значение устанавливается даже при наличии в данном TLV неизвестного обязательного суб-TLV и рассчитывается из первого адреса анонсируемого префикса, как показано ниже.

• Если размер адреса не меньше 8 октетов из последних 8 октетов адреса извлекается значение router-id.
• Если размер адреса меньше 8 октетов, новое значение router-id состоит из нужного числа нулевых октетов и поля адреса, записываемого в правую часть router-id. Например, для IPv4 значение router-id будет включать 4 октета нулей, за которыми следует адрес IPv4.

X

Все остальные биты должны иметь значение 0 при отправке и игнорируются при получении.

Расчет префикса, анонсируемого данным Update TLV, выполняется в соответствии с приведенным ниже описанием.

• Первые Omitted октетов префикса берутся из предыдущего Update TLV с флагом Prefix и тем же кодированием адресов даже при наличии так неизвестного обязательного суб-TLV. Если поле Omitted отлично от 0, но такого TLV нет, данное обновление должно игнорироваться.

• Следующие (Plen/8 — Omitted) октетов (с округлением вверх) берутся из поля Prefix.

• Если Plen не кратно 8, все биты вне Plen (младшие (8 — Plen MOD 8) битов последнего октета) сбрасываются.

• В оставшихся октетах устанавливается 0.

Если поле Metric имеет конечное значение, router-id узла-инициатора для данного анонса берется из префикса, анонсируемого этим обновлением, при наличии флага Router-Id, рассчитанного, как указано выше. В остальных случаях значение берется из предшествующего Router-Id TLV или Update TLV с флагом Router-Id, в зависимости от того, что указано последним, даже при наличии в TLV неизвестного обязательного суб-TLV. При отсутствии подходящего TLV обновление игнорируется.

Адрес следующего интервала (next-hop) для обновления берется из последнего предшествующего Next Hop TLV с тем же семейством адресов (IPv4 или IPv6) в том же пакете даже при наличии неизвестного обязательного суб-TLV. Если такого TLV нет, значение берется из адреса отправителя в пакете сетевого уровня, содержащем данное обновление, если он относится к тому же семейству адресов. В остальных случаях это обновление должно игнорироваться.

Шестнадцатеричное значение FFFF в поле метри указывает отзыв маршрута. В этом случае router-id, next-hop и seqno не используются. AE может иметь значение 0 и в этом случае Update TLV отзывает все маршруты, анонсированные ранее передавшим интерфейсом. Если метрика конечна, установка AE 0 недопустима. Update TLV с конечной метрикой и AE 0 должны игнорироваться. Если метрика бесконечная и AE имеет значение 0, в полях Plen и Omitted должно быть значение 0. Update TLV, не соответствующие этому требованию, должны игнорироваться.

Update TLV с неизвестным значением в поле AE должны игнорироваться.

TLV относится к самозавершающим и может включать суб-TLV.

4.6.10. Запрос маршрута

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Type = 9   |    Length     |      AE       |     Plen      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Prefix...
+-+-+-+-+-+-+-+-+-+-+-+-

Route Request TLV приглашает получателя передать обновление для заданного префикса или всю таблицу маршрутов.

Type

Значение 9 указывает Route Request TLV.

Length

Размер тела в октетах без учета полей Type и Length.

AE

Вариант кодирования поля Prefix. Значение 0 указывает запрос полного дампа таблицы маршрутов (шаблонный запрос).

Plen

Размер запрашиваемого префикса в битах.

Prefix

Запрашиваемый префикс, размер которого составляет Plen/8 с округлением в большую сторону.

Route Request TLV приглашает получателя передать обновление (возможно отзыв) для префикса, указанного полями AE, Plen и Prefix или полный дамп его таблицы маршрутов, если AE имеет значение 0 (в этом случае поле Plen должно иметь значение 0 и размер Prefix также должен быть 0). Request TLV с AE 0 и ненулевым Plen должны игнорироваться.

TLV относится к самозавершающим и может включать суб-TLV.

4.6.11. Запрос порядкового номера

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Type = 10  |    Length     |      AE       |    Plen       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Seqno             |  Hop Count    |   Reserved    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                          Router-Id                            +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Prefix...
+-+-+-+-+-+-+-+-+-+-+

Seqno Request TLV приглашает получателя передать Update для данного префикса с данным порядковым номером или переслать запрос, если его нельзя выполнить локально.

Type

Значение 10 указывает Seqno Request TLV.

Length

Размер тела в октетах без учета полей Type и Length.

AE

Формат кодирования поля Prefix. Значение 0 недопустимо.

Plen

Размер запрашиваемого префикса в битах.

Seqno

Запрашиваемый порядковый номер.

Hop Count

Максимальное число пересылок данного TLV плюс 1. Значение 0 недопустимо.

Reserved

Устанавливается 0 при передаче и должно игнорироваться при получении.

Router-Id

Запрашиваемый идентификатор Router-Id. Недопустимы значения, содержащие только 0 или только 1.

Prefix

Запрашиваемый префикс, размер которого составляет Plen/8 с округлением в большую сторону.

Seqno Request TLV приглашает получателя передать Update с конечной метрикой для префикса, указанного полями AE, Plen и Prefix, с router-id, отличным от заданного полем Router-Id, или Seqno не меньше (по модулю 2¹⁶) указанного в поле Seqno. Если запрос нельзя выполнить локально, он пересылается в соответствии с правилами параграфа 3.8.1.2.

Хотя Seqno Request можно передавать по групповому адресу, его недопустимо пересылать по групповому адресу, а также недопустима пересылка более чем одному соседу. Запрос недопустимо пересылать при Hop Count = 1.

TLV относится к самозавершающим и может включать суб-TLV.

4.7. Специальные суб-TLV

4.7.1. Pad1

 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|   Type = 0    |
+-+-+-+-+-+-+-+-+

Type

Значение 0 указывает суб-TLV Pad1.

Суб-TLV игнорируется при получении и может включаться в TLV, поддерживающие суб-TLV.

4.7.2. PadN

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Type = 1   |    Length     |      MBZ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

Type

Значение 1 указывает суб-TLV PadN.

Length

Размер тела в октетах без учета полей Type и Length.

MBZ

Должно иметь значение 0, устанавливаемое при передаче.

Суб-TLV игнорируется при получении и может включаться в TLV, поддерживающие суб-TLV.

5. Взаимодействие с IANA

Агентство IANA зарегистрировало порт UDP с номером 6696, названный babel, для использования протоколом Babel.

Агентство IANA зарегистрировало multicast-группы IPv6 ff02::1:6 и IPv4 224.0.0.111 для протокола Babel.

В IANA создан реестр Babel TLV Types с политикой распределения Specification Required [RFC8126] для типов 0-223 и Experimental Use для типов 224-254. Значения реестра приведены в таблице 1.

Таблица 1.

Тип	Имя	Документ
0	Pad1	RFC 8966
1	PadN	RFC 8966
2	Acknowledgment Request	RFC 8966
3	Acknowledgment	RFC 8966
4	Hello	RFC 8966
5	IHU	RFC 8966
6	Router-Id	RFC 8966
7	Next Hop	RFC 8966
8	Update	RFC 8966
9	Route Request	RFC 8966
10	Seqno Request	RFC 8966
11	TS/PC	[RFC7298]
12	HMAC	[RFC7298]
13	Reserved
14	Reserved
15	Reserved
224-254	Reserved for Experimental Use	RFC 8966
255	Reserved for expansion of the type space	RFC 8966

В IANA создан реестр Babel Sub-TLV Types с политикой распределения Specification Required для типов 0-111 и 128-239 и политикой Experimental Use для типов 112-126 и 240-254. Значения реестра приведены в таблице 2.

Таблица 2.

Тип	Имя	Документ
0	Pad1	RFC 8966
1	PadN	RFC 8966
2	Diversity	[BABEL-DIVERSITY]
3	Timestamp	[BABEL-RTT]
4-111	Unassigned
112-126	Reserved for Experimental Use	RFC 8966
127	Reserved for expansion of the type space	RFC 8966
128	Source Prefix	[BABEL-SS]
129-239	Unassigned
240-254	Reserved for Experimental Use	RFC 8966
255	Reserved for expansion of the type space	RFC 8966

В IANA создан реестр Babel Address Encodings с политикой распределения Specification Required для кодирования адресов (AE) 0-223 и Experimental Use для 224-254. Значения реестра приведены в таблице 3.

Таблица 3.

AE	Имя	Документ
0	Wildcard address	RFC 8966
1	IPv4 address	RFC 8966
2	IPv6 address	RFC 8966
3	Link-local IPv6 address	RFC 8966
4-223	Unassigned
224-254	Reserved for Experimental Use	RFC 8966
255	Reserved for expansion of the AE space	RFC 8966

Реестр Babel Flags Values переименован в Babel Update Flags Values. Для реестра применяется политика распределения Specification Required. Значения реестра приведены в таблице 4.

Таблица 4.

Бит	Имя	Документ
0	Default prefix	RFC 8966
1	Default router-id	RFC 8966
2-7	Unassigned

В IANA создан реестр Babel Hello Flags Values с политикой распределения Specification Required. Значения реестра приведены в таблице 5.

Таблица 5.

Бит	Имя	Документ
0	Unicast	RFC 8966
1-15	Unassigned

Агентство IANA заменило ссылки на RFC 6126 и RFC 7557 во всех перечисленных выше реестрах на данный документ.

6. Вопросы безопасности

Как указано в этом документе, протокол Babel является совершенно не защищенным. Без дополнительных механизмов защиты Babel доверяет любой информации, приходящей в открытых дейтаграммах UDP, и действует на основании ее. Злоумышленник в локальной сети может влиять на работу Babel разными способами. Например,

• подменять пакеты Babel и перенаправлять трафик, анонсируя анонсирования маршруты с меньшей метрикой, большим порядковым номером или более длинным префиксом;

• создавать некорректно сформированные пакеты, нарушающие работу недостаточно устойчивых реализаций или препятствующие остальной сети;

• повторно использовать перехваченные пакеты Babel, что может вести к перенаправлению трафика, возникновению «черных дыр» и даже нарушению работы всей сети.

При передаче по протоколу IPv6 пакеты Babel игнорируются, если они не переданы с адреса IPv6 link-local. Поскольку маршрутизаторы не пересылают пакеты IPv6 link-local, это смягчает атаки, указанные выше, необходимостью для злоумышленника иметь доступ к локальному каналу. Для пакетов Babel, переданных по протоколу IPv4 такой естественной защиты нет и это служит одной из причин рекомендуемого использования Babel на основе IPv6 (параграф 3.1).

Обычно сложно обеспечить доверие к пакетам, прибывающим на узел Babel, даже при защищенном локальном канале. По этой причине рекомендуется защищать весь трафик Babel криптографическим протоколом на уровне приложения. Имеется два подходящих механизма, выбор между которыми определяется копромиссом между простотой и безопасностью.

• Babel по протоколу DTLS [RFC8968] передает основную часть трафика Babel по протоколу DTLS и этот протокол применяется для аутентификации узлов, а также защиты целостности и конфиденциальности.

• MAC-аутентификация [RFC8967] добавляет код аутентификации сообщений (message authentication code или MAC) в каждый пакет Babel для подтверждения его отправки узлом, знающим общий секрет, и включения дополнительной информации для проверки свежести пакета (предотвращение повторного использования).

Оба механизма позволяют узлам игнорировать пакеты от злоумышленника без требуемых свидетельств. Обеспечивается также целостность сообщений и предотвращается их повторное использование. Babel-DTLS использует асимметричные ключи и обеспечивает конфиденциальность, а Babel-MAC имеет более ограниченную область применения (см. параграфы 1.1, 1.2, 7 в [RFC8967]). Поскольку Babel-MAC проще и более облегчен, его рекомендуется использовать в приложениях Babel, где ограничения протокола допустимы, например, достаточно симметричных ключей, а маршрутные данные не считаются конфиденциальными.

Каждой реализации Babel следует поддерживать BABEL-MAC.

Следует учитывать, что информации, которую мобильный узел Babel анонсирует всему домену маршрутизации, достаточно для определения физического местоположения мобильного узла с неплохой точностью, что может вызывать проблемы приватности даже при защите трафика управления от неаутентифицированных злоумышленников криптографическими механизмами, такими как Babel-DTLS. Эту проблему можно смягчить использованием случайных значений router-id и адресов IP, а также их достаточно частой сменой.

7. Литература

7.1. Нормативные документы

[RFC2119] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC793] Postel, J., «Transmission Control Protocol», STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981, <https://www.rfc-editor.org/info/rfc793>.

[RFC8126] Cotton, M., Leiba, B., and T. Narten, «Guidelines for Writing an IANA Considerations Section in RFCs», BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.

[RFC8174] Leiba, B., «Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words», BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8967] Dô, C., Kolodziejak, W., and J. Chroboczek, «MAC Authentication for the Babel Routing Protocol», RFC 8967, DOI 10.17487/RFC8967, January 2021, <https://www.rfc-editor.org/info/rfc8967>.

7.2. Дополнительная литература

[BABEL-DIVERSITY] Chroboczek, J., «Diversity Routing for the Babel Routing Protocol», Work in Progress, Internet-Draft, draft-chroboczek-babel-diversity-routing-01, 15 February 2016, <https://tools.ietf.org/html/draft-chroboczek-babel-diversity-routing-01>.

[BABEL-RTT] Jonglez, B. and J. Chroboczek, «Delay-based Metric Extension for the Babel Routing Protocol», Work in Progress, Internet-Draft, draft-ietf-babel-rtt-extension-00, 26 April 2019, <https://tools.ietf.org/html/draft-ietf-babel-rtt-extension-00>.

[BABEL-SS] Boutier, M. and J. Chroboczek, «Source-Specific Routing in Babel», Work in Progress, Internet-Draft, draft-ietf-babel-source-specific-07, 28 October 2020, <https://tools.ietf.org/html/draft-ietf-babel-source-specific-07>.

[DSDV] Perkins, C. and P. Bhagwat, «Highly dynamic Destination-Sequenced Distance-Vector routing (DSDV) for mobile computers», ACM SIGCOMM ’94: Proceedings of the conference on Communications architectures, protocols and applications, 234-244, DOI 10.1145/190314.190336, October 1994, <https://doi.org/10.1145/190314.190336>.

[DUAL] Garcia Luna Aceves, J. J., «Loop-free routing using diffusing computations», IEEE/ACM Transactions on Networking, 1:1, DOI 10.1109/90.222913, February 1993, <https://doi.org/10.1109/90.222913>.

[EIGRP] Albrightson, B., Garcia Luna Aceves, J. J., and J. Boyle, «EIGRP — a Fast Routing Protocol Based on Distance Vectors», Proc. Networld/Interop 94, 1994.

[ETX] De Couto, D., Aguayo, D., Bicket, J., and R. Morris, «A high-throughput path metric for multi-hop wireless networks», MobiCom ’03: Proceedings of the 9th annual international conference on Mobile computing and networking, 134-146, DOI 10.1145/938985.939000, September 2003, <https://doi.org/10.1145/938985.939000>.

[IEEE802.11] IEEE, «IEEE Standard for Information technology—Telecommunications and information exchange between systems Local and metropolitan area networks—Specific requirements Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications», IEEE 802.11-2012, DOI 10.1109/ieeestd.2012.6178212, April 2012, <https://doi.org/10.1109/ieeestd.2012.6178212>.

[IEN137] Cohen, D., «On Holy Wars and a Plea for Peace», IEN 137, 1 April 1980.

[IS-IS] International Organization for Standardization, «Information technology — Telecommunications and information exchange between systems — Intermediate System to Intermediate System intra-domain routeing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode network service (ISO 8473)», ISO/IEC 10589:2002, 2002.

[JITTER] Floyd, S. and V. Jacobson, «The Synchronization of Periodic Routing Messages», IEEE/ACM Transactions on Networking, 2, 2, 122-136, DOI 10.1109/90.298431, April 1994, <https://doi.org/10.1109/90.298431>.

[OSPF] Moy, J., «OSPF Version 2», STD 54, RFC 2328, DOI 10.17487/RFC2328, April 1998, <https://www.rfc-editor.org/info/rfc2328>.

[PACKETBB] Clausen, T., Dearlove, C., Dean, J., and C. Adjih, «Generalized Mobile Ad Hoc Network (MANET) Packet/Message Format», RFC 5444, DOI 10.17487/RFC5444, February 2009, <https://www.rfc-editor.org/info/rfc5444>.

[RFC2675] Borman, D., Deering, S., and R. Hinden, «IPv6 Jumbograms», RFC 2675, DOI 10.17487/RFC2675, August 1999, <https://www.rfc-editor.org/info/rfc2675>.

[RFC3561] Perkins, C., Belding-Royer, E., and S. Das, «Ad hoc On-Demand Distance Vector (AODV) Routing», RFC 3561, DOI 10.17487/RFC3561, July 2003, <https://www.rfc-editor.org/info/rfc3561>.

[RFC6126] Chroboczek, J., «The Babel Routing Protocol», RFC 6126, DOI 10.17487/RFC6126, April 2011, <https://www.rfc-editor.org/info/rfc6126>.

[RFC7298] Ovsienko, D., «Babel Hashed Message Authentication Code (HMAC) Cryptographic Authentication», RFC 7298, DOI 10.17487/RFC7298, July 2014, <https://www.rfc-editor.org/info/rfc7298>.

[RFC7557] Chroboczek, J., «Extension Mechanism for the Babel Routing Protocol», RFC 7557, DOI 10.17487/RFC7557, May 2015, <https://www.rfc-editor.org/info/rfc7557>.

[RFC8968] Décimo, A., Schinazi, D., and J. Chroboczek, «Babel Routing Protocol over Datagram Transport Layer Security», RFC 8968, DOI 10.17487/RFC8968, January 2021, <https://www.rfc-editor.org/info/rfc8968>.

[RIP] Malkin, G., «RIP Version 2», STD 56, RFC 2453, DOI 10.17487/RFC2453, November 1998, <https://www.rfc-editor.org/info/rfc2453>.

Приложение A. Расчет стоимости и метрики

Стратегия рачсета стоимости и метрики маршрутов определяется локально. Протокол Babel требует лишь соответствия условиям, указанным в параграфах 3.4.3 и 3.5.2. Разные узлы могут применять разную стратегию в одной сети и даже на разных типах интерфейсов. В это приложении описаны варианты, проверенные в реальных сетях.

Говоря кратко, узел поддерживает статистику на уровне соседа для 16 последних Hello TLV каждого типа (Приложение A.1) и рассчитывает стоимость, используя стратегию !два из трех» (Приложение A.2.1) на проводных каналах и ETX⁵ (Приложение A.2.2) на беспроводных. Для расчета метрики применяется аддитивная алгебра (параграф 3.5.2).

A.1. Поддержка истории Hello

Для каждого соседа узел поддерживает два комплекта истории Hello (по одному для каждого типа) и ожидаемый порядковый номер (один для Multicast, другой для Unicast Hello). Каждая история Hello представляет собой 16-битовый вектор, где 1 указывает прием Hello, а 0 — пропуск. Для каждого типа Hello ожидаемым порядковым номером (ne) является номер, который предполагается получить в следующем Hello от этого соседа.

При каждом приеме пакета Hello данного типа от соседа узел сравнивает полученный порядковый номер (nr) с ожидаемым для этого типа Hello номером ne. В зависимости от результат выполняются указанные ниже действия.

• Если номера различаются больше чем на 16 (по модулю 2¹⁶), это говорит о возможной перезагрузке передавшего пакет узла с потерей порядковых номеров. В этом случае запись таблицы соседей очищается и создается заново.

• В остальных случаях, если nr меньше (по модулю 2¹⁶) ожидаемого номера ne, это говорит об увеличении передающим узлом интервала Hello без уведомления и принимающий узел удаляет последние (ne — nr) элементов из истории Hello для этого соседа (undo history).

• Если nr больше (по модулю 2¹⁶) чем ne, это говорит об уменьшении передающим узлом интервала Hello и потере некоторых сообщения Hello. Принимающий узел добавляет (nr — ne) битов со значением 0 в историю Hello (fast-forward).

Принимающий узел добавляет бит 1 в историю Hello и устанавливает ne = (nr + 1). Если поле Interval в принятом Hello отлично от 0, для таймера Hello с соседом устанавливается значение в 1,5 анонсированного интервала (увеличение позволяет учесть вариации задержки). По завершении отсчета связанного с соседом таймера локальный узел добавляет 0 в историю Hello и инкрементирует номер ожидаемого Hello. Если обе истории Hello пусты (содержат лишь 0), запись соседа сбрасывается. В противном случае для соответствующего таймера Hello устанавливается значение, анонсированное в последнем Hello того же типа от данного соседа (без увеличения, поскольку вариации задержки уже учтены при расчете только что завершившегося тайм-аута).

A.2. Расчет стоимости

В этом параграфе описаны два алгоритма расчета стоимости (параграф 3.4.3) на основе истории Hello. Алгоритм из парарафа A.2.1 применим к проводным каналам, A.2.2 — к беспроводным. Рекомендуемые значения для установки по умолчанию для параметров этих алгоритмов указаны в Приложении B.

A.2.1. k-out-of-j

Метод k-out-of-j подходит для проводных каналов, которые могут принимать два состояния — рабочее (up), где пакеты могут иногда отбрасываться, и нерабочее (down), когда отбрасываются все пакеты.

Метод k-out-of-j параметризуется двумя небольшими целыми числами k и j, так что 0 < k <= j, и номинальной стоимостью канала C >= 1. Узел хранит историю последних j Hello и если из них не менее k были получены корректно, канал считается работающим (up) и устанавливается C. В противном случае канал считается неработающим (down) и устанавливается бесконечное значение rxcost.

Поскольку Babel поддерживает два типа Hello, узел Babel выполняет k-out-of-j дважды для каждого соседа с историей Unicast Hello и Multicast Hello. Если любой из вариантов k-out-of-j показывает рабочее (up) состояние канала, канал считается активным (up) и устанавливается rxcost = C. Если оба варианта указывают нерабочее (down) состояние канала, он считается неактивным и для rxcost устанавливается бесконечное значение. Иными словами, результирующим значением rxcost будет меньший из результатов двух экземпляров k-out-of-j link.

Стоимость канала с определением k-out-of-j будет:

• cost = FFFF (шестнадцатеричное), если rxcost = FFFF (шестнадцатеричное);

• cost = txcost в остальных случаях.

A.2.2. ETX

В отличии от проводных каналов, которые имеют лишь два состояния (up или down), у беспроводных соединений параметры качество могут изменяться непрерывно. Наивное применение маршрутизации по числу интервалов пересылки в сетях с беспроводными каналами для транзита имеет тенденцию к выбору длинных каналов с потерями вместо более коротких каналов без потерь, что может значительно снизить пропускную способность. По этой причине протоколы маршрутизации для беспроводных сетей должны выполнять ту или иную оценку качества соединений.

Алгоритм ETX [ETX] является простым способом оценки качества канала, предназначенным для работы с IEEE 802.11 MAC [IEEE802.11]. По умолчанию IEEE 802.11 MAC выполняет запрос автоматического повтора (Automatic Repeat Query или ARQ) и адаптацию скорости для индивидуальных кадров, но не делает этого для групповых, которые передаются с фиксированной скоростью без ARQ. Поэтому измерение частоты потерь групповых кадроа дает полезную оценку качества канала.

Узел, выполняющий оценку качества канала ETX, использует историю Multicast Hello для расчета оценки (beta) вероятности успешного приема Hello TLV. Значение параметра рассчитывается как доля битов 1 в небольшой (скажем, 6) группе последних записей истории Multicast Hello, экспоненциальное среднее значения или комбинация этих вариантов. Пусть rxcost = 256/beta.

Пусть alpha = MIN(1, 256/txcost) будет оценкой вероятности успешной передачи Hello TLV. Тогда стоимость будет cost = 256/(alpha * beta) или, эквивалентно, cost = (MAX(txcost, 256) * rxcost)/256.

Поскольку IEEE 802.11 MAC выполняет ARQ для индивидуальных кадров, такие кадры не вносят полезного вклада в измерение качества канала и ETX игнорирует историю Unicast Hello. Таким образом, узел, выполняющий оценку качества канала ETX, не будет маршрутизировать пакеты через соседние узлы, от которых он не получает Multicast Hello (возможно в дополнение в Unicast Hello).

A.3. Выбор маршрутов и гистерезис

В процессе выбора маршрута (параграф 3.6) узел выбирает один из доступных для данного адресата маршрутов. В Babel любая процедура, выбирающая лишь выполнимые маршруты с конечной метрикой будет давать маршрутизацию без петель. Однако при наличии постоянно меняющейся метрики, такой как ETX (Приложение A.2.2) наивная процедура выбора может приводить к постоянным переключениям маршрутов. Такие переключения можно ограничить и даже предотвратит путем задания гистерезиса в алгоритме выбора маршрута, например, учитывая при выборе историю маршрутов. Хорошие результаты должны давать любые разумные алгоритмы гистерезиса и ниже приведен один из вариантов, успешно развернутый во многих реализациях.

Для каждого маршрута R в дополнение к его метрике m(R) поддерживается сглаженная версия метрики ms(R) (рекомендуется рассчитывает ее как экспоненциально сглаженное среднее значение метрики в соответствии с параграфом 3.7 в [RFC793] для интервала, равного интервалу Hello, умноженному на небольшое число, например , 3). Если маршрута к данному адресату не выбрано, выбирается маршрут с наименьшей метрикой без учета сглаживания. Если выбран маршрут R, переключение на R’ выполняется лишь при условии m(R’) < m(R) и ms(R’) < ms(R).

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

Приложение B. Параметры протокола

Выбор временных констант является компромиссом между быстрым обнаружением перемещений (mobility event) и издержками протокола. Два экземпляра Babel с разными временными константами могут взаимодействовать, но при этом максимальное время схождения будет определять более медленная реализация. Интервал Hello является наиболее важной из временных констант, поскольку перебои или перемещения обнаруживаются в течение 1,5 — 3,5 интервалов Hello. В результате использования Babel таблицы маршрутов с избыточностью и работы протокола на основе триггерных обновлений интервал Update не оказывает существенного влияния на время схождения после отказа. На практике он сильно влияет лишь на время получения новых маршрутов после перемещений (mobility event). Хотя протокол разрешает интервалы меньше от 10, столь малые значения вызывают большой протокольный трафик при незначительной практической пользе.

Ниже даны проверенные на практике в разных средах значения, которые рекомендуется применять по умолчанию.

Интервал Multicast Hello

4 секунды.

Интервал Unicast Hello

Бесконечный (Unicast Hello не передаются).

Стоимость канала

Оценка ETX на беспроводных каналах и «два из трех» с C=96 — на проводных.

Интервал IHU

Анонсируемый интервал IHU составляет 3 интервала Multicast Hello. IHU передаются с каждым Hello на каналах с потерями (в соответствии с историей Hello), но лишь с каждым третьим Multicast Hello на каналах без потерь.

Интервал Update

4 интервала Multicast Hello.

Время удержания IHU

3,5 анонсированных интервала IHU.

Срок действия маршрута

3,5 анонсированных интервала обновления.

Тайм-аут для запросов

Изначально 2 секунды с удвоением при каждом повторе запроса (до 3 раз).

Тайм-аут срочности

0,2 секунды.

Время сборки мусора для источника

3 минуты.

Приложение C. Фильтрация маршрутов

Фильтрация маршрутов представляет собой процедуру, где экземпляр протокола маршрутизации отбрасывает некоторые из анонсированных соседями маршрутов или проверяет их метрику, сравнивая с ожидаемой. Подобно другим протоколам на основе вектора удаленности, Babel может применять к изучаемым маршрутам произвольные фильтры и реализации Babel с разными наборами фильтров и правилами фильтрации могут взаимодействовать, не порождая маршрутных петель. Способность протокола фильтровать маршруты обусловлена расчетом метрики, описанным в параграфе 3.5.2 — Babel может применять любую метрику со строгой монотонностью, включая метрику с бесконечным значением для выбранного подмножества маршрутов (см. также параграф 3.8.1, где запросы для несуществующих маршрутов рассматриваются как запросы маршрутов с бесконечной метрикой).

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

Фильтрация маршрутов является полезным инструментом, поскольку она позволяет точно настроить маршрутные решения, принимаемые протоколом. Поэтому некоторые реализации Babel поддерживают обширный язык настройки конфигурации, позволяющий задать набор правил фильтрации, например, по входному интерфейсу и префиксу.

Для ограничения последствий ошибочной настройки реализации Babel поддерживают по умолчанию разумный набор правил фильтрации, даже если они не позволяют настраивать фильтры пользователю. Как минимум, реализации отбрасывают маршруты с префиксом адресатов fe80::/64, ff00::/8, 127.0.0.1/32, 0.0.0.0/32, 224.0.0.0/8.

Приложение D. Расширения протокола

Протокол Babel является расширяемым и этот документ определяет множество механизмов, которые могут служить для расширения протокола с обеспечением совместимости с имеющимися версиями:

• увеличение номера версии в заголовке пакетов;

• определение новых TLV;

• определение новых суб-TLV (в битом обязательности или без него);

• определение новых AE;

• использование трейлеров в пакетах.

В этом приложении содержатся рекомендации для разработчиков расширений в части выбора кодирования.

Номер версии в заголовке Babel следует увеличивать лишь в тех случаях, когда не обеспечивается совместимости с более ранней версией протокола. Во многих случаях расширения можно реализовать путем определения новых TLV или добавления суб-TLV к имеющимся TLV. Например, расширение для добавления данных в обновления маршрутов можно реализовать путем «обогащения» Update TLV за счет необязательных или обязательных суб-TLV в Update TLV.

Различные кодировки по-разному обрабатываются реализациями, которым непонятно данное расширение. В случае новых TLV или суб-TLV с флагом обязательности не понимающая расширение реализация будет игнорировать TLV целиком, тогда как при нопонятных необязательных суб-TLV будет выполняться анализ и обработка TLV в целом с игнорированием непонятных суб-TLV. Поэтому для совместимых расширений Update TLV следует применять необязательные суб-TLV (расширение можно игнорировать), а обязательные суб-TLV или новые TLV должны применяться в расширениях, где непонятные TLV должны отбрасываться целиком.

Опыт показывает, что необходимость добавления данных обычно возникает в самых неожиданных местах. Поэтому рекомендуется определять новые TLV как самозавершающие, чтобы к ним можно было добавлять суб-TLV.

Добавление AE, по сути, эквивалентно определению нового TLV, поскольку Update TLV с неизвестным AE игнорируются подобно неизвестным TLV. Однако для добавление AE потребуется больше усилий, поскольку это создает новый набор состояний сжатия. А поскольку Next Hop TLV создает состояние, связанное с данным семейством адресов, а не данным AE, новое кодирование адресов AE для ранее определенного семейства даресов недопустимо применять в Next Hop TLV, если нужна совместимость с прежними версиями. Похожая проблема возникает для Update TLV с неизвестными AE, задающими новое значение router-id (в результате установки флага Router-Id). Поэтому определять новые AE нужно очень осторожно, если нужна совместимость с имеющимися реализациями.

Трейлер пакетов предназначен для использования криптографических подписей, охватывающих лишь тело пакета. Сохранение криптографической подписи в трейлере предотвращает сброс подписи перед расчетом хэш-значения для тела пакета и позволяет проверять подпись до запуска полного анализатора TLV с учетом состояний. Поэтому в трейлере следует размещать лишь TLV, для которых не требуется криптографическая защита. Такие TLV должны быть просты для анализа и, в частности, не требовать учета состояний при анализе.

Приложение E. Реализации-заглушки

Протокол Babel достаточно экономичен. Обновление для одного адресата занимает от 12 до 40 октетов в зависимости от семейства адресов, а средний размер составляет менее 24 октетов. Запись в таблице маршрутов для IPv6 занимает около 35 октетов. Таким образом, в один стандартный кадр Ethernet можно поместить около 65 обновлений а мегабайт памяти позволяет записать таблицу маршрутов с 20000 записей и связанную с ней таблицы источников.

Babel также является довольно простым протоколом и его полная реализация включает меньше 12000 строк C, а размер двоичного файла — меньше 120 Кбайт для 32-битовой архитектуры CISC, из которых около половины занимает код расширений и пользовательского интерфейса. Тем не менее, в некоторых средах с очень большими ограничениями, таких как КПК (PDA), микроволновые печи и т. п., может оказаться желательным реализовать лишь часть протокола.

Есть много разных определений маршрутизатора-заглушки, но здесь таким устройством считается реализация Babel, анонсирующая один или несколько подключенных напрямую префиксов в сети Babel, не не реанонсирующая полученные от соседей маршруты и всегда предпочитающая прямой маршрут к подключенному напрямую префиксу маршруту, полученному от протокола Babel, даже при одинаковых префиксах. Заглушка может поддерживать полную таблицу маршрутов или просто выбрать принятый по умолчанию маршрут через одного из соседей, анонсирующих такой маршрут. Поскольку заглушки не пересылают пакеты, не связанные с подключенными напрямую каналами, они не могут участвовать в маршрутных петлях и поэтому для них не нужно проверять условие выполнимости или поддерживать таблицу источников.

Независимо от степени упрощения, реализация-заглушка должна анализировать суб-TLV во всех понятных TLV и проверять флаг обязательности. Она должна отвечать на запросы подтверждений и участвовать в обмене Hello и IHU, а также должна быть способна отвечать на запросы seqno для анонсируемых маршрутов и на запросы маршрутов. Опыт показывает, что реализация-заглушка с поддержкой лишь IPv6 может иметь менее 1000 строк кода C и компилироваться в 13 Кбайт исполняемого кода для 32-битовой архитектуры CISC.

Приложение F. Совместимость с предыдущими версиями

Определенный в этом документе протокол является преемником протокола, заданного [RFC6126] и [RFC7557]. Хотя эти протоколы не совместимы полностью, новый протокол можно развернуть в сетях RFC 6126 без остановки работы.

Протокол имеет 3 необязательный свойства, делающих его несовместимым с предшественником. Во-первых, RFC 6126 не требует Unicast Hello (параграф 3.4.1) и реализация RFC 6126 будет ошибочно воспринимать Unicast Hello как Multicast Hello. Поскольку для этих сообщений применяются разные порядковые номера, передача Unicast Hello реализации RFC 6126 будет приводить к сбоям при оценке качества канала. Во-вторых, RFC 6126 не определяет неплановых Hello и реализация RFC 6126 будет неверно трактовать Hello с интервалом 0. В-третьих, RFC 7557 не определяет обязательных суб-TLV (параграф 4.4), поэтому реализации RFC 6126 и RFC 7557 будут некорректно игнорировать TLV с неизвестными обязательными суб-TLV, что может нарушать корректность маршрутизации.

Реализацию данного документа, которая не будет передавать Unicast и неплановые Hello, а также поддерживать какие-либо расширения с обязательными суб-TLV, можно без опаски развертывать в сети, где некоторые узлы используют протокол, определенный в RFC 6126 и RFC7557.

При внесении двух изменений в реализации RFC 6126 и RFC 7557 они смогут безопасно взаимодействовать с реализацией данной спецификации. Во-первых, нужно игнорировать или обрабатывать незапланированные и Unicast Hello. Во-вторых, нужно анализировать суб-TLV во всех понятных TLV и игнорировать TLV с неизвестными обязательными суб-TLV. Разбор неизвестных TLV не требуется и они просто игнорируются.

Ниже другие изменения, которые не препятствуют взаимодействию:

• смягчены условия восприятия маршрутов (параграф 3.5.3);

• при выборе маршрута больше не требуется его порядковый номер (параграф 3.6);

• определен формат трейлера в пакетах (параграф 4.2);

• запрещены router-id, содержащие только 0 или только 1 (параграф 4.1.3);

• состояние сжатия зависит от семейства адресов, а не от формата кодирования (параграф 4.5);

• рекомендуется задавать темп отправки пакетов (параграф 3.1).

Благодарности

Много людей внесло свой вклад в текст и идеи для этой спецификации. Авторы особо признательны Matthieu Boutier, Gwendoline Chouasne, Margaret Cullen, Donald Eastlake, Toke Høiland-Jørgensen, Benjamin Kaduk, Joao Sobrinho и Martin Vigoureux. Предыдущая версия спецификации [RFC6126] в значительной мере основана на вкладе Joel Halpern. Метод сжатия адресов был заимствован из [PACKETBB].

Адреса авторов

Juliusz Chroboczek

IRIF, University of Paris-Diderot

Case 7014

75205 Paris CEDEX 13

France

Email: jch@irif.fr

David Schinazi

Google LLC

1600 Amphitheatre Parkway

Mountain View, California 94043

United States of America

Email: dschinazi.ietf@gmail.com

Перевод на русский язык

Николай Малых

nmalykh@protokols.ru

Internet Engineering Task Force (IETF)                          C. Hopps
Request for Comments: 8819                                     L. Berger
Updates: 8407                                    LabN Consulting, L.L.C.
Category: Standards Track                                  D. Bogdanovic
ISSN: 2070-1721                                           Volta Networks
                                                            January 2021

YANG Module Tags

Теги модулей YANG

PDF

Аннотация

Этот документ связывает теги с модулями YANG. Предполагается, что использование таких тегов поможет классифицировать и организовать модули. Представлен метод определения, чтения и записи тегов модулей. Теги могут регистрироваться и назначаться в процессе создания модуля, назначаться при развертывании или динамически задаваться и устанавливаться пользователем. В документе также приведены рекомендации для разработчиков новых модулей, обновляющие RFC 8407.

Статус документа

Документ относится к категории Internet Standards Track.

Документ является результатом работы IETF¹ и представляет согласованный взгляд сообщества IETF. Документ прошел открытое обсуждение и был одобрен для публикации IESG². Дополнительную информацию о стандартах Internet можно найти в разделе 2 в RFC 7841.

Информация о текущем статусе документа, найденных ошибках и способах обратной связи доступна по ссылке https://www.rfc-editor.org/info/rfc8819.

Авторские права

Copyright (c) 2021. Авторские права принадлежат IETF Trust и лицам, указанным в качестве авторов документа. Все права защищены.

К этому документу применимы права и ограничения, перечисленные в BCP 78 и IETF Trust Legal Provisions и относящиеся к документам IETF (http://trustee.ietf.org/license-info), на момент публикации данного документа. Прочтите упомянутые документы внимательно. Фрагменты программного кода, включённые в этот документ, распространяются в соответствии с упрощённой лицензией BSD, как указано в параграфе 4.e документа IETF Trust Legal Provisions, без каких-либо гарантий (как указано в Simplified BSD License).

1. Введение

Применение тегов для классификации и организации достаточно широко распространено не только в протоколах IETF, но и в сети в целом (например, #хештеги). Одним из преимуществ использования тегов для организации по сравнению с жесткой структурой является гибкость и простота адаптации к новым технологиям. Теги можно регистрировать, но они могут также служить не регистрируемым механизмом, позволяющим пользователям самостоятельно задавать теги. В этом документе представлен механизм для определения тегов и гибкого связывания их с модулями YANG. В частности, теги можно регистрировать, а также назначать в процессе создания модулей, назначать при реализации или динамически задавать и устанавливать силами пользователя.

Этот документ определяет модуль YANG [RFC7950], включающий список записей для модулей, который позволяет добавлять и исключать теги, а также просматривать набор связанных с модулем тегов.

Документ определяет оператор расширения для указания тегов, которые следует автоматически добавлять реализации модуля (т. е. вне процедуры настройки).

Документ также задает реестр IANA для префиксов тегов и набора тегов глобального значения.

В разделе 6 приведены рекомендации для разработчиков моделей данных YANG.

Документ обновляет [RFC8407].

Модель данных YANG в этом документе соответствует архитектуре хранилища сетевого управления (Network Management Datastore Architecture или NMDA), определенной в [RFC8342].

1.1. Примеры возможного применения тегов модулей YANG

В процессе разработки этого документа возникали запросы на примеры использования тегов модулей. Ниже приведено несколько примеров применения тегов, список которых может быть расширен.

Одним из примеров служит помощь в фильтрации разных дискретных категорий модулей YANG, поддерживаемых устройством. Например, при задании для модулей подходящих тегов можно использовать запрос XPath для получения всех фирменных модулей, поддерживаемых устройством.

Теги можно также использовать для координации взаимодействия множества частично независимых клиентов с общим набором устройств. Например, один клиент управления может отметить, что некоторые модули не следует применять, поскольку корректность их поведения не проверена, чтобы другие клиенты управления избегали запроса данных, связанных с этими модулями.

Классификация по тегам полезна для пользователей при поиске в репозиториях модулей (например, каталог YANG). Запросы с тегом ietf:routing, например, можно использовать для получения лишь модулей IETF YANG, связанных с маршрутизацией. Без тега пользователю нужно знать имена всех модулей YANG для протоколов маршрутизации IETF.

Будущие расширения протоколов управления могут обеспечить фильтрацию запросов конфигурации или рабочего состояния на сервере по тегам (например, для получения рабочего состояния, связанного с управлением системой).

1.2. Используемые соглашения

Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не нужно (SHALL NOT), следует (SHOULD), не следует (SHOULD NOT), рекомендуется (RECOMMENDED), не рекомендуется (NOT RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе должны интерпретироваться в соответствии с BCP 14 [RFC2119] [RFC8174] тогда и только тогда, когда они набраны заглавными буквами, как показано здесь.

2. Значения тегов

Всем тегам следует начинаться с префикса, указывающего владельца определения. Для поддержки регистрации префиксов тегов используется реестр IANA (параграф 7.1). В настоящее время определены 3 префикса. Этот документ не задает дополнительной структуры тега после префикса и значение тега может включать любые символы типа string в YANG, за исключением возврата каретки (CR), новой строки и табуляции.

За исключением префикса, служащего для предотвращения конфликтов, этот документ намеренно не задает какой-либо структуры (т. е. ограничений) для значений тегов. Цель этого состоит в предотвращении произвольных ограничений на значения тегов, которые могут применять разработчики, операторы и пользователи. Это позволяет cвободно выбирать структуру (или ее отсутствие) для создаваемых тегов.

2.1. Теги IETF

Теги IETF начинаются с префикса ietf: и регистрируются в реестре IANA (параграф 7.2).

2.2. Теги производителей

Теги производителей начинаются с префикса vendor: и определяются производителем, реализующим модуль. Такие теги не регистрируются, однако производителям рекомендуется включать в тег дополнительную идентификацию для предотвращения конфликтов (это может быть имя компании или организации после префикса vendor:, например, vendor:example.com:vendor-defined-classifier).

2.3. Пользовательские теги

Пользовательскими считаются любые теги с префиксом user:. Эти теги задаются пользователем или администратором и не регистрируются. От пользователей не требуется применение префикса user:, но это рекомендуется для предотвращения конфликтов.

2.4. Зарезервированные теги

Все теги, не имеющие префикса ietf:, vendor: или user:, зарезервированы на будущее. Значения таких тегов не являются недействительными и просто резервируются в контексте спецификаций (например, RFC).

3. Управление тегами

Теги можно связать с модулем разными способами. Их можно определить и связать с модулем в процессе его создания, во время развертывания или с помощью пользовательских средств администрирования. Поскольку основными потребителями тегов являются пользователи, они могут также удалять теги независимо от способа их связывания с модулем.

3.1. Теги при создании модуля

Определение модуля может указывать набор тегов для добавления при реализации модуля. Эти теги указываются с помощью оператора расширения module-tag.

Если модуль определен в документе IETF Standards Track, теги должны относиться к IETF (параграф 2.1). Таким образом, новые модули могут приводить к добавлению тегов IETF в реестр IANA, определенный в параграфе 7.2, и реестр IANA будет служить для предотвращения дубликатов.

3.2. Теги при реализации

Реализация может включать дополнительные теги, связанные с модулем, которым следует быть тегами IETF (т. е. зарегистрированными) или производителя.

3.3. Теги, устанавливаемые пользователем

Теги любого типа (с префиксом или без него) могут быть добавлены или удалены пользователем с помощью обычных механизмов настройки конфигурации. Для удаления тега из рабочего хранилища пользователь добавляет соответствующую запись максирования (masked-tag) для данного модуля.

4. Структура модуля тегов

4.1. Дерево модуля тегов

Ниже приведено дерево, связанное с модулем ietf-module-tags. Значение символов описано в [RFC8340].

module: ietf-module-tags
  +--rw module-tags
     +--rw module* [name]
        +--rw name          yang:yang-identifier
        +--rw tag*          tag
        +--rw masked-tag*   tag

Рисунок 1. Дерево тегов модуля YANG.

4.2. Модуль YANG

   <CODE BEGINS> file "ietf-module-tags@2021-01-04.yang"
   module ietf-module-tags {
     yang-version 1.1;
     namespace "urn:ietf:params:xml:ns:yang:ietf-module-tags";
     prefix tags;

     import ietf-yang-types {
       prefix yang;
     }

     organization
       "IETF NetMod Working Group (NetMod)";
     contact
       "WG Web:  <https://datatracker.ietf.org/wg/netmod/> 
        WG List: <mailto:netmod@ietf.org> 

        Author: Christian Hopps
                <mailto:chopps@chopps.org> 

        Author: Lou Berger
                <mailto:lberger@labn.net> 

        Author: Dean Bogdanovic
                <mailto:ivandean@gmail.com>"; 

     description
       "Этот модуль описывает механизм связывания тегов с модулями
        YANG. Теги могут быть выделены IANA или определены приватно.

        Авторские права (Copyright (c) 2021) принадлежат IETF Trust и 
        лицам, указанным как авторы кода. Все права защищены.

        Распространение и использование в исходной или двоичной форме
        с изменениями или без таковых разрешено в соответствии с
        упрощенной лицензией BSD, как указано в параграфе 4.c
        документа IETF Trust Legal Provisions применительно к
        документам IETF (https://trustee.ietf.org/license-info).
        Данная версия модуля YANG является частью RFC 8819
        (https://www.rfc-editor.org/info/rfc8819), где правовые
        аспекты изложены более полно.

        Ключевые слова ДОЛЖНО, НЕДОПУСТИМО, ТРЕБУЕТСЯ, НУЖНО, НЕ НУЖНО,
        СЛЕДУЕТ, НЕ СЛЕДУЕТ, РЕКОМЕНДУЕТСЯ, НЕ РЕКОМЕНДУЕТСЯ, МОЖНО,
        НЕОБЯЗАТЕЛЬНО в этом документе интерпретируются в соответствии
        с BCP 14 (RFC 2119) (RFC 8174) тогда и только тогда, когда они
        указаны заглавными буквами, как показано здесь.";

     revision 2021-01-04 {
       description
         "Исходный выпуск.";
       reference
         "RFC 8819: YANG Module Tags";
     }

     typedef tag {
       type string {
         length "1..max";
         pattern '[\S ]+';
       }
       description
         "Тег является значением типа string, не включающим символов
          возврата каретки, перевода строки и табулфции. Теги СЛЕДУЕТ
          начинать с зарегистрированного префикса, однако теги без
          такого префикса НЕ СЛЕДУЕТ считать недействительными.";
     }

     extension module-tag {
       argument tag;
       description
         "Аргумент tag имеет тип tag. Этот оператор расширения применяется
          авторами модулей для указания тегов, которые системе СЛЕДУЕТ
          добавлять автоматически. Таким образом, источником значения для
          предопределенных тегов следует устанавливать system [RFC8342].";
     }

     container module-tags {
       description
         "Содержит список модулей и связанных с ними тегов.";
       list module {
         key "name";
         description
           "Список модулей и связанных с ними тегов.";
         leaf name {
           type yang:yang-identifier;
           mandatory true;
           description
             "Имя модуля YANG.";
         }
         leaf-list tag {
           type tag;
           description
             "Теги, связанные с модулем. Зарезервированные префиксы 
              указаны в реестре IANA YANG Module Tag Prefixes, а теги
              IETF - в реестре IANA IETF YANG Module Tags.

              Состояние operational [RFC8342] для этого списка 
              создается, как показано ниже.

              1) Системные теги (теги с источником system).
              2) Заданные пользователем теги (теги с источником intended).
              3) Все теги, соответствующие masked-tag удаляются.";
         }
         leaf-list masked-tag {
           type tag;
           description
             "Список тегов, которые на следует связывать с этим модулем.
              Пользователь может удалить (замаскировать) теги из рабочего
              хранилища данных [RFC8342], добавляя их в этот список.
              Добавление в список тега, не связанного с модулем, не 
              является ошибкой и не будет оказывать никакого влияния.";
         }
       }
     }
   }
   <CODE ENDS>

Рисунок 2. Модуль тегов.

5. Другая классификация

Следует отметить наличие другого документа с классификацией модулей YANG [RFC8199]. Этот документ классифицирует модули логически и не включает тегов или иных механизмов. Модули YANG в нем разделены на две категории (service и element), для каждой из которых возможны 3 источника — standard, vendor или user. Это обеспечивает хороший способ обсуждения и идентификации модулей в целом. Определенные здесь теги IETF поддерживают стиль классификации, описанный в [RFC8199].

6. Рекомендации для создателей модулей

Этот раздел обновляет [RFC8407].

6.1. Определение стандартных тегов

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

   module example-module {
     namespace "https://example.com/yang/example";
     prefix "ex";
     //...
     import module-tags { prefix tags; }

     tags:module-tag "ietf:some-new-tag";
     tags:module-tag "ietf:some-other-tag";
     // ...
   }

Авторы модулей могут использовать имеющиеся стандартные теги или задавать новые в определении модели. Для стандартизованных IETF модулей новые теги должны включаться в реестр IANA, определенный в параграфе 7.2.

7. Взаимодействие с IANA

7.1. Реестр YANG Module Tag Prefixes

Агентство IANA создало субреестр YANG Module Tag Prefixes в реестре YANG Module Tags для регистрации префиксов тегов. Всем тегам модулей YANG следует начинаться с одного из префиксов, включенных в этот реестр.

Префиксам в этом реестре следует быть короткими строками алфавитно-цифровых символов ASCII в нижнем регистре, заканчивающимися символом :. Включение префиксов в этот реестр выполняется по процедуре Specification Required [RFC8126]. Значения Reference и Assignee должны позволять идентифицировать организацию, которой был выделен префикс, и ее контактные данные.

Начальные значения префиксов указаны в таблице 1.

Таблица 1.

Префикс	Описание	Документ	Организация
ietf:	Теги IETF, включенные в реестр IANA IETF YANG Module Tags.	RFC 8819	IETF
vendor:	Не регистрируемые теги, выделенные разработчиком модуля.	RFC 8819	IETF
user:	Не регистрируемые теги, выделенные пользователем или для него.	RFC 8819	IETF

Другим органам стандартизации (standards development organization или SDO), желающим создать свой набор тегов, следует получить префикс из этого реестра.

7.2. Реестр IETF YANG Module Tags

Агентство IANA создало субреестр IETF YANG Module Tags в реестре YANG Module Tags ниже реестра YANG Module Tag Prefixes.

Этот реестр включает теги, имеющие зарегистрированный префикс ietf:. Новые значения тегов должны быть хорошо обдуманы и не должны представлять собой комбинацию уже имеющихся тегов IETF. Выделенные IANA теги должны соответствовать требованиям Net-Unicode [RFC5198] без нормализации. Значения тегов выделяются по процедуре IETF Review [RFC8126].

Начальные значения тегов приведены в таблице 2.

Таблица 2.

Tag	Description	Reference
ietf:network-element-class	Элемент сети в соответствии с [RFC8199].	[RFC8199]
ietf:network-service-class	Сетевая служба в соответствии с [RFC8199].	[RFC8199]
ietf:sdo-defined-class	Модуль, определенный органом стандартизации.	[RFC8199]
ietf:vendor-defined-class	Модуль, определенный производителем.	[RFC8199]
ietf:user-defined-class	Модуль, определенный пользователем.	[RFC8199]
ietf:hardware	Связан с оборудованием (например, инвентаризация).	RFC 8819
ietf:software	Связан с программой (например, установленной ОС).	RFC 8819
ietf:protocol	Представляет протокол (часто с другим тегом для уточнения).	RFC 8819
ietf:qos	Связан с качеством обслуживания.	RFC 8819
ietf:network-service-app	Связан с приложением сетевых услуг (например, сервер NTP, DNS, DHCP и т. п.).	RFC 8819
ietf:system-management	Связан с управлением системой (например, протокол управления, такой как TACACS+, SNMP, NETCONF.).	RFC 8819
ietf:oam	Связан с OAM (Operations, Administration, Maintenance, например, BFD).	RFC 8819
ietf:routing	Связан с маршрутизацией.	RFC 8819
ietf:security	Связан с безопасностью.	RFC 8819
ietf:signaling	Связан с сигнализацией плоскости управления.	RFC 8819
ietf:link-management	Связан с управлением каналом.	RFC 8819

7.3. Обновление реестра IETF XML

Этот документ регистрирует URI в IETF XML Registry [RFC3688] в соответствии с форматом [RFC3688].

   URI:  urn:ietf:params:xml:ns:yang:ietf-module-tags
   Registrant Contact:  The IESG.
   XML:  N/A; the requested URI is an XML namespace.

   URI:  urn:ietf:params:xml:ns:yang:ietf-module-tags-state
   Registrant Contact:  The IESG.
   XML:  N/A; the requested URI is an XML namespace.

7.4. Обновление реестра YANG Module Names

Документ включает 2 модуля YANG в реестр YANG Module Names [RFC6020] в соответствии с форматом [RFC6020].

   name:  ietf-module-tags
   namespace:  urn:ietf:params:xml:ns:yang:ietf-module-tags
   prefix:  tags
   reference:  RFC 8819

   name:  ietf-module-tags-state
   namespace:  urn:ietf:params:xml:ns:yang:ietf-module-tags-state
   prefix:  tags-s
   reference:  RFC 8819

8. Вопросы безопасности

Определенный в этом документе модуль YANG предназначен для доступа по протоколу NETCONF [RFC6241]. Нижним уровнем NETCONF является защищенный транспорт с обязательной реализацией Secure Shell (SSH) [RFC6242].

Этот документ добавляет возможность связать метаданные (теги) с модулями YANG. Документ не задает каких-либо действий на основе этих ассоциаций, поэтому сам по себе не создает новых проблем безопасности.

Пользователи тегов могут определять различные действия на основе метаданных из тегов. Такие действия и их определения выходят за рамки данного документа. Пользователи должны самостоятельно рассмотреть влияние определяемых действий на безопасность, включая возможность «маскирования» тегов другими пользователями.

9. Литература

9.1. Нормативные документы

[RFC2119] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC7950] Bjorklund, M., Ed., «The YANG 1.1 Data Modeling Language», RFC 7950, DOI 10.17487/RFC7950, August 2016, <https://www.rfc-editor.org/info/rfc7950>.

[RFC8126] Cotton, M., Leiba, B., and T. Narten, «Guidelines for Writing an IANA Considerations Section in RFCs», BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.

[RFC8174] Leiba, B., «Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words», BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8199] Bogdanovic, D., Claise, B., and C. Moberg, «YANG Module Classification», RFC 8199, DOI 10.17487/RFC8199, July 2017, <https://www.rfc-editor.org/info/rfc8199>.

[RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., and R. Wilton, «Network Management Datastore Architecture (NMDA)», RFC 8342, DOI 10.17487/RFC8342, March 2018, <https://www.rfc-editor.org/info/rfc8342>.

[RFC8407] Bierman, A., «Guidelines for Authors and Reviewers of Documents Containing YANG Data Models», BCP 216, RFC 8407, DOI 10.17487/RFC8407, October 2018, <https://www.rfc-editor.org/info/rfc8407>.

9.2. Дополнительная литература

[RFC3688] Mealling, M., «The IETF XML Registry», BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, <https://www.rfc-editor.org/info/rfc3688>.

[RFC5198] Klensin, J. and M. Padlipsky, «Unicode Format for Network Interchange», RFC 5198, DOI 10.17487/RFC5198, March 2008, <https://www.rfc-editor.org/info/rfc5198>.

[RFC6020] Bjorklund, M., Ed., «YANG — A Data Modeling Language for the Network Configuration Protocol (NETCONF)», RFC 6020, DOI 10.17487/RFC6020, October 2010, <https://www.rfc-editor.org/info/rfc6020>.

[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., «Network Configuration Protocol (NETCONF)», RFC 6241, DOI 10.17487/RFC6241, June 2011, <https://www.rfc-editor.org/info/rfc6241>.

[RFC6242] Wasserman, M., «Using the NETCONF Protocol over Secure Shell (SSH)», RFC 6242, DOI 10.17487/RFC6242, June 2011, <https://www.rfc-editor.org/info/rfc6242>.

[RFC8340] Bjorklund, M. and L. Berger, Ed., «YANG Tree Diagrams», BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, <https://www.rfc-editor.org/info/rfc8340>.

Приложение A. Примеры

Ниже приведен вымышленный пример вывода NETCONF, полученного по запросу списка тегов модулей. Для краткости показаны результаты лишь для нескольких модулей.

   <ns0:data xmlns:ns0="urn:ietf:params:xml:ns:netconf:base:1.0">
     <t:module-tags
      xmlns:t="urn:ietf:params:xml:ns:yang:ietf-module-tags">
       <t:module>
         <t:name>ietf-bfd</t:name>
         <t:tag>ietf:network-element-class</t:tag>
         <t:tag>ietf:oam</t:tag>
         <t:tag>ietf:protocol</t:tag>
         <t:tag>ietf:sdo-defined-class</t:tag>
       </t:module>
       <t:module>
         <t:name>ietf-isis</t:name>
         <t:tag>ietf:network-element-class</t:tag>
         <t:tag>ietf:protocol</t:tag>
         <t:tag>ietf:sdo-defined-class</t:tag>
         <t:tag>ietf:routing</t:tag>
       </t:module>
       <t:module>
         <t:name>ietf-ssh-server</t:name>
         <t:tag>ietf:network-element-class</t:tag>
         <t:tag>ietf:protocol</t:tag>
         <t:tag>ietf:sdo-defined-class</t:tag>
         <t:tag>ietf:system-management</t:tag>
       </t:module>
     </t:module-tags>
   </ns0:data>

Рисунок 3. Пример вывода для запроса NETCONF.

Приложение B. Модуль просмотра состояния не-NMDA

Ниже приведен модуль [RFC8407] для поддержки просмотра рабочего состояния сервера, не поддерживающего NMDA.

   <CODE BEGINS> file "ietf-module-tags-state@2021-01-04.yang"
   module ietf-module-tags-state {
     yang-version 1.1;
     namespace "urn:ietf:params:xml:ns:yang:ietf-module-tags-state";
     prefix tags-s;

     import ietf-yang-types {
       prefix yang;
     }
     import ietf-module-tags {
       prefix tags;
     }

     organization
       "IETF NetMod Working Group (NetMod)";
     contact
       "WG Web:  <https://datatracker.ietf.org/wg/netmod/> 
        WG List: <mailto:netmod@ietf.org> 

        Author: Christian Hopps
                <mailto:chopps@chopps.org> 

        Author: Lou Berger
                <mailto:lberger@labn.net> 
        Author: Dean Bogdanovic
                <mailto:ivandean@gmail.com>"; 

     description
       "Этот модуль описывает механизм связывания тегов с модулем YANG.
        Теги могут выделяться IANA или определяться приватно.

        Это временный модуль, предназначенный для использования 
        реализациями, еще не поддерживающими NMDA.

        Авторские права (Copyright (c) 2021) принадлежат IETF Trust и 
        лицам, указанным как авторы кода. Все права защищены.

        Распространение и использование в исходной или двоичной форме
        с изменениями или без таковых разрешено в соответствии с
        упрощенной лицензией BSD, как указано в параграфе 4.c
        документа IETF Trust Legal Provisions применительно к
        документам IETF (https://trustee.ietf.org/license-info).
        Данная версия модуля YANG является частью RFC 8819
        (https://www.rfc-editor.org/info/rfc8819), где правовые
        аспекты изложены более полно.";

     revision 2021-01-04 {
       description
         "Исходный выпуск.";
       reference
         "RFC 8819: YANG Module Tags";
     }

     container module-tags-state {
       config false;
       status deprecated;
       description
         "Содержит список модулей и связанных с ними тегов.";
       list module {
         key "name";
         status deprecated;
         description
           "Список модулей и связанных с ними тегов.";
         leaf name {
           type yang:yang-identifier;
           mandatory true;
           status deprecated;
           description
             "Имя модуля YANG.";
         }
         leaf-list tag {
           type tags:tag;
           status deprecated;
           description
             "Теги, связанные с модулем. Зарезервированные префиксы 
              указаны в реестре IANA YANG Module Tag Prefixes, а теги
              IETF - в реестре IANA IETF YANG Module Tags.

              Содержимое этого списка создается, как показано ниже.

              1) Системные теги (теги, добавленные системой).
              2) Заданные пользователем теги (теги, заданные в конфигурации).
              3) Все теги, соответствующие masked-tag в соответствующем
              листе ietf-module-tags:module-tags:module-tag удаляются.";
         }
       }
     }
   }
   <CODE ENDS>

Рисунок 4. Модуль состояния тегов модуля не-NMDA

Благодарности

Большое спасибо Robert Wilton за помощь в предоставлении примеров использования а также в создании модуля non-NMDA.

Адреса авторов

Christian Hopps

LabN Consulting, L.L.C.

Email: chopps@chopps.org

Lou Berger

LabN Consulting, L.L.C.

Email: lberger@labn.net

Dean Bogdanovic

Volta Networks

Email: ivandean@gmail.com

Перевод на русский язык

Николай Малых

nmalykh@protokols.ru

Internet Engineering Task Force (IETF)                        C. Bormann
Request for Comments: 8949                        Universität Bremen TZI
STD: 94                                                       P. Hoffman
Obsoletes: 7049                                                    ICANN
Category: Standards Track                                  December 2020
ISSN: 2070-1721

Concise Binary Object Representation (CBOR)

Краткое представление двоичных объектов

PDF

Аннотация

Краткое представление двоичных объектов (Concise Binary Object Representation или CBOR) — это формат данных, разработанный специально для обеспечения очень малого размера кода и расширяемость без необходимости согласовывать версии. Эти цели отличают CBOR от предшествующих вариантов двоичной сериализации, таких как ASN.1 и MessagePack.

Этот документ отменяет RFC 7049, внося редакторские правки, новые детали и исправление ошибок при сохранении полной совместимости с форматом обмена RFC 7049. Документ не задаёт новой версии формата.

Статус документа

Документ относится к категории Internet Standards Track.

Документ является результатом работы IETF¹ и представляет согласованный взгляд сообщества IETF. Документ прошёл открытое обсуждение и был одобрен для публикации IESG². Дополнительную информацию о стандартах Internet можно найти в разделе 2 в RFC 7841.

Информация о текущем статусе документа, найденных ошибках и способах обратной связи доступна по ссылке https://www.rfc-editor.org/info/rfc8949.

Авторские права

Copyright (c) 2020. Авторские права принадлежат IETF Trust и лицам, указанным в качестве авторов документа. Все права защищены.

К документу применимы права и ограничения, указанные в BCP 78 и IETF Trust Legal Provisions и относящиеся к документам IETF (http://trustee.ietf.org/license-info), на момент публикации данного документа. Прочтите упомянутые документы внимательно. Фрагменты программного кода, включённые в этот документ, распространяются в соответствии с упрощённой лицензией BSD, как указано в параграфе 4.e документа IETF Trust Legal Provisions, без каких-либо гарантий (как указано в Simplified BSD License).

1. Введение

Имеются сотни стандартизованных форматов для двоичного представления структурированных данных (binary serialization format). Некоторые из них предназначены для конкретных сфер информации, другие — для произвольных данных. В IETF наиболее известными форматами второй категории являются ASN.1 BER и DER [ASN.1].

Описываемый здесь формат следует некоторым целям, не вполне совпадающим с целями имеющихся форматов. Базовой моделью данных служит расширяемая версия модели JSON [RFC8259]. Важно отметить, что это не предложение по расширению грамматики RFC 8259 в целом, поскольку формат может быть не совместим с имеющимися вариантами JSON. В документе просто определяется своя модель данных, начинающаяся с JSON.

В Приложении E приведены некоторые имеющиеся двоичные форматы и обсуждается их соответствие целям CBOR.

Этот документ отменяет [RFC7049], внося редакторские правки, новые детали и исправление ошибок при сохранении полной совместимости с форматом обмена RFC 7049. Документ не задаёт новой версии формата.

1.1. Цели

Цели CBOR примерно в порядке снижения важности указаны ниже.

1. Представление должно однозначно кодировать наиболее общие типы данных, применяемые в стандартах Internet.

   • Должен предоставляться разумный набор базовых типов и структур данных с применением двоичного кодирования. Разумность здесь во многом определяется возможностями JSON с добавлением двоичных строк данных. К поддерживаемым структурам относятся массивы и деревья, а циклы и графы в виде решёток (lattice-style) не поддерживаются.

   • Не требуется однозначное кодирование всех типов данных, т. е. возможно представление, например, числа 7, разными способами.

2. Код для кодера или декодера должен быть компактным, чтобы поддерживать системы с ограниченной памятью, мощностью процессора и набора инструкций.

   • Кодер и декодер должны быть реализуемы очень небольшим объёмом кода (например, в ограниченных узлах класса 1, как определено в [RFC7228]).

   • Формату следует использовать современное машинное представление данных (например, без преобразования между двоичными и десятичными значениями).

3. Данные должны быть декодируемыми без описания схемы.

   • Как в JSON, кодирование данных должно быть самоописывающим, чтобы можно было создать универсальный декодер.

4. Сериализация должна быть разумно компактной, но компактность кода важней компактности данных.

   • Разумность здесь ограничивается JSON в качестве верхней границы размера и сложностью реализации, которая ограничивает усилия, затрачиваемые на обеспечение компактности. Применение общих схем сжатия или избыточного перебора битов нарушает этот подход.

5. Формат должен быть применим как для узлов с ограничениями, так и для приложений с большим объёмом данных.

   • Это значит, что он должен быть достаточно экономным в части ресурсов CPU, применяемых для кодирования и декодирования. Это актуально как для узлов с ограничениями, так и для возможного использования в приложениях с большими объёмами данных.

6. Формат должен поддерживать все типы данных JSON для преобразования в JSON и обратно.

   • Должен поддерживаться разумный уровень преобразования для данных, представляемых в пределах возможностей JSON. Должна быть возможность определить одностороннее преобразование в JSON для всех типов данных.

7. Формат должен быть расширяемым и для расширенных данных должно поддерживаться декодирование более ранними декодерами.

   • Формат рассчитан на использование в течение десятилетий.

   • Формат должен поддерживать расширяемость, допускающую откат, чтобы декодер, не поддерживающий расширения, мог декодировать сообщение.

   • Формат должен обеспечивать возможность расширения в будущих стандартах IETF.

1.2. Терминология

Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не нужно (SHALL NOT), следует (SHOULD), не следует (SHOULD NOT), рекомендуется (RECOMMENDED), не рекомендуется (NOT RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе должны интерпретироваться в соответствии с BCP 14 [RFC2119] [RFC8174] тогда и только тогда, когда они выделены шрифтом, как показано здесь.

Термин «байт» применяется в обычном смысле как синоним октета (битов). Все многобайтовые значения представляются в сетевом порядке байтов (сначала старший байт, big-endian). Используемые в спецификации термины определены ниже.

Data item — элемент данных

Единая часть данных CBOR. Структура элемента данных может включать вложенные элементы. Термин применяется как для элементов данных в формате представления, так и для абстрактной идеи, которая может быть выведена из него с помощью декодера. Первый может называться более конкретно кодированным элементом данных.

Decoder — декодер

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

Encoder — кодер

Процесс, создающий (корректно сформированное) представление элемента данных CBOR из данных приложения.

Data Stream — поток данных

Последовательность (возможно пустая) элементов данных, не связанных в более крупный элемент данных (см. [RFC8742]). Независимые элементы данных, составляющие поток иногда называют элементами данных верхнего уровня (top-level data item).

Well-formed — корректно сформированный

Элемент данных, соответствующий синтаксической структуре CBOR. Корректно сформированный элемент данных использует начальные байты и строки байтов и/или элементы данных, предполагающие значения в соответствии с CBOR, и не включают после них посторонних данных. Декодеры CBOR по определению возвращают содержимое лишь корректно сформированных элементов данных.

Valid — действительный, пригодный

Корректно сформированный элемент данных, следующий семантическим ограничениям CBOR (параграф 5.3).

Expected — ожидаемый

Помимо обычного значения «ожидаемый» этот термин служит для описания требований сверх пригодности CBOR, которые приложение предъявляет к входным данным. Корректность формирования (полностью обрабатываемый), пригодность (проверка на пригодность базовым декодером) и ожидаемость (проверка приложением) формируют иерархию уровней пригодности.

Stream decoder — потоковый декодер

Процесс, декодирующий поток данных и делающий каждый из элементов данных в последовательности доступным для приложения по мере получения.

Термины и концепции для значений с плавающей точкой, таких как бесконечность (Infinity), не число (NaN — not a number), отрицательный 0 (negative zero), и субнормальное значение (subnormal), определены в [IEEE754].

При описании битовой арифметики и типов данных в документе применяется синтаксис, похожий на используемый в языке C [C], однако «..» означает диапазон с включением обеих границ, а надстрочный индекс — возвадение в степень (например, 2 в степени 64 обозначается как 2^(64)). В текстовой версии спецификации надстрочные индексы недоступны, поэтому применяется суррогатная нотация. Такая нотация не совсем подходит для данного RFC, поскольку её можно спутать с обозначением исключающего ИЛИ в языке C (здесь встречается лишь в приложениях, где нет примеров возведения в степень) и от читателя требуется осмотрительность при работе с текстовой версией³.

В примерах и псевдокоде предполагается, что целые числа со знаком представлены дополнением до 2 и сдвиг числа со знаком вправо учитывает знак. Такие же допущения заданы в параграфах 6.8.1 (basic.fundamental) и 7.6.7 (expr.shift) версии C++ 2020 (доступна в виде финального черновика [Cplusplus20]).

Подобно 0x для обозначения шестнадцатеричных чисел, для двоичных чисел применяется префикс 0b. Для удобочитаемости в числа могут включаться символы подчёркивания, например, 0b00100001 (0x21) можно записать как 0b001_00001, чтобы подчеркнуть желательную интерпретацию битов в байте (здесь значение делится на части с 3 и 5 битами). Элементы данных в кодировке CBOR всегда указываются в нотации 0x или 0b и сначала интерпретируются как числа, подобно C, затем — как строки байтов с сетевым порядком, включая нулевые байты в начале.

Слова могут выделяться курсивом и в текстовом варианте документа это указывается символами подчеркивания (_italicized_) по обе стороны слова. Дословный текст (например, имена из языка программирования) может указываться фиксированным шрифтом и в текстовой версии документда для этого (не вполне однозначно) применяются двойные кавычки («monospace»), которые применяются и в обычном своём значении.

2. Модели данных CBOR

CBOR явно указывает свою базовую модель данных, определяющую набор всех элементов данных, которые могут быть представлены в CBOR. Базовая модель данных может расширяться путём регистрации «простых значений» и тегов. Приложения могут затем создавать подмножество расширенной базовой модели данных для своих моделей.

В средах, где элементы данных могут быть представлены в базовой модели данных, можно реализовать базовые кодеры и декодеры CBOR (это обычно включает определение дополнительных типов данных реализации для элементов, не имеющих естественного представления в среде). Возможность обеспечить базовые кодеры и декодеры является явной целью разработки CBOR, однако многие приложения будут предоставлять свои кодеры и декодеры.

В базовой (не расширенной) модели данных, описанной в разделе 3, элементами данных могут быть:

• целые числа от -2⁶⁴ до 2⁶⁴-1, включительно;

• простые значения, указываемые числом от 0 до 255, но не являющиеся числами;

• значения с плавающей точкой, отличающиеся от целых чисел вне набора IEEE 754 binary64 (включая неконечные) [IEEE754];

• последовательность (возможно пустая) байтов (строка байтов);

• последовательность (возможно пустая) кодов Unicode (строка текста);

• последовательность (возможно пустая) элементов данных (массив);

• отображение (математическая функция) набора (возможно пустого) элементов данных (ключ) на элемент данных (значение), (отображение)

• помеченный тегом элемент данных, содержащий номер (целое число от 0 до 2⁶⁴-1) и содержимое тега (элемент данных).

Отметим, что целые и действительные (floating-point) числа в этой модели различаются, даже когда значения чисел совпадают.

Отметим также, что варианты сериализации не видны на уровне базовой модели данных. Это преднамеренное отсутствие видимости включает число байтов кодированных значений с плавающей точкой. Это относится также к выбору кодирования для «аргумента» (раздел 3), такого как кодирование целого числа, кодирование размера строки текста или байтов, кодирование числа элементов в массиве, пар в отображении или номеров тегов.

2.1. Расширенные базовые модели данных

Базовая модель данных расширена в этом документе путём регистрации ряда простых значений и номеров тегов:

• false, true, null, undefined (простые значения, указываемые числами от 20 до 23, параграф 3.3);

• целые и действительные (floating-point) числа с большим диапазоном и точностью, чем указано выше (теги 2 — 5, параграф 3.4);

• типы данных приложения, такие как момент времени или даты и времени, определённые в RFC 3339 (теги 1 и 0, параграф 3.4)

Дополнительные элементы расширенной базовой модели данных могут быть (и были) определены через реестры IANA, созданные для CBOR. Даже при неизвестности такого расширения базовому кодеру или декодеру, использующие это расширение элементы данных могут передаваться в приложение или из него путём их представления на интерфейсе приложения в рамках обычной базовой модели данных, т. е. как базовые простые значения или базовые теги.

Иными словами, базовая модель данных стабильна, как определено в этом документе, а расширенные базовые модели создаются путём регистрации новых простых значений или номеров тегов без сокращения базовой модели.

Имеются серьёзные основания ждать, что базовые кодеры и декодеры смогут представлять false, true, null (undefined намерено не указано) в форме, подходящей для среды программирования, а поддержка расширений модели данных по тегам является полностью необязательной и зависит от качества реализации.

2.2. Конкретные модели данных

Конкретная модель данных для протокола на основе CBOR обычно принимает подмножество расширенной базовой модели данных и назначает семантику приложения для элементов данных в этом подмножестве и его компонентах. При документировании таких моделей данных и задании типов элементов данных предпочтительно указывать типы их именами в базовой модели (negative integer, array), а не ссылаться на аспекты их представления CBOR (major type 1, major type 4).

Конкретные модели данных могут также задавать эквивалентность значений (включая разнотипные) для ключей отображений и свободы кодеров. Например, в базовой модели данных действительное отображение может иметь в качестве ключей 0 и 0.0, а кодеру недопустимо представлять 0.0 как целое число (major type 0, параграф 3.1). Однако, если конкретная модель данных заявляет эквивалентность целых и действительных значений одного числа, использование ключей 0 и 0.0 в одном отображении будет считаться дублированием, даже если они представляются разными базовыми типами, а это не допускается и кодер может представлять целочисленные действительные значения целым числом или наоборот, возможно для экономии размера закодированного значения.

3. Спецификация кодирования CBOR

Элемент данных CBOR (раздел 2) кодируется или декодируется через строку байтов, содержащую корректно сформированный, кодированный элемент данных, как описано в этом параграфе. Сводка кодирования приведена в таблице 7 Приложения B, индексом служит начальный байт. Кодер должен создавать только корректно сформированные элементы данных. Декодеру недопустимо возвращать элемент данных, если он получил на входе некорректно сформированный элемент данных CBOR (это не умаляет полезности средств диагностики и восстановления, которые могут сделать доступной некоторую информацию из повреждённого элемента данных CBOR).

Начальный байт каждого кодированного элемента данных содержит сведения об основном типе (major type — 3 старших бита, описанных в параграфе 3.1) и дополнительное значение (5 младших битов). С некоторыми исключениями, значение этих 5 байтов описывает способ загрузки целочисленного (без знака) аргумента, как описано ниже.

Меньше 24

Значением аргумента является дополнительное значение.

24, 25, 26, 27

Значение аргумента размещено в следующих 1, 2, 4 или 8 байтах (соответственно) с сетевым порядком. Для базового типа 7 и дополнительных значений 25, 26, 27 эти байты содержат не целочисленный аргумент, а число с плавающей точкой (см. параграф s3.3).

28, 29, 30

Эти значения зарезервированы для будущих расширений CBOR. В текущей версии закодированный элемент будет некорректным по форме.

31

Значение аргумента не выводится. Для базовых типов 0, 1, 6 закодированный элемент некорректен по форме. Для базовых типов 2 — 5 размер элемента не определён, а для типа 7 байт не указывает элемент данных, а просто завершает элемент неопределённого размера (см. параграф 3.2).

Начальный байт и любые дополнительные байты, служащие для построения аргумента, называют головой (_head_) элемента данных.

Назначение аргумента зависит от базового типа (major type). Например, для типа 0 аргументом служит значение самого элемента данных, а для типа 1 значение элемента данных вычисляется из аргумента, для типов 2 и 3 аргумент указывает размер следующей за ним строки данных в байтах, для типов 4 и 5 аргумент служит для определения числа вложенных элементов данных.

Если закодированная последовательность байтов завершается раньше конца элемента данных, это говорит о некорректной форме элемента данных. Если в закодированной последовательности байтов остаются байты после декодирования внешнего кодированного элемента, этот код не представляет один корректно сформированный элемент CBOR. В зависимости от приложения декодер может счесть кодирование некорректным или просто идентифицировать начало оставшихся байтов для приложения.

Реализация декодера CBOR может быть основана на таблице переходов со всеми 256 определёнными значениями начального байта (Таблица 7). В реализации с ограничениями декодер может применять структуру начального байта и следующих байтов для более компактного кода (в Приложении C показано, как это можно сделать).

3.1. Базовые типы

Ниже описаны базовые типы, дополнительные значения и другие байты, связанные с типом.

Базовый тип 0

Целое число без знака от 0 до 2⁶⁴-1, включительно. Значением закоированного элемента является сам аргумент. Например, целое число 10 обозначается как байт 0b000_01010 (базовый тип 0, дополнительное значение 10). Целое число 500 будет иметь вид 0b000_11001 (базовый тип 0, дополнительное значение 25) с двумя байтами 0x01f4, указывающими десятичное значение 500.

Базовый тип 1

Отрицательное целое число от -2⁶⁴ до -1, включительно. Значением элемента будет -1 за вычетом аргумента. Например, целое число -500 будет иметь вид 0b001_11001 (базовый тип 1, дополнительное значение 25) с двумя байтами 0x01f3, указывающими десятичное число 499.

Базовый тип 2

Строка байтов, число которых указывает аргумент. Например, строка из 5 байтов имеет начальный байт 0b010_00101 (базовый тип 2, дополнительное значение 5 для размера) с 5 байтами двоичного содержимого. Строка из 500 байтов будет иметь начальный байт 0b010_11001 (базовый тип 2, дополнительное значение 25 для указания 2-байтового поля размера), 2-байтовое поле 0x01f4, указывающее размер 500 и пятьсот байтов двоичного содержимого.

Базовый тип 3

Текстовая строка (раздел 2) в кодировке UTF-8 [RFC3629]. Число байтов в строке указывает аргумент. Строка с непригодной последовательностью UTF-8 считается корректно сформированной, но недействительной (параграф 1.2). Этот тип предназначен для систем, которым нужно интерпретировать или выводить человекочитаемый текст и позволяет отделить неструктурированные байты от текста, имеющего конкретное значение (в Unicode) и кодировку (UTF-8). В отличие от таких форматов, как JSON, символы Unicode в этом типе никогда не экранируются (escape). Таким образом, символ новой строки (U+000A) всегда представляется в строке как 0x0a, а не байтами 0x5c6e (символы \ и n) или 0x5c7530303061 (символы \, u, 0, 0, 0, a).

Базовый тип 4

Массив элементов данных. В других форматах массивы называют также списками, последовательностями и кортежами (последовательность CBOR немного отличается, [RFC8742]). Аргумент указывает число элементов данных в массиве, которые не обязаны быть однотипными. Например, массив с 10 элементами любых типов будет иметь начальный байт 0b100_01010 (базовый тип 4, дополнительное значение 10 указывает число элементов), за которым следует 10 элементов массива.

Базовый тип 5

Сопоставление (отображение) пар элементов данных. Отображения называют также таблицами, словарями, хэшами или объектами (в JSON). Отображение состоит из пар элементов данных, каждая из которых содержит ключ и непосредственно следующее за ним значение. Аргумент указывает число пар элементов в отображении. Например, отображение с 9 парами будет иметь начальный байт 0b101_01001 (базовый тип 5, дополнительное значение 9 для числа пар), за которым следует 18 элементов. Первым элементом всегда является первый ключ, вторым — первое значение, третьим — второй ключ и т. д. Поскольку элементы отображения являются парами, их число всегда чётно и отображение с нечётным числом элементов (нет значения после последнего ключа) считается некорректно сформированным. Отображение с дублированием ключей считается корректно сформированным, но непригодным и ведёт к неопределённому декодированию (см. параграф 5.6).

Базовый тип 6

Помеченный тегом элемент данных, номер тега которого указан целым числом от 0 до 2⁶⁴-1, включительно, являющимся аргументом, а вложенным элементом данных (содержимое тега) является один элемент данных, следующий за головой (см. параграф 3.4).

Базовый тип 7

Числа с плавающей точкой (запятой) и простые значения, а также код завершения break (см. параграф 3.3).

Эти 8 базовых типов задают простую таблицу, показывающую, какие из 256 возможных значений начального байта элемента данных используются (Таблица 7).

В базовых типах 6 и 7 зарезервировано множество возможных значений для будущих спецификаций (см. раздел 9).

В таблице 1 дана сводка базовых типов CBOR без учёта параграфа 3.2. Число N в таблице указывает аргумент.

Таблица 1. Сводка базовых типов CBOR с определенным размером (N — аргумент).

 

Базовый тип	Значение	Содержимое
0	Целое число без знака N	—
1	Отрицательное целое число -1-N	—
2	Строка байтов	N байтов
3	Строка текста	N байтов текста UTF-8
4	Массив	N элементов данных
5	Отображение	2N элементов данных (пары ключ-значение)
6	Тег с номером N	1 элемент данных
7	Простое значение, действительное число (float)	—

 

3.2. Неопределённый размер некоторых базовых типов

Четыре элемента CBOR (массивы, отображения, строки байтов и текста) могут кодироваться с неопределённым размером, используя дополнительное значение 31. Это полезно в случаях, когда кодирование элемента нужно начинать до того, как станет известно число элементов массива или отображения или размер строки байтов или текста (возможность начать передачу элемента данных до того, как он станет известен полностью, часто называют потоковой передачей — streaming — внутри этого элемента данных).

Массивы и отображения неопределённого размера обрабатываются иначе, чем строки неопределённого размера.

3.2.1. Код завершения break

Код завершения break представляется базовым типом 7 и дополнительным значением 31 (0b111_11111). Это не элемент данных, а просто синтаксическая функция для завершения элемента с неопределённым размером.

Если код break появляется вместо ожидаемого элемента данных, т. е. не внутри строки, массива или отображения с неопределённым размером (например, с массиве или отображении с заданным размером), вложенный элемент считается некорректно сформированным.

3.2.2. Массивы и отображения неопределённого размера

Массивы и отображения неопределённого размера представляются базовым типом с дополнительным значением 31, за которым следует (возможно пустая) последовательность элементов массива или пар ключ-значение, а затем код завершения break (параграф 3.2.1). Иными словами, массивы и отображения неопределённого размера похожи на остальные массивы и отображения, но начинаются с дополнительного значения 31 и завершаются кодом break.

Если код break указан в отображении после ключа (вместо значения), отображение считается сформированным неверно.

Для вложенности массивов и отображений неопределённого размера не задано ограничений. Код break завершает лишь один элемент, поэтому в конструкции с вложениями число кодов break должно совпадать с числом байтов типа, начинающихся с элемента неопределённого размера (глубиной вложенности).

Предположим, например, что кодер хочет представить абстрактный массив [1, [2, 3], [4, 5]]. Кодирование с определенным размером бедет иметь вид 0x8301820203820405

   83        -- Массив размером 3
      01     -- 1
      82     -- Массив размером 2
         02  -- 2
         03  -- 3
      82     -- Массив размером 2
         04  -- 4
         05  -- 5

Для каждого из 3 массивов этого элемента данных можно применить неопределённый размер, как показано ниже

   0x9f018202039f0405ffff
   9F        -- Начало массива неопределённого размера
      01     -- 1
      82     -- Массив размером 2
         02  -- 2
         03  -- 3
      9F     -- Начало массива неопределённого размера
         04  -- 4
         05  -- 5
         AH  -- break для внутреннего массива
      FF     -- break для внешнего массива

   0x9f01820203820405ff
   9F        -- Начало массива неопределённого размера
      01     -- 1
      82     -- Массив размером 2
         02  -- 2
         03  -- 3
      82     -- Массив размером 2
         04  -- 4
         05  -- 5
      FF     -- break

   0x83018202039f0405ff
   83        -- Массив размером 3
      01     -- 1
      82     -- Массив размером 2
         02  -- 2
         03  -- 3
      9F     -- Начало массива неопределённого размера
         04  -- 4
         05  -- 5
         FF  -- break

   0x83019f0203ff820405
   83        -- Массив размером 3
      01     -- 1
      9F     -- Начало массива неопределённого размера
         02  -- 2
         03  -- 3
         FF  -- "break"
      82     -- Массив размером 2
         04  -- 4
         05  -- 5

Примером отображения неопределённого размера (с двумя парами ключ-значение) может быть

   0xbf6346756ef563416d7421ff
   BF           -- Начало отображения неопределённого размера
      63        -- Первый ключ - строка UTF-8 размером 3
         46756e --   Fun
      F5        -- Первое значение - true
      63        -- Второй ключ - строка UTF-8 размером 3
         416d74 --   Amt
      21        -- Второе значение - -2
      FF        -- break

3.2.3. Байтовые и текстовые строки неопределённого размера

Строки неопределённого размера представляются байтом базового типа для строки байтов или текста с дополнительным значением 31, за которым могут следовать строки указанного типа (chunk — блок) с определенным размером и код завершения break (параграф 3.2.1). Элемент данных, представленный строкой неопределённого размера, является конкатенацией блоков (chunk). Если блоков нет, элемент будет пустой строкой заданного типа. Блоки нулевого размера (пустые) разрешены, но не имеют практического смысла.

Если какой-либо элемент между индикатором строки неопределённого размера (0b010_11111 или 0b011_11111) и кодом break не является строкой того же базового типа с определенным размером, строка считается неверно сформированной.

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

Если какая-либо из строк текста определённого размера внутри строки с неопределённым размером недействительна, строка текста неопределённого размера будет недействительной. Это означает, что байты UTF-8 одного кода Unicode (скаляр) не могут находиться в разных блоках, т. е. блоки текстовых строк должны начинаться на границах кода.

Предположим, например, что кодированная строка имеет вид

   0b010_11111 0b010_00100 0xaabbccdd 0b010_00011 0xeeff99 0b111_11111
   5F              -- Начало строки неопределённого размера
      44           -- Строка из 4 байтов
         aabbccdd  -- Байты содержимого
      43           -- Строка из 3 байтов
         eeff99    -- Байты содержимого
      FF           -- break

После декодирования получается байтовая строка 0xaabbccddeeff99.

3.2.4. Сводка применения неопределённого размера в базовых типах

В таблице 2 приведена сводка базовых типов CBOR с неопределённым размером и дополнительным значением 31.

Таблица 2. Сводка базовых типов CBOR с неопределённым размером (дополнительное значение 31).

 

Базовый тип	Значение	Вложение до кода break
0	(неверный формат)	—
1	(неверный формат)	—
2	Строка байтов	Строки байтов определённого размера
3	Строка текста	Строки текста определённого размера
4	array	Элементы данных (массива)
5	Массив	Элементы данных (пары ключ-значение)
6	(неверный формат)	—
7	Код завершения break	—

 

3.3. Числа с плавающей точкой и значения без содержимого

Базовый тип 7 применяется для двух типов данных — чисел с плавающей точной и простых значений, которым не нужно содержимое. Каждое 5-битовое дополнительное значение в начальном байте имеет свой смысл, указанный в таблице 3. Подобно базовым типам для целых чисел элементы этого базового типа не включают данных содержимого и вся информация заключена в начальных байтах (голова).

Таблица 3. Дополнительные значения для базового типа 7.

 

5-битовое значение	семантика
0..23	Простое значение от 0 до 23.
24	Простое значение от 32 до 255 в следующем байте
25	IEEE 754 Half-Precision Float (следующие 16 битов)
26	IEEE 754 Single-Precision Float (следующие 32 бита)
27	IEEE 754 Double-Precision Float (следующие 64 бита)
28..30	Резерв, в настоящем документе — некорректная форма
31	Код завершение break для элементов неопределённого размера (параграф 3.2.1)

 

Как и для других базовых типов, 5-битовое значение 24 указывает 1-байтовое расширение — байт простого значения (для снижения путаницы применяются лишь значения 32 — 255). Это сохраняет структуру начальных байтов — как для других базовых типов размер всегда определяет дополнительное значение в первом байте. В таблице 4 указаны численные значения выделенные и доступные для простых значений.

Таблица 4. Простые значения.

 

Значение	Семантика
0..19	(не выделено)
20	false — ложь
21	true — истина
22	null — пусто
23	undefined — не определено
24..31	(резерв)
32..255	(не выделено)

 

Кодеру недопустимо вводит 2-байтовые последовательности, начинающиеся с 0xf8 (базовый тип 7, дополнительное значение 24), продолжая их байтом со значением меньше 0x20 (32). Такие последовательности некорректны. Это предполагает, что кодер не может указывать false, true, null или undefined в 2-байтовых последовательностях и корректны для них будут лишь 1-байтовые представления. В общем случае каждое простое значение имеет лишь один вариант представления.

5-битовые значение 25, 26, 27 служат для указания 16-, 32-, и 64-битовых чисел IEEE 754 [IEEE754]. Эти значения с плавающей точкой кодируются в дополнительных байтах соответвующего числа (16-битовые числа floating-point рассмотрены в Приложении D).

3.4. Теги элементов

В CBOR элемент данных может быть сопровождаться тегом для придания дополнительной семантики, однозначно определяемой номером тега. Тег имеет базовый тип 6, его аргумент (раздел 3) указывает номер, а содержимым является один вложенный элемент данных (содержимое тега). Если для содержимого тега нужна дополнительная структура, она указывается вложенным элементом данных. Термин «тег» в этом документе означает весь элемент данных, включая номер и содержимое тега (данные, помеченные тегом).

Предположим, например, что строка из 12 байтов помечена тегом номер 2 для указания того, что это bignum без знака (параграф 3.4.3). Вложенный элемент данных будет начинаться с байта 0b110_00010 (базовый тип 6, дополнительное значение 2 — номер тега), за которым следует содержимое закодированного тега 0b010_01100 (базовый тип 2, дополнительное значение 12 для размера) и 12 байтов bignum.

В расширенной базовой модели данных определение номера тега описывает дополнительную семантику, обеспечиваемую этим номером. Семантика может включать эквивалентность некоторых помеченных элементов данных другим элементам, включая те, которые могут быть представлены в простой базовой модели данных. Например, 0xc24101 — bignum, содержимое тега которого является строкой из одного байта 0x01, эквивалентно целому числу 1, которое можно представить в виде 0x01, 0x1801 или 0x190001. Определение тега может указывать предпочтительную сериализацию (параграф 4.1), рекомендуемую для базовых кодеров, это может обеспечить предпочтение для представлений базовой модели данных по отношению к использующим тег.

Определение тега обычно указывает вложенные данные, которые подходят для тега. Определение может ограничивать содержимое тега конкретной синтаксической структурой, как это сделано для тегов, определённых в этом документе, или может задать содержимое семантически. Примером последнего является восприятие тегами 40 и 1040 разных способов представления массивов [RFC8746].

По соглашению многие теги не принимают значений null или undefined в качестве содержимого, предполагая, что вместо такого тега можно просто использовать null или undefined. В параграфе 3.4.2 дополнительно приведены некоторые соображения для одного конкретного тега по части обработки этого соглашения в прикладных протоколах и отображения на конкретные типы платформ.

От декодера не требуется понимать все номера тегов и теги могут иметь небольшое значение в приложениях, где реализация, создающая конкретный элемент данных CBOR, и реализация, декодирующая этот поток знают семантику каждого элемента в потоке данных. Основной целью тегов в этой спецификации является определение типов данных общего назначения, таких как даты. Другая цель состоит в предоставлении рекомендаций по преобразованию, когда предполагается, что элемент данных CBOR должен транслироваться в другой формат, требующий подсказки о содержимом элементов. Понимание семантики тегов не обязательно для декодера, он может просто представить номер и содержимое тега приложению без интерпретации дополнительной семантики тега.

Тег применяет семантику к вложенному в него элементу данных. Теги могут быть вложенными — если в тег A встроен тег B, который включает элемент данных C, то A применяется к резудьтату применения тега B к элементу данных C.

IANA поддерживает реестр номеров тегов, как указано в параграфе 9.2. В таблице 5 указан список номеров тегов, заданных в [RFC7049], с определениями в оставшейся части этого параграфа. Тег 35 также определён в [RFC7049] и рассмотрен в параграфе 3.4.5.3. Отметим, что после публикации [RFC7049] определено много других тегов и полный список представлен в реестре, описанном в параграфе 9.2.

Таблица 5. Номера тегов, определённые в RFC 7049.

 

Тег	Элемент данных	Семантика
0	Текстовая строка	Стандартная строка даты и времени, см. параграф 3.4.1
1	integer или float	Дата и время на основе эпохи, см. параграф 3.4.2
2	Строка байтов	Bignum без знака, см. параграф 3.4.3
3	Строка байтов	Отрицательное значение bignum, см. параграф 3.4.3
4	Массив	Десятичная дробь, см. параграф 3.4.4
5	Массив	Bigfloat, см. параграф 3.4.4
21	(любой)	Ожидаемое преобразование в base64url, см. параграф 3.4.5.2
22	(любой)	Ожидаемое преобразование в base64, см. параграф 3.4.5.2
23	(любой)	Ожидаемое преобразование в base16, см. параграф 3.4.5.2
24	Строка байтов	Кодированный элемент данных CBOR, см. параграф 3.4.5.1
32	Текстовая строка	URI, см. параграф 3.4.5.3
33	Текстовая строка	base64url, см. параграф 3.4.5.3
34	Текстовая строка	base64, см. параграф 3.4.5.3
36	Текстовая строка	Сообщение MIME, см. параграф 3.4.5.3
55799	(любой)	CBOR с самоописанием, см. параграф 3.4.6

 

Концептуально теги интерпретируются в базовой модели данных, не во время (де)сериализации. Небольшое число тегов (в данный момент 25 и 29 [IANA.cbor-tags]) зарегистрировано с семантикой, которая может требовать обработки при (де)сериализации, декодер должен знать, а кодер — контролировать точную последовательность в которой элементы данных представляются в элементе данных CBOR. Это означает, что такие теги не могут быть реализованы «поверх» базового кодера/декодера CBOR (который может не отражать порядок сериализации для элементов в отображении на уровне модели данных и обратно), поэтому реализацию этих тегов требуется встраивать в базовых кодер/декодер. Определение новых тегов с такими свойствами не рекомендуется.

Агентство IANA выделило номера 65535, 4294967295 и 18446744073709551615 (все 1 в формате с 16, 32 и 64 битами). Их можно применять для удобства разработчиков, которые хотят, чтобы структура данных с одним целым числом указывала наличие или отсутствие конкретного тега. Это назначение описано в разделе 10 [CBOR-TAGS]. Теги не рассчитаны на применение в реальных элементах данных CBOR и реализация может считать их наличие ошибкой.

Протоколы могут расширять базовую модель данных (раздел 2) элементами, представляющими момент времени, используя теги 0 и 1, целыми числами произвольного размера, используя теги 2 и 3, и значениями floating-point произвольного размера, используя теги 4 и 5.

3.4.1. Стандартная строка даты и времени

Тег 0 содержит строку текста в стандартном формате даты и времени, описанном в [RFC3339] и переопределенном в параграфе 3.3 [RFC4287], который представляет момент времени, описываемый здесь. Вложенный элемент иного типа или строка текста, не соответствующая формату [RFC4287], недействительны.

3.4.2. Дата и время на основе эпохи

Тег 1 содержит число секунд с начала эпохи (1970-01-01T00:00Z UTC) для представления гражданского времени.

Содержимое тега должно быть целым числом без знака (базовые типы 0 и 1) или действительным числом (floating-point, базовый тип 7 с дополнительным значением 25, 26 или 27). Иные типы недействительны.

Неотрицательные значения (базовый тип 0 и неотрицательные числа floating-point) указывают время не раньше 1970-01-01T00:00Z UTC и интерпретируются в соответствии с POSIX [TIME_T] (время POSIX называют также временем эпохи UNIX). Високосные секунды обрабатываются в POSIX особо и это приводит к 1-секундным разрывам несколько раз в десятилетие. Отметим, что приложения, которым требуется выражать время после начала 2106 г., не могут исключать поддержку 64-битовых целых чисел для содержимого тега.

Отрицательные значения (базовый тип 1 и отрицательные числа floating-point) интерпретируются в соответствии с требованиями приложения, поскольку нет универсального стандарта отсчёта секунд для UTC до 1970-01-01T00:00Z (это особенно важно для моментов времени, предшествующих разрывам в национальных календарях). Это относится и к неконечным значениям (non-finite).

Для указания долей секунд можно применять вместо целых чисел значения floating-point с тегом 1. Отметим, что это обычно требует поддержки binary64, поскольку binary16 и binary32 обеспечивают отличную от нуля дробную часть секунд лишь для короткого интервала в начале 1970-х. Приложение, которому нужна поддержка тега 1, может ограничивать содержимое тега только целыми значениями (или только floating-point).

Отметим, что типы платформ для даты и времени могут включать значение null или undefined, которые могут также быть желательны на уровне прикладного протокола. Хотя выдача тегов 1 с неконечными значениями содержимого (например, NaN для неопределённых даты и времени или Infinity для незаданной даты завершения срока) может показаться обычным способом решения задачи, использование null или undefined без тега позволяет избежать неконечных значений и сократить кодирование. Разработчикам прикладных протоколов рекомендуется рассмотреть эти ситуации и включить чёткие рекомендации по их обработке.

3.4.3. Большие числа

Протокол использует теги 2 и 3 для расширения базовой модели данных (параграф 2) типом bignum, представляющим целые числа произвольного размера. В базовой модели данных значения bignum не равны целым числам той же модели, а расширенная базовая модель, заданная этим определением тегов, определяет эквивалентность на основе численных значений и предпочтительная сериализация (параграф 4.1) никогда не использует bignum, которые можно выразить базовыми целыми числами (см. ниже).

Bignum кодируются как строка байтов, интерпретируемая как целое число n с сетевым порядком байтов. Включённые элементы иных типов недействительны. Для тега 2 значением bignum будет n, для тега 3 — -1-n. Предпочтительная сериализация строки байтов состоит в исключении начальных нулей (это означает, что для n = 0 предпочтительной сериализацией будет пустая строка байтов, см. ниже). Понимающие эти теги декодеры должны быть способны декодировать bignum с нулями в начале. Предпочтительная сериализация целого числа, которое можно представить базовым типом 0 или 1 состоит в таком кодировании вместо bignum (это означает, что путая строка не будет появляться в bignum при использовании предпочтительной сериализации). Отметим, что это означает, что выбор непредпочтительного представления bignum вместо базового integer при кодировании не предназначен для семантики приложения (как и выбор при более длинного представления базового integer, такого как 0x1800 для 0x00).

Например, число 18446744073709551616 (2⁶⁴) представляется как 0b110_00010 (базовый тип 6, тег номер 2), затем 0b010_01001 (базовый тип 2, размер 9) и 0x010000000000000000 (один байт 0x01 и 8 байтов 0x00). В шестнадцатеричной форме

   C2                        -- тег 2
      49                     -- Строка из 9 байтов
         010000000000000000  -- Содержимое байтов

3.4.4. Десятичные дроби и большие действительные числа

Протоколы, применяющие тег 4, расширяют базовую модель данных элементами, представляющими десятичные дроби произвольного размера в форме m*10^e. Протоколы, применяющие тег 5, расширяют базовую модель данных элементами, представляющими двоичные дроби произвольного размера в форме m*2^e. Как и для bignum, значения разных типов не эквивалентны в базовой модели без расшинения.

Десятичная дробь — это целочисленная мантисса (m) и «масштабный коэффициент» в форме степени числа 10. такие дроби наиболее полезны в приложениях, требующих точного представления десятичной дроби, такой как 1,1, поскольку в двоичном формате с плавающей точкой нет точного представления для многих десятичных дробей.

Bigfloat — это целочисленная мантисса (m) и «масштабный коэффициент» в форме степени числа 2. Это двоичное значение с плавающей точкой, выходящее за пределы диапазона или точности трёх форматов IEEE 754, поддерживаемых CBOR (параграф 3.3). Bigfloat можно также применять в приложениях с ограничениями, где нужна некоторая поддержка действительных чисел без потребности поддерживать IEEE 754.

Десятичные и двоичные дроби представляются как массив с тегом, содержащий два целых числа. — показатель e и мартиссу m. Десятичные дроби (тег 4) используют основание 10 и значением элемента данных является m*10^e. Bigfloat (тег 5) использует основение 2 и имеет значение m*2^e. Показатель e должен представляться как целое число типа 0 или 1, а мантиссой может быть bignum (параграф 3.4.3). Элементы с иной структурой не действтительны.

Примером десятичной дроби может служить представление числа 273,15 как 0b110_00100 (базовый тип 6 с тегом 4), затем 0b100_00010 (базовый тип 4 для массива с дополнительным значением 2 для размера массива), 0b001_00001 (базовый типа 1 для первого целого числа, дополнительное значение 1 для -2), 0b000_11001 (базовый тип 0 для второго целого числа, дополнительное значение 25 для 2 байтов) и 0b0110101010110011 (27315 в двух байтах). В шестнадцатеричном формате это будеи

   C4             -- Тег 4
      82          -- Массив размером 2
         21       -- -2
         19 6ab3  -- 27315

Примером bigfloat может служить представление числа 1,5 как 0b110_00101 (базовый тип 6 для тега и номер тега 5), хатем 0b100_00010 (базовый тип 4 для массива и дополнительное значение 2 для размера), 0b001_00000 (базовый тип 1 для первого целого числа и дополнительное значение 0 для числа -1) и 0b000_00011 (базовый тип 0 для второго целого числа и дополнительное значение 3 для числа 3). Шестнадцатеричное представление имеет вид

   C5             -- Тег 5
      82          -- Массив размером 2
         20       -- -1
         03       -- 3

Десятичные дроби и bigfloat не обеспечивают представление Infinity, -Infinity, NaN. Если они нужны, можно применять взамен представление IEEE 754 с половинной точностью, как описано в параграфе 3.3.

3.4.5. Подсказки содержимого

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

3.4.5.1. Закодированный элемент данных CBOR

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

3.4.5.2. Ожидаемое последующее кодирование для преобразования CBOR в JSON

Теги 21 — 23 указывают, что строка байтов может требовать конкретного кодирования при взаимодействии с основанным на тексте представлением. Эти теги полезны, когда кодер знает, что записываемая строка байтов позднее будет преобразовываться для определённого использования на основе JSON. Такое использование указывает, что некоторые строки закодированы как base64, base64url и т. п. Кодер применяет строки байтов вместо выполнения самого кодирования с целью снизить размер кода, самого кодера или обоих. Кодер не знает, будет ли преобразователь базовым и поэтому хочет сказать, что он надеется на корректное преобразование двоичных строк в JSON.

Помеченный элемент данных может быть строкой байтов или иным элементом данных. В последнем случае тег применяется ко всем элементам данных строки байтов, содержащимся в элементе данных, за исключением тех, которые находятся во вложенном элементе, помеченном ожидаемым преобразованием.

Эти три тега предполагают преобразование в три базовых варианта кодирования, определённые с [RFC4648]. Тег 21 предполагает преобразование в base64url (раздел 5 в [RFC4648]) без заполнения (см. параграф 3.2 в [RFC4648]), т. е. все завершающие символы = (равенство) удаляются из кодированной строки. Тег 22 предполагает преобразование в классический код base64 (раздел 4 в [RFC4648]) с заполнением в соответствии с RFC 4648. Для base64url и base64 используются биты заполнения 0 (см. параграф 3.5 в [RFC4648]) и выполняется преобразование для дополнительного кодирования над содержимым строки байтов (т. е. без добавления символов завершения строки, пробелов и других дополнительных символов). Тег 23 предполагает преобразование в base16 (hex) с заглавными буквами (см. раздел 8 в [RFC4648]). Отметим, что для всех тегов кодирование пустой строки байтов даёт пустую строку текста.

3.4.5.3. Кодированный текст

Некоторые строки текста содержат данные в форматах, широко применяемых в Internet, а иногда декодер может проверить эти форматы и представить приложению в подходящей форме. Для части форматов имеются теги.

• Тег 32 применяется для URI, определённых в [RFC3986]. Если строка текста не соответствует URI-reference, она будет недействительной.

• Теги 33 и 34 служат для текста, закодированного в base64url или base64, соответственно, как задано в [RFC4648]. Строки, соответствующие любому из приведённых ниже условий, являются недействительными:

  • строка кодированного текста содержит неалфавитные символы или только 1 алфавитный символ в последнем из 4 блоков (алфавит определён в разделе 5 [RFC4648] для тега 33 и в разделе 4 [RFC4648] для тега 34);

  • биты заполнения в 2-х или 3-символьном блоке отличны от 0;

  • кодирование base64 имеет некорректное число символов заполнения;

  • кодирование base64url включает символы заполнения.

• Тег 36 служит для сообщений MIME (включая все заголовки), определённых в [RFC2045]. Строка текста, не являющаяся корректным сообщением MIME, будет недействительна. Для этого тега проверка корректности может быть особенно обременительной для базовых декодеров и по этой причине может не предоставляться. Отметим, что многие сообщения MIME представляют собой обычные двоичные данные и поэтому не могут быть представлены текстовыми строками. В [IANA.cbor-tags] представлена регистрация тега 257, похожего на тег 36, но использующего в качестве содержимого строку байтов.

Отметим, что теги 33 и 34 отличаются от тегов 21 и 22 тем, что данные передаются первыми в форме base-кода, а вторыми — в raw-строк байтов.

В [RFC7049] определён тег 35 для регулярных выражений Perl в форме PCRE/PCRE2 (Perl Compatible Regular Expression) [PCRE] или JavaScript [ECMA262]. Методы регулярных выражений с момента публикации документов были усовершенствованы и данная спецификация не пытается обновить ссылки. Тег остаётся доступным (как зарегистрировано в [RFC7049]) для приложений, которые задают конкретный вариант регулярного выражения (возможно с ограничением определенным подмножеством PCRE и ECMA262). Поскольку эта спецификация уточняет пригодность тегов сверх [RFC7049], отмечается, что в результате открытого способа определения тега в [RFC7049], любая содержащаяся в нем строка должна быть действительной на уровне тега CBOR (но это может не совпадать с ожиданием прикладного уровня).

3.4.6. Самоописание CBOR

Во многих приложениях из контекста понятно применение CBOR для кодирования элементов данных. Например, конкретный протокол может указывать использование CBOR или для типа носителя указано такое применение. Однако возможны приложения, где такой контекстной информации нет, например, при хранении данных CBOR в файле без метаданных, устраняющих неоднозначность. Здесь может помочь наличие отличительных признаков в самих данных.

Для этого определён тег 55799, применяемый, в частности, в начале сохраняемых данных в коде CBOR, как указано приложением. Это не задаёт особой семантики элемента данных, т. е. семантика содержимого тега с номером 55799 является семантикой самого содержимого.

Сериализация головы тега будет иметь вид 0xd9d9f7, что, похоже, не служит отличительным признаком для каких-либо часто используемых файлов. В частности, 0xd9d9f7 не является дозволенным началом текста Unicode в какой-либо кодировке Unicode, если за ним следует действительный элемент данных CBOR.

Например, декодер может быть способен декодировать как CBOR, так и JSON. Такому декодеру нужно различать два этих формата. Простым способом помочь этому со стороны кодера было бы указание всего элемента CBOR с тегом 55799, сериализация которого никогда не будет присутствовать в тексте JSON.

4. Вопросы сериализации

4.1. Предпочтительная сериализация

На уровне модели для некоторых значений CBOR представляет несколько вариантов сериализации. Во многих приложениях желательно, чтобы кодер всегда выбирал предпочтительную сериализацию (кодирование), однако данная спецификация не требует этого ни от кодера, ни от декодера.

Некоторые декодеры с ограничениями могут быть ограничены в способности декодировать отличную от предпочтительной сериализацию, например, если приложение ожидает лишь целые цисла, не превышающие 1 миллард (1 000 000 000), декодер может не включать кода, требуемого для 64-битовых целочисленных аргументов. Кодер, который должен всегда применять предпочтительную сериализацию (кодер с предпочтением), будет совместим с таким декодером для чисел, встречающихся в приложении. Вообще говоря, кодер с предпочтениями более универсален в части взаимодействия (и менее расточителен), нежели кодер, который всегда применяет, скажем, 64-битовые целые числа.

Точно так же кодер с ограничениями может быть ограничен в выборе поддерживаемых вариантов представления и не сможет выдавать предпочтительную сериализацию (кодер варианта). Например, кодер с ограничениями может быть спроектирован так, что всегда применяется 32-битовый вариант кодирования целых чисел даже при доступности более короткого представления (в предположении отсутствия потребности в 64-битовом представлении). Декодер, который не полагается на приём лишь предпочтительной сериализации (устойчивый к вариантам декодер) целых чисел можно считать более универсальным по части совместимости (хотя он может быть оптимизирован для получения предпочтительной сериализации). Полные реализации декодеров CBOR по определению устойчивы к вариациям и различие важно лишь в случае взаимодействия ограниченной реализации декодера CBOR с кодером варианта.

Предпочтительная сериализация всегда использует кратчайшую форму представления аргумента (раздел 3), а также кратчайшее кодирование floating-point, сохраняющее кодируемое значение.

Предпочтительной сериализацией действительного числа (floating-point) является кратчайшее кодирование floating-point, сохраняющее значение числа, например, 0xf94580 для числа 5,5 и 0xfa45ad9c00 для 5555,5. Для зачений NaN предпочтительно более короткое кодирование, если дополнение нулями со сдвигом вправо восстанавливает исходное значение NaN (для многих приложений достаточно одного кодирования NaN — 0xf97e00).

Кодирование с определенным размером предпочтительно, когда размер известен при старте сериализации элемента.

4.2. Детерминированное кодирование CBOR

Некоторым протоколам могут потребоваться кодеры, которые выдают CBOR только в детерминированном формате, эти протоколы могут также иметь декодеры, проверяющие входной формат на предмет соответствия заданному. Такие протоколы могут сами определять, что они считают «определенным форматом» и что они ждут от кодеров и декодеров В этом разделе задан набор ограничений, которые могут служить базой для определённого формата.

4.2.1. Базовые требования детерминированного кодирования

Кодирование CBOR удовлетворяет «базовым требованиям детерминированного кодирования» при выполнении перечисленных ниже условий.

• Должна применяться предпочтительная сериализация. В частности, это означает, что аргументы (раздел 3) для целых чисел, размеры базовых типов 2 — 5 и теги должны быть максимально короткими, например:

  • значения от 0 до 23 и от -1 до -24 должны выражаться в одном байте с базовым типом;

  • значения от 24 до 255 и от -25 до -256 должны выражаться только дополнительным полем uint8_t;

  • значения от 256 до 65535 и от -257 до -65536 должны выражаться только дополнительным полем uint16_t;

  • значения от 65536 до 4294967295 и от -65537 до -4294967296 должны выражаться только дополнительным полем uint32_t.

  Значения с плавающей точкой тоже должны использовать кратчайшую форму, сохраняющую значение, например 1,5 кодируется как 0xf93e00 (binary16), а 1000000.5 — как 0xfa49742408 (binary32). Одна из реализаций этого заключается в использовании сначала 64-битового формата, а затем тестового преобразования в 32-битовый и при совпадении значений — тестового преобразования в 16-битовый формат. Это также работает для 16-битовых чисел с плавающей точкой для положительных и отрицательных значений Infinity.

• Значения неопределённого размера недопустимо, но их можно кодировать элементами определённого размера.

• Ключи каждого отображения должны сортироваться в побайтовом лексикографическом порядке их детерминированных кодировок, ниже приведён пример корректной сортировки.

1. 1. 10, закодированный как 0x0a;

   2. 100, закодированный как 0x1864;

   3. -1, закодированный как 0x20;

   4. «z», закодированный как 0x617a;

   5. «aa», закодированный как 0x626161;

   6. [100], закодированный как 0x811864;

   7. [-1], закодированный как 0x8120;

   8. false, закодированный как 0xf4.

Примечание для разработчиков. Саморазграничение кодировок CBOR означает, что не может двух корректно сформированных кодированный элементов данных CBOR, из которых один является префиксом другого. Таким образом, побитовое лексикографическое сравнение детерминированных кодировок разных ключей отображения всегда находит различие между ключами до того, как будет достигнут конец любого из сравниваемых ключей.

4.2.2. Дополнительные вопросы детерминированного кодирования

Теги CBOR представляют дополнительные соображения по части детерминированного кодирования. Если протокол на основе CBOR обеспечивает одинаковую семантику независимо от наличия или отсутствия конкретного тега (например, разрешая элементы данных с тегом 1 и необработанные (raw) числа для даты и времени, трактуя последние как при наличии тега), детерминированный формат не допустит наличия тега из-за принципа использования кратчайшей формы. Например, протокол может предоставлять кодеру выбор представления URL в форме строки текста или с помощью тега 32 (параграф 3.4.5.3), содержащего строку текста. Детерминированное кодирование этого протокола должно требовать наличия или отсутствия тега, не допуская выбора.

В протоколе, требующем теги в некоторых местах для обеспечения конкретной семантики, теги должны присутствовать в детерминированном формате. Требования к детерминированному кодированию относятся и к содержимому тегов.

Если протокол включает поле, которое может содержать целое число со значением 2⁶⁴ или больше с использованием тега 2 или 3 (параграф 3.4.3), детерминированное кодирование протокола должно указывать, выражаются ли меньшие числа с использованием тех же тегов или могут использовать базовые типы 0 и 1. Предпочтительная сериализация применяет последний вариант и поэтому рекомендуется.

Протоколы, включающие действительные (floating-point) значения, независимо от применения базовых значений floating-point (параграф 3.3) или тегов, могут требовать задания дополнительных требования к детерминированному кодирования, как показано ниже.

• Хотя значения IEEE floating-point могут представлять положительные и отрицательные значения, приложение может не разделять их и может представлять значение, содержащее только 0, как положительное, запрещаю «отрицательный 0». Приложение может также ограничивать точность floating-point, чтобы никогда не применялись 64-битовые или даже 32-битовые значения с плавающей точкой.

• Если протокол включает поля, которые могут выражать значения floating-point, с конкретной моделью данных, заявляющей целые и действительные числа невзаимозаменяемыми, детерминированное кодирование протокола должно указывать, например, что число 1,0 кодируется как 0x01 (целое без знака), 0xf93c00 (binary16), 0xfa3f800000 (binary32), or 0xfb3ff0000000000000 (binary64). Примерные варианты даны ниже.

• 1. Кодировать целые числа, требующие 64 бита базовыми типами 0 или 1, а иные значения в соответствии с предпочтительным форматом floating-point, сохраняющим точность (меньшее из 16, 32 или 64 битов).

• • 1. Кодировать все значения с предпочтительным представлением floating-point, сохраняющим точность, даже для целых чисел.

    2. Кодировать все значения в 64-битовом представлении с плавающей точкой.

Правило 1 ставит границу между целочисленными и действительными значениями, в правило 3 не применяет предпочтительную сериализацию, поэтому во многих случаях лучше применять правило 2.

• Если разрешены значения NaN и нет намерений поддерживать NaN в данных (payload) или сигнализации, протокол должен указать обно представление (обычно 0xf97e00). Если этот простой вариант не приемлем, нужно обратить особое внимание на обработку NaN.

• Субнормальные числа (ненулевые значения с минимальным показателем для данного формата IEEE 754) могут отсекаться на выходе до 0 или трактоваться как 0 в некоторых реализациях floating-point. Детерминированное кодирование протокола может специально приспособить такие реализации, перенося нагрузку на другие реализации, исключая субнормальные числа из обмена и используя вместо них 0.

• Одно и то же число можно представить разными десятичными дробями, двоичными дробями (bigfloat) и иными формами с тегами, которые могут быть определены для числовых значений. В зависимости от реализации не всегда практично задавать, какие из этих форм (или форм базовой модели данных) эквивалентны. Прикладной протокол, предоставляющий выбор варианта представления чисел, должен явно указывать, как это делается для детерминированного формата.

4.2.3. Упорядочение ключей сначала по размеру

Базовые требования детерминированного кодирования (параграф 4.2.1) задают сортировку ключей в порядке, отличающемся от заданного в параграфе 3.9 [RFC7049] (здесь он называется каноническим — Canonical CBOR). Протоколы, которым нужна совместимость с [RFC7049], могут задать в терминах этой спецификации сортировку сначала по размеру ключа (length-first core deterministic encoding requirements). В этом случае должны выполняться приведённые ниже правила.

1. Из двух ключей разного размера первым считается более короткий.

2. Из двух ключей одного размера первым считается тот, у которого меньше побайтовое лексикографическое значение.

Например, в соответствии с этими требованиями ключи будут сортироваться в приведённом ниже порядке.

1. 10, закодированный как 0x0a;

2. -1, закодированный как 0x20;

3. false, закодированный как 0xf4;

4. 100, закодированный как 0x1864;

5. «z», закодированный как 0x617a;

6. [-1], закодированный как 0x8120;

7. «aa», закодированный как 0x626161;

8. [100], закодированный как 0x811864.

Хотя в [RFC7049] применяется термин Canonical CBOR для указания требований к детерминированному кодированию, данный документ избегает этого, поскольку «канонизация» часто ассоциируется только с конкретным применением детерминированного кодирования. Однако термины по существу взаимозаменяемы и набор базовых требований этого документа также можно назвать «каноническим CBOR», а вариант с сортировкой сначала по размеру — Old Canonical CBOR.

5. Создание протоколов на основе CBOR

Такие форматы данных как CBOR часто применяются в средах без согласования формата. Одной из целей CBOR является исключение потребности в какой-либо включённой или предполагаемой схеме — декодер может взять элемент CBOR и декодировать его без дополнительных сведений.

В практических реализациях конечно требуется, чтобы кодер и декодер имели общее представление об элементах данных CBOR. Например, согласованным форматом может быть «элемент — это массив, где первым значением является строка UTF-8, вторым — целое число, а последующие элементы могут содержать значения floating-point» или «элемент — это отображение с байтовыми строками для ключей и парой с ключом 0xab01».

Протоколы на основе CBOR должны задавать, как их декодеры обрабатывают недействительные или неожиданные данные. Протокол на основе CBOR может задавать трактовку произвольных действительных данных как неожиданных. Кодеры протоколов на основе CBOR должны создавать только действительные элементы, т. е. протокол не может использовать недействительные элементы. Кодер может быть способен кодировать столько типов значений, сколько требуется протоколу, где кодер применяется. Декодер может быть способен понимать столько типов значений, сколько требуется применяющему его протоколу. Такое отсутствие ограничений позволяет применять CBOR в разных средах.

В остальной части этого раздела рассматриваются некоторые вопросы создания протоколов на основе CBOR. За некоторыми исключениями, это будут лишь рекомендации и явно исключаются уровни требований BCP 14 [RFC2119] [RFC8174], кроме уровня можно, интерпретируемого в соответствии с BCP 14. Исключения нацелены на облегчение совместимости протоколов на основе CBOR с использованием широкого спектра базовых и зависимых от приложений кодеров и декодеров.

5.1. CBOR в потоковых приложениях

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

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

5.2. Базовые кодеры и декодеры

Базовый декодер CBOR может декодировать и представлять приложению все корректно сформированные элементы данных CBOR (см. Приложение C). для представления корректно сформированных значений CBOR человеку можно применять диагностическую нотацию (раздел 8).

Базовый кодер CBOR предоставляет приложению интерфейс, позволяющий указать для кодирования в элемент данных CBOR любое корректно сформированное значение, включая простые значения и теги, неизвестные кодеру.

Хотя CBOR пытается минимизировать случаи недействительности корректно сформированных данных CBOR, он возможны. Например, кодированная строка текста «0x62c0ae» не содержит пригодного UTF-8 (поскольку [RFC3629] требует использовать кратчайшую форму) и поэтому не является действительным элементом CBOR. Кроме того, конкретные теги могут вносить семантические ограничения, которые могут нарушаться, например, тег bignum, включающий другой тег, или экземпляр тега 0 со строкой байтов или текста, не соответствующей дате и времени [RFC3339]. От базовых кодеров и декодеров не требуется делать неестественный выбор для своих приложений с целью обработки недействительных данных. Предполагается, что базовые кодеры и декодеры пересылают простые значения и теги, даже если их конкретные коды не были зарегистрированы на момент создания кодера или декодера (параграф 5.4).

5.3. Пригодность элементов

Корректно сформированный, но недействительный элемент данных CBOR (параграф 1.2) создаёт проблему при интерпретации данных, закодированных в модели данных CBOR. Протокол на основе CBOR может включать несколько уровней и нижние уровни не смогут обработать семантику некоторых пересылаемых данных CBOR. Эти уровни не могут проверить пригодность данных, которые они обрабатывают, и должны пересылать их как есть. Первый уровень, обрабатывающий семантику непригодного элемента CBOR должен выбрать один из двух вариантов:

1. заменить проблемный элемент маркером ошибки и продолжить обработку следующего элемента;

2. выдать ошибку и прекратить обработку.

Протокол на основе CBOR должен указать какой из этих вариантов его декодеры выбирают для каждого встречающегося непригодного элемента. Отмеченная проблемы могут возникать на базовом уровне проверки пригодности CBOR или в контексте тегов (пригодность тега).

5.3.1. Базовая пригодность

На уровне базовой модели данных возможны две ошибки пригодности.

Дубликаты ключей в отображении

Базовые декодеры (параграф 5.2) делают данные доступными для приложений на основе естественной модели данных CBOR. Эта модель включает отображения (пары ключ-значение с уникальными ключами), но не множественные отображения (multimap, гда одному ключу может соответствовать несколько записей). Таким образом, базовый декодер, получающий элемент отображения CBOR с дубликатом ключа будет декодировать лишь один экземпляр и прекращать дальнейшую обработку. Кроме того, «потоковый декодер» может не заметить дубликата. Более подробное рассмотрение ключей отображений приведено в параграфе 5.6.

Неприголные строки UTF-8

Декодер может проверять или не проверять фактическую допустимость байтов в строке UTF-8 (базовый тип 3) с точки зрения корректности UTF-8 и в любом случае соответствующим образом реагировать.

5.3.2. Пригодность тегов

Два дополнительных типа ошибок пригодности связаны с добавлением тегов в базовую модель данных.

Недопустимое для типа тега содержимое

Номера тегов (параграф 3.4) указывают тип элемента данных, служащего содержимым тега, например, теги для беззнаковых или отрицательных bignum предполагают битовые строки. Декодер преобразует помеченный элемент данных в естественное представление (в данном случае естественное большое число) и от него ожидается проверка типа данных в теге. Даже декодеры, не имеющие в своей среде доступного представления, могут проверять известные им теги и реагировать должным образом.

Недопустимое для типа тега значение

Для элемента данных с тегом пригодный тип может содержать недействительное значение, например, «yesterday» не подходит в качестве содержимого тега 0, хотя и является корректной строкой текста. Декодер, который обычно преобразует такие значения в подходящий для платформы эквивалент, может представить тег приложению так же, как он представил бы тег с неизвестным номером (параграф 5.4).

5.4. Пригодность и развитие

Декодер с проверкой пригодности затрачивает усилия для надёжного обнаружения элементов данных с ошибками пригодности. Например, такому декодеру нужно иметь API для уведомления об ошибках (без возврата данных) для элементов CBOR, содержащих любую из указанных выше ошибок пригодности.

Набор тегов из реестра Concise Binary Object Representation (CBOR) Tags (параграф 9.2), а также простых значений из реестра Concise Binary Object Representation (CBOR) Simple Values (параграф 9.1) может быть расширен в любой момент так, что базовый декодер не будет знать новых значений. Декодер с проверкой пригодности в таких случаях может выбрать один из указанных ниже вариантов.

• Сообщить об ошибке (не возвращая данных). Отметим, что это может приводить к «окостенению» и по этой причине не рекомендуется. Такая ошибка сама по себе не является ошибкой пригодности и скорей всего выдаётся декодером, выполняющим проверку пригодности из-за неизвестного тега или простого значения.

• Передать неизвестный элемент (тип, значение, а для тегов и декодированный элемент) вызвавшему декодер приложению, а затем указать ему, что тег или простое значение не распознаны.

Во втором варианте, подходящем и для декодеров без проверки пригодности, обеспечивается совместимость с новыми тегами и простыми значениями без необходимости обновлять кодер вместе с вызывающим приложением. Для этого API декодера должен быть способен помечать неизвестные элементы, чтобы вызывающее приложение могло обработать их в соответствии с потребностями программы.

Поскольку обработка при проверке пригодности может быть связана со значительными издержками (в частности для обнаружения дубликатов в отображениях), поддержка проверки пригодности не требуется во всех декодерах CBOR.

Некоторые кодеры могут полагаться на свои приложения для предоставления входных данных так, чтобы кодер выдавал действительные результаты CBOR. Базовый кодер может также обеспечивать режим проверки пригодности, в котором он надёжно ограничивает свой вывод лишь действительными элементами CBOR, независимо от представления приложением совместимых с API данных.

5.5. Числа

Протоколам на основе CBOR следует учитывать, что разные языковые среды вносят разные ограничения на диапазоны и точность представляемых чисел. Например, базовая система счисления JavaScript считает все числа действительными (floating-point), что может вести к скрытой потере точности для целых чисел с числом значащих битов более 53. Поскольку CBOR сохраняет бит знака для своего представления целых чисел в базовом типе, имеется ещё один бит для чисел со знаком определённого размера (например, -2⁶⁴..2⁶⁴-1 для 1+8-байтовых целых чисел) по сравнению с обычным для платформы представлением целых чисел со знаком и таким же размером (-2⁶³..2⁶³-1 для 8-битового int64_t). Протоколу, использующему числа, следует указывать свои ожидания в части обработки нетривиальных чисел в декодерах и принимающих приложениях.

Протоколы на основе CBOR, использующие действительные числа могут ограничивать набор поддерживаемых форматов (половинная, одинарная и двойная точность). Для приложений, применяющих лишь целые числа, протокол может полностью исключить значения floating-point.

Протоколы CBOR, предназначенные для обеспечения компактности, могут исключать определённые варианты кодирования целых чисел, которые не нужны для приложений, например, требующие 64-битовых форматов. Предполагается, что кодеры будут использовать наиболее компактное представление целых чисел, подходящее для данного значения. Однако компактным приложениям, не требующим детерминированного кодирования, следует воспринимать значения, использующие представление с размером больше необходимого (например, представление 0 в виде 0b000_11001 с двухбайтовым значением 0x00), если приложение может декодировать целое число такого размера. Подобные соображения применимы и для действительных чисел — рекомендуется декодировать как предпочтительную сериализацию, так и более длинные форматы.

Протоколы на основе CBOR для приложений с ограничениями, которые предоставляют выбор между представлением данного значения целым числом, десятичной или двоичной (bigfloat) дробью (например, когда показатель мал и неотрицателен), могут выражать ожидание реализации, где целые числа представляются напрямую.

5.6. Задание ключей для отображений

Приложения кодирования и декодирования должны согласовывать типы ключей, используемых в отображениях. В приложениях, которым нужно взаимодействовать с приложениями на основе JSON преобразование упрощается применением лишь ключей в форме строк текста, в противном случае потребуется конкретное отображение других типов CBOR в строки текста, а это часто ведёт к ошибкам реализации. В приложениях, где ключи числовые по своей природе, полезно напрямую применять численные ключи.

Если требуется несколько типов ключей, следует рассмотреть применение этих типов в конкретных программных средах, которые будут использоваться. Например, в JavaScript Maps [ECMA262], целочисленный ключ 1 не отличить от ключа 1,0 (floating-point). Это значит, что при использовании целочисленных ключей протоколу потребуется избегать ключей floating-point со значениями, совпадающими с имеющимися в отображении целочисленными ключами.

Декодеры, доставляющие элементы данных, вложенные в элемент данных CBOR, сразу после их декодирования (потоковые декодеры). зачастую не сохраняют состояние, требуемое для проверки уникальности ключа в отображении. Точно так же кодер, который может начинать кодирование элемента данных до полной доступности вложенного элемента (потоковый кодер), может снижать свои издержки, полагаясь в плане уникальности ключей на источник.

Протоколы на основе CBOR должны указывать, что делать, когда принимающее приложение видит в отображении совпадающие ключи. Результирующее правило в протоколе должно соответствовать модели данных CBOR, оно не может предписывать конкретную обработку записей с одинаковыми ключами, за исключением возможности иметь правило, по которому наличие идентичных ключей указывает некорректную форму отображения и позволяет декодеру остановить обработку с возвратом ошибки. При обработке отображений, содержащих записи с одинаковыми ключами, базовый декодер может выбрать один из указанных ниже вариантов.

• Не отвергать отображения с дубликатами ключей (считать их пригодными, см. параграф 5.4). Такие базовые декодеры полезны. Приложение может быть заинтересовано в выполнении своей проверки правил применимости (например, если оно считает эквивалентными целые и действительные значения ключей для конкретных отображений).

• Передавать приложению все записи отображения, включая дубликаты ключей. Это требует от приложения обработки (проверки) дубликатов, даже если правила приложения идентичны правилам базовой модели.

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

Базовые декодеры должны указывать в документации используемый подход из числа перечисленных выше.

Модель данных CBOR для отображений не позволяет приписать семантику порядку пар ключ-значение в представлении отображения. Поэтому основанному на CBOR протоколу недопустимо задавать изменение семантики при смене порядка пар ключ-значение за исключением запрета некоторых вариантов порядка, например, при нарушении правил детерминированного кодирования (параграф 4.2). Вторичные эффекты упорядочения отображений, такие как синхронизация, использование кэша и другие возможные побочные влияния не считаются частью семантики, но могут служить достаточным основанием для того, чтобы протокол требовал детерминированного кодирования.

Приложениям для устройств с ограничениями следует рассмотреть применение небольших целых чисел в качестве часто используемых ключей, например, набор из 24 (или меньше) ключей можно закодировать одним байтов как целое число без знака, а использование отрицательных значений позволяет расширить набор до 48 ключей. Для более редко применяемых ключей можно использовать целые числа большего размера.

5.6.1. Эквивалентность ключей

Для определения дубликатов ключей отображения служит конкретная модель данных, применяемая к элементу CBOR.

В базовой модели данных целые и действительные числа с одним значением считаются разными, поскольку они происходят от разных больших чисел (теги 2 — 5). Точно так же строки текста отличаются от строк байтов, даже если они содержат одинаковые байты. Значение с тегом отличается от значения без тега или значения с иным тегом.

В каждой из этих групп численные значения различаются, если они не совпадают по величине (в частности, -0,0 = 0,0) при определении дубликатов ключей в отображении. Значения NaN эквивалентны, если они имеют одинаковые значения обеих частей после их дополнения справа нулями до 64 битов.

Строки байтов и текста сравниваются побайтно, а массивы — поэлементно и считаются равными, если имеют одинаковое число байтов или элементов и одинаковые значения в тех же позициях. Отображения являются равными, если они имеют одинаковые наборы пар независимо от их упорядочения, пары считаются равными при совпадении ключа и значения в них.

Значения с тегами равны, если совпадают номера и содержимое тегов. Отметим, что базовый декодер, обрабатывающий конкретный тег, может не различать некотрые семантически эквивалентные значения, например, нули слева в содержимом с тегом 2 или 3 (параграф 3.4.3). Простые значения равны при их совпадении. В базовой модели данных нет ничего равного, простое значение 2 не эквивалентно целочисленному значению 2, а массив никогда не эквивалентен отображению.

Как обсуждалось в параграфе 2.2, конкретная модель данных может считать при сравнении ключей эквивалентными значения, которые различаются в базовой модели данных. Отметим, что это предполагает, что базовый декодер может достаить приложению декодированное отображение, которое приложение должно проверить на предмет дубликатов ключей (декодер может также предоставить приложению программный интерфейс для выполнения этой задачи). Конкретные модели данных не будут различать в отображении ключи, одинаковые на уровне базовой модели данных.

5.7. Неопределённые значения

В некоторых протоколах на основе CBOR простое значение undefined (параграф 3.3) может применяться кодером для подстановки вместо вызывающих проблему элементов данных, чтобы закодировать остальные элементы без вреда.

6. Преобразование данных между CBOR и JSON

В этом разделе приведены ненормативные советы по преобразованию между CBOR JSON. Реализации конвертеров могут применять эти рекомендации по своему усмотрению. Следует отметить, что текст JSON является последовательностью символов, а не байтов, как в CBOR.

6.1. Преобразование CBOR в JSON

Большинство типов CBOR имеет прямые аналоги в JSON. Однако аналоги есть не всегда и при внедрении конвертеров CBOR в JSON следует учитывать это. Ниже приведены ненормативные рекомендации по предобразованию в одно подстановочное значение, такое как JSON null.

• Целые числа (базовые типы 0 и 1) становятся числами JSON.

• Строка байтов (базовый тип 2), не встроенная в тег, задающий предлагаемое кодирование, преобразуется в base64url без дополнение и становится строкой JSON.

• Строка UTF-8 (базовый тип 3) становится строкой JSON. Отметим, что JSON требует экранирования некоторых символов (раздел 7 в [RFC8259]): кавычки (U+0022), обратная дробная черта (U+005C) и символы управления C0 (U+0000 — U+001F). Остальные символы копируются в строку JSON UTF-8 без изменений.

• Массив (базовый тип 4) становится массивом JSON.

• Отображение (базовый тип 5) становится объектом JSON. Это можно сделать напрямую лишь при использовании в качестве ключей строк UTF-8. Конвертер может преобразовать другие ключи в строки UTF-8 (например, целые числа в десятично представление), однако это создаёт риск дублирования ключей. Отметим, что при игнорировании тегов в строках UTF-8 (см. ниже) могут возникать конфликты ключей.

• False (базовый тип 7, дополнительное значение 20) становится JSON false.

• True (базовый тип 7, дополнительное значение 21) становится JSON true.

• Null (базовый тип 7, дополнительное значение 22) становится JSON null.

• Действительное (floating-point) значение (базовый тип 7, дополнительное значение 25 — 27) становится числом JSON, если оно конечно (т. е. представимо числом JSON), а неконечные значения (NaN, положительные и отрицательные Infinity) заменяются подстановочным значением.

• Любое другое простое значение (базовый тип 7, любое дополнительное значение не указанное выше) представляется символом подстановки.

• Большое число (bignum, базовый тип 6, тег 2 или 3) представляется кодированием его строки байтов в base64url без дополнения и становится строкой JSON. Для тега 3 (отрицательное bignum) перед base-кодированным значением помещается символ тильды ~ (преобразование в binary blob вместо числа для предотвращения возможно переполнения в декодере JSON).

• Строка байтов с рекомендацией по кодированию (базовый тип 6, теги 21 — 23) кодируется, как указано в рекомендации, и становится строкой JSON.

• Для всех других тегов (базовый тип 6, любой тег) содержимое тега представляется как значение JSON. А номер тега игнорируется.

• Элементы неопределённого размера до преобразования конвертируются в конкретный размер.

Преобразователь CBOR в JSON может сохранить профиль JSON (I-JSON) [RFC7493] для максимальной совместимости и повышения уверенности в том, что выход JSON можно обработать с предсказуемым результатом. Например, есть влияние на диапазон целых чисел, которые можно представить надёжно, а также на элементы верхнего уровня, которые могут поддерживаться старыми реализациями JSON.

6.2. Преобразование JSON в CBOR

Все значения JSON, будучи закодированными, напрямую отображаются в одно или несколько значений CBOR. Как и при любой генерации CBOR нужно принимать решение относительно представления чисел, как отмечено ниже.

• Числа JSON без дробной части (целые) представляются целыми числами (базовые типы 0 и 1, возможен тип 6, теги 2 и 3) с выбором кратчайшей формы. Числа, длиннее заданного реализацией порога могут представляться действительными (floating-point) значениями. По умолчанию принят диапазон представления от -2⁵³+1 до 2⁵³-1 (полный диапазон целых чисел в представлении binary64, часто применяемом для декодирования JSON [RFC7493]). Протокол на основе CBOR или базовая реализация конвертера может выбрать диапазон -2³²..2³²-1 или -2⁶⁴..2⁶⁴-1 (полное использование диапазона целых чисел, доступных в CBOR с uint32_t и uint64_t, соответственно) и даже -2³¹..2³¹-1 или -2⁶³..2⁶³-1 (популярные диапазоны целых чисел со знаком и дополнением до 2). Если представление JSON создано реализацией JavaScript, точность уже ограничена значением не более 53 битов.

• Числа с дробной частью представляются действительными (floating-point) значениями с преобразованием двоичных значений в десятичные с точностью, обеспечиваемой форматом IEEE 754 binary64. Математическое значение числа JSON преобразуется в binary64 с использованием процедуры roundTiesToEven из параграфа 4.3.1 в [IEEE754]. Затем при кодировании CBOR применяется предпочтительная сериализация в кратчайшее представления floating-point с сохранением значения, например, число 1,5 преобразуется в 16-битовое значение floating-point (не все реализации способны эффективно определять кратчайшую форму). Вместо принятой по умолчанию точности binary64 может применяться заданная реализацией точность преобразования, влияющая на результат. Десятичные представления следует применять на стороне CBOR лишь при указании этого в протоколе.

Формат CBOR был разработан для обеспечения в общем случае более компактного представления, чем JSON. Одной из возможных стратегий реализации преобразования JSON в CBOR является кодирование на месте в одном буфере. В этом случае нужно внимательно рассмотреть множество патологических случаев, таких как преобразование некоторых строк без экранирования или с очень небольшим числом экранирований и размером больше (возможно, много больше) 255 байтов в строки UTF-8 формата CBOR. Точно так же некоторые двоичные представления floating-point могут возникать из некоторых десятичных представлений (1,1, 1e9) в JSON. Это может быть сложно для исправления и все возникающие уязвимости могут использоваться злоумышленником.

7. Будущее развитие CBOR

Успешные протоколы развиваются с течением времени. Появляются новые идеи, улучшается реализация платформ, сопровождающие протоколы разрабатываются и развиваются, добавляются требования от приложений и протоколов. Таким образом, содействие развитию протокола является важным при разработке любого нового протокола.

Для протоколов, которые будут использовать CBOR, формат CBOR обеспечивает некоторые полезные механизмы, способствующие развитию. Передовой опыт в этом направлении известен, в частности из разработки формата JSON для протоколов на основе JSON. Однако этот опыт выходит за рамки документа.

Тем не менее, развитие самого CBOR вписывается в эти задачи. Формат CBOR разработан для создания стабильной основы разработки протоколов на основе CBOR и возможности развития. Поскольку успешный протокол может развиваться в течение десятилетий, CBOR требуется разрабатывать с учётом такой эволюции. В этом разделе даны некоторые рекомендации по развитию CBOR. Они более субъективны, чем остальная часть этого документа. Кроме того, они не полны, чтобы не превратиться в текст по разработке протоколов.

7.1. Точки расширения

При создании протокола возможности его развития часто включаются в форме точек расширения. Например, может быть пространство кодов, которое не полностью выделено изначально, а протокол разработан так, чтобы допускались реализации, начинающие использовать больше кодов, чем было выделено исходно. Определение размера пространства кодов может быть затруднителеьным, поскольку требуемый диапазон предсказать модет быть сложно. При создании протокола следует следует пытаться сделать пространство кодов достаточно большим, чтобы оно не истощилось в течение предусмотренного срока действия протокола. В CBOR имеется 3 основных точки расширения.

Пространство простых значений (simple, базовый тип 7)

Из 24 эффективных (и 224 менее эффективных) значений, выделено лишь небольшое число. Реализации, получившие неизвестный элемент простых данных могут быть способны легко обработать их как таковые, учитывая простую структуру. Реестр IANA (параграф 9.1) даёт подходящий способ расширения пространства кода.

Пространство тегов (tag, базовый тип 6)

Общее пространство кодов избыточно и распределена лишь очень малая часть. Однако не все коды одинаково эффективны — первые 24 занимают лишь 1 байт (1+0) и половина из них уже распределена. Следующие 232 значения занимают по 2 байта (1+1) и распределены примерно на четверть. Для этих субпространств нужно некоторое наблюдение в течение нескольких следующих десятилетий. Реализации, получившие тег с неизвестным номером, могут обработать вложенное содержимое тега или (предпочтительно) обработать как неизвестный тег, включающий содержимое. Реестр IANA (параграф 9.2) даёт подходящий способ контроля расширения пространства кодов.

Пространство дополнительных значений

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

7.2. Курирование пространства дополнительных значений

Человеческий разум иногда стремится заполнить небольшие имеющиеся где-то зазоры. Предполагается, что остающиеся пропуски в пространстве кодов будут привлекать своим наличием новые идеи. Данная спецификация не управляет пространством дополнительных значений через реестр IANA. Выделения из этого пространства могут происходить лишь путём обновления этой спецификации.

Для дополнительного значения >= 24 размер дополнительных данных обычно составляет 2^n-24 байтов. Поэтому дополнительные значения 28 и 29 следует считать кандидатами для 128- и 256-битовых величин, при необходимости добавления их в протокол. Дополнительное значение 30 остаётся единственным доступным для общего распределения и должны быть важные причины для его выделения путём обновления данной спецификации.

8. Диагностическая нотация

CBOR — это двоичный формат обмена. Для облегчения документирования и отладки, в частности, для облегчения взаимодействия между элементами, участвующими в отладке, в этом разделе определятся простая и понятная человеку диагностическая нотация. Фактический обмен по-прежнему выполняется в двоичном формате. Это действительно диагностический формат, он не предназначен для синтаксического анализа, поэтому в документе нет формального определения (как в ABNF). Разработчики, ищущие основанный на тексте формат для представления элементов данных CBOR в файлах конфигурации, могут рассмотреть YAML [YAML].

Диагностическая нотация в общих чертах основана на JSON, как задано RFC 8259, с расширением при необходимости. Нотация следует синтаксису JSON для чисел (целых и действительных), True (true), False (false), Null (null), строк UTF-8, массивов и отображений (отображения в JSON называются объектами, диагностическая нотация расширяет здесь JSON, позволяя использовать в качестве ключа любой элемент данных). Неопределённые значения указываются в виде undefined как в JavaScript. Неконечные действительные числа Infinity, -Infinity и NaN записываются как здесь (этот же способ может применяться в JavaScript, хотя JSON не позволяет этого). Тег записываются как целое число (номер тега), за которым следует содержимое тега в скобках, например, дата в формате, заданном в RFC 3339 (ISO 8601), может быть записана как

        0("2013-03-21T20:04:00Z")

или эквивалентно в относительном формает

        1(1363896240)

Строки байтов указываются в одном из базовых форматов без дополнения в одинарных кавычках с префиксом h для base16, b32 для base32, h32 для base32hex, b64 для base64 или base64url (фактические коды не перекрываются, поэтому строки остаются однозначными). Например, строку байтов 0x12345678 можно записать в виде h’12345678′, b32’CI2FM6A’, b64’EjRWeA’.

Неназначенные простые значения указываются как «simple()» с подходящим целым числом в скобках. Например «simple(42)» указывает базовый тип 7 со значением 42.

Много полезных расширений для диагностической нотации дано в Приложении G к [RFC8610], Extended Diagnostic Notation (EDN). Нотация может быть расширена в отдельном документе для данных NaN, которые здесь не учтены.

8.1. Индикаторы кодирования

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

Соглашение для индикаторов кодирования состоит в том, что все, начинающееся с символа _, а последующие символы являются буквами, цифрами или знаком подчёркивания (_) является индикатором кодирования и может игнорироваться не заинтересованной в этих сведениях стороной, например, «_» или «_3». Индикаторы кодирования не обязательны.

Отдельный символ _ может указываться после открывающей квадратной скобки массива для указания того, что элемент данных был представлен в формате неопределённого размера. Например, [_ 1, 2] содержит индикатор неопределённого размера в представлении элемента данных [1, 2]. Симлов _, за которым следует десятичная цифра n, указывает что предшествующий элемент (для массивов и отображений, элемент, начинающийся с предшествующей круглой или квадратной скобки) был закодирован с дополнительным значением 24+n. Например, 1.5_1 — число floating-point половинной точности, а 1.5_3 — двойной. /тот индикатор кодирования не указан в Приложении A. Отметим, что индикатор _ является сокращением формы _7.

Подробная структура строк байтов и текста неопределённого размера может быть указана в форме (_ h’0123′, h’4567′) и (_ «foo», «bar»). Однако для строк неопределённого размера без блоков внутри (_ ) будет двусмысленным, в части того, применяется строка байтов (0x5fff) или текста (0x7fff), поэтому такой индикатор не применяется. Взамен могут применяться базовые формы »_ и «»_ и они зарезервированы лишь для отсутствия блоков, а не в качестве кратких форм (разрешено, но бесполезно) кодирования лишь с пустыми блоками, которые нужно обозначать как (_ »), (_ «»), для сохранения структуры блока.

9. Взаимодействие с IANA

Агентство IANA создало два реестра для новых значений CBOR. Реестры раздельны, т. е. не находятся под одним реестром, и следуют правилам [RFC8126]. Агентство IANA также выделило два новых типа носителя, связанную запись CoAP Content-Format и суффикс структурированного синтаксиса.

9.1. Реестр CBOR Simple Values

Агентство IANA создало реестр Concise Binary Object Representation (CBOR) Simple Values [IANA.cbor-simple-values]. Начальные значения приведены в таблице 4. Новые значения из диапазона 0 — 19 выделяются по процедуре Standards Action [RFC8126]. IANA предлагается выделять значения, начиная с 16, чтобы зарезервировать младшие номера для непрерывных блоков (если они есть). Значения из диапазона 32 — 255 выделяются по процедуре Specification Required.

9.2. Реестр CBOR Tags

Агентство IANA создало реестр Concise Binary Object Representation (CBOR) Tags [IANA.cbor-tags]. Теги, заданные в [RFC7049], подробно описаны в параграфе 3.4 и с тех пор уже определены другие теги. Новые значения из диапазона 0 — 23 (1+0) выделяются по процедуре Standards Action, из диапазонов 24 — 255 (1+1) и 256 — 32767 (нижняя половина 1+2) — по процедуре Specification Required. Новые значения от 32768 до 18446744073709551615 (верхняя половина 1+2, 1+4 и 1+8) выделяются по процедуре First Come First Served. Шаблон запроса на регистрацию имеет вид:

• элемент данных;

• семантика (краткая форма).

Кроме того, в запросы First Come First Served следует включать:

• точку контакта;

• описание семантики (URL) — оно не обязательно, URL может указывать что-то Internet-Draft или web-страницы.

Заявителям для диапазонов First Come First Served, предлагающим номер тега, который не представляется 32 битами (больше 4294967295), следует учитывать, что это может препятствовать совместимости с реализациями, которые не поддерживают 64-битовые числа.

9.3. Реестр Media Types

Типом носителя Internet [RFC6838] (MIME type) для одного кодированного элемента данных CBOR является application/cbor, как указано в реестре Media Types [IANA.media-types].

Type name: application

Subtype name: cbor

Required parameters: n/a

Optional parameters: n/a

Encoding considerations: Binary

Security considerations: See Section 10 of RFC 8949.

Interoperability considerations: n/a

Published specification: RFC 8949

Applications that use this media type: Many

Additional information:

Magic number(s): n/a

File extension(s): .cbor

Macintosh file type code(s): n/a

Person & email address to contact for further information: IETF CBOR Working Group (cbor@ietf.org) or IETF Applications and Real-Time Area (art@ietf.org)

Intended usage: COMMON

Restrictions on usage: none

Author: IETF CBOR Working Group (cbor@ietf.org)

Change controller: The IESG (iesg@ietf.org)

9.4. Реестр CoAP Content-Format

CoAP Content-Format для CBOR зарегистрирован в субреестре CoAP Content-Formats реестра Constrained RESTful Environments (CoRE) Parameters [IANA.core-parameters]:

Media Type: application/cbor

Encoding: —

ID: 60

Reference: RFC 8949

9.5. Реестр Structured Syntax Suffix

Суффиксом структурированного синтаксиса [RFC6838] для типов носителей, основанных на одном кодированном элементе данных CBOR, служит +cbor, зарегистрированный в реестре Structured Syntax Suffixes [IANA.structured-suffix]

Name: Concise Binary Object Representation (CBOR)

+suffix: +cbor

References: RFC 8949

Encoding Considerations: CBOR is a binary format.

Interoperability Considerations: n/a

Fragment Identifier Considerations: The syntax and semantics of fragment identifiers specified for +cbor SHOULD be as specified for «application/cbor». (At publication of RFC 8949, there is no fragment identification syntax defined for «application/cbor».)

The syntax and semantics for fragment identifiers for a specific «xxx/yyy+cbor» SHOULD be processed as follows:

• For cases defined in +cbor, where the fragment identifier resolves per the +cbor rules, then process as specified in +cbor.

• For cases defined in +cbor, where the fragment identifier does not resolve per the +cbor rules, then process as specified in «xxx/yyy+cbor».

• For cases not defined in +cbor, then process as specified in «xxx/yyy+cbor».

Security Considerations: See Section 10 of RFC 8949.

Contact: IETF CBOR Working Group (cbor@ietf.org) or IETF Applications and Real-Time Area (art@ietf.org)

Author/Change Controller: IETF

10. Вопросы безопасности

Сетевое приложение может иметь уязвимости в логике обработки входящих данных. Сложные синтаксические анализаторы хорошо известны как вероятный источник таких уязвимостей, как возможность удаленно вызвать отказ узла или даже выполнить на нем произвольный код. CBOR пытается сократить возможности внедрения таких уязвимостей путём снижения сложности синтаксических анализаторов за счёт придания смысла всему диапазону кодированных значений, когда это возможно.

Поскольку декодеры CBOR часто используются в качестве первого этапа обработки непроверенных входных данных, они должны быть полностью готовы ко всем типам враждебных данных, которые могут быть созданы для повреждения, переполнения или захвата управления системой, декодирующей элементы данных CBOR. Декодер CBOR должен предполагать, что весь ввод может быть враждебным, даже если данные проверены межсетевым экраном, поступили по защищённому каналу, такому как TLS, зашифрованы или подписаны, поступили из считающегося доверенным источника.

В параграфе 4.1 даны примеры ограничений функциональной совместимости при использовании ограниченного декодера CBOR вместе с кодером CBOR, использующим непредпочтительную сериализацию. Когда один элемент данных восприниают декодер с ограничениями и полный декодер, могут возникать проблемы безопасности, которыми атакующий может воспользоваться для внедрения или манипуляций содержимым.

Как уже обсуждалось в этом документе, есть много значений, которые могут считаться «эквивалентными» в одних обстоятельствах и разными — в других. Примером может служить численное значение «один», которое можно представить целым числом или bignum. Система, обрабатывающая ввод CBOR может воспринять или отвергнуть любую из этих форм (или обе). Это будет влиять на безопасность программы, использующей входные данные.

Враждебный ввод может служить для переполнения буферов, переполнения или потери значимости (underflow) в целочисленной арифметике, а также вызывать иные нарушения при декодировании. Элементы данных CBOR могут иметь размеры, которые преднамеренно сделаны слишком большими или слишком малыми. Атаки с истощением ресурсов могут пытаться вынудить декодер к выделению очень больших элементов данных (строк, массивов, отображений или даже чисел с произвольной точностью) или превышению глубины стека за счёт многоуровневой вложенности. Декодеры должны включать соответствующее управления ресурсами для смягчения таких атак. Элементы очень большого размера могут также служить для попыток использовать переполнение целых чисел.

Декодер CBOR по определению воспринимает лишь корректно сформированные данные CBOR — это первый шаг к отказоустойчивости. Получение некорректно сформированных данных CBOR не ведёт к их дальнейшей обработке после обнаружения некорректности. По возможности любые данные, которые уже декодированы к этому моменту, не должны оказывать влияния на приложение, использующее декодер CBOR.

В дополнение к проверке корректности декодер CBOR может проверять пригодность (validity) данных CBOR или оставить проверку пригодности приложению, использующему декодер. Этот выбор должен чётко указываться в документации декодера. Сверх проверки пригодности на уровне CBOR приложению нужно удостовериться в соответствии ввода приклатному протоколу, сериализуемому в CBOR.

Проверка ввода сама может потреблять ресурсы и обычно они линейно зависят от размера ввода, а это означает, что атакующему приходится затрачивать ресурсы, сопоставимые с затрачиваемыми на проверку ввода. Однако у атакующего может быть возможность создать входные данные, обработка которых займёт больше времени, чем их подготовка злоумышленником. Обработка чисел с произвольной точностью может усилить роста расхода ресурсов. Кроме того, некоторые реализации хэш-таблиц, используемые декодерами для представления отображений в памяти, могут быть атакованы с целью вызвать квадратичный рост расхода ресурсов, если не реализованы секретные ключи (см. раздел 7 в [SIPHASH_LNCS], а также [SIPHASH_OPEN]) или иные меры смягчения. Злоумышленник может воспользоваться такой нелинейностью для истощения ресурсов при входной проверке или до неё, поэтому следует избегать этого в реализации декодеров CBOR. Отметим, что определения номеров тегов и их реализация могут создавать проблемы безопасности этого типа, поэтому следует рассматривать соображения безопасности при определении тегов.

Кодеры CBOR не получают входные данные напрямую из сети и поэтому не подвержены таким же атакам, как декодеры CBOR. Однако кодеры CBOR часто включают API, принимающие данные от другого уровня реализации, и могут быть атакованы через эти API. Устройство и реализация таких API должны учитывать, что поведение вызывающей стороны может быть враждебным или основанным на ошибках кода. Следует проверять ввод на предмет переполнения буферов, переполнения и потери значимости в целочисленной арифметике, а также наличие иных ошибок, способных нарушить работу кодера.

Протоколы нужно задавать так, чтобы возможные множественные интерпретации надёжно сводились в одну. Например, злоумышленник может использовать непригодные входные данные, такие как дубликаты ключей в отображении, или воспользоваться разной точностью при обработке чисел, чтобы вынудить одно приложение к интерпретации, отличающейся от принятой другим. Для облегчения согласованной интерпретации реализациям кодеров и декодеров следует поддерживать режим проверки пригодности (параграф 5.4). Отметим однако, что базовый декодер не может знать всех требований приложения к входным данным, в результате чего приложение должно выполнять свою проверку ввода. Поскольку набор заданных тегов меняется, приложение может использовать номер тега, для которого ещё не поддерживается проверка пригодности в применяемом базовом декодере. Поэтому в документации базовых декодеров нужно указывать поддерживаемые теги и выполняемые проверки номеров тегов и базовые проверки CBOR (UTF-8, дубликаты ключей отображения).

В параграфе 3.4.3 отмечено, что использование непредпочтительного выбора для представления bignum вместо базового целого числа при кодировании не предназначено быть семантикой приложения, но может стать таковой, если принимающее данные CBOR приложение использует декодер в базовой модели данных. Это несоответствие создаёт проблему безопасности, если два варианта семантики различаются. Таким образом, использующим CBOR приложениям нужно указывать модель данных, которую они применяют при каждом использовании данных CBOR.

Данные CBOR часто преобразуются в иные форматы. Во многих случаях CBOR имеет более выразительные типы по сравнению с другими форматами и это особенно ярко проявляется для JSON. Потеря сведений о типе может вызывать проблемы безопасности для систем, обрабатывающих менее выразительные данные.

В параграфе 6.2 описан возможный вариант применения преобразования между CBOR и JSON, который может быть атакован, если злоумышленнику известно выполняющее преобразование приложение.

Соображения безопасности при использовании base16 и base64 из [RFC4648] и UTF-8 из [RFC3629] применимы и к CBOR.

11. Литература

11.1. Нормативные документы

[C] International Organization for Standardization, «Information technology — Programming languages — C», Fourth Edition, ISO/IEC 9899:2018, June 2018, <https://www.iso.org/standard/74528.html>.

[Cplusplus20] International Organization for Standardization, «Programming languages — C++», Sixth Edition, ISO/IEC DIS 14882, ISO/IEC ISO/IEC JTC1 SC22 WG21 N 4860, March 2020, <https://isocpp.org/files/papers/N4860.pdf>.

[IEEE754] IEEE, «IEEE Standard for Floating-Point Arithmetic», IEEE Std 754-2019, DOI 10.1109/IEEESTD.2019.8766229, <https://ieeexplore.ieee.org/document/8766229>.

[RFC2045] Freed, N. and N. Borenstein, «Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies», RFC 2045, DOI 10.17487/RFC2045, November 1996, <https://www.rfc-editor.org/info/rfc2045>.

[RFC2119] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC3339] Klyne, G. and C. Newman, «Date and Time on the Internet: Timestamps», RFC 3339, DOI 10.17487/RFC3339, July 2002, <https://www.rfc-editor.org/info/rfc3339>.

[RFC3629] Yergeau, F., «UTF-8, a transformation format of ISO 10646», STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, <https://www.rfc-editor.org/info/rfc3629>.

[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, «Uniform Resource Identifier (URI): Generic Syntax», STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <https://www.rfc-editor.org/info/rfc3986>.

[RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., «The Atom Syndication Format», RFC 4287, DOI 10.17487/RFC4287, December 2005, <https://www.rfc-editor.org/info/rfc4287>.

[RFC4648] Josefsson, S., «The Base16, Base32, and Base64 Data Encodings», RFC 4648, DOI 10.17487/RFC4648, October 2006, <https://www.rfc-editor.org/info/rfc4648>.

[RFC8126] Cotton, M., Leiba, B., and T. Narten, «Guidelines for Writing an IANA Considerations Section in RFCs», BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.

[RFC8174] Leiba, B., «Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words», BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[TIME_T] The Open Group, «The Open Group Base Specifications», Section 4.16, ‘Seconds Since the Epoch’, Issue 7, 2018 Edition, IEEE Std 1003.1, 2018, <https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_16>.

11.2. Дополнительная литература

[ASN.1] International Telecommunication Union, «Information Technology — ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)», ITU-T Recommendation X.690, 2015, <https://www.itu.int/rec/T-REC-X.690-201508-I/en>.

[BSON] Various, «BSON — Binary JSON», <http://bsonspec.org/>.

[CBOR-TAGS] Bormann, C., «Notable CBOR Tags», Work in Progress, Internet-Draft, draft-bormann-cbor-notable-tags-02, 25 June 2020, <https://tools.ietf.org/html/draft-bormann-cbor-notable-tags-02>.

[ECMA262] Ecma International, «ECMAScript 2020 Language Specification», Standard ECMA-262, 11th Edition, June 2020, <https://www.ecma-international.org/publications/standards/Ecma-262.htm>.

[Err3764] RFC Errata, Erratum ID 3764, RFC 7049, <https://www.rfc-editor.org/errata/eid3764>.

[Err3770] RFC Errata, Erratum ID 3770, RFC 7049, <https://www.rfc-editor.org/errata/eid3770>.

[Err4294] RFC Errata, Erratum ID 4294, RFC 7049, <https://www.rfc-editor.org/errata/eid4294>.

[Err4409] RFC Errata, Erratum ID 4409, RFC 7049, <https://www.rfc-editor.org/errata/eid4409>.

[Err4963] RFC Errata, Erratum ID 4963, RFC 7049, <https://www.rfc-editor.org/errata/eid4963>.

[Err4964] RFC Errata, Erratum ID 4964, RFC 7049, <https://www.rfc-editor.org/errata/eid4964>.

[Err5434] RFC Errata, Erratum ID 5434, RFC 7049, <https://www.rfc-editor.org/errata/eid5434>.

[Err5763] RFC Errata, Erratum ID 5763, RFC 7049, <https://www.rfc-editor.org/errata/eid5763>.

[Err5917] RFC Errata, Erratum ID 5917, RFC 7049, <https://www.rfc-editor.org/errata/eid5917>.

[IANA.cbor-simple-values] IANA, «Concise Binary Object Representation (CBOR) Simple Values», <https://www.iana.org/assignments/cbor-simple-values>.

[IANA.cbor-tags] IANA, «Concise Binary Object Representation (CBOR) Tags», <https://www.iana.org/assignments/cbor-tags>.

[IANA.core-parameters] IANA, «Constrained RESTful Environments (CoRE) Parameters», <https://www.iana.org/assignments/core-parameters>.

[IANA.media-types] IANA, «Media Types», <https://www.iana.org/assignments/media-types>.

[IANA.structured-suffix] IANA, «Structured Syntax Suffixes», <https://www.iana.org/assignments/media-type-structured-suffix>.

[MessagePack] Furuhashi, S., «MessagePack», <https://msgpack.org/>.

[PCRE] Hazel, P., «PCRE — Perl Compatible Regular Expressions», <https://www.pcre.org/>.

[RFC0713] Haverty, J., «MSDTP-Message Services Data Transmission Protocol», RFC 713, DOI 10.17487/RFC0713, April 1976, <https://www.rfc-editor.org/info/rfc713>.

[RFC6838] Freed, N., Klensin, J., and T. Hansen, «Media Type Specifications and Registration Procedures», BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, <https://www.rfc-editor.org/info/rfc6838>.

[RFC7049] Bormann, C. and P. Hoffman, «Concise Binary Object Representation (CBOR)», RFC 7049, DOI 10.17487/RFC7049, October 2013, <https://www.rfc-editor.org/info/rfc7049>.

[RFC7228] Bormann, C., Ersue, M., and A. Keranen, «Terminology for Constrained-Node Networks», RFC 7228, DOI 10.17487/RFC7228, May 2014, <https://www.rfc-editor.org/info/rfc7228>.

[RFC7493] Bray, T., Ed., «The I-JSON Message Format», RFC 7493, DOI 10.17487/RFC7493, March 2015, <https://www.rfc-editor.org/info/rfc7493>.

[RFC7991] Hoffman, P., «The «xml2rfc» Version 3 Vocabulary», RFC 7991, DOI 10.17487/RFC7991, December 2016, <https://www.rfc-editor.org/info/rfc7991>.

[RFC8259] Bray, T., Ed., «The JavaScript Object Notation (JSON) Data Interchange Format», STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, <https://www.rfc-editor.org/info/rfc8259>.

[RFC8610] Birkholz, H., Vigano, C., and C. Bormann, «Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures», RFC 8610, DOI 10.17487/RFC8610, June 2019, <https://www.rfc-editor.org/info/rfc8610>.

[RFC8618] Dickinson, J., Hague, J., Dickinson, S., Manderson, T., and J. Bond, «Compacted-DNS (C-DNS): A Format for DNS Packet Capture», RFC 8618, DOI 10.17487/RFC8618, September 2019, <https://www.rfc-editor.org/info/rfc8618>.

[RFC8742] Bormann, C., «Concise Binary Object Representation (CBOR) Sequences», RFC 8742, DOI 10.17487/RFC8742, February 2020, <https://www.rfc-editor.org/info/rfc8742>.

[RFC8746] Bormann, C., Ed., «Concise Binary Object Representation (CBOR) Tags for Typed Arrays», RFC 8746, DOI 10.17487/RFC8746, February 2020, <https://www.rfc-editor.org/info/rfc8746>.

[SIPHASH_LNCS] Aumasson, J. and D. Bernstein, «SipHash: A Fast Short-Input PRF», Progress in Cryptology — INDOCRYPT 2012, pp. 489-508, DOI 10.1007/978-3-642-34931-7_28, 2012, <https://doi.org/10.1007/978-3-642-34931-7_28>.

[SIPHASH_OPEN] Aumasson, J. and D.J. Bernstein, «SipHash: a fast short-input PRF», <https://www.aumasson.jp/siphash/siphash.pdf>.

[YAML] Ben-Kiki, O., Evans, C., and I.d. Net, «YAML Ain’t Markup Language (YAML[TM]) Version 1.2», 3rd Edition, October 2009, <https://www.yaml.org/spec/1.2/spec.html>.

Приложение A. Примеры кодированных элементов данных CBOR

В таблице 6 представлено кодирование CBOR для некоторых значений в шестнадцатеричной форме (справа) и диагностическая нотация для них (слева). Отметим, что строка «\u00fc» является одной из форм диагностической нотации для строк UTF-8 с одним символом Unicode U+00FC (LATIN SMALL LETTER U WITH DIAERESIS, «ü»), «\u6c34» — строки UTF-8 с одним символом U+6C34 (CJK UNIFIED IDEOGRAPH-6C34, «水«), часто представляющим воду (water), а «\ud800\udd51» — строки UTF-8 с одним символом U+10151 (GREEK ACROPHONIC ATTIC FIFTY STATERS, «?»). Отметим, что все эти односимвольные строки можно представить в обычно диагностической нотации UTF-8, если не требуется применять лишь символы ASCII. В диагностической нотации для bignums предполагаемое численное значение указывается в десятичной форме (например, 18446744073709551616), а не строкой байтов с тегом (например, 2(h’010000000000000000′)).

Таблица 6. Примеры кодированных элементов данных CBOR.

Диагностика	Кодирование
0	0x00
1	0x01
10	0x0a
23	0x17
24	0x1818
25	0x1819
100	0x1864
1000	0x1903e8
1000000	0x1a000f4240
1000000000000	0x1b000000e8d4a51000
18446744073709551615	0x1bffffffffffffffff
18446744073709551616	0xc249010000000000000000
-18446744073709551616	0x3bffffffffffffffff
-18446744073709551617	0xc349010000000000000000
-1	0x20
-10	0x29
-100	0x3863
-1000	0x3903e7
0.0	0xf90000
-0.0	0xf98000
1.0	0xf93c00
1.1	0xfb3ff199999999999a
1.5	0xf93e00
65504.0	0xf97bff
100000.0	0xfa47c35000
3.4028234663852886e+38	0xfa7f7fffff
1.0e+300	0xfb7e37e43c8800759c
5.960464477539063e-8	0xf90001
0.00006103515625	0xf90400
-4.0	0xf9c400
-4.1	0xfbc010666666666666
Infinity	0xf97c00
NaN	0xf97e00
-Infinity	0xf9fc00
Infinity	0xfa7f800000
NaN	0xfa7fc00000
-Infinity	0xfaff800000
Infinity	0xfb7ff0000000000000
NaN	0xfb7ff8000000000000
-Infinity	0xfbfff0000000000000
false	0xf4
true	0xf5
null	0xf6
undefined	0xf7
simple(16)	0xf0
simple(255)	0xf8ff
0(«2013-03-21T20:04:00Z»)	0xc074323031332d30332d32315432303a30343a30305a
1(1363896240)	0xc11a514b67b0
1(1363896240.5)	0xc1fb41d452d9ec200000
23(h’01020304′)	0xd74401020304
24(h’6449455446′)	0xd818456449455446
32(«http://www.example.com»)	0xd82076687474703a2f2f7777772e6578616d706c652e636f6d
h»	0x40
h’01020304′	0x4401020304
«»	0x60
«a»	0x6161
«IETF»	0x6449455446
«\»\\»	0x62225c
«\u00fc»	0x62c3bc
«\u6c34»	0x63e6b0b4
«\ud800\udd51»	0x64f0908591
[]	0x80
[1, 2, 3]	0x83010203
[1, [2, 3], [4, 5]]	0x8301820203820405
[1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25]	0x98190102030405060708090a0b0c0d0e0f101112131415161718181819
{}	0xa0
{1: 2, 3: 4}	0xa201020304
{«a»: 1, «b»: [2, 3]}	0xa26161016162820203
[«a», {«b»: «c»}]	0x826161a161626163
{«a»: «A», «b»: «B», «c»: «C», «d»: «D», «e»: «E»}	0xa56161614161626142616361436164614461656145
(_ h’0102′, h’030405′)	0x5f42010243030405ff
(_ «strea», «ming»)	0x7f657374726561646d696e67ff
[_ ]	0x9fff
[_ 1, [2, 3], [_ 4, 5]]	0x9f018202039f0405ffff
[_ 1, [2, 3], [4, 5]]	0x9f01820203820405ff
[1, [2, 3], [_ 4, 5]]	0x83018202039f0405ff
[1, [_ 2, 3], [4, 5]]	0x83019f0203ff820405
[_ 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25]	0x9f0102030405060708090a0b0c0d0e0f101112131415161718181819ff
{_ «a»: 1, «b»: [_ 2, 3]}	0xbf61610161629f0203ffff
[«a», {_ «b»: «c»}]	0x826161bf61626163ff
{_ «Fun»: true, «Amt»: -2}	0xbf6346756ef563416d7421ff

Приложение B. Таблица переходов для начального байта

Для краткости в таблице 7 не представлены начальные байты, зарезервированные для будущих расширений, и включена лишь подборка начальных байтов, которые могут служить для необязательных функций. Все целые числа без знака указаны в сетевом порядке байтов.

Таблица 7. Таблица перехода для начального байта.

 

Байт	Структура и семантика
0x00..0x17	целое число без знака 0x00..0x17 (0..23)
0x18	целое число без знака, затем 1 байт uint8_t
0x19	целое число без знака, затем 2 байта uint16_t
0x1a	целое число без знака, затем 4 байта uint32_t
0x1b	целое число без знака, затем 8 байтов uint64_t
0x20..0x37	отрицательное целое число -1-0x00..-1-0x17 (-1..-24)
0x38	отрицательное целое число -1-n, затем 1 байт uint8_t для n
0x39	отрицательное целое число -1-n, затем 2 байта uint16_t для n
0x3a	отрицательное целое число -1-n, затем 4 байта uint32_t для n
0x3b	отрицательное целое число -1-n, затем 8 байтов uint64_t для n
0x40..0x57	строка байтов, затем 0x00..0x17 байтов
0x58	строка байтов, затем 1 байт uint8_t для n и n байтов
0x59	строка байтов, затем 2 байта uint16_t для n и n байтов
0x5a	строка байтов, затем 4 байта uint32_t для n и n байтов
0x5b	строка байтов, затем 8 байтов uint64_t для n и n байтов
0x5f	строка байтов, затем строка байтов и break
0x60..0x77	строка UTF-8, затем 0x00..0x17 байтов
0x78	строка UTF-8, затем 1 байт uint8_t для n и n байтов
0x79	строка UTF-8, затем 2 байта uint16_t для n и n байтов
0x7a	строка UTF-8, затем 4 байта uint32_t для n и n байтов
0x7b	строка UTF-8, затем 8 байтов uint64_t для n и n байтов
0x7f	строка UTF-8, затем строка байтов и break
0x80..0x97	массив, затем 0x00..0x17 элементов данных
0x98	массив, затем 1 байт uint8_t для n и n элементов данных
0x99	массив, затем 2 байта uint16_t для n и n элементов данных
0x9a	массив, затем 4 байта uint32_t для n и n элементов данных
0x9b	массив, затем 8 байтов uint64_t для n и n элементов данных
0x9f	массив, затем элементы данных и break
0xa0..0xb7	отображение, затем 0x00..0x17 пар элементов данных
0xb8	отображение, затем 1 байт uint8_t для n и n пар элементов данных
0xb9	отображение, затем 2 байта uint16_t для n и n пар элементов данных
0xba	отображение, затем 4 байта uint32_t для n и n пар элементов данных
0xbb	отображение, затем 8 байтов uint64_t для n и n пар элементов данных
0xbf	отображение, затем пары элементов данных и break
0xc0	текстовое представление даты-времени, затем элемент данных (параграф 3.4.1)
0xc1	дата и время на основе эпохи, затем элемент данных (параграф 3.4.2)
0xc2	bignum без знака, затем строка байтов
0xc3	отрицательное значение bignum, затем строка байтов
0xc4	десятичная дробь, затем массив (параграф 3.4.4)
0xc5	bigfloat, затем массив (параграф 3.4.4)
0xc6..0xd4	(тег)
0xd5..0xd7	ожидаемое преобразование, затем элемент данных (параграф 3.4.5.2)
0xd8..0xdb	(дополнительные теги — 1/2/4/8 номера тега, затем элемент данных)
0xe0..0xf3	(простое значение)
0xf4	false
0xf5	true
0xf6	null
0xf7	undefined
0xf8	(простое значение, затем 1 байт)
0xf9	действительное число половинной точности (2 байта IEEE 754)
0xfa	действительное число одинарной точности (4 байта IEEE 754)
0xfb	действительное число двойной точности (8 байтов IEEE 754)
0xff	код завершения break

 

Приложение C. Псевдокод

Корректность формы элемента CBOR можно проверить с помощью псевдокода, представленного на рисунке 1. Данные считаются корректно сформированными лишь при выполнении обоих указанных ниже условий.

• Результат выполнения псевдокода отличается от fail.

• После выполнения псевдокода не остаётся байтов на входе (за исключением потоковых приложений).

Псевдокод предполагает выполнение указанных ниже условий.

• Функция take(n) считывает n байтов входных данных и возвращает их в форме строки байтов. Если n байтов больше не доступно, take(n) возвращает отказ (fail).

• Функция uint() преобразует строку байтов в целое число без знака, интерпретируя строку в сетевом порядке байтов.

• Арифметические операции выполняются как в языке C.

• Все переменные являются целыми числами без знака с достаточным размером.

Отметим, что well_formed возвращает базовый тип для корректно сформированных элементов определённого размера и значение 99 для элементов неопределённого размера (или -1 для кода завершения break, если установлен флаг breakable). Это используется в well_formed_indefinite, для проверки того, что строки неопределённого размера состоят лишь из блоков определённого размера.

   well_formed(breakable = false) {
     // обработка начальных байтов
     ib = uint(take(1));
     mt = ib >> 5;
     val = ai = ib & 0x1f;
     switch (ai) {
       case 24: val = uint(take(1)); break;
       case 25: val = uint(take(2)); break;
       case 26: val = uint(take(4)); break;
       case 27: val = uint(take(8)); break;
       case 28: case 29: case 30: fail();
       case 31:
         return well_formed_indefinite(mt, breakable);
     }
     // обработка содержимого
     switch (mt) {
       // в случаях 0, 1, 7 содержимого нет и просто используется val
       case 2: case 3: take(val); break; // байты/UTF-8
       case 4: for (i = 0; i < val; i++) well_formed(); break;
       case 5: for (i = 0; i < val*2; i++) well_formed(); break;
       case 6: well_formed(); break;     // 1 вложенный элемент
       case 7: if (ai == 24 && val < 32) fail(); // плохое простое значение
     }
     return mt;                    // элемент данных определённого размера
   }

   well_formed_indefinite(mt, breakable) {
     switch (mt) {
       case 2: case 3:
         while ((it = well_formed(true)) != -1)
           if (it != mt)           // нужен блок определённого размера
             fail();               // с тем же типом
         break;
       case 4: while (well_formed(true) != -1); break;
       case 5: while (well_formed(true) != -1) well_formed(); break;
       case 7:
         if (breakable)
           return -1;              // указывает прерывание (break out)
         else fail();              // нет вложенных элементов 
                                   // неопределённого размера
       default: fail();            // неверное значение mt
     }
     return 99;                    // элемент неопределённого размера
   }

Рисунок 1. Псевдокод для проверки пригодности формы.

Отметим, что оставшаяся сложность полного декодера CBOR состоит в представлении декодированных данных приложению в подходящей форме.

Базовые типы 0 и 1 можно закодировать в C из целого числа со знаком, фактически без if-then-else для знака (Рисунок 2). используется то, что (-1-n) — преобразование для базового типа 1 — совпадает с ~n (побитовое дополнение) в арифметике C, ~n можно выразить как (-1)ⁿ для отрицательного числа, тогда как 0ⁿ оставляет n без изменения в случае неотрицательного. Знак числа можно представить как -1 для отрицательного и 0 в ином случае (0 или положительное число) путём арифметического сдвига числа на 1 бит меньше его размера (например, на 63 для 64-битового числа).

   void encode_sint(int64_t n) {
     uint64t ui = n >> 63;    // извлечение знака
     unsigned mt = ui & 0x20; // извлечение базового типа
     ui ^= n;                 // дополнение отрицательного числа
     if (ui < 24)
       *p++ = mt + ui;
     else if (ui < 256) {
       *p++ = mt + 24;
       *p++ = ui;
     } else
          ...

Рисунок 2. Псевдокод для кодирования целого числа со знаком.

В параграфе 1.2 указаны некоторые конкретные допущения о профиле языка C, применяемого в этих фрагментах кода.

Приложение D. Половинная точность

Поскольку действительные числа (floating-point) с половинной точностью были добавлены в IEEE 754 лишь в 2008 г. [IEEE754], сегодняшние программные платформы зачастую имеют для них лишь ограниченную поддержку. Для этих чисел очень просто включить хотя бы поддержку декодирования. Пример небольшого декодера на языке C для действительных чисел с половинной точностью приведён на рисунке 3, а похожей программы Python — на рисунке 4. Этот код предполагает, что 2-байтовое значение уже декодировано как (короткое без знака) целое число с сетевым порядком байтов (как делает псевдокод из Приложения C).

   #include <math.h>

   double decode_half(unsigned char *halfp) {
     unsigned half = (halfp[0] << 8) + halfp[1];
     unsigned exp = (half >> 10) & 0x1f;
     unsigned mant = half & 0x3ff;
     double val;
     if (exp == 0) val = ldexp(mant, -24);
     else if (exp != 31) val = ldexp(mant + 1024, exp - 25);
     else val = mant == 0 ? INFINITY : NAN;
     return half & 0x8000 ? -val : val;
   }

Рисунок 3. Код C для декодера с половинной точностью.

   import struct
   from math import ldexp

   def decode_single(single):
       return struct.unpack("!f", struct.pack("!I", single))[0]

   def decode_half(half):
       valu = (half & 0x7fff) << 13 | (half & 0x8000) << 16
       if ((half & 0x7c00) != 0x7c00):
           return ldexp(decode_single(valu), 112)
       return decode_single(valu | 0x7f800000)

Рисунок 4. Код Python для декодера с половинной точностью.

Приложение E. Сравнение с другими двоичными форматами

Предложение CBOR следует за чередой двоичных форматов, длинной как история компьютеров. Разные форматы создавались с различными целями. В большинстве случаев цели формата не объявлялись, хотя они иногда подразумеваются контекстом, где формат изначально применялся. Некоторые форматы предназначались для универсального применения, хотя история показала, что ни один формат не отвечает потребностям всех протоколов и приложений.

CBOR отличается от многих из этих форматов тем, что он чётко задаёт набор целей и пытается достичь их. В этом приложении несколько десятков форматов сравнивается с целями CBOR, чтобы помочь читателю решить вопрос о применении CBOR или иного формата для конкретного протокола или приложения.

Отметим, что обсуждение не нацелено на критику того или иного формата. Насколько известно авторам, ни один из форматов до CBOR не предназначался для объявленных CBOR целей с учётом заданных для них приоритетов. Краткий список целей из параграфа 1.1 приведён ниже.

1. Однозначное кодирование наиболее распространённых форматов из стандартов Internet.

2. Компактность кодеров и декодеров.

3. Отсутствие требования описания схемы.

4. Достаточно компактная сериализация.

5. Применимость в приложениях с ограничениями и без таковых.

6. Хорошая преобразуемость в JSON.

7. Расширяемость.

Обсуждение CBOR и других форматов в плане иного набора целей представлено в разделе 5 и Приложении C [RFC8618].

E.1. ASN.1 DER, BER, PER

[ASN.1] имеет много вариантов сериализации. В IETF чаще всего применяются DER и BER. Последовательный вывод недостаточно компактен для многих элементов, а код для декодирования числовых элементов достаточно сложен для устройств с ограничениями.

Немногие (если есть) протоколы IETF приняли один из нескольких вариантов правил кодирования пакетов (Packed Encoding Rules или PER). Для этого есть много причин и одна из них как правило состоит в том, что PER использует схему даже для анализа поверхностной структуры элемента данных, требуя значительной инструментальной поддержки. Имеются разные версии языка схем ASN.1, что также препятствует внедрению.

E.2. MessagePack

[MessagePack] — это компактный, широко распространенный формат счетной двоичной сериализации, во многом походий на CBOR, хотя и менее привычный. Модель данных может служить для представления данных JSON, а также MessagePack применяется во многих приложениях с удаленным вызовом процедур (remote procedure call или RPC) а также для длительного хранения данных. Формат MessagePack практически стабилен с момента публикации около 2011 г., новых версий ещё нет. Развитие сдерживает необходимость поддержки полной совместимости с уже хранящимися данными и доступность для расширения лишь нескольких байт-кодов. Запросы сообщества пользователей MessagePack в течение многих лет на разделение двоичных и текстовых строк недавно привели к расширению, которое будет оставлять необработанные (raw) данные MessagePack неоднозначными при использовании для двоичных и текстовых данных. Механизм расширения MessagePack остаётся непонятным.

E.3. BSON

[BSON] — формат данных, разработанный для хранения отображений в стиле JSON (объекты JSON) в базе данных MongoDB. Его основным отличием является возможность обновления на месте, что препятствует компактности. BSON применяет счетное представление за исключением ключей отображений, которые используют null-байт в конце. Хотя BSON можно применять для представления подобных JSON объектов в линии, в спецификации преобладают требования баз данных и формат стал несколько причудливым. Статус способов расширения BSON остаётся неясным.

E.4. MSDTP — RFC 713

MSDTP (Message Services Data Transmission) является очень ранним примером компактного формата сообщений, описанным [RFC0713] в 1976 г. Формат включён изза исторической ценности, а не по причине широкого применения.

E.5. Лаконичность в линии

Хотя цель CBOR в части компактности кодеров и декодеров является более приоритетной, чем обеспечение лаконичности в линии, многих интересует компактность передачи. В таблице 8 приведены некоторые примеры кодирования для простого вложенного массива [1, [2, 3]], где поддерживается некая форма кодирования неопределённого размера, а также показано кодирование при неопределенном размере внешнего массива [_ 1, [2, 3]].

Таблица 8. Примеры разных уровней лаконичности.

Формат	[1, [2, 3]]	[_ 1, [2, 3]]
RFC 713	c2 05 81 c2 02 82 83
ASN.1 BER	30 0b 02 01 01 30 06 02 01 02 02 01 03	30 80 02 01 01 30 06 02 01 02 02 01 03 00 00
MessagePack	92 01 92 02 03
BSON	22 00 00 00 10 30 00 01 00 00 00 04 31 00 13 00 00 00 10 30 00 02 00 00 00 10 31 00 03 00 00 00 00 00
CBOR	82 01 82 02 03	9f 01 82 02 03 ff

Приложение F. Некорректные формы и примеры

При декодировании элементов данных CBOR могут возникать три основных ошибки формы элемента.

Слишком много данных

При вводе остались неиспользованные байты. Это является ошибкой лишь в том случае, когда приложение считало, что входные байты охватывают ровно один элемент данных. Если приложение использует присущее CBOR саморазграничение, чтобы разрешить дополнительные данные после элемента данных, как это делается, например, в последовательностях CBOR [RFC8742], декодер CBOR может просто указать, какая часть ввода не была использована.

Слишком мало данных

Доступных при вводе данных недостаточно для полного элемента данных CBOR. Это может указывать отсечку ввода или попытку декодировать случайные данные как CBOR. Однако для некоторых приложений это может не быть ошибкой, поскольку приложение может быть не уверено в получении всех данных или ждать поступления на вход дополнительных байтов. Некоторые из таких приложений могут иметь верхнее ограничение числа возможных дополнительных данных и декодер здесь может указать, что кодированный элемент данных CBOR не может поместиться с учётом этого предела.

Синтаксическая ошибка

Входные данные не соответствуют требованиям кодирования CBOR и это не исправить добавлением (или удалением) данных в конце.

Ошибки первого типа рассматриваются в первом абзаце (и списке — не осталось байтов) Приложения C, а ошибки второго типа — во втором абзаце и списке этого приложения. Третий тип ошибок идентифицируется в псевдокоде конкретными экземплярами вызова fail() в указанном ниже порядке.

• Дополнительное значение из числа зарезервированных (28, 29, 30).

• Базовый тип 7, дополнительное значение 24, значение < 32 (некорректно)

• Некорректная структура строки байтов или текста с неопределённым размером (может включать лишь строки того же базового типа с определенным размером).

• Код завершения break (базовый тип 7, дополнительное значение 31) в позиции значения в отображении, не находящейся в элементе неопределённого размера, куда может быть вложен другой элемент данных.

• Дополнительное значение 31 используется с базовым типом 0, 1 или 6.

F.1. Примеры элементов данных CBOR не пригодных по форме

В этом параграфе приведено несколько примеров некорректных по форме элементов данных CBOR в виде последовательности байтов в шестнадцатеричной форме. Отдельные примеры разделены запятыми.

Примеры ошибок типа 1 (много данных) легко создать добавлением байтов в конец корректного элемента CBOR. Примеры ошибок типа 2 (мало данных) легко создать путём отсечки корректных элементов CBOR. В тестовых наборах может быть полезной специальная проверка неполных элементов данных, которые требуют для завершения много данных (например, путём запуска кодирования очень большой строки).

Преждевременное завершение ввода может произойти в голове или внутри вложенных данных, которые могут быть обычными строками или вложенными элементами (подсчитываются или завершаются кодом break).

Конец ввода в голове

18, 19, 1a, 1b, 19 01, 1a 01 02, 1b 01 02 03 04 05 06 07, 38, 58, 78, 98, 9a 01 ff 00, b8, d8, f8, f9 00, fa 00 00, fb 00 00 00

Строка определённого размера с нехваткой данных

41, 61, 5a ff ff ff ff 00, 5b ff ff ff ff ff ff ff ff 01 02 03, 7a ff ff ff ff 00, 7b 7f ff ff ff ff ff ff ff 01 02 03

Отображения и массивы определённого размера с нехваткой элементов

81, 81 81 81 81 81 81 81 81 81, 82 00, a1, a2 01 02, a1 00, a2 00 00 00

Номер тега без содержимого тега

c0

Строка неопределённого размера без кода завершения break

5f 41 00, 7f 61 00

Отображение или массив неопределённого размера без кода завершения break

9f, 9f 01 02, bf, bf 01 02 01 02, 81 9f, 9f 80 00, 9f 9f 9f 9f 9f ff ff ff ff, 9f 81 9f 81 9f 9f ff ff ff

Ниже представлены примеры 5 подтипов синтаксических ошибок (тип 3).

Подтип 1

Резервные дополнительные значения

1c, 1d, 1e, 3c, 3d, 3e, 5c, 5d, 5e, 7c, 7d, 7e, 9c, 9d, 9e, bc, bd, be, dc, dd, de, fc, fd, fe,

Подтип 2

Резервное двухбайтовое кодирование простых значений

f8 00, f8 01, f8 18, f8 1f

Подтип 3

Блоки некорректного типа в строке неопределённого размера

5f 00 ff, 5f 21 ff, 5f 61 00 ff, 5f 80 ff, 5f a0 ff, 5f c0 00 ff, 5f e0 ff, 7f 41 00 ff

Блоки неопределённого размера в строке неопределённого размера

5f 5f 41 00 ff ff, 7f 7f 61 00 ff ff

Подтип 4

Код завершения вне элемента неопределённого размера

ff

Код завершения в массиве или отображении с определенным размером

81 ff, 82 00 ff, a1 ff, a1 ff 00, a1 00 ff, a2 00 00 ff, 9f 81 ff, 9f 82 9f 81 9f 9f ff ff ff ff

Код завершения в отображении неопределённого размера, задающие нечётное число элементов (break вместо значения)

bf 00 ff, bf 00 00 00 ff

Подтип 5

Базовый тип 0, 1, 6 с дополнительным значением 31

1f, 3f, df

Приложение G. Отличия от RFC 7049

Как указано во введении, этот документ формально отменяет RFC 7049, сохраняя полную совместимость с форматом обмена RFC 7049. Документ содержит редакционные правки, дополнительные детали и исправления ошибок. Документ не задаёт новую версию формата.

G.1. Ошибки и редакционные правки

Исправлены две подтверждённые ошибки в RFC 7049 [Err3764] [Err3770] (параграф 3.4.3: «29» -> «49», параграф 5.5: «0b000_11101» -> «0b000_11001»). Кроме того, в RFC 7049 дан пример использования числа 24 для простого значения [Err5917], что является ошибкой формы — пример исключён. В [Err5763] указана ошибка в формулировке определения тега, она исправлена в формулировке параграфа 3.4. В [Err5434] отмечено, что пример Universal Binary JSON (UBJSON) в Приложении E больше не соответствует текущей версии UBJSON на момент обнаружения ошибки. Оказалось, что спецификация UBJSON была полностью изменена с 2013 г., поэтому пример был удалён. В [Err4409] [Err4963] [Err4964] отмечена обременительность правил сортировки ключей отображения для канонического кодирования — это привело к пересмотру предложений по каноническому кодированию и замене их предложениями по детерминированному кодированию (см. ниже). Учтено сообщение [Err4294] путём добавления второго значения в комментарий к последнему примеру в параграфе 3.2.2, улучшившего симметрию.

Другие редакционные правки указаны ниже.

• Используется новая функциональность xml2rfc [RFC7991].

• Дополнительно разъяснена используемая нотация.

• Обновлены ссылки, например, [RFC8259] вместо RFC 4627, [RFC7228] вместо CNN-TERMS и 11-е издание [ECMA262] вместо 5.1. Добавлены ссылки на [IEEE754] и включены необходимые определения, добавлены ссылки на [C] и [Cplusplus20], а также ссылка на [RFC8618], где дополнительно иллюстрируется обсуждение из Приложения E.

• При обсуждении диагностической нотации (раздел 8) упомянута расширенная диагностическая нотация (Extended Diagnostic Notation или EDN), определённая в [RFC8610], выделен пробел в представлении данных NaN, а также добавлено разъяснения представления строк неопределённого размера без блоков (параграф 8.1).

• Добавлено это приложение.

G.2. Изменения взаимодействия с IANA

Обновлено описание взаимодействия с IANA (редакционные правки, например указание рабочей группы CBOR как автора спецификации). Добавлены ссылки на реестры IANA в раздел 11.2. Дополнительная литература.

В реестре Concise Binary Object Representation (CBOR) Tags [IANA.cbor-tags] теги 256 — 32767 (нижняя половина 1+2) больше не назначаются по процедуре First Come First Served, заменённой на процедуру Specification Required.

G.3. Изменения в предложениях и других информационных компонентах

При пересмотре документа, помимо исправления замеченных ошибок, рабочая группа учла почти 7-летний опыт применения CBOR в разнообразных приложениях. Это привело к ряду редакционных изменений, включая добавление таблиц для иллюстрации, а также выделение одних аспектов и снижение внимания к другим.

Важным дополнением является раздел 2 с обсуждением модели данных CBOR и её небольших вариаций, связанных с обработкой CBOR. Введение терминов для этих вариаций (базовая, расширенная базовая, конкретная) позволило сократить текст в других частях документа и помогло прояснить ожидания от реализаций и возможностей расширения.

Поскольку формат был выведен из экосистемы JSON, на RFC 7049 существенно повлияла система чисел в JSON, которая в свою очередь была унаследована от JavaScript. В JSON не разделяются целочисленные (integer) и действительные (floating-point) значения (последние указываются в десятичной форме). В CBOR применяется двоичное представление чисел, различающее значения integer и floating-point. Опыт реализации и развёртывания показал, что такое разделение следует более чётко указать в документе — текст, предполагающий простую замены действительного числа целым, был исключён. Кроме того, добавлено предложение (на основе I-JSON [RFC7493]) по обработке этих типов при преобразовании JSON в CBOR, а также рекомендовано использовать конкретный механизм округления.

В модели данных CBOR часто предполагает разные варианты кодирования одного значения. Новый раздел 4 вводит термин «предпочтительная сериализация» (preferred serialization, параграф 4.1) и определяет его для разных типов элементов данных. На основе этого в разделе обсуждается, как протокол на основе CBOR может определить детерминированное кодирование (параграф 4.2), чтобы избежать терминов «канонический» (canonical) и «канонизация» из RFC 7049. Параграф 4.2.1. Базовые требования детерминированного кодирования разрешает базовую поддержку таких протокольных требований к кодированию. Этот документ дополнительно упрощает реализацию детерминированного кодирования за счёт замены порядка отображений, предложенного в RFC 7049, простым лексикографическим порядком кодированных ключей. Описание старого предложения сохранено как вариант, названный упорядочением сначала по размеру (параграф 4.2.3).

Уточнена и более строго применяется терминология для корректно сформированных и действительных (пригодных) данных, что позволило избежать в примерах менее чётких терминов «синтаксическая ошибка» (syntax error), «ошибка декодирования» (decoding error» и «строгий режим» (strict mode). Явно назван третий уровень требования приложения к вводу, выходящий за пределы проверки пригодности на уровне CBOR. Корректно сформированный (пригодный для обработки), действительный (проверенный базовым декодером на пригодность) и ожидаемый (проверенный приложением) ввод образуют иерархию уровней пригодности (применимости).

Обработка простых значений с некорректной формой разъяснена в тексте и псевдокоде. Добавлено Приложение F с обсуждением ошибок формы и примерами. Псевдокод обновлён для улучшения переносимости и рассмотрены вопросы переносимости.

Обсуждение пригодности поделено на 2 части. Разъяснена пригодность отображений (обработка дубликатов ключей) и сфера применимости некоторых реализаций. При обсуждении терминологии для тегов, их номеров и содержимого добавлена пригодность тегов и разъяснены ограничения для содержимого в целом и конкретно для тега 1.

В параграф 3.4 добавлено примечание для разработчиков (и определения новых тегов) об определении тегов с зависящей от порядка сериализации семантикой.

Тег 35 не определён в этом документе, регистрация на основе определения из RFC 7049 сохранена.

В разделе 3 определены термины «аргумент» (argument) и «голова» (head), упрощающие дальнейшее обсуждение.

Раздел 10. Вопросы безопасности по большей части переписан, во многих местах документа теперь явно указано, что декодер не может просто мириться с ошибками формы.

Благодарности

Прообразом CBOR является формат MessagePack, разработанный и продвигаемый Sadayuki Furuhashi («frsyuki»). Это упоминание MessagePack предназначено лишь для указания авторства, CBOR не является версией или заменой MessagePack, поскольку они различаются по целям и требованиям.

Потребность в функциях, выходящих за пределы исходной спецификации MessagePack, стала очевидной для многих примерно в 2012 г. Формат BinaryPack на основе небольшого изменения MessagePack разработал Eric Zhang для проекта binaryjs. Похожее, но своё расширение предложил Tim Caswell для проектов msgpack-js и msgpack-js-browser. Многие люди участвовали в обсуждении расширения MessagePack для разделения представлений строк текста и байтов.

Прообразом кодирования дополнительной информации в CBOR послужило кодирование сведений о размере, разработанное Klaus Hartke для CoAP.

Этот документ включает предложения многих людей, среди которых выделяются Dan Frost, James Manger, Jeffrey Yasskin, Joe Hildebrand, Keith Moore, Laurence Lundblade, Matthew Lepinski, Michael Richardson, Nico Williams, Peter Occil, Phillip Hallam-Baker, Ray Polk, Stuart Cheshire, Tim Bray, Tony Finch, Tony Hansen и Yaron Sheffer. Benjamin Kaduk представил обширный обзор в процессе обработки IESG. Éric Vyncke, Erik Kline, Robert Wilton и Roman Danyliw предоставили дополнительные комментарии IESG, в том числе обзор директората IoT от Eve Schooler.

Адреса авторов

Перевод на русский язык

Николай Малых

nmalykh@protokols.ru

Internet Engineering Task Force (IETF)                     CJ. Bernardos
Request for Comments: 8948                                          UC3M
Category: Standards Track                                      A. Mourad
ISSN: 2070-1721                                             InterDigital
                                                           December 2020

Structured Local Address Plan (SLAP) Quadrant Selection Option for DHCPv6

Опция выбора квадранта SLAP для DHCPv6

PDF

Аннотация

Пространство 48-битовых адреса IEEE MAC1 исходно было разделено на 2 половины, одна из которых предназначена для локального использования. В 2017 г. был опубликован новый стандарт IEEE Std 802c с необязательным планом структурированных локальных адресов (Structured Local Address Plan — SLAP), задающим разный подход к распределению адресов из 4 указанных областей локального пространства MAC-адресов.

В IEEE разрабатываются протоколы для назначения адресов (IEEE P802.1CQ). В рамках IETF также ведется работа по определению новых механизмов для расширения операций DHCPv6 в части выделения локальных MAC-адресов.

Этот документ представляет расширение протоколов DHCPv6, позволяющее клиенту или ретранслятору DHCPv6 указать серверу предпочтительный квадрант SLAP, из которого могут быть назначены адреса, запрошенные клиентом или ретранслятором. Для этого определена новая опция DHCPv6 — QUAD.

Статус документа

Документ относится к категории Internet Standards Track.

Документ является результатом работы IETF² и представляет согласованный взгляд сообщества IETF. Документ прошел открытое обсуждение и был одобрен для публикации IESG³. Дополнительную информацию о стандартах Internet можно найти в разделе 2 в RFC 7841.

Информацию о текущем статусе документа, ошибках и способах обратной связи можно найти по ссылке https://www.rfc-editor.org/info/rfc8948.

Авторские права

Авторские права (Copyright (c) 2020) принадлежат IETF Trust и лицам, указанным в качестве авторов документа. Все права защищены.

К документу применимы права и ограничения, указанные в BCP 78 и IETF Trust Legal Provisions и относящиеся к документам IETF (http://trustee.ietf.org/license-info), на момент публикации данного документа. Прочтите упомянутые документы внимательно. Фрагменты программного кода, включённые в этот документ, распространяются в соответствии с упрощённой лицензией BSD, как указано в параграфе 4.e документа IETF Trust Legal Provisions, без каких-либо гарантий (как указано в Simplified BSD License).

1. Введение

Пространство 48-битовых адресов IEEE MAC разделено так, что одна половина предназначена для локального использования (бит Universal/Local (U/L) имеет значение 1). В 2017 г. был опубликован новый стандарт IEEE [IEEEStd802c], определяющий новый необязательный план структурированных локальных адресов (SLAP), который задает разный подход к назначению адресов в 4 заданных областях локальных адресов MAC. Эти 4 области, названные квадрантами SLAP, кратко описаны ниже (см. рисунок 1 и таблицу 1).

• В квадранте SLAP 01 с расширенным локальным идентификатором (Extended Local Identifier или ELI) MAC-адреса назначаются на основе 24-битового идентификатора компании (Company ID — CID), выделенного IEEE Registration Authority (RA). Оставшиеся биты указываются как расширение уполномоченным CID или протоколом, назначенным им.

• В квадранте SLAP 11 со стандартным идентификатором (Standard Assigned Identifier — SAI) MAC-адреса назначаются на основе протокола, заданного стандартом IEEE 802. Для 48-битовых MAC-адресов доступно 44 бита. Для назначения SAI в стандартах IEEE может быть задано множество протоколов. Сосуществование разных протоколов может поддерживаться ограничением доступного протоколу подпространства адресов.

• В квадранте SLAP 00 с административно назначенным идентификатором (Administratively Assigned Identifier — AAI) MAC-адреса назначаются администратором локально. Групповые пакеты IPv6 используют адреса получателей, начинающиеся с 33-33, поэтому адреса AAI из этого диапазона не следует выделять. Для 48-битовых MAC-адресов доступно 44 бита.

• В резервном квадранте SLAP 10 адреса MAC могут назначаться с помощью новых метолов (еще не заданы) или администратором как в квадранте AAI. Для 48-битовых MAC-адресов доступно 44 бита.

LSB                MSB
M  X  Y  Z  -  -  -  -
|  |  |  |
|  |  |  +------------ SLAP бит Z
|  |  +--------------- SLAP бит Y
|  +------------------ бит X (U/L) = 1 для локальных адресов
+--------------------- бит M (I/G) (unicast/group)

LSB - Least Significant Bit (младший бит)
MSB - Most Significant Bit (старший бит)

Рисунок 1. Структура 48-битового MAC-адреса (представления IEEE).

Таблица 1. Квадранты SLAP.

Квадрант	Бит Y	Бит Z	Тип локального идентификатора	Локальный идентификатор
01	0	1	Расширенный локальный идентификатор	ELI
11	1	1	Стандартное назначение	SAI
00	0	0	Административное назначение	AAI
10	1	0	Резерв	Резерв

1.1. Постановка задачи

В IEEE разрабатываются механизмы назначения адресов [IEEE-P802.1CQ-Project]. В [RFC8947] задано новое расширение DHCPv6 для обработки назначения локальных MAC-адресов. Этот документ предлагает расширение протокла DHCPv6, позволяющее клиентам и ретрансляторам DHCPv6 указать серверу предпочтительный квадрант SLAP для назначения MAC-адресов.

Ниже описаны 2 варианта, где имеется потребность выделения локальных MAC-адресов из заданного квадранта SLAP.

1.1.1. Устройства Wi-Fi (IEEE 802.11)

Сегодня большинство устройств Wi-Fi поставляются с интерфейсами, имеющими «вшитый» MAC-адрес из универсального пространства, распределяемого с помощью 24-битовых уникальных идентификаторов организаций (Organizationally Unique Identifier — OUI), выдаваемых производителям интерфейсов IEEE 802. Однако недавно возникла потребность локального (взамен универсального) назначения MAC-адресов, вызванная указанными ниже сценариями.

• IoT (Internet of Things — Интернет вещей) используют в основном устройства с ограниченными возможностями [RFC7228] в части питания, памяти и ресурсов обработки. Примерами служат датчики и исполнительные механизмы для здравоохранения или домашней автоматизации. Учитывая рост числа таких устройств, производители могут предпочесть установку для них временных MAC-адресов, используемых лишь при первой загрузке. Эти временные адреса служат лишь для отправки начальных пакетов DHCP доступным серверам. Устройствам IoT обычно нужен 1 MAC-адрес для каждого доступного сетевого интерфейса. После назначения сервером MAC-адреса устройство откажется от временного адреса. Устройства IoT для домашней автоматизации обычно не перемещаются (хотя следует отметить рост числа мобильных интеллектуальных устройств для охраны здоровья). Для таких устройств обычно подходит любой квадрант SLAP, но квадранты ELI и SAI в некоторых случаях будут лучше. Например, устройству может потребоваться адрес из CID, выделенного производителю коммуникационного устройства IoT, а не адрес из квадранта ELI.

• Приватность. Сегодня MAC-адреса позволяют раскрыть местоположение пользователя, позволяя сравнительно просто отслеживать перемещение. Одним из механизмов смягчения этой проблемы является использование случайных локальных MAC-адресов, изменяемых при подключении пользователя к другой сети. В этом варианте устройства в основном мобильны и квадрант AAI может оказаться лучшим для назначения адресов, поскольку здесь проще обеспечить их случайный характер и не требуется сохранение адреса при смене сети.

1.1.2. Гипервизор — возможность перемещения функций

В больших средах виртуализации могут быть активны тысячи виртуальных машин (VM), которые обычно управляются гипервизором, запускающим и останавливающим VM при необходимости. Обычно гипервизор назначает и новые MAC-адреса для VM. Если для этого служит сервер DHCP, гипервизор выступает клиентом DHCP и запрашивает у доступных серверов DHCP назначение одного или множества (блок) MAC-адресов. Гипервизор не использует эти адреса для себя, а назначает их создаваемым VM. В современных ЦОД часто используется деление сети на области, каждая из которых назначает свои адреса. В этом варианте следует рассмотреть два случая, описанных ниже.

• Перемещаемые функции. Если VM (обеспечивающую функцию) нужно перенести в другую область ЦОД (например, для обслуживания, обеспечения отказоустойчивости, перемещения конечного пользователя и пр.), вместе с VM нужно перенести ее сетевой контекст, включая MAC-адреса VM. Поскольку назначение адресов из квадрантов ELI/SAI подчиняется правилам IEEE Std 802c, они лучше подходят для обеспечения уникальности MAC-адресов в рамках ЦОД.

• Неперемещаемые функции. Если VM не перемещается в другую область ЦОД, связанных с MAC-адресом требований не возникает. В этом случае проще выделять адреса из квадранта AAI, которые не обязаны быть уникальными в рамках множества ЦОД (т. е. каждая область может управлять своим назначением MAC-адресов без глобальной проверки дубликатов).

2. Терминология

Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не следует (SHALL NOT), следует (SHOULD), не нужно (SHOULD NOT), рекомендуется (RECOMMENDED), не рекомендуется (NOT RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе интерпретируются в соответствии с BCP 14 [RFC2119] [RFC8174] тогда и только тогда, когда они выделены шрифтом, как показано здесь.

Когда возможно, в документе используются относящиеся к задаче термины из [RFC8415]. Ниже приведены определения терминов, которые отличаются от указанного документа или введены заново.

address — адрес

Если явно не указано иное, это адрес канального уровня (MAC-адрес) [IEEEStd802] размером 6 или 8 октетов.

address block — блок адресов

Множество последовательных адресов канального уровня. Блок указывается первым адресом и числом дополнительно выделяемых адресов. Один адрес можно представить блоком из этого адреса и 0 дополнительных.

client — клиент

Узел, заинтересованный в получении адреса канального уровня. Он реализует базовые механизмы DHCP, описанные в [RFC8415], и поддерживает новые опции, заданные [RFC8947] (IA_LL и LLADDR), а также этим документом (QUAD). Клиент может поддерживать назначение адресов IPv6 и делегирование префиксов в соответствии с [RFC8415].

IA_LL

Identity Association для Link-Layer Address — ассоциация отождествления (IA — identity association), используемая для запроса или назначения адресов канального уровня (параграф 11.1 [RFC8947]).

LLADDR

Опция адреса канального уровня, используемая для запроса или назначения блока адресов (параграф 11.2 [RFC8947]).

relay — ретранслятор

Узел, служащий посредником при доставке сообщений DHCP между клиентами и серверами. Ретранслятор на основе локальной информации и правил может указывать предпочтительный квадрант SLAP в передаваемой серверу опции QUAD. Ретранслятор реализует базовую фцнкциональность агента трансляции DHCPv6 [RFC8415].

server — сервер

Узел, который поддерживает назначение адресов канального уровня и способен отвечать на запросы клиентов. Узел реализует базовую функциональность сервера DHCP [RFC8415] и поддерживает новые опции, заданные [RFC8947] (IA_LL и LLADDR), а также этим документом (QUAD). Сервер может поддерживать назначение адресов IPv6 и делегирование префиксов в соответствии с [RFC8415].

3. Расширения DHCPv6

3.1. Назначение адресов из квадранта SLAP, указанного клиентом

Далее описаны операции протокола для выбора клиентом предпочтительного квадранта SLAP с помощтю сигнальных процедур DHCPv6, описанных в [RFC8947] и показанных на рисунке 2.

+--------+                            +--------+
| Клиент |                            | Сервер |
| DHCPv6 |                            | DHCPv6 |
+--------+                            +--------+
    |                                      |
    +----1. Solicit(IA_LL(LLADDR,QUAD))--->|
    |                                      |
    |<--2. Advertise(IA_LL(LLADDR,QUAD))---+
    |                                      |
    +---3. Request(IA_LL(LLADDR,QUAD))---->|
    |                                      |
    |<------4. Reply(IA_LL(LLADDR))--------+
    |                                      |
    .     (завершен отсчет таймера)        .
    |                                      |
    +---5. Renew(IA_LL(LLADDR,QUAD))------>|
    |                                      |
    |<-----6. Reply(IA_LL(LLADDR))---------+
    |                                      |

Рисунок 2. Поток сигнализации DHCPv6 (клиент-сервер).

1. Адреса канального уровня (MAC) выделяются блоками, начиная с одного. Для запроса адресов клиент передает сообщение Solicit с опцией IA_LL, которая должна включать опцию LLADDR. Для указания предпочтительного квадранта SLAP опция IA_LL включает новую опцию OPTION_SLAP_QUAD в поле IA_LL-option (наряду с опцией LLADDR).

2. Сервер при получении опции IA_LL в сообщении Solicit проверяет ее содержимое. Для каждой записи в OPTION_SLAP_QUAD в порядке значений поля preference (от большего к меньшему) сервер проверяет наличие настроенного пула адресов MAC, соответствующего запрошенному квадранту, и наличие доступного блока адресов запрошенного размера. Если подходящие адреса найдены, сервер передает сообщение Advertise с опцией IA_LL, содержащей опцию LLADDR, которая указывает предлагаемые адреса. Если у сервера есть блк адресов в указанном квадранте, должны предлагаться адреса из этого квадранта. Если соответствующих запросу клиента адресов нет у сервера, ему следует возвратить опцию IA_LL с адресами из поддерживаемого сервером квадранта (в соответствии с локальной политикой выбора квадранта). Если у сервера есть пул адресов в запрошенном квадранте, но в нем нет доступных адресов, сервер должен вернуть опцию IA_LL, где Status Code имеет значение NoAddrsAvail.

3. Клиент ждет от доступных серверов откликов Advertise и выбирает один сервер, как указано в параграфе 18.2.9 [RFC8415]. Клинету не следует выбирать сервер, которые не анонсировал адреса из запрошенного квадранта. Затем клиент передает сообщение Request, включающее контейнер IA_LL с опцией LLADDR, скопированной из сообщения Advertise от выбранного сервера, указав предпочтительные квадранты SLAP в новой опции QUAD IA_LL.

4. При получении Request с контейнером IA_LL сервер назначает запрошенные адреса, при этом он может изменить выделение (например, уменьшить блок). Затем сервер создает и отправляет клиенту сообщение Reply. При получении Reply клиент анализирует контейнер IA_LL и может начинать использование назначенных ему адресов. Отметим, что клиент, включивший опцию Rapid Commit в сообщение Solicit, может получить в ответ сообщение Reply и пропустить описанные выше этапы Advertise и Request (следуя стандартным процедурам DHCPv6).

5. Предполагается, что клиент будет периодически обновлять адреса канального уровня по таймерам T1 и T2. Этот механизм можно отключить административно путем отправки сервером «бесконечного» (infinity) значения для T1 и T2 (см. раздел 7.7 в [RFC8415]). Клиент передает опцию Renew по таймеру T1, включая предпочтительные квадранты в новую опцию QUAD IA_LL, чтобы в случае неспособности сервера расширить срок действия имеющихся адресов он знал предпочтительные квадранты для выделения других адресов.

6. Сервер отвечает сообщением Reply с опцией IA_LL, включающей опцию LLADDR с расширенным сроком.

Клиенту следует проверять принадлежность MAC-адреса к одному из запрошенных квадрантов. Клиент может повторить процесс выбора сервера DHCP.

3.2. Назначение адресов из квадранта SLAP, указанного ретранслятором

Далее описана работа протокола по выбору предпочтительного квадранта по запросу ретранслятора с помощью сигнальных процедур DHCPv6, описанных в [RFC8947]. Это полезно при работе сервера DHCPv6 в большой инфраструктуре, разделенной на области с разными требованиями. Поток сигналов показан на рисунке 3.

1. +--------+                  +--------+                     +--------+
   | Клиент |                  |Ретранс.|                     | Сервер |
   | DHCPv6 |                  | DHCPv6 |                     | DHCPv6 |
   +--------+                  +--------+                     +--------+
      |                            |                                |
      +-----1. Solicit(IA_LL)----->|                                |
      |                            +----2. Relay-forward            |
      |                            |    (Solicit(IA_LL),QUAD)------>|
      |                            |<---3. Relay-reply              |
      |                            |    (Advertise(IA_LL(LLADDR)))--+
      |<4. Advertise(IA_LL(LLADDR))+                                |
      |-5. Request(IA_LL(LLADDR))->|                                |
      |                            +-6. Relay-forward               |
      |                            | (Request(IA_LL(LLADDR)),QUAD)->|
      |                            |                                |
      |                            |<--7. Relay-reply               |
      |                            |   (Reply(IA_LL(LLADDR)))-------+
      |<--8. Reply(IA_LL(LLADDR))--+                                |
      |                            |                                |
      .               (завершен отсчет таймера)                     .
      |                            |                                |
      +--9. Renew(IA_LL(LLADDR))-->|                                |
      |                            |--10. Relay-forward             |
      |                            |  (Renew(IA_LL(LLADDR)),QUAD)-->|
      |                            |<---11. Relay-reply             |
      |                            |     (Reply(IA_LL(LLADDR)))-----+
      |<--12. Reply(IA_LL(LLADDR))-+                                |
      |                            |                                |

   Рисунок 3. Поток сигнализации DHCPv6 (клиент-ретранслятор-сервер).

   
   Адреса канального уровня (MAC) выделяются блоками, начиная с одного. Для запроса адресов клиент передает сообщение Solicit с опцией IA_LL, которая должна включать опцию LLADDR.

2. Ретранслятор DHCP получает сообщение Solicit и инкапсулирует его в Relay-forward. Ретранслятор на основе локальных сведений и правил включает в сообщение Relay-forward опцию QUAD с предпочтительным квадрантом. Ретранслятор может знать, какой квадрант следует запросить, из локальной конфигурации (например, обслуживаемая сеть содержит лишь устройства IoT и запрашивать следует ELI/SAI) или иных данных. Отметим, что при передаче клиентом множества опций IA_LL в одном сообщении, ретранслятор DHCP может добавить лишь один экземпляр опции QUAD.

3. При получении ретранслированного сообщения с опцией IA_LL сервер проверяет содержимое экземпляров OPTION_SLAP_QUAD в сообщении Relay-forward и вложенном в него клиентском сообщении. В зависимости от правил сервера выбирается экземпляр опции для обработки при выборе (см. конец этот параграфа). Для каждой записи в OPTION_SLAP_QUAD в порядке значений поля (от высшего к низшему) сервер проверяет наличие настроенного пула адресов MAC, соответствующего запрошенному квадранту, и наличие доступного блока адресов запрошенного размера. Если подходящие адреса найдены, сервер передает сообщение Advertise с опцией IA_LL, содержащей опцию LLADDR, которая указывает предлагаемые адреса. Это сообщение передается ретранслятору в сообщении Relay-reply. Если сервер поддерживает семантику предпочтительного квадранта из опции QUAD и поддерживает блок адресов в этом квадранте, он должен предлагать адреса из запрошенного квадранта. Серверу следует применять содержимое представленной ретранслятором опции QUAD для всех клиентских IA_LL, если в конфигурации не задано иное.

4. Ретранслятор передает клиенту полученное сообщение Advertise.

5. Клиент ждет от доступных серверов откликов Advertise и выбирает один сервер, как указано в параграфе 18.2.9 [RFC8415]. Затем клиент передает сообщение Request, включающее контейнер IA_LL с опцией LLADDR, скопированной из сообщения Advertise от выбранного сервера.

6. Ретранслятор пересылает полученное сообщение Request в сообщении Relay-forward, доавляя опцию QUAD IA_LL с предпочитаемым квадрантом.

7. При получении пересланного сообщения Request с контейнером IA_LL сервер назначает запрошенные адреса, которые он может изменить. Затем сервер создает и передает сообщение Reply ретранслятору в Relay-reply.

8. При получении сообщения Reply клиент разбирает контейнер IA_LL и может начать использование адресов.

9. Предполагается, что клиент будет периодически обновлять адреса канального уровня по таймерам T1 и T2. Этот механизм можно отключить административно путем отправки сервером «бесконечного» (infinity) значения для T1 и T2 (см. раздел 7.7 в [RFC8415]). Клиент передает опцию Renew по таймеру T1.

10. Это сообщение пересылается ретранслятором в сообщении Relay-forward с опцией QUAD IA_LL, указывающей предпочтительный квадрант.

11. Сервер отвечает сообщением Reply с опцией IA_LL, включающей опцию LLADDR с расширенным сроком, которое передается в сообщении Relay-reply.

12. Ретранслятор передает сообщение Reply клиенту.

Серверу следует реализовать конфигурационный параметр для обработки случаев, конда клинетское сообщение DHCP содержит экземпляр OPTION_SLAP_QUAD а ретранслятор добавляет второй экземпляр в своем сообщении Relay-forward. Этот параметр настраивает сервер на обработку одного из экземпляров QUAD. Рекомендуется по умолчанию обрабатывать опцию их запроса клиента.

Клиент может проверить принадлежность полученного MAC-адреса к желаемому квадранту и принять на основе этой проверки решение об использовании или настройке полученного адреса.

4. Определение опции DHCPv6

4.1. Опция QUAD

Опция QUAD служит для задания предпочтений при выборе квадрантов в опции IA_LL. Опция должна инкапсулироваться в поле IA_LL-options опции IA_LL или в сообщение Relay-forward. Формат QUAD показана на рисунке 4.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       OPTION_SLAP_QUAD        |          option-len           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   quadrant-1  |    pref-1     |   quadrant-2  |    pref-2     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.                                                               .
.                                                               .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  quadrant-n-1 |   pref-n-1    |   quadrant-n  |    pref-n     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 4. Формат опции QUAD.

option-code

OPTION_SLAP_QUAD (140).

option-len

Удвоенное число пар (quadrant, preference). Это 2-байтовое поле указывает общий размер всех пар (quadrant, preference), включенных в опцию.

quadrant-n

Идентификатор квадранта (0- AAI, 1 — ELI, 2 — резерв IEEE [IEEEStd802c], 3 — SAI). Каждый квадрант должен включаться в опцию не более 1 раза. Поле имеет размер 1 байт.

pref-n

Предпочтение для quadrant-n (большее значение для большего приоритета). Поле имеет размер 1 байт.

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

Если для нескольких квадрантов указано одинаковое предпочтение, сервер может выбрать квадрант (при условии наличия адресов в нескольких квадрантах с одинаковым предпочтением). assign addresses from all or some of the quadrants with the same assigned preference). Отметим, что это не просто список квадрантов, упорядоченных по предпочтению, а список с явными значениями предпочтения. Таким образом, может поддерживаться случай, когда у клиента действительно нет предпочтения среди двух или трех квадрантов и он отдает решение серверу.

Если клиент или ретранслятор задает OPTION_SLAP_QUAD, сервер должен использовать значения quadrant-n/pref-n для упорядочения выбора квадрантов. Если сервер может предоставить адреса в одном из указанных квадрантов, ему следует выполнить это назначение. Если у сервера нет пула адресов, соответствующего какому-либо из указанных значений quadrant-n, или есть пул в нужном квадранте, но в нем нет доступных адресов, сервер должен вернуть опцию IA_LL со статусом NoAddrsAvail.

От клиента и ретранслятора не требуется упорядочивать значения quadrant/pref определенным образом, поэтому серверу недопустимо предполагать, что quadrant-1/pref-1 имеет высший приоритет (кроме случая, когда есть лишь один набор значений).

В случаях, когда сервер не может быть настроен с пулом адресов, соответствующим предпочтениям клиента или ретранслятора, тем следует указать в опции QUAD все квадранты, чтобы гарантировать получение клиентом адресов, если они имеются. Указание всех квадрантов приводит также к тому, что сервер, поддерживающий опцию QUAD, отвечает как сервер без поддержки опции, т. е. может возвратить адреса из любого доступного квадранта.

5. Взаимодействие с IANA

Агентство IANA выделило код опции QUAD (140) из субреестра Option Codes в реестре Dynamic Host Configuration Protocol for IPv6 (DHCPv6), доступном по ссылке http://www.iana.org/assignments/dhcpv6-parameters.

   Value:  140
   Description:  OPTION_SLAP_QUAD
   Client ORO:  No
   Singleton Option:  Yes
   Reference:  RFC 8948

6. Вопросы безопасности

Вопросы безопасности и конфиденциальности DHCPv6 рассмотрены в [RFC8415] и [RFC7227], а безопасность IPv6 — в [RFC8200].

Вопросы безопасности назначения адресов канального уровня с помощью DHCP рассмотрены в [RFC8947].

7. Литература

7.1. Нормативные документы

[RFC2119] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC8174] Leiba, B., «Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words», BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., Richardson, M., Jiang, S., Lemon, T., and T. Winters, «Dynamic Host Configuration Protocol for IPv6 (DHCPv6)», RFC 8415, DOI 10.17487/RFC8415, November 2018, <https://www.rfc-editor.org/info/rfc8415>.

[RFC8947] Volz, B., Mrugalski, T., and CJ. Bernardos, «Link-Layer Address Assignment Mechanism for DHCPv6», RFC 8947, DOI 10.17487/RFC8947, December 2020, <https://www.rfc-editor.org/info/rfc8947>.

7.2. Дополнительная литература

[IEEE-P802.1CQ-Project] IEEE, «P802.1CQ — Standard for Local and Metropolitan Area Networks: Multicast and Local Address Assignment», <https://standards.ieee.org/project/802_1CQ.html>.

[IEEEStd802] IEEE, «IEEE Standard for Local and Metropolitan Area Networks: Overview and Architecture», IEEE Std 802-2014, DOI 10.1109/IEEESTD.2014.6847097, June 2014, <https://doi.org/10.1109/IEEESTD.2014.6847097>.

[IEEEStd802c] IEEE, «IEEE Standard for Local and Metropolitan Area Networks: Overview and Architecture — Amendment 2: Local Medium Access Control (MAC) Address Usage», IEEE Std 802c-2017, DOI 10.1109/IEEESTD.2017.8016709, August 2017, <https://doi.org/10.1109/IEEESTD.2017.8016709>.

[RFC7227] Hankins, D., Mrugalski, T., Siodelski, M., Jiang, S., and S. Krishnan, «Guidelines for Creating New DHCPv6 Options», BCP 187, RFC 7227, DOI 10.17487/RFC7227, May 2014, <https://www.rfc-editor.org/info/rfc7227>.

[RFC7228] Bormann, C., Ersue, M., and A. Keranen, «Terminology for Constrained-Node Networks», RFC 7228, DOI 10.17487/RFC7228, May 2014, <https://www.rfc-editor.org/info/rfc7228>.

[RFC7548] Ersue, M., Ed., Romascanu, D., Schoenwaelder, J., and A. Sehgal, «Management of Networks with Constrained Devices: Use Cases», RFC 7548, DOI 10.17487/RFC7548, May 2015, <https://www.rfc-editor.org/info/rfc7548>.

[RFC8200] Deering, S. and R. Hinden, «Internet Protocol, Version 6 (IPv6) Specification», STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, <https://www.rfc-editor.org/info/rfc8200>.

Приложение A. Пример использования механизма выбора квадранта

В этом приложении рассмотрены некоторые примеры использования механизмов предпочтения квадрантов.

В качестве первого примера рассмотрим вариант IoT. Устройство IoT может самостоятельно выбрать квадрант SLAP для использования локального MAC-адреса, используя для выбора приведенные ниже сведения.

• Тип развертывания IoT, например, промышленное, домашнее, сельское и т. п. Для небольших систем, например, в доме, устройство IoT может само выбрать квадрант AAI (это возможно даже без DHCP путем выбора случайного адреса самим устройством). Для больших систем, таких как промышленные, где могут быть тысячи устройств, могут использоваться квадранты ELI или SAI.

• Мобильность. Если устройство IoT может перемещаться, оно может предпочесть выбор квадрантов SAI или AAI для минимизации адресных конфликтов при перемещении между сетями. Если устройство знает, что оно не будет перемещаться, лучшим решением может оказаться квадрант ELI.

• Управляемость. В зависимости от того, управляется ли устройство IoT в течение своего срока действия или его конфигурацию нельзя изменить [RFC7548], решение о выборе подходящего квадранта может меняться. Например, если устройство IoT может управляться (например, настраиваться) и топология сети может меняться в течение срока службы (например, в результате изменения системы при добавлении устройств), это может влиять на выбор предпочтительного квадранта (например, для предотвращения будущих конфликтов).

• Срок работы от батареи. В зависимости от возможной продолжительности работы устройства предпочтительный квадрант может изменяться (например, для минимизации возможных конфликтов).

Предыдущие параметры служат аспектами, которые производитель или администратор могут учитывать при выборе правил запроса MAC-адресов устройствами IoT (выбор квадранта SLAP). Устройства IoT обычно очень ограничены в ресурсах, поэтому в них может применяться лишь очень простой процесс выбора на основе заданных предпочтений.

Далее рассматривается вариант Wi-Fi с учетом, например, подключения ноутбука или смартфона к сети с использованием встроенного MAC-адреса. Из соображений конфиденциальности и безопасности устройство может пожелать использовать локальный MAC-адрес. При этом для устройства можно использовать разные параметры и данные контекста — квадрант SLAP для назначения локального MAC-адреса, условия смены адреса (например, может потребоваться неоднократная смена). Эта информация может включать перечисленные ниже аспекты, а также иное.

• Тип сети, к которой подключается устройство — общественная, рабочая, домашняя.

• Является ли сеть доверенной.

• Является ли подключение к сети первым.

• Местоположение сети.

• Мобильность, т. е. возможность смены точки подключения устройства к сети.

• Сетевой профиль операционной системы (OS), включая параметры безопасности и доверия. Многие современные OS хранят метаданные, связанные с сетями, к которым устройство может подключаться, например, уровень доверия, заданный для сети пользователем или администратором. Эта информация служит для настройки повердения устройства в плане анонсирования себя в сети, настройки межсетевого экранирования и т. п. Но эта информация может также служить для решения вопроса об использовании локального MAC-адреса, выборе для него квадранта SLAP и частоте назначения такого адреса.

• Триггеры приложений, связанные с конфиденциальностью местоположения. Приложение может запросить у OS максимальную конфиденциальность местоположения (в силу прилоды этого приложения), а это может потребовать от OS использования или смены локального MAC-адреса.

Эта информация может служить устройству для выбора квадранта SLAP. Например, если устройство перемещается (скажем в общественной сети аэропорта), вполне вероятна смена точки доступа, поэтому разумно минимизировать вероятность конфликта адресов, выбрав квадрант SAI или AAI. Если устройство подключено к доверенной сети и его перемещение не предполагается (например, на работе), лучшим решением может оказаться квадрант ELI. Это лишь несколько примеров использования указанной выше информации при выборе квадранта.

Кроме того, информацию можно использовать для инициирования смены MAC-адреса с целью сохранения конфиденциальности местоположения. Смену квадранта SLAP можно также использовать для предотвращения отслеживания устройства.

В варианте ЦОД гипервизор может запросить выделение локальных MAC-адресов для виртуальных машин. Как и в описанных раньше вариантах, гипервизор может выбрать предпочтительный квадрант SLAP, используя данные системы управления облаком или менеджера виртуальной инфраструктуры. Примеры таких данных приведены ниже.

• Перемещаемость VM. Возможность переноса функции, реализуемой VM, на другой физический сервер может влиять на выбор предпочтительного квадрант SLAP, поскольку квадранты ELI и SAI лучше подходят для поддержки переноса в крупных ЦОД.

• Характеристики связности VM. Например, этом может быть автономная машина, часть пула или часть цепочки услуг. Если характеристики связности VM известны, гипервизор может использовать их при выборе квадранта SLAP.

Благодарности

Авторы благодарят Bernie Volz за полезные замечания к документу. Спасибо также Ian Farrer, Tomek Mrugalski, Éric Vyncke, Tatuya Jinmei, Carl Wallace, Ines Robles, Ted Lemon, Jaime Jimenez, Robert Wilton, Benjamin Kaduk, Barry Leiba, Alvaro Retana, Murray Kucherawy за подробные и полезные рецензии. Спасибо Roger Marks и Antonio de la Oliva за комментарии, связанные с работой IEEE, и ссылки.

Разработка этого документа поддержана проектами H2020 5GROWTH (Grant 856709) и 5G-DIVE (Grant 859881).

Адреса авторов

Carlos J. Bernardos

Universidad Carlos III de Madrid

Av. Universidad, 30

28911 Leganes, Madrid

Spain

Phone: +34 91624 6236

Email: cjbc@it.uc3m.es

URI: http://www.it.uc3m.es/cjbc/

Alain Mourad

InterDigital Europe

Email: Alain.Mourad@InterDigital.com

URI: http://www.InterDigital.com/

Перевод на русский язык

Николай Малых

nmalykh@protokols.ru