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 с (см. раздел 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 на предыдущий интервал, если при обработке Interest возникла ошибка. Возвращенное сообщение Interest может быть дополнительно обработано предыдущим интервалом или возвращено в направлении источника Interest. Когда узел возвращает Interest, он указывает, что предыдущему интервалу не следует ожидать от него отклика для 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. Это позволяет различать через сегмент имени без включения самих байтов данных.

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 normalization и соглашениях протокола маршрутизации, становятся возможными фишинговые атаки.

Более общее рассмотрение вопросов безопасности 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 — защищенная оболочка.




RFC 8527 RESTCONF Extensions to Support the Network Management Datastore Architecture

Internet Engineering Task Force (IETF)                      M. Bjorklund
Request for Comments: 8527                                Tail-f Systems
Updates: 8040                                           J. Schoenwaelder
Category: Standards Track                              Jacobs University
ISSN: 2070-1721                                                P. Shafer
                                                        Juniper Networks
                                                               K. Watsen
                                                         Watsen Networks
                                                               R. Wilton
                                                           Cisco Systems
                                                              March 2019

RESTCONF Extensions to Support the Network Management Datastore Architecture

Расширения RESTCONF для поддержки архитектуры NMDA

PDF

Тезисы

Этот документ расширяет протокол RESTCONF, определенный в RFC 8040, для поддержки архитектуры NMDA1, определенной в RFC 8342.

Документ обновляет RFC 8040 за счет добавления новых ресурсов и нового параметра запросов, а также требования использовать библиотеку YANG (описана RFC 8525) на серверах RESTCONF, реализующих NMDA.

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

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

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

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

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

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

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

Оглавление

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

1. Введение

Этот документ расширяет протокол RESTCONF [RFC8040] для поддержки архитектуры NMDA, определенной в [RFC8342].

Документ обновляет [RFC8040], чтобы позволить клиентам RESTCONF определять обеспечиваемые сервером RESTCONF хранилища и поддерживаемые каждым хранилищем модули, а также взаимодействовать со всеми хранилищами с архитектурой NMDA. В частности, обновление добавляет новые ресурсы хранилищ и новый параметр запроса, а также требует применять библиотеку YANG [RFC8525] на серверах RESTCONF с поддержкой NMDA.

Представленное здесь решение совместимо с [RFC8040]. Это достигнуто за счет того, что новые ресурсы добавлены без изменения семантики имеющихся ресурсов.

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

С документе применяется терминология, определенная NMDA [RFC8342].

Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не следует (SHALL NOT), следует (SHOULD), не нужно (SHOULD NOT), рекомендуется (RECOMMENDED), не рекомендуется (NOT RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе интерпретируются в соответствии с BCP 14 [RFC2119] [RFC8174] тогда и только тогда, когда они выделены шрифтом, как показано здесь.

2. Хранилище данных и требования YANG Library

Соответствующий NMDA сервер RESTCONF должен поддерживать хранилище рабочего состояния и должен реализовать как минимум выпуск 2019-01-04 модуля ietf-yang-library, определенного в [RFC8525].

Такой сервер указывает свою поддержку NMDA путем реализации ресурса {+restconf}/ds/ietf-datastores:operational и выпуска модуля ietf-yang-library не раньше 2019-01-04.

Клиент RESTCONF может проверить поддержку сервером архитектуры NMDA с помощью метода HEAD или GET для ресурса {+restconf}/ds/ietf-datastores:operational.

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

3. Расширения RESTCONF

В этом разделе описаны расширения RESTCONF, требуемые для поддержки архитектуры NMDA.

3.1. Новые ресурсы хранилища данных

Документ определяет набор новых ресурсов, представляющих хранилища данных [RFC8342]. Эти ресурсы доступны с использованием шаблона пути

     {+restconf}/ds/<datastore>

Компонента <datastore> кодируется как identityref в соответствии с правилами JSON, заданными в параграфе 6.8 [RFC7951]. Должны применяться идентификаторы с указанием пространства имен, которые должны выводиться из отождествления datastore, определенного в модуле YANG ietf-datastores [RFC8342].

В частности

  • ресурс {+restconf}/ds/ietf-datastores:operational указывает хранилище рабочего состояния;

  • ресурс {+restconf}/ds/ietf-datastores:running указывает хранилище рабочей конфигурации;

  • ресурс {+restconf}/ds/ietf-datastores:intendedуказывает хранилище предполагаемой конфигурации.

Сервер с поддержкой NMDA должен реализовать ресурс {+restconf}/ds/ietf-datastores:operational и может реализовать другие ресурсы.

Действия YANG могут вызываться лишь для ресурса {+restconf}/ds/ietf-datastores:operational.

Например, если сервер реализует хранилище с именем ds-ephemeral, определенное в модуле example-ds-ephemeral, он будет поддерживать ресурс {+restconf}/ds/example-ds-ephemeral:ds-ephemeral.

3.2. Протокольные операции

Для новых ресурсов хранилища данных (параграф 3.1) доступны те же протокольные операции, которые определены в [RFC8040] для ресурса {+restconf}/data с некоторыми исключениями, перечисленными ниже.

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

  • Некоторые хранилища по своей природе доступны лишь для чтения (например, <intended>), поэтому попытки изменить их будут приводить к отказам. Сервер должен возвращать в таких случаях отклик «405 Method Not Allowed» с кодом ошибки operation-not-supported.

  • Семантика параметра запроса with-defaults (параграф 4.8.9 в [RFC8040]) отличается при взаимодействии с хранилище рабочего состояния (см. параграф 3.2.1).

  • Абзац 3 в параграфе 3.5.4 [RFC8040] не применим при взаимодействии с ресурсами ветви {+restconf}/ds.

3.2.1. Параметр with-defaults для запроса к хранилищу рабочего состояния

Поддержка параметра запросов with-defaults (параграф 4.8.9 в [RFC8040]) необязательна при взаимодействии с ресурсом {+restconf}/ds/ietf-datastores:operational. Соответствующая возможность для индикации поддержки на сервере указывается URI

     urn:ietf:params:restconf:capability:with-operational-defaults:1.0

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

  • Если параметр запроса with-defaults не задан или имеет значение explicit, report-all или report-all-tagged, из хранилища рабочего состояния возвращаются значения in use, как определено в параграфе 5.3 [RFC8342] даже при наличии у принятого по умолчанию значения узла в модуле YANG и использовании сервером этого значения. Если with-defaults имеет значение report-all-tagged, все значения, соответствующие принятым по умолчанию в схеме, сопровождаются дополнительными метаданными, как описано в параграфе 4.8.9 [RFC8040].

  • Если параметр with-defaults имеет значение trim, возвращаются все значения in use, кроме тех, которые фильтруются на выходе для исключения принятых по умолчанию значений схемы YANG.

Серверы не обязаны поддерживать все значения для параметра with-defaults в запросах к хранилищу рабочего состояния. Если запрос содержит не поддерживаемое значение параметра, сервер возвращает ошибку в соответствии с параграфом 4.8.9 [RFC8040].

3.2.2. Новый параметр запроса with-origin

Добавлен новый параметр запроса with-origin для операции GET. При наличии этого параметра в запросе сервер будет включать в отклик аннотации метаданных origin, как определено в NMDA. Это параметр действует только для запросов к {+restconf}/ds/ietf-datastores:operational и другим хранилищам данных, производным от operational. При указании непригодного хранилища сервер должен возвращать отклик 400 Bad Request с кодом ошибки invalid-value. Аннотации метаданных origin не включаются в отклики без явного запроса клиента.

Данные в хранилище рабочего состояния могут приходить от разных источников. Серверу следует возвращать аннотацию метаданных origin, наиболее точно указывающую источник значения раббочего состояния, как указано в параграфе 5.3.4 [RFC8342].

При кодировании аннотации метаданных origin для иерархии возвращаемых узлов аннотации для дочерних узлов могут опускаться, если они совпадают с аннотациями родительских узлов, как описано в модуле YANG ietf-origin [RFC8342].

Поддержка параметра запроса with-origin является необязателльной и указывается URI

     urn:ietf:params:restconf:capability:with-origin:1.0

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

Этот документ определяет два идентификатора URN в реестре RESTCONF Capability URNs, заданном в [RFC8040].

Индекс

Идентификатор возможности

:with-origin
urn:ietf:params:restconf:capability:with-origin:1.0
:with-operational-defaults
urn:ietf:params:restconf:capability:with-operational-defaults:1.0

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

Этот документ расширяет протокол RESTCONF путем добавления новых ресурсов хранилищ данных. Базовым уровнем для RESTCONF является HTTPS с обязательной реализацией защищенного транспорта TLS [RFC8446]. Протокол RESTCONF использует модель управления доступом к настройке сети [RFC8341], которая позволяет ограничивать доступ конкретных пользователей RESTCONF предопределенным набором протокольных операций и содержимого RESTCONF.

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

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

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

[RFC7951] Lhotka, L., «JSON Encoding of Data Modeled with YANG», RFC 7951, DOI 10.17487/RFC7951, August 2016, <https://www.rfc-editor.org/info/rfc7951>.

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

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

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

[RFC8525] Bierman, A., Bjorklund, M., Schoenwaelder, J., Watsen, K., and R. Wilton, «YANG Library», RFC 8525, DOI 10.17487/RFC8525, March 2019, <https://www.rfc-editor.org/info/rfc8525>.

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

Martin Bjorklund

Tail-f Systems

Email: mbj@tail-f.com

Juergen Schoenwaelder

Jacobs University

Email: j.schoenwaelder@jacobs-university.de

Phil Shafer

Juniper Networks

Email: phil@juniper.net

Kent Watsen

Watsen Networks

Email: kent+ietf@watsen.net

Robert Wilton

Cisco Systems

Email: rwilton@cisco.com


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

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

nmalykh@protocols.ru

1Network Management Datastore Architecture — архитектура хранилища данных сетевого управления.

2Internet Engineering Task Force.

3Internet Engineering Steering Group.




RFC 8525 YANG Library

Internet Engineering Task Force (IETF)                        A. Bierman
Request for Comments: 8525                                     YumaWorks
Obsoletes: 7895                                             M. Bjorklund
Category: Standards Track                                 Tail-f Systems
ISSN: 2070-1721                                         J. Schoenwaelder
                                                       Jacobs University
                                                               K. Watsen
                                                         Watsen Networks
                                                               R. Wilton
                                                           Cisco Systems
                                                              March 2019

YANG Library

Библиотека YANG

PDF

Тезисы

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

Данный документ отменяет RFC 7895.

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

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

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

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

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

Авторские права (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. Введение

Нужны стандартные механизмы для идентификации модулей YANG [RFC7950], хранилищ данных [RFC8342] и схем хранилищ [RFC8342] применяемых сервером сетевого управления.

Данный документ описывает модуль YANG ietf-yang-library, который обеспечивает эту информацию. Данная версия библиотеки YANG совместима с архитектурой хранилищ NMDA [RFC8342]. Предыдущая версия библиотеки YANG, определенная в [RFC7895], не совместима с NMDA, поскольку предполагает применение во всех хранилищах одной схемы. Это может не соблюдаться в NMDA, где динамические хранилища конфигурации могут применять свои схемы. Кроме того, хранилище рабочего состояния может поддерживать ненастраиваемые модули YANG в дополнение к модулям, поддерживаемым традиционными хранилищами конфигурации.

Определения старой библиотеки YANG сохранены (для совместимости), но отмечены как deprecated (устаревшие). Для совместимости с прежними версиями серверам с поддержкой NMDA следует заполнять устаревшее дерево /modules-state в соответствии со старой версией. Новое дерево /yang-library будет игнорироваться старыми клиентами, но обеспечит все данные, требуемые поддерживающим NMDA клиентам (они будут игнорировать дерево /modules-state). При заполнении /modules-state рекомендуется указывать модули YANG с узлами данных config true, которые могут настраиваться через традиционные хранилища конфигурации, и модули YANG с узлами config false, которые возвращаются операцией NETCONF4 <get> или ее эквивалентом.

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

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

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

Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не следует (SHALL NOT), следует (SHOULD), не нужно (SHOULD NOT), рекомендуется (RECOMMENDED), не рекомендуется (NOT RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе интерпретируются в соответствии с BCP 14 [RFC2119] [RFC8174] тогда и только тогда, когда они выделены шрифтом, как показано здесь.

Перечисленные ниже термины определены в [RFC7950]:

  • module — модуль;

  • submodule — субмодуль;

  • data node — узел данных.

В документе фраза «реализует модуль» (implement a module) применяется в трактовке параграфа 5.6.5 [RFC7950].

Перечисленные ниже термины определены в [RFC8342]:

  • datastore — хранилище данных;

  • datastore schema — схема хранилища данных;

  • configuration — конфигурация;

  • conventional configuration datastore — традиционное хранилище данных;

  • operational state — рабочее состояние;

  • operational state datastore — хранилище рабочего состояния;

  • dynamic configuration datastore — динамическое хранилище конфигурации;

  • client — клиент;

  • server — сервер.

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

YANG library — библиотека YANG

Набор модулей и субмодулей YANG, хранилищ и схем хранилищ, применяемых сервером.

YANG library content identifier – идентификатор содержимого библиотеки YANG

Генерируемый сервером идентификатор содержимого библиотеки YANG.

В диаграммах деревьев данный документ использует обозначения, определенные в [RFC8340].

2. Постановка задачи

Приведенная ниже информация нужна клиентскому приложению (для каждого модуля YANG в библиотеке) для полного использования языка моделирования данных YANG:

  • name — имя модуля YANG;

  • revision — при наличии этой информации в модуле или субмодулей YANG номер выпуска берется из наиболее свежего оператора revision в модуле или субмодуле;

  • submodule list — имя и (при наличии) выпуск каждого субмодуля, используемого модулем;

  • feature list — имя каждой функции (возможности) YANG, поддерживаемой сервером;

  • deviation list — имя каждого модуля YANG с оператором deviation, влияющим на данный модуль YANG.

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

  • identity — отождествление YANG для хранилища данных;

  • schema — схема (т. е. набор модулей), реализованная в хранилище.

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

  1. Информация должна быть удобна для потребителя. Поскольку библиотека YANG может быть велика, следует позволять клиентам кэшировать содержимое библиотеки YANG.

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

  3. Можно не реализовать функцию или модуль в <operational> даже эсли это реализовано в другом хранилище. Это требуется для переходного процесса — сервер, желающий реализовать <operational>, не обязан поддерживать все модули сразу.

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

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

  6. Должна обеспечиваться возможность использования библиотеки YANG при монтировании схемы [RFC8528].

3. Модель данных библиотеки YANG

Модуль ietf-yang-library предоставляет информацию о модулях, субмодулях, хранилищах и схемах хранилищ, поддерживаемых сервером. Все узлы данных модуля ietf-yang-library имеют тип config false и поэтому доступны лишь в хранилище рабочего состояния.

+-----------+
| хранилище |
+-----------+
     |
     | имеет
     V
+-----------+            +--------+                +------------+
|   схема   |объединение | набор  |  состоит из    | модули +   |
| хранилища |----------->| модулей|--------------->| субмодули  |
+-----------+            +--------+                +------------+

Рисунок 1.


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

Ниже приведена диаграмма дерева YANG для модуля ietf-yang-library без устаревшего дерева /modules-state.

   module: ietf-yang-library
     +--ro yang-library
        +--ro module-set* [name]
        |  +--ro name                  string
        |  +--ro module* [name]
        |  |  +--ro name         yang:yang-identifier
        |  |  +--ro revision?    revision-identifier
        |  |  +--ro namespace    inet:uri
        |  |  +--ro location*    inet:uri
        |  |  +--ro submodule* [name]
        |  |  |  +--ro name        yang:yang-identifier
        |  |  |  +--ro revision?   revision-identifier
        |  |  |  +--ro location*   inet:uri
        |  |  +--ro feature*     yang:yang-identifier
        |  |  +--ro deviation*   -> ../../module/name
        |  +--ro import-only-module* [name revision]
        |     +--ro name         yang:yang-identifier
        |     +--ro revision     union
        |     +--ro namespace    inet:uri
        |     +--ro location*    inet:uri
        |     +--ro submodule* [name]
        |        +--ro name        yang:yang-identifier
        |        +--ro revision?   revision-identifier
        |        +--ro location*   inet:uri
        +--ro schema* [name]
        |  +--ro name          string
        |  +--ro module-set*   -> ../../module-set/name
        +--ro datastore* [name]
        |  +--ro name      ds:datastore-ref
        |  +--ro schema    -> ../../schema/name
        +--ro content-id    string
     notifications:
       +---n yang-library-update
          +--ro content-id    -> /yang-library/content-id

Контейнер /yang-library содержит всю библиотеку YANG и имеет перечисленные ниже дочерние узлы.

  • /yang-library/module-set содержит записи, представляющие наборы модулей. Список /yang-library/module-set/module перечисляет все модули, относящиеся к набору. Модуль указывается вместе с субмодулями (если они имеются), набором функций и всеми отклонениями. Список /yang-library/module-set/import-only-module содержит все модули (и их субмодули), используемые лишь для импорта. Назначение модуля в набор определяется сервером. Данный выпуск библиотеки YANG не задает семантики включения модуля в список набора.

  • Список /yang-library/schema содержит записи для каждой схемы хранилища, поддерживаемой сервером. Все традиционные хранилища данных используют общую запись списка schema. Динамическое хранилище конфигурации может использовать другую схему и для него может потребоваться отдельная запись в списке schema. Запись имеет лист-список (leaf-list) ссылок на записи в списке module-set. Схема является объединением всех модулей во всех указанных наборах.

  • Список /yang-library/datastore содержит одну запись для каждого хранилища, поддерживаемого сервером, и указывает связанную с хранилищем схему путем ссылки на запись списка schema. Каждое поддерживаемое традиционное хранилище имеет свою запись, указывающую на общий элемент списка schema.

  • Лист /yang-library/content-id содержит идентификатор содержимого библиотеки YANG, зависящий от реализации, который представляет текущие данные в библиотеке YANG на конкретном сервере. Значение этого листа должно меняться при любом изменении информации в библиотеке YANG. Не трребуется совпадение content-id для одной и той же информации. Этот лист позволяет клиентам извлекать сразу всю информацию схемы, кэшировать ее и запрашивать снова лишь при изменении листа. Если этот лист меняется, сервер также генерирует уведомление yang-library-update.

Отметим, что для серверов NETCONF, реализующих расширения NETCONF для поддержки NMDA [RFC8526], изменение идентификатора содержимого библиотеки YANG приводит к новому значению возможности :yang-library:1.1, определенной в [RFC8526]. Если такой сервер реализует уведомления NETCONF [RFC5277] и генерируются уведомления netconf-capability-change [RFC6470], такие уведомления будут создаваться при каждой смене идентификатора содержимого библиотеки YANG.

4. Модуль библиотеки YANG

Модуль YANG ietf-yang-library импортирует определения из модулей ietf-yang-types и ietf-inet-types, определенных в [RFC6991], а также из модуля ietf-datastores, определенного в [RFC8342]. Хотя модуль YANG определен с использованием YANG версии 1.1, библиотека YANG поддерживает модули YANG для любой версии языка YANG.

   <CODE BEGINS> file "ietf-yang-library@2019-01-04.yang"

   module ietf-yang-library {
     yang-version 1.1;
     namespace "urn:ietf:params:xml:ns:yang:ietf-yang-library";
     prefix yanglib;

     import ietf-yang-types {
       prefix yang;
       reference
         "RFC 6991: Common YANG Data Types";
     }
     import ietf-inet-types {
       prefix inet;
       reference
         "RFC 6991: Common YANG Data Types";
     }
     import ietf-datastores {
       prefix ds;
       reference
         "RFC 8342: Network Management Datastore Architecture
                    (NMDA)";
     }

     organization
       "IETF NETCONF (Network Configuration) Working Group";
     contact
       "WG Web:   <https://datatracker.ietf.org/wg/netconf/> 
        WG List:  <mailto:netconf@ietf.org>

        Author:   Andy Bierman
                  <mailto:andy@yumaworks.com> 

        Author:   Martin Bjorklund
                  <mailto:mbj@tail-f.com> 

        Author:   Juergen Schoenwaelder
                  <mailto:j.schoenwaelder@jacobs-university.de> 

        Author:   Kent Watsen
                  <mailto:kent+ietf@watsen.net> 

        Author:   Robert Wilton
                  <mailto:rwilton@cisco.com>"; 
     description
       "Этот модуль содержит информацию о модулях YANG, хранилищах и
        схемах хранилищ, используемых сервером сетевого управления.

        Клучевые слова ДОЛЖНО, НЕДОПУСТИМО, ТРЕБУЕТСЯ, НУЖНО, НЕ СЛЕДУЕТ, 
        СЛЕДУЕТ, НЕ НУЖНО, РЕКОМЕДУЕТСЯ, НЕ РЕКОМЕНДУЕТСЯ, МОЖНО и
        НЕОБЯЗАТЕЛЬНО в этом документе интерпретируются в соответствии с
        BCP 14 (RFC 2119) (RFC 8174) тогда и только тогда, когда они
        указаны заглавными буквами, как показано здесь.

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

        Распространение и использование в исходной или двоичной форме
        с изменениями или без таковых разрешено в соответствии с 
        упрощенной лицензией BSD, как указано в параграфе 4.c
        документа IETF Trust Legal Provisions применительно к 
        документам IETF (https://trustee.ietf.org/license-info). 

        Данная версия модуля YANG является частью RFC 8525, где
        правовые аспекты изложены более полно.";

     revision 2019-01-04 {
       description
         "Добавлена поддержка хранилищ данных с архитектурой NMDA.";
       reference
         "RFC 8525: YANG Library";
     }
     revision 2016-04-09 {
       description
         "Первый выпуск.";
       reference
         "RFC 7895: YANG Module Library";
     }

     /*
      * Определения типов
      */

     typedef revision-identifier {
       type string {
         pattern '\d{4}-\d{2}-\d{2}';
       }
       description
         "Представляет дату в формате ГГГГ-ММ-ЧЧ format.";
     }

     /*
      * Группировки
      */

     grouping module-identification-leafs {
       description
         "Параметры для идентификации модулей и субмодулей YANG.";
       leaf name {
         type yang:yang-identifier;
         mandatory true;
         description
           "Имя модуля или субмодуля YANG.";
       }
       leaf revision {
         type revision-identifier;
         description
           "Дата выпуска модуля или субмодуля YANG. Если оператора revision
            нет в модуле или субмодуле YANG, этот лист не создается.";
       }
     }

     grouping location-leaf-list {
       description
         "Общий параметр leaf-list для местоположения модулей и субмодулей.";
       leaf-list location {
         type inet:uri;
         description
           "Содержит идентификатор URL, представляющий ресурс схемы YANG 
            для модуля или субмодуля.

            Этот лист присутствует лишь при налияии URL для извлечения
            схемы для данной записи.";
       }
     }

     grouping module-implementation-parameters {
       description
         "Параметры для описания реализации модуля..";
       leaf-list feature {
         type yang:yang-identifier;
         description
           "Список имен всех возможностей YANG из данного модуля, 
            поддерживаемых сервером, независимо от их определения
            в модуле или включенном в него субмодуле.";
       }
       leaf-list deviation {
         type leafref {
           path "../../module/name";
         }
         description
           "Список всем модулей отклонения YANG, используемых сервером,
            для изменения соответствия модуля, связанного с этой записью.
            Отметим, что один и тот же модуль может служить для отклонений
            разных модулей, поэтому одна запись МОЖЕТ присутствовать в 
            нескольких записях module.

            Этой ссылке НЕДОПУСТИМО указывать (напрямую или косвенно)
            на отклоняющийся модуль.

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

     grouping module-set-parameters {
       description
         "Набор параметров, описывающих набор модулей.";
       leaf name {
         type string;
         description
           "Произвольное имя набора модулей.";
       }
       list module {
         key "name";
         description
           "Запись этого списка представляет модуль, реализованный сервером,
            как описано в параграфе 5.6.5 RFC 7950, с конкретным набором
            поддерживаемых возможностей и отклонений.";
         reference
           "RFC 7950: The YANG 1.1 Data Modeling Language";
         uses module-identification-leafs;
         leaf namespace {
           type inet:uri;
           mandatory true;
           description
             "Идентификатор пространства имен XML для этого модуля.";
         }
         uses location-leaf-list;
         list submodule {
           key "name";
           description
             "Каждая запись представляет один субмодуль в родительском
              модуле.";
           uses module-identification-leafs;
           uses location-leaf-list;
         }
         uses module-implementation-parameters;
       }
       list import-only-module {
         key "name revision";
         description
           "Запись этого списка указывает, что сервер импортирует 
            многократно используемые определения из указанного выпуска
            модуля, но не реализует из этого выпуска каких-либо
            доступных протоколу объектов.

            Для одного модуля МОЖЕТ присутствовать множество записей. 
            Это может быть обусловлено импортом множеством модулей одного
            модуля с указанием разных дат выпуска в операторах revision.";
         leaf name {
           type yang:yang-identifier;
           description
             "Имя модуля YANG.";
         }
         leaf revision {
           type union {
             type revision-identifier;
             type string {
               length "0";
             }
           }
           description
             "Дата выпуска модуля YANG. При отсутствии оператора
              revision в модуле YANG указывается пустая строка.";
         }
         leaf namespace {
           type inet:uri;
           mandatory true;
           description
             "Пространство имен XML для этого модуля.";
         }
         uses location-leaf-list;
         list submodule {
           key "name";
           description
             "Каждая запись представляет один субмодуль в родительском
              модуле.";
           uses module-identification-leafs;
           uses location-leaf-list;
         }
       }
     }
     grouping yang-library-parameters {
       description
         "Структура данных библиотеки YANG представлена как группировка,
          поэтому ее можно повторно применять в конфигурации или иных 
          структурах данных мониторинга.";
       list module-set {
         key "name";
         description
           "Набор модулей, который может применяться в одной или 
            нескольких схемах.

            Набор модулей не обязан быть ссылочно полным, т. е он может
            определять модули, содержащие операторы import для модулей
            не включенных в этот набор.";
         uses module-set-parameters;
       }
       list schema {
         key "name";
         description
           "Схема хранилища, которая может применяться одним или
            несколькими хранилищами.

            Схема должна быть действительной и ссылочно полное, т. е.
            она должна включать модули для выполнения всех операторов 
            import во всех модулях, указанных в схеме.";
         leaf name {
           type string;
           description
             "Произвольное имя схемы.";
         }
         leaf-list module-set {
           type leafref {
             path "../../module-set/name";
           }
           description
             "Набор module-set, включенных в схему. Если не импортируемый
              модуль присутствует в нескольких наборах модулей, выпуск
              модуля и связанные с ним возможности (функции) и 
              отклонения должны быть идентичны.";
         }
       }
       list datastore {
         key "name";
         description
           "Хранилище, поддерживаемое сервером.

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

            Сервер ДОЛЖЕН создавать в этом списке одну запись для 
            каждого поддерживаемого хранилища. Всем хранилищам с
            одной схемой СЛЕДУЕТ ссылаться на эту схему.";
         leaf name {
           type ds:datastore-ref;
           description
             "Отождествление хранилища данных.";
         }
         leaf schema {
           type leafref {
             path "../../schema/name";
           }
           mandatory true;
           description
             "Ссылка на схему, поддерживаемую хранилищем. Все 
              не имортируемые модули схемы реализуются со связанными
              возможностями и отклонениями.";
         }
       }
     }

     /*
      * Контейнер верхнего уровня
      */

     container yang-library {
       config false;
       description
         "Контейнер, содержащий всю библиотеку YANG данного сервера.";
       uses yang-library-parameters;
       leaf content-id {
         type string;
         mandatory true;
         description
           "Созданный сервером идентификатор содержимого дерева
            /yang-library. Сервер ДОЛЖЕН менять значение этого листа, 
            если представленная в дереве /yang-library информация
            меняется (за исключением смены /yang-library/content-id).";
       }
     }

     /*
      * Уведомления
      */

     notification yang-library-update {
       description
         "Генерируется при любом изменении информации в библиотеке YANG
          на сервере.";
       leaf content-id {
         type leafref {
           path "/yanglib:yang-library/yanglib:content-id";
         }
         mandatory true;
         description
           "Включает идентификатор содержимого библиотеки YANG для
            обновленного варианта на момент создания уведомления.";
       }
     }

     /*
      * Унаследованные группировки
      */

     grouping module-list {
       status deprecated;
       description
         "Структура данных модуля представлена в форме группировки и
          может многократно применяться в конфигурации или другой
          структуре данных мониторинга.";

       grouping common-leafs {
         status deprecated;
         description
           "Общие параметры модулей и субмодулей YANG.";
         leaf name {
           type yang:yang-identifier;
           status deprecated;
           description
             "Имя модуля или субмодуля YANG.";
         }
         leaf revision {
           type union {
             type revision-identifier;
             type string {
               length "0";
             }
           }
           status deprecated;
           description
             "Дата выпуска модуля или субмодуля YANG. Если оператора
              revision нет в модулей или субмодуле, строка будет пустой.";
         }
       }

       grouping schema-leaf {
         status deprecated;
         description
           "Базовый параметр листа схему для модулей и субмодулей.";
         leaf schema {
           type inet:uri;
           description
             "Содержит идентификатор URL, представляющий ресурс схемы YANG
              для модуля или субмодуля.

              Этот лист присутствует лишь при наличии URL, доступного для
              извлечения схемы для данной записи.";
         }
       }
       list module {
         key "name revision";
         status deprecated;
         description
           "Каждая запись представляет один выпуск модуля, поддерживаемый
            в данный момент сервером.";
         uses common-leafs {
           status deprecated;
         }
         uses schema-leaf {
           status deprecated;
         }
         leaf namespace {
           type inet:uri;
           mandatory true;
           status deprecated;
           description
             "Идентификатор пространства имен XML для этого модуля.";
         }
         leaf-list feature {
           type yang:yang-identifier;
           status deprecated;
           description
             "Список имен свойств YANG из данного модуля, которые 
              поддерживаются сервером, независимо от их определения
              в модуле или любом из включенных субмодулей.";
         }
         list deviation {
           key "name revision";
           status deprecated;
           description
             "Список имен отклонений модулей YANG и выпусков, 
              используемых этим сервером для изменения соответствия
              модуля, связанного с этой записью. Отметим, что один
              и тот же модуль может использоваться для указания 
              отклонений множества модулей, поэтому запись МОЖЕТ
              появляться во множестве записей module.

              Модуль отклонений ДОЛЖЕН присутствовать в списке
              module с тем же именем и выпуском. Значением 
              conformance-type для модуля deviation будет implement.";
           uses common-leafs {
             status deprecated;
           }
         }
         leaf conformance-type {
           type enumeration {
             enum implement {
               description
                 "Показывает, что сервер реализует один или множество 
                  доступных протоколу объектов, определенных в модуле 
                  YANG, указанном этой записью. Это включает операторы 
                  deviation, определенные в модуле.

                  Для модулей YANG версии 1.1 имеется не более одной
                  записи с типом соответствия implement для конкретного
                  имени модуля, поскольку YANG 1.1 требует реализации
                  не более одного выпуска модуля.

                  Для модулей YANG версии 1 НЕ СЛЕДУЕТ включать более
                  одной записи module для конкретного имени модуля.";
             }
             enum import {
               description
                 "Показывает, что сервер импортирует повторно используемые
                  определения из указанного выпуска модуля, но не реализует
                  каких-либо доступных протоколу объектов из этого выпуска.

                  МОЖЕТ существовать множество записей module для одного 
                  имени модуля. Это может возникать в случаях импорта одного
                  модуля множеством других модулей с разными датами выпуска 
                  в операторах import.";
             }
           }
           mandatory true;
           status deprecated;
           description
             "Указывает тип соответствия, заявленного сервером для модуля 
              YANG, указанного этой записью.";
         }
         list submodule {
           key "name revision";
           status deprecated;
           description
             "Каждая запись представляет 1 субмодуль в родительском модуле.";
           uses common-leafs {
             status deprecated;
           }
           uses schema-leaf {
             status deprecated;
           }
         }
       }
     }

     /*
      * Унаследованные узлы данных рабочего состояния
      */

     container modules-state {
       config false;
       status deprecated;
       description
         "Содержит информацию мониторинга модуля YANG.";
       leaf module-set-id {
         type string;
         mandatory true;
         status deprecated;
         description
           "Содержит специфический для сервера идентификатор, который
            представляет текущий набор модулей и субмодулей. Сервер
            ДОЛЖЕН менять значение этого листа при изменении данных,
            представленных экземплярами списков module.";
       }
       uses module-list {
         status deprecated;
       }
     }

     /*
      * Унаследованные уведомления
      */

     notification yang-library-change {
       status deprecated;
       description
         "Генерируется при изменении набора модулей и субмодулей,
          поддерживаемых сервером.";
       leaf module-set-id {
         type leafref {
           path "/yanglib:modules-state/yanglib:module-set-id";
         }
         mandatory true;
         status deprecated;
         description
           "Содержит значение module-set-id, которое представляет
            набор модулей и субмодулей, которые сервер поддерживал в
            момент генерации уведомления.";
       }
     }
   }

   <CODE ENDS>

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

RFC 7895 ранее зарегистрировал один идентификатор URI в реестре IETF XML Registry [RFC3688]. Данный документ перенимает эту запись RFC 7895 и меняет значение Registrant Contact на IESG в соответствии с разделом 4 [RFC3688].

     URI: urn:ietf:params:xml:ns:yang:ietf-yang-library
     Registrant Contact: The IESG.
     XML: N/A, the requested URI is an XML namespace.

Данный документ регистрирует модуль YANG в реестре YANG Module Names [RFC6020]

     name:         ietf-yang-library
     namespace:    urn:ietf:params:xml:ns:yang:ietf-yang-library
     prefix:       yanglib
     reference:    RFC 8525

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

Модуль YANG, заданный в этом документе, определяет схему данных, предназначенных для доступа с использованием протоколов сетевого управления, таких как NETCONF [RFC6241] или RESTCONF [RFC8040]. Нижним уровнем NETCONF является защищенный транспорт с обязательной реализацией протокола SSH5 [RFC6242]. Нижним уровнем RESTCONF является HTTPS с обязательной реализацией защищенного транспорта TLS [RFC8446].

Модель NACM6 [RFC8341] обеспечивает способы ограничения доступа для конкретных пользователей NETCONF или RESTCONF предопределенным подмножеством протокольных операций NETCONF или RESTCONF и содержимого .

Некоторые из доступных для чтения узлов данных этого модуля YANG могут оказаться чувствительными или уязвимыми в отдельных сетевых средах. Поэтому важно ограничить возможность чтения (например, с помощью get, get-config или notification) таких данных. Ниже указаны деликатные/уязвимые субдеревья и узлы данных.

Субдерево /yang-library библиотеки YANG может помочь атакующему при определении возможностей сервера и известных ошибок реализации. Хотя часть такой информации доступна всем пользователям через сообщения NETCONF <hello> (или похожие сообщения других протоколов управления), этот модуль YANG может раскрывать дополнительные детали, способные помочь атакующему. Уязвимости сервера могут относиться к конкретным модулям, версиям возможностям или отклонениям. Эта информация включается в каждую запись module. Например, если конкретная операция с определенным узлом данных может приводить к аварии на сервере или значительно снижать его производительность, информация из списка модулей будет помогать атакующему обнаружить серверы с таким дефектом для организации атаки на службы.

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

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

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

[RFC6991] Schoenwaelder, J., Ed., «Common YANG Data Types», RFC 6991, DOI 10.17487/RFC6991, July 2013, <https://www.rfc-editor.org/info/rfc6991>.

[RFC7950] Bjorklund, M., Ed., «The YANG 1.1 Data Modeling Language», RFC 7950, DOI 10.17487/RFC7950, August 2016, <https://www.rfc-editor.org/info/rfc7950>.

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

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

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

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

[RFC5277] Chisholm, S. and H. Trevino, «NETCONF Event Notifications», RFC 5277, DOI 10.17487/RFC5277, July 2008, <https://www.rfc-editor.org/info/rfc5277>.

[RFC6470] Bierman, A., «Network Configuration Protocol (NETCONF) Base Notifications», RFC 6470, DOI 10.17487/RFC6470, February 2012, <https://www.rfc-editor.org/info/rfc6470>.

[RFC7895] Bierman, A., Bjorklund, M., and K. Watsen, «YANG Module Library», RFC 7895, DOI 10.17487/RFC7895, June 2016, <https://www.rfc-editor.org/info/rfc7895>.

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

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

[RFC8344] Bjorklund, M., «A YANG Data Model for IP Management», RFC 8344, DOI 10.17487/RFC8344, March 2018, <https://www.rfc-editor.org/info/rfc8344>.

[RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., Ananthakrishnan, H., and X. Liu, «A YANG Data Model for Network Topologies», RFC 8345, DOI 10.17487/RFC8345, March 2018, <https://www.rfc-editor.org/info/rfc8345>.

[RFC8348] Bierman, A., Bjorklund, M., Dong, J., and D. Romascanu, «A YANG Data Model for Hardware Management», RFC 8348, DOI 10.17487/RFC8348, March 2018, <https://www.rfc-editor.org/info/rfc8348>.

[RFC8349] Lhotka, L., Lindem, A., and Y. Qu, «A YANG Data Model for Routing Management (NMDA Version)», RFC 8349, DOI 10.17487/RFC8349, March 2018, <https://www.rfc-editor.org/info/rfc8349>.

[RFC8526] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., and R. Wilton, «NETCONF Extensions to Support the Network Management Datastore Architecture», RFC 8526, DOI 10.17487/RFC8526, March 2019, <https://www.rfc-editor.org/info/rfc8526>.

[RFC8528] Bjorklund, M. and L. Lhotka, «YANG Schema Mount», RFC 8528, DOI 10.17487/RFC8528, March 2019, <https://www.rfc-editor.org/info/rfc8528>.

Приложение A. Отличия от RFC 7895

Ниже перечислены изменения [RFC7895] внесенные этим документом.

  • Название YANG Module Library заменено на YANG Library.

  • Добавлен контейнер верхнего уровня /yang-library, включающий всю библиотеку YANG и обеспечивающий информацию о наборах модулей, схемах и хранилищах данных.

  • Контейнер /modules-state переработан в список /yang-library/module-set.

  • Добавлены списки /yang-library/schema и /yang-library/datastore.

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

  • Добавлено уведомление yang-library-update взамен устаревшего yang-library-change.

  • Отменено дерево /modules-state.

  • Отменена группировка /module-list.

  • Отменено уведомление /yang-library-change.

Приложение B. Экземпляр библиотеки YANG для базового сервера

Приведенный ниже пример показывает библиотеку YANG базового сервера, реализующего модули ietf-interfaces [RFC8343] и ietf-ip [RFC8344] в хранилищах <running>, <startup> и <operational>, а также модуль ietf-hardware [RFC8348] в хранилище <operational>.

Некоторые значения листьев разбиты на несколько строк из соображений форматирования.

   <yang-library
       xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-library"
       xmlns:ds="urn:ietf:params:xml:ns:yang:ietf-datastores">

     <module-set>
       <name>config-modules</name>
       <module>
         <name>ietf-interfaces</name>
         <revision>2018-02-20</revision>
         <namespace>
           urn:ietf:params:xml:ns:yang:ietf-interfaces
         </namespace>
       </module>
       <module>
         <name>ietf-ip</name>
         <revision>2018-02-22</revision>
         <namespace>
           urn:ietf:params:xml:ns:yang:ietf-ip
         </namespace>
       </module>
       <import-only-module>
         <name>ietf-yang-types</name>
         <revision>2013-07-15</revision>
         <namespace>
           urn:ietf:params:xml:ns:yang:ietf-yang-types
         </namespace>
       </import-only-module>
       <import-only-module>
         <name>ietf-inet-types</name>
         <revision>2013-07-15</revision>
         <namespace>
           urn:ietf:params:xml:ns:yang:ietf-inet-types
         </namespace>
       </import-only-module>
     </module-set>

     <module-set>
       <name>state-modules</name>
       <module>
         <name>ietf-hardware</name>
         <revision>2018-03-13</revision>
         <namespace>
           urn:ietf:params:xml:ns:yang:ietf-hardware
         </namespace>
       </module>
       <import-only-module>
         <name>ietf-inet-types</name>
         <revision>2013-07-15</revision>
         <namespace>
           urn:ietf:params:xml:ns:yang:ietf-inet-types
         </namespace>
       </import-only-module>
       <import-only-module>
         <name>ietf-yang-types</name>
         <revision>2013-07-15</revision>
         <namespace>
           urn:ietf:params:xml:ns:yang:ietf-yang-types
         </namespace>
       </import-only-module>
       <import-only-module>
         <name>iana-hardware</name>
         <revision>2018-03-13</revision>
         <namespace>
           urn:ietf:params:xml:ns:yang:iana-hardware
         </namespace>
       </import-only-module>
     </module-set>

     <schema>
       <name>config-schema</name>
       <module-set>config-modules</module-set>
     </schema>
     <schema>
       <name>state-schema</name>
       <module-set>config-modules</module-set>
       <module-set>state-modules</module-set>
     </schema>

     <datastore>
       <name>ds:startup</name>
       <schema>config-schema</schema>
     </datastore>
     <datastore>
       <name>ds:running</name>
       <schema>config-schema</schema>
     </datastore>
     <datastore>
       <name>ds:operational</name>
       <schema>state-schema</schema>
     </datastore>

     <content-id>75a43df9bd56b92aacc156a2958fbe12312fb285</content-id>
   </yang-library>

Приложение C. Экземпляр библиотеки YANG для расширенного сервера

Приведенный ниже пример расширяет библиотеку из приложения B за счет использования модулей из [RFC8345] и [RFC8349] для иллюстрации сервера с перечисленными ниже дополнительными возможностями.

  • Имеется модуль с возможностями, поддерживаемыми лишь в хранилище <operational>. Модуль ietf-routing поддерживается в <running>, <startup> и <operational>, а модули multiple-ribs и router-id разрешены лишь в <operational>. Поэтому лист router-id доступен для чтения, но не может быть изменен.

  • Поддерживается динамическое хранилище конфигурации example-ds-ephemeral с модулями ietf-network и ietf-network-topology, настраиваемыми с помощью условного протокола динамического управления конфигурацией.

  • Показан пример связанных с хранилищем отклонений. Модуль example-vendor-hardware-deviations включен в схему для хранилища <operational> с целью удаления узлов данных, которые сервер не может поддерживать.

  • Показано применение наборов модулей (module-set) для совместной организации связанных модулей.

Некоторые значения листьев разбиты на несколько строк из соображений форматирования.

   <yang-library
       xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-library"
       xmlns:ds="urn:ietf:params:xml:ns:yang:ietf-datastores"
       xmlns:ex-ds-eph="urn:example:ds-ephemeral">

     <module-set>
       <name>config-state-modules</name>
       <module>
         <name>ietf-interfaces</name>
         <revision>2018-02-20</revision>
         <namespace>
           urn:ietf:params:xml:ns:yang:ietf-interfaces
         </namespace>
       </module>
       <module>
         <name>ietf-ip</name>
         <revision>2018-02-22</revision>
         <namespace>
           urn:ietf:params:xml:ns:yang:ietf-ip
         </namespace>
       </module>
       <module>
         <name>ietf-routing</name>
         <revision>2018-03-13</revision>
         <namespace>
           urn:ietf:params:xml:ns:yang:ietf-routing
         </namespace>
       </module>
       <import-only-module>
         <name>ietf-yang-types</name>
         <revision>2013-07-15</revision>
         <namespace>
           urn:ietf:params:xml:ns:yang:ietf-yang-types
         </namespace>
       </import-only-module>
       <import-only-module>
         <name>ietf-inet-types</name>
         <revision>2013-07-15</revision>
         <namespace>
           urn:ietf:params:xml:ns:yang:ietf-inet-types
         </namespace>
       </import-only-module>
     </module-set>

     <module-set>
       <name>config-only-modules</name>
       <module>
         <name>ietf-routing</name>
         <revision>2018-03-13</revision>
         <namespace>
           urn:ietf:params:xml:ns:yang:ietf-routing
         </namespace>
       </module>
     </module-set>

     <module-set>
       <name>dynamic-config-state-modules</name>
       <module>
         <name>ietf-network</name>
         <revision>2018-02-26</revision>
         <namespace>
           urn:ietf:params:xml:ns:yang:ietf-network
         </namespace>
       </module>
       <module>
         <name>ietf-network-topology</name>
         <revision>2018-02-26</revision>
         <namespace>
           urn:ietf:params:xml:ns:yang:ietf-network-topology
         </namespace>
       </module>
       <import-only-module>
         <name>ietf-inet-types</name>
         <revision>2013-07-15</revision>
         <namespace>
           urn:ietf:params:xml:ns:yang:ietf-inet-types
         </namespace>
       </import-only-module>
     </module-set>

     <module-set>
       <name>state-only-modules</name>
       <module>
         <name>ietf-hardware</name>
         <revision>2018-03-13</revision>
         <namespace>
           urn:ietf:params:xml:ns:yang:ietf-hardware
         </namespace>
         <deviation>example-vendor-hardware-deviations</deviation>
       </module>
       <module>
         <name>ietf-routing</name>
         <revision>2018-03-13</revision>
         <namespace>
           urn:ietf:params:xml:ns:yang:ietf-routing
         </namespace>
         <feature>multiple-ribs</feature>
         <feature>router-id</feature>
       </module>
       <module>
         <name>example-vendor-hardware-deviations</name>
         <revision>2018-01-31</revision>
         <namespace>
           urn:example:example-vendor-hardware-deviations
         </namespace>
       </module>
       <import-only-module>
         <name>ietf-inet-types</name>
         <revision>2013-07-15</revision>
         <namespace>
           urn:ietf:params:xml:ns:yang:ietf-inet-types
         </namespace>
       </import-only-module>
       <import-only-module>
         <name>ietf-yang-types</name>
         <revision>2013-07-15</revision>
         <namespace>
           urn:ietf:params:xml:ns:yang:ietf-yang-types
         </namespace>
       </import-only-module>
       <import-only-module>
         <name>iana-hardware</name>
         <revision>2018-03-13</revision>
         <namespace>
           urn:ietf:params:xml:ns:yang:iana-hardware
         </namespace>
       </import-only-module>
     </module-set>

     <schema>
       <name>config-schema</name>
       <module-set>config-state-modules</module-set>
       <module-set>config-only-modules</module-set>
     </schema>
     <schema>
       <name>dynamic-config-schema</name>
       <module-set>dynamic-config-state-modules</module-set>
     </schema>
     <schema>
       <name>state-schema</name>
       <module-set>config-state-modules</module-set>
       <module-set>dynamic-config-state-modules</module-set>
       <module-set>state-only-modules</module-set>
     </schema>

     <datastore>
       <name>ds:startup</name>
       <schema>config-schema</schema>
     </datastore>
     <datastore>
       <name>ds:running</name>
       <schema>config-schema</schema>
     </datastore>
     <datastore>
       <name>ex-ds-eph:ds-ephemeral</name>
       <schema>dynamic-config-schema</schema>
     </datastore>
     <datastore>
       <name>ds:operational</name>
       <schema>state-schema</schema>
     </datastore>

     <content-id>14782ab9bd56b92aacc156a2958fbe12312fb285</content-id>
   </yang-library>

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

Andy Bierman

YumaWorks

Email: andy@yumaworks.com

Martin Bjorklund

Tail-f Systems

Email: mbj@tail-f.com

Juergen Schoenwaelder

Jacobs University

Email: j.schoenwaelder@jacobs-university.de

Kent Watsen

Watsen Networks

Email: kent+ietf@watsen.net

Robert Wilton

Cisco Systems

Email: rwilton@cisco.com


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

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

nmalykh@protocols.ru

1Network Management Datastore Architecture — архитектура хранилища данных сетевого управления.

2Internet Engineering Task Force.

3Internet Engineering Steering Group.

4Network Configuration Protocol — протокол настройки конфигурации сети.

5Secure Shell — защищенная оболочка.

6Network Configuration Access Control Model — модель управления доступом к конфигурации.




RFC 8469 Recommendation to Use the Ethernet Control Word

Internet Engineering Task Force (IETF)                         S. Bryant
Request for Comments: 8469                                      A. Malis
Updates: 4448                                                     Huawei
Category: Standards Track                                    I. Bagdonas
ISSN: 2070-1721                                                  Equinix
                                                           November 2018

Recommendation to Use the Ethernet Control Word

Рекомендации по использованию управляющего слова Ethernet

PDF

Тезисы

Для псевдопроводной (PW1) инкапсуляции Ethernet в RFC 4448 указано, что использование управляющего слова (CW2) не обязательно. В отсутствие CW пакет Ethernet PW может быть ошибочно принят маршрутизатором LSR3 за пакет IP. Это может привести к ошибочному выбору пути для пакета среди ECMP4 а в результате может нарушиться порядок пакетов. Эта проблема стала более серьезной в результате развертывания оборудования с адресами Ethernet MAC5, начинающимися с 0x4 или 0x6. Использование Ethernet PW CW решает эту проблему. Данный документ рекомендует использовать Ethernet PW CW при любых необычных обстоятельствах.

Этот документ обновляет RFC 4448.

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

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

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

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

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

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

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

Оглавление

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

1. Введение

Спецификация псевдопроводной инкапсуляции Ethernet [RFC4448] указывает, что использование управляющего слова CW не обязательно. Маршрутизаторы LSR обычно выполняют поиск после стека меток для определения присутствиея пакета IP в поле данных и, при его обнаружении, выбора следующего интервала (next hop) на основании «пятерки» (five-tuple) — IP-адреса отправителя и получателя, protocol/next-header, номера транспортных портов отправителя и получателя. В отсутствие PW CW пакет Ethernet PW может быть ошибочно принят за пакетом IP маршрутизатором LSR, выбирающим путь ECMP на основе five-tuple. Это может приводить к выбору ошибочного пути ECMP и, в результате, к нарушению порядка доставки пакетов. Дополнительное рассмотрение этой проблемы дано в [RFC4928].

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

Пакеты IPv4 и IPv6 начинаются со значений 0x4 и 0x6, соответственно. Может происходить ошибочная идентификация пакета, если пакет Ethernet PW без CW содержит кадр Ethernet с адресом получателя, начинающимся с указанных значений.

По ряду причин эта проблема недавно стала серьезной. Во-первых, Регистрационный комитет IEEE (RAC8) выделил адреса Ethernet MAC, начинающиеся с 0x4 и 0x6, а оборудование с такими MAC-адресами появилось в сетях. Во-вторых, озабоченность вопросами приватности привела к использованию случайных MAC-адресов, назначаемых локально. При случайном назначении адреса, начинающиеся с указанных значений будут составлять приблизительно 1/8 часть всех выделяемых адресов.

Использование Ethernet PW CW решает эту проблему.

Данный документ рекомендует использовать Ethernet PW CW при любых необычных обстоятельствах.

2. Уровни требований

Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не нужно (SHALL NOT), следует (SHOULD), не следует (SHOULD NOT), рекомендуется (RECOMMENDED), не рекомендуется (NOT RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе должны интерпретироваться в соответствии с BCP 14 [RFC2119] [RFC8174] тогда и только тогда, когда они набраны заглавными буквами, как показано здесь.

3. Обоснование

Инкапсуляция Ethernet PW определена в [RFC4448]. Особое значение имеет параграф 4.6, часть которого для удобства читателя приведена ниже. Отметим, что RFC 4448 цитирует [PWE3-CW] для ссылки на [RFC4385] и [VCCV] для ссылки на документ, который в конечном итоге опубликован как [RFC5085].

Управляющее слово, определенное в этом параграфе, основано на Generic PW MPLS Control Word из [PWE3-CW]. Оно обеспечивает возможность упорядочить отдельные кадры в PW, а также избежать распределения пакетов между равноценными путями (ECMP) [RFC2992] и применения механизмов OAM9, включая VCCV [VCCV].

В [PWE3-CW] сказано «Если PW реагирует на нарушение порядка пакетов и передается через MPLS PSN с использованием содержимого данных MPLS (payload) для выбора пути ECMP, псевдопровод может реализовать механизм предотвращения нарушений порядка пакетов». Это требуется для того, чтобы реализации ECMP могли проверить первый полубайт после стека меток MPLS для определения принадлежности пакета к протоколу IP. Если MAC-адрес отправителя в кадре Ethernet, передаваемом через PW без управляющего слова, начинается с 0x4 или 0x6, он будет ошибочно сочтен пакетом IPv4 или IPv6. В зависимости от конфигурации и топологии сети MPLS это может приводить к ситуации, где пакеты данного PW будут передаваться по разным путям. В результате может возрасти число кадров с нарушением порядка доставки в данном PW или пакеты OAM пойдут по пути, отличающемуся от пути обычного трафика (см. параграф 4.4.3 Порядок кадров).

Функции, предоставляемые управляющим словом, могут не требоваться для данного Ethernet PW. Например, ECMP может не быть или не использоваться в данной сети MPLS, соблюдение порядка кадров может не требоваться и пр. В таких случаях роль слова управления невелика и оно может не использоваться. Ранние реализации Ethernet PW развертывались без CW и возможности обрабатывать слово управления при его наличии. Для совместимости со старыми версиями будущие реализации должны быть способны передавать и принимать кадры без CW.

В начале развертывания PW часть коммерчески значимого оборудования была не способна обрабатывать Ethernet CW. Кроме того, в те времена предполагалось, что адреса Ethernet MAC, начинающиеся с 0x4 или 0x6, не будут назначаться IEEE RAC и можно реализовать Ethernet PW без поддержки CW.

С течением времени адреса Ethernet MAC, начинающиеся с 0x4 и 0x6, были выделены RAC. Поэтому допущение о том, что в реальных сетях не будет возникать путаницы между пакетами Ethernet PW без CW и пакетами IP, перестало соответствовать реалиям.

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

Проблема была обозначения в почтовой конференции NANOG, доступной по ссылке https://mailman.nanog.org/pipermail/nanog/2016-December/089395.html.

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

Неоднозначность идентификации в данных MPLS пакетов Ethernet PW и IP устраняется при использовании Ethernet PW CW. Этот документ обновляет [RFC4448] в том смысле, что входным и выходным граничным устройствам провайдера (PE10) следует поддерживать Ethernet PW CW и при наличии этой поддержки CW должно применяться.

Там, где требуется применение ECMP для трафика Ethernet PW, а входные и выходные устройства PE поддерживают ELI/EL11 [RFC6790] и FAT PW12 [RFC6391], может применяться любой метод. Использование обоих методов на одном PW обычно не требуется и его следует избегать, если позволяют обстоятельства. В случае многосегментных PW при использовании ELI/EL его следует применять на каждом сегменте PW. Метод обеспечения использования ELI/EL на каждом сегменте выходит за рамки этого документа.

5. Равноценные пути (ECMP)

Там, где объем трафика Ethernet PW требует применения ECMP, может использоваться один из двух методов:

  • FAT PW через сеть MPLS PSN13, как описано в [RFC6391];

  • метки энтропии LSP14, как описано в [RFC6790].

RFC 6391 работает на основе повышения энтропии нижней метки стека. Поддержка этой функции требуется на входных и выходных PE. Также требуется, чтобы достаточное число LSR на пути LSP между входным и выходным PE было способно выбирать путь ECMP для пакета MPLS с достаточной глубиной стека.

RFC 6790 работает на основе включения энтропии в путь LSP-часть стека меток. Это требует от входного и выходного PE поддержки вставки и удаления EL и ELI, а также достаточного числа LSR на пути LSP, способных выбирать путь ECMP на основе EL.

В обоих случаях требуется обеспечить прохождение пакетов OAM и пакетов данных по одному пути. Этот вопрос подробно рассмотрен в разделе 7 [RFC6391] и разделе 6 [RFC6790]. Однако в обоих случаях ситуация улучшается по сравнению с поведением ECMP без использования Ethernet PW CW, когда нет возможности обеспечить прохождение пакетов PW OAM по одному пути с пакетами данных PW, для которых ECMP выбирается на основе five-tuple данных IP.

Метка PW вталкивается перед меткой LSP. Поскольку метки ELI/EL являются частью уровня LSP, а не уровня PW, они вталкиваются после метки PW.

6. Пути смягчения проблемы

Когда нет возможности использовать Ethernet PW CW, влияние ECMP может быть предотвращено путем передачи PW по пути с организацией трафика, который не использует поле данных (payload) для распределения нагрузки (например, RSVP-TE [RFC3209]). Однако на таких путях может применяться распределение нагрузки через связки каналов (link-bundle) и, естественно, весь трафик PW должен передаваться через один LSP.

7. Эксплуатационные вопросы

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

Вместо указания типа данных в пакетах MPLS использует уровень управления для сигнализации о типе данных, который следуют за нижней меткой стека. Некоторые LSR пытаются определить типа пакета путем проверки данных MPLS и в ряде случаев просматривают данные дальше PW CW. Если данные представляются пакетом IP или IP указан в заголовке Ethernet, они выполняют расчет ECMP на основе данных, сочтенных полями five-tuple. Однако такое определение типа данных не дает точного результата и при ошибочной идентификации пакета как IP может нарушаться порядок доставки пакетов. Нарушение порядка в этом случае оператору трудно обнаружить. При включении функции, позволяющей использовать информацию из пакета, расположенную после PW CW, при расчете ECMP, оператору следует принимать во внимание возможность нарушения порядка доставки кадров Ethernet, несмотря на присутствие CW.

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

В этом документе отдано предпочтение одной широко распространенной инкапсуляции Ethernet PW над другой. С этим методом связаны вопросы безопасности, рассмотренные в [RFC4448]. Документ не создает других проблем безопасности.

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

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

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

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

[RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, «Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS PSN», RFC 4385, DOI 10.17487/RFC4385, February 2006, <https://www.rfc-editor.org/info/rfc4385>.

[RFC4448] Martini, L., Ed., Rosen, E., El-Aawar, N., and G. Heron, «Encapsulation Methods for Transport of Ethernet over MPLS Networks», RFC 4448, DOI 10.17487/RFC4448, April 2006, <https://www.rfc-editor.org/info/rfc4448>.

[RFC4928] Swallow, G., Bryant, S., and L. Andersson, «Avoiding Equal Cost Multipath Treatment in MPLS Networks», BCP 128, RFC 4928, DOI 10.17487/RFC4928, June 2007, <https://www.rfc-editor.org/info/rfc4928>.

[RFC6391] Bryant, S., Ed., Filsfils, C., Drafz, U., Kompella, V., Regan, J., and S. Amante, «Flow-Aware Transport of Pseudowires over an MPLS Packet Switched Network», RFC 6391, DOI 10.17487/RFC6391, November 2011, <https://www.rfc-editor.org/info/rfc6391>.

[RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and L. Yong, «The Use of Entropy Labels in MPLS Forwarding», RFC 6790, DOI 10.17487/RFC6790, November 2012, <https://www.rfc-editor.org/info/rfc6790>.

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

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

[RFC2992] Hopps, C., «Analysis of an Equal-Cost Multi-Path Algorithm», RFC 2992, DOI 10.17487/RFC2992, November 2000, <https://www.rfc-editor.org/info/rfc2992>.

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

[RFC5085] Nadeau, T., Ed. and C. Pignataro, Ed., «Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires», RFC 5085, DOI 10.17487/RFC5085, December 2007, <https://www.rfc-editor.org/info/rfc5085>.

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

Авторы благодарят Job Snijders за привлечение внимания к проблеме. Спасибо Pat Thaler за разъяснение вопроса о локальном назначении MAC-адресов и Sasha Vainshtein за ценные разъяснения и замечания.

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

Stewart Bryant

Huawei

Email: stewart.bryant@gmail.com

Andrew G. Malis

Huawei

Email: agmalis@gmail.com

Ignas Bagdonas

Equinix

Email: ibagdona.ietf@gmail.com>


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

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

nmalykh@gmail.com

1Pseudowire.

2Control word.

3Label switching router — маршрутизатор с коммутацией по меткам.

4Equal-cost multipath — множество равноценных путей.

5Media Access Control — управление доступом к среде.

6Internet Engineering Task Force.

7Internet Engineering Steering Group.

8Registration Authority Committee.

9Operations, Administration, and Maintenance — операции, администрирование и поддержка.

10Provider edge.

11Entropy Label Indicator/Entropy Label — индикатор метки энтропии/метка энтропии.

12Flow-Aware Transport of Pseudowire — осведомленный о потоках транспорт псевдопровода.

13Packet Switched Network — сеть с коммутацией пакетов.

14Label Switched Path — путь с коммутацией по меткам.




RFC 8466 (часть 2)

Часть 1

8. Модуль YANG

Этот модуль YANG импортирует определения типов (typedef) из [RFC6991] и [RFC8341].

<CODE BEGINS> file "ietf-l2vpn-svc@2018-10-09.yang"
module ietf-l2vpn-svc {
  yang-version 1.1;
  namespace "urn:ietf:params:xml:ns:yang:ietf-l2vpn-svc";
  prefix l2vpn-svc;

  import ietf-inet-types {
    prefix inet;
  }
  import ietf-yang-types {
    prefix yang;
  }
  import ietf-netconf-acm {
    prefix nacm;
  }

  organization
    "IETF L2SM Working Group.";
  contact
    "WG Web:   <https://datatracker.ietf.org/wg/l2sm/> 
     WG List:  <mailto:l2sm@ietf.org> 
     Editor:   Giuseppe Fioccola
               <mailto:giuseppe.fioccola@tim.it>"; 
  description
    "This YANG module defines a generic service configuration model
     for Layer 2 VPN services common across all vendor
     implementations.

     Copyright (c) 2018 IETF Trust and the persons
     identified as authors of the code.  All rights reserved.

     Redistribution and use in source and binary forms, with or
     without modification, is permitted pursuant to, and subject
     to the license terms contained in, the Simplified BSD License
     set forth in Section 4.c of the IETF Trust's Legal Provisions
     Relating to IETF Documents
     (https://trustee.ietf.org/license-info). 

     This version of this YANG module is part of RFC 8466;
     see the RFC itself for full legal notices.";

  revision 2018-10-09 {
    description
      "Initial revision.";
    reference
      "RFC 8466: A YANG Data Model for Layer 2 Virtual Private
       Network (L2VPN) Service Delivery";
  }

  feature carrierscarrier {
    description
      "Enables the support of carriers' carriers (CsC).";
  }

  feature ethernet-oam {
    description
      "Enables the support of Ethernet Service OAM.";
  }

  feature extranet-vpn {
    description
      "Enables the support of extranet VPNs.";
  }

  feature l2cp-control {
    description
      "Enables the support of L2CP control.";
  }

  feature input-bw {
    description
      "Enables the support of input bandwidth in a VPN.";
  }

  feature output-bw {
    description
      "Enables the support of output bandwidth in a VPN.";
  }

  feature uni-list {
    description
      "Enables the support of a list of UNIs in a VPN.";
  }

  feature cloud-access {
    description
      "Allows the VPN to connect to a Cloud Service Provider (CSP)
       or an ISP.";
  }

  feature oam-3ah {
    description
      "Enables the support of OAM 802.3ah.";
  }

  feature micro-bfd {
    description
      "Enables the support of micro-BFD.";
  }

  feature bfd {
    description
      "Enables the support of BFD.";
  }

  feature signaling-options {
    description
      "Enables the support of signaling options.";
  }

  feature site-diversity {
    description
      "Enables the support of site diversity constraints in a VPN.";
  }

  feature encryption {
    description
      "Enables the support of encryption.";
  }

  feature always-on {
    description
      "Enables support for the 'always-on' access constraint.";
  }

  feature requested-type {
    description
      "Enables support for the 'requested-type' access constraint.";
  }

  feature bearer-reference {
    description
      "Enables support for the 'bearer-reference' access
       constraint.";
  }

  feature qos {
    description
      "Enables support for QoS.";
  }

  feature qos-custom {
    description
      "Enables the support of a custom QoS profile.";
  }

  feature lag-interface {
    description
      "Enables LAG interfaces.";
  }

  feature vlan {
    description
      "Enables the support of VLANs.";
  }

  feature dot1q {
    description
      "Enables the support of dot1Q.";
  }

  feature qinq {
    description
      "Enables the support of QinQ.";
  }

  feature qinany {
    description
      "Enables the support of QinAny.";
  }

  feature vxlan {
    description
      "Enables the support of VXLANs.";
  }

  feature lan-tag {
    description
      "Enables LAN tag support in a VPN.";
  }

  feature target-sites {
    description
      "Enables the support of the 'target-sites'
       match-flow parameter.";
  }

  feature bum {
    description
      "Enables BUM capabilities in a VPN.";
  }

  feature mac-loop-prevention {
    description
      "Enables the MAC loop-prevention capability in a VPN.";
  }

  feature lacp {
    description
      "Enables the Link Aggregation Control Protocol (LACP)
       capability in a VPN.";
  }

  feature mac-addr-limit {
    description
      "Enables the MAC address limit capability in a VPN.";
  }

  feature acl {
    description
      "Enables the ACL capability in a VPN.";
  }

  feature cfm {
    description
      "Enables the 802.1ag CFM capability in a VPN.";
  }

  feature y-1731 {
    description
      "Enables the Y.1731 capability in a VPN.";
  }

  typedef svc-id {
    type string;
    description
      "Defines the type of service component identifier.";
  }

  typedef ccm-priority-type {
    type uint8 {
      range "0..7";
    }
    description
      "A 3-bit priority value to be used in the VLAN tag,
       if present in the transmitted frame.";
  }

  typedef control-mode {
    type enumeration {
      enum peer {
        description
          "'peer' mode, i.e., participate in the protocol towards
           the CE.  Peering is common for LACP and the Ethernet
           Local Management Interface (E-LMI) and, occasionally,
           for LLDP.  For VPLSs and VPWSs, the subscriber can also
           request that the SP peer enable spanning tree.";
      }
      enum tunnel {
        description
          "'tunnel' mode, i.e., pass to the egress or destination
           site.  For EPLs, the expectation is that L2CP frames are
           tunneled.";
      }
      enum discard {
        description
          "'discard' mode, i.e., discard the frame.";
      }
    }
    description
      "Defines the type of control mode on L2CP protocols.";
  }

  typedef neg-mode {
    type enumeration {
      enum full-duplex {
        description
          "Defines full-duplex mode.";
      }
      enum auto-neg {
        description
          "Defines auto-negotiation mode.";
      }
    }
    description
      "Defines the type of negotiation mode.";
  }

  identity site-network-access-type {
    description
      "Base identity for the site-network-access type.";
  }

  identity point-to-point {
    base site-network-access-type;
    description
      "Identity for a point-to-point connection.";
  }

  identity multipoint {
    base site-network-access-type;
    description
      "Identity for a multipoint connection, e.g.,
       an Ethernet broadcast segment.";
  }

  identity tag-type {
    description
      "Base identity from which all tag types are derived.";
  }

  identity c-vlan {
    base tag-type;
    description
      "A CVLAN tag, normally using the 0x8100 Ethertype.";
  }

  identity s-vlan {
    base tag-type;
    description
      "An SVLAN tag.";
  }

  identity c-s-vlan {
    base tag-type;
    description
      "Using both a CVLAN tag and an SVLAN tag.";
  }

  identity multicast-tree-type {
    description
      "Base identity for the multicast tree type.";
  }

  identity ssm-tree-type {
    base multicast-tree-type;
    description
      "Identity for the Source-Specific Multicast (SSM) tree type.";
    reference "RFC 8299: YANG Data Model for L3VPN Service Delivery";
  }

  identity asm-tree-type {
    base multicast-tree-type;
    description
      "Identity for the Any-Source Multicast (ASM) tree type.";
    reference "RFC 8299: YANG Data Model for L3VPN Service Delivery";
  }

  identity bidir-tree-type {
    base multicast-tree-type;
    description
      "Identity for the bidirectional tree type.";
    reference "RFC 8299: YANG Data Model for L3VPN Service Delivery";
  }

  identity multicast-gp-address-mapping {
    description
      "Identity for mapping type.";
  }

  identity static-mapping {
    base multicast-gp-address-mapping;
    description
      "Identity for static mapping, i.e., attach the interface
       to the multicast group as a static member.";
  }

  identity dynamic-mapping {
    base multicast-gp-address-mapping;
    description
      "Identity for dynamic mapping, i.e., an interface was added
       to the multicast group as a result of snooping.";
  }

  identity tf-type {
    description
      "Identity for the traffic type.";
  }

  identity multicast-traffic {
    base tf-type;
    description
      "Identity for multicast traffic.";
  }

  identity broadcast-traffic {
    base tf-type;
    description
      "Identity for broadcast traffic.";
  }

  identity unknown-unicast-traffic {
    base tf-type;
    description
      "Identity for unknown unicast traffic.";
  }

  identity encapsulation-type {
    description
      "Identity for the encapsulation type.";
  }

  identity ethernet {
    base encapsulation-type;
    description
      "Identity for Ethernet type.";
  }

  identity vlan {
    base encapsulation-type;
    description
      "Identity for the VLAN type.";
  }

  identity carrierscarrier-type {
    description
      "Identity of the CsC type.";
  }

  identity ldp {
    base carrierscarrier-type;
    description
      "Use LDP as the signaling protocol
       between the PE and the CE.";
  }

  identity bgp {
    base carrierscarrier-type;
    description
      "Use BGP (as per RFC 8277) as the signaling protocol
       between the PE and the CE.
       In this case, BGP must also be configured as
       the routing protocol.";
  }

  identity eth-inf-type {
    description
      "Identity of the Ethernet interface type.";
  }

  identity tagged {
    base eth-inf-type;
    description
      "Identity of the tagged interface type.";
  }

  identity untagged {
    base eth-inf-type;
    description
      "Identity of the untagged interface type.";
  }

  identity lag {
    base eth-inf-type;
    description
      "Identity of the LAG interface type.";
  }

  identity bw-type {
    description
      "Identity of the bandwidth type.";
  }

  identity bw-per-cos {
    base bw-type;
    description
      "Bandwidth is per CoS.";
  }

  identity bw-per-port {
    base bw-type;
    description
      "Bandwidth is per site network access.";
  }

  identity bw-per-site {
    base bw-type;
    description
      "Bandwidth is per site.  It is applicable to
       all the site network accesses within the site.";
  }

  identity bw-per-svc {
    base bw-type;
    description
      "Bandwidth is per VPN service.";
  }

  identity site-vpn-flavor {
    description
      "Base identity for the site VPN service flavor.";
  }

  identity site-vpn-flavor-single {
    base site-vpn-flavor;
    description
      "Identity for the site VPN service flavor.
       Used when the site belongs to only one VPN.";
  }

  identity site-vpn-flavor-multi {
    base site-vpn-flavor;
    description
      "Identity for the site VPN service flavor.
       Used when a logical connection of a site
       belongs to multiple VPNs.";
  }

  identity site-vpn-flavor-nni {
    base site-vpn-flavor;
    description
      "Identity for the site VPN service flavor.
       Used to describe an NNI option A connection.";
  }

  identity service-type {
    description
      "Base identity of the service type.";
  }

  identity vpws {
    base service-type;
    description
      "Point-to-point Virtual Private Wire Service (VPWS)
       service type.";
  }

  identity pwe3 {
    base service-type;
    description
      "Pseudowire Emulation Edge to Edge (PWE3) service type.";
  }

  identity ldp-l2tp-vpls {
    base service-type;
    description
      "LDP-based or L2TP-based multipoint Virtual Private LAN
       Service (VPLS) service type.  This VPLS uses LDP-signaled
       Pseudowires or L2TP-signaled Pseudowires.";
  }

  identity bgp-vpls {
    base service-type;
    description
      "BGP-based multipoint VPLS service type.  This VPLS uses a
       BGP control plane as described in RFCs 4761 and 6624.";
  }

  identity vpws-evpn {
    base service-type;
    description
      "VPWS service type using Ethernet VPNs (EVPNs)
       as specified in RFC 7432.";
  }

  identity pbb-evpn {
    base service-type;
    description
      "Provider Backbone Bridge (PBB) service type using
       EVPNs as specified in RFC 7432.";
  }

  identity bundling-type {
    description
      "The base identity for the bundling type.  It supports
       multiple CE-VLANs associated with an L2VPN service or
       all CE-VLANs associated with an L2VPN service.";
  }

  identity multi-svc-bundling {
    base bundling-type;
    description
      "Identity for multi-service bundling, i.e.,
       multiple CE-VLAN IDs can be associated with an
       L2VPN service at a site.";
  }

  identity one2one-bundling {
    base bundling-type;
    description
      "Identity for one-to-one service bundling, i.e.,
       each L2VPN can be associated with only one CE-VLAN ID
       at a site.";
  }

  identity all2one-bundling {
    base bundling-type;
    description
      "Identity for all-to-one bundling, i.e., all CE-VLAN IDs
       are mapped to one L2VPN service.";
  }

  identity color-id {
    description
      "Base identity of the color ID.";
  }

  identity color-id-cvlan {
    base color-id;
    description
      "Identity of the color ID based on a CVLAN.";
  }

  identity cos-id {
    description
      "Identity of the CoS ID.";
  }

  identity cos-id-pcp {
    base cos-id;
    description
      "Identity of the CoS ID based on the
       Port Control Protocol (PCP).";
  }

  identity cos-id-dscp {
    base cos-id;
    description
      "Identity of the CoS ID based on DSCP.";
  }

  identity color-type {
    description
      "Identity of color types.";
  }

  identity green {
    base color-type;
    description
      "Identity of the 'green' color type.";
  }

  identity yellow {
    base color-type;
    description
      "Identity of the 'yellow' color type.";
  }

  identity red {
    base color-type;
    description
      "Identity of the 'red' color type.";
  }

  identity policing {
    description
      "Identity of the type of policing applied.";
  }

  identity one-rate-two-color {
    base policing;
    description
      "Identity of one-rate, two-color (1R2C).";
  }

  identity two-rate-three-color {
    base policing;
    description
      "Identity of two-rate, three-color (2R3C).";
  }

  identity bum-type {
    description
      "Identity of the BUM type.";
  }

  identity broadcast {
    base bum-type;
    description
      "Identity of broadcast.";
  }

  identity unicast {
    base bum-type;
    description
      "Identity of unicast.";
  }

  identity multicast {
    base bum-type;
    description
      "Identity of multicast.";
  }

  identity loop-prevention-type {
    description
      "Identity of loop prevention.";
  }

  identity shut {
    base loop-prevention-type;
    description
      "Identity of shut protection.";
  }

  identity trap {
    base loop-prevention-type;
    description
      "Identity of trap protection.";
  }

  identity lacp-state {
    description
      "Identity of the LACP state.";
  }

  identity lacp-on {
    base lacp-state;
    description
      "Identity of LACP on.";
  }

  identity lacp-off {
    base lacp-state;
    description
      "Identity of LACP off.";
  }

  identity lacp-mode {
    description
      "Identity of the LACP mode.";
  }

  identity lacp-passive {
    base lacp-mode;
    description
      "Identity of LACP passive.";
  }

  identity lacp-active {
    base lacp-mode;
    description
      "Identity of LACP active.";
  }

  identity lacp-speed {
    description
      "Identity of the LACP speed.";
  }

  identity lacp-fast {
    base lacp-speed;
    description
      "Identity of LACP fast.";
  }

  identity lacp-slow {
    base lacp-speed;
    description
      "Identity of LACP slow.";
  }

  identity bw-direction {
    description
      "Identity for the bandwidth direction.";
  }

  identity input-bw {
    base bw-direction;
    description
      "Identity for the input bandwidth.";
  }

  identity output-bw {
    base bw-direction;
    description
      "Identity for the output bandwidth.";
  }

  identity management {
    description
      "Base identity for the site management scheme.";
  }

  identity co-managed {
    base management;
    description
      "Identity for a co-managed site.";
  }

  identity customer-managed {
    base management;
    description
      "Identity for a customer-managed site.";
  }

  identity provider-managed {
    base management;
    description
      "Identity for a provider-managed site.";
  }

  identity address-family {
    description
      "Identity for an address family.";
  }

  identity ipv4 {
    base address-family;
    description
      "Identity for an IPv4 address family.";
  }

  identity ipv6 {
    base address-family;
    description
      "Identity for an IPv6 address family.";
  }

  identity vpn-topology {
    description
      "Base identity for the VPN topology.";
  }

  identity any-to-any {
    base vpn-topology;
    description
      "Identity for the any-to-any VPN topology.";
  }

  identity hub-spoke {
    base vpn-topology;
    description
      "Identity for the Hub-and-Spoke VPN topology.";
  }

  identity hub-spoke-disjoint {
    base vpn-topology;
    description
      "Identity for the Hub-and-Spoke VPN topology,
       where Hubs cannot communicate with each other.";
  }

  identity site-role {
    description
      "Base identity for a site type.";
  }

  identity any-to-any-role {
    base site-role;
    description
      "Site in an any-to-any L2VPN.";
  }

  identity spoke-role {
    base site-role;
    description
      "Spoke site in a Hub-and-Spoke L2VPN.";
  }

  identity hub-role {
    base site-role;
    description
      "Hub site in a Hub-and-Spoke L2VPN.";
  }

  identity pm-type {
    description
      "Performance-monitoring type.";
  }

  identity loss {
    base pm-type;
    description
      "Loss measurement.";
  }

  identity delay {
    base pm-type;
    description
      "Delay measurement.";
  }

  identity fault-alarm-defect-type {
    description
      "Indicates the alarm-priority defect (i.e., the
       lowest-priority defect that is allowed to
       generate a fault alarm).";
  }

  identity remote-rdi {
    base fault-alarm-defect-type;
    description
      "Indicates the aggregate health
       of the Remote MEPs.";
  }

  identity remote-mac-error {
    base fault-alarm-defect-type;
    description
      "Indicates that one or more of the Remote MEPs are
       reporting a failure in their Port Status TLVs or
       Interface Status TLVs.";
  }

  identity remote-invalid-ccm {
    base fault-alarm-defect-type;
    description
      "Indicates that at least one of the Remote MEP
       state machines is not receiving valid
       Continuity Check Messages (CCMs) from its Remote MEP.";
  }

  identity invalid-ccm {
    base fault-alarm-defect-type;
    description
      "Indicates that one or more invalid CCMs have been
       received and that a period of time 3.5 times the length
       of those CCMs' transmission intervals has not yet expired.";
  }

  identity cross-connect-ccm {
    base fault-alarm-defect-type;
    description
      "Indicates that one or more cross-connect CCMs have been
       received and that 3.5 times the period of at least one of
       those CCMs' transmission intervals has not yet expired.";
  }

  identity frame-delivery-mode {
    description
      "Delivery types.";
  }

  identity discard {
    base frame-delivery-mode;
    description
      "Service frames are discarded.";
  }

  identity unconditional {
    base frame-delivery-mode;
    description
      "Service frames are unconditionally delivered to the
       destination site.";
  }

  identity unknown-discard {
    base frame-delivery-mode;
    description
      "Service frames are conditionally delivered to the
       destination site.  Packets with unknown destination addresses
       will be discarded.";
  }

  identity placement-diversity {
    description
      "Base identity for site placement constraints.";
  }

  identity bearer-diverse {
    base placement-diversity;
    description
      "Identity for bearer diversity.
       The bearers should not use common elements.";
  }

  identity pe-diverse {
    base placement-diversity;
    description
      "Identity for PE diversity.";
  }

  identity pop-diverse {
    base placement-diversity;
    description
      "Identity for POP diversity.";
  }

  identity linecard-diverse {
    base placement-diversity;
    description
      "Identity for linecard diversity.";
  }

  identity same-pe {
    base placement-diversity;
    description
      "Identity for having sites connected on the same PE.";
  }

  identity same-bearer {
    base placement-diversity;
    description
      "Identity for having sites connected using the same bearer.";
  }

  identity tagged-inf-type {
    description
      "Identity for the tagged interface type.";
  }

  identity priority-tagged {
    base tagged-inf-type;
    description
      "Identity for the priority-tagged interface.";
  }

  identity qinq {
    base tagged-inf-type;
    description
      "Identity for the QinQ tagged interface.";
  }

  identity dot1q {
    base tagged-inf-type;
    description
      "Identity for the dot1Q VLAN tagged interface.";
  }

  identity qinany {
    base tagged-inf-type;
    description
      "Identity for the QinAny tagged interface.";
  }

  identity vxlan {
    base tagged-inf-type;
    description
      "Identity for the VXLAN tagged interface.";
  }

  identity provision-model {
    description
      "Base identity for the provision model.";
  }

  identity single-side-provision {
    description
      "Identity for single-sided provisioning with discovery.";
  }

  identity doubled-side-provision {
    description
      "Identity for double-sided provisioning.";
  }

  identity mac-learning-mode {
    description
      "MAC learning mode.";
  }

  identity data-plane {
    base mac-learning-mode;
    description
      "User MAC addresses are learned through ARP broadcast.";
  }

  identity control-plane {
    base mac-learning-mode;
    description
      "User MAC addresses are advertised through EVPN-BGP.";
  }

  identity vpn-policy-filter-type {
    description
      "Base identity for the filter type.";
  }

  identity lan {
    base vpn-policy-filter-type;
    description
      "Identity for a LAN tag filter type.";
  }

  identity mac-action {
    description
      "Base identity for a MAC action.";
  }

  identity drop {
    base mac-action;
    description
      "Identity for dropping a packet.";
  }

  identity flood {
    base mac-action;
    description
      "Identity for packet flooding.";
  }

  identity warning {
    base mac-action;
    description
      "Identity for sending a warning log message.";
  }

  identity qos-profile-direction {
    description
      "Base identity for the QoS-profile direction.";
   }

  identity site-to-wan {
    base qos-profile-direction;
    description
      "Identity for the site-to-WAN direction.";
  }

  identity wan-to-site {
    base qos-profile-direction;
    description
      "Identity for the WAN-to-site direction.";
  }

  identity bidirectional {
    base qos-profile-direction;
    description
      "Identity for both the WAN-to-site direction
       and the site-to-WAN direction.";
  }

  identity vxlan-peer-mode {
    description
      "Base identity for the VXLAN peer mode.";
  }

  identity static-mode {
    base vxlan-peer-mode;
    description
      "Identity for VXLAN access in the static mode.";
  }

  identity bgp-mode {
    base vxlan-peer-mode;
    description
      "Identity for VXLAN access by BGP EVPN learning.";
  }

  identity customer-application {
    description
      "Base identity for a customer application.";
  }

  identity web {
    base customer-application;
    description
      "Identity for a web application (e.g., HTTP, HTTPS).";
  }

  identity mail {
    base customer-application;
    description
      "Identity for a mail application.";
  }

  identity file-transfer {
    base customer-application;
    description
      "Identity for a file-transfer application
       (e.g., FTP, SFTP).";
  }

  identity database {
    base customer-application;
    description
      "Identity for a database application.";
  }

  identity social {
    base customer-application;
    description
      "Identity for a social-network application.";
  }

  identity games {
    base customer-application;
    description
      "Identity for a gaming application.";
  }

  identity p2p {
    base customer-application;
    description
      "Identity for a peer-to-peer application.";
  }

  identity network-management {
    base customer-application;
    description
      "Identity for a management application
       (e.g., Telnet, syslog, SNMP).";
  }

  identity voice {
    base customer-application;
    description
      "Identity for a voice application.";
  }

  identity video {
    base customer-application;
    description
      "Identity for a videoconference application.";
  }

  identity embb {
    base customer-application;
    description
      "Identity for the enhanced Mobile Broadband (eMBB)
       application.  Note that the eMBB application
       requires strict threshold values for a wide variety
       of network performance parameters (e.g., data rate,
       latency, loss rate, reliability).";
  }

  identity urllc {
    base customer-application;
    description
      "Identity for the Ultra-Reliable and Low Latency
       Communications (URLLC) application.  Note that the
       URLLC application requires strict threshold values for
       a wide variety of network performance parameters
       (e.g., latency, reliability).";
  }

  identity mmtc {
    base customer-application;
    description
      "Identity for the massive Machine Type
       Communications (mMTC) application.  Note that the
       mMTC application requires strict threshold values for
       a wide variety of network performance parameters
       (e.g., data rate, latency, loss rate, reliability).";
  }

  grouping site-acl {
    container access-control-list {
      if-feature "acl";
      list mac {
        key "mac-address";
        leaf mac-address {
          type yang:mac-address;
          description
            "MAC addresses.";
        }
        description
          "List of MAC addresses.";
      }
      description
        "Container for the ACL.";
    }
    description
      "Grouping that defines the ACL.";
  }

  grouping site-bum {
    container broadcast-unknown-unicast-multicast {
      if-feature "bum";
      leaf multicast-site-type {
        type enumeration {
          enum receiver-only {
            description
              "The site only has receivers.";
          }
          enum source-only {
            description
              "The site only has sources.";
          }
          enum source-receiver {
            description
              "The site has both sources and receivers.";
          }
        }
        default "source-receiver";
        description
          "Type of multicast site.";
      }
      list multicast-gp-address-mapping {
        key "id";
        leaf id {
          type uint16;
          description
            "Unique identifier for the mapping.";
        }
        leaf vlan-id {
          type uint16 {
            range "0..1024";
          }
          mandatory true;
          description
            "The VLAN ID of the multicast group.
             The range of the 12-bit VLAN ID is 0 to 1024.";
        }
        leaf mac-gp-address {
          type yang:mac-address;
          mandatory true;
          description
            "The MAC address of the multicast group.";
        }
        leaf port-lag-number {
          type uint32;
          description
            "The ports/LAGs belonging to the multicast group.";
        }
        description
          "List of port-to-group mappings.";
      }
      leaf bum-overall-rate {
        type uint64;
        units "bps";
        description
          "Overall rate for BUM.";
      }
      list bum-rate-per-type {
        key "type";
        leaf type {
          type identityref {
            base bum-type;
          }
          description
            "BUM type.";
        }
        leaf rate {
          type uint64;
          units "bps";
          description
            "Rate for BUM.";
        }
        description
          "List of limit rates for the BUM type.";
      }
      description
        "Container of BUM configurations.";
    }
    description
      "Grouping for BUM.";
  }

  grouping site-mac-loop-prevention {
    container mac-loop-prevention {
      if-feature "mac-loop-prevention";
      leaf protection-type {
        type identityref {
          base loop-prevention-type;
        }
        default "trap";
        description
          "Protection type.  By default, the protection
           type is 'trap'.";
      }
      leaf frequency {
        type uint32;
        default "5";
        description
          "The number of times to detect MAC duplication, where
           a 'duplicate MAC address' situation has occurred and
           the duplicate MAC address has been added to a list of
           duplicate MAC addresses.  By default, the number of
           times is 5.";
      }
      leaf retry-timer {
        type uint32;
        units "seconds";
        description
          "The retry timer.  When the retry timer expires,
           the duplicate MAC address will be flushed from
           the MAC-VRF.";
      }
      description
        "Container of MAC loop-prevention parameters.";
    }
    description
      "Grouping for MAC loop prevention.";
  }

  grouping site-service-qos-profile {
    container qos {
      if-feature "qos";
      container qos-classification-policy {
        list rule {
          key "id";
          ordered-by user;
          leaf id {
            type string;
            description
              "A description identifying the QoS classification
               policy rule.";
          }
          choice match-type {
            default "match-flow";
            case match-flow {
              container match-flow {
                leaf dscp {
                  type inet:dscp;
                  description
                    "DSCP value.";
                }
                leaf dot1q {
                  type uint16;
                  description
                    "802.1Q matching.  It is a VLAN tag added into
                     a frame.";
                }
                leaf pcp {
                  type uint8 {
                    range "0..7";
                  }
                  description
                    "PCP value.";
                }
                leaf src-mac {
                  type yang:mac-address;
                  description
                    "Source MAC.";
                }
                leaf dst-mac {
                  type yang:mac-address;
                  description
                    "Destination MAC.";
                }
                leaf color-type {
                  type identityref {
                    base color-type;
                  }
                  description
                    "Color types.";
                }
                leaf-list target-sites {
                  if-feature "target-sites";
                  type svc-id;
                  description
                    "Identifies a site as a traffic destination.";
                }
                leaf any {
                  type empty;
                  description
                    "Allow all.";
                }
                leaf vpn-id {
                  type svc-id;
                  description
                    "Reference to the target VPN.";
                }
                description
                  "Describes flow-matching criteria.";
              }
            }
            case match-application {
              leaf match-application {
                type identityref {
                  base customer-application;
                }
                description
                  "Defines the application to match.";
              }
            }
            description
              "Choice for classification.";
          }
          leaf target-class-id {
            type string;
            description
              "Identification of the CoS.
               This identifier is internal to the
               administration.";
          }
          description
            "List of marking rules.";
        }
        description
          "Configuration of the traffic classification policy.";
      }
      container qos-profile {
        choice qos-profile {
          description
            "Choice for the QoS profile.
             Can be a standard profile or a customized profile.";
          case standard {
            description
              "Standard QoS profile.";
            leaf profile {
              type leafref {
                path "/l2vpn-svc/vpn-profiles/"
                   + "valid-provider-identifiers/"
                   + "qos-profile-identifier";
              }
              description
                "QoS profile to be used.";
            }
          }
          case custom {
            description
              "Customized QoS profile.";
            container classes {
              if-feature "qos-custom";
              list class {
                key "class-id";
                leaf class-id {
                  type string;
                  description
                    "Identification of the CoS.  This identifier is
                     internal to the administration.";
                }
                leaf direction {
                  type identityref {
                    base qos-profile-direction;
                  }
                  default "bidirectional";
                  description
                    "The direction in which the QoS profile is
                     applied.  By default, the direction is
                     bidirectional.";
                }
                leaf policing {
                  type identityref {
                    base policing;
                  }
                  default "one-rate-two-color";
                  description
                    "The policing type can be either one-rate,
                     two-color (1R2C) or two-rate, three-color
                     (2R3C).  By default, the policing type is
                     'one-rate-two-color'.";
                }
                leaf byte-offset {
                  type uint16;
                  description
                    "Number of bytes in the service frame header
                     that are excluded from the QoS calculation
                     (e.g., extra VLAN tags).";
                }
                container frame-delay {
                  choice flavor {
                    case lowest {
                      leaf use-lowest-latency {
                        type empty;
                        description
                          "The traffic class should use the path
                           with the lowest delay.";
                      }
                    }
                    case boundary {
                      leaf delay-bound {
                        type uint16;
                        units "milliseconds";
                        description
                          "The traffic class should use a path
                           with a defined maximum delay.";
                      }
                    }
                    description
                      "Delay constraint on the traffic class.";
                  }
                  description
                    "Delay constraint on the traffic class.";
                }
                container frame-jitter {
                  choice flavor {
                    case lowest {
                      leaf use-lowest-jitter {
                        type empty;
                        description
                          "The traffic class should use the path
                           with the lowest jitter.";
                      }
                    }
                    case boundary {
                      leaf delay-bound {
                        type uint32;
                        units "microseconds";
                        description
                          "The traffic class should use a path
                           with a defined maximum jitter.";
                      }
                    }
                    description
                      "Jitter constraint on the traffic class.";
                  }
                  description
                    "Jitter constraint on the traffic class.";
                }
                container frame-loss {
                  leaf rate {
                    type decimal64 {
                      fraction-digits 2;
                      range "0..100";
                    }
                    units "percent";
                    description
                      "Frame loss rate constraint on the traffic
                       class.";
                  }
                  description
                    "Container for frame loss rate.";
                }
                container bandwidth {
                  leaf guaranteed-bw-percent {
                    type decimal64 {
                      fraction-digits 5;
                      range "0..100";
                    }
                    units "percent";
                    mandatory true;
                    description
                      "Used to define the guaranteed bandwidth
                       as a percentage of the available service
                       bandwidth.";
                  }
                  leaf end-to-end {
                    type empty;
                    description
                      "Used if the bandwidth reservation
                       must be done on the MPLS network too.";
                  }
                  description
                    "Bandwidth constraint on the traffic class.";
                }
                description
                  "List of CoS entries.";
              }
              description
                "Container for list of CoS entries.";
            }
          }
        }
        description
          "Qos profile configuration.";
      }
      description
        "QoS configuration.";
    }
    description
      "Grouping that defines QoS parameters for a site.";
  }

  grouping site-service-mpls {
    container carrierscarrier {
      if-feature "carrierscarrier";
      leaf signaling-type {
        type identityref {
          base carrierscarrier-type;
        }
        default "bgp";
        description
          "CsC.  By default, the signaling type is 'bgp'.";
      }
      description
        "Container for CsC.";
    }
    description
      "Grouping for CsC.";
  }

  container l2vpn-svc {
    container vpn-profiles {
      container valid-provider-identifiers {
        leaf-list cloud-identifier {
          if-feature "cloud-access";
          type string;
          description
            "Identification of the public cloud service or
             Internet service.  Local to each administration.";
        }
        leaf-list qos-profile-identifier {
          type string;
          description
            "Identification of the QoS profile to be used.
             Local to each administration.";
        }
        leaf-list bfd-profile-identifier {
          type string;
          description
            "Identification of the SP BFD profile to be used.
             Local to each administration.";
        }
        leaf-list remote-carrier-identifier {
          type string;
          description
            "Identification of the remote carrier name to be used.
             It can be an L2VPN partner, data-center SP, or
             private CSP.  Local to each administration.";
        }
        nacm:default-deny-write;
        description
          "Container for valid provider identifiers.";
      }
      description
        "Container for VPN profiles.";
    }
    container vpn-services {
      list vpn-service {
        key "vpn-id";
        leaf vpn-id {
          type svc-id;
          description
            "Defines a service identifier.";
        }
        leaf vpn-svc-type {
          type identityref {
            base service-type;
          }
          default "vpws";
          description
            "Service type.  By default, the service type is 'vpws'.";
        }
        leaf customer-name {
          type string;
          description
            "Customer name.";
        }
        leaf svc-topo {
          type identityref {
            base vpn-topology;
          }
          default "any-to-any";
          description
            "Defines the service topology, e.g.,
             'any-to-any', 'hub-spoke'.";
        }
        container cloud-accesses {
          if-feature "cloud-access";
          list cloud-access {
            key "cloud-identifier";
            leaf cloud-identifier {
              type leafref {
                path "/l2vpn-svc/vpn-profiles/"
                   + "valid-provider-identifiers"
                   + "/cloud-identifier";
              }
              description
                "Identification of the cloud service.
                 Local to each administration.";
            }
            choice list-flavor {
              case permit-any {
                leaf permit-any {
                  type empty;
                  description
                    "Allow all sites.";
                }
              }
              case deny-any-except {
                leaf-list permit-site {
                  type leafref {
                    path "/l2vpn-svc/sites/site/site-id";
                  }
                  description
                    "Site ID to be authorized.";
                }
              }
              case permit-any-except {
                leaf-list deny-site {
                  type leafref {
                    path "/l2vpn-svc/sites/site/site-id";
                  }
                  description
                    "Site ID to be denied.";
                }
              }
              description
                "Choice for cloud access policy.
                 By default, all sites in the L2VPN
                 MUST be authorized to access the cloud.";
            }
            description
              "Cloud access configuration.";
          }
          description
            "Container for cloud access configurations.";
        }
        container frame-delivery {
          if-feature "bum";
          container customer-tree-flavors {
            leaf-list tree-flavor {
              type identityref {
                base multicast-tree-type;
              }
              description
                "Type of tree to be used.";
            }
            description
              "Types of trees used by the customer.";
          }
          container bum-deliveries {
            list bum-delivery {
              key "frame-type";
              leaf frame-type {
                type identityref {
                  base tf-type;
                }
                description
                  "Type of frame delivery.  It supports unicast
                   frame delivery, multicast frame delivery,
                   and broadcast frame delivery.";
              }
              leaf delivery-mode {
                type identityref {
                  base frame-delivery-mode;
                }
                default "unconditional";
                description
                  "Defines the frame delivery mode
                   ('unconditional' (default), 'conditional',
                   or 'discard').  By default, service frames are
                   unconditionally delivered to the destination site.";
              }
              description
                "List of frame delivery types and modes.";
            }
            description
              "Defines the frame delivery types and modes.";
          }
          leaf multicast-gp-port-mapping {
            type identityref {
              base multicast-gp-address-mapping;
            }
            mandatory true;
            description
              "Describes the way in which each interface is
               associated with the multicast group.";
          }
          description
            "Multicast global parameters for the VPN service.";
        }
        container extranet-vpns {
          if-feature "extranet-vpn";
          list extranet-vpn {
            key "vpn-id";
            leaf vpn-id {
              type svc-id;
              description
                "Identifies the target VPN that the local VPN wants to
                 access.";
            }
            leaf local-sites-role {
              type identityref {
                base site-role;
              }
              default "any-to-any-role";
              description
                "Describes the role of the local sites in the target
                 VPN topology.  In the any-to-any VPN service topology,
                 the local sites must have the same role, which will be
                 'any-to-any-role'.  In the Hub-and-Spoke VPN service
                 topology or the Hub-and-Spoke-Disjoint VPN service
                 topology, the local sites must have a Hub role or a
                 Spoke role.";
            }
            description
              "List of extranet VPNs to which the local VPN
               is attached.";
          }
          description
            "Container for extranet VPN configurations.";
        }
        leaf ce-vlan-preservation {
          type boolean;
          mandatory true;
          description
            "Preserves the CE-VLAN ID from ingress to egress, i.e.,
             the CE-VLAN tag of the egress frame is identical to
             that of the ingress frame that yielded this
             egress service frame.  If all-to-one bundling within
             a site is enabled, then preservation applies to all
             ingress service frames.  If all-to-one bundling is
             disabled, then preservation applies to tagged
             ingress service frames having CE-VLAN IDs 1 through 4094.";
        }
        leaf ce-vlan-cos-preservation {
          type boolean;
          mandatory true;
          description
            "CE VLAN CoS preservation.  The PCP bits in the CE-VLAN tag
             of the egress frame are identical to those of the
             ingress frame that yielded this egress service frame.";
        }
        leaf carrierscarrier {
          if-feature "carrierscarrier";
          type boolean;
          default "false";
          description
            "The VPN is using CsC, and so MPLS is required.";
        }
        description
          "List of VPN services.";
      }
      description
        "Container for VPN services.";
    }
    container sites {
      list site {
        key "site-id";
        leaf site-id {
          type string;
          description
            "Identifier of the site.";
        }
        leaf site-vpn-flavor {
          type identityref {
            base site-vpn-flavor;
          }
          default "site-vpn-flavor-single";
          description
            "Defines the way that the VPN multiplexing is
             done, e.g., whether the site belongs to
             a single VPN site or a multi-VPN site.  By
             default, the site belongs to a single VPN.";
        }
        container devices {
          when "derived-from-or-self(../management/type, "
             + "'l2vpn-svc:provider-managed') or "
             + "derived-from-or-self(../management/type, "
             + "'l2vpn-svc:co-managed')" {
            description
              "Applicable only for a provider-managed or
               co-managed device.";
          }
          list device {
            key "device-id";
            leaf device-id {
              type string;
              description
                "Identifier for the device.";
            }
            leaf location {
              type leafref {
                path "../../../locations/location/location-id";
              }
              mandatory true;
              description
                "Location of the device.";
            }
            container management {
              when "derived-from-or-self(../../../management/type, "
                 + "'l2vpn-svc:co-managed')" {
                description
                  "Applicable only for a co-managed device.";
              }
              leaf transport {
                type identityref {
                  base address-family;
                }
                description
                  "Transport protocol or address family
                   used for management.";
              }
              leaf address {
                when '(../ transport)' {
                  description
                    "If the address family is specified, then the
                     address should also be specified.  If the
                     transport is not specified, then the address
                     should not be specified.";
                }
                type inet:ip-address;
                description
                  "Management address.";
              }
              description
                "Management configuration.  Applicable only for a
                 co-managed device.";
            }
            description
              "List of devices requested by the customer.";
          }
          description
            "Device configurations.";
        }
        container management {
          leaf type {
            type identityref {
              base management;
            }
            mandatory true;
            description
              "Management type of the connection.";
          }
          description
            "Management configuration.";
        }
        container locations {
          list location {
            key "location-id";
            leaf location-id {
              type string;
              description
                "Location ID.";
            }
            leaf address {
              type string;
              description
                "Address (number and street) of the site.";
            }
            leaf postal-code {
              type string;
              description
                "Postal code of the site.  The format of 'postal-code'
                 is similar to the 'PC' (postal code) label format
                 defined in RFC 4119.";
            }
            leaf state {
              type string;
              description
                "State (region) of the site.  This leaf can also be used
                 to describe a region of a country that does not have
                 states.";
            }
            leaf city {
              type string;
              description
                "City of the site.";
            }
            leaf country-code {
              type string;
              description
                "Country of the site.  The format of 'country-code' is
                 similar to the 'country' label defined in RFC 4119.";
            }
            description
              "List of locations.";
          }
          description
            "Location of the site.";
        }
        container site-diversity {
          if-feature "site-diversity";
          container groups {
            list group {
              key "group-id";
              leaf group-id {
                type string;
                description
                  "The group-id to which the site belongs.";
              }
              description
                "List of group-ids.";
            }
            description
              "Groups to which the site belongs.
               All site network accesses will inherit those group
               values.";
          }
          description
            "The type of diversity constraint.";
        }
        container vpn-policies {
          list vpn-policy {
            key "vpn-policy-id";
            leaf vpn-policy-id {
              type string;
              description
                "Unique identifier for the VPN policy.";
            }
            list entries {
              key "id";
              leaf id {
                type string;
                description
                  "Unique identifier for the policy entry.";
              }
              container filters {
                list filter {
                  key "type";
                  ordered-by user;
                  leaf type {
                    type identityref {
                      base vpn-policy-filter-type;
                    }
                    description
                      "Type of VPN policy filter.";
                  }
                  leaf-list lan-tag {
                    when "derived-from-or-self(../type, "
                       + "'l2vpn-svc:lan')" {
                      description
                        "Only applies when the VPN policy filter is a
                         LAN tag filter.";
                    }
                    if-feature "lan-tag";
                    type uint32;
                    description
                      "List of Ethernet LAN tags to be matched.  An
                       Ethernet LAN tag identifies a particular
                       broadcast domain in a VPN.";
                  }
                  description
                    "List of filters used on the site.  This list can
                     be augmented.";
                }
                description
                  "If a more granular VPN attachment is necessary,
                   filtering can be used.  If used, it permits the
                   splitting of site LANs among multiple VPNs.  The
                   site LAN can be split based on either the LAN tag or
                   the LAN prefix.  If no filter is used, all the LANs
                   will be part of the same VPNs with the same role.";
              }
              list vpn {
                key "vpn-id";
                leaf vpn-id {
                  type leafref {
                    path "/l2vpn-svc/vpn-services/vpn-service/vpn-id";
                  }
                  description
                    "Reference to an L2VPN.";
                }
                leaf site-role {
                  type identityref {
                    base site-role;
                  }
                  default "any-to-any-role";
                  description
                    "Role of the site in the L2VPN.";
                }
                description
                  "List of VPNs with which the LAN is associated.";
              }
              description
                "List of entries for an export policy.";
            }
            description
              "List of VPN policies.";
          }
          description
            "VPN policy.";
        }
        container service {
          uses site-service-qos-profile;
          uses site-service-mpls;
          description
            "Service parameters on the attachment.";
        }
        uses site-bum;
        uses site-mac-loop-prevention;
        uses site-acl;
        leaf actual-site-start {
          type yang:date-and-time;
          config false;
          description
            "This leaf is optional.  It indicates the date and time
             when the service at a particular site actually started.";
        }
        leaf actual-site-stop {
          type yang:date-and-time;
          config false;
          description
            "This leaf is optional.  It indicates the date and time
             when the service at a particular site actually stopped.";
        }
        leaf bundling-type {
          type identityref {
            base bundling-type;
          }
          default "one2one-bundling";
          description
            "Bundling type.  By default, each L2VPN
             can be associated with only one
             CE-VLAN, i.e., one-to-one bundling is used.";
        }
        leaf default-ce-vlan-id {
          type uint32;
          mandatory true;
          description
            "Default CE VLAN ID set at the site level.";
        }
        container site-network-accesses {
          list site-network-access {
            key "network-access-id";
            leaf network-access-id {
              type string;
              description
                "Identifier of network access.";
            }
            leaf remote-carrier-name {
              when "derived-from-or-self(../../../site-vpn-flavor,"
                 + "'l2vpn-svc:site-vpn-flavor-nni')" {
                description
                  "Relevant when the site's VPN flavor is
                   'site-vpn-flavor-nni'.";
              }
              type leafref {
                path "/l2vpn-svc/vpn-profiles/"
                   + "valid-provider-identifiers"
                   + "/remote-carrier-identifier";
              }
              description
                "Remote carrier name.  The 'remote-carrier-name'
                 parameter must be configured only when
                 'site-vpn-flavor' is set to 'site-vpn-flavor-nni'.
                 If it is not set, it indicates that the customer
                 does not know the remote carrier's name
                 beforehand.";
            }
            leaf type {
              type identityref {
                base site-network-access-type;
              }
              default "point-to-point";
              description
                "Describes the type of connection, e.g.,
                 point-to-point or multipoint.";
            }
            choice location-flavor {
              case location {
                when "derived-from-or-self(../../management/type, "
                   + "'l2vpn-svc:customer-managed')" {
                  description
                    "Applicable only for a customer-managed device.";
                }
                leaf location-reference {
                  type leafref {
                    path "../../../locations/location/location-id";
                  }
                  description
                    "Location of the site-network-access.";
                }
              }
              case device {
                when "derived-from-or-self(../../management/type, "
                   + "'l2vpn-svc:provider-managed') or "
                   + "derived-from-or-self(../../management/type, "
                   + "'l2vpn-svc:co-managed')" {
                  description
                    "Applicable only for a provider-managed
                     or co-managed device.";
                }
                leaf device-reference {
                  type leafref {
                    path "../../../devices/device/device-id";
                  }
                  description
                    "Identifier of the CE to use.";
                }
              }
              mandatory true;
              description
                "Choice of how to describe the site's location.";
            }
            container access-diversity {
              if-feature "site-diversity";
              container groups {
                list group {
                  key "group-id";
                  leaf group-id {
                    type string;
                    description
                      "Group-id to which the site belongs.";
                  }
                  description
                    "List of group-ids.";
                }
                description
                  "Groups to which the site or site-network-access
                   belongs.";
              }
              container constraints {
                list constraint {
                  key "constraint-type";
                  leaf constraint-type {
                    type identityref {
                      base placement-diversity;
                    }
                    description
                      "The type of diversity constraint.";
                  }
                  container target {
                    choice target-flavor {
                      default "id";
                      case id {
                        list group {
                          key "group-id";
                          leaf group-id {
                            type string;
                            description
                              "The constraint will apply against this
                               particular group-id.";
                          }
                          description
                            "List of groups.";
                        }
                      }
                      case all-accesses {
                        leaf all-other-accesses {
                          type empty;
                          description
                            "The constraint will apply against all other
                             site network accesses of this site.";
                        }
                      }
                      case all-groups {
                        leaf all-other-groups {
                          type empty;
                          description
                            "The constraint will apply against all other
                             groups the customer is managing.";
                        }
                      }
                      description
                        "Choice for the group definition.";
                    }
                    description
                      "The constraint will apply against
                       this list of groups.";
                  }
                  description
                    "List of constraints.";
                }
                description
                  "Constraints for placing this site network access.";
              }
              description
                "Diversity parameters.";
            }
            container bearer {
              container requested-type {
                if-feature "requested-type";
                leaf type {
                  type string;
                  description
                    "Type of requested bearer: Ethernet, ATM, Frame
                     Relay, IP Layer 2 transport, Frame Relay Data
                     Link Connection Identifier (DLCI), SONET/SDH,
                     PPP.";
                }
                leaf strict {
                  type boolean;
                  default "false";
                  description
                    "Defines whether the requested type is a preference
                     or a strict requirement.";
                }
                description
                  "Container for requested types.";
              }
              leaf always-on {
                if-feature "always-on";
                type boolean;
                default "true";
                description
                  "Request for an 'always-on' access type.
                   For example, this could mean no dial-in access
                   type.";
              }
              leaf bearer-reference {
                if-feature "bearer-reference";
                type string;
                description
                  "An internal reference for the SP.";
              }
              description
                "Bearer-specific parameters.  To be augmented.";
            }
            container connection {
              leaf encapsulation-type {
                type identityref {
                  base encapsulation-type;
                }
                default "ethernet";
                description
                  "Encapsulation type.  By default, the
                   encapsulation type is set to 'ethernet'.";
              }
              leaf eth-inf-type {
                type identityref {
                  base eth-inf-type;
                }
                default "untagged";
                description
                  "Ethernet interface type.  By default, the
                   Ethernet interface type is set to 'untagged'.";
              }
              container tagged-interface {
                leaf type {
                  type identityref {
                    base tagged-inf-type;
                  }
                  default "priority-tagged";
                  description
                    "Tagged interface type.  By default,
                     the type of the tagged interface is
                     'priority-tagged'.";
                }
                container dot1q-vlan-tagged {
                  when "derived-from-or-self(../type, "
                     + "'l2vpn-svc:dot1q')" {
                    description
                      "Only applies when the type of the tagged
                       interface is 'dot1q'.";
                  }
                  if-feature "dot1q";
                  leaf tg-type {
                    type identityref {
                      base tag-type;
                    }
                    default "c-vlan";
                    description
                      "Tag type.  By default, the tag type is
                       'c-vlan'.";
                  }
                  leaf cvlan-id {
                    type uint16;
                    mandatory true;
                    description
                      "VLAN identifier.";
                  }
                  description
                    "Tagged interface.";
                }
                container priority-tagged {
                  when "derived-from-or-self(../type, "
                     + "'l2vpn-svc:priority-tagged')" {
                    description
                      "Only applies when the type of the tagged
                       interface is 'priority-tagged'.";
                  }
                  leaf tag-type {
                    type identityref {
                      base tag-type;
                    }
                    default "c-vlan";
                    description
                      "Tag type.  By default, the tag type is
                       'c-vlan'.";
                  }
                  description
                    "Priority tagged.";
                }
                container qinq {
                  when "derived-from-or-self(../type, "
                     + "'l2vpn-svc:qinq')" {
                    description
                      "Only applies when the type of the tagged
                       interface is 'qinq'.";
                  }
                  if-feature "qinq";
                  leaf tag-type {
                    type identityref {
                      base tag-type;
                    }
                    default "c-s-vlan";
                    description
                      "Tag type.  By default, the tag type is
                       'c-s-vlan'.";
                  }
                  leaf svlan-id {
                    type uint16;
                    mandatory true;
                    description
                      "SVLAN identifier.";
                  }
                  leaf cvlan-id {
                    type uint16;
                    mandatory true;
                    description
                      "CVLAN identifier.";
                  }
                  description
                    "QinQ.";
                }
                container qinany {
                  when "derived-from-or-self(../type, "
                     + "'l2vpn-svc:qinany')" {
                    description
                      "Only applies when the type of the tagged
                       interface is 'qinany'.";
                  }
                  if-feature "qinany";
                  leaf tag-type {
                    type identityref {
                      base tag-type;
                    }
                    default "s-vlan";
                    description
                      "Tag type.  By default, the tag type is
                       's-vlan'.";
                  }
                  leaf svlan-id {
                    type uint16;
                    mandatory true;
                    description
                      "SVLAN ID.";
                  }
                  description
                    "Container for QinAny.";
                }
                container vxlan {
                  when "derived-from-or-self(../type, "
                     + "'l2vpn-svc:vxlan')" {
                    description
                      "Only applies when the type of the tagged
                       interface is 'vxlan'.";
                  }
                  if-feature "vxlan";
                  leaf vni-id {
                    type uint32;
                    mandatory true;
                    description
                      "VXLAN Network Identifier (VNI).";
                  }
                  leaf peer-mode {
                    type identityref {
                      base vxlan-peer-mode;
                    }
                    default "static-mode";
                    description
                      "Specifies the VXLAN access mode.  By default,
                       the peer mode is set to 'static-mode'.";
                  }
                  list peer-list {
                    key "peer-ip";
                    leaf peer-ip {
                      type inet:ip-address;
                      description
                        "Peer IP.";
                    }
                    description
                      "List of peer IP addresses.";
                  }
                  description
                    "QinQ.";
                }
                description
                  "Container for tagged interfaces.";
              }
              container untagged-interface {
                leaf speed {
                  type uint32;
                  units "mbps";
                  default "10";
                  description
                    "Port speed.";
                }
                leaf mode {
                  type neg-mode;
                  default "auto-neg";
                  description
                    "Negotiation mode.";
                }
                leaf phy-mtu {
                  type uint32;
                  units "bytes";
                  description
                    "PHY MTU.";
                }
                leaf lldp {
                  type boolean;
                  default "false";
                  description
                    "LLDP.  Indicates that LLDP is supported.";
                }
                container oam-802.3ah-link {
                  if-feature "oam-3ah";
                  leaf enabled {
                    type boolean;
                    default "false";
                    description
                      "Indicates whether or not to support
                       OAM 802.3ah links.";
                  }
                  description
                    "Container for OAM 802.3ah links.";
                }
                leaf uni-loop-prevention {
                  type boolean;
                  default "false";
                  description
                    "If this leaf is set to 'true', then the port
                     automatically goes down when a physical
                     loopback is detected.";
                }
                description
                  "Container of untagged interface attribute
                   configurations.";
              }
              container lag-interfaces {
                if-feature "lag-interface";
                list lag-interface {
                  key "index";
                  leaf index {
                    type string;
                    description
                      "LAG interface index.";
                  }
                  container lacp {
                    if-feature "lacp";
                    leaf enabled {
                      type boolean;
                      default "false";
                      description
                        "LACP on/off.  By default, LACP is disabled.";
                    }
                    leaf mode {
                      type neg-mode;
                      description
                        "LACP mode.  LACP modes have active mode and
                         passive mode ('false').  'Active mode' means
                         initiating the auto-speed negotiation and
                         trying to form an Ethernet channel with the
                         other end.  'Passive mode' means not initiating
                         the negotiation but responding to LACP packets
                         initiated by the other end (e.g., full duplex
                         or half duplex).";
                    }
                    leaf speed {
                      type uint32;
                      units "mbps";
                      default "10";
                      description
                        "LACP speed.  By default, the LACP speed is 10
                         Mbps.";
                    }
                    leaf mini-link-num {
                      type uint32;
                      description
                        "Defines the minimum number of links that must
                         be active before the aggregating link is put
                         into service.";
                    }
                    leaf system-priority {
                      type uint16;
                      default "32768";
                      description
                        "Indicates the LACP priority for the system.
                         The range is from 0 to 65535.
                         The default is 32768.";
                    }
                    container micro-bfd {
                      if-feature "micro-bfd";
                      leaf enabled {
                        type enumeration {
                          enum on {
                            description
                              "Micro-bfd on.";
                          }
                          enum off {
                            description
                              "Micro-bfd off.";
                          }
                        }
                        default "off";
                        description
                          "Micro-BFD on/off.  By default, micro-BFD
                           is set to 'off'.";
                      }
                      leaf interval {
                        type uint32;
                        units "milliseconds";
                        description
                          "BFD interval.";
                      }
                      leaf hold-timer {
                        type uint32;
                        units "milliseconds";
                        description
                          "BFD hold timer.";
                      }
                      description
                        "Container of micro-BFD configurations.";
                    }
                    container bfd {
                      if-feature "bfd";
                      leaf enabled {
                        type boolean;
                        default "false";
                        description
                          "BFD activation.  By default, BFD is not
                           activated.";
                      }
                      choice holdtime {
                        default "fixed";
                        case profile {
                          leaf profile-name {
                            type leafref {
                              path "/l2vpn-svc/vpn-profiles/"
                                 + "valid-provider-identifiers"
                                 + "/bfd-profile-identifier";
                            }
                            description
                              "SP well-known profile.";
                          }
                          description
                            "SP well-known profile.";
                        }
                        case fixed {
                          leaf fixed-value {
                            type uint32;
                            units "milliseconds";
                            description
                              "Expected hold time expressed in
                               milliseconds.";
                          }
                        }
                        description
                          "Choice for the hold-time flavor.";
                      }
                      description
                        "Container for BFD.";
                    }
                    container member-links {
                      list member-link {
                        key "name";
                        leaf name {
                          type string;
                          description
                            "Member link name.";
                        }
                        leaf speed {
                          type uint32;
                          units "mbps";
                          default "10";
                          description
                            "Port speed.";
                        }
                        leaf mode {
                          type neg-mode;
                          default "auto-neg";
                          description
                            "Negotiation mode.";
                        }
                        leaf link-mtu {
                          type uint32;
                          units "bytes";
                          description
                            "Link MTU size.";
                        }
                        container oam-802.3ah-link {
                          if-feature "oam-3ah";
                          leaf enabled {
                            type boolean;
                            default "false";
                            description
                              "Indicates whether OAM 802.3ah links are
                               supported.";
                          }
                          description
                            "Container for OAM 802.3ah links.";
                        }
                        description
                          "Member link.";
                      }
                      description
                        "Container of the member link list.";
                    }
                    leaf flow-control {
                      type boolean;
                      default "false";
                      description
                        "Flow control.  Indicates whether flow control
                         is supported.";
                    }
                    leaf lldp {
                      type boolean;
                      default "false";
                      description
                        "LLDP.  Indicates whether LLDP is supported.";
                    }
                    description
                      "LACP.";
                  }
                  description
                    "List of LAG interfaces.";
                }
                description
                  "Container of LAG interface attribute
                   configurations.";
              }
              list cvlan-id-to-svc-map {
                key "svc-id";
                leaf svc-id {
                  type leafref {
                    path "/l2vpn-svc/vpn-services/vpn-service/vpn-id";
                  }
                  description
                    "VPN service identifier.";
                }
                list cvlan-id {
                  key "vid";
                  leaf vid {
                    type uint16;
                    description
                      "CVLAN ID.";
                  }
                  description
                    "List of CVLAN-ID-to-SVC-map configurations.";
                }
                description
                  "List of CVLAN-ID-to-L2VPN-service-map
                   configurations.";
              }
              container l2cp-control {
                if-feature "l2cp-control";
                leaf stp-rstp-mstp {
                  type control-mode;
                  description
                    "STP / Rapid STP (RSTP) / Multiple STP (MSTP)
                     protocol type applicable to all sites.";
                }
                leaf pause {
                  type control-mode;
                  description
                    "Pause protocol type applicable to all sites.";
                }
                leaf lacp-lamp {
                  type control-mode;
                  description
                    "LACP / Link Aggregation Marker Protocol (LAMP).";
                }
                leaf link-oam {
                  type control-mode;
                  description
                    "Link OAM.";
                }
                leaf esmc {
                  type control-mode;
                  description
                    "Ethernet Synchronization Messaging Channel
                     (ESMC).";
                }
                leaf l2cp-802.1x {
                  type control-mode;
                  description
                    "IEEE 802.1x.";
                }
                leaf e-lmi {
                  type control-mode;
                  description
                    "E-LMI.";
                }
                leaf lldp {
                  type boolean;
                  description
                    "LLDP protocol type applicable to all sites.";
                }
                leaf ptp-peer-delay {
                  type control-mode;
                  description
                    "Precision Time Protocol (PTP) peer delay.";
                }
                leaf garp-mrp {
                  type control-mode;
                  description
                    "GARP/MRP.";
                }
                description
                  "Container of L2CP control configurations.";
              }
              container oam {
                if-feature "ethernet-oam";
                leaf md-name {
                  type string;
                  mandatory true;
                  description
                    "Maintenance domain name.";
                }
                leaf md-level {
                  type uint16 {
                    range "0..255";
                  }
                  mandatory true;
                  description
                    "Maintenance domain level.  The level may be
                     restricted in certain protocols (e.g.,
                     protocols in Layer 0 to Layer 7).";
                }
                list cfm-8021-ag {
                  if-feature "cfm";
                  key "maid";
                  leaf maid {
                    type string;
                    mandatory true;
                    description
                      "Identifies a Maintenance Association (MA).";
                  }
                  leaf mep-id {
                    type uint32;
                    description
                      "Local Maintenance Entity Group End Point (MEP)
                       ID.  The non-existence of this leaf means
                       that no defects are to be reported.";
                  }
                  leaf mep-level {
                    type uint32;
                    description
                      "Defines the MEP level.  The non-existence of this
                       leaf means that no defects are to be reported.";
                  }
                  leaf mep-up-down {
                    type enumeration {
                      enum up {
                        description
                          "MEP up.";
                      }
                      enum down {
                        description
                          "MEP down.";
                      }
                    }
                    default "up";
                    description
                      "MEP up/down.  By default, MEP up is used.
                       The non-existence of this leaf means that
                       no defects are to be reported.";
                  }
                  leaf remote-mep-id {
                    type uint32;
                    description
                      "Remote MEP ID.  The non-existence of this leaf
                       means that no defects are to be reported.";
                  }
                  leaf cos-for-cfm-pdus {
                    type uint32;
                    description
                      "CoS for CFM PDUs.  The non-existence of this leaf
                       means that no defects are to be reported.";
                  }
                  leaf ccm-interval {
                    type uint32;
                    units "milliseconds";
                    default "10000";
                    description
                      "CCM interval.  By default, the CCM interval is
                       10,000 milliseconds (10 seconds).";
                  }
                  leaf ccm-holdtime {
                    type uint32;
                    units "milliseconds";
                    default "35000";
                    description
                      "CCM hold time.  By default, the CCM hold time
                       is 3.5 times the CCM interval.";
                  }
                  leaf alarm-priority-defect {
                    type identityref {
                      base fault-alarm-defect-type;
                    }
                    default "remote-invalid-ccm";
                    description
                      "The lowest-priority defect that is
                       allowed to generate a fault alarm.  By default,
                       'fault-alarm-defect-type' is set to
                       'remote-invalid-ccm'.  The non-existence of
                       this leaf means that no defects are
                       to be reported.";
                  }
                  leaf ccm-p-bits-pri {
                    type ccm-priority-type;
                    description
                      "The priority parameter for CCMs transmitted by
                       the MEP.  The non-existence of this leaf means
                       that no defects are to be reported.";
                  }
                  description
                    "List of 802.1ag CFM attributes.";
                }
                list y-1731 {
                  if-feature "y-1731";
                  key "maid";
                  leaf maid {
                    type string;
                    mandatory true;
                    description
                      "Identifies an MA.";
                  }
                  leaf mep-id {
                    type uint32;
                    description
                      "Local MEP ID.  The non-existence of this leaf
                       means that no measurements are to be reported.";
                  }
                  leaf type {
                    type identityref {
                      base pm-type;
                    }
                    default "delay";
                    description
                      "Performance-monitoring types.  By default, the
                       performance-monitoring type is set to 'delay'.
                       The non-existence of this leaf means that no
                       measurements are to be reported.";
                  }
                  leaf remote-mep-id {
                    type uint32;
                    description
                      "Remote MEP ID.  The non-existence of this
                       leaf means that no measurements are to be
                       reported.";
                  }
                  leaf message-period {
                    type uint32;
                    units "milliseconds";
                    default "10000";
                    description
                      "Defines the interval between Y.1731
                       performance-monitoring messages.  The message
                       period is expressed in milliseconds.";
                  }
                  leaf measurement-interval {
                    type uint32;
                    units "seconds";
                    description
                      "Specifies the measurement interval for
                       statistics.  The measurement interval is
                       expressed in seconds.";
                  }
                  leaf cos {
                    type uint32;
                    description
                      "CoS.  The non-existence of this leaf means that
                       no measurements are to be reported.";
                  }
                  leaf loss-measurement {
                    type boolean;
                    default "false";
                    description
                      "Indicates whether or not to enable loss
                       measurement.  By default, loss
                       measurement is not enabled.";
                  }
                  leaf synthetic-loss-measurement {
                    type boolean;
                    default "false";
                    description
                      "Indicates whether or not to enable synthetic loss
                       measurement.  By default, synthetic loss
                       measurement is not enabled.";
                  }
                  container delay-measurement {
                    leaf enable-dm {
                      type boolean;
                      default "false";
                      description
                        "Indicates whether or not to enable delay
                         measurement.  By default, delay measurement
                         is not enabled.";
                    }
                    leaf two-way {
                      type boolean;
                      default "false";
                      description
                        "Indicates whether delay measurement is two-way
                         ('true') or one-way ('false').  By default,
                         one-way measurement is enabled.";
                    }
                    description
                      "Container for delay measurement.";
                  }
                  leaf frame-size {
                    type uint32;
                    units "bytes";
                    description
                      "Frame size.  The non-existence of this leaf
                       means that no measurements are to be reported.";
                  }
                  leaf session-type {
                    type enumeration {
                      enum proactive {
                        description
                          "Proactive mode.";
                      }
                      enum on-demand {
                        description
                          "On-demand mode.";
                      }
                    }
                    default "on-demand";
                    description
                      "Session type.  By default, the session type
                       is 'on-demand'.  The non-existence of this
                       leaf means that no measurements are to be
                       reported.";
                  }
                  description
                    "List of configured Y-1731 instances.";
                }
                description
                  "Container for Ethernet Service OAM.";
              }
              description
                "Container for connection requirements.";
            }
            container availability {
              leaf access-priority {
                type uint32;
                default "100";
                description
                  "Access priority.  The higher the access-priority
                   value, the higher the preference will be for the
                   access in question.";
              }
              choice redundancy-mode {
                case single-active {
                  leaf single-active {
                    type empty;
                    description
                      "Single-active mode.";
                  }
                  description
                    "In single-active mode, only one node forwards
                     traffic to and from the Ethernet segment.";
                }
                case all-active {
                  leaf all-active {
                    type empty;
                    description
                      "All-active mode.";
                  }
                  description
                    "In all-active mode, all nodes can forward
                     traffic.";
                }
                description
                  "Redundancy mode choice.";
              }
              description
                "Container of available optional configurations.";
            }
            container vpn-attachment {
              choice attachment-flavor {
                case vpn-id {
                  leaf vpn-id {
                    type leafref {
                      path "/l2vpn-svc/vpn-services/vpn-service/vpn-id";
                    }
                    description
                      "Reference to an L2VPN.  Referencing a vpn-id
                       provides an easy way to attach a particular
                       logical access to a VPN.  In this case,
                       the vpn-id must be configured.";
                  }
                  leaf site-role {
                    type identityref {
                      base site-role;
                    }
                    default "any-to-any-role";
                    description
                      "Role of the site in the L2VPN.  When referencing
                       a vpn-id, the site-role setting must be added to
                       express the role of the site in the target VPN
                       service topology.";
                  }
                }
                case vpn-policy-id {
                  leaf vpn-policy-id {
                    type leafref {
                      path "../../../../vpn-policies/vpn-policy/"
                         + "vpn-policy-id";
                    }
                    description
                      "Reference to a VPN policy.";
                  }
                }
                mandatory true;
                description
                  "Choice for the VPN attachment flavor.";
              }
              description
                "Defines the VPN attachment of a site.";
            }
            container service {
              container svc-bandwidth {
                if-feature "input-bw";
                list bandwidth {
                  key "direction type";
                  leaf direction {
                    type identityref {
                      base bw-direction;
                    }
                    description
                      "Indicates the bandwidth direction.  It can be
                       the bandwidth download direction from the SP to
                       the site or the bandwidth upload direction from
                       the site to the SP.";
                  }
                  leaf type {
                    type identityref {
                      base bw-type;
                    }
                    description
                      "Bandwidth type.  By default, the bandwidth type
                       is set to 'bw-per-cos'.";
                  }
                  leaf cos-id {
                    when "derived-from-or-self(../type, "
                       + "'l2vpn-svc:bw-per-cos')" {
                      description
                        "Relevant when the bandwidth type is set to
                         'bw-per-cos'.";
                    }
                    type uint8;
                    description
                      "Identifier of the CoS, indicated by DSCP or a
                       CE-VLAN CoS (802.1p) value in the service frame.
                       If the bandwidth type is set to 'bw-per-cos',
                       the CoS ID MUST also be specified.";
                  }
                  leaf vpn-id {
                    when "derived-from-or-self(../type, "
                       + "'l2vpn-svc:bw-per-svc')" {
                      description
                        "Relevant when the bandwidth type is
                         set as bandwidth per VPN service.";
                    }
                    type svc-id;
                    description
                      "Identifies the target VPN.  If the bandwidth
                       type is set as bandwidth per VPN service, the
                       vpn-id MUST be specified.";
                  }
                  leaf cir {
                    type uint64;
                    units "bps";
                    mandatory true;
                    description
                      "Committed Information Rate.  The maximum number
                       of bits that a port can receive or send over
                       an interface in one second.";
                  }
                  leaf cbs {
                    type uint64;
                    units "bps";
                    mandatory true;
                    description
                      "Committed Burst Size (CBS).  Controls the bursty
                       nature of the traffic.  Traffic that does not
                       use the configured Committed Information Rate
                       (CIR) accumulates credits until the credits
                       reach the configured CBS.";
                  }
                  leaf eir {
                    type uint64;
                    units "bps";
                    description
                      "Excess Information Rate (EIR), i.e., excess frame
                       delivery allowed that is not subject to an SLA.
                       The traffic rate can be limited by the EIR.";
                  }
                  leaf ebs {
                    type uint64;
                    units "bps";
                    description
                      "Excess Burst Size (EBS).  The bandwidth available
                       for burst traffic from the EBS is subject to the
                       amount of bandwidth that is accumulated during
                       periods when traffic allocated by the EIR
                       policy is not used.";
                  }
                  leaf pir {
                    type uint64;
                    units "bps";
                    description
                      "Peak Information Rate, i.e., maximum frame
                       delivery allowed.  It is equal to or less
                       than the sum of the CIR and the EIR.";
                  }
                  leaf pbs {
                    type uint64;
                    units "bps";
                    description
                      "Peak Burst Size.  It is measured in bytes per
                       second.";
                  }
                  description
                    "List of bandwidth values (e.g., per CoS,
                     per vpn-id).";
                }
                description
                  "From the customer site's perspective, the service
                   input/output bandwidth of the connection or
                   download/upload bandwidth from the SP/site
                   to the site/SP.";
              }
              leaf svc-mtu {
                type uint16;
                units "bytes";
                mandatory true;
                description
                  "SVC MTU.  It is also known as the maximum
                   transmission unit or maximum frame size.  When
                   a frame is larger than the MTU, it is broken
                   down, or fragmented, into smaller pieces by
                   the network protocol to accommodate the MTU
                   of the network.  If CsC is enabled,
                   the requested svc-mtu leaf will refer to the
                   MPLS MTU and not to the link MTU.";
              }
              uses site-service-qos-profile;
              uses site-service-mpls;
              description
                "Container for services.";
            }
            uses site-bum;
            uses site-mac-loop-prevention;
            uses site-acl;
            container mac-addr-limit {
              if-feature "mac-addr-limit";
              leaf limit-number {
                type uint16;
                default "2";
                description
                  "Maximum number of MAC addresses learned from
                   the subscriber for a single service instance.
                   The default allowed maximum number of MAC
                   addresses is 2.";
              }
              leaf time-interval {
                type uint32;
                units "seconds";
                default "300";
                description
                  "The aging time of the MAC address.  By default,
                   the aging time is set to 300 seconds.";
              }
              leaf action {
                type identityref {
                  base mac-action;
                }
                default "warning";
                description
                  "Specifies the action taken when the upper limit is
                   exceeded: drop the packet, flood the packet, or
                   simply send a warning log message.  By default,
                   the action is set to 'warning'.";
              }
              description
                "Container of MAC address limit configurations.";
            }
            description
              "List of site network accesses.";
          }
          description
            "Container of port configurations.";
        }
        description
          "List of sites.";
      }
      description
        "Container of site configurations.";
    }
    description
      "Container for L2VPN services.";
  }
}

<CODE ENDS>

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

Модуль YANG, заданный в этом документе, определяет схему данных, которые предназначены для доступа по протоколам сетевого управления, таким как NETCONF [RFC6241] или RESTCONF [RFC8040]. Нижним уровнем NETCONF является защищенный транспорт, а обязательным для реализации транспортом — SSH1 [RFC6242]. Нижним уровнем протокола RESTCONF является HTTPS и обязательна реализация защищенного транспорта TLS [RFC8446].

Модель управления доступом NETCONF [RFC8341] обеспечивает способы ограничения доступа, разрешая его конкретным пользователям NETCONF или RESTCONF к заранее заданному набору всех доступных операций протокола NETCONF или RESTCONF, а также компонентам содержимого.

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

  • /l2vpn-svc/vpn-services/vpn-service

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

  • /l2vpn-svc/sites/site

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

Некоторые из доступных для чтения узлов данных в этом модуле YANG могут быть уязвимыми или конфиденциальными в отдельных сетевых средах. Важно контролировать доступ (например, get, get-config, notification) к таким узлам. Ниже перечислены такие субдеревья и узлы данных.

  • /l2vpn-svc/vpn-services/vpn-service

  • /l2vpn-svc/sites/site

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

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

Модель данных определяет некоторые параметры защиты, которые могут быть расширены с помощью дополнений. Эти параметры описаны в параграфах 5.12 и 5.13.

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

Агентство IANA выделило новое значение URI в реестре «IETF XML Registry» [RFC3688].

      URI: urn:ietf:params:xml:ns:yang:ietf-l2vpn-svc
      Registrant Contact: The IESG
      XML: N/A; the requested URI is an XML namespace

Агентство IANA выделило новое имя модуля YANG в реестре «YANG Module Names» [RFC6020].

      name: ietf-l2vpn-svc
      namespace: urn:ietf:params:xml:ns:yang:ietf-l2vpn-svc
      prefix: l2vpn-svc
      reference: RFC 8466

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

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

[RFC3688] Mealling, M., «The IETF XML Registry», BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, <https://www.rfc-editor.org/info/rfc3688>.

[RFC4364] Rosen, E. and Y. Rekhter, «BGP/MPLS IP Virtual Private Networks (VPNs)», RFC 4364, DOI 10.17487/RFC4364, February 2006, <https://www.rfc-editor.org/info/rfc4364>.

[RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., «Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling», RFC 4761, DOI 10.17487/RFC4761, January 2007, <https://www.rfc-editor.org/info/rfc4761>.

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

[RFC6073] Martini, L., Metz, C., Nadeau, T., Bocci, M., and M. Aissaoui, «Segmented Pseudowire», RFC 6073, DOI 10.17487/RFC6073, January 2011, <https://www.rfc-editor.org/info/rfc6073>.

[RFC6074] Rosen, E., Davie, B., Radoaca, V., and W. Luo, «Provisioning, Auto-Discovery, and Signaling in Layer 2 Virtual Private Networks (L2VPNs)», RFC 6074, DOI 10.17487/RFC6074, January 2011, <https://www.rfc-editor.org/info/rfc6074>.

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

[RFC6991] Schoenwaelder, J., Ed., «Common YANG Data Types», RFC 6991, DOI 10.17487/RFC6991, July 2013, <https://www.rfc-editor.org/info/rfc6991>.

[RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., Uttaro, J., Drake, J., and W. Henderickx, «BGP MPLS-Based Ethernet VPN», RFC 7432, DOI 10.17487/RFC7432, February 2015, <https://www.rfc-editor.org/info/rfc7432>.

[RFC7950] Bjorklund, M., Ed., «The YANG 1.1 Data Modeling Language», RFC 7950, DOI 10.17487/RFC7950, August 2016, <https://www.rfc-editor.org/info/rfc7950>.

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

[RFC8214] Boutros, S., Sajassi, A., Salam, S., Drake, J., and J. Rabadan, «Virtual Private Wire Service Support in Ethernet VPN», RFC 8214, DOI 10.17487/RFC8214, August 2017, <https://www.rfc-editor.org/info/rfc8214>.

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

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

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

[W3C.REC-xml-20081126] Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., and F. Yergeau, «Extensible Markup Language (XML) 1.0 (Fifth Edition)», World Wide Web Consortium Recommendation REC-xml-20081126, November 2008, <https://www.w3.org/TR/2008/REC-xml-20081126>.

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

[EVPN-YANG] Brissette, P., Ed., Shah, H., Ed., Chen, I., Ed., Hussain, I., Ed., Tiruveedhula, K., Ed., and J. Rabadan, Ed., «Yang Data Model for EVPN», Work in Progress, draft-ietf-bess-evpn-yang-052, February 2018.

[IEEE-802-1ag] IEEE, «802.1ag — 2007 — IEEE Standard for Local and Metropolitan Area Networks — Virtual Bridged Local Area Networks Amendment 5: Connectivity Fault Management», DOI 10.1109/IEEESTD.2007.4431836.

[IEEE-802-1D] IEEE, «802.1D-2004 — IEEE Standard for Local and metropolitan area networks: Media Access Control (MAC) Bridges», DOI 10.1109/IEEESTD.2004.94569.

[IEEE-802-1Q] IEEE, «802.1Q — 2014 — IEEE Standard for Local and metropolitan area networks—Bridges and Bridged Networks», DOI 10.1109/IEEESTD.2014.6991462.

[IEEE-802-3ah] IEEE, «802.3ah — 2004 — IEEE Standard for Information technology— Local and metropolitan area networks— Part 3: CSMA/CD Access Method and Physical Layer Specifications Amendment: Media Access Control Parameters, Physical Layers, and Management Parameters for Subscriber Access Networks», DOI 10.1109/IEEESTD.2004.94617.

[ITU-T-Y-1731] International Telecommunication Union, «Operations, administration and maintenance (OAM) functions and mechanisms for Ethernet-based networks», ITU-T Recommendation Y.1731, August 2015, <https://www.itu.int/rec/T-REC-Y.1731/en>.

[MEF-6] Metro Ethernet Forum, «Ethernet Services Definitions — Phase 2», April 2008, <https://mef.net/PDF_Documents/technical-specifications/MEF6-1.pdf>.

[MPLS-L2VPN-YANG] Shah, H., Ed., Brissette, P., Ed., Chen, I., Ed., Hussain, I., Ed., Wen, B., Ed., and K. Tiruveedhula, Ed., «YANG Data Model for MPLS-based L2VPN», Work in Progress, draft-ietf-bess-l2vpn-yang-08, February 2018.

[RFC4119] Peterson, J., «A Presence-based GEOPRIV Location Object Format», RFC 4119, DOI 10.17487/RFC4119, December 2005, <https://www.rfc-editor.org/info/rfc4119>.

[RFC6624] Kompella, K., Kothari, B., and R. Cherukuri, «Layer 2 Virtual Private Networks Using BGP for Auto-Discovery and Signaling», RFC 6624, DOI 10.17487/RFC6624, May 2012, <https://www.rfc-editor.org/info/rfc6624>.

[RFC7130] Bhatia, M., Ed., Chen, M., Ed., Boutros, S., Ed., Binderberger, M., Ed., and J. Haas, Ed., «Bidirectional Forwarding Detection (BFD) on Link Aggregation Group (LAG) Interfaces», RFC 7130, DOI 10.17487/RFC7130, February 2014, <https://www.rfc-editor.org/info/rfc7130>.

[RFC7209] Sajassi, A., Aggarwal, R., Uttaro, J., Bitar, N., Henderickx, W., and A. Isaac, «Requirements for Ethernet VPN (EVPN)», RFC 7209, DOI 10.17487/RFC7209, May 2014, <https://www.rfc-editor.org/info/rfc7209>.

[RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, L., Sridhar, T., Bursell, M., and C. Wright, «Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks», RFC 7348, DOI 10.17487/RFC7348, August 2014, <https://www.rfc-editor.org/info/rfc7348>.

[RFC7436] Shah, H., Rosen, E., Le Faucheur, F., and G. Heron, «IP-Only LAN Service (IPLS)», RFC 7436, DOI 10.17487/RFC7436, January 2015, <https://www.rfc-editor.org/info/rfc7436>.

[RFC8199] Bogdanovic, D., Claise, B., and C. Moberg, «YANG Module Classification», RFC 8199, DOI 10.17487/RFC8199, July 2017, <https://www.rfc-editor.org/info/rfc8199>.

[RFC8299] Wu, Q., Ed., Litkowski, S., Tomotaki, L., and K. Ogaki, «YANG Data Model for L3VPN Service Delivery», RFC 8299, DOI 10.17487/RFC8299, January 2018, <https://www.rfc-editor.org/info/rfc8299>.

[RFC8309] Wu, Q., Liu, W., and A. Farrel, «Service Models Explained», RFC 8309, DOI 10.17487/RFC8309, January 2018, <https://www.rfc-editor.org/info/rfc8309>.

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

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

Спасибо Qin Wu и Adrian Farrel за содействие в работе над предварительными версиями документа. Спасибо Zonghe Huang, Wei Deng и Xiaoling Song за рецензирование этого документа.

Отдельная благодарность Jan Lindblad за внимательное рецензирование YANG.

Этот документ основан на работе группы L3SM, представленной в [RFC8299].

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

Bin Wen

Comcast

Email: bin_wen@comcast.com

Giuseppe Fioccola (редактор)

Telecom Italia

Email: giuseppe.fioccola@tim.it

Chongfeng Xie

China Telecom

Email: xiechf.bri@chinatelecom.cn

Luay Jalil

Verizon

Email: luay.jalil@verizon.com

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

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

nmalykh@protocols.ru

1Secure Shell.

2Имеется следующая версия документа https://tools.ietf.org/html/draft-ietf-bess-evpn-yang-06. Прим. перев.




RFC 8466 A YANG Data Model for Layer 2 Virtual Private Network (L2VPN) Service Delivery

Internet Engineering Task Force (IETF)                            B. Wen
Request for Comments: 8466                                       Comcast
Category: Standards Track                               G. Fioccola, Ed.
ISSN: 2070-1721                                           Telecom Italia
                                                                  C. Xie
                                                           China Telecom
                                                                L. Jalil
                                                                 Verizon
                                                            October 2018

A YANG Data Model for Layer 2 Virtual Private Network (L2VPN) Service Delivery

Модель данных YANG для предоставления услуг виртуальных сетей L2 (L2VPN)

PDF

Тезисы

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

Определенная в этом документе модель данных YANG включает услуги VPWS1 («точка-точка») и VPLS2 (многоточечные), которые используют псевдопровода с сигнализаций на основе протокола LDP3 и BGP4, как описано в RFC 4761 и RFC 6624.

Определенная здесь модель данных YANG соответствует архитектуре конфигурационных хранилищ NMDA5, определенной в RFC 8342.

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

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

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

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

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

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

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

Оглавление

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

1. Введение

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

Дополнительное рассмотрение способов моделирования услуг с помощью YANG и связей между «абонентскими моделями сервиса», подобными описанным здесь, и конфигурационными моделями можно найти в [RFC8309] и [RFC8199]. В разделах 4 и 6 приведена более подробная информация о способах применения этой модели сервиса и ее роли в общей архитектуре моделирования.

Определенная в этом документе модель YANG включает поддержку услуг VPWS (точка-точка) и VPLS (многоточечные), использующих псевдопровода с сигнализацией на основе протокола LDP и BGP, как описано в [RFC4761] и [RFC6624]. Модель соответствует архитектуре NMDA [RFC8342].

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

Ниже перечислены термины, определенные в [RFC6241] и используемые здесь:

  • client — клиент;

  • configuration data — данные конфигурации;

  • server — сервер;

  • state data — данные состояния.

Ниже перечислены термины, определенные в [RFC7950] и используемые здесь:

  • augment — добавление (усиление);

  • data model — модель данных;

  • data node — узел данных.

Терминология для описания моделей данных YANG заимствована из [RFC7950].

1.1.1. Уровни требований

Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не нужно (SHALL NOT), следует (SHOULD), не следует (SHOULD NOT), рекомендуется (RECOMMENDED), не рекомендуется (NOT RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе должны интерпретироваться в соответствии с BCP 14 [RFC2119] [RFC8174] тогда и только тогда, когда они набраны заглавными буквами, как показано здесь.

1.2. Диаграммы деревьев

Диаграммы деревьев в этом документе используют нотацию [RFC8340].

2. Определения

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

Service Provider (SP) — сервис-провайдер

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

Customer Edge (CE) Device — краевое устройство абонента

Оборудование, выделенное для конкретного абонента и напрямую подключенное к одному или нескольким устройствам PE через устройства (каналы) присоединения (AC8). Устройсва CE обычно размещаются на площадке абонента и как правило выделяются для одной сети VPN, хотя могут поддерживать и множество VPN, если для каждой применяется свое присоединение AC. Устройствами CE могут быть маршрутизаторы, мосты, коммутаторы или хосты.

Provider Edge (PE) Device — краевое устройство провайдера

Управляемое SP оборудование, способное поддерживать множество VPN для разных абонентов и напрямую соединенное с одним или множеством устройств CE через AC. Устройства PE обычно размещаются в точке присутствия SP POP9 и управляются SP.

Virtual Private LAN Service (VPLS) — услуги виртуальной частной ЛВС

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

Virtual Private Wire Service (VPWS) — услуги виртуального частного провода

VPWS представляет собой устройство «точка-точка» (т. е. канал), соединяющее два устройства CE. Канал организуется в форме логического соединения L2 через PSN. Устройства CE в сети абонента подключаются к PE в сети провайдера через AC, которые являются физическими или логическими устройствами (каналами). VPWS отличается от VPLS тем, что VPLS является многоточечным сервисом, а VPWS обеспечивает соединения «точка-точка». В некоторых реализациях набор VPWS служит для создания сети L2VPN с множеством сайтов.

Pseudowire (PW) — псевдопровод

Псевдопровод представляет собой эмуляцию естественного сервиса через PSN. Эмулируемым сервисом может быть ATM, Frame Relay, Ethernet, низкоскоростной канал TDM11 или SONET/SDH12, а сетью PSN — MPLS, IP (IPv4 или IPv6), L2TPv313.

MAC-VRF

Таблица виртуальной маршрутизации и пересылки для MAC14-адресов в PE. Иногда используется термин VSI15.

UNI

Интерфейс пользователя с сетью. Точка физического разделения между областями ответственности абонента и провайдера.

NNI

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

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

BSS

Business Support System — система поддержки бизнеса.

BUM

Broadcast, Unknown Unicast, or Multicast — групповые, неизвестные индивидуальные и широковещательные (кадры).

CoS

Class of Service — класс обслуживания.

LAG

Link Aggregation Group — группы объединенных каналов.

LLDP

Link Layer Discovery Protocol — протокол обнаружения канального уровня.

OAM

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

OSS

Operations Support System — система поддержки операций.

PDU

Protocol Data Unit — модуль данных протокола.

QoS

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

3. Модель сервиса L2 VPN

Сервис VPN уровня 2 (L2VPN16) представляет собой набор сайтов, уполномоченных обмениваться трафиком между собой через общую сетевую инфраструктуру на базе технологии общего назначения. Модель сервиса L2VPN (L2SM17), описанная в этом документе, обеспечивает базовое представление о развертывании соответствующих услуг L2VPN через инфраструктуру общего пользования.

Этот документ представляет L2SM на основе языка моделирования данных YANG [RFC7950] в качестве формального языка, понятного человеку и пригодного для разбора программами, использующими протоколы NETCONF18 [RFC6241] и RESTCONF [RFC8040].

Эта модель ограничена сетями VPN на основе VPWS и VPLS, как описано в [RFC4761] и [RFC6624], а также Ethernet VPN (EVPN), описанными в [RFC7432].

3.1. Типы сервиса L2 VPN

С точки зрения технологии базовые типы сервиса L2VPN включают:

  • VPWS «точка-точка», использующие псевдопровода с сигнализацией LDP или L2TP [RFC6074];

  • многоточечные VPLS, использующие псевдопровода с сигнализацией LDP или L2TP [RFC6074];

  • многоточечные VPLS, использующие уровень управления BGP, как описано в [RFC4761] и [RFC6624];

  • IPLS19, являющиеся функциональным подмножеством услуг VPLS [RFC7436];

  • EVPN на основе BGP MPLS, как описано в [RFC7432] и [RFC7209];

  • EVPN VPWS, как описано в [RFC8214].

3.2. Топология физической сети L2 VPN

На рисунке 1 показана физическая топология типовой сети SP. Большинство SP использует инфраструктуру с мультисервисным ядром IP, MPLS или сегментной маршрутизации (SR20). Входящие кадры L2 отображаются в псевдопровод Ethernet (например, PWE321) или туннель VXLAN22 между устройствами PE. Выбор механизмов туннелирования остается за провайдером и не является частью L2SM.

L2VPN обеспечивает сквозные соединения L2 через инфраструктуру мультисервисного ядра между двумя или более площадками абонента. Устройства AC размещаются между CE и PE, обеспечивая доставку кадров L2 из сети абонента через сеть доступа в провайдерскую сеть или на удаленный сайт. Граничная точка (т. е., UNI) между абонентом и SP может размещаться (1) между узлами абонента и устройством CE или (2) между устройствами CE и PE. Опорное соединение между CE и PE будет описано в L2SM.

SP может также выбрать модель «бесшовного MPLS» для создания туннеля PWE3 или VXLAN между сайтами.

SP может использовать MP-BGP23 для автоматического обнаружения и сигнализации конечных точек туннелей PWE3 или VXLAN.

          Сайт A  |                          | Сайт B
 ---     ----     |        VXLAN/PW          |               ---
|   |   |    |    |<------------------------>|              |   |
| C +---+ CE |    |                          |              | C |
|   |   |    |    |         ---------        |              |   |
 ---     ----\    |        (         )       |              /---
              \  -|--     (           )     -|--     ----  /
               \|    |   (    Сеть     )   |    |   |    |/
                | PE +---+ IP/MPLS/SR  +---+ PE +---+ CE |
               /|    |   (             )   |    |   |    |\
              /  ----     (           )     ----     ----  \
 ---     ----/             (         )                      \---
|   |   |    |              ----+----                       |   |
| C +---+ CE |                  |                           | C |
|   |   |    |                --+--                         |   |
 ---     ----                | PE  |                         ---
                              --+--
                                |      Сайт C
                              --+--
                             | CE  |
                              --+--
                                |
                              --+--
                             |  C  |
                              -----

Рисунок 1. Эталонная сеть для использования L2SM.


Однако с точки зрения абонента все устройства CE будут соединены через имитируемую среду ЛВС, как показано на рисунке 2. Широковещательные и групповые пакеты передаются всем участникам одного домена мостов.

CE---+----+-----+---CE
     |    |     |
     |    |     |
     |    |     |
CE---+    CE    +---CE

Рисунок 2. L2VPN с точки зрения абонента.


4. Использование модели данных сервиса

L2SM обеспечивает абстрактный интерфейс для запроса, настройки и управления компонентами сервиса L2VPN. Модель применяется абонентами, приобретающими соединения и другие услуги у SP, для коммуникаций с этим SP.

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

Настройка конфигурации элементов сети может выполняться через командный интерфейс (CLI25) или иной интерфейс настройки (южную границу — southbound), такой как NETCONF [RFC6241] в комбинации с определяемой устройством и протоколом моделью YANG.

Этот способ использования модели сервиса показан на рисунке 3, а более подробное описание приведено в [RFC8309] и [RFC8199]. Разделение функций оркестровки на уровне сервиса (service orchestrator) и сети (network orchestrator) разъяснено в [RFC8309]. Применение этой модели сервиса не исчерпывается представленным примером, она может использоваться любым компонентом системы управления, но не напрямую элементами сети.

Применение и структуру этой модели следует сравнивать с сервисной моделью L3 VPN, определенной в [RFC8299].

В Metro Ethernet Forum (MEF) [MEF-6] также была разработана архитектура работы сети и сетевого управления, но работа MEF охватывает все аспекты оркестровки жизненного цикла сервиса, включая оплату (billing), соглашения об уровне обслуживания (SLA26), управление заказами и жизненным циклом сервиса. Работа IETF над моделью сервиса обычно более компактна и предлагает простой, самодостаточный модуль YANG. Подробности см. в [RFC8309].

    ---------------------------------
   | Запрашивающее сервис устройство |
    ---------------------------------
           |
           |
     L2SM  |
           |
           |
         -----------------------
        |  Оркестровка сервиса  |
         -----------------------
           |
           |     Модель              +-------------+
           |     доставки    +------>|  Приложение |
           |     сервиса     |       |   BSS/OSS   |
           |                 V       +-------------+
         -----------------------
        |   Оркестровка сети    |
         -----------------------
           |            |
   +----------------+   |
   |Менеджер конфиг.|   |
   +----------------+   |  Модели
           |            |  устройств
           |            |
--------------------------------------------
                   Сеть
                              +++++++
                              + AAA +
                              +++++++

      ++++++++   Опорное   ++++++++           ++++++++      ++++++++
      + CE A + ----------- + PE A +           + PE B + ---- + CE B +
      ++++++++  соединение ++++++++           ++++++++      ++++++++

                 Сайт A                               Сайт B

Рисунок 3. Эталонная архитектура для использования L2SM.


5. Устройство модели данных

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

Модуль YANG разделен на два основных контейнера — услуги VPN (vpn-services) и сайты (sites). Контейнер vpn-svc в иерархии vpn-services определяет глобальные параметры сервиса VPN для конкретного абонента.

Сайт имеет по меньше мере одно подключение к сети (т. е. доступ сайта в сеть обеспечивающий связь и другими сайтами, как указано в параграфе 5.3.2) и может иметь множество подключений в многодомном случае. Подключение сайта к сети выполняется через опорное соединение (носитель — bearer) на канальном уровне (L2). «Носитель» относится к свойствам ниже уровня L2, а «соединение» к протокольным свойствам L2. Соединение-носитель может динамически выделяться SP, а абонент может задавать некоторые ограничения для управления местом соединения.

Полномочия на обмен трафиком предоставляются на основе политики или топологии VPN, которая определяет правила обмена маршрутной информацией между сайтами.

Сквозные многосегментные соединения могут быть реализованы на основе комбинации связности на уровне сайтов и сегментов.

На рисунке 4 показана общая структура модуля YANG.

   module: ietf-l2vpn-svc
   +--rw l2vpn-svc
     +--rw vpn-profiles
     |  +--rw valid-provider-identifiers
     |     +--rw cloud-identifier*  string{cloud-access}?
     |     +--rw qos-profile-identifier* string
     |     +--rw bfd-profile-identifier* string
     |     +--rw remote-carrier-identifier* string
     +--rw vpn-services
     |  +--rw vpn-service* [vpn-id]
     |     +--rw vpn-id                      svc-id
     |     +--rw vpn-svc-type?               identityref
     |     +--rw customer-name?              string
     |     +--rw svc-topo?                   identityref
     |     +--rw cloud-accesses {cloud-access}?
     |     |  +--rw cloud-access* [cloud-identifier]
     |     |     +--rw cloud-identifier
     |     |     |    -> /l2vpn-svc/vpn-profiles/
     |     |     |      valid-provider-identifiers/cloud-identifier
     |     |     +--rw (list-flavor)?
     |     |        +--:(permit-any)
     |     |        |  +--rw permit-any?         empty
     |     |        +--:(deny-any-except)
     |     |        |  +--rw permit-site*
     |     |        |  :    -> /l2vpn-svc/sites/site/site-id
     |     |        +--:(permit-any-except)
     |     |           +--rw deny-site*
     |     |                -> /l2vpn-svc/sites/site/site-id
     |     +--rw frame-delivery {frame-delivery}?
     |     |  +--rw customer-tree-flavors
     |     |  |  +--rw tree-flavor*   identityref
     |     |  +--rw bum-frame-delivery
     |     |  |  +--rw bum-frame-delivery* [frame-type]
     |     |  |     +--rw frame-type       identityref
     |     |  |     +--rw delivery-mode?   identityref
     |     |  +--rw multicast-gp-port-mapping    identityref
     |     +--rw extranet-vpns {extranet-vpn}?
     |     |  +--rw extranet-vpn* [vpn-id]
     |     |     +--rw vpn-id              svc-id
     |     |     +--rw local-sites-role?   identityref
     |     +--rw ce-vlan-preservation        boolean
     |     +--rw ce-vlan-cos-preservation    boolean
     |     +--rw carrierscarrier?            boolean {carrierscarrier}?
     +--rw sites
       +--rw site* [site-id]
        +--rw site-id                                string
        +--rw site-vpn-flavor?                       identityref
        +--rw devices
        |  +--rw device* [device-id]
        |     +--rw device-id     string
        |     +--rw location
        |     |    -> ../../../locations/location/location-id
        |     +--rw management
        |        +--rw transport?   identityref
        |        +--rw address?     inet:ip-address
        +--rw management
        |  +--rw type    identityref
        +--rw locations
        |  +--rw location* [location-id]
        |     +--rw location-id     string
        |     +--rw address?        string
        |     +--rw postal-code?    string
        |     +--rw state?          string
        |     +--rw city?           string
        |     +--rw country-code?   string
        +--rw site-diversity {site-diversity}?
        |  +--rw groups
        |     +--rw group* [group-id]
        |        +--rw group-id    string
        +--rw vpn-policies
        |  +--rw vpn-policy* [vpn-policy-id]
        |     +--rw vpn-policy-id    string
        |     +--rw entries* [id]
        |        +--rw id         string
        |        +--rw filters
        |        |  +--rw filter* [type]
        |        |     +--rw type       identityref
        |        |     +--rw lan-tag*   uint32 {lan-tag}?
        |        +--rw vpn* [vpn-id]
        |           +--rw vpn-id
        |           |    -> /l2vpn-svc/vpn-services/
        |           |            vpn-service/vpn-id
        |           +--rw site-role?   identityref
        +--rw service
        |  +--rw qos {qos}?
        |  |  +--rw qos-classification-policy
        |  |  |  +--rw rule* [id]
        |  |  |     +--rw id                   string
        |  |  |     +--rw (match-type)?
        |  |  |     |  +--:(match-flow)
        |  |  |     |  |  +--rw match-flow
        |  |  |     |  |     +--rw dscp?           inet:dscp
        |  |  |     |  |     +--rw dot1q?          uint16
        |  |  |     |  |     +--rw pcp?            uint8
        |  |  |     |  |     +--rw src-mac?        yang:mac-address
        |  |  |     |  |     +--rw dst-mac?        yang:mac-address
        |  |  |     |  |     +--rw color-type?     identityref
        |  |  |     |  |     +--rw target-sites*
        |  |  |     |  |     |               svc-id {target-sites}?
        |  |  |     |  |     +--rw any?            empty
        |  |  |     |  |     +--rw vpn-id?         svc-id
        |  |  |     |  +--:(match-application)
        |  |  |     |     +--rw match-application?   identityref
        |  |  |     +--rw target-class-id?     string
        |  |  +--rw qos-profile
        |  |     +--rw (qos-profile)?
        |  |        +--:(standard)
        |  |        |  +--rw profile?
        |  |        |       -> /l2vpn-svc/vpn-profiles/
        |  |        |              valid-provider-identifiers/
        |  |        |              qos-profile-identifier
        |  |        +--:(custom)
        |  |           +--rw classes {qos-custom}?
        |  |              +--rw class* [class-id]
        |  |                 +--rw class-id        string
        |  |                 +--rw direction?      identityref
        |  |                 +--rw policing?       identityref
        |  |                 +--rw byte-offset?    uint16
        |  |                 +--rw frame-delay
        |  |                 |  +--rw (flavor)?
        |  |                 |     +--:(lowest)
        |  |                 |     |  +--rw use-lowest-latency? empty
        |  |                 |     +--:(boundary)
        |  |                 |        +--rw delay-bound?     uint16
        |  |                 +--rw frame-jitter
        |  |                 |  +--rw (flavor)?
        |  |                 |     +--:(lowest)
        |  |                 |     |  +--rw use-lowest-jitter? empty
        |  |                 |     +--:(boundary)
        |  |                 |        +--rw delay-bound?     uint32
        |  |                 +--rw frame-loss
        |  |                 |  +--rw rate?   decimal64
        |  |                 +--rw bandwidth
        |  |                    +--rw guaranteed-bw-percent decimal64
        |  |                    +--rw end-to-end?           empty
        |  +--rw carrierscarrier {carrierscarrier}?
        |     +--rw signaling-type?   identityref
        +--rw broadcast-unknown-unicast-multicast {bum}?
        |  +--rw multicast-site-type?            enumeration
        |  +--rw multicast-gp-address-mapping* [id]
        |  |  +--rw id                 uint16
        |  |  +--rw vlan-id            uint16
        |  |  +--rw mac-gp-address     yang:mac-address
        |  |  +--rw port-lag-number?   uint32
        |  +--rw bum-overall-rate?     uint32
        |  +--rw bum-rate-per-type* [type]
        |     +--rw type    identityref
        |     +--rw rate?   uint32
        +--rw mac-loop-prevention {mac-loop-prevention}?
        |  +--rw protection-type?   identityref
        |  +--rw frequency?         uint32
        |  +--rw retry-timer?       uint32
        +--rw access-control-list
        |  +--rw mac* [mac-address]
        |     +--rw mac-address    yang:mac-address
        +--ro actual-site-start?   yang:date-and-time
        +--ro actual-site-stop?    yang:date-and-time
        +--rw bundling-type?       identityref
        +--rw default-ce-vlan-id   uint32
        +--rw site-network-accesses
           +--rw site-network-access* [network-access-id]
           +--rw network-access-id                 string
           +--rw remote-carrier-name?              string
           +--rw type?                             identityref
           +--rw (location-flavor)
           |  +--:(location)
           |  |  +--rw location-reference?
           |  |       -> ../../../locations/location/
           |  |               location-id
           |  +--:(device)
           |     +--rw device-reference?
           |          -> ../../../devices/device/device-id
           +--rw access-diversity {site-diversity}?
           |  +--rw groups
           |  |  +--rw group* [group-id]
           |  |     +--rw group-id    string
           |  +--rw constraints
           |     +--rw constraint* [constraint-type]
           |        +--rw constraint-type    identityref
           |        +--rw target
           |           +--rw (target-flavor)?
           |              +--:(id)
           |              |  +--rw group* [group-id]
           |              |     +--rw group-id    string
           |              +--:(all-accesses)
           |              |  +--rw all-other-accesses?   empty
           |              +--:(all-groups)
           |                 +--rw all-other-groups?     empty
           +--rw bearer
           |  +--rw requested-type {requested-type}?
           |  |  +--rw type?     string
           |  |  +--rw strict?   boolean
           |  +--rw always-on?         boolean {always-on}?
           |  +--rw bearer-reference?  string {bearer-reference}?
           +--rw connection
           |  +--rw encapsulation-type?    identityref
           |  +--rw eth-inf-type?          identityref
           |  +--rw tagged-interface
           |  |  +--rw type?               identityref
           |  |  +--rw dot1q-vlan-tagged {dot1q}?
           |  |  |  +--rw tg-type?    identityref
           |  |  |  +--rw cvlan-id    uint16
           |  |  +--rw priority-tagged
           |  |  |  +--rw tag-type?   identityref
           |  |  +--rw qinq {qinq}?
           |  |  |  +--rw tag-type?   identityref
           |  |  |  +--rw svlan-id    uint16
           |  |  |  +--rw cvlan-id    uint16
           |  |  +--rw qinany {qinany}?
           |  |  |  +--rw tag-type?   identityref
           |  |  |  +--rw svlan-id    uint16
           |  |  +--rw vxlan {vxlan}?
           |  |     +--rw vni-id       uint32
           |  |     +--rw peer-mode?   identityref
           |  |     +--rw peer-list* [peer-ip]
           |  |        +--rw peer-ip    inet:ip-address
           |  +--rw untagged-interface
           |  |  +--rw speed?                 uint32
           |  |  +--rw mode?                  neg-mode
           |  |  +--rw phy-mtu?               uint32
           |  |  +--rw lldp?                  boolean
           |  |  +--rw oam-802.3ah-link {oam-3ah}?
           |  |  |  +--rw enabled?   boolean
           |  |  +--rw uni-loop-prevention?   boolean
           |  +--rw lag-interfaces {lag-interface}?
           |  |  +--rw lag-interface* [index]
           |  |     +--rw index    string
           |  |     +--rw lacp {lacp}?
           |  |        +--rw enabled?           boolean
           |  |        +--rw mode?              neg-mode
           |  |        +--rw speed?             uint32
           |  |        +--rw mini-link-num?     uint32
           |  |        +--rw system-priority?   uint16
           |  |        +--rw micro-bfd {micro-bfd}?
           |  |        |  +--rw enabled?      enumeration
           |  |        |  +--rw interval?     uint32
           |  |        |  +--rw hold-timer?   uint32
           |  |        +--rw bfd {bfd}?
           |  |        |  +--rw enabled?      boolean
           |  |        |  +--rw (holdtime)?
           |  |        |     +--:(profile)
           |  |        |     |  +--rw profile-name?
           |  |        |     |    -> /l2vpn-svc/
           |  |        |     |         vpn-profiles/
           |  |        |     |        valid-provider-identifiers/
           |  |        |     |       bfd-profile-identifier
           |  |        |     +--:(fixed)
           |  |        |        +--rw fixed-value?    uint32
           |  |        +--rw member-links
           |  |        |  +--rw member-link* [name]
           |  |        |     +--rw name                string
           |  |        |     +--rw speed?              uint32
           |  |        |     +--rw mode?               neg-mode
           |  |        |     +--rw link-mtu?           uint32
           |  |        |     +--rw oam-802.3ah-link {oam-3ah}?
           |  |        |        +--rw enabled?  boolean
           |  |        +--rw flow-control?      boolean
           |  |        +--rw lldp?              boolean
           |  +--rw cvlan-id-to-svc-map* [svc-id]
           |  |  +--rw svc-id
           |  |  |    -> /l2vpn-svc/vpn-services/vpn-service/
           |  |  |           vpn-id
           |  |  +--rw cvlan-id* [vid]
           |  |     +--rw vid    uint16
           |  +--rw l2cp-control {l2cp-control}?
           |  |  +--rw stp-rstp-mstp?    control-mode
           |  |  +--rw pause?            control-mode
           |  |  +--rw lacp-lamp?        control-mode
           |  |  +--rw link-oam?         control-mode
           |  |  +--rw esmc?             control-mode
           |  |  +--rw l2cp-802.1x?      control-mode
           |  |  +--rw e-lmi?            control-mode
           |  |  +--rw lldp?             boolean
           |  |  +--rw ptp-peer-delay?   control-mode
           |  |  +--rw garp-mrp?         control-mode
           |  +--rw oam {oam}
           |     +--rw md-name         string
           |     +--rw md-level        uint16
           |     +--rw cfm-802.1-ag* [maid]
           |     |  +--rw maid                     string
           |     |  +--rw mep-id?                  uint32
           |     |  +--rw mep-level?               uint32
           |     |  +--rw mep-up-down?             enumeration
           |     |  +--rw remote-mep-id?           uint32
           |     |  +--rw cos-for-cfm-pdus?        uint32
           |     |  +--rw ccm-interval?            uint32
           |     |  +--rw ccm-holdtime?            uint32
           |     |  +--rw alarm-priority-defect?   identityref
           |     |  +--rw ccm-p-bits-pri?       ccm-priority-type
           |     +--rw y-1731* [maid]
           |        +--rw maid                           string
           |        +--rw mep-id?                        uint32
           |        +--rw type?                       identityref
           |        +--rw remote-mep-id?                 uint32
           |        +--rw message-period?                uint32
           |        +--rw measurement-interval?          uint32
           |        +--rw cos?                           uint32
           |        +--rw loss-measurement?              boolean
           |        +--rw synthetic-loss-measurement?    boolean
           |        +--rw delay-measurement
           |        |  +--rw enable-dm?   boolean
           |        |  +--rw two-way?     boolean
           |        +--rw frame-size?                    uint32
           |        +--rw session-type?               enumeration
           +--rw availability
           |  +--rw access-priority?   uint32
           |  +--rw (redundancy-mode)?
           |     +--:(single-active)
           |     |  +--rw single-active?     empty
           |     +--:(all-active)
           |        +--rw all-active?        empty
           +--rw vpn-attachment
           |  +--rw (attachment-flavor)
           |     +--:(vpn-id)
           |     |  +--rw vpn-id?
           |     |  |    -> /l2vpn-svc/vpn-services/
           |     |  |            vpn-service/vpn-id
           |     |  +--rw site-role?              identityref
           |     +--:(vpn-policy-id)
           |        +--rw vpn-policy-id?
           |             -> ../../../../vpn-policies/
           |                     vpn-policy/vpn-policy-id
           +--rw service
           |  +--rw svc-bandwidth {input-bw}?
           |  |  +--rw bandwidth* [direction type]
           |  |     +--rw direction    identityref
           |  |     +--rw type         identityref
           |  |     +--rw cos-id?      uint8
           |  |     +--rw vpn-id?      svc-id
           |  |     +--rw cir          uint64
           |  |     +--rw cbs          uint64
           |  |     +--rw eir?         uint64
           |  |     +--rw ebs?         uint64
           |  |     +--rw pir?         uint64
           |  |     +--rw pbs?         uint64
           |  +--rw svc-mtu            uint16
           |  +--rw qos {qos}?
           |  |  +--rw qos-classification-policy
           |  |  |  +--rw rule* [id]
           |  |  |     +--rw id                   string
           |  |  |     +--rw (match-type)?
           |  |  |     |  +--:(match-flow)
           |  |  |     |  |  +--rw match-flow
           |  |  |     |  |     +--rw dscp?           inet:dscp
           |  |  |     |  |     +--rw dot1q?          uint16
           |  |  |     |  |     +--rw pcp?            uint8
           |  |  |     |  |     +--rw src-mac?  yang:mac-address
           |  |  |     |  |     +--rw dst-mac?  yang:mac-address
           |  |  |     |  |     +--rw color-type?     identityref
           |  |  |     |  |     +--rw target-sites*
           |  |  |     |  |     |          svc-id {target-sites}?
           |  |  |     |  |     +--rw any?            empty
           |  |  |     |  |     +--rw vpn-id?         svc-id
           |  |  |     |  +--:(match-application)
           |  |  |     |     +--rw match-application? identityref
           |  |  |     +--rw target-class-id?     string
           |  |  +--rw qos-profile
           |  |     +--rw (qos-profile)?
           |  |        +--:(standard)
           |  |        |  +--rw profile?
           |  |        |       -> /l2vpn-svc/vpn-profiles/
           |  |        |              valid-provider-identifiers/
           |  |        |              qos-profile-identifier
           |  |        +--:(custom)
           |  |           +--rw classes {qos-custom}?
           |  |              +--rw class* [class-id]
           |  |                 +--rw class-id        string
           |  |                 +--rw direction?      identityref
           |  |                 +--rw policing?       identityref
           |  |                 +--rw byte-offset?    uint16
           |  |                 +--rw frame-delay
           |  |                 |  +--rw (flavor)?
           |  |                 |     +--:(lowest)
           |  |                 |     |  +--rw use-lowest-latency?
           |  |                 |     |                     empty
           |  |                 |     +--:(boundary)
           |  |                 |        +--rw delay-bound? uint16
           |  |                 +--rw frame-jitter
           |  |                 |  +--rw (flavor)?
           |  |                 |     +--:(lowest)
           |  |                 |     |  +--rw use-lowest-jitter?
           |  |                 |     |                     empty
           |  |                 |     +--:(boundary)
           |  |                 |        +--rw delay-bound? uint32
           |  |                 +--rw frame-loss
           |  |                 |  +--rw rate?   decimal64
           |  |                 +--rw bandwidth
           |  |                    +--rw guaranteed-bw-percent
           |  |                    |                    decimal64
           |  |                    +--rw end-to-end?       empty
           |  +--rw carrierscarrier {carrierscarrier}?
           |     +--rw signaling-type?   identityref
           +--rw broadcast-unknown-unicast-multicast {bum}?
           |  +--rw multicast-site-type?            enumeration
           |  +--rw multicast-gp-address-mapping* [id]
           |  |  +--rw id                 uint16
           |  |  +--rw vlan-id            uint16
           |  |  +--rw mac-gp-address     yang:mac-address
           |  |  +--rw port-lag-number?   uint32
           |  +--rw bum-overall-rate?               uint32
           |  +--rw bum-rate-per-type* [type]
           |     +--rw type    identityref
           |     +--rw rate?   uint32
           +--rw mac-loop-prevention {mac-loop-prevention}?
           |  +--rw protection-type?   identityref
           |  +--rw frequency?         uint32
           |  +--rw retry-timer?       uint32
           +--rw access-control-list
           |  +--rw mac* [mac-address]
           |     +--rw mac-address    yang:mac-address
           +--rw mac-addr-limit
           +--rw limit-number?    uint16
           +--rw time-interval?   uint32
           +--rw action?          identityref

Рисунок 4. Общая структура модуля YANG.

5.1. Свойства и их дополнение

Определенная в этом документе модель включает множество функций, которые обеспечивают возможность модульной реализации. Например, параметры L2 (параграф 5.3.2.2), предлагаемые абоненту, могут включаться и выключаться с помощью функций (возможностей). Модель также определяет некоторые возможности для расширенных опций, таких как поддержка Extranet VPN (параграф 5.2.4), разнородность сайтов (параграф 5.3) и QoS (параграф 5.10.2).

Как и многие другие модели YANG, данная модель может быть дополнена для реализации новых вариантов поведения или специальных возможностей. Например, эта модель определяет VXLAN [RFC7348] для инкапсуляции пакетов Ethernet и если инкапсуляция VXLAN не совсем удовлетворяет требования сервиса, можно реализовать новые опции путем дополнения.

5.2. Обзор сервиса VPN

Элемент списка vpn-service содержит базовую информацию о сервисе VPN. Элемент vpn-id в списке vpn-service задает внутреннюю ссылку для данного сервиса VPN. Этот идентификатор является внутренним для организации, отвечающей за поддержку сервиса VPN.

Список vpn-service содержит перечисленные ниже характеристики.

Информация абонента (customer-name)

Служит для идентификации абонента (заказчика).

Тип сервиса VPN (vpn-svc-type)

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

Доступ в облако (cloud-access)

Всем сайтам в L2VPN следует по умолчанию предоставлять доступ в облако. Контейнер cloud-access содержит правила предоставления полномочий. Для идентификации целевого сервиса служит указатель облака. Идентификатор является локальным для каждого домена администрирования.

Топология сервиса (svc-topo)

Служит для указания требуемой топологии сервиса VPN.

Служба доставки кадров (frame-delivery)

Определяет поддержку доставки кадров, требуемую для L2VPN, например, групповая, индивидуальная или широковещательная доставка.

Extranet VPN (extranet-vpns)

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

5.2.1. Тип сервиса VPN

Параметр vpn-svc-type определяет тип сервиса для предоставляемых провайдером услуг L2VPN. Текущая версия модели поддерживает шесть вариантов:

  • VPWS «точка-точка» для соединения двух сайтов абонента;

  • VPWS «точка-точка» или «точка-многоточка» для соединения множества сайтов абонента [RFC8214];

  • многоточечные VPLS для соединения множества сайтов абонента;

  • многоточечные VPLS для соединения одного или множества корневых сайтов с набором отделений (leaf site), но без связи между этими отделениями;

  • EVPN [RFC7432] для соединения множества сайтов абонента;

  • EVPN VPWS между двумя или множеством сайтов абонента, как указано в [RFC8214].

Другие типы сервиса L2VPN могут включаться через дополнения. Отметим, что сервис EPL27 или EVPL28 относится к типу E-Line29 [MEF-6] или EVC30, а сервис EP-LAN31 или EVP-LAN32 — к типу E-LAN33 [MEF-6] или многоточечному EVC.

5.2.2. Топология сервиса VPN

Рассматриваемые здесь типы топологии сервиса VPN могут при необходимости использоваться для настройки конфигурации. Описанный в документе модуль поддерживает полносвязные соединения (any-to-any), звезду (Hub-and-Spoke, где концентраторы могут обмениваться трафиком) и Hub-and-Spoke Disjoint (концентраторы не могут обмениваться трафиком). Новые варианты топологии могут быть реализованы в дополнениях. По умолчанию применяется топология any-to-any.

5.2.2.1. Выделение RT

Основанные на PE услуги L2 VPN (такие как VPLS и EVPN с применением BGP в качестве сигнального протокола) могут строиться с использованием целей маршрутов (RT34), как описано в [RFC4364] и [RFC7432]. Предполагается, что система управления автоматически выделяет набор RT при получении запроса на организацию сервиса VPN. Способ выделения RT системой управления выходит за рамки документа, но можно предусмотреть несколько вариантов, как описано в параграфе 6.2.1.1 [RFC8299].

5.2.2.2. Каждый с каждым (Any-to-Any)
+--------------------------------------------------------------+
|  VPN1_Site 1 ------ PE1               PE2 ------ VPN1_Site 2 |
|                                                              |
|  VPN1_Site 3 ------ PE3               PE4 ------ VPN1_Site 4 |
+--------------------------------------------------------------+

Рисунок 5. Топология сервиса Any-to-Any VPN.


В топологии сервиса VPN «any-to-any » все сайты VPN могут взаимодействовать между собой без ограничений. В этой модели предполагается, что система управления, получающая запрос на организацию сервиса any-to-any L2VPN, назначит, а затем настроит MAC-VRF и RT на соответствующих устройствах PE. Для полносвязной топологии в общем случае требуется одно значение RT и каждая таблица MAC-VRF импортирует и экспортирует это значение RT.

5.2.2.3. Концентратор и лучи (Hub-and-Spoke)
+---------------------------------------------------------------+
|   Hub_Site 1 ------ PE1               PE2 ------ Spoke_Site 1 |
|                          +------------------------------------+
|                          |
|                          +------------------------------------+
|   Hub_Site 2 ------ PE3               PE4 ------ Spoke_Site 2 |
+---------------------------------------------------------------+

Рисунок 6. Топология сервиса Hub-and-Spoke VPN.


В топологии сервиса VPN Hub-and-Spoke

  • все сайты-лучи (Spoke) могут взаимодействовать только с сайтами-концентраторами (Hub), т. е. лучи не могут взаимодействовать между собой;

  • концентраторы могут взаимодействовать между собой.

В этой модели предполагается, что система управления, получившая запрос на организацию сервиса Hub-and-Spoke L2VPN, назначит, а затем настроит MAC-VRF и RT на соответствующих устройствах PE. Для Hub-and-Spoke обычно нужны два значения RT (одно для Hub-маршрутов, другое для Spoke). Таблица Hub MAC-VRF, подключающая Hub-сайты, будет экспортировать Hub-маршруты с Hub RT и импортировать Spoke-маршруты через Spoke RT. Будут также импортироваться Hub RT для поддержки коммуникаций между Hub-сайтами. Таблица Spoke MAC-VRF, подключающая Spoke-сайты, будет экспортировать Spoke-маршруты со Spoke RT и импортировать Hub-маршруты через Hub RT.

5.2.2.4. Hub-and-Spoke Disjoint
+---------------------------------------------------------------+
|   Hub_Site 1 ------ PE1               PE2 ------ Spoke_Site 1 |
+--------------------------+  +---------------------------------+
                           |  |
+--------------------------+  +---------------------------------+
|   Hub_Site 2 ------ PE3               PE4 ------ Spoke_Site 2 |
+---------------------------------------------------------------+

Рисунок 7. Топология сервиса Hub-and-Spoke-Disjoint VPN.


В топологии сервиса VPN Hub-and-Spoke-Disjoint

  • все сайты-лучи (Spoke) могут взаимодействовать только с сайтами-концентраторами (Hub), т. е. лучи не могут взаимодействовать между собой;

  • концентраторы не могут взаимодействовать между собой.

В этой модели предполагается, что система управления, получившая запрос на организацию сервиса Hub-and-Spoke-Disjoint L2VPN назначит, а затем настроит VRF и RT для соответствующих устройств PE. В случае Hub-and-Spoke-Disjoint требуется по меньшей мере два значения RT (хотя бы одно для Hub-маршрутов и хотя бы одно для Spoke). Таблица Hub VRF, подключающая сайты Hub, будет экспортировать Hub-маршруты с RT и импортировать Spoke-маршруты через Spoke RT. Таблица Spoke VRF, подключающая сайты Spoke, будет экспортировать Spoke-маршруты со Spoke RT и импортировать Hub-маршруты через Hub RT.

Система управления должна учитывать ограничения для соединений Hub-and-Spoke как в предыдущем случае.

Топологию Hub-and-Spoke Disjoint можно рассматривать как множество Hub-and-Spoke VPN (одна сеть на Hub), использующих общий набор сайтов Spoke.

5.2.3. Доступ к облаку

Эта модель предполагает настройку доступа к облаку через контейнер cloud-access. Использование контейнера cloud-access нацелено на доступ к облачным службам общего пользования и в Internet. Контейнер cloud-access обеспечивает параметры правил предоставления полномочий. Отметим, что в этой модели предполагается некая общность доступа к облакам общего пользования и сети Internet, поэтому такие варианты доступа не различаются. При необходимости для доступа в Internet можно добавить отдельную метку путем дополнения.

Доступ к частным облакам можно организовать через контейнер site, как описано в параграфе 5.3, с использованием совместимого с сайтом типа интерфейса NNI.

Идентификатор облака служит для указания целевого сервиса. Этот идентификатор является локальным для административного домена.

По умолчанию всем сайтам в L2VPN следует разрешать доступ в облако или Internet. Если требуются ограничения, пользователь может настроить некоторые ограничения для отдельных сайтов или узлов с помощью правил, т. е. листа-списка permit-site или deny-site. Лист-список permit-site определяет список сайтов, имеющих полномочия для доступа к облаку, deny-site определяет сайты, которым доступ запрещен. Модель поддерживает варианты deny-any-except (запрет всем кроме …) и permit-any-except (разрешить всем кроме …).

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

          L2VPN
++++++++++++++++++++++++++++++++     ++++++++++++
+            Сайт 3            + --- + Облако 1 +
+ Сайт 1                       +     ++++++++++++
+                              +
+ Сайт 2                       + --- ++++++++++++
+                              +     + Internet +
+            Сайт 4            +     ++++++++++++
++++++++++++++++++++++++++++++++
             |
        ++++++++++++
        + Облако 2 +
        ++++++++++++

Рисунок 8. Пример конфигурации доступа в облако.


На рисунке 8 показан пример VPN с глобальным доступом в Internet путем создания контейнера cloud-access, указывающего идентификатор контейнера для доступа в Internet (см. приведенный ниже код XML [W3C.REC-xml-20081126]). Уполномоченных сайтов не задано, поскольку доступ в Internet нужен для всех сайтов.

    <?xml version="1.0"?>
       <l2vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l2vpn-svc">
       <vpn-services>
       <vpn-service>
       <vpn-id>123456487</vpn-id>
      <cloud-accesses>
       <cloud-access>
          <cloud-identifier>INTERNET</cloud-identifier>
       </cloud-access>
      </cloud-accesses>
      <ce-vlan-preservation>true</ce-vlan-preservation>
      <ce-vlan-cos-preservation>true</ce-vlan-cos-preservation>
      </vpn-service>
      </vpn-services>
    </l2vpn-svc>

Если Сайтам 1 и 2 нужно доступ в Облако 1, создается новый контейнер cloud-access с идентификатором Облака 1. Лист-список permit-site в нем указывает Сайты 1 и 2.

    <?xml version="1.0"?>
       <l2vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l2vpn-svc">
        <vpn-services>
         <vpn-service>
         <vpn-id>123456487</vpn-id>
         <cloud-accesses>
          <cloud-access>
            <cloud-identifier>Cloud1</cloud-identifier>
            <permit-site>site1</permit-site>
            <permit-site>site2</permit-site>
          </cloud-access>
         </cloud-accesses>
        <ce-vlan-preservation>true</ce-vlan-preservation>
        <ce-vlan-cos-preservation>true</ce-vlan-cos-preservation>
       </vpn-service>
       </vpn-services>
    </l2vpn-svc>

Если всем сайтам кроме Сайта 1 нужен доступ в Облако 2, создается контейнер cloud-access с идентификатором Облака 2, в котором лист-список deny-site указывает Сайт 1.

    <?xml version="1.0"?>
      <l2vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l2vpn-svc">
        <vpn-services>
         <vpn-service>
           <vpn-id>123456487</vpn-id>
            <cloud-accesses>
             <cloud-access>
              <cloud-identifier>Cloud2</cloud-identifier>
              <deny-site>site1</deny-site>
            </cloud-access>
           </cloud-accesses>
          <ce-vlan-preservation>true</ce-vlan-preservation>
          <ce-vlan-cos-preservation>true</ce-vlan-cos-preservation>
        </vpn-service>
      </vpn-services>
    </l2vpn-svc>

5.2.4. Сети Extranet VPN

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

            +-----------+           +-----------+
           /             \         /             \
Сайт A -- |    VPN A      |  ---  |    VPN B      | --- Сайт B
           \             /         \             /      (общие
            +-----------+           +-----------+        ресурсы)

Рисунок 9. Пример общего ресурса VPN.


Как показано на рисунке 9, VPN B имеет на Сайте B отдельные ресурсы, которые должны быть доступны некоторым абонентам/партнерам. В частности, для VPN A должен обеспечиваться доступ к этим ресурсам VPN B.

Такие варианты связи между VPN могут быть реализованы на основе политики VPN, как описано в параграфе 5.5.2.2. Однако в некоторых простых случаях отдельной сети VPN (VPN A) нужен доступ ко всем ресурсам другой VPN (VPN B). Модель обеспечивает простой способ такого соединения за счет использования контейнера extranet-vpns.

Контейнер extranet-vpns определяет список VPN, к которым заданная сеть VPN хочет получить доступ. Контейнеры extranet-vpns используются в абонентских VPN, требующих доступа к ресурсам других VPN. На рисунке 9 для предоставления VPN A доступа в VPN B нужно настроить контейнер extranet-vpns для VPN A с записью, соответствующей VPN B. Настроек сервиса для VPN B не требуется.

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

Лист site-role указывает роль локальных сайтов VPN в топологии сервиса extranet VPN. Определения ролей приведены в параграфе 5.4.

В приведенном ниже примере VPN A обращается к ресурсам VPN B через соединение extranet. Для сайтов VPN A нужна роль Spoke, поскольку этим сайтам не разрешается взаимодействовать между собой через соединение extranet.

     <?xml version="1.0"?>
       <l2vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l2vpn-svc">
        <vpn-services>
          <vpn-service>
            <vpn-id>VPNB</vpn-id>
              <svc-topo>hub-spoke</svc-topo>
             <ce-vlan-preservation>true</ce-vlan-preservation>
             <ce-vlan-cos-preservation>true</ce-vlan-cos-preservation>
          </vpn-service>
          <vpn-service>
             <vpn-id>VPNA</vpn-id>
               <svc-topo>any-to-any</svc-topo>
                  <extranet-vpns>
                    <extranet-vpn>
                     <vpn-id>VPNB</vpn-id>
                     <local-sites-role>spoke-role</local-sites-role>
                   </extranet-vpn>
                 </extranet-vpns>
             <ce-vlan-preservation>true</ce-vlan-preservation>
             <ce-vlan-cos-preservation>true</ce-vlan-cos-preservation>
         </vpn-service>
       </vpn-services>
      </l2vpn-svc>

Эта модель не определяет способов создания конфигурации extranet в сети.

В любом более сложном варианте соединений между VPN (например, доступ лишь некоторых сайтов VPN A только к некоторой части сайтов VPN B) требуется присоединение VPN, описанное в параграфе 5.5.2, и, в частности, политика VPN, описанная в параграфе 5.5.2.2.

5.2.5. Услуги доставки кадров

Если для L2VPN поддерживается доставка индивидуальных кадров с неизвестными адресами, а также групповых и широковещательных кадров (BUM), при запросе сервиса потребуется указать некоторые глобальные параметры доставки кадров. Когда CE передает пакеты BUM, на входном PE выполняется репликация и необходимо поддерживать три типа кадров.

Пользователи этой модели должны обеспечить варианты деревьев, которые будут применяться абонентами в L2VPN (customer-tree-flavors). Определенная в документе модель поддерживает двунаправленные (bidirectional), совместно используемые (shared) и основанные на источнике (source-based) деревья, а с помощью дополнений могут поддерживаться другие типы. Одновременно может использоваться множество типов деревьев.

                          Сеть оператора
                          ______________
                         /              \
                        |                |
                        |                |
Recv -- Сайт 2 ------- PE2               |
                        |               PE1 --- Сайт 1 --- Источник 1
                        |                |        \
                        |                |         -- Источник 2
                        |                |
                        |                |
Recv -- Сайт 3 ------- PE3               |
                        |                |
                        |                |
Recv -- Сайт 4 ------- PE4               |
                      / |                |
Recv -- Сайт 5 -------  |                |
                        |                |
                        |                |
                         \______________/

Рисунок 10. Пример услуг доставки кадров BUM.


Отображения multicast-групп на порты могут быть созданы с использованием листа rp-group-mappings. Поддерживается два метода отображения:

  • статическая настройка групповых адресов Ethernet и портов (интерфейсов);

  • протокол управления групповой адресацией на основе технологии L2, обеспечивающей сигнализацию сопоставления групповых адресов с портами (интерфейсами), такой как GARP35/GMRP36 [IEEE-802-1D].

5.3. Обзор сайтов

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

                                               +-------------+
                                              /               \
                                       +-----|      VPN1       |
+------------------+                   |      \               /
|                  |                   |       +-------------+
| Офис в Нью-Йорке |------ (сайт) -----+
|                  |                   |       +-------------+
+------------------+                   |      /               \
                                       +-----|      VPN2       |
                                              \               /
                                               +-------------+

Рисунок 11. Офис абонента с двумя услугами VPN.


Провайдер использует контейнер site для хранения информации с подробным описанием соглашений с абонентом или операторами-партнерами для каждой точки присоединения (interconnect location).

Мы ограничиваем L2SM внешними интерфейсами (т. е. интерфейсами UNI и NNI), поскольку внутренние интерфейсы и базовая топология выходят за рамки L2SM.

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

Уникальный идентификатор (site-id)

Произвольная строка, однозначно указывающая сайт в общей сетевой инфраструктуре. Формат site-id определяется локальным администратором сервиса VPN.

Устройство (device)

Абонент может запросить подключение одного или множества устройств CPE к SP для отдельного сайта.

Управление (management)

Определяет модель управления для сайта. Например, тип, транспорт системы управления, адрес. Эти параметры задают границу между SP и абонентом, т. е. владение устройством CE.

Местоположение (location)

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

Отличия сайта (site-diversity)

Представляет те или иные параметры для поддержки разнообразных сайтов.

Доступ сайта к сети (site-network-accesses)

Указывает список портов для сайта и их свойства, в частности параметры носителя (bearer), соединения и сервиса.

Объект site-network-access представляет логическое соединение Ethernet для сайта. Сайт может иметь множество site-network-access.

+------------------+             Сайт
|                  |-------------------------------------
|                  |****** (site-network-access#1) ******
| Офис в Нью-Йорке |
|                  |****** (site-network-access#2) ******
|                  |-------------------------------------
+------------------+

Рисунок 12. Два объекта Site-Network-Access для сайта.


Множество site-network-access используется, например, при многодомных подключениях и в некоторых других случаях.

Конфигурация сайта представляется глобальным элементом, предполагается, что роль системы управления заключается в разделении параметров между разными элементами внутри сети. Например, в случае конфигурации site-network-access система управления должна разделить параметры конфигурации между устройствами PE и CE.

Сайт может иметь однодомное или многодомное подключение. Во втором случае сайт может поддерживать множество site-network-access, в каждом из которых определяется элемент vpn-attachment (подключение к VPN), связывающий site-network-access с данным сайтом, а также указывающий сеть VPN, к которой сайт будет подключен.

5.3.1. Устройства и площадки

Информация в субконтейнере location контейнера site и в контейнере devices позволяет легко отыскать данные о ближайших доступных точках подключения и может применяться для планирования топологии доступа. Она может также использоваться другими компонентами оркестровки сети для выбора восходящего PE и нисходящего CE. Местоположение указывается в терминах почтовой адресации. Более подробные сведения о месте расположения можно указать с помощью дополнений.

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

  Сайт в Нью-Йорке
+------------------+             Сайт
| +--------------+ |-------------------------------------
| | Манхэттен    | |****** (site-network-access#1) ******
| +--------------+ |
| +--------------+ |
| | Бруклин      | |****** (site-network-access#2) ******
| +--------------+ |-------------------------------------
+------------------+

Рисунок 13. Два сайта, два Site-Network-Access.


Абонент может также запросить использование некоторых элементов оборудования (CE) у SP через контейнер devices. Для запрашиваемых CE предполагается управление со стороны провайдера или совместное управление. Может быть запрошено конкретное устройство для конкретной, уже включенной в конфигурацию площадки. Это позволит SP отправить устройство по указанному почтовому адресу. Для сайта с множеством площадок абонент может, например, запросить CE на каждую площадку, где требуется многодомное подключение. В примере на рисунке 13 одно устройство может быть запрошено для площадки на Манхэттене, другое — для площадки в Бруклине.

Используя контейнеры devices и locations, абонент может влиять на организацию многодомного подключения — одно устройство CE, два CE и т. д.

5.3.2. Доступ сайта в сеть

L2SM включает важный набор свойств физических интерфейсов и характеристик уровня Ethernet в контейнере site-network-accesses. Некоторые из них являются важными параметрами реализации, которые должны быть согласованы между абонентом и провайдером.

Как отмечено выше, сайт может быть многодомным. Каждое логическое подключение для сайта определяется контейнером site-network-accesses. Параметр site-network-access определяет способ подключения сайта к сети и включает три основных класса параметров:

  • bearer определяет требования к подключению (ниже уровня L2);

  • connection определяет параметры L2 для подключения;

  • availability определяет политику доступности сайта в соответствии с определениями параграфа 5.8.

Параметр site-network-access имеет конкретный тип. Данный документ определяет 2 типа:

  • point-to-point — соединение типа «точка-точка» между SP и абонентом;

  • multipoint — многоточечное соединение между SP и абонентом.

Тип site-network-access может влиять на параметры, предлагаемые абоненту. Например, SP может не предлагать предоставление защиты от петель MAC при многоточечном доступе. Провайдер сам принимает решение о поддерживаемых параметрах доступа для point-to-point и/или multipoint. Многоточечный доступ выходит за рамки документа. Некоторые контейнеры, определенные в этой модели, могут потребовать расширения для корректной работы при многоточечном доступе.

5.3.2.1. Контейнер bearer

Контейнер bearer определяет требования для подключения сайта (ниже уровня L2) к сети провайдера.

Параметры bearer помогают определить тип используемой для доступа среды передачи.

5.3.2.2. Контейнер connection

Контейнер connection определяет протокольные параметры L2 для подключения (например, vlan-id или circuit-id) и обеспечивают связность между абонентскими коммутаторами Ethernet. В зависимости от режима управления они относятся к адресации сегмента «PE-CE-ЛВС» или «CE-ЛВС абонента». В любом случае они описывают границу разделения ответственности между абонентом и провайдером. Для управляемого абонентом сайта параметры относятся к сегменту соединения «PE-CE-ЛВС», а для управляемого провайдером — к сегменту «CE-ЛВС абонента».

Параметр encapsulation-type позволяет абоненту выбрать инкапсуляцию Ethernet (доступ по портам) или Ethernet VLAN (доступ по VLAN). Все разрешенные типом интерфейса Ethernet (например, с тегами, без тегов, LAG) сервисные кадры могут быть указаны в ether-inf-type.

В соответствии с ether-inf-type контейнер connection представляет также три набора атрибутов канала для интерфейсов с тегами и без тегов, а также необязательного интерфейса LAG. Эти параметры важны для корректной организации соединения между устройствами CE и PE. Контейнер connection определяет также атрибут L2CP37, обеспечивающий протокольное взаимодействие на уровне управления между устройствами CE и PE.

5.3.2.2.1. Интерфейс без тегов

Для каждого интерфейса без тегов (untagged-interface) имеются базовые параметры, такие как индекс и скорость, MTU, настройки автосогласования и управления потоком данных и т. п. В дополнение к этому на основе взаимного соглашения между абонентом и провайдером могут указываться дополнительные возможности — LLDP, IEEE 802.3ah [IEEE-802-3ah] или обнаружение/предотвращение петель MAC на интерфейсе UNI. Если требуется предотвращение петель, для атрибута uni-loop-prevention должно быть установлено значение true.

5.3.2.2.2. Интерфейс с тегами

Если на логическом модуле соединения для интерфейса включены услуги с тегами, в качестве encapsulation-type следует указывать инкапсуляцию Ethernet VLAN (при работе на основе VLAN) или VXLAN, а также следует установить в eth-inf-type индикацию использования тегов.

В дополнение к этому следует указать tagged-interface-type в контейнере tagged-interface для задания режима использования тегов. Текущая модель определяет пять режимов установки тегов VLAN:

  • priority-tagged — SP инкапсулируют и помечают пакеты между CE и PE уровнем приоритета для кадра;

  • dot1q-vlan-tagged — SP инкапсулируют пакеты между CE и PE с одним или множеством абонентских идентификаторов VLAN (CVLAN38);

  • qinq — SP инкапсулируют пакеты на входе в свои сети с множеством идентификаторов CVLAN и одним тегом SP VLAN (SVLAN);

  • qinany — SP инкапсулируют пакеты на входе в свои сети с неизвестными CVLAN и одним тегом SVLAN;

  • vxlan — SP инкапсулирует пакеты на входе в свои сети и идентификатором VNI39 и списком партнеров.

Общий S-tag для устройства Ethernet и (если применимо) отображение C-tag на SVC40 помещаются в контейнер service. Для вариантов qinq и qinany значению S-tag в qinq и qinany в большинстве случаев следует соответствовать значению S-tag в контейнере service, однако в некоторых системах требуется трансляция VLAN для S-tag на обращенном наружу интерфейсе или восходящих PE для «нормализации» внешнего тега VLAN в S-tag сервиса на входе в сеть и обратной трансляции в S-tag при выходе из сети. Одним из примеров является агрегирующий коммутатор L2 на пути — S-tag для SVC ранее был назначен другому сервису и не может использоваться этим AC.

5.3.2.2.3. Интерфейс LAG

Иногда абонентам может потребоваться сборка множества физических каналов в одно логическое соединение LAG (точка-точка) с SP. Обычно на таких соединения применяется протокол LACP41 для динамического добавления или удаления каналов в группу-агрегат. В общем случае LAG позволяет расширить пропускную способность сервиса по сравнению с одиночным каналом, обеспечивая аккуратное снижение пропускной способности при отказе канала в группе, а также повышение уровня доступности.

В L2SM имеется набор атрибутов (под lag-interface), связанных с агрегированием каналов. Абонент и провайдер сначала должны решить, будет ли выполняться обмен LACP PDU между краевыми устройствами, и выбрать для LACP-state значение on или off. При включенном протоколе LACP обе стороны должны указать, (1) будет LACP работать в пассивном или активном режиме и (2) задать временной интервал и уровень приоритета для LACP PDU. Абонент и провайдер могут также определить минимальную пропускную способность агрегата LAG, которая считается допустимой, путем задания необязательного атрибута mini-link-num. Для включения быстрого детектирования отказов на каналах через независимые сессии UDP работает микро-BFD42 [RFC7130] для мониторинга состояния каждого канала в группе. Абоненту и провайдеру следует согласовать интервал BFD hello и время удержания.

Каждый канал группы указывается под интерфейсом LAG с базовыми свойствами физического канала. Некоторые атрибуты, такие как управление потоком данных, тип инкапсуляции, разрешенные Ethertype на входе и установки LLDP задаются на уровне LAG.

5.3.2.2.4. Отображение CVLAN-ID на SVC

Когда более одного сервиса мультиплексируется в один интерфейс, входящие кадры передаются в один из экземпляров сервиса L2VPN в соответствии с заранее согласованным сопоставлением абонентских VLAN с SVC. Множество CVLAN может передаваться через один канал SVC. Тип группировки будет определять связывание множества CVLAN в одном экземпляре сервиса VPN (т. е. группировку VLAN).

Когда это применимо, отображение cvlan-id-to-svc-map содержит список CVLAN, отображенных на один сервис. В большинстве случаев это будет списком доступа по VLAN из внутреннего тега 802.1Q [IEEE-802-1Q] (C-tag).

Сервис VPN можно настроить на сохранение CE-VLAN ID и CE-VLAN CoS от сайта-источника до сайта-получателя. Это нужно в тех случаях, когда абонент хочет использовать информацию из заголовка VLAN на обоих сайтах. Сохранение CE-VLAN ID и CE-VLAN CoS применяется в каждом site-network-access на сайтах. Это сохранение означает, что CE-VLAN ID и/или CE-VLAN CoS на стороне отправителя должны совпадать со значениями этих полей на стороне сайта-получателя, относящегося к тому же сервису L2VPN.

Если разрешена группировка для всех сайтов (тип группировки all-to-one), сохранение применяется для всех входящих кадров сервиса. Если группировка не включена, сохранение применяется для входящих кадров с тегом CE-VLAN ID.

5.3.2.2.5. Поддержка управления L2CP

Абоненту и SP следует заранее согласовать вопрос разрешения протокольных взаимодействий между CE и PE на уровне управления. Для обеспечения эффективной доставки группового трафика абоненты могут применять протоколы управления Ethernet (например, STP43 [IEEE-802-1D]).

Для поддержки эффективной динамической доставки могут использоваться кадры управления групповой передачей Ethernet (например, GARP/GMRP [IEEE-802-1D]) между устройствами CE и PE. Однако недопустимо предполагать, что все CE всегда используют такие протоколы (например, CE может быть маршрутизатором или не знать деталей L2).

MAC-адреса получателей в L2CP PDU относятся к двум резервным блокам, заданным рабочей группой IEEE 802.1. Для пакетов с MAC-адресом получателя из указанных ниже групповых диапазонов применяются особые правила пересылки.

  • Протоколы мостов — 01-80-C2-00-00-00 — 01-80-C2-00-00-0F.

  • Протоколы MRP — 01-80-C2-00-00-20 — 01-80-C2-00-00-2F.

Туннелирование протоколов L2 позволяет SP передавать абонентские L2 PDU через сеть без интерпретации и обработки на промежуточных устройствах. Эти L2CP PDU инкапсулируются с использованием QinQ для передачи через ядро сети с поддержкой MPLS.

Контейнер L2CP-control содержит список обычно используемых протоколов и параметров L2CP. SP может задать для каждого отдельного протокола режим отбрасывания (discard-mode), партнерства (peer-mode) или туннелирования (tunnel-mode).

5.3.2.2.6. Ethernet Service OAM

Применение Ethernet в качестве технологии распределенных сетей предъявляет дополнительные требования к сквозному мониторингу сервиса и контролю отказов в сетях SP, особенно в части доступности сервиса и среднего времени восстановления (MTTR44). Ethernet Service OAM в контексте L2SM означает комбинацию протоколов IEEE 802.1ag [IEEE-802-1ag] и ITU-T Y.1731 [ITU-T-Y-1731].

Вообще говоря, Ethernet Service OAM позволяет SP проверять непрерывность предоставления услуг, изолировать отказы, измерять задержки и их вариации на уровне абонента и доступа сайта в сеть. Информация Ethernet Service OAM дополняет данные других инструментов верхних уровней IP/MPLS OSS для обеспечения SLA.

Функциональная модель обработки отказов 802.1ag CFM45 структурирована в иерархические домены MD46, каждому из которых назначается уникальный уровень обслуживания. MD верхних уровней могут быть вложены в MD нижних уровней, однако домены MD не могут пересекаться. Область действия каждого домена MD полностью находится в сети абонента или сети SP. Домены MD могут взаимодействовать между CE и PE (от абонента к провайдеру) или между PE (взаимодействие провайдеров), а также могут туннелироваться через другую сеть SP.

В зависимости от варианта применения несколько точек MEP47 может размещаться на обращенном наружу интерфейсе, передавая CFM PDU в направлении ядра сети (Up MEP) или в нисходящий канал (Down MEP).

Субконтейнер cfm-802.1-ag в контейнере site-network-access представляет ассоциацию обслуживания CFM MA48, т. е. Down MEP для UNI MA. Для каждой ассоциации MA пользователь может задать идентификатор MAID49, уровень и направление MEP, Remote MEP ID, уровень CoS для CFM PDU, интервал и время удержания сообщений проверки связности (CCM50), уровень генерации сигналов об отказе (т. е. самый низкий приоритет, при котором генерируется сигнал об отказе), тип приоритета CCM и т. п.

Мониторинг производительности ITU-T Y.1731 (PM51) обеспечивает важную телеметрическую информацию, которая включает задержку кадров Ethernet и ее вариации, потери кадров и пропускную способность для кадров. Измерения задержки и ее вариаций могут выполняться в одном или обоих направлениях. Обычно зонд Y.1731 PM передает небольшое число синтетических кадров вместе с обычными кадрами для измерения параметров SLA.

Субконтейнер y-1731 в контейнере site-network-access содержит набор данных для определения параметров зонда PM, включая MAID, локальный и удаленный идентификатор MEP ID, тип PM PDU, период сообщений и интервал измерения, уровень CoS для PM PDU, опции измерения по синтетическим или естественным кадрам, одно или два направления для измерений, размер кадров PM и тип сессии.

5.4. Роли сайта

Сервис VPN имеет определенную топологию, как описано в параграфе 5.2.2. В результате каждому сайту, относящемуся к VPN, назначается в этой топологии определенная роль. Лист site-role указывает роль сайта в конкретной топологии VPN.

В топологии any-to-any (каждый с каждым) все сайты должны играть одну роль — any-to-any-role.

В топологии Hub-and-Spoke или Hub-and-Spoke-Disjoint сайты должны играть роль Hub или Spoke.

5.5. Сайты, входящие в несколько VPN

5.5.1. Варианты VPN на сайте

Сайт может входить в одну или множество сетей VPN и site-vpn-flavor указывает способ мультиплексирования VPN. Возможны 4 типа обращенных наружу соединений, связанных с сервисом EVPN и сайтом. Поэтому модель поддерживает четыре варианта:

  • site-vpn-flavor-single — сайт входит в единственную сеть VPN;

  • site-vpn-flavor-multi — сайт включен во множество VPN и все логические соединения сайтов относятся к одному набору VPN;

  • site-vpn-flavor-nni — сайт представляет интерфейс NNI, где соединяются два административных домена, относящихся к одному или разным провайдерам;

  • site-vpn-flavor-e2e — сайт представляет сквозное многосегментное соединение.

5.5.1.1. Одно подключение — site-vpn-flavor-single

На рисунке 14 показано подключение сайта к одной сети VPN.

                                                   +--------+
+------------------+             Сайт             /          \
|                  |-----------------------------|            |
|                  |***(site-network-access#1)***|    VPN1    |
| Офис в Нью-Йорке |                             |            |
|                  |***(site-network-access#2)***|            |
|                  |-----------------------------|            |
+------------------+                              \          /
                                                   +--------+

Рисунок 14. Одно подключение к VPN.


5.5.1.2. Множество подключений — site-vpn-flavor-multi

На рисунке 15 показано подключение сайта к множеству VPN.

                                                        +---------+
                                                   +---/----+      \
+------------------+             Сайт             /   |      \      |
|                  |--------------------------------- |       |VPN B|
|                  |***(site-network-access#1)******* |       |     |
| Офис в Нью-Йорке |                             |    |       |     |
|                  |***(site-network-access#2)*******  \      |    /
|                  |-----------------------------| VPN A+-----|---+
+------------------+                              \          /
                                                   +--------+

Рисунок 15. Подключение к множеству VPN.


Офис в Нью-Йорке на рисунке 15 является многодомным. Для обоих логических соединений применяются одинаковые правила подключения к VPN и оба соединения относятся к VPN A и VPN B.

Доступ к VPN A или VPN B из офиса в Нью-Йорке выполняется на основе пересылки по MAC-адресу получателя. Возможность доступа к одному адресату из двух VPN может создавать проблемы маршрутизации. В этом случае роль администратора абонентской сети заключается в подходящем отображении MAC-адресов каждой VPN. Более подробное описание приведено в параграфах 5.5.2 и 5.10.2, а поддержка BUM рассмотрена в параграфе 5.10.3.

5.5.1.3. NNI — site-vpn-flavor-nni

Вариант с межсетевым соединением (NNI) можно промоделировать, используя контейнер sites. Для SP полезно указать, что запрашиваемое соединение VPN не относится к обычному сайту, а является NNI, поскольку в этом случае могут по умолчанию применяться другие параметры конфигурации (например, ACL52, правила маршрутизации).

         SP A                                         SP B
  -------------------                         -------------------
 /                   \                       /                   \
|                     |                     |                     |
|                 ++++++++Канал между AS ++++++++                 |
|                 +      +_______________+      +                 |
|                 + (MAC-VRF1)-(VPN1)-(MAC-VRF1)+                 |
|                 +      +               +      +                 |
|                 + ASBR +               + ASBR +                 |
|                 +      +               +      +                 |
|                 + (MAC-VRF2)-(VPN2)-(MAC-VRF2)+                 |
|                 +      +_______________+      +                 |
|                 ++++++++               ++++++++                 |
|                     |                     |                     |
|                     |                     |                     |
|                     |                     |                     |
|                 ++++++++Канал между AS ++++++++                 |
|                 +      +_______________+      +                 |
|                 + (MAC-VRF1)-(VPN1)-(MAC-VRF1)+                 |
|                 +      +               +      +                 |
|                 + ASBR +               + ASBR +                 |
|                 +      +               +      +                 |
|                 + (MAC-VRF2)-(VPN2)-(MAC-VRF2)+                 |
|                 +      +_______________+      +                 |
|                 ++++++++               ++++++++                 |
|                     |                     |                     |
|                     |                     |                     |
 \                   /                       \                   /
  -------------------                         -------------------

Рисунок 16. Сценарий NNI, вариант A.


На рисунке 16 показан вариант A сценария NNI, который можно смоделировать с помощью контейнера sites. Для подключения абонентских VPN (VPN1 и VPN2) к сети SP B провайдер SP A может запросить создание того или иного контейнера site-network-accesses для сети SP B. Можно использовать тип site-vpn-flavor-nni для информирования SP B о том, что это соединение NNI, а не обычное подключение абонента.

5.5.1.4. E2E — site-vpn-flavor-e2e

Сквозное (E2E53) многосегментное соединение VPN организуется из нескольких соединительных сегментов. Для SP будет полезно указать, что запрошенное соединение VPN не является обычным подключением сайта, а служит сквозным соединением VPN, поскольку в случае site-vpn-flavor-e2e по умолчанию могут применяться другие параметры (например, конфигурация QoS). Для организации соединения между Сайтом 1 в SP A и Сайтом 2 в SP B через множество доменов провайдер SP A может запросить организацию сквозного соединения с SP B. Тип site-vpn-flavor-e2e позволяет указать, что это сквозное соединение, а не обычное подключение абонентского сайта.

5.5.2. Присоединение сайта к VPN

По причине наличия множества вариантов site-vpn присоединение сайта к L2VPN выполняется на уровне site-network-access (логический доступ) через контейнер vpn-attachment, который является обязательным. Модель обеспечивает два способа присоединения сайта к VPN:

  • по непосредственной ссылке на целевую сеть VPN;

  • по ссылке на правила присоединения к VPN, которые могут быть более сложными.

Эти опции позволяют пользователю выбрать наиболее подходящий вариант.

5.5.2.1. Указание VPN

Указание vpn-id обеспечивает простой способ привязать конкретное логическое соединение к VPN. Это является лучшим способом для VPN с одним подключением. При указании vpn-id должна добавляться роль сайта (site-role) в топологии целевого сервиса VPN.

    <?xml version="1.0"?>
    <l2vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l2vpn-svc">
     <vpn-services>
        <vpn-service>
          <vpn-id>VPNA</vpn-id>
          <ce-vlan-preservation>true</ce-vlan-preservation>
          <ce-vlan-cos-preservation>true</ce-vlan-cos-preservation>
        </vpn-service>
        <vpn-service>
          <vpn-id>VPNB</vpn-id>
          <ce-vlan-preservation>true</ce-vlan-preservation>
          <ce-vlan-cos-preservation>true</ce-vlan-cos-preservation>
        </vpn-service>
     </vpn-services>
     <sites>
       <site>
        <site-id>SITE1</site-id>
       <locations>
        <location>
         <location-id>L1</location-id>
        </location>
       </locations>
       <management>
        <type>customer-managed</type>
          </management>
           <site-network-accesses>
            <site-network-access>
             <network-access-id>LA1</network-access-id>
                <service>
                  <svc-bandwidth>
                     <bandwidth>
                       <direction>input-bw</direction>
                        <type>bw-per-cos</type>
                         <cir>450000000</cir>
                         <cbs>20000000</cbs>
                         <eir>1000000000</eir>
                         <ebs>200000000</ebs>
                     </bandwidth>
                    </svc-bandwidth>
                     <carrierscarrier>
                       <signaling-type>bgp</signaling-type>
                     </carrierscarrier>
                     <svc-mtu>1514</svc-mtu>
                   </service>
            <vpn-attachment>
             <vpn-id>VPNA</vpn-id>
             <site-role>spoke-role</site-role>
            </vpn-attachment>
           </site-network-access>
           <site-network-access>
            <network-access-id>LA2</network-access-id>
                <service>
                  <svc-bandwidth>
                     <bandwidth>
                       <direction>input-bw</direction>
                        <type>bw-per-cos</type>
                         <cir>450000000</cir>
                         <cbs>20000000</cbs>
                         <eir>1000000000</eir>
                         <ebs>200000000</ebs>
                     </bandwidth>
                    </svc-bandwidth>
                     <carrierscarrier>
                       <signaling-type>bgp</signaling-type>
                     </carrierscarrier>
                     <svc-mtu>1514</svc-mtu>
                   </service>
            <vpn-attachment>
             <vpn-id>VPNB</vpn-id>
             <site-role>spoke-role</site-role>
            </vpn-attachment>
           </site-network-access>
          </site-network-accesses>
      </site>
     </sites>
    </l2vpn-svc>

Приведенный выше пример описывает случай множества VPN, где сайт (SITE1) имеет два логических подключения (LA1 и LA2) к сетям VPNA и VPNB.

5.5.2.2. Политика VPN

Список vpn-policy позволяет описать вариант с множеством VPN, где логические подключения относятся к разным VPN.

Поскольку сайт может входить в несколько VPN, список vpn-policy может включать множество записей. Можно использовать фильтр для выбора ЛВС на сайте, которые будут частью определенной сети VPN. Сайт может включать множество сегментов ЛВС, каждый из которых может быть подключен к своей сети VPN. Каждый раз при подключении сайта (или ЛВС) к VPN пользователь должен точно указать его роль (site-role) в топологии целевого сервиса VPN.

+---------------------------------------------------------------+
|       Сайт 1 ------ PE7                                       |
+-------------------------+                 [VPN2]              |
                          |                                     |
+-------------------------+                                     |
|       Сайт 2 ------ PE3               PE4 ------ Сайт 3       |
+-----------------------------------+                           |
                                    |                           |
+-------------------------------------------------------------+ |
|       Сайт 4 ------ PE5           |   PE6 ------ Сайт 5     | |
|                                                             | |
|                      [VPN3]                                 | |
+-------------------------------------------------------------+ |
                                   |                            |
                                   +----------------------------+

Рисунок 17. Пример политики VPN.


На рисунке 17 Сайт 5 входит в VPN3 и VPN2, выступая в качестве Hub для VPN2 и any-to-any для VPN3. Этот вариант подключения описан ниже.

   <?xml version="1.0"?>
    <l2vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l2vpn-svc">
     <vpn-services>
      <vpn-service>
       <vpn-id>VPN2</vpn-id>
       <ce-vlan-preservation>true</ce-vlan-preservation>
       <ce-vlan-cos-preservation>true</ce-vlan-cos-preservation>
      </vpn-service>
      <vpn-service>
       <vpn-id>VPN3</vpn-id>
       <ce-vlan-preservation>true</ce-vlan-preservation>
       <ce-vlan-cos-preservation>true</ce-vlan-cos-preservation>
      </vpn-service>
     </vpn-services>
     <sites>
        <site>
       <locations>
        <location>
         <location-id>L1</location-id>
        </location>
       </locations>
       <management>
        <type>customer-managed</type>
       </management>
          <site-id>Site5</site-id>
          <vpn-policies>
           <vpn-policy>
            <vpn-policy-id>POLICY1</vpn-policy-id>
            <entries>
             <id>ENTRY1</id>
             <vpn>
              <vpn-id>VPN2</vpn-id>
              <site-role>hub-role</site-role>
             </vpn>
            </entries>
            <entries>
             <id>ENTRY2</id>
             <vpn>
              <vpn-id>VPN3</vpn-id>
              <site-role>any-to-any-role</site-role>
             </vpn>
            </entries>
           </vpn-policy>
          </vpn-policies>
          <site-network-accesses>
           <site-network-access>
            <network-access-id>LA1</network-access-id>
         <site>
          <site-id>SITE1</site-id>
       <locations>
        <location>
         <location-id>L1</location-id>
        </location>
       </locations>
       <management>
        <type>customer-managed</type>
       </management>
          <site-network-accesses>
           <site-network-access>
            <network-access-id>LA1</network-access-id>
                <service>
                  <svc-bandwidth>
                     <bandwidth>
                       <direction>input-bw</direction>
                        <type>bw-per-cos</type>
                         <cir>450000000</cir>
                         <cbs>20000000</cbs>
                         <eir>1000000000</eir>
                         <ebs>200000000</ebs>
                     </bandwidth>
                    </svc-bandwidth>
                     <carrierscarrier>
                       <signaling-type>bgp</signaling-type>
                     </carrierscarrier>
                     <svc-mtu>1514</svc-mtu>
                   </service>
            <vpn-attachment>
             <vpn-id>VPNA</vpn-id>
             <site-role>spoke-role</site-role>
            </vpn-attachment>
           </site-network-access>
           <site-network-access>
            <network-access-id>LA2</network-access-id>
                <service>
                  <svc-bandwidth>
                     <bandwidth>
                       <direction>input-bw</direction>
                        <type>bw-per-cos</type>
                         <cir>450000000</cir>
                         <cbs>20000000</cbs>
                         <eir>1000000000</eir>
                         <ebs>200000000</ebs>
                     </bandwidth>
                    </svc-bandwidth>
                     <carrierscarrier>
                       <signaling-type>bgp</signaling-type>
                     </carrierscarrier>
                     <svc-mtu>1514</svc-mtu>
                   </service>
            <vpn-attachment>
             <vpn-id>VPNB</vpn-id>
             <site-role>spoke-role</site-role>
            </vpn-attachment>
           </site-network-access>
          </site-network-accesses>
         </site>
            <vpn-attachment>
             <vpn-policy-id>POLICY1</vpn-policy-id>
            </vpn-attachment>
           </site-network-access>
          </site-network-accesses>
         </site>
     </sites>
    </l2vpn-svc>

Если требуется более детальное управление подключением к VPN, можно воспользоваться фильтрацией. Например, если сеть LAN1 Сайта 5 должна быть подключена к VPN2 в роли Hub, а LAN2 должна быть подключена к VPN3, можно использовать приведенную ниже конфигурацию.

    <?xml version="1.0"?>
      <l2vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l2vpn-svc">
        <vpn-services>
          <vpn-service>
            <vpn-id>VPN2</vpn-id>
            <ce-vlan-preservation>true</ce-vlan-preservation>
            <ce-vlan-cos-preservation>true</ce-vlan-cos-preservation>
            </vpn-service>
            <vpn-service>
             <vpn-id>VPN3</vpn-id>
             <ce-vlan-preservation>true</ce-vlan-preservation>
             <ce-vlan-cos-preservation>true</ce-vlan-cos-preservation>
            </vpn-service>
        </vpn-services>
      <sites>
       <site>
       <locations>
        <location>
         <location-id>L1</location-id>
        </location>
       </locations>
       <management>
        <type>customer-managed</type>
       </management>
             <site-id>Site5</site-id>
             <vpn-policies>
              <vpn-policy>
               <vpn-policy-id>POLICY1</vpn-policy-id>
               <entries>
                <id>ENTRY1</id>
                <filters>
                  <filter>
                    <type>lan</type>
                    <lan-tag>LAN1</lan-tag>
                  </filter>
                </filters>
                <vpn>
                 <vpn-id>VPN2</vpn-id>
                 <site-role>hub-role</site-role>
                </vpn>
               </entries>
               <entries>
                <id>ENTRY2</id>
                <filters>
                  <filter>
                    <type>lan</type>
                    <lan-tag>LAN2</lan-tag>
                  </filter>
                </filters>
                 <vpn>
                 <vpn-id>VPN3</vpn-id>
                 <site-role>any-to-any-role</site-role>
                </vpn>
               </entries>
              </vpn-policy>
             </vpn-policies>
             <site-network-accesses>
              <site-network-access>
               <network-access-id>LA1</network-access-id>
                 <service>
                   <svc-bandwidth>
                      <bandwidth>
                       <direction>input-bw</direction>
                        <type>bw-per-cos</type>
                         <cir>450000000</cir>
                         <cbs>20000000</cbs>
                         <eir>1000000000</eir>
                         <ebs>200000000</ebs>
                      </bandwidth>
                     </svc-bandwidth>
                      <carrierscarrier>
                         <signaling-type>bgp</signaling-type>
                      </carrierscarrier>
                       <svc-mtu>1514</svc-mtu>
                   </service>
               <vpn-attachment>
                <vpn-policy-id>POLICY1</vpn-policy-id>
               </vpn-attachment>
              </site-network-access>
             </site-network-accesses>
            </site>
           </sites>
         </l2vpn-svc>

5.6. Определение точки подключения сайта

Система управления будет определять для каждого site-network-access на конкретном сайте точку подключения к сети провайдера (например, PE или агрегирующий коммутатор).

Эта модель определяет параметры и ограничения, которые могут влиять на подключение site-network-access.

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

Параметры расположения сайта (параграф 5.6.2) и типа доступа (параграф 5.6.3) влияют на размещение сервиса, выбираемое системой управления.

Кроме учета параметров и ограничений на решение системы управления могут влиять внутренние ограничения SP, например, наименьшая загрузка или удаленность.

5.6.1. Ограничение — устройство

При управлении со стороны провайдера или совместном управлении абонент может заказать одно или множество устройств на конкретную площадку, которая уже настроена. Абонент может принудительно задать site-network-access для подключения заказанного устройства.

  Сайт в Нью-Йорке
+------------------+             Сайт
| +--------------+ |-------------------------------------
| | Манхэттен    | |
| |           CE1********* (site-network-access#1) ******
| +--------------+ |
| +--------------+ |
| | Бруклин      | |
| |           CE2********* (site-network-access#2) ******
| +--------------+ |
|                  |-------------------------------------
+------------------+

Рисунок 18. Пример ограничений для устройства.


На рисунке 18 site-network-access#1 связывается с устройством CE1 из запроса. SP должен обеспечить это подключение.

5.6.2. Ограничение и параметр — расположение сайта

Обеспечивая этой моделью информация о местоположении может применяться системой управления при поиске PE для подключения сайта (на стороне SP). С каждым подключением сайта к сети должно быть связано конкретное место. Провайдер должен обеспечивать завершение сервиса в указанной точке доступа сайта в сеть (на стороне абонента). Значение country-code в местоположении сайта следует указывать кодом ISO 3166 и оно похоже на метку country, определенную в [RFC4119].

Местоположение site-network-access определяется значением location-flavor. Для сайтов, управляемых провайдером или совместно с ним, предполагается, что пользователь укажет значение device-reference (для устройства), которое свяжет site-network-access с конкретным устройством, заказанным абонентом. Поскольку устройство связано с конкретным местом, в этом случае информация о местоположении определяется по размещению устройства. Если сайт управляется абонентом, предполагается, что пользователь укажет location-reference (для местоположения) и это значение будет указывать уже настроенное местоположение, что поможет в размещении.

                         POP#1 (Нью-Йорк)
                      +---------+
                      |   PE1   |
 Сайт 1 ---...        |   PE2   |
(Атлантик-Сити)       |   PE3   |
                      +---------+

                         POP#2 (Вашингтон)
                      +---------+
                      |   PE4   |
                      |   PE5   |
                      |   PE6   |
                      +---------+

                         POP#3 (Филадельфия)
                      +---------+
                      |   PE7   |
 Сайт 2 CE#1---...    |   PE8   |
(Рестон)              |   PE9   |
                      +---------+

Рисунок 19. Данные о местоположении сайтов.


На рисунке 19 управляемый абонентом Сайт 1 имеет местоположение L1, а для управляемого провайдером Сайта 2 заказано устройство CE (CE#1). Для Сайта 2 указано местоположение L2. При настройке site-network-access для Сайта 1 пользователь должен указать местоположение L1, чтобы система управления знала, что в этом месте организуется доступ. Затем с учетом расстояния система управления может соединить Сайт 1 с PE в Philadelphia POP. При этом могут также учитываться ресурсы, доступные на PE, для точного определения целевого устройства PE (например, менее загруженного). Для Сайта 2 предполагается, что пользователь настроит site-network-access со ссылкой (device-reference) на CE#1, чтобы система управления знала о том, что доступ будет завершаться в месте размещения устройства CE#1, которое должно быть подключено. Для организации подключения на стороне SP в случае использования ближайшего PE, Сайт 2 может быть подключен к Washington POP.

5.6.3. Ограничение и параметр — тип доступа

Система управления должна выбрать среду для подключения сайта (например, xDSL, арендованная линия, Ethernet). Абонент может задать некоторые параметры и/или ограничения, которые помогут системе управления выбрать среду.

Информацию контейнера bearer следует рассматривать в первую очередь.

  • Параметр requested-type обеспечивает информацию о типе среды, который абонент хочет использовать. Если лист strict имеет значение true, система управления должна считать это строгим ограничением для типа среды. Если strict = false (принято по умолчанию) и запрошенная среда недоступна, система управления может выбрать другой тип среды. Абоненту и провайдеру следует обменяться данными о поддерживаемых типах сред, но механизмы такого обмена выходят за рамки документа.

  • Лист always-on определяет строгое ограничение. При значении true система управления должна выбрать тип среды, которая всегда доступна (always-on), т. е. не может применяться коммутируемый доступ.

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

Могут применяться также иные внутренние параметры от SP. Система управления может использовать такие параметры, как «input svc-bandwidth» и «output svc-bandwidth» для выбора используемого типа доступа.

5.6.4. Ограничение — разнесение доступа

Каждый элемент site-network-access может включать одно или множество ограничений, которые будут определять размещение доступа. По умолчанию в модели предполагается отсутствие ограничений, но ожидается выделение уникального носителя (bearer) для каждого site-network-access.

Для реализации разных вариантов доступа элементы site-network-access можно помечать с помощью одного или нескольких идентификаторов групп. Идентификатор группы представляет собой строку, которая может включать как явное именование группы сайтов (например, multihomed-set1), так и числовое значение (например, 12345678). Значение каждого group-id локально для администратора абонента и система управления должна обеспечивать разным абонентам возможность использования одинаковых идентификаторов. Один или несколько group-id могут быть также определены на уровне сайта, в результате чего все site-network-access этого сайта должны наследовать идентификаторы group-id своего сайта. Когда в дополнение group-id сайта определяются идентификаторы на уровне site-network-access, система управления должна учитывать объединение всех групп (уровня сайта и уровня site-network-access) для конкретного элемента site-network-access.

Для уже настроенного элемента site-network-access каждое ограничение должно быть выражено применительно к набору site-network-accesses. Уже настроенный элемент site-network-access должен не приниматься во внимание в целевом наборе site-network-accesses. Например, «site-network-access S недопустимо подключать к той же точке присутствия POP, куда подключен контейнер site-network-accesses, являющийся частью Group 10». Набор site-network-accesses, к которому применяются ограничения, может быть указан в форме списка групп all-other-accesses или all-other-groups. Опция all-other-accesses означает, что текущее ограничение site-network-access допустимо применять ко всем site-network-accesses, относящимся к текущему сайту. Опция all-other-groups означает, что ограничение должно применяться ко всем группам, в которые текущий элемент site-network-access не входит.

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

  • pe-diverse — текущий элемент site-network-access недопустимо соединять с тем же PE, что и целевой site-network-accesses.

  • pop-diverse — текущий элемент site-network-access недопустимо соединять с той же точкой POP, что и целевой site-network-accesses.

  • linecard-diverse — текущий элемент site-network-access недопустимо соединять с той же линейной платой, что и целевой site-network-accesses. Отметим, что абонент может запросить linecard-diverse для site-network-accesses, но идентификатор текущей используемой линейной платы не следует показывать абоненту.

  • bearer-diverse — текущему элементу site-network-access недопустимо использовать общие компоненты носителя (bearer) с носителями, используемыми целевым site-network-accesses. Элемент bearer-diverse обеспечивает некоторый уровень разнесения доступа. Например, двум bearer-diverse site-network-accesses недопустимо использовать один мультиплексор DSLAM54, BAS55 или коммутатор L2.

  • same-pe — текущий элемент site-network-access должен соединяться с тем же PE, что и целевой site-network-accesses.

  • same-bearer — текущий элемент site-network-access должен соединяться с тем же носителем, что и целевой site-network-accesses.

Типы ограничений могут быть расширены с помощью дополнений. Каждое ограничение должно выражаться в форме «элемент site-network-access S должен быть <constraint-type> (например, pe-diverse, pop-diverse) из <target> site-network-accesses».

Идентификатор group-id, используемый для нацеливания того или иного site-network-accesses, может совпадать с применяемым в текущем элементе site-network-access. Это упрощает настройку для случаев, где группа точек site-network-access имеет ограничения между собой.

5.7. Выделение значений RD

Обозначение маршрута (RD56) является важнейшим параметром L2VPN на основе протокола BGP, описанных в [RFC4364], который обеспечивает возможность различать общие блоки адресов в разных VPN. Поскольку для целей маршрутов (RT) предполагается выделение системой управления таблиц MAC-VRF на целевом PE и RD для этих MAC-VRF, значение RD должно быть уникальным для каждой таблицы MAC-VRF в целевом PE.

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

Если таблицы MAC-VRF нет в целевом PE, система управления инициирует создание MAC-VRF в целевом PE и выделение для нее нового значения RD.

Система управления может применять политику выделения RD на уровне VPN или MAC-VRF в зависимости от правил SP. При выделении на уровне VPN все таблицы MAC-VRF (отправленные в разные PE) в рамках VPN будут использовать общее значение RD. При выделении на уровне MAC-VRF каждой таблице MAC-VRF следует назначать уникальное значение RD. Возможны другие варианты выделения значений и данный документ не ограничивает выбор.

Выделение RD может выполняться таким же способом как для RT. Представленная в параграфе 5.2.2.1 информация пригодна и в этом случае.

Отметим, что SP может настроить целевое устройство PE на автоматическое выделение значений RD. В таких случаях не потребуется какой-либо отдельной системы (backend) для назначения RD.

5.8. Доступность Site-Network-Access

Сайт может быть многодомным с множеством точек site-network-access. Ограничения на размещение, описанные в параграфе 5.6, помогут обеспечить разнесение физических подключений.

При размещении site-network-accesses в сети абонент может захотеть использовать определенную политику маршрутизации для этого доступа. Контейнер site-network-access/availability определяет параметры избыточности для резервирования на данном сайте. Лист access-priority определяет предпочтения для конкретного доступа. Эти предпочтения используются в сценариях «основной-резервный» и «распределение нагрузки». Большее значение access-priority задает более предпочтительное использование. Атрибут redundancy-mode определен для многодомных сайтов и служит для использования в сценариях «один активный» и «активный-активный». Это позволяет поддерживать множество активных путей в состоянии пересылки и для распределения нагрузки.

На рисунке 20 показаны варианты использования атрибута access-priority.

ЛВС Hub#1 (основной/резервный)    ЛВС Hub#2 (распределение нагрузки)
  |                                                     |
  |    access-priority 1          access-priority 1     |
  |--- CE1 ------- PE1            PE3 --------- CE3 --- |
  |                                                     |
  |                                                     |
  |--- CE2 ------- PE2            PE4 --------- CE4 --- |
  |    access-priority 2          access-priority 1     |

                        PE5
                         |
                         |
                         |
                        CE5
                         |
                    Сайт Spoke#1 (однодомный)

Рисунок 20. Пример настройки приоритета доступа.


Для ЛВС Hub#2 требуется распределение нагрузки, поэтому оба site-network-access должны иметь одинаковые значения access-priority. Для ЛВС Hub#1 требуется резервирование доступа и большее значение access-priority определяет основное соединение (site-network-access).

Могут быть промоделированы и более сложные сценарии. Рассмотрим Hub-сайт с 5 подключениями к сети (A1, A2, A3, A4, A5). Абонент хочет в обычных условиях распределять нагрузку между соединениями A1 и A2, при отказе этих каналов — распределять нагрузку между A3 и A4, а случае отказа всех каналов A1, A2, A3 и A4 — использовать канал A5. Это можно реализовать, установив значения access-priority: A1=100, A2=100, A3=50, A4=50, A5=10.

Подход access-priority имеет некоторые ограничения. Например, в описанном выше случае переход на распределение нагрузки между каналами A3 и A4 недостижим в случае отказа лишь одного из каналов A1 и A2. Однако атрибут access-priority хорошо подходит для большинства практических реализаций и при необходимости модель может быть расширена с помощью дополнений.

5.9. SVC MTU

Значение MTU для кадров абонентского сервиса можно вывести из принятого по умолчанию MTU физических интерфейсов или задать в листе svc-mtu, если принятое по умолчанию значение не подходит.

5.10. Контейнер service

Контейнер service определяет параметры сервиса, связанные с сайтом.

5.10.1. Параметр Bandwidth

Параметр bandwidth указывает требования к пропускной способности между устройствами CE и PE, которая может быть указана значением согласованной (CIR57), избыточной (EIR58) или пиковой (PIR59) скорости. Запрошенная пропускная способность выражается как входная и выходная пропускная способность, определяемые относительно сайта абонента. Входная пропускная способность указывает скорость загрузки данных на сайт абонента, выходная — скорость выгрузки данных с сайта в сеть.

Пропускная способность настраивается только на уровне site-network-access (т. е. для соединения сайта с сетью).

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

Параметр svc-bandwidth имеет определенный тип. Данный документ определяет 4 типа:

  • bw-per-access — пропускная способность задается для соединения или доступа сайта в сеть применительно ко всем кадрам сервиса на интерфейсе, связанном с конкретным подключением;

  • bw-per-cos — пропускная способность задается для класса обслуживания (CoS), определяя скорость для всех кадров данного CoS с конкретным cos-id;

  • bw-per-svc — пропускная способность задается для сайта в целом, определяя скорость для всех кадров сервиса, связанных с конкретным экземпляром VPN;

  • «непрозрачная» пропускная способность, не связанная с каким-либо cos-id, экземпляром VPN (vpn-id) или идентификатором доступа сайта в сеть.

Параметр svc-bandwidth должен включать cos-id для типа bw-per-cos. Значения cos-id могут выделяться на основе (1) значения IEEE 802.1p [IEEE-802-1D] в C-tag или (2) кода DSCP60 в заголовке IP61. Измерения выполняются в соответствии с профилем пропускной способности, заданным cos-id.

Для типа bw-per-access параметр svc-bandwidth должен быть связан с конкретным параметром site-network-access-id. С каждым подключением сайта может быть связано множество значений полосы на уровне cos-id.

Для типа bw-per-svc параметр svc-bandwidth должен включать конкретный параметр vpn-id. С одним сервисом EVPN может быть связано множество значений полосы на уровне cos-id.

5.10.2. Параметр QoS

Модель определяет параметры QoS как абстракцию:

  • qos-classification-policy — определяет набор упорядоченных правил классификации абонентского трафика;

  • qos-profile — определяет применяемый профиль планирования QoS.

5.10.2.1. Классификация QoS

Правила классификации QoS определяются параметром qos-classification-policy, который представляет собой упорядоченный список правил, которые сопоставляются с потоками или приложениями, и устанавливают подходящий целевой класс обслуживания CoS (target-class-id). Пользователь может определить сопоставление с использованием более конкретного определения потока (по MAC-адресам отправителей и получателей, cos, dscp, cos-id, color-id и т. п.). Значение color-id может быть назначено кадру для идентификации соответствия профилю QoS. Кадры сервиса считаются «зелеными» (green), если они соответствуют согласованной скорости профиля пропускной способности. «Желтыми» (yellow) считаются кадры, выходящие за пределы согласованной скорости, но соответствующие «избыточной» скорости профиля пропускной способности. «Красными» (red) будут кадры, выходящие за пределы согласованной и избыточной скорости в профиле пропускной способности.

При использовании определения потока пользователь может применить лист-список target-sites для указания получателя потока вместо адреса получателя. В таких случаях привязка между абстракцией сайта и применяемыми для сайта MAC-адресами должна выполняться динамически. Способы организации такой привязки выходят за рамки документа. Связь сайта с L2VPN указывается контейнером vpn-attachment. Поэтому пользователь может идентифицировать получателей в потоке целевой сети VPN с помощью листа-списка target-sites и контейнера vpn-attachment. Правила без оператора сопоставления match считаются правилами «соответствия всему» (match-all). SP может реализовать завершающее правило классификации, если абонент не задал такого правила. Используемый по умолчанию класс определяет SP. В этой модели определены некоторые приложения, но можно добавлять новые с помощью дополнений. Точное значение отождествления каждого приложения зависит от SP, поэтому провайдер должен заранее информировать абонента об использовании сопоставлений по приложениям.

5.10.2.2. Профиль QoS

Пользователь может выбрать стандартный профиль, предоставленный оператором, или создать свой профиль. Профиль QoS (qos-profile) определяет правила планирования трафика, используемые SP.

Абонентский профиль QoS определяется как список записей CoS и связанных в ними свойств, приведенных ниже.

  • direction — служит для указания направления, к которому применяется qos-profile. Эта модель поддерживает направление с сайта в WAN (site-to-wan), из WAN на сайт (wan-to-site) и двухстороннее управление (bidirectional), которое применяется по умолчанию. При выборе двухстороннего управления провайдеру следует обеспечить планирование трафика в соответствии с запрошенными правилами в обоих направлениях (от SP на сайт и обратно). Например, правила планирования могут применяться на стороне PE и на стороне CE канала WAN. В направлении из WAN на сайт провайдеру следует обеспечивать планирование трафика из сети SP на сайт абонента. Например, правила управления трафиком могут быть реализованы лишь на устройстве PE, подключенном к WAN-каналу в направлении абонента.

  • policing — (необязательно) указывает, следует ли применять правила к одной скорости и двум цветами или двум скоростям и трем цветам.

  • byte-offset — (необязательно) указывает число байтов в заголовках кадров, которые не учитываются при ограничении скорости.

  • frame-delay — ограничивает задержки для данного класса. Ограничение задержки может быть указано минимальной возможной задержкой или границей задержки в миллисекундах. Выполнение этого ограничения зависит от реализации SP — может применяться строгий механизм приоритизации для очередей на канале доступа и в ядре сети или создаваться путь маршрутизации с малой задержкой для этого класса трафика.

  • frame-jitter — ограничивает вариации задержек для данного класса. Ограничение может быть выражено как минимальная возможная вариация или граница вариации в миллисекундах. Выполнение этого ограничения зависит от реализации SP — может применяться строгий механизм приоритизации для очередей на канале доступа и в ядре сети или создаваться путь маршрутизации с известной величиной вариаций для этого класса.

  • bandwidth — задает гарантированную пропускную способность для CoS, выражаемую в процентах. Параметр guaranteed-bw-percent использует в качестве единицы отсчета доступную пропускную способность, которой следует быть не ниже значения CIR, определенного во входном или выходном параметре svc-bandwidth. При реализации контейнера qos-profile на стороне CE в качестве единицы отсчета применяется выходное значение svc-bandwidth, а при реализации на стороне PE — входное значение svc-bandwidth. По умолчанию резервирование пропускной способности гарантируется лишь на уровне доступа. Пользователь может применить лист end-to-end для запроса сквозного резервирования пропускной способности, включая транспортную сеть MPLS. Иными словами, SP будет активировать в ядре MPLS те или иные средства обеспечения запрошенной абонентом пропускной способности. Решение этой задачи (например, резервирование RSVP-TE или резервирование в контроллере) выходит за рамки документа.

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

5.10.3. Поддержка BUM

Контейнер broadcast-unknown-unicast-multicast указывает тип сайта в топологии групповой пересылки абонента — источник, получатель или оба сразу. Эти параметры помогают системе управления оптимизировать групповой трафик.

Можно создать множество отображений групп на порты (group-to-port) с помощью списка multicast-gp-address-mapping, определяющего адрес multicast-группы и номер порта LAG. Эти параметры помогают SP выбрать подходящую привязку интерфейса к multicast-группе для удовлетворения требований абонента.

Для обеспечения «прозрачной» доставки данного кадра все групповые кадры L2 (данные и управление) следует без изменений (за исключением VLAN ID) передавать от CE до CE. Значения VLAN ID, заданные SP, также можно менять.

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

Пересылка кадров BUM в многоточечном сервисе включает локальную лавинную рассылку другим устройствам AC того же PE и удаленную репликацию на всех других PE, которая требует дополнительных ресурсов и пропускной способности в ядре сети. На обращенных наружу интерфейсах (UNI или E-NNI62) могут быть реализованы специальные правила обработки кадром BUM с ограничением скорости для них числом пакетов или битов в секунду.

Может задаваться общий порог для всего трафика BUM или отдельные пороги для каждой категории трафика.

5.11. Управление сайтом

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

Управляемое провайдером устройство CE. Провайдер монопольно владеет устройством CE и только он имеет доступ к CE. Граница ответственности SP и абонента размещается между CE и сетью абонента. Этот вариант используется чаще всего.

Управляемое абонентом устройство CE. Абонент монопольно вдадеет устройством CE и только он имеет доступ к CE. Граница ответственности SP и абонента размещается между PE и CE.

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

Выбранная модель управления указывается в листе type. Лист address хранит адрес для управления устройством CE. Лист management-transport служит для указания протокола, используемого для управления (IPv4 или IPv6). На основе выбранной модели управления могут быть заданы дополнительные опции защиты.

5.12. Защита от петель MAC

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

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

Частота переброса MAC-адресов и опции предотвращения петель указываются в контейнере mac-loop-prevention.

5.13. Ограничение числа MAC-адресов

Необязательный контейнер mac-addr-limit содержит предельное число абонентских MAC-адресов и данные, описывающие поведение при достижении предела или старении MAC-адреса.

При реализации нескольких экземпляров сервиса на одном элементе сети таблица MAC-адресов (а также пространство RIB63 для маршрутов MAC в случае EVPN) является совместно используемым ресурсом. Провайдер может ограничивать число MAC-адресов, узнанных от абонента, для одного экземпляра сервиса с помощью листа mac-addr-limit и может применять лист action для указания действий в случае превышения заданного предела — отбрасывание пакета, лавинная рассылка или просто запись события в системный журнал.

Если для услуг «точка-точка» обучение MAC отключено, ограничивать число MAC-адресов не требуется.

5.14. Расширенные возможности VPN

5.14.1. Оператор для операторов

В случае CsC64 [RFC8299] абонент может захотеть организовать сервис MPLS на основе L2VPN для передачи трафика.

ЛВС customer1
   |
   |
  CE1
   |
   | -------------
(vrf_cust1)
 CE1_ISP1
   |                 ISP1 POP
   | Канал MPLS 
   | -------------
   |
(vrf ISP1)
  PE1

 (...)   Магистраль првайдера

  PE2
(vrf ISP1)
   |
   | ------------
   |
   | Канал MPLS 
   |                 ISP1 POP
 CE2_ISP1
(vrf_cust1)
   | ------------
   |
  CE2
   |
ЛВС customer1

Рисунок 21. Сервис MPLS с использованием L2VPN.


В примере на рисунке 21 ISP1 продает услуги L2VPN, но не имеет инфраструктуры ядра между своими точками POP и использует сервис L2VPN в качестве такой инфраструктуры (принадлежащей другому провайдеру) между своими POP.

Для поддержки CsC сервис VPN должен указать поддержку MPLS путем указания для листа carrierscarrier в списке vpn-service значения true. Канал между CE1_ISP1/PE1 и CE2_ISP1/PE2 должен также поддерживать протокол сигнализации MPLS. Конфигурация выполняется на уровне сайта.

В этой модели в качестве сигнального протокола MPLS может применяться LDP или BGP. В случае LDP должен также применяться протокол внутренней маршрутизации IGP. В случае сигнализации BGP протокол BGP должен также служить протоколом маршрутизации.

При использовании CsC запрашиваемый лист svc-mtu должен указывать MPLS MTU, а не MTU на канале.

5.15. Ссылки на внешние идентификаторы

Модель сервиса порой обращается к внешней информации путем задания идентификаторов. Например, для заказа доступа в облако конкретного CSP65 в модели используется идентификатор целевого CSP. Если абонент напрямую применяет модель сервиса в качестве API (например, через RESTCONF или NETCONF) для заказа определенной услуги, провайдеру следует предоставлять список действующих идентификаторов. В случае доступа к облаку SP будет предоставлять идентификаторы, связанные с доступными провайдерами CSP. То же самое относится и к другим идентификаторам (таким, как qos-profile).

Например, установка remote-carrier-name используется в случае NNI, поскольку эта информация нужна текущему L2VPN SP, с которым организуется соединение, тогда как идентификатор облака (cloud-identifier) нужен текущему L2VPN SP и абоненту, поскольку он применяется для доступа к публичному облаку или в Internet.

Способы предоставления провайдером этой информации абоненту выходят за рамки документа.

5.16. Определение NNI и поддержка нескольких AS

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

  • партнерские отношения между SP (например, оператор или облако) для расширения сервиса VPN;

  • внутренние границы в рамках одного SP (например, транзитные сети, ядро и ЦОД).

Интерфейсы NNI определяются для организации VPN через множество AS. В [RFC4761] определено множество вариантов реализации VPN NNI (например, VPLS), каждый из которых имеет свои преимущества и недостатки, но этот вопрос выходит за рамки документа. Например в варианте A (две AS) партнеры ASBR67 соединяются через множество интерфейсов, из которых по крайнем мере один, относящийся в обеим AS, будет присутствовать в VPN. Чтобы эти ASBR могли обмениваться блоками меток, они связывают каждый интерфейс с таблицей MAC-VRF (VSI, раздел 2) и сессией BGP. В результате трафик между устройствами в VPLS передается по протоколу Ethernet. В этом варианте все VPN изолированы одна от другой, а поскольку трафик передаются с помощью Ethernet, механизмы QoS для трафика Ethernet могут применяться для обеспечения абонентских соглашений SLA.

  --------                 --------------              -----------
 /        \               /              \            /           \
| Облачный |             |                |          |             |
| провайдер|-----NNI-----|                |----NNI---|     ЦОД     |
|  #1      |             |                |          |             |
 \        /              |                |           \           /
  --------               |                |            -----------
                         |                |
  --------               |    Моя сеть    |           -----------
 /        \              |                |          /           \
| Облачный |             |                |         |             |
| провайдер|-----NNI-----|                |---NNI---| Партнер     |
|  #2      |             |                |         | L2VPN       |
 \        /              |                |         |             |
  --------               |                |         |             |
                          \              /          |             |
                           --------------            \           /
                                 |                    -----------
                                 |
                                NNI
                                 |
                                 |
                         -------------------
                        /                   \
                       |                     |
                       |                     |
                       |                     |
                       |     Партнер L2VPN   |
                       |                     |
                        \                   /
                         -------------------

Рисунок 22. Сеть SP с несколькими NNI.


На рисунке 22 показана сеть SP (Моя сеть), имеющая несколько интерфейсов NNI, используемых для

  • расширения своего присутствия, основанного на партнерстве L2VPN;

  • подключения своих ЦОД к абонентским L2VPN;

  • обеспечения абонентам доступа к частным ресурсам, расположенным в облаке некого провайдера CSP.

5.16.1. Определение NNI, вариант A

         AS A                                         AS B
  -------------------                         -------------------
 /                   \                       /                   \
|                     |                     |                     |
|                 ++++++++ Канал между AS+++++++++                |
|                 +      +_______________+       +                |
|                 +(MAC-VRF1)--(VPN1)--(MAC-VRF1)+                |
|                 +      +               +       +                |
|                 + ASBR +               + ASBR  +                |
|                 +      +               +       +                |
|                 +(MAC-VRF2)--(VPN2)--(MAC-VRF2)+                |
|                 +      +_______________+       +                |
|                 ++++++++               +++++++++                |
|                     |                     |                     |
|                     |                     |                     |
|                     |                     |                     |
|                 ++++++++ Канал между AS+++++++++                |
|                 +      +_______________+       +                |
|                 +(MAC-VRF1)--(VPN1)--(MAC-VRF1)+                |
|                 +      +               +       +                |
|                 + ASBR +               + ASBR  +                |
|                 +      +               +       +                |
|                 +(MAC-VRF2)--(VPN2)--(MAC-VRF2)+                |
|                 +      +_______________+       +                |
|                 ++++++++               +++++++++                |
|                     |                     |                     |
|                     |                     |                     |
 \                   /                       \                   /
  -------------------                         -------------------

Рисунок 23. Интерфейс NNI, вариант A, пример 1.


В варианте A две AS соединены между собой физическими каналами на маршрутизаторах ASBR. Для отказоустойчивости между AS может быть организовано множество физических соединений. Соединение VPN (физическое или логическое на основе физического) создается для каждой сети VPN, которой требуется выход за границу AS.

С точки зрения модели сервиса это соединение VPN может выглядеть сайтом. Предположим, что AS B хочет расширить соединение для VPN C на AS A. Администратор AS B может использовать эту модель сервиса для заказа сайта в AS A. Все варианты могут быть реализованы с использованием возможностей текущей модели. Например, на рисунке 23 показаны два физических соединения, на которые наложены логические соединения VPN. Это можно рассматривать как сценарий с множеством VPN. Администратор AS B может также выбрать подходящий протокол маршрутизации (например, EBGP68) для динамического обмена маршрутами между AS.

В этом документе предполагается, что для варианта A интерфейса NNI следует применять имеющуюся модель сайта VPN.

На рисунке 24 показан пример, где абонент хочет, чтобы его CSP A присоединил свою виртуальную сеть N к имеющейся L2VPN (VPN1) от сервиса L2VPN провайдера SP B.

         CSP A                           L2VPN SP B
  -----------------                     -----------
 /                 \                   /           \
|       |           |                 |             |
|  VM --|       ++++++++     NNI    ++++++++++      |--- VPN1
|       |       +      +____________+        +      |   Сайт 1
|       |-------+(MAC-VRF1)-(VPN1)-(MAC-VRF1)+      |
|       |       +      +            +        +      |
|       |       + ASBR +            + ASBR   +      |
|       |       +      +____________+        +      |
|       |       ++++++++            ++++++++++      |
|  VM --|           |                 |             |--- VPN1
|       |Виртуальная|                 |             |   Сайт 2
|       |сеть       |                 |             |
|  VM --|           |                 |             |--- VPN1
|       |           |                 |             |   Сайт 3
 \                 /                   \           /
  -----------------                     -----------
                                             |
                                             |
VM = Виртуальная машина                     VPN1
                                           Сайт 4

Рисунок 24. Интерфейс NNI, вариант A, пример 2.


Для подключения VPN провайдер CSP или абонент может использовать модель L2SM, раскрытую провайдером SP B. Поскольку интерфейс NNI используется совместно, можно считать, что физическое соединение (bearer) между CSP A и SP B уже имеется. CSP A может запросить через модель сервиса создание нового сайта с одним контейнером site-network-access (single-homing на рисунке 24). В качестве ограничения для размещения CSP A может использовать ссылку на носитель (bearer) от SP A для размещения VPN NNI на имеющемся канале. Приведенный ниже код XML иллюстрирует возможный запрос конфигурации к провайдеру SP B.

   <?xml version="1.0"?>
   <l2vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l2vpn-svc">
    <vpn-profiles>
     <valid-provider-identifiers>
      <qos-profile-identifier>
       <id>GOLD</id>
      </qos-profile-identifier>
      <qos-profile-identifier>
       <id>PLATINUM</id>
      </qos-profile-identifier>
     </valid-provider-identifiers>
    </vpn-profiles>
    <vpn-services>
     <vpn-service>
      <vpn-id>VPN1</vpn-id>
      <ce-vlan-preservation>true</ce-vlan-preservation>
      <ce-vlan-cos-preservation>true</ce-vlan-cos-preservation>
     </vpn-service>
    </vpn-services>
    <sites>
         <site>
             <site-id>CSP_A_attachment</site-id>
              <locations>
               <location>
                 <location-id>NY1</location-id>
                 <city>NY</city>
                 <country-code>US</country-code>
              </location>
              </locations>
             <site-vpn-flavor>site-vpn-flavor-nni</site-vpn-flavor>
               <site-network-accesses>
                 <site-network-access>
                  <network-access-id>CSP_A_VN1</network-access-id>
                          <connection>
                          <encapsulation-type>vlan</encapsulation-type>
                          <eth-inf-type>tagged</eth-inf-type>
                           <tagged-interface>
                            <tagged-inf-type>dot1q</tagged-inf-type>
                            <dot1q-vlan-tagged>
                             <cvlan-id>17</cvlan-id>
                           </dot1q-vlan-tagged>
                           </tagged-interface>
                          </connection>
                            <service>
                              <svc-bandwidth>
                                <bandwidth>
                                 <direction>input-bw</direction>
                                  <type>bw-per-cos</type>
                                   <cir>450000000</cir>
                                   <cbs>20000000</cbs>
                                   <eir>1000000000</eir>
                                   <ebs>200000000</ebs>
                                </bandwidth>
                              </svc-bandwidth>
                              <carrierscarrier>
                                <signaling-type>bgp</signaling-type>
                             </carrierscarrier>
                            </service>
                           <vpn-attachment>
                              <vpn-id>12456487</vpn-id>
                              <site-role>spoke-role</site-role>
                            </vpn-attachment>
                </site-network-access>
             </site-network-accesses>
             <management>
              <type>customer-managed</type>
             </management>
         </site>
    </sites>
   </l2vpn-svc>

Описанный выше случай отличается от сценария использования контейнера cloud-accesses, который обеспечивает доступ в публичное облако, тогда как в примере организуется доступ к приватным ресурсам в сети CSP.

5.16.2. Определение NNI, вариант B

        AS A                                          AS B
  -------------------                         -------------------
 /                   \                       /                   \
|                     |                     |                     |
|                 ++++++++ Канал между AS++++++++                 |
|                 +      +_______________+      +                 |
|                 +      +               +      +                 |
|                 + ASBR +<---MP-BGP---->+ ASBR +                 |
|                 +      +               +      +                 |
|                 +      +_______________+      +                 |
|                 ++++++++               ++++++++                 |
|                     |                     |                     |
|                     |                     |                     |
|                     |                     |                     |
|                 ++++++++ Канал между AS++++++++                 |
|                 +      +_______________+      +                 |
|                 +      +               +      +                 |
|                 + ASBR +<---MP-BGP---->+ ASBR +                 |
|                 +      +               +      +                 |
|                 +      +_______________+      +                 |
|                 ++++++++               ++++++++                 |
|                     |                     |                     |
|                     |                     |                     |
 \                   /                       \                   /
  -------------------                         -------------------

Рисунок 25. Интерфейс NNI, вариант B, пример 1.


В варианте B две AS соединены между собой физическими каналами на ASBR. Для отказоустойчивости может использоваться множество соединений между AS. «VPN-соединение» между AS организуется путем обмена маршрутами VPN с использованием MP-BGP [RFC4761].

Существует три варианта реализации такого интерфейса NNI.

  1. NNI является внутренним для провайдера и расположен между магистралью и ЦОД. Домены являются доверенными и не нужно фильтровать маршруты VPN, т. е. обмен происходит для всех маршрутов. Может применяться фильтрация RT для сохранения некоторых необязательных состояний.

  2. NNI располагается между провайдерами, готовыми обмениваться маршрутами VPN лишь для конкретных RT. Каждый провайдер получил от другого полномочия на использование этих значений RT.

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

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

В случае 2 требуется политика фильтрации RT на ASBR. С точки зрения модели сервиса требуется согласовать список RT для передачи полномочий.

В случае 3 обе AS должны согласовать VPN RT для обмена, а также отображение VPN RT одной AS на RT из другой.

Такое моделирование выходит за рамки этого документа.

       CSP A                               L3VPN SP B
  -----------------                    ------------------
 /                 \                  /                  \
|       |           |                |                    |
|  VM --|       ++++++++   NNI    ++++++++                |--- VPN1
|       |       +      +__________+      +                |   Сайт 1
|       |-------+      +          +      +                |
|       |       + ASBR +<-MP-BGP->+ ASBR +                |
|       |       +      +__________+      +                |
|       |       ++++++++          ++++++++                |
|  VM --|           |                |                    |--- VPN1
|       |Виртуальная|                |                    |   Сайт 2
|       |сеть       |                |                    |
|  VM --|           |                |                    |--- VPN1
|       |           |                |                    |   Сайт 3
 \                 /                 |                    |
  -----------------                  |                    |
                                      \                  /
                                       ------------------
                                                |
VM = Виртуальная машина                         |
                                               VPN1
                                              Сайт 4

Рисунок 26. Интерфейс NNI, вариант B, пример 2.


На рисунке 26 показано соединение NNI между CSP A и сетью SP B. Провайдеры не доверяют друг другу и каждый применяет свои правила выделения RT. Поэтому в терминах реализации абонентская VPN имеет свое значение RT в каждой сети (RT A в CSP A и RT B в сети SP B). Для подключения виртуальной сети абонента в CSP A к абонентской L2VPN (VPN1) в сети SP B провайдеру CSP A следует запросить у сети SP B создание абонентской VPN на интерфейсе NNI (восприятие соответствующего RT). Трансляция RT выполняется на основе соглашения между двумя SP — SP B может разрешить CSP A запрос трансляции VPN (RT).

5.16.3. Определение NNI, вариант C

         AS A                                           AS B
  -------------------                          -------------------
 /                   \                        /                   \
|                     |                      |                     |
|                     |                      |                     |
|                     |                      |                     |
|                 ++++++++ Multihop EBGP  ++++++++                 |
|                 +      +                +      +                 |
|                 +      +                +      +                 |
|                 + RGW  +<----MP-BGP---->+ RGW  +                 |
|                 +      +                +      +                 |
|                 +      +                +      +                 |
|                 ++++++++                ++++++++                 |
|                     |                      |                     |
|                     |                      |                     |
|                     |                      |                     |
|                     |                      |                     |
|                     |                      |                     |
|                 ++++++++ Канал между AS++++++++                  |
|                 +      +_______________+      +                  |
|                 +      +               +      +                  |
|                 + ASBR +               + ASBR +                  |
|                 +      +               +      +                  |
|                 +      +_______________+      +                  |
|                 ++++++++               ++++++++                  |
|                     |                      |                     |
|                     |                      |                     |
|                     |                      |                     |
|                 ++++++++ Канал между AS++++++++                  |
|                 +      +_______________+      +                  |
|                 +      +               +      +                  |
|                 + ASBR +               + ASBR +                  |
|                 +      +               +      +                  |
|                 +      +_______________+      +                  |
|                 ++++++++               ++++++++                  |
|                     |                      |                     |
|                     |                      |                     |
 \                   /                        \                   /
  -------------------                          -------------------

Рисунок 27. Вариант C для NNI.


С точки зрения сервиса VPN вариант C для NNI очень похож на вариант B, поскольку используется сессия MP-BGP для обмена маршрутами VPN между AS. Различие состоит в том, что уровни пересылки и управления размещаются на разных узлах, поскольку сессия MP-BGP включает несколько этапов пересылки между шлюзами маршрутизации (RGW). С точки зрения сервиса VPN моделирование вариантов B и C выполняется идентично.

5.17. Применимость L2SM в межпровайдерской и междоменной оркестровке

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

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

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

Межпровайдерские управляющие соединения варианта (a) могут быть реализованы с использованием методов, описанных в параграфе 5.16 (например, определение NNI). Многосегментные соединения варианта (b) могут приводить к решениям для соединений между AS, похожим на схему (b) в разделе 10 [RFC4364]. Это можно реализовать путем «сшивания» соединений сайтов и сегментов сервиса в разных доменах. Например, сквозное соединение между сайтами 1 и 3 через множество доменов (скажем, городские сети) может быть организовано путем сшивания соединений доступа на сайте 1 с SEG1, SEG3, SEG4, а также с подключением к сети на сайте 3 (как показано на рисунке 28). Предполагается, что компонент оркестровки на рисунке 3 должен иметь представление о полной абстрактной топологии и доступности ресурсов. Это может основываться на планировании сети.

         ----------   ----------   ----------
        |          | |          | |          |
      +--+        +---+        +---+        +--+
Сайт 1|PE|==SEG1==|   |==SEG3==|   |==SEG4==|PE|Сайт 3
      +--+        +---+        |   |        +--+
        |          | |         |   |         |  ----------
        |          | |         |   |         | |          |
      +--+        +---+        |   |        +---+        +--+
Сайт 2|PE|==SEG2==|   |==SEG5==|   |==SEG6==|   |==SEG7==|PE|Сайт 4
      +--+        +---+        +---+        +---+        +--+
        |          | |          | |          | |          |
         ----------   ----------   ----------   ----------

Рисунок 28. Пример межпровайдерской и междоменной оркестровки.


Отметим, что SEG1, SEG2, SEG3, SEG4, SEG5 и SEG6 можно рассматривать как подключения доступа на сайте и они могут быть созданы как подключения обычных сайтов с использованием L2SM.

На рисунке 28 протокол BGP служит для распространения L2VPN NLRI69 из одной AS в соседнюю. Сначала маршрутизаторы PE используют BGP для распространения L2VPN NLRI маршрутизаторам ASBR или рефлекторам маршрутов, клиентами которых являются ASBR. Затем ASBR использует BGP для распространения этих L2VPN NLRI маршрутизатору ASBR в другой AS, который далее распространит их маршрутизаторам PE в своей AS или, возможно, другим ASBR, которые разошлют анонсы дальше.

В этом случае PE может узнать адрес маршрутизатора ASBR, через который доступендругой PE, для организации соединения с последним. Т. е. локальный PE будет получать анонс BGP с L2VPN NLRI для экземпляра L2VPN, где у локального PE есть подключенные участники. Следующим интервалом BGP в этом L2VPN NLRI будет ASBR локальной AS. Затем вместо создания управляющего соединения через весь путь с удаленным PE, локальный PE создаст соединение лишь с ASBR, т. е. сегмент соединения от PE до ASBR. Маршрутизатор ASBR может организовать соединение с ASBR в следующей AS, а затем «сшить» с соединением от PE, как описано в [RFC6073]. Повторение процедуры на каждом ASBR создаст цепочку соединений, которая после «сшивания» свяжет два маршрутизатора PE.

Отметим, что при описанном подходе локальный маршрутизатор PE может никогда не узнать IP-адрес удаленного PE. Он знает L2VPN NLRI из анонсов удаленного PE, который не обязан включать адрес удаленного PE, и знает IP-адрес ASBR, который служит следующим интервалом BGP для данного NLRI.

При использовании такого подхода для VPLS или полносвязной (full-mesh) VPWS возникает полносвязный набор соединений между PE, но полносвязные управляющие соединения (сессии LDP или L2TPv3) не требуются. Вместо этого управляющие соединения внутри AS организуются между всеми PE данной AS и маршрутизаторами ASBR этой AS. Одно управляющее соединение между ASBR смежных AS может поддерживать множество сегментов соединений AS-AS, если они нужны.

6. Взаимодействие с другими модулями YANG

Как разъяснено в разделе 4, эта модель сервиса не предназначена для элементов сети, а реализуется в системе управления.

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

  1. компонент, отвечающий за модель сервиса (назовем его сервисным компонентом);

  2. компонент, отвечающий за настройку элементов сети (назовем его конфигурационным компонентом).

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

В разделе 7 приведен пример трансляции запросов на предоставление сервиса в строки конфигурации маршрутизатора. В экосистеме на основе YANG предполагается использование NETCONF и YANG между конфигурационным компонентом и сетевыми элементами для настройки запрошенного сервиса на этих элементах.

В этой схеме предполагается, что модели данных YANG будут применяться для настройки компонент сервиса на элементах сети. Будет существовать тесная связь между абстрактным представлением, обеспечиваемым этой моделью сервиса, и детальным представлением конфигурации, которое будет обеспечиваться конкретными моделями конфигурации для элементов сети, такими как определены в [MPLS-L2VPN-YANG] и [EVPN-YANG]. Компоненты сервиса, для которых нужна настройка элементов сети для поддержки определенной здесь модели сервиса, включают:

  • определения экземпляров сетей, которые включают правила VPN;

  • физические интерфейсы;

  • параметры уровня Ethernet (например, идентификаторы VLAN);

  • QoS (классификация, профили и т. п.);

  • поддержка Ethernet Service OAM.

7. Пример использования модели сервиса

Как разъяснено в разделе 4, эта модель сервиса предназначена для реализации на уровне управления и не рассчитана на прямое использование элементами сети. Система управления служит центральной точкой настройки сервиса в целом.

В этом