IEEE1588翻译稿Word格式.docx

IEEE1588翻译稿Word格式.docx

《IEEE1588翻译稿Word格式.docx》由会员分享，可在线阅读，更多相关《IEEE1588翻译稿Word格式.docx（28页珍藏版）》请在冰豆网上搜索。

IEEE1588翻译稿翻译稿IEEEStandardforaPrecisionClockSynchronizationProtocolforNetworkedMeasurementandControlSystems6.Clocksynchronizationmodel6.1GeneralThisclauseprovidesamodelforunderstandingtheoperationofthePrecisionTimeProtocol.Theexactspecificationsoftheseinteractionsarefoundinsubsequentclauses.ThePTPstandardspecifiesaclocksynchronizationprotocol.Thisprotocolisapplicabletodistributedsystemsconsistingofoneormorenodes,communicatingoveranetwork.Nodesaremodeledascontainingareal-timeclockthatmaybeusedbyapplicationswithinthenodeforvariouspurposessuchasgeneratingtimestampsfordataororderingeventsmanagedbythenode.Theprotocolprovidesamechanismforsynchronizingtheclocksofparticipatingnodestoahighdegreeofaccuracyandprecision.Thisstandardspecifies:

@#@a）ThePrecisionTimeProtocolb）Thenode,system,andcommunicationpropertiesnecessarytosupportPTP.6.2PrincipleassumptionsaboutthenetworkandimplementationrecommendationsThefollowingprincipleassumptionsandrecommendationsshouldbefollowedinordertoensurecorrectoperationoftheprotocol.Thesearediscussedingreaterdetailinlaterclauses:

@#@a）PTPassumesthatthenetworkeliminatescyclicforwardingofPTPmessageswithineachcommunicationpath（e.g.,byusingaspanningtreeprotocol）.PTPeliminatescyclicforwardingofPTPmessagesbetweencommunicationpaths.b）PTPistolerantofanoccasionalmissedmessage,duplicatedmessage,ormessagethatarrivedoutoforder.However,PTPassumesthatsuchimpairmentsarerelativelyrare.c）PTPwasdesignedassumingamulticastcommunicationmodel.PTPalsosupportsaunicastcommunicationmodelaslongasthebehavioroftheprotocolispreserved.PTPassumesthatAnnouncemessagesareperiodicallysentbyoneportanddeliveredtoallotherportsofordinaryorboundaryclockswithinacommunicationpath.Ifthecommunicationpathconsistsofmorethantwoports,theassumptionisthatAnnouncemessagesareeithersentinmulticastortheAnnounceinformationisreplicatedtoallportsinthecommunicationpathusingunicastmessages.PTPportsdiscoverotherportswithinacommunicationpaththroughthereceiptofmulticastAnnouncemessages.Whenmulticastcommunicationisnotavailable,anotherformofdiscovery（e.g.,byconfiguration）isrequired;@#@seeforexample17.5.PTPmanagementmessagessenttoallportsalsorequireeithermulticastmessagingorreplicationofthemanagementmessagetoallportswithinthecommunicationpath.d）Likeallmessage-basedtimetransferprotocols,PTPtimeaccuracyisdegradedbyasymmetryinthepathstakenbyeventmessages;@#@see7.4.2.Specificallythetimeoffseterroris1/2oftheasymmetry.AsymmetryisnotdetectablebyPTP;@#@however,ifknown,PTPcorrectsforasymmetry.Asymmetrycanbeintroducedinthephysicallayer,e.g.,viatransmissionmediaasymmetry,bybridgesandrouters,andinlargesystemsbytheforwardandreversepathstraversedbyeventmessagestakingdifferentroutesthroughthenetwork.Systemsshouldbeconfiguredandcomponentsselectedtominimizetheseeffectsguidedbytherequiredtimingaccuracy.Insinglesubnetsystemswithdistancesofafewmeters,asymmetryisnotusuallyaconcernfortimeaccuraciesaboveafew10sofns.e）Iftwo-stepclocksareused,thenthenetworkhastobedesignedsuchthatthegeneralmessagetakesthesamepathastheeventmessagethroughatransparentclock.Failuretodothiswillresultinaconditionwherethetransparentclockdoesnotcalculatepathdelayproperly.Thisconditionisundetectableandmayintroduceadditionaljitterandwander,butitwillnotbreaktheprotocol.f）PTPassumesthatthenumberofboundaryclocksformingthemaster-slavesynchronizationhierarchyfromthegrandmasterclocktoanyslaveclockislessthan255;@#@see9.3.2.5.g）Networkcomponents,forexamplebridges,introducetimingjitterandwanderthatifuncorrectedcandegradetimetransferaccuracy.Sincethejitterandwanderareoftentrafficdependent,thenetworktrafficpatternsshouldbedesignedtominimizethetrafficandtominimizethevariationinthetrafficload.ItisalsorecommendedthatPTPeventmessagesbesentinhighprioritycomparedwithotherdata;@#@seeA.5.3.3.WheneverpossiblesuchdevicesshouldbereplacedbyPTPboundaryortransparentclocks.h）Thenetworksprotocolisstructuredsuchthatamessagetimestamppointcanbedefined.6.3PTPsystemsAPTPsystemisadistributed,networkedsystemconsistingofacombinationofPTPandnon-PTPdevices.PTPdevicesincludeordinaryclocks,boundaryclocks,end-to-endtransparentclocks,peer-to-peertransparentclocks,andmanagementnodes.Non-PTPdevicesincludebridges,routers,andotherinfrastructuredevices,andpossiblydevicessuchascomputers,printers,andotherapplicationdevices.Theprotocolisadistributedprotocolthatspecifieshowthereal-timeclocksinthesystemsynchronizewitheachother.Theseclocksareorganizedintoamasterslavesynchronizationhierarchywiththeclockatthetopofthehierarchythegrandmasterclockdeterminingthereferencetimefortheentiresystem.ThesynchronizationisachievedbyexchangingPTPtimingmessages,withtheslavesusingthetiminginformationtoadjusttheirclockstothetimeoftheirmasterinthehierarchy.DevicesinaPTPsystemcommunicatewitheachotherviaacommunicationnetwork.Thenetworkmayincludetranslationdevicesbetweensegmentsimplementingdifferentnetworkcommunicationprotocols.Theprotocolexecuteswithinalogicalscopecalledadomain.Unlessotherwisespecified,allPTPmessages,datasets,statemachines,andallotherPTPentitiesarealwaysassociatedwithaparticulardomain.Agivenphysicalnetworkandindividualdevicesconnectedtothenetworkcanbeassociatedwithmultipledomains.Withinthisstandard,thetimeestablishedwithinonedomainbytheprotocolisindependentofthetimeinotherdomains.6.4PTPmessageclassesTheprotocoldefineseventandgeneralPTPmessages.Eventmessagesaretimedmessagesinthatanaccuratetimestampisgeneratedatbothtransmissionandreceiptasspecifiedin6.6.5.Generalmessagesdonotrequireaccuratetimestamps.Thesetofeventmessagesconsistsof:

