RFC 10030: Protocolo de Tempo de Rede (NTP) sobre o Protocolo de Tempo Preciso (PTP)

Resumo

Este documento especifica um transporte para os modos cliente-servidor e simétrico do Protocolo de Tempo de Rede (NTP) que encapsula mensagens NTP em mensagens do Protocolo de Tempo Preciso (PTP). Este transporte permite o carimbamento de tempo de hardware em controladores de interface de rede (NICs) que só podem carimbar mensagens PTP e correções de atraso em relógios transparentes PTP.¶

1. Introdução

Protocolo de Tempo Preciso (PTP)[IEEE1588–2019]Foi projetado para sincronização altamente precisa de relógios em redes locais. Ele depende do suporte de carimbo de tempo de hardware em todos os dispositivos de rede envolvidos na sincronização (por exemplo, controladores de interface de rede (NICs), switches e roteadores) para eliminar o impacto de atrasos de software, processamento e fila na precisão das medições de deslocamento e atraso.¶

O PTP foi originalmente projetado para comunicação multicast. Posteriormente, foi adicionada a suporte para mensagens unicast, o que é útil em redes maiores com suporte parcial de PTP no caminho (por exemplo, perfis de telecomunicações).G.8265.1 [G8265-1]eG.8275.2 [G8275-2]).¶

O Protocolo de Tempo da Rede (NTP)[RFC5905]não depende¶

Um problema para o NTP é o hardware que pode carimbar especificamente apenas pacotes PTP. Esta limitação vem de um design de hardware que pode fornecer carimbos de tempo de recebimento apenas em uma taxa limitada, em vez da taxa máxima possível na velocidade do link de rede. Para evitar a perda de carimbos de tempo de recebimento quando a interface está recebendo outro tráfego em alta taxa, um filtro é implementado no hardware para inspecionar cada pacote recebido e capturar um carimbo de tempo apenas para pacotes que precisam dele.¶

O filtro de hardware pode ser geralmente configurado para transportes PTP específicos (por exemplo, UDP sobre IPv4, UDP sobre IPv6 e 802.3) e às vezes até o tipo de mensagem PTP (por exemplo, mensagem de sincronização ou solicitação de atraso) para reduzir ainda mais a taxa de carimbos de tempo no lado do servidor ou do cliente no caso de mensagens multicast, mas ele normalmente não pode ser configurado para carimbar mensagens NTP enviadas para o porta UDP 123.¶

Outro problema para o NTP é a falta de suporte de hardware em switches e roteadores de rede. Com o PTP, os dispositivos operam como relógios de fronteira ou relógios transparentes. Os relógios de fronteira são análogos a clientes NTP que também funcionam como servidores para outros clientes. Os relógios transparentes são muito mais simples. Eles apenas medem o atraso na transmissão de pacotes PTP e escrevem esse atraso no campo de correção do próprio pacote (modo de uma etapa) ou de um pacote posterior na troca PTP (modo de duas etapas). Os relógios transparentes são específicos para o mecanismo de atraso PTP usado na rede, seja de ponta a ponta (E2E) ou peer-to-peer (P2P).¶

Este documento especifica um novo meio de transporte para NTP para habilitar o timestamp de hardware em NICs que podem timestamp apenas mensagens PTP e para aproveitar relógios transparentes unicast PTP de ponta a ponta. Adiciona um novo tipo-comprimento-valor (TLV) para PTP para conter mensagens NTP e um novo campo de extensão para NTP para fornecer aos clientes e pares a correção de suas solicitações NTP dos relógios transparentes. O modo de transmissão NTP não é suportado.¶

O uso de mensagens PTP requer que as regras do protocolo IEEE 1588 sejam seguidas.[IEEE1588–2019]O NTP sobre PTP não requer que outros relógios PTP estejam presentes na rede. Não interrompe seu funcionamento se estiverem presentes. Se a rede utiliza relógios transparentes unicast PTP de ponta a ponta, clientes e pares NTP usando PTP como meio de transporte podem alcançar a mesma ou melhor precisão que relógios PTP usando PTP para sincronização. Hostes em uma rede podem usar PTP para sincronização em um domínio e transporte de mensagens NTP em outro domínio ao mesmo tempo.¶

1.1. Comparação com PTP

