RFC 6130 Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)

Internet Engineering Task Force (IETF)                        T. Clausen
Request for Comments: 6130                      LIX, Ecole Polytechnique
Category: Standards Track                                    C. Dearlove
ISSN: 2070-1721                                          BAE Systems ATC
                                                                 J. Dean
                                               Naval Research Laboratory
                                                              April 2011

Протокол обнаружения соседей (NHDP) для сетей MANET

Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)

PDF

Аннотация

Этот документ описывает протокол обнаружения соседей NHDP¹, отделенных одним или двумя (симметрично) интервалами маршрутизации, для мобильных сетей MANET².

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

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

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

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

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

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

В этом документе описан протокол обнаружения соседей NHDP для мобильных сетей MANET [RFC2501]. Этот протокол использует локальный обмен сообщениями HELLO, позволяющий любому маршрутизатору определить наличие и связность с ближайшими соседями (1-hop) и соседями второго уровня с симметричным соединением (symmetric 2-hop). Сообщения определяются и передаются в пакетах в соответствии со спецификацией [RFC5444].

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

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

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

Данный протокол основан на процессе обнаружения соседей из протокола OLSR⁵ [RFC3626].

1.1. Мотивация

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

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

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

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

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

Протоколы маршрутизации MANET (например, [RFC3626] и [RFC5449]) часто используют сокращение множества используемых трансляторов в целях экономии «емкости» сети, расходуемой на поддержку топологической информации о сети в целом, при этом сокращенный набор трансляторов включает информацию вплоть до двух интервалов маршрутизации (hop).

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

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

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

Все термины, введенные в [RFC5444], включая packet, message, Address Block, TLV Block, TLV, address, address prefix, address object, интерпретируются в соответствии с этим документом.

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

Network Address – адрес сети

Адрес и связанный с ним размер префикса. Это может быть адрес с максимальным размером префикса или адрес, включающий связанный с ним размер префикса. Таким образом, этот параметр (network address) представляет диапазон адресов.

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

Маршрутизатор MANET, поддерживающий описанный здесь протокол обнаружения соседей.

Interface – интерфейс

Подключение маршрутизатора к среде передачи. Интерфейсу присваивается один или множество адресов.

MANET interface – интерфейс MANET

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

Heard – слышимость

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

Link – соединение

Соединение между двумя интерфейсами MANET существует, если любой из них может слышать другого.

Symmetric link – симметричное соединение

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

1-hop neighbor – ближайший сосед

Маршрутизатор X является ближайшим соседом (1-hop neighbor) маршрутизатора Y, если интерфейс MANET в маршрутизаторе X слышен интерфейсу MANET в маршрутизаторе Y.

Symmetric 1-hop neighbor – ближайший сосед с симметричным соединением

Маршрутизатор X является ближайшим соседом с симметричным соединением (symmetric 1-hop neighbor) для маршрутизатора Y, если имеется симметричное соединение между интерфейсами MANET маршрутизаторов X и Y.

2-hop neighbor – сосед, следующий за ближайшим (сосед второго уровня)

Маршрутизатор X является соседом второго уровня (2-hop neighbor) для маршрутизатора Y, если X является ближайшим соседом ближайшего соседа маршрутизатора Y, но не самого маршрутизатора Y.

Symmetric 2-hop neighbor – сосед второго уровня с симметричным соединением

маршрутизатор X является соседом второго уровня с симметричным соединением для маршрутизатора Y, если X является ближайшим соседом с симметричным соединением для ближайшего соседа Y с симметричным соединением, но не для самого маршрутизатора Y.

1-hop neighborhood – ближайшая окрестность

Ближайшая окрестность маршрутизатора X – это множество ближайших соседей маршрутизатора X.

Symmetric 1-hop neighborhood – ближайшая окрестность с симметричным соединением

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

2-hop neighborhood – окрестность второго уровня

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

Symmetric 2-hop neighborhood – окрестность второго уровня с симметричным соединением

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

Constant – константа

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

Interface parameter – параметр интерфейса

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

Router parameter – параметр маршрутизатора

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

Information Base – информационная база

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

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

X contains y, or y is contained in X – X содержит y или y содержится в X

Оператор принадлежности к неупорядоченному списку. X является неупорядоченным списком, а y – его элементом. Выражения «X содержит y» или «y содержится X» возвращают значение true (истина), если список X включает элемент y, и false – в противном случае.

X contains Y, or Y is contained in X – X содержит Y или Y содержится в X

Оператор включения в неупорядоченный список. X и Y являются неупорядоченными списками. Выражения «X содержит Y» и «Y содержится в X» возвращают значение true (истина), если список X содержит все элементы y из списка Y и false – в противном случае.

A overlaps B – A перекрывается с B

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

a := b

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

c = d

Оператор сравнения, возвращающий значение true (истина), если значение левой части (c) равно значению правой части (d). c и d могут быть просто величинами, адресами сетей или неупорядоченными списками (они должны быть одного типа). Если c и d – неупорядоченные списки, они считаются равными, если c содержит d и d содержит c (т. е., оба списка включают одинаковые наборы элементов без учета порядка их размещения в списках). Если c и d – адреса сетей, они считаются равными при совпадении адресов и размеров префиксов.

e != f

Оператор сравнения, возвращающий значение not (e = f), т. е. true, если (e = f) возвращает false и false, если (e = f) возвращает true.

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

Данный протокол:

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

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

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

• обеспечивает каждому маршрутизатору локальную топологическую информацию на удалении до двух интервалов (hop) и делает ее доступной для протоколов маршрутизации MANET через информационные базы;

• использует форматы пакетов и сообщений, заданные в [RFC5444], включая определение типа сообщения HELLO, используемого для передачи сведений о локальной топологии;

• обеспечивает возможность «внутренних» и «внешних» расширений, разрешенную [RFC5444];

• может взаимодействовать с другими протоколами (например, протоколами маршрутизации MANET, описанными у разделе 16) и расширяться с их помощью;

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

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

4. Обзор работы протокола

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

• идентификация ближайших соседей (1-hop neighbor) и ближайших соседей с симметричным соединением;

• нахождение адресов сетей для интерфейсов соседей второго уровня с симметричным соединением;

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

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

Эти цели достигаются за счет использования локальной (1 интервал) сигнализации, которая:

• анонсирует присутствие маршрутизатора и адреса сетей для его интерфейсов;

• обнаруживает соединения с соседними маршрутизаторами;

• выполняет проверки двухсторонней связи на обнаруженных соединениях;

• анонсирует обнаруженные соединения и их симметрию/асимметрию своим ближайшим соседям, обнаруживая тем самым соседей второго уровня с симметричным соединением.

Данная спецификация определяет:

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

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

• Формат сообщений HELLO, используемых для локальной сигнализации.

• Генерацию сообщений HELLO из части информации в базах.

• Обновление информационных баз в соответствии с полученными сообщениями HELLO и другими событиями.

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

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

Для участия маршрутизатора в работе сети MANET он должен иметь хотя бы один интерфейс MANET.

Ниже перечислены свойства интерфейсов MANET.

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

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

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

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

• Интерфейс имеет базу Interface Information Base с данными, относящимися к каналам на данный интерфейс MANET и соседям второго уровня с симметричным соединением, которые доступны через этот интерфейс.

• Интерфейс генерирует и обрабатывает сообщения HELLO.

В дополнение к набору описанных выше интерфейсов MANET каждый маршрутизатор имеет базы:

• Local Information Base с адресами сетей для интерфейсов (MANET и не-MANET) данного маршрутизатора; содержимое этой базы не меняется с помощью сигнализации;

• Neighbor Information Base с данными об имеющихся и недавно утраченных ближайших соседях.

Маршрутизатор может иметь не только интерфейсы MANET. Информация о всех этих интерфейсах записывается в Local Information Base, которая используется, но не изменяется в сигнализации данного протокола.

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

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

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

Информация для Local Information Base определяется локально и включается в сообщения HELLO. Информация для Interface Information Base и Neighbor Information Base определяется из полученных сообщений HELLO и часть этой информации может включаться в передаваемые сообщения HELLO. Срок действия этой информации ограничен и определяется значением VALIDITY_TIME TLV в сообщении HELLO, доставившем эти данные, которое, в свою очередь, устанавливается маршрутизатором, создавшим сообщение HELLO, в соответствии со значением параметра интерфейса H_HOLD_TIME.

В Приложении E показаны связи между получением сообщений, значениями VALIDITY_TIME TLV и сроком действия информации, полученной в сообщении HELLO. В Приложении F даны примеры топологии и связанной с ней информации в базах.

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

Маршрутизатор поддерживает Local Information Base с данными локальной конфигурации, включающими, в частности:

• конфигурацию Local Interface Set с упорядоченными списками Local Interface Tuple, каждый их которых представляет интерфейс (не обязательно MANET) данного маршрутизатора;

• конфигурацию Removed Interface Address Set с упорядоченными списками Removed Interface Address Tuple, каждый из которых представляет недавно использованный адрес сети на интерфейсе (не обязательно MANET) данного маршрутизатора.

Конфигурация Local Interface Set используется при генерации сообщений HELLO, в частности, для определения адресов сетей на интерфейсе, которые будут включаться в сообщение и идентифицироваться, как локальные интерфейсы. Конфигурация Removed Interface Address Set используется для предотвращения некорректной записи использованного ранее адреса сети в качестве адреса сети соседа второго уровня с симметричным подключением.

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

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

Каждый маршрутизатор поддерживает для каждого из своих интерфейсов MANET базу Interface Information Base, содержащую данные о ближайших соседях и соседях второго уровня с симметричным соединением, полученные от этого интерфейса MANET. База, в частности, включает перечисленные ниже конфигурации.

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

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

Конфигурация Link Set для интерфейса MANET служит для генерации сообщений HELLO. В частности, данные из Link Set служат для того, чтобы обеспечить другим маршрутизаторам возможность идентификации симметричных соединений и заполнения конфигурации 2-Hop Set. Недавно утерянные соединения записываются в конфигурацию Link Set для интерфейса MANET и могут анонсироваться в сообщениях HELLO для ускоренного их удаления из конфигураций Link Set для соответствующих ближайших соседей.

Сама конфигурация Link Set для интерфейса MANET обновляется при получении сообщений HELLO, включающих записи о симметричных соединениях, упомянутые выше. Конфигурация 2-Hop Set для интерфейса MANET обновляется, как указано выше, но сама по себе не применяется при генерации сообщений HELLO.

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

Каждый маршрутизатор поддерживает Neighbor Information Base с информацией об имеющихся и недавно утраченных ближайших соседях. Эта база включает, в частности:

• Конфигурацию Neighbor Set состоящую из списков Neighbor Tuple, в каждом из которых записаны все адреса сетей для одного из ближайших соседей. Списки Neighbor Tuple поддерживаются в течение всего срока существования соответствующего Link Tuple.

• Конфигурацию Lost Neighbor Set со списками Lost Neighbor Tuple, каждый из которых содержит адрес сети для недавно потерянного ближайшего соседа с симметричным подключением.

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

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

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

Этот протокол включает сигнальный механизм для поддержки Interface Information Base и Neighbor Information Base. Если информация с канального уровня или из другого источника доступна и приемлема, она тоже может использоваться для обновления этих баз. На такие обновления накладывается ряд ограничений, описанных в Приложении B.

Сигнализация использует единственный тип сообщений – HELLO. Каждый маршрутизатор генерирует сообщения HELLO на каждом из своих интерфейсов MANET. Сообщения HELLO на каждом интерфейсе MANET маршрутизатора MANET не зависят одно от другого – содержимое сообщения HELLO зависит лишь от интерфейса MANET, для которого оно создается.

Каждое сообщение HELLO:

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

• сообщает адреса сетей на интерфейсах (MANET и не-MANET) маршрутизатора – это позволяет получателям данного сообщения HELLO связать множество адресов сетей с одним ближайшим соседом;

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

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

4.3.1. Генерация сообщений HELLO

Сообщения HELLO генерируются маршрутизатором для каждого из его интерфейсов MANET и могут передаваться:

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

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

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

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

Сообщения HELLO могут независимо планироваться для каждого интерфейса MANET в маршрутизаторе или использовать общее планирование для всех интерфейсов MANET.

4.3.2. Содержимое сообщений HELLO

Содержимое сообщений HELLO должно соответствовать приведенным ниже требованиям.

• Сообщение HELLO должно содержать все адреса сетей из конфигурации Local Interface Set маршрутизатора, на котором это сообщение генерируется, включая:

  • по крайней мере один адрес сети каждого интерфейса MANET в маршрутизаторе;

  • адреса сетей, включающие все адреса отправителей всех дейтаграмм IP, передаваемых маршрутизатором через каждый из его интерфейсов MANET;

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

• Для каждого интерфейса MANET в течение каждого интервала времени, равного соответствующему значению REFRESH_INTERVAL, сообщения HELLO должны включать всю имеющую отношение к делу информацию из соответствующих Link Set и Neighbor Information Base⁶.

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

• Сообщение HELLO должно включать в точности одно VALIDITY_TIME Message TLV (как указано в [RFC5497]) для индикации промежутка времени, в течение которого содержимое сообщения считается достоверным и, следовательно, включается в Interface Information Base получившего его маршрутизатора.

• В периодически генерируемые сообщения HELLO следует включать в точности одно INTERVAL_TIME Message TLV (как указано в [RFC5497]) для индикации текущего значения HELLO_INTERVAL на данном интерфейсе MANET (т. е., периода в течение которого гарантируется передача следующего сообщения HELLO с данного интерфейса MANET).

4.3.3. Обработка сообщений HELLO

Полученные маршрутизатором сообщения HELLO используются при обновлении Interface Information Base для интерфейса MANET, принявшего сообщение, а также Neighbor Information Base для маршрутизатора.

• Маршрутизатор проверяет наличие единственного Neighbor Tuple, соответствующего инициатору HELLO.

• Маршрутизатор проверяет наличие Link Tuple с приемлемым статусом (слышимый или симметрично подключенный) и соответствие анонсированной продолжительности каналу между интерфейсами MANET, через которые было передано и принято сообщение HELLO. Может создаваться один или множество списков Lost Neighbor Tuple, если сообщение HELLO говорит о потере соединений.

• Если соединение между интерфейсами MANET, через которые было передано и принято сообщение HELLO, является симметричным, маршрутизатор проверяет наличие подходящих списков 2-Hop Tuple с анонсированной продолжительностью.

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

