RFC 6551 Routing Metrics Used for Path Calculation in Low-Power and Lossy Networks

Internet Engineering Task Force (IETF)                  JP. Vasseur, Ed.
Request for Comments: 6551                                 Cisco Systems
Category: Standards Track                                    M. Kim, Ed.
ISSN: 2070-1721                           Corporate Technology Group, KT
                                                               K. Pister
                                                           Dust Networks
                                                               N. Dejean
                                                              Elster SAS
                                                              D. Barthel
                                                   France Telecom Orange
                                                              March 2012

Routing Metrics Used for Path Calculation in Low-Power and Lossy Networks

Метрика маршрутов для расчёта путей в сети LLN

PDF

Аннотация

Сети LLN¹ отличаются от традиционных кабельных и специализированных (ad hoc) сетей и требуют спецификации новой метрики маршрутов и ограничения. В отличие от типичных протоколов IGP², где метрикой служит число интервалов пересылки или метрика каналов, этот документ задаёт набор параметров маршрутной метрики узлов и каналов, а также ограничений, подходящих для сетей LLN, использующих протокол маршрутизации RPL³.

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

Этот документ содержит проект стандарта Internet (Internet Standards Track).

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

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

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

Авторские права ((c) 2012) принадлежат 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. Введение

В этом документе используется терминология, определённая в [ROLL-TERMS].

Сети со слабым электропитанием и потерями (LLN) отличаются по характеристикам маршрутизации от традиционных кабельных и специализированных сетей, описанных в [RFC5548], [RFC5673], [RFC5826], [RFC5867].

Протоколы IGP, такие как OSPF ([RFC2328]) и IS-IS ([RFC1195]), используют статические количественные параметры каналов в качестве метрики маршрутов. Другие механизмы, подобные MPLS TE4 (см. [RFC2702] и [RFC3209]), применяют иные атрибуты соединений, такие как доступная для резервирования пропускная способность (динамический параметр) или близость (по большей части статичный параметр) для расчёта кратчайших путей с учётом ограничений TE LSP⁵.

В этом документе заданы метрики маршрутов и ограничения для использования при расчёте путей протоколом маршрутизации RPL, заданным в [RFC6550].

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

Определённые здесь метрики и ограничения передаются в объектах, которые необязательны с точки зрения реализации RPL. Это позволяет реализациям включать произвольный набор функций (метрик, ограничений), заданных в этом документе. Конкретные наборы метрик, ограничений и других необязательных параметров RPL для применения в ключевых средах будут задаваться в форме профилей применимости, разрабатываемых рабочей группой ROLL. Отметим, что RPL может совсем не использовать метрику, обходясь предметной функцией OF, заданной в [RFC6552].

RPL является протоколом на основе векторов удалённости, который создаёт направленные ациклические графы (Directed Acyclic Graph или DAG) на основе маршрутной метрики и ограничений. Правила создания DAG заданы в [RFC6550]

• Корень ориентированного на адресата графа (Destination-Oriented Directed Acyclic Graph или DODAG) в соответствии с [RFC6550] может анонсировать маршрутные ограничения, служащие «фильтрами» для исключения каналов и узлов, не соответствующих конкретным требованиям. Например, может требоваться прохождение пути лишь через устройства с питанием от сети или каналы, обеспечивающие определённую надёжность или имеющие конкретный «цвет», отражающий заданные пользователем характеристики (скажем, поддержка шифрования на канале).

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

Лучшим считается путь, соответствующий всем ограничениям (при наличии) и имеющий наименьшую стоимость в части заданной метрики. Его также называют кратчайшим путём с ограничениями (при их наличии). Метрики маршрута можно характеризовать по трём категориям:

• метрика каналов и метрика узлов;

• количественная и качественная метрика;

• динамическая и статическая метрика.

В документах с требованиями к маршрутизации ([RFC5673], [RFC5826], [RFC5548], [RFC5867]) отмечено, что при расчёте пути должна обеспечиваться возможность учёта множества ограничений и параметров метрики узла.

Некоторые характеристики канала или узла (например, надёжность канала, запас питания на узле) могут служить в RPL ограничениями или метрикой маршрута (иногда в том и другом качестве). Например, может рассчитываться путь без каналов с малой надёжностью (ограничение) или путь, в котором большинство каналов обеспечивают заданный уровень надёжности (метрика). Этот документ обеспечивает гибкость использования параметров узлов и каналов в качестве ограничений и/или метрики.

Применение метрики и ограничений каналов и узлов не является исключительным. Например, можно указать число интервалов пересылки (hop count) в качестве метрики пути и ограничения (максимальное число пересылок).

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

Следует отметить, что использование динамической метрики не является новинкой и было опробовано в ARPANET 2 (см. [Zinky1989]). Применение динамической метрики нетривиально и требует уделять внимание изменению параметров, поскольку оно может вести к нестабильности маршрутизации. За прошедшие годы накоплен большой опыт работы с динамической метрикой маршрутов, которая была развёрнута в ряде сетей (не IP).

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

