Именованная сеть передачи данных

Named Data Networking ( NDN ) (относится к контент-центричным сетям (CCN), контент-ориентированным сетям, ориентированным на данные или информационно-ориентированным сетям (ICN)) — это предлагаемая будущая архитектура Интернета , которая стремится решить проблемы современных интернет- архитектур, таких как IP . [1] [2] NDN берет свое начало в более раннем проекте Content-Centric Networking (CCN), который Ван Якобсон впервые публично представил в 2006 году. Проект NDN исследует предложенную Якобсоном эволюцию от сегодняшней хост-центричной сетевой архитектуры IP к архитектуре сети, ориентированной на данные (NDN). Заявленная цель этого проекта заключается в том, чтобы с помощью концептуально простого сдвига можно было реализовать далеко идущие последствия для того, как люди проектируют, разрабатывают, развертывают и используют сети и приложения. [3]

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

Его предпосылка заключается в том, что Интернет в первую очередь используется как сеть распространения информации , что не очень хорошо подходит для IP , и что будущая «тонкая талия» Интернета должна быть основана на именованных данных, а не на численно адресуемых хостах. Основной принцип заключается в том, что коммуникационная сеть должна позволять пользователю сосредоточиться на необходимых ему данных, именованном контенте , а не ссылаться на конкретное физическое местоположение, откуда эти данные должны быть извлечены, именованных хостах . Мотивация этого исходит из того факта, что подавляющее большинство текущего использования Интернета («высокий уровень трафика 90%) состоит из данных, распространяемых из источника нескольким пользователям. [4] Сетевые именованные данные обладают потенциалом для широкого спектра преимуществ, таких как кэширование контента для снижения перегрузки и повышения скорости доставки, более простая конфигурация сетевых устройств и встраивание безопасности в сеть на уровне данных.

Обзор

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


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

Проект Named Data Networking (NDN) предложил эволюцию архитектуры IP, которая обобщает роль этой тонкой талии, так что пакеты могут именовать объекты, отличные от конечных точек связи. Более конкретно, NDN изменяет семантику сетевого сервиса с доставки пакета по заданному адресу назначения на выборку данных, идентифицированных заданным именем. Имя в пакете NDN может именовать что угодно — конечную точку, фрагмент данных в фильме или книге, команду включить свет и т. д. Надежда состоит в том, что это концептуально простое изменение позволит сетям NDN применять почти все хорошо проверенные инженерные свойства Интернета к более широкому кругу проблем за пределами сквозных коммуникаций. [6] Примерами применения NDN уроков, извлеченных из 30 лет сетевой инженерии, являются то, что саморегулирование сетевого трафика (через баланс потока между Interest (запрос данных) и пакетами данных) и примитивы безопасности (через подписи для всех именованных данных) интегрированы в протокол с самого начала.

История

Ранние исследования

Философия NDN была впервые предложена Тедом Нельсоном в 1979 году, а затем Брентом Баккалой в 2002 году. В 1999 году проект TRIAD в Стэнфорде предложил избегать поиска DNS, используя имя объекта для маршрутизации к его близкой копии. В 2006 году проект Data-Oriented Network Architecture (DONA) в Калифорнийском университете в Беркли и ICSI предложил контентно-ориентированную сетевую архитектуру, которая улучшила TRIAD, включив безопасность (аутентичность) и постоянство в качестве первоклассных примитивов в архитектуру. Ван Якобсон выступил с докладом Google Talk, A New Way to Look at Networking, в 2006 году об эволюции сети и утверждал, что NDN — это следующий шаг. В 2009 году PARC анонсировала свою контентно-ориентированную архитектуру в рамках проекта CCNx , который возглавлял Якобсон, который в то время был научным сотрудником PARC. 21 сентября 2009 года PARC опубликовал спецификации для взаимодействия и выпустил начальную реализацию с открытым исходным кодом (под лицензией GPL ) исследовательского проекта Content-Centric Networking на сайте Project CCNx. NDN является одним из примеров более общего направления сетевых исследований, называемого информационно-центричными сетями (ICN), в рамках которого появились различные архитектурные проекты. [7] Internet Research Task Force (IRTF) создала исследовательскую рабочую группу ICN в 2012 году.

Текущее состояние