4.4. Качество соединений

Некоторые соединения в сети MANET могут оказаться малоприменимыми (например, по причине некачественного распространения радиосигнала. Для предотвращения использования таких каналов в каждый список Link Tuple включается оценка качества соединения. Маршрутизатор MANET рассматривает каналы с недостаточным уровнем качества, как потерянные. Изменение значения качества соединения в Link Tuple является необязательным. Если значение качества не изменяется, оно всегда должно указывать применимость данного соединения.

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

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

Данные о качестве соединения определяются в этой спецификации, как нормализованное, безразмерное значение в диапазоне от 0 до 1, где большее значение указывает более высокое качество. Более подробное описание приведено в разделе 14.

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

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

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

Этот протокол задает сообщения HELLO, которые включаются в пакеты, определенные в [RFC5444]. Эти пакеты могут передаваться с использованием общеизвестного номера протокола manet или общеизвестного номера порта UDP manet, как указано в [RFC5498].

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

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

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

Используемые в этой спецификации параметры интерфейсов можно разделить на 4 категории:

• интервалы между сообщениями;

• время достоверности информации;

• качество соединения;

• вариации.

Параметры подробно описаны ниже.

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

5.3.1. Интервалы между сообщениями

Сообщения HELLO служат двум основным целям:

• анонсирование адресов сетей на интерфейсах этого маршрутизатора ближайшим соседям (частота передачи таких анонсов определяется параметрами интерфейса HELLO_INTERVAL и HELLO_MIN_INTERVAL);

• анонсирование маршрутизатором своей информации о ближайших соседях (частота передачи таких анонсов определяется параметром интерфейса REFRESH_INTERVAL).

HELLO_INTERVAL

Максимальный перерыв между двумя последовательными сообщениями HELLO на данном интерфейсе MANET. При периодической отправке сообщений HELLO их следует передавать с интервалом HELLO_INTERVAL, возможно измененном вариациями [RFC5148].

HELLO_MIN_INTERVAL

Минимальный перерыв между двумя последовательными сообщениями HELLO на данном интерфейсе MANET (может быть изменен вариациями, определенными в [RFC5148]).

REFRESH_INTERVAL

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

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

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

Ниже приведены ограничения, применимые к описанным параметрам интерфейсов.

• HELLO_INTERVAL > 0;

• HELLO_MIN_INTERVAL >= 0;

• HELLO_INTERVAL >= HELLO_MIN_INTERVAL;

• REFRESH_INTERVAL >= HELLO_INTERVAL;

• при включении INTERVAL_TIME Message TLV (как определено в [RFC5497]) в сообщение HELLO, значение HELLO_INTERVAL должно представляться в соответствии с [RFC5497].

Если REFRESH_INTERVAL > HELLO_INTERVAL, маршрутизатор может распределять анонсы соседей между сообщениями HELLO любым способом с учетом приведенных выше ограничений.

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

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

5.3.2. Время достоверности информации

Описанные ниже параметры управляют временем достоверности информации о соединениях.

L_HOLD_TIME

Период анонсирования в сообщениях HELLO на данном интерфейсе MANET адреса сети бывшего ближайшего соседа, как потерянного, позволяет получателям этого сообщения HELLO ускорить удаление соответствующей информации из своих конфигураций Link Set. Если ускоренное удаление информации не требуется, можно установить L_HOLD_TIME = 0.

H_HOLD_TIME

Используется в качестве Value в VALIDITY_TIME Message TLV, включаемом во все сообщения HELLO на данном интерфейсе MANET. Это значение используется каждым маршрутизатором, получившим сообщение HELLO, для индикации достоверности информации из данного сообщения HELLO, записываемой в информационные базы маршрутизатора.

Поскольку каждый элемент информации о соседе включается в сообщения HELLO в интервале времени REFRESH_INTERVAL, ограничения H_HOLD_TIME основаны на значении REFRESH_INTERVAL, а не HELLO_INTERVAL.

Для приведенных выше параметров имеется ряд ограничений:

• L_HOLD_TIME >= 0;

• H_HOLD_TIME >= REFRESH_INTERVAL;

• если сообщения HELLO могут теряться, для обоих параметров следует выбирать значения существенно больше REFRESH_INTERVAL;

• H_HOLD_TIME должно представляться в соответствии с [RFC5497].

5.3.3. Качество соединения

Ниже приведены параметры управления использованием качества канала (см. раздел 14).

HYST_ACCEPT

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

HYST_REJECT

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

INITIAL_QUALITY

Начальный уровень качества для недавно обнаруженного соединения.

INITIAL_PENDING

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

Для приведенных выше параметров имеется ряд ограничений:

• 0 <= HYST_REJECT <= HYST_ACCEPT <= 1;

• 0 <= INITIAL_QUALITY <= 1;

• если качество соединения не обновляется, то INITIAL_QUALITY >= HYST_ACCEPT;

• если INITIAL_QUALITY >= HYST_ACCEPT, то INITIAL_PENDING := false;

• если INITIAL_QUALITY < HYST_REJECT, то INITIAL_PENDING := true.

5.3.4. Вариации

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

HP_MAXJITTER

Представляет значение MAXJITTER, используемое в [RFC5148] для периодически генерируемых сообщений HELLO на данном интерфейсе MANET.

HT_MAXJITTER

Представляет значение MAXJITTER, используемое в [RFC5148] для вызванных внешними событиями сообщений HELLO на данном интерфейсе MANET.

Ограничения для этих параметров описаны в [RFC5148].

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

Два параметра, определенных для маршрутизаторов данной спецификацией, относятся к категории времени достоверности информации.

5.4.1. Время достоверности информации

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

N_HOLD_TIME

Задает период, в течение которого адреса сетей бывшего ближайшего соседа анонсируются, как потерянные, в сообщениях HELLO, что позволяет получателям этих сообщений HELLO ускорять удаление этой информации из своих конфигураций 2-Hop Set. Если ускоренное удаление информации не требуется, можно установить N_HOLD_TIME MAY = 0.

I_HOLD_TIME

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

Для приведенных выше параметров имеется ряд ограничений:

   N_HOLD_TIME >= 0
   I_HOLD_TIME >= 0

5.5. Ограничения на изменение параметров

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

HELLO_INTERVAL

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

Если значение HELLO_INTERVAL для интерфейса MANET уменьшается, следующие сообщения HELLO на данном интерфейсе MANET должны передаваться в соответствии с новым (меньшим) значением HELLO_INTERVAL.

REFRESH_INTERVAL

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

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

HYST_ACCEPT and HYST_REJECT

При изменении HYST_ACCEPT или HYST_REJECT должны предприниматься действия по изменению качества каналов, описанные в параграфе 14.3.

L_HOLD_TIME

При изменении L_HOLD_TIME время достоверности всех имеющих к этому отношение списков Link Tuple должно меняться.

N_HOLD_TIME

При изменении N_HOLD_TIME время достоверности всех имеющих к этому отношение списков Lost Neighbor Tuple должно меняться.

HP_MAXJITTER

При изменении HP_MAXJITTER планирование периодических сообщений HELLO на этом интерфейсе MANET может быть изменено.

HT_MAXJITTER

При изменении HT_MAXJITTER вызываемые внешними событиями сообщения HELLO на данном интерфейсе MANET могут быть перепланированы.

5.6. Константы

Константа C (квант отсчета времени) используется в соответствии с [RFC5497].

6. База локальной информации

Маршрутизатор поддерживает базу локальной информации (Local Information Base) с записями о своих интерфейсах (не только MANET). Каждый интерфейс маршрутизатора должен идентифицироваться хотя бы одни адресом сети. Адрес может быть специфическим для одного интерфейса, а в некоторых случаях может совместно использоваться несколькими интерфейсами, как описано ниже.

Содержимое Local Information Base не меняется под воздействием сигнализации. Если конфигурация маршрутизатора меняется, эти изменения должны быть отражены в Local Information Base. Такие изменения могут также приводить к сигнализации для анонсирования изменений.

Не обязательно включать все адреса интерфейса в Local Information Base и, следовательно, в сообщения HELLO. Однако любые адреса, которые могут указываться в качестве источника переданных интерфейсом дейтаграмм IP, должны включаться в базу (для каждого интерфейса в базе должен присутствовать по крайней мере один адрес). Протокол, использующий эту спецификацию, может предъявлять дополнительные требования (например, о включении всех адресов, которые могут использоваться в качестве адреса получателя в дейтаграммах IP).

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

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

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

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

6.1. Конфигурация локальных интерфейсов

В конфигурации Local Interface Set хранятся записи о локальных интерфейсах маршрутизатора, состоящие из списков Local Interface Tuple вида

      (I_local_iface_addr_list, I_manet)

где

I_local_iface_addr_list – неупорядоченный список адресов сетей для данного интерфейса;

I_manet – флаг, указывающий относится ли данный интерфейс к MANET.

Списки Local Interface Tuple удаляются из конфигурации Local Interface Set только при изменении конфигурации интерфейсов в маршрутизаторе (см. раздел 9), т. е., не зависят от каких-либо таймеров.

6.2. Конфигурация адресов удаленных интерфейсов

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

      (IR_local_iface_addr, IR_time)

где

IR_local_iface_addr – недавно использовавшийся адрес сети на интерфейсе данного маршрутизатора;

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

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

Маршрутизатор поддерживает базе Interface Information Base для каждого из своих интерфейсов MANET. В этой базе хранятся сведения о каналах к данному интерфейсу MANET и соседях второго уровня с симметричным соединением, доступных через этот интерфейс (в качестве первого интервала). Каждая база Interface Information Base включает конфигурации Link Set и 2-Hop Set.

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

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

7.1. Конфигурация соединения

Конфигурация Link Set для интерфейса указывает соединения с другими маршрутизаторами (которые являются или недавно были ближайшими соседями) через данный интерфейс и состоит из списков Link Tuple вида

(L_neighbor_iface_addr_list, L_HEARD_time, L_SYM_time, L_quality, L_pending, L_lost, L_time)

где

L_neighbor_iface_addr_list – неупорядоченный список адресов сетей на интерфейсе MANET ближайшего соседа;

L_HEARD_time – время, до завершения которого интерфейс MANET ближайшего соседа считается слышимым, если не принимается во внимание качество соединения;

L_SYM_time – время, до завершения которого соединение с ближайшим соседом считается симметричным, если не принимается во внимание качество соединения;

L_quality – число от 0 до 1, включительно, описывающее качество соединения; большее значение L_quality указывает более высокое качество соединения;

L_pending – флаг, показывающий, является ли соединение ожидающим (т. е., подготовленным, но еще не организованным);

L_lost – флаг, показывающий, считается ли соединение утраченным по причине низкого качества;

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

Статус соединения, полученный из обмена сообщениями HELLO и оценки качества канала, обозначается L_status и может принимать значения PENDING, HEARD, SYMMETRIC и LOST. Значения LOST, SYMMETRIC и HEARD определены в параграфе 18.5. Значение PENDING никогда не используется в сообщениях HELLO и применяется только локально самим маршрутизатором и может быть любым, отличающимся от LOST, SYMMETRIC и HEARD.

L_status определяется следующим образом:

1. если L_pending = true, то L_status := PENDING;

2. иначе, если L_lost = true, то L_status := LOST;

3. иначе, если время L_SYM_time не истекло, L_status := SYMMETRIC;

4. иначе, если время L_HEARD_time не истекло, L_status := HEARD;

5. в остальных случаях L_status := LOST.

7.2. 2-Hop Set

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

      (N2_neighbor_iface_addr_list, N2_2hop_addr, N2_time)

где

N2_neighbor_iface_addr_list – неупорядоченный список адресов сетей на интерфейсе MANET ближайшего соседа с симметричным соединением, от которого была получена информация;

N2_2hop_addr – адрес сети соседа второго уровня с симметричным соединением, который имеет симметричное соединение с указанным выше ближайшим соседом, используя интерфейс MANET;

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

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

Каждый маршрутизатор поддерживает Neighbor Information Base с адресами сетей текущих и недавних ближайших соседей с симметричным подключением.

8.1. Множество соседей

Конфигурация Neighbor Set содержит все адреса сетей для каждого из ближайших соседей и состоит из списков Neighbor Tuple для каждого соседа

      (N_neighbor_addr_list, N_symmetric)

где

N_neighbor_addr_list – неупорядоченный список адресов сетей ближайшего соседа;

N_symmetric – флаг симметричности соединения с данным соседом.

Списки Neighbor Tuple удаляются из Neighbor Set только при завершении срока действия соответствующих списков Link Tuple в конфигурации Link Set, т. е., Neighbor Tuple не удаляются напрямую по таймерам.

8.2. Множество утерянных соседей

Конфигурация Lost Neighbor Set содержит адреса сетей маршрутизаторов, которые недавно были ближайшими соседями с симметричным соединением, но анонсированы, как потерянные. Конфигурация состоит из упорядоченных списков Lost Neighbor Tuple, каждый из которых представляет один адрес сети

      (NL_neighbor_addr, NL_time)

где

NL_neighbor_addr – адрес сети маршрутизатора, который недавно был ближайшим соседом с симметричным соединением;

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

9. Изменения базы локальной информации

База Local Information Base должна обновляться при изменении конфигурации локальных интерфейсов маршрутизатора. При этом могут изменяться также базы Interface Information Base и Neighbor Information Base. Если любые изменения в этих двух базах удовлетворяют условиям, описанным в разделе 13, эти изменения должны быть применены незамедлительно, если ниже не указано иное.

В результате упомянутых здесь изменений маршрутизатор может передавать сообщения HELLO.

9.1. Добавление интерфейса

Добавление интерфейса на маршрутизаторе указывается путем добавления списка Local Interface Tuple в конфигурацию Local Interface Set. Если новый интерфейс относится к MANET, для него должна создаваться исходно пустая база Interface Information Base. Для каждого адреса сети на этом интерфейсе должны быть выполнены действия, указанные в параграфе 9.3. Сообщение HELLO может быть передано через все интерфейсы MANET и такое сообщение следует передать через новый интерфейс, если он относится к MANET. При использовании планирования сообщений должно быть организовано планирование для нового интерфейса MANET.

9.2. Удаление интерфейса

Удаление интерфейса на маршрутизаторе должно сопровождаться перечисленными ниже изменениями в базах Local Information Base и Neighbor Information Base.

1. Определяется список Local Interface Tuple, соответствующий удаляемому интерфейсу.

2. Для каждого адреса сети (далее, удаляемый адрес) в I_local_iface_addr_list данного списка Local Interface Tuple если этот адрес не входит в I_local_iface_addr_list какого-либо другого списка Local Interface Tuple, создается список Removed Interface Address Tuple с приведенными ниже значениями:

• • IR_local_iface_addr := удаляемый адрес;

  • IR_time := текущее время + I_HOLD_TIME.

3. Данный список Local Interface Tuple удаляется из конфигурации Local Interface Set.

4. Если удаляется интерфейс MANET (т. е., интерфейс с I_manet = true), выполняются следующие действия:

   1. удаляется база Interface Information Base для этого интерфейса MANET;

   2. все списки Neighbor Tuple, в которых ни один из адресов сетей в их N_neighbor_addr_list не содержится в каком-либо из L_neighbor_iface_addr_list того или иного сохраняющегося списка Link Tuple, удаляются.

Если удаляется последний интерфейс MANET на данном маршрутизаторе, баз Interface Information Base после этого не останется и маршрутизатор больше не будет участвовать в работе данного протокола.

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

9.3. Добавление сетевого адреса на интерфейсе

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

1. Удаляются все списки Removed Interface Address Tuple, где IR_local_iface_addr содержит добавленный адрес.

2. Удаляются все списки Neighbor Tuple, где N_neighbor_addr_list содержит адрес сети, пересекающийся с добавленным адресом.

3. Удаляются все списки Link Tuples во всех конфигурациях Link Set для которых выполняется любое из условий:

• • • L_neighbor_iface_addr_list содержит любой адрес сети в N_neighbor_addr_list любого из удаляемых списков Neighbor Tuple;

    • L_neighbor_iface_addr_list содержит адрес сети, пересекающийся с добавленным адресом,

выполняются действия из параграфа 13.2, но не из 13.3;

4. Удаляются все списки Lost Neighbor Tuple, где NL_neighbor_addr пересекается с добавленным адресом сети.

5. Удаляются все списки 2-Hop Tuples, где N2_2hop_addr пересекается с добавленным адресом сети.

После добавления интерфейса и выполнения перечисленных действий может быть передано сообщение HELLO через все интерфейсы MANET.

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

9.4. Удаление сетевого адреса на интерфейсе

При удалении адреса сети (далее, удаляемый адрес) на интерфейсе выполняются перечисленные ниже действия.

1. Определяется список Local Interface Tuple, соответствующий удаляемому адресу.

2. Если этот адрес является единственным адресом сети на интерфейсе (в соответствующем I_local_iface_addr_list только один адрес), данный интерфейс удаляется, как описано в параграфе 9.2.

3. В остальных случаях:

   1. адрес удаляется из I_local_iface_addr_list;

   2. если удаляемого адреса нет в I_local_iface_addr_list никаких других списков Local Interface Tuple, создается список Removed Interface Address Tuple с приведенными ниже значениями:

• • IR_local_iface_addr := удаляемый адрес;

  • IR_time := текущее время + I_HOLD_TIME.

После удаления интерфейса и выполнения перечисленных действий может быть передано сообщение HELLO через все интерфейсы MANET.

10. Пакеты и сообщения

Формат используемых данным протоколом пакетов и сообщений определен в [RFC5444]. Ниже перечислены некоторые специфические аспекты, связанные с сообщениями протокола.

• Протокол использует единственный тип сообщений (Message Type) – HELLO.

• В сообщениях HELLO может использоваться любая комбинация опций заголовка сообщения (Message Header), определенных в [RFC5444].

• Пересылка сообщений HELLO недопустима, т. е. при наличии <msg-hop-limit> этот параметр должен иметь значение 1.

• Множество сообщений HELLO может помещаться в один пакет, как указано в [RFC5444].

• Разбор полученных сообщений HELLO должен выполняться в соответствии с [RFC5444]. Сообщения HELLO, не соответствующие спецификации [RFC5444], должны отбрасываться без обработки. Возможно отбрасывание сообщений HELLO без обработки и по иным причинам (см. параграф 12.1).

• Протокол задает три Address Block TLV и использует также два Message TLV, определенных в [RFC5497]. Для этих пяти типов TLV определено единственное расширение – Extension = 0. TLV всех прочих типов и этих пяти типов без Type Extension = 0 игнорируются данным протоколом. Все случаи использования в данной спецификации Address Block TLV с Type = LINK_STATUS подразумевают использование Address Block TLV с Type = LINK_STATUS и Type Extension = 0.

10.1. Сообщения HELLO

Сообщение HELLO должно включать:

• в точности один экземпляр VALIDITY_TIME Message TLV, как указано в [RFC5497], представляющий значение H_HOLD_TIME для передающего интерфейса MANET.

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

В сообщения HELLO, передаваемые периодически, следует включать, а в остальные (передаваемые по иным причинам, например, в ответ на изменения информационных баз) можно включать:

• в точности один экземпляр INTERVAL_TIME Message TLV, как указано в [RFC5497], представляющий значение HELLO_INTERVAL для передающего интерфейса MANET. Эта опция включена в [RFC5497] для представления того, что недопустимо использовать интервалы нулевой и бесконечной продолжительности.

Сообщение HELLO может включать:

• иные Message TLV;

• один или множество Address Block, каждый из которых связан с Address Block TLV Block, который может включать другие Address Block TLV.

10.1.1. Блоки адресов

Все адреса сетей в базе локальных интерфейсов маршрутизатора Local Interface Set (т. е., в любом I_local_iface_addr_list) должны быть представлены, как адресные объекты (см. [RFC5444]), и включены в блоки адресов (Address Block) всех генерируемых сообщений HELLO с учетом приведенного ниже исключения.

• Если интерфейс MANET, через который будет передано сообщение HELLO, имеет единственный адрес с префиксом максимального размера (/32 для IPv4, /128 для IPv6), такой адрес может не включаться в Address Block, поскольку он указан в поле отправителя в заголовке дейтаграммы IP, содержащей сообщение HELLO.

Все адреса сетей на интерфейсах маршрутизатора, включенные в какой-либо из Address Block, должны быть связаны с Address Block TLV с Type = LOCAL_IF, как показано в таблице 1.

Таблица 1. Определение LOCAL_IF TLV.

Имя	Размер	Описание
LOCAL_IF	1 октет	Указывает, что адрес сети связан с интерфейсом MANET, через который было передано сообщение (THIS_IF), или другим интерфейсом того же маршрутизатора (OTHER_IF).

Address Block могут содержать адреса сетей текущих или недавно потерянных ближайших соседей, представленные, как адресные объекты (см. [RFC5444]), каждый из которых связан с одним или обоими Address Block TLV, как показано в таблице 2.

Таблица 2. Определения LINK_STATUS и OTHER_NEIGHB TLV.

Имя	Размер	Описание
LINK_STATUS	1 октет	Показывает статус соединения от указанного адреса сети до интерфейса MANET, через который передается сообщение HELLO (LOST, SYMMETRIC или HEARD).
OTHER_NEIGHB	1 октет	Показывает, что адрес сети относится к интерфейсу MANET маршрутизатора, который является (SYMMETRIC) или был (LOST) ближайшим соседом с симметричным соединением для передающего сообщение HELLO маршрутизатора.

Address Block TLV с Type = LINK_STATUS и Value = SYMMETRIC или Value = LOST выполняет также функцию Address Block TLV с Type = OTHER_NEIGHB и таким же значением (Value). Включение последнего с тем же самым адресным блоком не рекомендуется по соображениям эффективности. Если Address Block TLV с Type = LINK_STATUS и Value = SYMMETRIC в комбинации с Address Block TLV с Type = OTHER_NEIGHB и Value = LOST связываются с одним адресным объектом, второй Address Block TLV должен игнорироваться и не следует его включать (см. Приложение A).

Другие адреса сетей можно представлять, как адресные объекты (см. [RFC5444]) и включать в Address Block, но недопустимо связывать с каким-либо из Address Block TLV, указанных в этой спецификации.

11. Генерация сообщений HELLO

Каждый интерфейс MANET должен генерировать сообщения HELLO в соответствии с приведенной в этом разделе спецификацией. Генерация сообщений HELLO для каждого интерфейса MANET выполняется независимо. Генерация и планирование сообщений HELLO должны происходить в соответствии с параметрами данного интерфейса MANET и могут быть независимыми для каждого интерфейса MANET или (если позволяют параметры интерфейсов) могут использовать общее планирование.

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

11.1. Спецификация сообщения HELLO

Сообщения HELLO генерируются независимо на каждом интерфейсе MANET.

Все адреса из каждого списка I_local_iface_addr_list должны включаться в сообщения с представлением адресными объектами (см. [RFC5444]), за исключением приведенного ниже случая.

• Если интерфейс, через который будет передаваться сообщение HELLO, имеет единственный адрес сети и этот адрес имеет максимальный размер префикса (/32 для IPv4, /128 для IPv6), такой адрес можно опускать, поскольку он включается в заголовок IP содержащей сообщение HELLO дейтаграммы.

Все такие включенные адреса должны быть связаны с Address Block TLV с Type := LOCAL_IF и Value, соответствующим приведенным ниже условиям:

• если адресный объект представляет адрес сети передающего сообщение интерфейса MANET, то Value := THIS_IF;

• в остальных случаях Value := OTHER_IF.

Если такое адрес включен во множество I_local_iface_addr_list, из соображений эффективности рекомендуется связывать соответствующий адресный объект только с одним Value, используя Address Block TLV с Type := LOCAL_IF; если адресный объект представляется адрес сети передающего сообщение интерфейса MANET, должно устанавливаться Value := THIS_IF.

Следующие адреса сетей текущих или прошлых ближайших соседей могут представляться адресными объектами (см. [RFC5444]) и включаться в любое сообщение HELLO в соответствии с параметром REFRESH_INTERVAL для каждой ассоциации на данном интерфейсе MANET и приведенными ниже правилами.

• Адреса сетей на интерфейсах MANET ближайших соседей из конфигурации Link Set в базе Interface Information Base для этого интерфейса MANET (т. е., из списков L_neighbor_iface_addr_list), отличающиеся от адресов из списков Link Tuple с L_status = PENDING.

• Другие адреса сетей ближайших соседей с симметричным подключением из конфигурации Neighbor Set в базе данного маршрутизатора Neighbor Information Base (т. е., из списка N_neighbor_addr_list).

• Адреса сетей на интерфейсах MANET ранее симметричных или слышимых ближайших соседей, соединенных с данным интерфейсом MANET, из конфигурации Link Set базы Interface Information Base для этого интерфейса MANET (т. е. из L_neighbor_iface_addr_list с L_status = LOST).

• Другие адреса сетей ранее симметричных ближайших соседей из конфигурации Lost Neighbor Set в базе данного маршрутизатора Neighbor Information Base (т. е., из NL_neighbor_addr).

Каждый такой адресный объект (см. [RFC5444]) должен быть связан с одним или множеством подходящих Address Block TLV. В частности, должны выполняться приведенные ниже условия.

1. Для каждого адресного объекта (далее, связанный адрес), который представляет адрес сети, содержащийся в L_neighbor_iface_addr_list списка Link Tuple в конфигурации Link Set для этого интерфейса MANET, и имеет L_status != PENDING, включается связанный адрес со связанным Address Block TLV с

Type := LINK_STATUS
Value := L_status

2. Для каждого адресного объекта (далее, адрес соседа), который представляет адрес сети, содержащийся в N_neighbor_addr_list из списка Neighbor Tuple с N_symmetric = true, и еще не включен со связанным Address Block TLV с Type = LINK_STATUS и Value = SYMMETRIC, включается адрес соседа со связанным Address Block TLV с

Type := OTHER_NEIGHB
Value := SYMMETRIC

3. Для каждого списка Lost Neighbor Tuple, в котором NL_neighbor_addr (далее, потерянный адрес) еще не представлен в качестве связанного объекта и не включен, включается потерянный адрес со связанным Address Block TLV с

Type := OTHER_NEIGHB
Value := LOST

Если любой из таких адресов был добавлен в информационные базы с момента отправки последнего сообщения HELLO на данном интерфейсе MANET или статус адрес (указывается TLV и Value, связанными с адресами сетей) изменился с момента последней передачи информации об этом адресе через данный интерфейс MANET, этот адрес сети и указанные TLV следует включить в сообщение HELLO.

Если адресный объект (см. [RFC5444]), представляющий адрес сети ближайшего соседа, задан со множеством связанных Address Block TLV, эти Address Block TLV могут независимо включаться или исключаться для каждого сообщения HELLO. Каждый такой Address Block TLV должен включаться с представлением с помощью адресного объекта такого адреса сети в сообщение HELLO, передаваемое данным интерфейсом MANET в течение каждого интервала, равного по продолжительности со значением параметра REFRESH_INTERVAL для данного интерфейса MANET. Address Block TLV, связанные с общим адресным объектом в одном сообщении HELLO, могут применяться для общей или разных копий этого адресного объекта.

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

11.2. Передача сообщений HELLO

Сообщения HELLO передаются в формате, заданном [RFC5444].

11.2.1. Вариации для сообщений HELLO

Сообщения HELLO могут генерироваться периодически или по внешним событиям. Если на канальном или физическом уровне возможны потери данных в результате конфликтов при доступе к среде передачи, для сообщений HELLO следует вносить временные вариации, описанные в [RFC5148].

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

Пересылка сообщений HELLO недопустима и вариации при пересылке не применяются для сообщений HELLO. Для каждой из форм вариаций в [RFC5148] требуется параметр MAXJITTER. Эти параметры могут быть динамическими и задаются для:

• периодических сообщений (HP_MAXJITTER);

• вызванных внешними событиями сообщений (HT_MAXJITTER).

Когда генерация сообщения HELLO задерживается для того, чтобы это сообщение не было передано до истечения интервала HELLO_MIN_INTERVAL с момента передачи предыдущего сообщения HELLO на том же интерфейсе MANET, значение HELLO_MIN_INTERVAL следует уменьшать с использованием вариаций с максимальным значением HP_MAXJITTER, как описано в [RFC5148]. В таких случаях недопустимо HP_MAXJITTER > HELLO_MIN_INTERVAL.

12. Обработка сообщений HELLO

При получении сообщения HELLO маршрутизатор сначала должен проверить его пригодность для обработки на данном маршрутизаторе (см. параграф 12.1) и отбросить без обработки непригодное сообщение. Для каждого пригодного для обработки сообщения HELLO принимающий маршрутизатор должен обновить соответствующие базы Interface Information Base и Neighbor Information Base, как указано в параграфах 12.3 – 12.6. Эти обновления должны выполняться в порядке их указания в данной спецификации. Если какое-либо изменение соответствует условиям, описанным в разделе 13, указанные в этом разделе последствия должны применяться незамедлительно, если явно не указано иное.

Вся обработка сообщения, включая проверку его пригодности, выполняется только для TLV с Type Extension = 0. TLV с другими типа расширения игнорируются. Все упоминания, например, TLV с Type = LINK_STATUS говорят о TLV с Type = LINK_STATUS и Type Extension = 0.

12.1. Непригодные сообщения

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

• Размер адреса, указанный в Message Header, не совпадает с размером адресов, используемых этим маршрутизатором.

• Значение поля <msg-hop-limit> в Message Header отличается от 1 (отметим, что поле <msg-hop-limit> не обязательно).

• Значение поля <msg-hop-count> в Message Header отличается от 0 (отметим, что поле <msg-hop-count> не обязательно).

• Сообщение не включает Message TLV с Type = VALIDITY_TIME в своем Message TLV Block.

• Сообщение включает более одного Message TLV с Type = VALIDITY_TIME в своем Message TLV Block.

• Сообщение включает более одного Message TLV с Type = INTERVAL_TIME в своем Message TLV Block.

• Сообщение включает любые Address Block TLV с Type = LOCAL_IF и одно Value = v такое, что v != THIS_IF и v != OTHER_IF.

• Любой адресный объект (включая разные представления одного сетевого адреса в одном или разных Address Block) связан более чем с одним Value одним или множеством Address Block TLV с Type = LOCAL_IF.

• Любой адресный объект (далее, локальный адрес), связанный с Address Block TLV с Type = LOCAL_IF, представляет один из текущий или недавно использованных принимающим маршрутизатором адресов (т. е. локальный адрес перекрывается с любым сетевым адресом в любом I_local_iface_addr_list набора Local Interface Set или в любом IR_local_iface_addr набора Removed Interface Address Set).

• Сообщение имеет любые Address Block TLV с Type = LINK_STATUS и любым одним Value v, не равным LOST, SYMMETRIC или HEARD.

• Сообщение имеет любые Address Block TLV с Type = OTHER_NEIGHB и любым одним Value v, таким, что v != LOST и v != SYMMETRIC.

• Любой адресный объект (включая разные представления одного сетевого адреса в одном или разных Address Block) связан с Address Block TLV, где Type = LOCAL_IF и Address Block TLV, где Type = LINK_STATUS.

• Любой адресный объект (включая разные представления одного сетевого адреса в одном или разных Address Block) связан Address Block TLV, где Type = LOCAL_IF и Address Block TLV, где Type = OTHER_NEIGHB.

• Любой адресный объект (включая разные представления одного сетевого адреса в одном или разных Address Block) связан множеством Value одним или множеством Address Block TLV с Type = LINK_STATUS.

• Любой адресный объект (включая разные представления одного сетевого адреса в одном или разных Address Block) связан множеством Value одним или множеством Address Block TLV с Type = OTHER_NEIGHB.

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

Непригодные сообщения должны отбрасываться без уведомления и обновления Information Base в маршрутизаторе.

12.2. Определения

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

validity time – время действия

Рассчитывается из Message TLV с Type = VALIDITY_TIME в сообщении HELLO, как указано в [RFC5497] (отметим, что в соответствии с параграфом 12.1 сообщение HELLO должно включать в точности один блок Message TLV). Вся информация в сообщении HELLO, применяемая этой спецификацией, имеет одинаковый срок действия.

Receiving Address List – список принимающих адресов

Список I_local_iface_addr_list, соответствующий интерфейсу MANET, на котором принято сообщение HELLO.

Sending Address List – список передающих адресов

Неупорядоченный список сетевых адресов интерфейса MANET, через который было передано сообщение HELLO, т. е. неупорядоченный список сетевых адресов, представленный адресными объектами в сообщении HELLO со связанным Address Block TLV с Type = LOCAL_IF и Value = THIS_IF. Если Sending Address List иначе будет пуст, он образуется из одного сетевого адреса с префиксом максимального размера (/32 для IPv4, /128 для IPv6), совпадающего с адресом отправителя дейтаграммы IP, в которую было включено сообщение HELLO.

Neighbor Address List – список адресов соседей

Неупорядоченный список всех сетевых адресов всех интерфейсов маршрутизатора, который создал сообщение HELLO, т. е. Sending Address List и сетевые адреса, представленные адресными объектами в сообщении HELLO со связанным Address Block TLV с Type = LOCAL_IF и Value = OTHER_IF.

EXPIRED – истек срок

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

Removed Address List – список удаленных адресов

Список сетевых адресов, созданных обработкой данного сообщения HELLO, о которых ранее сообщал как о локальных маршрутизатор, создавший сообщение HELLO, но которые не включены в список Neighbor Address List. Данный список инициализируется пустым.

Lost Address List – список потерянных адресов

Подмножество Removed Address List, содержащее сетевые адреса, которые раньше считались симметричными. Данный список инициализируется пустым.

12.3. Обновление Neighbor Set

При получении сообщения HELLO маршрутизатор должен обновить свой Neighbor Set и заполнит списки Removed Address List и Lost Address List, как показано ниже.

1. Находятся все Neighbor Tuple (далее совпадающие Neighbor Tuple), где N_neighbor_addr_list содержит любой сетевой адрес, перекрывающийся с любым из сетевых адресов в списке Neighbor Address List.

2. Если нет совпадающих Neighbor Tuples, выполняются указанные ниже действия.

   1. Создается Neighbor Tuple с

• • N_neighbor_addr_list := Neighbor Address List;

  • N_symmetric := false.

3. Если имеется один совпадающий Neighbor Tuple, выполняются указанные ниже действия.

   1. Если в этом Neighbor Tuple выполняется условие N_neighbor_addr_list != Neighbor Address List, то

      1. для каждого сетевого адреса (далее удаленный адрес), который содержится в N_neighbor_addr_list, но не включен в Neighbor Address List

         1. удаленный адрес добавляется в список Removed Address List;

         2. если N_symmetric = true, удаленный адрес добавляется в список Lost Address List;

      2. обновляется совпадающий Neighbor Tuple

• • N_neighbor_addr_list := Neighbor Address List.

4. Если имеется не менее двух совпадающих Neighbor Tuples, выполняются указанные ниже действия.

   1. Для каждого сетевого адреса (далее удаленный адрес), который содержится в N_neighbor_addr_list любого из совпадающих Neighbor Tuple, но не включен в Neighbor Address List:

      1. удаленный адрес добавляется в Removed Address List;

      2. если N_symmetric = true, удаленный адрес добавляется в список Lost Address List.

   2. Совпадающие Neighbor Tuple заменяются одним Neighbor Tuple с:

• • N_neighbor_addr_list := Neighbor Address List;

  • N_symmetric := false.

12.4. Обновление Lost Neighbor Set

При получении HELLO маршрутизатор должен обновить свой Lost Neighbor Set, как показано ниже.

1. Для каждого сетевого адреса (далее потерянный адрес), который содержится в Lost Address List, если нет Lost Neighbor Tuple с NL_neighbor_addr, указывающим потерянный адрес, добавляется Lost Neighbor Tuple с

• • NL_neighbor_addr := потерянный адрес;

  • NL_time := current time + N_HOLD_TIME.

12.5. Обновление Link Set

При получении HELLO маршрутизатор должен обновить свои Link Set, как показано ниже.

1. Удалить все сетевые адреса в Removed Address List из L_neighbor_iface_addr_list всех Link Tuple.

2. Удалить все Link Tuple с непустыми L_neighbor_iface_addr_list (применяется параграф 13.2, но не 13.3).

Затем маршрутизатор должен обновить свой Link Set для интерфейса MANET, принявшего HELLO, как указано ниже.

1. Найти все Link Tuple (далее совпадающие Link Tuple), где

• • L_neighbor_iface_addr_list содержит один или несколько сетевых адресов из Sending Address List.

2. При наличии нескольких совпадающих Link Tuple все они удаляются (применяется параграф 13.2, но не 13.3).

3. Если больше нет совпадающих Link Tuples, создается новый совпадающий Link Tuple с:

• • L_neighbor_iface_addr_list := пуст;

  • L_HEARD_time := EXPIRED;

  • L_SYM_time := EXPIRED;

  • L_quality := INITIAL_QUALITY;

  • L_pending := INITIAL_PENDING;

  • L_lost := false;

  • L_time := текущее время + срок действия.

4. Совпадающий Link Tuple (новый или имеющийся) изменяется, как показано ниже.

   1. Если маршрутизатор находит любой сетевой адрес (далее принимающий адрес) из Receiving Address List в Address Block сообщения HELLO, Link Tuple изменяется, как показано ниже.

      1. Если любой принимающий адрес в сообщении HELLO связан с Address Block TLV с Type = LINK_STATUS и Value = HEARD или Value = SYMMETRIC, то

• • L_SYM_time := текущее время + срок действия.

1. 1. 1. Иначе если любой принимающий в сообщении HELLO связан с Address Block TLV с Type = LINK_STATUS и Value = LOST, то

         1. если время L_SYM_time не истекло,

            1. L_SYM_time := EXPIRED;

            2. если L_status = HEARD,

• • L_time := текущее время + L_HOLD_TIME.

1. 2. L_neighbor_iface_addr_list := Sending Address List.

   3. L_HEARD_time := max(текущее время + срок действия, L_SYM_time).

   4. Если L_status = PENDING, то

• • L_time := max(L_time, L_HEARD_time).

1. 5. Иначе если L_status = HEARD или L_status = SYMMETRIC, то

• • L_time := max(L_time, L_HEARD_time + L_HOLD_TIME).

12.6. Обновление 2-Hop Set

При получении HELLO маршрутизатор должен обновить свой 2-Hop Set для интерфейса MANET, принявшего HELLO.

1. Удалить все сетевые адреса в Removed Address List из N2_neighbor_iface_addr_list всех 2-Hop Tuple.

2. Если Link Tuple с L_neighbor_iface_addr_list = Sending Address List имеет L_status = SYMMETRIC, то

   1. для каждого сетевого адреса (далее адрес 2-hop) из Address Block в сообщении HELLO, где

• адрес 2-hop не содержится в Neighbor Address List;

• адрес 2-hop не содержится в каком-либо I_local_iface_addr_list и

• адрес 2-hop address не совпадает ни с одним IR_local_iface_addr

выполняются указанные ниже действия.

1. 1. 1. Если адрес 2-hop имеет связанный Address Block TLV с

• • Type = LINK_STATUS и Value = SYMMETRIC или

  • Type = OTHER_NEIGHB и Value = SYMMETRIC,

то при отсутствии 2-Hop с

• • N2_neighbor_iface_addr_list, содержащим один или несколько адресов из Sending Address List, и

  • N2_2hop_addr = адрес 2-hop,

создается 2-Hop Tuple⁷ с

• N2_2hop_addr := адрес 2-hop.

Затем этот 2-Hop Tuple (имеющийся или новый) изменяется, как показано ниже.

• • N2_neighbor_iface_addr_list := Sending Address List;

  • N2_time := текущее время + срок действия.

1. 1. 1. Иначе при наличии у адреса 2-hop блока Address Block TLV с

• • Type = LINK_STATUS и Value = LOST or Value = HEARD или

  • Type = OTHER_NEIGHB и Value = LOST,

удаляются все 2-Hop Tuple с

• • N2_neighbor_iface_addr_list, содержащим один или несколько адресов из Sending Address List, и

  • N2_2hop_addr = адрес 2-hop.

13. Изменения других информационных баз

Базы Interface и Neighbor Information должны изменяться при некоторых событиях, которые могут быть результатом обработки HELLO или порождаться иными причинами (например, таймерами или изменением качества каналов).

Изменения Information Base вызывают перечисленные ниже события.

• Смена L_status для Link Tuple на SYMMETRIC (выполняются действия параграфа 13.1).

• Смена L_status для Link Tuple с SYMMETRIC на другое состояние или удаление Link Tuple (выполняются действия параграфа 13.2).

• Истекло время L_HEARD_time для Link Tuple или Link Tuple удален (выполняются действия параграфа 13.3).

• Смена сетевого адреса локального интерфейса (выполняются действия раздела 9).

• Изменение качества канала (выполняются действия раздела 14).

Если Link Tuple удален или L_status изменился с SYMMETRIC на другое значение и время L_HEARD_time истекло, должны выполняться действия параграфа 13.2 до выполнения действий параграфа 13.3 для этого Link Tuple.

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

Маршрутизатору, передающему сообщения HELLO при таких изменениях, следует отправлять сообщение HELLO:

• во все интерфейсы MANET, если Neighbor Set меняется так, что указывает на изменение симметрии любого соседа 1-hop (включая добавление и удаление соседей с симметричными соединениями 1-hop);

• в остальных случаях в те интерфейсы MANET, для которых Link Set меняется так, что указывает изменение в L_status любого из соседей 1-hop (включая добавление и удаление любых соседей 1-hop, кроме ожидающих).

13.1. Симметрия Link Tuple

Если для любого Link Tuple, не имеющего L_status = SYMMETRIC,

• L_status меняется на SYMMETRIC,

выполняются следующие действия.

1. Для Neighbor Tuple с N_neighbor_addr_list, содержащим L_neighbor_iface_addr_list, устанавливается

• • N_symmetric := true

2. Удаляются все Lost Neighbor Tuple с NL_neighbor_addr, содержащимися в этом N_neighbor_addr_list.

Это включает вновь созданные Link Tuple, чье состояние сразу изменилось на L_status = SYMMETRIC (в данной спецификации все Link Tuple создаются с L_status отличным от SYMMETRIC, но Link Tuple может незамедлительно обновиться последующей обработкой того же сообщения HELLO, вызывающей L_status = SYMMETRIC.)

13.2. Асимметрия Link Tuple

Если для любого Link Tuple с L_status = SYMMETRIC:

• значение L_status изменилось или

• Link Tuple удален,

выполняются следующие действия.

1. Все 2-Hop Tuple для того же интерфейса MANET с

• • N2_neighbor_iface_addr_list с одним или несколькими сетевыми адресами из L_neighbor_iface_addr_list

удаляются.

1. Для Neighbor Tuple с N_neighbor_addr_list с L_neighbor_iface_addr_list выполняются указанные ниже действия.

   1. Если не остается Link Tuple для какого либо интерфейса MANET с

• • L_neighbor_iface_addr_list, содержащимся в N_neighbor_addr_list, и

  • L_status = SYMMETRIC,

Neighbor Tuple изменяется, как показано ниже.

1. 1. 1. N_symmetric := false.

      2. Для каждого адреса (далее адрес соседа) в N_neighbor_addr_list добавляется Lost Neighbor Tuple с

• • NL_neighbor_addr := адрес соседа;

  • NL_time := текущее время + N_HOLD_TIME.

13.3. Тайм-аут Link Tuple Heard

Если для любого Link Tuple

• истекло время L_HEARD_time или

• Link Tuple удален,

выполняются указанные ниже действия.

1. Для Neighbor Tuple, чей N_neighbor_addr_list содержит L_neighbor_iface_addr_list, если не остается Link Tuple для какого-либо интерфейса MANET, где

• • L_neighbor_iface_addr_list содержится в N_neighbor_addr_list и

  • время L_HEARD_time не истекло,

Neighbor Tuple удаляется.

14. Качество канала

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

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

Для систем без применения параметров качества каналов применимы соображения, приведенные в параграфе 14.1. Для систем с использованием параметров качества каналов общие принципы описаны в параграфе 14.2. Работа с качеством каналов подробно описана в параграфах 14.3 и 14.4.

14.1. Системы без Link Quality

Маршрутизаторы, не применяющие параметры качества каналов, должны установить:

• INITIAL_PENDING := false;

• INITIAL_QUALITY >= HYST_REJECT (не причин не указать INITIAL_QUALITY := 1).

14.2. Базовые принципы Link Quality

Для применения параметров качества каналов используется значение L_quality в Link Tuple с двумя порогами -HYST_ACCEPT и HYST_REJECT установки флагов L_pending и L_lost в данном Link Tuple. На основе этих флагов состояние канала, анонсируемое для этого Link Tuple, определяется в соответствии с параграфом 7.1.

Наличие двух пороговых значений позволяет задать гистерезис, обеспечивающий HYST_REJECT <= L_quality < HYST_ACCEPT, когда канал принимается или отвергается в зависимости от недавнего порога, который недавно преодолело значение L_quality, или от параметра INITIAL_PENDING). При хорошо подобранных значениях параметров быстрая смена состояния канала будет исключаться.

