stringtranslate.com

Сквозной принцип

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

Суть того, что позже назовут сквозным принципом, содержалась в работах Пола Бэрана и Дональда Дэвиса о сетях с коммутацией пакетов в 1960-х годах. Луи Пузен первым применил сквозную стратегию в сети CYCLADES в 1970-х годах. [1] Этот принцип был впервые четко сформулирован в 1981 году Зальцером , Ридом и Кларком . [2] [a] Значение сквозного принципа постоянно переосмысливается с момента его первоначального формулирования. Кроме того, примечательные формулировки сквозного принципа можно найти еще до основополагающей статьи Зальцера, Рида и Кларка 1981 года. [3]

Основная предпосылка этого принципа заключается в том, что выгоды от добавления определенных функций, требуемых конечным приложением, в подсистему связи быстро уменьшаются. Конечные хосты должны реализовать эти функции для корректности. [b] Реализация конкретной функции влечет за собой некоторые штрафы за ресурсы независимо от того, используется эта функция или нет, а реализация определенной функции в сети добавляет эти штрафы ко всем клиентам, независимо от того, нужна им эта функция или нет.

Концепция

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

Фундаментальная идея, лежащая в основе сквозного принципа, заключается в том, что для двух процессов , взаимодействующих друг с другом через некоторые средства связи, нельзя ожидать, что надежность , полученная с помощью этих средств, будет полностью соответствовать требованиям надежности процессов. В частности, удовлетворение или превышение требований очень высокой надежности процессов связи, разделенных сетями нетривиального размера, обходится дороже, чем получение требуемой степени надежности посредством положительных сквозных подтверждений и повторных передач (называемых PAR или ARQ ). [c] Иными словами, гораздо легче добиться надежности за пределами определенного предела с помощью механизмов на конечных узлах сети, а не на промежуточных узлах , [d] особенно когда последние находятся вне контроля и не подотчетны им. , бывший. [e] Положительные сквозные подтверждения с бесконечными повторами могут обеспечить сколь угодно высокую надежность из любой сети с вероятностью выше нуля успешной передачи данных от одного конца к другому. [ф]

Сквозной принцип не распространяется на функции, выходящие за рамки сквозного контроля и исправления ошибок, а также безопасности. Например, для таких параметров связи, как задержка и пропускная способность , нельзя указать прямые сквозные аргументы . В статье 2001 года Блюменталь и Кларк отмечают: «С самого начала сквозные аргументы вращались вокруг требований, которые могли быть правильно реализованы в конечных точках; если реализация внутри сети является единственным способом выполнить требование , то сквозной аргумент вообще не подходит." [7] : 80 

Сквозной принцип тесно связан с принципом сетевого нейтралитета , а иногда и рассматривается как его прямой предшественник . [8]

История

В 1960-х годах Пол Бэран и Дональд Дэвис в своих разработках сетей, предшествовавших появлению ARPANET , сделали комментарии по поводу надежности, которые отражают суть более позднего сквозного принципа. Цитируя статью Бэрана 1964 года: «Надежность и частота ошибок вторичны. Сеть в любом случае должна строиться с расчетом на серьезные повреждения. Существуют мощные методы устранения ошибок». [9] : 5  Аналогичным образом, Дэвис отмечает о сквозном контроле ошибок: «Считается, что все пользователи сети обеспечивают себе некоторый вид контроля ошибок и что это можно без труда сделать, чтобы выявить недостающие Поэтому с потерей пакетов, если она происходит достаточно редко, можно мириться." [10] : 2,3 

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

Дэвис работал над моделированием дейтаграммных сетей. [11] [12] Основываясь на этой идее, сеть CYCLADES Луи Пузена была первой, которая реализовала дейтаграммы и возложила на хосты ответственность за надежную доставку данных, а не за централизованную службу самой сети. [1] Концепции, реализованные в этой сети, повлияли на архитектуру TCP/IP . [13]

Приложения

АРПАНЕТ

ARPANET продемонстрировала несколько важных аспектов сквозного принципа.