NDN включает шестнадцать финансируемых NSF главных исследователей в двенадцати кампусах и растущий интерес со стороны академических и промышленных исследовательских сообществ. [8] [9] Более 30 учреждений формируют глобальный испытательный стенд. Существует большой объем исследований и активно растущая кодовая база. внесен в NDN.

В настоящее время пересылка NDN поддерживается в Ubuntu 18.04 и 20.04, Fedora 20+, CentOS 6+, Gentoo Linux, Raspberry Pi, OpenWRT, FreeBSD 10+ и нескольких других платформах. Общие клиентские библиотеки активно поддерживаются для языков программирования C++, Java, Javascript, Python, .NET Framework (C#) и Squirrel. NDN-LITE — это облегченная библиотека NDN, разработанная для сетей IoT и ограниченных устройств. NDN-LITE активно разрабатывается, и на данный момент NDN-LITE адаптирована для плат POSIX, RIOT OS, NRF. Симулятор и эмулятор NDN также доступны и активно разрабатываются. Разрабатывается несколько клиентских приложений в областях конференций в реальном времени, дружественных NDN файловых систем, чата, обмена файлами и IoT.

Основные архитектурные принципы

  • Принцип сквозного проектирования : позволяет разрабатывать надежные приложения в условиях сетевых сбоев. NDN сохраняет и расширяет этот принцип проектирования.
  • Разделение плоскости маршрутизации и пересылки: Это оказалось необходимым для развития Интернета. Это позволяет плоскости пересылки функционировать, в то время как система маршрутизации продолжает развиваться с течением времени. NDN использует тот же принцип, чтобы обеспечить развертывание NDN с наилучшей доступной технологией пересылки, пока ведутся исследования новой системы маршрутизации.
  • Пересылка с отслеживанием состояния: маршрутизаторы NDN сохраняют состояние недавно пересланных пакетов, что обеспечивает интеллектуальную пересылку, обнаружение петель, балансировку потока, повсеместное кэширование и т. д.
  • Встроенная безопасность: в NDN передача данных защищена на сетевом уровне путем подписания и проверки любых именованных данных. [10]
  • Обеспечить выбор и конкуренцию для пользователей: Архитектура должна способствовать выбору и конкуренции для пользователей, где это возможно. Хотя это и не было важным фактором в изначальном дизайне Интернета, глобальное развертывание продемонстрировало, что «архитектура не является нейтральной». [11] NDN делает сознательные усилия для расширения прав и возможностей конечных пользователей и обеспечения конкуренции.

Обзор архитектуры

Типы пакетов

Коммуникация в NDN осуществляется получателями, то есть потребителями данных, посредством обмена двумя типами пакетов: Interest и Data. Оба типа пакетов имеют имя, которое идентифицирует часть данных, которая может быть передана в одном пакете данных.

Обзор содержимого пакета NDN

Типы пакетов

  • Интерес: Потребитель помещает имя желаемого фрагмента данных в пакет Interest и отправляет его в сеть. Маршрутизаторы используют это имя для пересылки Interest производителю(ям) данных.
  • Данные: Как только Interest достигает узла, имеющего запрошенные данные, узел возвращает пакет Data, содержащий как имя, так и содержимое, вместе с подписью ключа производителя, который связывает их. Этот пакет Data следует в обратном направлении по пути, пройденному Interest, чтобы вернуться к запрашивающему потребителю.

Полную спецификацию см. в разделе «Спецификация формата пакета NDN».

Архитектура маршрутизатора

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

  • Таблица ожидаемых интересов (PIT): хранит все интересы, которые маршрутизатор переслал, но еще не удовлетворил. Каждая запись PIT записывает имя данных, передаваемых в интересе, вместе с его входящим и исходящим интерфейсом(ами).
  • Forwarding Information Base (FIB): таблица маршрутизации, которая сопоставляет компоненты имени с интерфейсами. Сама FIB заполняется протоколом маршрутизации на основе имени-префикса и может иметь несколько выходных интерфейсов для каждого префикса.
  • Хранилище контента (CS): временный кэш пакетов данных, полученных маршрутизатором. Поскольку пакет данных NDN имеет смысл независимо от того, откуда он пришел или куда он был переслан, его можно кэшировать для удовлетворения будущих интересов. Стратегия замены традиционно используется реже всего, но стратегия замены определяется маршрутизатором и может отличаться.
  • Стратегии пересылки: ряд политик и правил пересылки интересов и пакетов данных. Обратите внимание, что стратегия пересылки может решить отбросить интерес в определенных ситуациях, например, если все восходящие соединения перегружены или есть подозрения, что интерес является частью DoS-атаки. Эти стратегии используют ряд триггеров в конвейере пересылки и назначаются префиксам имен. Например, по умолчанию /localhost использует стратегию многоадресной пересылки для пересылки интересов и данных любому локальному приложению, работающему на клиентском NFD. Стратегия пересылки по умолчанию (т. е. "/") — это стратегия пересылки по лучшему маршруту.

Когда приходит пакет Interest, маршрутизатор NDN сначала проверяет Content Store на предмет соответствия данных; если он существует в маршрутизаторе, он возвращает пакет Data на интерфейсе, с которого пришел Interest. В противном случае маршрутизатор ищет имя в своем PIT, и если соответствующая запись существует, он просто записывает входящий интерфейс этого Interest в запись PIT. При отсутствии соответствующей записи PIT маршрутизатор пересылает Interest производителю(ям) данных на основе информации в FIB, а также адаптивной стратегии пересылки маршрутизатора. Когда маршрутизатор получает Interest для одного и того же имени от нескольких нижестоящих узлов, он пересылает только первый из них вверх по течению к производителю(ям) данных.

Когда приходит пакет данных, маршрутизатор NDN находит соответствующую запись PIT и пересылает данные на все нисходящие интерфейсы, перечисленные в этой записи PIT. Затем он удаляет эту запись PIT и кэширует данные в хранилище контента. Пакеты данных всегда проходят по обратному пути Interests, и при отсутствии потерь пакетов один пакет Interest приводит к одному пакету Data на каждом канале, обеспечивая баланс потока. Для извлечения больших объектов контента, которые состоят из нескольких пакетов, Interests выполняют ту же роль в управлении потоком трафика, что и TCP ACK в современном Интернете: мелкозернистый цикл обратной связи, контролируемый потребителем данных.

Ни пакеты Interest, ни пакеты Data не содержат адресов хоста или интерфейса; маршрутизаторы пересылают пакеты Interest производителям данных на основе имен, содержащихся в пакетах, и пересылают пакеты Data потребителям на основе информации о состоянии PIT, установленной Interests на каждом переходе. Эта симметрия обмена пакетами Interest/Data вызывает цикл управления по переходам (не путать с симметричной маршрутизацией или с маршрутизацией вообще!) и устраняет необходимость в каком-либо понятии узлов источника или назначения при доставке данных, в отличие от модели доставки пакетов IP «от конца до конца».

Имена

Дизайн

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

Структура

Дизайн NDN предполагает иерархически структурированные имена, например, видео, созданное UCLA, может иметь имя /ucla/videos/demo.mpg, где '/' обозначает компоненты имени в текстовых представлениях, подобно URL-адресам. Эта иерархическая структура имеет много потенциальных преимуществ:

  • Спецификация отношений: позволяет приложениям представлять контекст и отношения элементов данных. НАПРИМЕР: сегмент 3 версии 1 демонстрационного видео UCLA может быть назван /ucla/videos/demo.mpg/1/3
  • Агрегация имен: /ucla может соответствовать автономной системе, создающей видео
  • Маршрутизация: позволяет системе масштабироваться и помогает обеспечить необходимый контекст для данных.

Указание имени

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

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

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

Пространства имен

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

  • повышение точности сопоставления данных приложения и его использования сети.
  • снижение потребности во вторичной записи (ведение записей для сопоставления конфигурации приложения с конфигурацией сети).
  • расширение спектра абстракций, доступных разработчикам.
  • Запросы на контент на основе имени также вызывают опасения по поводу утечки конфиденциальности . Благодаря разделению управления пространством имен от архитектуры NDN, можно обеспечить схему именования, сохраняющую конфиденциальность, внеся незначительные изменения в традиционную схему именования NDN. [13]

Маршрутизация

Решения проблем интеллектуальной собственности

NDN маршрутизирует и пересылает пакеты на основе имен, что устраняет три проблемы, вызванные адресами в архитектуре IP:

  • Исчерпание адресного пространства : Пространство имен NDN по сути не ограничено. Пространство имен ограничено только максимальным размером пакета интересов 8 Кб и числом возможных уникальных комбинаций символов, составляющих имена.
  • Обход NAT : NDN устраняет необходимость в адресах, как публичных, так и частных, поэтому NAT становится ненужным.
  • Управление адресами: в локальных сетях больше не требуется назначение и управление адресами.
  • В сетевой многоадресной рассылке : производитель данных не должен получать несколько интересов для одних и тех же данных, поскольку записи PIT на нисходящих пересылающих устройствах будут объединять интересы. Производитель получает и отвечает на один интерес, а те узлы пересылки, в которых было получено несколько входящих интересов, будут многоадресно рассылать ответы на данные на интерфейсы, с которых были получены эти интересы.
  • Высокая сквозная надежность потерь: сети на основе IP требуют, чтобы потерянные или отброшенные пакеты были повторно переданы отправителем. Однако в NDN, если интерес истекает до того, как ответ с данными достигнет запрашивающей стороны, ответ с данными все равно кэшируется пересылающими устройствами на обратном пути. Повторно переданный интерес должен достичь пересылающего устройства только с кэшированной копией данных, что обеспечивает сетям на основе NDN более высокую пропускную способность, чем сетям на основе IP, когда показатели потери пакетов высоки.

Протоколы

NDN может использовать обычные алгоритмы маршрутизации, такие как состояние канала и вектор расстояния . Вместо объявления префиксов IP маршрутизатор NDN объявляет префиксы имен, которые охватывают данные, которые маршрутизатор готов обслуживать. Обычные протоколы маршрутизации, такие как OSPF и BGP , могут быть адаптированы для маршрутизации по префиксам имен, обрабатывая имена как последовательность непрозрачных компонентов и выполняя покомпонентное сопоставление самого длинного префикса имени в пакете Interest с таблицей FIB . [14] Это позволяет объединять широкий спектр входных данных в режиме реального времени и распределять их по нескольким интерфейсным средам одновременно, не нарушая шифрование контента. [15] Ключевая аналитика интерфейса также не затрагивается процессом. Передача приложений и совместное использование данных в среде определяются многомодальной распределительной структурой, так что затронутые протоколы облачной ретрансляции уникальны для индивидуального идентификатора среды выполнения. [16]

состояние ПИТ

Состояние PIT на каждом маршрутизаторе поддерживает пересылку через плоскость данных NDN, записывая каждый ожидающий Interest и входящий интерфейс(ы), и удаляя Interest после получения соответствующих Data или истечения времени ожидания. Это состояние на каждый переход, на каждый пакет отличается от плоскости данных без сохранения состояния IP. На основе информации в FIB и измерений производительности модуль адаптивной стратегии пересылки в каждом маршрутизаторе принимает обоснованные решения о:

  • Поток управления: поскольку каждый интерес извлекает не более одного пакета данных, маршрутизатор может напрямую управлять потоком, контролируя количество ожидающих интереса, которые он хранит.
  • Многоадресная доставка данных: PIT, записывающий набор интерфейсов, на которые поступили одни и те же данные, естественным образом поддерживает эту функцию.
  • Обновление путей для учета изменений в их представлении о сети. [17]
  • Доставка: маршрутизатор может рассуждать о том, какие интересы пересылать на какие интерфейсы, сколько неудовлетворенных интересов разрешать в PIT, а также об относительном приоритете различных интересов.

Интерес

Если маршрутизатор решает, что Interest не может быть удовлетворен, например, восходящий канал не работает, нет записи пересылки в FIB или возникла экстремальная перегрузка, маршрутизатор может отправить NACK своим нисходящим соседям, которые передали Interest. Такое отрицательное подтверждение (NACK) может заставить принимающий маршрутизатор переслать Interest на другие интерфейсы для исследования альтернативных путей. Состояние PIT позволяет маршрутизаторам идентифицировать и отбрасывать зацикленные пакеты, что позволяет им свободно использовать несколько путей к одному и тому же производителю данных. Пакеты не могут зацикливаться в NDN, что означает, что нет необходимости во времени жизни и других мерах, реализованных в IP и связанных протоколах для решения этих проблем.

Безопасность

Обзор

В отличие от безопасности TCP/IP (например, TLS), которая защищает связь, защищая каналы IP-to-IP, NDN защищает сами данные, требуя от производителей данных криптографически подписывать каждый пакет данных. Подпись издателя обеспечивает целостность и позволяет аутентифицировать происхождение данных , позволяя разделить доверие потребителя к данным от того, как или где они получены. NDN также поддерживает мелкозернистое доверие, позволяя потребителям рассуждать о том, является ли владелец открытого ключа приемлемым издателем для определенной части данных в определенном контексте. Вторым основным направлением исследований является проектирование и разработка пригодных для использования механизмов для управления доверием пользователей. Были проведены исследования 3 различных типов моделей доверия:

  • иерархическая модель доверия: где пространство имен ключей разрешает использование ключей. Пакет данных, содержащий открытый ключ, фактически является сертификатом, поскольку он подписан третьей стороной, и этот открытый ключ используется для подписи определенных данных. [18]
  • сеть доверия : для обеспечения безопасной связи без необходимости предварительно согласованных якорей доверия. [19]
  • Легковесное доверие для IoT : модель доверия NDN, в первую очередь основанная на асимметричной криптографии , которая невозможна для устройств с ограничениями ресурсов в парадигме IoT. [13]

Безопасность приложений

Безопасность NDN, ориентированная на данные, имеет естественные приложения для контроля доступа к контенту и безопасности инфраструктуры. Приложения могут шифровать данные и распространять ключи в виде именованных пакетов, используя ту же именованную инфраструктуру для распространения ключей, эффективно ограничивая периметр безопасности данных контекстом одного приложения. Чтобы проверить подпись пакета данных, приложение может извлечь соответствующий ключ, идентифицированный в поле локатора ключа пакета, как и любой другой контент. Но управление доверием, т. е. как определить подлинность данного ключа для конкретного пакета в данном приложении, является основной исследовательской задачей. В соответствии с экспериментальным подходом, исследования управления доверием NDN обусловлены разработкой и использованием приложений: сначала решаются конкретные проблемы, а затем определяются общие закономерности. Например, потребности безопасности NLSR потребовали разработки простой иерархической модели доверия с ключами на более низких (ближе к корневому) уровнях, которые используются для подписи ключей на более высоких уровнях, на которых ключи публикуются с именами, отражающими их доверительные отношения. В этой модели доверия пространство имен соответствует иерархии делегирования доверия, т. е. /root/site/operator/ router/process. Публикация ключей с определенным именем в иерархии разрешает им подписывать определенные пакеты данных и ограничивает их область действия. Эту парадигму можно легко распространить на другие приложения, где реальное доверие имеет тенденцию следовать иерархическому шаблону, например, в наших системах управления зданиями (BMS). [20] Поскольку NDN оставляет модель доверия под контролем каждого приложения, могут быть также выражены более гибкие и выразительные доверительные отношения. Одним из таких примеров является ChronoChat, [19] , который побудил экспериментировать с моделью сети доверия. Модель безопасности заключается в том, что текущий участник чата может представить новичка другим, подписав ключ новичка. Будущие приложения будут реализовывать модель перекрестной сертификации (SDSI) [13, 3], которая обеспечивает большую избыточность проверки, позволяя данным и именам ключей быть независимыми, что более легко вмещает различные реальные доверительные отношения.

Эффективность и безопасность маршрутизации

Кроме того, NDN обрабатывает сообщения маршрутизации и управления сетью как все данные NDN, требующие подписей. Это обеспечивает прочную основу для защиты протоколов маршрутизации от атак, например, спуфинга и подделки. Использование NDN многопутевой пересылки вместе с модулем адаптивной стратегии пересылки смягчает перехват префикса, поскольку маршрутизаторы могут обнаруживать аномалии, вызванные перехватом, и извлекать данные через альтернативные пути. [21] Благодаря многоисточниковой, многоадресной природе доставки контента Named Data Networking случайное линейное кодирование может повысить общую эффективность сети. [22] Поскольку пакеты NDN ссылаются на контент, а не на устройства, сложнее злонамеренно нацелиться на конкретное устройство, хотя механизмы смягчения потребуются против других атак, специфичных для NDN, например, DoS-атак Interest flooding . [23] [24] Кроме того, наличие таблицы Pending Interest, которая хранит состояние относительно прошлых запросов, что может принимать обоснованные решения о том, как обрабатывать Interest, имеет многочисленные преимущества в области безопасности: [25]

  • Балансировка нагрузки: количество записей PIT является индикатором нагрузки на маршрутизатор; ограничение их размера ограничивает эффект DDoS-атаки.
  • Тайм-аут интересов: тайм-ауты записей PIT обеспечивают относительно дешевое обнаружение атак, а информация об интерфейсе прибытия в каждой записи PIT может поддерживать схему push-back, в которой маршрутизаторы нижестоящего уровня информируются о неудовлетворенных интересах, что помогает обнаруживать атаки.

Смотрите также

Ссылки

  1. ^ "NSF Future Internet Architectures (FIA)". nsf.gov . Национальный научный фонд.
  2. ^ "NSF - Будущие архитектуры Интернета". Будущие архитектуры Интернета - Следующая фаза . Национальный научный фонд.
  3. ^ Чжан, Лися ; Афанасьев, Александр; Берк, Джеффри; Якобсон, Ван; Клаффи, К.С.; Кроули, Патрик; Пападопулос, Христос; Ван, Лань; Чжан, Бэйчуань (28 июля 2014 г.). «Именованные сети передачи данных». ACM SIGCOMM Computer Communication Review . 44 (3): 66–73. doi :10.1145/2656877.2656887. S2CID  8317810.
  4. ^ Якобсон, Ван. «Новый взгляд на сетевое взаимодействие». You Tube . Google Talk.
  5. ^ Якобсон, Ван; Сметтерс, Диана К.; Торнтон, Джеймс Д.; Пласс, Майкл; Бриггс, Ник; Брейнард, Ребекка (1 января 2012 г.). «Сетевое именованное содержимое». Сообщения ACM . 55 (1): 117. doi :10.1145/2063176.2063204. S2CID  52895555.
  6. ^ "Сети: Краткое изложение". named-data.net/ . Named Data Networking.
  7. ^ Ксиломен, Джордж; Верверидис, Кристофер Н.; Сирис, Василиос А.; Фотиу, Никос; Цилопулос, Христос; Василакос, Ксенофонт; Кацарос, Константинос В.; Полизос, Джордж К. (2014). «Обзор информационно-центрических сетевых исследований». Опросы и учебные пособия IEEE по коммуникациям . 16 (2): 1024–1049. CiteSeerX 10.1.1.352.2228 . doi : 10.1109/SURV.2013.070813.00063. S2CID  6645760. 
  8. ^ "Именованные сети передачи данных: участники следующего этапа". named-data.net . Именованные сети передачи данных.
  9. ^ Кислюк, Билл (3 сентября 2015 г.). «Консорциум под руководством UCLA сосредоточится на разработке новой архитектуры для Интернета». UCLA Newsroom . № НАУКА + ТЕХНОЛОГИИ. Калифорнийский университет в Лос-Анджелесе. Калифорнийский университет в Лос-Анджелесе.
  10. ^ Сметтерс, Диана; Якобсон, Ван. Защита сетевого контента (PDF) (Технический отчет).
  11. ^ Кларк, Д.Д.; Вроцлавски, Дж.; Соллинс, К.Р.; Брейден, Р. (2005). «Схватка в киберпространстве: определение завтрашнего Интернета». IEEE/ACM Transactions on Networking . 13 (3): 462–475. CiteSeerX 10.1.1.163.3356 . doi :10.1109/TNET.2005.850224. S2CID  47081087. 
  12. ^ Моисеенко, Илья; Чжан, Лися (25 августа 2014 г.). «API потребителя-производителя для именованных сетей передачи данных». Технические отчеты NDN .
  13. ^ ab Bilal, Muhammad; et al. (2020). «Безопасное распределение защищенного контента в информационно-ориентированных сетях». IEEE Systems Journal . 14 (2): 1921–1932. arXiv : 1907.11717 . Bibcode : 2020ISysJ..14.1921B. doi : 10.1109/JSYST.2019.2931813. S2CID  198967720.
  14. ^ Чжан и др. (2014). «Именованные сети передачи данных». Обзор компьютерных коммуникаций ACM SIGCOMM . 44 (3): 66–73. doi :10.1145/2656877.2656887. S2CID  8317810.
  15. ^ Гали и др. (2014). «Иголка в стоге сена: смягчение отравления контента в сетях с именованными данными». Труды семинара NDSS по безопасности новых сетевых технологий . doi :10.14722/sent.2014.23014. ISBN 978-1-891562-36-5.
  16. ^ Чжу, З (2013). «Let's ChronoSync: децентрализованная синхронизация состояний наборов данных в именованных сетях передачи данных». 2013 21-я Международная конференция IEEE по сетевым протоколам (ICNP) . стр. 1–10. doi :10.1109/ICNP.2013.6733578. ISBN 978-1-4799-1270-4. S2CID  14086875.
  17. ^ Йи, Ченг; Афанасьев Александр; Ван, Лан; Чжан, Бэйчуань; Чжан, Лися (26 июня 2012 г.). «Адаптивная пересылка в именованных сетях передачи данных». Обзор компьютерных коммуникаций ACM SIGCOMM . 42 (3): 62. CiteSeerX 10.1.1.251.2724 . дои : 10.1145/2317307.2317319. S2CID  8598344. 
  18. ^ Якобсон, Ван; Сметтерс, Дайан К.; Торнто, Джемс Д.; Пласс, Микаэль Ф.; Бриггс, Николас Х.; Брейнард, Ребекка Л. (2009-12-01). "Сетевой именованный контент". Труды 5-й международной конференции по новым сетевым экспериментам и технологиям . С. 1–12. CiteSeerX 10.1.1.642.2386 . doi :10.1145/1658939.1658941. ISBN  9781605586366. S2CID  220961152.
  19. ^ ab Zhu, Zhenkai; Bian, Chaoyi; Afanasyev, Alexander; Jacobson, Van; Zhang, Lixia (10 октября 2012 г.). "Chronos: Serverless Multi-User Chat Over NDN" (PDF) . Технические отчеты NDN .
  20. ^ Шан, Вентао; Дин, Цюхань; Марианантони, А.; Берк, Дж.; Чжан, Лися (26 июня 2014 г.). «Защита систем управления зданиями с использованием именованных сетей передачи данных». IEEE Network . 28 (3): 50–56. doi :10.1109/MNET.2014.6843232. S2CID  8859671.
  21. ^ Йи, Ченг; Афанасьев Александр; Моисеенко Илья; Ван, Лан; Чжан, Бэйчуань; Чжан, Лися (2013). «Дело в пользу самолета пересылки с сохранением состояния». Компьютерные коммуникации . 36 (7): 779–791. CiteSeerX 10.1.1.309.1500 . дои : 10.1016/j.comcom.2013.01.005. 
  22. ^ Билал, Мухаммад и др. (2019). «Подход к сетевому кодированию для информационно-ориентированных сетей». IEEE Systems Journal . 13 (2): 1376–1385. arXiv : 1808.00348 . Bibcode : 2019ISysJ..13.1376B. doi : 10.1109/JSYST.2018.2862913. S2CID  51894197.
  23. ^ Афанасьев, Александр; Махадеван, Прия; Моисеенко, Илья; Узун, Эрсин; Чжан, Лися (2013). «Атака с переполнением интересами и меры противодействия в именованных сетях передачи данных» (PDF) . IFIP .
  24. ^ Вэлиш, Маттиас; Шмидт, Томас К.; Фаленкамп, Маркус (2013). «Обратное рассеяние из плоскости данных — угрозы стабильности и безопасности в информационно-ориентированной сетевой инфраструктуре» (PDF) . Компьютерные сети . 57 (16): 3192–3206. arXiv : 1205.4778 . doi : 10.1016/j.comnet.2013.07.009. S2CID  5767511.
  25. ^ Афанасьев, Александр; Махадеван, Прия; Моисеенко, Илья; Узун, Эрсин; Чжан, Лися (2013). «Атака с переполнением интересами и меры противодействия в именованных сетях передачи данных» (PDF) . IFIP .
  • СМЕРТЬ TCP/IP крик Cisco, Intel, правительство США и множество ученых
  • FIA-NP: Совместные исследования: Новая фаза именованных сетей передачи данных (NDN-NP)
  • Домашняя страница Named Data Research
  • Награды NSF для NDN 2
  • FIA: Совместные исследования: именованные сети передачи данных (NDN)
  • Сеть именованных функций (NFN)
  • NDN на Galileo (снимок WebArchive)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Named_data_networking&oldid=1231301199"