O modo cliente-servidor do NTP, mesmo com o transporte PTP, tem várias vantagens sobre o PTP usando mensagens multicast ou unicast:¶

• O NTP é mais seguro. Mecanismos de segurança existentes especificados para NTP, como Network Time Security (NTS)[RFC8915]Ainda há trabalho a ser feito no transporte PTP. É mais difícil proteger o PTP contra ataques de atraso porque a mensagem de sincronização não é uma resposta imediata a um pedido do cliente. O modo unicast do PTP permite uma amplificação quase infinita do tráfego, que pode ser explorada para ataques de negação de serviço e pode ser limitada apenas por mecanismos de segurança que exigem autenticação do cliente.¶

• O NTP é mais resiliente a falhas. Cada cliente pode usar múltiplos servidores e detectar fontes falhadas na sua seleção de fontes. No PTP, uma única falha de hardware ou software pode interromper todo o domínio PTP. Múltiplos domínios independentes precisam ser usados para lidar com qualquer falha.¶

• O NTP é mais adequado para sincronização em redes que não possuem suporte total PTP no caminho ou onde os erros de carimbo de tempo não têm uma distribuição simétrica (por exemplo, devido à sensibilidade à carga da rede). O NTP não assume que o atraso da rede é constante e a taxa de medições em direções opostas é simétrica. Ele pode filtrar as medições de forma mais eficaz e não é sensível a atrasos da rede e erros de carimbo de tempo assimetricamente distribuídos. O PTP precisa medir a compensação e o atraso separadamente para permitir mensagens multicast, o que é necessário para reduzir a taxa de carimbo de tempo de transmissão.¶

• O NTP precisa de menos mensagens para obter o mesmo número de carimbos de tempo. Ele usa menos largura de banda da rede do que o PTP usando mensagens unicast.¶

• O NTP fornece aos clientes uma estimativa do erro máximo do relógio (distância raiz).¶

A desvantagem do NTP é que a taxa de carimbo de tempo de transmissão aumenta à medida que o número de clientes cresce. Um servidor limitado pela taxa de carimbo de tempo de hardware não pode fornecer um serviço de tempo altamente preciso ao mesmo número de clientes como com o PTP usando mensagens multicast.¶

1.2. Linguagem de Requisitos

As palavras-chave "DEVE", "NÃO DEVE", "OBRIGATÓRIO", "DEVE FAZER", "NÃO DEVE FAZER", "DEVE-SE", "NÃO DEVE-SE", "RECOMENDADO", "NÃO RECOMENDADO", "PODE, eOPÇIONAL" neste documento devem ser interpretados como[RFC2119] [RFC8174]quando, e apenas quando, aparecerem em letras maiúsculas, como mostrado aqui.¶

2. PTP Transporte para NTP

Um novo TLV é definido para PTP para conter mensagens NTP nos modos cliente (3), servidor (4) e simétrico (1 e 2) (ver[RFC 5905]). O uso de outros modos NTP no TLV não é especificado. Qualquer transporte especificado para PTP que suporte mensagens unicast e um mapeamento IPv4 ou IPv6 pode ser usado para NTP sobre PTP.¶

O NTP TLVTexto: DEVEDeve ser incluído em uma mensagem de evento unicast PTP. Uma mensagem de evento é necessária para habilitar o carimbo de tempo de hardware específico PTP e correções de relógios transparentes. A mensagem PTPTexto: DEVEConformar-se à[IEEE1588–2008]Versão 2.1 do PTP[IEEE1588–2019]ou qualquer versão futura do¶

O NTP TLV é um TLV específico da organização que possui os seguintes¶

• tipo é 0x8000 (EXTENSÃO_DA_ORGANIZAÇÃO_NÃO_PROPAGAR) na¶

• lengthField é 8 + comprimento da mensagem NTP¶

• O identificador de organização é 00-00-5E (o Identificador Único Organizacional (OUI) é atribuído à IANA pela Autoridade de Registro IEEE).¶

• O subtipo de organização é 0x1.¶

• O campo de dados contém dois octetos zero para alinhamento de 32 bits seguido pelo mensagem NTP, que normalmente seria o payload UDP.¶

Um cliente ou par NTP que utiliza o transporte PTP envia solicitações NTP contidas como o NTP TLV nas mensagens PTP.¶

