Рекурсивная межсетевая архитектура - Recursive Internetwork Architecture

В Рекурсивная межсетевая архитектура (RINA) это новый компьютер сетевая архитектура предлагается в качестве альтернативы архитектуре популярной в настоящее время Набор интернет-протоколов. Основополагающие принципы RINA: компьютерная сеть просто Межпроцессного взаимодействия или IPC, и это разделение на уровни должно выполняться на основе области действия / масштаба с одним повторяющимся набором протоколов, а не на основе функции со специализированными протоколами. Экземпляры протокола на одном уровне взаимодействуют с экземплярами протокола на более высоких и нижних уровнях через новые концепции и объекты, которые эффективно овеществлять сетевые функции, в настоящее время специфичные для таких протоколов, как BGP, OSPF и ARP. Таким образом, RINA утверждает, что поддерживает такие функции, как мобильность, множественная адресация и Качество обслуживания без необходимости в дополнительных специализированных протоколах, таких как RTP и UDP, а также для упрощения сетевого администрирования без необходимости использования таких концепций, как автономные системы и NAT.

Фон

Принципы, лежащие в основе RINA, впервые были представлены Джон Дэй в своей книге 2008 года Паттерны в сетевой архитектуре: возвращение к основам.[1] Эта работа является началом новой работы с учетом уроков, извлеченных за 35 лет TCP / IP Существования, а также уроки OSI Провала и уроки других сетевых технологий последних нескольких десятилетий, таких как ЦИКЛАДЫ, DECnet, и Сетевые системы Xerox.

Отправной точкой для радикально новой и отличной сетевой архитектуры, такой как RINA, является попытка решить следующие проблемы или ответ на них, которые, по-видимому, не имеют практических или безупречных решений с текущими сетевыми архитектурами, особенно Набор интернет-протоколов и его функциональное распределение, как показано на рисунке 1:

Рисунок 1. Функциональное распределение TCP / IP архитектура
  • Сложность передачи: разделение IP и TCP приводит к неэффективности, с Обнаружение MTU выполняется для предотвращения Фрагментация IP это самый явный симптом.
  • Производительность: TCP сам несет в себе довольно высокие накладные расходы на свое рукопожатие, что также вызывает уязвимости, такие как SYN флуд. Кроме того, TCP полагается на отбрасывание пакетов для саморегулирования и предотвращения перегрузки, что означает, что его контроль перегрузки является чисто реактивным, а не упреждающим или превентивным. Это плохо взаимодействует с большими буферами, что приводит к буфер.[2]
  • Множественная адресация: the айпи адрес и номер порта слишком низкоуровневые, чтобы идентифицировать приложение в двух разных сетях. DNS не решает это, потому что имена хостов должны разрешаться в единую комбинацию IP-адреса и номера порта, делая их псевдонимами вместо идентификаторов. Также не делает LISP, потому что i) он по-прежнему использует локатор, который является IP-адресом, для маршрутизации, и ii) он основан на ложном различении, поскольку все объекты в области с самого начала расположены по своим идентификаторам;[3] кроме того, он также создает собственные проблемы масштабируемости.[4]
  • Мобильность: IP-адрес и номер порта также слишком низкоуровневые, чтобы идентифицировать приложение при его перемещении между сетями, что создает сложности для мобильных устройств, таких как смартфоны. Хотя решение, Мобильный IP на самом деле перекладывает проблему полностью на Адрес для передачи и вводит IP-туннель с сопутствующей сложностью.
  • Управление: одинаковый низкоуровневый характер IP-адреса способствует выделению нескольких адресов или даже диапазонов адресов для отдельных хостов.[5], оказывая давление на выделения и ускоряя истощение. NAT только задерживает исчерпание адресов и потенциально создает еще больше проблем. В то же время функциональная многоуровневая архитектура пакета Интернет-протоколов оставляет место только для двух областей, усложняя разделение администрирования Интернета и требуя искусственного представления об автономных системах. OSPF и IS-IS имеют относительно немного проблем, но плохо масштабируются, вынуждая использовать BGP для более крупных сетей и междоменной маршрутизации.
  • Безопасность: природа пространства IP-адресов сама по себе приводит к слабой безопасности, поскольку не существует действительно настраиваемой политики для добавления или удаления IP-адресов, кроме физического предотвращения прикрепления. TLS и IPSec предлагать решения, но с сопутствующей сложностью. Межсетевые экраны и черные списки уязвимы для подавляющего большинства, следовательно, не масштабируемы. «[...] опыт показал, что сложно добавить безопасность в набор протоколов, если она не встроена в архитектуру с самого начала».[6]

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

