CC BY
21
АЛГОРИТМИЗАЦИЯ И ПРОГРАММИРОВАНИЕ
УДК 316.776
Я. Ю. Навроцкий, Н. В. Пацей
Белорусский государственный технологический университет
АЛГОРИТМЫ МАРШРУТИЗАЦИИ ИМЕНОВАННЫХ ОБЪЕКТОВ В ИНФОРМАЦИОННО-ОРИЕНТИРОВАННЫХ СЕТЯХ
Работа посвящена проблеме проектирования информационно-ориентированных сетей (ICN -Information-Centric Networks), в частности одному из самых важных вопросов - публикации, поиска и доставки именованных объектов сети. Пошагово описаны алгоритмы маршрутизации, а также схемы, используемые при именовании и разрешении имен для четырех оставшихся на сегодняшний день актуальных проектов архитектур информационно--ориентированных сетей: Data-Oriented Network Architecture (DONA), Content-Centric Networking/Named Data Networking (CCN/NDN), Scalable and Adaptive Internet Solutions (SAIL) и MobilityFirst (MF). Пошагово и единообразно описан процесс последовательного обмена сообщениями между «издателем» и «подписчиком», а также работа блоков разрешения имен для выбранных сетей. Выполнен анализ производительности рассматриваемых алгоритмов на основе сценария получения объекта, рассчитана асимптотическая сложность. Указаны недостатки каждой стратегии при практическом использовании. Установлено, что более производительными являются архитектуры DONA и ^N/NON. Наименьшая производительность при поиске и доставке локатора будет в MF-сети.
Ключевые слова: маршрутизация, информационно-ориентированные сети, сообщение, сервер, объект, разрешение имен, хэш.
Ya. Yu. Navrotsky, N. V. Patsei
Belarusian State Technological University
ALGORITHMS OF NAMEED OBJECT ROUTING IN INFORMATION-CENTRIC NETWORKS
The article is devoted to the problem of designing Information-Centric Networks (ICN), in particular, one of the most important issues - the publication, search and delivery of named objects. The step-by-step routing algorithms are described, as well as the schemes used in naming and resolving names for the four remaining current projects of Information-Centric Networks architecture: Data-Oriented Network Architecture (DONA), Content-Centric Networking/Named Data Networking (CCN/NDN), Scalable and Adaptive Internet Solutions (SAIL) and MobilityFirst (MF). The process of sequential messaging between "publisher" and "subscriber", as well as the operation of name resolution nodes for the selected networks, is described in detail and in a uniform manner. The performance analysis of the described algorithms based on the scenario of obtaining the object is performed, the asymptotic complexity is calculated. The shortcomings of each strategy in practical use are indicated. It is established that the DONA and CCN/NDN architectures are more productive. The smallest performance in locating and delivering a locator will be in the MF network.
Key words: routing, information-centric networks, message, server, object, name resolution, hash.
Введение. Доставка и управление именованной информацией является главным применением сети интернет. В традиционной хост-ориентированной архитектуре появляются новые технологии доставки контента, в основе которых лежит принцип получения данных по имени без учета расположения сервера. Возрастающий интернет-трафик вынуждает использовать набор различных технологий для обеспечения кэширования, репликации и доставки контента. Невозможно однозначно и безопасно
идентифицировать информацию, не зная канала ее получения, это вынуждает одновременно использовать несколько подходов доставки данных, что приводит к потере эффективности. Информационно-ориентированные сети (ICN -Information-Centric Networks) как следующее поколение сетей должны решить все эти проблемы. За последние десятилетия было предложено множество различных вариантов архитектур информационных сетей. Ответа на вопрос, какая из архитектур будет использоваться в
качестве основы, пока нет. Рассмотрим подробнее алгоритмы публикации/подписки данных в четырех проектах ICN: Data-Oriented Network Architecture, Content-Centric Networking/Named Data Networking, Scalable and Adaptive Internet Solutions, MobilityFirst. Проанализируем производительность алгоритмов маршрутизации на примере сценария извлечения данных.
Основная часть. Data-Oriented Network Architecture (DONA). В DONA каждый информационный объект или сервис связан с владельцем [1]. Имя объекта формируется из криптографического хэша публичного ключа владельца P и его уникального названия L. Имена при этом являются неструктурированными, глобально уникальными, независимыми от уровня приложения и местоположения. Для неизменяемых данных название может быть криптографическим хэшем самого информационного объекта. Предполагается, что пользователи, заинтересованные в информационном объекте, получат его имя через определенные механизмы, например поисковую систему. В отличие от структуриро-
ванных DNS-имен, flat-имена в DONA не содержат административной информации, что позволяет сопоставлять имена DONA с пользовательскими именами [1].
Разрешение имен в DONA обеспечивается специализированными серверами, называемыми обработчиками разрешений (Resolution Handlers - RH), при этом автономная система в DONA состоит как минимум из одного логического сервера RH. Под автономной системой (Autonomous System - AS) понимают множество IP-сетей и маршрутизаторов, управляемых одним или несколькими операторами, имеющими единую политику маршрутизации. Все серверы RH связаны между собой, образуя иерархический сервис разрешения имен, который находится вверху иерархии связей междоменной маршрутизации, что позволяет сервисам разрешения имен и маршрутизации данных соблюдать установленные правила маршрутизации между автономными системами.
Публикация объекта в сети осуществляется с помощью сообщения REGISTER (рис. 1).
Соединение Сообщение REGISTER (1-2) Сообщение FIND (3-6) Сообщение DATA (7-10)
Рис. 1. Схема маршрутизации объектов для DONA
Издатель отправляет сообщение REGISTER с именем объекта на локальный сервер RH. Затем сервер RH распространяет это сообщение на серверы RH в своих родительских и пиринговых доменах, следуя установленным правилам маршрутизации (стрелки 2-3 на рис. 1). Каждый сервер RH, получивший такое сообщение, сохраняет у себя сопоставление между именем объекта и адресом сервера RH, который переадресовал ему сообщение REGISTER. Конечной точкой сообщения REGISTER является RH провайдера верхнего уровня (tier-1). Все провайдеры верхнего уровня равны и связаны между собой, что позволяет серверам RH в каждой из них получать информацию о регистрации объектов во всей сети. Издатели также могут формировать сообщения-шаблоны REGISTER, чтобы указать иерархии RH на то, что они могут предоставить все возможные данные в соответствии с определенным шаблоном, например, предоставить все версии определенного документа.
Для получения данных клиент/подписчик отправляет сообщение FIND на локальный сервер RH, который передает это сообщение вверх по сети, до тех пор, пока не будут найдены соответствующие записи о регистрации объекта (стрелки 4-5 на рис. 1). После этого запрос маршрутизируется согласно указателям, созданным при регистрации (стрелки 6-7 на рис. 1). Поскольку провайдеры tier-1 знают обо всех объектах в сети, этот процесс гарантированно завершится успешно в случае, если запрошенное имя существует. Подписчики также могут отправлять сообщения-шаблоны FIND для запроса данных с определенным названием.
В DONA маршрутизация данных может быть разделена или связана с сервисом разрешения имен. В варианте с разделением, если сообщение FIND достигает издателя, данные могут быть напрямую отправлены подписчику с использованием обычной IP-маршрутизации и передачи. Фактическая передача данных будет осуществляться в соответствии с установленными правилами маршрутизации сетевого трафика между автономными системами издателя и подписчика. В другом случае в сообщение FIND записываются адреса серверов RS, которые оно проходит с учетом последовательности систем AS. Когда запрос достигает издателя, данные о пройденном пути используются в обратном порядке, для доставки данных подписчику (стрелки 8-11 на рис. 1). В таком варианте устраняется необходимость в глобальных IP-адре-сах и больших таблицах маршрутизации типа Border Gateway Protocol (BGP), поскольку все данные о пути имеют локальное значение. Такой вариант передачи обеспечивает симметричную маршрутизацию между запросами и ответами.
DONA также поддерживает каналы многоадресной передачи данных. Реализуется это с помощью кэширования сообщения FIND в серверах RH. Это позволяет клиенту подписаться на обновления определенной информации на время срока действия сообщения FIND. В случае если сервер RH получает еще одно сообщение FIND c запросом на ту же информацию, то записи об ожидании данных объединяются в единую запись с несколькими указателями пути для ответа, тем самым создавая дерево многоадресной доставки (multicast distribution tree). Такая передача данных может работать только при совместной работе систем маршрутизации и именования, так как требуется, чтобы данные следовали по обратному пути системы AS, выбранному сообщениями FIND.
Content-Centric Networking/Named Data Networking (CCN/NDN). Имена в NDN являются иерархическими и похожи на URL. Например, имя может выглядеть как /wiki.org/icn/ccn.html. Однако имена NDN не являются URL-адресами. Каждая часть имени может быть чем угодно - это понятное пользователю название или же значение хэша. В NDN поиск информационного объекта осуществляется путем сопоставления введенного запроса с названием объекта, где запрос - префикс названия объекта. Например, запрос на /wiki.org/icn/ccn.html может вернуть объект /wiki.org/icn/ccn.html/_v1/_s1. Это означает, что получен первый сегмент первой версии запрошенных данных. После получения такого объекта пользователь может запросить следующий сегмент данных, явно указав это в имени. Способ сегментации информационных объектов и правило сопоставления префиксов будет известно уровню приложения пользователя. Правило сопоставления префиксов позволяет уровню приложения исследовать доступность данных по сети, а также пользователю запрашивать данные, которые еще не были опубликованы. В этом случае издатель указывает, что может отвечать на запросы с определенным префиксом. После создания объектов они будут возвращены клиентам с полными именами. Данный подход может быть использован в случае, когда информационные объекты генерируются динамически, поэтому их полные имена не могут быть известны заранее, например голосовые конференции [2].
В NDN для получения данных клиент отправляет сообщение INTEREST, в ответ на которое получает сообщение DATA (рис. 2). Оба типа сообщений содержат имя запрошенного/переданного информационного объекта. Все сообщения пересылаются последовательно при помощи маршрутизаторов контента (Content Router - CR), при этом каждый маршрутизатор CR содержит три структуры данных: таблицу
маршрутизации информации (или информационную базу пересылки - Forwarding Information Base - FIB), таблицу ожидания интересов (Pending Interest Table - PIT) и хранилище контента (Content Store - CS). FIB хранит сопоставление имени информационного объекта и адреса, по которому можно его запросить, маршрутизатор контента использует FIB для пересылки сообщений INTEREST. Таблица PIT хранит информацию о том, кто какие данные ожидает. При поступлении запроса на маршрутизатор в PIT создается запись с адресом отправителя сообщения INTEREST и ожидаемого для него сообщения DATA. Хранилище контента является локальным кэшем для информационных объектов.
При поступлении сообщения INTEREST маршрутизатор сначала проверяет хранилище контента на наличие запрошенного объекта. Если объект найден, он отправляется клиенту в сообщении DATA, а сообщение INTEREST удаляется. В случае если объекта в хранилище нет, маршрутизатор выполняет сопоставление префиксов имен в своей базе FIB для определения маршрута пересылки сообщения INTEREST. Если запись найдена в базе FIB, маршрутизатор создает запись в таблице PIT и передает сообщение INTEREST на маршрутизатор CR, который был указан базой FIB. Если запись в PIT по запрошенному объекту уже существует, маршрутизатор добавляет к ней адрес маршрутизатора, с которого поступил запрос, а сообщение INTEREST удаляется (стрелки 1-3 на рис. 2).
Это позволяет эффективно формировать дерево многоадресной передачи (a multicast tree) информационных объектов.
Информационный объект возвращается подписчику в сообщении DATA в последовательном режиме, основываясь на состоянии таблицы PIT. Когда маршрутизатор CR получает сообщение DATA, он сначала кэширует ин-
формационный объект в хранилище CS, а затем на основании таблицы PIT передает сообщение вниз по сети. Сообщение DATA дублируется на каждого клиента в записи PIT, что обеспечивает многоадресную доставку. После отправки сообщения DATA маршрутизатор удаляет запись из таблицы PIT (стрелки 4-6 на рис. 2). В случае если при получении сообщения DATA в таблице PIT нет соответствующих записей, маршрутизатор удаляет полученное сообщение.
В NDN разрешение имен и маршрутизация данных связаны. Маршрутизация сообщений DATA осуществляется согласно данным таблицы PIT. Заполнение таблицы FIB в NDN может выполняться по протоколам распределенной маршрутизации, таким как OSPF [3], в которых маршрутизаторы CR используют префиксы имен, а не диапазоны IP-адресов. Маршрутизаторы CR могут иметь множество адресов для одного префикса в записях FIB. В этом случае стратегический уровень может выбрать отправку сообщения INTEREST либо сразу на все адреса, либо только на интерфейс, который демонстрировал лучшую производительность.
Scalable and Adaptive Internet Solutions (SAIL). В архитектуре SAIL имена информационных объектов одновременно являются неструктурированными и иерархическими. SAIL определяет схему URI-имен как ni://A/L, в которой имена состоят из авторитетной части A, связанной с владельцем информации, и локальной части L. Каждая часть может быть хэшем, что позволит проводить самосертификацию (проверка подлинности полученной информации), или любым другим видом строки, что позволит использовать их как обычные URL. Для поиска нужного объекта в SAIL служат неструктурированные имена. В то же время для маршрутизации используются иерархические имена (как в CCN/NDN) [4, 5].
Соединение Сообщение INTEREST (1-3) Сообщение DATA (4-6) ■
Рис. 2. Схема маршрутизации объектов для NDN
Разрешение имен и маршрутизация данных могут быть связаны, разделены или работать в гибридном варианте. В случае раздельной реализации система разрешения имен (Name Resolution System - NRS) преобразует имя объекта в локатор, который в дальнейшем необходим для получения объекта. Локатор содержит IP-адрес именного объекта. Система NRS может быть разновидностью хэш-таблицы DHT, многоуровневой DHT или иерархической SkipNet. В случае реализации многоуровневой DHT каждая область сети поддерживает свою собственную локальную систему NRS для обработки разрешения L-части, в то время как глобальная система NRS обрабатывает разрешение A-части (рис. 3). Издатель публикует информационный объект, отправляя сообщение PUBLISH с локатором в локальную систему NRS (стрелка 1 на рис. 3), которая сохраняет сопоставление L-части с локатором. Затем локальная система NRS объединяет все L-части, входящие в эту область (А), и передает их в фильтр Блума, результат добавляется в сообщение PUBLISH и отправляется в глобальную систему NRS (стрелка 2 на рис. 3).
Глобальная система NRS сохраняет сопоставление между областью (A) c учетом фильтра Блума и локальной системой NRS. Для запроса данных подписчик отправляет сообщение GET в свою локальную систему NRS, которая обращается к глобальной системе NRS (стрелки 3-4 на рис. 3) для запроса локатора объекта (стрелки 4-5 на рис. 3). Затем подписчик отправляет сообщение GET издателю, используя возвращенный локатор (стрелки 7-9 на рис. 3), и издатель отвечает информационным объектом в сообщении DATA (стрелки 10-12 на рис. 3) [6, 7].
В совместной реализации протокол маршрутизации используется для публикации имен объектов и заполнения таблиц маршрутизации CR. Подписчик отправляет сообщение GET на свой локальный маршрутизатор CR, который передает его последовательно, по направлению к издателю (стрелки a-c на рис. 3). Когда информационный объект найден, он возвращается с помощью сообщения DATA по обратному пути, пройденному сообщением GET (стрелки d-f на рис. 3).
Global
Соединение -
Сообщение PUBLISH (1-2) -
Запрос локатора (3-6) - ■ - -----
Сообщение GET (7-9, a-c)-----►
Сообщение DATA (10-12, d-f) -----------
Рис. 3. Схема маршрутизации объектов для SAIL
В отличие от NDN, где информация, хранимая в маршрутизаторе CR, используется для составления обратного пути, в SAIL сообщения GET содержат информацию о пройденном пути, которая затем служит для доставки данных к подписчику.
В гибридном режиме работы система NRS возвращает подсказки маршрутизации, которые являются частью локатора и могут использоваться для передачи сообщения GET по одному из направлений. Таким образом, отправка сообщения GET может начинаться с получения подсказок маршрутизации от системы NRS для доставки сообщения GET как можно ближе к источнику, а затем, используя информацию маршрутизации на основе имени, хранящуюся в маршрутизаторе CR, достигать своего места назначения. Также возможен вариант, когда отправка сообщения GET может начинаться с информации о маршрутизации на основе имени, хранящейся в маршрутизаторе CR, и прибегать к системе NRS для дальнейших подсказок маршрутизации.
MobilityFirst (MF). В архитектуре Mobi-lityFirst каждому сетевому объекту назначается глобальный уникальный идентификатор (GUID) через глобальную службу имен, которая переводит понятные человеку имена в GUID. Каждое устройство в MF должно полу-
чить GUID для себя, своих информационных объектов и своих сервисов. Если объект доступен из нескольких мест в сети, то все его копии будут иметь одинаковый идентификатор GUID. Поскольку все сущности именованы, поддерживается как доставка данных на основе имени, так и хост-ориентированная доставка [8]. Любое взаимодействие начинается с преобразования GUID в сетевой адрес. Преобразование выполняется за один или более шагов, и отвечает за это глобальная служба разрешения имен (Global Name Resolution Service - GNRS) (рис. 4).
Для публикации данных издатель запрашивает у службы именования идентификатор GUID, а затем регистрирует его и свой сетевой адрес в службе GNRS (стрелка 1 на рис. 4). Для получения данных клиент отправляет сообщение GET на локальный маршрутизатор CR. Сообщение GET содержит GUID-идентификатор запрашиваемого объекта, а так же GUID-идентификатор клиента, на который будет отправлен ответ (стрелка 2 на рис. 4). CR выполняет маршрутизацию только на основе фактических сетевых адресов, например IP-адресов, следовательно, он запрашивает службу GNRS для сопоставления GUID-идентификатора запрошенного объекта с его сетевым адресом (стрелка 3 на рис. 4).
Global Name Resolution Service
G\R GNR GNR
Соединение Сообщение REGISTER (1) Сообщение GET (2, 5, 6, 9) Сопоставление GUID с локатором (3, 4, 7, 8) Сообщение DATA (10-13)
Рис. 4. Схема маршрутизации объектов для MF Трулы БГТУ Серия 3 № 1 2020
Служба GNRS присылает на такой запрос (стрелка 4 на рис. 4) набор сетевых адресов. В зависимости от запроса может прислать целый маршрут, часть целого маршрута и/или промежуточные сетевые адреса. CR выбирает один из сетевых адресов, добавляет его в сообщение GET, которое затем пересылает, используя обычные таблицы маршрутизации (стрелки 5-6 и 9 на рис. 4). Сообщение GET включает в себя как идентификатор GUID запрашиваемого объекта, так и его сетевой адрес, это позволяет любому маршрутизатору CR обратиться к службе GNRS для получения обновленного списка сетевых адресов для запрошенного объекта (стрелки 7-8 на рис. 4), если, например, сообщение GET не может быть доставлено издателю. По такой же схеме издатель отправляет сообщение ответа подписчику (стрелки 10-13 на рис. 4) [9, 10].
Фактическая маршрутизация выполняется на основе сетевых адресов, а служба GNRS используется только для сопоставления идентификаторов GUID с сетевыми адресами. Для статических сервисов или данных MobilityFirst может преобразовывать каждый идентификатор GUID в сетевой адрес только один раз, как в DNS, и работать только на основе сетевых адресов, игнорируя идентификатор GUID. Для более динамичных сервисов идентификатор GUID может преобразовываться несколько раз; первый маршрутизатор (опционально и другие) отправляет запрос в GNRS на получение сетевых адресов, привязанных к данному GUID, и затем принимает решение о переадресации на основе ответа от службы GNRS. Таким образом, переадресация может быть быстрой, когда служба GNRS не принимается во внимание, или медленной, когда маршрутизаторы обращаются к службе GNRS для получения обновленного списка сетевых адресов. Позднее связывание особенно полезно при большой мобильности клиента или издателя. Следует отметить, что каждое сообщение доставляется отдельно, т. е. сообщение GET и информационный объект, отправляемый в ответ на него, индивидуально маршрутизируются на основе их GUID-назначения, поэтому разрешение имен и маршрутизация данных в MobilityFirst разделены.
Анализ производительности. Для сравнения алгоритмов маршрутизации рассмотрим сценарий получения данных каждой сети. Сценарии передачи сообщения исключают идеальную ситуацию для каждой из сетей. Например, в случае с CCN/NDN опустим момент извлечения данных из кэша при получении сообщения INTEREST. Тогда сценарий принимает следующий вид: сообщение INTEREST проходит полный путь подписчик - издатель - подписчик. При таких условиях ключевую роль будут
играть время доставки сообщения между маршрутизаторами, количество пройденных узлов и количество выполняемых операций в узлах сети. В сетях DONA, MF и SAIL данные о пройденном маршруте сохраняются в сообщении FIND, а в CCN/NDN данные хранятся в таблице PIT. В первых трех случаях способ хранения данных можно рассматривать с позиции очереди или стека, в CCN/NDN - хэш-таблицы. Для упрощения анализа приведем все к хэш-таблице. Время доставки сообщения между узлами и количество маршрутизаторов в сети примем за постоянную величину, одинаковую для всех сетей.
Особенности иерархической структуры сети DONA позволяют сразу провести маршрутизацию сообщения от подписчика к издателю. При восходящем пути на каждом узле будет выполнена операция записи в сообщении FIND информации о пройденном маршруте. При нисходящем пути запись будет удалена. Асимптотическую сложность удаления и вставки обозначим Od и Oc соответственно, время запроса локатора - tl, количество узлов - n. Тогда сложность получения данных будет: Og = tl + 2n(Od + Oc).
Извлечение данных в сети CCN/NDN потребует обращения к таблицам FIB и PIT. Так как используется одинаковая структура для хранения информации, разница будет в том, где она хранится, то сложность извлечения остается прежней. При этом в обоих случаях величина tl = 0.
В MF используется GNRS для получения локатора при каждой отправке сообщения, поэтому tl будет отлично от нуля и пренебречь им нельзя. Похожий алгоритм используется в сети SAIL, где за получение локатора отвечает NRS. Однако в случае с SAIL локатор будет запрошен только один раз, а в случае с MF локатор запрашивается каждый раз на пути от подписчика к издателю и обратно. В итоге сложность алгоритма извлечения данных в MF будет: Og = 2tl + 2n(Od + Oc).
Для анализа будем использовать модель экспериментальной сети Abilene [11]. Сеть имеет 22 источника данных, 172 маршрутизатора, 139 edge-узлов и 139 клиентов. Если пренебречь такими характеристиками, как потеря пакетов, задержка и пропускная способность, и принять за единицу производительность сети DONA в сценарии извлечения данных, то можно рассчитать относительную производительность (Л) для остальных сетей, которая представлена в таблице ниже.
Относительная производительность сетей
DONA CCN/NDN SAIL MF
1,00 1,05 0,94 0,89
С учетом введенных обобщений и ограничений получаем практически одинаковую производительность для CCN/NDN и DONA, наибольшую из всех рассмотренных сетей. Менее производительной будет сеть SAIL, на последнем месте - MF.
Заключение. Как видно из описания схем маршрутизации, в ICN информация передается более эффективным образом и расположена ближе к пользователям, чем в TCP/IP. В статье представлен обзор схем именования и механизмов маршрутизации четырех проектов ICN. При маршрутизации используются два разных подхода: маршрутизация на основе имен и на основе разрешения имен.
Схема, основанная на разрешении имен, значительно снижает накладные расходы при публикации контента, особенно для больших размеров сети, и скорость публикации контента также высока. Однако она требует дополнительного запроса в процессе поиска контента. Основной же проблемой flat-именования явля-
ется масштабируемость, поэтому для большого количества сетевых объектов она не подходит. Очевидно, при построении сценариев маршрутизации требуется компромиссное решение.
При построении схем маршрутизации предъявляют ряд других требований: масштабируемость (архитектуры ICN должны быть способны обслуживать огромное количество объектов); эффективный поиск ближайшей копии для сокращения междоменного трафика; гарантия доставки контента с минимальными задержками (высокая скорость поступления запросов вызовет переполнение таблиц, а запросы подписчиков приведут к увеличению скорости ретрансляции и краху всей сети); безопасность и фильтрация (злоумышленники могут создавать искусственные запросы для заполнения таблиц на маршрутизаторах); единая точка отказа (присуще всем рассмотренным архитектурам). Ни одна из представленных здесь архитектур явно не указала режим удаления контента или обновление метаданных.
Литература
1. A data-oriented (and beyond) network architecture / T. Koponen [et al.] // ACM SIGCOMM. 2007. P.181-192.
2. VoCCN: Voice over content-centric networks / V. Jacobson [et al.] // ACM ReArch Workshop. 2009. P.20-65.
3. Networking named content / V. Jacobson [et al.] // ACM CoNEXT. 2009. P. 1-12.
4. The Network of Information: Architecture and applications [Electronic resource] // SAIL Project. URL: https://sail-project.eu/deliverables (date of access: 18.09.2019).
5. Final NetInf Architecture [Electronic resource] // SAIL Project. URL: https://sail-project.eu/ deliverables (date of access: 18.09.2019).
6. MDHT: a hierarchical name resolution service for information-centric networks / M. D'Ambrosio [et al.] // ACM Workshop on Information-Centric Networking (ICN). 2011. P. 584-587.
7. Dannewitz C., D'Ambrosio M., Vercellone V. Hierarchical DHTbased name resolution for information-centric networks // Computer Communications. 2012. vol. 36, no. 7. P. 736-749.
8. Baid A., Vu T., Raychaudhuri D. Comparing alternative approaches for networking of named objects in the future Internet // IEEE Workshop on Emerging Design Choices in Name-Oriented Networking (NOMEN). 2012. P. 89-93.
9. Map: A shared hosting scheme for dynamic identifier to locator mappings in the global Internet / T. Vu [et al.] // IEEE International Conference on Distributed Computing Systems (ICDCS). 2012. P. 1-92.
10. Jaber G., Patsei N., Rahal F. A Survey: Routing Schemes in Information-Centric Networks (ICN) // Scholars Journal of Engineering and Technology. 2019. No. 7 (8). P. 229-234.
11. Internet2: [site]. URL: https://www.internet2.edu/products-services/advanced-networking/ (date of access: 18.09.2019).
References
1. Koponen T., Chawla M., Chun B., Ermolinskiy A., Kim K. H., Shenker S., Stoica I. A data-oriented (and beyond) network architecture. ACM SIGCOMM, 2007, pp. 181-192.
2. Jacobson V., Smetters D. K., Briggs N. H., Plass M. F., Stewart P., Thornton J. D., Braynard R. L. VoCCN: Voice over content-centric networks. ACM ReArch Workshop, 2009, pp. 20-65.
3. Jacobson V., Smetters D. K., Thornton J. D., Plass M. F., Briggs N. H., Braynard R. L. Networking named content. ACM CoNEXT, 2009, pp. 1-12.
4. The Network of Information: Architecture and applications. SAIL Project. Available at: https://sail-project.eu/deliverables (accessed 18.09.2019).
5. Final NetInf Architecture. SAIL Project. Available at: https://sail-project.eu/deliverables (accessed 18.09.2019).
6. D'Ambrosio M., Dannewitz C., Karl H., Vercellone V. MDHT: a hierarchical name resolution service for information-centric networks. ACM Workshop on Information-Centric Networking (ICN), 2011, pp.584-587.
7. Dannewitz C., D'Ambrosio M., Vercellone V. Hierarchical DHTbased name resolution for information-centric networks. Computer Communications, 2012, vol. 36, no. 7, pp. 736-749.
8. Baid A., Vu T., Raychaudhuri D. Comparing alternative approaches for networking of named objects in the future Internet. IEEE Workshop on Emerging Design Choices in Name-Oriented Networking (NOMEN), 2012, pp. 89-93.
9. Vu T., Baid A., Zhang Y., Nguyen T., Fukuyama J., Martin R., Raychaudhuri D. Map: A shared hosting scheme for dynamic identifier to locator mappings in the global Internet. IEEE International Conference on Distributed Computing Systems (ICDCS), 2012, pp. 1-92.
10. Jaber G., Patsei N., Rahal F. A Survey: Routing Schemes in Information-Centric Networks (ICN). Scholars Journal of Engineering and Technology, 2019, no. 7 (8), pp. 229-234.
11. Internet2. Available at: https://www.internet2.edu/products-services/advanced-networking/ (accessed 18.09.2019).
Информация об авторах
Навроцкий Ярослав Юрьевич - аспирант. Белорусский государственный технологический университет (220006, г. Минск, ул. Свердлова, 13а, Республика Беларусь). E-mail: yaroslav.navrotskiy.yn@mail.ru
Пацей Наталья Владимировна - кандидат технических наук, доцент, заведующая кафедрой программной инженерии. Белорусский государственный технологический университет (220006, г. Минск, ул. Свердлова, 13а, Республика Беларусь). E-mail: n.patsei@belstu.by
Information about the authors
Navrotsky Yaroslav Yur'yevich - PhD student. Belarusian State Technological University (13a, Sverdlova str., 220006, Minsk, Republic of Belarus). E-mail: yaroslav.navrotskiy.yn@mail.ru
Patsei Nataliya Vladimirovna - PhD (Engineering), Associate Professor, Head of the Department of Software Engineering. Belarusian State Technological University (13a, Sverdlova str., 220006, Minsk, Republic of Belarus). E-mail: n.patsei@belstu.by
Поступила после доработки 29.10.2019