Коммутация пакетов переносит некоторые логические функции на конечные точки связи.
Если основной предпосылкой распределенной сети является коммутация пакетов, то такие функции, как переупорядочение и обнаружение дубликатов, неизбежно должны быть реализованы на логических конечных точках такой сети. Следовательно, ARPANET имела два различных уровня функциональности:
  1. более низкий уровень, связанный с транспортировкой пакетов данных между соседними сетевыми узлами (называемыми процессорами интерфейсных сообщений или IMP), и
  2. более высокий уровень касается различных аспектов сквозной передачи данных. [г]
Дэйв Кларк, один из авторов статьи о сквозных принципах, заключает: «Обнаружение пакетов не является следствием сквозного аргумента. Именно успех пакетов делает сквозное соединение Конечный аргумент актуален». [16] : слайд 31 
Никакой произвольно надежной передачи данных без механизмов сквозного подтверждения и повторной передачи.
ARPANET была разработана для обеспечения надежной передачи данных между любыми двумя конечными точками сети – во многом подобно простому каналу ввода-вывода между компьютером и находящимся поблизости периферийным устройством. [h] Чтобы исправить любые потенциальные сбои передачи пакетов, обычные сообщения ARPANET передавались от одного узла к следующему узлу с положительным подтверждением и схемой повторной передачи; после успешной передачи обслуживания они затем отбрасывались, [i] повторная передача от источника к месту назначения в случае потери пакета не учитывалась. Однако, несмотря на значительные усилия, идеальную надежность, предусмотренную первоначальной спецификацией ARPANET, оказалось невозможно обеспечить – реальность, которая стала все более очевидной, когда ARPANET вышла далеко за рамки своей первоначальной четырехузловой топологии. [j] Таким образом, ARPANET предоставила веские аргументы в пользу присущих сетевым механизмам поэтапной надежности ограничений в стремлении к истинной сквозной надежности. [к]
Компромисс между надежностью, задержкой и пропускной способностью
Стремление к идеальной надежности может нанести ущерб другим важным параметрам передачи данных, в первую очередь задержке и пропускной способности. Это особенно важно для приложений, которые ценят предсказуемую пропускную способность и низкую задержку выше надежности — классическим примером являются интерактивные голосовые приложения в реальном времени. Этот вариант использования был реализован в ARPANET путем предоставления службы необработанных сообщений, которая обходилась без различных мер по обеспечению надежности, чтобы обеспечить более быструю передачу данных с меньшей задержкой на конечные хосты. [л]

TCP/IP

Интернет-протокол (IP) — это служба дейтаграмм без установления соединения и без гарантий доставки . В Интернете IP используется практически для всех коммуникаций. За сквозное подтверждение и повторную передачу отвечает ориентированный на соединение протокол управления передачей (TCP), который находится поверх IP. Функциональное разделение между IP и TCP иллюстрирует правильное применение сквозного принципа при разработке транспортных протоколов.

Передача файла

Примером сквозного принципа является передача файлов с произвольной надежностью между двумя конечными точками в распределенной сети различного, нетривиального размера: [3] Единственный способ, которым две конечные точки могут получить полностью надежную передачу, - это передача и подтверждение контрольной суммы для всего потока данных; в такой ситуации протоколы меньшей контрольной суммы и подтверждения ( ACK /NACK) оправданы только с целью оптимизации производительности — они полезны для подавляющего большинства клиентов, но недостаточны для выполнения требований надежности этого конкретного приложения. Таким образом, тщательную контрольную сумму лучше всего выполнять на конечных точках, а сеть поддерживает относительно низкий уровень сложности и приемлемую производительность для всех клиентов. [3]

Ограничения

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

Пример ограничений сквозного принципа существует в мобильных устройствах, например, с мобильным IPv6 . [24] Перенесение сложностей, связанных с обслуживанием, на конечные точки может вызвать проблемы с мобильными устройствами, если у устройства ненадежный доступ к сетевым каналам. [25]

Дальнейшие проблемы можно увидеть в снижении прозрачности сети из-за добавления трансляции сетевых адресов (NAT), на которую IPv4 опирается для борьбы с исчерпанием адресов . [26] С появлением IPv6 пользователи снова получили уникальные идентификаторы, что обеспечивает полноценное сквозное соединение. Уникальные идентификаторы могут основываться на физическом адресе или могут генерироваться хостом случайным образом. [27]

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