@#@a）Sync（see13.6）b）Delay_Req（see13.6）c）Pdelay_Req（see13.9）d）Pdelay_Resp（see13.10）Thesetofgeneralmessagesconsistsof:

@#@Announce（see13.5）Follow_Up（see13.7）Delay_Resp（see13.8）Pdelay_Resp_Follow_Up（see13.11）Management（seeClause15）Signaling（see13.12）TheSync,Delay_Req,Follow_Up,andDelay_Respmessagesareusedtogenerateandcommunicatethetiminginformationneededtosynchronizeordinaryandboundaryclocksusingthedelayrequest-responsemechanism.ThePdelay_Req,Pdelay_Resp,andPdelay_Resp_Follow_Upmessagesareusedtomeasurethelinkdelaybetweentwoclockportsimplementingthepeerdelaymechanism.ThelinkdelayisusedtocorrecttiminginformationinSyncandFollow_Upmessagesinsystemscomposedofpeer-to-peertransparentclocks.OrdinaryandboundaryclocksthatimplementthepeerdelaymechanismcansynchronizeusingthemeasuredlinkdelaysandtheinformationintheSyncandFollow_Upmessages.TheAnnouncemessageisusedtoestablishthesynchronizationhierarchy.ThemanagementmessagesareusedtoqueryandupdatethePTPdatasetsmaintainedbyclocks.ThesemessagesarealsousedtocustomizeaPTPsystemandforinitializationandfaultmanagement.Managementmessagesareusedbetweenmanagementnodesandclocks.Thesignalingmessagesareusedforcommunicationbetweenclocksforallotherpurposes.Forexample,signalingmessagescanbeusedfornegotiationoftherateofunicastmessagesbetweenamasteranditsslaves.Allmessagescanbeextendedbymeansofastandardtype,length,value（TLV）extensionmechanism.Forexample,thePATH_TRACEmessageextensionscanbeusedtodetectrogueframes;@#@see16.2.1formoredetailonrogueframes.6.5PTPdevicetypes6.5.1GeneralTherearefivebasictypesofPTPdevices,asfollows:

@#@a）Ordinaryclockb）Boundaryclockc）End-to-endtransparentclockd）Peer-to-peertransparentclocke）ManagementnodeAllfivetypesimplementoneormoreaspectsoftheprotocol.TwomechanismsareusedinPTPtomeasurethepropagationdelaybetweenPTPports.Thefirstone,thedelayrequest-responsemechanism,usesthemessagesSync,Delay_Req,Delay_Resp,andifrequired,Follow_Up;@#@see11.3.Thesecondone,thepeerdelaymechanism,usesthemessagesPdelay_Req,Pdelay_Resp,andifrequired,Pdelay_Resp_Follow_Up;@#@see11.4.Portsonordinaryandboundaryclockscanbeimplementedusingeithermechanism.Portsonend-to-endtransparentclocksareindependentofthesemechanisms.Portsonpeer-to-peertransparentclocksusethepeerdelaymechanism.Thesetwomechanismsdonotinterworkonthesamecommunicationpath.Inaddition,thepeerdelaymechanismisrestrictedtotopologieswhereeachpeer-to-peerportcommunicatesPTPmessageswithatmostoneothersuchport;@#@see11.4.4.Theuseofthevariousclocktypesislimitedasfollows:

@#@Ordinaryandboundaryclockswithportsimplementingthepeerdelaymechanism,andpeer-topeertransparentclocks,canonlybeconnectedintopologieswhereportsimplementingthepeerdelaymechanismcommunicatePTPmessagestoandfromasingleportalsoimplementingthepeerdelaymechanism;@#@see11.4.4.Exceptincarefullydesignednetworks,thiswillprecludetheuseofend-to-endtransparentclocksandbridgesthatdonotsupportPTPusingthepeerdelaymechanism,e.g.,aconventionalbridge.Ordinaryandboundaryclockportsimplementingthedelayrequest-responsemechanism,andend-to-endtransparentclocks,canbeconnectedinanytopologythatexcludesportsusingthepeerdelaymechanism.Thisprecludestheuseofpeer-to-peertransparentclocksinsuchasystem.Aboundaryclockwithportssupportingeachofthetwomechanismsmaybeusedtobridgebetween