RFC 9138 Design Considerations for Name Resolution Service in Information-Centric Networking (ICN)

Internet Research Task Force (IRTF)                              J. Hong
Request for Comments: 9138                                        T. You
Category: Informational                                             ETRI
ISSN: 2070-1721                                                  L. Dong
                                                             C. Westphal
                                             Futurewei Technologies Inc.
                                                               B. Ohlman
                                                                Ericsson
                                                           November 2021

Design Considerations for Name Resolution Service in Information-Centric Networking (ICN)

Вопросы проектирования службы распознавания имён для ориентированных на информацию сетей

PDF

Аннотация

В этом документе рассматриваются вопросы функциональности и проектирования служб распознавания имён (Name Resolution Service или NRS) в ориентированных на информацию сетях (Information-Centric Networking или ICN). Целью NRS в ICN является трансляция имени объекта в некую иную информацию, такую как местоположение (locator), другое имя и т. п. Документ является результатом исследовательской группы ICNRG¹.

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

Этот документ не содержит спецификации стандарта Internet (Standards Track) и публикуется с информационными целями.

Документ является результатом работы IRTF². IRTF публикует результаты связанных Internet исследований и разработок. Эти результаты могут не подходить для развёртывания. Данный документ представляет согласованное мнение исследовательской группы Information-Centric Networking в составе IRTF. Документы, одобренные для публикации IRSG не являются кандидатами в какие-либо стандарты Internet (см. раздел 2 в RFC 7841).

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

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

