RFC 8875 Working Group GitHub Administration

Internet Engineering Task Force (IETF)                         A. Cooper
Request for Comments: 8875                                         Cisco
Category: Informational                                       P. Hoffman
ISSN: 2070-1721                                                    ICANN
                                                             August 2020

Working Group GitHub Administration

Администрирование рабочих групп GitHub

PDF

Аннотация

Использование GitHub в рабочих группах (WG) IETF возрастает. Этот документ описывает использование и соглашения для рабочих групп, начинающих пользоваться GitHub. Документ не задает обязательных процессов и не требует изменения работы существующих и будущих групп, которые не пользуются GitHub.

Статус документа

Документ не содержит какой-либо спецификации (Internet Standards Track) и публикуется с информационными целями.

Документ является результатом работы IETF1 и представляет согласованный взгляд сообщества IETF. Документ прошел открытое обсуждение и был одобрен для публикации IESG2. Дополнительную информацию о стандартах Internet можно найти в разделе 2 в RFC 7841.

Информация о текущем статусе документа, найденных ошибках и способах обратной связи доступна по ссылке https://www.rfc-editor.org/info/rfc8875.

Авторские права

Copyright (c) 2020. Авторские права принадлежат IETF Trust и лицам, указанным в качестве авторов документа. Все права защищены.

Документ является субъектом прав и ограничений, указанных в BCP 78 и IETF Trust Legal Provisions и относящихся к документам IETF (http://trustee.ietf.org/license-info), на момент публикации данного документа. Прочтите упомянутые документы внимательно, поскольку в них описаны права и ограничения, относящиеся к данному документу. Фрагменты программного кода, включенные в этот документ, распространяются в соответствии с упрощенной лицензией BSD, как указано в параграфе 4.e документа IETF Trust Legal Provisions, без каких-либо гарантий (как указано в Simplified BSD License).

Оглавление

Исключено в варианте HTML.

1. Введение

Многие рабочие группы и участники процессов IETF используют GitHub разными способами в своей работе над документами IETF. Некоторые люди заинтересованы в использовании GitHub их рабочими группами, но не знают, с чего начать или каким соглашениям следовать. Некоторые рабочие группы используют или планируют применять другие репозитории кода, такие как GitLab и Bitbucket, свойства которых отличаются от GitHub.

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

2. Административный процесс и соглашения

В этом разделе описан административный процесс и соглашения для поддержки создания и управления организацией в GitHub для рабочих групп и хранилищ отдельных документов единообразным способом. Эти действия можно выполнить вручную через секретариат IETF или автоматизированным путем. Примеры автоматизированных решений доступны по ссылкам https://github.com/richsalz/ietf-gh-scripts и https://github.com/martinthomson/i-d-template.

В этом документе вопрос выбора ручного или автоматизированного процесса намеренно не рассматривается, поскольку эти детали будут рассмотрены в IETF Secretariat и Tools Team.

Большинство приведенных ниже соглашений взяты из [RFC8874].

2.1. Создание организации в GitHub

Этот документ указывает, что интерфейс IETF Datatracker позволяет руководителям направлений (area director — AD) или рабочих групп запрашивать создание в GitHub организации для конкретной рабочей группы. В идеале эта возможность должна присутствовать как часть пользовательского интерфейса (UI) создания рабочей группы и ее страницы.

При запросе руководителем направления или рабочей группы создания организации в GitHub инициируется описанный ниже процесс.

  1. Для рабочей группы создается организация GitHub.

  2. Имя организации имеет формат ietf-wg-<wgname>…

  3. Организация инициализируется путем указания IETF Secretariat и руководителей направления в качестве владельцев области данной группы. Если ответственный AD для рабочей группы работает в другом направлении (area), этот AD также будет владельцем.

  4. Организация инициализируется с указанием администраторов, в число которых входят руководитель и секретарь рабочей группы, если они есть.

После создания организации ее URL добавляется на страницу рабочей группы в Datatracker.

Этапы 3 и 4 подразумевают, что идентификаторы владельцев и администраторов известны GitHub. Запись идентификаторов GitHub в Datatracker (см. https://trac.tools.ietf.org/tools/ietfdb/ticket/2548) будет облегчать это. Лицо, запрашивающее создание организации о недоступности идентификаторов GitHub для любого из указанных в качестве владельцев и администраторов.

2.2. Перенос существующих организаций

Если рабочая группа уже имеет организацию, для нее будет полезно указание такого же персонала управления, как описано в параграфе 2.1. Т. е. будет полезно иметь возможность выполнить этапы 3 и 4 из параграфа 2.1, чтобы описанные ниже действия, такие как смена персонала, выполнялись так же, как для созданной заново организации.

2.3. Изменение персонала

При смене персонала для направления или рабочей группы эти изменения будут отражаться в организации GitHub. В Datatracker следует обеспечить возможность отслеживания смены персонала.

2.4. Закрытие рабочей группы

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

2.5. Создание репозитория документов

Имеется много вариантов и конфигураций, в которых может быть полезно использование автоматизации или административных соглашения для репозиториев в рамках организации WG:

  • создание нового репозитория для отдельного чернового документа (по решению руководителя WG);

  • создание нового репозитория для уже принятого рабочей группой проекта (draft);

  • перенос имеющегося репозиория документов в организацию WG;

  • создание нового репозитория с множеством черновых документов.

В качестве этапа процесса этот документ указывает наличие в интерфейсе Datatracker инструмента, позволяющего администратору организации ietf-wg-<wgname> запросить создание нового репозитория для одного документа внутри этой организации. Авторы этого документа будут указаны как участники работы, а репозиторий получит имя чернового документа. В идеале репозиторий должен быть настроен с шаблоном чернового документа, файлами CONTRIBUTING, LICENSE и README, а также с поддержкой непрерывной интеграции в стиле https://github.com/martinthomson/i-d-template. Выполнение этого этапа будет автоматически информировать IETF Secretariat о необходимости создать резерную копию репозитория в соответствии с параграфом 3.2.

2.6. Список связанных репозиториев

В IETF Datatracker следует позволять пользователя добавлять ссылки на репозитории (GitHub и др.) для рабочих групп, документов и страниц пользователей. В данный момент эта функция находится стадии разработки.

3. Рабочий процесс

В [RFC8874] рассмотрены разные варианты использования GitHub рабочими группами и множество решений для реализации этого. В этом разделе указаны базовые административные правила для рабочих групп и описана административная поддержка этих правил.

3.1. Участники работы

Каждый репозиторий, созданный в организации WG, должен как минимум включать в свой файл CONTRIBUTING шаблонный текст https://trustee.ietf.org/license-for-open-source-repositories.html из файла лицензии IETF для репозиториев с открытым кодом. Этот файл может включать и другую информацию (см., например, https://github.com/ietf/repo-files/tree/master/contributing-samples).

Будет полезно указывать в пользовательских данных Datatracker как минимум список учетные данные пользователей GitHub, чтобы упростить отслеживание их вклада в работу.

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

3.2. Резервные копии и архивы содержимого GitHub

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

Информация рабочей группы в GitHub также должна архивироваться с обеспечением публичного доступа к архивам. Этот документ задает использование для решения этих задач протокола Git [git-protocol].

Репозиторий каждой рабочей группы IETF в GitHub будет иметь одноименный репозиторий (зеркало) на сервере, поддерживаемом секретариатом IETF. Каждый час служба будет использовать команду git fetch для всех отслеживаемых репозиториев GitHub. Зеркало репозитория будет обеспечивать доступ для всех.

Отметим, что эта система не делает резервных копий и запросов на вытягивание (pull). Резервные копии следует делать и GitHub API позволяет это. Секретариату IETF следует делать резерные копии зеркала одновременно с созданием резерных копий репозиториев GitHub.

Шаги, описанные в параграфе 2.5, информируют IETF Secretariat о репозиториях, для которых следует создать резервные копии. Руководителям рабочих групп и направлений следует аткже иметь возможность запрашивать у секретариата IETF резервное копирование других репозиториев и связанных рабочих IETF.

4. Вопросы безопасности

Злоумышленник может изменить содержимое Internet-Drafts, особенно на финальных этапах работы и внести незаметные изменения в протоколы, которые могут быть в коненом итоге приняты.

Существует риск потери данных из-за их размещения в одном сервисе. Это учитывается и может быть смягчено мерами, описанными в параграфе 3.2.

5. Взаимодействие с IANA

Этот документ не требует действий IANA.

6. Литература

[git-protocol] Chacon, S. and B. Straub, «Git on the Server — The Protocols», in Pro Git, 2014, <https://git-scm.com/book/en/v2/Git-on-the-Server-The-Protocols#The-Git-Protocol>.

[RFC8874] Thomson, M. and B. Stark, «Working Group GitHub Usage Guidance», RFC 8874, DOI 10.17487/RFC8874, August 2020, <https://www.rfc-editor.org/info/rfc8874>.

Адреса авторов

Alissa Cooper

Cisco

Email: alcoop@cisco.com

Paul Hoffman

ICANN

Email: paul.hoffman@icann.org

Перевод на русский язык

Николай Малых

nmalykh@protocols.ru

1Internet Engineering Task Force.

2Internet Engineering Steering Group.




RFC 8802 The Quality for Service (Q4S) Protocol

Опубликована спецификация протокола Q4S

В документе описан  протокол прикладного уровня для сквозной передачи информации о соответствии QoS с использованием протоколов HTTP и SDP. Протокол Q4S предоставляет механизм согласования и отслеживания задержек, их вариаций, полосы пропускания и потери пакетов, а также для оповещения в случае нарушения одного из согласованных условий.

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

Документ доступен по ссылке.




Ограниченные домены и протоколы Internet

RFC 8799

Limited Domains and Internet Protocols

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

Документ является результатом исследований авторов и прошел обсуждение и консультации в рамках IETF, но не выражает согласованного мнения IETF.

Текст документа доступен по ссылке.




RFC 8799 Limited Domains and Internet Protocols

Independent Submission                                      B. Carpenter
Request for Comments: 8799                             Univ. of Auckland
Category: Informational                                           B. Liu
ISSN: 2070-1721                                      Huawei Technologies
                                                               July 2020

Limited Domains and Internet Protocols

Ограниченные домены и протоколы Internet

PDF

Аннотация

Наблюдается четкая тенденция к изменению поведения и семантики сетей в соответствии с определенными наборами требования, применяемыми в ограниченной части Internet. Правила, принятые по умолчанию параметры, стиль управления сетями и требования безопасности могут существенно отличаться в таких ограниченных областях. В этом документе рассмотрены примеры таких областей х называют также контролируемыми средами), отмечены новые решения и описана связанная с этим таксономия. Кратко рассматривается также стандартизация протоколв для ограниченных доменов. В заключение показана необходимость четкого определения «принадлежности к ограниченным ддоменам» и механизмов, позволяющих узлам безопасно подключаться к домену и находить других членов домена, включая граничные узлы.

Документ является результатом исследований авторов и прошел обсуждение и консультации в рамках IETF, но не выражает согласованного мнения IETF.

Статус документа

Документ не содержит какой-либо спецификации (Internet Standards Track) и публикуется с информационными целями.

Документ не связан с другими RFC и выбран для публикации редактором (RFC Editor) по своему усмотрению без каких-либо заявлений о ценности документа для внедрения или развертывания. Документы, одобренные для публикации RFC Editor, не претендуют на статус стандартов Internet (см. раздел 2 в RFC 7841).

Информация о текущем статусе документа, найденных ошибках и способах обратной связи доступна по ссылке https://www.rfc-editor.org/info/rfc8799.

Авторские права

Copyright (c) 2020. Авторские права принадлежат IETF Trust и лицам, указанным в качестве авторов документа. Все права защищены.

Документ является субъектом прав и ограничений, указанных в BCP 78 и IETF Trust Legal Provisions и относящихся к документам IETF (http://trustee.ietf.org/license-info), на момент публикации данного документа. Прочтите упомянутые документы внимательно, поскольку в них описаны права и ограничения, относящиеся к данному документу.

Оглавление

Исключено в версии HTML.

1. Введение

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

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

Термин «домен» в этом документе не относится к доменным именам DNS, хотя в некоторых случаях ограниченный домен может случайно совпадать с доменом DNS. В частности при конфигурации DNS с расщепленным горизонтом (split horizon) [RFC6950] раздел может проходить по краю ограниченного домена. Недавнее предложение определить периметры внутри DNS [DNS-PERIMETER] также может рассматриваться как механизм ограниченного домена.

Другим термином, который используется в ином контексте, является «контролируемая среда» (controlled environment). Например в [RFC8085] этот термин служит для обозначения границ области действия, в которой может применяться определенная туннельная инкапсуляция. Конкретным примером является инкапсуляция GRE-in-UDP [RFC8086], в которой четко указано: «контролируемая среда предъявляет менее строгие требования, нежели Internet.» Например, трафик без контроля перегрузок может быть приемлемым в контролируемой среде. Эта же фраза может применяться для обозначения области действия протоколов QoS1 [RFC6398]. Это не обязательно тот случай, где протоколы будут отказывать (fail) за пределами контролируемой среды, но они могут работать неоптимально. В этом документе предполагается, что на практике термины «ограниченный домен» и «контролируемая среда» означают одно и то же. Термин «управляемая сеть» (managed network) используется аналогичным образом, например, в [RFC6947]. В контексте защищенной групповой адресации определен термин «домен интерпретации для группы» (group domain of interpretation) [RFC6407].

Еще больше определений типов доменов имеется в документах о маршрутизации, таких как [RFC4397], [RFC4427], [RFC4655]. Понятие ограниченного домена используется весьма широко в разных аспектах технологий Internet.

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

В этом документе рассматриваются и анализируются некоторые последствия отмеченной тенденции и ее возможное влияние на идею универсального взаимодействия в Internet. Во-первых, приведены примеры вариантов и технических решений для ограниченных доменов с основным вниманием к Internet-уровню стека протоколов. В приложении приведена таксономия свойст ограниченных доменов. На этом фоне рассматривается проблема универсальности стандартов Internet в плане области действия и применимости. Отмечено, что некоторые протоколы, хотя и требуют стандартизации и совместимости, должны быть ограниченными в применении. Это предполагает необходимость формализации и обеспечения механизмов защиты для ограниченных доменов и принадлежности к ним. Документ не предлагает устройства таких механизмов, но задает некоторые функциональные требования.

Документ является результатом исследований авторов и прошел процедуры обсуждения и консультаций в IETF, но не является выражением согласованной точки зрения IETF.

2. Текущие отказы в Internet

Сегодня в Internet нет четкой концепции ограниченных доменов. В результате этого некоторые протоколы и функции не работают на определенных путях. Прежний анализ этой проблем концентрировался на потере «прозрачности» Internet [RFC2775], [RFC4924] или ответственности промежуточных узлов за такую потерю [RFC3234], [RFC7663], [RFC8517]. К сожалению проблемы возникают как в прикладных протоколах, так и в фундаментальных механизмах. Например, в Internet нет прозрачности для заголовков расширения IPv6 [RFC7872], а механизм Path MTU Discovery не обеспечивал надежности в течение многих лет [RFC2923], [RFC4821]. Фрагментация IP также ненадежна [FRAG-FRAGILE] и отмечены проблемы согласования TCP MSS [IPV6-USE-MINMTU].

С точки зрения безопасности широкое применение межсетевых экранов на границах сетей, воспринимаемых людьми, но неизвестных протоколам, ведет к различным отказам на прикладных уровнях. Имее реальный опыт и рекомендации, гарантированно при эффективного boundaries that are perceived by humans but unknown to protocols results in arbitrary failure modes as far as the application layer is concerned. There are operational recommendations and practices that effectively guarantee arbitrary failures in realistic scenarios [IPV6-EXT-HEADERS].

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

Исследования ненадежности фрагментации IP [FRAG-FRAGILE] и фильтрации заголовков расширения IPv6 [RFC7872] убедительно показывают потерю прозрачности по меньшей мере для некоторых протокольных элементов и промежуточные устройства играют здесь свою роль. В двух следующих параграфах рассмотрены некоторые среды приложений, требующие свойств протоколов, которые невозможно или не следует поддерживать в масштабе Internet.

3. Примеры требований ограниченного домена

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

  1. Домашняя сеть. Это обычно неуправляемая сеть созданная не специалистом. Сеть должна работать с «устройствами из коробки» от производителя и обеспечивать по умолчанию адекватный уровень защиты. Может потребоваться удаленный доступ. Требования и применимые принципы описаны в [RFC7368].

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

  3. Сеть транспортного средства. Такие сети создаются производителями транспортных средств и могут включать устройства, добавленные владельцем или оператором транспортного средства. К элементам сети предъявляются высокие требования по надежности и производительности, оказывающие влияние на безопасность людей. Для некоторых функций может требоваться удаленный доступ, тогда как к другим он должен быть полностью запрещен. Требуется связь с другими транспортными средствами, дорожной инфраструктурой и внешними источниками данных. Примеры рассмотрены в [IPWAVE-NETWORKING].

  4. Сети SCADA2 и другие сети, работающие в реальном масштабе времени. Эти сети предъявляют конкретные требования, включая жесткие показатели работы в режиме реального времени. Множество примеров таких сетей рассмотрено в [RFC8578]. Одним из примеров является сеть строительных служб, разработанная специально для строительства конкретного здания, но с использованием стандартных компонентов. В любой момент может потребоваться добавление в сеть новых устройств. Отдельные части могут предъявлять высоркие требования к надежности, связанные с безопасностью людей. Может требоваться удаленный доступ к некоторым функциям при полном запрете доступа к другим. Крайним случаяем является сеть, используемая для приложений виртуальной или дополненной реальности с высокими требованиями к задержкам.

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

  6. Сети IoT3. Этот термин очень гибок и охватывает многие инновационные типы сетей, включая специализированные (ad hoc) сети, формируемые спонтанно, и некоторые приложения 5G, представляется разумным считать, что пограничные сети IoT будут предъявлять специальные требования и использовать протоколы, которые полезны лишь в конкретном домене и из соображений безопасности не могут применяться для работы через Internet.

  7. Сети устройств с ограниченными возможностями. Важным подклассом сетей IoT являются сети устройств с ограниченными возможностями [RFC7228], в которых узлы ограничены по энергопотреблению и пропускной способности, что требует использования очень экономных протоколов.

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

  9. Традиционные сети предприятий и кампусов могут иметь значительную протяженность и включать множество сайтов со своим подключением к Internet. Интересно, что в рамках IETF такой вариант давно существующих сетей не анализировался в общем виде, за исключениям случаев, связанных с развертыванием IPv6 (например, [RFC7381]).

  10. Неприемлемые стандарты. В корпоративных сетях могут возникать ситуации, когда решение, подходящее для Internet может приводить к локальным отказам или быть слишком сложным. Примером могут быть сложности, вызванные такими механизмами как ICE4 [RFC8445], не оправданными внутри сети. Кроме того, ICE в некоторых случаях невозможно использовать по причине неизвестности адресов-кандидатов до организации соединения, в результате чего может требоваться иное локальное решение [RFC6947].

  11. Управляемые распределенные сети сервис-провайдеров и предприятий, такие как соединения «точка-точка» на уровне L2 (Ethernet и т. п.) с использованием псевдопроводов, многоточечные L2 Ethernet VPNs, использующие услуги VPLS5, или Ethernet VPN (EVPN) и L3 IP VPN. Обычно они характеризуются соглашениями об уровне обслуживания я части доступности, потери пакетов и, возможно, групповых служб. Это отличается от предыдущего случая тем, что используются такие сети в основном на инфраструктурах MPLS, требования к которым четко заданы IETF.

  12. ЦОД и хостинг. Высокие требования к производительности, безопасности и приватности. Большое число независимых сетей «арендаторов», наложенных на общую инфраструктуру.

  13. Сети CDN6, состоящие из распределенных ЦОД и путей между ними, простирающихся на тысячи километров. Множество подключений к Internet.

  14. Крупные сети Web. Небольшой класс общеизвестных сетей, объединяющих в себе аспекты распределенных корпоративных сетей, ЦОД и CDN. Они имеют свои транснациональные сети в обход традиционных опереторов. Кодобно CDN, они имеют множество соединений с Internet, обычно предлагая свои услуги в каждой стране.

Еще три аспекта, хоть и не привязаны к конкретным типам сетей, сильно зависят от концепции ограниченных доменов.

  1. Многие из перечисленных типов сетей могут включать соединения через Internet на основе методов VPN7. Поэтому можно утверждать, что ограниченные домены могут перекрываться между собой с использованием методов виртуализации. Как отмечено выше, для использования в конкретном домене могут быть приспособлены те или иные методы туннелирования и инкапсуляции.

  2. В сетях на основе намерений (intent-based) домены настраиваются и управляются в соответствии с абстрактной политикой, называемой намерением (Intent), для обеспечения подобающей работы сети [IBN-CONCEPTS]. Какие бы технологии не использовались для поддержки этого, они будут применяться в границах домена, даже если поддерживаемые доменом службы доступны глобально.

  3. «Нарезка» сетей (network slicing) является формой виртуальной сети, состоящей из управляемого набора ресурсов, взятого из более крупной сети [ENHANCED-VPN]. Предполагается, что этот подход станет значимым в сетях 5G [USER-PLANE-PROTOCOL]. Какие бы технологии не применялись для «нарезки», потребуется четкое определение границ каждого «среза» в более крупном домене.

Хотя желание использовать общие решения и стандарты очевидно, это становится все трудней обеспечить с учетом широко меняющихся требований, перечисленных выше. Тем не менее, имеется тенденция при создании новых протоколов и расширений задаваться вопросом, как это будет работать через открытую сеть Internet. Здесь предлагается несколько иной подход — считать некоторые протоколы и расширения не предназначенными для работы через Internet. Требования и семантика таких протоколов имеют существенные ограничения (в отмеченном смысле).

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

Тем не менее, разнообразие ограниченных доменов с особыми характеристиками вероятно приведет к появлению конкретных стандартов (включая ad hoc) для различных типов доменов. Будут предприняты попытки охватить каждый сектор рынка, но рынок потребует стандартизации решений в каждом секторе. Кроме того, будут приняты решения, которые фактически будут работать лишь в ограниченных доменах. История RSVP [RFC2205] показывает, что стандарт, созданный для работы через открытую сеть Internet, на деле этого не может. В общем случае больше нельзя считать, что протоколы, созданные по классическим правилам Internet, смогут реально работать во всей сети. Однако «открытая сеть Internet» должна оставаться универсальным средством соединения. Устранение этого конфликта является сложной задачей.

4. Примеры ограниченных доменов

В этом разделе перечислены примеры ограниченных доменов, которые были предложены или определены. Здесь намеренно не включены разные технологические решения L2, которые по определению применяются в разных доменах. Тем не менее, следует отметить, что с учетом недавних разработок, таких как TRILL8 [RFC6325] и [SPB9], домены L2 могут быть очень большими.

  1. Дифференцированные услуги. Механизм [RFC2474] позволяет сети назначать 6-битовые значения кодов обслуживания DSCP10 с локальной значимостью каждому пакету IP. Имеются рекомендации по выделению кодов для управления поведением очередей на этапе пересылки, однако в целом эти коды предназначены для классификации, кондиционирования и (пере)маркировки пакетов на границах домена (если нет междоменного соглашения о маркировке пакетов).

  2. Интегрированные услуги. Хотя этот механизм и не является неотъемлемой частью RSVP [RFC2205], многие годы эксплуатации показали, что интегрированные услуги можно эффективно реализовать лишь в ограниченном домене с подобающей настройкой оборудования и ресурсов.

  3. Виртуализация сетевых функций. Как отмечено в [RFC8568], эта базовая концепция является темой продожающихся исследований систем, где виртуализованные сетевые функции организованы как часть распределенной системы. Такая организация функций с неизбежностью ведет к использованию того или иного домена с ограничениями, несмотря на то, что междоменная организация (оркестровки) тоже является предметом исследований.

  4. Цепочки сервисных функций (SFC11). Этот метод [RFC7665] предполагает, что сетевые службы представляют собой цепочки отдельных сервисных функций внутри конкретного домена SFC (например, 5G). Как отмечено в RFC: «Возможно потребуется применять определенные функции на границе домена SFC, например, для предотвращения утечки информации SFC». Для инкапсуляции пакетов, проходящих через цепочку функций, применяются заголовки NSH12 [RFC8300]: «Предполагаемая область действия NSH — один домен провайдера».

  5. Квитанции FAST13 сопровождают пакет, позволяя тому проходить через сеть или запрашвать конкретную сетевыую услугу [FAST]. «Билеты» имеют значение лишь в конкретном домене.

  6. Наложенные виртуальные сети ЦОД. Общим требованием ЦОД, где размещается оборудование множества арендаторов (клиентов), является предоставление каждому клиенту защищенной частной сети, но при этом сети всех клиентов должны работать на основе общей физической инфраструктуры. В [RFC8151] описаны различные варианты решений, а также рассмотрены разрабатываемые спецификации. Включены также ситуации, где сеть арендатора физически разделена между несколькими ЦОД, но должна представляться пользователям как единый защищенный домен.

  7. Сегментная маршрутизация. Этот метод «ведет пакет через упорядоченный список инструкций, называемых сегментами» [RFC8402]. Семантика инструкция является локаотной для домена сегментной маршрутизации или даже для одного узла. Технически эти сегменты или инструкции представляются как метки MPLS или адреса IPv6, обеспечивающие их сементическую интерпретацию в домене.

  8. Автономные сети. Как указано в [REF-MODEL], автономная сеть является также доменом безопасности, в котором агенты автономных служб используют автономную плоскость (уровень) управления [ACP]. These agents manage technical objectives, which may be locally defined, subject to domain-wide policy. Thus, the domain boundary is important for both security and protocol purposes.

  9. Домовые сети. Как показано в [RFC7368], домашние сети имеют свои требования к протоколам, отличающиеся от требований корпоративных сетей и Internet в целом. Это включает протокол HNCP14 [RFC7788], а также решение [HOMENET-NAMING] для именования и обнаружения.

  10. Творческое использование свойств IPv6. Протокол IPv6 обеспечивает большую по сравнению с IPv4 гибкость.

    • Метки потоков, например, [RFC6294].

    • Заголовки расширений, например, для сегментной маршрутизации [RFC8754] или маркировки OAM15 [IPV6-ALT-MARK].

    • Значимые биты адресов, например, [EMBEDDED-SEMANTICS]. Сегментная маршрутизация использует адреса IPv6 в качестве идентификаторов сегментов с локальной значимостью [RFC8402].

    • При использовании сегментной маршрутизации для программирования сети [SRV6-NETWORK] заголовки расширений IPv6 могут применяться взамен более сложной локальной функциональности.

    Заголовки расширений особенно интересны, поскольку их наличие является основной «точкой продажи» IPv6, однако новые заголовки практически невозможно размернуть в масштабе Internet [RFC7045] [RFC7872]. Следует отметить, что фильтрация заголовков считается важной проблемой безопасности [IPV6-EXT-HEADERS]. Прозводители и операторы стремятся гибко определять заголовки расширения для использования в ограниченных или специализированных доменах, например, [IPV6-SRH], [BIGIP], [APP-AWARE]. Предусмотрены также локально значимые поэтапные (hop-by-hop) опции, понятные маршрутизаторам внутри домена, но не внешним устройствам (например, [IN-SITU-OAM]).

  11. Детерминированные сети (DetNet). Архитектура [RFC8655] и инкапсуляция [DETNET-DATA-PLANE] нацелены на поддержку потоков с экстемально низкими потерями данных и ограниченной задержкой, но лишь в части сети, понимающей DetNet. Как и для дифференцированных услуг концепция является фундаментальной.

  12. Домены обеспечения (PvD). Архитектура [RFC7556] позволяет хостам, подключенным к нескольким сетям, явно узнавать детали услуг, предоставляемых каждой сетью.

  13. Область действия адресов. Отметим, что некоторые адреса, в частности IPv6, имеют явно ограниченную область действия. Например локальные для канала адреса (link-local) действуют лишь на одном физическом соединении [RFC4291], а уникальные локальные адреса [RFC4193] ограничены слабо определенной областью локального сайта. Были определены также локальные для сайта адреса (site-local), но их сочли устаревшими по причине нечеткости концепции сайта [RFC3879]. Групповые адреса также явно ограничены в области действия [RFC4291].

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

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

5. Область действия протоколов в ограниченных доменах

Одним из следствий развертывания доменов с ограничениями в Internet является разработка, расширение и настройка некоторых протоколов так, что они будут корректно работать лишь между конечными системами таких доменов. Это в той или иной степени поощряется некоторыми имеющимися стандартами и назначением кодов для экспериментального или локального применения. В любом случае предотвратить эти процессы не удастся. Кроме того, поддержка таких направлений, как цепочки сервисных функций, сегментная маршрутизация детерминированные сети, в рамках IETF фактически поощряет развертывание ограниченных доменов. Если же IoT16 станет реальностью, к Internet будут подключены миллионы граничных сетей, содержащих совершенно новые типы устройств, и каждая из таких сетей будет ограниченным доменом.

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

  1. Если домен разделен на две части, связанные через Internet непосредственно на уровне IP (т. е. без туннельной инкапсуляции), протокол ограниченного домена независимо от своей специальной природы, если он использует стандартные форматы IP и не блокируется межсетевыми экранами. Простым примером является использование специального номера порта для протокола не-IETF.

    Такой протокол можно считать междоменным, поскольку сеть Internet прозрачна для него, даже если протокол имеет смысл лишь в ограниченном домене. Это не вносит ничего нового в архитектуру Internet.

  2. Есди протокол ограниченного домена не соответствует стандартным форматам IP (например, включает нестандартный заголовок расширения IPv6), он не сможет работать между парой доменов, соединенных напрямую через Internet на уровне IP.

    Такие протоколы можно называть внутридоменными и сеть Internet «непрозрачна» для них.

  3. Если для протокола ограниченного домена явно указана непригодность за пределами домена, ни один из вариантов A и B не применим. Единственным решением будет создание общего виртуального домена. Например, можно использовать туннельную инкапсуляцию для создания общего виртуального домена. На границе домена все пакеты такого протокола должны отбрасываться.

  4. Если протокол ограниченного домена имеет специфические для доменов варианты, реализации в разных доменах могут оказаться несовместимыми при соединении доменов по варианту C. Протокол при таком соединении может приводить к непредсказуемым отказам. Простым примером является любой протокол, использующий выделенный для эеспериментов номер порта. Связанные с этим вопросы рассматриваются в [RFC5704], включая достаточно сложный вариант использования Transport MPLS.

В качестве распространенного примера рассмотрим дифференцированные услуги [RFC2474]. Пакет с любым значением в 6 битах поля DSCP17 имеет корректный формат для варианта A. Однако семантика кодов DSCP имеет локальную значимость, поэтому применим также вариант D. Фактически дифференцированные услуги могут поддерживаться через границы доменов лишь при наличии соответствующего соглашения между операторами. В иных случаях для полноценного взаимодействия нужны специальные функции на шлюзе. Более подробно это рассмотрено в [RFC2474] и [RFC8100].

В качестве провокационного примера рассмотрим предложенное в [IPV6-SRH] смягчение ограничений [RFC8200], позволяющее вставлять заголовки расширения в пакеты IPv6 «на лету». Если это делать так, чтобы измененные пакеты никогда не покидали ограниченный домен, применим вариант C. Если семантика вставляемых заголовков определена локально, применим также вариант D. В обоих случаях работа Internet за пределами ограниченного домена не нарушается. Однако внутри домена узлы должны понимать вариант протокола. Если вариант не стандартизован в виде формальной версии в учетом всех обстоятельств, предусмотренных [RFC6709], все узлы должны быть нестандартными для понимания варианта протокола. Для случая вставки заголовков расширения IPv6 это означает несоответствие [RFC8200] внутри домена даже при полном соответствии стандарту самих вставляемых заголовков. Помимо проблемы формального соответствия такие отклонения могут значительно усложнять отладку. Возможное практическое влияние такой вставки заголовков рассмотрено в [IN-FLIGHT-IPV6].

Отмеченное в разделе 4 (п. 5) предложение FAST также дает интересный пример. Семантика квитанций FAST [FAST] имеет ограниченную область действия. Однако они разработаны так, что в принципе могут передаваться через Internet в форме стандартизованных опций IPv6 hop-by-hop или даже в заголовках расширения IPv4 [IPV4-EXT-HEADERS]. Вопрос надежности использования таких вариантов в открытой сети Internet остается неясным [IPV6-EXT-HEADERS].

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

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

6. Функциональные требования ограниченных доменов

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

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

Во-первых, создание топологического плана (карты) данного домена (физического или виртуального) позволяет четко определить границу домена. Однако сама по себе граница не имеет технического значения. На деле важна принадлежность узлов к домену и факт размещения узлов на границе между доменом и остальной частью Internet. Таким образом, важна идентификация не самой границы, а узлов, имеющих интерфейсы внутрь домена и наружу. Внутри домена передающему узлу нужно понимать, расположен адресат внутри или вне домена, а принимающим — получен пакет от внешнего или внутреннего узла. Граничным узлам следует различать свои внутренние и внешние интерфейсы (как физические, так и виртуальные).

Чтобы подчеркнуть важность идентификации границы домена, отметим проблему детерминированных сетей [RFC8557], где «все еще недостаточно четко определены границы домена, в котором может быть оганизован детерминированный путь». Это замечание можно обобщить.

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

  1. Идентификация домена. Домен должен иметь уникальный проверяемый идентификатор, фактически это будет открытый ключ домена. Без этого невозможно обеспечить безопасность работы домена и принадлежности к нему. Владелец соответствующего секретного ключа будет привязкой доверия для домена.

  2. Вложенность. Домены могут быть вложенными (см. приведенный выше пример «нарезки сетей»).

  3. Наложение. Узлы и каналы могут входить в несколько доменов (см. упомянутый выше случай PvD).

  4. Выбор для узла. Узел должен иметь возможность определить домены, к которым он может присоединиться и применяемые для этого интерфейсы.

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

  6. Отзыв. Узел должен иметь возможность отозвать регистрацию в данном домене.

  7. Динамическое членство. Узлам может предоставляться возможность временного выхода (отключения) из домена (регистрация сохраняется, но принадлежность к домену прекращается).

  8. Роль, предполагающее предоставление прав выполнять некие действия. Узел должен иметь проверяемую роль. В простейшем случае узлы делятся по ролям на внутренние и граничные. В граничных узлах роли интерфейсов могут различаться (например, внешние и внутренние).

  9. Проверка партнеров. Узел должен иметь возможность проверки принадлежности своего партнера к домену.

  10. Проверка роли. Узлу слудует обеспечивать возможность проверки роли партнера. В частности, следует обеспечивать возможность нахождения граничных узлов (с интерфейсом в Internet).

  11. Данные домена. В домене с требованиями по управления узлам должна обеспечиваться возможность получить правила и/или конфигурационные данные домена. Это включает, например, пакеты, которые не должны покидать домен.

Эти требования могут стать основой для последующего анализа и разработки решения.

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

7. Вопросы безопасности

Как отмечено выше, протоколы, предназначенные для ограниченного применения, могут попадать в открытую часть Internet, поэтому ограниченности применния протокола не является основанием для пренебрежения вопросами защиты. Фактически, ограниченное применение протокола усложняет разработку средств его защиты.

Зачастую периметр домена с ограничениями является также границей защиты. В частности, периметр является границей доверия и полномочий доступа к определенным возможностям. Например, сегментная маршрутизация [RFC8402] явно использует для концепцию «домена доверия». Внутри периметра протоколы или свойства ограниченного домена могут быть полезны, но за пределами домена они могут становиться ненужными или вредными.

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

Модель безопасности для протокола с ограниченной областью применения должна поддерживать границу и, в частности, смену модели доверия на этой границе. Обычно для этого требуются «свидетельства» (credentials) подписанные уполномоченным органом домена.

8. Взаимодействие с IANA

Этот документ не требует действий со стороны IANA.

9. Литература

[ACP] Eckert, T., Behringer, M., and S. Bjarnason, «An Autonomic Control Plane (ACP)», Work in Progress, Internet-Draft, draft-ietf-anima-autonomic-control-plane-27, 2 July 2020, <https://tools.ietf.org/html/draft-ietf-anima-autonomic-control-plane-27>.

[APP-AWARE] Li, Z., Peng, S., Li, C., Xie, C., Voyer, D., Li, X., Liu, P., Liu, C., and K. Ebisawa, «Application-aware IPv6 Networking (APN6) Encapsulation», Work in Progress, Internet-Draft, draft-li-6man-app-aware-ipv6-network-02, 2 July 2020, <https://tools.ietf.org/html/draft-li-6man-app-aware-ipv6-network-02>.

[BIGIP] Li, R., «HUAWEI — Big IP Initiative», 2018, <https://www.iaria.org/announcements/HuaweiBigIP.pdf>.

[DETNET-DATA-PLANE] Varga, B., Farkas, J., Berger, L., Malis, A., and S. Bryant, «DetNet Data Plane Framework», Work in Progress, Internet-Draft, draft-ietf-detnet-data-plane-framework-06, 6 May 2020, <https://tools.ietf.org/html/draft-ietf-detnet-data-plane-framework-06>.

[DNS-PERIMETER] Crocker, D. and T. Adams, «DNS Perimeter Overlay», Work in Progress, Internet-Draft, draft-dcrocker-dns-perimeter-01, 11 June 2019, <https://tools.ietf.org/html/draft-dcrocker-dns-perimeter-01>.

[EMBEDDED-SEMANTICS] Jiang, S., Qiong, Q., Farrer, I., Bo, Y., and T. Yang, «Analysis of Semantic Embedded IPv6 Address Schemas», Work in Progress, Internet-Draft, draft-jiang-semantic-prefix-06, 15 July 2013, <https://tools.ietf.org/html/draft-jiang-semantic-prefix-06>.

[ENHANCED-VPN] Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, «A Framework for Enhanced Virtual Private Networks (VPN+) Service», Work in Progress, Internet-Draft, draft-ietf-teas-enhanced-vpn-06, 13 July 2020, <https://tools.ietf.org/html/draft-ietf-teas-enhanced-vpn-06>.

[FAST] Herbert, T., «Firewall and Service Tickets», Work in Progress, Internet-Draft, draft-herbert-fast-04, 10 April 2019, <https://tools.ietf.org/html/draft-herbert-fast-04>.

[FRAG-FRAGILE] Bonica, R., Baker, F., Huston, G., Hinden, R., Troan, O., and F. Gont, «IP Fragmentation Considered Fragile», Work in Progress, Internet-Draft, draft-ietf-intarea-frag-fragile-17, 30 September 2019, <https://tools.ietf.org/html/draft-ietf-intarea-frag-fragile-17>.

[HOMENET-NAMING] Lemon, T., Migault, D., and S. Cheshire, «Homenet Naming and Service Discovery Architecture», Work in Progress, Internet-Draft, draft-ietf-homenet-simple-naming-03, 23 October 2018, <https://tools.ietf.org/html/draft-ietf-homenet-simple-naming-03>.

[IBN-CONCEPTS] Clemm, A., Ciavaglia, L., Granville, L., and J. Tantsura, «Intent-Based Networking — Concepts and Definitions», Work in Progress, Internet-Draft, draft-irtf-nmrg-ibn-concepts-definitions-01, 9 March 2020, <https://tools.ietf.org/html/draft-irtf-nmrg-ibn-concepts-definitions-01>.

[IN-FLIGHT-IPV6] Smith, M., Kottapalli, N., Bonica, R., Gont, F., and T. Herbert, «In-Flight IPv6 Extension Header Insertion Considered Harmful», Work in Progress, Internet-Draft, draft-smith-6man-in-flight-eh-insertion-harmful-02, 30 May 2020, <https://tools.ietf.org/html/draft-smith-6man-in-flight-eh-insertion-harmful-02>.

[IN-SITU-OAM] Bhandari, S., Brockners, F., Pignataro, C., Gredler, H., Leddy, J., Youell, S., Mizrahi, T., Kfir, A., Gafni, B., Lapukhov, P., Spiegel, M., Krishnan, S., and R. Asati, «In-situ OAM IPv6 Options», Work in Progress, Internet-Draft, draft-ietf-ippm-ioam-ipv6-options-02, 13 July 2020, <https://tools.ietf.org/html/draft-ietf-ippm-ioam-ipv6-options-02>.

[IPV4-EXT-HEADERS] Herbert, T., «IPv4 Extension Headers and Flow Label», Work in Progress, Internet-Draft, draft-herbert-ipv4-eh-01, 2 May 2019, <https://tools.ietf.org/html/draft-herbert-ipv4-eh-01>.

[IPV6-ALT-MARK] Fioccola, G., Zhou, T., Cociglio, M., Qin, F., and R. Pang, «IPv6 Application of the Alternate Marking Method», Work in Progress, Internet-Draft, draft-ietf-6man-ipv6-alt-mark-01, 22 June 2020, <https://tools.ietf.org/html/draft-ietf-6man-ipv6-alt-mark-01>.

[IPV6-EXT-HEADERS] Gont, F. and W. LIU, «Recommendations on the Filtering of IPv6 Packets Containing IPv6 Extension Headers», Work in Progress, Internet-Draft, draft-ietf-opsec-ipv6-eh-filtering-06, 2 July 2018, <https://tools.ietf.org/html/draft-ietf-opsec-ipv6-eh-filtering-06>.

[IPV6-SRH] Voyer, D., Filsfils, C., Dukes, D., Matsushima, S., Leddy, J., Li, Z., and J. Guichard, «Deployments With Insertion of IPv6 Segment Routing Headers», Work in Progress, Internet-Draft, draft-voyer-6man-extension-header-insertion-09, 19 May 2020, <https://tools.ietf.org/html/draft-voyer-6man-extension-header-insertion-09>.

[IPV6-USE-MINMTU] Andrews, M., «TCP Fails To Respect IPV6_USE_MIN_MTU», Work in Progress, Internet-Draft, draft-andrews-tcp-and-ipv6-use-minmtu-04, 18 October 2015, <https://tools.ietf.org/html/draft-andrews-tcp-and-ipv6-use-minmtu-04>.

[IPWAVE-NETWORKING] Jeong, J., «IPv6 Wireless Access in Vehicular Environments (IPWAVE): Problem Statement and Use Cases», Work in Progress, Internet-Draft, draft-ietf-ipwave-vehicular-networking-16, 7 July 2020, <https://tools.ietf.org/html/draft-ietf-ipwave-vehicular-networking-16>.

[REF-MODEL] Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L., and J. Nobre, «A Reference Model for Autonomic Networking», Work in Progress, Internet-Draft, draft-ietf-anima-reference-model-10, 22 November 2018, <https://tools.ietf.org/html/draft-ietf-anima-reference-model-10>.

[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. Jamin, «Resource ReSerVation Protocol (RSVP) — Version 1 Functional Specification», RFC 2205, DOI 10.17487/RFC2205, September 1997, <https://www.rfc-editor.org/info/rfc2205>.

[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, «Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers», RFC 2474, DOI 10.17487/RFC2474, December 1998, <https://www.rfc-editor.org/info/rfc2474>.

[RFC2775] Carpenter, B., «Internet Transparency», RFC 2775, DOI 10.17487/RFC2775, February 2000, <https://www.rfc-editor.org/info/rfc2775>.

[RFC2923] Lahey, K., «TCP Problems with Path MTU Discovery», RFC 2923, DOI 10.17487/RFC2923, September 2000, <https://www.rfc-editor.org/info/rfc2923>.

[RFC3234] Carpenter, B. and S. Brim, «Middleboxes: Taxonomy and Issues», RFC 3234, DOI 10.17487/RFC3234, February 2002, <https://www.rfc-editor.org/info/rfc3234>.

[RFC3879] Huitema, C. and B. Carpenter, «Deprecating Site Local Addresses», RFC 3879, DOI 10.17487/RFC3879, September 2004, <https://www.rfc-editor.org/info/rfc3879>.

[RFC4193] Hinden, R. and B. Haberman, «Unique Local IPv6 Unicast Addresses», RFC 4193, DOI 10.17487/RFC4193, October 2005, <https://www.rfc-editor.org/info/rfc4193>.

[RFC4291] Hinden, R. and S. Deering, «IP Version 6 Addressing Architecture», RFC 4291, DOI 10.17487/RFC4291, February 2006, <https://www.rfc-editor.org/info/rfc4291>.

[RFC4397] Bryskin, I. and A. Farrel, «A Lexicography for the Interpretation of Generalized Multiprotocol Label Switching (GMPLS) Terminology within the Context of the ITU-T’s Automatically Switched Optical Network (ASON) Architecture», RFC 4397, DOI 10.17487/RFC4397, February 2006, <https://www.rfc-editor.org/info/rfc4397>.

[RFC4427] Mannie, E., Ed. and D. Papadimitriou, Ed., «Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)», RFC 4427, DOI 10.17487/RFC4427, March 2006, <https://www.rfc-editor.org/info/rfc4427>.

[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, «A Path Computation Element (PCE)-Based Architecture», RFC 4655, DOI 10.17487/RFC4655, August 2006, <https://www.rfc-editor.org/info/rfc4655>.

[RFC4821] Mathis, M. and J. Heffner, «Packetization Layer Path MTU Discovery», RFC 4821, DOI 10.17487/RFC4821, March 2007, <https://www.rfc-editor.org/info/rfc4821>.

[RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, R., Scott, K., Fall, K., and H. Weiss, «Delay-Tolerant Networking Architecture», RFC 4838, DOI 10.17487/RFC4838, April 2007, <https://www.rfc-editor.org/info/rfc4838>.

[RFC4924] Aboba, B., Ed. and E. Davies, «Reflections on Internet Transparency», RFC 4924, DOI 10.17487/RFC4924, July 2007, <https://www.rfc-editor.org/info/rfc4924>.

[RFC5704] Bryant, S., Ed., Morrow, M., Ed., and IAB, «Uncoordinated Protocol Development Considered Harmful», RFC 5704, DOI 10.17487/RFC5704, November 2009, <https://www.rfc-editor.org/info/rfc5704>.

[RFC6294] Hu, Q. and B. Carpenter, «Survey of Proposed Use Cases for the IPv6 Flow Label», RFC 6294, DOI 10.17487/RFC6294, June 2011, <https://www.rfc-editor.org/info/rfc6294>.

[RFC6325] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. Ghanwani, «Routing Bridges (RBridges): Base Protocol Specification», RFC 6325, DOI 10.17487/RFC6325, July 2011, <https://www.rfc-editor.org/info/rfc6325>.

[RFC6398] Le Faucheur, F., Ed., «IP Router Alert Considerations and Usage», BCP 168, RFC 6398, DOI 10.17487/RFC6398, October 2011, <https://www.rfc-editor.org/info/rfc6398>.

[RFC6407] Weis, B., Rowles, S., and T. Hardjono, «The Group Domain of Interpretation», RFC 6407, DOI 10.17487/RFC6407, October 2011, <https://www.rfc-editor.org/info/rfc6407>.

[RFC6709] Carpenter, B., Aboba, B., Ed., and S. Cheshire, «Design Considerations for Protocol Extensions», RFC 6709, DOI 10.17487/RFC6709, September 2012, <https://www.rfc-editor.org/info/rfc6709>.

[RFC6947] Boucadair, M., Kaplan, H., Gilman, R., and S. Veikkolainen, «The Session Description Protocol (SDP) Alternate Connectivity (ALTC) Attribute», RFC 6947, DOI 10.17487/RFC6947, May 2013, <https://www.rfc-editor.org/info/rfc6947>.

[RFC6950] Peterson, J., Kolkman, O., Tschofenig, H., and B. Aboba, «Architectural Considerations on Application Features in the DNS», RFC 6950, DOI 10.17487/RFC6950, October 2013, <https://www.rfc-editor.org/info/rfc6950>.

[RFC7045] Carpenter, B. and S. Jiang, «Transmission and Processing of IPv6 Extension Headers», RFC 7045, DOI 10.17487/RFC7045, December 2013, <https://www.rfc-editor.org/info/rfc7045>.

[RFC7228] Bormann, C., Ersue, M., and A. Keranen, «Terminology for Constrained-Node Networks», RFC 7228, DOI 10.17487/RFC7228, May 2014, <https://www.rfc-editor.org/info/rfc7228>.

[RFC7368] Chown, T., Ed., Arkko, J., Brandt, A., Troan, O., and J. Weil, «IPv6 Home Networking Architecture Principles», RFC 7368, DOI 10.17487/RFC7368, October 2014, <https://www.rfc-editor.org/info/rfc7368>.

[RFC7381] Chittimaneni, K., Chown, T., Howard, L., Kuarsingh, V., Pouffary, Y., and E. Vyncke, «Enterprise IPv6 Deployment Guidelines», RFC 7381, DOI 10.17487/RFC7381, October 2014, <https://www.rfc-editor.org/info/rfc7381>.

[RFC7556] Anipko, D., Ed., «Multiple Provisioning Domain Architecture», RFC 7556, DOI 10.17487/RFC7556, June 2015, <https://www.rfc-editor.org/info/rfc7556>.

[RFC7663] Trammell, B., Ed. and M. Kuehlewind, Ed., «Report from the IAB Workshop on Stack Evolution in a Middlebox Internet (SEMI)», RFC 7663, DOI 10.17487/RFC7663, October 2015, <https://www.rfc-editor.org/info/rfc7663>.

[RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., «Service Function Chaining (SFC) Architecture», RFC 7665, DOI 10.17487/RFC7665, October 2015, <https://www.rfc-editor.org/info/rfc7665>.

[RFC7754] Barnes, R., Cooper, A., Kolkman, O., Thaler, D., and E. Nordmark, «Technical Considerations for Internet Service Blocking and Filtering», RFC 7754, DOI 10.17487/RFC7754, March 2016, <https://www.rfc-editor.org/info/rfc7754>.

[RFC7788] Stenberg, M., Barth, S., and P. Pfister, «Home Networking Control Protocol», RFC 7788, DOI 10.17487/RFC7788, April 2016, <https://www.rfc-editor.org/info/rfc7788>.

[RFC7872] Gont, F., Linkova, J., Chown, T., and W. Liu, «Observations on the Dropping of Packets with IPv6 Extension Headers in the Real World», RFC 7872, DOI 10.17487/RFC7872, June 2016, <https://www.rfc-editor.org/info/rfc7872>.

[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, «UDP Usage Guidelines», BCP 145, RFC 8085, DOI 10.17487/RFC8085, March 2017, <https://www.rfc-editor.org/info/rfc8085>.

[RFC8086] Yong, L., Ed., Crabbe, E., Xu, X., and T. Herbert, «GRE-in-UDP Encapsulation», RFC 8086, DOI 10.17487/RFC8086, March 2017, <https://www.rfc-editor.org/info/rfc8086>.

[RFC8100] Geib, R., Ed. and D. Black, «Diffserv-Interconnection Classes and Practice», RFC 8100, DOI 10.17487/RFC8100, March 2017, <https://www.rfc-editor.org/info/rfc8100>.

[RFC8151] Yong, L., Dunbar, L., Toy, M., Isaac, A., and V. Manral, «Use Cases for Data Center Network Virtualization Overlay Networks», RFC 8151, DOI 10.17487/RFC8151, May 2017, <https://www.rfc-editor.org/info/rfc8151>.

[RFC8200] Deering, S. and R. Hinden, «Internet Protocol, Version 6 (IPv6) Specification», STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, <https://www.rfc-editor.org/info/rfc8200>.

[RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., «Network Service Header (NSH)», RFC 8300, DOI 10.17487/RFC8300, January 2018, <https://www.rfc-editor.org/info/rfc8300>.

[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, «Segment Routing Architecture», RFC 8402, DOI 10.17487/RFC8402, July 2018, <https://www.rfc-editor.org/info/rfc8402>.

[RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, «Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal», RFC 8445, DOI 10.17487/RFC8445, July 2018, <https://www.rfc-editor.org/info/rfc8445>.

[RFC8517] Dolson, D., Ed., Snellman, J., Boucadair, M., Ed., and C. Jacquenet, «An Inventory of Transport-Centric Functions Provided by Middleboxes: An Operator Perspective», RFC 8517, DOI 10.17487/RFC8517, February 2019, <https://www.rfc-editor.org/info/rfc8517>.

[RFC8557] Finn, N. and P. Thubert, «Deterministic Networking Problem Statement», RFC 8557, DOI 10.17487/RFC8557, May 2019, <https://www.rfc-editor.org/info/rfc8557>.

[RFC8568] Bernardos, CJ., Rahman, A., Zuniga, JC., Contreras, LM., Aranda, P., and P. Lynch, «Network Virtualization Research Challenges», RFC 8568, DOI 10.17487/RFC8568, April 2019, <https://www.rfc-editor.org/info/rfc8568>.

[RFC8578] Grossman, E., Ed., «Deterministic Networking Use Cases», RFC 8578, DOI 10.17487/RFC8578, May 2019, <https://www.rfc-editor.org/info/rfc8578>.

[RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas, «Deterministic Networking Architecture», RFC 8655, DOI 10.17487/RFC8655, October 2019, <https://www.rfc-editor.org/info/rfc8655>.

[RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., Matsushima, S., and D. Voyer, «IPv6 Segment Routing Header (SRH)», RFC 8754, DOI 10.17487/RFC8754, March 2020, <https://www.rfc-editor.org/info/rfc8754>.

[SPB] «IEEE Standard for Local and metropolitan area networks — Bridges and Bridged Networks», DOI 10.1109/IEEESTD.2018.8403927, IEEE 802.1Q-2018, July 2018, <https://ieeexplore.ieee.org/document/8403927>.

[SRV6-NETWORK] Filsfils, C., Camarillo, P., Leddy, J., Voyer, D., Matsushima, S., and Z. Li, «SRv6 Network Programming», Work in Progress, Internet-Draft, draft-ietf-spring-srv6-network-programming-16, 27 June 2020, <https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-16>.

[USER-PLANE-PROTOCOL] Homma, S., Miyasaka, T., Matsushima, S., and D. Voyer, «User Plane Protocol and Architectural Analysis on 3GPP 5G System», Work in Progress, Internet-Draft, draft-ietf-dmm-5g-uplane-analysis-03, 3 November 2019, <https://tools.ietf.org/html/draft-ietf-dmm-5g-uplane-analysis-03>.

Приложение A. Таксономия ограниченных доменов

В этом приложении рассмотрена таксономия ограниченных доменов, включая:

  • домен как целое;

  • отдельные узлы;

  • границы доменов;

  • топологию доменов;

  • технологии доменов;

  • подключение доменов к Internet

  • модели безопасности, доверия и конфиденциальности;

  • рабочие операции.

A.1. Домен как целое

  • Почему домен существует (например, человеческий выбор, административные правила, организационные требования, технические требования, такие как операционное разделение с целями масштабирования)?

  • Если есть специальные требования, они относятся к L2, L3 или вышележащему уровню?

  • Где находится домен в спектре от полностью управляемого людьми до соврешенно автономного?

  • Если домен управляемый, какой стиль применяется (ручная или автоматизированная настройка, автоматическое управление (orchestration))?

  • Имеется ли модель политики (намерения, правила настройки конфигурации)?

  • Используется в домене контролируемый, платный или свободный доступ?

A.2. Отдельные узлы

  • Являются члены домена полными узлами или только интерфейсами узлов?

  • Являются узлы постоянными членами домена или возможно подключение и отключение?

  • Являются узлы физическими или виртуальными устройствами?

  • Являются виртуальные устройства обычными (общего назначения) или специализированными (функции, приложения, пользователи)?

  • Являются узлы ограниченными в возможностях (батареи и т. п.)?

  • Устройства устанавливаются «из коробки» или требуют предварительной настройки?

A.3. Граница домена

  • Как задается или идентифицируется граница домена?

  • Граница домена фиксирована или является динамической?

  • Являются граничные узлы специальными или можно применять любое устройство?

A.4. Топология

  • Является домен частью другого домена L2 или L3?

  • Перекрывается ли домен с другими доменами (может ли узел входить в несколько доменов)?

  • Модем соответствует физической топологии или использует виртуальную (наложенную)?

  • Ограничен домен зданием, кампусом, транспортным средством или является распределенным?

  • Распределенный домен имеет соединения через частные сети или Internet?

  • В плане адресации IP домен является локальным для канала, локальным для сайта или глобальным?

  • Соответствует ли область индивидуальной и групповой адресации границам домена?

A.5. Технология

  • Какие применяются протоколы маршрутизации или иные механизмы пересылки (например, MPLS или не-IP)?

  • Если домен является наложенным, какой применяется метод (L2VPN, L3VPN и т. п.)?

  • Есть ли специфические требования QoS?

  • Какова задержка на каналах — обычная или очень большая?

  • Имеются ли в домене мобильные узлы? Является ли вся сеть мобильной?

  • Какие специфические технологии применимы (например, из числа описанных в разделе 4)?

A.6. Подключение к Internet

  • Является подключение к Internet постоянным или прерывистым (отсутствие подключения не считается)?

  • Блокируется ли трафик на входе или выходе?

  • Какой трафик разрешен (allow), входящий или исходящий?

  • Какой трафик преобразуется, входящий или исходящий?

  • Нужен ли защищенный или привилегированный удаленный доступ?

  • Разрешает ли домен непривилегированные удаленные сессии?

A.7. Модель безопасности, доверия и приватности

  • Требуется ли контроль полномочий для членов домена?

  • Имеют ли все узлы домена одинаковый уровень доверия?

  • Является ли трафик аутентифицированным?

  • Шифруется ли трафик?

  • Что спрятано от внешнего мира?

A.8. Работа

  • Играет ли домен важную роль в обеспечении безопасности людей?

  • Требования к надежности обычны или нужно 99,999%?

  • Работает ли домен в условиях опасной среды?

  • Имеются ли специфические требования к установке?

  • Доступ для обслуживания — просто, сложно или невозможно?

  • Возможно ли обновление программ и микрокода?

A.9. Использование таксономии

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

Благодарности

Полезные замечания предоставили Amelia Andersdotter, Edward Birrane, David Black, Ron Bonica, Mohamed Boucadair, Tim Chown, Darren Dukes, Donald Eastlake, Adrian Farrel, Tom Herbert, Ben Kaduk, John Klensin, Mirja Kuehlewind, Warren Kumari, Andy Malis, Michael Richardson, Mark Smith, Rick Taylor, Niels ten Oever и другие.

Участники работы

Sheng Jiang

Huawei Technologies

Q14, Huawei Campus

No. 156 Beiqing Road

Hai-Dian District, Beijing

100095

China

Email: jiangsheng@huawei.com

Адреса авторов

Brian Carpenter

The University of Auckland

School of Computer Science

University of Auckland

PB 92019

Auckland 1142

New Zealand

Email: brian.e.carpenter@gmail.com

Bing Liu

Huawei Technologies

Q14, Huawei Campus

No. 156 Beiqing Road

Hai-Dian District, Beijing

100095

China

Email: leo.liubing@huawei.com

Перевод на русский язык

Николай Малых

nmalykh@protocols.ru

1Quality-of-service — качество обслуживания.

2Supervisory Control And Data Acquisition — диспетчерское управление и сбор данных.

3Internet-of-Things — Internet вещей.

4Interactive Connectivity Establishment — интерактивная организация соединений.

5Virtual Private LAN Service — виртуальная частная ЛВС.

6Content Delivery Network — сеть доставки содержимого.

7Virtual private network — виртуальная частная сеть.

8Transparent Interconnection of Lots of Links — прозрачные соединения между большим числом каналов.

9Shortest Path Bridging — мост через кратчайший путь.

10Differentiated Services Code Point — код дифференцированного обслуживания.

11Service Function Chaining.

12Network Service Header — заголовок сетевой службы.

13Firewall and Service Ticket — квитанция (билет) для межсетевых экранов и служб.

14Home Network Control Protocol — протокол управления домашней сетью.

15Operations, Administration, and Maintenance — эксплуатация, администрирование и обслуживание.

16Internet of Things — Internet вещей.

17Differentiated Services Code Point — код дифференцирования услуг.




RFC 8793 Information-Centric Networking (ICN): Content-Centric Networking (CCNx) and Named Data Networking (NDN) Terminology

Internet Research Task Force (IRTF)                          B. Wissingh
Request for Comments: 8793                                           TNO
Category: Informational                                          C. Wood
ISSN: 2070-1721                          University of California Irvine
                                                            A. Afanasyev
                                        Florida International University
                                                                L. Zhang
                                                                    UCLA
                                                                 D. Oran
                                       Network Systems Research & Design
                                                             C. Tschudin
                                                     University of Basel
                                                               June 2020

Информационно-ориентированные сети — терминология CCNx и NDN

PDF

Аннотация

Информационно-ориентированные сети (ICN1) — это новая парадигма, где сетевые коммуникации выполняются путем запроса именованного содержимого (content) вместо отправки пакетов по адресам получателей. Примерами архитектуры ICN являются сети именованных данных (NDN2) и контентно-ориентированные сети (CCNx3). В этом документе представлен обзор терминологии и определений, которые могут использоваться при описании концепций этих двух реализаций ICN. Имеются и другие архитектуры ICN, не являющиеся частью концепций NDN и CCNx, но они выходят за рамки этого документа. Документ является результатом работы исследовательской группы ICNRG4.

Статус документа

Документ не содержит проекта какой-либо спецификации (Internet Standards Track) и публикуется с информационными целями.

Документ создан в Internet Research Task Force (IRTF). IRTF публиуует результаты связанных с Internet исследований и разработок. Эти результаты могут оказаться не пригодными для реализации. Данный документ RFC выражает согласованную точку зрения ICNRG и IRTF. Документы, одобренные для публикации IRSG, не претендуют на статус стандартов Internet (см. раздел 2 в RFC 7841).

Информация о текущем статусе документа, найденных ошибках и способах обратной связи доступна по ссылке https://www.rfc-editor.org/info/rfc8793.

Авторские права

Copyright (c) 2020. Авторские права принадлежат IETF Trust и лицам, указанным в качестве авторов документа. Все права защищены.

Документ является субъектом прав и ограничений, указанных в BCP 78 и IETF Trust Legal Provisions и относящихся к документам IETF (http://trustee.ietf.org/license-info), на момент публикации данного документа. Прочтите упомянутые документы внимательно, поскольку в них описаны права и ограничения, относящиеся к данному документу.


1. Введение

Архитектура ICN является развитием инфраструктуры Internet от имеющихся хост-ориентированных систем в направлении ориентации на данные, где доступ к информации по именам становится важным элементом (примитивом) сетей. Цель заключается в обеспечении приложениям возможности ссылаться на данные независимо от места их размещения или способов доставки, что обеспечивает естественную групповую доставку, повсеместное кэширование в сети и репликацию объектов данных.

Поскольку разработка этого направления продолжается, появляется много новых терминой. Целью данного документа является сбор ключевых терминов с их определениями, применяемыми в проектах CCNx и NDN. Важными для этих проектов документами являются [RFC8569], [RFC8609] и [NDNTLV]. Другие проекты ICN, такие как [NETINF], [PSIRP], [MOBILITY-FIRST] не рассматриваются здесь, но могут быть предметом других документов.

Для обеспечения контекста некоторых из определяемых здесь терминов сначала обрисована общая картина ICN путем введения базовых концепций и указания основных компонентов в разделе 2. Затем в разделе 3 рассматриваются относящиеся к ICN термины, разделенные по категориям. Следует отметить, что при такой организации некоторые термины могут применяться до их определения.

Хотя этот документ описывает термины, связанные с конфиденциальностью и целостностью, следует отметить, что архитектуры ICN, подобные NDN и CCNx, в общем случае не обеспечивают конфиденциальности данных, перенося этот вопрос на уровень приложений.

Документ представляет согласованную точку зрения ICNRG. Он широко обсуждался членами исследовательской группы (RG5), занимающимися конкретными направлениями, рассматриваемыми в документе. Документ не является результатом работы IETF и не предназначен для стандартизации в IETF.

2. Набросок общей картины ICN

В сетевом смысле ICN является инфраструктурой для доставки именованных данных, более полное описание которой дано в разделе 4.

запрашивающий   необязательные         узел-источник 
    (узел)      узлы пересылки           или реплика
  |                 | ... |                  |...|
  |   Interest(n)   |     |   Interest(n)    |   |
  | --------------> |     | ---------------> |   |
  |                 |     | -------------------> |
  |                 |     |                  |   |
  |                 |     |  Data([n],c,[s]) |   |
  |                 |     | <--------------- |   |
  |                 |     | <------------------- |
  | Data([n],c,[s]) |     |                  |   |
  | <-------------- |     |                  |   |

n - имя, c - содержимое, s - подпись

Рисунок 1. Протокол «запрос-отклик в сети ICN.


Ниже описаны базовые концепции, требуемые для обсуждения реализации этой абстракции услуг.

Request-Reply Protocol (пакеты Interest и Packet) — протокол “запрос-отклик”

Услуги поиска в ICN реализуются через определение двух форматов сетевых пакетов — Interest с запросом содержимого по имени и Data с запрошенным содержимым. Возвращаемые пакеты Data должны соответствовать параметрам запроса (например, полное или частичное совпадение имени). Если запрос не однозначен и ему соответствует несколько пакетов Data, сеть ICN возвращает лишь один подходящий пакет Data (это балансирует пакеты Interest и Data через отдельный интерфейс L2).

Packet and Content Names — пакеты и имена содержимого

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

Data Authenticity and Encryption — шифрование и аутентичность данных

Любой потребитель или элемент сети может (в принципе) проверить аутентичность пакета Data на основании криптографической привязки между именем и содержимым. Отметим, что аутентичность данных не тождественна доверию к ним, хотя они связаны между собой. Пакет считается аутентичным, если он имеет действительную привязку имени к содержимому, но это не предполагает обязательного «доверия» к нему.

Trust — доверие

Аутентичность данных отличается от доверия к ним, хотя эти концепции связаны. Пакет считается аутентичным при наличии действительной привязки имени к содержимому. Пакет считается доверенным (т. е. происходящим от «уважаемого» или достоверного источника), если привязка действительна в контексте модели доверия. Модель доверия предполагает доверие к тому, что имя, присвоенное определенной порции данных, действительно для их содержимого. Дополнительно этот вопрос рассматривается в разделе 6.

Segmenting and Versioning — сегментация и версии

В сетях ICN размер пакетов ограничен. Поскольку объекты данных прикладного уровня могут быть достаточно велики, их приходится сегментировать в отдельные пакеты Data. Имена таких пакетов могут, например, создаваться путем выбора общего имени объекта прикладного уровня и суффикса, добавляемого к каждому сегменту. Один и тот же метод может применяться для обслуживания разных версий объекта прикладного уровня путем включения номера версии в имя объекта.

Packet and Frame — пакет и кадр

NDN и CCNx используют протокольные блоки данных (PDU6), которые обычно больше максимального передаваемого блока базовой сетевой технологии. Здесь PDU называются пакетами и (возможно фрагментированными) частями пакетов, роходящими через интерфейс L2 с ограниченным MTU как кадры. Обработка на уровне L2, ведущая к фрагментированию пакетов ICN, выполняется внутри сети ICN и не видна сервисному интерфейсу.

ICN Node — узел ICN

Узел в сети ICN может играть роль производителя данных (producer), их потребителя (consumer) и/или пересылающего пакеты Interest и Data. При соединении узла пересылки с соседями он в реальном масштабе времени пересылает пакеты Interest и Data. Этот узел может также служить промежуточным хранилищем, удерживающимна некоторое время пакеты Interest и Data перед их отправкой следующему узлу. На узле ICN могут также применяться протоколы маршрутизации для оказания помощи в пересылке пакетов Interest.

Forwarding Plane — плоскость (уровень) пересылки

Канонический способ реализации пересылки пакетов в сети ICN базируется на 3 структурах данных, фиксирующих состояние узла, — FIB7, PIT8 и CS9. Применяются также стратегии пересылки Interest, принимающие данные от FIB и измерителей для принятия решений о пересылке Interest. Получив пакет Interest, узел проверяет CS и PIT для поиска подходящей записи. Если такой записи не найдено, узел записывает Interest в свою таблицу PIT и пересылает Interest на следующий интервал (интервалы) по пути к запрошенному содержимому на основе информации из своей базы FIB.

3. Термины

3.1. Базовые термины

Information-Centric Networking (ICN) — информационно-ориентированная сеть

Сетевая архитектура, отыскивающая пакеты данных (Data) в ответ на запросы Interest. Двумя реализациями ICN служат ориентированные на соединения сети CCNx (1.x) и сети именованных данных NDN.

Data Packet Immutability — неизменяемость пакетов данных

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

3.2. Термины, относящиеся к узлам ICN

ICN Interface — интерфейс ICN

Обобщение сетевого интерфейса, которое может представлять физический интерфейс (ethernet, Wi-Fi, bluetooth и т. п.), наложенный канал между узлами (туннель IP/UDP и т. п.) или канал IPC10 с приложением (сокет unix, общая память и т. п.).

Синоним — face.

ICN Consumer — потребитель ICN

Элемент ICN, запрашивающий пакеты Data путем создания и отправки пакетов Interest в направлении локального (через интерфейс внутри узла) или удаленного (через внешний интерфейс узла) узла пересылки ICN.

Синонимы — consumer, information consumer, data consumer, consumer of the content.

ICN Producer — производитель (издатель) ICN

Элемент ICN, создающий пакеты Data и делающий их доступными для извлечения.

Синонимы — producer, publisher, information publisher, data publisher, data producer.

ICN Forwarder — пересылающий узел ICN

Элемент ICN, реализующий пересылку с учетом состояния.

Синоним — ICN router.

ICN Data Node — узел данных ICN

Элемент ICN, временно сохраняющий и потенциально содержащий пакет Interest или Data перед его пересылкой следующему элементу ICN. Отметим, что такие узлы ICN не обладают всеми свойствами узлов данных, используемыми в спецификации DTN11 [RFC4838].

3.3. Термины, связанные с пересылкой

Stateful Forwarding — пересылка с учетом состояния

Процесс пересылки, записывающий входящие пакеты Interest в таблицу PIT и использующий записанную информацию для пересылки полученных пакетов Data в направлении потребителей. Записанная информация может также служить для измерения производительности плоскости данных, например, для тонкой настройки стратегии пересылки.

Синонимы — ICN Data plane, ICN Forwarding.

Forwarding Strategy — стратегия пересылки

Модуль пересылки ICN с учетом состояния (ICN data), принимающие решение о том, куда и как переслать входящий пакет Interest. Стратегия пересылки принимает также данные FIB, параметры производительности плоскости данных и/или использует иные механизмы для принятия решений.

Синоним — Interest forwarding strategy.

Upstream — восходящая (пересылка)

Пересылка пакетов в направлении Interest (т. е. пакеты Interest пересылаются в восходящем направлении — потребитель, маршрутизатора, маршрутизатор, …, издатель.

Downstream — нисходящая (пересылка)

Пересылка пакетов в направлении, обратном перемылке Interest (пакеты Data и Interest Nacks пересылаются в нисходящем направлении): издатель, маршрутизатор, …, потребители.

Interest Forwarding — пересылка Interest

Процесс пересылки пакетов Interest с использованием Name из этих пакетов. При пересылке с учетом состояния это включает также создание записи в PIT. Решение о пересылке принимает Forwarding Strategy.

Interest Aggregation — агрегирование Interest

Процесс объединения множества пакетов Interest с одним Name и дополнительными ограничениями для тех же Data в одну запись PIT.

Синоним — Interest collapsing.

Data Forwarding — пересылка данных

Процесс пересылки входящих пакетов Data интерфейсам, указанным в соответствующих записях PIT и удаления этих записей.

Satisfying an Interest — выполнение Interest

Процесс возврата содержимого в целом, удовлетворяющий ограничениям, заданным в Interest (прежде всего, совпадение Name).

Interest Match in FIB (longest prefix match) — совпадение Interest в FIB по самому длинному префиксу

Процесс нахождения записи FIB с наибольшим совпадением префикса (по числу компонентов Name), являющимся префиксом указанного Name (см. 3.5. Термины, связанные с типами имен).

Interest Match in PIT (exact match) — точное совпадение Interest в FIB

Процесс нахождения записи PIT с тем же Name, что указано в Interest (включая ограничения Interest при наличии).

Data Match in PIT (all match) — полное совпадение Data в FIB

Процесс нахождения набора записей PIT, которым может соответствовать указанный пакет Data.

Interest Match in CS (any match) — совпадение Interest в CS

Процесс нахождения записи в Content Store маршрутизатора, соответствующей заданному пакету Interest.

Pending Interest Table (PIT) — таблица ожидающих Interest

База данных с записями полученных, но еще не выполненных Interest с указанием интерфейсов, принявших запросы. PIT может также включать интерфейсы, в которые пересланы Interest, ссылки для доступа к сведениям о производительности плоскости данных. Пакеты Interest до одних Data объединяются в одну запись PIT.

Forwarding Information Base (FIB) — база информации о пересылке

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

Content Store (CS) — хранилище содержимого

База данных для кэширования в маршрутизаторе ICN.

In-Network Storage — хранилище в сети

Необязательный процесс хранения пакетов Data внутри сети (opportunistic cache, dedicated on/off path cache, managed in-network storage system) для выполнения будущих запросов Interest к тем же Data. Хранилища могут анонсировать сохраненные пакеты Data в систему маршрутизации.

Opportunistic Caching

Процесс временного хранения пересланных пакетов Data в памяти маршрутизатора (RAM или диск) для их использования в ответах на будущие Interest для тех же Data.

Синоним — on-path in-network caching.

Managed Caching — управляемое кэширование

Процесс поддержки временного, постоянного или планируемого хранилища избранных пакетов Data.

Синоним — off-path in-network storage.

Managed In-Network Storage — управляемое хранилище в сети

Элемент, выступающий как издатель ICN, который реализует управляемое кэширование.

Синонимы — repository, repo.

ICN Routing Plane — плоскость маршрутизации ICN

Протокол или набор протоколов ICN для обмена информацией о доступности пространства имен (Name).

ICN Routing Information Base (RIB) — информационная база маршрутизации ICN

База данных с набором отображений префикс-интерфейс, создаваемых работой одного или множества протоколов маршрутизации. RIB используется для заполнения FIB.

3.4. Термины, связанные с типами пакетов

Interest Packet — пакет Interest

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

Синонимы — Interest, Interest message, information request.

Interest Nack — негативное подтверждение Interest

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

Синонимы — network NACK, Interest return.

Data Packet — пакет Data

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

Синонимы — data, data object, content object, content object packet, data message, named data object, named data.

Link — привязка

Тип пакета Data, тело которого содержит имя (Name) другого пакета Data. Это внутреннее имя часто является полным, т. е. указывает Packet ID соответствующего пакета Data, но это не является требованием.

Синоним — pointer.

Manifest — манифест

Тип пакета Data, содержащего привязки полного имени для одного или нескольких пакетов Data. Манифесты группируют коллекции связанных пакетов Data с одним Name. Манифесты позволяют разбивать большие объекты Data на отдельные Content Object с одним именем, а также представлять наборы связанных Content Object как форму «каталога» (directory). Дополнительным преимуществом манифестов является снижение издержек на верификацию подписей для каждого пакета Data, упомянутого во внутренних Link. Манифесты обычно содержат дополнительные метаданные, например, размер (в байтах) каждого привязанного пакета Data и криптографический хэш-дайджест всех Data, содержащихся в связанных пакетах Data.

3.5. Термины, связанные с типами имен

Name

Идентификатор пакета Data. Имена в ICN организованы иерархически (последовательность меток) и обычно семантически значимы, что делает их выразительными, гибкими и специфичными для приложения (подобно HTTP URL). Name может кодировать информацию о контексте приложения, семантике, местоположении (топология, география и т. п.), имени сервиса и т. п.

Синонимы — data name, interest name, content name.

Name component — компонент Name

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

Синоним — name segment (as in CCNx).

Packet ID

Уникальный криптографический идентификатор пакета Data. Обычно это криптографический дайджест пакета Data (например, SHA256 [RFC6234]), учитывающая имя, данные, метаинформацию и подпись.

Синоним — implicit digest.

Selector — селектор

Механизм (условие) выбора отдельного пакета Data из коллекции, соответствующего данному пакету Interest, запрашивающему данные с использованием префикса или точного имени.

Синонимы — interest selector, restrictor, interest restrictor.

Nonce

Поле пакета Interest, временно указывающее экземпляр Interest (для данного имени). Отметим, что определение nonce в спецификации NDN не обязательно соответствует всем свойствам nonce из [RFC4949].

Exact Name — точное имя

Имя, указанное в пакете Data, которое обычно однозначно указывает данный пакет Data.

Full Name — полное имя

Точное имя с Packet ID соответствующего пакета Data.

Prefix Name — префикс имени

Name с частью последовательности меток (начиная с первой) из Name в пакете Data.

Синоним — prefix.

3.6. Термины, связанные с использованием имен

Naming conventions — соглашения об именовании

Соглашение, договор или спецификация именования пакетов Data, структурирующие пространство имен.

Синонимы — Naming scheme, ICN naming scheme, namespace convention.

Hierarchically structured naming — иерархически структурированное именование

Схема именования, выделяющая и интерпретирующая Name как последовательность меток (компоненты Name) с иерархической структурой без единого административного корня (узла). Структура обеспечивает полезный контекст для Name.

Синонимы — hierarchical naming, structured naming.

Flat naming — плоское именование

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

Segmentation — сегментация

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

Синоним — chunking.

Versioning — поддержка версий

Процесс назначения уникального имени (Name) выпуску содержимого в определенном пакете Data. При импользовании в Name с иерархической структурой версия пакета Data может передаваться в отдельной метке Name (например, префикс указывает данные, а уникальный номер — их версию).

Fragmentation — фрагментация

Процесс расщепления PDU на кадры (Frame), которые можно передать через интерфейс L2 с меьшим MTU.

3.7. Термины, связанные с безопасностью

Data-Centric Security — защита данных

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

Синоним — directly securing Data packet.

Data Integrity — целостность данных

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

Data Authenticity — достоверность данных

Криптографический механизм обеспечения достоверности пакета Data на основе выбранной (например, издателем и/или потребителем) модели доверия. Обычно аутентичность данных обеспечивается за счет использования криптографических подписей с асимметричным шифрованием (например, RSA, ECDSA), но может применяться и симметричное шифрование (например, HMAC12) внутри домена доверия.

Data Confidentiality — конфиденциальность данных

Криптографический механизм обеспечения секретности пакета Data. Защита конфиденциальности Data включает раздельные механизмы для содержимого и имени.

Content Confidentiality — конфиденциальность содержимого

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

Name Confidentiality — конфиденциальность имени

Криптографический механизм, предотвращающий получение мата-информации из пакета Data наблюдателю обмена Interest-Data (например, промежуточному маршрутизатору). Этот механизм может быть реализован на основе шифрования Data (как конфиденциальность содержимого) или «затемнения» (obfuscation).

4. Семантика и применение

Описанная выше терминология является обнародованием предплагаемой семантики операций NDN и CCNx (Wчто ожидается в сети). Далее кратко рассмотрены наиболее часто предлагаемые варианты применения и интерпретации.

4.1. Передача данных

Представление сети NDN и CCNx основано на допущение о том, что протокол запрос-отклик реализует базовые услуги передачи данных без гарантии доставки для одиночных именованных пакетов.

4.2. Транспортировка данных

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

4.3. Служба поиска

В более распределенных системном представлении базового протокола запрос-отклик NDN и CCNx обеспечивают распределенную службу поиска, возвращающую значение, найденное по ключу (=name).

4.4. Доступ к базе данных

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

4.5. Вызов удаленных процедур

Имена, определенные в этом документе для Interest и Data, могут указывать на вызовы удаленных процедур, их входные аргументы и результаты. Для полного представления о создании RPC и работе с другими системами удаленных вызовов следует обратиться к работе [RICE]. Эти возможности могут быть расширены в полную инфраструктуру распределенной обработки, как предложено в работе [CFN].

4.6. Публикация и подписка

Имена, определенные в этом документе для Interest и Data, могут указывать коллекции даннх, на которые можно подписаться, а также отдельные объекты данных, публикуемые в архитектуре Publish-Subscribe. Пример создания таких систем на основе ICN приведен в работе [LESSONS-LEARNED].

5. Взаимодействие с IANA

Этот документ не предполагает действий IANA.

6. Вопросы безопасности

Хотя определенные здесь термины сами по себе не создают новых вопросов безопасности, использующие эти термины архитекуты могут вызывать такие вопросы. Следует обратиться к спецификации архитектуры (например, [RFC8569] и [NDN]), где вопросы безопасности рассматриваются подробно.

Некоторые из терминов в этом документе используют понятия «доверие» (trust), «заслуживающий доверия» (trustworthy) и «модель доверия» (trust model). Предполагается, что эти термины имеют общепринятый смысл, однако в недавнее время было опубликовано мноэество работ, посвященных доверию и, в частности, схемам доверия в архитектуре ICN. Например, полезно прочесть работу [SCHEMATIZING-TRUST], где более подробно рассмотрена формализация доверия для современных систем NDN и CCNx.

7. Литература

7.1. Нормативные документы

[CFN] Krol, M., Mastorakis, S., Kutscher, D., and D. Oran, «Compute First Networking: Distributed Computing meets ICN»13, ACM ICN, DOI 10.1145/3357150.3357395, September 2019, <https://dl.acm.org/citation.cfm?id=3357395>.

[LESSONS-LEARNED] Nichols, K., «Lessons Learned Building a Secure Network Measurement Framework using Basic NDN»14, ACM ICN, DOI 10.1145/3357150.3357397, September 2019, <https://dl.acm.org/citation.cfm?id=3357397>.

[MOBILITY-FIRST] Raychaudhuri, D., Nagaraja, K., and A. Venkataramani, «MobilityFirst: a robust and trustworthy mobility-centric architecture for the future internet»15, ACM SIGMOBILE, Volume 16, Issue 3, DOI 10.1145/2412096.2412098, July 2012, <https://dl.acm.org/citation.cfm?id=2412098>.

[NDNTLV] Named Data Networking, «NDN Packet Format Specification», <https://named-data.net/doc/ndn-tlv/>.

[NETINF] Dannewitz, C., Kutscher, D., Ohlman, B., Farrell, S., Ahlgren, B., and K. Holger, «Network of Information (NetInf) — An information-centric networking architecture», Computer Communications, Volume 36, Issue 7, DOI 10.1016/j.comcom.2013.01.009, April 2013, <https://dl.acm.org/citation.cfm?id=2459643>.

[PSIRP] Trossen, D., Tuononen, J., Xylomenos, G., Sarela, M., Zahemszky, A., Nikander, P., and T. Rinta-aho, «From Design for Tussle to Tussle Networking: PSIRP Vision and Use Cases», May 2008, <http://www.psirp.org/files/Deliverables/PSIRP-TR08-0001_Vision.pdf>.

[RICE] Krol, M., Habak, K., Kutscher, D., Oran, D., and I. Psaras, «RICE: remote method invocation in ICN»16, ACM ICN, DOI 10.1145/3267955.3267956, September 2018, <https://dx.doi.org/10.1145/3267955.3267956>.

[SCHEMATIZING-TRUST] Yu, Y., Afanasyev, A., Clark, D., Claffy, K. C., Jacobson, V., and L. Zhang, «Schematizing Trust in Named Data Networking»17, ACM ICN, DOI 0.1145/2810156.2810170, September 2015, <https://dx.doi.org/10.1145/2810156.2810170>.

7.2. Дополнительная литература

[NDN] Named Data Networking, «Named Data Networking: Executive Summary», September 2010, <https://named-data.net/project/execsummary/>.

[RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, R., Scott, K., Fall, K., and H. Weiss, «Delay-Tolerant Networking Architecture», RFC 4838, DOI 10.17487/RFC4838, April 2007, <https://www.rfc-editor.org/info/rfc4838>.

[RFC4949] Shirey, R., «Internet Security Glossary, Version 2», FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, <https://www.rfc-editor.org/info/rfc4949>.

[RFC6234] Eastlake 3rd, D. and T. Hansen, «US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)», RFC 6234, DOI 10.17487/RFC6234, May 2011, <https://www.rfc-editor.org/info/rfc6234>.

[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>.

Благодарности

Marc Mosko предоставил много рекомендаций и точных указаний для правильных формулировок и определений терминов. Marie-Jose Montpetit подготовила рецензию IRSG, что помогло существенно улучшить текст. Дополнительные замечания при опросе IRSG от Stephen Farrell, Ari Keraenen, Spencer Dawkins, Carsten Bormann, Brian Trammell помогли улучшить документ. Полезные комментарии были получены в рамках обзора конфликтов IESG от Mirja Kuehlewind и Benjamin Kaduk.

Адреса авторов

Bastiaan Wissingh

TNO

Email: bastiaan.wissingh@tno.nl

Christopher A. Wood

University of California Irvine

Email: caw@heapingbits.net

Alex Afanasyev

Florida International University

Email: aa@cs.fiu.edu

Lixia Zhang

UCLA

Email: lixia@cs.ucla.edu

David Oran

Network Systems Research & Design

Email: daveoran@orandom.net

Christian Tschudin

University of Basel

Email: christian.tschudin@unibas.ch

Перевод на русский язык

Николай Малых

nmalykh@protocols.ru


1Information-Centric Networking.

2Named Data Networking.

3Content-Centric Networking.

4Information-Centric Networking Research Group — группа исследований по информационно-ориентированным сетям.

5Research Group.

6Protocol Data Unit.

7Forwarding Interest Base — база пересылки Interest.

8Pending Interest Table — таблица ожидающих Interest.

9Content Store — хранилище содержимого.

10Inter-process communication — коммуникации между процессами на узле.

11Delay Tolerant Networking — устойчивая к задержкам сеть.

12Hashed Message Authentication Code — хэшированный код аутентификации сообщения.

13Презентация доклада доступна по ссылке. Прим. перев.

14Полный текст работы доступен по ссылке. Прим. перев.

15Полный текст работы доступен по ссылке. Прим. перев.

16Презентация доклада доступна по ссылке. Прим. перев.

17Полный текст работы доступен по ссылке. Прим. перев.




RFC 8655 Deterministic Networking Architecture

Internet Engineering Task Force (IETF)                           N. Finn
Request for Comments: 8655                                        Huawei
Category: Standards Track                                     P. Thubert
ISSN: 2070-1721                                                    Cisco
                                                                B. Varga
                                                               J. Farkas
                                                                Ericsson
                                                            October 2019

Deterministic Networking Architecture

Архитектура детерминированых сетей

PDF

Тезисы

В этом документе описана базовая архитектура детерминированных сетей (DetNet1), обеспечивающая возможность передачи конкретного группового и индивидуального трафика приложений, работающих в реальном масштабе времени, с минимальными потерями и ограниченной задержкой внутри сетевого домена. Используемые методы включают 1) резервирование ресурсов уровня данных для индивидуальных (или агрегированных) потоков DetNet на некоторых или всех промежуточных узлах пути, 2) обеспечение явных маршрутов для потоков, которые не меняются сразу при изменении топологии сети, и 3) распределение данных из пакетов потока DetNet во времени и/или пространстве для обеспечения доставки каждого пакета, несмотря на потери в пути. DetNet работает на уровне IP и предоставляет услуги на основе технологий нижележащих уровней, таких как MPLS и TSN2 (IEEE 802.1).

Статус документа

Документ относится к категории Internet Standards Track.

Документ является результатом работы IETF3 и представляет согласованный взгляд сообщества IETF. Документ прошел открытое обсуждение и был одобрен для публикации IESG4. Дополнительную информацию о стандартах Internet можно найти в разделе 2 в RFC 7841.

Информацию о текущем статусе документа, ошибках и способах обратной связи можно найти по ссылке https://www.rfc-editor.org/info/rfc8655.

Авторские права

Авторские права (Copyright (c) 2019) принадлежат IETF Trust и лицам, указанным в качестве авторов документа. Все права защищены.

Этот документ является субъектом прав и ограничений, перечисленных в BCP 78 и IETF Trust Legal Provisions и относящихся к документам IETF (http://trustee.ietf.org/license-info), на момент публикации данного документа. Прочтите упомянутые документы внимательно, поскольку в них описаны права и ограничения, относящиеся к данному документу. Фрагменты программного кода, включенные в этот документ, распространяются в соответствии с упрощенной лицензией BSD, как указано в параграфе 4.e документа IETF Trust Legal Provisions, без каких-либо гарантий (как указано в Simplified BSD License).

Оглавление

Исключено в версии HTML.

1. Введение

В этом документе представлена архитектура детерминированных сетей DetNet, которая обеспечивает возможность доставки потоков данных с очень низкими потерями пакетов и ограниченной сквозной задержкой. Архитектура DetNet предназначена для сетей с единым администрированием или управляемых тесно связанными администраторами, включая кампусные сети и частные сети WAN. DetNet не рассчитана на большие группы доменов, такие как Internet.

DetNet на уровне IP и обеспечивает услуги на основе технологий нижележащих уровней, таких как MPLS и IEEE 802.1 TSN. DetNet обеспечивает надежные и доступные услуги путем выделения сетевых ресурсов (таких как пропускная способность каналов и буферное пространство) для потоков DetNet и/или классов потоков, а также репликации пакетов в несколько путей. Не использованные резервы ресурсов доступны для прочего (не DetNet) трафика, если гарантии соблюдены.

Документ Deterministic Networking Problem Statement [RFC8557] является введением в DetNet, а в Deterministic Networking Use Cases [RFC8578] обоснована потребность в архитектуре. Конкретные методы идентификации потоков DetNet и назначения им определенных путей через сеть рассмотрены в [DETNET-FRAMEWORK].

Целью DetNet является создание конвергентных сетей, включая объединение критичных сетей без протокола IP в общую сетевую инфраструктуру. Присутствие потоков DetNet не мешает другим потокам, а преимущества потоков DetNet в большинстве случаев не должны препятствовать нормальной работе имеющихся механизмов QoS5 если для потоков DetNet достаточно пропускной способности. Для одной пары отправитель-получатель могут поддерживаться потоки DetNet и иные потоки. Конечным системам и приложениям не требуются специальные интерфейсы для потоков DetNet. Сети не привязаны к определенным топологиям и типы подключений не ограничиваются. Любое приложение, генерирующее поток данных, который можно охарактерировать как имеющий ограниченную пропускную способность, должно иметь возможность использовать преимущества DetNet при условии резервирования требуемых ресурсов. Резервирование может организовать само приложение через управления сетью или централизованный контроллер приложений, а также иные средства, например, это можно сделать путем резервирования по запросу через распределенный уровень управления по протоколу RSVP6 [RFC2205]. Требования QoS для потоков DetNet могут быть выполнены, если все узлы сети в домене DetNet поддерживают возможности DetNet. Узлы DetNet могут соединяться с использованием разных технологий (4.1.2. Обзор уровня данных DetNet), при этом узлы подсетей могут не знать о DetNet (4.1.3. Модель эталонной сети).

Многие приложениям, рассчитанным на обслуживание DetNet, нужна возможность синхронизировать часы оконечных систем с микросекундной точностью. Некоторые методы управления очередями, определенные в разделе 4.5. Очереди, формирование, планирование и вытеснение трафика, также требуют синхронизации между узлами сети. Средства обеспечения такой синхронизации в этом документе не рассматриваются. DetNet может использовать разные методы синхронизации часов, определенные в других документах, для решения своих задач, диктуемых рынком.

2. Терминология

2.1. Используемые в документе термины

Ниже приведены определения терминов, используемых в этом документе.

allocation — выделение

Выделение ресурсов для поддержки потока DetNet. В зависимости от реализации ресурс может отдаваться за пределы DetNet, когда он не нужен потоку DetNet.

App-flow — поток приложений

Данные (payload), передаваемые через службы DetNet.

DetNet compound flow и DetNet member flow — составной поток DetNet и поток участника DetNet

Составным потоком DetNet называется поток DetNet, разделенный на несколько дубликатов потоков членов DetNet для защиты сервиса на подуровне службы DetNet. Потоки членов объединяются в один составной поток DetNet без дублирования пакетов. Понятия «составной поток» и «поток участника» не являются абсолютными. Составной поток DetNet, содержащий множество потоков членов DetNet, может быть включен в составной поток более высокого уровня.

DetNet destination — получатель DetNet

Конечная система, способная завершать поток DetNet.

DetNet domain — домен DetNet

Часть сети, поддерживающая DetNet. Включает конечные системы и узлы DetNet.

DetNet edge node — краевой узел DetNet

Экземпляр ретранслятора DetNet, выступающий в качестве источника и получателя на подуровне службы DetNet. Например, он может включать функцию прокси подуровня DetNet для защиты службы DetNet (добавление и удаление данных упорядочения пакетов) для одной или множества конечных систем, начинать или завершать выделение ресурсов на подуровне пересылки DetNet в новых потоках DetNet. Такой узел аналогичен маршрутизатору LER7 или PE8.

DetNet flow — поток DetNet

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

DetNet forwarding sub-layer — подуровень пересылки DetNet

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

DetNet intermediate node — промежуточный узел DetNet

Ретранслятор или промежуточный узел DetNet.

DetNet node — узел DetNet

Краевой узел, ретранслятор или промежуточный узел DetNet.

DetNet relay node — ретранслятор DetNet

Узел DetNet включающий функцию подуровня сервиса, которая соединяет разные пути пересылки DetNet для обеспечения защиты сервиса. Ретранслятор DetNet участвует в работе сервисного подуровня DetNet. Обычно он также включает функции подуровня пересылки DetNet и в этом случае совмещается с транзитным узлом.

DetNet service sub-layer — сервисный подуровень DetNet

Функциональность DetNet разделена на два подуровня. Одним из них является сервисный подуровень DetNet, обеспечивающий услуги DetNet (например, защиту сервиса).

DetNet service proxy — прокси службы DetNet

Посредник, обеспечивающий отображение между потоками приложений и потоками DetNet.

DetNet source — источник DetNet

Конечная система, способная создавать поток DetNet.

DetNet system — система DetNet (система)

Поддерживающая DetNet конечная система, промежуточный узел или ретранслятор.

DetNet transit node — транзитный узел DetNet

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

DetNet-UNI

Интерфейс пользователь-сеть (User-to-Network Interface — UNI) с функциональностью DetNet. Это опорная точка на уровне пакетов, способная выполнять функции инкапсуляции, синхронизации, поддержки состояния и т. п.

end system — оконечная система

Обычно называется хостом в документах RFC и оконечной станцией в стандартах IEEE 802. В этом документе рассматриваются оконечные системы, являющиеся отправителями или получателями потоков DetNet, которые могут (но не обязаны) поддерживать подуровни сервиса и пересылки DetNet.

link

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

Packet Elimination Function (PEF) — функция исключения дубликатов

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

Packet Replication Function (PRF) — функция репликации пакетов

Функция, реплицирующая пакеты потоков DetNet и пересылающая их на один или несколько следующих интервалов домена DetNet. Число пакетов, передаваемых на следующий интервал, являеся параметром потока DetNet в точке репликации. PRF можно реализовать на граничном узле, ретрансляторе или оконечной системе.

PREOF

Общее название функций репликации, исключения дубликатов и упорядочения.

Packet Ordering Function (POF) — функция упорядочения пакетов

Функция восстановления порядка пакетов в потоке DetNet, которая может быть реализована на граничном узле, ретрансляторе или оконечной системе DetNet.

reservation — резервирование

Набор ресурсов, выделяемых отправителю и одному или множеству получателей на узлах и подсетях, связанных с потоком DetNet для обеспечения сервиса DetNet.

2.2. Термины, используемые TSN и DetNet

Этот параграф служит словарем для перевода терминов, применяемых группой TSN [IEEE802.1TSNTG] в составе IEEE 802.1 WG, в термины рабочей группы WG в рамках IETF.

Listener — слушатель

Термин, используемый в IEEE 802.1, для получателей потоков DetNet.

Relay system — ретранслятор

Термин, используемый в IEEE 802.1, для промежуточных узлов DetNet.

Stream — поток

Термин, используемый в IEEE 802.1, для потоков DetNet.

Talker — “оратор”

Термин, используемый в IEEE 802.1, для источников потоков DetNet.

3. Обеспечение качества обслуживания в DetNet

3.1. Основные цели определения DetNet QoS

DetNet QoS можно выразить несколькими способами, указанными ниже.

  • Минимальная и максимальная сквозная задержка между отправителем и получателем, своевременная доставка и ограниченные вариации задержки.

  • Доля теряемых пакетов в разных условиях, связанных с рабочими состояниями узлов и каналов.

  • Верхняя граница нарушения порядка доставки пакетов. Здесь следует отметить, что некоторые приложения DetNet совсем не позволяют нарушать порядок доставки.

Отличительной чертой DetNet является работа исключительно с худшими вариантами сквозной задержки, ее вариаций и нарушения порядка доставки. Нормальные, усредненные и типовые значения малоинтересны, поскольку они не влияют на способность систем выполнять свои задачи в реальном масштабе времени. В общем случае тривиальная система управления очередями по приоритетам будет давать для потока данных лучшую среднюю задержку, нежели DetNet, однако она не подходит для DetNet при учете наибольшей задержки.

В DetNet используются три метода обеспечения качества обслуживания:

  • 3.2.1. Выделение ресурсов;

  • 3.2.2. Защита сервиса;

  • 3.2.3. Явные маршруты.

Выделение ресурсов происходит путем назначения ресурса (например, буферной емкости или пропускной способности канала) потоку или группе потоков DetNet по пути их следования. Выделение ресурсов существенно снижает или даже исключает потерю пакетов в результате конфликтов при передаче пакетов в сети, но применимо лишь к потоку DetNet, ограниченному у отправителя по размеру пакетов и скорости их передачи. Поскольку предполагается ограничение скорости потоков DetNet и предоставление в DetNet достаточных ресурсов (включая пропускную способность), применять контроль перегрузок на транспортном уровне [RFC2914] для потоков приложений (App-flow) не требуется, однако при подобающем выделении ресурсов контроль перегрузок не будет оказывать негативного влияния.

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

Другим важным вкладом в потерю пакетов являются случайные ошибки в среде и сбои в оборудовании. Защитой сервиса называются механизмы, используемые в DetNet для устранения таких потерь. Применяемые механизмы ограничены необходимостью выполнять требования пользователей к задержкам. В параграфах 3.2.2.2. Репликация и устранение копий и 3.2.2.3. Кодирование пакетов для защиты сервиса описаны два метода защиты сервиса, но могут применяться и другие механизмы. Например, может использоваться кодирование пакетов для защиты сервиса от случайных ошибок в среде, а репликация и устранение копий — для защиты от сбоев оборудования. Этот механизм распределяют потоки DetNet по нескольким путям в пространстве и/или времени, поэтому потеря некоторых путей не обязательно приведет к потере каких-либо пакетов.

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

Эти три метода могут применяться по отдельности или совместно. Возможно использование любой комбинации, включая полное отсутствие (без DetNet). Однако некоторые сочетания используются чаще. Такое разделение обеспечивает согласованность стека протоколов и максимальную совместимость с имеющимися и разрабатываемыми стандартами (в IETF и других органах стандартизации). Ниже приведено несколько примеров типовых сочетаний.

  • Комбинация явных маршрутов и защиты сервиса является методом организации бесшовной избыточности в кольцевой топологии, как описано в [IEC-62439-3]. В этом случае явные маршруты обеспечиваются за счет ограничения физической топологии сети кольцом. Упорядочение, репликация и устранение дубликатов обеспечиваются добавлением тегов в начале или в конце кадров Ethernet. В [RFC8227] представлен другой пример в контексте MPLS.

  • Выделение ресурсов в качестве единственного метода было предложено в IEEE 802.1 Audio Video Bridging [IEEE802.1BA]. Пока в сети не возникает отказов, потеря пакетов в результате конкуренции на выходе может быть устранена с помощью протокола резервирования (например, Multiple Stream Registration Protocol [IEEE802.1Q]), формирователей в каждом мосту и соблюдения нужных размеров.

  • Использование всех трех методов обеспечивает максимальную защиту.

Имеются и другие доступные (и развернутые) методы обеспечения приемлемой задержки и потери пакетов для многих приложений. К таким методам относится приоритизация и предоставление избыточных ресурсов (over-provisioning). Обгако такие методы лучше всего работают при отсутсвии в сети значимого объема некритичного трафика (если такой трафик поддерживается). Они могут работать лишь в тех случаях когда критичный к задержкам и потерям трафик составляет малую часть от теоретической пропускной способности сети, все системы работают корректно и нет конечных систем, действия которых нарушают работу сети.

Определено, применяется или разрабатывается много механизмов реализации каждого из отмеченных выше методов. Предполагается, что определенная здесь архитектура DetNet поможет производителям пользователям и «вертикальным» органам стандартизации (отраслевым) сделать выбор между доступными реализациями сетей DetNet.

3.2. Механизмы обеспечения DetNet QoS

3.2.1. Выделение ресурсов

3.2.1.1. Устранение потерь в результате конкуренции

Основным способом достижения гарантий QoS в DetNet является снижение или даже полное устранение потери пакетов в результате конкуренции в выходных очередях на узлах DetNet. Это можно реализовать лишь обеспечением достаточного объема буферов, чтобы пакеты не терялись в результате нехватки буферной емкости. Отметим, что в общем случае не предполагается реакция потоков приложений на неявные [RFC2914] или явные [RFC3168] уведомления о перегрузке.

Обеспечение адекватной буферизации требует от отправителя и каждого узла в пути DetNet к получателю (почти кажый узел, см. параграф 4.3.3) аккуратного регулирования своего вывода, чтобы не превышалась скорость для каждого потока DetNet за исключением кратких периодов сочетания с мешающим трафиком. Любой пакет, отправленный раньше времени, может добавлять объем буферов, требуемых на следующем узле DetNet, что может приводить к выходу за предел выделенных отдельному потоку DetNet ресурсов. Кроме того, на входе в домен DetNet должны применяться функции ограничения скорости (например, правила для трафика) и механизмы формовки (например, [RFC2475]). Это нужно для соблюдения требований DetNet, а также защиты остального (не DetNet) трафика от некорректно работающих источников трафика DetNet. Отметим, что большие буферы создают некоторые проблемы (см. например, [BUFFERBLOAT]).

Описанные в параграфе 4.5 механизмы нижних уровней обеспечивают требуемое регулирование передачи в конечных системах или узлах DetNet с учетом выделения ресурсов. Выделенную для потока DetNet пропускную способность или буферы требуется обеспечить. Узел DetNet может иметь другие ресурсы требующие выделения и/или планирования, которые могут быть без этого перегружены и вызывать отказ при резервировании.

3.2.1.2. Снижение вариаций задержки

Основной целью DetNet является обеспечение возможности сведения отличных от IP сетей с критичными (sensitive) приложениями в единую сетевую инфраструктуру. Это требует аккуратной эмуляции развернутых в настоящее время под конкретные задачи сетей, которые основаны, например, на аналоговых (к примеру, с модуляцией 4 — 20 мА) и цифровых последовательных линиях (или шинах) для обеспечения надежных, синхронизированных коммуникаций без вариации задержек. Хотя задержка аналоговой передачи определяется в основном скоростью света, традиционные последовательные каналы обычно медленны (кбит/с) по сравнению с Gigabit Ethernet, а некоторая задержка как правило допустима. А вот чрезмерные вариации задержки могут влиять на стабильность систем управления.

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

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

  • Поле времени выполнения в пакетах приложений.

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

3.2.2. Защита сервиса

Защита сервиса нацелена на снижение или предотвращение потери пакетов в результате отказов оборудования, включая случайные ошибки в среде передачи и/или памяти. Такие потери можно существенно сократить за счет распределения данных по множеству не связанных между собой путей пересылки. В [RFC6372] описаны различные методы защиты сервиса, например, линейная защита 1+1. Функциональные детали дополнительного метода описаны в параграфе 3.2.2.2 и могут быть реализованы в соответствии с параграфом 3.2.2.3 or или [DETNET-MPLS] для обеспечения защиты 1+n. Выбор механизмов защиты сервиса зависит от сценария и требований.

3.2.2.1. Упорядоченная доставка

Побочным эффектом защиты сервиса может быть нарушение порядка доставки. Нарушение порядка доставки повышает требования к буферизации пакетов на приемной стороне для корректной обработки данных. Такие пакеты также влияют на вариации задержки в потоке. Гарантии сервиса DetNet включают максимальное сохранение порядка доставки в качестве ограничения. Отсутствие нарушений порядка было бы действительным ограничением, отражающим неприемлемость нарушения для конечных систем. Для сохранения порядка доставки в DetNet может применяться функция POF (3.2.2.2. Репликация и устранение копий).

3.2.2.2. Репликация и устранение копий

В этом параграфе описан метод защиты сервиса за счет передачи копий пакета по нескольким путям.

Подуровень сервиса DetNet включает функции PRF, PEF и POF для использования в ретрансляторах, краевых и оконечных устройствах DetNet при обработке пакетов. Эти функции могут быть включены на ретрансляторах, краевых и оконечных устройствах DetNet. Все эти функции обозначают общим термином PREOF. Метод защиты сервиса за счет репликации и устранения копий пакетов включает четыре возможности, указанные ниже.

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

  • PRF реплицирует пакеты в несколько потоков участников DetNet и обычно передает их по разным путям к получателю, например, с помощью явных маршрутов, описанных в параграфе 3.2.3. Место и механизм использования PRF внутри узла DetNet определяется реализацией.

  • PEF устраняет дубликаты пакетов потока DetNet на основе данных о порядке и истории приема пакетов. На выходе PEF всегда остается один пакет. Операция может выполняться любым узлом DetNet в пути для экономии сетевых ресурсов в нисходящем направлении, особенно при наличии нескольких точек репликации. Но обычно это происходит на самом краю сети DetNet, предпочтительно вблизи получателя. Место и механизм использования PEF внутри узла DetNet определяется реализацией.

  • POF использует информацию о порядке для восстановления нарушенного порядка пакетов в потоке DetNet.

Порядок применения узлом DetNet функций PEF, POF и PRF к потоку DetNet определяется реализацией.

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

В простейшем случае это эквивалентно 1) репликации каждого пакета у отправителя с двумя интерфейсами и 2) передача их через сеть по разным путям (разделение SRLG10) к похожим двудомным получателям, которые 3) восстанавливают порядок пакетов и 4) отбрасывают дубликаты. Это обеспечивает сохранение одного пути даже при отказе некоторых промежуточных узлов DetNet. Информация о порядке служит также для обнаружения потерь.

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

Это показано на рисунке 1, где два ретранслятора реплицируют (R) потоки DetNet на входе, передают потоки членов DetNet другому ретранслятору и конечной системе, а также устраняют дубликаты (E) на выходном интерфейсе в сторону конечной системы справа. При отказе любого канала в сети составной поток DetNet сохраняется. Кроме того, обеспечивается работа при отказе двух каналов, если они размещены в разных сегментах сети.

              > > > > > > > ретранслятор > > > > > > >
             > /------------+ R узел E +------------\ >
            > /                  v + ^               \ >
Конечная   R +                   v | ^                + E Конечная
система      +                   v | ^                +   система
            > \                  v + ^               / >
             > \---------+ R ретранслятор E +-------/ >
              > > > > > > > > >  узел  > > > > > > > >

Рисунок 1. Репликация и исключение потоков.


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

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

3.2.2.3. Кодирование пакетов для защиты сервиса

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

3.2.3. Явные маршруты

В сетях, управляемых типичными протоклами динамической маршрутизации, такими как IS-IS или OSPF, события в сетевой топологии той или иной части сети могут, по меньшей мере в течение короткого времени, влиять на доставку данных в участках сети, удаленных от точки отказа или восстановления. Даже использование резервных путей через сеть (например, как определено в [RFC6372]) не устраняет вероятность потери пакетов. Кроме того, побочным эффектом изменения маршрутов может быть нарушение порядка доставки.

Многие сети, работающие в реальном масштабе времени, основаны на кольце из двухпортовых устройств с относительно простым протоколом управления кольцом. Это обеспечивает резервирование пути для защиты сервиса с минимальным числом проводов. Дополнительным преимуществом кольцевой топологии часто является возможность использования протоколов управления, отличающихся от применяемых в многосвязных (mesh) сетях и соответствующее сокращение времени отклика на изменение топологии. Недостатком кольцевой топологии является большее число этапов пересылки (hop) и соответствующий рост задержки на типичном пути.

Для получения преимуществ малого числа этапов пересылки вместе с защитой даже от очень коротких перебоев в связи DetNet использует явные маршруты, где путь данного потока DetNet не меняется сразу и может не измениться совсем в результате событий смены топологии. Защита сервиса (параграфы 3.2.2 и 3.2.2.3) при явных маршрутах обеспечивает высокую вероятность сохранения непрерывной связности. Явные маршруты можно создавать разными способами, например, с помощью RSVP-TE [RFC3209], SR11 [RFC8402], SDN [RFC8453], IS-IS [RFC7813] и т. п. Явные маршруты обычно применяются в MPLS TE12 LSP13.

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

3.3. Дополнительные цели DetNet

Многие приложения требуют от DetNet предоставления дополнительных услуг, включая использование других механизмов QoS (3.3.1. Сосуществование с обычным трафиком) и защиту от некорректно работающих передатчиков (3.3.2. Устранение отказов).

3.3.1. Сосуществование с обычным трафиком

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

  • Пропускная спопобность (возможность передачи), не занятая потоками DetNet, доступна для прочих пакетов.

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

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

Следует избегать подавления трафика, не относящегося к DetNet, например, с помощью правил или формовки трафика (например, [RFC2475]). Таким образом, финальным эффектом наличия в сети потоков DetNet будет в основном уменьшение пропускной способности, доступной для другого трафика.

3.3.2. Устранение отказов

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

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

Отметим, что передача потоков приложений, не применяющих контроль перегрузок на транспортном уровне в соответствии с [RFC2914], в сеть, не подготовленную для обработки такого трафика, должна считаться сбоем и пресекаться. Созданные функцией PRF потоки участников DetNet должны считаться не использующими контроль перегрузок на транспортном уровне даже при наличии такого контроля в исходных потоках приложений, поскольку PREOF может удалять индикацию перегрузки в функции PEF (например, отбрасывание, маркеры ECN, рост задержки).

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

4. Архитектура DetNet

4.1. Модель стека DetNet

Функции DetNet (раздел 3. Обеспечение качества обслуживания в DetNet) реализованы на двух смежных подуровнях стека протоколов — сервис DetNet и пересылка DetNet. Подуровень сервиса предоставляет услуги DetNet (например, защиту сервиса) вышележащему уровню стека и приложениям. Подуровень пересылки поддерживает услуги DetNet в базовой сети, например, путем предоставления явных маршрутов и резервирования ресурсов для потоков DetNet.

4.1.1. Представление модели стека протоколов

Нарисунке 2 представлена концептуальная модель уровней плоскости данных DetNet. Можно сравнить ее с моделью из [IEEE802.1CB], Annex C.

   |Пакет, проходящий|        ^ Пакет, проходящий ^
   v  вниз по стеку  v        |  вверх по стеку   |
+-----------------------+   +-----------------------+
|       Источник        |   |      Получатель       |
+-----------------------+   +-----------------------+
|   Подуровень сервиса: |   | Подуровень сервиса:   |
|   Упорядочение пакетов|   | Исключение дубликатов |
|   Репликация потоков  |   | Слияние потоков       |
|   Кодирование пакетов |   | Декодирование пакетов |
+-----------------------+   +-----------------------+
| Подуровень пересылки: |   | Подуровень пересылки: |
| Выделение ресурсов    |   | Выделение ресурсов    |
| Явные маршруты        |   | Явные маршруты        |
+-----------------------+   +-----------------------+
|     Нижние уровни     |   |     Нижние уровни     |
+-----------------------+   +-----------------------+
            v                           ^
             \_________________________/

Рисунок 2. Стек протоколов плоскости данных DetNet.


Для данного приложения и даже сети могут требоваться не все подуровни из числа перечисленных ниже.

Application — приложение

На рисунке приложения показаны как отправитель и получатель.

Packet sequencing — упорядочение пакетов

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

Duplicate elimination — исключение дубликатов

Как часть сервисного подуровня DetNet, отбрасывает все дубликаты пакетов на основе порядковых номеров, представленных партнером (упорядочение пакетов) для репликации потоков DetNet. Подуровень может работать с потоками членов и составными потоками. Репликация может также работать на основе точного времени приема в сети с планированием. Подуровень устранения дубликатов может также восстанавливать порядок пакетов в потоке, нарушенный потерей пакетов в одном из множества путей потока.

Flow replication — репликация потоков

Как часть защиты сервиса DetNet, пакеты, относящиеся к составному потоку DetNet, реплицируются в два или более потоков участиника DetNet. Эта функция отделена от упорядочения пакетов. Репликация потока может быть явной репликацией и перемаркировкой или выполняться, например, на основе методов, похожих на обычную групповую репликацию с последующим выделением ресурсов. Партнером является подуровень слияния потоков.

Flow merging — слияние потоков

Как часть сервисного подуровня DetNet, функция слияния потоков объединяет потоки членов DetNet для поднимающихся по стеку пакетов, относящихся к конкретному составному потоку DetNet. Слияние потоков DetNet вместе с подуровнями упорядочениям пакетов, устранения дубликатов и репликации потоков DetNet обеспечивает репликацию и устранение дубликатов (3.2.2. Защита сервиса). Партнером является подуровень репликации.

Packet encoding — кодирование пакетов

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

Packet decoding — декодирование пакетов

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

Resource allocation — выделение ресурсов

Подуровень пересылки DetNet обеспечивает выделение ресурсов (4.5. Очереди, формирование, планирование и вытеснение трафика). Используемые механизмы очередей и формовки трафика обычно предоставляются базовой сетью. Они могут быть тесно связаны со способами предоставления путей для потоков DetNet. На рисунке выделение путей и ресурсов объединено.

Explicit routes — явные маршруты

Явные маршруты являются фиксированными путями, работающими на подуровне пересылки DetNet и определяемыми заранее для предотвращений воздействий схождения сетей (маршрутов) на потоки DetNet.

Функции OAM15 используют сигнализацию в основной полосе или по отдельному каналу для проверки эффективности обеспечения параметров QoS. Функции OAM не показаны на рисунке 2 и могут размещаться на разных уровнях. OAM может включать специальные теги, добавляемые в пакеты для трассировки ошибок реализации или настройки сети, что позволяет определить пакеты, являющиеся репликами, найти ретранляторы DetNet, выполняющие репликацию, и определить сегмент, предназначенный для реплики. Активные и гибридные методы OAM требуют дополнительного расхода полосы для контроля отказов и мониторинга производительности в домене DetNet. Например, OAM может генерировать специальные тестовые зонды или добавлять свою информацию в пакеты данных.

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

4.1.2. Обзор уровня данных DetNet

«Детерминированные сети» организуются из поддерживающих DetNet конечных систем, краевых узлов и ретрансляторов DetNet, которые совместно предоставляют услуги DetNet. Ретрансляторы и краевые узлы DetNet соединены можду собой транзитными узлами DetNet (например, LSR), которые поддерживают DetNet, но не обеспечивают услуг DetNet. Все узлы DetNet подключаются к подсетям, при этом канал «точка-точка» считается вырожденной подсетью. Эти подсети обеспечивают совместимые с DetNet услуги для поддержки трафика DetNet. Примерами технологий подсетей являются MPLS TE, IEEE 802.1 TSN и OTN16. Возможны многоуровневые системы DetNet, где одна подсеть DetNet предоставляет услуги системе DetNet более высокого уровня. Простая концептуальная сеть DetNet показана на рисунке 3. Отметим, что на этом и последующих рисунках «Пересылка» и Fwd относятся к подуровню пересылки DetNet, а «сервис» и Svc — к подуровню сервиса DetNet (4.1.1. Представление модели стека протоколов).

Оконечная       Краевой      Транзитный     Ретранслятор    Оконечная
система TSN       узел          узел                   система DetNet
+----------+   +.........+                               +----------+
|Приложение|<--:Svc Proxy:--  Сквозной сервис   -------->|Приложение|
+----------+   +---------+                 +---------+   +----------+
|   TSN    |   |TSN| |Svc|<- поток DetNet--: Сервис  :-->| Сервис   |
+----------+   +---+ +---+   +--------+    +---------+   +----------+
|Пересылка |   |Fwd| |Fwd|   |  Fwd   |    |Fwd| |Fwd|   |Пересылка |
+-------.--+   +-.-+ +-.-+   +--.----.+    +-.-+ +-.-+   +---.------+
        : Канал  :    /  ,-----. \   : Канал :    /  ,-----.  \
        +........+    +-[Подсеть]-+  +.......+    +-[Подсеть]-+
                         `-----'                     `-----'

Рисунок 3. Простая сеть с поддержкой DetNet.


Уровень данных DetNet разделен на два подуровня — сервис DetNet и пересылка DetNet. Это помогает изучать и оценивать разные комбинации доступных решений на уровне данных, некоторы из них показаны на рисунке 4. Это разделение на подуровни DetNet полезно, но не является формальным требованием. Некоторые технологии могут предоставлять услуги DetNet без выделения этих уровней.

              .
              .
+-----------------------------+
| Сервисный подуровень DetNet | PW, UDP, GRE
+-----------------------------+
| Подуровень пересылки DetNet | IPv6, IPv4, MPLS TE LSPs, MPLS SR
+-----------------------------+
              .
              .

Рисунок 4. Адаптация DetNet к уровню данных.


В некоторых сетях конечные системы исходно обеспечивают инкапсуляцию потоков DetNet со всей информацией, нужной узлам DetNet (например, потоки DetNet на основе протокола RTP17 [RFC3550], передаваемые через сети UDP/IP или псевдопровода PW18). В иных случаях формат инкапсуляции может существенно отличаться.

Имеется много вариантов организации уровня данных для трафика DetNet за счет выбора технологического решения для подуровня сервиса DetNet service sub-layer и подуровня пересылки DetNet. Число таких комбинаций велико.

Одним из основных различий между уровнями данных являются базовые заголовки, используемые узлами DetNet. Например, базовый сервис может предоставляться на основе меток MPLS или заголовков IP. Этот выбор влияет на базовую логику пересылки для подуровня сервиса DetNet. Отметим, что в обоих случаях для адресации узлов DetNet служат IP-адреса. Выбранная для подуровня пересылки DetNet технология тоже должна отображаться не технологию подсети, соединяющей узлы DetNet. Например, потоки DetNet могут отображаться на потоки TSN.

4.1.3. Модель эталонной сети

На рисунке 5 дано другое представление связанных с сервисом DetNet эталонных точек и основных компонентов.

Интерфейры DetNet-UNI (U на рисунке 5) в этом документе считаются опорными точками для пакетов и обеспечивают соединение с пакетной сетью. Интерфейс DetNet-UNI вожет обеспечивать множество функций, включая:

  • инкапсуляцию потоков DetNet в соответствии с сетевой технологией;

  • предоставлять статус доступности ресурсов для их резервирования;

  • предоставлять услуги синхронизации для конечных систем;

  • поддерживать сигнализацию для организации резервирования в сети без контроллера или с использованием контроллера, работающего лишь с сетью, а не с конечными системами.

Конечная система                                     Конечная система
DetNet                                                         DetNet
   _                                                             _
  / \     +----DetNet-UNI (U)                                   / \
 /App\    |                                                    /App\
/-----\   |                                                   /-----\
| NIC |   v         ________                                  | NIC |
+--+--+   _____    /        \             DetNet-UNI (U) --+  +--+--+
   |     /     \__/          \                             |     |
   |    / +----+    +----+    \_____                       |     |
   |   /  |    |    |    |          \_______               |     |
   +------U PE +----+ P  +----+             \          _   v     |
       |  |    |    |    |    |              |     ___/ \        |
       |  +--+-+    +----+    |       +----+ |    /      \_      |
       \     |                |       |    | |   /         \     |
        \    |   +----+    +--+-+  +--+PE  |------         U-----+
         \   |   |    |    |    |  |  |    | |   \_      _/
          \  +---+ P  +----+ P  +--+  +----+ |     \____/
           \___  |    |    |    |           /
               \ +----+__  +----+     DetNet-1    DetNet-2
   |            \_____/  \___________/                           |
   |                                                             |
   |      |    Сквозное обслуживание       |     |         |     |
   <------------------------------------------------------------->
   |      |     Сервис DetNet              |     |         |     |
   |      <------------------------------------------------>     |
   |      |                                |     |         |     |

Рисунок 5. Эталонная модель сервиса DetNet (многодоменная).


Внутренние опорные конечных систем (между приложением App и NIC19) более сложны с точки зрения управления и могут предъявлять дополнительные требования (например, предполагать упорядоченную доставку во внутренние опорные точки, где не обязательно такая доставка через DetNet-UNI).

4.2. Системы DetNet

4.2.1. Оконечные системы

Трафик потока приложения может иметь тип CBR (постоянная скорость) или VBR (переменная скорость) и может иметь инкапсуляцию L1, L2 или L3 (наприем, TDM20, Ethernet, IP). Эти характеристики являются входными данными для резервирования ресурсов и могут быть упрощены для обеспечения детерминизма при пересылке пакетов (например, резервирование для пиковой скорости трафика VBR и т. п.).

Конечная система может не знать о подуровне пересылки DetNet или подуровне сервиса DetNet. Т. е. конечная система может не включать относящихся к DetNet функций. Системы с функциональностью DetNet в домене DetNet могут применять один или разные подуровни пересылки. Категории конечных систем показаны на рисунке 6.

          Конечная система
                 |
                 |
                 |  DetNet поддерживается?
                / \
        +------<   >------+
    нет |       \ /       | да
        |        v        |
 Конечная система,        |
 не понимающая DetNet     |
                          | Подуровни сервиса и
                          | пересылки 
                         / \  поддерживаются?
               +--------<   >-------------+
Поддерживается |         \ /              | Поддерживается
пересылка      |          v               | сервис
               |          | Поддерживаются|
               |          | оба           |
       Конечная система   |         Конечная система
       с пересылкой DetNet|         с сервисом  DetNet
                          v
                    Конечная система
                    с пересылкой и сервисом

Рисунок 6. Категории конечных систем.


Ниже перечислены примеры известных конечных систем.

DetNet unaware — без поддержки DetNet

Классический вариант, требующий промежуточное устройство (прокси).

DetNet f-aware — с поддержкой пересылки DetNet

Система, которая знает о подуровне пересылки DetNet. Ей известны некоторые функции TSN (например, незервирование), но неизвестно о защите сервиса.

DetNet s-aware — с поддержкой сервиса DetNet

Система, которая знает о подуровне сервиса DetNet. Она предоставляет порядковые номера, но не знает о выделении ресурсов.

DetNet sf-aware — с поддержкой пересылки и сервиса DetNet

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

4.2.2. Ретрансляторы, краевые и транзитные узлы DetNet

Как показано на рисунке 3, краевые узлы DetNet служат посредниками (proxy), ретрансляторы DetNet, обеспечивающие подуровень сервиса DetNet, знают об DetNet, а транзитным узлам DetNet нужно знать лишь о подуровне пересылки.

В общем случае поток DetNet проходит через одну или множество узлов, не знающих о DetNet, между двумя узлами DetNet, обеспечивающими подуровень пересылки DetNet для этого потока. Здесь могут возникать нарушения или отказы DetNet QoS. Администраторы сетей должны 1) обеспечить настройку не знающих о DetNet узлов для минимизации потери и задержки пакетов, а также 2) предоставить достаточное буферное пространство на транзитных узлах DetNet, которые следуют за узлами, не поддерживающими DetNet, для компенсации вариций задержки.

4.3. Потоки DetNet

4.3.1. Типы потоков DetNet

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

App-flow — поток приложения

Данные, передаваемые в потоке DetNet между двумя не знающими о DetNet конечными системами. App-flow не включает связанных с DetNet атрибутов и не задает специфических требований к узлам DetNet.

DetNet-f-flow — поток, знающий о пересылке

Конкретный формат потока DetNet, требующий выделения ресурсов от подуровня пересылки DetNet.

DetNet-s-flow — поток, знающий о сервисе

Конкретный формат потока DetNet, требующий защиты сервиса от подуровня сервиса DetNet.

DetNet-sf-flow — поток, знающий о пересылке и сервисе

Конкретный формат потока DetNet, требующий функции подуровней пересылки и сервиса DetNet при пересылке.

4.3.2. Поведение источника передачи

В плане выделения ресурсов поток DetNet может быть синхронным или асинхронным. В синхронных потоках DetNet по меньшей мере узлы DetNet (возможно и конечные системы) синхронизированы (обычно с точностью не хуже 1 мксек). За счет передачи разных потоков или классов потоков DetNet в разное время с использованием повторяющихся расписаний на синхронизированных узлах DetNet, ресурсы (такие как буферы и пропускную способность) можно совместно использовать для разных потоков DetNet. Для синхронных потоков DetNet имеется компромисс между точным планированием и уменьшением потребных ресурсов (особенно буферов).

Асинхронные потоки DetNet не скоординированы с точным расписанием, поэтому ретрансляторы и конечные системы должны предполагать худший вариант взаимодействия разных потоков DetNet при использовании буферных ресурсов. Асинхронные потоки DetNet характеризуются:

  • максимальным размером пакетов;

  • интервалом наблюдения;

  • максимальным числом передач в течение интервала наблюдения.

Эти параметры вместе с информацией о применяемом стеке протоколов (и размере добавляемых в пакет заголовков) позволяют определить пропускную способность, требуемую для потока DetNet.

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

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

Хотя DetNet стремится минимизировать изменения, которые нужно внести в приложения для перехода от цифровых сетей специального назначения к сетям IP, не удается избавиться от необходимости выделения ресурсов до запуска приложения. Во-первых, сеть не может обеспечить конечную задержку и практически нулевую потерю пакетов при произвольно высоком уровне загрузки. Во-вторых, для достижения практически нулевой потери пакетов в потоках DetNet узлам DetNet требуются выделенные буферы для конкретных потоков или классов потоков DetNet. Требования каждого резервирования должны преобразовываться в параметры, управляющие в каждой системе DetNet очередями, формовкой и планированием трафика, которые должны быть распространены между узлами и конечными системами.

Предполагается, что все узлы в домене DetNet будут обеспечивать поведение, требуемое для предоставления конкретного сервиса DetNet. Если сам узел не знает о сервисе DetNet, смежные с ним узлы DetNet должны обеспечить ему подобающую поддержку сервиса DetNet. Например, узел TSN (как определено в IEEE 802.1) можно использовать для соединения узлов DetNet и эти узлы могут отображать потоки DetNet на потоки 802.1 TSN. Другим примером является домен MPLS-TE или MPLS-TP21, используемый для соединения узлов DetNet, которые могут отображать потоки DetNet на TE LSP, обеспечивающие требования QoS для сервиса DetNet.

4.3.3. Неполные сети

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

4.4. Организация трафика для DetNet

TEAS22 [TEAS] определяет архитектуру организаци трафика, применимую для пакетных и иных сетей. С точки зрения TEAS организацией трафика (TE23) считаются методы, позволяющие операторам управлять обработкой определенных потоков трафика в своих сетях.

Благодаря созданию явных оптимизированных путей, DetNet можно считать новой, специализированной ветвью TE, наследующей архитектуру с разделением по плоскостям (уровням). Архитектура DetNet включает три плоскости — (пользовательские) приложения, контроллер и сеть. Это похоже на уровни, приведенные на рисунке 1 в Software-Defined Networking (SDN): Layers and Architecture Terminology [RFC7426], и контроллеры из [RFC8453] и [RFC7149].

4.4.1. Плоскость приложений

В соответствии [RFC7426] плоскость приложений включает приложения и службы. В частности, здесь присутствует пользовательский агент — специализированное приложение, взаимодействующее с конечным пользователем и оператором для запроса услуг DetNet с помощью элемента управления потоком (FME24), который может размещаться в одной из конечных систем.

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

4.4.2. Плоскость контроллера

Плоскость контроллера соответствует плоскостям Control и Management в [RFC7426], хотя CCAMP26 (в соответствии с определением рабочей группы CCAMP [CCAMP]) задает дополнительное различие между управлением и измерениями. Когда различие между элементами управления, измерений и другими объектами управления (Management) не существенно, для упрощения применяется термин «плоскость контроллера» (представляет все), а CPF27 указывает любое устройство, работающее в этой плоскости, будь то PCE28 [RFC4655], NME29 или протокол распределенного управления. CPF является основным элементом контроллера, отвечающим за расчет детерминированных путей, применяемых в сетевой плоскости.

(Северный) интерфейс сервиса позволяет приложениям из прикладной плоскости взаимодействовать с объектами плоскости контроллера, как показано на рисунке 7.

Несколько CPF могут действовать совместно для реализации запросов от FME как поведения на уровне потока или интервала (hop), задаваемого на узлах DetNet для каждого отдельного потока. CPF размещают каждый поток через детерминированный набор узлов DetNet, чтобы выполнить ограничения на уровне потоков (такие как защита и задержки) и оптимизировать общий результат по таким показателям, как абстрактная агрегированная стоимость. Детерминированная структура обычно слложней прямого назначения и включает резервные пути с одной или несколькими точками репликации и устранения дубликатов. Большие сети рассматриваются в параграфе 4.9.

4.4.3. Плоскость сети

Плоскость сети представляет сетевые устройства и протоколы в целом, независимо от уровня, на котором работают устройства. Плоскость включает уровни (плоскости) данных и операций (например, OAM).

Конечная                                             Конечная
система                                               система

-+-+-+-+-+-+-+ Северная граница -+-+-+-+-+-+-+-+-+-+-+-+-+-+-

          CPF         CPF              CPF              CPF

-+-+-+-+-+-+-+ Южная граница +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

             Узел       Узел       Узел       Узел
            DetNet     DetNet     DetNet     DetNet
 NIC                                                     NIC
            Узел       Узел       Узел       Узел
           DetNet     DetNet     DetNet     DetNet

Рисунок 7. Интерфейсы северной и южной границы.


Плоскость сети включает сетевые адаптеры (NIC) в оконечных системах, которые обычно являются хостами IP, и узлах DetNet, которыми обычно служат маршрутизаторы IP и коммутаторы MPLS.

Южный (сетевой) интерфейс позволяет объектам плоскости контроллера взаимодействовать с устройствами в плоскости сети, как показано на рисунке 7. Этот интерфейс использует и расширяет TEAS для описания физической топологии и ресурсов в плоскости сети.

Узлы DetNet (и, возможно, сетевые адаптеры конечных систем) раскрывают свои возможности и физические ресурсы контроллеру (CPF) и обновляют CPF своим динамическим восприятием топологии через южный интерфейс. В ответ CPF организуют пути на уровне потоков, обеспечивая характеризацию потока, которая более тесно связана с работой узла DetNet, нежели Tspec.

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

В этом документе основное внимание уделено южному интерфейсу и сетевой плоскости.

4.5. Очереди, формирование, планирование и вытеснение трафика

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

Стандартные алгоритмы организации очередей и выбора передачи позволяют TE (4.4. Организация трафика для DetNet) рассчитать вклад задержки на каждом узле в общую задержку DetNet, размер буферов на каждом узле DetNet для каждого инкрементного потока DetNet, а также, что более важно, преобразовать спецификацию потока в набор значений для объектов управления на каждом ретрансляторе и конечной системе. Например, рабочая группа IEEE 802.1 задала набор алгоритмов очередей, формовки и планирования, позволяющий каждому узлу DetNet и/или центральному контроллеру рассчитать эти значения. Эти алгоритмы включают:

  • формовщик на основе кредитов [IEEE802.1Qav] (включен в [IEEE802.1Q]);

  • очереди с ограничением по времени и чередующимся расписанием на основе синхронизированных часов [IEEE802.1Qbv] (включен в [IEEE802.1Q]);

  • синхронизированные двойные (или тройные) буферы, управляемые синхронизированными часами [IEEE802.1Qch] (включен в [IEEE802.1Q]);

  • вытеснение передачи пакетов Ethernet пакетами с более строгими требованиями к задержке [IEEE802.1Qbu] (включен в [IEEE802.1Q]) [IEEE802.3br] (включен в [IEEE802.3]).

Хотя эти методы в настоящее время включены лишь в стандарты Ethernet [IEEE802.3] и мостов, следует отметить, что они (за исключением, возможно, вытеснения пакетов) применимы к средам иных типов, а также к маршрутизаторам. В других средах могут применяться свои методы (например, [TSCH-ARCH] и [RFC7554]). В IETF разработаны свои методы (например, [RFC8289] и [RFC8033]). DetNet может включить эти определения в будущем и описать их применение на узлах DetNet.

4.6. Экземпляр сервиса

Экземпляр сервиса представляет все функции, требуемые на узле DetNet для организации сквозного сервиса между UNI.

Эталонная модель сети DetNet показана на рисунке 8 для сценария сервиса DetNet (т. е. между парой DetNet-UNI). На рисунке конечные системы (A и B) подключены напрямую к граничным узлам сети IP/MPLS (PE1 и PE2). Для конечных систем, участвующих в коммуникациях DetNet, подключение может потребоваться до организации потока приложения, которому нужны услуги DetNet. Такой экземпляр сервиса, относящийся к подключению, и экземпляр, выделенный для сервиса DetNet, используют общий доступ. Пакеты, относящиеся к потоку DetNet, выбираются фильтром, настроенным для доступа (F1 и F2). В результате связанный с потоком доступ (Доступ-A + F1 и Доступ-B + F2) завершается в связанном с потоком экземпляре сервиса (SI-1 и SI-2). Туннель обеспечивает связность экземпляров.

             Доступ-A                                     Доступ-B
              <----->    <-------- Туннель --------->     <----->

                 +---------+        ___  _        +---------+
 Конечная система|  +----+ |       /   \/ \_      | +----+  | Конечная система
       "A" -------F1+    | |      /   Сеть  \     | |    +F2----- "B"
                 |  |    +========+ IP/MPLS +=======+    |  |
                 |  |SI-1| |      \__      _/     | |SI-2|  |
                 |  +----+ |         \____/       | +----+  |
                 |PE1      |                      |      PE2|
                 +---------+                      +---------+

Рисунок 8. Эталонная модель сети DetNet.


Туннель используется исключительно для пакетов потока DetNet между SI-1 и SI-2. Экземпляры сервиса настроены на реализацию функций DetNet и связанной с потоком пересылки DetNet. Экземпляры и туннель могут поддерживать несколько потоков DetNet. Для совместного использования экземпляра сервиса несколькими потоками нужно соответственно заполнить таблицы пересылки этих экземпляров.

Туннель может иметь особые свойства. Например, для сервиса DetNet L3 имеются отличия использования PW для трафика DetNet от модели, описанной в [RFC6658]. В варианте DetNet PW служит лишь для потока DetNet, тогда как в [RFC6658] сказано:

Пакетный PW выглядит для клиентского уровня как один канал «точка-точка». Организация и поддержка смежности на сетевом уровне между клиентскими устройствами будет следовать обычной практике поддержки нужных отношений на уровне клиентов.

и

Этот пакетный псевдопровод используется для транспортировки всех протоколов L2 и L3 между LSR1 и LSR2.

Further details are network technology specific and can be found in [DETNET-FRAMEWORK].

4.7. Идентификация потоков на границах технологии

В этом разделе описаны действия, которые нужно выполнять на границах технологий, включая Ethernet как одну из них. Идентификация потоков для плоскостей данных MPLS и IP описана в [DETNET-MPLS] и [DETNET-IP].

4.7.1. Экспорт идентификации потоков

Узлу DetNet может потребоваться отобразить конкретные потоки на потоки нижележащих уровней (Stream) для обеспечения требуемых услуг по управлению учередями и формовке трафика.

  • Конечная система-источник L2 (не IP) X может передавать множество потоков другой конечной системе L2 Y. Эти потоки могут включати потоки DetNet с разными требованиями QoS, а также потоки иного трафика.

  • Маршрутизатор может передавать любое число потоков другому маршрутизатору. Здесь также могут быть потоки DetNet с разными требованиями QoS и потоки, не относящиеся к DetNet.

  • Два маршрутизатора могут быть разделены мостами. Чтобы мосты могли организовать очереди и формовку на уровне потоков, ин нужно идентифицировать отдельные потоки.

  • Маршрутизатор LER может иметь LSP для обслуживания трафика, направленного по конкретному адресу IP и содержащего лишь не относящиеся к DetNet потоки. При запросе потока DetNet в тот же адрес может потребоваться отдельный LSP, чтобы все маршрутизаторы LSR в пути к получателю обеспечили нужные очереди и формовку трафикаs) along the path to the destination to give that flow special queuing and shaping.

Необходимость информирования нижележащих уровней о потоках не уникальна для DetNet. Но с учетом сложности уровней и ретрансляции через туннели, доступных разработчикам, в DetNet требуется модель идентификации потоков, которая лучше просмотра пакетов. Это не означает, что не будет применяться просмотр пакетов на уровне L4 или L5 или возможность стандартизована, однако имеются варианты.

Ретранслятор DetNet может направлять потоки DetNet по разным путям используя разные методы идентификации.

  • Одиночному потоку DetNet от маршрутизатора A, проходящему черед сеть мостов в маршрутизатор B можно назначить идентификатор TSN Stream, уникальный для сети мостов. После этого мосты смогут узнавать поток без просмотра заголовков вышележащих уровней. Принимающий маршрутизатор также должен понимать и воспринимать TSN Stream.

  • Потоку DetNet от LSR A к LSR B можно назначить метку, отличающуюся от метки другого трафика в тот же адрес IP.

В обоих случаях имеющийся поток DetNet может содержать в себе множество других потоков DetNet (не путайте составные потоки и потоки участников DetNet). Для этого требуется корректная подготовка потока DetNet для передачи агрегированных потоков.

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

4.7.2. Отображение атрибутов потока между уровнями

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

  • маршрутизация IP;

  • коммутация по меткам MPLS;

  • мосты Ethernet.

add/remove     add/remove
Eth Flow-ID    IP Flow-ID
    |             |
    v             v
 +-----------------------------------------------------------+
 |      |      |      |                                      |
 | Eth  | MPLS |  IP  |     Данные приложения                |
 |      |      |      |                                      |
 +-----------------------------------------------------------+
           ^
           |
       add/remove
      MPLS Flow-ID

Рисунок 9. Пакет с множеством Flow-ID.


На рисунке 9 показан пакет с несколькими Flow-ID и указаны точик добавления и удаления каждого Flow-ID.

Дополнительными (зависит от домена) Flow-ID могут быть:

  • идентификаторы, созданный специальной функцией домена;

  • идентификаторы, полученные добавлением Flow-ID к App-flow.

Значение Flow-ID должно быть уникальным в рамках домена. Отметим, что Flow-ID, добавляемые к App-flow, продолжают оставаться в пакетах, но некоторые узлы могут не иметь функций для их распознавания, поэтому используется дополнительный Flow-ID.

4.7.3. Примеры отображений Flow-ID

Узлы IP и MPLS предполагаются настроенными на вталкивание таких дополнительных (зависящих от домена) Flow-ID при передаче трафика коммутатору Ethernet, как показано в примерах ниже.

На рисунке 10 показана конечная система IP (IP-A), подключенная через два коммутатора Ethernet (ETH-n) к маршрутизатору IP (IP-1).

                                        Домен IP
                     <----------------------------------------------->

              +======+                                       +======+
              |L3-ID |                                       |L3-ID |
              +======+  /\                           +-----+ +======+
                       /  \       Пересылка          |     |
                      /IP-A\      по ETH-ID          |IP-1 |  Распознавание
Вталкивание ------>  +-+----+         |              +---+-+  <----- ETH-ID
   ETH-ID           |         +----+-----+            |
                    |         v          v            |
                    |      +-----+    +-----+         |
                    +------+     |    |     +---------+
           +......+        |ETH-1+----+ETH-2|           +======+
           .L3-ID .        +-----+    +-----+           |L3-ID |
           +======+             +......+                +======+
           |ETH-ID|             .L3-ID .                |ETH-ID|
           +======+             +======+                +------+
                                |ETH-ID|
                                +======+

                             Домен Ethernet
                           <---------------->

Рисунок 10. Соединение узлов IP через домен Ethernet.


Система IP-A использует исходный идентификатор потока приложения L3-ID, но она подключена к домену Ethernet, поэтому помещает в пакет связанный с этим доменом Flow-ID (ETH-ID) перед отправкой пакета ETH-1. Коммутатор ETH-1 может распознать поток по ETH-ID и пересылает его ETH-2, который коммутирует пакет маршрутизатору IP. Маршрутизатор IP-1 должен быть настроен на прием группового потока, указанного Ethernet Flow-ID. Он является устройством L3 и декодирует идентификатор потока данных по полям L3-ID в полученных пакетах.

На рисунке 11 показаны узлы домена MPLS (PE-n и P-m) соединенные через два коммутатора Ethernet (ETH-n).


                                       Домен MPLS
                     <----------------------------------------------->

          +=======+                                  +=======+
          |MPLS-ID|                                  |MPLS-ID|
          +=======+  +-----+                 +-----+ +=======+ +-----+
                     |     |   Пересылка     |     |           |     |
                     |PE-1 |   по ETH-ID     | P-2 +-----------+ PE-2|
Вталкивание  ----->  +-+---+        |        +---+-+           +-----+
   ETH-ID           |      +-----+----+       |  \ Recognize
                    |      v          v       |   +-- ETH-ID
                    |   +-----+    +-----+    |
                    +---+     |    |     +----+
           +.......+    |ETH-1+----+ETH-2|   +=======+
           .MPLS-ID.    +-----+    +-----+   |MPLS-ID|
           +=======+                         +=======+
           |ETH-ID |         +.......+       |ETH-ID |
           +=======+         .MPLS-ID.       +-------+
                             +=======+
                             |ETH-ID |
                             +=======+
                          Домен Ethernet 
                        <---------------->

Рисунок 11. Соединение узлов MPLS через домен Ethernet.

PE-1 использует идентификатор MPLS-ID, но этот узел подключен к домену Ethernet и вталкивает идентификатор для этого домена (ETH-ID) перед отправкой пакета ETH-1. Коммутатор ETH-1 может распознать поток данных по ETH-ID и пересылает их ETH-2, который коммутирует пакеты узлу MPLS (P-2). Узел P-2 должен быть настроен на получение группового потока по Ethernet Flow-ID. Он является узлом MPLS и декодирует идентификатор потока данных по полям MPLS-ID в принятых пакетах.

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

4.8. Анонсирование ресурсов, возможностей и соседства

Для подготовки сервиса DetNet нужно иметь указанные ниже сведения.

  • Сведения о возможностях системы DetNet, которые нужны для точного выделения ресурсов этой и других систем DetNet. Это включает, например, реализуемые алгоритмы очередей и формирования трафика (4.5. Очереди, формирование, планирование и вытеснение трафика), объем буферов для выделения DetNet, наихудшие допустимые задержка и нарушение порядка доставки.

  • Фактическое состояние ресурсов DetNet на узле DetNet.

  • Идентификационные данные соседей системы DetNet и характеристики каналов между системами DetNet, включая задержку в наносекундах.

4.9. Большие сети

Резервирование для отдельных потоков DetNet требует обширной информации о состоянии в каждом узле DetNet, особенно если требуется адекватное устранение отказов (3.3.2. Устранение отказов). Плоскость данных DetNet для поддержки большого числа потоков DetNet должна обеспециать агрегирование потоков DetNet. Такие агрегированные потоки могут рассматриваться плоскостями данных узлов DetNet как отдельные потоки DetNet. Без такого агрегирования система на уровне ретранслятора может ограничивать размеры сетей DetNet. Примеры используемых методов включают иерархию MPLS и коды IP DiffServ (DSCP).

4.10. Совместимость с уровнями L2

Стандарты, обеспечивающие похожие возможности в сетях на основе (лишь) мостов были созданы в IEEE 802 LAN/MAN Standards Committee. Представленная архитектура описывает абстрактную модель, которая может применяться к L2 и L3, а также к каналам, не определенным IEEE 802.

Концечные системы с поддержкой DetNet и узлы DetNet могут соединяться через подсети, т. е. технологией L2. Эти подсети будут предоставлять совместимые с DetNet услуги для поддержки трафика DetNet. Примеры технологий таких подсетей включают MPLS TE, IEEE 802.1 TSN и каналы точка-точка в OTN. Возможны и многоуровневые системы DetNet, где сеть DetNet выступает в качестве подсети для системы DetNet более высокого уровня.

5. Вопросы безопасности

Вопросы безопасности DetNet подробно рассмотрены в [DETNET-SECURITY]. Здесь обсуждаются лишь вопросы безопасности, связанные в архитектурой DetNet.

Уникальными дял DetNet аспектами безопасности являются вопросы QoS в DetNet, которые связаны с максимально низкой потерей пакетов и ограниченной сквозной задержкой. DetNet может работать на основе MPLS и/или IP (v4 и v6), наследуя их защитные свойства на уровнях данных и управления.

Вопросы безопасности для DetNet ограничены (например, по сравнению с открытой сетью Internet), DetNet работает только внутри одного административного домена (1. Введение). В первую очередь нужно обеспечить безопасность запроса и управления ресурсами DetNet, конфиденциальность данных DetNet и доступность DetNet QoS.

Для защиты запросов и управления ресурсами DetNet может применяться аутентификация и контроль полномочий для каждого устройства, подключенного к домену DetNet, что наиболее важно для устройств управления сетью. Управление сетью DetNet может быть централизованным или распределенным (внутри одного административного домена). Для централизованного управления вопросы безопасности в сетях ACTN30 приведено в разделе 9 [RFC8453]. При использовании протоколов распределенного управления предполагается, что безопасность DetNet обеспечивается свойствами применяемых протоколов. В любом случае возможности манипулировать административно задаваемыми параметрами предоставляются лишь уполномоченным элементам (лицам).

Для обеспечения конфиденциальности данных в DetNet потоки приложений можно защищать с использованием возможностей базовой технологии. Например, может применяться шифрование, обеспечиваемое IPsec [RFC4301] для потоков IP flows и MACSec [IEEE802.1AE] для потоков Ethernet (L2).

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

Для обеспечения бесперебойной доступности DetNet QoS могут применяться меры защиты от DoS-атак и добавления задержек. Для защиты от атак на службы (DoS) избыточный трафик злонамеренных или неисправных устройств можно предотвращать или ослаблять, например, с помощью контроля допуска трафика на входе в домен DetNet, как описано в параграфе 3.2.1, или с помощью методов устранения отказов, описанных в параграфе 3.3.2. Для предотвращения задержки пакетов устройствами за пределами домена DetNet выбор технологии DetNet может смягчить MITM31-атаки, например, за счет аутентификации и контроля полномочий устройств внутри домена DetNet.

Поскольку механизмы DetNet и приложения, опирающиеся на DetNet, могут широко применять методы, требующие синхронизации часов, точность, доступность и целостность синхронизации очень важны. Этот вопрос рассмотрен в [RFC7384].

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

6. Вопросы конфиденциальности

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

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

7. Взаимодействие с IANA

Документ не требует действий со стороны IANA.

8. Литература

[BUFFERBLOAT] Gettys, J. and K. Nichols, «Bufferbloat: Dark Buffers in the Internet», DOI 10.1145/2063176.2063196, Communications of the ACM, Volume 55, Issue 1, January 2012, <https://doi.org/10.1145/2063176.2063196>.

[CCAMP] IETF, «Common Control and Measurement Plane (ccamp)», October 2019, <https://datatracker.ietf.org/wg/ccamp/charter/>.

[DETNET-FRAMEWORK] Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A., Bryant, S., and J. Korhonen, «DetNet Data Plane Framework», Work in Progress, Internet-Draft, draft-ietf-detnet-data-plane-framework-02, 13 September 2019, <https://tools.ietf.org/html/draft-ietf-detnet-data-plane-framework-0232>.

[DETNET-IP] Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A., Bryant, S., and J. Korhonen, «DetNet Data Plane: IP», Work in Progress, Internet-Draft, draft-ietf-detnet-ip-01, 1 July 2019, <https://tools.ietf.org/html/draft-ietf-detnet-ip-0133>.

[DETNET-MPLS] Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A., Bryant, S., and J. Korhonen, «DetNet Data Plane: MPLS», Work in Progress, Internet-Draft, draft-ietf-detnet-mpls-01, 1 July 2019, <https://tools.ietf.org/html/draft-ietf-detnet-mpls-0134>.

[DETNET-SECURITY] Mizrahi, T., Grossman, E., Hacker, A., Das, S., Dowdell, J., Austad, H., Stanton, K., and N. Finn, «Deterministic Networking (DetNet) Security Considerations», Work in Progress, Internet-Draft, draft-ietf-detnet-security-05, 29 August 2019, <https://tools.ietf.org/html/draft-ietf-detnet-security-0535>.

[IEC-62439-3] IEC, «Industrial communication networks — High availability automation networks — Part 3: Parallel Redundancy Protocol (PRP) and High-availability Seamless Redundancy (HSR)», TC 65 / SC 65C, IEC 62439-3:2016, March 2016, <https://webstore.iec.ch/publication/24447>.

[IEEE802.1AE] IEEE, «IEEE Standard for Local and metropolitan area networks-Media Access Control (MAC) Security», IEEE 802.1AE-2018, <https://ieeexplore.ieee.org/document/8585421>.

[IEEE802.1BA] IEEE, «IEEE Standard for Local and metropolitan area networks—Audio Video Bridging (AVB) Systems», IEEE 802.1BA-2011, <https://ieeexplore.ieee.org/document/6032690>.

[IEEE802.1CB] IEEE, «IEEE Standard for Local and metropolitan area networks—Frame Replication and Elimination for Reliability», DOI 10.1109/IEEESTD.2017.8091139, IEEE 802.1CB-2017, October 2019, <https://ieeexplore.ieee.org/document/8091139>.

[IEEE802.1Q] IEEE, «IEEE Standard for Local and Metropolitan Area Network—Bridges and Bridged Networks», IEEE 802.1Q-2018, <https://ieeexplore.ieee.org/document/8403927>.

[IEEE802.1Qav] IEEE, «IEEE Standard for Local and Metropolitan Area Networks — Virtual Bridged Local Area Networks Amendment 12: Forwarding and Queuing Enhancements for Time-Sensitive Streams», IEEE 802.1Qav-2009, <https://ieeexplore.ieee.org/document/5375704>.

[IEEE802.1Qbu] IEEE, «IEEE Standard for Local and metropolitan area networks — Bridges and Bridged Networks — Amendment 26: Frame Preemption», IEEE 802.1Qbu-2016, <https://ieeexplore.ieee.org/document/7553415>.

[IEEE802.1Qbv] IEEE, «IEEE Standard for Local and metropolitan area networks — Bridges and Bridged Networks — Amendment 25: Enhancements for Scheduled Traffic», IEEE 802.1Qbv-2015, <https://ieeexplore.ieee.org/document/7440741>.

[IEEE802.1Qch] IEEE, «IEEE Standard for Local and metropolitan area networks—Bridges and Bridged Networks—Amendment 29: Cyclic Queuing and Forwarding», IEEE 802.1Qch-2017, <https://ieeexplore.ieee.org/document/7961303>.

[IEEE802.1TSNTG] IEEE, «Time-Sensitive Networking (TSN) Task Group», <https://1.ieee802.org/tsn/>.

[IEEE802.3] IEEE, «IEEE Standard for Ethernet», IEEE 802.3-2018, <https://ieeexplore.ieee.org/document/8457469>.

[IEEE802.3br] IEEE, «IEEE Standard for Ethernet Amendment 5: Specification and Management Parameters for Interspersing Express Traffic», IEEE 802.3br, <https://ieeexplore.ieee.org/document/7900321>.

[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. Jamin, «Resource ReSerVation Protocol (RSVP) — Version 1 Functional Specification», RFC 2205, DOI 10.17487/RFC2205, September 1997, <https://www.rfc-editor.org/info/rfc2205>.

[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, «An Architecture for Differentiated Services», RFC 2475, DOI 10.17487/RFC2475, December 1998, <https://www.rfc-editor.org/info/rfc2475>.

[RFC2914] Floyd, S., «Congestion Control Principles», BCP 41, RFC 2914, DOI 10.17487/RFC2914, September 2000, <https://www.rfc-editor.org/info/rfc2914>.

[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, «The Addition of Explicit Congestion Notification (ECN) to IP», RFC 3168, DOI 10.17487/RFC3168, September 2001, <https://www.rfc-editor.org/info/rfc3168>.

[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, «RSVP-TE: Extensions to RSVP for LSP Tunnels», RFC 3209, DOI 10.17487/RFC3209, December 2001, <https://www.rfc-editor.org/info/rfc3209>.

[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, «RTP: A Transport Protocol for Real-Time Applications», STD 64, RFC 3550, DOI 10.17487/RFC3550, July 2003, <https://www.rfc-editor.org/info/rfc3550>.

[RFC4301] Kent, S. and K. Seo, «Security Architecture for the Internet Protocol», RFC 4301, DOI 10.17487/RFC4301, December 2005, <https://www.rfc-editor.org/info/rfc4301>.

[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, «A Path Computation Element (PCE)-Based Architecture», RFC 4655, DOI 10.17487/RFC4655, August 2006, <https://www.rfc-editor.org/info/rfc4655>.

[RFC6372] Sprecher, N., Ed. and A. Farrel, Ed., «MPLS Transport Profile (MPLS-TP) Survivability Framework», RFC 6372, DOI 10.17487/RFC6372, September 2011, <https://www.rfc-editor.org/info/rfc6372>.

[RFC6658] Bryant, S., Ed., Martini, L., Swallow, G., and A. Malis, «Packet Pseudowire Encapsulation over an MPLS PSN», RFC 6658, DOI 10.17487/RFC6658, July 2012, <https://www.rfc-editor.org/info/rfc6658>.

[RFC7149] Boucadair, M. and C. Jacquenet, «Software-Defined Networking: A Perspective from within a Service Provider Environment», RFC 7149, DOI 10.17487/RFC7149, March 2014, <https://www.rfc-editor.org/info/rfc7149>.

[RFC7384] Mizrahi, T., «Security Requirements of Time Protocols in Packet Switched Networks», RFC 7384, DOI 10.17487/RFC7384, October 2014, <https://www.rfc-editor.org/info/rfc7384>.

[RFC7426] Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S., Hadi Salim, J., Meyer, D., and O. Koufopavlou, «Software-Defined Networking (SDN): Layers and Architecture Terminology», RFC 7426, DOI 10.17487/RFC7426, January 2015, <https://www.rfc-editor.org/info/rfc7426>.

[RFC7554] Watteyne, T., Ed., Palattella, M., and L. Grieco, «Using IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the Internet of Things (IoT): Problem Statement», RFC 7554, DOI 10.17487/RFC7554, May 2015, <https://www.rfc-editor.org/info/rfc7554>.

[RFC7567] Baker, F., Ed. and G. Fairhurst, Ed., «IETF Recommendations Regarding Active Queue Management», BCP 197, RFC 7567, DOI 10.17487/RFC7567, July 2015, <https://www.rfc-editor.org/info/rfc7567>.

[RFC7813] Farkas, J., Ed., Bragg, N., Unbehagen, P., Parsons, G., Ashwood-Smith, P., and C. Bowers, «IS-IS Path Control and Reservation», RFC 7813, DOI 10.17487/RFC7813, June 2016, <https://www.rfc-editor.org/info/rfc7813>.

[RFC8033] Pan, R., Natarajan, P., Baker, F., and G. White, «Proportional Integral Controller Enhanced (PIE): A Lightweight Control Scheme to Address the Bufferbloat Problem», RFC 8033, DOI 10.17487/RFC8033, February 2017, <https://www.rfc-editor.org/info/rfc8033>.

[RFC8227] Cheng, W., Wang, L., Li, H., van Helvoort, H., and J. Dong, «MPLS-TP Shared-Ring Protection (MSRP) Mechanism for Ring Topology», RFC 8227, DOI 10.17487/RFC8227, August 2017, <https://www.rfc-editor.org/info/rfc8227>.

[RFC8289] Nichols, K., Jacobson, V., McGregor, A., Ed., and J. Iyengar, Ed., «Controlled Delay Active Queue Management», RFC 8289, DOI 10.17487/RFC8289, January 2018, <https://www.rfc-editor.org/info/rfc8289>.

[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, «Segment Routing Architecture», RFC 8402, DOI 10.17487/RFC8402, July 2018, <https://www.rfc-editor.org/info/rfc8402>.

[RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., «Framework for Abstraction and Control of TE Networks (ACTN)», RFC 8453, DOI 10.17487/RFC8453, August 2018, <https://www.rfc-editor.org/info/rfc8453>.

[RFC8557] Finn, N. and P. Thubert, «Deterministic Networking Problem Statement», RFC 8557, DOI 10.17487/RFC8557, May 2019, <https://www.rfc-editor.org/info/rfc8557>.

[RFC8578] Grossman, E., Ed., «Deterministic Networking Use Cases», RFC 8578, DOI 10.17487/RFC8578, May 2019, <https://www.rfc-editor.org/info/rfc8578>.

[TEAS] IETF, «Traffic Engineering Architecture and Signaling (teas)», October 2019, <https://datatracker.ietf.org/doc/charter-ietf-teas/>.

[TSCH-ARCH] Thubert, P., «An Architecture for IPv6 over the TSCH mode of IEEE 802.15.4», Work in Progress, Internet-Draft, draft-ietf-6tisch-architecture-26, 27 August 2019, <https://tools.ietf.org/html/draft-ietf-6tisch-architecture-2636>.

Благодарности

Авторы благодарны Lou Berger, David Black, Stewart Bryant, Rodney Cummings, Ethan Grossman, Craig Gunther, Marcel Kiessling, Rudy Klecka, Jouni Korhonen, Erik Nordmark, Shitanshu Shah, Wilfried Steiner, George Swallow, Michael Johas Teener, Pat Thaler, Thomas Watteyne, Patrick Wetterwald, Karl Weber и Anca Zamfir за их вклад в эту работу.

Адреса авторов

Norman Finn

Huawei

3101 Rio Way

Spring Valley, California 91977

United States of America

Phone: +1 925 980 6430

Email: nfinn@nfinnconsulting.com

Pascal Thubert

Cisco Systems

Batiment T3

Village d’Entreprises Green Side, 400, Avenue de Roumanille

06410 Biot — Sophia Antipolis

France

Phone: +33 4 97 23 26 34

Email: pthubert@cisco.com

Balázs Varga

Ericsson

Budapest

Magyar tudosok korutja 11

1117

Hungary

Email: balazs.a.varga@ericsson.com

János Farkas

Ericsson

Budapest

Magyar tudosok korutja 11

1117

Hungary

Email: janos.farkas@ericsson.com

Перевод на русский язык

Николай Малых

nmalykh@protocols.ru

1Deterministic Networking.

2Time-Sensitive Networking — чувствительные ко времени сети.

3Internet Engineering Task Force.

4Internet Engineering Steering Group.

5Quality-of-Service — качество обслуживания.

6Resource Reservation Protocol — протокол резервирования ресурсов.

7Label Edge Router — краевой маршрутизатор по меткам.

8Provider Edge — краевой маршрутизатор провайдера.

9MPLS Label Switch Router — маршрутизатор с коммутацией по меткам.

10Shared Risk Link Group — группа каналов с общим риском.

11Segment Routing — сегментная маршрутизация.

12Traffic Engineering — организация трафика.

13Label Switched Path — путь с коммутацией по меткам.

14Class-of-Service.

15Operations, Administration, and Maintenance — эксплуатация, администрирование, поддержка.

16Optical Transport Network — оптическая транспортная сеть.

17Real-time Transport Protocol — протокол доставки в реальном масштабе времени.

18Pseudowire.

19Network Interface Card — плата сетевого интерфейса.

20Time-division multiplexing — мультиплексирование с разделением по времени.

21Transport Profile — транспортный профиль.

22Traffic Engineering Architecture and Signaling — архитектура и сигнализация для организации трафика.

23Traffic Engineering.

24Flow Management Entity.

25Traffic Specification — спецификация трафика.

26Common Control and Measurement Plane — общая плоскость управления и измерений.

27Controller Plane Function — функция плоскости контроллера.

28Path Computation Element — элемент расчета пути.

29Network Management Entity — элемент управления сетью.

30Abstraction and Control of Traffic Engineered Network.

31Man-in-the-middle — перехват и изменение трафика с участием человека.

32Доступен более свежий вариант https://tools.ietf.org/html/draft-ietf-detnet-data-plane-framework-04. Прим. перев.

33Доступен более свежий вариант https://tools.ietf.org/html/draft-ietf-detnet-ip-05. Прим. перев.

34Доступен более свежий вариант https://tools.ietf.org/html/draft-ietf-detnet-mpls-05. Прим. перев.

35Доступен более свежий вариант https://tools.ietf.org/html/draft-ietf-detnet-security-09. Прим. перев.

36Доступен более свежий вариант https://tools.ietf.org/html/draft-ietf-6tisch-architecture-28. Прим. перев.




RFC 8609 Content-Centric Networking (CCNx) Messages in TLV Format

Internet Research Task Force (IRTF)                             M. Mosko
Request for Comments: 8609                                    PARC, Inc.
Category: Experimental                                          I. Solis
ISSN: 2070-1721                                                 LinkedIn
                                                                 C. Wood
                                         University of California Irvine
                                                               July 2019

Content-Centric Networking (CCNx) Messages in TLV Format

Сообщения ориентированных на содержимое сетей (CCNx) в формате TLV

PDF

Тезисы

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

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

Статус документа

Документ не является спецификацией стандартного протокола Internet (Standards Track) и публикуется для проверки, экспериментальной реализации и оценки.

Документ определяет экспериментальный протокол для сообщества Internet. Документ является результатом работы IRTF3. IRTF публикует результаты связанных с Internet исследований и разработок. Эти результаты могут оказаться не подходящими для развертывания. Данный RFC представляет согласованное мнение группы ICNRG в составе IRTF. Документ одобрен для публикации IRSG и не претендует на роль стандарта Internet (см. раздел 2 в RFC 7841).

Информацию о текущем статусе документа, ошибках и способах обратной связи можно найти по ссылке https://www.rfc-editor.org/info/rfc8609.

Авторские права

Авторские права (Copyright (c) 2019) принадлежат IETF Trust и лицам, указанным в качестве авторов документа. Все права защищены.

Документ является субъектом прав и ограничений, указанных в BCP 78 и IETF Trust Legal Provisions и относящихся к документам IETF (http://trustee.ietf.org/license-info), на момент публикации данного документа. Прочтите упомянутые документы внимательно, поскольку в них описаны права и ограничения, относящиеся к данному документу.

Оглавление

Исключено в версии HTML.

1. Введение

Этот документ задает формат пакетов TLV4, а также кодирование типа и значения TLV для сообщений CCNx. Полное описание сетевого протокола CCNx с независимым от кодирования описанием сообщений CCNx и их элементов можно найти в [RFC8569]. Сетевой протокол CCNx использует иерархические имена для пересылки запросов и сопоставления откликов с запросами. Протокол не использует адресов конечных точек, как это делает протокол IP. Ограничения в запросе могут лимитировать отклик открытым ключом подписавшей его стороны или криптографическим эш-значением отклика. Каждый узел пересылки CCNx на пути выполняет сопоставление имен и проверку ограничений. Протокол CCNx вписывается в более широкую модель протоколов ICN5 [RFC7927].

Этот документ описывает схему TLV, использующую 2-байтовые поля T и L. Основания этого выбора приведены в разделе 5. Вкратце, это позволяет избежать множества вариантов кодирования одного значения (псевдонимов) и уменьшить работу при проверке пригодности для обеспечения соответствия. В отличие от некоторых других применений TLV в сетях, каждый интервал пересылки должен проверять кодирование, поэтому даже небольшая задержка на каждом узле будет приводить к значительной суммарной задержке пересылки. Для очень мелких пакетов и низкоскоростных каналов, где лишние байты могут иметь значение, можно применять протокол сжатия TLV (например, [compress] и [CCNxz]).

В документе используются термины пакет CCNx, сообщение CCNx и TLV сообщения CCNx. Пакетом CCNx называют всю дейтаграмму L3, как указано в параграфе 3.1. Сообщение CCNx — это маркер ABNF, определенный семантикой CCNx [RFC8569]. TLV сообщения CCNx говорит о кодировании сообщения CCNx в соответствии с параграфом 3.6.

Этот документ задает:

  • формат пакетов CCNx;

  • формат TLV сообщений CCNx;

  • типы TLV, используемые в сообщениях CCNx;

  • кодирование значений каждого типа;

  • типы верхнего уровня, существующие во внешнем окружении;

  • Interest TLV, существующие в Interest;

  • Content Object TLV, используемые в Content Object.

Данный документ дополняется указанными ниже документами:

  • [RFC8569], описывающий семантику сообщений и протокольные операции, относящиеся к сообщениям Interest и Content Object, включая протокол Interest Return;

  • [CCNxURI], описывающий нотацию CCNx URI.

Значения типов в разделе 4 соответствуют выделенным IANA номерам для протокола CCNx. В документе применяются символьные имена, определенные в указанном разделе. Все значения для типов TLV указываются относительно их родительских контейнеров. Например, каждый уровень вложенной структуры TLV может определять type = 1 со своим смыслом.

Пакеты представляются в форме 32-битовых слов. По причине вложенности TLV и наличия необязательных полей нет возможности показать все варианты. Поля на рисунках, ограниченные символами | представляют точный размер в битах. Поля с символами / имеют переменный размер и обычно дополняются до границы слова для удобства восприятия.

Документ выражает согласованные взгляды ICN RG. Это первый протокол ICN рабочей группы, созданный на базе раннего протокола CCNx [nnc] с существенным пересмотром и учетом предложения сообщества ICN и членов исследовательской группы. Документ прошел рецензирование нескольких участников сообщества ICN и исследовательской группы. Авторы и руководитель исследовательской группы одобрили документ. Подготовка документа поддержана IRTF, документ выпущен за рамками процесса IETF и не является стандартом IETF. Это экспериментальный протокол, который может не подойти для конкретных применений. Спецификация в будущем может измениться.

1.1. Уровни требований

Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не следует (SHALL NOT), следует (SHOULD), не нужно (SHOULD NOT), рекомендуется (RECOMMENDED), не рекомендуется (NOT RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе интерпретируются в соответствии с BCP 14 [RFC2119] [RFC8174] тогда и только тогда, когда они выделены шрифтом, как показано здесь.

2. Определения

Приведенные ниже определения взяты из [RFC8569]. Данный документ определяет их кодирование.

Name

Иерархически организованный идентификатор переменного размера, представленный упорядоченным списком сегментов пути, являющихся строками октетов с переменным размером. В удобной для человека форме имена представляются в формате URI, как ccnx:/path/part. Здесь нет строк хостов и запросов. Подробности именования приведены в [CCNxURI].

Interest

Сообщение, запрашивающее Content Object с совпадающим именем (Name) и другими необязательными селекторами для выбора из множества объектов с одинаковым именем. Любой Content Object с Name и атрибутами, соответствующими Name, и необязательным селекторам в Interest считается удовлетворяющим Interest.

Content Object

Объект данных, передаваемый в ответ на запрос Interest, имеющий необязательное имя (Name) и данные содержимого, связанные вместе криптографическими средствами.

3. Пакеты TLV

Для кодирования пакетов на основе TLV применяются 16-битовые поля Type и Length. Это обеспечивает 65536 значений типов и размер до 64 Кбайт. При 65536 возможных типах на каждом уровне кодирования TLV пространства базовых протокольных типов вполне достаточно и остается место для экспериментов, приложений, фирменных расширений и последующего роста. При таком кодировании не возникает больших пакетов (jumbo), размер которых превышает 64 Кбайта. При использовании в средах с поддержкой кадров jumbo можно определить агрегирование множества мелких кадров в один большой.

Таблица 1. Резервные типы TLV.

Сокращение

Имя

Описание

T_ORG

Информация производителя

Информация, относящаяся к реализации данного прозводителя (параграф 3.3.2).

T_PAD

Заполнение

Дополнение поля до нужного размера (параграф 3.3.1).

нет

Эксперимент

Экспериментальное использование.

Имеется несколько глобальных определений TLV, зарезервированных для всех вариантов иерархического контекста. TLV типов 0x1000 — 0x1FFF являются резервом для экспериментов (Reserved for Experimental Use), TLV типа T_ORG — для фирменных расширений (Reserved for Vendor Extensions, см. парагра 3.3.2), TLV типа T_PAD служат для заполнения полей до нужной границы.

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
|              Type             |            Length             |
+---------------+---------------+---------------+---------------+

Рисунок 1. Кодирование типа и размера.


Поле Length указывает размер поля Value в октетах, не включая размер полей Type и Length. Поле Length может иметь значения 0.

Структуры TLV могут быть вложенными, когда поле Value одной структуры TLV включает целиком другие структуры TLV. Внешняя структура The enclosing TLV structure is called the container of the enclosed TLV.

Значения типов зависят от контекста. Внутри контейнера TLV могут применяться ранее использованные типы для новых целей, зависящих от контекста.

3.1. Общий формат пакетов

Каждый пакет CCNx включает 8-байтовый фиксированный заголовок, описанный ниже, за которым следует набор TLV. Эти поля содержат необязательные поэтапные (hop-by-hop) заголовки и данные пакета (Packet Payload).

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
|    Version    |  PacketType   |         PacketLength          |
+---------------+---------------+---------------+---------------+
|         Зависимые от PacketType поля          | HeaderLength  |
+---------------+---------------+---------------+---------------+
/ TLV необязательных поэтапных заголовков                       /
+---------------+---------------+---------------+---------------+
/ PacketPayload TLV                                             /
+---------------+---------------+---------------+---------------+

Рисунок 2. Общий формат пакета.


PacketPayload в пакете CCNx предсатвляет собой само протокольное сообщение. Значение Content Object Hash рассчитывается только для PacketPayload без учета фиксированных и поэтапных заголовков, которые могут меняться в пути. В подписанную информацию или хэш-значения сходства не следует включать фиксированные или поэтапные заголовки. Полю PacketPayload следует быть самодостаточным на случай удаления фиксированных и поэтапных заголовков (см. параграф 3.4.3).

Как и TLV сообщения CCNx, поле PacketPayload может включать необязательный блок Validation TLV.

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| CCNx Message TLV                                              /
+---------------+---------------+---------------+---------------+
/ Необязат. CCNx ValidationAlgorithm TLV                        /
+---------------+---------------+---------------+---------------+
/ Необязат. CCNx ValidationPayload TLV (требуется ValidationAlg)/
+---------------+---------------+---------------+---------------+

Рисунок 3. PacketPayload TLV.


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

Набор байтов, защищенных полем Validation, включает CCNx Message TLV и ValidationAlgorithm TLV.

ContentObjectHash начинается с CCNx Message TLV и завершается в конце CCNx Packet.

3.2. Фиксированные заголовки

Ниже приведены описания полей фиксированного заголовка, показанных на рисунке 2.

Version

Определяет версию пакета и должно иметь значение 1.

HeaderLength

Указывает размер фиксированного (8 байтов) и поэтапных заголовков. Значение должно быть не меньше 8.

PacketType

Описывает действия узла пересылки по отношению к пакету.

PacketLength

Общее число октетов в пакете с учетом всех заголовков и протокольного сообщения.

Зависимые от PacketType поля

Зависящие от PacketType поля пакета.

Поле PacketType указывает, как узлу пересылки следует обрабатывать пакет. Пакеты запроса (Interest) имеют PacketType = PT_INTEREST, отклики (Content Object) — PacketType = PT_CONTENT, а Interest Return — PacketType = PT_RETURN.

HeaderLength указывает число октетов от начала пакета CCNx (Version) до конца поэтапных заголовков, PacketLength — число октетов от начала до конца пакета. Оба поля имеет значение не меньше 8 (размер фиксированного заголовка).

Зависящие от PacketType поля являются резервными битами, использование которых зависит от типа пакета. Они служат для сигнализации сетевого уровня.

3.2.1. Фиксированный заголовок Interest

Если PacketType = PT_INTEREST, это говорит о том, что пакет следует пересылать в соответствии с конвейером Interest, описанным в параграфе 2.4.4 [RFC8569].Для этого типа пакетов фиксированный заголовок включает поле HopLimit, а также поля Reserved и Flags. Поле Reserved в сообщениях Interest должно иметь значение 0. Флаги в настоящее время не определены и поле Flags должно иметь значение 0.

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
|    Version    |  PT_INTEREST  |         PacketLength          |
+---------------+---------------+---------------+---------------+
|   HopLimit    |   Reserved    |     Flags     | HeaderLength  |
+---------------+---------------+---------------+---------------+

Рисунок 4. Заголовок Interest.


3.2.1.1. Interest HopLimit

Для сообщений Interest поле HopLimit содержит счетчик, декрементируемый на каждом интервале пересылки (hop). Оно ограничивает дальность перемещения Interest через сеть. Создавший Interest узел может поместить в это поле любое значение до 255. Каждый узел, принявший Interest с HopLimit декрементирует значение поля при получении. Если после декремента значение становится 0, Interest недопустимо пересылать за пределы узла.

Прием от удаленного узла сообщений Interest с HopLimit = 0 является ошибкой.

3.2.2. Фиксированный заголовок Content Object

Если PacketType = PT_CONTENT, это указывает, что пакет следует пересылать в соответствии с конвейером Content Object, определенным в параграфе 2.4.4 [RFC8569]. Content Object включает поле Flags, однако флаги в настоящее время не определены и поле должно иметь значение 0.

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
|    Version    |  PT_CONTENT   |         PacketLength          |
+---------------+---------------+---------------+---------------+
|            Reserved           |     Flags     | HeaderLength  |
+---------------+---------------+---------------+---------------+

Рисунок 5. Заголовок Content Object.


3.2.3. Фиксированный заголовок Interest Return

Если PacketType = PT_RETURN, это указывает, что пакет следует обрабатывать в соответствии с правилами Interest Return, указанными в разделе 10 [RFC8569]. Единственным различием сообщения Interest Return и исходного Interest является замена PacketType на PT_RETURN и включение ReturnCode в поле ReturnCode. Все прочие поля сохраняются неизменными из пакета Interest. Целью этого заключается в предотвращении смены размера, чтобы не нужно было добавлять байты для возврата Interest на предыдущий интервал.

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
|    Version    |   PT_RETURN   |         PacketLength          |
+---------------+---------------+---------------+---------------+
|   HopLimit    |  ReturnCode   |     Flags     | HeaderLength  |
+---------------+---------------+---------------+---------------+

Рисунок 6. Заголовок Interest Return.


3.2.3.1. Interest Return HopLimit

Это поле HopLimit из сообщения Interest до декрементирования его узлом, передающим Interest Return.

3.2.3.2. Флаги Interest Return

Поле Flags из сообщения Interest.

3.2.3.3. Коды возврата

В этом параграфе имена кодов возврата из [RFC8569] отображены на символические имена TLV. В параграфе 4.2 символические имена отображены на числовые значения. Это поле устанавливается узлом, создающим Interest Return.

Код возврата 0 недопустимо устанавливать, поскольку он показывает, что возвращающая сообщение система не изменила поле Return Code.

Таблица 2. Коды возврата.

ReturnType

Имя в 8569

T_RETURN_NO_ROUTE

No Route

T_RETURN_LIMIT_EXCEEDED

Hop Limit Exceeded

T_RETURN_NO_RESOURCES

No Resources

T_RETURN_PATH_ERROR

Path Error

T_RETURN_PROHIBITED

Prohibited

T_RETURN_CONGESTED

Congested

T_RETURN_MTU_TOO_LARGE

MTU too large

T_RETURN_UNSUPPORTED_HASH_RESTRICTION

Unsupported ContentObjectHashRestriction

T_RETURN_MALFORMED_INTEREST

Malformed Interest

3.3. Глобальные форматы

В этом параграфе определены глобальные форматы, которые могут быть встроены в другие TLV.

3.3.1. Заполнение

Тип pad может применяться отправителями, которые хотят выравнивать данные по границе слова. Дополнение 4-байтовых слов может иметь размер 1, 2 или 3 байта, заполнение 8-байтовых слов — 0, 1, 2, 3, 5, 6 или 7 байтов.

Недопустимо применять заполнение в поле Name. Заполнение можно включать в любые другие TLV в CCNx Message TLV или ValidationAlgorithm TLV. В оставшейся части документа не будут указываться необязательные Pad TLV.

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
|             T_PAD             |             Length            |
+---------------+---------------+---------------+---------------+
/                 variable-length pad MUST be zeros             /
+---------------+---------------+---------------+---------------+

Рисунок 7. Заполнение.


3.3.2. Фирменные TLV

Специфичные для организация TLV (фирменные) должны использовать тип T_ORG. Поле Length указывает размер фирменной информации + 3. Поле Value начинается с 3-байтового номера организации, выведенного из значения в реестре IANA Private Enterprise Numbers [IANA-PEN] с сетевым порядком байтов, а за ним следуют специфичные для организации данные.

T_ORG MAY может служит сегментом пути в Name, которые трактуется как все прочие сегменты пути.

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
|             T_ORG             |     Length (3+value length)   |
+---------------+---------------+---------------+---------------+
|   PEN[0]      |    PEN[1]     |     PEN[2]    |               /
+---------------+---------------+---------------+               +
/                  Vendor Specific Value                        /
+---------------+---------------+---------------+---------------+

Рисунок 8. Organization-Specific TLV.


3.3.3. Формат хэш-значений

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

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

Применение вложенного формата обусловлено тем, что он позволяет выполнять двоичное сравнение хэш-значений некоторых полей без необходимости понимания маршрутизатором новой хэш-функции. Например, поле KeyIdRestriction в Interest сравнивается побитово с полем KeyId в ContentObject. Этот формат означает, что значения внешнего поля не меняются при разных хэш-функциях, поэтому маршрутизатор может идентифицировать эти поля и выполнить двоичное сравнение хэш-TLV, не зная конкретной функции. Другой подход (например, использование T_KEYID_SHA512-256) будет требовать от маршрутизатора обновлять анализатор и поддерживать определяемые пользователями хэш-функции, что связано со значительными издержками при анализе.

Элементы CCNx должны поддерживать хэширование T_SHA-256 и могут поддерживать другие типы.

Таблица 3. Хэш-функции CCNx.

 

Сокращение

Размер в октетах

T_SHA-256

32

T_SHA-512

64, 32

нет

Экспериментальные типы TLV

 

 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
|             T_FOO             |              36               |
+---------------+---------------+---------------+---------------+
|           T_SHA512            |               32              |
+---------------+---------------+---------------+---------------+
/                        32-байтовое хэш-значение               /
+---------------+---------------+---------------+---------------+

Рисунок 9. Пример вложенности в тип T_FOO.

3.3.4. Link

Link представляет собой кортеж {Name, [KeyIdRestr], [ContentObjectHashRestr]}. Это базовая форма кодирования, применяемая в данных Content Object с PayloadType = Link и поле KeyLink объектов Content. Link по сути является телом Interest.

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
/ Mandatory CCNx Name                                           /
+---------------+---------------+---------------+---------------+
/ Необязательный KeyIdRestriction                               /
+---------------+---------------+---------------+---------------+
/ Необязательный ContentObjectHashRestriction                   /
+---------------+---------------+---------------+---------------+

Рисунок 10. Кодирование Link.


3.4. TLV поэтапных заголовков

TLV поэтапных (hop-by-hop) заголовков являются неупорядоченными и упорядочивать их недопустимо. В документе определены три заголовка hop-by-hop, показанных в таблице.

Таблица 4. Типы поэтапных заголовков.

Сокращение

Имя

Описание

T_INTLIFE

Interest Lifetime (параграф 3.4.1)

Время, в течение которого сообщению Interest можно оставаться ожидающим на промежуточном узле.

T_CACHETIME

Recommended Cache Time (параграф 3.4.2)

Рекомендуемое время кэширования для Content Object.

T_MSGHASH

Message Hash (параграф 3.4.3)

Криптографическая хэш-функция (параграф 3.3.3).

Дополнительные поэтапные заголовки определены в спецификациях верхнего уровня, таких как фрагментирование.

3.4.1. Срок действия Interest

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

Значение 0 (кодируется одним байтом 0x00) указывает, что сообщение Interest не вызвало получения отклика Content Object. Сообщение все еще может пересылаться, но отклика не ожидается и узел пересылки может не создавать запись PIT.

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
|          T_INTLIFE            |             Length            |
+---------------+---------------+---------------+---------------+
/                                                               /
/                      Lifetime (Length октетов)                /
/                                                               /
+---------------+---------------+---------------+---------------+

Рисунок 11. Кодирование Interest Lifetime.


3.4.2. Рекомендуемое время кэширования

RCT6 указывает срок действия Content Object, назначенный издателем содержимого или восходящим узлом. Это значение служит рекомендацией для хранилищ Content Store при определении срока кэширования объектов Content. Кэш имеет право игнорировать эти рекомендации. Это отличается от времени ExpiryTime (параграф 3.6.2.2.2), которое имеет преимущество перед RCT и должно соблюдаться.

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

RCT (временная метка в миллисекундах с начала эпохи в UTC) является 64-битовым целым числом без знака с сетевым порядком байтов, которое указывает время заверщения срока действия данных UTC).

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
|         T_CACHETIME           |               8               |
+---------------+---------------+---------------+---------------+
/                                                               /
/                    Recommended Cache Time                     /
/                                                               /
+---------------+---------------+---------------+---------------+

Рисунок 12. Кодирование рекомендуемого времени кэширования.


3.4.3. Хэш сообщения

Внутри доверенного домена оператор может рассчитать хэш сообщения на граничном устройстве и поместить его в поэтапные заголовки сообщения. Выходному устройству следует это значение удалить. Такой подход позволит промежуточным устройствам доверенного домена сопоставлять ContentObjectHashRestriction без расчетов на каждом узле.

Криптографическое хэш-значение сообщения учитывает данные от начала CCNx Message TLV до конца пакета. Оно служит для сопоставления с ContentObjectHashRestriction (параграф 3.6.2.1.2). Message Hash может превышать по размеру ограничение Interest и в этом случае устройству следует принимать расположенные слева байты Message Hash для сравнения с Interest.

Message Hash может содержать только одно хэш-значение и заголовок Message Hash может быть лишь один.

Заголовок Message Hash не защищен, поэтому практический смысл имеет лишь в доверенном домене, таком как автономная система оператора.

                    1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
|          T_MSGHASH            |         (length + 4)          |
+---------------+---------------+---------------+---------------+
|          hash type            |            length             |
+---------------+---------------+---------------+---------------+
/                           хэш-значение                        /
+---------------+---------------+---------------+---------------+

Рисунок 13. Заголовок Message Hash.


3.5. Типы верхнего уровня

Типы TLV верхнего уровня, показанные в таблице, размещаются на внешнем уровне CCNx Message TLV.

Таблица 5. Типы верхнего уровня CCNx.

Сокращение

Имя

Описание

T_INTEREST

Interest (параграф 3.6)

Сообщение типа Interest.

T_OBJECT

Content Object (параграф 3.6)

Сообщение типа Content Object.

T_VALIDATION_ALG

Validation Algorithm (параграф 3.6.4.1)

Метод проверки сообщения, такой как MIC7, MAC8 или криптографическая подпись.

T_VALIDATION_PAYLOAD

Validation Payload (параграф 3.6.4.2)

Выход проверки, такой как код CRC32C или подпись RSA.

3.6. TLV сообщений CCNx

Здесь описан формат самого сообщения CCNx. TLV сообщения CCNx является частью пакета CCNx между поэтапными заголовками и Validation TLV. На рисунке показано расширение CCNx Message TLV, указанное в начале раздела 3. CCNx Message TLV начинается с MessageType и тянется вплоть до необязательного Payload. Один базовый формат применяется для сообщений Interest и Content Object, различающихся лишь полями MessageType. Первым TLV в CCNx Message TLV всегда является Name TLV, если имя имеется. Далее следуют необязательные Message TLV и необязательный Payload TLV.

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
|         MessageType           |         MessageLength         |
+---------------+---------------+---------------+---------------+
/ Name TLV       (Type = T_NAME)                                /
+---------------+---------------+---------------+---------------+
/ Необязательные Message TLV   (разные типы)                    /
+---------------+---------------+---------------+---------------+
/ Необязательный Payload TLV  (Type = T_PAYLOAD)                /
+---------------+---------------+---------------+---------------+

Рисунок 14. Кодирование TLV сообщения CCNx.


Таблица 6. Типы TLV сообщений CCNx.

Сокращение

Имя

Описание

T_NAME

Name (параграф 3.6.1)

Имя CCNx Name запрошенное в Interest или опубликованное в Content Object.

T_PAYLOAD

Payload (параграф 3.6.3)

Данные сообщения.

3.6.1. Name

Name представляет собой TLV, кодированный последовательностью сегментов. В таблице 7 указаны типы сегментов имен. В Name недопустимо включать Pad TLV.

Как указано в семантике CCNx [RFC8569], при использовании нотации CCNx URI [CCNxURI] T_NAME нулевого размера соответствует ccnx:/ (маршрут по умолчанию). Грамматика сообщений не позволяет иметь нулевой размер первому сегменту в CCNx Message TLV Name. При кодировании TLV значение ccnx:/ соответствует T_NAME размера 0.

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
|            T_NAME             |            Length             |
+---------------+---------------+---------------+---------------+
/ TLV сегментов имени                                           /
+---------------+---------------+---------------+---------------+

Рисунок 15. Кодирование Name.

Таблица 7. Типы имен CCNx.

Символическое имя

Имя

Описание

T_NAMESEGMENT

Name segment (параграф 3.6.1.1)

Базовый сегмент имени.

T_IPID

Interest Payload ID (параграф 3.6.1.2)

Идентификатор, представляющий поле Interest Payload. Например, Payload ID может быть хэш-значением Interest Payload. Это позволяет разделять сообщения Interest на основе их данных без анализа всех байтов данных лишь по сегменту имени Payload ID.

T_APP:00 — T_APP:4096

Application Components (параграф 3.6.1.1)

Определяемые приложением данные в сегменте имени. Приложение может использовать свою семантику для 4096 зарезервированных типов.

3.6.1.1. Сегменты имен

Выделено 4096 типа сегментов имен приложений, семантика которых задается приложениями. Хорошим тоном является указание приложения в имени до использования других сегментов.

На рисунке 16 показано возможное представление имени ccnx:/foo/bar/hi.

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
|            (T_NAME)           |           0x14 (20)           |
+---------------+---------------+---------------+---------------+
|        (T_NAME_SEGMENT)       |           0x03 (3)            |
+---------------+---------------+---------------+---------------+
|       f                o               o      |(T_NAME_SEGMENT)
+---------------+---------------+---------------+---------------+
|               |            0x03 (3)           |       b       |
+---------------+---------------+---------------+---------------+
|      a                r       |           (T_NAME_SEGMENT)    |
+---------------+---------------+---------------+---------------+
|           0x02 (2)            |       h       |       i       |
+---------------+---------------+---------------+---------------+

Рисунок 16. Пример кодирования имени.


3.6.1.2. Идентификатор данных Interest

InterestPayloadID — это сегмент имени, создаваемый источником Interest для представления Interest Payload. Это позволяет мультиплексировать Interest на основе имен, если они различаются содержимым. Базовым вариантом является использование хэш-значений Interest Payload в качестве InterestPayloadID.

Как часть поля Value в TLV значение InterestPayloadID содержит 1-октетный идентификатор метода, использованного для создания InterestPayloadID, за которым следует строка октетов переменного размера. От реализаций не требуется поддержка какого-либо метода для приема Interest, поле InterestPayloadID можно считать просто строкой октетов для мультиплексирования Interest с разными данными. Алгоритмы требуется реализовать лишь на устройствах, создающих и проверяющих сегмент имени InterestPayloadID.

В поле применяется кодирование хэш-значений, описанное в параграфе 3.3.3.

При нормальной работе рекомендуется отображать InterestPayloadID просто как строку октетов в CCNx URI.

В InterestPayloadID (даже если это хэш) не следует передавать какой-либо контекст защиты. Если система требует подтверждения события, связанного с созданием Interest Payload, ей следует применять криптографическую подпись Interest в ValidationAlgorithm и ValidationPayload или использовать свой метод внутри Interest Payload.

3.6.2. TLV сообщений

С каждым типом сообщений (Interest и Content Object) связан набор Message TLV. Для создания дополнительных типов могут быть подготовлены другие спецификации.

3.6.2.1. TLV сообщений Interest

В настоящее время имеется два Message TLV, связанных с сообщениями Interest, — селектор KeyIdRestriction и селектор ContentObjectHashRestr, используемые для сущения пространства подходящих Content Object, которые удовлетворяют запросу Interest.


                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
|         MessageType           |         MessageLength         |
+---------------+---------------+---------------+---------------+
| Name TLV                                                      |
+---------------+---------------+---------------+---------------+
/ Необязательный KeyIdRestriction TLV                           /
+---------------------------------------------------------------+
/ Необязательный ContentObjectHashRestriction TLV               /
+---------------------------------------------------------------+

Рисунок 17. Interest Message TLV.

Таблица 8. Типы CCNx Interest Message TLV.

Сокращение

Имя

Описание

T_KEYIDRESTR

KeyIdRestriction (параграф 3.6.2.1.1)

Представление KeyId (параграф 3.3.3).

T_OBJHASHRESTR

ContentObjectHashRestriction (параграф 3.6.2.1.2)

Представление хэш-значения конкретного Content Object, который удовлетворяет Interest (параграф 3.3.3).

3.6.2.1.1. KeyIdRestriction

Сообщение Interest может включать селектор KeyIdRestriction, который задает соответствие Interest лишь объектов Content с совпадающими KeyId (см. параграф 3.6.4.1.4.1).

3.6.2.1.2. ContentObjectHashRestriction

Сообщение Interest может включать селектор ContentObjectHashRestriction. Это хэш-значение Content Object — самосертифицированное ограничение имени, которое должно проверяться в сети, если Interest содержит это расширение (см. параграф 3.4.3). Поле LENGTH должно иметь одно из разрешенных для этого хэширования значений (см. параграф 3.3.3).

ContentObjectHashRestriction следует иметь тип T_SHA-256 и размер 32 байта.

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
|        T_OBJHASHRESTR         |           (LENGTH+4)          |
+---------------+---------------+---------------+---------------+
|        тип хэширования        |             LENGTH            |
+---------------+---------------+---------------+---------------+
/                  LENGTH октетов хэш-значения                  /
+---------------+---------------+---------------+---------------+

Рисунок 18. Кодирование ContentObjectHashRestriction.


3.6.2.2. TLV сообщений Content Object

Для сообщений Content Object в настоящее время определены 2 необязательных TLV — PayloadType и ExpiryTime.


                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
|         MessageType           |         MessageLength         |
+---------------+---------------+---------------+---------------+
| Name TLV                                                      |
+---------------+---------------+---------------+---------------+
/ Необязательный PayloadType TLV                                /
+---------------------------------------------------------------+
/ Необязательный ExpiryTime TLV                                 /
+---------------------------------------------------------------+

Рисунок 19. Content Object Message TLV.

Таблица 9. Типы CCNx Content Object Message TLV.

Сокращение

Имя

Описание

T_PAYLDTYPE

PayloadType (параграф 3.6.2.2.1)

Указывает тип содержимого Payload.

T_EXPIRY

ExpiryTime (параграф 3.6.2.2.2)

Время завершения срока действия Payload, указанное числом миллисекунд с начала эпохи в UTC. При отсутствии этого значения срок действия Content Object не ограничен.

3.6.2.2.1. PayloadType

Октет PayloadType представляет базовый тип Payload TLV.

T_PAYLOADTYPE_DATA

Data (возможно шифрование)

T_PAYLOADTYPE_KEY

Key

T_PAYLOADTYPE_LINK

Link

Тип Data указывает, что Payload в сообщении ContentObject содержит неанализируемые байты приложения. Тип Key показывает, что Payload содержит открытый ключ в DER-представлении. Тип Link указывает, что Payload содержит один или несколько каналов (параграф 3.3.4). При отсутствии поля предполагается тип Data.

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
|            T_PAYLDTYPE        |               1               |
+---------------+---------------+---------------+---------------+
|  PayloadType  |
+---------------+

Рисунок 20. Кодирование PayloadType.


3.6.2.2.2. ExpiryTime

ExpiryTime показывает время окончания срока действия Payload, выраженное числом миллисекунд с начала эпохи в UTC (64-битовое целое число без знака с сетевым порядком байтов). Системе кэширования или конечной системе не следует отдавать отклики с просроченными Content Object (ExpiryTime в прошлом). Маршрутизаторы, пересылающие Content Object, не обязаны проверять ExpiryTime. При отсутствии ExpiryTime срок действия Content Object считается неограниченным, поэтому системы кэширования и конечные системы могут использовать его неограниченно долго.

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
|           T_EXPIRY            |               8               |
+---------------+---------------+---------------+---------------+
/                          ExpiryTime                           /
/                                                               /
+---------------+---------------+---------------+---------------+

Рисунок 21. Кодирование ExpiryTime.


3.6.3. Payload

В Payload TLV передается содержимое пакетов, которое может иметь нулевой размер. Если пакет не содержит данных, это поле следует опускать, не помещая данные с размером 0.

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
|           T_PAYLOAD           |            Length             |
+---------------+---------------+---------------+---------------+
/                        содержимое Payload                     /
+---------------+---------------+---------------+---------------+

Рисунок 22. Кодирование Payload.


3.6.4. Validation

Сообщения Interest и Content Object могут включать информацию, указывающую способ проверки пригодности сообщения CCNx. Эта информация содержится в двух TLV — ValidationAlgorithm и ValidationPayload. Блок ValidationAlgorithm TLV задает механизм проверки сообщения CCNx (например, MIC, MAC или криптографическая подпись). ValidationPayload TLV содержит выход проверки, такой как код CRC32C или подпись RSA.

В сообщениях Interest скорей всего будет применяться только тип MIC — CRC, контрольная сумма или подпись.

3.6.4.1. Алгоритм проверки

ValidationAlgorithm — это набор вложенных TLV, которые содержат всю информацию, требуемую для проверки сообщения. Внешний контейнер имеет тип T_VALIDATION_ALG. Первый вложенный блок TLV определяет конкретный тип проверки, применяемой для сообщения. Тип задается полем ValidationType, как показано на рисунке 23 и описано в таблице 10. В контейнере размещаются TLV для всех зависящих от ValidationType данных (например, идентификатор ключа, его местоположение и т. п.).

Примеры для нескольких типов проверок представлены в параграфе 3.6.4.1.5.


                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
|       T_VALIDATION_ALG        |      ValidationAlgLength      |
+---------------+---------------+---------------+---------------+
|        ValidationType         |            Length             |
+---------------+---------------+---------------+---------------+
/ Зависимые от ValidationType данные                            /
+---------------+---------------+---------------+---------------+

Рисунок 23. Кодирование алгоритма проверки.

Таблица 10. Типы CCNx Validation TLV.

Сокращение

Имя

Описание

T_CRC32C

CRC32C (параграф 3.6.4.1.1)

Castagnoli CRC32 (iSCSI, ext4 и т. п.) с полиномом нормальной формы 0x1EDC6F41.

T_HMAC-SHA256

HMAC-SHA256 (параграф 3.6.4.1.2)

HMAC (RFC 2104) с использованием SHA256.

T_RSA-SHA256

RSA-SHA256 (параграф 3.6.4.1.3)

Подпись RSA с открытым ключом SHA256.

T_EC-SECP-256K1

SECP-256K1 (параграф 3.6.4.1.3)

Подпись на основе эллиптической кривой с параметрами SECP-256K1 [ECC].

T_EC-SECP-384R1

SECP-384R1 (параграф 3.6.4.1.3)

Подпись на основе эллиптической кривой с параметрами SECP-384R1 [ECC].

3.6.4.1.1. Проверка целостности сообщения

Коды MIC не требуют других данных для выполнения проверки (например, CRC32C имеет значение нулевого размера).

3.6.4.1.2. Коды аутентификации сообщений

Коды MAC полезны для коммуникаций между двумя доверяющими одна другой сторонами, которые имеют общий секретный ключ. Примером может служит алгоритм HMAC. MAC использует поле KeyId для указания применяемого секрета. Назначение поля KeyId согласовано между сторонами и это может быть, например, просто номер ключа. Если новый механизм MAC требует дополнительное поле (например, вектор инициализации), это поле должно быть определено в обновленной спецификации.

3.6.4.1.3. Подпись

Тип Signature задает механизм и алгоритм подписи для проверки сообщения. Примеры включают подписи RSA с SHA256, подписи на основе эллиптической кривой с параметрами SECP-256K1 и т. п. Для таких проверок требуется KeyId и механизм получения открытого ключа издателя (KeyLocator), а также может применяться PublicKey, Certificate или KeyLink.

3.6.4.1.4. Зависящие от способа проверки данные

Различные алгоритмы проверки требуют доступа к разным частям данных в ValidationAlgorithm TLV. Как указано выше, Key Id, Key Locator, Public Key, Certificate, Link и Key Name играют роль в разных алгоритмах проверки. В Validation Algorithm TLV может присутствовать любой число зависящих от способа проверки контейнеров данных.

Таблица 11. Типы данных, зависящие от способа проверки.

Сокращение

Имя

Описание

T_KEYID

SignerKeyId (параграф 3.6.4.1.4.1)

Идентификатор общего секрета или открытого ключа, связанного с MAC или Signature.

T_PUBLICKEY

PublicKey (параграф 3.6.4.1.4.2)

Открытый ключ в DER-представлении.

T_CERT

Certificate (параграф 3.6.4.1.4.3)

Ключ X.509 в DER-представлении.

T_KEYLINK

KeyLink (параграф 3.6.4.1.4.4)

Объект CCNx Link.

T_SIGTIME

SignatureTime (параграф 3.6.4.1.4.5)

Временная метка (в миллисекундах) момента созания подписи.

3.6.4.1.4.1. KeyId

KeyId для подписи является идентификатором открытого ключа издателя. Это похоже на Subject Key Identifier в X.509 (см. параграф 4.2.1.2 в [RFC5280]). Значение следует выводить из ключа, использованного для подписи (например, хэш SHA-256 для ключа). Это применимо к системам как с симметричными, так и с открытыми ключами.

KeyId представляется с использованием формата хэш-значений, описанного в параграфе 3.3.3. Если прикладной протокол применяет иной идентификатор, ему следует использовать зарезервированные значения.

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
|            T_KEYID            |            LENGTH+4           |
+---------------+---------------+---------------+---------------+
|          <hash type>          |             LENGTH            |
+---------------+---------------+---------------+---------------+
/                  LENGTH октетов хэш-значения                  /
+---------------+---------------+---------------+---------------+

Рисунок 24. Кодирование KeyId.


3.6.4.1.4.2. Открытый ключ

Открытый ключ указывается DER-представлением блока SPKI9 как в сертификате X.509.

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
|          T_PUBLICKEY          |            Length             |
+---------------+---------------+---------------+---------------+
/           Открытый ключ (DER-представление SPKI)              /
+---------------+---------------+---------------+---------------+

Рисунок 25. Кодирование открытого ключа.


3.6.4.1.4.3. Сертификат

Certificate указывается DER-представлением сертификата X.509. KeyId (параграф 3.6.4.1.4.1) выводится из этого представления.

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
|            T_CERT             |            Length             |
+---------------+---------------+---------------+---------------+
/             Certificate (DER-представление X.509)             /
+---------------+---------------+---------------+---------------+

Рисунок 26. Кодирование сертификата.


3.6.4.1.4.4. KeyLink

KeyLink типа KeyLocator представляет Link.

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+-------------------------------+
|          T_KEYLINK            |            Length             |
+---------------+---------------+-------------------------------+
/ Link                                                          /
+---------------------------------------------------------------+

Рисунок 27. Кодирование KeyLink.


При наличии KeyLink ContentObjectHashRestr это поле содержит дайджест Content Object, указанный KeyLink, а не подпись открытого ключа. Аналогично, KeyIdRestr в KeyLink является KeyId для ContentObject, а не обязательно «завернутого» ключа.

3.6.4.1.4.5. SignatureTime

SignatureTime указывает временную метку (в миллисекундах) момента создания подписи. Подписывающий устанавливает это поле в соответствии с текущим временем. Проверяющий может использовать это значение для проверки того, что подпись была создана в период действия ключа или это поисходило в разумной последовательности с другими связанными подписями. Значение SignatureTime не связано с моментом создания сообщения CCNx (оно могло быть создано задолго до подписания). По умоланию принято включать SignatureTime при создании аутентифицированных сообщений (например, HMAC или RSA).

SignatureTime является 64-битовым целым числом без знака с сетевым порядком байтов, которое указывает число миллисекунд с начала эпохи в UTC при создании подписи.

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+-------------------------------+
|           T_SIGTIME           |               8               |
+---------------+---------------+-------------------------------+
/                         SignatureTime                         /
+---------------------------------------------------------------+

Рисунок 28. Кодирование SignatureTime.


3.6.4.1.5. Примеры проверок

Как пример проверки типа MIC кодирование CRC32C может иметь вид, представленный ниже.

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
|      T_VALIDATION_ALG         |               4               |
+---------------+---------------+---------------+---------------+
|            T_CRC32C           |               0               |
+---------------+---------------+---------------+---------------+

Рисунок 29. Пример кодирования CRC32C.


Как пример проверки типа MAC кодирование HMAC с использованием SHA256 может иметь вид

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
|       T_VALIDATION_ALG        |               40              |
+---------------+---------------+---------------+---------------+
|        T_HMAC-SHA256          |               36              |
+---------------+---------------+---------------+---------------+
|             T_KEYID           |               32              |
+---------------+---------------+---------------+---------------+
/                            KeyId                              /
/---------------+---------------+-------------------------------+

Рисунок 30. Пример кодирования HMAC-SHA256.


Как пример проверки типа Signature кодирование подписи с открытым клюом RSA при использовании подписи SHA256 и Public может иметь вид

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
|       T_VALIDATION_ALG        |   44 octets + Variable Length |
+---------------+---------------+---------------+---------------+
|          T_RSA-SHA256         |   40 octets + Variable Length |
+---------------+---------------+---------------+---------------+
|             T_KEYID           |               32              |
+---------------+---------------+---------------+---------------+
/                            KeyId                              /
/---------------+---------------+-------------------------------+
|          T_PUBLICKEY          |  Variable Length (~160 octets)|
+---------------+---------------+---------------+---------------+
/                Public Key (DER-encoded SPKI)                  /
+---------------+---------------+---------------+---------------+

Рисунок 31. Пример кодирования RSA-SHA256.


3.6.4.2. Данные Validation
                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
|     T_VALIDATION_PAYLOAD      |  ValidationPayloadLength      |
+---------------+---------------+---------------+---------------+
/ Type-dependent data                                           /
+---------------+---------------+---------------+---------------+

Рисунок 32. Пример кодирования данных проверки.


ValidationPayload содержит вывод проверки, такой как код CRC32C или подпись RSA.

4. Взаимодействие с IANA

В этом разделе подробно описаны все типы значений протокола CCNx, которые могут регистрироваться. Каждый реестр может обновляться путем постепенного расширения пространства, например, за счет выделения и резервирования новых типов. В соответствии с [RFC8126] этот раздел описывает создание реестра Content-Centric Networking (CCNx) и его субреестров.

4.1. Реестр типов пакетов

Агентство IANA создало реестр CCNx Packet Types и выделило значения для типа пакетов, приведенные ниже. Регистрация выполняется по процедуре RFC Required. Размер Type составляет 1 октет, диапазон — 0x00-0xFF.

Типы пакетов.

 

Тип

Имя

Документ

0x00

PT_INTEREST

Фиксированные заголовки (параграф 3.2)

0x01

PT_CONTENT

Фиксированные заголовки (параграф 3.2)

0x02

PT_RETURN

Фиксированные заголовки (параграф 3.2)

 

4.2. Реестр кодов Interest Return

Агентство IANA создало реестр CCNx Interest Return Code Types и выделило значения кодов, приведенные ниже. Регистрация выполняется по процедуре RFC Required. Размер Type составляет 1 октет, диапазон — 0x00-0xFF.

Типы CCNx Interest Return.

 

Тип

Имя

Документ

0x00

Резерв

0x01

T_RETURN_NO_ROUTE

Фиксированные заголовки (параграф 3.2.3.3)

0x02

T_RETURN_LIMIT_EXCEEDED

Фиксированные заголовки (параграф 3.2.3.3)

0x03

T_RETURN_NO_RESOURCES

Фиксированные заголовки (параграф 3.2.3.3)

0x04

T_RETURN_PATH_ERROR

Фиксированные заголовки (параграф 3.2.3.3)

0x05

T_RETURN_PROHIBITED

Фиксированные заголовки (параграф 3.2.3.3)

0x06

T_RETURN_CONGESTED

Фиксированные заголовки (параграф 3.2.3.3)

0x07

T_RETURN_MTU_TOO_LARGE

Фиксированные заголовки (параграф 3.2.3.3)

0x08

T_RETURN_UNSUPPORTED_HASH_RESTRICTION

Фиксированные заголовки (параграф 3.2.3.3)

0x09

T_RETURN_MALFORMED_INTEREST

Фиксированные заголовки (параграф 3.2.3.3)

 

4.3. Реестр типов Hop-by-Hop

Агентство IANA создало реестр CCNx Hop-by-Hop Types и выделило значения кодов, приведенные ниже. Регистрация выполняется по процедуре RFC Required. Размер Type составляет 2 октета, диапазон — 0x0000-0xFFFF.

Типы CCNx Hop-by-Hop

 

Тип

Имя

Документ

0x0000

Резерв

0x0001

T_INTLIFE

TLV поэтапных заголовков (параграф 3.4)

0x0002

T_CACHETIME

TLV поэтапных заголовков (параграф 3.4)

0x0003

T_MSGHASH

TLV поэтапных заголовков (параграф 3.4)

0x0004 — 0x0007

Резерв

0x0FFE

T_PAD

Заполнение (параграф 3.3.1)

0x0FFF

T_ORG

Фирменные TLV (параграф 3.3.2)

0x1000 — 0x1FFF

Резерв

Экспериментальное использование (раздел 3)

 

4.4. Реестр типов верхнего уровня

Агентство IANA создало реестр CCNx Top-Level Types и выделило значения кодов, приведенные ниже. Регистрация выполняется по процедуре RFC Required. Размер Type составляет 2 октета, диапазон — 0x0000-0xFFFF.

Типы верхнего уровня CCNx

 

Тип

Имя

Документ

0x0000

Резерв

0x0001

T_INTEREST

Типы верхнего уровня (параграф 3.5)

0x0002

T_OBJECT

Типы верхнего уровня (параграф 3.5)

0x0003

T_VALIDATION_ALG

Типы верхнего уровня (параграф 3.5)

0x0004

T_VALIDATION_PAYLOAD

Типы верхнего уровня (параграф 3.5)

 

4.5. Реестр типов сегментов имен

Агентство IANA создало реестр CCNx Name Segment Types и выделило значения кодов, приведенные ниже. Регистрация выполняется по процедуре RFC Required. Размер Type составляет 2 октета, диапазон — 0x0000-0xFFFF.

Типы сегментов имен CCNx.

 

Тип

Имя

Документ

0x0000

Резерв

0x0001

T_NAMESEGMENT

Name (параграф 3.6.1)

0x0002

T_IPID

Name (параграф 3.6.1)

0x0010 — 0x0013

Резерв

RFC 8609

0x0FFF

T_ORG

Фирменные TLV (параграф 3.3.2)

0x1000 — 0x1FFF

T_APP:00 — T_APP:4096

Сегменты имен (параграф 3.6.1.1)

 

4.6. Реестр типов сообщений

Агентство IANA создало реестр CCNx Message Types и выделило значения кодов, приведенные ниже. Регистрация выполняется по процедуре RFC Required. Размер Type составляет 2 октета, диапазон — 0x0000-0xFFFF.

Типы сообщений CCNx.

 

Тип

Имя

Документ

0x0000

T_NAME

TLV сообщений CCNx (параграф 3.6)

0x0001

T_PAYLOAD

TLV сообщений CCNx (параграф 3.6)

0x0002

T_KEYIDRESTR

TLV сообщений CCNx (параграф 3.6)

0x0003

T_OBJHASHRESTR

TLV сообщений CCNx (параграф 3.6)

0x0005

T_PAYLDTYPE

TLV сообщений Content Object (параграф 3.6.2.2)

0x0006

T_EXPIRY

TLV сообщений Content Object (параграф 3.6.2.2)

0x0007 — 0x000C

Резерв

RFC 8609

0x0FFE

T_PAD

Заполнение (параграф 3.3.1)

0x0FFF

T_ORG

Фирменные TLV (параграф 3.3.2)

0x1000-0x1FFF

Резерв

Экспериментальное использование (раздел 3)

 

4.7. Реестр типов данных

Агентство IANA создало реестр CCNx Payload Types и выделило значения кодов, приведенные ниже. Регистрация выполняется по процедуре Specification Required. Размер Type составляет 1 октет, диапазон — 0x00-0xFF.

Типы CCNx Payload.

 

Тип

Имя

Документ

0x00

T_PAYLOADTYPE_DATA

PayloadType (параграф 3.6.2.2.1)

0x01

T_PAYLOADTYPE_KEY

PayloadType (параграф 3.6.2.2.1)

0x02

T_PAYLOADTYPE_LINK

PayloadType (параграф 3.6.2.2.1)

 

4.8. Реестр типов алгоритма проверки

Агентство IANA создало реестр CCNx Validation Algorithm Types и выделило значения кодов, приведенные ниже. Регистрация выполняется по процедуре Specification Required. Размер Type составляет 2 октета, диапазон — 0x0000-0xFFFF.

Типы алгоритмов проверки CCNx.

 

Тип

Имя

Документ

0x0000

Резерв

0x0002

T_CRC32C

Алгоритм проверки (параграф 3.6.4.1)

0x0004

T_HMAC-SHA256

Алгоритм проверки (параграф 3.6.4.1)

0x0005

T_RSA-SHA256

Алгоритм проверки (параграф 3.6.4.1)

0x0006

T_EC-SECP-256K1

Алгоритм проверки (параграф 3.6.4.1)

0x0007

T_EC-SECP-384R1

Алгоритм проверки (параграф 3.6.4.1)

0x0FFE

T_PAD

Заполнение (параграф 3.3.1)

0x0FFF

T_ORG

Фирменные TLV (параграф 3.3.2)

0x1000 — 0x1FFF

Резерв

Экспериментальное использование (раздел 3)

 

4.9. Реестр зависимых от типа проверки данных

Агентство IANA создало реестр CCNx Validation-Dependent Data Types и выделило значения кодов, приведенные ниже. Регистрация выполняется по процедуре RFC Required. Размер Type составляет 2 октета, диапазон — 0x0000-0xFFFF.

Зависящие от способа проверки типы данных CCNx.

 

Тип

Имя

Документ

0x0000

Резерв

0x0009

T_KEYID

Зависящие от способа проверки данные (параграф 3.6.4.1.4)

0x000A

T_PUBLICKEYLOC

Зависящие от способа проверки данные (параграф 3.6.4.1.4)

0x000B

T_PUBLICKEY

Зависящие от способа проверки данные (параграф 3.6.4.1.4)

0x000C

T_CERT

Зависящие от способа проверки данные (параграф 3.6.4.1.4)

0x000D

T_LINK

Зависящие от способа проверки данные (параграф 3.6.4.1.4)

0x000E

T_KEYLINK

Зависящие от способа проверки данные (параграф 3.6.4.1.4)

0x000F

T_SIGTIME

Зависящие от способа проверки данные (параграф 3.6.4.1.4)

0x0FFF

T_ORG

Фирменные TLV (параграф 3.3.2)

0x1000-0x1FFF

Резерв

Экспериментальное использование (раздел 3)

 

4.10. Реестр типов хэш-функций

Агентство IANA создало реестр CCNx Hash Function Types и выделило значения кодов, приведенные ниже. Регистрация выполняется по процедуре Specification Required. Размер Type составляет 2 октета, диапазон — 0x0000-0xFFFF.

Типы хэш-функций CCNx.

 

Тип

Имя

Документ

0x0000

Резерв

0x0001

T_SHA-256

Формат хэш-значений (параграф 3.3.3)

0x0002

T_SHA-512

Формат хэш-значений (параграф 3.3.3)

0x0FFF

T_ORG

Фирменные TLV (параграф 3.3.2)

0x1000-0x1FFF

Резерв

Экспериментальное использование (раздел 3)

 

5. Вопросы безопасности

CCNx является протоколом сетевого уровня (L3), котрый может работать в режиме наложения с использованием такого транспорта, как UDP или туннели. Протокол имеет встроенную поддержку аутентификации сообщений с помощью подписи (например, RSA или эллиптическая кривая) или кода аутентификации (например, HMAC). Взамен аутентификатора может применяться проверка целостности сообщения (например, SHA или CRC). CCNx не определяет «конверт» шифрования, оставляя это вышележащим протоколам (например, [esic]).

Формат пакетов CCNx позволяет присоединить MIC (например, CRC32C), MAC (например, HMAC) и подписи (например, RSA или ECDSA) к пакетам любого типа. Это не означает, что хорошей идеей будет использование произвольного ValidationAlgorithm или включать ресурсоемкие алгоритмы в пакеты Interest, поскольку это может приводить к DoS-атакам за счет ычислений. Приложениям следует использовать явный протокол для руководства применением подписей пакетов. В качестве общего руководства приложения могут использовать MIC в сообщениях Interest для обнаружения непреднамеренно поврежденных пакетов. Если нужна защита Interest, следует рассмотреть возможность шифрования и протокол, предотвращающий атаки с повторным использованием, особенно при использовании Interest в качестве исполнительного механизма (actuator). Простое применение кода аутентификации или подписи не обеспечивает защиты Interest. В литературе имеется несколько примеров защиты обмена сообщениями в стиле ICN [mobile] [ace].

Поскольку документ относится к протоколу L3, он не описывает способов доставки ключей и механизмов доверия к ним. Content Object в CCNx может включать открытый ключ или сертификат, а также может использовать поле KeyLink для указания открытого ключа или сертификата для проверки подлинности сообщения. Одной из спецификаций обмена ключами является CCNxKE [ccnx-ke] [mobile], где обмен похож на процедуру TLS 1.3, отличаясь тем, что происходит через сообщения CCNx L3. Вопросы доверия выходят за рамки протокола L3 и решаются приложениями.

Комбинация обмена эфемерными ключами (например, CCNxKE [ccnx-ke]) с инкапсулирующим шифрованием (например, [esic]) обеспечивает эквивалент туннеля TLS. Промежуточные узлы могут пересылать сообщения Interest и Content Object, но не будут видеть их содержимого. Это также полностью скрывает внутренние имена, заменяя их именами, используемыми уровнем шифрования. Этот тип туннельного шифрования полезен для передачи содержимого, которое не мало или совсем не подходит для кэширования, поскольку оно может применяться лишь теми, кто знает эфемерный ключ. Краткосрочное кэширование может помочь на каналах с потерями, но длительное кэширование обычно не представляет интереса.

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

Конкретное кодирование сообщений будет влиять на безопасность. В [RFC8609] применяется кодирование TLV. Был выбран компромисс между расширяемостью и однозначностью кодирования типа и размера. Некоторые TLV используют поля T и L переменного размера, чтобы вместить более широкий диапазон значений с сохранением эффективного использования байтов. Здесь TLV кодируются с 2-байтовыми полями T и L, что решает 2 проблемы. Первая проблема связана с псевдонимами. Если можно кодировать одно значение в полях разного размера (например, %x02 и %x0002), кто-то может счесть их одним, а другой — разными. Если есть различие, оно должно определяться в буферах, а не числовом представлении. Если от этого отказаться, придется проверять кодирование TLV в каждом поле каждого пакета на всех узлах пересылки. Если они одинаковы, возникает другая проблема — как задавать фильтры. Например, если имя включает 6 компонент, имеется 7 полей T и 7 полей L, каждое из которых может иметь до 4 представлений одного значения. В результате имеется 14 полей с 4 представлениями для каждого или «1001 комбинация». Это также означает невозможность сравнения, например, имени через функции памяти, поскольку нужно учитывать разные форматы T и L.

Сообщение Interest Return не имеет аутентификатора от предыдущего интервала. Поэтому данные из Interest Return следует применять лишь локально для сопоставления с Interest. Узлу не следует пересылать эти Interest Payload как Interest. Он должен также убедиться, что передал Interest в Interest Return нужному узлу и не позволять кому-либо отменять сообщения Interest.

Кэширующие узлы должны соблюдать осторожность при обработке Content Object. Важно, чтобы хранилище Content Store следовало правилам параграфа 2.4.3 во избежание некоторых типов атак. CCNx 1.0 не имеет механизмов обхода нежелательных результатов из сети (нет «исключений»), поэтому при отравлении кэша непригодным содержимым это может вызвать проблемы при поиске. Существует 3 типа доступа к содержимому из Content Store — неограниченный, а также ограниченные подписью и хэш-значением. Если Interest не имеет ограничений, запрашивающая сторона не заботится о том, что она получит в ответ и подойдет любой кэшированный объект. При ограничении по хэш-значению запрашивающая сторона очень точно определяет желаемый результат и Content Store (и каждый пересылающий узел) может легко проверить соответствие содержимого запросу. При ограничении подписью (часто служит для начального обнаружения манифеста) запрашивающий знает лишь KeyId для подписи содержимого. Этот случай требует пристального внимания в Content Store, чтобы избежать усиления неверных данных. Хранилище Content Store должно отвечать лищь объектами Content с проверенной подписью. Это значит, что Content Object содержит в себе открытый ключ или Interest передает открытый ключ в дополнение к KeyId. Если это не выполняется, хранилищу Content Store следует рассматривать Interest как отсутствие кэша и позволять конечной точке ответить.

Кэш пользовательского уровня может выполнять полную проверку подписи путем извлечения открытого ключа или сертификата по KeyLink. Однако это не та задача, которую можно отдать узлу пересылки. Пользовательский кэш может также полагаться на внешнюю (out-of-band) аттестацию, например, если оператор кэша включает лишь информацию, для которой у него есть корректная подпись.

Грамматика CCNx обеспечивает гибкость алгоритма хэширования с помощью HashType, указывая список приемлемых алгоритмов, которые следует реализовать на каждом узле пересылки. Некоторые типы пригодны лишь для конечных систем и обновление их не влияет на узлы пересылки, которые будут просто сопоставлять буферы, включающие type-length-hash. Некоторые поля (например, ConObjHash) должны проверяться на каждом узле, поэтому узел пересылки (или связанная с ним система) должен знать алгоритм хэширования. Это может вызвать проблемы совместимости при смене типа хэша. [RFC8609] является официальным источником данных о разрешенных типах хэширования.

Для имен CCNx применяется двоичное сопоставление, тогда как для URI используются имена хостов без учета регистра. Некоторые системы могут применять независимое от регистра сопоставление путей URI к ресурсу. В результате введенные человеком имена CCNx будут скорей всего сталкиваться с несоответствием символов разных регистров и символы не-ASCII, если не применять нормализацию URI для имен CCNx. Это означает, что объект, регистрирующий маршрутизируемый префикс CCNx, скажем ccnx:/example.com, должен зарегистрировать варианты типа ccnx:/Example.com. Если это не учтено в нормализации URI normalization и соглашениях протокола маршрутизации, становятся возможными фишинговые атаки.

Более общее рассмотрение вопросов безопасности ICN приведено в [RFC7927] и [RFC7945].

6. Литература

6.1. Нормативные документы

[RFC2119] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC8174] Leiba, B., «Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words», BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

6.2. Дополнительная литература

[ace] Shang, W., Yu, Y., Liang, T., Zhang, B., and L. Zhang, «NDN-ACE: Access control for constrained environments over named data networking», NDN Technical Report NDN-0036, 2015, <http://new.named-data.net/wp-content/uploads/2015/12/ndn-0036-1-ndn-ace.pdf>.

[ccnxke] Mosko, M., Uzun, E., and C. Wood, «CCNx Key Exchange Protocol Version 1.0», Work in Progress, draft-wood-icnrg-ccnxkeyexchange-02, March 2017.

[CCNxURI] Mosko, M. and C. Wood, «The CCNx URI Scheme», Work in Progress, draft-mosko-icnrg-ccnxurischeme-01, April 2016.

[CCNxz] Mosko, M., «CCNxz TLV Header Compression Experimental Code», commit f1093a2, March 2018, <https://github.com/PARC/CCNxz>.

[compress] Mosko, M., «Header Compression for TLV-based Packets», ICNRG Interim Meeting, 2016, <https://datatracker.ietf.org/meeting/interim-2016-icnrg-02/materials/slides-interim-2016-icnrg-2-7>.

[ECC] Certicom Research, «SEC 2: Recommended Elliptic Curve Domain Parameters», 2010, <http://www.secg.org/sec2-v2.pdf>.

[esic] Mosko, M. and C. Wood, «Encrypted Sessions In CCNx (ESIC)», Work in Progress, draft-wood-icnrg-esic-01, September 2017.

[IANA-PEN] IANA, «Private Enterprise Numbers», <http://www.iana.org/assignments/enterprise-numbers>.

[mobile] Mosko, M., Uzun, E., and C. Wood, «Mobile Sessions in Content-Centric Networks», IFIP Networking, 2017, <http://dl.ifip.org/db/conf/networking/networking2017/1570334964.pdf>.

[nnc] Jacobson, V., Smetters, D., Thornton, J., Plass, M., Briggs, N., and R. Braynard, «Networking Named Content», Proceedings of the 5th international conference on Emerging networking experiments and technologies (CoNEXT ’09), 2009, <http://dx.doi.org/10.1145/1658939.1658941>.

[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, «Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile», RFC 5280, DOI 10.17487/RFC5280, May 2008, <https://www.rfc-editor.org/info/rfc5280>.

[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>.

[RFC7945] Pentikousis, K., Ed., Ohlman, B., Davies, E., Spirou, S., and G. Boggia, «Information-Centric Networking: Evaluation and Security Considerations», RFC 7945, DOI 10.17487/RFC7945, September 2016, <https://www.rfc-editor.org/info/rfc7945>.

[RFC8126] Cotton, M., Leiba, B., and T. Narten, «Guidelines for Writing an IANA Considerations Section in RFCs», BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.

[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>.

Адреса авторов

Marc Mosko

PARC, Inc.

Palo Alto, California 94304

United States of America

Phone: +01 650-812-4405

Email: mmosko@parc.com

Ignacio Solis

LinkedIn

Mountain View, California 94043

United States of America

Email: nsolis@linkedin.com

Christopher A. Wood

University of California, Irvine

Irvine, California 92697

United States of America

Phone: +01 315-806-5939

Email: woodc1@uci.edu


Перевод на русский язык

Николай Малых

nmalykh@protocols.ru

1Content-Centric Networking — ориентированные на содержимое сети.

2Information-Centric Networking Research Group — группа по исследованию ориентированных на информацию сетей.

3Internet Research Task Force.

4Type-Length-Value — тип, размер, значение.

5Information-Centric Networking — ориентированная на информацию сеть.

6Recommended Cache Time — рекомендуемое время кэширования.

7Message Integrity Check — код целостности сообщения.

8Message Authentication Code — код аутентификации сообщения.

9Subject Public Key Info — информация о субъекте открытого ключа.




RFC 8569 Content-Centric Networking (CCNx) Semantics

Internet Research Task Force (IRTF)                             M. Mosko
Request for Comments: 8569                                    PARC, Inc.
Category: Experimental                                          I. Solis
ISSN: 2070-1721                                                 LinkedIn
                                                                 C. Wood
                                         University of California Irvine
                                                               July 2019

Content-Centric Networking (CCNx) Semantics

Семантика ориентированных на содержимое сетей (CCNx)

PDF

Тезисы

Этот документ описывает базовые концепции архитектуры ориентированных на содержимое сетей (CCNx1) и представляет сетевой протокол, основанный на двух сообщениях с объектами Interests и Content. Документ задает набор обязательных и опциональных полей в этих сообщениях, а также описывает их поведение и интерпретацию. Эта архитектура и протокол не зависят от представления сигналов в линиях передачи.

Протокол также применяет управляющие сообщения Interest Return, посредством которых одна система может возвращать сообщения Interest на предыдущий интервал пересылки (hop) при возникновении ошибки. Это указывает предыдущему интервалу, что текущая система не будет отвечать на Interest.

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

Статус документа

Документ не является спецификацией стандартного протокола Internet (Standards Track) и публикуется для проверки, экспериментальной реализации и оценки.

Документ определяет экспериментальный протокол для сообщества Internet. Документ является результатом работы IRTF3. IRTF публикует результаты связанных с Internet исследований и разработок. Эти результаты могут оказаться не подходящими для развертывания. Данный RFC представляет согласованное мнение группы ICNRG в составе IRTF. Документ одобрен для публикации IRSG и не претендует на роль стандарта Internet (см. раздел 2 в RFC 7841).

Информацию о текущем статусе документа, ошибках и способах обратной связи можно найти по ссылке https://www.rfc-editor.org/info/rfc8569.

Авторские права

Авторские права (Copyright (c) 2019) принадлежат IETF Trust и лицам, указанным в качестве авторов документа. Все права защищены.

Документ является субъектом прав и ограничений, указанных в BCP 78 и IETF Trust Legal Provisions и относящихся к документам IETF (http://trustee.ietf.org/license-info), на момент публикации данного документа. Прочтите упомянутые документы внимательно, поскольку в них описаны права и ограничения, относящиеся к данному документу.

Оглавление

Исключено в версии HTML.

1. Введение

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

Протокол CCNx основан на ранних работах ICN, выполненных Jacobson и др. [nnc]. Версия Jacobson для CCNx известна как 0.x (CCNx 0.x), а настоящая работа имеет версию 1.0 (CCNx 1.0). Имеются две активные реализации CCNx 1.0. Наиболее полной является Community ICN (CICN) [cicn] — проект Linux Foundation, размещенный на fd.io. Другой активной реализацией является CCN-lite [ccn-lite], поддерживающая системы IoT6 и операционную систему RIOT. CCNx 0.x стал основой для университетского проекта NDN7 [ndn].

Текущая спецификация CCNx 1.0 отличается от CCNx 0.x в нескольких значимых областях. Наиболее явное поведенческое различие между CCNx 0.x и CCNx 1.0 состоит в том, что CCNx 1.0 имеет более простую обработку откликов. В обоих версиях пересылающие узлы используют иерархическое сопоставление самого длинного совпадающего префикса с информационной базой пересылки (FIB8) для отправки запроса через сеть в систему, которая может выдать ответ. Пересылающий узел должен затем сопоставить имя отклика с именем запроса для определения обратного пути и доставить отклик запрашивающему. В CCNx 0.x имя Interest может быть иерархическим префиксом имени отклика, который позволяет обнаруживать содержимое на уровне 3 (L3). В CCNx 1.0 имя отклика должно совпадать с именем запроса. Обнаружение содержимого выполняет протокол вышележащего уровня.

Протокол селекторов CCNx Selectors [selectors] является примером использования протокола вышележащего уровня над CCNx 1.0 L3 для обнаружения содержимого. Протокол селекторов использует метод, похожий на исходные методы CCNx 0.x, не требуя частичного сопоставления имен откликов и запросов в пересылающем узле.

Этот документ представляет согласованную точку зрения группы ICNRG. Это первый протокол ICN исследовательской группы, созданный на основе раннего протокола CCNx [nnc] с существенным пересмотром и вкладом сообщества ICN и членов исследовательской группы. Документ прошел критический обзор нескольких членов сообщества ICN и исследовательской группы. Авторы и руководитель исследовательской группы одобрили документ. Документ поддержан IRTF, выпущен без участия IETF и не является стандартом IETF. Это экспериментальный протокол, который может не подойти для конкретных применений. Спецификация в будущем может измениться.

1.1. Уровни требований

Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не следует (SHALL NOT), следует (SHOULD), не нужно (SHOULD NOT), рекомендуется (RECOMMENDED), не рекомендуется (NOT RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе интерпретируются в соответствии с BCP 14 [RFC2119] [RFC8174] тогда и только тогда, когда они выделены шрифтом, как показано здесь.

1.2. Архитектура

Опишем архитектуру сети, в которой работает CCNx и введем некоторые термины из [terminology]. Подробное описание всех компонент и грамматика сообщений рассмотрены в разделе 2.

Производителем (producer) или издателем (publisher) является конечная точка, которая инкапсулирует содержимое в объекты Content для транспортировки в сеть CCNx. Издатель имеет открытый и секретный ключ, а также подписывает (напрямую или опосредованно) объекты Content. Обычно идентификатор открытого ключа издателя KeyId (хэш открытого ключа) широко известен или может быть выведен из пространства имен издателя стандартным путем.

Издатель оперирует в одном или нескольких пространствах имен, которые являются префиксами имен, представленными в информационных базах пересылки (FIB). Это позволяет запросу достичь издателя и получить отклик (если он существует).

Таблица FIB говорит пересылающему узлу, куда направить запрос. Она может указывать локальное приложение, локальный кэш или хранилище содержимого (Content Store), а также удаленную систему. Если в FIB не найдено соответствующей записи, узел пересылки не может обработать запрос. Детали правил сопоставления имен с FIB приведены в параграфе 2.4.4. Конечная точка имеет FIB, хотя это может быть простой маршрут, принятый по умолчанию. Промежуточные системы (т. е. маршрутизаторы) обычно имеют более крупные базы FIB. Центральный узел пересылки CCNx, например, будет знать все глобальные маршруты.

Потребителем является конечная точка, запрашивающая имя. Этот документ не описывает способов выяснения имен или KeyId издателей потребителями — протокол вышележащего уровня, работающий на основе CCNx, выполняет функции машины поиска и служб поиска или общеизвестных имен. Потребитель создает запрос, называемый Interest (интерес), и пересылает его через FIB конечной точки. Потребитель должен получить ответ на запрос (объект Content), соответствующий Interest, или управляющее сообщение (Interest Return), указывающее невыполнимость запроса.

Имеется 3 способа обнаружения ошибок при обработке Interest. Interest Return представляет собой управляющее сообщение, которое указывает ошибку низкого уровня, такую как отсутствие маршрута (no route) или нехватку ресурсов (out of resources). Если Interest приходит к издателю, но у того нет запрошенного содержимого, издателю следует передать зависящее от приложения сообщение об ошибке (например, not found — не найдено). Наконец, потребитель может не получить ничего (тайм-аут) и, в зависимости от приложения, ему следует повторить запрос или вернуть ошибку приложению.

1.3. Обзор протокола

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

Имя CCNx представляет собой иерархическую последовательность сегментов имен, каждый из которых имеет тип и может иметь значение. Сопоставление двух имен выполняется путем посегментного двоичного сравнения типа и значения. Удобная для человека форма определена по схеме URI «ccnx:» [ccnx-uri], хотя каноническое кодирование имен представляет собой последовательность пар (тип, строка октетов). К сегментам имен не предъявляется требований удобочитаемости или кодировки UTF-8. Первые несколько сегментов имени будут сопоставляться с FIB и протокол маршрутизации может вносить свои ограничения для компонент маршрутизируемого имени (например, максимальный размер или правила кодирования символов). В принципе сегменты имен и имена могут иметь неограниченный размер, хотя на практике они ограничиваются кодированием в линии и практическими соображениями протоколов маршрутизации. Отметим, что в CCNx для сегментов имен применяется двоичное сравнение, тогда как в URI — имена хостов сравниваются без учета регистра символов (обусловлено DNS).

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

CCNx является протоколом запросов и откликов, выбирающим блоки данных (chunk) по именам. Целостность каждого блока может быть подтверждена напрямую с помощью цифровой подписи или кода MAC9, а также опосредованно с помощью хэш-цепочек. Блоки также могут включать более слабые коды MIC10 или совсем не использовать защиты целостности. Поскольку информация об источнике передается в каждом блоке (или более крупном блоке с защитой целостности), больше не нужно полагаться на идентификацию хоста, такую как сертификат TLS, для подтверждения легитимности блока. Таким образом, целостность данных является основным свойством CCNx и не зависит от канала передачи данных. Имеется несколько вариантов защиты конфиденциальности, рассмотренных ниже.

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

Важная концепция CCNx заключается в том, что субъективное имя криптографически связывается с фиксированными данными (payload). Эти создаваемые издателями привязки можно проверить криптографическими методами. Именованные данные в результате являются кортежами {{Name, ExtraFields, Payload, ValidationAlgorithm}, ValidationPayload}, где все поля внутреннего кортежа учитываются в проверочных полях (например, в подписи). Потребители данных могут проверить целостность этих блоков путем выполнения расчета тех же криптографических хэш-значений и сравнения с цифровыми подписями в ValidationPayload.

В дополнение к цифровым подписям (например, RSA) CCNx поддерживает коды проверки подлинности (например, HMAC11) и целостности (например, CRC12). Для поддержки криптографических привязок следует применять по меньшей мере одну подпись или код аутентификации, но это требуется не для всех объектов. Например, первый объект с подписью может охватывать другие объекты с помощью хэш-цепочки, дерева Merkle или подписанного манифеста. Последующие объекты могут не иметь каких-либо проверок и полагаться лишь на ссылки. Код целостности (например, CRC) предназначен для обнаружения случайных повреждений в Interest.

CCNx задает сетевой протокол для объектов Interest (запросные сообщения) и Content (отклики) для переноса именованных данных. Interest включает поле Name, которое указывает желаемый отклик, и необязательные ограничения по соответствию, определяющие подходящие объекты Content. Имеется два ограничения — для идентификатора ключа (KeyIdRestr) и хэш-значения объекта Content (ContentObjectHashRestr). Первое ограничение для KeyId позволяет отобрать отклики с полем ValidationAlgorithm KeyId, соответствующим заданному значению. Второе ограничение позволяет выбрать отклики, в которых криптографическое хэш-значение совпадает с заданным ограничением. В разделе 9 описано применение этих ограничений при сопоставлении объектов Content с Interest.

Иерархия имен CCNx служит для маршрутизации по максимальному соответствию префиксов в узлах пересылки. Максимальным совпадением префиксов является рассчитанный сегмент имени за сегментом в иерархическом имени, где все сегменты совпадают. Глобальной маршрутизации префиксов не требуется. В рамках развертывания может применяться любая локальная маршрутизация, даже если она использует один плоский (без иерархии) сегмент имени.

Другая концепция CCNx заключается в наличии баланса между потоками сообщений Interest и Content Object. На уровне сети сообщение Interest, проходящее по одному пути, должно вызывать не более одного отклика Content Object. Если некоторые узлы передают Interest по разным путям, таким узлам следует объединять отклики, чтобы к запрашивающему приходил лишь один поток Content Object. При передаче Interest в широковещательном или групповом режиме, отправителю следует быть готовым к множеству откликов, если не применяется зависимый от среды механизм, такой как подавление «болтовни» или выбор ведущего.

По мере перемещения Interest в направлении следующей таблицы FIB устанавливается состояние на каждом узле пересылки, так что ответ Content Object может возвращаться к исходному запрашивающему (запрашивающим) без необходимости включения запрашивающей стороной маршрутизируемого адреса возврата. Применяется смысловая таблица PIT13 в качестве метода хранения состояний, упрощающих возврат Content Object.

Таблица PIT хранит последний интервал (hop) для Interest, а также поле Name и необязательные ограничения. Эти данные нужны для сопоставления Content Object с Interest (см. раздел 9). При поступлении Content Object он сопоставляется с PIT для определения подходящей записи. Для каждой такой записи передается не более одного Content Object в каждый указанный в таблице PIT последний интервал.

Реальные таблицы PIT не задаются данной спецификацией. Реализация может применять любой метод, обеспечивающий такое же внешнее поведение. Имеются исследовательские работы, где применялись методы, подобные коммутации по меткам в некоторых частях сети для снижения на узлах числа состояний, создаваемых PIT [dart]. Некоторые реализации хранят состояния PIT в FIB, не используя второй таблицы.

Если на узел приходит множество Interest с одинаковыми {Name, [KeyIdRestr], [ContentObjectHashRestr]} до прибытия Content Object, соответствующего первому Interest, они группируются в одну запись PIT и их последние интервалы (hop) агрегируются (см. параграф 2.4.2). Таким образом, один объект Content может соответствовать множеству ожидающих Interest в таблице PIT.

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

Этот документ описывает также управляющее сообщение Interest Return. Элемент сети может вернуть сообщение Interest Return на предыдущий интервал, если при обработке Interest возникла ошибка. Возвращенное сообщение может быть дополнительно обработано предыдущим интервалом или возвращено в направлении источника Interest. Когда узел возвращает Interest Return, он указывает, что предыдущему интервалу не следует ожидать от него отклика для Interest, т. е. на возвращающем узле нет записи PIT для Content Object.

Есть много способов описания более крупных объектов в CCNx. Агрегирование L3 Content Object в более крупные объекты выходит за рамки документа. Один из предложенных методов FLIC14 [flic] использует манифест для перечисления фрагментов большого объекта. Сами манифесты являются объектами Content. Другим вариантом является применение соглашений в именах Content Object как в протоколе CCNx Chunking [chunking], где большой объект дробится на мелкие блоки и каждый такой блок получает специальную компоненту имени, указывающую его порядковый номер. Один из экспериментальных протоколов фрагментирования BeginEnd Fragments [befrags] использует метод в стиле многоточечного PPP для работы через интерфейсы L2 с указанием сообщений CCNx [RFC8609] в форме TLV для кодирования в линии.

На основе этих концепций в оставшейся части документа определяется поведение узлов пересылки при обработке сообщений Interest, Content Object и Interest Return.

2. Протокол

В этом разделе определена грамматика сообщений CCNx (Interest, Content Object, Interest Return). Затем описано типичное поведение потребителей, издателей и узлов пересылки. В параграфе, посвященном пересылке, подробно описана обработка относящихся к пересылке вопросов, таких как HopLimit и Content Store, а также конвейеры обработки сообщений Interest и Content Object .

2.1. Грамматика сообщений

ABNF-грамматика [RFC5234] для сообщений CCNx показана на рисунке 1. Грамматика не включает разграничителей кодирования, таких как TLV. Кодирование в линиях представлено в отдельном документе. При наличии раздела Validation поле Validation Algorithm охватывает данные от Body (BodyName или BodyOptName) до конца раздела ValidationAlg. Поля InterestLifetime, CacheTime и Return Code не учитываются для проверки и могут быть изменены.

HashType, PayloadType и Private Enterprise Number (PEN) должны соответствовать значениям IANA в регистрах CCNx Hash Function Types, CCNx Payload Types [ccnx-registry] и Private Enterprise Numbers [eprise-numbers], соответственно.

Ниже представлены определения полей в алфавитном порядке.

AbsTime

Абсолютное время в виде 64-битового значения UTC в миллисекундах с начала эпохи (стандартное время POSIX).

CacheTime

Абсолютное время, при котором издатель будет считать кэшированный Content Object малоценным. Этот параметр рекомендуется для систем кэширования (см. раздел 4).

Cert

Некоторые приложения могут захотеть встраивать сертификат X.509 для проверки и обеспечения доверенной привязки. Cert представляет собой сертификат X.509 с кодированием DER.

ConObjField

Необязательные поля, которые могут присутствовать в объектах Content.

ConObjHash

Значение Content Object Hash, рассчитываемое с помощью SHA256-32 для сообщения от начала тела до конца сообщения. Отметим, что область охвата отличается от ValidationAlg. Значению не следует доверять за пределами домена (см. раздел 5).

ContentObjectHashRestr

Ограничение Content Object Hash. Объект Content должен хэшироваться до того же значения, что и ограничение, с использованием того же HashType. В ContentObjectHashRestr должно использоваться хэширование SHA256-32.

ExpiryTime

Абсолютное время, при котором Content Object следует считать устаревшим (см. раздел 4).

Hash

Хэш-значения в сообщении содержат HashType для указания алгоритма, использованного при генерации хэш-значения, за которым следует это значение. Такой подход позволяет обеспечить быстрое хэшировавние. Некоторые поля могут требовать определенного HashType.

HashType

Алгоритм, используемый для расчета свертки (hash), который должен соответствовать одному из перечисленных в реестре IANA CCNx Hash Function Types [ccnx-registry].

HopLimit

Сообщения Interest могут попадать в петли, если они имеются на уровне пересылки. Для устранения влияния таких петель в каждом Interest содержится поле HopLimit, декрементируемое на каждом интервале. При достижении 0 сообщение не будет пересылаться. См. параграф 2.4.

InterestField

Необязательные поля, которые могут присутствовать в сообщении Interest.

KeyId

Идентификатор ключа, используемого в ValidationAlg. См описание Validation (раздел 8), где рассматривается использование ключей для кодов MAC и подписей.

KeyIdRestr

Ограничения KeyId. Объект Content должен иметь KeyId, значение которого совпадает с ограничением.

KeyLink

Канал (Link, см. параграф 6), который указывает, как получить ключ для проверки ValidationPayload (см. раздел 8).

Lifetime

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

Name

Имя состоит из непустого первого сегмента, за которым могут следовать дополнительные сегменты возможно с нулевым размером. Сегменты имени являются не анализируемыми строками октетов и при использовании кодировки UTF-8 учитывается регистр символов. Объект Interest должен иметь имя (Name), Content Object может иметь Name (см. раздел 9). Сегменты имени называют полными, если они однозначно указывают один объект Content. Имя является точным, если его сегменты полны. Interest с полным именем — это объект, который указывает точное имя и ограничение Content Object Hash соответствующего Content Object.

Payload

Данные сообщения в соответствии с PayloadType.

PayloadType

Формат поля Payload. При отсутствии типа предполагается тип Data (T_PAYLOADTYPE_DATA) [ccnx-registry], означающий не анализируемые байты данных приложения. Тип Key (T_PAYLOADTYPE_KEY [ccnx-registry]) указывает DER-кодированный открытый ключ или сертификат X.509. Тип Link (T_PAYLOADTYPE_LINK [ccnx-registry]) указывает один или множество каналов (Link, см. раздел 6).

PublicKey

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

RelTime

Относительное время в миллисекундах.

ReturnCode

Указывает причины возврата сообщения Interest на предыдущий интервал (см. параграф 10.2).

SigTime

Абсолютное время создания подписи (UTC, в миллисекундах). Время подписи относится только к алгоритму проверки и не обязательно указывает момент создания проверяемого сообщения.

Vendor

Зависящие от производителя не анализируемые (opaque) данные. Данные Vendor включают IANA Private Enterprise Number [eprise-numbers], за которым следует заданная производителем информация. CCNx разрешает зависящие от производителя данные во многих местах.

Message       = Interest / ContentObject / InterestReturn
Interest      = IntHdr BodyName [Validation]
IntHdr        = HopLimit [Lifetime] *Vendor
ContentObject = ConObjHdr BodyOptName [Validation]
ConObjHdr     = [CacheTime / ConObjHash] *Vendor
InterestReturn= ReturnCode Interest
BodyName      = Name Common
BodyOptName   = [Name] Common
Common        = *Field [Payload]
Validation    = ValidationAlg ValidationPayload

Name          = FirstSegment *Segment
FirstSegment  = 1*OCTET / Vendor
Segment       = *OCTET / Vendor

ValidationAlg = (RSA-SHA256 / EC-SECP-256K1 / EC-SECP-384R1 /
                 HMAC-SHA256 / CRC32C) *Vendor
ValidationPayload = 1*OCTET
PublicAlg     = KeyId [SigTime] [KeyLink] [PublicKey] [Cert]
RSA-SHA256    = PublicAlg
EC-SECP-256K1 = PublicAlg
EC-SECP-384R1 = PublicAlg
HMAC-SHA256   = KeyId [SigTime] [KeyLink]
CRC32C        = [SigTime]

AbsTime       = 8OCTET ; 64-bit UTC msec since epoch
CacheTime     = AbsTime
ConObjField   = ExpiryTime / PayloadType
ConObjHash    = Hash
ExpiryTime    = AbsTime
Field         = InterestField / ConObjField / Vendor
Hash          = HashType 1*OCTET
HashType      = 2OCTET ; IANA "CCNx Hash Function Types"
HopLimit      = OCTET
InterestField = KeyIdRestr / ContentObjectHashRestr
KeyId         = Hash
KeyIdRestr    = Hash
KeyLink       = Link
Lifetime      = RelTime
Link          = Name [KeyIdRestr] [ContentObjectHashRestr]
ContentObjectHashRestr  = Hash
Payload       = *OCTET
PayloadType   = OCTET ; IANA "CCNx Payload Types"
PublicKey     = *OCTET ; DER-encoded public key
Cert          = *OCTET ; DER-encoded X.509 Certificate
RelTime       = 1*OCTET ; msec
ReturnCode    = OCTET ; см. параграф 10.2
SigTime       = AbsTime
Vendor        = PEN *OCTET
PEN           = 1*OCTET ; IANA "Private Enterprise Number"

Рисунок 1. ABNF-грамматика сообщений CCNx.

2.2. Поведение потребителя

Для запроса части содержимого данного кортежа {Name, [KeyIdRest], [ContentObjectHashRestr]} потребитель создает сообщение Interest с указанными значениями. Он может добавить раздел validation (обычно только CRC32C). Потребитель может включить поле Payload в сообщение Interest для отправки издателю в дополнение к имени. Имя служит для маршрутизации и может запоминаться на каждом интервале в смысловой таблице PIT для облегчения возврата Content Object. Сохранение большого числа состояний в имени ведет к высокому расходу памяти. Поскольку данные (payload) не рассматриваются при пересылке Interest или сопоставлении Content Object с Interest, потребителю следует включать Interest Payload ID (см. параграф 3.2) как часть имени, чтобы позволить пересылающему узлу сопоставить Interest с Content Object и предотвратить объединение Interest с разными данными. Точно также, если потребитель применяет MAC или подпись, ему следует включать уникальный сегмент как часть имени для предотвращения агрегирования Interest с другими сообщениями Interest или его удовлетворение объектом Content, не связанным с проверкой пригодности.

Потребителю следует указать время InterestLifetime, в течение которого он готов ждать отклика. Значение InterestLifetime определяется приложением, а не временем кругового обхода в сети (см. параграф 2.4.2). По умолчанию применяется InterestLifetime = 2 сек.

Потребителю следует установить подходящее значение Interest HopLimit или использовать принятое по умолчанию ограничение (255). Если потребителю известно число интервалов маршрутизации до издателя, следует указать его.

Потребитель передает Interest своему первому узлу пересылки, который затем пересылает Interest через сеть к издателю (или реплике), где запрос может быть выполнен по имени (см. параграф 2.4).

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

Сеть может передать потребителю сообщение Interest Return, указывающее невозможность выполнить Interest. Значение ReturnCode указывает причину отказа, такую как отсутствие маршрута или перегрузка. В зависимости от ReturnCode потребитель может повторить Interest или вернуть ошибку запрашивающему приложению.

Если содержимое найдено и возвращено первому узлу пересылки, потребитель получит Content Object. Для проверки принятого Content Object потребитель использует приведенный ниже набор тестов.

  • Потребитель должен убедиться в корректности формата Content Object.

  • Потребитель должен проверить, что полученный Content Object соответствует одному или нескольким Interest, как описано в разделе 9.

  • Если Content Object подписан, потребителю следует криптографически проверить подпись в соответствии с разделом 8. При отсутствии нужного ключа потребителю следует получить его (например, от службы распространения ключей или через KeyLink).

  • Если подпись содержит SigTime, потребитель может использовать это значение для проверки действия подписи. Например, если потребитель запрашивает динамически создаваемое содержимое, ему следует ожидать, что значение SigTime будет не раньше времени создания Interest.

  • Если Content Object подписан, потребителю следует подтвердить доверие к ключу подписи для пространства имен. Эта процедура выходит за рамки документа, хотя можно использовать традиционные методы PKI, службы распространения доверенных ключей или методы, подобные [trust].

  • Потребитель может кэшировать Content Object для последующего использования вплоть до ExpiryTime, если это значение присутствует.

  • Потребитель может воспринять просроченный Content Object из линии. Срок действия пакета Content Object может завершиться в процессе передачи, если узлы пересылки не отбрасывают просроченные пакеты «на лету». Единственным требованием для просроченных объектов является недопустимость их размещения в Content Store или кэше, а издателям недопустимо отправлять просроченные Content Object.

2.3. Поведение издателя

Этот документ не задает методов заполнения именами таблиц FIB на узлах пересылки (см. параграф 2.4). Издатель настраивает один или множество префиксов имен, с которыми он может создавать содержимое, или выбирает префиксы имен и информирует уровень маршрутизации для анонсирования этих префиксов.

При получении издателем сообщения Interest ему следует выполнить указанные ниже действия.

  • Убедиться, что Interest является частью пространства имен издателя.

  • Если в Interest есть раздел Validation, нужно проверить его в соответствии с разделом 8. Обычно Interest включают лишь CRC32C, если приложение издателя явно не указывает восприятие других вариантов. Издатель может отбрасывать Interest с разделом Validation, если приложение издателя не ожидает таких подписей, поскольку это может быть формой атаки на отказ в обслуживании. Если подпись требует ключа, которого нет у издателя, ему не рекомендуется получать ключ из сети, когда это не является частью ожидаемого поведения приложения.

  • Нахождение или создание Content Object и возврат его на предыдущий интервал Interest. Если запрошенное содержимое не может быть возвращено, издателю следует ответить сообщением Interest Return или Content Object с данными, говорящими о недоступности содержимого. В такой объект Content следует включать малое значение ExpiryTime (в будущем) или 0 (чтобы его не кэшировали).

2.4. Поведение пересылающего узла

Пересылающий узел маршрутизирует сообщения Interest на основе таблицы пересылки (FIB), возвращает Content Object, соответствующие Interest, на предыдущий интервал Interest и обрабатывает управляющие сообщения Interest Return. Он может также сохранять кэш сообщений Content Object в смысловой таблице Content Store. Этот документ не задает внутреннего поведения узла пересылки, определяя лишь внешние характеристики.

В этом документе применяется два конвейера обработки — один для Interest, другой для Content Object. Обработка Interest состоит в проверке наличия дубликатов Interest в PIT (см. параграф 2.4.2), проверке наличия кэшированного Content Object в Content Store (см. параграф 2.4.3) и пересылке Interest на основе FIB. Обработка Content Store заключается в сопоставлении Interest с таблицей PIT и пересылке на предыдущий интервал.

2.4.1. Interest HopLimit

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

Петли могут также разрываться при агрегировании Interest с предыдущей записью PIT внутри петли. В этом случае Content Object будет отправлен назад по петле и может вернуться на узел, который уже переслал содержимое, где он скорей всего не будет иметь записи в PIT и будет отброшен. Может оказаться так, что новое или другое попавшее в петлю сообщение Interest вернется на тот же узел и в этом случае узел будет возвращать кэшированный отклик для создания новой записи PIT, как описано ниже.

HopLimit является последним средством устранения петель Interest, когда Content Object проходит в петле Interest, где промежуточные узлы по каким-то причинам больше не имеют записи в PIT и кэшированного Content Object.

Каждое сообщение Interest должно включать HopLimit. Сообщение Interest от локального приложения может иметь HopLimit = 0, что ограничивает Interest локальными источниками.

При получении Interest от другого узла пересылки значение HopLimit должно быть положительным — в противном случае пересылающий узел отбрасывает Interest. Пересылающий узел должен декрементировать HopLimit в Interest перед пересылкой по меньшей мере на 1.

Если после декрементирования HopLimit приобретает значение 0, сообщение Interest недопустимо пересылать другому узлу пересылки, но его можно передать локальному приложению издателя или обслужить из локального Content Store.

Рекомендуемый конвейер обработки HopLimit представлен ниже.

  • Если сообщение Interest получено от удаленной системы:

    • при HopLimit = 0 сообщение Interest отбрасывается и можно передать Interest Return (HopLimit Exceeded);

    • в остальных случаях HopLimit уменьшается на 1.

  • Выполняется обработка по правилам Content Store и Aggregation.

  • Если сообщение Interest будет пересылаться:

    • при (возможно декрементированном) HopLimit = 0, пересылка ограничивается локальной системой;

    • в остальных случаях сообщение пересылается локальной или удаленной системе.

2.4.2. Агрегирование Interest

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

CCNx использует правило агрегирования Interest, которое считает, что время InterestLifetime сродни времени подписки, а не кругового обхода в сети. В некоторых прежних правилах агрегирования срок действия считался временем кругового обхода и это создавало проблемы завершения срока действия Interest до прихода отклика, если значение RTT было недооценено или возникали конфликты со схемой автоматического повтора запросов (ARQ15), которая хотела повторить Interest, но для предыдущего Interest значение RTT было переоценено.

Узел пересылки может реализовать схему агрегирования Interest. Если это не делается, узел будет пересылать все сообщения Interest. Это не означает возврата множества (возможно идентичных) Content Object. Пересылающий узел должен по-прежнему выполнять все ожидающие запросы Interest, поэтому один Content Object может удовлетворять множеству похожих Interest, даже если узел пересылки не подавляет дубликаты Interest.

Рекомендуется приведенная ниже схема агрегирования Interest.

  • Два сообщения Interest считаются «похожими», если у них совпадают Name, KeyIdRestr и ContentObjectHashRestr, а отсутствующие в одном сообщении поля отсутствуют и в другом.

  • Разрешать совпадение двух смысловых значения InterestExpiry (локальные для пересылающего узла) со временем приема + InterestLifetime (или зависимое от платформы значение по умолчанию, если поле не задано).

  • Запись Interest (в таблице PIT) считается недействительной, если ее время InterestExpiry в прошлом.

  • Полученное первым сообщение Interest должно пересылаться.

  • Второе и последующие сообщения Interest, похожие на действительное ожидающее сообщение Interest, от того же предыдущего интервала должны пересылаться (это считается повтором передачи запроса).

  • Второе и последующие сообщения Interest, похожие на действительное ожидающее сообщение Interest, от другого предыдущего интервала можно агрегировать (не пересылать). Если это сообщение Interest имеет большее значение HopLimit, нежели ожидающее Interest, оно должно пересылаться.

  • Агрегирование Interest должно продлевать время InterestExpiry для записи Interest. Реализация может сохранять одно значение InterestExpiry для всех предыдущих интервалов или сохранять InterestExpiry независимо для каждого интервала. В первом случае пересылающий узел может передать Content Object по пути, где объект уже не ждут и в этом случае предыдущий интервал (следующий для Content Object) будет отбрасывать его.

2.4.3. Поведение хранилища содержимого

Content Store представляет собой специальный кэш, являющийся частью узла пересылки CCNx. Это хранилище не является обязательным и служит для исправления поврежденных пакетов и обработки множественных (flash) запросов популярного содержимого. Хранилище может заполняться заранее или содержать кэшированные данные. Поскольку Content Store можно использовать для усиления атак с помощью «отправления кэша», для Content Store применяются специальные правила, указанные ниже.

  1. Пересылающий узел может реализовать Content Store. В этом случае содержимое Content Store сопоставляется с Content Object для Interest по обычным правилам (см. раздел 9).

  2. Если Interest имеет ограничение KeyId, хранилище Content Store недопустимо использовать для ответа при отсутствии уверенности в корректности подписи совпадающего Content Object. Это можно проверить с помощью внешнего источника (например, в управляемой сети или системе с заранее заполненным кэшем) или путем получения открытого ключа для криптографической проверки подписи. От Content Store не требуется проверять подписи и отказ от предоставления непроверенного объекта просто считается его отсутствием.

  3. Если Content Store выбирает проверку подписей, это можно сделать, как описано далее. Если открытый ключ указан в самом Content Object (в поле PublicKey field) или в сообщении Interest, хранилище Content Store должно проверить совпадение хэш-значения открытого ключа с KeyId, а затем проверить подпись (см. параграф 8.4). Content Store может проверять цифровую подпись Content Object перед его кэшированием, но это не требуется. Хранилищу Content Store не следует получать ключи через сеть. Если подпись еще не проверена или ее невозможно проверить, следует считать Interest не кэшированным.

  4. Если Interest имеет ограничение Content Object Hash, хранилищу Content Store недопустимо отвечать на этот запрос, пока нет уверенности в наличии у Content Object корректного хэш-значения. Если проверка значения невозможна, Interest считается не кэшированным.

  5. Хранилище должно выполнять директивы управления кэшем (см. раздел 4).

2.4.4. Конвейер Interest

  1. Выполняется проверка HopLimit (см. параграф 2.4.1).

  2. Если Interest включает проверку пригодности, такую как MIC или подпись со встроенным открытым ключом или сертификатом, пересылающий узел может проверить Interest, как указано в разделе 8. Пересылающему узлу не следует получать ключ через KeyLink. Если пересылающий узел отбрасывает Interest в результате проверки, он может передать Interest Return (параграф 10.3.9).

  3. Определяется возможность агрегирования Interest, как указано в параграфе 2.4.2. Если агрегирование возможно, оно выполняется и Interest не пересылается.

  4. При пересылке Interest проверяется его наличие в Content Store, как описано в параграфе 2.4.3. Если соответствующий Content Object найден, он возвращается на предыдущий интервал Interest и объект помещается в Content Store, как описано в параграфе 2.4.5.

  5. Выполняется просмотр Interest в таблице FIB с поиском максимально длинного префикса (LPM16) по сегментам имени (а не по байтам или битам). Предыдущий интервал Interest следует исключать. Если найдено соответствие, сообщение Interest пересылается. Если соответствия не найдено или узел решил не пересылать сообщение по локальным условиям (например, перегрузка), ему следует передать сообщение Interest Return, как указано в разделе 10.

2.4.5. Конвейер объектов Content

  1. Пересылающему узлу, получившему Content Object, рекомендуется проверить, что Content Object принят от ожидаемого предыдущего узла. На этот узел указывает FIB или запись в PIT, которая имеет совпадающее сообщение Interest, отправленное по этому пути.

  2. Объект Content должен соответствовать всем ожидающим запросам Interests, которые удовлетворяют правилам сопоставления (см. раздел 9). Каждый удовлетворяющий запрос Interest должен удаляться из числа ожидающих Interest.

  3. Пересылающему узлу не следует передавать более одной копии полученного Content Object на один предыдущий интервал Interest. Например, может случиться так, что два Interest запрашивают один Content Object по-разному (например, по имени или KeyId и имени) и оба объекта придут от одного предыдущего интервала. Нормально передавать несколько раз один Content Object через один интерфейс (например, Ethernet), если он передается на разные предыдущие интервалы.

  4. Content Object следует помещать в Content Store лишь в том случае, когда он удовлетворяет Interest (см. п. 1 выше). Это снизит вероятность отравления кэша.

3. Имена

Имя CCNx состоит из нескольких сегментов, каждый из которых содержит метку, указывающую цель сегмента и его значение. Например, некоторые сегменты являются именами общего назначения, а другие служат для определенных целей, таких как передача информации о версии или упорядочение множества блоков большого объекта в мелкие подписанные Content Object.

В CCNx имеется три разных типа имен — префиксы, точные и полные имена. Префикс является просто именем, которое однозначно указывает не один Content Object, а скорее пространство имен или префикс существующего имени Content Object. Точное имя однозначно указывает Content Object. Полное имя включает точное имя и сопровождающее его явное или неявное значение ConObjHash. Явные ConObjHash используются в Interest, неявные — в Content Object.

Отметим, что узлам пересылки не нужно знать семантику имен. Они должны лишь быть способны сопоставлять префиксы для пересылки Interest и точное или полное имя — для пересылки Content Object. Узлы пересылки не чувствительны к типам сегментов.

Метки сегментов имен, заданных в этом документе, представлены в таблице 1. Name Segment является сегментом общего назначения, Interest Payload ID указывает данные Interest, а Application Components представляет набор типов сегментов имен, зарезервированных для приложений.

Таблица 1. Типы сегментов имен CCNx.

Тип

Описание

Name Segment

Базовый сегмент имени, включающий произвольные октеты.

Interest Payload ID

Строка октетов, указывающая данные, переносимые в Interest. Например, Payload ID может быть хэш-значением Interest Payload. Это позволяет различать Interest через сегмент имени без включения самих байтов данных.

Application Components

Специфичные для приложения данные в сегменте имени. Приложение может использовать свою семантику компонент. Хорошим тоном является указание приложения в сегменте имени перед сегментами компонент приложения.

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

3.1. Примеры имен

В этом параграфе используется представление CCNx URI [ccnx-uri] для имен CCNx. Отметим, что эта грамматика применяется на уровне сообщения и у Interest должно быть поле Name хотя бы с одним сегментом имени, который должен иметь не менее 1 октета в значении. У Content Object должно быть похожее имя или совсем не быть имени. FIB может иметь имена размером 0 (принятый по умолчанию маршрут), первый сегмент без значения или обычное имя.

Таблица 2. Примеры имен CCNx.

Имя

Описание

ccnx:/

Пустое (0-length) имя, соответствующее принятому по умолчанию маршруту.

ccnx:/NAME=

Имя с 1 сегментом нулевого размера. Отличается от ccnx:/.

ccnx:/NAME=foo/APP:0=bar

2-сегментное имя, где первый сегмент имеет тип NAME, а второй — APP:0.

3.2. Идентификатор данных Interest

Interest может включать поле Payload, в котором передается состояние Interest, не используемое для сопоставления с Content Object. Если Interest содержит данные, в имя Interest следует включать Interest Payload ID (IPID). Значение IPID позволяет записи PIT корректно мультиплексировать Content Object в ответ на конкретные Interest с конкретным идентификатором данных. IPID можно выводить из хэш-значения данных, а также применять уникальный идентификатор GUID17 или одноразовое значение (nonce). Необязательное поле Metadata определяет поле IPID так, чтобы другие системы могли проверить его (например, при выводе из хэш-значения). Проверка IPID не требуется.

4. Управление кэшем

CCNx поддерживает два поля для воздействия на управление кэшем, управляющие обработкой Content Object в кэше или Content Store. Они не применяются в быстром пути и служат лишь для определения возможности внедрения Content Object в быстрый путь при отклике на Interest.

Поле ExpiryTime используется в «конверте» подписи Validation Algorithm. Оно указывает время UTC в миллисекундах, после которого Content Object считается устаревшим и должен больше не применяться в откликах на Interest из кэша. Устаревшее содержимое может исключаться из кэша.

Поле RCT18 размещается за пределами конверта подписи и указывает время UTC в миллисекундах, по достижении которого издатель будет считать Content Object малоценным для кэша. Системе кэширования следует отбрасывать объекты после RCT, хотя их можно хранить и применять в откликах. Кэш может отбросить Content Object до RCT — нет никаких обязательств по хранению объектов.

Эта формулировка позволяет издателю создавать объекты Content с большим ExpiryTime, но коротким RCT, снова и снова переиздавая один и тот же подписанный Content Object с расширением RCT. Это позволяет издателю периодически видеть, что содержимое продолжает использоваться.

5. Хэш Content Object

CCNx позволяет сообщениям Interest ограничивать отклик определенным хэшем, который учитывает тело сообщения Content Object и разделы проверки, если они имеются. Таким образом, для подписанного Content Object хэш будет учитывать значение подписи. Хэш не включает фиксированные и поэтапно добавляемые заголовки Content Object. Поскольку это является частью правил сопоставления (см. раздел 9), хэш применяется на каждом интервале.

Имеется два варианта сопоставления с ограничением Content Object Hash в Interest. Во-первых, узел пересылки может рассчитывать для себя хэш-значение и сравнивать его с ограничением, однако это ресурсоемкая операция. Вторым вариантом является расчет хэш-значения на граничном устройстве и его размещение в заголовке (ConObjHash), передаваемом через сеть. Этот вариант не обеспечивает защиты сопоставления, поэтому его следует применять лишь в доверенных средах. Заголовок следует удалять на границе доверенной области.

6. Канал

Link представляет собой кортеж {Name, [KeyIdRestr], [ContentObjectHashRestr]}, информация которого состоит из полей Interest, определяющих цель Link. Content Object с PayloadType = Link является объектом, данными которого является один или несколько каналов (Link). Этот кортеж может применяться в качестве KeyLink для указания конкретного объекта с «обернутым» сертификатом ключом. Рекомендуется включать хотя бы одно ограничение KeyId или Content Object Hash. Если таких ограничений нет, от издателя может быть возвращен любой Content Object с совпадающим именем.

7. Хэш-значения

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

В этом документе предложены несколько функций хэширования (например, SHA-256), но конкретная реализация может применять функцию, которая кажется лучшей. Нормативную спецификацию сообщений CCNx [RFC8609] следует считать определением подходящих функций и их использования.

8. Проверка пригодности

8.1. Алгоритм проверки

Validator включает раздел ValidationAlgorithm, задающий способ проверки сообщения, и ValidationPayload с выводом проверки (например, цифровая подпись или MAC). Раздел ValidationAlgorithm определяет тип используемого алгоритма и включает требуемую дополнительную информацию. Проверка выполняется от начала сообщения CCNx до конца раздела ValidationAlgorithm (т. е. до данных проверки, но без их включения). Это называется областью проверки. ValidationPayload содержит байты значения контроля целостности, такие как MAC или подпись.

Грамматика сообщения CCNx (параграф 2.1) показывает разрешенные алгоритмы и их структуру. Для случая алгоритма Vendor производитель может использовать любую желаемую структуру. Validator может применяться лишь к Interest и Content Object, но не к Interest Return. Interest внутри Interest Return будет иметь исходное поле проверки, если оно есть.

Грамматика разрешает множество расширений Vendor для алгоритма проверки. Производитель должен описать область проверки для каждого расширения. Например, производитель может использовать обычную подпись в алгоритме проверки, затем добавить фирменный код MIC для обнаружения ошибок в сети без применения дорогостоящей проверки подписи. Данная спецификация не разрешает использовать несколько блоков Validation Algorithm за пределами фирменных методов.

8.2. Коды целостности сообщений

Если алгоритмом проверки служит CRC32C, данные проверки являются выводом CRC для проверяемой области. Этот алгоритм разрешает необязательную временную метку момента подписи (SigTime) при проверке сообщения (не совсем корректно называется «временем подписи», но здесь для этих целей применяется одно поле в MIC, MAC и подписях).

Коды MIC обычно применяются с Interest для предотвращения непреднамеренного повреждения в сети. Они обычно не используются с Content Object, поскольку объекты как правило подписаны или связаны с хэш-цепочкой, поэтому значение CRC32C избыточно.

8.3. Коды аутентификации сообщений

Если для проверки применяется алгоритм HMAC-SHA256, проверочными данными служит вывод HMAC для области проверки. Алгоритм проверки требует KeyId и разрешает SigTime и KeyLink.

Поле KeyId указывает общий секрет, используемый двумя сторонами для аутентификации сообщений. Эти секреты следует выводить из протокола обмена ключами, такого как [ccnx-ke]. KeyId для общего секрета следует быть неанализируемым идентификатором, который не выводится из реального ключа (хорошим выбором, например, будет целочисленный счетчик).

Временем подписи является временная метка момента, когда код аутентификации был рассчитан и добавлен в сообщение.

Поле KeyLink в MAC определяет способ согласования ключей и ему следует указывать в направлении конечной точки обмена ключами. Применение алгоритма согласования ключей выходит за рамки спецификации и такие алгоритмы не требуются для использования этого поля.

8.4. Подпись

Для проверки подписи применяются криптографические алгоритмы с открытым ключом, такие как RSA и ECDSA19. Данная спецификация и документ по кодированию [RFC8609] поддерживают лишь 3 конкретных алгоритма — RSA-SHA256, EC-SECP-256K1 и EC-SECP-384R1. Дополнительные алгоритмы могут применяться на основе других документов или с использованием экспериментальных и фирменных типов.

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

Встроенные сертификаты не распространены, поскольку они могут быть очень большими, а периоды их действия могут отличаться от сроков действия проверяемых данных. Предпочтительным методом проверки является KeyLink.

Поле KeyId в ValidationAlgorithm указывает открытый ключ, применяемый для проверки подписи. Он похож на Subject Key Identifier в X.509 (параграф 4.2.1.2 [RFC5280]). KeyId определен как криптографическое хэш-значение открытого ключа в форме DER. Все реализации должны поддерживать SHA-256 для хэширования KeyId.

Использование других алгоритмов для KeyId разрешено и не будет вызывать проблем на узлах пересылки, поскольку эти узлы сопоставляют лишь алгоритм и его результат, не выполняя самих вычислений (см. раздел 9). Могут возникать проблемы с Content Store, поскольку хранилищу нужно проверять соответствие KeyId и PublicKey (см. параграф 2.4.3), хотя в этом случае может происходить лишь потеря кэша и сообщение Interest будет пересылаться издателю. Пока издатель и потребитель поддерживают хэш, данные будут проверяемы.

В соответствии с разделом 9, пересылающий узел сопоставляет лишь KeyId с ограничениями для него. Ему не нужно смотреть такие поля, как открытый ключ, сертификат или KeyLink.

Если в сообщении имеется несколько KeyId, открытых ключей, сертификатов или KeyLink, конечная точка (потребитель, кэш или Content Store) должна обеспечить согласованность этих полей. Поле KeyId должно быть соответствующим хэш-значением встроенного открытого ключа или открытого ключа сертификата. Хэш-функцией является HashType из KeyId. Если есть встроенный открытый ключ и сертификат, открытые ключи должны совпадать.

Сообщению не следует иметь PublicKey и KeyLink для открытого ключа, поскольку это избыточно. Оно может иметь PublicKey и KeyLink для сертификата.

KeyLink в первом Content Object может указывать на второй Content Object с DER-представлением открытого ключа в поле PublicKey и необязательным DER-представлением сертификата X.509 в поле данных (payload). KeyId второго Content Object должен совпадать с KeyId первого объекта. Поле PublicKey второго объекта должно быть открытым ключом, соответствующим KeyId. Этот ключ должен проверять пригодность подписей первого и второго объекта. Сертификат X.509 в форме DER может быть включен в данные второго объекта, а его встроенный открытый ключ должен соответствовать PublicKey. Он должен быть выдан доверенным центром, предпочтительно задающим действительное пространство имен ключа в отличительном имени. Второму объекту недопустимо иметь KeyLink, поскольку рекурсивный поиск ключа не разрешен.

9. Сопоставление Interest и Content Object

Content Object соответствует запросу Interest тогда и только тогда, когда (a) имя Content Object при его наличии совпадает с именем Interest, (b) ValidationAlgorithm KeyId в Content Object совпадает с ограничением Interest KeyId при наличии и (c) рассчитанное значение Content Object Hash совпадает с ограничением Interest Content Object при наличии.

KeyId и KeyIdRestr используют формат Hash (см. параграф 2.1), имеющий встроенное поле HashType, за которым следует хэш-значение. При сравнении KeyId и KeyIdRestr сравниваются HashType и значение.

Правила сопоставления задаются утверждением, значение true в котором означает, что Content Object соответствует Interest, Ni = Name в Interest (не может быть пустым), Ki = KeyIdRestr в Interest (может быть пустым), Hi = ContentObjectHashRestr в Interest (может быть пустым). No, Ko и Ho являются свойствами Content Object, где No и Ko могут быть пустыми, а Ho существует всегда (это внутреннее свойство Content Object). Для двоичных выражений используются символы & (AND) и | (OR), E означает оператор существования (не пусто), а ! — оператор отсутствия.

В особом случае, когда ограничение Content Object Hash в Interest задает не поддерживаемый алгоритм хэширования, Content Object не может соответствовать Interest, поэтому системе следует отбросить Interest и можно передать Interest Return на предыдущий интервал. В этом случае приведенное ниже утверждение никогда не выполняется, поскольку Interest не пересылается. Если система использует необязательное поведение, заключающееся в том, что другая система рассчитывает хэш для нее, эта система может предполагать поддержку всех хэш-функций и оставлять другой системе решение вопроса о восприятии или отклонении Interest.

   (!No | (Ni=No)) & (!Ki | (Ki=Ko)) & (!Hi | (Hi=Ho)) & (E No | E Hi)

Как можно видеть, имеется два типа атрибутов, которые могут совпадать. Первое совпадение зависит от наличия атрибута в Content Object, а два следующих — от наличия атрибута в Interest. Последним совпадением является ограничение Nameless Object (безымянный объект), которое говорит, что Content Object, не имеющий Name, должен соответствовать Interest хотя бы по ограничению Hash.

Если Content Object не содержит Content Object Hash в явном виде, хэш-значение должно рассчитываться в сети для сопоставления. В автономной системе достаточно рассчитать Content Object Hash на граничном маршрутизаторе и передавать его доверенным способом внутри автономной системы. Если ValidationAlgorithm в Content Object не имеет KeyId, этот объект Content не может соответствовать Interest с ограничением KeyId.

10. Возврат Interest

В этом разделе описывается процесс, посредством которого элемент сети может возвращать сообщение Interest на предыдущий интервал, если при обработке Interest возникла ошибка. Возвращенное сообщение Interest может обрабатываться на предыдущем интервале или возвращаться в направлении его источника. Когда узел возвращает Interest, это указывает, что предыдущий интервал не ожидает отклика для данного Interest, т. е. на возвратившем сообщение узле нет записи PIT.

Возвращаемое сообщение совместимо с имеющимся форматом пакетов TLV (фиксированный заголовок, необязательные поэтапные заголовки и тело сообщения CCNx). Возвращаемый пакет Interest имеет лишь 2 отличия:

  • в PacketType устанавливается Interest Return для индикации сообщения Feedback;

  • в ReturnCode указывается подходящее значение для обозначения причины возврата.

Детали кодирования Interest Return указаны в [RFC8609].

Пересылающий узел не обязан передавать какие-либо сообщения Interest Return.

Пересылающий узел не обязан обрабатывать полученные сообщения Interest Return. Если он не может обработать Interest Return, следует просто отбросить сообщение.

Сообщения Interest Return не применяются к Content Object и другим типам сообщений.

Сообщение Interest Return передается между партнерами одного интервала (1-hop) и не распространяется через множество интервалов с применением FIB. Промежуточный узел, получивший Interest Return, может выполнить корректирующие действия или передать свое сообщение Interest Return на предыдущий интервал, указанный в пути возврата записи PIT.

10.1. Формат сообщения

Сообщение Interest Return выглядит как исходное сообщение Interest, отличаясь лишь двумя отмеченными выше изменениями. Поле PacketType устанавливается для индикации типа сообщения Interest Return, а резервный байт в заголовке Interest служит кодом возврата. Значения PacketType и ReturnCode приведены в [RFC8609].

10.2. Типы ReturnCode

В этом параграфе описаны коды возврата Interest Return (ReturnCode), определенные в данном RFC. Численные значения кодов, используемые в пакетах, определены в [RFC8609].

Таблица 3. Коды причин Interest Return.

Имя

Описание

No Route (параграф 10.3.1)

Возвращающий узел пересылки не имеет пути к имени в Interest.

HopLimit Exceeded (параграф 10.3.2)

Значение HopLimit уменьшено до 0, но требуется пересылка пакета.

Interest MTU too large (параграф 10.3.3)

MTU для Interest не соответствует требуемому минимуму и нужна фрагментация.

No Resources (параграф 10.3.4)

Узел не имеет ресурсов для обработки Interest.

Path error (параграф 10.3.5)

Ошибка передачи при пересылке Interest по маршруту (временная ошибка).

Prohibited (параграф 10.3.6)

Административные настройки запрещают обработку Interest.

Congestion (параграф 10.3.7)

Сообщение Interest отброшено по причине перегрузки (временная ошибка).

Unsupported Content Object Hash Algorithm (параграф 10.3.8)

Сообщение Interest отброшено по причине запроса в нем ограничения Content Object Hash, использующего алгоритм хэширования, который не доступен.

Malformed Interest (параграф 10.3.9)

Сообщение Interest отброшено по причине невозможности корректного разбора.

10.3. Протокол возврата Interest

В этом параграфе описано поведение узла пересылки для разных кодов причины возврата Interest. От узла пересылки не требуется генерация каких-либо кодов, но если узел делает это, он должен следовать данной спецификации.

Если узел пересылки получает Interest Return, ему следует выполнить стандартные корректировочные действия. Узлу разрешено игнорировать сообщения Interest Return, при этом для записи PIT действует обычная процедура тайм-аута.

  • Проверка прибытия Interest Return со следующего интервала, на который было реально передано Interest.

  • Если записи PIT для соответствующего Interest нет, узлу пересылки следует игнорировать Interest Return.

  • Если запись PIT для соответствующего Interest имеется, узел может выбрать один из двух вариантов:

    • попробовать другой путь пересылки при его наличии и отбросить Interest Return;

    • сбросить состояние PIT и передать Interest Return по пути возврата.

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

При использовании узлом пересылки дополнительных маршрутов он может получить второе сообщение Interest Return возможно другого типа, нежели первое сообщение Interest Return. Например, узел A передал Interest для узла B, который вернул сообщение No Route. Затем узел A пытается передать сообщение через узел C, который возвращает Prohibited Interest Return. Узлу A следует выбрать подходящий код для отправки своему предыдущему интервалу.

При использовании узлом пересылки дополнительных маршрутов ему следует декрементировать Interest Lifetime с учетом времени, уже затраченного на обработку Interest.

10.3.1. No Route

Если узел пересылки получает Interest, для которого нет маршрута или существует лишь маршрут назад к передавшей Interest системе, узлу пересылки следует генерировать сообщение Interest Return No Route.

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

10.3.2. HopLimit Exceeded

Узел пересылки может передавать сообщения HopLimit Exceeded при получении сообщений Interest с HopLimit = 0, которые нужно пересылать.

10.3.3. Interest MTU Too Large

Если узел пересылки получает сообщение Interest, в котором MTU превышает предписанный минимум, узел может передать сообщение Interest MTU Too Large или просто отбросить Interest.

Если узел пересылки получает отклик Interest MTU Too Large, ему не следует пробовать другие пути. Следует передать это сообщение Interest Return на предыдущий интервал.

10.3.4. No Resources

Если узел пересылки получает сообщение Interest и не может его обработать по причине нехватки ресурсов, он может передать сообщение No Resources. Нехватка ресурсов может быть связана с размером PIT или иными ограничениями.

10.3.5. Path Error

Если узел пересылки обнаруживает ошибку при пересылке Interest (например, через надежный канал), он может передать сообщение Path-Error, указывающее неспособность устранить ошибку при пересылке.

10.3.6. Prohibited

Узел пересылки может иметь административные правила, такие как списки контроля доступа (ACL20), которые препятствуют приему или пересылке Interest. Если узел отбрасывает Interest на основании правил, он может передать сообщение Prohibited на предыдущий интервал. Например, при наличии ACL, разрешающего получать /example/private только на интерфейсе e0, но полученном на e1, узел должен иметь способ вернуть Interest с указанием причины.

10.3.7. Congestion

Узел пересылки, отбрасывающий Interest по причине перегрузки, может передать Congestion на предыдущий интервал.

10.3.8. Unsupported Content Object Hash Algorithm

Если ограничение Content Object Hash задает алгоритм хэширования, который узел пересылки не может проверить, Interest не следует воспринимать и узел может передать Interest Return на предыдущий интервал.

10.3.9. Malformed Interest

Если узел пересылки обнаруживает структурную или синтаксическую ошибку в Interest, ему следует отбросить Interest и можно передать Interest Return на предыдущий интервал. Это не означает, что любой маршрутизатор должен проверять структуру Interest целиком.

11. Взаимодействие с IANA

Этот документ не задает действий IANA.

12. Вопросы безопасности

CCNx является протоколом сетевого уровня (L3), котрый может работать в режиме наложения с использованием такого транспорта, как UDP или туннели. Протокол имеет встроенную поддержку аутентификации сообщений с помощью подписи (например, RSA или эллиптическая кривая) или кода аутентификации (например, HMAC). Взамен аутентификатора может применяться проверка целостности сообщения (например, SHA или CRC). CCNx не определяет «конверт» шифрования, оставляя это вышележащим протоколам (например, [esic]).

Формат сообщений CCNx позволяет присоединить MIC (например, CRC32C), MAC (например, HMAC) и подписи (например, RSA или ECDSA) к пакетам любого типа. Это не означает, что хорошей идеей будет использовать произвольный ValidationAlgorithm или включать ресурсоемкие алгоритмы в пакеты Interest, поскольку это может приводить к DoS-атакам за счет вычислений. Приложениям следует использовать явный протокол для руководства применением подписей пакетов. В качестве общего руководства приложения могут использовать MIC в сообщениях Interest для обнаружения непреднамеренно поврежденных пакетов. Если нужна защита Interest, следует рассмотреть возможность шифрования и протокол, предотвращающий атаки с повторным использованием, особенно при использовании Interest в качестве исполнительного механизма (actuator). Простое применение кода аутентификации или подписи не обеспечивает защиты Interest. В литературе имеется несколько примеров защиты обмена сообщениями в стиле ICN [mobile] [ace].

Поскольку документ относится к протоколу L3, он не описывает способов доставки ключей и механизмов доверия к ним. Content Object в CCNx может включать открытый ключ или сертификат, а также может использовать поле KeyLink для указания открытого ключа или сертификата для проверки подлинности сообщения. Одной из спецификаций обмена ключами является CCNxKE [ccnx-ke] [mobile], где обмен похож на процедуру TLS 1.3, отличаясь тем, что происходит через сообщения CCNx L3. Вопросы доверия выходят за рамки протокола L3 и решаются приложениями.

Комбинация обмена эфемерными ключами (например, CCNxKE [ccnx-ke]) с инкапсулирующим шифрованием (например, [esic]) обеспечивает эквивалент туннеля TLS. Промежуточные узлы могут пересылать сообщения Interest и Content Object, но не будут видеть их содержимого. Это также полностью скрывает внутренние имена, заменяя их именами, используемыми уровнем шифрования. Этот тип туннельного шифрования полезен для передачи содержимого, которое мало или совсем не подходит для кэширования, поскольку оно может применяться лишь теми, кто знает эфемерный ключ. Краткосрочное кэширование может помочь на каналах с потерями, но длительное кэширование обычно не представляет интереса.

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

Конкретное кодирование сообщений будет влиять на безопасность. В [RFC8609] применяется кодирование TLV. Был выбран компромисс между расширяемостью и однозначностью кодирования типа и размера. Некоторые TLV используют поля T и L переменного размера, чтобы вместить более широкий диапазон значений с сохранением эффективного использования байтов. Здесь TLV кодируются с 2-байтовыми полями T и L, что решает 2 проблемы. Первая проблема связана с псевдонимами. Если можно кодировать одно значение в полях разного размера (например, %x02 и %x0002), кто-то может счесть их одним, а другой — разными. Если есть различие, оно должно определяться в буферах, а не числовом представлении. Если от этого отказаться, придется проверять кодирование TLV в каждом поле каждого пакета на всех узлах пересылки. Если они одинаковы, возникает другая проблема — как задавать фильтры. Например, если имя включает 6 компонент, имеется 7 полей T и 7 полей L, каждое из которых может иметь до 4 представлений одного значения. В результате имеется 14 полей с 4 представлениями для каждого или «1001 комбинация». Это также означает невозможность сравнения, например, имени через функции памяти, поскольку нужно учитывать разные форматы T и L.

Сообщение Interest Return не имеет аутентификатора от предыдущего интервала. Поэтому данные из Interest Return следует применять лишь локально для сопоставления с Interest. Узлу не следует пересылать эти Interest Payload как Interest. Он должен также убедиться, что передал Interest в Interest Return нужному узлу и не позволять кому-либо отменять сообщения Interest.

Кэширующие узлы должны соблюдать осторожность при обработке Content Object. Важно, чтобы хранилище Content Store следовало правилам параграфа 2.4.3 во избежание некоторых типов атак. CCNx 1.0 не имеет механизмов обхода нежелательных результатов из сети (нет «исключений»), поэтому при отравлении кэша непригодным содержимым это может вызвать проблемы при поиске. Существует 3 типа доступа к содержимому из Content Store — неограниченный, а также ограниченные подписью и хэш-значением. Если Interest не имеет ограничений, запрашивающая сторона не заботится о том, что она получит в ответ и подойдет любой кэшированный объект. При ограничении по хэш-значению запрашивающая сторона очень точно определяет желаемый результат и Content Store (и каждый пересылающий узел) может легко проверить соответствие содержимого запросу. При ограничении подписью (часто служит для начального обнаружения манифеста) запрашивающий знает лишь KeyId для подписи содержимого. Этот случай требует пристального внимания в Content Store, чтобы избежать усиления неверных данных. Хранилище Content Store должно отвечать лишь объектами Content с проверенной подписью. Это значит, что Content Object содержит в себе открытый ключ или Interest передает открытый ключ в дополнение к KeyId. Если это не выполняется, хранилищу Content Store следует рассматривать Interest как отсутствие кэша и позволять конечной точке ответить.

Кэш пользовательского уровня может выполнять полную проверку подписи путем извлечения открытого ключа или сертификата по KeyLink. Однако это не та задача, которую можно отдать узлу пересылки. Пользовательский кэш может также полагаться на внешнюю (out-of-band) аттестацию, например, если оператор кэша включает лишь информацию, для которой у него есть корректная подпись.

Грамматика CCNx обеспечивает гибкость алгоритма хэширования с помощью HashType, указывая список приемлемых алгоритмов, которые следует реализовать на каждом узле пересылки. Некоторые типы пригодны лишь для конечных систем и обновление их не влияет на узлы пересылки, которые будут просто сопоставлять буферы, включающие type-length-hash. Некоторые поля (например, ConObjHash) должны проверяться на каждом узле, поэтому узел пересылки (или связанная с ним система) должен знать алгоритм хэширования. Это может вызвать проблемы совместимости при смене типа хэша. [RFC8609] является официальным источником данных о разрешенных типах хэширования.

Для имен CCNx применяется двоичное сопоставление, тогда как для URI сравниваются имена хостов без учета регистра. Некоторые системы могут применять независимое от регистра сопоставление путей URI к ресурсу. В результате введенные человеком имена CCNx будут скорей всего сталкиваться с несоответствием символов разных регистров и символов не-ASCII, если не применять нормализацию URI для имен CCNx. Это означает, что объект, регистрирующий маршрутизируемый префикс CCNx, скажем ccnx:/example.com, должен зарегистрировать варианты типа ccnx:/Example.com. Если это не учтено в нормализации URI и соглашениях протокола маршрутизации, становятся возможными фишинговые атаки.

Более общее рассмотрение вопросов безопасности ICN приведено в [RFC7927] и [RFC7945].

13. Литература

13.1. Нормативные документы

[RFC2119] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC8174] Leiba, B., «Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words», BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

13.2. Дополнительная литература

[ace] Shang, W., Yu, Y., Liang, T., Zhang, B., and L. Zhang, «NDN-ACE: Access Control for Constrained Environments over Named Data Networking», NDN Technical Report NDN-0036, December 2015, <http://new.named-data.net/wp-content/uploads/2015/12/ndn-0036-1-ndn-ace.pdf>.

[befrags] Mosko, M. and C. Tschudin, «ICN «Begin-End» Hop by Hop Fragmentation», Work in Progress, draft-mosko-icnrg-beginendfragment-02, December 2016.

[ccn-lite] Tschudin, C., et al., «CCN-lite», University of Basel, 2011-2019, <http://ccn-lite.net>.

[ccnx-ke] Mosko, M., Uzun, E., and C. Wood, «CCNx Key Exchange Protocol Version 1.0», Work in Progress, draft-wood-icnrg-ccnxkeyexchange-02, March 2017.

[ccnx-registry] IANA, «Content-Centric Networking (CCNx)», <https://www.iana.org/assignments/ccnx>.

[ccnx-uri] Mosko, M. and C. Wood, «The CCNx URI Scheme», Work in Progress, draft-mosko-icnrg-ccnxurischeme-01, April 2016.

[chunking] Mosko, M., «CCNx Content Object Chunking», Work in Progress, draft-mosko-icnrg-ccnxchunking-02, June 2016.

[cicn] FD.io, «Community ICN (CICN)», February 2017, <https://wiki.fd.io/index.php?title=Cicn&oldid=7191>.

[dart] Garcia-Luna-Aceves, J. and M. Mirzazad-Barijough, «A Light-Weight Forwarding Plane for Content-Centric Networks», International Conference on Computing, Networking, and Communications (ICNC), DOI 10.1109/ICCNC.2016.7440637, February 2016, <https://arxiv.org/pdf/1603.06044.pdf>.

[eprise-numbers] IANA, «IANA Private Enterprise Numbers», <https://www.iana.org/assignments/enterprise-numbers>.

[esic] Mosko, M. and C. Wood, «Encrypted Sessions In CCNx (ESIC)», Work in Progress, draft-wood-icnrg-esic-01, September 2017.

[flic] Tschudin, C. and C. Wood, «File-Like ICN Collection (FLIC)», Work in Progress, draft-tschudin-icnrg-flic-03, March 2017.

[mobile] Mosko, M., Uzun, E., and C. Wood, «Mobile Sessions in Content-Centric Networks», IFIP Networking Conference (IFIP Networking) and Workshops, DOI 10.23919/IFIPNetworking.2017.8264861, June 2017, <https://dl.ifip.org/db/conf/networking/networking2017/1570334964.pdf>.

[ndn] UCLA, «Named Data Networking», 2019, <https://www.named-data.net>.

[nnc] Jacobson, V., Smetters, D., Thornton, J., Plass, M., Briggs, N., and R. Braynard, «Networking Named Content», Proceedings of the 5th International Conference on Emerging Networking Experiments and Technologies, DOI 10.1145/1658939.1658941, December 2009, <https://dx.doi.org/10.1145/1658939.1658941>.

[RFC5234] Crocker, D., Ed. and P. Overell, «Augmented BNF for Syntax Specifications: ABNF», STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <https://www.rfc-editor.org/info/rfc5234>.

[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, «Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile», RFC 5280, DOI 10.17487/RFC5280, May 2008, <https://www.rfc-editor.org/info/rfc5280>.

[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>.

[RFC7945] Pentikousis, K., Ed., Ohlman, B., Davies, E., Spirou, S., and G. Boggia, «Information-Centric Networking: Evaluation and Security Considerations», RFC 7945, DOI 10.17487/RFC7945, September 2016, <https://www.rfc-editor.org/info/rfc7945>.

[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>.

[selectors] Mosko, M., «CCNx Selector Based Discovery», Work in Progress, draft-mosko-icnrg-selectors-01, May 2019.

[terminology] Wissingh, B., Wood, C., Afanasyev, A., Zhang, L., Oran, D., and C. Tschudin, «Information-Centric Networking (ICN): CCN and NDN Terminology», Work in Progress, draft-irtf-icnrg-terminology-04, June 2019.

[trust] Tschudin, C., Uzun, E., and C. Wood, «Trust in Information-Centric Networking: From Theory to Practice», 25th International Conference on Computer Communication and Networks (ICCCN), DOI 10.1109/ICCCN.2016.7568589, August 2016, <https://doi.org/10.1109/ICCCN.2016.7568589>.

Адреса авторов

Marc Mosko

PARC, Inc.

Palo Alto, California 94304

United States of America

Phone: +01 650-812-4405

Email: marc.mosko@parc.com

Ignacio Solis

LinkedIn

Mountain View, California 94043

United States of America

Email: nsolis@linkedin.com

Christopher A. Wood

University of California Irvine

Irvine, California 92697

United States of America

Phone: +01 315-806-5939

Email: woodc1@uci.edu

Перевод на русский язык

Николай Малых

nmalykh@protocols.ru

1Content-Centric Networking.

2Information-Centric Networking Research Group — группа по исследованию ориентированных на информацию сетей.

3Internet Research Task Force.

4Information-Centric Networking.

5Type-length-value — тип, размер, значение.

6Internet of Things — Internet вещей.

7Named Data Networking — сеть именованных данных.

8Forwarding information base.

9Message Authentication Code — код аутентификации сообщения.

10Message Integrity Code — код целостности сообщения.

11Hashed Message Authentication Code — хешированный код аутентификации сообщения.

12Cyclic Redundancy Check — циклическая контрольная сумма с избыточностью.

13Pending Interest Table — таблица ожидающих Interest.

14File-Like ICN Collection — файлоподобная коллекция ICN.

15Automatic Repeat reQuest.

16Longest Prefix Match.

17Globally Unique Identifier — уникальный в глобальном масштабе идентификатор.

18Recommended Cache Time — рекомендуемое время кэширования.

19Elliptic Curve Digital Signature Algorithm — алгоритм цифровой подписи на основе эллиптической кривой.

20Access control list.




RFC 8597 Cooperating Layered Architecture for Software-Defined Networking (CLAS)

Independent Submission                                     LM. Contreras
Request for Comments: 8597                                    Telefonica
Category: Informational                                    CJ. Bernardos
ISSN: 2070-1721                                                     UC3M
                                                                D. Lopez
                                                              Telefonica
                                                            M. Boucadair
                                                                  Orange
                                                              P. Iovanna
                                                                Ericsson
                                                                May 2019

Архитектура CLAS для программно-определяемых сетей

Cooperating Layered Architecture for Software-Defined Networking (CLAS)

PDF

Тезисы

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

В этом документе описан подход, названный многоуровневой архитектурой взаимодействия для программно-определяемых сетей (CLAS2), где связанные с транспортом функции управления отделены от функций, связанным с услугами так, что они могут предоставляться, поддерживаться и развиваться независимо и самостоятельно.

Статус документа

Этот документ не является спецификацией Internet Standards Track и публикуется с информационными целями.

Этот документ в серии RFC не связан с каким-либо потоком RFC. Редактор (RFC Editor) принял решение о публикации документа по своему усмотрению и не делает каких-либо заявлений о возможности реализации или развертывания. Документ одобрен для публикации редактором и не претендует на статус Internet Standard (см. раздел 2 в RFC 7841).

Информацию о текущем статусе документа, ошибках и способах обратной связи можно найти по ссылке https://www.rfc-editor.org/info/rfc8597.

Авторские права

Авторские права (Copyright (c) 2019) принадлежат IETF Trust и лицам, указанным в качестве авторов документа. Все права защищены.

Этот документ является субъектом прав и ограничений, перечисленных в BCP 78 и IETF Trust Legal Provisions и относящихся к документам IETF (http://trustee.ietf.org/license-info), на момент публикации данного документа. Прочтите упомянутые документы внимательно, поскольку в них описаны права и ограничения, относящиеся к данному документу.

Оглавление

Исключено в версии HTML

1. Введение

Успехи в сфере программных сетевых решений облегчают внедрение программируемых служб и инфраструктуры операторов связи. Обычно это достигается за счет применения программно-определяемых сетей (SDN) [RFC7149] [RFC7426], включая контроллеры и оркестраторы.

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

SDN предлагает разделять уровни управления и данных в сетевых устройствах путем абстрагирования обоих уровней, позволяющего централизовать логику управления в объекте, обычно называемом контроллером SDN (в сети может применяться один или множество контроллеров). Затем определяется программный интерфейс между элементом пересылки (в узлах сети) и управляющим элементом. Через этот интерфейс управляющий элемент инструктирует узлы уровня пересылки и меняет нужным образом их поведение в части пересылки трафика. Поддержка дополнительных возможностей (например, мониторинга производительности, контроля отказов и т. п.) также может осуществляться через этот программный интерфейс [RFC7149].

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

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

  • Комплексное и многократное использование функций для предоставления услуг.

  • Закрытая, монолитная архитектура управления.

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

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

  • Сложность диагностики и обслуживания сети, а также поиска неполадок (в частности, определение ответственного за отказ уровня).

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

Этот документ описывает подход, названный многоуровневой архитектурой взаимодействия для программно-определяемых сетей (CLAS), где связанные с транспортом функции управления отделены от функций, связанным с услугами так, что они могут предоставляться, поддерживаться и развиваться независимо и самостоятельно.

Несмотря на такое различие, тесное взаимодействие между уровнями услуг и транспорта (или слоями в [Y.2011]) и связанными компонентами требуется для эффективного использования ресурсов.

2. Терминология

Ниже приведены определения используемых в документе терминов.

Transport — транспорт

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

Service – сервис (услуга, служба)

Логическая конструкция, использующая транспортные возможности.

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

Layer — уровень

Набор элементов с возможностями транспорта или услуг в соответствии с предшествующими определениями. В [Y.2011] уровни называются слоями (stratum) и в этом документе применяются оба термина.

Domain — домен

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

SDN Intelligence — интеллект SDN

Процесс принятия решений, реализованный на узле или наборе узлов, называемых контроллерами SDN.

Интеллект может быть распределенным или централизованным. В документе рассматриваются оба варианта.

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

Точная декомпозиция интеллекта SDN, за исключением описанных здесь уровней, выходит за рамки документа.

Кроме того, в документе используются перечисленные ниже сокращения.

CLAS

Cooperating Layered Architecture for SDN — многоуровневая архитектура взаимодействия для программно-определяемых сетей.

FCAPS

Fault, Configuration, Accounting, Performance, and Security — отказы, настройка, учет, производительность и безопасность.

SDN

Software-Defined Networking — программно-определяемая сеть.

SLA

Service Level Agreement — соглашение об уровне обслуживания.

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

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

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

Этот документ в основном посвящен решению перечисленных ниже задач:

  • представление транспортных возможностей сервису;

  • фиксация требований сервиса к транспорту;

  • уведомление сервисного интеллекта о транспортных событиях, например, для корректировки процесса принятия решения при том или ином событии на транспорте;

  • информирование базового транспорта о новых требованиях и т. п.

Примером является гарантия некоторых уровней качества обслуживания (QoS4). Различные предложения на основе QoS могут быть представлены на сервисном и транспортном уровне. Должны быть предусмотрены вертикальные связи между механизмами QoS транспортного и сервисного уровня, чтобы гарантировать качество обслуживания конечному пользователю.

Архитектура CLAS предполагает, что логически централизованные функции разделены на два функциональных уровня. Один из уровней содержит связанные с сервисом функции, а другой — функции, связанные с транспортом. Предполагается взаимодействие этих уровней через стандартные интерфейсы.

На рисунке 1 показана архитектура CLAS, основанная на функциональном разделении архитектуры NGN5, определенной ITU-T в стандарте [Y.2011], где заданы два слоя (уровня) функциональности. Эти слои называются сервисным (Service Stratum) и транспортным (Transport Stratum). Функции каждого из этих уровней дополнительно группируются по уровням управления, администрирования и данных (пользовательский).

CLAS принимает структурную модель, описанную в [Y.2011], но применяет ее для решения задач программируемости с помощью SDN [RFC7149]. В этом отношении CLAS предлагает разделение услуг и транспорта на основе различия их задач.

                                  Приложения
                                      /\
                                      ||
                                      ||
+-------------------------------------||-------------+
| Сервисный слой                      ||             |
|                                     \/             |
|                       ...........................  |
|                       . Интеллект SDN           .  |
|                       .                         .  |
|  +--------------+     .        +--------------+ .  |
|  |    Уровень   |     .        |Уровень админ.| .  |
|  |    ресурсов  |<===>.  +--------------+     | .  |
|  |              |     .  |Уровень управ.|     | .  |
|  +--------------+     .  |              |-----+ .  |
|                       .  |              |       .  |
|                       .  +--------------+       .  |
|                       ...........................  |
|                                     /\             |
|                                     ||             |
+-------------------------------------||-------------+
                                      ||   Стандартный
                                   -- || --    API
                                      ||
+-------------------------------------||-------------+
| Транспортный слой                   ||             |
|                                     \/             |
|                       ...........................  |
|                       . Интеллект SDN           .  |
|                       .                         .  |
|  +--------------+     .        +--------------+ .  |
|  |    Уровень   |     .        |Уровень админ.| .  |
|  |    ресурсов  |<===>.  +--------------+     | .  |
|  |              |     .  |Уровень управ.|     | .  |
|  +--------------+     .  |              |-----+ .  |
|                       .  |              |       .  |
|                       .  +--------------+       .  |
|                       ...........................  |
|                                                    |
|                                                    |
+----------------------------------------------------+

Рисунок 1.Архитектура CLAS.


В архитектуре CLAS функции управления и администрирования выполняются на одном или множестве контроллеров SDN (например, для расширяемости и надежности), обеспечивая интеллект SDN таким способом, что контроллеры SDN представлены в сервисном и транспортном слое. Функции администрирования считаются частью интеллекта SDN, обеспечивающего эффективную работу в экосистеме сервис-провайдера [RFC7149], хотя в некоторых предложениях эти функции не считались частью среды SDN [ONFArch].

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

Контроллеры SDN взаимодействуют для предоставления и доставки услуг. Имеется иерархия, в которой интеллект сервисной SDN делает запросы к интеллекту транспортной SDN для предоставления транспортных возможностей.

Интеллект сервисной SDN выступает клиентом интеллекта транспортной SDN.

Кроме того, интеллект транспортной SDN взаимодействует с интеллектом сервисной SDN для информирования о событиях в транспортной сети, которые могут вызывать действия на уровне серсива.

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

3.1. Функциональные слои

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

Согласованность определяется и характеризуется уровнем сервиса.

3.1.1. Транспортный слой

Транспортный слой включает функции, ориентированные на передачу данных между взаимодействующими конечными точками (например, между пользовательскими устройствами, сервисными шлюзами и т. п.). Узлы пересылки данных управляются и поддерживаются компонентой Transport SDN.

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

3.1.2. Сервисный слой

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

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

3.1.3. Рекурсия уровней

В некоторых вариантах применения может использоваться рекурсивное деление на уровни, где транспортный слой дополнительно делится на сервисный и транспортный слои. Это может возникать в случаях предоставления транспортных услуг, дополненных расширенными возможностями (например, для поддержки SLA [RFC7297]).

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

3.2. Разделение уровней

Архитектура CLAS усиливает разделение уровней. Как отмечено в параграфах 3.1.1 и 3.1.2, в каждом слое выделяются три разных уровня. Взаимодействие между соответствующими уровнями в разных слоях основано на стандартных, открытых интерфейсах.

3.2.1. Уровень управления

Уровень управления логически централизует функции управления каждого слоя и непосредственно управляет соответствующими ресурсами. Роль уровня управления в архитектуре SDN рассмотрена в [RFC7426]. Этот уровень является частью SDN Intelligence и может взаимодействовать с другими уровнями управления в том же или другом слое для реализации управляющих функций.

3.2.2. Уровень администрирования

Уровень администрирования логически централизует административные функции каждого слоя, включая администрирование уровней управления и ресурсов. Уровень администрирования в среде SDN описан в [RFC7426]. Этот уровень также является частью SDN Intelligence и может взаимодействовать с соответствующими уровнями администрирования в контроллерах SDN того же или другого слоя.

3.2.3. Уровень ресурсов

Уровень ресурсов включает ресурсы для выполнения транспортных или сервисных функций. В некоторых случаях сервисные ресурсы могут быть подключены к транспортным (например, служить точками завершения транспортных функций), в других они могут быть полностью отделены от ресурсов транспорта (например, база данных с реестром для конечных пользователей). Уровни пересылки и операций, предложенные в [RFC7426], являются в данной архитектуре частью уровня ресурсов.

4. Требуемые функции

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

  • Абстрагирование — отображение физических ресурсов на соответствующие абстрактные ресурсы.

  • Трансляция параметров сервиса (например, в форме SLA) в параметры (возможности) транспорта в соответствии с различными правилами.

  • Мониторинг — механизмы (например, уведомления о событиях) для динамического обновления состояний (абстрагированных) ресурсов с учетом, например, уровня трафика.

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

  • Оркестровка — возможность комбинировать разные ресурсы (например, IT и сетевые) оптимальным способом.

  • Учет использования ресурсов.

  • Безопасность — защищенное взаимодействие между компонентами с предотвращением атак (например, DoS).

5. Взаимодействие между контроллерами SDN

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

С точки зрения сервиса требуется Service SDN Intelligence для упрощения доступа к транспортным ресурсам через четко определенные интерфейсы API, чтобы определить возможности, предоставляемые транспортным слоем. Могут применяться разные способы получения информации о транспорте, например, механизмы обнаружения или публикации. В первом случае Service SDN Intelligence может обрабатывать полную информацию о транспортных возможностях (включая ресурсы), предлагаемых транспортным слоем. Во втором варианте транспортный слой раскрывает доступные возможности (например, через каталог), снижая объем передаваемых через сеть деталей.

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

Взаимодействие между контроллерами должно быть защищено, например, путем предотвращения атак на службы или иных угроз (должно быть защищено и взаимодействие между узлами сети).

6. Варианты развертывания

Варианты развертывания могут существенно различаться в зависимости от характеристик используемой сети.

6.1. Среда SDN

В этом варианте сети, участвующие в предоставлении и доставке услуг, обладают возможностями SDN.

6.1.1. Множество сервисных слоев с одним транспортным слоем

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

6.1.2. Один сервисный слой с множеством транспортных слоев

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

6.2. Гибридные среды

В этом разделе рассмотрены варианты где один из слоев является полностью или частино унаследованным (не SDN).

6.2.1. Сервисный слой SDN и унаследованный транспортный слой

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

Интеллект SDN в сервисном слое не знает об унаследованной природе базового транспортного слоя.

6.2.2. Унаследованный сервисный слой и транспортный слой SDN

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

6.3. Многодоменные варианты в транспортном слое

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

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

В этом конкретном случае рекурсия делает возможным использовать множество доменов на транспортном уровне.

Многодоменные варианты могут возникать при использовании сетей как одного, так и множества операторов.

В варианте с одним оператором многодоменная или сквозная абстрактная компонента может обеспечить однородное представление возможностей разнородного базового транспорта.

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

7. Примеры использования

В этом разделе представлены примеры использования в качестве иллюстрации применимости модели CLAS.

7.1. Виртуализация сетевых функций (NFV)

Среды NFV6 включает два возможных уровня управления SDN [GSNFV-EVE005]. Одним из уровней является необходимость управлять инфраструктурой NFV (NFVI) для обеспечения сквозной связности между VNF (Virtual Network Function — функция виртуальной сети) или между VNF и PNF (Physical Network Function — функция физической сети). Вторым уровнем является настройка и управление VNF (настройка сетевых служб, реализуемых VNF), которая выигрывает от программных возможностей SDN. Эти уровни разделены по своей природе, однако можно предполагать взаимодействие между ними для оптимизации, расширяемости и влияния друг на друга.

7.2. Абстракции и управление в сетях TE

Модель ACTN7 [RFC8453] позволяет создавать виртуальные сети, предлагаемые клиентам. Роль провайдера в ACTN ограничивается предоставлением услуг виртуальных сетей. Эти услуги по сути являются транспортными и соответствуют транспортному слою в CLAS. Сервисный слой CLAS может считаться клиентом в контексте ACTN.

ACTN определяет иерархию контроллеров для облегчения создания и функционирования виртуальных сетей. Определен интерфейс для взаимодействия между клиентами, запрашивающими услуги виртуальных сетей, и контроллером, отвечающим за оркестровку и обслуживание таких запросов. Такой интерфейс эквивалентен показанному на рисунке 1 (раздел 3) интерфейсу между сервисным и транспортным слоем.

8. Реализация взаимодействия между слоями сервиса и транспорта

Различия между сервисными и транспортными задачами порождают множество проблем при взаимодействии между слоями. Ниже приведен список некоторых известных проблем такого рода.

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

    Некоторые из таких предложений могут быть решениями, подобными [CPNP8] или I-CPI9 [ONFArch].

    Другими кандидатами могут служить транспортный API [TAPI] или транспортный интерфейс северного моста [TRANS-NORTH]. Каждый из этих вариантов имеет свою область действия.

  • Поддержка множества провайдеров. В многодоменных системах, где на транспортном уровне работает более одного провайдера сервисный слой может знать или не знать о наличии множества доменов.

    Если сервисный слой не знает о множестве доменов, транспортный слой выступает в качестве единой точки взаимодействия для запросов сервисного слоя и должен отвечать за взаимодействие с разными доменами.

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

  • Отображение SLA. Оба слоя будут обрабатывать SLA, но природа этих SLA может различаться. Поэтому от объектов каждого слоя требуется отображение сервисных SLA на транспортные (связность) для надлежащей доставки услуг.

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

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

  • Учет. Контроль и учет использования ресурсов услугами должен поддерживаться для связей между слоями.

9. Взаимодействие с IANA

С этим документом не связано действий IANA.

10. Вопросы безопасности

Архитектура CLAS опирается на функциональные элементы, определенные в [RFC7149] и [RFC7426]. Поэтому следует принимать в внимание вопросы безопасности, отмеченные в разделе 5 [RFC7149].

Связи между транспортными и сервисными контроллерами SDN должны быть защищены с использованием:

  • взаимной аутентификации сторон до выполнения каких-либо действий;

  • защиты целостности сообщения.

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

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

Защиту взаимодействий между слоями следует применять к API (и/или протоколам), которые применяются для связи. Поэтому вопросы безопасности будут определяться конкретным решением.

11. Литература

11.1. Нормативные документы

[Y.2011] International Telecommunication Union, «General principles and general reference model for Next Generation Networks», ITU-T Recommendation Y.2011, October 2004, <https://www.itu.int/rec/T-REC-Y.2011-200410-I/en>.

11.2. Дополнительная литература

[CPNP] Boucadair, M., Jacquenet, C., Zhang, D., and P. Georgatsos, «Connectivity Provisioning Negotiation Protocol (CPNP)», Work in Progress, draft-boucadair-connectivity-provisioning-protocol-15, December 2017.

[GSNFV-EVE005] ETSI, «Network Functions Virtualisation (NFV); Ecosystem; Report on SDN Usage in NFV Architectural Framework», ETSI GS NFV-EVE 005, V1.1.1, December 2015, <https://www.etsi.org/deliver/etsi_gs/NFV-EVE/001_099/005/01.01.01_60/gs_nfv-eve005v010101p.pdf>.

[ONFArch] Open Networking Foundation, «SDN Architecture, Issue 1», June 2014, <https://www.opennetworking.org/images/stories/downloads/sdn-resources/technical-reports/TR_SDN_ARCH_1.0_06062014.pdf>.

[RFC7149] Boucadair, M. and C. Jacquenet, «Software-Defined Networking: A Perspective from within a Service Provider Environment», RFC 7149, DOI 10.17487/RFC7149, March 2014, <https://www.rfc-editor.org/info/rfc7149>.

[RFC7297] Boucadair, M., Jacquenet, C., and N. Wang, «IP Connectivity Provisioning Profile (CPP)», RFC 7297, DOI 10.17487/RFC7297, July 2014, <https://www.rfc-editor.org/info/rfc7297>.

[RFC7426] Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S., Hadi Salim, J., Meyer, D., and O. Koufopavlou, «Software-Defined Networking (SDN): Layers and Architecture Terminology», RFC 7426, DOI 10.17487/RFC7426, January 2015, <https://www.rfc-editor.org/info/rfc7426>.

[RFC7926] Farrel, A., Ed., Drake, J., Bitar, N., Swallow, G., Ceccarelli, D., and X. Zhang, «Problem Statement and Architecture for Information Exchange between Interconnected Traffic-Engineered Networks», BCP 206, RFC 7926, DOI 10.17487/RFC7926, July 2016, <https://www.rfc-editor.org/info/rfc7926>.

[RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., «Framework for Abstraction and Control of TE Networks (ACTN)», RFC 8453, DOI 10.17487/RFC8453, August 2018, <https://www.rfc-editor.org/info/rfc8453>.

[SDN-ARCH] Contreras, LM., Bernardos, CJ., Lopez, D., Boucadair, M., and P. Iovanna, «Cooperating Layered Architecture for SDN», Work in Progress, draft-irtf-sdnrg-layered-sdn-01, October 2016.

[TAPI] Open Networking Foundation, «Functional Requirements for Transport API», June 2016, <https://www.opennetworking.org/wp-content/uploads/2014/10/TR-527_TAPI_Functional_Requirements.pdf>.

[TRANS-NORTH] Busi, I., King, D., Zheng, H., and Y. Xu, «Transport Northbound Interface Applicability Statement», Work in Progress, draft-ietf-ccamp-transport-nbi-app-statement-05, March 2019.

Приложение A. Связь с RFC 7426

В [RFC7426] введена таксономия SDN путем определения множества плоскостей, уровней абстракции и интерфейсов или API между ними для прояснения связей между разными составляющими SDN (сетевые устройства, управление, администрирование). Определено множество уровней (плоскостей), включая:

  • уровень пересылки, обеспечивающий доставку пакетов через путь данных на основе инструкций от уровня управления;

  • операционный уровень, обеспечивающий поддержку рабочего состояния сетевого устройства;

  • уровень управления, предназначенный для инструктирования устройств в части пересылки пакетов;

  • уровень администрирования, отвечающий за мониторинг и поддержку сетевых устройств;

  • уровень приложений, обеспечивающий использование для решения различных задач (определяются приложениями) всех управляемых таким способом устройств.

Кроме этого [RFC7426] предлагает множество уровней абстракции, позволяющих объединить разные плоскости через общие интерфейсы. Архитектура CLAS фокусируется на уровнях управления, администрирования и ресурсов в качестве базовых компонент. По существу, уровень управления меняет поведение и действия контролируемых ресурсов. Уровень администрирования обеспечивает мониторинг и получение статуса этих ресурсов. А уровень ресурсов группирует все ресурсы, связанные с задачами каждого слоя.

С этой точки зрения уровни CLAS можно считать надмножеством уровней [RFC7426]. Однако в некоторых случаях не все уровни [RFC7426] могут полностью присутствовать в представлении CLAS (например, уровень пересылки в сервисном слое). При этом внутренняя структура слоя CLAS может соответствовать таксономии [RFC7426]. Отличительная особенность заключается в специализации сред SDN за счет разделения услуг и транспорта.

Благодарности

Этот документ рассмотрен и принят исследовательской группой IRTF SDN как [SDN-ARCH]. После завершения работы группы IRTF SDN RG документ был преобразован в независимое представление (Independent Submission) некоторыми из участников групповых обсуждений.

Авторы выражают свою признательность (в алфавитном порядке) Bartosz Belter, Gino Carrozzo, Ramon Casellas, Gert Grammel, Ali Haider, Evangelos Haleplidis, Zheng Haomian, Giorgios Karagianis, Gabriel Lopez, Maria Rita Palatella, Christian Esteve Rothenberg и Jacek Wytrebowicz за их комментарии и предложения.

Спасибо Adrian Farrel за рецензию.

Адреса авторов

Luis M. Contreras

Telefonica

Ronda de la Comunicacion, s/n

Sur-3 building, 3rd floor

Madrid 28050

Spain

Email: luismiguel.contrerasmurillo@telefonica.com

URI: http://lmcontreras.com

Carlos J. Bernardos

Universidad Carlos III de Madrid

Av. Universidad, 30

Leganes, Madrid 28911

Spain

Phone: +34 91624 6236

Email: cjbc@it.uc3m.es

URI: http://www.it.uc3m.es/cjbc/

Diego R. Lopez

Telefonica

Ronda de la Comunicacion, s/n

Sur-3 building, 3rd floor

Madrid 28050

Spain

Email: diego.r.lopez@telefonica.com

Mohamed Boucadair

Orange

Rennes 35000

France

Email: mohamed.boucadair@orange.com

Paola Iovanna

Ericsson

Pisa

Italy

Email: paola.iovanna@ericsson.com


Перевод на русский язык

Николай Малых

nmalykh@protocols.ru


1Software-Defined Networking.

2Cooperating Layered Architecture for Software-Defined Networking.

3Voice over IP — голосовая связь по протоколу IP.

4Quality-of-Service.

5Next Generation Network — сеть следующего поколения.

6Network Function Virtualization.

7Abstraction and Control of TE Networks.

8Connectivity Provisioning Negotiation Protocol — протокол согласования связности.

9Intermediate-Controller Plane Interface — интерфейс с промежуточным контроллером.




RFC 8531 Generic YANG Data Model for Connection-Oriented Operations, Administration, and Maintenance (OAM) Protocols

Internet Engineering Task Force (IETF)                          D. Kumar
Request for Comments: 8531                                         Cisco
Category: Standards Track                                          Q. Wu
ISSN: 2070-1721                                                  M. Wang
                                                                  Huawei
                                                              April 2019

Generic YANG Data Model for Connection-Oriented Operations, Administration, and Maintenance (OAM) Protocols

Базовая модель данных YANG для ориентированных на соединения протоколов OAM

PDF

Тезисы

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

Модель данных YANG в этом документе соответствует архитектуре NMDA1.

Статус документа

Документ относится к категории Internet Standards Track.

Документ является результатом работы IETF2 и представляет согласованный взгляд сообщества IETF. Документ прошел открытое обсуждение и был одобрен для публикации IESG3. Дополнительную информацию о стандартах Internet можно найти в разделе 2 в RFC 7841.

Информацию о текущем статусе документа, ошибках и способах обратной связи можно найти по ссылке https://www.rfc-editor.org/info/rfc8531.

Авторские права

Авторские права (Copyright (c) 2019) принадлежат IETF Trust и лицам, указанным в качестве авторов документа. Все права защищены.

Этот документ является субъектом прав и ограничений, перечисленных в BCP 78 и IETF Trust Legal Provisions и относящихся к документам IETF (http://trustee.ietf.org/license-info), на момент публикации данного документа. Прочтите упомянутые документы внимательно, поскольку в них описаны права и ограничения, относящиеся к данному документу. Фрагменты программного кода, включенные в этот документ, распространяются в соответствии с упрощенной лицензией BSD, как указано в параграфе 4.e документа IETF Trust Legal Provisions, без каких-либо гарантий (как указано в Simplified BSD License).

Оглавление

Исключено в версии HTML.

1. Введение

OAM включает важные сетевые функции, которые позволяют операторам:

  1. отслеживать состояние сетевых коммуникаций (т. е. проверку доступности и связности);

  2. поиск неполадок (т. е. обнаружение отказов);

  3. контролировать соглашения об уровне обслуживания и производительность (т. е. управлять производительностью).

Обзор инструментов OAM представлен в [RFC7276]. За долгие годы было разработано множество инструментов для контроля отказов и управления производительностью.

Разные наборы инструментов OAM могут поддерживать как технологии на основе соединений, так и без них. В ориентированных на соединения технологиях соединение создается до начала передачи данных. После организации соединения не требуется передачи дополнительной управляющей информации (такой как сигналы или операции) для передачи пользовательских данных. В технологиях без организации соединений данные обычно передаются между взаимодействующими конечными точками без предварительного согласования, но нужны управляющие данные для указания получателя (например, [G.800]). Модель данных YANG для протоколов OAM без организации соединений задана в [RFC8532] и [IEEE802.1Q].

Контроль отказов в соединениях (CFM), как указано в [IEEE802.1Q], является четко определенным стандартом OAM, широко распространенным в сетях Ethernet. ITU-T [G.8013], MEF Forum (MEF) Service OAM [MEF-17], MPLS-TP4 [RFC6371] и TRILL [RFC7455] определяют механизмы OAM, основанные на модели управляемости CFM [IEEE802.1Q].

С учетом широкого распространения базовых концепций OAM, определенных в CFM [IEEE802.1Q], разумным шагом будет разработка унифицированной схемы управления для ориентированных на соединения решений OAM на базе этих концепций. В этом документе модель CFM [IEEE802.1Q] служит основой для расширения до технологически независимой модели и определения соответствующей модели данных YANG. Представленная здесь модель данных YANG служит базой для ориентированных на соединения протоколов OAM и поддерживает базовую проверку непрерывности, проверку связности и обнаружение пути (traceroute). Базовая модель YANG для ориентированных на соединения решений OAM разработана с возможностью расширения на другие технологии, основанные на соединениях. Зависимые от технологии узлы и команды (RPC) определяются в зависимых от технологии моделях данных YANG, которые используют и расширяют определенную здесь базовую модель. Например, расширяемые виртуальные ЛВС (VXLAN5), используют порт отправителя UDP для энтропии потока, а TRILL использует (a) MAC-адрес, (b) тег VLAN или метку Fine-Grained Label и/или (c) адрес IP для энтропии потока в хэшировании при выборе среди множества путей. С учетом этих различий соответствующие модели данных YANG будут определять подходящие структуры в качестве дополнения к представленной здесь базовой модели. Это решает три задачи — во-первых, каждая модель данных YANG сохраняется компактной и управляемой, во-вторых, такие модели можно разрабатывать независимо, и в-третьих, реализации могут ограничиваться поддержкой лишь нужного набора моделей YANG. Например, TRILL RBridge может ограничиться реализацией базовой модели данных и модели TRILL YANG.

Представленная здесь модель данных YANG генерируется на уровне управления. Инкапсуляция и конечные автоматы состояний могут различаться для каждого протокола OAM. Пользователь, желающий ввести программу проверки непрерывности работы (Continuity Check), Loopback или организовать сеанм мониторинга производительности, может сделать это независимо от базового протокола, технологии или конкретной реализации производителя.

В качестве примера рассмотрим случай, где в соединении между устройствами A возникает отказ B. Между A и B имеются мосты IEEE 802.1 a, b и c. Предположим, что эти мосты используют CFM [IEEE802.1Q]. Пользователь, увидев отказ, может решить, что следует выполнить проверку на более низком уровне в разных сегментах пути и запускает соответствующие средства проверки (Loopback Message) и изоляции (Looktrace Message) отказов, использующие общий API. Такая возможность детализации до нижнего уровня стека протоколов в конкретном сегменте пути для поиска точки отказа, называется вложенным процессом OAM. Это полезная концепция, которая обеспечивает эффективный поиск неполадок и процесс обслуживания. Представленная в документе модель данных OAM YANG, ориентированная на соединения, облегчает такой подход не требуя менять базовые протоколы.

Модель данных YANG в этом документе соответствует архитектуре сетевых хранилищ NMDA6, определенной в [RFC8342].

2. Используемые соглашения

Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не следует (SHALL NOT), следует (SHOULD), не нужно (SHOULD NOT), рекомендуется (RECOMMENDED), не рекомендуется (NOT RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе интерпретируются в соответствии с BCP 14 [RFC2119] [RFC8174] тогда и только тогда, когда они выделены шрифтом, как показано здесь.

Многие из применяемых в документе терминов (включая указанные в параграфах 2.1 и 2.2) относятся к сфере OAM. Этот документ не пытается объяснить эти термины и предполагает знакомство читателя с концепциями. Хороший обзор представлен в [IEEE802.1Q]. Термины OAM в работах IETF рассмотрены в [RFC6371].

2.1. Сокращения

CCM

Continuity Check Message — сообщение проверки непрерывности [IEEE802.1Q].

ECMP

Equal-Cost Multipath — множество равноценных путей.

LBM

Loopback Message — сообщение Loopback [IEEE802.1Q].

LTM

Linktrace Message — сообщение Linktrace [IEEE802.1Q].

MP

Maintenance Point — точка обслуживания [IEEE802.1Q].

MEP

Maintenance End Point — конечная точка обслуживания [RFC7174] (называется также Maintenance association End Point [IEEE802.1Q] и MEG End Point [RFC6371]).

MIP

Maintenance Intermediate Point — промежуточная точка обслуживания [RFC7174] (называется также Maintenance domain Intermediate Point [IEEE802.1Q] и MEG Intermediate Point [RFC6371]).

MA

Maintenance Association — ассоциация обслуживания [IEEE802.1Q] [RFC7174].

MD

Maintenance Domain — домен (область) обслуживания [IEEE802.1Q].

MEG

Maintenance Entity Group — группа объектов обслуживания [RFC6371].

MTV

Multi-destination Tree Verification Message — сообщение проверки дерева со множеством получателей.

OAM

Operations, Administration, and Maintenance — операции, администрирование и обслуживания [RFC6291].

TRILL

Transparent Interconnection of Lots of Links — прозрачное соединение множества каналов [RFC6325].

CFM

Connectivity Fault Management — обслуживание отказов в соединениях [RFC7174] [IEEE802.1Q].

RPC

Remote Procedure Call — вызов удаленной процедуры.

CC

Continuity Check — проверка непрерывности [RFC7276].

CV

Connectivity Verification — проверка связности [RFC7276].

2.2. Термины

Continuity Checks — проверка непрерывности

CC служит для проверки доступности адресата, поэтому называется также проверкой доступности.

Connectivity Verification — проверка связности

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

Proactive OAM – OAM в проактивном режиме

Proactive OAM указывает действия OAM, выполняемые непрерывно для упреждающего информирования об отказах. Проактивный метод OAM требует постоянной конфигурации.

On-demand OAM – OAM по запросу

OAM по запросу указывает действия OAM инициируемые вручную для диагностики в течение ограниченного времени. Метод OAM по запросу требует лишь временной конфигурации.

2.3. Диаграммы деревьев

В диаграммах деревьев применяется нотация, определенная в [RFC8340].

3. Архитектура базовой модели YANG для OAM на базе соединений

В этом документе определена базовая модель YANG для ориентированных на соединения протоколов OAM. Модель является базовой в том смысле, что другие технологии могут расширить ее с учетом зависящих от технологии потребностей. Базовая модель данных для ориентированных на соединения протоколов OAM служит корнем для других моделей данных OAM YANG. Это позволяет использовать разные протоколы OAM с использованием унифицированного набора API. Это также делает возможными вложенные процессы OAM. На рисунке 1 показаны связи разных моделей OAM YANG с базовой моделью YANG для ориентированных на соединения протоколов OAM. Эта базовая модель обеспечивает основу, от которой модели YANG для конкретных технологий могут наследовать те или иные конструкции без необходимости их переопределения.

                       +-----------+
                       |Connection-|
                       | Oriented  |
                       |  generic  |
                       | OAM YANG  |
                       +-+-+-+-+-+-+
                             |
                             |
                             |
     +------------------------------------------+
     |                       |                  |
+-+-+-+-+-+          +-+-+-+-+-+          +-+-+-+-+-+
| TRILL   |          | MPLS-TP |     . . .|  foo    |
|OAM YANG |          |OAM YANG |          |OAM YANG |
+-+-+-+-+-+          +-+-+-+-+-+          +-+-+-+-+-+
     |                    |                     |
     |                    |               +-+-+-+-+-+
     |                    |          . . .|  foo    |
     |                    |               |sub tech |
     |                    |               +-+-+-+-+-+
     |                    |                     |
     |                    |                     |
+---------------------------------------------------+
|                      Uniform API                  |
+---------------------------------------------------+

Рисунок 1. Связь модели OAM YANG с базовой моделью YANG.


4. Обзор ориентированной на соединения модели данных OAM YANG

В этом документе применяются концепции модели CFM [IEEE802.1Q] и структура, которые могут быть адаптированы для других протоколов OAM, ориентированных на соединения.

На вершине модели размещается домен обслуживания (MD). Каждый домен обслуживания связан с именем обслуживания (Maintenance Name) и уровнем домена (Domain Level).

В каждом MD имеется одна или множество ассоциаций обслуживания (MA). В TRILL ассоциация MA может соответствовать Fine-Grained Label.

В MA может быть две и более конечных точки обслуживания (MEP), которые задаются адресами, связанными с технологией. Представленная здесь модель YANG обеспечивает гибкость для поддержки разных схем адресации.

Команды представлены в протоколе управления, который ортогонален MD. В терминах YANG это команды RPC. Они обеспечивают унифицированные интерфейсы API для CC, CV, обнаружения пути (traceroute) и их эквивалентов, а также для других команд OAM.

Объекты OAM в определенной здесь базовой модели YANG будут явно или неявно настраиваться с помощью инструментов OAM. Эти инструменты ограничены набором OAM, указанным в параграфе 5.1 [RFC7276]. Для упрощения настройки «в одно касание» (zero-touch) этот документ определяет принятый по умолчанию режим OAM. Этот режим называется базовым (Base Mode) и задает принятые по умолчанию значения для каждого параметра модели (уровень MD, имя MA, адреса MEP и т. д.). Принятые по умолчанию значения зависят от технологии. Базовый режим для TRILL определен в [RFC7455], а базовые режимы для других технологий и будущие расширения, созданные в IETF, будут определены в соответствующих документах.

Важено отметить, что в модель YANG не требуется вносить изменений для поддержки Base Mode. Реализации, соответствующие этому документу, по умолчанию используют узлы данных применимой технологии. Узлы данных базовой модели доступны лишь для чтения (read-only).

4.1. Конфигурация MD

module: ietf-connection-oriented-oam
 +--rw domains
    +--rw domain* [technology md-name-string]
       +--rw technology        identityref
       +--rw md-name-string    md-name-string
       +--rw md-name-format?   identityref
       +--rw (md-name)?
       |  +--:(md-name-null)
       |     +--rw md-name-null? empty
       +--rw md-level?           md-level

Фрагмент иерархии данных домена OAM.


Контейнер domains является контейнером верхнего уровня в модуле gen-oam. Внутри этого контейнера поддерживаются отдельные списки для MD, индексируемые ключом md-name-string. Лист md-name-string имеет тип, выведенный из string. Могут включаться дополнительные форматы имен из [IEEE802.1Q] или иных стандартов путем связывания md-name-format с identity-ref. Лист md-name-format указывает формат добавленного md-name. Лист md-name представляется как конструкция choice/case. Это обеспечивает простоту дополнения.

4.2. Конфигурация MA

В данном MD может присутствовать одна или множество ассоциаций MA, представляемых в виде списка и индексируемых ma-name-string. Подобно md-name, могут добавляться форматы имен с помощью identity-ref и добавления подходящих операторов case в ma-name.

module: ietf-connection-oriented-oam
 +--rw domains
    +--rw domain* [technology md-name-string]
       .
       .
       +--rw mas
          +--rw ma* [ma-name-string]
             +--rw ma-name-string          ma-name-string
             +--rw ma-name-format?         identityref
             +--rw (ma-name)?
             |  +--:(ma-name-null)
             |     +--rw ma-name-null?     empty

Фрагмент иерархии MA.


4.3. Конфигурация MEP

В данной MA может быть одна или множество конечных точек обслуживания (MEP), представляемых списком в иерархии данных и индексируемых ключом mep-name.

module: ietf-connection-oriented-oam
 +--rw domains
    +--rw domain* [technology md-name-string]
       +--rw technology                  identityref
       .
       .
       +--rw mas
          +--rw ma* [ma-name-string]
             .
             .
             +--rw mep* [mep-name]
             |  +--rw mep-name         mep-name
             |  +--rw (mep-id)?
             |  |  +--:(mep-id-int)
             |  |     +--rw mep-id-int?      int32
             |  +--rw mep-id-format?   identityref
             |  +--rw (mep-address)?
             |  |  +--:(mac-address)
             |  |  |  +--rw mac-address?     yang:mac-address
             |  |  +--:(ip-address)
             |  |     +--rw ip-address?      inet:ip-address
             .          .
             .          .
             .          .

Фрагмент иерархии MEP.


4.4. Определения RPC

Модель RPC упрощает ввод команд на «сервере» (в данном случае на устройстве, которое должно выполнять команды OAM) и получение откликов. Определенная здесь модель RPC абстрагирует команды OAM независимо от технологии.

Для целей OAM определено несколько команд RPC. В этом параграфе для иллюстрации представлен фрагмент команды проверки непрерывности (CC). Полное описание иерархии данных приведено в параграфе 4.7, а модуль YANG описан в разделе 5.

   module: ietf-connection-oriented-oam
       +--rw domains
             +--rw domain* [technology md-name-string]
             +--rw technology        identityref
       .
       .
   rpcs:
     +---x continuity-check {continuity-check}?
     |  +---w input
     |  |  +---w technology?             identityref
     |  |  +---w md-name-string -> /domains/domain/md-name-string
     |  |  +---w md-level?      -> /domains/domain/md-level
     |  |  +---w ma-name-string -> /domains/domain/mas/ma/ma-name-string
     |  |  +---w cos-id?                 uint8
     |  |  +---w ttl?                    uint8
     |  |  +---w sub-type?               identityref
     |  |  +---w source-mep?    -> /domains/domain/mas/ma/mep/mep-name
     |  |  +---w destination-mep
     |  |  |  +---w (mep-address)?
     |  |  |  |  +--:(mac-address)
     |  |  |  |  |  +---w mac-address?     yang:mac-address
     |  |  |  |  +--:(ip-address)
     |  |  |  |     +---w ip-address?      inet:ip-address
     |  |  |  +---w (mep-id)?
     |  |  |  |  +--:(mep-id-int)
     |  |  |  |     +---w mep-id-int?      int32
     |  |  |  +---w mep-id-format?   identityref
     |  |  +---w count?                  uint32
     |  |  +---w cc-transmit-interval?   time-interval
     |  |  +---w packet-size?            uint32
     |  +--ro output
     |     +--ro (monitor-stats)?
     |        +--:(monitor-null)
     |           +--ro monitor-null?   empty
     +---x continuity-verification {connectivity-verification}?
     |  +---w input
     |  |  +---w md-name-string -> /domains/domain/md-name-string
     |  |  +---w md-level?      -> /domains/domain/md-level
     |  |  +---w ma-name-string -> /domains/domain/mas/ma/ma-name-string
     |  |  +---w cos-id?            uint8
     |  |  +---w ttl?               uint8
     |  |  +---w sub-type?          identityref
     |  |  +---w source-mep?    -> /domains/domain/mas/ma/mep/mep-name
     |  |  +---w destination-mep
     |  |  |  +---w (mep-address)?
     |  |  |  |  +--:(mac-address)
     |  |  |  |  |  +---w mac-address?     yang:mac-address
     |  |  |  |  +--:(ip-address)
     |  |  |  |     +---w ip-address?      inet:ip-address
     |  |  |  +---w (mep-id)?
     |  |  |  |  +--:(mep-id-int)
     |  |  |  |     +---w mep-id-int?      int32
     |  |  |  +---w mep-id-format?   identityref
     |  |  +---w count?             uint32
     |  |  +---w interval?          time-interval
     |  |  +---w packet-size?       uint32
     |  +--ro output
     |     +--ro (monitor-stats)?
     |        +--:(monitor-null)
     |           +--ro monitor-null?   empty
     +---x traceroute {traceroute}?
        +---w input
        |  +---w md-name-string -> /domains/domain/md-name-string
        |  +---w md-level?      -> /domains/domain/md-level
        |  +---w ma-name-string -> /domains/domain/mas/ma/ma-name-string
        |  +---w cos-id?             uint8
        |  +---w ttl?                uint8
        |  +---w command-sub-type?   identityref
        |  +---w source-mep?    -> /domains/domain/mas/ma/mep/mep-name
        |  +---w destination-mep
        |  |  +---w (mep-address)?
        |  |  |  +--:(mac-address)
        |  |  |  |  +---w mac-address?     yang:mac-address
        |  |  |  +--:(ip-address)
        |  |  |     +---w ip-address?      inet:ip-address
        |  |  +---w (mep-id)?
        |  |  |  +--:(mep-id-int)
        |  |  |     +---w mep-id-int?      int32
        |  |  +---w mep-id-format?   identityref
        |  +---w count?              uint32
        |  +---w interval?           time-interval
        +--ro output
           +--ro response* [response-index]
              +--ro response-index     uint8
              +--ro ttl?               uint8
              +--ro destination-mep
              |  +--ro (mep-address)?
              |  |  +--:(mac-address)
              |  |  |  +--ro mac-address?     yang:mac-address
              |  |  +--:(ip-address)
              |  |     +--ro ip-address?      inet:ip-address
              |  +--ro (mep-id)?
              |  |  +--:(mep-id-int)
              |  |     +--ro mep-id-int?      int32
              |  +--ro mep-id-format?   identityref
              +--ro mip {mip}?
              |  +--ro interface?     if:interface-ref
              |  +--ro (mip-address)?
              |     +--:(mac-address)
              |     |  +--ro mac-address?   yang:mac-address
              |     +--:(ip-address)
              |        +--ro ip-address?    inet:ip-address
              +--ro (monitor-stats)?
                 +--:(monitor-null)
                    +--ro monitor-null?      empty

Фрагмент иерархии RPC Call Continuity-Check.

4.5. Уведомления

Уведомления передаются при обнаружении и снятии условий дефекта и содержат имена MD и MA, тип дефекта (существующего в данный момент), идентификатор создавшей уведомление точки (generating-mepid) и сообщение defect-message с дополнительными деталями.

4.6. Статистика мониторинга

Группировка для статистики мониторинга применяется модулями YANG для конкретной технологии, которые дополняют базовую модель данных YANG для предоставления статистики с использованием похожих на OAM сообщений проверки непрерывности (CCM7), например, CCM transmit, CCM receive, CCM error и т. п.

4.7. Иерархия данных OAM

Ниже представлена полная иерархия данных, относящихся к ориентированной на соединения модели данных OAM YANG.

 module: ietf-connection-oriented-oam
     +--rw domains
        +--rw domain* [technology md-name-string]
           +--rw technology        identityref
           +--rw md-name-string    md-name-string
           +--rw md-name-format?   identityref
           +--rw (md-name)?
           |  +--:(md-name-null)
           |     +--rw md-name-null?     empty
           +--rw md-level?         md-level
           +--rw mas
              +--rw ma* [ma-name-string]
                 +--rw ma-name-string    ma-name-string
                 +--rw ma-name-format?   identityref
                 +--rw (ma-name)?
                 |  +--:(ma-name-null)
                 |     +--rw ma-name-null?     empty
                 +--rw (connectivity-context)?
                 |  +--:(context-null)
                 |     +--rw context-null?     empty
                 +--rw cos-id?           uint8
                 +--rw cc-enable?        boolean
                 +--rw mep* [mep-name]
                 |  +--rw mep-name         mep-name
                 |  +--rw (mep-id)?
                 |  |  +--:(mep-id-int)
                 |  |     +--rw mep-id-int?      int32
                 |  +--rw mep-id-format?   identityref
                 |  +--rw (mep-address)?
                 |  |  +--:(mac-address)
                 |  |  |  +--rw mac-address?     yang:mac-address
                 |  |  +--:(ip-address)
                 |  |     +--rw ip-address?      inet:ip-address
                 |  +--rw cos-id?          uint8
                 |  +--rw cc-enable?       boolean
                 |  +--rw session* [session-cookie]
                 |     +--rw session-cookie             uint32
                 |     +--rw destination-mep
                 |     |  +--rw (mep-id)?
                 |     |  |  +--:(mep-id-int)
                 |     |  |     +--rw mep-id-int?      int32
                 |     |  +--rw mep-id-format?   identityref
                 |     +--rw destination-mep-address
                 |     |  +--rw (mep-address)?
                 |     |     +--:(mac-address)
                 |     |     |  +--rw mac-address?   yang:mac-address
                 |     |     +--:(ip-address)
                 |     |        +--rw ip-address?    inet:ip-address
                 |     +--rw cos-id?                    uint8
                 +--rw mip* [name] {mip}?
                    +--rw name           string
                    +--rw interface?     if:interface-ref
                    +--rw (mip-address)?
                       +--:(mac-address)
                       |  +--rw mac-address?   yang:mac-address
                       +--:(ip-address)
                          +--rw ip-address?    inet:ip-address

   rpcs:
     +---x continuity-check {continuity-check}?
     |  +---w input
     |  |  +---w technology?             identityref
     |  |  +---w md-name-string -> /domains/domain/md-name-string
     |  |  +---w md-level?      -> /domains/domain/md-level
     |  |  +---w ma-name-string -> /domains/domain/mas/ma/ma-name-string
     |  |  +---w cos-id?                 uint8
     |  |  +---w ttl?                    uint8
     |  |  +---w sub-type?               identityref
     |  |  +---w source-mep?    -> /domains/domain/mas/ma/mep/mep-name
     |  |  +---w destination-mep
     |  |  |  +---w (mep-address)?
     |  |  |  |  +--:(mac-address)
     |  |  |  |  |  +---w mac-address?     yang:mac-address
     |  |  |  |  +--:(ip-address)
     |  |  |  |     +---w ip-address?      inet:ip-address
     |  |  |  +---w (mep-id)?
     |  |  |  |  +--:(mep-id-int)
     |  |  |  |     +---w mep-id-int?      int32
     |  |  |  +---w mep-id-format?   identityref
     |  |  +---w count?                  uint32
     |  |  +---w cc-transmit-interval?   time-interval
     |  |  +---w packet-size?            uint32
     |  +--ro output
     |     +--ro (monitor-stats)?
     |        +--:(monitor-null)
     |           +--ro monitor-null?   empty
     +---x continuity-verification {connectivity-verification}?
     |  +---w input
     |  |  +---w md-name-string -> /domains/domain/md-name-string
     |  |  +---w md-level?      -> /domains/domain/md-level
     |  |  +---w ma-name-string -> /domains/domain/mas/ma/ma-name-string
     |  |  +---w cos-id?            uint8
     |  |  +---w ttl?               uint8
     |  |  +---w sub-type?          identityref
     |  |  +---w source-mep?    -> /domains/domain/mas/ma/mep/mep-name
     |  |  +---w destination-mep
     |  |  |  +---w (mep-address)?
     |  |  |  |  +--:(mac-address)
     |  |  |  |  |  +---w mac-address?     yang:mac-address
     |  |  |  |  +--:(ip-address)
     |  |  |  |     +---w ip-address?      inet:ip-address
     |  |  |  +---w (mep-id)?
     |  |  |  |  +--:(mep-id-int)
     |  |  |  |     +---w mep-id-int?      int32
     |  |  |  +---w mep-id-format?   identityref
     |  |  +---w count?             uint32
     |  |  +---w interval?          time-interval
     |  |  +---w packet-size?       uint32
     |  +--ro output
     |     +--ro (monitor-stats)?
     |        +--:(monitor-null)
     |           +--ro monitor-null?   empty
     +---x traceroute {traceroute}?
        +---w input
        |  +---w md-name-string -> /domains/domain/md-name-string
        |  +---w md-level?      -> /domains/domain/md-level
        |  +---w ma-name-string -> /domains/domain/mas/ma/ma-name-string
        |  +---w cos-id?             uint8
        |  +---w ttl?                uint8
        |  +---w command-sub-type?   identityref
        |  +---w source-mep?    -> /domains/domain/mas/ma/mep/mep-name
        |  +---w destination-mep
        |  |  +---w (mep-address)?
        |  |  |  +--:(mac-address)
        |  |  |  |  +---w mac-address?     yang:mac-address
        |  |  |  +--:(ip-address)
        |  |  |     +---w ip-address?      inet:ip-address
        |  |  +---w (mep-id)?
        |  |  |  +--:(mep-id-int)
        |  |  |     +---w mep-id-int?      int32
        |  |  +---w mep-id-format?   identityref
        |  +---w count?              uint32
        |  +---w interval?           time-interval
        +--ro output
           +--ro response* [response-index]
              +--ro response-index     uint8
              +--ro ttl?               uint8
              +--ro destination-mep
              |  +--ro (mep-address)?
              |  |  +--:(mac-address)
              |  |  |  +--ro mac-address?     yang:mac-address
              |  |  +--:(ip-address)
              |  |     +--ro ip-address?      inet:ip-address
              |  +--ro (mep-id)?
              |  |  +--:(mep-id-int)
              |  |     +--ro mep-id-int?      int32
              |  +--ro mep-id-format?   identityref
              +--ro mip {mip}?
              |  +--ro interface?     if:interface-ref
              |  +--ro (mip-address)?
              |     +--:(mac-address)
              |     |  +--ro mac-address?   yang:mac-address
              |     +--:(ip-address)
              |        +--ro ip-address?    inet:ip-address
              +--ro (monitor-stats)?
                 +--:(monitor-null)
                    +--ro monitor-null?      empty

   notifications:
     +---n defect-condition-notification
     |  +--ro technology?         identityref
     |  +--ro md-name-string -> /domains/domain/md-name-string
     |  +--ro ma-name-string -> /domains/domain/mas/ma/ma-name-string
     |  +--ro mep-name?      -> /domains/domain/mas/ma/mep/mep-name
     |  +--ro defect-type?        identityref
     |  +--ro generating-mepid
     |  |  +--ro (mep-id)?
     |  |  |  +--:(mep-id-int)
     |  |  |     +--ro mep-id-int?      int32
     |  |  +--ro mep-id-format?   identityref
     |  +--ro (defect)?
     |     +--:(defect-null)
     |     |  +--ro defect-null?        empty
     |     +--:(defect-code)
     |        +--ro defect-code?        int32
     +---n defect-cleared-notification
        +--ro technology?         identityref
        +--ro md-name-string -> /domains/domain/md-name-string
        +--ro ma-name-string -> /domains/domain/mas/ma/ma-name-string
        +--ro mep-name?      -> /domains/domain/mas/ma/mep/mep-name
        +--ro defect-type?        identityref
        +--ro generating-mepid
        |  +--ro (mep-id)?
        |  |  +--:(mep-id-int)
        |  |     +--ro mep-id-int?      int32
        |  +--ro mep-id-format?   identityref
        +--ro (defect)?
           +--:(defect-null)
           |  +--ro defect-null?        empty
           +--:(defect-code)
              +--ro defect-code?        int32

Иерархия OAM.

5. Модуль OAM YANG

Этот модуль импортирует определения типов (typedef) из [RFC6991] и [RFC8343], а также ссылается на [RFC6371], [RFC6905] и [RFC7276].

   <CODE BEGINS> file "ietf-connection-oriented-oam@2019-04-16.yang"
module ietf-connection-oriented-oam {
  yang-version 1.1;
  namespace "urn:ietf:params:xml:ns:yang:ietf-connection-oriented-oam";
  prefix co-oam;

  import ietf-yang-types {
    prefix yang;
  }
  import ietf-inet-types {
    prefix inet;
  }
  import ietf-interfaces {
    prefix if;
  }

  organization
    "IETF LIME Working Group";
  contact
    "WG Web:    http://datatracker.ietf.org/wg/lime 
     WG List:   <mailto:lime@ietf.org> 
     Editor:    Deepak Kumar <dekumar@cisco.com> 
     Editor:    Qin Wu <bill.wu@huawei.com> 
     Editor:    Michael Wang <wangzitao@huawei.com>"; 
  description
    "Этот модуль YANG определяет базовую конфигурацию,
     статистику и RPC для ориентированных на соединения OAM,
     применяемых в IETF независимо от протокола. Абстракция
     функционального уровня не зависит от модели YANG.
     Предполагается, что каждый протокол отображает 
     соответствующие абстракции на их естественный формат.
     Каждый протокол может расширять модель YANG, определенную 
     здесь, для решения специфических задач.

     Авторские права (Copyright (c) 2019) принадлежат IETF Trust
     и лицам, указанным как авторы кода. Все права защищены.

     Распространение и использование модуля в исходном или двоичном
     формате, с изменениями или без таковых разрешено в соответствии 
     с условиями лицензии Simplified BSD License, изложенными в
     разделе 4.c документа IETF Trust's Legal Provisions применительно
     применительно к документам IETF (http://trustee.ietf.org/license-info). 

     Эта версия модуля YANG является частью RFC 8531, где правовые
     аспекты изложены более полно.";

  revision 2019-04-16 {
    description
      "Первый выпуск.";
    reference
      "RFC 8531: Generic YANG Data Model for Connection-
       Oriented Operations, Administration, and Maintenance (OAM)
       Protocols";
  }

  feature connectivity-verification {
    description
      "Это свойство указывает, что сервер поддерживает команду
       OAM для проверки связности и возвращает отклик. Серверы,
       не анонсирующие эту возможность, не будут поддерживать
       выполнение команды проверки связности или модели RPC для
       такой команды.";
  }

  feature continuity-check {
    description
      "Это свойство указывает, что сервер поддерживает команду
       OAM CC и возвращает отклик. Серверы, не анонсирующие
       эту возможность, не будут поддерживать команду CC или 
       модель RPC для нее.";
  }

  feature traceroute {
    description
      "Это свойство указывает, что сервер поддерживает команду
       OAM traceroute и возвращает отклик. Серверы, не 
       анонсирующие  эту возможность, не будут поддерживать 
       команду traceroute или модель RPC для traceroute.";
  }

  feature mip {
    description
      "Это свойство показывает, что MIP требует явной настройки.";
  }
  identity technology-types {
    description
      "Базовое отождествление типов технологии (TRILL, MPLS-TP и т. п.).";
  }

  identity command-sub-type {
    description
      "Определяет субтипы различных команд RPC, например,
       TRILL OAM как указано в RFC 6905. В большинстве
       случаев это не обязательно.";
    reference
      "RFC 6905: Requirements for OAM in Transparent
       Interconnection of Lots of Links (TRILL)";
  }

  identity on-demand {
    base command-sub-type;
    description
      "Активизация по запросу указывает, что инструмент запускается
       вручную для поиска соответствующей аномалии.
       OAM по запросу требует лишь временной настройки конфигурации.";
    reference
      "RFC 7276: An Overview of Operations, Administration, and
       Maintenance (OAM) Tools";
  }

  identity proactive {
    base command-sub-type;
    description
      "Проактивный режим показывает, что инструмент работает непрерывно,
       сообщения передаются периодически, а ошибкой считается отсутствие 
       некоторого числа сообщения. Проактивный режим требует постоянной
       настройки конфигурации.";
    reference
      "RFC 7276: An Overview of Operations, Administration, and
       Maintenance (OAM) Tools";
  }

  identity name-format {
    description
      "Определяет формат имени, отличающийся от CFM (IEEE 802.1Q). 
       Предполагается, что формат имени является идентификационной
       ссылкой, которая будет расширена новыми типами.";
  }

  identity name-format-null {
    base name-format;
    description
      "Определяет формат как пустой (null).";
  }

  identity identifier-format {
    description
      "Отождествление identifier-format может быть дополнено для
       определения других форматов, применяемых в MEP-ID и пр.";
  }

  identity identifier-format-integer {
    base identifier-format;
    description
      "Определяет identifier-format как целое число.";
  }

  identity defect-types {
    description
      "Определяет различные типы дефектов, например,
       RDI8, потеря непрерывности.";
  }

  identity rdi {
    base defect-types;
    description
      "RDI указывает общее состояние точек MEP.";
  }

  identity remote-mep-defect {
    base defect-types;
    description
      "Указывает, что одна или несколько удаленных MEP
       сообщили об отказе.";
  }

  identity loss-of-continuity {
    base defect-types;
    description
      "Указывает, что в течение заданного интервала не было пакетов CC
       OAM от удаленной MEP (а в случае CV, это включает требование
       наличия уникального, зависящего от технологии идентификатора MEP).";
    reference
      "RFC 6371: Operations, Administration, and Maintenance
       Framework for MPLS-Based Transport Networks";
  }

  identity cv-defect {
    base defect-types;
    description
      "Этой функции следует поддерживать мониторинг между MEP, а
       также между MEP и MIP. При выполнении CV сообщения CC и
       CC-V9 должны однозначно указывать проверяемую MEG и
       MEP, передающую сообщение.";
    reference
      "RFC 6371: Operations, Administration, and Maintenance
       Framework for MPLS-Based Transport Networks";
  }

  identity invalid-oam-defect {
    base defect-types;
    description
      "Указывает, что было получено 1 или несколько непригодных 
       сообщений OAM, а интервал передачи сообщений OAM еще не
       истек (3,5 раза).";
  }

  identity cross-connect-defect {
    base defect-types;
    description
      "Указывает, что был получен 1 или несколько дефектов кросс-
       соединений (например, идентификатор сервиса не соответствует
       VLAN), а интервал передачи сообщений OAM еще не истек (3,5 раза).";
  }

  typedef mep-name {
    type string;
    description
      "Базовое административное имя для MEP.";
  }

  typedef time-interval {
    type decimal64 {
      fraction-digits 2;
    }
    units "milliseconds";
    description
      "Временной интервал между пакетами в мсек, который следует
       задавать не меньше 0. Нулевой интервал означает отсутствие
       передачи пакетов.";
  }

  typedef md-name-string {
    type string;
    description
      "Базовое административное имя для MD.";
  }

  typedef ma-name-string {
    type string;
    description
      "Базовое административное имя для MA.";
  }

  typedef oam-counter32 {
    type yang:zero-based-counter32;
    description
      "Определяет 32-битовый счетчик для OAM.";
  }

  typedef md-level {
    type uint32 {
      range "0..255";
    }
    description
      "Уровень домена обслуживания (MD). Некоторые протоколы 
       могут ограничивать уровень (например, от 0 до 7).";
  }

  grouping maintenance-domain-reference {
    description
      "Эта группировка однозначно указывает MD.";
    leaf maintenance-domain {
      type leafref {
        path "/co-oam:domains/co-oam:domain/co-oam:md-name-string";
      }
      description
        "Указание конкретного MD.";
    }
  }

  grouping maintenance-association-reference {
    description
      "Эта группировка однозначно указывает MA и 
       состоит из leafref maintenance-domain-reference 
       и maintenance-association.";
    uses maintenance-domain-reference;
    leaf maintenance-association {
      type leafref {
        path "/co-oam:domains/co-oam:domain[co-oam:md-name-string "
           + "= current()/../maintenance-domain]/co-oam:mas"
           + "/co-oam:ma/co-oam:ma-name-string";
      }
      description
        "Указание конкретной MA.";
    }
  }

  grouping maintenance-association-end-point-reference {
    description
      "Эта группировка однозначно указывает MA и 
       состоит из листьев-ссылок 
       maintenance-association-reference и
       a maintenance-association-end-point.";
    uses maintenance-association-reference;
    leaf maintenance-association-end-point {
      type leafref {
        path "/co-oam:domains/co-oam:domain[co-oam:md-name-string "
           + "= current()/../maintenance-domain]/co-oam:mas"
           + "/co-oam:ma[co-oam:ma-name-string = "
           + "current()/../maintenance-association]"
           + "/co-oam:mep/co-oam:mep-name";
      }
      description
        "Указание конкретной MEP.";
    }
  }

  grouping time-to-live {
    leaf ttl {
      type uint8;
      description
        "Время жизни.";
    }
    description
      "Группировка TTL.";
  }

  grouping defect-message {
    choice defect {
      case defect-null {
        description
          "Подстановка для случаев ненужности статуса дефектов.";
        leaf defect-null {
          type empty;
          description
            "Дефекты не определены и будут определяться в моделях
             для конкретных технологий.";
        }
      }
      case defect-code {
        description
          "Подстановка для отображения кода дефекта.";
        leaf defect-code {
          type int32;
          description
            "Значение кода дефекта зависит от технологии.";
        }
      }
      description
        "Варианты сообщения о дефекте.";
    }
    description
      "Сообщение о дефекте.";
  }

  grouping mep-address {
    choice mep-address {
      default "ip-address";
      case mac-address {
        leaf mac-address {
          type yang:mac-address;
          description
            "MAC-адрес.";
        }
        description
          "Адресация MEP на основе MAC-адреса.";
      }
      case ip-address {
        leaf ip-address {
          type inet:ip-address;
          description
            "IP-адрес.";
        }
        description
          "Адресация MEP на основе IP-адреса.";
      }
      description
        "Адресация MEP.";
    }
    description
      "Группировка для адреса MEP";
  }

  grouping mip-address {
    choice mip-address {
      default "ip-address";
      case mac-address {
        leaf mac-address {
          type yang:mac-address;
          description
            "MAC-адрес точки MIP";
        }
        description
          "Адресация MIP на основе MAC-адреса.";
      }
      case ip-address {
        leaf ip-address {
          type inet:ip-address;
          description
            "IP-адрес.";
        }
        description
          "Адресация MIP на основе IP-адреса .";
      }
      description
        "Адресация MIP.";
    }
    description
      "Адрес MIP.";
  }

  grouping maintenance-domain-id {
    description
      "Группировка, содержащая листья, достаточные 
       для идентификации MD.";
    leaf technology {
      type identityref {
        base technology-types;
      }
      mandatory true;
      description
        "Определяет технологию.";
    }
    leaf md-name-string {
      type md-name-string;
      mandatory true;
      description
        "Определяет базовое административное имя MD.";
    }
  }

  grouping md-name {
    leaf md-name-format {
      type identityref {
        base name-format;
      }
      description
        "Формат имени MD.";
    }
    choice md-name {
      case md-name-null {
        leaf md-name-null {
          when "derived-from-or-self(../md-name-format,"
             + "'name-format-null')" {
            description
              "Формат имени MD совпадает с пустым форматом.";
          }
          type empty;
          description
            "Пустое имя MD.";
        }
      }
      description
        "Имя MD.";
    }
    description
      "Имя MD.";
  }

  grouping ma-identifier {
    description
      "Группировка с листьями, достаточными для указания MA.";
    leaf ma-name-string {
      type ma-name-string;
      description
        "Строка имени MA.";
    }
  }

  grouping ma-name {
    description
      "MA name.";
    leaf ma-name-format {
      type identityref {
        base name-format;
      }
      description
        "Формат имени MA.";
    }
    choice ma-name {
      case ma-name-null {
        leaf ma-name-null {
          when "derived-from-or-self(../ma-name-format,"
             + "'name-format-null')" {
            description
              "MA.";
          }
          type empty;
          description
            "Пусто";
        }
      }
      description
        "Имя MA.";
    }
  }

  grouping mep-id {
    choice mep-id {
      default "mep-id-int";
      case mep-id-int {
        leaf mep-id-int {
          type int32;
          description
            "MEP ID в целочисленном формате.";
        }
      }
      description
        "MEP ID.";
    }
    leaf mep-id-format {
      type identityref {
        base identifier-format;
      }
      description
        "Формат MEP ID.";
    }
    description
      "MEP ID.";
  }

  grouping mep {
    description
      "Определяет элементы в MEP.";
    leaf mep-name {
      type mep-name;
      mandatory true;
      description
        "Базовое административное имя MEP.";
    }
    uses mep-id;
    uses mep-address;
  }

  grouping monitor-stats {
    description
      "Группировка для статистики мониторинга, дополняемая 
       другими при использовании этой компоненты.";
    choice monitor-stats {
      default "monitor-null";
      case monitor-null {
        description
          "Заменитель для случаев ненужности статистики 
           мониторинга.";
        leaf monitor-null {
          type empty;
          description
            "Статистика мониторинга не определена.";
        }
      }
      description
        "Определяет состояния монитора.";
    }
  }

  grouping connectivity-context {
    description
      "Группировка, определяющая контекст связности для MA,
       например, LSP для MPLS-TP. Будет дополняться каждым
       протоколом, использующим компоненту.";
    choice connectivity-context {
      default "context-null";
      case context-null {
        description
          "Замена на случая ненужности контекста.";
        leaf context-null {
          type empty;
          description
            "Контекст не определен.";
        }
      }
      description
        "Контекст связности.";
    }
  }

  grouping cos {
    description
      "Группировка для приоритета в отправляемых пакетах,
       например, в поле CoS для MPLS-TP.";
    leaf cos-id {
      type uint8;
      description
        "Идентификатор класса обслуживания (CoS).";
    }
  }

  grouping mip-grouping {
    uses mip-address;
    description
      "Группировка для настройки MIP.";
  }

  container domains {
    description
      "Содержит относящиеся к конфигурации данные. Внутри
       контейнера имеется список сбойных доменов. Каждый
       домен имеет список MA.";
    list domain {
      key "technology md-name-string";
      description
        "Определяет список доменов в модуле 
         ietf-connection-oriented-oam.";
      uses maintenance-domain-id;
      uses md-name;
      leaf md-level {
        type md-level;
        description
          "Определяет уровень MD.";
      }
      container mas {
        description
          "Содержит относящиеся к конфигурации данные. Внутри
           контейнера имеется список MA, каждая из которых
           имеет список MEP.";
        list ma {
          key "ma-name-string";
          uses ma-identifier;
          uses ma-name;
          uses connectivity-context;
          uses cos {
            description
              "Принятый по умолчанию класс обслуживания для MA.
               Список может быть переписан для отдельных MEP,
               сессий или операций.";
          }
          leaf cc-enable {
            type boolean;
            description
              "Указывает включена ли проверка CC.";
          }
          list mep {
            key "mep-name";
            description
              "Содержит список MEP.";
            uses mep;
            uses cos;
            leaf cc-enable {
              type boolean;
              description
                "Указывает включена ли проверка CC.";
            }
            list session {
              key "session-cookie";
              description
                "Сеанс мониторинга с конкретной удаленной точкой MEP.
                 В зависимости от протокола может представлять сообщения
                 CC от удаленной MEP (если протокол применяет групповые
                 CC), целевая точка, куда передаются индивидуальные
                 эхо-запросы CC или откуда принимаются отклики (если
                 протокол использует механизм запрос-отклик с
                 индивидуальной адресацией).";
              leaf session-cookie {
                type uint32;
                description
                  "Cookie для идентификации сессий при наличии множества
                   MEP или множества сессий с одной удаленной точкой MEP.";
              }
              container destination-mep {
                uses mep-id;
                description
                  "Целевая точка MEP.";
              }
              container destination-mep-address {
                uses mep-address;
                description
                  "Адрес целевой точки MEP.";
              }
              uses cos;
            }
          }
          list mip {
            if-feature "mip";
            key "name";
            leaf name {
              type string;
              description
                "Идентификатор точки MIP.";
            }
            leaf interface {
              type if:interface-ref;
              description
                "Интерфейс.";
            }
            uses mip-grouping;
            description
              "List for MIP.";
          }
          description
            "Список ассоциаций MA.";
        }
      }
    }
  }

  notification defect-condition-notification {
    description
      "При обнаружении дефекта передается такое уведомление.";
    leaf technology {
      type identityref {
        base technology-types;
      }
      description
        "Технология.";
    }
    leaf md-name-string {
      type leafref {
        path "/domains/domain/md-name-string";
      }
      mandatory true;
      description
        "Указывает MD, к которому относится дефект.";
    }
    leaf ma-name-string {
      type leafref {
        path "/domains/domain/mas/ma/ma-name-string";
      }
      mandatory true;
      description
        "Указывает MA, с которой связан дефект.";
    }
    leaf mep-name {
      type leafref {
        path "/domains/domain/mas/ma/mep/mep-name";
      }
      description
        "Указывает точку MEP, увидевшую дефект.";
    }
    leaf defect-type {
      type identityref {
        base defect-types;
      }
      description
        "Существующие в данный момент дефекты указанной MEP.";
    }
    container generating-mepid {
      uses mep-id;
      description
        "Указывает кто создал уведомление о дефекте или 0,
         если точка не известна.";
    }
    uses defect-message {
      description
        "Сообщение о дефекте с допонительными детялями.";
    }
  }

  notification defect-cleared-notification {
    description
      "Сообщение, передаваемое при устранении дефекта.";
    leaf technology {
      type identityref {
        base technology-types;
      }
      description
        "Технология.";
    }
    leaf md-name-string {
      type leafref {
        path "/domains/domain/md-name-string";
      }
      mandatory true;
      description
        "Указывает MD, к которому относился дефект.";
    }
    leaf ma-name-string {
      type leafref {
        path "/domains/domain/mas/ma/ma-name-string";
      }
      mandatory true;
      description
        "Указывает MA, с которой был связан дефект.";
    }
    leaf mep-name {
      type leafref {
        path "/domains/domain/mas/ma/mep/mep-name";
      }
      description
        "Указывает точку MEP, увидевшую дефект.";
    }
    leaf defect-type {
      type identityref {
        base defect-types;
      }
      description
        "Существующие в данный момент дефекты указанной MEP.";
    }
    container generating-mepid {
      uses mep-id;
      description
        "Указывает кто создал уведомление о дефекте или 0,
         если точка не известна.";
    }
    uses defect-message {
      description
        "Сообщение о дефекте с допонительными детялями.";
    }
  }

  rpc continuity-check {
    if-feature "continuity-check";
    description
      "Генерирует CC, как указано в таблице 4 RFC 7276.";
    input {
      leaf technology {
        type identityref {
          base technology-types;
        }
        description
          "Технология.";
      }
      leaf md-name-string {
        type leafref {
          path "/domains/domain/md-name-string";
        }
        mandatory true;
        description
          "Указывает MD, к которому относится дефект.";
      }
      leaf md-level {
        type leafref {
          path "/domains/domain/md-level";
        }
        description
          "Уровень MD.";
      }
      leaf ma-name-string {
        type leafref {
          path "/domains/domain/mas/ma/ma-name-string";
        }
        mandatory true;
        description
          "Указывает MA, с которой связан дефект.";
      }
      uses cos;
      uses time-to-live;
      leaf sub-type {
        type identityref {
          base command-sub-type;
        }
        description
          "Определяет различные типы команд.";
      }
      leaf source-mep {
        type leafref {
          path "/domains/domain/mas/ma/mep/mep-name";
        }
        description
          "Исходная точка MEP.";
      }
      container destination-mep {
        uses mep-address;
        uses mep-id {
          description
            "Применимо лишь в случае, когда целью является MEP.";
        }
        description
          "Целевая точка MEP.";
      }
      leaf count {
        type uint32;
        default "3";
        description
          "Число передаваемых сообщений CC.";
      }
      leaf cc-transmit-interval {
        type time-interval;
        description
          "Интервал времени между эхо-запросами.";
      }
      leaf packet-size {
        type uint32 {
          range "64..10000";
        }
        description
          "Размер пакетов CC в октетах.";
      }
    }
    output {
      uses monitor-stats {
        description
          "Статистика CC.";
      }
    }
  }

  rpc continuity-verification {
    if-feature "connectivity-verification";
    description
      "Генерация CV в соответствии с таблицей 4 в RFC 7276.";
    input {
      leaf md-name-string {
        type leafref {
          path "/domains/domain/md-name-string";
        }
        mandatory true;
        description
          "Указывает MD, к которому относится дефект.";
      }
      leaf md-level {
        type leafref {
          path "/domains/domain/md-level";
        }
        description
          "Уровень MD.";
      }
      leaf ma-name-string {
        type leafref {
          path "/domains/domain/mas/ma/ma-name-string";
        }
        mandatory true;
        description
          "Указывает MA, с которой связан дефект.";
      }
      uses cos;
      uses time-to-live;
      leaf sub-type {
        type identityref {
          base command-sub-type;
        }
        description
          "Определяет различные типы команд.";
      }
      leaf source-mep {
        type leafref {
          path "/domains/domain/mas/ma/mep/mep-name";
        }
        description
          "MEP-источник.";
      }
      container destination-mep {
        uses mep-address;
        uses mep-id {
          description
            "Применимо лишь в случае, когда целью является MEP.";
        }
        description
          "Целевая точка MEP.";
      }
      leaf count {
        type uint32;
        default "3";
        description
          "Число передаваемых сообщений CV.";
      }
      leaf interval {
        type time-interval;
        description
          "Интервал времени между эхо-запросами.";
      }
      leaf packet-size {
        type uint32 {
          range "64..10000";
        }
        description
          "Размер пакетов CV в октетах.";
      }
    }
    output {
      uses monitor-stats {
        description
          "Статистика CV.";
      }
    }
  }

  rpc traceroute {
    if-feature "traceroute";
    description
      "Генерирует Traceroute или Path Trace и отклики.
       В RFC 7276 указываются имена инструментов - для MPLS-TP OAM
       - это Route Tracing, а для TRILL OAM - Path Tracing. Начинает
       с TTL = 1 и увеличивает значение на 1 для каждого интервала, 
       пока не будет достигнут адресат или максимальное значение TTL.";
    input {
      leaf md-name-string {
        type leafref {
          path "/domains/domain/md-name-string";
        }
        mandatory true;
        description
          "Указывает MD, к которому относится дефект.";
      }
      leaf md-level {
        type leafref {
          path "/domains/domain/md-level";
        }
        description
          "Уровень MD.";
      }
      leaf ma-name-string {
        type leafref {
          path "/domains/domain/mas/ma/ma-name-string";
        }
        mandatory true;
        description
          "Указывает MA, с которой связан дефект.";
      }
      uses cos;
      uses time-to-live;
      leaf command-sub-type {
        type identityref {
          base command-sub-type;
        }
        description
          "Определяет различные типы команд.";
      }
      leaf source-mep {
        type leafref {
          path "/domains/domain/mas/ma/mep/mep-name";
        }
        description
          "MEP-источник.";
      }
      container destination-mep {
        uses mep-address;
        uses mep-id {
          description
            "Применимо лишь в случае, когда целью является MEP.";
        }
        description
          "Целевая точка MEP.";
      }
      leaf count {
        type uint32;
        default "1";
        description
          "Число передаваемых проб traceroute. В протоколах, где 
           передаются раздельные сообщения для каждого TTL, - это
           число пакетов, переданных с каждым значением TTL.";
      }
      leaf interval {
        type time-interval;
        description
          "Интервал времени между эхо-запросами.";
      }
    }
    output {
      list response {
        key "response-index";
        leaf response-index {
          type uint8;
          description
            "Произвольный индекс для отклика. В протоколах, где 
             гарантируется лишь один отклик для каждого TTL, 
             значение TTL может служить индексом откликов.";
        }
        uses time-to-live;
        container destination-mep {
          description
            "Точка MEP, от которой получен отклик.";
          uses mep-address;
          uses mep-id {
            description
              "Применимо лишь в случае, когда целью является MEP.";
          }
        }
        container mip {
          if-feature "mip";
          leaf interface {
            type if:interface-ref;
            description
              "Интерфейс MIP.";
          }
          uses mip-address;
          description
            "Точка MIP, отвечающая на traceroute";
        }
        uses monitor-stats {
          description
            "Статистика traceroute.";
        }
        description
          "Список откликов.";
      }
    }
  }
}

   <CODE ENDS>

6. Базовый режим

Базовый режим (принят по умолчанию, см. раздел 4) определяет принятую по умолчанию конфигурацию, которая должна присутствовать в устройстве, соответствующем данному документу. Base Mode позволяет пользователям получить опыт настройки «в одно касание». Некоторые параметры требуют задаваемого настройкой определения.

6.1. Адрес MEP

В базовом режиме работы адресом MEP по умолчанию служит IP-адрес интерфейса, где размещается MEP.

6.2. MEP ID для базового режима

В базовом режиме каждое устройство создает одну точку MEP, связанную с виртуальным портом OAM без физического уровня (NULL PHY). MEP-ID для этой точки MEP имеет значение 0 (см. разъяснение ниже).

MEP-ID по умолчанию является 2-октетным полем. Оно не применяется в линии (проводе) кроме случаев использования CCM. Важно иметь метод автоматического выведения MEP-ID для базового режима без участия пользователя. IP-адрес не подходит для этого, поскольку поле MEP-ID имеет меньший размер. Для базового режима работы по умолчанию выбрано значение MEP-ID = 0.

Пакеты CCM используют MEP-ID в поле данных (payload). CCM недопустимо применять в базовом режиме, поэтому CCM должны быть запрещены в MA для Base Mode.

Если CCM требуется, пользователи должны настроить отдельную MA и присвоить уникальные идентификаторы соответствующим MEP.

CFM [IEEE802.1Q] определяет MEP-ID как целое число без знака со значением от 1 до 8191. В этом документе предлагается расширить диапазон значений до 0 — 65535. Значение 0 резервируется для MEP-ID в базовом режиме работы и его недопустимо применять в других случаях.

6.3. Ассоциация обслуживания (MA)

Идентификаторы MA (MA-ID) [IEEE802.1Q] имеют гибкий формат и включают две части — имя MD и краткое имя MA. В базовом режиме работы значением имени MD должна быть строка символов «GenericBaseMode» (включая кавычки). Формат Short MA Name включает 2-октетный целочисленный формат (значение 3 в поле Short MA Format [IEEE802.1Q]) и имя Short MA со значением 65532 (0xFFFC).

7. Применимость модели YANG для OAM на основе соединений

Определенный здесь модуль ietf-connection-oriented-oam, обеспечивает независимую от технологии абстракцию основных конструкций OAM для ориентированных на соединения протоколов. Этот модуль можно расширить путем добавления зависимых от технологий деталей, например определяя новые узлы данных с зависящими от технологии функциями и параметрами в соответствующую точку базовой модели, чтобы получить ориентированную на соединения модель OAM для конкретной технологии.

В этом разделе показана возможность применения ориентированной на соединения модели данных YANG OAM для таких технологий, как TRILL и MPLS-TP. Отметим, что здесь преведено лишь несколько фрагментов связанных с технологиями расширений. Полные расширения модели должны быть разработаны в соответствующих протоколах.

7.1. Расширение базовой модели данных YANG для TRILL OAM

Модуль TRILL OAM YANG [TRILL-YANG-OAM] является дополнением ориентированного на соединения модуля OAM для настройки и RPC.

Кроме того, для модуля TRILL OAM YANG нужна также поддержка базового модуля TRILL ([TRILL-YANG]), поскольку они тесно связаны между собой.

Конфигурационные расширения для ориентированного на соединения модуля OAM включают расширение для настройки MD, типа технологии, настройки MA, Connectivity-Context, настройки MEP и ECMP. В расширении RPC команды проверки связности и обнаружения пути дополняются связанными с TRILL параметрами.

7.1.1. Расширение MD Configuration

Конфигурационные параметры уровня MD являются управляющей информацией, которая может наследоваться в модели TRILL OAM с использованием значений базовой модели в качестве принятых по умолчанию. Например, в качестве имени домена может быть задано значение area-ID для случая TRILL OAM. Кроме того, на уровне MD (т. е. корневом) узел данных домена может быть дополнен типом технологии.

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

7.1.1.1. Расширение Technology Type

В базовой модели не определен тип технологии TRILL. Поэтому требуется расширение для определения этого типа в модели TRILL OAM. Тип trill определен как элемент, дополняющий базовое определение technology-types в модели.

      identity trill{
       base co-oam:technology-types;
       description
        "trill type";
      }

7.1.2. Расширение MA Configuration

Конфигурационные параметры уровня MA являются управляющей информацией, которая может наследоваться в модели TRILL OAM с использованием значений базовой модели в качестве принятых по умолчанию. Кроме того, на уровне MA (т. е. на втором), узел данных MA может быть дополнен расширением с контекстом соединения.

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

7.1.2.1. Расширение Connectivity-Context

В TRILL OAM примером контекста связности является 12-битовое значение VLAN ID или 24-битовое значение Fine-Grained Label. Ориентированная на соединения базовая модель включает заменитель для context-id. Это позволяет другим технологиям легко дополнить заменитель и включить связанное с технологией расширение. Приведенный ниже фрагмент показывает пример дополнения контекста связности путем включения VLAN ID или Fine-Grained Label.

      augment /co-oam:domains/co-oam:domain
   /co-oam:mas/co-oam:ma/co-oam:connectivity-context:
            +--:(connectivity-context-vlan)
            |  +--rw connectivity-context-vlan?   vlan
            +--:(connectivity-context-fgl)
               +--rw connectivity-context-fgl?    fgl

7.1.3. Расширение MEP Configuration

Определение конфигурации MEP в базовой модели уже поддерживает настройку интерфейса MEP с адресом MAC или IP. Кроме того, адрес MEP можно представить с помощью 2-октетного RBridge Nickname в TRILL OAM. Поэтому модель TRILL OAM дополняет конфигурацию MEP базовой модели дополнительной возможностью задания адреса.

   augment /co-oam:domains/co-oam:domain
   /co-oam:mas/co-oam:ma/co-oam:mep/co-oam:mep-address:
            +--:( mep-address-trill)
            |  +--rw mep-address-trill?  tril-rb-nickname

В дополнение к этому на уровне MEP (т. е. третьем) узел данных MEP может быть дополнен расширением ECMP.

7.1.3.1. Расширение ECMP

Поскольку TRILL поддерживает ECMP при выборе пути, энтропия потока в TRILL определяется как 96-октетное поле в Layer-Independent OAM Management расширения модели LIME10 для TRILL OAM. Фрагмент дерева приведен ниже.

      augment /co-oam:domains/co-oam:domain
   /co-oam:mas/co-oam:ma/co-oam:mep:
               +--rw flow-entropy-trill?   flow-entropy-trill
      augment /co-oam:domains/co-oam:domain
   /co-oam:mas/co-oam:ma/co-oam:mep/co-oam:session:
               +--rw flow-entropy-trill?   flow-entropy-trill

7.1.4. Расширение RPC

В модели данных TRILL OAM YANG команды RPC для проверки связности и обнаружения пути предполагаются с учетом требований TRILL. Приведенный ниже фрагмент описывает расширение TRILL OAM RPC.

      augment /co-oam:continuity-check/co-oam:input:
            +--ro (out-of-band)?
            |  +--:(ipv4-address)
            |  |  +--ro ipv4-address?      inet:ipv4-address
            |  +--:(ipv6-address)
            |  |  +--ro ipv6-address?      inet:ipv6-address
            |  +--:(trill-nickname)
            |     +--ro trill-nickname?    tril-rb-nickname
            +--ro diagnostic-vlan?   boolean
      augment /co-oam:continuity-check/co-oam:input:
               +--ro flow-entropy-trill?   flow-entropy-trill
      augment /co-oam:continuity-check/co-oam:output:
            +--ro upstream-rbridge?   tril-rb-nickname
            +--ro next-hop-rbridge*   tril-rb-nickname
      augment /co-oam:path-discovery/co-oam:input:
            +--ro (out-of-band)?
            |  +--:(ipv4-address)
            |  |  +--ro ipv4-address?      inet:ipv4-address
            |  +--:(ipv6-address)
            |  |  +--ro ipv6-address?      inet:ipv6-address
            |  +--:(trill-nickname)
            |     +--ro trill-nickname?    tril-rb-nickname
            +--ro diagnostic-vlan?   boolean
      augment /co-oam:path-discovery/co-oam:input:
               +--ro flow-entropy-trill?   flow-entropy-trill
      augment /co-oam:path-discovery/co-oam:output/co-oam:response:
            +--ro upstream-rbridge?   tril-rb-nickname
            +--ro next-hop-rbridge*   tril-rb-nickname

7.2. Расширение базовой модели YANG для MPLS-TP OAM

Модуль MPLS-TP OAM YANG может дополнять ориентированный на соединения модуль OAM некоторыми детялями, связанными с технологией. В [MPLS-TP-OAM-YANG] представлена модель данных YANG для MPLS-TP OAM.

Конфигурационные расширения базовой модели OAM включают расширение для настройки MD, тип и субтип технологии, расширения для настройки MA и MEP.

7.2.1. Расширение MD Configuration

Конфигурационные параметры уровня MD являются управляющей информацией, которая может наследоваться в модели MPLS-TP OAM с использованием значений базовой модели в качестве принятых по умолчанию. Например, в качестве имени домена может быть задано значение area-ID или номер автономной системы провайдера (ASN11) [RFC6370] для случая MPLS-TP OAM. Кроме того, на уровне MD (т. е. корневом) узел данных домена может быть дополнен типом и субтипом технологии.

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

7.2.1.1. Расширение Technology Type

Тип технологии MPLS-TP не определен в базовой модели, поэтому требуется расширение для определения этого типа в модели MPLS-TP OAM. Тип mpls-tp определен как элемент, дополняющий базовое определение technology-types в модели.

       identity mpls-tp{
             base co-oam:technology-types;
             description
              "mpls-tp type";
            }
7.2.1.2. Расширение Technology Subtype

Поскольку в MPLS-TP применяются разные типы инкапсуляции (такие как IP/UDP и PW-ACH), в модели MPLS-TP OAM определен узел данных technology-sub-type для идентификации используемого типа инкапсуляции. С помощью этого узла определены субтипы для инкапсуляции IP/UDP и PW-ACH, а также могут быть определены другие субтипы. Приведенный ниже фрагмент показывает пример определения нескольких типов.

   identity technology-sub-type {
         description
         "Некоторые реализации могут применять другие типы 
          инкапсуляции (IP/UDP, PW-ACH и т. п.). Вместо
          задания отдельной модели для каждого типа определен
          субтип технологии для указания инкапсуляции. Этот
          тип указывается на уровне MA."; }

              identity technology-sub-type-udp {
                base technology-sub-type;
                description
                  "Субтип для инкапсуляции IP/UDP.";
              }

              identity technology-sub-type-ach {
                base technology-sub-type;
                description
                  "Субтип для инкапсуляции PW-ACH.";
              }
              }

         augment "/co-oam:domains/co-oam:domain"
               + "/co-oam:mas/co-oam:ma" {
                leaf technology-sub-type {
                  type identityref {
                    base technology-sub-type;
                  }
                }
              }

7.2.2. Расширение MA Configuration

Конфигурационные параметры уровня MA являются управляющей информацией, которая может наследоваться в модели MPLS-TP OAM с использованием значений базовой модели в качестве принятых по умолчанию. Примерами MA Name являются MPLS-TP LSP MEG_ID, MEG Section ID, MEG PW ID [RFC6370].

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

7.2.3. Расширение MEP Configuration

В MPLS-TP идентификатором MEP-ID служит значение метки с переменным размером в случае инкапсуляции G-ACH или 2-октетное целое число без знака при инкапсуляции IP/UDP. Одним из вариантов MEP-ID в MPLS-TP является LSP_MEP_ID [RFC6370]. В ориентированной на соединения базовой модели MEP-ID определен как узел choice/case, который может поддерживать значения int32 и такие же значения применяются в MPLS-TP. В дополнение к этому на уровне MEP (третий уровень) узел данных MEP может быть дополнен расширением для сессии или интерфейса.

8. Вопросы безопасности

Описанный здесь модуль YANG определяет схему для данных, которые предназначены для доступа с помощью протоколов сетевого управления, таких как NETCONF [RFC6241] или RESTCONF [RFC8040]. Нижним уровнем NETCONF является защищенный транспорт с обязательной поддержкой протокола SSH12 [RFC6242]. Нижним уровнем RESTCONF служит HTTPS с обязательной поддержкой протокола TLS [RFC8446].

Модель управления доступом к конфигурации сети [RFC8341] обеспечивает способы ограничить доступ определенных пользователей NETCONF или RESTCONF предопределенным подмножеством операций и содержимого NETCONF или RESTCONF.

Множество узлов данных в модуле YANG доступны для чтения, создания и удаления (значение config true, принятое по умолчанию). Эти узлы могут считаться деликатными в некоторых сетевых средах. Запись в такие узлы (например, edit-config) без соответствующей защиты может оказывать негативное влияние на работу сети. К таким узлам и субдеревьям относятся:

   /co-oam:domains/co-oam:domain/
   /co-oam:domains/co-oam:domain/co-oam:mas/co-oam:ma
   /co-oam:domains/co-oam:domain/co-oam:mas/co-oam:ma/co-oam:mep
   /co-oam:domains/co-oam:domain/co-oam:mas/co-oam:ma/co-oam:mep/co-oam:session

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

9. Взаимодействие с IANA

Этот документ регистрирует URI в реестре IETF XML Registry [RFC3688], куда внесены приведенные ниже данные.

     URI: urn:ietf:params:xml:ns:yang:ietf-connection-oriented-oam
     Registrant Contact: The IESG.
     XML: N/A; the requested URI is an XML namespace.

Документ регистрирует модуль YANG в реестре YANG Module Names [RFC6020].

  name:         ietf-connection-oriented-oam
  namespace:    urn:ietf:params:xml:ns:yang:ietf-connection-oriented-oam
  prefix:       co-oam
  reference:    RFC 8531

10. Литература

10.1. Нормативные документы

[IEEE802.1Q] IEEE, «IEEE Standard for Local and Metropolitan Area Networks-Bridges and Bridged Networks», IEEE Std 802.1Q.

[RFC2119] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC3688] Mealling, M., «The IETF XML Registry», BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, <https://www.rfc-editor.org/info/rfc3688>.

[RFC6020] Bjorklund, M., Ed., «YANG — A Data Modeling Language for the Network Configuration Protocol (NETCONF)», RFC 6020, DOI 10.17487/RFC6020, October 2010, <https://www.rfc-editor.org/info/rfc6020>.

[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., «Network Configuration Protocol (NETCONF)», RFC 6241, DOI 10.17487/RFC6241, June 2011, <https://www.rfc-editor.org/info/rfc6241>.

[RFC6242] Wasserman, M., «Using the NETCONF Protocol over Secure Shell (SSH)», RFC 6242, DOI 10.17487/RFC6242, June 2011, <https://www.rfc-editor.org/info/rfc6242>.

[RFC6370] Bocci, M., Swallow, G., and E. Gray, «MPLS Transport Profile (MPLS-TP) Identifiers», RFC 6370, DOI 10.17487/RFC6370, September 2011, <https://www.rfc-editor.org/info/rfc6370>.

[RFC6991] Schoenwaelder, J., Ed., «Common YANG Data Types», RFC 6991, DOI 10.17487/RFC6991, July 2013, <https://www.rfc-editor.org/info/rfc6991>.

[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, «RESTCONF Protocol», RFC 8040, DOI 10.17487/RFC8040, January 2017, <https://www.rfc-editor.org/info/rfc8040>.

[RFC8174] Leiba, B., «Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words», BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8341] Bierman, A. and M. Bjorklund, «Network Configuration Access Control Model», STD 91, RFC 8341, DOI 10.17487/RFC8341, March 2018, <https://www.rfc-editor.org/info/rfc8341>.

[RFC8343] Bjorklund, M., «A YANG Data Model for Interface Management», RFC 8343, DOI 10.17487/RFC8343, March 2018, <https://www.rfc-editor.org/info/rfc8343>.

[RFC8446] Rescorla, E., «The Transport Layer Security (TLS) Protocol Version 1.3», RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/info/rfc8446>.

10.2. Дополнительная литература

[G.800] «Unified functional architecture of transport networks», ITU-T Recommendation G.800, 2016.

[G.8013] «OAM functions and mechanisms for Ethernet based networks», ITU-T Recommendation G.8013/Y.1731, 2013.

[MEF-17] MEF Forum, «Service OAM Requirements & Framework — Phase 1», MEF 17, April 2007.

[MPLS-TP-OAM-YANG] Zhang, L., Zheng, L., Aldrin, S., and G. Mirsky, «YANG Data Model for MPLS-TP Operations, Administration, and Maintenance (OAM)», Work in Progress, draft-zhang-mpls-tp-yang-oam-05, October 2017.

[RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu, D., and S. Mansfield, «Guidelines for the Use of the «OAM» Acronym in the IETF», BCP 161, RFC 6291, DOI 10.17487/RFC6291, June 2011, <https://www.rfc-editor.org/info/rfc6291>.

[RFC6325] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. Ghanwani, «Routing Bridges (RBridges): Base Protocol Specification», RFC 6325, DOI 10.17487/RFC6325, July 2011, <https://www.rfc-editor.org/info/rfc6325>.

[RFC6371] Busi, I., Ed. and D. Allan, Ed., «Operations, Administration, and Maintenance Framework for MPLS-Based Transport Networks», RFC 6371, DOI 10.17487/RFC6371, September 2011, <https://www.rfc-editor.org/info/rfc6371>.

[RFC6905] Senevirathne, T., Bond, D., Aldrin, S., Li, Y., and R. Watve, «Requirements for Operations, Administration, and Maintenance (OAM) in Transparent Interconnection of Lots of Links (TRILL)», RFC 6905, DOI 10.17487/RFC6905, March 2013, <https://www.rfc-editor.org/info/rfc6905>.

[RFC7174] Salam, S., Senevirathne, T., Aldrin, S., and D. Eastlake 3rd, «Transparent Interconnection of Lots of Links (TRILL) Operations, Administration, and Maintenance (OAM) Framework», RFC 7174, DOI 10.17487/RFC7174, May 2014, <https://www.rfc-editor.org/info/rfc7174>.

[RFC7276] Mizrahi, T., Sprecher, N., Bellagamba, E., and Y. Weingarten, «An Overview of Operations, Administration, and Maintenance (OAM) Tools», RFC 7276, DOI 10.17487/RFC7276, June 2014, <https://www.rfc-editor.org/info/rfc7276>.

[RFC7455] Senevirathne, T., Finn, N., Salam, S., Kumar, D., Eastlake 3rd, D., Aldrin, S., and Y. Li, «Transparent Interconnection of Lots of Links (TRILL): Fault Management», RFC 7455, DOI 10.17487/RFC7455, March 2015, <https://www.rfc-editor.org/info/rfc7455>.

[RFC8340] Bjorklund, M. and L. Berger, Ed., «YANG Tree Diagrams», BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, <https://www.rfc-editor.org/info/rfc8340>.

[RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., and R. Wilton, «Network Management Datastore Architecture (NMDA)», RFC 8342, DOI 10.17487/RFC8342, March 2018, <https://www.rfc-editor.org/info/rfc8342>.

[RFC8532] Kumar, D., Wang, M., Wu, Q., Ed., Rahman, R., and S. Raghavan, «Generic YANG Data Model for the Management of Operations, Administration, and Maintenance (OAM) Protocols That Use Connectionless Communications», RFC 8532, DOI 10.17487/RFC8532, April 2019, <https://www.rfc-editor.org/info/rfc8532>.

[TRILL-YANG] Weiguo, H., Yizhou, L., Kumar, D., Durrani, M., Zhai, H., and L. Xia, «TRILL YANG Data Model», Work in Progress, draft-ietf-trill-yang-04, December 2015.

[TRILL-YANG-OAM] Kumar, D., Senevirathne, T., Finn, N., Salam, S., Xia, L., and H. Weiguo, «YANG Data Model for TRILL Operations, Administration, and Maintenance (OAM)», Work in Progress, draft-ietf-trill-yang-oam-05, March 2017.

Благодарности

Giles Heron предложил разработать модель данных YANG в качестве пути создания унифицированного набора OAM API и этот документ во многом вдохновлен этим преддложением. Alexander Clemm дал много ценных советов, комментариев и замечаний, которые помогли улучшить представленную здесь модель YANG.

Carlos Pignataro, David Ball, Mahesh Jethanandani, Benoit Claise, Ladislav Lhotka, Jens Guballa, Yuji Tochio, Gregory Mirsky, Huub van Helvoort, Tom Taylor, Dapeng Liu, Mishael Wexler и Adi Molkho внесли важный вклад в разработку этого документа.

Участники работы

Tissa Senevirathne

Consultant

Email: tsenevir@gmail.com

Norman Finn

CISCO Systems

510 McCarthy Blvd

Milpitas, CA 95035

United States of America

Email: nfinn@cisco.com

Samer Salam

CISCO Systems

595 Burrard St. Suite 2123

Vancouver, BC V7X 1J1

Canada

Email: ssalam@cisco.com

Адреса авторов

Deepak Kumar

CISCO Systems

510 McCarthy Blvd

Milpitas, CA 95035

United States of America

Email: dekumar@cisco.com

Qin Wu

Huawei

101 Software Avenue, Yuhua District

Nanjing, Jiangsu 210012

China

Email: bill.wu@huawei.com

Michael Wang

Huawei Technologies, Co., Ltd

101 Software Avenue, Yuhua District

Nanjing 210012

China

Email: wangzitao@huawei.com


Перевод на русский язык

Николай Малых

nmalykh@protocols.ru

1Network Management Datastore Architecture — архитектура хранилища данных сетевого управления.

2Internet Engineering Task Force.

3Internet Engineering Steering Group.

4MPLS Transport Profile — транспортный профиль MPLS.

5Virtual eXtensible Local Area Network.

6Network Management Datastore Architecture — архитектура хранилища данных конфигурации сети.

7Continuity Check Message.

8Remote Defect Indication — индикация удаленного дефекта.

9Connectivity Verification.

10Multi-Layer Environment — многоуровневое расширение.

11Autonomous System Number.

12Secure Shell — защищенная оболочка.