Увядзенне
Канцэпцыя пабудовы "Лічбавай падстанцыі" ў электраэнергетыцы патрабуе сінхранізацыі з дакладнасцю 1 мкс. Для правядзення фінансавых транзакцый таксама патрэбна дакладнасць у мкс. У гэтых прыкладаннях дакладнасці часу NTP ужо недастаткова.
Пратакол сінхранізацыі PTPv2, апісаны стандартам IEEE 1588v2, дазваляе дамагчыся дакладнасці сінхранізацыі ў некалькі дзясяткаў нанасекунд. PTPv2 дазваляе адпраўляць пакеты сінхранізацыі праз L2 і L3-сеткі.
Асноўнымі абласцямі, дзе прымяняецца PTPv2, з'яўляюцца:
- энергетыка;
- кантрольна-вымяральнае абсталяванне;
- абаронна-прамысловы комплекс;
- целікам;
- фінансавы сектар.
У дадзеным пасце разбіраецца, як працуе пратакол сінхранізацыі PTPv2.
У нас больш вопыту ў прамысловасці і мы часта сустракаемся з гэтым пратаколам у энергетычных дадатках. Адпаведна, і агляд зробім з аглядкай .
Навошта неабходны?
На дадзены момант у СТА 34.01-21-004-2019 ПАТ "Россети" і ў СТА 56947007-29.240.10.302-2020 ПАТ "ФСК ЕЭС" змяшчаюцца патрабаванні да арганізацыі шыны працэсу з забеспячэннем сінхранізацыі часу па PTPv2.
Звязана гэта з тым, што да шыны працэсу падлучаюцца тэрміналы рэлейнай абароны і прылады вымярэння, якія праз шыну працэсу, пры дапамозе так званых SV-струменяў (multicast-струмені), перадаюць імгненныя значэнні току і напругі.
Тэрміналы рэлейнай абароны выкарыстоўваюць гэтыя значэнні для рэалізацыі абарон далучэнняў. Калі дакладнасць вымярэнняў па часе будзе невялікай, то некаторыя абароны могуць ілжыва адпрацоўваць.
Напрыклад, ахвярай "слабой" сінхранізацыі часу могуць стаць абароны абсалютнай селектыўнасці. Часта логіка падобных абарон будуецца на параўнанні дзвюх велічынь. Калі велічыні разыходзяцца на дастаткова вялікае значэнне, то абарона спрацоўвае. Калі гэтыя велічыні вымераць з дакладнасцю часу 1 мс, то можна атрымаць вялікую розніцу там, дзе значэння на самой справе знаходзяцца ў норме, калі вымераць іх з дакладнасцю 1 мкс.
Версіі PTP
Пратакол PTP быў першапачаткова апісаны ў 2002 годзе ў стандарце IEEE 1588-2002 і меў назву "Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems". У 2008 годзе быў выпушчаны абноўлены стандарт IEEE 1588-2008, які апісвае PTP Version 2. У гэтай версіі пратакола была палепшана дакладнасць і стабільнасць, але не была захавана зваротная сумяшчальнасць з першай версіяй пратакола. Таксама, у 2019 годзе выйшла версія стандарту IEEE 1588-2019, якая апісвае PTP v2.1. Гэтая версія дадае невялікія паляпшэнні да PTPv2 і з'яўляецца зваротна сумяшчальнай з PTPv2.
Іншымі словамі, маем наступную карціну з версіямі:
PTPv1
(IEEE 1588-2002)
PTPv2
(IEEE 1588-2008)
PTPv2.1
(IEEE 1588-2019)
PTPv1 (IEEE 1588-2002)
-
Несумяшчальныя
Несумяшчальныя
PTPv2 (IEEE 1588-2008)
Несумяшчальныя
-
Сумяшчальныя
PTPv2.1 (IEEE 1588-2019)
Несумяшчальныя
Сумяшчальныя
-
Але, як і заўжды, ёсць нюансы.
Несумяшчальнасць паміж PTPv1 і PTPv2 мяркуе, што прылада з падтрымкай PTPv1 не зможа сінхранізавацца ад дакладных гадзін, якія працуюць на PTPv2. Для сінхранізацыі яны выкарыстоўваюць розныя фарматы паведамленняў.
Але сумясціць прылады c PTPv1 і прылады з PTPv2 у адной сетцы ўсёткі можна. Для гэтага некаторыя вытворцы дазваляюць на партах межавых гадзіннікаў выбіраць версію пратаколу. Гэта значыць, межавыя гадзіны могуць сінхранізавацца па PTPv2 і пры гэтым сінхранізаваць іншыя падлучаныя да іх гадзіны і па PTPv1, і па PTPv2.
Прылады PTP. Якія бываюць і чым адрозніваюцца?
Стандартам IEEE 1588v2 апісана некалькі тыпаў прылад. Усе яны прыведзены ў табліцы.
Прылады ўзаемадзейнічаюць сябар з сябрам праз ЛВС, выкарыстаючы PTP.
Прылады PTP называюцца гадзінамі. Усе гадзіны бяруць дакладны час у гросмайстарскіх гадзіннікаў.
Ёсць 5 тыпаў гадзін:
Grandmaster clock (Гросмайстарскі гадзіннік)
Асноўная крыніца дакладнага часу. Часта абсталёўваюцца інтэрфейсам для падлучэння GPS.
Ordinary Clock (Звычайныя гадзіны)
Прылада з адным портам, якое можа быць майстрам (вядучым гадзіннікам) або слэйвам (вядомым гадзіннікам)
Вядучыя гадзіны (майстар)
З'яўляюцца крыніцай сапраўды часу, па якім сінхранізуюцца іншыя гадзіны.
Вядзёны гадзіннік (слэйв)
Канчатковая прылада, якое сінхранізуецца ад вядучых гадзін
Boundary Clock (Прымежны гадзіннік)
Прылада з некалькімі партамі, якое можа быць майстрам ці слейвам.
Гэта значыць гэтыя гадзіны могуць сінхранізавацца ад вышэйстаячых кіроўных гадзін і сінхранізаваць ніжэйстаячыя кіраваныя гадзіны.
End-to-end Transparent Clock (Празрысты гадзіннік, які працуе ў рэжыме End-to-End)
Прылада з некалькімі партамі, якое не з'яўляецца ні вядучымі гадзінамі, ні кіраванымі. Яно перадае дадзеныя PTP паміж двума гадзінамі.
Пры перадачы дадзеных празрыстыя гадзіны карэктуюць усе PTP-паведамленні.
Карэкціроўка адбываецца за кошт дадання часу затрымкі на гэтай прыладзе ў поле карэкцыі ў загалоўку перадаецца паведамлення.
Peer-to-Peer Transparent Clock (Празрысты гадзіннік, які працуе ў рэжыме Peer-to-Peer)
Прылада з некалькімі партамі, якое не з'яўляецца ні вядучымі гадзінамі, ні кіраванымі.
Яно перадае дадзеныя PTP паміж двума гадзінамі.
Пры перадачы дадзеных празрыстыя гадзіны карэктуюць усе PTP-паведамленні Sync і Follow_Up (пра іх падрабязней расказана ніжэй).
Карэкціроўка дасягаецца за кошт дадання да поля карэкціроўкі перадаецца пакета затрымкі на якая перадае прыладзе і затрымкі на канале перадачы дадзеных.
Management Node (Кіравальны вузел)
Прылада, якое канфігуруе і дыягнастуе іншыя гадзіны
Вядучыя і кіраваныя гадзіны сінхранізуюцца пры дапамозе пазнак часу ў PTP-паведамленнях. Ёсць два тыпу паведамленняў у PTP-пратаколе:
- Event Messages – гэта сінхранізаваныя паведамленні, якія мяркуюць генерацыю пазнакі часу ў момант адпраўкі паведамлення і ў момант яго прыёму
- General Messages – гэтыя паведамленні не патрабуюць пазнак часу, але могуць змяшчаць пазнакі часу для звязаных паведамленняў
Паведамленні аб падзеях
Агульныя паведамленні
Сінхранізацыя
Delay_Req
Pdelay_Req
Pdelay_Resp
Абвясці
Follow_Up
Delay_Resp
Pdelay_Resp_Follow_Up
кіраванне
сігналізацыі
Далей будуць разгледжаны ўсе тыпы паведамленняў больш падрабязна.
Асноўныя праблемы сінхранізацыі
Пры перадачы пакета сінхранізацыі праз лакальную сетку ён затрымоўваецца на камутатары і ў канале перадачы дадзеных. Любы камутатар будзе даваць затрымку каля 10 мкс, што недапушчальна для PTPv2. Бо нам на канчатковым прыладзе неабходна атрымаць дакладнасць 1 мкс. (Гэта калі гаворка ідзе пра энергетыку. Іншыя прыкладанні могуць патрабаваць і большай дакладнасці.)
У IEEE 1588v2 апісаны некалькі алгарытмаў працы, якія дазваляюць фіксаваць затрымку часу і карэктаваць яе.
алгарытм працы
Пры нармальнай працы пратакол працуе ў дзве фазы.
- Фаза 1 — устаноўка іерархіі «Вядучы гадзіннік – Кіраваны гадзіннік».
- Фаза 2 - сінхранізацыя гадзін пры дапамозе механізму End-to-End або Peer-to-Peer.
Фаза 1 — Устаноўка іерархіі «Майстар-Слэйв»
Кожны порт звычайных або межавых гадзін мае пэўную колькасць станаў (кіраваны гадзіннік і вядучыя гадзіннік). Стандарт апісвае алгарытм пераходу паміж гэтымі станамі. У праграмаванні такі алгарытм завецца канчатковым аўтаматам ці машынай станаў (падрабязней у Wiki).
Гэты канчатковы аўтамат выкарыстоўвае алгарытм Best Master Clock Algorithm (BMCA) для ўстаноўкі майстра пры злучэнні дзвюх гадзін.
Дадзены алгарытм дазваляе гадзінам браць на сябе абавязанні гросмайстарскіх гадзін, калі вышэйстаячыя гросмайстарскія гадзіны губляюць сігнал GPS, адключаюцца ад сеткі і г.д.
Пераходы паміж станамі ў адпаведнасці з BMCA коратка адлюстраваны на наступнай схеме:
Інфармацыя аб гадзінах на іншым канцы "провада" дасылаецца ў спецыяльным паведамленні (Announce message). Калі гэтая інфармацыя атрымана, алгарытм машыны станаў адпрацоўвае і выконваецца параўнанне, якія гадзіны лепш. Порт на лепшым гадзінніку становіцца вядучым гадзіннікам.
Простая іерархія прадстаўлена схеме ніжэй. Шляхі 1, 2, 3, 4, 5 могуць змяшчаць празрыстыя гадзіннікі (Transparent clock), але яны не ўдзельнічаюць ва ўсталяванні іерархіі «Вядучыя гадзіны – Кіраваны гадзіннік».
Фаза 2 - Сінхранізацыя звычайных і межавых гадзін.
Адразу пасля ўстаноўкі іерархіі "Вядучы гадзіннік - Кіраваны гадзіннік" пачынаецца фаза сінхранізацыі звычайных і межавых гадзін.
Для сінхранізацыі вядучыя гадзіны адпраўляюць кіраваным гадзінам паведамленне, якое змяшчае пазнаку часу.
Вядучыя гадзіны могуць быць:
- аднаступенныя;
- двухступеністыя.
Аднаступенныя гадзіны для сінхранізацыі пасылаюць адно паведамленне Sync.
Двухступеністыя гадзіны для сінхранізацыі выкарыстоўваюць два паведамленні - Sync і Follow_Up.
Для фазы сінхранізацыі могуць быць скарыстаны два механізму:
- Механізм запыту-адказу затрымкі (Delay request-response mechanism).
- Механізм вымярэння затрымкі суседняга вузла (Peer delay measurement mechanism).
Для пачатку разгледзім гэтыя механізмы ў самым найпростым выпадку - калі не ўжываюцца празрыстыя гадзіны.
Механізм запыту-адказу затрымкі (Delay request-response mechanism)
Механізм мяркуе два крокі:
- Вымярэнне затрымкі пры перадачы паведамлення паміж вядучымі гадзінамі і кіраванымі. Выконваецца пры дапамозе механізма запыту-адказу затрымкі.
- Выконваецца карэкцыя зруху дакладнага часу.
Вымярэнне затрымкі
t1 - Час адпраўкі паведамлення Sync вядучымі гадзінамі; t2 - Час прыёму паведамлення Sync кіраваным гадзінамі; t3 - Час адпраўкі запыту затрымкі (Delay_Req) кіраваным гадзінамі; t4 - Час прыёму Delay_Req кіроўнымі гадзінамі.
Калі кіраваныя гадзіны ведаюць час t1, t2, t3 і t4, то яны могуць разлічыць сярэднюю затрымку пры перадачы паведамлення сінхранізацыі (tmpd). Яна разлічваецца наступным чынам:
Пры перадачы паведамлення Sync і Follow_Up вылічаецца затрымка часу ад майстра да слэйву - t-ms.
Пры перадачы паведамленняў Delay_Req і Delay_Resp вылічаецца затрымка часу ад слэйву да майстра - t-sm.
Калі паміж гэтымі двума значэннямі ўзнікае нейкая асіметрыя, тое з'яўляецца памылка карэкцыі сыходу дакладнага часу. Памылка абумоўліваецца тым, што вылічаная затрымка з'яўляецца сярэдняй ад затрымак t-ms і t-sm. Калі затрымкі не роўныя адна адной, то мы будзем карэктаваць час недакладна.
Карэкцыя зруху дакладнага часу
Пасля таго як затрымка паміж кіроўнымі гадзінамі і кіраванымі гадзінамі вядомая, кіраваныя гадзіны выконваюць карэкцыю часу.
Вядзёныя гадзіны выкарыстаюць паведамленне Sync і апцыянальнае паведамленне Follow_Up для разліку зруху дакладнага часу пры перадачы пакета ад кіроўных гадзін да кіраваных. Зрух разлічваецца па наступнай формуле:
Механізм вымярэння затрымкі суседняга вузла (Peer delay measurement mechanism)
Дадзены механізм таксама выкарыстоўвае два крокі для сінхранізацыі:
- Прылады вымяраюць затрымку часу да ўсіх суседзяў праз усе парты. Для гэтага яны выкарыстоўваюць peer delay mechanism.
- Карэкціроўка зруху дакладнага часу.
Вымярэнне затрымкі паміж прыладамі, якія падтрымліваюць рэжым Peer-to-Peer
Затрымка паміж партамі, якія падтрымліваюць механізм peer-to-peer, вымяраецца пры дапамозе наступных паведамленняў:
Калі порце 1 вядомы час t1, t2, t3 і t4, ён можа разлічыць сярэднюю затрымку (tmld). Яна разлічваецца па наступнай формуле:
Затым порт выкарыстоўвае гэта значэнне пры разліку поля карэкціроўкі для кожнага паведамлення Sync або апцыянальнага паведамлення Follow_Up, якія праходзяць праз дадзеную прыладу.
Выніковая затрымка будзе роўная суме затрымкі пры перадачы праз дадзеную прыладу, сярэдняй затрымкі пры перадачы праз канал дадзеных і ўжо якая змяшчаецца затрымкі ў дадзеным паведамленні, уключанай на вышэйстаячых прыладах.
Паведамленні Pdelay_Req, Pdelay_Resp і апцыянальнае Pdelay_Resp_Follow_Up дазваляе атрымаць затрымку ад майстра да слэйву і ад слэйва да майстра (кругавую).
Любая асіметрыя паміж гэтымі двума значэннямі прыўнясе памылку карэкцыі зруху дакладнага часу.
Карэкціроўка зруху дакладнага часу
Вядзёныя гадзіны выкарыстаюць Sync-паведамленне і апцыянальнае паведамленне Follow_Up для разліку зруху дакладнага часу пры перадачы пакета ад кіроўных гадзін да кіраваных. Зрух разлічваецца па наступнай формуле:
Перавагі карэкціроўка механізму peer-to-peer - затрымка часу кожнага паведамлення Sync або Follow_Up разлічваецца па ходзе яго перадачы ў сетцы. Такім чынам, і змена шляху перадачы не паўплывае ніякай выявай на дакладнасць карэкціроўкі.
Пры выкарыстанні гэтага механізму сінхранізацыя часу не патрабуе разліку затрымкі часу на пройдзеным пакетам сінхранізацыі шляху, як гэта робіцца пры базавым абмене. Г.зн. паведамлення Delay_Req і Delay_Resp не адпраўляюцца. У гэтым метадзе затрымка паміж кіроўнымі гадзінамі і кіраванымі проста падсумоўваецца ў поле карэкціроўкі кожнага паведамлення Sync або Follow_Up.
Яшчэ адна перавага - вядучыя гадзіны разгружаюцца ад неабходнасці апрацоўваць паведамленні Delay_Req.
Рэжымы працы празрыстых гадзін
Адпаведна, гэта былі разабраныя простыя прыклады. А зараз выкажам здагадку, што на шляхі сінхранізацыі з'яўляюцца камутатары.
Калі выкарыстоўваць камутатары без падтрымкі PTPv2, то пакет сінхранізацыі будзе затрымоўвацца на камутатары прыкладна на 10 мкс.
Камутатары з падтрымкай PTPv2 у тэрміналогіі IEEE 1588v2 завуцца празрыстымі гадзінамі (Transparent clock). Празрысты гадзіннік не сінхранізуецца ад вядучых гадзіннікаў і не ўдзельнічае ў іерархіі «Вядучы гадзіннік - Кіраваны гадзіннік», але пры перадачы паведамленняў сінхранізацыі запамінаюць, на колькі паведамленне затрымалася на іх. Гэта дазваляе скарэктаваць затрымку часу.
Празрысты гадзіннік можа працаваць у двух рэжымах:
- End-to-End.
- Равеснік.
End-to-End (E2E)
Празрыстыя гадзіны E2E перадаюць паведамленні Sync і спадарожныя паведамленні Follow_Up на ўсе парты. Нават на тыя, якія заблакаваныя якімі-небудзь пратаколамі (напрыклад, RSTP).
Камутатар запамінае пазнаку часу, калі пакет Sync (Follow_Up) быў прыняты на порт і калі быў адпраўлены з порта. На падставе гэтых двух пазнак часу вылічаецца час апрацоўкі камутатарам паведамлення. У стандарце гэты час завецца residence time.
Час апрацоўкі дадаецца ў поле correctionField паведамлення Sync (аднаступеньчатыя гадзіны) або Follow_Up (двухступеністыя гадзіны).
Празрыстыя гадзіны E2E вымяраюць час апрацоўкі для паведамленняў Sync і Delay_Req, якія праходзяць праз камутатар. Але пры гэтым важна разумець, што затрымка часу паміж кіроўнымі гадзінамі і кіраваным гадзінамі вылічаецца пры дапамозе механізму запыту-адказу затрымкі. Калі кіроўныя гадзіны змяняюцца ці змяняецца шлях ад кіроўных гадзін да кіраваных, то затрымка вымяраецца нанова. Гэта павялічвае час пераходнага стану ў выпадку зменаў сеткі.
Празрыстыя гадзіны P2P, акрамя вымярэння часу апрацоўкі паведамлення камутатарам, вымяраюць затрымку на канале перадачы дадзеных да бліжэйшага суседа, выкарыстоўваючы механізм вымярэння затрымкі суседняга вузла.
Затрымка вымяраецца на кожным канале ў абодвух напрамках, у тым ліку каналы, якія заблакаваныя якім-небудзь пратаколам (напрыклад, RSTP). Гэта дазваляе адразу вылічыць новую затрымку на шляху сінхранізацыі, калі змяніліся гросмайстарскія гадзіны або тапалогія сеткі.
Час апрацоўкі паведамленняў камутатарамі і час затрымкі акумулююцца пры перадачы паведамленняў Sync ці Follow_Up.
Тыпы падтрымкі PTPv2 камутатарамі
Камутатары могуць падтрымліваць PTPv2:
- праграмна;
- апаратна.
Пры праграмнай рэалізацыі пратаколу PTPv2 камутатар запытвае пазнаку часу ў прашыўкі. Праблема заключаецца ў тым, што прашыўка працуе цыклічна, і давядзецца пачакаць, пакуль яна скончыць бягучы цыкл, возьме запыт у апрацоўку і па заканчэнні наступнага цыклу выдасць пазнаку часу. На гэта ўсё таксама спатрэбіцца час, і мы атрымаем затрымку, хай і не такую істотную як без праграмнай падтрымкі PTPv2.
Выканаць неабходную дакладнасць дазваляе толькі апаратная падтрымка PTPv2. У гэтым выпадку выдача пазнакі часу выконваецца адмысловым ASIC'ом, які ўсталяваны на порт.
Фармат паведамлення
Усе паведамленні PTP складаюцца з наступных палёў:
- Header - 34 байта.
- Body - памер залежыць ад тыпу паведамлення.
- Suffix апцыянальна.
Загаловак
Поле Header аднолькава для ўсіх допісаў PTP. Яго памер - 34 байта.
Фармат поля Header:
messageType - Змяшчае тып перадаецца паведамлення, напрыклад Sync, Delay_Req, PDelay_Req і г.д.
messageLength – утрымоўвае поўны памер паведамлення PTP, уключаючы header, body і suffix (але выключаючы якія запаўняюць байты).
domainNumber - вызначае, да якога дамену PTP належыць паведамленне.
дамен – гэта некалькі розных гадзін, сабраных у адну лагічную групу і сінхранізаваных ад адных вядучых гадзін, але не абавязкова сінхранізаваных з гадзінамі, якія належаць да іншага дамену.
Сцягі – гэтае поле змяшчае розныя сцягі для ідэнтыфікацыі статусу паведамлення.
correctionField - змяшчае час затрымкі ў нанасекундах. Час затрымкі ўключае ў сябе затрымку пры перадачы праз празрыстыя гадзіны, а таксама затрымку пры перадачы праз канал пры выкарыстанні рэжыму Peer-to-Peer.
sourcePortIdentity - дадзенае поле змяшчае інфармацыю аб тым, з якога порта было першапачаткова адпраўлена дадзенае паведамленне.
sequenceID - змяшчае ідэнтыфікацыйны нумар для індывідуальных паведамленняў.
controlField – поле-артэфакт=) Яно засталося ад першай версіі стандарту і ўтрымоўвае ў сабе інфармацыю аб тыпе дадзенага паведамлення. Па сутнасці, тое ж самае, што і messageType, але з меншай колькасцю опцый.
logMessageInterval - дадзенае поле вызначаецца тыпам паведамлення.
Цела
Як абмяркоўвалася вышэй, існуе некалькі тыпаў паведамленняў. Гэтыя тыпы апісаны ніжэй:
Паведамленне Announce
Паведамленне Announce выкарыстоўваецца для таго, каб "расказаць" іншым гадзінам усярэдзіне аднаго дамена аб сваіх параметрах. Гэта паведамленне дазваляе ўсталяваць іерархію "Вядучы гадзіннік - Кіраваны гадзіннік".
Паведамленне Sync
Паведамленне сінхранізацыі (Sync) адпраўляецца вядучымі гадзінамі і змяшчае час вядучых гадзін на момант, калі паведамленне Sync было створана. Калі вядучыя гадзіны двухступеністыя, то пазнака часу ў паведамленні Sync будзе прыраўнавана да 0, а актуальная пазнака часу будзе даслана ў спалучаным паведамленні Follow_Up. Паведамленне Sync выкарыстоўваецца для абодвух механізмаў вымярэння затрымкі.
Паведамленне перадаецца пры дапамозе Multicast. Апцыянальна можна выкарыстоўваць Unicast.
Паведамленне Delay_Req
Фармат паведамлення Delay_Req ідэнтычны паведамленні Sync. Вядзёныя гадзіны пасылаюць Delay_Req. Яно змяшчае час адпраўкі Delay_Req кіраваным гадзінамі. Дадзенае паведамленне выкарыстоўваецца толькі для механізму запыту-адказу затрымкі.
Паведамленне перадаецца пры дапамозе Multicast. Апцыянальна можна выкарыстоўваць Unicast.
Паведамленне Follow_Up
Паведамленне Follow_Up апцыянальна адпраўляецца вядучымі гадзінамі і змяшчае час адпраўкі паведамлення Sync майстрам. Паведамленне Follow_Up адпраўляюць толькі двухступеністыя вядучыя гадзіны.
Паведамленне Follow_Up выкарыстоўваецца для абодвух механізмаў вымярэння затрымкі.
Паведамленне перадаецца пры дапамозе Multicast. Апцыянальна можна выкарыстоўваць Unicast.
Паведамленне Delay_Resp
Паведамленне Delay_Resp адпраўляецца вядучымі гадзінамі. Яно змяшчае час прыёму Delay_Req вядучымі гадзінамі. Дадзенае паведамленне выкарыстоўваецца толькі для механізму запыту-адказу затрымкі.
Паведамленне перадаецца пры дапамозе Multicast. Апцыянальна можна выкарыстоўваць Unicast.
Паведамленне Pdelay_Req
Паведамленне Pdelay_Req адпраўляецца прыладай, якое запытвае затрымку. Яно змяшчае час адпраўкі паведамлення з порта гэтай прылады. Pdelay_Req выкарыстоўваецца толькі для механізму вымярэння затрымкі суседняга вузла.
Паведамленне Pdelay_Resp
Паведамленне Pdelay_Resp адпраўляецца прыладай, якая атрымала запыт на затрымку. Яно ўтрымоўвае час прыёму паведамлення Pdelay_Req дадзенай прыладай. Паведамлення Pdelay_Resp выкарыстоўваецца толькі для механізму вымярэння затрымкі суседняга вузла.
Паведамленне Pdelay_Resp_Follow_Up
Паведамленне Pdelay_Resp_Follow_Up апцыянальна адпраўляецца прыладай, якое атрымала запыт на затрымку. Яно змяшчае час прыёму паведамлення Pdelay_Req гэтай прыладай. Паведамленне Pdelay_Resp_Follow_Up адпраўляецца толькі двухступеністымі вядучымі гадзінамі.
Таксама гэтае паведамленне можа выкарыстоўвацца для часу выканання замест пазнакі часу. Час выканання - гэта час ад моманту атрымання Pdelay-Req да адпраўкі Pdelay_Resp.
Pdelay_Resp_Follow_Up выкарыстоўваюцца толькі для механізму вымярэння затрымкі суседняга вузла.
Кіравальныя паведамленні (Паведамленне Management)
Кіравальныя паведамленні PTP неабходныя для перадачы інфармацыі паміж аднымі ці некалькімі гадзінамі і кіравальным вузлом.
Перадача ў ЛВ
PTP-паведамленне можа перадавацца на двух узроўнях:
- Сеткавым - у складзе IP-дадзеных.
- Канальным - у складзе Ethernet-фрэйма.
Перадача паведамлення PTP праз UDP праз IP праз Ethernet
PTP праз UDP праз Ethernet
профілі
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.
Дамен па змаўчанні - 0, рэкамендуемы дамен - 93.
У філасофіі стварэння C37.238-2011 ляжала жаданне паменшыць колькасць апцыянальных характарыстык і пакінуць толькі неабходныя функцыі для надзейнага ўзаемадзеяння паміж прыладамі і павышэння стабільнасці сістэмы.
Таксама, вызначана частата перадачы паведамленняў:
Па сутнасці для выбару даступны толькі адзін параметр - тып вядучых гадзін (аднаступеністыя або двухступеністыя).
Дакладнасць павінна быць не больш за 1 мкс. Іншымі словамі ў адным шляху сінхранізацыі можа ўтрымоўвацца максімальна 15 празрыстых гадзін ці тры межавыя гадзіны.
Крыніца: habr.com