1972: Множественная адресация не поддерживается ARPANET

В 1972 году база ВВС Тинкер.[7] хотел связи с двумя разными IMP для резервирования. Разработчики ARPANET поняли, что они не могут поддерживать эту функцию, потому что адреса хостов были адресами номера порта IMP, к которому был подключен хост (заимствование из телефонии). Для ARPANET два интерфейса одного и того же хоста имели разные адреса; другими словами, адрес был слишком низким для идентификации хоста.

1978: TCP отделен от IP

Первоначальные версии TCP выполняли функции управления ошибками и потоком (текущий TCP), а также функции ретрансляции и мультиплексирования (IP) в одном протоколе. В 1978 году TCP был отделен от IP, хотя оба уровня имели одинаковую область действия. К 1987 году сетевое сообщество было хорошо осведомлено о проблемах фрагментации IP до такой степени, что оно считалось вредным.[8] Однако это не считалось признаком взаимозависимости TCP и IP.

1981: игнорирование фундаментальных результатов Уотсона

Ричард Уотсон в 1981 году представил фундаментальную теорию надежного транспорта.[9] при этом для управления соединением требуются только таймеры, ограниченные небольшим фактором максимального срока службы пакета (MPL). Основываясь на этой теории, Watson et al. разработал протокол Delta-t [10] который позволяет определять состояние соединения, просто ограничивая три таймера, без квитирования. С другой стороны, TCP использует как явное квитирование, так и более ограниченное управление состоянием соединения на основе таймера.

1983: Потеря межсетевого уровня

Рисунок 2. Архитектура Интернета с точки зрения INWG

В начале 1972 г. Международная сетевая рабочая группа (INWG) была создана, чтобы объединить зарождающееся сообщество сетевых исследователей. Одной из первых задач, которую он выполнил, было голосование по международному сетевому транспортному протоколу, утвержденному в 1976 году.[11] Примечательно, что выбранный вариант, как и все другие кандидаты, имел архитектуру, состоящую из трех уровней увеличивающегося объема: канал передачи данных (для обработки различных типов физических носителей), сеть (для обработки различных типов сетей) и объединенная сеть (для обрабатывать сеть сетей), каждый уровень имеет собственное адресное пространство. Когда был введен TCP / IP, он работал на межсетевом уровне поверх NCP. Но когда NCP был отключен, TCP / IP взял на себя роль сети, и межсетевой уровень был потерян.[12] Это объясняет потребность в автономных системах и NAT сегодня для разделения и повторного использования диапазонов пространства IP-адресов для облегчения администрирования.

1983: упущена первая возможность исправить адресацию

Необходимость адреса более высокого уровня, чем IP-адрес, была хорошо известна с середины 1970-х годов. Однако имена приложений не были введены, и DNS был разработан и развернут, продолжая использовать хорошо известные порты для идентификации приложений. Появление Интернета и HTTP возникла потребность в именах приложений, ведущих к URL-адресам. Однако URL-адреса привязывают каждый экземпляр приложения к физическому интерфейсу компьютера и определенному транспортному соединению, поскольку URL-адрес содержит DNS-имя IP-интерфейса и номер порта TCP, передавая проблемы множественной адресации и мобильности приложениям.

