RFC 9009 Efficient Route Invalidation

Internet Engineering Task Force (IETF)                  R.A. Jadhav, Ed.
Request for Comments: 9009                                        Huawei
Category: Standards Track                                     P. Thubert
ISSN: 2070-1721                                                    Cisco
                                                              R.N. Sahoo
                                                                  Z. Cao
                                                                  Huawei
                                                              April 2021

Efficient Route Invalidation

Эффективное аннулирование маршрутов

PDF

Аннотация

В документе рассматриваются проблемы, связанные с использованием сообщений NPDAO¹ в RFC 6550, а также требования к оптимизированной схеме обмена сообщениями об аннулировании маршрутов. Кроме того, здесь описано новое сообщение для проактивного аннулирования маршрутов, названное DCO², которое соответствует требованиям к оптимизированному обмену сообщениями об аннулировании маршрутов.

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

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

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

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

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

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

Протокол RPL⁵, определённый в [RFC6550], задаёт проактивную схему маршрутизации на основе вектора удалённости. RPL включает необязательные сообщения в форме DAO⁶, которые могут применять маршрутизаторы 6LBR⁷ и 6LR⁸ для изучения маршрутов к нисходящим узлам. 6LoWPAN является сокращением для IPv6 через беспроводные персональные сети с недостаточным электропитанием. В режиме сохранения (Storing) сообщения DAO приводят к созданию маршрутных записей на всех промежуточных 6LR от родительского узла ко всем 6LBR.

RPL позволяет использовать сообщения NPDAO для аннулирования пути, соответствующего данному адресату, с освобождением используемых для этого пути ресурсов. NPDAO является сообщением DAO с нулевым сроком действия маршрута, которое исходит от целевого узла и перемещается в восходящем направлении к 6LBR. В этом документе разъясняются проблемы, связанные с использованием сообщения NPDAO в [RFC6550], а также требования по оптимизации схемы сообщений об аннулировании маршрутов. Кроме того, документ определяет новое сообщение о проактивном аннулировании маршрутов DCO, соответствующее требованиям к оптимизированной схеме сообщений.

Этот документ относится лишь к режиму хранения RPL (Storing MOP⁹). Режим Non-Storing MOP не требует использования NPDAO для аннулирования маршрутов, поскольку маршрутные записи не поддерживаются в 6LR.

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

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

От читателей этой спецификации требуется знакомство с терминами и концепциями документа «RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks» [RFC6550].

Low-Power and Lossy Network (LLN) – сеть с недостаточным электропитанием и большими потерями

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

6LoWPAN Router (6LR) – маршрутизатор 6LoWPAN

Промежуточный маршрутизатор, способный передавать и принимать сообщения RA (Router Advertisement) и RS (Router Solicitation), а также пересылать и маршрутизировать пакеты IPv6.

Directed Acyclic Graph (DAG) – направленный ациклический граф

Направленный граф, в котором все ребра ориентированы так, что не возникает петель.

Destination-Oriented DAG (DODAG) – ориентированный на получателя граф DAG

DAG, маршрутизируемый у одного получателя, т. е. корень DAG без исходящих рёбер.

6LoWPAN Border Router (6LBR) – маршрутизатор 6LoWPAN

Граничный маршрутизатор, служащий корнем DODAG и граничным узлом для трафика 6LoWPAN.

Destination Advertisement Object (DAO) – объект анонсирования получателя

Сообщения DAO позволяют организовать нисходящие маршруты к узлам.

DODAG Information Object (DIO) – объект с информацией DODAG

Сообщения DIO позволяют организовать восходящие маршруты к 6LBR. DIO инициируются в корне DAO.

Common ancestor node – узел общего предка

Первый общий узел 6LR или 6LBR для двух путей к целевому узлу.

No-Path DAO (NPDAO) – сообщение DAO об отсутствии пути

Сообщение DAO с нулевым сроком действия, служащее для аннулирования маршрутов.

Destination Cleanup Object (DCO) – объект “очистки” адресата

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

Regular DAO – обычное сообщение DAO

Сообщение DAO с ненулевым сроком действия, служащее для создания или обновления отношений смежности.

Target node – целевой узел

Узел, меняющий родителя, для которого обновляется (создание или удаление) маршрутная смежность.

1.2. Сообщения RPL NPDAO

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

   (6LBR)
     |
     |
     |
    (A)
    / \
   /   \
  /     \
(G)     (H)
 |       |
 |       |
 |       |
(B)     (C)
  \      ;
   \    ;
    \  ;
     (D)
     / \
    /   \
   /     \
 (E)     (F)

Рисунок 1. Простая топология.

