Энциклопедия сетевых протоколов

http://www.icir.org/vern/

Аннотация

Этот документ задает стандартный алгоритм для отправителей TCP¹, который требуется использовать при расчете и поддержке таймера повторной передачи. Документ расширяет обсуждение параграфа 4.2.3.1 в RFC 1122 и обновляет требование к поддержке алгоритма со следует на должно. Документ отменяет действие RFC 2988.

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

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

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

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

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

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

1. Введение

Протокол управления передаче (TCP) [Pos81] использует таймер повтора для обеспечения доставки данных в отстутсвие обратной связи от удаленного получателя. Длительность этого таймера называют RTO (retransmission timeout). В RFC 1122 [Bra89] указано, что значение RTO следует рассчитывать в соответствии с [Jac88].

В этом документе представлен алгоритм установки RTO. Кроме того, здесь расширено обсуждение параграфа 4.2.3.1 в 1122 и изменено требование к поддержке алгоритма со следует на должно. В RFC 5681 [APB09] описан алгоритм, используемый TCP для начала передачи после завершения RTO и отправки повтора. Данный документ не меняет поведения, описанного в RFC 5681 [APB09].

В некоторых ситуациях отправителю TCP может быть выгодно быть более консервативным, нежели позволяет описанный в этом документе алгоритм. Однако TCP недопустимо быть более энергичным (агрессивным) нежели позволяет описанный здесь алгоритм. Этот документ отменяет действие RFC 2988 [PA00].

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

2. Базовый алгоритм

Для расчете текущего RTO отправитель TCP поддерживает две переменные состояний — SRTT (сглаженное время кругового обхода) и RTTVAR (вариации времени кругового обхода). Предполагается дискретность часов G секунд.

Правила расчета SRTT, RTTVAR и RTO приведены ниже.

На время измерения периода кругового обхода (RTT) для сегмента, переданного отправителем, ему следует установить RTO не более 1 секунды, хотя указанное в (5.5) увеличение тайм-аута сохраняется.

Отметим, что в предыдущей версии документа использовалось начальное значение RTO = 3 сек. [PA00]. Реализация TCP может продолжать использовать это значение (или любое другое больше 1 сек.). Изменение нижней границы начального значения RTO обсуждается в Приложении A.
При первом измерении RTT (R) хост должен установить

            SRTT <- R
            RTTVAR <- R/2
            RTO <- SRTT + max (G, K*RTTVAR)

где K = 4.

При последующем измерении RTT (R’) хост должен установить

            RTTVAR <- (1 - beta) * RTTVAR + beta * |SRTT - R'|
            SRTT <- (1 - alpha) * SRTT + alpha * R'

Используемое для обновления RTTVAR значение SRTT — это значение самого SRTT до обновления с использованием второго назначения, т. е. обновление значений RTTVAR и SRTT должно выполняться в указанном порядке.

Указанные выше расчеты следует выполнять со значениями alpha=1/8 и beta=1/4 (в соответствии с [JK88]).

После расчета хост должен обновить RTO <- SRTT + max (G, K*RTTVAR)

Если при расчете RTO получается значение меньше 1 сек., его следует округлять до 1 сек.

Традиционно реализации TCP используют грубые часы для измерения RTT и запуска RTO, что ведет к большому минимальному значению RTO. Исследования показывают, что для сохранения умеренности (консервативности) TCP и предотвращения ненужных повторов требуется большое значение минимального RTO [AP99]. Поэтому данная спецификация требует большого минимального значения RTO в качестве умеренного подхода, но признает что в будущем исследования могут показать иное.
Для RTO можно задать максимальное значение, но оно должно быть не больше 60 сек.

3. Выборка RTT

В TCP должен применяться алгоритм Karn [KP87] для выборки RTT, т. е. выборку RTT недопустимо делать с использованием повторно передаваемых сегментов (неясно, к какому из сегментов относится полученный отклик). Единственным случаем, когда TCP может безопасно делать выборку RTT с повторно передаваемым сегментом, является применение опции TCP [JBB92], поскольку временные метки устраняют неоднозначность подтверждений.

Традиционно реализации TCP выполняют одно измерение RTT за раз (обычно за период RTT). Однако при использовании временных меток каждое подтверждение (ACK) может служить для выборки RTT. В RFC 1323 [JBB92] предполагается, что соединениям TCP с большим окном насыщения следует выполнять многократную выборку RTT в окне данных для предотвращения эффекта сглаживания RTT. Реализация TCP должна выполнять не менее 1 измерения RTT за период RTT (если это не противоречит алгоритму Karn).

При небольшом окне насыщения исследования показывают, что синхронизация каждого сегмента не улучшает точность оценки RTT [AP99]. Кроме того, при многократной выборке за период RTT, значения alpha и beta, определенные в разделе 2 могут содержать неадекватную историю RTT. Метод изменения значений этих констант в настоящее время остается темой для изучения.

4. Дискретность часов

К уровню дискретности часов G, используемому для измерения RTT и разных переменных состояния не предъявляется каких-либо требований. Однако, если при расчете RTO значение K*RTTVAR = 0, элемент дисперсии должен округляться до G сек. (т. е. должно использоваться уравнение из 2.3).

       RTO <- SRTT + max (G, K*RTTVAR)

Опыт показывает, что менее дискретные часы (<= 100 мсек) дают несколько лучший результат.

Отметим, что в [Jac88] описано несколько хитростей, которые могут повысить точность при использовании грубых часов. Эти методы широко применяются в современных реализациях TCP.

5. Поддержка таймера RTO

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

При каждой отправке пакета с данными (включая повторы) запускается таймер на время RTO (текущее), если он еще на запущен.
Таймер отключается после подтверждения всех ожидающих этого данных.
При получении ACK с подтверждением новых данных таймер перезапускается на время RTO (текущее).

При завершении отсчета таймера повтора выполняются перечисленные ниже действия.

Повторяется передача самого раннего из неподтвержденных получателем TCP сегментов.
Хост должен установить RTO не более RTO*2 (выключение таймера). Максимальное значение, указанное в (2.5), может задавать верхнюю границу для удвоения.
Запускается таймер на время RTO (удвоенное в соответствии с 5.5 значение RTO).
Если отсчет таймера завершается в ожидании ACK для сегмента SYN и реализация TCP применяет RTO меньше 3 сек., значение RTO должно быть увеличено до 3 сек. В начале передачи данных (после 3-этапного согласования).

Это отличается от предложенного в прежней версии документа [PA00] и рассмотрено в Приложении A.

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

Реализация TCP может сбросить SRTT и RTTVAR после многократного изменения (backoff) таймера, поскольку в этой ситуации вполне вероятна некорректность текущих значений SRTT и RTTVAR. После сброса этих значений их следует инициализировать следующей выборкой RTT в соответствии с правилом 2.2, а не 2.3.

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

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

Internet в значительной степени полагается на корректную реализацию алгоритма RTO (а также описанных в RFC 5681 алгоритмов) для сохранения стабильности сети и предотвращении перегрузок. Злоумышленник может вынудить конечные точки TCP более энергично реагировать на перегрузку, создавая подтверждения до того, как получатель реально примет данные, что ведет к небезопасному снижению RTO. Но для этого требуется аккуратно подделать подтверждения, что достаточно сложно, если злоумышленник не может отслеживать трафик на пути между отправителем и получателем. Кроме того, даже если злоумышленник сможет вынудить отправителя к снижению RTO, представляется, что это не поможет усилить атаку (по сравнению с другими повреждениями, которые могут нанести соединению подставные пакеты), поскольку отправитель TCP будет возвращать значение таймера при потере некорректно переданных пакетов в результате реальной перегрузки.

Рассмотренные в RFC 5681 [APB09] вопросы безопасности применимы и к данному документу.

7. Отличия от RFC 2988

Этот документ снижает начальное значение RTO с 3 секунд [PA00] до 1, если только не были потеряны SYN или ACK для SYN, когда следует возвращаться к принятому ранее значению RTO (3 сек.) до начала передачи данных.

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

Описанный в этом документе алгоритм RTO предложен Van Jacobson в работе [Jac88].

Большинство данных, вызвавших замену начального значения RTO (с 3 секунд на 1), получено от Robert Love, Andre Broido и Mike Belshe.

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

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

[APB09] Allman, M., Paxson, V., and E. Blanton, «TCP Congestion Control», RFC 5681, September 2009.

[Bra89] Braden, R., Ed., «Requirements for Internet Hosts — Communication Layers», STD 3, RFC 1122, October 1989.

[Bra97] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, March 1997.

[JBB92] Jacobson, V., Braden, R., and D. Borman, «TCP Extensions for High Performance», RFC 1323, May 1992.

[Pos81] Postel, J., «Transmission Control Protocol», STD 7, RFC 793, September 1981.

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

[AP99] Allman, M. and V. Paxson, «On Estimating End-to-End Network Path Properties», SIGCOMM 99.

[Chu09] Chu, J., «Tuning TCP Parameters for the 21st Century», http://www.ietf.org/proceedings/75/slides/tcpm-1.pdf, July 2009.

[SLS09] Schulman, A., Levin, D., and Spring, N., «CRAWDAD data set umd/sigcomm2008 (v. 2009-03-02)», http://crawdad.cs.dartmouth.edu/umd/sigcomm2008, March, 2009.

[HKA04] Henderson, T., Kotz, D., and Abyzov, I., «CRAWDAD trace dartmouth/campus/tcpdump/fall03 (v. 2004-11-09)», http://crawdad.cs.dartmouth.edu/dartmouth/campus/tcpdump/fall03, November 2004.

[Jac88] Jacobson, V., «Congestion Avoidance and Control», Computer Communication Review, vol. 18, no. 4, pp. 314-329, Aug. 1988.

[JK88] Jacobson, V. and M. Karels, «Congestion Avoidance and Control», ftp://ftp.ee.lbl.gov/papers/congavoid.ps.Z.

[KP87] Karn, P. and C. Partridge, «Improving Round-Trip Time Estimates in Reliable Transport Protocols», SIGCOMM 87.

[PA00] Paxson, V. and M. Allman, «Computing TCP’s Retransmission Timer», RFC 2988, November 2000.

Приложение A. Обоснование снижения Initial RTO

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

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

Традиционно в TCP устанавливается начальное значение RTO 3 секунды [Bra89] [PA00]. Данный документ предлагает снизить его до 1 секунды с учетом приведенных ниже оснований.

Современные сети быстрее, чем были в момент выбора начального значения RTO 3 секунды.
Исследования показали, что время кругового обхода более чем для 97,5% крупномасштабных наблюдений составляет менее 1 сек. [Chu09], что позволяет счесть значение 1 сек. подходящим по критерию 1 см. (выше).
Кроме того, исследования показали, что наблюдаемая частота повторов передачи при 3-этапном согласовании составляет около 2%. Это говорит, что снижение начального RTO даст преимущества большинству соединений.
Однако примерно 2,5% соединений, исследованных в [Chu09], использовали RTT больше 1 секунды. Для таких соединений 1 секунда в качестве начального RTO гарантирует повтор передачи при организации соединения (он может оказаться ненужным).Для таких случаев документ предлагает использовать прежнее значение RTO (3 сек.) в фазе передачи данных. Поэтому влияние ложных повторов передачи будет незначительным — (1) в сеть передается дополнительный пакет SYN и (2) в соответствии с RFC 5681 [APB09] начальное окно насыщения будет ограничено 1 сегментом. Хотя обстоятельство (2) явно ставит такие соединения в невыгодное положение, этот документ по меньшей мере задает сброс RTO, чтобы соединение не сталкивалось постоянно с проблемами из-за короткого тайм-аута (при RTT больше 3 сек. проблемы в соединении сохранятся, но это не создает новых проблем для TCP).Кроме того, отмечено, что при использовании временных меток TCP может сделать выборку RTT даже при наличии ложных повторов, облегчая сходимость к корректной оценке RTT для значений больше 1 секунды.

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

Имя	Период измерения	Число пакетов	Число соединений	Число клиентов	Число серверов
LBL-1	10.2005 — 03.2006	292M	242K	228	74K
LBL-2	11.2009 — 02.2010	1.1B	1.2M	1047	38K
ICSI-1	11-18.09.2007	137M	2.1M	193	486K
ICSI-2	11-18.09.2008	163M	1.9M	177	277K
ICSI-3	14-21.09.2009	334M	3.1M	170	253K
ICSI-4	11-18.09.2010	298M	5M	183	189K
Dartmouth	4-21.01.2004	1B	4M	3782	132K
SIGCOMM	17-21.08.2008	11.6M	133K	152	29K

Данные LBL были получены в Lawrence Berkeley National Laboratory, ICSI — в International Computer Science Institute, SIGCOMM — из беспроводной сети для участников конференции SIGCOMM 2008 и Dartmouth — из беспроводной сети Dartmouth College. Две последних базы данных доступны в хранилище CRAWDAD [HKA04] [SLS09]. В таблице указаны даты сбора данных, число отобранных пакетов, число наблюдаемых соединений TCP, число отслеживаемых локальных клиентов и число удаленных серверов, с которыми были контакты. Рассматривались только соединения, инициированные вблизи точки отслеживания.

Анализ этих данных показывает, что распространенность повторной передачи SYN составляет от 0,03% (ICSI-4) приблизительно до 2% (LBL-1 и Dartmouth).

Затем данные были проанализированы для определения числа добавочных и ложных повторов передачи, которые могли бы возникнуть при начальном RTO в 1 сек. В большинстве баз данных доля соединений с ложными повторами была меньше 0,1%. Однако в данных Dartmouth около 1,1% соединений передавали ненужные повторы при снижении начального значения RTO. Это было связано с тем, что наблюдаемая сеть была беспроводной и в ней возникали добавочные задержки из-за радиочастотных эффектов.

Очевидно, что преимущество повторной передачи потерянных пакетов SYN растет при уменьшении начального RTO. В рассмотренных данных доля соединений с повтором SYN, позволившим повысить производительность по меньшей мере на 10% за счет сниженного в соответствии с этим документом начального значения RTO, составила от 43 (LBL-1) до 87% (ICSI-4). Доля соединений, которые могут повысить производительно как минимум на 50%, составила от 17 (ICSI-1 и SIGCOMM) до 73% (ICSI-4).

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

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

Vern Paxson

ICSI/UC Berkeley

1947 Center Street

Suite 600

Berkeley, CA 94704-1198

Phone: 510-666-2882

EMail: vern@icir.org

Mark Allman

ICSI

1947 Center Street

Suite 600

Berkeley, CA 94704-1198

Phone: 440-235-1792

EMail: mallman@icir.org

http://www.icir.org/mallman/

H.K. Jerry Chu

Google, Inc.

1600 Amphitheatre Parkway

Mountain View, CA 94043

Phone: 650-253-3010

EMail: hkchu@google.com

Matt Sargent

Case Western Reserve University

Olin Building

10900 Euclid Avenue

Room 505

Cleveland, OH 44106

Phone: 440-223-5932

EMail: mts71@case.edu

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

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

1Transmission Control Protocol — протокол управления передачей.

2Internet Engineering Task Force.

3Internet Engineering Steering Group.

Рубрика: RFC | Комментарии отключены

RFC 6264 An Incremental Carrier-Grade NAT (CGN) for IPv6 Transition

Опубликовано 02.06.2011 автором Nikolai Malykh

Internet Engineering Task Force (IETF)                          S. Jiang
Request for Comments: 6264                                        D. Guo
Category: Informational                                           Huawei
ISSN: 2070-1721                                             B. Carpenter
                                                  University of Auckland
                                                               June 2011

Инкрементная модель CGN для перехода на IPv6

An Incremental Carrier-Grade NAT (CGN) for IPv6 Transition

Аннотация

Глобальное развертывание IPv6 оказалось значительно более медленным, нежели предполагалось. По мере исчерпания адресов IPv4 вопросы перехода с IPv4 на IPv6 становятся все более важными и решаются сложнее. Механизмы перехода на уровне хостов, использующие среду с двумя стеками протоколов, не могут удовлетворить все требования. Большинство конечных пользователей не имеет опыта, требуемого для настройки и поддержки таких механизмов. Устройства CGN¹ со встроенными механизмами перехода могут снизить операционные издержки в период перехода с IPv4 на IPv6 и совместного использования обоих протоколов.

В этом документе предлагается инкрементная модель CGN для перехода на IPv6. Эта модель позволяет обеспечить услуги доступа к IPv6 для хостов IPv6 и услуги доступа к IPv4 для хостов IPv4, обеспечивая существующим ISP возможность не менять свою сетевую инфраструктуру на начальном этапе перехода от IPv4 к IPv6. В отличие от CGN, как таковой, инкрементная модель CGN также поддерживает плавный переход (и способствует ему) к сетям ISP² с двумя стеками протоколов или только IPv6. Описаны интегрируемое настраиваемое устройство CGN и адаптивный домашний шлюз (HG³). Оба типа устройств могут использоваться на разных стадиях перехода, что избавляет от необходимости многократного обновления устройств. Такое решение позволяет постепенно переходить на IPv6 в соответствии с реальными потребностями пользователей.

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

Этот документ не является спецификацией проекта стандарта Internet и публикуется с информационными целями.

Документ является результатом работы IETF⁴ и представляет согласованное мнение сообщества IETF. Документ был вынесен на открытое обсуждение и одобрен для публикации IESG⁵. Не все документы, одобренные IESG, претендуют на статус тех или иных стандартов Internet (см. раздел 2 документа RFC 5741).

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

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

1. Введение

Глобального перехода на Ipv6, как прогнозировалось 10 лет назад, не произошло. Сетевые операторы не решились сделать первый шаг, поскольку IPv4 работал и продолжает работать хорошо. Однако полное истощение адресов IPv4 неизбежно. Этот вопрос анализируется в динамически обновляемом документе IPv4 Address Report⁶ [IPUSAGE]. Пул нераспределенных адресов IANA закончился в феврале 2011 года и на момент публикации данного документа указанный сайт предсказывал неизбежное истощение адресных пулов региональных регистраторов (RIR⁷). С учетом этих обстоятельств похоже, что индустрия Internet достигла согласия по вопросу неизбежности глобального развертывания IPv6 и необходимости сделать это как можно скорее.

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

Системы трансляции адресов на уровне оператора (CGN⁸) [CGN-REQS], которые называют также NAT444 CGN и Large Scale NAT, позволяют решить эксплуатационные проблемы IPv4, но никак не способствуют переходу с IPv4 на IPv6. Развертывание NAT444 CGN позволяет ISP отложить переход и, следовательно, вдвое повышает расходы, связанные с переходом (сначала на добавление CGN, а потом на поддержку IPv6).

Реализации CGN, интегрирующие множество механизмов перехода, могут упростить операции по обслуживанию конечных пользователей в процессе перехода с IPv4 на IPv6 и в период сосуществования протоколов. Системы CGN развертываются на стороне сети и управляются/поддерживаются профессионалами. На пользовательской стороне могут потребоваться домашние шлюзы (HG). Эти устройства могут предоставляться пользователям операторами в зависимости от конкретных бизнес-моделей. Упрощенные устройства с двумя стеками протоколов (DS-Lite⁹) [DS-LITE] представляют собой основанное на CGN решение, которое поддерживает переход, но требуют от ISP незамедлительно перевести свою сеть на IPv6. Многие ISP не решаются сделать этот первый шаг. Теоретически устройства DS-Lite можно использовать с двойной инкапсуляцией (IPv4-in-IPv6-in-IPv4), но такое решение вряд ли будет принято ISP и не рассматривается в этом документе.

Данный документ предлагает инкрементную модель CGN для перехода на IPv6. В документе не определяются новые протоколы или механизмы, но описано использование комбинации имеющихся предложений для постепенного перехода. Модель похожа на DS-Lite, но работает иначе. Она, прежде всего, объединяет функции трансляции v4-v4 NAT с туннелированием v6-over-v4. Эта модель позволяет обеспечить услуги доступа IPv6 для хостов, поддерживающих IPv6 и услуги IPv4 для хостов IPv4 без изменения инфраструктуры IPv4 сервис-провайдера (ISP). Развертывание этой технологии не оказывает никакого влияния на унаследованные хосты IPv4 с глобально доступными адресами IPv4. Технология подходит для начальной стадии перехода с IPv4 на IPv6. Она также поддерживает переход к сетям ISP с двумя стеками протоколов и сетям, использующим только IPv6.

В документе описан также механизм постепенного перехода. Этот механизм использует интегрируемые и настраиваемые устройства CGN, а также адаптивные устройства HG. Оба типа устройств (CGN и HG) могут использоваться на разных стадиях перехода и не потребуют замены. Это позволяет переходить на IPv6 постепенно в соответствии с реальными потребностями пользователей.

2. Инкрементная модель CGN

Сегодня большинство пользователей работает с адресами IPv4. Сервис-провайдеры начинают предоставлять услуги доступа IPv6 конечным пользователям. На начальном этапе перехода от IPv4 к IPv6 связность и трафик IPv4 будут сохранять свое присутствие (и преобладание) в сетях большинства ISP. Сервис-провайдеры хотят минимизировать изменения в своих сетях IPv4. Переход всей сети ISP на использование только IPv6 будет рассматриваться, как радикальная стратегия. Переход всей сети ISP на использование двух протоколов не столь радикален, но усложняет сеть и требует дополнительных расходов. Хотя некоторые ISP успешно развернули сети с двумя протоколами, остальные предпочитают не делать этого в качестве первого этапа своего перехода на IPv6. Однако в настоящее время требуется достаточно срочно решать две проблемы — преодоление текущего дефицита адресов IPv4 путем развертывания того или иного механизма совместного использования адресов и подготовки к активному использованию адресного пространства и услуг IPv6. ISP решают одну из двух проблем путем адаптации CGN (для преодоления дефицита адресов IPv4) или 6rd (для предоставления услуг подключения по IPv6). Описанная здесь модель предназначена для решения обеих проблем за счет комбинирования технологий v4-v4 CGN и туннелирования v6-over-v4.

2.1. Обзор инкрементной модели CGN

Инкрементная модель CGN, предлагаемая здесь, схематически показана на рисунке 1.

Как показано на рисунке 1, ISP не требуется существенно менять свою сеть IPv4. Эта модель обеспечивает хостам IPv4 доступ в сеть IPv4 Internet, а хостам IPv6 — доступ в сеть IPv6 Internet. Хосты с двумя стеками протоколов трактуются, как хосты IPv4, при использовании ими услуг доступа IPv4 и, как хосты Ipv6, при использовании услуг доступа IPv6. Для обеспечения хостам IPv4 возможности доступа в сеть IPv6 Internet, а хостам IPv6 — в сеть IPv4 Internet можно интегрировать NAT64 с CGN (более подробное описание взаимодействия IPv4/IPv6 приведено в параграфе 2.6). Рассмотрение интеграции таких механизмов выходит за пределы этого документа.

                              +-------------+
                              |IPv6 Internet|
                              +-------------+
                                     |
                     +---------------+----------+
+-----+   +--+       |  Сеть IPv4 +--+--+       |   +--------+
|Хост |---|DS|=======+============| CGN |-------+---|  IPv4  |
|v4/v6|   |HG|       |    ISP     +-----+   |   |   |Internet|
+-----+   +--+       +----------------------+---+   +--------+
             _ _ _ _ _ _ _ _ _ _ _          |
           ()_Туннель_6_over_4_ _____() +-----------------------+
                                        |Существующие хосты IPv4|
                                        +-----------------------+

Рисунок 1 Инкрементная модель CGN для сети IPv4 Internet-провайдера
DS HG — домашний шлюз с двумя протоколами (CPE — оборудование на стороне пользователя).

В рассматриваемой модели нужны два типа устройств: домашние шлюзы с двумя стеками протоколов (HG) и устройства CGN с двумя стеками. Домашние шлюзы с двумя стеками протоколов интегрируют пересылку для протоколов IPv6 и IPv4 с функциями туннелирования v6-over-v4. Такие устройства следует выполнять в соответствии с требованиями [RFC6204], включая делегирование префиксов IPv6. Они могут также поддерживать функциональность v4-v4 NAT. Устройства CGN с двумя стеками протоколов интегрируют функции туннелирования v6-over-v4 и v4-v4 CGN, а также стандартную маршрутизацию IPv6 и IPv4.

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

2.2. Выбор технологии туннелирования

В принципе, эта модель будет работать с любой формой туннеля между HG с двойным стеком и CGN с двойным стеком. Однако туннели, требующие явной настройки, очевидно будут нежелательны ввиду связанных с ними операционных расходов. Следовательно, настраиваемые туннели [RFC4213] не подойдут. Туннельный брокер [RFC3053] также требует операционных расходов и будет нежелателен для домашних пользователей.

Технология 6rd [RFC5569, RFC5969] представляется подходящим решением для поддержки туннелей v6-over-v4 с низкими операционными расходами. Инкапсуляция GRE¹⁰ [RFC2784] с дополнительным механизмом автоматической настройки конфигурации также подходит для поддержки туннелей v6-over-v4. Могут рассматриваться и другие механизмы туннелирования типа 6over4 [RFC2529], 6to4 [RFC3056], ISATAP¹¹ [RFC5214] или VET¹² [RFC5558]. Если ISP имеет полнофункциональную инфраструктуру MPLS между HG и CGN с двойным стеком, можно использовать также туннели 6PE¹³ [RFC4798] непосредственно в MPLS. Однако это решение подойдет только для устройств HG с расширенными функциями, которые сложно отнести к числу потребительских устройств, поэтому оно не будет рассматриваться подробно. Для простоты предположим использование туннелей 6rd.

2.3. Поведение шлюза с двумя стеками протоколов

Когда домашний шлюз с двойным стеком протоколов принимает пакет от хоста, он будет квалифицировать этот пакет, как IPv4 или IPv6. Принятый пакет в зависимости от результата определения будет обрабатываться стеком IPv4 или IPv6. Для IPv4 при отсутствии на шлюзе HG трансляции адресов v4-v4 NAT стек будет просто пересылать пакет устройству CGN, в качестве которого в общем случае будет служить используемый по умолчанию маршрутизатор IPv4. Если на шлюзе включена трансляция v4-v4 NAT, HG изменит в заголовке пакета адрес отправителя с приватного адреса IPv4 в зоне действия HG на адрес IPv4 в зоне действия CGN, при необходимости выполнит трансляцию портов и перешлет пакет в направлении CGN. Шлюз HG будет сохранять данные о трансляции адресов и отображении портов v4-v4 для входящих пакетов, подобно другим системам NAT.

Для IPv6 шлюз HG должен инкапсулировать данные в туннель IPv4, для которого адресатом IPv4 служит устройство CGN с двойным стеком. HG передает новый пакет IPv4 в направлении CGN, используя (например) 6rd.

Если шлюз HG связан с множеством устройств CGN, он будет сохранять данные отображения между туннелем и адресом отправителя IPv6 для входящих пакетов. Подробное рассмотрение работы множества CGN с одним шлюзом HG оставлено на будущее.

Пакеты IPv4 от CGN и инкапсулированные пакеты IPv6 от CGN будут транслироваться или декапсулироваться в соответствии с сохраненными данными об отображении и пересылаться на пользовательскую сторону шлюза HG.

2.4. Поведение CGN с двумя стеками протоколов

Когда CGN с двойным стеком протоколов получает пакет данных IPv4 от домашнего шлюза с двойным стеком, он будет определять, является ли этот пакет обычным пакетом IPv4 (без инкапсуляции) или туннелируемым пакетом v6-over-v4, адресованным конечной точке туннеля внутри этого CGN. Для обычного пакета IPv4 устройство CGN транслирует адрес отправителя в пакете из области IPv4 этого CGN в публичный адрес IPv4, выполняя при необходимости отображение портов, и затем обычным путем пересылает этот пакет в IPv4 Internet. CGN записывает данные трансляции адресов v4-v4 и отображения портов для последующей обработки входящих пакетов, как это делают обычные устройства NAT. Для туннелируемый пакетов v6-over-v4 конечная точка туннеля в CGN будет декапсулировать пакет в обычный пакет IPv6 и затем пересылать его в IPv6 Internet. CGN записывает информацию об отображении туннеля на адреса отправителя IPv6 для последующей обработки входящих пакетов.

В зависимости от места установки CGN это устройство может использовать дополнительный туннель v6-over-v4 для подключения к IPv6 Internet.

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

2.5. Влияние на имеющиеся хосты и необновленные сети

Эта модель не оказывает никакого влияния на неизменяемые части сети ISP. Унаследованные сети IPv4 ISP и устройства IPv4 в них продолжат работать, как обычно. Имеющиеся хосты IPv4, показанные прямоугольником в нижнем правом углу на рисунке 1 и имеющие публичные (глобальные) адреса IPv4 или расположенные за трансляторами v4-v4 NAT, могут подключаться к IPv4 Internet обычным способом. Эти хосты при переходе к двойному стеку протоколов смогут подключаться к IPv6 Internet через сеть IPv4 ISP, используя туннелирование Ipv6-over-IPv4 (см. параграф 2.7, где рассмотрен размер MTU).

2.6. Связь между IPv4 и IPv6

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

Предполагается, IETF стандартизует рекомендуемый алгоритм перехода от IPv4 к IPv6, иногда называемый NAT64. Этот алгоритм описан в перечисленных ниже документах.

Framework for IPv4/IPv6 Translation [RFC6144];
IPv6 Addressing of IPv4/IPv6 Translators [RFC6052];
DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers [RFC6147];
IP/ICMP Translation Algorithm [RFC6145];
Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers [RFC6146];
An FTP ALG for IPv6-to-IPv4 Translation [FTP-ALG].

Сервис, как описано в документе IETF «Guidelines for Using IPv6 Transition Mechanisms during IPv6 Deployment» [RFC6180], обеспечивает трансляцию без учета состояний (stateless) между хостами в домене только-IPv4 или хостами, предоставляющими только услуги IPv4, и хостами с адресом IPv6, имеющими встроенный адрес IPv4 (IPv4-embedded IPv6), в домене только-IPv6. В дополнение к этому он обеспечивает доступ с хостов IPv6 с адресами общего формата к хостам в домене только-IPv4 или хостам, предоставляющим только услуги IPv4. Сервис не обеспечивает трансляции «все во все» (any-to-any). Одним из результатов является то, что хосты в домене IPv6 получают услуги IPv4 через трансляцию с учетом состояния (stateful). Другой результат состоит в том, что оператор сети IPv6 получает вариант переноса серверов в домен только-IPv6, сохраняя доступ к ним для клиентов только-IPv4 через трансляцию без учета состояния в адреса IPv6 со встроенными адресами IPv4.

Документ «Architectural Implications of NAT» [RFC2993] применим к службе так же, как к обычной трансляции IPv4/IPv4, с учетом того, что система с адресом IPv6, включающим адрес IPv4, доступна через NAT. Документ «Architectural Implications of NAT» [RFC2993] применяется к сервису просто как к трансляции IPv4/IPv4 за исключением того, что системы с адресом IPv6, содержащим IPv4, достижимы через NAT и в отличие от IPv4, любые допущения приложения о значимости локального адреса для удаленного партнера и любое использование адреса IP буквально в данных приложения являются прерогативой источника сервиса. В общем случае для снижения риска рекомендуются указанные ниже меры.

В идеале приложениям следует использовать имена DNS, а не адреса IP в идентификаторах URL, URI и ссылках, что обеспечит независимость от сетевого уровня.
Если этого не делается, сеть может предоставлять транслятор или прокси, охватывающий домены. Например, агент SMTP MTA¹⁴ с подключением IPv4 и IPv6 четко обрабатывает трансляцию IPv4/IPv6 на прикладном уровне.

2.7. Обсуждение

Для трафика IPv4 модель постепенного перехода CGN наследует все проблемы методов совместного использования адресов CGN [ADDR-ISSUES] (например, расширяемость и сложность поддержки общеизвестных портов для входящего трафика). Проблемы прикладного уровня, вызываемые двойным преобразованием NAT, выходят за рамки этого документа.

Для трафика IPv6 пользователи, находящиеся за DS HG, будут видеть обычный сервис IPv6. Было замечено, что MTU туннелей IPv6 размером не меньше 1500 байтов обеспечивает механизм, не вызывающий избыточной фрагментации трафика IPv6 или избыточных взаимодействий по определению IPv6 path MTU. Вместе с отсутствием проблем NAT для IPv6 это будет стимулом для пользователей и провайдеров приложений к переходу на IPv6.

Фильтрация ICMP [RFC4890] может быть включена как часть функций CGN.

3. Плавный переход к инфраструктуре IPv6

Переход от «чистого» NAT444 CGN или 6rd к инкрементному CGN прост. Устройства HG и CGN и их местоположение не меняются и может потребоваться лишь обновление программ. В описанной ниже идеальной модели не требуется даже обновления программ и достаточно лишь изменить конфигурацию. NAT444 CGN решает проблему нехватки публичных адресов в современной инфраструктуре IPv4. Однако это не способствует развертыванию IPv6 в целом. Инкрементный CGN может наследовать функции NAT444 CGN, обеспечивая при этом наложенные услуги IPv6. механизмы 6rd можно плавно преобразовать в эту инкрементную модель CGN. Однако домашние шлюзы придется обновить для выполнения описанных ниже действий.

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

Если ISP предпочтет перейти на маршрутизацию для двух протоколов (dual-stack routing), HG следует просто отключить свою функцию v6-over-v4 при наличии трафика IPv6 RA¹⁵ или DHCPv6 и пересылать трафик IPv6 и IPv4 напрямую, а в CGN с двумя стеками сохранить лишь функцию v4-v4 NAT.

Однако предполагается, что ISP выберут подход, описанный как инкрементный CGN в этом документе, поскольку это позволит избежать маршрутизации для двух протоколов и постепенно перейти от маршрутизации IPv4 к маршрутизации только IPv6. В этом случае идеальной модель для инкрементного CGN будет интегрированное настраиваемое устройство CGN и адаптивное устройство HG. Интегрированное устройство CGN сможет поддерживать множество функций, включая NAT444 CGN, маршрутизатор 6rd (или дополнительный механизм туннелирования), DS-Lite и пересылку для двух протоколов.

HG интегрирует соответствующие функции и сможет детектировать соответствующие инкрементные изменения на стороне CGN. Обычно HG будет время от времени опрашивать CGN для определения работающих функций. Например, начав с поддержки только IPv4 (в этом случае HG считает CGN принятым по умолчанию маршрутизатором IPv4), HG обнаружит (путем нечастого опроса) доступность 6rd. Тогда домашние пользователи будут получать адреса IPv6. Позднее HG обнаружит появление естественных сообщений IPv6 Route Advertisement или DHCPv6 для определения доступности сервиса IPv6, включая DS-Lite. Таким образом, когда ISP решит перейти от инкрементного CGN на DS-Lite CGN, потребуется лишь изменить конфигурацию и слегка обновить программы на устройствах CGN. Домашние шлюзы увидят эти изменения и автоматически переключатся в режим DS-Lite. Единственным влиянием на домашних пользователей будет изменение префикса IPv6.

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

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

Вопросы безопасности, связанные с NAT, были рассмотрены в [RFC2663] и [RFC2993]. Проблемы безопасности для крупномасштабного использования общих адресов, включая CGN, рассмотрены в [ADDR-ISSUES]. Этот документ не добавляет новых функций в CGN и поэтому не создает новых проблем безопасности. Вопросы безопасности 6rd рассмотрены в [RFC5569] и [RFC5969], а DS-Lite — в [DS-LITE].

Поскольку предложенные здесь туннели полностью размещаются в сети одного ISP между устройствами HG/CPE и CGN, модель угроз относительно проста. В [RFC4891] описана защита туннелей с использованием IPsec, но ISP могут обоснованно считать свою инфраструктуру достаточно защищенной без применения IPsec. Внутренние риски туннелей описаны в [RFC6169], где рекомендуется не передавать туннелируемый трафик через граничные маршрутизаторы. В инкрементной модели CGN эта рекомендация учтена. Для предотвращения других рисков, связанных с туннелями, важно, чтобы все механизмы защиты, основанные на проверке пакетов и все реализации входных фильтров применялись к пакетам IPv6 после их декапсуляции устройством CGN. Домашним шлюзам с двумя стеками протоколов нужно поддерживать базовые функции защиты для IPv6 [RFC6092]. Другие вопросы рассмотрены в[RFC4864].

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

Множество полезных замечаний было получено от Fred Baker, Dan Wing, Fred Templin, Seiichi Kawamura, Remi Despres, Janos Mohacsi, Mohamed Boucadair, Shin Miyakawa, Joel Jaeggli, Jari Arkko, Tim Polk, Sean Turner и других членов рабочей группы IETF V6OPS.

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

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

[RFC2529] Carpenter, B. and C. Jung, «Transmission of IPv6 over IPv4 Domains without Explicit Tunnels», RFC 2529, March 1999.

[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, «Generic Routing Encapsulation (GRE)», RFC 2784, March 2000.

[RFC5569] Despres, R., «IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)», RFC 5569, January 2010.

[RFC5969] Townsley, W. and O. Troan, «IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) — Protocol Specification», RFC 5969, August 2010.

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

[RFC2663] Srisuresh, P. and M. Holdrege, «IP Network Address Translator (NAT) Terminology and Considerations», RFC 2663, August 1999.

[RFC2993] Hain, T., «Architectural Implications of NAT», RFC 2993, November 2000.

[RFC3053] Durand, A., Fasano, P., Guardini, I., and D. Lento, «IPv6 Tunnel Broker», RFC 3053, January 2001.

[RFC3056] Carpenter, B. and K. Moore, «Connection of IPv6 Domains via IPv4 Clouds», RFC 3056, February 2001.

[RFC4213] Nordmark, E. and R. Gilligan, «Basic Transition Mechanisms for IPv6 Hosts and Routers», RFC 4213, October 2005.

[RFC4798] De Clercq, J., Ooms, D., Prevost, S., and F. Le Faucheur, «Connecting IPv6 Islands over IPv4 MPLS Using IPv6 Provider Edge Routers (6PE)», RFC 4798, February 2007.

[RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and E. Klein, «Local Network Protection for IPv6», RFC 4864, May 2007.

[RFC4890] Davies, E. and J. Mohacsi, «Recommendations for Filtering ICMPv6 Messages in Firewalls», RFC 4890, May 2007.

[RFC4891] Graveman, R., Parthasarathy, M., Savola, P., and H. Tschofenig, «Using IPsec to Secure IPv6-in-IPv4 Tunnels», RFC 4891, May 2007.

[RFC5214] Templin, F., Gleeson, T., and D. Thaler, «Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)», RFC 5214, March 2008.

[RFC5558] Templin, F., Ed., «Virtual Enterprise Traversal (VET)», RFC 5558, February 2010.

[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. Li, «IPv6 Addressing of IPv4/IPv6 Translators», RFC 6052, October 2010.

[RFC6092] Woodyatt, J., Ed., «Recommended Simple Security Capabilities in Customer Premises Equipment (CPE) for Providing Residential IPv6 Internet Service», RFC 6092, January 2011.

[RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, «Framework for IPv4/IPv6 Translation», RFC 6144, April 2011.

[RFC6145] Li, X., Bao, C., and F. Baker, «IP/ICMP Translation Algorithm», RFC 6145, April 2011.

[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, «Stateful NAT64: Network Address and Protocol Translation from Ipv6 Clients to IPv4 Servers», RFC 6146, April 2011.

[RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. Van Beijnum, «DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers», RFC 6147, April 2011.

[RFC6169] Krishnan, S., Thaler, D., and J. Hoagland, «Security Concerns with IP Tunneling», RFC 6169, April 2011.

[RFC6180] Arkko, J. and F. Baker, «Guidelines for Using IPv6 Transition Mechanisms during IPv6 Deployment», RFC 6180, May 2011.

[RFC6204] Singh, H., Beebee, W., Donley, C., Stark, B., and O. Troan, Ed., «Basic Requirements for IPv6 Customer Edge Routers», RFC 6204, April 2011.

[IPUSAGE] G. Huston, IPv4 Address Report, June 2011, http://www.potaroo.net/tools/ipv4/index.html.

[DS-LITE] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, «Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion», Work in Progress¹⁶, May 2011.

[ADDR-ISSUES] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. Roberts, «Issues with IP Address Sharing», Work in Progress¹⁷, March 2011.

[CGN-REQS] Perreault, S., Ed., Yamagata, I., Miyakawa, S., Nakagawa, A., and H. Ashida, «Common requirements for IP address sharing schemes», Work in Progress¹⁸, March 2011.

[FTP-ALG] van Beijnum, I., «An FTP ALG for Ipv6-to-IPv4 Translation», Work in Progress¹⁹, May 2011.

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

Sheng Jiang

Huawei Technologies Co., Ltd

Huawei Building, No.3 Xinxi Rd.,

Shang-Di Information Industry Base, Hai-Dian District

Beijing 100085

P.R. China

EMail: jiangsheng@huawei.com

Dayong Guo

Huawei Technologies Co., Ltd

Huawei Building, No.3 Xinxi Rd.,

Shang-Di Information Industry Base, Hai-Dian District

Beijing 100085

P.R. China

EMail: guoseu@huawei.com

Brian Carpenter

Department of Computer Science

University of Auckland

PB 92019

Auckland, 1142

New Zealand

EMail: brian.e.carpenter@gmail.com

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

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

1Carrier-Grade NAT — система трансляции сетевых адресов в масштабе оператора.

2Internet Service Provider. Прим. перев.

3Home gateway.

4Internet Engineering Task Force.

5Internet Engineering Steering Group.

6Отчет об адресах IPv4.

7Regional Internet Registry.

8Carrier-Grade NAT.

9Dual-stack lite.

10Generic Routing Encapsulation — базовая инкапсуляция маршрутной информации.

11Intra-Site Automatic Tunnel Addressing Protocol — протокол автоматической адресации туннелей внутри сайта.

12Virtual Enterprise Traversal — виртуальный проход через сеть предприятия.

13IPv6 Provider Edge.

14Mail Transfer Agent — агент доставки почты.

15Router Advertisement — анонс маршрутизатора.

16Работа опубликована в RFC 6333. Прим. перев.

17Работа опубликована в RFC 6269. Прим. перев.

18Работа опубликована в RFC 6888. Прим. перев.

19Работа опубликована в RFC 6384. Прим. перев.

Рубрика: RFC | Комментарии отключены

RFC 6253 Host Identity Protocol Certificates

Опубликовано 14.05.2011 автором Nikolai Malykh

Заменен RFC 8002.

Рубрика: RFC | Оставить комментарий

RFC 6126 The Babel Routing Protocol

Опубликовано 15.04.2011 автором Nikolai Malykh

Заменен RFC 8966.

Рубрика: RFC | Оставить комментарий

RFC 6265 HTTP State Management Mechanism

Опубликовано 15.04.2011 автором Nikolai Malykh

Internet Engineering Task Force (IETF)                          A. Barth
Request for Comments: 6265                                 U.C. Berkeley
Obsoletes: 2965                                               April 2011
Category: Standards Track
ISSN: 2070-1721

Механизм управления состоянием HTTP

HTTP State Management Mechanism

Аннотация

Этот документ определяет поля Cookie и Set-Cookie заголовка HTTP. Эти поля могут использоваться серверами HTTP для сохранения состояний (называемых cookie) на стороне пользовательских агентов HTTP, что позволяет серверам поддерживать состояния для протокола HTTP, который не поддерживает состояний. Хотя с переменными cookie исторически связано множество недостатков, снижающих уровни безопасности и приватности, поля заголовков Cookie и Set-Cookie широко используются в сети Internet. Данный документ отменяет действие RFC 2965.

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

Документ является проектом стандарт Internet (Internet Standards Track).

Документ является результатом работы IETF¹ и представляет согласованный взгляд сообщества IETF. Документ прошел открытое обсуждение и был одобрен для публикации IESG². Не все одобренные IESG документы претендуют на статус Internet Standard (см. раздел 2 в RFC 5741).

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

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

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

Документ может содержать материалы из IETF Document или IETF Contribution, опубликованных или публично доступных до 10 ноября 2008 года. Лица, контролирующие авторские права на некоторые из таких документов, могли не предоставить IETF Trust права разрешать внесение изменений в такие документы за рамками процессов IETF Standards. Без получения соответствующего разрешения от лиц, контролирующих авторские права этот документ не может быть изменен вне рамок процесса IETF Standards, не могут также создаваться производные документы за рамками процесса IETF Standards за исключением форматирования документа для публикации или перевода с английского языка на другие языки.

1. Введение

Этот документ определяет поля Cookie и Set-Cookie в заголовках HTTP. Используя поле Set-Cookie, сервер HTTP может передать пару «имя-значение» (name/value) и связанные метаданные (cookie) пользовательскому агенту. При последующем запросе этого агента к данному серверу, агент будет использовать метаданные и другую информацию, чтобы определить, нужно ли возвращать в заголовке Cookie пары «имя-значение».

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

Исторически с cookie связано множество вопросов конфиденциальности и приватности. Например, сервер может указать, что данное значение cookie предназначено для «защищенных» соединений, но атрибут Secure не обеспечивает защиты целостности от активных сетевых атак. Аналогично, значения cookie для данного хоста являются общими для всех портов хоста, хотя обычная политика «одного источника (same-origin policy), используемая браузерами, изолирует содержимое, полученное через разные порты.

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

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

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

Этот документ задает синтаксис и семантику заголовков, которые реально применяются в Internet. В частности, этот документ не определяет какого-либо нового синтаксиса или семантики. Рекомендации по созданию cookie в разделе 4 представляют предпочтительное подмножество свойств современных серверов и даже алгоритм более мягкой обработки cookie, описанный в разделе 5 не включает всех современных синтаксических и семантических вариаций. В тех случаях, когда существующие программы значительно отличаются от рекомендуемого протокола, документ дает соответствующие разъяснения.

До выпуска этого документа существовало по крайней мере три описания cookie — Netscape cookie specification [Netscape], RFC 2109 [RFC2109] и RFC 2965 [RFC2965]. Однако ни один из этих документов не описывал реального использования заголовков Cookie и Set-Cookie в сети Internet (см. [Kri2001]). В отношении предыдущих спецификаций IETF для механизмов управления состояниями HTTP данный документ запрашивает указанные ниже действия.

Перевести [RFC2109] в состояние Historic (документ уже отменен [RFC2965]).
Перевести [RFC2965] в состояние Historic.
Указать, что [RFC2965] отменен данным документом.

В частности, вместе с отменой RFC 2965 и переводом документа в состояние Historic, данный документ отменяет использование в заголовках полей Cookie2 и Set-Cookie2.

2. Соглашения

2.1. Критерии соответствия

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

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

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

2.2. Описание синтаксиса

В этой спецификации используются обозначения ABNF³ [RFC5234].

Используются определенные в Приложении B.1 [RFC5234] определения: ALPHA (буквы), CR (возврат каретки), CRLF (CR LF), CTL (элемент управления), DIGIT (десятичные цифры 0-9), DQUOTE (двойные кавычки), HEXDIG (шестнадцатеричные цифры 0-9/A-F/a-f), LF (перевод строки), NUL (октет со значением 0), OCTET (любая 8-битовая последовательность кроме NUL), SP (пробел), HTAB (горизонтальная табуляция), CHAR (любой символ [USASCII]), VCHAR (любой видимый (печатный) символ [USASCII]), WSP (пробел).

Правило OWS (необязательные пробелы) применяется в тех случаях когда может (но не обязательно) появляться некоторое число пробелов (linear whitespace).

   OWS            = *( [ obs-fold ] WSP ) ; «необязательный» пробел
   obs-fold       = CRLF

OWS следует создавать в виде одного символа SP или не создавать совсем.

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

Термины пользовательский агент, клиент, сервер, прокси и сервер-источник используются в том же смысле, который принят в спецификации HTTP/1.1 ([RFC2616], параграф 1.3).

Request-host указывает имя хоста, известное пользовательскому агенту, по которому этот агент отправляет запрос HTTP или с которого он получает отклик HTTP (т. е., хоста, которому он отправил соответствующий запрос HTTP).

Термин request-uri определен в параграфе 5.1.2 [RFC2616].

О двух последовательностях октетов говорят, что они совпадают без учета регистра, тогда и только тогда, когда они эквивалентны в сопоставлении i;ascii-casemap, определенном в [RFC4790].

Термин «строка» (string) обозначает последовательность октетов, отличающихся от NUL.

3. Обзор

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

Для сохранения состояния сервер-источник включает заголовок Set-Cookie в отклик HTTP. В последующих запросах пользовательский агент возвращает заголовок запроса Cookie серверу-источнику. Заголовок Cookie содержит значения cookie, которые пользовательский агент получил в предшествующих заголовках Set-Cookie. Сервер-источник может игнорировать заголовок Cookie или использовать его содержимое в своих целях, определяемых приложением.

Серверы-источники могут передавать заголовок Set-Cookie в любом отклике. Пользовательские агенты могут игнорировать заголовки Set-Cookie, содержащиеся в откликах с кодом уровня 100, но должны обрабатывать заголовки Set-Cookie, содержащиеся в других откликах (включая отклики с кодами уровней 400 и 500). Сервер-источник может включить в один отклик множество полей заголовка Set-Cookie. Наличие полей Cookie или Set-Cookie в заголовках не препятствует хранению откликов в кэше HTTP и их повторному использованию.

Серверам-источникам недопустимо помещать множество полей Set-Cookie в одно поле заголовка. Обычный механизм «упаковки» полей заголовков HTTP (определенный в [RFC2616]) может менять семантику полей заголовка Set-Cookie, поскольку символ %x2C (,) используется в Set-Cookie так, что может вызывать конфликт с такой «упаковкой».

3.1. Примеры

Используя заголовок Set-Cookie, сервер может передать пользовательскому агенту короткую строку в отклике HTTP, которую этот агент будет возвращать в последующих запросах HTTP, попадающих в область действия cookie. Например, сервер может передать пользовательскому агенту идентификатор сессии с именем SID и значением 31d4d96e407aad42. Пользовательский агент будет возвращать этот идентификатор в последующих запросах.

   == Сервер -> Пользовательский агент ==
   Set-Cookie: SID=31d4d96e407aad42

   == Пользовательский агент -> Сервер ==
   Cookie: SID=31d4d96e407aad42

Сервер может поменять принятую по умолчанию область действия cookie, используя атрибуты Path и Domain. Например, сервер может дать пользовательскому агенту инструкцию возвращать cookie для каждого пути и каждого субдомена в example.com.

   == Сервер -> Пользовательский агент ==
   Set-Cookie: SID=31d4d96e407aad42; Path=/; Domain=example.com

   == Пользовательский агент -> Сервер ==
   Cookie: SID=31d4d96e407aad42

Как показано в следующем примере, сервер может сохранить множество cookie на стороне пользовательского агента. Например, сервер может сохранить идентификатор сессии, а также предпочитаемый пользователем язык, возвращая два поля заголовка Set-Cookie. Обратите внимание на то, что сервер использует атрибуты Secure и HttpOnly для обеспечения дополнительной защиты идентификатора сессии (см. параграф 4.1.2).

   == Сервер -> Пользовательский агент ==
   Set-Cookie: SID=31d4d96e407aad42; Path=/; Secure; HttpOnly
   Set-Cookie: lang=en-US; Path=/; Domain=example.com

   == Пользовательский агент -> Сервер ==
   Cookie: SID=31d4d96e407aad42; lang=en-US

Обратите внимание, что заголовок Cookie содержит два значения cookie с именами SID и lang. Если сервер хочет, чтобы пользовательский агент сохранял значения cookie на протяжении нескольких «сессий» (например, при перезапуске пользовательского агента), он может задать срок действия с помощью атрибута Expires. Отметим, что пользовательский агент может удалить cookie до истечения срока действия, если в хранилище cookie не будет достаточно места или пользователь вручную удалит cookie сервера.

   == Сервер -> Пользовательский агент ==
   Set-Cookie: lang=en-US; Expires=Wed, 09 Jun 2021 10:18:14 GMT

   == Пользовательский агент -> Сервер ==
   Cookie: SID=31d4d96e407aad42; lang=en-US

В заключение отметим, что сервер может удалить cookie, возвращая заголовок Set-Cookie с уже завершившимся сроком действия. Сервер сможет удалить cookie только в том случае, когда атрибуты Path и Domain в заголовке Set-Cookie соответствуют значениям, использованным при создании cookie.

   == Сервер -> Пользовательский агент ==
   Set-Cookie: lang=; Expires=Sun, 06 Nov 1994 08:49:37 GMT

   == Пользовательский агент -> Сервер ==
   Cookie: SID=31d4d96e407aad42

4. Требования к серверу

В этом разделе описаны синтаксис и семантика хорошо себя зарекомендовавшего профиля заголовков Cookie и Set-Cookie.

4.1. Заголовок Set-Cookie

Заголовок Set-Cookie в откликах HTTP служит для передачи cookie от сервера к пользовательскому агенту.

4.1.1. Синтаксис

Неформально заголовок отклика Set-Cookie содержит имя заголовка (Set-Cookie), за которым следует символ двоеточия (:) и cookie. Каждое поле cookie начинается с пары «имя-значение», за которым могут следовать дополнительные пары «имя-значение». Серверам недопустимо передавать заголовки Set-Cookie, не соответствующие приведенным ниже правилам.

 set-cookie-header = "Set-Cookie:" SP set-cookie-string
 set-cookie-string = cookie-pair *( ";" SP cookie-av )
 cookie-pair       = cookie-name "=" cookie-value
 cookie-name       = token
 cookie-value      = *cookie-octet / ( DQUOTE *cookie-octet DQUOTE )
 cookie-octet      = %x21 / %x23-2B / %x2D-3A / %x3C-5B / %x5D-7E
                       ; символы US-ASCII, включая CTL, пробельный
                       ; DQUOTE, запятую, точку с запятой и \
 token             = <token, определенный в параграфе 2.2 [RFC2616]>

 cookie-av         = expires-av / max-age-av / domain-av /
                     path-av / secure-av / httponly-av /
                     extension-av
 expires-av        = "Expires=" sane-cookie-date
 sane-cookie-date  = <rfc1123-date, определенный в параграфе 3.3.1 [RFC2616]>
 max-age-av        = "Max-Age=" non-zero-digit *DIGIT
                       ; На практике expires-av и max-age-av ограничены датами,
                       ; которые может представить пользовательский агент.
 non-zero-digit    = %x31-39
                       ; цифры от 1 до 9
 domain-av         = "Domain=" domain-value
 domain-value      = <subdomain>
                       ; определено в параграфе 3.5 [RFC1034] и
                       ; расширено в параграфе 2.1 [RFC1123]
 path-av           = "Path=" path-value
 path-value        = * <любой CHAR, кроме CTL и ";">
 secure-av         = "Secure"
 httponly-av       = "HttpOnly"
 extension-av      = * <любой CHAR, кроме CTL и ";">

Отметим, что в некоторых грамматических терминах в упомянутых выше документах применяются грамматические обозначения, отличающиеся от принятых в этом документе (ABNF из [RFC5234]).

Семантика cookie-value не определяется этим документом.

Для обеспечения максимальной совместимости с пользовательскими агентами серверам, которые хотят сохранять в cookie-value произвольные значения, следует кодировать эти данные (например, с использованием Base64 [RFC4648]).

Части set-cookie-string, создаваемые элементами cookie-av, называют атрибутами. Для обеспечения максимальной совместимости с пользовательскими агентами серверам не следует создавать два атрибута с одинаковыми именами в одной set-cookie-string (см. параграф 5.3, где описана обработка этого случая пользовательскими агентами).

Серверам не следует включать в один отклик более одного поля Set-Cookie с тем же значением cookie-name см. параграф 5.2, где описана обработка этого случая пользовательскими агентами (параграф 5.2).

Если сервер одновременно передает пользовательскому агенту множество откликов с заголовками Set-Cookie (например, при взаимодействии с пользовательским агентом через несколько сокетов), между откликами возникает «конкуренция» (race condition), которая может давать непредсказуемые результаты.

Примечание. Некоторые из имеющихся пользовательских агентов по разному интерпретируют обозначение года двумя цифрами. Для предотвращения проблем совместимости серверам следует использовать формат rfc1123-date, где год указывается 4 цифрами.

Примечание. Некоторые пользовательские агенты сохраняют и обрабатывают даты в cookie, как 32-битовые значения UNIX time_t. Ошибки реализации в некоторых библиотеках, поддерживающих обработку time_t могут приводить к некорректной обработке дат после 2038 года.

4.1.2. Семантика (не нормативно)

В этом параграфе описана упрощенная семантика заголовка Set-Cookie. Описание содержит достаточное число деталей для понимания общих вопросов использования cookie на серверах. Полное описание семантики приведено в разделе 5.

При получении пользовательским агентом заголовка Set-Cookie он сохраняет cookie вместе с атрибутами. Позднее, когда пользовательский агент делает запрос HTTP, он включает применимые cookie, для которых не истек срок действия, в заголовок Cookie.

Если пользовательский агент получает новое «значение» cookie с такими же полями cookie-name, domain-value и path-value, какие уже сохранены, существующая запись cookie заменяется новой. Отметим, что серверы могут удалять cookie, передавая клиенту новое значение cookie с атрибутом Expires, указывающим уже прошедшее время.

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

4.1.2.1. Атрибут Expires

Атрибут Expires указывает срок действия cookie датой и временем его завершения. Пользовательский агент не обязан сохранять cookie до наступления указанного времени. На практике пользовательские агенты зачастую удаляют cookie для освобождения памяти или по соображениям защиты приватности.

4.1.2.2. Атрибут Max-Age

Атрибут Max-Age указывает срок действия cookie, представленный число оставшихся секунд. Пользовательский агент не обязан сохранять cookie до истечения указанного времени. На практике пользовательские агенты зачастую удаляют cookie для освобождения памяти или по соображениям защиты приватности.

Примечание. Некоторые из имеющихся пользовательских агентов не поддерживают атрибут Max-Age и просто игнорируют его.

Если в cookie присутствуют оба атрибута Max-Age и Expires, атрибут Max-Age является предпочтительным и будет определять срок действия cookie. Если в cookie не указано ни одного из атрибутов Max-Age и Expires, пользовательский агент будет сохранять cookie «до завершения текущей сессии» (с его точки зрения).

4.1.2.3. Атрибут Domain

Атрибут Domain указывает хосты, для которых было передано значение cookie. Например, если указан атрибут Domain со значением example.com, пользовательский агент будет включать cookie в заголовки Cookie при отправке запросов HTTP на серверы example.com, www.example.com и www.corp.example.com (отметим, что при наличии в начале значения символа точки — %x2E — он будет игнорироваться, поскольку не является разрешенным, но точка в конце будет приводить к игнорированию атрибута целиком). Если сервер не указал атрибута Domain, пользовательский агент будет возвращать cookie только серверу-источнику.

Предупреждение. Некоторые реализации пользовательских агентов трактуют отсутствие атрибута Domain, как атрибут Domain с текущим именем хоста. Например, если example.com возвращает заголовок Set-Cookie без атрибута Domain, такие агенты будут ошибочно отправлять cookie также серверу www.example.com.

Пользовательский агент будет отвергать cookie, в которых атрибут Domain задает область действия, не включающую сервер-источник. Например, пользовательский агент будет воспринимать cookie с атрибутом Domain, имеющим значение example.com или foo.example.com, от сервера foo.example.com, но не будет воспринимать от него cookie с атрибутом Domain, имеющим значение bar.example.com или baz.foo.example.com.

Примечание. Из соображений безопасности многие пользовательские агенты настроены отвергать атрибуты Domain, соответствующие «публичным суффиксам». Например, некоторые пользовательские агенты будут отвергать атрибуты Domain со значением com или co.uk (см. параграф 5.3).

4.1.2.4. Атрибут Path

Область действия cookie ограничена путями, контролируемыми с помощью атрибута Path. Если сервер не указывает атрибут Path, пользовательский агент будет использовать по умолчанию компонент пути из request-uri (см. параграф 5.1.4).

Пользовательский агент будет включать cookie в запрос HTTP только в тех случаях, когда относящаяся к пути часть request-uri совпадает (или является подкаталогом) со значением атрибута Path в cookie, где символ %x2F (/) интерпретируется, как разделитель в иерархии каталогов.

Несмотря на кажущуюся привлекательность разделения cookie по путям в рамках данного хоста, атрибут Path не может служить основой для защиты (см. раздел 8).

4.1.2.5. Атрибут Secure

Атрибут Secure ограничивает область действия cookie «защищенными» каналами («защищенность определяется пользовательским агентом). При наличии в cookie атрибута Secure пользовательский агент будет включать cookie в запросы HTTP только при их передаче через защищенные каналы (обычно HTTP на основе TLS⁴ [RFC2818]).

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

4.1.2.6. Атрибут HttpOnly

Атрибут Secure ограничивает область действия cookie запросами HTTP. В частности, этот атрибут предлагает пользовательскому агенту опускать cookie в случае предоставления доступа к cookie через не относящиеся в HTTP интерфейсы API⁵ (например, API браузера, раскрывающий cookies для сценариев).

Отметим, что атрибут HttpOnly не связан с атрибутом Secure и в cookie могут включаться оба эти атрибута.

4.2. Заголовок Cookie

4.2.1. Синтаксис

Пользовательские агент передает сохраненные значение cookie серверу-источнику в заголовке Cookie. Если сервер соответствует требованиям параграфа 4.1 (а пользовательский агент соответствует требованиям раздела 5), агент будет передавать заголовок Cookie, соответствующий приведенной ниже форме.

   cookie-header = "Cookie:" OWS cookie-string OWS
   cookie-string = cookie-pair *( ";" SP cookie-pair )

4.2.2. Семантика

Каждая пара cookie-pair представляет экземпляр cookie, сохраненный пользовательским агентом. Пара cookie-pair включает поля cookie-name и cookie-value, которые агент получил в заголовке Set-Cookie.

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

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

Хотя cookie указываются в заголовке Cookie последовательно, серверам не следует полагаться на порядок их размещения. В частности, если заголовок Cookie содержит пару одноименных cookie (например, полученных с разными атрибутами Path или Domain), серверу не следует принимать решения, основанные на порядке размещения cookie в заголовке.

5. Требования к пользовательским агентам

В этом разделе заголовки Cookie и Set-Cookie рассмотрены более подробно, чтобы пользовательские агенты, в точности реализующие эти требования, были совместимы с имеющимися серверами (включая те, которые не соответствуют профилю, описанному в разделе 4).

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

5.1. Алгоритмы обработки субкомпонент

В этом разделе определены некоторые алгоритмы, применяемые пользовательскими агентами для обработки конкретных субкомпонент заголовков Cookie и Set-Cookie.

5.1.1. Даты

Для разбора cookie-date пользовательский агент должен использовать алгоритм, эквивалентный описанному ниже. Отметим, что различные логические флаги, определенные как часть алгоритма (т. е., found-time, found-day-of-month, found-month, found-year) изначально сброшены (0).

На основе приведенных ниже правил cookie-date разбивается на date-token.

cookie-date     = *delimiter date-token-list *delimiter
date-token-list = date-token *( 1*delimiter date-token )
date-token      = 1*non-delimiter

delimiter       = %x09 / %x20-2F / %x3B-40 / %x5B-60 / %x7B-7E
non-delimiter   = %x00-08 / %x0A-1F / DIGIT / ":" / ALPHA / %x7F-FF
non-digit       = %x00-2F / %x3A-FF

day-of-month    = 1*2DIGIT [ non-digit *OCTET ]
month           = ( "jan" / "feb" / "mar" / "apr" /
                    "may" / "jun" / "jul" / "aug" /
                    "sep" / "oct" / "nov" / "dec" ) *OCTET
year            = 2*4DIGIT [ non-digit *OCTET ]
time            = hms-time [ non-digit *OCTET ]
hms-time        = time-field ":" time-field ":" time-field
time-field      = 1*2DIGIT

Маркеры date-token последовательно обрабатываются в порядке их указания в cookie-date.
1. Если флаг found-time не установлен и маркер соответствует времени создания, устанавливается флаг found-time, а также значения hour-value, minute-value и second-value в соответствии с числами в date-token. Остальные этапы пропускаются и обрабатывается следующий маркер date-token.
2. Если флаг found-day-of-month не установлен и маркер соответствует дате (число месяца) создания, устанавливается флаг found-day-of-month, а также значение day-of-month-value в соответствии с числом в date-token. Остальные этапы пропускаются и обрабатывается следующий маркер date-token.
3. Если флаг found-month не установлен и маркер соответствует месяцу создания, устанавливается флаг found-month, а также значение month-value в соответствии с числом в date-token. Остальные этапы пропускаются и обрабатывается следующий маркер date-token.
4. Если флаг found-year не установлен и маркер соответствует году создания, устанавливается флаг found-year, а также значение year-value в соответствии с числом в date-token. Остальные этапы пропускаются и обрабатывается следующий маркер date-token.
Если значение year-value находится в интервале от 70 до 99 (включительно), к year-value добавляется 1900.
Если значение year-value находится в интервале от 0 до 69 (включительно), к year-value добавляется 2000.
1. Примечание. Некоторые пользовательские агенты иначе интерпретируют представление года двумя цифрами.
Обработка cookie-date прерывается отказом, если выполняется любое из указанных ниже условий:

- не установлен хотя бы один из флагов found-day-of-month, found-month, found-year, found-time;
- значение day-of-month-value меньше 1 или больше 31;
- значение year-value меньше 1601;
- значение hour-value больше 23;
- значение minute-value больше 59;
- значение second-value больше 59
  
  (отметим, что в этом синтаксисе не могут быть представлены високосные секунды).

Пусть parsed-cookie-date будет дата, в которой поля day-of-month, month, year, hour, minute и second (в UTC) будут иметь значения day-of-month-value, month-value, year-value, hour-value, minute-value second-value, соответственно. Если такой даты не существует, разбор cookie-date прерывается отказом.
Возврат значения parsed-cookie-date в качестве результат работы алгоритма.

5.1.2. Канонические имена хостов

Канонические имена хостов создаются с помощью приведенного ниже алгоритма.

Имя хоста преобразуется в последовательность отдельных меток доменного имени.
Каждая метке, которая не является NR-LDH⁶, преобразуется в A-метку (см. параграф 2.3.2.1 в [RFC5890]) или метку punycode (преобразование ToASCII в соответствии с разделом 4 в [RFC3490]), в зависимости от ситуации (см. параграф 6.3).
Полученные метки собираются в одну строку с разделением точками (%x2E).

5.1.3. Соответствие домена

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

Домен идентичен строке (отметим, что здесь предполагается приведение обеих строк к нижнему регистру).
Выполняются все приведенные ниже условия:
- домен является суффиксом строки;
- последним символом строки, не входящим в имя домена, является точка (%x2E);
- строка является именем хоста (не IP-адресом).

5.1.4. Пути и path-Match

Для расчета default-path в cookie пользовательский агент должен применять алгоритм, эквивалентный приведенному ниже.

Пусть uri-path будет частью request-uri, если такая часть существует и пустым в остальных случаях. Например, если request-uri содержит путь (и необязательную строку запроса), uri-path будет этим путем (без %x3F (?) и строки запроса), а если request-uri содержит полный идентификатор absoluteURI, uri-path будет компонентой пути этого URI.
Если значение uri-path пусто или первый символ отличается от / (%x2F), возвращается %x2F (/) и остальные этапы пропускаются.
Если uri-path содержит не более одного символа / (%x2F), возвращается %x2F (/) и остальные этапы пропускаются.
Возвращаются символы uri-path, начиная с первого и заканчивая (но не включая) последним символом %x2F (/).

Строка request-path соответствует пути в данном cookie-path, если выполняется хотя бы одно из приведенных ниже условий.

Строки cookie-path и request-path идентичны. Отметим, что это отличается от правил RFC 3986 для эквивалентности компоненты path и, следовательно, два эквивалентных пути могут иметь разные cookie.
Строка cookie-path является префиксом request-path и последним символом cookie-path является , (%x2F).
Строка cookie-path является префиксом request-path и первым символом request-path, не включенным в cookie-path, является / (%x2F).

5.2. Заголовок Set-Cookie

Получив поле заголовка Set-Cookie в отклике HTTP, пользовательский агент может игнорировать поле Set-Cookie целиком. Например, пользовательский агент может выбрать блокирование установки cookie на основании откликов на запросы «третьих сторон» (см. параграф 7.1).

Если пользовательский агент не игнорирует Set-Cookie целиком, он должен разобрать содержимое заголовка Set-Cookie, как set-cookie-string (см. определение ниже).

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

Для разбора set-cookie-string пользовательский агент должен применять алгоритм, эквивалентный приведенному ниже.

Если set-cookie-string содержит символ %x3B (;),

строка name-value-pair будет включать символы вплоть (но не включая) до первого символа %x3B (;), а строка unparsed-attributes будет содержать оставшуюся часть set-cookie-string (включая упомянутый символ %x3B ).

В противном случае

строка name-value-pair будет включать все символы set-cookie-string, а unparsed-attributes будет пустой.
Если строка name-value-pair не содержит знака равенства (%x3D), set-cookie-string игнорируется целиком.
Строка name (возможно пустая) будет содержать символы вплоть (но не включая) до первого знака равенства (%x3D), а строка (возможно пустая) будет содержать символы после первого знака равенства (%x3D).
Удаляются все символы WSP (пробелы) в начале и в конце строк name и value.
Если строка name пуста, set-cookie-string игнорируется целиком.
Строка cookie-name будет строкой name, а cookie-value — value.

Для разбора unparsed-attributes пользовательский агент должен использовать алгоритм, эквивалентный приведенному ниже.

Если строка unparsed-attributes пуста, остальные шаги пропускаются.
Отбрасывается первый символ unparsed-attributes (%x3B — ;).
Если оставшаяся часть unparsed-attributes содержит символ %x3B (;),

извлекаются символы unparsed-attributes вплоть (но не включая) до первого символа %x3B (;).

В противном случае

извлекается оставшаяся часть unparsed-attributes.

Извлеченные на этом этапе символы составляют значение cookie-av.
Если cookie-av включает символ %x3D (=),

Строка (возможно пустая) attribute-name будет содержать символы вплоть (но не включая) до первого знака равенства (%x3D), а строка (возможно пустая) attribute-value будет содержать символы после знака равенства (%x3D).

В противном случае

Строка attribute-name будет содержать cookie-av целиком, а attribute-value будет пустой.
Удаляются все символы WSP (пробелы) в начале и в конце строк attribute-name и attribute-value.
Строки attribute-name и attribute-value обрабатываются в соответствии с требованиями последующих параграфов (отметим, что атрибуты с нераспознанными именами attribute-names игнорируются).
Возврат на этап 1 данного алгоритма.

По завершении разбора set-cookie-string пользовательский агент «получает cookie» из request-uri с именем cookie-name, значением cookie-value и атрибутами cookie-attribute-list (дополнительные требования, связанные с получением cookie, рассмотрены в параграфе 5.3).

5.2.1. Атрибут Expires

Если attribute-name без учета регистра символов совпадает со строкой Expires, пользовательский агент должен обработать cookie-av, как показано ниже.

Пусть expiry-time будет результатом разбора attribute-value, как cookie-date (см. параграф 5.1.1).

Если attribute-value не удается разобрать, как дату cookie, значение cookie-av игнорируется.

Если expiry-time указывает дату позже последней даты, которую может представить пользовательский агент, он может заменить expiry-time последней представимой датой.

Если expiry-time указывает дату раньше самой ранней даты, которую может представить пользовательский агент, он может заменить expiry-time самой ранней представимой датой.

В конец списка cookie-attribute-list добавляется attribute-name со значением Expires и attribute-value со значением expiry-time.

5.2.2. Атрибут Max-Age

Если attribute-name без учета регистра символов совпадает со строкой Max-Age, пользовательский агент должен обработать cookie-av, как показано ниже.

Если первый символ attribute-value не является цифрой (DIGIT) или символом «-», значение cookie-av игнорируется.

Если оставшаяся часть attribute-value содержит нецифровые символы (не DIGIT), значение cookie-av игнорируется.

Пусть delta-seconds будет значением attribute-value, преобразованным в целое число.

Если delta-seconds не больше 0, значение expiry-time будет самой ранней представимой датой. В противном случае expiry-time будет текущей датой с добавлением delta-seconds секунд.

В конец списка cookie-attribute-list добавляется attribute-name со значением Max-Age и attribute-value со значением expiry-time.

5.2.3. Атрибут Domain

Если attribute-name без учета регистра символов совпадает со строкой Domain, пользовательский агент должен обработать cookie-av, как показано ниже.

Если строка attribute-value является пустой, поведение не определено, однако пользовательскому агенту следует игнорировать cookie-av целиком.

Если первым символом attribute-value является точка (%x2E),

тогда cookie-domain будет attribute-value без начальной точки (%x2E).

В противном случае

cookie-domain будет полным значением attribute-value.

Строка cookie-domain приводится к нижнему регистру.

В конец списка cookie-attribute-list добавляется attribute-name со значением Domain и attribute-value со значением cookie-domain.

5.2.4. Атрибут Path

Если attribute-name без учета регистра символов совпадает со строкой Path, пользовательский агент должен обработать cookie-av, как показано ниже.

Если строка attribute-value является пустой или первый символ отличается от %x2F (/),

тогда cookie-path будет принимать значение default-path.

В противном случае

cookie-path будет принимать значение attribute-value.

В конец списка cookie-attribute-list добавляется attribute-name со значением Path и attribute-value со значением cookie-path.

5.2.5. Атрибут Secure

Если attribute-name без учета регистра символов совпадает со строкой Secure, пользовательский агент должен добавить в конец списка cookie-attribute-list attribute-name со значением Secure и пустым attribute-value.

5.2.6. Атрибут HttpOnly

Если attribute-name без учета регистра символов совпадает со строкой HttpOnly, пользовательский агент должен добавить в конец списка cookie-attribute-list attribute-name со значением HttpOnly и пустым attribute-value.

5.3. Модель хранения

Пользовательский агент сохраняет для каждого cookie поля name, value, expiry-time, domain, path, creation-time, last-access-time, persistent-flag, host-only-flag, secure-only-flag и http-only-flag.

Когда пользовательский агент из request-uri «получает cookie» с именем cookie-name, значением cookie-value и атрибутами cookie-attribute-list, этот агент должен обработать cookie в соответствии с приведенным ниже алгоритмом.

Пользовательский агент может игнорировать полученный cookie целиком. Например, он может блокировать получение cookie из «чужих откликов» или отказаться от сохранения cookie по причине экономии места в хранилище.
Создается новая запись cookie с именем cookie-name и значением cookie-value. Для creation-time и last-access-time указывается текущее время и дата.
Если cookie-attribute-list содержит атрибут с именем (attribute-name) Max-Age,

устанавливается флаг persistent-flag = true;

в качестве expiry-time для cookie устанавливается attribute-value последнего атрибута cookie-attribute-list с именем (attribute-name) Max-Age.

В противном случае, если cookie-attribute-list содержит атрибут с именем (attribute-name) Expires (и не содержит атрибута с именем Max-Age),

устанавливается флаг persistent-flag = true;

в качестве expiry-time для cookie устанавливается attribute-value последнего атрибута cookie-attribute-list с именем (attribute-name) Expires.

В остальных случаях

устанавливается флаг persistent-flag = false;

в качестве expiry-time для cookie устанавливается последняя представимая дата.
Если cookie-attribute-list содержит атрибут с именем (attribute-name) Domain,

domain-attribute будет attribute-value последнего атрибута в списке cookie-attribute-list с именем (attribute-name) Domain.

В противном случае

domain-attribute будет пустой строкой.
Если пользовательский агент настроен отвергать «публичные суффиксы» (public suffix), а domain-attribute является таким суффиксом,

если domain-attribute идентичен канонизированному значению request-host,

domain-attribute будет пустой строкой.

В противном случае

cookie игнорируется целиком и обработка прерывается.

Примечание. «Публичным суффиксом» считается домен, контролируемый публичным регистратором (например, com, co.uk или pvt.k12.wy.us). Выполнение этого этапа имеет важное значение для предотвращения нарушения целостности домена example.com со стороны злоумышленника attacker.com путем организации cookie с атрибутом Domain = com. К сожалению множество публичных суффиксов (их называют также «доменами, контролируемыми регистратором») изменяется с течением времени. По возможности пользовательским агентам следует применять актуальный список публичных суффиксов типа поддерживаемого проектом Mozilla на странице <http://publicsuffix.org/>.
Если значение domain-attribute не пусто,

если канонизированное значение request-host не соответствует domain-attribute:

cookie игнорируется целиком и обработка прерывается.

В противном случае

устанавливается флаг host-only-flag = false;

для domain-attribute в качестве домена для cookie.

Иначе

устанавливается флаг host-only-flag = true;

в качестве домена для cookie устанавливается канонизированное значение request-host.
Если cookie-attribute-list содержит атрибут с именем (attribute-name) Path, в качестве пути для cookie устанавливается attribute-value последнего атрибута в cookie-attribute-list с именем (attribute-name) Path. В противном случае в качестве пути для cookie устанавливается default-path из the request-uri.
Если cookie-attribute-list содержит атрибут с именем (attribute-name) Secure, устанавливается флаг secure-only-flag = true. В противном случае устанавливается secure-only-flag = false.
Если cookie-attribute-list содержит атрибут с именем (attribute-name) HttpOnly, устанавливается флаг http-only-flag = true. В противном случае устанавливается secure-only-flag = false.
Если cookie был получен от API, не являющегося HTTP, и установлен флаг http-only-flag, обработка прерывается и cookie игнорируется целиком.
Если хранилище cookie содержит cookie с таким же именем, доменом и путем, как у вновь созданного cookie:
1. Пусть old-cookie будет существующий cookie с тем же именем, доменом и путем (отметим, что этот алгоритм предполагает не более одного такого cookie).
2. Если новый cookie был получен от API, не являющегося HTTP, и для old-cookie установлен флаг http-only-flag, обработка прерывается и вновь созданный cookie игнорируется целиком.
3. Значение creation-time для нового cookie устанавливается равным creation-time из old-cookie.
4. old-cookie удаляется из хранилища.
Вновь созданный cookie помещается в хранилище.

Cookie считается недействительным (expired) если срок завершения уже наступил.

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

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

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

При удалении избыточных cookie из хранилища пользовательский агент должен руководствоваться приведенным ниже порядком удаления:

устаревшие cookie;
cookie с одинаковым доменом в количестве, превышающем заданное значение;
прочие cookie.

При наличии двух cookie с одинаковым приоритетом удаления пользовательский агент должен удалять cookie с более ранним временем последнего обращения (last-access date).

Когда задан срок действия до конца текущей сессии (the current session is over), пользовательский агент должен удалить из хранилища все cookie, для которых не установлен флаг persistent-flag (false).

5.4. Заголовок Cookie

Пользовательский агент включает сохраненные cookie в заголовки Cookie своих запросов HTTP.

При генерации запроса HTTP пользовательскому агенту недопустимо включать в запрос более одного поля Cookie.

Пользовательский агент может не включать в запрос заголовок Cookie. Например, пользовательский агент может блокировать отправку cookie при запросе «третьей стороны» на установку cookie (см. параграф 7.1).

Если пользовательский агент включает заголовок Cookie в свой запрос HTTP, он должен передать в качестве такого заголовка описанную ниже строку cookie-string.

Для создания cookie-string из сохраненного cookie и request-uri пользовательский агент должен применять алгоритм, эквивалентный приведенному ниже.

Пусть cookie-list обозначает набор cookie из хранилища, удовлетворяющих приведенным ниже требованиям.

- Или
  
  флаг host-only-flag для cookie имеет значение true и канонизированное значение request-host идентично домену cookie.
  
  Или
  
  флаг host-only-flag для cookie имеет значение false и канонизированное значение request-host соответствует домену cookie.
- Путь в request-uri соответствует пути в cookie.
- Если флаг secure-only-flag для cookie имеет значение true, схема request-uri должна указывать «защищенный» протокол (с точки зрения пользовательского агента).
  
  Примечание. Понятие «безопасного» протокола не определяется в данном документе. Обычно пользовательский агент считает протокол безопасным, если тот обеспечивает защиту на транспортном уровне (типа SSL или TLS). Например, большинство пользовательских агентов считают схему https обозначением безопасного протокола.
- Если флаг http-only-flag для cookie имеет значение true, исключаются cookie, где cookie-string создана с использованием отличного от HTTP API (по усмотрению пользовательского агента).

Пользовательскому агенту следует отсортировать cookie-list в описанном ниже порядке.

- Cookie с более длинными путями размещаются впереди cookie с короткими путями.
- Среди cookies с одинаковым размером пути первыми размещаются cookie с более ранним creation-time.
  
  Примечание. Не все пользовательские агенты сортируют cookie-list в указанном порядке, но этот порядок отражает общепринятую практику во время подготовки этого документа. Исторически сложилось так, что некоторые серверы (ошибочно) зависят от соблюдения этого порядка.

Значение last-access-time каждого cookie из списка cookie-list заменяется текущим временем и датой.
Список cookie-list преобразуется в строку cookie-string путем обработки каждого cookie в соответствии с порядком их размещения в cookie-list:
1. Выводится имя cookie, знак равенства (%x3D) и значение cookie.
2. Если в списке cookie-list остаются необработанные cookie , выводятся символы %x3B и %x20 (; ).

Примечание. Несмотря на свое имя, cookie-string в реальности представляет собой последовательность октетов, а не символов. Для преобразования cookie-string (или отдельных компонент) в последовательность символов (например, для представления пользователю) пользовательский агент может предпринять попытку использования кодировки UTF-8 [RFC3629]. При этом могут возникать отказы, поскольку не всякая последовательность октетов является корректной строкой UTF-8.

6. Вопросы реализации

6.1. Ограничения

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

не менее 4096 байтов на cookie (суммарный размер имени, значения и атрибутов cookie);
не менее 50 cookie на домен;
всего не менее 3000 cookie.

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

Серверам следует аккуратно снижать возможности (деградировать), если пользовательский агент не возвратил один или несколько cookie в заголовке Cookie, поскольку пользовательский агент имеет право по своему усмотрению или запросу пользователя удалять cookie в любой момент.

6.2. Интерфейс прикладных программ

Одна из причин использования в заголовках Cookie и Set-Cookie столь эзотерического синтаксиса заключается в том, что на многих платформах (как серверных, так и пользовательских) для cookie предоставляется основанный на строковых переменных интерфейс (API), требующий от разработчиков прикладных программ генерации и анализа синтаксиса, использованного в заголовках Cookie и Set-Cookie, который многие программисты реализуют некорректно, что приводит к проблемам совместимости.

Вместо предоставления для cookie интерфейса API на базе строковых переменных от платформ хотелось бы получить более осмысленный API. Рекомендации по конкретным API выходят за рамки этого документа, однако восприятие абстрактных объектов Date обеспечит явные преимущества по сравнению со строковым представлением дат.

6.3. Связь с IDNA

IDNA2008 [RFC5890] заменяет собой IDNA2003 [RFC3490]. Тем не менее, между этими спецификациями имеются различия и это может приводить к разной обработке (т. е., преобразованию) меток доменных имен, соответствующих разным спецификациям. В течение некоторого времени метки доменных имен на базе IDNA2003 будут сохраняться в сети. Пользовательским агентам следует поддерживать IDNA2008 [RFC5890] и можно поддерживать [UTS46] или [RFC5895] для упрощения перехода IDNA. Если в пользовательском агенте не реализуется IDNA2008, он должен поддерживать IDNA2003 [RFC3490].

7. Вопросы приватности

Cookie часто критикуют за возможность серверов отслеживать пользователей. Например, множество компаний web-анализа используют cookie для обнаружения возврата пользователя на сайт или его перехода на другой сайт. Хотя cookie является не единственным механизмом, позволяющим серверам отслеживать пользователей по запросам HTTP, cookie упрощают такое отслеживание поскольку они сохраняются в пользовательском агенте и могут совместно использоваться несколькими хостами.

7.1. Сторонние cookie

Особенно тревожат «сторонние cookie» (third-party). При воспроизведении документа HTML пользовательский агент часто запрашивает ресурсы с других серверов (типа рекламных сетей). Эти сторонние серверы могут использовать cookie для отслеживания даже тех пользователей, которые никогда не заходили на сервер напрямую. Например, если пользователь посетит сайт, содержащий информацию от третьей стороны, а позднее посетит сайт, также содержащий информацию от этой третьей стороны, та сможет отследить посещение этим пользователем двух сайтов.

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

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

7.2. Пользовательские элементы управления

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

Пользовательским агентам следует предоставлять пользователю механизм запрета cookie. При отключенных cookie пользовательскому агенту недопустимо включать заголовок Cookie в исходящие запросы HTTP, а также недопустима обработка заголовков Set-Cookie во входящих откликах HTTP.

Некоторые пользовательские агенты предоставляют возможность запрета сохранения cookie по завершении сессии. В таком режиме пользовательский агент должен трактовать все полученные cookie, как имеющие флаг persistent-flag со значением false. Некоторые популярные пользовательские агенты указывают такую функциональность, как режим private browsing [Aggarwal2010].

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

7.3. Сроки действия

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

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

8.1. Обзор

С cookie связано множество проблем безопасности. В этом разделе рассматриваются некоторые наиболее важные проблемы.

В частности, cookie подталкивают разработчиков полагаться на сомнительные основания при проверке подлинности, зачастую создающие уязвимости для атак типа поддержки кросс-сайтовых запросов [CSRF]. Аналогично, при сохранении сеансовых идентификаторов в cookie разработчики зачастую создают уязвимость, связанную с фиксацией сессии.

Шифрования на транспортном уровне, реализованного в HTTPS, не достаточно для предотвращения сетевых атак, связанных с перехватом и изменением cookie жертвы атаки, поскольку сам протокол cookie имеет множество уязвимостей (см. параграфы 8.5. Недостаточная конфиденциальность и 8.6. Недостаточная защита целостности). Кроме того, по умолчанию cookie не обеспечивают защиты конфиденциальности и целостности от сетевых атак даже при использовании с HTTPS.

8.2. Сомнительные основания

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

Эту проблему называют по-разному (например, кросс-сайтовый обман (cross-site request forgery) или обманное делегирование (confused deputy)), она связана с использованием cookie в качестве основания для отождествления. Cookie побуждают операторов серверов отделять обозначение (в форме URL) от проверки полномочий (в форме cookie). Следовательно, пользовательский агент может предоставить полномочия для указанного атакующим ресурса и это может приводить к тому, что сервере или его клиенты предпримут заданные атакующим действия как будто они были уполномочены реальным пользователем.

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

8.3. Открытый текст

Пока не используется защищенный канал (типа TLS), информация заголовков Cookie и Set-Cookie передается в открытом виде.

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

Серверам следует шифровать и подписывать содержимое cookie (используя любой желаемый для сервера формат) при их передаче пользовательскому агенту (даже при передаче cookie по защищенному каналу). Однако шифрование и подписывание содержимого cookie не препятствует атакующему при «пересадке» cookie из одного пользовательского агента в другой или повторном использовании (replay) cookie.

В дополнение к шифрованию и подписыванию содержимого cookie серверам, которым требуется высокий уровень защиты, следует использовать заголовки Cookie и Set-Cookie только через защищенные каналы. В этом случае серверу следует устанавливать атрибут Secure (см. параграф 4.1.2.5) для каждого cookie. Если сервер не будет устанавливать атрибут Secure, защита, обеспечиваемая безопасным каналом, становится весьма спорной.

В качестве примера рассмотрим почтовый сервер (webmail), который хранит идентификатор сессии в cookie и обычно предоставляет доступ по протоколу HTTPS. Если сервер не устанавливает атрибут Secure в своих cookie, активный атакующий в сети может перехватить любой исходящий запрос HTTP от пользовательского агента и перенаправить этот запрос серверу webmail по HTTP. Даже если сервер webmail не принимает соединений HTTP, пользовательский агент все равно будет включать cookie в запрос. Активный атакующий в сети может перехватывать эти cookie и использовать их (replay) для контакта с сервером, получая доступ к электронной почте пользователя. Если же сервер установит атрибут Secure для своих cookie, пользовательский агент не будет включать cookie в открытые (незашифрованные) запросы.

8.4. Идентификаторы сессий

Вместо сохранения сеансовых данных в cookie (откуда они могут быть получены и использованы злоумышленником), серверы обычно сохраняют в cookie одноразовый идентификатор (nonce или session identifier). При получении сервером запроса HTTP с nonce, сервер может получить данные о состоянии, связанные с cookie, используя nonce в качестве ключа поиска.

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

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

8.5. Недостаточная конфиденциальность

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

Cookie не изолированы по схеме. Хотя обычно они применяются со схемами http и https, cookie для данного хоста могут быть доступны и для других схем типа ftp или gopher. Несмотря на то, что этот недостаток изоляции связан в основном с интерфейсами API, не относящимися к HTTP и разрешающим доступ к cookie (например, интерфейс document.cookie API в HTML), отсутствие изоляции по схеме фактически присутствует в требованиях к обработке самих cookie (например, получение URI со схемой gopher через HTTP).

Cookies не всегда изолированы по пути. Хотя протокол сетевого уровня не передает cookie, сохраненные для одного пути в другой путь, некоторые пользовательские агенты раскрывают cookie через API, не относящиеся к HTTP, типа document.cookie API в HTML. Поскольку некоторые из таких пользовательских агентов (например, web-браузеры) не изолируют ресурсы, полученные из других путей, ресурсы полученные из одного пути, могут иметь доступ к cookie, сохраненным для другого пути.

8.6. Недостаточная защита целостности

Cookie не обеспечивают гарантий целостности для родственных (sibling) доменов и их субдоменов. Например, рассмотрим домены foo.example.com и bar.example.com. Сервер foo.example.com может установить cookie с атрибутом Domain = example.com (возможно, переписав существующий cookie example.com от bar.example.com) и пользовательский агент будет включать этот файл cookie в запросы HTTP к серверу bar.example.com. В худшем случае bar.example.com не сможет отличить этот cookie от своего. Сервер foo.example.com может усугубить эту ситуацию, организовав атаку на bar.example.com.

Даже при наличии в заголовке Set-Cookie атрибута Path этот атрибут не обеспечивает какой-либо защиты целостности, поскольку пользовательский агент будет принимать произвольный атрибут Path в заголовке Set-Cookie. Например, отклик HTTP на запрос http://example.com/foo/bar может установить cookie с атрибутом Path = /qux. По этой причине серверам не следует запускать не доверяющие друг другу службы на разных путях одного хоста и применять cookie для хранения связанной с безопасностью информации.

При активной сетевой атаке возможна также вставка cookie в заголовок Cookie, переданный по адресу https://example.com/, путем подмены отклика от http://example.com/ и вставки заголовка Set-Cookie. Сервер HTTPS на example.com не сможет отличить эти cookie от установленных им самим в отклике HTTPS. Атакующий сможет использовать это для организации атаки на example.com даже если этот сервер использует только HTTPS.

Серверы могут частично смягчить такие атаки, используя шифрование и подпись для содержимого своих cookie. Однако применение криптографии не решает проблему полностью, поскольку атакующий может воспроизвести (replay) cookie, полученные от настоящего сервера example.com server в сессии пользователя, с непредсказуемым результатом.

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

8.7. Зависимость от DNS

Cookie работают на основе DNS⁷ в части обеспечения безопасности. При частичной или полной компрометации DNS протокол cookie может оказаться не способным обеспечить требуемую приложениями защиту.

9. Согласование с IANA

Реестр полей заголовков сообщений (см. [RFC3864]) обновляется приведенными ниже значениями.

9.1. Cookie

Название поля заголовка: Cookie

Применимый протокол: http

Статус: стандарт

Автор/контроль изменений: IETF

Спецификация: данный документ (параграф 5.4)

9.2. Set-Cookie

Название поля заголовка: Set-Cookie

Применимый протокол: http

Статус: стандарт

Автор/контроль изменений: IETF

Спецификация: данный документ (параграф 5.2)

9.3. Cookie2

Название поля заголовка: Cookie2

Применимый протокол: http

Статус: отменено

Автор/контроль изменений: IETF

Спецификация: [RFC2965]

9.4. Set-Cookie2

Название поля заголовка: Set-Cookie2

Применимый протокол: http

Статус: отменено

Автор/контроль изменений: IETF

Спецификация: [RFC2965]

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

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

[RFC1034] Mockapetris, P., «Domain names — concepts and facilities», STD 13, RFC 1034, November 1987.

[RFC1123] Braden, R., «Requirements for Internet Hosts — Application and Support», STD 3, RFC 1123, October 1989.

[RFC2119] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, March 1997.

[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, «Hypertext Transfer Protocol — HTTP/1.1», RFC 2616, June 1999.

[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, «Internationalizing Domain Names in Applications (IDNA)», RFC 3490, March 2003.

В параграфе 6.3 указано, почему в числе нормативных документов указаны отмененные спецификации.

[RFC4790] Newman, C., Duerst, M., and A. Gulbrandsen, «Internet Application Protocol Collation Registry», RFC 4790, March 2007.

[RFC5234] Crocker, D., Ed. and P. Overell, «Augmented BNF for Syntax Specifications: ABNF», STD 68, RFC 5234, January 2008.

[RFC5890] Klensin, J., «Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework», RFC 5890, August 2010.

[USASCII] American National Standards Institute, «Coded Character Set — 7-bit American Standard Code for Information Interchange», ANSI X3.4, 1986.

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

[RFC2109] Kristol, D. and L. Montulli, «HTTP State Management Mechanism», RFC 2109, February 1997.

[RFC2965] Kristol, D. and L. Montulli, «HTTP State Management Mechanism», RFC 2965, October 2000.

[RFC2818] Rescorla, E., «HTTP Over TLS», RFC 2818, May 2000.

[Netscape] Netscape Communications Corp., «Persistent Client State – HTTP Cookies», 1999, <http://web.archive.org/web/20020803110822/http://wp.netscape.com/newsref/std/cookie_spec.html>.

[Kri2001] Kristol, D., «HTTP Cookies: Standards, Privacy, and Politics», ACM Transactions on Internet Technology Vol. 1, #2, November 2001, <http://arxiv.org/abs/cs.SE/0105018>.

[RFC3629] Yergeau, F., «UTF-8, a transformation format of ISO 10646», STD 63, RFC 3629, November 2003.

[RFC4648] Josefsson, S., «The Base16, Base32, and Base64 Data Encodings», RFC 4648, October 2006.

[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, «Registration Procedures for Message Header Fields», BCP 90, RFC 3864, September 2004.

[RFC5895] Resnick, P. and P. Hoffman, «Mapping Characters for Internationalized Domain Names in Applications (IDNA) 2008», RFC 5895, September 2010.

[UTS46] Davis, M. and M. Suignard, «Unicode IDNA Compatibility Processing», Unicode Technical Standards # 46, 2010, <http://unicode.org/reports/tr46/>.

[CSRF] Barth, A., Jackson, C., and J. Mitchell, «Robust Defenses for Cross-Site Request Forgery», 2008, <http://portal.acm.org/citation.cfm?id=1455770.1455782>.

[Aggarwal2010] Aggarwal, G., Burzstein, E., Jackson, C., and D. Boneh, «An Analysis of Private Browsing Modes in Modern Browsers», 2010, <http://www.usenix.org/events/sec10/tech/full_papers/Aggarwal.pdf>.

Приложение A. Благодарности

Этот документ включает много заимствований из RFC 2109 [RFC2109]. Мы обязаны David M. Kristol и Lou Montulli за их усилия по спецификации cookie. David M. Kristol, в частности, предоставил неоценимые рекомендации про прохождению процесса IETF. Мы благодарим также Thomas Broyer, Tyler Close, Alissa Cooper, Bil Corry, corvid, Lisa Dusseault, Roy T. Fielding, Blake Frantz, Anne van Kesteren, Eran Hammer-Lahav, Jeff Hodges, Bjoern Hoehrmann, Achim Hoffmann, Georg Koppen, Dean McNamee, Alexey Melnikov, Mark Miller, Mark Pauley, Yngve N. Pettersen, Julian Reschke, Peter Saint-Andre, Mark Seaborn, Maciej Stachowiak, Daniel Stenberg, Tatsuhiro Tsujikawa, David Wagner, Dan Winship и Dan Witte за их полезные отклики на этот документ.

Адрес автора

Adam Barth

University of California, Berkeley

EMail: abarth@eecs.berkeley.edu

URI: http://www.adambarth.com/

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

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

1Internet Engineering Task Force.

2Internet Engineering Steering Group.

3Augmented Backus-Naur Form — расширенная форма Бэкуса-Наура.

4Transport Layer Security — защита транспортного уровня.

5Application programming interface — интерфейс для прикладных программ. Прим. перев.

6Non-Reserved LDH

7Domain Name System — система доменных имен.

Рубрика: RFC | Комментарии отключены

RFC 6130 Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)

Опубликовано 14.04.2011 автором Nikolai Malykh

Internet Engineering Task Force (IETF)                        T. Clausen
Request for Comments: 6130                      LIX, Ecole Polytechnique
Category: Standards Track                                    C. Dearlove
ISSN: 2070-1721                                          BAE Systems ATC
                                                                 J. Dean
                                               Naval Research Laboratory
                                                              April 2011

Протокол обнаружения соседей (NHDP) для сетей MANET

Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)

Аннотация

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

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

Этот документ является проектом стандарта Internet (Internet Standards Track).

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

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

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

1. Введение

В этом документе описан протокол обнаружения соседей NHDP для мобильных сетей MANET [RFC2501]. Этот протокол использует локальный обмен сообщениями HELLO, позволяющий любому маршрутизатору определить наличие и связность с ближайшими соседями (1-hop) и соседями второго уровня с симметричным соединением (symmetric 2-hop). Сообщения определяются и передаются в пакетах в соответствии со спецификацией [RFC5444].

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

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

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

Данный протокол основан на процессе обнаружения соседей из протокола OLSR⁵ [RFC3626].

1.1. Мотивация

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

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

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

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

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

Протоколы маршрутизации MANET (например, [RFC3626] и [RFC5449]) часто используют сокращение множества используемых трансляторов в целях экономии «емкости» сети, расходуемой на поддержку топологической информации о сети в целом, при этом сокращенный набор трансляторов включает информацию вплоть до двух интервалов маршрутизации (hop).

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

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

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

Все термины, введенные в [RFC5444], включая packet, message, Address Block, TLV Block, TLV, address, address prefix, address object, интерпретируются в соответствии с этим документом.

В дополнение к этому данная спецификация использует описанные ниже термины.

Network Address — адрес сети

Адрес и связанный с ним размер префикса. Это может быть адрес с максимальным размером префикса или адрес, включающий связанный с ним размер префикса. Таким образом, этот параметр (network address) представляет диапазон адресов.

Router — маршрутизатор

Маршрутизатор MANET, поддерживающий описанный здесь протокол обнаружения соседей.

Interface — интерфейс

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

MANET interface — интерфейс MANET

Интерфейс, участвующий в работе MANET и использующий этот протокол обнаружения соседей. Маршрутизатор может иметь несколько интерфейсов MANET.

Heard — слышимость

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

Link — соединение

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

Symmetric link — симметричное соединение

Соединение между двумя интерфейсами MANET является симметричным, если оба интерфейса могут слышать друг друга.

1-hop neighbor — ближайший сосед

Маршрутизатор X является ближайшим соседом (1-hop neighbor) маршрутизатора Y, если интерфейс MANET в маршрутизаторе X слышен интерфейсу MANET в маршрутизаторе Y.

Symmetric 1-hop neighbor — ближайший сосед с симметричным соединением

Маршрутизатор X является ближайшим соседом с симметричным соединением (symmetric 1-hop neighbor) для маршрутизатора Y, если имеется симметричное соединение между интерфейсами MANET маршрутизаторов X и Y.

2-hop neighbor — сосед, следующий за ближайшим (сосед второго уровня)

Маршрутизатор X является соседом второго уровня (2-hop neighbor) для маршрутизатора Y, если X является ближайшим соседом ближайшего соседа маршрутизатора Y, но не самого маршрутизатора Y.

Symmetric 2-hop neighbor — сосед второго уровня с симметричным соединением

маршрутизатор X является соседом второго уровня с симметричным соединением для маршрутизатора Y, если X является ближайшим соседом с симметричным соединением для ближайшего соседа Y с симметричным соединением, но не для самого маршрутизатора Y.

1-hop neighborhood — ближайшая окрестность

Ближайшая окрестность маршрутизатора X — это множество ближайших соседей маршрутизатора X.

Symmetric 1-hop neighborhood — ближайшая окрестность с симметричным соединением

Ближайшая окрестность маршрутизатора X с симметричными соединениями — это множество ближайших соседей маршрутизатора X, имеющих симметричные соединения с ним.

2-hop neighborhood — окрестность второго уровня

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

Symmetric 2-hop neighborhood — окрестность второго уровня с симметричным соединением

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

Constant — константа

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

Interface parameter — параметр интерфейса

Логическое или числовое значение, задаваемое раздельно для каждого интерфейса MANET в каждом маршрутизаторе. Маршрутизатор может менять значения параметров в любой момент с учетом ограничений.

Router parameter — параметр маршрутизатора

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

Information Base — информационная база

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

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

X contains y, or y is contained in X — X содержит y или y содержится в X

Оператор принадлежности к неупорядоченному списку. X является неупорядоченным списком, а y — его элементом. Выражения «X содержит y» или «y содержится X» возвращают значение true (истина), если список X включает элемент y, и false — в противном случае.

X contains Y, or Y is contained in X — X содержит Y или Y содержится в X

Оператор включения в неупорядоченный список. X и Y являются неупорядоченными списками. Выражения «X содержит Y» и «Y содержится в X» возвращают значение true (истина), если список X содержит все элементы y из списка Y и false — в противном случае.

A overlaps B — A перекрывается с B

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

a := b

Оператор присвоения, в котором левой части (a) присваивается значение из правой части (b). a и b могут быть просто величинами, адресами сетей или неупорядоченными списками (они должны быть одного типа).

c = d

Оператор сравнения, возвращающий значение true (истина), если значение левой части (c) равно значению правой части (d). c и d могут быть просто величинами, адресами сетей или неупорядоченными списками (они должны быть одного типа). Если c и d — неупорядоченные списки, они считаются равными, если c содержит d и d содержит c (т. е., оба списка включают одинаковые наборы элементов без учета порядка их размещения в списках). Если c и d — адреса сетей, они считаются равными при совпадении адресов и размеров префиксов.

e != f

Оператор сравнения, возвращающий значение not (e = f), т. е. true, если (e = f) возвращает false и false, если (e = f) возвращает true.

3. Заявление о применимости

Данный протокол:

применим для сетей (в частности, беспроводных), где можно связаться с неизвестными соседями с помощью локальных широковещательных или групповых пакетов;
предназначен для работы в сетях с изменяющейся топологией, где сообщения могут теряться (например, в результате конфликтов в беспроводной сети);
поддерживает маршрутизаторы, имеющие хотя бы один интерфейс MANET; набор интерфейсов таких маршрутизаторов может изменяться с течением времени; с каждым интерфейсом может быть связан один или множество адресов сетей, которые могут динамически изменяться;
обеспечивает каждому маршрутизатору локальную топологическую информацию на удалении до двух интервалов (hop) и делает ее доступной для протоколов маршрутизации MANET через информационные базы;
использует форматы пакетов и сообщений, заданные в [RFC5444], включая определение типа сообщения HELLO, используемого для передачи сведений о локальной топологии;
обеспечивает возможность «внутренних» и «внешних» расширений, разрешенную [RFC5444];
может взаимодействовать с другими протоколами (например, протоколами маршрутизации MANET, описанными у разделе 16) и расширяться с их помощью;
может использовать имеющую отношение к делу информацию канального уровня при ее доступности;
разработан для работы в полностью распределенном режиме без какой-либо централизации.

4. Обзор работы протокола

Целью данного протокола является (для каждого маршрутизатора):

идентификация ближайших соседей (1-hop neighbor) и ближайших соседей с симметричным соединением;
нахождение адресов сетей для интерфейсов соседей второго уровня с симметричным соединением;
запись информации в Information Base и обеспечение ее доступности для других протоколов, использующих протокол обнаружения соседей;
обеспечение возможности использования другими протоколами, которые могут расширять набор информации в базах, включая добавление конфигураций (Set) в базы, элементов в протокольные упорядоченные списки (Tuple), TLV в исходящие сообщения HELLO и обработка их во входящих сообщениях HELLO.

Эти цели достигаются за счет использования локальной (1 интервал) сигнализации, которая:

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

Данная спецификация определяет:

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

4.1. Маршрутизаторы и интерфейсы

Для участия маршрутизатора в работе сети MANET он должен иметь хотя бы один интерфейс MANET.

Ниже перечислены свойства интерфейсов MANET.

Интерфейс имеет один или несколько адресов сетей и каждый из адресов из диапазона, представленного данным адресом сети должен удовлетворять перечисленным ниже требованиям:
- адрес сети должен быть уникальным для данного маршрутизатора, т. е. его недопустимо присваивать любому интерфейсу любого другого маршрутизатора.
- Если адрес присваивается другим интерфейсам MANET на том же маршрутизаторе, эти интерфейсы MANET должны быть изолированы (т. е., адреса могут быть присвоены разным интерфейсам на одном маршрутизаторе только в том случае, когда на других маршрутизаторах нет интерфейсов MANET, которые могут обмениваться данными с обоими такими интерфейсами). Например, для интерфейсов, использующих разные каналы, может использоваться одинаковый адрес.
Интерфейс имеет набор параметров, определяющих его поведение. Параметры каждого интерфейса MANET могут задаваться индивидуально.
Интерфейс имеет базу Interface Information Base с данными, относящимися к каналам на данный интерфейс MANET и соседям второго уровня с симметричным соединением, которые доступны через этот интерфейс.
Интерфейс генерирует и обрабатывает сообщения HELLO.

В дополнение к набору описанных выше интерфейсов MANET каждый маршрутизатор имеет базы:

Local Information Base с адресами сетей для интерфейсов (MANET и не-MANET) данного маршрутизатора; содержимое этой базы не меняется с помощью сигнализации;
Neighbor Information Base с данными об имеющихся и недавно утраченных ближайших соседях.

Маршрутизатор может иметь не только интерфейсы MANET. Информация о всех этих интерфейсах записывается в Local Information Base, которая используется, но не изменяется в сигнализации данного протокола.

4.2. Обзор информационных баз

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

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

Информация для Local Information Base определяется локально и включается в сообщения HELLO. Информация для Interface Information Base и Neighbor Information Base определяется из полученных сообщений HELLO и часть этой информации может включаться в передаваемые сообщения HELLO. Срок действия этой информации ограничен и определяется значением VALIDITY_TIME TLV в сообщении HELLO, доставившем эти данные, которое, в свою очередь, устанавливается маршрутизатором, создавшим сообщение HELLO, в соответствии со значением параметра интерфейса H_HOLD_TIME.

В Приложении E показаны связи между получением сообщений, значениями VALIDITY_TIME TLV и сроком действия информации, полученной в сообщении HELLO. В Приложении F даны примеры топологии и связанной с ней информации в базах.

4.2.1. Локальная информационная база

Маршрутизатор поддерживает Local Information Base с данными локальной конфигурации, включающими, в частности:

конфигурацию Local Interface Set с упорядоченными списками Local Interface Tuple, каждый их которых представляет интерфейс (не обязательно MANET) данного маршрутизатора;
конфигурацию Removed Interface Address Set с упорядоченными списками Removed Interface Address Tuple, каждый из которых представляет недавно использованный адрес сети на интерфейсе (не обязательно MANET) данного маршрутизатора.

Конфигурация Local Interface Set используется при генерации сообщений HELLO, в частности, для определения адресов сетей на интерфейсе, которые будут включаться в сообщение и идентифицироваться, как локальные интерфейсы. Конфигурация Removed Interface Address Set используется для предотвращения некорректной записи использованного ранее адреса сети в качестве адреса сети соседа второго уровня с симметричным подключением.

Локальная информационная база используется при генерации сигналов, но сама не обновляется по сигналам, описанным в данном документе. Обновления Local Information Base происходят при изменении конфигурации маршрутизатора и могут служить инициаторами передачи сигналов.

4.2.2. База информации об интерфейсах

Каждый маршрутизатор поддерживает для каждого из своих интерфейсов MANET базу Interface Information Base, содержащую данные о ближайших соседях и соседях второго уровня с симметричным соединением, полученные от этого интерфейса MANET. База, в частности, включает перечисленные ниже конфигурации.

Link Set с информацией об имеющихся и недавно утерянных соединениях между данным интерфейсом MANET и интерфейсами MANET у ближайших соседей. Конфигурация Link Set состоит из списков Link Tuple, каждый из которых содержит сведения об одном соединении. Информация о качестве соединения (см. раздел 14), при ее использовании, записывается в Link Tuple.
2-Hop Set с записями о наличии симметричных соединений ближайших соседей, с которыми организовано симметричное соединение через данный интерфейс MANET, с другими маршрутизаторами (соседи второго уровня с симметричным соединением). Конфигурация 2-Hop Set состоит из списков 2-Hop Tuple, каждый из которых включает адрес сети соседа второго уровня с симметричным соединением и все адреса сетей соответствующего ближайшего соседа с симметричным соединением.

Конфигурация Link Set для интерфейса MANET служит для генерации сообщений HELLO. В частности, данные из Link Set служат для того, чтобы обеспечить другим маршрутизаторам возможность идентификации симметричных соединений и заполнения конфигурации 2-Hop Set. Недавно утерянные соединения записываются в конфигурацию Link Set для интерфейса MANET и могут анонсироваться в сообщениях HELLO для ускоренного их удаления из конфигураций Link Set для соответствующих ближайших соседей.

Сама конфигурация Link Set для интерфейса MANET обновляется при получении сообщений HELLO, включающих записи о симметричных соединениях, упомянутые выше. Конфигурация 2-Hop Set для интерфейса MANET обновляется, как указано выше, но сама по себе не применяется при генерации сообщений HELLO.

4.2.3. База информации о соседях

Каждый маршрутизатор поддерживает Neighbor Information Base с информацией об имеющихся и недавно утраченных ближайших соседях. Эта база включает, в частности:

Конфигурацию Neighbor Set состоящую из списков Neighbor Tuple, в каждом из которых записаны все адреса сетей для одного из ближайших соседей. Списки Neighbor Tuple поддерживаются в течение всего срока существования соответствующего Link Tuple.
Конфигурацию Lost Neighbor Set со списками Lost Neighbor Tuple, каждый из которых содержит адрес сети для недавно потерянного ближайшего соседа с симметричным подключением.

Конфигурация Neighbor Set включает все адреса сетей для каждого из ближайших соседей. Эти адреса могут включаться в создаваемые сообщения HELLO, чтобы другие ближайшие соседи с симметричным соединением могли включить их в свою конфигурацию 2-Hop Set. Neighbor Set может обновляться по полученным сообщениям HELLO.

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

4.3. Обзор сигнализации

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

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

Каждое сообщение HELLO:

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

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

4.3.1. Генерация сообщений HELLO

Сообщения HELLO генерируются маршрутизатором для каждого из его интерфейсов MANET и могут передаваться:

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

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

Сообщения HELLO могут независимо планироваться для каждого интерфейса MANET в маршрутизаторе или использовать общее планирование для всех интерфейсов MANET.

4.3.2. Содержимое сообщений HELLO

Содержимое сообщений HELLO должно соответствовать приведенным ниже требованиям.

Сообщение HELLO должно содержать все адреса сетей из конфигурации Local Interface Set маршрутизатора, на котором это сообщение генерируется, включая:
- по крайней мере один адрес сети каждого интерфейса MANET в маршрутизаторе;
- адреса сетей, включающие все адреса отправителей всех дейтаграмм IP, передаваемых маршрутизатором через каждый из его интерфейсов MANET;
- все другие адреса сетей на маршрутизаторе, которые сообщаются другим маршрутизаторам по той или иной причине.
Для каждого интерфейса MANET в течение каждого интервала времени, равного соответствующему значению REFRESH_INTERVAL, сообщения HELLO должны включать всю имеющую отношение к делу информацию из соответствующих Link Set и Neighbor Information Base⁶.
При решении вопроса о включении данной части информации о соседе в сообщение HELLO не достаточно проверки была ли эта информация передана в интервале REFRESH_INTERVAL до текущего времени. Вместо этого маршрутизатор должен рассмотреть интервал REFRESH_INTERVAL до момента завершения ожидания передачи следующего сообщения HELLO через данный интерфейс MANET (обычно это HELLO_INTERVAL от текущего времени, но может быть и меньший интервал, если этот маршрутизатор примет решение о разделе информации о соседе между несколькими сообщениями HELLO для уменьшения размера таких сообщений). Вся информация о соседе должна быть отправлена в этом интервале, т. е. маршрутизатор должен обеспечить за этот интервал включение всех информации о соседе, не переданной в каких-либо сообщениях HELLO с начала отсчета этого интервала (обычно текущее время за вычетом REFRESH_INTERVAL + HELLO_INTERVAL).
Сообщение HELLO должно включать в точности одно VALIDITY_TIME Message TLV (как указано в [RFC5497]) для индикации промежутка времени, в течение которого содержимое сообщения считается достоверным и, следовательно, включается в Interface Information Base получившего его маршрутизатора.
В периодически генерируемые сообщения HELLO следует включать в точности одно INTERVAL_TIME Message TLV (как указано в [RFC5497]) для индикации текущего значения HELLO_INTERVAL на данном интерфейсе MANET (т. е., периода в течение которого гарантируется передача следующего сообщения HELLO с данного интерфейса MANET).

4.3.3. Обработка сообщений HELLO

Полученные маршрутизатором сообщения HELLO используются при обновлении Interface Information Base для интерфейса MANET, принявшего сообщение, а также Neighbor Information Base для маршрутизатора.

Маршрутизатор проверяет наличие единственного Neighbor Tuple, соответствующего инициатору HELLO.
Маршрутизатор проверяет наличие Link Tuple с приемлемым статусом (слышимый или симметрично подключенный) и соответствие анонсированной продолжительности каналу между интерфейсами MANET, через которые было передано и принято сообщение HELLO. Может создаваться один или множество списков Lost Neighbor Tuple, если сообщение HELLO говорит о потере соединений.
Если соединение между интерфейсами MANET, через которые было передано и принято сообщение HELLO, является симметричным, маршрутизатор проверяет наличие подходящих списков 2-Hop Tuple с анонсированной продолжительностью.

Определенная в этой спецификации обработка предусматривает неожиданную и ошибочную информацию в сообщениях HELLO, поддерживая ограничения для содержимого Information Base, описанные в Приложении B.

4.4. Качество соединений

Некоторые соединения в сети MANET могут оказаться малоприменимыми (например, по причине некачественного распространения радиосигнала. Для предотвращения использования таких каналов в каждый список Link Tuple включается оценка качества соединения. Маршрутизатор MANET рассматривает каналы с недостаточным уровнем качества, как потерянные. Изменение значения качества соединения в Link Tuple является необязательным. Если значение качества не изменяется, оно всегда должно указывать применимость данного соединения.

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

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

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

5. Параметры и константы протокола

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

5.1. Номера протокола и портов

Этот протокол задает сообщения HELLO, которые включаются в пакеты, определенные в [RFC5444]. Эти пакеты могут передаваться с использованием общеизвестного номера протокола manet или общеизвестного номера порта UDP manet, как указано в [RFC5498].

5.2. Групповой адрес

Этот протокол задает сообщения HELLO, которые включаются в пакеты, определенные в [RFC5444]. Эти пакеты могут передаваться локально с использованием группового адреса LL-MANET-Routers, как указано в [RFC5498].

5.3. Параметры интерфейса

Используемые в этой спецификации параметры интерфейсов можно разделить на 4 категории:

интервалы между сообщениями;
время достоверности информации;
качество соединения;
вариации.

Параметры подробно описаны ниже.

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

5.3.1. Интервалы между сообщениями

Сообщения HELLO служат двум основным целям:

анонсирование адресов сетей на интерфейсах этого маршрутизатора ближайшим соседям (частота передачи таких анонсов определяется параметрами интерфейса HELLO_INTERVAL и HELLO_MIN_INTERVAL);
анонсирование маршрутизатором своей информации о ближайших соседях (частота передачи таких анонсов определяется параметром интерфейса REFRESH_INTERVAL).

HELLO_INTERVAL

Максимальный перерыв между двумя последовательными сообщениями HELLO на данном интерфейсе MANET. При периодической отправке сообщений HELLO их следует передавать с интервалом HELLO_INTERVAL, возможно измененном вариациями [RFC5148].

HELLO_MIN_INTERVAL

Минимальный перерыв между двумя последовательными сообщениями HELLO на данном интерфейсе MANET (может быть изменен вариациями, определенными в [RFC5148]).

REFRESH_INTERVAL

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

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

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

Ниже приведены ограничения, применимые к описанным параметрам интерфейсов.

HELLO_INTERVAL > 0;
HELLO_MIN_INTERVAL >= 0;
HELLO_INTERVAL >= HELLO_MIN_INTERVAL;
REFRESH_INTERVAL >= HELLO_INTERVAL;
при включении INTERVAL_TIME Message TLV (как определено в [RFC5497]) в сообщение HELLO, значение HELLO_INTERVAL должно представляться в соответствии с [RFC5497].

Если REFRESH_INTERVAL > HELLO_INTERVAL, маршрутизатор может распределять анонсы соседей между сообщениями HELLO любым способом с учетом приведенных выше ограничений.

При отсутствии изменений в локальной окрестности маршрутизатор будет передавать сообщения HELLO на интерфейсе MANET по истечении интервала HELLO_INTERVAL (возможно с вариациями). Для того, чтобы поддерживающий этот протокол маршрутизатор передавал сообщения HELLO на интерфейсе MANET только в ответ на внешние события, значение HELLO_INTERVAL (и, следовательно, REFRESH_INTERVAL) следует устанавливать достаточно большим (т. е., сообщения HELLO в ответ на внешнее события должны передаваться заведомо чаще этого интервала).

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

5.3.2. Время достоверности информации

Описанные ниже параметры управляют временем достоверности информации о соединениях.

L_HOLD_TIME

Период анонсирования в сообщениях HELLO на данном интерфейсе MANET адреса сети бывшего ближайшего соседа, как потерянного, позволяет получателям этого сообщения HELLO ускорить удаление соответствующей информации из своих конфигураций Link Set. Если ускоренное удаление информации не требуется, можно установить L_HOLD_TIME = 0.

H_HOLD_TIME

Используется в качестве Value в VALIDITY_TIME Message TLV, включаемом во все сообщения HELLO на данном интерфейсе MANET. Это значение используется каждым маршрутизатором, получившим сообщение HELLO, для индикации достоверности информации из данного сообщения HELLO, записываемой в информационные базы маршрутизатора.

Поскольку каждый элемент информации о соседе включается в сообщения HELLO в интервале времени REFRESH_INTERVAL, ограничения H_HOLD_TIME основаны на значении REFRESH_INTERVAL, а не HELLO_INTERVAL.

Для приведенных выше параметров имеется ряд ограничений:

L_HOLD_TIME >= 0;
H_HOLD_TIME >= REFRESH_INTERVAL;
если сообщения HELLO могут теряться, для обоих параметров следует выбирать значения существенно больше REFRESH_INTERVAL;
H_HOLD_TIME должно представляться в соответствии с [RFC5497].

5.3.3. Качество соединения

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

HYST_ACCEPT

Порог качества канала, после превышения которого неиспользуемый канал считается используемым.

HYST_REJECT

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

INITIAL_QUALITY

Начальный уровень качества для недавно обнаруженного соединения.

INITIAL_PENDING

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

Для приведенных выше параметров имеется ряд ограничений:

0 <= HYST_REJECT <= HYST_ACCEPT <= 1;
0 <= INITIAL_QUALITY <= 1;
если качество соединения не обновляется, то INITIAL_QUALITY >= HYST_ACCEPT;
если INITIAL_QUALITY >= HYST_ACCEPT, то INITIAL_PENDING := false;
если INITIAL_QUALITY < HYST_REJECT, то INITIAL_PENDING := true.

5.3.4. Вариации

При использовании вариаций (jitter), определенных в [RFC5148], применяются также перечисленные ниже параметры.

HP_MAXJITTER

Представляет значение MAXJITTER, используемое в [RFC5148] для периодически генерируемых сообщений HELLO на данном интерфейсе MANET.

HT_MAXJITTER

Представляет значение MAXJITTER, используемое в [RFC5148] для вызванных внешними событиями сообщений HELLO на данном интерфейсе MANET.

Ограничения для этих параметров описаны в [RFC5148].

5.4. Параметры маршрутизаторов

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

5.4.1. Время достоверности информации

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

N_HOLD_TIME

Задает период, в течение которого адреса сетей бывшего ближайшего соседа анонсируются, как потерянные, в сообщениях HELLO, что позволяет получателям этих сообщений HELLO ускорять удаление этой информации из своих конфигураций 2-Hop Set. Если ускоренное удаление информации не требуется, можно установить N_HOLD_TIME MAY = 0.

I_HOLD_TIME

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

Для приведенных выше параметров имеется ряд ограничений:

   N_HOLD_TIME >= 0
   I_HOLD_TIME >= 0

5.5. Ограничения на изменение параметров

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

HELLO_INTERVAL

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

Если значение HELLO_INTERVAL для интерфейса MANET уменьшается, следующие сообщения HELLO на данном интерфейсе MANET должны передаваться в соответствии с новым (меньшим) значением HELLO_INTERVAL.

REFRESH_INTERVAL

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

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

HYST_ACCEPT and HYST_REJECT

При изменении HYST_ACCEPT или HYST_REJECT должны предприниматься действия по изменению качества каналов, описанные в параграфе 14.3.

L_HOLD_TIME

При изменении L_HOLD_TIME время достоверности всех имеющих к этому отношение списков Link Tuple должно меняться.

N_HOLD_TIME

При изменении N_HOLD_TIME время достоверности всех имеющих к этому отношение списков Lost Neighbor Tuple должно меняться.

HP_MAXJITTER

При изменении HP_MAXJITTER планирование периодических сообщений HELLO на этом интерфейсе MANET может быть изменено.

HT_MAXJITTER

При изменении HT_MAXJITTER вызываемые внешними событиями сообщения HELLO на данном интерфейсе MANET могут быть перепланированы.

5.6. Константы

Константа C (квант отсчета времени) используется в соответствии с [RFC5497].

6. База локальной информации

Маршрутизатор поддерживает базу локальной информации (Local Information Base) с записями о своих интерфейсах (не только MANET). Каждый интерфейс маршрутизатора должен идентифицироваться хотя бы одни адресом сети. Адрес может быть специфическим для одного интерфейса, а в некоторых случаях может совместно использоваться несколькими интерфейсами, как описано ниже.

Содержимое Local Information Base не меняется под воздействием сигнализации. Если конфигурация маршрутизатора меняется, эти изменения должны быть отражены в Local Information Base. Такие изменения могут также приводить к сигнализации для анонсирования изменений.

Не обязательно включать все адреса интерфейса в Local Information Base и, следовательно, в сообщения HELLO. Однако любые адреса, которые могут указываться в качестве источника переданных интерфейсом дейтаграмм IP, должны включаться в базу (для каждого интерфейса в базе должен присутствовать по крайней мере один адрес). Протокол, использующий эту спецификацию, может предъявлять дополнительные требования (например, о включении всех адресов, которые могут использоваться в качестве адреса получателя в дейтаграммах IP).

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

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

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

6.1. Конфигурация локальных интерфейсов

В конфигурации Local Interface Set хранятся записи о локальных интерфейсах маршрутизатора, состоящие из списков Local Interface Tuple вида

      (I_local_iface_addr_list, I_manet)

где

I_local_iface_addr_list — неупорядоченный список адресов сетей для данного интерфейса;

I_manet — флаг, указывающий относится ли данный интерфейс к MANET.

Списки Local Interface Tuple удаляются из конфигурации Local Interface Set только при изменении конфигурации интерфейсов в маршрутизаторе (см. раздел 9), т. е., не зависят от каких-либо таймеров.

6.2. Конфигурация адресов удаленных интерфейсов

В конфигурации Removed Interface Address Set на маршрутизаторе хранятся адреса сетей, которые недавно использовались в качестве адресов сетей для локальных интерфейсов этого маршрутизатора. Если адреса сетей на интерфейсах маршрутизатора неизменны, конфигурация Removed Interface Address Set всегда будет пустой и может быть опущена. Конфигурация состоит из упорядоченных списков Removed Interface Address Tuple вида

      (IR_local_iface_addr, IR_time)

где

IR_local_iface_addr — недавно использовавшийся адрес сети на интерфейсе данного маршрутизатора;

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

7. Базы информации об интерфейсах

Маршрутизатор поддерживает базе Interface Information Base для каждого из своих интерфейсов MANET. В этой базе хранятся сведения о каналах к данному интерфейсу MANET и соседях второго уровня с симметричным соединением, доступных через этот интерфейс (в качестве первого интервала). Каждая база Interface Information Base включает конфигурации Link Set и 2-Hop Set.

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

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

7.1. Конфигурация соединения

Конфигурация Link Set для интерфейса указывает соединения с другими маршрутизаторами (которые являются или недавно были ближайшими соседями) через данный интерфейс и состоит из списков Link Tuple вида

(L_neighbor_iface_addr_list, L_HEARD_time, L_SYM_time, L_quality, L_pending, L_lost, L_time)

где

L_neighbor_iface_addr_list — неупорядоченный список адресов сетей на интерфейсе MANET ближайшего соседа;

L_HEARD_time — время, до завершения которого интерфейс MANET ближайшего соседа считается слышимым, если не принимается во внимание качество соединения;

L_SYM_time — время, до завершения которого соединение с ближайшим соседом считается симметричным, если не принимается во внимание качество соединения;

L_quality — число от 0 до 1, включительно, описывающее качество соединения; большее значение L_quality указывает более высокое качество соединения;

L_pending — флаг, показывающий, является ли соединение ожидающим (т. е., подготовленным, но еще не организованным);

L_lost — флаг, показывающий, считается ли соединение утраченным по причине низкого качества;

L_time задает срок действия данного Tuple, по истечении которого список должен удаляться.

Статус соединения, полученный из обмена сообщениями HELLO и оценки качества канала, обозначается L_status и может принимать значения PENDING, HEARD, SYMMETRIC и LOST. Значения LOST, SYMMETRIC и HEARD определены в параграфе 18.5. Значение PENDING никогда не используется в сообщениях HELLO и применяется только локально самим маршрутизатором и может быть любым, отличающимся от LOST, SYMMETRIC и HEARD.

L_status определяется следующим образом:

если L_pending = true, то L_status := PENDING;
иначе, если L_lost = true, то L_status := LOST;
иначе, если время L_SYM_time не истекло, L_status := SYMMETRIC;
иначе, если время L_HEARD_time не истекло, L_status := HEARD;
в остальных случаях L_status := LOST.

7.2. 2-Hop Set

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

      (N2_neighbor_iface_addr_list, N2_2hop_addr, N2_time)

где

N2_neighbor_iface_addr_list — неупорядоченный список адресов сетей на интерфейсе MANET ближайшего соседа с симметричным соединением, от которого была получена информация;

N2_2hop_addr — адрес сети соседа второго уровня с симметричным соединением, который имеет симметричное соединение с указанным выше ближайшим соседом, используя интерфейс MANET;

N2_time задает срок действия данного Tuple, по истечении которого список должен удаляться.

8. База информации о соседях

Каждый маршрутизатор поддерживает Neighbor Information Base с адресами сетей текущих и недавних ближайших соседей с симметричным подключением.

8.1. Множество соседей

Конфигурация Neighbor Set содержит все адреса сетей для каждого из ближайших соседей и состоит из списков Neighbor Tuple для каждого соседа

      (N_neighbor_addr_list, N_symmetric)

где

N_neighbor_addr_list — неупорядоченный список адресов сетей ближайшего соседа;

N_symmetric — флаг симметричности соединения с данным соседом.

Списки Neighbor Tuple удаляются из Neighbor Set только при завершении срока действия соответствующих списков Link Tuple в конфигурации Link Set, т. е., Neighbor Tuple не удаляются напрямую по таймерам.

8.2. Множество утерянных соседей

Конфигурация Lost Neighbor Set содержит адреса сетей маршрутизаторов, которые недавно были ближайшими соседями с симметричным соединением, но анонсированы, как потерянные. Конфигурация состоит из упорядоченных списков Lost Neighbor Tuple, каждый из которых представляет один адрес сети

      (NL_neighbor_addr, NL_time)

где

NL_neighbor_addr — адрес сети маршрутизатора, который недавно был ближайшим соседом с симметричным соединением;

NL_time задает срок действия данного Tuple, по истечении которого список должен удаляться.

9. Изменения базы локальной информации

База Local Information Base должна обновляться при изменении конфигурации локальных интерфейсов маршрутизатора. При этом могут изменяться также базы Interface Information Base и Neighbor Information Base. Если любые изменения в этих двух базах удовлетворяют условиям, описанным в разделе 13, эти изменения должны быть применены незамедлительно, если ниже не указано иное.

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

9.1. Добавление интерфейса

Добавление интерфейса на маршрутизаторе указывается путем добавления списка Local Interface Tuple в конфигурацию Local Interface Set. Если новый интерфейс относится к MANET, для него должна создаваться исходно пустая база Interface Information Base. Для каждого адреса сети на этом интерфейсе должны быть выполнены действия, указанные в параграфе 9.3. Сообщение HELLO может быть передано через все интерфейсы MANET и такое сообщение следует передать через новый интерфейс, если он относится к MANET. При использовании планирования сообщений должно быть организовано планирование для нового интерфейса MANET.

9.2. Удаление интерфейса

Удаление интерфейса на маршрутизаторе должно сопровождаться перечисленными ниже изменениями в базах Local Information Base и Neighbor Information Base.

Определяется список Local Interface Tuple, соответствующий удаляемому интерфейсу.
Для каждого адреса сети (далее, удаляемый адрес) в I_local_iface_addr_list данного списка Local Interface Tuple если этот адрес не входит в I_local_iface_addr_list какого-либо другого списка Local Interface Tuple, создается список Removed Interface Address Tuple с приведенными ниже значениями:

- IR_local_iface_addr := удаляемый адрес;
- IR_time := текущее время + I_HOLD_TIME.

Данный список Local Interface Tuple удаляется из конфигурации Local Interface Set.
Если удаляется интерфейс MANET (т. е., интерфейс с I_manet = true), выполняются следующие действия:
1. удаляется база Interface Information Base для этого интерфейса MANET;
2. все списки Neighbor Tuple, в которых ни один из адресов сетей в их N_neighbor_addr_list не содержится в каком-либо из L_neighbor_iface_addr_list того или иного сохраняющегося списка Link Tuple, удаляются.

Если удаляется последний интерфейс MANET на данном маршрутизаторе, баз Interface Information Base после этого не останется и маршрутизатор больше не будет участвовать в работе данного протокола.

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

9.3. Добавление сетевого адреса на интерфейсе

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

Удаляются все списки Removed Interface Address Tuple, где IR_local_iface_addr содержит добавленный адрес.
Удаляются все списки Neighbor Tuple, где N_neighbor_addr_list содержит адрес сети, пересекающийся с добавленным адресом.
Удаляются все списки Link Tuples во всех конфигурациях Link Set для которых выполняется любое из условий:

- - L_neighbor_iface_addr_list содержит любой адрес сети в N_neighbor_addr_list любого из удаляемых списков Neighbor Tuple;
  - L_neighbor_iface_addr_list содержит адрес сети, пересекающийся с добавленным адресом,

выполняются действия из параграфа 13.2, но не из 13.3;

Удаляются все списки Lost Neighbor Tuple, где NL_neighbor_addr пересекается с добавленным адресом сети.
Удаляются все списки 2-Hop Tuples, где N2_2hop_addr пересекается с добавленным адресом сети.

После добавления интерфейса и выполнения перечисленных действий может быть передано сообщение HELLO через все интерфейсы MANET.

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

9.4. Удаление сетевого адреса на интерфейсе

При удалении адреса сети (далее, удаляемый адрес) на интерфейсе выполняются перечисленные ниже действия.

Определяется список Local Interface Tuple, соответствующий удаляемому адресу.
Если этот адрес является единственным адресом сети на интерфейсе (в соответствующем I_local_iface_addr_list только один адрес), данный интерфейс удаляется, как описано в параграфе 9.2.
В остальных случаях:
1. адрес удаляется из I_local_iface_addr_list;
2. если удаляемого адреса нет в I_local_iface_addr_list никаких других списков Local Interface Tuple, создается список Removed Interface Address Tuple с приведенными ниже значениями:

- IR_local_iface_addr := удаляемый адрес;
- IR_time := текущее время + I_HOLD_TIME.

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

10. Пакеты и сообщения

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

Протокол использует единственный тип сообщений (Message Type) — HELLO.
В сообщениях HELLO может использоваться любая комбинация опций заголовка сообщения (Message Header), определенных в [RFC5444].
Пересылка сообщений HELLO недопустима, т. е. при наличии <msg-hop-limit> этот параметр должен иметь значение 1.
Множество сообщений HELLO может помещаться в один пакет, как указано в [RFC5444].
Разбор полученных сообщений HELLO должен выполняться в соответствии с [RFC5444]. Сообщения HELLO, не соответствующие спецификации [RFC5444], должны отбрасываться без обработки. Возможно отбрасывание сообщений HELLO без обработки и по иным причинам (см. параграф 12.1).
Протокол задает три Address Block TLV и использует также два Message TLV, определенных в [RFC5497]. Для этих пяти типов TLV определено единственное расширение — Extension = 0. TLV всех прочих типов и этих пяти типов без Type Extension = 0 игнорируются данным протоколом. Все случаи использования в данной спецификации Address Block TLV с Type = LINK_STATUS подразумевают использование Address Block TLV с Type = LINK_STATUS и Type Extension = 0.

10.1. Сообщения HELLO

Сообщение HELLO должно включать:

в точности один экземпляр VALIDITY_TIME Message TLV, как указано в [RFC5497], представляющий значение H_HOLD_TIME для передающего интерфейса MANET.

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

В сообщения HELLO, передаваемые периодически, следует включать, а в остальные (передаваемые по иным причинам, например, в ответ на изменения информационных баз) можно включать:

в точности один экземпляр INTERVAL_TIME Message TLV, как указано в [RFC5497], представляющий значение HELLO_INTERVAL для передающего интерфейса MANET. Эта опция включена в [RFC5497] для представления того, что недопустимо использовать интервалы нулевой и бесконечной продолжительности.

Сообщение HELLO может включать:

иные Message TLV;
один или множество Address Block, каждый из которых связан с Address Block TLV Block, который может включать другие Address Block TLV.

10.1.1. Блоки адресов

Все адреса сетей в базе локальных интерфейсов маршрутизатора Local Interface Set (т. е., в любом I_local_iface_addr_list) должны быть представлены, как адресные объекты (см. [RFC5444]), и включены в блоки адресов (Address Block) всех генерируемых сообщений HELLO с учетом приведенного ниже исключения.

Если интерфейс MANET, через который будет передано сообщение HELLO, имеет единственный адрес с префиксом максимального размера (/32 для IPv4, /128 для IPv6), такой адрес может не включаться в Address Block, поскольку он указан в поле отправителя в заголовке дейтаграммы IP, содержащей сообщение HELLO.

Все адреса сетей на интерфейсах маршрутизатора, включенные в какой-либо из Address Block, должны быть связаны с Address Block TLV с Type = LOCAL_IF, как показано в таблице 1.

Таблица 1. Определение LOCAL_IF TLV.

Имя	Размер	Описание
LOCAL_IF	1 октет	Указывает, что адрес сети связан с интерфейсом MANET, через который было передано сообщение (THIS_IF), или другим интерфейсом того же маршрутизатора (OTHER_IF).

Address Block могут содержать адреса сетей текущих или недавно потерянных ближайших соседей, представленные, как адресные объекты (см. [RFC5444]), каждый из которых связан с одним или обоими Address Block TLV, как показано в таблице 2.

Таблица 2. Определения LINK_STATUS и OTHER_NEIGHB TLV.

Имя	Размер	Описание
LINK_STATUS	1 октет	Показывает статус соединения от указанного адреса сети до интерфейса MANET, через который передается сообщение HELLO (LOST, SYMMETRIC или HEARD).
OTHER_NEIGHB	1 октет	Показывает, что адрес сети относится к интерфейсу MANET маршрутизатора, который является (SYMMETRIC) или был (LOST) ближайшим соседом с симметричным соединением для передающего сообщение HELLO маршрутизатора.

Address Block TLV с Type = LINK_STATUS и Value = SYMMETRIC или Value = LOST выполняет также функцию Address Block TLV с Type = OTHER_NEIGHB и таким же значением (Value). Включение последнего с тем же самым адресным блоком не рекомендуется по соображениям эффективности. Если Address Block TLV с Type = LINK_STATUS и Value = SYMMETRIC в комбинации с Address Block TLV с Type = OTHER_NEIGHB и Value = LOST связываются с одним адресным объектом, второй Address Block TLV должен игнорироваться и не следует его включать (см. Приложение A).

Другие адреса сетей можно представлять, как адресные объекты (см. [RFC5444]) и включать в Address Block, но недопустимо связывать с каким-либо из Address Block TLV, указанных в этой спецификации.

11. Генерация сообщений HELLO

Каждый интерфейс MANET должен генерировать сообщения HELLO в соответствии с приведенной в этом разделе спецификацией. Генерация сообщений HELLO для каждого интерфейса MANET выполняется независимо. Генерация и планирование сообщений HELLO должны происходить в соответствии с параметрами данного интерфейса MANET и могут быть независимыми для каждого интерфейса MANET или (если позволяют параметры интерфейсов) могут использовать общее планирование.

При передаче периодических сообщений HELLO интервал между двумя последовательными сообщениями HELLO на одном интерфейсе MANET должен быть не больше HELLO_INTERVAL. Два последовательных сообщения HELLO с одного интерфейса MANET должны быть разделены интервалом не менее HELLO_MIN_INTERVAL, за исключением случаев, указанных в параграфе 11.2.1.

11.1. Спецификация сообщения HELLO

Сообщения HELLO генерируются независимо на каждом интерфейсе MANET.

Все адреса из каждого списка I_local_iface_addr_list должны включаться в сообщения с представлением адресными объектами (см. [RFC5444]), за исключением приведенного ниже случая.

Если интерфейс, через который будет передаваться сообщение HELLO, имеет единственный адрес сети и этот адрес имеет максимальный размер префикса (/32 для IPv4, /128 для IPv6), такой адрес можно опускать, поскольку он включается в заголовок IP содержащей сообщение HELLO дейтаграммы.

Все такие включенные адреса должны быть связаны с Address Block TLV с Type := LOCAL_IF и Value, соответствующим приведенным ниже условиям:

если адресный объект представляет адрес сети передающего сообщение интерфейса MANET, то Value := THIS_IF;
в остальных случаях Value := OTHER_IF.

Если такое адрес включен во множество I_local_iface_addr_list, из соображений эффективности рекомендуется связывать соответствующий адресный объект только с одним Value, используя Address Block TLV с Type := LOCAL_IF; если адресный объект представляется адрес сети передающего сообщение интерфейса MANET, должно устанавливаться Value := THIS_IF.

Следующие адреса сетей текущих или прошлых ближайших соседей могут представляться адресными объектами (см. [RFC5444]) и включаться в любое сообщение HELLO в соответствии с параметром REFRESH_INTERVAL для каждой ассоциации на данном интерфейсе MANET и приведенными ниже правилами.

Адреса сетей на интерфейсах MANET ближайших соседей из конфигурации Link Set в базе Interface Information Base для этого интерфейса MANET (т. е., из списков L_neighbor_iface_addr_list), отличающиеся от адресов из списков Link Tuple с L_status = PENDING.
Другие адреса сетей ближайших соседей с симметричным подключением из конфигурации Neighbor Set в базе данного маршрутизатора Neighbor Information Base (т. е., из списка N_neighbor_addr_list).
Адреса сетей на интерфейсах MANET ранее симметричных или слышимых ближайших соседей, соединенных с данным интерфейсом MANET, из конфигурации Link Set базы Interface Information Base для этого интерфейса MANET (т. е. из L_neighbor_iface_addr_list с L_status = LOST).
Другие адреса сетей ранее симметричных ближайших соседей из конфигурации Lost Neighbor Set в базе данного маршрутизатора Neighbor Information Base (т. е., из NL_neighbor_addr).

Каждый такой адресный объект (см. [RFC5444]) должен быть связан с одним или множеством подходящих Address Block TLV. В частности, должны выполняться приведенные ниже условия.

Для каждого адресного объекта (далее, связанный адрес), который представляет адрес сети, содержащийся в L_neighbor_iface_addr_list списка Link Tuple в конфигурации Link Set для этого интерфейса MANET, и имеет L_status != PENDING, включается связанный адрес со связанным Address Block TLV с

Type := LINK_STATUS
Value := L_status

Для каждого адресного объекта (далее, адрес соседа), который представляет адрес сети, содержащийся в N_neighbor_addr_list из списка Neighbor Tuple с N_symmetric = true, и еще не включен со связанным Address Block TLV с Type = LINK_STATUS и Value = SYMMETRIC, включается адрес соседа со связанным Address Block TLV с

Type := OTHER_NEIGHB
Value := SYMMETRIC

Для каждого списка Lost Neighbor Tuple, в котором NL_neighbor_addr (далее, потерянный адрес) еще не представлен в качестве связанного объекта и не включен, включается потерянный адрес со связанным Address Block TLV с

Type := OTHER_NEIGHB
Value := LOST

Если любой из таких адресов был добавлен в информационные базы с момента отправки последнего сообщения HELLO на данном интерфейсе MANET или статус адрес (указывается TLV и Value, связанными с адресами сетей) изменился с момента последней передачи информации об этом адресе через данный интерфейс MANET, этот адрес сети и указанные TLV следует включить в сообщение HELLO.

Если адресный объект (см. [RFC5444]), представляющий адрес сети ближайшего соседа, задан со множеством связанных Address Block TLV, эти Address Block TLV могут независимо включаться или исключаться для каждого сообщения HELLO. Каждый такой Address Block TLV должен включаться с представлением с помощью адресного объекта такого адреса сети в сообщение HELLO, передаваемое данным интерфейсом MANET в течение каждого интервала, равного по продолжительности со значением параметра REFRESH_INTERVAL для данного интерфейса MANET. Address Block TLV, связанные с общим адресным объектом в одном сообщении HELLO, могут применяться для общей или разных копий этого адресного объекта.

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

11.2. Передача сообщений HELLO

Сообщения HELLO передаются в формате, заданном [RFC5444].

11.2.1. Вариации для сообщений HELLO

Сообщения HELLO могут генерироваться периодически или по внешним событиям. Если на канальном или физическом уровне возможны потери данных в результате конфликтов при доступе к среде передачи, для сообщений HELLO следует вносить временные вариации, описанные в [RFC5148].

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

Пересылка сообщений HELLO недопустима и вариации при пересылке не применяются для сообщений HELLO. Для каждой из форм вариаций в [RFC5148] требуется параметр MAXJITTER. Эти параметры могут быть динамическими и задаются для:

периодических сообщений (HP_MAXJITTER);
вызванных внешними событиями сообщений (HT_MAXJITTER).

Когда генерация сообщения HELLO задерживается для того, чтобы это сообщение не было передано до истечения интервала HELLO_MIN_INTERVAL с момента передачи предыдущего сообщения HELLO на том же интерфейсе MANET, значение HELLO_MIN_INTERVAL следует уменьшать с использованием вариаций с максимальным значением HP_MAXJITTER, как описано в [RFC5148]. В таких случаях недопустимо HP_MAXJITTER > HELLO_MIN_INTERVAL.

12. Обработка сообщений HELLO

При получении сообщения HELLO маршрутизатор сначала должен проверить его пригодность для обработки на данном маршрутизаторе (см. параграф 12.1) и отбросить без обработки непригодное сообщение. Для каждого пригодного для обработки сообщения HELLO принимающий маршрутизатор должен обновить соответствующие базы Interface Information Base и Neighbor Information Base, как указано в параграфах 12.3 — 12.6. Эти обновления должны выполняться в порядке их указания в данной спецификации. Если какое-либо изменение соответствует условиям, описанным в разделе 13, указанные в этом разделе последствия должны применяться незамедлительно, если явно не указано иное.

Вся обработка сообщения, включая проверку его пригодности, выполняется только для TLV с Type Extension = 0. TLV с другими типа расширения игнорируются. Все упоминания, например, TLV с Type = LINK_STATUS говорят о TLV с Type = LINK_STATUS и Type Extension = 0.

12.1. Непригодные сообщения

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

Размер адреса, указанный в Message Header, не совпадает с размером адресов, используемых этим маршрутизатором.
Значение поля <msg-hop-limit> в Message Header отличается от 1 (отметим, что поле <msg-hop-limit> не обязательно).
Значение поля <msg-hop-count> в Message Header отличается от 0 (отметим, что поле <msg-hop-count> не обязательно).
Сообщение не включает Message TLV с Type = VALIDITY_TIME в своем Message TLV Block.
Сообщение включает более одного Message TLV с Type = VALIDITY_TIME в своем Message TLV Block.
Сообщение включает более одного Message TLV с Type = INTERVAL_TIME в своем Message TLV Block.
Сообщение включает любые Address Block TLV с Type = LOCAL_IF и одно Value = v такое, что v != THIS_IF и v != OTHER_IF.
Любой адресный объект (включая разные представления одного сетевого адреса в одном или разных Address Block) связан более чем с одним Value одним или множеством Address Block TLV с Type = LOCAL_IF.
Любой адресный объект (далее, локальный адрес), связанный с Address Block TLV с Type = LOCAL_IF, представляет один из текущий или недавно использованных принимающим маршрутизатором адресов (т. е. локальный адрес перекрывается с любым сетевым адресом в любом I_local_iface_addr_list набора Local Interface Set или в любом IR_local_iface_addr набора Removed Interface Address Set).
Сообщение имеет любые Address Block TLV с Type = LINK_STATUS и любым одним Value v, не равным LOST, SYMMETRIC или HEARD.
Сообщение имеет любые Address Block TLV с Type = OTHER_NEIGHB и любым одним Value v, таким, что v != LOST и v != SYMMETRIC.
Любой адресный объект (включая разные представления одного сетевого адреса в одном или разных Address Block) связан с Address Block TLV, где Type = LOCAL_IF и Address Block TLV, где Type = LINK_STATUS.
Любой адресный объект (включая разные представления одного сетевого адреса в одном или разных Address Block) связан Address Block TLV, где Type = LOCAL_IF и Address Block TLV, где Type = OTHER_NEIGHB.
Любой адресный объект (включая разные представления одного сетевого адреса в одном или разных Address Block) связан множеством Value одним или множеством Address Block TLV с Type = LINK_STATUS.
Любой адресный объект (включая разные представления одного сетевого адреса в одном или разных Address Block) связан множеством Value одним или множеством Address Block TLV с Type = OTHER_NEIGHB.

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

Непригодные сообщения должны отбрасываться без уведомления и обновления Information Base в маршрутизаторе.

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

Для этого раздела отметим приведенные ниже определения.

validity time — время действия

Рассчитывается из Message TLV с Type = VALIDITY_TIME в сообщении HELLO, как указано в [RFC5497] (отметим, что в соответствии с параграфом 12.1 сообщение HELLO должно включать в точности один блок Message TLV). Вся информация в сообщении HELLO, применяемая этой спецификацией, имеет одинаковый срок действия.

Receiving Address List — список принимающих адресов

Список I_local_iface_addr_list, соответствующий интерфейсу MANET, на котором принято сообщение HELLO.

Sending Address List — список передающих адресов

Неупорядоченный список сетевых адресов интерфейса MANET, через который было передано сообщение HELLO, т. е. неупорядоченный список сетевых адресов, представленный адресными объектами в сообщении HELLO со связанным Address Block TLV с Type = LOCAL_IF и Value = THIS_IF. Если Sending Address List иначе будет пуст, он образуется из одного сетевого адреса с префиксом максимального размера (/32 для IPv4, /128 для IPv6), совпадающего с адресом отправителя дейтаграммы IP, в которую было включено сообщение HELLO.

Neighbor Address List — список адресов соседей

Неупорядоченный список всех сетевых адресов всех интерфейсов маршрутизатора, который создал сообщение HELLO, т. е. Sending Address List и сетевые адреса, представленные адресными объектами в сообщении HELLO со связанным Address Block TLV с Type = LOCAL_IF и Value = OTHER_IF.

EXPIRED — истек срок

Указывает, что для таймера установлено время явно раньше текущего времени (например, текущее время — 1).

Removed Address List — список удаленных адресов

Список сетевых адресов, созданных обработкой данного сообщения HELLO, о которых ранее сообщал как о локальных маршрутизатор, создавший сообщение HELLO, но которые не включены в список Neighbor Address List. Данный список инициализируется пустым.

Lost Address List — список потерянных адресов

Подмножество Removed Address List, содержащее сетевые адреса, которые раньше считались симметричными. Данный список инициализируется пустым.

12.3. Обновление Neighbor Set

При получении сообщения HELLO маршрутизатор должен обновить свой Neighbor Set и заполнит списки Removed Address List и Lost Address List, как показано ниже.

Находятся все Neighbor Tuple (далее совпадающие Neighbor Tuple), где N_neighbor_addr_list содержит любой сетевой адрес, перекрывающийся с любым из сетевых адресов в списке Neighbor Address List.
Если нет совпадающих Neighbor Tuples, выполняются указанные ниже действия.
1. Создается Neighbor Tuple с

- N_neighbor_addr_list := Neighbor Address List;
- N_symmetric := false.

Если имеется один совпадающий Neighbor Tuple, выполняются указанные ниже действия.
1. Если в этом Neighbor Tuple выполняется условие N_neighbor_addr_list != Neighbor Address List, то
  1. для каждого сетевого адреса (далее удаленный адрес), который содержится в N_neighbor_addr_list, но не включен в Neighbor Address List
    1. удаленный адрес добавляется в список Removed Address List;
    2. если N_symmetric = true, удаленный адрес добавляется в список Lost Address List;
  2. обновляется совпадающий Neighbor Tuple

- N_neighbor_addr_list := Neighbor Address List.

Если имеется не менее двух совпадающих Neighbor Tuples, выполняются указанные ниже действия.
1. Для каждого сетевого адреса (далее удаленный адрес), который содержится в N_neighbor_addr_list любого из совпадающих Neighbor Tuple, но не включен в Neighbor Address List:
  1. удаленный адрес добавляется в Removed Address List;
  2. если N_symmetric = true, удаленный адрес добавляется в список Lost Address List.
2. Совпадающие Neighbor Tuple заменяются одним Neighbor Tuple с:

- N_neighbor_addr_list := Neighbor Address List;
- N_symmetric := false.

12.4. Обновление Lost Neighbor Set

При получении HELLO маршрутизатор должен обновить свой Lost Neighbor Set, как показано ниже.

Для каждого сетевого адреса (далее потерянный адрес), который содержится в Lost Address List, если нет Lost Neighbor Tuple с NL_neighbor_addr, указывающим потерянный адрес, добавляется Lost Neighbor Tuple с

- NL_neighbor_addr := потерянный адрес;
- NL_time := current time + N_HOLD_TIME.

12.5. Обновление Link Set

При получении HELLO маршрутизатор должен обновить свои Link Set, как показано ниже.

Удалить все сетевые адреса в Removed Address List из L_neighbor_iface_addr_list всех Link Tuple.
Удалить все Link Tuple с непустыми L_neighbor_iface_addr_list (применяется параграф 13.2, но не 13.3).

Затем маршрутизатор должен обновить свой Link Set для интерфейса MANET, принявшего HELLO, как указано ниже.

Найти все Link Tuple (далее совпадающие Link Tuple), где

- L_neighbor_iface_addr_list содержит один или несколько сетевых адресов из Sending Address List.

При наличии нескольких совпадающих Link Tuple все они удаляются (применяется параграф 13.2, но не 13.3).
Если больше нет совпадающих Link Tuples, создается новый совпадающий Link Tuple с:

- L_neighbor_iface_addr_list := пуст;
- L_HEARD_time := EXPIRED;
- L_SYM_time := EXPIRED;
- L_quality := INITIAL_QUALITY;
- L_pending := INITIAL_PENDING;
- L_lost := false;
- L_time := текущее время + срок действия.

Совпадающий Link Tuple (новый или имеющийся) изменяется, как показано ниже.
1. Если маршрутизатор находит любой сетевой адрес (далее принимающий адрес) из Receiving Address List в Address Block сообщения HELLO, Link Tuple изменяется, как показано ниже.
  1. Если любой принимающий адрес в сообщении HELLO связан с Address Block TLV с Type = LINK_STATUS и Value = HEARD или Value = SYMMETRIC, то

- L_SYM_time := текущее время + срок действия.

1. 1. Иначе если любой принимающий в сообщении HELLO связан с Address Block TLV с Type = LINK_STATUS и Value = LOST, то
    1. если время L_SYM_time не истекло,
      1. L_SYM_time := EXPIRED;
      2. если L_status = HEARD,

- L_time := текущее время + L_HOLD_TIME.

1. L_neighbor_iface_addr_list := Sending Address List.
2. L_HEARD_time := max(текущее время + срок действия, L_SYM_time).
3. Если L_status = PENDING, то

- L_time := max(L_time, L_HEARD_time).

1. Иначе если L_status = HEARD или L_status = SYMMETRIC, то

- L_time := max(L_time, L_HEARD_time + L_HOLD_TIME).

12.6. Обновление 2-Hop Set

При получении HELLO маршрутизатор должен обновить свой 2-Hop Set для интерфейса MANET, принявшего HELLO.

Удалить все сетевые адреса в Removed Address List из N2_neighbor_iface_addr_list всех 2-Hop Tuple.
Если Link Tuple с L_neighbor_iface_addr_list = Sending Address List имеет L_status = SYMMETRIC, то
1. для каждого сетевого адреса (далее адрес 2-hop) из Address Block в сообщении HELLO, где

адрес 2-hop не содержится в Neighbor Address List;
адрес 2-hop не содержится в каком-либо I_local_iface_addr_list и
адрес 2-hop address не совпадает ни с одним IR_local_iface_addr

выполняются указанные ниже действия.

1. 1. Если адрес 2-hop имеет связанный Address Block TLV с

- Type = LINK_STATUS и Value = SYMMETRIC или
- Type = OTHER_NEIGHB и Value = SYMMETRIC,

то при отсутствии 2-Hop с

- N2_neighbor_iface_addr_list, содержащим один или несколько адресов из Sending Address List, и
- N2_2hop_addr = адрес 2-hop,

создается 2-Hop Tuple⁷ с

N2_2hop_addr := адрес 2-hop.

Затем этот 2-Hop Tuple (имеющийся или новый) изменяется, как показано ниже.

- N2_neighbor_iface_addr_list := Sending Address List;
- N2_time := текущее время + срок действия.

1. 1. Иначе при наличии у адреса 2-hop блока Address Block TLV с

- Type = LINK_STATUS и Value = LOST or Value = HEARD или
- Type = OTHER_NEIGHB и Value = LOST,

удаляются все 2-Hop Tuple с

- N2_neighbor_iface_addr_list, содержащим один или несколько адресов из Sending Address List, и
- N2_2hop_addr = адрес 2-hop.

13. Изменения других информационных баз

Базы Interface и Neighbor Information должны изменяться при некоторых событиях, которые могут быть результатом обработки HELLO или порождаться иными причинами (например, таймерами или изменением качества каналов).

Изменения Information Base вызывают перечисленные ниже события.

Смена L_status для Link Tuple на SYMMETRIC (выполняются действия параграфа 13.1).
Смена L_status для Link Tuple с SYMMETRIC на другое состояние или удаление Link Tuple (выполняются действия параграфа 13.2).
Истекло время L_HEARD_time для Link Tuple или Link Tuple удален (выполняются действия параграфа 13.3).
Смена сетевого адреса локального интерфейса (выполняются действия раздела 9).
Изменение качества канала (выполняются действия раздела 14).

Если Link Tuple удален или L_status изменился с SYMMETRIC на другое значение и время L_HEARD_time истекло, должны выполняться действия параграфа 13.2 до выполнения действий параграфа 13.3 для этого Link Tuple.

Маршрутизатор может сообщить обновленную информацию в ответ на любое из этих изменений в сообщениях HELLO с учетом ограничений, заданный в разделе 11.

Маршрутизатору, передающему сообщения HELLO при таких изменениях, следует отправлять сообщение HELLO:

во все интерфейсы MANET, если Neighbor Set меняется так, что указывает на изменение симметрии любого соседа 1-hop (включая добавление и удаление соседей с симметричными соединениями 1-hop);
в остальных случаях в те интерфейсы MANET, для которых Link Set меняется так, что указывает изменение в L_status любого из соседей 1-hop (включая добавление и удаление любых соседей 1-hop, кроме ожидающих).

13.1. Симметрия Link Tuple

Если для любого Link Tuple, не имеющего L_status = SYMMETRIC,

L_status меняется на SYMMETRIC,

выполняются следующие действия.

Для Neighbor Tuple с N_neighbor_addr_list, содержащим L_neighbor_iface_addr_list, устанавливается

- N_symmetric := true

Удаляются все Lost Neighbor Tuple с NL_neighbor_addr, содержащимися в этом N_neighbor_addr_list.

Это включает вновь созданные Link Tuple, чье состояние сразу изменилось на L_status = SYMMETRIC (в данной спецификации все Link Tuple создаются с L_status отличным от SYMMETRIC, но Link Tuple может незамедлительно обновиться последующей обработкой того же сообщения HELLO, вызывающей L_status = SYMMETRIC.)

13.2. Асимметрия Link Tuple

Если для любого Link Tuple с L_status = SYMMETRIC:

значение L_status изменилось или
Link Tuple удален,

выполняются следующие действия.

Все 2-Hop Tuple для того же интерфейса MANET с

- N2_neighbor_iface_addr_list с одним или несколькими сетевыми адресами из L_neighbor_iface_addr_list

удаляются.

Для Neighbor Tuple с N_neighbor_addr_list с L_neighbor_iface_addr_list выполняются указанные ниже действия.
1. Если не остается Link Tuple для какого либо интерфейса MANET с

- L_neighbor_iface_addr_list, содержащимся в N_neighbor_addr_list, и
- L_status = SYMMETRIC,

Neighbor Tuple изменяется, как показано ниже.

1. 1. N_symmetric := false.
  2. Для каждого адреса (далее адрес соседа) в N_neighbor_addr_list добавляется Lost Neighbor Tuple с

- NL_neighbor_addr := адрес соседа;
- NL_time := текущее время + N_HOLD_TIME.

13.3. Тайм-аут Link Tuple Heard

Если для любого Link Tuple

истекло время L_HEARD_time или
Link Tuple удален,

выполняются указанные ниже действия.

Для Neighbor Tuple, чей N_neighbor_addr_list содержит L_neighbor_iface_addr_list, если не остается Link Tuple для какого-либо интерфейса MANET, где

- L_neighbor_iface_addr_list содержится в N_neighbor_addr_list и
- время L_HEARD_time не истекло,

Neighbor Tuple удаляется.

14. Качество канала

Качество канала — это механизм, с помощью которого маршрутизатор может учитывать соображения, выходящие за пределы обмена сообщениями, для определения пригодности канала в качестве HEARD или SYMMETRIC. Т. е. это является механизмом «принятия каналов».

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

Для систем без применения параметров качества каналов применимы соображения, приведенные в параграфе 14.1. Для систем с использованием параметров качества каналов общие принципы описаны в параграфе 14.2. Работа с качеством каналов подробно описана в параграфах 14.3 и 14.4.

14.1. Системы без Link Quality

Маршрутизаторы, не применяющие параметры качества каналов, должны установить:

INITIAL_PENDING := false;
INITIAL_QUALITY >= HYST_REJECT (не причин не указать INITIAL_QUALITY := 1).

14.2. Базовые принципы Link Quality

Для применения параметров качества каналов используется значение L_quality в Link Tuple с двумя порогами -HYST_ACCEPT и HYST_REJECT установки флагов L_pending и L_lost в данном Link Tuple. На основе этих флагов состояние канала, анонсируемое для этого Link Tuple, определяется в соответствии с параграфом 7.1.

Наличие двух пороговых значений позволяет задать гистерезис, обеспечивающий HYST_REJECT <= L_quality < HYST_ACCEPT, когда канал принимается или отвергается в зависимости от недавнего порога, который недавно преодолело значение L_quality, или от параметра INITIAL_PENDING). При хорошо подобранных значениях параметров быстрая смена состояния канала будет исключаться.

Базовые принципы применения качества каналов приведены ниже.

Маршрутизатор не анонсирует интерфейс соседа в любом состоянии без приемлемого L_quality:
- если INITIAL_PENDING = true, канал анонсируется при условии L_quality >= HYST_ACCEPT;
- в остальных случаях канал анонсируется при L_quality >= HYST_REJECT.
Для канала, который еще не анонсирован, L_pending = true.

После выполнения L_quality >= HYST_ACCEPT, маршрутизатор устанавливает L_pending := false, указывая, что канал можно анонсировать.
Канал с L_pending = false анонсируется, пока L_quality не опустится ниже HYST_REJECT.
Если L_pending = false и L_quality < HYST_REJECT, канал теряется (LOST) с анонсированием этого. Такой канал не рекомендуется кандидатом в HEARD или SYMMETRIC, пока не будет L_quality >= HYST_ACCEPT.
Канал с приемлемым качеством может анонсироваться как HEARD, SYMMETRIC или LOST в соответствии с обменом сообщениями HELLO.

Для соблюдения этих принципов маршрутизатору недопустимо задавать:

INITIAL_PENDING = false и INITIAL_QUALITY < HYST_REJECT или
INITIAL_PENDING = true и INITIAL_QUALITY >= HYST_ACCEPT.

14.3. Действия при изменении качества канала

Если L_quality для канала меняется, должны выполняться указанные ниже действия.

Если L_quality >= HYST_ACCEPT, соответствующий Link Tuple меняется, как показано ниже.
1. L_pending := false.
2. L_lost := false.
3. Если L_status = HEARD или L_status = SYMMETRIC, то

- L_time := max(L_time, L_HEARD_time + L_HOLD_TIME).

Если L_status != PENDING и L_quality < HYST_REJECT, Link Tuple меняется, как показано ниже.
1. Если L_lost = false, то:

- L_lost := true;
- L_time := min(L_time, текущее время + L_HOLD_TIME).

В результате такое обработки L_STATUS в Link Tuple может измениться. В этом случае должны также выполняться соответствующие изменения действия, как указано в разделе 13.

Если L_quality для канала меняется в результате приема сообщения HELLO или пакета с таким сообщением, значение L_quality должно обновляться до обработки HELLO, описанной в разделе 12 (если прием HELLO или пакета с ним создает Link Tuple, для него должно задаваться обновленное значение L_quality, а не L_quality := INITIAL_QUALITY).

14.4. Обновление Link Quality

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

Сведения канального уровня, такие как отношение сигнал/шум, получение подтверждения или потеря пакета.
Прием или потеря пакета управления. Если такие пакеты включают порядковые номера, как указано в [RFC5444], качество канала можно обновлять при получении пакета управления, независимо от наличия в нем сообщения HELLO. Качество канала может основываться на том, приняты ли последние N из M пакетов управления в канале, или на «индикаторе утечки», отслеживающем прием и потери.
Прием или потеря сообщений HELLO. Если известен максимальный интервал между HELLO (например, в сообщения HELLO включен блок Message TLV с Type := INTERVAL_TIME, как указано в [RFC5497]), потерю HELLO можно увидеть без ожидания следующего сообщения HELLO. Отметим, что при сочетании этого варианта с предыдущим нужно позаботиться о том, чтобы потеря HELLO не учитывалась дважды.

15. Предлагаемые значения параметров и констант

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

15.1. Интервал между сообщениями для интерфейса

     HELLO_INTERVAL := 2 секунды
     HELLO_MIN_INTERVAL := HELLO_INTERVAL/4
     REFRESH_INTERVAL := HELLO_INTERVAL

15.2. Сроки действия информации для интерфейса

     H_HOLD_TIME := 3 x REFRESH_INTERVAL
     L_HOLD_TIME := H_HOLD_TIME

15.3. Сроки действия информации для маршрутизатора

     N_HOLD_TIME := L_HOLD_TIME
     I_HOLD_TIME := N_HOLD_TIME

15.4. Параметры качества канала для интерфейса

Если качество канала изменилось, значения параметров будут зависеть от обработки качества. Если качество не изменилось

     HYST_ACCEPT := 1
     HYST_REJECT := 0
     INITIAL_QUALITY := 1
     INITIAL_PENDING := false

15.5. Параметры вариаций задержки для интерфейса

     HP_MAXJITTER := HELLO_INTERVAL/4
     HT_MAXJITTER := HP_MAXJITTER

15.6. Константа

     C := 1/1024 сек.

16. Применение с другими протоколами

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

Путем доступа (возможно расширения) к информации в Local Information Base (раздел 6), Interface Information Base (раздел 7) и Neighbor Information Base (раздел 8). Эти информационные базы содержат конфигурацию интерфейсов маршрутизатора, а также данные о локальных соединениях на расстоянии до 2 интервалов. Для всех обновлений элементов, заданных в этом документе, действуют ограничения, указанные в приложении B.
Путем доступа к исходящему сообщению HELLO до его передачи через интерфейс MANET и добавления информации (например, TLV) в сообщение, как указано в [RFC5444]. Это позволяет, например, протоколам защиты, как указано в разделе 17, добавлять TLV с криптографической подписью сообщения или добавлять данные для выбора ретрансляторов в сообщение HELLO путем включения TLV в исходящее сообщение HELLO до его передачи.
Путем доступа к входящим сообщениям HELLO с возможностью их отбрасывания до обработки данным протоколом. Это может быть полезно, например, протоколу защиты выполнять, как предложено в разделе 17, проверку подписи в HELLO и отклонение обработки данным протоколом непроверяемых сообщений HELLO.
Путем доступа к входящим сообщениям HELLO после их полной обработки данным протоколом. Это может, в частности, позволить протоколу, добавившему такую информацию, как данные выбора ретранслятора, включения подходящих TLV, доступ к ней после записи соответствующих обновления в информационные базы этого протокола.
Путем запроса генерации сообщений HELLO в определенное время. В этом случае генерация HELLO должна происходить в соответствии с ограничениями приложения B.

Адресные объекты в сообщениях HELLO обрабатываются в соответствии со связанными с ними Address Block TLV. Все такие объекты обрабатываются в соответствии с данной спецификацией и связаны с Address Block TLV типа LOCAL_IF, OTHER_NEIGHB или LINK_STATUS (с расширением типа 0). Адресные объекты, не связанные с Address Block TLV какого-либо из указанных типов не обрабатываются описанным в спецификации протоколом.

Протоколам (таким, как протокол маршрутизации MANET), взаимодействующим с данным протоколом, может потребоваться добавить информацию в сообщения HELLO. Это может иметь форму связывания TLV (типов, отличных от LOCAL_IF, OTHER_NEIGHB, LINK_STATUS) с адресными объектами, включенными в данную спецификацию.

Такие протоколы могут также добавлять информацию в сообщения HELLO путем вставки адресных объектов, которые еще не включены в эту спецификацию. Такие адресные объекты далее называются «вставленными адресами». Эти адреса могут добавляться к имеющимся Address Block, которые созданы при генерации сообщения HELLO, или указываться в новых Address Blocks. В обоих случаях должны выполняться приведенные ниже условия.

Вставленные адреса недопустимо связывать с Address Block TLV типов LOCAL_IF, OTHER_NEIGHB или LINK_STATUS. Поэтому обработка по данной спецификации будет игнорировать такие адресные объекты.
Каждый вставленный адрес должен быть связан с Address Block TLV, определенным спецификацией добавляющего адресный объект протокола. Таким образом, все адреса в сообщении HELLO будут связаны с Address Block TLV, определяющими их семантику.

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

Адресный объект в Address Block, не связанный с Address Block TLV, должен игнорироваться, а обработка таких блоков недопустима.

Протокол, взаимодействующий с этим протоколом, может также добавлять адрес инициатора в сообщения HELLO, как указано в [RFC5444]. Такой адрес должен быть уникальным для маршрутизатора-источника и может быть адресом локального интерфейса маршрутизатора. Его следует использовать согласованно и не следует как-то ограничивать.

Строгое соблюдение этих пунктов обеспечит однозначное сосуществование с будущими расширениями сообщений HELLO.

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

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

Цель этого протокола заключается в том, чтобы каждый маршрутизатор сети мог получить информацию, описывающую соседей в одном интервале и соседей с симметричными соединениями в 2 интервалах. Это обеспечивается обменом сообщениями HELLO между соседними маршрутизаторами. Информация доступна через базы Interface Information Base и Neighbor Information Base, описывающие соседей в одном и двух интервалах.

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

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

Поэтому в данном разделе сначала описаны корректно сформированные, но все же недействительные сообщения HELLO (параграф 17.1).

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

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

Поэтому в параграфе 17.2 не приводится «один механизм для всех», а рассматривается, как предложения [RFC5444] по защите могут применяться в контексте этого протокола и какие механизмы защиты следует разработать для конкретного развертывания.

17.1. Недействительные сообщения HELLO

Корректно сформированные, но непригодные сообщения HELLO могут иметь любую из приведенных ниже форм. Отметим, что наличие или отсутствие адресного объекта в Address Block само по себе не создает проблем. Проблемы могут быть вызваны наличие, отсутствием или некорректностью связанных Address Block TLV типа LOCAL_IF, LINK_STATUS, OTHER_NEIGHB.

Маршрутизатор может представить ложную самоидентификацию.

Сообщение HELLO может содержать адресный объект со связанным LOCAL_IF Address Block TLV, не соответствующий адресам маршрутизатора, передавшего сообщение HELLO.
Сообщение HELLO может не содержать сетевых адресов или связанных с ними LOCAL_IF Address Block TLV для интерфейсов маршрутизатора, передавшего сообщение HELLO (кроме разрешенного пропуска сетевого адреса единственного интерфейса MANET, через который было передано сообщение HELLO).
Сообщение HELLO может некорректно задавать значение LOCAL_IF Address Block TLV, связанное с одним или несколькими адресами локальных сетевых интерфейсов, неверно указывающее связь с интерфейсом MANET, через который передано сообщение HELLO.

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

Имеющийся LINK_STATUS Address Block TLV может некорректно указать сетевой адрес как адрес интерфейса MANET, который слышен или был слышен на интерфейсе MANET, передавшем HELLO.
Отсутствующий LINK_STATUS Address Block TLV может некорректно указать сетевой адрес как относящийся к интерфейсу MANET, который слышен или был слышен на интерфейсе MANET, передавшем HELLO.
Имеющийся OTHER_NEIGHB Address Block TLV может некорректно указать сетевой адрес как относящийся к маршрутизатору который является или был симметричным соседом 1-hop для передающего маршрутизатора.
Отсутствующий OTHER_NEIGHB Address Block TLV может некорректно указать сетевой адрес как относящийся к маршрутизатору который является или был симметричным соседом 1-hop для передающего маршрутизатора.
Value в LINK_STATUS Address Block TLV может некорректно указывать статус (LOST, SYMMETRIC, HEARD) канала от соседа 1-hop.
Value в OTHER_NEIGHB Address Block TLV может некорректно указывать статус (LOST или SYMMETRIC) симметричного соседа 1-hop.

17.2. Предложения по аутентификации, целостности, конфиденциальности

Предложения [RFC5444] по защите, касающиеся включения криптографической подписи в Message TLV или Packet TLV, применимы к этому протоколу. Отказ при проверке любой формы криптографической подписи следует считать ошибкой, а сообщение HELLO следует отбрасывать без обработки.

Ниже описано упрощение предложений по сквозной аутентификации для защиты целостности [RFC5444] применительно к сообщениям HELLO.

Поскольку поля заголовка сообщения (Message Header) <msg-hop-count> и <msg-hop-limit> пропускаются или всегда имеют значения 0 и 1 (соответственно), сквозная криптографическая подпись может быть рассчитана для всего сообщения HELLO, включая неизменный заголовок сообщения (Message Header).

Механизмы защиты конфиденциальности, предложенные в [RFC5444], напрямую применимы к этому протоколу.

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

Эта спецификация определяет одно значение Message Type, выделенное из реестра Message Types [RFC5444], и три типа Address Block TLV из реестра Address Block TLV Types [RFC5444].

18.1. Expert Review — рекомендации по оценке

Для реестров с политикой Expert Review назначенному эксперту следует придерживаться общих рекомендаций, приведенных в [RFC5444].

18.2. Типы сообщений

Эта спецификация определяет одно значение Message Type, выделенное из диапазона 0-223 в пространстве имен Message Types, определенном в [RFC5444], как показано в таблице 3.

Таблица 3. Выделенное значение для типа сообщений.

Тип	Описание
LOCAL_IF	HELLO — локальная сигнализация.

18.3. Реестры Message-Type-Specific TLV Type

Агентство IANA создало реестр Message-Type-specific Message TLV для сообщений HELLO в соответствии с параграфом 6.2.1 [RFC5444], начальные значения и политика распределения в котором приведены в таблице 4.

Таблица 4. Типы TLV.

Тип	Описание	Процедура
128-223	Не распределены.	Expert Review

Агентство IANA создало реестр Message-Type-specific Address Block TLV для сообщений HELLO в соответствии с параграфом 6.2.1 [RFC5444], начальные значения и политика распределения в котором приведены в таблице 5.

Таблица 5. Типы Address Block TLV.

Тип	Описание	Процедура
128-223	Не распределены.	Expert Review

18.4. Типы Address Block TLV

Эта спецификация определяет 3 типа Address Block TLV, которые выделены из пространства имен Address Block TLV Types, определенного в [RFC5444]. Для этих типов выделены значения из диапазона 0-127. Созданы три новых реестра расширений типов, начальные значения которых приведены в таблицах 6 — 8. Спецификации этих Address Block TLV даны в параграфе 10.1.1, а константы определены в параграфе 18.5.

Таблица 6. Распределение типов Address Block TLV — LOCAL_IF.

Имя	Тип	Расширение	Описание	Процедура
LOCAL_IF	2	0	Указывает, что сетевые адреса связаны с этим (THIS_IF=0) или иным (OTHER_IF=1) локальным интерфейсом передающего маршрутизатора.
LOCAL_IF	2	1-255	Не распределены.	Expert Review

Таблица 7. Распределение типов Address Block TLV — LINK_STATUS.

Имя	Тип	Расширение	Описание	Процедура
LINK_STATUS	3	0	Указывает статус канал от обозначенного сетевого адреса (LOST=0, SYMMETRIC=1 или HEARD=2).
LINK_STATUS	3	1-255	Не распределены	Expert Review

Таблица 8. Распределение типов Address Block TLV — OTHER_NEIGHB.

Имя	Тип	Расширение	Описание	Процедура
OTHER_NEIGHB	4	0	Указывает статус взаимоотношений с маршрутизатором, который использует сетевой адрес одного или нескольких интерфейсов (LOST=0 или SYMMETRIC=1)
OTHER_NEIGHB	4	1-255	Не распределены.	Expert Review

18.5. Значения LOCAL_IF, LINK_STATUS, OTHER_NEIGHB

Эта информация приведена здесь для четкости и использования в других местах спецификации. Сведения, нужные IANA, включены в описание Address Block TLV (параграф 18.4).

Ниже приведены Value для LOCAL_IF в Address Block TLV.

   THIS_IF := 0
   OTHER_IF := 1

Ниже приведены Value для LINK_STATUS в Address Block TLV.

   LOST := 0
   SYMMETRIC := 1
   HEARD := 2

Ниже приведены Value для OTHER_NEIGHB в Address Block TLV.

   LOST := 0
   SYMMETRIC := 1

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

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

Brian Adamson, NRL, USA, <adamson@itd.nrl.navy.mil>;
Cedric Adjih, INRIA, France, <Cedric.Adjih@inria.fr>;
Thomas Heide Clausen, LIX, France, <T.Clausen@computer.org>;
Justin Dean, NRL, USA, <jdean@itd.nrl.navy.mil>;
Christopher Dearlove, BAE Systems ATC, UK, <chris.dearlove@baesystems.com>;
Philippe Jacquet, INRIA, France, <Philippe.Jacquet@inria.fr>.

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

Авторы хотели бы поблагодарить участников команды OLSRv1, указанных в RFC3626, за их вклад.

Авторы признательны за технические обсуждения, ранние рецензии и комментарии к спецификации и ее компонентам Alan Cullen (BAE Systems), Ulrich Herberg (LIX), Satoh Hiroki (Hitachi) Joe Macker (NRL), Charles E. Perkins (WiChorus), Laurent Viennot (INRIA) (указаны по алфавиту) и всей рабочей группе IETF MANET.

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

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

[RFC2119] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, March 1997.

[RFC5148] Clausen, T., Dearlove, C., and B. Adamson, «Jitter Considerations in Mobile Ad Hoc Networks (MANETs)», RFC 5148, February 2008.

[RFC5444] Clausen, T., Dearlove, C., Dean, J., and C. Adjih, «Generalized Mobile Ad Hoc Network (MANET) Packet/Message Format», RFC 5444, February 2009.

[RFC5497] Clausen, T. and C. Dearlove, «Representing Multi-Value Time in Mobile Ad Hoc Networks (MANETs)», RFC 5497, March 2009.

[RFC5498] Chakeres, I., «IANA Allocations for Mobile Ad Hoc Network (MANET) Protocols», RFC 5498, March 2009.

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

[RFC2501] Corson, M. and J. Macker, «Mobile Ad hoc Networking (MANET): Routing Protocol Performance Issues and Evaluation Considerations», RFC 2501, January 1999.

[RFC3626] Clausen, T. and P. Jacquet, «Optimized Link State Routing Protocol (OLSR)», RFC 3626, October 2003.

[RFC5449] Baccelli, E., Jacquet, P., Nguyen, D., and T. Clausen, «OSPF Multipoint Relay (MPR) Extension for Ad Hoc Networks», RFC 5449, February 2009.

Приложение A. Комбинации Address Block TLV

Алгоритм генерации сообщений HELLO (раздел 11) указывает, какие из адресов соседей 1-hop могут быть включены в Address Block и с какими связанными Address Block TLV. Эти Address Block TLV могут иметь тип LINK_STATUS, OTHER_NEIGHB или оба. Address Block TLV типа LINK_STATUS могут иметь 3 возможных значения (HEARD, SYMMETRIC, LOST), а Address Block TLV типа OTHER_NEIGHB — 2 (SYMMETRIC или LOST). При связывании обоих Address Block TLV с одним сетевым адресом необходимы лишь некоторые комбинации значений этих Address Block TLV и только они генерируются алгоритмом из раздела 11. Эти комбинации приведены в таблице 9.

Значение «да» указывает возможные комбинации, генерируемые алгоритмом из раздела 11, «нет» указывают комбинации, которые не генерируются этим алгоритмом, но могут быть корректно проанализированы и интерпретированы алгоритмом из раздела 12. Ячейка «нет*» на деле противоречива — она обрабатывается с игнорированием Address Block TLV типа OTHER_NEIGHB, но применять это не следует.

Таблица 9. Комбинации LINK_STATUS и OTHER_NEIGHB TLV.

	Type = OTHER_NEIGHB, (отсутств.)	Type = OTHER_NEIGHB, Value = SYMMETRIC	Type = OTHER_NEIGHB, Value = LOST
Type = LINK_STATUS, (отсутств.)	нет	да	да
Type = LINK_STATUS, Value = HEARD	да	да	да
Type = LINK_STATUS, Value = SYMMETRIC	да	нет	нет*
Type = LINK_STATUS, Value = LOST	да	да	нет

Приложение B. Ограничения

Любой процесс, обновляющий Local Information Base или Neighbor Information Base должен обеспечивать соблюдение всех приведенных в этом приложении ограничений.

В каждом Local Interface Tuple:

I_local_iface_addr_list недопустимо быть пустым;
I_local_iface_addr_list недопустимо содержать дубликаты сетевых адресов;
если I_manet = true, в I_local_iface_addr_list недопустимо включать сетевые адреса, перекрывающиеся с любым адресом в I_local_iface_addr_list любого другого Local Interface Tuple с I_manet = true, пока не известно, что соответствующие интерфейсы MANET всегда будут взаимодействовать с отдельными наборами интерфейсов MANET на других маршрутизаторах.

В каждом Removed Interface Address Tuple:

IR_local_iface_addr недопустимо содержать сетевой адрес, имеющийся в I_local_iface_addr_list любого Local Interface Tuple;
IR_local_iface_addr недопустимо совпадать с IR_local_iface_addr любого другого Removed Interface Address Tuple.

В каждом Link Tuple:

L_neighbor_iface_addr_list недопустимо быть пустым;
L_neighbor_iface_addr_list недопустимо содержать сетевой адрес, перекрывающийся с любым адресом в I_local_iface_addr_list любого Local Interface Tuple или IR_local_iface_addr любого Removed Interface Address Tuple;
L_neighbor_iface_addr_list недопустимо содержать дубликаты сетевых адресов;
L_neighbor_iface_addr_list недопустимо содержать сетевой адрес, имеющийся в L_neighbor_iface_addr_list любого другого Link Tuple в том же Link Set;
Если время L_HEARD_time не истекло, должен быть Neighbor Tuple с N_neighbor_addr_list, содержащим L_neighbor_iface_addr_list;
недопустимо L_HEARD_time > L_time, если не выполняется условие L_lost = true⁸;
L_SYM_time недопустимо быть больше L_HEARD_time (пока оба не истекли);
L_quality недопустимо быть меньше 0 или больше 1;
если L_quality >= HYST_ACCEPT, должно быть L_pending = false;
если L_quality < HYST_REJECT, L_status должен быть PENDING или LOST;
для L_pending недопустимо устанавливать значение true при текущем значении false.

В каждом Neighbor Tuple:

N_neighbor_addr_list недопустимо содержать сетевой адрес, перекрывающийся с любым адресом в I_local_iface_addr_list любого Local Interface Tuple или IR_local_iface_addr любого Removed Interface Address Tuple;
N_neighbor_addr_list недопустимо содержать дубликаты сетевых адресов;
N_neighbor_addr_list недопустимо содержать сетевой адрес, имеющийся в N_neighbor_addr_list любого другого Neighbor Tuple;
если N_symmetric is = true, должен быть один или несколько Link Tuples с
- L_neighbor_iface_addr_list из N_neighbor_addr_list и
- L_status = SYMMETRIC;
если N_symmetric is = false, должен быть один или несколько Link Tuples с
- L_neighbor_iface_addr_list из N_neighbor_addr_list.

Всем таким Link Tuple недопустимо иметь L_status = SYMMETRIC. Хотя бы один такой Link Tuple должен иметь не истекшее время L_HEARD_time.

В каждом Lost Neighbor Tuple:

NL_neighbor_addr недопустимо перекрываться с любым сетевым адресом в I_local_iface_addr_list любого Local Interface Tuple или IR_local_iface_addr любого Removed Interface Address Tuple;
NL_neighbor_addr недопустимо совпадать с NL_neighbor_addr любого другого Lost Neighbor Tuple;
NL_neighbor_addr недопустимо быть в N_neighbor_addr_list любого Neighbor Tuple с N_symmetric = true.

В каждом 2-Hop Tuple:

должен быть Link Tuple с тем же интерфейсом MANET с
- L_neighbor_iface_addr_list = N2_neighbor_iface_addr_list и
- L_status = SYMMETRIC;
N2_2hop_addr недопустимо перекрываться с любым сетевым адресом в I_local_iface_addr_list любого Local Interface Tuple или IR_local_iface_addr любого Removed Interface Address Tuple;
N2_2hop_addr недопустимо быть N2_2hop_addr любого другого 2-Hop Tuple в том же 2-Hop Set и с таким же N2_neighbor_iface_addr_list;
N2_2hop_addr недопустимо быть в N2_neighbor_iface_addr_list того же 2-Hop Tuple.

Приложение C. Пример сообщения HELLO

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

4-битовое поле флагов HELLO (MF — Message Flags) имеет значение 7, указывающее, что заголовок содержит поля ограничения числа интервалов, счетчика интервалов и порядкового номера сообщения. 4-битовое поле размера адреса (MAL — Message Address Length) имеет значение 3, указывающее, что адреса в сообщении имеют размер 4 октета (IPv4). Сообщение передано с hop limit = 1 и hop count = 0. Общий размер сообщения составляет 45 октетов.

Сообщение содержит Message TLV Block с 8 октетами, включающими 2 Message TLV типов VALIDITY_TIME и INTERVAL_TIME. Каждый применяет Message TLV с октетом флагов (MTLVF) 16, указывающим наличие в каждом поля Value размером (Value Length) в 1 октет. Поля Value содержат коды времени (в соответствии с [RFC5497]) представляющие параметры H_HOLD_TIME и HELLO_INTERVAL, соответственно.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     HELLO     | MF=7  | MAL=3 |      Message Length = 45      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop Limit = 1 | Hop Count = 0 |    Message Sequence Number    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message TLV Block Length = 8  | VALIDITY_TIME |  MTLVF = 16   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value Len = 1 | Value (Time)  | INTERVAL_TIME |  MTLVF = 16   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value Len = 1 | Value (Time)  | Num Addrs = 5 |   ABF = 128   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Head Len = 3  |                     Head                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Mid 0     |     Mid 1     |     Mid 2     |     Mid 3     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Mid 4     | Address TLV Block Length = 14 |   LOCAL_IF    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  ATLVF = 80   |   Index = 0   | Value Len = 1 |    THIS_IF    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  LINK_STATUS  |   ATLV = 52   | Strt Indx = 1 | Stop Indx = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value Len = 4 |     HEARD     |     HEARD     |   SYMMETRIC   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     LOST      |
+-+-+-+-+-+-+-+-+

Сообщение имеет один Address Block с 5 адресами. Октет флагов Address Block (ABF) имеет значение 128, указывающее наличие Head, но отсутствие Tail и префикса. Размер Head (3 октета) указывает разделы Mid для адресов в один октет каждый (Mid 0 — Mid 4).

Следующий блок Address Block TLV (14 октетов) включает 2 Address Block TLV. Первый является LOCAL_IF Address Block TLV с октетом флагов (ATLVF) 80, который указывает, что 1 адрес с индексом 0 (т. е. Head:Mid 0) является адресом одного локального интерфейса маршрутизатора (1 октет Value THIS_IF показывает что это адрес данного интерфейса). Второй является LINK_STATUS Address Block TLV с октетом флагов (ATLVF) 52 и задает значения статуса каналов всех сообщенных соседей в одном Address Block TLV со множеством значений, покрывающем адреса с индексами 1 — 4, включительно. Размер значения Address Block TLV в 4 октета указывает 1 октет на Value для адреса. Последние 4 адреса являются, таким образом, соседями, каждый из которых имеет статус канала — первый и второй — HEARD, третий — SYMMETRIC, четвертый — LOST.

Отметим, что пример служит лишь для иллюстрации. Важная информация может передаваться более эффективно (при условии, что адрес локального интерфейса будут представлен IP, а INTERVAL_TIME TLV не требуется) и займет 29 октетов, как показано ниже.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     HELLO     |0 0 0 0 0 0 1 1|0 0 0 0 0 0 0 0 0 0 0 1 1 1 0 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0| VALIDITY_TIME |0 0 0 1 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 1|0 1 1 0 0 1 0 0|0 0 0 0 0 1 0 0|1 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 1 1|                     Head                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Mid 1     |     Mid 2     |     Mid 3     |     Mid 4     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1|  LINK_STATUS  |0 0 0 1 0 1 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 1 0 0|     HEARD     |     HEARD     |   SYMMETRIC   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     LOST      |
+-+-+-+-+-+-+-+-+

Отметим, что в этом примере H_HOLD_TIME и C имеют принятые по умолчанию значения (6 секунд и 1/1024 сек.), что приводит к коду времени 100 (64 в шестнадцатеричной форме).

Приложение D. Контроль потоков и перегрузок

Этот протокол задает 1 тип сообщений — HELLO. Максимальный размер HELLO пропорционален размеру окрестности 1-hop передающего маршрутизатора. Пересылка сообщений HELLO недопустима.

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

Маршрутизатор должен гарантировать, что два последовательных сообщения HELLO с одного интерфейса MANET разделены интервалом не меньше HELLO_MIN_INTERVAL (при учете вариаций значение может быть уменьшено до среднего минимального значения HELLO_MIN_INTERVAL — HP_MAXJITTER/2). Это устанавливает верхнюю границу для трафика управления, создаваемого каждым маршрутизатором в сети, использующей этот протокол.

Приложение E. Интервалы и таймеры

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

E.1. Тактирование генерации сообщений HELLO

На рисунке 1 показано базовое планирование сообщений HELLO для маршрутизатора на интерфейсе MANET, реализующем строго периодическую отправку сообщений HELLO. Маршрутизатор передает HELLO каждый интервал HELLO_INTERVAL. Каждое сообщение HELLO содержит адреса соседей 1-hop, которые указываются в каждом таком HELLO (параметр REFRESH_INTERVAL, не показанный в примере, совпадает с HELLO_INTERVAL).

H_HOLD_TIME:         |-----------------------------|   ...
HELLO_INTERVAL:      |---------|---------|---------|   ...
Время             ---*---------*---------*---------*------>
                     ^         ^         ^         ^
                     |         |         |         |
    HELLO (a, b, c, d)         |         |         |
                               |         |         |
              HELLO (a, b, c, d)         |         |   ...
                                         |         |
                        HELLO (a, b, c, d)         |
                                                   |
                                  HELLO (a, b, c, d)

L_time:              |-----------------------------|
                               |--------------------   ...
                                         |----------   ...
                                                   |   ...

Рисунок 1. Генерация регулярного сообщения HELLO.

Маршрутизатор включает VALIDITY_TIME TLV в каждое сообщение HELLO, представляя параметр H_HOLD_TIME, указывающий в течение какого времени информацию из HELLO принявшему маршрутизатору следует считать действительной. Принимающие маршрутизаторы при записи информации из сообщения HELLO будут применять это значение для установки элементов L_HEARD_time, L_SYM_time и L_time в соответствующих Link Tuple и N2_time в соответствующем 2-Hop Tuple для каждого сетевого адреса. На рисунке 1 указано только L_time.

На рисунке 2 представлено планирование сообщений, похожее на рисунок 1, где маршрутизатор анонсирует свое присутствие передачей дополнительных сообщений HELLO. Сообщения HELLO передаются регулярно с уменьшенным интервалом, определяемым HELLO_INTERVAL. Однако значение REFRESH_INTERVAL не уменьшается. Адрес каждого соседа 1-hop, включенный в HELLO, требуется анонсировать лишь 1 раз за каждый интервал REFRESH_INTERVAL. Поэтому дополнительные сообщения HELLO могут быть пустыми в результате снижения HELLO_INTERVAL (это не единственный разрешенный способ распространения сетевых адресов соседей 1-hop, они могут, например, отправляться поочередно — a, b и c, d).

H_HOLD_TIME:         |-----------------------------|   ...
REFRESH_INTERVAL:    |---------|---------|---------|   ...
HELLO_INTERVAL:      |----|----|----|----|----|----|   ...
Время             ---*---------*---------*---------*------>
                     ^    ^    ^    ^    ^    ^    ^
                     |    |    |    |    |    |    |
    HELLO (a, b, c, d)    |    |    |    |    |    |
                          |    |    |    |    |    |
                   HELLO ()    |    |    |    |    |
                               |    |    |    |    |
              HELLO (a, b, c, d)    |    |    |    |
                                    |    |    |    |   ...
                             HELLO ()    |    |    |
                                         |    |    |
                        HELLO (a, b, c, d)    |    |
                                              |    |
                                       HELLO ()    |
                                                   |
                                  HELLO (a, b, c, d)

L_time:              |-----------------------------|
                          |-------------------------   ...
                               |--------------------   ...
                                    |---------------   ...
                                         |----------   ...
                                              |-----   ...
                                                   |   ...

Рисунок 2. Генерация регулярного сообщения HELLO при разных HELLO_INTERVAL и REFRESH_INTERVAL.

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

H_HOLD_TIME:         |-----------------------------|   ...
HELLO_INTERVAL:      |---------|---------|---------|   ...
HELLO_MIN_INTERVAL:  |----|----|----|----|----|----|   ...
Время             ---*---------*---------*---------*------>
                     ^    ^    ^    ^    ^    ^    ^
                     |    |    |    |    |    |    |
              HELLO ()    |    |    |    |    |    |
                          |    |    |    |    |    |
                  HELLO (a)    |    |    |    |    |
                               |    |    |    |    |
                    HELLO (a, b)    |    |    |    |
                                    |    |    |    |   ...
                      HELLO (a, b, c)    |    |    |
                                         |    |    |
                        HELLO (a, b, c, d)    |    |
                                              |    |
                          HELLO (a, b, c, d, e)    |
                                                   |
                            HELLO (a, b, c, d, e, f)

L_time:              |-----------------------------|
                          |-------------------------   ...
                               |--------------------   ...
                                    |---------------   ...
                                         |----------   ...
                                              |-----   ...
                                                   |   ...

Рисунок 3. Генерация сообщений HELLO — регулярная и по событиям.

На рисунке 3 показано планирование сообщений, похожее на рисунок 1, но с отправкой HELLO по событиям с максимальной скоростью — 1 сообщение HELLO за каждый интервал HELLO_MIN_INTERVAL. Отметим, что при передаче HELLO предполагается, что следующие сообщения будут планироваться с интервалом HELLO_INTERVAL, поэтому каждое сообщение HELLO содержит все сетевые адреса соседей 1-hop. В каждом сообщении HELLO этого примера добавляется новый адрес соседа 1-hop в соответствии с изменениями, произошедшими после отправки последнего сообщения HELLO. Сообщения HELLO передаются с максимальной разрешенной скоростью для обеспечения быстрой сигнализации об изменениях.

На рисунке 4 показан случай похожий на рисунок 3, но в увеличенным REFRESH_INTERVAL и показом частичных сообщений HELLO, включающих лишь необходимые сетевые адреса.

H_HOLD_TIME:         |-----------------------------|   ...
REFRESH_INTERVAL:    |-------------------|----------   ...
                          |-------------------|-----   ...
                               |-------------------|   ...
                                    |---------------   ...
                                         |----------   ...
                                              |-----   ...
                                                   |   ...
HELLO_INTERVAL:      |---------|---------|---------|   ...
HELLO_MIN_INTERVAL:  |----|----|----|----|----|----|   ...
Время             ---*---------*---------*---------*------>
                     ^    ^    ^    ^    ^    ^    ^
                     |    |    |    |    |    |    |
              HELLO ()    |    |    |    |    |    |
                          |    |    |    |    |    |
                  HELLO (a)    |    |    |    |    |
                               |    |    |    |    |
                       HELLO (b)    |    |    |    |
                                    |    |    |    |   ...
                            HELLO (c)    |    |    |
                                         |    |    |
                              HELLO (a, d)    |    |
                                              |    |
                                   HELLO (b, e)    |
                                                   |
                                        HELLO (c, f)

L_time:              |-----------------------------|
                          |-------------------------   ...
                               |--------------------   ...
                                    |---------------   ...
                                         |----------   ...
                                              |-----   ...
                                                   |   ...

Рисунок 4. Генерация сообщений HELLO — регулярно и по событиям при разных HELLO_INTERVAL и REFRESH_INTERVAL.

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

H_HOLD_TIME:         |------------------------------------|
REFRESH_INTERVAL:    |----------------|
HELLO_INTERVAL:      |----------|
HELLO_MIN_INTERVAL:  |---|
Время             ----------------------------------------------->
                     ^   ^      ^     ^                   ^
                     |   |      |     |                   |
                     |   |      |     |           Время, до которого
             Передача    |      |     |           действительно 
      сообщения HELLO    |      |     |           содержимое принятого
                         |      |     |           сообщения HELLO.
                         |      |     |
                         |      |     Время, до которого вся
                         |      |     информация о соседях должна
                         |      |     быть передана в сообщениях 
                         |      |     HELLO (одном или нескольких).
                         |      |
                         |      Самое позднее время отправки
                         |      следующего сообщения HELLO.
                         |
                         Самое раннее время отправки
                         следующего сообщения HELLO.

Рисунок 5. Интервалы генерации сообщений HELLO.

E.2. Тактирование обработки сообщения HELLO

На рисунке 6 показаны таймеры Link при получении HELLO без сетевого адреса принявшего интерфейса MANET.

VALIDITY_TIME:    |--------------------------|
L_time:           |--------------------------|
L_HEARD_time:     |--------------------------|
L_SYM_time:     *-| (i.e.,  expired)
Время          ---*-------------------------------->
                  ^
                  |
   Принято HELLO ()

Рисунок 6. Обработка сообщения HELLO при отсутствии сетевых адресов.

На рисунке 7 показаны таймеры Link Set, когда вслед за сообщением HELLO, показанным на рисунке 6, маршрутизатор принимает HELLO с адресом (a) принимающего интерфейса с состоянием канала HEARD (или SYMMETRIC).

VALIDITY_TIME:    |--------------------------|
                        |--------------------------|
L_time:           |--------------------------|
                        |--------------------------|
L_HEARD_time:     |--------------------------|
                        |--------------------------|
L_SYM_time:     *-| (т. е. время истекло)
L_SYM_time:             |--------------------------|
Время            -*-----*--------------------------------->
                  ^     ^
                  |     |
   Принято HELLO ()     |
                        |
 Принято HELLO (a:HEARD)

Рисунок 7. Обработка сообщения HELLO при наличии сетевых адресов.

На рисунке 8 показаны таймеры Link Set, когда вслед за сообщением HELLO, показанным на рисунке 7, маршрутизатор получает HELLO с сетевым адресом (a) принимающего интерфейса со статусом канала LOST.

VALIDITY_TIME:    |--------------------------|
                        |--------------------------|
                              |--------------------------|
L_time:           |--------------------------|
                        |--------------------------|
                              |--------------------------|
L_HEARD_time:     |--------------------------|
                        |--------------------------|
                              |--------------------------|
L_SYM_time:     *-| (т. е. время истекло)
                        |--------------------------|
                            *-| (т. е. время истекло)
Время            -*-----*-----*--------------------------------->
                  ^     ^     ^
                  |     |     |
   Принято HELLO ()     |     |
                        |     |
  Принято HELLO (a:HEARD)     |
                              |
         Принято HELLO (a:LOST)

Рисунок 8. Обработка сообщения HELLO при потере сетевого адреса.

E.3. Тактирование других сообщений HELLO

Есть 3 других параметра синхронизации, которые маршрутизатор применяет для контроля генерации и обработки сообщений HELLO.

На рисунке 9 показан интервал L_HOLD_TIME, в течение которого адреса, которые были (но перестали) адресами симметричных соседей 1-hop, подключенных к этому интерфейсу MANET, анонсируются как потерянные (LOST) с использованием LINK_STATUS TLV в сообщениях HELLO на этом интерфейсе MANET, позволяя соседу 1-hop обновить подобающим образом свой Link Set.

L_HOLD_TIME:   |----------------------------|
Время       ---*---------------------------------->
               ^                            ^
               |                            |
    Ранее симметричный сосед 1-hop          |
    перестал быть симметричным на           |
    этом интерфейсе MANET                   |
                                            |
                 Время, до которого сетевые адреса этого
                 соседа, подключенного через данный
                 интерфейс MANET, анонсируеются в
                 сообщениях HELLO этого интерфейса MANET 
                 с LINK_STATUS TLV, Value = LOST

Рисунок 9. Создание сообщения HELLO при потере ближайшего соседа с симметричным подключением на интерфейсе MANET.

На рисунке 10 показан интервал N_HOLD_TIME, в течение которого все сетевые адреса, которые были (но перестали) быть адресами симметричного соседа 1-hop, анонсируются как LOST в сообщениях HELLO на всех интерфейса MANET с использованием OTHER_NEIGHB TLV (если не указываются также с использованием LINK_STATUS TLV), что позволяет другим симметричным соседям 1-hop обновить должным образом свои 2-Hop Set.

L_HOLD_TIME:   |----------------------------|
Время       ---*---------------------------------->
               ^                            ^
               |                            |
    Ранее симметричный сосед 1-hop          |
    перестал быть симметричным              |
                                            |
                 Время, до которого сетевые адреса этого
                 соседа анонсируются в сообщениях HELLO
                 на всех интерфейсах MANET с использованием
                 OTHER_NEIGHB TLV, Value = LOST

Рисунок 10. Создание сообщения HELLO при потере ближайшего соседа с симметричным подключением на любом интерфейсе MANET.

На рисунке 11 показан интервал I_HOLD_TIME, в течение которого адреса, которые использовались (но перестали) локальным интерфейсом, исключаются из числа считающихся сетевыми адресами соседей 2-hop (чтобы маршрутизатор не записывал их как своих соседей 2-hop в течение этого периода).

I_HOLD_TIME:      |----------------------------|
Время          ---*----------------------------------->
                  ^                            ^
                  |                            |
  Время, когда используемый локальным          |
  интерфейсом сетевой адрес был утрачен        |
                                               |
                          Время, когда этот сетевой адрес
                          перестает включаться в 2-Hop Set
                          данного маршрутизатора

Рисунок 11. Удаление сетевого адреса на локальном интерфейсе.

Приложение F. Варианты топологии

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

Приведенные примеры не являются исчерпывающими и выбраны для представления в NHDP соседских отношений физической топологии MANET.

Примеры включают три физических маршрутизатора (A, B, C), каждый из которых имеет один или два интерфейса, обозначенные как верхний (top) и нижний (bottom). Каждый интерфейс имеет один или два адреса, а симметричные соединения между парами интерфейсов показаны на рисунке линиями.

Во всех примерах топология представлена как записанная протоколом NHDP в маршрутизаторе A.

F.1. Пример 1 — стандартная топология с одним интерфейсом

На рисунке 12 каждый маршрутизатор имеет 1 интерфейс с одним адресом IP. Это простейшая из возможных сетей и ее представление показано справа на рисунке 12.

    __________ __________
   |          |          |
  {1}        {2}        {3}
   |          |          |              {1}--------{2}--------{3}
+--'--+    +--'--+    +--'--+
|  A  |    |  B  |    |  C  |
+-----+    +-----+    +-----+

Рисунок 12. Стандартная топология с одним интерфейсом (слева) и представление NHDP.

Local Information Set в A содержит один Local Interface Tuple с I_local_iface_addr_list = {1}. Это значение показано как {1} в левой части рисунка.

Interface Information Base имеет лишь один Link Set, представляющий «верхний» интерфейс A или {1}. В этом Link Set единственный Link Tuple имеет L_neighbor_iface_addr_list, содержащий {2}, это соответствует пунктирной линии от {1} к {2} в правой части рисунка 12. 2-Hop Set содержит один 2-Hop Tuple с N2_neighbor_iface_addr_list = {2} и N2_2hop_addr = {3}, это соответствует пунктирной линии от {2} к {3} в правой части рисунка 12.

В последующих примерах этого приложения используются похожие описания и нотация.

F.2. Пример 2 — интерфейс с 2 адресами у ближайшего соседа

Сеть на рисунке 13 идентична примеру 1, но средний маршрутизатор B имеет 2 адреса IP на одном интерфейсе.

    __________ __________
   |          |          |
  {1}       {2,4}       {3}
   |          |          |              {1}-------{2,4}-------{3}
+--'--+    +--'--+    +--'--+
|  A  |    |  B  |    |  C  |
+-----+    +-----+    +-----+

Рисунок 13. Одиночные интерфейсы с ближайшим соседом B, имеющим 2 адреса (слева), и представление NHDP.

Содержимое Interface Information Base идентично примеру 1, но L_neighbor_iface_addr_list = {2,4} и N2_neighbor_iface_addr_list = {2,4}.

F.3. Пример 3 — интерфейс с 2 адресами у соседа второго уровня

Сеть на рисунке 13 идентична примеру 1, но средний правый C имеет 2 адреса IP на одном интерфейсе.

    __________ __________
   |          |          |
  {1}        {2}       {3,4}                             +----{3}
   |          |          |              {1}--------{2}---+
+--'--+    +--'--+    +--'--+                            +----{4}
|  A  |    |  B  |    |  C  |
+-----+    +-----+    +-----+

Рисунок 14. Одиночные интерфейсы с соседом 2-Hop C, имеющим 2 адреса (слева), и представление NHDP.

Содержимое Interface Information Base идентично примеру 1, но 2-Hop Set содержит дополнительный 2-Hop Tuple с N2_neighbor_iface_addr_list = {2} и N2_2hop_addr = {4}. Эти 2-Hop Tuple показаны справа пунктирами от {2} к {3} и от {2} к {4}, соответственно.

F.4. Пример 4 — интерфейсы с двумя адресами

Сеть на рисунке 15 идентична примеру 1, но все маршрутизаторы имеют по 2 адреса IP на интерфейсе. Local Information Base в A совпадает с примером 1, но I_local_iface_addr_list = {1,5}.

    __________ __________
   |          |          |
 {1,5}      {2,6}      {3,4}                             +----{3}
   |          |          |             {1,5}------{2,6}--+
+--'--+    +--'--+    +--'--+                            +----{4}
|  A  |    |  B  |    |  C  |
+-----+    +-----+    +-----+

Рисунок 15. Одиночные интерфейсы на всех маршрутизаторах, имеющие 2 адреса (слева), и представление NHDP.

Содержимое Interface Information Base в этом случае идентично комбинации Interface Information Base из примеров 1-3.

F.5. Пример 5 — два интерфейса у соседа второго уровня

На рисунке 16 все маршрутизаторы имеют 1 адрес IP на интерфейс, а сосед 2-hop имеет два интерфейса.

    __________ __________
   |          |          |
  {1}        {2}        {3}                              +----{3}
   |          |          |              {1}--------{2}---+
+--'--+    +--'--+    +-----+                            +----{4}
|  A  |    |  B  |    |  C  |
+-----+    +-----+    +-----+
                         |
                        {4}

Рисунок 16. Одиночные адреса с соседом 2-Hop C, имеющим 2 интерфейса (слева), и представление NHDP.

Interface Information Base идентична примеру 3 и NHDP топологически не различаются.

F.6. Пример 6 — два интерфейса у ближайшего соседа

На рисунке 17 все маршрутизаторы имеют 1 адрес IP на интерфейс, а сосед 1-hop имеет два интерфейса.

    __________
   |          |
  {1}        {2}                                  +-----+
   |          |                         {1}-------| {2} |------{4}
+--'--+    +--'--+    +-----+                     | {5} |
|  A  |    |  B  |    |  C  |                     +-----+
+-----+    +-----+    +-----+
              |          |
             {5}        {4}
              |__________|

Рисунок 17. Одиночные адреса с соседом 1-Hop B, имеющим 2 интерфейса (слева), и представление NHDP.

Local Information Base идентична примеру 1.

Interface Information Base имеет единственный Link Set, содержащий один Link Tuple = L_neighbor_iface_addr_list = {2}. 2-Hop Set содержит один 2-Hop Tuple с N2_neighbor_iface_addr_list = {2} и N2_2hop_addr = {4}.

Neighbor Information Base содержит Neighbor Set с одним Neighbor Tuple, который представляет маршрутизатор B с N_neighbor_addr_list = {2,5}. Эта запись представлена справа на рисунке 17 прямоугольником с {2} и {5}.

Отметим, что у маршрутизатора A нет информации, показывающей, что интерфейсы маршрутизатора B соединены с маршрутизатором C. Однако A знает, что адрес {4} (и маршрутизатор C) достижим через {2}.

F.7. Пример 7 — сдвоенный интерфейс с соседями 1-Hop и 2-Hop

На рисунке 18 все маршрутизаторы имеют 1 адрес IP на интерфейс, а соседи 1-hop и 2-hop имеют по 2 интерфейса. Кроме того, имеется 2 физических соединения между маршрутизаторами B и C через разные пары интерфейсов.

    __________ __________
   |          |          |
  {1}        {2}        {3}                      +-----+   +----{3}
   |          |          |             {1}-------| {2} |---+
+--'--+    +--'--+    +-----+                    | {5} |   +----{4}
|  A  |    |  B  |    |  C  |                    +-----+
+-----+    +-----+    +-----+
              |          |
             {5}        {4}
              |__________|

Рисунок 18. Одиночные адреса с соседом 1-Hop B и соседом 2-Hop C, имеющими по 2 интерфейса (слева), и представление NHDP.

Local Information Base идентична примеру 1.

Link Set идентичен примеру 6, а 2-Hop Set содержит, как в примере 5 (и подобно примерам 3 и 4), два 2-Hop Tuple, представляющие два канала между маршрутизаторами B и C.

Отметим, что маршрутизатор A не имеет информации, описывающей соединения между интерфейсами B и C, а также не знает, что интерфейсы с адресами {3} и {4} находятся на одном маршрутизаторе. Однако A знает, что адреса {3} и {4} (маршрутизатор C) доступны через {2}.

F.8. Пример 8 — cдвоенный интерфейс локально и у ближайшего соседа

На рисунке 19 все маршрутизаторы имеют 1 адрес IP на интерфейс, а маршрутизатор A и его ближайший сосед B имеют по 2 интерфейса. Кроме того, имеется 2 физических соединения между маршрутизаторами A и B через разные пары интерфейсов.

    __________ __________
   |          |          |                       +-----+
  {1}        {2}        {3}            {1}-------| {2} |--------{3}
   |          |          |                       | {5} |
+--'--+    +--'--+    +-----+                    +-----+
|  A  |    |  B  |    |  C  |
+-----+    +-----+    +-----+                    +-----+
   |          |                                  | {2} |
  {6}        {5}                       {6}-------| {5} |--------{3}
   |__________|                                  +-----+

Рисунок 19. Одиночные адреса с соседями 1-Hop A и B, имеющими по 2 интерфейса (слева), и представление NHDP.

Local Information Set содержит 2 Local Interface Tuple с I_local_iface_addr_list = {1} и {6}, соответственно.

В каждой Interface Information Base набор Link Set содержит один Link Tuple, представляющий каналы между {1} и {2} и между {6} и {5}, соответственно. 2-Hop Set for для интерфейса {1} содержит один 2-Hop Tuple с N2_neighbor_iface_addr_list = {2} и N2_2hop_addr = {3}. 2-Hop Set для интерфейса {6} содержит один 2-Hop Tuple с N2_neighbor_iface_addr_list = {5} и N2_2hop_addr = {3}.

Neighbor Information Base содержит Neighbor Set с одним Neighbor Tuple, представляющим маршрутизатор B с N_neighbor_addr_list = {2,5}. Эта запись показана прямоугольником с {2} и {5}.

F.9. Пример 9 – два интерфейса на всех маршрутизаторах

На рисунке 20 все маршрутизаторы имеют 1 адрес IP на интерфейс и по 2 интерфейса. Кроме того, имеются 2 физических канала между A и B через разные пары интерфейсов и 2 физических канала между B и C тоже через разные пары.

    __________ __________
   |          |          |                       +-----+   +----{3}
  {1}        {2}        {3}            {1}-------| {2} |---+
   |          |          |                       | {5} |   +----{4}
+--'--+    +--'--+    +-----+                    +-----+
|  A  |    |  B  |    |  C  |
+-----+    +-----+    +-----+                    +-----+
   |          |          |                       | {2} |   +----{3}
  {6}        {5}        {4}            {6}-------| {5} |---+
   |__________|__________|                       +-----+   +----{4}

Рисунок 20. Одиночные адреса со всеми маршрутизаторами, имеющими по 2 интерфейса (слева), и представление NHDP.

Local Information Set идентичен примеру 8. Interface Information Base для каждого интерфейса в A тоже идентичны примеру 8, но имеют дополнительный 2-Hop Tuple в каждом 2-Hop Set, представляющий канал между маршрутизатором B и интерфейсом маршрутизатора C с адресом {4}.

Как в примере 7, маршрутизатор A не имеет информации о соединениях между интерфейсами маршрутизаторов B и C, а также не знает, что адреса {3} и {4} относятся к одному маршрутизатору. Однако маршрутизатор A знает, что адреса {3} и {4} (и маршрутизатор C) доступны через {2} или {5} (в зависимости от локального интерфейса).

F.10. Пример 10 — двойные интерфейсы с двумя адресами у всех

На рисунке 21 все маршрутизаторы имеют 2 адреса IP на интерфейс и по 2 интерфейса. Кроме того, имеются 2 физических канала между A и B через разные пары интерфейсов и 2 физических канала между B и C тоже через разные пары.

                                                            +--{9}
    __________ __________                            +------|
   |          |          |                 +-----+   |      +--{10}
 {1,2}      {5,6}      {9,10}       {1,2}--|{5,6}|---+
   |          |          |                 |{7,8}|   |      +--{11}
+--'--+    +--'--+    +-----+              +-----+   +------|
|  A  |    |  B  |    |  C  |                               +--{12}
+-----+    +-----+    +-----+
   |          |          |                                  +--{9}
   |          |          |                 +-----+   +------|
   |          |          |                 |{5,6}|   |      +--{10}
 {3,4}      {7,8}     {11,12}       {3,4}--|{7,8}|---+
   |__________|__________|                 +-----+   |      +--{11}
                                                     +------|
                                                            +--{12}

Рисунок 21. Двойные адреса на всех маршрутизаторах, имеющих по 2 интерфейса (слева), и представление NHDP.

Этот пример является комбинацией всех приведенных выше примеров. Local Information Set в A содержит Local Information Tuple для каждого из своих интерфейсов и каждая Interface Information Base содержит в своем Link Set представление каналов {1,2}-{5,6} или {3,4}-{7,8}, соответственно. Neighbor Set (в Neighbor Information Base) указывает наличие маршрутизатора B и всех адресов на всех его интерфейсах, т. е. {5,6,7,8}.

Как в примере 9, адрес каждого интерфейса маршрутизатора C представлен в 2-Hop Set каждой Interface Information Base как канал от маршрутизатора B к каждому из этих интерфейсов. Маршрутизатор A не имеет информации о соединениях между интерфейсами маршрутизаторов B и C, а также не знает, что адреса {9}, {10}, {11}, {12} относятся к одному маршрутизатору (и что некоторые, например, {9} и {10} являются адресами одного интерфейса).

F.11. Пример 11 — локальный сдвоенный интерфейс с одним адресом

На рисунке 22 все маршрутизаторы, кроме A, имеют по одному интерфейсу. Каждый из двух интерфейсов A имеет канал к интерфейсу маршрутизатора B. Все интерфейсы имеют по одному адресу.

    __________ __________
   |     _____|          |
  {1}   |    {2}        {3}             {1}--------{2}---------{3}
   |    |     |          |
+--'--+ |  +--'--+    +-----+
|  A  | |  |  B  |    |  C  |
+-----+ |  +-----+    +-----+
   |    |
  {6}   |                               {6}--------{2}---------{3}
   |____|

Рисунок 22. Один адрес с A, имеющим 2 интерфейса, подключенных к одному интерфейсу B (слева), и представление NHDP.

Это похоже на пример 8, но адрес {2} заменяет собой адрес {5}. В частности, оба Link Tuple (по одному в Link Set, каждый из которых соответствует Interface Information Base) имеют L_neighbor_iface_addr_list = {2}, Neighbor Set (в Neighbor Information Base) содержит 1 Neighbor Tuple с N_neighbor_addr_list = {2}, а оба 2-Hop Tuple (по одному в каждом 2-Hop Set в соответствующих Interface Information Base) имеют N2_neighbor_iface_addr_list = {2} и N2_2hop_addr = {3}.

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

Thomas Heide Clausen

LIX, Ecole Polytechnique

Phone: +33 6 6058 9349

EMail: T.Clausen@computer.org

URI: http://www.ThomasClausen.org/

Christopher Dearlove

BAE Systems ATC

Phone: +44 1245 242194

EMail: chris.dearlove@baesystems.com

URI: http://www.baesystems.com/

Justin W. Dean

Naval Research Laboratory

Phone: +1 202 767 3397

EMail: jdean@itd.nrl.navy.mil

URI: http://pf.itd.nrl.navy.mil/

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

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

1Neighborhood discovery protocol.

2Mobile ad hoc network — специализированная мобильная сеть.

3Internet Engineering Task Force.

4Internet Engineering Steering Group.

5Optimized Link State Routing — оптимизированная маршрутизация по состоянию каналов.

6В оригинале 3 пункта списка частично повторялись. См. http://www.rfc-editor.org/errata/eid4866. Прим. перев.

7В оригинале ошибочно сказано 2-Hop Neighbor Tuple. См. https://www.rfc-editor.org/errata/eid4276. Прим. перев.

8В оригинале текст «если не выполняется условие L_lost = true» отсутствует. См. https://www.rfc-editor.org/errata/eid3677. Прим. перев.

Рубрика: RFC | Комментарии отключены

RFC 6182 Architectural Guidelines for Multipath TCP Development

Опубликовано 19.03.2011 автором Nikolai Malykh

Internet Engineering Task Force (IETF)                           A. Ford
Request for Comments: 6182                           Roke Manor Research
Category: Informational                                        C. Raiciu
ISSN: 2070-1721                                               M. Handley
                                               University College London
                                                                S. Barre
                                        Universite catholique de Louvain
                                                              J. Iyengar
                                           Franklin and Marshall College
                                                              March 2011

Architectural Guidelines for Multipath TCP Development

Архитектурные рекомендации для разработки Multipath TCP

Аннотация

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

В документе представлены архитектурные рекомендации для разработки транспортного протокола с множеством путей (Multipath Transport Protocol) и указаны способы объединения этих архитектурных элементов для создания протокола Multipath TCP (MPTCP). В документе перечислены некоторые высокоуровневые решения, обеспечивающие основу для создания протокола MPTCP на основе рассмотренных архитектурных требований.

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

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

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

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

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

1. Введение

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

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

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

Multipath TCP является измененным вариантом TCP [1], который реализует доставку по нескольким путям, объединяя их в транспортное соединение, прозрачное для приложения. Протокол Multipath TCP в первую очередь связан со сквозным использованием множества путей, когда один или оба конечных хоста являются многодомными. Протокол может также применяться при наличии в сети множества путей, которыми конечный хост может манипулировать, например, с помощью разных портов для ECMP³ [4].

Протокол MPTCP, определенный в [5], задает концепцию Multipath TCP. В этом документе рассмотрены базовые принципы архитектуры Multipath TCP для достижения целей, заявленных в разделе 2, а также основные решения, лежащие в основе MPTCP (раздел 5).

Хотя функции для работы с многодомными хостами и множеством путей не являются новыми для транспортных протоколов (примером может служить SCTP⁴ [6]), целями MPTCP является более широкое развертывание и совместимость с сетью. Эти цели, подробно рассматриваемые в разделе 2, относятся к представлению MPTCP сети (чтобы не знающие о MPTCP элементы воспринимали его как TCP) и приложению (путем предоставления услуг, эквивалентных TCP не поддерживающим MPTCP приложениям).

Основными целями этого документа служат (i) описание назначения транспортировки по нескольким путям (назначение MPTCP), (ii) описание архитектурной основы MPTCP (обсуждение другого транспорта со множеством путей) и (iii) обсуждение и документирование высокоуровневых решений, принятых в MPTCP, а также их влияние.

Сопровождающий этот архитектурный обзор документ детализирует расширения протокола [5], алгоритмы контроля перегрузок [7] и вопросы прикладного уровня [8]. Совместно эти документы полностью описывают устройство Multipath TCP. Отметим, что конкретные компоненты могут заменяться в соответствии с определенной здесь декомпозицией уровней и функций.

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

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

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

Regular/Single-Path TCP — обычный (единственный) путь TCP

Стандартная версия TCP [1], применяемая сегодня для взаимодействия между парой адресов IP и портов.

Multipath TCP — TCP с множеством путей

Измененная версия протокола TCP для одновременной поддержки множества путей между хостами.

Path — путь

Последовательность каналов между отправителем и получателем, определяемая в контексте документа парой адресов отправителя и получателя.

Host — хост

Конечный хост, инициирующий или завершающий соединение Multipath TCP.

MPTCP

Предложенное в [5] расширение протокола для реализации Multipath TCP.

Subflow — субпоток

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

(Multipath TCP) Connection — соединение (Multipath TCP)

Множество из одного или нескольких субпотоков, объединенных для предоставления услуги Multipath TCP приложению на хосте.

1.3. Эталонный сценарий

Схема на рисунке 3 иллюстрирует типичный пример использования Multipath TCP, где два хоста A и B взаимодействуют между собой. Эти хосты являются многодомными и многоадресными, обеспечивая два несвязанных соединения через Internet. Адреса хостов обозначены A1, A2, B1 и B2. В результате можно организовать до 4 путей между хостами A1-B1, A1-B2, A2-B1, A2-B2.

+------+           __________           +------+
|      |A1 ______ (          ) ______ B1|      |
| Хост |--/      (            )      \--| Хост |
|      |        (   Internet   )        |      |
|  A   |--\______(            )______/--|   B  |
|      |A2        (__________)        B2|      |
+------+                                +------+

Рисунок 1. Простой пример применения Multipath TCP.

Сценарий будет работать с любым числом адресов (от 1) на каждом хосте, а также при любом числе путей между хостами, начиная с 2 (т. е. num_addr(A) * num_addr(B) > 1). Пути, образуемые комбинациями адресов, не обязаны быть полностью разделенными в сети Internet и вопросы беспристрастности при возникновении «пробок» на общем пути должны обрабатываться контроллером перегрузок Multipath TCP. Кроме того, пути через Internet зачастую не обеспечивают «чистого» сквозного обслуживания и могут включать промежуточные устройства, такие как NAT и МСЭ⁵.

2. Цели

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

2.1. Функциональные цели

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

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

Распределение трафика по доступным путям и отклики на перегрузку выполняются в соответствии с принципами объединения ресурсов [3], а дополнительным эффектом достижения этих целей является широкое применение Multipath TCP в Internet, которое должно повысить общую производительность сети за счет избавления от «пробок» и использования по возможности резервных «емкостей» сети.

Кроме того, Multipath TCP следует поддерживать автоматическое согласование применения. Хосту, поддерживающему Multipath TCP нужна возможность надежного определения возможностей хоста-партнера в части поддержки требуемых расширений, поскольку при их отсутствии он вынужден будет вернуться к использования обычного протокола TCP.

2.2. Цели совместимости

В дополнение к указанным выше функциональным целям протокол Multipath TCP должен соответствовать множеству целей совместимости для поддержки развертывания в сети Internet. Эти цели делятся на несколько категорий.

2.2.1. Совместимость с приложениями

Совместимость с приложениями относится к представлению Multipath TCP в плане доступных для использования API и предоставляемой модели обслуживания.

Протокол Multipath TCP должен следовать модели сервиса, используемой TCP [1] — упорядоченная, надежная, ориентированная на байты доставка. Кроме того, соединению Multipath TCP следует предоставлять приложению пропускную способность не хуже ожидаемой при работе через одно соединение TCP по любому из доступных путей. Однако Multipath TCP не может обеспечить такой же уровень согласованности пропускной способности и задержки, как одиночное соединение TCP. Эти и другие вопросы применения подробно рассматриваются в [8].

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

Обычные сессии TCP могут пережить короткие перебои связности, сохраняя состояние на конечных хостах до тайм-аута. Желательная поддержка такой непрерывности сессий и в MPTCP, однако обстоятельства могут быть разными. Если в обычном TCP адреса IP остаются неизменными после потери связности, в MPTCP это может быть не так. Желательно (но не требуется) поддерживать непрерывность сессий «break-before-make⁶». Это вносит ограничения для механизмов защиты, описанные в параграфе 5.8. Тайм-ауты для такой функции настраиваются локально.

2.2.2. Совместимость с сетью

+-------------+                                       +-------------+
| Приложение  |<------ сквозное взаимодействие ------>| Приложение  |
+-------------+                                       +-------------+
|  Транспорт  |<------ сквозное взаимодействие ------>|  Транспорт  |
+-------------+   +-------------+   +-------------+   +-------------+
|    Сеть     |<->|    Сеть     |<->|    Сеть     |<->|    Сеть     |
+-------------+   +-------------+   +-------------+   +-------------+
 Конечный хост     Маршрутизатор     Маршрутизатор     Конечный хост

Рисунок 2. Традиционная архитектура Internet.

В традиционной архитектуре Internet сетевые устройства работают на сетевом (L3) и нижележащих уровнях, а вышележащие уровни создаются лишь конечными хостами. Хотя показанная на рисунке 2 архитектура изначально в основном соблюдалась, сейчас она уже не отражает реалии Internet в связи с наличием большого числа промежуточных устройств [9], которые обычно помещаются на транспортный уровень и иной раз полностью перехватывают транспортные соединения, делая первым «сквозным» уровень приложений, как показано на рисунке 3.

+-------------+                                       +-------------+
| Приложение  |<------ сквозное взаимодействие ------>| Приложение  |
+-------------+                     +-------------+   +-------------+
|  Транспорт  |<------------------->|  Транспорт  |<->|  Транспорт  |
+-------------+   +-------------+   +-------------+   +-------------+
|    Сеть     |<->|    Сеть     |<->|    Сеть     |<->|    Сеть     |
+-------------+   +-------------+   +-------------+   +-------------+
 Конечный хост     Маршрутизатор       Межсетевой       Конечный хост
                                   экран, NAT, Proxy

Рисунок 3. Реалии Internet.

Перехват соединений промежуточными устройствами приводит к потере «общей судьбы» (fate-sharing) [10] — «жестким» состояниям, потеря или повреждение которых ведет к потере или повреждению сквозного транспортного соединения.

Цель совместимости с сетью требует от расширения TCP на множество путей сохранения совместимости с сегодняшней сетью Internet, включая разумные усилия по работе через преобладающие промежуточные устройства, такие как МСЭ, трансляторы NAT и прокси для повышения производительности [9]. Это требование основано на осознании важной роли промежуточных устройств в создании «пробок» для любого транспорта, отличного от TCP и UDP, что ограничивает представление Multipath TCP как TCP в соединительных линиях для использования расширений TCP там, где они нужны. Для обеспечения сквозной работы транспорта в Multipath TCP должна сохраняться «общая судьба» без каких-либо допущений о поведении промежуточных устройств.

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

Промежуточные устройства могут также приводить к тому, что некоторые свойства TCP могут поддерживаться в одном субпотоке, но отсутствовать в другом. Обычно это происходит на уровне субпотока (например, селективные подтверждения SACK [11]) и поэтому не будет влиять на свойства соединения в целом. В будущем для любых расширений на уровне соединения TCP следует учитывать возможность сосуществования с MPTCP.

Изменения для поддержки Multipath TCP остаются на транспортном уровне, хотя требуются некоторые сведения о нижележащем сетевом уровне. Расширению Multipath TCP следует работать взаимозаменяемо с IPv4 и IPv6, т. е. одно соединение может работать сразу через сети IPv4 и IPv6.

2.2.3. Совместимость с другими пользователями

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

2.3. Безопасность

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

2.4. Смежные протоколы

Имеется ряд сходств между SCTP [6] и MPTCP, поскольку оба могут использовать множество адресов конечного хоста для поддержки нескольких путей. Основным применением SCTP является поддержка избыточности (резервирования) и мобильности для многодомных хостов (т. е. при изменении адреса конечного хоста на одном из путей), а одновременное использование множества путей не поддерживается. Расширения, предложенные для транспортировки одновременно по нескольким путям [13], еще не стандартизованы. Наиболее широко для транспортировки потоков применяется протокол TCP [1], а SCTP не соответствует требованиям по совместимости с сетью и приложениями, указанным в параграфе 2.2. В части совместимости с сетью имеются проблемы, связанные с тем, что промежуточные устройства (прежде всего NAT) не знают о протоколе SCTP и в результате блокируют его. В части совместимости с приложениями нужно активно выбирать использование протокола SCTP, а из-за проблем с развертыванием это делается достаточно редко. Цели совместимости MPTCP частично основаны на наблюдении за развертыванием SCTP.

3. Архитектурные основы Multipath TCP

В этом разделе представлен один из возможных вариантов транспортной архитектуры, которые по мнению авторов позволит эффективно достичь целей Multipath TCP. Предложенная здесь новая модель Internet основана на идеях, предложенных ранее в Tng⁷ [14]. Не будучи единственной возможной архитектурой для поддержки транспорта со множеством путей, Tng включает многие уроки, извлеченные из исследований транспорта и практики разработок, предлагая хорошую отправную точку для рассмотрения имеющейся архитектуры Internet и ее влияния на разработку новых транспортных решений и расширений транспорта Internet.

+------------------+
|    Приложение    |
+------------------+  ^ Ориентированные на приложение функции
|                  |  | транспорта (семантика)
+ - - Транспорт - -+ ----------------------------------------
|                  |  | Ориентированные на сеть функции
+------------------+  v транспорта (поток + конечная точка)
|       Сеть       |
+------------------+
  Имеющиеся уровни      Декомпозиция Tng

Рисунок 4. Декомпозиция транспортных функций.

Tng делит транспортный уровень на два уровня, ориентированные на приложение и сеть, как показано на рисунке 4. Ориентированный на приложения уровень (семантика) реализует функции, связанные в первую очередь с поддержкой и защитой сквозных коммуникаций между приложениями. Ориентированный на сеть уровень (поток + конечная точка) реализует такие функции, как идентификация конечной точки (использование номеров портов) и контроль перегрузок. Эти функции, традиционно размещаемые на якобы «сквозном» транспортном уровне, на практике вызывают существенную озабоченность операторов и промежуточных устройств, развернутых для исполнения правил использования сети [15] [16] или оптимизации производительности [17]. На рисунке 5 показано взаимодействие промежуточного устройства с разными уровнями в этой модели транспорта с декомпозицией. Ориентированный на приложения уровень обеспечивает сквозную работу, а ориентированный на сеть работает на уровне сегментов и может быть реализована на промежуточных устройствах.

+-------------+                                       +-------------+
| Приложение  |<------ сквозное взаимодействие ------>| Приложение  |
+-------------+                                       +-------------+
|  Семантика  |<------ сквозное взаимодействие ------>|  Семантика  |
+-------------+   +-------------+   +-------------+   +-------------+
|Flow+Endpoint|<->|Flow+Endpoint|<->|Flow+Endpoint|<->|Flow+Endpoint|
+-------------+   +-------------+   +-------------+   +-------------+
|    Сеть     |<->|    Сеть     |<->|    Сеть     |<->|    Сеть     |
+-------------+   +-------------+   +-------------+   +-------------+
 Конечный хост      МСЭ или NAT        Прокси для      Конечный хост
                                   производительности

Рисунок 5. Промежуточные устройства в новой модели.

Архитектура MPTCP соответствует декомпозиции Tng, как показано на рисунке 6. Протокол MPTCP, который обеспечивает совместимость приложений за счет предоставления семантики в стиле TCP для глобального упорядочивания данных приложения и надежной доставки, является экземпляром ориентированного на приложения уровня семантики. Компоненты субпотоков TCP, которые обеспечивают совместимость с сетью, проявляя себя как сетевые потоки TCP, являются экземплярами ориентированного на сеть уровня Flow+Endpoint.

+--------------------------+    +-------------------------------+
|       Приложение         |    |          Приложение           |
+--------------------------+    +-------------------------------+
|        Семантика         |    |             MPTCP             |
|------------+-------------|    + - - - - - - - + - - - - - - - +
| Flow+Endpt | Flow+Endpt  |    | Субпоток (TCP)| Субпоток (TCP)|
+------------+-------------+    +---------------+---------------+
|    Сеть    |    Сеть     |    |       IP      |       IP      |
+------------+-------------+    +---------------+---------------+

Рисунок 6. Связь между Tng (слева) и MPTCP (справа).

Будучи расширением протокола TCP, MPTCP явно признает наличие промежуточных устройств и задает протокол, работающий «в двух масштабах» — MPTCP обеспечивает сквозное взаимодействие, позволяя компонентам TCP работать на уровне сегментов.

4. Функциональная декомпозиция MPTCP

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

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

                             +-------------------------------+
                             |           Приложение          |
+---------------+            +-------------------------------+
|  Приложение   |            |             MPTCP             |
+---------------+            + - - - - - - - + - - - - - - - +
|      TCP      |            | Субпоток (TCP)| Субпоток (TCP)|
+---------------+            +-------------------------------+
|      IP       |            |       IP      |      IP       |
+---------------+            +-------------------------------+

Рисунок 7. Сравнение стеков стандартного TCP и MPTCP.

Расположенное ниже приложения расширение MPTCP управляет множеством расположенных под ним субпотоков TCP и должно выполнять перечисленные ниже функции.

Поддержка путей. Эта функция находит и использует множество путей между хостами. MPTCP использует наличие множества адресов IP на одном или обоих хостах в качестве индикатора. Функции поддержки путей в протоколе MPTCP служат механизмами сигнализации хостам о дополнительных адресах и организации новых субпотоков, связанных с имеющимся соединением MPTCP.
Планирование пакетов. Эта функция разбивает поток байтов от приложения на сегменты, передаваемые в одном из доступных субпотоков. MPTCP использует отображение последовательности данных, связывая сегменты, отправленные в разных субпотоках, порядковыми номерами на уровне соединения, что позволяет передавать сегменты в разных субпотоках с сохранением порядка на приемной стороне. Планировщик пакетов зависит от информации о доступности путей, предоставляемой средствами поддержки путей, что позволяет передавать сегменты по разным путям с восстановлением порядка у получателя. Планировщик на основе данных о доступности путей, предоставляемых средствами поддержки путей, использует субпотоки для передачи сегментов из очереди. Эта функция отвечает также за восстановление порядка принятых в разных субпотоках TCP пакетов на уровне соединения в соответствии с отображением порядковых номеров.
Интерфейс с субпотоками (отдельные пути TCP). Субпотоки принимают сегменты от планировщика пакетов и передают их по конкретному пути, обеспечивая подтвеждаемую доставку хосту. MPTCP использует услуги TCP для совместимости с сетью, а TCP обеспечивает надежную, упорядоченную доставку. TCP добавляет свои порядковые номера в сегменты, используемые для обнаружения потерь и повторной передачи пакетов на уровне субпотока. На приемной стороне субпоток передает собранные данные планировщику пакетов для сборки на уровне соединения. Отображение последовательности данных от планировщика на стороне отправителя позволяет корректно восстановить поток байтов.
Контроль перегрузок координирует распределение трафика между субпотоками при возникновении насыщения в сети. Как указано, этот алгоритм должен обеспечить для соединения MPTCP пропускную способность больше пропускной способности отдельного потока TCP через сеть с «пробками». Алгоритм для поддержки механизма задан в [7].

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

5. Устройство протокола

Очевидно, что имеется много вариантов разработки расширения TCP с поддержкой нескольких путей. Однако рассмотренные выше цели ограничивают набор возможных решений, оставляя сравнительно небольшой выбор во многих областях. В этом разделе очерчены высокоуровневые решения, основанные на архитектуре, описанной в разделе 3, с учетом устройства расширения MPTCP [5].

5.1. Порядковые номера

MPTCP использует два типа порядковых номеров — на уровне соединения и на уровне каждого субпотока. Это позволяет сегментировать данные на уровне соединения, а также собирать и (при необходимости) передавать повторно с теми же порядковыми номерами для соединения но с другими номерами на уровне субпотока.

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

Отправитель должен быть способен сказать получателю, как собрать данные для доставки приложению. Для сборки получатель должен определить, как данные из субпотока (переносящие свои номера) отображаются на уровень соединения. Это называется «отображением последовательности данных» (data sequence mapping). Такое отображение можно представить кортежем (порядковый номер данных, порядковый номер в субпотоке, размер), т. е. для данного числа байтов (размер) порядковые номера в субпотоке, начиная с указанного номера, отображаются на порядковые номера в соединении (начиная с указанного). Эта информация предположительно может приходить из разных источников.

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

В По причине наличия отмеченных проблем выбранное для протокола MPTCP решение состоит в том, что всякий раз при возникновении необходимости отправки отображения данных субпотока другому хосту protocol должны передаваться все 3 части данных (data seq, subflow seq, length). Для сокращения издержек можно отправлять отображения периодически, включая в них более одного сегмента. Нужны дополнительные эксперименты для поиска компромиссов, связанных с частотой передачи отображений. Ее можно исключить полностью в соединении, где пока не используется более одного субпотока и пространства номеров соединения и субпотока совпадают.

5.2. Надежность и повторы передачи

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

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

Кроме того, можно представить случаи, когда подтверждения на уровне соединения будут повышать отказоустойчивость. Рассмотрим субпоток, проходящий через прозрачный прокси — если в прокси возникает отказ после отправки ACK, отправитель не будет повторять потерянный сегмент в другом субпотоке, считая, что сегмент получен. В результате соединение прерывается, несмотря на наличие других работающих субпотоков, и отправитель не сможет определить причину проблемы. Примером ситуации, где это может случиться, является перемещение между точками беспроводного доступа, на каждой из которых работает прокси транспортного уровня. Наконец, в качестве оптимизации может оказаться возможной передача подтверждения на уровне соединения по пути с наименьшим временем кругового обхода (Round-Trip Time или RTT), что может снизить требования к буферу передачи (параграф 5.3).

Следовательно для обеспечения полной отказоустойчивости Multipath TCP с учетом указанных ограничений MPTCP, работающий в публичной сети Internet, должен поддерживать явные подтверждения на уровне соединения в дополнение к подтверждениям на уровне субпотока. Подтверждения на уровне соединения требуются лишь для сигнализации о перемещении окна приема вперед и эвристика такой сигнализации более подробно рассматривается в спецификации протокола [5].

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

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

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

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

5.3. Буферы

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

В TCP с одним путем обычно рекомендуется устанавливать размер приемного буфера 2*BDP (произведение пропускной способности и задержки, т. е. BDP = BW*RTT, где BW — пропускная способность, а RTT — время кругового обхода). Один размер BDP позволяет восстановить порядок, нарушенный в сети, другой BDP позволяет сохранять соединение при ускоренном повторе передачи, когда от получателя требуется возможность сохранять данные в течение дополнительного интервала RTT.

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

Худшим случаем является тайм-аут субпотока с наибольшим отношением RTT/RTO (время кругового обхода к тайм-ауту повторной передачи), когда получатель буферизует данные из всех субпотоков за интервал RTO. Таким образом, минимальный размер приемного буфера для соединения, который позволит избежать остановки при отказе субпотока, составляет sum(BW_i)*RTO_max, где BW_i = пропускная способность каждого субпотока i, а RTO_max — наибольшее значение RTO среди субпотоков.

Это на порядок больше размера буфера для одного потока и, возможно, слишком много для практических целей. Более разумным требованием будет предотвращение остановки в отсутствие тайм-аутов. Поэтому рекомендуется приемный буфер размером 2*sum(BW_i)*RTT_max, где RTT_max — наибольшее значение RTO среди субпотоков. Такой размер приемного буфера предотврати остановку субпотоков при использовании ускоренного повтора любым из них.

Результирующий размер буфера должен быть достаточно небольшим для практического применения. Однако могут возникать экстремальные ситуации, когда быстрый путь с высокой пропускной способностью (например, 100 Мбит/с с RTT 10 мсек.) применяется вместе с медленными путями (например, 1 Мбтит/с и RTT 1000 мсек.). В таком случае требуемый размер буфера составит 12,5 Мбайт, что явно слишком много. В подобных случаях может оказаться разумным использовать в соединении MPTCP лишь самые быстрые пути, оставляя медленные в качестве резерва.

Для буфера передачи рекомендуется такой же размер, как для приемного буфера, т. е. 2*sum(BW_i)*RTT_max. Это обусловлено тем, что отправитель локально хранить переданные, но не подтвержденные на уровне соединения сегменты. Размер буфера передачи особенно важен для хостов, поддерживающих много исходящих соединений. Если требуемый размер слишком велик, хосту следует ограничить передачу данных только быстрыми субпотоками, оставляя другие на случай отказа.

5.4. Сигнализация

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

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

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

Опции TCP являются традиционным методом сигнализации для TCP.
Опции TCP в SYN обеспечивают конечным хостам наиболее совместимый способ указать поддержку MPTCP.
При передаче ACK для соединения в данных (payload) они могут пропадать при потере пакетов или подвергаться влиянию контроля перегрузок, что может влиять на пропускную способность данных от отправителя и приводить к блокировке head-of-line.
Промежуточные устройства (например, трансляторы NAT) легко разбирают опции TCP (скажем, меняют адреса).

С другой стороны, основными недостатками опций TCP по сравнению с кодированием TLV в данных являются:

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

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

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

5.5. Управление путями

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

Таким образом, в большинстве случаев будет использоваться множество адресных пар (отправитель, получатель) в качестве селекторов путей. Однако каждый путь будет указываться стандартным квинтетом, включающим адреса и номера портов отправителя и получателя, а также номер протокола, что позволяет MPTCP использовать в качестве селекторов пути адреса и номера портов. Это позволяет хостам распределять нагрузку в MPTCP по номерам портов, например, при их маршрутизации по разным путям (что может обеспечиваться такими технологиями, как ECMP⁸ [4]). Однако следует отметить, что ISP часто используют организацию трафика для оптимизации ресурсов в своих сетях, поэтому следует проявлять осторожность (как разработчикам, так и ISP), чтобы в MPTCP не применялись практически совпадающие пути.

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

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

5.6. Идентификация соединений

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

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

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

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

5.7. Контроль перегрузок

Как отмечено в требования к совместимости на сетевом уровне параграфа 2.2.3, для алгоритма контроля перегрузок в MPTCP имеется 3 цели — повышение пропускной способности (не хуже одиночного соединения TCP), отсутствие помех для других пользователей сети (использование на любом пути не больше пропускной способности, чем получит отдельный поток на этом маршруте, что особенно важно для общих «пробочных» участков) и балансирование загрузки путем переноса трафика с наиболее насыщенных путей. Для достижения этих целей алгоритмы контроля перегрузок каждого потока должны быть связаны между собой. Подходящие алгоритмы предложены в [7].

5.8. Безопасность

Подробный анализ угроз для Multipath TCP представлен в [12]. Этот документ рассматривает лавинные рассылки и атаки с захватом, которые могут быть использованы против соединений Multipath TCP.

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

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

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

Были развернуты дополнительные механизма (как часть стандартных стеков TCP) для обеспечения устойчивости к DoS-атакам⁹. Например, имеются различные механизмы для защиты от атак со сбросом TCP [18] и Multipath TCP следует поддерживать такую защиту. Разработан механизм TCP SYN Cookie [19], позволяющий серверу TCP отложить создание соединения в состоянии SYN_RCVD и оставаться без состояния до перехода в ESTABLISHED. Multipath TCP следует в идеальном случае поддерживать такую функциональность или хотя бы избегать значительных вычислений до перехода в состояние ESTABLISHED (для всего соединения Multipath TCP).

Следует отметить, что аспекты пространства разработки Multipath TCP вносят ограничения для защитных решений:

использование опций TCP существенно ограничивает передаваемую при согласовании информацию;
необходимость работы через промежуточные устройства требует обработки изменяемых пакетов;
желание поддержать подходы break-before-make¹⁰ и make-before-break¹¹ при добавлении субпотоков (в ограниченный срок) предполагает, что хост не может полагаться на использование уже имеющегося субпотока для поддержки добавления нового.

Протокол MPTCP будет разрабатываться с учетом требований безопасности и спецификация [5] будет документировать их выполнение.

6. Программные взаимодействия

6.1. Взаимодействие с приложениями

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

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

TCP имеет возможность отправки срочных (Urgent) данных, доставка которых приложению может (не обязательно) обеспечиваться по отдельному каналу (out-of-band). Использовать эту возможность не рекомендуется по причине ее влияния на безопасность и различий в реализациях [20]. MPTCP требует непрерывных данных для поддержки отображения их последовательности на множество сегментов, поэтому указатель Urgent не может прерывать имеющееся отображение. Реализация MPTCP может поддерживать отправку срочных данных и в этом случае ей следует отправлять такие данные в ближайшем доступном не выделенном пространстве номеров субпотока. Входящие срочные данные следует отображать на номера в соединении и доставлять приложению как в TCP.

6.2. Взаимодействие с системами управления

Для обеспечения взаимодействия между TCP и системами управления сетью были определены базы MIB TCP [21] и TCP Extended Statistics (ESTATS) [22]. MPTCP следует использовать эти MIB для аспектов, которые должны быть прозрачны для приложений.

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

7. Взаимодействие с промежуточными устройствами

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

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

Multipath TCP будет развертываться в сети, которая уже не просто обеспечивает доставку дейтаграмм. В сети имеется огромное число промежуточных устройств для оптимизации и смягчения различных проблем, связанных с протоколами Internet — трансляторы NAT решают проблему нехватки адресов IP [15], прокси для повышения производительности (Performance Enhancing Proxy или PEP) оптимизируют TCP для различных каналов [17], МСЭ [16] и системы детектирования вторжений пытаются блокировать вредоносное содержимое от попадания на хосты, а нормализаторы трафика [23] обеспечивают согласованное представление потоков трафика в системах детектирования вторжений (Intrusion Detection System или IDS) и на хостах.

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

Ниже перечислены классы промежуточных устройств с указанием поведения, которое может влиять на применение MPTCP. Этот список применяется в [5] для описания свойств протокола MPTCP, служащих для снижения влияния промежуточных устройств.

NAT (Network Address Translator) — транслятор сетевых адресов

Отвязывает локальный IP-адрес хоста (в случае NAPT и номер порта) от адреса, появляющегося в Internet при прохождении пакетов через NAT. Это усложняет работу и снижает шансы на успех при передаче адресов IP.

PEP (Performance Enhancing Proxy) — прокси для повышения производительности

Служат для повышения производительности протоколов при работе по каналам с низкой производительностью (например, с высокой задержкой или большими потерями). В результате соединения TCP могут «расщепляться» с возникновением таких явлений, как упреждающие ACK, что не гарантирует прямого взаимодействия между хостами. PEP, МСЭ и другие промежуточные устройства могут также изменять объявленный размер окна приема.

Traffic Normalizer — нормализатор трафика

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

Firewall — межсетевой экран

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

IDS (Intrusion Detection System) — система детектирования вторжений

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

МСЭ с проверкой содержимого

Некоторые промежуточные устройства могут менять содержимое пакетов, включая переписывание URI в HTTP.

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

Опции TCP

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

Сегментация и объединение

Промежуточные устройства (иной раз достаточно близкие к конечным хостам, как в случае TSO (TCP Segmentation Offloading) на сетевых адаптерах (Network Interface Card или NIC) могут менять границы пакетов по сравнению с заданными отправителем. Это может выполняться путем расщепления или объединения пакетов. В результате возникает два основных эффекта — границы пакетов не могут гарантироваться и поведение промежуточных устройств применительно к опциям TCP в таких случаях нельза предсказать точно (пакеты могут повторяться, отбрасываться или передаваться лишь однократно).

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

Авторы признательны Andrew McDonald и Bryan Ford за их вклад в документ.

Авторы также благодарны за детальное рецензирование Olivier Bonaventure, Gorry Fairhurst, Iljitsch van Beijnum, Philip Eardley, Michael Scharf, Lars Eggert, Cullen Jennings, Joel Halpern, Juergen Quittek, Alexey Melnikov, David Harrington, Jari Arkko и Stewart Bryant.

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

Alan Ford, Costin Raiciu, Mark Handley и Sebastien Barre поддерживались в рамках исследовательского проекта Trilogy (http://www.trilogy-project.org, ICT-216372), частично финансируемого Европейской комиссией в рамках программы Seventh Framework. Выраженные здесь мнения принадлежат лишь авторам и Европейская комиссия не несет ответственности за любое использование представленной в документе информации.

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

Этот информационный документ содержит обзор архитектуры Multipath TCP и сам по себе не вызывает проблем безопасности. В отдельном документе [12] приведен анализ угроз, которые могут возникать при использовании Multipath TCP. Однако к протоколу, основанному на описанной в документе архитектуре, будет предъявляться много требований безопасности. Высокоуровневые цели для такого протокола указаны в параграфе 2.3, а параграф 5.8 содержит более подробное рассмотрение требований безопасности и проектных решений, применимых при разработке протокола MPTCP [5].

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

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

[1] Postel, J., «Transmission Control Protocol», STD 7, RFC 793, September 1981.

[2] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, March 1997.

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

[3] Wischik, D., Handley, M., and M. Bagnulo Braun, «The Resource Pooling Principle», ACM SIGCOMM CCR vol. 38 num. 5, pp. 47-52, October 2008, <http://ccr.sigcomm.org/online/files/p47-handleyA4.pdf>.

[4] Hopps, C., «Analysis of an Equal-Cost Multi-Path Algorithm», RFC 2992, November 2000.

[5] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, «TCP Extensions for Multipath Operation with Multiple Addresses», Work in Progress¹², March 2011.

[6] Stewart, R., «Stream Control Transmission Protocol», RFC 4960, September 2007.

[7] Raiciu, C., Handley, M., and D. Wischik, «Coupled Congestion Control for Multipath Transport Protocols», Work in Progress¹³, March 2011.

[8] Scharf, M. and A. Ford, «MPTCP Application Interface Considerations», Work in Progress¹⁴, March 2011.

[9] Carpenter, B. and S. Brim, «Middleboxes: Taxonomy and Issues», RFC 3234, February 2002.

[10] Carpenter, B., «Internet Transparency», RFC 2775, February 2000.

[11] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, «TCP Selective Acknowledgment Options», RFC 2018, October 1996.

[12] Bagnulo, M., «Threat Analysis for TCP Extensions for Multipath Operation with Multiple Addresses», RFC 6181, March 2011.

[13] Becke, M., Dreibholz, T., Iyengar, J., Natarajan, P., and M. Tuexen, «Load Sharing for the Stream Control Transmission Protocol (SCTP)», Work in Progress, December 2010.

[14] Ford, B. and J. Iyengar, «Breaking Up the Transport Logjam», ACM HotNets, October 2008.

[15] Srisuresh, P. and K. Egevang, «Traditional IP Network Address Translator (Traditional NAT)», RFC 3022, January 2001.

[16] Freed, N., «Behavior of and Requirements for Internet Firewalls», RFC 2979, October 2000.

[17] Border, J., Kojo, M., Griner, J., Montenegro, G., and Z. Shelby, «Performance Enhancing Proxies Intended to Mitigate Link-Related Degradations», RFC 3135, June 2001.

[18] Ramaiah, A., Stewart, R., and M. Dalal, «Improving TCP’s Robustness to Blind In-Window Attacks», RFC 5961, August 2010.

[19] Eddy, W., «TCP SYN Flooding Attacks and Common Mitigations», RFC 4987, August 2007.

[20] Gont, F. and A. Yourtchenko, «On the Implementation of the TCP Urgent Mechanism», RFC 6093, January 2011.

[21] Raghunarayan, R., «Management Information Base for the Transmission Control Protocol (TCP)», RFC 4022, March 2005.

[22] Mathis, M., Heffner, J., and R. Raghunarayan, «TCP Extended Statistics MIB», RFC 4898, May 2007.

[23] Handley, M., Paxson, V., and C. Kreibich, «Network Intrusion Detection: Evasion, Traffic Normalization, and End-to-End Protocol Semantics», Usenix Security 2001, 2001, <http://www.usenix.org/events/sec01/full_papers/handley/handley.pdf>.

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

Alan Ford

Roke Manor Research

Old Salisbury Lane

Romsey, Hampshire SO51 0ZN

Phone: +44 1794 833 465

EMail: alan.ford@roke.co.uk

Costin Raiciu

University College London

Gower Street

London WC1E 6BT

EMail: c.raiciu@cs.ucl.ac.uk

Mark Handley

University College London

Gower Street

London WC1E 6BT

EMail: m.handley@cs.ucl.ac.uk

Sebastien Barre

Universite catholique de Louvain

Pl. Ste Barbe, 2

Louvain-la-Neuve 1348

Belgium

Phone: +32 10 47 91 03

EMail: sebastien.barre@uclouvain.be

Janardhan Iyengar

Franklin and Marshall College

Mathematics and Computer Science

PO Box 3003

Lancaster, PA 17604-3003

USA

Phone: 717-358-4774

EMail: jiyengar@fandm.edu

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

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

1Internet Engineering Task Force.

2Internet Engineering Steering Group.

3Equal Cost MultiPath — множество равноценных путей.

4Stream Control Transmission Protocol — протокол управления передачей потоков.

5Межсетевой экран — firewall.

6Разрыв до создания.

7Transport next-generation — следующее поколение транспорта.

8Equal-Cost Multipath — множество равноценных путей.

9Denial-of-Service — отказ в обслуживании.

10Прервать до создания.

11Создать до прерывания.

12Работа опубликована в RFC 6824, замененном RFC 8684. Прим. перев.

13Работа опубликована в RFC 6356. Прим. перев.

14Работа опубликована в RFC 6897. Прим. перев.

Рубрика: RFC | Комментарии отключены

RFC 6091 Using OpenPGP Keys for Transport Layer Security (TLS) Authentication

Опубликовано 16.02.2011 автором Nikolai Malykh

Internet Engineering Task Force (IETF)          N. Mavrogiannopoulos
Request for Comments: 6091                                       KUL
Obsoletes: 5081                                           D. Gillmor
Category: Informational                                  Independent
ISSN: 2070-1721                                        February 2011

Использование ключей OpenPGP для аутентификации TLS

Using OpenPGP Keys for Transport Layer Security (TLS) Authentication

Аннотация

Этот документ определяет расширение TLS¹ и связанную с ним семантику, позволяющие клиентам и серверам согласовывать использование сертификатов OpenPGP для сессий TLS, а также задает способ доставки сертификатов OpenPGP через TLS. Документ также определяет реестр для сертификатов, отличных от X.509 типов.

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

Этот документ не является проектом стандарта Internet и публикуется с информационной целью.

Документ является результатом работы IETF и выражает согласованное мнение сообщества IETF. Документ был представлен на публичное рассмотрение и одобрен для публикации IESG. Не все одобренные IESG документы являются проектами стандартов Internet (см. раздел 2 RFC 5741).

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

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

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

1. Введение

IETF имеет два набора стандартов для сертификатов открытых ключей — один использует сертификаты X.509 [RFC5280], а другой — OpenPGP [RFC4880]. Ко времени подготовки этого документа были определены стандарты TLS [RFC5246] для использования сертификатов X.509. Данный документ задает способ согласования использования сертификатов OpenPGP для сессий TLS, а также способ доставки сертификатов OpenPGP с использованием TLS. Предложенные расширения обеспечивают совместимость с существующей спецификацией TLS, поэтому имеющиеся реализации клиентов и серверов, применяющие сертификаты X.509, не затрагиваются этим документом.

Предлагаемые расширения не обеспечивают совместимости с [RFC5081]; основные различия рассмотрены в Приложении A. Хотя значение CertificateType в OpenPGP, используемое в этом документе, совпадает с заданным в [RFC5081], семантика использования отличается. Авторы предполагают, что это различие не вызовет проблем совместимости, поскольку реализации [RFC5081] не получили широкого распространения.

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

Термин «ключ OpenPGP» используется в этом документе в соответствии со спецификацией OpenPGP [RFC4880]. Для ключей OpenPGP, которые допускается использовать для аутентификации, служит термин «сертификат OpenPGP».

В этом документе используется такая же нотация и терминология, как в спецификации протокола TLS [RFC5246].

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

3. Изменение содержимого сообщений Handshake

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

3.1. Клиентское сообщение Hello

Для индикации поддержки множества типов сертификатов клиенты должны включать расширение типа cert_type в расширенное приветственное сообщение (Hello). Расширению TLS cert_type присвоено значение 9 в реестре TLS ExtensionType. Это значение используется в качестве номера расширения для расширений в приветственных сообщениях клиента и сервера. Механизм расширения hello описан в [RFC5246].

Это расширение передает список поддерживаемых типов сертификатов, которые клиент может использовать, отсортированных по уровню предпочтения. Это расширение должно опускаться, если клиент поддерживает только сертификаты X.509. Поле extension_data в этом расширении содержит структуру CertificateTypeExtension. Отметим, что структура CertificateTypeExtension используется как клиентом, так и сервером, хотя она описана в документе только один раз. Повторное использование однократно заданной спецификации на клиентской и серверной стороне является общепринятой практикой для спецификаций (в частности, для протокола TLS [RFC5246]).

      enum { client, server } ClientOrServerExtension;

      enum { X.509(0), OpenPGP(1), (255) } CertificateType;

      struct {
         select(ClientOrServerExtension) {
            case client:
               CertificateType certificate_types<1..2^8-1>;
            case server:
               CertificateType certificate_type;
         }
      } CertificateTypeExtension;

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

3.2. Серверное сообщение Hello

Если сервер получает клиентское сообщение hello, которое содержит расширение cert_type и выбирает шифр, который требует сертификат, возможны два варианта. Сервер должен выбрать тип сертификата из поля certificate_types в расширенном приветствии клиента или разорвать сеанс с критическим сигналом типа unsupported_certificate².

Выбранный сервером тип сертификата представляется в структуре CertificateTypeExtension, которая включается в расширенное сообщение hello от сервера с использованием расширения типа cert_type. Серверы, поддерживающие только сертификаты X.509, могут не включать расширение cert_type в расширенное сообщение hello.

3.3. Сертификат сервера

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

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

Алгоритм обмена ключами	Тип сертификата OpenPGP
RSA	Открытый ключ RSA, который может использоваться для шифрования.
DHE_DSS	Открытый ключ DSA, который может использоваться для аутентификации.
DHE_ RSA	Открытый ключ RSA, который может использоваться для аутентификации.

Сертификат OpenPGP, появляющийся в сообщении, передается с использованием двоичного формата OpenPGP. Сертификат должен содержать все элементы, требуемые параграфом 11.1 [RFC4880].

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

Доступна также опция для передачи оттиска OpenPGP взамен передачи сертификата целиком (с помощью тега subkey_cert_fingerprint). Этот тег использует структуру OpenPGPSubKeyFingerprint и требует задания оттиска первичного ключа, а также идентификатора субключа для использования в данной сессии. Партнер будет отвечать критическим сигналом certificate_unobtainable, если сертификат с данным оттиском не будет найден. Критический сигнал certificate_unobtainable определен в разделе 5 [RFC6066].

Реализации этого протокола должны гарантировать, что размеры идентификаторов субключей и оттисков в структурах OpenPGPSubKeyCert и OpenPGPSubKeyFingerprint соответствуют требованиям [RFC4880]. Кроме того, рекомендуется для ключей, используемых с этим протоколом, устанавливать флаг аутентификации (0x20).

Процесс генерации оттисков описан в параграфе 12.2 [RFC4880].

Перечисляемые типы cert_fingerprint и cert структуры OpenPGPCertDescriptorType, которые были определены в [RFC5081], больше не используются и отменяются данным документом. Тип empty_cert, введенный взамен cert, обеспечивает совместимый с прежней версией способ задания пустого сертификата; использование cert_fingerprint недопустимо в соответствии с обновленной спецификацией и, следовательно, старый вариант был удален из описания структуры Certificate.

      enum {
           empty_cert(1),
           subkey_cert(2),
           subkey_cert_fingerprint(3),
           (255)
      } OpenPGPCertDescriptorType;

      uint24 OpenPGPEmptyCert = 0;

      struct {
          opaque OpenPGPKeyID<8..255>;
          opaque OpenPGPCert<0..2^24-1>;
      } OpenPGPSubKeyCert;

      struct {
          opaque OpenPGPKeyID<8..255>;
          opaque OpenPGPCertFingerprint<20..255>;
      } OpenPGPSubKeyFingerprint;

      struct {
           OpenPGPCertDescriptorType descriptorType;
           select (descriptorType) {
                case empty_cert: OpenPGPEmptyCert;
                case subkey_cert: OpenPGPSubKeyCert;
                case subkey_cert_fingerprint:
                    OpenPGPSubKeyCertFingerprint;
           }
      } Certificate;

3.4. Запрос сертификата

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

3.5. Сертификат клиента

Это сообщение передается только в ответ на сообщение с запросом сертификата. Сообщение с сертификатом клиента передается с использованием такого же форматирования, которое служит для сообщений с сертификатом сервера, и также требуется присутствие сертификата, который соответствует согласованному типу. Если были выбраны сертификаты OpenPGP, а у клиента нет нужного сертификата, должна передаваться структура сертификата типа empty_cert, которая содержит значение OpenPGPEmptyCert. Серверу в таком случае следует отвечать критическим сигналом handshake_failure, если требуется аутентификация клиента.

3.6. Другие сообщения Handshake

Все остальные согласующие сообщения идентичны заданным в спецификации TLS.

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

Все вопросы безопасности, рассмотренные в [RFC5246], [RFC6066] и [RFC4880], применимы к настоящему документу. Вопросы использования «сети доверия» (web of trust) или верификации тождественности и сертификатов выходят за пределы данного документа. Здесь рассматриваются задачи, обрабатываемые протоколами прикладного уровня.

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

Для случая использования оттисков OpenPGP взамен полных сертификатов применимо обсуждение раздела 5 [RFC6066] для «URL сертификата клиента», особенно при использовании внешних серверов для нахождения ключей. Однако основное различие заключается в том, что расширение client_certificate_url хотя и позволяет идентифицировать сертификаты без включения их хэш-сумм, это невозможно для предложенного здесь использования протокола. В данном протоколе сертификаты, если они не передаются, всегда идентифицируются по их оттискам, которые служат в качестве криптографических хэш-сумм для сертификатов (см. параграф 12.2 [RFC4880]).

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

5. Согласование с IANA

Этот документ использует реестр cert_type, определенный в [RFC5081]. Имеющиеся в IANA ссылки были обновлены и указывают на настоящий документ.

В дополнение к этому реестр TLS Certificate Types, организованный [RFC5081] был обновлен, как показано ниже.

В данном документе определены значения 0 (X.509) и 1 (OpenPGP).
Значения из диапазона 2 — 223, включительно, выделяются в соответствии с процедурой RFC Required [RFC5226].
Значения из диапазона 224 — 255, включительно, зарезервированы для приватного использования [RFC5226].

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

Авторы хотят выразить благодарность Alfred Hoenes и Ted Hardie за их предложения по улучшению данного документа.

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

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

[RFC2119] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, March 1997.

[RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. Thayer, «OpenPGP Message Format», RFC 4880, November 2007.

[RFC5226] Narten, T. and H. Alvestrand, «Guidelines for Writing an IANA Considerations Section in RFCs», BCP 26, RFC 5226, May 2008.

[RFC5246] Dierks, T. and E. Rescorla, «The Transport Layer Security (TLS) Protocol Version 1.2», RFC 5246, August 2008.

[RFC6066] Eastlake 3rd, D., «Transport Layer Security (TLS) Extensions: Extension Definitions», RFC 6066, January 2011.

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

[RFC5081] Mavrogiannopoulos, N., «Using OpenPGP Keys for Transport Layer Security (TLS) Authentication», RFC 5081, November 2007.

[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, May 2008.

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

Этот документ включает существенные изменения сообщений TLS «Server Certificate» и «Client Certificate», что делает реализации данного протокола несовместимыми с реализациями [RFC5081]. Эти изменения требуют явной маркировки идентификаторов субключей, используемых для аутентификации TLS, в процедуре согласования. Это было сделано для того, чтобы не вносить ограничений на содержимое сертификатов OpenPGP, которые могут применяться в данном протоколе.

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

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

Nikos Mavrogiannopoulos

ESAT/COSIC Katholieke Universiteit Leuven

Kasteelpark Arenberg 10, bus 2446

Leuven-Heverlee, B-3001

Belgium

EMail: nikos.mavrogiannopoulos@esat.kuleuven.be

Daniel Kahn Gillmor

Independent

119 Herkimer St.

Brooklyn, NY 11216-2801

EMail: dkg@fifthhorseman.net

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

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

1Transport Layer Security — защита на транспортном уровне.

2Неподдерживаемый сертификат.

Рубрика: RFC | Оставить комментарий

RFC 6110 Mapping YANG to Document Schema Definition Languages and Validating NETCONF Content

Опубликовано 11.02.2011 автором Nikolai Malykh

Internet Engineering Task Force (IETF)                    L. Lhotka, Ed.
Request for Comments: 6110                                        CESNET
Category: Standards Track                                  February 2011
ISSN: 2070-1721

Mapping YANG to Document Schema Definition Languages and Validating NETCONF Content

Сопоставление YANG с языками DSDL и проверка содержимого NETCONF

Аннотация

Этот документ задаёт правила отображения моделей данных YANG в языки определения схемы документа (Document Schema Definition Languages или DSDL) — скоординированный набор языков схем XML, стандартизованный как ISO/IEC 19757. Рассмотрены сопоставления с языками Regular Language for XML Next Generation (RELAX NG), Schematron и Document Schema Renaming Language (DSRL). Отображение принимает один или несколько модулей YANG и создаёт набор схем DSDL для выбранного типа целевого документа — хранилища содержимого сообщения протокола настройки сети (Network Configuration Protocol или NETCONF) и т. п. Рассмотрены также процедуры проверки таких документов на основе схем.

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

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

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

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

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

1. Введение

Рабочая группа NETCONF завершила спецификацию базового протокола управления конфигурацией [RFC4741]. Эта спецификаци задаёт протокольные привязки и синтаксис контейнеров XML для операций настройки и управления, но не включает язык моделирования данных или соответствующие правила для передачи модели конфигурации и данных состояния протоколом NETCONF. Направление IETF Operations Area имеет давние традиции определения данных для модулей баз управляющей информации (Management Information Bases или MIB) [RFC1157] простого протокола управления сетью Simple Network Management Protocol или SNMP) с использованием языка структур управляющей информации (Structure of Management Information или SMI) [RFC2578] для моделирования данных. Хотя такой подход к моделирования имеет множество известных проблем, большая часть функций моделирования данных в SMI по-прежнему считается очень важной. Простое моделирование допустимого синтаксиса бех дополнительных семантических связей в прошлом вызывало многочисленные проблемы совместимости.

Сообщество NETCONF пришло к выводу о необходимости схемы моделирования данных для поддержки текущих разработок IETF и задаваемых производителями модулей управляющей информации. Была создана рабочая группа NETMOD для разработки языка моделирования, определяющего семантику рабочих данных, уведомлений о событиях и операций с упором на удобство для человека, т. е. удобочитаемость и простоту использования. Результатом стал язык моделирования данных YANG [RFC6020], который сейчас служит для нормативного описания моделей данных NETCONF.

Поскольку NETCONF использует XML для кодирования своих сообщений, естественно выражать ограничения на содержимое NETCONF с помощью стандартных языков схем XML. Для этого рабочая группа NETMOD WG выбрала DSDL, стандартизированные как ISO/IEC 19757 [DSDL]. Платформа DSDL включает набор языков схем XML, учитывающих правила грамматики, семантические ограничения и другие аспекты моделирования данных, делая это согласованным и скоординированным способом, что очень важно. Хотя некоторые части DSDL ещё не стандартизованы и работа продолжается, три части, на которые опирается сопоставление YANG-DSDL — Regular Language for XML Next Generation (RELAX NG), Schematron и Document Schema Renaming Language (DSRL) — уже имеют статус ISO/ IEC International Standard и поддерживаются множеством программных инструментов.

Этот документ содержит спецификацию отображения, которое транслирует модели данных YANG в схемы XML с применением подмножества языков схем DSDL. Процедура сопоставления делится на два шага. Сначала структура дерева данных, подписи удалённых вызовов процедур (remote procedure call или RPC) и уведомления выражаются в так называемой гибридной схеме — одной схеме RELAX NG с аннотациями, представляющими дополнительные сведения модели данных (метаданные, документацию, семантические ограничения, принятые по умолчанию значения и т. п.). На втором шаге создаётся скоординированный набор схем DSDL, которые можно использовать для проверки конкретных документов XML, таких как запросы клиентов или уведомления, возможно, с учётом дополнительного контекста, такого как активные возможности или функции.

2. Термины и обозначения

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

Ниже перечислены термины, заданные в [RFC4741]:

client — клиент;
datastore — хранилище данных;
message — сообщение;
operation — операция;
server — сервер.

Ниже перечислены термины, заданные в [RFC6020]:

augment — дополнение;
base type — базовый тип;
built-in type — встроенный тип;
configuration data — данные конфигурации;
container — контейнер;
data model — модель данных;
data node — узел данных;
data tree — дерево данных;
derived type — производный тип;
device deviation — отклонение устройства;
extension — расширение;
feature — свойство, функция;
grouping — группировка;
instance identifier — идентификатор экземпляра;
leaf-list — лист-список;
list — список;
mandatory node — обязательный узел;
module — модуль;
RPC — удаленный вызов процедуры;
RPC operation — операция RPC;
schema node — узел схемы;
schema tree — дерево схемы;
state data — данные состояния;
submodule — субмодуль;
top-level data node — узел данных верхнего уровня;
uses — использует.

Ниже перечислены термины, заданные в [XML-INFOSET]:

attribute — атрибут;
document — документ;
document element — элемент документа;
document type declaration (DTD) — объявление типа документа;
element — элемент;
information set — набор информации;
namespace — пространство имён.

В тексте применяются перечисленные ниже типографические соглашения:

ключевые слова операторов YANG указываются в одинарных кавычках³;
имена элементов XML указываются в угловых скобках <>;
имена атрибутов XML указываются с префиксом @;
иные буквальные значения указываются в двойных кавычках¹.

Имена элементов XML всегла указываются с явным префиксом пространства имён, соответствующим указанным ниже словарям:

a — аннотации совместимости DTD [RNG-DTD];

dc — элементы метаданных Dublin Core [RFC5013];

dsrl — язык переименования семантики документов (Document Semantics Renaming Language) [DSRL];

en — уведомления NETCONF о событиях [RFC5277];

nc — протокол NETCONF [RFC4741];

nma — относящиеся к NETMOD аннотации схем (5.3. Связанные с NETMOD аннотации);

nmf — относящиеся к NETMOD функции расширения языка путей XML (XML Path Language или XPath) (12.7. Аннотация <nma:instance-identifier>);

rng — RELAX NG [RNG];

sch — ISO Schematron [Schematron];

xsd — W3C XML Schema [XSD].

В таблице 1 указаны сопоставления этих префиксов с URI пространств имён.

Таблица 1. Префиксы и URI пространств имен.

Префикс	URI пространства имен
a	http://relaxng.org/ns/compatibility/annotations/1.0
dc	http://purl.org/dc/terms
dsrl	http://purl.oclc.org/dsdl/dsrl
en	urn:ietf:params:xml:ns:netconf:notification:1.0
nc	urn:ietf:params:xml:ns:netconf:base:1.0
nma	urn:ietf:params:xml:ns:netmod:dsdl-annotations:1
nmf	urn:ietf:params:xml:ns:netmod:xpath-extensions:1
rng	http://relaxng.org/ns/structure/1.0
sch	http://purl.oclc.org/dsdl/schematron
xsd	http://www.w3.org/2001/XMLSchema

2.1. Новые термины

ancestor data type — тип данных предка

Любой тип данных из которого (транзитивно) выведен этот тип.

ancestor built-in data type — встроенный тип данных предка

Встроенный тип, с которого начинается цепочка производных типов для этого типа данных.

hybrid schema — гибридная схема

Схема RELAX NG с аннотациями, которая содержит те же сведения, что и исходный модуль или модулия YANG (8.1. Гибридная схема).

implicit node — неявный узел

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

3. Цели и мотивация

Основной целью этой работы является дополнение языка моделирования данных YANG возможностями проверки языков схем DSDL — RELAX NG, Schematron, DSRL. Документ описывает соответствия между грамматикой, семантикой и ограничениями типов данных в YANG и эквивалентными шаблонами и правилами DSDL. Конечной целью является возможность сбора всех значимых сведений из модулей YANG и их представления в схемах DSDL. Хотя отображение YANG в DSDL, описанное в документе, в принципе может быть обратимым, отображение DSDL в YANG выходит за рамки этого документа.

Основанные на XML модели данных и кодирование данных в XML присутствуют в нескольких формах на разных этапах моделирования YANG и рабочего процесса NETCONF — содержимое хранилищ данных конфигурации, запросы и отклики RPC, уведомления. Кроме того, операции RPC отличаются разнообразием, обусловленным выборочной доступностью возможностей и функций. Модули YANG могут определять новые операции RPC. Отображениям следует поддерживать такую изменчивость и создавать схемы, адаптированные к конкретной ситуации и поэтому более эффективные для проверки, нежели базовые всеобъемлющие схемы. Для охвата такой изменчивости предлагается генерировать схемы DSDL по запросам для конкретной задачи из доступного набора модулей YANG. Жихненный цикл таких схем будет сравнительно коротким, иными словами, не предполагается, что какой-либо набор схем DSDL будет создаваться для долгосрочной поддержки вместе с модулями YANG.

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

На первом этапе 1 или несколько модулей YANG отображается в так называемую гибридную схему, которая представляет собой одну схему RELAX NG, описывающую грамматические ограничения для основного дерева данных, а также операций RPC и уведомлений. Семантические ограничения и другие сведения из входных модулей YANG записываются в гибридную схему в форме аннотаций внешних пространств имён. Вывод этого этапа можно считать практически полным эквивалентом входных модулей YANG. Однако он не подходит напрямую для какой-либо проверки.
На втором этапе полученная гибридная схема преобразуется в согласованный набор схем DSDL, содержащих ограничения для конкретных объектов данных и ситуаций. Эти схемы DSDL предназначены, прежде всего, для машинной проверки с использованием готовых инструментов.

4. Языки схем DSDL

DSDL — это набор языков схем, разрабатываемых как международный стандарт ISO/IEC 19757 [DSDL]. В отличие от других подходов к проверке документов XML, прежде всего W3C XML Schema Definition (XSD) [XSD], модель DSDL придерживается принципа «малых языков» — каждый компонент DSDL представляет собой законченный язык схем с относительно небольшой сферой применения (назначением). Совместно эти языки можно применять для согласованного решения различных задач проверки.

Описанное в этом документе отображение использует три языка схем DSDL — RELAX NG [RNG], Schematron [Schematron], DSRL [DSRL].

4.1. RELAX NG

RELAX NG (произносится как relaxing) — это язык схем XML для основанной на грамматике проверки и часть 2 в семействе стандартов ISO/IEC DSDL [RNG]. Подобно XSD, он может описывать ограничения для структуры и содержимого документов XML. Однако, в отличие от языков схем DTD [XML] и XSD, язык RELAX NG намеренно избегает каких-либо дополнений, вроде задания принятых по умолчанию значений. default values. В архитектуре DSDL конкретная задача определения и применения принятых по умолчанию значения отдана доугому языку описания схем — DSRL (4.3. DSRL).

В качестве базовой библиотеки типов данных RELAX NG использует W3C XML Schema Datatypes [XSD-D], но в отличие от XSD, можно применять и другие библиотеки типов совместно с этой библиотеков или вместо неё.

Язык RELAX NG свободно воспринимает аннотации из других пространств имён. С некоторыми исключениями такие аннотации могут помещаться в любое место схемы и не требуют инкапсулирующих элементов, таких как <xsd:annotation> в XSD.

Схемы RELAX NG можно представлять в двух вариантах — компактном и XML. Компактный синтаксис описан в Приложении C к спецификации RELAX NG [RNG-CS], добавленной в стандарт в 2006 г. (Amendment 1). Автоматические двухсторонние преобразования между двумя вариантами синтаксиса возможны с использованием нескольких инструментов, например, Trang [Trang].

Лаконичность и удобочитаемость компактного синтаксиса часто делают его предпочтительным для публикации схем RELAX NG, тогда как средства проверки и другие программные инструменты обычно работают с синтаксисом XML. Однако компактный синтаксис имеет два недостатка.

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

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

Элементы RELAX NG связаны с URI пространства имён http://relaxng.org/ns/structure/1.0. Пространство имён библиотеки типов данных XSD доступно по ссылке http://www.w3.org/2001/XMLSchema-datatypes.

4.2. Schematron

Schematron — это часть 3 DSDL, стандартизованная ISO/IEC в 2006 г. [Schematron]. В отличие от традиционных языков схем, таких как DTD, XSD, RELAX NG, которые основаны на формальной грамматике, Schematron использует основанный на правилах подход. Правила могут задавать произвольные условия, включающие данные из разных частей документа XML. Каждое правило состоит из трёх основных компонентов:

контекст — выражение XPath, определяющее набор мест, где правило должно применяться;
условие утверждения или отчёта — другое выражение XPath, оцениваемое в месте применения правила;
понятное человеку сообщение, которое выводится при несоблюдении (false) условия утверждения или соблюдении (true) условия отчёта.

Разница между условиями утверждения и отчёта состоит в том, что первое выполняется, когда документ соответствует, а второе — когда возникает ошибка.

Большая часть выразительных средств Schematron взята и XPath [XPath] и XSLT⁴ [XSLT]. ISO допускает привязку языка динамических запросов для возможности применения языков запросов запросов XML — STX, XSLT 1.0, XSLT 1.1, EXSLT, XSLT 2.0, XPath 1.0, XPath 2.0, XQuery 1.0 (список может быть расширен в будущем).

Понятные человек сообщения об ошибках — ещё одно отличие Schematron от других языков схем. Сообщения могут даже включать выражения XPath, оцениваемые в фактическом контексте и таким образом указывающие элементы информации в проверяемом документе XML. Друго особенностью Schematron является применение при отображениях абстрактных шаблонов, которые, по сути, работают как макросы и могут иметь параметры, подставляемые в абстрактный шаблон. Элементы Schematron связаны с URI пространства имён http://purl.oclc.org/dsdl/schematron.

4.3. DSRL

Язык переименования семантики документа (Document Semantics Renaming Language или DSRL, произносится disrule) — это часть 8 DSDL, стандартизованная ISO/IEC в 2008 г. [DSRL]. В отличие от RELAX NG и Schematron, языку DSRL разрешено изменять набор сведений XML проверяемого документа. Хотя DSRL предназначен в основном для переименования элементов и атрибутов XML, он может определять принятые по умолчанию значения атрибутов XML и содержимого элементов XML или ветвей дерева со вставкой принятого по умолчанию содержимого, если его нет в проверяемом документе. Последнее свойство применяется в отображении YANG-DSDL для представления принятого по умолчанию содержимого YANG в виде листьев с принятыми по умолчанию значениями и из предков — контейнеров отсутствия (non-presence). Элементы DSRL связаны с URI пространства имён http://purl.oclc.org/dsdl/dsrl.

5. Дополнительные аннотации

Помимо языков схем DSDL сопоставление использует 3 набора аннотаций, добавляемых в схемы RELAX NG как атрибуты внешнего пространства имён и элементы. Два из этих наборов аннотаций — элементы Dublin Core и аннотации совместимости DTD — являются стандартными словарями для представления метаданных и документации, соответственно. Хотя эти элементы модели данных не подвергаются формальной проверке, они достаточно часто немут важные сведения для разработчиков модели данных. Поэтому их следует включать в гибридную схему и можно включать в схемы окончательной проверки. Третий набор образуют аннотации, относящиеся к NETMOD. Они предназначены для гибридных схем и содержат семантические ограничения и другие сведения, которые не могут быть напрямую выражены в RELAX NG. На втором этапе сопоставления ити аннотации преобразуются в правила Schematron и DSRL.

5.1. Элементы метаданных Dublin Core

Dublin Core — это система элементов метаданных, исходно предназначенная для описания метаданных ресурсов WWW с целью упрощения их поиска, а позднее принятая как стандарт описания метаданных произвольных ресурсов. В этой спецификации применяется определение из [RFC5013]. Элементы Dublin Core связаны с URI пространства имён http://purl.org/dc/terms.

5.2. Аннотации RELAX NG для совместимости DTD

Аннотации совместимости DTD являются частью спецификации the RELAX NG DTD Compatibility [RNG-DTD]. Отображение YANG-DSDL использует лишь аннотацию <a:documentation> для представления текста операторов YANG description и reference. Отметим, что нет намерения сделать полученные схемы DTD-совместимыми и основной причиной применения этих аннотаций является хорошая их поддержки и адекватное форматирование некоторыми инструментами RELAX NG. Аннотации совместимости DTD связаны с URI пространства имён http://relaxng.org/ns/compatibility/annotations/1.0.

5.3. Связанные с NETMOD аннотации

Специфические аннотации NETMOD являются элементами и атрибутами XML, связанными с URI пространства имён urn:ietf:params:xml:ns:netmod:dsdl-annotations:1 и присутствующие в разных местах гибридной схеиы. Операторы YANG сопоставляются с этими аннотациями напрямую. В большинстве случаев атрибуты и элементы аннотации имеют то же имя, что и соответствующий оператор YANG. В таблице 2 приведён список связанных с NETMOD атрибутов аннотаций (префикс @) и элементов (<>) со ссылками на параграфы с их описаниями. В Приложении A приведена схема RELAX NG для этого словаря аннотаций.

Таблица 2. Аннотации, связанные с NETMOD.

Аннотация	Параграф
@nma:config	10.9. Оператор config
<nma:data>⁵	8.1. Гибридная схема
@nma:default	10.12. Оператор default
<nma:error-app-tag>⁶	10.16. Оператор error-app-tag
<nma:error-message>²	10.17. Оператор error-message
@nma:if-feature	10.22. Оператор if-feature
@nma:implicit	10.11. Оператор container, 10.7. Оператор case, 10.12. Оператор default
<nma:input>¹	8.1. Гибридная схема
<nma:instance-identifier>⁷	10.53.7. Тип instance-identifier
@nma:key	10.26. Оператор key
@nma:leaf-list	10.28. Оператор leaf-list
@nma:leafref	10.53.8. Тип leafref
@nma:mandatory	10.8. Оператор choice
@nma:max-elements	10.28. Оператор leaf-list
@nma:min-elements	10.28. Оператор leaf-list
@nma:module	10.34. Оператор module
<nma:must>⁸	10.35. Оператор must
<nma:notification>¹	8.1. Гибридная схема
<nma:notifications>¹	8.1. Гибридная схема
@nma:ordered-by	10.38. Оператор ordered-by
<nma:output>¹	8.1. Гибридная схема
<nma:rpc>¹	8.1. Гибридная схема
<nma:rpcs>¹	8.1. Гибридная схема
@nma:status	10.51. Оператор status
<nma:unique>⁹	10.55. Оператор unique
@nma:units	10.56. Оператор units
@nma:when	10.59. Оператор when

6. Обзор сопоставления

В этом разделе дан обзор отображения YANG-DSDL (вход и выход). Общая структура приведена на рисунке 1

              +----------------+
              |  Модули YANG   |
              +----------------+
                       |
                       |T
                       |
     +------------------------------------+
     |          Гибридная схема           |
     +------------------------------------+
         /       |           |       \
      Tg/      Tr|           |Tn      \
       /         |           |         \
+---------+   +-----+    +-------+    +------+
|get reply|   | rpc |    | notif |    | .... |
+---------+   +-----+    +-------+    +------+

Рисунок 1. Структура отображения.

Процедура отображения делится на два этапа.

Преобразование T отображает 1 или несколько модулей YANG в гибридную схему (8.1. Гибридная схема). Ограничения, которые не выражаются напрямую в RELAX NG (определения ключей списков, must и т. п.) и документирующие тексты записываются в схему как аннотации внешних пространств имён.
На втором этапе гибридная схема может быть разными способами преобразована в набор схем DSDL, которые могут служить для проверки отдельных объектов данных в конкретном контексте. На рисунке 1 показаны в качестве примеров 3 простых возможности. В процессе преобразования извлекаются нужные части гибридной схемы, а конкретные аннотации преобразуются в эквивалентные, но обычно более сложные шаблоны Schematron, карты элементов DSRL и т. п.

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

Другие сведения из входных модулей YANG (такие как семантика ограничений и принятые по умолчанию значения) записываются в гибридную схему как аннотации — атрибуты или элементы XML, связанные с URI пространства имён urn:ietf:params:xml:ns:netmod:dsdl-annotations:1. Метаданные, описывающие модули YANG, отображаются в элементы аннотаций Dublin Core (5.1. Элементы метаданных Dublin Core), а строки документации — в элементы <a:documentation>, относящиеся к словарю соответствия DTD (5.2. Аннотации RELAX NG для совместимости DTD).

Выводом второго этапа является согласованный набор из трёх схем DSDL, соответствующих конкретному объекту данных и контексту:

схема RELAX NG описывает ограничения для грамматики и типов данных;
схема Schematron выражает другие ограничения, такие как неуникальность ключей списка, или заданные пользователем правила семантики;
схема DSRL содержит спецификации принятого по умолчанию содержимого.

7. Проверка содержимого NETCONF

В этом разделе описано, как схемы, созданные при отображении YANG-DSDL представляются для проверки экземпляров документов XML, таких как содержимое хранилищ данных или сообщения NETCONF. Этапы проверки показаны на рисунке 2.

+----------+                        +----------+
|          |                        | Документ |
| Документ |                        |   XML с  |
|   XML    |-----------o----------->|принятыми |
|          |           ^            | по умолч.|
|          |           |            |значениями|
+----------+           |            +----------+
     ^                 | Заполнение       ^
     | грамматика,     | принятых         | Семантические 
     | типы данных     | по умолчанию     | ограничения
     |                 | значений         |
+----------+       +--------+       +------------+
|  Схема   |       | Схема  |       |   Схема    |
| RELAX NG |       |  DSRL  |       | Schematron |
+----------+       +--------+       +------------+

Рисунок 2. Процедура проверки.

Экземпляр документа XML проверяется в плане грамматики и типов данных по схеме RELAX NG.

Применяются заданные по умолчанию значения листьев и при необходимости добавляются их контейнеры-предки. Важно добавить неявные узлы до следующей проверки, поскольку спецификация YANG [RFC6020] требует, чтобы в используемом при оценке выражения XPath были указаны все принятые по умолчанию значения. Отметим, что этот шаг меняет набор информации в проверяемом документе XML.
Проверяются семантические ограничения с использованием схемы Schematron.

8. Устройство

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

8.1. Гибридная схема

Как указано в разделе 6, первый этап сопоставления создаёт промежуточный документ — гибридную схему, задающую все ограничения для модели данных с использованием синтаксиса RELAX NG и дополнительных аннотаций. Её нельзя напрямую использовать для проверки и на деле это даже не будет действительной схемой RELAX NG, поскольку в документе будет несколько схем, разделённых элементами аннотаций.

Каждому входному модулю YANG соответствует один вложенный блок (grammar) гибридной схемы. Такое разделение входных модулей YANG позволяет в каждый вложенный блок включить определения именованных шаблонов со своим пространством имён, ччто важно для отображения группировок YANG (см. 9.2. Отображение группировок и определений типов YANG).

В дополнение к ограничениям грамматики и типов данных модули YANG предоставляют другие важные сведения, которые нельзя выразить в схеме RELAX NG — семантические ограничения, принятые по умолчанию значения, метаданные, документацию и т. п. Такая информация представляется в гибридной схеме атрибутами и элементами XML, относящимися к пространству имён с URI urn:ietf:params:xml:ns:netmod:dsdl-annotations:1. Полный список таких аннотаций приведён в параграфе 5.3, а правила их применения описаны ниже.

Модули YANG задают модели не только для данных конфигурации и состояния, но и для (множества) операций RPC [RFC4741] и/или уведомлений [RFC5277]. Чтобы зафиксировать все эти типы данных в одном документе схемы, в гибридной схеме применяются специальные маркеры, заключающие в себе субсхемы для данных конфигурации и состояния, отдельные операции RPC (вход и выход) и отдельные уведомления. В маркерах применяются указанные в таблице 3 элементы XML в пространстве имён связанных с NETMOD аннотаций (URI urn:ietf:params:xml:ns:netmod:dsdl-annotations:1).

Таблица 3. Элементы маркеров в гибридной схеме.

Имя элемента	Охват
nma:data	Данные конфигурации и состояния
nma:rpcs	Все операции RPC
nma:rpc	Отдельная операция RPC
nma:input	Запрос RPC
nma:output	Отклик RPC
nma:notifications	Все уведомления
nma:notification	Отдельное уведомление

В качестве примера рассмотрим модель с двумя модулями YANG example-a и example-b, которые определяют узлы данных в пространствах имён http://example.com/ns/example-a и http://example.com/ns/example-b. Модуль example-a задаёт данные конфигурации и состояния, методы RPC и уведомления, а example-b — только данные конфигурации и состояния. Гибридную схему можно вредставить в виде

  <grammar xmlns="http://relaxng.org/ns/structure/1.0" 
           xmlns:nma="urn:ietf:params:xml:ns:netmod:dsdl-annotations:1"
           xmlns:exa="http://example.com/ns/example-a"
           xmlns:exb="http://example.com/ns/example-b"
           datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes"> 
    <start>
      <grammar nma:module="example-a"
               ns="http://example.com/ns/example-a">
        <start>
          <nma:data>
            ... данные конфигурации и состояния из example-a...
          </nma:data>
          <nma:rpcs>
            <nma:rpc>
              <nma:input>
                <element name="exa:myrpc">
                  ...
                </element>
              </nma:input>
              <nma:output>
                ...
              </nma:output>
            </nma:rpc>
            ...
          </nma:rpcs>
          <nma:notifications>
            <nma:notification>
              <element name="exa:mynotif">
                ...
              </element>
            </nma:notification>
            ...
          </nma:notifications>
        </start>
        ... локальные определения именованных шаблонов из example-a...
      </grammar>
      <grammar nma:module="example-b"
               ns="http://example.com/ns/example-a">
        <start>
          <nma:data>
            ... данные конфигурации и состояния из example-b...
          </nma:data>
          <nma:rpcs/>
          <nma:notifications/>
        </start>
        ... локальные определения именованных шаблонов из example-b...
      </grammar>
    </start>
    ... глобальные определения именованных шаблонов ...
  </grammar>

Полная гибридная схема для модели данных сервера DHCP приведена в Приложении C.2.

8.2. Модульность

YANG и RELAX NG предоставляют средства для обеспечения модульности, т. е. разделения содержимого полной схемы на отдельные модули и комбинирования или использования их разными способами. Однако подход в YANG и RELAX NG различается. Модульность RELAX NG подходит для специализированных комбинаций небольшого числа схем, а YANG предполагает большой набор модулей, подобно SNMP MIB. Нииболее важные различия указаны ниже.

В YANG модуль A, импортирующий модуль B, получает доступ к определениям (grouping и typedef) на верхнем уровне модуля B. Однако дерево данных модуля B не импортируется с определениями. В RELAX NG шаблон <rng:include> импортирует определения именованных шаблонов и всё дерево включённой схемы.
Имена импортированных группировок и определений типов YANG указываются с пространством имён импортированного модуля, а имена узлов данных, содержащихся в импортированных группировках, при использовании в импортирующем модуле становятся частью его пространства имён. В RELAX NG имена шаблонов не уточняются, а именованные шаблоны в импортирующем и импортируемом шаблоне используют общее плоское пространство имён. Содержимое именованных шаблонов RELAX NG может сохранять пространство имён схемы, где они определены, или наследовать пространство имён импортирующего модуля, как в YANG. Однако для второго варианта определения именованных шаблонов должны включаться из внешней схемы, которая должна быть специально подготовлена (см. главу 11 в [Vli04]).

Для максимально возможного отображения модульности YANG в RELAX NG проверяющую схему RELAX NG (результат второго этапа отображения) нужно разделить на два файла, один из которых содержит все глобальные определения, отображённые из группировок YANG верхнего уровня всех входных модулей YANG. Этой схеме RELAX NG недопустимо определять какое-либо пространство имён через атрибут @ns. Второй файл схемы RELAX NG определяет фактические деревья данных, отображённые из входных модулей YANG и каждое из них помещается в свой блок (grammar). Вложенные блоки, в которых используется хотя бы одно глобальное определение, должны включать первую схему с определениями, а также должны задать локальное пространство имён с помощью атрибута @ns. Таким способом можно использовать глобальные определения внутри разных встроенных блоков (grammar), каждый раз принимая своё локальное пространство имён.

Определения именованных шаблонов, отображённые из группировок YANG, не относящихся к верхнему уровню, должны помещаться внутрь встроенного блока (grammar), соответствующего модулю YANG, где группировка задана.

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

Каждое глобальное определение должно размещаться как потомок внешнего элемента <rng:grammar> (корневой документ гибридной схемы).
Каждое неглобальное определение должно размещаться как потомок соответствующего вложенного элемента <rng:grammar>.

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

8.3. Детализация

RELAX NG поддерживает разные стили структурирования схем. Например, один из крайних случаей называется русской матрешкой (Russian Doll) и задаёт структуру экземпляра документа XML в одной иерархии. Другой крайний случай (плоский стиль) использует подход, похожий на язык схем определения типа данных (Data Type Definition или DTD), где каждый элемент XML соответствует определению именованного шаблона. На практике обычно применяется что-то среднее между этими вариантами.

YANG в принципе поддерживает оба стиля, но в большинстве случаев модули организуются подобно матрешке, что позволяет лучше увидеть структуру данных конфигурации. Группировки обычно определяются лишь для содержимого, предназначенного для многократного использования в разных местах с помощью операторов uses. Схемы RELAX NG обычно более плоские, поскольку в RELAX NG нужна более тонкая детализация для расширяемости схем — можно заменять или изменять лишь фрагменты схемы, которые выделены как именованные шаблоны. Для YANG это не проблема, поскольку операторы augment и refine можно углублять с помошью выражений для путей до произвольной глубины имеющихся структур.

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

8.4. Обработка пространств имён XML

Большинство современных языков схем XML, включая RELAX NG, Schematron и DSRL, поддерживают схемы для составных (compound) документов XML с элеменатми из разных пространство имён. Это полезно для наших целей, поскольку отображение YANG-DSDL поддерживает на входе несколько модулей YANG, что естественно ведёт в составным схемам документов. В RELAX NG есть два вариант определения целевых пространств имён в схемах:

традиционный способ XML через атрибут @xmlns:xxx;
один из URI целевых пространств имён может быть объявлен через атрибуто @ns.

В гибридной схеме и схемах проверки RELAX NG, создаваемых на втором этапе, пространства имён должны объявляться, как показано ниже.

Корень <rng:grammar> должен иметь атрибуты @xmlns:xxx, объявляющие префиксы всех используемых в модели пространств имён. Префиксам следует быть идентичными заданным в операторах prefix. Реализация отображения должна разрешать все конфликты префиксов из разных входных модулей при их возникновении.
Каждый вложенный элемент <rng:grammar> должен объявлять пространство имён соответствующего модуля с помощью атрибута @ns. Таким образом, имена узлов, заданные глобальными именованными шаблонами, могут принимать локальные пространства имён каждого встроенного блока (grammar), как указано в параграфе 8.2.

Это проиллюстрировано примером в конце параграфа 8.1.

Схемы DSRL могут объявлять любой число целевых пространств имён через стандартные атрибуты XML xmlns:xxx. В Schematron требуется определять все используемые пространства имён в субэлементах <sch:ns> элемента <sch:schema>.

9. Отображение моделей данных YANG в гибридную схему

В этом разделе разъясняются основные принципы первого этапа отображения, результатом которого является гибридная схема, описанная в параграфе 8.1. Подробные описания отображений операторов YANG даны в разделе 10.

9.1. Правила вхождения для узлов данных

В языках схем DSDL ограничения для размещения узла всегда размещаются вместе с этим узлом. В схеме RELAX NG, например, шаблон <rng:optional> служит родительским элементом для шаблона, определяющего лист или иной элемент. DSRL задаёт принятое по умолчанию содержимое раздельно для каждого узла, независимо от того, является ли он узлом. Для листьев в модулях YANG ограничения вхождения легко выводится из субоператоров leaf. Однако для контейнеров YANG часто требуется проверить всю ветвь для определения ограничений на вхождение контейнера.

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

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

Другое ограничение вхождения связано с семантикой default и возможностью удаления пустых контейнеров отсутствия (non-presence). В результате набор сведений допустимой конфигурации может быть изменён путём добавления или удаления некоторых элементов leaf или container без изменения смысла конфигурации. В этом документе такие элементы называются неявными. В гибридной схеме они могут быть указаны шаблоном RELAX NG, начинающимся с атрибута @nma:default или @nma:implicit.

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

       container outer {
           presence 'Наличие outer что-то означает.';
           container c1 {
               leaf foo {
                   type uint8;
                   default 1;
               }
           }
           container c2 {
               leaf-list bar {
                   type uint8;
                   min-elements 0;
               }
           }
           container c3 {
               leaf baz {
                   type uint8;
                   mandatory true;
               }
           }
       }

Здесь контейнер outer включает субоператор presence, который говорит, что контейнер является необязательным и не неявным. Если outer нет в конфигурации, не будет и его дочерних контейнеров. Однако при наличии outer имеет смысл спросить, какой из контейнеров-потомков является необязательным, а какой — неявным. В примере c1 является необязательным и неявным, c2 — необязательным но не неявным, c3 — обязательным (следовательно, не неявным).

В последующих параграфах приведены точные правил для определения, авляется контейнер обязательным или необязательным и является ли он неявным. Для упрощения рекурсивного определения этих характеристик вхождения полезно задать их и для других типов узлов схемы YANG — leaf, list, leaf-list, anyxml, choice.

9.1.1. Обязательные и необязательные узлы

Ниже приведены правила, позволяющие классифицировать узел как обязательный или необязательный:

узлы leaf, anyxml, choice являются обязательными, если они включают субоператор mandatory true, для узлов choice это означает, что должен существовать хотя бы 1 узел в одной ветви case;
узел leaf является обязательным, если он объявлен ключом списка;
узлы list и leaf-list обязательны при наличии субоператора min-elements со значением больше 0;
узел container является обязательным, если его определение не включает субоператор presence и в контейнере имеется хотя бы один обязательный лист-потомок.

Остальные узлы считаются необязательными.

В RELAX NG определения необязательных узлов должны явно помещаться в элемент <rng:optional>. Отображение должно использовать приведённые выше правила для определения необязательных узлов YANG и при обнаружении таковых помещать элемент <rng:optional> в гибридную схему. Варианты в <rng:choice> недопустимо указывать в гибридной схеме как необязательные. Если choice в YANG является необязательным, должен применяться элемент <rng: optional> для включения всего шаблона <rng:choice>.

9.1.2. Неявные узлы

Ниже приведены правила, позволяющие классифицировать узел как неявный:

узлы list, leaf-list, anyxml никогда не бывают неявными;
узел leaf является неявным, если он имеет заданное по умолчанию значение напрямую или через тип данных;
узел container является неявным, если у него нет субоператора presence, ни один их потомков не является обязательным и хотя бы один потомок является неявным.

В гибридной схеме все неявные контейнеры, а также листья, которые получают заданное по умолчанию значение от typedef и не имеют атрибута @nma:default, должны помечаться атрибутом @nma:implicit со значением true.

Отметим, что в параграфе 7.9.3 [RFC6020] заданы иные правила, которые должны учитываться при решении вопроса, является ли неявным container или leaf, размещённый внутри case оператора choice. В частности, лист или контейнер в case может быть неявным лишь при условии, что case присутствует в аргументе оператора default для choice. Однако этого недостаточно и решение зависит от конкретного экземпляра документа XML, а именно от наличия или отсутствия узлов из других (не принятых по умолчанию) case (см. 11.3. Отображение принятых по умолчанию значений в DSRL).

9.2. Отображение группировок и определений типов YANG

Группировки и определения типов YANG обычно отображаются в именованные шаблоны RELAX NG, однако есть несколько предостережений, которые нужно учитывать. Прежде всего, определения типов и группировки YANG могут присутствовать на всех уровнях иерархии модуля и с ними связана область лексической видимости (параграф 5.5 в [RFC6020]. Во-вторых, символы верхнего уровня из внешних модулей могут импортироваться как полные имена, представленные с префиксом пространства имён внешнего модуля. Именованные шаблоны в RELAX NG (локальные и импортированные через шаблон <rng:include>) используют одно пространство имён, а внутри блока (grammar) они всегда глобальны — их определения могут присутствовать лишь на верхнем уровне как потомки элемента <rng:grammar>. Следовательно, всякий раз при отображении группировок и определений типов YANG в определения именованных шаблонов RELAX NG в их именах должна устраняться неоднозначность, чтобы избежать конфликтов. При отображении применяется описанная ниже процедура изменения имён группировок и определений типов.

К именам grouping и typedef с верхнего уровня иерархии модуля YANG добавляется префикс из имени модуля и 2 символов подчёркивания (__).
К остальным именам grouping и typedef (не присутствующим на верхнем уровне модуля YANG) добавляется префикс из имени модуля, 2 символов подчёркивания (__) и всех узлов-предков, разделённых 2 символами подчёркивания.
Поскольку имена groupings и typedef в YANG относятся к разным пространствам имён, в начале имён всех группировок добавляется 1 символ подчёркивания.

Дополнительная сложность связана с правилами YANG для упорядочения субэлементов (см., например, параграф 7.5.7 в [RFC6020]). Во входных и выходных параметрах RPC субэлементы должны размещаться в порядке, заданном моделью данных, остальные субэлементы могут иметь произвольный порядок. Поэтому при использовании группировки во входных или выходных параметрах RPC и ещё где-нибудь, она должна отображаться в 2 разных определения именованных шаблонов — один с фиксированным порядком, другой — с произвольным. Чтобы различать их, для фиксированного порядка должен добавляться суффикс __rpc.

Рассмотрим в качестве пример модуль YANG, импортирующий стандартный модуль ietf-inet-types [RFC6021].

   module example1 {
       namespace "http://example.com/ns/example1";
       prefix ex1;
       typedef vowels {
           type string {
               pattern "[aeiouy]*";
           }
       }
       grouping "grp1" {
           leaf "void" {
               type "empty";
           }
       }
       container "cont" {
           leaf foo {
               type vowels;
           }
           uses "grp1";
       }
   }

Гибридная схема, созданная на первом этапе отображения, будет содержать 2 (глобальных) определения именованных шаблонов, как показано ниже.

   <rng:define name="example1__vowels">
     <rng:data type="string">
       <rng:param name="pattern">[aeiouy]*</rng:param>
     </rng:data>
   </rng:define>

   <rng:define name="_example1__grp1">
     <rng:optional>
       <rng:element name="void">
         <rng:empty/>
       </rng:element>
     </rng:optional>
   </rng:define>

9.2.1. Уточнения и дополнения YANG

Группировки YANG представляют ту же концепцию, что и определения именованных шаблонов в RELAX NG и оба языка предоставляют механизмы для их последующего изменения. Однако в RELAX NG изменяются сами определения, а YANG использует субоператоры uses, меняющие расширения группировок.

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

Операторы refine и augment имеют достаточно эффективные возможности, используя выражения в стиле XPath как свои аргументы для обращения к узлам схемы, расположенным сколь угодно глубоко внутри содержимого группировки. Изменения определений именованных шаблонов в RELAX NG применяются исключительно на верхнем уровне содержимого именованного шаблона. Для достижения изменяемости именованных шаблонов, сравнимой с YANG, схема RELAX NG должна быть совершенно плоской (8.4. Обработка пространств имён XML) и станет неудобочитаемой.

Поскольку цель описываемого здесь отображения заключается в генерации специализированных схем DSDL, принято решение избегать этих сложностей и преобразовывать grouping, refine и/или augment «на месте». Иными словами, каждый оператор uses с субоператорами refine и/или augment заменяется содержимым соответствующей группировки, применяются изменения, заданные операторами refine и augment, после чего полученный фрагмент схемы YANG отображается, как будто опосредованности uses/grouping не было.

Если в содержимом группировки имеются дополнительные операторы uses, для них тоже может потребоваться преобразование. Это необходимо, если имеющиеся пары uses и grouping находятся на «пути изменения», заданном аргументом оператора refine или augment.

Рассмотрим в качестве примера приведённый ниже модуль YANG.

   module example2 {
       namespace "http://example.com/ns/example2";
       prefix ex2;
       grouping leaves {
           uses fr;
           uses es;
       }
       grouping fr {
           leaf feuille {
               type string;
           }
       }
       grouping es {
           leaf hoja {
               type string;
           }
       }
       uses leaves;
   }

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

   <rng:define name="_example2__leaves">
     <rng:interleave>
       <rng:ref name="_example2__fr"/>
       <rng:ref name="_example2__es"/>
     </rng:interleave>
   </rng:define>

   <rng:define name="_example2__fr">
     <rng:optional>
       <rng:element name="feuille">
         <rng:data type="string"/>
       </rng:element>
     </rng:optional>
   </rng:define>

   <rng:define name="_example2__es">
     <rng:optional>
       <rng:element name="hoja">
         <rng:data type="string"/>
       </rng:element>
     </rng:optional>
   </rng:define>

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

   <nma:data>
     <rng:ref name="_example2__leaves"/>
   </nma:data>

Предположим, что оператор uses leaves включает субоператор refine, например,

   uses leaves {
       refine "hoja" {
           default "alamo";
       }
   }

Результирующая гибридная схема теперь содержит лишь одно определение именованного шаблона — _example2__fr. Две другие группировки leaves и es должны быть преобразованы, поскольку они находятся на «пути изменения», т. е. содержат уточнение hoja. Связанная с данными конфигурации часть гибридной схемы будет иметь вид

   <nma:data>
     <rng:interleave>
       <rng:ref name="_example2__fr"/>
       <rng:optional>
         <rng:element name="ex2:hoja" nma:default="alamo">
           <rng:data type="string"/>
         </rng:element>
       </rng:optional>
     </rng:interleave>
   </nma:data>

9.2.2. Цепочки производных типов

В RELAX NG нет эквивалента созданию производных типов YANG, позволяющего ограничить встроенный тип (возможно, за несколько шагов) путём добавления ограничений. Всякий раз, когда производный тип YANG применяется без ограничений (как субоператор leaf или другого typedef), оператор type просто отображается в ссылку на именованный шаблон <rng:ref>, а определение типа — в определение именованного шаблона RELAX NG <rng:define>. Однако при указании ограничений субоператорами оператора type определение типа должно преобразовываться в этой точке, чтобы в гибридной схеме отображался лишь встроенный тип предка, ограниченный поскольку лишь лишь «гранями», соответствующими сочетанию всех ограничений, найденный в цепочке производного типа и операторе type.

Рассмотрим в качестве примера модуль YANG, представленный ниже.

   module example3 {
       namespace "http://example.com/ns/example3";
       prefix ex3;
       typedef dozen {
           type uint8 {
               range 1..12;
           }
       }
       leaf month {
           type dozen;
       }
   }

Оператор type в листе month не имеет ограничений и поэтому отображается просто в ссылку <rng:ref name=»example3__dozen»/>, а соответствующий именованный шаблон имеет вид

   <rng:define name="example3__dozen">
     <rng:data type="unsignedByte">
       <rng:param name="minInclusive">1</rng:param>
       <rng:param name="maxInclusive">12</rng:param>
     </rng:data>
   </rng:define>

Предположим, что определение листа month изменено, как показано ниже

   leaf month {
       type dozen {
           range 7..max;
       }
   }

Выходная схема RELAX NG не будет включать определения именованного шаблона и лист month будет отображён в

   <rng:element name="ex3:month">
     <rng:data type="unsignedByte">
       <rng:param name="minInclusive">7</rng:param>
       <rng:param name="maxInclusive">12</rng:param>
     </rng:data>
   </rng:element>

Отображение цепочек производных типов может дополнительно осложняться наличием оператора default в определениях типа. В простом случае, когда определение типа с оператором default применяется без ограничений, default отображается в атрибут @nma:default элемента <rng:define>. Однако при расширении определения типа в результате ограничений атрибут @nma:default, возникающий из расширенного типа или родительских типов в цепочке создания производного типа, должен присоединяться к шаблону, где выполняется преобразование. При наличии нескольких операторов default в цепочке производного типа применяется лишь ближайший к преобразуемому типу оператор default.

Рассмотрим вариант предыдущего примера.

   module example3bis {
       namespace "http://example.com/ns/example3bis";
       prefix ex3bis;
       typedef dozen {
           type uint8 {
               range 1..12;
           }
           default 7;
       }
       leaf month {
           type dozen;
       }
   }

Оператор typedef в этом модуле отображается в приведённое ниже определение именованного шаблона.

   <rng:define name="example3bis__dozen" @nma:default="7">
     <rng:data type="unsignedByte">
       <rng:param name="minInclusive">1</rng:param>
       <rng:param name="maxInclusive">12</rng:param>
     </rng:data>
   </rng:define>

Если тип dozen ограничен при использовании в определении листа month (как в предыдущем примере), тип dozen преобразуется и @nma:default становится атрибутом определения элемента <ex3bis:month>.

   <rng:element name="ex3bis:month" @nma:default="7">
     <rng:data type="unsignedByte">
       <rng:param name="minInclusive">7</rng:param>
       <rng:param name="maxInclusive">12</rng:param>
     </rng:data>
   </rng:element>

Однако при наличии в листе month субоператора default, заданное по умолчанию значение типа dozen игнорируется.

9.3. Трансляция выражений XPath

YANG использует полный синтаксис XPath 1.0 [XPath] для аргументов must, when, path. Поскольку имена узлов данных в модуле YANG всегда относятся к пространству имён этого модуля, в YANG принято упрощение, похожее на концепцию принятого по умолчанию пространства имён XPath 2.0 — в именах узлов в выражениях XPath не требуется указывать префикс пространства имён внутри модуля, где эти узлы определены (предполагается локальное пространство). Поэтому все выражения XPath должны транслироваться в полном соответствии с XPath 1.0 — к каждому узлу без префикса должен добавляться в начале префикс пространства имён локального модуля, заданный оператором prefix.

Выражения XPath внутри группировок верхнего уровня требуют особого внимания, поскольку имена содержащихся в них узлов без префиксов должны принимать пространство имён модуля, где применяется группировка (8.2. Модульность). Для этого локальный префикс должен быть представлен в гибридной схеме с использованием переменной $pref. В Schematron для таких выражений XPath подставляется соответствующее значение переменной через параметр в абстрактном шаблоне, в который отображается группировка YANG (11.2. Отображение семантических ограничений в Schematron). Например, выражение XPath /dhcp/max-lease-time из модуля YANG с префиксом dhcp будет транслироваться в

$pref:dhcp/$pref:max-lease-time, если оно находится в группировке верхнего уровня;
dhcp:dhcp/dhcp:max-lease-time в ином случае.

В YANG также применяются другие выражения в стиле XPath — идентификаторы ключей и идентификаторы узлов-потомков схемы (см. ABNF для descendant-schema-nodeid в параграфе 12 [RFC6020]). Эти выражения должны транслироваться с добавлением префикса локального модуля.

9.4. Расширения языка YANG

YANG позволяет расширять себя, добавляя новые операторы с ключевыми словами из специальных пространств имён. Такие расширения должны сначала объявляться с помощью оператора extension, затем их можно применять как стандартные операторы YANG, от которых они отличаются префиксом пространства имён, определяющим ключевое слово расширения. В RELAX NG имеется похожий механизм расширения — элементы и атрибуты XML с именами из внешних пространств имён могут помещаться почти в любое место схемы RELAX NG.

Расширения YANG могут (но не обязаны) иметь значение в контексте схем DSDL, поэтому реализация может игнорировать любое или все расширения. Если расширение не игнорируется, оно должно отображаться в элементы и/или атрибуты XML, которые точно соответствуют YIN-форме расширения (см. параграф 11.1 в [RFC6020]).

Рассмотрим в качестве примера расширение, заданное модулем acme.

   extension documentation-flag {
       argument number;
   }

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

   leaf folio {
       acme:documentation-flag 42;
       type string;
   }

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

   <rng:element name="acme:folio">
      <acme:documentation-flag number="42"/>
      <rng:data type="string"/>
   </rng:element>

Отметим, что сам оператор extension не отображается.

10. Отображение операторов YANG в гибридную схему

Каждый параграф этого раздела посвящён одному оператору YANG и описывает его отображение в гибридную схему. Параграфы отсортированы по алфавиту в соответствии с ключевыми словами операторов.

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

Правила кодирования YANG XML транслируются в приведённые ниже правила упорядочения субэлементов.

Внутри ветви <nma:rpcs> (параметры ввода и вывода для операции RPC) порядок субэлементов фиксирован и их определения в гибридной схеме должны следовать порядку в исходном модуле YANG.
При отображении оператора list все ключи должны размещаться впереди других субэлементов с сохранением порядка, заданного в операторе key. Порядок остальных субэлементов (не ключей) не задаётся, поэтому определения в гибридной схеме должны помещаться в элемент <rng:interleave>.
В иных случаях порядок субэлементов может быть произвольным, поэтому определения в гибридной схеме должны помещаться в элемент <rng:interleave>.

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

Аргумент отображаемого оператора обозначается словом ARGUMENT.
Элемент схемы RELAX NG, становящийся родителем в полученном фрагменте XML, указывается словом PARENT.

10.1. Оператор anyxml

Этот оператор отображается в элемент <rng:element> и ARGUMENT с добавленным впереди префиксом локального пространства имён становится значением атрибута @name. Содержимое элемента <rng:element> имеет вид

   <rng:ref name="__anyxml__"/>

При наличии у anyxml субоператоров они могут отображаться в дочерние элементы <rng:element>.

Если в любом из входных модулей YANG имеется хотя бы один оператор anyxml, должно добавляться в точности 1 определение шаблона в схему RELAX NG как потомок корневого элемента <rng:grammar> (см. стр 172 в [Vli04]).

   <rng:define name="__anyxml__">
     <rng:zeroOrMore>
       <rng:choice>
         <rng:attribute>
           <rng:anyName/>
         </rng:attribute>
         <rng:element>
           <rng:anyName/>
           <rng:ref name="__anyxml__"/>
         </rng:element>
         <rng:text/>
       </rng:choice>
     </rng:zeroOrMore>
   </rng:define>

Например, оператор YANG в модуле с пространством имён с префиксом yam

   anyxml data {
       description "Произвольное содержимое XML.";
   }

отображается в приведённый ниже фрагмент.

   <rng:element name="yam:data">
       <a:documentation>Произвольное содержимое XML</a:documentation>
       <rng:ref name="__anyxml__"/>
   </rng:element>

Узел anyxml является необязательным, если в нем нет субоператора mandatory true. В этом случае элемент <rng:element> должен помещаться в <rng:optional>, если anyxml не является потомком оператора choice, формируя таким образом сокращение case для этого выбора (см. 9.1.1. Обязательные и необязательные узлы).

10.2. Оператор argument

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

10.3. Оператор augment

Как и субоператор uses, этот оператор обрабатывается как часть отображения uses, описанного в параграфе 10.57.

На верхнем уровне модуля или субмодуля оператор augment служит для дополнения дерева схемы другого модуля YANG. Если расширяемый модуль не обрабатывается в том же отображении, оператор augment на верхнем уровне должен игнорироваться. В ином случае содержимое оператора добавляется к внешнему модулю с пространством имён модуля, где указан оператор augment.

10.4. Оператор base

Этот оператор игнорируется, будучи субоператором identity, и обрабатывается с типом identityref при использовании как субоператора определения данного типа (см. 10.53.6. Тип identityref).

10.5. Оператор belongs-to

Этот оператор не применяется, поскольку обработка субмодулей всегда инициируется из основного модуля (см. 10.24. Оператор include).

10.6. Оператор bit

Этот оператор обрабатывается внутри типа bits (см. 10.53.4. Тип bits).

10.7. Оператор case

Этот оператор отображается в элемент <rng:group> или <rng:interleave> в зависимости от принадлежности к операции RPC. Если аргумент братского (sibling) оператора default равен ARGUMENT, должен добавляться атрибут @nma:implicit со значением true к этому элементу <rng:group> или <rng:interleave>. Атрибут @nma:implicit недопустимо применять для узлов верхнего уровня в case, не используемом по умолчанию (см. параграф 7.9.3 в [RFC6020]).

10.8. Оператор choice

Этот оператор отображается в элемент <rng:choice>. Если choice включает субоператор mandatory true, к элементу <rng:choice> должен добавляться атрибут @nma:mandatory со значением ARGUMENT, что может потребовать дополнительной обработки (см. параграф 11.2.1. Ограничения для обязательного choice). При отсутствии mandatory true элемент <rng:choice> должен помещаться в <rng:optional>. Варианты <rng:choice>, отображённые из оператора case или сокращения case, недопустимо делять необязательными.

10.9. Оператор config

Этот оператор отображается в атрибут @nma:config, а ARGUMENT становится его значением.

10.10. Оператор contact

Этот оператор не следует использовать в отображении, поскольку с гибридной может сопоставляться несколько модулей YANG, созданных разными авторами. Гибридная схема содержит ссылки на все входные модули в элементах Dublin Core <dc:source> (см. 10.34. Оператор module). Полномочные сведения об авторах содержатся в модулях YANG.

10.11. Оператор container

Используя правила параграфа 9.1.1, алгоритм отображения должен определить, задаёт ли оператор необязательный контейнер и, если это так, вставить элемент <rng:optional> и сделать его новым PARENT. Контейнер, заданный этим оператором, отображается в элемент <rng:element>, который становится потомком PARENT и использует ARGUMENT с добавленным впереди префиксом локального пространства имён как значение атрибута @name.

Используя правила параграфа 9.1.2, алгоритм отображения должен определить, является ли контейнер неявным и, если это так, добавить атрибут @nma:implicit со значением true к элементу <rng:element>.

10.12. Оператор default

Будучи субоператором leaf, этот оператор отображается в атрибут @nma:default для PARENT, а ARGUMENT становится его значением. Как субоператор typedef, оператор default тоже отображается в атрибут @nma:default со значением ARGUMENT. Размещение этого атрибута зависит от того, нужно ли преобразовывать определение типа при использовании.

Если определение типа не преобразуется, @nma:default становится атрибутом шаблона <rng:define>, являющегося результатом отображения родительского typedef.
В ином случае @nma:default будет атрибутом шаблона-предка RELAX NG, где выполняется преобразование.

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

Будучи субоператором choice, оператор default указывает принятый по умолчанию вариант и обрабатывается внутри оператора case (см. 10.7. Оператор case). Если принятый по умолчанию вариант использует сокращённую нотацию, где оператор case опущен, атрибут @nma:implicit со значением true присоединяется к узлу, представляющему заданный по умолчанию вариант в сокращённой нотации, или может вставляться дополнительный элемент <rng:group>, к которому и присоединяется атрибут @nma:implicit. В последнем случае конечный результат будет как при наличии case для принятого по умолчанию варианта.

Рассмотрим в качестве пример оператор choice в модуле с пространством имён yam.

   choice leaves {
       default feuille;
       leaf feuille { type empty; }
       leaf hoja { type empty; }
   }

Он отображается напрямую в

   <rng:choice>
     <rng:element name="yam:feuille" nma:implicit="true">
       <rng:empty/>
     </rng:element>
     <rng:element name="yam:hoja">
       <rng:empty/>
     </rng:element/>
   </rng:choice>

или принятый по умолчанию вариант может быть помещён в дополнительный элемент <rng:group>

   <rng:choice>
     <rng:group nma:implicit="true">
       <rng:element name="yam:feuille">
         <rng:empty/>
       </rng:element>
     </rng:group>
     <rng:element name="yam:hoja">
       <rng:empty/>
     </rng:element/>
   </rng:choice>

10.13. Оператор description

Этот оператор отображается в элемент совместимости DTD <a:documentation>, а ARGUMENT будет его текстом. Для получения корректно форматированного компактного синтаксиса RELAX NG этот элемент следует вставлять как первого потомка PARENT.

10.14. Оператор deviation

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

10.15. Оператор enum

Этот оператор отображается в элемент <rng:value>, а ARGUMENT будет его текстом. Все субоператоры, кроме status, игнорируются, поскольку элемент <rng:value> не может включать аннотаций (см. раздел 6 в [RNG]).

10.16. Оператор error-app-tag

Этот оператор игнорируется, если он не является субоператором must. В последнем случае оператор отображается в элемент <nma:error-app-tag> (см. 10.35. Оператор must).

10.17. Оператор error-message

10.18. Оператор extension

Этот оператор игнорируется, однако расширения языка YANG могут отображаться, как описано в параграфе 9.4.

10.19. Оператор feature

Этот оператор игнорируется.

10.20. Оператор grouping

Этот оператор отображается в определение именованного шаблона RELAX NG <rng:define>, но лишь при использовании заданной оператором группировки без уточнений и дополнений в каком-либо из входных модулей. В этом случае определение именованного шаблона становится потомком элемента <rng:grammar>, а его именем будет значение ARGUMENT, изменённое в соответствии с правилами параграфа 9.2. Отображение группировок и определений типов YANG.

Как указано в параграфе 8.2. Модульность, определение именованного шаблона должно размещаться как потомок:

элемента <rng:grammar>, если группировка задана на верхнем уровне входного модуля YANG;
вложенного элемента <rng:grammar>, соответствующего модулю, где задана группировка, в ином случае.

При использовании группировки с уточнением или дополнением, она преобразуется так, чтобы применить уточнения и дополнения для предписанных узлов схемы на месте (см. 9.2.1. Уточнения и дополнения YANG).

Реализация может предлагать вариант отображения всех операторов grouping в определения именованных шаблонов в выходной схеме RELAX NG, даже если на них нет ссылок. Это полезно при отображении библиотечных модулей YANG, обычно содержащих лишь typedef и grouping.

10.21. Оператор identity

Этот оператор отображается в показанное ниже определение именованного шаблона, размещаемое как потомок корневого элемента <rng:grammar>.

   <rng:define name="__PREFIX_ARGUMENT">
     <rng:choice>
       <rng:value type="QName">PREFIX:ARGUMENT</rng:value>
       <rng:ref name="IDENTITY1"/>
       ...
     </rng:choice>
   </rng:define>

где

PREFIX — префикс, используемый в гибридной схеме для пространства имён модуля с определением identity;

IDENTITY1 — имя шаблона, соответствующего идентификатору, выведенному из текущего identity. Для каждого такого идентификатора должен присутствовать в точности 1 элемент <rng:ref>.

Рассмотрим пример из параграфа 7.16.3 в ([RFC6020], где заданы 2 identity в двух входных модулях YANG.

   module crypto-base {
     namespace "http://example.com/crypto-base";
     prefix "crypto";
     identity crypto-alg {
       description
         "Базовый идентификатор для вывода всех криптоалгоритмов.";
       }
   }

   module des {
     namespace "http://example.com/des";
     prefix "des";
     import "crypto-base" {
       prefix "crypto";
     }
     identity des {
       base "crypto:crypto-alg";
       description "Алгоритм DES";
     }
     identity des3 {
       base "crypto:crypto-alg";
       description "Алгоритм Triple DES";
     }
   }

Идентификаторы будут отображаться в приведённые ниже определения именованных шаблонов.

   <define name="__crypto_crypto-alg">
     <choice>
       <value type="QName">crypto:crypto-alg</value>
       <ref name="__des_des"/>
       <ref name="__des_des3"/>
     </choice>
   </define>
   <define name="__des_des">
     <value type="QName">des:des</value>
   </define>
   <define name="__des_des3">
     <value type="QName">des:des3</value>
   </define>

10.22. Оператор if-feature

ARGUMENT вместе с аргументами всех братских (sibling) операторов if-feature (с добавленными префиксами при их отсутствии) должны собираться в разделённый пробелами список, становящийся значением атрибута @nma:if-feature, который присоединяется к PARENT.

10.23. Оператор import

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

10.24. Оператор include

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

10.25. Оператор input

Этот оператор обрабатывается в рамках rpc, см. 10.50. Оператор rpc.

10.26. Оператор key

Этот оператор отображается в атрибут @nma:key. Значение ARGUMENT должно транслироваться так, что к каждому ключу добавлялся префикс пространства имён локального модуля. Результат трансляции становится значением атрибута @nma:key.

10.27. Оператор leaf

Этот оператор отображается в элемент <rng:element>, ARGUMENT с префиксом локального пространства имён становится значением атрибута @name. Если лист не является обязательным (не включает mandatory true), и не указан среди ключей содержащего его списка, элемент <rng:element> должен помещаться в <rng:optional>, за исключением случая, когда leaf является потомком choice и, таким образом, представляет сокращение case для этого выбора (см. 9.1.1. Обязательные и необязательные узлы).

10.28. Оператор leaf-list

Этот оператор отображается в блок, помещённый в элемент <rng:zeroOrMore> или <rng:oneOrMore> в зависимости от значения субоператора min-elements (0 для первого случая, применяемого по умолчанию, положительное значение для второго). Элемент <rng:zeroOrMore> или <rng: oneOrMore> становится родителем (PARENT). Затем добавляется элемент <rng:element> как потомок PARENT, а ARGUMENT с префиксом локального пространства имён становится значением атрибута @name. К элементу <rng:element> должен также добавляться атрибут @nma:leaf-list со значением true. Если leaf-list имеет субоператор min-elements с аргументом больше 1, к <rng:element> добавляется атрибут @nma:min-elements со значением аргумента min-elements. При наличии субоператора max-elements со значением, отличным от unbounded добавляется атрибут @nma:max-elements со значением аргумента max-elements.

Рассмотрим в качестве примера leaf-list из модуля с префиксом пространства имён yam.

   leaf-list foliage {
       min-elements 3;
       max-elements 6378;
       ordered-by user;
       type string;
   }

Он отображается во фрагмент RELAX NG

   <rng:oneOrMore>
     <rng:element name="yam:foliage" nma:leaf-list="true"
                  nma:ordered-by="user"
                  nma:min-elements="3" nma:max-elements="6378">
       <rng:data type="string"/>
     </rng:element>
   </rng:oneOrMore>

10.29. Оператор length

Этот оператор обрабатывается в рамках string, см. 10.53.10. Тип string

10.30. Оператор list

Этот оператор отображается как и leaf-list (см. параграф 10.28). Единственным отличием является то, что наличие аннотации @nma:leaf-list недопустимо или атрибут должен иметь значение false.

При отображении субоператоров list порядок потомков элемента списка должен быть таким, чтобы ключи (при наличии) всегда указывались в порядке, заданном оператором key, и до остальных потомков (см. параграф 7.8.5 в [RFC6020]). В частности, если ключ списка задан в группировке, а сам узел списка не является частью этой группировки и положение оператора uses будет нарушать приведённые выше требования к порядку, группировка должна быть преобразована (uses заменяется содержимым группировки).

Рассмотрим в качестве примера фрагмент модуля YANG с префиксом yam.

   grouping keygrp {
     leaf clef {
       type uint8;
     }
   }
   list foo {
     key clef;
     leaf bar {
       type string;
     }
     leaf baz {
       type string;
     }
     uses keygrp;
   }

Он отображается в приведённый ниже фрагмент RELAX NG.

   <rng:zeroOrMore>
     <rng:element name="yam:foo" nma:key="yam:clef">
       <rng:element name="yam:clef">
         <rng:data type="unsignedByte"/>
       </rng:element>
       <rng:interleave>
         <rng:element name="yam:bar">
           <rng:data type="string"/>
         </rng:element>
         <rng:element name="yam:baz">
           <rng:data type="string"/>
         </rng:element>
       </rng:interleave>
     </rng:element>
   </rng:zeroOrMore>

Отметим, что группировка keygrp преобразована и определение yam:clef размещено перед шаблоном <rng:interleave>.

10.31. Оператор mandatory

Этот оператор может появляться как субоператор leaf, choice или anyxml. Если ARGUMENT имеет значение true, родительский узел отображается как обязательный (9.1.1. Обязательные и необязательные узлы).

В качестве субоператора choice этот оператор отображается в атрибут @nma:mandatory, добавляемый к PARENT. Значением этого атрибута служит аргумент родительского оператора choice.

10.32. Оператор max-elements

Этот оператор обрабатывается в рамках leaf-list или list, см. 10.28. Оператор leaf-list.

10.33. Оператор min-elements

Этот оператор обрабатывается в рамках leaf-list или list, см. 10.28. Оператор leaf-list.

10.34. Оператор module

Этот оператор отображается во встроенный шаблон <rng:grammar> с атрибутом @nma:module со значением ARGUMENT. Дополнительно следует создавать элемент <dc:source> как потомка этого <rng:grammar> со значением ARGUMENT как метаданные ссылки на входной модуль YANG (см. также 10.49. Оператор revision). Субоператоры module должны отображаться, как указано ниже.

Субоператоры данных конфигурации и состояния отображаются в потомков элемента <nma:data>.
Субоператоры содержимого запросов и откликов RPC отображаются в потомков элемента <nma:rpcs>.
Субоператоры содержимого уведомлений отображаются в потомков элемента <nma:notifications>.

10.35. Оператор must

Этот оператор отображается в элемент <nma:must>, имеющий обязательный атрибут @assert (без пространства имён) с ARGUMENT, преобразованным в действительное выражение XPath (9.3. Трансляция выражений XPath). Элемент <nma:must> может иметь субэлементы, полученные из отображения субоператоров error-app-tag и error-message. Иные субоператоры must (description и reference) игнорируются.

Рассмотрим в качестве примера оператор YANG в модуле dhcp.

   must 'current() <= ../max-lease-time' {
     error-message
       "Значение default-lease-time должно быть меньше max-lease-time";
   }

Он отображается в

   <nma:must assert="current()&lt;=../dhcp:max-lease-time">
     <nma:error-message>
       Значение default-lease-time должно быть меньше max-lease-time
     </nma:error-message>
   </nma:must>

10.36. Оператор namespace

Этот оператор отображается двумя способами одновременно.

В атрибут @xmlns:PREFIX корневого элемента <rng:grammar>, где PREFIX — префикс пространства имён, заданный братским оператором prefix. ARGUMENT будет значением этого атрибута.
В атрибут @ns со значением ARGUMENT для PARENT, являющегося вложенным шаблоном <rng: grammar>.

10.37. Оператор notification

Этот оператор отображается в ветвь элемента <nma:notifications> в гибридной схеме, где PREFIX — префикс локального модуля YANG.

   <nma:notification>
     <rng:element name="PREFIX:ARGUMENT">
       ...
     </rng:element>
   </nma:notification>

Субоператоры notification отображаются в ветви <rng:element name=»PREFIX:ARGUMENT»>.

10.38. Оператор ordered-by

Этот оператор отображается в атрибут @nma:ordered-by со значением ARGUMENT (см. 10.28. Оператор leaf-list).

10.39. Оператор organization

Этот оператор игнорируется при отображении, поскольку гибридная схема может создаваться из нескольких модулей YANG, разработанных разными организациями. Гибридной схеме следует указывать все входные модули в элементах Dublin Core <dc:source> (см. 10.34. Оператор module). Сведения об организациях даны в исходных модулях YANG.

10.40. Оператор output

Этот оператор обрабатывается в рамках rpc, см. 10.50. Оператор rpc

10.41. Оператор path

Этот оператор обрабатывается в рамках типа leafref, см. 10.53.8. Тип leafref

10.42. Оператор pattern

Этот оператор обрабатывается в рамках типа string, см. 10.53.10. Тип string

10.43. Оператор position

Этот оператор игнорируется.

10.44. Оператор prefix

Этот оператор обрабатывается в рамках братского оператора namespace (10.36. Оператор namespace) или родительского оператора import (10.23. Оператор import). Как субоператор belongs-to (в субмодулях) оператор prefix игнорируется.

10.45. Оператор presence

Этот оператор влияет на отображение родительского контейнера (10.11. Оператор container), определение которого должно помещаться в <rng:optional>, независимо от содержимого (см. 9.1.1. Обязательные и необязательные узлы).

10.46. Оператор range

Этот оператор обрабатывается в рамках численных типов, см. 10.53.9. Численные типы.

10.47. Оператор reference

Этот оператор отображается в элемент <a:documentation>, а его текстом служит ARGUMENT с префиксом модуля.

10.48. Оператор require-instance

Этот оператор обрабатывается в рамках типа instance-identifier, см. 10.53.5. Типы enumeration и union.

10.49. Оператор revision

При отображении используется лишь последний экземпляр оператора revision (с наиболее поздней датой в ARGUMENT), который задаёт текущий выпуск входного модуля YANG [RFC6020]. Эту дату следует записать вместе с именем модуля YANG в соответствющий элемент Dublin Core <dc:source> (10.34. Оператор module), например, в виде <dc:source>YANG module ‘foo’, revision 2010-03-02</dc:source>. Субоператоры description в revision игнорируются.

10.50. Оператор rpc

Этот оператор отображается в показанную ниже ветвь схемы RELAX NG, где PREFIX — префикс локального модуля YANG.

   <nma:rpc>
     <nma:input>
       <rng:element name="PREFIX:ARGUMENT">
         ... отображённое содержимое input ...
       </rng:element>
     </nma:input>
     <nma:output">
       ... отображённое содержимое output ...
     </nma:output>
   </nma:rpc>

Как указано во фрагменте схемы, содержимое субоператора input (при наличии) отображается внутри <rng:element name=»PREFIX: ARGUMENT»>, а содержимое output — в <nma:output>. При отсутствии субоператора output включать элемент <nma:output> недопустимо. Элемент <nma:rpc> является потомком <nma:rpcs>.

10.51. Оператор status

Этот оператор может игнорироваться или отображаться в атрибут @nma:status со значением ARGUMENT.

10.52. Оператор submodule

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

10.53. Оператор type

Большинство встроенных типов YANG имеет эквиваленты в библиотеке типов данных XSD [XSD-D] (Таблица 4).

Таблица 4. Встроенные типы данных YANG и их эквиваленты в W3C XML Schema Type Library.

Тип YANG	Тип XSD	Назначение
int8	byte	8-битовое целое число
int16	short	16-битовое целое число
int32	int	32-битовое целое число
int64	long	64-битовое целое число
uint8	unsignedByte	8-битовое целое число без знака
uint16	unsignedShort	16-битовое целое число без знака
uint32	unsignedInt	32-битовое целое число без знака
uint64	unsignedLong	64-битовое целое число без знака
string	string	Строка символов
binary	base64Binary	Двоичные данные в кодировке base64

Два важных типа из библиотеки типов данных XSD — dateTime и anyURI — не имеют встроенных аналогов в YANG и определены как производные типа в стандартных модулях [RFC6021]: date-and-time в модулей ietf-yang-types и uri — в ietf-inet-types. Однако формальные ограничения в определениях типов YANG достаточно слабы и реализациям отображений YANG-DSDL следует находить эти производные типы в исходных модулях YANG и отображать их в dateType и anyURI.

Отображения конкретных встроенных типов YANG описаны в последующих параграфах.

10.53.1. Тип empty

Этот тип отображается в <rng:empty/>.

10.53.2. Тип boolean

Этот встроенный тип не поддерживает ограничений и отображается в приведённый ниже фрагмент XML.

   <rng:choice>
     <rng:value>true</rng:value>
     <rng:value>false</rng:value>
   </rng:choice>

Отметим, что тип XSD boolean не может применяться здесь, поскольку он, в отличие от YANG, допускает численное представление логических значений — 0 для false и 1 для true.

10.53.3. Тип binary

Этот встроенный тип не поддерживает ограничений и отображается вставкой элемента <rng:data> с атрибутом @type base64Binary (Таблица 4).

10.53.4. Тип bits

Этот тип отображается в <rng:list> и для каждого субоператора bit вставляется показанный ниже фрагмент XML как потомок <rng:list>.

   <rng:optional>
     <rng:value>bit_name</rng:value>
   </rng:optional>

Здесь bit_name указывает имя бита из аргумента субоператора bit.

10.53.5. Типы enumeration и union

Эти типы отображаются в элементы <rng:choice>.

10.53.6. Тип identityref

Этот тип отображается в ссылку на именованный шаблон <rng:ref name=»__PREFIX_BASE»/>, где PREFIX:BASE — полное имя идентификатора в аргументе субоператора base. Предположим, например, что модуль des из параграфа 10.21. Оператор identity содержит показанное ниже определение.

   leaf foo {
     type identityref {
       base crypto:crypto-alg;
     }
   }

Этот лист будет отображаться в шаблон

   <element name="des:foo">
     <ref name="__crypto_crypto-alg"/>
   </element>

10.53.7. Тип instance-identifier

Этот тип отображается в элемент <rng:data> с атрибутом @type string. Кроме того, должен вставляться пустой элемент <nma:instance-identifier> как потомок PARENT. Аргументом субоператора require-instance (при наличии) будет значение атрибута @require-instance из элемента <nma:instance-identifier>.

10.53.8. Тип leafref

Этот тип отображается так же как тип leaf в аргументе субоператора path. Однако если тип указанного листа задаёт принятое по умолчанию значение, оно должно игнорироваться при отображении. Кроме того, к PARENT должен добавляться атрибут @nma:leafref. Аргумент субоператора path, преобразованный в соответствии с параграфом 9.3. Трансляция выражений XPath, становится значением этого атрибута.

10.53.9. Численные типы

Встроенными численными типами YANG являются int8, int16, int32, int64, uint8, uint16, uint32, uint64, decimal64. Они отображаются в элементы <rng:data> с атрибутом @type, имеющим значение ARGUMENT в соответствии с таблицей 4.

Тип decimal64 является исключением и отображается в тип decimal из библиотеки типов данных XSD. Его точность и число значащих цифр контролируются указанными ниже границами, которые должны присутствовать:

totalDigits имеет значение 19;
fractionDigits получает значение аргумента субоператора fraction-digits.

Фиксированное значение totalDigits соответствует максимальному числу десятичных цифр в 64-битовом целом числе.

Например оператор

   type decimal64 {
       fraction-digits 2;
   }

отображается в тип данных RELAX NG

   <rng:data type="decimal">
     <rng:param name="totalDigits">19</rng:param>
     <rng:param name="fractionDigits">2</rng:param>
   </rng:data>

Все численные типы поддерживают ограничение range, которое отображается, как указано ниже.

Если выражение содержит лишь один диапазон LO..HI, оно отображается в пару границ <rng:param name=»minInclusive»>LO</rng:param> и <rng:param name=»maxInclusive»>HI</rng:param>. Если диапазон указан одним числом, значения границ будут одинаковыми. Если LO имеет значение min, граница minInclusive опускается, а при HI со значением max опускается граница maxInclusive. Если диапазон содержит несколько блоков, разделённых |, элемент <rng:data> должен повторяться для каждого блока, а все такие элементы <rng:data> заключаются в <rng:choice>. Каждый элемент <rng:data> содержит границы minInclusive и maxInclusive для одного блока, как указано выше. Для типа decimal64 значения totalDigits и fractionDigits должны повторяться в каждом элементе <rng:data>.

Например,

   type int32 {
       range "-6378..0|42|100..max";
   }

отображается во фрагмент RELAX NG

   <rng:choice>
     <rng:data type="int">
       <rng:param name="minInclusive">-6378</rng:param>
       <rng:param name="maxInclusive">0</rng:param>
     </rng:data>
     <rng:data type="int">
       <rng:param name="minInclusive">42</rng:param>
       <rng:param name="maxInclusive">42</rng:param>
     </rng:data>
     <rng:data type="int">
       <rng:param name="minInclusive">100</rng:param>
     </rng:data>
   </rng:choice>

Дополнительные детали и ограничения для отображения приведены в параграфе 9.2.2. Цепочки производных типов.

10.53.10. Тип string

Этот тип отображается в элемент <rng:data> с атрибутом @type string. Ограничение length обрабатывается аналогично ограничению range для численных типов (10.53.9. Численные типы):

Если выражение для размер имеет просто один диапазон:

при указании одного числа LENGTH используется <rng:param name=»length»>LENGTH</rng:param>;
при указании в форме LO..HI (обе границы), вставляются элементы <rng:param name=»minLength»>LO</rng:param> и <rng:param name=»maxLength»>HI</rng:param>.

Если LO имеет значение min, граница minLength опускается, если HI имеет значение max, опускается maxLength. Если в выражении для размера имеется несколько частей, разделённых |, элемент <rng:data> должен применяться для каждой такой части, а все эти элементы <rng:data> заключаются в элемент <rng:choice>. Каждый элемент <rng:data> содержит значение length или границы minLength и maxLength для одной части ограничения.

Каждое ограничение pattern для одного типа данных string отображается в блок pattern

   <rng:param name="pattern">...</rng:param>

с текстом, эквивалентным аргументу pattern. Такие блоки pattern должны повторяться внутри каждого элемента <rng:data>, т. е. по одному на каждую часть диапазона размера. Например,

   type string {
       length "1|3..8";
       pattern "[A-Z][a-z]*";
   }

отображается в приведённый ниже фрагмент RELAX NG.

   <rng:choice>
     <rng:data type="string">
       <rng:param name="length">1</rng:param>
       <rng:param name="pattern">[A-Z][a-z]*</rng:param>
     </rng:data>
     <rng:data type="string">
       <rng:param name="minLength">3</rng:param>
       <rng:param name="maxLength">8</rng:param>
       <rng:param name="pattern">[A-Z][a-z]*</rng:param>
     </rng:data>
   </rng:choice>

10.53.11. Производные типы

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

Без ограничений type отображается в элемент <rng:ref> , т. е. ссылку на именованный шаблон. Если определения этого именованного шаблона ещё нет в гибридной схеме RELAX NG, должно быть найдено определение соответствующего типа и включено как субэлемент корневого или встроенного элемента <rng:grammar> (см. 10.54. Оператор typedef). Даже при неоднократном использовании производного типа во входных модулях YANG, соответствующее отображение typedef должно устанавливаться 1 раз.
При наличии ограничения нужно определить встроенного предка производного типа, а затем должно применяться отображение для этого базового типа. Все ограничения, указанные в цепочке производного типа должны учитываться, а их комбинация добавляется в элемент <rng:data>, определяющий базовый тип.

Дополнительные детали и пример приведены в параграфе 9.2. Отображение группировок и определений типов YANG.

10.54. Оператор typedef

Этот оператор отображается в определение именованного шаблона RELAX NG <rng:define>, но лишь при отсутствии ограничений при использовании заданного оператором типа во входных модулях. В этом случае определение именованного шаблона становится потомком корневого или встроенного элемента <rng:grammar> в зависимости от присутствия оператора typedef на верхнем уровне модуля YANG. Именем этого определения шаблона будет значение ARGUMENT, преобразованное в соотсветствии с правилами параграфа 9.2. Отображение группировок и определений типов YANG.

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

Реализация может предложить запись всех операторов typedef как именованных шаблонов выходной схемы RELAX NG, даже если на эти типы не ссылаются. Это полезно для отображения библиотечных модулей YANG, содержащих лишь typedef и grouping.

10.55. Оператор unique

Этот оператор отображается в элемент <nma:unique>. Значение ARGUMENT должно транслироваться так, чтобы каждый идентификатор узла в каждом из его компонентов имел префикс пространства имён локального модуля, если такого префикса ещё нет. Результат трансляции будет значением аргумента @tag, присоединяемого к <nma:unique>¹⁰.

Предположим, что локальный модуль имеет префикс ex. Тогда unique «foo ex:bar/baz» отображается в пару атрибут-значение nma:unique=»ex:foo ex:bar/ex:baz»

10.56. Оператор units

Этот оператор отображается в атрибут @nma:units attribute and ARGUMENT becomes its value.

10.57. Оператор uses

При отсутствии субоператора refine или augment этот оператор отображается в элемент <rng:ref>, т. е. ссылку на именованный шаблон, а значением его атрибута @name будет ARGUMENT после преобразования в соответствии с параграфом 9.2. Отображение группировок и определений типов YANG. Если определения RELAX NG для этого именованного шаблона ещё нет, должна быть найдена соответствующая группировка с установкой её отображения как субэлемента <rng:grammar>, см. параграф 10.20. Оператор grouping. Если же оператор uses имеет субоператор refine или augment, должна отыскиваться соответствующая группировка со вставкой её содержимого в PARENT. Дополнительные детали и пример приведены в параграфе 9.2.1. Уточнения и дополнения YANG.

10.58. Оператор value

Этот оператор игнорируется.

10.59. Оператор when

Этот оператор отображается в атрибут @nma:when со значением ARGUMENT, преобразованным в соответствии с параграфом 9.3. Трансляция выражений XPath.

10.60. Оператор yang-version

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

10.61. Оператор yin-element

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

11. Отображение гибридной схемы в DSDL

Как указано в разделе 6, второй этап отображения YANG в DSDL принимает гибридную схему и преобразует её в различные схемы DSDL, пригодня для проверки экземпляров документов XML. В простейшем случае входным параметром этого этапа является просто спецификация типа проверяемого документа NETCONF XML. Таким типом может быть, например, содержимое хранилища данных, отклик на <nc:get> или <nc:get-config>, содержимое запросов и откликов RPC или уведомлений о событиях и т. п.

На этом этапе выполняются три основных задачи.

Извлечение частей гибридной схемы, соответствующих запрошенному типу документа, например, для отклика на <nc:get> это будет ветвь <nma:data>.
Адаптация схемы к конкретным элементам инкапсуляции XML, требуемым уровнем RPC. Например, это могут быть <nc:rpc> и <nc:data> для отклика на <nc:get> или <en:notification> для уведомления.
Сопоставление относящихся к NETMOD аннотаций, относящихся к отображаемому языку схемы с соответствующими шаблонами и правилами.

Эти 3 задачи вместе проще первого этапа отображения и могут быть реализованы с помощью преобразований XSL [XSLT]. В последующих параграфах подробно описан этот этап для отдельных языков схем DSDL. Затем в разделе 12 приведена подробная спецификация отображений всех аннотаций, специфичных для NETMOD.

11.1. Генерация схем RELAX NG для разных типов документов

За одним небольшим исключением, получение проверочной схемы RELAX NG из гибридной схемы состоит лишь в извлечении подходящих частей гибридной схемы и сборки из них новой грамматики RELAX NG (возможно, с удалением ненужных аннотаций). Структура результирующей схемы RELAX NG похожа на структуру гибридной схемы — корневой блок (grammar) содержит встроенные блоки, по одному для каждого входного модуля YANG. Однако, как отмечено в параграфе 8.2. Модульность, определения глобальных именованных шаблонов (потомки корневого элемента <rng:grammar>) должны размещаться в отдельном файле схемы.

В зависимости от типа целевого документа XML для проверки, такого как отклик на <nc:get> или <nc:get-config>, операции RPC или уведомления, должны добавляться шаблоны, задающие соответствующие сведения верхнего уровня, такие как <nc:rpc-reply> с атрибутом @message-id и т. п.

Чтобы избежать копирования общих определений именованных шаблонов для базовых элементов и атрибутов NETCONF в каждый выходной файл RELAX NG, такие независимые от схемы определения следует собирать в файл библиотеки, включаемый затем в проверяемые схемы RELAX NG (пример такого файла представлен в Приложении B).

Незначительное исключение, отмеченное выше, — это аннотация @nma:config, которая должна присутствовать, если целевым типом документа является <nc:get-config>. В таком случае определения элементов, в которых этот атрибут имеет значение false, должны удаляться из схемы вместе с его потомками (см. 12.1. Аннотация @nma:config).

11.2. Отображение семантических ограничений в Schematron

Схемы Schematron обычно более плоские и однородные, нежели RELAX NG, и имеют ровно 4 уровня иерархии XML — <sch: schema>, <sch:pattern>, <sch:rule> и <sch:assert> или <sch:report>. В схемах Schematron, создаваемых на втором этапе базой организации является правило, представленное элементом <sch:rule>. В соответствующие правила Schematron из гибридной схемы отображаются связанные с NETMOD аннотации (далее, семантические аннотации) <nma:must>, <nma:unique>, @nma:key, @nma:max-elements, @nma:min-elements, @nma:when, @nma:leafref, @nma:leaf-list, а также @nma:mandatory как атрибут <rng: choice> (см. 11.2.1. Ограничения для обязательного choice)¹¹.

Каждый входной модуль YANG отображается в шаблон Schematron, атрибут @id которого получает имя модуля в качестве значения. Каждый шаблон <rng:element>, содержащий хотя бы 1 семантическую аннотацию, отображается в правило Schematron.

   <sch:rule context="XELEM">
     ...
   </sch:rule>

В качестве значения обязательного атрибута @context правила <sch:rule> (обозначается как XELEM) должен быть указан абсолютный путь к элементу контекста в дереве данных. Элемент <sch:rule> содержит отображения всех включённых семантических аннотаций в форме утверждений или отчетов Schematron.

Семантические аннотации в определении именованного шаблона (т. е. имеющие <rng:define> среди предков) требуют особого отношения, поскольку могут применяться в разном контексте. Это достигается за счёт применения разных абстрактных шаблонов Schematron, использующих переменную $pref вместо префикса локального пространства имён. Значением атрибута @id такого абстрактного шаблона должно быть имя определения шаблона, который отображается (т. е. преобразованное имя исходной группировки YANG). При создании экземпляра абстрактного шаблона должны предоставляться значения двух параметров:

pref — фактический префикс пространства имён;
start — выражение XPath, задающее контекст, где применяется группировка.

Рассмотрим в качестве примера приведённый ниже модуль YANG.

module example4 {
  namespace "http://example.com/ns/example4";
  prefix ex4;
  uses sorted-leaf-list;
  grouping sorted-leaf-list {
    leaf-list sorted-entry {
      must "not(preceding-sibling::sorted-entry > .)" {
        error-message "Записи должны быть упорядочены по возрастанию.";
      }
      type uint8;
    }
  }
}

Результирующая схема Schematron для отклика <nc:get> будет иметь вид

   <?xml version="1.0" encoding="utf-8"?>
   <sch:schema xmlns:sch="http://purl.oclc.org/dsdl/schematron"> 
     <sch:ns uri="http://example.com/ns/example4" prefix="ex4"/>
     <sch:ns uri="urn:ietf:params:xml:ns:netconf:base:1.0"
             prefix="nc"/>
     <sch:pattern abstract="true"
                  id="_example4__sorted-leaf-list">
       <sch:rule context="$start/$pref:sorted-entry">
         <sch:report
             test=". = preceding-sibling::$pref:sorted-entry">
           Дубликат записи leaf-list "<sch:value-of select="."/>".
         </sch:report>
         <sch:assert
             test="not(preceding-sibling::$pref:sorted-entry &gt; .)">
           Записи должны быть упорядочены по возрастанию.
         </sch:assert>
       </sch:rule>
     </sch:pattern>
     <sch:pattern id="example4"/>
     <sch:pattern id="id2573371" is-a="_example4__sorted-leaf-list">
       <sch:param name="start" value="/nc:rpc-reply/nc:data"/>
       <sch:param name="pref" value="ex4"/>
     </sch:pattern>
   </sch:schema>

Группировка sorted-leaf-list из входного модуля отображается в абстрактный шаблон с атрибутом @id, имеющим значение _example4__sorted-leaf-list, в котором оператору must соответствует элемент <sch:assert>. Из абстрактного шаблона создаётся экземпляр с @id id2573371, который устанавливает значение параметров start и pref.

Отметим, что автоматически добавлен элемент Schematron <sch:report>, проверяющий дубликаты записей leaf-list.

Отображение гибридной схемы в Schematron выполняется за несколько этапов.

Выбирается активная ветвь (ветви) гибридной схемы в зависимости от запрошенного типа целевого документа. Эта процедура аналогична случаю RELAX NG, включая обработку @nma:config для целевого типа отклика на <nc:get-config>.
Должны объявляться пространства имён всех входных модулей YANG вместе с пространствами имён базового NETCONF (префикс nc ) или уведомлений (префикс en) с применением элемента <sch:ns>, например, <sch:ns uri=»http://example.com/ns/example4″ prefix=»ex4″/>
Создаётся 1 шаблон для каждого входного модуля, а также абстрактные шаблоны, для каждого определения именованного шаблона, содержащего одну или несколько семантических аннотаций.
Создаётся элемент <sch:rule> для каждого шаблона элемента, содержащего семантические аннотации.
Каждая такая аннотация отображается в элемент <sch:assert> или <sch:report>, устанавливаемый как потомок элемента <sch:rule>.

11.2.1. Ограничения для обязательного choice

Для полного представления семантики оператора YANG choice с субоператором mandatory true грамматика RELAX NG должна сочетаться со специальным правилом Schematron. Рассмотрим в качестве примера показанный ниже модуль.

   module example5 {
       namespace "http://example.com/ns/example5";
       prefix ex5;
       choice foobar {
           mandatory true;
           case foo {
               leaf foo1 {
                   type uint8;
               }
               leaf foo2 {
                   type uint8;
               }
           }
           leaf bar {
               type uint8;
           }
       }
   }

Здесь все три узла leaf в обеих ветвях case являются необязательными, но из-за оператора mandatory true в choice хотя бы один из этих узлов должен присутствовать в действительной конфигурации. Оператор choice из этого модуля отображается в приведённый ниже фрагмент схемы RELAX NG.

   <rng:choice>
     <rng:interleave>
       <rng:optional>
         <rng:element name="ex5:foo1">
           <rng:data type="unsignedByte"/>
         </rng:element>
       </rng:optional>
       <rng:optional>
         <rng:element name="ex5:foo2">
           <rng:data type="unsignedByte"/>
         </rng:element>
       </rng:optional>
     </rng:interleave>
     <rng:element name="ex5:bar">
       <rng:data type="unsignedByte"/>
     </rng:element>
   </rng:choice>

Во второй ветви case элемент ex5:bar определён как обязательный, поэтому он должен присутствовать в допустимой конфигурации, если эта ветвь выбрана. Однако оба элемента первой ветви foo не могут быть объявлены обязательными, поскольку любого из них достаточно для пригодной конфигурации. В результате приведённый выше фрагмент RELAX NG будет подтверждать конфигурации, где нет ни одного из трёх листьев.

Поэтому обязательные choice, которые могут быть распознаны в гибридной схеме как элементы <rng:choice> с аннотацией @nma:mandatory, обрабатываются особым способом. Для каждого обязательного choice, где хотя бы один из вариантов содержит более 1 узла, должно добавляться правило Schematron, обеспечивающее наличие хотя бы одного узла из любого такого case (схема RELAX NG гарантирует, что элементы из разных case не перемешиваются, обязательные узлы присутствуют и т. д.).

Для приведённого выше примера правило Schematron будет иметь вид

   <sch:rule context="/nc:rpc-reply/nc:data">
     <sch:assert test="ex5:foo1 or ex5:foo2 or ex5:bar">
       Должен быть узел хотя бы из 1 case оператора choice foobar.
     </sch:assert>
   </sch:rule>

11.3. Отображение принятых по умолчанию значений в DSRL

DSRL — единственный компонент DSDL, которому разрешено менять набор информации в проверенных документах XML. Хотя в DSRL имеются и другие функции, отображение YANG-DSDL использует лишь задание и применение принятого по умолчанию содержимого. Для экземпляров документов XML, основанных на моделях данных YANG, вставка принятого по умолчанию содержимого может выполняться для всех неявных узлов, идентифицированных по правилам параграфа 9.2.1. Уточнения и дополнения YANG.

В DSRL принятое по умолчанию содержимое элемента задаётся с использованием элемента <dsrl:default-content>, являющегося потомком <dsrl:element-map>. Два братских (sibling) элемента <dsrl:default-content> определяют контекст для применения заданного по умолчанию содержимого (см. [DSRL]):

элемент <dsrl:parent> содержит шаблон XSLT, задающий родительский элемент и заданное по умолчанию содержимое применяется лишь при наличии этого родителя в экземпляре документа;
<dsrl:name> содержит имя XML элемента, который, будучи отсутствующим или пустым, вставляется вместе с содержимым <dsrl: default-content>.

Элемент <dsrl:parent> является необязательным в базовой схеме DSRL, но для отображения YANG-DSDL этот элемент должен присутствовать для гарантии корректного применения заданного по умолчанию содержимого.

Отображение DSRL работает лишь с определяющими неявные узлы шаблонами <rng:element> из гибридной схемы (см. 9.1.2. Неявные узлы). Такие шаблоны элементов отличаются наличием специфичных для NETMOD атрибутов аннотаций @nma:default или @nma:implicit, т. е.

   <rng:element name="ELEM" nma:default="DEFVALUE">
     ...
   </rng:element>

или

   <rng:element name="ELEM" nma:implicit="true">
     ...
   </rng:element>

Первый вариант применяется к узлам leaf, имеющим субоператор default, а также к узлам leaf, получающим заданные по умолчанию значения от typedef, если это определение типа преобразуется по правилам параграфа 9.2. Отображение группировок и определений типов YANG, так что аннотация @nma:default присоединяется напрямую к шаблону элемента. Второй вариант применяется для всех неявных контейнеров (9.1. Правила вхождения для узлов данных) и leaf, которые получают заданное по умолчанию значение от typedef и не имеют аннотации @nma:default.

В простейшем случае оба шаблона элементов отображаются в приведённый ниже фрагмент DSRL.

   <dsrl:element-map>
     <dsrl:parent>XPARENT</dsrl:parent>
     <dsrl:name>ELEM</dsrl:name>
     <dsrl:default-content>DEFCONT</dsrl:default-content>
   </dsrl:element-map>

где XPARENT — абсолютный XPath родительского элемента ELEM в дереве данных, а DEFCONT строится, как показано ниже.

Если неявный узел ELEM является листом (leaf) и имеет атрибут @nma:default, для DEFCONT устанавливается значение этого атрибута (DEFVALUE).
Если неявный узел ELEM является листом и имеет атрибут @nma:implicit со значением true, принятое по умолчанию значение определяется из атрибута @nma:default в определении типа ELEM (возможно, рекурсивно) и применяется вместо DEFCONT в приведённом выше элементе DSRL (см. 9.2.2. Цепочки производных типов).
В остальных случаях неявный узел ELEM является контейнером и DEFCONT строится как фрагмент XML, содержащий все элементы-потомки ELEM с атрибутом @nma:implicit или @nma:default.

Кроме того, при отображении принятого по умолчанию case из оператора choice нужно гаратировать, что принятое по умолчанию содержимое не применяется, если имеется какой-либо из вариантов (case), не заданных по умолчанию. Это достигается установкой <dsrl:parent> особым способом <dsrl:parent>XPARENT[not (ELEM1|ELEM2|…|ELEMn)]</dsrl:parent>, где ELEM1, ELEM2, … ELEMn — имена всех узлов верхнего уровня из всех case, на заданных по умолчанию. Остальная часть элемента не меняется.

Рассмотрим в качестве примера модуль YANG, показанный ниже.

   module example6 {
     namespace "http://example.com/ns/example6";
     prefix ex6;
     container outer {
       leaf leaf1 {
         type uint8;
         default 1;
       }
       choice one-or-two {
         default "one";
         container one {
           leaf leaf2 {
             type uint8;
             default 2;
           }
         }
         leaf leaf3 {
           type uint8;
           default 3;
         }
       }
     }
   }

Схема DSRL для целевого документа get-reply имеет вид

   <?xml version="1.0" encoding="utf-8"?>
   <dsrl:maps xmlns:dsrl="http://purl.oclc.org/dsdl/dsrl" 
              xmlns:ex6="http://example.com/ns/example6"
              xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
     <dsrl:element-map>
       <dsrl:parent>/nc:rpc-reply/nc:data</dsrl:parent>
       <dsrl:name>ex6:outer</dsrl:name>
       <dsrl:default-content>
         <ex6:leaf1>1</ex6:leaf1>
         <ex6:one>
           <ex6:leaf2>2</ex6:leaf2>
         </ex6:one>
       </dsrl:default-content>
     </dsrl:element-map>
     <dsrl:element-map>
       <dsrl:parent>/nc:rpc-reply/nc:data/ex6:outer</dsrl:parent>
       <dsrl:name>ex6:leaf1</dsrl:name>
       <dsrl:default-content>1</dsrl:default-content>
     </dsrl:element-map>
     <dsrl:element-map>
       <dsrl:parent>
         /nc:rpc-reply/nc:data/ex6:outer[not(ex6:leaf3)]
       </dsrl:parent>
       <dsrl:name>ex6:one</dsrl:name>
       <dsrl:default-content>
         <ex6:leaf2>2</ex6:leaf2>
       </dsrl:default-content>
     </dsrl:element-map>
     <dsrl:element-map>
       <dsrl:parent>
         /nc:rpc-reply/nc:data/ex6:outer/ex6:one
       </dsrl:parent>
       <dsrl:name>ex6:leaf2</dsrl:name>
       <dsrl:default-content>2</dsrl:default-content>
     </dsrl:element-map>
   </dsrl:maps>

Отметим, что принятое по умолчанию значение для leaf3, заданное в модуле YANG, игнорируется, поскольку leaf3 не представляет принятый по умолчанию вариант choice и поэтому не становится неявным элементом.

12. Отображение аннотаций NETMOD в языки схем DSDL

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

12.1. Аннотация @nma:config

Если эта аннотация присутствует со значением false, должны соблюдаться приведённые ниже правила для схем DSDL откликов на <nc:get-config>.

При генерации RELAX NG содержимое определения CONTELEM должно заменяться на <rng:notAllowed>.
При генерации Schematron или DSRL определение CONTELEM и все его потомки в гибридной схеме должны игнорироваться.

12.2. Аннотация @nma:default

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

12.3. Аннотация <nma:error-app-tag>

Для этой аннотации с настоящее время не задано отображения.

12.4. Аннотация <nma:error-message>

Эта аннотация обрабатывается в рамках <nma:must>, см. параграф 12.13. Аннотация <nma:must>.

12.5. Аннотация @if-feature

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

При генерации RELAX NG CONTELEM должно заменяться на <rng:notAllowed>.
При генерации Schematron или DSRL определение CONTELEM и все его потомки в гибридной схеме должны игнорироваться.

12.6. Аннотация @nma:implicit

12.7. Аннотация <nma:instance-identifier>

Если этот элемент аннотации имеет атрибут @require-instance со значением false, он игнорируется. В ином случае элемент отображается в утверждение Schematron

   <sch:assert test="nmf:evaluate(.)">
     Элемент, указанный CONTELEM, должен существовать.
   </sch:assert>

Функция nmf:evaluate() является функцией преобразования XSLT (см. Extension Functions в [XSLT]), которая оценивает выражение XPath во время исполнения. Такая функция расширения доступна в Extended XSLT (EXSLT) или предоставляется как фирменное (proprietary) расширение некоторыми процессорами XSLT (например, Saxon).

12.8. Аннотация @nma:key

Предположим, что этот атрибут аннотации содержит k_1 k_2 … k_n, т. е. задаёт n потомков CONTELEM как ключи списка. Тогда аннотация отображается в показанный ниже отчёт Schematron.

   <sch:report test="CONDITION">
     Дубликат ключа списка CONTELEM
   </sch:report>

где CONDITION имеет вид preceding-sibling::CONTELEM[C_1 and C_2 and … and C_n]. Каждое субвыражение C_i для i=1,2,…,n задаёт условие неуникальности ключа k_i, а именно k_i=current()/k_i.

12.9. Аннотация @nma:leaf-list

Эта аннотация отображается в приведённое ниже правило Schematron, которое находит дубликаты записей в leaf-list.

   <sch:report
       test=". = preceding-sibling::PREFIX:sorted-entry">
     Дубликат записи leaf-list "<sch:value-of select="."/>".
   </sch:report>

Полный пример представлен в параграфе 11.2. Отображение семантических ограничений в Schematron.

12.10. Аннотация @nma:leafref

Эта аннотация отображается в приведённое ниже утверждение.

   <sch:assert test="PATH=.">
     Листа PATH не существует для leafref со значением VALUE
   </sch:assert>

где PATH — значение @nma:leafref, VALUE — значение элемента контекста в экземпляре документа, для которого указанный лист (leaf) не существует.

12.11. Аннотация @nma:min-elements

Эта аннотация отображается в приведённое ниже утверждение Schematron.

   <sch:assert test="count(../CONTELEM)&gt;=MIN">
     Список CONTELEM — число элементов должно быть не меньше MIN
   </sch:assert>

где MIN — значение @nma:min-elements.

12.12. Аннотация @nma:max-elements

Эта аннотация отображается в приведённое ниже утверждение Schematron.

<sch:assert
    test="count(../CONTELEM)&lt;=MAX or preceding-sibling::../CONTELEM">
  Число элементов списка должно быть не больше MAX
</sch:assert>

где MAX — значение @nma:max-elements.

12.13. Аннотация <nma:must>

Эта аннотация отображается в приведённое ниже Schematron.

   <sch:assert test="EXPRESSION">
     MESSAGE
   </sch:assert>

где EXPRESSION — значение атрибута @assert для <nma:must>. Если субэлемент <nma:error-message> существует, в MESSAGE помещается его содержимое, иначе — принятое по умолчанию сообщение Condition EXPRESSION must be true.

12.14. Аннотация <nma:ordered-by>

Для этой аннотации с настоящее время не задано отображения.

12.15. Аннотация <nma:status>

Для этой аннотации с настоящее время не задано отображения.

12.16. Аннотация <nma:unique>¹²

Отображение этой аннотации похоже на @nma:key (12.7. Аннотация <nma:instance-identifier>) с двумя отличиями.

Значением атрибута @tag для <nma:unique> является список идентификаторов узлов-потомков, а не имён простых leaf. Обнако выражение XPath, заданное в параграфе 12.8, работает без изменений, если идентификаторы узлов-потомков заменяются на k_1, k_2, …, k_n.
Сообщение, отображаемое как текст <sch:report>, отличается — Violated uniqueness of NODES (нарушена уникальность NODES), где NODES — значение атрибута @tag.

12.17. Аннотация @nma:when

Эта аннотация отображается в приведённое ниже утверждение Schematron.

   <sch:assert test="EXPRESSION">
     Узел CONTELEM действителен лишь при EXPRESSION true.
   </sch:assert>

где EXPRESSION — значение @nma:when.

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

Этот документ запрашивает регистрацию двух URI пространств имён в реестре IETF XML [RFC3688]

   URI: urn:ietf:params:xml:ns:netmod:dsdl-annotations:1
   Registrant Contact: The IESG.
   XML: N/A, запрошенный URI является пространством имён XML.

   URI: urn:ietf:params:xml:ns:netmod:xpath-extensions:1
   Registrant Contact: The IESG.
   XML: N/A, запрошенный URI является пространством имён XML.

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

Этот документ определяет процедуру отображения моделей данных на языке YANG в согласованный набор схем DSDL. Процедура сама по себе не влияет на безопасность Internet.

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

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

Ниже указаны люди, внёсшие значительный вклад в начальный вариант этого документа.

Rohan Mahy
Sharon Chisholm (Ciena)

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

Редактор хотел бы поблагодарить за предоставленные полезные предложения и комментарии к разным версиям этого документа Andy Bierman, Martin Bjorklund, Jirka Kosek, Juergen Schoenwaelder, Phil Shafer.

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

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

[DSDL] ISO/IEC, «Document Schema Definition Languages (DSDL) — Part 1: Overview», ISO/IEC 19757-1, November 2004.

[DSRL] ISO/IEC, «Information Technology — Document Schema Definition Languages (DSDL) — Part 8: Document Semantics Renaming Language — DSRL», ISO/IEC 19757-8:2008(E), December 2008.

[RFC2119] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, March 1997.

[RFC3688] Mealling, M., «The IETF XML Registry», BCP 81, RFC 3688, January 2004.

[RFC4741] Enns, R., «NETCONF Configuration Protocol», RFC 4741, December 2006.

[RFC6020] Bjorklund, M., Ed., «YANG — A Data Modeling Language for Network Configuration Protocol (NETCONF)», RFC 6020, October 2010.

[RFC6021] Schoenwaelder, J., Ed., «Common YANG Data Types», RFC 6021, October 2010.

[RNG] ISO/IEC, «Information Technology — Document Schema Definition Languages (DSDL) — Part 2: Regular-Grammar-Based Validation — RELAX NG. Second Edition.», ISO/IEC 19757-2:2008(E), December 2008.

[RNG-CS] ISO/IEC, «Information Technology — Document Schema Definition Languages (DSDL) — Part 2: Regular-Grammar-Based Validation — RELAX NG. AMENDMENT 1: Compact Syntax», ISO/IEC 19757-2:2003/Amd. 1:2006(E), January 2006.

[RNG-DTD] Clark, J., Ed. and M. Murata, Ed., «RELAX NG DTD Compatibility», OASIS Committee Specification, 3 December 2001.

[Schematron] ISO/IEC, «Information Technology — Document Schema Definition Languages (DSDL) — Part 3: Rule-Based Validation — Schematron», ISO/IEC 19757-3:2006(E), June 2006.

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

[XML-INFOSET] Tobin, R. and J. Cowan, «XML Information Set (Second Edition)», World Wide Web Consortium Recommendation REC-xml-infoset-20040204, February 2004, <http://www.w3.org/TR/2004/REC-xml-infoset-20040204>.

[XPath] Clark, J. and S. DeRose, «XML Path Language (XPath) Version 1.0», World Wide Web Consortium Recommendation REC-xpath-19991116, November 1999, <http://www.w3.org/TR/1999/REC-xpath-19991116>.

[XSD-D] Biron, P. and A. Malhotra, «XML Schema Part 2: Datatypes Second Edition», World Wide Web Consortium Recommendation REC-xmlschema-2-20041028, October 2004, <http://www.w3.org/TR/2004/REC-xmlschema-2-20041028>.

[XSLT] Clark, J., «XSL Transformations (XSLT) Version 1.0», World Wide Web Consortium Recommendation REC-xslt-19991116, November 1999.

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

[DHCPtut] Bjorklund, M., «DHCP Tutorial», November 2007, <http://www.yang-central.org/twiki/bin/view/Main/DhcpTutorial>.

[RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, «Simple Network Management Protocol (SNMP)», RFC 1157, May 1990.

[RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., «Structure of Management Information Version 2 (SMIv2)», STD 58, RFC 2578, April 1999.

[RFC5013] Kunze, J., «The Dublin Core Metadata Element Set», RFC 5013, August 2007.

[RFC5277] Chisholm, S. and H. Trevino, «NETCONF Event Notifications», RFC 5277, July 2008.

[Trang] Clark, J., «Trang: Multiformat schema converter based on RELAX NG», 2008, <http://www.thaiopensource.com/relaxng/trang.html>.

[Vli04] van der Vlist, E., «RELAX NG», O’Reilly, 2004.

[XSD] Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, «XML Schema Part 1: Structures Second Edition», World Wide Web Consortium Recommendation REC-xmlschema-1-20041028, October 2004, <http://www.w3.org/TR/2004/REC-xmlschema-1-20041028>.

[pyang] Bjorklund, M. and L. Lhotka, «pyang: An extensible YANG validator and converter in Python», 2010, <http://code.google.com/p/pyang/>.

Приложение A. Схема RELAX NG для связанных с NETMOD аннотаций

В этом приложении задана модель содержимого для всех относящихся к NETMOD аннотаций в форме определений именованных шаблонов RELAX NG.

  <CODE BEGINS> file "nmannot.rng"

  <?xml version="1.0" encoding="UTF-8"?>
  <grammar xmlns="http://relaxng.org/ns/structure/1.0" 
           xmlns:nma="urn:ietf:params:xml:ns:netmod:dsdl-annotations:1"
           datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes"> 

  <define name="config-attribute">
    <attribute name="nma:config">
      <data type="boolean"/>
    </attribute>
  </define>

  <define name="data-element">
    <element name="nma:data">
      <ref name="__anyxml__"/>
    </element>
  </define>

  <define name="default-attribute">
    <attribute name="nma:default">
      <data type="string"/>
    </attribute>
  </define>

  <define name="error-app-tag-element">
    <element name="nma:error-app-tag">
      <text/>
    </element>
  </define>

  <define name="error-message-element">
    <element name="nma:error-message">
      <text/>
    </element>
  </define>

  <define name="if-feature-attribute">
    <attribute name="nma:if-feature">
      <list>
        <data type="QName"/>
      </list>
    </attribute>
  </define>

  <define name="implicit-attribute">
    <attribute name="nma:implicit">
      <data type="boolean"/>
    </attribute>
  </define>

  <define name="instance-identifier-element">
    <element name="nma:instance-identifier">
      <optional>
        <attribute name="nma:require-instance">
          <data type="boolean"/>
        </attribute>
      </optional>
    </element>
  </define>

  <define name="key-attribute">
    <attribute name="nma:key">
      <list>
        <data type="QName"/>
      </list>
    </attribute>
  </define>

  <define name="leaf-list-attribute">
    <attribute name="nma:leaf-list">
      <data type="boolean"/>
    </attribute>
  </define>

  <define name="leafref-attribute">
    <attribute name="nma:leafref">
      <data type="string"/>
    </attribute>
  </define>

  <define name="mandatory-attribute">
    <attribute name="nma:mandatory">
      <data type="Name"/>
    </attribute>
  </define>

  <define name="max-elements-attribute">
    <attribute name="nma:max-elements">
      <data type="nonNegativeInteger"/>
    </attribute>
  </define>

  <define name="min-elements-attribute">
    <attribute name="nma:min-elements">
      <data type="nonNegativeInteger"/>
    </attribute>
  </define>

  <define name="module-attribute">
    <attribute name="nma:module">
      <data type="Name"/>
    </attribute>
  </define>

  <define name="must-element">
    <element name="nma:must">
      <attribute name="assert">
        <data type="string"/>
      </attribute>
      <interleave>
        <optional>
          <ref name="error-app-tag-element"/>
        </optional>
        <optional>
          <ref name="error-message-element"/>
        </optional>
      </interleave>
    </element>
  </define>

  <define name="notifications-element">
    <element name="nma:notifications">
      <zeroOrMore>
        <element name="nma:notification">
          <ref name="__anyxml__"/>
        </element>
      </zeroOrMore>
    </element>
  </define>

  <define name="rpcs-element">
    <element name="nma:rpcs">
      <zeroOrMore>
        <element name="nma:rpc">
          <interleave>
            <element name="nma:input">
              <ref name="__anyxml__"/>
            </element>
            <optional>
              <element name="nma:output">
                <ref name="__anyxml__"/>
              </element>
            </optional>
          </interleave>
        </element>
      </zeroOrMore>
    </element>
  </define>

  <define name="ordered-by-attribute">
    <attribute name="nma:ordered-by">
      <choice>
        <value>user</value>
        <value>system</value>
      </choice>
    </attribute>
  </define>

  <define name="status-attribute">
    <optional>
      <attribute name="nma:status">
        <choice>
          <value>current</value>
          <value>deprecated</value>
          <value>obsolete</value>
        </choice>
      </attribute>
    </optional>
  </define>

  <define name="unique-element">
    <element name="nma:unique">
      <attribute name="tag">
        <list>
          <data type="token"/>
        </list>
      </attribute>
    </element>
  </define>
  <define name="units-attribute">¹³
    <optional>
      <attribute name="nma:units">
        <data type="string"/>
      </attribute>
    </optional>
  </define>

  <define name="when-attribute">
    <optional>
      <attribute name="nma:when">
        <data type="string"/>
      </attribute>
    </optional>
  </define>

  <define name="__anyxml__">
    <zeroOrMore>
      <choice>
        <attribute>
          <anyName/>
        </attribute>
        <element>
          <anyName/>
          <ref name="__anyxml__"/>
        </element>
        <text/>
      </choice>
    </zeroOrMore>
  </define>

  </grammar>

  <CODE ENDS>

Приложение B. Независимая от схем библиотека

Во избежание копирования базовых определений именованных шаблонов в каждую создаваемую на втором этапе схему RELAX NG определения собраны в файлы независимой от схемы библиотеки, которые включаются проверяющими схемами по имени relaxng-lib.rng (синтаксис XML) и relaxng-lib.rnc (компактный синтаксис). Включённые определения охватывают шаблоны для основных элементов из базового NETCONF [RFC4741] и уведомления о событиях [RFC5277].

  <CODE BEGINS> file "relaxng-lib.rng"

  <?xml version="1.0" encoding="UTF-8"?>

  <grammar xmlns="http://relaxng.org/ns/structure/1.0" 
           xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"
           xmlns:en="urn:ietf:params:xml:ns:netconf:notification:1.0"
           datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes"> 

    <define name="message-id-attribute">
      <attribute name="message-id">
        <data type="string">
          <param name="maxLength">4095</param>
        </data>
      </attribute>
    </define>

    <define name="ok-element">
      <element name="nc:ok">
        <empty/>
      </element>
    </define>

    <define name="eventTime-element">
      <element name="en:eventTime">
        <data type="dateTime"/>
      </element>
    </define>
  </grammar>

  <CODE ENDS>

Приложение C. Сопоставление модели данных DHCP — полный пример

В этом приложении показаны оба этапа отображения YANG-DSDL для «канонической» модели данных из учебника по DHCP [DHCPtut]. Входной модуль YANG представлен в Приложении C.1, а выходные схемы — в двух последующих.

Гибридная схема была получена с помощью плагина dsdl для pyang [pyang], а проверка схем DSDL была выполнена с помощью таблиц стилей XSLT, также входящих в пакет pyang.

Из-за ограничения размера строк (72 символа) некоторые длинные строки были отредактированы вручную (шаблоны регулярных выражений для адресов IP и т. п.). В некоторые строки были добавлены символы переноса \ (документация и сообщения Schematron). В остальном результаты автоматической трансляции не изменялись.

C.1. Входной модуль YANG

   module dhcp {
     namespace "http://example.com/ns/dhcp";
     prefix dhcp;

     import ietf-yang-types { prefix yang; }
     import ietf-inet-types { prefix inet; }

     organization
       "yang-central.org";
     description
       "Частичная модель данных DHCP на основе эталонной реализации
        ISC DHCP.";

     container dhcp {
       description
         "Конфигурационные и рабочие параметры сервера DHCP.";

       leaf max-lease-time {
         type uint32;
         units seconds;
         default 7200;
       }

       leaf default-lease-time {
         type uint32;
         units seconds;
         must '. <= ../max-lease-time' {
           error-message
             "default-lease-time должно быть не больше max-lease-time";
         }
         default 600;
       }

       uses subnet-list;

       container shared-networks {
         list shared-network {
           key name;

           leaf name {
             type string;
           }
           uses subnet-list;
         }
       }

       container status {
         config false;
         list leases {
           key address;
           leaf address {
             type inet:ip-address;
           }
           leaf starts {
             type yang:date-and-time;
           }
           leaf ends {
             type yang:date-and-time;
           }
           container hardware {
             leaf type {
               type enumeration {
                 enum "ethernet";
                 enum "token-ring";
                 enum "fddi";
               }
             }
             leaf address {
               type yang:phys-address;
             }
           }
         }
       }
     }

     grouping subnet-list {
       description "Многократно применяемый список подсетей";
       list subnet {
         key net;
         leaf net {
           type inet:ip-prefix;
         }
         container range {
           presence "Разрешает динамическое назначение адресов";
           leaf dynamic-bootp {
             type empty;
             description
               "Разрешает клиентам BOOTP получать адреса из блока";
           }
           leaf low {
             type inet:ip-address;
             mandatory true;
           }
           leaf high {
             type inet:ip-address;
             mandatory true;
           }
         }
         container dhcp-options {
           description "Опции протокола DHCP";
           leaf-list router {
             type inet:host;
             ordered-by user;
             reference "Параграф 3.8 в RFC 2132";
           }
           leaf domain-name {
             type inet:domain-name;
             reference "Параграф 3.17 в RFC 2132";
           }
         }

         leaf max-lease-time {
           type uint32;
           units seconds;
           default 7200;
         }
       }
     }
   }

C.2. Гибридная схема

   <?xml version="1.0" encoding="UTF-8"?>
   <grammar
       xmlns="http://relaxng.org/ns/structure/1.0" 
       xmlns:nma="urn:ietf:params:xml:ns:netmod:dsdl-annotations:1" 
       xmlns:dc="http://purl.org/dc/terms"
       xmlns:a="http://relaxng.org/ns/compatibility/annotations/1.0" 
       xmlns:dhcp="http://example.com/ns/dhcp"
       datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes"> 
    <dc:creator>Pyang 1.0a, DSDL plugin</dc:creator>
    <dc:date>2010-06-17</dc:date>
    <start>
     <grammar nma:module="dhcp" ns="http://example.com/ns/dhcp">
      <dc:source>YANG module 'dhcp'</dc:source>
      <start>
       <nma:data>
        <optional>
         <element nma:implicit="true" name="dhcp:dhcp">
          <interleave>
           <a:documentation>
            Конфигурационные и рабочие параметры сервера DHCP.
           </a:documentation>
           <optional>
            <element nma:default="7200"
                     name="dhcp:max-lease-time"
                     nma:units="seconds">
             <data type="unsignedInt"/>
            </element>
           </optional>
           <optional>
            <element nma:default="600"
                     name="dhcp:default-lease-time"
                     nma:units="seconds">
             <data type="unsignedInt"/>
             <nma:must assert=". &lt;= ../dhcp:max-lease-time">
              <nma:error-message>
               default-lease-time должно быть не больше max-lease-time
              </nma:error-message>
             </nma:must>
            </element>
           </optional>
           <ref name="_dhcp__subnet-list"/>
           <optional>
            <element name="dhcp:shared-networks">
             <zeroOrMore>
              <element nma:key="dhcp:name"
                       name="dhcp:shared-network">
               <element name="dhcp:name">
                <data type="string"/>
               </element>
               <ref name="_dhcp__subnet-list"/>
              </element>
             </zeroOrMore>
            </element>
           </optional>
           <optional>
            <element name="dhcp:status" nma:config="false">
             <zeroOrMore>
              <element nma:key="dhcp:address"
                       name="dhcp:leases">
               <element name="dhcp:address">
                <ref name="ietf-inet-types__ip-address"/>
               </element>
               <interleave>
                <optional>
                 <element name="dhcp:starts">
                  <ref name="ietf-yang-types__date-and-time"/>
                 </element>
                </optional>
                <optional>
                 <element name="dhcp:ends">
                  <ref name="ietf-yang-types__date-and-time"/>
                 </element>
                </optional>
                <optional>
                 <element name="dhcp:hardware">
                  <interleave>
                   <optional>
                    <element name="dhcp:type">
                     <choice>
                      <value>ethernet</value>
                      <value>token-ring</value>
                      <value>fddi</value>
                     </choice>
                    </element>
                   </optional>
                   <optional>
                    <element name="dhcp:address">
                     <ref name="ietf-yang-types__phys-address"/>
                    </element>
                   </optional>
                  </interleave>
                 </element>
                </optional>
               </interleave>
              </element>
             </zeroOrMore>
            </element>
           </optional>
          </interleave>
         </element>
        </optional>
       </nma:data>
       <nma:rpcs/>
       <nma:notifications/>
      </start>
     </grammar>
    </start>
    <define name="ietf-yang-types__phys-address">
     <data type="string">
      <param name="pattern">([0-9a-fA-F]{2}(:[0-9a-fA-F]{2})*)?</param>
     </data>
    </define>
    <define name="ietf-inet-types__ipv6-address">
     <data type="string">
      <param name="pattern">... шаблон regex ...</param>
      <param name="pattern">... шаблон regex ...</param>
     </data>
    </define>
    <define name="ietf-inet-types__ip-prefix">
     <choice>
      <ref name="ietf-inet-types__ipv4-prefix"/>
      <ref name="ietf-inet-types__ipv6-prefix"/>
     </choice>
    </define>
    <define name="ietf-inet-types__host">
     <choice>
      <ref name="ietf-inet-types__ip-address"/>
      <ref name="ietf-inet-types__domain-name"/>
     </choice>
    </define>
    <define name="ietf-yang-types__date-and-time">
     <data type="string">
      <param name="pattern">... шаблон regex ...</param>
     </data>
    </define>
    <define name="_dhcp__subnet-list">
     <a:documentation>Многократно применяемый список подсетей
     </a:documentation>
     <zeroOrMore>
      <element nma:key="net" name="subnet">
       <element name="net">
        <ref name="ietf-inet-types__ip-prefix"/>
       </element>
       <interleave>
        <optional>
         <element name="range">
          <interleave>
           <optional>
            <element name="dynamic-bootp">
             <a:documentation>
              Разрешает клиентам BOOTP получать адреса из блока
             </a:documentation>
             <empty/>
            </element>
           </optional>
           <element name="low">
            <ref name="ietf-inet-types__ip-address"/>
           </element>
           <element name="high">
            <ref name="ietf-inet-types__ip-address"/>
           </element>
          </interleave>
         </element>
        </optional>
        <optional>
         <element name="dhcp-options">
          <interleave>
           <a:documentation>
            Опции протокола DHCP
           </a:documentation>
           <zeroOrMore>
            <element nma:leaf-list="true" name="router"
                     nma:ordered-by="user">
             <a:documentation>
              См. параграф 3.8 в RFC 2132
             </a:documentation>
             <ref name="ietf-inet-types__host"/>
            </element>
           </zeroOrMore>
           <optional>
            <element name="domain-name">
             <a:documentation>
               См. параграф 3.17 в RFC 2132
             </a:documentation>
             <ref name="ietf-inet-types__domain-name"/>
            </element>
           </optional>
          </interleave>
         </element>
        </optional>
        <optional>
         <element nma:default="7200" name="max-lease-time"
                  nma:units="seconds">
          <data type="unsignedInt"/>
         </element>
        </optional>
       </interleave>
      </element>
     </zeroOrMore>
    </define>
    <define name="ietf-inet-types__domain-name">
     <data type="string">
      <param name="pattern">... шаблон regex ...</param>
      <param name="minLength">1</param>
      <param name="maxLength">253</param>
     </data>
    </define>
    <define name="ietf-inet-types__ipv4-prefix">
     <data type="string">
      <param name="pattern">... шаблон regex ...</param>
     </data>
    </define>
    <define name="ietf-inet-types__ipv4-address">
     <data type="string">
      <param name="pattern">... шаблон regex ...</param>
     </data>
    </define>
    <define name="ietf-inet-types__ipv6-prefix">
     <data type="string">
      <param name="pattern">... шаблон regex ...</param>
      <param name="pattern">... шаблон regex ...</param>
     </data>
    </define>
    <define name="ietf-inet-types__ip-address">
     <choice>
      <ref name="ietf-inet-types__ipv4-address"/>
      <ref name="ietf-inet-types__ipv6-address"/>
     </choice>
    </define>
   </grammar>

C.3. Окончательные схемы DSDL

Здесь представлены схемы DSDL, полученные из гибридной схемы в Приложении C.2 путём преобразования XSL. Эти схемы можно применять напрямую для проверки отклика на нефильтрованный запрос <nc:get> с содержимым, соответствующим модели данных DHCP. Схема RELAX NG (из 2 частей, как указано в параграфе 8.2. Модульность) включает также независимую от схемы библиотеку из Приложения B.

C.3.1. Основная схема RELAX NG для отклика <nc:get>

   <?xml version="1.0" encoding="utf-8"?>
   <grammar
       xmlns="http://relaxng.org/ns/structure/1.0" 
       xmlns:nma="urn:ietf:params:xml:ns:netmod:dsdl-annotations:1"
       xmlns:dhcp="http://example.com/ns/dhcp"
       datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes" 
       ns="urn:ietf:params:xml:ns:netconf:base:1.0"> 
    <include href="relaxng-lib.rng"/>
    <start>
     <element name="rpc-reply">
      <ref name="message-id-attribute"/>
      <element name="data">
       <interleave>
        <grammar ns="http://example.com/ns/dhcp">
         <include href="dhcp-gdefs.rng"/>
         <start>
          <optional>
           <element name="dhcp:dhcp">
            <interleave>
             <optional>
              <element name="dhcp:max-lease-time">
               <data type="unsignedInt"/>
              </element>
             </optional>
             <optional>
              <element name="dhcp:default-lease-time">
               <data type="unsignedInt"/>
              </element>
             </optional>
             <ref name="_dhcp__subnet-list"/>
             <optional>
              <element name="dhcp:shared-networks">
               <zeroOrMore>
                <element name="dhcp:shared-network">
                 <element name="dhcp:name">
                  <data type="string"/>
                 </element>
                 <ref name="_dhcp__subnet-list"/>
                </element>
               </zeroOrMore>
              </element>
             </optional>
             <optional>
              <element name="dhcp:status">
               <zeroOrMore>
                <element name="dhcp:leases">
                 <element name="dhcp:address">
                  <ref name="ietf-inet-types__ip-address"/>
                 </element>
                 <interleave>
                  <optional>
                   <element name="dhcp:starts">
                    <ref name="ietf-yang-types__date-and-time"/>
                   </element>
                  </optional>
                  <optional>
                   <element name="dhcp:ends">
                    <ref name="ietf-yang-types__date-and-time"/>
                   </element>
                  </optional>
                  <optional>
                   <element name="dhcp:hardware">
                    <interleave>
                     <optional>
                      <element name="dhcp:type">
                       <choice>
                        <value>ethernet</value>
                        <value>token-ring</value>
                        <value>fddi</value>
                       </choice>
                      </element>
                     </optional>
                     <optional>
                      <element name="dhcp:address">
                       <ref name="ietf-yang-types__phys-address"/>
                      </element>
                     </optional>
                    </interleave>
                   </element>
                  </optional>
                 </interleave>
                </element>
               </zeroOrMore>
              </element>
             </optional>
            </interleave>
           </element>
          </optional>
         </start>
        </grammar>
       </interleave>
      </element>
     </element>
    </start>
   </grammar>

C.3.2. Схема RELAX NG — определения глобально именуемых шаблонов

   <?xml version="1.0" encoding="utf-8"?>
   <grammar
       xmlns="http://relaxng.org/ns/structure/1.0" 
       xmlns:nma="urn:ietf:params:xml:ns:netmod:dsdl-annotations:1"
       xmlns:dhcp="http://example.com/ns/dhcp"
       datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes"> 
    <define name="ietf-yang-types__phys-address">
     <data type="string">
      <param name="pattern">
       ([0-9a-fA-F]{2}(:[0-9a-fA-F]{2})*)?
      </param>
     </data>
    </define>
    <define name="ietf-inet-types__ipv6-address">
     <data type="string">
      <param name="pattern">... шаблон regex ...</param>
     </data>
    </define>
    <define name="ietf-inet-types__ip-prefix">
     <choice>
      <ref name="ietf-inet-types__ipv4-prefix"/>
      <ref name="ietf-inet-types__ipv6-prefix"/>
     </choice>
    </define>
    <define name="ietf-inet-types__host">
     <choice>
      <ref name="ietf-inet-types__ip-address"/>
      <ref name="ietf-inet-types__domain-name"/>
     </choice>
    </define>
    <define name="ietf-yang-types__date-and-time">
     <data type="string">
      <param name="pattern">... шаблон regex ...</param>
     </data>
    </define>
    <define name="_dhcp__subnet-list">
     <zeroOrMore>
      <element name="subnet">
       <element name="net">
        <ref name="ietf-inet-types__ip-prefix"/>
       </element>
       <interleave>
        <optional>
         <element name="range">
          <interleave>
           <optional>
            <element name="dynamic-bootp">
             <empty/>
            </element>
           </optional>
           <element name="low">
            <ref name="ietf-inet-types__ip-address"/>
           </element>
           <element name="high">
            <ref name="ietf-inet-types__ip-address"/>
           </element>
          </interleave>
         </element>
        </optional>
        <optional>
         <element name="dhcp-options">
          <interleave>
           <zeroOrMore>
            <element name="router">
             <ref name="ietf-inet-types__host"/>
            </element>
           </zeroOrMore>
           <optional>
            <element name="domain-name">
             <ref name="ietf-inet-types__domain-name"/>
            </element>
           </optional>
          </interleave>
         </element>
        </optional>
        <optional>
         <element name="max-lease-time">
          <data type="unsignedInt"/>
         </element>
        </optional>
       </interleave>
      </element>
     </zeroOrMore>
    </define>
    <define name="ietf-inet-types__domain-name">
     <data type="string">
      <param name="pattern">... шаблон regex ...</param>
      <param name="minLength">1</param>
      <param name="maxLength">253</param>
     </data>
    </define>
    <define name="ietf-inet-types__ipv4-prefix">
     <data type="string">
      <param name="pattern">... шаблон regex ...</param>
     </data>
    </define>
    <define name="ietf-inet-types__ipv4-address">
     <data type="string">
      <param name="pattern">... шаблон regex ...</param>
     </data>
    </define>
    <define name="ietf-inet-types__ipv6-prefix">
     <data type="string">
      <param name="pattern">... шаблон regex ...</param>
      <param name="pattern">... шаблон regex ...</param>
     </data>
    </define>
    <define name="ietf-inet-types__ip-address">
     <choice>
      <ref name="ietf-inet-types__ipv4-address"/>
      <ref name="ietf-inet-types__ipv6-address"/>
     </choice>
    </define>
   </grammar>

C.3.3. Схема Schematron для отклика <nc:get>

  <?xml version="1.0" encoding="utf-8"?>
  <sch:schema xmlns:sch="http://purl.oclc.org/dsdl/schematron">
   <sch:ns uri="http://example.com/ns/dhcp" prefix="dhcp"/>
   <sch:ns uri="urn:ietf:params:xml:ns:netconf:base:1.0" prefix="nc"/>
   <sch:pattern abstract="true" id="_dhcp__subnet-list">
    <sch:rule context="$start/$pref:subnet">
     <sch:report test="preceding-sibling::$pref:subnet
                       [$pref:net=current()/$pref:net]">
      Дубликат ключа net
     </sch:report>
    </sch:rule>
    <sch:rule
      context="$start/$pref:subnet/$pref:dhcp-options/$pref:router">
     <sch:report test=".=preceding-sibling::router">
      Дубликат значения leaf-list "<sch:value-of select="."/>"
     </sch:report>
    </sch:rule>
   </sch:pattern>
   <sch:pattern id="dhcp">
    <sch:rule
      context="/nc:rpc-reply/nc:data/dhcp:dhcp/dhcp:default-lease-time">
     <sch:assert test=". &lt;= ../dhcp:max-lease-time">
      default-lease-time должно быть не больше max-lease-time
     </sch:assert>
    </sch:rule>
    <sch:rule context="/nc:rpc-reply/nc:data/dhcp:dhcp/
                       dhcp:shared-networks/dhcp:shared-network">
     <sch:report test="preceding-sibling::dhcp:shared-network
                       [dhcp:name=current()/dhcp:name]">
      Дубликат ключа dhcp:name
     </sch:report>
    </sch:rule>
    <sch:rule context="/nc:rpc-reply/nc:data/dhcp:dhcp/
                       dhcp:status/dhcp:leases">
     <sch:report test="preceding-sibling::dhcp:leases
                       [dhcp:address=current()/dhcp:address]">
      Дубликат ключа dhcp:address
     </sch:report>
    </sch:rule>
   </sch:pattern>
   <sch:pattern id="id2768196" is-a="_dhcp__subnet-list">
    <sch:param name="start" value="/nc:rpc-reply/nc:data/dhcp:dhcp"/>
    <sch:param name="pref" value="dhcp"/>
   </sch:pattern>
   <sch:pattern id="id2768215" is-a="_dhcp__subnet-list">
    <sch:param name="start"
               value="/nc:rpc-reply/nc:data/dhcp:dhcp/
                      dhcp:shared-networks/dhcp:shared-network"/>
    <sch:param name="pref" value="dhcp"/>
   </sch:pattern>
  </sch:schema>

C.3.4. Схема DSRL для отклика <nc:get>

   <?xml version="1.0" encoding="utf-8"?>
   <dsrl:maps
       xmlns:dsrl="http://purl.oclc.org/dsdl/dsrl"
       xmlns:dhcp="http://example.com/ns/dhcp"
       xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
    <dsrl:element-map>
     <dsrl:parent>/nc:rpc-reply/nc:data</dsrl:parent>
     <dsrl:name>dhcp:dhcp</dsrl:name>
     <dsrl:default-content>
      <dhcp:max-lease-time>7200</dhcp:max-lease-time>
      <dhcp:default-lease-time>600</dhcp:default-lease-time>
     </dsrl:default-content>
    </dsrl:element-map>
    <dsrl:element-map>
     <dsrl:parent>/nc:rpc-reply/nc:data/dhcp:dhcp</dsrl:parent>
     <dsrl:name>dhcp:max-lease-time</dsrl:name>
     <dsrl:default-content>7200</dsrl:default-content>
    </dsrl:element-map>
    <dsrl:element-map>
     <dsrl:parent>/nc:rpc-reply/nc:data/dhcp:dhcp</dsrl:parent>
     <dsrl:name>dhcp:default-lease-time</dsrl:name>
     <dsrl:default-content>600</dsrl:default-content>
    </dsrl:element-map>
    <dsrl:element-map>
     <dsrl:parent>
      /nc:rpc-reply/nc:data/dhcp:dhcp/dhcp:subnet
     </dsrl:parent>
     <dsrl:name>dhcp:max-lease-time</dsrl:name>
     <dsrl:default-content>7200</dsrl:default-content>
    </dsrl:element-map>
    <dsrl:element-map>
     <dsrl:parent>
      /nc:rpc-reply/nc:data/dhcp:dhcp/dhcp:shared-networks/
      dhcp:shared-network/dhcp:subnet
     </dsrl:parent>
     <dsrl:name>dhcp:max-lease-time</dsrl:name>
     <dsrl:default-content>7200</dsrl:default-content>
    </dsrl:element-map>
   </dsrl:maps>

Адрес автора

Ladislav Lhotka (editor)

CESNET

EMail: lhotka@cesnet.cz

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

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

1Internet Engineering Task Force — комиссия по решению инженерных задач Internet.

2Internet Engineering Steering Group — комиссия по инженерным разработкам Internet.

3В переводе это не используется. Прим. перев.

4Extensible Stylesheet Language Transformations — трансформации языка расширяемых шаблонов стилей.

5Маркерный элемент в гибридной схеме.

6Присутствует лишь как субэлемент в <nma:must>.

7Имеет необязательный атрибут @require-instance.

8Имеет обязательный атрибут @assert и два необязательных субэлемента <nma:error-app-tag> и <nma:error-message>.

9В оригинале ошибочно указано @nma:unique, см. https://www.rfc-editor.org/errata/eid3362. Прим. перев.

10В оригинале этот абзац содержал ошибку, см. https://www.rfc-editor.org/errata/eid3362. Прим. перев.

11В оригинале этот абзац содержал ошибку, см. https://www.rfc-editor.org/errata/eid3362. Прим. перев.

12В оригинале этот параграф содержал ошибки, см. https://www.rfc-editor.org/errata/eid3362. Прим. перев.

13В оригинале этот блок содержал ошибку, см. https://www.rfc-editor.org/errata/eid3362. Прим. перев.

Рубрика: RFC | Оставить комментарий

RFC 6087 Guidelines for Authors and Reviewers of YANG Data Model Documents

Опубликовано 23.01.2011 автором Nikolai Malykh

Internet Engineering Task Force (IETF)                        A. Bierman
Request for Comments: 6087                                       Brocade
Category: Informational                                     January 2011
ISSN: 2070-1721

Guidelines for Authors and Reviewers of YANG Data Model Documents

Рекомендации для авторов и рецензентов документов с моделями YANG

Аннотация

Этот документ содержит руководство для авторов и рецензентов спецификаций Standards Track, содержащих модули с моделями данных YANG. Применимые части документа могут служить основой для рецензирования других документов с моделями данных YANG. Заданы рекомендации и процедуры, предназначенные для улучшения совместимости и применимости реализация протокола конфигурации сети (Network Configuration Protocol или NETCONF), использующих модули моделей данных YANG.

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

Документ не относится к категории Internet Standards Track и публикуется лишь для информации.

Документ не содержит стандарта Internet и публикуется с информациоными целями.

Документ является результатом работы IETF¹ и представляет согласованный взгляд сообщества IETF. Документ прошёл открытое обсуждение и был одобрен для публикации IESG². Не все документы, одобренные IESG претендуют на статус Internet Standard. Дополнительную информацию о стандартах Internet можно найти в разделе 2 в RFC 5741.

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

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

1. Введение

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

Этот документ задаёт набор рекомендаций для документов Standards Track с моделями данных YANG [RFC6020]. Язык YANG служит для определения структур данных, протокольных операций и содержимого уведомлений, используемых на серверах NETCONF. Сервер, поддерживающий конкретный модуль YANG, позволяет клиентам NETCONF запрашивать операции, как указано конкретным содержимым модуля YANG.

Этот документ по назначению и структуре похож на рекомендации по использованию Structure of Management Information version 2 (SMIv2) [RFC4181]. Однако упомянутый документ бы написан через 10 лет после начала использования модулей SMIv2 и опубликован в серии обмена опытом (Best Current Practice или BCP). Данный документ не является BCP и служит, скорее, информационным справочником, предназначенным для обеспечения согласованности документов, содержащих модули YANG.

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

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

Этот документ задаёт рекомендации по использованию, относящиеся к операционному уровню и уровню содержимого NETCONF, как указано в [RFC4741]. Рекомендации предназначены для разработчиков и рецензентов с целью повышения удобочитаемости и функциональной совместимости публикуемых моделей данных YANG.

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

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

Соглашения RFC 2119 здесь служат для представления взглядов рабочей группы NETMOD в части содержимого модулей YANG. Модули YANG, соответствующие этому документу будут трактовать соглашения RFC 2119 как описанные в документах BCP.

2.2. Термины NETCONF

Ниже указаны термины, определённые в [RFC4741] и не пререопределяемые здесь.

capabilities — возможности;
client — клиент;
operation — операция;
server — сервер.

2.3. Термины YANG

Ниже указаны термины, определённые в [RFC6020] и не пререопределяемые здесь.

data node — узел данных;
module — модуль;
namespace — пространство имён;
submodule — субмодуль;
version — версия;
YANG;
YIN.

Отметим, что термин «модуль» может применяться к модулям и субмодулям YANG. При описании субмодулей применяется термин «субмодуль».

2.4. Термины

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

published — опубликованный

Стабильный выпуск модуля или субмодуля, оычно содержащийся в RFC.

unpublished — неопубликованный

Нестабильный выпуск модуля или субмодуля, оычно содержащийся в Internet-Draft.

3. Общие рекомендации

Рецензируемые модули данных вероятно будут содержаться в Internet-Draft. Должны выполняться все рекомендации для авторов Internet-Draft. RFC Editor представляет рекомендации для авторов RFC, которые впервые публикуются как Internet-Draft. Следует соблюдать рекомендации, опубликованные в [RFC2223] и обновлённые в [RFC5741] и RFC Document Style [RFC-STYLE].

Ниже указаны разделы, которые должны присутствовать в Internet-Draft с модулем

Описательные разделы.
Раздел определений.
Раздел Security Considerations.
Раздел IANA Considerations.
Раздел ссылок.

3.1. Авторские права на модуль

Оператор описания модуля должен включать ссылку на последнее заявление авторских прав IETF Trust Copyright, которое доступно по ссылке http://trustee.ietf.org/license-info/

Каждый модуль или субмодуль YANG, содержащийся в Internet-Draft или RFC считается кодом. Для идентификации кода должны использоваться строки <CODE BEGINS> и <CODE ENDS>.

После тега <CODE BEGINS> следует помещать строку с именем модуля, описанную в параграфе 5.2 [RFC6020]. Ниже приведён пример для выпуска 2010-01-18 модуля ietf-foo.

   <CODE BEGINS> file "ietf-foo@2010-01-18.yang"
   module ietf-foo {
       // ...
      revision 2010-01-18 {
         description "Последний выпуск";
         reference "RFC XXXX";
      }
      // ...
   }
   <CODE ENDS>

3.2. Описательные разделы

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

Если определяемые спецификацией модули импортируют определения из других модулей (за исключением определённых в YANG [RFC6020] и YANG Types [RFC6021]) или всегда реализуется в сочетании с другими модулями, этот факт должен быть указан в обзорном разделе и должны быть отмечены любые специальные интерпретации определений из других модулей.

3.3. Раздел определений

Этот раздел содержит модули, заданные спецификацией. Эти модули должны использовать синтаксис YANG, определённый в [RFC6020]. В документ может также включаться версия YIN. Возможно включение в документ других типов модулей, таких как SMIv2, к которым эти рекомендации не применяются.

Рекомендации по использованию YANG приведены в разделе 4. Рекомендации по использованию YANG.

3.4. Раздел Security Considerations

Каждая спецификация, определяющая модуль или модули, должна включать раздел посвящённый соображениям безопасности, применимым к этим модулям. Этот раздел должен соответствовать последнему утвержденному шаблону (http://www.ops.ietf.org/netconf/yang-security-considerations.txt). В параграфе 6.1 приведён шаблон раздела от 16 июня 2010 г. Авторы должны проверить его соответствие приведённой выше ссылке.

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

3.5. Раздел IANA Considerations

В соответствии с правилами IESG (http://www.ietf.org/id-info/checklist.html) каждый документ Internet-Draft, представленный IESG для публикации, должен включать раздел IANA Considerations. Требования к разделу зависят от действий, которые нужно выполнить IANA. Если действий IANA не требуется, раздел IANA Considerations, заявляющий об этом, RFC Editor удаляет перед публикацией. Более подробные сведения приведены в [RFC5226].

3.5.1. Документы, создающие новые пространства имен

Если Internet-Draft задаёт новое пространство имён, администрируемое IANA, документ должен включать раздел IANA Considerations, указывающий, как администрируется пространство имён. В частности, если значение оператора namespace в модуле YANG ещё не зарегистрировано в IANA, должна запрашиваться новая запись в реестре YANG Namespace. В спецификации YANG [RFC6020] указана процедура для этого.

3.5.2. Документы, расширяющие пространства имен

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

3.6. Разделы ссылок

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

Для каждого нормативного оператора reference в модуле, указывающего модуль из отдельного документа, следует включать ссылку на соответствующий документ в раздел Normative References. Этой ссылке следует указывать документ с фактически используемой версией модуля. Если оператор reference указывает ненормативную ссылку на другой документ, этот документ можно включить в раздел Informative References.

4. Рекомендации по использованию YANG

В общем случае модули из спецификаций IETF Standards Track должны соответствовать всем синтаксическим и сементическим требованиям YANG [RFC6020]. Рекомендации этого раздела дополняют спецификацию YANG, задающую минимальный набор требований по соответствию.

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

4.1. Соглашения по именованию модулей

Модули в документах Standards Track следует именовать в соответствии с разделом IANA Considerations в [RFC6020].

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

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

После публикации имени модуля недопустимо использовать его ещё раз, даже при переводе RFC с этим модулем в статус Historic.

4.2. Идентификаторы

Все идентификаторы в опубликованных модулях YANG должны иметь размер от 1 до 64 символов. Это включает конструкции, заданные как identifier-arg-str в ABNF (раздел 12 в [RFC6020]).

4.3. Значения по умолчанию

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

Оператор	Значение по умолчанию
config	true
mandatory	false
max-elements	unbounded
min-elements	0
ordered-by	system
status	current
yin-element	false

4.4. Операторы условий

Модуль можно концептуально разделить на части, используя операторы if-feature и/или when.

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

Если определение данный не является обязательным и зависит от поддержки сервером возможностей протокола NETCONF, следует использовать оператор YANG feature для указания поддержки функции SHOULD в модели данных.

Если какие-либо данные уведомления или определение данных для не относящегося к конфигурации узла не являются обязательными, сервер может (но не обязан) возвращать экземпляр этого узла данных. Если имеются какие-либо условные требования для возврата узла данных в уведомлении или ответе на поисковый запрос, они должны быть указаны в документации. Например, к узлу данных может применяться оператор when или if-feature или условия могут быть разъяснены в операторе description внутри узла данных или одном из его предков (при наличии таковых).

4.5. Использование XPath

В этом параграфе даны рекомендации по использованию языка путей XML (XML Path Language или XPath) [W3C.REC-xpath-19991116] в модулях YANG.

Оси attribute и namespace не поддерживаются в YANG и могут быть пустыми в реализации сервер NETCONF. Функции position и last применять не следует. Это относится и к неявному использования функции position (например, //chapter[42]). От сервера требуется поддержка лишь относительного порядка документов XML всех экземпляров из конкретного, упорядоченного пользователем list или leaf-list. Функции position и last можно применять, если они оцениваются в контексте, где узел контекста является упорядоченным пользователем list или leaf-list.

Оси preceding и following применять не следует. Эти конструкции основаны на порядке документов XML в базе данных конфигурации сервера NETCONF, который не может поддерживаться согласованно и давать надёжные результате в разных реализациях. Взамен следует использовать выражения предикатов, основанные на статических свойствах узла (например, имя элемента или значение осей ancestor или descendant). Оси preceding и following можно применять, если порядок документов не связан с результатом выражения (например, проверка глобальной уникальности значения параметра).

Оси preceding-sibling и following-sibling не следует использовать. От сервера требуется лишь поддержка относительного порядка документов всех экземпляров из конкретного, упорядоченного пользователем list или leaf-list. Оси preceding-sibling и following-sibling можно применять, если они оцениваются в контексте, где узел контекста является упорядоченным пользователем list или leaf-list.

Узлы данных, использующие встроенные типы int64 и uint64, не следует применять в численных выражениях. Имеются граничные условия, при которых преобразование 64-битовогог типа YANG в число XPath может давать некорректный результат. В частности, число XPath с двойной точностью и плавающей точкой, не может представлять очень большие или отрицательные 64-битовые значения и ограничено лишь 53 битами. Типы int64 и uint64 можно применять в численных выражениях, если для представления значение не требуется более 53 битов.

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

Можно использовать явные преобразования типа данных XPath (например, функции string, boolean, number) вместо неявных.

4.6. Управление жизненным циклом

Оператор status должен присутствовать, если он имеет значение deprecated или obsolete.

Модуль или субмодуль недопустимо изменять после публикации содержащего его документа. Значение URI пространства имён модуля недопустимо изменять после публикации содержащего модуль документа.

Субоператор revision-date в операторе imports следует включать при использовании любой группировки из внешнего модуля. Субоператор revision-date в операторе include следует включать при использовании любой группировки из внешнего модуля.

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

4.7. Заголовок модуля, операторы Meta и Revision

Для опубликованных модулей пространство имён должно быть указано глобально уникальным URI, как указано в [RFC3986]. Эти значения обычно выделяются IANA.

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

Должен присутствовать оператор contact, а для модулей Standards Track в этом операторе должна быть указана web-страница рабочей группы и следует также указывать контактные данные основного автора или редактора документа. Если имеется несколько авторов, можно включить их контактные данные. Дополнительно можно указать Area Director и другие сведения о контактах.

Должен присутствовать оператор, а также должен включаться подходящий текст IETF Trust Copyright, как указано в параграфе 3.1. Авторские права на модуль.

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

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

Допускается неоднократно использовать один и тот же оператор revision в разных выпусках неопубликованного модуля (Internet-Draft), но дата выпуска должна обновляться при каждой «публикации» документа Internet-Draft.

4.8. Назначение пространств имён

Рекомендуется включать в документы лишь действительные модули YANG, независимо от публикации. Это позволит:

корректно компилировать модули, не получая сообщений о критических ошибках;
применять модули в ранних реализациях, не выбирая случайных значений для пространства имён XML;
заранее проверить совместимость, поскольку независимые реализации будут использовать одно пространство имён XML.

Пока IANA не назначит URI, в операторе namespace внутри модуля YANG должно указываться предложенное значение URI пространства имён. Значение следует выбирать так, чтобы не возникало конфликтов с другими пространствами имён YANG. Недопустимо применять для этого стандартные имена модулей, префиксы и строки URI, уже включённые в реестр YANG Module Names.

Стандартному оператору namespace следует иметь форму

   <URN prefix string>:<module-name>

Для опубликованных и неопубликованных модулей YANG следует применять строку префикса URN вида

   urn:ietf:params:xml:ns:yang:

Ниже даны примеры действительных URN для временных операторов namespace в модулях Standards Track.

      urn:ietf:params:xml:ns:yang:ietf-netconf-partial-lock
      urn:ietf:params:xml:ns:yang:ietf-netconf-state
      urn:ietf:params:xml:ns:yang:ietf-netconf

Отметим, что для модулей, не относящихся к Standards Track следует применять иную строку префикса URN, которую следует выбирать в соответствии с рекомендациями [RFC6020]. Ниже приведены примеры для модулей, на являющихся Standards Track. Этот документ не содержит рекомендаций для этого типа URN.

      http://example.com/ns/example-interfaces
      http://example.com/ns/example-system

4.9. Определения данных верхнего уровня

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

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

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

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

4.10. Типы данных

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

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

Если нужна расширяемость набора перечисляемых значений, следует применять тип identityref вместо enumeration или встроенного типа.

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

Для численных типов следует применять оператор range, если предполагаемая семантика отличается от разрешённой неограниченным внутренним типом данных (например, int32). Численные типы со знаком (int8, int16, int32, int64) не следует применять, если желаемая семантика не включает отрицательных значений.

Для типов enumeration и bits следует документировать семантику каждого enum и bit и в таких случаях следует применять каждый раз свой оператор description (внутри enum или bit).

4.11. Определения типов многократного использования

Если подходящий производный тип имеется в стандартном модуле, таком как [RFC6021], следует применять этот тип вместо задания нового.

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

Если с желаемой семантикой можно связать подходящее значение по умолчанию, следует включать оператор default.

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

Должен присутствовать оператор description.

Если семантика определения типа задана в другом документе (отличном от указанного в операторе import модуля YANG), должен присутствовать оператор reference.

4.12. Определения данных

Оператор description должен присутствовать в операторах YANG:

anyxml;
augment;
choice;
container;
extension;
feature;
grouping;
identity;
leaf;
leaf-list;
list;
notification;
rpc;
typedef.

Если семантика определения данных задана в другом документе (отличном от указанного в операторе import модуля YANG), должен присутствовать оператор reference.

Конструкция anyxml может быть полезна для представления заголовков (banner) HTML с элементами разметки, такими как <b> и </b>, и может применяться в таких случаях. Однако её не следует использовать, если для желаемого синтаксиса и семантики подходит иной тип данных YANG.

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

Для определений данных list и leaf-list следует применять оператор max-elements, если нужно ограничить число возможных экземпляров во всех реализациях.

Если в определении данных имеются операторы must или when, в оператор description этого определения следует помещать описание назначения.

4.13. Определения операций

Если семантика операции задана в другом документе (отличном от указанного в операторе import модуля YANG), должен присутствовать оператор reference.

Если операция влияет на поведение системы, это следует отметить в операторе description.

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

4.14. Определения уведомлений

Должен присутствовать оператор description.

Если семантика уведомления задана в другом документе (отличном от указанного в операторе import модуля YANG), должен присутствовать оператор reference.

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

Этот документ регистрирует URI in the IETF XML в реестре [RFC3688].

   URI: urn:ietf:params:xml:ns:yang:ietf-template
   Registrant Contact: The NETMOD WG of the IETF.
   XML: N/A, запрошенный URI является пространством имён XML.

В соответствии с этим документом в реестр YANG Module Names внесён шаблон модуля YANG из Приложения B.

Поле	Значение
Name	ietf-template
Namespace	urn:ietf:params:xml:ns:yang:ietf-template
Prefix	temp
Reference	RFC6087

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

Этот документ содержит рекомендации по документированию содержимого NETCONF, определённого на языке моделирования данных YANG. Рекомендации по написанию разделов Security Considerations для модулей YANG приведены в документе http://www.ops.ietf.org/netconf/yang-security-considerations.txt

Этот документ не вносит новых и не меняет существующих рисков для систем управления.

В следующем параграфе представлен шаблон для раздела Security Considerations от 16 июня 2010 г. Следует пользоваться приведённой выше ссылкой, чтобы проверить наличие новой версии шаблона.

Каждая спецификация, задающая 1 или несколько модулей YANG, должна включать раздел с обсуждением вопросов безопасности, связанных с этими модулями. Этот раздел должен следовать последнему опубликованному шаблону (http://www.ops.ietf.org/netconf/yang-security-considerations.txt).

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

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

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

6.1. Шаблон раздела Security Considerations

X. Security Considerations

Модуль YANG, заданный в этом документе, предназначен для доступа по протоколу NETCONF [RFC4741]. Нижним уровнем NETCONF является защищённый транспорт с обязательной реализацией SSH [RFC4742].

Если имеются открытые для записи узлы данных (config true, как принято по умолчанию), нужно описать их конкретную чувствительность или уязвимости.

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

    <список ветвей и узлов данных с указанием причин их чувствительности>

Для всех модулей YANG требуется оценить, являются ли доступные лишь для чтения узлы (config false и другие узлы, поскольку они могут быть считаны такими операциями, как get или get-config) чувствительными или уязвимыми (например, могут раскрывать сведения о клиенте или нарушать законы о персональных данных).

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

    <список ветвей и узлов данных с указанием причин их чувствительности>

Если модуль YANG определяет операции RPC, должна быть описана их чувствительность или уязвимости.

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

    <список операций RPC с указанием причин их чувствительности>

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

Структура и содержимое этого документа основаны на Guidelines for MIB Documents [RFC4181] от C. M. Heard.

Рабочая группа благодарит Martin Bjorklund и Juergen Schoenwaelder за обстоятельные рецензии и вклад в документ.

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

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

[RFC2119] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, March 1997.

[RFC2223] Postel, J. and J. Reynolds, «Instructions to RFC Authors», RFC 2223, October 1997.

[RFC3688] Mealling, M., «The IETF XML Registry», BCP 81, RFC 3688, January 2004.

[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, «Uniform Resource Identifier (URI): Generic Syntax», STD 66, RFC 3986, January 2005.

[RFC4741] Enns, R., «NETCONF Configuration Protocol», RFC 4741, December 2006.

[RFC5378] Bradner, S. and J. Contreras, «Rights Contributors Provide to the IETF Trust», BCP 78, RFC 5378, November 2008.

[RFC5741] Daigle, L., Kolkman, O., and IAB, «RFC Streams, Headers, and Boilerplates», RFC 5741, December 2009.

[W3C.REC-xpath-19991116] DeRose, S. and J. Clark, «XML Path Language (XPath) Version 1.0», World Wide Web Consortium Recommendation REC-xpath-19991116, November 1999, <http://www.w3.org/TR/1999/REC-xpath-19991116>.

[RFC6020] Bjorklund, M., «YANG — A Data Modeling Language for the Network Configuration Protocol (NETCONF)», RFC 6020, October 2010.

[RFC6021] Schoenwaelder, J., «Common YANG Data Types», RFC 6021, October 2010.

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

[RFC4181] Heard, C., «Guidelines for Authors and Reviewers of MIB Documents», BCP 111, RFC 4181, September 2005.

[RFC5226] Narten, T. and H. Alvestrand, «Guidelines for Writing an IANA Considerations Section in RFCs», BCP 26, RFC 5226, May 2008.

[RFC-STYLE] Braden, R., Ginoza, S., and A. Hagens, «RFC Document Style», September 2009, <http://www.rfc-editor.org/rfc-style-guide/rfc-style>.

Приложение A. Контрольный список рецензирования модуля

Этот раздел заимствован из RFC 4181.

Цель рецензирования модуля YANG состоит в проверке технической корректности и соответствия требованиям IETF к документации. Ниже приведён контрольный список, которых может быть полезен при рецензировании Internet-Draft.

Шаблон I-D. Проверяется использование требуемого шаблона Internet-Draft (http://www.ietf.org/id-info/guidelines.html), включая соответствующее заявление с разрешением публикации как RFC и отсутствие в шаблоне I-D ссылок и номеров разделов.
Аннотация. Проверяется отсутствие ссылок и номера раздела, а также соответствие содержимого рекомендациям http://www.ietf.org/id-info/guidelines.html.
Авторские права. Проверяется наличие подходящего текста относительно авторских прав, которые участники предоставляют IETF Trust [RFC5378]. Проверка наличия полного уведомления об авторских паравах IETF Trust в начале документа. IETF Trust Legal Provisions (TLP) можно найти по ссылке http://trustee.ietf.org/license-info/.
Раздел Security Considerations. Проверяется использование последнего утверждённого шаблона из области OPS (http://www.ops.ietf.org/netconf/yang-security-considerations.txt) и следование этому шаблону.
Раздел IANA Considerations должен присутствовать всегда. Для каждого модуля в документе раздел IANA Considerations должен указывать приведённые ниже реестры IANA.

XML Namespace Registry — регистрация пространства имён модуля YANG.

YANG Module Registry — регистрация имени модуля YANG, префикса, пространства имён и номера RFC в соответствии с правилами [RFC6020].
Ссылки. Проверяется корректность деления на нормативные документы и дополнительную литературу, наличие RFC 2119 в числе нормативных документов, если применяется соответствующая терминология, наличие все требуемых шаблоном ссылок, указание в нормативных документах всех импортируемых модулей YANG, ссылки на последние RFC, если нет конкретных причин указывать предшествующие версии (например, включение в дополнительную литературу ссылку на предыдущую спецификацию для разъяснения функций совместимости с прежними версиями). Проверяется наличие в тексте документа (вне модуля YANG) ссылок на все импортируемые модули.
Лицензия. Проверяется указание Simplified BSD License в каждом модуле и субмодуле. Некоторые рекомендации по этой части даны в параграфе 3.1. Проверяется корректность указания года во всех упоминаниях авторских прав. Используется утвержденный текст из документа (Trust Legal Provisions или TLP), доступного по ссылке http://trustee.ietf.org/license-info/
Другие вопросы. Проверяется наличие проблем, указанных в http://www.ietf.org/id-info/checklist.html, которые не рассмотрены.
Техническое содержимое. Просматривается фактическое техническое содержимое на предмет соответствия рекомендациям этого документа. Для проверки синтаксических ошибок рекомендуется применять компилятор YANG. Список свободно распространяемых инструментов доступен по ссылке http://trac.tools.ietf.org/wg/netconf/trac/wiki

Checking for correct syntax, however, is only part of the job. It is just as important to actually read the YANG module document from the point of view of a potential implementor. It is particularly important to check that description statements are sufficiently clear and unambiguous to allow interoperable implementations to be created.

Приложение B. Шаблон модуля YANG

<CODE BEGINS> file "ietf-template@2010-05-18.yang"

module ietf-template {

    // Указывается уникальное значение URN пространства имён 
    namespace
      "urn:ietf:params:xml:ns:yang:ietf-template";

    // Указывается уникальный префикс
    prefix "temp";


    // Операторы import, например
    // import ietf-yang-types { prefix yang; }
    // import ietf-inet-types { prefix inet; }

    // Указывается рабочая группа IETF (если применимо)
    organization
       "IETF NETMOD (NETCONF Data Modeling Language) Working Group";

    // Указываются сведения об авторах
    contact
       "WG Web:   <http://tools.ietf.org/wg/your-wg-name/>
        WG List:  <mailto:your-wg-name@ietf.org>

        WG Chair: your-WG-chair
                  <mailto:your-WG-chair@example.com>

        Editor:   your-name
                  <mailto:your-email@example.com>";


    // В первом абзаце даётся кратное описание модуля.
    // Указываются авторские права для последней версии,
    // если она обновилась с момента публикации документа.
    description
     "Этот модуль задаёт шаблон для других модулей YANG.

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

      Распространение и использование в исходной или двоичной форме с
      изменениями или без таковых разрешено в соответствии с лицензией
      Simplified BSD, изложенной в разделе 4  IETF Trust's Legal
      Provisions применительно к документам IETF
      (http://trustee.ietf.org/license-info). 
 
      Эта версия данного модуля YANG является частью RFC XXXX, где
      правовые вопросы рассмотрены более полно.";

    // RFC Ed.: Заменить XXXX фактическим номером RFC и удалить примечание

    reference "RFC XXXX";

    // RFC Ed.: Удалить это примечание
    // Примечание: Извлечено из RFC 6087


    // Заменить 2010-05-18 датой публикации модуля в формате
    // (год-месяц-число)
    revision "2010-05-18" {
      description
        "исходный выпуск";
    }

    // Операторы extension

    // Операторы feature

    // Операторы identity

    // Операторы typedef

    // Операторы grouping

    // Операторы определения данных

    // Операторы augment

    // Операторы rpc

    // Операторы notification

    // НЕ ВКЛЮЧАЙТЕ операторы deviation в опубликованные модули

}
<CODE ENDS>

Адрес автора

Andy Bierman

Brocade

EMail: andy.bierman@brocade.com

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

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