Прозрачные часы E2E измеряют время обработки для сообщений Sync
и Delay_Req, проходящих через коммутатор. Но при этом важно понимать, что задержка времени между ведущими часами и ведомыми часами вычисляется при помощи механизма запроса-ответа задержки. Если ведущие часы меняются или меняется путь от ведущих часов до ведомых, то задержка измеряется заново. Это увеличивает время переходного состояния в случае изменений сети.
Peer-to-Peer
Прозрачные часы P2P, помимо измерения времени обработки сообщения коммутатором, измеряют задержку на канале передачи данных до ближайшего соседа, используя механизм измерения задержки соседнего узла.
Задержка измеряется на каждом канале в обоих направлениях, включая каналы, которые заблокированы каким-либо протоколом (например, RSTP). Это позволяет сразу вычислить новую задержку на пути синхронизации, если изменились гроссмейстерские часы или топология сети.
Время обработки сообщений коммутаторами и время задержки аккумулируются при передачи сообщений Sync или Follow_Up.
•Типы поддержки PTPv2 коммутаторами
•Коммутаторы могут поддерживать PTPv2:
•программно;
•аппаратно.
•При программной реализации протокола PTPv2 коммутатор запрашивает метку времени у прошивки. Проблема заключается в том, что прошивка работает циклически, и придется подождать, пока она закончит текущий цикл, возьмет запрос в обработку и по истечению следующего цикла выдаст метку времени. На это все также уйдет время, и мы получим задержку, пусть и не такую существенную как без программной поддержки PTPv2.
•Соблюсти необходимую точность позволяет только аппаратная поддержка PTPv2. В этом случае выдача метки времени выполняется специальным ASIC’ом, который установлен на порт.
Существует несколько типов сообщений. Эти типы описаны ниже:
•Сообщение Announce
•Используется для того, чтобы «рассказать» другим часам внутри одного домена о своих параметрах. Это сообщение позволяет установить иерархию «Ведущие часы — Ведомые часы».
•Сообщение Sync
•Отправляется ведущими часами и содержит время ведущих часов на момент, когда сообщение Sync было создано. Если ведущие часы двухступенчатые, то метка времени
всообщении Sync будет приравнена к 0, а актуальная метка времени будет послана
всопряженном сообщении Follow_Up. Сообщение Sync используется для обоих механизмов измерения задержки.
•Сообщение передается при помощи Multicast. Опционально можно использовать Unicast.
•Сообщение Delay_Req
•Формат сообщения идентичен сообщению Sync. Ведомые часы посылают Delay_Req. Оно содержит время отправки Delay_Req ведомыми часами. Данное сообщение используется только для механизма запроса-ответа задержки.
•Сообщение передается при помощи Multicast. Опционально можно использовать Unicast.
•Сообщение Follow_Up
•Опционально отправляется ведущими часами и содержит время отправки сообщения Sync мастером. Сообщение Follow_Up отправляют только двухступенчатые ведущие часы. Используется для обоих механизмов измерения задержки и передается при помощи Multicast. Опционально можно использовать Unicast.
•Сообщение Delay_Resp
•Отправляется ведущими часами. Оно содержит время приема Delay_Req ведущими часами. Данное сообщение используется только для механизма запроса-ответа задержки. Сообщение передается при помощи Multicast. Опционально можно использовать Unicast.
•Сообщение Pdelay_Req
•Отправляется устройством, которое запрашивает задержку. Оно содержит время отправки сообщения с порта этого устройства. Pdelay_Req используется только для механизма измерения задержки соседнего узла.
•Сообщение Pdelay_Resp
•Отправляется устройством, которое получило запрос на задержку. Оно содержит время приема сообщения Pdelay_Req данным устройством. Этот формат используется только для механизма измерения задержки соседнего узла.
•Сообщение Pdelay_Resp_Follow_Up
•Опционально отправляется устройством, которое получило запрос на задержку. Оно содержит время приема сообщения Pdelay_Req этим устройством. Сообщение Pdelay_Resp_Follow_Up отправляется только двухступенчатыми ведущими часами.
•Также это сообщение может использоваться для времени исполнения вместо метки времени. Время исполнения — это время от момента получения Pdelay-Req
до отправки Pdelay_Resp.
•Pdelay_Resp_Follow_Up используются только для механизма измерения задержки соседнего узла.
•Управляющие сообщения (Сообщение Management)
•Необходимы для передачи информации между одними или несколькими часами и управляющим узлом.
Профили
•PTP имеет достаточно много «гибких» параметров, которые необходимы настроить. Например:
•Опции BMCA.
•Механизм измерения задержки.
•Интервалы и начальные значения всех конфигурируемых параметров и т.д.
•И несмотря на то, что ранее мы говорили, что устройства PTPv2 совместимы между собой, по-хорошему это не так. Устройства должна иметь одинаковые настройки, чтобы взаимодействовать.
•Поэтому существуют так называемые профили PTPv2. Профили являются группами сконфигурированных настроек и определенных ограничений протокола, чтобы можно было реализовать синхронизацию времени для определенного приложения.
•Сам стандарт IEEE 1588v2 описывает только один профиль — «Default Profile». Все остальные профили созданы и описаны различными организациями и ассоциациями.
•Например, профиль для электроэнергетики или PTPv2 Power Profile был создан комитетом Power Systems Relaying Committee и комитетом Substation Committee общества IEEE Power and Energy Society. Сам профиль носит название IEEE C37.238- 2011.
•Профиль описывает, что PTP может передаваться:
•Только через L2-сети (т.е. Ethernet, HSR, PRP, не IP).
•Сообщения передаются только Multicast-рассылкой.
•В качестве механизма измерения задержки используется Peer delay measurement mechanism.
МАРШРУТИЗАЦИЯ ОПТИЧЕСКИХ КАНАЛОВ
•Маршрутизация оптических каналов в сети необходима для наиболее эффективной организации соединений с точки зрения пропуска информационного трафика и его защиты в условиях ограниченного числа несущих волн (всего до 120волн в диапазонах стандартных волокон C, L(1530–1625нм) с волновым интервалом 0,8нм (частотный интервал 100ГГц) для каналов на скорости 112Гбит/с или до 240 волн с волновым интервалом 0,4нм (частотный интервал 50ГГц)).Маршрутизация оптических каналов осуществляется в отдельных перекрывающихся плоскостях Wi, т.е. на различных длинах волн λi с исключением совпадений (рис. ниже) и возможными вариантами управления одиночными и сцепленными соединениями (несколько каналов для одного соединения).
•Распределение трафика в оптической транспортной сети с позиций функций grooming (Trafficgrooming)может происходить статично, т.е. фиксировано во времени и в пространстве соединений достаточно длительный период и динамично, т.е. изменением структуры предоставляемых ресурсов под информационный трафик по запросам на сеансы с ограниченной длительностью и из-меняемыми скоростями передачи. Для поддержки статической и динамической маршрутизации используются различные алгоритмы и протоколы с назначением ресурсов оптических сетей, например, с назначением когерентных оптических каналов на различные требования по OSNR, общими участками, переприемами с коммутацией и без нее (Single-HopGroomingWDM, Multi- HopGroom-ingWDM–односкачковый (одноступенчатый) и многоскачковый (многоступенчатый) варианты назначения оптических каналов в сети со спектральным мультиплексированием) и т.п.