Узел D подключён через предпочитаемого родителя B и имеет дополнительный путь к 6LBR через C. Узел A является общим предком D для путей через B-G и C-H. При переключении D с узла B на узел C протокол RPL позволяет передать сообщение NPDAO узлу B и обычное сообщение DAO узлу C.

1.3. Важность сообщений NPDAO

Ресурсы узлов LLN обычно ограничены. Узел имеет ограниченную память, а маршрутные записи является основным содержимым динамической памяти узлов. Аннулирование маршрутов помогает узлам 6LR принимать решение об удалении маршрутных записей для более эффективного использования ограниченных ресурсов. Поэтому требуется механизм эффективного аннулирования маршрутов. Отметим, что одна смена родителя может приводить к смене предка для субдерева. Таким образом, аннулирование маршрутов должно происходить от имени субдерева, а не только от имени меняющего родителя узла. В приведённом выше примере, где узел D меняет своего родителя, требуется обновить маршрутные записи узлов C, H, A, G и B, где адресатами являются D, E, F. Без эффективного аннулирования маршрутов 6LR может сохранять ненужные маршрутные записи.

2. Проблемы, связанные с RPL NPDAO

2.1. Потеря NPDAO в результате обрыва канала к прежнему родителю

При смене узлом родителя передаётся сообщение NPDAO прежнему родителю и обычное сообщение DAO – новому родителю. При смене родителя в результате отказа узла или канала, сообщение NPDAO может не отправляться.

2.2. Аннулирование маршрутов зависимых узлов

RPL не задаёт механизм аннулирования маршрутов для зависимых узлов в суб-DAG меняющего родителя узла, что может приводить к сохранению на зависимых узлах устаревших записей. Для 6LR единственным способом аннулирования маршрутных записей является срок действия маршрутов, что может быть очень важно для сетей LLN.

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

2.3. Возможность простоя маршрута из-за асинхронности NPDAO и DAO

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

В приведённом примере узел D меняет родителя B на C и сообщение NPDAO, переданное по прежнему пути, может аннулировать предыдущий маршрут и невозможно определить обновление записей на новом пути сообщением DAO.

3. Требования к оптимизации NPDAO

3.1. Требование 1 – независимость от канала к прежнему родителю

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

3.2. Требование 2 – аннулирование маршрута для зависимых узлов

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

3.3. Требование 3 – независимость трафика данных от аннулирования пути

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

4. Изменение сигнализации RPL

4.1. Смена семантики аннулирования маршрутов в RPL

Как указано в параграфе 1.2, сообщения NPDAO исходят от меняющего родителя узла и передаются в восходящем к корню направлении. Для решения проблемы, отмеченной в разделе 2, этот документ определяет новое сообщение DCO, анонсирующее удаление маршрута, которой исходит от общего узла-предка и передаётся по прежнему пути в нисходящем направлении. Общий предок создаёт сообщение DCO при удалении следующего интервала на пути к цели. Например, в качестве отложенного отклика на получение обычного DAO от другого дочернего узла с той же или более новым Path Sequence для цели, передача DCO отменяется.

Маршрутизаторы 6LR в пути DCO аннулируют маршрут на основе данных DCO, а затем передают другое сообщение DCO с теми же сведениями следующему маршрутизатору или маршрутизаторам в нисходящем направлении. Эта операция похожа на обработку DAO промежуточными 6LR в режиме Storing MOP [RFC6550]. Подобно DAO в Storing MOP, сообщение DCO передаётся с использованием локального для канала индивидуального адреса IPv6 link-local для отправителя и получателя, но в отличие от DAO, передаваемых в восходящем направлении, сообщения DCO передаются в нисходящем направлении.

В приведённом на рисунке 1 примере дочерний узел D при смене родителя B на C передаёт обычное сообщение DAO узлу C с информацией о доступности, включающей адрес D как цель и инкрементированное значение Path Sequence. Узел C обновляет таблицу маршрутизации на основе сведений о доступности из DAO, затем создаёт новое сообщение DAO с теми же данными о доступности, пересылаемое узлу H. На узле H выполняется такая же процедура, как на узле C и передаётся сообщение узлу A. Когда A получает обычное сообщение DAO, он видит, что в таблице маршрутизации уже имеется целевой адрес (Target Address) узла D. Однако он будет видеть, что информация о следующем интервале на пути к узлу D изменилась, что говорит о смене пути узлом D. В этом случае узел A, который является общим предком для двух путей к D (прежний и новый), может создать сообщение DCO, передаваемое в нисходящем направлении по старому пути к цели. Узел A выполняет обычную пересылку DAO маршрутизатору 6LBR, как требует [RFC6550].

4.2. Изменение опции Transit Information

