Рекурсивная межсетевая архитектура
 |
Рекурсивная межсетевая архитектура (RINA) — это новая архитектура компьютерной сети, предложенная в качестве альтернативы архитектуре основного набора протоколов Интернета . Принципы, лежащие в основе RINA, были впервые представлены Джоном Дэем в его книге «Шаблоны сетевой архитектуры: возвращение к основам» в 2008 году . [1] Эта работа — это начало заново, с учетом уроков, извлеченных за 35 лет существования TCP/IP , а также уроков неудач OSI и уроков других сетевых технологий последних нескольких десятилетий, таких как CYCLADES. , DECnet и Xerox Network Systems . Фундаментальные принципы RINA заключаются в том, что компьютерные сети — это всего лишь межпроцессное взаимодействие или IPC, и что иерархическое разделение должно осуществляться на основе объема/масштаба с единым повторяющимся набором протоколов, а не на основе функций со специализированными протоколами. Экземпляры протоколов на одном уровне взаимодействуют с экземплярами протоколов на более высоких и нижних уровнях посредством новых концепций и объектов, которые эффективно реализуют сетевые функции, специфичные в настоящее время для таких протоколов, как BGP , OSPF и ARP . Таким образом, RINA утверждает, что поддерживает такие функции, как мобильность, множественная адресация и качество обслуживания , без необходимости использования дополнительных специализированных протоколов, таких как RTP и UDP , а также позволяет упростить администрирование сети без необходимости использования таких концепций, как автономные системы и NAT .
Обзор
[ редактировать ]
RINA является результатом усилий по разработке общих принципов компьютерных сетей , применимых во всех ситуациях. RINA — это конкретная архитектура, реализация, платформа тестирования и, в конечном итоге, развертывание модели, неофициально известной как модель IPC. [2] хотя здесь также рассматриваются концепции и результаты, применимые к любому распределенному приложению, а не только к сети. Что касается распределенных приложений, то большая часть терминологии связана с разработкой приложений, а не с сетями, что вполне понятно, учитывая, что фундаментальный принцип RINA заключается в сведении сетевых технологий к IPC.
Базовой сущностью RINA является процесс распределенного приложения или DAP, который часто соответствует процессу на хосте. Два или более DAP составляют Distributed Application Facility или DAF, как показано на рисунке 1. Эти DAP взаимодействуют с использованием общего протокола распределенных приложений или CDAP, обмениваясь структурированными данными в форме объектов. Эти объекты структурированы в базе информации о ресурсах или RIB, которая обеспечивает им схему именования и логическую организацию. CDAP обеспечивает шесть основных операций с объектами удаленного DAP: создание, удаление, чтение, запись, запуск и остановка. [ нужна ссылка ]
Для обмена информацией DAP необходим базовый механизм, задачей которого является предоставление услуг IPC и управление ими в определенном объеме. Этот объект представляет собой еще один DAF, называемый Distributed IPC Facility или DIF. DIF позволяет DAP распределять потоки между одним или несколькими DAP, просто предоставляя имена целевых DAP и желаемые параметры QoS, такие как ограничения на потерю данных и задержку, упорядоченную или внеочередную доставку, надежность и т. д. вперед. Например, точки доступа DAP могут не доверять используемому ими DIF и поэтому могут защищать свои данные перед их записью в поток через модуль защиты SDU , например, путем их шифрования. DAP DIF называются процессами IPC или IPCP. Они имеют одну и ту же общую структуру DAP, показанную на рис. 3, а также некоторые конкретные задачи по обеспечению и управлению IPC. Эти задачи, как показано на рисунке 4, можно разделить на три категории в порядке возрастания сложности и убывания частоты: [ нужна ссылка ]
- передача данных,
- контроль передачи данных и
- управление слоями.
Таким образом, в большинстве современных сетевых моделей DAF соответствует уровню приложений, а DIF — уровню, расположенному непосредственно ниже, а три предыдущие категории задач соответствуют подавляющему большинству задач не только сетевых операций, но и управления сетью и даже аутентификации ( с некоторыми изменениями в ответственности, как будет показано ниже). [ нужна ссылка ]
DIF, будучи DAF, в свою очередь сами используют другие базовые DIF, вплоть до DIF физического уровня, управляющего проводами и разъемами. Вот откуда взялась рекурсия RINA. Все слои RINA имеют одинаковую структуру и компоненты и выполняют одни и те же функции; они отличаются только своими областями действия, конфигурациями или политиками (отражая разделение механизма и политики в операционных системах). [3] Как показано на рисунке 2, сети RINA обычно структурированы в виде DIF увеличивающегося объема. На рис. 3 показан пример того, как можно структурировать Интернет с помощью RINA: самый высокий уровень — самый близкий к приложениям, например электронная почта или веб-сайты; нижние уровни объединяют и мультиплексируют трафик более высоких уровней, соответствующий магистралям интернет-провайдера . DIF с несколькими поставщиками (например, общедоступный Интернет или другие) располагаются поверх уровней интернет-провайдера. В этой модели выделяются три типа систем: хосты, содержащие DAP; внутренние маршрутизаторы, внутренние для уровня; и пограничные маршрутизаторы на краях уровня, где пакеты идут вверх или вниз на один уровень.
Короче говоря, RINA сохраняет концепции PDU и SDU, но вместо разделения по функциям оно распределяется по областям. Уровни соответствуют не разным обязанностям, а разным масштабам, и модель специально разработана для применения от одного двухточечного соединения Ethernet до Интернета. Таким образом, RINA представляет собой попытку повторно использовать как можно больше теории и устранить необходимость в разработке специальных протоколов и, таким образом, снизить сложность построения, управления и эксплуатации сети в процессе. [ нужна ссылка ]
Именование, адресация, маршрутизация, мобильность и множественная адресация
[ редактировать ]Как объяснялось выше, IP-адрес является слишком низкоуровневым идентификатором, на котором можно эффективно основывать множественную адресацию и мобильность, а также требует, чтобы таблицы маршрутизации были больше, чем необходимо. Литература RINA следует общей теории Джерри Зальцера об адресации и именовании. По словам Зальцера, необходимо определить четыре элемента: приложения, узлы, точки присоединения и пути. [4] Приложение может работать на одном или нескольких узлах и должно иметь возможность перемещаться с одного узла на другой, не теряя своей идентичности в сети. Узел может быть подключен к паре точек подключения и иметь возможность перемещаться между ними, не теряя своей идентичности в сети. Каталог сопоставляет имя приложения с адресом узла, а маршруты представляют собой последовательности адресов узлов и точек подключения. Эти точки проиллюстрированы на рисунке 4.
Зальцер взял свою модель из операционных систем, но авторы RINA пришли к выводу, что ее нельзя применить к объединенным сетям, которые могут иметь более одного пути между одной и той же парой узлов (не говоря уже о целых сетях). Их решение состоит в том, чтобы моделировать маршруты как последовательности узлов: на каждом прыжке соответствующий узел выбирает наиболее подходящую точку подключения для пересылки пакета следующему узлу. Таким образом, маршрутизация RINA осуществляется в два этапа: сначала рассчитывается маршрут как последовательность адресов узлов, а затем для каждого перехода выбирается соответствующая точка подключения. Это шаги по созданию таблицы пересылки: пересылка по-прежнему выполняется с помощью одного поиска. Более того, последний шаг можно выполнять чаще, чтобы использовать множественную адресацию для балансировки нагрузки. [ нужна ссылка ]
При такой структуре именования изначально поддерживаются мобильность и множественная адресация. [5] если имена имеют тщательно выбранные свойства:
- имена приложений не зависят от местоположения, что позволяет приложению перемещаться;
- адреса узлов зависят от местоположения, но не зависят от маршрута; и
- Точки присоединения по своей природе зависят от маршрута.
Применение этой схемы именования к RINA с его рекурсивными уровнями позволяет сделать вывод, что сопоставление имен приложений с адресами узлов аналогично сопоставлению адресов узлов с точками подключения. Проще говоря, на любом уровне узлы верхнего уровня можно рассматривать как приложения, а узлы нижнего уровня — как точки присоединения.
Разработка протокола
[ редактировать ]Набор интернет-протоколов также обычно требует, чтобы протоколы разрабатывались изолированно, независимо от того, дублируются ли аспекты в других протоколах и, следовательно, могут ли они быть включены в политику. RINA пытается избежать этого, применяя разделение механизма и политики в операционных системах при разработке протоколов. [6] Каждый DIF использует разные политики для обеспечения разных классов качества обслуживания и адаптации к характеристикам либо физического носителя, если DIF низкоуровневый, либо приложений, если DIF высокоуровневый.
RINA использует теорию протокола Delta-T. [7] разработан Ричардом Уотсоном в 1981 году. Исследования Уотсона показывают, что достаточными условиями для надежной передачи является связывание трех таймеров. Delta-T является примером того, как это должно работать: в нем не требуется установка или разрыв соединения. В том же исследовании также отмечается, что TCP уже использует эти таймеры в своей работе, что делает Delta-T сравнительно простым. Исследование Уотсона также предполагает, что синхронизация и распределение портов должны быть отдельными функциями, распределение портов должно быть частью управления уровнями, а синхронизация — частью передачи данных.
Безопасность
[ редактировать ]
Для обеспечения безопасности RINA требует, чтобы каждый DIF/DAF определял политику безопасности, функции которой показаны на рисунке 5. Это позволяет защитить не только приложения, но и сами магистральные сети и коммутационные фабрики. Публичная сеть — это просто особый случай, когда политика безопасности ничего не делает. Это может привести к накладным расходам для небольших сетей, но лучше масштабируется с более крупными сетями, поскольку уровням не нужно координировать свои механизмы безопасности: по оценкам, текущий Интернет требует примерно в 5 раз больше отдельных объектов безопасности, чем RINA. [8] Помимо прочего, политика безопасности также может определять механизм аутентификации; это упраздняет межсетевые экраны и черные списки, поскольку DAP или IPCP, которые не могут присоединиться к DAF или DIF, не могут передавать или получать. DIF также не раскрывают свои IPCP-адреса более высоким уровням, предотвращая широкий класс атак «человек посередине».
Важным фактором также является конструкция самого протокола Delta-T с упором на простоту. Например, поскольку в протоколе нет рукопожатия, у него нет соответствующих управляющих сообщений, которые можно было бы подделать, или состояния, которое можно было бы использовать не по назначению, как, например, при SYN-флуде. Механизм синхронизации также позволяет лучше коррелировать аномальное поведение с попытками вторжения, что значительно упрощает обнаружение атак. [9]
Фон
[ редактировать ]Отправной точкой для радикально новой и другой сетевой архитектуры, такой как RINA, является попытка решить или ответить на следующие проблемы, которые, по-видимому, не имеют практических или бескомпромиссных решений с современными сетевыми архитектурами, особенно с набором интернет-протоколов и его функциональными возможностями. наложение слоев, как показано на рисунке 6:
- Сложность передачи: разделение IP и TCP приводит к неэффективности, при этом обнаружение MTU выполняется для предотвращения фрагментации IP , что является наиболее явным признаком.
- Производительность: TCP сам по себе несет довольно высокие накладные расходы при рукопожатии, что также приводит к уязвимостям, таким как SYN-флуд . Кроме того, TCP полагается на отбрасывание пакетов, чтобы регулировать себя и избегать перегрузок. Это означает, что его контроль перегрузки является чисто реактивным, а не упреждающим или превентивным. Это плохо взаимодействует с большими буферами, что приводит к раздуванию буфера . [10]
- Multihoming : IP-адрес и номер порта слишком низкого уровня, чтобы идентифицировать приложение в двух разных сетях. DNS не решает эту проблему, поскольку имена хостов должны разрешаться в одну комбинацию IP-адреса и номера порта, что делает их псевдонимами, а не идентификаторами. тоже не делает этого LISP , потому что i) он по-прежнему использует локатор, который является IP-адресом, для маршрутизации, и ii) он основан на ложном различении, в котором все объекты в области видимости изначально располагаются по их идентификаторам; [11] кроме того, он также создает собственные проблемы масштабируемости. [12]
- Мобильность: IP-адрес и номер порта также слишком низкоуровневые, чтобы идентифицировать приложение при его перемещении между сетями, что приводит к осложнениям для мобильных устройств, таких как смартфоны. является решением, Несмотря на то, что Mobile IP на самом деле проблема полностью переносится на временный адрес и вводится IP-туннель с сопутствующими сложностями.
- Управление: тот же низкоуровневый характер IP-адреса способствует выделению нескольких адресов или даже диапазонов адресов одному хосту. [13] оказывая давление на распределение и ускоряя истощение. NAT только задерживает исчерпание адресов и потенциально создает еще больше проблем. В то же время функциональное разделение архитектуры набора протоколов Интернета оставляет место только для двух областей, что усложняет разделение администрирования Интернета и требует искусственного понятия автономных систем. У OSPF и IS-IS относительно мало проблем, но они плохо масштабируются, что вынуждает использовать BGP для более крупных сетей и междоменной маршрутизации.
- Безопасность: сама природа пространства IP-адресов приводит к слабой безопасности, поскольку не существует настоящей настраиваемой политики для добавления или удаления IP-адресов, кроме физического предотвращения присоединения. TLS и IPSec предоставляют решения, но с сопутствующими сложностями. Брандмауэры и черные списки уязвимы к перегрузке и, следовательно, не масштабируются. «[...] опыт показал, что сложно повысить безопасность набора протоколов, если он не встроен в архитектуру с самого начала». [14]
Хотя сегодня эти проблемы гораздо более заметны, прецеденты и случаи были почти с самого начала ARPANET , среды, в которой был разработан набор интернет-протоколов:
1972: Многосетевая адресация не поддерживается ARPANET.
[ редактировать ]1972 год, база ВВС Тинкер. [15] требовалось подключение к двум разным IMP для резервирования. Разработчики ARPANET поняли, что они не могут поддерживать эту функцию, поскольку адреса хостов были адресами номера порта IMP, к которому был подключен хост (заимствованные из телефонии). В ARPANET два интерфейса одного и того же хоста имели разные адреса; другими словами, адрес был слишком низкоуровневым, чтобы идентифицировать хост.
1978: TCP отделился от IP
[ редактировать ]Первоначальные версии TCP выполняли функции управления ошибками и потоками (текущий TCP), а также функции ретрансляции и мультиплексирования (IP) в одном и том же протоколе. В 1978 году TCP был отделен от IP, хотя эти два уровня имели одинаковую область применения. К 1987 году сетевое сообщество было хорошо осведомлено о проблемах фрагментации IP и считало ее вредной. [16] Однако то, что TCP и IP взаимозависимы, не воспринималось как симптом.
1981: фундаментальные результаты Уотсона игнорируются
[ редактировать ]Ричард Уотсон в 1981 году представил фундаментальную теорию надежного транспорта. [17] при этом для управления соединением требуются только таймеры, ограниченные небольшим коэффициентом максимального срока службы пакета (MPL). Основываясь на этой теории, Watson et al. разработал протокол Delta-t [7] что позволяет определять состояние соединения просто путем связывания трех таймеров без квитирования связи. С другой стороны, TCP использует как явное подтверждение связи, так и более ограниченное управление состоянием соединения на основе таймера.
1983: Утерян межсетевой уровень
[ редактировать ]
В начале 1972 года была создана Международная сетевая рабочая группа (INWG) для объединения зарождающегося сообщества сетевых исследователей. Одной из первых задач, которые он выполнил, было голосование по международному сетевому транспортному протоколу, который был одобрен в 1976 году. [18] Примечательно, что выбранный вариант, как и все другие кандидаты, имел архитектуру, состоящую из трех уровней расширяющегося объема: канала передачи данных (для работы с различными типами физических носителей), сети (для работы с различными типами сетей) и межсетевого взаимодействия (для работы с различными типами сетей). обрабатывать сеть сетей), каждый уровень со своим собственным адресным пространством. Когда TCP/IP был представлен, он работал на межсетевом уровне поверх протокола Host-IMP при работе через ARPANET. Но когда NCP был отключен, TCP/IP взял на себя роль сети, и межсетевой уровень был потерян. [19] Это объясняет сегодняшнюю необходимость в автономных системах и NAT для разделения и повторного использования диапазонов пространства IP-адресов для облегчения администрирования.
1983: Упущена первая возможность исправить адресацию
[ редактировать ]Необходимость в адресе более высокого уровня, чем IP-адрес, была хорошо понята с середины 1970-х годов. Однако имена приложений не были введены, а DNS была спроектирована и развернута, продолжая использовать известные порты для идентификации приложений. Появление Интернета и HTTP создало потребность в именах приложений, что привело к появлению URL-адресов. Однако URL-адреса привязывают каждый экземпляр приложения к физическому интерфейсу компьютера и конкретному транспортному соединению, поскольку URL-адрес содержит DNS-имя IP-интерфейса и номер TCP-порта, что перекладывает проблемы множественной адресации и мобильности на приложения. [ нужна ссылка ]
1986: Крах перегрузок застал Интернет врасплох
[ редактировать ]Хотя проблема контроля перегрузки в дейтаграммных сетях была известна еще с 1970-х и начала 80-х годов, [20] [21] коллапс перегрузок в 1986 году застал Интернет врасплох. Что еще хуже, принятый контроль перегрузки — Ethernet схема предотвращения перегрузки с некоторыми модификациями — была включена в TCP.
1988: Управление сетью делает шаг назад
[ редактировать ]В 1988 году IAB рекомендовал использовать SNMP в качестве исходного протокола управления сетью для Интернета для последующего перехода к объектно-ориентированному подходу CMIP . [22] SNMP был шагом назад в управлении сетью, оправданным как временная мера, пока были реализованы необходимые более сложные подходы, но переход так и не произошел.
1992: Вторая возможность исправить упущенную адресацию
[ редактировать ]В 1992 году IAB подготовил ряд рекомендаций по решению проблем масштабирования Интернета на основе IPv4 : потребление адресного пространства и взрывной рост информации о маршрутизации. Было предложено три варианта: ввести CIDR для смягчения проблемы; разработать следующую версию IP (IPv7) на основе CLNP ; или продолжить исследования в области именования, адресации и маршрутизации. [23] CLNP был протоколом на основе OSI, который обращался к узлам, а не к интерфейсам, решая старую проблему множественной адресации, восходящую к ARPANET , и позволяя лучше агрегировать информацию о маршрутизации. Был представлен CIDR, но IETF не принял IPv7 на основе CLNP. IAB пересмотрел свое решение, и начался процесс IPng, кульминацией которого стал IPv6 . Одним из правил IPng было не менять семантику IP-адреса, который продолжает называть интерфейс, увековечивая проблему множественной адресации. [13]
Исследовательские проекты
[ редактировать ]С момента публикации книги PNA в 2008 по 2014 год RINA провела большую исследовательскую и опытно-конструкторскую работу. Неофициальная группа, известная как Общество Пузена , названная в честь Луи Пузена , [24] координирует ряд международных усилий.
Исследовательская группа БУ
[ редактировать ]Исследовательскую группу RINA в Бостонском университете возглавляют профессора Абрахам Матта, Джон Дэй и Лу Читкушев. Она получила ряд грантов от Национального научного фонда и EC для продолжения исследования основ RINA и разработки прототипа с открытым исходным кодом. реализация через UDP/IP для Java [25] [26] и поэкспериментируйте с ним поверх инфраструктуры GENI. [27] [28] BU также является членом Общества Пузена и активным участником проектов FP7 IRATI и PRISTINE. В дополнение к этому, BU включил концепции и теорию RINA в свои курсы по компьютерным сетям.
РП7 ЗЛЫЙ
[ редактировать ]IRATI — это проект, финансируемый в рамках FP7 с пятью партнерами: 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+ Open Call ИРИНА
[ редактировать ]IRINA финансировалась открытым конкурсом GÉANT3 + и представляет собой проект с четырьмя партнерами: iMinds, WIT-TSSG, i2CAT и Nextworks. Основная цель IRINA — изучить использование рекурсивной межсетевой архитектуры (RINA) в качестве основы сетевых архитектур следующего поколения NREN и GÉANT. IRINA основывается на прототипе IRATI и будет сравнивать RINA с текущим состоянием сетевых технологий и соответствующей исследуемой архитектурой с чистого листа; провести тематическое исследование того, как можно лучше использовать RINA в сценариях NREN; и продемонстрировать лабораторные испытания исследования. [ нужна ссылка ]
См. также
[ редактировать ]Ссылки
[ редактировать ]- ^ Шаблоны сетевой архитектуры: возвращение к основам , Джон Дэй (2008), Прентис Холл, ISBN 978-0-13-225242-3 [ нужна страница ]
- ^ Дэй, Джон; Матта, Ибрагим; Маттар, Карим (2008). «Сеть — это IPC: руководящий принцип улучшения Интернета». Материалы конференции ACM CoNEXT 2008 г. - CONEXT '08 . стр. 1–6. дои : 10.1145/1544012.1544079 . ISBN 978-1-60558-210-8 . S2CID 3287224 .
- ^ Маттар, Карим; Матта, Ибрагим; Дэй, Джон; Ишакян, Ватче; Гурсун, Гонча (12 июля 2008 г.). Декларативный транспорт: больше не нужно разрабатывать транспортные протоколы, нужно указывать только политики (отчет). hdl : 2144/1707 .
- ^ Дж. Зальцер. Об именовании и привязке сетевых адресатов. RFC 1498 (информационный), август 1993 г.
- ^ Ишакян, Ватче; Акинвуми, Джозеф; Эспозито, Флавио; Матта, Ибрагим (июль 2012 г.). «О поддержке мобильности и множественной адресации в рекурсивных интернет-архитектурах». Компьютерные коммуникации . 35 (13): 1561–1573. дои : 10.1016/j.comcom.2012.04.027 . S2CID 3036132 .
- ^ Хансен, Пер Бринч (апрель 1970 г.). «Ядро мультипрограммной системы». Коммуникации АКМ . 13 (4): 238–241. дои : 10.1145/362258.362278 . S2CID 9414037 .
- ^ Jump up to: а б Уотсон, RW (4 декабря 1981 г.). Спецификация протокола Delta-t: рабочий проект (Отчет). дои : 10.2172/5542785 .
- ^ Смолл, Иеремия (2012). Шаблоны сетевой безопасности: анализ архитектурной сложности в обеспечении безопасности сетей с рекурсивной межсетевой архитектурой (Диссертация). hdl : 2144/17155 .
- ^ Боддапати, Гаутам; Дэй, Джон; Матта, Ибрагим; Читкушев, Лу (2012). «Оценка безопасности чистой архитектуры Интернета». 2012 20-я Международная конференция IEEE по сетевым протоколам (ICNP) . стр. 1–6. дои : 10.1109/ICNP.2012.6459947 . ISBN 978-1-4673-2447-2 . S2CID 7500711 .
- ^ Пузен, Л. (апрель 1981 г.). «Методы, инструменты и наблюдения за управлением потоком в сетях передачи данных с коммутацией пакетов». Транзакции IEEE в области коммуникаций . 29 (4): 413–426. дои : 10.1109/TCOM.1981.1095015 .
- ^ Дэй, Джон (2008). Почему разделение Loc/Id не является ответом (PDF) (Отчет). [ самостоятельно опубликованный источник? ]
- ^ Д. Мейер и Д. Льюис. Архитектурные последствия разделения локатора и идентификатора. https://tools.ietf.org/html/draft-meyer-loc-id-implications-01
- ^ Jump up to: а б Р. Хинден и С. Диринг. «Архитектура IP-адресации версии 6». RFC 4291 (проект стандарта), февраль 2006 г. Обновлено RFC 5952, 6052.
- ^ Д. Кларк, Л. Чапин, В. Серф, Р. Брейден и Р. Хобби. На пути к будущей архитектуре Интернета. RFC 1287 (информационный), декабрь 1991 г.
- ^ Фриц. Э. Фрелих; Аллен Кент (1992). «ARPANET, сеть оборонных данных и Интернет» . Энциклопедия телекоммуникаций Фрелиха/Кента . Том. 5. ЦРК Пресс. п. 82. ИСБН 978-0-8247-2903-5 .
- ^ Кент, Калифорния; Могул, Джей Си (1987). «Фрагментация считается вредной». Материалы семинара ACM «Границы в области компьютерных коммуникационных технологий» . стр. 390–401. дои : 10.1145/55482.55524 . ISBN 978-0-89791-245-7 . S2CID 10042690 .
- ^ Уотсон, Ричард В. (1981). «Механизм на основе таймера в надежном управлении соединениями по транспортному протоколу». Компьютерные сети . 5 (1): 47–56. дои : 10.1016/0376-5075(81)90031-3 .
- ^ Маккензи, Александр (2011). «INWG и концепция Интернета: рассказ очевидца». IEEE Анналы истории вычислений . 33 : 66–71. дои : 10.1109/MAHC.2011.9 . S2CID 206443072 .
- ^ Дэй, Джон (2011). «Как, черт возьми, можно потерять слой!?». 2011 Международная конференция «Сети будущего» . стр. 135–143. дои : 10.1109/НОФ.2011.6126673 . ISBN 978-1-4577-1607-2 . S2CID 15198377 .
- ^ Пузен, Л. (апрель 1981 г.). «Методы, инструменты и наблюдения за управлением потоком в сетях передачи данных с коммутацией пакетов». Транзакции IEEE в области коммуникаций . 29 (4): 413–426. дои : 10.1109/TCOM.1981.1095015 .
- ^ Лам; Лиен (октябрь 1981 г.). «Контроль перегрузки в сетях пакетной связи с помощью ограничений входного буфера - моделирование». Транзакции IEEE на компьютерах . С-30 (10): 733–742. дои : 10.1109/TC.1981.1675692 .
- ^ Совет по архитектуре Интернета. Рекомендации IAB по разработке стандартов управления сетями Интернета. RFC 1052 , апрель 1988 г.
- ^ Совет по архитектуре Интернета. ИП Версия 7**ПРОЕКТ 8**. Проект IAB IPversion7, июль 1992 г.
- ^ Рассел, Эндрю Л.; Шафер, Валери (2014). «В тени ARPANET и Интернета: Луи Пузен и сеть Киклад в 1970-е годы». Технологии и культура . 55 (4): 880–907. дои : 10.1353/tech.2014.0096 . S2CID 143582561 . Проект МУЗА 562835 .
- ^ Эспозито, Флавио; Ван, Юэфэн; Матта, Ибрагим; Дэй, Джон (апрель 2013 г.). Создание экземпляра динамического слоя как услуга (PDF) . Симпозиум USENIX по проектированию и внедрению сетевых систем (NSDI '13).
- ^ Ван, Юэфэн; Матта, Ибрагим; Эспозито, Флавио; Дэй, Джон (28 июля 2014 г.). «Представляем ProtoRINA: прототип для программирования политик рекурсивной сети» . Обзор компьютерных коммуникаций ACM SIGCOMM . 44 (3): 129–131. дои : 10.1145/2656877.2656897 . S2CID 1007699 .
- ^ Ван, Юэфэн; Эспозито, Флавио; Матта, Ибрагим (2013). «Демонстрация RINA на испытательном стенде GENI». Второй семинар по исследованиям и образовательным экспериментам GENI , 2013 г. стр. 93–96. дои : 10.1109/GREE.2013.26 . ISBN 978-0-7695-5003-9 . S2CID 6735043 .
- ^ Ван, Юэфэн; Матта, Ибрагим; Ахтар, Набиль (2014). «Эксперименты с политиками маршрутизации с использованием ProtoRINA поверх GENI». 2014 Третий семинар по исследованиям и образовательным экспериментам GENI . стр. 61–64. дои : 10.1109/GREE.2014.11 . ISBN 978-1-4799-5120-8 . S2CID 16799199 .
- ^ Врейдерс, Сандер; Стаэссенс, Дмитрий; Колле, Дидье; Сальвестрини, Франческо; Граса, Эдуард; Тарзан, Микель; Берджезио, Леонардо (март 2014 г.). «Прототипирование рекурсивной интернет-архитектуры: подход проекта IRATI» . Сеть IEEE . 28 (2): 20–25. дои : 10.1109/MNET.2014.6786609 . hdl : 1854/LU-5730910 . S2CID 7594551 .
- ^ Врейдерс, Сандер; Стаэссенс, Дмитрий; Колле, Дидье; Сальвестрини, Франческо; Маффионе, Винченцо; Берджезио, Леонардо; Тарзан-Лоренте, Микель; Гастон, Бернат; Граса, Эдуард (2014). «Экспериментальная оценка прототипа рекурсивной межсетевой архитектуры». Конференция по глобальным коммуникациям IEEE 2014 . стр. 2017–2022 гг. дои : 10.1109/GLOCOM.2014.7037104 . hdl : 1854/LU-5955523 . ISBN 978-1-4799-3512-3 . S2CID 13462659 .
Внешние ссылки
[ редактировать ]- Веб-сайт Общества Пузена: http://pouzinsociety.org.
- Страница RINA Education на веб-сайте IRATI доступна онлайн по адресу http://irati.eu/education/.
- Репозиторий документов RINA, управляемый TSSG, доступен на сайте http://rina.tssg.org.
- Учебное пособие по RINA на конференции IEEE Globecom 2014 доступно онлайн по адресу http://www.slideshare.net/irati-project/rina-tutorial-ieee-globecom-2014.