Internet Research Task Force (IRTF) J. Hong
Request for Comments: 9236 T. You
Category: Informational ETRI
ISSN: 2070-1721 V. Kafle
NICT
April 2022
Architectural Considerations of Information-Centric Networking (ICN)
Using a Name Resolution Service
Архитектурные вопросы сетей ICN, использующих службы распознавания имён
Аннотация
В этом документе описаны архитектурные соображения, относящиеся к службе распознавания имён (Name Resolution Service или NRS) в ориентированных на информацию сетях (Information-Centric Networking или ICN). Документ разъясняет, как может меняться архитектура ICN при использовании NRS и как это использование влияет на систему маршрутизации ICN. Документ разработан исследовательской группой ICNRG (Information-Centric Networking Research Group).
Статус документа
Этот документ не содержит спецификации стандарта Internet (Standards Track) и публикуется с информационными целями.
Документ является результатом работы IRTF1. IRTF публикует результаты связанных Internet исследований и разработок. Эти результаты могут не подходить для развёртывания. Данный документ представляет согласованное мнение исследовательской группы Information-Centric Networking в составе IRTF. Документы, одобренные для публикации IRSG не являются кандидатами в какие-либо стандарты Internet (см. раздел 2 в RFC 7841).
Информацию о текущем статусе документа, ошибках и способах обратной связи можно найти по ссылке https://www.rfc-editor.org/info/rfc9236.
Авторские права
Copyright (c) 2022. Авторские права принадлежат IETF Trust и лицам, указанным в качестве авторов документа. Все права защищены.
К этому документу применимы права и ограничения, перечисленные в BCP 78 и IETF Trust Legal Provisions и относящиеся к документам IETF2 (http://trustee.ietf.org/license-info), на момент публикации данного документа. Прочтите упомянутые документы внимательно. Фрагменты программного кода, включённые в этот документ, распространяются в соответствии с упрощённой лицензией BSD, как указано в параграфе 4.e документа IETF Trust Legal Provisions, без каких-либо гарантий (как указано в Simplified BSD License).
1. Введение
Информационно-ориентированные сети (ICN) – это подход к развитию инфраструктуры Internet для обеспечения прямого доступа к именованным объектам (Named Data Object или NDO) по их именам. В двух распространённых архитектурах ICN – сети именованных данных (Named Data Networking или NDN) [NDN] и ориентированные на содержимое сети (Content-Centric Networking или CCNx) [CCNx] – имена NDO используются напрямую для маршрутизации запросов на извлечение объектов данных. Такая непосредственная маршрутизация по именам сталкивается с присущей ей по природе проблемами глобально расширяемой системы маршрутизации, обеспечением мобильности создателей (производителей) данных и поддержкой кэширования вне пути. Эти вопросы рассматриваются в разделе 3. Основы. Известны описания решений этих проблем с использованием системы распознавания имён (NRS), а также предложено несколько проектов ICN [Afanasyev] [Zhang2] [Ravindran] [SAIL] [MF] [Bayhan].
В этом документе рассматриваются возможные изменения архитектуры ICN, связанные с внедрением NRS, и влияние этого на систему маршрутизации ICN. Рассмотрены также архитектурные вопросы онтеграции ICN и NRS. Документ включает рассмотрение с точки зрения архитектуры ICN и системы маршрутизации при использовании NRS в сетях ICN. Описание самой системы NRS представлено в отдельном документе [RFC9138], где описаны подходы, функции и устройство NRS.
Этот документ представляет согласованное мнение исследовательской группы ICNRG. Он был тщательно рассмотрен членами группы, активно участвующими в исследованиях и разработке технологии, описанной здесь. Документ не является результатом работы IETF или стандартом.
2. Терминология
Name Resolution Service (NRS) – система распознавания имен
NRS в ICN определяется как служба, обеспечивающая функцию трансляции имён содержимого или объекта данных в некую информацию, такую как маршрутизируемый префикс, локатор, указатель на кэш вне пути или псевдоним имени, более подходящий, чем исходное имя, служащие для пересылки запроса объекта в направлении целевого получателя, хранящего NDO [RFC9138]. NRS, скорее всего, реализуется на основе распределенной базы данных с отображениями. В качестве NRS можно использовать систему доменных имён Domain Name System или DNS). Однако в этом случае необходимо учитывать требования частого обновления NRS в результате создания большого числа новых NDO и смены их местоположения в сети.NRS server – сервер NRS
NRS состоит из распределенных серверов NRS, хранящих в своих базах данных записи об отображениях. Серверы NRS хранят и поддерживают записи отображений, сопоставляющий содержимое или имя объекта с некой информацией, используемой для пересылки запросов содержимого или самого содержимого.NRS resolver – распознаватель NRS
Клиентская функция NRS. Распознаватели NRS отвечают за инициирования запросов на распознавание имён, приводящих в конечном итоге к распознаванию имени целевого объекта данных. Распознаватели NRS могут размещаться на узлах потребителей (клиентов) и/или маршрутизаторах ICN. Распознаватели NRS могут также кэшировать записи отображений, полученные при распознавании, для последующего использования.Name registration – регистрация имён
Для заполнения системы NRS имена содержимого и записи отображений должны регистрироваться в NRS издателем, имеющим права доступа хотя бы к одному полномочному серверу NRS, или создателем содержимого, генерирующим именованные объекты данных. Записи отображения имён на некую информацию, такую как псевдонимы, маршрутизируемые префиксы и локаторы, которая может служить для пересылки запросов содержимого. Издатель или создатель содержимого создаёт запрос на регистрацию в NRS и передаёт его серверу NRS. При регистрации сервер NRS сохраняет (или обновляет) запись с отображением имени в базе данных и подтверждает издателя или создателя об исполнении регистрационного запроса.Name resolution – распознавание имён
Распознавание имён является основной функцией системы NRS. Оно выполняется распознавателями NRS, которые могут быть развёрнуты на узлах потребителей или маршрутизаторах ICN. Распознаватели отвечают за возврат кэшированной записи об отображении (срок действия таких записей ограничен) или передаёт запрос на распознавание в направлении сервера NRS. Сервер NRS выполняет поиск по имени содержимого в своей базе данных и в случае наличия записи извлекает её и возвращает в отклике на запрос распознавателю NRS.NRS node – узел NRS
Серверы NRS называют также узлами NRS, поддерживающими записи об именах. Термины взаимозаменяемы.NRS client – клиент NRS
Узлы, использующие NRS, называют клиентами NRS. Любой узел, инициирующий регистрацию, распознавание или обновление записи для имени, является клиентом NRS (это распознаватели, узлы клиентов ICN, маршрутизаторы ICN, создатели содержимого).3. Основы
Подход к маршрутизации ICN на основе тлишь имён связан с присущими по самой природе проблемы, связанные с созданием глобально расширяемой системы маршрутизации, приспособления к перемещению создателей содержимого и поддержки кэширования вне пути. Для решения этих проблем в литературе и нескольких проектах ICN предложено использовать NRS.
Расширяемость маршрутизации
В ICN, имена приложений, указывающее содержимое, предназначены для использования напрямую при доставке пакетов, поэтому в маршрутизаторах ICN применяются протоколы маршрутизации по именам для создания таблиц маршрутизации и пересылки на основе имён. Как и в случае расширения маршрутизации IP, попадание неагрегируемых префиксов имён в зону без принятого по умолчанию маршрута (Default Route Free Zone или DFZ) маршрутизаторов ICN, вызывает неконтролируемый рост размера таблицы маршрутизации DFZ. Поэтому обеспечение некоторого уровня опосредованности за счёт внедрения NRS в ICN может обеспечить сохранение контроля над размером таблиц маршрутизации. Система NRS транслирует префиксы имён, отсутствующие в таблице пересылки DFZ, в глобально маршрутизируемые префиксы, такие как предложено в NDN [Afanasyev]. Другим решением проблемы расширяемости маршрутизации являются многоуровневые распределенные хэш-таблицы (Multi-level Distributed Hash Table или MDHT), применяемые в NetInf [Dannewitz]. Это обеспечивает anycast-маршрутизацию на основе имён, которая может поддерживать плоское (без иерархии) пространство имён и может быть приспособлена в глобальном масштабе [Dannewitz2].Мобильность создателей содержимого
Если в ICN производитель содержимого перемещается в другую область (домен) имён, использующую иной префикс имён, запрос на созданное им содержимое по исходному его имени должен пересылаться в новое местоположение производителя содержимого. if a producer moves into a different name domain that uses a different name prefix, the request for a content produced by the moving producer with the origin content name must be forwarded to the moving producer’s new location. Поддержка мобильных создателей содержимого особенно усложняется в иерархической системе именования по сравнению с плоской схемой, поскольку требуется обновлять таблицы маршрутизации в более широкой области для отслеживания перемещений создателя содержимого. Поэтому в различных вариантах архитектуры ICN, таких как NetInf [Dannewitz] и MobilityFirst [MF], применяется система NRS для решения проблем при перемещении создателей содержимого.Кэширование вне пути
Кэширование в сети является базовым свойством архитектуры ICN. Подход к кэшированию можно разделить на on-path (на пути) и off-path (вне пути) по местоположению кэша относительно пути пересылки от исходного хранилища содержимого к потребителю. Кэширование вне пути иногда называют репликацией или сохранением содержимого и оно нацелено на репликацию именованных объектов данных (NDO) в разных местах сети для повышения доступности содержимого и/или сокращения задержки при доступе. Кэш может располагать вне пути пересылки содержимого. Нахождение кэшированного вне пути содержимого требуется в системах маршрутизации исключительно на основе имён. Для поддержки доступа к кэшу вне пути местоположение реплик обычно анонсируется в систему маршрутизации по именам или в систему NRS, как описано в [Bayhan].В этом документе рассматриваются вопросы архитектуры и влияния на ICN при использовании NRS для решения проблем, возникающих в ICN с маршрутизацией исключительно по именам.
4. Влияние NRS на ICN
Система NRS не является обязательной частью архитектуры ICN, поскольку в большинстве ICN применяется маршрутизация по именам, не требующая процедуры распознавания имён. Поэтому добавление NRS в архитектуру ICN меняет некоторые аспекты по меньшей мере в части процедур рассылки, задержек и безопасности.
Процедура пересылки
При добавлении NRS в архитектуру ICN процедура распознавания имён включается в базовые архитектурные процедуры маршрутизации и пересылки ICN. Для интеграции NRS в архектуру ICN требуется решить ряд вопросов и указать, например, где, когда и как выполняется распознавание имён.Задержка
Включение NRS в архитектуру ICN вносит дополнительную задержку, связанную с распознаванием, в систему маршрутизации и пересылки. Несмотря на добавление задержки из-за распознавания имён, общая задержка при обслуживании отдельных запросов может быть меньше, если процедура поиска NRS будет находить ближайшие копии расположенных вне пути кэшей. Кроме того, возможен благоприятный компромисс между задержкой на распознавание имён и снижением междоменного трафика за счёт нахождения ближайшей копии содержимого в кэше off-path. Нахождение ближайшего кэша с нужным содержимым может существенно сократить обнаружение содержимого и задержку при доставке.Безопасность
Добавлении в архитектуру ICN системы NRS может расширить фронт атак. Защита самой NRS от распределенных атак на службы (Distributed Denial of Service или DDoS) и подмены или изменения отображений имён может оказаться сложной задачей.5. Вопросы архитектуры ICN для NRS
В этом разделе обсуждаются различные элементы, которые могут рассматриваться с точки зрения архитектуры ICN при развёртывании системы NRS. Эти элементы относятся к регистрации, распознаванию и обновлению записей отображения имён, протоколам и сообщениям, а также интеграции с системой маршрутизации.
5.1. Регистрация, распознавание и обновление записей для имён
При встраивании NRS а архитектуру ICN нужно рассмотреть функции, связанные с регистрацией, распознаванием и обновлением записей отображения имён. Узлы NRS поддерживают записи отображения имён и могут существовать в форме сети, наложенной на маршрутизаторы ICN, т. е. они взаимодействуют между собой через маршрутизаторы ICN. На рисунке 1 показаны узлы и клиенты NRS, связанные через базовую сеть. Узлы NRS следует развёртывать так, чтобы они всегда были доступны на небольшом удалении от клиентов NRS для снижения задержки при запросах регистрации и распознавания от клиентов NRS. Процедуры регистрации и распознавания имён, а также процедуры обновления записей для имён кратко рассматриваются ниже.
+------------+ +------------+
| Узел NRS | | Узел NRS |
+------------+ +------------+
| |
| |
+------------+ | | +------------+
| Клиент NRS |--------------------------------------| Клиент NRS |
+------------+ Базовая сеть +------------+
Рисунок 1. Узлы и клиенты NRS, соединённые через базовую сеть.
Регистрация имён
Распознавание имён
Распознавание имён выполняется клиентом NRS для получения записи об имени от узла NRS путём отправки сообщения с запросом распознавания и получения отклика с записью. В контексте маршрутизации ICN на основе имён распознавание требуется на каждом маршрутизаторе ICN, чья база данных о пересылке (forwarding information base или FIB) не содержит префикса запрошенного имени. Распознавание имён может также выполняться потребителем (особенно многодомным) для пересылки запросов содержимого в более подходящем направлении, чтобы получить содержимое из ближайшего кэша. Если потребитель имеет одно подключение, он может не утруждать себя распознаванием имён, полагаясь на прямую маршрутизацию по именам или распознавание имён восходящим маршрутизатором ICN. В этом случае потребитель создаёт пакет запроса содержимого, включающий имя, и направляет этот пакет ближайшему маршрутизатору ICN. Маршрутизатор ICN просматривает свою таблицу FIB для пересылки запроса содержимого. Если маршрутизатор ICN не может определить доступность запрошенного содержимого, он выполняет распознавание имени для получения записи об отображении имени и добавляет эту запись в свою FIB. Маршрутизатор ICN может выполнять распознавание имени даже до получения запроса содержимого, чтобы использовать запись об отображении в своей таблице FIB.Обновление записей для имён
Обновление записи для имён происходит в случае изменения записи об отображении имени, например, в результате недоступности содержимого в одном или нескольких указанных ранее местах. Обновление записи для имени включает замену или удаление имеющихся записей. Обновление может выполняться явно путём обмена сообщениями об обновлении записей для имён или неявно при возникновении тайм-аута, делающего запись недействительной. Неявное обновление возможно при завершении срока действия каждой записи. Срок действия может обновлять лишь полномочный издатель или узел. Кэшированные записи об отображениях удаляются по истечении срока действия, если не получено указание продлить этот срок от полномочного издателя.5.2. Протоколы и семантика
Для развёртывания системы NRS в локальном или глобальном домене сети ICN нужны новые протоколы и семантика, разработанные и реализованные для поддержки и распознавания имён в разных пространствах имён.
Одним из способов реализации NRS для CCNx является расширение базового формата TLV и семантики [RFC8569] [RFC8609]. Например, запросы и отклики распознавания имён можно реализовать путём определения новых типов полей в сообщениях Interest и Content Object [CCNxNRS]. Используя имеющиеся пакеты CCNx Interest и Content Object для регистрации и распознавания имён, систему NRS можно развернуть с незначительными изменениями протоколов ICN. Однако в таких случаях система NRS может быть неспособной использовать более гибкие и расширяемые схемы.
С другой стороны, система NRS может быть разработана независимо ко своими протоколами и семантикой, подобно NRS, описанной в [Hong]. Например, протокол и сообщения NRS можно реализовать с использованием RESTful API, а NRS может работать как прикладной протокол, независимый от остальных протоколов ICN.
5.3. Система маршрутизации
NRS упрощает маршрутизацию в архитектуре ICN по сравнению с маршрутизацией лишь на основе имён. Это обусловлено возможностью системы маршрутизации обновлять маршрутные таблицы по запросу с помощью записей об именах, получаемых от NRS. Поэтому системе маршрутизации приходиться делать запросы об именах и обрабатывать сведения, такие как префиксы, локаторы, указатели на кэши и псевдонимы имён вне пути, полученные от системы распознавания имён.
Независимо от типа полученных при распознавании имён сведений, коль скоро они имеют форму имён, сообщения с запросами содержимого в системе маршрутизации могут меняться в соответствии с полученными данными. В этом случае имя содержимого, изначально запрошенное потребителем, должно быть задействовано в переформатированном запросе содержимого для проверки целостности связи между именем и запрошенным содержимым. Иными словами, информация, полученная при распознавании имён, применяется для пересылки запроса содержимого, а исходное имя содержимого, запрошенное потребителем, служит для идентификации содержимого. Кроме того, данные от системы распознавания могут служить для построения таблиц маршрутизации.
Сведения, полученные при распознавании имён, могут не иметь фору имени. Например, они могут указывать IP-адрес конечной точки туннеля, чрез которую пересылается запрос содержимого.
6. Заключение
Система NRS не является обязательной частью архитектуры ICN, поскольку в большинстве ICN применяется маршрутизация по именам, не требующая процедуры распознавания имён. Однако такая маршрутизация на основе лишь имён ICN сталкивается с проблемами глобальной расширяемости, мобильности создателей содержимого и поддержки кэширования вне пути. Для решения этих проблем в некоторые проекты ICN была добавлена система NRS. Поэтому в данном документе описаны изменения архитектуры ICN при использовании NRS и влияние этого на систему маршрутизации ICN.
В документе определено несколько терминов, связанных с NRS, и разъяснены некоторые проблемы, присущие маршрутизации ICN на основе лишь имён, такие как расширяемость маршрутизации, мобильность издателей, кэширование вне пути. Документ описывает изменения архитектуры ICN в части процедур, задержек и безопасности при использовании NRS. В соответствии с изменениями архитектуры ICN документ рассматривает архитектурные соображения ICN для NRS, такие как функции, связанные с регистрацией, распознаванием и обновлением записей об отображении имён, протоколами и семантикой для реализации системы NRS, а также вовлечением системы маршрутизации в распознавание имён.
7. Взаимодействие с IANA
Этот документ не требует действий IANA.
8. Вопросы безопасности
При внесении в архитектуру ICN новых компонент, таких как NRS, фронт атак расширяется. Связанные с этим вопросы безопасности рассмотрены ниже.
Безопасность пространств имён
Для развёртывания системы NRS в архитектуре ICN пространства имён ICN, которые могут выделяться уполномоченными элементами, должны защищённо отображаться на издателей содержимого и надёжно обслуживаться теми. Согласно исследованиям ICN [RFC7927], новое пространство имён может также обеспечивать функцию проверки целостности для контроля подлинности издателей. Вопросы аутентификации пространства имён и отображений между разными пространствами имён требуют дополнительного исследования.Безопасность системы NRS
NRS требует развёртывания новых элементов (например, серверов NRS) для создания распределенных и расширяемых систем NRS. Такие элементы, например, серверы NRS, могут подвергаться атакам с использованием ложных запросов от бесчисленных злоумышленников, включая атаки на отказ в обслуживании (DoS и DDoS). Кроме того, клиенты NRS обычно должны в некоторой степени доверять серверам NRS из других доменов сети, а обмен данными в этих случаях должен быть надёжно защищён от вредоносных воздействий. Историю данных распознавания имён требуется хранить и анализировать как в пассивных DNS для выявления возможных инцидентов безопасности и обнаружения вредоносных инфраструктур.Безопасность протокола и сообщений NRS
В системе NRS протоколы для создания, передачи и приёма сообщений NRS, связанных с регистрацией, распознаванием и обновлением записей для имён, следует защищать с помощью подходящих механизмов. Должны обеспечиваться подобающие меры защиты, чтобы инициировать и читать сообщения NRS могли только легитимные узлы. Целостность этих сообщений должна защищаться, а также должны применяться механизмы проверки подлинности, чтобы неуполномоченные стороны не могли манипулировать сообщениями при пересылке через сеть. Следует также предусматривать механизмы шифрования сообщений, чтобы предотвратить утечки данных и нарушения конфиденциальности. Множество проблем, аналогичных известным для сетей IP и DNS, могут оказывать влияние на архитектуру ICN в целом. Подход с минимизацией DNS QNAME может оказаться подходящим для обеспечения безопасности процессов распознавания имён. Следует предусматривать механизмы защиты, такие как проверка подлинности при доступе и т. п. для систем NRS [RFC9138], обеспечивающие безопасность не только NRS но и всей архитектуры ICN.9. Литература
9.1. Нормативные документы
[RFC7927] Kutscher, D., Ed., Eum, S., Pentikousis, K., Psaras, I., Corujo, D., Saucez, D., Schmidt, T., and M. Waehlisch, “Information-Centric Networking (ICN) Research Challenges”, RFC 7927, DOI 10.17487/RFC7927, July 2016, <https://www.rfc-editor.org/info/rfc7927>.
[RFC8569] Mosko, M., Solis, I., and C. Wood, “Content-Centric Networking (CCNx) Semantics”, RFC 8569, DOI 10.17487/RFC8569, July 2019, <https://www.rfc-editor.org/info/rfc8569>.
[RFC8609] Mosko, M., Solis, I., and C. Wood, “Content-Centric Networking (CCNx) Messages in TLV Format”, RFC 8609, DOI 10.17487/RFC8609, July 2019, <https://www.rfc-editor.org/info/rfc8609>.
[RFC9138] Hong, J., You, T., Dong, L., Westphal, C., and B. Ohlman, “Design Considerations for Name Resolution Service in Information-Centric Networking (ICN)”, RFC 9138, DOI 10.17487/RFC9138, December 2021, <https://www.rfc-editor.org/info/rfc9138>.
9.2. Дополнительная литература
[Afanasyev] Afanasyev, A., Yi, C., Wang, L., Zhang, B., and L. Zhang, “SNAMP: Secure namespace mapping to scale NDN forwarding”, 2015 IEEE Conference on Computer Communications Workshops (INFOCOM WKSHPS), DOI 10.1109/INFCOMW.2015.7179398, April 2015, <https://doi.org/10.1109/INFCOMW.2015.7179398>.
[Bayhan] Bayhan, S., Ott, J., Kangasharju, J., Sathiaseelan, A., and J. Crowcroft, “On Content Indexing for Off-Path Caching in Information-Centric Networks”, ACM ICN, DOI 10.1145/2984356.2984372, September 2016, <https://doi.org/10.1145/2984356.2984372>.
[CCNx] “Cicn”, <https://wiki.fd.io/view/Cicn>.
[CCNxNRS] Hong, J., You, T., and Y. Hong, “CCNx Extension for Name Resolution Service”, Work in Progress, Internet-Draft, draft-hong-icnrg-ccnx-nrs-02, 2 July 2018, <https://datatracker.ietf.org/doc/html/draft-hong-icnrg-ccnx-nrs-02>.
[Dannewitz] Dannewitz, C., Kutscher, D., Ohlman, B., Farrell, S., Ahlgren, B., and H. Karl, “Network of Information (NetInf) – An information-centric networking architecture”, Computer Communications vol. 36, issue 7, DOI 10.1016/j.comcom.2013.01.009, April 2013, <https://doi.org/10.1016/j.comcom.2013.01.009>.
[Dannewitz2] Dannewitz, C., D’Ambrosio, M., and V. Vercellone, “Hierarchical DHT-based name resolution for information-centric networks”, Computer Communications vol. 36, issue 7, DOI 10.1016/j.comcom.2013.01.014, April 2013, <https://doi.org/10.1016/j.comcom.2013.01.014>.
[Hong] Hong, J., Chun, W., and H. Jung, “Demonstrating a Scalable Name Resolution System for Information-Centric Networking”, ACM ICN, DOI 10.1145/2810156.2812617, September 2015, <https://doi.org/10.1145/2810156.2812617>.
[MF] Future Internet Architecture (FIA), “MobilityFirst”, <http://mobilityfirst.cs.umass.edu/>.
[NDN] NDN, “Named Data Networking”, September 2010, <https://www.named-data.net>.
[Ravindran] Ravindran, R., Chakraborti, A., and A. Azgin, “Forwarding Label support in CCN Protocol”, Work in Progress, Internet-Draft, draft-ravi-icnrg-ccn-forwarding-label-02, 5 March 2018, <https://datatracker.ietf.org/doc/html/draft-ravi-icnrg-ccn-forwarding-label-02>.
[SAIL] “Scalable and Adaptive Internet Solutions (SAIL)”, <https://www.sail-project.eu/>.
[Zhang2] Zhang, Y., Afanasyev, A., Burke, J., and L. Zhang, “A Survey of Mobility Support in Named Data Networking”, Named Data Networking, Workshop on Name-Oriented Mobility: Architecture, Algorithms and Applications (NOM), April 2016.
Благодарности
Авторы признательны Dave Oran (сопредседатель ICNRG) за очень полезные рецензии и комментарии, которые помогли значительно улучшить этот документ.
Адреса авторов
Jungha Hong ETRI Yuseung-Gu 218 Gajeong-ro Daejeon 34129 Republic of Korea Email: jhong@etri.re.kr Tae-Wan You ETRI Yuseung-Gu 218 Gajeong-ro Daejeon 34129 Republic of Korea Email: twyou@etri.re.kr Ved Kafle NICT Koganei 4-2-1 Nukui-Kitamachi, Tokyo 184-8795 Japan Email: kafle@nict.go.jpПеревод на русский язык
Николай Малых
1Internet Research Task Force – комиссия по исследованиям Internet.
2Internet Engineering Task Force – комиссия по решению инженерных задач Internet.