| Header | Body | Suffix |
|---|
| 34 字节 | Variable length | Optional |
所有的 PTP 帧都包含一个公共报头，它决定了协议版本和消息类型，还定义了消息的剩余内容。
所有多字节字段以大端顺序发送（高位字节首先发送/接收）。
versionPTP 的最后四位位于 PTPv1 和 PTPv2 数据头的相同位置（第二个字节）。这允许通过检查消息的前两个字节进行准确的识别。
PTP 报文头
PTPv1
| Offset | Octets | Name |
|---|
| 0 | 2 | versionPTP = 0x0001 |
| 2 | 2 | versionNetwork |
| 4 | 16 | subdomain |
| 20 | 1 | messageType |
| 21 | 1 | sourceCommunicationTechnology |
| 22 | 6 | sourceUuid |
| 28 | 2 | sourcePortId |
| 30 | 2 | sequenceId |
| 32 | 1 | control |
| 33 | 1 | 0x00 |
| 34 | 2 | flags |
| 36 | 4 | reserved |
消息的类型编码在 messageType 和 control 字段中，如表中所示：
| messageType | control | Message Name | Message |
|---|
| 0x01 | 0x0 | SYNC | Event message |
| 0x01 | 0x1 | DELAY_REQ | Event message |
| 0x02 | 0x2 | FOLLOW_UP | General message |
| 0x02 | 0x3 | DELAY_RESP | General message |
| 0x02 | 0x4 | MANAGEMENT | General message |
| other | other | — | Reserved |
字段 sequenceId 用于明确地标识消息。
PTPv2
| 偏移 | 字节数 | 字段名称 | 含义 |
|---|
| 0 | 1 | transportSpecific(bit7-4)
messageId(bit3-0) | |
| 1 | 1 | reserved(bit7-4)
versionPTP = 0x2(bit3-0) | 表示 1588 协议的版本 |
| 2 | 2 | messageLength | PTP 消息的长度，即 PTP 消息的全部字节数目。
计入字节始于报头的第一个字节，同时包含并收
尾于任何尾标的最后一个字节，或是无尾标成员
时收尾于消息的最后一个字节 |
| 4 | 1 | domainNumber | 域编号，表示发送该消息时钟所属的域 |
| 5 | 1 | reserved | |
| 6 | 2 | flags | |
| 8 | 8 | correctionField | 修正域，各报文都有，主要用在 Sync 报文中，
用于补偿网络中的传输时延，E2E 的频率同步 |
| 16 | 4 | reserved | |
| 20 | 10 | sourcePortIdentity | 源端口标识符，发送该消息时钟的 ID 和端口号 |
| 30 | 2 | sequenceId | 序列号 ID，表示消息的序列号，以及关联消息
的对应关系 |
| 32 | 1 | control | 控制域（IEEE 1588v1），由消息类型决定：
- 0x00：Sync
- 0x01：Delay_Req
- 0x02：Follow_Up
- 0x03：Delay_Resp
- 0x04：Management
- 0x05：All others
- 0x06-0xFF：reserved |
| 33 | 1 | logMeanMessageInterval | 录入消息周期，PTP 消息的发送时间间隔，
由消息类型决定 |
在使用 UDP/IP 协议封装时：
| transportSpecific | 含义 |
|---|
| 0 | UDP/IPv6 封装时，接收者忽略这个域 |
| 1 | UDP/IPv4 封装时，这个域为 1，表示接收者需要将 PTP 事件消息的 UDP 负载填充到 124 字节 |
在使用以太网封装时：
| transportSpecific | 含义 |
|---|
| 0 | 表示PTP消息由1588协议使用 |
| 1 | 表示PTP消息由802.1as协议使用 |
消息的类型在 messageId 字段中编码，如下表：
| messageId | Message name | Message |
|---|
| 0x0 | SYNC | Event message（进出设备端口时需要打上精确的时间戳） |
| 0x1 | DELAY_REQ | Event message |
| 0x2 | PATH_DELAY_REQ | Event message |
| 0x3 | PATH_DELAY_RESP | Event message |
| 0x4– 0x7 | — | Reserved |
| 0x8 | FOLLOW_UP | General message（进出设备不会产生时戳） |
| 0x9 | DELAY_RESP | General message |
| 0xA | PATH_DELAY_FOLLOW_UP | General message |
| 0xB | ANNOUNCE | General message |
| 0xC | SIGNALING | General message |
| 0xD | MANAGEMENT | General message |
| 0xE– 0xF | — | Reserved |
PTPv2 flags 字段包含关于消息类型的进一步详细信息，尤其在使用一步或两步实现的情况下。一布或两步的实现由 flags 字段的前八位中的 TWO_STEP 位控制，如下所示。
保留位被清除。
| 字节 | 位 | 消息类型 | 消息名 | 描述 |
|---|
| 0 | 0 | Announce, Sync,
Follow_Up, Delay_Resp | ALTERNATE_MASTER | See IEEE 1588 Clause 17.4 |
| 0 | 1 | Sync, Pdelay_Resp | TWO_STEP | 1 Two-step clock
0 One-step clock |
| 0 | 2 | ALL | UNICAST | 1 Transport layer address uses a
unicast destination address
0 Multicast is used |
| 0 | 3 | ALL | — | Reserved |
| 0 | 4 | ALL | — | Reserved |
| 0 | 5 | ALL | Profile specific | |
| 0 | 6 | ALL | Profile specific | |
| 0 | 7 | ALL | — | Reserved |
| 1 | 0 | Announce | leap61 | - |
| 1 | 1 | Announce | leap59 | - |
| 1 | 2 | Announce | currentUtcOffsetValid | - |
| 1 | 3 | Announce | ptpTimescale | - |
| 1 | 4 | Announce | timeTraceable | - |
| 1 | 5 | Announce | frequencyTraceable | - |
PTP 报文类型
- Sync 报文
- Delay_Req 报文
- Pdelay_Req Message 报文
- Pdelay_Resp Message 报文
- Follow_Up 报文
- Delay_Resp 报文
- Pdelay_Resp_Follow_Up 报文
- Announce 报文
Sync 报文
该报文由 Master 时钟发送，带有 Master 的时间信息。如果 Master 是 Two_step 模式的时钟，其发送的 Sync 报文中的时间戳将被设置为 0，实际的时间戳将由和该 Sync 报文相关联的 Follow_up 报文发送。
| Offset | Octets | Name |
|---|
| 0 | 34 | PTP Header |
| 34 | 10 | Origin Timestamp |
Delay_Req 报文
Delay_Req 报文的内容格式与 Sync 报文完全相同，Delay_Req 报文由从时钟发出，类似于 Master 有 One_Step 及 Two_Step 2 种时钟模式。Slave 存在 One_Way 和 Two_way 2 种模式（单向和双向），在 One_Way 模式下，Slave 不需要发送 Delay_Req 报文。
| Offset | Octets | Name |
|---|
| 0 | 34 | PTP Header |
| 34 | 10 | Origin Timestamp |
Pdelay_Req Message 报文
该报文仅在 P2P TC 时钟模式下才产生，由 P2P 时钟作为“延迟请求者”发出。
| Offset | Octets | Name |
|---|
| 0 | 34 | PTP Header |
| 34 | 10 | Origin Timestamp |
| 44 | 10 | Reserved |
Pdelay_Resp Message 报文
该报文仅在 P2P TC 时钟模式下才产生，由 P2P 时钟作为“延迟响应者”发出。
如果 P2P 时钟模式是 Two_Step，Pdelay_Resp Message 报文的时间戳将被设置为 0，实际的时间戳将由该报文相关联的 Pdelay_Resq_Follow_Up 报文发送。
| 偏移 | 字节数 | 名称 | 描述 |
|---|
| 0 | 34 | PTP Header | |
| 34 | 10 | receiveReceipt Timestamp | 在 One_Step 模式下的数值为 0；在 Two_Step 模式下为响应 Pdelay_Req 报文的接收时间戳，精度为 ns 以上的精确时间戳 |
| 44 | 10 | requestingPortIdentity | 响应 Pdelay_Req 报文的发送设备端口 ID |
Follow_Up 报文
只有在主时钟是 Two_Step 时钟模式时，才会发送 Follow_UP 报文，其内容格式与 Sync 和 Delay_Req 报文相同。
| Offset | Octets | Name |
|---|
| 0 | 34 | PTP Header |
| 34 | 10 | preciseOrigin Timestamp |
Delay_Resp 报文
当 Master 收到 Slave 发出的 Delay_Req 报文时，会响应 Delay_Resq 报文。
| 偏移 | 字节数 | 名称 | 描述 |
|---|
| 0 | 34 | PTP Header | |
| 34 | 10 | receive Timestamp | 响应 Delay_Req 报文的接收时间戳，精度为 ns 级 |
| 44 | 10 | requestingPortIdentity | 响应 Delay_Req 报文的发送设备端口 ID。 |
Pdelay_Resp_Follow_Up 报文
只有在 P2P 时钟模式是 Two_Step 时才会产生 Pdelay_Resp_Follow_Up 报文。
| 偏移 | 字节数 | 名称 | 描述 |
|---|
| 0 | 34 | PTP Header | |
| 34 | 10 | responseOrigin Timestamp | 在 Two_Step 模式下响应 Pdelay_Resq 报文的发送时间戳，精度为 ns 级以上 |
| 44 | 10 | requestingPortIdentity | 响应 Pdelay_Resq 报文的发送设备端口 ID。 |
Announce 报文
该报文用来描述时间源能力。
| 偏移 | 字节数 | 名称 | 描述 |
|---|
| 0 | 34 | PTP Header | PTP 报文头 |
| 34 | 10 | Origin Timestamp | 数值为 0 或精度为 ±1 ns 的时间戳 |
| 44 | 2 | CurrentUtcOffset | UTC 与 TAI 时间标尺间的闰秒时间差 |
| 46 | 1 | Reserved | - |
| 47 | 1 | GrandmasterPriority1 | 用户定义的 grandmaster 优先级 |
| 48 | 4 | GrandmasterClockQuality | grandmaster 的时间质量级别 |
| 52 | 1 | GrandmasterPriority2 | |
| 53 | 8 | GrandmasterIdentity | grandmaster 的时钟设备 ID |
| 61 | 2 | StepRemoved | grandmaster 与 Slave 设备间的时钟路径跳数 |
| 63 | 1 | TimeSource | 时间源头类型：
GPS - GPS 卫星传送时钟
PTP - PTP 时钟
NTF - NTP 时钟
Hand_set - 人工调整校准时钟 |
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