Каждое сообщение RPL делится на базовые поля и опции, как описано в разделе 6 [RFC6550]. Базовые поля относятся к сообщению в целом, а опции добавляют зависимые от сообщения и варианта использования атрибуты. Например, сообщение DAO может включать одну или несколько опций RPL Target, которые указывают к каким целям относятся сведения о доступности. С набором опций RPL Target может быть связана опция Transit Information.

Этот документ меняет спецификацию опции Transit Information путём включения флага аннулирования прежнего маршрута I¹⁰, который информирует общего предка о необходимости создать сообщение DCO от имени целевого узла с полем RPL Status 195, указывающим перемещение адреса. Флаг I передаётся в опции Transit Information, которая дополняет сведения о доступности для данного набора RPL Target. Опцию Transit Information с флагом I следует передавать в сообщении DAO при аннулировании маршрута к соответствующим целям.

Значение 195 представляет установленные биты U и A в поле RPL Status (см. рисунок 6 в [RFC9010]), где 6 младших битов содержат значение 6LoWPAN Neighbor Discovery (ND) EARO¹¹ Status 3, указывающее состояние Moved в соответствии с таблицей 1 в [RFC8505].

 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 = 0x06 | Option Length |E|I|  Flags    | Path Control  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Path Sequence | Path Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 2. Обновлённая опция Transit Information (новый флаг I).

I (Invalidate previous route)

Флаг I устанавливается целевым узлом для указания общему предку своего желания аннулировать все прежние маршруты.

[RFC6550] позволяет передавать адрес родителя в опции Transit Information в зависимости от MOP. В случае Storing MOP это поле обычно не требуется, а для DCO включение поля Parent Address недопустимо.

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

4.3. Объект «очистки» адресата (DCO)

Определён новый код управляющего сообщения ICMPv6 RPL, названного DCO, которое служит для проактивной очистки состояния и маршрутных данных, сохраняемые в 6LR от имени целевого узла. Сообщения DCO передаются в нисходящем направлении и сбрасывают маршрутные данные и другие сведения о состоянии, связанные с данной целью. Формат сообщения DCO показан на рисунке 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RPLInstanceID |K|D|   Flags   |   RPL Status  | DCOSequence   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
|                                                               |
+                    DODAGID (необязательно)                    +
|                                                               |
+                                                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Опции...
+-+-+-+-+-+-+-+-+

Рисунок 3. Базовый объект DCO.

RPLInstanceID

8-битовое поле, указывающее связанный с DODAG экземпляр топологии, определённый из DIO.

K

Флаг K указывает, что от получателя сообщения DCO ожидается отправка подтверждения DCO-ACK. Если сообщение DCO-ACK не даже при установке флага K, реализация может позднее повторить DCO. Число повторов зависит от реализации и предполагается значение, близкое к числу повторов DAO [RFC6550]. Вопрос числа попыток DCO рассматривается в параграфе 4.6.3. Узел, получивший сообщение DCO без флага K, может отвечать сообщением DCO-ACK, особенно для информирования об ошибках. Примером такой ошибки может служить ситуация, когда передающий DCO-ACK узел не нашёл маршрутной записи для указанной цели. Отказ отправителя от установки флага K говорит о том, что отправитель не ждёт ответа и ему не следует повторять DCO.

D

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

Flags

Оставшиеся 6 битов поля Flags зарезервированы на будущее. Отправитель должен устанавливать в них 0, а получатель должен игнорировать.

RPL Status

Статус, определённый в [RFC6550] и обновленный в [RFC9010]. Корневой узел или общий предок, генерирующий DCO, полномочен устанавливать сведения о статусе, которые не меняются при нисходящем распространении DODAG. Этот документ не задаёт дифференциации действий в зависимости от RPL Status.

DCOSequence

8-битовое поле, инкрементируемое для каждого уникального сообщения DCO от узла, которое включается в сообщение DCO-ACK. Начальное значение DCOSequence узел может выбирать произвольно. Обработка DCOSequence описана в параграфе 4.4.

DODAGID

128-битовое целое число без знака, устанавливаемое корнем DODAG для однозначной идентификации DODAG. Поле должно присутствовать при установке флага D и недопустимо при сброшенном флаге D. Значение DODAGID применяется при использовании локального RPLInstanceID для указания DODAGID, связанного с RPLInstanceID.

4.3.1. Secure DCO

Сообщение Secure DCO следует формату, заданному на рисунке 7 в [RFC6550]. Базовый формат сообщения DCO показан на рисунке 3.

4.3.2. Опции DCO

Сообщение DCO должно включать по меньшей мере одну опцию RPL Target и Transit Information, а также может включать иные опции. Данная спецификация позволяет включать в DCO опции:

• 0x00 Pad1;

• 0x01 PadN;

• 0x05 RPL Target;

• 0x06 Transit Information;

• 0x09 RPL Target Descriptor.