Базовые принципы применения качества каналов приведены ниже.

• Маршрутизатор не анонсирует интерфейс соседа в любом состоянии без приемлемого L_quality:

  • если INITIAL_PENDING = true, канал анонсируется при условии L_quality >= HYST_ACCEPT;

  • в остальных случаях канал анонсируется при L_quality >= HYST_REJECT.

  Для канала, который еще не анонсирован, L_pending = true.

• После выполнения L_quality >= HYST_ACCEPT, маршрутизатор устанавливает L_pending := false, указывая, что канал можно анонсировать.

• Канал с L_pending = false анонсируется, пока L_quality не опустится ниже HYST_REJECT.

• Если L_pending = false и L_quality < HYST_REJECT, канал теряется (LOST) с анонсированием этого. Такой канал не рекомендуется кандидатом в HEARD или SYMMETRIC, пока не будет L_quality >= HYST_ACCEPT.

• Канал с приемлемым качеством может анонсироваться как HEARD, SYMMETRIC или LOST в соответствии с обменом сообщениями HELLO.

Для соблюдения этих принципов маршрутизатору недопустимо задавать:

• INITIAL_PENDING = false и INITIAL_QUALITY < HYST_REJECT или

• INITIAL_PENDING = true и INITIAL_QUALITY >= HYST_ACCEPT.

