1588-V2中文资料

('1588V2协议基本的时间同步机制1588V2提供了一套时间同步的方案PTP，可以提供亚微秒级的时间同步精度。1588V2时间同步过程分为偏移测量阶段和延迟测量2个阶段。偏移测量阶段用来修正主、从属时钟的时间差。如图1所示,在该偏移修正过程中,主时钟周期性发出一个确定的同步信息(Sync信息)(缺省为1次/1s),它包含了一个时间戳,含有数据包发出的预计时间a,即它是真实发出时间T1的估计值。由于信息包含的是预计的发出时间而不是真实的发出时间,故主时钟在Sync信息发出后发出一个FollowUp信息,该信息也加了一个时间戳,准确地记载了Sync信息的真实发出时间T。这样做的目的是使报文传输和时间测量分开进行,相互不影响。从属时钟使用FollowUp信息中的真实发出时间T1和接收方的真实接收时间T2,可以计算出从属时钟与主时钟之间的偏移OffsetOffset=T2－T1－Delay。延迟测量DelayMeasurement阶段用来测量网络传输造成的延迟时间。为了测量网络传输延时,IEEE1588定义了一个延迟请求信息DelayRequestPacket(DelayReq)。从属时钟在收到Sync信息后在T3时刻发延迟请求信息包DelayReq,主时钟收到DelayReq后在延迟响应信息包DelayRequestPacke（DelayResp）加时间戳,反映出准确的接收时T4,并发送给从属时钟,故从属时钟就可以非常准确地计算出网络延时。与偏移测量阶段不同是,延迟测量阶段的延迟请求信息包是随机发的,并没有时间限制。由于T2－T1=Delay+OffsetT4－T3=Delay－Offset故可得Delay=[T2－T1+T4－T3]/2Offset=[T2－T1－T4＋T3]/2最后根据Offset来修正从时钟。需要提出的是这里假设的是：Delay是双向一致的，且不同信息报文的延时也是一样的。本文中的所有信息归中兴通讯股份有限公司所有第1/24页图11588时间同步过程。消息分类PTP协议定义了2种消息：事件消息和通用消息。事件消息需要在发送和接收的时候打上精确的时间戳。而通用消息不需要。事件消息包括：\uf06cSync\uf06cDelay_Req\uf06cPdelay_Req\uf06cPdelay_Resp通用消息包括\uf06cAnnounce\uf06cFollow_Up\uf06cDelay_Resp\uf06cPdelay_Resp_Follow_Up\uf06cManagement\uf06cSignalingSync,Delay_Req,Follow_Up,Delay_Resp.消息是用来产生和交互时间信息的，这些信息用来同步时间的。Pdelay_Req,Pdelay_Resp,Pdelay_Resp_Follow_Up用来测量link延时。Announce消息用来建立同步层次。Management消息用来查询和设置PTP时钟的时钟数据。Signaling消息是用来PTP时钟之间进行交互（如协商消息的周期等）所有消息均使用TLV格式以利于扩展。本文中的所有信息归中兴通讯股份有限公司所有第2/24页PTP实体类型有5种PTP实体：\uf06c普通时钟（Ordinaryclock），\uf06c边界时钟（Boundaryclock），\uf06cE2E透传时钟（End-to-endtransparentclock），\uf06cP2P透传时钟（Peer-to-peertransparentclock），\uf06c管理节点。普通时钟普通时钟只有一个PTP物理通信端口和网络相连，一个物理端口包括2个逻辑接口，事件接口（eventinterface）和通用接口（generalinterface）。事件接口接收和发送需要打时间标签的事件消息。通用接口接收和发送其他消息。一个普通时钟只有一个PTP协议处理器。在网络中，普通时钟可以作为祖父时钟（grandmasterclock）或从时钟（slaveclock）。当作为祖父时钟是，其PTP端口处于主状态（master），作为从时钟时其PTP端口处于从状态（slave），普通时钟的框图如下：框图中的协议引擎主要完成：\uf06c发送和接收协议消息。\uf06c维护时钟和端口数据本文中的所有信息归中兴通讯股份有限公司所有第3/24页\uf06c执行PTP状态机的处理功能。\uf06c如果普通时钟是作为从时钟，则根据PTP协议计算父时钟的时间。一个普通时钟维护两套数据：时钟相关的数据和端口相关的数据时钟相关的数据有：\uf06cDefault数据：用于描述普通时钟的属性。\uf06cCurrent数据：用于描述同步相关的属性。\uf06c父时钟和祖父时钟数据：用于描述父时钟和祖父时钟的属性。\uf06c时间特性：用于描述时标的属性。端口相关的数据包括端口的属性以及PTP状态的数据。当普通时钟的端口是从状态时，时钟控制环路用来控制本地时钟和父时钟同步。当普通时钟作为祖父时钟时，本地时钟要么自由振荡要么同步于外部的时钟源（如GPS等）。边界时钟边界时钟有多个PTP物理通信端口和网络相连，每个物理端口包括2个逻辑接口，事件接口和通用接口。边界时钟的每个PTP端口和普通时钟的PTP端口一样，除了以下几点：\uf06c边界时钟的所有端口共同使用一套时钟数据。\uf06c边界时钟的所有端口共同使用一个本地时钟。\uf06c每个端口的协议引擎增加一个功能：从所有端口中选择一个端口作为本地时钟的同步输入。协议引擎将总结和同步相关（包括建立时钟同步层次）的消息和信令。但可以转发管理消息。边界时钟的框图如下：本文中的所有信息归中兴通讯股份有限公司所有第4/24页E2E透传时钟E2E透传时钟像路由器或交换机一样转发所有的PTP消息，但对于事件消息，有一个停留时间桥计算该消息报文在本点停留的时间（消息报文穿过本点所花的时间），停留时间将累加到消息报文中的“修正”（correctionfield）字段中。修正过程如下图：本文中的所有信息归中兴通讯股份有限公司所有第5/24页E2E透传时钟的框图如下：用于计算停留时间的时间戳是由本地时钟产生的，所以本地时钟和时间源的时钟之间的频率差会造成误差。最好是本地时钟去锁定时钟源时钟。如果本地时钟锁定的不是时间源时钟则要求其精度能到达一定标准,以本地时钟是三级钟为例，1ms的停留时间大约造成5ns的误差。E2E透传时钟可以和普通时钟合在一起作为一个网络单元，其框图如下：本文中的所有信息归中兴通讯股份有限公司所有第6/24页在上图中，如果普通时钟是从时钟，停留时间桥将接收到的时间消息，宣称消息，由输入的时钟同步消息产生的时间戳以及内部的停留时间传送给协议引擎，协议信息根据这些信息计算出正确的时间并以此控制本地时钟。如果普通时钟是主时钟，协议引擎将产生Sync和Followup消息，消息中发送时间戳由本地时钟基于内部停留时间和输出时间戳产生（itwouldoriginateSyncandFollow_Upmessageswiththesendingtimestampsreferencedtothelocalclockoftheordinaryclockandbasedoninternaltimingcorrectionsandtheegresstimestamp.）在实现中，透传时钟和普通时钟使用同一个本地时钟。P2P透传时钟P2P透传时钟和E2E透传时钟只是对PTP时间消息的修正和处理方法不同，在其他方面是完全一样的。P2P透传时钟可以和E2E透传时钟一样与普通时钟合在一起作为一个网络单元。P2P透传时钟的框图如下：本文中的所有信息归中兴通讯股份有限公司所有第7/24页P2P透传时钟对每个端口有一个模块用来测量该端口和对端端口的link延时，对端端口也必须支持P2P模式。link的延时通过交换Pdelay_Req,Pdelay_Resp以及可能的Pdelay_Resp_Follow_Up消息测量出。P2P透传时钟仅仅修正和转发Sync和Followup消息。本地的停留时间和收到消息的端口的link延时均记入修正。修正过程如下图：本文中的所有信息归中兴通讯股份有限公司所有第8/24页因为P2P的修正包括了link延时和停留时间，其修正域反映了整个路径的延时，从时钟可以根据Sync消息计算出正确的时间，而不需要再发Delay测量消息。再发生时钟路径倒换的时候，P2P方式基本不受影响，而E2E方式则需要在进行过新的延时测量之后，才能计算出正确的时间。管理节点管理节点向人或程序提供PTP管理消息的接口，管理节点可以和任意时钟合在一起。建立时钟同步层次在每个时钟域，普通时钟和边界时钟的每个端口都运行一个PTP协议状态机，该状态机根据设置和宣称（Announce）消息决定本端口的状态。Slave-only时钟和Non-Slave-only时钟一个普通时钟可以通过管理平面设置为Slave-only时钟或Non-Slave-only时钟，如果设置成Slave-only时钟，则该时钟不能进入主用模式。边界时钟只能是Non-Slave-only时钟。端口的状态普通时钟和边界时钟的每个端口正常工作时可以处于以下3个状态中的一个：本文中的所有信息归中兴通讯股份有限公司所有第9/24页\uf06cMaster：表明本端口是一条时钟路径的源。\uf06cSlave：表明本端口同步与一个Master时钟。\uf06cPassive：表明本端口即不是Master，也不是Slave。该状态主要用于防止时钟成环。处于该状态的端口除了Pdelay_Req,Pdelay_Resp,Pdelay_Resp_Follow_Up消息和信令以及必须响应的管理消息外不发送任何PTP消息。其他状态还包括：\uf06c初始化（INITIALIZING）：表示该端口正在初始化数据，硬件或通讯口。一个时钟如果一个端口处于初始化状态，其他所有端口都应处于初始化状态。在初始化状态端口不发送和接收任何PTP消息。\uf06c故障（FAULTY）：表示端口有故障。处于故障状态的端口除了必须响应的管理信息不发送和接收任何PTP消息。故障端口的动作不应影响其他端口。如果故障不能限制在故障端口内，则该时钟的所有端口应均为故障状态。\uf06c不可用（DISABLED）：表示端口不可使用（例如网管禁止）。处于不可用状态的端口不能发送任何PTP消息，除了必须管理信息也接收任何PTP消息。不可用端口的动作不应影响其他端口。\uf06c侦听（LISTENING）：表示端口正在等待接收Announce消息。该状态用于将时钟加入到时钟域时。处于侦听状态的端口除了Pdelay_Req,Pdelay_Resp,Pdelay_Resp_Follow_Up消息和其他必须响应的管理消息和信令外不发送其他PTP消息。\uf06c预主用（PRE_MASTER）：处于这个状态的端口的行为和主用端口一样，但是它除了Pdelay_Req,Pdelay_Resp,Pdelay_Resp_Follow_Up消息和管理消息和信令外不发送其他PTP消息。\uf06c未校准（UNCALIBRATED）：表明域内发现一个和多个Master端口，本地时钟已经从中选择一个并准备跟踪。该状态是一个过渡状态，用于进行跟踪前的预处理。状态转移图Non-slave-only时钟的端口的状态转移图如下：本文中的所有信息归中兴通讯股份有限公司所有第10/24页本文中的所有信息归中兴通讯股份有限公司所有第11/24页Slave-only时钟的端口的状态转移图如下：状态转移图中的STATE_DECISION_EVENT一种根据Announce消息和本地时钟配置决定哪个是最好的主用时钟（BestMasterClock（BMC））并决定端口的状态。每个时钟应实现产生该事件的机制，如当接收到新的Announce消息或新的时钟配置或检测到故障等，应产生该事件，当该事件发生时，将会调用BMC算法，逻辑框图如下：本文中的所有信息归中兴通讯股份有限公司所有第12/24页最佳主时钟算法BMC算法主要包括2部分：\uf06c数据比较算法：比较两个时钟以决定哪个更好。\uf06c状态决定算法：计算端口应该处于的状态。BMC使用的数据主要包括Announce消息和本地时钟的配置信息。本文中的所有信息归中兴通讯股份有限公司所有第13/24页状态决定算法对于一个时钟的端口r，要根据本端口的收到的Announce消息，从和本端口相连Master时钟中挑出一个最好的，记为Erbest。然后时钟从所有端口的Erbest时钟中挑出一个最好的，记为Ebest。然后再加上本地时钟的配置D0。端口根据本端口的Erbest和Ebest和D0确定端口应该的状态，具体流程如下：本文中的所有信息归中兴通讯股份有限公司所有第14/24页数据比较算法数据比较算法用来比较两个时钟以决定哪个更好。其用到的数据有：数据比较算法的流程图如下：本文中的所有信息归中兴通讯股份有限公司所有第15/24页本文中的所有信息归中兴通讯股份有限公司所有第16/24页本文中的所有信息归中兴通讯股份有限公司所有第17/24页管理消息管理消息的接收当下列2个条件中的一个满足时，一个管理消息将被接受。1）当消息中的targetPortIdentity域中的clockIdentity和本点配置的clock_identity一致时。如果portNumber域为0，则该命令对所有端口生效。否则该命令只对指定端口生效。2）当消息中targetPortIdentity域中的所有字段均为0，说明是广播命令。管理消息在边界时钟的转发边界时钟应该将收到的广播消息向其他端口转发，转发规则如下：\uf06c只有从处于MASTER,SLAVE,UNCALIBRATED,和PRE_MASTER状态下的端口接收到的广播包才被转发。\uf06c如果boundaryHops域值为0，则不转发该包。否则减一后转发。\uf06c只向处于转发MASTER,SLAVE,UNCALIBRATED,和PRE_MASTER状态下的端口转发。可选功能通用可选功能\uf06c单播消息协商。\uf06c通道追踪\uf06c预备的时标。状态可选功能\uf06cMasterclusters\uf06cAlternatemaster\uf06cUnicastdiscovery\uf06cAcceptablemastertable本文中的所有信息归中兴通讯股份有限公司所有第18/24页时钟同步一个设备如果由一个端口是Slave状态，可以利用Sync消息来进行时钟同步。\uf06c记录接收到Sync消息的时钟标签\uf06c计算correctedmaster-event-timestamp。公式为：=+\uf06c计算调整因子\uf06c根据调整因子去调整本地时钟。PTP组网层次模型层次模型的示意图如下：层次模型是一个树状结构，在每个分叉点设置一个边界时钟。该模型适合于星形，树形，MESH组网，其优点是层次清楚且时钟传送路径比较短。本文中的所有信息归中兴通讯股份有限公司所有第19/24页线型模型线型模型的示意图如下：有时网络的拓扑是比较长的线型结构，这时如果使用边界时钟组网，随着长度的增加，级联的锁相环会造成相位误差的积累。这时使用透传时钟模式会比较好。这种方法的缺点是主时钟要响应很多从时钟的延时测量请求，网络比较大时，对主时钟的资源消耗比较大。快速多路由模型快速多路由模型如下图：本文中的所有信息归中兴通讯股份有限公司所有第20/24页但需要同步的时钟由一个MESH的通信网络连接，这时使用P2P透传时钟可以实现快速的重路由。实现方面的考虑PTP组网采用什么设备，用什么方式组网，需要考虑很多方面：客户层和传送层的时钟需求客户层和传送层是否使用同一个时钟\uf06c如果客户层和服务层使用同一个时钟源，则可以使用边界时钟或透传时钟组网。\uf06c如果客户层和服务层使用不同的时钟源或需要传送多个客户时钟，则对于服务层时钟的传送可以使用边界时钟或透传时钟组网，而对于客户层时钟只能采用透传时钟组网。这时应要求传送层和客户层的时钟偏差不能太大。对于透传客户层时钟，是否可以把传送网当作一个站点？即进传送网时，打进入时间戳，出传送网时打输出时间戳，并计算修正项。本文中的所有信息归中兴通讯股份有限公司所有第21/24页网络拓扑\uf06c对于星形或MESH组网，使用边界时钟和P2P透传时钟比较好。\uf06c对于站点数比较多的链或环形组网，使用E2E或P2P透传时钟比较好，如果能够保证精度，边界时钟也可以。通信类型1588V2协议是按照广播型网络设计的，虽然可以支持单播网络，但对于透传时钟实现比较麻烦，而且客户层的实现很有可能是广播型的。\uf06c如果是广播型网络，使用透传时钟或边界时钟都可以。值得提出的是，对于Pdelay_Req,Pdelay_Resp,Pdelay_Resp_Follow_Up等消息虽然可以是单播的，但是为了保证延时测量尽量的和Sync等广播消息一样，最好是也采用广播发送。（在有修正项的情况下，为什么单播和广播的测量延时不一样？）但是当网络规模比较大得时候，如果采用E2E时钟，因为每个从时钟都要广播延时测量消息，会消耗大量得网络带宽。使用边界时钟和P2P时钟可以有效得减少通信量。\uf06c如果是单播型网络，使用边界时钟最好，因为边界时钟会终结所有得PTP消息，如果所有设备都是边界时钟，则意味着所有消息都将是点对点的，这对于单播的网络最好实现。而对于透传时钟，将需要为每个主时钟和每个从时钟建立连接，而且要提供足够的保护，这就相当于提供了一个ELan的业务。\uf06c在单播网络中是否可以采用类似管理消息的转发方式来实现广播？通信方式1588V2定义了PTP在如下协议中传送的地址和格式本文中的所有信息归中兴通讯股份有限公司所有第22/24页推荐实现方式将客户层的时间同步和传送层的时间同步分开。\uf06c对于客户层的时间同步。传送层全部采用透传时钟，这样传送设备只用负责打时间戳和计算修正项（P2P透传时钟需要计算link延时），而不用参与处理客户层的时钟协议。这个功能甚至只用在接口实现，而不用时钟板的参与。如果能在进传送网时打输入时间戳，而在出传送网时打输出时间戳并计算修正项，则只需要边界端口处理即可。但这要求传送网可以提供ELan业务（对PBT没问题，但对TMPLS可能比较复杂）\uf06c对于传送层的时间同步。它和客户层独立，可以使用任何方便的方式。这样做的好处是：\uf06c传送和客户独立互不影响。除了link延时测量外不用和客户互通任何协议。大大的增加了组网的灵活性。\uf06c在传送层不需要时间同步的时候（个人认为这是大多数情况），传送层可以不启动1588协议，这样即减少了网络中的流量，又简化了网络设计的难度。send(26):0180C200000200D0D0C000B088090A00send(26):19A700011000000001000404020004E0send(26):00000000000000000000000000000000send(26):00000000000000000000000000000000Table10-6-2:ESMCPDUformatOctetnumberSizeField1-66octetsDestinationAddress=01-80-C2-00-00-02(hex)7-126octetsSourceAddress13-142octetsSlowProtocolEthertype=88-09(hex)151octetsSlowProtocolSubtype=0A(hex)16-183octetsITU-OUI=00-19-A7(hex)19-202octetsITUSubtype4bitsVersion1bitEventflag213bitsReserved22-243octetsReserved25-153236-1490octetsDataandPadding(SeepointJ)Last44octetsFCS本文中的所有信息归中兴通讯股份有限公司所有第23/24页11.4ESMCPDUextensionsFutureextensionstotheESMCPDUareforfurtherstudy.However,itisexpectedthatfutureextensionswillbespecifiedintermsofaTLVformat.TheTLVformatisindicatedinTable10-6-1.ThesizeoftheTLViscalculatedasthetotalnumberofoctetsintheTLVstructure.Thelengthincludesthetypeandlengthfields.PaddingofdataisrequiredtoensurethattheTLVcontainsanintegralnumberofoctets.Note:twobytesareusedtorepresentthelengthfield.ThesuggestedmaximumsizeofaSlowProtocolPDUis128BytesasperIEEE802.3-2005Clause43B.However,slowprotocolPDUlengthsgreaterthan128bytesarepermissible.Detailsofusageareforfurtherstudy.Table10-6-1TLVstructure1byteType2bytesLength(Octets)NbytesDatapluspaddingOrganizationalUniqueIdentifier3.1.19one-stepclock:Aone-stepPTPordinaryorboundaryclockaccuratelysetstheoriginTimestampandcorrectionfieldsoftheeventmessagesthatittransmits.Aone-stepPTPtransparentclockaccuratelyupdatesthecorrectionfieldoftheeventmessagesthatitforwards.Seetwo-stepclock.3.1.40two-step-clock:Atwo-stepPTPordinaryorboundaryclockdoesnotaccuratelysettheoriginTimestampandcorrectionfieldsoftheeventmessagesthatittransmits.Atwo-stepPTPtransparentclockdoesnotupdatethecorrectionfieldoftheeventmessagesthatitforwards.Theaccurateinformationistransmittedinasubsequentgeneralmessage.Seeone-step.本文中的所有信息归中兴通讯股份有限公司所有第24/24页',)