Набор метрик и ограничений, используемых при развёртывании RPL, передаётся по графу DAG, создаваемому в соответствии с предметной функцией OF (правила построения DAG), а метрика и ограничения анонсируются в информационном объекте DIO (DODAG Information Object), заданном в [RFC6550]. RPL можно использовать для построения графов DAG с разными характеристиками. Например, можно создать DAG с максимальной надёжностью, используя метрику надёжности каналов для выбора пути. Другим примером может служит учёт ограничений по питанию узлов (например, предпочтение узлов с питанием от сети) при построении DAG для исключения узлов с батарейным питанием при оптимизации по пропускной способности.

Спецификация предметной функции OF, служащей для расчёта DAG, создаваемого RPL, выходит за рамки этого документа. Здесь определены метрики и ограничения, не связанные с OF. Таким образом, базовая OF может задавать, например, правила выбора родителей в DAG, числа резервных родителей и т. п. и её можно применять с метрикой и ограничениями, в этом документе.

Некоторые типы метрики агрегируются или записываются. Агрегируемая метрика корректируется по мере прохождения DIO через граф DAG. Например, если метрикой служит число интервалов пересылки (hop), каждый узел обновляет стоимость пути, отражая общее число пересылок в DAG. Для записываемой метрики каждый узел добавляет субобъект, отражающий локальную оценку метрики, записывая локальный уровень качества канала. Для ограничения числа субобъектов может оказаться желательным использование счётчиков (например, число каналов с неким уровнем качества), позволяющее сократить размер сообщения. При получении сообщения DIO от набора родителей узел может в соответствии с предметной функцией OF и локальными правилами принять решение о выборе родительского узла (например, по наибольшему числу каналов с заданным уровнем надёжности.

Отметим, что метрика маршрутов и ограничения, заданные в документе, не связаны с каким-либо конкретным канальным уровнем. Для точного учёта значения метрики каналов (кабельных, беспроводных, PLC) может применяться внутренний API между уровнем контроля доступа к среде (Medium Access Control или MAC) и RPL.

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

Имеются различные варианты опций, которые могут применяться в разных развёртываниях. Реализации должны чётко указывать включаемые опции и принятые по умолчанию параметры, а также настраиваемые опции. Рабочая группа ROLL будет выпускать заявления о применимости для разъяснения опций, применимых к конкретным вариантам развёртывания, описанным в [RFC5673], [RFC5826], [RFC5548] и [RFC5867].

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

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

2. Формат объектов

2.1. Контейнер метрики DAG

Метрика маршрутов и ограничения передаются в объектах DAG Metric Container [RFC6550]. Если в DAG Metric Container имеется несколько метрик и/или ограничений, выбор «лучшего» может задаваться функцией OF.

Объекты Routing Metric/Constraint представляют метрику или ограничения определённого типа. Они могут указываться в любом порядке внутри DAG Metric Container (определён в [RFC6550]). Контейнер содержит один или несколько байтов с общим заголовком.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Routing-MC-Type|Res Flags|P|C|O|R| A   |  Prec |    Length     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
//                        (тело объекта)                       //
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 1. Базовый объект маршрутной метрики или ограничений.

Тело объекта содержит один или несколько субобъектов, определённых в этом документе. Объект может включать TLV⁷, которые сами содержат TLV.

Routing-MC-Type (Routing Metric/Constraint Type – 8 битов)

Поле типа метрики или ограничений однозначно указывает объект Routing Metric/Constraint из реестра IANA.

Length (8 битов)

Размер тела объекта в байтах (0 – 255).

Res Flags (16 битов)

Флаги объекта Routing Metric/Constraint поддерживаются IANA. Не выделенные биты считаются резервными (отправитель должен устанавливать 0, а получатель должен игнорировать их).

Ниже перечислены определённые в настоящее время биты поля Routing Metric/Constraint Flag.

P

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

C

Установленный флаг указывает, что объект Routing Metric/Constraint задаёт к ограничение (иначе метрику).

O

Служит лишь для маршрутных ограничений (C = 1). Установленный флаг указывает необязательность указанных в теле объекта ограничения. В противном случае они обязательны. При C = 0 флаг O должен сбрасываться при передаче и игнорироваться при получении.

R

Относится лишь к метрике маршрутов (C=0) и должен сбрасываться при C=1. Установка флага указывает, что метрика маршрута записывается на пути, а при сброшенном флаге метрика агрегируется.

A (3 бита)

Поле A относится лишь к метрике и служит для указания типа агрегирования метрики:

• A=0 – аддитивная метрика;

• A=1 – максимальное значение;

• A=2 – минимальное значение;

• A=3 – мультипликативная метрика.

Поле A не имеет смысла при установленном флаге C (объект Routing Metric/Constraint задаёт ограничения) и действительно лишь при сброшенном флаге R. В иных случаях поле A должно сбрасываться (0) при передаче, а получатель должен игнорировать его.

Prec (4 бита)

Поле Prec указывает приоритет данного объекта Routing Metric/Constraint по отношению к другим объектам в контейнере при наличии их в DAG Metric Container. Поле может иметь значение от 0 (высший приоритет) до 15.

Пример 1

DAG формируется RPL, где все узлы имеют питание от сети, а лучшим является путь с наименьшим ожидаемым совокупным числом передач (expected transmission count или ETX). В этом случае DAG Metric Container содержит два объекта Routing Metric/Constraint, один из которых указывает метрику ETX и имеет заголовок (C=0, O=0, A=00, R=0), а другой – ограничение Node Energy и имеет заголовок (C=1, O=0, A=00, R=0). RPL Instance может использовать объект метрики для указания максимума (A=1) или минимума (A=2). Например, если лучший путь выбирается по отсутствию соединений с низким качеством, метрика указывает максимум (A=1) (большее значение ETX говорит о меньшем качестве канала) – когда сообщение DIO с метрикой качества канала (ETX) обрабатывается узлом, каждый узел, выбравший анонсирующий узел в качестве родителя, обновляет значение в объекте метрики, помещая туда своё локальное значение ETX, если оно выше имеющегося. Что касается указанного ограничения, тело объекта сдержит ограничение Node Energy, определённое в параграфе 3.1 и задающее требование питания узла от сети, – если это ограничение, заданное в сообщении DIO, не выполняется, анонсирующий узел просто не выбирается в качестве родителя, обрабатывающего сообщение DIO.

Пример 2

DAG формируется RPL, где метрикой служит уровень качества канала (раздел 4) и эти уровни должны записываться в пути. DAG Metric Container содержит объект Routing Metric/Constraint с заголовком (C=0, O=0, A=00, R=1) и множеством субобъектов.

Объект Routing Metric/Constraint может также включать один или несколько объектов TLV с наборами данных. Все Routing Metric/Constraint TLV имеют структуру:

Type: 1 байт;

Length: 1 байт;

Value: переменный размер.

Routing Metric/Constraint TLV содержит 1-байтовое поле типа, 1-байтовое поле размера и поле значения. Поле TLV указывает размер значения в байтах (0 – 255). Нераспознанные TLV должны игнорироваться без прерывания распространения в DIO, созданных принимающим узлом.

Агентство IANA поддерживает коды для всех TLV, передаваемых в объектах метрики и ограничений. Пространство кодов объектов Routing Metric/Constraint описано в разделе 6.

2.2. Использование нескольких контейнеров DAG Metric

Поскольку размер опций RPL задаётся одним октетом, он не может быть больше 255 байтов, что применимо и для DAG Metric Container. В подавляющем большинстве случаев анонсируемые метрики маршрутов и ограничения не требуют большего размера, однако иногда возникают обстоятельства, требующие большего пространства. В таких случаях для предотвращения переполнения, как указано в [RFC6550], маршрутная метрика может передаваться в нескольких объектах DAG Metric Container. Далее в этом документе использование нескольких объектов DAG Metric Container рассматривается как один большой объект DAG Metric Container.

2.3. Применение метрики

Когда DAG Metric Container содержит одну агрегированную метрику (скаляр), порядок при выборе лучшего пути неявно выводится из типа метрики. Например, более низкое значение лучше для типов Hop Count, Link Latency, ETX, а более высокое – для Node Energy и Throughput. Примером использования простой агрегированной метрики является оптимизация маршрутов по энергетическим возможностям узлов. Метрика Node Energy (поле E_E), определённая в параграфе 3.2, агрегируется на пути явной функцией min (поле A), а лучший путь выбирается предполагаемой функцией Max, поскольку метрикой служит Energy.

Когда DAG Metric Container содержит несколько агрегированных метрик, конфликты разрешаются в соответствии с приоритетом в полях Prec. Примером использования нескольких агрегированных метрик является выбор Hop Count как основного критерия, Link Quality Level (LQL) – как вторичного и Node Energy – в качестве окончательного. В таком случае в полях Prec объектов Hop Count, LQL, Node Energy следует указывать строго возрастающие значения, например, 0, 1, 2. Если несколько агрегированных метрик имеют одинаковые значения Prec, поведение зависит от реализации.

3. Объекты метрики и ограничений для узла

В разделах 3 и 4 задано несколько объектов метрики и ограничений для узлов и каналов. Если в таком случае реализация RPL получает более одного объекта данного типа, второй объект должен игнорироваться. При наличии ограничений узел должен включать метрику того же типа, используемую для проверки соблюдения ограничений. В любом случае узел должен сохранять содержимое ограничений.

3.1. Объект состояния и атрибутов узла

Объект состояния и атрибутов узла (Node State and Attribute или NSA) содержит сведения о характеристиках узла. Объекты NSA могут присутствовать в DAG Metric Container, но недопустимо включать в контейнер более одного объекта NSA в качестве ограничения и недопустимо включать более одного объекта NSA в качестве метрики. Объект NSA может включать набор TLV с различными характеристиками узла. TLV пока не определены.

Для типа NSA выделено значение 1 в реестре IANA, формат объекта показан на рисунке 2.

 0                   1                   2
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...
|     Res       |  Flags    |A|O|Необязательные TLV
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...

Рисунок 2. Тело объекта NSA.

Res (8 битов)

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

Flags (8 битов)

В настоящее время определены два флага для объектов NSA.

A

Атрибут агрегирования (Aggregation Attribute). Агрегирование указано как требование в параграфе 6.2 [RFC5548]. Некоторые приложения могут использовать атрибут агрегирования узла при выборе маршрута для минимизации объёма трафика в сети, что может увеличить срок работы устройств с батарейным питанием. Приложения, в которых регулярно ожидается высокий трафик, могут получить преимущество в результате маршрутизации с агрегированием данных. Установка флага говорит, что узел может агрегировать трафик. В других документах могут определяться дополнительные TLV для описания функциональности агрегатора.

O

Нагрузку на узел может быть трудно определить и выразить в скалярной форме, однако она может быть полезной метрикой при расчёте пути, в частности, при необходимости минимизировать задержки в очередях для чувствительного к ним трафика с учётом задержки на уровне MAC. Флаг можно устанавливать для узла по перегрузке CPU, нехватке памяти или иным похожим условиям. Использование простого 1-битового флага обеспечивает достаточный уровень детализации, подобно биту перегрузки в протоколах маршрутизации, таких как IS-IS. Алгоритмы установки бита и расчёта путей, узлы которых не содержат этого бита, выходит за рамки спецификации но рекомендуется избегать частой смены состояния флага для предотвращения осцилляций маршрутов. Установка флага говорит о перегрузке узла и его неспособности обработать трафик.

Незаданные поля должны содержать 0 при передаче, а на приёме должны игнорироваться.

Значения Flags в объектах NSA Routing Metric/Constraint выделяются IANA, невыделенные биты остаются в резерве.

3.2. Объект Energy для узла

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

Электропитание явно является важным ресурсом в большинстве LLN. Пока не предложено простой абстракции, адекватно описывающей широкий спектр источников питания и аккумуляторов в узлах LLN, включающий сетевое и батарейное питание, преобразователи (scavenger) и множество вторичных накопительных механизмов. Преобразователи могут надёжно обеспечивать невысокий уровень мощности, например, контур с током 4-20 мА, надёжный но непостоянный поток энергии, например, от солнечной батареи или предсказуемый уровень, например, от вибрационного преобразователя на насосе. Маршруты, работающие при солнце, могут пропадать ночью, включение насоса может соединить две ранее разделённых части сети. Аккумуляторы часто теряют свойства при регулярном полном разряде, что ведёт к разному уровню остаточной энергии для аварийного и обычного режима. Маршрут для аварийных ситуаций может отличаться от оптимального маршрута в обычных условиях.

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

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

С учётом сложности попыток сократить набор ограничений в документе предлагается два уровня точности решения. Простейшее решение основано на 2-битовом поле, задающем 3 типа источников питания powered, battery, scavenger. Такого подхода может быть достаточно для многих приложений.

Решение средней сложности заключается в использовании одного параметра, позволяющего представить энергетические возможности для устройств с питанием от батарей и преобразователей. Для узлов с преобразователями 8-битовое значение задаёт мощность, обеспечиваемую источником, поделённую на потребляемую приложением мощность (E_E=P_in/P_out) и выраженную в процентах. Узлы, собирающие больше энергии, нежели потребляется будут давать значения больше 100. Подходящий интервал усреднения для расчёта может быть связан со временем разряда имеющегося на узле аккумулятора, но задание этого параметра выходит за рамки спецификации. Для устройств с батарейным питанием E_E представляет текущий ожидаемый срок службы, поделённый на желаемый минимальный срок и выраженный в процентах. Оценка остающейся в батарее энергии и расчёт реального потребления могут быть сложны и выходят за рамки документа, однако здесь представлены два примера. Если узел может измерить свою среднюю потребляемую мощность, E_E можно рассчитать как отношение желаемой максимальной мощности (исходная энергия E_0, поделённая на желаемый срок службы T) на реальную мощность E_E=P_max/P_now. В качестве другого варианта при возможности оценки энергии в батарее E_bat и знании прошедшего времени t можно рассчитать E_E как отношение оставшейся сохранённой энергии к целевой оставшейся энергии E_E= E_bat/[E_0 (T-t)/T].

Примером оптимизированного маршрута является max(min(E_E)) для набора узлов с батарейным питанием по маршруту с ограничением E_E>=100 для всех преобразователей на пути.

Отметим, что расчётная доля оставшейся энергии, указанная полем E_E, может оказаться бесполезной при наличии узлов с питанием от батарей или преобразователей, когда объем накопленной устройствами энергии существенно различается. Действительно, X% энергии, оставшейся на узле, способном сохранять большой объем, сложно сравнивать с долей оставшейся энергии на узле, имеющем крошечный источник энергии. Однако в сетях с близкими параметрами накопителей энергии этот параметр будет полезен.

Объект Node Energy (NE) служит для предоставления информации, относящейся к питанию узла и способной служить параметром метрики или ограничений. Объект NE может присутствовать в DAG Metric Container, однако недопустимо включать более одного объекта NE в качестве ограничения и недопустимо включать более одного NE в качестве метрики.

Для объекта NE выделено значение Type = 2 в реестре IANA. Формат объекта показан на рисунке 3.

 0                   1                   2
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...
|     Субобъекты NE
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...

Рисунок 3. Формат объекта NE.

Формат тела субобъекта NE показан на рисунке 4.

 0                   1                   2
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...
| Flags |I| T |E|      E_E      |Необязательные TLV
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...

Рисунок 4. Формат субобъекта NE.

Субобъект NE может включать набор TLV с различными характеристиками узла.

Flags (8 битов)

Определённые в настоящее время флаги перечислены ниже.

I (Included)

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

T (node Type)

2-битовое поле, указывающее тип узла – T=0 для устройств с питанием от сети, T=1 – с батарейным питанием, T=2 – с питанием от преобразователей (scavenger).

E (Estimation)

При установленном флаге для метрики оценка доли оставшейся на узле энергии указывается 8-битовым полем E_E, при сброшенном эта оценка не предоставляется. Если флаг E установлен для ограничения, поле E_E указывает порог включения/исключения. Если указано включение, превышение порога задаёт включение узла, если указано исключение, значение ниже порога задаёт исключение узла.

E_E (Estimated-Energy)

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

Если объект NE содержит несколько субобъектов и служит ограничением, каждый субобъект добавляет иди исключает подмножество узлов по мере упорядоченного анализа субобъектов. Начальный набор определяется флагом I в первом субобъекте и будет полным, если флаг I задаёт исключение, и пустым, если флаг I задаёт включение.

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

3.3. Объект Hop Count

Объект Hop Count (HP) служит для указания числа узлов на пути. Объекты HP могут присутствовать в DAG Metric Container, но недопустимо включать в контейнер более одного объекта HP в качестве ограничения и недопустимо включать более одного объекта HP в качестве метрики. Объект HP может включать набор TLV с различными характеристиками узла. TLV пока не определены.

Для объекта HP выделено значение Type = 3 в реестре IANA. Формат объекта Count показан на рисунке 5.

 0                   1                   2
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...
|  Res  | Flags |   Hop Count   |  Необязательные TLV
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...

Рисунок 5. Формат тела объекта Hop Count.

Res (4 бита)

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

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

Объект HP может служить в качестве ограничения или метрики. При использовании в качестве ограничения корень DAG указывает максимальное число интервалов пересылки, которые могут быть в пути. При достижении заданного предела в путь нельзя включить другие узлы. При использовании в качестве метрики прохождение каждого узла просто инкрементирует значение поля Hop Count.

Первый узел пути, включающий объект метрики HC, должен установить в поле Hop Count значение 1.

4. Объекты метрики и ограничений для канала

4.1. Объект Throughput

Многие сети LLN поддерживают широкий диапазон значений пропускной способности. Для некоторых каналов это может быть связано с переменным кодированием. На загруженных каналах, встречающихся во многих LLN, изменчивость может быть результатом компромисса между потребляемой мощностью и скоростью. Имеется несколько протоколов уровня MAC, позволяющих менять эффективную скорость каналов более чем на 3 порядка с соответствующим изменением потребляемой мощности. Для эффективной работы может быть желательно указание узлами диапазона поддерживаемых на каналах скоростей в дополнение к текущей доступной пропускной способности.

Объекты Throughput могут присутствовать в DAG Metric Container, но недопустимо включать в контейнер более одного объекта Throughput в качестве ограничения и недопустимо включать более одного объекта Throughput в качестве метрики.

Объект Throughput состоит из одноимённых субобъектов и должен включать по меньшей мере один субобъект Throughput. Первым должен указываться субобъект Throughput с самой свежей оценкой фактической пропускной способности. Метод оценки фактической пропускной способности выходит за рамки спецификации.

Субобъект Throughput имеет фиксированный размер 4 байта. Объект Throughput не включает дополнительных TLV. Для объектов Throughput выделено значение Type = 4 в реестре IANA, формат объекта показан на рисунке 6.

 0                   1
 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  (субобъекты) .....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 6. Тело объекта Throughput.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Throughput                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 7. Формат субобъекта Throughput.

Throughput (32 бита)

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

4.2. Объект Latency

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

Объекты Latency могут присутствовать в DAG Metric Container, но недопустимо включать в контейнер более одного объекта Latency в качестве ограничения и недопустимо включать более одного объекта Latency в качестве метрики.

Объект Latency состоит из одноимённых субобъектов и должен включать по меньшей мере один субобъект Latency.

Субобъект Latency имеет фиксированный размер 4 байта. Объект Latency не включает дополнительных TLV. Для объектов Latency выделено значение Type = 5 в реестре IANA, формат объекта показан на рисунке 8. Объект Latency может указывать метрику или ограничение.

 0                   1
 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  (субобъект) .....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 8. Тело объекта Latency.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         Latency                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 9. Формат субобъекта Latency.

Latency (32 бита)

Задержка в микросекундах, указанная 32-битовым целым числом без знака.

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

4.3. Надёжность канала

В сетях LLN надёжность соединения может снижаться в результате ослабления сигналов, различных помех и т. п. Временной масштаб изменений может варьироваться от миллисекунд до дней и часто связан с человеческой деятельностью. Частота ошибок в пакетах может быть измерена напрямую, а другие параметры (например, частота битовых ошибок, среднее время между отказами) обычно выводятся из неё. Отметим, что такая изменчивость присуща не только беспроводным каналам, но и каналам PLC.

Изменение качества каналов может влиять на сетевую связность, поэтому качество соединения может применяться в качестве важной метрики маршрутизации. Можно определить множество параметров надёжности, отражающих разные аспекты. Данный документ задаёт два параметра — уровень качества канала (Link Quality Level или LQL) и ETX Metric. Реализация RPL может использовать LQL, ETX или оба параметра.

4.3.1. Объект LQL

Объект LQL служит для указания качества канала дискретным значением от 0 до 7 (0 – неопределённое качество, 1 – высший уровень). Механизмы и алгоритмы расчёта LQL зависят от реализации и выходят за рамки документа. LQL может служить метрикой или ограничением. При использовании в качестве метрики значение LQL может только записываться. Например, объект DAG Metric может запрашивать у всех проходимых узлов запись LQL на их входящем канале в объект LQL. Затем каждый узел может применять запись LQL для выбора родителей на основе заданных пользователем правил (например, выбор пути, где большинство узлов указывает значение LQL не более 3). Для сжатия данных применяются счётчики и записывается лишь число каналов для каждого встретившегося значения LQL.

Объекты LQL могут присутствовать в DAG Metric Container, но недопустимо включать в контейнер более одного объекта LQL в качестве ограничения и недопустимо включать более одного объекта LQL в качестве метрики.

Объект LQL должен включать один или несколько субобъектов, служащих для указания числа каналов с данным LQL. Для объектов LQL выделено значение Type = 6 в реестре IANA, формат объекта показан на рисунке 10

 0                   1                   2
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...
|       Res     | LQL sub-object
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...

Рисунок 10. Тело объекта LQL.

Res (8 битов)

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

При записи метрики LQL тело объекта LQL содержит один или несколько субобъектов LQL типа 1 (рисунок 11).

 0
 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Val | Counter |
+-+-+-+-+-+-+-+-+

Рисунок 11. Субоъект LQL типа 1.

Val

Значение LQL от 0 до 7, где 0 указывает неопределённое, а 1 – наивысшее качество соединения.

Counter

Число каналов с данным уровнем качества.

4.3.2. Объект ETX

Метрика ETX указывает число передач, ожидаемых узлом для доставки пакета адресату. В отличие от метрики LQL, ETX задаёт дискретное значение (не обязательно целое), которое рассчитывается по заданной формуле. Например, реализация может использовать расчёт ETX= 1/(Df*Dr), где Df указывает измеренную вероятность получения пакета соседом, а Dr – измеренную вероятность приёма пакета подтверждения. Документ не задаёт формулу расчёта ETX.

Объекты ETX могут присутствовать в DAG Metric Container, но недопустимо включать в контейнер более одного объекта ETX в качестве ограничения и недопустимо включать более одного объекта ETX в качестве метрики.

Объект ETX состоит из одноимённых субобъектов и должен включать по меньшей мере один субобъект ETX. Субобъект ETX имеет фиксированный размер 16 байтов. Объект ETX не включает дополнительных TLV. Для объектов Latency выделено значение Type = 7 в реестре IANA, формат объекта показан на рисунке 12.

 0                   1
 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  (субобъекты) .....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 12. Тело объекта ETX.

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

Рисунок 13. Субобъект ETX.

ETX (16 битов)

Значение ETX*128 в форме целого числа без знака с округлением. Например, для ETX = 3,569 объект будет иметь значение 457. Для ETX > 511,9921875 объект принимает максимальное значение 65535.

Объект ETX может указывать ограничение или метрику. Например, если нужно, чтобы не превышался заданный максимум ETX, базовый заголовок объекта ETX указывает ограничение. Объект ETX может указывает агрегируемую аддитивную метрику и значение будет обновляться в соответствии с качеством каналов по мере прохождения пути. Узел получает агрегированное значение ETX на пути (совокупное значение ETX будет суммой ETX для всех пройденных каналов от анонсирующего узла до корня DAG) и при выборе анонсирующего узла в качестве предпочтительного родителя он обновляет ETX для пути, прибавляя значение ETX на локальном канале к предпочтительному родителю к полученной стоимости пути (ETX) перед возможным анонсированием нового ETX.

4.4. Объект LC

4.4.1. Описание объекта

Объект Link Color (LC) задаёт административное 10-битовое значение (статическое или динамическое), применяемое для исключения или предпочтения определённых каналов для определённых типов трафика. Объект LC может указывать метрику или ограничение. При использовании в качестве метрики значение LC может только записываться. Например, DAG может требовать записи LC для всех пройденных каналов. Цвет определяется как конкретный набор битов, т. е. 10-битовое поле содержит флаги, а не скалярное значение. Каждый узел может применять LC для выбора родителя на основе правил (например, выбирать путь с максимальным числом каналов, где установлен бит 1). При использовании в качестве записываемой метрики для сжатия данных применяются счётчики, указывающие число каналов для каждого указанного LC.

Объекты LC могут присутствовать в DAG Metric Container, но недопустимо включать в контейнер более одного объекта LC в качестве ограничения и недопустимо включать более одного объекта LC в качестве метрики.

Объект LC должен включать по меньшей мере один субобъект LC и не включает дополнительных TLV. Для объектов LC выделено значение Type = 8 в реестре IANA, формат объекта показан на рисунке 14.

 0                   1                   2
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...
|      Res      | субобъекты LC
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...

Рисунок 14. Формат объекта LC.

Res (8 битов)

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

При использовании объекта LC как записываемой метрики тело LC содержит один или несколько субобъектов LC типа 1 (рисунок 15).

 0                   1
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Link Color     |  Counter  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 15. Субобъект LC типа 1.

При использовании объекта LC как ограничения тело LC содержит один или несколько субобъектов LC типа 2 (рисунок 16)

 0                   1
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Link Color    |Reserved |I|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 16. Субобъект LC типа 2.

Reserved (5 битов)

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

I

Флаг, действительный лишь при использовании LC в качестве ограничения. Установленный флаг задаёт включения каналов с заданным цветом, сброшенный – исключение.

Назначение каждого бита поля Link Color определяется реализацией.

4.4.2. Режим работы

Цвет канала может служит ограничением или метрикой.

• В качестве ограничения объект LC может помещаться в DAG Metric Container для включения или исключения из пути каналов соответствующего цвета.

• При использовании в качестве записываемой метрики каждый узел на пути может помещать объект LC в DAG Metric Container для указания цвета локального канала. Если объект LC уже указывает такой цвет, узлу недопустимо добавлять идентичный субобъект LC и он должен лишь увеличивать значение счётчика.

5. Расчёт динамической метрики и атрибутов

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

Для минимизации обновлений метрики можно применять алгоритмы с несколькими порогами для передачи обновлений. На практике следует применять частотные фильтры и/или гистерезис для предотвращения быстрых флуктуаций значений. Хотя указание алгоритмов расчёта пути с использованием динамической метрики выходит за рамки спецификации, рекомендуется тщательно разрабатывать алгоритмы оптимизации маршрутов для предотвращения слишком частого расчёта маршрутов при изменении метрики.

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

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

Агентство IANA создало новый реестр верхнего уровня RPL Routing Metric/Constraint для включения всех кодов объектов и субреестров. Для каждого из новых реестров применяется процедура IETF review [RFC5226]. В частности, новые значения выделяются через RFC, одобренные IESG. Как правило, IESG запрашивает сведения о предполагаемом назначении у соответствующих лиц (например, в рабочей группе при её наличии).

Новые номера ботов выделяются только по процедуре IETF Review и отслеживаются по 3 параметрам:

• номер бита;

• описание возможности;

• RFC с определением.

6.1. Типы метрики и ограничений

Агентство IANA создало субреестр Routing Metric/Constraint Type для типа объектов Routing Metric/Constraint со значениями от 0 до 255. Значение 0 не выделено.

Значение	Описание	Документ
1	Состояние и атрибут узла	Данный документ
2	Питание узла	Данный документ
3	Счётчик интервалов пересылки	Данный документ
4	Пропускная способность канала	Данный документ
5	Задержка в канале	Данный документ
6	Уровень качества канала	Данный документ
7	ETX для канала	Данный документ
8	Цвет канала	Данный документ

6.2. TLV для метрики и ограничений

Агентство IANA создало субреестр Routing Metric/Constraint TLVs для всех TLV, передаваемых в объектах Routing Metric/Constraint. Поле Type имеет размер 8 битов и может включать значения от 0 до 255. Значение 0 не выделено. 8-битовое поле Length может содержать значения от 0 до 255. Размер и назначение поля Value зависит от типа и здесь не определено, поскольку типы пока не зарегистрированы.

6.3. Поле Routing Metric/Constraint Common Header Flag

Агентство IANA создало субреестр Routing Metric/Constraint Common Header Flag field для поддержки значений 9-битового поля Flag в базовом заголовке Routing Metric/Constraint. Этот документ определяет несколько битов поля Flag, как показано ниже.

Биты поля Flag в базовом заголовке Routing Metric/Constraint.

Бит	Описание	Документ
8	Запись/агрегирование	Данный документ
7	Необязательное ограничение	Данный документ
6	Ограничение/метрика	Данный документ
5	P (неполное)	Данный документ

Биты 0-4 не пока выделены.

6.4. Поле Routing Metric/Constraint Common Header A

Агентство IANA создало субреестр Routing Metric/Constraint Common Header A field для значения поля A в базовом заголовке Routing Metric/Constraint. 3-битовое поле A может содержать значение от 0 до 7.

Значения поля A в базовом заголовке Routing Metric/Constraint.

Значение	Описание	Документ
0	Метрика является аддитивной	Данный документ
1	Метрика указывает максимум	Данный документ
2	Метрика указывает минимум	Данный документ
3	Метрика является мультипликативной	Данный документ

6.5. Поле флагов объекта NSA

Агентство IANA создало субреестр NSA Object Flag field для значений поля Flag в объекте NSA.

Этот документ определяет несколько битов поля NSA Object Flag, показанных в таблице.

Биты поля Flag в объекте NSA.

Бит	Описание	Документ
6	Агрегатор	Данный документ
7	Перегрузка	Данный документ

Биты 0-5 не пока выделены.

6.6. Поле флагов объекта Hop-Count

Агентство IANA создало субреестр Hop-Count Object Flag field для битов поля Flag в объекте Hop Count. Флаги пока не заданы.

6.7. Поле типа узла

Агентство IANA создало субреестр Node Type Field для кодов типа узла в базовом заголовке Routing Metric/Constraint. Поле T имеет размер 2 бита и может иметь значение от 0 до 3.

Значения поля T в базовом заголовке Routing Metric/Constraint.

Значение	Описание	Документ
0	Узел с питанием от сети	Данный документ
1	Узел с батарейным питанием	Данный документ
2	Узел с питанием от преобразователя	Данный документ

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

Метрика маршрутов должна обрабатываться безопасным и надёжным способом. Например, протоколу RPL не следует позволять вредоносным узлам анонсировать ложную хорошую метрику для маршрутов с целью выбора их в качестве предпочтительного маршрутизатора next-hop для трафика других узлов и перехвата пакетов. Другой тип атак может быть связан с повторяющимися попытками поменять качество канала и связанной с ним метрики маршрута, которые могут создавать флуктуации в DODAG. Поэтому реализациям RPL рекомендуется внедрять механизмы для прекращения анонсирования маршрутной метрики для нестабильный каналов, которые могут подвергаться атакам.

Некоторые типы метрики могут применяться для нахождения в сети слабых мест (например, ненадёжных каналов, узлов с недостаточным питанием и т. п.), которые злоумышленник может использовать. Поэтому рекомендуется тщательно выбирать используемые в RPL метрики и учитывать уровень раскрытия сведений о состоянии сети или применять для такой информации механизмы защиты, указанные в [RFC6550].

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

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

Авторы признательны Young Jae Kim, Hakjin Chong, David Meyer, Mischa Dohler, Anders Brandt, Philip Levis, Pascal Thubert, Richard Kelsey, Jonathan Hui, Alexandru Petrescu, Richard Kelsey, Mathilde Durvy, Phoebus Chen, Tim Winter, Yoav Ben-Yehezkel, Matteo Paris, Omprakash Gnawali, Mads Westergreen, Mukul Goyal, Joseph Saloway, David Culler, Jari Arkko за вклад в работу, рецензии и ценные замечания. Отдельная благодарность Adrian Farrel за внимательное рецензирование.

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

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

[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, March 1997.

[RFC5226] Narten, T. and H. Alvestrand, “Guidelines for Writing an IANA Considerations Section in RFCs”, BCP 26, RFC 5226, May 2008.

[RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. Alexander, “RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks”, RFC 6550, March 2012.

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

[RFC1195] Callon, R., “Use of OSI IS-IS for routing in TCP/IP and dual environments”, RFC 1195, December 1990.

[RFC2328] Moy, J., “OSPF Version 2”, STD 54, RFC 2328, April 1998.

[RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O’Dell, M., and J. McManus, “Requirements for Traffic Engineering Over MPLS”, RFC 2702, September 1999.

[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, “RSVP-TE: Extensions to RSVP for LSP Tunnels”, RFC 3209, December 2001.

[RFC5548] Dohler, M., Watteyne, T., Winter, T., and D. Barthel, “Routing Requirements for Urban Low-Power and Lossy Networks”, RFC 5548, May 2009.

[RFC5673] Pister, K., Thubert, P., Dwars, S., and T. Phinney, “Industrial Routing Requirements in Low-Power and Lossy Networks”, RFC 5673, October 2009.

[RFC5826] Brandt, A., Buron, J., and G. Porcu, “Home Automation Routing Requirements in Low-Power and Lossy Networks”, RFC 5826, April 2010.

[RFC5867] Martocci, J., De Mil, P., Riou, N., and W. Vermeylen, “Building Automation Routing Requirements in Low-Power and Lossy Networks”, RFC 5867, June 2010.

[RFC6552] Thubert, P., Ed., “Objective Function Zero for the Routing Protocol for Low-Power and Lossy Networks (RPL)”, RFC 6552, March 2012.

[ROLL-TERMS] Vasseur, JP., “Terminology in Low power And Lossy Networks”, Work in Progress⁸, September 2011.

[Zinky1989] Zinky, J., Vichniac, G., and A. Khanna, “Performance of the Revised Routing Metric for ARPANET and MILNET”, Military Communications Conference, MILCOM ’89, March 1989.

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

JP. Vasseur (editor)

Cisco Systems

11, Rue Camille Desmoulins

Issy Les Moulineaux 92782

France

EMail: jpv@cisco.com

Mijeom Kim (editor)

Corporate Technology Group, KT

17 Woomyeon-dong, Seocho-gu

Seoul 137-792

Korea

EMail: mjkim@kt.com

Kris Pister

Dust Networks

30695 Huntwood Ave.

Hayward, CA 95544

USA

EMail: kpister@dustnetworks.com

Nicolas Dejean

Elster SAS

Espace Concorde, 120 impasse JB Say

Perols 34470

France

EMail: nicolas.dejean@coronis.com

Dominique Barthel

France Telecom Orange

28 chemin du Vieux Chene, BP 98

Meylan 38243

France

EMail: dominique.barthel@orange.com

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

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

nmalykh@protokols.ru