1986: коллапс перегрузки застает Интернет врасплох

Хотя проблема контроля перегрузки в сетях дейтаграмм была известна с 1970-х - начала 80-х годов,[13][14] то коллапс заторов в 1986 году застал Интернет врасплох. Что еще хуже, принятый контроль перегрузки - Ethernet предотвращение перегрузки Схема, с небольшими доработками - ставился в ПТС.

1988: Управление сетью делает шаг назад

В 1988 году IAB рекомендовал использовать SNMP как начальный протокол управления сетью для Интернета для последующего перехода к объектно-ориентированному подходу CMIP.[15] SNMP был шагом назад в управлении сетью, оправданным как временная мера, в то время как требуемые более сложные подходы были реализованы, но перехода так и не произошло.

1992: Упущена вторая возможность исправить адресацию

В 1992 г. IAB подготовил ряд рекомендаций по решению проблем масштабирования IPv4 Интернет на основе: потребление адресного пространства и взрывной рост маршрутной информации. Было предложено три варианта: ввести CIDR для смягчения проблемы; разработать следующую версию IP (IPv7) на основе CLNP; или продолжить исследования в области именования, адресации и маршрутизации.[16] CLNP был протоколом на основе OSI, который обращался к узлам, а не к интерфейсам, решая старую проблему множественной адресации, восходящую к ARPANET, и позволяет улучшить агрегацию информации о маршрутизации. CIDR был введен, но IETF не принимал IPv7 на основе CLNP. IAB пересмотрел свое решение, и начался процесс IPng, который завершился IPv6. Одним из правил IPng было не изменять семантику IP-адреса, который продолжает именовать интерфейс, что усугубляет проблему множественной адресации.[5]

Обзор

Рисунок 3. Распределенные прикладные процессы (DAP) и их компоненты

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

Основной объект RINA - это распределенный прикладной процесс или DAP, который часто соответствует процессу на хосте. Два или более DAP составляют средство распределенного приложения или DAF, как показано на рисунке 3. Эти DAP взаимодействуют с использованием общего протокола распределенных приложений или CDAP, обмениваясь структурированными данными в форме объектов. Эти объекты структурированы в базе информации о ресурсах или RIB, которая обеспечивает им схему именования и логическую организацию. CDAP обеспечивает шесть основных операций с объектами удаленного DAP: создание, удаление, чтение, запись, запуск и останов.

Для обмена информацией DAP нуждаются в базовом средстве, которое предоставляет им услуги связи. Это средство является еще одним DAF, называемым распределенным средством IPC или DIF, задачей которого является предоставление и управление услугами IPC в определенной области. DAP в DIF называются процессами IPC или IPCP. У них та же самая общая структура DAP, показанная на рисунке 3, плюс некоторые конкретные задачи по предоставлению и управлению IPC. Эти задачи, как показано на рисунке 4, можно разделить на три категории: передача данных, управление передачей данных и управление уровнями. Категории упорядочены по возрастанию сложности и уменьшению частоты, при этом передача данных является наиболее простой и частой, управление уровнями является наиболее сложным и наименее частым, а управление передачей данных - промежуточным.

Рисунок 4. Пример сетей RINA и компонентов IPCP.

DIF, будучи DAF, в свою очередь, сами используют другие базовые DIF, вплоть до физического уровня DIF, контролирующего провода и разъемы. Вот откуда взялась рекурсия RINA. Как показано на Рисунке 4, сети RINA обычно структурированы в DIF увеличивающегося объема. На рисунке 5 показан пример того, как Интернет может быть структурирован с помощью RINA: самый высокий уровень - ближайший к приложениям, соответствующий электронной почте или веб-сайтам; самые низкие уровни агрегируют и мультиплексируют трафик более высоких уровней, что соответствует Интернет-провайдер позвоночники. DIF с несколькими поставщиками (например, общедоступный Интернет или другие) плавают поверх уровней ISP. В этой модели различают три типа систем: хосты, содержащие DAP; внутренние маршрутизаторы, внутренние по отношению к слою; и граничные маршрутизаторы на краях уровня, где пакеты идут вверх или вниз на один уровень.