Мультиагентные системы предлагают подходы, основанные на семантике приложений, которые позволяют удобно реализовывать распределенные приложения, не требуя упорядочивания сообщений и гарантий доставки от базовых служб связи. Основная идея этих подходов состоит в том, чтобы смоделировать координацию между конечными точками приложения через информационный протокол [28] и затем реализовать конечные точки (агенты) на основе этого протокола. Информационные протоколы могут применяться к неупорядоченным службам связи с потерями. Промежуточное программное обеспечение, основанное на информационных протоколах и соответствующей модели программирования, абстрагирует прием сообщений от базовой сети и позволяет программистам конечных точек сосредоточиться на бизнес-логике для отправки сообщений.

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

Примечания

  1. ^ Статья 1981 года [2] была опубликована в TOCS ACM в обновленной версии в 1984 году. [3] [4]
  2. ^ Полная цитата из статьи Зальцера, Рида и Кларка гласит: [3] «В системе, включающей средства связи, обычно проводится модульная граница вокруг подсистемы связи и определяется прочный интерфейс между ней и остальной частью системы. Когда при этом становится очевидным, что существует список функций, каждая из которых может быть реализована любым из нескольких способов: подсистемой связи, ее клиентом, совместно или, возможно, дублированно, каждый из которых выполняет свою собственную версию. Рассуждая о таком выборе, требования приложения дают основание для следующего класса аргументов: Полно и корректно рассматриваемая функция может быть реализована только с ведома и с помощью приложения, стоящего на конечных точках системы связи. предоставление этой сомнительной функции как функции самой системы связи невозможно и, более того, приводит к снижению производительности для всех клиентов системы связи (иногда неполная версия функции, предоставляемой системой связи, может быть полезна в качестве производительности). усовершенствование.) Мы называем эту линию рассуждений против реализации функций низкого уровня сквозным аргументом». (с. 278).
  3. ^ Фактически, даже в локальных сетях существует ненулевая вероятность сбоя связи – «требуется внимание к надежности на более высоких уровнях независимо от стратегии управления сетью». [5]
  4. ^ С точки зрения экономики, предельные затраты на дополнительную надежность в сети превышают предельные затраты на получение такой же дополнительной надежности за счет мер на конечных хостах. Экономически эффективный уровень повышения надежности внутри сети зависит от конкретных обстоятельств; однако оно определенно далеко не равно нулю: [3] «Очевидно, что некоторые усилия на более низких уровнях по повышению надежности сети могут оказать существенное влияние на производительность приложений (стр. 281)».
  5. ^ Несмотря на возможность применения договорных средств правовой защиты, ни одна сеть, в которой промежуточные ресурсы распределяются недетерминированным образом, не может гарантировать абсолютную надежность. В лучшем случае он может указывать средние статистические показатели производительности.
  6. ^ Точнее: [6] «THM 1: Правильно функционирующий протокол PAR с бесконечным количеством повторов никогда не перестает доставлять, теряет или дублирует сообщения. COR 1A: Правильно функционирующий протокол PAR с конечным количеством повторов никогда не теряет и не дублирует сообщения, и вероятность неудачной доставки сообщения может быть сделана отправителем сколь угодно малой». (стр. 3).
  7. ^ В соответствии с запросом предложений ARPANET [14] (стр. 47 и далее) в ARPANET концептуально разделены определенные функции. Как отмечает BBN в статье 1977 года: [15] «[В] реализации сети ARPA используется метод разбиения сообщений на пакеты, чтобы минимизировать задержку, наблюдаемую при длительной передаче через множество переходов. Реализация сети ARPA также позволяет передавать несколько сообщений одновременно передаются между данной парой хостов.Однако несколько сообщений и пакеты внутри сообщений могут поступать в IMP назначения не по порядку, а в случае обрыва IMP или линии могут быть дубликаты. Процедура передачи от источника к месту назначения в сети ARPA заключается в изменении порядка пакетов и сообщений в пункте назначения, отбраковке дубликатов и после прибытия всех пакетов сообщения в передаче сообщения на хост назначения и возврате сквозного сообщения. подтверждение завершения (стр. 284)».
  8. ^ Это требование было изложено в запросе предложений ARPANET : «С точки зрения подрядчиков ARPA как пользователей сети, коммуникационная подсеть представляет собой автономный объект, программное и аппаратное обеспечение которого обслуживается сетевым подрядчиком. При проектировании межсоединения Программное обеспечение нам нужно использовать только соглашения ввода-вывода для перемещения данных в подсеть и из нее, а не участвовать в деталях работы подсети иным образом. В частности, проверка ошибок, обнаружение неисправностей, коммутация сообщений, устранение неисправностей, переключение линий и отказы операторов связи и оценка качества связи, необходимые для обеспечения надежной работы сети, являются исключительной ответственностью сетевого подрядчика». [14] : 25 
  9. ^ Отмечает Уолден в статье 1972 года: «Каждый IMP удерживает пакет до тех пор, пока не получит положительное подтверждение от следующего IMP по линии о том, что пакет был правильно получен. Если он получает подтверждение, все в порядке; IMP знает что следующий IMP теперь несет ответственность за пакет, а передающий IMP может отказаться от своей копии пакета». [17] : 11 
  10. ^ К 1973 году BBN признал, что первоначальная цель обеспечения идеальной надежности внутри ARPANET была недостижима: «Первоначально считалось, что единственными компонентами в проекте сети, которые были подвержены ошибкам, были схемы связи и модемные интерфейсы в сети. IMP оснащены контрольной суммой CRC для обнаружения «почти всех» таких ошибок. Остальная часть системы, включая интерфейсы хоста, процессоры IMP, память и интерфейсы, считалась безошибочной. Нам пришлось переоценить эта позиция в свете нашего опыта. [18] : 1  Фактически, как резюмировал Меткалф к 1973 году, «в ARPANET было достаточно битов с ошибками, чтобы заполнить эту квоту [одна необнаруженная битовая ошибка передачи в год] на протяжении веков. [ 19] : 7–28  См. также отчет BBN 2816 [20] : 10 и далее  для получения дополнительной информации об опыте, полученном в первые годы эксплуатации ARPANET.
  11. ^ Между прочим, ARPANET также представляет собой хороший пример компромисса между стоимостью механизмов сквозной надежности и выгодами, которые можно получить таким образом. Обратите внимание, что настоящие механизмы сквозной надежности были бы в то время непомерно дорогими, учитывая, что спецификация предусматривала, что между двумя конечными точками одновременно может передаваться до 8 сообщений на уровне хоста, каждое из которых имеет максимум более 8000 бит. Объем памяти, который потребовался бы для хранения копий всех этих данных для возможной повторной передачи в случае отсутствия подтверждения от IMP назначения, был слишком дорогим, чтобы его можно было окупить. Что касается механизмов сквозной надежности на основе хоста, то они значительно усложнили бы общий протокол уровня хоста ( протокол хост-хост ). Хотя желательность механизмов обеспечения надежности «хост-хост» была сформулирована в RFC  1, после некоторого обсуждения от них отказались (хотя протоколы или приложения более высокого уровня, конечно, могли сами реализовать такие механизмы). Пересчет дебатов того времени см. Bärwolff 2010, [21], стр. 56-58 и примечания к ним, особенно примечания 151 и 163.
  12. ↑ Ранние эксперименты с пакетной голосовой связью датируются 1971 годом, а к 1972 году начались более формальные исследования ARPA по этому вопросу. Как описано в RFC  660 (стр. 2), [22] в 1974 году BBN представила в ARPANET службу необработанных сообщений (Raw Message Interface, RMI), в первую очередь для того, чтобы позволить хостам экспериментировать с пакетными голосовыми приложениями, но также признавая необходимость использование такого средства с учетом возможной межсетевой связи (см. Отчет BBN 2913 [23] на стр. 55 и далее). См. также Bärwolff 2010, [21], стр. 80-84 и многочисленные примечания к нему.

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

  1. ^ Аб Беннетт, Ричард (сентябрь 2009 г.). «Создан для перемен: сквозные аргументы, интернет-инновации и дебаты о сетевом нейтралитете» (PDF) . Фонд информационных технологий и инноваций. стр. 7, 11 . Проверено 11 сентября 2017 г.
  2. ^ Аб Зальцер, Дж. Х., Д. П. Рид и Д. Д. Кларк (1981) «Сквозные аргументы в проектировании систем». В: Материалы Второй Международной конференции по распределенным вычислительным системам. Париж, Франция. 8–10 апреля 1981 г. Компьютерное общество IEEE, стр. 509–512.
  3. ^ abcdef Дж. Х. Зальцер ; Д. П. Рид ; Д. Д. Кларк (1 ноября 1984 г.). «Сквозные аргументы в проектировании систем» (PDF) . Транзакции ACM в компьютерных системах . 2 (4): 277–288. дои : 10.1145/357401.357402. ISSN  0734-2071. S2CID  215746877. Викиданные  Q56503280 . Проверено 5 апреля 2022 г.
  4. ^ Зальцер, Дж. Х. (1980). Сквозные аргументы в проектировании систем. Запрос комментариев № 185, Лаборатория компьютерных наук Массачусетского технологического института, Отдел исследований компьютерных систем. (Онлайн-копия).
  5. ^ Кларк, Д.Д., К.Т. Погран и Д.П. Рид (1978). «Введение в локальные сети». В: Труды IEEE 66.11, стр. 1497–1517.
  6. ^ Саншайн, Калифорния (1975). Проблемы проектирования протоколов связи – формальная корректность. Черновик. Примечание к протоколу INWG 5. IFIP WG 6.1 (INWG). (Копия из CBI).
  7. ^ Блюменталь, М.С. и Д.Д. Кларк (2001). «Переосмысление дизайна Интернета: сквозные аргументы против храброго мира». В: Транзакции ACM по Интернет-технологиям 1.1, стр. 70–109. (Интернет-версия для предварительной публикации).
  8. ↑ Алексис К. Мадригал и Адриенн ЛаФранс (25 апреля 2014 г.). «Сетевой нейтралитет: руководство (и история) оспариваемой идеи». Атлантический океан . Проверено 5 июня 2014 г. Эта идея сетевого нейтралитета... [Лоуренс Лессиг] называл принцип e2e, от начала до конца.
  9. ^ Баран, П. (1964). «О распределенных сетях связи». В: Транзакции IEEE в области коммуникаций 12.1, стр. 1–9.
  10. ^ Дэвис, Д.В., К.А. Бартлетт, Р.А. Скантлбери и П.Т. Уилкинсон (1967). «Цифровая сеть связи для компьютеров, обеспечивающая быстрое реагирование на удаленных терминалах». В: SOSP '67: Материалы первого симпозиума ACM по принципам операционной системы. Гатлинбург, Теннесси. 1–4 октября 1967 г. Нью-Йорк, штат Нью-Йорк: ACM, стр. 2.1–2.17.
  11. ^ К. Хемпстед; В. Уортингтон (2005). Энциклопедия технологий ХХ века. Рутледж . ISBN 9781135455514. Работа по моделированию пакетных сетей также проводилась группой NPL.
  12. ^ Пелки, Джеймс. «6.3 Сеть CYCLADES и Луи Пузен 1971–1972». Предпринимательский капитализм и инновации: история компьютерных коммуникаций 1968–1988. Он провел некоторое моделирование дейтаграммных сетей, хотя и не построил их, и это выглядело технически жизнеспособным.
  13. ^ "Пятый человек Интернета" . Экономист . 13 декабря 2013 года . Проверено 11 сентября 2017 г. В начале 1970-х годов Пузен создал инновационную сеть передачи данных, которая связала места во Франции, Италии и Великобритании. Ее простота и эффективность указали путь к сети, которая могла бы соединить не только десятки машин, но и миллионы из них. Он захватил воображение доктора Серфа и доктора Кана, которые включили аспекты его конструкции в протоколы, которые сейчас поддерживают Интернет.
  14. ^ аб Шеблик, Т.Дж., Д.Б. Докинз и Агентство перспективных исследовательских проектов (1968). Запрос цен на компьютерную сеть ARPA. Запрос котировок. Агентство перспективных исследовательских проектов (ARPA) Министерства обороны (DoD). (Интернет-копия. Архивировано 15 августа 2011 г. в Wayback Machine ).
  15. ^ Маккуиллан, Дж. М. и округ Колумбия Уолден (1977). «Решения по проектированию сети ARPA». В: Компьютерные сети 1.5, стр. 243–289. (Онлайн-копия). На основе Crowther et al. (1975), основанная на отчете BBN 2918, который, в свою очередь, представляет собой выдержку из отчета BBN 2913, оба за 1974 год.
  16. ^ Кларк, Д.Д. (2007). Проектирование приложений и сквозные аргументы. Встреча, проводимая раз в два года в рамках программы будущего коммуникаций MIT. Филадельфия, Пенсильвания. 30–31 мая 2007 г. Слайды презентации. (Онлайн-копия).
  17. ^ Уолден, округ Колумбия (1972). «Процессор интерфейсных сообщений, его алгоритмы и их реализация». В: AFCET Journées d'Etudes: Réseaux de Calculateurs (Семинар AFCET по компьютерным сетям). Париж, Франция. 25–26 мая 1972 г. Французская ассоциация кибернетической экономики и техники (AFCET). (Онлайн-копия).
  18. ^ Маккуиллан, Дж. М. (1973). Программное обеспечение контрольной суммы в IMP и надежности сети. RFC  528. Исторический. НРГ.
  19. ^ Меткалф, RM (1973). «Пакетная связь». Кандидатская диссертация. Кембридж, Массачусетс: Гарвардский университет. Интернет-копия (переработанное издание, опубликовано как Технический отчет 114 Лаборатории компьютерных наук Массачусетского технологического института). В основном написано в MIT Project MAC и Xerox PARC.
  20. ^ Болт, Беранек и Ньюман Inc. (1974). Интерфейсные процессоры сообщений для компьютерной сети Arpa. Отчет BBN 2816. Ежеквартальный технический отчет № 5, с 1 января 1974 г. по 31 марта 1974 г. Bolt, Beranek and Newman Inc. (BBN). (Частная копия, любезно предоставлено BBN).
  21. ^ аб Бервольфф, М. (2010). «Сквозные аргументы в Интернете: принципы, практика и теория». Публикуется самостоятельно в Интернете и через Createspace/Amazon (PDF, исправления и т. д.)
  22. ^ Уолден, округ Колумбия (1974) Некоторые изменения в IMP и интерфейсе IMP/хост. RFC  660. Исторический. НРГ.
  23. ^ ББН (1974). Интерфейсные процессоры сообщений для компьютерной сети Arpa. Отчет BBN 2913. Ежеквартальный технический отчет № 7, с 1 июля 1974 г. по 30 сентября 1974 г. Bolt, Beranek and Newman Inc. (BBN).
  24. ^ Дж. Кемпф; Р. Остейн (март 2004 г.). Возвышение середины и будущее сквозной связи: размышления об эволюции архитектуры Интернета. Сетевая рабочая группа, IETF . дои : 10.17487/RFC3724 . РФК 3724.
  25. ^ «Архитектура протокола CNF». Фокусные проекты . Винлаб, Университет Рутгерса. Архивировано из оригинала 23 июня 2016 года . Проверено 23 мая 2016 г.
  26. ^ Уорд, Марк (14 сентября 2012 г.). «Европа достигает старых ограничений на интернет-адреса» . Новости BBC . Проверено 28 февраля 2017 г.
  27. ^ Стив Диринг и Боб Хинден, сопредседатели рабочей группы IETF по IP следующего поколения (6 ноября 1999 г.). «Заявление о конфиденциальности IPv6-адресов» . Проверено 28 февраля 2017 г.
  28. ^ «Информационно-ориентированное программирование, ориентированное на взаимодействие: BSPL, ослепительно простой язык протоколов» (PDF) . Проверено 24 апреля 2013 г.