Указанные опции определены в параграфе 6.7 [RFC6550]. Сообщение DCO содержит опцию RPL Target и связанную с ней опцию Transit Information со сроком действия 0x00000000 для индикации потери связности с указанной целью.

4.3.3. Последовательность путей в DCO

Сообщение DCO содержит опцию Transit Information для каждого аннулируемого пути. Значение счётчика Path Sequence в опции Transit Information позволяет определить свежесть сообщения DCO по сравнению с самым новым, известным маршрутизаторам 6LR на удаляемом пути. Если сообщение DCO создано общим предком в ответ на сообщение DAO, опция Transit Information в DCO должна использовать значение Path Sequence из новейшей опции Transit Information, которая была получена для цели общим предком. Если 6LR на нисходящем пути получает DCO с Path Sequence не новее Path Sequence из опции Transit Information в сообщении DAO, маршрутизатору 6LR недопустимо удалять своё текущее состояние маршрутизации и недопустимо пересылать DCO вниз по пути, где сообщение не является более свежим. Если DCO новее, маршрутизатор 6LR может сохранить временное состояние, чтобы обеспечить игнорирование DAO, полученного позднее с опцией Transit Information, содержащей более старый порядковый номер. Опция Transit Information в сообщении DAO, которая соответствует или новее, чем чем в DCO, означает, что указанный в DAO установлен и сообщение DAO распространено. При распространении DCO в результате приёма DCO от восходящего родителя, значение Path Sequence должно копироваться из полученного DCO.

4.3.4. Подтверждение DCO-ACK

Сообщение DCO-ACK получателю DCO следует передавать в индивидуальном пакете в ответ на индивидуальное сообщение DCO с флагом K. Если флаг K не установлен, получатель сообщения DCO может передать DCO-ACK, особенно при возникновении ошибки. Формат сообщения DCO-ACK показан на рисунке 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RPLInstanceID |D|   Flags     |  DCOSequence  | DCO-ACK Status|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
|                                                               |
+                    DODAGID (необязательно)                    +
|                                                               |
+                                                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 4. Базовый объект DCO-ACK.

RPLInstanceID

8-битовое поле, указывающее связанный с DODAG экземпляр топологии, определённый из DIO.

D

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

Flags

7 резервных битов поля Flags. Отправитель должен устанавливать в них 0, а получатель должен игнорировать.

DCOSequence

8-битовое поле. Значение DCOSequence в DCO-ACK копируется из DCOSequence в принятом сообщении DCO.

DCO-ACK Status

Указывает статус завершения. Поле DCO-ACK Status определено на основе рисунка 6 в [RFC9010], указывающего формат RPL Status. StatusValue = 0 при сброшенном (0) флаге U указывает безусловное восприятие. StatusValue = 1 с установленным (1) флагом U говорит об отсутствии маршрутной записи, как указано в параграфе 5.3.

DODAGID

128-битовое целое число без знака, устанавливаемое корнем DODAG для однозначного указания DODAG. Поле должно присутствовать при установленном флаге D и недопустимо при сброшенном флаге D. Поле DODAGID применяется при использовании локального RPLInstanceID для указания DODAGID, связанного с RPLInstanceID.

4.3.5. Secure DCO-ACK

Формат сообщения Secure DCO-ACK следует приведённому на рисунке 7 в [RFC6550], а базовый формат сообщения DCO-ACK показан на рисунке 4.

4.4. Базовые правила DCO

1. Если узел передаёт сообщение DCO с более новой или просто отличающейся от переданной в предыдущем DCO информацией, он должен инкрементировать поле DCOSequence. При передаче сообщения DCO, идентичного переданному ранее, узел может инкрементировать DCOSequence. Счётчик DCOSequence работает в соответствии с правилами параграфа 7.2 в [RFC6550].

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

3. Узел может установить флаг K в индивидуальном сообщении DCO для запроса индивидуального DCO-ACK с целью подтверждения попытки.

4. Узлу, получившему индивидуальное сообщение DCO с флагом K, следует отвечать сообщением DCO-ACK. При сброшенном флага K в полученном сообщении DCO узел может передать DCO-ACK, особенно при наличии ошибки.

5. Узел, получивший индивидуальное сообщение DCO, должен проверить сохранённое значение Path Sequence в контексте данной цели. Если сохранённое значение Path Sequence не старее полученного в DCO, сообщение DCO должно отбрасываться.

6. Узел, установивший флаг K в индивидуальном сообщении DCO, но не получивший в ответ DCO-ACK, может запланировать повтор сообщения DCO вплоть до заданного реализацией числа попыток.

7. Узел, получивший индивидуальное сообщение DCO со своим адресом в опции RPL Target, должен вырезать опцию Target. Если эта опция Target является единственной в сообщении DCO, сообщение DCO должно отбрасываться.