Рисунок 5. Несколько сетей RINA, поддерживающих несколько объединенных сетей.

DIF позволяет DAP распределять потоки одному или нескольким DAP, просто предоставляя имена целевых DAP и желаемые параметры QoS, такие как границы потери данных и задержки, упорядоченная или неупорядоченная доставка, надежность и т. Д. вперед. DAP могут не доверять DIF, который они используют, и поэтому могут защищать свои данные перед записью их в поток через SDU модуль защиты, например, зашифровав его. Все уровни RINA имеют одинаковую структуру и компоненты и обеспечивают одинаковые функции; они отличаются только своими конфигурациями или политиками.[18] Это отражает разделение механизма и политики в операционных системах.

Короче говоря, RINA сохраняет концепции PDU и SDU, но вместо разделения по функциям, она по уровням по объему. Вместо того чтобы считать, что разные шкалы имеют разные характеристики и атрибуты, он считает, что все коммуникации имеют в основном одинаковое поведение, только с разными параметрами. Таким образом, RINA - это попытка концептуализировать и параметризовать все аспекты коммуникации, тем самым устраняя необходимость в конкретных протоколах и концепциях и повторно используя как можно больше теории.

Именование, адресация, маршрутизация, мобильность и множественная адресация

Как объяснялось выше, IP-адрес является идентификатором слишком низкого уровня, на котором можно эффективно основывать множественную адресацию и мобильность, а также требовать, чтобы таблицы маршрутизации были больше, чем необходимо. Литература RINA следует общей теории Джерри Зальцер по адресации и именованию. По словам Зальцера, необходимо выделить четыре элемента: приложения, узлы, точки подключения и пути.[19] Приложение может работать на одном или нескольких узлах и должно иметь возможность перемещаться с одного узла на другой, не теряя своей идентичности в сети. Узел может быть подключен к паре точек подключения и должен иметь возможность перемещаться между ними, не теряя своей идентичности в сети. Каталог сопоставляет имя приложения с адресом узла, а маршруты представляют собой последовательности адресов узлов и точек подключения. Эти точки показаны на рисунке 6.

Рисунок 6. Иллюстрация теории Зальцера об именовании и адресации.

Зальцер взял свою модель из операционных систем, но авторы RINA пришли к выводу, что ее нельзя полностью применить к объединенным сетям, которые могут иметь более одного пути между одной и той же парой узлов (не говоря уже о целых сетях). Их решение состоит в том, чтобы моделировать маршруты как последовательности узлов: на каждом переходе соответствующий узел выбирает наиболее подходящую точку подключения для пересылки пакета следующему узлу. Следовательно, RINA выполняет маршрутизацию в два этапа: сначала рассчитывается маршрут как последовательность адресов узлов, а затем для каждого перехода выбирается соответствующая точка подключения. Вот шаги для создания таблицы пересылки: пересылка по-прежнему выполняется с одним поиском. Более того, последний шаг можно выполнять чаще, чтобы использовать множественную адресацию для балансировки нагрузки.

Эта структура именования по сути поддерживает мобильность и множественную адресацию.[20] если в названиях тщательно подобраны свойства:

  1. имена приложений не зависят от местоположения, что позволяет приложению перемещаться;
  2. адреса узлов зависят от местоположения, но не зависят от маршрута; и
  3. точки крепления по своей природе зависят от маршрута.

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

Дизайн протокола