14.3. Действия при изменении качества канала

Если L_quality для канала меняется, должны выполняться указанные ниже действия.

1. Если L_quality >= HYST_ACCEPT, соответствующий Link Tuple меняется, как показано ниже.

   1. L_pending := false.

   2. L_lost := false.

   3. Если L_status = HEARD или L_status = SYMMETRIC, то

• • L_time := max(L_time, L_HEARD_time + L_HOLD_TIME).

2. Если L_status != PENDING и L_quality < HYST_REJECT, Link Tuple меняется, как показано ниже.

   1. Если L_lost = false, то:

• • L_lost := true;

  • L_time := min(L_time, текущее время + L_HOLD_TIME).

В результате такое обработки L_STATUS в Link Tuple может измениться. В этом случае должны также выполняться соответствующие изменения действия, как указано в разделе 13.

Если L_quality для канала меняется в результате приема сообщения HELLO или пакета с таким сообщением, значение L_quality должно обновляться до обработки HELLO, описанной в разделе 12 (если прием HELLO или пакета с ним создает Link Tuple, для него должно задаваться обновленное значение L_quality, а не L_quality := INITIAL_QUALITY).

14.4. Обновление Link Quality

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

• Сведения канального уровня, такие как отношение сигнал/шум, получение подтверждения или потеря пакета.