Um servidor ou par NTP que responde a uma solicitação NTP recebida através do transporte PTP.DEVEFormar sua resposta como o NTP TLV utilizando o mesmo transporte PTP. Para evitar amplificação de tráfego, o servidor ou par DEVE agir dessa maneira.NÃO DEVEEnvie a resposta se a mensagem PTP contendo a resposta NTP for maior que a mensagem PTP contendo o pedido NTP. Esta exigência afeta o Autokey.[RFC 5906]Em alguns casos, as respostas são maiores que as solicitações (por exemplo, durante o intercâmbio de certificados). A solicitação...DEVERIAO texto será preenchido com o PTP PAD TLV (tipo 0x8008) até o comprimento máximo esperado da resposta para permitir a transmissão da resposta.¶

Se a resposta NTP for esperada para ser utilizada na sincronização (ou seja, não for uma mensagem de erro), o PTP deve conter a resposta NTP.DEVERIATenho o mesmo comprimento da mensagem PTP que contém o pedido NTP, utilizando o PTP PAD TLV, se necessário, para evitar um atraso assimétrico em redes sem suporte total PTP no caminho.¶

A versão 2.1 do PTP[IEEE1588–2019]A especificação estabelece o seguinte:¶

Um domínio deve definir o escopo da comunicação de mensagens PTP, estado, operações, conjuntos de dados e escala de tempo. Dentro de uma Rede PTP, um domínio é identificado por dois atributos: domainNumber e sdoId.¶

No contexto do NTP sobre PTP versão 2.1, isso significa que os servidores, clientes e pares NTPDEVEverificar que as mensagens PTP recebidas tenham o domainNumber e sdoId esperados para serem usados pelo NTP sobre PTP na rede. O domainNumberDEVESeja 123 por padrão, e sdoId.DEVERIASeja 0. O número de domínio 123 não é comumente usado por perfis PTP, então é menos provável que interfira em qualquer outra operação PTP que possa estar rodando na rede. O número de domínioDEVERIAO texto pode ser configurado para permitir que o NTP seja movido de um domínio para outro, caso haja conflito com um perfil PTP que utilize o mesmo número de domínio e sdoId. No entanto, todos os servidores, clientes e pares que utilizam NTP sobre PTP na rede precisam usar o mesmo número de domínio e sdoId para se comunicarem entre si.¶

Se o transporte UDP for usado para PTP, os números de porta UDP de origem e destino devem ser preservados.DEVERIASeja o porto de evento PTP (319). Se o cliente implementou a randomização de porto.[RFC9109]As solicitações e/ou respostas não receberiam um carimbo de tempo de hardware devido ao filtro de hardware corresponder apenas ao porto de evento PTP.¶

Quaisquer campos de autenticador incluídos nas mensagens NTPDEVERIAMser calculados apenas sobre a mensagem NTP seguinte ao cabeçalho do NTP TLV. Outros dados na mensagem PTP (fora do NTP TLV) não são protegidos. Com exceção do campo de correção PTP que requer manuseio especial conforme descrito na seção seguinte, os outros campos PTP são utilizados apenas para o transporte da mensagem NTP e não têm impacto na segurança do NTP, da mesma forma que os cabeçalhos IP e UDP.¶

Carimbos de tempo de recebimento e transmissão contidos nas mensagens NTPNÃO DEVERIAMser ajustados para o início dos dados NTP na mensagem PTP. Para minimizar o impacto de diferentes velocidades de link na precisão em redes sem suporte total PTP no caminho, o carimbo de tempo de transmissãoDEVERIAcorresponder ao ponto de carimbo de tempo da mensagem PTP (ou seja, o início do primeiro símbolo após o delimitador de quadro de início Ethernet), e o carimbo de tempo de recepçãoDEVERIAser transposta do ponto de carimbo de tempo da mensagem PTP para o final da recepção (por exemplo, o final do último símbolo da sequência de verificação de quadro Ethernet).¶

3. Campo de Extensão de Correção de Rede

Relógios transparentes PTP de um passo modificam o campo de correção no cabeçalho das mensagens de evento PTP que contêm mensagens NTP. Para poder verificar e aplicar as correções em uma medição NTP, o cliente ou par precisa saber a correção tanto da solicitação quanto da resposta.¶