Диапазон значения DCOSequence уникален для узла, генерирующего сообщения.

4.5. Незапрошенные DCO

Маршрутизатор 6LR может создавать сообщения DCO без запроса для односторонней очистки пути от имени целевой записи. 6LR имеет все сведения о состоянии, а именно Target Address и Path Sequence, требуемые для генерации DCO по его таблице маршрутизации. Условия, при которых 6LR может генерировать DCO без запроса, выходят за рамки этой спецификации, но могут включать перечисленные ниже.

1. По завершении срока действия записи 6LR может аккуратно очистить её, инициируя сообщение DCO.

2. 6LR должен поддерживать записи с более высоким приоритетом и заполнение таблицы требует удаления имеющихся записей. Это удаление может быть выполнено путём создания DCO.

Сообщение DCO, созданное независимо от DAO (асинхронно) и предназначено для сброса всех состояний на пути независимо от Path Sequence, должно использовать в Path Sequence значение 240 (см. параграф 7.2 в [RFC6550]). Это значение позволяет DCO «выиграть» у любого установленного пути DAO, но проигрывает устанавливаемому пути DAO. Если предок инициирует одностороннюю очистку на созданном пути с использованием DCO м Path Sequence 240, сообщение DCO в конечном итоге достигнет целевого узла, который в результате узнает об аннулировании пути.

4.6. Другие вопросы

4.6.1. Аннулирование зависимых узлов

Спецификация RPL [RFC6550] не включает механизма аннулирования маршрутов для зависимых узлов. Этот документ позволяет зависимым узлам аннулировать маршруты. Зависимые узлы генерируют соответствующие сообщения DAO для обновления путей и предыдущее аннулирование маршрутов для этих узлов должно работать подобно описанному выше для узла, меняющего родителя. Зависимый узел может установить флаг I в опции Transit Information как часть обычного DAO для запроса аннулирования прежнего маршрута от общего предка.

Зависимые узлы не имеют указаний по части возможной смены их родителями своих родителей. Таким образом, для аннулирования маршрута зависимый узел может устанавливать флаг I во всех опциях Transit Information своих сообщений DAO. Установка флага I не препятствует работе, даже при отсутствии аннулирования прежнего маршрута.

4.6.2. NPDAO и DCO в одной сети

Механизм NPDAO, предусмотренный в [RFC6550], по-прежнему можно использовать в одной сети с DCO. Сообщения NPDAO могут применяться, например, по истечении срока действия маршрута целевого объекта или при решении узла корректно завершить сессию RPL при отключении узла (shutdown). Кроме того, в сети может использоваться сочетание узлов, поддерживающих DCO и имеющийся механизм NPDAO. Возможно также использование одним узлом сигнализации NPDAO и DCO для аннулирования маршрутов.

В параграфе 9.8 [RFC6550] сказано: «При удалении узлом другого узла из числа родителей DAO ему следует передать сообщение No-Path DAO (параграф 6.4.3) этому удаляемому родителю DAO для аннулирования имеющегося маршрута.» Этот документ добавляет более оптимальный способ аннулирования маршрута, сохраняя возможность использования сообщений NPDAO. В результате реализация имеет 2 варианта аннулирования маршрута.

1. Использование NPDAO для аннулирования прежнего маршрута и отправка обычного DAO по новому пути.

2. Передача по новому пути обычного DAO с флагом I в опции Transit Information, чтобы общий предок инициировал нисходящее сообщение DCO для аннулирования прежнего маршрута.

Этот документ рекомендует использовать вариант 2 по причинам, указанным в разделе 3.

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

4.6.3. Повторы DCO

Отправитель сообщения DCO может повторит его, если был установлен флаг K, а ответного DCO-ACK не получено. Время повтора DCO может зависеть от глубины сети и средней задержки на этапе пересылки (hop) и составляет 2 – 120 секунд в зависимости от сети. Если пределы задержки не известны, реализации недопустимо повторять передачу чаще 1 раза за 3 секунды и недопустимо использовать более трёх повторов.

Число повторов может также зависеть от критичности аннулирования маршрутов для сети и настройки повторов на канальном уровне. Для сетей, поддерживающих лишь потоки MP2P¹² и P2MP¹³, таких как AMI¹⁴ и телеметрия, маршрутизаторы 6LR могут не очень стремиться аннулировать маршруты, если у них нет сильных ограничений на память. Для сетей автоматизации зданий и жилых помещений, где может присутствовать значительная доля трафика P2P, маршрутизаторы 6LR могут быть заинтересованы в быстром аннулировании маршрутов, поскольку это может влиять на эффективность пересылки.

4.6.4. DCO с множеством предпочтительных родителей