К этому документу применимы права и ограничения, перечисленные в BCP 78 и IETF Trust Legal Provisions и относящиеся к документам IETF (http://trustee.ietf.org/license-info), на момент публикации данного документа. Прочтите упомянутые документы внимательно. Фрагменты программного кода, включённые в этот документ, распространяются в соответствии с упрощённой лицензией BSD, как указано в параграфе 4.e документа IETF Trust Legal Provisions, без каких-либо гарантий (как указано в Simplified BSD License).

1. Введение

Сеть Internet в настоящее время основана на парадигме, ориентированной на хосты, где хосты указываются адресами IP, а взаимодействие происходит между парой хостов. Таким образом, информация в Internet сейчас идентифицируется именем хоста (или сервера), где она хранится. В отличие от ориентированных на хосты сетей основными объектами взаимодействия в ориентированной на информацию сети (ICN) являются объекты именованных данных (named data object или NDO), которые однозначно указываются независимыми от местоположения именами. Таким образом, сети ICN нацелены на эффективное распространение и извлечение объектов NDO в глобальном масштабе и эта технология была признана многообещающей архитектурой будущей сети Internet для преодоления современных ограничений Internet, в таких сферах, как расширяемость и мобильность [Ahlgren] [Xylomenos]. ICN также является кандидатом при выборе архитектуры «Internet вещей» (Internet of Things или IoT), поскольку IoT фокусируется на данных и информации [Baccelli] [Amadeo] [Quevedo] [Amadeo2] [ID.Zhang2].

Поскольку именование данных, не зависящее от их текущего местоположения (хранилища) является основной концепцией ICN, отыскание NDO с использованием независимого от местоположения имени является одной из важнейших задач при проектировании ICN. Маршрутизацию ICN можно разделить на 3 этапа [RFC7927]:

распознавание имени – сопоставление (и трансляция) имени содержимого с местоположением (locator) издателя содержимого или источника, способного предоставить содержимое;
маршрутизация запроса содержимого к местоположению этого содержимого по локатору или имени;
доставка содержимого запросившей его стороне.

Из отмеченных 3 этапов маршрутизации ICN в этом документе рассматривается этап 1 – распознавание имён, при котором имя содержимого транслируется в его местоположение (locator). Кроме того, докуме6нт охватывает возможные типы распознавания имён в ICN, такие как преобразование имени в другое имя, манифест или метаданные.

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

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

2. Служба распознавания имён в ICN

Служба распознавания имён (NRS) в ICN определяется как служба, обеспечивающая функцию распознавания имён для трансляции имени объекта в иные сведения, такие как местоположение, другое имя, метаданные, сведения о следующем интервале пересылки (next-hop) и т. п., которые применяются для пересылки запроса объекта. Иными словами, служба NRS может предоставляться инфраструктурой ICN, чтобы помочь потребителю получить нужные сведения (или именованный объект данных). Потребитель предоставляет NRS постоянное имя, а NRS возвращает имя или местоположение (locator), возможно в нескольких экземплярах, для получения текущего экземпляра запрошенного объекта.

Распознавание имён является важной частью маршрутизации ICN, хотя сам процесс распознавания может быть отделен от маршрутизации запросов содержимого или быть встроенным в маршрутизацию запросов содержимого как неявный процесс. Первый вариант в этом документе называется явным распознаванием (explicit name resolution), второй – маршрутизацией по именам (name-based routing).

2.1. Явное распознавание имён

NRS может использовать явное распознавание имён для возврата клиенту местоположения содержимого и базовая сеть будет использовать это местоположение в качестве идентификатора для маршрутизации запроса клиента к одному из издателей или копии содержимого. Есть несколько проектов ICN, использующих явное распознавание, например ориентированная на данные архитектура сети (Data-Oriented Network Architecture или DONA) [Koponen], PURSUIT [PURSUIT], сеть информации (Network of Information или NetInf) [SAIL], MobilityFirst [MF], IDNet [Jung] и др. Кроме того, явное распознавание имён также разрешено в плоскостях управления 5G [SA2-5GLAN].

2.2. Маршрутизация по именам

NRS может принимать подход с маршрутизацией по именам, где распознавание имен интегрировано с маршрутизацией запросов содержимого, как в сетях именованных данных и ориентированных на содержимое сетях (Named Data Networking / Content-Centric Networking или NDN/CCNx) [NDN] [CCNx].

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

2.3. Гибридный подход

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

Гибридный подход будет сочетать распознавание имён через подмножество маршрутизаторов на пути и тем или иным туннелированием между ними (например, через административный домен) так, чтобы лишь часть узлов в сети ICN выполняла распознавание имён в подходе с маршрутизацией по имени.

2.4. Сравнение подходов к распознаванию имён

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

Издержки на хранение местоположений. Доступность содержимого меняется динамически и поддержка включает кэширование новых записей, а также удаление из кэша записей при их старении, перемещении мобильного издателя и т. п. Поддержка согласованного представления местоположений содержимого требует некоторых издержек, которые различаются в разных подходах к распознаванию имён. При маршрутизации по именам может потребоваться лавинная рассылка в части сети для распространения обновлений. В худшем случае такая рассылка будет происходить во всей сети (однако ждя этого случая имеются методы задания области лавинной рассылки). При явном распознавании имён требуется лишь распространение обновлений для части системы распознавания имён, которая может быть наложением с ограниченным числом узлов.
Возможность распознавания. Если явное распознавание имён реализовано и развёрнуто с достаточной отказоустойчивостью, имеется хоть какая-то гарантия успешного распознавания любого имени содержимого в сети, зарегистрированного в наложении (overlay) распознавания имён. При маршрутизации по именам распознавание содержимого зависит от области лавинной рассылки имён содержимого (т. е. сообщений о публикации и результирующих таблиц маршрутизации по именам. Например, при кэшировании содержимого маршрутизатор может уведомлять об этой информации лишь непосредственных соседей и только они смогут создавать записи на основе имён кэшированного содержимого. Если же соседние маршрутизаторы будут дальше распространять эту информацию, другие узлы также смогут направлять к кэшированной копии.
Влияние отказа узла. Узлы, вовлечённые в явное распознавание имён, имеют наложенные серверы распознавания (например, обработчики распознавания в DONA), а узлы, участвующие в маршрутизации по именам, являются маршрутизаторами, которые направляют сообщения на основе таблицы маршрутизации по именам (например, маршрутизаторы NDN). Отказ узла в системе явного распознавания может приводить к отказам некоторых запросов содержимого, которое не утратило доступности. Эта проблема не возникает при маршрутизации по именам, поскольку могут быть найдены пути обхода отказавших маршрутизаторов ICN при условии сохранения связности сети.
Поддерживаемые базы данных. Использование хранилища для явного распознавания имён отличается от случая маршрутизации по именам. Для явного распознавания имён обычно требуется поддержка двух баз данных – сопоставления имён с местоположением в наложении распознавания имён и таблицы маршрутизации в маршрутизаторах плоскости пересылки данных. В маршрутизации по именам достаточно лишь поддержки таблиц маршрутизации.

Кроме того, в распознавание имён может быть включён промежуточный шаг, а именно отображение имени на другие имена, чтобы упростить извлечение именованного содержимого через манифест [Westphal] [RFC8569]. Манифест распознаётся с помощью одного или двух описанных выше подходов и может включать дальнейшее сопоставление имён с содержимым и местоположением. Этапы распознавания имён становятся следующими – сначала транслируется имя манифеста в местоположение его копии, которая включает дополнительные имена компонентов содержимого и возможные места размещения содержимого, затем извлекается содержимое с помощью имён и/или местоположения, что может приводить к дополнительному распознаванию имён.

Таким образом, независимо от подхода, используемого NRS в ICN, распознавание имён является важной функцией, которая должна обеспечиваться инфраструктурой ICN.

3. Функциональность NRS в ICN

В этом разделе рассматривается функциональность NRS в ICN.

3.1. Поддержка разнотипных имён

В ICN имя служит для идентификации объекта данных и привязано к нему [RFC7927]. ICN требует уникальности и постоянства имени объекта данных для обеспечения доступности объекта в некой области. Есть разные подходы к разработке схем именования ICN [Bari]. В идеале имя может включать любую форму идентификатора, плоскую или иерархическую, понятную человеку или нечитаемую.

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

В PURSUIT [PURSUIT] имена являются плоскими и для NRS определены функции встречи (rendezvous), которые реализуются набором узлов встречи (rendezvous node или RN), называемых также сетью встреч (rendezvous network или RENE). Таким образом, имя состоит из цепочки идентификаторов областей действия (scope ID), а один идентификатор встречи (rendezvous ID) маршрутизируется узлами RN в сети RENE. В результате PURSUIT отделяет распознавание имён и маршрутизацию данных. Функции NRS выполняются сетью RENE.

В MobilityFirst [MF] имена, называемые глобально уникальными идентификаторами Global Unique Identifier или GUID), выводятся из понятных человеку имён через глобальную службу именования и являются «плоскими» типизованными строками размером 160 битов со свойствами самосертификации. MobilityFirst определяет глобальную службу распознавания имён (Global Name Resolution Service или GNRS), которая преобразует GUID в сетевые адреса и отделяет распознавание имён от маршрутизации данных аналогично PURSUIT.

В NetInf [Dannewitz] информационные объекты используют имена Named Information (NI) [RFC6920], состоящие из названия органа (authority) и дайджеста (хэш содержимого). Имена NI могут быть плоскими, поскольку часть authority необязательна. Архитектура NetInf также включает систему распознавания имён (NRS), которая может служить для преобразования NI в адреса нижележащего сетевого уровня с маршрутизацией.

В NDN [NDN] и CCNx [CCNx] имена являются иерархическими и могут быть похожи на URL. Каждый компонент имени может быть любым, включая понятные человеку строки или хэш-значения. В NDN/CCNx применяется маршрутизация по именам и маршрутизатор NDN пересылает запросы, выполняя поиск по наибольшему совпадению в базе данных пересылки (Forwarding Information Base FIB) для имени содержимого, а запросы хранятся в таблице ожидающих интересов (Pending Interest Table или PIT).

3.2. Поддержка мобильности издателей

ICN по своей природе поддерживает мобильность абонентов. Мобильность потребителя (клиента) обрабатывается путём повторного запроса содержимого в случае связанного с мобильностью события (например, при передаче обслуживания – handover), которое произошло до получения запрошенного содержимого из сети. Поскольку ICN может гарантировать продолжение приёма без каких-либо нарушений в приложениях ICN, с точки зрения потребителя может легко поддерживаться «бесшовная» мобильность.

Однако мобильность издателей не возникает автоматически из модели пересылки ICN, как мобильность потребителей. Если издатель перемещается в другое место сети или в другой домен, который управляется другим полномочным издателем, системе управления мобильностью будет сложно обновить базу маршрутной информации (Routing Information Base или RIB) и записи FIB в маршрутизаторах ICN, указав новый путь пересылки. Поэтому для различных вариантов архитектуры ICN в литературе предлагается принять NRS для обеспечения мобильности издателей. NRS можно реализовать разными способами, такими как точки встречи (rendezvous point) и/или наложенные системы отображения.

В NDN [Zhang2] для поддержки мобильности издателей были предложены механизмы встречи (rendezvous), организующие встречи по интересам (RV) с данными, создаваемыми мобильным издателем (mobile producer или MP). Здесь можно выделить на два подхода – «погоню» за мобильным издателем и данные встречи. В случае погони за MP встреча обеспечивает службу отображения, сопоставляющую имена данных от MP с именем текущей точки подключения MP (point of attachment или PoA). Дополнительно к этому RV выступает в качестве домашнего агента для поддержки IP mobility, поскольку RV позволяет туннелировать сообщения Interest от потребителей в направлении MP в точке PoA. В части данных встречи (rendezvous data) решение включает перенос данных, создаваемых MP, в хранилище (depot) вместо пересылки сообщений Interest. Таким образом, сообщение Interest от потребителя может пересылаться в стационарное место, называемое «встречей с данными» (data rendezvous), чтобы данные возвращались оттуда или извлекались из иного места с помощью отображения. В результате RV или иные функции отображения играют роль NRS в NDN.

В [Ravindran] используются метки пересылки (forwarding label или FL) для обеспечения возможности разделить пространства имён идентификаторов (ID) и местоположений (LID) в ICN. Обычно идентификаторы ID поддерживаются приложениями, а локаторы (местоположение) – администраторами сетей, так что ID сопоставляются с разнотипными схемами имён, а LID – с сетевыми доменами или конкретными элементами сети. Таким образом, объект FL выступает локатором (LID) и обеспечивает гибкость пересылки сообщений Interest через службы сопоставления между ID и LID. Поэтому в данном проекте служба сопоставления в инфраструктуре плоскости управления может рассматриваться как NRS.

В MobilityFirst [MF] мобильность потребителей и издателей может обрабатываться в основном глобальной службой распознавания имён (global name resolution service или GNRS), которая преобразует GUID в сетевые адреса. Поэтому требуется обновлять GNRS для поддержки мобильности, когда подключенный к сети объект меняет точку подключения, что отличается от NDN/CCNx.

В NetInf [Dannewitz] мобильность обслуживается NRS очень похожим на MobilityFirst способом.

Помимо мобильности потребителей и издателей в ICN возникает задача поддержки других динамических свойств, таких как множественные подключения (multi-homing), перенос (migration) и репликация именованных ресурсов (например, содержимого, устройств, служб). Следовательно, NRS может помочь в решении и этих динамических задач.

3.3. Поддержка расширяемой системы маршрутизации

В ICN имя объекта данных служит для маршрутизации на этапе распознавания или при поиске в таблице маршрутизации. Поэтому маршрутные сведения для каждого объекта данных следует поддерживать в маршрутных базах, таких как RIB и FIB. Поскольку число объектов данных будет очень велико, размер информационных баз также будет большим [RFC7927].

Иерархические пространства имён, применяемые в архитектуре CCNx [CCNx] и NDN [NDN] снижают размер таблиц за счёт агрегирования имён и повышают возможности расширения системы маршрутизации. Плоская же система имён существенно осложняет задачи расширения системы маршрутизации. Неагрегируемые префиксы имён, внедряемые в зону без принятого по умолчанию маршрута (Default Route Free Zone или DFZ) сети ICN могут создавать более серьёзные проблемы расширяемости по сравнению с аналогичными проблемами в системе маршрутизации IP. Таким образом, NRS может играть важную роль в смягчении проблемы расширяемости независимо от типа пространство имён.

В работе [Afanasyev] для решения задачи расширяемости маршрутизации в NDN DFZ применяется хорошо известная концепция сопоставления и инкапсуляции (map-and-encap), чтобы обеспечить простое и защищённое решение по сопоставлению пространств имён. В предложенном решении map-and-encap данные, у которых префиксов имён нет в таблице пересылки DFZ, можно получить с помощью распределенной системы сопоставления NDNS, которая обеспечивает поддержку и поиск данных отображения имён на глобально маршрутизируемые префиксы, играя роль NRS.

3.4. Поддержка кэширования вне пути

Кэширование в сети считается основным компонентом архитектуры ICN. Оно может применяться для обеспечения качества обслуживания (quality-of-service или QoS) пользователей с целью снижения общего трафика, предотвращения перегрузок и атак на службы (denial-of-service или DoS), а также улучшения доступности. Кэширование можно разделить на внутрипутевое (on-path) и внешнее (off-path) в зависимости от размещения кэша относительно пути от исходного сервера к потребителю. Внешнее кэширование, которое называют также репликацией (content replication) или сохранением (content storing) содержимого, предназначено для репликации содержимого в сети с целью повышения уровня доступности независимо от местоположения по отношению к пути пересылки. Поиск кэшированных объектов вне пути является нетривиальной задачей в ICN с маршрутизацией по именам. Для поддержки внешнего кэширования реплики обычно анонсируются в систему маршрутизации по именам или в NRS.

В [Bayhan] распознавание имён (NRS) служит для поиска копий вне пути через сеть, которые могут быть недоступны для механизмов маршрутизации по именам. Такая возможность может быть полезна в автономной системе (Autonomous System или AS) для предотвращения дорогостоящего трафика между AS к внешнему содержимому, повышения эффективности использования пропускной способности для внутреннего трафика AS и снижения задержки доступа к данным для пользователей.

3.5. Поддержка безымянных объектов

В CCNx 1.0 [Mosko2] концепция Nameless Object, которые представляют собой безымянные объекты содержимого (Content Object), введена для обеспечения возможности перемещать содержимое между хранилищами реплик без переименования или повторного подписывания объектов с новым именем. К безымянным объектам можно обращаться по хэш-значению ContentObjectHash на основе алгоритма SHA-256.

Сообщения Interest будут содержать имя и ContentObjectHash – имя будет служить для маршрутизации, а ContentObjectHash – для сопоставления. Однако на обратном пути при отсутствии имени Content Object объект будет безымянным и сопоставление будет возможно лишь по ContentObjectHash. Поэтому потребителю потребуется распознавать имя и хэш через внешнюю систему, которую можно рассматривать как NRS.

3.6. Манифест поддержки

Для коллекций объектов данных, организованных в большие файлоподобные структуры [FLIC] применяются манифесты в качестве структур данных для передачи информации. Манифест может содержать хэш-дайджесты подписанных Content Object или других манифестов, так что большие объекты содержимого, представляющие крупные части данных приложения, могут быть собраны с использованием такого манифеста.

Для запроса Content Object потребителю нужно знать имя корня манифеста для получения этого манифеста. В случае файлоподобных коллекций FLIC (File-Like ICN Collection) имя манифеста может быть представлено безымянным корневым манифестом, чтобы можно было задействовать для предоставления информации потребителю внешние системы, такие как NRS.

3.7. Метаданные поддержки

При распознавании имени Content Object служба NRS может возвращать множество метаданных в дополнение к местоположению объекта. Метаданные могут включать дополнительное местоположение, поддерживаемые протоколы передачи, правила кэширования, параметры защиты, формат данных, хэш объекта и пр. Потребитель может использовать метаданные для выбора протокола передачи, механизмов защиты, выходного интерфейса и т. п. Пример такого использования метаданных даёт архитектура сетевых объектов (Networked Object или NEO) в ICN [NEO].

4. Вопросы проектирования NRS и ICN

В этом разделе приведены соображения об устройстве и проектировании NRS в ICN.

4.1. Время отклика при распознавании

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

Приемлемая задержка отклика может составлять время порядка интервала кругового обхода (round-trip) между запросившим клиентом и обеспечивающим отклик сервером NRS. Хотя значения RTT могут существенно зависеть от удалённости указанных точек, следует использовать ту или иную верхнюю границу. Верхняя граница задержки отклика должна гарантироваться в некоторых приложениях, чувствительных к задержкам, например в промышленных системах или телемедицине.

Время отклика учитывает все этапы распознавания, включая возможное поэтапное (hop-by-hop) распознавание или иерархическую пересылку запроса.

4.2. Точность распознавания

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

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

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

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

4.3. Гарантии распознавания

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

4.4. Беспристрастность распознавания

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

Отдано следует отметить, что содержимое (или его издатель) может требовать от сети иного уровня QoS (см., например, [RFC9064]) и это может затрагивать NRS, поэтому в таких случаях беспристрастность может обеспечиваться в рамках одного класса обслуживания.

4.5. Расширяемость

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

Система NRS должна расширяться с ростом числа частей (имён) содержимого и следует поддерживать очень большой каталог содержимого. Трафик Internet измеряется зеттабайтами (10²¹ байт) в год. Поскольку служба NRS связана с фактическим трафиком, число имён содержимого будет расти с увеличением трафика. Размер содержимого может варьироваться от нескольких байтов до гигабайт, поэтому в NRS следует предполагать в ближайшем будущем расширение каталога до 10²¹ и более.

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

Система NRS может поддерживать доступ с использованием для подключения разных методов и устройств. В частности, NRS может поддерживать доступ устройств с ограниченными возможностями и взаимодействие с NRS не должно быть слишком «дорогим» для них. Например, узлам IoT следует предоставлять доступ к NRS как и более мощным устройствам.

Системе NRS следует расширять свои возможности реагирования при росте числа запросов, которые ожидаются от таких приложений, как IoT или межмашинные взаимодействия (machine-to-machine или M2M), где запросы и обмен данными происходят часто.

4.6. Управляемость

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

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

4.7. Развёрнутая система

Система NRS должна быть развёртываемой, поскольку такая возможность важна для реальной системы. В NRS должна поддерживаться возможность развёртывания на периметре или в ядре сети, чтобы потребители и маршрутизаторы ICN могли распознавать имена с очень малой задержкой.

4.8. Отказоустойчивость

Система NRS должна обеспечивать устойчивость к отказам серверов NRS. Отказ небольшого числа устройств не должен существенно влиять на производительность NRS.

При отказе сервера NRS система NRS должна быть способна восстановить и/или возобновить записи, хранившиеся на этом сервере NRS.

4.9. Безопасность и приватность

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

4.9.1. Конфиденциальность

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

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

NRS может поддерживать механизмы запутывания (obfuscation) и/или шифрования, чтобы содержимое запросов на распознавание не было доступно сторонним лицам вне системы NRS.

Система NRS должна сохранять конфиденциальность для предотвращения несанкционированного доступа к записям сопоставления имён. Это может требоваться в средах IoT где создаётся много «деликатных» данных.

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

4.9.2. Проверка подлинности

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

4.9.3. Целостность

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

4.9.4. Отказоустойчивость и доступность

Системе NRS следует быть устойчивой к атакам на службы (denial-of-service) и другим распространенным атакам, чтобы предотвратить косвенное нарушение работы всей системы. Поэтому при отказе части системы NRS отказ следует изолировать без влияния на другие домены. Для возобновления нормальной работы службы нужны механизмы быстрого восстановления.

5. Заключение

Маршрутизация ICN может состоять из 3 этапов – распознавание имени, маршрутизация запроса содержимого и доставка содержимого. В этом документе описан этап распознавания имён, который является первым и наиболее важным для успешной маршрутизации в ICN. Сервис распознавания имён (NRS) в ICN определён как служба, обеспечивающая функцию распознавания имён для трансляции имени объекта в иную информацию, такую как местоположение (locator), иное имя, метаданные, следующий этап пересылки (next-hop) и т. п., которая может применяться для пересылки к интересующему объекту.

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

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

Документ не требует действий IANA.

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

Рекомендации по безопасности приведены в параграфе 4.9.

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

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

[RFC7927] Kutscher, D., Ed., Eum, S., Pentikousis, K., Psaras, I., Corujo, D., Saucez, D., Schmidt, T., and M. Waehlisch, “Information-Centric Networking (ICN) Research Challenges”, RFC 7927, DOI 10.17487/RFC7927, July 2016, <https://www.rfc-editor.org/info/rfc7927>.

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

[Afanasyev] Afanasyev, A. et al., “SNAMP: Secure Namespace Mapping to Scale NDN Forwarding”, 2015 IEEE Conference on Computer Communications Workshops, DOI 10.1109/INFCOMW.2015.7179398, April 2015, <https://doi.org/10.1109/INFCOMW.2015.7179398>.

[Ahlgren] Ahlgren, B., Dannewitz, C., Imbrenda, C., Kutscher, D., and B. Ohlman, “A Survey of Information-Centric Networking”, IEEE Communications Magazine, Vol. 50, Issue 7, DOI 10.1109/MCOM.2012.6231276, July 2012, <https://doi.org/10.1109/MCOM.2012.6231276>.

[Amadeo] Amadeo, M., Campolo, C., Iera, A., and A. Molinaro, “Named data networking for IoT: An architectural perspective”, European Conference on Networks and Communications (EuCNC), DOI 10.1109/EuCNC.2014.6882665, June 2014, <https://doi.org/10.1109/EuCNC.2014.6882665>.

[Amadeo2] Amadeo, M. et al., “Information-centric networking for the internet of things: challenges and opportunities”, IEEE Network, Vol. 30, No. 2, DOI 10.1109/MNET.2016.7437030, March 2016, <https://doi.org/10.1109/MNET.2016.7437030>.

[Baccelli] Baccelli, E., Mehlis, C., Hahm, O., Schmidt, T., and M. Wählisch, “Information Centric Networking in the IoT: Experiments with NDN in the Wild”, ACM-ICN 2014, DOI 10.1145/2660129.2660144, 2014, <https://doi.org/10.1145/2660129.2660144>.

[Bari] Bari, M.F., Chowdhury, S.R., Ahmed, R., Boutaba, R., and B. Mathieu, “A Survey of Naming and Routing in Information-Centric Networks”, IEEE Communications Magazine, Vol. 50, No. 12, pp. 44-53, DOI 10.1109/MCOM.2012.6384450, December 2012, <https://doi.org/10.1109/MCOM.2012.6384450>.

[Bayhan] Bayhan, S. et al., “On Content Indexing for Off-Path Caching in Information-Centric Networks”, ACM-ICN 2016, DOI 10.1145/2984356.2984372, September 2016, <https://doi.org/10.1145/2984356.2984372>.

[CCNx] “CICN”, <https://wiki.fd.io/view/Cicn>.

[Dannewitz] Dannewitz, C. et al., “Network of Information (NetInf) – An information-centric networking architecture”, Computer Communications, Vol. 36, Issue 7, DOI 10.1016/j.comcom.2013.01.009, April 2013, <https://doi.org/10.1016/j.comcom.2013.01.009>.

[FLIC] Tschudin, C., Wood, C. A., Mosko, M., and D. Oran, “File-Like ICN Collections (FLIC)”, Work in Progress, Internet-Draft, draft-irtf-icnrg-flic-03, 7 November 2021, <https://datatracker.ietf.org/doc/html/draft-irtf-icnrg-flic-03>.

[ID.Zhang2] Ravindran, R., Zhang, Y., Grieco, L. A., Lindgren, A., Burke, J., Ahlgren, B., and A. Azgin, “Design Considerations for Applying ICN to IoT”, Work in Progress, Internet-Draft, draft-irtf-icnrg-icniot-03, 2 May 2019, <https://datatracker.ietf.org/doc/html/draft-irtf-icnrg-icniot-03>.

[Jung] Jung, H. et al., “IDNet: Beyond All-IP Network”, ETRI Journal, Vol. 37, Issue 5, DOI 10.4218/etrij.15.2415.0045, October 2015, <https://doi.org/10.4218/etrij.15.2415.0045>.

[Koponen] Koponen, T., Chawla, M., Chun, B., Ermolinskiy, A., Kim, K.H., Shenker, S., and I. Stoica, “A Data-Oriented (and Beyond) Network Architecture”, ACM SIGCOMM 2007, pp. 181-192, DOI 10.1145/1282380.1282402, August 2007, <https://doi.org/10.1145/1282380.1282402>.

[MF] “MobilityFirst Future Internet Architecture Project Overview”, <http://mobilityfirst.winlab.rutgers.edu>.

[Mosko2] Mosko, M., “Nameless Objects”, IRTF ICNRG, January 2016, <https://datatracker.ietf.org/meeting/interim-2016-icnrg-01/materials/slides-interim-2016-icnrg-1-7.pdf>.

[NDN] “Named Data Networking”, <http://www.named-data.net>.

[NEO] Eriksson, A. and A.M. Malik, “A DNS-based information-centric network architecture open to multiple protocols for transfer of data objects”, 21st Conference on Innovation in Clouds, Internet and Networks and Workshops (ICIN), pp. 1-8, DOI 10.1109/ICIN.2018.8401595, February 2018, <https://doi.org/10.1109/ICIN.2018.8401595>.

[NRSarch] Hong, J., You, T., and V. Kafle, “Architectural Considerations of ICN using Name Resolution Service”, Work in Progress, Internet-Draft, draft-irtf-icnrg-nrsarch-considerations-06, 12 February 2021, <https://datatracker.ietf.org/doc/html/draft-irtf-icnrg-nrsarch-considerations-06>.

[PURSUIT] “FP7 PURSUIT”, <https://www.fp7-pursuit.eu/>.

[Quevedo] Quevedo, J., Corujo, D., and R. Aguiar, “A case for ICN usage in IoT environments”, IEEE GLOBECOM, DOI GLOCOM.2014.7037227, December 2014, <https://doi.org/GLOCOM.2014.7037227>.

[Ravindran] Ravindran, R., Chakraborti, A., and A. Azgin, “Forwarding Label support in CCN Protocol”, Work in Progress, Internet-Draft, draft-ravi-icnrg-ccn-forwarding-label-02, 5 March 2018, <https://datatracker.ietf.org/doc/html/draft-ravi-icnrg-ccn-forwarding-label-02>.

[RFC6920] Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B., Keranen, A., and P. Hallam-Baker, “Naming Things with Hashes”, RFC 6920, DOI 10.17487/RFC6920, April 2013, <https://www.rfc-editor.org/info/rfc6920>.

[RFC8569] Mosko, M., Solis, I., and C. Wood, “Content-Centric Networking (CCNx) Semantics”, RFC 8569, DOI 10.17487/RFC8569, July 2019, <https://www.rfc-editor.org/info/rfc8569>.

[RFC9064] Oran, D., “Considerations in the Development of a QoS Architecture for CCNx-Like Information-Centric Networking Protocols”, RFC 9064, DOI 10.17487/RFC9064, June 2021, <https://www.rfc-editor.org/info/rfc9064>.

[SA2-5GLAN] 3GPP, “New WID: 5GS Enhanced support of Vertical and LAN Services”, TSG SA Meeting #SP-82, December 2018, <http://www.3gpp.org/ftp/tsg_sa/TSG_SA/TSGS_82/Docs/SP-181120.zip>.

[SAIL] “Scalable and Adaptive Internet Solutions (SAIL)”, <http://www.sail-project.eu/>.

[Westphal] Westphal, C. and E. Demirors, “An IP-Based Manifest Architecture for ICN”, ACM-ICN 2015, DOI 10.1145/2810156.2812614, September 2015, <https://doi.org/10.1145/2810156.2812614>.

[Xylomenos] Xylomenos, G., Ververidis, C., Siris, V., Fotiou, N., Tsilopoulos, C., Vasilakos, X., Katsaros, K., and G. Polyzos, “A Survey of Information-Centric Networking Research”, IEEE Communications Surveys and Tutorials, Vol. 16, Issue 2, DOI 10.1109/SURV.2013.070813.00063, 2014, <https://doi.org/10.1109/SURV.2013.070813.00063>.

[Zhang2] Zhang, Y. et al., “A Survey of Mobility Support in Named Data Networking”, IEEE Conference on Computer Communications Workshops, DOI 10.1109/INFCOMW.2016.7562050, April 2016, <https://doi.org/10.1109/INFCOMW.2016.7562050>.

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

Авторы благодарны Dave Oran, Dirk Kutscher, Ved Kafle, Vincent Roca, Marie-Jose Montpetit, Stephen Farrell, Mirja Kühlewind, Colin Perkins за полезные рецензии, комментарии и улучшения для документа.

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

Jungha Hong

ETRI

Yuseung-Gu

218 Gajeong-ro

Daejeon

34129

Republic of Korea

Email: jhong@etri.re.kr

Tae-Wan You

ETRI

Yuseung-Gu

218 Gajeong-ro

Daejeon

34129

Republic of Korea

Email: twyou@etri.re.kr

Lijun Dong

Futurewei Technologies Inc.

10180 Telesis Court

San Diego, CA 92121

United States of America

Email: lijun.dong@futurewei.com

Cedric Westphal

Futurewei Technologies Inc.

2330 Central Expressway

Santa Clara, CA 95050