• Прием или потеря пакета управления. Если такие пакеты включают порядковые номера, как указано в [RFC5444], качество канала можно обновлять при получении пакета управления, независимо от наличия в нем сообщения HELLO. Качество канала может основываться на том, приняты ли последние N из M пакетов управления в канале, или на «индикаторе утечки», отслеживающем прием и потери.

• Прием или потеря сообщений HELLO. Если известен максимальный интервал между HELLO (например, в сообщения HELLO включен блок Message TLV с Type := INTERVAL_TIME, как указано в [RFC5497]), потерю HELLO можно увидеть без ожидания следующего сообщения HELLO. Отметим, что при сочетании этого варианта с предыдущим нужно позаботиться о том, чтобы потеря HELLO не учитывалась дважды.

15. Предлагаемые значения параметров и констант

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

15.1. Интервал между сообщениями для интерфейса

     HELLO_INTERVAL := 2 секунды
     HELLO_MIN_INTERVAL := HELLO_INTERVAL/4
     REFRESH_INTERVAL := HELLO_INTERVAL

15.2. Сроки действия информации для интерфейса

     H_HOLD_TIME := 3 x REFRESH_INTERVAL
     L_HOLD_TIME := H_HOLD_TIME

15.3. Сроки действия информации для маршрутизатора

     N_HOLD_TIME := L_HOLD_TIME
     I_HOLD_TIME := N_HOLD_TIME

15.4. Параметры качества канала для интерфейса

Если качество канала изменилось, значения параметров будут зависеть от обработки качества. Если качество не изменилось

     HYST_ACCEPT := 1
     HYST_REJECT := 0
     INITIAL_QUALITY := 1
     INITIAL_PENDING := false

15.5. Параметры вариаций задержки для интерфейса

     HP_MAXJITTER := HELLO_INTERVAL/4
     HT_MAXJITTER := HP_MAXJITTER

15.6. Константа

     C := 1/1024 сек.

16. Применение с другими протоколами

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

• Путем доступа (возможно расширения) к информации в Local Information Base (раздел 6), Interface Information Base (раздел 7) и Neighbor Information Base (раздел 8). Эти информационные базы содержат конфигурацию интерфейсов маршрутизатора, а также данные о локальных соединениях на расстоянии до 2 интервалов. Для всех обновлений элементов, заданных в этом документе, действуют ограничения, указанные в приложении B.

• Путем доступа к исходящему сообщению HELLO до его передачи через интерфейс MANET и добавления информации (например, TLV) в сообщение, как указано в [RFC5444]. Это позволяет, например, протоколам защиты, как указано в разделе 17, добавлять TLV с криптографической подписью сообщения или добавлять данные для выбора ретрансляторов в сообщение HELLO путем включения TLV в исходящее сообщение HELLO до его передачи.

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

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

• Путем запроса генерации сообщений HELLO в определенное время. В этом случае генерация HELLO должна происходить в соответствии с ограничениями приложения B.

Адресные объекты в сообщениях HELLO обрабатываются в соответствии со связанными с ними Address Block TLV. Все такие объекты обрабатываются в соответствии с данной спецификацией и связаны с Address Block TLV типа LOCAL_IF, OTHER_NEIGHB или LINK_STATUS (с расширением типа 0). Адресные объекты, не связанные с Address Block TLV какого-либо из указанных типов не обрабатываются описанным в спецификации протоколом.

Протоколам (таким, как протокол маршрутизации MANET), взаимодействующим с данным протоколом, может потребоваться добавить информацию в сообщения HELLO. Это может иметь форму связывания TLV (типов, отличных от LOCAL_IF, OTHER_NEIGHB, LINK_STATUS) с адресными объектами, включенными в данную спецификацию.

Такие протоколы могут также добавлять информацию в сообщения HELLO путем вставки адресных объектов, которые еще не включены в эту спецификацию. Такие адресные объекты далее называются «вставленными адресами». Эти адреса могут добавляться к имеющимся Address Block, которые созданы при генерации сообщения HELLO, или указываться в новых Address Blocks. В обоих случаях должны выполняться приведенные ниже условия.

• Вставленные адреса недопустимо связывать с Address Block TLV типов LOCAL_IF, OTHER_NEIGHB или LINK_STATUS. Поэтому обработка по данной спецификации будет игнорировать такие адресные объекты.

• Каждый вставленный адрес должен быть связан с Address Block TLV, определенным спецификацией добавляющего адресный объект протокола. Таким образом, все адреса в сообщении HELLO будут связаны с Address Block TLV, определяющими их семантику.

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

• Адресный объект в Address Block, не связанный с Address Block TLV, должен игнорироваться, а обработка таких блоков недопустима.

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

Строгое соблюдение этих пунктов обеспечит однозначное сосуществование с будущими расширениями сообщений HELLO.

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

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

Цель этого протокола заключается в том, чтобы каждый маршрутизатор сети мог получить информацию, описывающую соседей в одном интервале и соседей с симметричными соединениями в 2 интервалах. Это обеспечивается обменом сообщениями HELLO между соседними маршрутизаторами. Информация доступна через базы Interface Information Base и Neighbor Information Base, описывающие соседей в одном и двух интервалах.

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

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

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

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

Следует подчеркнуть еще один момент, следующий из приведенных выше рассуждений, – «нет одного уровня защиты, который подходит всем». В разных системах требования могут различаться. Например, в недорогой сенсорной сети может быть достаточно простой аутентификации по коду и шифрования с общим симметричным ключом, а развертывание дополнительных средств может потребовать слишком больших вычислительных ресурсов. И наоборот, в общественной сети может потребоваться не только проверка подлинности отправителя HELLO по наличию «правильного ключа», но и точная идентификация такого отправителя. При этом ресурсов для таких проверок в сети достаточно.

Поэтому в параграфе 17.2 не приводится «один механизм для всех», а рассматривается, как предложения [RFC5444] по защите могут применяться в контексте этого протокола и какие механизмы защиты следует разработать для конкретного развертывания.

17.1. Недействительные сообщения HELLO

Корректно сформированные, но непригодные сообщения HELLO могут иметь любую из приведенных ниже форм. Отметим, что наличие или отсутствие адресного объекта в Address Block само по себе не создает проблем. Проблемы могут быть вызваны наличие, отсутствием или некорректностью связанных Address Block TLV типа LOCAL_IF, LINK_STATUS, OTHER_NEIGHB.

Маршрутизатор может представить ложную самоидентификацию.

• Сообщение HELLO может содержать адресный объект со связанным LOCAL_IF Address Block TLV, не соответствующий адресам маршрутизатора, передавшего сообщение HELLO.

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

• Сообщение HELLO может некорректно задавать значение LOCAL_IF Address Block TLV, связанное с одним или несколькими адресами локальных сетевых интерфейсов, неверно указывающее связь с интерфейсом MANET, через который передано сообщение HELLO.

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

• Имеющийся LINK_STATUS Address Block TLV может некорректно указать сетевой адрес как адрес интерфейса MANET, который слышен или был слышен на интерфейсе MANET, передавшем HELLO.

• Отсутствующий LINK_STATUS Address Block TLV может некорректно указать сетевой адрес как относящийся к интерфейсу MANET, который слышен или был слышен на интерфейсе MANET, передавшем HELLO.

• Имеющийся OTHER_NEIGHB Address Block TLV может некорректно указать сетевой адрес как относящийся к маршрутизатору который является или был симметричным соседом 1-hop для передающего маршрутизатора.

• Отсутствующий OTHER_NEIGHB Address Block TLV может некорректно указать сетевой адрес как относящийся к маршрутизатору который является или был симметричным соседом 1-hop для передающего маршрутизатора.

• Value в LINK_STATUS Address Block TLV может некорректно указывать статус (LOST, SYMMETRIC, HEARD) канала от соседа 1-hop.

• Value в OTHER_NEIGHB Address Block TLV может некорректно указывать статус (LOST или SYMMETRIC) симметричного соседа 1-hop.

17.2. Предложения по аутентификации, целостности, конфиденциальности

Предложения [RFC5444] по защите, касающиеся включения криптографической подписи в Message TLV или Packet TLV, применимы к этому протоколу. Отказ при проверке любой формы криптографической подписи следует считать ошибкой, а сообщение HELLO следует отбрасывать без обработки.

Ниже описано упрощение предложений по сквозной аутентификации для защиты целостности [RFC5444] применительно к сообщениям HELLO.

• Поскольку поля заголовка сообщения (Message Header) <msg-hop-count> и <msg-hop-limit> пропускаются или всегда имеют значения 0 и 1 (соответственно), сквозная криптографическая подпись может быть рассчитана для всего сообщения HELLO, включая неизменный заголовок сообщения (Message Header).

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

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

Эта спецификация определяет одно значение Message Type, выделенное из реестра Message Types [RFC5444], и три типа Address Block TLV из реестра Address Block TLV Types [RFC5444].

18.1. Expert Review – рекомендации по оценке

Для реестров с политикой Expert Review назначенному эксперту следует придерживаться общих рекомендаций, приведенных в [RFC5444].

18.2. Типы сообщений

Эта спецификация определяет одно значение Message Type, выделенное из диапазона 0-223 в пространстве имен Message Types, определенном в [RFC5444], как показано в таблице 3.