[RFC6550] позволяет узлу выбрать множество предпочтительных родителей для организации маршрутов. В параграфе 9.2.1 [RFC6550] сказано: «Все DAO, созданные одновременно для одной цели Target, должны передаваться с одним значением Path Sequence в опции Transit Information». Впоследствии, при необходимости инициировать аннулирование маршрута можно использовать сообщение NPDAO, которое может быть инициировано обновлением Path Sequence для всех родительских узлов, через которые проходит аннулируемый маршрут (см. [RFC6550]).

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

Этот документ рекомендует использовать для таймера DelayDCO значение в 1 секунду, основанное на принятом по умолчанию таком же значении для таймера DelayDAO в [RFC6550]. Это основано на предположении, что DAO от всех возможных наборов родителей будут получены общим предком в этом интервале времени.

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

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

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

Агентство IANA выделило коды для сообщений DCO и DCO-ACK в реестре RPL Control Codes (таблица 1).

Таблица 1. Новые коды для сообщений DCO и DCO-ACK.

 

Код	Описание	Документ
0x07	Destination Cleanup Object	Данный документ
0x08	Destination Cleanup Object Acknowledgment	Данный документ
0x87	Secure Destination Cleanup Object	Данный документ
0x88	Secure Destination Cleanup Object Acknowledgment	Данный документ

 

Выделен также бит 1 из реестра Transit Information Option Flags для флага I (4.2. Изменение опции Transit Information).

5.1. Новый реестр для флагов DCO

Агентство IANA создало реестр для 8-битового поля флагов DCO, названный Destination Cleanup Object (DCO) Flags и размещённый в реестре Routing Protocol for Low Power and Lossy Networks (RPL). Новые флаги в этом реестре могут выделяться лишь по процедуре IETF Review [RFC8126]. Для каждого бита отслеживаются 3 параметра:

• номер (отсчёт с 0 для старшего бита);

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

• определяющий флаг документ RFC.

Выделенные к настоящему времени биты указаны в таблице 2.

Таблица 2. Базовые флаги DCO.

 

Номер бита	Описание	Документ
0	Запрос DCO-ACK (K)	Данный документ
1	Поле DODAGID присутствует (D)	Данный документ

 

5.2. Новый реестр для флагов подтверждения DCO

Агентство IANA создало реестр для 8-битового поля флагов DCO-ACK, названный Destination Cleanup Object (DCO) Acknowledgment Flags и размещённый в реестре Routing Protocol for Low Power and Lossy Networks (RPL).Новые флаги в этом реестре могут выделяться лишь по процедуре IETF Review [RFC8126]. Для каждого бита отслеживаются 3 параметра:

• номер (отсчёт с 0 для старшего бита);

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

• определяющий флаг документ RFC.

Выделенный к настоящему времени флаг указан в таблице 3.

Таблица 3. Базовый флаг DCO-ACK.

 

Номер бита	Описание	Документ
0	Поле DODAGID присутствует (D)	Данный документ

 

5.3. Значения RPL Rejection Status

Этот документ добавляет значение в реестр RPL Rejection Status, созданный в [RFC9010] (параграф 12.6).

Таблица 4. Базовый флаг DCO-ACK.

 

Значение	Смысл	Документ
1	Нет маршрутной записи	Данный документ

 

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

Этот документ предоставляет узлу общего предка возможность аннулировать маршрут от имени целевого узла. Общий предок может делать это по наличию флага I в опции Transit Information сообщения DCO от целевого узла. Однако общий предок может аннулировать маршрут и по своей инициативе, поскольку он обладает всеми нужными сведениями, а именно Target Address и соответствующее значение Path Sequence. Это позволяет мошенническому узлу общего предка аннулировать маршруты и влиять на трафик к целевому узлу.

DCO передаёт значение RPL Status, являющееся информативным. С течение времени могут выделяться новые значения статуса и узел будет игнорировать неизвестные значения. Это позволяет использовать поле RPL Status для создания скрытого канала. Но канал работает лишь 1 раз, поскольку сообщение уничтожает свою среду (маршрут).

В этом документе определён флаг I, устанавливаемый целевым узлом и применяемый узлом-предком для инициирования сообщения DCO, если предок видит обновление смежности в маршрутизации. Однако флаг может быть подделан вредоносным маршрутизатором 6LR на пути и вызвать аннулирование имеющегося активного маршрута. Аннулирование будет срабатывать лишь при выполнении условия Path Sequence для цели, к которой предпринимается попытка аннулировать маршрут. При этом злонамеренный 6LR может подделать сообщение DAO от имени потомка, установив в нем флаг I для аннулирования маршрута от имени этого потомка. Следует отметить, что при использовании механизмов, предложенных в [RFC6550], вредоносный маршрутизатор 6LR может также создать поддельное сообщение DAO с нулевым сроком действия или вызвать отказ в обслуживании путём полного отбрасывания трафика, поэтому предложенный в данном документе механизм не ведёт к существенному росту рисков.

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