O formato do Campo de Extensão de Correção de Rede é mostrado na Figura1.¶

0 1 2 3

O comprimento do preenchimento é o mínimo necessário para criar um campo de extensão válido na versão utilizada do NTP. No NTPv4, são 16 octetos para obter um campo de extensão de 28 octetos conforme o[RFC7822].¶

O campo de correção da rede no campo de extensão utiliza o formato de carimbo de tempo NTP de 64 bits (com resolução de aproximadamente 1/4 de nanosegundo). O campo de correção no cabeçalho PTP tem um formato diferente (64 bits de nanosegundos + 16 bits de fração).¶

O valor da correção de rede NTP é a soma das correções PTP fornecidas por relógios transparentes e o tempo necessário para receber o pacote (ou seja, o comprimento do pacote incluindo a sequência de verificação de quadro dividida pela velocidade de link).¶

O motivo para não usar apenas a correção PTP é evitar uma correção assimétrica quando o servidor e o cliente, ou pares, estão conectados à rede com diferentes velocidades de link. A duração de recebimento incluída na correção NTP cancela a transposição do carimbo de tempo de recebimento PTP (que corresponde ao início da recepção) para o carimbo de tempo de recebimento NTP (que corresponde ao fim da recepção).¶

A Figura2Os gráficos mostram os carimbos de tempo NTP, as durações de transmissão/recepção e os atrasos de processamento e fila incluídos nas correções PTP para uma troca NTP feita através de dois relógios PTP transparentes. A velocidade de link está aumentando na trajetória da rede do cliente para o servidor. Os atrasos de propagação nos cabos não são mostrados.¶

Servidor NTP T2 T3

Quando um servidor NTP que suporta o transporte PTP recebe um pedido NTP contendo o campo de extensão de correção de rede, eleDEVEresponder com o campo de extensão fornecendo a correção de rede do pedido do cliente. O servidorDEVEIgnore o valor da rede na correção da solicitação.¶

Um cliente ou par NTP que suporta o transporte PTP e está configurado para usar a correção da rede para a associação.DEVEIncluir o campo de extensão em suas solicitações NTP. Em caso de cliente, o valor de correção no campo de extensão deve ser sempre zero.DEVESer sempre¶

Quando o cliente ou par tiver a correção da rede tanto na solicitação quanto na resposta, ele pode corrigir o atraso e o deslocamento medidos no par NTP:¶

• delta_c = delta - (nc_rs + nc_rq - dur_rs - dur_rq) * (1 - freq_tc)¶

• theta_c = theta + (nc_rs - nc_rq) / 2¶

Onde¶

• Delta é o atraso do par NTP de[RFC 5905]¶

• Theta é o deslocamento NTP de[RFC 5905]¶

• nc_rq é a correção de rede da solicitação¶

• nc_rs é a correção de rede da resposta¶

• a duração da transmissão da solicitação (dur_rq)¶

• a duração da recepção da resposta (dur_rs)¶

• a frequência máxima de erro assumida de relógios transparentes (freq_tc)¶

o atraso corrigido (delta_c) e o deslocamento (theta_c)NÃO DEVEser¶

Atraso na raiz (DELTA)atraso raiz (DELTA)Precisa ser corrigido para garantir que a distância de erro máxima (distância raiz) permaneça independente das correções de rede.¶

A escalonamento pelo constante freq_tc (por exemplo, 100 partes por milhão (ppm)) é necessário para criar espaço para erros em correções feitas por relógios transparentes que rodam mais rápido que o tempo verdadeiro e para evitar que amostras com correções maiores recebam um atraso mais curto do que amostras com correções menores, o que impactaria negativamente seu filtragem e ponderação.¶

Os valores dur_rq e dur_rs fazem com que o atraso corrigido corresponda a uma conexão direta ao servidor. Se não fossem usados, um atraso perfeitamente corrigido em um caminho de rede curto seria muito próximo de zero e frequentemente negativo devido ao deslocamento de frequência entre o cliente e o servidor. Note que os pares NTP e relógios PTP que usam o mecanismo de atraso E2E são mais sensíveis a deslocamentos de frequência devido a intervalos de medição mais longos. Se dur_rq for desconhecido,PODEser assumido igual a dur_rs.¶

6. Referências

6.1. Referências Normativas

6.2. Referências Informativas