Internet Engineering Task Force (IETF) Y. Jiang, Ed.
Request for Comments: 8575 Huawei
Category: Standards Track X. Liu
ISSN: 2070-1721 Independent
J. Xu
Huawei
R. Cummings, Ed.
National Instruments
May 2019
YANG Data Model for the Precision Time Protocol (PTP)
Модель данных YANG для протокола точного времени (PTP)
Аннотация
Этот документ задаёт модель данных YANG для настройки устройств и часов с использованием протокола точного времени (Precision Time Protocol или PTP), заданного стандартом IEEE Std 1588-2008. Документ также определяет извлечение конфигурационных сведений, наборов данных и рабочих состояний часов PTP. Модуль YANG соответствует архитектуре хранилищ данных управления сетью (Network Management Datastore Architecture – NMDA).
Статус документа
Документ относится к категории Internet Standards Track.
Документ является результатом работы IETF1 и представляет согласованный взгляд сообщества IETF. Документ прошёл открытое обсуждение и был одобрен для публикации IESG2. Дополнительную информацию о стандартах Internet можно найти в разделе 2 в RFC 7841.
Информация о текущем статусе документа, найденных ошибках и способах обратной связи доступна по ссылке https://www.rfc-editor.org/info/rfc8575.
Авторские права
Copyright (c) 2019. Авторские права принадлежат IETF Trust и лицам, указанным в качестве авторов документа. Все права защищены.
К документу применимы права и ограничения, указанные в BCP 78 и IETF Trust Legal Provisions и относящиеся к документам IETF (http://trustee.ietf.org/license-info), на момент публикации данного документа. Прочтите упомянутые документы внимательно. Фрагменты программного кода, включённые в этот документ, распространяются в соответствии с упрощённой лицензией BSD, как указано в параграфе 4.e документа IETF Trust Legal Provisions, без каких-либо гарантий (как указано в Simplified BSD License).
1. Введение
Как протокол синхронизации, IEEE Std 1588-2008 [IEEE1588] широко поддерживается в сетях операторов, промышленных и автомобильных сетях, а также во многих других приложениях. Протокол может обеспечить синхронизацию часов с наносекундной точностью. Протокол зависит от машины PTP для автоматического определения состояния и транспортного уровня PTP для передачи сигналов синхронизации и сообщений о качестве. Наборы данных конфигурации и рабочего состояния IEEE Std 1588-2008 весьма широки.
В соответствии с концепциями, описанными в [RFC3444], IEEE Std 1588-2008 сам по себе обеспечивает информационную модель в нормативной спецификации наборов данных (IEEE Std 1588-2008 clause 8). Некоторые органы стандартизации, включая IETF, имеют свои модели данных в базах управляющей информации (MIB или Management Information Base) для наборов данных IEEE Std 1588-2008 (например, [RFC8173] и [IEEE8021AS]). Эти MIB обычно сосредоточены на извлечении данных состояния с применением простого протокола управления сетью (Simple Network Management Protocol или SNMP), а настройка наборов данных PTP даже не рассматривается в [RFC8173].
Некоторым поставщикам услуг и приложениям нужно, чтобы упреаление сетью синхронизации IEEE Std 1588-2008 было гибким и в большей степени основанным на Internet (накладывалось на транспортные сети). Программно-определяемые сети (Software-Defined Networking или SDN) являются ещё одним фактором, требующим улучшения возможностей настройки сетей синхронизации.
Язык моделирования данных YANG [RFC7950] служит для моделирования данных конфигурации и состояния, управляемых по протоколам сетевого управления, таким как протокол настройки сетей (Network Configuration Protocol или NETCONF) [RFC6241]. Небольшой набор встроенных типов данных определён в [RFC7950], а коллекция базовых типов – в [RFC6991]. Преимущества YANG включают основанные на Internet возможности настройки, проверки и отката конфигурации и т. д. Эти характеристики деляют YANG привлекательным в качестве ещё одного кандидата в языки моделирования для IEEE Std 1588-2008.
Этот документ определяет модель данных YANG для настройки устройств и часов IEEE Std 1588-2008, а также извлечения данных состояния часов IEEE Std 1588-2008. Модель данных основана на наборах данных PTP, заданных в [IEEE1588]. Связанные с конкретными технологиями сведения PTP (например, реализованные в профилях для мостов, маршрутизаторов или операторов) выходят за рамки этого документа.
Представленный здесь модуль YANG соответствует архитектуре хранилищ данных управления сетью (NMDA) [RFC8342].
При практическом использовании сетевой продукция для поддержки синхронизации обычно соответствует одному или нескольким профилям IEEE Std 1588-2008. Каждый профиль задаёт применение IEEE Std 1588-2008 в данной отрасли (например, в телекоммуникациях или автомобилестроении) и приложении. Профиль может требовать свойств, которые не обязательны в IEEE Std 1588-2008, а также задавать новые свойства, основанные на IEEE Std 1588-2008.
Предполагается знакомство читателя с IEEE Std 1588-2008. Ниже указаны некоторые аспекты применения модуля.
-
Модуль YANG IEEE Std 1588-2008 может использоваться для продукции, соответствующей одному или нескольким профилям, заданным в IEEE Std 1588-2008.
-
При пересмотре стандарта IEEE Std 1588 (например, это происходило во время создания данного документа) в наборы данных могут добавляться новые необязательные свойства (функции). Представленный здесь модуль YANG может пересматриваться для поддержки таких новых функций. Оператор YANG revision должен использоваться для указания изменений в модуле YANG в таких обстоятельствах.
-
Стандарт профиля на основе IEEE Std 1588-2008 может приводить к созданию отдельного модуля YANG для этого профиля. Модулям YANG с профилями следует использовать оператор YANG import для импорта модуля YANG IEEE Std 1588-2008 в качестве своей основы. Для добавления связанных с профилем возможностей в модуле YANG следует использовать оператор YANG augment.
-
Для продукции, соответствующей стандартному профилю, могут создаваться свои модули YANG, в которых следует использовать оператор import, а также augment при добавлении связанных с продукцией возможностей.
1.1. Используемые соглашения
Ключевые слова должно (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не следует (SHALL NOT), следует (SHOULD), не нужно (SHOULD NOT), рекомендуется (RECOMMENDED), не рекомендуется (NOT RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе интерпретируются в соответствии с BCP 14 [RFC2119] [RFC8174] тогда и только тогда, когда они выделены шрифтом, как показано здесь.
1.2. Термины
Большая часть используемых в документе терминов заимствована из [IEEE1588].
BC Boundary Clock
Пограничные часы, см. параграф 3.1.3 в [IEEE1588].DS Data Set
Набор данных, см. параграф 8.1.1 в [IEEE1588]E2E End-to-End
Сквозной, см. параграф 3.2 в [IEEE1588]IANA Internet Assigned Numbers Authority
Агентство по выделению значений для Internet.OC Ordinary Clock
Обычные часы, см. параграф 3.1.22 в [IEEE1588]P2P Peer-to-Peer
Одноранговый, см. параграф 3.2 в [IEEE1588]PTP Precision Time Protocol
Протокол точного времен, см. параграф 3.1.28 в [IEEE1588]TAI International Atomic Time
Международные атомные часы, см. параграф 3.2 в [IEEE1588]TC Transparent Clock
«Прозрачные» часы, см. параграф 3.1.46 в [IEEE1588]UTC Coordinated Universal Time
Универсальное координатное время, см. параграф 3.2 в [IEEE1588]PTP data set
Набор данных PTP – структурированные атрибуты часов (в OC, BC, TC), используемые для решений PTP и предоставления значений в полях сообщений PTP, см. раздел 8 в [IEEE1588].PTP instance
Экземпляр PTP – реализация протокола в устройстве (т. е. OC или BC), представленная конкретным набором данных PTP.2. Иерархия модели данных YANG IEEE Std 1588-2008
В этом разделе показана иерархия модуля YANG для IEEE Std 1588-2008, в частности, запросы и конфигурация сведений для устройства в целом или порта, а также наборы данных в часах.
Запросы и конфигурация сведений о часах включают3:
-
атрибуты набора данных в узле часов включают current-ds, parent-ds, default-ds, time-properties-ds, transparent-clock-default-ds.
-
Атрибуты набора данных для порта включают port-ds и transparent-clock-port-ds.
Поскольку все термины и атрибуты наборов данных PTP подробно описаны в IEEE Std 1588-2008, в этом документе они представлены лишь в общих чертах в модуле YANG.
Для модулей YANG обычно применяется упрощённое представление модели данных в виде дерева [RFC8340]. Здесь используется синтаксис представления дерева, заданный в [RFC8340].
module: ietf-ptp
+--rw ptp
+--rw instance-list* [instance-number]
| +--rw instance-number uint32
| +--rw default-ds
| | +--rw two-step-flag? boolean
| | +--ro clock-identity? clock-identity-type
| | +--rw number-ports? uint16
| | +--rw clock-quality
| | | +--rw clock-class? uint8
| | | +--rw clock-accuracy? uint8
| | | +--rw offset-scaled-log-variance? uint16
| | +--rw priority1? uint8
| | +--rw priority2? uint8
| | +--rw domain-number? uint8
| | +--rw slave-only? boolean
| +--rw current-ds
| | +--rw steps-removed? uint16
| | +--rw offset-from-master? time-interval-type
| | +--rw mean-path-delay? time-interval-type
| +--rw parent-ds
| | +--rw parent-port-identity
| | | +--rw clock-identity? clock-identity-type
| | | +--rw port-number? uint16
| | +--rw parent-stats? boolean
| | +--rw observed-parent-offset-scaled-log-variance? uint16
| | +--rw observed-parent-clock-phase-change-rate? int32
| | +--rw grandmaster-identity? clock-identity-type
| | +--rw grandmaster-clock-quality
| | | +--rw clock-class? uint8
| | | +--rw clock-accuracy? uint8
| | | +--rw offset-scaled-log-variance? uint16
| | +--rw grandmaster-priority1? uint8
| | +--rw grandmaster-priority2? uint8
| +--rw time-properties-ds
| | +--rw current-utc-offset-valid? boolean
| | +--rw current-utc-offset? int16
| | +--rw leap59? boolean
| | +--rw leap61? boolean
| | +--rw time-traceable? boolean
| | +--rw frequency-traceable? boolean
| | +--rw ptp-timescale? boolean
| | +--rw time-source? uint8
| +--rw port-ds-list* [port-number]
| +--rw port-number uint16
| +--rw port-state? port-state-enumeration
| +--rw underlying-interface? if:interface-ref
| +--rw log-min-delay-req-interval? int8
| +--rw peer-mean-path-delay? time-interval-type
| +--rw log-announce-interval? int8
| +--rw announce-receipt-timeout? uint8
| +--rw log-sync-interval? int8
| +--rw delay-mechanism? delay-mechanism-enumeration
| +--rw log-min-pdelay-req-interval? int8
| +--rw version-number? uint8
+--rw transparent-clock-default-ds
| +--ro clock-identity? clock-identity-type
| +--rw number-ports? uint16
| +--rw delay-mechanism? delay-mechanism-enumeration
| +--rw primary-domain? uint8
+--rw transparent-clock-port-ds-list* [port-number]
+--rw port-number uint16
+--rw log-min-pdelay-req-interval? int8
+--rw faulty-flag? boolean
+--rw peer-mean-path-delay? time-interval-type
2.1. Интерпретации от рабочей группы IEEE 1588
Предшествующая модель и связанный с ней модуль YANG имеют незначительные отличия от спецификаций наборов данных в IEEE Std 1588-2008, основанные на интерпретации рабочей группы IEEE 1588 и предназначенные для обеспечения совместимости с будущими версиями IEEE Std 1588.
В IEEE Std 1588-2008 физическая продукция может реализовать несколько часов PTP (например, обычные, граничные и прозрачные часы). Как указано в параграфе 7.1 IEEE Std 1588-2008, каждые из таких часов работают в независимом домене. Однако организация нескольких доменов PTP не ясна в наборах данных IEEE Std 1588-2008. Этот документ вводит понятие экземпляра PTP, который является реализацией PTP в устройстве (т. е. OC или BC), представленной конкретным набором данных PTP. Каждый экземпляр работает в единственном домене. Понятие экземпляра применяется лишь для поддержки нескольких доменов. Номер экземпляра не применяется в сообщениях PTP.
На основе утверждений в параграфах 8.3.1 и 10.1 IEEE Std 1588-2008, большинство устройств с прозрачными часами интерпретируют наборы данных прозрачных часов как одиночный элемент (singleton) на корневом уровне управляемого объекта и модель данных YANG отражает эту позицию.
2.2. Конфигурация и состояние
Информационная модель IEEE Std 1588-2008 разделяет наборы данных PTP на 3 указанных ниже класса.
Configurable – настраиваемые
Доступные для записи из системы управленияDynamic – динамические
Доступные лишь для чтения из системы управления и изменяемые протокольными операциями PTP.Static – статические
Доступные лишь для чтения из системы управления и обычно неизменяемые.Подробности классификации каждого элемента наборов данных PTP приведены в спецификации IEEE Std 1588-2008.
При некоторых обстоятельствах классификация элементов наборов данных IEEE Std 1588 может изменяться для реализации YANG, например, настраиваемый элемент нужно сделать доступным лишь для записи. В таких случаях реализации следует возвращать предупреждение при попытке записи в доступный лишь для чтения объект или использовать механизм отклонений для создания новой модели, как указано в параграфе 7.20.3 [RFC7950].
3. Модуль YANG IEEE Std 1588-2008
Этот модуль импортирует определение типа interface-ref из [RFC8343]. Большинство атрибутов основано на модели информации из [IEEE1588], но их имена приведены в соответствие со стилем именования в YANG.
<CODE BEGINS> file "ietf-ptp@2019-05-07.yang"
module ietf-ptp {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-ptp";
prefix ptp;
import ietf-interfaces {
prefix if;
reference
"RFC 8343: A YANG Data Model for Interface Management";
}
organization
"IETF TICTOC Working Group";
contact
"WG Web: https://datatracker.ietf.org/wg/tictoc/
WG List: <mailto:tictoc@ietf.org>
Editor: Yuanlong Jiang
<mailto:jiangyuanlong@huawei.com>
Editor: Rodney Cummings
<mailto:rodney.cummings@ni.com>";
description
"Этот модуль YANG задаёт модель данных для настройки часов
IEEE Std 1588-2008, а также извлечения из них данных состояния.";
revision 2019-05-07 {
description
"Исходный выпуск";
reference
"RFC 8575: YANG Data Model for the Precision Time Protocol";
}
typedef delay-mechanism-enumeration {
type enumeration {
enum e2e {
value 1;
description
"Порт использует механизм задержки запросов-откликов.";
}
enum p2p {
value 2;
description
"Порт использует механизм задержки у партнера.";
}
enum disabled {
value 254;
description
"Порт не реализует механизмов задержки.";
}
}
description
"Порт использует опцию измерения задержки при распространении.
Значения этого перечисляемого типа полностью заданы стандартом
IEEE Std 1588.";
reference
"IEEE Std 1588-2008: 8.2.5.4.4";
}
typedef port-state-enumeration {
type enumeration {
enum initializing {
value 1;
description
"Порт инициализирует свои наборы данных, аппаратные и
коммуникационные средства.";
}
enum faulty {
value 2;
description
"Порт находится в состоянии отказа.";
}
enum disabled {
value 3;
description
"Порт отключён и не участвует в обмене сообщениями PTP
(кроме возможных управляющих сообщений PTP).";
}
enum listening {
value 4;
description
"Порт прослушивает сообщения Announce.";
}
enum pre-master {
value 5;
description
"Порт находится в состоянии pre-master.";
}
enum master {
value 6;
description
"Порт ведёт себя как первичный (master).";
}
enum passive {
value 7;
description
"Порт находится в пассивном состоянии.";
}
enum uncalibrated {
value 8;
description
"Ведущий порт выбран, но порт остаётся некалиброванным.";
}
enum slave {
value 9;
description
"Порт синхронизируется с выбранным ведущим портом.";
}
}
description
"Текущее состояние машины протокола, связанной с портом.
Перечисляемые значения полностью заданы IEEE Std 1588.";
reference
"IEEE Std 1588-2008: 8.2.5.3.1, 9.2.5";
}
typedef time-interval-type {
type int64;
description
"Производный тип данных для интервала времени, представляемый
в наносекундах с умножением на 2^16.";
reference
"IEEE Std 1588-2008: 5.3.2";
}
typedef clock-identity-type {
type binary {
length "8";
}
description
"Производный тип данных для идентификации часов.";
reference
"IEEE Std 1588-2008: 5.3.4";
}
grouping clock-quality-grouping {
description
"Производный тип данных для качества часов, содержащий
clockClass, clockAccuracy, offsetScaledLogVariance.";
reference
"IEEE Std 1588-2008: 5.3.7";
leaf clock-class {
type uint8;
default "248";
description
"clockClass обозначает прослеживаемость времени или
частоты, распространяемых часами.";
}
leaf clock-accuracy {
type uint8;
description
"clockAccuracy указывает ожидаемую точность часов.";
}
leaf offset-scaled-log-variance {
type uint16;
description
"offsetScaledLogVariance предоставляет оценку отклонений
часов от линейного хода при отсутствии синхронизации
с другими часами по протоколу.";
}
}
container ptp {
description
"Структура PTP, содержащая все атрибуты набора данных PTP,
в которую могут добавляться необязательные атрибуты PTP.";
list instance-list {
key "instance-number";
description
"Список наборов данных PTP в устройстве(см. параграф 6.3 в
IEEE Std 1588-2008). Каждый набор данных PTP представляет
экземпляр реализации PTP в устройстве (т. е., OC или BC).";
leaf instance-number {
type uint32;
description
"Номер текущего экземпляра PTP, используемый для управления.
Этот номер не представляет номер домена PTP и не
применяется в сообщениях PTP.";
}
container default-ds {
description
"Принятый по умолчанию набор данных часов (см. параграф
8.2.1 в IEEE Std 1588-2008). Этот набор представляет
конфигурацию и состояние, требуемые для работы конечных
автоматов протокола точного времени (PTP).";
reference
"IEEE Std 1588-2008: 8.2.1";
leaf two-step-flag {
type boolean;
description
"Значение true указывает двухшаговые (two-step) часы,
иначе часы являются одношаговыми (one-step).";
}
leaf clock-identity {
type clock-identity-type;
config false;
description
"Значение clockIdentity для локальных часов.";
}
leaf number-ports {
type uint16;
description
"Число портов PTP в экземпляре.";
}
container clock-quality {
description
"Значение clockQuality для локальных часов.";
uses clock-quality-grouping;
}
leaf priority1 {
type uint8;
description
"Атрибут priority1 для локальных часов.";
}
leaf priority2 {
type uint8;
description
"Атрибут priority2 для локальных часов.";
}
leaf domain-number {
type uint8;
description
"Номер текущего домена синхронизации.";
}
leaf slave-only {
type boolean;
description
"Значение true указывает вторичные (slave-only) часы.";
}
}
container current-ds {
description
"Текущий набор данных часов (см. параграф 8.2.2 в IEEE Std
1588-2008). Этот набор данных представляет локальные
состояния полученные из обмена сообщениями PTP.";
reference
"IEEE Std 1588-2008: 8.2.2";
leaf steps-removed {
type uint16;
default "0";
description
"Число коммуникационных путей, пройденных между локальными
и эталонными (grandmaster) часами.";
}
leaf offset-from-master {
type time-interval-type;
description
"текущая разница времени между ведущими и ведомыми часами,
рассчитанная ведомыми (slave).";
}
leaf mean-path-delay {
type time-interval-type;
description
"Текущее среднее время распространения между ведущими и
ведомыми часами, рассчитанное ведомыми.";
}
}
container parent-ds {
description
"Родительский набор данных для часов (см. параграф 8.2.3 в
IEEE Std 1588-2008).";
reference
"IEEE Std 1588-2008: 8.2.3";
container parent-port-identity {
description
"Значение portIdentity порта на ведущем устройстве,
содержащее clockIdentity и portNumber.";
reference
"IEEE Std 1588-2008: 5.3.5";
leaf clock-identity {
type clock-identity-type;
description
"Идентификатор часов.";
}
leaf port-number {
type uint16;
description
"Номер порта.";
}
}
leaf parent-stats {
type boolean;
default "false";
description
"Значение true указывает, что
observedParentOffsetScaledLogVariance и
observedParentClockPhaseChangeRate у parentDS
измерены и действительны.";
}
leaf observed-parent-offset-scaled-log-variance {
type uint16;
default "65535";
description
"Оценка вариаций PTP родительских часов, наблюдаемых
ведомыми часами.";
}
leaf observed-parent-clock-phase-change-rate {
type int32;
description
"Оценка скорости изменения фазы родительской часов,
наблюдаемой ведомыми часами.";
}
leaf grandmaster-identity {
type clock-identity-type;
description
"Атрибут clockIdentity эталонных (grandmaster) часов.";
}
container grandmaster-clock-quality {
description
"Значение clockQuality эталонных (grandmaster) часов.";
uses clock-quality-grouping;
}
leaf grandmaster-priority1 {
type uint8;
description
"Атрибут priority1 эталонных (grandmaster) часов.";
}
leaf grandmaster-priority2 {
type uint8;
description
"Атрибут priority2 эталонных (grandmaster) часов.";
}
}
container time-properties-ds {
description
"Набор данных timeProperties в часах (см. параграф 8.2.4 в
IEEE Std 1588-2008).";
reference
"IEEE Std 1588-2008: 8.2.4";
leaf current-utc-offset-valid {
type boolean;
description
"Значение true указывает действительное смещение UTC.";
}
leaf current-utc-offset {
when "../current-utc-offset-valid='true'";
type int16;
description
"Смещение (в секундах) между TAI и UTC когда эпохой
системы PTP является эпоха PTP, т. е. ptp-timescale
имеет значение TRUE. В ином случае не имеет смысла.";
}
leaf leap59 {
type boolean;
description
"Значение true указывает, что последняя минута текущих
суток UTC содержит 59 секунд.";
}
leaf leap61 {
type boolean;
description
"Значение true указывает, что последняя минута текущих
суток UTC содержит 61 секунду.";
}
leaf time-traceable {
type boolean;
description
"Значение true говорит, что шкала времени и
currentUtcOffset отслеживаются до первичного источника.";
}
leaf frequency-traceable {
type boolean;
description
"Значение true говорит, что частота, задающая шкалу
времени, отслеживается до первичного источника.";
}
leaf ptp-timescale {
type boolean;
description
"Значение true говорит, что шкала времени эталонных часов
является PTP, иначе она произвольна (ARB).";
}
leaf time-source {
type uint8;
description
"Источник времени эталонных часов (grandmaster).";
}
}
list port-ds-list {
key "port-number";
description
"Список наборов данных порта часов (см. параграф 8.2.5 в
IEEE Std 1588-2008).";
reference
"IEEE Std 1588-2008: 8.2.5";
leaf port-number {
type uint16;
description
"Номер порта. Наборы данных (т. е. модель информации)
IEEE Std 1588-2008 задают значения portDS.portIdentity,
используемые типизованной структурой с элементами
clockIdentity и portNumber.
В этой модели YANG параметр portIdentity не моделируется
в port-ds-list. Однако его элементы представлены:
portIdentity.portNumber обеспечивается этим листом
port-number в port-ds-list, а portIdentity.clockIdentity -
листом clock-identity в default-ds экземпляра
(т. е., ../../default-ds/clock-identity).";
}
leaf port-state {
type port-state-enumeration;
default "initializing";
description
"Текущее состояние, связанное с портом.";
}
leaf underlying-interface {
type if:interface-ref;
description
"Ссылка на настроенный базовый интерфейс, используемый
этим портом PTP (см. RFC 8343).";
reference
"RFC 8343: A YANG Data Model for Interface Management";
}
leaf log-min-delay-req-interval {
type int8;
description
"Двоичный логарифм minDelayReqInterval (минимально
разрешённый средний интервал между сообщениями
Delay_Req).";
}
leaf peer-mean-path-delay {
type time-interval-type;
default "0";
description
"Оценка текущей задержки распространения в одном
направлении, когда delayMechanism — это P2P, в ином
случае это 0.";
}
leaf log-announce-interval {
type int8;
description
"Двоичный логарифм среднего значения announceInterval
(средний интервал между последовательными Announce).";
}
leaf announce-receipt-timeout {
type uint8;
description
"Число announceIntervals без получения сообщений
Announce message перед возникновением события
ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES.";
}
leaf log-sync-interval {
type int8;
description
"Двоичный логарифм среднего значения SyncInterval для
групповых сообщений. Скорость индивидуальных передач
согласуется отдельно на уровне портов и не ограничивается
этим атрибутом.";
}
leaf delay-mechanism {
type delay-mechanism-enumeration;
description
"Вариант измерения задержки распространения, используемого
портом при расчёте meanPathDelay.";
}
leaf log-min-pdelay-req-interval {
type int8;
description
"Двоичный логарифм среднего значения minPdelayReqInterval
(минимально разрешённый средний интервал между
сообщениями Pdelay_Req).";
}
leaf version-number {
type uint8;
description
"Используемая портом версия PTP.";
}
}
}
container transparent-clock-default-ds {
description
"Элементы набора данных transparentClockDefault
(см. параграф 8.3.2 в IEEE Std 1588-2008).";
reference
"IEEE Std 1588-2008: 8.3.2";
leaf clock-identity {
type clock-identity-type;
config false;
description
"Значение clockIdentity для прозрачных часов.";
}
leaf number-ports {
type uint16;
description
"Число портов PTP в прозрачных часах.";
}
leaf delay-mechanism {
type delay-mechanism-enumeration;
description
"Вариант измерения задержки распространения,
применяемый прозрачными часами.";
}
leaf primary-domain {
type uint8;
default "0";
description
"Значение domainNumber основного домена синхронизации
(см. параграф 10.1 в IEEE Std 1588-2008).";
reference
"IEEE Std 1588-2008: 10.1";
}
}
list transparent-clock-port-ds-list {
key "port-number";
description
"Список наборов данных transparentClockPort прозрачных часов
(см. параграф 8.3.3 в IEEE Std 1588-2008).";
reference
"IEEE Std 1588-2008: 8.3.3";
leaf port-number {
type uint16;
description
"Номер порта. Наборы данных (т. е. модель информации)
IEEE Std 1588-2008 задают значения
transparentClockPortDS.portIdentity, используемые
типизованной структурой с элементами clockIdentity
и portNumber.
В этой модели YANG параметр portIdentity не моделируется в
transparent-clock-port-ds-list. Однако его элементы
представлены: portIdentity.portNumber обеспечивается этим
листом в transparent-clock-port-ds-list, а
portIdentity.clockIdentity - листом clock-identity в
transparent-clock-default-ds (т. е.,
../../transparent-clock-default-ds/clock-identity).";
}
leaf log-min-pdelay-req-interval {
type int8;
description
"Двоичный логарифм minPdelayReqInterval (минимально
разрешённый средний интервал между сообщениями
Pdelay_Req).";
}
leaf faulty-flag {
type boolean;
default "false";
description
"Значение true указывает отказ порта.";
}
leaf peer-mean-path-delay {
type time-interval-type;
default "0";
description
"Оценка текущей односторонней задержки распространения
на канале, когда delayMechanism — это P2P, в ином
случае 0.";
}
}
}
}
<CODE ENDS>
4. Вопросы безопасности
Заданные этим документом модули YANG определяют схему для данных, предназначенную для доступа через сеть с использованием протоколов управления, таких как NETCONF [RFC6241] или RESTCONF [RFC8040]. Нижним уровнем NETCONF служит защищённый транспорт с обязательной поддержкой SSH (Secure Shell) [RFC6242]. Нижним уровнем RESTCONF служит протокол HTTPS с обязательной поддержкой защиты на транспортном уровне (TLS) [RFC8446].
Модель доступа к конфигурации сети (NACM – Network Configuration Access Control Model) [RFC8341] обеспечивает возможность разрешить доступ лишь определённых пользователей NETCONF или RESTCONF к заранее заданному подмножеству операций NETCONF или RESTCONF и содержимого.
В модулях данных YANG определено множество узлов данных, которые разрешают запись. Ниже перечислены ветви и узлы, которые могут быть конфиденциальны или уязвимы.
/ptp/instance-list задаёт экземпляры (т. е. наборы данных PTP) для OC или BC.
/ptp/transparent-clock-default-ds задаёт принятый по умолчанию набор данных для TC.
/ptp/transparent-clock-port-ds-list задаёт список наборов данных портов для TC.
Запись в такие узлы (например, edit-config) без должной защиты может негативно влиять на работу сети. В частности, неподходящая настройка может отрицательно сказаться на работе сети синхронизации PTP. Например, это может быть потеря синхронизации часов, снижение точности набора часов и даже выход из строя всей сети синхронизации.
5. Взаимодействие с IANA
Этот документ регистрирует URI в реестре IETF XML Registry [RFC3688]
URI: urn:ietf:params:xml:ns:yang:ietf-ptp Registrant Contact: The IESG XML: N/A; запрошенный URI является пространством имён XML
Документ регистрирует модуль YANG в реестре YANG Module Names [RFC6020]
Name: ietf-ptp Namespace: urn:ietf:params:xml:ns:yang:ietf-ptp Prefix: ptp Reference: RFC 8575
6. Литература
6.1. Нормативные документы
[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC3688] Mealling, M., “The IETF XML Registry”, BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, <https://www.rfc-editor.org/info/rfc3688>.
[RFC6020] Bjorklund, M., Ed., “YANG – A Data Modeling Language for the Network Configuration Protocol (NETCONF)”, RFC 6020, DOI 10.17487/RFC6020, October 2010, <https://www.rfc-editor.org/info/rfc6020>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., “Network Configuration Protocol (NETCONF)”, RFC 6241, DOI 10.17487/RFC6241, June 2011, <https://www.rfc-editor.org/info/rfc6241>.
[RFC6242] Wasserman, M., “Using the NETCONF Protocol over Secure Shell (SSH)”, RFC 6242, DOI 10.17487/RFC6242, June 2011, <https://www.rfc-editor.org/info/rfc6242>.
[RFC6991] Schoenwaelder, J., Ed., “Common YANG Data Types”, RFC 6991, DOI 10.17487/RFC6991, July 2013, <https://www.rfc-editor.org/info/rfc6991>.
[RFC7950] Bjorklund, M., Ed., “The YANG 1.1 Data Modeling Language”, RFC 7950, DOI 10.17487/RFC7950, August 2016, <https://www.rfc-editor.org/info/rfc7950>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, “RESTCONF Protocol”, RFC 8040, DOI 10.17487/RFC8040, January 2017, <https://www.rfc-editor.org/info/rfc8040>.
[RFC8174] Leiba, B., “Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words”, BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8341] Bierman, A. and M. Bjorklund, “Network Configuration Access Control Model”, STD 91, RFC 8341, DOI 10.17487/RFC8341, March 2018, <https://www.rfc-editor.org/info/rfc8341>.
[RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., and R. Wilton, “Network Management Datastore Architecture (NMDA)”, RFC 8342, DOI 10.17487/RFC8342, March 2018, <https://www.rfc-editor.org/info/rfc8342>.
[RFC8343] Bjorklund, M., “A YANG Data Model for Interface Management”, RFC 8343, DOI 10.17487/RFC8343, March 2018, <https://www.rfc-editor.org/info/rfc8343>.
[RFC8446] Rescorla, E., “The Transport Layer Security (TLS) Protocol Version 1.3”, RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/info/rfc8446>.
[IEEE1588] IEEE, “IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems”, IEEE Std 1588-2008, DOI 10.1109/IEEESTD.2008.4579760, July 2008.
6.2. Дополнительная литература
[IEEE8021AS] IEEE, “IEEE Standard for Local and Metropolitan Area Networks – Timing and Synchronizations for Time-Sensitive Applications in Bridged Local Area Networks”, IEEE 802.1AS-2001.
[RFC3444] Pras, A. and J. Schoenwaelder, “On the Difference between Information Models and Data Models”, RFC 3444, DOI 10.17487/RFC3444, January 2003, <https://www.rfc-editor.org/info/rfc3444>.
[RFC4663] Harrington, D., “Transferring MIB Work from IETF Bridge MIB WG to IEEE 802.1 WG”, RFC 4663, DOI 10.17487/RFC4663, September 2006, <https://www.rfc-editor.org/info/rfc4663>.
[RFC7384] Mizrahi, T., “Security Requirements of Time Protocols in Packet Switched Networks”, RFC 7384, DOI 10.17487/RFC7384, October 2014, <https://www.rfc-editor.org/info/rfc7384>.
[RFC8340] Bjorklund, M. and L. Berger, Ed., “YANG Tree Diagrams”, BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, <https://www.rfc-editor.org/info/rfc8340>.
[RFC8173] Shankarkumar, V., Montini, L., Frost, T., and G. Dowd, “Precision Time Protocol Version 2 (PTPv2) Management Information Base”, RFC 8173, DOI 10.17487/RFC8173, June 2017, <https://www.rfc-editor.org/info/rfc8173>.
Приложение A. Перенос работы YANG в IEEE 1588 WG
Это приложение является информационным и описывает будущий план передачи ответственности за модули YANG IEEE Std 1588 от рабочей группы (Working Group или WG) IETF TICTOC в IEEE 1588 WG, разрабатывающей технологию синхронизации времени, для управления которой создаются модули YANG. Приложение ориентировано на будущие планы стандартизации IETF и IEEE. Поскольку такие планы невозможно предсказать достоверно, приложение носит информационный характер и не задаёт императивной или нормативной спецификации.
Модуль YANG IEEE Std 1588-2008 представляет сотрудничество между IETF (YANG) и IEEE (1588). Для исходной стандартизации модулей YANG IEEE-1588 YANG информационная модель относительно понятна (наборы данных IEEE Std 1588), но нужен опыт работы с YANG, делающий IETF подходящим местом для стандартизации. У TICTOC WG есть опыт работы с IEEE Std 1588, делающий рабочую группу подходящей для разработки в рамках IETF.
IEEE 1588 WG предполагает, что стандарт будет постоянно обновляться. По мере того, как члены IEEE 1588 WG приобретут практический опыт работы с YANG, рабочая группа IEEE 1588 станет более подходящим местом для стандартизации модулей YANG. При пересмотре и/или изменении стандарта IEEE 1588 члены IEEE 1588 смогут более эффективно синхронизировать выпуски модуля YANG с новыми версиями стандарта IEEE 1588.
Это приложение предназначено для установки чётких ожиданий IETF и IEEE в плане грядущей передачи модулей YANG IEEE 1588 в IEEE 1588 WG, чтобы сделать эту передачу как можно более гладкой. По мере передачи могут возникать разные ситуации, которые могут быть разрешены путём обсуждения в почтовых конференциях IETF TICTOC WG и/или у соответствующих представителей.
Это приложение основано на информационном документе [RFC4663], где обсуждается похожая передача работы по MIB от IETF Bridge MIB WG в IEEE 802.1 WG.
A.1. Допущения о переносе
Предположим, что в IESG одобрена публикация RFC с модулем YANG для опубликованного стандарта IEEE 1588. Сейчас это IEEE Std 1588-2008, но возможны выпуски модулей YANG для последующих версий 1588, которые может публиковать IETF TICTOC WG. В этом приложении используется выражение «последний выпуск YANG IETF 1588» для обозначения наиболее свежего опубликованного модуля YANG 1588 от IETF TICTOC WG.
Комитет по новым стандартам (New Standards Committee или NesCom) совета по стандартизации IEEE-SA обрабатывает новые запросы на предоставление полномочий проектам (Project Authorization Request или PAR, <http://standards.ieee.org/board/nes/>). Документы PAR похожи на уставы рабочих групп (Working Group Charter) IETF и включают сведения, относящиеся к области действия, цели и обоснованию проектов стандартизации.
Предположим, что в IEEE 1588 одобрен новый документ PAR, явно задающий разработку модуля YANG. Передача работы YANG будет происходит в контексте IEEE 1588 PAR. В этом приложении используется выражение “первый стандарт YANG IEEE 1588» для обозначения первого стандарта IEEE 1588 для YANG.
Предположим, что в рамках передачи работы YANG группа IETF TICTOC WG согласилась прервать свою работу над стандартными модулями YANG для IEEE 1588. Также предположим, что IEEE 1588 WG участвовала в разработке последнего выпуска модуля YANG IETF 1588, так что первый стандарт YANG IEEE 1588 фактически будет выпуском этого модуля. Иными словами, передача работы YANG будет достаточно «чистой».
Реальные условия будущего переноса могут привести к нарушению этих предположений и такие исключения потребуется рассматривать отдельно. В этом приложении рассмотрены вопросы, которые можно решить на основе принятый выше допущений.
A.2. Вопросы интеллектуальной собственности
При рассмотрении юридических вопросов, связанных с передачей документов Bridge MIB WG в IEEE 802.1 WG (параграф 3.1 и раздел 9 в [RFC4663]) был сделан вывод об отсутствии у IETF достаточных юридических полномочий для передачи документов в IEEE без согласия авторов.
Если последний выпуск YANG IETF 1588 публикуется как RFC, работа должна быть передана из IETF в IEEE, чтобы IEEE 1588 WG могла начать работу над первым стандартом YANG IEEE 1588.
Когда работа над первым модулем IEEE YANG начнётся в IEEE 1588 WG, она будет базироваться на последнем модуле IETF YANG из этого RFC, что требует передачи этой работы из IETF в IEEE. Чтобы передача не зависела от авторов этого RFC, отдел управления рисками и лицензирования IEEE SA предоставил авторам соответствующие формы и механизмы для неисключительного предоставления IEEE прав на создание производных от документа работ. Эти формы и механизмы потребуется обновлять для будущих моделей IETF YANG IEEE 1588 (подписанные формы хранятся в отделе управления рисками и лицензирования IEEE SA). Это поможет сделать будущую передачу работы из IETF в IEEE максимально гладкой.
Как отмечено в разделе «Статус документа», содержащийся здесь модуль YANG соответствует положениям BCP 78. IETF сохраняет за собой все права, предоставленные на момент публикации RFC.
A.3. Пространство имён и имя модуля
Как указано в разделе 5. Взаимодействие с IANA, модуль YANG из этого документа использует IETF как корень своего пространства имён URN и имени модуля YANG. Использование IETF в качестве корня для этих имён подразумевает, что модуль YANG стандартизован рабочей группой IETF по процессу IETF. Если рабочая группа IEEE 1588 продолжит использовать имена с корнями в IETF, стандартизацию IEEE 1588 YANG придётся сохранять в IETF. Цель переноса работы YANG состоит в исключении такой зависимости между органами стандартизации.
В IEEE 802 имеется активный документ PAR (IEEE P802d) по созданию пространства имён URN для использования IEEE (<http://standards.ieee.org/develop/project/802d.html>). Вполне вероятно одобрение и публикация IEEE 802 PAR до переноса работы YANG в IEEE 1588 WG. В этом случае IEEE 1588 WG может использовать пространство имён IEEE URN для первого стандартного модуля YANG IEEE 1588, например, urn:ieee:Std:1588:yang:ieee1588-ptp, где ieee1588-ptp – зарегистрированное имя модуля YANG в IEEE.
При допущениях из Приложения A.1, префикс первого модуля YANG IEEE 1588 будет совпадать с префиксом последнего модуля YANG IETF 1588 (т. е. ptp). Другие модули YANG могут сохранять префикс импорта ptp для доступа к узлам PTP в процессе перехода от последнего модуля YANG IETF 1588 к первому YANG IEEE 1588.
Результатом такой смены имён будет то, что для полной совместимости сервер (узел IEEE 1588) может реализовать последний модуль YANG IETF 1588 (с корнем IETF) и первый модуль YANG IEEE 1588 (with IEEE root). Поскольку содержимое передаваемого модуля YANG не меняется, реализация сервера фактически одинакова для обоих.
Клиент последнего модуля YANG IETF 1588 (или более ранних) ищет модуль с корнем IETF, а клиент первого YANG IEEE 1588 (или позднее) ищет модуль с корнем IEEE.
A.4. Модули YANG IEEE 1588 в формате ASCII
Хотя IEEE 1588 может принять решение о публикации модулей YANG лишь в формате PDF, который принят для их стандартов, не публикуя вариант ASCII, но большинство систем сетевого управления не сможет импортировать модули YANG из PDF. Таким образом, отказ от публикации ASCII-версии модуля YANG негативно повлияет на реализацию и внедрение модуля YANG и затруднить возможное рецензирование модуля со стороны IETF.
Этот документ рекомендует IEEE 1588 WG рассмотреть свои будущие планы в части указанных ниже аспектов.
-
Общий доступ к модуля YANG в формате ASCII в процессе разработки проектов. Эти файлы позволят участникам IETF работать с этими документами для предварительного рецензирования.
-
Общедоступная YANG-часть выпущенных стандартов IEEE 1588, предоставляемая в форме файла ASCII для каждого модуля YANG. Эти файлы ASCII предназначены для использования стандарта IEEE 1588.
Как пример общей доступности в IEEE 802 при разработке проектов используется тот же репозиторий, который IETF использует для разработки модулей YANG (<https://github.com/YangModels/yang>). Ветви IEEE предназначены для экспериментальных работ (до PAR), а также стандартных работ (после PAR). В IEEE-SA одобрено использование этого репозитория для разработки проектов, но не для опубликованных стандартов.
Примером публичной доступности для опубликованных стандартов IEEE 802.1 может служить список ASCII-файлов для MIB (<http://www.ieee802.org/1/files/public/MIBs/> и <http://www.ieee802.org/1/pages/MIBS.html>). Аналогичные списки планируются и для файлов IEEE 802.1 YANG.
Благодарности
Авторы благодарны Tom Petch, Radek Krejci, Mahesh Jethanandani, Tal Mizrahi, Opher Ronen, Liang Geng, Alex Campbell, Joe Gwinn, John Fletcher, William Zhao, Dave Thaler за их значимые рецензии и предложения. Спасибо Benoit Claise и Radek Krejci за проверку модуля YANG, а также Jingfei Lv и Zitao Wang за обсуждения IEEE 1588 и YANG, соответственно.
Адреса авторов
Yuanlong Jiang (editor) Huawei Bantian, Longgang district Shenzhen 518129 China Email: jiangyuanlong@huawei.com Xian Liu Independent Shenzhen 518129 China Email: lene.liuxian@foxmail.com Jinchun Xu Huawei Bantian, Longgang district Shenzhen 518129 China Email: xujinchun@huawei.com Rodney Cummings (editor) National Instruments 11500 N. Mopac Expwy Bldg. C Austin, TX 78759-3504 United States of America Email: Rodney.Cummings@ni.comПеревод на русский язык
Николай Малых
1Internet Engineering Task Force – комиссия по решению инженерных задач Internet.
2Internet Engineering Steering Group – комиссия по инженерным разработкам Internet.
3Имена атрибутов соответствуют IEEE Std 1588-2008, но изменены в стиле YANG, т. е. приведены к нижнему регистру и пробелы заменены символами дефиса.