Для всех сообщений RPL имеются защищённые варианты, обеспечивающие контроль целостности с использованием кодов MAC¹⁵ или подписей. Кроме того, для защищённых сообщений RPL доступно шифрование.

Этот документ добавляет сообщения DCO и DCO-ACK, синтаксически похожие на имеющиеся сообщения RPL, такие как DAO и DAO-ACK. Защищённые версии DCO и DCO-ACK используют методы, похожие на методы защиты других сообщений RPL (таких как DAO и DAO-ACK).

RPL поддерживает 3 режима защиты, описанных в параграфе 10.1 [RFC6550].

Unsecured – без защиты

В этом режиме RPL использует базовые сообщения DIS, DIO, DAO, DAO-ACK без разделов Security. Поскольку в сети могут применяться иные методы защиты (например, защита на канальном уровне), использование этого режима не означает полного отсутствия защиты сообщений.

Preinstalled – с предустановленным ключом

В этом режиме RPL применяет защищённые сообщения, поэтому должны использоваться защищённые варианты DCO и DCO-ACK.

Authenticated – с проверкой подлинности

В этом режиме RPL применяет защищённые сообщения, поэтому должны использоваться защищённые варианты DCO и DCO-ACK.

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

[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>.

[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, DOI 10.17487/RFC6550, March 2012, <https://www.rfc-editor.org/info/rfc6550>.

[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>.

[RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C. Perkins, “Registration Extensions for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Neighbor Discovery”, RFC 8505, DOI 10.17487/RFC8505, November 2018, <https://www.rfc-editor.org/info/rfc8505>.

[RFC9010] Thubert, P., Ed. and M. Richardson, “Routing for RPL (Routing Protocol for Low-Power and Lossy Networks) Leaves”, RFC 9010, DOI 10.17487/RFC9010, April 2021, <https://www.rfc-editor.org/info/rfc9010>.

Приложение A. Примеры сообщений

A.1. Пример сообщений DCO

В этом примере узел D (рисунок 1) меняет родителя B на C. В примере предполагается наличие у узла D своего маршрута через B-G-A-6LBR, использующего pathseq=x. В примере используются соглашения о сообщениях DAO и DCO и указаны лишь требуемые для разъяснения примера параметры, а именно, tgt (опция Target), значение которого задаёт адрес целевого узла, pathseq (Path Sequence) в опции Transit Information и I_flag (флаг I) в той же опции. Последовательность действий приведена ниже.

1. Узел D меняет родителя B на C.

2. D передаёт обычное сообщение DAO(tgt=D,pathseq=x+1,I_flag=1) в обновленный путь к C.

3. C проверяет наличие маршрутной записи от D (которой нет), создаёт новую запись и пересылает сведения о доступности целевого узла D узлу H в сообщении DAO(tgt=D,pathseq=x+1,I_flag=1).

4. Подобно C, узел H проверяет наличие маршрутной записи от D (её нет), создаёт запись и пересылает информацию о доступности цели D узлу A в сообщении DAO(tgt=D,pathseq=x+1,I_flag=1).

5. Узел A получает DAO(tgt=D,pathseq=x+1,I_flag=1) и проверяет наличие записи от узла D. Эта запись имеется и A проверяет в ней следующий интервал пересылки (next-hop) для D, который является другим (узел G). Затем A проверяет I_flag и создаёт сообщение DCO(tgt=D,pathseq=x+1) на прежний next-hop для цели D (узел G). Далее узел A обновляет маршрутную запись и пересылает сведения о доступности цели D в восходящем направлении, используя DAO(tgt=D,pathseq=x+1,I_flag=1).

6. Узел G получает DCO(tgt=D,pathseq=x+1) и сравнивает Path Sequence с сохраненным значением. Если новое значение свежее, G аннулирует маршрутную запись для цели D и пересылает сведения о (не)доступности в нисходящем направлении узлу B в сообщении DCO(tgt=D,pathseq=x+1).

7. Узел B аналогичным способом обрабатывает DCO(tgt=D,pathseq=x+1), аннулируя маршрутную запись для цели D и пересылает сведения о (не)доступности вниз узлу D.

8. Узел D игнорирует сообщение DCO(tgt=D,pathseq=x+1), поскольку сам является целью.

9. Распространение DCO будет останавливаться на любом узле, у которого нет маршрутной информации для цели. Если применяется кэширование маршрутных данных и кэшированное значение Path Sequence больше значения в DCO, сообщение DCO отбрасывается.

A.2. Пример сообщений DCO с несколькими предпочтительными родителями

На рисунке 5 показан выбор узлом (N41) нескольких предпочтительных родителей (N32) и (N33).

1.        (6LBR)
            |
            |
            |
          (N11)
           / \
          /   \
         /     \
      (N21)   (N22)
        /      / \
       /      /   \
      /      /     \
   (N31)  (N32)  (N33)
       :    |    /
        :   |   /
         :  |  /
          (N41)

   Рисунок 5. Пример топологии 2.

   
   (N41) передаёт сообщение DAO(tgt=N41,PS=x,I_flag=1) узлам (N32) и (N33). Значение I_flag указывает флаг аннулирования (Invalidation), а PS – Path Sequence в опции Transit Information.

2. (N32) передаёт DAO(tgt=N41,PS=x,I_flag=1) узлу (N22), а (N33) передаёт этому же узлу сообщение DAO(tgt=N41,PS=x,I_flag=1). (N22) узнает несколько маршрутов к одному получателю (N41) через разные next-hop. Узел (N22) может получить сообщения DAO от (N32) и (N33) с флагом I_flag в любом порядке. Реализации следует использовать таймер DelayDCO перед инициированием DCO. Если (N22) получает обновлённое сообщение DAO от всех путей, инициировать DCO не нужно. Таким образом, таблица маршрутизации N22 должна содержать (Dst,NextHop,PS): { (N41,N32,x), (N41,N33,x) }.

3. (N22) передаёт DAO(tgt=N41,PS=x,I_flag=1) узлу (N11).

4. (N11) передаёт DAO(tgt=N41,PS=x,I_flag=1) граничному маршрутизатору (6LBR). Это создаёт полный путь.

5. (N41) принимает решение о смене набора предпочтительных родителей { N32, N33 } на { N31, N32 }.

6. (N41) передаёт DAO(tgt=N41,PS=x+1,I_flag=1) узлу (N32) и DAO(tgt=N41,PS=x+1,I_flag=1) узлу (N31).

7. (N32) передаёт DAO(tgt=N41,PS=x+1,I_flag=1) узлу (N22). Узел (N22) имеет несколько маршрутов к адресату (N41). Он видит новое значение Path Sequence для Target=N41 и ждёт в течение заданного интервала (DelayDCO) перед аннулированием другого маршрута { (N41),(N33),x }. По истечении срока ожидания (N22) передаёт DCO(tgt=N41,PS=x+1) узлу (N33) и обычное сообщение DAO(tgt=N41,PS=x+1,I_flag=1) узлу (N11).

8. (N33) принимает DCO(tgt=N41,PS=x+1). Полученное значение Path Sequence является более поздним и аннулирует запись, связанную с целью (N41). Затем (N33) передаёт DCO(tgt=N41,PS=x+1) узлу (N41). Узел (N41) видит себя в качестве цели и отбрасывает DCO.

9. После п. 6 узел (N31) получает DAO(tgt=N41,PS=x+1,I_flag=1), в результате чего создаёт маршрутную запись и передаёт DAO(tgt=N41,PS=x+1,I_flag=1) узлу (N21), который получает DAO и в результате передаёт DAO(tgt=N41,PS=x+1,I_flag=1) узлу (N11).

10. (N11) получает DAO(tgt=N41,PS=x+1,I_flag=1) от (N21) и ждёт в течение DelayDCO, поскольку у него имеется несколько маршрутов к (N41). Узел (N41) получит DAO(tgt=N41,PS=x+1,I_flag=1) от (N22) (п. 7). Таким образом, (N11) получит обычные сообщения DAO(tgt=N41,PS=x+1,I_flag=1) от всех путей и не будет инициировать DCO.

11. (N11) пересылает DAO(tgt=N41,PS=x+1,I_flag=1) маршрутизатору (6LBR) и это создаёт полный путь.

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

Большое спасибо Alvaro Retana, Cenk Gundogan, Simon Duquennoy, Georgios Papadopoulos и Peter van der Stok за их рецензии и комментарии. Alvaro Retana помог создать окончательный вариант документа, внеся важные замечания.

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

Rahul Arvind Jadhav (editor)

Huawei

Whitefield

Kundalahalli Village

Bangalore 560037

Karnataka

India

Phone: +91-080-49160700

Email: rahul.ietf@gmail.com

Pascal Thubert

Cisco Systems, Inc.

Building D

45 Allee des Ormes – BP1200

06254 MOUGINS – Sophia Antipolis

France

Phone: +33-497-23-26-34

Email: pthubert@cisco.com

Rabi Narayan Sahoo

Huawei

Whitefield

Kundalahalli Village

Bangalore 560037

Karnataka

India

Phone: +91-080-49160700

Email: rabinarayans0828@gmail.com

Zhen Cao

Huawei

W Chang’an Ave

Beijing

China

Email: zhencao.ietf@gmail.com

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

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

nmalykh@protokols.ru