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

Internet Engineering Task Force (IETF)                          D. Mills
Request for Comments: 5905                                   U. Delaware
Obsoletes: 1305, 4330                                     J. Martin, Ed.
Category: Standards Track                                            ISC
ISSN: 2070-1721                                               J. Burbank
                                                                W. Kasch
                                                                 JHU/APL
                                                               June 2010

Network Time Protocol Version 4: Protocol and Algorithms Specification

Протокол сетевого времени NTPv4 — спецификация и алгоритмы

PDF

Аннотация

Протокол сетевого времени (Network Time Protocol или NTP) широко применяется для синхронизации клиентских часов в Internet. Этот документ описывает протокол NTP версии 4 (NTPv4), который совместим с NTP версии 3 (NTPv3, RFC 1305), а также с предыдущими версиями протокола. NTPv4 использует изменённый заголовок для работы с адресами семейства IPv6. В NTPv4 включены фундаментальные улучшения в алгоритмах смягчения и дисциплины, повышающие потенциальную точность до десятков микросекунд для современных рабочих станций и скоростных ЛВС. Протокол включает схему динамического обнаружения серверов, что во многих случаях позволяет избежать специальной настройки. В протоколе исправлены некоторые ошибки в устройстве и реализации NTPv3, а также включён дополнительный механизм расширения.

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

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

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

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

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

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

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

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

1. Введение

Этот документ определяет протокол NTP версии 4 (NTPv4), который широко применяется для синхронизации часов между множеством распределенных серверов и клиентов. Описана базовая архитектура, протокол, конечные автоматы, структуры данных и алгоритмы. NTPv4 расширяет функциональность NTPv3, описанную в [RFC1305], и Simple NTP версии 4 (SNTPv4), описанную в [RFC4330] (SNTPv4 является частью NTPv4). Этот документ отменяет [RFC1305] и [RFC4330]. Хотя в отдельные поля заголовков протокола внесены незначительные изменения, это не влияет на совместимость NTPv4 с предыдущими версиями NTP и SNTP.

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

В NTPv4 устранены существенные недостатки NTPv3, исправлены некоторые ошибки и добавлены новые возможности. В частности, расширены определения меток времени NTP для использования типа данных с плавающей запятой (точкой) и двойной точностью. В результате разрешение (дискретность счета) времени составляет меньше 1 нсек, а частотное разрешение — меньше 1 нсек. За секунду. Дополнительные улучшения включают алгоритм дисциплины часов, который более стабилен при флуктуациях аппаратных часов системы. Типовые первичные серверы используют современные машины и обеспечивают точность в пределах нескольких десятков мксек. Типовые вторичные серверы и клиенты в быстрых ЛВС обеспечивают точность в несколько сотен микросекунд с интервалами опроса до 1024 секунд, что было максимальным для NTPv3. С помощью NTPv4 клиенты и серверы работают с точностью в несколько десятков миллисекунд, а интервалы опроса составляют до 36 часов.

Основная часть документа описывает ядро протокола и структуры данных, требуемые для взаимодействия разных реализаций. В Приложении A приведён полнофункциональный пример в форме скелета программы, включающий структуры данных и сегменты кода для алгоритмов ядра, а также алгоритмов смягчения, служащих для повышения точности и надёжности. Хотя скелет программы и другие описания в этом документе относятся к конкретной реализации, они не являются единственным способом реализации требуемых функций. Содержимое Приложения A не является нормативным и предназначено для иллюстрации работы протокола, поэтому его не обязательно использовать в реализации. Хотя описанная в документе схема аутентификации NTPv3 с симметричным ключом была скопирована из NTPv3, новая схема аутентификации с открытым ключом Autokey доступна для NTPv4 [RFC5906].

NTP включает режимы работы, описанные в разделе 2, с использованием типов (раздел 6) и структур (раздел 7) данных. Модель реализации в разделе 5 описана на основе многопоточной, многопроцессорной архитектуры, хотя возможны и другие варианты. Протокол в линии (on-wire) описанный в разделе 8, основан на схеме с возвращаемым временем (returnable-time), которая зависит лишь от измеренных сдвигов (offset) часов и не требует надёжной доставки сообщений. Гарантированная доставка, такая как TCP [RFC0793], может сделать доставленный пакет NTP менее надёжным, поскольку повторы передачи увеличивают задержку и другие ошибки. Подсеть синхронизации является самоорганизующейся иерархической сетью «ведущий-ведомый» с путями синхронизации, определяемыми связующим деревом кратчайших путей (shortest-path spanning tree) и заданной метрикой. Хотя может существовать несколько ведущих серверов (primary server), протокол выбора среди них не требуется.

Этот документ включает материалы из [ref9], где содержатся схемы и формулы, не подходящие для формата RFC. Много дополнительных сведений представлено в [ref7], включая обширный технический анализ и оценку производительности протокола и алгоритмов из этого документа. Эталонная реализация доступна на www.ntp.org.

Далее в документе представлено множество численных переменных и математических выражений. Некоторые переменные обозначаются греческими символами, которые представлены полным именем буквы с учётом регистра. Например, DELTA указывает загравную греческую букву «дельта», а delta — строчную. Кроме того, нижние индексы обозначены символом подчёркивания ‘_’, например, theta_i указывает греческую букву theta с нижним индексом i (фонетически i). Время в документе указывается в секундах, частоты указаны значениями FFO (fractional frequency offset). Зачастую FFO удобно указывать в миллионных долях (ppm).

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

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

2. Режимы работы

Реализация NTP работает как первичный сервер, вторичный сервер или клиент. Первичный сервер синхронизируется с эталонными часами, отслеживаемыми напрямую до UTC (например, GPS, Galileo и т. п.). Клиент синхронизируется с одним или несколькими серверами восходящего направления, но сам не обеспечивает синхронизации зависимым клиентам. Вторичный сервер имеет один или несколько восходящих серверов и один или несколько нисходящих серверов или клиентов. Все серверы и клиенты, полностью совместимые с NTPv4, должны реализовать весь набор алгоритмов, описанных в этом документе. Для поддержки стабильности в больших подсетях NTP вторичным серверам следует быть полностью совместимыми с NTPv4. Можно применять дополнительные алгоритмы, но их вывод должен быть идентичен выводу алгоритмов, описанных в этой спецификации.

3. Режимы протокола

Имеется 3 варианта протокола NTP: симметричный, клиент-сервер и широковещательный. С каждым из них связан режим ассоциации (описание отношения между двумя узлами NTP) как показано на рисунке 1. Кроме того, постоянные ассоциации активируются (mobilize) при старте и никогда не деактивируются (demobilize), а временные (эфемерные — ephemeral) активируются приёмом пакета и деактивируются по ошибке или тайм-ауту.

Рисунок 1. Режимы протокола

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

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

В широковещательном варианте ассоциация постоянного широковещательного сервера передаёт периодические пакеты широковещательного сервера (режим 5), которые может получить множество клиентов. При получении такого пакета без соответствующей ассоциации ассоциация временного широковещательного клиента (режим 6) активизируется и сохраняется до ошибки или тайм-аута. Полезно обеспечить начальный поток (volley), где клиент, работающий в клиентском режиме обменивается несколькими пакетами с сервером, чтобы откалибровать задержку распространения и запустить протокол защиты Autokey, после чего клиент возвращаетмя в режим широковещательного клиента. Широковещательный сервер выталкивает синхронизацию клиентам и другим серверам.

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

В качестве стандартной практики топологию сети синхронизации следует организовывать так, чтобы не возникало петель синхронизации и минимизировались дистанции синхронизации. В NTP топология подсети определяется с использованием варианта алгоритма распределенной маршрутизации Беллмана-Форда (Bellman-Ford), который рассчитывает связующее дерево кратчайших путей с первичным сервером в качестве корня. В результате алгоритм автоматически реорганизует подсеть, чтобы обеспечить наиболее точное и надёжное время даже при сбоях в сети синхронизации.

3.1. Динамическое обнаружение серверов

Две специальные ассоциации — manycast-клиент и manycast-сервер, — которые обеспечивают функцию динамического обнаружения сервера. Имеется два типа клиентских ассоциаций manycast: постоянные и временные. Постоянный manycast-клиент передаёт клиентские пакеты (режим 3) по назначенному групповому или широковещательному адресу IPv4 или IPv6. Назначенные manycast-серверы в диапазоне срока действия пакета (time-to-live или TTL) в заголовке прослушивают пакеты по этому адресу. Если сервер подходит для синхронизации, он возвращает обычный серверный пакет (режим 4) по индивидуальному адресу клиента. При получении этого пакета клиент активирует временную клиентскую ассоциацию (режим 3), которая сохраняется до ошибки или тайм-аута.

Клиент manycast продолжает передавать пакеты поиска для создания минимального числа ассоциаций. Передача начинается с TTL=1 с увеличением значения, пока не будет создано минимальное число ассоциаций или достигнуто максимальное значение TTL. Если по достижении максимума TTL активировано ещё недостаточно ассоциаций, клиент останавливает передачу на время ожидания для очистки всех ассоциаций, затем повторяет цикл поиска. Если минимальное число ассоциаций активировано, клиент начинает передавать один пакет за время ожидания для поддержки ассоциаций. Значение поля ограничено диапазоном от 1 до 255, но приложения могут менять диапазон.

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

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

В этом разделе определено множество технических терминов. Шкала времени (timescale) — это система отсчёта, где время выражается монотонно возрастающим двоичным счётчиком с неопределённым числом битов. Счет ведётся в секундах и долях секунды, если используется десятичная точка (запятая). Шкала универсального координированного времени (Coordinated Universal Time или UTC) определена в ITU-R TF.460 [ITU-R_TF.460]. Под эгидой метрической конвенции (Metre Convention) 1865 г. в 1975 году Генеральная конференция мер и весов (CGPM) [CGPM] настоятельно рекомендовала использовать UTC в качестве базы гражданского времени.

Шкала UTC представляет среднее солнечное время, распространяемое национальными органами стандартизации. Системное время представляется часами системы, поддерживаемыми оборудованием и операционной системой. Целью алгоритмов NTP является минимизация разности во времени и частоте (скорости хода) между UTC и системными часами. Когда эта разница ниже номинальных допусков (nominal tolerance), системные часы считаются синхронизированными с UTC.

Датой события считается время UTC, при котором событие произошло. Даты — это эфемерные значения, обозначаемые символом T. Время при работе (running time) — это шкала времени, совпадающая с функцией синхронизации программы NTP.

Метка времени T(t) представляет дату UTC или смещение от UTC в момент t (running time). Какой из двух смыслов применяется должно быть ясно из контекста. Пусть T(t) — смещение по времени (time offset), R(t) — смещение по частоте (frequency offset), D(t) — скорость старения (первая производная R(t) по t). Тогда, если T(t_0) — смещение по времени UTC, определённое в момент t = t_0, смещение по времени UTC в момент t составляет

   T(t) = T(t_0) + R(t_0)(t-t_0) + 1/2 * D(t_0)(t-t_0)^2 + e

где e — стохастическая ошибка (см. ниже). Хотя значение D(t) важно при характеризации точности задающих генераторов, этим значением обычно пренебрегают для компьютерных тактовых генераторов. В этом документе все значения времени даются в секундах, а значения допуска частоты в секундах за секунду (s/s). Иногда удобно выражать частотные сдвиги в миллионных долях 10^-6.

В компьютерных хронометрических приложениях важно оценивать производительность хронометрической функции. Модель производительности NTP включает 4 статистических показателя, обновляемые при каждом измерении (корректировке) времени с сервером. Смещение (theta) представляет максимально вероятное смещение часов сервера относительно системных часов. Задержка (delta) представляет круговую (round-trip) задержку между клиентом и сервером. Дисперсия (epsilon) указывает максимальную ошибку, присущую измерению, которая растёт со скоростью, равной максимально допустимому допуску тактовой частоты в дисциплине системных часов (PHI), который обычно составляет 15 ppm. Вариации (jitter, psi) определяются как среднеквадратичное (root-mean-square или RMS) значение последних разностей смещений и указывает номинальную ошибку при оценке смещения.

Параметры theta, delta, epsilon, psi представляют измерения системных часов раздельно по отношению к каждому серверу, а протокол NTP включает механизмы объединения статистики для нескольких серверов, улучшающие дисциплину и точность калибровки системных часов. Смещение системы (THETA) представляет максимально вероятное смещение часов относительно совокупности серверов. Вариации (PSI) представляют номинальную ошибку при оценке смещения системы. Статистика delta и epsilon аккумулируется от эталонных часов для каждого слоя и дают корневую задержку (DELTA) и дисперсию (EPSILON). Дистанция синхронизации (LAMBDA), равная EPSILON + DELTA / 2, указывает максимальную ошибку для всех случаев. Подробное описание этих показателей статистики приведено в параграфе 11.2. Операции системного процесса. Параметры доступны зависимым приложениям для оценки производительности функции синхронизации.

5. Модель реализации

На рисунке 2 показана архитектура типовой многопотоковой реализации. Она включает 2 выделенных процесса на каждый сервер — партнёрский (peer) процесс для получения сообщений от сервера или эталонных часов и процесс опроса (poll) для передачи сообщений серверу или эталонным часам.

.....................................................................
. Удаленные.   Процессы   .              Системный       . Процесс  .
. серверы  .   Peer/Poll  .              процесс         .дисциплины.
.          .              .                              . часов    .
.+--------+. +-----------+. +------------+               .          .
.|        |->|           |. |            |               .          .
.|Сервер 1|  |Peer/Poll 1|->|            |               .          .
.|        |<-|           |. |            |               .          .
.+--------+. +-----------+. |            |               .          .
.          .       ^      . |            |               .          .
.          .       |      . |            |               .          .
.+--------+. +-----------+. |            |  +-----------+.          .
.|        |->|           |. | Алгоритмы  |->|           |. +------+ .
.|Сервер 2|  |Peer/Poll 2|->| выбора и   |  | Алгоритм  |->|Фильтр| .
.|        |<-|           |. | кластера   |  |комбиниров.|. | Loop | .
.+--------+. +-----------+. |            |->|           |. +------+ .
.          .       ^      . |            |  +-----------+.    |     .
.          .       |      . |            |               .    |     .
.+--------+. +-----------+. |            |               .    |     .
.|        |->|           |. |            |               .    |     .
.|Сервер 3|  |Peer/Poll 3|->|            |               .    |     .
.|        |<-|           |. |            |               .    |     .
.+--------+. +-----------+. +------------+               .    |     .
....................^.........................................|......
                    |                                    .    V     .
                    |                                    . +-----+  .
                    +--------------------------------------| VFO |  .
                                                         . +-----+  .
                                                         . Процесс  .
                                                         .корректир..
                                                         .  часов   .
                                                         ............

Рисунок 2. Модель реализации.

Эти процессы работают с общей структурой данных, называемой ассоциацией, которая содержит описанные выше показатели статистики вместе с различными структурами данных, описанными в разделе 9. Клиент передаёт пакеты одному или нескольким серверам, а затем обрабатывает возвращённые пакеты. Сервер меняет местами адреса и номера портов отправителя и получателя, переписывает некоторые поля в пакете и возвращает пакет сразу (в режиме клиент-сервер) или спустя некоторое время (в симметричном режиме). При получении каждого сообщения NTP рассчитывается смещение theta между часами системы и партнёра, а также связанная с статистика delta, epsilon, psi.

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

Процесс дисциплины часов является системным процессом, контролирующим время и частоту системных часов, представленные генератором переменной частоты (variable frequency oscillator или VFO). Временные метки (тики) от VFO замыкают контур обратной связи, поддерживающей системное время. С процессом дисциплины связан процесс корректировки часов (clock-adjust), запускаемый 1 раз в секунду для внесения расчётного сдвига часов и поддержки постоянной частоты. Значение RMS разностей прошлых смещений времени представляет номинальную ошибку или вариации (jitter) системных часов. RMS разностей прошлых смещений частоты представляет стабильность тактового генератора или дрейф частоты. Точная интерпретация этих терминов представлена в параграфе 11.3.

Клиент передаёт сообщения каждому серверу с интервалом 2^tau секунд, определяемому показателем опроса tau. В NTPv4 параметр tau составляет от 4 (16 секунд) до 17 (36 часов). Значение tau определяет алгоритм дисциплины часов, чтобы соответствовать постоянной цикла времени T_c = 2^tau. В режиме клиент-сервер серверы отвечают незамедлительно, однако в симметричных режимах каждый из двух партнёров поддерживает tau как функцию текущего смещения и вариаций системы, поэтому партнёры могут не согласовать общее значение. Важно, чтобы динамическое поведение алгоритма дисциплины часов тщательно контролировалось для поддержки стабильности подсети NTP в целом. Это требует от партнёров согласования общего значения tau, равного меньшему из двух показателей опроса среди партнёров. Протокол NTP включает средства надлежащего согласования этого параметра.

Модель реализации включает некоторые средства установки и корректировки системных часов. Предполагается, что операционная система предоставляет две функции — одну для установки времени напрямую (например, функция Unix settimeofday()), другую для корректировки времени на небольшое значение вперёд или назад (например, функция Unix adjtime()). Здесь и далее скобки после имени отличают функцию от простой переменной. В предлагаемом решении процесс дисциплины часов использует adjtime(), если корректировка меньше заданного порога, и settimeofday() — в иных случаях. Способ корректировки и значение порога рассматриваются в разделе 10. Алгоритм фильтрации часов.

6. Типы данных

Все значения времени в NTP представляются в формате дополнение до 2 с порядком битов big-endian (см. Приложение A к [RFC0791]), нумеруемых с 0 для старшего (левого) бита. Имеется 3 формата времени NTP, 128-битовые даны, 64-битовые метки и 32-битовые короткие метки, как показано на рисунке 3. 128-битовые даты применяются в тех случаях, когда имеется достаточно места. Значение включает 64-битовое целое число со знаком для указания целых секунд, что позволяет представить 584 миллиарда лет, и 64-битовое значение дробной части с дисретностью 0,05 аттосек (0,05*10^-184). Для удобства сопоставления форматов поле seconds поделено на два поля — 32-битовое значение Era Number и 32-битовое значение Era Offset. Эры не могут создаваться NTP напрямую, да это и не требуется. При необходимости это можно сделать внешними средствами, такими как файловая система или специальное оборудование.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Seconds              |           Fraction            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                        Короткий формат NTP

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                            Seconds                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                            Fraction                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                     Формат временной метки NTP

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           Era Number                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           Era Offset                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                           Fraction                            +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                         Формат даты NTP

Рисунок 3. Форматы времени NTP.

64-битовые метки времени применяются в заголовках пакетов и других местах с ограниченным пространством. Они включают 32-битовое целое число без знака для указания секунд, что охватывает интервал в 136 лет, и 32-поле долей секунд с разрешением 232 пикосекунды. 32-битовый короткий формат применяется полях заголовков задержки и дисперсии, где полное разрешение и диапазон других форматов не оправданы. Это формат включает 16-битовое целое число без знака для учёта секунд и 16-битовое поле долей секунд. В форматах даты и временных меток первичной эпохой или базовой датой служит Era 0, начинающаяся в полночь (0 часов) 1 января 1900 г. по часовому поясу UTC, когда все биты имеют значение 0. Следует отметить, что, строго говоря, UTC не существовало до 1 января 1972 г., но удобно предполагать что UTC было всегда, даже если все исторические сведения о високосных секундах были утеряны. Даты исчисляются относительно этой первичной эпохи и отрицательные значения представляют время до начала эпохи. Отметим, что поле Era Offset в формате даты и поле Seconds в формате временных меток интерпретируются одинаково.

Временные метки являются беззнаковыми и операции над ними дают результат из той же или смежной эры. Эра 0 включает даты от начала первичной эпохи до некого момента в 2036 г., когда поле временной метки достигнет максимума и будет создана базовая дата эры 1. В любом формате метка со значением 0 указывает неизвестное или несинхронизированное время. На рисунке 4 приведены знаменательные даты NTP с соответствующими изменёнными юлианскими датами (Modified Julian Day или MJD), эрой и меткой NTP.

Рисунок 4. Интересные исторические даты NTP.

Если p — число значимых битов во второй части, тогда разрешение часов в секундах будет определяться значением 2^-p. Чтобы минимизировать смещение и сделать метки времени непредсказуемыми для нарушителя, для незначащих битов следует устанавливать случайную битовую строку без смещения. Точность часов определяется как время на считывание часов. Отметим, что определённая таким образом точность может быть больше или меньше разрешения (дискретности) часов. Элемент rho, представляющий точность в этом протоколе, является большим из этих двух.

Единственной разрешённой для дат и меток времени арифметической операцией является вычитание с дополнением до 2, дающее 126- или 64-битовое значение со знаком. Крайне важно, чтобы в разности первого порядка между двумя датами сохранялось полное 128-битовое значение, а в разности меток — полное 64-битовое. Однако разность обычно мала по сравнению с интервалом секунд, поэтому её можно преобразовать в действительное число с плавающей запятой для дальнейшей обработки без потери точности. Важно отметить, что в арифметике с дополнением до 2 нет различий между значениями со знаком и без него (хотя при сравнении знак учитывается), различия проявляются только при ветвлении. Таким образом, несмотря различие дат со знаком и беззнаковых меток, они обрабатываются одинаково. Опасность при операциях с 64-битовыми метками времени, охватывающими эпоху, может возникать, например, в 2036 г., приводя к переполнению. На деле, если клиент был установлен в интервале 68 лет от сервера до запуска протокола, корректные значения будут получены даже при нахождении клиента и сервера в смежных эрах.

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

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

   era = s / 2^(32) 
   timestamp = s - era * 2^(32)

Эти выражения применимы для положительных и отрицательных дат. Для получения метки времени из значений the era и timestamp служит выражение

   s = era * 2^(32) + timestamp.

Преобразование между NTP и системным временем может быть немного запутанным и выходит за рамки этого документа. Отметим, что число дней эры 0 на 1 больше числа дней во многих других эрах и это повторится уже около 2400 г. в эру 3.

В последующих описаниях переменных состояния явное указание целочисленного типа (integer) предполагает 32-битовое целое число без знака. Это урощает проверку границ, поскольку требуется задать лишь верхний предел. Без явного указания предполагается 64-битовое действительное число с плавающей запятой и двойной точностью. Исключения указываются, когда это необходимо.

7. Структуры данных

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

7.1. Соглашения о структурах

Чтобы различать одноименные переменные из разных процессов применяются префиксы, показанные на рисунке 5. Переменная принимаемого пакета v, являющаяся членом структуры пакета r, имеет полное обозначение r.v. Аналогично, x.v будет переменной передаваемого пакета, p.v — переменной партнёра, s.v — системной переменной, c.v — переменной дисциплины часов. Имеется набор партнёрских переменных для каждой ассоциации и лишь по одному набору системных переменных и переменных часов.

Рисунок 5. Соглашения о префиксах.

7.2. Глобальные параметры

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

Указаны лишь глобальные переменные требуемые для совместимости и любой реализации потребуется больший набор. В Приложении A.1.1 показаны глобальные переменные используемые в скелете кода для алгоритмов смягчения, дисциплины часов и связанных с ними функций, зависящих от реализации. Некоторые из значений параметров неизменны (например, номер порта NTP, выделенный IANA, и номер версии протокола NTPv4). Другие, например допуск по частоте (PHI), включают допущение о наихудшем поведении системных часов, синхронизированных однократно с последующим дрейфом, когда источник синхронизации становится недоступным. Минимальные и мксимальны значения параметров задают пределы переменных состояния в последующих параграфах документа.

Рисунок 6. Глобальные параметры.

Хотя переменные в этом документе показаны с фиксированными значениями, некоторые реализации могут делать их настраиваемыми в конфигурации. Например, эталонная вычисляет значение PRECISION как двоичный логарифм (log2) минимального времени среди нескольких итераций считывания системных часов.

7.3. Переменные заголовков пакетов

Наиболее важны с внешней точки зрения переменные состояния представлены на рисунке 7 и далее. Заголовок пакета NTP из целого числа 32-битовых (4 октета) слов с сетевым порядком байтов. Пакет включает заголовок, а также может включать одно или несколько полей расширения и код проверки подлинности (message authentication code или MAC). Компоненты заголовка идентичны применяемым в NTPv3 и предыдущих версиях. Необязательные поля расширения применяются криптографическими алгоритмами открытых ключей Autokey, как описано в [RFC5906]. Необязательное поле MAC используется Autokey и криптографическими алгоритмами, описанными в этом RFC.

Рисунок 7. Переменные заголовков пакетов.

  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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |LI | VN  |Mode |    Stratum     |     Poll     |   Precision   |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                         Root Delay                            |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                         Root Dispersion                       |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                          Reference ID                         |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 |                     Reference Timestamp (64)                  |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 |                      Origin Timestamp (64)                    |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 |                      Receive Timestamp (64)                   |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 |                      Transmit Timestamp (64)                  |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 .                                                               .
 .                    Extension Field 1 (переменный)             .
 .                                                               .
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 .                                                               .
 .                    Extension Field 2 (переменный)             .
 .                                                               .
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                          Key Identifier                       |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 |                      Message Digest (128)                     |
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 8. Формат заголовка пакета.

Пакет NTP передаётся в дейтаграмме UDP [RFC0768]. Некоторые поля используют несколько слов, а иные размещаются в меньших полях внутри слова. Заголовок пакета NTP, показанный на рисунке 8, имеет 12 слов, за которыми могут следовать поля расширения и код аутентификации (MAC), состоящий из полей идентификатора ключа и дайджеста сообщения.

Поля расширения служат для добавления необязательных возможностей, например, протокола безопасности Autokey [RFC5906]. Формат поля расширения предназначен для обеспечения возможности его разбора без знания функций поля. Код MAC применяется в Autokey и схеме симметричного шифрования.

Переменные заголовков пакетов представлены на рисунке 7 и подробно описаны ниже. За исключением небольших изменений, связанных с использованием адресов семейства IPv6, эти поля совместимы с NTPv3. Поля заголовков пакетов применяются для передаваемых (префикс x) и примаемых (префикс r) пакетов. На рисунке 8 размер нескольких многословных полей указан в битах, если он отличается от принятых по умолчанию 32 битов. Базовый заголовок простирается от начала пакета до конца поля Transmit Timestamp. Поля и связанные с ними переменные (в скобках) описаны ниже.

LI Leap Indicator (leap)

2-битовое целочисленное предупреждение о приближающейся високосной секунде, добавляемой или удаляемой в последнюю минуту суток⁹, как указано на рисунке 9.

Рисунок 9. Индикатор високосной секунды.

VN Version Number (version)

3-битовое целое число, представляющее номер версии NTP. Текущее значение — 4.

Mode (mode)

3-битовое целое число, представляющее режим. Значения режима приведены на рисунке 10.

Рисунок 10. Режимы ассоциаций.

Stratum (stratum)

8-битовое целое число, представляющее слой (Рисунок 11).

Рисунок 11. Слой пакета.

Обычно значение 0 в полученных пакетах сопоставляется со значением MAXSTRAT (16) в переменной партнёра p.stratum, а значения p.stratum = MAXSTRAT и выше сопоставляются с 0 в передаваемых пакетах. Это позволяет удобно умещать эталонные часы, которые обычно относятся к слою 0, с использованием того же лагоритма выбора чассов, который применяется для внешних источников (см. для примера Приложение A.5.5.1).

Poll

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

Precision

8-битовое целое число, представляющее точность системных часов двоичным логарифмом числа секнд. Например, значение -20¹⁰ соответствует точности около 1 мксек. Точность может определяться при первом запуске службы как минимальное время нескольких операций считывания системных часов.

Root Delay (rootdelay)

Суммарная круговая задержка для эталонных часов в коротком формате NTP.

Root Dispersion (rootdisp)

Суммарная дисперсия для эталонных часов в коротком формате NTP.

Reference ID (refid)

32-битовый код, указывающий конкретный сервер или эталонные часы. Интерпретация значения зависит от поля stratum. При stratum=0 (не задано или недействительно) это 4-символьная строка ASCII [RFC1345], называемая kiss-кодом и служащая для отладки и мониторинга. При stratum=1 (эталонные часы) это 4-октетная, выровненная слева и дополненная справа нулями строка ASCII, назначенная эталонным часам. Полномочный список идентификаторов эталонных часов поддерживается IANA (Рисунок 12), а строки, начинающиеся символом ASCII X зарезервированы для нерегистрируемых значений, применяемых в экспериментах и разработке.

Рисунок 12. Идентификаторы источников точного времени.

Для stratum > 1 (вторичные серверы и клиенты) указывает сервер и может служить для обнаружения петель синхронизации. При использовании адресов семейства IPv4 идентификатором служит 4-октетный адрес IPv4, при использовании IPv6 — первые 4 октета хэш-значения MD5 для адреса IPv6. Отметим, что при использовании семейства IPv6 на сервере NTPv4 с клиентом NTPv3 поле Reference Identifier будет случайным значением и не сможет применяться для обнаружения петель синхронизации.

Reference Timestamp

Время, когда системные часы последний раз устанавливались или корректировались (метка NTP).

Origin Timestamp (org)

Время клиента в момент отправки запроса серверу (метка NTP).

Receive Timestamp (rec)

Время сервера в момент прибытия запроса от клиента (метка NTP).

Transmit Timestamp (xmt)

Время сервера в момент отправки отклика клиенту (метка NTP).

Destination Timestamp (dst)

Время клиента в момент прибытия отклика от сервера (метка NTP).

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

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

Поле MAC состоит из идентификатора ключа (Key Identifier), за которым следует дайджест сообщения. Дайджест или криптографическая сумма вычисляется в соответствии с [RFC1321] для заголовка NTP и полей расширения без MAC.

Extension Field n

Формат поля описан в параграфе 7.5. Формат поля расширения NTP.

Key Identifier (keyid)

32-битовое целое число без знака, используемое клиентом и сервером для обозначения секретного 128-битового ключа MD5.

Message Digest (digest)

128-битовое хэш-значение MD5, вычисляемое для ключа, за которым следует заголовок пакета NTP и поля расширения (без учёта Key Identifier и Message Digest).

Следует отметить, что описанный здесь расчёт MAC отличается от заданного в [RFC1305] и [RFC4330], но совместим с генерацией MAC в имеющихся реализациях.

7.4. Пакет Kiss-o’-Death

Если Stratum = 0 (незаданный или недействительный слой), поле Reference Identifier может служить для передачи сообщений, полезных для отчётов о состоянии и контроля доступа. Такие пакеты называются «поцелуем смерти» Kiss-o’-Death или KoD), а сообщения ASCII в них — кодами kiss. Пакеты KoD получили своё имя потому, что сначала их применяли для указания клиенту прекратить передачу пакетов, нарушающих правила доступа к серверу. Коды kiss могут предоставить полезные сведения клиентам NTPv4 и SNTPv4. Kiss-коды представляются 4-символьными строками ASCII (Рисунок 13) с выравниванием по левому краю и дополнением нулями справа. Строки предназначены для символьных дисплеев и log-файлов. Получатель kiss-кода должен проверить его и в указанных ниже случаях выполнить действия.

1. Для DENY и RSTR клиент должен деактивировать все ассоциации с этим сервером и прекратить отправку пакетов ему.

2. Для kiss-кода RATE клиент должен незамедлительно увеличить свой интервал опроса для этого сервера и продолжать увеличение при каждом получении кода RATE¹¹.

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

4. В остальных случаях пакеты KoD не имеют значения для протокола и отбрасываются после проверки.

Рисунок 13. Kiss-коды.

Receive Timestamp и Transmit Timestamp (задаёт сервер) не определены для пакетов KoD, на из значения недопустимо полагаться и они должны отбрасываться.

7.5. Формат поля расширения NTP¹²

В NTPv4 могут включаться поля расширения после заголовка и перед кодом MAC (если MAC присутствует).

Этот документ определяет лишь формат поля, не задавая его использования. Поле расширения содержит сообщение запроса или отклика в формате, показанном на рисунке 14.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Field Type           |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.                                                               .
.                            Value                              .
.                                                               .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                   Padding (при необходимости)                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 14. Формат поля расширения.

Все поля расширения дополняются нулями до границы слова (4 октета).

Поля Field Type, Value, Padding зависят от заданной функции и не рассматриваются здесь. Значения Field Type заданы в ррестре IANA, а значения Length, Value, Padding определяются указанным в этом реестре документом. Если хост получает поле расширения с неизвестным Field Type, ему следует игнорировать это поле расширения и можно отбросить пакет совсем, если правила требуют этого.

Хотя минимальный размер поля, содержащего обязательные компоненты, составляет 4 слова (16 октетов), максимальный размер не может превышать 65532 октетов по причине ограниченного размера поля Length.

Length содержит 16-битовое целое число без знака, задающее размер поля расширения в октетах, включая Padding.

7.5.1. Поля расширения и коды MAC

7.5.1.1. Поля расширения при наличии MAC

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

7.5.1.2. Несколько полей расширения с MAC

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

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

7.5.1.3. MAC без полей расширения

Размер MAC более 24 октетов недопустим без поля расширения, если длинный код MAC не согласован клиентом и сервером. Согласование может быть выполнено в предыдущем обмене пакетами с полем расширения, задающим размер и алгоритм кодов MAC передаваемых в пакетах NTP.

7.5.1.4. Поля расширения без MAC

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

• При одном поле расширения размер этого поля должен быть не менее 7 слов (28 октетов).

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

8. Протокол в линии

Основой NTP является протокол on-wire, обеспечивающий ядро механизма обмена значениями времени между серверами, партнёрами и клиентами. Протокол по своей природе устойчив к потере и дублированию пакетов. Целостность данных обеспечивается контрольными суммами IP и UDP. Механизмы управления потоком данных и повторной передачи не требуются и не применяются. Протокол использует метки времени, извлекаемые из заголовков пакетов или системных часов в момент прибытия или отправки пакета. Метки являются прецизионными данными и их следует получать заново в случае повтора передачи на канальном уровне с поправкой на время расчёта MAC.

Сообщения NTP могут использовать два режима связи — «один с одним» или «один со многими», обычно называемые одноадресными (unicast) или широковещательными (broadcast). В этом документе широковещательным считается любой механизм, обеспечивающий передачу от одного ко многим. Для IPv4 это соответствует широковещательной или групповой передаче IPv4, для IPv6 — групповой передаче IPv6. Для этого агентство IANA выделило групповой адрес IPv4 224.0.1.1 и групповой адрес IPv6 с суффиксом :101 и префиксом, определяемым локальными правилами для области действия. Могут применяться также иные групповые адреса в дополнение к указанным.

Протокол в линии (on-wire) использует 4 метки времени с номерами от t1 до t4 и 3 переменных состояния org, rec и xmt, как показано на рисунке 15. Рисунок представляет общий случай, где каждый из двух партнёров (A и B) независимо измеряет смещение и задержку относительно другого. На рисунке метки указаны строчными буквами, а переменные состояния — прописными. Переменные состояния копируются из меток в пакетах при отправке и получении.

          t2            t3           t6            t7
     +---------+   +---------+   +---------+   +---------+
     |    0    |   |    t1   |   |   t3    |   |    t5   |
     +---------+   +---------+   +---------+   +---------+
     |    0    |   |    t2   |   |   t4    |   |    t6   | Метки
     +---------+   +---------+   +---------+   +---------+ пакета
     |   t1    |   |t3=clock |   |   t5    |   |t7=clock |
     +---------+   +---------+   +---------+   +---------+
     |t2=clock |                 |t6=clock |
     +---------+                 +---------+
                                                          Партнёр B
     +---------+   +---------+   +---------+   +---------+
org  |   T1    |   |    T1   |   | t5<>T1? |   |    T5   |
     +---------+   +---------+   +---------+   +---------+ Переменные  
rec  |   T2    |   |    T2   |   |   T6    |   |    T6   | состояния
     +---------+   +---------+   +---------+   +---------+
xmt  |    0    |   |    T3   |   |  t3=T3? |   |    T7   |
     +---------+   +---------+   +---------+   +---------+

               t2      t3                 t6          t7
     ---------------------------------------------------------
              /\         \                 /\            \
              /           \                /              \
             /             \              /                \
            /               \/           /                 \/
     ---------------------------------------------------------
          t1                t4         t5                  t8

         t1            t4            t5             t8
     +---------+   +---------+   +---------+   +---------+
     |    0    |   |    t1   |   |   t3    |   |    t5   |
     +---------+   +---------+   +---------+   +---------+
     |    0    |   |    t2   |   |   t4    |   |    t6   | Метки
     +---------+   +---------+   +---------+   +---------+ пакета
     |t1=clock |   |    t3   |   |t5=clock |   |    t7   |
     +---------+   +---------+   +---------+   +---------+
                   |t4=clock |                 |t8=clock |
                   +---------+                 +---------+
                                                          Партнёр A
     +---------+   +---------+   +---------+   +---------+
org  |    0    |   |  t3<>0? |   |   T3    |   | t7<>T3? |
     +---------+   +---------+   +---------+   +---------+ Переменные
rec  |    0    |   |    T4   |   |   T4    |   |    T8   | состояния
     +---------+   +---------+   +---------+   +---------+
xmt  |   T1    |   |  t1=T1? |   |   T5    |   |  t5=T5? |
     +---------+   +---------+   +---------+   +---------+

Рисунок 15. Протокол в линии.

На рисунке первый пакет, переданный A, содержит лишь метку источника t1, которая копируется в T1. Партнёр B принимает пакет в момент t2 и копирует t1 в T1 а метку приёма t2 — в T2. В этот момент или несколько позже в t3 партнёр B передаёт A пакет, содержащий t1, t2 и метку отправки t3. Все три метки копируются в соответствующие переменные состояния. A получает в момент t4 пакет с метками t1, t2, t3 и меткой получателя t4. Эти четыре метки служат для расчёта смещения и задержки B относительно A, как описано ниже.

До обновления значений xmt и org выполняются две проверки пригодности для защиты от дубликатов, подделок и повторов. В приведённом выше обмене пакет является дубликатом или повтором, если t3 в нем совпадает с переменной состояния org T3. Пакет является фиктивным, если метка источника t1 в нем не совпадает с переменной состояния xmt T1. В обоих случаях переменные состояния обновляются, а пакет отбрасывается. Для защиты от повторного использования (replay) переданного последним пакета в переменной состояния xmt устанавливает 0 сразу же после обнаружения подделки.

Для 4 наиболее свежих меток времени переменные T1 — T4 служат для расчёта смещения B относительно A

   theta = T(B) - T(A) = 1/2 * [(T2-T1) + (T4-T3)]13

и круговой задержки

   delta = T(ABA) = (T4-T1) - (T3-T2).

Отметим, что выражения в круглых скобках рассчитываются по 64-битовым меткам без знака и будут давать 63 бита значения и бит знака. Это позволяет представлять даты от 68 лет в прошлом до 68 в будущем, но смещение и задержка считаются как сумма и разность величин и дают 62 бита значения и 2 бита знаков, поэтому могут однозначно представлять время от 34 дет в прошлом до 34 в будущем. Иными словами, клиент должен быть установлен в интервале 34 до запуска сервера. Это фундаментальное ограничение 64-битовой арифметики целых чисел.

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

В некоторых случаях, где начальный сдвиг частоты клиента сравнительно велик, а реальное время распространения мало, результат расчёта задержки может быть отрицательным. Например, если разница частот составляет 100 ppm а интервал T4-T1 — 64 секунды, задержка будет равна -6,4 мсек. Поскольку отрицательные значения в последующих расчётах вводят в заблуждение, значение delta следует фиксировать не меньше s.rho, где s.rho — точность системы в секундах, как описано в параграфе 11.1.

Приведённое выше обсуждение предполагает наиболее общий случай, где два симметричных партнёра независимо измеряют смещения и задержки между собой. В случае сервера, не хранящего состояний протокол можно упростить. Такой сервер копирует T3 и T4 из клиентского пакета в T1 и T2 серверного пакета и присоединяет метку отправки T3 до передачи пакета клиенту. Сведения о заполнении других полей протокола приведены в разделе 9 и Приложении.

Отметим, что описанный протокол on-wire устойчив к повторному использованию пакетов отклика от сервера. Однако он не стоек к повторному использованию клиентских запросов, которые будут вынуждать сервер повторить пакет с новыми значениями T2 и T3, дающими некорректные результаты для смещения и задержки. Этой уязвимости можно избежать, установив значение 0 для переменной состояния xmt после расчёта смещения и задержки.

9. Партнёрский процесс

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

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

9.1. Переменные партнёрского процесса

На рисунках 16 — 19 приведены базовые имена, имена формул и краткие описания переменных партнёра. Базовые имена и имена формул взаимозаменяемы, имена формул предназначены для удобочитаемости уравнений в спецификации. Если явно не указано иное, для партнёрских переменных применяется префикс p.

Рисунок 16. Переменные конфигурации партнёрского процесса.

Рисунок 17. Переменные партнёрского процесса.

Рисунок 18. Переменные метки времени партнёрского процесса.

Рисунок 19. Статистические переменные партнёрского процесса.

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

srcaddr

IP-адрес удалённого сервера или эталонных часов. Он будет адресом получателя для пакетов из ассоциации.

srcport

Номер порта UDP на сервере или эталонных часах. Он будет портом получателя для пакетов из ассоциации. При работе в симметричных режимах (1 и 2), это поле должно содержать номер порт NTP PORT (123), выделенный IANA. В иных режимах номер порта определяется локальными правилами.

dstaddr

IP-адрес клиента. Он будет адресом отправителя для пакетов из ассоциации.

dstport

Номер порта UDP на клиенте, исходно порт NTP PORT (123), выделенный IANA. Он будет портом отправителя для пакетов из ассоциации.

keyid

Идентификатор симметричного ключа для 128-битового ключа MD5, служащий для генерации и проверки MAC. Клиент и сервер или партнёр могут использовать разные значения, но они должны указывать один ключ.

Переменные с рисунка 17 обновляются из заголовка каждого прибывающего пакета и интерпретируются так же, как одноименные переменные пакета. Для последующей обработки удобно преобразовать короткий формат NTP для r.rootdelay и r.rootdisp в переменные партнёра с форматом floating double.

Переменные с рисунка 18 включают временные метки, передаваемые протоколом (раздел 8). Переменная t указывает счётчик секунд c.t, связанный с этими значениями. Переменная c.t поддерживается процессом корректировки часов, описанным в разделе 12. Она учитывает секунды с момента запуска службы. Переменные с рисунка 19 включают статистику, рассчитываемую подпрограммой clock_filter(), описанной в разделе 10. Переменная tp содержит число секунд, связанное с этими значениями.

9.2. Операции партнёрского процесса

Процедура приёма определяет поток процессов по прибытию пакета, как показано функцией receive() в Приложении A.5.1. Для управления доступом не нужен специальный метода, хотя реализациям рекомендуется включать схему, аналогичныю многим широко применяемым. Функция access() в Приложении A.5.4 описывает метод реализации ограничений на основе списка контроля доступа (access control list или ACL). Проверка формата требует корректного размера и выравнивания полей, приемлемого номера версии (1-4) и корректного синтаксиса полей расширения при их наличии.

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

Затем выполняется поиск в таблице ассоциаций по адреса и порту источника, например, с помощью функции find_assoc() из Приложения A.5.1. На рисунке 20 приведена таблица диспетчеризации, где столбцы соответствуют режиму пакетов, а строки — режиму ассоциации. Ячейка на пересечении указывает один из описанных ниже шагов.

Рисунок 20. Таблица диспетчеризации партнёров.

DSCRD

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

ERR

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

FXMIT

Клиентский пакет (режим 3) не соответствует ассоциации (режим 0). Если адрес получателя не является широковещательным, сервер создаёт серверный пакет (режим 4) и возвращает его клиенту без сохранения состояния. Создаётся заголовок серверного пакета, пример описан в функции fast_xmit() Приложения A.5.3. Заголовок собирается из полученного пакета и системных переменных, как показано на рисунке 21. Если системные переменные хранятся в форме floating double, они должны преобразовываться в короткие метки NTP.

Переменная пакета -->     Переменная
r.leap            -->     p.leap
r.mode            -->     p.mode
r.stratum         -->     p.stratum
r.poll            -->     p.ppoll
r.rootdelay       -->     p.rootdelay
r.rootdisp        -->     p.rootdisp
r.refid           -->     p.refid
r.reftime         -->     p.reftime
r.keyid           -->     p.keyid

Отметим, что при отказе аутентификации сервер возвращает специальное сообщение crypto-NAK, включающее обычные данные заголовка NTP (Рисунок 8), но с кодом MAC, содержащим 4 октета нулей. Клиент может принять или отвергнуть данные сообщения. После этого партнёрский процесс завершается.

Если адрес получателя является групповым, отправитель работает в клиентском режиме manycast. Если пакет действителен и слой сервера меньше слоя клиента, сервер передаёт обычный среверный пакет (режим 4), но с одним из индивидуальных (unicast) адресов получателя. При отказе аутентификации crypto-NAK не передаётся. После этого партнёрский процесс завершается.

MANY

Серверный пакет (режим 4) не соответствует ассоциации. Обычно это происходит при отклике manycast-сервера на переданный ранее групповой пакет клиента. Если пакет действителен, активируется обычная ассоциация клиента (режим 3) и работа продолжается как при активации ассоциации по конфигурационному файлу.

NEWBC

Широковещательный пакет (режим 5) не соответствует ассоциации. Клиент активирует обычную (режим 3) или широковещательную (режим 6) ассоциацию. Примеры показаны в функциях mobilize() и clear() Приложения A.2. Затем пакет проверяется и инициализируются переменные партнёра, как показано в функции packet() Приложения A.5.1.1.

Если реализация не поддерживает дополнительных функций защиты или калибровки, ассоциация устанавливается в режим широковещательного клиента (режим 6) и процесс партнёра завершается. Реализации с аутентификацией на основе открытых ключей может применять Autokey или эквивалентный протокол защиты. Реализациям следует устанавливать режим ассоциации 3 и запускать короткий обмен клиент-сервер для определения задержки расппространения. После обмена устанавливается режим ассоциации 6 и процесс партнёра продолжается в режиме «только прослушивание». Отметим, различие между пакетом режима 6, зарезервированным для функций мониторинга и управления NTP, и режимом 6 в ассоциации.

NEWPS

Пакет симметричного активного режима (режим 1) не соответствует ассоциации. Клиент активирует симметричныую пассивную ассоциацию (режим 2). Пример приведён в функциях mobilize() и clear() Приложения A.2. Обработка продолжается, как описано ниже для PROC.

PROC

Пакет соответствует имеющейся ассоциации. Метки времени в пакете аккупатно проверяются для обнаружения недействительных, дублированных и фиктивных пакетов. Дополнительные проверки показаны на рисунке 22. Отметим, что все пакеты, включая crypto-NAK, считаются действительными лишь после прохождения этих тестов.

Рисунок 22. Проверка ошибок пакета.

Обработка продолжается копированием переменных пакета в переменные партнёра, как показано на рисунке 21. Пример этого приведён в функции packet() Приложения A.5.1.1. Функция receive() реализует тесты 1-5 (Рисунок 22), packet() — тесты 6-7. При обнаружении ошибки пакет отбрасывается и процесс партнёра завершается.

Протокол on-wire вычисляет смещение часов theta и круговую задержку delta по 4 наиболее свежим меткам времени, как описано в разделе 8. Хотя, в принципе, можно выполнить все расчёты, кроме разности первого порядка для временных меток, в арифметике с фиксированной запятой, много проще преобразовать разности первого порядка в floating double и выполнить оставшиеся расчёты в этой арифметике, как предполагается ниже.

Затем используется 8-битовый регистр сдвига p.reach (раздел 13) для определения доступности сервера и актуальности данных. Регистр сдвигается на 1 бит влево при передаче пакета с установкой правого бита в 0. При поступлении действительного пакета правый бит устанавливается (1). При наличии в регистре отличных от 0 битов сервер считается доступным, в ином случае — недоступным. Поскольку интервал опроса у партнёра мог измениться с последнего пакета, интервал опроса у хоста пересматривается. Пример представлен в функции poll_update() Приложения A.5.7.2.

Статистика дисперсии epsilon(t) представляет максимальную ошибку в результате допуска частоты и времени с момента передачи последнего пакета. Она инициализируется значением epsilon(t_0) = r.rho + s.rho + PHI * (T4-T1), когда измерение выполняется в момент t_0 согласно счетчику секунд. Здесь r.rho — точность пакета (параграф 7.3), а s.rho — точность системы (параграф 11.1), выраженные в секундах. Эти элементы требуются для учёта погрешности при считывании системных часов сервера и клиента.

Затем дисперсия растёт с постоянной скоростью PHI, т. е. в момент t будет epsilon(t) = epsilon(t_0) + PHI * (t-t_0). С принятым по умолчанию допуском PHI = 15 ppm это составляет около 1,3 сек/сутки. При таком подходе аргумент t отбрасывается и дисперсия представляется просто как epsilon. Остальная статистика рассчитывается алгоритмом фильтрации часов, описанным в следующем параграфе.

10. Алгоритм фильтрации часов

Алгоритм фильтра часов является частью процесса партнёра и обрабатывает поток данных для выбора образцов, представляющих наиболее точное время. Алгоритм создаёт переменные, показанные на рисунке 19, включая смещение (theta), задержку (delta), дисперсию (epsilon), вариации (psi) и время прибытия (t). Эти данные применяются алгоритмами смягчения для определения лучшего и окончательного смещения, применяемого дисциплиной системных часов, а также для определения работоспособности сервера и его пригодности для синхронизации.

Алгоритм фильтра часов сохраняет наиболее свежие квартеты выборки (theta, delta, epsilon, t) в структуре фильтра, служащей 8-ступенчатым регистром сдвига. Квартеты сохраняются в порядке прибытия пакетов, t указывает время прибытия по счётчику секунд и его не следует путать с партнёрской переменной tp.

Для обеспечения фильтру достаточного числа выборок и удаления старых данных применяется описанная далее схема. Исходно для квартетов всех ступеней устанавливаются фиктивные значения (0, MAXDISP, MAXDISP, 0), по мере прибытия новых пакетов квартеты сдвигаются в регистре с отбрасыванием старых и в результате остаются лишь действительные квартеты. Если 3 младших бита регистра охвата имеют значение 0, показывающее, что истекли 3 интервала опроса без приёма новых действительных пакетов, процесс опроса вызывает алгоритм фильтра часов с фиктивным квартетом, как будто тот прибыл из сети. Если это сохраняется в течение 8 интервалов опроса, регистр возвращается в исходное состояние. На следующем этапе ступени регистра сдвига копируются во временный список с сортировкой по возрастанию delta. Путь i — индекс ступени, начинающейся с минимального значения delta. Если первая эпоха квартета t_0 не позднее эпохи последней действительной выборки tp, программа завершается без изменения текущих переменных партнёра. В ином случае для дисперсии i-й записи epsilon_i — выражение

                     i=n-1
                     ---     epsilon_i
      epsilon =       \     ----------
                      /        (i+1)
                     ---     2
                     i=0

задаёт дисперсию партнёра p.disp. Отметим, что при переполнении epsilon на входе или выходе фильтра часов смысл должен быть ясен из контекста.

Наблюдатель следует отметить: (a) если все все ступени содержат фиктивные квартеты с дисперсией MAXDISP, рассчитанная дисперсия составит чуть меньше 16 сек, (b) при каждом сдвиге действительного квартета в регистр дисперсия падает чуть меньше, чем на половину в зависимости от дисперсии действительного квартета, (c) после четвёртого действительного квартета дисперсия обычно будет чуть меньше 1 сек, что является предполагаемым значением параметра MAXDIST по которому алгоритм выбора определяет приемлемость переменных партнёра.

Пусть смещение первой ступени в сортированном списке будет theta_0. Тогда для других ступеней в любом порядке вариация будет определяться средним значением RMS¹⁴

              +-----                             -----+^1/2
              |              n-1                      |
              |              ---                      |
              |    1         \                     2  |
      psi   = | -------- *   /    (theta_0-theta_j)   |
              |  (n-1)       ---                      |
              |              j=1                      |
              +-----                             -----+

где n — число действительных квартетов в фильтре (n > 1). Для обеспечения согласованности и предотвращения исключений при делении в других расчётах значение psi ограничивается снизу точностью системы s.rho, выраженной в секундах. Хотя обычно вариации не считаются основным фактором ранжирования качества серверов, это важный индикатор работы хронометража и состояний перегрузки в сети. Особое значение для алгоритмов смягчения имеет дистанция синхронизации с партнёром, которая вычисляется по задержке и дисперсии.

   lambda = (delta / 2) + epsilon

Отметим, что epsilon и, следовательно, lambda растёт со скоростью PHI. Переменная lambda не является переменной состояния, поскольку она рассчитывается при каждом применении. Это часть корневой дистанции синхронизации, применяемая алгоритмами смягчения как показатель качества времени, доступного от каждого сервера.

Важно отметить, что, в отличие от NTPv3, ассоциации NTPv4 не указывают тайм-аут установкой слоя 16 и индикатора високосных секунд 3. Переменные ассоциации сохраняют значения, полученные при поступлении последнего пакета. В NTPv4 значение lambda растёт со временем, поэтому в конечном итоге дистанция синхронизации превышает порог MAXDIST, после чего ассоциация считается не пригодной для синхронизации.

Пример реализации алгоритма фильтра часов содержится в функции clock_filter() из Приложения A.5.2.

11. Системный процесс

При получении каждой новой выборки (theta, delta, epsilon, jitter, t) алгоритмом фильтра часов все процессы партнёров сканируются алгоритмами смягчения, состоящими из алгоритмов выбора, кластера, комбинирования и дисциплины часов в системном процессе. Алгоритм выбора сканирует все ассоциации и отбрасывает фальшивые часы, которые указывают неверное время, оставляя лишь истинные. В серии раундов алгоритм кластера отбрасывает ассоциации, наиболее удалённые статистически от центроида, пока не останется заданное минимальное их число. Алгоритм комбинирования даёт лучшую и окончательную статистику на основе средневзвешенного значения. Окончательное смещение передаётся алгоритму дисциплины часов для корректировки времени системных часов.

Алгоритм кластера выбирает одного из оставшихся в качестве партнёра системы. Связанная с ним статистика (theta, delta, epsilon, jitter, t) служит для создания системных переменных, наследуемых зависимыми серверами и клиентами, доступными для других приложений на той же машине.

11.1. Переменные системного процесса

На рисунке 23 приведены базовые имена, формулы и краткие описания каждой системной переменной. Если явно не указано иное, все переменные имеют суффикс s.

Рисунок 23. Переменные системного процесса.

За исключением переменных t, p, offset, jitter и констант NMIN и CMIN, для переменных системы применяется тот же формат и интерпретация, что и для одноимённых переменных партнёра. Параметры NMIN и CMIN, используемые алгоритмами выбора и кластера, описаны в следующем параграфе.

Переменная t указывает счётчик секунд в момент последнего обновления, пример приведён в функции clock_update() (Приложение A.5.5.4). Переменная p содержит идентификатор партнёра системы, определяемый функцией cluster() (параграф 11.2.2). Переменная precisionс имеет такой же формат, что и одноимённая переменная партнёра. Точность определяется как двоичных логарифм большего из значений разрешения и времени считывания. Например, точность тактового генератора от сети переменного тока 60 Гц составляет 16 мсек, даже если аппаратные часы представляются с точностью в наносекунду. Переменные offset и jitter определяет алгоритм комбинирования (параграф 11.2.3). Они представляют лучшее и окончательное смещение и вариацию, используемые дисциплиной системных часов.

Исходно все переменные сбрасываются в 0, затем устанавливается leap = 3 (не синхронизировано) и stratum = MAXSTRAT (16). Помните, что MAXSTRAT в передаваемых пакетах указывается значением 0.

11.2. Операции системного процесса

На рисунке 24 показаны операции системного процесса, выполняемые программой выбора часов. Описанный в параграфе 11.2.1 алгоритм выдаёт набор основных предполагаемых кандидатов (истинные часы) на основе принципов соглашения. Алгоритм кластера (параграф 11.2.2) отбрасывает лишних кандидатов для создания более узкого набора. Алгоритм комбинирования (11.2.3) выдаёт наилучшее и окончательное смещение для алгоритма дисциплины часов. Пример представлен в Приложении A.5.5.6. Если алгоритм выбора не может создать набор кандидатов (majority clique) или не возможно выдать хотя бы CMIN оставшихся, системный процесс завершается без дисциплины системных часов. При успешном выполнении алгоритм кластера выбирает статистически оучшего кандидата как партнёра системы и его переменные наследуются как переменные системы.

                       +-----------------+
                       | clock_select()  |
                       +-----------------+
................................|...........
.                               V          .
.      yes +---------+ +-----------------+ .
.       +--| accept? | |  сканирование   | .
.       |  +---------+ |   кандидатов    | .
.       V        no |  |                 | .
.  +---------+      |  |                 | .
.  | add peer|      |  |                 | .
.  +----------      |  |                 | .
.       |           V  |                 | .
.       +---------->-->|                 | .
.                      |                 | .
. Алгоритм выбора      +-----------------+ .
.................................|..........
                                 V
                    no +-------------------+
         +-------------|     остались?     |
         |             +-------------------+
         |                       | yes
         |                       V
         |             +-------------------+
         |             | Алгоритм кластера |
         |             +-------------------+
         |                       |
         |                       V
         V         yes +-------------------+
         |<------------|     n < CMIN?     |
         |             +-------------------+
         V                       |
  +-----------------+            V no
  |   s.p = NULL    |  +-------------------+
  +-----------------+  |   s.p = v_0.p     |
         |             +-------------------+
         V                       |
  +-----------------+            V
  | return (UNSYNC) |  +-------------------+
  +-----------------+  |   return (SYNC)   |
                       +-------------------+

Рисунок 24. Процедура выбора часов.

11.2.1. Алгоритм выбора

Алгоритмы выбора и кластера описаны по отдельности, но в скелете кода объединены. Алгоритм выбора ищет пересечение интервалов, содержащее основные истинные часы, по принципам византийского алгоритма, исходно предложенного Marzullo [ref6], но изменённого для повышения точности. Обзор алгоритма приведён ниже, а код представлен в первой половине функции clock_select() в Приложении A.5.5.1.

Сначала серверы, не подходящие по правилам протокола обнаруживаются и отбрасываются, как показано в функции accept() Приложения A.5.2¹⁵. Затем создаётся набор триплетов (p, type, edge) для оставшихся кандидатов. Здесь p — идентификатор ассоциации, type указывает верхнюю (+1), среднюю (0) и нижнюю (-1) конечные точки интервала корректности кандидата с центром theta. Это даёт 3 триплета lowpoint (p, -1, theta — lambda), midpoint (p, 0, theta), highpoint (p, +1, theta + lambda), где lambda — корневая дистанция синхронизации. Пример расчёта показан в функции root_dist() Приложения A.5.1.2¹⁶. Этапы алгоритма приведены ниже.

1. Для каждой из m ассоциаций 3 триплета помещаются в список кандидатов, как указано выше.

2. Триплеты списка сортируются по краевым компонентам в порядке lowpoint, midpoint, highpoint. Для числа фальшивых часов устанавливается значение f = 0.

3. Устанавливается число средних точек d = 0, а также c = 0 и выполняется сканирование от низшей точки к высшей. Значение c увеличивается на 1 для каждой lowpoint, снижается на 1 для каждой highpoint и добавляется 1 к каждой midpoint. Если c >= m — f, выполнение завершается и в качестве l устанавливается текущая нижняя точка.

4. Устанавливается c = 0 и выполняется сканирование от верхней точки к нижней. К c добавляется 1 для каждой highpoint и вычитается 1 для каждой lowpoint, к d добавляется 1 для каждой . Если c >= m — f, выполнение завершается и в качестве u устанавливается текущая верхняя точка.

5. Проверяется выполнение условий d <= f¹⁷ и l < u. При соблюдении выполняется 5A, иначе — 5B.

   1. Интервалом пересечения будет [l, u].

   2. К f добавляется 1 и проверяется условие f < (m / 2). При выполнении возврат к п. 3, иначе — 6.

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

Алгоритм подробно описан в Приложении A.5.5.1. Отметим, что он начинается с допущения отсутствия фальшивых часов (f = 0) и попытки еайти непустой интервал пересечения со средними точками всех корректных серверов (истинные часы). Если такой интервал не найден, число предполагаемых ложных часов увеличивается на 1 и попытка повторяется. Если интервал найден и число ложных часов меньше числа истинных, набор кандидатов найден и midpoint каждых истинных часов (theta) представляет кандидатов, доступных для алгоритма кластера.

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

11.2.2. Алгоритм кластера

Кандидаты из набора помещаются в список оставшихся v в форме триплетов (p, theta_p, psi_p, lambda_p), где p — идентификатор ассоциации, theta_p, psi_p и stratum_p — текущее смещение, вариации (jitter) и слой ассоциации p, соответственно, а lambda_p — показатель качества, равный stratum_p * MAXDIST + lambda, где lambda — корневая дистанция синхронизации для p. Список обрабатывается алгоритмом кластера, как описано ниже, а пример можно найти во второй половине алгоритма clock_select() из Приложения A.5.5.1.

1. Пусть (p, theta_p, psi_p, lambda_p) представляет сохранившегося кандидата.

2. Кандидаты сортируются по росту lambda_p. Пусть n — число кандидатов, а NMIN — минимально требуемое число оставшихся.

3. Для каждого кандидата рассчитывается вариация выбора как

             +-----                       -----+^1/2
             |        n-1                      |
             |        ---                      |
             |   1    \                     2  |
     psi_s = | ---- * /  (theta_s - theta_j)   |
             |  n-1   ---                      |
             |        j=1                      |
             +-----                       -----+

4. Выбирается psi_max как кандидат с наибольшим значением psi_s.

5. Выбирается psi_min как кандидат с наименьшим значением psi_p.

6. Если psi_max < psi_min или n <= NMIN, выполняется 6A, иначе — 6B.

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

   2. Удаляется кандидат с psi_max, значение n уменьшается на 1 и алгоритм возвращается к п. 3.

Алгоритм работает с серией раундов, в каждом из которых отбрасывается статистический выброс с максимальной вариацией выбора psi_s. Однако, если psi_s меньше минимальной вариации партнёра psi_p, отбрасывание выбросов уже не даст улучшения. Это минимальное число оставшихся даёт условие завершения алгоритма. По завершении финальное значение psi_max сохраняется как вариация выбора системы PSI_s для последующего применения.

11.2.3. Алгоритм комбинирования

Маршрут комбинирования часов обрабатывает оставшихся кандидатов для создания лучших и окончательных данных для алгоритма дисциплины часов. Программа обрабатывает статистику смещения и вариаций партнёра для создания комбинированного смещения THETA и вариаций PSI_p, где статистика каждого сервера «взвешивается» обратной величиной корневой дистанции синхронизации и результат нормализуется (см. функцию clock_combine() в Приложении A.5.5.5)

Комбинированное значение THETA передаётся программе обновления часов. Первый кандидат из списка оставшихся назначается партнёром системы с идентификатором p. Его значение является компонентом вариаций системы PSI и применяется вместе с PSI_s для расчёта, как показано ниже.

   PSI = [(PSI_s)^2 + (PSI_p)^2]^1/2

При каждом обновлении, полученном от партнёра системы вызывается программа обновления часов. По правилу обновление отбрасывается, если время прибытия p.t не строго позже последнего принятого обновления s.t. Метки IGNOR, PANIC, ADJ, STEP указывают коды возврата локальной программы часов, описанной в следующем параграфе.

IGNORE указывает, что обновление проигнорировано, как выброс, PANIC означает смещение, превышающее порог PANICT (1000 сек) и по нему следует завершать программу с диагностическим сообщением для журнала системы (log). STEP указывает, что смещение меньше PANICT, но больше порога ступени STEPT (125 мсек). В этом случае часы переводятся на корректное смещение, но, поскольку это означает недействительность всех данных партнёра, все ассоциации должны быть сброшены, а клиент начинает заново как при исходном запуске.

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

Системная переменная <-- Системная переменная партнёра 
         s.leap      <-- p.leap
         s.stratum   <-- p.stratum + 1
         s.offset    <-- THETA
         s.jitter    <-- PSI
         s.rootdelay <-- p.delta_r + delta
         s.rootdisp  <-- p.epsilon_r + p.epsilon + 5* p.psi + PHI * (t_s - p.t) + |THETA|
         s.refid     <-- p.refid
         s.reftime   <-- p.reftime
         s.t         <-- p.t

Рисунок 25. Обновление системных переменных.

Переменная t_s указывает время обновления системных переменных. На рисунке не показана важная деталь. Инкремент дисперсии (p.epsilon + 5 * p.psi + PHI * (t_s — p.t) + |THETA|) ограничен снизу значением MINDISP. В подсетях с очень быстрыми процессорами и скоростью, а также очень малой задержкой и дисперсией это ведёт к монотонно-определённому росту s.rootdisp (EPSILON), что предотвращает петли между партнёрами, работающими в одном слое¹⁸.

Системные переменные доступны зависимым прикладным программам как номинальная статистика производительности. Системное смещение THETA — смещение часов относительно источников синхронизации, системные вариации PSI — оценка ошибки при определении значения, иногда называемая ожидаемой ошибкой. Корневая задержка DELTA — суммарная круговая задержка до первичного сервера. Корневая дисперсия EPSILON — дисперсия аккумулированная в сети от первичного сервера. Дистанция синхронизации определяется выражением

   LAMBDA = EPSILON + DELTA / 2

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

Пример программы обновления часов представлен в Приложении A.5.5.4.

11.3. Алгоритм дисциплины часов

Алгоритм дисциплины часов NTPv4, сокращенно называемый дисциплиной, работает как комбинация двух достаточно различающихся систем обратной связи. В схеме фазовой автоподстройки частоты (phase-locked loop или PLL) периодически обновляется фаза с интервалами в несколько микросекунд для минимизации временной ошибки напрямую и ошибки частоты — опосредованно. В контуре автоподстройки частоты (frequency-locked loop или FLL) периодически обновляется частота с микросекундными интервалами для минимизации ошибки частоты напрямую и ошибки времени — опосредованно. Как показано в [ref7], PLL работает лучше при доминировании сетевых вариаций, а FLL — при доминировании дрейфа тактового генератора. В этом разделе описана работа NTPv4, подробное описание принципов устройства дано в [ref7] вместе с анализом производительности.

Дисциплина реализована как система управления с обратной связью (Рисунок 26). Переменная theta_r представляет смещение алгоритма комбинирования (опорная фаза), а theta_c — смещение VFO (фаза управления). Каждое обновление создаёт сигнал V_d, представляющий мгновенную разность фаз theta_r — theta_c. Фильтр часов для каждого сервера работает как линия задержки с ответвлениями, при этом вывод берётся с ответвления, выбранного алгоритмом фильтра часов. Алгоритмы выбора, кластера и комбинирования объединяют данные нескольких фильтров для создания сигнала V_s. Кольцевой фильтр с импульсным откликом F(t) создаёт сигнал V_c, управляющий частотой VFO omega_c и, таким образом, фазой theta_c, замыкая контур. Сигнал V_c генерируется процессом корректировки часов (раздел 12). Уравнения, реализующие эти функции, представлены в Приложениях A.5.5.6 и A.5.6.1.

    theta_r + +---------\        +----------------+
NTP --------->| Детектор \  V_d  |                | V_s
    theta_c - |   фазы    ------>|  Фильтр часов  |----+
    +-------->|          /       |                |    |
    |         +---------/        +----------------+    |
    |                                                  |
  -----                                                |
 /     \                                               |
 | VFO |                                               |
 \     /                                               |
  -----    .......................................     |
    ^      .         Кольцевой фильтр            .     |
    |      . +---------+   x  +-------------+    .     |
    | V_c  . |         |<-----|             |    .     |
    +------.-|Корректир|   y  |Предсказание |<---------+
           . |  часов  |<-----|фазы/частоты |    .
           . |         |      |             |    .
           . +---------+      +-------------+    .
           .......................................

Рисунок 26. Контуры обратной связи дисциплины часов.

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

На рисунке 27 приведены переменные и параметры, имена формул и краткие описания. Если явно не указано иное, для всех переменных предполагается префикс c. Переменные t, tc, state, hyster, count являются целочисленными, остальные — floating double. Назначение каждой переменной приведено ниже в описании алгоритма.

Рисунок 27. Переменные и параметры дисциплины часов.

Процесс прерывается незамедлительно, если смещение превышает порог PANICT (1000 сек). Программа смены состояния rstclock() представлена в Приложении A.5.5.7, а на рисунке 28 показаны используемые в ней функции смены состояний. В столбцах таблицы приведены имена состояний, условие и действие для случаев, кода смещение theta меньше порога ступени и больше этого порога, а также комментарии.

 NSET

 ->FREQ
 adjust time 

 ->FREQ
 step time 

 FSET

 ->SYNC
 adjust time 

 ->SYNC
 step time 

 SPIK

 ->SYNC
 adjust freq 
 adjust time 

 if < 900 s ->SPIK 
 else ->SYNC 
 step freq 
 step time 

 FREQ

 if < 900 s ->FREQ 
 else ->SYNC 
 step freq 
 adjust time 

 if < 900 s ->FREQ 
 else ->SYNC 
 step freq 
 adjust time 

 SYNC

 ->SYNC
 adjust freq 
 adjust time 

 if < 900 s ->SPIK 
 else ->SYNC 
 step freq 
 step time 

Рисунок 28. Функции смены состояния.

В таблице следующее состояние указывается стрелкой ->, а далее приведены действия. Такие операции как корректировка времени и частоты реализуются контуром обратной связи PLL/FLL в функции local_clock(). Операция «сдвига часов на шаг» (step clock) реализуется установкой часов напрямую, но это происходит лишь после порога порога WATCH (900 сек), когда смещение превышает порог шага STEPT (0,125 сек). Это позволяет избежать ненужных корректировок в случае перегрузки в сети.

Статистика вариаций (psi) и дрейфа (omega) рассчитывается с использованием экспоненциального среднего значения с весовым коэффициентом AVG. Показатель постоянной времени (tau) определяется сравнением psi с величиной текущего смещения theta. Если смещение больше PGATE (4), умноженного на вариации часов, счётчик гистерезиса hyster уменьшается на 2, а ином случае — увеличивается на 1. Если hyster увеличивается до верхнего предела LIMIT (30), tau увеличивается на 1, при снижении до нижнего предела -LIMIT (-30) значение tau уменьшается на 1. Обычно tau колеблется около MAXPOLL, но быстро снижается, если скачок температуры вызывает всплеск частоты.

12. Процесс корректировки часов

Фактический процесс корректировки часов выполняется с интервалом в 1 секунду для учёта корректировки частоты и фиксированного процента оставшегося смещения theta_r. По сути, theta_r представляет экспоненциальное затухание значения theta, создаваемого фильтром контура обратной связи при каждом обновлении. Параметр TC для удобства масштабирует постоянную времени в соответствии с интервалом опроса. Отметим, что дисперсия EPSILON растёт на величину PHI каждую секунду.

Процесс корректировки часов включает прерывание по таймеру, управляющее счётчиком секунд c.t. Отсчёт начинается с 0 при запуске службы и значение инкрементируется 1 раз в секунду. При каждом прерывании вызывается функция clock_adjust() для включения времени дисциплины часов и корректировки частоты, затем ассоциации сканируются, чтобы сравнить значение счётчика секунд с переменной состояния p.next, определённой в следующем параграфе. Если значение счётчика не меньше p.next, вызывается процесс опроса и рассчитывается следующее значение p.next.

Пример процесса корректировки часов содержится в функции clock_adjust() Приложения A.5.6.1.

13. Процесс опроса

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

13.1. Переменные процесса опроса

На рисунке 29 приведены имена, формулы и краткие описания переменных и параметров процесса опроса. Если явно не указано иное, для переменных предполагается суффикс p.

Рисунок 29. Переменные и параметры процесса опроса.

Переменные процесса опроса выделяются в структуре данных вместе с переменными процесса партнёра. Ниже приведены описания переменных, а параметры рассматриваются позднее.

hpoll

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

last

Целочисленное значение счётчика секунд с момент передачи последнего пакета.

next

Целое число секунд до момента передачи следующего пакета.

reach

8-битовый целочисленный регистр сдвига, совместно используемые процессами партнёра и опроса.

unreach

Целое число секунд, в течение которых сервер был недоступен.

13.2. Операции процесса опроса

Как описано выше, процесс корректировки часов вызывается 1 раз в секунду и сам вызывает процедуру опроса для каждой ассоциации. Если время отправки следующего опросного сообщения больше значения счётчика секунд, программа сразу же завершается. Симметричные (режимы 1, 2), клиентские (режим 3) и широковещательные серверный (режим 5) ассоциации регулярно отправляют пакеты. Широковещательные ассоциации клиентов (режим 6) запускают процедуру для обновления переменных reach и unreach, но не передают пакеты. Процесс опроса вызывает процесс передачи для отправки пакета. В случае burst > 0 ничего не делается, кроме вызова процедуры обновления опроса для установки интервала следующего опроса. В ином случае переменная reach сдвигается влево на 1 бит с установкой для правого бита значения 0. Если сервер не был слышен в течение трёх последних интервалов опроса, вызывается программа фильтра часов для увеличения дисперсии (Приложение A.5.7.3).

Если флаг BURST установлен, сервер доступен и имеется действительный источник синхронизации, клиент передаёт блок (burst) из BCOUNT (8) пакетов за каждый интервал опроса. Интервал между пакетами в блоке составляет 2 секунды. Это полезно для точного измерения вариаций с длинными интервалами опроса. Если флаг IBURST установлен и это первый пакет, переданный с момента недоступности сервера, клиент передаёт блок пакетов. Это полезно для быстрого сокращения дистанции синхронизации до значения ниже порога и синхронизации часов.

Если флаг P_MANY установлен в слове ассоциации p.flags, это ассоциация является клиентской многоадресной (manycast). Такая ассоциация передаёт клиентские пакеты по назначенному групповому адресу с интервалом MINPOLL, начиная работу с TTL = 1. Если к моменту следующего опроса активировано (mobilized) менее MINCLOCK серверов, значение TTL увеличивается на 1. Если значение достигло TTLMAX и не найдено MINCLOCK серверов, интервал опроса увеличивается до достижения BEACON, после чего процесс возобновляется с начала.

Функция poll() включает увеличение интервала опроса, если сервер становится недоступным. Если reach имеет ненулевое значение, сервер доступен и устанавливается unreach = 0, в ином случае значение unreach увеличивается на 1 для каждого опроса вплоть до UNREACH. После этого hpoll для каждого опроса увеличивается на 1, что удваивает интервал опроса, вплоть до значения MAXPOLL, определяемого функцией poll_update(). Когда сервер снова становится доступным, устанавливается unreach = 0, для hpoll устанавливается значение системной переменной tc и работа возобновляется в обычном режиме.

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

Переменная пакета <--     Переменная
x.leap            <--     s.leap
x.version         <--     s.version
x.mode            <--     s.mode
x.stratum         <--     s.stratum
x.poll            <--     s.poll
x.precision       <--     s.precision
x.rootdelay       <--     s.rootdelay
x.rootdisp        <--     s.rootdisp
x.refid           <--     s.refid
x.reftime         <--     s.reftime
x.org             <--     p.xmt
x.rec             <--     p.dst
x.xmt             <--     clock
x.keyid           <--     p.keyid
x.digest          <--     md5 digest

Рисунок 30. Заголовок xmit_packet.

Процедура обновления опроса вызывается при получении действительного пакета и сразу же после отправки опросного сообщения. В блочном (burst) режиме фиксируется интервал опроса 2 сек, в ином случае для показателя hpoll устанавливается меньшее из значений ppoll для последнего полученного пакета и hpoll из функции опроса, но не меньше MINPOLL и не больше MAXPOLL. Таким образом дисциплина часов может применяться излишне часто (oversampled) но не слишком редко. Это нужно для сохранения динамики подсети и защиты от ошибок протокола.

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

14. Простой протокол сетевого времени (SNTP)

Первичным серверам и клиентам, соответствующим подмножеству NTP, называемому простым протоколом сетевого времени (Simple Network Time Protocol или SNTPv4) [RFC4330], не требуется реализовать алгоритмы смягчения, описанные в разделе 9 и последующих разделах этого документа. Протокол SNTP предназначен для первичных серверов, оборудованных одними эталонными часами, и клиентов с одним восходящим сервером без зависимых клиентов. Полная реализация NTPv4 предназначена для вторичных серверов с несколькими восходящими серверами и множеством нисходящих серверов или клиентов. За исключением этого, серверы и клиенты NTP и SNTP полностью совместимы и могут перемешиваться в подсетях NTP.

Первичный сервер SNTP, реализующий протокол on-wire, описанный в разделе 8 , не имеет восходящих серверов за исключением одних эталонных часов. В принципе, он неотличим от первичного сервера NTP, имеющего алгоритмы смягчения и за счёт этого способного смягчать различия между несколькими эталонными часами.

При получении запроса от клиента первичный сервер SNTP создаёт и отправляет пакет отклика, показанный на рисунке 31. Отметим, что поле дисперсии в заголовке должно обновляться в соответствии с разделом 5.

Переменная пакета <--     Переменная
x.leap            <--     s.leap
x.version         <--     r.version
x.mode            <--     4
x.stratum         <--     s.stratum
x.poll            <--     r.poll
x.precision       <--     s.precision
x.rootdelay       <--     s.rootdelay
x.rootdisp        <--     s.rootdisp
x.refid           <--     s.refid
x.reftime         <--     s.reftime
x.org             <--     r.xmt
x.rec             <--     r.dst
x.xmt             <--     clock
x.keyid           <--     r.keyid
x.digest          <--     md5 digest

Рисунок 31. Заголовок fast_xmit.

Клиент SNTP, реализующий протокол on-wire, имеет 1 сервер и не имеет зависимых клиентов. Он может работать с любым подмножеством протокола NTP on-wire, а самый простой подход использует лишь метку времени передачи от сервера и игнорирует прочие поля. Однако добавочные сложности полной реализации протокола on-wire минимальны и такая реализация приветствуется.

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

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

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

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

1. Злоумышленник может перехватывать и архивировать пакеты и открытые значения, создаваемые и передаваемые через сеть.

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

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

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

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

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

2. В некоторых режимах работы серверу нереально сохранять переменные состояния для каждого клиента. Однако возможно создать их заново по прибытии пакета от этого клиента.

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

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

В отличие от модели безопасности Secure Shell (SSH), где клиент должен пройти безопасную аутентификацию на сервере, в NTP сервер должен пройти проверку подлинности у клиента. В SSH каждый адрес интерфейса можно связать со своим именем, возвращаемым запросом reverse-DNS. В этой схеме могут требоваться разные пары ключей «открытый-секретный» для каждого интерфейса со своим именем. Очевидным преимуществом такого подхода является возможность организации своего «отсека» безопасности для каждого интерфейса. Это позволяет межсетевому экрану, например, требовать аутентификацию клиента на одних интерфейсах, не требуя на других.

В случае NTP, как указано здесь, широковещательные клиенты NTP уязвимы из-за некорректного поведения или враждебности широковещательных серверов SNTP и NTP в сети Internet. Такая опасность может быть сведена к минимуму несколькими способами. Можно организовать фильтрацию, чтобы клиенты NTP получали доступ лишь к доверенным серверам NTP, что предотвратит попадание вредоносного трафика к клиентам NTP. Криптографическая аутентификация у клиента позволит применять при синхронизации часов лишь должным образом подписанные сообщения NTP. Более надёжную аутентификацию может обеспечить механизм Autokey [RFC5906].

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

Следует отметить, что эта спецификация описывает имеющуюся реализацию. Хотя недостатки защиты алгоритма MD5 хорошо известны, его применение в спецификации NTP согласуется с широким применением в сообществе Internet.

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

Порт UDP/TCP 123 был ранее выделен IANA для этого протокола. Агентство IANA выделило групповой адрес IPv4 224.0.1.1 и групповой адрес IPv6, заканчивающийся на :101 для протокола NTP. Этот документ добавляет поля расширения NTP, позволяющие разработку будущих расширений протокола, где конкретное расширение задаётся субполем Field Type в поле расширения. Агенство IANA создало и поддерживает реестр для типов полей расширения (Extension Field Types), связанных с этим протоколом, который исходно пуст. По мере необходимости у будущем могут определяться новые типы полей расширения, регистрируемые по процедуре IETF Review [RFC5226].

Агентство IANA создало новый реестр для кодов идентификации эталогов NTP (NTP Reference Identifier codes), включающий значения, заданные в параграфе 7.3. Новые коды могут добавляться по процедуре First-Come-First-Serve (FCFS). Формат реестра показан ниже.

Рисунок 32. Коды идентификации эталонных источников.

Агентство IANA создало новый реестр для кодов NTP Kiss-o’-Death. Реестр включает коды, заданные в параграфе 7.4, и может расширяться по процедуре FCFS. Формат реестра показан ниже.

Рисунок 33. Коды Kiss.

Для идентификаторов эталонов и кодов Kiss-o’-Death, начинающихся с символа X (эксперименты и разработка) запрашивать IANA не требуется.

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

Авторы благодарны Karen O’Donoghue, Brian Haberman, Greg Dowd, Mark Elliot, Harlan Stenn, Yaakov Stein, Stewart Bryant, Danny Mayer за технические рецензии и текстовый вклад в этот документ.

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

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

[RFC0768] Postel, J., «User Datagram Protocol», STD 6, RFC 768, August 1980.

[RFC0791] Postel, J., «Internet Protocol», STD 5, RFC 791, September 1981.

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

[RFC1321] Rivest, R., «The MD5 Message-Digest Algorithm», RFC 1321, April 1992.

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

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

[CGPM] Bureau International des Poids et Mesures, «Comptes Rendus de la 15e CGPM», 1976.

[ITU-R_TF.460] International Telecommunications Union, «ITU-R TF.460 Standard-frequency and time-signal emissions», February 2002.

[RFC1305] Mills, D., «Network Time Protocol (Version 3) Specification, Implementation and Analysis», RFC 1305, March 1992.

[RFC1345] Simonsen, K., «Character Mnemonics and Character Sets», RFC 1345, June 1992.

[RFC4330] Mills, D., «Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI», RFC 4330, January 2006.

[RFC5226] Narten, T. and H. Alvestrand, «Guidelines for Writing an IANA Considerations Section in RFCs», BCP 26, RFC 5226, May 2008.

[RFC5906] Haberman, B., Ed. and D. Mills, «Network Time Protocol Version 4: Autokey Specification», RFC 5906, June 2010.

[ref6] Marzullo and S. Owicki, «Maintaining the time in a distributed system», ACM Operating Systems Review 19, July 1985.

[ref7] Mills, D.L., «Computer Network Time Synchronization — the Network Time Protocol», CRC Press, 304 pp, 2006.

[ref9] Mills, D.L., Electrical and Computer Engineering Technical Report 06-6-1, NDSS, June 2006, «Network Time Protocol Version 4 Reference and Implementation Guide», 2006.

Приложение A. Скелет кода

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

Здесь включено большинство возможностей эталонной реализации, но нет предоставления эталонных часов и криптографии с открытым ключом (Autokey). Отсутствует фильтр huff-n’-puff filter, гистерезис anti-clockhop и процедуры мониторинга. Многие из значений, которые могут меняться в эталонной реализации, здесь предполагаются константами. Пакеты kiss-o’-death представлены минимально и без соответствующего кода.

Программа не обеспечивает компактности и скорости, она предназначена лишь для демонстрации алгоритмов с достаточной для понимания их работы точностью. Скелет кода состоит из 8 сегментов — сегмент заголовка, включаемый во все остальные сегменты, сегмент кода основной программы, интерфейсы с ядром, системой ввода-вывода и системными часами, а также процессы партнёра, системы, опроса и clock_adjust. Они представлены вместе с определениями и переменными, характерными для каждого процесса.

A.1. Глобальные определения

A.1.1. Определения, константы, параметры

#include <math.h>               /* избегать жалоб на sqrt() */
#include <sys/time.h>           /* для gettimeofday() и т. п. */
#include <stdlib.h>             /* для malloc() и т. п. */
#include <string.h>             /* для memset() */

/*
 * Типы данных
 *
 * Эта программа предполагает тип int размеров 32 бита и long - 64 бита.
 * В большинстве расчётов применяется естественный тип floating double.
 * Типы данных в некоторых полях заголовков требуют преобразования.
 * Некоторые поля заголовков делятся по октетам и представлены здесь
 * октетами.
 *
 * 64-битовый формат меток времени NTP, применяемый в расчётах меток,
 * является беззнаковым числом секунд слева от бита 32. Для этих значений
 * разрешена лишь операция вычитания, дающая значения со знаком и размером
 * 31 бит. Короткий формат 32-битовых меток NTP применяется при расчёте 
 * задержки и дисперсии. Значение целых секунд указывается слева от бита
 * 16. Для этих значений разрешено лишь сложение и умножение на константу.
 *
 * Адреса IPv4 задаются 32 битами, IPv6 - 128 битами. Поле дайджеста
 * сообщения содержит 128 битов результата расчёта MD5. Поля точности и
 * интервала опроса задаются двоичным логарифмом (log2) числа секунд.
 */
typedef unsigned long long tstamp;   /* Формат метки времени NTP */
typedef unsigned int tdist;     /* Короткий формат NTP */
typedef unsigned long ipaddr;   /* Адрес IPv4 или IPv6 */
typedef unsigned long digest;   /* Дайджест md5 */
typedef signed char s_char;     /* Точность или интервал опроса (log2) */

/*
 * Макросы преобразования меток времени
 */
#define FRIC        65536.                  /* 2^16 как double */
#define D2FP(r)     ((tdist)((r) * FRIC))   /* короткая метка NTP */
#define FP2D(r)     ((double)(r) / FRIC)

#define FRAC       4294967296.             /* 2^32 как double */
#define D2LFP(a)   ((tstamp)((a) * FRAC))  /* метка NTP */
#define LFP2D(a)   ((double)(a) / FRAC)
#define U2LFP(a)   (((unsigned long long) \
                       ((a).tv_sec + JAN_1970) << 32) + \
                       (unsigned long long) \
                       ((a).tv_usec / 1e6 * FRAC))

/*
 * Арифметические преобразования
 */
#define LOG2D(a)        ((a) < 0 ? 1. / (1L << -(a)) : \
                            1L << (a))          /* опрос и т. п. */
#define SQUARE(x)       ((x) * (x))19
#define SQRT(x)         (sqrt(x))

/*
 * Глобальные константы. Часть их может конвертироваться в переменные,
 * которые можно менять в конфигурации или рассчитывать «на лету».
 * Например, эталонная реализация рассчитывает PRECISION на лету и
 * обеспечивает настройку для определений, помеченных %.
 */
#define VERSION         4       /* номер версии */
#define MINDISP         .01     /* % минимальная дисперсия (s) */
#define MAXDISP         16      /* максимальная дисперсия (s) */
#define MAXDIST         1       /* % порог дистанции (s) */
#define NOSYNC          0x3     /* високосные секунды не синхронизированы */
#define MAXSTRAT        16      /* Максимальный номер слоя (бесконечность) */
#define MINPOLL         6       /* % минимальный интервал опроса (64 сек)*/
#define MAXPOLL         17      /* % максимальный интервал опроса (36,4 час) */
#define MINCLOCK        3       /* минимальное число оставшихся manycast */
#define MAXCLOCK        10      /* максимальное число кандидатов manycast */
#define TTLMAX          8       /* max ttl manycast */
#define BEACON          15      /* максимальный интервал между beacon */

#define PHI             15e-6   /* % допуск частоты (15 ppm) */
#define NSTAGE          8       /* ступени регистра часов */
#define NMAX            50      /* максимальное число партнёров */
#define NSANE           1       /* % минимальное пересечение оставшихся */
#define NMIN            3       /* % минимум оставшихся для кластера */

/*
 * Глобальные значения возврата
 */
#define TRUE            1       /* boolean true */
#define FALSE           0       /* boolean false */

/*
 * Коды возврата локального процесса часов
 */
#define IGNORE          0       /* игнорировать */
#define SLEW            1       /* настройка поправки */
#define STEP            2       /* настройка шага */
#define PANIC           3       /* паника - нет корректировки */

/*
 * Флаги системы
 */
#define S_FLAGS         0       /* любые системные флаги */
#define S_BCSTENAB      0x1     /* включение широковещательного клиента */

/*
 * Флаги партнёра 
 */
#define P_FLAGS         0       /* любые флаги партнёра */
#define P_EPHEM         0x01    /* ассоциация временна */
#define P_BURST         0x02    /* блоки (burst) разрешены */
#define P_IBURST        0x04    /* начальный блок разрешён */
#define P_NOTRUST       0x08    /* аутентифицированный доступ */
#define P_NOPEER        0x10    /* аутентифицированная активизация */
#define P_MANY          0x20    /* manycast-клиент */

/*
 * Коды проверки подлинности
 */
#define A_NONE          0       /* без аутентификации */
#define A_OK            1       /* успешная аутентификация */
#define A_ERROR         2       /* ошибка аутентификации */
#define A_CRYPTO        3       /* crypto-NAK */

/*
 * Коды состояния ассоциаций
 */
#define X_INIT          0       /* инициализация */
#define X_STALE         1       /* тайм-аут */
#define X_STEP          2       /* шаг времени */
#define X_ERROR         3       /* ошибка аутентификации */
#define X_CRYPTO        4       /* получено сообщение crypto-NAK */
#define X_NKEY          5       /* недоверенный ключ */

/*
 * Определения режимов протокола
 */
#define M_RSVD          0       /* резерв */
#define M_SACT          1       /* симметричный активный */
#define M_PASV          2       /* симметричный пассивный */
#define M_CLNT          3       /* клиент */
#define M_SERV          4       /* сервер */
#define M_BCST          5       /* широковещательный сервер */
#define M_BCLN          6       /* широковещательный клиент */

/*
 * Определения состояний часов
 */
#define NSET            0       /* часы не устанавливались */
#define FSET            1       /* частота установлена из файла */
#define SPIK            2       /* обнаружен всплеск (spike) */
#define FREQ            3       /* режим частоты */
#define SYNC            4       /* часы синхронизированы */

#define min(a, b)   ((a) < (b) ? (a) : (b))
#define max(a, b)   ((a) < (b) ? (b) : (a))

A.1.2. Структуры данных пакета

/*
 * Принимаемые и передаваемые пакеты могут включать необязательный код
 * MAC, состоящий из идентификатора ключа keyid и дайджеста сообщения
 * (mac в принимаемой структуре и dgst - в передаваемой). NTPv4 
 * поддерживает необязательные поля расширения между заголовком и MAC, 
 * но здесь это не описано.
 *
 * Приёмный пакет.
 *
 * Отметим, что метка времени dst не является частью самого пакета. Она
 * извлекается по прибытии и возвращается в приёмный буфер вместе с его
 * размером и данными. Некоторые из полей char сжимаются в заголовке, но
 * здесь это не рассматривается.
 */
struct r {
        ipaddr  srcaddr;        /* Адрес источника (удалённый) */
        ipaddr  dstaddr;        /* Адрес получателя (локальный) */
        char    version;        /* Номер версии */
        char    leap;           /* Индикатор високосных секунд */
        char    mode;           /* Режим */
        char    stratum;        /* Слой (stratum) */
        char    poll;           /* Интервал опроса */
        s_char  precision;      /* Точность */
        tdist   rootdelay;      /* Корневая задержка */
        tdist   rootdisp;       /* Корневая дисперсия */
        char    refid;          /* Идентификатор эталона */
        tstamp  reftime;        /* Время эталона */
        tstamp  org;            /* Метка времени источника */
        tstamp  rec;            /* Метка времени приёма */
        tstamp  xmt;            /* Метка времени передачи */
        int     keyid;          /* Идентификатор ключа */
        digest  mac;            /* Дайджест сообщения */
        tstamp  dst;            /* Метка времени получателя */
} r;

/*
 * Передаваемый пакет
 */
struct x {
        ipaddr  dstaddr;        /* Адрес источника (локальный) */
        ipaddr  srcaddr;        /* Адрес получателя (удалённый) */
        char    version;        /* Номер версии */
        char    leap;           /* Индикатор високосных секунд */
        char    mode;           /* Режим */
        char    stratum;        /* Слой (stratum) */
        char    poll;           /* Интервал опроса */
        s_char  precision;      /* Точность */
        tdist   rootdelay;      /* Корневая задержка */
        tdist   rootdisp;       /* Корневая дисперсия */
        char    refid;          /* Идентификатор эталона */
        tstamp  reftime;        /* Время эталона */
        tstamp  org;            /* Метка времени источника */
        tstamp  rec;            /* Метка времени приёма */
        tstamp  xmt;            /* Метка времени передачи */
        int     keyid;          /* Идентификатор ключа */
        digest  dgst;           /* Дайджест сообщения */
} x;

A.1.3. Структуры данных ассоциации

   /*
    * Структура ступени фильтра. Отметим, что t в этой и других структурах
    * указывает время процесса, а не реальное время. Время процесса 
    * увеличивается на 1 каждую секунду реального времени.
    */
   struct f {
           tstamp  t;              /* Время обновления */
           double  offset;         /* Смещение часов */
           double  delay;          /* Круговая задержка */
           double  disp;           /* Дисперсия */
   } f;

   /*
    * Структура ассоциации используемая процессами партнёра и опроса.
    */
   struct p {

           /*
            * Переменные, задаваемые в конфигурации.
            */
           ipaddr  srcaddr;        /* Адрес источника (удалённый) */
           ipaddr  dstaddr;        /* Адрес получателя (локальный) */
           char    version;        /* Номер версии */
           char    hmode;          /* Режим хоста */
           int     keyid;          /* Идентификатор ключа */
           int     flags;          /* Флаги опций */

           /*
            * Переменные, устанавливаемые принятым пакетом.
            */
           char    leap;           /* Индикатор високосных секунд */
           char    pmode;          /* Режим партнёра */
           char    stratum;        /* Слой (stratum) */
           char    ppoll;          /* Интервал опроса партнёра */
           double  rootdelay;      /* Корневая задержка */
           double  rootdisp;       /* Корневая дисперсия */
           char    refid;          /* Идентификатор эталона */
           tstamp  reftime;        /* Время эталона */
   #define begin_clear org         /* Начало чистой области */
           tstamp  org;            /* Метка времени источника */
           tstamp  rec;            /* Метка времени приёма */
           tstamp  xmt;            /* Метка времени передачи */

           /*
            * Расчётные данные
            */
           double  t;              /* Время обновления */
           struct f f[NSTAGE];     /* Фильтр часов */
           double  offset;         /* Смещение партнёра */
           double  delay;          /* Задержка партнёра */
           double  disp;           /* Дисперсия партнёра */
           double  jitter;         /* RMS для вариаций */

           /*
            * Переменные процесса опроса
            */
           char    hpoll;          /* Интервал опроса для хоста */
           int     burst;          /* Счётчик блоков (burst) */
           int     reach;          /* Регистр доступа */
           int     ttl;            /* ttl (manycast) */
   #define end_clear unreach       /* Конец чистой области */
           int     unreach;        /* Счётчик недоступности */
           int     outdate;        /* Время последнего опроса */
           int     nextdate;       /* Время следующего опроса */
   } p;

A.1.4. Структуры данных системы

   /*
    * Список, применяемый алгоритмом пересечения.
    */
   struct m {                      /* m применяется для Marzullo */
           struct p *p;            /* Указатель на структуру партнёра */
           int     type;           /* high +1, mid 0, low -1 */
           double  edge;           /* Граница интервала корректности */
   } m;

   /*
    * Список оставшихся, применяемый алгоритмом кластера.
    */
   struct v {
           struct p *p;            /* Указатель на структуру партнёра */
           double  metric;         /* Показатель сортировки */
   } v;

   /*
    * Системная структура
    */
   struct s {
           tstamp  t;              /* Время обновления */
           char    leap;           /* Индикатор високосных секунд */
           char    stratum;        /* Слой (stratum) */
           char    poll;           /* Интервал опроса */
           char    precision;      /* Точность */
           double  rootdelay;      /* Корневая задержка */
           double  rootdisp;       /* Корневая дисперсия */
           char    refid;          /* Идентификатор эталона */
           tstamp  reftime;        /* Время эталона */
           struct m m[NMAX];       /* Список кандидатов */
           struct v v[NMAX];       /* Список оставшихся */
           struct p *p;            /* Идентификатор ассоциации */
           double  offset;         /* Комбинированное смещение */
           double  jitter;         /* Комбинированные вариации */
           int     flags;          /* Флаги опций */
           int     n;              /* Число оставшихся */
   } s;

A.1.5. Структуры данных локальных часов

   /*
    * Структура локальных часов
    */
   struct c {
           tstamp  t;              /* Время обновления */
           int     state;          /* Текущее состояние*/
           double  offset;         /* Текущее смещение */
           double  last;           /* Предыдущее смещение*/
           int     count;          /* Счётчик качаний (jiggle) */
           double  freq;           /* Частота */
           double  jitter;         /* RMS для вариаций */
           double  wander;         /* RMS для дрейфа */
   } c;

A.1.6. Прототипы функций

  /*
   * Процесс партнёра 
   */
  void    receive(struct r *);    /* Приём пакета */
  void    packet(struct p *, struct r *); /* Обработка пакета */
  void    clock_filter(struct p *, double, double, double); /* Фильтр */
  double  root_dist(struct p *);  /* Расчёт корневой дистанции */
  int     fit(struct p *);        /* Определение пригодности сервера */
  void    clear(struct p *, int); /* Очистка ассоциации */
  int     access(struct r *);     /* Определение ограничений для доступа */

  /*
   * Системный процесс
   */
  int     main();                 /* Основная программа */
  void    clock_select();         /* Поиск лучших часов */
  void    clock_update(struct p *); /* Обновление системных часов */
  void    clock_combine();        /* Комбинирование смещений */

  /*
   * Процесс локальных часов
   */
  int     local_clock(struct p *, double); /* Дисциплина часов */
  void    rstclock(int, double, double); /* Смена состояния часов */

  /*
   * Процесс корректировки часов
   */
  void    clock_adjust();         /* Процесс 1-секундного таймера */

  /*
   * Процесс опроса
   */
  void    poll(struct p *);               /* Процесс опроса */
  void    poll_update(struct p *, int); /* Обновление интервала опроса */
  void    peer_xmit(struct p *);  /* Передача пакета */
  void    fast_xmit(struct r *, int, int); /* Передача пакета отклика */

  /*
   * Вспомогательные функции
   */
  digest  md5(int);               /* Создание дайджеста сообщения */
  struct p *mobilize(ipaddr, ipaddr, int, int, int, int); /* Активация */
  struct p *find_assoc(struct r *); /* Поиск в таблице ассоциаций */

  /*
   * Интерфейс с ядром
   */
  struct r *recv_packet();        /* Ожидание пакета */
  void    xmit_packet(struct x *); /* Передача пакета */
  void    step_time(double);      /* Шаг времени */
  void    adjust_time(double);    /* Корректировка (slew) времени */
  tstamp  get_time();             /* Считывание времени */

A.2. Основная программа и утилиты

/*
 * определения
 */
#define PRECISION       -18     /* Точность (log2 s)  */
#define IPADDR          0       /* Любой адрес IP */
#define MODE            0       /* Любой режим NTP */
#define KEYID           0       /* Любой идентификатор ключа */

/*
 * main() - основная программа
 */
int
main()
{
        struct p *p;            /* Указатель на структуру партнёра */
        struct r *r;            /* Указатель на принятый пакет */

        /*
         * Чтение опций команды и инициализация переменных системы. 
         * Эталонная реализация оценивает точность каждой машины, измеряя
         * приращение времени при считывании системных часов.
         */
        memset(&s, sizeof(s), 0);
        s.leap = NOSYNC;
        s.stratum = MAXSTRAT;
        s.poll = MINPOLL;
        s.precision = PRECISION;
        s.p = NULL;

        /*
         * Инициализация переменных локальных часов.
         */
        memset(&c, 0, sizeof(c));20
        if (/* файл частоты */ 0) {
                c.freq = /* freq */ 0;
                rstclock(FSET, 0, 0);
        } else {
                rstclock(NSET, 0, 0);
        }
        c.jitter = LOG2D(s.precision);

        /*
         * Чтение файла конфигурации и активация постоянных ассоциаций
         * с заданными адресами, версией, режимом, ключами и флагами.
         */
        while (/* активация настроенной ассоциации */ 0) {
                p = mobilize(IPADDR, IPADDR, VERSION, MODE, KEYID,
                    P_FLAGS);
        }

        /*
         * Запуск системного таймера, увеличивающегося 1 раз в секунду,
         * чтение прибывающих пакетов, создание меток приёма и вызов 
         * функции receive().
         */
        while (0) {
                r = recv_packet();
                r->dst = get_time();
                receive(r);
        }

        return(0);
}

/*
 * mobilize() - активация и инициализация ассоциации.
 */
struct p
*mobilize(
        ipaddr  srcaddr,        /* IP-адрес отправителя */
        ipaddr  dstaddr,        /* IP-адрес получателя */
        int     version,        /* Версия */
        int     mode,           /* Режим хоста */
        int     keyid,          /* Идентификатор ключа */
        int     flags           /* Флаги партнёра */
        )
{
        struct p *p;            /* Указатель на процесс партнёра */

        /*
         * Выделение и инициализация памяти для ассоциации.
         */
        p = malloc(sizeof(struct p));
        p->srcaddr = srcaddr;
        p->dstaddr = dstaddr;
        p->version = version;
        p->hmode = mode;
        p->keyid = keyid;
        p->hpoll = MINPOLL;
        clear(p, X_INIT);
        p->flags = flags;
        return (p);
}

/*
 * find_assoc() - найти соответствующую ассоциацию.
 */
struct p                        /* Указатель на структуру партнёра или NULL */
*find_assoc(
        struct r *r             /* Указатель на принятый пакет */
        )
{
        struct p *p;            /* Указатель на «фиктивную» (dummy) структуру партнёра */

        /*
         * Таблица поиска ассоциаций для сопоставления адреса и порта 
         * отправителя, а также режима.
         */
        while (/* все ассоциации */ 0) {
                if (r->srcaddr == p->srcaddr && r->mode == p->hmode)
                        return(p);
        }
        return (NULL);
}

/*
 * md5() - расчёт дайджеста сообщения.
 */
digest
md5(
       int     keyid           /* идентификатор ключа */
       )
{
       /*
        * Расчёт криптографического дайджеста сообщения с ключом. 
        * Идентификатор связывается с ключом в локальном кэше ключей. Ключ
        * помещается перед заголовком пакета и полями расширения, результат
        * хэшируется по алгоритму MD5, как указано в RFC 1321. Возвращается
        * код MAC, состоящий из 32-битового идентификатора ключа, 
        * объединённого (конкатенация) со 128-битовым дайджестом сообщения.
        */
       return (/* дайджест MD5 */ 0);
}

A.3. Интерфейс ввода-вывода ядра

   /*
    * Интерфейс с ядром для передачи и приёма пакетов, детали которого
    * зависят от операционной системы.
    *
    * recv_packet — получение пакета из сети.
    */
   struct r                        /* указатель на принятый пакет */
   *recv_packet() {
           return (/* принятый пакет r */ 0);
   }


   /*
    * xmit_packet — передача пакета в сеть.
    */
   void
   xmit_packet(
           struct x *x             /* указатель на передаваемый пакет */
           )
   {
           /* передача пакета x */
   }

A.4. Интерфейс системных часов ядра

/*
 * Утилиты системных часов
 *
 * Имеется 3 формата времени: native (Unix), NTP, floating double.
 * Функция get_time() возвращает время в формате NTP. Программы
 * Unix ожидают аргументов в виде структуры из двух 32-битовых слов
 * со знаком в секундах и микросекундах (timeval) или наносекундах
 * (timespec). Функции step_time() и adjust_time() ожидают аргументов
 * floating double со знаком. Упрощённый код здесь показан лишь для
 * иллюстрации и не проверялся.
 */
#define JAN_1970        2208988800UL /* 1970 - 1900 в секундах */

/*
 * get_time — чтение системного времени и преобразование в формат NTP.
 */
tstamp
get_time()
{
        struct timeval unix_time;

        /*
         * Функция вызывается в программе лишь дважды - один раз по
         * прибытии пакета из сети, другой - при включении в очередь на
         * передачу. Вызывает функцию ядра для времени суток (такую как
         * gettimeofday()) и преобразует значение в формат NTP.
         */
        gettimeofday(&unix_time, NULL);
        return (U2LFP(unix_time));
}

/*
 * step_time() - сдвиг системного времени на указанное смещение.
 */
void
step_time(
        double  offset          /* смещение часов */
        )
{
        struct timeval unix_time;
        tstamp  ntp_time;

        /*
         * Преобразование из формата double в native (со знаком) и
         * добавление к текущему времени. Отметим, что добавление 
         * происходит в естественном формате, чтобы избежать 
         * переполнения и потери точности.
         */
        gettimeofday(&unix_time, NULL);
        ntp_time = D2LFP(offset) + U2LFP(unix_time);
        unix_time.tv_sec = ntp_time >> 32;
        unix_time.tv_usec = (long)(((ntp_time - unix_time.tv_sec) <<
            32) / FRAC * 1e6);
        settimeofday(&unix_time, NULL);
}


/*
 * adjust_time() - сдвиг системных часов на указанное смещение.
 */
void
adjust_time(
        double  offset          /* смещение часов */
        )
{
        struct timeval unix_time;
        tstamp  ntp_time;

        /*
         * Преобразование из формата double в native (со знаком) и
         * добавление к текущему времени.
         */
        ntp_time = D2LFP(offset);
        unix_time.tv_sec = ntp_time >> 32;
        unix_time.tv_usec = (long)(((ntp_time - unix_time.tv_sec) <<
            32) / FRAC * 1e6);
        adjtime(&unix_time, NULL);
}

A.5. Партнёрский процесс

   /*
    * Пакет crypto-NAK включает заголовок NTP, за которым следует код MAC,
    * состоящий лишь из идентификатора ключа со значением 0. Это говорит 
    * получателю, что предыдущий запрос не был должным образом
    * аутентифицирован, но поля заголовка NTP корректны.
    *
    * Пакет kiss-o'-death содержит заголовок NTP с leap 0x3 (NOSYNC) и
    * stratum 16 (MAXSTRAT). Он говорит получателю, что произошло нечто
    * серьёзное, о чем говорит код kiss в поле refid. Другие поля
    * заголовка NTP могут быть некорректными.
    */
   /*
    * Параметры и константы процесса партнёра.
    */
   #define SGATE           3       /* spike gate (фильтр часов) */
   #define BDELAY          .004    /* широковещательная задержка (s) */

   /*
    * Dispatch codes
    */
   #define ERR             -1      /* Ошибка */
   #define DSCRD           0       /* Отбросить пакет */
   #define PROC            1       /* Обработать пакет */
   #define BCST            2       /* Широковещательный пакет */
   #define FXMIT           3       /* Пакет клиента */
   #define MANY            4       /* Пакет manycast */
   #define NEWPS           5       /* Новый симметричный пассивный клиент */
   #define NEWBC           6       /* Новый широковещательный клиент */

   /*
    * Матрица диспетчеризации
    *              active  passv  client server bcast */
   int table[7][5] = {
   /* nopeer  */   { NEWPS, DSCRD, FXMIT, MANY, NEWBC },
   /* active  */   { PROC,  PROC,  DSCRD, DSCRD, DSCRD },
   /* passv   */   { PROC,  ERR,   DSCRD, DSCRD, DSCRD },
   /* client  */   { DSCRD, DSCRD, DSCRD, PROC,  DSCRD },
   /* server  */   { DSCRD, DSCRD, DSCRD, DSCRD, DSCRD },
   /* bcast   */   { DSCRD, DSCRD, DSCRD, DSCRD, DSCRD },
   /* bclient */   { DSCRD, DSCRD, DSCRD, DSCRD, PROC}
   };

   /*
    * Прочие макросы
    *
    * Этот макрос определяет статус аутентификации. Значение x = 0 говорит
    * о  её необязательности, в иных случаях аутентификация требуется.
    */
   #define AUTH(x, y)      ((x) ? (y) == A_OK : (y) == A_OK || \
                               (y) == A_NONE)

   /*
    * Макросы для функции clear()
    */
   #define BEGIN_CLEAR(p)  ((char *)&((p)->begin_clear))
   #define END_CLEAR(p)    ((char *)&((p)->end_clear))
   #define LEN_CLEAR       (END_CLEAR((struct p *)0) - \
                               BEGIN_CLEAR((struct p *)0))

A.5.1. receive()

/*
 * receive() - приём пакета и декодирование режима.
 */
void
receive(
        struct r *r             /* Указатель на полученный пакет */
        )
{
        struct p *p;            /* Указатель на структуру партнёра */
        int     auth;           /* Код аутентификации */
        int     has_mac;        /* Размер MAC */
        int     synch;          /* Состояние синхронизации */

        /*
         * Проверяет списки контроля доступа, служащего для поддержки
         * списка разрешённых или запрещённых адресов IP. Могут быть
         * разные списки для аутентифицированных и неаутентифицированных
         * клиентов.
         */
        if (!access(r))
                return;                 /* Доступ отклонён */

        /*
         * Версия не должна быть в будущем. Проверка формата включает 
         * размера пакета, MAC и полей заголовка при их наличии.
         */
        if (r->version > VERSION /* или ошибка формата */)
                return;                 /* ошибка формата */

        /*
         * Условие аутентификации задаётся двумя параметрами на уровне
         * клиента
         * P_NOPEER     не активировать ассоциацию до аутентификации.
         * P_NOTRUST    не разрешать доступ  до аутентификации 
         *              (предполагает P_NOPEER).
         *
         * Выходные значения
         * A_NONE       пакет не включает MAC.
         * A_OK         пакет содержит MAC и аутентификация успешна.
         * A_ERROR      пакет имеет MAC, но проверка не прошла.
         * A_CRYPTO     crypto-NAK. MAC содержит лишь 4 октета.
         *
         * Примечание. Макрос AUTH (x, y) служит для фильтрации вывода. 
         * При x=0 приемлемыми результатами будут NONE и OK, при x=1 - OK.
         */

        has_mac = /* размер поля MAC */ 0;
        if (has_mac == 0) {
                auth = A_NONE;          /* не требуется */
        } else if (has_mac == 4) {
                auth = A_CRYPTO;       /* crypto-NAK */
        } else {
                if (r->mac != md5(r->keyid))
                        auth = A_ERROR; /* ошибка аутентификации */
                else
                        auth = A_OK;    /* проверка прошла */
        }

        /*
         * Поиск ассоциации и диспетчеризация кода. Если ассоциации не
         * найдено, предполагается p->hmode = NULL.
         */
        p = find_assoc(r);
        switch(table[(unsigned int)(p->hmode)][(unsigned int)(r->mode)])
        {

        /*
         * Пакет клиента без ассоциации. Передача отклика сервера без 
         * сохранения состояния.
         */
        case FXMIT:

                /*
                 * Для unicast-адреса получателя передача пакета сервера.
                 * При отказе аутентификации передача пакета crypto-NAK.
                 */

                /* Адрес получателя не групповой */21
                if (0) {
                        if (AUTH(p->flags & P_NOTRUST, auth))
                                fast_xmit(r, M_SERV, auth);
                        else if (auth == A_ERROR)
                                fast_xmit(r, M_SERV, A_CRYPTO);
                        return;         /* M_SERV packet sent */
                }

                /*
                 * Должно быть manycast. Отклик не передаётся, если нет
                 * синхронизации или stratum больше чем у manycast.
                 */
                if (s.leap == NOSYNC || s.stratum > r->stratum)
                        return;

                /*
                 * Отклик лишь при успешной аутентификации. Применяется
                 * адрес unicast, а не multicast.
                 */
                if (AUTH(p->flags & P_NOTRUST, auth))
                        fast_xmit(r, M_SERV, auth);
                return;

        /*
         * Новая временная ассоциация клиента manycast. Активизируется с
         * указанной в пакете версией. При отказе аутентификации пакет
         * игнорируется. Серверный пакет проверяется сравнением метки
         * r->org в пакете с меткой p->xmt в групповой клиентской 
         * ассоциации. При совпадении пакет сервера аутентичен.
         */

        case MANY:
                if (!AUTH(p->flags & (P_NOTRUST | P_NOPEER), auth))
                        return;         /* Ошибка аутентификации */

                p = mobilize(r->srcaddr, r->dstaddr, r->version, M_CLNT,
                    r->keyid, P_EPHEM);
                break;

       /*
        * Новая симметричная пассивная ассоциация.  Активизируется с
        * указанной в пакете версией. При отказе аутентификации передаётся 
        * пакет crypto-NAK. Если активация не разрешена, передаётся 
        * пакет симметричный активной ассоциации.
        */
        case NEWPS:
                if (!AUTH(p->flags & P_NOTRUST, auth)) {
                        if (auth == A_ERROR)
                                fast_xmit(r, M_SACT, A_CRYPTO);
                        return;         /* передача crypto-NAK */
                }
                if (!AUTH(p->flags & P_NOPEER, auth)) {
                        fast_xmit(r, M_SACT, auth);
                        return;         /* передача M_SACT */
                }
                p = mobilize(r->srcaddr, r->dstaddr, r->version, M_PASV,
                    r->keyid, P_EPHEM);
                break;

        /*
         * Новая широковещательная клиентская ассоциация. Активизируется с
         * указанной в пакете версией. При отказе аутентификации пакет
         * игнорируется. Отметим, что этот код не поддерживает начальный
         * блок передач (volley) в эталонной реализации.
         */
        case NEWBC:
                if (!AUTH(p->flags & (P_NOTRUST | P_NOPEER), auth))
                        return;         /* Ошибка аутентификации */

                if (!(s.flags & S_BCSTENAB))
                        return;         /* Широковещание не разрешено */

                p = mobilize(r->srcaddr, r->dstaddr, r->version, M_BCLN,
                    r->keyid, P_EPHEM);
                break;                  /* Обработка продолжается */

        /*
         * Обработка пакета (заглушка).
         */
        case PROC:
                break;                  /* Обработка продолжается */

        /*
         * Недействительная комбинация режимов. Это возникает лишь
         * для временных ассоциаций, поэтому корректно просто бросить.
         */
        case ERR:
                clear(p, X_ERROR);
                return;          /* Недействительная комбинация режимов */

        /*
         * Нет совпадения, пакет просто отбрасывается.
         */
        case DSCRD:
                return;                 /* Брошенный сирота */
        }

        /*
         * Далее выполняется строгое планирование проверки меток. Если
         * метка передачи имеет значение 0, сервер просто повреждён. 
         */
        if (r->xmt == 0)
                return;                 /* Недействительная метка */

        /*
         * Если метка дублирует предыдущую, пакет использован повторно.
         */
        if (r->xmt == p->xmt)
                return;                 /* Дубликат пакета */

        /*
         * Если это пакет широковещательного режима, проверка завершается.
         * Если метка источника 0, отправитель ещё не слышал нас. Иначе,
         * если метка не совпадает с меткой передачи, пакет фальшивый.
         */
        synch = TRUE;
        if (r->mode != M_BCST) {
                if (r->org == 0)
                        synch = FALSE;  /* Не синхронизировано */
                else if (r->org != p->xmt)
                        synch = FALSE;  /* фиктивный пакет */
        }

        /*
         * Обновление меток источника и получателя. Если нет
         * синхронизации или пакет фиктивный, доставка прерывается.
         */
        p->org = r->xmt;
        p->rec = r->dst;
        if (!synch)
                return;                 /* нет синхронизации */

        /*
         * Метка действительная и принятый пакет соответствует последнему
         * переданному. Пакет crypto-NAK может говорить о смене ключей
         * сервером. Ассоциация деактивируется до лучших времён.
         */
        if (auth == A_CRYPTO) {
                clear(p, X_CRYPTO);
                return;                 /* crypto-NAK */
        }

        /*
         * Если ассоциация аутентифицирована, key ID отличен от 0 и 
         * принятый должен аутентифицироваться. Это предназначено для
         * предотвращения атак bait-and-switch (заманить и подменить),
         * возможных в прежних версиях.
         */
        if (!AUTH(p->keyid || (p->flags & P_NOTRUST), auth))
                return;                 /* bad auth */

        /*
         * Сделано всё возможное для проверки меток времени и 
         * предотвращения возможности нарушить работу протокола или
         * внедрить фиктивные данные.
         */
        packet(p, r);
}

A.5.1.1. packet()

/*
 * packet() - обработка пакета и расчёт смещения, задержки и дисперсии.
 */
void
packet(
        struct p *p,            /* Указатель на структуру партнёра */
        struct r *r             /* Указатель на полученный пакет */
        )
{
        double  offset;         /* Смещение выборки */
        double  delay;          /* Задержка выборки */
        double  disp;           /* Дисперсия выборки */

        /*
         * Пакет действителен, рассматриваются остальные поля заголовка.
         * Отметим, что stratum 0 (не задано) отображается на MAXSTRAT
         * для упрощения сравнения слоёв и обеспечения естественного
         * интерфейса с драйверами радиочасов, работающими со stratum 0.
         */
        p->leap = r->leap;
        if (r->stratum == 0)
                p->stratum = MAXSTRAT;
        else
                p->stratum = r->stratum;
        p->pmode = r->mode;
        p->ppoll = r->poll;
        p->rootdelay = FP2D(r->rootdelay);
        p->rootdisp = FP2D(r->rootdisp);
        p->refid = r->refid;
        p->reftime = r->reftime;

        /*
         * Проверка синхронизации сервера с действительным слоем и того,
         * что время эталона не позднее времени передачи.
         */
        if (p->leap == NOSYNC || p->stratum >= MAXSTRAT)
                return;                 /* нет синхронизации */

        /*
         * Проверка пригодности корневой дистанции.22
         */
        if (p->rootdelay / 2 + p->rootdisp >= MAXDISP || p->reftime >
            r->xmt)
                return;                 /* Непригодные значения заголовка */

        poll_update(p, p->hpoll);
        p->reach |= 1;

        /*
         * Расчёт смещения, задержки и дисперсии и передача их фильтру
         * часов. Отметим подразумеваемую обработку. Разность первого
         * порядка определяется напрямую в 64-битовой арифметике и
         * результат преобразуется в floating double. Дальнейшая обработка
         * использует арифметику floating double с аппаратным округлением.
         * Это нужно для предотвращения переполнений и потери точности.
         *
         * Расчёт задержки является особым случаем. Если часы сервера и
         * клиента работают с разной скоростью, а сеть очень быстрая,
         * задержка может стать отрицательной. Для предотвращения проблем
         * задержка должна быть не меньше точности системы23.
         */
        if (p->pmode == M_BCST) {
                offset = LFP2D(r->xmt - r->dst);
                delay = BDELAY;
                disp = LOG2D(r->precision) + LOG2D(s.precision) + PHI *
                    2 * BDELAY;
        } else {
                offset = (LFP2D(r->rec - r->org) + LFP2D(r->xmt -
                    r->dst)) / 2;
                delay = max(LFP2D(r->dst - r->org) - LFP2D(r->xmt -
                    r->rec), LOG2D(s.precision));
                disp = LOG2D(r->precision) + LOG2D(s.precision) + PHI *
                    LFP2D(r->dst - r->org);
        }
        clock_filter(p, offset, delay, disp);
}

A.5.2. clock_filter()

/*
 * clock_filter(p, offset, delay, dispersion) — выбор лучшей из 8 последних 
 * выборок задержка/смещения.
 */
void
clock_filter(
        struct p *p,            /* Указатель на структуру партнёра */
        double  offset,         /* Смещение часов */
        double  delay,          /* Круговая задержка */
        double  disp            /* Дисперсия */
        )
{
        struct f f[NSTAGE];     /* Сортированный список */
        double  dtemp;
        int     i;

        /*
         * Фильтр часов включает 8 квартетов (offset, delay, dispersion,
         * time). Выполняется сдвиг на 1 квартет влево с отбрасыванием
         * левого квартета. При сдвиге каждого квартета дисперсия растёт 
         * поскольку обновляется последний фильтр. Одновременно каждый
         * квартет копируется во временный список, а потом offset, delay,
         * disp, time) помещается в пустую позицию справа.
         */
        for (i = 1; i < NSTAGE; i++) {
                p->f[i] = p->f[i - 1];
                p->f[i].disp += PHI * (c.t - p->t);
                f[i] = p->f[i];
        }
        p->f[0].t = c.t;
        p->f[0].offset = offset;
        p->f[0].delay = delay;
        p->f[0].disp = disp;
        f[0] = p->f[0];

        /*
         * Сортировка временного списка по росту f[].delay. Первая запись
         * сортированного списка указывает лучшую выборку, но может быть
         * старой.
         */
        dtemp = p->offset;
        p->offset = f[0].offset;
        p->delay = f[0].delay;
        for (i = 0; i < NSTAGE; i++) {
                p->disp += f[i].disp / (1 << (i + 1));24
                p->jitter += SQUARE(f[i].offset - f[0].offset);
        }
        p->jitter = max(SQRT(p->jitter), LOG2D(s.precision));

        /*
         * Применять выборку лишь один раз и никогда не применять выборку
         * старше последней, но сделанной до синхронизации.
         */
        if (f[0].t - p->t <= 0 && s.leap != NOSYNC)
                return;

        /*
         * Сравниваются разность последнего и текущего смещения с текущим
         * значением jitter). Если разность больше SGATE (3) и интервал с
         * момента получения последнего смещения меньше удвоенного
         * интервала опроса, всплеск отбрасывается. Иначе, если не в режиме
         * burst, выбираются истинные часы.
         */
        if (fabs(p->offset - dtemp) > SGATE * p->jitter && (f[0].t -
            p->t) < 2 * s.poll)
                return;

        p->t = f[0].t;
        if (p->burst == 0)
                clock_select();
        return;
}

/*
 * fit() - проверка пригодности ассоциации p для синхронизации.
 */
int
fit(
        struct p *p             /* Указатель на структуру партнёра */
        )
{
        /*
         * Ошибка stratum, если (1) сервер не был синхронизирован, 
         * (2) слой сервера недействителен.
         */
        if (p->leap == NOSYNC || p->stratum >= MAXSTRAT)
                return (FALSE);

        /*
         * Ошибка дистанции возникает, если корневая дистанция 
         * превышает порог плюс один интервал опроса.
         */
        if (root_dist(p) > MAXDIST + PHI * LOG2D(s.poll))
                return (FALSE);

        /*
         * Петля (ошибка), если удалённый партнёр синхронизирован с
         * локальным или с текущим партнёром системы. Отметим, что это
         * относится к IPv4, а для IPv6 применяется хэш MD5.
         */
        if (p->refid == p->dstaddr || p->refid == s.refid)
                return (FALSE);

        /*
         * Ошибка доступности возникает, если сервер недоступен.
         */
        if (p->reach == 0)
                return (FALSE);

        return (TRUE);
}

/*
 * clear() - повторная инициализация ассоциации, деактивация
 * временной ассоциации.
 */
void
clear(
        struct p *p,            /* Указатель на структуру партнёра */
        int     kiss            /* kiss-код */
        )
{
        int i;

        /*
         * Сначала возвращаются все ресурсы. Типовые ресурсы не указаны
         * здесь, но включают динамически созданные структуры для ключей,
         * сертификатов и т. п. Если ассоциация временная и нет  
         * повторной инициализации, просто возвращается память ассоциации.
         */
        /* Возврат ресурсов */
        if (s.p == p)
                s.p = NULL;
        if (kiss != X_INIT && (p->flags & P_EPHEM)) {
                free(p);
                return;
        }

        /*
         * Инициализация полей ассоциации для общего сброса.
         */
        memset(BEGIN_CLEAR(p), LEN_CLEAR, 0);
        p->leap = NOSYNC;
        p->stratum = MAXSTRAT;
        p->ppoll = MAXPOLL;
        p->hpoll = MINPOLL;
        p->disp = MAXDISP;
        p->jitter = LOG2D(s.precision);
        p->refid = kiss;
        for (i = 0; i < NSTAGE; i++)
                p->f[i].disp = MAXDISP;

        /*
         * Первый опрос делается случайным на случай одновременного
         * возникновения тысяч широковещательных клиентов после 
         * долгого отсутствия широковещательного сервера.
         */
        p->outdate = p->t = c.t;
        p->nextdate = p->outdate + (random() & ((1 << MINPOLL) - 1));
}

A.5.3. fast_xmit()

/*
 * fast_xmit() - передача отклика на принятый пакет r
 */
void
fast_xmit(
        struct r *r,            /* Указатель на полученный пакет */
        int     mode,           /* Режим ассоциации */
        int     auth            /* Код аутентификации */
        )
{
        struct x x;

        /*
         * Инициализация заголовка и метки времени передачи. Отметим, что
         * поле version копируется из принятого пакета для совместимости
         * с прежними версиями.
         */
        x.version = r->version;
        x.srcaddr = r->dstaddr;
        x.dstaddr = r->srcaddr;
        x.leap = s.leap;
        x.mode = mode;
        if (s.stratum == MAXSTRAT)
                x.stratum = 0;
        else
                x.stratum = s.stratum;
        x.poll = r->poll;
        x.precision = s.precision;
        x.rootdelay = D2FP(s.rootdelay);
        x.rootdisp = D2FP(s.rootdisp);
        x.refid = s.refid;
        x.reftime = s.reftime;
        x.org = r->xmt;
        x.rec = r->dst;
        x.xmt = get_time();

        /*
         * Если код аутентификации имеет значение A.NONE, включается лишь
         * заголовок, при A.CRYPTO передаётся crypto-NAK, для A.OK -
         * действительный код MAC. Используется key ID из принятого пакета
         * и ключ из локального кэша.
         */
        if (auth != A_NONE) {
                if (auth == A_CRYPTO) {
                        x.keyid = 0;
                } else {
                        x.keyid = r->keyid;
                        x.dgst = md5(x.keyid);
                }
        }
        xmit_packet(&x);
}

A.5.4. access()

 /*
  * access() - задаёт ограничения при доступе.
  */
 int
 access(
         struct r *r             /* Указатель на полученный пакет */
         )
 {
         /*
          * Список контроля доступа — это неупорядоченный набор кортежей
          * из адреса, маски и слова ограничения, содержащего определённые  
          * биты. В списке отыскивается первое совпадение по адресу
          * отправителя (r->srcaddr) и возвращаются заданные ограничения.
          */
         return (/* биты доступа */ 0);
 }

A.5.5. Системный процесс

A.5.5.1. clock_select()

/*
 * clock_select() - поиск лучших часов
 */
void
clock_select() {
       struct p *p, *osys;     /* Указатели на структуры партнёров */
       double  low, high;      /* Протяжённость интервалов корректности */
       int     allow, found, chime; /* Применяется алгоритмом пересечения */
       int     n, i, j;

        /*
         * Сначала исключаются из набора серверов ложные часы и остаются
         * лишь истинные. Интервалом корректности для ассоциации p служит
         * интервал от offset - root_dist() до offset + root_dist(). 
         * Задача состоит в отборе кандидатов, т. е. поиске пересечения 
         * интервалов корректности числом более половины набора серверов.
         *
         * Сначала создаётся список триплетов (p, type, edge), как показано
         * ниже, затем список сортируется по росту edge.25
         */
        osys = s.p;
        s.p = NULL;
        n = 0;
        while (fit(p)) {
                s.m[n].p = p;
                s.m[n].type = +1;
                s.m[n].edge = p->offset + root_dist(p);
                n++;
                s.m[n].p = p;
                s.m[n].type = 0;
                s.m[n].edge = p->offset;
                n++;
                s.m[n].p = p;
                s.m[n].type = -1;
                s.m[n].edge = p->offset - root_dist(p);
                n++;
        }

        /*
         * Поиск наибольшего непрерывного пересечения интервалов 
         * корректности. Значение allow указывает число разрешённых 
         * ложных часов, found - число найденных midpoint. Отметим, что
         * значения edge ограничены диапазоном +-(2 ^ 30) < +-2e9 
         * расчётами меток времени.
         */
        low = 2e9; high = -2e9;
        for (allow = 0; 2 * allow < n; allow++) {

                /*
                 * Сканирование списка кандидатов от низшего в высшему
                 * для поиска низшей конечной точки.26
                 */
                found = 0;
                chime = 0;
                for (i = 0; i < n; i++) {
                        chime -= s.m[i].type;
                        if (chime >= n - allow) {
                                low = s.m[i].edge;
                                break;
                        }
                        if (s.m[i].type == 0)
                                found++;
                }

                /*
                 * Сканирование списка кандидатов от высшего к низшему 
                 * для поиска высшей конечной точки.
                 */
                chime = 0;
                for (i = n - 1; i >= 0; i--) {
                        chime += s.m[i].type;
                        if (chime >= n - allow) {
                                high = s.m[i].edge;
                                break;
                        }
                        if (s.m[i].type == 0)
                                found++;
                }

                /*
                 * Если число midpoint больше числа разрешённых ложных
                 * часов, пересечение включает хотя бы одни истинные часы
                 * без midpoint. В этом случае инкрементируется число
                 * разрешённых ложных часов и процесс повторяется. Если это
                 * не так и пересечение не пусто, заявляется успех.
                 */
                if (found > allow)
                        continue;

                if (high > low)
                        break;
        }

        /*
         * Алгоритм кластеризации, создающий список оставшихся пар (p,
         * metric) из списка кандидатов, где metric определяется первым
         * по stratum, затем по корневой дистанции. При прочих равных это
         * задаёт порядок предпочтения.
         */
        s.n = 0;
        for (i = 0; i < n; i++) {
                if (s.m[i].edge < low || s.m[i].edge > high)
                        continue;

                p = s.m[i].p;
                s.v[n].p = p;
                s.v[n].metric = MAXDIST * p->stratum + root_dist(p);
                s.n++;
        }

        /*
         * Для соблюдения утверждений о корректности должно остаться 
         * хотя бы NSANE кандидатов. Исходно византийский критерий 
         * требует 4 оставшихся, но для демонстрации достаточно 1.
         */
        if (s.n < NSANE)
                return;

        /*
         * Для каждой ассоциации p поочередно рассчитывается выбор
         * jitter p->sjitter как квадратного корня из суммы квадратов
         * (p->offset - q->offset) для всех q ассоциаций. Идея состоит в
         * повторяющемся отбрасывании оставшихся с максимальной вариацией, 
         * пока не будут выполнены условия завершения.
         */
        while (1) {
                struct p *p, *q, *qmax; /* Указатели на структуры партнёров */
                double  max, min, dtemp;

                max = -2e9; min = 2e9;
                for (i = 0; i < s.n; i++) {
                        p = s.v[i].p;
                        if (p->jitter < min)
                                min = p->jitter;
                        dtemp = 0;
                        for (j = 0; j < n; j++) {
                                q = s.v[j].p;
                                dtemp += SQUARE(p->offset - q->offset);
                        }
                        dtemp = SQRT(dtemp);
                        if (dtemp > max) {
                                max = dtemp;
                                qmax = q;
                        }
                }

                /*
                 * Если максимальная вариация выбора меньше минимальной
                 * вариации партнёра, дополнительное отбрасывание не 
                 * повысит минимальную вариацию партнёра, поэтому можно
                 * остановиться. Для уверенности в сохранении достаточного
                 * для алгоритма кластеризации числа оставшихся процесс
                 * завершается, если их число не превышает NMIN (3).
                 */
                if (max < min || n <= NMIN)
                        break;

                /*
                 * Удаление оставшегося с qmax и повтор процесса.
                 */
                s.n--;
        }

        /*
         * Выбор лучших часов. Если прежний партнёр системы имеется в
         * списке с тем же слоем, что и у первого в списке, часы не 
         * обновляются. Иначе выбирается первый оставшийся как новый
         * партнёр системы.
         */
        if (osys->stratum == s.v[0].p->stratum)
                s.p = osys;
        else
                s.p = s.v[0].p;
        clock_update(s.p);
}

A.5.5.2. root_dist()

/*
 * root_dist() - расчёт корневой дистанции.
 */
double
root_dist(
        struct p *p             /* Указатель на структуру партнёра */
        )
{

        /*
         * Корневой дистанцией синхронизации служит максимальная ошибка
         * из-за всех причин локальных часов относительно первичного
         * сервера. Она определяется как половина суммы общей задержки,
         * общей дисперсии и вариации партнера.
         */
        return (max(MINDISP, p->rootdelay + p->delay) / 2 +
            p->rootdisp + p->disp + PHI * (c.t - p->t) + p->jitter);
}

A.5.5.3. accept()

/*
 * accept() - проверка пригодности ассоциации p для синхронизации.
 */
int
accept(
        struct p *p             /* Указатель на структуру партнёра */
        )
{
        /*
         * Ошибка stratum возникает, если (1) сервер не синхронизирован,
         * (2) слой сервера не действителен.
         */
        if (p->leap == NOSYNC || p->stratum >= MAXSTRAT)
                return (FALSE);

        /*
         * Ошибка дистанции возникает, если корневая дистанция 
         * превышает порог плюс один интервал опроса.
         */
        if (root_dist(p) > MAXDIST + PHI * LOG2D(s.poll))
                return (FALSE);

        /*
         * Петля (ошибка), если удалённый партнёр синхронизирован с
         * локальным или с текущим партнёром системы. Отметим, что это
         * относится к IPv4, а для IPv6 применяется хэш MD5.
         */
        if (p->refid == p->dstaddr || p->refid == s.refid)
                return (FALSE);

        /*
         * Ошибка доступности возникает, если сервер недоступен.
         */
        if (p->reach == 0)
                return (FALSE);

        return (TRUE);
}

A.5.5.4. clock_update()

/*
 * clock_update() - обновление системных часов.
 */
void
clock_update(
        struct p *p             /* Указатель на структуру партнёра */
        )
{
        double dtemp;

        /*
         * Старое обновление, например, в результате смены партнёра системы
         * не выполняется. Старые и совпадающие выборки не применяются.
         */
        if (s.t >= p->t)
                return;

        /*
         * Объединение оставшихся смещения и обновление системных часов,
         * функция local_clock() будет указывать результат.
         */
        s.t = p->t;
        clock_combine();
        switch (local_clock(p, s.offset)) {

        /*
         * Смещение слишком велико и может быть фиктивным. Это вносится в
         * журнал системы и оператор оповещается для установки часов 
         * вручную в диапазоне PANIC. Эталонная реализация включает опции
         * команды для отключения этой проверки и смены порога паники,
         * принятого по умолчанию (1000 секунд).
         */
        case PANIC:
                exit (0);

        /*
         * Смещение больше шага ступени (0,125 сек по умолчанию). После 
         * применения шага все ассоциации будут иметь несогласованные 
         * значения времени, поэтому они сбрасываются и запускаются снова.
         * Порог шага можно изменить в эталонной реализации для снижения
         * вероятности того, что часы могут быть переведены обратно.
         * Однако возможны серьёзные последствия, как отмечено в 
         * публикации на сайте проекта NTP.
         */
        case STEP:
                while (/* all associations */ 0)
                        clear(p, X_STEP);
                s.stratum = MAXSTRAT;
                s.poll = MINPOLL;
                break;

        /*
         * Смещение меньше порога шага, что является обычным делом. 
         * Системные переменные обновляются по переменным партнёра. 
         * Нижний предел роста дисперсии служит для предотвращения
         * петель и скачков часов при вступлении в игру прецизионных
         * источников. Предел можно сменить с принятого по умолчанию 
         * значения 0,01 сек в эталонной реализации.
         */
        case SLEW:
                s.leap = p->leap;
                s.stratum = p->stratum + 1;
                s.refid = p->refid;
                s.reftime = p->reftime;
                s.rootdelay = p->rootdelay + p->delay;
                dtemp = SQRT(SQUARE(p->jitter) + SQUARE(s.jitter));
                dtemp += max(p->disp + PHI * (c.t - p->t) +
                    fabs(p->offset), MINDISP);
                s.rootdisp = p->rootdisp + dtemp;
                break;

        /*
         * некоторые выборки отбрасываются, хотя, например, прямое
         * измерение частоты происходит.
         */
        case IGNORE:
                break;
        }
}

A.5.5.5. clock_combine()

/*
 * clock_combine() - объединение смещений.
 */
void
clock_combine()
{
        struct p *p;            /* Указатель на структуру партнёра */
        double x, y, z, w;
        int     i;

        /*
         * Объединение смещений, оставшихся после алгоритма кластеризации,
         * с использованием взвешенного среднего по весу, определяемому
         * корневой дистанцией. Расчёт вариаций выбора как взвешенная RMS
         * разница между первым и остальными кандидатами. В некоторых
         * случаях наследуемые вариации часов можно снизить, отказавшись от
         * этого алгоритма, особенно при частом переводе часов. Эталонную
         * реализацию можно настроить на отказ от этого алгоритма указанием
         * предпочтительного партнёра. 
         */
        y = z = w = 0;
        for (i = 0; s.v[i].p != NULL; i++) {
                p = s.v[i].p;
                x = root_dist(p);
                y += 1 / x;
                z += p->offset / x;
                w += SQUARE(p->offset - s.v[0].p->offset) / x;
        }
        s.offset = z / y;
        s.jitter = SQRT(w / y);
}

A.5.5.6. local_clock()

/*
 * Параметры и константы дисциплины часов.
 */
#define STEPT           .128    /* Порог шага (s) */
#define WATCH           900     /* Порог ступени (stepout) (s) */
#define PANICT          1000    /* Порог паники (s) */
#define PLL             65536   /* Усиление контура PLL */
#define FLL             MAXPOLL + 1 /* Усиление контура FLL */
#define AVG             4       /* Константа усреднения параметров */
#define ALLAN           1500    /* Компрометация перехвата Allan (s) */
#define LIMIT           30      /* Порог корректировки опроса */
#define MAXFREQ         500e-6  /* Допуск частоты (500 ppm) */
#define PGATE           4       /* Диапазон корректировки опроса */

/*
 * local_clock() - дисциплина локальных часов.
 */
int                             /* код завершения */
local_clock(
        struct p *p,            /* Указатель на структуру партнёра */
        double  offset          /* Смещение часов из combine() */
        )
{
        int     state;          /* Статус дисциплины часов */
        double  freq;           /* Частота */
        double  mu;             /* Интервал с последнего обновления */
        int     rval;
        double  etemp, dtemp;

        /*
         * Отказ и возврат при слишком большом смещении.
         */
        if (fabs(offset) > PANICT)
                return (PANIC);

        /*
         * Функция смены состояния конечного автомата. Именно здесь 
         * выполняется действие и определяется реакция системы на 
         * слишком большие ошибки времени и частоты. Есть 2 основных
         * режима в зависимости от превышения порога шага (ступени).
         */
        rval = SLEW;
        mu = p->t - s.t;
        freq = 0;
        if (fabs(offset) > STEPT) {
                switch (c.state) {

                /*
                 * В состоянии S_SYNC игнорируется первый всплеск и статус
                 * меняется на S_SPIK.
                 */
                case SYNC:
                        state = SPIK;
                        return (rval);

                /*
                 * В состоянии S_FREQ игнорируются всплески и провалы. При
                 * первом всплеске после порога stepout рассчитывается 
                 * коррекция частоты и шаг времени.
                 */
                case FREQ:
                        if (mu < WATCH)
                                return (IGNORE);

                        freq = (offset - c.offset) / mu;
                        /* переход в S_SPIK */

                /*
                 * В состоянии S_SPIK игнорируются последующие всплески, 
                 * пока не будет найден выступ или превышен порог stepout.
                 */
                case SPIK:
                        if (mu < WATCH)
                                return (IGNORE);

                        /* Возврат к принятому по умолчанию */

                /*
                 * По умолчанию сюда попадают в состоянии S_NSET и S_FSET,
                 * в также сверху в состоянии S_FREQ. Применяется шаг 
                 * времени и снижается интервал опроса.
                 *
                 * В S_NSET исходная корректировка частоты недоступна
                 * обычно по причине того, что файл частоты ещё не записан.
                 * Поскольку время не попадает в диапазон захвата,
                 * применяется шаг часов. Частота устанавливается напрямую
                 * после интервала stepout.
                 *
                 * В S_FSET исходная корректировка частоты выполняется из
                 * файла. Поскольку время не попадает в диапазон захвата,
                 * часы переводятся незамедлительно, а не по истечении
                 * интервала stepout. Если первый перевод часов занимает
                 * 17 минут, люди начинают нервничать.
                 *
                 * В S_SPIK превышен порог stepout и фаза остаётся выше
                 * порога шага. Отметим, что один пик выше порога шага
                 * всегда подавляется даже при более длинных интервалах
                 * опроса.
                 */
                default:

                        /*
                         * Функция установки времени ядра обычно 
                         * через системный вызов Unix settimeofday().
                         */
                        step_time(offset);
                        c.count = 0;
                        s.poll = MINPOLL;
                        rval = STEP;
                        if (state == NSET) {
                                rstclock(FREQ, p->t, 0);
                                return (rval);
                        }
                        break;
                }
                rstclock(SYNC, p->t, 0);
        } else {

                /*
                 * Расчёт вариаций часов как RMS экспоненциально взвешенных
                 * разностей смещения. Применяется кодом настройки опроса.
                 */
                etemp = SQUARE(c.jitter);
                dtemp = SQUARE(max(fabs(offset - c.last),
                    LOG2D(s.precision)));
                c.jitter = SQRT(etemp + (dtemp - etemp) / AVG);
                switch (c.state) {

                /*
                 * В S_NSET это первое полученное обновление и частота ещё
                 * не инициализирована. Первым делом напрямую измеряется
                 * частота тактового генератора.
                 */
                case NSET:
                        rstclock(FREQ, p->t, offset);
                        return (IGNORE);

                /*
                 * В S_FSET это первое полученное обновление и частота ещё
                 * не инициализирована. Настраивается фаза, но частота не
                 * настраивается до следующего обновления.
                 */
                case FSET:
                        rstclock(SYNC, p->t, offset);
                        break;

                /*
                 * В S_FREQ обновления игнорируются до достижения порога
                 * stepout. После этого корректировка фазы и частоты с
                 * переходом в S_SYNC.
                 */
                case FREQ:
                        if (c.t - s.t < WATCH)
                                return (IGNORE);

                        freq = (offset - c.offset) / mu;
                        break;

                /*
                 * Сюдя по умолчанию попадают в состоянии S_SYNC и S_SPIK.
                 * Рассчитывается обновление частоты по данным PLL и FLL.
                 */
                default:

                        /*
                         * Константы FLL и PLL для изменения частоты 
                         * зависят от интервала опроса и перехвата Allan
                         * FLL не применяется ниже половины перехвата 
                         * Allan. Выше него усиление контура растёт с
                         * шагом 1 / AVG.
                         */
                        if (LOG2D(s.poll) > ALLAN / 2) {
                                etemp = FLL - s.poll;
                                if (etemp < AVG)
                                        etemp = AVG;
                                freq += (offset - c.offset) / (max(mu,
                                    ALLAN) * etemp);
                        }

                        /*
                         * Для PLL интервалом интеграции (numerator)  
                         * служит минимальное из значений интервалов
                         * обновления и опроса. Это разрешает более частые
                         * избыток выборок, но не их недостаток.
                         */
                        etemp = min(mu, LOG2D(s.poll));
                        dtemp = 4 * PLL * LOG2D(s.poll);
                        freq += offset * etemp / (dtemp * dtemp);
                        rstclock(SYNC, p->t, offset);
                        break;
                }
        }

        /*
         * Расчёт новой частоты и её стабильности (дрейф). Расчёт дрейфа
         * часов как RMS экспоненциально взвешенных разностей частот. Это
         * не применяется напрямую, но вместе с вариациями может быть очень
         * полезно для мониторинга и отладки.
         */
        freq += c.freq;
        c.freq = max(min(MAXFREQ, freq), -MAXFREQ);
        etemp = SQUARE(c.wander);
        dtemp = SQUARE(freq);
        c.wander = SQRT(etemp + (dtemp - etemp) / AVG);

        /*
         * Настраивается интервал опроса путём сравнения текущего смещения
         * с вариациями часов. Если смещение меньше, значения вариаций 
         * часов, умноженного на константу, средний интервал увеличивается,
         * иначе снижается. Небольшой гистерезис повысит стабильность.
         * лучше всего это работает в режиме burst.
         */
        if (fabs(c.offset) < PGATE * c.jitter) {
                c.count += s.poll;
                if (c.count > LIMIT) {
                        c.count = LIMIT;
                        if (s.poll < MAXPOLL) {
                                c.count = 0;
                                s.poll++;
                        }
                }
        } else {
                c.count -= s.poll << 1;
                if (c.count < -LIMIT) {
                        c.count = -LIMIT;
                        if (s.poll > MINPOLL) {
                                c.count = 0;
                                s.poll--;
                        }
                }
        }
        return (rval);
}

A.5.5.7. rstclock()

  /*
   * rstclock() - конечный автомат часов.
   */
  void
  rstclock(
          int     state,          /* Новое состояние */
          double  offset,         /* Новое смещение */
          double  t               /* Новое время обновления */
          )
  {
          /*
           * Переход в новое состояние и установка переменных состояния.
           * Отметим, что применяется время последней выборки фильтра 
           * часов, которое должно быть раньше текущего времени.
           */
          c.state = state;
          c.last = c.offset = offset;
          s.t = t;
  }

A.5.6. Процесс корректировки часов

A.5.6.1. clock_adjust()

 /*
  * clock_adjust() - запускается с интервалом в 1 секунду.
  */
 void
 clock_adjust() {
         double  dtemp;

         /*
          * Обновление времени процесса c.t и увеличение дисперсии с
          * момента последнего обновления. В отличие от NTPv3, NTPv4 не
          * заявляет отсутствие синхронизации по истечении суток, 
          * поскольку для этого служит порог дисперсии. Когда дисперсия
          * превышает MAXDIST (1 s), сервер считается неподходящим
          * для синхронизации.
          */
         c.t++;
         s.rootdisp += PHI;

         /*
          * Настройка фазы и частоты. Коэффициент усиления (denominator)
          * не разрешается увеличивать сверх перехвата Allan. Не имеет 
          * смысла усреднять фазовый шум за пределами этой точки и это
          * помогает демпфировать остаточное смещение при больших
          * интервалах опроса.
          */
         dtemp = c.offset / (PLL * min(LOG2D(s.poll), ALLAN));
         c.offset -= dtemp;

         /*
          * Функция корректировки времени ядра, обычно реализуемая 
          * системным вызовом Unix adjtime().
          */
         adjust_time(c.freq + dtemp);

         /*
          * Таймер партнёра, вызывающий функцию poll() по завершении.
          */
         while (/* all associations */ 0) {
                 struct p *p;/* Фиктивный указатель на структуру партнёра */

                 if (c.t >= p->nextdate)
                         poll(p);
         }

         /*
          * Один раз в час записывает частоту часов в файл.
          */
         /*
          * if (c.t % 3600 == 3599)
          *   запись c.freq в файл
          */
 }

A.5.7. Процесс опроса

   /*
    * Параметры и константы процесса опроса.
    */
   #define UNREACH         12      /* Порог счётчика недоступности */
   #define BCOUNT          8       /* Число пакетов в блоке (burst) */
   #define BTIME           2       /* Интервал между блоками (s) */

A.5.7.1. poll()

/*
 * poll() - определяет момент передачи пакета для ассоциации p
 */
void
poll(
        struct p *p     /* Указатель на структуру партнёра */
        )
{
        int     hpoll;
        int     oreach;

        /*
         * Эта функция вызывается, когда текущее время c.t догоняет время
         * следующего опроса p->nextdate. Значение p->outdate указывает
         * время последнего вызова функции. Время следующего выполнения 
         * p->nextdate задаёт функция poll_update().
         *
         * В широковещательном режиме просто вызывается функция, но
         * только при наличии синхронизации.
         */
        hpoll = p->hpoll;
        if (p->hmode == M_BCST) {
                p->outdate = c.t;
                if (s.p != NULL)
                        peer_xmit(p);
                poll_update(p, hpoll);
                return;
        }

        /*
         * Для manycast начинается с ttl = 1 и значение ttl увеличивается
         * на 1 для каждого опроса, пока не будет найдено MAXCLOCK серверов
         * или ttl не достигнет TTLMAX. При достижении MAXCLOCK опрос
         * прекращается, пока число серверов не упадёт ниже MINCLOCK, после
         * чего процесс повторяется.
         */
        if (p->hmode == M_CLNT && p->flags & P_MANY) {
                p->outdate = c.t;
                if (p->unreach > BEACON) {
                        p->unreach = 0;
                        p->ttl = 1;
                        peer_xmit(p);
                } else if (s.n < MINCLOCK) {
                        if (p->ttl < TTLMAX)
                                p->ttl++;
                        peer_xmit(p);
                }
                p->unreach++;
                poll_update(p, hpoll);
                return;
        }
        if (p->burst == 0) {

                /*
                 * Режим не burst. Регистр доступности сдвигается влево.
                 * Надеемся, что до следующего опроса поступит пакет и
                 * заполнится правый бит регистра.
                 */
                oreach = p->reach;
                p->outdate = c.t;
                p->reach = p->reach << 1;
                if (!(p->reach & 0x7))
                        clock_filter(p, 0, 0, MAXDISP);
                if (!p->reach) {

                        /*
                         * Сервер недоступен, поэтому увеличивается счётчик
                         * unreach. По достижении порога недоступности 
                         * интервал опроса удваивается для минимизации
                         * сетевого трафика. Блок пакетов (burst) 
                         * передаётся, если это разрешено и 
                         * достигнут порог недоступности.
                         */
                        if (p->flags & P_IBURST && p->unreach == 0) {
                                p->burst = BCOUNT;
                        } else if (p->unreach < UNREACH)
                                p->unreach++;
                        else
                                hpoll++;
                        p->unreach++;
                } else {

                        /*
                         * Сервер доступен. Для интервала опроса задаётся 
                         * значение системного интервала опроса. Блок
                         * (burst) передаётся , если это разрешено и 
                         * партнёр подходит.
                         */
                        p->unreach = 0;
                        hpoll = s.poll;
                        if (p->flags & P_BURST && fit(p))
                                p->burst = BCOUNT;
                }
        } else {

                /*
                 * В случае значение снижается. При получении отклика 
                 * функция clock_filter() вызывает clock_select() для
                 * обработки результатов передачи блока пакетов.
                 */
                p->burst--;
        }
        /*
         * Не передавать в режиме широковещательного клиента.
         */
        if (p->hmode != M_BCLN)
                peer_xmit(p);
        poll_update(p, hpoll);
}

A.5.7.2. poll_update()

/*
 * poll_update() - обновление интервала опроса для ассоциации p.
 *
 * Эту функцию вызывают packet() и poll(). Поскольку packet() вызывается
 * при получении пакета из сети, а poll() - по тайм-ауту, может возникать
 * «конфликт», который способен сделать некорректным следующий интервал
 * опроса. Такие ситуации считаются пренебрежимо редкими.
 */
void
poll_update(
        struct p *p,            /* Указатель на структуру партнёра */
        int     poll            /* Интервал опроса (log2 s) */
        )
{
        /*
         * Эту функцию вызывают poll() и packet() для определения времени
         * следующего опроса. В блочном (burst) режиме интервал опроса
         * составляет 2 секунды, в ином случае определяется меньшим из
         * значений интервалов опроса хоста и партнёра, но не более MAXPOLL
         * и не менее MINPOLL. Это позволяет заменить долгий интервал более
         * коротким, если требуется быстрый отклик.
         */
        p->hpoll = max(min(MAXPOLL, poll), MINPOLL);
        if (p->burst > 0) {
                if (p->nextdate != c.t)
                        return;
                else
                        p->nextdate += BTIME;
        } else {

                /*
                 * Хотя здесь это не показано, эталонная реализация вносит
                 * интервал опроса небольшой случайный фактор.
                 */
                p->nextdate = p->outdate + (1 << max(min(p->ppoll,
                    p->hpoll), MINPOLL));
        }

        /*
         * Может случиться так, что заданное время уже прошло. В этом
         * случае задаётся время на 1 секунду в будущее.
         */
        if (p->nextdate <= c.t)
                p->nextdate = c.t + 1;
}

A.5.7.3. peer_xmit()

/*
 * transmit() - передача пакета для ассоциации p
 */
void
peer_xmit(
        struct p *p             /* Указатель на структуру партнёра */
        )
{
        struct x x;             /* Передаваемый пакет */

        /*
         * Инициализация заголовка и метки времени передачи.
         */
        x.srcaddr = p->dstaddr;
        x.dstaddr = p->srcaddr;
        x.leap = s.leap;
        x.version = p->version;
        x.mode = p->hmode;
        if (s.stratum == MAXSTRAT)
                x.stratum = 0;
        else
                x.stratum = s.stratum;
        x.poll = p->hpoll;
        x.precision = s.precision;
        x.rootdelay = D2FP(s.rootdelay);
        x.rootdisp = D2FP(s.rootdisp);
        x.refid = s.refid;
        x.reftime = s.reftime;
        x.org = p->org;
        x.rec = p->rec;
        x.xmt = get_time();
        p->xmt = x.xmt;

        /*
         * Если идентификатор ключа отличен от 0, передаётся MAC с 
         * использованием key ID ассоциации и ключа из локального кэша. 
         * Если что-то пошло не так, например, нет доверенного ключа,
         * пакет не передаётся, а ассоциация сбрасывается и прекращает
         * работу до устранения проблем.
         */
        if (p->keyid)
                if (/* p->keyid invalid */ 0) {
                        clear(p, X_NKEY);
                        return;
                }
                x.dgst = md5(p->keyid);
        xmit_packet(&x);
}

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

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

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

nmalykh@protokols.ru

Internet Engineering Task Force (IETF)                      J. Arkko
Request for Comments: 5871                                  Ericsson
Updates: 2460                                             S. Bradner
Category: Standards Track                         Harvard University
ISSN: 2070-1721                                             May 2010

Рекомендации IANA по распределению значений IPv6 Routing Header

IANA Allocation Guidelines for the IPv6 Routing Header

PDF

Аннотация

В этом документе приведены рекомендации IANA для выделения новых значений поля Routing Type в заголовках расширения IPv6 Routing Header.

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

Этот документ относится к проектам стандартов Internet.

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

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

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

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

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

1. Введение

Этот документ содержит рекомендации для агентства IANA [RFC5226] по выделению новых значений для поля Routing Type в заголовке расширения IPv6 Routing [RFC2460]. Ранее рекомендаций для IANA по этому вопросы не существовало.

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

Новые значения Routing Type выделяются в соответствии с процедурой IETF Review³ или IESG Approval⁴ [RFC5226].

Отметим, что два экспериментальных значения (253 и 254) уже выделены для использования [RFC4727].

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

Данная спецификация не меняет связанных с безопасностью свойств заголовка Routing Header. Однако имеющийся опыт показывает возможность и простоту создания заголовков маршрутизации, которые могут создавать серьезные проблемы [RFC5095].

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

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

[RFC2460] Deering, S. and R. Hinden, «Internet Protocol, Version 6 (IPv6) Specification», RFC 2460, December 1998.

[RFC5226] Narten, T. and H. Alvestrand, «Guidelines for Writing an IANA Considerations Section in RFCs», BCP 26, RFC 5226, May 2008.

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

[RFC4727] Fenner, B., «Experimental Values In IPv4, IPv6, ICMPv4, ICMPv6, UDP, and TCP Headers», RFC 4727, November 2006.

[RFC5095] Abley, J., Savola, P., and G. Neville-Neil, «Deprecation of Type 0 Routing Headers in IPv6», RFC 5095, December 2007.

Приложение A. Изменения в RFC 2460

Этот документ только задает для IANA правила выделения значений для поля Routing Type.

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

Jari Arkko

Ericsson

Jorvas 02420

Finland

EMail: jari.arkko@piuha.net

Scott Bradner

Harvard University

Cambridge, MA 02138

US

Phone: +1 617 495 3864

EMail: sob@harvard.edu

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

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

nmalykh@gmail.com

Internet Engineering Task Force (IETF)                    E. Ertekin
Request for Comments: 5857                               C. Christou
Category: Standards Track                                  R. Jasani
ISSN: 2070-1721                                  Booz Allen Hamilton
                                                          T. Kivinen
                                                     AuthenTec, Inc.
                                                          C. Bormann
                                             Universitaet Bremen TZI
                                                            May 2010

Расширения IKEv2 для поддержки компрессии ROHC с IPsec

IKEv2 Extensions to Support Robust Header Compression over IPsec

PDF

Аннотация

Для интеграции ROHC¹ с Ipsec требуется сигнальный механизм для передачи параметров канала ROHC между конечными точками. Механизм IKE² подходит для решения этой задачи. В этом документе предложены расширения IKEv2, позволяющие передавать сигнализацию ROHC и канальные параметры для защищенных связей IPsec.

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

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

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

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

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

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

К этому документу применимы права и ограничения, перечисленные в 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. Введение

Увеличение размера заголовков в результате использования IPsec [IPSEC] может приводить к неэффективному использованию полосы каналов. Объединение модели ROHC [ROHC] с IPsec обеспечивает эффективный способ передачи защищенного трафика IP.

ROHCoIPsec [ROHCOIPSEC] требует инициализации конфигурационных параметров на компрессоре и декомпрессоре. В современных спецификациях для поэтапного (hop-by-hop) сжатия ROHC эти параметры согласуются с использованием протоколов канального уровня типа PPP⁵ (т. е. ROHC через PPP [ROHC-PPP]). Поскольку для динамического обмена параметрами между партнерами IPsec можно использовать протоколы обмена ключами (например, IKEv2 [IKEV2]), в этом документе определяются расширения IKEv2 для передачи параметров ROHC в ROHCoIPsec.

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

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

3. Инициализация канала ROHC для ROHCoIPsec

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

3.1. Сообщение ROHC_SUPPORTED Notify

Параметры канала ROHC должны передаваться раздельно для каждой поддерживающей ROHC связи IPsec SA. В частности, должен быть включен новый тип сообщений Notify в обмены IKE_AUTH и CREATE_CHILD_SA при каждой организации IPsec SA с поддержкой ROHC или смене ключей в существующих связях.

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

Отметим, что для переноса параметров ROHC используется только одно поле Notify. При получении множества Notify с параметрами ROHC все такие данные Notify, кроме первых, должны быть отброшены. Если инициатор не получил данных Notify с параметрами канала ROHC у ответчика, включать ROHC для Child SA недопустимо.

Новое значение Notify Message Type, обозначаемое ROHC_SUPPORTED, показывает, что данные Notify передают параметры канала ROHC (параграф 3.1.2⁶).

Формат данных Notify (определен в 4306 [IKEV2]) показан на рисунке 1.

                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ! Next Payload  !C!  RESERVED   !         Payload Length        !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   !  Protocol ID  !   SPI Size    !      Notify Message Type      !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   !                                                               !
   ~                Security Parameter Index (SPI)                 ~
   !                                                               !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   !                                                               !
   ~                       Notification Data                       ~
   !                                                               !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 1: Формат Notify Payload

Поля Notify Payload описаны ниже.

Next Payload (1 октет)

Идентификатор типа следующих данных в сообщении. Дополнительная информация в RFC 4306 [IKEV2].

Critical (1 бит)

Поскольку все реализации IKEv2 поддерживают данные Notify, это поле должно иметь значение 0.

Payload Length (2 октета)

В соответствии с определением RFC 4306 [IKEV2] это поле показывает размер данных (payload) вместе с их базовым заголовком.

Protocol ID (1 октет)

Поскольку эти сообщения используются в процессе создания Child SA, данное поле должно иметь значение 0.

SPI Size (1 октет)

Это поле должно иметь значение 0, поскольку применимых SPI нет (параметры ROHC задаются при создании SA, когда SPI не определены).

Notify Message Type (2 октета)

В это поле должно помещаться значение ROHC_SUPPORTED.

Security Parameter Index (SPI)

Поскольку поле SPI Size = 0, передавать данное поле недопустимо.

Notification Data (переменный размер)

В этом поле должно содержаться не менее трех атрибутов ROHC (см. параграф 3.1.1).

3.1.1. Атрибуты ROHC

Сообщение ROHC_SUPPORTED Notify используется для передачи канальных параметров между компрессором и декомпрессором ROHCoIPsec. Сообщение содержит список атрибутов ROHC, включающих параметры, требуемые для сеанса ROHCoIPsec.

Формат сигнальных атрибутов ROHC похож на формат атрибутов преобразования, описанных в параграфе 3.3.5 документа RFC 4306 [IKEV2]. Формат атрибута ROHC показан на рисунке 2.

                         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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    !A!     ROHC Attribute Type     !  AF=0  ROHC Attribute Length  !
    !F!                             !  AF=1  ROHC Attribute Value   !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    !                   AF=0  ROHC Attribute Value                  !
    !                   AF=1  Not Transmitted                       !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 2: Формат атрибута ROHC

• Attribute Format (AF) (1 бит) — если AF=0, атрибут ROHC представляется в формате TLV⁷. При AF=1 атрибут указывается в формате TV (тип/значение).
• ROHC Attribute Type (15 битов) — уникальный идентификатор для каждого типа атрибутов ROHC (см. параграф 3.1.2).
• ROHC Attribute Length (2 октета) — размер Attribute Value в октетах. Если AF=1, значение атрибута ROHC занимает 2 октета и поле ROHC Attribute Length отсутствует.
• ROHC Attribute Value (переменный размер) — значение атрибута ROHC, связанное с ROHC Attribute Type. Если AF=0, размер этого поля определяется значением поля ROHC Attribute Length. При AF=1 размер поля ROHC Attribute Value составляет 2 октета.

3.1.2. Типы атрибутов ROHC

В этом параграфе описаны типы атрибутов ROHC: MAX_CID, ROHC_PROFILE, ROHC_INTEG, ROHC_ICV_LEN и MRRU. Связанные с каждым из типов значения рассмотрены в разделе 5⁸.

MAX_CID (Максимальное значение идентификатора контекста, AF = 1)

Атрибут MAX_CID является обязательным и должен передаваться в единственном экземпляре. Поле MAX_CID указывает максимальное значение идентификатора контекста, поддерживаемое декомпрессором ROHCoIPsec. Значение атрибута имеет размер 2 октета и должно находиться в диапазоне от 0 до 16383, включительно. Поскольку идентификаторы CID могут принимать значения от 0 до MAX_CID, число контекстов, которые могут использоваться реально, составляет MAX_CID+1. Значение MAX_CID = 0 говорит о единственном контексте. Получатель атрибута MAX_CID должен использовать для компрессии только контексты, номера атрибутов для которых не превышают MAX_CID.

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

ROHC_PROFILE (профиль ROHC, AF = 1)

Атрибут ROHC_PROFILE является обязательным. Каждый атрибут ROHC_PROFILE имеет фиксированный размер в 4 октета, а значением атрибута является 2-октетный идентификатор профиля ROHC [ROHCPROF]. В сообщение ROHC_SUPPORTED Notify должен включаться по крайней мере один атрибут ROHC_PROFILE. При передаче множества атрибутов ROHC_PROFILE они могут размещаться в произвольном порядке. Получатель атрибутов ROHC_PROFILE должен использовать для компрессии только предложенные этими атрибутами профили.

Некоторые профили общего назначения определены в RFC 3095 [ROHCV1] и RFC 5225 [ROHCV2]. Следует отметить, что передавать в атрибутах две версии одного профиля недопустимо. Например, если декомпрессор ROHCoIPsec поддерживает ROHCv1 UDP (0x0002) и ROHCv2 UDP (0x0102), недопустимо указывать оба профиля. Это ограничение обусловлено тем, что пакеты, сжатые с использованием ROHC, содержат только 8 младших битов идентификатора профиля, а они совпадают для профилей ROHCv1 и ROHCv2, поэтому декомпрессор не сможет определить версию профиля, использованного для сжатия пакета.

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

ROHC_INTEG (Алгоритм контроля целостности для проверки заголовков после декомпрессии, AF = 1)

Атрибут ROHC_INTEG является обязательным и в каждом сообщении ROHC_SUPPORTED Notify должно указываться не менее одного атрибута ROHC_INTEG. Значение атрибута содержит идентификатор алгоритма контроля целостности, используемого для обеспечения целостности декомпрессированных пакетов (т. е., гарантии совпадения заголовка пакета после декомпрессии с заголовком исходного пакета до сжатия).

Алгоритмы аутентификации, которые должны поддерживаться, заданы в таблице «Алгоритмы аутентификации» параграфа 3.1.1 (Алгоритмы шифрования и аутентификации ESP) RFC 4835 [CRYPTO-ALG] (или его замены).

Алгоритм контроля целостности представляется 2-октетным значением, соответствующим значению из реестра параметров IKEv2 [IKEV2-PARA], раздел Transform Type 3 — Integrity Algorithm Transform IDs⁹. При получении атрибутов ROHC_INTEG ответчик должен выбрать единственный из предложенных алгоритмов и передать свой выбор в сообщении ROHC_SUPPORTED Notify, адресованном инициатору. Выбранный алгоритм контроля целостности должен использоваться для обоих направлений. Если ответчик не принимает ни одного из предложенных алгоритмов, включать ROHC для данной SA недопустимо.

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

1. Ключи (по одному для каждого направления) для алгоритма контроля целостности создаются из IKEv2 KEYMAT (см. [IKEV2], параграф 2.17). При создании ключей ROHC рассматривается, как протокол IPsec. При смене ключей для поддерживающей ROHC связи CHILD_SA меняются и ключи, связанные с этим алгоритмом контроля целостности.

2. Инициатор ROHCoIPsec может передать в атрибуте ROHC_INTEG нулевое значение (0x0000). Это соответствует значению NONE из реестра IKEv2 Integrity Algorithm Transform IDs. Ответчик ROHCoIPsec может выбрать это значение, отвечая инициатору атрибутом ROHC_INTEG = 0x0000. В этом случае для обоих направлений алгоритм контроля целостности не применяется.

3. ROHC_INTEG является параметром, согласуемым обеими сторонами. Иными словами, инициатор показывает поддерживаемые им алгоритмы, а ответчик выбирает одно из предложенных значений ROHC_INTEG и передает свой выбор инициатору.

ROHC_ICV_LEN (Размер алгоритма контроля целостности, AF = 1)

Атрибут ROHC_ICV_LEN относится к числу необязательных. В сообщения ROHC_SUPPORTED Notify может включаться множество атрибутов ROHC_ICV_LEN. Атрибут задает число октетов значения ICV¹⁰, которые отправитель сообщения ожидает получить во входящих пакетах ROHC. Значение ICV согласованного алгоритма ROHC_INTEG должно сокращаться до ROHC_ICV_LEN байтов, путем отбрасывания лишних октетов в конце. Инициатор и ответчик анонсируют свои значения размера ICV. Получатель атрибута ROHC_ICV_LEN должен уменьшить размер ICV до величины, указанной в сообщении. Если ROHC_ICV_LEN = 0, передача ICV недопустима. Если атрибут ROHC_ICV_LEN не был задан совсем или его значение превышает размер ICV для выбранного алгоритма, должно использоваться полное значение ICV соответствующего алгоритма ROHC_INTEG .

Отметим, что атрибут ROHC_ICV_LEN служит односторонним уведомлением и в каждом направлении может анонсироваться свое значение ROHC_ICV_LEN.

MRRU (Максимальный восстанавливаемый блок для приема, AF = 1)

Атрибут MRRU относится к числу необязательных. В сообщения ROHC_SUPPORTED Notify может включаться не более одного атрибута MRRU. Размер атрибута составляет 2 октета. Атрибут задает размер (в октетах) максимального блока, который декомпрессор ROHCoIPsec ожидает для восстановления из сегментов ROHC (см. параграф 5.2.5 [ROHCV1]). Этот размер включает поля контрольной суммы (CRC) и ROHC ICV. Если MRRU = 0 или значение MRRU не задано, сегменты заголовков недопустимо передавать в канал ROHCoIPsec.

Отметим, что атрибут MRRU служит односторонним уведомлением и в каждом направлении может анонсироваться свое значение MRRU.

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

3.2. Неявно устанавливаемые канальные параметры ROHC

Перечисленные ниже параметры каналов ROHC недопустимо передавать в сигнализации.

• LARGE_CIDS. Это значение неявно определяется значением MAX_CID (т. е., при MAX_CID <= 15, принимается LARGE_CIDS = 0).
• FEEDBACK_FOR. При создании пары SA (по одной для каждого направления) параметр FEEDBACK_FOR для канала ROHC должен неявно задаваться для другой SA в паре (т. е., SA в обратном направлении).

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

Возможность согласования размера ROHC ICV может создавать уязвимость для протокола ROHCoIPsec. В частности, возможность задать малый размер может приводить к ситуациям, когда в защищенный домен будут пересылаться ошибочные пакеты. Более детально эта проблема рассмотрена в параграфе 6.1.4 документа [ROHCOIPSEC] и в разделе 5 [IPSEC-ROHC].

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

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

В этом документе определено новое сообщение Notify (Status Type). Следовательно, агентство IANA выделило одно значение из реестра «IKEv2 Notify Message Types» для индикации поддержки ROHC (ROHC_SUPPORTED).

В дополнение к этому агентство IANA создало новый субреестр ROHC Attribute Types в рамках реестра Internet Key Exchange Version 2 (IKEv2) Parameters [IKEV2-PARA]. В реестре ROHC Attribute Types этот документ выделяет значения, перечисленные в таблице.

В соответствии с [IANA-CONSIDERATIONS] выделение IANA новых значений для типов атрибутов ROHC должно осуществляться после рецензии эксперта (Expert Review).

Для регистрационных запросов ответственный руководитель направления IESG (IESG Area Director) будет назначать эксперта (Designated Expert), который будет направлять запрос в списки рассылки ROHC и IPsec (или заменяющие их списки, указанные руководителем направления) для получения комментариев и рецензий. После этого назначенный эксперт будет принимать или отвергать запрос на регистрацию, направляя свое решение в оба списка рассылки и информируя IANA. Отказ от регистрации должен быть мотивирован.

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

Авторы благодарят Sean O’Keeffe, James Kohler, и Linda Noone из Министерства Обороны¹¹, а также Rich Espy из OPnet за их вклад и поддержку при разработке этого документа.

Авторы также благодарны Yoav Nir и Robert A Stangarone Jr., которые выступили рецензентами данной спецификации.

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

• Magnus Westerlund
• Stephen Kent
• Lars-Erik Jonsson
• Pasi Eronen
• Jonah Pezeshki
• Carl Knutsson
• Joseph Touch
• David Black
• Glen Zorn

В заключение авторы выражают свою признательность Tom Conkle, Michele Casey и Etzel Brower.

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

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

[IPSEC] Kent, S. and K. Seo, «Security Architecture for the Internet Protocol», RFC 4301, December 2005.

[ROHC] Sandlund, K., Pelletier, G., and L-E. Jonsson, «The RObust Header Compression (ROHC) Framework», RFC 5795, March 2010.

[IKEV2] Kaufman, C., «Internet Key Exchange (IKEv2) Protocol», RFC 4306, December 2005.

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

[ROHCV1] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T., Yoshimura, T., and H. Zheng, «Robust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed», RFC 3095, July 2001.

[ROHCV2] Pelletier, G. and K. Sandlund, «RObust Header Compression Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP and UDP-Lite», RFC 5225, April 2008.

[IPSEC-ROHC] Ertekin, E., Christou, C., and C. Bormann, «IPsec Extensions to Support Robust Header Compression over IPsec», RFC 5858, May 2010.

[IANA-CONSIDERATIONS] Narten, T. and H. Alvestrand, «Guidelines for Writing an IANA Considerations Section in RFCs», BCP 26, RFC 5226, May 2008.

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

[ROHCOIPSEC] Ertekin, E., Jasani, R., Christou, C., and C. Bormann, «Integration of Header Compression over IPsec Security Associations», RFC 5856, May 2010.

[ROHC-PPP] Bormann, C., «Robust Header Compression (ROHC) over PPP», RFC 3241, April 2002.

[ROHCPROF] IANA, «RObust Header Compression (ROHC) Profile Identifiers», <http://www.iana.org>.

[CRYPTO-ALG] Manral, V., «Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)», RFC 4835, April 2007.

[IKEV2-PARA] IANA, «Internet Key Exchange Version 2 (Kev2) Parameters», <http://www.iana.org>.

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

Emre Ertekin

Booz Allen Hamilton

5220 Pacific Concourse Drive, Suite 200

Los Angeles, CA 90045

US

EMail: ertekin_emre@bah.com

Chris Christou

Booz Allen Hamilton

13200 Woodland Park Dr.

Herndon, VA 20171

US

EMail: christou_chris@bah.com

Rohan Jasani

Booz Allen Hamilton

13200 Woodland Park Dr.

Herndon, VA 20171

US

EMail: ro@breakcheck.com

Tero Kivinen

AuthenTec, Inc.

Fredrikinkatu 47

HELSINKI

FI

EMail: kivinen@iki.fi

Carsten Bormann

Universitaet Bremen TZI

Postfach 330440

Bremen D-28334

Germany

EMail: cabo@tzi.org

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

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

nmalykh@gmail.com

Internet Engineering Task Force (IETF)                        J. Halpern
Request for Comments: 5812                                          Self
Category: Standards Track                                  J. Hadi Salim
ISSN: 2070-1721                                            Znyx Networks
                                                              March 2010

Модель элемента пересылки ForCES

Forwarding and Control Element Separation (ForCES) Forwarding Element Model

PDF

Аннотация

Этот документ определяет модель элемента пересылки (FE¹), используемую протоколом ForCES². Модель представляет возможности, состояние и конфигурацию элементов пересылки в контексте протокола ForCES так, что элементы управления CE³ могут должным образом управлять элементами FE. Более конкретно, модель описывает логические функции, присутствующие в FE, поддерживаемые этими функциями возможности и способы взаимодействия между функциями. Эта модель FE предназначена для выполнения требований, заданных в RFC 3654.

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

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

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

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

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

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

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

1. Введение

В RFC 3746 [RFC3746] задана схема, с помощью которой элементы управления CE могут настраивать и управлять одним или множеством раздельных элементов пересылки FE внутри элемента сети NE⁶ с помощью протокола ForCES. Архитектура ForCES позволяет элементам пересылки с различной функциональностью принимать участие в работе сетевого элемента ForCES. Вследствие различной функциональности элементы CE могут принимать лишь минимальные допущения о функциях FE в NE. До того, как CE смогут настраивать и контролировать поведение элементов пересылки FE, и требуется запросить и определить возможности и состояния своих FE. В RFC 3654 [RFC3654] указано, что эти характеристики, состояния и конфигурационные данные выражаются в форме модели FE.

В RFC 3444 [RFC3444] показано, что информационные модели (IM⁷) и модели данных (DM⁸) различаются целями. «Основной целью IM является моделирование управляемых объектов на концептуальном уровне независимо от конкретной реализации или используемого протокола». «DM, напротив, определяются на нижнем уровне абстракции и включают множество деталей. Они предназначены для разработчиков и включают зависимые от протокола конструкции». Иногда сложно провести четкую границу между этими моделями. Описанная в этом документе модель FE является прежде всего информационной моделью, но она также включает некоторые аспекты модели данных типа явных определений схемы класса логических функциональных блоков LFB⁹ и схемы FE. Предполагается, что эта модель FE будет служить для определения содержимого (payload) информационного обмена между CE и FE в протоколе ForCES.

1.1. Требования к модели FE

В RFC 3654 [RFC3654] приведены требования к модели ForCES FE, которые должна определять перечисленное ниже.

• Логически разделяемые и отчетливые операции пересылки пакетов в пути данных FE (логические функциональные блоки или LFB).

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

• Операционные возможности (например, пределы емкости, ограничения, операционные свойства, детализация настройки) каждого типа LFB.

• Возможные конфигурационные параметры (например, компоненты) каждого типа LFB.

• Метаданные, которые могут передаваться между LFB.

1.2. Модель FE и реализации FE

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

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

1.3. Модель FE и протокол ForCES

Базовый протокол ForCES [RFC5810] используется элементами CE и FE для поддержки коммуникационного канала между собой. Протокол ForCES может служить для запроса и раскрытия внутренней топологии FE. Детали конкретной реализации пути данных внутри FE, включая топологию LFB, а также возможности и атрибуты каждого LFB, передаются CE в информационных элементах протокола ForCES. Модели класса LFB следует определять всю информацию, требуемую для обмена между FE и CE с целью подходящей настройки и управления данным LFB.

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

В разделе 7 приведено более подробное рассмотрение способов использования модели FE протоколом ForCES.

1.4. Язык моделирования FE

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

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

Для этого документа в качестве языка спецификации был выбран XML, поскольку этот язык понятен человеку и удобен для машинного анализа, поддерживаемого множеством доступных инструментов. В этом документе применяется схема XML для определения структуры документов библиотеки LFB в соответствии с определениями [RFC3470], [Schema1] и [Schema2]. Хотя эти определения классов LFB не передаются в протоколе ForCES, они соответствуют рекомендациям RFC 3470 [RFC3470] по использованию XML в протоколах IETF.

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

1.5. Структура документа

В разделе 3 приведен концептуальный обзор модели FE, являющийся основой для более подробного рассмотрения и спецификации в последующих разделах. Разделы 4 и 5 описывают ядро модели FE, с подробным рассмотрением двух основных аспектов — общей модели LFB и определения FE Object LFB с компонентами, включая возможности FE и топологическую информацию LFB. Раздел 6 посвящен требованиям к модели в соответствии с приведенными в RFC 3654 [RFC3654] требованиями к протоколу ForCES, а в разделе 7 разъясняется как модель FE следует применять в протоколе ForCES.

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

Уровни требований (должно, следует, может, недопусимо) указываются в соответствии с RFC 2119 [RFC2119]. Эти уровни применяются при описании требуемого поведения элементов пересылки или управления ForCES для поддержки или манипуляций с описываемой в этой модели информацией.

Термины, связанные с требованиями к ForCES, определены в RFC 3654 [RFC3654] и не дублируются здесь. Набор терминов, относящихся к модели FE, приведен ниже.

FE Model — модель элемента пересылки

Модель, описывающая функции логической обработки в FE. Модель FE, предлагаемая в документе, включает три компоненты — модель отдельного логического функционального блока (модель LFB¹⁰), логическое соединение между LFB (топология LFB) и атрибуты уровня FE, включая возможности FE. Модель FE служит основой для определения информационных элементов, передаваемых между CE и FE в протоколе ForCES [RFC5810].

Data Path — путь (передачи) данных

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

LFB (Logical Functional Block) Class (или type)

Шаблон, представляющий небольшой, логически выделяемый аспект обработки FE. Большинство LFB относится к обработке пакетов в пути данных. Классы LFB являются базовыми элементами модели FE.

LFB Instance — экземпляр LFB

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

LFB Model — модель LFB

Модель LFB описывает содержимое и структуры LFB, а также дает определения связанных с блоком данных. Для формальных определений требуемых при моделировании структур используется язык XML. В модели LFB определены четыре типа информации. Ядром модели являются определения классов LFB, а три оставшихся типа определяют конструкции, связанные с определениями классов или используемые в них, — это типы данных многократного использования, поддерживаемые форматы кадров (пакетов) и метаданные.

Element — элемент

Термин «элемент» в документе применяется в соответствии с практикой XML и указывает на помеченную тегом XML часть документа XML. Точное определение можно найти в спецификациях XML от W3C. Термин включен в этот список для полноты, поскольку формальная модель ForCES использует XML.

Attribute — атрибут

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

LFB Meta Data — метаданные LFB

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

ForCES Component — компонента ForCES

Компонентой ForCES называют четко определенный, однозначно идентифицируемый и адресуемый блок модели ForCES. Компонента имеет 32-битовый идентификатор, имя, тип и необязательное описание, которые зачастую называют просто компонентами.

LFB Component — компонента LFB

Компонентами LFB являются компоненты ForCES, определяющие рабочие параметры LFB, которые должны быть видны CE.

Structure Component — компонента структуры

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

Property — свойство

Компоненты ForCES имеют связанные с ними свойства типа читабельности. Другим примером является длина компонент переменного размера. Эти свойства доступны CE для чтения, а в некоторых случаях и для записи. Подробное описание свойств ForCES приведено в параграфе 4.8.

LFB Topology — топология LFB

Представление логических связей между экземплярами LFB и их размещения в пути данных внутри одного элемента FE. Иногда используется термин «внутренняя топология FE», но не следует путать ее с топологией соединений между FE (inter-FE topology). Топология LFB не входит в модель LFB, но является частью модели FE.

FE Topology — топология FE

Представление соединений между множеством FE в одном NE. Иногда это называют внешней топологией FE, чтобы отличать от внутренней топологии FE (т. е. топологии LFB). Отдельный элемент FE может не иметь информации о всей топологии FE, но локальное представление его соединений с другими FE считается частью модели FE. Топология FE раскрывается базовым протоколом ForCES или иным способом.

Inter-FE Topology — внешняя топология FE

См. FE Topology.

Intra-FE Topology — внутренняя топология FE

См. LFB Topology.

LFB Class Library — библиотека классов LFB

Библиотека классов LFB представляет собой набор классов LFB, которые отмечены как наиболее общие функции в большинстве FE, и поэтому рабочей группе ForCES следовало определить их в первую очередь.

3. Концепции модели ForCES

В этом разделе вводятся некоторые важные концепции ForCES, которые используются на протяжении всего документа. К ним относятся абстракции возможностей и состояния, конструкция моделей FE и LFB, а также однозначная адресация различных структур модели. Детали этих аспектов рассмотрены в разделах 4 и 5. Назначение данного раздела состоит в обсуждении этих концепций на верхнем уровне и создание основы для подробного рассмотрения в следующих разделах.

Модель ForCES FE включает абстракции возможностей и состояния.

• Модель возможностей FE/LFB описывает «способности и емкость» FE/LFB путем задания вариаций, поддерживаемых функциями, и всех ограничений. «Емкость» описывает пределы конкретных компонент (например, предельный размер таблиц).

• Модель состояния описывает текущее состояние FE/LFB, т. е. мгновенные значения или рабочее поведение FE/LFB.

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

Конструкция модели ForCES описанная в этом документе, позволяет элементу FE предоставить информацию о своей структуре для работы. Ее можно рассматривать как информацию уровня FE и информацию об отдельных экземплярах LFB, обеспечиваемых FE.

• Модель ForCES включает конструкции для определения классов логических функциональных блоков (LFB), которые FE может поддерживать. Классы определены в этом и других документах. Определение такого класса обеспечивает информационное содержимое экземпляров класса LFB для мониторинга и управления в целях ForCES. Каждый класс модели LFB формально определяет операционные компоненты LFB, возможности и события LFB. В параграфе 3.2 представлена концепция LFB как базовых функциональных блоков для построения модели ForCES.

• Модель FE также предоставляет конструкции, требуемые для мониторинга и управления элементом FE в целом для протокола ForCES. Для согласованности операций и простоты эта информация представляется как LFB — класс FE Object LFB и одиночный экземпляр LFB данного класса, определенные с использованием модели LFB. Класс FE Object определяет компоненты для предоставления информации на уровне FE, в частности, возможности FE на грубом уровне, без их полного перечисления и детализации. Частью информации уровня FE является топология LFB, которая показывает логические соединения между экземплярами LFB на пути данных внутри элемента FE. Эта топология рассматривается в параграфе 3.3. FE Object также включает информацию о классах LFB, которые FE может поддерживать.

Модель ForCES позволяет однозначно указывать различные конструкции, которые она определяет. Это включает идентификацию классов LFB и экземпляров LFB внутри класса, а также идентификацию компонент экземпляра.

Протокол ForCES [RFC5810] инкапсулирует целевые адреса, чтобы получать доступ к объектам, указываемым CE. Иерархия адресации показана ниже.

• Элементы FE однозначно указываются 32-битовыми идентификаторами FEID.

• Каждый класс LFB имеет уникальный 32-битовый идентификатор LFB ClassID, который является глобальным для элемента сети и может быть выделенным IANA значением.

• Внутри FE может присутствовать множество экземпляров каждого класса LFB. Эти классы указываются 32-битовыми идентификаторами, уникальными в рамках отдельного класса LFB в данном FE.

• Для всех компонент экземпляра LFB используются свои 32-битовые идентификаторы.

Адресация более подробно рассматривается в параграфе 3.3.

3.1. Модели возможностей и состояний ForCES

Моделирование возможностей и состояний применимо к абстракциям FE и LFB.

На рисунке 1 показаны возможности, состояние и конфигурация FE в контексте коммуникаций CE-FE по протоколу ForCES.

+-------+                                          +-------+
|       | Возможности FE - что может и не может.   |       |
|       |<-----------------------------------------|       |
|       |                                          |       |
|   CE  | Состояние FE - что сейчас.               |  FE   |
|       |<-----------------------------------------|       |
|       |                                          |       |
|       | Конфигурация FE - чему следует быть.     |       |
|       |----------------------------------------->|       |
+-------+                                          +-------+

Рисунок 1. Обмен возможностями, состоянием и конфигурацией FE в контексте коммуникаций CE-FE по протоколу ForCES.

3.1.1. Модели возможностей и состояний FE

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

3.1.1.1. Модель возможностей FE

Модель возможностей FE может быть использована для описания FE без детализации. Например, FE можно определить следующим образом:

• FE может обслуживать пересылку IPv4 и IPv6;

• FE может выполнять классификацию на основе IP-адресов отправителя и получателя, портов отправителя и получателя и т.п.;

• FE может выполнять измерения;

• FE может обслуживать до N очередей (емкость);

• FE может добавлять и удалять заголовки инкапсуляции, включая IPsec, GRE, L2TP.

Хотя можно было попытаться построить объектную модель для полного представления возможностей FE, требуемые для реализации такого подхода усилия оказались слишком велики. Основная сложность связана с описанием подробных ограничений типа максимального числа классификаторов, очередей, буферных пулов и измерителей, которые FE может обеспечивать. Мы надеемся, что баланс между простотой и гибкостью может быть достигнут для модели FE путем объединения достаточно грубого описания возможностей с механизмом информирования об ошибках. Т. е. при попытке CE задать для элемента FE поведение, которое тот не способен реализовать, FE будет возвращать ошибку, указывающую проблему. Примерами такого подхода служат Diffserv PIB [RFC3317] и схема PIB [RFC3318].

3.1.1.2. Модель состояний FE

Модель состояний FE представляет мгновенное состояние FE для элемента CE. Например, с помощью модели состояния FE можно описать элемент FE соответствующему CE следующим образом:

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

• данный классификатор приводит к «измерению» и маркировке пакетов определенными способами;

• пакеты от конкретных маркировщиков доставляются в общую очередь для обработки, тогда как другие пакеты доставляются в иную очередь;

• конкретный планировщик с определенным поведением и параметрами будет обслуживать собранные очереди.

3.1.1.3. Модели возможностей и состояний LFB

Информация о возможностях и состоянии LFB формально определяется с использованием схемы XML.

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

Информация о состоянии формально определяется с использованием компонент LFB.

3.1.2. Связи между моделями возможностей и состояний LFB и FE

Информация о возможностях FE описывает классы LFB, которые FE может создавать, число экземпляров каждого класса, которые могут быть созданы, топологические ограничения (связность) для экземпляров LFB и т. п. В разделе 5 определены компоненты уровня FE, включающие информацию о возможностях. Поскольку вся информация представляется в виде LFB, это обеспечивается одним экземпляром класса FE Object LFB. Благодаря использованию известного класса LFB с известным идентификатором экземпляра, протокол ForCES обеспечивает элементам CE доступ к этой информации при возникновении потребности в ней в любой момент, включая организацию соединения между CE и FE.

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

3.2. Моделирование логического функционального блока (LFB)

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

Имеются также случаи, когда LFB могут применяться для обеспечения набора компонент управления работой FE со стороны CE (т. е., предназначены для управления), без связывания этого управления с конкретными пакетами или частями пути данных. Примером такого LFB является FE Object, который обеспечивает CE информацией о FE в целом, и позволяет CE¹¹ управлять некоторыми аспектами FE типа самого пути данных. Такие LFB не имеют ориентированных на пакеты свойств, описываемых в этом параграфе.

В общем случае FE включает множество LFB, как показано на рисунке 2, и все этил LFB используют общую точку завершения (интерфейс) протокола ForCES (Fp), которая реализует логику протокола ForCES и обеспечивает коммуникационный канал с элементом CE.

                     +-----------+
                     |    CE     |
                     +-----------+
                           ^
                           | Интерфейс (опорная точка) Fp
                           |
+--------------------------|-----------------------------------+
| FE                       |                                   |
|                          v                                   |
| +----------------------------------------------------------+ |
| |                Точка завершения                          | |
| |                   протокола ForCES                       | |
| +----------------------------------------------------------+ |
|           ^                            ^                     |
|           :                            : Внутренний контроль |
|           :                            :                     |
|       +---:----------+             +---:----------|          |
|       |   :LFB1      |             |   :     LFB2 |          |
| =====>|   v          |============>|   v          |======>...|
| Ввод  | +----------+ |Вывод        | +----------+ |          |
| (P,M) | |Компоненты| |(P',M')      | |Компоненты| |(P",M")   |
|       | +----------+ |             | +----------+ |          |
|       +--------------+             +--------------+          |
|                                                              |
+--------------------------------------------------------------+

Рисунок 2. Базовая диаграмма LFB.

LFB, как показано на рисунке 2, может иметь входы, выходы и компоненты, которые мугкт запрашиваться и управляться CE через интерфейс Fp (определен в RFC 3746 [RFC3746]), и точку завершения протокола ForCES. Горизонтальные стрелки на рисунке показывает уровень пересылки для соединения входов и выходов LFB внутри одного FE. P (с маркировкой изменений) показывает пакет данных, а M (с маркерами изменений) показывает связанные с пакетом метаданные. Вертикальная линия между CE и FE указывает опорную точку Fp где происходит двухсторонний обмен между CE и FE — от CE к FE передается конфигурация, управления и вставка пакетов, а от FE к CE происходит перенаправление пакетов на уровень управления, передаются данные мониторинга и учета, сообщения об ошибках и т. п. Отметим, что взаимодействие между CE и LFB является лишь абстрактным и опосредованным. Результатом такого взаимодействия являются манипуляции CE с компонентами экземпляров LFB.

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

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

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

Операция LFB задается в модели для того, что CE мог понимать поведение пересылки в пути данных. Например, CE нужно понимать, в какой точке пути данных FEбудет декрементироваться поле TTL заголовка IPv4. Т. е. CE нужно знать может ли пакет быть доставлен ему до или после данной точки в пути данных. Кроме того, CE нужно понимать где и какие изменения заголовков (например, добавление или исключение заголовка туннеля) могут выполняться элементами FE. CE проверяет совместимость между собой разных LFB на пути данных FE для предотвращения присутствия несовместимых экземпляров LFB, которые нарушать работу пути данных. Поэтому модель разработана с учетом предоставления CE требуемой информации.

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

Модель класса LFB среди прочей информации задает:

• число входов и выходов (а также возможность его настройки);

• метаданные, считываемые и потребляемые на входах;

• метаданные, создаваемые на выходах;

• типы пакетов, приемлемые на входах и передаваемые на выходах;

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

• критерии маршрутизации пакетов (при наличии в LFB множества выходов);

• временные изменения пакетов;

• изменение порядка в потоке пакетов

• компоненты информации о возможностях LFB;

• события, которые могут детектироваться LFB с передачей уведомлений CE;

• рабочие компоненты LFB.

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

3.2.1. Выход LFB

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

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

Некоторые LFB будут иметь один вывод, как показано на рисунке 3.a.

+---------------+               +-----------------+
|               |               |                 |
|               |               |             OUT +-->
...          OUT +-->           ...               |
|               |               |    EXCEPTIONOUT +-->
|               |               |                 |
+---------------+               +-----------------+
a. Один выход                   b. Два одиночных выхода

+---------------+               +-----------------+
|               |               |    EXCEPTIONOUT +-->
|         OUT:1 +-->            |                 |
...       OUT:2 +-->           ...          OUT:1 +-->
|         ...   +...            |           OUT:2 +-->
|         OUT:n +-->            |           ...   +...
+---------------+               |           OUT:n +-->
                                +-----------------+
c. Одна выходная группа         d. Один выход и одна 
                                   выходная группа

Рисунок 3. Примеры LFB с разными выходными комбинациями.

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

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

Например IPv4 LPM¹² LFB может иметь один выход (OUT) для отправки пакетов после успешного поиска LPM с передачей одновременно метаданных META_ROUTEID, а другой (EXCEPTIONOUT) для исключительных ситуаций, когда поиск LPM завершился отказом. Этот пример показан на рисунке 3.b. Пакеты на этих выходах не только требуют разных трактовок нисходящего направления, но и приводят к двум разным условиям в LFB и каждый выход передает свои метаданные. Эта концепция предполагает, что число выходов известно в момент определения LFB. Для каждого одиночного выходя определение класса LFB указывает типы передаваемых кадров (пакетов) и метаданные.

Выходная группа, с другой стороны, используется для моделирования случаев когда поток похожих пакетов с идентичным набором разрешенных метаданных расщепляется на несколько путей. В таком случае число путей не известно в момент определения класса LFB, поскольку оно не является неотъемлемым свойством класса. Выходная группа состоит из множества выходов, которые используют общие определения для передачи кадров (пакетов) и метаданных (см. рисунок 3.c). Каждый экземпляр выхода может быть соединен со своим нисходящим LFB, как это делается для одиночных выходов, но число экземпляров выходов может быть разным у разных экземпляров одного класса LFB. Определение класса может включать нижний и/или верхний предел числа выходов. Кроме того, для настраиваемых FE информация о возможностях FE может задавать свои пределы для числа экземпляров в конкретных выходных группах для определенных LFB. Реальное число выходов в группе является компонентой экземпляра LFB, которая доступна только для чтения в статической топологии и может быть изменена в динамической. Экземпляры выходов в группе нумеруются с 0 до N-1 и доступны по номерам в рамках LFB. Для использования групп выходных портов LFB имеет встроенный механизм выбора конкретного экземпляра выхода для каждого пакета. Этот механизм описывается в тестовом определении класса и обычно может быть настроен с помощью тех или иных атрибутов LFB.

В качестве примера рассмотрим LFB редиректора, единственной задачей которого является направлять пакеты в один из N нисходящих путей на основе метаданных, связанных с каждым прибывающим пакетом. Такой LFB достаточно универсален и может использоваться в разных точках топологии. Например, рассмотрим LFB, которые записывают типа пакета в метаданные FRAMETYPE или класс скорости для пакета в COLOR и эти метаданные могут использоваться для пересылки. Редиректор может служить для разделения путей IPv4 и IPv6 на основе FRAMETYPE (N=2) или для разделения путей по скорости на основе метаданных COLOR (red, yellow, green; N=3) и т. п..

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

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

Модель позволяет комбинировать выходную группу с одиночными выходами в одном классе, как показано на рисунке 3.d. Здесь LFB имеет два типа выходов — OUT для обычного вывода пакетов и EXCEPTIONOUT для пакетов, с которыми связаны исключительные ситуации. Обычный выход OUT имеет множество экземпляров, т. е. является выходной группой.

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

• Число нисходящих направлений наследуется из определения класса (фиксировано).

• Тип кадров и разрешенных для отправки метаданных любого из выходов отличается от аналогичных параметров других выходов (т. е. разные выходы не могут использоваться для однотипных пакетов и метаданных).

Выходная группа подходит в тех случаях, когда нужно ветвление и выполняется хотя бы одно из условий:

• число нисходящих направлений не было известно при определении класса LFB;

• тип кадров и набор метаданных для этих выходов достаточно похожи (в идеале одинаковы) и для них может применяться одно определение выхода.

3.2.2. Вход LFB

Вход LFB представляет собой концептуальный порт, через который данный LFB может принимать информацию от других LFB. Эта информация обычно состоит из пар «пакет-метаданные». Любая из компонент пары может отсутствовать, а отсутствие обеих означает просто отсутствие ввода.

Для экземпляров LFB, принимающих пакеты от множества других экземпляров LFB (fan-in), имеется три варианта моделирования fan-in, которые поддерживаются моделью и могут комбинироваться в одном LFB:

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

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

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

Простейший вариант мультиплексирования использует одиночный вход (рисунок 4.a). Большинство LFB имеют лишь один одиночный вход. Мультиплексирование в такой порт возможно за счет того, что модель позволяет подключать к одному входу множество выходов LFB. Это свойство применимо ко всем входам LFB без каких-либо особых требований к классу LFB. Мультиплексирование в один порт применимо, когда пакеты из восходящих LFB похожи по типам кадров и сопровождающим их метаданным и для них требуется похожая обработка. Отметим, что этот вариант не решает вопросов «конкуренции» между одновременно прибывающими пакетами. Если такая обработка требуется, следует воспользоваться одним из двух других вариантов мультиплексирования.

Во втором варианте используются отдельные одиночные порты (рисунок 4.b). Этот вариант подходит для ситуаций, когда LFB нужно обрабатывать разнотипные потоки пакетов, требующие определяемой входом обработки внутри LFB, и число разных входов известно в момент определения класса LFB. Например, LFB, способных выполнять декапсуляцию L2 (в L3) и инкапсуляцию L3 (в L2), может иметь два входа — один будет принимать кадры L2 для декапсуляции, а второй — L3 для инкапсуляции. Этот тип LFB ожидает разные кадры (L2 и L3) на своих входах, имеющие свои наборы метаданных, и будет применять к этим кадрам разную обработку. Эта модель может явно решать проблему «конкуренции» пакетов путем определения их обработки в классе LFB.

+--------------+       +------------------------+
| LFB X        +---+   |                        |
+--------------+   |   |                        |
                   |   |                        |
+--------------+   v   |                        |
| LFB Y        +---+-->|вход     Meter LFB      |
+--------------+   ^   |                        |
                   |   |                        |
+--------------+   |   |                        |
| LFB Z        |---+   |                        |
+--------------+       +------------------------+

(a) LFB соединен с множеством восходящих LFB через один вход.

+--------------+       +------------------------+
| LFB X        +---+   |                        |
+--------------+   +-->|layer2                  |
+--------------+       |                        |
| LFB Y        +------>|layer3     LFB          |
+--------------+       +------------------------+

(b) LFB соединен с множеством восходящих LFB через два раздельных входа.

+--------------+       +------------------------+
| Queue LFB #1 +---+   |                        |
+--------------+   |   |                        |
                   |   |                        |
+--------------+   +-->|in:0   \                |
| Queue LFB #2 +------>|in:1   | Входная группа |
+--------------+       |...    |                |
                   +-->|in:N-1 /                |
...                |   |                        |
+--------------+   |   |                        |
| Queue LFB #N |---+   |     Scheduler LFB      |
+--------------+       +------------------------+

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

Рисунок 4. Примеры LFB с разными комбинациями входов.

Треться модель мультиплексирования использует концепцию входной группы. Это похоже на описанную выше концепцию выходной группы и показано на рисунке 4.c. Входная группа включает множество входов с общими свойствами (ожидание однотипных кадров и метаданных). Экземпляры входов нумеруются от 0 до N-1. Извне эти входы выглядят обычными, т. е. совместимый восходящий LFB может подключить свой выход к одному из этих входов. Когда пакет представляется в LFB через конкретный экземпляр входа, индекс этого входа известен LFB и может использоваться при внутренней обработке. Например, индекс входа может служить селектором таблицы или явным селектором предпочтений при возникновении «конкуренции» Как и для выходных групп, число экземпляров входов не определяется классом LFB. Однако определение класса может включать ограничения на диапазон возможных значений. Кроме того, если FE поддерживает настройку топологии, это может вносить дополнительные ограничесние на число экземпляров входов для конкретной группы определенного класса LFB. С учетом этих ограничений разные экземпляры одного класса могут иметь разное число входов.

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

В качестве примера входной группы рассмотрим Scheduler LFB на рисунке 4.c. LFB получает пакеты от множества Queue LFB через экземпляры входов и использует индекс входа для разрешения конфликтов и планирования.

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

3.2.3. Тип пакета

Когда классы LFB определены, должны быть заданы форматы входных и выходных пакетов (например, IPv4, IPv6, Ethernet). Это типы пакетов, которые вход данного LFB способен принимать и обрабатывать или выход LFB способен выдавать. Модель требует однозначно указывать разные типы пакетов именами и/или идентификаторами.

Отметим, что каждый LFB имеет набор пакетов, с которыми он работает, но не имеет значения, передает ли нижележащая (базовая) реализация большую часть пакета. Например, IPv4 LFB может работать только с пакетами IPv4, но нижележащая (базовая) реализация может вырезать или не вырезать заголовок L2 из пакета. Наличие или отсутствие такой обработки «непрозрачно» для CE.

3.2.4. Метаданные

Метаданные представляют собой состояние, которое передается от одного LFB к другому вместе с пакетом. Метаданные помогают последующим блокам LFB обрабатывать этот пакет.

Модель ForCES определяет метаданные как неделимые элементы в форме пар «имя-значение».

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

Метаданные Inter-FE, пересекающие границу FE, выходят за рамки этого документа, хотя семантически они похожи на обычные метаданные.

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

3.2.4.1. Жизненный цикл метаданных в модели ForCES

Каждый элемент метаданных представляется в виде пары <label, value>, где метка (label) указывает тип информации (например, color), а ее значение (value) задает реальную информацию (например, red). Здесь метка представлена в текстовой форме, но для протокольной обработки она связывается с числовым идентификатором.

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

3.2.4.2. Создание и потребление метаданных

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

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

Метаданные, которые производит LFB, задаются определением класса LFB на уровне группы выходных портов. Производитель может генерировать метаданные в группе портов всегда или при некоторых условиях. В первом случае мы называем метаданные безусловными, а во втором — условными. Например, LFB глубокой проверки пакетов производит несколько частей метаданных для пакета. Первым типом метаданных может быть протокол IP (TCP, UDP, SCTP, …), а вторым — номера портов отправителя и получателя. Эти дополнительные элементы метаданных являются условными и зависят от первого элемента (протокол IP), поскольку они имеют смысл лишь для протоколов, использующих порты. Для условных метаданных в определении LFB следует обеспечивать возможность понять, когда эти метаданные создаются. Поведение потребляющего метаданные LFB, т. е. метаданные, требующиеся для работы LFB, задается в определении класса LFB на уровне группы входных портов. Группа может «требовать» определенных метаданных, а может считать их дополнительной информацией. В последнем случае определение класса LFB должно явно указывать, что произойдет, если необязательные метаданные не будут предоставлены. Одним из вариантов является задание принятых по умолчанию значений для каждого необязательного элемента метаданных и использование таких значений в случаях когда метаданные не представлены с пакетом.

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

3.2.4.3. Операции LFB над метаданными

Когда пакет обрабатывается в LFB (т. е. после получения но до пересылки пакета), этот LFB может выполнять операции чтения, записи и/или поглощения активных метаданных, связанных с пакетом. Если рассматривать LFB как черный ящик, с каждым активным элементом метаданных выполняется одна из перечисленных операций.

• IGNORE — игнорирование и пересылка.

• READ — считывание и пересылка.

• READ/RE-WRITE — считывание, запись нового значения и пересылка.

• WRITE — запись и пересылка (это может служить для создания нового элемента метаданных).

• READ-AND-CONSUME — считывание и поглощение.

• CONSUME — поглощение (удаление) метаданных без считывания.

Две последних операции завершают жизненный цикл элемента метаданных, который не уже пересылается вместе с пакетом следующему LFB.

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

Для LFB, вставляющих пакеты в модель, имеет смысл лишь операция WRITE.

LFB, удаляющие пакет из модели, могут выполнять операцию READ-AND-CONSUME (считывание) или CONSUME (игнорирование) каждого активного элемента метаданных, связанного с пакетом.

3.2.5. События LFB

В процессе работы могут возникать различные условия, которые будут детектироваться LFB. Примерами могут служить отказы каналов или перезапуск по таймеру LFB специального назначения. CE может захотеть уведомлений о таких событиях. Описание передачи таких сообщений и их формата является частью спецификации протокола ForCES [RFC5810]. Очевидно, что указание условий, при которых могут передаваться уведомления относится к модели.

События указываются в определении класса LFB. Декларация события LFB включает:

• уникальный 32-битовый идентификатор;

• указание компоненты LFB, используемой для активизации события, которую называют сигналом события;

• условия, при которых сигнал события будет приводить к генерации сообщения о событии для CE (примерами могут служить создание или удаление объекта, изменение конфигурации и т. п.);

• что элементу FE следует передать CE при выполнении условий.

Объявление событий внутри класса LFB по существу определяет, для каких компонент LFB нужен мониторинг применительно к событию, какие условия должны должен обнаружить элемент FE для констатации события и что следует сообщать CE в ответ на событие.

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

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

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

С концептуальной точки зрения в процессе работы обслуживание событий делится на 4 части.

1. Детектирование сигнала о событии (объявленного в определении класса LFB). Если CE подписан (во время работы) на событие, выполняется следующий этап.

2. Проверка условий (заданы при определении класса LFB) генерации события. Если условия выполняются, переход к следующему этапу.

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

4. Представления отчета (уведомления) элементу CE.

Более подробное описание событий приведено в параграфе 4.7.6.

3.2.6. Свойства компонент

Блоки LFB и структуры состоят из компонент, содержащих информацию о функционировании LFB, которую CE нужно просматривать и/или менять. Эти компоненты, как описано в параграфе 4.7, могут быть базовыми значениями, комплексными структурами (содержат множество компонент, которые могут быть значениями, структурами и таблицами) или таблицами (которые содержат значения, структуры или таблицы). Компоненты могут быть определены так, что их присутствие в экземплярах LFB будет не обязательно. Доступ к чтению и записи для компонент определяется реализацией FE. Элемент CE должен знать эти свойства. Кроме того, некоторые типы компонент (массивы и таблицы, псевдонимы, события) имеют дополнительную информацию о свойствах, которую элементу CE может потребоваться считывать или записывать. Модель задает структуру информации о свойствах для всх определяемых типов данных.

Более подробное описание свойств дано в параграфе 4.8.

3.2.7. Версии LFB

Версии классов LFB обеспечивают возможность поэтапного изменения этих классов. Обычно элементам FE не разрешается включать экземпляры LFB разных версий того или иного класса. Наследование (см. параграф 3.2.8) имеет некоторые правила. Если модель пути данных FE содержит экземпляр LFB некого класса C, а также экземпляр LFB другого класса C’, который является «наследником» C, классы C и C’ будут иметь разные версии.

Для поддержки версий класса LFB в определение класса нужно включать строку версии. Элементы CE могут поддерживать множество версий определенного класса LFB для обеспечения совместимости, однако FE недопустимо поддерживать более одной версии данного класса.

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

3.2.8. Наследование LFB

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

Наследование следует применять лишь при использовании значительной части определения родительского класса LFB. При малом объеме или отсутствии повторно используемых определений следует определять новый класс LFB.

Интересным вопросом, связанным с наследованием, является совместимость наследника с классом-предком. Предположим существование некого стандартизованного класса LFB L1. Предположим также, что компания A создает FE, который реализует LFB L1, а компания B создает CE, который может распознавать и взаимодействовать с LFB L1. Пусть новый класс LFB L2 является наследником L1 и расширяет его возможности. Рассмотрим вопрос совместимости FE с прежней версией в контексте того, что производитель A обновил свой FE с версии L1 до версии L2, а B не обновил свой элемент CE. Основанный на старом L1 элемент CE сможет взаимодействовать с FE версии L2, если производный класс LFB L2 действительно совместим с базовым классом L1.

Обратный случай (переход CE на LFB L2 без обновления FE) вызывает гораздо меньше проблем. Отметим, что пока CE способен работать со старыми классами LFB, это не оказывает влияния на модель, поэтому термин «совместимость со старыми версиями» (backward compatibility) относится только к элементам FE.

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

1. При обнаружении экземпляра LFB неизвестного элементу CE типа CE должен быть способен запросить базовый класс этого типа LFB у элемента FE.

2. Экземплярам LFB на FE следует поддерживать режим совместимости со старыми версиями (это означает возврат экземпляра LFB к базовому классу), а элементам CE следует поддерживать возможность настройки LFB для работы в таком режиме.

3.3. Адресация модели ForCES

На рисунке 5 показана абстракция двух разных объектов модели ForCES. Протокол ForCES обеспечивает механизмы однозначного указания компонент экземпляра класса LFB.

FE Address = FE01
+--------------------------------------------------------------+
|                                                              |
| +--------------+             +--------------+                |
| | LFB ClassID 1|             |LFB ClassID 91|                |
| | InstanceID 3 |============>|InstanceID 3  |======>...      |
| | +----------+ |             | +----------+ |                |
| | |Компоненты| |             | |Компоненты| |                |
| | +----------+ |             | +----------+ |                |
| +--------------+             +--------------+                |
|                                                              |
+--------------------------------------------------------------+

Рисунок 5. Иерархия FE Object.

На верхнем уровне иерархии адресации размещается идентификатор FE. В приведенном выше примере 32-битовый идентификатор FE обозначен FE01. Следующим 32-битовым селектором элемента является LFB ClassID. В нашем примере идентификаторы классов LFB имеют значения 1 и 91. далее на рисунке показано по одному экземпляру каждого класса. 32-битовые идентификаторы экземпляров класса LFB имеют значение только внутри данного класса LFB. Чтобы подчеркнуть это, на рисунке показаны экземпляры разных классов 1 и 91 с одним идентификатором 3.

Используя описанную схему адресации, сообщение можно отправить по адресу FE01, LFB ClassID 1, LFB InstanceID 3, с помощью протокола ForCES. Однако для повышения эффективности, такому сообщению следовало вы указывать также объекты внутри LFB. Эти объекты могут содержать состояния, возможности и т. п. Иллюстрация таких приведена на рисунке 6.

Показанные на рисунке 6 компоненты относятся к LFB Class ID 1, LFB InstanceID 3 на рисунке 5.

Компоненты LFB Class ID 1,InstanceID 3 
+-------------------------------------+
|                                     |
| LFB ComponentID 1                   |
| +----------------------+            |
| |                      |            |
| +----------------------+            |
|                                     |
| LFB ComponentID 31                  |
| +----------------------+            |
| |                      |            |
| +----------------------+            |
|                                     |
| LFB ComponentID 51                  |
| +----------------------+            |
| | LFB ComponentID 89   |            |
| | +-----------------+  |            |
| | |                 |  |            |
| | +-----------------+  |            |
| +----------------------+            |
|                                     |
|                                     |
+-------------------------------------+

Рисунок 6. Иерархия LFB.

LFB ComponentID 51 может представлять таблицу (массив). В этом случае для выбора компоненты LFB с ID 89 из седьмой записи в таблице можно использовать путь 51.7.89. В дополнение к поддержке явного выбора элемента таблицы путем включения индекса в разделенный точками путь модель позволяет указывать элементы таблиц по содержимому. Это называется использованием ключа или индексацией по ключу. Например, если ComponentID 51 представляет собой таблицу с поддержкой индексации по ключу, описывающий содержимое ключ также может передаваться элементом CE вместе и идентификатором таблицы 51 для выбора таблицы, а за ним будет следовать путь 89 для выбора элемента структуры в таблице, который после расчета в FE будет преобразовываться в LFB ComponentID 89 внутри заданной строки таблицы.

3.4. Моделирование пути данных FE

Пакеты, приходящие в FE из входных портов, обычно проходят через один или множество LFB прежде, чем попадут в выходные порты. Трактовка пакета элементом FE зависит от типа пакета (например, IPv4, IPv6, MPLS), значений заголовков, времени прибытия и других факторов. Результат обработки LFB может влиять на трактовку пакета нисходящими LFB. Эти различия можно концептуально рассматривать как наличие нескольких путей данных в FE. Например результат классификации по 6 элементами в LFB классификатора может влиять на выбор диапазона скорости в LFB измерителя на дальнейшем пути пакета.

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

3.4.1. Другие подходы к моделированию пути данных FE

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

• Топологический подход

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

• Кодирование состояний

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

Теоретически эти два подхода взаимозаменяемы, поэтому можно было бы рассмотреть один вариант описания всех путей данных в FE. Однако ни одна из этих моделей сама по себе не дает лучшего представления для практически важных случаев. Для конкретного FE с некими логическими путями данных применение двух разных вариантов моделирования будет приводить к существенно различающимся представлениям графа топологии LFB. Модель, использующая лишь топологический подход, будет требовать очень большого графа с множеством каналов или путей и узлов (экземпляры LFB) для представления всех возможных путей данных. С другой стороны, модель, использующая лишь кодированные состояния, будет ограничена строками LFB, которые не обеспечат интуитивно понятного описания разных путей данных (таких как MPLS и IPv4). Поэтому на практике скорей всего будет применяться сочетание этих подходов. Как будет показано ниже, эти два подхода можно комбинировать даже в одном LFB.

Используя простой пример классификатора с N выходами, подключенными к другим LFB, рисунок 7.a показывает, как выглядит топология LFB при использовании «чистого» топологического подхода. Каждый выход классификатора подключен к одному из N блоков LFB и метаданные не требуются. Топологический подход прост и интуитивно понятен. Однако, если число N велико и N узлов, следующих за классификатором (LFB#1, LFB#2, …, LFB#N), относятся к одному типу LFB (например, измеритель), но каждый из них имеет свои независимые компоненты, подход с кодированием состояний обеспечивает более простое представление топологии, как показано на рисунке 7.b. Этот подход требует таблицы из N строк с компонентами измерителей, обеспеченными узлами Meter, где каждая строка представляет атрибуты одного экземпляра измерителя. Нужны также метаданные M, которые передаются вместе с пакетом P от классификатора к измерителю, чтобы тот мог использовать M в качестве ключа поиска (индекса) нужной строки атрибутов, для конкретного пакета P.

Что же будет в случае N разнотипных узлов (LFB#1, LFB#2, …, LFB#N)? Например, если LFB#1 является очередью, а остальные — измерителями? Хотя и в этом случае можно использовать один из двух описанных вариантов, лучше будет объединить их. На рисунке 7.c показаны два функционально различающихся пути с использованием обеих моделей.

                                +----------+
                         P      |   LFB#1  |
                     +--------->|(Compon-1)|
+-------------+      |          +----------+
|            1|------+   P      +----------+
|            2|---------------->|   LFB#2  |
| classifier 3|                 |(Compon-2)|
|          ...|...              +----------+
|            N|------+          ...
+-------------+      |   P      +----------+
                     +--------->|   LFB#N  |
                                |(Compon-N)|
                                +----------+

(a) Использование «чистого» топологического подхода

+-------------+                 +-------------+
|            1|                 |   Meter     |
|            2|   (P, M)        | (Compon-1)  |
|            3|---------------->| (Compon-2)  |
|          ...|                 |   ...       |
|            N|                 | (Compon-N)  |
+-------------+                 +-------------+

(b) Использование состояний для представления топологии LFB (a) с однотипными LFB#1, LFB#2, …, LFB#N (например, измерители).

                             +-------------+
+-------------+ (P, M)       | queue       |
|            1|------------->| (Compon-1)  |
|            2|              +-------------+
|            3| (P, M)       +-------------+
|          ...|------------->|   Meter     |
|            N|              | (Compon-2)  |
+-------------+              |   ...       |
                             | (Compon-N)  |
                             +-------------+

(c) Использование комбинированного подхода при разнотипных LFB#1, LFB#2, …, LFB#N (например, очереди и измерители).

Рисунок 7. Пример моделирования путей данных FE.

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

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

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

                   +---------------------------------------------+
                   |                                             |
     +----------+  V      +----------+           +------+        |
     |          |  |      |          |if IP-in-IP|      |        |
---->| входные  |->+----->|classifier|---------->|Decap.|---->---+
     |  порты   |         |          |---+       |      |
     +----------+         +----------+   |others +------+
                                         |
                                         V

(a) Топология LFB с логической петлей.

    +-------+   +-----------+            +------+   +-----------+
    |       |   |           |if IP-in-IP |      |   |           |
--->|входные|-->|classifier1|----------->|Decap.|-->+classifier2|->
    | порты |   |           |----+       |      |   |           |
    +-------+   +-----------+    |others +------+   +-----------+
                                 |
                                 V

(b) Топология LFB без петель с двумя независимыми экземплярами классификатора.

Рисунок 8. Пример топологии LFB.

Важно отметить, что описанная здесь топология LFB является логической и не связана с топологией физических соединений оборудования FE. Тем не менее, реальная реализация может оказывать влияние на отображение ее функциональности на топологию LFB. На рисунке 8 представлен пример FE, где пакет IP-in-IP от приложения IPsec (типа VPN) может сначала проходить через классификатор, который будет принимать во внимание внешний заголовок IP. После классификации пакета как IP-in-IP он будет передан в декапсулятор для удаления внешнего заголовка IP, а затем будет снова классифицироваться по внутреннему заголовку IP. При использовании одного программного или аппаратного модуля классификации для внутреннего и внешнего заголовка IP с общим набором правил фильтрации в логической топологии LFB естественным образом возникает петля, показанная на рисунке 8.a. Однако при использовании двух разных наборов фильтров (например, один набор для внешних заголовков IP, другой для внутренних) более естественным будет применение двух разных экземпляров LFB классификатора (рисунок 8.b).

3.4.2. Настройка топологии LFB

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

Почему пути данных в FE меняются динамически? Эти пути создаются элементами CE для предоставления неких услуг уровня данных (например, Diffserv, VPN) сетевым элементам (NE) потребителей. Целью изменения конфигурации путей данных является обеспечение элементам CE возможности настройки услуг, предоставляемых NE, в процессе работы. CE нужно менять пути данных при изменении требований к сервису типа добавления нового потребителя или изменении потребностей имеющегося заказчика. Однако следует отметить, что не все изменения путей данных меняют граф топологии LFB. Изменения графа зависят от подхода, используемого при отображении путей данных на топологию LFB. Как было отмечено в параграфе 3.4.1, топологический подход и подход, основанный на кодировании состояний приводят к существенно разным представлениям топологии LFB для одних и тех же путей данных. В общем случае топология LFB, основанная на чистом топологическом подходе, скорей всего будет приводить к более частым изменениям по сравнению с использованием подхода с кодированием состояний. Однако даже для топологии, основанной только на представлении состояний, время от времени может потребоваться изменение (например, для обхода некоторых LFB или добавления LFB). Поскольку для моделирования путей данных используется комбинация обоих подходов, изменение топологии LFB является важным аспектом модели FE.

Мы хотим отметить, что поддержка настраиваемой топологии LFB в модели FE не требует от всех FE реализации такой возможности. Если даже FE поддерживает настраиваемую топологию LFB, он может вносить ограничения для такой настройки. Оптимизированные по производительности аппаратные реализации могут не иметь возможностей такой настройки или сильно ограничивать их, а реализации FE на базе сетевых процессоров могут обеспечивать значительную гибкость и настраиваемость. Разработчики FE могут самостоятельно принимать решение о возможности настройки топологии и ограничениях для нее. Выбор простого решения для включения или отключения (обхода) некоторых LFB или более гибкой программной настройки конфигурации определяется внутренним устройством FE и выходит за рамки модели FE. В любом случае элементы CE должны быть способны определить возможности настройки FE. Поэтому модель FE должна обеспечивать механизм для описания возможностей настройки топологии LFB внутри элементов FE. Эти возможности могут включать (см. раздел 5):

• указание классов LFB, экземпляры которых может создавать FE;

• максимальное число экземпляров одного класса LFB;

• топологические ограничения:

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

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

     +----------+     +-----------+
---->| Ingress  |---->|classifier |--------------+
     |          |     |chip       |              |
     +----------+     +-----------+              |
                                                 v
                     +-------------------------------------------+
       +--------+    |   Network Processor                       |
  <----| Egress |    |   +------+    +------+   +-------+        |
       +--------+    |   |Meter |    |Marker|   |Dropper|        |
             ^       |   +------+    +------+   +-------+        |
             |       |                                           |
  +----------+-------+                                           |
  |          |                                                   |
  |    +---------+       +---------+   +------+    +---------+   |
  |    |Forwarder|<------|Scheduler|<--|Queue |    |Counter  |   |
  |    +---------+       +---------+   +------+    +---------+   |
  +--------------------------------------------------------------+

Рисунок 9. Представление возможностей FE элементу CE.

Элементам CE нужна некоторая программная поддержка, чтобы справиться с рядом сложностей. Иными словами, даже при возможности CE настраивать топологию LFB для элемента FE, не предполагается возможность CE интерпретировать произвольную топологию LFB и определить конкретные услуги или приложения (например, VPN, Diffserv), поддерживаемые FE. Однако, если CE может грубо оценить возможности FE, элемент CE должен настроить топологию LFB для реализации сетевого сервиса, который требуется от NE. Таким образом, отображение, которое должно быть понятно CE, относится к сервису NE верхнего уровня для конкретной топологии LFB, а не наоборот. Не предполагается наличие у CE интеллектуальных возможностей трансляции политики сервиса на верхнем уровне в данные конфигурации для элементов FE. Однако можно предположить, что внутри данного домена сетевого сервиса некоторый интеллект может быть запрограммирован в CE, чтобы позволить тому понять какие LFB вовлечены в процесс для трансляции политики верхнего уровня в конфигурацию нижнего уровня для FE, задаваемую автоматически. Отметим, что это относится к внутренней реализации уровня управления и выходит за рамки модели FE, поэтому подробно в этом документе не рассматривается.

На рисунке 9 приведен пример, где маршрутизатор с поддержкой QoS¹³ имеет несколько интерфейсных плат с небольшим числом входных и выходных портов, специализированный контроллер классификатора и сетевой процессор с кодом блоков FE типа измерителей, маркировщиков, отбрасывателей, счетчиков, очередей, планировщиков и модулей пересылки IPv4. Часть топологии LFB уже зафиксирована и остается неизменной в соответствии с физическими соединениями интерфейсных плат. Например, все входные порты могут быть жестко соединены с контроллером классификации, чтобы все входящие пакеты сначала классифицировались. С другой стороны, блоки LFB на сетевом процессоре и порядок их применения являются программируемыми. Однако имеются некоторые ограничения возможностей и соединений между этими LFB. Ограничения возможностей могут включать:

• 8 измерителей;

• 16 очередей в одном FE;

• планировщик не может обслуживать больше 16 очередей;

• канальные ограничения могут включать:

• после классификатора может следовать:

• измеритель;

• маркировщик;

• отбрасыватель;

• счетчик;

• очередь или модуль пересылки IPv4но не планировщик;

• за очередью может следовать только планировщик;

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

• последним LFB в пути данных перед отправкой в выходной порт должен быть модуль пересылки IPv4.

       +-----+    +-------+                      +---+
       |    A|--->|Queue1 |--------------------->|   |
------>|     |    +-------+                      |   |  +---+
       |     |                                   |   |  |   |
       |     |    +-------+      +-------+       |   |  |   |
       |    B|--->|Meter1 |----->|Queue2 |------>|   |->|   |
       |     |    |       |      +-------+       |   |  |   |
       |     |    |       |--+                   |   |  |   |
       +-----+    +-------+  |   +-------+       |   |  +---+
     classifier              +-->|Dropper|       |   |  IPv4
                                 +-------+       +---+  Fwd.
                                              Scheduler

Рисунок 10. Топология LFB, настроенная CE и воспринятая FE.

                                          Queue1
                  +---+                    +--+
                  |  A|------------------->|  |--+
               +->|   |                    |  |  |
               |  |  B|--+  +--+   +--+    +--+  |
               |  +---+  |  |  |   |  |          |
               | Meter1  +->|  |-->|  |          |
               |            |  |   |  |          |
               |            +--+   +--+          |          IPv4
               |         Counter1 Dropper1 Queue2|    +--+  Fwd.
       +---+   |                           +--+  +--->|A |  +-+
       |  A|---+                           |  |------>|B |  | |
------>|  B|------------------------------>|  |   +-->|C |->| |->
       |  C|---+                           +--+   | +>|D |  | |
       |  D|-+ |                                  | | +--+  +-+
       +---+ | |    +---+                  Queue3 | |Scheduler
   Classifier1 | |  |  A|------------>       +--+ | |
               | +->|   |                    |  |-+ |
               |    |  B|--+  +--+ +-------->|  |   |
               |    +---+  |  |  | |         +--+   |
               |  Meter2   +->|  |-+                |
               |              |  |                  |
               |              +--+           Queue4 |
               |            Marker1          +--+   |
               +---------------------------->|  |---+
                                             |  |
                                             +--+

Рисунок 11. Топология LFB, настроенная CE и воспринятая FE.

Когда FE сообщил о своих возможностях и ограничениях элементу CE, тот может транслировать правила QoS в желаемую конфигурацию для FE. На рисунке 9 показаны возможности FE, а рисунки 10 и 11 показывают две разных топологии, которые CE может настроить в FE. Отметим, что рисунок 11 неполон, поскольку каналы между LFB не указаны.

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

4. Модель и схема для классов LFB

Основной целью модели FE является предоставление абстрактного базового модульного представления FE, не зависящего от реализации. Эта задача облегчается использованием блоков LFB, создаваемых из классов LFB. Классы LFB и связанные с ними определения будут представлены в наборе документов XML. Этот набор документов XML называется библиотекой классов LFB, а каждый из документов называется документом библиотеки классов LFB (или документом библиотеки для краткости). Каждый документ библиотеки должен соответствовать схеме, представленной в этом разделе. Схема и правила соответствия ей определяются консорциумом W3C в определениях схемы XML [Schema1] и типов данных схемы XML [Schema2]. Корневым элементом документа библиотеки является <LFBLibrary>.

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

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

4.1. Пространство имен

Пространство имен требуется для однозначной идентификации типа LFB в библиотеке классов LFB. Ссылки на определение пространства имен приведены в разделе 9. Взаимодействие с IANA.

4.2. Элемент <LFBLibrary>

Элемент <LFBLibrary> является корнем всех библиотечных документом. Документ библиотеки содержит последовательность элементов верхнего уровня. Ниже приведен список всех элементов, которые могут присутствовать непосредственно в <LFBLibrary> (имеющиеся элементы должны располагаться в указанном порядке.

• <description> содержит текстовое описание назначения библиотечного документа;

• <load> задает загрузку информации из других библиотечных документов;

• <frameDefs> служит для объявления кадров;

• <dataTypeDefs> служит для определения типов данных общего назначения;

• <metadataDefs> служит для определения метаданных;

• <LFBClassDefs> служит для определения классов LFB.

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

Документ библиотеки может импортировать другие библиотечные документы, если ему нужно ссылаться на содержащиеся в них определения. Это походе на директиву #include в языке программирования C. Импорт указывается с помощью элементов <load>, которые должны предшествовать в документе перечисленным выше элементам. Для однозначных ссылок каждый экземпляр документа LFBLibrary имеет уникальную метку, определенную в атрибуте provide элемента LFBLibrary. Отметим, что это включение относится к протоколу ForCES, а не к XML. Включается семантика содержимого библиотеки, указанной элементом <load>, а не содержимое XML. Кроме того, с точки зрения концептуальной обработки элементов <load> полный набор загружаемых документов считается одним документом. Указанный документ включается в этот набор лишь однократно, даже если он указан в нескольких элементах <load> (даже в разных файлах). Поскольку обработка информации LFBLibrary не зависит от порядка документов, порядок обработки загружаемых элементов определяется разработчиком и общий эффект будет определяться общим набором информации во всех указанных ссылками документах. Отметим, что такая компьютерная обработка библиотечных документов модели ForCES может быть полезна для различных реализаций, но не требуется для определения библиотек или реальных операций самого протокола.

Ниже приведен шаблон библиотечного документа.

       <?xml version="1.0" encoding="UTF-8"?>
       <LFBLibrary xmlns="urn:ietf:params:xml:ns:forces:lfbmodel:1.0"
         provides="this_library">

         <description>

         </description>

         <!-- Загрузка внешних библиотек (необязательно) -->
         <load library="another_library"/>
          ...
         <!-- Определения типов кадров (необязательно) -->
         <frameDefs>
          ...
         </frameDefs>

         <!-- Определения типов данных (необязательно) -->
         <dataTypeDefs>
          ...
         </dataTypeDefs>

         <!-- Определения метаданных (необязательно) -->
         <metadataDefs>
          ...
         </metadataDefs>

         <!--
           -
           -
            Определения классов LFB (необязательно) -->
         <LFBCLassDefs>

         </LFBCLassDefs>
         </LFBLibrary>

4.3. Элемент <load>

Этот элемент применяется для ссылки на другой документ библиотеки LFB. Подобно директиве #include в языке C, он делает объекты (типы метаданных и данных и т. п.), определенные в указанном документе библиотеки, доступными в текущем документе.

Элемент должен содержать метку библиотечного документа для включения и может включать идентификатор URL для указания места хранения документа. Элемент <load> может повторяться неограниченное число раз. Ниже представлены три примера элемента <load>.

   <load library="a_library"/>
   <load library="another_library" location="another_lib.xml"/>
   <load library="yetanother_library"
    location="http://www.example.com/forces/1.0/lfbmodel/lpm.xml"/>

4.4. Элемент <frameDefs> для определения типа кадра

Имена кадров используются в определении LFB для указания типов кадров, которые LFB ожидает на входных портах и выдает в выходные порты. Необязательный элемент <frameDefs> в документе библиотеки содержит один или множество элементов <frameDef> каждый из которых указывает один тип кадров.

Каждое указание типа кадра должно включать уникальное имя (NMTOKEN) и краткое описание. Дополнительно может представляться более подробное описание.

Уникальность имен типов должна обеспечиваться в рамках библиотечного документа и всех включенных в него (напрямую или опосредованно) библиотечных документов.

Приведенный ниже пример указывает два типа кадров.

   <frameDefs>
     <frameDef>
      <name>ipv4</name>
      <synopsis>IPv4 packet</synopsis>
      <description>
       Этот тип кадров относится к пакетам IPv4.
     </description>
    </frameDef>
     <frameDef>
     <name>ipv6</name>
     <synopsis>IPv6 packet</synopsis>
     <description>
       Этот тип кадров относится к пакетам IPv6.
     </description>
    </frameDef>
     ...
   </frameDefs>

4.5. Элемент <dataTypeDefs> для определения типа данных

Необязательный элемент <dataTypeDefs> может служить для определения типов данных общего пользования. Он содержит один или множество элементов <dataTypeDef>, каждый из которых определяет тип данных с уникальным именем. Такие типы данных могут затем использоваться в разных местах файла библиотеки, включая:

• определения других типов данных;

• определения компонент классов LFB.

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

Каждый элемент <dataTypeDef> должен включать уникальное имя (NMTOKEN), краткое описание и элемент определения типа. Уникальность имен типов должна обеспечиваться в рамках библиотечного документа и всех включенных в него (напрямую или опосредованно) библиотечных документов. Элемент <dataTypeDef> может также включать дополнительное, более подробное описание.

   <dataTypeDefs>
     <dataTypeDef>
       <name>ieeemacaddr</name>
        <synopsis>48-битовый адрес IEEE MAC</synopsis>
         ... определение типа ...
     </dataTypeDef>
     <dataTypeDef>
       <name>ipv4addr</name>
        <synopsis>Адрес IPv4</synopsis>
        ... определение типа ...
     </dataTypeDef>
     ...
   </dataTypeDefs>

Существует два типа данный — неделимые (atomic) и композитные (compound). Неделимые типы данных подходят для переменных с одним значением (например, integer, string, byte array).

Ниже приведен список встроенных типов atomic, но можно определеить другие неделимые типы с помощью элементов <typeRef> и <atomic>.

char

uchar

int16

uint16

int32

uint32

int64

uint64

boolean

string[N]

string

byte[N]

octetstring[N]

float32

float64

Эти встроенные типы данных готовы для использования при определении метаданных или атрибутов LFB, но могут также служить для определения новых типов данных. Тип boolean определен здесь по причине его широкого использования, хотя его можно создать путем сужения типа uchar, как делается в типах atomic (параграф 4.5.2).

Композитные типы данных можно создавать или неделимых типов и других композитных типов. Для определения композитных типов имеется четыре способа. Их можно определять как массив компонент некого композитного или неделимого типа, как структуру именованных компонент неделимых или композитных типов (аналог структур C), как объединение (union) именованных компонент неделимых или структурных типов (аналог C union), а также как дополнения существующих композитных типов (см. параграф 4.5.7).

С учетом того, что протокол ForCES будет принимать и устанавливать значения компонент, все используемые здесь неделимые типы должны передаваться протоколом ForCES. Кроме того, для протокола ForCES нужен механизм передачи композитных типов. Однако детали таких представления относятся к документу, определяющему протокол ForCES [RFC5810], а не к данной модели. Типы string и octetstring должны передаваться протоколом вместе с полем размера, поскольку их фактический размер не задается определением.

Для строковых типов модель задает небольшой набор ограничений и определений способов структурирования. Ограничения размера для string и octetstring могут быть указаны в определениях классов LFB. Свойства компонент string и octetstring также включают действительные размеры и ограничения размера. Дублирование ограничений позволяет реализациям сократить максимальные размеры переменных, заданные в определении класса LFB. В любом случае ограничения задаются числом октетов, а не символов. При работе протокола если указанный размер не превосходит возможности FE, элемент FE полностью сохраняет содержимое строки, представленной CE, и возвращает такие строки по запросу. Элемент FE не выполняет преобразований строк. Компоненты типа string или string[n] могут применяться для хранения идентификаторов сопоставляемых с компонентами других LFB. В таких случаях должно проверяться пооктетное соответствие ьез каких-либо преобразований. Протокол ForCES [RFC5810] не проверяет и не требует проверки пригодности содержимого строк UTF-8. Однако строки UTF-8 следует кодировать в кратчайшей форме для предотвращения возможных проблем безопасности, описанных в [UNICODE]. Предполагается, что любой объект, отображающий такие строки, сам проверяет их пригодность (например, для корректировки многобайтовых символов или гарантии того, что строка не завершается в середине многобайтовой последовательности). Определения конкретных классов LFB могут ограничивать содержимое строк с учетом их применения (например, компоненты с именами DNS могут быть ограничены использованием лишь допустимых в таких именах октетов). Элементам FE следует проверять содержимое запросов SET для компонент с такими ограничениями при установке запрошенных значений путем простого сравнения с диапазоном разрешенных для компоненты символов. Протокол ForCES определяет нормативную обработку для используемых протоколом запросов.

Для задания типа в элементах <dataTypeDef> доступны элементы <typeRef>, <atomic>, <array>, <struct> и <union>.

Предопределенный псевдоним (alias) типа занимает промежуточное положение между типами данных atomic и compound. Псевдонимы служат для того, чтобы компоненты внутри LFB могли опосредованно ссылаться на другие компоненты внутри того же или другого класса или экземпляра LFB. Компонента alias ведет себя подобно структуре, в которой одна компонента имеет специальное назначение. Учетом того, что особое поведение связано с другими частями структуры, результат считается предопределенной конструкцией.

4.5.1. Элемент <typeRef> для переименования имеющихся типов данных

Элемент <typeRef> указывает на существующий тип данных по его имени. Упомянутый тип данных должен быть определен в том же документе или в одном из включенных в него библиотечных документов. Если указанный тип данных является неделимым, определенный заново тип так же будет относится к числу типов atomic. Если указанный тип является композитным, вновь определенный тип также будет композитным. Пример использования показан ниже.

   <dataTypeDef>
     <name>short</name>
     <synopsis>Псевдоним для int16</synopsis>
     <typeRef>int16</typeRef>
   </dataTypeDef>
   <dataTypeDef>
     <name>ieeemacaddr</name>
     <synopsis>48-битовый адрес IEEE MAC</synopsis>
     <typeRef>byte[6]</typeRef>
   </dataTypeDef>

4.5.2. Элемент <atomic> для создания производных неделимых типов

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

Например, приведенный ниже фрагмент определяет новый неделимый тип данных dscp.

   <dataTypeDef>
     <name>dscp</name>
     <synopsis>Код Diffserv.</synopsis>
     <atomic>
       <baseType>uchar</baseType>
       <rangeRestriction>
         <allowedRange min="0" max="63"/>
       </rangeRestriction>
       <specialValues>
         <specialValue value="0">
           <name>DSCP-BE</name>
           <synopsis>Best Effort</synopsis>
         </specialValue>
          ...
       </specialValues>
     </atomic>
    </dataTypeDef>

4.5.3. Элемент <array> для определения массивов

Элемент <array> может служить для создания новых композитных типов данных в форме массива композитных или неделимых типов. В зависимости от контекста этот и другие документы считают такие массивы и таблицы взаимозаменяемыми без учета синтаксиса и семантики. Тип элементов массива может быть задан ссылкой на имеющийся тип (с помощью элемента <typeRef>) или определением неименованного типа внутри элемента <array> с помощью элементов <atomic>, <array>, <struct> или <union>.

Массив может иметь фиксированный или переменный размер, что указывается атрибутом type элемента <array>. По умолчанию размер считается переменным и для него может указываться необязательный атрибут maxlength, задающий максимальный размер. Этот атрибут следует применять для задания семантических ограничений, а не ограничений реализации. Последнее (поддержка ограничений реализации) следует задавать с помощью возможностей компонент классов LFB и никогда не следует включать максимальный размер в тип данных array, размер которого считается неограниченным.

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

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

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

В дополнение к индексам массив может быть объявлен с использованием ключей. Это дает несколько эффектов:

• лшюбой объявленный ключ может применяться в контексте протокола ForCES при выборе компонент для операций (см. спецификацию протокола ForCES [RFC5810]);

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

Каждый ключ объявляется с идентификатором keyID для использования в протоколе ForCES [RFC5810], где уникальный идентификатор формируется из одного или множества заданных полей ключа. Для поддержки случаев где массив неделимого типа с уникальными значениями может быть указан этими значениями в качестве идентификатора ключевого поля может применяться шаблон (т. е. элемент массива является ключом). Если типом значения массива является структура или массив, ключом служит одна или множество компонент значения, указываемых именами. Поскольку поле может быть компонентой включенной в массив структуры, компонентой компоненты структуры и т. д., имя поля на практике является конкатенацией идентификаторов компонент, разделенных точками. Синтаксис для идентификации полей ключа показан в приведенных ниже примерах массивов.

Этот пример показывает определение массива фиксированного размера с предопределенным типом данных.

     <dataTypeDef>
           <name>dscp-mapping-table</name>
           <synopsis>
              Таблица из 64 значений DSCP, используемая для переотображения кодов.
           </synopsis>
           <array type="fixed-size" length="64">
              <typeRef>dscp</typeRef>
           </array>
         </dataTypeDef>

Пример массива переменного размера с указанием верхнего предела.

         <dataTypeDef>
           <name>mac-alias-table</name>
           <synopsis>Таблица, содержащая до 8 адресов IEEE MAC</synopsis>
           <array type="variable-size" maxlength="8">
               <typeRef>ieeemacaddr</typeRef>
           </array>
         </dataTypeDef>

Пример массива с локальным (неименованным) определением типа содержимого.

         <dataTypeDef>
           <name>classification-table</name>
           <synopsis>Таблица правил классификации и кодов результата.</synopsis>
           <array type="variable-size">
             <struct>
               <component componentID="1">
                 <name>rule</name>
                 <synopsis>Правило для сопоставления</synopsis>
                 <typeRef>classrule</typeRef>
               </component>
               <component componentID="2">
                 <name>opcode</name>
                 <synopsis>Код результата</synopsis>
                 <typeRef>opcode</typeRef>
               </component>
            </struct>
           </array>
         </dataTypeDef>

В приведенном выше примере каждый элемент массива является структурой с двумя компонентами (rule и opcode).

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

      <dataTypeDef>
        <name>ipPrefixInfo_table</name>
        <synopsis>Таблица данных об известных префиксах</synopsis>
        <array type="variable-size">
          <struct>
            <component componentID="1">
              <name>address-prefix</name>
              <synopsis>Префикс, который будет описан</synopsis>
              <typeRef>ipv4Prefix</typeRef>
            </component>
            <component componentID="2">
              <name>source</name>
              <synopsis>Протокол или процесс, обеспечивший эту информацию</synopsis>
              <typeRef>uint16</typeRef>
            </component>
            <component componentID="3">
              <name>prefInfo</name>
              <synopsis>Информация, о которой мы заботимся</synopsis>
              <typeRef>hypothetical-info-type</typeRef>
            </component>
          </struct>
          <contentKey contentKeyID="1">
            <contentKeyField> address-prefix.ipv4addr</contentKeyField>
            <contentKeyField> address-prefix.prefixlen</contentKeyField>
            <contentKeyField> source</contentKeyField>
          </contentKey>
        </array>
      </dataTypeDef>

Отметим, что элементами keyField могут также быть просто address-prefix и source, поскольку они включают все поля.

4.5.3.1. Ссылки на поля ключа

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

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

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

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

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

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

4.5.4. Элемент <struct> для определения структур

Структура состоит из набора компонент с данными. Каждая компонента имеет тип (неделимый или композитный) и имя, которое должно быть уникальным в области действия определения композитного типа. Это похоже на struct в языке C. Компоненты определяются с помощью элементов <component>. Элемент <struct> может содержать элемент <derivedFrom>, указывающий базовую структуру. Определение структуры должно включать не менее одного элемента <component>.

Фактический тип компоненты может определяться ссылкой на имеющийся тип (элемент <typeRef>) или задаваться локальным (неименованным) типом, созданным с использованием элементов <atomic>, <array>, <struct> или <union>.

Элемент <component> должен включать атрибут componentID, обеспечивающий числовой идентификатор компоненты для использования протоколом. В элемент <component> должны включаться также имя и краткое описание компоненты, дополнительно может включаться элемент <description> с более подробным описанием. Определение может также включать элемент <optional>, указывающий, что определяемая компонента не является обязательной. Определение должно содержать элементы, определяющие тип компоненты, как описано выше.

Для dataTypeDef определение структуры может быть унаследовано от ранее определенного структурированного типа и дополнено. Это указывается включением необязательного атрибута derivedFrom в объявление структуры до определения дополнений или замены компонент (см. параграф 4.5.7).

Атрибуты componentID для разных компонент структуры (или LFB) должны различаться. Задавать какой-либо порядок идентификаторов не требуется. Для удобочитаемости и упрощения обслуживания обычно определяется набор последовательных значений, но это не является требованием протокола.

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

Пример определения структуры приведен ниже.

   <dataTypeDef>
    <name>ipv4prefix</name>
    <synopsis>Префикс IPv4, определяемый адресом и размером префикса</synopsis>
    <struct>
     <component componentID="1">
      <name>address</name>
      <synopsis>Адресная часть префикса</synopsis>
      <typeRef>ipv4addr</typeRef>
     </component>
     <component componentID="2">
      <name>prefixlen</name>
      <synopsis>Размер префикса</synopsis>
      <atomic>
       <baseType>uchar</baseType>
       <rangeRestriction>
        <allowedRange min="0" max="32"/>
       </rangeRestriction>
      </atomic>
     </component>
    </struct>
   </dataTypeDef>

4.5.5. Элемент <union> для определения типов объединений

Подобно объявлению union в языке C, эта конструкция позволяет определять оверлейные типы. Формат аналогичен формату элемента <struct>.

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

4.5.6. Элемент <alias>

Иногда в LFB или структуре нужна компонента, ссылающаяся на информацию (или компоненту) в другом LFB. Это может позволять, например, использовать в ARP LFB таблицу трансляции адресов IP->MAC совместно с LFB локальной передачи без дублирования информации. Аналогично можно позволить LFB измеритель трафика разделять информацию с LFB формирования трафика. Для создания таких конструкций служит элемент <alias>. Конструкция позволяет сказать элементам CE и FE, что любые манипуляции с определенными данными на деле применяются к данным, находящимся в некой заданной части другого указанного экземпляра LFB. Содержимое элемента <alias> должно быть именованным типом. Независимо от того, на какую компоненту указывает псевдоним (это определяется описанными ниже свойствами компоненты псевдонима), эта компонента должна иметь такой же тип, какой был заявлен для псевдонима. Таким образом, когда CE или FE разыменовывает компоненту псевдонима, тип возвращаемой информации известен. Этим типом может быть как базовый, так и производный тип. Когда операция GET или SET указывает на псевдоним, возвращается или изменяется значение, на которое этот псевдоним указывает (цель). Запись в псевдоним будет разрешена, если имеется возможность записи в цель псевдонима.

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

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

4.5.7. Дополнения

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

Дополнения недопустимо применять к объединению (union).

Одним из следствий этого является совместимость дополнений с базовым типом, из которого дополнение создано. Таким образом, дополнения полезны для определения компонент субклассов LFB, совместимых со своими «прародителями». Кроме добавления в класс новых компонент типы данных существующих компонент могут быть заменены их дополнениями и при этом будут соответствовать правилам совместимости для субклассов. Именно это служит причиной неприменимости дополнений к типу union.

Рассмотрим, например, простой базовый блок LFB класса A, имеющий одну компоненту (comp1) типа X. Одним из способов создать класс A1 из A является простое добавление второй компоненты (любого типа). Другим способом создать класс A2 из A является замена в A исходной компоненты (comp1) типа X на тип Y, который является дополнением (расширением) X. Оба класса A1 и A2 совместимы с классом A.

Синтаксис дополнения заключается во включении в определение структуры элемента <derivedFrom>, показывающего, что структура была дополнена. Именам и идентификаторам для новых компонент в дополнении недопустимо совпадать с именами или идентифкаторами в дополняемой структуре. Для компонент, где тип имеющихся данных был замене подходящим для дополнения типом данных, имеющееся имя и идентификатор компоненты должны использоваться в дополнении. Кроме ограничений на существующие компоненты, не задается других требований к идентификаторам компонент (последовательность, возрастание или иные связи с имеющимися идентификаторами). Предполагается, что в общем случае используемые значения будут последовательными при дополнении и отличающимися от ранее использованных значений, что удобно для человеческого восприятия.

4.6. Элемент <metadataDefs> для определения метаданных

Необязательный элемент <metadataDefs> в библиотечном документе содержит один или множество элементов <metadataDef>, определяющих метаданные.

Каждый элемент <metadataDef> должен содержать уникальное имя (NMTOKEN). Уникальность определяется среди всех метаданных в масштабе библиотечного документа и всех включенных в него (напрямую или косвенно) библиотечных документов. Элемент <metadataDef> должен также включать краткое описание (synopsis), значение тега, используемое для этих метаданных и информацию об определении типа значения. В качестве значений метаданных могут применяться лишь неделимые (atomic) типы данных. Элемент <metadataDef> может содержать элемент с подробным описанием.

Разрешены две формы определения типа. Первая форма использует элемент <typeRef> для указания имеющегося неделимого типа данных, определенного в элементе <dataTypeDefs> того же библиотечного документа или включенного в него документа. Использование элемента <typeRef> идентично использованию элементов <dataTypeDef>, за исключением того, что они могут указывать лишь неделимые типы. Последнее ограничение не проверяется схемой XML.

Вторая форма использует явное определение типа с помощью элемента <atomic>, который используется здесь так же, как в элементах <dataTypeDef>.

Ниже приведен пример использования обеих форм.

   <metadataDefs>
    <metadataDef>
     <name>NEXTHOPID</name>
     <synopsis>Указывает элемент Next Hop в NH LFB</synopsis>
     <metadataID>17</metadataID>
     <typeRef>int32</typeRef>
    </metadataDef>
    <metadataDef>
     <name>CLASSID</name>
     <synopsis>Результат классификации (0 говорит о несоответствии).</synopsis>
     <metadataID>21</metadataID>
     <atomic>
      <baseType>int32</baseType>
      <specialValues>
       <specialValue value="0">
        <name>NOMATCH</name>
        <synopsis>Классификация не нашла соответствия.</synopsis>
       </specialValue>
      </specialValues>
     </atomic>
    </metadataDef>
   </metadataDefs>

4.7. Элемент <LFBClassDefs> для определения классов LFB

Необязательный элемент <LFBClassDefs> можно использовать для определения одного или множества классов LFB с помощью элементов <LFBClassDef>. Каждый элемент <LFBClassDef> должен определять класс LFB и включать перечисленные ниже элементы.

• <name> указывает символьное имя класса LFB (например ipv4lpm).

• <synopsis> содержит краткое описание класса LFB (например, IPv4 Longest Prefix Match Lookup LFB).

• <version> указывает номер версии.

• <derivedFrom> указывает предка.

• <inputPorts> перечисляет входные порты и их спецификации.

• <outputPorts> перечисляет выходные порты и их спецификации.

• <components> определяет рабочие компоненты LFB.

• <capabilities> определяет компоненты возможностей (capability) LFB.

• <description> содержит операционную спецификацию LFB.

• Атрибут LFBClassID элемента LFBClassDef определяет идентификатор класса, который должен быть уникальным в глобальном масштабе.

• <events> определяет события, которые могут генерироваться экземплярами этого класса LFB.

Имена классов LFB должны быть уникальными, чтобы другие документы могли указывать классы по имени, а читатели могли понимать ссылки на классы по именам. Комплексное именование но возбраняется, но приветствуется простота. Как указано в разделе 9. Взаимодействие с IANA, агентство IANA поддерживает реестр имен и идентификаторов классов LFB со ссылками на определяющие классы документы.

Ниже приведена структура определения класса LFB. Отметим, что в целях упрощения схемы XML порядок размещения элементов в определении класса фиксирован. Имеющиеся в определении элементы должны размещаться в указанном ниже порядке.

   <LFBClassDefs>
    <LFBClassDef LFBClassID="12345">
     <name>ipv4lpm</name>
     <synopsis>LFB поиска максимального размера соответствия префикса IPv4</synopsis>
     <version>1.0</version>
     <derivedFrom>baseclass</derivedFrom>

     <inputPorts>
      ...
     </inputPorts>

     <outputPorts>
      ...
     </outputPorts>

     <components>
      ...
     </components>

     <capabilities>
      ...
     </capabilities>

     <events>
      ...
     </events>

     <description>
      Этот класс LFB представляет операцию поиска префикса IPv4 с 
      максимальной длиной совпадения.
      Моделируемым поведением является ...
     </description>

    </LFBClassDef>
    ...
   </LFBClassDefs>

Отдельные компоненты и возможности имеют идентификаторы для использования протоколом ForCES. Эти componentID используются в структурах, подобно именам. Значения componentID для компонент и возможностей должны быть уникальными в рамках определения класса LFB.

Отметим, что элементы <name>, <synopsis> и <version> являются обязательными, а все остальные элементы могут отсутствовать в <LFBClassDef>. Однако при наличии необязательных элементов они должны размещаться в указанном выше порядке.

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

4.7.1. Элемент <derivedFrom> для выражения наследования LFB

Необязательный элемент <derivedFrom> может служить для указания того, что данный класс происходит от другого класса. Содержимым этого элемента должно быть уникальное имя (<name>) другого класса LFB, который должен быть определен в том же библиотечном документе или во включенном в него документе. При отсутствии элемента <derivedFrom> класс концептуально выводится из пустого базового класса.

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

4.7.2. Элемент <inputPorts> для определения входов LFB

Необязательный элемент <inputPorts> служит для определения входных портов. Класс LFB может не иметь входов или иметь один или более вход. Если у класса LFB нет входных портов, элемент <inputPorts> должен отсутствовать. Элемент <inputPorts> может содержать один или множество элементов <inputPort>, по одному для каждого порта или группы портов. Предполагается, что большинство LFB будет иметь один вход. Множество входов одного типа моделируется как входная группа. Группы определяются так же, как входные порты с помощью элемента <inputPort>, отличаясь лишь атрибутом group.

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

Отдельные входные порты и группы входных портов определяются элементами <inputPort> и различаются лишь необязательным атрибутом group.

Элемент <inputPort> должен включать перечисленные ниже элементы.

• <name> указывает символьное имя входного порта (например, in). Отметим, что имя должно быть уникальным в рамках класса LFB.

• <synopsis> содержит краткое описание входа (например, Normal packet input).

• <expectation> перечисляет все разрешенные форматы кадров (например, {ipv4 и ipv6}. Отметим, что в список следует включать имена, заданные в элементе <frameDefs> того же библиотечного документа или включенных в него документов. Элемент <expectation> может также содержать список требуемых метаданных (например, {classid, vpnid}. В список следует включать имена, заданные в элементе <metadataDefs> того же библиотечного документа или включенных в него документов. Для каждого элемента метаданных должно быть указано, является он обязательным или опциональным. Для необязательных метаданных должно быть указано значение, которое LFB будет использовать при отсутствии соответствующих метаданных у пакета.

В дополнение к этому необязательный атрибут group в элементе <inputPort> может указывать, что порт может вести себя как группа портов, т. е позволяет создавать экземпляры. Это указывается значением атрибута true (по умолчанию создание экземпляров запрещено — false).

Пример элемента <inputPorts>, определяющего два входных порта, из которых второй является группой, показан ниже.

   <inputPorts>
    <inputPort>
     <name>in</name>
     <synopsis>Обычный вход</synopsis>
     <expectation>
      <frameExpected>
       <ref>ipv4</ref>
       <ref>ipv6</ref>
      </frameExpected>
      <metadataExpected>
       <ref>classid</ref>
       <ref>vifid</ref>
       <ref dependency="optional" defaultValue="0">vrfid</ref>
      </metadataExpected>
     </expectation>
    </inputPort>
    <inputPort group="true">
     ... другой входной порт ...
    </inputPort>
   </inputPorts>

Для каждого элемента <inputPort> ожидаемые типы кадров определяются элементом <frameExpected> с одним или несколькими элементами <ref> (см. пример выше). При указании нескольких типов кадров ожидается один из перечисленных. Пакеты всех остальных типов считаются несовместимыми с этим входным портом в данном классе LFB. В приведенном выше примере ожидаемыми типами кадров являются ipv4 и ipv6.

Ожидаемые метаданные указываются элементом <metadataExpected>. В простейшей форме этот элемент может содержать список элементов <ref>, каждый из которых указывает элемент метаданных. При указании множества экземпляров метаданных в элементах <ref> это означает, что каждый принятый пакет должен сопровождаться всеми этими метаданными (за исключением метаданных, помеченных как optional в атрибуте dependency соответствующего элемента <ref>). Для необязательных (optional) метаданных должно указываться принятое по умолчанию значение с помощью атрибута defaultValue. В приведенном выше примере указаны три ожидаемых элемента метаданных, два из которых обязательны (classid и vifid), а один не обязателен (vrfid).

Схема также позволяет более сложные определения ожидаемых метаданных. Например, с помощью элемента <one-of> можно указать список метаданных, из которого с пакетом должен быть представлен один элемент. Например,

   <metadataExpected>
    <one-of>
     <ref>prefixmask</ref>
     <ref>prefixlen</ref>
    </one-of>
   </metadataExpected>

Здесь метаданные prefixmaskили prefixlen должны сопровождать каждый пакет.

Две формы указания метаданных можно комбинировать, как показано ниже.

   <metadataExpected>
    <ref>classid</ref>
    <ref>vifid</ref>
    <ref dependency="optional" defaultValue="0">vrfid</ref>
    <one-of>
     <ref>prefixmask</ref>
     <ref>prefixlen</ref>
    </one-of>
   </metadataExpected>

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

4.7.3. Элемент <outputPorts> для определения выходов LFB

Необязательный элемент <outputPorts> служит для определения выходных портов. Класс LFB может совсем не иметь выходов или содержать один или несколько выходных портов. Если у класса LFB нет выходных портов, элемент <outputPorts> должен отсутствовать. Элемент <outputPorts> должен включать один или несколько элементов <outputPort>, по одному для каждого порта или группы портов. При наличии множества однотипных выходов они моделируются как группа выходных портов. Некоторые LFB специального назначения не имеют выходных портов (например, Dropper).

Одиночные выходные порты и отдельные группы определяются элементами <outputPort> и различаются лишь необязательным атрибутом group.

Элемент <outputPort> должен содержать перечисленные ниже элементы.

• <name> указывает символьное имя выходного порта (например, out). Отметим, что имя должно быть уникальным в рамках класса LFB.

• <synopsis> содержит краткое описание входа (например, Normal packet output).

• <product> перечисляет все разрешенные форматы кадров (например, {ipv4 и ipv6}. Отметим, что в список следует включать имена, заданные в элементе <frameDefs> того же библиотечного документа или включенных в него документов. Элемент <product> может также содержать список выдаваемых (генерируемых) метаданных (например, {classid, color}. В список следует включать имена, заданные в элементе <metadataDefs> того же библиотечного документа или включенных в него документов. Для каждого генерируемого элемента метаданных следует указать, создается он всегда или при заданных условиях. Эта информация нужна при оценке совместимости LFB.

В дополнение к этому необязательный атрибут group в элементе <outputPort> может указывать, что порт может вести себя как группа портов, т. е позволяет создавать экземпляры. Это указывается значением атрибута true (по умолчанию создание экземпляров запрещено — false).

Пример элемента <outputPort>, определяющего 2 выходных порта, из которых второй является группой, показан ниже.

   <outputPorts>
    <outputPort>
     <name>out</name>
     <synopsis>Обычный вывод</synopsis>
     <product>
      <frameProduced>
       <ref>ipv4</ref>
       <ref>ipv4bis</ref>
      </frameProduced>
      <metadataProduced>
       <ref>nhid</ref>
       <ref>nhtabid</ref>
      </metadataProduced>
     </product>
    </outputPort>
    <outputPort group="true">
     <name>exc</name>
     <synopsis>Группа портов для вывода в исключительных случаях</synopsis>
     <product>
      <frameProduced>
       <ref>ipv4</ref>
       <ref>ipv4bis</ref>
      </frameProduced>
      <metadataProduced>
       <ref availability="conditional">errorid</ref>
      </metadataProduced>
     </product>
    </outputPort>
   </outputPorts>

Типы кадров и метаданных, выдаваемых портом определяются в элементе <product> каждого <outputPort>. Внутри <product> список производимых портом типов кадров указывается в элементе <frameProduced>. При указании нескольких типов это значит, что порт будет выдавать один из указанных типов.

Список метаданных, выдаваемых портом указывается в необязательном элементе <metadataProduced> внутри <product>. В простейшей форме этот элемент содержит список элементов <ref>, каждый из которых задает тип метаданных. При наличии списка все метаданные из него выдаются с каждым пакетом (за исключением помеченных необязательным атрибутом availability со значением conditional). Подобно элементу <metadataExpected> в <inputPort>, элемент <metadataProduced> поддерживает более сложные формы, которые здесь не рассматриваются.

4.7.4. Элемент <components> для определения рабочих компонент LFB

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

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

• Настраиваемые флаги и переключатели рабочих режимов LFB.

• Число входов или выходов в группе портов.

• Настраиваемые таблицы поиска, включа таблицы интерфейсов, префиксов, классификаци, отображения DSCP, MAC-адресов и т. п.

• Счетчики пакетов и байтов.

• Счетчики событий.

• Текущее число входов или выходов для каждой группы входов или выходов.

Модель ForCES поддерживает определение ограничений доступа, указывающих, что может делать CE с компонентами LFB. Ниже перечислены поддерживаемые моделью категории доступа.

• No-access — нет доступа. Применяется для полноты и позволяет определять объекты, используемые другими, но не указываемые непосредственно элементами управления CE. Это полезно также для FE, сообщающих, что для некоторых определенных и обычно доступных компонент не поддерживается доступ со стороны CE.

• Read-only — только чтение.

• Read-write — чтение и запись.

• Write-only — только запись. Это могут быть любые настраиваемые данные, чтение которых не разрешено для CE (например, ключи защиты).

• Read-reset — чтение и сброс. CE может считывать и сбрасывать этот ресурс, но не может установить для него произвольное значение. Примером могут служить счетчики.

• Firing-only — инициирование. Попытка записи в этот ресурс будет вызывать в LFB крнкретные действия, но записанное значение игнорируется.

Класс LFB должен определять для данной компоненты лишь один из возможных режимов доступа.

Компоненты класса LFB перечисляются в элементе <components>, где для каждой компоненты используется элемент <component>, содержащий все или некоторые из перечисленных ниже элементов, часть которых обязательна.

• <name> определяет имя компоненты, которое должно присутствовать. Имя должно быть уникальным среди компонент класса LFB (например, version).

• <synopsis> обеспечивает краткое описание назначения компоненты и является обязательным.

• <optional/> является необязательным элементом, наличие которого указывает необязательность компоненты.

• Тип данных компоненты может быть указан ссылкой на предопределенный тип данных или локальным определением типа. Ссылка на определение задается с помощью элемента <typeRef>, который должен указывать уникальное имя имеющегося типа данных, который определен элементом <dataTypeDefs> в этом же библиотечном документе или в любом из включенных в него документов. При локальном определении данных (безымянный тип) используется один из элементов <atomic>, <array>, <struct> или <union>. Их использование аналогично использованию внутри элементов <dataTypeDef> (параграф 4.5). В определении компоненты должна быть включена та или иная форма определения типа данных.

• <defaultValue> является необязательным элементов и при наличии указывает принятое по умолчанию значение компоненты. Если принятое по умолчанию значение задано, элемент FE должен обеспечить установку этого значения компоненты при инициализации или сбросе LFB. Если принятое по умолчанию значение для компоненты не задано, элементу CE недопустимо принимать какие-либо допущения о значении компоненты при инициализации. Элемент CE должен считать или установить значение, если хочет знать его.

• <description> может включаться в определение для более детального описания назначения или использования определяемой компоненты.

Элемент <component> должен иметь атрибут componentID, числовое значение которого используется протоколом ForCES.

В дополнение к перечисленным элементам <component> включает необязательный атрибут access, который может принимать значение read-only, read-write (используется по умолчанию), write-only, read-reset или trigger-only.

Поддержка необязательных компонент и возможность реальной записи в компоненты read-write может быть определена для данного экземпляра LFB элементом CE путем считывания информации о свойствах компоненты. Установка режима доступа trigger-only означает включение компоненты для использования лишь в качестве детектора событий.

Приведенный ниже пример определяет две компоненты для LFB.

   <components>
    <component access="read-only" componentID="1">
     <name>foo</name>
     <synopsis>число объектов</synopsis>
     <typeRef>uint32</typeRef>
    </component>
    <component access="read-write" componentID="2">
     <name>bar</name>
     <synopsis>число других объектов</synopsis>
     <atomic>
      <baseType>uint32</baseType>
      <rangeRestriction>
       <allowedRange min="10" max="2000"/>
      </rangeRestriction>
     </atomic>
     <defaultValue>10</defaultValue>
    </component>
   </components>

Первая компонента (foo) является доступным лишь для чтения 32-битовым целым числом без знака, определяемым ссылкой на встроенный неделимый тип uint32. Вторая компонента (bar) также является целым числом, но использует элемент <atomic> для задания дополнительных ограничений диапазона. Эта компонента доступна для чтения и записи. По умолчанию для нее задано значение 10. Хотя доступ разрешен для чтения и записи, некоторые реализации могут дополнительно ограничивать доступ и это будет указано в свойствах компоненты.

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

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

4.7.5. Элемент <capabilities> для определения возможностей LFB

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

Такая информация выражается компонентами возможностей класса LFB, которые всегда являются доступными лишь для чтения атрибутами и указываются в отдельном элементе <capabilities> определения <LFBClassDef>. Элемент <capabilities> содержит один или множество элементов <capability>, кажый из которых определяет одну возможность. Формат элемента <capability> похож на формат <component> и отличается лишь отсутствием атрибута режима доступа (всегда read-only) и элемента <defaultValue> (принятое по умолчанию значение не применимо к атрибутам read-only).

Ниже приведены некоторые примеры возможностей.

• Версия класса LFB с которой был собран экземпляр LFB.

• Поддерживаемые необязательные возможности класса LFB.

• Максимальное число настраиваемых выходов в выходной группе.

• Ограничения LFB на передачу метаданных.

• Дополнительные ограничения диапазона рабочих компонент.

Ниже приведен пример с двумя атрибутами возможностей.

   <capabilities>
    <capability componentID="3">
     <name>version</name>
     <synopsis>
      Версия класса LFB, которой соответствует экземпляр.
     </synopsis>
     <typeRef>version</typeRef>
    </capability>
    <capability componentID="4">
     <name>limitBar</name>
     <synopsis>
      Максимальное значение атрибута bar.
     </synopsis>
     <typeRef>uint16</typeRef>
    </capability>
   </capabilities>

4.7.6. Элемент <events> для генерации уведомлений LFB

Элемент <events> содержит информацию о событиях, для которых экземпляры этого класса LFB могут генерировать уведомления для CE. Общее описание объявления и работы с событиями LFB приведено в параграфе 3.2.5.

Элемент <events> может (но не обязан) содержать элементы <event>, каждый из которых описывает одно событие и имеет атрибут eventID с уникальным (для класса LFB) идентификатором события и включает элементы:

• <eventTarget>, указывающий поле (компоненту) LFB, проверяемую для генерации события;

• <condition>, указывающий для поля условие генерации события из списка определенных условий;

• <eventReports>, указывает значения, включаемые в уведомление о событии.

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

Элемент <events> имеет атрибут baseID, который обычно имеет форму <events baseID=»number»>. Значением baseID является стартовый идентификатор componentID для пути, указывающего события. Он должен отличаться от componentID всех компонент верхнего уровня (включая возможности) класса LFB. В производных LFB (т. е. имеющих элемент <derivedFrom>), у которых родительский класс LFB имеет объявления для событий, значению baseID недопустимо присутствовать в элементе <events> производного LFB и взамен используется значение baseID из родительского класса LFB. В приведенном примере baseID имеет значение 7.

   <events baseID="7">
    <event eventID="7">
      <name>Foochanged</name>
      <synopsis>Пример события для скаляра</synopsis>
      <eventTarget>
        <eventField>foo</eventField>
      </eventTarget>
      <eventChanged/>
      <eventReports>
        <!-- Отчет о новом состоянии -->
        <eventReport>
          <eventField>foo</eventField>
        </eventReport>
      </eventReports>
    </event>

    <event eventID="8">
      <name>Goof1changed</name>
      <synopsis>
          Пример события для составной структуры
      </synopsis>
      <eventTarget>
        <!-- Целью служит goo.f1 -->
        <eventField>goo</eventField>
        <eventField>f1</eventField>
      </eventTarget>
      <eventChanged/>
      <eventReports>
        <!-- Отчет о новом состоянии goo.f1 -->
        <eventReport>
        <eventField>goo</eventField>
        <eventField>f1</eventField>
        </eventReport>
      </eventReports>
    </event>

    <event eventID="9">
      <name>NewbarEntry</name>
      <synopsis>
          Событие для новой записи, созданной в таблице bar
      </synopsis>
      <eventTarget>
        <eventField>bar</eventField>
        <eventSubscript>_barIndex_</eventSubscript>
      </eventTarget>
      <eventCreated/>
      <eventReports>
        <eventReport>
         <eventField>bar</eventField>
         <eventSubscript>_barIndex_</eventSubscript>
       </eventReport>
       <eventReport>
        <eventField>foo</eventField>
       </eventReport>
      </eventReports>
    </event>

    <event eventID="10">
      <name>Gah11changed</name>
      <synopsis>
          Событие для таблицы gah изменена запись с индексом 11
      </synopsis>
      <eventTarget>
        <eventField>gah</eventField>
        <eventSubscript>11</eventSubscript>
      </eventTarget>
      <eventChanged/>
      <eventReports>
        <eventReport>
         <eventField>gah</eventField>
         <eventSubscript>11</eventSubscript>
       </eventReport>
      </eventReports>
    </event>

    <event eventID="11">
      <name>Gah10field1</name>
      <synopsis>
          Событие для таблицы gah изменена запись с индексом 10, 
          колонка field1
      </synopsis>
      <eventTarget>
        <eventField>gah</eventField>
        <eventSubscript>10</eventSubscript>
        <eventField>field1</eventField>
      </eventTarget>
      <eventChanged/>
      <eventReports>
        <eventReport>
         <eventField>gah</eventField>
         <eventSubscript>10</eventSubscript>
        </eventReport>
      </eventReports>
    </event>
   </events>

4.7.6.1. Элемент <eventTarget>

Элемент <eventTarget> содержит информацию, указывающую поле в LFB, которое отслеживается для событий.

Элемент <eventTarget> содержит одно или множество элементов <eventField, за каждым из которых может следовать один или множество элементов <eventSubscript>. Каждый из этих двух элементов представляет текстовый эквивалент компоненты выбора пути в LFB.

Элемент <eventField> содержит имя компоненты в LFB или компоненты, встроенной в массив или структуру внутри LFB. Имя, используемое в <eventField>, должно указывать действительную компоненту в содержащем LFB контексте. Первым в элементе <eventTarget> должен быть элемент <eventField>. В приведенном ниже примере в качестве <eventField> используются 4 компоненты LFB — foo, goo, bar и gah.

В простом случае <eventField> указывает компоненту atomic. Этот случай показан в событии Foochanged. Элемент <eventField> служит также для указания сложных компонент, таких как массивы или структуры.

Определенное в примере первым событие Foochanged показывает, как скалярная компонента LFB (foo) может отслеживаться для инициирования событий.

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

События NewbarEntry, Gah11changed и Gah10field1 представляют мониторинг массивов bar и gah с разными деталями.

Если <eventField> указывает составную компоненту, может применяться дополнительный элемент <eventField> для уточнения пути к целевому элементу. Событие Goof1changed показывает применение второго <eventField> для указания на элемент f1 в структуре goo.

Если <eventField> указывает массив, применимы приведенные ниже правила.

• Элемент <eventSubscript> должен быть представлен как следующий элемент XML после <eventField>, указывающего элемент массива. Элементу <eventSubscript> недопустимо появляться иначе как после ссылки на массив, поскольку он имеет смысл только в этом контексте.

• Элемент <eventSubscript> содержит один из двух приведенных ниже вариантов.

  • Численное значение для указания применимости события к конкретному элементу массива (по индексу). Например, событие Gah11changed задает мониторинг элемента таблицы gah с индексом 11.

  • Предполагается, что наиболее вероятным будет использование событий, определенных для всех элементов массива (т. е. шаблон для всех значений индекса). В этом случае значением <eventSubscript> должно быть имя, а не число. Это же имя может использоваться в качестве значения <eventSubscript> в элементах <eventReport>, как описано ниже. An example of a wild card table index is shown in event NewBarentry where the <eventSubscript> value is named _barIndex_

• За элементом <eventField> может следовать <eventSubscript> для уточнения пути к целевому элементу (это похоже на использование <eventField> для уточнения пути в составной структуре, показанное в событии Goof1changed). Событие Gah10field1 в примере отслеживает изменения столбца field1 в таблице gah.

Следует подчеркнуть, что элемент <eventSubscript> в событии NewbarEntry не является именем компоненты. Это имя переменной для использования в элементах <eventReport> (параграф 4.7.6.3) определения данного класса LFB. Это имя должно отличаться от всех имен компонент, которые докустиму в <eventReport>.

4.7.6.2. Элемент <eventCondition>

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

<eventCreated/>

Целью должен быть массив, завершающийся указанным индексом. Событие генерируется при создании элемента в массиве, даже если это происходит по указанию CE. Условие <eventCreated/> показано в примере NewbarEntry.

<eventDeleted/>

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

<eventChanged/>

Событие генерируется при любом изменении целевой компоненты. Для двоичных компонент, таких как включение/выключение (up/down) это отражает смену состояния. Условие может применяться и с цифровыми атрибутами, когда триггером служит смена значения. Условие <eventChanged/> показано в примерах Foochanged, Gah11changed и Gah10field1.

<eventGreaterThan/>

Событие генерируется при превышении целевой компонентой порогового значения, являющегося свойством события.

<eventLessThan/>

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

4.7.6.3. Элемент <eventReports>

Элемент <eventReports> в <event> заявляет информацию, доставляемую элементом FE с уведомлением о событии.

Элемент <eventReports> содержит один или несколько элементов <eventReport>, содержащих части данных, сообщаемых классом LFB. Уведомление переносит данные как набор элементов <eventReport>, определенных в структуре. Синтаксис совпадает с синтаксисом <eventTarget> и использует элементы <eventField> и <eventSubscript> с применением тех же правил. Каждый элемент <eventReport> должен указывать компоненту класса LFB. Элементы <eventSubcript> могут содержать целые числа. Если они содержат имена, это должны быть имена из элементов <eventSubscript> цели события <eventTarget>. При выборе используется значение индекса, который указывает конкретный элемент, вызвавший событие. Это может служить для указания компоненты, вызвавшей событие, или ссылки на связанную информацию в параллельных таблицах.

В приведенном примере для события Foochanged отчет будет содержать значение foo. Для события NewbarEntry, связанного с компонентой LFB bar, которая является массивом, будут сообщаться два элемента, указанные двумя объявлениями <eventReport>.

• Первый элемент <eventReport> указывает добавление новой записи в таблицу bar. Напомним, что _barIndex_ объявлен как <eventTarget> <eventSubcript> для события и можно использовать имя вместо числа. Элемент <eventSubcript> предполагается шаблоном, которому соответствует любой индекс новой записи.

• Второй элемент <eventReport> включает значение компоненты LFB foo в момент создания новой записи в bar. Указание foo в этом случае приведено для демонстрации гибкости отчетов о событиях.

Структура отчетов о события создана для того, чтобы позволить разработчикам LFB задавать информацию, которая вероятно не известна заранее CE и вероятно потребуется CE для обработки события. Хотя структура позволяет указывать большие блоки информации (массив или составная структура целиком), делать это не рекомендуется. Кроме того, переменная ссылки/подписки в отчете содержит лишь малуя часть связанной с событием информации. Например, цепочки через поля индексов в таблице не поддерживаются. В общем случае механизм <eventReports> является оптимизацией для базовых ситуаций, позволяющей CE избавиться от необходимости запрашивать информацию, требуемую для того, чтобы понять событие. Он не представляет всю возможную информацию.

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

4.7.6.4. Управление событиями во время работы

Базовый обзор объявления событий LFB и работы с ними приведен в параграфе 3.2.5.

Элемент <eventTarget> обеспечивает дополнительные компоненты используемые в пути для ссылки на событие. Путь содержит baseID для событий, далее следует идентификатор конкретного события, а затем значения для каждого элемента <eventSubscript>, если они имеются в <eventTarget>.

Путь к событию будет однозначно указывать конкретный факт события в уведомлении о событии для CE. В приведенном выше примере (конец параграфа 4.7.6) уведомление с путем 7.7 однозначно указывает событие, вызванное изменением foo, а путь 7.9.100 однозначно указывает событие, вызванное созданием записи в таблице bar с индексом 100.

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

В дополнение к идентификации источников событий CE использует путь к событиям для активации во время работы элементов управления на основании свойств событий (параграф 4.8.5) с использованием операции SET-PROP, определенной в протоколе ForCES [RFC5810].

Для того, чтобы активизировать генерацию событий на FE устройство CE передает FE сообщение SET-PROP, указывающее событие и его регистрационное свойство с любым префиксом пути к событию. Таким образом, для события NewbarEntry, определенного выше сообщение SET-PROP с путем 7.9 будет подписывать CE на все факты событий, связанных с любй записью в таблице bar. Это особенно полезно для условий <eventCreated/> и <eventDestroyed/> в таблицах. События, использующие эти условия, обычно будут определяться с последовательностью полей/индексов, указывающей массив и завершающейся елементом <eventSubscript>. Таким образом, уведомление о событии будет указывать созданный или уничтоженный элемент массива. Обычно подписка будет выполняться для массива, а не для его конкретноо элемента, поэтому будет применяться более короткий путь.

В приведенном примере подписка 7.8 предполагает получение всех объявленных событий из таблицы bar, подписка 7.8.100 означает получение уведомлений о создании в таблице записи с индексом 100.

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

4.7.7. Элемент <description> для рабочей спецификации LFB

Элемент <description> в <LFBClass> содержит неструктурированный (в смысле XML) текст, описывающий LFB для человека.

4.8. Свойства

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

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

4.8.1. Базовые свойства

Определение базовых свойств вместе со скаляром dataTypeDef для доступности приведено ниже. Отметим, что доступ к информации о свойствах обычно разрешен лишь в режиме read-only.

                <dataTypeDef>
                  <name>accessPermissionValues</name>
                  <synopsis>
                    Возможные значения прав доступа к компоненте
                  </synopsis>
                  <atomic>
                    <baseType>uchar</baseType>
                    <specialValues>
                      <specialValue value="0">
                        <name>None</name>
                        <synopsis>Доступ запрещен</synopsis>
                      </specialValue>
                       <specialValue value="1">
                        <name> Read-Only </name>
                        <synopsis>Доступ только для чтения</synopsis>
                      </specialValue>
                      <specialValue value="2">
                        <name>Write-Only</name>
                        <synopsis>
                          Компонента МОЖЕТ записываться, но чтение недоступно
                        </synopsis>
                      </specialValue>
                      <specialValue value="3">
                        <name>Read-Write</name>
                        <synopsis>
                          ВОЗМОЖНО чтение и запись компоненты
                        </synopsis>
                      </specialValue>
                    </specialValues>
                  </atomic>
                </dataTypeDef>
                <dataTypeDef>
                  <name>baseElementProperties</name>
                  <synopsis>Базовые свойства, доступность</synopsis>
                  <struct>
                    <component componentID="1">
                      <name>accessibility</name>
                      <synopsis>
                          Компоненты не существует, чтение и
                          запись невозможны
                      </synopsis>
                      <typeRef>accessPermissionValues</typeRef>
                    </component>
                  </struct>
                </dataTypeDef>

4.8.2. Свойства массива

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

         <dataTypeDef>
           <name>arrayElementProperties</name>
           <synopsis>Определение свойств элементов массива</synopsis>
           <struct>
             <derivedFrom>baseElementProperties</derivedFrom>
             <component componentID="2">
               <name>entryCount</name>
               <synopsis>Число элементов в массиве</synopsis>
               <typeRef>uint32</typeRef>
             </component>
             <component componentID="3">
               <name>highestUsedSubscript</name>
               <synopsis>Последний использованный индекс в массиве</synopsis>
               <typeRef>uint32</typeRef>
             </component>
             <component componentID="4">
               <name>firstUnusedSubscript</name>
               <synopsis>
                 Индекс первого неиспользуемого элемента массива
               </synopsis>
               <typeRef>uint32</typeRef>
             </component>
           </struct>
         </dataTypeDef>

4.8.3. Свойства строки

Свойства строки задают реальный размер в октетах и максимальную длину элемента. Максимальный размер включен потому, что реализации FE могут ограничивать размер строк сверх заданного классом LFB предела.

           <dataTypeDef>
             <name>stringElementProperties</name>
             <synopsis>Определение свойств строкового элемента</synopsis>
             <struct>
               <derivedFrom>baseElementProperties</derivedFrom>
               <component componentID="2">
                 <name>stringLength</name>
                 <synopsis>Число октетов в строке</synopsis>
                 <typeRef>uint32</typeRef>
               </component>
               <component componentID="3">
                 <name>maxStringLength</name>
                 <synopsis>
                   Максимальное число октетов в строке
                   </synopsis>
                 <typeRef>uint32</typeRef>
               </component>
             </struct>
           </dataTypeDef>

4.8.4. Свойства строки октетов

Свойства octetstring задают реальный и максимальный размер, посокольку реализации FE могут ограничивать сверх заданного определением класса LFB предела.

              <dataTypeDef>
                <name>octetstringElementProperties</name>
                <synopsis>Определеение свойств элемента octetstring
                </synopsis>
                <struct>
                  <derivedFrom>baseElementProperties</derivedFrom>
                  <component componentID="2">
                    <name>octetstringLength</name>
                    <synopsis>Число октетов в octetstring</synopsis>
                    <typeRef>uint32</typeRef>
                  </component>
                  <component componentID="3">
                    <name>maxOctetstringLength</name>
                    <synopsis>
                      Максимальное число октетов в octetstring
                    </synopsis>
                    <typeRef>uint32</typeRef>
                  </component>
                </struct>
              </dataTypeDef>

4.8.5. Свойства событий

Свойства событий (обычно) добавляют 3 доступных для записи поля. Одно из них является полем подписки, значение 0 в котором указывает, что уведомление не создается. Отличное от 0 значение (обычно 1) задает генерацию уведомлений. Поле гистерезиса служит для подавления уведомлений в результате колебаний около условного значения, как описано ниже (параграф 4.8.5.2). Поле порога используется в условиях <eventGreaterThan/> и <eventLessThan/>, задавая значение для сравнений с целью события. Использование свойства позволяет CE задать интересующий уровень. Элементы FE, не поддерживающие порогов для событий, будут делать поле read-only.

            <dataTypeDef>
              <name>eventElementProperties</name>
              <synopsis>Определение свойств события</synopsis>
              <struct>
                <derivedFrom>baseElementProperties</derivedFrom>
                <component componentID="2">
                  <name>registration</name>
                  <synopsis>
                    Имеется CE, зарегистрированный для уведомлений о событии
                  </synopsis>
                  <typeRef>uint32</typeRef>
                </component>
                <component componentID="3">
                  <name>threshold</name>
                  <synopsis>Значение для сравнения в условии</synopsis>
                  <optional/>
                  <typeRef>uint32</typeRef>
                </component>
                <component componentID="4">
                  <name>eventHysteresis</name>
                  <synopsis>Зона подавления рекурсивных уведомлений</synopsis>
                  <optional/>
                  <typeRef>uint32</typeRef>
                </component>
                <component componentID="5">
                  <name>eventCount</name>
                  <synopsis>Число уведомлений для подавления</synopsis>
                  <optional/>
                  <typeRef>uint32</typeRef>
                </component>
                <component componentID="6">
                  <name>eventInterval</name>
                  <synopsis>Интервал между уведомлениями в мсек</synopsis>
                  <optional/>
                  <typeRef>uint32</typeRef>
                </component>
              </struct>
            </dataTypeDef>

4.8.5.1. Базовая фильтрация событий

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

В настоящее время определены три разных переменных для условий фильтрации — eventCount, eventInterval и eventHysteresis. Установка значения 0 (принято по умолчанию) отключает проверку соответствующего условия.

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

Примером взаимодействия условий может служить событие с eventCount = 5 и eventInterval = 500 мсек. Предположим, что элемент FE обнаружил всплеск генерации таких уведомлений. Первое событие вызвало передачу уведомления CE. Затем, если быстро (менее 0,5 сек) произошли еще 4 события, они не вызовут уведомлений. Если обнаружены 2 дополнительных события, второе приведет к передаче уведомления. Если прошло более 500 мсек после уведомления и обнаружено событие, это приведет к передаче уведомления. В любом случае счетчик и временной интервал подавления сбрасываются, независимо от условия, вызвавшего генерацию уведомления.

4.8.5.2. Фильтрация гистерезиса событий

События с численными условиями могут иметь фильтр гистерезиса. Уровень гистерезиса определяется свойством события. Это позволяет элементу FE уведомлять CE о применении гистерезиса и в случае выбора FE может разрешать CE менять гистерезис. Это применимо для <eventChanged/> с численным полем, а также для <eventGreaterThan/> и <eventLessThan/>. Содержимым элемента <variance> является число. При поддержке гистерезиса элемент FE должен отслеживать значение элемента и гарантировать, что условие не выполняется по крайней мере в части гистерезиса из свойства события. Для гистерезиса V выполняется указанное ниже.

• Если при условии <eventChanged/> последнее уведомление было для значения X, то уведомление <changed/> недопустимо создавать, пока значение не достигнет X +/- V.

• Для условия <eventGreaterThan/> с порогом T после генерации хотя бы одного уведомления недопустимо создавать новые, пока поле сначала не станет меньше или равно T — V, а затем снова превысит T.

• Для условия <eventLessThan/> с порогом T после генерации хотя бы одного уведомления недопустимо создавать новые, пока поле сначала не станет больше или равно T + V, а затем снова меньше T.

4.8.5.3. Фильтрация счета событий

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

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

4.8.5.4. Фильтрация времени событий

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

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

4.8.6. Свойства псевдонимов

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

          <dataTypeDef>
            <name>aliasElementProperties</name>
            <synopsis>Определение свойств псевдонима</synopsis>
            <struct>
              <derivedFrom>baseElementProperties</derivedFrom>
              <component componentID="2">
                <name>targetLFBClass</name>
                <synopsis>Идентификатор класса для цели псевдонима</synopsis>
                <typeRef>uint32</typeRef>
              </component>
              <component componentID="3">
                <name>targetLFBInstance</name>
                <synopsis>Идентификатор экземпляра для цели псевдонима</synopsis>
                <typeRef>uint32</typeRef>
              </component>
              <component componentID="4">
                <name>targetComponentPath</name>
                <synopsis>
                  Путь к составной цели. Каждые 4 элемента
                  считываются как 1 элемент пути с использованием
                  конструкции path протокола ForCES [RFC5810].
                </synopsis>
                <typeRef>octetstring[128]</typeRef>
              </component>
            </struct>
          </dataTypeDef>

4.9. Схема XML для документов LFB Class Library

      <?xml version="1.0" encoding="UTF-8"?>
      <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
       xmlns="urn:ietf:params:xml:ns:forces:lfbmodel:1.0"
       xmlns:lfb="urn:ietf:params:xml:ns:forces:lfbmodel:1.0"
       targetNamespace="urn:ietf:params:xml:ns:forces:lfbmodel:1.0"
       attributeFormDefault="unqualified"
       elementFormDefault="qualified">
      <xsd:annotation>
        <xsd:documentation xml:lang="en">
        Schema for Defining LFB Classes and associated types (frames,
        data types for LFB attributes, and metadata).
        </xsd:documentation>
      </xsd:annotation>
      <xsd:element name="description" type="xsd:string"/>
      <xsd:element name="synopsis" type="xsd:string"/>
      <!-- Корневой элемент документа: LFBLibrary -->
      <xsd:element name="LFBLibrary">
        <xsd:complexType>
          <xsd:sequence>
            <xsd:element ref="description" minOccurs="0"/>
            <xsd:element name="load" type="loadType" minOccurs="0"
                      maxOccurs="unbounded"/>
         <xsd:element name="frameDefs" type="frameDefsType"
                      minOccurs="0"/>
         <xsd:element name="dataTypeDefs" type="dataTypeDefsType"
                      minOccurs="0"/>
         <xsd:element name="metadataDefs" type="metadataDefsType"
                      minOccurs="0"/>
         <xsd:element name="LFBClassDefs" type="LFBClassDefsType"
                      minOccurs="0"/>
       </xsd:sequence>
       <xsd:attribute name="provides" type="xsd:Name" use="required"/>
     </xsd:complexType>
     <!-- Ограничения уникальности -->
     <xsd:key name="frame">
      <xsd:selector xpath="lfb:frameDefs/lfb:frameDef"/>
       <xsd:field xpath="lfb:name"/>
     </xsd:key>
     <xsd:key name="dataType">
      <xsd:selector xpath="lfb:dataTypeDefs/lfb:dataTypeDef"/>
       <xsd:field xpath="lfb:name"/>
     </xsd:key>
     <xsd:key name="metadataDef">
       <xsd:selector xpath="lfb:metadataDefs/lfb:metadataDef"/>
       <xsd:field xpath="lfb:name"/>
     </xsd:key>
     <xsd:key name="LFBClassDef">
       <xsd:selector xpath="lfb:LFBClassDefs/lfb:LFBClassDef"/>
       <xsd:field xpath="lfb:name"/>
     </xsd:key>
   </xsd:element>
   <xsd:complexType name="loadType">
     <xsd:attribute name="library" type="xsd:Name" use="required"/>
     <xsd:attribute name="location" type="xsd:anyURI" use="optional"/>
   </xsd:complexType>
   <xsd:complexType name="frameDefsType">
     <xsd:sequence>
       <xsd:element name="frameDef" maxOccurs="unbounded">
         <xsd:complexType>
        <xsd:sequence>
             <xsd:element name="name" type="xsd:NMTOKEN"/>
             <xsd:element ref="synopsis"/>
             <xsd:element ref="description" minOccurs="0"/>
           </xsd:sequence>
         </xsd:complexType>
       </xsd:element>
     </xsd:sequence>
   </xsd:complexType>
   <xsd:complexType name="dataTypeDefsType">
     <xsd:sequence>
          <xsd:element name="dataTypeDef" maxOccurs="unbounded">
            <xsd:complexType>
              <xsd:sequence>
                <xsd:element name="name" type="xsd:NMTOKEN"/>
                <xsd:element ref="synopsis"/>
                <xsd:element ref="description" minOccurs="0"/>
                <xsd:group ref="typeDeclarationGroup"/>
              </xsd:sequence>
            </xsd:complexType>
          </xsd:element>
        </xsd:sequence>
      </xsd:complexType>
      <!--
         Предопределенными (встроенными) неделимыми типа данных являются
             char, uchar, int16, uint16, int32, uint32, int64, uint64,
             string[N], string, byte[N], boolean, octetstring[N],
             float32, float64
      -->
      <xsd:group name="typeDeclarationGroup">
        <xsd:choice>
          <xsd:element name="typeRef" type="typeRefNMTOKEN"/>
          <xsd:element name="atomic" type="atomicType"/>
          <xsd:element name="array" type="arrayType"/>
          <xsd:element name="struct" type="structType"/>
          <xsd:element name="union" type="structType"/>
          <xsd:element name="alias" type="typeRefNMTOKEN"/>
        </xsd:choice>
      </xsd:group>
      <xsd:simpleType name="typeRefNMTOKEN">
        <xsd:restriction base="xsd:token">
          <xsd:pattern value="\c+"/>
          <xsd:pattern value="string\[\d+\]"/>
          <xsd:pattern value="byte\[\d+\]"/>
          <xsd:pattern value="octetstring\[\d+\]"/>
        </xsd:restriction>
      </xsd:simpleType>
      <xsd:complexType name="atomicType">
        <xsd:sequence>
          <xsd:element name="baseType" type="typeRefNMTOKEN"/>
          <xsd:element name="rangeRestriction"
                       type="rangeRestrictionType" minOccurs="0"/>
          <xsd:element name="specialValues" type="specialValuesType"
                       minOccurs="0"/>
        </xsd:sequence>
      </xsd:complexType>
      <xsd:complexType name="rangeRestrictionType">
        <xsd:sequence>
          <xsd:element name="allowedRange" maxOccurs="unbounded">
            <xsd:complexType>
            <xsd:attribute name="min" type="xsd:integer" use="required"/>
            <xsd:attribute name="max" type="xsd:integer" use="required"/>
         </xsd:complexType>
       </xsd:element>
     </xsd:sequence>
   </xsd:complexType>
   <xsd:complexType name="specialValuesType">
     <xsd:sequence>
       <xsd:element name="specialValue" maxOccurs="unbounded">
         <xsd:complexType>
           <xsd:sequence>
             <xsd:element name="name" type="xsd:NMTOKEN"/>
             <xsd:element ref="synopsis"/>
           </xsd:sequence>
           <xsd:attribute name="value" type="xsd:token"/>
         </xsd:complexType>
       </xsd:element>
     </xsd:sequence>
   </xsd:complexType>
   <xsd:complexType name="arrayType">
     <xsd:sequence>
       <xsd:group ref="typeDeclarationGroup"/>
       <xsd:element name="contentKey" minOccurs="0"
                    maxOccurs="unbounded">
         <xsd:complexType>
           <xsd:sequence>
             <xsd:element name="contentKeyField" maxOccurs="unbounded"
                          type="xsd:string"/>
           </xsd:sequence>
           <xsd:attribute name="contentKeyID" use="required"
                          type="xsd:integer"/>
         </xsd:complexType>
         <!-- Заявление уникальных идентификаторов ключей -->
         <xsd:key name="contentKeyID">
           <xsd:selector xpath="lfb:contentKey"/>
           <xsd:field xpath="@contentKeyID"/>
         </xsd:key>
       </xsd:element>
     </xsd:sequence>
     <xsd:attribute name="type" use="optional"
                    default="variable-size">
       <xsd:simpleType>
         <xsd:restriction base="xsd:string">
           <xsd:enumeration value="fixed-size"/>
           <xsd:enumeration value="variable-size"/>
         </xsd:restriction>
       </xsd:simpleType>
        </xsd:attribute>
        <xsd:attribute name="length" type="xsd:integer" use="optional"/>
        <xsd:attribute name="maxLength" type="xsd:integer"
                       use="optional"/>
      </xsd:complexType>
      <xsd:complexType name="structType">
        <xsd:sequence>
          <xsd:element name="derivedFrom" type="typeRefNMTOKEN"
                       minOccurs="0"/>
          <xsd:element name="component" maxOccurs="unbounded">
            <xsd:complexType>
              <xsd:sequence>
                <xsd:element name="name" type="xsd:NMTOKEN"/>
                <xsd:element ref="synopsis"/>
                <xsd:element ref="description" minOccurs="0"/>
                <xsd:element name="optional" minOccurs="0"/>
                <xsd:group ref="typeDeclarationGroup"/>
              </xsd:sequence>
              <xsd:attribute name="componentID" use="required"
                             type="xsd:unsignedInt"/>
            </xsd:complexType>
            <!-- Объявление ключей для уникальности componentID в структуре
            -->
            <xsd:key name="structComponentID">
              <xsd:selector xpath="lfb:component"/>
              <xsd:field xpath="@componentID"/>
            </xsd:key>
          </xsd:element>
        </xsd:sequence>
      </xsd:complexType>
      <xsd:complexType name="metadataDefsType">
        <xsd:sequence>
          <xsd:element name="metadataDef" maxOccurs="unbounded">
            <xsd:complexType>
              <xsd:sequence>
                <xsd:element name="name" type="xsd:NMTOKEN"/>
                <xsd:element ref="synopsis"/>
                <xsd:element name="metadataID" type="xsd:integer"/>
                <xsd:element ref="description" minOccurs="0"/>
                <xsd:choice>
                  <xsd:element name="typeRef" type="typeRefNMTOKEN"/>
                  <xsd:element name="atomic" type="atomicType"/>
                </xsd:choice>
              </xsd:sequence>
            </xsd:complexType>
          </xsd:element>
        </xsd:sequence>
      </xsd:complexType>
      <xsd:complexType name="LFBClassDefsType">
        <xsd:sequence>
          <xsd:element name="LFBClassDef" maxOccurs="unbounded">
            <xsd:complexType>
              <xsd:sequence>
                <xsd:element name="name" type="xsd:NMTOKEN"/>
                <xsd:element ref="synopsis"/>
                <xsd:element name="version" type="versionType"/>
                <xsd:element name="derivedFrom" type="xsd:NMTOKEN"
                             minOccurs="0"/>
                <xsd:element name="inputPorts" type="inputPortsType"
                             minOccurs="0"/>
                <xsd:element name="outputPorts" type="outputPortsType"
                             minOccurs="0"/>
                <xsd:element name="components" type="LFBComponentsType"
                             minOccurs="0"/>
                <xsd:element name="capabilities"
                             type="LFBCapabilitiesType" minOccurs="0"/>
                <xsd:element name="events"
                             type="eventsType" minOccurs="0"/>
                <xsd:element ref="description" minOccurs="0"/>
              </xsd:sequence>
              <xsd:attribute name="LFBClassID" use="required"
                             type="xsd:unsignedInt"/>
            </xsd:complexType>
            <!-- Ограничение ключей для обеспечения уникальности имен
                 атрибутов в классе
            -->
            <xsd:key name="components">
              <xsd:selector xpath="lfb:components/lfb:component"/>
              <xsd:field xpath="lfb:name"/>
            </xsd:key>
            <xsd:key name="capabilities">
              <xsd:selector xpath="lfb:capabilities/lfb:capability"/>
              <xsd:field xpath="lfb:name"/>
            </xsd:key>
            <xsd:key name="componentIDs">
              <xsd:selector xpath="lfb:components/lfb:component"/>
              <xsd:field xpath="@componentID"/>
            </xsd:key>
            <xsd:key name="capabilityIDs">
              <xsd:selector xpath="lfb:capabilities/lfb:capability"/>
              <xsd:field xpath="@componentID"/>
            </xsd:key>
          </xsd:element>
        </xsd:sequence>
      </xsd:complexType>
    <xsd:simpleType name="versionType">
      <xsd:restriction base="xsd:NMTOKEN">
        <xsd:pattern value="[1-9][0-9]*\.([1-9][0-9]*|0)"/>
      </xsd:restriction>
    </xsd:simpleType>
    <xsd:complexType name="inputPortsType">
      <xsd:sequence>
        <xsd:element name="inputPort" type="inputPortType"
                     maxOccurs="unbounded"/>
      </xsd:sequence>
    </xsd:complexType>
    <xsd:complexType name="inputPortType">
      <xsd:sequence>
        <xsd:element name="name" type="xsd:NMTOKEN"/>
        <xsd:element ref="synopsis"/>
        <xsd:element name="expectation" type="portExpectationType"/>
        <xsd:element ref="description" minOccurs="0"/>
      </xsd:sequence>
      <xsd:attribute name="group" type="xsd:boolean" use="optional"
                     default="0"/>
    </xsd:complexType>
    <xsd:complexType name="portExpectationType">
      <xsd:sequence>
        <xsd:element name="frameExpected" minOccurs="0">
          <xsd:complexType>
            <xsd:sequence>
            <!-- Ссылка ref должна указывать определенный тип кадра -->
            <xsd:element name="ref" type="xsd:string"
                           maxOccurs="unbounded"/>
            </xsd:sequence>
          </xsd:complexType>
        </xsd:element>
        <xsd:element name="metadataExpected" minOccurs="0">
          <xsd:complexType>
            <xsd:choice maxOccurs="unbounded">
              <!-- Ссылка ref должна указывать имя определенных метаданных -->

              <xsd:element name="ref" type="metadataInputRefType"/>
              <xsd:element name="one-of"
                           type="metadataInputChoiceType"/>
            </xsd:choice>
          </xsd:complexType>
        </xsd:element>
      </xsd:sequence>
    </xsd:complexType>
    <xsd:complexType name="metadataInputChoiceType">
      <xsd:choice minOccurs="2" maxOccurs="unbounded">
        <!-- Ссылка ref должна указывать имя определенных метаданных -->
        <xsd:element name="ref" type="xsd:NMTOKEN"/>
        <xsd:element name="one-of" type="metadataInputChoiceType"/>
        <xsd:element name="metadataSet" type="metadataInputSetType"/>
      </xsd:choice>
    </xsd:complexType>
    <xsd:complexType name="metadataInputSetType">
      <xsd:choice minOccurs="2" maxOccurs="unbounded">
        <!-- Ссылка ref должна указывать имя определенных метаданных -->
        <xsd:element name="ref" type="metadataInputRefType"/>
        <xsd:element name="one-of" type="metadataInputChoiceType"/>
      </xsd:choice>
    </xsd:complexType>
    <xsd:complexType name="metadataInputRefType">
      <xsd:simpleContent>
        <xsd:extension base="xsd:NMTOKEN">
          <xsd:attribute name="dependency" use="optional"
                         default="required">
            <xsd:simpleType>
              <xsd:restriction base="xsd:string">
                <xsd:enumeration value="required"/>
                <xsd:enumeration value="optional"/>
              </xsd:restriction>
            </xsd:simpleType>
          </xsd:attribute>
          <xsd:attribute name="defaultValue" type="xsd:token"
                         use="optional"/>
        </xsd:extension>
      </xsd:simpleContent>
    </xsd:complexType>
    <xsd:complexType name="outputPortsType">
      <xsd:sequence>
        <xsd:element name="outputPort" type="outputPortType"
                     maxOccurs="unbounded"/>
      </xsd:sequence>
    </xsd:complexType>
    <xsd:complexType name="outputPortType">
      <xsd:sequence>
        <xsd:element name="name" type="xsd:NMTOKEN"/>
        <xsd:element ref="synopsis"/>
        <xsd:element name="product" type="portProductType"/>
        <xsd:element ref="description" minOccurs="0"/>
      </xsd:sequence>
      <xsd:attribute name="group" type="xsd:boolean" use="optional"
                     default="0"/>
    </xsd:complexType>
    <xsd:complexType name="portProductType">
      <xsd:sequence>
        <xsd:element name="frameProduced">
         <xsd:complexType>
            <xsd:sequence>
              <!-- Ссылка ref должна указывать определенный тип кадра
                   -->
                  <xsd:element name="ref" type="xsd:NMTOKEN"
                             maxOccurs="unbounded"/>
              </xsd:sequence>
            </xsd:complexType>
          </xsd:element>
          <xsd:element name="metadataProduced" minOccurs="0">
            <xsd:complexType>
              <xsd:choice maxOccurs="unbounded">
                <!-- Ссылка ref должна указывать имя определенных метаданных
                -->
                <xsd:element name="ref" type="metadataOutputRefType"/>
                <xsd:element name="one-of"
                             type="metadataOutputChoiceType"/>
              </xsd:choice>
            </xsd:complexType>
          </xsd:element>
        </xsd:sequence>
      </xsd:complexType>
      <xsd:complexType name="metadataOutputChoiceType">
        <xsd:choice minOccurs="2" maxOccurs="unbounded">
          <!-- Ссылка ref должна указывать имя определенных метаданных -->
          <xsd:element name="ref" type="xsd:NMTOKEN"/>
          <xsd:element name="one-of" type="metadataOutputChoiceType"/>
          <xsd:element name="metadataSet" type="metadataOutputSetType"/>
        </xsd:choice>
      </xsd:complexType>
      <xsd:complexType name="metadataOutputSetType">
        <xsd:choice minOccurs="2" maxOccurs="unbounded">
          <!-- Ссылка ref должна указывать имя определенных метаданных -->
          <xsd:element name="ref" type="metadataOutputRefType"/>
          <xsd:element name="one-of" type="metadataOutputChoiceType"/>
        </xsd:choice>
      </xsd:complexType>
      <xsd:complexType name="metadataOutputRefType">
        <xsd:simpleContent>
          <xsd:extension base="xsd:NMTOKEN">
            <xsd:attribute name="availability" use="optional"
                           default="unconditional">
              <xsd:simpleType>
                <xsd:restriction base="xsd:string">
                  <xsd:enumeration value="unconditional"/>
                  <xsd:enumeration value="conditional"/>
                </xsd:restriction>
              </xsd:simpleType>
            </xsd:attribute>
          </xsd:extension>
        </xsd:simpleContent>
      </xsd:complexType>
      <xsd:complexType name="LFBComponentsType">
        <xsd:sequence>
          <xsd:element name="component" maxOccurs="unbounded">
            <xsd:complexType>
              <xsd:sequence>
                <xsd:element name="name" type="xsd:NMTOKEN"/>
                <xsd:element ref="synopsis"/>
                <xsd:element ref="description" minOccurs="0"/>
                <xsd:element name="optional" minOccurs="0"/>
                <xsd:group ref="typeDeclarationGroup"/>
                <xsd:element name="defaultValue" type="xsd:token"
                             minOccurs="0"/>
              </xsd:sequence>
              <xsd:attribute name="access" use="optional"
                             default="read-write">
                <xsd:simpleType>
                  <xsd:list itemType="accessModeType"/>
                </xsd:simpleType>
              </xsd:attribute>
              <xsd:attribute name="componentID" use="required"
                             type="xsd:unsignedInt"/>
            </xsd:complexType>
          </xsd:element>
        </xsd:sequence>
      </xsd:complexType>
      <xsd:simpleType name="accessModeType">
        <xsd:restriction base="xsd:NMTOKEN">
          <xsd:enumeration value="read-only"/>
          <xsd:enumeration value="read-write"/>
          <xsd:enumeration value="write-only"/>
          <xsd:enumeration value="read-reset"/>
          <xsd:enumeration value="trigger-only"/>
        </xsd:restriction>
      </xsd:simpleType>
      <xsd:complexType name="LFBCapabilitiesType">
        <xsd:sequence>
          <xsd:element name="capability" maxOccurs="unbounded">
            <xsd:complexType>
              <xsd:sequence>
                <xsd:element name="name" type="xsd:NMTOKEN"/>
                <xsd:element ref="synopsis"/>
                <xsd:element ref="description" minOccurs="0"/>
                <xsd:element name="optional" minOccurs="0"/>
                <xsd:group ref="typeDeclarationGroup"/>
              </xsd:sequence>
              <xsd:attribute name="componentID" use="required"
                             type="xsd:integer"/>
            </xsd:complexType>
          </xsd:element>
        </xsd:sequence>
      </xsd:complexType>
      <xsd:complexType name="eventsType">
        <xsd:sequence>
          <xsd:element name="event" maxOccurs="unbounded">
            <xsd:complexType>
              <xsd:sequence>
                <xsd:element name="name" type="xsd:NMTOKEN"/>
                <xsd:element ref="synopsis"/>
                <xsd:element name="eventTarget" type="eventPathType"/>
                <xsd:element ref="eventCondition"/>
                <xsd:element name="eventReports" type="eventReportsType"
                             minOccurs="0"/>
                <xsd:element ref="description" minOccurs="0"/>
              </xsd:sequence>
              <xsd:attribute name="eventID" use="required"
                             type="xsd:integer"/>
            </xsd:complexType>
          </xsd:element>
        </xsd:sequence>
        <xsd:attribute name="baseID" type="xsd:integer"
                       use="optional"/>
      </xsd:complexType>
      <!-- Группа подстановки для условий события -->
      <xsd:element name="eventCondition" abstract="true"/>
      <xsd:element name="eventCreated"
                  substitutionGroup="eventCondition"/>
      <xsd:element name="eventDeleted"
                  substitutionGroup="eventCondition"/>
      <xsd:element name="eventChanged"
                  substitutionGroup="eventCondition"/>
      <xsd:element name="eventGreaterThan"
                  substitutionGroup="eventCondition"/>
      <xsd:element name="eventLessThan"
                  substitutionGroup="eventCondition"/>
      <xsd:complexType name="eventPathType">
        <xsd:sequence>
          <xsd:element ref="eventPathPart" maxOccurs="unbounded"/>
        </xsd:sequence>
      </xsd:complexType>
      <!-- Группа подстановки для частей пути к событию -->
      <xsd:element name="eventPathPart" type="xsd:string"
                   abstract="true"/>
      <xsd:element name="eventField" type="xsd:string"
                   substitutionGroup="eventPathPart"/>
      <xsd:element name="eventSubscript" type="xsd:string"
                   substitutionGroup="eventPathPart"/>
      <xsd:complexType name="eventReportsType">
        <xsd:sequence>
          <xsd:element name="eventReport" type="eventPathType"
                       maxOccurs="unbounded"/>
        </xsd:sequence>
      </xsd:complexType>
      <xsd:simpleType name="booleanType">
        <xsd:restriction base="xsd:string">
          <xsd:enumeration value="0"/>
          <xsd:enumeration value="1"/>
        </xsd:restriction>
      </xsd:simpleType>
      </xsd:schema>

5. Компоненты и возможности FE

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

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

Чтобы сделать информацию FE легкодоступной, она представлена в LFB. Этот блок LFB имеет класс FEObject с идентификатором LFBClassID = 1. В FE будет присутствовать лишь один экземпляр этого класса и идентификатор экземпляра в протоколе будет иметь значение 1. таким образом, ссылаясь на компоненты class:1, instance:1, CE может получить общую инормацию о FE. Класс LFB FEObject описан в этом разделе.

Будет также класс LFB FEProtocol, для которого зарезервирован идентификатор LFBClassID = 2. Этот класс также будет иметь единственный экземпляр, а его детали определены в спецификации протокола ForCES [RFC5810].

5.1. XML для определения класса FEObject

          <?xml version="1.0" encoding="UTF-8"?>
          <LFBLibrary xmlns="urn:ietf:params:xml:ns:forces:lfbmodel:1.0"
            xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
            provides="FEObject">
            <dataTypeDefs>
              <dataTypeDef>
                <name>LFBAdjacencyLimitType</name>
                <synopsis>Описание Adjacent LFB</synopsis>
                <struct>
                  <component componentID="1">
                    <name>NeighborLFB</name>
                    <synopsis>Идентификатор для данного класса LFB</synopsis>
                    <typeRef>uint32</typeRef>
                  </component>
                  <component componentID="2">
                    <name>ViaPorts</name>
                    <synopsis>
                      Порты, к которым можно подключаться
                    </synopsis>
                    <array type="variable-size">
                      <typeRef>string</typeRef>
                    </array>
                  </component>
                </struct>
              </dataTypeDef>
              <dataTypeDef>
                <name>PortGroupLimitType</name>
                <synopsis>
                  Предельное число портов в данной группе
                </synopsis>
                <struct>
                  <component componentID="1">
                    <name>PortGroupName</name>
                    <synopsis>Имя группы</synopsis>
                    <typeRef>string</typeRef>
                  </component>
                  <component componentID="2">
                    <name>MinPortCount</name>
                    <synopsis>Минимальное число портов</synopsis>
                    <optional/>
                    <typeRef>uint32</typeRef>
                  </component>
                  <component componentID="3">
                    <name>MaxPortCount</name>
                    <synopsis>Максимальное число портов</synopsis>
                    <optional/>
                    <typeRef>uint32</typeRef>
                  </component>
                </struct>
              </dataTypeDef>
              <dataTypeDef>
                <name>SupportedLFBType</name>
                <synopsis>запись таблицы для поддерживаемых LFB</synopsis>
                <struct>
                  <component componentID="1">
                    <name>LFBName</name>
                    <synopsis>Имя поддерживаемого класса LFB</synopsis>
                    <typeRef>string</typeRef>
                  </component>
                  <component componentID="2">
                    <name>LFBClassID</name>
                    <synopsis>Идентификатор поддерживаемого класса LFB</synopsis>
                    <typeRef>uint32</typeRef>
                  </component>
                  <component componentID="3">
                    <name>LFBVersion</name>
                    <synopsis>Версия класса LFB, используемого этим FE.</synopsis>
                    <typeRef>string</typeRef>
                  </component>
                  <component componentID="4">
                    <name>LFBOccurrenceLimit</name>
                    <synopsis>
                      Максимальое число экземпляров данного класса LFB
                    </synopsis>
                    <optional/>
                    <typeRef>uint32</typeRef>
                  </component>
                  <!-- Для каждой группы указывается допустимое число портов
                  -->
                  <component componentID="5">
                    <name>PortGroupLimits</name>
                    <synopsis>Таблица пределов групп портов</synopsis>
                    <optional/>
                    <array type="variable-size">
                      <typeRef>PortGroupLimitType</typeRef>
                    </array>
                  </component>
        <!-- Классы LFB, за которыми может следовать именованный LFB Class -->
                  <component componentID="6">
                    <name>CanOccurAfters</name>
                    <synopsis>
                      Список классов LFB, за которыми может следовать этот класс
                    </synopsis>
                    <optional/>
                    <array type="variable-size">
                      <typeRef>LFBAdjacencyLimitType</typeRef>
                    </array>
                  </component>
        <!-- Классы LFB, которые могут следовать за именованным LFB Class -->
                  <component componentID="7">
                    <name>CanOccurBefores</name>
                    <synopsis>
                      Список классов LFB, которые могут следовать за этим классом
                    </synopsis>
                    <optional/>
                    <array type="variable-size">
                      <typeRef>LFBAdjacencyLimitType</typeRef>
                    </array>
                  </component>
                  <component componentID="8">
                    <name>UseableParentLFBClasses</name>
                    <synopsis>
                      Список классов LFB, из которых унаследован этот класс
                      и которые FE разрешает для ссылок на экземпляры этого
                      класса.
                    </synopsis>
                    <optional/>
                    <array type="variable-size">
                      <typeRef>uint32</typeRef>
                    </array>
                  </component>
                </struct>
              </dataTypeDef>
              <dataTypeDef>
                <name>FEStateValues</name>
                <synopsis>Возможные значения статуса</synopsis>
                <atomic>
                  <baseType>uchar</baseType>
                  <specialValues>
                    <specialValue value="0">
                      <name>AdminDisable</name>
                      <synopsis>FE административно запрещен</synopsis>
                    </specialValue>
                    <specialValue value="1">
                      <name>OperDisable</name>
                      <synopsis>FE исключен из работы</synopsis>
                    </specialValue>
                    <specialValue value="2">
                      <name>OperEnable</name>
                      <synopsis>FE работает</synopsis>
                    </specialValue>
                  </specialValues>
                </atomic>
              </dataTypeDef>
              <dataTypeDef>
                <name>FEConfiguredNeighborType</name>
                <synopsis>Детали соседей FE</synopsis>
                <struct>
                  <component componentID="1">
                    <name>NeighborID</name>
                    <synopsis>FEID соседа</synopsis>
                    <typeRef>uint32</typeRef>
                  </component>
                  <component componentID="2">
                    <name>InterfaceToNeighbor</name>
                    <synopsis>Интерфейс FE к этому соседу</synopsis>
                    <optional/>
                    <typeRef>string</typeRef>
                  </component>
                  <component componentID="3">
                    <name>NeighborInterface</name>
                    <synopsis>
                      Имя интерфейса соседам с которым данных FE 
                      является смежным. Это нужно при наличии более
                      одного смежного FE на интерфейсе.
                    </synopsis>
                    <optional/>
                    <typeRef>string</typeRef>
                  </component>
                </struct>
              </dataTypeDef>
              <dataTypeDef>
                <name>LFBSelectorType</name>
                <synopsis>Уникальное имя экземпляра класса LFB</synopsis>
                <struct>
                  <component componentID="1">
                    <name>LFBClassID</name>
                    <synopsis>Идентификатор класса LFB</synopsis>
                    <typeRef>uint32</typeRef>
                  </component>
                  <component componentID="2">
                    <name>LFBInstanceID</name>
                    <synopsis>Идентификатор экземпляра LFB</synopsis>
                    <typeRef>uint32</typeRef>
                  </component>
                </struct>
              </dataTypeDef>
              <dataTypeDef>
                <name>LFBLinkType</name>
                <synopsis>
                  Канал между двумя экземплярами LFB в топологии
                </synopsis>
                <struct>
                  <component componentID="1">
                    <name>FromLFBID</name>
                    <synopsis>Источник LFB</synopsis>
                    <typeRef>LFBSelectorType</typeRef>
                  </component>
                  <component componentID="2">
                    <name>FromPortGroup</name>
                    <synopsis>Группа портов источника</synopsis>
                    <typeRef>string</typeRef>
                  </component>
                  <component componentID="3">
                    <name>FromPortIndex</name>
                    <synopsis>Индекс порта-источника</synopsis>
                    <typeRef>uint32</typeRef>
                  </component>
                  <component componentID="4">
                    <name>ToLFBID</name>
                    <synopsis>LFBID назначения</synopsis>
                    <typeRef>LFBSelectorType</typeRef>
                  </component>
                  <component componentID="5">
                    <name>ToPortGroup</name>
                    <synopsis>Группа портов назначения</synopsis>
                    <typeRef>string</typeRef>
                  </component>
                  <component componentID="6">
                    <name>ToPortIndex</name>
                    <synopsis>Индекс порта назначения</synopsis>
                    <typeRef>uint32</typeRef>
                  </component>
                </struct>
              </dataTypeDef>
            </dataTypeDefs>
            <LFBClassDefs>
              <LFBClassDef LFBClassID="1">
                <name>FEObject</name>
                <synopsis>Core LFB: FE Object</synopsis>
                <version>1.0</version>
                <components>
                  <component access="read-write" componentID="1">
                    <name>LFBTopology</name>
                    <synopsis>Таблица известных топологий</synopsis>
                    <array type="variable-size">
                      <typeRef>LFBLinkType</typeRef>
                    </array>
                  </component>
                  <component access="read-write" componentID="2">
                    <name>LFBSelectors</name>
                    <synopsis>
                       Таблица известных активных классов и экземпляров LFB
                    </synopsis>
                    <array type="variable-size">
                      <typeRef>LFBSelectorType</typeRef>
                    </array>
                  </component>
                  <component access="read-write" componentID="3">
                    <name>FEName</name>
                    <synopsis>Имя данного FE</synopsis>
                    <typeRef>string[40]</typeRef>
                  </component>
                  <component access="read-write" componentID="4">
                    <name>FEID</name>
                    <synopsis>Идентификатор данного FE</synopsis>
                    <typeRef>uint32</typeRef>
                  </component>
                  <component access="read-only" componentID="5">
                    <name>FEVendor</name>
                    <synopsis>Производитель FE</synopsis>
                    <typeRef>string[40]</typeRef>
                  </component>
                  <component access="read-only" componentID="6">
                    <name>FEModel</name>
                    <synopsis>Модель FE</synopsis>
                    <typeRef>string[40]</typeRef>
                  </component>
                  <component access="read-write" componentID="7">
                    <name>FEState</name>
                    <synopsis>Состояние данного FE</synopsis>
                    <typeRef>FEStateValues</typeRef>
                  </component>
                  <component access="read-write" componentID="8">
                    <name>FENeighbors</name>
                    <synopsis>таблица известных соседей</synopsis>
                    <optional/>
                    <array type="variable-size">
                      <typeRef>FEConfiguredNeighborType</typeRef>
                    </array>
                  </component>
                </components>
                <capabilities>
                  <capability componentID="30">
                    <name>ModifiableLFBTopology</name>
                    <synopsis>Поддержка изменяемых LFB</synopsis>
                    <optional/>
                    <typeRef>boolean</typeRef>
                  </capability>
                  <capability componentID="31">
                    <name>SupportedLFBs</name>
                    <synopsis>Список всех поддерживаемых LFB</synopsis>
                    <optional/>
                    <array type="variable-size">
                      <typeRef>SupportedLFBType</typeRef>
                    </array>
                  </capability>
                </capabilities>
              </LFBClassDef>
            </LFBClassDefs>
          </LFBLibrary>

5.2. Возможности FE

Информация о возможностях FE содержится в элементе <capabilities> определения класса. Как уже было сказано, информация о возможностях доступна лишь для чтения.

В настоящее время определены возможности ModifiableLFBTopology и SupportedLFBs. Информация о поддерживаемых компонентах LFB FEObject доступна из свойств этих компонент.

5.2.1. ModifiableLFBTopology

Компонента относится к логическому типу (boolean) и показывает, может ли CE изменить топологию LFB для FE. При отсутствии компоненты предполагается значение true и CE считает, что топологию LFB можно изменить. Если присутсвует значение false, топология LFB для FE является фиксированной. В таких случаях элемент SupportedLFBs может быть опущен и список поддерживаемых LFB выводится CE из топологической информации LFB. Если список поддерживаемых LFB представлен и ModifiableLFBTopology = false, информацию CanOccurBefore и CanOccurAfter следует опускать.

5.2.2. SupportedLFBs и SupportedLFBType

Одной из возможностей, которую FE следует включать, является список поддерживаемых классов LFB. Компонента SupportedLFBs является массивом, содержащим информацию о каждом поддерживаемом классе LFB. Структура массива определена как SupportedLFBType dataTypeDef.

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

5.2.2.1. LFBName

Значением этой компоненты является имя описываемого класса LFB.

5.2.2.2. LFBClassID

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

5.2.2.3. LFBVersion

LFBVersion содержит строку, указывающую версию класса LFB, поддерживаемую этим FE. Как указано выше, FE может поддерживать лишь одну версию данного класса LFB.

5.2.2.4. LFBOccurrenceLimit

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

5.2.2.5. PortGroupLimits и PortGroupLimitType

Компонента PortGroupLimits является массивом информации о группах портов, поддерживаемых этим классом LFB. Структура информации об ограничении числа портов в группе определяется PortGroupLimitType dataTypeDef.

Каждый элемент массива PortGroupLimits содержит информацию об одной группе портов класса LFB, включающую имя группы портов в компоненте PortGroupName, наименьшее число портов группы в компоненте MinPortCount и наибольшее число портов группы в компоненте MaxPortCount.

5.2.2.6. CanOccurAfters и LFBAdjacencyLimitType

Компонента CanOccurAfters является массивом, содержащим список LFB, после которых может размещаться описываемый класс. Элементы массива определены в LFBAdjacencyLimitType dataTypeDef.

Элементы массива описывают разрешенное размещение данного класса LFB, называемого здесь SupportedLFB. В частности, каждый элемент именует LFB, который может топологически предшествовать данному классу LFB. То есть SupportedLFB может иметь входной порт, соединенный с выходным портом LFB, указанного в массиве CanOccurAfters. Класс LFB, за которым может следовать SupportedLFB, указывается компонентой NeighborLFB (LFBAdjacencyLimitType dataTypeDef) в массиве CanOccurAfters. Если сосед может быть подключен лишь к определенному набору групп входных портов, включается компонента viaPort, являющаяся массивом с элементом для каждой группы входных портов в SupportedLFB, который может быть соединен с выходным портом NeighborLFB.

Например, взаписи SupportedLFBs, каждый элемент массива CanOccurAfters должен иметь уникального соседа NeighborLFB, а в каждом таком элементе массива кажая компонента viaPort должна представлять свою действительную группу входных портов SupportedLFB. Схема определения класса LFB не включает этих требований к уникальности.

5.2.2.7. CanOccurBefores и LFBAdjacencyLimitType

Массив CanOccurBefores содержит информацию о классах LFB, которые могут следовать за описываемым классом. Структурно элемент похож на CanOccurAftersи использует такое же определение типа для элементов массива.

Элементы массива указывают классы LFB, которым SupportedLFB может предшествовать в топологии. В этой компоненте записи viaPort указывают группы выходных портов SupportedLFB, которые могут быть подключены к NeighborLFB. Как и в CanOccurAfters, viaPort может иметь множество записей если многим группам портов разрешено соединение с данным классом NeighborLFB.

Приведенные выше требования к уникальности для CanOccurAfter применимы и к CanOccurBefore, даже если класс LFB указан сразу в CanOccurAfter и CanOccurBefore.

5.2.2.8. UseableParentLFBClasses

При наличии массива UseableParentLFBClasses он используется для хранения списка идентификаторов родительских классов LFB. Все элементы массива должны быть идентификаторами классов, для которых класс SupportedLFB class является наследником¹⁴ (напрямую или через промежуточного предка). Кроме того, включая данный класс в список, FE указывает CE, что данный родительский класс может использовать для манипуляций с экземпляром этого поддерживаемого класса LFB.

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

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

5.2.2.9. LFBClassCapabilities

Информация об уровне возможностей класса желательна, но модель ее не включает. Хотя такая информация относится к FE Object в таблице поддерживаемых классов, содержимое ее зависит от класса. Ожидаемые в настоящее время структуры кодирования при передаче информации между CE и FE таковы, что размещение совершенно не описанной информации может приводить к ошибкам при ее анализе. Можно было бы выбрать для этой информации тип octetstring, но это требует определения внутреннего формата строки октетов.

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

5.3. Компоненты FE

Элемент <components> включается, если определение класса содержит определение компонент объекта FE, которы не считаются «возможностями» (capabilities). Некоторые из этих компонент доступны для записи, а другие — лишь для чтения, что можно проверить путем просмотра информации компонент.

5.3.1. FEState

Эта компонента передает общее состояние FE и может принимать значение AdminDisable, OperDisable или OperEnable. Начальным состояние является OperDisable, а переход в OperEnable управляется FE. Элемент CE контролирует переходы между состояниями OperEnable и AdminDisable. Дополнительная информация приведена в спецификации протокола ForCES [RFC5810].

5.3.2. LFBSelectors и LFBSelectorType

LFBSelectors представляет собой массив информации LFB, доступных в данный момент по протоколу ForCES в FE. Структура информации LFB определена LFBSelectorType dataTypeDef.

Каждый элемент массива описывает один экземпляр LFB в элементе FE. Запись содержит числовые идентификаторы класса экземпляра LFB и данного экземпляра.

5.3.3. LFBTopology и LFBLinkType

Необязательная компонента LFBTopology содержит информацию о соединениях между LFB внутри FE, описывая каждое такое соединение в LFBLinkType dataTypeDef. Компонента LFBLinkType содержит информацию, достаточную для точного указания конечных точек соединения. Компоненты FromLFBID и ToLFBID задают экземпляры LFB на каждой стороне соединения и должны указывать LFB из таблицы экземпляров LFB. Компоненты FromPortGroup и ToPortGroup должны указывать входную и выходную группу портов, определенные в классах LFB экземпляров LFB, указанных в FromLFBID и ToLFBID. Компоненты FromPortIndex и ToPortIndex выбирают из групп порты, к которым это соединение подключено. Все соединения однозначно указываются полями FromLFBID, FromPortGroup и FromPortIndex. Множество соединений может иметь одинаковые значения ToLFBID, ToPortGroup и ToPortIndex, поскольку эта модель поддерживает входное (но не выходное) разветвление.

5.3.4. FENeighbors и FEConfiguredNeighborType

FENeighbors — это массив информации о настроенных вручную отношениях смежности между данным FE и другими элементами FE. Содержимое массива определяется FEConfiguredNeighborType dataTypeDef.

Массив предназначен для сбора информации, которая может быть задана на FE и нужна CE. Каждый элемент массива соответствует одному соседу. Отметим, что массив не отражает результатов автоматического обнаружения, поскольку они будут указывать свои LFB. Эта компонента не обязательна.

Существует много способов указания соседей, но для сопоставления в CE наиболее эффективно применять FE-ID. Идентификатор интерфейса (строка имени) является лучшим коррелятором. CE сможет получить IP-адрес и данные уровня среды напрямую от соседа. Отсутствие этой информации в таблице позволяет предотвратить риск некорректной «двойной настройки».

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

5.3.4.1. NeighborID

Это идентификатор в неком пространстве имен, значимый для CE применительно к соседу.

5.3.4.2. InterfaceToNeighbor

Идентификатор интерфейса, через который доступен сосед.

5.3.4.3. NeighborInterface

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

6. Выполнение требований к модели FE

В этом разделе рассматривается выполнение предложенной моделью FE требований, заданных в разделе 5 RFC 3654 [RFC3654]. Требования разделены на общую часть (раздел 5, параграфы 5.1 — 5.4) и требования к минимальному набору логических функций, которые должна поддерживать модель FE (параграф 5.5).

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

Основной компонентой предложенной модели FE является логический функциональный блок LFB. Каждая логическая функция в FE моделируется как LFB. Рабочие параметры LFB, которые должны быть видимы CE, называются компонентами LFB. Эти компоненты указывают возможности FE и поддерживают гибкость реализаций, позволяя FE указать поддерживаемые дополнительные возможности. Компоненты также указывают возможность настройки класса LFB элементами CE. Настраиваемые компоненты обеспечивают CE некоторую гибкость при задании поведения LFB. При создании множества экземпляров LFB одного класса LFB в элементе FE каждый из экземпляров LFB может быть настроен с разными параметрами компонент. Запрашивая настройки компонент экземпляров LFB, элемент CE может определить состояние LFB.

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

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

Модель FE включает лишь определение самого FE Object LFB. Для выполнения полного набора требований рабочей группы нужны дополнительные LFB. Определение классов для этих LFB будет дано в других документах.

7. Использование модели FE в протоколе ForCES

Фактическая модель уровня пересылки в данном NE заключается в том, что элемент CE должен изучать и контролировать, взаимодействуя с элементами FE (или иными способами). Большая часть таких коммуникаций будет происходить после создания ассоциации с использованием протокола ForCES. Ниже перечислены данные, которыми элементы CE и FE должны обмениваться по протоколу ForCES [RFC5810].

1. Запрос топологии FE.

2. Объявление возможностей FE.

3. Запрос топологии LFB (на уровне FE) и настройки возможностей.

4. Объявление возможностей LFB.

5. Запрос состояния компонент LFB.

6. Манипуляции с компонентами LFB.

7. Изменение топологии LFB.

В пп. 1 — 5 основной поток информации идет от FE к CE. Пп. 1 — 4 обычно запрашиваются элементами CE на начальном этапе фазы PA¹⁵, хотя они могут повторяться в фазе PA (в любой момент). П. 5 (запрос состояния) используется в начале фазы PA и часто повторяется в этой фазе (особенно запросы счетчиков статистики).

Пп. 6 и 7 представляют собой «команды» и основной поток информации идет от CE к FE. Сообщения п. 6 (команды изменения конфигурации LFB) предполагаются достаточно частыми. П. 7 (изменение топологии LFB ) нужно использовать ли при поддержке FE динамического изменения топологии LFB и они предполагаются нечастыми.

Топология соединений между FE (п. 1) может быть определена CE разными способами. Ни данный документ, ни спецификация ForCES [RFC5810] не задают конкретных механизмов. Определение класса LFB включает возможность настройки идентификации соседей на FE или предоставление этой информации по запросу CE. Могут быть также определены специальные классы LFB и протоколы для обнаружения соседей. CE может применять протоколы маршрутизации для определения отношений смежности. Соответствующая конфигурация может быть задана в CE.

Связи между моделью FE и семью сообщениями фазы PA показаны на рисунке 12.

                                    +--------+
                       ..........-->|   CE   |
  /----\               .            +--------+
  \____/ Модель FE     .              ^    |
  |    |................        (1),2 |    | 6, 7
  |    |  (off-line)   .      3, 4, 5 |    |
  \____/               .              |    v
                       .            +--------+
Например, RFC          ..........-->|   FE   |
                                    +--------+

Рисунок 12. Связь между моделью FE и сообщениями протокола ForCES, где (1) — часть базового протокола ForCES, а остальное определено моделью FE

Кодирование этих сообщений определяется протоколом ForCES protocol [RFC5810] и выходит за рамки модели FE. Тем не менее важно рассмотреть этот вопрос здесь в силу перечисленных ниже причин.

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

• Знание типа информации, которая может передаваться между FE и CE может помочь при выборе подходящего протокольного формата и метода кодирования (такого как XML, TLV).

• Знание частоты этого типа сообщений должно влиять на выбор протокольного формата (эффективность).

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

7.1. Запрос топологии FE

FE может (не обязательно) иметь один или несколько внешних входных портов, а также может (не обязательно) иметь один или несколько внешних выходных портов. Иными словами, не каждый элемент FE имеет внешние входные и/или выходные интерфейсы. Например, на рисунке 13 показан каскад из двух FE. FE #1 имеет внешний входной интерфейс, но не имеет внешнего выходного, а FE #2 — наоборот. Можно соединить эти два FE через их внутренние интерфейсы для обеспечения входной и выходной обработки. Это позволяет гибко распределять функции между множеством FE, а затем соединять их в соответствии с задачами.

   +-----------------------------------------------------+
   |  +---------+   +------------+   +---------+         |
 Вход |         |   |            |   |         | Выход   |
---+->| Входной |-->|Сжатие      |-->|Пересылка|---------+--->+
   |  | порт    |   |заголовков  |   |IPv4     | FE      |    |
   |  +---------+   +------------+   +---------+ #1      |    |
   +-----------------------------------------------------+    V
                                                              |
        +-----------------------<-----------------------------+
        |
        |    +----------------------------------------+
        V    |  +------------+   +----------+         |
        | Вход  |            |   |          | Выход   |
        +->--+->|Декомпрессия|-->| Выходной |---------+-->
             |  |заголовков  |   | порт     | FE      |
             |  +------------+   +----------+ #2      |
             +----------------------------------------+

Рисунок 13. Пример двух соединенных вместе FE.

Хотя протокол взаимодействия между FE выходит за рамки ForCES, элементам CE нужно понимать, как соединены между собой FE для полной реализации функций входной и выходной обработки, например, как показано на рисунке 13. Топологию соединений могут предоставлять устройства FEs, она может быть жестко закодирована в CE или предоставляться иным путем (например, менеджером шины) независимо от FE. Поэтому, хотя протокол ForCES [RFC5810] и позволяет запросить у FE топологические данные, CE не обязательно использовать это при наличии у CE других способов получения этой информации.

Когда топология соединений между FE получена CE по запросу, далее она считается статичной. Однако элемент FE может быть отключен в процессе работы NE или может быть установлена новая плата и активизирован новый элемент FE и топология соединений между FE может измениться. Протокол ForCES должен обеспечивать для CE механизм детектирования таких событий и обработки изменений в топологии FE, однако топология FE выходит за рамки модели FE.

7.2. Объявление возможностей FE

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

• возможности передачи метаданных (понимание этих возможностей поможет CE пригодность топологии LFB и определить доступность некоторых служб);

• глобальные ограничения на запрос ресурсов (применимо ко всем LFB в FE);

• LFB, поддерживаемые FE;

• пределы числа экзепляров классов LFB;

• топологические ограничения LFB (соединения, порядок и т. п.).

7.3. Запрос топологии LFB и возможности ее настройки

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

7.4. Объявления возможностей LFB

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

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

Ниже перечислены два имеющихся типа ограничений.

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

• Количественные ограничения, такие как размер таблиц и т. п.

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

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

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

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

7.5. Запрос состояния компонент LFB

Это свойство должно поддерживаться всеми FE. Протокол ForCES и схема/кодирование данных протокола должны совместно выполнять приведенные ниже требования для упрощения запроса состояния компонентLFB.

• Должен поддерживаться выбор FE. Это относится прежде всего к указанию одного FE, но может поддерживаться и указание группы или всех FE.

• Должен разрешаться выбор экземпляра LFB. Это относится прежде всего к указанию одного экземпляра LFB, но может поддерживаться и указание группы или всех экземпляров LFB.

• Должна поддерживаться адресация отдельных компонент LFB.

• Должно поддерживаться эффективное кодирование и декодирование адресной информации и настроенных данных.

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

7.6. Манипуляции компонентами LFB

Модель FE обеспечивает определения для классов LFB, каждый из которых имеет глобально уникальный идентификатор. Информация внутри класса представляется как компоненты и назначенные идентификаторы в области действия этого класса. Модель также указывает, что экземпляры классов LFB имеют идентификаторы. Комбинация идентификатора класса, идентификатора экземпляра и идентификатора компоненты используется протоколом для доступа к информации LFB в протокольных операциях.

7.7. Изменение топологии LFB

Операции, которые требуются для перенастройки топологии LFB, включают:

• создание нового экземпляра данного класса LFB в данном FE;

• подключение данного выхода LFB x к данному входу LFB y;

• отключение путем удаления канала между данным выходом одного LFB и данным входом другого;

• удаление данного LFB (автоматически удаляются все его соединения с другими LFB).

8. Пример определения LFB

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

Последняя часть этого примера включает ссылки на протокольные операции. Формат и поля здесь указаны исключительно для иллюстрации, поскольку точный синтаксис и семантику операций определяет протокол ForCES [RFC5810].

  <?xml version="1.0" encoding="UTF-8"?>
        <LFBLibrary xmlns="urn:ietf:params:xml:ns:forces:lfbmodel:1.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         provides="LaserFrameLFB">
          <frameDefs>
            <frameDef>
              <name>FRFrame</name>
              <synopsis>
                  Кадр Frame Relay с DLCI без «прокладки»</synopsis>
            </frameDef>
            <frameDef>
              <name>IPFrame</name>
               <synopsis>Пакет IP</synopsis>
            </frameDef>
          </frameDefs>
          <dataTypeDefs>
            <dataTypeDef>
              <name>frequencyInformationType</name>
              <synopsis>Информация об одной частоте CWDM</synopsis>
              <struct>
                <component componentID="1">
                  <name>LaserFrequency</name>
                  <synopsis>Кодированная частота (канал)</synopsis>
                  <typeRef>uint32</typeRef>
                </component>
                <component componentID="2">
                  <name>FrequencyState</name>
                  <synopsis>Состояние частоты</synopsis>
                  <typeRef>PortStatusValues</typeRef>
                </component>
                <component componentID="3">
                  <name>LaserPower</name>
                  <synopsis>Текущая наблюдаемая мощность</synopsis>
                  <typeRef>uint32</typeRef>
                </component>
                <component componentID="4">
                  <name>FrameRelayCircuits</name>
                  <synopsis>
                      Информация об устройствах на этой частоте
                  </synopsis>
                  <array>
                    <typeRef>frameCircuitsType</typeRef>
                  </array>
                </component>
              </struct>
            </dataTypeDef>
            <dataTypeDef>
              <name>frameCircuitsType</name>
              <synopsis>
                  Информация об одном устройстве (канале) Frame Relay
              </synopsis>
              <struct>
                <component componentID="1">
                  <name>DLCI</name>
                  <synopsis>DLCI of the circuit</synopsis>
                  <typeRef>uint32</typeRef>
                </component>
                <component componentID="2">
                  <name>CircuitStatus</name>
                  <synopsis>Состояние устройства</synopsis>
                  <typeRef>PortStatusValues</typeRef>
                </component>
                <component componentID="3">
                  <name>isLMI</name>
                  <synopsis>Является ли устройство LMI16</synopsis>
                  <typeRef>boolean</typeRef>
                </component>
                <component componentID="4">
                  <name>associatedPort</name>
                  <synopsis>
                      Какой входной/выходной порт связан с устройством
                  </synopsis>
                  <typeRef>uint32</typeRef>
              </struct>
            </dataTypeDef>
            <dataTypeDef>
              <name>PortStatusValues</name>
              <synopsis>
                  Возможные значения состояния (рабочего и административного)
              </synopsis>
              <atomic>
                <baseType>uchar</baseType>
                <specialValues>
                  <specialValue value="0">
                    <name>Disabled </name>
                    <synopsis>Компонента отключена</synopsis>
                  </specialValue>
                  <specialValue value="1">
                    <name>Enabled</name>
                    <synopsis>Элемент FE оперативно включен</synopsis>
                  </specialValue>
                </specialValues>
              </atomic>
            </dataTypeDef>
          </dataTypeDefs>
          <metadataDefs>
            <metadataDef>
              <name>DLCI</name>
              <synopsis>DLCI прибывшего кадра</synopsis>
              <metadataID>12</metadataID>
              <typeRef>uint32</typeRef>
            </metadataDef>
            <metadataDef>
              <name>LaserChannel</name>
              <synopsis>Индекс канала лазера</synopsis>
              <metadataID>34</metadataID>
              <typeRef>uint32</typeRef>
            </metadataDef>
          </metadataDefs>
          <LFBClassDefs>
              <!-- Фиктивный идентификатор класса с действительным значением -->
            <LFBClassDef LFBClassID="255">
              <name>FrameLaserLFB</name>
              <synopsis>Фиктивный блок LFB для демонстрации</synopsis>
              <version>1.0</version>
              <inputPorts>
                <inputPort group="true">
                  <name>LMIfromFE</name>
                  <synopsis>Порты для передачи трафика LMI</synopsis>
                  <expectation>
                    <frameExpected>
                      <ref>FRFrame</ref>
                    </frameExpected>
                    <metadataExpected>
                      <ref>DLCI</ref>
                      <ref>LaserChannel</ref>
                    </metadataExpected>
                  </expectation>
                </inputPort>
                <inputPort>
                  <name>DatafromFE</name>
                  <synopsis>
                      Порты для данных, передаваемых в каналы (устройства)
                  </synopsis>
                  <expectation>
                    <frameExpected>
                      <ref>IPFrame</ref>
                    </frameExpected>
                    <metadataExpected>
                      <ref>DLCI</ref>
                      <ref>LaserChannel</ref>
                    </metadataExpected>
                  </expectation>
                </inputPort>
              </inputPorts>
              <outputPorts>
                <outputPort group="true">
                  <name>LMItoFE</name>
                  <synopsis>Порты для обрабатываемого трафика LMI</synopsis>
                  <product>
                    <frameProduced>
                      <ref>FRFrame</ref>
                    </frameProduced>
                    <metadataProduced>
                      <ref>DLCI</ref>
                      <ref>LaserChannel</ref>
                    </metadataProduced>
                  </product>
                </outputPort>
                <outputPort group="true">
                  <name>DatatoFE</name>
                  <synopsis>Порты для обрабатываемого трафика данных</synopsis>
                  <product>
                    <frameProduced>
                      <ref>IPFrame</ref>
                    </frameProduced>
                    <metadataProduced>
                      <ref>DLCI</ref>
                      <ref>LaserChannel</ref>
                    </metadataProduced>
                  </product>
                </outputPort>
              </outputPorts>
              <components>
                <component access="read-write" componentID="1">
                  <name>AdminPortState</name>
                  <synopsis>Разрешена ли работа этого порта</synopsis>
                  <typeRef>PortStatusValues</typeRef>
                </component>
                <component access="read-write" componentID="2">
                  <name>FrequencyInformation</name>
                  <synopsis>Таблица информации для частоты CWDM</synopsis>
                  <array type="variable-size">
                    <typeRef>frequencyInformationType</typeRef>
                  </array>
                </component>
              </components>
              <capabilities>
                <capability componentID="31">
                  <name>OperationalState</name>
                  <synopsis>Работает ли порт всегда</synopsis>
                  <typeRef>PortStatusValues</typeRef>
                </capability>
                <capability componentID="32">
                  <name>MaximumFrequencies</name>
                  <synopsis>Число имеющихся длин волн</synopsis>
                  <typeRef>uint16</typeRef>
                </capability>
                <capability componentID="33">
                  <name>MaxTotalCircuits</name>
                  <synopsis>
                      Общее число поддерживаемых устройств Frame Relay 
                      на всех длинах волн
                  </synopsis>
                  <optional/>
                  <typeRef>uint32</typeRef>
                </capability>
              </capabilities>
              <events baseID="61">
                <event eventID="1">
                  <name>FrequencyState</name>
                  <synopsis>
                      Состояние лазерной частоты изменилось
                  </synopsis>
                  <eventTarget>
                    <eventField>FrequencyInformation</eventField>
                    <eventSubscript>_FrequencyIndex_</eventSubscript>
                    <eventField>FrequencyState</eventField>
                  </eventTarget>
                  <eventChanged/>
                  <eventReports>
                      <!-- Отчет о новом состоянии -->
                    <eventReport>
                      <eventField>FrequencyInformation</eventField>
                      <eventSubscript>_FrequencyIndex_</eventSubscript>
                      <eventField>FrequencyState</eventField>
                    </eventReport>
                  </eventReports>
                </event>
                <event eventID="2">
                  <name>CreatedFrequency</name>
                  <synopsis>Обнаружена новая частота</synopsis>
                  <eventTarget>
                    <eventField>FrequencyInformation></eventField>
                    <eventSubscript>_FrequencyIndex_</eventSubscript>
                  </eventTarget>
                  <eventCreated/>
                  <eventReports>
                    <eventReport>
                      <eventField>FrequencyInformation</eventField>
                      <eventSubscript>_FrequencyIndex_</eventSubscript>
                      <eventField>LaserFrequency</eventField>
                    </eventReport>
                  </eventReports>
                </event>
                <event eventID="3">
                  <name>DeletedFrequency</name>
                  <synopsis>
                      Удалена запись в таблице частот
                  </synopsis>
                  <eventTarget>
                    <eventField>FrequencyInformation</eventField>
                    <eventSubscript>_FrequencyIndex_</eventSubscript>
                  </eventTarget>
                  <eventDeleted/>
                 </event>
                <event eventID="4">
                  <name>PowerProblem</name>
                  <synopsis>Проблемы с уровнем мощности лазера</synopsis>
                  <eventTarget>
                    <eventField>FrequencyInformation</eventField>
                    <eventSubscript>_FrequencyIndex_</eventSubscript>
                    <eventField>LaserPower</eventField>
                  </eventTarget>
                  <eventLessThan/>
                  <eventReports>
                    <eventReport>
                      <eventField>FrequencyInformation</eventField>
                      <eventSubscript>_FrequencyIndex_</eventSubscript>
                      <eventField>LaserPower</eventField>
                    </eventReport>
                    <eventReport>
                      <eventField>FrequencyInformation</eventField>
                      <eventSubscript>_FrequencyIndex_</eventSubscript>
                      <eventField>LaserFrequency</eventField>
                    </eventReport>
                  </eventReports>
                </event>
                <event eventID="5">
                  <name>FrameCircuitChanged</name>
                  <synopsis>
                      Изменилось состояние устройства FR на частоте
                  </synopsis>
                  <eventTarget>
                    <eventField>FrequencyInformation</eventField>
                    <eventSubscript>_FrequencyIndex_</eventSubscript>
                    <eventField>FrameRelayCircuits</eventField>
                    <eventSubscript>FrameCircuitIndex</eventSubscript>
                    <eventField>CircuitStatus</eventField>
                  </eventTarget>
                  <eventChanged/>
                  <eventReports>
                    <eventReport>
                      <eventField>FrequencyInformation</eventField>
                      <eventSubscript>_FrequencyIndex_</eventSubscript>
                      <eventField>FrameRelayCircuits</eventField>
                      <eventSubscript>FrameCircuitIndex</eventSubscript>
                      <eventField>CircuitStatus</eventField>
                    </eventReport>
                    <eventReport>
                      <eventField>FrequencyInformation</eventField>
                      <eventSubscript>_FrequencyIndex_</eventSubscript>
                      <eventField>FrameRelayCircuits</eventField>
                      <eventSubscript>FrameCircuitIndex</eventSubscript>
                      <eventField>DLCI</eventField>
                    </eventReport>
                  </eventReports>
                </event>
              </events>
            </LFBClassDef>
          </LFBClassDefs>
        </LFBLibrary>

8.1. Обработка данных

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

Пакеты, прибывшие без ошибок из физического интерфейса, попадают в Frame Relay DLCI на лазерном канале. Эти два значения используются LFB для поиска при обработке пакета. Если обработка показывает, что пакет относится к LMI, используется выходной индекс для выбора порта LFB в группе LMItoFE. Пакет передается в виде полного кадра FR (без вставки битов или байтов) в выбранный порт. Лазерный канал и DLCI передаются как метаданные, хотя DLCI имеется и в пакете.

Пакеты без ошибок, не относящиеся к LMI и имеющие индикатор типа IP, передаются как пакеты IP в порт группы DatatoFE с использованием того же поля индекса из таблицы на основе лазерного канала и DLCI, которые передаются как метаданные для последующего применения (например, классификации).

Текущее определение не указывает поведения для кадров, тип которых не является IP.

Пакеты, приходящие на входные порты сопровождаются метаданными для лазерного канала и DLCI. Поэтому может использоваться один входной порт. Со структурой, которая определена (параллельно выходной структуре) выбор канала и DLCI может быть ограничен группой входного порта (LMI и данные) и индексом порта. При другом устройстве LFB структура может требовать взаимно-однозначного соответствия между DLCI и портом LFB, когда метаданные станут ненужными. Однако это приведет к усложнению. Промежуточный уровень структуры здесь обеспечивает параллелизм между входом и выходом, не требуя избыточных портов.

8.1.1. Организация DLCI

Когда элемент CE решает организовать DLCI на определенном лазерном канале, он передает запрос SET, направленный этому блоку LFB. Запрос имеет вид

      T = SET
        T = PATH-DATA
          Path: flags = none, length = 4, path = 2, channel, 4, entryIdx
          DataRaw: DLCI, Enabled(1), false, out-idx

Это будет создавать DLCI с трафиком, идущим в конкретный порт выходной группы DatatoFE (CE будет гарантировать подключение этого порта к нужному месту до отправки запроса).

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

Можно представить, что FE имеет LMI LFB. Такие LFB будут подключаться к группам портов LMItoFE и LMIfromFE и обрабатывать информацию LMI. Задачей LFB может быть организация устройств Frame Relay. LMI LFB будет иметь псевдоним, указывающий на поддерживаемую таблицу устройств Frame Relay и сможет манипулировать этими записями.

8.1.2. Обработка ошибок

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

При некоторых ошибках может потребоваться передача части пакета элементу CE. Ошибка сама по себе не вызывает события в LFB. Имеется два способа решить задачу отправки информации CE.

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

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

Другие аспекты обработки ошибок рассмотрены ниже.

8.2. Компоненты LFB

Этот блок LFB определен с компонентами верхнего уровня, отражающими административное состояние LFB, что позволяет элементу CE полностью отключить LFB.

Другой компонентой является таблица информации о лазерных каналах в виде массива с переменным размером. Каждый элемент массива содержит идентификатор длины волны, с которой связан этот элемент, рабочее состояние этой длины волны, мощность лазера на данном канале и таблицу устройств Frame Relay на этой длине волны. Здесь нет административного состояния, поскольку CE может отключить запись путем ее удаления (длиы волн и мощность лазера в неиспользуемых каналах практического интереса не представляют, информация о поддерживаемых длинах волн доступна в разделе возможностей).

Информация об устройстве (канале) Frame Relay содержит DLCI, рабочее состояние канала, использование канала для передачи информации LMI и и порт выходной группы LFB, в который передается трафик. Как отмечено выше, индекс устройства может в некоторых случаях комбинироваться с DLCI.

8.3. Возможности

Информация о возможностях для этого LFB включает рабочее состояние базового интерфеса, число поддерживаемых длин волн, число разрешенных локальных устройств для всех каналов. Максимальное число устройств для данного лазерного канала можно определить из таблицы FrameRelayCircuits. GET-PROP для пути 2.channel.4 будет давать CE свойства данного массива FrameRelayCircuits, которые включают число используемых элементов, первый доступный элемент и максимально разрешенное число элементов.

8.4. События

Этот блок LFB определен с возможностью генерации нескольких событий, которые могут быть интересны CE. Это уведомления об изменении рабочего состояния лазерных частот, а также создании и удалении частот (длин волн). Кроме того, поддерживаются уведомления о смене состояний отдельных устройств Frame Relay. Например, уведомление 61.5.3.11 будет говорить об изменении статуса устройства с индексом 11 в текущей таблице с индексом 3 таблицы длин волн. Уведомление о событии будет также указывать новое состояние устройства и DLCI. Возможно, DLCI является избыточным, поскольку CE предположительно знает DLCI по индексу устройства. Это поле указано здесь для демонстрации включения в отчет о событии двух информационных элементов.

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

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

         T = SET-PROP
           Path-TLV: flags=0, length = 2, path = 61.4
             Path-TLV: flags = property-field, length = 1, path = 2
               Content = 1 (register)
             Path-TLV: flags = property-field, length = 1, path = 3
               Content = 15 (threshold)

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

Если мощность лазера колеблется около значения 15, может возникать множество уведомлений (например при переходе между 14 и 15 каждый переход будет создавать уведомление). Предположим, что CE решает подавить эти осцилляции на канале 5. Это можно сделать путем задания гистерезиса, как показано ниже.

         T = SET-PROP
           Path-TLV: flags=0, length = 3, path = 61.4.5
             Path-TLV: flags = property-field, length = 1, path = 4
               Content = 2 (hysteresis)

Установка гистерезиса 2 подавляет множество ненужных уведомлений. Когда уровень первый раз упадет ниже 10, будет создано уведомление. Если мощность возрастет до 10 или 11, а затем снова упадет ниже 10, уведомления не будет. Если мощность поднимется по меньшей мере до 12, а затем упадет ниже 10, снова будет создано уведомление. Одной из основных причин таких колебаний является фактическое значение мощности около границы. Если мощность составляет 9,5, незначительные ее изменения будут приводить к скачкам между 9 и 10. Гистерезис со значением 1 будет подавлять ненужные уведомления. Другие события могут приводить к более сильным колебаниям и для них потребуется большее значение гистерезиса.

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

The ForCES model creates the need for a unique XML namespace for ForCES library definition usage, and unique class names and numeric class identifiers.

9.1. Регистрация пространства имен URN

Агентство IANA зарегистрировало новое пространство имен XML в соответствии с рекомендациями RFC 3688 [RFC3688].

   URI: URI для этого пространства имен имеет значение
   urn:ietf:params:xml:ns:forces:lfbmodel:1.0
   Registrant Contact: IESG
   XML: нет, но это пространство имен XML

9.2. Имена и идентификаторы классов LFB

Чтобы иметь четко определенные классы ForCES LFB и четко определенные идентификаторы в этих классах агентство IANA создало реестр имен классов LFB, соответствующих идентификаторов классов и документов с определениями классов LFB. Значения в реестре выделяются в порядке подачи заявок (FCFS¹⁷) Идентификаторы классов LFB со значением меньше 65536 зарезервированы для IETF Standards-Track RFC. Идентификаторы с номерами 65536 и выше в 32-битовом пространстве доступны для выделения в порядке поступления запросов. Все записи реестра должны быть документированы в стабильной форме с открытым доступом.

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

Агентство IANA создало реестр ForCES LFB Class Names и соответствующих идентификаторов ForCES LFB Class Identifiers как показано в таблице.

10. Почетные авторы

Ниже приведен список авторов, внесших свой вклад в создание ранних версий этого документа.

Ellen Delganes, Intel Corp.

Lily Yang, Intel Corp.

Ram Gopal, Nokia Research Center

Alan DeKok, Infoblox, Inc.

Zsolt Haraszti, Clovis Solutions

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

Многие из наших коллег в компаниях и участников почтовой конференции ForCES внесли важный вклад в эту работу. Особая благодарность Evangelos Haleplidis за помощью с XML.

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

Модель FE описывает организацию и представление наборов данных и компонент в FE. Базовый документ ForCES [RFC3746] включает всеобъемлющий анализ безопасности архитектуры ForCES в целом. Например, объекты протокола ForCES должны быть аутентифицированы в соответствии с требованиями ForCES до того, как они смогут получить доступ к описанной в этом документе информации по протоколу ForCES. Доступ к информации, содержащейся в модели FE, обеспечивается протоколом ForCES, который определен в отдельных документах, включающих рассмотрение вопросов безопасности.

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

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

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

[RFC5810] Doria, A., Ed., Hadi Salim, J., Ed., Haas, R., Ed., Khosravi, H., Ed., Wang, W., Ed., Dong, L., Gopal, R., and J. Halpern, «Forwarding and Control Element Separation (ForCES) Protocol Specification», RFC 5810, March 2010.

[RFC3688] Mealling, M., «The IETF XML Registry», BCP 81, RFC 3688, January 2004.

[Schema1] Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, «XML Schema Part 1: Structures», W3C REC-xmlschema-1, http://www.w3.org/TR/xmlshcema-1/, May 2001.

[Schema2] Biron, P. and A. Malhotra, «XML Schema Part 2: Datatypes», W3C REC-xmlschema-2, http://www.w3.org/TR/xmlschema-2/, May 2001.

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

[RFC3654] Khosravi, H. and T. Anderson, «Requirements for Separation of IP Control and Forwarding», RFC 3654, November 2003.

[RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal, «Forwarding and Control Element Separation (ForCES) Framework», RFC 3746, April 2004.

[RFC3317] Chan, K., Sahita, R., Hahn, S., and K. McCloghrie, «Differentiated Services Quality of Service Policy Information Base», RFC 3317, March 2003.

[RFC3318] Sahita, R., Hahn, S., Chan, K., and K. McCloghrie, «Framework Policy Information Base», RFC 3318, March 2003.

[RFC3444] Pras, A. and J. Schoenwaelder, «On the Difference between Information Models and Data Models», RFC 3444, January 2003.

[RFC3470] Hollenbeck, S., Rose, M., and L. Masinter, «Guidelines for the Use of Extensible Markup Language (XML) within IETF Protocols», BCP 70, RFC 3470, January 2003.

[UNICODE] Davis, M. and M. Suignard, «UNICODE Security Considerations», http://www.unicode.org/reports/tr36/tr36-3.html, July 2005.

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

Joel Halpern

Self

P.O. Box 6049

Leesburg, VA 20178

USA

Phone: +1 703 371 3043

EMail: jmh@joelhalpern.com

Jamal Hadi Salim

Znyx Networks

Ottawa, Ontario

Canada

EMail: hadi@mojatatu.com

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

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

nmalykh@gmail.com

PDF

Автор:
Christoph Rohland <cr@sap.com>, 1.12.01

Обновление:
Hugh Dickins, 4 June 2007

Обновление:
KOSAKI Motohiro, 16 Mar 2010

Файловая система tmpfs служит для хранения файлов в виртуальной памяти.

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

Файловая система tmpfs размещается во внутреннем кэше ядра и меняет свой размер (расширяется или сужается) в соответствии с обънмом хранящейся информации. Ненужные в настоящее время страницы могут «сбрасываться» в область подкачки (swap). Максимальный размер файловой системы можно исзменять в процессе работы с помощью команды mount -o remount …

В отличие от файловой системы ramfs (прообраз tmpfs) поддерживается возможность свопинга и контроля размера. Другим похожим объектом являются виртуальные диски в ОЗУ
(RAM-диск, /dev/ram*), которые имитируют «жесткий» диск фиксированного размера, размещаемый в физической памяти компьютера с организованной на нем обычной файловой системой. Для виртуальных дисков свопинг и изменение размера не поддерживаются.

Поскольку tmpfs может размещаться только в страницах кэша и области подкачки, все страницы tmpfs, находящиеся в памяти, будут выглядеть, как кэшированные. Они не будут представляться чем-либо типа разделяемых страниц. Более того, вы можете проверить реальное размещение данных tmpfs в ОЗУ и области подкачки с помощью команд df и du.

Файловая система tmpfs служит для решения ряда задач:

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

   На эти монтирования опция ядра CONFIG_TMPFS не указывает влияния. Если эта опция не была установлена при сборке ядра, видимая пользователю часть tmpfs не создается, но внутренние механизмы продолжают использоваться.

2. glibc, начиная с версии 2.2, предполагает, что файловая система tmpfs примонтирована, как /dev/shm для разделяемой памяти POSIX (shm_open, shm_unlink). Для реализации этого в файле /etc/fstab указывается строка:

   tmpfs	/dev/shm	tmpfs	defaults	0 0

   Не забудьте создать на диске каталог, куда вы планируете монтировать tmpfs.

   Эта точка монтирования не требуется для разделяемой памяти SYSV, поскольку для этого служит внутреннее монтирование в ядре (в ядре версии 2.3 требовалось монтировать предшественника tmpfs — shm fs — для использования разделяемой памяти SYSV).

3. Некоторые считают весьма удобным монтировать файловую систему tmpfs как /tmp и/или /var/tmp при наличии большого раздела подкачки. В большинстве дистрибутивов mkinitrd позволяет работать с tmpfs, примонтированной, как /tmp.

4. Можно придумать еще множество вариантов применения tmpfs.

Файловая система tmpfs поддерживает три опции монтирования для управления размером:

size задает предельный размер экземпляра tmpfs в байтах (по умолчанию составляет половину размера имеющейся в системе физической памяти — ОЗУ). Создание tmpfs слишком большого размера может приводить к «зависанию» системы, поскольку обработчик OOM не сможет освободить эту память.

nr_blocks задает предельный размер числом блоков PAGE_CACHE_SIZE.

nr_inodes задает максимальное число узлов inode для данного экземпляра (по умолчанию совпадает меньшим из значений половины от числа страниц ОЗУ или на машинах с highmem половины от числа страниц ОЗУ lowmem).

При задании этих параметров можно использовать суффиксы k (kilo), m (mega) и g (giga). Для параметра size можно также использовать суффикс %, который показывает задание размера tmpfs в процентах от физического размера ОЗУ. По умолчанию, если ни один из параметров size, nr_blocks не задан, будет использоваться значение size=50%.
Если nr_blocks=0 (или size=0), число блоков для данного экземпляра не ограничивается; если nr_inodes=0, не ограничивается число узлов inode. В общем случае монтирование с такими опциями нежелательно, поскольку при этом каждый пользователь с правом записи сможет занять всю оперативную память системы, однако такие значения позволяют повысить уровень масштабируемости tmpfs в многопроцессорных машинах, интенсивно использующих файловую систему tmpfs.

Для tmpfs поддерживается опция монтирования mpol, позволяющая использовать политику выделения памяти NUMA для всех файлов данного экземпляра (при включенной опции CONFIG_NUMA). Значение данной опции также можно менять в процессе работы с помощью команды mount -o remount …

mpol=default использовать политику выделения для процессов (см. set_mempolicy(2));

mpol=prefer:Node предпочтительно выделять память из данного узла (Node);

mpol=bind:NodeList выделять память только из узлов списка NodeList;

mpol=interleave предпочтительно выделять память из каждого узла поочередно;

mpol=interleave:NodeList память выделяется из каждого узла NodeList поочередно;

mpol=local предпочительно выделять память из локального узла.

NodeList предсатвляет собой список разделенных запятыми десятичных значений или диапазонов (два десятичных числа, начиная с меньшего, через дефис). Например, mpol=bind:0-3,5,7,9-15.

Заданная при монтировании политика выделения памяти сохраняется для использования при создании файлов. Когда та или иная задача создает файл в tmpfs, политика выделения памяти, заданная при монтировании, применяется с соответствующим списком NodeList (если он задан) и с учетом ограничений набора процессоров (см. Documentation/cgroups/cpusets.txt в дистрибутиве ядра) и флагов, перечисленных ниже. Если в результате список NodeLists становится пустым, используется принятая по умолчанию политика выделения памяти (mpol=default).

Политика распределения памяти NUMA поддерживает ряд дополнительных флагов, используемых вместе с заданным при монтировании режимом. Эти флаги могут быть заданы при монтировании tmpfs путем указания после режима но перед списком NodeList. Полный список флагов можно найти в документе Documentation/vm/numa_memory_policy.txt, где описано также воздействие этих флагов на политику выделения памяти.

=static эквивалентно MPOL_F_STATIC_NODES

=relative эквивалентно MPOL_F_RELATIVE_NODES

Например, mpol=bind=static:NodeList эквивалентно политике выделения MPOL_BIND | MPOL_F_STATIC_NODES.

Отметим, что попытка монтирование tmpfs с опцией mpol будет приводить к отказу, если используемое ядро не поддерживает NUMA, а также в тех случаях, когда в списке присутствует неактивный узел. Если в вашей системе используется tmpfs, но некоторые варианты ядра могут не поддерживать NUMA (например, ядро, используемое при восстановлении системы) или отдельные узлы могут лказываться неактивными, рекомендуется исключить опцию mpol из параметров автоматического монтирования. Вы можете добавить нужную опцию позднее, когда tmpfs уже примонтирована (как MountPoint) с помощью команды mount -o remount,mpol=Policy:NodeList MountPoint.

Для задания изначального корневого каталога можно использовать приведенные ниже опции монтирования:

mode права доступа в восьмеричном формате;

uid идентификатор пользователя;

gid идентификатор группы.

Эти опции не меняются при перемонтировании файловой системы, но исх можно поменять с помощью команд chmod, chown и chgrp на смонтированной файловой системе.

Так, команда mount -t tmpfs -o size=10G,nr_inodes=10k,mode=700 tmpfs /mytmpfs будет создавать экземпляр tmpfs с точкой монтирования /mytmpfs, для которого будет выделено 10 Гбайт RAM/SWAP с 10240 узлами inode, доступный только пользователю root.

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

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

nmalykh@protokols.ru

Independent Submission                              V. Dolmatov, Ed.
Request for Comments: 5830                           Cryptocom, Ltd.
Category: Informational                                   March 2010
ISSN: 2070-1721

GOST 28147-89. Алгоритмы шифрования, дешифрования и MAC

GOST 28147-89: Encryption, Decryption, and Message Authentication Code (MAC) Algorithms

PDF

Аннотация

Этот документ опубликован в качестве источника информации о стандарте Российской Федерации для алгоритмов шифрования, дешифрования и идентификации сообщений (GOST 28147-89), который является одним из российских стандартов для криптографических алгоритмов, называемых алгоритмами GOST. Недавно российские криптоалгоритмы начали использовать в приложениях Internet и этот документ был подготовлен в качестве источника информации для разработчиков и пользователей алгоритмов GOST 28147-89 в плане шифрования, дешифровки и идентификации сообщений.

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

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

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

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

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

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

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

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

1. Введение

1.1. Общие сведения

[GOST28147-89] является алгоритмом унифицированного криптографического преобразования для систем обработки информации разного назначения, определяющим правила шифрования/дешифрования и генерации кода идентификации сообщений (MAC¹).

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

2. Применимость

GOST 28147-89 определяет модель шифрования/дешифрования и генерации MAC для заданного сообщения (документа), который предназначен для передачи по незащищенным публичным телекоммуникационным каналам между системами обработки данных разного назначения.

Алгоритм GOST 28147-89 обязателен в Российской Федерации для использования во всех системах обработки данных, предоставляющих публичный сервис.

3. Определения и обозначения

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

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

Running key — рабочий ключ²

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

Encryption — шифрование³

Процесс преобразования открытых данных в зашифрованные с помощью шифра.

MAC — код идентификации сообщения⁴

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

Key — ключ

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

Cryptographic protection — криптографическая защита, криптозащита

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

Cryptographic transformation – криптографическое преобразование

Преобразование данных с использованием шифрования и (или) MAC.

Decryption — дешифровка⁵

Процесс преобразования защищенных данных в открытые с использованием шифра.

Initialisation vector — вектор инициализации⁶

Исходные значения открытых параметров алгоритма криптографического преобразования.

Encryption equation — уравнение зашифровки

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

Decryption equation — уравнение расшифровки

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

Cipher — шифр

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

3.2. Обозначения

В этом документе используются следующие обозначения:

(+) побитовое сложение слов одного размера по модулю 2;

[+] сложение 32-битовых векторов по модулю 2³².

[+]’ сложение 32-битовых векторов по модулю 2³²-1.

1..N множество целых чисел от 1 до N, включительно.

4. Общие сведения

Структурная схема алгоритма криптографических преобразований (криптографическая модель⁷) включает:

• 256-битовое устройство хранения ключей (KDS⁸), состоящее из восьми 32-битовых регистров (X0, X1, X2, X3, X4, X5, X6, X7);
• четыре 32-битовых регистра (N1, N2, N3, N4);
• два 32-битовых регистра (N5 и N6), содержащих константы⁹ C1 и C2;
• два 32-битовых сумматора по модулю 2³² (CM1, CM3);
• 32-битовый сумматор для побитового сложения по модулю 2 (CM2);
• 32-битовый сумматор по модулю (2³²-1) (CM4);
• сумматор по модулю 2 (CM5) без ограничения по разрядности;
• блок подстановки (K);
• циклический регистр сдвига на одиннадцать разрядов¹⁰ в сторону старшего разряда (R).

Блок подстановки (S-box) K состоит из восьми узлов замены K1, K2, K3, K4, K5, K6, K7, K8 с памятью по 64 бита в каждом. Приходящий в блок подстановки 32-битовый вектор делится на 8 последовательных 4-битовых векторов, каждый из которых преобразуется соответствующим узлом замены в другой 4-битовый вектор. Узел замены представляет собой таблицу из 16 строк по 4 бита. Входной вектор определяет номер строки в таблице, а содержимое этой строки служит выходным вектором. Далее 4-битовые выходные векторы последовательно объединяются в 32-битовый вектор.

Примечание: стандарт не определяет каких-либо блоков подстановки. Некоторые из таких блоков определены в [RFC4357].

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

При записи ключа (W1, W2, …, W256), Wq = 0..1, q = 1..256 в KDS:

• значение W1 записывается в первый бит регистра X0;
• значение W2 записывается во второй бит регистра X0;
• …
• значение W32 записывается в 32-й бит регистра X0;
• значение W33 записывается в первый бит регистра X1;
• значение W34 записывается во второй бит регистра X1;
• …
• значение W64 записывается в 32-й бит регистра X1;
• значение W65 записывается в первый бит регистр X2;
• …
• значение W256 записывается в 32-й бит регистра X7.

При перезаписи информации значение p-го бита одного регистра (сумматора) записывается в p-й бит другого регистра (сумматора).

Значения констант C1 и C2, хранящихся в регистрах N5 и N6 приведены в приложении 1.

Ключи, определяющие заполнение KDS и таблиц блока подстановки K, являются секретными элементами и поставляются в установленном порядке.

Заполнение блока подстановки K описано в GOST 28147-89, как долговременный ключевой элемент, который является общим для компьютерной сети. Обычно K используется в качестве параметра алгоритма и некоторые возможные наборы значений K описаны в [RFC4357].

В криптографической модели предполагается 4 режима работы:

• зашифровка (дешифровка) данных в режиме простой замены (ECB¹¹);
• зашифровка (дешифровка) данных в режиме гаммирования (CNT¹²);
• зашифровка (дешифровка) данных в режиме гаммирования с обратной связью (CFB¹³);
• генерация MAC (имитовставки).

В [RFC4357] также описан режим CBC, но он не входит в стандарт. =

5. Режим простой замены

5.1. Зашифровка открытых данных в режиме простой замены

Шифруемые данные делятся на блоки по 64 бита в каждом. Ввод любого двоичного блока Tp = (a1(0), a2(0), … , a31(0), a32(0), b1(0), b2(0), …, b32(0)) в регистры N1 и N2 выполняется таким образом, что значение a1(0) помещается в первый разряд регистра N1, значение a2(0) — во второй разряд N1 и т. д, а значение a32(0) помещается в 32-й разряд регистра N1. Значение b1(0) помещается в первый разряд регистра N2, значение b2(0) — во второй разряд N2, …, значение b32(0) — в 32-й разряд регистра N2.

В результате получается состояние (a32(0), a31(0), …, a2(0), a1(0)) в регистре N1 и состояние (b32(0), b31(0), …, b1(0)) в регистре N2.

В KDS вводятся 256 битов ключа. Содержимое восьми 32-битовых регистров X0, X1, …, X7 будет иметь вид:

X0 = W32, W31, ..., W2, W1
X1 = W64, W63, ..., W34, W33
. . . . . . . . . . . . . . .
X7 = W256, W255, ..., W226, W225

Алгоритм зашифровки 64-битового блока открытых данных в режиме простой подстановки состоит из 32 циклов.

В первом цикле начальное значение регистра N1 складывается по модулю 2³² в сумматоре CM1 с содержимым регистра X0 блока хранения ключей. Отметим, что значение регистра N1 при этом остается неизменным.

Результат суммирования преобразуется в блоке подстановки K и полученный вектор помещается в регистр R, где он циклически сдвигает на 11 разрядов в направлении старших битов¹⁴. Результат операции сдвига суммируется поразрядно по модуля 2 в сумматоре CM2 с 32-битовым значением регистра N2. Полученные в сумматоре CM2 результат записывается в регистр N1, а прежнее содержимое этого регистра переносится в регистр N2. На этом первый цикл заканчивается.

Последующие циклы выполняются по аналогии с первым. При этом:

• во втором цикле из KDS считывается¹⁵ содержимое регистра X1;
• в третьем цикле из KDS считывается содержимое регистра X2;
• …
• в восьмом цикле из KDS считывается содержимое регистра X7.
• в циклах 9 — 16 и 17 — 24 операции считывания содержимого регистров KDS повторяются в том же порядке:

X0, X1, X2, X3, X4, X5, X6, X7.

• в последних 8 циклах (25 — 32) содержимое регистров KDS считывается в обратном порядке:

X7, X6, X5, X4, X3, X2, X1, X0.

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

X0, X1, X2, X3, X4, X5, X6, X7, X0, X1, X2, X3, X4, X5, X6, X7,
X0, X1, X2, X3, X4, X5, X6, X7, X7, X6, X5, X4, X3, X2, X1, X0

В 32-м цикле результат из сумматора CM2 копируется в регистр N2, а в регистре N1 значение сохраняется.

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

Уравнения для зашифровки в режиме electronic codebook имеют вид:

|a(j) = (a(j-1) [+] X(j-1)(mod 8))*K*R (+) b (j-1)
|b(j) = a(j-1)

при j = 1..24;

|a(j) = (a(j-1) [+] X(32-j))*K*R (+) b(j-1)
|b(j) = a(j-1)

при j = 25..31; a32 = a31;

b(32) = (a(31) [+] X0)*K*R (+) b(31) 

при j=32.

Где:

a(0) = (a32(0), a31(0), …, a1(0)) — начальные значения регистра N1 перед первым циклом зашифровки;

b(0) = (b32(0), b31(0), …, b1(0)) — начальные значения регистра N2 перед первым циклом зашифровки;

a(j) = (a32(j), a31(j), …, a1(j)) — содержимое регистра N1 после j-го цикла зашифровки (j = 1..32);

b(j) = (b32(j), b31(j), …, b1(j)) — содержимое регистра N2 после j-го цикла зашифровки (j = 1..32).

R — операция циклического сдвига на 11 разрядов в направлении старших битов:

R(r32, r31, r30, r29, r28, r27, r26, r25, r24, r23, r22, r21, r20, ..., r2, r1) = 
(r21, r20, ..., r2, r1, r32, r31, r30, r29, r28, r27, r26, r25, r24, r23, r22)

64-битовый блок зашифрованных данных Tc считывается из регистров N1 и N2 в следующем порядке:

1-й, 2-й, …, 32-й бит регистра N1, затем 1-й, 2-й, …, 32-й бит регистра N2

Tc = a1(32), a2(32), ..., a32(32), b1(32), b2(32), ..., b32(32)).

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

5.2. Дешифровка в режиме простой подстановки

Ключ, который использовался при зашифровке (256 битов) загружается в KDS, зашифрованные данные делятся на блоки по 64 бита. Ввод любого двоичного блока

Tc = (a1(32), a2(32), ..., a32(32), b1(32), b2(32), ..., b32(32))

в регистры N1 и N2 выполняется следующим образом:

• значение a1(32) записывается в первый бит регистра N1;
• значение a2(32) записывается во второй бит регистра N1;
• …
• значение a32(32) записывается в 32-й бит регистра N1;
• значение b1(32) записывается в первый бит регистра N2;
• …
• значение b32(32) записывается в 32-й бит регистра N2.

Процедура дешифровки использует тот же алгоритм, который применялся при зашифровке открытых данных с одним исключением — содержимое регистров X0, X1, …, X7 считывается из KDS для дешифровки в следующем порядке:

X0,X1,X2,X3,X4,X5,X6,X7, X7,X6,X5,X4,X3,X2,X1,X0,
X7,X6,X5,X4,X3,X2,X1,X0, X7,X6,X5,X4,X3,X2,X1,X0.

Уравнение дешифровки имеет вид:

|a(32-j) = (a(32-j+1) [+] X(j-1))*K*R (+) b(32-j+1)
|b(32-1) = a(32-j+1)

при j = 1..8;

|a(32-j) = (a(32-j+1) [+] X(j-1)(mod 8))*K*R (+) b(32-j+1)
|b(32-1) = a(32-j+1)

при j = 9..31;

|a(0) = a(1)
|b(0) = (a(1) [+] X0)*K*R (+) b1

при j=32.

Содержимое регистров N1 и N2 после 32 циклов работы составляет блок расшифрованных (открытых) данных.

Tp = (a1(0), a2(0), ... , a32(0), b1(0), b2(0), ..., b32(0))

соответствующий зашифрованному блоку:

• значение a1(0) блока Tp соответствует первому биту регистра N1;
• значение a2(0) соответствует второму биту регистра N1;
• …
• значение b1(0) соответствует первому биту регистра N2;
• значение b2(0) соответствует второму биту регистра N2;
• …
• значение b32(0) соответствует 32-му биту регистра N2.

Оставшиеся блоки расшифровываются аналогично.

Алгоритм зашифровки в режиме простой замены 64-битового блока Tp обозначается A, т. е.:

A(Tp) = A(a(0), b(0)) = (a(32), b(32)) = Tc.

6. Режим гаммирования

6.1. Зашифровка открытых данных в режиме гаммирования

Открытые данные, разбитые на блоки по 64 бита Tp(1), Tp(2), …, Tp(M-1), Tp(M), зашифровываются в режиме гаммирования путем поразрядного суммирования по модулю 2 в сумматоре CM5 рабочим ключом (гаммой шифра) Gc, который генерируется блоками по 64 бита:

Gc = (Gc(1), Gc(2), ..., Gc(M-1), Gc(M))

где M определяется размером шифруемых данных.

Gc(i) — это i-й блок данных размером 64 бита, где i=1..M — число двоичных разрядов в блоке Tp(M) — может быть меньше 64 (в этом случае неиспользованная для шифрования часть рабочего ключа Gc(M) отбрасывается).

256 битов ключа помещаются в KDS. В регистры N1 и N2 помещаются 64-битовая двоичная последовательность (вектор инициализации или синхропосылка) S = (S1, S2, …, S64), которая служит исходными данными для генерации M блоков рабочего ключа. Вектор инициализации помещается в регистры N1 и N2 следующим образом:

• значение S1 записывается в первый бит регистра N1;
• значение S2 записывается во второй бит регистра N1;
• …
• значение S32 записывается в 32-й бит регистра N1;
• значение S33 записывается в первый бит регистра N2;
• значение S34 записывается во второй бит регистра N2;
• …
• значение S64 записывается в 32-й бит регистра N2.

Исходное содержимое регистров N1 и N2 (вектор инициализации S) шифруется в режиме простой подстановки в соответствии с требованиями параграфа 5.1. Результат шифрования A(S) = (Y0, Z0) записывается в 32-битовые регистры N3 и N4 (содержимое N1 записывается в N3, содержимое N2 — в N4).

Содержимое регистра N4 суммируется по модулю (2³²-1) в сумматоре CM4 с 32-битовой константой C1 из регистра N6, а результат записывается в регистр N4. Содержимое регистра N3 складывается по модулю 2³² в сумматоре CM3 с 32-битовой константой C2 из регистра N5, а результат записывается в регистр N3.

Содержимое регистра N3 копируется в N1, а содержимое N4 — в N2, значения регистров N3 и N4 при этом не меняются.

Содержимое регистров N1 и N2 шифруется методом простой подстановки в соответствии с требованиями параграфа 5.1. Полученное в результате содержимое регистров N1 и N2 образует первый 64-битовый блок рабочего ключа Gc(1), который поразрядно суммируется по модулю 2 в сумматоре CM5 с первым 64-битовым блоком открытых данных:

Tp(1) = (t1(1), t2(1), ..., t63(1), t64(1)).

Результат суммирования дает 64-битовый блок зашифрованных данных:

Tc(1) = (tau1(1), tau2(1), ..., tau63(1), tau64(1)).

Значение tau1(1) блока Tc(1) является результатом сложения по модулю 2 в сумматоре CM5 значения t1(1) из блока Tp(1) со значением первого бита регистра N1, tau2(1) блока Tc(1) — результатом сложения по модулю 2 в сумматоре CM5 значения t2(1) из блока Tp(1) со значением второго бита N1 и т. д., значение tau64(1) блока Tc(1) является результатом сложения по модулю 2 в сумматоре CM5 значения t64(1) из блока Tp(1) со значением 32-го бита N2.

Для получения следующего 64-битового блока рабочего ключа Gc(2) содержимое регистра N4 складывается по модулю (2³²-1) в сумматоре CM4 с константой C1 из регистра N6; содержимое регистра N3 складывается по модулю 2³² в сумматоре CM3 с константой C2 из регистра N5. Новое значение регистра N3 копируется в N1, новое значение N4 — в N2¹⁶. Значения регистров N3 и N4 при этом сохраняются.

Содержимое регистров N1 и N2 шифруется методом простой подстановки в соответствии с требованиями параграфа 5.1. Полученное в результате зашифрованное содержимое регистров N1 и N2 образует первый 64-битовый блок рабочего ключа Gc(2), который поразрядно суммируется по модулю 2 в сумматоре CM5 с первым 64-битовым блоком открытых данных Tp(2). Генерация остальных блоков рабочего ключа Gc(3), Gc(4), …, Gc(M) и зашифровка открытых блоков Tp(3), Tp(4), …, Tp(M) выполняется аналогично. Если размер последнего (M-го) блока открытых данных менее 64 битов, из последнего блока рабочего ключа используется только соответствующее количество битов, а остальные биты отбрасываются¹⁷.

Вектор инициализации S и блоки зашифрованных данных Tc(1), Tc(2), …, Tc(M) передаются в канал связи или память ЭВМ.

Уравнение зашифровки имеет вид:

Tc(i) = A(Y[i-1] [+] C2, Z[i-1]) [+]' C1) (+) Tp(i) = Gc(i) (+) Tp(i)
i=1..M

где

Y[i] — содержимое регистра N3 после зашифровки i-го блока открытых данных Tp(i);

Z(i) — содержимое регистра N4 после зашифровки i-го блока открытых данных Tp(i);

(Y[0], Z[0]) = A(S).

6.2. Расшифровка данных с режиме гаммирования

В KDS вводятся 256 битов ключа, использованного для зашифровки открытых данных Tp(1), Tp(2), …, Tp(M). Значение вектора инициализации S помещается в регистры N1 и N2 и генерируются M блоков рабочего ключа Gc(1), Gc(2), …, Gc(M), как описано в параграфе 6.1. Блоки зашифрованных данных Tc(1), Tc(2), …, Tc(M) поразрядно складываются по модулю 2 в сумматоре CM5 с блоками рабочего ключа, что приводит к восстановлению блоков открытых данных Tp(1), Tp(2), …, Tp(M). Блок Tp(M) может иметь размер менее 64 битов.

Уравнение расшифровки имеет вид:

Tp(i) = A (Y[i-1] [+] C2, Z[i-1] [+]' C1) (+) Tc(i) = Gc(i) (+) Tc(i)
i = 1..M

7. Режим гаммирования с обратной связью

7.1. Зашифровка открытых данных в режиме гаммирования с обратной связью

Открытые данные разбиваются на блоки размером 64 бита Tp(1), Tp(2), …, Tp(M) и шифруются в режиме гаммирования с обратной связью путем поразрядного сложения по модулю в сумматоре CM5 с рабочим ключом (гаммой) Gc, генерируемым в форме 64-битовых блоков. Т. е., Gc(i)=(Gc(1), Gc(2), …, Gc(M)), где M определяется размером открытых данных, Gc(i) — i-й блок ключа размером 64 бита, i=1..M. Размер блока Tp(M) может быть менее 64 битов.

В KDS вводятся 256 битов ключа. 64-битовый вектор инициализации (синхропосылка) S = (S1, S2, …, S64) помещается в регистры N1 и N2, как описано в параграфе 6.1.

Исходное содержимое регистров N1 и N2 зашифровывается в режиме простой подстановки в соответствии с требованиями параграфа 5.1¹⁸. Зашифрованное содержимое регистров N1 и N2 является первым 64-битовым блоком рабочего ключа Gc(1)=A(S), который складывается по модулю 2 в сумматоре CM5 с первым 64-битовым блоком открытых данных Tp(1) = (t1(1), t2(1), …, t64(1))¹⁹.

В результате получается 64-битовый блок зашифрованных данных

Tc(1) = (tau1(1), tau2(1), ..., tau64(1)).

Блок зашифрованных данных Tc(1) одновременно используется в качестве исходных значений регистров N1 и N2 для генерации второго блока рабочего ключа Gc(2) и по цепи обратной связи этот блок записывается в регистры следующим образом:

• значение tau1(1) записывается в первый бит регистра N1;
• значение tau2(1) записывается во второй бит регистра N1;
• …
• значение tau32(1) записывается в 32-й бит регистра N1;
• значение tau33(1) записывается в первый бит регистра N2;
• значение tau34(1) записывается во второй бит регистра N2;
• …
• значение tau64(1) записывается в 32-й бит регистра N2.

Содержимое регистров N1 и N2 зашифровывается в режиме простой подстановки в соответствии с требованиями параграфа 5.1⁷. Зашифрованное содержимое регистров N1 и N2 образует второй 64-битовый блок рабочего ключа Gc(2), который складывается по модулю 2 в сумматоре CM5 со вторым блоком открытых данных Tp(2).

Генерация последующих блоков рабочего ключа Gc(i) и шифрование соответствующих блоков открытых данных Tp(i) (i = 3..M) выполняется аналогично. Если размер последнего (M-го) блока открытых данных меньше 64 битов, используются только соответствующие биты M-го блока рабочего ключа Gc(M), а оставшиеся биты отбрасываются.

Уравнение шифрования в режиме гаммирования с обратной связью имеет вид:

|Tc(1) = A(S) (+) Tp(1) = Gc(1) (+) Tp(1)
|Tc(i) = A(Tc(i-1)) (+) Tp(i) = Gc(i) + Tp(i), i = 2..M.

Вектор инициализации (синхропосылка) S и блоки зашифрованных данных Tc(1), Tc(2), …, Tc(M) предаются в канал связи или память ЭВМ.

7.2. Расшифровка в режиме гаммирования с обратной связью

В KDS помещаются 256 битов ключа, использованного для зашифровки блока открытых данных Tp(1), Tp(2), …, Tp(M). Вектор инициализации (синхропосылка) S в регистры N1 и N2, как описано в параграфе 6.1. Исходное содержимое регистров N1 и N2 (вектор инициализации S) шифруется в режиме простой подстановки в соответствии с требованиями параграфа 5.1⁷. Зашифрованное содержимое регистров N1, N2 образует первый блок рабочего ключа Gc(1) = A(S), который суммируется поразрядно по модулю 2 в сумматоре CM5 с блоком зашифрованных данных Tc(1). Результатом этой операции является первый блок открытых (расшифрованных) данных Tp(1).

Блок зашифрованных данных Tc(1) служит исходным содержимым регистров N1, N2 при генерации второго блока рабочего ключаGc(2). Блок Tc(1) записывается в регистры N1 и N2 в соответствии с требованиями параграфа 6.1. Содержимое регистров N1 и N2 шифруется в режиме простой подстановки в соответствии с требованиями параграфа 5.1 и полученный а результате блок Gc(2) поразрядно суммируется по модулю 2 в сумматоре CM5 со вторым блоком зашифрованных данных Tc(2). В результате получается второй блок расшифрованных данных Tc(2).

Аналогично, блоки зашифрованных данных Tc(2), Tc(3), …, Tc(M-1) поочередно записываются в регистры N1, N2, а содержимое этих регистров шифруется в режиме простой подстановки для генерации блоков рабочего ключа Gc(3), Gc(4), …, Gc(M). Эти блоки поразрядно суммируются по модулю 2 в сумматоре CM5 с блоками зашифрованных данных Tc(3), Tc(4), …, Tc(M), в результате чего получаются блоки открытых (расшифрованных) данных Tp(3), Tp(4), …, Tp(M). Размер последнего блока открытых данных Tp(M) может быть менее 64 битов.

Уравнение расшифровки в режиме гаммирования с обратной связью имеет вид:

Tp(1) = A(S) (+) Tc(1) = Gc(1) (+) Tc(1)
Tp(1) = A(Tc(i-1)) (+) Tc(i) = Gc(i) (+) Tc(i), i=2..M

8. Режим генерации MAC

Для защиты от фальсификации открытых данных, представляющих собой M блоков размером 64 бита Tp(1), Tp(2), …, Tp(M), где M >= 2 генерируется дополнительный блок размером l (имитовставка или MAC — I(l)). Процесс генерации MAC в режимах зашифровки и расшифровки совпадает.

Первый блок открытых данных

Tp(1) = (t1(1), t1(2), ..., t64(1))
= (a1(1)[0], a2(1)[0], ..., a32(1)[0], b1(1)[0], b2(1)[0], ..., b32(1)[0])

записывается в регистры N1 и N2 следующим образом:

• значение t1(1) = a1(1)[0] записывается в первый бит регистра N1;
• значение t2(1) = a2(1)[0] записывается во второй бит регистра N1;
• …
• значение t32(1) = a32(1)[0] записывается в 32-й бит регистра N1;
• значение t33(1) = b1(1)[0] записывается в первый бит регистра N2;
• …
• значение t64(1) = b32(1)[0] записывается в 32-й бит регистра N2.

Содержимое регистров N1 и N2 преобразуется в соответствии с первыми 16 циклами алгоритма шифрования в режиме простой подстановки (параграф 5.1). В KDS при этом находится тот же ключ, который используется для зашифровки блоков открытых данных Tp(1), Tp(2), …, Tp(M) в соответствующие блоки закрытых данных Tc(1), Tc(2), …, Tc(M).

Полученное после 16 циклов содержимое регистров N1 и N2, имеющее вид (a1(1)[16], a2(1)[16], …, a32(1)[16], b1(1)[16], b2(1)[16], …, b32(1)[16]), суммируется по модулю 2 в сумматоре CM5 со вторым блоком открытых данных Tp(2) = (t1(2), t2(2), …, t64(2)).

Результат суммирования

(a1(1)[16](+)t1(2), a2(1)[16](+)t2(2), ..., a32(1)[16](+)t32(2),
b1(1)[16](+)t33(2), b2(1)[16](+)t34(2), ..., b32(1)[16](+)t64(2))
=
(a1(2)[0], a2(2)[0] ..., a32(2)[0], b1(2)[0], b2(2)[0], ..., b32(2)[0])

записывается в регистры N1, N2 и преобразуется в соответствии с первыми 16 циклами процесса шифрования в режиме простой подстановки.

Полученное в результате содержимое регистров N1 и N2 суммируется по модулю 2 в сумматоре CM5 с третьим блоком Tp(3) и т. д. Последний блок Tp(M) = (t1(M), t2(M), …, t64(M)) при необходимости дополняется нулями до размера 64 бита и суммируется по модулю 2 в сумматоре CM5 с содержимым регистров N1 и N2

(a1(M-1)[16], a2(M-1)[16], ..., a32(M-1)[16], b1(M-1)[16], b2(M-1)[16], ..., b32(M-1)[16]).

Результат суммирования

(a1(M-1)[16](+)t1(M), a2(M-1)[16](+)t2(M), ..., a32(M-1)[16](+)
t32(M), b1(M-1)[16](+)t33(M), b2(M-1)[16](+)t34(M), ..., b32(M-1)[16](+)t64(M))
=
(a1(M)[0], a2(M)[0] ..., a32(M)[0], b1(M)[0], b2(M)[0], ..., b32(M)[0])

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

(a1(M)[16], a2(M)[16] ..., a32(M)[16], b1(M)[16], b2(M)[16], ..., b32(M)[16])

выбирается отрезок размером l-битов — имитовставка (MAC) I(l):

I(l) = [a(32-l+1)(M)[16], a(32-l+2)(M)[16], ..., a32(M)[16]].

MAC I(l) передается по каналу связи или в память ЭВМ в конце зашифрованных данных. Т. е., результат имеет вид

Tc(1), Tc(2), ..., Tc(M), I(l).

Полученные зашифрованные данные Tc(1), Tc(2), …, Tc(M) расшифровываются, а из полученных при этом блоков открытых данных Tp(1), Tp(2), …, Tp(M) генерируется MAC I'(l), как описано выше, и результат сравнивается с полученным (из канала передачи или памяти ЭВМ) вместе с зашифрованными данными значением MAC I(l). Если значения MAC не совпадают, полученные в результате расшифровки открытые данные Tp(1), Tp(2), …, Tp(M) считаются фальсифицированы.

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

Значение параметра l (размер MAC) определяется действующими криптографическими требованиями с учетом того, что вероятность навязывания ложных данных равна 2^-l.

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

Документ целиком посвящен вопросам безопасности.

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

[GOST28147-89] «Система обработки информации. Защита криптографическая. Алгоритм криптографического преобразования», ГОСТ 28147-89, Государственный стандарт Союза ССР, Издательство стандартов, 1989.

[RFC4357] Popov, V., Kurepkin, I., and S. Leontiev, «Additional Cryptographic Algorithms for Use with GOST 28147-89, GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 Algorithms», RFC 4357, January 2006.

Приложение A. Значения констант C1 и C2

Константа C1 имеет вид:

Константа C2 имеет вид:

Приложение B. Разработчики документа

Dmitry Kabelev

Cryptocom, Ltd.

14 Kedrova St., Bldg. 2

Moscow, 117218

Russian Federation

EMail: kdb@cryptocom.ru

Igor Ustinov

Cryptocom, Ltd.

14 Kedrova St., Bldg. 2

Moscow, 117218

Russian Federation

EMail: igus@cryptocom.ru

Irene Emelianova

Cryptocom Ltd.

14 Kedrova St., Bldg. 2

Moscow, 117218

Russian Federation

EMail: irene@cryptocom.ru

Адрес автора

Vasily Dolmatov, редактор

Cryptocom, Ltd.

14 Kedrova St., Bldg. 2

Moscow, 117218

Russian Federation

EMail: dol@cryptocom.ru

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

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

nmalykh@protokols.ru

Internet Engineering Task Force (IETF)                      D. Fedyk
Request for Comments: 5828                            Alcatel-Lucent
Category: Informational                                    L. Berger
ISSN: 2070-1721                                                 LabN
                                                        L. Andersson
                                                            Ericsson
                                                          March 2010

Архитектура и схема обобщенной коммутации по меткам для Ethernet

Generalized Multiprotocol Label Switching (GMPLS) Ethernet Label Switching Architecture and Framework

PDF

Аннотация

В настоящее время выполняется множество работ по расширению возможностей коммутаторов Ethernet и повышению эффективности пересылки кадров Ethernet. В результате таких работ сфера применения Ethernet расширилась до транспортных сетей, в которых традиционно использовались такие технологии, как SONET¹/SDH², TDM³ и ATM⁴. В этом документе рассматривается архитектура и схема обобщенного уровня управления для Ethernet в такой «транспортной сети». Спецификации GMPLS⁵ для подобных технологий уже существуют. В этом документе рассмотрены некоторые расширения, которые потребовались на управляющем уровне GMPLS, а также схема таких расширений.

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

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

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

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

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

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

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

1. Введение

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

Многие организации активно работают в сфере расширения технологии Ethernet для ее использования в магистральных сетях. Эта активность сосредоточена в рабочих группах IEEE⁷ 802.1, сектора стандартизации телекоммуникаций ITU-T⁸ и MEF⁹. Усилия этих групп сфокусированы на пересылке Ethernet, расширении уровня управления Ethernet и протокола Spanning Tree, но не явно маршрутизируемого уровня управления, основанного на ограничениях.

В контексте уровня пересылки определяются или будут определены расширения для поддержки различных моделей транспортной пересылки Ethernet, режимов защиты и сервисных интерфейсов. Примерами таких расширений могут служить [802.1ah], [802.1Qay], [G.8011] и [MEF.6]. Эти расширения повышают гибкость уровня пересылки Ethernet, а в некоторых случаях позволяют отказаться от пересылки на основе модели «остовного дерева¹⁰». Например, в случае [802.1ah] повышение уровня гибкости пересылки обеспечивается путем добавления «адресного пространства провайдера». [802.1Qay] поддерживает использование систем обеспечения и протоколов сетевого управления, которые явно задают пути трафика.

В этом документе дается схема коммутации меток Ethernet — GELS¹¹. Для поддержки разных моделей GELS явно требуется более одного типа коммутации и потребуется расширение процедур GMPLS в зависимости от типа коммутации. Эти вопросы будут рассматриваться в отдельных документах, связанных с конкретными технологиями.

В модели «провайдерского моста» (provider bridge), разработанной в рамках проекта IEEE 802.1ad и внесенной в стандарт IEEE 802.1Q [802.1Q], добавляется идентификатор виртуальной ЛВС (VLAN¹²) — VID. Этот VID называют сервисным VID (S-VID¹³) и он передается в специальном теге S-TAG¹⁴. В модели PBB¹⁵ [802.1ah] идентификатор опорной сети B-VID¹⁶ и заголовок B-MAC с тегом экземпляра сервиса (I-TAG) инкапсулируются в пользовательский или служебный кадр Ethernet.

В стандарте IEEE 802.1Q термины PBB и PBBN¹⁷ используются в контексте упомянутых расширений.

Пример защитного расширения Ethernet можно найти в [G.8031]. Эксплуатация, администрирование и обслуживание Ethernet (OAM¹⁸) являются другой важной сферой, которая должна быть расширена для обеспечения провайдерских услуг на основе Ethernet. Связанные с этим расширения можно найти в [802.1ag] и [Y.1731].

Модель сервиса на базе Ethernet будет определяться в контексте MEF и ITU-T. Документы [MEF.6] и [G.8011] обеспечивают основу для определения сетеориентированных характеристик сервиса Ethernet в транспортных сетях. В этих документах рассматриваются общие характеристики соединений Ethernet, интерaейсы Ethernet между пользователем и сетью (UNI¹⁹), а также межсетевые интерфейсы Ethernet (NNI²⁰). [G.8011.1] определяет сервис «частных линий Ethernet» (EPL²¹), а [G.8011.2] — сервис «виртуальных частных линий Ethernet» (EVPL²²). В [MEF.6] рассматриваются оба типа сервиса. Эти работы согласуются с типами коммутации Ethernet, определенными в [802.1ah].

Расширения Ethernet для уровней пересылки и управления позволяют отключить стандартный протокол STP²³, но не определяют явно маршрутизируемого, основанного на ограничениях²⁴ уровня управления. Например, [802.1Qay] является исправленным вариантом стандарта IEEE 802.1Q, который явно разрешает построение путей пересылки трафика Ethernet.

Работа IETF GMPLS обеспечивает общий уровень управления для различных технологий канального уровня в сетях провайдеров Internet и телекоммуникационных операторов. Архитектура GMPLS описана в RFC 3945 [RFC3945]. Спецификации протоколов GMPLS могут использоваться для управления технологиями «транспортных сетей» (например, оптических и TDM-сетей). GMPLS можно использовать также для коммутации пакетов и блоков данных канального уровня (кадров, ячеек).

В этом документе приведена схема использования GMPLS для управления «транспортными» путями коммутации по меткам Ethernet (Eth-LSP²⁵). «Транспорт» Ethernet вносит дополнительные ограничения, которые требуется отличать от ограничений в ранее специфицированных для GMPLS технологиях. Требуются новые расширения для уровня управления GMPLS и в этом документе описана основа для таких расширений. Все расширения для поддержки Eth-LSP будут строиться на базе архитектуры GMPLS и соответствующих спецификаций.

В этом документе вводится и разъясняется применение уровня управления GMPLS для транспорта Ethernet и концепция Eth-LSP. Аспекты уровня данных Eth-LSP выходят за пределы данного документа и работы IETF.

Задачей этого документа является определение согласованного использования с возможно большим числом протоколов GMPLS. Например, использование уровня управления IP обеспечивает возможность применения существующих методов сигнализации, маршрутизации, протоколов управления каналами (LMP²⁶) и расчета путей. Протоколы GMPLS поддерживают как иерархические, так и непрерывные (contiguous) LSP. Механизмы протоколов GMPLS поддерживают также множество «опорных точек» (network reference point) от UNI к NNI. Дополнения к существующим возможностям GMPLS будут вноситься только для аккомодации к уникальным особенностям транспорта Ethernet.

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

1.1.1. Концепции

Ниже приведены определения основных терминов Ethernet и GMPLS.

Asymmetric Bandwidth — асимметричная полоса

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

Bidirectional congruent LSP — двухсторонний симметричный путь

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

Contiguous Eth-LSP — непрерывный путь Eth-LSP

Непрерывный путь Eth-LSP представляет собой сквозной Eth-LSP, образованный из множества Eth-LSP, каждый из которых работает внутри VLAN и однозначно отображается на границах VLAN. «Сшитые» LSP формируют непрерывные LSP.

Eth-LSP

Путь Ethernet с коммутацией по меткам, который может контролироваться посредством GMPLS.

Hierarchical Eth-LSP — иерархический путь Eth-LSP

Иерархические пути Eth-LSP создают иерархию Eth-LSP.

In-band GMPLS signaling — сигнализация GMPLS в основной полосе

Сигнализация GMPLS в основной полосе основана на управляющих сообщениях IP, которые передаются через каналы Ethernet путем инкапсуляции в заголовок single-hop Ethernet. Логические каналы, которые используют выделенные VID на одном физическом канале, будут рассматриваться, как сигнализация в основной полосе.

Out-of-band GMPLS signaling — сигнализация GMPLS по отдельному каналу

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

Point-to-point (P2P) Traffic Engineering (TE) service instance — экземпляр сервиса TE между парой точек

Экземпляр сервиса P2P TE включает один двухсторонний или два односторонних P2P Eth-LSP.

Point-to-multipoint (P2MP) Traffic Engineering (TE) service instance — экземпляр сервиса TE между точкой и множеством точек

Экземпляр сервиса TE, поддерживаемый набором LSP, который представляет собой один «многоготочечный» путь P2MP LSP от корня к n ветвей, плюс двухсторонний симметричный P2P LSP от каждой ветви к корню.

Shared forwarding- совместная пересылка

Свойство пути передачи данных, позволяющее одну запись таблицы пересылки (VID + MAC-адрес получателя) использовать для кадров из множества источников (MAC-адреса получателей). Совместная пересылка не меняет поведения уровня данных. Такая пересылка просто экономит пространство базы данных FDB²⁷. Совместная пересылка обеспечивает похожие преимущества для слияния на уровне данных. Однако при совместной пересылке пакеты данных Ethernet не меняются. При совместной пересылке выделенные состояния управляющего уровня для всех Eth-LSP обслуживаются независимо от записей совместной пересылки.

1.1.2. Используемые сокращения

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

CCM Continuity Check Message – сообщение для проверки непрерывности.

CFM Connectivity Fault Management — контроль нарушений связности.

DMAC Destination MAC Address — MAC-адрес получателя.

Eth-LSP Ethernet Label Switched Path — путь Ethernet с коммутацией по меткам.

I-SID Backbone Service Identifier carried in the I-TAG — идентификатор магистрального сервиса в I-TAG.

I-TAG Тег экземпляра магистрального сервиса, определенный в стандарте IEEE 802.1ah [802.1ah].

LMP Link Management Protocol — протокол управления каналом.

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

MP2MP Multipoint to multipoint — множество с множеством.

NMS Network Management System — система управления сетью.

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

PBB Provider Backbone Bridges [802.1ah] — мосты опорной сети провайдера.

PBB-TE Provider Backbone Bridges Traffic Engineering [802.1Qay] — построение трафика мостов опорной сети.

P2P Point to Point — «точка-точка».

P2MP Point to Multipoint — «точка-многоточка».

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

SMAC Source MAC Address — MAC-адрес отправителя.

S-TAG Тег сервиса, определенный в стандарте IEEE 802.1 [802.1Q].

TE Traffic Engineering — построение трафика.

TAG сокращенное обозначение заголовка TAG.

TAG Header Заголовок TAG — расширение кадра Ethernet для передачи уровня приоритета и других данных.

TSpec Traffic specification — спецификация трафика.

VID VLAN Identifier — идентификатор ВЛВС.

VLAN Virtual LAN — виртуальная ЛВС (ВЛВС).

2. Основные принципы

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

Представленный в этом параграфе материал основан на завершенных и продолжающихся работах в рамках IEEE 802.1, ITU-T, MEF. В этом параграфе приводится краткий обзор работ, но он не может служить заменой первоисточникам.

2.1. Коммутация Ethernet

В терминах коммутации Ethernet мост²⁸ отвечает за пересылку и репликацию кадров. Мосты пересылают кадры на основе значений полей заголовков Ethernet — идентификаторов VLAN (VID) и MAC-адресов получателей (DMAC). В PBB [802.1ah] также определен тег экземпляра сервиса (I-TAG). Во всех расширениях Ethernet, уже упомянутых во введении, множество функций пересылки или сервисных интерфейсов определяется с использованием комбинации VID, DMAC и I-TAG. В документе PBB [802.1ah] дан анализ различных типов сервиса коммутации Ethernet, проиллюстрированный на рисунке 1.

               Типы сетевого сервиса PBB
                 _,,-'    |    '--.._
           _,.-''         |          `'--.._
     _,.--'               |                 `'--..
По портам              S-теги                 I-теги
                      _,-     -.
                   _.'          `.
                _,'               `.
         один к одному          групповой
                                _.-   =.
                            _.-'        ``-.._
                        _.-'                 `-..
                множество в один      один на множество
                                                 |
                                                 |
                                                 |
                                            прозрачный

Рисунок 1: Типы коммутируемого сервиса Ethernet

Типы коммутации определены в п. 25 стандарта [802.1ah]. Хотя это не описано явно в [802.1ah], типы сервиса Ethernet, определенные в контексте [MEF.6] и [G.8011], также относятся к типам сервиса, представленным на рисунке 1 (за исключением определенного недавно типа I-tagged).

В [802.1ah] определен новый тип сервиса I-tagged, но не определены специально типы сервиса Ethernet, которые определены в контексте [MEF.6] и [G.8011] и показаны на рисунке 1.

Обобщим определения типов сервиса.

Коммутация по портам

Этот основанный на кадрах тип сервиса поддерживает специфические типы кадров; теги Service VLAN и коммутация по MAC-адресам не используются.

S-теги

Существует множество вариантов коммутации по S-TAG, включая:

• «один-к-одному» (взаимно-однозначный)

В этом случае каждое значение VID отображается на свой тип сервиса.

• групповой (bundled)

В этом случае поддерживается отображение множества VID на один тип сервиса, включая:

• множество на один

В этом сервисе на основе кадров множество VID отображается на один тип сервиса.

• все на один

В этом сервисе на основе кадров все VID отображаются на один тип сервиса.

• прозрачный

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

I-теги

Периметр PBBN включает транслятор опорной сети (backbone relay или B-component relay) и транслятор экземпляра сервиса (service instance relay — I-component relay). I-TAG содержит 24-битовый идентификатор сервиса I-SID и маркеры приоритета, а также некоторые другие поля. Сервис I-tagged обычно организуется между краевыми узлами PBBN и завершается на I-компоненте каждого узла, которая «прикрывает» пользовательский порт так, что сервис часто остается невидимым за пределами краевых устройств. Однако, поскольку транслятор I-компоненты включает другой транслятор, можно получить видимый сервис с I-тегами путем отделения транслятора I-компоненты от транслятора B-компоненты. Ситуации, когда это следует делать, включают сервис I-tagged между двумя PBBN и подключение к пользовательскому порту Provider Instance Port.

В общем случае тип коммутации определяет, какие из полей заголовка Ethernet используются функцией пересылки/коммутации (например, только VID или VID и DMAC). Тип коммутации также может потребовать использования дополнительных заголовков Ethernet или полей в заголовках. В типах сервиса, определенных для UNI, имеется тенденция использования заголовков для запроса сервиса (service delimiter) на стыке между сайтом пользователя и периметром сети.

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

Для всех типов сервиса уровень данных является двухсторонним и симметричным. Это означает, что прямой и обратный путь используют один и тот же набор узлов, портов и двухсторонних каналов. Это свойство является фундаментальным. Группа 802.1 поддерживает это свойство двухсторонней симметрии в определении CFM²⁹, являющегося частью OAM.

2.2. Эксплуатация, администрирование и обслуживание (OAM)

Отказоустойчивость повышается при добавлении OAM для уровня данных с поддержкой контроля отказов и управления производительностью.

Сообщения Ethernet OAM ([802.1ag] и [Y.1731]) основаны на пересылке кадров уровня данных в обоих направлениях. Определение прерванного пути или некорректно направленного пакета в этом случае основано на сообщении OAM, передаваемом вслед за Eth-LSP. Идентификаторы таких сообщений OAM зависят от уровня данных, поэтому они так же хорошо работают для путей, управляемых с помощью GMPLS.

Сообщения Ethernet OAM в настоящее время включают:

[802.1ag] и [Y.1731]:

• CCM³⁰/RDI³¹ — проверка непрерывности/индикация удаленного дефекта;
• LBM/LBR³² — сообщение/отклик проверки по петле;
• LTM/LTR³³ — сообщение/отклик трассировки канала;
• VSM/VSR³⁴ — специфическое для производителя сообщение/отклик.

[Y.1731]:

• AIS³⁵ — сигнал тревоги;
• LCK³⁶ — сигнал блокировки;
• TST — тест;
• LMM/LMR³⁷ — сообщение/отклик замера потерь;
• DM³⁸ — измерение задержки;
• DMM/DMR³⁹ — сообщение/отклик замера задержки;
• EXM/EXR⁴⁰ — сообщение/отклик для экспериментов;
• APS, MCC⁴¹ — автоматическое переключение защиты, служебный коммуникационный канал.

Эти функции поддерживаются для всех стандартизованных форматов Eth-LSP.

2.3. Характеристики коммутации Ethernet

Технологии Ethernet и MPLS похожи в части инкапсуляции разнотипных пакетов и кадров для передачи данных. В Ethernet инкапсулированные данные называют данными MAC-клиента. Кадр Ethernet MAC с инкапсуляцией включает заголовок, адреса отправителя и получателя, необязательнее поле идентификатора VLAN, тип и размер данных клиента (вместе с возможным заполнением), а также контрольную сумму FCS⁴² в конце кадра.

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

Коммутаторы Ethernet с функциями моста используют для пересылки MAC-адрес получателя и номер VLAN. Номер VLAN идентифицирует некий набор (возможно активных) мостов и ЛВС. Адрес предполагается уникальным и инвариантным в рамках VLAN. MAC-адрес зачастую являются уникальными в глобальном масштабе, но для работы мостов это не требуется.

3. Модель

В соответствии с архитектурой GMPLS, определенной в [RFC3945], уровень управления GMPLS может быть применен к некой технологии путем управления уровнем данных и коммутационными характеристиками этой технологии. В соответствии с [RFC3945] архитектура GMPLS позволяет использовать для управления мостами Ethernet и другими технологиями канального уровня коммутацию типа L2SC⁴³. Однако управление коммутацией Ethernet не было явно определено в [RFC3471], [RFC4202] или каком-либо из последующих документов GMPLS.

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

Все аспекты GMPLS (адресация, сигнализация, маршрутизация и управление каналами) применимы к коммутации Ethernet. GMPLS может обеспечить управление для сервисных путей Ethernet с защитой и построением трафика. В этом документе определен термин Eth-LSP для обозначения сервисных путей Ethernet, контролируемых с помощью GMPLS. Как и другие типы сервиса, управляемые через GMPLS, пути Eth-LSP могут использовать общие атрибуты построения трафика, типа перечисленных ниже:

• профиль полосы пропускания;
• уровень приоритета пересылки;
• параметры «покупки» соединений;
• возможности защиты/быстрого восстановления;
• правила маршрутизации (например, явные маршруты);
• двухсторонний сервис;
• сквозная и посегментная защита;
• иерархия.

Профиль полосы пропускания может использоваться для задания согласованной скорости передачи данных, пиковой скорости передачи и правил для случаев превышения или недостаточной нагрузки. Службы, управляемые по такой схеме, будут использовать TSpec для поддержки параметров трафика Ethernet, которые определены в [ETH-TSPEC].

При использовании GMPLS для «транспорта» Ethernet потребуется расширение GMPLS для работы с уровнем данных Ethernet и функциями коммутации. Определение поддержки Ethernet в GMPLS является многогранным по причине различий в функциях пересылки/коммутации, присущих различным типам сервиса, рассмотренным в параграфе 2.1. В общем случае поля заголовка, используемые функцией коммутации/пересылки (например, VID и DMAC), могут характеризоваться, как метки уровня данных. В некоторых ситуациях эти поля могут быть неизменными на пути Eth-LSP, а при других условиях они могут меняться на каждом этапе пересылки или на некоторых интерфейсах вдоль пути. В тех случаях, когда «метки» должны пересылаться без изменения, возникают незначительные ограничения при распределении меток, как в некоторых других технологиях (например, коммутации по «лямбдам⁴⁴»)..

Характеристики уровня данных «транспорта» Ethernet не требуется менять для управления с помощью GMPLS. В качестве примера рассмотрим уровень данных IEEE 802.1Q [802.1Q]. Значение VID используется в качестве «фильтра», указывающего на определенную таблицу пересылки, и, если значение DMAC найдено в таблице, решение о пересылке принимается на базе DMAC. Если для пересылки используется связующее дерево и значение DMAC не найдено в таблице, применяется широковещательная пересылка через все выходные интерфейсы, для которых определено данное значение VID. Такая проверка MAC-адресов и широковещательная пересылка корректны и позволяют выполнить «обучение». В специальном случае, когда значение VID определено только для пары портов, пересылка осуществляется в режиме «точка-точка» (P2P). В этом случае все кадры, помеченные данным значением VID, принимаются через один из пары портов и пересылаются в другой порт пары без необходимости «обучения».

Стандарт [802.1Qay] позволяет отключить обучение и, следовательно, механизм широковещания, что обеспечивает возможность организации явно маршрутизируемых соединений Ethernet.

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

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

Тип коммутации (Switching Type) и дескриптор возможностей коммутации интерфейса (Interface Switching Capability Descriptor) используют общий набор значений и определены в [RFC3945], [RFC3471] и [RFC4202], как индикаторы типа коммутации, которую следует ([RFC3471]) и можно ([RFC4202]) осуществить на конкретном канале для LSP. Тип коммутации L2SC уже может использоваться реализациями коммутаторов канального уровня (включая Ethernet). В связи с этим и для сохранения возможности использования этого типа коммутации и существующих коммутаторов, а также для того, чтобы различать две парадигмы коммутации Ethernet, требуется определить новый тип коммутации для каждой поддерживаемой парадигмы коммутации Ethernet.

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

4. Модель маршрутизации и адресации GMPLS

Этот документ не меняет модели маршрутизации и адресации GMPLS. Управление GMPLS для путей Eth-LSP использует модель маршрутизации и адресации, описанную в [RFC3945]. Важно отметить, что эта модель включает использование адресов IP для идентификации интерфейсов и конечных точек LSP, а также поддержку безадресных интерфейсов.

В тех случаях, когда для поддержки того или иного сервиса Ethernet требуется другое семейство адресов или тип идентификаторов, могут определяться специальные расширения для отображения на адреса IP. Предполагается, что поддержка Eth-LSP будет строго соответствовать схеме адресации стека протоколов GMPLS, описанного в [RFC3471], [RFC3473] и других документах.

4.1. Маршрутизация GMPLS

Маршрутизация GMPLS в соответствии с определением [RFC4202] использует протоколы маршрутизации IP с TLV-расширением для поддержки распространения связанной с GMPLS информации TE (маршрутизатор и канал). Как всегда бывает в GMPLS, информация TE заполняется на основе данных о ресурсах, полученных от LMP или из параметров конфигурации. Ресурсы полосы каналов определяются при организации Eth-LSP. Интерфейсы, поддерживающие коммутацию Eth-LSP, идентифицируются по соответствующим дескрипторам возможностей (ISC⁴⁵). Как отмечено в параграфе 3, предполагается определение одного или множества ISC для поддержки путей Eth-LSP. И снова L2SC ISC не будут использоваться для представления поддерживающих Eth-LSP интерфейсов, которые определены в данном документе и последующих работах для поддержки парадигмы коммутации транспорта Ethernet. Кроме того, для поддержки требований конкретного типа коммутируемого сервиса Ethernet при необходимости может быть определена относящаяся к ISC информация TE .

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

4.2. Сеть управления

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

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

Такая связность IP может обеспечиваться за счет отдельной независимой сети (out-of-band) или через сеть коммутаторов Ethernet (in-band).

5. Сигнализация GMPLS

Сигнализация GMPLS ([RFC3471] и [RFC3473]) хорошо подходит для управления путями Eth-LSP и коммутаторами Ethernet. Сигнализация обеспечивает возможность динамической организации пути от входного узла к выходному. Полученный с помощью сигнализации путь может быть полностью статическим и неизменным в течение всего срока жизни. Однако сигнализация также позволяет динамически изменять путь после его создания. Выбор статического или динамического варианта определяется оператором. Стандартизованная сигнализация повышает уровень взаимодействия между операторами.

Сигнализация GMPLS поддерживает организацию и контроль для односторонних и двухсторонних путей. Технология Ethernet является двухсторонней и CFM⁴⁶ создаются для усиления этого. До разработки CFM в двухсторонних соединениях использовались эмуляция провода и требования по обучению. В соответствии со сказанным от путей Eth-LSP требуется двухсторонняя симметрия. Eth-LSP может представлять собой P2P или P2MP (см. [RFC4875]). Сигнализация GMPLS также позволяет организовать полную или частичную защиту LSP (см. [RFC4872] и [RFC4873]).

Отметим, что стандарт GMPLS не поддерживает различной полосы для каждого направления двухсторонних LSP. В [RFC5467] и экспериментальных документах рассматриваются процедуры для тех случаев, когда на двухсторонних соединениях требуется асимметрия.

6. Управление каналом

Обнаружение каналов было специфицировано для мостов IEEE 802.1 в стандарте [802.1AB]. Преимущества обнаружения каналов в больших системах весьма существенны. Обнаружение каналов может снижать сложность настройки и вероятность возникновения недетектируемых ошибок в конфигурации, а также создания ошибочных соединений. Однако поддержка 802.1AB является необязательной, поэтому она может отсутствовать до активизации канала и поддерживает преимущественно уровень управления.

В контексте GMPLS был определен протокол управления каналом (LMP) [RFC4204] для поддержки управления каналами и автоматического детектирования на уровне управления GMPLS. LMP также поддерживает автоматизированное создание безадресных интерфейсов для уровня управления. Если LMP не используется, возникают дополнительные конфигурационные требования к идентификаторам каналов GMPLS. Для крупных реализаций предпочтительно использование LMP. Протокол LMP также имеет опции контроля отказов, прежде всего для использования с прозрачными и «темными» (opaque) сетевыми технологиями. С новыми возможностями IEEE CFM [802.1ag] и ITU-T [Y.1731] такая функция может остаться невостребованной. Задачей архитектуры GMPLS Ethernet является обеспечение возможности выбора наилучшего набора средств в соответствии с потребностями пользователей. При использовании уровня управления GMPLS следует применять всю функциональность Ethernet CFM .

LMP и 802.1AB сравнительно независимы. Поддержки LMP должно быть достаточно для того, чтобы обойтись без 802.1AB, однако при желании 802.1 AB можно независимо использовать в параллель. На рисунке 2 показаны возможные варианты одновременного применения LMP, 802.1AB и 802.1ag.

     +-------------+        +-------------+
     | +---------+ |        | +---------+ |
     | |         | |        | |         | |Корреляция
     | |  LMP    |-|<------>|-|  LMP    | |свойств
     | |         | |        | |         | |каналов GMPLS
     | |  (opt)  | |GMPLS   | |  (opt)  | |
     | |         | |        | |         | |Связывание
     | +---------+ |        | +---------+ |
     | +---------+ |        | +---------+ |
     | |         | |        | |         | |
     | | 802.1AB |-|<------>|-| 802.1AB | |идентификаторы
     | |  (opt)  | |Ethernet| |  (opt)  | |каналов P2P
     | |         | |        | |         | |
     | +---------+ |        | +---------+ |
     | +---------+ |        | +---------+ |
     | |         | |        | |         | |Сквозной
-----|-| 802.1ag |-|<------>|-| 802.1ag |-|-------
     | | Y.1731  | |Ethernet| | Y.1731  | |Контроль отказов
     | |  (opt)  | |        | |  (opt)  | |Управление
     | |         | |        | |         | |производительностью
     | +---------+ |        | +---------+ |
     +-------------+        +-------------+
       Коммутатор 1   Канал   Коммутатор 2

Рисунок 2: Опции управления логическим каналом

Рисунок 2 иллюстрирует функциональные соотношения между схемами управления каналами и OAM. Предполагается, что LMP будет использоваться для функций сопоставления свойств каналов на уровне управления, а механизмы Ethernet для OAM (такие, как CFM, трассировка каналов и т. п.) будут применяться на уровне данных для контроля и трассировки отказов.

7. Расчет и выбор пути

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

Пути Eth-LSP могут могут поддерживаться с использованием любых механизмов выбора или расчета путей. Как в любой функции выбора пути GMPLS и любом механизме выбора пути, в процессе выбора пути должны приниматься во внимание возможности коммутации и кодирования, анонсируемые конкретным интерфейсом. Eth-LSP можно также создавать с использованием методик, описанных в [RFC4655].

8. Множество VLAN

Этот документ позволяет поддерживать сигнализацию для параметров Ethernet через множество VLAN, поддерживающих как непрерывные Eth-LSP, так и Hierarchical Ethernet LSP. Смысл этого заключается в том, чтобы использовать иерархию GMPLS для поддержки одноранговых моделей, UNI и NNI.

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

Для управляемых с помощью GMPLS «транспортных» систем Ethernet следует иметь в виду, что пользователи и устройства, подключенные к UNI, могут вести себя враждебно, небрежно или некорректно. Трафик управления внутри сети провайдера предполагается доверенным. В общем случае эти требования не отличаются от требований безопасности для любой сети GMPLS. Доступ в доверенную сеть будет осуществляться только по протоколам, определенным для UNI или NNI, и через защищенные интерфейсы управления.

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

Если GMPLS используется только для управления VLAN, для портов UNI могут потребоваться общепринятые средства защиты от атак на службы (DoS) Ethernet.

Более подробное обсуждение вопросов безопасности MPLS и GMPLS проводится в документе [SECURITY]. Для защиты от множества атак можно использовать криптографические методы [SECURITY]. Одной из опций защиты «транспорта» Ethernet является использование технологии защиты управления доступом к среде⁴⁷ 802.1AE [802.1AE], обеспечивающей шифрование и аутентификацию. Предполагается, что документы по конкретным решениям будут включать полное рассмотрение вопросов безопасности, возникающих в связи с вводимым расширением.

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

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

[RFC3471] Berger, L., Ed., «Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description», RFC 3471, January 2003.

[RFC3473] Berger, L., Ed., «Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions», RFC 3473, January 2003.

[RFC3945] Mannie, E., Ed., «Generalized Multi-Protocol Label Switching (GMPLS) Architecture», RFC 3945, October 2004.

[RFC4202] Kompella, K., Ed., and Y. Rekhter, Ed., «Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)», RFC 4202, October 2005.

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

[802.1AB] «IEEE Standard for Local and Metropolitan Area Networks, Station and Media Access Control Connectivity Discovery», IEEE 802.1AB, 2009.

[802.1AE] «IEEE Standard for Local and metropolitan area networks Media Access Control (MAC) Security», IEEE 802.1AE-2006⁴⁹, August 2006.

[802.1ag] «IEEE Standard for Local and Metropolitan Area Networks — Virtual Bridged Local Area Networks — Amendment 5: Connectivity Fault Management», IEEE 802.1ag⁵⁰, 2007.

[802.1ah] «IEEE Standard for Local and Metropolitan Area Networks — Virtual Bridged Local Area Networks — Amendment 6: Provider Backbone Bridges», IEEE Std 802.1ah-2008⁵¹, August 2008.

[802.1Q] «IEEE standard for Virtual Bridged Local Area Networks», IEEE 802.1Q-2005⁵², May 2006.

[802.1Qay] «IEEE Standard for Local and Metropolitan Area Networks — Virtual Bridged Local Area Networks — Amendment 10: Provider Backbone Bridge Traffic Engineering», IEEE Std 802.1Qay-2009, August 2009.

[ETH-TSPEC] Papadimitriou, D., «Ethernet Traffic Parameters», Work in Progress, January 2010.

[G.8011] ITU-T Recommendation G.8011⁵³, «Ethernet over Transport — Ethernet services framework», January 2009.

[G.8011.1] ITU-T Recommendation G.8011.1/Y.1307.1⁵⁴, «Ethernet private line service», January 2009.

[G.8011.2] ITU-T Recommendation G.8011.2/Y.1307.2⁵⁵, «Ethernet virtual private line service», January 2009.

[G.8031] ITU-T Recommendation G.8031, «Ethernet linear protection switching», November 2009.

[MEF.6] The Metro Ethernet Forum MEF 6, «Ethernet Services Definitions — Phase I», 2004⁵⁶.

[RFC4204] Lang, J., Ed., «Link Management Protocol (LMP)», RFC 4204, October 2005.

[RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S. Yasukawa, Ed., «Extensions to Resource Reservation Protocol — Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs)», RFC 4875, May 2007.

[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, «A Path Computation Element (PCE)-Based Architecture», RFC 4655, August 2006.

[RFC4872] Lang, J., Ed., Rekhter, Y., Ed., and D. Papadimitriou, Ed., «RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery», RFC 4872, May 2007.

[RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel, «GMPLS Segment Recovery», RFC 4873, May 2007.

[RFC5467] Berger, L., Takacs, A., Caviglia, D., Fedyk, D., and J. Meuric, «GMPLS Asymmetric Bandwidth Bidirectional Label Switched Paths (LSPs)», RFC 5467, March 2009.

[SECURITY] Fang, L., Ed., «Security Framework for MPLS and GMPLS Networks», Work in Progress, October 2009.

[Y.1731] ITU-T Recommendation Y.1731⁵⁷, «OAM Functions and Mechanisms for Ethernet based Networks», February 2008.

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

На начальных этапах работы в ней принимало участие множество людей. Документы по основам GELS и расширению PBB-TE оказали существенную помощь при выполнении работы по подготовке данного документа. Благодарим за работу авторов первоначальных документов: Dimitri Papadimitriou, Nurit Sprecher, Jaihyung Cho, Dave Allan, Peter Busschbach, Attila Takacs, Thomas Eriksson, Diego Caviglia, Himanshu Shah, Greg Sunderwood, Alan McGuire, Nabil Bitar.

George Swallow внес существенный вклад в подготовку данного документа.

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

Don Fedyk

Alcatel-Lucent

Groton, MA, 01450

Phone: +1-978-467-5645

EMail: donald.fedyk@alcatel-lucent.com

Lou Berger

LabN Consulting, L.L.C.

Phone: +1-301-468-9228

EMail: lberger@labn.net

Loa Andersson

Ericsson

Phone: +46 10 717 52 13

EMail: loa.andersson@ericsson.com

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

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

nmalykh@protokols.ru

Internet Engineering Task Force (IETF)                   K. Sandlund
Request for Comments: 5795                              G. Pelletier
Obsoletes: 4995                                             Ericsson
Category: Standards Track                               L-E. Jonsson
ISSN: 2070-1721                                           March 2010

Модель отказоустойчивой компрессии заголовков ROHC

The RObust Header Compression (ROHC) Framework

PDF

Аннотация

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

Модель ROHC вместе с набором профилей сжатия была изначально предложена в RFC 3095. Для развития и упрощения спецификаций ROHC в этом документе явно разделены определения модели ROHC и профиля без компрессии. Приводимое здесь определение модели не меняет и не обновляет модели, описанной в RFC 3095.

Эта спецификация отменяет RFC 4995. Решена проблема взаимодействия, ошибочно внесенная в RFC 4995, и добавлены некоторые разъяснения.

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

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

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

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

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

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

К этому документу применимы права и ограничения, перечисленные в 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. Введение

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

Для каналов, где используются заголовки IP, суммарный размер этих заголовков может быть достаточно большим. Приложения, передающие данные по протоколу RTP [RFC3550], в дополнение к кадрированию канального уровня используют заголовок IPv4 [RFC0791] (20 октетов), заголовок UDP [RFC0768] (8 октетов) и заголовок RTP (12 октетов), что в сумме добавляет 40 октетов. При использовании IPv6 [RFC2460] заголовок IPv6 составит 40 октетов, а общий размер достигнет 60 октетов. Приложения, использующие протокол TCP [RFC0793], будут добавлять 20-октетный заголовок транспортного уровня и общий размер составит 40 октетов для IPv4 и 60 октетов для IPv6.

Относительный эффект компрессии для конкретных потоков (или приложений) зависит от используемого размера пакетов. Для приложений типа VoIP³, где размер данных, служащих для передачи голоса, может быть достаточно мал (15-20 октетов), компрессия заголовков может давать существенный эффект. Относительная эффективность для потоков TCP с большими пакетами (например, копирование файлов) будет значительно меньше, чем для потоков с мелкими пакетами (например, сигнализация или организация сессий).

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

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

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

В RFC 3095 [RFC3095] определена схема ROHC и стартовый набор профилей сжатия. Для развития и упрощения спецификации модель и профили были разнесены в отдельные документы. Этот документ явно определяет модель ROHC, не меняя и не обновляя определения, данного в RFC 3095 (оба документа могут использоваться независимо один от другого). Реализации, основанные на определениях того и другого документа будут совместимы и смогут взаимодействовать. Однако, эту спецификацию следует рассматривать как замену RFC 3095 в качестве базовой спецификации для всех профилей, определяемых в будущем.

В этом документе исправления возникшая в RFC 4995 ошибка, приводящая к проблемам совместимости. Исправление приведено в параграфе 5.2.4.1 и связано с уточнением интерпретации поля Size в обратной связи ROHC.

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

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

2.1. Сокращения

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

ACK Acknowledgment — подтверждение.

CID Context Identifier — идентификатор контекста.

CO Compressed Packet Format — формат сжатого пакета.

CRC Cyclic Redundancy Check — контрольная сумма.

IR Initialization and Refresh — инициализация и обновление.

IR-DYN Initialization and Refresh, Dynamic part — инициализация и обновление, динамическая часть.

LSB Least Significant Bit — наименее значимый (младший) бит.

MRRU Maximum Reconstructed Reception Unit — максимальный восстанавливаемый на приеме блок.

MSB Most Significant Bit — наиболее значимый (старший) бит.

MSN Master Sequence Number — основной порядковый номер.

NACK Negative Acknowledgment — негативное подтверждение.

ROHC RObust Header Compression — сильная компрессия заголовков.

2.2. Терминология ROHC

Context — контекст

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

Context damage — повреждение контекста

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

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

Context repair mechanisms — механизмы исправления контекста

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

CRC-8 validation — проверка CRC-8

Проверка целостности в плане битовых ошибок для принятого заголовка IR и IR-DYN с использованием 8-битовой контрольной суммы CRC, включенной в заголовок IR/IR-DYN.

CRC verification — проверка CRC

Проверка результата попытки декомпрессии с использованием 3-битовых или 7-битовых контрольных сумм CRC, включенных в сжатый заголовок пакета.

Damage propagation — распространение повреждений

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

Error detection — детектирование ошибок

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

Error propagation — распространение ошибок

Распространение повреждений или потерь.

ROHC profile — профиль ROHC

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

Link — канал

Физический путь передачи, образующий один интервал IP (hop).

Loss propagation — распространение потерь

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

Packet flow — поток пакетов

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

Residual error — остаточная ошибка

Ошибка, возникшая в процессе передачи и не обнаруженная на нижележащих уровнях.

ROHC channel — канал ROHC

Логический односторонний канал «точка-точка», передающий пакеты ROHC от одного компрессора к одному декомпрессору и опционально передающий данные обратной связи ROHC от имени другой пары компрессор-декомпрессор, работающей по отдельному каналу ROHC в противоположном направлении (см. также [RFC3759]).

В этом документе используется также концептуальная терминология из документа ROHC Terminology and Channel Mapping Examples [RFC3759].

3. Основы (информационный раздел)

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

3.1. Основы компрессии заголовков

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

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

3.2. Краткая история компрессии заголовков

Первая схема компрессии заголовков CTCP⁴ [RFC1144] была предложена Van Jacobson. Схема CTCP, которую называют также компрессией VJ, позволяет уменьшить 40-октетные заголовки TCP/IP до 4 октетов. CTCP использует дельта-кодирование для последовательно изменяющихся полей. Компрессор CTCP детектирует повторы передачи на транспортом уровне и передает в таких случаях заголовок, обновляющий весь контекст. Такой механизм исправления не требует явной сигнализации между компрессором и декомпрессором.

В общей схеме компрессии заголовков IP (IPHC⁵) [RFC2507] достигнуты некоторые улучшения по сравнению с CTCP. IPHC позволяет сжимать любые заголовки IP, TCP и UDP. При сжатии заголовков, отличных от TCP, в IPHC не используется дельта-кодирование и это обеспечивает отказоустойчивость. Механизм исправления CTCP дополнен здесь негативными подтверждениями (их называют сообщениями CONTEXT_STATE), которые повышают скорость исправления. Скорость работы этого механизма исправления ограничивается временем кругового обхода для канала. IPHC не сжимает заголовки RTP.

CRTP [RFC2508] является расширением IPHC для протокола RTP. CRTP сжимает 40 октетов заголовков IPv4/UDP/RTP до 2 октетов при отключенных контрольных суммах UDP. При использовании UDP минимальный размер заголовков CRTP составляет октета.

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

CRTP использует механизм локального исправления TWICE, который был предложен в IPHC. Имя TWICE происходит от того, что для регулярных сжатых пакетов корректное предсказание потери пакета между точками компрессии определяется двойным (twice) обновлением в текущем пакете. Хотя механизм TWICE значительно повышает производительность CRTP, в [CRTP-eval] отмечено, что даже при его использовании протокол CRTP удваивает число теряемых пакетов.

Улучшенный вариант протокола CRTP, названный eCRTP [RFC3545], повышает отказоустойчивость CRTP при наличии разупорядочивания и потери пакетов, сохраняя сам протокол CRTP почти без изменений. В результате eCRTP обеспечивает повышение уровня отказоустойчивости, но за счет добавочных издержек несколько уступает протоколу CRTP по эффективности компрессии.

4. Обзор ROHC (информационный раздел)

4.1. Общие принципы

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

Первый этап включает идентификацию и группировку пакетов в различные «потоки» с максимальной избыточностью в рамках каждого потока для обеспечения максимальной сжимаемости. Группировка пакетов в потоки обычно осуществляется по адресам хостов отправителя и получателя (IP), типу протокола транспортного уровня (например, UDP или TCP), номерам процессов (портов) и, возможно, дополнительным уникальным идентификаторам приложений типа источника синхронизации (SSRC⁶) в RTP [RFC3550]. Компрессор и декомпрессор организуют контекст для потока пакетов и обозначают его идентификатором контекста CID⁷ включаемым в сжатый заголовок.

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

INFERRED — производные

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

STATIC — статический

Статические поля предполагаются неизменными в течение срока жизни потока. Значение такого поля достаточно передать один раз в начале потока.

STATIC-DEF — статические поля, определяющие принадлежность к потоку

Поля типа STATIC-DEF используются для определения потока, как отмечено выше. Пакеты, в которых соответствующие поля различаются, относят к разным потокам. В общем случае эти поля сжимаются, как STATIC.

STATIC-KNOWN — статические известные поля

Предполагается, что поля, относящиеся к типу STATIC-KNOWN, содержат общеизвестные значения, передавать которые, следовательно, не требуется.

CHANGING — меняющиеся

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

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

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

4.2. Эффективность, отказоустойчивость и прозрачность компрессии

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

Эффективность сжатия

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

Отказоустойчивость

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

Прозрачность сжатия

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

4.3. Развитие протокола ROHC

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

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

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

Документ RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed [RFC3095] был опубликован в 2001 году, как первый результат ROHC WG. Модель ROHC является обобщенной и расширяемой схемой компрессии заголовков, на основе которой могут определяться профили сжатия для различных протоколов. В RFC 3095 предложено множество новых методов компрессии, показавших соответствие предъявляемым требованиям, как описано в [RFC3096].

Тестирование взаимодействия RFC 3095 подтверждает возможности ROHC в части заявленных целей, но сообщения от разработчиков показали, что спецификация чересчур сложна и не всегда понятна. Один из основных недостатков заключался в том, что базовую модель и профили было достаточно сложно разделить в [RFC3095], что также осложняет разработку дополнительных профилей. Поэтому цель данного документа заключается в явной спецификации модели ROHC, а пересмотренные профили сжатия RFC 3095 приведены в отдельном документе [RFC5225].

4.4. Операционные характеристики канала ROHC

Отказоустойчивая компрессия заголовков может использоваться со многими технологиями канального уровня. Модель ROHC обеспечивает гибкость профилей для решения задач различных приложений и в этом параграфе кратко рассмотрены некоторые операционные характеристики каналов ROHC (см. также [RFC3759]).

Мультиплексирование через один логический канал

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

Организация канальных параметров

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

Идентификация типа пакетов

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

Нарушение порядка доставки пакетов между конечными точками компрессии

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

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

Профили ROHCv2, заданные в [RFC5225], предполагают, что декомпрессор может получать пакеты с нарушением порядка (т. е., не в том порядке, в котором они были переданы компрессором). Нарушение порядка доставки в точку компрессии также учитывается в этих профилях.

Дублирование пакетов

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

Кадрирование

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

Детектирование ошибок и защита от них

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

4.5. Компрессия и порядковый номер MSN

Компрессия полей заголовков основывается на организации функции от номера пакета (MSN⁸), которая описывает картину изменения полей по мере изменения MSN.

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

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

MSN определяется на уровне профиля. Значение может извлекаться непосредственно из какого-либо поля сжимаемого заголовка (например, RTP SN [RFC5225]) или создаваться и поддерживаться самим компрессором (например, MSN для сжатия UDP в профиле 0x0102 [RFC5225] или MSN в ROHC-TCP [RFC4996]).

4.6. Статические и динамические части контекста

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

Статическая часть включает информацию, требуемую для сжатия и декомпрессии полей класса STATIC, STATIC-KNOWN или STATIC-DEF (см. параграф 4.1).

Динамическая часть включает состояния, поддерживаемые для всех прочих полей (т. е. полей класса CHANGING).

5. Модель ROHC (нормативный раздел)

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

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

5.1. Канал ROHC

5.1.1. Контексты и их идентификаторы

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

Контекст считается новым, когда CID связывается с профилем в первый раз с момента создания канала ROHC или CID связывается с получением IR (не IR-DYN) для профиля, отличающегося от профиля контекста.

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

Пространство CID может быть небольшим (значения от 0 до 15) или большим (от 0 до 2¹⁴ — 1 = 16383). Решение о размере пространства CID должно приниматься (возможно, путем согласования) до того, как можно будет передать первый пакет через канал ROHC.

Пространство CID организуется независимо доя каждого канала. Например, CID 3 для канала A и CID 3 для канала B не указывают на один контекст даже в тех случаях, когда конечные точки каналов A и B совпадают. В частности значения CID для любой пары каналов ROHC не связаны между собой (двум связанным каналам ROHC, каждый из которых используется в качестве канала обратной связи для другого, даже не требуется использовать пространства CID одного размера).

5.1.2. Поканальные параметры

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

LARGE_CIDS

Логическая переменная. Значение false говорит о малом пространстве CID (0 октетов или один префиксный октет, значения CID от 0 до 15), значение true — о большом пространстве CID (1 или 2 октета CID, значения CID от 0 до 16383). См. также параграфы 5.1.1 и 5.2.1.3.

MAX_CID

Неотрицательное целое число. Максимальный номер CID, который будет использоваться компрессором (отметим, что этот параметр не связан с LARGE_CIDS, но в дальнейшем может быть ограничен этим параметром). Это значение представляет согласие декомпрессора на выделение ресурсов памяти, достаточных для обслуживания по крайней мере MAX_CID+1 контекстов; декомпрессор должен поддерживать организованные контексты в этом пространстве, пока значение CID не будет использовано снова путем организации нового контекста или канала не прекратит существование.

PROFILES

Множество неотрицательных целых чисел, каждое из которых указывает профиль, поддерживаемый компрессором и декомпрессором. Профили идентифицируются 16-битовыми значениями, в которых 8 младших битов указывают реальный профиль, а 8 старших — вариант этого профиля. Формат сжатого заголовка ROHC идентифицирует используемый профиль только 8 младшими битами LSB — это означает, что при наличии у профиля вариантов во множество PROFILES после согласования недопустимо включать более одного варианта данного профиля. Компрессору недопустимо сжимать заголовки с использованием профилей, не включенных в PROFILES.

FEEDBACK_FOR

Необязательная ссылка на канал ROHC в обратном направлении между теми же конечными точками. При наличии этого параметра он указывает в какой канал ROHC передается вся обратная связь для данного канала ROHC (см. [RFC3759]).

MRRU⁹

Неотрицательное целое число. Показывает максимальный размер (в октетах) восстанавливаемого блока, который декомпрессор может собрать из сегментов (см. параграф 5.2.5). Это значение включает контрольную сумму сегментации. Если согласовано MRRU = 0, сегментацию недопустимо использовать на канале, а полученные сегменты должны отбрасываться декомпрессором.

5.1.3. Продолжительность контекста декомпрессора

Как часть согласования параметров канала, компрессор и декомпрессор с помощью параметра MAX_CID договариваются о максимальном используемом идентификаторе контекста (CID). Соглашаясь с MAX_CID, декомпрессор принимает на себя обязательство по выделению памяти для поддержки не менее MAX_CID+1 контекстов и контексты со значениями CID в этом согласованном пространстве декомпрессору следует сохранять, пока значение CID не будет использовано заново или пока канал не будет разорван или согласован заново.

5.2. Пакеты ROHC и их типы

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

Схема индикации типа пакета ROHC разработана так, чтобы обеспечивалось необязательное поле заполнения, поле типа пакетов обратной связи, необязательный октет Add-CID (включает 4 бита CID) и простой механизм сегментации-сборки.

На уровне модели ROHC зарезервировано несколько типов пакетов:

11100000 : заполнение
1110nnnn : октет Add-CID (nnnn=CID со значениями от 0x1 до 0xF)
11110    : обратная связь
11111000 : пакет IR-DYN
1111110  : пакет IR
1111111  : сегмент

В отдельных профилях могут определяться и использоваться другие типы пакетов:

0        : доступно (не резервируется моделью ROHC)
10       : доступно (не резервируется моделью ROHC)
110      : доступно (не резервируется моделью ROHC)
1111101  : доступно (не резервируется моделью ROHC)
11111001 : доступно (не резервируется моделью ROHC)

5.2.1. Общий формат пакетов ROHC

Базовый формат пакета ROHC показан на рисунке.

       --- --- --- --- --- --- --- ---
      :           Padding             :
       --- --- --- --- --- --- --- ---
      :           Feedback            :
       --- --- --- --- --- --- --- ---
      :            Header             :
       --- --- --- --- --- --- --- ---
      :           Payload             :
       --- --- --- --- --- --- --- ---

Padding — заполнение

Произвольное (0 или больше) число октетов заполнения, формат которых определен в параграфе 5.2.1.1.

Feedback — обратная связь

Произвольное (0 или больше) число элементов обратной связи, формат которых определен в параграфе 5.2.4.1.

Header — заголовок

Специфический для профиля заголовок CO (см. параграф 5.2.1.3), заголовок IR или IR-DYN (см. параграф 5.2.2) или сегмент ROHC (см. параграф 5.2.5). В пакете ROHC не может быть более одного заголовка, который может отсутствовать, если пакет содержит только обратную связь (поле Feedback).

Payload — данные

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

В пакете должно присутствовать по крайней мере одно поле Feedback или Header.

5.2.1.1. Формат октета заполнения

Октет заполнения показан на рисунке.

        0   1   2   3   4   5   6   7
      +---+---+---+---+---+---+---+---+
      | 1   1   1   0   0   0   0   0 |
      +---+---+---+---+---+---+---+---+

Отметим, что октет Padding недопустимо интерпретировать, как октет Add-CID для CID 0.

5.2.1.2. Формат октета Add-CID

Октет Add-CID показан на рисунке.

        0   1   2   3   4   5   6   7
      +---+---+---+---+---+---+---+---+
      | 1   1   1   0 |      CID      |
      +---+---+---+---+---+---+---+---+

CID

Значения от 0x1 до 0xF указывают CID от 1 до 15.

Отметим, что для CID 0 октет Add-CID совпадает с октетом заполнения (Padding).

5.2.1.3. Общий формат заголовка

Все типы пакетов ROHC используют общий формат заголовка (поле Header), показанный на рисунке.

  0              x-1  x       7
 --- --- --- --- --- --- --- ---
:         октет Add-CID         : если CID 1-15 и малое пространство CID
+--- --- --- --- ---+--- --- ---+
| type indication   |   body    | 1 октет (8-x битов образуют тело)
+--- --- --- --- ---+--- --- ---+
:                               :
/     0, 1, или 2 октета CID    / 1 или 2 октета при 
:                               : большом пространстве CID
+---+---+---+---+---+---+---+---+
/             body              / переменный размер
+---+---+---+---+---+---+---+---+

type indication

Тип пакета ROHC.

body

Интерпретируется в зависимости от типа пакета и данных CID в соответствии с определением профиля.

Заголовок начинается с индикации типа пакета или включает индикации, следующую сразу после октета Add-CID.

Когда канал ROHC настроен на использование малого пространства CID:

• если поле Add-CID непосредственно предшествует индикации типа пакета, пакет имеет значение CID = Add-CID, в противном случае CID = 0;
• CID = 0 из малого пространства представляется без использования каких-либо битов (0), следовательно, для потоков с CID 0 не возникает издержек на передачу CID в сжатом заголовке; в этом случае поле Header начинается с индикации типа пакета;
• CID из малого пространства со значениями от 1 до 15 представляются октетом Add-CID, как описано выше; поле Header начинается с октета Add-CID, за которым следует индикация типа пакета;
• CID из большого пространства не включаются в поле Header.

Если канал ROHC настроен на использование большого пространства CID:

• большое значение CID всегда указывается с использованием схемы кодирования, описанной в параграфе 5.3.2 (не более 2 октетов); в таких случаях поле Header начинается с индикации типа пакета.

5.2.2. Типы пакетов инициализации и обновления (IR)

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

Пакеты IR и IR-DYN всегда обновляют контекст в части содержащихся в заголовке полей обновления. Они никогда не сбрасывают контекст, за исключением случаев инициализации нового контекста (см. параграф 5.1.1) и ситуаций, когда профиль, указанный полем Profile задает иное.

5.2.2.1. Формат заголовка ROHC IR

Заголовок IR связывает CID с профилем и обычно также инициализирует контекст, а также обновляет все или часть контекстов. Для пакетов IR поле Header имеет формат, показанный на рисунке.

  0   1   2   3   4   5   6   7
 --- --- --- --- --- --- --- ---
:         октет Add-CID         : если CID 1-15 и малое пространство CID
+---+---+---+---+---+---+---+---+
| 1   1   1   1   1   1   0 | x | октет типа IR
+---+---+---+---+---+---+---+---+
:                               :
/   0, 1, или 2 октета CID      / 1 или 2 октета при 
:                               : большом пространстве CID
+---+---+---+---+---+---+---+---+
|            Profile            | 1 октет
+---+---+---+---+---+---+---+---+
|              CRC              | 1 октет
+---+---+---+---+---+---+---+---+
|                               |
/ profile-specific information  / переменный размер
|                               |
+---+---+---+---+---+---+---+---+

x

Зависящая от профиля информация, интерпретируемая в соответствии с профилем, указанным в поле Profile заголовка IR.

Profile

Профиль, связанный с CID. В заголовке IR профиль представляется 8 младшими битами идентификатора (см. параграф 5.1.2).

CRC

8-битовое значение контрольной суммы ( см. параграф 5.3.1.1).

Profile-specific information

Содержимое этой части заголовка IR определяется конкретным профилем и интерпретируется в соответствии с профилем, указанным в поле Profile.

5.2.2.2. Формат заголовка ROHC IR-DYN

В отличие от заголовка IR заголовок IR-DYN не может инициализировать неинициализированный контекст. Однако он может переопределить связанный с контекстом профиль, если указанный в заголовке IR-DYN профиль позволяет это. Этот тип пакетов также резервируется на уровне модели. Заголовок IR-DYN обычно также инициализирует или обновляет части контекста. Формат заголовка IR-DYN показан на рисунке.

  0   1   2   3   4   5   6   7
 --- --- --- --- --- --- --- ---
:         октет Add-CID         : если CID 1-15 и малое пространство CID
+---+---+---+---+---+---+---+---+
| 1   1   1   1   1   0   0   0 | октет типа IR-DYN
+---+---+---+---+---+---+---+---+
:                               :
/        0-2 октета CID         / 1 или 2 октета при
:                               : большом пространстве CID
+---+---+---+---+---+---+---+---+
|            Profile            | 1 октет
+---+---+---+---+---+---+---+---+
|              CRC              | 1 октет
+---+---+---+---+---+---+---+---+
|                               |
/ profile-specific information  / переменный размер
|                               |
+---+---+---+---+---+---+---+---+

Profile

Профиль, связанный с CID. Задается так же, как для пакетов IR.

CRC

8-битовое значение контрольной суммы ( см. параграф 5.3.1.1).

Profile-specific information

Содержимое этой части заголовка IR-DYN определяется конкретным профилем и интерпретируется в соответствии с профилем, указанным в поле Profile.

5.2.3. Изначальная обработка в декомпрессоре ROHC

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

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

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

При получении декомпрессором пакета IR-DYN указанный в нем профиль определяет обработку данного пакета.

• Если проверка целостности заголовка с помощью 8-битового поля CRC приводит к отказу, пакет недопустимо декомпрессировать и доставлять на вышележащие уровни. Если в контексте указан профиль, логика этого профиля определяет передачу данных обратной связи, если они имеются. Если профиль в контексте не отмечен, логика передачи данных обратной связи (при их наличии) определяется реализацией. Однако может оказаться разумным отказ от каких-либо дальнейших действий, поскольку причиной отказа может быть любая часть заголовка IR-DYN, покрываемая контрольной суммой.
• Если контекст еще не был инициализирован, пакет недопустимо декомпрессировать и доставлять на вышележащие уровни. При наличии данных обратной связи логику действий для них определяет профиль, указанный в заголовке IR-DYN (при совпадении 8-битовой контрольной суммы CRC).

При возникновении ошибок разбора пакетов любого типа декомпрессор должен отбрасывать такие пакеты без дальнейшей обработки. Например, поле CID присутствует в заголовке пакета при указанном использовании большого пространства CID для канала ROHC и поле представлено с использованием самоописывающего кодирования с переменным размером (см. параграф 5.3.2); если поле начинается с 110 или 111 это будет вызывать ошибку при разборе, поскольку такое поле не может быть представлено с размером, превышающим 2 октета.

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

5.2.4. Обратная связь ROHC

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

Общий формат пакетов ROHC позволяет передавать данные обратной связи с использованием «размывания» (interspersion), «наложения» (piggybacking) (см. [RFC3759]) или их комбинации по любому каналу ROHC. Это обеспечивается за счет перечисленных ниже свойств

Reserved packet type — зарезервированный тип пакетов

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

CID information — информация CID

Данные обратной связи, передаваемые по отдельному каналу, направляются компрессору и интерпретируются им. Для этого в каждом пакете обратной связи содержится информация CID из канала, к которому относится обратная связь. Схема обратной связи в ROHC требует, чтобы канал обратной связи доставлял данные не более, чем одному компрессору. Связь компрессора с обратной связью для конкретного канала выходит за пределы данной спецификации (см. [RFC3759]).

Length information — информация о размере

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

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

5.2.4.1. Формат обратной связи ROHC

ROHC определяет три разных категории сообщений обратной связи — подтверждение (ACK), негативное подтверждение (NACK) и NACK для контекста в целом (STATIC-NACK). Для профилей могут определяться другие типы сообщений.

ACK

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

NACK

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

STATIC-NACK

Показывает, что декомпрессор считает некорректным статический контекст или этот контекст отсутствует.

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

  0   1   2   3   4   5   6   7
+---+---+---+---+---+---+---+---+
| 1   1   1   1   0 |   Code    | тип обратной связи
+---+---+---+---+---+---+---+---+
:             Size              : если Code = 0
+---+---+---+---+---+---+---+---+
:         октет Add-CID         : при малом пространстве CID и (CID != 0)
+---+---+---+---+---+---+---+---+
:                               :
/           large CID           / 1 или 2 октета при
:                               : большом пространстве CID
+---+---+---+---+---+---+---+---+
/         FEEDBACK data         / переменный размер
+---+---+---+---+---+---+---+---+

Code

Значение 0 указыва-ет на присутствие октета Size, 1-7 показывает общий размер полей FEEDBACK data и CID (если оно имеется) в октетах.

Size

Показывает общий размер полей FEEDBACK data и CID (если оно имеется) в октетах.

FEEDBACK data

FEEDBACK-1 или FEEDBACK-2 (см. ниже).

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

Поле большого CID (при его наличии) кодируется, как описано в параграфе 5.3.2 и для его представления недопустимо использовать более 2 октетов.

Поле FEEDBACK может содержать данных в любом из двух показанных ниже форматов.

FEEDBACK-1

        0   1   2   3   4   5   6   7
      +---+---+---+---+---+---+---+---+
      | profile-specific information  |  1 октет
      +---+---+---+---+---+---+---+---+

FEEDBACK-2

        0   1   2   3   4   5   6   7
      +---+---+---+---+---+---+---+---+
      |Acktype|                       |
      +---+---+   profile-specific    /  не менее 2 октетов
      /             information       |
      +---+---+---+---+---+---+---+---+

Acktype: 0 = ACK

1 = NACK

2 = STATIC-NACK

3 резерв (использование недопустимо; приводит к невозможности разбора).

5.2.5. Сегментация ROHC

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

5.2.5.1. Вопросы использования сегментации

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

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

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

5.2.5.2. Протокол сегментации

Сегментация ROHC применяется к комбинации полей Header и Payload пакетов ROHC, как определено в параграфе 5.2.1.

Формат сегмента показан на рисунке.

  0   1   2   3   4   5   6   7
+---+---+---+---+---+---+---+---+
| 1   1   1   1   1   1   1 | F |  тип сегмента
+---+---+---+---+---+---+---+---+
/           Segment             /  переменный размер
+---+---+---+---+---+---+---+---+

F

Финальный бит, указывающий последний сегмент восстанавливаемого блока. Октету типа сегмента могут предшествовать поля Padding и/или Feedback. Для сегментов не указывается CID, но информация CID включается в восстановленный блок. В этот блок недопустимо включать заполнение, сегменты или обратную связь.

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

Восстановленный блок показан на рисунке.

  0   1   2   3   4   5   6   7
+---+---+---+---+---+---+---+---+
/            Header             /
+---+---+---+---+---+---+---+---+
:            Payload            :
+---+---+---+---+---+---+---+---+
/              CRC              /  4 октета
+---+---+---+---+---+---+---+---+

Header

См. параграф 5.2.1

Payload

См. параграф 5.2.1

CRC

32-битовое значение CRC вычисляется с использованием полинома, приведенного в параграфе 5.3.1.4.

Если размер восстановленного блока не превышает 4 октетов, проверка CRC завершается отказом или размер блока превышает значение параметра MRRU (см. параграф 5.1.2) для канала, восстановленный блок должен быть отброшен декомпрессором. При совпадении CRC восстановленный блок может быть подвергнут дальнейшей обработке.

5.3. Общие методы кодирования

5.3.1. Контрольные суммы при компрессии заголовка

В этом разделе описан расчет контрольных сумм CRC, используемых ROHC. Для всех значений CRC используется алгоритм, описанный в [RFC1662] и определенный в Приложении ,A к данному документу, с полиномами, заданными в последующих параграфах.

5.3.1.1. 8-битовая сумма CRC в заголовках IR и IR-DYN

Покрытие 8-битовой контрольной суммы в заголовках IR и IR-DYN зависит от профиля, но должно включать, по крайней мере, начальную часть заголовка, завершающуюся полем Profile и включающую CID или октет Add-CID. Обратная связь и заполнение не относятся к заголовку Header (параграф 5.2.1) и, таким образом, не включаются в расчет CRC. В спецификации профилей следует также включать в покрытие CRC все прочую информацию, используемую для инициализации контекста декомпрессора.

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

Полином CRC для 8-битовой контрольной суммы имеет вид

C(x) = 1 + x + x^2 + x^8

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

5.3.1.2. 3-битовая сумма CRC в сжатых заголовках

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

В качестве начального содержимого регистра CRC устанавливаются все 1.

Для расчета контрольной суммы используется полином

C(x) = 1 + x + x^3

3-битовое значение CRC позволяет декомпрессору проверять результат декомпрессии для небольших сжатых заголовков и обнаруживать повреждения контекста на основе агрегированной вероятности для множества попыток декомпрессии. Однако эти суммы слишком слабы даже для того, чтобы гарантировать отсутствие ошибок в одном заголовке. По этой причине 3-битового значения CRC в сжатом заголовке обычно недостаточно для исправления контекста декомпрессора. Следовательно, профилям рекомендуется воздерживаться от декомпрессии таких заголовков, когда контекст декомпрессора или его часть предполагается некорректным.

5.3.1.3. 7-битовая контрольная сумма в сжатых заголовках

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

В качестве начального содержимого регистра CRC устанавливаются все 1.

Для расчета контрольной суммы используется полином

C(x) = 1 + x + x^2 + x^3 + x^6 + x^7

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

5.3.1.4. 32-битовая контрольная сумма сегментации

32-битовые контрольные суммы используются схемой сегментации для проверки восстановленных блоков и, поэтому, рассчитываются для сегментируемого блока, т. е., включают поля Header и Payload пакетов ROHC.

В качестве начального содержимого регистра CRC устанавливаются все 1.

Для расчета контрольной суммы используется полином

C(x) = x^0 + x^1 + x^2 + x^4 + x^5 + x^7 + x^8 + x^10 + x^11 + x^12 + x^16 + x^22 + x^23 + x^26 + x^32

Назначением 32-битовых контрольных сумм CRC является проверка восстановленных блоков.

5.3.2. Самоописывающиеся значения переменного размера

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

Первый бит равен 0: 1 октет.

7 битов передается

десятичное значение до 127

Шестнадцатеричное представление октетов от 00 до 7F

Первые биты равны 10: 2 октета.

14 битов передается

десятичное значение до 16 383

Шестнадцатеричное представление октетов от 80 00 до BF FF

Первые биты равны 110: 3 октета.

21 бит передается

десятичное значение до 2 097 151

Шестнадцатеричное представление октетов от C0 00 00 до DF FF FF

Первые биты равны 111: 4 октета.

29 битов передается

десятичное значение до 536 870 911

Шестнадцатеричное представление октетов от E0 00 00 00 до FF FF FF FF

5.4. ROHC UNCOMPRESSED — без компрессии (профиль 0x0000)

В этом разделе описан профиль ROHC без компрессии, имеющий идентификатор 0x0000.

Профиль 0x0000 обеспечивает способ передачи пакетов IP без их сжатия. Он может использоваться с любыми пакетами, для которых недоступны профили из набора поддерживаемых для канала ROHC или в тех случаях, когда компрессия нежелательна по тем или иным причинам.

После инициализации единственной издержкой при передаче пакетов с использованием Profile 0x0000 является размер CID. Когда несжимаемые пакеты встречаются часто, Profile 0x0000 следует связывать с CID размером 0 или 1 октет. Profile 0x0000 не следует связывать с несколькими CID.

5.4.1. Пакет IR

Пакет инициализации и обновления (IR) для Profile 0x0000 имеет формат, показанный на рисунке.

  0   1   2   3   4   5   6   7
 --- --- --- --- --- --- --- ---
:         октет Add-CID         : для малых CID при (CID != 0)
+---+---+---+---+---+---+---+---+
| 1   1   1   1   1   1   0 |res|
+---+---+---+---+---+---+---+---+
:                               :
/    0-2 octets of CID info     / 1-2 октета для больших CID
:                               :
+---+---+---+---+---+---+---+---+
|         Profile = 0x00        | 1 октет
+---+---+---+---+---+---+---+---+
|              CRC              | 1 октет
+---+---+---+---+---+---+---+---+

res

это поле должно иметь значение 0; в противном случае декомпрес-сор должен отбрасывать пакет.

Profile

0x00

CRC

8-битовое значение CRC, рассчитанное с использованием полинома из параграфа 5.3.1.1. CRC покрывает первый октет IR Header до октета Profile в IR Header, т. е., не включает самого поля CRC. В контрольной сумме также не учитываются предшествующие поля Padding или Feedback и Payload.

Для пакетов IR поле Payload имеет формат, показанный на рисунке.

 --- --- --- --- --- --- --- ---
:                               : (необязательно)
/           IP packet           / переменный размер
:                               :
 --- --- --- --- --- --- --- ---

IP packet

Несжатый пакет IP может быть включен в пакет IR. Декомпрессор определяет присутствие пакета IP по размеру пакета IR.

5.4.2. Нормальный пакет

Пакет Normal представляет собой обычный пакет IP с дополнительной информацией CID. Для пакетов Normal формат, показанный на рисунке справа, соответствует полям Header и Payload (как определено в параграфе 5.2.1).

  0   1   2   3   4   5   6   7
 --- --- --- --- --- --- --- ---
:         октет Add-CID          : для малых CID при (CID != 0)
+---+---+---+---+---+---+---+---+
|   первый октет пакета IP      |
+---+---+---+---+---+---+---+---+
:                               :
/  0-2 октета информации CID    / 1-2 октета для больших CID
:                               :
+---+---+---+---+---+---+---+---+
|                               |
/       остаток пакета IP       / переменный размер
|                               |
+---+---+---+---+---+---+---+---+

Отметим, что первый октет пакета IP начинается с битовой последовательности 0100 (IPv4) или 0110 (IPv6). Это не вызывает конфликтов с какими-либо из зарезервированных типов пакетов.

При использовании в канале малых значений CID и связывании профиля 0x0000 с CID > 0, пакету IP предшествует октет Add-CID. Если на канале используются большие значения CID, идентификатор CID начинается со второго октета комбинированного формата Header/Payload, описанного выше.

Пакет Normal может содержать поле Padding и/или Feedback, как любые другие пакеты ROHC, перед комбинированным полем Header/Payload.

5.4.3. Инициализация контекста

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

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

5.4.4. Работа декомпрессора

При получении пакета IR декомпрессор сначала проверяет его корректность, используя 8-битовое значение CRC.

• Если проверка завершилась отказом для декомпрессора недопустимо передавать пакет IP вышележащим уровням;
• при совпадении контрольных сумм декомпрессор

1. инициализирует контекст, если у него нет корректного контекста для данного CID, связанного с этим профилем,
2. доставляет пакет IP вышележащим уровням при наличии таковых,
3. может передать подтверждение ACK.

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

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

5.4.5. Обратная связь

Единственным типом обратной связи для 0x0000 является подтверждение ACK с использованием формата FEEDBACK-1 (см. параграф 5.2.4.1) с нулевым значением октета profile-specific в поле FEEDBACK-1. Формат FEEDBACK-2 не определен для Profile 0x0000.

6. Обзор профилей ROHC (информационный раздел)

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

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

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

Форматы пакетов

• Bits-on-the-wire — биты в линии

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

• Field encodings — кодирование полей

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

• Updating properties — свойства обновления

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

• Verification — верификация

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

Управление контекстом

• Robustness logic — логика отказоустойчивости

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

• Repair mechanism — механизм исправления

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

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

Авторы выражают свою признательность всем, кто внес свой вклад в предшествующие работы по ROHC, и особенно авторам документа RFC 3095 [RFC3095], который послужил технической основой для данного документа. Спасибо всем, кто внес свои правки и разъяснения в корректирующий RFC 3095 документ [RFC4815], — их технические предложения (когда они были применимы) включены в этот документ. Спасибо Jani Juvan за обнаружение несоответствия между структурой обратной связи, описанной в [RFC4995], и аналогичной структурой из [RFC3095] — это сделало необходимым обновление [RFC4995].

Назначенными рабочей группой рецензентами документа были Carl Knutsson, Biplab Sarkar и Robert Stangarone — они принимали участие в работе над документом вплоть до ее завершения. Отдельная благодарность Bert Wijnen и Brian Carpenter за их комментарии в процессе IETF Last Call.

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

Реестр IANA «RObust Header Compression (ROHC) Profile Identifiers» [ROHC-ids] был создан RFC 3095 [RFC3095]. Правила распределения, предложенные в RFC 3095, включают нижеперечисленное.

Идентификатор профиля ROHC представляет собой неотрицательное целое число. Во многих протоколах согласования оно представляется 16-битовым значением. В результате сжатия этих идентификаторов в пакетах ROHC младшие 8 битов идентификатора имеют специальное значение — два идентификатора профилей, совпадающие по восьми младшим битам, следует выделять лишь в тех случаях, когда идентификатор с большим значением предназначен для замены идентификатора с меньшим значением. Для того, чтобы не упустить это из виду, идентификаторы следует указывать в шестнадцатеричном формате (например, идентификатор 0x1234 можно выделить взамен 0x0A34).

Приведенные далее правила были включены в [RFC5226]. Политика IANA при выделении новых значений идентификаторов профиля должна соответствовать процедуре Specification Required¹¹ — значения и их трактовки должны быть документированы в RFC или аналогичном документе, доступном по известной и постоянной ссылке, достаточно подробно для обеспечения возможности взаимодействия независимых реализаций. В младших 8 битах идентификатора значения от 0 до 127 резервируются для спецификаций проектов стандартов IETF, диапазон от 128 до 254 доступен для других спецификаций, удовлетворяющих требованиям (таких, как информационные RFC). Значение 255 в младших восьми битах зарезервировано для будущих расширений данной спецификации.

Выделенные идентификаторы профилей перечислены в таблице справа.

Для новых профилей потребуется выделение агентством IANA новых идентификаторов, но этот документ не требует от IANA каких-либо действий.

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

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

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

Атаки на службы (DoS¹²) будут возможны, если атакующий способен ввести в канал обманные пакеты IR, IR-DYN или пакеты обратной связи, снижая тем самым эффективность компрессии. Однако атакующий с возможностью вставки на канальном уровне произвольных пакетов способен нанести более серьезный урон, нежели снижение эффективности компрессии заголовков.

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

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

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

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

[CRTP-eval] Degermark, M., Hannu, H., Jonsson, L., and K. Svanbro, «»Evaluation of CRTP Performance over Cellular Radio Networks», IEEE Personal Communication Magazine, Volume 7, number 4, pp. 20-25, August 2000.», 2000.

[RFC0768] Postel, J., «User Datagram Protocol», STD 6, RFC 768, August 1980.

[RFC0791] Postel, J., «Internet Protocol», STD 5, RFC 791, September 1981.

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

[RFC1144] Jacobson, V., «Compressing TCP/IP headers for low-speed serial links», RFC 1144, February 1990.

[RFC1662] Simpson, W., «PPP in HDLC-like Framing», STD 51, RFC 1662, July 1994.

[RFC2460] Deering, S. and R. Hinden, «Internet Protocol, Version 6 (IPv6) Specification», RFC 2460, December 1998.

[RFC2507] Degermark, M., Nordgren, B., and S. Pink, «IP Header Compression», RFC 2507, February 1999.

[RFC2508] Casner, S. and V. Jacobson, «Compressing IP/UDP/RTP Headers for Low-Speed Serial Links», RFC 2508, February 1999.

[RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T., Yoshimura, T., and H. Zheng, «Robust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed», RFC 3095, July 2001.

[RFC3096] Degermark, M., «Requirements for robust IP/UDP/RTP header compression», RFC 3096, July 2001.

[RFC3241] Bormann, C., «Robust Header Compression (ROHC) over PPP», RFC 3241, April 2002.

[RFC3545] Koren, T., Casner, S., Geevarghese, J., Thompson, B., and P. Ruddy, «Enhanced Compressed RTP (CRTP) for Links with High Delay, Packet Loss and Reordering», RFC 3545, July 2003.

[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, «RTP: A Transport Protocol for Real-Time Applications», STD 64, RFC 3550, July 2003.

[RFC3759] Jonsson, L-E., «RObust Header Compression (ROHC): Terminology and Channel Mapping Examples», RFC 3759, April 2004.

[RFC4224] Pelletier, G., Jonsson, L-E., and K. Sandlund, «Robust Header Compression (ROHC): ROHC over Channels That Can Reorder Packets», RFC 4224, January 2006.

[RFC4815] Jonsson, L-E., Sandlund, K., Pelletier, G., and P. Kremer, «RObust Header Compression (ROHC): Corrections and Clarifications to RFC 3095», RFC 4815, February 2007.

[RFC4995] Jonsson, L-E., Pelletier, G., and K. Sandlund, «The RObust Header Compression (ROHC) Framework», RFC 4995, July 2007.

[RFC4996] Pelletier, G., Sandlund, K., Jonsson, L-E., and M. West, «RObust Header Compression (ROHC): A Profile for TCP/IP (ROHC-TCP)», RFC 4996, July 2007.

[RFC5225] Pelletier, G. and K. Sandlund, «RObust Header Compression Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP and UDP-Lite», RFC 5225, April 2008.

[RFC5226] Narten, T. and H. Alvestrand, «Guidelines for Writing an IANA Considerations Section in RFCs», BCP 26, RFC 5226, May 2008.

[ROHC-ids] IANA, «RObust Header Compression (ROHC) Profile Identifiers», <http://www.iana.org>.

Приложение A. Алгоритм CRC

   #!/usr/bin/perl -w
   use strict;
   #=================================
   #
   # ROHC CRC demo - Carsten Bormann cabo@tzi.org 2001-08-02
   #
   # Эта маленькая программа показывает 4 типа CRC, используемых в 3095
   # для отказоустойчивого сжатия заголовков. Введите данные в 
   # шестнадцатеричном формате и нажмите Control+D.
   #
   #---------------------------------
   #
   # utility
   #
   sub dump_bytes($) {
       my $x = shift;
       my $i;
       for ($i = 0; $i < length($x); ) {
     printf("%02x ", ord(substr($x, $i, 1)));
     printf("n") if (++$i % 16 == 0);
       }
       printf("n") if ($i % 16 != 0);
   }

   #---------------------------------
   #
   # Алгоритм расчета CRC
   #
   sub do_crc($$$) {
       my $nbits = shift;
       my $poly = shift;
       my $string = shift;

       my $crc = ($nbits == 32 ? 0xffffffff : (1 << $nbits) - 1);
       for (my $i = 0; $i < length($string); ++$i) {
         my $byte = ord(substr($string, $i, 1));
         for( my $b = 0; $b < 8; $b++ ) {
           if (($crc & 1) ^ ($byte & 1)) {
             $crc >>= 1;
             $crc ^= $poly;
           } else {
           $crc >>= 1;
           }
           $byte >>= 1;
         }
       }

       printf "%2d bits, ", $nbits;
       printf "CRC: %02xn", $crc;
   }

   #---------------------------------
   #
   # Тестирование
   #
   $/ = undef;
   $_ = <>;         # читать до конца файла
   my $string = ""; # извлечь все шестнадцатеричное
   s/([0-9a-fA-F][0-9a-fA-F])/$string .= chr(hex($1)), ""/eg;
   dump_bytes($string);

   #---------------------------------
   #
   # 32-битовое значение CRC для сегментации
   # Отметим, что в тексте предполагается дополнение, как в PPP
   # (это отличается от 8, 7 и 3-битовых CRC)
   #
   #      C(x) = x^0 + x^1 + x^2 + x^4 + x^5 + x^7 + x^8 + x^10 +
   #             x^11 + x^12 + x^16 + x^22 + x^23 + x^26 + x^32
   #
   do_crc(32, 0xedb88320, $string);

   #---------------------------------
   #
   # 8-битовая сумма для IR/IR-DYN
   #
   #      C(x) = x^0 + x^1 + x^2 + x^8
   #
   do_crc(8, 0xe0, $string);

   #---------------------------------
   #
   # 7-битовая сумма для FO/SO
   #
   #      C(x) = x^0 + x^1 + x^2 + x^3 + x^6 + x^7
   #
   do_crc(7, 0x79, $string);

   #---------------------------------
   #
   # 3-битовая сумма FO/SO
   #
   #      C(x) = x^0 + x^1 + x^3
   #
   do_crc(3, 0x6, $string);

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

Kristofer Sandlund

Ericsson

Box 920

Lulea SE-971 28

Sweden

Phone: +46 (0) 8 404 41 58

EMail: kristofer.sandlund@ericsson.com

Ghyslain Pelletier

Ericsson

Box 920

Lulea SE-971 28

Sweden

Phone: +46 (0) 8 404 29 43

EMail: ghyslain.pelletier@ericsson.com

Lars-Erik Jonsson

Optand 737

Ostersund SE-831 92

Sweden

Phone: +46 76 830 03 12

EMail: lars-erik@lejonsson.com

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