Набор Интернет-протоколов также обычно требует, чтобы протоколы разрабатывались изолированно, независимо от того, были ли аспекты дублированы в других протоколах и, следовательно, могут ли они быть включены в политику. RINA пытается избежать этого, применяя разделение механизма и политики в операционных системах при разработке протокола.[21] Каждый DIF использует разные политики для обеспечения разных классов качества обслуживания и адаптации к характеристикам либо физического носителя, если DIF является низкоуровневым, либо приложений, если DIF является высокоуровневым.

RINA использует теорию протокола Delta-T[10] разработан Ричардом Ватсоном в 1981 году. Исследования Уотсона показывают, что достаточными условиями для надежной передачи являются привязка трех таймеров. Delta-T - это пример того, как это должно работать: у него нет установки соединения или разрыва. В том же исследовании также отмечается, что TCP уже использует эти таймеры в своей работе, что делает Delta-T сравнительно проще. Исследование Watson также предполагает, что синхронизация и распределение портов должны быть разными функциями, выделение портов должно быть частью управления уровнями, а синхронизация - частью передачи данных.

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

Рисунок 7. Организация охранных функций в RINA.

Для обеспечения безопасности RINA требует, чтобы каждый DIF / DAF определял политику безопасности, функции которой показаны на рисунке 7. Это позволяет защитить не только приложения, но и магистрали и сами коммутационные фабрики. Общедоступная сеть - это просто особый случай, когда политика безопасности ничего не делает. Это может привести к накладным расходам для небольших сетей, но лучше масштабируется с более крупными сетями, поскольку уровням не нужно координировать свои механизмы безопасности: текущий Интернет оценивается как требующий примерно в 5 раз больше отдельных объектов безопасности, чем RINA.[22] Среди прочего, политика безопасности может также определять механизм аутентификации; это делает устаревшими брандмауэры и черные списки, потому что DAP или IPCP, которые не могут присоединиться к DAF или DIF, не могут передавать или принимать. DIF также не раскрывают свои IPCP-адреса на более высоких уровнях, предотвращая широкий класс атак типа «человек посередине».

Сама конструкция протокола Delta-T с упором на простоту также является важным фактором. Например, поскольку протокол не имеет рукопожатия, у него нет соответствующих управляющих сообщений, которые могут быть подделаны, или состояния, которые могут быть использованы неправильно, как в случае SYN-лавинной рассылки. Механизм синхронизации также делает аномальное поведение более связанным с попытками вторжения, что значительно упрощает обнаружение атак.[23]

Исследовательские проекты

С момента публикации книги PNA в 2008–2014 годах RINA проделала большую исследовательскую и опытно-конструкторскую работу. Неформальная группа, известная как Общество Пузена, названный в честь Луи Пузен,[24] координирует несколько международных усилий.

Исследовательская группа BU

В Исследовательская группа RINA в Бостонском университете возглавляют профессора Абрахам Матта, Джон Дэй и Лу Читкушев, и был удостоен ряда грантов от Национальный фонд науки и EC, чтобы продолжить изучение основ RINA, разработать реализация прототипа с открытым исходным кодом через UDP / IP для Java [25][26] и поэкспериментируйте с ним поверх инфраструктуры GENI.[27][28] BU также является членом Pouzin Society и активным участником проектов FP7 IRATI и PRISTINE. В дополнение к этому, BU включила концепции и теорию RINA в свои курсы по компьютерным сетям.

FP7 IRATI

ИРАТИ является FP7 проект с 5 партнерами: i2CAT, Nextworks, iMinds, Interoute и Бостонский университет. Это произвело реализация RINA с открытым исходным кодом для ОС Linux поверх Ethernet[29][30].

FP7 PRISTINE

ПРИСТИН это проект, финансируемый FP7, с 15 партнерами: WIT-TSSG, i2CAT, Nextworks, Telefónica I + D, Thales, Nexedi, B-ISDN, Atos, Университет Осло, Juniper Networks, Университет Брно, IMT-TSP, CREATE-NET , iMinds и UPC. Его основная цель - изучить аспекты программируемости RINA для реализации инновационных политик для контроля перегрузки, распределения ресурсов, маршрутизации, безопасности и управления сетью.

