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

Заменен RFC 9111.

Internet Engineering Task Force (IETF)                        C. Bormann
Request for Comments: 7228                       Universitaet Bremen TZI
Category: Informational                                         M. Ersue
ISSN: 2070-1721                             Nokia Solutions and Networks
                                                              A. Keranen
                                                                Ericsson
                                                                May 2014

Terminology for Constrained-Node Networks

Терминология для сетей с ограниченными узлами

PDF

Аннотация

Расширяется применение стека протоколов Internet в мелких устройствах с некоторыми ограничениями по питанию, памяти и ресурсам обработки, образующих сети устройств с ограничениями (constrained-node network). Этот документ определяет множество базовых терминов, полезных для работ по стандартизации сетей из узлов с ограничениями.

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

Документ не относится к категории Internet Standards Track и публикуется лишь для информации.

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

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

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

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

Мелкие устройства с ограниченными ресурсами CPU, памяти и питания, называемые устройствами с огранисениями (constrained devices), часто применяемые в качестве датчиков и приводов, «умных» (smart) объектов или устройств, могут образовывать сети, становясь в них узлами с ограничениями. Такие сети сами по себе могут иметь ограничения, например, ненадёжные каналы с потерями, ограниченной и непредсказуемой пропускной способностью, быстро меняющейся топологией.

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

Сегодня к сетям подключаются устройства с разными ограничениями ресурсов и возможностей. Персональные мобильные гаджеты, устройства автоматизации зданий, сотовые телефоны, устройства межмашинного обмена (machine-to-machine или M2M) и другие устройства выигрывают от взаимодействия с другими «вещами» поблизости или в Internet. При этом Internet вещей (Internet of Things или IoT) становится реальностью, включающей однозначно идентифицируемые и адресуемые объекты (вещи). В следующем десятилетии число подключённых к Internet объектов с ограниченными возможностями может существенно вырасти [FIFTY-BILLION], увеличивая размер и охват Internet.

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

В этом документе термин «байт» (byte) используется в обычном смысле как синоним октета (битов). При указании размеров полупроводниковой памяти применяется префикс kibi (1024), например, kibibyte, обычно с сокращением до KiB (1024 байта) [ISQ-13].

В вычислительной технике термин power часто обозначает вычислительную мощность (computing power) или мощность обработки (processing power) как производительность CPU. В этом документе термин относится к электрической мощности (питание), если явно не указано иное. Термин «сетевое питание» (Mains-powered) служит для сокращённого обозначения подключения к стабильной сети электропитания.

2. Базовые термины

Имеется два важных аспекта расширяемости для IoT:

• расширяемость технологий Internet для большого числа [FIFTY-BILLION] недорогих устройств

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

Необходимость упрощения узлов (scaling down) ведёт к узлам с ограничениями.

2.1. Узлы с ограничениями

Термин «узел с ограничениями» (constrained node) лучше всего определять путём сопоставления характеристик узла с некоторыми широко распространёнными ожиданиями для более знакомых узлов Internet.

Constrained Node — узел с ограничениями

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

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

Другим термином, когда свойства сетевого узла не находятся в центре внимания, является constrained device — устройство с ограничениями.

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

• ограничение максимальной сложности кода (ROM/Flash);

• ограничения размера состояний и буферов (RAM);

• ограничение объёма вычислений за единицу времени (вычислительная мощность — processing power);

• ограничения по питанию;

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

В разделе 3 определено несколько классов (класс-N для N = 0, 1, 2) узлов с ограничениями, ориентированных на комбинации первых двух ограничений. В части доступного питания [RFC6606] различает энергоёмкие (power-affluent — питание от сети или регулярная зарядка) узлы от узлов с ограничением по питанию (power-constrained node), которые работают от батареи или устройства сбора энергии. Более подробно связанные с питанием термины рассмотрены в разделе 4.

Применение узлов с ограничениями в сетях часто задаёт ограничения для самих сетей. Однако в сетях могут быть свои ограничения, не зависящие от ограничений узлов. Поэтому здесь различаются сети с ограничениями (constrained network) и сети узлов с ограничениями (constrained-node network).

2.2. Сети с ограничениями

Аналогичным способом определяется сеть с ограничениями (constrained network).

Constrained Network — сеть с ограничениями

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

Ограничения могут включать:

• низкую скорость,пропускную способность (включая ограничения на рабочие циклы);

• значительные потери пакетов и большая вариативность числа потерь (скорость доставки);

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

• серьёзные издержки при использовании больших пакетов (например, большие потери в результате фрагментации на канальном уровне);

• ограничение доступности по времени (значительное число устройств может отключаться в любой момент, время от времени «просыпаться» для кратковременного обмена данными);

• отсутствие (или серьёзные ограничения) расширенных услуг, таких как групповая передача IP (multicast).

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

• ценовые ограничения;

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

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

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

• технологические ограничения, такие как устаревшие и низкоскоростные технологии, которые все ещё работают, и могут сохраняться ещё в течение некоторого времени.

2.2.1. Сети с проблемами

Сети с ограничениями не обязательно являются сетями с проблемами (challenged network) [FALL].

Challenged Network — сеть с проблемами

Сеть, в которой есть серьёзные проблемы с поддержкой ожиданий приложений в части сквозной модели IP:

• невозможно организовать сквозные соединения IP;

• серьёзные прерывания сквозной связности IP;

• задержки, превышающие максимальный срок существования сегментов (Maximum Segment Lifetime или MSL), заданный для TCP [RFC0793].

Все сети с проблемами являются в некотором смысле сетями с ограничениями, но все сети с ограничениями имеют проблемы. Чёткой границы здесь нет. Были разработаны устойчивые к задержкам сети (Delay-Tolerant Networking или DTN) для работы с проблемными сетями [RFC4838].

2.3. Сети узлов с ограничениями

Constrained-Node Network — сеть узлов с ограничениями

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

Сеть узлов с ограничениями всегда является сетью с ограничениями, из-за ограничений, вносимых узлами с ограничениями, но у неё могут быть и свои ограничения.

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

2.3.1. LLN

Термин, использовавшийся для описания сферы деятельности рабочей группы IETF ROLL (Low-Power and Lossy Network или LLN). Документ по терминологии ROLL (Routing Over Low-Power and Lossy) [RFC7102] определяет LLN.

LLN (Low-Power and Lossy Network) — сеть с недостаточным питанием и потерями

Обычно состоит из множества встраиваемых устройств с ограниченным питанием, памятью и ресурсами обработки, соединённых различными каналами, такими как IEEE 802.15.4 или Wi-Fi со слабым питанием. Существует широкая сфера применения LLN, включая промышленный мониторинг, автоматизацию зданий (обогрев, вентиляция и кондиционирование — HVAC, освещение, контроль доступа, противопожарная безопасность), подключение домов, здравоохранение, мониторинг окружающей среды, сети городских датчиков, управления энергией, отслеживание активов, охлаждение.

Кроме того, для LLN часто характерны значительные потери на физическом уровне с большой вариативностью скорости доставки и краткосрочной ненадёжностью в сочетании со среднесрочной стабильностью, что делает целесообразным построение направленных ациклических графов со среднесрочной стабильностью для маршрутизации и измерений на границах, таких как ожидаемое число передач (Expected Transmission Count или ETX) [RFC6551]. Не все LLN содержат узлы со слабым питанием [RPL-DEPLOYMENT].

LLN обычно состоят из узлов с ограничениями, это ведёт к разработке режимов работы, таких как non-storing (без сохранения), определённый в RPL [RFC6550]. Поэтому в данном документе LLN означает сеть узлов с ограничениями с определёнными характеристиками, которые включают и ограничения самой сети.

2.3.2. LoWPAN, 6LoWPAN

Интересным случаем сетей с ограничениями, часто применяемым для узлов с ограничениями, являются сети LoWPAN [RFC4919], названные по имени рабочей группы IEEE 802.15.4 LR-WPAN. Расшифровка акронима LoWPAN (Low-Power Wireless Personal Area Network) — низкоскоростные персональные беспроводные сети — содержит малопонятное слово Personal, связанное скорее с историей именования групп IEEE 802, нежели со сферой применения LoWPAN. Фактически эти сети были предложены для городского мониторинга и промышленного контроля и слово Personal можно считать просто пережитком. Иногда термин сокращают до Low-Power Wireless Area Network [WEI] (беспроводная сеть со слабым питанием). Первоначально связанный с IEEE 802.15.4, термином LoWPAN (6LoWPAN для случая IPv6) обозначают также сети с похожими технологиями канального уровня [V6-BTLE] [V6-DECT-ULE] [V6-G9959].

3. Классы узлов с ограничениями

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

Таблица 1. Классы устройств с ограничениями (KiB = 1024 байта).

 

Имя	Размер данных (например, RAM)	Размер кода (например, Flash)
Класс 0, C0	<< 10 KiB	<< 100 KiB
Класс 1, C1	~ 10 KiB	~ 100 KiB
Класс 2, C2	~ 50 KiB	~ 250 KiB

 

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

К классу 0 относятся очень ограниченные устройства, такие как датчики. У них обычно нет ресурсов, требуемых для безопасного прямого взаимодействия с Internet (несмотря на редкие героические попытки сделать это). Устройства класса 0 участвуют в коммуникациях Internet через более крупные устройства-посредниками, такие как proxy, шлюзы и серверы. Обычно для таких устройств недоступны традиционные средства защиты и управления. Скорей всего они будут настраиваться заранее (и настройка меняется редко или не меняется) с очень небольшим набором данных. Для управления они могут отвечать на сигналы keepalive и передавать базовые сведения о состоянии.

Устройства класса 1 очень ограничены в части пространства кода и возможностей обработки и им сложно взаимодействовать с другими устройствами Internet, реализующими полный стек протоколов, такими как HTTP, TLS (Transport Layer Security), протоколы защиты и представление данных на основе XML. Однако они могут использовать специализированные для устройств с ограничениями стеки протоколов, такие как CoAP (Constrained Application Protocol) на основе UDP [COAP], т участвовать в осмысленных обмена без помощи шлюзов. В частности, они могут поддерживать функции защиты, требуемые в больших сетях. Такие устройства могут интегрироваться в сети IP как партнёры, но должны экономно расходовать память, пространство кода и экономить энергию при работе приложений.

Устройства класса 2 не так ограничены и обычно способны поддерживать большинство протокольных стеков, применяемых в ноутбуках и серверах. Однако для таких устройств важны облегчённые и энергоэффективные протоколы, а также малый расход пропускной способности. Кроме того, снижение объёма ресурсов для работы в сети оставляет больше ресурсов для приложений. Таким образом, применение специализированных стеков на устройствах класса 2 может снизить стоимость развёртывания и повысить уровень совместимости.

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

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

4. Термины в части питания

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

4.1. Свойства расширяемости

Питание (энергия), доступное устройству, может сильно различаться (от микроватт до киловатт, от микроджоулей, до практически неограниченной энергии). Вместо задания классов или кластеров предлагается просто использовать единицы международной системы СИ (International System of Units — SI units) в качестве приближения (Таблица 2)

Таблица 2. Параметры, связанные с мощностью и энергией.

 

Имя	Определение	SI Unit
Ps	Средняя мощность в установившемся состоянии, доступная для работы устройства	Вт (W, Watt)
Et	Общая электрическая энергия, которую способен обеспечить источник питания	Дж (J, Joule)

 

Значение Et может интерпретироваться в сочетании с периодом времени (см. параграф 4.2).

Некоторые устройства переходят в режим экономии (low-power) до исчерпания доступной энергии и даже применять несколько таких режимов. Для таких устройств значение Ps нужно указывать в каждом из поддерживаемых режимов.

4.2. Классы ограничения энергии

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

В таблице 3 дана свода перечисленных выше устройств.

Таблица 3. Классы ограничений по энергии.

Имя	Тип ограничения	Пример источника питания
E0	Ограничение энергии для события	Сбор энергии по событию
E1	Ограничение энергии для интервала времени	Периодическая зарядка или замена батарей
E2	Ограничение энергии для срока действия	Незаменяемая батарея питания
E9	Нет прямых количественных ограничений доступной энергии	Питание от электросети

4.3. Стратегия использования питания для коммуникаций

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

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

Always-on — всегда включено

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

Normally-off — обычно выключено

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

Low-power — режим экономии

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

В таблице 4 приведена сводка описанных выше стратегий.

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

 

Имя	Стратегия	Способность к взаимодействию
P0	Обычно выключено	Повторное подключение при необходимости
P1	Энергосбережение	Представляется подключённым, возможно с задержкой
P9	Всегда включено	Всегда подключено

 

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

При описании подходов к энергосбережению часто применяется термин «рабочий цикл» (duty-cycling), он описывает все формы периодического отключения некоторых функций, оставляя их включёнными лишь на некоторое время (duty cycle).

В [RFC7102] различаются лишь 2 уровня, определяющие неспящий узел (Non-Sleepy Node) как узел, всегда сохраняющий полное питание (всегда активен), когда имеется возможность коммуникаций (P9), а засыпающий узел (Sleepy Node) как узел, иногда переходящий в режим сна (снижение потребления энергии в целях экономии) и отключающий протокольные коммуникации (P0). Явного упоминания P1 в документе нет.

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

Документ вводит базовую терминологию, не создавая новых проблем безопасности. Вопросы безопасности, связанные с рассматриваемыми в документе ограничениями, должны обсуждаться в контексте конкретных протоколов. Например, в параграфе 11.6 [COAP] рассматривается влияние конкретных ограничение на развёртывание механизмов защиты. В [ROLL-SEC-THREATS] приведён анализ угроз безопасности для протокола маршрутизации RPL. Вопросы реализации протоколов защиты на узлах с ограничениями рассмотрены в [IKEV2-MINIMAL] и [TLS-MINIMAL]. Общие соображения безопасности сетей из узлов с ограничениями представлены в [IOT-SECURITY].

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

Dominique Barthel и Peter van der Stok предоставили полезные замечания, Charles Palmer — редакторскую рецензию. Peter van der Stok настоял на включение терминов, связанных с питанием (раздел 4). Текст параграфа 4.3 в основном взят из предыдущей версии [COAP-CELLULAR] и адаптирован для этого документа.

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

[COAP] Shelby, Z., Hartke, K., and C. Bormann, «Constrained Application Protocol (CoAP)», Work in Progress³, June 2013.

[COAP-CELLULAR] Arkko, J., Eriksson, A., and A. Keranen, «Building Power-Efficient CoAP Devices for Cellular Networks», Work in Progress⁴, February 2014.

[FALL] Fall, K., «A Delay-Tolerant Network Architecture for Challenged Internets», SIGCOMM 2003, 2003.

[FIFTY-BILLION] Ericsson, «More Than 50 Billion Connected Devices», Ericsson White Paper 284 23-3149 Uen, February 2011, <http://www.ericsson.com/res/docs/whitepapers/wp-50-billions.pdf>.

[IKEV2-MINIMAL] Kivinen, T., «Minimal IKEv2», Work in Progress, October 2013.

[IOT-SECURITY] Garcia-Morchon, O., Kumar, S., Keoh, S., Hummen, R., and R. Struik, «Security Considerations in the IP-based Internet of Things», Work in Progress, September 2013.

[ISQ-13] International Electrotechnical Commission, «International Standard — Quantities and units — Part 13: Information science and technology», IEC 80000-13, March 2008.

[RFC0793] Postel, J., «Transmission Control Protocol», STD 7, RFC 793, September 1981.

[RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, R., Scott, K., Fall, K., and H. Weiss, «Delay-Tolerant Networking Architecture», RFC 4838, April 2007.

[RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, «IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals», RFC 4919, August 2007.

[RFC6550] Winter, T., Thubert, P., 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.

[RFC6551] Vasseur, JP., Kim, M., Pister, K., Dejean, N., and D. Barthel, «Routing Metrics Used for Path Calculation in Low-Power and Lossy Networks», RFC 6551, March 2012.

[RFC6606] Kim, E., Kaspar, D., Gomez, C., and C. Bormann, «Problem Statement and Requirements for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Routing», RFC 6606, May 2012.

[RFC7102] Vasseur, JP., «Terms Used in Routing for Low-Power and Lossy Networks», RFC 7102, January 2014.

[ROLL-SEC-THREATS] Tsao, T., Alexander, R., Dohler, M., Daza, V., Lozano, A., and M. Richardson, «A Security Threat Analysis for Routing Protocol for Low-power and lossy networks (RPL)», Work in Progress⁵, December 2013.

[RPL-DEPLOYMENT] Vasseur, J., Ed., Hui, J., Ed., Dasgupta, S., and G. Yoon, «RPL deployment experience in large scale networks», Work in Progress, July 2012.

[TLS-MINIMAL] Kumar, S., Keoh, S., and H. Tschofenig, «A Hitchhiker’s Guide to the (Datagram) Transport Layer Security Protocol for Smart Objects and Constrained Node Networks», Work in Progress, March 2014.

[V6-BTLE] Nieminen, J., Ed., Savolainen, T., Ed., Isomaki, M., Patil, B., Shelby, Z., and C. Gomez, «Transmission of IPv6 Packets over BLUETOOTH Low Energy», Work in Progress⁶, May 2014.

[V6-DECT-ULE] Mariager, P., Ed., Petersen, J., and Z. Shelby, «Transmission of IPv6 Packets over DECT Ultra Low Energy», Work in Progress⁷, July 2013.

[V6-G9959] Brandt, A. and J. Buron, «Transmission of IPv6 packets over ITU-T G.9959 Networks», Work in Progress⁸, May 2014.

[WEI] Shelby, Z. and C. Bormann, «6LoWPAN: the Wireless Embedded Internet», ISBN 9780470747995, 2009.

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

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

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

nmalykh@protokols.ru

Internet Engineering Task Force (IETF)                        A. Sajassi
Request for Comments: 7209                                         Cisco
Category: Informational                                      R. Aggarwal
ISSN: 2070-1721                                                   Arktan
                                                               J. Uttaro
                                                                    AT&T
                                                                N. Bitar
                                                                 Verizon
                                                           W. Henderickx
                                                          Alcatel-Lucent
                                                                A. Isaac
                                                               Bloomberg
                                                                May 2014

Requirements for Ethernet VPN (EVPN)

Требования к Ethernet VPN (EVPN)

PDF

Аннотация

Широкое распространение услуг Ethernet L2VPN и появление новых применений технологии (например, соединение ЦОД) привели к возникновению набора новых требований, которые не всегда выполняются современными решениями для виртуальных частных ЛВС (Virtual Private LAN Service или VPLS). В частности, не поддерживается многодомность с пересылкой всем активным (all-active) и нет решения для использования путей с коммутацией по меткам (Label Switched Path или LSP) «многие со многими» (Multipoint-to-Multipoint или MP2MP) для оптимизации доставки кадров с множеством получателей. Кроме того, предоставление услуг VPLS даже в контексте основанного на BGP автоматического обнаружения требует от операторов сети указания различных сетевых параметров в дополнение к конфигурации доступа. Этот документ задаёт требования к решениям Ethernet VPN (EVPN) для решения этих проблем.

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

Этот документ не является спецификацией проекта стандарта Internet и публикуется с информационными целями.

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

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

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

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

Виртуальные частные ЛВС (VPLS), определённые в [RFC4664], [RFC4761] и [RFC4762], являются проверенной и широко развёрнутой технологией. Однако у имеющихся решений есть много ограничений в части резервирования, оптимизации групповой передачи и простоты предоставления. Кроме того, новые применения внесли дополнительные требования для других услуг L2VPN, таких как деревья Ethernet (Ethernet Tree или E-Tree) и виртуальные частные провода (Virtual Private Wire Service или VPWS).

В части многодомности современные VPLS могут поддерживать несколько адресов лишь в режиме резервирования single-active (активен один), например, как описано в [VPLS-BGP-MH]. Гибкая многодомность в режиме all-active (активны все) не поддерживается в имеющихся решениях VPLS.

В части оптимизации групповой передачи [RFC7117] описывает способ применения групповых LSP в сочетании с VPLS. Однако это решение ограничено LSP «один со многими» (Point-to-Multipoint или P2MP), поскольку нет определения для многоточечных (Multipoint-to-Multipoint или MP2MP) LSP с VPLS.

В части простоты предоставления текущие VPLS не предлагают механизма одностороннего предоставления, полагаясь на автоматическое обнаружение служб на основе BGP [RFC4761] [RFC6074]. Однако это требует от оператора настройки множества параметров на стороне сети в дополнение к настройке Ethernet на стороне доступа.

В части соединений между ЦОД приложения требуют новых типов интерфейсов служб, комбинирующих свойства интерфейсов со связкой VLAN (bundling) и интерфейсов на основе VLAN. Их называют интерфейсами связывания с поддержкой VLAN (VLAN-aware bundling).

Приложения виртуализации повышают число MAC³-адресов, обрабатываемых в сети, и это требует, чтобы повторное схождение сети после отказа не зависело от числа MAC-адресов, узнанных границей провайдера (Provider Edge или PE).

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

Имеются требования по поддержке гибкости топологии и политики VPN сверх доступной сегодня в VPLS и Hierarchical VPLS (H-VPLS).

Основное внимание в этом документе уделено заданию требований к новому решению — Ethernet VPN (EVPN), которое преодолеет упомянутые проблемы. В разделе 4 рассмотрены требования к резервированию, в разделе 5 — к оптимизации групповой передачи. В разделе 5 сформулированы требования к предоставлению услуг, а раздел 7 посвящён новым требованиям к интерфейсу сервиса. В разделе 8 рассмотрены требования к быстрому схождению, в разделе 9 — к подавлению лавинной рассылки, а в разделе 10 — к поддержке гибкости топологии и правил VPN.

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

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

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

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

AS

Автономная система.

CE

Граница клиента.

E-Tree

Дерево Ethernet.

MAC address

Адрес управления доступом к среде — MAC-адрес.

LSP

Путь с коммутацией по меткам.

PE

Граница провайдера.

MP2MP

Многие со многими.

VPLS

Служба виртуальной частной ЛВС.

Single-Active Redundancy Mode

Когда многодомное устройство или сеть подключены к группе из двух или более PE и лишь одно из устройств PE в этой группе может пересылать трафик многотомному устройству или сети (и от них) для данной VLAN, такую многодомную систему называют Single-Active (активен один).

All-Active Redundancy Mode

Когда многодомное устройство или сеть подключены к группе из двух или более PE и все PE группы могут пересылать трафик многотомному устройству или сети (и от них) для данной VLAN, такую многодомную систему называют All-Active (активны все).

4. Требования к избыточности

4.1. Распределение нагрузки по потокам

Базовый механизм работы многодомного узла CE с набором узлов PE включает применение групп агрегирования каналов Ethernet (link aggregation group или LAG) с несколькими шасси на основе [802.1AX]. В [PWE3-ICCP] описана одна из таких схем. При объединении каналов Ethernet алгоритмы распределения нагрузки, с помощью которых CE распределяет трафик между устройствами подключения (AC) к разным PE, достаточно гибки. Единственным требованием к алгоритмам является обеспечения упорядоченной доставки кадров данного потока трафика. В типичных реализациях эти алгоритмы включают выбор исходящего канала внутри группы на основе хэш-функции, указывающей поток по одному или нескольким полям, указанным ниже.

1. L2: MAC-адреса отправителя и получателя, VLAN.

2. L3: IP-адреса отправителя и получателя.

3. L4: порты UDP или TCP у отправителя и получателя.

Важно отметить, что [802.1AX] не определяет стандартный алгоритм распределения нагрузки для связки каналов Ethernet, поэтому поведение разных реализаций различается. На деле связка каналов корректно работает даже при неравномерной загрузке каналов. В этом случае первым требованием для режима all-active является способность обеспечивать гибкое распределение нагрузки на основе потоков от узла CE по полям заголовков L2, L3, L4.

(R1a) Решение должно поддерживать гибкое распределение нагрузки по потокам от CE, как указано выше.

(R1b) Решение должно поддерживать распределение по потокам трафика, направленного в CE, даже при подключении CE к нескольким PE. Таким образом, решение должно быть способно использовать несколько каналов, подключённых к CE, независимо от числа PE, с которыми соединён узел CE.

Следует отметить, что при соединении CE с несколькими PE, возможны равноценные (Equal-Cost Multipath или ECMP) пути от каждого удалённого PE к каждому многодомному PE. Кроме того, для многодомных CE в режиме all-active удалённый PE может выбрать любой из многодомных узлов PE для передачи трафика, адресованного многодомному CE. Следовательно, при поддержке решением режима all-active оно должно использовать как можно больше таких путей для трафика к многодомному CE.

(R1c) Решению следует поддерживать распределение нагрузки по потокам среди PE, являющихся членами группы резервирования, охватывающей несколько автономных систем (AS).

4.2. Множество путей по потокам

Любое решение, соответствующее режиму избыточности all-active (например, распределение нагрузки по потокам), описанному в параграфе 4.1, должно также использовать множество путей между данной парой PE. Например, при наличии 2 или более LSP между удаленным PE и парой PE в группе all-active, решение должно поддерживать распределение нагрузки этих LSP по потокам для трафика, направленного PE из группы с избыточностью. Кроме того, при наличии 2 или более путей ECMP между удаленным PE и одним из PE в группе с избыточностью решение должно использовать все равноценные LSP. В последнем случае решение может также применять распределение нагрузки на основе меток энтропии [RFC6790].

(R2a) Решение должно быть способно использовать все LSP между удалённым PE и всеми PE из группы с избыточностью в режиме all-active.

(R2b) Решение должно быть способно использовать все пути ECMP между удалённым PE и любым PE из группы с избыточностью в режиме all-active.

Рассмотрим как пример систему, где устройство CE1 подключено к PE1 и PE2, а CE2 — к PE3 и PE4 в режиме all-active. Кроме того, имеется три пути ECMP между PE устройств CE1 и CE2. Трафик от CE1 к CE2 может пересылаться по 12 разным путям через ядро MPLS/IP. CE1 распределяет нагрузку между PE1 и PE2, у каждого из которых имеется 3 пути ECMP к PE3 и PE4, что даёт 12 путей в целом. Когда трафик прибывает на PE3 и PE4, он пересылается CE2 по каналу Ethernet (связка каналов).

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

4.3. Географически распределенные узлы PE

Узлы PE, предоставляющие многодомную связность CE или сети доступа, могут размещаться в одном месте (co-located) или быть распределены географически (например, в разных CO⁴ или POP⁵). Последнее требуется для предоставления географической избыточности, которая обеспечивает непрерывность бизнеса при критических повреждениях в случае отключения питания, стихийных бедствий и т. п. Многодомный режим all-active нужен для поддержки обоих вариантов размещения PE. При географическом удалении выделенный канал между PE зачастую не является привлекательным решением с точки зрения расходов. Кроме того, нельзя предполагать, что стоимость IGP от удалённых PE к паре PE в двудомной будет одинаковой при географическим разделении этих PE.

(R3a) Решение должно поддерживать многодомный режим all-active, не требуя выделенного канала данных-управления между PE многодомной группы.

(R3b) Решение должно поддерживать разную стоимость IGP от удалённого PE к каждому из PE многодомной группы.

(R3c) Решение должно поддерживать многодомность через разные домены IGP в одной AS.

(R3d) Решение должно поддерживать многодомность через разные AS.

4.4. Оптимальная пересылка трафика

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

(R4) Многодомным решениям all-active следует поддерживать оптимальную пересылку индивидуального трафика для всех указанных ниже случаев. Оптимальной считается пересылка, где трафик не пересылается между устройствами PE одной многодомной группы, пока целевое устройство CE не подключено к одному из многодомных PE.

1. От однодомного CE к многодомному CE.

2. От многодомного CE к однодомному CE.

3. От многодомного CE к многодомному CE

Это особенно важно в случаях географически разнесённых PE, где пересылка трафика от одного PE к другому в той же многодомной группе вносит дополнительную задержку в добавок к неэффективном использованию пересылки узла PE и ядра. Многодомной (используется также термин multi-chassis LAG) считается группа PE, поддерживающих многодомный CE.

4.5. Поддержка гибкой группировки избыточности

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

Это лучше всего объяснить на примере. Рассмотрим 3 узла PE — PE1, PE2, PE3. Многодомный механизм должен позволять данному PE, скажем , PE1, входить одновременно в разные группы с избыточностью. Например, могут быть группы (PE1, PE2), (PE1, PE3), (PE2, PE3), где узлы CE могут быть подключены к любой из этих трёх групп с избыточностью.

4.6. Многодомная сеть

Имеются приложения, которым для подключения к многодомной группе PE нужна сеть Ethernet, а не отдельное устройство. Сеть Ethernet обычно использует механизмы избыточности, такие как протокол MSTP⁶ [802.1Q] или защитное переключение в кольце Ethernet (Ring Protection Switching) [G.8032]. PE могут (но не обязаны) принимать участие в работе протокола управления сетью Ethernet. Для многодомных сетей, применяющих [802.1Q] или [G.8032], эти протоколы требуют, чтобы каждая сеть VLAN была активна лишь на одном из многодомных каналов.

(R6a) Решение должно поддерживать подключение к многодомной сети в режиме single-active redundancy, где все VLAN активны на одном PE.

(R6b) Решение должно поддерживать многодомные сети в режиме single-active, где неперекрывающиеся наборы VLAN активны на разных PE.

(R6c) Решению следует поддерживать режим single-active среди PE, принадлежащими к группе с избыточностью, охватывающей несколько AS.

(R6d) Решение может поддерживать режим all-active для многодомной сети с распределением нагрузки на основе MAC (т. е. разные MAC-адреса в VLAN доступны через разные PE).

5. Требования к оптимизации групповой передачи

Имеются среды, где использование MP2MP LSP может быть желательно для оптимизации группового, широковещательного и индивидуального трафика с неизвестным адресатом для снижения числа групповых состояний в маршрутизаторах ядра. [RFC7117] исключает применение MP2MP LSP поскольку текущие решения VPLS требуют от входного PE обучения при получении через LSP индивидуальных пакетов с неизвестным адресатом. Это сложно при использовании MP2MP LSP, поскольку здесь нет унаследованного механизма идентификации отправителя. Применение MP2MP LSP для групповой оптимизации становится приемлемым, если отпадает необходимость определять отправителя при обучении.

(R7a) Решение должно быть способно предоставить механизм, не требующий обучения MAC для MPLS LSP при получении пакетов через MP2MP LSP.

(R7b) Решение должно быть способно предоставить процедуры использования MP2MP LSP для оптимизации доставки группового, широковещательного и индивидуального трафика с неизвестным получателем.

6. Требования к простоте предоставления

По мере внедрения технологий L2VPN в сети предприятий простота предоставления становится первостепенной задачей. Хотя современные VPLS имеют механизм автоматического обнаружения, позволяющий находить PE данного экземпляра VPN через сеть ядра MPLS/IP, требуется дальнейшее упрощение.

(R8a) Решение должно поддерживать автоматическое обнаружение PE в VPN через сеть ядра MPLS/IP подобно механизму автоматического обнаружения VPLS, описанному в [RFC4761] и [RFC6074].

(R8b) Решению следует поддерживать автоматическое обнаружение PE данной группы с избыточностью или многодомной группы.

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

(R8d) Решению следует поддерживать автоматизированный выбор DF⁷ среди PE, участвующей в группе с избыточностью (многодомной) и обеспечивать возможность делить экземпляры службы (например, VLAN) между PE в группе с избыточностью.

(R8e) Для развёртываний, где идентификаторы VLAN глобальны в масштабе сети MPLS (т. е. сеть поддерживает не более 4K служб), устройствам PE следует выводить относящиеся к MPLS атрибуты (например, VPN ID, BGP Route Target и т. п.) из идентификатора VLAN. Таким образом, сетевому оператору достаточно задать идентификаторы VLAN для устройств доступа, и все параметры MPLS и BGP, требуемые для организации сервиса через сеть ядра, будут выведены автоматически и не потребуют явной настройки.

(R8f) Реализациям следует возвращаться к принятым по умолчанию значениям параметров, для которых новые значения не заданы.

7. Новые требования к интерфейсу службы

Для [MEF] и [802.1Q] заданы приведённые ниже службы.

• Режим порта — весь трафик на порту отображается в один домен мостов и один соответствующий экземпляр сервиса L2VPN. Для клиентских VLAN гарантируется сквозная прозрачность.

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

• Связка VLAN (bundling) — группа VLAN на порту коллективно отображается в уникальный домен мостов и соответствующий экземпляр сервиса L2VPN. Клиентские адреса MAC должны быть уникальными во всех VLAN, отображаемых в один экземпляр сервиса.

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

Следует отметить, что термин домен мостов (bridge domain) относится к таблице пересылки MAC определённой в модели моста IEEE, и не означает и не предполагает определённой реализации.

В [RFC4762] определены два типа служб VPLS на основе неквалифицированного и квалифицированного обучения, которые, в свою очередь делятся на режим порта и VLAN.

(R9a) Решение должно поддерживать 3 указанных выше типа служб (порт, VLAN, связка VLAN).

Для размещённых приложений соединения ЦОД сетевым операторам нужна возможность расширять Ethernet VLAN через каналы WAN с использованием обного экземпляра L2VPN, сохраняя при этом разделение плоскостей данных разных VLAN в этом экземпляре. Это называется связкой с пооддержкой VLAN (VLAN-aware bundling).

(R9b) Решение может поддерживать услугу VLAN-aware bundling.

Это ведёт к появлению двух новых типов интерфейсов сервиса: VLAN-aware bundling с трансляцией и без таковой.

Сервисный интерфейс для VLAN-aware bundling без трансляции имеет указанные ниже характеристики.

• Обеспечивает связывание клиентских VLAN в один экземпляр сервиса L2VPN.

• Гарантирует сквозную прозрачность для клиентских VLAN.

• Поддерживает разделение плоскостей данных между клиентскими VLAN (т. е. создаёт выделенный домен мостов на VLAN).

В особом случае связывания всех с одним (all-to-one) интерфейсу сервиса недопустимо предполагать заранее какие-либо сведения о клиентских VLAN. Иными словами, VLAN клиента не нужно настраивать на PE, а вместо этого интерфейс настраивается как для услуги на основе порта.

Сервисный интерфейс для VLAN-aware bundling с трансляцией имеет указанные ниже характеристики.

• Обеспечивает связывание клиентских VLAN в один экземпляр сервиса L2VPN.

• Поддерживает разделение плоскостей данных между клиентскими VLAN (т. е. создаёт выделенный домен мостов на VLAN).

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

Основным различием в плане выделения ресурсов сервис-провайдером между этими новыми типами услуг и определёнными ранее тремя типами является то, что новым службам нужно выделять несколько доменов мостов (по одному на VLAN клиента) на экземпляр сервиса L2VPN, а прежним достаточно одного домена на экземпляр L2VPN.

8. Быстрое схождение

(R10a) Решение должно обеспечивать возможность восстановления после отказов устройства соединения PE-CE, а также отказов узлов PE для многодомного устройства и многодомной сети.

(R10b) Механизм восстановления должен обеспечивать время схождения, не зависящее от числа MAC-адресов, изученных PE. Это особенно важно в контексте приложений виртуализации, которые способствуют росту числа MAC-адресов, обрабатываемых сетью L2.

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

9. Подавление лавинной рассылки

(R11a) Решению следует разрешать оператору сети выбирать, отбрасывание или лавинную рассылку индивидуальных кадров с неизвестным адресатом. Этот атрибут должен быть настраиваемым на уровне экземпляра службы.

(R11b) При использовании решения для соединения ЦОД ему следует минимизировать лавинную рассылку широковещательных кадров за пределы данного сайта. Особенный интерес представляет периодический трафик протокола распознавания адресов (Address Resolution Protocol или ARP).

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

10. Гибкая поддержка топологии и политики VPN

(R12a) Решение должно поддерживать гибкость топологии VPN, не ограниченной базовыми механизмами решения.

Одним из примеров является топология E-Tree, где один или несколько сайтов в VPN являются корнями, а другие — листьями. Корням можно передавать трафик в другие корни и листья, а листьям разрешено взаимодействовать лишь с корнями. Решение должно обеспечивать возможность поддержки топологии E-Tree.

(R12b) Решение может обеспечивать возможность применения правил на уровне MAC-адресов, чтобы контролировать, какие PE в VPN узнают о каких MAC-адресах и как пересылается трафик для конкретного MAC. Следует предусматривать возможность применения правил, позволяющих лишь некоторым PE в VPN передавать или принимать трафик для конкретных MAC-адресов.

(R12c) Решение должно быть способно поддерживать между AS варианты C и B, описанные в разделе 10 [RFC4364].

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

Расширениям протоколов для EVPN нужно включать подобающий анализ безопасности. Помимо требований безопасности, описанных в [RFC4761] и [RFC4762] для изучения MAC в плоскости данных и [RFC4364] для изучения MAC в плоскости управления, нужно охватывать указанные ниже аспекты.

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

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

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

[802.1AX] IEEE, «IEEE Standard for Local and metropolitan area networks — Link Aggregation», Std. 802.1AX-2008, IEEE Computer Society, November 2008.

[802.1Q] IEEE, «IEEE Standard for Local and metropolitan area networks — Virtual Bridged Local Area Networks», Std. 802.1Q-2011, 2011.

[G.8032] ITU-T, «Ethernet ring protection switching», ITU-T Recommendation G.8032, February 2012.

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

[RFC4364] Rosen, E. and Rekhter, Y., «BGP/MPLS IP Virtual Private Networks (VPNs)», RFC 4364, February 2007⁸.

[RFC4761] Kompella, K., Ed., and Y. Rekhter, Ed., «Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling», RFC 4761, January 2007.

[RFC4762] Lasserre, M., Ed., and V. Kompella, Ed., «Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling», RFC 4762, January 2007.

[RFC6074] Rosen, E., Davie, B., Radoaca, V., and W. Luo, «Provisioning, Auto-Discovery, and Signaling in Layer 2 Virtual Private Networks (L2VPNs)», RFC 6074, January 2011.

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

[VPLS-BGP-MH] Kothari, B., Kompella, K., Henderickx, W., Balue, F., Uttaro, J., Palislamovic, S., and W. Lin, «BGP based Multi-homing in Virtual Private LAN Service», Work in Progress, July 2013.

[PWE3-ICCP] Martini, L., Salam, S., Sajassi, A., and S. Matsushima, «Inter-Chassis Communication Protocol for L2VPN PE Redundancy», Work in Progress⁹, March 2014.

[MEF] Metro Ethernet Forum, «Ethernet Service Definitions», MEF 6.1 Technical Specification, April 2008.

[RFC4664] Andersson, L., Ed., and E. Rosen, Ed., «Framework for Layer 2 Virtual Private Networks (L2VPNs)», RFC 4664, September 2006.

[RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and L. Yong, «The Use of Entropy Labels in MPLS Forwarding», RFC 6790, November 2012.

[RFC7117] Aggarwal, R., Ed., Kamite, Y., Fang, L., Rekhter, Y., and C. Kodeboniya, «Multicast in Virtual Private LAN Service (VPLS)», RFC 7117, February 2014.

14. Участники работы

Samer Salam, Cisco, ssalam@cisco.com

John Drake, Juniper, jdrake@juniper.net

Clarence Filsfils, Cisco, cfilsfil@cisco.com

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

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

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

nmalykh@protokols.ru

Internet Engineering Task Force (IETF)                      M. Bjorklund
Request for Comments: 7223                                Tail-f Systems
Category: Standards Track                                       May 2014
ISSN: 2070-1721

A YANG Data Model for Interface Management

Модель данных YANG для управления интерфейсом

PDF

Аннотация

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

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

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

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

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

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

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

Этот документ определяет модель данных YANG [RFC6020] для управления сетевыми интерфейсами. Предполагается, что базовая модель будет дополнена (augment) моделями данных для конкретных типов интерфейсов.

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

Модель включает данные конфигурации и состояния (информация о состоянии и счетчики статистики).

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

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

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

system-controlled interface – управляемый системой интерфейс

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

user-controlled interface – управляемый пользователем интерфейс

Интерфейс называют управляемым пользователем (user-controlled), если создание интерфейса определяется его явной настройкой в хранилище рабочей конфигурации, а удаление — явным удалением конфигурации интерфейса из этого хранилища. Примерами являются интерфейсы VLAN, настроенные на управляемых системой интерфейсах Ethernet.

Ниже приведен список используемых терминов из [RFC6241].

• client — клиент;

• configuration data — данные конфигурации;

• server — сервер;

• state data — данные состояния.

Ниже приведен список используемых терминов из [RFC6020].

• augment — дополнение;

• data model — модель данных;

• data node — узел данных;

• presence container — контейнер присутствия.

1.2. Диаграммы деревьев

В этом документе применяется упрощенное графическое представление данных. Назначение символов описано ниже.

• Ключи списков указываются в квадратных скобках [].

• Сокращения перед именами узлов задают режим доступа — rw для данных конфигурации (чтение и запись), ro для данных состояния (только чтение).

• Символ ? после узла данных указывает необязательный узел, ! — контейнер присутствия, * — список или лист-список.

• В круглых скобках указываются узлы выбора (choice) и вариантов (case), последние также маркируются двоеточием (:).

• Троеточие (…) указывает пропущенное содержимое субдерева.

2. Цели

В этом разделе описаны некоторые из целей разработки модели, представленной в разделе 5.

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

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

• Ссылки на интерфейсы должны быть как можно проще, предпочтительно с использованием одного leafref.

• Отображение на ifIndex [RFC2863], используемое протоколом SNMP³ для указания интерфейсов, должно быть четким.

• Модель должна поддерживать уровни интерфейсов — как (1) простые, где один интерфейс работает поверх единственного другого, так и (2) более сложные, где один интерфейс может быть результатом агрегирования N других интерфейсов или N интерфейсов могут мультиплексироваться в один.

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

• Модель данных должна поддерживать как физические, так и логические интерфейсы.

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

3. Модель данных интерфейса

Этот документ определяет модуль YANG ietf-interfaces, структура которого показана ниже.

      +--rw interfaces
      |  +--rw interface* [name]
      |     +--rw name                        string
      |     +--rw description?                string
      |     +--rw type                        identityref
      |     +--rw enabled?                    boolean
      |     +--rw link-up-down-trap-enable?   enumeration
      +--ro interfaces-state
         +--ro interface* [name]
            +--ro name               string
            +--ro type               identityref
            +--ro admin-status       enumeration
            +--ro oper-status        enumeration
            +--ro last-change?       yang:date-and-time
            +--ro if-index           int32
            +--ro phys-address?      yang:phys-address
            +--ro higher-layer-if*   interface-state-ref
            +--ro lower-layer-if*    interface-state-ref
            +--ro speed?             yang:gauge64
            +--ro statistics
               +--ro discontinuity-time    yang:date-and-time
               +--ro in-octets?            yang:counter64
               +--ro in-unicast-pkts?      yang:counter64
               +--ro in-broadcast-pkts?    yang:counter64
               +--ro in-multicast-pkts?    yang:counter64
               +--ro in-discards?          yang:counter32
               +--ro in-errors?            yang:counter32
               +--ro in-unknown-protos?    yang:counter32
               +--ro out-octets?           yang:counter64
               +--ro out-unicast-pkts?     yang:counter64
               +--ro out-broadcast-pkts?   yang:counter64
               +--ro out-multicast-pkts?   yang:counter64
               +--ro out-discards?         yang:counter32
               +--ro out-errors?           yang:counter32

3.1. Списки интерфейсов

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

Модуль iana-if-type [RFC7224] определяет отождествления YANG для типов интерфейсов в поддерживаемом IANA реестре «ifType definitions».

Имеется один список настроенных интерфейсов (/interfaces/interface) и отдельный список рабочих состояний интерфейсов (/interfaces-state/interface).

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

В качестве примера возможного дополнения для конкретного типа интерфейса рассмотрим приведенный ниже фрагмент кода YANG. Более полный пример приведен в Приложении A.

     import interfaces {
         prefix "if";
     }
     import iana-if-type {
       prefix ianaift;
     }

     augment "/if:interfaces/if:interface" {
         when "if:type = 'ianaift:ethernetCsmacd'";

         container ethernet {
             leaf duplex {
                 ...
             }
         }
     }

Для управляемых системой интерфейсов name является зависимым от устройства именем интерфейса. Не являющийся конфигурационным (config false) список «/interfaces-state/interface» содержит все имеющиеся на устройстве интерфейсы.

Если устройство поддерживает произвольное именование управляемых пользователем интерфейсов, сервер NETCONF⁴ анонсирует свойство arbitrary-names. Если устройство не анонсирует это свойство, имена управляемых пользователем интерфейсов должны соответствовать схеме именования для устройства. Способ получения клиентом информации о схемах именования таких устройств выходит за рамки документа. Примеры приведены в приложениях E.1 и E.2.

Когда система создает управляемый ею интерфейс, она пытается применить конфигурацию из /interfaces/interface с именем нового интерфейса. Если такой конфигурации не найдено или заданный в конфигурации тип не соответствует типу реального интерфейса, система создает интерфейс без применения явной конфигурации.

При создании управляемого пользователем интерфейса имя этого интерфейса определяет конфигурация.

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

3.2. Указание интерфейсов

Интерфейс указывается именем, которое уникально в рамках сервера. Это свойство фиксируется в определениях типов (typedef) interface-ref и interface-state-ref, которые другим модулям YANG следует применять, когда нужно указать настраиваемый или используемый в работе интерфейс, соответственно.

3.3. Уровни интерфейсов

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

Ниже приведен пример модели с такими узлами. Более полный пример представлен в Приложении B.

     import interfaces {
         prefix "if";
     }
     import iana-if-type {
       prefix ianaift;
     }

     augment "/if:interfaces/if:interface" {
         when "if:type = 'ianaift:ieee.8023adLag'";

         leaf-list slave-if {
             type if:interface-ref;
             must "/if:interfaces/if:interface[if:name = current()]"
                + "/if:type = 'ianaift:ethernetCsmacd'" {
                 description
                     "Ведомый (slave) интерфейс должен иметь тип 
                      'ethernetCsmacd'.";
             }
         }
         // Другие параметры настройки связки, время восстановления и пр.
     }

Хотя параметры уровней настраиваются в моделях для конкретных типов интерфейсов, два базовых leaf-list (higher-layer-if и lower-layer-if) представляют доступную только для чтения иерархию уровней интерфейсов.

4. Связь с IF-MIB

Если устройство реализует IF-MIB [RFC2863], каждая запись списка /interfaces-state/interface обычно отображается на один элемент ifEntry. Лист if-index должен содержать ifIndex соответствующего элемента ifEntry.

В большинстве случаев name из записи /interfaces-state/interface отображается на ifName. База IF-MIB позволяет двум разным ifEntry иметь общее имя ifName. Поддерживающие такую возможность устройства, которые соответствуют также определенной в этом документе модели данных, не могут иметь взаимно-однозначного отображения между листом name и ifName.

Указанное в конфигурации описание (description) интерфейса традиционно отображается некоторыми реализациями в ifAlias. Этот документ разрешает такие отображения, но рекомендует разработчикам учитывать различия в пространстве значений и постоянстве этих объектов. Подробности приведены в определении листа description представленного в разделе 5 модуля YANG.

IF-MIB определяет также открытый для записи объект ifPromiscuousMode. Поскольку агенты SNMP обычно не реализуют этот объект как конфигурационный, он не отображается в модуль ietf-interfaces.

Объект ifMtu из IF-MIB не отображается в модуль ietf-interfaces. Предполагается, что модули YANG для конкретных типов интерфейсов будут представлять MTU с помощью дополнения модели ietf-interfaces.

В IF-MIB имеется множество счетчиков, существующих в 32-битовом и 64-битовом варианте. 64-битовые счетчики были добавлены для поддержки интерфейсов со скоростью выше 20000000 бит/с. Современные реализации обычно поддерживают такие интерфейсы, поэтому модель данных включает лишь 64-битовые счетчики. Отметим, что NETCONF и SNMP могут различаться по частоте обращения к этим счетчикам. Например, многие реализации SNMP кэшируют значения счетчиков в течение некоторого времени.

Объекты ifDescr и ifConnectorPresent из IF-MIB не отображаются в модуль ietf-interfaces.

Ниже приведены таблицы сопоставления узлов данных YANG и объектов IF-MIB.

Узлы YANG для данных состояния и соответствующие объекты IF-MIB.

Узел данных YANG в /interfaces-state/interface	Объект IF-MIB
name	ifName
type	ifType
admin-status	ifAdminStatus
oper-status	ifOperStatus
last-change	ifLastChange
if-index	ifIndex
link-up-down-trap-enable	ifLinkUpDownTrapEnable
phys-address	ifPhysAddress
higher-layer-if and lower-layer-if	ifStackTable
speed	ifSpeed and ifHighSpeed
discontinuity-time	ifCounterDiscontinuityTime
in-octets	ifHCInOctets
in-unicast-pkts	ifHCInUcastPkts
in-broadcast-pkts	ifHCInBroadcastPkts
in-multicast-pkts	ifHCInMulticastPkts
in-discards	ifInDiscards
in-errors	ifInErrors
in-unknown-protos	ifInUnknownProtos
out-octets	ifHCOutOctets
out-unicast-pkts	ifHCOutUcastPkts
out-broadcast-pkts	ifHCOutBroadcastPkts
out-multicast-pkts	ifHCOutMulticastPkts
out-discards	ifOutDiscards
out-errors	ifOutErrors

YANG Config Data Nodes and Related IF-MIB Objects

Узел данных YANG в /interfaces/interface	Объект IF-MIB
description	ifAlias

5. Модуль YANG

Этот модуль YANG импортирует определения типов (typedef) из [RFC6991].

   <CODE BEGINS> file "ietf-interfaces@2014-05-08.yang"

   module ietf-interfaces {

     namespace "urn:ietf:params:xml:ns:yang:ietf-interfaces";
     prefix if;

     import ietf-yang-types {
       prefix yang;
     }

     organization
       "IETF NETMOD (NETCONF Data Modeling Language) Working Group";

     contact
       "WG Web:   <http://tools.ietf.org/wg/netmod/> 
        WG List:  <mailto:netmod@ietf.org> 

        WG Chair: Thomas Nadeau
                  <mailto:tnadeau@lucidvision.com> 

        WG Chair: Juergen Schoenwaelder
                  <mailto:j.schoenwaelder@jacobs-university.de> 

        Editor:   Martin Bjorklund
                  <mailto:mbj@tail-f.com>"; 

     description
       "Этот модуль содержит набор определений YANG для управления
        сетевыми интерфейсами.

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

        Распространение и использование в исходной и двоичной форме
        с изменениями или без них разрешается в соответствии с условиями,
        указанными в упрощенной лицензии BSD, изложенной в разделе 4.c
        Правового положения IETF Trust применительно к документам IETF
        (http://trustee.ietf.org/license-info). 

        Эта версия модуля YANG является частью RFC 7223, где
        правовые аспекты выражены более полно.";

     revision 2014-05-08 {
       description
         "Первый выпуск.";
       reference
         "RFC 7223: A YANG Data Model for Interface Management";
     }

     /*
      * Определения типов
      */

     typedef interface-ref {
       type leafref {
         path "/if:interfaces/if:interface/if:name";
       }
       description
         "Этот тип применяется моделями данных, которым нужно 
          указывать настроенные интерфейсы.";
     }

     typedef interface-state-ref {
       type leafref {
         path "/if:interfaces-state/if:interface/if:name";
       }
       description
         "Этот тип применяется моделями данных, которым нужно 
          указывать работающие интерфейсы.";
     }

     /*
      * Отождествления
      */

     identity interface-type {
       description
         "Базовое отождествление, из которого выводятся конкретные типы.";
     }

     /*
      * Возможности
      */

     feature arbitrary-names {
       description
         "Это свойство показывает, что управляемые пользователем интерфейсы
          могут иметь произвольные имена.";
     }

     feature pre-provisioning {
       description
         "Это свойство показаывает, что устройство поддерживает подготовленные
          заранее конфигурации интерфейсов, т. е. можно настроить интерфейс,
          которого еще нет в системе.";
     }

     feature if-mib {
       description
         "Это свойство указывает поддержку устройством IF-MIB.";
       reference
         "RFC 2863: The Interfaces Group MIB";
     }

     /*
      * Узлы конфигурационных данных
      */

     container interfaces {
       description
         "Конфигурационные параметры интерфейса.";
       list interface {
         key "name";

         description
           "Список настроенных на устройстве интерфейсов.

            Рабочее состояние интерфейса доступно в списке
            /interfaces-state/interface. Если конфигурация управляемого
            системой интерфейса не может использоваться системой
            (например, установленное оборудование не соответствует типу
            интерфейса), конфигурация не применяется к управляемому 
            системой интерфейсу из списка /interfaces-state/interface.
            Если конфигурация управляемого пользователем интерфейса не
            может применяться системой, настроенный интерфейс не 
            включается в список /interfaces-state/interface.";

        leaf name {
           type string;
           description
             "Имя интерфейса.

              Устройство МОЖЕТ ограничивать разрешенные для этого листа
              значения, возможно в зависимости от типа интерфейса.

              Для управляемых системой интерфейсов этот лист содержит
              зависимое от устройства имя интерфейса. Список
              /interfaces-state/interface (config false) содержит 
              имеющиеся в устройстве интерфейсы.

              Когда клиент пытается создать конфигурацию для управляемого
              системой интерфейса, которого нет в списке 
              /interfaces-state/interface, сервер МОЖЕТ отвергнуть
              запрос, если система не поддерживает предварительной
              настройки интерфейсов или имя указывает интерфейс, который
              не может присутствовать в системе. Сервер NETCONF ДОЛЖЕН
              вернуть отклик rpc-error с error-tag 'invalid-value'.

              Если устройство поддерживает предварительную настройку
              интерфейсов, анонсируется свойство 'pre-provisioning'.

              Если устройство разрешает произвольные имена для управляемых
              пользователем интерфейсов, анонсируется свойство 
              'arbitrary-names'.

              Когда управляемый пользователем интерфейс создается системой,
              он указывается с этим именем в /interface-state/interface.";
         }

         leaf description {
           type string;
           description
             "Текстовое описание интерфейса.

              Реализация сервера МОЖЕТ отображать этот лист на объект MIB 
              ifAlias. Такие реализации должны использовать тот или иной
              механизм для обработки различий в размере и разрешенных
              символах для этого листа и ifAlias. Определение таких
              механизмов выходит за рамки документа.

              Поскольку ifAlias определяется для сохранения в
              энергонезависимой памяти, реализация MIB ДОЛЖНА отображать 
              ifAlias на значение 'description' в постоянном хранилище.

              В частности, если устройство поддерживает ':startup', при
              считывании ifAlias устройство ДОЛЖНО возвращать значение
              'description' из хранилища 'startup', а при записи значение
              ДОЛЖНО сохраняться в хранилищах 'running' и 'startup'.
              Отметим, что реализация должна решить, следует ли изменить
              только лист в хранилище 'startup' или неявно выполнить
              copy-config из хранилища 'running' в хранилище 'startup'.

              Если устройство не поддерживает ':startup', значение ifAlias 
              ДОЛЖНО отображаться в лист 'description' хранилища 'running'.";
           reference
             "RFC 2863: The Interfaces Group MIB - ifAlias";
         }
         leaf type {
           type identityref {
             base interface-type;
           }
           mandatory true;
           description
             "Тип интерфейса.

              При создании записи для интерфейса сервер МОЖЕТ 
              инициализировать лист type действующим значением, например, 
              если можно вывести тип из имени интерфейса.

              Если клиент пытается установить для типа интерфейса значение,
              которое никогда не используется системой (например, тип не
              поддерживается или не соответствует имени), сервер ДОЛЖЕН
              отвергнуть запрос. Сервер NETCONF ДОЛЖЕН возвратить отклик
              rpc-error с error-tag 'invalid-value' в таком случае.";
           reference
             "RFC 2863: The Interfaces Group MIB - ifType";
         }

         leaf enabled {
           type boolean;
           default "true";
           description
             "Этот лист содержит настроенное, желаемое состояние интерфейса.

              Системы, реализующие IF-MIB, используют значение этого листа в
              хранилище running для установки в IF-MIB.ifAdminStatus 
              значения up или down после инициализации ifEntry как описано в
              RFC 2863.

              Изменение этого листа в хранилище running отражается в
              ifAdminStatus, но при изменении ifAdminStatus с помощью 
              SNMP этот лист не меняется.";
           reference
             "RFC 2863: The Interfaces Group MIB - ifAdminStatus";
         }

         leaf link-up-down-trap-enable {
           if-feature if-mib;
           type enumeration {
             enum enabled {
               value 1;
             }
             enum disabled {
               value 2;
             }
           }
           description
             "Указывает следует ли генерировать уведомления SNMP 
              linkUp/linkDown для этого интерфейса.

              Если этот узел не настроен, значение enabled применяется
              сервером для интерфейсов, которые не работают поверх другого
              интерфейса (т. е. нет записей lower-layer-if), и disabled 
              в остальных случаях.";
           reference
             "RFC 2863: The Interfaces Group MIB - ifLinkUpDownTrapEnable";
         }
       }
     }

     /*
      * Узлы данных состояния
      */

     container interfaces-state {
       config false;
       description
         "Узлы данных для операционных состояний интерфейсов.";

       list interface {
         key "name";
         description
           "Список интерфейсов в устройстве.
            Системно-управляемые интерфейсы, созданные системой, всегда
            присутствуют в этом списке, независимо от их конфигурации.";

         leaf name {
           type string;
           description
             "Имя интерфейса.

              Реализация сервера МОЖЕТ отображать этот лист на объект 
              MIB ifName. Такие реализации должны использовать тот или
              иной механизм для обработки различий в размере и разрешенных
              символах для этого листа и ifName. Определение механизмов
              выходит за рамки этого документа.";
           reference
             "RFC 2863: The Interfaces Group MIB - ifName";
         }

         leaf type {
           type identityref {
             base interface-type;
           }
           mandatory true;
           description
             "Тип интерфейса.";
           reference
             "RFC 2863: The Interfaces Group MIB - ifType";
         }

         leaf admin-status {
           if-feature if-mib;
           type enumeration {
             enum up {
               value 1;
               description
                 "Готов пропускать пакеты.";
             }
             enum down {
               value 2;
               description
                 "Не готов пропускать пакеты и не находится в режиме теста.";
             }

             enum testing {
               value 3;
               description
                 "Находится в режиме тестирования.";
             }
           }
           mandatory true;
           description
             "Желаемое состояние интерфейса.

              Этот лист имеет такую же семантику, как ifAdminStatus.";
           reference
             "RFC 2863: The Interfaces Group MIB - ifAdminStatus";
         }

         leaf oper-status {
           type enumeration {
             enum up {
               value 1;
               description
                 "Готов пропускать пакеты.";
             }
             enum down {
               value 2;
               description
                 "Интерфейс не пропускает никаких пакетов.";
             }
             enum testing {
               value 3;
               description
                 "В режиме тестирования. Не может пропускать рабочих 
                  пакетов.";
             }
             enum unknown {
               value 4;
               description
                 "Состояние не может быть определено по каким-то причинам.";
             }
             enum dormant {
               value 5;
               description
                 "Ожидание внешнего события.";
             }
             enum not-present {
               value 6;
               description
                 "Отсутствует тот или иной (обычно аппаратный) компонент.";
             }

             enum lower-layer-down {
               value 7;
               description
                 "Не работает вследствие состояния нижележащего интерфейса.";
             }
           }
           mandatory true;
           description
             "Текущее операционное состояние интерфейса.

              Этот лист имеет такую же семантику, как ifOperStatus.";
           reference
             "RFC 2863: The Interfaces Group MIB - ifOperStatus";
         }

         leaf last-change {
           type yang:date-and-time;
           description
             "Время перехода интерфейса в текущее операционное состояние.
              Если текущее состояние началось до предыдущей реинициализации
              локальной подсистемы сетевого управления, этого узла не будет.";
           reference
             "RFC 2863: The Interfaces Group MIB - ifLastChange";
         }

         leaf if-index {
           if-feature if-mib;
           type int32 {
             range "1..2147483647";
           }
           mandatory true;
           description
             "Значение ifIndex для ifEntry, представленной этим интерфейсом.";
           reference
             "RFC 2863: The Interfaces Group MIB - ifIndex";
         }

         leaf phys-address {
           type yang:phys-address;
           description
             "Адрес интерфейса на его протокольном подуровне. Например,
              для интерфейса 802.x этот объект обычно содержит MAC5-адрес
              Зависящие от среды модули должны определять порядок битов
              и байтов, а также формат значения для этого объекта. Для
              интерфейсов, не имеющих такого адреса (например, 
              последовательная линия), этого узла не будет.";
           reference
             "RFC 2863: The Interfaces Group MIB - ifPhysAddress";
         }

         leaf-list higher-layer-if {
           type interface-state-ref;
           description
             "Список ссылок на интерфейсы, работающие поверх этого
              интерфейса.";
           reference
             "RFC 2863: The Interfaces Group MIB - ifStackTable";
         }


         leaf-list lower-layer-if {
           type interface-state-ref;
           description
             "Список ссылок на интерфейсы под этим интерфейсом.";
           reference
             "RFC 2863: The Interfaces Group MIB - ifStackTable";
         }

         leaf speed {
           type yang:gauge64;
           units "bits/second";
           description
               "Оценка текущей пропускной способности интерфейса в бит/с.
                Для интерфейсов, не меняющих пропускной способности или
                не позволяющих точно оценить ее, в этом узле следует
                указывать номинальную пропускную способность. Для 
                интерфейсов, не использующих концепцию пропускной 
                способности, этот узел не присутствует.";
           reference
             "RFC 2863: The Interfaces Group MIB - ifSpeed, ifHighSpeed";
         }

         container statistics {
           description
             "Набор связанных с интерфейсом объектов статистики.";

           leaf discontinuity-time {
             type yang:date-and-time;
             mandatory true;
             description
               "Время последнего события, когда один или несколько 
                счетчиков интерфейса подверглись разрыву. Если таких
                событий не было с момента последней реиинициализации
                локальной подсистемы управления, указывается время с
                момента этой реинициализации.";
           }

           leaf in-octets {
             type yang:counter64;
             description
               "Общее число октетов, принятых на интерфейсе с учетом
                символов кадрирования.

                Разрыв значения этого счетчика может происходить при
                реинициализации системы управления или иных событиях
                указанных временем 'discontinuity-time'.";
             reference
               "RFC 2863: The Interfaces Group MIB - ifHCInOctets";
           }

           leaf in-unicast-pkts {
             type yang:counter64;
             description
               "Число пакетов, доставленных этим подуровнем на 
                вышележащий (под)уровень, которые не были направлены по 
                широковещательному или групповому адресу этого подуровня.

                Разрыв значения этого счетчика может происходить при
                реинициализации системы управления или иных событиях
                указанных временем 'discontinuity-time'.";
             reference
               "RFC 2863: The Interfaces Group MIB - ifHCInUcastPkts";
           }

           leaf in-broadcast-pkts {
             type yang:counter64;
             description
               "Число пакетов, доставленных этим подуровнем на 
                вышележащий (под)уровень, которые были направлены по 
                широковещательному адресу этого подуровня.
                Разрыв значения этого счетчика может происходить при
                реинициализации системы управления или иных событиях
                указанных временем 'discontinuity-time'.";
             reference
               "RFC 2863: The Interfaces Group MIB - ifHCInBroadcastPkts";
           }
           leaf in-multicast-pkts {
             type yang:counter64;
             description
               "Число пакетов, доставленных этим подуровнем на 
                вышележащий (под)уровень, которые были направлены по 
                групповому адресу этого подуровня. Для протокола
                уровня MAC учитываются групповые (Group) и
                функциональные (Functional) адреса.

                Разрыв значения этого счетчика может происходить при
                реинициализации системы управления или иных событиях
                указанных временем 'discontinuity-time'.";
             reference
               "RFC 2863: The Interfaces Group MIB -
                          ifHCInMulticastPkts";
           }

           leaf in-discards {
             type yang:counter32;
             description
               "Число входящих пакетов, которые несмотря на отсутствие
                ошибок были выбраны для отбрасывания с целью предотвратить
                их доставку протоколу вышележащего уровня. Одной из 
                возможных причин отбрасывания является освобождение буферов.

                Разрыв значения этого счетчика может происходить при
                реинициализации системы управления или иных событиях
                указанных временем 'discontinuity-time'.";
             reference
               "RFC 2863: The Interfaces Group MIB - ifInDiscards";
           }

           leaf in-errors {
             type yang:counter32;
             description
               "Для ориентированных на пакеты интерфейсов - число входящих
                пакетов с ошибками, препятствующими передаче протоколу 
                вышележащего уровня. Для ориентированных на символы 
                интерфейсов и интерфейсов с фиксированным размером блоков -
                число входящих блоков передачи с ошибками, препятствующими 
                доставке протоколу вышележащего уровня.

                Разрыв значения этого счетчика может происходить при
                реинициализации системы управления или иных событиях
                указанных временем 'discontinuity-time'.";
             reference
               "RFC 2863: The Interfaces Group MIB - ifInErrors";
           }

           leaf in-unknown-protos {
             type yang:counter32;
             description
               "Для ориентированных на пакеты интерфейсов - число принятых
                через интерфейс пакетов, которые были отброшены по причине
                неизвестного или не поддерживаемого протокола. Для символьно-
                ориентированных интерфейсов и интерфейсов с фиксированным 
                размером блока и поддержкой мультиплексирования протоколов - 
                число принятых через интерфейс блоков передачи, которые были 
                отброшены по причине неизвестного или не поддерживаемого 
                протокола. Для интерфейсов, не поддерживающих 
                мультиплексирование протоколов, этот счетчик не присутствует.

                Разрыв значения этого счетчика может происходить при
                реинициализации системы управления или иных событиях
                указанных временем 'discontinuity-time'.";
             reference
               "RFC 2863: The Interfaces Group MIB - ifInUnknownProtos";
           }

           leaf out-octets {
             type yang:counter64;
             description
               "Общее число переданных интерфейсом октетов, включая символы
                кадрирования.

                Разрыв значения этого счетчика может происходить при
                реинициализации системы управления или иных событиях
                указанных временем 'discontinuity-time'.";
             reference
               "RFC 2863: The Interfaces Group MIB - ifHCOutOctets";
           }

           leaf out-unicast-pkts {
             type yang:counter64;
             description
               "Общее число пакетов, для которых протокол вышележащего
                уровня запросил передачу по адресу, не являющемуся
                широковещательным или групповым адресам для этого 
                подуровня, включая отброшенные и не переданные пакеты.

                Разрыв значения этого счетчика может происходить при
                реинициализации системы управления или иных событиях
                указанных временем 'discontinuity-time'.";
             reference
               "RFC 2863: The Interfaces Group MIB - ifHCOutUcastPkts";
           }

           leaf out-broadcast-pkts {
             type yang:counter64;
             description
               "Общее число пакетов, для которых протокол вышележащего
                уровня запросил передачу, направленных по
                широковещательным адресам для этого подуровня,
                включая отброшенные и не переданные пакеты.

                Разрыв значения этого счетчика может происходить при
                реинициализации системы управления или иных событиях
                указанных временем 'discontinuity-time'.";
             reference
               "RFC 2863: The Interfaces Group MIB -
                          ifHCOutBroadcastPkts";
           }

           leaf out-multicast-pkts {
             type yang:counter64;
             description
                "Общее число пакетов, для которых протокол вышележащего
                уровня запросил передачу, направленных по
                групповым адресам для этого подуровня, включая
                отброшенные и не переданные пакеты. Для протокола уровня
                MAC это включает групповые и функциональные адреса.

                Разрыв значения этого счетчика может происходить при
                реинициализации системы управления или иных событиях
                указанных временем 'discontinuity-time'.";
             reference
               "RFC 2863: The Interfaces Group MIB -
                          ifHCOutMulticastPkts";
           }

           leaf out-discards {
             type yang:counter32;
             description
               "Число исходящих пакетов, которые были выбраны для 
                отбрасывания, несмотря на отсутствие препятствующих
                передаче ошибок. Возможной причиной такого отбрасывания
                является освобождение буферного пространства.

                Разрыв значения этого счетчика может происходить при
                реинициализации системы управления или иных событиях
                указанных временем 'discontinuity-time'.";
             reference
               "RFC 2863: The Interfaces Group MIB - ifOutDiscards";
           }

           leaf out-errors {
             type yang:counter32;
             description
               "Для пакетно-ориентированных интерфейсов - число исходящих
                пакетов, которые не были переданы по причине ошибок. Для
                символьных интерфейсов и интерфейсов с постоянным размером
                блока - число блоков, не переданных из-за ошибок.

                Разрыв значения этого счетчика может происходить при
                реинициализации системы управления или иных событиях
                указанных временем 'discontinuity-time'.";
             reference
               "RFC 2863: The Interfaces Group MIB - ifOutErrors";
           }
         }
       }
     }
   }

   <CODE ENDS>

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

Этот документ регистрирует URI в реестре «IETF XML Registry» [RFC3688]. В соответствии с форматом RFC 3688 выполнена приведенная ниже регистрация.

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

Документ регистрирует модуль YANG в реестре «YANG Module Names» [RFC6020].

      name:         ietf-interfaces
      namespace:    urn:ietf:params:xml:ns:yang:ietf-interfaces
      prefix:       if
      reference:    RFC 7223

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

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

В модуле YANG имеется множество узлов данных, доступных для чтения, создания и удаления (например, с принятым по умолчанию config true). Эти узлы могут быть конфиденциальными или уязвимыми в некоторых сетевых средах. Операции записи (например, <edit-config>) в эти узлы без подобающей защиты могут оказывать негативное влияние на работу сети. Ниже перечислены субдеревья и узлы данных с указанием уязвимости.

/interfaces/interface

Этот список указывает настроенные в устройстве интерфейсы. Несанкционированный доступ к списку может вынуждать устройство игнорировать пакеты, которые оно должно принимать и обрабатывать.

/interfaces/interface/enabled

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

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

Авторы благодарят Alexander Clemm, Per Hedeland, Ladislav Lhotka, Juergen Schoenwaelder за полезные замечания.

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

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

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

[RFC2863] McCloghrie, K. and F. Kastenholz, «The Interfaces Group MIB», RFC 2863, June 2000.

[RFC3688] Mealling, M., «The IETF XML Registry», BCP 81, RFC 3688, January 2004.

[RFC6020] Bjorklund, M., «YANG — A Data Modeling Language for the Network Configuration Protocol (NETCONF)», RFC 6020⁶, October 2010.

[RFC6991] Schoenwaelder, J., «Common YANG Data Types», RFC 6991, July 2013.

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

[RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. Bierman, «Network Configuration Protocol (NETCONF)», RFC 6241, June 2011.

[RFC6242] Wasserman, M., «Using the NETCONF Protocol over Secure Shell (SSH)», RFC 6242, June 2011.

[RFC6536] Bierman, A. and M. Bjorklund, «Network Configuration Protocol (NETCONF) Access Control Model», RFC 6536⁷, March 2012.

[RFC7224] Bjorklund, M., «IANA Interface Type YANG Module», RFC 7224, May 2014.

Приложение A. Пример модуля для интерфейса Ethernet

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

   module ex-ethernet {
     namespace "http://example.com/ethernet";
     prefix "eth";

     import ietf-interfaces {
       prefix if;
     }
     import iana-if-type {
       prefix ianaift;
     }

     // Конфигурационные параметры для интерфейсов Ethernet 
     augment "/if:interfaces/if:interface" {
       when "if:type = 'ianaift:ethernetCsmacd'";

       container ethernet {
         choice transmission-params {
           case auto {
             leaf auto-negotiate {
               type empty;
             }
           }
           case manual {
             leaf duplex {
               type enumeration {
                 enum "half";
                 enum "full";
               }
             }

             leaf speed {
               type enumeration {
                 enum "10Mb";
                 enum "100Mb";
                 enum "1Gb";
                 enum "10Gb";
               }
             }
           }
         }
         // Другие параметры, относящиеся к Ethernet ...
       }
     }

     // Параметры рабочего состояния для интерфейсов Ethernet
     augment "/if:interfaces-state/if:interface" {
       when "if:type = 'ianaift:ethernetCsmacd'";

       container ethernet {
         leaf duplex {
           type enumeration {
             enum "half";
             enum "full";
           }
         }
         // Другие параметры, относящиеся к Ethernet ...
       }
     }
   }

Приложение B. Пример модуля для связки интерфейсов Ethernet

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

   module ex-ethernet-bonding {
     namespace "http://example.com/ethernet-bonding";
     prefix "bond";

     import ietf-interfaces {
       prefix if;
     }
     import iana-if-type {
       prefix ianaift;
     }

     augment "/if:interfaces/if:interface" {
       when "if:type = 'ianaift:ieee8023adLag'";

       leaf-list slave-if {
         type if:interface-ref;
         must "/if:interfaces/if:interface[if:name = current()]"
            + "/if:type = 'ianaift:ethernetCsmacd'" {
           description
             "Ведомый (slave) интерфейс должен иметь тип 'ethernetCsmacd'.";
         }
       }
       leaf bonding-mode {
         type enumeration {
           enum round-robin;
           enum active-backup;
           enum broadcast;
         }
       }
       // Другие параметры конфигурации связки, время восстановления и пр.
     }
   }

Приложение C. Пример модуля для интерфейса VLAN

В этом приложении представлен пример определения интерфейса VLAN.

   module ex-vlan {
     namespace "http://example.com/vlan";
     prefix "vlan";

     import ietf-interfaces {
       prefix if;
     }
     import iana-if-type {
       prefix ianaift;
     }

     augment "/if:interfaces/if:interface" {
       when "if:type = 'ianaift:ethernetCsmacd' or
             if:type = 'ianaift:ieee8023adLag'";
       leaf vlan-tagging {
         type boolean;
         default false;
       }
     }

     augment "/if:interfaces/if:interface" {
       when "if:type = 'ianaift:l2vlan'";

       leaf base-interface {
         type if:interface-ref;
         must "/if:interfaces/if:interface[if:name = current()]"
            + "/vlan:vlan-tagging = 'true'" {
           description
             "На базовом интерфейсе должны быть разрешены теги VLAN.";
         }
       }
       leaf vlan-id {
         type uint16 {
           range "1..4094";
         }
         must "../base-interface" {
           description
             "При определении vlan-id должен быть указан базовый интерфейс.";
         }
       }
     }
   }

Приложение D. Пример отклика NETCONF <get>

В этом приложении дан пример отклика на запрос NETCONF <get> для устройства, реализующего приведенный выше пример модели данных.

   <rpc-reply
       xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
       message-id="101">
     <data>

       <interfaces
           xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces"
           xmlns:ianaift="urn:ietf:params:xml:ns:yang:iana-if-type"
           xmlns:vlan="http://example.com/vlan">

         <interface>
           <name>eth0</name>
           <type>ianaift:ethernetCsmacd</type>
           <enabled>false</enabled>
         </interface>

         <interface>
           <name>eth1</name>
           <type>ianaift:ethernetCsmacd</type>
           <enabled>true</enabled>
           <vlan:vlan-tagging>true</vlan:vlan-tagging>
         </interface>

         <interface>
           <name>eth1.10</name>
           <type>ianaift:l2vlan</type>
           <enabled>true</enabled>
           <vlan:base-interface>eth1</vlan:base-interface>
           <vlan:vlan-id>10</vlan:vlan-id>
         </interface>

         <interface>
           <name>lo1</name>
           <type>ianaift:softwareLoopback</type>
           <enabled>true</enabled>
         </interface>

       </interfaces>

       <interfaces-state
           xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces"
           xmlns:ianaift="urn:ietf:params:xml:ns:yang:iana-if-type">

         <interface>
           <name>eth0</name>
           <type>ianaift:ethernetCsmacd</type>
           <admin-status>down</admin-status>
           <oper-status>down</oper-status>
           <if-index>2</if-index>
           <phys-address>00:01:02:03:04:05</phys-address>
           <statistics>
             <discontinuity-time>
               2013-04-01T03:00:00+00:00
             </discontinuity-time>
             <!-- Здесь показаны счетчики -->
           </statistics>
         </interface>

         <interface>
           <name>eth1</name>
           <type>ianaift:ethernetCsmacd</type>
           <admin-status>up</admin-status>
           <oper-status>up</oper-status>
           <if-index>7</if-index>
           <phys-address>00:01:02:03:04:06</phys-address>
           <higher-layer-if>eth1.10</higher-layer-if>
           <statistics>
             <discontinuity-time>
               2013-04-01T03:00:00+00:00
             </discontinuity-time>
             <!-- Здесь показаны счетчики -->
           </statistics>
         </interface>

         <interface>
           <name>eth1.10</name>
           <type>ianaift:l2vlan</type>
           <admin-status>up</admin-status>
           <oper-status>up</oper-status>
           <if-index>9</if-index>
           <lower-layer-if>eth1</lower-layer-if>
           <statistics>
             <discontinuity-time>
               2013-04-01T03:00:00+00:00
             </discontinuity-time>
             <!-- Здесь показаны счетчики -->
           </statistics>
         </interface>

         <!-- Этот интерфейс не настроен -->
         <interface>
           <name>eth2</name>
           <type>ianaift:ethernetCsmacd</type>
           <admin-status>down</admin-status>
           <oper-status>down</oper-status>
           <if-index>8</if-index>
           <phys-address>00:01:02:03:04:07</phys-address>
           <statistics>
             <discontinuity-time>
               2013-04-01T03:00:00+00:00
             </discontinuity-time>
             <!-- Здесь показаны счетчики -->
           </statistics>
         </interface>

         <interface>
           <name>lo1</name>
           <type>ianaift:softwareLoopback</type>
           <admin-status>up</admin-status>
           <oper-status>up</oper-status>
           <if-index>1</if-index>
           <statistics>
             <discontinuity-time>
               2013-04-01T03:00:00+00:00
             </discontinuity-time>
             <!-- Здесь показаны счетчики -->
           </statistics>
         </interface>

       </interfaces-state>
     </data>
   </rpc-reply>

Приложение E. Примеры схем именования интерфейсов

В этом приложении приведены примеры стратегии развертывания.

В примерах используется модель данных ex-vlan (Приложение C) для показа настройки управляемых пользователем интерфейсов.

E.1. Маршрутизатор с ограничениями для имен интерфейсов

В этом примере маршрутизатор имеет 4 линейных платы с восемью портами на каждой. Гнезда для плат имеют физические номера от 0 до 3, а порты на каждой плате — от 0 до 7. Каждая плата имеет порты Fast Ethernet или Gigabit Ethernet.

Обусловленными устройством именами физических интерфейсов будут fastethernet-N/M или gigabitethernet-N/M.

Имена интерфейсов VLAN ограничены формой <physical-interface-name>.<subinterface-number>.

Предполагается, что схема именования известна оператору. Реализация автоматически инициализирует значение type в соответствии с именем интерфейса.

Сервер NETCONF не анонсирует возможность arbitrary-names в сообщении <hello>.

Оператор может настроить физический интерфейс, передавая команду <edit-config>, содержащую

     <interface nc:operation="create">
       <name>fastethernet-1/0</name>
     </interface>

При получении сервером такого запроса он будет устанавливать для листа type значение ianaift:ethernetCsmacd. Если клиент передаст команду <get-config> после приведенной выше команды <edit-config>, он получит

     <interface>
       <name>fastethernet-1/0</name>
       <type>ianaift:ethernetCsmacd</type>
     </interface>

Клиент может настроить интерфейс VLAN с помощью команды <edit-config>, содержащей

     <interface nc:operation="create">
       <name>fastethernet-1/0.10005</name>
       <type>ianaift:l2vlan</type>
       <vlan:base-interface>fastethernet-1/0</vlan:base-interface>
       <vlan:vlan-id>5</vlan:vlan-id>
     </interface>

Если клиент попытается изменить тип физического интерфейса командой <edit-config>, содержащей

     <interface nc:operation="merge">
       <name>fastethernet-1/0</name>
       <type>ianaift:tunnel</type>
     </interface>

сервер вернет ошибку invalid-value, поскольку новый тип не соответствует имени.

E.2. Маршрутизатор с произвольными именами интерфейсов

В этом примере маршрутизатор имеет 4 линейных платы с восемью портами на каждой. Гнезда для плат имеют физические номера от 0 до 3, а порты на каждой плате — от 0 до 7. Каждая плата имеет порты Fast Ethernet или Gigabit Ethernet.

Обусловленными устройством именами физических интерфейсов будут fastethernet-N/M или gigabitethernet-N/M.

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

Сервер NETCONF анонсирует возможность arbitrary-names в сообщении <hello>.

Физические интерфейсы настраиваются в соответствии с приложением E.1.

Оператор может настроить интерфейс VLAN с помощью команды <edit-config>, содержащей

     <interface nc:operation="create">
       <name>acme-interface</name>
       <type>ianaift:l2vlan</type>
       <vlan:base-interface>fastethernet-1/0</vlan:base-interface>
       <vlan:vlan-id>5</vlan:vlan-id>
     </interface>

При необходимости оператор может перенести конфигурацию с именем acme-interface на другой физический интерфейс с помощью команды <edit-config>, содержащей

     <interface nc:operation="merge">
       <name>acme-interface</name>
       <vlan:base-interface>fastethernet-1/1</vlan:base-interface>
     </interface>

E.3. Коммутатор Ethernet с ограничениями для имен интерфейсов

В этом примере коммутатор Ethernet имеет множество портов, каждый из которых указывается простым номером.

Зависящие от устройства имена физических интерфейсов являются номерами, соответствующими номерам физических портов.

Оператор может настроить физический интерфейс с помощью команды <edit-config>, содержащей

     <interface nc:operation="create">
       <name>6</name>
     </interface>

Когда сервер получает такой запрос, он устанавливает для листа type значение ianaift:ethernetCsmacd. Если клиент выполнит команду <get-config> после показанной выше команды <edit-config>, он получит

     <interface>
       <name>6</name>
       <type>ianaift:ethernetCsmacd</type>
     </interface>

E.4. Типовой хост с ограничениями для имен интерфейсов

В этом примере обычный хост имеет интерфейсы, именуемые ядром. Система идентифицирует физические интерфейсы по именам, назначенным операционной системой.

Имена интерфейсов VLAN ограничены формой <physical-interface-name>:<vlan-number>.

Сервер NETCONF не анонсирует возможность arbitrary-names в сообщении <hello>.

Оператор может настроить интерфейс с помощью команды <edit-config>, содержащей

     <interface nc:operation="create">
       <name>eth8</name>
     </interface>

Когда сервер получает такой запрос, он устанавливает для листа type значение ianaift:ethernetCsmacd. Если клиент выполнит команду <get-config> после показанной выше команды <edit-config>, он получит

     <interface>
       <name>eth8</name>
       <type>ianaift:ethernetCsmacd</type>
     </interface>

Клиент может настроить интерфейс VLAN с помощью команды <edit-config>, содержащей

     <interface nc:operation="create">
       <name>eth8:5</name>
       <type>ianaift:l2vlan</type>
       <vlan:base-interface>eth8</vlan:base-interface>
       <vlan:vlan-id>5</vlan:vlan-id>
     </interface>

E.5. Типовой хост с произвольными именами интерфейсов

В этом примере обычный хост имеет интерфейсы, именуемые ядром. Система идентифицирует физические интерфейсы по именам, назначенным операционной системой.

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

Сервер NETCONF анонсирует возможность arbitrary-names в сообщении <hello>.

Физические интерфейсы настраиваются как в приложении E.4.

Оператор может настроить интерфейс VLAN с помощью команды <edit-config>, содержащей

     <interface nc:operation="create">
       <name>acme-interface</name>
       <type>ianaift:l2vlan</type>
       <vlan:base-interface>eth8</vlan:base-interface>
       <vlan:vlan-id>5</vlan:vlan-id>
     </interface>

При необходимости оператор может перенести конфигурацию с именем acme-interface на другой физический интерфейс с помощью команды <edit-config>, содержащей

     <interface nc:operation="merge">
       <name>acme-interface</name>
       <vlan:base-interface>eth3</vlan:base-interface>
     </interface>

Адрес автора

Martin Bjorklund

Tail-f Systems

EMail: mbj@tail-f.com

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

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

nmalykh@protokols.ru

Internet Engineering Task Force (IETF)                      M. Bjorklund
Request for Comments: 7224                                Tail-f Systems
Category: Standards Track                                       May 2014
ISSN: 2070-1721

IANA Interface Type YANG Module

Модуль YANG для типов интерфейсов IANA

PDF

Аннотация

В этом документе представлен первый выпуск модуля YANG iana-if-type.

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

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

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

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

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

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

Этот документ определяет первый выпуск модуля YANG iana-if-type с определениями типов интерфейсов.

Модуль iana-if-type отражает имеющийся реестр IANA ifType definitions [IFTYPE-IANA-REGISTRY]. Последняя версия модуля может быть загружена с сайта IANA.

При добавлении нового типа интерфейса в реестр ifType definitions агентство IANA будет обновлять IANAifType-MIB и модуль YANG iana-if-type.

2. Модуль YANG для поддерживаемых IANA типов интерфейсов

Этот модуль YANG импортирует отождествление interface-type из [RFC7223].

   <CODE BEGINS> file "iana-if-type.yang"

   module iana-if-type {
     namespace "urn:ietf:params:xml:ns:yang:iana-if-type";
     prefix ianaift;

     import ietf-interfaces {
       prefix if;
     }

     organization "IANA";
     contact
       "        Internet Assigned Numbers Authority

        Postal: ICANN
                4676 Admiralty Way, Suite 330
                Marina del Rey, CA 90292

        Tel:    +1 310 823 9358
        <mailto:iana@iana.org>"; 

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

        Этот модуль YANG поддерживается агентством IANA и отражает
        реестр ifType definitions.

        Последнюю версию этого модуля YANG можно загрузить с сайта IANA.

        Запросы на новые значения следует направлять в IANA по адресу
        (iana@iana.org). 

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

        Распространение и использование в исходной или двоичной форме
        с изменениями или без них разрешается в соответствии с условиями
        упрощённой лицензии BSD, изложенной в разделе 4.c Правового
        положения IETF Trust применительно к документам IETF
        (http://trustee.ietf.org/license-info). 

        Эта исходная версия модуля YANG является частью RFC 7224, где
        правовые аспекты выражены более полно.";
     reference
         "Реестр IANA ifType definitions.
          <http://www.iana.org/assignments/smi-numbers>"; 

     revision 2014-05-08 {
       description
         "Исходный выпуск.";
       reference
         "RFC 7224: IANA Interface Type YANG Module";
     }

     identity iana-interface-type {
       base if:interface-type;
       description
         "Это отождествление служит базой для всех типов интерфейсов,
          определённых в реестре ifType definitions.";
     }
     identity other {
       base iana-interface-type;
     }
     identity regular1822 {
       base iana-interface-type;
     }
     identity hdh1822 {
       base iana-interface-type;
     }
     identity ddnX25 {
       base iana-interface-type;
     }
     identity rfc877x25 {
       base iana-interface-type;
       reference
         "RFC 1382 - SNMP MIB Extension for the X.25 Packet Layer";
     }
     identity ethernetCsmacd {
       base iana-interface-type;
       description
         "Для всех интерфейсов типа Ethernet, независимо от скорости,
          как указано в RFC 3635.";
       reference
         "RFC 3635 - Definitions of Managed Objects for the
                     Ethernet-like Interface Types";
     }
     identity iso88023Csmacd {
       base iana-interface-type;
       status deprecated;
       description
         "Отменено в 3635 с заменой на ethernetCsmacd(6).";
       reference
         "RFC 3635 - Definitions of Managed Objects for the
                     Ethernet-like Interface Types";
     }
     identity iso88024TokenBus {
       base iana-interface-type;
     }
     identity iso88025TokenRing {
       base iana-interface-type;
     }
     identity iso88026Man {
       base iana-interface-type;
     }
     identity starLan {
       base iana-interface-type;
       status deprecated;
       description
         "Отменено в 3635 с заменой на ethernetCsmacd(6).";
       reference
         "RFC 3635 - Definitions of Managed Objects for the
                     Ethernet-like Interface Types";
     }
     identity proteon10Mbit {
       base iana-interface-type;
     }
     identity proteon80Mbit {
       base iana-interface-type;
     }
     identity hyperchannel {
       base iana-interface-type;
     }
     identity fddi {
       base iana-interface-type;
       reference
         "RFC 1512 - FDDI Management Information Base";
     }
     identity lapb {
       base iana-interface-type;
       reference
         "RFC 1381 - SNMP MIB Extension for X.25 LAPB";
     }
     identity sdlc {
       base iana-interface-type;
     }
     identity ds1 {
       base iana-interface-type;
       description
         "DS1-MIB.";
       reference
         "RFC 4805 - Definitions of Managed Objects for the
                     DS1, J1, E1, DS2, and E2 Interface Types";
     }
     identity e1 {
       base iana-interface-type;
       status obsolete;
       description
         "Отменено, см. DS1-MIB.";
       reference
         "RFC 4805 - Definitions of Managed Objects for the
                     DS1, J1, E1, DS2, and E2 Interface Types";
     }
     identity basicISDN {
       base iana-interface-type;
       description
         "Больше не применяется. См. также RFC 2127.";
     }
     identity primaryISDN {
       base iana-interface-type;
       description
         "Больше не применяется. См. также RFC 2127.";
     }
     identity propPointToPointSerial {
       base iana-interface-type;
       description
         "Proprietary serial.";
     }
     identity ppp {
       base iana-interface-type;
     }
     identity softwareLoopback {
       base iana-interface-type;
     }
     identity eon {
       base iana-interface-type;
       description
         "CLNP по протоколу IP.";
     }
     identity ethernet3Mbit {
       base iana-interface-type;
     }
     identity nsip {
       base iana-interface-type;
       description
         "XNS по протоколу IP.";
     }
     identity slip {
       base iana-interface-type;
       description
         "Базовый интерфейс SLIP.";
     }
     identity ultra {
       base iana-interface-type;
       description
         "Ultra Technologies.";
     }
     identity ds3 {
       base iana-interface-type;
       description
         "DS3-MIB.";
       reference
         "RFC 3896 - Definitions of Managed Objects for the
                     DS3/E3 Interface Type";
     }
     identity sip {
       base iana-interface-type;
       description
         "SMDS, coffee.";
       reference
         "RFC 1694 - Definitions of Managed Objects for SMDS
                     Interfaces using SMIv2";
     }
     identity frameRelay {
       base iana-interface-type;
       description
         "Только DTE.";
       reference
         "RFC 2115 - Management Information Base for Frame Relay
                     DTEs Using SMIv2";
     }
     identity rs232 {
       base iana-interface-type;
       reference
         "RFC 1659 - Definitions of Managed Objects for RS-232-like
                     Hardware Devices using SMIv2";
     }
     identity para {
       base iana-interface-type;
       description
         "Параллельный порт.";
       reference
         "RFC 1660 - Definitions of Managed Objects for
                     Parallel-printer-like Hardware Devices using
                     SMIv2";
     }
     identity arcnet {
       base iana-interface-type;
       description
         "ARCnet.";
     }
     identity arcnetPlus {
       base iana-interface-type;
       description
         "ARCnet Plus.";
     }
     identity atm {
       base iana-interface-type;
       description
         "Ячейки ATM.";
     }
     identity miox25 {
       base iana-interface-type;
       reference
         "RFC 1461 - SNMP MIB extension for Multiprotocol
                     Interconnect over X.25";
     }
     identity sonet {
       base iana-interface-type;
       description
         "SONET или SDH.";
     }
     identity x25ple {
       base iana-interface-type;
       reference
         "RFC 2127 - ISDN Management Information Base using SMIv2";
     }
     identity iso88022llc {
       base iana-interface-type;
     }
     identity localTalk {
       base iana-interface-type;
     }
     identity smdsDxi {
       base iana-interface-type;
     }
     identity frameRelayService {
       base iana-interface-type;
       description
         "FRNETSERV-MIB.";
       reference
         "RFC 2954 - Definitions of Managed Objects for Frame
                     Relay Service";
     }
     identity v35 {
       base iana-interface-type;
     }
     identity hssi {
       base iana-interface-type;
     }
     identity hippi {
       base iana-interface-type;
     }
     identity modem {
       base iana-interface-type;
       description
         "Модем общего назначения.";
     }
     identity aal5 {
       base iana-interface-type;
       description
         "AAL5 для ATM.";
     }
     identity sonetPath {
       base iana-interface-type;
     }
     identity sonetVT {
       base iana-interface-type;
     }
     identity smdsIcip {
       base iana-interface-type;
       description
         "SMDS InterCarrier Interface.";
     }
     identity propVirtual {
       base iana-interface-type;
       description
         "Фирменный виртуальный/внутренний.";
       reference
         "RFC 2863 - The Interfaces Group MIB";
     }
     identity propMultiplexor {
       base iana-interface-type;
       description
         "Фирменное мультиплексирование.";
       reference
         "RFC 2863 - The Interfaces Group MIB";
     }
     identity ieee80212 {
       base iana-interface-type;
       description
         "100BaseVG.";
     }
     identity fibreChannel {
       base iana-interface-type;
       description
         "Fibre Channel.";
     }
     identity hippiInterface {
       base iana-interface-type;
       description
         "Интерфейсы HIPPI.";
     }
     identity frameRelayInterconnect {
       base iana-interface-type;
       status obsolete;
       description
         "Заменён на frameRelay(32) или frameRelayService(44).";
     }
     identity aflane8023 {
       base iana-interface-type;
       description
         "ATM Emulated LAN для 802.3.";
     }
     identity aflane8025 {
       base iana-interface-type;
       description
         "ATM Emulated LAN для 802.5.";
     }
     identity cctEmul {
       base iana-interface-type;
       description
         "Эмулируемое устройство в ATM.";
     }
     identity fastEther {
       base iana-interface-type;
       status deprecated;
       description
         "Отменено RFC 3635 с заменой на ethernetCsmacd(6).";
       reference
         "RFC 3635 - Definitions of Managed Objects for the
                     Ethernet-like Interface Types";
     }
     identity isdn {
       base iana-interface-type;
       description
         "ISDN и X.25.";
       reference
         "RFC 1356 - Multiprotocol Interconnect on X.25 and ISDN
                     in the Packet Mode";
     }
     identity v11 {
       base iana-interface-type;
       description
         "CCITT V.11/X.21.";
     }
     identity v36 {
       base iana-interface-type;
       description
         "CCITT V.36.";
     }
     identity g703at64k {
       base iana-interface-type;
       description
         "CCITT G703 при скорости 64 Кбит/с.";
     }
     identity g703at2mb {
       base iana-interface-type;
       status obsolete;
       description
         "Отменено, см.  DS1-MIB.";
     }
     identity qllc {
       base iana-interface-type;
       description
         "SNA QLLC.";
     }
     identity fastEtherFX {
       base iana-interface-type;
       status deprecated;
       description
         "Отменено RFC 3635 с заменой на ethernetCsmacd(6).";
       reference
         "RFC 3635 - Definitions of Managed Objects for the
                     Ethernet-like Interface Types";
     }
     identity channel {
       base iana-interface-type;
       description
         "Канал.";
     }
     identity ieee80211 {
       base iana-interface-type;
       description
         "Радиодиапазон.";
     }
     identity ibm370parChan {
       base iana-interface-type;
       description
         "Канал IBM System 360/370 OEMI.";
     }
     identity escon {
       base iana-interface-type;
       description
         "Соединение IBM Enterprise Systems.";
     }
     identity dlsw {
       base iana-interface-type;
       description
         "Коммутация на канальном уровне.";
     }
     identity isdns {
       base iana-interface-type;
       description
         "Интерфейс ISDN S/T.";
     }
     identity isdnu {
       base iana-interface-type;
       description
         "Интерфейс ISDN U.";
     }
     identity lapd {
       base iana-interface-type;
       description
         "Протокол доступа к каналу D.";
     }
     identity ipSwitch {
       base iana-interface-type;
       description
         "Коммутирующие объекты IP.";
     }
     identity rsrb {
       base iana-interface-type;
       description
         "Мост Remote Source Route.";
     }
     identity atmLogical {
       base iana-interface-type;
       description
         "Логический порт ATM.";
       reference
         "RFC 3606 - Definitions of Supplemental Managed Objects
                     for ATM Interface";
     }
     identity ds0 {
       base iana-interface-type;
       description
         "Цифровой сигнал уровня 0.";
       reference
         "RFC 2494 - Definitions of Managed Objects for the DS0
                     and DS0 Bundle Interface Type";
     }
     identity ds0Bundle {
       base iana-interface-type;
       description
         "Группа ds0 на одном ds1.";
       reference
         "RFC 2494 - Definitions of Managed Objects for the DS0
                     and DS0 Bundle Interface Type";
     }
     identity bsc {
       base iana-interface-type;
       description
         "Бисинхронный протокол.";
     }
     identity async {
       base iana-interface-type;
       description
         "Асинхронный протокол.";
     }
     identity cnr {
       base iana-interface-type;
       description
         "Combat Net Radio.";
     }
     identity iso88025Dtr {
       base iana-interface-type;
       description
         "ISO 802.5r DTR.";
     }
     identity eplrs {
       base iana-interface-type;
       description
         "Ext Pos Loc Report Sys.";
     }
     identity arap {
       base iana-interface-type;
       description
         "Протокол удалённого доступа Appletalk.";
     }
     identity propCnls {
       base iana-interface-type;
       description
         "Фирменный протокол без организации соединений.";
     }
     identity hostPad {
       base iana-interface-type;
       description
         "Протокол CCITT-ITU X.29 PAD.";
     }
     identity termPad {
       base iana-interface-type;
       description
         "Объект CCITT-ITU X.3 PAD.";
     }
     identity frameRelayMPI {
       base iana-interface-type;
       description
         "Multiproto Interconnect по протоколу FR.";
     }
     identity x213 {
       base iana-interface-type;
       description
         "CCITT-ITU X213.";
     }
     identity adsl {
       base iana-interface-type;
       description
         "Асимметричная цифровая абонентская линия.";
     }
     identity radsl {
       base iana-interface-type;
       description
         "Цифровая абонентская линия с адаптацией скорости.";
     }
     identity sdsl {
       base iana-interface-type;
       description
         "Симметричная цифровая абонентская линия.";
     }
     identity vdsl {
       base iana-interface-type;
       description
         "Высокоскоростная цифровая абонентская линия.";
     }
     identity iso88025CRFPInt {
       base iana-interface-type;
       description
         "ISO 802.5 CRFP.";
     }
     identity myrinet {
       base iana-interface-type;
       description
         "Myricom Myrinet.";
     }
     identity voiceEM {
       base iana-interface-type;
       description
         "Приём и передача голоса.";
     }
     identity voiceFXO {
       base iana-interface-type;
       description
         "Голосовой интерфейс телефонной станции.";
     }
     identity voiceFXS {
       base iana-interface-type;
       description
         "Голосовой интерфейс телефонного оборудования.";
     }
     identity voiceEncap {
       base iana-interface-type;
       description
         "Инкапсуляция голоса.";
     }
     identity voiceOverIp {
       base iana-interface-type;
       description
         "Инкапсуляция голоса в IP.";
     }
     identity atmDxi {
       base iana-interface-type;
       description
         "ATM DXI.";
     }
     identity atmFuni {
       base iana-interface-type;
       description
         "ATM FUNI.";
     }
     identity atmIma {
       base iana-interface-type;
       description
         "ATM IMA.";
     }
     identity pppMultilinkBundle {
       base iana-interface-type;
       description
         "Связка каналов PPP Multilink.";
     }
     identity ipOverCdlc {
       base iana-interface-type;
       description
         "IBM ipOverCdlc.";
     }
     identity ipOverClaw {
       base iana-interface-type;
       description
         "Общий канал доступа к рабочим станциям IBM.";
     }
     identity stackToStack {
       base iana-interface-type;
       description
         "IBM stackToStack.";
     }
     identity virtualIpAddress {
       base iana-interface-type;
       description
         "IBM VIPA.";
     }
     identity mpc {
       base iana-interface-type;
       description
         "Поддержка многопротокольных каналов IBM.";
     }
     identity ipOverAtm {
       base iana-interface-type;
       description
         "IBM ipOverAtm.";
       reference
         "RFC 2320 - Definitions of Managed Objects for Classical IP
                     and ARP Over ATM Using SMIv2 (IPOA-MIB)";
     }
     identity iso88025Fiber {
       base iana-interface-type;
       description
         "ISO 802.5j Fiber Token Ring.";
     }
     identity tdlc {
       base iana-interface-type;
       description
         "Управление каналом данных IBM twinaxial.";
     }
     identity gigabitEthernet {
       base iana-interface-type;
       status deprecated;
       description
         "Отменено RFC 3635 с заменой на ethernetCsmacd(6).";
       reference
         "RFC 3635 - Definitions of Managed Objects for the
                     Ethernet-like Interface Types";
     }
     identity hdlc {
       base iana-interface-type;
       description
         "HDLC.";
     }
     identity lapf {
       base iana-interface-type;
       description
         "LAP F.";
     }
     identity v37 {
       base iana-interface-type;
       description
         "V.37.";
     }
     identity x25mlp {
       base iana-interface-type;
       description
         "Многоканальный протокол.";
     }
     identity x25huntGroup {
       base iana-interface-type;
       description
         "X25 Hunt Group.";
     }
     identity transpHdlc {
       base iana-interface-type;
       description
         "Прозрачный HDLC.";
     }
     identity interleave {
       base iana-interface-type;
       description
         "Канал с чередованием.";
     }
     identity fast {
       base iana-interface-type;
       description
         "Быстрый канал.";
     }
     identity ip {
       base iana-interface-type;
       description
         "IP (для APPN HPR в сетях IP).";
     }
     identity docsCableMaclayer {
       base iana-interface-type;
       description
         "Уровень CATV Mac.";
     }
     identity docsCableDownstream {
       base iana-interface-type;
       description
         "Нисходящий интерфейс CATV.";
     }
     identity docsCableUpstream {
       base iana-interface-type;
       description
         "Восходящий интерфейс CATV.";
     }
     identity a12MppSwitch {
       base iana-interface-type;
       description
         "Параллельный процессор Avalon.";
     }
     identity tunnel {
       base iana-interface-type;
       description
         "Интерфейс инкапсуляции.";
     }
     identity coffee {
       base iana-interface-type;
       description
         "Coffee pot.";
       reference
         "RFC 2325 - Coffee MIB";
     }
     identity ces {
       base iana-interface-type;
       description
         "Служба эмуляции устройств (каналов).";
     }
     identity atmSubInterface {
       base iana-interface-type;
       description
         "Субинтерфейс ATM.";
     }
     identity l2vlan {
       base iana-interface-type;
       description
         "Виртуальная ЛВС L2 с использованием 802.1Q.";
     }
     identity l3ipvlan {
       base iana-interface-type;
       description
         "Виртуальная ЛВС L3 с использованием IP.";
     }
     identity l3ipxvlan {
       base iana-interface-type;
       description
         "Виртуальная ЛВС L3 с использованием IPX.";
     }
     identity digitalPowerline {
       base iana-interface-type;
       description
         "IP через электросеть.";
     }
     identity mediaMailOverIp {
       base iana-interface-type;
       description
         "Multimedia-почта по протоколу IP.";
     }
     identity dtm {
       base iana-interface-type;
       description
         "Динамический синхронный режим передачи.";
     }
     identity dcn {
       base iana-interface-type;
       description
         "Сеть передачи данных.";
     }
     identity ipForward {
       base iana-interface-type;
       description
         "Интерфейс пересылки IP.";
     }
     identity msdsl {
       base iana-interface-type;
       description
         "Многоскоростной симметричный интерфейс DSL.";
     }
     identity ieee1394 {
       base iana-interface-type;
       description
         "Высокопроизводительная последовательная шина IEEE1394.";
     }
     identity if-gsn {
       base iana-interface-type;
       description
         "HIPPI-6400.";
     }
     identity dvbRccMacLayer {
       base iana-interface-type;
       description
         "MAC-уровень DVB-RCC.";
     }
     identity dvbRccDownstream {
       base iana-interface-type;
       description
         "Нисходящий канал DVB-RCC.";
     }
     identity dvbRccUpstream {
       base iana-interface-type;
       description
         "Восходящий канал DVB-RCC .";
     }
     identity atmVirtual {
       base iana-interface-type;
       description
         "Виртуальный интерфейс ATM.";
     }
     identity mplsTunnel {
       base iana-interface-type;
       description
         "Виртуальный интерфейс MPLS.";
     }
     identity srp {
       base iana-interface-type;
       description
         "Протокол пространственного разделения.";
     }
     identity voiceOverAtm {
       base iana-interface-type;
       description
         "Голос по протоколу ATM.";
     }
     identity voiceOverFrameRelay {
       base iana-interface-type;
       description
         " Голос по протоколу Frame Relay.";
     }
     identity idsl {
       base iana-interface-type;
       description
         "DSL через ISDN.";
     }
     identity compositeLink {
       base iana-interface-type;
       description
         "Интерфейс композитного канала Avici.";
     }
     identity ss7SigLink {
       base iana-interface-type;
       description
         "Сигнальный канал SS7.";
     }
     identity propWirelessP2P {
       base iana-interface-type;
       description
         "Беспроводный интерфейс Prop. P2P.";
     }
     identity frForward {
       base iana-interface-type;
       description
         "Интерфейс пересылки кадров.";
     }
     identity rfc1483 {
       base iana-interface-type;
       description
         "Многопротокольная поддержка на основе ATM AAL5.";
       reference
         "RFC 1483 - Multiprotocol Encapsulation over ATM
                     Adaptation Layer 5";
     }
     identity usb {
       base iana-interface-type;
       description
         "Интерфейс USB.";
     }
     identity ieee8023adLag {
       base iana-interface-type;
       description
         "Агрегат каналов IEEE 802.3ad.";
     }
     identity bgppolicyaccounting {
       base iana-interface-type;
       description
         "BGP Policy Accounting.";
     }
     identity frf16MfrBundle {
       base iana-interface-type;
       description
         "Многоканальный интерфейс FRF.16.";
     }
     identity h323Gatekeeper {
       base iana-interface-type;
       description
         "H323 Gatekeeper.";
     }
     identity h323Proxy {
       base iana-interface-type;
       description
         "Прокси H323 для голоса и видео.";
     }
     identity mpls {
       base iana-interface-type;
       description
         "MPLS.";
     }
     identity mfSigLink {
       base iana-interface-type;
       description
         "Многочастотный сигнальный канал.";
     }
     identity hdsl2 {
       base iana-interface-type;
       description
         "Высокоскоростной интерфейс DSL второго поколения.";
     }
     identity shdsl {
       base iana-interface-type;
       description
         "Многоскоростной интерфейс HDSL2.";
     }
     identity ds1FDL {
       base iana-interface-type;
       description
         "Канал данных (4 Кбит/с) в DS1.";
     }
     identity pos {
       base iana-interface-type;
       description
         "Пакетный интерфейс SONET/SDH.";
     }
     identity dvbAsiIn {
       base iana-interface-type;
       description
         "Вход DVB-ASI.";
     }
     identity dvbAsiOut {
       base iana-interface-type;
       description
         "Выход DVB-ASI.";
     }
     identity plc {
       base iana-interface-type;
       description
         "Связь по проводам питания.";
     }
     identity nfas {
       base iana-interface-type;
       description
         "Не связанная с оборудованием сигнализация.";
     }
     identity tr008 {
       base iana-interface-type;
       description
         "TR008.";
     }
     identity gr303RDT {
       base iana-interface-type;
       description
         "Удалённый цифровой терминал.";
     }
     identity gr303IDT {
       base iana-interface-type;
       description
         "Интегрированный цифровой терминал.";
     }
     identity isup {
       base iana-interface-type;
       description
         "ISUP.";
     }
     identity propDocsWirelessMaclayer {
       base iana-interface-type;
       description
         "Фирменный уровень Cisco MAC.";
     }
     identity propDocsWirelessDownstream {
       base iana-interface-type;
       description
         "Фирменный нисходящий интерфейс Cisco.";
     }
     identity propDocsWirelessUpstream {
       base iana-interface-type;
       description
         "Фирменный восходящий интерфейс Cisco.";
     }
     identity hiperlan2 {
       base iana-interface-type;
       description
         "HIPERLAN Type 2 Radio Interface.";
     }
     identity propBWAp2Mp {
       base iana-interface-type;
       description
         "PropBroadbandWirelessAccesspt2Multipt (использование
          этого значения для интерфейсов IEEE 802.16 WMAN в 
          соответствии с IEEE Std 802.16f отменено с заменой на 
          ieee80216WMAN(237)).";
     }
     identity sonetOverheadChannel {
       base iana-interface-type;
       description
         "Наложенный канал SONET.";
     }
     identity digitalWrapperOverheadChannel {
       base iana-interface-type;
       description
         "наложенный цифровой канал.";
     }
     identity aal2 {
       base iana-interface-type;
       description
         "Адаптации ATM уровня 2.";
     }
     identity radioMAC {
       base iana-interface-type;
       description
         "MAC-уровень для радиоканалов.";
     }
     identity atmRadio {
       base iana-interface-type;
       description
         "ATM по радиоканалам.";
     }
     identity imt {
       base iana-interface-type;
       description
         "Межмашинные транки.";
     }
     identity mvl {
       base iana-interface-type;
       description
         "DSL с множеством виртуальных линий.";
     }
     identity reachDSL {
       base iana-interface-type;
       description
         "DSL для длинных линий.";
     }
     identity frDlciEndPt {
       base iana-interface-type;
       description
         "Конечная точка Frame Relay DLCI.";
     }
     identity atmVciEndPt {
       base iana-interface-type;
       description
         "Конечная точка ATM VCI.";
     }
     identity opticalChannel {
       base iana-interface-type;
       description
         "Оптический канал.";
     }
     identity opticalTransport {
       base iana-interface-type;
       description
         "Оптический транспорт.";
     }
     identity propAtm {
       base iana-interface-type;
       description
         "Фирменный интерфейс ATM.";
     }
     identity voiceOverCable {
       base iana-interface-type;
       description
         "Интерфейс передачи голоса по кабелю.";
     }
     identity infiniband {
       base iana-interface-type;
       description
         "Infiniband.";
     }
     identity teLink {
       base iana-interface-type;
       description
         "Канал TE.";
     }
     identity q2931 {
       base iana-interface-type;
       description
         "Q.2931.";
     }
     identity virtualTg {
       base iana-interface-type;
       description
         "Виртуальная транк-группа.";
     }
     identity sipTg {
       base iana-interface-type;
       description
         "Транк-группа SIP.";
     }
     identity sipSig {
       base iana-interface-type;
       description
         "Сигнализация SIP.";
     }
     identity docsCableUpstreamChannel {
       base iana-interface-type;
       description
         "Восходящий канал CATV.";
     }
     identity econet {
       base iana-interface-type;
       description
         "Acorn Econet.";
     }
     identity pon155 {
       base iana-interface-type;
       description
         "Симметричный интерфейс PON FSAN 155 Мбит/с.";
     }
     identity pon622 {
       base iana-interface-type;
       description
         "Симметричный интерфейс PON FSAN 622 Мбит/с.";
     }
     identity bridge {
       base iana-interface-type;
       description
         "Интерфейс прозрачного моста.";
     }
     identity linegroup {
       base iana-interface-type;
       description
         "Общий для множества линий интерфейс.";
     }
     identity voiceEMFGD {
       base iana-interface-type;
       description
         "Voice E&M Feature Group D.";
     }
     identity voiceFGDEANA {
       base iana-interface-type;
       description
         "Voice FGD Exchange Access North American.";
     }
     identity voiceDID {
       base iana-interface-type;
       description
         "Прямой входящий набор для голосовой связи.";
     }
     identity mpegTransport {
       base iana-interface-type;
       description
         "Транспортный интерфейс MPEG.";
     }
     identity sixToFour {
       base iana-interface-type;
       status deprecated;
       description
         "Интерфейс 6to4 (ОТМЕНЕН).";
       reference
         "RFC 4087 - IP Tunnel MIB";
     }
     identity gtp {
       base iana-interface-type;
       description
         "GTP (туннельный протокол GPRS).";
     }
     identity pdnEtherLoop1 {
       base iana-interface-type;
       description
         "Paradyne EtherLoop 1.";
     }
     identity pdnEtherLoop2 {
       base iana-interface-type;
       description
         "Paradyne EtherLoop 2.";
     }
     identity opticalChannelGroup {
       base iana-interface-type;
       description
         "Группа оптических каналов.";
     }
     identity homepna {
       base iana-interface-type;
       description
         "HomePNA ITU-T G.989.";
     }
     identity gfp {
       base iana-interface-type;
       description
         "Базовая процедура кадрирования (GFP3).";
     }
     identity ciscoISLvlan {
       base iana-interface-type;
       description
         "Виртуальная ЛВС L2 с использованием Cisco ISL.";
     }
     identity actelisMetaLOOP {
       base iana-interface-type;
       description
         "Фирменный высокоскоростной канал Acteleis MetaLOOP.";
     }
     identity fcipLink {
       base iana-interface-type;
       description
         "Канал FCIP.";
     }
     identity rpr {
       base iana-interface-type;
       description
         "Интерфейс отказоустойчивого пакетного кольца.";
     }
     identity qam {
       base iana-interface-type;
       description
         "Интерфейс RF Qam.";
     }
     identity lmp {
       base iana-interface-type;
       description
         "Протокол управления каналом.";
       reference
         "RFC 4327 - Link Management Protocol (LMP) Management
                     Information Base (MIB)";
     }
     identity cblVectaStar {
       base iana-interface-type;
       description
         "Cambridge Broadband Networks Limited VectaStar.";
     }
     identity docsCableMCmtsDownstream {
       base iana-interface-type;
       description
         "Нисходящий интерфейс CATV Modular CMTS.";
     }
     identity adsl2 {
       base iana-interface-type;
       status deprecated;
       description
         "Асимметричная цифровая абонентская линия версии 2
          (ОТМЕНЕНО/УСТАРЕЛО с заменой на adsl2plus(238)).";
       reference
         "RFC 4706 - Definitions of Managed Objects for Asymmetric
                     Digital Subscriber Line 2 (ADSL2)";
     }
     identity macSecControlledIF {
       base iana-interface-type;
       description
         "MACSecControlled.";
     }
     identity macSecUncontrolledIF {
       base iana-interface-type;
       description
         "MACSecUncontrolled.";
     }
     identity aviciOpticalEther {
       base iana-interface-type;
       description
         "Агрегат Avici Optical Ethernet.";
     }
     identity atmbond {
       base iana-interface-type;
       description
         "atmbond.";
     }
     identity voiceFGDOS {
       base iana-interface-type;
       description
         "Операторский сервис Voice FGD.";
     }
     identity mocaVersion1 {
       base iana-interface-type;
       description
         "Интерфейс MoCA4 в соответствии с документацией, приватно
          переданной агентству IANA.";
     }
     identity ieee80216WMAN {
       base iana-interface-type;
       description
         "Интерфейс IEEE 802.16 WMAN.";
     }
     identity adsl2plus {
       base iana-interface-type;
       description
         "Асимметричная цифровая абонентская линия версии 2 -
          2+ и все варианты.";
     }
     identity dvbRcsMacLayer {
       base iana-interface-type;
       description
         "MAC-уровень DVB-RCS.";
       reference
         "RFC 5728 - The SatLabs Group DVB-RCS MIB";
     }
     identity dvbTdm {
       base iana-interface-type;
       description
         "DVB Satellite TDM.";
       reference
         "RFC 5728 - The SatLabs Group DVB-RCS MIB";
     }
     identity dvbRcsTdma {
       base iana-interface-type;
       description
         "DVB-RCS TDMA.";
       reference
         "RFC 5728 - The SatLabs Group DVB-RCS MIB";
     }
     identity x86Laps {
       base iana-interface-type;
       description
         "LAPS на основе ITU-T X.86/Y.1323.";
     }
     identity wwanPP {
       base iana-interface-type;
       description
         "3GPP WWAN.";
     }
     identity wwanPP2 {
       base iana-interface-type;
       description
         "3GPP2 WWAN.";
     }
     identity voiceEBS {
       base iana-interface-type;
       description
         "Физический голосовой интерфейс P-phone EBS.";
     }
     identity ifPwType {
       base iana-interface-type;
       description
         "Интерфейс псевдопровода.";
       reference
         "RFC 5601 - Pseudowire (PW) Management Information Base (MIB)";
     }
     identity ilan {
       base iana-interface-type;
       description
         "Внутренняя ЛВС на мосту IEEE 802.1ap.";
     }
     identity pip {
       base iana-interface-type;
       description
         "Экземпляр провайдерского порта на мосту IEEE 802.1ah PBB.";
     }
     identity aluELP {
       base iana-interface-type;
       description
         "Защита канала Ethernet от Alcatel-Lucent.";
     }
     identity gpon {
       base iana-interface-type;
       description
         "Гигабитная пассивная оптическая сеть G-PON1 ITU-T G.948.";
     }
     identity vdsl2 {
       base iana-interface-type;
       description
         "Высокоскоростная цифровая абонентская линия версии 2
          (в соответствии с ITU-T G.993.2).";
       reference
         "RFC 5650 - Definitions of Managed Objects for Very High
                     Speed Digital Subscriber Line 2 (VDSL2)";
     }
     identity capwapDot11Profile {
       base iana-interface-type;
       description
         "Интерфейс профиля WLAN.";
       reference
         "RFC 5834 - Control and Provisioning of Wireless Access
                     Points (CAPWAP) Protocol Binding MIB for
                     IEEE 802.11";
     }
     identity capwapDot11Bss {
       base iana-interface-type;
       description
         "Интерфейс WLAN BSS.";
       reference
         "RFC 5834 - Control and Provisioning of Wireless Access
                     Points (CAPWAP) Protocol Binding MIB for
                     IEEE 802.11";
     }
     identity capwapWtpVirtualRadio {
       base iana-interface-type;
       description
         "Виртуальный радиоинтерфейс WWTP.";
       reference
         "RFC 5833 - Control and Provisioning of Wireless Access
                     Points (CAPWAP) Protocol Base MIB";
     }
     identity bits {
       base iana-interface-type;
       description
         "bitsport.";
     }
     identity docsCableUpstreamRfPort {
       base iana-interface-type;
       description
         "Восходящий порт RF в DOCSIS CATV.";
     }
     identity cableDownstreamRfPort {
       base iana-interface-type;
       description
         "Нисходящий порт RF в CATV.";
     }
     identity vmwareVirtualNic {
       base iana-interface-type;
       description
         "Виртуальный сетевой интерфейс VMware.";
     }
     identity ieee802154 {
       base iana-interface-type;
       description
         "Интерфейс IEEE 802.15.4 WPAN.";
       reference
         "IEEE 802.15.4-2006";
     }
     identity otnOdu {
       base iana-interface-type;
       description
         "Оптический модуль данных OTN.";
     }
     identity otnOtu {
       base iana-interface-type;
       description
         "Транспортный модуль оптического канала OTN.";
     }
     identity ifVfiType {
       base iana-interface-type;
       description
         "Тип интерфейса пересылающего экземпляра VPLS.";
     }
     identity g9981 {
       base iana-interface-type;
       description
         "Связанный интерфейс G.998.1.";
     }
     identity g9982 {
       base iana-interface-type;
       description
         "Связанный интерфейс G.998.2.";
     }
     identity g9983 {
       base iana-interface-type;
       description
         "Связанный интерфейс G.998.3.";
     }
     identity aluEpon {
       base iana-interface-type;
       description
         "Пассивные оптические сети Ethernet (E-PON5).";
     }
     identity aluEponOnu {
       base iana-interface-type;
       description
         "Модуль оптической сети EPON.";
     }
     identity aluEponPhysicalUni {
       base iana-interface-type;
       description
         "Физический интерфейс между пользователем и сетью EPON.";
     }
     identity aluEponLogicalLink {
       base iana-interface-type;
       description
         "Эмуляция канала «точка-точка» через уровень EPON.";
     }
     identity aluGponOnu {
       base iana-interface-type;
       description
         "Модуль оптической сети GPON.";
       reference
         "ITU-T G.984.2";
     }
     identity aluGponPhysicalUni {
       base iana-interface-type;
       description
         "Физический интерфейс между пользователем и сетью GPON.";
       reference
         "ITU-T G.984.2";
     }
     identity vmwareNicTeam {
       base iana-interface-type;
       description
         "VMware NIC Team.";
     }
   }

   <CODE ENDS>

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

Этот документ определяет первую версию поддерживаемого IANA модуля YANG iana-if-type.

Модуль YANG iana-if-type предназначен для отражения реестра ifType definitions [IFTYPE-IANA-REGISTRY], так же как этот реестр отражается в модуле IANAifType-MIB [IANAifType-MIB].

Агентство IANA добавило новое примечание в реестр iana-if-type YANG Module.

Типы интерфейсов недопустимо напрямую добавлять в модуль YANG iana-if-type, они должны добавляться в реестр ifType definitions.

При добавлении типа интерфейса в реестр ifType definitions должен добавляться новый оператор identity в модуль YANG iana-if-type. Имя identity должно совпадать с соответствующим перечисляемым именем в IANAifType-MIB. Следует определять перечисленные ниже субоператоры вместе с оператором identity.

base

Содержит значение iana-interface-type.

status

Включается только для отменённых (значение deprecated) или устаревших (значение obsolete) регистраций.

description

Дублирует описание из реестра, если оно имеется. Используются символы перевода строки, чтобы размер строк не превышал 72 символов.

reference

Дублирует ссылку из реестра, если она имеется, и добавляет название документа.

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

При обновлении модуля YANG iana-if-type должен добавляться новый оператор revision перед имеющимися такими операторами.

Агентство IANA добавило новое примечание в реестр ifType definitions.

При обновлении реестра должен обновляться модуль YANG iana-if-type, определённый в RFC 7224.

Текст раздела Reference в реестре ifType definitions был изменён, как показано ниже.

      Старый текст
        [RFC1213][RFC2863]
      Новый текст
        [RFC1213][RFC2863][RFC7224]

3.1. Регистрация URI

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

      URI: urn:ietf:params:xml:ns:yang:iana-if-type
      Registrant Contact: IANA.
      XML: N/A; запрошенный URI является пространством имён XML.

3.2. Регистрация модуля YANG

Этот документ регистрирует модуль YANG в реестре «YANG Module Names» [RFC6020].

      name:         iana-if-type
      namespace:    urn:ietf:params:xml:ns:yang:iana-if-type
      prefix:       ianaift
      reference:    RFC 7224

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

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

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

[IANAifType-MIB] Internet Assigned Numbers Authority, «IANAifType Textual Convention definitions», <http://www.iana.org/assignments/ianaiftype-mib>.

[IFTYPE-IANA-REGISTRY] Internet Assigned Numbers Authority, «ifType Definitions», <http://www.iana.org/assignments/smi-numbers>.

[RFC3688] Mealling, M., «The IETF XML Registry», BCP 81, RFC 3688, January 2004.

[RFC6020] Bjorklund, M., «YANG — A Data Modeling Language for the Network Configuration Protocol (NETCONF)», RFC 6020, October 2010.

[RFC7223] Bjorklund, M., «A YANG Data Model for Interface Management», RFC 7223, May 2014.

Адрес автора

Martin Bjorklund

Tail-f Systems

EMail: mbj@tail-f.com

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

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

nmalykh@protokols.ru

Internet Engineering Task Force (IETF)                        T. Clausen
Request for Comments: 7181                      LIX, Ecole Polytechnique
Category: Standards Track                                    C. Dearlove
ISSN: 2070-1721                                          BAE Systems ATC
                                                              P. Jacquet
                                                Alcatel-Lucent Bell Labs
                                                              U. Herberg
                                         Fujitsu Laboratories of America
                                                              April 2014

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

The Optimized Link State Routing Protocol Version 2

PDF

Аннотация

Эта спецификация описывает версию 2 протокола OLSRv2¹ для сетей MANET².

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

Этот документ является проектом стандарта Internet (Internet Standards Track).

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

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

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

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

Документ может содержать материалы из IETF Document или IETF Contribution, опубликованных или публично доступных до 10 ноября 2008 года. Лица, контролирующие авторские права на некоторые из таких документов, могли не предоставить IETF Trust права разрешать внесение изменений в такие документы за рамками процессов IETF Standards. Без получения соответствующего разрешения от лиц, контролирующих авторские права этот документ не может быть изменен вне рамок процесса IETF Standards, не могут также создаваться производные документы за рамками процесса IETF Standards за исключением форматирования документа для публикации или перевода с английского языка на другие языки.

1. Введение

Протокол OLSRv2⁵ является развитием протокола OLSR (версии 1), опубликованного в [RFC3626]. OLSRv2 при выборе кратчайшего пути использует те же механизмы и алгоритмы, что и [RFC3626], но усовершенствованные за счет использования метрики, отличающейся от числа интервалов. В OLSRv2 также применяется более гибкая и эффективная модель сигнализации, а также внесено некоторое упрощение в процесс обмена сообщениями.

Протокол OLSRv2 разработан для сетей MANET⁶. Протокол работает на основе регулярного обмена топологической информацией между маршрутизаторами. OLSRv2 представляет собой оптимизацию классического протокола маршрутизации по состояниям каналов. Ключевым элементом концепции являются многоточечные трансляторы (MPR⁷). Каждый маршрутизатор выбирает два набора MPR, каждый из которых является множеством соседних маршрутизаторов, «покрывающим» все симметрично подключенные маршрутизаторы «второго интервала» (2-hop neighbor router). Наборы MPR называются «рассылающими MPR» (flooding MPR) и «маршрутизирующими MPR» (routing MPR) и применяются для снижения уровня лавинных рассылок и упрощения топологии, соответственно.

Снижение объема лавинных рассылок обеспечивается путем контроля трафика, который будет рассылаться лавинообразно через сеть с использованием поэтапной (hop-by-hop) пересылки, при этом маршрутизатору нужно пересылать лишь управляющий трафик, который был впервые получен напрямую от одного из маршрутизаторов, которые выбраны в качестве рассылающих MPR (flooding MPR selectors). Этот механизм, названный MPR flooding, обеспечивает эффективный способ распространения информации внутри сетей MANET за счет снижения числа требуемых передач [MPR].

Упрощение топологии обеспечивается путем назначения особой ответственности для маршрутизаторов, выбранных в качестве routing MPR, при декларировании информации о состоянии каналов. Для OLSRv2 достаточным требованием для обеспечения кратчайших маршрутов ко всем получателям является декларирование информации о состоянии каналов маршрутизаторам из своего routing MPR (если они есть). Маршрутизаторам, не выбранным в routing MPR, не нужно передавать данные о состоянии каналов. На основе этой сокращенной информации о состоянии канала routing MPR используются в качестве промежуточных маршрутизаторов на многоэтапных (multi-hop) маршрутах.

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

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

OLSRv2 использует и расширяет протокол NHDP⁸, определенный в [RFC6130], и также обобщенный формат пакетов и сообщений MANET [RFC5444] с описанными в [RFC5497] TLV, а также может использовать вариации message jitter, как описано в [RFC5148]. Все эти 4 протокола и спецификации создавались в рамках разработки OLSRv2, но были выделены в отдельные документы для более широкого применения.

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

OLSRv2, подобно OLSR [RFC3626], использует концепции пересылки и трансляции HIPERLAN⁹ (протокол уровня MAC), стандартизованного ETSI [HIPERLAN] [HIPERLAN2]. Данный документ не отменяет действия [RFC3626], который сохраняется для дальнейших экспериментов.

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

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

Все термины, введенные в [RFC5444], включая packet, Packet Header, message, Message Header, Message Body, Message Type, message sequence number, hop limit, hop count, Address Block, TLV Block, TLV, Message TLV, Address Block TLV, type (для TLV), type extension (для TLV), value (для TLV), address, address prefix, address object, интерпретируются в соответствии с этим документом.

Все термины, введенные в [RFC6130], включая interface, MANET interface, network address, link, symmetric link, symmetric 1-hop neighbor, symmetric 2-hop neighbor, symmetric 1-hop neighborhood constant, interface parameter, router parameter, Information Base, HELLO message, интерпретируются в соответствии с этим документом.

В дополнение к этому данная спецификация использует описанные ниже термины.

Router — маршрутизатор

Маршрутизатор MANET, реализующий данный протокол.

OLSRv2 interface — интерфейс OLSRv2

Интерфейс MANET, на котором работает данный протокол. Маршрутизатор, на котором используется данный протокол, должен иметь хотя бы один интерфейс OLSRv2.

Routable address — маршрутизируемый адрес

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

Originator address — адрес инициатора

Адрес, являющийся уникальным (в рамках MANET) для маршрутизатора. Маршрутизатор должен выбрать originator address и может использовать в этом качестве адрес одного из своих интерфейсов, который может быть как маршрутизируемым, так и немаршрутизируемым. Недопустимо использовать в качестве адреса инициатора широковещательные, групповые и anycast-адреса. Если маршрутизатор выбирает маршрутизируемый адрес, это должен быть адрес, воспринимаемый маршрутизатором в качестве адреса получателя. Для адреса инициатора недопустимо использовать размер префикса за исключением случаев, когда он включен в Address Block, где может быть связан с префиксом максимального размера (например, если адрес инициатора представляет собой адрес IPv6, он должен иметь размер префикса 128или не иметь его совсем).

Message originator address — адрес инициатора сообщения

Адрес инициатора для маршрутизатора, создавшего сообщение, извлекаемый получателем этого сообщения. Для всех сообщений, используемых в данной спецификации, а также сообщений HELLO, определенных в [RFC6130], получатель должен быть способен выделить адрес инициатора. Обычно адрес инициатора сообщения включается в сообщение, как элемент <msg-orig-addr> в соответствии с определением [RFC5444]. Однако маршрутизаторы с единственным адресом могут не включать элемент <msg-orig-addr> в свои сообщения HELLO.

Willingness — готовность

Численное значение от WILL_NEVER до WILL_ALWAYS (включительно), которое представляет готовность маршрутизатора быть выбранным в качестве MPR. Маршрутизатор имеет разные значения готовности быть рассылающим и маршрутизирующим MPR.

Willing symmetric 1-hop neighbor — готовый ближайший сосед с симметричным соединением

Ближайший сосед с симметричным соединением и отличным от WILL_NEVER значением готовности.

Multipoint relay (MPR) — многоточечный транслятор

Маршрутизатор X является MPR для маршрутизатора Y, если Y указал выбор маршрутизатора X в качестве MPR в своем недавнем сообщении HELLO. Маршрутизатор X может быть рассылающим MPR для Y, если он указан в качестве участника рассылки сообщений, полученных от Y, или маршрутизирующим MPR для Y, если он указан в качестве объявляющего информацию о состоянии канала от X до Y. Возможно также совмещение этих ролей.

MPR selector — селектор MPR

Маршрутизатор Y является селектором (рассылающего/маршрутизирующего) MPR для маршрутизатора X, если Y выбрал маршрутизатор X в качестве рассылающего/маршрутизирующего MPR.

MPR flooding — лавинная рассылка MPR

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

EXPIRED — время истекло

Указывает, что для таймера установлено значения, явно предшествующее текущему времени (например, текущее время — 1).

В данной спецификации используются обозначения, принятые в [RFC5444] и [RFC6130].

3. Заявление о применимости

Этот документ является спецификацией OLSRv2 — проактивного протокола, предназначенного для использования в сетях MANET [RFC2501]. Применимость протокола определяется его характеристиками, перечисленными ниже.

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

• Поддерживаются маршрутизаторы, в которых один или множество интерфейсов принимают участие в работе OLSRv2 и все или некоторые из интерфейсов MANET используют протокол [RFC6130]. Множества интерфейсов OLSRv2 с маршрутизаторе, а также его множества интерфейсов MANET и иных типов могут меняться с течением времени. Каждый интерфейс может иметь один или множество сетевых адресов (у некоторых может присутствовать размер префикса), которые могут динамически меняться.

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

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

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

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

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

• Используется [RFC5444], как указано в Приложении «Предусмотренное применение» к этому документу, и [RFC5498].

• Поддерживается «внутренняя» и «внешняя» расширяемость (добавление новых типов сообщений и добавление информации в имеющиеся сообщения), разрешенная [RFC5444].

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

4. Обзор и функциональность протокола

Целью данного протокола является обеспечение каждому маршрутизатору возможности:

• идентифицировать всех получателей в сети;

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

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

4.1. Обзор

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

• Использование протокола NHDP [RFC6130] для идентификации ближайших соседей с симметричным соединением и соседей второго уровня с симметричным соединением.

• Информирование об участии в работе OLSRv2 и готовности выступать в качестве рассылающего или маршрутизирующего MPR с использованием расширения сообщений HELLO, определенных в [RFC6130], путем добавления MPR_WILLING Message TLV. Готовность маршрутизатора к рассылке показывает, что он может выступать в качестве рассылающего MPR. Готовность к маршрутизации показывает, что маршрутизатор готов выступать в качестве промежуточного устройства в системе маршрутизации. Отметим, что маршрутизатор может быть источником и получателем в системе маршрутизации, даже если он не указал готовности выполнять функции рассылающего или маршрутизирующего MPR.

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

• Выбор рассылающих и маршрутизирующих MPR из числа выразивших готовность ближайших соседей с симметричным соединением так, чтобы для каждого набора MPR все соседи второго уровня с симметричным подключением были доступны напрямую или хотя бы через один маршрутизирующий MPR из числа выбранных с использованием пути с подходящей минимальной метрикой по выбора крайней мере для одного маршрутизирующего MPR. Анализ и примеры алгоритмов выбора MPR приведены в [MPR], предложенный алгоритм, подобающим образом адаптированный для каждого набора MPR, рассмотрен в приложении B к данной спецификации. Отметим, что маршрутизаторы не обязаны использовать один и тот же алгоритм для обеспечения интероперабельности в рамках одной сети MANET, но каждый из таких алгоритмов должен иметь определенные свойства, описанные в разделе 18.

• Информация о своем выборе рассылающих и маршрутизирующих MPR в расширенных (путем добавления MPR Address Block TLV с подходящими сетевыми адресами) сообщениях HELLO, определенных в [RFC6130].

• Извлечение информации о выборе рассылающих и маршрутизирующих MPR из MPR Address Block TLV в полученных сообщениях HELLO.

• Определение сообщений типа TC¹⁰, использующих формат из [RFC5444]. Сообщения TC служат для периодической сигнализации между маршрутизатором и выбравшими его в качестве маршрутизирующего MPR через сеть MANET. Сигнализация включает подходящую направленную метрику для соседей (лучшая канальная метрика в данном направлении для этого соседа).

• Возможность включать сообщений TC и HELLO в пакеты, определенные [RFC5444], с использованием номера протокола IP и порта UDP, заданных для MANET в [RFC5498].

• Распространение (диффузия) сообщений TC с использованием механизма ограниченной лавинной рассылки (MPR flooding), при которой пересылку сообщений от маршрутизатора (созданных или пересланных им) осуществляют только выбранные им рассылающие MPR.

Отметим, что указанные расширения [RFC6130] имеют формы, разрешаемые этой спецификацией.

Данная спецификация определяет перечисленные ниже аспекты.

• Требование использовать спецификацию [RFC6130] с параметрами, константами, сообщениями HELLO и информационными базами, которые расширяются данной спецификацией.

• Добавлены две информационных базы — топологическая информация (Topology Information Base) и полученные сообщения (Received Message Information Base).

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

• Для каждого маршрутизатора вводится требование включения адреса инициатора в сообщения HELLO и TC или возможности определить адрес из таких сообщений.

• Указаны новые Message TLV и Address Block TLV, которые используются в соощениях HELLO и TC, включая передачу сведений о состоянии соседа, выборе MPR, внешних шлюзах, метрике каналов, готовности быть MPR и порядковых номерах содержимого. Отметим, что генерация значений (входной) метрики каналов выполняется процессом, не включенным в данную спецификацию, которая описывает лишь распространение и использование этой метрики.

• Сообщения TC генерируются из подходящей информации в базах Information Base.

• База топологической информации обновляется в соответствии с полученными сообщениями TC.

• Механизм лавинной рассылки flooding включает добавление адреса инициатора и порядкового номера сообщения для контроля дубликатов с использованием информации из Received Message Information Base.

• Отклики на другие события типа завершения срока действия информации в Information Bases.

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

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

4.2. Маршрутизаторы и интерфейсы

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

• Это должен быть интерфейс MANET в соответствии с [RFC6130]. В частности, на нем должен быть задан хотя бы один сетевой адрес. Это множество адресов должно быть специфичным для данного маршрутизатора и включать все адреса, которые будут использоваться в качестве адресов отправителей всех пакетов IP, передаваемых с данного интерфейса OLSRv2.

• Интерфейс должен иметь множество параметров в дополнение к заданным в [RFC6130].

• Интерфейс должен иметь Interface Information Base, расширенную по сравнению с [RFC6130].

• Интерфейс должен генерировать и обрабатывать сообщения HELLO в соответствии со спецификацией [RFC6130] и расширениями раздела 15.

В дополнение к описанным интерфейсам OLSRv2 каждый маршрутизатор обладает перечисленными ниже свойствами.

• Может иметь один или множество интерфейсов не-OLSRv2 (которые могут быть или не быть интерфейсами MANET) и/или подключенных локально сетей для которых этот маршрутизатор может воспринимать пакеты IP. Все маршрутизируемые адреса, для которых маршрутизатор воспринимает пакеты IP, должны быть адресами сетевых интерфейсов (OLSRv2 или других) маршрутизатора или адресами локально подключенных сетей.

• Имеет множество параметров в дополнение к заданным в спецификации [RFC6130].

• Имеет базу локальной информации (Local Information Base), расширяющую спецификацию [RFC6130] путем включения выбора адреса инициатора и записей для всех локально подключенных сетей.

• Имеет базу информации о соседях (Neighbor Information Base), расширяющую спецификацию [RFC6130] для записи выбора MPR и анонсов.

• Имеет базу топологической информации (Topology Information Base) с данными из полученных сообщений TC.

• Имеет базу принятых сообщений (Received Message Information Base) с информацией о полученных сообщениях для того, чтобы каждое принятое сообщение TC обрабатывалось только один раз и пересылалось не более одного раза через каждый интерфейс OLSRv2 данного маршрутизатора.

• Генерирует, получает и обрабатывает сообщения TC.

4.3. Обзор информационных баз

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

4.3.1. Локальная информационная база

База Local Information Base определена в [RFC6130] и содержит данные о локальной конфигурации маршрутизатора. Данная спецификация расширяет это определение для включения адреса инициатора и перечисленных свойств маршрутизатора:

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

• конфигурация Local Attached Network Set, содержащая сетевые адреса сетей, для которых данный маршрутизатор может выступать в качестве шлюза (т. е., анонсируемых им в сообщениях TC).

4.3.2. База информации об интерфейсах

База Interface Information Base для каждого интерфейса OLSRv2, определенная в [RFC6130], расширена здесь путем записи в каждую конфигурацию Link Set значений канальной метрики (входящей или исходящей) и данных о выборе flooding MPR.

4.3.3. База информации о соседях

База Neighbor Information Base определена в [RFC6130] и расширена здесь путем добавления в Neighbor Tuple записи для каждого соседа:

• адрес инициатора;

• значения метрики соседа (минимальные значения канальной метрики в указанном направлении для всех симметричных непосредственных (1-hop) соединений с данным соседом).

• Готовность быть рассылающим и маршрутизирующим MPR;

• выбран ли этот сосед в качестве рассылающего или маршрутизирующего MPR данным маршрутизатором и является ли он селектором routing MPR для данного маршрутизатора (запись о состоянии селектора flooding MPR для данного соседа хранится в Interface Information Base);

• анонсируется ли этот сосед в сообщениях TC, передаваемых данным маршрутизатором.

4.3.4. База топологической информации

База Topology Information Base в каждом маршрутизаторе включает перечисленные ниже данные.

• Конфигурация Advertising Remote Router Set, содержащая каждый удаленный маршрутизатор, от которого было получено сообщение TC. Эти данные используются для проверки актуальности информации в получаемых сообщениях TC — устаревшие сообщения игнорируются.

• Конфигурация Router Topology Set, содержащая данные о каналах между маршрутизаторами в сети MANET из полученных сообщений TC.

• Конфигурация Routable Address Topology Set, содержащая информацию о маршрутизируемых адресах в сети MANET (IP-адреса получателей пакетов) и удаленных маршрутизаторах, через которые эти маршрутизирующие адреса доступны напрямую (т. е., находятся в одном интервале маршрутизации IP от удаленного маршрутизатора), из полученных сообщений TC.

• Конфигурация Attached Network Set, содержащая информацию о сетях, для которых удаленные маршрутизаторы анонсируют себя в качестве шлюзов. Эти сети могут находиться на удалении в один или множество интервалов от удаленного маршрутизатора.

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

Назначение Topology Information Base состоит в записи информации, используемой в дополнение к содержимому Local Information Base, Interface Information Bases и Neighbor Information Base для создания конфигурации Routing Set (которая тоже включается в Topology Information Base).

Данная спецификация описывает расчет Routing Set на основе графа топологии (Topology Graph), создаваемого в два этапа. Сначала создается опорный (backbone) граф, представляющий маршрутизаторы сети MANET и связи между ними, на основе данных из Local Information Base, Neighbor Information Base и Router Topology Set. Далее этот граф «декорируется» дополнительными адресами сетей получателей с использованием данных из Local Information Base, Routable Address Topology Set и Attached Network Set.

Topology Graph не требуется записывать в Topology Information Base, поскольку он может быть создан при изменении конфигурации Routing Set или возникновении явной необходимости в его создании (см. Приложение C). Однако реализация может создавать и хранить Topology Graph, если считает это нужным.

4.3.5. База информации о полученных сообщениях

Полученная база  Message Information в каждом маршрутизаторе включает перечисленные ниже данные.

• Конфигурация Received Set для каждого интерфейса OLSRv2, описывающая сообщения TC, полученные данным маршрутизатором от этого интерфейса OLSRv2.

• Конфигурация Processed Set, описывающая обработанные данным маршрутизатором сообщения TC.

• Конфигурация Forwarded Set, описывающая сообщения TC, пересланные данным маршрутизатором.

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

4.4. Обзор сигнализации

Протокол генерирует и обрабатывает сообщения HELLO в соответствии с [RFC6130]. В сообщения HELLO, передаваемые интерфейсами OLSRv2, в соответствии с разделом 15 этой спецификации включается адрес инициатора, канальная метрика и данные о выборе MPR.

Данная спецификация определяет один тип сообщений — TC. Сообщения TC передаются создавшими их маршрутизаторами с упреждающей манере с регулярными интервалами через все интерфейсы OLSRv2. Интервал между сообщениями может быть постоянным или меняться динамически — например, он может уменьшаться в результате перегрузки или стабильности сети. Сообщения TC могут также передаваться в результате изменений в самом маршрутизаторе или анонсируемой им ближайшей окрестности с симметричными соединениями (symmetric 1-hop neighborhood) — например, в результате выбора этого маршрутизатора впервые в качестве маршрутизирующего MPR.

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

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

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

Сообщения TC и HELLO расширены данной спецификацией путем добавления адреса инициатора (явное включение или дедукция при наличии единственного адреса) для маршрутизатора, создавшего сообщение. В сообщениях TC указывается адрес инициатора и маршрутизируемые адреса его анонсируемых соседей в двух разных Address Block TLV (адрес может быть одновременно маршрутизируемым и адресом инициатора). В сообщениях TC указываются также локально подключенные к инициатору сети.

Сообщения TC рассылаются MPR в лавинном режиме через сеть MANET. Маршрутизатор пересылает сообщение TC, принятое на интерфейсе OLSRv2, тогда и только тогда, когда это сообщение не порождено данным маршрутизатором и не пересылалось им ранее, т. е. сообщение получено впервые на данном интерфейсе OLSRv2 и принято от одного из селекторов flooding MPR (порождено или переслано этим селектором).

Для некоторый сообщений TC лавинная рассылка может осуществляться только в части сети, например, для того, чтобы ближние маршрутизаторы обеспечивались более актуальными данными, нежели удаленные, как это происходит в Fisheye State Routing [FSR] и Fuzzy Sighted Link State routing [FSLS]. Для этого используется [RFC5497].

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

4.5. Метрика каналов

OLSRv1 [RFC3626] создает маршруты к получателям с минимальным числом интервалов (hop). Однако во многих, если не в большинстве случаев можно создать лучшие маршруты (в плане качества обслуживания конечных пользователей) на основе метрики каналов.

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

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

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

Спецификация не определяет природу метрики канала. Однако за счет применения расширения типов определенных Address Block TLV спецификация позволяет определять канальную метрику со специфическим значением через распределение агентством IANA или для частного использования. Каждое сообщение HELLO или TC, указывающее метрику канала (или соседа), показывает какая метрика передается, что позволяет маршрутизаторам убедиться в возможности взаимодействия. Если канальная метрика требует дополнительной сигнализации для определения ее значений через сообщения HELLO или иным способом, это допускается но выходит за рамки данной спецификации.

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

4.6. Flooding MPR и Routing MPR

Данная спецификация использует два типа MPR — рассылающие (flooding MPR) и маршрутизирующие (routing MPR). Трансляторы выбираются раздельно, поскольку:

• рассылающие MPR могут использовать метрику, маршрутизирующие MPR должны ее использовать;

• когда рассылающие MPR используют метрику, это исходящая канальная метрика, маршрутизирующие MPR используют входящую метрику соседей;

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

4.7. Использование Routing Set

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

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

Сигнализация в данной спецификации разработана так, что «опорный» граф топологии («backbone» Topology Graph) для маршрутизаторов, каждый из которых идентифицируется своим адресом инициатора, а для любой пары маршрутизаторов имеется по крайней мере одно прямое соединение, может быть создан (из Neighbor Set и Router Topology Set) с использованием подходящего алгоритма минимального пути. В Topology Graph могут после этого добавляться адреса сетей (маршрутизируемые или от ближайших соседей с симметричным подключением) с использованием данных из Interface Information Base, Routable Address Topology Set и Attached Network Set.

5. Протокольные параметры и константы

В этой спецификации используются параметры и константы, определенные в [RFC6130] и последующих параграфах данного документа. В этой спецификации также используется деление параметров [RFC6130] на параметры интерфейсов, параметры маршрутизаторов и константы.

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

5.1. Номера протокола и портов

Этот протокол задает сообщения TC, которые включаются в пакеты, определенные в [RFC5444]. Эти пакеты должны использовать номер протокола manet или общеизвестный номер порта UDP manet, заданный в спецификации [RFC5498].

Оба типа сообщений TC и HELLO [RFC6130] должны в данной сети MANET использовать протокол IP или UDP для того, чтобы сообщения обоих протоколов можно было помещать в один пакет [RFC5444] для передачи.

5.2. Групповой адрес

Данный протокол задает сообщения TC, которые включаются в пакеты, определенные в [RFC5444]. Эти пакеты могут передаваться с использованием локального для соединения (Link-Local) группового адреса LL-MANET-Routers, как указано в [RFC5498].

5.3. Параметр интерфейса

Задан один дополнительный параметр интерфейса, используемый только для интерфейсов OLSRv2.

5.3.1. Срок корректности полученного сообщения

Описанный ниже параметр определяет срок достоверности записанной информации из принятого сообщения.

RX_HOLD_TIME

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

Параметр имеет показанные ниже ограничения.

• RX_HOLD_TIME > 0;

• значение RX_HOLD_TIME SHOULD следует задавать больше максимальной разницы времени прохождения сообщениями сети MANET с учетом вариаций при пересылке сообщения, времени в пути, задержек в очередях и при обработке.

5.4. Параметры маршрутизатора

Ниже описаны параметры, задаваемые для маршрутизаторов.

5.4.1. Время сохранения изменившейся локальной информации

Приведенный ниже параметр определяет время, в течение которого сохраняется локальная информация.

O_HOLD_TIME

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

Параметр имеет показанное ниже ограничение.

O_HOLD_TIME > 0

5.4.2. Параметр метрики каналов

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

5.4.3. Интервалы между сообщениями

Здесь описаны параметры, регулирующие передачу маршрутизаторами сообщений TC. Такие сообщения обычно передаются периодически, но могут отправляться также в ответ на изменение в маршрутизаторе конфигурации Neighbor Set и/или Local Attached Network Set. В сильно динамичных сетях при большом значении TC_INTERVAL и малом значении TC_MIN_INTERVAL вызванные изменениями сообщения TC могут передаваться чаще периодических. Однако, по причине отсутствия у маршрутизатора сведений, например, о подключающихся к сети удаленных (более, чем на 2 интервала) маршрутизаторов, недопустимо ограничиваться передачей лишь вызванных событиями сообщений TC.

TC_INTERVAL

Максимальный интервал между двумя последовательными сообщениями TC от этого маршрутизатора. Когда сообщения TC не передаются в ответ на локальные изменения (в силу особенностей протокола или отсутствия локальных изменений в сети), сообщения TC должны отправляться регулярно с интервалом TC_INTERVAL, который может меняться за счет вариаций, как описано в [RFC5148].

TC_MIN_INTERVAL

Минимальный интервал между двумя последовательными сообщениями TC от этого маршрутизатора (этот интервал может меняться за счет вариаций, как описано в [RFC5148]).

Для параметров установлен ряд ограничений:

• TC_INTERVAL > 0;

• 0 <= TC_MIN_INTERVAL <= TC_INTERVAL;

• если TLV с Type = INTERVAL_TIME (как определено в [RFC5497]) включаются в сообщения TC, значение TC_INTERVAL должно быть представимо в экспоненциальной форме, как описано в разделе 5 [RFC5497].

5.4.4. Анонсированные интервалы достоверности информации

Приведенные ниже параметры определяют время достоверности информации в сообщениях TC.

T_HOLD_TIME

Используется в качестве минимального значения в TLV с Type = VALIDITY_TIME, включаемых во все сообщения TC, которые передает данный маршрутизатор. Если используется одно значение параметра TC_HOP_LIMIT (см. параграф 5.4.7), в данном TLV будет только одно значение.

A_HOLD_TIME

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

Для параметров установлен ряд ограничений:

• T_HOLD_TIME > 0;

• A_HOLD_TIME >= 0;

• T_HOLD_TIME >= TC_INTERVAL;

• если сообщения TC могут теряться, значения T_HOLD_TIME и A_HOLD_TIME следует делать существенно больше TC_INTERVAL; рекомендуется использовать коэффициент не менее 3;

• значение T_HOLD_TIME должно быть представимо в экспоненциальной форме, как описано в разделе 5 [RFC5497].

5.4.5. Обработка и пересылка времени достоверности

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

P_HOLD_TIME

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

F_HOLD_TIME

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

Для параметров установлен ряд ограничений:

• P_HOLD_TIME > 0

• F_HOLD_TIME > 0

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

5.4.6. Вариации задержек

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

TP_MAXJITTER

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

TT_MAXJITTER

Представляет значение MAXJITTER, используемое в [RFC5148] для вызываемых событиями сообщений TC от этого маршрутизатора.

F_MAXJITTER

Представляет принятое по умолчанию значение MAXJITTER, используемое в [RFC5148] для пересылаемых этим маршрутизатором сообщений. Отметим, что до начала использования F_MAXJITTER маршрутизатор может предпринять попытку вывести более подходящее значение MAXJITTER (например, на основе TLV с Type = INTERVAL_TIME или Type = VALIDITY_TIME в сообщении, которое будет пересылаться).

Ограничения для этих параметров рассмотрены в [RFC5148].

5.4.7. Ограничение числа интервалов

Параметр TC_HOP_LIMIT задает предел числа интервалов пересылки, устанавливаемый в каждом сообщении TC. TC_HOP_LIMIT может использовать одно фиксированное значение, а может раздельно устанавливаться в каждом сообщении TC даже от одного маршрутизатора. Однако каждый из других маршрутизаторов на любом удалении должен видеть регулярную картину сообщений TC для того, чтобы осмысленные значения TLV с Type = INTERVAL_TIME и Type = VALIDITY_TIME на каждом удалении могли включаться в сообщения в соответствии с [RFC5497]. Для этого должна использоваться определенная картина TC_HOP_LIMIT. Например, повторяющаяся последовательность (255 4 4) удовлетворяет этому требованию (период TC_INTERVAL для числа интервалов до 4, включительно, и 3 x TC_INTERVAL при числе интервалов более 4), а (255 255 4 4) не удовлетворяет, поскольку при числе интервалов пересылки более 4 интервалы между сообщениями будут принимать чередующиеся значения TC_INTERVAL и 3 x TC_INTERVAL.

Для параметра установлен ряд ограничений:

• максимальное значение TC_HOP_LIMIT не меньше диаметра сети в числе интервалов пересылки (hop0; рекомендуется значение 255; отметим, что при использовании упомянутой выше картины разных значений TC_HOP_LIMIT ограничивается только наибольшее значение в последовательности;

• во всех случаях TC_HOP_LIMIT >= 2.

5.4.8. Готовность

Каждый маршрутизатор имеет два параметра готовности WILL_FLOODING и WILL_ROUTING, каждый из которых должен принимать значение из диапазона от WILL_NEVER до WILL_ALWAYS, включительно.

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

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

Во всех случаях большее значение параметра указывает на более высокую готовность маршрутизатора выступать в роли рассылающего или маршрутизирующего MPR. Если значение параметра готовности маршрутизатора составляет WILL_NEVER (минимально возможное), он не выполняет соответствующей задачи. Использующая этот протокол сеть MANET со слишком большим числом маршрутизаторов, для которых параметры WILL_FLOODING или WILL_ROUTING имеют значения WILL_NEVER, просто не будет работать — должны быть приняты административные или иные меры для предотвращения таких ситуаций.

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

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

В сетях MANET, где все маршрутизаторы имеют WILL_FLOODING = WILL_ALWAYS, ограничение лавинной рассылки будет по сути дела отключено и лавинная рассылка будет выполняться «вслепую».

В сетях MANET, где все маршрутизаторы имеют WILL_ROUTING = WILL_ALWAYS, упрощение топологии (topology reduction) будет по сути дела отключено и все маршрутизаторы будут анонсировать все свои соединения в сообщениях TC.

Маршрутизатор c WILL_ROUTING = WILL_NEVER не будет выполнять функций промежуточного маршрутизатора в сети MANET. Такой маршрутизатор может быть лишь источником, получателем или шлюзом в другой домен маршрутизации.

Разные маршрутизаторы могут иметь различные значения WILL_FLOODING и/или WILL_ROUTING.

Для параметров установлен ряд ограничений:

WILL_NEVER <= WILL_FLOODING <= WILL_ALWAYS
WILL_NEVER <= WILL_ROUTING <= WILL_ALWAYS

5.5. Ограничения на смену параметров

Если параметры протокола изменяются динамически, эти изменения будут ограничены описанными ниже параметрами.

RX_HOLD_TIME

Если изменяется значение RX_HOLD_TIME для интерфейса OLSRv2, срок действия всех списков Received Tuple для этого интерфейса OLSRv2 может быть изменен.

O_HOLD_TIME

Если изменяется значение O_HOLD_TIME, срок действия всех списков Originator Tuple может быть изменен.

TC_INTERVAL

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

Если значение TC_INTERVAL уменьшается, последующие сообщение TC от этого маршрутизатора должны генерироваться в соответствии с текущим (уменьшенным) значением TC_INTERVAL.

P_HOLD_TIME

Если изменяется значение P_HOLD_TIME, срок действия всех списков Processed Tuple может быть изменен.

F_HOLD_TIME

Если изменяется значение F_HOLD_TIME, срок действия всех списков Forwarded Tuple может быть изменен.

TP_MAXJITTER

Если изменяется значение TP_MAXJITTER, планирование периодических сообщений TC на данном маршрутизаторе может быть изменено незамедлительно.

TT_MAXJITTER

Если изменяется значение TT_MAXJITTER, вызываемые внешними событиями сообщения TC на данном маршрутизаторе могут быть перепланированы.

F_MAXJITTER

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

TC_HOP_LIMIT

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

LINK_METRIC_TYPE

Если изменяется значение LINK_METRIC_TYPE, все метрические данные каналов, записанные этим маршрутизатором, становятся неприменимыми. Маршрутизатор должен выполнить перечисленные ниже действия и последующие операции, описанные в разделе 17 и [RFC6130].

• Для каждого Link Tuple во всех Link Set для данного интерфейса OLSRv2 требуется обновить L_in_metric (может использоваться значение MAXIMUM_METRIC) или удалить Link Tuple из Link Set.
• Для каждого списка Link Tuple, который не будет удален, нужно установить:

  • L_out_metric := UNKNOWN_METRIC;

  • L_SYM_time := EXPIRED;

  • L_MPR_selector := false.

• Удалить все списки Router Topology Tuple, Routable Address Topology Tuple, Attached Network Tuple и Routing Tuple из соответствующих конфигураций Protocol Set в Topology Information Base.

5.6. Константы

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

5.6.1. Константы метрики каналов

Константы для минимального и максимального значений метрики каналов определяются, как:

     MINIMUM_METRIC := 1
     MAXIMUM_METRIC := 16776960

Символическое значение UNKNOWN_METRIC определено в параграфе 6.1.

5.6.2. Константы готовности

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

     WILL_NEVER := 0
     WILL_DEFAULT := 7
     WILL_ALWAYS := 15

5.6.3. Временная константа

Константа C (единица отсчета времени) используется в соответствии с [RFC5497]. Она должна совпадать с используемой в [RFC6130], рекомендуемое значение составляет (в секундах):

     C := 1/1024

Отметим, что эта константа используется для представления временных интервалов. Значения времени (например, в списках Protocol Tuple) представляются иначе. Уровня разрешения C достаточно (но не требуется) для таких значений.

6. Значения метрики каналов

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

6.1. Представление метрики канала

Метрика каналов передается в сообщениях с использованием сжатого представления в форме 12-битового поля, состоящего из 4-битовой и 8-компонент. Сжатая форма обеспечивает представление положительных целых чисел с минимальным значением 1 и максимальным значением, которое несколько меньше максимального 24-битового числа в обычном представлении. Для метрики применяются лишь те значения, которые имеют точно представление в сжатой форме. Метрика маршрута определяется суммой (не более 256) значений канальной метрики и, следовательно, представляется с использованием не более 32битов.

Метрика каналов и маршрутов, используемая в информационных базах, которые определены в данной спецификации, основана на несжатых значениях и арифметические операции со значениями метрики также выполняются с несжатыми значениями и полной точностью результата. Запись значений метрики определяется реализацией и не входит в данную спецификацию, равно как и поведение реализации при записи несжатых значений. Например, реализация может использовать 32-битовые значения для метрики каналов и маршрутов.

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

6.2. Сжатая форма метрики канала

Сжатая 12-битовая форма представления метрики каналов использует модифицированный формат представления с 8-битовой мантиссой (обозначена a) и 4-битовым показателем степени (обозначена b). Отметим, что для представления в виде 12-битового значения 256b+a будет сохраняться такой же порядок значений, как для сжатого представления.

Значение метрики определяется, как (257+a)2^b — 256, где ^ означает возведение в степень. Минимальное значение (при a = 0 и b = 0) составит MINIMUM_METRIC = 1, а максимальное (a = 255 и b = 15) — MAXIMUM_METRIC = 2^24 — 256.

Алгоритм расчета значений a и b для представления наименьшего значения, которое не меньше реального значения канальной метрики v (MINIMUM_METRIC <= v <= MAXIMUM_METRIC) имеет вид:

1. найти наименьшее целое число b, для которого выполняется условие v + 256 <= 2^(b + 9);

2. установить a := (v — 256(2^b — 1)) / (2^b) — 1 с округлением до ближайшего целого числа.

7. Локальная информационная база

База Local Information Base, определенная для каждого маршрутизатора в [RFC6130], расширяется данным протоколом.

• Запись адреса инициатора для маршрутизатора. Адрес инициатора должен быть уникальным для данного маршрутизатора и его недопустимо использовать в качестве адреса инициатора для любого другого маршрутизатора. Этот адрес может входить в адресный блок любой сети из любого I_local_iface_addr_list в данном маршрутизаторе; недопустимо использование адреса из любого адреса сети в любом I_local_iface_addr_list любого другого маршрутизатора. Адрес инициатора может входить в AL_net_addr в любом списке Local Attached Network Tuple этого или любого другого маршрутизатора, но точное совпадение недопустимо.

• Добавлены конфигурация Originator Set, определенная в параграфе 7.1, и Local Attached Network Set, определенная в параграфе 7.2.

Все маршрутизируемые адреса, для адреса которых маршрутизатор воспринимает в качестве IP-адреса получателя, должны быть включены в конфигурацию Local Interface Set или Local Attached Network Set.

7.1. Originator Set

Конфигурация Originator Set в маршрутизаторе содержит адреса, которые недавно использовались этим маршрутизатором в качестве адреса инициатора. Если маршрутизатор не меняет адрес инициатора, конфигурация Originator Set всегда будет пустой и может быть опущена. Конфигурация состоит из упорядоченных списков Originator Tuple:

      (O_orig_addr, O_time)

где

O_orig_addr — недавно использованный адрес инициатора (без включения размера префикса);

O_time указывает время завершения срока действия Originator Tuple, после чего этот список должен удаляться.

7.2. Local Attached Network Set

Конфигурация Local Attached Network Set в маршрутизаторе содержит записи о его локальных интерфейсах, не относящихся к OLSRv2, через которые он может выполнять функции шлюза в другие сети. Конфигурация Local Attached Network Set должна обеспечиваться для этого протокола и должна отражать любые изменения в состоянии маршрутизатора (если конфигурация маршрутизатора не изменяется, Local Attached Network Set также сохраняется без изменений, а в случае наличия на маршрутизаторе только интерфейсов OLSRv2 множество Local Attached Network Set может быть пустым). Этот протокол не меняет конфигурации Local Attached Network Set и лишь реагирует на (внешние по отношению к протоколу) изменения в Local Attached Network Set. Конфигурация содержит упорядоченные списки of Local Attached Network Tuple:

      (AL_net_addr, AL_dist, AL_metric)

где

AL_net_addr — адрес сети, подключенной к интерфейсу, которая доступна через данный маршрутизатор; в этом поле следует указывать маршрутизируемый адрес, ограничения рассмотрены ниже;

AL_dist — число интервалов пересылки до сети с адресом AL_net_addr от данного маршрутизатора.

AL_metric — метрика соединения с подключенной через интерфейс сетью с адресом AL_net_addr от данного маршрутизатора.

Сети с локальным подключением только к данному маршрутизатору (т. е., недоступные иными путями), следует трактовать, как локальные интерфейсы не-MANET и добавлять в Local Interface Set, как указано в [RFC6130], а не в Local Attached Network Set.

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

Этот протокол не отвечает за поддержку маршрутов от данного маршрутизатора в сети, указанные в Local Attached Network Set.

Списки Local Attached Network Tuple исключаются из конфигурации Local Attached Network Set только в случае изменения набора локально подключенных к данному маршрутизатору сетей, т. е., срок их жизни не ограничен какими-либо параметрами или информацией из принятых сообщений.

8. База информации об интерфейсах

Interface Information Base, как определено в [RFC6130], поддерживается для каждого интерфейса MANET. Конфигурации Link Set и 2-Hop Set в Interface Information Base для интерфейсов OLSRv2 изменены данным протоколом. В некоторых случаях эти конфигурации удобней рассматривать, как содержащие также эти дополнительные элементы для других интерфейсов MANET, принимая указанные элементы при создании и не меняя их.

8.1. Link Set

Конфигурация Link Set изменена путем добавления приведенных ниже элементов в каждый список Link Tuple.

L_in_metric — метрика канала от интерфейса OLSRv2 с адресом L_neighbor_iface_addr_list до данного интерфейса OLSRv2;

L_out_metric — метрика канала к интерфейсу OLSRv2 с адресом L_neighbor_iface_addr_list от данного интерфейса OLSRv2;

L_mpr_selector — флаг, указывающий выбран ли этот сосед данным маршрутизатором в качестве рассылающего MPR (т. е., данный маршрутизатор является для того селектором flooding MPR).

L_in_metric будет задаваться процессом, который по отношению к данной спецификации является внешним. Любой список Link Tuple с L_status = HEARD или L_status = SYMMETRIC должен иметь указанное значение L_in_metric, если оно используется данным протоколом.

В списке Link Tuple, определенном в [RFC6130] (до изменения), должно устанавливаться:

     L_in_metric := UNKNOWN_METRIC
     L_out_metric := UNKNOWN_METRIC
     L_mpr_selector := false

8.2. 2-Hop Set

Конфигурация 2-Hop Set изменяется путем добавления перечисленных ниже элементов в каждый список 2-Hop Tuple.

N2_in_metric — метрика соседа от маршрутизатора с адресом N2_2hop_iface_addr до маршрутизатора с интерфейсом OLSRv2, имеющим адрес N2_neighbor_iface_addr_list;

N2_out_metric — метрика соседа к маршрутизатору с адресом N2_2hop_iface_addr от маршрутизатора с интерфейсом OLSRv2, имеющим адрес N2_neighbor_iface_addr_list.

В списке 2-Hop Tuple, определенном в [RFC6130] (до изменения), должно устанавливаться:

     N2_in_metric := UNKNOWN_METRIC
     N2_out_metric := UNKNOWN_METRIC

9. База информации о соседях

База Neighbor Information Base в соответствии с [RFC6130] поддерживается для каждого маршрутизатора. Данный протокол меняет ее путем добавления дополнительных элементов в каждый список Neighbor Tuple конфигурации Neighbor Set. В некоторых случаях эти конфигурации удобней рассматривать, как содержащие также эти дополнительные элементы для других интерфейсов MANET, принимая указанные элементы при создании и не меняя их.

N_orig_addr — соседский адрес инициатора, который может быть не известен (отметим, что этот адрес не включает размер префикса);

N_in_metric — метрика соседа для любого канала от этого соседа к интерфейсу OLSRv2 на данном маршрутизаторе (т. е., минимальное из всех соответствующих значений L_in_metric с L_status = SYMMETRIC и L_in_metric != UNKNOWN_METRIC, UNKNOWN_METRIC, если нет таких Link Tuple);

N_out_metric — метрика соседа для любого канала от интерфейса OLSRv2 данного маршрутизатора к этому соседу (т. е., минимальное из всех соответствующих значений L_out_metric с L_status = SYMMETRIC и L_out_metric != UNKNOWN_METRIC, UNKNOWN_METRIC, если нет таких Link Tuple);

N_will_flooding — готовность соседа быть выбранным в качестве рассылающего MPR в диапазоне от WILL_NEVER до WILL_ALWAYS, включительно, или WILL_NEVER при отсутствии информации OLSRv2 от этого соседа;

N_will_routing — готовность соседа быть выбранным в качестве маршрутизирующего MPR в диапазоне от WILL_NEVER до WILL_ALWAYS, включительно, или WILL_NEVER при отсутствии информации OLSRv2 от этого соседа;

N_flooding_mpr — флаг, показывающий выбран ли данный сосед эти маршрутизатором в качестве рассылающего MPR;

N_routing_mpr — флаг, показывающий выбран ли данный сосед эти маршрутизатором в качестве маршрутизирующего MPR;

N_mpr_selector — флаг, показывающий выбрал ли данный сосед этот маршрутизатор в качестве маршрутизирующего MPR (т. е., является ли сосед селектором routing MPR для данного маршрутизатора);

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

В списке Neighbor Tuple, определенном в [RFC6130] (до изменения), должно устанавливаться:

     N_orig_addr := unknown
     N_in_metric := UNKNOWN_METRIC
     N_out_metric := UNKNOWN_METRIC
     N_will_flooding := WILL_NEVER
     N_will_routing := WILL_NEVER
     N_routing_mpr := false
     N_flooding_mpr := false
     N_mpr_selector := false
     N_advertised := false

Neighbor Information Base включает также переменную ANSN¹², значение которой помещается в сообщения TC для индикации «свежести» передаваемой информации. Значение ANSN инкрементируется при каждом изменении анонсируемой информации (адрес инициатора и маршрутизируемые адреса, включенные в списки Neighbor Tuple с N_advertised = true и адреса локально подключенных сетей в Local Attached Network Set базы Local Information Base), включая добавление или удаление данных.

10. База топологической информации

В Topology Information Base, определяемой данной спецификацией для каждого маршрутизатора, хранится информация из полученных сообщений TC, представленная там в конфигурациях Advertising Remote Router Set, Router Topology Set, Routable Address Topology Set и Attached Network Set.

В дополнение к этому поддерживается конфигурация Routing Set, создаваемая на основе информации из Local Information Base, Interface Information Bases, Neighbor Information Base и остальной части Topology Information Base.

10.1. Advertising Remote Router Set

Конфигурация маршрутизатора Advertising Remote Router Set хранит данные, описывающие каждый удаленный маршрутизатор в сети, который передает сообщения TC, что позволяет распознавать и отбрасывать устаревшие сообщения TC. Конфигурация состоит из упорядоченных списков Advertising Remote Router Tuple

      (AR_orig_addr, AR_seq_number, AR_time)

где

AR_orig_addr — адрес инициатора полученного сообщения TC (этот адрес не включает размер префикса);

AR_seq_number — наибольшее значение номера ANSN во всех сообщениях TC, полученных от маршрутизатора с адресом инициатора AR_orig_addr (т. е., представляющего информацию в данном Tuple);

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

10.2. Router Topology Set

Конфигурация маршрутизатора Topology Set содержит топологические данные о соединениях между маршрутизаторами в сети MANET и состоит из списков Router Topology Tuple

      (TR_from_orig_addr, TR_to_orig_addr, TR_seq_number, TR_metric, TR_time)

где

TR_from_orig_addr — адрес инициатора для маршрутизатора, которому маршрутизатор с адресом инициатора TR_to_orig_addr доступен через один интервал (hop) (этот адрес не включает размер префикса);

TR_to_orig_addr — адрес инициатора для маршрутизатора, который может быть доступен для маршрутизатора с адресом инициатора TR_from_orig_addr через один интервал (этот адрес не включает размер префикса);

TR_seq_number — наибольшее значение номера ANSN во всех сообщениях TC, полученных от маршрутизатора с адресом инициатора TR_from_orig_addr (т. е., представляющего информацию в данном Tuple);

TR_metric — метрика соседа от маршрутизатора с адресом инициатора TR_from_orig_addr для маршрутизатора с адресом инициатора TR_to_orig_addr;

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

10.3. Routable Address Topology Set

Конфигурация маршрутизатора Routable Address Topology Set содержит топологические данные о маршрутизируемых адресах в сети MANET, включая адреса, доступные через другие маршрутизаторы. Конфигурация состоит из упорядоченных списков Routable Address Topology Tuple

      (TA_from_orig_addr, TA_dest_addr, TA_seq_number, TA_metric, TA_time)

где

TA_from_orig_addr — адрес инициатора для маршрутизатора, которому маршрутизатор с адресом инициатора TA_dest_addr доступен через один интервал (этот адрес не включает размер префикса);

TA_dest_addr адрес инициатора для маршрутизатора, который может быть доступен для маршрутизатора с адресом инициатора TA_from_orig_addr через один интервал;

TA_seq_number — наибольшее значение номера ANSN во всех сообщениях TC, полученных от маршрутизатора с адресом инициатора TA_from_orig_addr (т. е., представляющего информацию в данном Tuple);

TA_metric — метрика соседа от маршрутизатора с адресом инициатора TA_from_orig_addr до маршрутизатора с интерфейсом OLSRv2, имеющим адрес TA_dest_addr;

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

10.4. Attached Network Set

Конфигурация маршрутизатора Attached Network Set содержит информацию о сетях (которые могут не входить в MANET), подключенных к другим маршрутизаторам, и маршрутизируемым адресам этих сетей. Конфигурация состоит из упорядоченных списков Attached Network Tuple

      (AN_orig_addr, AN_net_addr, AN_seq_number, AN_dist, AN_metric, AN_time)

где

AN_orig_addr — адрес инициатора для маршрутизатора, который может служить шлюзом в сеть с адресом AN_net_addr (этот адрес не включает размер префикса);

AN_net_addr — адрес подключенной сети, которая может быть доступна через маршрутизатор с адресом инициатора AN_orig_addr;

AN_seq_number — наибольшее значение номера ANSN во всех сообщениях TC, полученных от маршрутизатора с адресом инициатора AN_orig_addr (т. е., представляющего информацию в данном Tuple);

AN_dist — число интервалов пересылки до сети с адресом AN_net_addr от маршрутизатора с адресом инициатора AN_orig_addr;

AN_metric — метрика канала от маршрутизатора с адресом инициатора AN_orig_addr до подключенной сети с адресом AN_net_addr;

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

10.5. Routing Set

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

      (R_dest_addr, R_next_iface_addr, R_local_iface_addr, R_dist, R_metric)

где

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

R_next_iface_addr — адрес сети следующего интервала (next hop) на выбранном пути к получателю;

R_local_iface_addr — адрес локального интерфейса, через пакеты IP должны передаваться для доставки получателю по выбранному пути;

R_dist — число интервалов пересылки (hop) на выбранном пути к получателю;

R_metric — метрика маршрута к получателю с адресом R_dest_addr.

Конфигурация Routing Set для маршрутизатора создается на основе содержимого конфигураций Protocol Sets этого маршрутизатора (множество Link Set, Neighbor Set, Router Topology Set, Routable Address Topology Set, Attached Network Set и, возможно, конфигурации 2-Hop Set). Конфигурация Routing Set обновляется (списки Routing Tuple добавляются и удаляются или Routing Set пересчитывается полностью) при расчете маршрутных путей на основе изменений в других Protocol Set. Действие списков Routing Tuple не ограничивается по времени.

11. База информации о полученных сообщениях

База Received Message Information Base, определяемая данной спецификацией, содержит информацию, которая требуется для того, чтобы сообщения обрабатывались не более одного раза и пересылались не более одного раза не более, чем через один интерфейс OLSRv2 маршрутизатора, обеспечивающего пересылку MPR. Сообщения записываются с помощью «ключей» (signature), содержащих тип сообщения, адрес инициатора и порядковый номер.

11.1. Received Set

Маршрутизатор имеет конфигурацию Received Set для каждого интерфейса OLSRv2. Каждая конфигурация Received Set содержит ключи сообщений, полученных через данный интерфейс OLSRv2. Каждая конфигурация состоит из упорядоченных списков Received Tuple

      (RX_type, RX_orig_addr, RX_seq_number, RX_time)

где

RX_type — тип полученного сообщения (Message Type);

RX_orig_addr — адрес инициатора полученного сообщения (этот адрес не включает размер префикса);

RX_seq_number — порядковый номер полученного сообщения;

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

11.2. Processed Set

Маршрутизатор имеет одну конфигурацию Processed Set, в которой содержатся ключи обработанных маршрутизатором сообщений. Конфигурация состоит из упорядоченных списков Processed Tuple

      (P_type, P_orig_addr, P_seq_number, P_time)

где

P_type — тип полученного сообщения (Message Type);

P_orig_addr — адрес инициатора полученного сообщения (этот адрес не включает размер префикса);

P_seq_number — порядковый номер полученного сообщения;

P_time specifies задает время окончания срока действия данного Tuple, после чего список должен удаляться.

11.3. Forwarded Set

Маршрутизатор имеет одну конфигурацию Forwarded Set, в которой содержатся ключи пересланных маршрутизатором сообщений. Конфигурация состоит из упорядоченных списков Forwarded Tuple

      (F_type, F_orig_addr, F_seq_number, F_time)

где

F_type — тип полученного сообщения (Message Type);

F_orig_addr — адрес инициатора полученного сообщения (этот адрес не включает размер префикса);

F_seq_number — порядковый номер полученного сообщения;

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

12. Свойства информационных баз

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

12.1. Соответствие списков Protocol Tuple

Как часть спецификации во многих случаях возникает естественное соответствие списка Protocol Tuple в одной конфигурации Protocol Set списку Protocol Tuple в другой конфигурации Protocol Set той же или иной информационной базы. В таких случаях второй список Protocol Tuple называется «соответствующим» первому списку Protocol Tuple.

Конкретные примеры соответствующих списков Protocol Tuple перечислены ниже.

• Список Local Interface Tuple, соответствующий каждому Link Tuple, где Link Tuple является частью конфигурации Link Set для интерфейса MANET, а Local Interface Tuple представляет этот интерфейс MANET.

• Список Neighbor Tuple, соответствующий каждому списку Link Tuple, для которого время L_HEARD_time не истекло, так, что N_neighbor_addr_list содержит L_neighbor_iface_addr_list.

• Список Link Tuple (в конфигурации Link Set той же базы Interface Information Base), соответствующий каждому списку 2-Hop Tuple, так, что L_neighbor_iface_addr_list = N2_neighbor_iface_addr_list.

• Список Neighbor Tuple, соответствующий каждому списку 2-Hop Tuple, так, что N_neighbor_addr_list содержит N2_neighbor_iface_addr_list (имеется список Neighbor Tuple, соответствующий списку Link Tuple, который соответствует списку 2-Hop Tuple).

• Список Advertising Remote Router Tuple, соответствующий каждому списку Router Topology Tuple, так, что AR_orig_addr = TR_from_orig_addr.

• Список Advertising Remote Router Tuple, соответствующий каждому списку Routable Address Topology Tuple, так, что AR_orig_addr = TA_from_orig_addr.

• Список Advertising Remote Router Tuple, соответствующий каждому списку Attached Network Tuple, так, что AR_orig_addr = AN_orig_addr.

• Список Neighbor Tuple, соответствующий каждому списку Routing Tuple, так, что N_neighbor_addr_list содержит R_next_iface_addr.

12.2. Принадлежность адресов

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

• Совпадающие с его адресом инициатора;

• совпадающие с O_orig_addr в списке Originator Tuple;

• совпадающие или являющиеся подмножеством I_local_iface_addr_list в списке Local Interface Tuple;

• совпадающие или являющиеся подмножеством IR_local_iface_addr в списке Removed Interface Address Tuple;

• совпадающие с AL_net_addr в списке Local Attached Network Tuple.

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

• Перекрывающие (совпадение или надмножество) его адрес инициатора;

• перекрывающие (совпадение или надмножество) O_orig_addr в списке Originator Tuple;

• перекрывающие I_local_iface_addr_list в списке Local Interface Tuple;

• перекрывающие IR_local_iface_addr в списке Removed Interface Address Tuple;

• совпадающие или включающие AL_net_addr в списке Local Attached Network Tuple.

13. Пакеты и сообщения

Формат используемых этим протоколом пакетов и сообщений определен в [RFC5444]. Если не указано иное, опции, определенные в [RFC5444] также могут использоваться, включая дополнительные форматы, определенные для пакетов, сообщений, Address Block и флагов TLV.

В этом параграфе описано использование данной спецификацией пакетов и сообщений, определенных в [RFC5444], а также определенных здесь TLV.

13.1. Сообщения

Использующие этот протокол маршрутизаторы обмениваются информацией через сообщения. Протокол использует сообщения типов HELLO и TC. Сообщения HELLO определены в [RFC6130] и расширены данной спецификацией (см. раздел 15). Сообщения TC определяются данной спецификацией (см. раздел 16).

13.2. Пакеты

Одно или множество одновременно передаваемых маршрутизатором сообщений следует объединять в один пакет, для которого могут действовать ограничения на размер (например, в соответствии со значением MTU на локальном интерфейсе). Это могут быть сообщения от самого маршрутизатора или сообщения других маршрутизатор, которые он пересылает. Сообщения от разных инициаторов можно объединять в одном пакете. Сообщения других протоколов, использующие форматы [RFC5444], включая (но не ограничиваясь) протокол NHDP [RFC6130], также могут комбинироваться для передачи в одном пакете. Данная спецификация не определяет и не использует содержимого заголовка пакетов (Packet Header).

Для пересылаемых сообщений могут добавляться вариации, описанные в [RFC5148], с учетом того, что вариации для всех сообщений, принятых в одном пакете, следует делать одинаковыми. Значение MAXJITTER, используемые при задании вариаций для пересылки сообщений, может основываться на информации из данного сообщения (в частности, всех Message TLV с Type = INTERVAL_TIME или Type = VALIDITY_TIME), в остальных случаях следует использовать максимальную задержку F_MAXJITTER. Маршрутизатор может изменять вариации для сообщений с целью более эффективного объединения сообщений в пакет при условии того, что значение вариации не превысит разрешенный максимум.

13.3. TLV

Данная спецификация определяет два Message TLV и четыре Address Block TLV.

Во всех упоминаниях TLV в данной спецификации, где не указан тип расширения, предполагается Type Extension = 0. TLV в обрабатываемых сообщениях с типом расширения, отличным от указанного нулевого значения и 0, игнорируются.

Отметим, что в соответствии с [RFC5444] и сетевым порядком байтов, биты октетов нумеруются от 0 (старший) до 7 (младший).

13.3.1. Message TLV

MPR_WILLING TLV используется в сообщениях HELLO. В сообщение недопустимо включать более одного MPR_WILLING TLV.

Таблица 1. Определение MPR_WILLING TLV.

 

Тип	Размер	Значение
MPR_WILLING	1 октет	Биты 0-3 представляют параметр WILL_FLOODING, биты 4-7 — WILL_ROUTING.

 

CONT_SEQ_NUM TLV используются в сообщениях TC. В сообщение недопустимо включать более одного CONT_SEQ_NUM TLV.

Таблица 2. Определение CONT_SEQ_NUM TLV.

Тип	Размер	Значение
CONT_SEQ_NUM	2 октета	Порядковый номер ANSN из Neighbor Information Base.

13.3.2. Address Block TLV

LINK_METRIC TLV применяются в сообщениях HELLO и TC и могут использовать любые расширения типов. Данная спецификация использует LINK_METRIC TLV только с расширением LINK_METRIC_TYPE. Адрес недопустимо связывать более, чем с одним значением метрики канала для любого конкретного расширения типа, вида (канал или сосед) или направления при использовании этого TLV.

Таблица 3. Определение LINK_METRIC TLV.

Тип	Размер	Значение
LINK_METRIC	2 октета	Биты 0-3 указывают вид и направление; биты 4-7 — показатель степени (b), а биты 8-15 — мантиссу (a) значения метрики.

Для показателя степени и мантиссы используется формат представления, описанный в разделе 6. Биты в вида и направления могут присутствовать в любой комбинации, их трактовка указана в таблице 4.

Таблица 4. Типы и направления LINK_METRIC TLV.

 

Бит	Тип	Направление
0	Метрика канала	Входящее
1	Метрика канала	Исходящее
2	Метрика соседа	Входящее
3	Метрика соседа	Исходящее

 

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

Таблица 5. Определение MPR TLV.

Тип	Размер	Значение
MPR	1 октет	FLOODING указывает, что соответствующий адрес принадлежит соседу, выбранному в качестве рассылающего MPR, ROUTING указывает, что адрес принадлежит соседу, выбранному в качестве маршрутизирующего MPR, FLOOD_ROUTE указывает, что адрес принадлежит соседу, выбранному в качестве маршрутизирующего и рассылающего MPR (см. параграф 24.6).

NBR_ADDR_TYPE TLV используются в сообщениях TC.

Таблица 6. Определение NBR_ADDR_TYPE TLV.

Тип	Размер	Значение
NBR_ADDR_TYPE	1 октет	ORIGINATOR указывает, что соответствующий адрес (которых должен иметь максимальный размер префикса) является адресом инициатора, ROUTABLE указывает, что соответствующий адрес сети является маршрутизируемым, ROUTABLE_ORIG указывает на то, что адрес является маршрутизируемым адресом инициатора ( см. параграф 24.6).

Если адрес принадлежит инициатору и является маршрутизируемым, он может быть связан с одним Address Block TLV с Type := NBR_ADDR_TYPE и Value := ROUTABLE_ORIG или двумя Address Block TLV с Type:= NBR_ADDR_TYPE, и Value := ORIGINATOR для одного и Value := ROUTABLE для другого.

GATEWAY TLV используются в сообщениях TC. Адрес недопустимо связывать более, чем с одним значением счетчика интервалов, используемым в этом TLV.

Таблица 7. Определение GATEWAY TLV.

Тип	Размер	Значение
GATEWAY	1 октет	Число интервалов пересылки (hop) до подключенной сети.

Все адресные объекты, включаемые в сообщения TC в соответствии с данной спецификацией, должны связываться хотя бы с одним TLV с Type := NBR_ADDR_TYPE или TLV с Type := GATEWAY, но не с обоими сразу. В Address Block сообщений TC могут включаться любые адресные объекты, но данная спецификация будет игнорировать их.

14. Обработка и пересылка сообщений

В этом разделе описаны операции оптимизированной лавинной рассылки (MPR flooding), используемой в тех случаях, когда управляющие сообщения, как экземпляры [RFC5444], предназначены для рассылки в масштабе всей сети MANET. Этот механизм рассылки определяет, когда принятое сообщение должно (или не должно) обрабатываться и пересылаться.

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

Этот механизм рассылки всегда применяется для сообщений TC (см. раздел 16). Полученные сообщения HELLO (см. раздел 15) всегда обрабатываются (если они корректны) и никогда не пересылаются с использованием данного механизма. По этой причине такие сообщения не требуется записывать в базу Received Message Information Base.

Механизмы выбора обработки и пересылки устроены так, что требуется разбирать лишь Message Header для того, чтобы определить потребность в обработке и/или пересылке сообщения и не нужно разбирать Message Body для пересылаемых без обработки сообщений. Реализация может разбирать Message Body только при необходимости, а может разбирать тело сообщения и отвергать сообщения, которые содержат ошибки или не понятны.

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

14.1. Действия при получении сообщения

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

1. Если маршрутизатор по адресу инициатора в сообщении определяет что сообщение относится к числу порожденных этим маршрутизатором сообщений (т. е., адрес инициатора в сообщении является адресом инициатора для данного маршрутизатора или указан в поле O_orig_addr списка Originator Tuple), сообщение должно быть отброшено без уведомления.

2. В остальных случаях:

   1. Если тип сообщение относится к числу обрабатываемых, рассматривается вопрос обработки этого сообщения в соответствии с параграфом 14.2.

   2. Если данный тип сообщений может пересылаться и выполняются условия:

• • • <msg-hop-limit> > 1;

    • <msg-hop-count> отсутствует или < 255,

рассматривается вопрос о пересылке сообщения в соответствии с параграфом 14.3.

14.2. Рассмотрение вопроса обработки сообщения

Если (текущее) сообщение рассматривается для обработки, должны быть выполнены перечисленные ниже операции.

1. Если адрес отправителя (адрес в заголовке дейтаграммы IP, содержащей текущее сообщение) не соответствует (с учетом размера префикса) адресу сети в поле L_neighbor_iface_addr_list списка Link Tuple с L_status = SYMMETRIC в конфигурации Link Set для интерфейса OLSRv2, принявшего (полученное) сообщение, обработка такого сообщения является необязательной. Если обработка текущего сообщения не будет производиться, последующие операции не выполняются.

2. Если имеется Processed Tuple, для которого выполняются все приведенные ниже условия:

• • • P_type = Message Type текущего сообщения;

    • P_orig_addr = адрес инициатора текущего сообщения;

    • P_seq_number = порядковый номер текущего сообщения,

обработка текущего сообщения недопустима.

3. В остальных случаях

   1. создается Processed Tuple в Processed Set со значениями

• • P_type := Message Type текущего сообщения;

  • P_orig_addr := адрес инициатора текущего сообщения;

  • P_seq_number := порядковый номер текущего сообщения;

  • P_time := текущее время + P_HOLD_TIME;

1. 2. выполняется обработка текущего сообщения в соответствии с Message Type.

      Для сообщений TC обработка описана в параграфе 16.3.

14.3. Рассмотрение вопроса пересылки сообщения

Если (текущее) сообщение рассматривается для пересылки, должны быть выполнены перечисленные ниже операции.

1. Если адрес отправителя (адрес в заголовке дейтаграммы IP, содержащей текущее сообщение) не соответствует (с учетом размера префикса) адресу сети в поле L_neighbor_iface_addr_list списка Link Tuple с L_status = SYMMETRIC в конфигурации Link Set для интерфейса OLSRv2, принявшего (полученное) сообщение, такое сообщение должно отбрасываться без уведомления.

2. В остальных случаях

   1. если имеется Received Tuple в конфигурации Received Set для принявшего сообщение интерфейса и выполняются все перечисленные ниже условия:

• • • RX_type = Message Type текущего сообщения;

    • RX_orig_addr = адрес инициатора текущего сообщения;

    • RX_seq_number = порядковый номер текущего сообщения,

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

1. 1. В остальных случаях

      1. Создается список Received Tuple в конфигурации Received Set для принявшего сообщение интерфейса со значениями:

• • RX_type := Message Type текущего сообщения;

  • RX_orig_addr := адрес инициатора текущего сообщения;

  • RX_seq_number := порядковый номер текущего сообщения;

  • RX_time := текущее время + RX_HOLD_TIME.

1. 1. 1. Если имеется список Forwarded Tuple для которого выполняются все приведенные ниже условия:

• • • F_type = Message Type текущего сообщения;

    • F_orig_addr = адрес инициатора текущего сообщения;

    • F_seq_number = порядковый номер текущего сообщения,

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

1. 1. 1. В остальных случаях, если адрес отправитель (с учетом любого префикса) соответствует любому адресу сети в поле L_neighbor_iface_addr_list списка Link Tuple в конфигурации Link Set для принявшего сообщение интерфейса OLSRv2, который имеет L_status = SYMMETRIC и L_mpr_selector = true:

         1. создается список Forwarded Tuple в конфигурации Forwarded Set со значениями:

• • F_type := Message Type текущего сообщения;

  • F_orig_addr := адрес инициатора текущего сообщения;

  • F_seq_number := порядковый номер текущего сообщения;

  • F_time := текущее время + F_HOLD_TIME;

1. 1. 1. 1. Message Header текущего сообщения изменяется, как показано ниже:

• • значение <msg-hop-limit> в Message Header уменьшается на 1;

  • при наличии <msg-hop-count> в Message Header это поле увеличивается на 1;

1. 1. 1. 1. сообщение передается через все интерфейсы OLSRv2, как описано в разделе 13.

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

15. Сообщения HELLO

Тип сообщений HELLO принадлежит протоколу NHDP [RFC6130] и эти сообщения, таким образом, генерируются, передаются, принимаются и обрабатываются протоколом NHDP. Данный протокол, в соответствии с [RFC6130], тоже использует сообщения HELLO, включая их генерацию и реализацию дополнительной обработки на основе полученных сообщений HELLO. Сообщения HELLO не пересылаются с помощью NHDP [RFC6130] или OLSRv2.

15.1. Генерация сообщения HELLO

Сообщения HELLO, передаваемые через интерфейсы OLSRv2, генерируются в соответствии с [RFC6130] и после этого изменяются, как описано в этом параграфе. Сообщения HELLO, передаваемые через другие интерфейсы MANET, данная спецификация не меняет.

В сообщения HELLO, передаваемые через интерфейсы OLSRv2, добавляются описанные ниже элементы.

• Адрес инициатора сообщения, в качестве которого используется адрес инициатора на маршрутизаторе. Если не выполняется ни одного из перечисленных ниже условий, должен использоваться элемент <msg-orig-addr>:

  • если сообщение указывает единственный адресный элемент (т. е., содержит лишь один адресный объект, который связан с Address Block TLV с Type = LOCAL_IF и не имеет размера префикса или использует максимальный размер), этот элемент используется в качестве адреса инициатора сообщения;

  • если сообщение не включает ни одного адреса сетей на локальных интерфейсах (т. е., не имеет адресных объектов, которые связаны с Address Block TLV с Type = LOCAL_IF), как указано в спецификации [RFC6130], маршрутизатор, генерирующий данное сообщение HELLO, имеет только один адрес интерфейса и будет использовать его в качестве адреса отправителя дейтаграммы IP, в которой содержится сообщение HELLO — этот адрес будет использоваться и в качестве адреса инициатора сообщения.

• Должно включаться Message TLV с Type := MPR_WILLING.

• В приведенных ниже случаях Address Block TLV связываются с одним или множеством списков Link Tuple или Neighbor Tuple, если такие списки включены в сообщение HELLO. В каждом случае TLV должен связываться хотя бы с одним адресным объектом для адреса из подходящего Tuple; TLV может связываться со множеством таких адресов (включая копии данного адресного объекта, сами по себе возможно не связанные ни с какими другими из указанных TLV в том же или другом Address Block). Эти дополнительные TLV недопустимо связывать с какими-либо иными адресами в сообщении HELLO, которые будут обрабатываться протоколом NHDP [RFC6130].

  • Для каждого списка Link Tuple с L_in_metric != UNKNOWN_METRIC, в котором один или множество адресов в его L_neighbor_iface_addr_list включены в качестве адресных объектов со связанными Address Block TLV с Type = LINK_STATUS и Value = HEARD или Value = SYMMETRIC, хотя бы один из таких адресов должен быть связан с Address Block TLV с Type := LINK_METRIC, указывающим метрику входного канала со значением L_in_metric.

  • Для каждого списка Link Tuple с L_in_metric != UNKNOWN_METRIC, в котором один или множество адресов в его L_neighbor_iface_addr_list включены в качестве адресных объектов со связанными Address Block TLV с Type = LINK_STATUS и Value = SYMMETRIC, хотя бы один из таких адресов должен быть связан с Address Block TLV с Type := LINK_METRIC, указывающим метрику выходного канала со значением L_out_metric.

  • Для каждого списка Neighbor Tuple с N_symmetric = true, в котором один или множество адресов в его N_neighbor_addr_list включены в качестве адресных объектов со связанными Address Block TLV с Type = LINK_STATUS или Type = OTHER_NEIGHB и Value = SYMMETRIC, хотя бы один из таких адресов должен быть связан с Address Block TLV с Type := LINK_METRIC, указывающим входную метрику соседа со значением N_in_metric.

  • Для каждого списка Neighbor Tuple с N_symmetric = true, в котором один или множество адресов в его N_neighbor_addr_list включены в качестве адресных объектов со связанными Address Block TLV с Type = LINK_STATUS или Type = OTHER_NEIGHB и Value = SYMMETRIC, хотя бы один из таких адресов должен быть связан с Address Block TLV с Type := LINK_METRIC, указывающим выходную метрику соседа со значением N_out_metric.

  • Для каждого списка Neighbor Tuple с N_flooding_mpr = true, в котором один или множество адресов в его N_neighbor_addr_list включены в качестве адресных объектов в сообщение HELLO со связанным Address Block TLV с Type = LINK_STATUS и Value = SYMMETRIC, хотя бы один из таких адресов должен быть связан с Address Block TLV с Type := MPR и Value := FLOODING или Value := FLOOD_ROUTE.

  • Для каждого списка Neighbor Tuple с N_routing_mpr = true, в котором один или множество адресов в его N_neighbor_addr_list включены в качестве адресных объектов в сообщение HELLO со связанным Address Block TLV с Type = LINK_STATUS и Value = SYMMETRIC, хотя бы один из таких адресов должен быть связан с Address Block TLV с Type := MPR и Value := ROUTING или Value := FLOOD_ROUTE.

15.2. Передача сообщения HELLO

Сообщения HELLO планируются и передаются протоколом NHDP [RFC6130]. Этот протокол может требовать передачи дополнительного сообщения HELLO на каждом интерфейсе OLSRv2 при любом изменении множества MPR в маршрутизаторе в дополнение к случаям, указанным в [RFC6130]. В этом случае применяются ограничения, заданные в [RFC6130] (в частности, для минимальных интервалов передачи сообщений HELLO).

15.3. Обработка сообщения HELLO

При получении интерфейсом OLSRv2 сообщения HELLO это сообщение становится доступным данному протоколу одним из двух способов, разрешенных [RFC6130]:

• принятое сообщение HELLO должно быть сделано доступным этому протоколу при получении, что позволяет отбросить его до обработки протоколом NHDP [RFC6130] (например, если добавленная данной спецификацией в сообщение HELLO информация противоречива);

• принятое сообщение HELLO должно быть сделано доступным OLSRv2 для обработки после того, как NHDP [RFC6130] завершит его обработку, если оно не отброшено NHDP, как некорректно сформированное.

15.3.1. Отбрасывание сообщений HELLO

В дополнение к указанным в [RFC6130] причинам отбрасывания полученных сообщений HELLO отбрасываться должны также перечисленные ниже сообщения HELLO, полученные на интерфейсе OLSRv2, до их обработки NHDP [RFC6130] или данным протоколом.

• В сообщении имеется более одного Message TLV с Type = MPR_WILLING;

• в сообщении имеется адрес его инициатора или адрес сети, соответствующие адресному объекту, связанному с Address Block TLV с Type = LOCAL_IF, т. е., частично принадлежащие данному маршрутизатору (некоторые из таких сообщений уже отбрасываются в соответствии с [RFC6130]);

• сообщение включает какой-либо адресный объект, связанный с Address Block TLV с Type = LINK_STATUS или Type = OTHER_NEIGHB, перекрывающий адрес инициатора сообщения;

• сообщение содержит адреса, которые будут обрабатываться NHDP [RFC6130], связанные с использованием того же или иного адресного объекта, с двумя разными значениями канальной метрики одного вида и направления, использующие TLV с Type = LINK_METRIC и Type Extension = LINK_METRIC_TYPE; это применимо также к разным адресам, относящимся к интерфейсу OLSRv2, принявшему сообщение HELLO;

• сообщение включает какой-либо адресный объект, связанный с Address Block TLV с Type = MPR, но не связанный также с Address Block TLV с Type = LINK_STATUS и Value = SYMMETRIC (включая использование разных копий адресного объекта в одном или разных Address Block).

15.3.2. Использование сообщений HELLO

Сообщения HELLO сначала обрабатываются в соответствии с [RFC6130]. Эта обработка включает идентификацию (или создание) списков Link Tuple и Neighbor Tuple, соответствующих инициатору сообщения HELLO (current Link Tuple и current Neighbor Tuple). После этого должны выполняться перечисленные ниже действия, если сообщение HELLO принято на интерфейсе OLSRv2 и содержит TLV с Type = MPR_WILLING.

1. Если сообщение HELLO имеет точно указанный (well-defined) адрес инициатора (т. е. включает элемент <msg-orig-addr>) или имеет не более одного адреса сети, связанного с TLV с Type = LOCAL_IF, выполняются следующие действия.

   1. Удаляются все Neighbor Tuple за исключением текущего списка Neighbor Tuple, где N_orig_addr совпадает с адресом инициатора сообщения, после чего выполняются следующие из этого действия (включая возможное удаление списков Link Tuple), указанные в [RFC6130].

   2. Для текущего списка Link Tuple выполняются следующие операции:

      1. обновляются L_in_metric и L_out_metric в соответствии с параграфом 15.3.2.1;

      2. обновляется L_mpr_selector в соответствии с параграфом 15.3.2.3.

   3. Для текущего списка Neighbor Tuple выполняются следующие операции:

      1. N_orig_addr присваивается значение адреса инициатора сообщения;

      2. обновляются N_in_metric и N_out_metric в соответствии с параграфом 15.3.2.1;

      3. обновляются N_will_flooding и N_will_routing в соответствии с параграфом 15.3.2.2;

      4. обновляется N_mpr_selector в соответствии с параграфом 15.3.2.3.

   4. Для всех списков 2-Hop Tuple, обновленных в соответствии с [RFC6130] выполняются следующие операции:

      1. обновляются N2_in_metric и N2_out_metric в соответствии с параграфом 15.3.2.1.

2. При наличии каких-либо изменений в информационных базах маршрутизатора выполняются действия, описанные в разделе 17.

15.3.2.1. Обновление метрики

Для каждого адреса в принятом сообщении HELLO со связанным TLV с Type = LINK_STATUS и Value = HEARD или Value = SYMMETRIC определяется значение входящей (к инициатору сообщения) метрики канала. Если сообщение HELLO включает TLV с Type = LINK_METRIC и Type Extension = LINK_METRIC_TYPE, связывающее это значение адреса со значением метрики подходящего вида (канал) и направления (входящее), входящей метрикой канала будет это значение метрики; в противном случае метрика определяется значением UNKNOWN_METRIC.

Для каждого адреса в полученном сообщении HELLO со связанным TLV с Type = LINK_STATUS и Value = SYMMETRIC определяется значение исходящей (от инициатора сообщения) метрики канала. Если сообщение HELLO содержит TLV с Type = LINK_METRIC и Type Extension = LINK_METRIC_TYPE, связывающее это значение адреса со значением метрики подходящего вида (канал) и направления (исходящее), это значение будет исходящей метрикой канала, в противном случае для исходящей метрики устанавливается значение UNKNOWN_METRIC.

Для каждого адреса в полученном сообщении HELLO со связанным TLV с Type = LINK_STATUS или Type = OTHER_NEIGHB и Value = SYMMETRIC определяется значение входящей (к инициатору сообщения) метрики соседа. Если сообщение HELLO содержит TLV с Type = LINK_METRIC и Type Extension = LINK_METRIC_TYPE, связывающее это значение адреса со значением метрики подходящего вида (сосед) и направления (входящее), это значение будет входящей метрикой соседа, в противном случае для входящей метрики устанавливается значение UNKNOWN_METRIC.

Для каждого адреса в полученном сообщении HELLO со связанным TLV с Type = LINK_STATUS или Type = OTHER_NEIGHB и Value = SYMMETRIC определяется значение исходящей (от инициатора сообщения) метрики соседа. Если сообщение HELLO содержит TLV с Type = LINK_METRIC и Type Extension = LINK_METRIC_TYPE, связывающее это значение адреса со значением метрики подходящего вида (сосед) и направления (исходящее), это значение будет исходящей метрикой соседа, в противном случае для исходящей метрики устанавливается значение UNKNOWN_METRIC.

Элементы метрики канала L_in_metric и L_out_metric в Link Tuple обновляются, как показано ниже:

• Для любого Link Tuple в L_in_metric может быть установлено любое представительное значение внешним по отношению к данной спецификации процессом в любой момент. Значение L_in_metric должно устанавливаться всякий раз, когда L_status становится равным HEARD или SYMMETRIC (при недоступности других значений должно устанавливаться значение MAXIMUM_METRIC MUST). При установке L_in_metric может использоваться информация, основанная на получении пакета с сообщением HELLO, вызвавшего создание или обновление Link Tuple.

• При обновлении Link Tuple, как указано в [RFC6130], (возможно, сразу после создания) в результате получения сообщения HELLO для L_out_metric устанавливается значение входящей метрики канала для любого из включенных адресов интерфейса, через который было получено сообщение HELLO, если L_status = SYMMETRIC (отметим, что правила отбрасывания сообщений HELLO из параграфа 15.3.1 делают это значение однозначным). Если такой адрес имеется, но нет метрики канала, для L_out_metric устанавливается значение UNKNOWN_METRIC.

Элементы метрики соседа N_in_metric и N_out_metric в Neighbor Tuple обновляются в соответствии с параграфом 17.3.

Элементы метрики N2_in_metric и N2_out_metric в любом 2-Hop Tuple, обновленные в соответствии с [RFC6130], обновляются, соответственно, значениями входящей и исходящей метрики соседа, связанного с соответствующим N2_2hop_addr. При отсутствии такой метрики для этих элементов устанавливаются значения UNKNOWN_METRIC.

15.3.2.2. Обновление Willingness

Значения N_will_flooding и N_will_routing в текущем списке Neighbor Tuple обновляются с использованием Message TLV с Type = MPR_WILLING (должно присутствовать), как показано ниже:

• N_will_flooding := биты 0-3 значения TLV;

• N_will_routing := биты 4-7 значения TLV.

Каждое их этих значений будет находиться в диапазоне от 0 до 15 (т. е., от WILL_NEVER до WILL_ALWAYS.)

15.3.2.3. Обновление состояний селекторов MPR

L_mpr_selector обновляется следующим образом:

1. Если маршрутизатор находит адресный объект, представляющий любой из имеющих отношение к делу адресов сетей его локальных интерфейсов (т. е., содержащийся в I_local_iface_addr_list его интерфейса OLSRv2), со связанным Address Block TLV с Type = MPR и Value = FLOODING или Value = FLOOD_ROUTE в сообщении HELLO (показывающем, что его инициатор выбран получившим сообщение маршрутизатором в качестве рассылающего MPR), для текущего Link Tuple устанавливается

L_mpr_selector := true

2. В противном случае (т. е., не найдено таких адресов и Address Block TLV), если маршрутизатор находит адресный объект, представляющий любой из имеющих отношение к делу адресов сетей его локальных интерфейсов (т. е., содержащийся в I_local_iface_addr_list его интерфейса OLSRv2), со связанным Address Block TLV с Type = LINK_STATUS и Value = SYMMETRIC в сообщении HELLO, для текущего Link Tuple устанавливается

L_mpr_selector := false

N_mpr_selector обновляется следующим образом:

1. Если маршрутизатор находит адресный объект, представляющий любой из имеющих отношение к делу адресов сетей его локальных интерфейсов (т. е., содержащийся в I_local_iface_addr_list его интерфейса OLSRv2), со связанным Address Block TLV с Type = MPR и Value = ROUTING или Value = FLOOD_ROUTE в сообщении HELLO (показывающем, что его инициатор выбран получившим сообщение маршрутизатором в качестве маршрутизирующего MPR), для текущего Neighbor Tuple устанавливается

N_mpr_selector := true
N_advertised := true

2. В противном случае (т. е., не найдено таких адресов и Address Block TLV), если маршрутизатор находит адресный объект, представляющий любой из имеющих отношение к делу адресов сетей его локальных интерфейсов (т. е., содержащийся в I_local_iface_addr_list его интерфейса OLSRv2), со связанным Address Block TLV с Type = LINK_STATUS и Value = SYMMETRIC в сообщении HELLO, для текущего Neighbor Tuple устанавливается

N_mpr_selector := false

маршрутизатор может также установить N_advertised := false

16. Сообщения TC

Протокол определяет (и, следовательно, владеет им) TC Message Type (см. раздел 24). Таким образом, как указано в [RFC5444], этот протокол генерирует и передает все сообщения TC, получает все сообщения TC и отвечает за условия и способы обработки (обновления Topology Information Base) каждого сообщения TC, а также за их пересылку в соответствии с данной спецификацией.

16.1. Генерация сообщений TC

Сообщения TC соответствуют определению [RFC5444]. Генерируемые сообщения TC должны содержать перечисленные ниже элементы, соответствующие спецификации [RFC5444]:

• Адрес инициатора сообщения (маршрутизатор, создавший сообщений). Это поле должно использовать элемент <msg-orig-addr>.

• Элемент <msg-seq-num> с порядковым номером сообщения.

• Элемент <msg-hop-limit>, содержащий TC_HOP_LIMIT. Маршрутизатор может одно или разные значения TC_HOP_LIMIT в своих сообщениях TC (см. параграф 5.4.7).

• Элемент <msg-hop-count> со значением 0, если сообщение содержит TLV с Type = VALIDITY_TIME или Type = INTERVAL_TIME (как указано в [RFC5497]), указывающее более одного значения времени. Сообщение TC может включать элемент <msg-hop-count> даже если он не требуется.

• Один экземпляр Message TLV с Type := CONT_SEQ_NUM и Value := ANSN из базы Neighbor Information Base. Если сообщение TC является полным, для этого Message TLV должно устанавливаться Type Extension := COMPLETE, в противном случае должно быть Type Extension := INCOMPLETE (если сообщение TC не включает никаких адресных объектов со связанным Address Block TLV с Type = NBR_ADDR_TYPE или Type = GATEWAY, Message TLV может отсутствовать).

• Один экземпляр Message TLV с Type := VALIDITY_TIME, как указано в [RFC5497]. Если все сообщения TC передаются с одинаковым предельным числом интервалов, этот экземпляр TLV должен иметь значение, представляющее период T_HOLD_TIME. В противном случае (более одного значения TC_HOP_LIMIT) этот экземпляр TLV должен задавать время, которое зависит от числа интервалов применительно к выбранной схеме ограничения числа интервалов, как указано в [RFC5497]; в качестве таких значений следует выбирать числа, кратные T_HOLD_TIME. Эта опция включена в [RFC5497] для представления того, что недопустимо использовать интервалы нулевой и бесконечной продолжительности.

• Если сообщение TC является полным, все адреса сетей, которые являются N_orig_addr в списках Neighbor Tuple с N_advertised = true, должны быть представлены адресами объектов в одном или множестве Address Block. В неполные сообщения TC могут включаться любые такие адресные объекты. Хотя бы одна копия каждого такого включенного адресного объекта должна быть связана с Address Block TLV с Type := NBR_ADDR_TYPE и Value := ORIGINATOR или Value := ROUTABLE_ORIG, если этот адресный объект также связан с Value = ROUTABLE.

• Если сообщение TC является полным, все маршрутизируемые адреса сетей из списков N_neighbor_addr_list в Neighbor Tuple с N_advertised = true должны быть представлены адресными объектами в одном или множестве Address Block. В неполные сообщения TC могут включаться любые такие адресные объекты. Хотя бы одна копия каждого такого адресного объекта должна быть связана с Address Block TLV с Type = NBR_ADDR_TYPE и Value = ROUTABLE или Value = ROUTABLE_ORIG, если этот адресный объект также связан с Value = ORIGINATOR. Хотя бы одна копия каждого такого адресного объекта должна быть связана с Address Block TLV с Type = LINK_METRIC и Type Extension = LINK_METRIC_TYPE, показывающим исходящую метрику соседа со значением, равным соответствующему значению N_out_metric.

• Если сообщение TC является полным, все адреса сетей, которые являются AL_net_addr в Local Attached Network Tuple, должны быть представлены адресами объектов в одном или множестве Address Block. В неполные сообщения TC могут включаться любые такие адресные объекты. Хотя бы одна копия каждого такого адресного объекта должна быть связана с Address Block TLV с Type := GATEWAY и Value := AN_dist. В неполные сообщения TC могут включаться любые такие адресные объекты. Хотя бы одна копия каждого такого адресного объекта должна быть связана с Address Block TLV с Type = LINK_METRIC и Type Extension = LINK_METRIC_TYPE, показывающим исходящую метрику соседа со значением, равным соответствующему значению AL_metric.

Сообщения TC могут включать:

• Один экземпляр Message TLV с Type := INTERVAL_TIME, как указано в [RFC5497]. Если все сообщения TC передаются с одинаковым предельным числом интервалов, этот экземпляр TLV должен иметь значение, представляющее период TC_INTERVAL. Если в сообщениях TC используются разные предельные значения числа интервалов, этот экземпляр TLV должен задавать время, которое зависит от числа интервалов применительно к выбранной схеме ограничения числа интервалов, как указано в [RFC5497]; в качестве таких значений следует выбирать числа, кратные TC_INTERVAL. Эта опция включена в [RFC5497] для представления того, что недопустимо использовать интервалы нулевой и бесконечной продолжительности.

16.2. Передача сообщений TC

Маршрутизатор с одним или множеством интерфейсов OLSRv2 и любыми Neighbor Tuple с N_advertised = true или непустой конфигурацией Local Attached Network Set должен генерировать сообщения TC. Маршрутизатор, не имеющий такой информации для анонсирования, должен генерировать «пустые» сообщения TC в интервале A_HOLD_TIME с момента создания последнего непустого сообщения TC.

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

Сообщения TC могут генерироваться в ответ на изменения информации, которую они анонсируют, указываемые изменением ANSN в Neighbor Information Base. В таких случаях маршрутизатор может передавать полные сообщения TC, а может перезапустить свое планирование сообщений TC. Кроме того, маршрутизатор может передавать неполные сообщения TC, содержащие по крайней мере недавно анонсированные адреса сетей (т. е., не предшествующие, а текущие N_orig_addr или из списка N_neighbor_addr_list в Neighbor Tuple с N_advertised = true или AL_net_addr) в своих Address Block со связанными Address Block TLV. Отметим, что маршрутизатор не может сообщать об удалении анонсированных данных с помощью неполных сообщений TC.

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

При генерации сообщений TC (периодических или вызванных изменением содержимого) могут вноситься вариации, описанные в [RFC5148]. При этом вариации должны быть ограничены сверху (MAXJITTER) значениями:

• TP_MAXJITTER для периодических сообщений TC;

• TT_MAXJITTER для вызванных изменениями сообщений TC.

16.3. Обработка сообщений TC

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

Если сообщение рассматривается для обработки (параграф 14.2), маршрутизатор должен сначала проверить его приемлемость для обработки данным маршрутизатором, как указано в параграфе 16.3.1. Аналогичную проверку маршрутизатор может выполнять и для сообщений, рассматриваемых для пересылки — он должен проверить элементы в заголовке сообщения.

Если сообщение TC приемлемо, оно должно обрабатываться в соответствии с TC Message Type, как описано в параграфе 16.3.2, с обновлением информации в соответствующих базах Interface Information Base и Router Information Base. При внесении изменений в информационные базы должна выполняться обработка, описанная в разделе 17.

16.3.1. Отбрасывание сообщений TC

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

• Размер адреса в Message Header не соответствует используемому этим маршрутизатором размеру адреса.

• В сообщении отсутствует адрес инициатора и порядковый номер.

• В сообщении нет счетчика интервалов пересылки и присутствует многозначный экземпляр TLV с Type = VALIDITY_TIME или Type = INTERVAL_TIME, как определено в [RFC5497].

• В сообщении не содержится в точности один экземпляр Message TLV с Type = VALIDITY_TIME.

• В сообщении присутствует более одного экземпляра Message TLV с Type = INTERVAL_TIME.

• В сообщении нет Message TLV с Type = CONT_SEQ_NUM и Type Extension = COMPLETE или Type Extension = INCOMPLETE, но есть хотя бы один адресный объект, связанный с Address Block TLV с Type = NBR_ADDR_TYPE или Type = GATEWAY.

• В сообщении присутствует более одного экземпляра Message TLV с Type = CONT_SEQ_NUM и Type Extension = COMPLETE или Type Extension = INCOMPLETE.

• Адрес инициатора сообщения частично принадлежит данному маршрутизатору.

• Сообщение включает какой-либо адресный объект с отличным от максимального размером префикса (размер префикса в битах), связанный с Address Block TLV с Type = NBR_ADDR_TYPE и Value = ORIGINATOR или Value = ROUTABLE_ORIG.

• Сообщение включает какой-либо адресный объект, представляющий немаршрутизируемый адрес, связанный с Address Block TLV с Type = NBR_ADDR_TYPE и Value = ROUTABLE или Value = ROUTABLE_ORIG.

• Сообщение включает какой-либо адресный объект, связанный с Address Block TLV с Type = NBR_ADDR_TYPE или Type = GATEWAY, который представляет адрес инициатора сообщения.

• Сообщение включает какой-либо адресный объект (включая разные копии адресного объекта в одном или разных Address Block), связанный с Address Block TLV с Type = NBR_ADDR_TYPE или Type = GATEWAY, который также связан с множеством исходящих метрик соседей, использующих TLV с Type = LINK_METRIC и Type Extension = LINK_METRIC_TYPE.

• Связывает какой-либо адресный объект (включая разные копии адресного объекта в одном или разных Address Block) с множеством значений single hop count, использующих один или множество Address Block TLV с Type = GATEWAY.

• Связывает какой-либо адресный объект (включая разные копии адресного объекта в одном или разных Address Block) с Address Block TLV с Type = NBR_ADDR_TYPE и Type = GATEWAY.

Маршрутизатор может признать сообщение неприемлемым и по иным причинам. Неприемлемые сообщения должны отбрасываться без уведомления отправителя и обновления информационных баз маршрутизатора.

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

16.3.2. Определения для обработки сообщений TC

Когда, в соответствии с параграфом 14.2, сообщение TC «обрабатывается в соответствии с его типом», это означает:

• если сообщение TC содержит множество Message TLV с Type = CONT_SEQ_NUM и Type Extension = COMPLETE, оно обрабатывается в соответствии с параграфом 16.3.3, а затем выполняется финальная обработка в соответствии с параграфом 16.3.4;

• если сообщение TC содержит Message TLV с Type = CONT_SEQ_NUM и Type Extension = INCOMPLETE, оно обрабатывается лишь в соответствии с параграфом 16.3.3.

При обработке сообщений в соответствии с параграфами 16.3.3 и 16.3.4:

• «время достоверности» определяется из VALIDITY_TIME Message TLV в сообщении TC, согласно спецификации [RFC5497]; это время одинаково для всех данных в сообщении TC;

• «полученный ANSN» определяется значением Message TLV с Type = CONT_SEQ_NUM;

• «связанное значение метрики» определяется для любого адреса в сообщении TC, как значение метрики соседа, указанное TLV с Type = LINK_METRIC и Type Extension = LINK_METRIC_TYPE, которое связано с любым адресным объектом в сообщении TC, эквивалентным этому адресу, или UNKNOWN_METRIC (отметим, что правила параграфа 16.3.1 делают это определение однозначным);

• сравнение порядковых номеров выполняется в соответствии с разделом 21.

16.3.3. Первоначальная обработка сообщения TC

Обработка сообщения TC выполняется в несколько этапов, перечисленных ниже.

1. Обновляется конфигурация Advertising Remote Router Set в соответствии с параграфом 16.3.3.1. Если сообщение TC при этом будет признано отбрасываемым, остальные этапы не выполняются.

2. Обновляется конфигурация Router Topology Set в соответствии с параграфом 16.3.3.2.

3. Обновляется конфигурация Routable Address Topology Set в соответствии с параграфом 16.3.3.3.

4. Обновляется конфигурация Attached Network Set в соответствии с параграфом 16.3.3.4.

16.3.3.1. Заполнение Advertising Remote Router Set

Маршрутизатор должен обновить свою конфигурацию Advertising Remote Router Set, как показано ниже.

1. Если имеется список Advertising Remote Router Tuple, для которого выполняются оба условия:

• • • AR_orig_addr = адрес инициатора сообщения;

    • AR_seq_number > полученный ANSN,

сообщение TC должно быть отброшено.

2. В остальных случаях выполняются следующие операции:

   1. если нет Advertising Remote Router Tuple с

• • • AR_orig_addr = адрес инициатора сообщения,

создается Advertising Remote Router Tuple с

• • AR_orig_addr := адрес инициатора сообщения.

1. 2. Список Advertising Remote Router Tuple (существующий или новый) изменяется, как показано ниже:

• • AR_seq_number := полученный ANSN;

  • AR_time := текущее время + время достоверности.

16.3.3.2. Заполнение Router Topology Set

Маршрутизатор должен обновить свою конфигурацию Router Topology Set, как показано ниже.

1. Для каждого адреса (далее, анонсируемый адрес), соответствующего одному или множеству адресных объектов со связанным Address Block TLV с Type = NBR_ADDR_TYPE и Value = ORIGINATOR или Value = ROUTABLE_ORIG, который не принадлежит частично данному маршрутизатору, выполняются следующие действия.

   1. Если связанная метрика имеет значение UNKNOWN_METRIC, удаляются все Router Topology Tuple, для которых выполняются два условия:

• • TR_from_orig_addr = адрес инициатора сообщения;

  • TR_to_orig_addr = анонсируемый адрес.

1. 1. В остальных случаях, если нет Router Topology Tuple, для которого выполняются оба условия:

• • • TR_from_orig_addr = адрес инициатора сообщения;

    • TR_to_orig_addr = анонсируемый адрес,

создается новый список Router Topology Tuple с:

• • TR_from_orig_addr := адрес инициатора сообщения;

  • TR_to_orig_addr := анонсируемый адрес.

1. 3. Этот список Router Topology Tuple (существующий или новый) изменяется, как показано ниже:

• • TR_seq_number := полученный ANSN;

  • TR_metric := метрика связанного канала;

  • TR_time := текущее время + время достоверности.

16.3.3.3. Заполнение Routable Address Topology Set

Маршрутизатор должен обновить свою конфигурацию Routable Address Topology Set, как показано ниже.

1. Для каждого адреса (далее, анонсируемый адрес), соответствующего одному или множеству адресных объектов со связанным Address Block TLV с Type = NBR_ADDR_TYPE и Value = ROUTABLE или Value = ROUTABLE_ORIG, который не принадлежит частично данному маршрутизатору, выполняются следующие действия.

   1. Если связанная метрика имеет значение UNKNOWN_METRIC, удаляются все Routable Address Topology Tuple, для которых выполняются два условия:

• • TA_from_orig_addr = адрес инициатора сообщения;

  • TA_dest_addr = анонсируемый адрес.

1. 1. В остальных случаях, если нет Routable Address Topology Tuple, для которого выполняются оба условия:

• • • TA_from_orig_addr = адрес инициатора сообщения;

    • TA_dest_addr = анонсируемый адрес,

создается новый список Routable Address Topology Tuple с:

• • TA_from_orig_addr := адрес инициатора сообщения;

  • TA_dest_addr := анонсируемый адрес.

1. 3. Этот список Routable Address Topology Tuple (существующий или новый) изменяется, как показано ниже:

• • TA_seq_number := полученный ANSN;

  • TA_metric := метрика связанного канала;

  • TA_time := текущее время + время достоверности.

16.3.3.4. Заполнение Attached Network Set

Маршрутизатор должен обновить свою конфигурацию Attached Network Set, как показано ниже.

1. Для каждого адреса (далее, анонсируемый адрес), соответствующего одному или множеству адресных объектов со связанным Address Block TLV с Type = GATEWAY, который не принадлежит полностью данному маршрутизатору, выполняются следующие действия.

   1. Если связанная метрика имеет значение UNKNOWN_METRIC, удаляются все Attached Network Tuple, для которых выполняются два условия:

• • AN_net_addr = присоединенный адрес;

  • AN_orig_addr = адрес инициатора сообщения.

1. 1. В остальных случаях, если нет Attached Network Tuple, для которого выполняются оба условия:

• • • AN_net_addr = присоединенный адрес;

    • AN_orig_addr = адрес инициатора сообщения,

создается новый список Attached Network Tuple с:

• • AN_net_addr := присоединенный адрес;

  • AN_orig_addr := адрес инициатора сообщения.

1. 3. Этот список Attached Network Tuple (существующий или новый) изменяется, как показано ниже:

• • AN_seq_number := полученный ANSN;

  • AN_dist := значение (Value) из связанного GATEWAY TLV;

  • AN_metric := метрика связанного канала;

  • AN_time := текущее время + время достоверности.

16.3.4. Финальная обработка сообщения TC

Окончательная обработка сообщения TC выполняется в несколько этапов, перечисленных ниже.

1. Обновляется конфигурация Router Topology Set в соответствии с параграфом 16.3.4.1.

2. Обновляется конфигурация Routable Address Topology Set в соответствии с параграфом 16.3.4.2.

3. Обновляется конфигурация Attached Network Set в соответствии с параграфом 16.3.4.3.

16.3.4.1. Очистка Router Topology Set

Конфигурация Router Topology Set должна быть обновлена, как показано ниже.

1. Все списки Router Topology Tuples, для которых выполняются оба условия:

• • TR_from_orig_addr = адрес инициатора сообщения;

  • TR_seq_number < полученный ANSN,

должны быть удалены.

16.3.4.2. Очистка Routable Address Topology Set

Конфигурация Routable Address Topology Set должна быть обновлена, как показано ниже.

1. Все списки Routable Address Topology Tuples, для которых выполняются оба условия:

• • TA_from_orig_addr = адрес инициатора сообщения;

  • TA_seq_number < полученный ANSN,

должны быть удалены.

16.3.4.3. Очистка Attached Network Set

Конфигурация Attached Network Set должна быть обновлена, как показано ниже.

1. Все списки Attached Network Tuples, для которых выполняются оба условия:

• • AN_orig_addr = адрес инициатора сообщения;

  • AN_seq_number < полученный ANSN,

должны быть удалены.

17. Изменения информационных баз

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

17.1. Изменение адреса инициатора

При изменении на маршрутизаторе адреса инициатора выполняются перечисленные ниже действия¹³.

1. Если существует список Originator Tuple с

O_orig_addr = прежний адрес инициатора

этот список удаляется.

Создается Originator Tuple с

O_orig_addr := новый адрес инициатора
O_time := текущее время + O_HOLD_TIME

17.2. Изменения состояний каналов

Должна поддерживаться непротиворечивость Link Tuple в соответствии с приведенными ниже правилами, дополняющими правила [RFC6130].

• Если L_status = HEARD или L_status = SYMMETRIC, должен устанавливаться флаг L_in_metric (внешним по отношению к этой спецификации процессом).

• Если L_status != SYMMETRIC, устанавливается L_mpr_selector := false.

• Если L_out_metric = UNKNOWN_METRIC, недопустимо значение L_status = SYMMETRIC; устанавливается L_SYM_time := EXPIRED, если был указан симметричный канал.

17.3. Изменения состояний соседей

Должна поддерживаться непротиворечивость Neighbor Tuple MUST в соответствии с приведенными ниже правилами, дополняющими правила [RFC6130].

1. Если N_symmetric = true, то N_in_metric должно быть равно минимальному из значений L_in_metric в соответствующих Link Tuple с L_status = SYMMETRIC и L_in_metric != UNKNOWN_METRIC. Если таких списков нет, должно устанавливаться N_in_metric = UNKNOWN_METRIC.

2. Если N_symmetric = true, то N_out_metric должно быть равно минимальному из значений L_out_metric в соответствующих Link Tuple с L_status = SYMMETRIC и L_out_metric != UNKNOWN_METRIC. Если таких списков нет, должно устанавливаться N_in_metric = UNKNOWN_METRIC.

3. Если N_symmetric = false, то для N_flooding_mpr, N_routing_mpr, N_mpr_selector и N_advertised должно устанавливаться значение false.

4. Если N_mpr_selector = true, то для N_advertised должно устанавливаться значение true.

5. Если N_symmetric = true, N_out_metric != UNKNOWN_METRIC и N_mpr_selector = false, маршрутизатор может выбрать N_advertised = true или N_advertised = false. При росте числа анонсируемых соседей увеличивается размер сообщений TC, но при этом растет и уровень избыточности (резервирования) маршрутизации. Маршрутизаторам следует принимать во внимание природу своей сети при выборе решения, а также следует избегать ненужных изменения в анонсируемых состояниях, которые могут приводить к неоправданным изменениям в маршрутизации.

17.4. Изменение анонсируемых соседей

Маршрутизатор должен инкрементировать ANSN в Neighbor Information Base в перечисленных ниже случаях.

1. В любом списке Neighbor Tuple меняется значение N_advertised или список Neighbor Tuple с N_advertised = true удаляется.

2. В любом списке Neighbor Tuple меняется значение N_orig_addr или добавляется/удаляется любой маршрутизируемый адрес в N_neighbor_addr_list.

3. В любом списке Neighbor Tuple с N_advertised = true меняется значение N_out_metric.

4. Возникают какие-либо изменения в Local Attached Network Set.

17.5. Завершение срока действия Advertising Remote Router

Конфигурации Router Topology Set, Routable Address Topology Set и Attached Network Set должны меняться при завершении срока действия Advertising Remote Router Tuple (достижения времени AR_time). Перед удалением Advertising Remote Router Tuple должны выполняться перечисленные ниже изменения.

1. Все списки Router Topology Tuple с

• • TR_from_orig_addr = AR_orig_addr из Advertising Remote Router Tuple удаляются.

2. Все списки Routable Address Topology Tuple с

• • TA_from_orig_addr = AR_orig_addr из Advertising Remote Router Tuple удаляются.

3. Все списки Attached Network Tuple с

• • AN_orig_addr = AR_orig_addr из Advertising Remote Router Tuple удаляются.

17.6. Изменения соседства и обновления MPR

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

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

• • добавлен список Link Tuple с L_status = SYMMETRIC и L_out_metric != UNKNOWN_METRIC;

  • удален список Link Tuple с L_status = SYMMETRIC и L_out_metric != UNKNOWN_METRIC;

  • список Link Tuple с L_status = SYMMETRIC и L_out_metric != UNKNOWN_METRIC изменяется так, что L_status = HEARD, L_status = LOST или L_out_metric = UNKNOWN_METRIC;

  • список Link Tuple с L_status = HEARD or L_status = LOST изменяется так, что L_status = SYMMETRIC и L_out_metric != UNKNOWN_METRIC;

  • процесс выбора рассылающего MPR использует значения метрики (см. параграф 18.4) и меняется L_out_metric в любом из списков Link Tuple с L_status = SYMMETRIC;

  • значение N_will_flooding в Neighbor Tuple с N_symmetric = true и N_out_metric != UNKNOWN_METRIC меняется с WILL_NEVER на любое значение;

  • значение N_will_flooding в Neighbor Tuple с N_flooding_mpr = true меняется на WILL_NEVER;

  • значение N_will_flooding в Neighbor Tuple с N_symmetric = true, N_out_metric != UNKNOWN_METRIC и N_flooding_mpr = false меняется на WILL_ALWAYS;

  • добавляется или удаляется 2-Hop Tuple с N2_out_metric != UNKNOWN_METRIC;

  • значение N2_out_metric в любом 2-Hop Tuple изменяется и процесс выбора рассылающего MPR используется значения метрики (см. параграф 18.4) или меняет метрику на значение UNKNOWN_METRIC или наоборот.

2. В остальных случаях набор рассылающих MPR маршрутизатора может рассчитываться заново, если N_will_flooding в Neighbor Tuple с N_symmetric = true меняется каким-либо иным способом; этот набор следует рассчитывать заново, если N_flooding_mpr = false и это увеличивает N_will_flooding или N_flooding_mpr = true и это уменьшает N_will_flooding.

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

• • добавлен список Neighbor Tuple с N_symmetric = true и N_in_metric != UNKNOWN_METRIC;

  • удален список Neighbor Tuple с N_symmetric = true и N_in_metric != UNKNOWN_METRIC;

  • список Neighbor Tuple с N_symmetric = true и N_in_metric != UNKNOWN_METRIC меняется так, что N_symmetric = false;

  • список Neighbor Tuple с N_symmetric = false меняется так, что N_symmetric = true и N_in_metric != UNKNOWN_METRIC;

  • меняется значение N_in_metric в любом из Neighbor Tuple с N_symmetric = true;

  • значение N_will_routing в Neighbor Tuple с N_symmetric = true и N_in_metric != UNKNOWN_METRIC меняется с WILL_NEVER на любое другое значение;

  • значение N_will_routing в Neighbor Tuple с N_routing_mpr = true меняется на WILL_NEVER;

  • значение N_will_routing в Neighbor Tuple с N_symmetric = true, N_in_metric != UNKNOWN_METRIC и N_routing_mpr = false меняется на WILL_ALWAYS;

  • добавляется или удаляется 2-Hop Tuple с N2_in_metric != UNKNOWN_METRIC;

  • меняется N2_in_metric в любом 2-Hop Tuple.

4. В остальных случаях набор маршрутизирующих MPR для маршрутизатора может рассчитываться заново, если N_will_routing в Neighbor Tuple с N_symmetric = true меняется иным способом; этот набор следует рассчитывать заново, если N_routing_mpr = false и это увеличивает N_will_routing или N_routing_mpr = true и это уменьшает N_will_routing.

При повторном расчете набора MPR для маршрутизатора должны выполняться требования раздела 18.

17.7. Обновления Routing Set

Конфигурация Routing Set должна обновляться (см. раздел 19), когда изменения в Local Information Base, Neighborhood Information Base или Topology Information Base указывают на изменения (включая любые потенциально используемые значения исходящей метрики соседей) известных симметричных соединений и/или подключенных сетей в MANET и, следовательно, изменения топологического графа (Topology Graph). Достаточно принимать во внимание изменения, оказывающие влияние по крайней мере на перечисленные ниже аспекты.

• Конфигурация Local Interface Set для интерфейса OLSRv2 при удалении любого адреса сети из I_local_iface_addr_list. В таких случаях, если не удаляется интерфейс OLSRv2, может не потребоваться ничего сверх замены адреса сети (если он используется) на другой адрес сетей из того же I_local_iface_addr_list.

• Конфигурация Local Attached Set при удалении любого AL_net_addr, который является также AN_net_addr. В этом случае может не потребоваться ничего, кроме добавления списков Routing Tuple с R_dest_addr равным этому AN_net_addr.

• Конфигурация Link Set любого интерфейса OLSRv2 с учетом только списков Link Tuple, которые имеют или имели L_status = SYMMETRIC и L_out_metric != UNKNOWN_METRIC (включая удаление таких списков Link Tuple).

• Конфигурация Neighbor Set с учетом только списков Neighbor Tuple, которые имеют или имели N_symmetric = true и N_out_metric != UNKNOWN_METRIC, но не имеют N_orig_addr = unknown.

• Конфигурация 2-Hop Set любого интерфейса OLSRv2, если она используется при создании Routing Set и изменения воздействуют на какой-либо 2-Hop Tuple с N2_out_metric != UNKNOWN_METRIC.

• Конфигурация Router Topology Set.

• Конфигурация Routable Address Topology Set.

• Конфигурация Attached Network Set.

18. Выбор MPR

Каждый маршрутизатор должен выбрать из числа выразивших готовность ближайших соседей с симметричным соединением два подмножества маршрутизаторов — flooding MPR и routing MPR. Этот выбор записывается в конфигурацию маршрутизатора Neighbor Set и указывается в сообщениях HELLO от этого маршрутизатора. Маршрутизаторы могут выбирать для себя устройства MPR с помощью любого процесса, который удовлетворяет приведенным далее условиям и может (но не обязан) использовать описанную здесь организацию данных. Взаимодействие маршрутизаторов не зависит от использования ими общего или разных алгоритмов выбора MPR.

Только рассылающие MPR пересылают сообщения, передаваемые в лавинном режиме через сеть MANET. Это позволяет снизить объем лавинных рассылок и оптимизировать механизмы такой рассылки (MPR flooding). Маршрутизирующие Routing MPR служат для упрощения топологии в сетях MANET (если такое упрощение не требуется, маршрутизатор может выбрать всех подходящих соседей в качестве routing MPR). Минимизация этих двух наборов MPR не имеет существенного значения для работы сети, однако позволяет снизить издержки протокола.

18.1. Обзор

MPR выбирается в соответствии с перечисленными ниже этапами, определенными в последующих параграфах.

• Определяется структура данных Neighbor Graph.

• Определяются свойства MPR Set на основе Neighbor Graph. Любой алгоритм, создающий MPR Set с нужными свойствами, будет пригоден для выбора MPR. Пример алгоритма создания MPR Set дан в Приложении B.

• Определяется способ создания графа соседей (Neighbor Graph) для каждого интерфейса на основе соответствующей Interface Information Base и способ комбинирования полученных MPR Set для определения рассылающего MPR для данного маршрутизатора, а также запись соответствующей информации в Neighbor Set данного маршрутизатора.

• Определяется способ создания единого Neighbor Graph на основе информации из всех Interface Information Bases и Neighbor Information Base, а также запись полученного MPR Set в качестве маршрутизирующих MPR в Neighbor Set данного маршрутизатора.

• Приведена спецификация условий, когда должен выполняться расчет MPR.

При выборе маршрутизатором своих MPR он может принимать во внимание любые, известные ему характеристики соседей. В частности, следует учитывать готовность соседа, указанную в соответствующем значении N_will_flooding или N_will_routing, предпочитая соседей в более высоким уровнем готовности (отметим, что уровни готовности WILL_NEVER и WILL_ALWAYS принимаются во внимание всегда). Однако маршрутизатор может принимать во внимание другие характеристики, считая их более важными.

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

18.2. Граф соседей

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

Свойства Neighbor Graph перечислены ниже.

• Граф состоит из двух множеств N1 и N2.

• Для каждого элемента x в N1 имеются связанное с ним значение готовности W(x) и WILL_NEVER < W(x) <= WILL_ALWAYS.

• Для каждого элемента x в N1 имеется связанное с ним значение метрики d1(x) > 0.

• Для некоторых элементов y в N2 имеется значение связанной с элементом метрики d1(y) > 0 (остальные элементы y в N2 имеют неопределенное значение d1(y), которое можно рассматривать, как бесконечное).

• Для каждого элемента x в N1 существует подмножество N2(x) элементов N2 (которое может быть пустым), такое, что для каждого x в N1 и каждого y в N2(x) имеется связанное с ними значение метрики d2(x,y) > 0 (для других x в N1 и y в N2 значение d2(x,y) не определено и может считаться бесконечным).

• N2 является объединением всех N2(x) для всех x в N1 (т. е., для каждого y в N2 имеется хотя бы один элемент x в N1, такой, что y входит в N2(x)).

Удобно также определить приведенные ниже свойства.

• Для каждого y в N2 существует множество N1(y), включающее x из N1 тогда и только тогда, когда y входит в N2(x); из последнего свойства предыдущей группы следует, что множество N1(y) не пусто.

• Для каждого x в N1 и y в N2, если определено d2(x,y), то d(x,y) := d1(x)+d2(x,y); в противном случае метрика d(x,y) не определена (таким образом, метрика d(x,y) определена, если y входит в N2(x) или, что эквивалентно, если x входит в N1(y)).

• Для любого подмножества S в N1 и для каждого y в N2 метрика d(y,S) представляет собой значение d1(y), если оно определено и все d(x,y) для x входят в N1(y) и S. Если нет минимального значения метрики, d(y,S) не определена (может считаться бесконечной). Из последнего свойства предыдущей группы следует, что метрика d(y,N1) определена для всех y.

18.3. Свойства MPR

С учетом определения Neighbor Graph в параграфе 18.2 множество MPR Set для данного Neighbor Graph представляет собой подмножество M множества N1, удовлетворяющее приведенным ниже условиям:

• если x из N1 имеет W(x) = WILL_ALWAYS, x входит в M;

• для любого y в N2, не имеющего определенной метрики d1(y), существует хотя бы один элемент в M, входящий также в N1(y) (это эквивалентно требованию определенности d(y,M));

• для любого y в N2 выполняется условие d(y,M) = d(y,N1).

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

Отметим, что если множество M является MPR Set, то и любое подмножество N1, содержащее M, также будет MPR Set, а N1 всегда является MPR Set. Множество MPR Set может быть пустым, если N2 не содержит ни одного элемента с неопределенной метрикой d1(y).

18.4. Рассылающие MPR

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

При расчете рассылающих MPR не требуется использовать метрику каналов или, эквивалентно, можно использовать метрику с фиксированным значением, в качестве которого принимается 1. Однако каналы с неизвестной метрикой (L_out_metric = UNKNOWN_METRIC) использовать недопустимо, даже если метрики каналов не применяются.

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

Для каждого интерфейса OLSRv2 (текущий интерфейс) определяется граф соседей (Neighbor Graph), как описано в параграфе 18.2, в соответствии с приведенными ниже правилами.

• Определить доступный Link Tuple в качестве Link Tuple набора Link Set для текущего интерфейса с L_status = SYMMETRIC и L_out_metric != UNKNOWN_METRIC.

• Определить разрешенный Link Tuple в качестве доступного Link Tuple, для которого соответствующий Neighbor Tuple имеет N_will_flooding > WILL_NEVER.

• Определить разрешенный 2-Hop Tuple в качестве 2-Hop Tuple в наборе 2-Hop Set для текущего интерфейса с N2_out_metric != UNKNOWN_METRIC и наличием разрешенного Link Tuple с L_neighbor_iface_addr_list = N2_neighbor_iface_addr_list.

• Определить элемент N1 для каждого разрешенного Link Tuple. Это будет определять соответствующий Link Tuple для каждого элемента N1 и соответствующий Neighbor Tuple для каждого элемента N1, являющийся Neighbor Tuple для Link Tuple.

• Для каждого элемента x в N1 определить W(x) := N_will_flooding соответствующего Neighbor Tuple.

• Для каждого элемента x в N1 определить d1(x) как одно из приведенных ниже значений:

1. L_out_metric соответствующего Link Tuple;

2. 1.

• Определить элемент N2 для каждого сетевого адреса, который является N2_2hop_addr одного или нескольких разрешенных 2-Hop Tuple. Это будет определять соответствующий адрес каждого элемента N2.

• Если соответствующий адрес присутствует в N_neighbor_addr_list кортежа Neighbor, соответствующего одному или множеству доступных Link Tuple, для каждого элемента y в N2 определяется d1(y) как одно из

1. минимальное из значений L_out_metric в этих Link Tuple;

2. 1.

• В остальных случаях d1(y) не определяется. При d1(y) := 1 все такие y в N2 могут быть удалены из N2.

• Для каждого элемента x в N1 определяется N2(x) как набор элементов y в N2, у которых соответствующий адрес имеет значение N2_2hop_addr из разрешенного 2-Hop Tuple с N2_neighbor_iface_addr_list = L_neighbor_iface_addr_list кортежа Link Tuple, соответствующего x.

  Для всех таких x и y определяется d2(x,y) как одно из двух значений

1. N2_out_metric из данного 2-Hop Tuple;

2. 1.

Решение о способе маркировки каждого элемента N1 или N2 зависит от реализации. Например, элемент N1 может быть помечен одним ли несколькими адресами из соответствующего L_neighbor_iface_addr_list, указателем или ссылкой на соответствующий Link Tuple.

С использованием этих Neighbor Graph использующие лавинную рассылку MPR выбираются и записываются, как указано ниже.

• Для каждого интерфейса OLSRv2 определяется MPR Set as в соответствии с параграфом 18.3.

• Neighbor Tuple представляет использующий лавинную рассылку MPR и имеет N_flooding_mpr := true (иначе, N_flooding_mpr := false) тогда и только тогда, когда данный Neighbor Tuple соответствует элементу в MPR Set, создаваемому для любого интерфейса, как описано выше. Т. е. общий набор использующих лавинную рассылку MPR является объединением наборов рассылающих MPR для всех интерфейсов OLSRv2.

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

18.5. Маршрутизирующие MPR

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

Определяется один Neighbor Graph в соответствии с параграфом 18.2, как описано ниже.

• Определяется достижимый Neighbor Tuple для установки в качестве Neighbor Tuple с N_symmetric = true и N_in_metric != UNKNOWN_METRIC.

• Определяется разрешенный Neighbor Tuple в качестве достижимого Neighbor Tuple с N_will_routing > WILL_NEVER.

• Определяется разрешенный 2-Hop Tuple в качестве 2-Hop Tuple в 2-Hop Set для любого интерфейса OLSRv2 с N2_in_metric != UNKNOWN_METRIC, для которого имеется разрешенный Neighbor Tuple с N_neighbor_addr_list, содержащим N2_neighbor_iface_addr_list.

• Определяется элемент N1 для каждого разрешенного Neighbor Tuple. Затем он определяет соответствующий Neighbor Tuple для каждого элемента N1.

• Для каждого элемента x в N1 определяется W(x) := N_will_routing соответствующего Neighbor Tuple.

• Для каждого элемента x в N1 определяется d1(x) := N_in_metric соответствующего Neighbor Tuple.

• Определяется элемент N2 для каждого сетевого адреса, который является N2_2hop_addr одного или нескольких 2-Hop Tuple. Затем он определяет соответствующий адрес для каждого элемента N2.

• Для каждого элемента y в N2 определяется d1(y) = N_in_metric данного Neighbor Tuple, если соответствующий адрес имеется в списке N_neighbor_addr_list достижимого Neighbor Tuple. В остальных случаях d1(y) не определяется.

• Для каждого элемента x в N1 определяется N2(x) как набор элементов y в N2, соответствующие адреса которых являются N2_2hop_addr в разрешенном 2-Hop Tuple, который имеет N2_neighbor_iface_addr_list, содержащийся в N_neighbor_addr_list кортежа Neighbor Tuple, соответствующего x. Для всех таких x и y определяется d2(x,y) := N2_out_metric из данного 2-Hop Tuple.

Решение о способе маркировки каждого элемента N1 или N2 определяется реализацией. Например, элемент N1 можно пометить одним или несколькими адресами из соответствующего N_neighbor_addr_list, указателем или ссылкой на соответствующий Neighbor Tuple.

С использованием этих Neighbor Graph выбираются и записываются маршрутизирующие MPR, как указано ниже.

• Определяется MPR Set в соответствии с параграфом 18.3.

• Neighbor Tuple представляет маршрутизирующий MPR и имеет N_routing_mpr := true (иначе N_routing_mpr := false), тогда и только тогда, когда этот Neighbor Tuple соответствует элементу в MPR Set, созданному как указано выше.

18.6. Рассчитывающий MPR

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

19. Расчет Routing Set

Routing Set маршрутизатора заполняется Routing Tuple, которые представляют пути от маршрутизатора ко всем адресатам в сети. Эти пути рассчитываются на основе графа Network Topology Graph, который создается из данных в Information Base, полученных при обмене сообщениями HELLO и TC.

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

19.1. Граф сетевой топологии

Network Topology Graph формируется из содержащейся в маршрутизаторе информации Local Interface Set, Link Set для интерфейсов OLSRv2, Neighbor Set, Router Topology Set, Routable Address Topology Set и Attached Network Set. Network Topology Graph может также использовать информацию из имеющихся в маршрутизаторе 2-Hop Set для интерфейсов OLSRv2. Network Topology Graph формирует представление маршрутизатора для топологии сети в форме направленного графа. С каждым ребром этого графа связано значение метрики. Network Topology Graph имеет «магистраль» (создается из маршрутов с минимальной суммарной метрикой), содержащую перечисленные ниже ребра.

• Ребра X -> Y для всех возможных Y по одному X для Y, для которых выполняются все приведенные ниже условия:

  • Y = N_orig_addr из Neighbor Tuple;

  • N_orig_addr неизвестно;

  • X входит в I_local_iface_addr_list из Local Interface Tuple;

  • имеется Link Tuple с L_status = SYMMETRIC и L_out_metric != UNKNOWN_METRIC, такой, что этот Neighbor Tuple и этот Local Interface Tuple соответствуют ему. Сетевой адрес из L_neighbor_iface_addr_list будет в этом случае обозначаться R.

  По возможности следует предпочитать выбор R = Y и выбор X из Local Interface Tuple, соответствующего Link Tuple, из которого был выбран R. Метрикой для такого ребра будет соответствующее значение N_out_metric.

• Все ребра W -> U, для которых выполняются все приведенные ниже условия:

  • W является TR_from_orig_addr из Router Topology Tuple;

  • U является TR_to_orig_addr из того же Router Topology Tuple.

  Метрикой такого ребра является соответствующее значение TR_metric.

Network Topology Graph дополнительно «декорируется» описанными далее ребрами. Если сетевой адрес S, V, Z или T равен сетевому адресу Y или W, ребро, завершающееся адресом S, V, Z или T, недопустимо использовать в пути.

• Ребра X -> S для всех возможных S и одного X на S, для которых выполняются все приведенные ниже условия:

  • S входит в N_neighbor_addr_list из Neighbor Tuple;

  • X входит в I_local_iface_addr_list из Local Interface Tuple;

  • Имеется Link Tuple с L_status = SYMMETRIC и L_out_metric != UNKNOWN_METRIC, такой, что этот Neighbor Tuple и этот Local Interface Tuple соответствуют ему. Сетевой адрес из L_neighbor_iface_addr_list будет в этом случае обозначаться R.

  По возможности следует предпочитать выбор R = S и выбор X из Local Interface Tuple, соответствующего Link Tuple, из которого был выбран R. Метрикой для такого ребра будет соответствующее значение N_out_metric.

• Все ребра W -> V, для которых выполняются все приведенные ниже условия:

  • W является TA_from_orig_addr из Routable Address Topology Tuple;

  • V является TA_dest_addr из того же Routable Address Topology Tuple.

  Метрикой такого ребра является соответствующее значение TA_metric.

• Все ребра W -> T, для которых выполняются все приведенные ниже условия:

  • W является AN_orig_addr из Attached Network Tuple;

  • T является AN_net_addr из того же Attached Network Tuple.

  Метрикой такого ребра является соответствующее значение AN_metric.

• (Необязательно) Все ребра Y -> Z, для которых выполняются все приведенные ниже условия:

  • Z является маршрутизируемым адресом и N2_2hop_addr из 2-Hop Tuple с N2_out_metric != UNKNOWN_METRIC;

  • Y является N_orig_addr из соответствующего Neighbor Tuple;

  • This Neighbor Tuple имеет значение N_will_routing, отличное от WILL_NEVER.

  Пути, завершающиеся такими ребрами, недопустимо предпочитать какому-либо иному пути. Метрикой такого ребра является соответствующее значение N2_out_metric.

Ни одна часть Topology Graph, которая не соединена с локальным сетевым адресом X, не применяется. Следует выбирать лишь одно значение X из каждого I_local_iface_addr_list и лишь одно значение R следует выбирать из любого L_neighbor_iface_addr_list. Все ребра имеют значение счетчика интервалов 1, за исключением ребер W -> T, у которых счетчик интервалов имеет значение соответствующего AN_dist.

19.2. Заполнение Routing Set

Routing Set должен содержать кратчайшие пути ко всем адресатам от локальных интерфейсов OLSRv2, использующих Network Topology Graph. Для расчета можно использовать любой алгоритм, включающий те или иные способы выбора среди путей с одинаковой метрикой (при наличии двух путей с одинаковой метрикой, но разным числом интервалов, следует выбирать путь с меньшим числом интервалов).

Используя нотацию из параграфа 19.1, сначала строятся «магистральные» пути, использующие только ребра X -> Y и W -> U (с помощью алгоритма определения минимальной дистанции). Затем могут быть добавлены пути, использующие лишь финальное ребро. Их недопустимо применять вместо магистральных путей к тем же адресатам (а пути, завершающиеся ребром Y -> Z, не следует применять взамен путей с другой формой завершающего ребра).

Каждый путь будет соответствовать Routing Tuple. Пути могут быть двух типов. Первый тип будет представлять пути с одним ребром типа X → S и X -> Y в виде:

• R_local_iface_addr := X;

• R_next_iface_addr := R;

• R_dest_addr := S или Y;

• R_dist := 1;

• R_metric := метрика ребра,

где R определен в параграфе 19.1 для этих типов ребер.

Второй тип будет представлять пути с множеством ребер, которые всегда будут иметь первое ребро типа X -> Y и финальное ребро типа W -> U, W -> V, W -> T или Y -> Z. Routing Tuple будет иметь вид:

• R_local_iface_addr := X;

• R_next_iface_addr := Y;

• R_dest_addr := U, V, T или Z;

• R_dist := суммарный счётчик интервалов (hop) на всех ребрах пути;
• R_metric := суммарная метрика на всех ребрах пути.

Routing Tuple второго типа с немаршрутизируемым адресом R_dest_addr можно отбрасывать.

Пример алгоритма для расчета Routing Set в маршрутизаторе представлен в приложении C.

20. Предлагаемые значения параметров

Этот протокол использует все параметры, определенные в [RFC6130], и дополнительные параметры из данной спецификации. Все дополнительные параметры, за исключением RX_HOLD_TIME, являются параметрами маршрутизатора, как определено в [RFC6130]. Предлагаемые значения параметров, приведенные в следующих параграфах, подходят для случаев, когда каждый параметр (включая определенные в [RFC6130]) имеет одно значение. Значения, предлагаемые для параметров, которые определены в [RFC6130], даны в этом документе.

Предлагаемые ниже значения основаны на опыте развертывания [RFC3626] (описанном, например, в [McCabe]) и считаются типовыми. Они могут изменяться с учетом требований конкретного развертывания. Например, предполагается, что сеть с ограниченной пропускной способностью интерфейсов будет использовать более продолжительные интервалы между соединениями, а сети с высокой мобильностью будут применять более короткие интервалы. При выборе этих значений должны соблюдаться ограничения, приведенные в разделе 5.

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

20.1. Время сохранения локальной истории

   O_HOLD_TIME := 30 (секунд)

20.2. Интервалы между сообщениями

   TC_INTERVAL := 5 (секунд)
   TC_MIN_INTERVAL := TC_INTERVAL/4

20.3. Параметры срока достоверности анонсированной информации

   T_HOLD_TIME := 3 x TC_INTERVAL
   A_HOLD_TIME := T_HOLD_TIME

20.4. Параметры срока достоверности принятых сообщений

   RX_HOLD_TIME := 30 (секунд)
   P_HOLD_TIME := 30 (секунд)
   F_HOLD_TIME := 30 (секунд)

20.5. Параметры вариаций

   TP_MAXJITTER := HP_MAXJITTER
   TT_MAXJITTER := HT_MAXJITTER
   F_MAXJITTER := TT_MAXJITTER

20.6. Параметр Hop Limit

   TC_HOP_LIMIT := 255

20.7. Параметры готовности

   WILL_FLOODING := WILL_DEFAULT
   WILL_ROUTING := WILL_DEFAULT

21. Порядковые номера

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

Термин MAXVALUE обозначает, что следующее значение (на 1 больше) будет превышать максимально допустимое. Для 16-битовых порядковых номеров (используются в данной спецификации) MAXVALUE = 65536.

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

   S1 > S2 и S1 - S2 < MAXVALUE/2
   S2 > S1 и S2 - S1 > MAXVALUE/2

Когда порядковые номера отличаются на MAXVALUE/2 их порядок следования становится неопределенным. В такой ситуации (которой не должно возникать) можно выбирать любой порядок.

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

22. Расширения

Расширения этого протокола должны взаимодействовать с данной спецификацией и, возможно, с [RFC6130]. Устройство протокола обеспечивает такое взаимодействие разными способами, включая перечисленные ниже.

• Через доступ и, возможно, расширение данных в Information Base. Для обновления элементов, заданных в этой спецификации, действуют нормативные ограничения, указанные в [RFC6130] и приложении A. Отметим, что указанная в данном документе гарантирует выполнение этих ограничений.

• Через доступ к исходящим сообщениям до их отправки через любой из интерфейсов OLSRv2 и добавление информации в сообщения, как указано в [RFC5444]. Это может включать Message TLV и/или сетевые адреса со связанными Address Block TLV (адреса без вновь привязанных TLV не следует добавлять в сообщения). Это позволяет, например, протоколу защиты (см. раздел 23) добавить TLV с криптографической подписью сообщения.

• Через доступ к входящим сообщениям с возможностью их отбрасывания до обработки данным протоколом. Это позволяет, например, протоколу защиты (см. раздел 23) проверять подписи сообщений и предотвращать обработку и/или пересылку не поддающихся проверке сообщений.

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

• Через запросы генерации сообщений в заданное время. В этом случае при генерации сообщений должны соблюдаться ограничения, заданные в [RFC6130] и параграфе 5.4.3.

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

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

23.1. Архитектура защиты

OLSRv2 встраивается в архитектуру, указанную в приложении A к [RFC5444], [RFC5498] и разделе 16 в [RFC6130], причем последняя использует и расширяет сообщения и базы Information Base.

В рамках этой архитектуры OLSRv2 и NHDP [RFC6130] принимают наличие внешних причин, позволяющих отвергнуть сообщения, которые будут сочтены некорректно сформированными или небезопасными (например, значение ICV¹⁴, включенное внешним механизмом, не может быть проверено). Эта архитектура позволяет выбрать способ реализации функций защиты, отражая ситуацию, когда домены развертывания протокола маршрутизации MANET имеют разные требования безопасности от самых строгих до практического отсутствия. Это позволяет спецификации протокола маршрутизации MANET оставаться достаточно общей с возможностью расширения самого протокола и/или процесса мультиплексирования и демультиплексирования, описанного в приложении A к [RFC5444], обеспечивая механизмы защиты, подходящие для данного домена развертывания.

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

23.2. Целостность

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

Ниже перечислены некоторые возможные варианты некорректной работы маршрутизаторов.

1. Генерация сообщений TC, анонсирующих каналы к маршрутизаторам, не являющимся соседними.

2. Генерация сообщений TC, выдающих его за другой маршрутизатор.

3. Генерация сообщений HELLO, анонсирующих каналы к маршрутизаторам, не являющимся соседними.

4. Генерация сообщений HELLO, выдающих его за другой маршрутизатор.

5. Пересылка измененных управляющих сообщений.

6. Отказ от пересылки управляющих сообщений.

7. Некорректный выбор многоточечных трансляторов.

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

9. Воспроизведение (replay) записанного ранее управляющего трафика от другого маршрутизатора.

Аутентификация исходного маршрутизатора (для случаев 2, 4, 5) и отдельных каналов, анонсированных в управляющих сообщениях (для случаев 1 и 3) может служить противодействием. Однако для предотвращения передачи маршрутизаторами старой (корректно аутентифицированной) информации (случай 9) нужны дополнительные данные (например, временная метка или порядковый номер), позволяющие обнаружить воспроизводимые сообщения.

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

Важно понимать, что все управляющие сообщения (HELLO и TC) передаются всем маршрутизаторам в радиусе одного интервала (1-hop neighborhood), а некоторые сообщения (TC) лавинно рассылаются всем маршрутизаторам сети. Это выполняется с помощью пакетов, передаваемых всем маршрутизаторам в радиусе одного интервала, текущий набор которых может быть неизвестен. Таким образом, управляющее сообщение или пакет, используемые этим протоколом, всегда содержатся в отправке, адресованной множеству получателей и важно, чтобы применяемый механизм аутентификации позволял любому принимающему маршрутизатору проверить подлинность сообщения или пакета.

В [RFC7182] задан общий формат обмена для криптографической информации в виде Packet TLV, Message TLV и Address Block TLV, как указано в [RFC5444]. Эти данные могут использоваться (сообща) разными защитными расширениями протокола маршрутизации MANET. В частности, [RFC7182] задает формат TLV для включения ICV, т. е. подписей для защиты целостности, а также TLV с временной информацией для предотвращения атак с воспроизведением. В [RFC7182] указаны реестры для использования разных шифров и форматов временной информации. При использовании ICV TLV в среде OLSRv2 невозможность проверить включенное значение ICV требует отвергать входящее сообщение или пакет как непригодные в соответствии с параграфом 12.1 [RFC6130] и параграфом 16.3.1 данной спецификации, когда применяется процесс мультиплексирования и демультиплексирования, описанный в приложении A к [RFC5444].

[RFC7182] указывает, как помещать ICV в созданные сообщения, как проверять входящие сообщения и как отвергать «небезопасные» (т. е. сообщения без ICV или с ICV, которое невозможно проверить). Разные развертывания MANET могут в зависимости от целей использования требовать разных алгоритмов ICV и временных меток или ключей, поэтому защитные расширения могут применять любые из опций, представленных в [RFC7182].

23.3. Конфиденциальность

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

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

23.4. Взаимодействие с внешними доменами маршрутизации

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

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

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

23.5. Обязательные механизмы защиты

Соответствующая спецификации реализация OLSRv2 должна, как минимум, поддерживать механизмы, указанные в [RFC7183], для защиты целостности и предотвращения повторного использования управляющих сообщений OLSRv2, включая сообщения HELLO, указанные в [RFC6130] и используемые OLSRv2, путем включения TLV с временной меткой и ICV TLV. Эти ICV TLV используют HMAC на основе SHA-256 и один или множество управляемых вручную общих секретных ключей. TLV временный меток основаны на времени POSIX¹⁵, предполагающем синхронизацию часов в маршрутизаторах.

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

При любом развертывании OLSRv2 следует применять механизм защиты, указанный в [RFC7183], но можно использовать другой механизм, если он лучше подходит для среды OLSRv2. Например, при долгосрочном развертывании OLSRv2 следует рассмотреть дополнительные механизмы защиты (например, смену ключей).

23.6. Управление ключами

Эта спецификация и [RFC7183] не предписывают автоматизированное управление ключами (AKM¹⁶) как часть архитектуры защиты OLSRv2. Хотя в некоторых случаях OLSRv2 может требовать AKM, предполагается, что в большинстве случаев этого не требуется по описанным ниже причинам.

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

Широкое применение радиосетей и мобильных телефонов основано на предположениях о том, что (i) секретная информация встраивается в телефон производителем и (ii) централизованная база этой информации доступна в течение срока службы сети.

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

В [BCP107] даны рекомендации по управлению криптографическими ключами. В частности, параграф 2.1 задает условия, когда нужно использовать AKM, а в параграфе 2.2 указано, когда возможно ручное управление ключами.

В параграфе 2.1 [BCP107] сказано: «Автоматизированное управление ключами должно применяться при выполнении любого из [задан набор] условий». Эти условия приведены ниже с обоснованием их применимости для базового варианта развертывания OLSRv2.

• Участник должен поддерживать n² статических ключей, где значение n может быть велико.

  В базовом варианте OLSRv2 применяется один или несколько управляемых вручную общих секретов для всей MANET.

• Используется любой потоковый шифр (например, RC4 [RFC6229][RC4], AES-CTR [RFC3610][NIST-SP-800-38A], или AES-CCM [RFC3686][NIST-SP-800-38C]).

  Потоковый шифр не подходит для создания ICV в управляющих сообщениях OLSRv2.

• Вектор инициализации (IV¹⁷) может использоваться неоднократно (особенно неявный IV). Отметим, что случайные или псевдослучайные IV не создают проблемы при невысокой вероятности повторения.

  IV не подходит для создания ICV в управляющих сообщениях OLSRv2.

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

  ICV требуются только для управляющих сообщений OLSRv2 и объем данных невелик.

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

  Управляющие сообщения OLSRv2 передаются с использованием групповых адресов link-local.

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

  Это не является предусмотренным применением OLSRv2. Для долгосрочных систем OLSRv2 следует предусматривать дополнительные механизмы защиты (например, смену ключей).

В параграфе 2.2 [BCP107] сказано: «Ручное управление ключами может быть разумно в любой из [указан набор] ситуаций». Эти условия приведены ниже с обоснованием их применимости для базового варианта развертывания OLSRv2.

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

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

• Ценность защищаемой информации невысока.

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

• Общий объем трафика в течение времени действия долгосрочного ключа очень мал.

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

• Масштаб каждого развертывания очень ограничен.

  Типичный вариант OLSRv2 может включать десятки устройств и даже крупные системы OLSRv2 невелики по стандартам Internet.

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

Эта спецификация определяет один тип сообщений из реестра Message Types [RFC5444], 2 типа Message TLV из реестра Message TLV Types [RFC5444] и 4 типа Address Block TLV из реестра Address Block TLV Types [RFC5444].

24.1. Expert Review — рекомендации по оценке

Для реестров с политикой Expert Review назначенному эксперту следует учитывать общие рекомендации [RFC5444].

24.2. Типы сообщений

Эта спецификация определяет одно значение Message Type из диапазона 0-223 в пространстве имен Message Types, определенном [RFC5444], как показано в таблице 8.

Таблица 8. Выделение типов сообщений.

 

Тип	Описание
1	TC (Topology Control — контроль топологии) — сигнализация в масштабе MANET

 

24.3. Реестры специфических для типа сообщений типов TLV

Агентство IANA создало реестр для зависящих от типа сообщения Message TLV в сообщениях TC согласно параграфу 6.2.1 [RFC5444] с начальными значениями, приведенными в таблице 9.

Таблица 9. Типы специфических для типа сообщений TLV.

 

Тип	Описание	Политика назначения
128 — 223	Не распределены	Expert Review

 

Агентство IANA создало реестр для зависящих от типа сообщения Block TLV в сообщениях TC согласно параграфу 6.2.1 [RFC5444] с начальными значениями, приведенными в таблице 10.

Таблица 10. Типы специфических для типа сообщений Address Block TLV.

 

Тип	Описание	Политика назначения
128 — 223	Не распределены	Expert Review

 

24.4. Типы Message TLV

Эта спецификация определяет два типа Message TLV, значения которых выделены из пространства имен Message TLV Types, определенного в [RFC5444]. Агентство IANA выделило эти значения из диапазона 0-127. Были созданы два новых реестра расширений типов (Type Extension), начальные значения которых показаны в таблицах 11 и 12. Спецификации этих TLV приведены в параграфе 13.3.1. Любой из этих TLV недопустимо включать в Message TLV Block более одного раза.

Таблица 11. Распределение типов Message TLV — MPR_WILLING.

Имя	Тип	Расширение типа	Описание	Политика назначения
MPR_WILLING	7	0	Биты 0-3 указывают желание исходного маршрутизатора служить рассылающим MPR, биты 4-7 — маршрутизирующим MPR.
MPR_WILLING	7	1 — 255	Не распределены	Expert Review

Таблица 12. Распределение типов Message TLV — CONT_SEQ_NUM.

Имя	Тип	Расширение типа	Описание	Политика назначения
CONT_SEQ_NUM	8	0	COMPLETE — указывает порядковый номер для этого полного сообщения.
CONT_SEQ_NUM	8	1	INCOMPLETE — указывает порядковый номер для этого неполного сообщения.
CONT_SEQ_NUM	8	2 — 255	Не распределены	Expert Review

Для расширений типов с политикой Expert Review эксперту следует учитывать [RFC5444] в соответствии с процедурой Expert Review, определенной в [RFC5226].

24.5. Типы Address Block TLV

Эта спецификация определяет 4 типа Address Block TLV из пространства имен Address Block TLV Types, определенного в [RFC5444]. Агентство IANA выделило для них значения из диапазона 8-127. Созданы 4 новых реестра расширений типов (Type Extension), начальные значения которых приведены в таблицах 13 — 16. Спецификации этих TLV указаны в параграфе 13.3.2.

Для реестра LINK_METRIC Address Block TLV Type Extensions применяется процедура Expert Review.

Таблица 13. Распределение типов Address Block TLV — LINK_METRIC.

Имя	Тип	Расширение типа	Описание
LINK_METRIC	7	0	Метрика канала назначена административно
LINK_METRIC	7	1 — 223	Не распределены
LINK_METRIC	7	224 — 255	Резерв для экспериментов

Все LINK_METRIC TLV независимо от расширения типа должны использовать свое поле value для указания типа и значения (от MINIMUM_METRIC до MAXIMUM_METRIC, включительно) метрики канала, как указано в разделе 6 и параграфе 13.3.2. Назначение типов расширений LINK_METRIC TLV должно указывать физический смысл метрики канала и его отображение на значения указанного интервала.

Таблица 14. Распределение типов Address Block TLV — MPR.

Имя	Тип	Расширение типа	Описание	Политика назначения
MPR	8	0	Указывает, что данный сетевой адрес относится к маршрутизатору, выбранному рассылающим MPR (FLOODING = 1), маршрутизирующим MPR (ROUTING = 2) или обоими сразу (FLOOD_ROUTE = 3).
MPR	8	1 — 255	Не распределены	Expert Review

Таблица 15. Распределение типов Address Block TLV — NBR_ADDR_TYPE.

Имя	Тип	Расширение типа	Описание	Политика назначения
NBR_ADDR_TYPE	9	0	Указывает, что данный сетевой адрес относится к соседу, доступному через исходный маршрутизатор, если это адрес источника (ORIGINATOR = 1), маршрутизируемый адрес (ROUTABLE = 2) или то и другое вместе (ROUTABLE_ORIG = 3).
NBR_ADDR_TYPE	9	1 — 255	Не распределены	Expert Review

Таблица 16. Распределение типов Address Block TLV — GATEWAY.

Имя	Тип	Расширение типа	Описание	Политика назначения
GATEWAY	10	0	Указывает, что данный сетевой адрес доступен через шлюз на исходном маршрутизаторе со значением равным числу интервалов пересылки (hop).
GATEWAY	10	1 — 255	Не распределены	Expert Review

Для расширений типов с политикой Expert Review эксперту следует учитывать [RFC5444] в соответствии с процедурой Expert Review, определенной в [RFC5226].

24.6. Значения NBR_ADDR_TYPE и MPR

Примечание. Этот параграф не требует действий IANA, поскольку нужная информация включена в описания MPR и NBR_ADDR_TYPE Address Block TLV, выделенные в параграфе 24.5. Эта информация приведена здесь для ясности и использования в этой спецификации.

Ниже приведены поля Value, которые может использовать MPR Address Block TLV:

   FLOODING := 1;
   ROUTING := 2;
   FLOOD_ROUTE := 3.

Ниже приведены поля Value, которые может использовать NBR_ADDR_TYPE Address Block TLV:

   ORIGINATOR := 1;
   ROUTABLE := 2;
   ROUTABLE_ORIG := 3.

25. Разработчики документа

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

Cedric Adjih, INRIA, France, <Cedric.Adjih@inria.fr>
Emmanuel Baccelli, INRIA , France, <Emmanuel.Baccelli@inria.fr>
Thomas Heide Clausen, LIX, France, <T.Clausen@computer.org>
Justin Dean, NRL, USA, <jdean@itd.nrl.navy.mil>
Christopher Dearlove, BAE Systems, UK, <chris.dearlove@baesystems.com>
Ulrich Herberg, Fujitsu Laboratories of America, USA, <ulrich@herberg.name>
Satoh Hiroki, Hitachi SDL, Japan, <hiroki.satoh.yj@hitachi.com>
Philippe Jacquet, Alcatel Lucent Bell Labs, France, <philippe.jacquet@alcatel-lucent.fr>
Monden Kazuya, Hitachi SDL, Japan, <kazuya.monden.vw@hitachi.com>
Kenichi Mase, Niigata University, Japan, <mase@ie.niigata-u.ac.jp>
Ryuji Wakikawa, Toyota, Japan, <ryuji@sfc.wide.ad.jp>

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

Авторы благодарят команду людей за рамками OLSRv1, указанных в RFC 3626, включая Anis Laouiti (INT), Pascale Minet (INRIA), Paul Muhlethaler (INRIA), Amir Qayyum (M.A. Jinnah University), Laurent Viennot (INRIA) за вклад в работу.

Авторы благодарны за технические дискуссии, рецензии и комментарии к спецификации и ее компонентам Khaldoun Al Agha (LRI), Teco Boot (Infinity Networks), Ross Callon (Juniper), Song-Yean Cho (Samsung), Alan Cullen (BAE Systems), Louise Lamont (CRC), Li Li (CRC), Joseph Macker (NRL), Richard Ogier (SRI), Charles E. Perkins (Futurewei), Henning Rogge (Frauenhofer FKIE) (указаны в алфавитном порядке) и всю рабочую группу IETF MANET.

В заключение авторы хотели бы выразить свою признательность руководителям направлений за ценные комментарии в процессе оценки IESG, в частности, (по алфавиту) Benoit Claise, Adrian Farrel, Stephen Farrell, Barry Leiba, Pete Resnick, Martin Stiemerling.

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

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

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

[RFC5148] Clausen, T., Dearlove, C., and B. Adamson, «Jitter Considerations in Mobile Ad Hoc Networks (MANETs)», RFC 5148, February 2008.

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

[RFC5444] Clausen, T., Dearlove, C., Dean, J., and C. Adjih, «Generalized Mobile Ad Hoc Network (MANET) Packet/Message Format», RFC 5444, February 2009.

[RFC5497] Clausen, T. and C. Dearlove, «Representing Multi-Value Time in Mobile Ad Hoc Networks (MANETs)», RFC 5497, March 2009.

[RFC5498] Chakeres, I., «IANA Allocations for Mobile Ad Hoc Network (MANET) Protocols», RFC 5498, March 2009.

[RFC6130] Clausen, T., Dearlove, C., and J. Dean, «Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)», RFC 6130, April 2011.

[RFC7182] Herberg, U., Clausen, T., and C. Dearlove, «Integrity Check Value and Timestamp TLV Definitions for Mobile Ad Hoc Networks (MANETs)», RFC 7182, April 2014.

[RFC7183] Herberg, U., Dearlove, C., and T. Clausen, «Integrity Protection for the Neighborhood Discovery Protocol (NHDP) and Optimized Link State Routing Protocol Version 2 (OLSRv2)», RFC 7183, April 2014.

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

[BCP107] Bellovin, S. and R. Housley, «Guidelines for Cryptographic Key Management», BCP 107, RFC 4107, June 2005.

[FSLS] Santivanez, C., Ramanathan, R., and I. Stavrakakis, «Making Link-State Routing Scale for Ad Hoc Networks», MobiHoc ’01, Proceedings of the 2nd ACM International Symposium on Mobile Ad Hoc Networking & Computing, 2001.

[FSR] Pei, G., Gerla, M., and T. Chen, «Fisheye State Routing in Mobile Ad Hoc Networks», ICDCS Workshop on Wireless Networks and Mobile Computing, 2000.

[HIPERLAN] ETSI, «Radio Equipment and Systems (RES); High PErformance Radio Local Area Network (HIPERLAN) Type 1; Functional Specification», ETSI 300-652, June 1996.

[HIPERLAN2] Jacquet, P., Minet, P., Muhlethaler, P., and N. Rivierre, «Increasing Reliability in Cable-Free Radio LANs: Low Level Forwarding in HIPERLAN», Wireless Personal Communications, Volume 4, Issue 1, 1997.

[MPR] Qayyum, A., Viennot, L., and A. Laouiti, «Multipoint relaying: An efficient technique for flooding in mobile wireless Networks», INRIA, No. 3898, March 2000.

[McCabe] McCabe, A., Dearlove, C., Fredin, M., and L. Axelsson, «Scalability modelling of ad hoc routing protocols — a comparison of OLSR and DSR», Scandinavian Wireless Adhoc Networks ’04, 2004.

[NIST-SP-800-38A] National Institute of Standards and Technology, «Recommendation for Block Cipher Modes of Operation: Methods and Techniques», Special Publication 800-38A, December 2001.

[NIST-SP-800-38C] National Institute of Standards and Technology, «Recommendation for Block Cipher Modes of Operation: The CCM Mode for Authentication and Confidentiality», Special Publication 800-38C, May 2004.

[RC4] Schneier, B., «Applied Cryptography: Protocols, Algorithms, and Source Code in C», Second Edition, John Wiley and Sons, New York, 1996.

[RFC2501] Corson, M. and J. Macker, «Mobile Ad hoc Networking (MANET): Routing Protocol Performance Issues and Evaluation Considerations», RFC 2501, January 1999.

[RFC3610] Whiting, D., Housley, R., and N. Ferguson, «Counter with CBC-MAC (CCM)», RFC 3610, September 2003.

[RFC3626] Clausen, T. and P. Jacquet, «Optimized Link State Routing Protocol (OLSR)», RFC 3626, October 2003.

[RFC3686] Housley, R., «Using Advanced Encryption Standard (AES) Counter Mode With IPsec Encapsulating Security Payload (ESP)», RFC 3686, January 2004.

[RFC6229] Strombergson, J. and S. Josefsson, «Test Vectors for the Stream Cipher RC4», RFC 6229, May 2011.

Приложение A. Ограничения

Обновления Local Information Base, Neighborhood Information Base или Topology Information Base должны обеспечивать соблюдение всех ограничений, заданных этим приложением, а также [RFC6130]. Это вариант обработки, заданный в данном документе. Любое расширение протокола или внешний процесс, обновляющие Neighborhood Information Base или Topology Information Base, также должны соблюдать эти ограничения.

В каждом Originator Tuple:

• O_orig_addr недопустимо совпадать с любым другим O_orig_addr;

• O_orig_addr недопустимо совпадать с адресом источника для этого маршрутизатора.

В каждом Local Attached Network Tuple:

• AL_net_addr недопустимо совпадать с любым другим AL_net_addr;

• AL_net_addr недопустимо совпадать или быть поддиапазоном любого сетевого адреса в I_local_iface_addr_list любого Local Interface Tuple;

• AL_net_addr недопустимо быть адресом источника для этого маршрутизатора или O_orig_addr в любом Originator Tuple;

• AL_dist недопустимо быть меньше 0.

В каждом Link Tuple:

• L_neighbor_iface_addr_list недопустимо включать какой-либо сетевой адрес, совпадающий с AL_net_addr любого Local Attached Network Tuple или являющийся его поддиапазоном;

• Если L_in_metric != UNKNOWN_METRIC, значение L_in_metric должно должно быть представимо в определенной сжатой форме;

• Если L_out_metric != UNKNOWN_METRIC, значение L_out_metric должно должно быть представимо в определенной сжатой форме;

• Если L_mpr_selector = true, то L_status = SYMMETRIC.

В каждом Neighbor Tuple:

• N_orig_addr недопустимо менять на unknown;

• N_orig_addr недопустимо совпадать с адресом источника для этого маршрутизатора или O_orig_addr в любом Originator Tuple;

• N_orig_addr недопустимо совпадать с AL_net_addr в любом Local Attached Network Tuple;

• Если N_orig_addr != unknown, то N_orig_addr недопустимо быть N_orig_addr из любого другого Neighbor Tuple;

• N_neighbor_addr_list недопустимо содержать какой-либо сетевой адрес, который включает адрес источника для этого маршрутизатора, O_orig_addr из любого Originator Tuple, совпадать или быть частью AL_net_addr в любом Local Attached Network Tuple;

• Если N_orig_addr = unknown, то N_will_flooding = WILL_NEVER, N_will_routing = WILL_NEVER, N_flooding_mpr = false, N_routing_mpr = false, N_mpr_selector = false, N_advertised = false;

• N_in_metric должно совпадать с минимальным L_in_metric из всех соответствующих Link Tuple с L_status = SYMMETRIC и L_in_metric != UNKNOWN_METRIC (при наличии), иначе N_in_metric = UNKNOWN_METRIC;

• N_out_metric должно совпадать с минимальным L_out_metric из всех соответствующих Link Tuple с L_status = SYMMETRIC and L_out_metric != UNKNOWN_METRIC (при наличии), иначе N_out_metric = UNKNOWN_METRIC;

• N_will_flooding и N_will_routing должны быть из диапазона WILL_NEVER — WILL_ALWAYS, включительно;

• Если N_flooding_mpr = true, то N_symmetric должно быть true, N_out_metric недопустимо быть UNKNOWN_METRIC, а N_will_flooding недопустимо быть WILL_NEVER;

• If N_routing_mpr = true, то N_symmetric должно быть true, N_in_metric недопустимо быть UNKNOWN_METRIC, N_will_routing недопустимо быть WILL_NEVER;

• Если N_symmetric = true и N_flooding_mpr = false, то N_will_flooding недопустимо быть WILL_ALWAYS;

• Если N_symmetric = true и N_routing_mpr = false, то N_will_routing недопустимо быть WILL_ALWAYS;

• Если N_mpr_selector = true, то N_advertised должно быть true;

• Если N_advertised = true, то N_symmetric должно быть true, а N_out_metric недопустимо быть UNKNOWN_METRIC.

В каждом Lost Neighbor Tuple:

• NL_neighbor_addr недопустимо быть адресом источника для этого маршрутизатора, O_orig_addr любого другого Originator Tuple, адресом или частью AL_net_addr в любом Local Attached Network Tuple.

В каждом 2-Hop Tuple:

• N2_2hop_addr недопустимо быть адресом источника для этого маршрутизатора, O_orig_addr любого другого Originator Tuple, адресом или частью AL_net_addr в любом Local Attached Network Tuple;

• Если N2_in_metric != UNKNOWN_METRIC, значение N2_in_metric должно должно быть представимо в определенной сжатой форме;

• Если N2_out_metric != UNKNOWN_METRIC, значение N2_out_metric должно должно быть представимо в определенной сжатой форме.

В каждом Advertising Remote Router Tuple:

• AR_orig_addr недопустимо быть адресом из I_local_iface_addr_list с любом Local Interface Tuple или IR_local_iface_addr в любом Removed Interface Address Tuple;

• AR_orig_addr недопустимо быть адресом источника для этого маршрутизатора или O_orig_addr любого Originator Tuple;

• AR_orig_addr недопустимо быть AL_net_addr из любого Local Attached Network Tuple;

• AR_orig_addr недопустимо быть AR_orig_addr из любого другого Advertising Remote Router Tuple.

В каждом Router Topology Tuple:

• Должен быть Advertising Remote Router Tuple с AR_orig_addr = TR_from_orig_addr.

• TR_to_orig_addr недопустимо быть адресом из I_local_iface_addr_list с любом Local Interface Tuple или IR_local_iface_addr в любом Removed Interface Address Tuple;

• TR_to_orig_addr MUST NOT недопустимо быть адресом источника для этого маршрутизатора или O_orig_addr любого Originator Tuple;

• TR_to_orig_addr недопустимо быть AL_net_addr из любого Local Attached Network Tuple;

• Упорядоченной паре (TR_from_orig_addr, TR_to_orig_addr) недопустимо быть соответствующей парой любого другого Router Topology Tuple;

• TR_seq_number недопустимо быть больше AR_seq_number в Advertising Remote Router Tuple с AR_orig_addr = TR_from_orig_addr;

• Значение TR_metric должно должно быть представимо в определенной сжатой форме.

В каждом Routable Address Topology Tuple:

• Должен быть Advertising Remote Router Tuple с AR_orig_addr = TA_from_orig_addr;

• Адрес TA_dest_addr должен быть маршрутизируемым;

• TA_dest_addr недопустимо перекрываться с любым сетевым адресом из I_local_iface_addr_list в любом Local Interface Tuple или IR_local_iface_addr в любом Removed Interface Address Tuple;

• TA_dest_addr недопустимо включать адрес источника для этого маршрутизатора или O_orig_addr из любого Originator Tuple;

• TA_dest_addr недопустимо быть адресом или частью AL_net_addr любого Local Attached Network Tuple;

• Упорядоченной паре (TA_from_orig_addr, TA_dest_addr) недопустимо быть соответствующей парой любого другого Attached Network Tuple;

• TA_seq_number недопустимо быть больше AR_seq_number в Advertising Remote Router Tuple с AR_orig_addr = TA_from_orig_addr;

• Значение TA_metric должно должно быть представимо в определенной сжатой форме.

В каждом Attached Network Tuple:

• Должен быть Advertising Remote Router Tuple с AR_orig_addr = AN_orig_addr;

• AN_net_addr недопустимо быть адресом или частью любого сетевого адреса из I_local_iface_addr_list в любом Local Interface Tuple, адресом или частью IR_local_iface_addr в любом Removed Interface Address Tuple;

• AN_net_addr недопустимо быть адресом источника для этого маршрутизатора или O_orig_addr любого Originator Tuple;

• Упорядоченной паре (AN_orig_addr, AN_net_addr) недопустимо быть соответствующей парой любого другого Attached Network Tuple;

• AN_seq_number недопустимо быть больше AR_seq_number в Advertising Remote Router Tuple с AR_orig_addr = AN_orig_addr;

• AN_dist недопустимо быть меньше 0;

• Значение AN_metric должно должно быть представимо в определенной сжатой форме.

Приложение B. Пример алгоритма для расчета MPR

Ниже описан алгоритм, который можно применять для выбора MPR Set с учетом Neighbor Graph, как указано в параграфах 18.2 и 18.3.

Этот алгоритм выбирает MPR Set M, являющийся подмножеством набора N1, который является частью Neighbor Graph. Алгоритм предполагает, что подмножество I набора N1 заранее выбрано как MPR, т. е. M будет включать I.

B.1. Дополнительные обозначения

Ниже приведены дополнительные обозначения (см. параграф 18.2), используемые алгоритмом.

N

Подмножество N2, состоящее из элементов y в N2 таких, что либо d1(y) не определено, либо в N1 имеется хотя бы одно x, для которого определено d(x,y) и d(x,y) < d1(y).

D(x)

Для элемента x в N1 число элементов y в N, для которых d(x,y) определено и имеет минимальное значение среди d(z,y) для всех z в N1.

R(x,M)

Для элемента x в N1 число элементов y в N, для которых d(x,y) определено минимальным среди d(z,y) для всех z в N1 и ни одно из таких минимальных значений не имеет z в M (отметим, что обозначением пустого множества 0 будет D(x) = R(x,0)).

B.2. Алгоритм выбора MPR

Создание MPR Set M начинается с M := I.

1. В M добавляются все элементы x из N1, которые имеют W(x) = WILL_ALWAYS.

2. Для каждого y в N, имеющего лишь 1 элемент x в N1, такой, что d2(x,y) определено, x добавляется в M.

3. Пока в N1 имеются элементы x с R(x,M) > 0:

   1. выбирается элемент x из N1 с R(x,M) > 0 и добавляется к M в приведенном ниже порядке:

• • наибольшее W(x);

  • наибольшее R(x,M);

  • наибольшее D(x);

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

4. Необязательно. Рассмотрим каждый элемент x в M, не входящий в I. Если x можно удалить из M, оставив его соответствующим определению MPR Set, этот элемент x удаляется из M. Элементы можно рассматривать в любом порядке, например, по возрастанию W(x).

Приложение C. Пример алгоритма для расчета Routing Set

Описанная здесь процедура приведена в качестве примера расчета Routing Set с использованием варианта алгоритма Dijkstra. Сначала все Routing Tuple удаляются, а затем с помощью выбора и определений приложения C.1 применяются процедуры из последующих параграфов (каждый считается «этапом» обработки).

C.1. Локальные интерфейсы и соседи

Ниже перечислены принятые определения и варианты выбора.

1. Для каждого Local Interface Tuple выбирается сетевой адрес из его I_local_iface_addr_list.

2. Для каждого Link Tuple выбранный адрес из его соответствующего Local Interface Tuple определяется как выбранный локальный адрес для этого Link Tuple.

3. Для каждого Neighbor Tuple с N_symmetric = true и N_out_metric != UNKNOWN_METRIC выбирается Link Tuple с L_status = SYMMETRIC, для которого это соответствующий Neighbor Tuple и L_out_metric = N_out_metric. Это будет выбранный Link Tuple для данного Neighbor Tuple.

4. Для каждого сетевого адреса (N_orig_addr или из списка N_neighbor_addr_list, «адрес соседа») из Neighbor Tuple с N_symmetric = true и N_out_metric != UNKNOWN_METRIC выбирается Link Tuple («выбранный Link Tuple») из тех, для которых это соответствующий Neighbor Tuple, L_status = SYMMETRIC и L_out_metric = N_out_metric, как показано ниже.

   1. Если есть Link Tuple, где L_neighbor_iface_addr_list содержит адрес соседа, выбирается этот Link Tuple.

   2. В остальных случаях берется выбранный Link Tuple для этого Neighbor Tuple.

   Затем для этого сетевого адреса выполняются указанные ниже действия.

   1. Выбранный локальный адрес определяется как выбранный локальный адрес для выбранного Link Tuple.

   2. Выбранный адрес канала определяется как адрес из L_neighbor_iface_addr_list выбранного Link Tuple, по возможности совпадающий с этим соседним адресом.

5. Предпочтение Routing Tuple определяется предпочтением для минимального R_metric, затем для минимального R_dist, а затем для соответствующих Neighbor Tuple, как указано ниже.

• • • Большее значение N_will_routing.

    • N_mpr_selector = true предпочтительней N_mpr_selector = false.

Отметим, что использовать следует предпочтительные Routing Tuple. Должны использоваться Routing Tuple с минимальной метрикой R_metric MUST, это задано за пределами определения предпочтений. Реализация может изменить определение предпочтений (включая минимум для R_dist) без иного влияния на алгоритм.

C.2. Добавление соседних маршрутизаторов

Приведенная ниже процедура выполняется однократно.

1. Для каждого Neighbor Tuple с N_symmetric = true и N_out_metric != UNKNOWN_METRIC добавляется Routing Tuple с:

• • R_dest_addr := N_orig_addr;

  • R_next_iface_addr := выбранный адрес канала для N_orig_addr;

  • R_local_iface_addr := выбранный локальный адрес для N_orig_addr;

  • R_metric := N_out_metric;

  • R_dist := 1.

C.3. Добавление удаленных маршрутизаторов

Приведенная ниже процедура выполняется однократно.

1. Добавляется метка used (применяется) или unused (не применяется) к каждому Routing Tuple. Начальны значением является unused (эти метки нужны лишь для алгоритма).

2. Если нет неиспользуемых Routing Tuple, этап завершается, иначе выполняется указанное ниже.

   1. Находится неиспользуемый Routing Tuple с минимальной R_metric (при наличии нескольких выбирается любой) и помечается как текущий current Routing Tuple.

   2. Текущий Routing Tuple помечается как используемый (used).

   3. Для каждого Router Topology Tuple с TR_from_orig_addr = R_dest_addr из текущего Routing Tuple:

      1. определяется

• • new_metric := R_metric из текущего Routing Tuple + TR_metric;

  • new_dist := R_dist из текущего Routing Tuple + 1.

1. 1. 1. Если нет Routing Tuple с R_dest_addr = TR_to_orig_addr, создается неиспользуемый Routing Tuple с

• • R_dest_addr := TR_to_orig_addr;

  • R_next_iface_addr := R_next_iface_addr из текущего Routing Tuple;

  • R_local_iface_addr := R_local_iface_addr из текущего Routing Tuple;

  • R_metric := new_metric;

  • R_dist := new_dist.

1. 1. 1. В остальных случаях при наличии Routing Tuple с R_dest_addr = TR_to_orig_addr и new_metric < R_metric или new_metric = R_metric и обновленный Routing Tuple будут предпочтительней, обновляется Routing Tuple, как показано ниже

• • R_next_iface_addr := R_next_iface_addr из текущего Routing Tuple;

  • R_local_iface_addr := R_local_iface_addr из текущего Routing Tuple;

  • R_metric := new_metric;

  • R_dist := new_dist.

C.4. Добавление адресов соседей

Приведенная ниже процедура выполняется однократно.

1. Для каждого Neighbor Tuple с N_symmetric = true и N_out_metric != UNKNOWN_METRIC:

   1. Для каждого сетевого адреса («адрес соседа») в N_neighbor_addr_list при несовпадении адреса соседа с R_dest_addr из какого-либо Routing Tuple добавляется Routing Tuple

• • R_dest_addr := neighbor address;

  • R_next_iface_addr := выбранный адрес канала для адреса соседа;

  • R_local_iface_addr := выбранный локальный адрес для адреса соседа;

  • R_metric := N_out_metric;

  • R_dist := 1.

C.5. Добавление удаленных маршрутизируемых адресов

Приведенная ниже процедура выполняется однократно.

1. Для каждого Routable Address Topology Tuple при выполнении обоих приведенных ниже условий

• TA_dest_addr не совпадает с R_dest_addr ни одного из Routing Tuple, добавленных на предыдущих этапах;

• TA_from_orig_addr совпадает с R_dest_addr из Routing Tuple («предыдущий Routing Tuple»),

добавляется новый Routing Tuple с

• R_dest_addr := TA_dest_addr;

• R_next_iface_addr := R_next_iface_addr из предыдущего Routing Tuple;

• R_local_iface_addr := R_local_iface_addr из предыдущего Routing Tuple;

• R_metric := R_metric из предыдущего Routing Tuple + TA_metric;

• R_dist := R_dist из предыдущего Routing Tuple + 1.

Может существовать несколько Routing Tuple, которые могут быть добавлены для R_dest_addr на этом этапе. В таких случаях, для каждого такого R_dest_addr должен добавляться Routing Tuple с минимальной R_metric MUST, в остальных случаях следует добавлять предпочтительный Routing Tuple.

C.6. Добавление подключенных сетей

Приведенная ниже процедура выполняется однократно.

1. Для каждого Attached Network Tuple при выполнении обоих приведенных ниже условий

• • AN_net_addr не совпадает с R_dest_addr ни одного из Routing Tuple, добавленных на предыдущих этапах;

  • AN_orig_addr совпадает с R_dest_addr из Routing Tuple («предыдущий Routing Tuple»),

добавляется новый Routing Tuple с

• • R_dest_addr := AN_net_addr;

  • R_next_iface_addr := R_next_iface_addr из предыдущего Routing Tuple;

  • R_local_iface_addr := R_local_iface_addr из предыдущего Routing Tuple;

  • R_metric := R_metric из предыдущего Routing Tuple + AN_metric;

  • R_dist := R_dist из предыдущего Routing Tuple + AN_dist.

Может существовать несколько Routing Tuple, которые могут быть добавлены для R_dest_addr на этом этапе. В таких случаях, для каждого такого R_dest_addr должен добавляться Routing Tuple с минимальной R_metric MUST, в остальных случаях следует добавлять предпочтительный Routing Tuple.

C.7. Добавление соседей 2-Hop

Описанная ниже процедура необязательна в соответствии с параграфом 19.1 и может быть выполнена один раз.

1. Для каждого 2-Hop Tuple с N2_out_metric != UNKNOWN_METRIC при выполнении всех приведенных условий

• • • N2_2hop_addr является маршрутизируемым адресом;

    • N2_2hop_addr не совпадает с R_dest_addr ни одного из Routing Tuple, добавленных на предыдущих этапах;

    • Routing Tuple с R_dest_addr = N_orig_addr соответствующего Neighbor Tuple («предыдущий Routing Tuple») имеет R_dist = 1,

добавляется новый Routing Tuple с

• • R_dest_addr := N2_2hop_addr;

  • R_next_iface_addr := R_next_iface_addr из предыдущего Routing Tuple;

  • R_local_iface_addr := R_local_iface_addr из предыдущего Routing Tuple;

  • R_metric := R_metric из предыдущего Routing Tuple + N_out_metric из соответствующего Neighbor Tuple;

  • R_dist := 2.

Может существовать несколько Routing Tuple, которые могут быть добавлены для R_dest_addr на этом этапе. В таких случаях, для каждого такого R_dest_addr должен добавляться Routing Tuple с минимальной R_metric MUST, в остальных случаях следует добавлять предпочтительный Routing Tuple.

Приложение D. Пример сообщения TC

Сообщения TC являются экземплярами сообщений [RFC5444]. Эта спецификация требует наличия в TC полей <msg-hop-limit> и <msg-orig-addr>. Поддерживаются сообщения TC с любой комбинацией оставшихся опций заголовка сообщения и кодирования адресов, разрешенных [RFC5444], которые переносят нужную информацию. В результате этого не существует способа представить, как выглядят все сообщения TC. Это приложение служит иллюстрацией сообщения TC. Точные значения полей приведены и разъяснены в тексте.

В TC 4-битовое поле флагов (Message Flags — MF) имеет значение 15, указывающее, что заголовок сообщения содержит адрес инициатора, ограничение числа интервалов и порядковый номер сообщения. 4-битовое поле размера адреса (Message Address Length — MAL) имеет значение 3, указывающее, что адреса в сообщении имеют размер 4 октета (в данном случае это IPv4). Общий размер сообщения составляет 75 октетов.

Сообщение имеет Message TLV Block с размером содержимого 17 октетов, включающий 4 TLV. Первые два TLV указывают срок действия и интервал времени для сообщения. Третий TLV указывает порядковый номер и передает 2 октета ANSN и (с нулевым типом расширения по умолчанию — COMPLETE) указывает полноту сообщения TC. Четвертый TLV указывает намерения исходного маршрутизатора в части пересылки и маршрутизации (FWILL и RWILL, соответственно). Каждый блок TLV использует октет флагов (MTLVF) со значением 16, указывающим наличие Value, и отсутствие расширения типа или индексов начала и завершения. Первые 2 TLV имеют Value Length в 1 октет, остальные — 2.

Сообщение имеет два Address Block (это необязательно — информацию можно передать в одном Address Block, использование двух, что тоже разрешено, выбрано для иллюстрации). Первый Address Block содержит 3 адреса с октетом флагов (ABF) 128, поэтому включает раздел Head (2 октета), но не имеет раздела Tail, а разделы Mid имеют размер по 2 октета. Следующий TLV Block (13 октетов) содержит 2 TLV. Первым является NBR_ADDR_TYPE TLV с октетом флагов (ATLVF) 16, оказывающим одно поле Value без индексов. Таким образом, все эти адреса связаны с Value (Value Length = 1) ROUTABLE_ORIG, т. е. являются адресами инициатора анонсов соседей, которые также являются маршрутизируемыми. Вторым является LINK_METRIC TLV с октетом флагов (ATLVF) 20, указывающим Value для каждого адреса, т. е. общий размер Value Length = 6 октетов и каждый адрес, связанный с Value, имеет размер 2 октета. Эти поля Value показаны как имеющие 4 бита, указывающие, что они являются значениями метрики исходящих соседей и имеют 12 битов со значением метрики (первые 4 бита — показатель степени, остальные 8 — мантисса).

Второй Address Block содержит 1 адрес с октетом флагов (ATLVF) 176, указывающим наличие раздела Head (2 октета), разделом Tail (2 октета) со значениями 0 (не включены) и наличие размера префикса 16. Сетевой адрес в результате будет иметь вид Head.0.0/16. Следующий TLV Block (9 октетов содержимого) включает 2 TLV. Первый имеет октет флагов (ATLVF) 16, снова указывающий ненужность индексов, но с наличием поля Value (Value Length = 1), указывающего удаленность адреса числом интервалов (hop). Вторым является LINK_METRIC TLV, как в первом Address TLV Block, но с октетом флагов (ATLVF) 16, указывающим наличие одного поля Value.

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |      TC       | MF=15 | MAL=3 |      Message Length = 75      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                      Originator Address                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Hop Limit   |   Hop Count   |    Message Sequence Number    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Message TLV Block Length = 17 | VALIDITY_TIME |  MTLVF = 16   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Value Len = 1 | Value (Time)  | INTERVAL_TIME |  MTLVF = 16   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Value Len = 1 | Value (Time)  | CONT_SEQ_NUM  |  MTLVF = 16   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Value Len = 2 |         Value (ANSN)          |  MPR_WILLING  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  MTLVF = 16   | Value Len = 1 | FWILL | RWILL | Num Addrs = 3 |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   ABF = 128   | Head Len = 2  |             Head              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |              Mid              |              Mid              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |              Mid              | Address TLV Block Length = 13 |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | NBR_ADDR_TYPE |  ATLVF = 16   | Value Len = 1 | ROUTABLE_ORIG |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  LINK_METRIC  |  ATLVF = 20   | Value Len = 6 |0|0|0|1|Metric |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Metric (cont) |0|0|0|1|        Metric         |0|0|0|1|Metric |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Metric (cont) | Num Addrs = 1 |   ABF = 176   | Head Len = 2  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |             Head              | Tail Len = 2  | Pref Len = 16 |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Address TLV Block Length = 9  |    GATEWAY    |  ATLVF = 16   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Value Len = 1 | Value (Hops)  |  LINK_METRIC  |  ATLVF = 16   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Value Len = 2 |0|0|0|1|        Metric         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Приложение E. Управление потоком и контроль перегрузок

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

Этот протокол применяет [RFC6130] для локальной сигнализации, встраивая анонсы выбора MPR через простой Address Block TLV и анонсы намерений маршрутизатора (при наличии) как один блок Message TLV. Поэтому локальная сигнализации имеет характеристики и ограничения, описанные в [RFC6130].

Кроме того, применение MPR может существенно снизить издержки на сигнализацию за счет распространения информации о состоянии каналов двумя способами, снижающими объем лавинной рассылки и топологических данных. Во-первых, при использовании лавинной рассылки MPR затраты на распространение информации о состоянии каналов по сети снижаются по сравнению с лавинной рассылкой «вслепую», поскольку сообщения о состоянии каналов передают лишь маршрутизаторы MPR. Во-вторых, снижается объем информации, которую маршрутизатор должен объявлять, — это лишь селекторы MPR данного маршрутизатора. Это снижает объем объявлений о состоянии каналов по сравнению с полной информацией о состоянии каналов. В частности, некоторым маршрутизаторам не нужно декларировать такую информацию. В плотных сетях снижение объема управляющего трафика может составлять несколько порядков по сравнению с протоколами маршрутизации, использующими лавинную рассылку вслепую [MPR]. Это свойство обеспечивает расширение полосы, доступной для трафика данных и снижает уровень насыщения сети.

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

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

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

Thomas Heide Clausen

LIX, Ecole Polytechnique

Phone: +33 6 6058 9349

EMail: T.Clausen@computer.org

URI: http://www.ThomasClausen.org/

Christopher Dearlove

BAE Systems Advanced Technology Centre

West Hanningfield Road

Great Baddow, Chelmsford

United Kingdom

Phone: +44 1245 242194

EMail: chris.dearlove@baesystems.com

URI: http://www.baesystems.com/

Philippe Jacquet

Alcatel-Lucent Bell Labs

Phone: +33 6 7337 1880

EMail: philippe.jacquet@alcatel-lucent.com

Ulrich Herberg

Fujitsu Laboratories of America

1240 E. Arques Ave.

Sunnyvale, CA 94085

USA

EMail: ulrich@herberg.name

URI: http://www.herberg.name/

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

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

nmalykh@gmail.com

Internet Engineering Task Force (IETF)                      M. Boucadair
Request for Comments: 7149                                  C. Jacquenet
Category: Informational                                   France Telecom
ISSN: 2070-1721                                               March 2014

Программно-определяемые сети с точки зрения сервис-провайдеров

Software-Defined Networking: A Perspective from within a Service Provider Environment

PDF

Аннотация

Программно-определяемые сети (SDN¹) в течение нескольких последних лет были одним из наиболее обсуждаемых вопросов в сетевой индустрии. Тем не менее четкого и общепринятого определения SDN до сих пор не дано. Этот документ пытается описать «ландшафт» SDN, указав требования, проблемы и другие связанные с SDN вопросы с точки зрения поставщиков сетевых услуг.

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

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

Этот документ не является спецификацией стандарта Internet и публикуется с информационными целями.

Документ является результатом работы IETF² и представляет согласованное мнение сообщества IETF. Документ был вынесен на открытое обсуждение и одобрен для публикации IESG³. Не все документы, одобренные IESG, претендуют на статус стандарта Internet (см. раздел 2 документа RFC 5741).

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

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

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

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

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

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

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

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

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

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

2. Введение SDN

2.1. Тавтология?

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

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

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

2.2. Гибкость

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

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

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

С учетом довольно широкой области применения термина «гибкость» следует отметить приведенные ниже аспекты.

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

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

2.3. Предварительное определение

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

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

Такое определение предполагает внедрение высокого уровня автоматизации процедур предоставления услуг и сетевых операций. Поскольку сетевое взаимодействие по своей природе управляется программным путем, приведенное выше определение не выделяет «программно-определяемых» свойств решений SDN.

2.4. Функциональные метадомены

Методы SDN можно классифицировать по перечисленным ниже функциональным метадоменам.

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

• Демонстрация сетевых услуг и их характеристик, а также динамическое согласование набора параметров сервиса, которые будут служить для измерения качества, связанного с предоставлением услуги или набора услуг. Примером может служить [CPP].

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

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

3. Реальность

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

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

3.1. Помним о прошлом

Методы SDN — это не следующий большой шаг вперед, а скорее пересмотр предложений, которые исследовались в течение нескольких лет, таких как активные или программируемые сети [AN] [PN]. Фактически, некоторые из объявленных «новыми» функций SDN уже были реализованы (например, NMS⁶ и PCE⁷ [RFC4655]) и поддерживаются производителями в течение достаточно долгого времени.

Некоторые из этих функций были стандартизованы (например, маршрутизация на основе DNS [RFC1383]), что можно считать иллюстрацией разделения уровней управления и пересылки или ForCES⁸ [RFC5810] [RFC5812].

Кроме того, модель сетевого управления на основе правил [RFC2753], предложенная в начале 2000-х годов, была разработана для организации доступных ресурсов с помощью PDP⁹, которые управляют расширенными возможностями автономного (offline) построения трафика. Эта модель может взаимодействовать с программными модулями, встроенными в управляемые устройства, по основному каналу (in-band).

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

В точках PEP исполняются решения политики. PEP встраиваются в (сетевые) устройства, которые динамически настраиваются на основе данных в формате политики, которые обрабатываются в PEP. Точки PEP запрашивают конфигурацию у PDP, сохраняя данные конфигурации в базе PIB¹¹ и делегируя принятие решений точкам PDP.

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

3.2. Будем прагматичными

Подходы SDN должны быть целостными в глобальном и сетевом масштабе. Речь не идет о настройке устройств одного за другим для исполнения конкретной политики пересылки. Вместо этого методы SDN нацелены на настройку и работу целого ряда устройств в масштабе сети для автоматизированного предоставления услуг [AUTOMATION] от согласования (например, [CPNP]) и организации (например, [SLA-EXCHANGE]) услуги до ее заверения и исполнения.

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

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

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

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

3.3. Сравнение результатов с ожиданиями

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

Этим типичным методам, основанным на правилах, следует взаимодействовать как с машинами структурирования услуг (которые предназначены для демонстрации и, возможно, согласования характеристик услуг), так и с сетью для постоянной оценки соответствия поведения сети целям, заданным механизмом структурирования услуг, и целям, которые могут динамически согласовываться с клиентом (например, как указано в CPP [CPP] [CPNP]). Это требование применимо к нескольким участкам сети, включая перечисленные ниже.

1. Интерфейс между двумя смежными провайдерами сетей IP.

2. Интерфейс доступа между сервис-провайдером и провайдером сети IP.

3. Интерфейс между абонентом и провайдером сети IP.

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

3.4. Проектируем осторожно

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

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

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

Следует избегать или хотя бы тщательно продумывать внедрение новых функций и устройств, которые могут поставить под угрозу гибкость сетей, в свете возможного влияния на производительность и расширяемость. Устройства с поддержкой SDN должны сосуществовать с унаследованными системами.

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

3.5. OpenFlow

Расширение возможностей сетей с управляемыми по основному каналу модулями может опираться на протокол OpenFlow или иные протоколы обмена информацией между уровнями управления и данных.

Действительно, имеется много протоколов, которые можно применить для решения этих и более широких (например, резервирование ресурсов) задач. Пересылка конфигурационной информации, например, может быть реализована на основе таких протоколов как PCEP¹² [RFC5440], NETCONF¹³ [RFC6241], COPS-PR¹⁴ [RFC3084], RPSL¹⁵ [RFC2622] и т. п.

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

3.6. Дополнительные соображения

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

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

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

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

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

4. Обсуждение

4.1. Влияние полной автоматизации

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

• Автоматизация должна быть хорошо реализована для облегчения тестирования (включая проверки пригодности) и поиска неполадок.

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

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

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

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

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

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

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

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

  • Представление услуг связности IP для пользователей, партнеров, приложений, поставщиков услуг и содержимого и т. п. (пример можно найти в [CPP]).

  • Решения, согласующие требования связности IP с целями проектирования сетей.

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

• Эффективное согласование технологически разнородных сетевых сред за счет указанных ниже мер.

  • Независимые от производителей процедуры настройки, основанные на исполнении не связанных с производителями правил вместо заданных производителями языков.

  • Средства упрощения процедур управления и оркестровки ресурсов.

  • Исключение промежуточных устройств и прямое взаимодействие с системами (например, маршрутизации и пересылки).

4.2. Загрузка SDN

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

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

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

Методы SDN (как отмечено в параграфе 2.4) могут быть развернуты в среде без поддержки протоколов IGP и BGP, но процедура начальной загрузки SDN в такой среде предполагает поддержку перечисленных ниже возможностей.

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

• Динамическое подключение PDP к участвующим узлам с предотвращением петель.

• Динамическое включение сетевых услуг в зависимости от возможностей устройства и (возможно) динамического согласования между сервис-провайдером и абонентом.

• Динамическая проверка связности между PDP и участвующими узлами для предоставления данной сетевой услуги (или набора услуг).

• Динамическая оценка области доступности как функции предоставляемой услуги.

• Динамическое обнаружение и диагностика отказов, а также принятие соответствующих мер.

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

Таким образом, в средах без IGP и BGP может потребоваться специальный протокол начальной загрузки для поддержки упомянутых возможностей и корректной работы устройств с поддержкой PDP и SDN в дополнение к возможной потребности в дополнительной сети, которая будет обеспечивать функции обнаружения и связности.

В частности, организация и работа SDN в средах без IGP и BGP должны обеспечивать производительность, аналогичную характеристикам унаследованных сред, где используются протоколы IGP и BGP. Например, базовой сети следует сохранять работоспособность даже при потере соединения с PDP. Кроме того, операторам следует оценить стоимость внедрения нового протокола начальной загрузки по сравнению с интеграцией упомянутых возможностей с имеющимися механизмами протоколов IGP и BGP.

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

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

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

4.3. Работа SDN

С точки зрения OAM¹⁶ [RFC6291] при работе сети с поддержкой SDN возникает несколько вопросов, приведенных ниже.

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

• Что подходит в качестве инструментов OAM для работы в сети SDN (например, для проверки доступности PDP или PEP)?

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

• До какой степени реализация SDN упрощает управление сетью, включая диагностику сети и служб?

• Следует применять принцип разделения уровней управления и данных к сети или ее части в зависимости от природы предоставляемых услуг или с учетом развернутой в настоящее время технологии?

• Каково влияние на процедуры и методологию тестирования у сервис-провайдеров (проверка пригодности и подготовка к развертыванию)? В частности, (1) как будут определяться и выполняться тестовые сценарии при активации настраиваемых модулей, (2) какова методология оценки поведения управляемых SDN устройств, (3) как выполняется выход из тестового сценария (4) и т. п.

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

• Возникает ли риск «замораживания» архитектуры в результате возможных проблем при взаимодействии между управляемыми устройствами и контроллером SDN?

• Как внедрение методов SDN влияет на срок службы унаследованных систем? Возникает ли риск (быстрого) устаревания имеющихся технологий по причине их программных или аппаратных ограничений?

Ответы на эти вопросы скорей всего будут разными у каждого сервис-провайдера в зависимости от технологии и требований бизнеса.

4.4. Интеллект остается в PDP

Предложенное в параграфе 2.3 определение SDN предполагает, что интеллект сохраняется на уровне управления или администрирования (или в обоих). Этот интеллект обычно представляется точками принятия решений (PDP) [RFC2753], которые являются одной из важных компонент модели управления на основе правил.

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

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

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

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

4.5. Простота и адаптивность против сложности

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

Удовлетворение потребностей в простоте и адаптируемости за счет автоматизации процедур обычно приводит к усложнению автоматизации.

4.6. Производительность и расширяемость

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

Например, сети ЦОД¹⁷, реализованные на коммутаторах OpenFlow, вряд ли столкнуться с проблемами расширяемости FIB. И напротив, соединения между ЦОД, нацеленные на динамическое управление мобильностью виртуальных машин (VM¹⁸), возможно на основе определенных правил QoS, могут столкнуться с проблемами расширяемости.

Заявленная гибкость сетей SDN в таком контексте требует тщательного изучения со стороны операторов.

4.7. Оценка рисков

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

• Зависимость от технологии контроллера вместо зависимости от технологии устройств.

• Возможность «замораживания» системы в результате проблем взаимодействия устройств с контроллером.

• Старение решений SDN в результате программных и аппаратных ограничений. С технической точки зрения возможность динамического предоставления ресурсов в зависимости от предоставляемых услуг может оказаться несовместимой с унаследованными системами маршрутизации, например, в результате их аппаратных ограничений. С экономической точки зрения применение решений SDN для обеспечения гибкости и автоматизации может существенно увеличить капитальные (CAPEX¹⁹) и операционные (OPEX²⁰) расходы.

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

Безопасность является важным аспектом любой системы SDN, поскольку она обеспечивает надежность и отказоустойчивость взаимодействий между сетью и приложениями для эффективного контроля доступа и оптимизированной защиты ресурсов SDN от атак любого типа. В частности, политике безопасности SDN [SDNSEC] следует обеспечивать надлежащую защиту ресурсов SDN от действий, способных угрожать работе сети или приложений.

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

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

Взаимодействия между PEP и PDP предполагают необходимость проверить, что (1) PDP имеет право запрашивать у PEP исполнения принятых PDP решений, (2) PEP имеет право передавать запросы PDP (дополнительные данные конфигурации, уведомление по результатам настройки и т. п.), (3) PEP может воспринимать решения PDP и (4) связь между PDP внутри домена или между доменами надежно защищена (например, каждой точке PDP разрешено взаимодействие с партнером и обеспечивается конфиденциальность данных при обмене между PDP).

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

Большое спасибо R. Barnes, S. Bryant, S. Dawkins, A. Farrel, S. Farrell, W. George, J. Halpern, D. King, J. Hadi Salim и T. Tsou за их комментарии. Отдельная благодарность P. Georgatos за плодотворные дискуссии по соединениям SDNI²¹.

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

[AN] Tennenhouse, D. and D. Wetherall, «Towards an Active Network Architecture«, Multimedia Computing and Networking (MMCN), January 1996.

[AUTOMATION] Boucadair, M. and C. Jacquenet, «Requirements for Automated (Configuration) Management», Work in Progress, January 2014.

[CPNP] Boucadair, M. and C. Jacquenet, «Connectivity Provisioning Negotiation Protocol (CPNP)», Work in Progress, October 2013.

[CPP] Boucadair, M., Jacquenet, C., and N. Wang, «IP/MPLS Connectivity Provisioning Profile», Work in Progress²², September 2012.

[LS-DISTRIB] Gredler, H., Medved, J., Previdi, S., Farrel, A., and S. Ray, «North-Bound Distribution of Link-State and TE Information using BGP», Work in Progress²³, November 2013.

[PN] Campbell, A., De Meer, H., Kounavis, M., Kazuho, M., Vincente, J., and D. Villela, «A Survey of Programmable Networks«, ACM SIGCOMM Computer Communication Review, April 1999.

[RFC1383] Huitema, C., «An Experiment in DNS Based IP Routing», RFC 1383, December 1992.

[RFC2622] Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D., Meyer, D., Bates, T., Karrenberg, D., and M. Terpstra, «Routing Policy Specification Language (RPSL)», RFC 2622, June 1999.

[RFC2753] Yavatkar, R., Pendarakis, D., and R. Guerin, «A Framework for Policy-based Admission Control», RFC 2753, January 2000.

[RFC3084] Chan, K., Seligson, J., Durham, D., Gai, S., McCloghrie, K., Herzog, S., Reichmeyer, F., Yavatkar, R., and A. Smith, «COPS Usage for Policy Provisioning (COPS-PR)», RFC 3084, March 2001.

[RFC4655] Farrel, A., Vasseur, J., and J. Ash, «A Path Computation Element (PCE)-Based Architecture», RFC 4655, August 2006.

[RFC5440] Vasseur, JP. and JL. Le Roux, «Path Computation Element (PCE) Communication Protocol (PCEP)», RFC 5440, March 2009.

[RFC5810] Doria, A., Hadi Salim, J., Haas, R., Khosravi, H., Wang, W., Dong, L., Gopal, R., and J. Halpern, «Forwarding and Control Element Separation (ForCES) Protocol Specification», RFC 5810, March 2010.

[RFC5812] Halpern, J. and J. Hadi Salim, «Forwarding and Control Element Separation (ForCES) Forwarding Element Model», RFC 5812, March 2010.

[RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. Bierman, «Network Configuration Protocol (NETCONF)», RFC 6241, June 2011.

[RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu, D., and S. Mansfield, «Guidelines for the Use of the «OAM» Acronym in the IETF», BCP 161, RFC 6291, June 2011.

[SDNSEC] Hartman, S. and D. Zhang, «Security Requirements in the Software Defined Networking Model», Work in Progress, April 2013.

[SLA-EXCHANGE] Shah, S., Patel, K., Bajaj, S., Tomotaki, L., and M. Boucadair, «Inter-domain SLA Exchange», Work in Progress, November 2013.

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

Mohamed Boucadair

France Telecom

Rennes 35000

France

EMail: mohamed.boucadair@orange.com

Christian Jacquenet

France Telecom

Rennes

France

EMail: christian.jacquenet@orange.com

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

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

nmalykh@gmail.com

Заменен RFC 7159

Заменен RFC 8259.