No protocolo PTP (Precision Time Protocol), as mensagens atuam como transportadores de informações cruciais para a sincronização de tempo. Cada tipo de mensagem tem um propósito específico e uma estrutura definida. Esta análise explora os dez formatos de mensagem do PTP, detalhando seus campos e utilizações.
Classificação das Mensagens PTP
Mensagens de Evento
Essas mensagens requerem carimbos de tempo (timestamps) de alta precisão, frequentemente processadas por hardware para garantir exatidão. Incluem:
- Sync: Transmite informações temporais do mestre.
- Delay_Req: Solicita medição de atraso unidirecional.
- Pdelay_Req: Inicia medição de atraso entre pares.
- Pdelay_Resp: Responde a solicitações de medição entre pares.
Os carimbos de tempo são essenciais para calcular atrasos e assimetrias na rede.
Mensagens Gerais
Não necessitam de carimbos de tempo precisos, transportando configurações e estados. São tratadas por software e incluem:
- Follow_Up: Fornece timestamp exato no modo two-step.
- Delay_Resp: Responde a solicitações de atraso.
- Pdelay_Resp_Follow_Up: Carrega timestamp preciso para medição entre pares.
- Announce: Anuncia informações do relógio mestre.
- Signaling: Utilizada para sinalização, como negociação unicast.
- Management: Permite configuração e diagnóstico de dispositivos.
Cabeçalho Comum das Mensagens
Todas as mensagens PTP começam com um cabeçalho de 34 bytes, que contém metadados essenciais:
| Campo | Tamanho (bytes) | Descrição |
|---|---|---|
| majorSdoId + messageType | 1 | Bits altos: identificador de domínio; bits baixos: tipo de mensagem. |
| minorVersionPTP + versionPTP | 1 | Versão secundária e principal do PTP. |
| messageLength | 2 | Comprimento total da mensagem em bytes. |
| domainNumber | 1 | Número do domínio PTP. |
| minorSdoId | 1 | Parte baixa do identificador de domínio. |
| flagField | 2 | Campo de flags para indicar estados especiais. |
| correctionField | 8 | Valor de correção em unidades de 2⁻¹⁶ nanossegundos. |
| messageTypeSpecific | 4 | Reservado para uso específico do tipo de mensagem. |
| sourcePortIdentity | 10 | Identidade da porta de origem (8 bytes clockIdentity + 2 bytes portNumber). |
| sequenceId | 2 | Número de sequência para correlacionar mensagens. |
| controlField | 1 | Obsoleto, geralmente definido como zero. |
| logMessageInterval | 1 | Logaritmo do intervalo de transmissão. |
Detalhes de Campos Chave
Campo messageType
Os 4 bits inferiores identificam o tipo de mensagem:
- 0x0: Sync
- 0x1: Delay_Req
- 0x2: Pdelay_Req
- 0x3: Pdelay_Resp
- 0x8: Follow_Up
- 0x9: Delay_Resp
- 0xA: Pdelay_Resp_Follow_Up
- 0xB: Announce
- 0xC: Signaling
- 0xD: Management
Campo flagField
Um campo de 16 bits com flags importantes, como:
- twoStepFlag: Indica modo two-step quando verdadeiro.
- unicastFlag: Sinaliza transmissão unicast.
- leap61 e leap59: Ajustes de segundo bissexto.
- ptpTimescale: Especifica uso da escala de tempo PTP.
Campo correctionField
Armazena correções em frações de nanossegundos. A unidade é 2⁻¹⁶ ns (aproximadamente 0.01526 ps). Por exemplo:
correctionField = 0x0000000000028000 (decimal: 163840)
Valor = 163840 / 65536 = 2.5 nanossegundos
Utilizado para acumular tempo de residência em relógios transparentes ou corrigir assimetrias.
Análise de Formatos de Mensagem Específicos
Mensagem Sync
Carrega o timestamp de origem do mestre. No modo one-step, inclui segundos inteiros no campo originTimestamp e nanossegundos fracionários no correctionField. No modo two-step, o timestamp preciso é enviado via Follow_Up.
| Campo | Tamanho (bytes) | Descrição |
|---|---|---|
| Cabeçalho comum | 34 | Cabeçalho padrão. |
| originTimestamp | 10 | Timestamp de envio (6 bytes segundos + 4 bytes nanossegundos). |
Mensagem Follow_Up
Fornece o timestamp preciso de envio de uma mensagem Sync anterior, correlacionada pelo sequenceId. Estrutura semelhante à Sync, mas com campo preciseOriginTimestamp.
Mensagem Delay_Req e Delay_Resp
Utilizadas para medir atraso unidirecional (E2E). Delay_Req é enviada pelo escravo, e Delay_Resp pelo mestre com o timestamp de recepção. Incluem campos reservados para manter comprimento consistente com mesnagens Pdelay.
| Mensagem | Campos Adicionais |
|---|---|
| Delay_Req | originTimestamp (geralmente zero) + 10 bytes reservados. |
| Delay_Resp | receiveTimestamp + requestingPortIdentity (identifica o solicitante). |
Mensagens Pdelay_Req, Pddelay_Resp e Pdelay_Resp_Follow_Up
Para medição de atraso entre pares (P2P). Pdelay_Req inicia a medição, Pdelay_Resp carrega o timestamp de recepção, e Pdelay_Resp_Follow_Up fornece o timestamp de envio da resposta. Permitem calcular atrasos de link de forma precisa.
Mensagem Announce
Transmite atributos do relógio mestre para o processo de seleção (BMCA). Inclui informações como grandmasterPriority, clockQuality e stepsRemoved. Estrutura:
| Campo | Tamanho (bytes) | Exemplo |
|---|---|---|
| originTimestamp | 10 | Timestamp de envio. |
| currentUtcOffset | 2 | Deslocamento UTC atual. |
| grandmasterPriority1 | 1 | Prioridade primária. |
| grandmasterClockQuality | 4 | Inclui clockClass e clockAccuracy. |
| grandmasterIdentity | 8 | Identidade única do relógio. |
| stepsRemoved | 2 | Número de saltos até o grandmaster. |
Mensagens Signaling e Management
Signaling suporta funcionalidades estenddias via TLVs (Type-Length-Value), como negociação unicast. Management permite configuração e consulta de dispositivos, com campos como actionField (GET, SET, RESPONSE, etc.) e TLVs específicos.
Exemplo de Mensagem em Hexadecimal
Considere uma mensagem Sync simplificada:
// Cabeçalho comum (34 bytes)
00 00 00 2C // messageType=0x0 (Sync), comprimento=44
00 00 00 00 // domainNumber=0, minorSdoId=0
00 00 // flagField=0
00 00 00 00 00 00 00 00 // correctionField=0
00 00 00 00 // messageTypeSpecific=0
00 1B 19 00 00 00 00 01 00 01 // sourcePortIdentity (clockIdentity=00-1B-19-00-00-00-00-01, portNumber=1)
00 64 // sequenceId=100
00 00 // controlField=0, logMessageInterval=0
// Timestamp de origem
00 00 00 00 00 00 03 E8 // segundos=1000
00 00 00 00 // nanossegundos=0
Isso representa uma mensagem Sync enviada no tempo 1000.000000000 segundos, com identificação de porta e sequência específicas.
Considerações Finais sobre Formatos
O comprimento padrão das mensagens varia: Sync e Follow_Up têm 44 bytes, mensagens de atraso (Delay_Req, Pdelay_Req, etc.) têm 54 bytes, e Announce tem 64 bytes. O uso de TLVs permite extensões flexíveis, como autenticação ou rastreamento de caminho. A estrutura fixa do cabeçalho garante interoperabilidade, enquanto campos como sequenceId e sourcePortIdentity facilitam o gerenciamento de diálogos entre dispositivos.