Победитель конкурса GÉANT3 + ИРИНА

ИРИНА был профинансирован GÉANT3 + открытый конкурс, и это проект с четырьмя партнерами: iMinds, WIT-TSSG, i2CAT и Nextworks. Основная цель IRINA - изучить использование рекурсивной межсетевой архитектуры (RINA) в качестве основы сетевых архитектур следующего поколения NREN и GÉANT. IRINA основывается на прототипе IRATI и будет сравнивать RINA с текущим современным уровнем развития сети и соответствующей архитектурой с чистого листа, которая находится в стадии исследования; выполнить исследование практических примеров того, как RINA можно лучше использовать в сценариях NREN; и продемонстрировать лабораторные испытания исследования.

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

Рекомендации

  1. ^ Паттерны в сетевой архитектуре: возвращение к основам, Джон Дэй (2008), Прентис Холл, ISBN  978-0132252423
  2. ^ Л. Пузин. Методы, инструменты и наблюдения по управлению потоком в сетях с коммутацией пакетов данных. IEEE Transactions on Communications, 29 (4): 413–426, 1981.
  3. ^ J. Day. Почему разделение loc / id - не ответ, 2008 г. Доступно на сайте http://rina.tssg.org/docs/LocIDSplit090309.pdf
  4. ^ Д. Мейер и Д. Льюис. Архитектурные последствия разделения локатора / идентификатора. https://tools.ietf.org/html/draft-meyer-loc-id-implications-01
  5. ^ а б Р. Хинден и С. Диринг. «Архитектура адресации IP версии 6». RFC  4291 (Проект стандарта), февраль 2006 г. Обновлено в соответствии с RFC 5952, 6052
  6. ^ Д. Кларк, Л. Чапин, В. Серф, Р. Брейден и Р. Хобби. К будущей архитектуре Интернета. RFC  1287 (Информационное), декабрь 1991 г.
  7. ^ Фриц. E Froehlich; Аллен Кент (1992). «ARPANET, сеть передачи данных для обороны и Интернет». Энциклопедия телекоммуникаций Фрёлиха / Кента. 5. CRC Press. п. 82. ISBN  9780824729035.
  8. ^ C.A. Kent and J.C. Mogul. Фрагментация считается вредной. Proceedings of Frontiers in Computer Communications Technologies, ACM SIGCOMM, 1987
  9. ^ Р. Ватсон. Механизм на основе таймера в надежном управлении соединениями транспортного протокола. Компьютерные сети, 5: 47–56, 1981
  10. ^ а б Р. Ватсон. Спецификация протокола Delta-t. Технический отчет UCID-19293, Ливерморская национальная лаборатория Лоуренса, декабрь 1981 г.
  11. ^ Маккензи, Александр (2011). «INWG и концепция Интернета: рассказ очевидцев». IEEE Annals of the History of Computing. 33 (1): 66–71. Дои:10.1109 / MAHC.2011.9. ISSN  1934-1547. S2CID  206443072.
  12. ^ J. Day. Как, черт возьми, вы теряете слой !? 2-я Международная конференция IFIP Сети будущего, Париж, Франция, 2011 г.
  13. ^ Д. Дэвис. Методы, инструменты и наблюдения по управлению потоком в сетях с коммутацией пакетов данных. IEEE Transactions on Communications, 20 (3): 546–550, 1972 г.
  14. ^ С.С. Лам, Ю.С. Люк Льен. Контроль перегрузки сетей пакетной передачи данных с помощью ограничений входного буфера - исследование с помощью моделирования. IEEE Transactions on Computers, 30 (10), 1981.
  15. ^ Совет по архитектуре Интернета. Рекомендации IAB по разработке стандартов управления сетью Интернет. RFC  1052, Апрель 1988 г.
  16. ^ Совет по архитектуре Интернета. IP Версия 7 ** ПРОЕКТ 8 **. Проект IAB IPversion7, июль 1992 г.
  17. ^ Джон Дэй, Ибрагим Матта и Карим Маттар. Сеть - это IPC: руководящий принцип к лучшему Интернету. В материалах конференции ACM CoNEXT 2008. ACM, 2008 г.
  18. ^ И. Матта, Дж. Дэй, В. Исхакян, К. Маттар и Г. Гурсун. Декларативный транспорт: больше не нужно разрабатывать транспортные протоколы, нужно только определять политики. Технический отчет BUCS-TR-2008-014, Департамент CS, Бостон. U., июль 2008 г.
  19. ^ J. Saltzer. Об именовании и привязке сетевых пунктов назначения. RFC  1498 (Информационное), август 1993 г.
  20. ^ В. Исхакян, Дж. Акинвуни, Ф. Эспозито, И. Матта, «О поддержке мобильности и множественной адресации в рекурсивных интернет-архитектурах». Компьютерные коммуникации, том 35, выпуск 13, июль 2012 г., страницы 1561-1573
  21. ^ П. Бринч Хансен. Ядро многопрограммной системы. Сообщения ACM, 13 (4): 238-241, 1970
  22. ^ Дж. Смолл (2012), Шаблоны сетевой безопасности: анализ архитектурной сложности в защите сетей с рекурсивной межсетевой архитектурой
  23. ^ Г. Боддапати; Дж. Дэй; И. Матта; Л. Читкушев (июнь 2009 г.), Оценка безопасности архитектуры Интернета с чистого листа (PDF)
  24. ^ А. Л. Рассел, В. Шаффер. «В тени ARPAnet и Интернета: Луи Пузен и сеть Кикладов в 1970-х». Доступно на сайте http://muse.jhu.edu/journals/technology_and_culture/v055/55.4.russell.html
  25. ^ Флавио Эспозито, Юфенг Ван, Ибрагим Матта и Джон Дэй. Создание динамического уровня как услуги. Демонстрация на симпозиуме USENIX по проектированию и внедрению сетевых систем (NSDI ’13), Ломбард, Иллинойс, 2–5 апреля 2013 г.
  26. ^ Юэфэн Ван, Ибрагим Матта, Флавио Эспозито и Джон Дэй. Представляем ProtoRINA: прототип для программирования политик рекурсивной сети. Обзор компьютерных коммуникаций ACM SIGCOMM. Том 44, выпуск 3, июль 2014 г.
  27. ^ Юэфэн Ван, Флавио Эспозито и Ибрагим Матта. «Демонстрация RINA на стенде GENI». Второй семинар по исследованиям и образовательным экспериментам GENI (GREE 2013), Солт-Лейк-Сити, Юта, март 2013 г.
  28. ^ Юефенг Ван, Ибрагим Матта и Набиль Ахтар. «Эксперименты с политиками маршрутизации с использованием ProtoRINA поверх GENI». Третий научно-образовательный экспериментальный семинар GENI (GREE2014), 19–20 марта 2014 г., Атланта, Джорджия
  29. ^ С. Фрайдерс, Д. Стаэссенс, Д. Колле, Ф. Сальвестрини, Э. Граса, М. Тарзан и Л. Бергезио «Прототипирование рекурсивной межсетевой архитектуры: подход проекта IRATI», Сеть IEEE, Vol. 28, вып. 2 марта 2014 г.
  30. ^ С. Фрайдерс, Д. Стаэссенс, Д. Колле, Ф. Сальвестрини, В. Маффионе, Л. Бергезио, М. Тарзан, Б. Гастон, Э. Граса; «Экспериментальная оценка прототипа рекурсивной межсетевой архитектуры», IEEE Globecom 2014, Остин, Техас.

внешняя ссылка