Таблица 3. Выделенное значение для типа сообщений.

Тип	Описание
LOCAL_IF	HELLO – локальная сигнализация.

18.3. Реестры Message-Type-Specific TLV Type

Агентство IANA создало реестр Message-Type-specific Message TLV для сообщений HELLO в соответствии с параграфом 6.2.1 [RFC5444], начальные значения и политика распределения в котором приведены в таблице 4.

Таблица 4. Типы TLV.

 

Тип	Описание	Процедура
128-223	Не распределены.	Expert Review

 

Агентство IANA создало реестр Message-Type-specific Address Block TLV для сообщений HELLO в соответствии с параграфом 6.2.1 [RFC5444], начальные значения и политика распределения в котором приведены в таблице 5.

Таблица 5. Типы Address Block TLV.

 

Тип	Описание	Процедура
128-223	Не распределены.	Expert Review

 

18.4. Типы Address Block TLV

Эта спецификация определяет 3 типа Address Block TLV, которые выделены из пространства имен Address Block TLV Types, определенного в [RFC5444]. Для этих типов выделены значения из диапазона 0-127. Созданы три новых реестра расширений типов, начальные значения которых приведены в таблицах 6 – 8. Спецификации этих Address Block TLV даны в параграфе 10.1.1, а константы определены в параграфе 18.5.

Таблица 6. Распределение типов Address Block TLV – LOCAL_IF.

Имя	Тип	Расширение	Описание	Процедура
LOCAL_IF	2	0	Указывает, что сетевые адреса связаны с этим (THIS_IF=0) или иным (OTHER_IF=1) локальным интерфейсом передающего маршрутизатора.
LOCAL_IF	2	1-255	Не распределены.	Expert Review

Таблица 7. Распределение типов Address Block TLV – LINK_STATUS.

Имя	Тип	Расширение	Описание	Процедура
LINK_STATUS	3	0	Указывает статус канал от обозначенного сетевого адреса (LOST=0, SYMMETRIC=1 или HEARD=2).
LINK_STATUS	3	1-255	Не распределены	Expert Review

Таблица 8. Распределение типов Address Block TLV – OTHER_NEIGHB.

Имя	Тип	Расширение	Описание	Процедура
OTHER_NEIGHB	4	0	Указывает статус взаимоотношений с маршрутизатором, который использует сетевой адрес одного или нескольких интерфейсов (LOST=0 или SYMMETRIC=1)
OTHER_NEIGHB	4	1-255	Не распределены.	Expert Review

18.5. Значения LOCAL_IF, LINK_STATUS, OTHER_NEIGHB

Эта информация приведена здесь для четкости и использования в других местах спецификации. Сведения, нужные IANA, включены в описание Address Block TLV (параграф 18.4).

Ниже приведены Value для LOCAL_IF в Address Block TLV.

   THIS_IF := 0
   OTHER_IF := 1

Ниже приведены Value для LINK_STATUS в Address Block TLV.

   LOST := 0
   SYMMETRIC := 1
   HEARD := 2

Ниже приведены Value для OTHER_NEIGHB в Address Block TLV.

   LOST := 0
   SYMMETRIC := 1

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

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

• Brian Adamson, NRL, USA, <adamson@itd.nrl.navy.mil>;

• Cedric Adjih, INRIA, France, <Cedric.Adjih@inria.fr>;

• Thomas Heide Clausen, LIX, France, <T.Clausen@computer.org>;

• Justin Dean, NRL, USA, <jdean@itd.nrl.navy.mil>;

• Christopher Dearlove, BAE Systems ATC, UK, <chris.dearlove@baesystems.com>;

• Philippe Jacquet, INRIA, France, <Philippe.Jacquet@inria.fr>.

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

Авторы хотели бы поблагодарить участников команды OLSRv1, указанных в RFC3626, за их вклад.

Авторы признательны за технические обсуждения, ранние рецензии и комментарии к спецификации и ее компонентам Alan Cullen (BAE Systems), Ulrich Herberg (LIX), Satoh Hiroki (Hitachi) Joe Macker (NRL), Charles E. Perkins (WiChorus), Laurent Viennot (INRIA) (указаны по алфавиту) и всей рабочей группе IETF MANET.

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

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

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

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

[RFC2501] Corson, M. and J. Macker, “Mobile Ad hoc Networking (MANET): Routing Protocol Performance Issues and Evaluation Considerations”, RFC 2501, January 1999.

[RFC3626] Clausen, T. and P. Jacquet, “Optimized Link State Routing Protocol (OLSR)”, RFC 3626, October 2003.

[RFC5449] Baccelli, E., Jacquet, P., Nguyen, D., and T. Clausen, “OSPF Multipoint Relay (MPR) Extension for Ad Hoc Networks”, RFC 5449, February 2009.

Приложение A. Комбинации Address Block TLV

Алгоритм генерации сообщений HELLO (раздел 11) указывает, какие из адресов соседей 1-hop могут быть включены в Address Block и с какими связанными Address Block TLV. Эти Address Block TLV могут иметь тип LINK_STATUS, OTHER_NEIGHB или оба. Address Block TLV типа LINK_STATUS могут иметь 3 возможных значения (HEARD, SYMMETRIC, LOST), а Address Block TLV типа OTHER_NEIGHB – 2 (SYMMETRIC или LOST). При связывании обоих Address Block TLV с одним сетевым адресом необходимы лишь некоторые комбинации значений этих Address Block TLV и только они генерируются алгоритмом из раздела 11. Эти комбинации приведены в таблице 9.

Значение «да» указывает возможные комбинации, генерируемые алгоритмом из раздела 11, «нет» указывают комбинации, которые не генерируются этим алгоритмом, но могут быть корректно проанализированы и интерпретированы алгоритмом из раздела 12. Ячейка «нет*» на деле противоречива – она обрабатывается с игнорированием Address Block TLV типа OTHER_NEIGHB, но применять это не следует.

Таблица 9. Комбинации LINK_STATUS и OTHER_NEIGHB TLV.

	Type = OTHER_NEIGHB, (отсутств.)	Type = OTHER_NEIGHB, Value = SYMMETRIC	Type = OTHER_NEIGHB, Value = LOST
Type = LINK_STATUS, (отсутств.)	нет	да	да
Type = LINK_STATUS, Value = HEARD	да	да	да
Type = LINK_STATUS, Value = SYMMETRIC	да	нет	нет*
Type = LINK_STATUS, Value = LOST	да	да	нет

Приложение B. Ограничения

Любой процесс, обновляющий Local Information Base или Neighbor Information Base должен обеспечивать соблюдение всех приведенных в этом приложении ограничений.

В каждом Local Interface Tuple:

• I_local_iface_addr_list недопустимо быть пустым;

• I_local_iface_addr_list недопустимо содержать дубликаты сетевых адресов;

• если I_manet = true, в I_local_iface_addr_list недопустимо включать сетевые адреса, перекрывающиеся с любым адресом в I_local_iface_addr_list любого другого Local Interface Tuple с I_manet = true, пока не известно, что соответствующие интерфейсы MANET всегда будут взаимодействовать с отдельными наборами интерфейсов MANET на других маршрутизаторах.

В каждом Removed Interface Address Tuple:

• IR_local_iface_addr недопустимо содержать сетевой адрес, имеющийся в I_local_iface_addr_list любого Local Interface Tuple;

• IR_local_iface_addr недопустимо совпадать с IR_local_iface_addr любого другого Removed Interface Address Tuple.

В каждом Link Tuple:

• L_neighbor_iface_addr_list недопустимо быть пустым;

• L_neighbor_iface_addr_list недопустимо содержать сетевой адрес, перекрывающийся с любым адресом в I_local_iface_addr_list любого Local Interface Tuple или IR_local_iface_addr любого Removed Interface Address Tuple;

• L_neighbor_iface_addr_list недопустимо содержать дубликаты сетевых адресов;

• L_neighbor_iface_addr_list недопустимо содержать сетевой адрес, имеющийся в L_neighbor_iface_addr_list любого другого Link Tuple в том же Link Set;

• Если время L_HEARD_time не истекло, должен быть Neighbor Tuple с N_neighbor_addr_list, содержащим L_neighbor_iface_addr_list;

• недопустимо L_HEARD_time > L_time, если не выполняется условие L_lost = true⁸;

• L_SYM_time недопустимо быть больше L_HEARD_time (пока оба не истекли);

• L_quality недопустимо быть меньше 0 или больше 1;

• если L_quality >= HYST_ACCEPT, должно быть L_pending = false;

• если L_quality < HYST_REJECT, L_status должен быть PENDING или LOST;

• для L_pending недопустимо устанавливать значение true при текущем значении false.

В каждом Neighbor Tuple:

• N_neighbor_addr_list недопустимо содержать сетевой адрес, перекрывающийся с любым адресом в I_local_iface_addr_list любого Local Interface Tuple или IR_local_iface_addr любого Removed Interface Address Tuple;

• N_neighbor_addr_list недопустимо содержать дубликаты сетевых адресов;

• N_neighbor_addr_list недопустимо содержать сетевой адрес, имеющийся в N_neighbor_addr_list любого другого Neighbor Tuple;

• если N_symmetric is = true, должен быть один или несколько Link Tuples с

  • L_neighbor_iface_addr_list из N_neighbor_addr_list и

  • L_status = SYMMETRIC;

• если N_symmetric is = false, должен быть один или несколько Link Tuples с

  • L_neighbor_iface_addr_list из N_neighbor_addr_list.

Всем таким Link Tuple недопустимо иметь L_status = SYMMETRIC. Хотя бы один такой Link Tuple должен иметь не истекшее время L_HEARD_time.

В каждом Lost Neighbor Tuple:

• NL_neighbor_addr недопустимо перекрываться с любым сетевым адресом в I_local_iface_addr_list любого Local Interface Tuple или IR_local_iface_addr любого Removed Interface Address Tuple;

• NL_neighbor_addr недопустимо совпадать с NL_neighbor_addr любого другого Lost Neighbor Tuple;

• NL_neighbor_addr недопустимо быть в N_neighbor_addr_list любого Neighbor Tuple с N_symmetric = true.

В каждом 2-Hop Tuple:

• должен быть Link Tuple с тем же интерфейсом MANET с

  • L_neighbor_iface_addr_list = N2_neighbor_iface_addr_list и

  • L_status = SYMMETRIC;

• N2_2hop_addr недопустимо перекрываться с любым сетевым адресом в I_local_iface_addr_list любого Local Interface Tuple или IR_local_iface_addr любого Removed Interface Address Tuple;

• N2_2hop_addr недопустимо быть N2_2hop_addr любого другого 2-Hop Tuple в том же 2-Hop Set и с таким же N2_neighbor_iface_addr_list;

• N2_2hop_addr недопустимо быть в N2_neighbor_iface_addr_list того же 2-Hop Tuple.

Приложение C. Пример сообщения HELLO

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

4-битовое поле флагов HELLO (MF – Message Flags) имеет значение 7, указывающее, что заголовок содержит поля ограничения числа интервалов, счетчика интервалов и порядкового номера сообщения. 4-битовое поле размера адреса (MAL – Message Address Length) имеет значение 3, указывающее, что адреса в сообщении имеют размер 4 октета (IPv4). Сообщение передано с hop limit = 1 и hop count = 0. Общий размер сообщения составляет 45 октетов.

Сообщение содержит Message TLV Block с 8 октетами, включающими 2 Message TLV типов VALIDITY_TIME и INTERVAL_TIME. Каждый применяет Message TLV с октетом флагов (MTLVF) 16, указывающим наличие в каждом поля Value размером (Value Length) в 1 октет. Поля Value содержат коды времени (в соответствии с [RFC5497]) представляющие параметры H_HOLD_TIME и HELLO_INTERVAL, соответственно.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     HELLO     | MF=7  | MAL=3 |      Message Length = 45      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop Limit = 1 | Hop Count = 0 |    Message Sequence Number    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message TLV Block Length = 8  | VALIDITY_TIME |  MTLVF = 16   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value Len = 1 | Value (Time)  | INTERVAL_TIME |  MTLVF = 16   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value Len = 1 | Value (Time)  | Num Addrs = 5 |   ABF = 128   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Head Len = 3  |                     Head                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Mid 0     |     Mid 1     |     Mid 2     |     Mid 3     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Mid 4     | Address TLV Block Length = 14 |   LOCAL_IF    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  ATLVF = 80   |   Index = 0   | Value Len = 1 |    THIS_IF    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  LINK_STATUS  |   ATLV = 52   | Strt Indx = 1 | Stop Indx = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value Len = 4 |     HEARD     |     HEARD     |   SYMMETRIC   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     LOST      |
+-+-+-+-+-+-+-+-+

Сообщение имеет один Address Block с 5 адресами. Октет флагов Address Block (ABF) имеет значение 128, указывающее наличие Head, но отсутствие Tail и префикса. Размер Head (3 октета) указывает разделы Mid для адресов в один октет каждый (Mid 0 – Mid 4).

Следующий блок Address Block TLV (14 октетов) включает 2 Address Block TLV. Первый является LOCAL_IF Address Block TLV с октетом флагов (ATLVF) 80, который указывает, что 1 адрес с индексом 0 (т. е. Head:Mid 0) является адресом одного локального интерфейса маршрутизатора (1 октет Value THIS_IF показывает что это адрес данного интерфейса). Второй является LINK_STATUS Address Block TLV с октетом флагов (ATLVF) 52 и задает значения статуса каналов всех сообщенных соседей в одном Address Block TLV со множеством значений, покрывающем адреса с индексами 1 – 4, включительно. Размер значения Address Block TLV в 4 октета указывает 1 октет на Value для адреса. Последние 4 адреса являются, таким образом, соседями, каждый из которых имеет статус канала – первый и второй – HEARD, третий – SYMMETRIC, четвертый – LOST.

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

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     HELLO     |0 0 0 0 0 0 1 1|0 0 0 0 0 0 0 0 0 0 0 1 1 1 0 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0| VALIDITY_TIME |0 0 0 1 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 1|0 1 1 0 0 1 0 0|0 0 0 0 0 1 0 0|1 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 1 1|                     Head                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Mid 1     |     Mid 2     |     Mid 3     |     Mid 4     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1|  LINK_STATUS  |0 0 0 1 0 1 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 1 0 0|     HEARD     |     HEARD     |   SYMMETRIC   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     LOST      |
+-+-+-+-+-+-+-+-+

Отметим, что в этом примере H_HOLD_TIME и C имеют принятые по умолчанию значения (6 секунд и 1/1024 сек.), что приводит к коду времени 100 (64 в шестнадцатеричной форме).

Приложение D. Контроль потоков и перегрузок

Этот протокол задает 1 тип сообщений – HELLO. Максимальный размер HELLO пропорционален размеру окрестности 1-hop передающего маршрутизатора. Пересылка сообщений HELLO недопустима.

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

Маршрутизатор должен гарантировать, что два последовательных сообщения HELLO с одного интерфейса MANET разделены интервалом не меньше HELLO_MIN_INTERVAL (при учете вариаций значение может быть уменьшено до среднего минимального значения HELLO_MIN_INTERVAL – HP_MAXJITTER/2). Это устанавливает верхнюю границу для трафика управления, создаваемого каждым маршрутизатором в сети, использующей этот протокол.

Приложение E. Интервалы и таймеры

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

E.1. Тактирование генерации сообщений HELLO

На рисунке 1 показано базовое планирование сообщений HELLO для маршрутизатора на интерфейсе MANET, реализующем строго периодическую отправку сообщений HELLO. Маршрутизатор передает HELLO каждый интервал HELLO_INTERVAL. Каждое сообщение HELLO содержит адреса соседей 1-hop, которые указываются в каждом таком HELLO (параметр REFRESH_INTERVAL, не показанный в примере, совпадает с HELLO_INTERVAL).

H_HOLD_TIME:         |-----------------------------|   ...
HELLO_INTERVAL:      |---------|---------|---------|   ...
Время             ---*---------*---------*---------*------>
                     ^         ^         ^         ^
                     |         |         |         |
    HELLO (a, b, c, d)         |         |         |
                               |         |         |
              HELLO (a, b, c, d)         |         |   ...
                                         |         |
                        HELLO (a, b, c, d)         |
                                                   |
                                  HELLO (a, b, c, d)

L_time:              |-----------------------------|
                               |--------------------   ...
                                         |----------   ...
                                                   |   ...

Рисунок 1. Генерация регулярного сообщения HELLO.

Маршрутизатор включает VALIDITY_TIME TLV в каждое сообщение HELLO, представляя параметр H_HOLD_TIME, указывающий в течение какого времени информацию из HELLO принявшему маршрутизатору следует считать действительной. Принимающие маршрутизаторы при записи информации из сообщения HELLO будут применять это значение для установки элементов L_HEARD_time, L_SYM_time и L_time в соответствующих Link Tuple и N2_time в соответствующем 2-Hop Tuple для каждого сетевого адреса. На рисунке 1 указано только L_time.

На рисунке 2 представлено планирование сообщений, похожее на рисунок 1, где маршрутизатор анонсирует свое присутствие передачей дополнительных сообщений HELLO. Сообщения HELLO передаются регулярно с уменьшенным интервалом, определяемым HELLO_INTERVAL. Однако значение REFRESH_INTERVAL не уменьшается. Адрес каждого соседа 1-hop, включенный в HELLO, требуется анонсировать лишь 1 раз за каждый интервал REFRESH_INTERVAL. Поэтому дополнительные сообщения HELLO могут быть пустыми в результате снижения HELLO_INTERVAL (это не единственный разрешенный способ распространения сетевых адресов соседей 1-hop, они могут, например, отправляться поочередно – a, b и c, d).

H_HOLD_TIME:         |-----------------------------|   ...
REFRESH_INTERVAL:    |---------|---------|---------|   ...
HELLO_INTERVAL:      |----|----|----|----|----|----|   ...
Время             ---*---------*---------*---------*------>
                     ^    ^    ^    ^    ^    ^    ^
                     |    |    |    |    |    |    |
    HELLO (a, b, c, d)    |    |    |    |    |    |
                          |    |    |    |    |    |
                   HELLO ()    |    |    |    |    |
                               |    |    |    |    |
              HELLO (a, b, c, d)    |    |    |    |
                                    |    |    |    |   ...
                             HELLO ()    |    |    |
                                         |    |    |
                        HELLO (a, b, c, d)    |    |
                                              |    |
                                       HELLO ()    |
                                                   |
                                  HELLO (a, b, c, d)

L_time:              |-----------------------------|
                          |-------------------------   ...
                               |--------------------   ...
                                    |---------------   ...
                                         |----------   ...
                                              |-----   ...
                                                   |   ...

Рисунок 2. Генерация регулярного сообщения HELLO при разных HELLO_INTERVAL и REFRESH_INTERVAL.

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

H_HOLD_TIME:         |-----------------------------|   ...
HELLO_INTERVAL:      |---------|---------|---------|   ...
HELLO_MIN_INTERVAL:  |----|----|----|----|----|----|   ...
Время             ---*---------*---------*---------*------>
                     ^    ^    ^    ^    ^    ^    ^
                     |    |    |    |    |    |    |
              HELLO ()    |    |    |    |    |    |
                          |    |    |    |    |    |
                  HELLO (a)    |    |    |    |    |
                               |    |    |    |    |
                    HELLO (a, b)    |    |    |    |
                                    |    |    |    |   ...
                      HELLO (a, b, c)    |    |    |
                                         |    |    |
                        HELLO (a, b, c, d)    |    |
                                              |    |
                          HELLO (a, b, c, d, e)    |
                                                   |
                            HELLO (a, b, c, d, e, f)

L_time:              |-----------------------------|
                          |-------------------------   ...
                               |--------------------   ...
                                    |---------------   ...
                                         |----------   ...
                                              |-----   ...
                                                   |   ...

Рисунок 3. Генерация сообщений HELLO – регулярная и по событиям.

На рисунке 3 показано планирование сообщений, похожее на рисунок 1, но с отправкой HELLO по событиям с максимальной скоростью – 1 сообщение HELLO за каждый интервал HELLO_MIN_INTERVAL. Отметим, что при передаче HELLO предполагается, что следующие сообщения будут планироваться с интервалом HELLO_INTERVAL, поэтому каждое сообщение HELLO содержит все сетевые адреса соседей 1-hop. В каждом сообщении HELLO этого примера добавляется новый адрес соседа 1-hop в соответствии с изменениями, произошедшими после отправки последнего сообщения HELLO. Сообщения HELLO передаются с максимальной разрешенной скоростью для обеспечения быстрой сигнализации об изменениях.

На рисунке 4 показан случай похожий на рисунок 3, но в увеличенным REFRESH_INTERVAL и показом частичных сообщений HELLO, включающих лишь необходимые сетевые адреса.

H_HOLD_TIME:         |-----------------------------|   ...
REFRESH_INTERVAL:    |-------------------|----------   ...
                          |-------------------|-----   ...
                               |-------------------|   ...
                                    |---------------   ...
                                         |----------   ...
                                              |-----   ...
                                                   |   ...
HELLO_INTERVAL:      |---------|---------|---------|   ...
HELLO_MIN_INTERVAL:  |----|----|----|----|----|----|   ...
Время             ---*---------*---------*---------*------>
                     ^    ^    ^    ^    ^    ^    ^
                     |    |    |    |    |    |    |
              HELLO ()    |    |    |    |    |    |
                          |    |    |    |    |    |
                  HELLO (a)    |    |    |    |    |
                               |    |    |    |    |
                       HELLO (b)    |    |    |    |
                                    |    |    |    |   ...
                            HELLO (c)    |    |    |
                                         |    |    |
                              HELLO (a, d)    |    |
                                              |    |
                                   HELLO (b, e)    |
                                                   |
                                        HELLO (c, f)

L_time:              |-----------------------------|
                          |-------------------------   ...
                               |--------------------   ...
                                    |---------------   ...
                                         |----------   ...
                                              |-----   ...
                                                   |   ...

Рисунок 4. Генерация сообщений HELLO – регулярно и по событиям при разных HELLO_INTERVAL и REFRESH_INTERVAL.

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

H_HOLD_TIME:         |------------------------------------|
REFRESH_INTERVAL:    |----------------|
HELLO_INTERVAL:      |----------|
HELLO_MIN_INTERVAL:  |---|
Время             ----------------------------------------------->
                     ^   ^      ^     ^                   ^
                     |   |      |     |                   |
                     |   |      |     |           Время, до которого
             Передача    |      |     |           действительно 
      сообщения HELLO    |      |     |           содержимое принятого
                         |      |     |           сообщения HELLO.
                         |      |     |
                         |      |     Время, до которого вся
                         |      |     информация о соседях должна
                         |      |     быть передана в сообщениях 
                         |      |     HELLO (одном или нескольких).
                         |      |
                         |      Самое позднее время отправки
                         |      следующего сообщения HELLO.
                         |
                         Самое раннее время отправки
                         следующего сообщения HELLO.

Рисунок 5. Интервалы генерации сообщений HELLO.

E.2. Тактирование обработки сообщения HELLO

На рисунке 6 показаны таймеры Link при получении HELLO без сетевого адреса принявшего интерфейса MANET.

VALIDITY_TIME:    |--------------------------|
L_time:           |--------------------------|
L_HEARD_time:     |--------------------------|
L_SYM_time:     *-| (i.e.,  expired)
Время          ---*-------------------------------->
                  ^
                  |
   Принято HELLO ()

Рисунок 6. Обработка сообщения HELLO при отсутствии сетевых адресов.

На рисунке 7 показаны таймеры Link Set, когда вслед за сообщением HELLO, показанным на рисунке 6, маршрутизатор принимает HELLO с адресом (a) принимающего интерфейса с состоянием канала HEARD (или SYMMETRIC).

VALIDITY_TIME:    |--------------------------|
                        |--------------------------|
L_time:           |--------------------------|
                        |--------------------------|
L_HEARD_time:     |--------------------------|
                        |--------------------------|
L_SYM_time:     *-| (т. е. время истекло)
L_SYM_time:             |--------------------------|
Время            -*-----*--------------------------------->
                  ^     ^
                  |     |
   Принято HELLO ()     |
                        |
 Принято HELLO (a:HEARD)

Рисунок 7. Обработка сообщения HELLO при наличии сетевых адресов.

На рисунке 8 показаны таймеры Link Set, когда вслед за сообщением HELLO, показанным на рисунке 7, маршрутизатор получает HELLO с сетевым адресом (a) принимающего интерфейса со статусом канала LOST.

VALIDITY_TIME:    |--------------------------|
                        |--------------------------|
                              |--------------------------|
L_time:           |--------------------------|
                        |--------------------------|
                              |--------------------------|
L_HEARD_time:     |--------------------------|
                        |--------------------------|
                              |--------------------------|
L_SYM_time:     *-| (т. е. время истекло)
                        |--------------------------|
                            *-| (т. е. время истекло)
Время            -*-----*-----*--------------------------------->
                  ^     ^     ^
                  |     |     |
   Принято HELLO ()     |     |
                        |     |
  Принято HELLO (a:HEARD)     |
                              |
         Принято HELLO (a:LOST)

Рисунок 8. Обработка сообщения HELLO при потере сетевого адреса.

E.3. Тактирование других сообщений HELLO

Есть 3 других параметра синхронизации, которые маршрутизатор применяет для контроля генерации и обработки сообщений HELLO.

На рисунке 9 показан интервал L_HOLD_TIME, в течение которого адреса, которые были (но перестали) адресами симметричных соседей 1-hop, подключенных к этому интерфейсу MANET, анонсируются как потерянные (LOST) с использованием LINK_STATUS TLV в сообщениях HELLO на этом интерфейсе MANET, позволяя соседу 1-hop обновить подобающим образом свой Link Set.

L_HOLD_TIME:   |----------------------------|
Время       ---*---------------------------------->
               ^                            ^
               |                            |
    Ранее симметричный сосед 1-hop          |
    перестал быть симметричным на           |
    этом интерфейсе MANET                   |
                                            |
                 Время, до которого сетевые адреса этого
                 соседа, подключенного через данный
                 интерфейс MANET, анонсируеются в
                 сообщениях HELLO этого интерфейса MANET 
                 с LINK_STATUS TLV, Value = LOST

Рисунок 9. Создание сообщения HELLO при потере ближайшего соседа с симметричным подключением на интерфейсе MANET.

На рисунке 10 показан интервал N_HOLD_TIME, в течение которого все сетевые адреса, которые были (но перестали) быть адресами симметричного соседа 1-hop, анонсируются как LOST в сообщениях HELLO на всех интерфейса MANET с использованием OTHER_NEIGHB TLV (если не указываются также с использованием LINK_STATUS TLV), что позволяет другим симметричным соседям 1-hop обновить должным образом свои 2-Hop Set.

L_HOLD_TIME:   |----------------------------|
Время       ---*---------------------------------->
               ^                            ^
               |                            |
    Ранее симметричный сосед 1-hop          |
    перестал быть симметричным              |
                                            |
                 Время, до которого сетевые адреса этого
                 соседа анонсируются в сообщениях HELLO
                 на всех интерфейсах MANET с использованием
                 OTHER_NEIGHB TLV, Value = LOST

Рисунок 10. Создание сообщения HELLO при потере ближайшего соседа с симметричным подключением на любом интерфейсе MANET.

На рисунке 11 показан интервал I_HOLD_TIME, в течение которого адреса, которые использовались (но перестали) локальным интерфейсом, исключаются из числа считающихся сетевыми адресами соседей 2-hop (чтобы маршрутизатор не записывал их как своих соседей 2-hop в течение этого периода).

I_HOLD_TIME:      |----------------------------|
Время          ---*----------------------------------->
                  ^                            ^
                  |                            |
  Время, когда используемый локальным          |
  интерфейсом сетевой адрес был утрачен        |
                                               |
                          Время, когда этот сетевой адрес
                          перестает включаться в 2-Hop Set
                          данного маршрутизатора

Рисунок 11. Удаление сетевого адреса на локальном интерфейсе.

Приложение F. Варианты топологии

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

Приведенные примеры не являются исчерпывающими и выбраны для представления в NHDP соседских отношений физической топологии MANET.

Примеры включают три физических маршрутизатора (A, B, C), каждый из которых имеет один или два интерфейса, обозначенные как верхний (top) и нижний (bottom). Каждый интерфейс имеет один или два адреса, а симметричные соединения между парами интерфейсов показаны на рисунке линиями.

Во всех примерах топология представлена как записанная протоколом NHDP в маршрутизаторе A.

F.1. Пример 1 – стандартная топология с одним интерфейсом

На рисунке 12 каждый маршрутизатор имеет 1 интерфейс с одним адресом IP. Это простейшая из возможных сетей и ее представление показано справа на рисунке 12.

    __________ __________
   |          |          |
  {1}        {2}        {3}
   |          |          |              {1}--------{2}--------{3}
+--'--+    +--'--+    +--'--+
|  A  |    |  B  |    |  C  |
+-----+    +-----+    +-----+

Рисунок 12. Стандартная топология с одним интерфейсом (слева) и представление NHDP.

Local Information Set в A содержит один Local Interface Tuple с I_local_iface_addr_list = {1}. Это значение показано как {1} в левой части рисунка.

Interface Information Base имеет лишь один Link Set, представляющий «верхний» интерфейс A или {1}. В этом Link Set единственный Link Tuple имеет L_neighbor_iface_addr_list, содержащий {2}, это соответствует пунктирной линии от {1} к {2} в правой части рисунка 12. 2-Hop Set содержит один 2-Hop Tuple с N2_neighbor_iface_addr_list = {2} и N2_2hop_addr = {3}, это соответствует пунктирной линии от {2} к {3} в правой части рисунка 12.

В последующих примерах этого приложения используются похожие описания и нотация.

F.2. Пример 2 – интерфейс с 2 адресами у ближайшего соседа

Сеть на рисунке 13 идентична примеру 1, но средний маршрутизатор B имеет 2 адреса IP на одном интерфейсе.

    __________ __________
   |          |          |
  {1}       {2,4}       {3}
   |          |          |              {1}-------{2,4}-------{3}
+--'--+    +--'--+    +--'--+
|  A  |    |  B  |    |  C  |
+-----+    +-----+    +-----+

Рисунок 13. Одиночные интерфейсы с ближайшим соседом B, имеющим 2 адреса (слева), и представление NHDP.

Содержимое Interface Information Base идентично примеру 1, но L_neighbor_iface_addr_list = {2,4} и N2_neighbor_iface_addr_list = {2,4}.

F.3. Пример 3 – интерфейс с 2 адресами у соседа второго уровня

Сеть на рисунке 13 идентична примеру 1, но средний правый C имеет 2 адреса IP на одном интерфейсе.

    __________ __________
   |          |          |
  {1}        {2}       {3,4}                             +----{3}
   |          |          |              {1}--------{2}---+
+--'--+    +--'--+    +--'--+                            +----{4}
|  A  |    |  B  |    |  C  |
+-----+    +-----+    +-----+

Рисунок 14. Одиночные интерфейсы с соседом 2-Hop C, имеющим 2 адреса (слева), и представление NHDP.

Содержимое Interface Information Base идентично примеру 1, но 2-Hop Set содержит дополнительный 2-Hop Tuple с N2_neighbor_iface_addr_list = {2} и N2_2hop_addr = {4}. Эти 2-Hop Tuple показаны справа пунктирами от {2} к {3} и от {2} к {4}, соответственно.

F.4. Пример 4 – интерфейсы с двумя адресами

Сеть на рисунке 15 идентична примеру 1, но все маршрутизаторы имеют по 2 адреса IP на интерфейсе. Local Information Base в A совпадает с примером 1, но I_local_iface_addr_list = {1,5}.

    __________ __________
   |          |          |
 {1,5}      {2,6}      {3,4}                             +----{3}
   |          |          |             {1,5}------{2,6}--+
+--'--+    +--'--+    +--'--+                            +----{4}
|  A  |    |  B  |    |  C  |
+-----+    +-----+    +-----+

Рисунок 15. Одиночные интерфейсы на всех маршрутизаторах, имеющие 2 адреса (слева), и представление NHDP.

Содержимое Interface Information Base в этом случае идентично комбинации Interface Information Base из примеров 1-3.

F.5. Пример 5 – два интерфейса у соседа второго уровня

На рисунке 16 все маршрутизаторы имеют 1 адрес IP на интерфейс, а сосед 2-hop имеет два интерфейса.

    __________ __________
   |          |          |
  {1}        {2}        {3}                              +----{3}
   |          |          |              {1}--------{2}---+
+--'--+    +--'--+    +-----+                            +----{4}
|  A  |    |  B  |    |  C  |
+-----+    +-----+    +-----+
                         |
                        {4}

Рисунок 16. Одиночные адреса с соседом 2-Hop C, имеющим 2 интерфейса (слева), и представление NHDP.

Interface Information Base идентична примеру 3 и NHDP топологически не различаются.

F.6. Пример 6 – два интерфейса у ближайшего соседа

На рисунке 17 все маршрутизаторы имеют 1 адрес IP на интерфейс, а сосед 1-hop имеет два интерфейса.

    __________
   |          |
  {1}        {2}                                  +-----+
   |          |                         {1}-------| {2} |------{4}
+--'--+    +--'--+    +-----+                     | {5} |
|  A  |    |  B  |    |  C  |                     +-----+
+-----+    +-----+    +-----+
              |          |
             {5}        {4}
              |__________|

Рисунок 17. Одиночные адреса с соседом 1-Hop B, имеющим 2 интерфейса (слева), и представление NHDP.

Local Information Base идентична примеру 1.

Interface Information Base имеет единственный Link Set, содержащий один Link Tuple = L_neighbor_iface_addr_list = {2}. 2-Hop Set содержит один 2-Hop Tuple с N2_neighbor_iface_addr_list = {2} и N2_2hop_addr = {4}.

Neighbor Information Base содержит Neighbor Set с одним Neighbor Tuple, который представляет маршрутизатор B с N_neighbor_addr_list = {2,5}. Эта запись представлена справа на рисунке 17 прямоугольником с {2} и {5}.

Отметим, что у маршрутизатора A нет информации, показывающей, что интерфейсы маршрутизатора B соединены с маршрутизатором C. Однако A знает, что адрес {4} (и маршрутизатор C) достижим через {2}.

F.7. Пример 7 – сдвоенный интерфейс с соседями 1-Hop и 2-Hop

На рисунке 18 все маршрутизаторы имеют 1 адрес IP на интерфейс, а соседи 1-hop и 2-hop имеют по 2 интерфейса. Кроме того, имеется 2 физических соединения между маршрутизаторами B и C через разные пары интерфейсов.

    __________ __________
   |          |          |
  {1}        {2}        {3}                      +-----+   +----{3}
   |          |          |             {1}-------| {2} |---+
+--'--+    +--'--+    +-----+                    | {5} |   +----{4}
|  A  |    |  B  |    |  C  |                    +-----+
+-----+    +-----+    +-----+
              |          |
             {5}        {4}
              |__________|

Рисунок 18. Одиночные адреса с соседом 1-Hop B и соседом 2-Hop C, имеющими по 2 интерфейса (слева), и представление NHDP.

Local Information Base идентична примеру 1.

Link Set идентичен примеру 6, а 2-Hop Set содержит, как в примере 5 (и подобно примерам 3 и 4), два 2-Hop Tuple, представляющие два канала между маршрутизаторами B и C.

Отметим, что маршрутизатор A не имеет информации, описывающей соединения между интерфейсами B и C, а также не знает, что интерфейсы с адресами {3} и {4} находятся на одном маршрутизаторе. Однако A знает, что адреса {3} и {4} (маршрутизатор C) доступны через {2}.

F.8. Пример 8 – cдвоенный интерфейс локально и у ближайшего соседа

На рисунке 19 все маршрутизаторы имеют 1 адрес IP на интерфейс, а маршрутизатор A и его ближайший сосед B имеют по 2 интерфейса. Кроме того, имеется 2 физических соединения между маршрутизаторами A и B через разные пары интерфейсов.

    __________ __________
   |          |          |                       +-----+
  {1}        {2}        {3}            {1}-------| {2} |--------{3}
   |          |          |                       | {5} |
+--'--+    +--'--+    +-----+                    +-----+
|  A  |    |  B  |    |  C  |
+-----+    +-----+    +-----+                    +-----+
   |          |                                  | {2} |
  {6}        {5}                       {6}-------| {5} |--------{3}
   |__________|                                  +-----+

Рисунок 19. Одиночные адреса с соседями 1-Hop A и B, имеющими по 2 интерфейса (слева), и представление NHDP.

Local Information Set содержит 2 Local Interface Tuple с I_local_iface_addr_list = {1} и {6}, соответственно.

В каждой Interface Information Base набор Link Set содержит один Link Tuple, представляющий каналы между {1} и {2} и между {6} и {5}, соответственно. 2-Hop Set for для интерфейса {1} содержит один 2-Hop Tuple с N2_neighbor_iface_addr_list = {2} и N2_2hop_addr = {3}. 2-Hop Set для интерфейса {6} содержит один 2-Hop Tuple с N2_neighbor_iface_addr_list = {5} и N2_2hop_addr = {3}.

Neighbor Information Base содержит Neighbor Set с одним Neighbor Tuple, представляющим маршрутизатор B с N_neighbor_addr_list = {2,5}. Эта запись показана прямоугольником с {2} и {5}.

F.9. Пример 9 – два интерфейса на всех маршрутизаторах

На рисунке 20 все маршрутизаторы имеют 1 адрес IP на интерфейс и по 2 интерфейса. Кроме того, имеются 2 физических канала между A и B через разные пары интерфейсов и 2 физических канала между B и C тоже через разные пары.

    __________ __________
   |          |          |                       +-----+   +----{3}
  {1}        {2}        {3}            {1}-------| {2} |---+
   |          |          |                       | {5} |   +----{4}
+--'--+    +--'--+    +-----+                    +-----+
|  A  |    |  B  |    |  C  |
+-----+    +-----+    +-----+                    +-----+
   |          |          |                       | {2} |   +----{3}
  {6}        {5}        {4}            {6}-------| {5} |---+
   |__________|__________|                       +-----+   +----{4}

Рисунок 20. Одиночные адреса со всеми маршрутизаторами, имеющими по 2 интерфейса (слева), и представление NHDP.

Local Information Set идентичен примеру 8. Interface Information Base для каждого интерфейса в A тоже идентичны примеру 8, но имеют дополнительный 2-Hop Tuple в каждом 2-Hop Set, представляющий канал между маршрутизатором B и интерфейсом маршрутизатора C с адресом {4}.

Как в примере 7, маршрутизатор A не имеет информации о соединениях между интерфейсами маршрутизаторов B и C, а также не знает, что адреса {3} и {4} относятся к одному маршрутизатору. Однако маршрутизатор A знает, что адреса {3} и {4} (и маршрутизатор C) доступны через {2} или {5} (в зависимости от локального интерфейса).

F.10. Пример 10 – двойные интерфейсы с двумя адресами у всех

На рисунке 21 все маршрутизаторы имеют 2 адреса IP на интерфейс и по 2 интерфейса. Кроме того, имеются 2 физических канала между A и B через разные пары интерфейсов и 2 физических канала между B и C тоже через разные пары.

                                                            +--{9}
    __________ __________                            +------|
   |          |          |                 +-----+   |      +--{10}
 {1,2}      {5,6}      {9,10}       {1,2}--|{5,6}|---+
   |          |          |                 |{7,8}|   |      +--{11}
+--'--+    +--'--+    +-----+              +-----+   +------|
|  A  |    |  B  |    |  C  |                               +--{12}
+-----+    +-----+    +-----+
   |          |          |                                  +--{9}
   |          |          |                 +-----+   +------|
   |          |          |                 |{5,6}|   |      +--{10}
 {3,4}      {7,8}     {11,12}       {3,4}--|{7,8}|---+
   |__________|__________|                 +-----+   |      +--{11}
                                                     +------|
                                                            +--{12}

Рисунок 21. Двойные адреса на всех маршрутизаторах, имеющих по 2 интерфейса (слева), и представление NHDP.

Этот пример является комбинацией всех приведенных выше примеров. Local Information Set в A содержит Local Information Tuple для каждого из своих интерфейсов и каждая Interface Information Base содержит в своем Link Set представление каналов {1,2}-{5,6} или {3,4}-{7,8}, соответственно. Neighbor Set (в Neighbor Information Base) указывает наличие маршрутизатора B и всех адресов на всех его интерфейсах, т. е. {5,6,7,8}.

Как в примере 9, адрес каждого интерфейса маршрутизатора C представлен в 2-Hop Set каждой Interface Information Base как канал от маршрутизатора B к каждому из этих интерфейсов. Маршрутизатор A не имеет информации о соединениях между интерфейсами маршрутизаторов B и C, а также не знает, что адреса {9}, {10}, {11}, {12} относятся к одному маршрутизатору (и что некоторые, например, {9} и {10} являются адресами одного интерфейса).

F.11. Пример 11 – локальный сдвоенный интерфейс с одним адресом

На рисунке 22 все маршрутизаторы, кроме A, имеют по одному интерфейсу. Каждый из двух интерфейсов A имеет канал к интерфейсу маршрутизатора B. Все интерфейсы имеют по одному адресу.

    __________ __________
   |     _____|          |
  {1}   |    {2}        {3}             {1}--------{2}---------{3}
   |    |     |          |
+--'--+ |  +--'--+    +-----+
|  A  | |  |  B  |    |  C  |
+-----+ |  +-----+    +-----+
   |    |
  {6}   |                               {6}--------{2}---------{3}
   |____|

Рисунок 22. Один адрес с A, имеющим 2 интерфейса, подключенных к одному интерфейсу B (слева), и представление NHDP.

Это похоже на пример 8, но адрес {2} заменяет собой адрес {5}. В частности, оба Link Tuple (по одному в Link Set, каждый из которых соответствует Interface Information Base) имеют L_neighbor_iface_addr_list = {2}, Neighbor Set (в Neighbor Information Base) содержит 1 Neighbor Tuple с N_neighbor_addr_list = {2}, а оба 2-Hop Tuple (по одному в каждом 2-Hop Set в соответствующих Interface Information Base) имеют N2_neighbor_iface_addr_list = {2} и N2_2hop_addr = {3}.

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

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 ATC

Phone: +44 1245 242194

EMail: chris.dearlove@baesystems.com

URI: http://www.baesystems.com/

Justin W. Dean

Naval Research Laboratory

Phone: +1 202 767 3397

EMail: jdean@itd.nrl.navy.mil

URI: http://pf.itd.nrl.navy.mil/

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

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

nmalykh@gmail.com