Noções básicas de PTP e SyncE com configuração do Cisco IOS XR

Introdução

Este documento descreve o funcionamento do Precision Time Protocol (PTP) e do Synchronous Ethernet (SyncE) com exemplos de configurações, exemplos e comandos de solução de problemas para dispositivos Cisco IOS® XR em perfis de telecomunicações 8275.1 e 8275.2.

Informações de Apoio

Um relógio para nós é um relógio de parede ou um relógio de pulso, mas para dispositivos de rede, é um sinal periódico de 0 e 1's alternativos que é usado para obter amostras dos bits de dados. Assim como uma mão de segundos no relógio tem um movimento angular para representar um segundo, um par de 0 e 1 representa T (período de tempo [T=1/frequência]). Para gerar esse relógio, os dispositivos de rede usam um oscilador de cristal que tem um erro de ±100 ppm (partes por milhão. Por exemplo, um relógio com a frequência de 250 MHz e 100 ppm terá uma faixa de frequência de 249,975 MHz a 250,025 MHz.) na geração do sinal de clock. Assim, idealmente, o relógio não é completamente periódico, mas é suficiente para o requisito de amostragem dos sinais de dados para fora das interfaces.

As redes de telecomunicações (3G/4G/5G) usam um relógio de altíssima qualidade (estrato) e todas as estações base (NodeB’s/eNodeB’s e assim por diante) devem ser sincronizadas com esse relógio com o mínimo possível de erro/atraso (aproximadamente 1µs).

• Uma opção é instalar um GPS em todas as estações de base, que é bastante caro e menos seguro como o GPS funciona em sistemas de satélite.
• A segunda opção é usar o NE (Networking Equipment, equipamento de rede) existente para transferir as informações do relógio junto com o sinal de dados. Essa opção é muito econômica, pois os dados já estão sendo transferidos por NEs e a utilização de NEs para a transferência de sinal de clock os tornará mais baratos e mais seguros. No entanto, a qualidade do relógio pode não ser tão boa quanto a da opção anterior do GPS e varia no perfil/protocolo usado nos NEs, bem como no congestionamento na rede.

Importância da sincronização de fase/frequência

Um sinal de mensagem (por exemplo, sinal de voz) modulado com uma onda de alta frequência (sinal portador) na extremidade do transmissor deve ser demodulado na extremidade do receptor com o mesmo sinal portador usado na extremidade do transmissor. Se ocorrer qualquer alteração/deslocamento na frequência ou fase da onda portadora no receptor, o sinal da mensagem será corrompido. No entanto, um pequeno deslocamento é sempre esperado entre a onda portadora Rx e a onda portadora Tx.

Uma analogia é usar uma caixa segura para enviar uma mensagem e bloqueá-la com uma chave. Se alguém quiser ler a mensagem na caixa de segurança, a mesma chave deve ser usada para desbloquear a caixa na extremidade do receptor. Se a chave de réplica tiver distorções/desfigurações, a mensagem não poderá ser lida.

As compensações aceitáveis para vários serviços de telecomunicações são:

Sincronização de relógio de rede

A sincronização é o alinhamento dos relógios com a mesma hora/fase e frequência.

A sincronização para temporização pode ser categorizada em sincronização de frequência (atingindo = / = onde = também chamado como a mesma taxa), sincronização de fase (ao mesmo tempo) e sincronização de hora (hora do dia).

Sincronização de Frequência

Todos os NE devem corresponder a frequência do seu relógio a um relógio de origem (derivado de um MasterClock).

A sincronização de frequência para NE pode ser obtida com SyncE ou PTPv2, que serão discutidos mais adiante nesta seção.

O SyncE trabalha na derivação da frequência dos pacotes de dados recebidos na interface (funciona na camada física) juntamente com os pacotes ESMC recebidos (aproximadamente um pacote por segundo) na interface que descreve a qualidade do relógio. Assim, ele não adiciona nenhum pacote de controle e não é afetado pelo congestionamento de tráfego, que é o melhor aspecto do SyncE.

O PTP é executado em pacotes, portanto haverá um fluxo de pacotes de controle e os pacotes serão afetados pelo congestionamento, o que aumenta o atraso.

Sincronização de Fases

A sincronização de fase é sobre o alinhamento desses sinais do relógio. Podemos ver que os sinais sincronizados de frequência acima ainda não estão alinhados, portanto, eles têm um deslocamento de fase.

O PTPv2 é usado para transportar as informações de fase através da rede.

Sincronização de horário

A sincronização de horário, também chamada de hora do dia, simplesmente tem a mesma hora em todos os NEs. Ou seja, t₁=t₂.

NTP e PTP são usados para transferir informações de tempo na rede. Enquanto o NTP fornece precisão de milissegundos, o PTP pode fornecer precisão de até submicrossegundos.

A sincronização de tempo e a sincronização de fase são frequentemente usadas como sinônimos na rede, pois o PTP usado para a sincronização de fase alcançará a sincronização de tempo.

O NTP não fará parte de nossa discussão agora.

SyncE

Princípio básico do SyncE

O SyncE funciona com base no princípio básico de extrair a frequência do relógio dos dados recebidos em uma porta.

Um exemplo simples é ilustrado aqui. O sinal de dados é processado com o oscilador local e os dados de saída são enviados para fora da porta Tx. Você pode observar que a frequência do relógio está presente no sinal de dados transmitido na porta. O SyncE funciona com base no princípio do processamento reverso do sinal recebido na porta Rx e na obtenção das informações de frequência do relógio transmitido.

SyncE é uma recomendação da ITU-T sobre como fornecer uma frequência em uma rede. De acordo com a recomendação, a frequência será recuperada do fluxo de bits na camada física, como apontado anteriormente. O relógio que será distribuído na cadeia é chamado de relógio de referência primário (PRC) e todos os relógios na rede devem ser rastreáveis para esse relógio. Para obter um relógio rastreável, todos os nós em uma cadeia entre o MasterClock e o dispositivo final precisam ser implementados com um Relógio de Equipamento Ethernet (EEC) síncrono, de acordo com as recomendações do SyncE. O desempenho do relógio recuperado não dependerá da carga da rede, já que ele não sincroniza com nenhum pacote específico.

O NE MasterClock usa referências de temporização de entrada externas que vêm do relógio da rede (SSU ou BITS). Essas referências são então usadas como entrada para o relógio EEC, normalmente localizado no cartão de temporização central do NE. A referência de cronometragem de saída EEC é então usada para obter dados de amostra e enviar o tráfego na porta Tx de ativação de SyncE.

Na NE SlaveClock, o relógio é recuperado dentro da recuperação de dados do relógio do transceptor (CDR). Em alguns casos em que o relógio RX não está disponível no transceptor, o uso de um CDR externo pode ser necessário para recuperar o relógio. Em seguida, o relógio é enviado através do painel traseiro para acessar a placa de sincronização central do SlaveClock. Esta referência cronológica torna-se então uma referência à CEE (também conhecida como uma referência cronológica de linha). Como mostrado no SlaveClock NE, um EEC pode aceitar referências de linha e externas, bem como a entrada de um oscilador local de ±4,6 ppm (usado em situações onde não há referências de linha ou externas disponíveis). A partir desse ponto, o NE SlaveClock torna-se o NE MasterClock para o próximo NE downstream e a sincronização é transportada em uma base de nó para nó, onde cada nó participa da recuperação e da distribuição.

Canal de Mensagens de Sincronização Ethernet

O ESMC (Ethernet Synchronization Messaging Channel) é um protocolo lento Ethernet definido pela ITU-T (isto é, as mensagens são enviadas ao endereço de destino Ethernet multicast 01-80-C2-00-00-02 e usam o Ether Type 88-09) para evitar que as mensagens vazem de um link sincronizado para outro link.

Ele transporta as informações da Mensagem de Status de Sincronização (SSM), que é o nível de qualidade (QL) do relógio transmissor. Por exemplo: se o dispositivo upstream estiver em sincronia com um relógio PRC, o valor QL recebido será QL-PRC e o valor SSM correspondente será 0010.

As PDUs de informações do ESMC são enviadas periodicamente a uma taxa de uma PDU por segundo. A falta de recepção de uma PDU ESMC em um período de cinco segundos resulta no SSF=true (QL=QL-FALHA). O valor padrão (inicial) para o QL é DNU (SSM=1111) e só deve ser alterado quando um TLV QL válido for recebido.

Precisamos observar que, se um dispositivo for dual-homed e a fonte de sinal para ambos os dispositivos upstream for PRC, o QL recebido no dispositivo de ambos os links será QL-PRC. Portanto, precisamos priorizar os links de acordo para escolher o dispositivo upstream correto com relação a saltos, links, etc.

A sincronização de MasterClock-SlaveClock sobre vários NEs com várias entradas de sincronização possíveis para proteção da sincronização pode levar a loops de temporização entre NEs. Para evitar loops de temporização, um NE deve inserir um valor SSM de DNU na direção do NE, que é usado como a origem de sincronização real para o relógio NE.

SyncE com LAG

O SyncE funciona na camada Física e os pacotes ESMC também são transportados pelo protocolo lento Ethernet. O LAG é outra função que utiliza protocolos lentos e opera acima do ESMC. O processamento de mensagens ESMC é, portanto, necessário em cada link síncrono habilitado para Ethernet no grupo LAG.

Também é importante observar que o uso de links paralelos, como no caso do LAG, precisa ser cuidadosamente considerado devido ao potencial de criação de loops de temporização.

 Idealmente, é suficiente executá-lo no link de membro único do pacote, mas, caso contrário, é deixado para os operadores configurar várias portas síncronas habilitadas para Ethernet.

PTPv2/1588v2

O IEEE 1588 é definido pelo Institute of Electrical and Electronics Engineers (IEEE) em 2002 como Precision Clock Synchronization Protocol (PTP) para sistemas de controle e medição em rede. É chamado de Precision Time Protocol (PTP), abreviando.

O IEEE 1588v1 aplica-se a campos de automação industrial e testes e medições. Com o desenvolvimento de redes IP e a popularização de redes 3G, a demanda por sincronização de tempo em redes de telecomunicações aumentou. Para satisfazer essa necessidade, o IEEE elaborou o IEEE 1588v2 baseado no IEEE 1588v1 em junho de 2006, revisou o IEEE 1588v2 em 2007 e lançou o IEEE 1588v2 no final de 2008.

1588v2 é um protocolo de sincronização de tempo que permite uma sincronização de tempo altamente precisa entre dispositivos. Também é usado para implementar a sincronização de frequência entre dispositivos.

Esse mecanismo de sincronização baseado em pacotes combina sincronização de frequência e fase em níveis de submicrossegundos, com recursos de distribuição de ToD através do mecanismo eficiente de trocas de pacotes

A maior fraqueza do PTP também se deve à sua natureza de pacote, já que os pacotes de sincronização usados pelo PTP são encaminhados na rede entre o MasterClock e os hosts, que estão sujeitos a todos os eventos de rede, como atraso de quadro (latência), variação de atraso de quadro (jitter de pacote) e perda de quadro. Mesmo com a prática recomendada de aplicar alta prioridade aos fluxos de sincronização, esses pacotes de sincronização ainda experimentarão congestionamento e possíveis problemas de roteamento e encaminhamento, como oscilações fora de sequência e de rota.

Princípio básico de funcionamento do PTP

Enviamos o tempo (hh:mm:ss) em um pacote e usamos o tempo de ida e volta do fluxo do pacote para localizar o atraso na transmissão de um pacote e corrigir o tempo do relógio ajustando com a metade do atraso de ida e volta.

Funcionamento do PTP

O PTP usa uma arquitetura hierárquica MasterClock-SlaveClock para a distribuição do relógio.

Ele especifica como os relógios em tempo real no sistema são sincronizados entre si. Esses relógios são organizados em uma hierarquia de sincronização MasterClock−SlaveClock com o relógio na parte superior da hierarquia, o MasterClock, determinando o tempo de referência para todo o sistema. A sincronização é obtida através da troca de mensagens de temporização PTP, com os SlaveClocks usando as informações de temporização para ajustar seus relógios à hora de seu MasterClock na hierarquia.

O PTP foi projetado considerando um modelo de comunicação multicast. O PTP também suporta um modelo de comunicação unicast desde que o comportamento do protocolo seja preservado. O PTP assume que as mensagens de Anúncio são enviadas periodicamente por uma porta e entregues a todas as outras portas dos relógios ordinários ou de limite dentro de um caminho de comunicação. Se o caminho de comunicação consistir em mais de duas portas, presume-se que as mensagens de Anúncio sejam enviadas em multicast ou que as informações de Anúncio sejam replicadas para todas as portas no caminho de comunicação usando mensagens unicast. As portas PTP descobrem outras portas em um caminho de comunicação através do recebimento de mensagens de Anúncio multicast.

O protocolo é executado dentro de um escopo lógico chamado domínio. Todas as mensagens PTP, conjuntos de dados, máquinas de estado e todas as outras entidades PTP são sempre associadas a um ID de domínio específico

O protocolo define o evento e as mensagens PTP gerais. As mensagens de evento são mensagens temporizadas, ou seja, um timestamp preciso (tempo registrado no dispositivo no ponto de entrada/saída, mas não é necessário que a mensagem transporte o tempo t) é gerado na transmissão e na recepção. As mensagens gerais não exigem carimbos de data/hora precisos.

Domínios PTP

Um domínio consiste em um agrupamento lógico de relógios que se comunicam usando o protocolo PTP.

Os domínios PTP são usados para particionar uma rede dentro de uma entidade administrativa. As mensagens e os conjuntos de dados do PTP são associados a um domínio e, portanto, o protocolo PTP é independente para domínios diferentes.

Padrão de troca de mensagens

1. MasterClock envia uma mensagem Sync para SlaveClock e observa a hora em que foi enviado.
2. O SlaveClock recebe a mensagem Sync e anota o horário da recepção.
3. MasterClock transmite para SlaveClock o timestamp por:
   • Incorporando o carimbo de data/hora na mensagem de sincronização. Isso requer algum tipo de processamento de hardware para maior precisão.
   • Incorporando o carimbo de data/hora em uma mensagem de follow_up.
4. SlaveClock envia uma mensagem Delay_Req para MasterClock e anota a hora em que foi enviado.
5. MasterClock recebe a mensagem Delay_Req e observa o horário da recepção.
6. O MasterClock transmite ao SlaveClock o timestamp, incorporando-o em uma mensagem Delay_Resp.

A precisão do tempo do PTP é degradada pela assimetria nos caminhos tomados pelas mensagens de evento. Especificamente, o erro de deslocamento de tempo é 1/2 da assimetria.

Assimetria não detectável pelo PTP. No entanto, se conhecido, o PTP corrige a assimetria. A assimetria pode ser introduzida na camada física, por exemplo, através da assimetria dos meios de transmissão, por bridges e roteadores, e em grandes sistemas pelos caminhos de encaminhamento e de reversão percorridos por mensagens de evento que tomam diferentes rotas através da rede. Os sistemas devem ser configurados e os componentes devem ser selecionados para minimizar esses efeitos, guiados pela precisão de temporização necessária. Em sistemas de sub-rede simples com distâncias de alguns metros, a assimetria geralmente não é uma preocupação para precisões de tempo acima de alguns 10s de ns.

Vários tipos de pacotes

O conjunto de mensagens de evento consiste em:

1. Sync - Usado para sincronização de tempo entre MasterClock e SlaveClock. Em Duas Etapas, as mensagens de Sincronização não transportam tempo, mas o tempo será marcado no MasterClock e será transportado na mensagem Follow_Up. Em Uma Etapa, a mensagem Sync levará o tempo. Dispositivos/hardware antigos não podiam suportar a medição e o transporte do ponto de tempo de saída quando uma mensagem era entregue em uma porta, portanto, duas etapas foram devido à limitação de hardware. Hoje em dia, o hardware pode gravar o ponto de tempo de saída e enviá-lo dentro da mensagem de sincronização. Uma etapa é compatível com versões anteriores e duas etapas.

   

2. Delay_Req - Uma mensagem Delay_Req é uma solicitação do nó receptor/SlaveClock para retornar a hora em que a mensagem Delay_Req foi recebida, usando uma mensagem Delay_Resp. Ele será usado para calcular o tempo de trânsito entre SlaveClock e MasterClock. Esta mensagem tem carimbo de data/hora em SlaveClock.
3. Pdelay_Req - Uma mensagem Pdelay_Req é transmitida por uma porta PTP para outra porta PTP como parte da medição do tempo de propagação de porta a porta para determinar o atraso no link entre elas. É usado pelo relógio transparente P2P para calcular o atraso do link por salto.
4. Pdelay_Resp - Uma mensagem Pdelay_Resp é transmitida por uma porta PTP em resposta ao recebimento de uma mensagem Pdelay_Req.

O conjunto de mensagens gerais consiste em:

• Announce - Esta mensagem é usada pelo Best MasterClock Algorithm (BMCA) para gerar a topologia MasterClock-SlaveClock. Ele é usado para selecionar o melhor MasterClock e mantê-lo no lugar.
• Follow_Up - Este tipo de mensagem é usado no modo de duas etapas. Ele carrega o tempo. (Hora de saída de sincronização no nó MasterClock) em sua mensagem.
• Delay_Resp - É usado para calcular o tempo de trânsito de MasterClock para SlaveClock. Ele transporta a hora (hora de saída da mensagem Delay_Resp) na mensagem.
• Pdelay_Resp_Follow_Up - É semelhante à mensagem Follow_Up, mas é gerada por um relógio transparente P2P.
• Gerenciamento: não faz parte de nossa discussão.
• Sinalização - Para comunicação entre relógios para todos os outros fins. Por exemplo, as mensagens de sinalização podem ser usadas para a negociação da taxa de mensagens unicast entre um MasterClock e seus SlaveClocks.

As mensagens Sync, Delay_Req, Follow_Up e Delay_Resp são usadas para gerar e comunicar as informações de temporização necessárias para sincronizar relógios comuns e de limite usando o mecanismo de solicitação-resposta de atraso.

As mensagens Pdelay_Req, Pdelay_Resp e Pdelay_Resp_Follow_Up são usadas para medir o atraso do link entre duas portas de relógio que implementam o mecanismo de atraso do peer. O retardo do link é usado para corrigir informações de temporização em mensagens Sync e Follow_Up em sistemas compostos de relógios transparentes ponto-a-ponto.

Os relógios comuns e de limite que implementam o mecanismo de atraso de peer podem sincronizar usando os atrasos de link medidos e as informações nas mensagens Sync e Follow_Up. A mensagem de Anúncio é usada para estabelecer a hierarquia de sincronização. As mensagens de gerenciamento são usadas para consultar e atualizar os conjuntos de dados PTP mantidos por relógios. Essas mensagens também são usadas para personalizar um sistema PTP e para inicialização e gerenciamento de falhas. As mensagens de gerenciamento são usadas entre nós de gerenciamento e relógios (não farão parte de nossa discussão).

As mensagens de sinalização são usadas para comunicação entre relógios para todos os outros fins. Por exemplo, as mensagens de sinalização podem ser usadas para a negociação da taxa de mensagens unicast entre um MasterClock e seus SlaveClocks.

Tipos de dispositivo PTP

Há cinco tipos básicos de dispositivos PTP, como a seguir:

1. Relógio comum - Pode ser apenas um Grand MasterClock (GM) ou apenas um SlaveClock.
2. Relógio de limite - Pode ser SlaveClock e GM ao mesmo tempo
3. Relógio transparente de ponta a ponta - O relógio transparente de ponta a ponta encaminha todas as mensagens apenas como uma ponte, roteador ou repetidor normal. No entanto, para mensagens de evento PTP, a ponte de tempo de residência, mostrada na Figura abaixo, mede o tempo de residência (o tempo que a mensagem leva para passar pelo relógio transparente) das mensagens de evento PTP. Esses tempos de residência são acumulados em um campo especial, o Campo de correção, da mensagem de evento PTP ou da mensagem de acompanhamento associada. Essa correção é baseada na diferença no carimbo de data/hora gerado quando a mensagem de evento entra e sai do relógio transparente.

   

   

   

4. Peer-to-peer transparent clock - Adiciona o tempo de residência, bem como o tempo de atraso de trânsito do link para mensagens ptp usando o mecanismo de atraso de peer (gera seus próprios pacotes delay-req-resp para calcular o atraso de link de peer).

   

   

5. Nó de gerenciamento (não faz parte de nossa discussão).

Estabelecer a Hierarquia MasterClock−SlaveClock

Dentro de um domínio, cada porta de um relógio comum e de limite executa uma cópia independente da máquina de estado do protocolo. Para "eventos de decisão de estado", cada porta examina o conteúdo de todas as mensagens de Anúncio recebidas na porta. Usando o melhor algoritmo de MasterClock, o conteúdo da mensagem de Anúncio e o conteúdo dos conjuntos de dados associados ao relógio comum ou de limite são analisados para determinar o estado de cada porta do relógio.

Máquina de Estado PTP

Cada porta de um relógio comum e de limite mantém uma cópia separada da máquina de estado do PTP. Esta máquina de estado define os estados permitidos da porta e as regras de transição entre os estados. Os principais "eventos de decisão de estado" que determinam a hierarquia de MasterClock−SlaveClock são o recebimento de uma mensagem de Anúncio e o fim de um Intervalo de anúncio (o intervalo entre as mensagens de Anúncio). Os estados de porta que determinam a hierarquia de MasterClock−SlaveClock são os seguintes:

• INIT - A porta ainda não está pronta para participar do PTP.
• LISTENING - O primeiro estado quando uma porta se torna pronta para participar do PTP: a porta ouve o PTP MasterClocks por um período de tempo (configurável)
• PRE-MasterClock - A porta está prestes a entrar no estado MasterClock.
• MasterClock - A porta fornece carimbos de data e hora para qualquer SlaveClock de escuta/relógios de limite.
• UNCALIBRATED - A porta recebe carimbos de data/hora de um MasterClock, mas o relógio do roteador ainda não está sincronizado com esse MasterClock
• SLAVE - A porta recebe carimbos de data/hora de um MasterClock, e o relógio do roteador é sincronizado com esse MasterClock
• PASSIVO - A porta está ciente de um relógio melhor do que aquele que anunciaria se estivesse no estado MasterClock, mas não está cortando esse relógio

Melhor algoritmo MasterClock

O melhor algoritmo de MasterClock compara os dados que descrevem dois relógios para determinar quais dados descrevem o melhor relógio. Esse algoritmo é usado para determinar qual dos relógios descritos em várias mensagens de Anúncio recebidas por uma porta de relógio local é o melhor relógio. Também é usado para determinar se um relógio recém-descoberto, um MasterClock estrangeiro, é melhor que o relógio local. Os dados que descrevem um MasterClock externo estão contidos nos campos grandMasterClock de uma mensagem Announce.

O algoritmo de comparação do conjunto de dados é baseado em comparações de atributos entre pares com a seguinte precedência:

1. priority1 - Uma designação configurável pelo usuário de que um relógio pertence a um conjunto ordenado de relógios a partir do qual um MasterClock é selecionado
2. clockClass - Um atributo que define a rastreabilidade TAI de um relógio
3. clockAccuracy - Um atributo que define a precisão de um relógio
4. offsetScaledLogVariance - Um atributo que define a estabilidade de um relógio
5. priority2 - Uma designação configurável pelo usuário que fornece um pedido mais refinado entre relógios equivalentes
6. clockIdentity - Um desempate baseado em identificadores exclusivos

Além dessa ordem de precedência, a "distância" medida pelo número de relógios de limite entre o relógio local e o MasterClock externo é usada quando duas mensagens de Anúncio refletem o mesmo MasterClock externo. A distância é indicada no campo stepsRemoved das mensagens de anúncio. Essa condição pode ocorrer em sistemas PTP com caminhos cíclicos não removidos por um protocolo fora do PTP. O algoritmo de comparação do conjunto de dados seleciona sem ambiguidade um dos dois relógios como "melhor" ou "topologicamente melhor".

Perfis

A finalidade de um perfil PTP é permitir que as organizações especifiquem seleções específicas de valores de atributo e recursos opcionais de PTP que, ao usar o mesmo protocolo de transporte, interfuncionem e alcancem um desempenho que atenda aos requisitos de uma determinada aplicação.

Um perfil PTP deve definir:

• Melhores opções de algoritmo MasterClock
• Opções de gerenciamento de configuração
• Mecanismos de retardo de caminho (peer-delay ou delay request-response)
• O intervalo e os valores padrão de todos os atributos configuráveis do PTP e membros do conjunto de dados
• Os mecanismos de transporte exigidos, permitidos ou proibidos
• Os tipos de nó necessários, permitidos ou proibidos
• As opções necessárias, permitidas ou proibidas

Vários perfis definidos para redes de pacotes com PTP são os seguintes:

Os perfis 8265.x são usados para obter a sincronização de frequência com o PTP.

O 8275.x é usado para a sincronização de hora do dia/fase usando o PTP. Atualmente, o NCS5xx/55xx suporta 8265.1, 8275.1, 8275.2 e 8273.2.

O 8265.1 foi usado anteriormente para sincronização de relógio 3G/4G, enquanto o 8275.x é usado agora para 5G devido ao aumento na demanda por precisão com redes 5G.

8275.1

Este anexo contém o perfil de telecom PTP para distribuição de fase/tempo com suporte de tempo total da rede.

Modelo de sincronização:

O perfil G.8275.1 adota o modelo de sincronização salto por salto. Cada dispositivo de rede no caminho do relógio do Servidor para o Cliente sincroniza seu relógio local para dispositivos upstream e fornece sincronização para o dispositivo downstream

Tipos de nó:

Neste perfil, os tipos de nó permitidos são relógios comuns, relógios de limite e relógios transparentes de ponta a ponta.

Neste perfil, os tipos de nó proibidos são relógios transparentes ponto-a-ponto.

Domínios:

Os IDs de domínio de 24 a 43 podem ser usados. A ID de domínio padrão é 24

Modo de relógio:

São permitidos relógios de uma e duas etapas. Um relógio deve ser capaz de receber e lidar com mensagens transmitidas de relógios de uma e duas etapas. Não é necessário um relógio para suportar os modos de uma e duas etapas para a transmissão de mensagens.

Mecanismos de transporte exigidos, permitidos ou proibidos

Neste perfil, os mecanismos de transporte permitidos são:

• IEEE 802.3/Ethernet e
• OTN

Pelo menos um dos dois mecanismos de transporte deve ser apoiado. Para transporte sobre IEEE 802.3/Ethernet, o endereço multicast não encaminhável, 01-80-C2-00-00-0E, e o endereço multicast encaminhável, 01-1B-19-00-00-00, devem ser suportados para conformidade com este perfil

Mensagens unicast/multicast:

Todas as mensagens são enviadas em multicast, usando um dos dois endereços multicast (01-80-C2-00-00-0E/01-1B-19-00-00-00). O modo unicast não é permitido nesta versão do perfil.

Melhores opções de algoritmo MasterClock:

Esse perfil usa o BMCA alternativo.

Os seguintes parâmetros de relógio são comparados (em ordem) de cada nó disponível para selecionar o melhor MasterClock:

Tabela 1. Hierarquia BMCA do perfil do Telcom

Parâmetro	Descrição
Prioridade 1	NÃO usado em perfis de telecomunicações
Clock-class	Medida de rastreabilidade do relógio. Se a frequência/hora do MasterClock é rastreável até uma referência GNSS (A, B melhor que C)
Precisão do relógio	Qual é a precisão da saída de relógio do GM para referência principal? por exemplo: tempo preciso de até 25 ns.
Variação de Log em Escala de Deslocamento (OSPLV)	Medida da precisão do relógio. O quanto a saída de clock varia quando não sincronizada com outra origem.
Prioridade 2	Prioridade definida pelo usuário no nó MasterClock se todos os parâmetros acima corresponderem
Prioridade de porta local	Prioridade por porta definida pelo usuário no DUT
Identidade de relógio GM	ID de relógio de GrandMasterClock usada como um separador de tempo
Etapas removidas	Caminho mais curto escolhido se grandMasterClock é alcançável através de várias portas (A melhor que B)

Opção de Medição de Atraso de Caminho (Solicitação de Atraso/Resposta de Atraso):

O mecanismo de solicitação de atraso/resposta de atraso é usado nesse perfil. O mecanismo peer-delay não deve ser usado neste perfil, o método delay_req—response deve ser usado.

Esse perfil de telecom PTP define um BMCA alternativo que permite usar duas abordagens principais para configurar a topologia da rede de sincronização de fase/tempo:

Estabelecimento automático de topologia:

Ao configurar os atributos localPriority definidos nesta Recomendação para seu valor padrão, a topologia PTP é estabelecida automaticamente pelo BMCA alternativo com base nas mensagens de Anúncio trocadas pelos relógios PTP. Uma árvore de sincronização com os caminhos mais curtos para os T-GMs é construída após esta operação. Neste modo, durante eventos de falha e reconfiguração de topologia, o BMCA alternativo será executado novamente e resultará em uma nova árvore de sincronização. Essa operação BMCA alternativa garante que nenhum loop de temporização seja criado sem a necessidade de intervenção manual ou análise prévia da rede. O tempo de convergência para a nova topologia PTP depende do tamanho da rede e da configuração específica dos parâmetros PTP.

Planejamento de rede manual: o uso dos atributos localPriority definidos nesta recomendação com valores diferentes dos valores padrão permite a criação manual da topologia de rede de sincronização, de forma semelhante às redes SDH (Synchronous Digital Hierarchy) que são normalmente operadas com base na mensagem de status de sincronização (SSM). Essa opção permite o controle total das ações durante eventos de falha e a reconfiguração da topologia, com base nas prioridades locais configuradas do sistema. No entanto, é necessário um planejamento cuidadoso da rede antes da implantação para evitar loops de temporização.

Considerações sobre o uso da prioridade 2:

O atributo PTP priority2 é configurável nesse perfil. Em algumas circunstâncias especiais, o uso do atributo priority2 pode simplificar o gerenciamento da rede. Esta seção descreve dois casos de uso; outros possíveis são para estudo posterior.

• Caso 1.

Os operadores podem configurar o atributo PTP priority2 para tornar todo o Telecom Boundary Clock (T-BCs) rastreável para um Telecom Grand MasterClock (T-GM) ou rastreável para dois T-GMs diferentes ao mesmo tempo.

Por exemplo, nesta imagem, se todos os outros atributos PTP dos dois T-GMs forem iguais e os dois T-GMs estiverem configurados com o mesmo valor de prioridade2, cada T-BC selecionará o T-GM com o caminho mais curto. Se os dois T-GMs forem configurados com valores de prioridade2 diferentes, todos os T-BCs serão sincronizados com o T-GM com o menor valor de prioridade2.

• Caso 2.

Os operadores podem configurar o atributo PTP priority2 para evitar que os T-BCs de uma rede upstream sincronizem com os T-BCs de uma rede downstream quando o T-GM está em falha.

Por exemplo, na figura, se todos os outros atributos PTP de todos os T-BCs forem iguais e a prioridade2 do atributo PTP de todos os T-BCs estiver configurada com o mesmo valor, quando o T-GM estiver em falha, os T-BCs na rede upstream poderão sincronizar com os T-BCs na rede downstream, dependendo dos valores clockIdentity de todos os T-BCs. Se os T-BCs na rede upstream forem configurados com um valor de prioridade2 menor que os T-BCs na rede downstream, então, quando o T-GM estiver em falha, os T-BCs na rede downstream sincronizarão com os T-BCs na rede upstream.

Operações sobre agregação de links:

Quando dois dispositivos que incorporam relógios PTP compatíveis com esse perfil estão conectados por meio de uma agregação de links (LAG), cada link físico deve ser acessado diretamente para transmitir mensagens PTP, ignorando o LAG. Esse método evita possíveis assimetrias que podem estar presentes quando os caminhos de encaminhamento e de reversão são entregues em diferentes links pertencentes ao LAG.

Considerações sobre a escolha do endereço de destino multicast Ethernet PTP:

Esse perfil PTP suporta o endereço multicast não encaminhável 01-80-C2-00-00-0E e o endereço multicast encaminhável 01-1B-19-00-00-00 quando o mapeamento PTP é usado.

O endereço multicast Ethernet a ser usado depende da política do operador; considerações adicionais são fornecidas a seguir.

A função de bridging da Camada 2 associada à porta PTP de um T-BC ou T-TC não deve encaminhar nenhum quadro com o endereço MAC de destino 01-1B-19-00-00-00; isso pode ser feito provisionando adequadamente esse endereço multicast no banco de dados de filtragem.

• Opção 1 - Uso do endereço multicast não encaminhável 01-80-C2-00-00-0E.

Alguns operadores de rede consideram que as mensagens PTP nunca devem ser encaminhadas através de equipamentos de rede sem reconhecimento de PTP.

O uso do endereço multicast não encaminhável 01-80-C2-00-00-0E garante essa propriedade na maioria das vezes (existem exceções para alguns equipamentos Ethernet mais antigos).

Portanto, no caso de configuração incorreta do equipamento de rede (por exemplo, se as funções de PTP não estiverem habilitadas no equipamento de rede PTP), o uso desse endereço multicast evita a distribuição incorreta da sincronização, uma vez que as mensagens de PTP serão bloqueadas pelo equipamento de rede não PTP.

• Opção 2 - Uso do endereço multicast que pode ser encaminhado 01-1B-19-00-00-00.

Alguns operadores de rede consideram que o uso de um endereço multicast que pode ser encaminhado é mais flexível e que é preferível encaminhar as mensagens PTP para manter o link de sincronização em execução no caso de alguns equipamentos estarem configurados incorretamente como nós não PTP, embora haja riscos potenciais de degradação do desempenho. O sistema de gerenciamento de rede (NMS) encontrará facilmente o erro de configuração e enviará alarmes.

No entanto, é possível bloquear as mensagens PTP provisionando adequadamente esse endereço multicast no banco de dados de filtragem de cada equipamento Ethernet.

8275.2

Esta recomendação define outro perfil PTP para permitir a distribuição de fase e tempo com suporte de cronometragem parcial (PTS - Partial Timing Support) da rede (isto é, não há necessidade de cada dispositivo executar o ptp na rede). A principal diferença entre 8275.2 e 8275.1 é que ele é executado em unicast IPv4 e nem todos os nós na rede precisam executar o PTP.

Mecanismos de transporte:

Neste perfil, o mecanismo de transporte necessário é UDP/IPv4.

Mensagens unicast:

Todas as mensagens são enviadas em unicast.

Neste perfil de telecom, a negociação unicast é ativada por padrão.

O SlaveClock iniciará a sessão seguindo o procedimento de negociação da mensagem unicast.

Domínios:

Os IDs de domínio de 44 a 63 podem ser usados. O ID de domínio padrão é 44.

Melhores opções de algoritmo MasterClock:

Esse perfil usa o BMCA alternativo.

Propriedades lPath delay measurement option (delay request/delay response), Automatic topology establishment e Considerações sobre o uso de priority2 são os mesmos que telecom profile 8275.1

Considerações de PTP sobre transporte IP em topologias em anel:

Ao usar mensagens PTP sobre uma camada de transporte IP, há alguns aspectos do protocolo da camada 3 que precisam ser considerados. A camada PTP entrega mensagens na camada IP com um endereço IP de destino. A camada IP então garante que a mensagem seja entregue ao destino, desde que haja algum caminho através da rede de transporte IP do nó origem para o endereço destino. A camada IP inclui protocolos de roteamento dinâmico que podem adaptar o caminho através da rede com base nos links disponíveis entre os roteadores IP. Pode acontecer que o caminho tomado pela camada de transporte IP não seja o caminho 'esperado' pelo planejador de sincronização. A aplicação de algumas restrições na camada de transporte IP para controlar caminhos não ideais para mensagens PTP pode ser benéfica. Esse provavelmente é o caso em topologias em anel.

Tomando a topologia mostrada na figura abaixo como um exemplo, o SlaveClock é configurado para solicitar o serviço unicast de BC3 e BC4. Depois de receber as mensagens de Anúncio de BC3 e BC4, o SlaveClock executará o BMCA e selecionará BC4 como seu relógio pai com base no fato de que o valor de etapas removidas de BC4 é 1, comparado a um valor de etapas removidas de 3 para BC3. O SlaveClock solicitaria mensagens de sincronização de BC4.

Se a conexão entre BC4 e R6 for interrompida (veja a figura abaixo), BC4 não será alcançado pelo caminho esperado. No entanto, ele ainda pode ser alcançado porque os protocolos de roteamento manterão a conexão roteando os pacotes IP ao redor do anel. BC4 é mantido como o relógio pai porque ainda é considerado melhor pelo BMCA.

É mais provável que a operação desejada seja que SlaveClock alterne para BC3 para melhor desempenho.

Há algumas técnicas que podem ser empregadas para garantir que no cenário de falha identificado acima, o SlaveClock selecionará BC3 como seu relógio pai. Eles são baseados no bloqueio de mensagens IP PTP de BC4 para SlaveClock se essas mensagens estiverem transitando no sentido horário ao redor do anel. A solução é baseada no bloqueio somente das mensagens PTP e não da mensagem de outros protocolos que possam usar os mesmos endereços IP.

Opção 1. Endereços IP exclusivos e rotas estáticas:

Em alguns modelos de implantação, talvez seja possível alocar endereços IP exclusivos para o uso do PTP sozinho. Isso permite o uso de rotas estáticas para controlar a direção dos fluxos de PTP entre os nós. BC4 seria configurado de tal forma que o único caminho a ser usado para acessar 11.x.x.141 (SlaveClock) seria o link entre BC4 e R6. Além disso, R6 pode ser configurado de forma que o único caminho a ser usado para acessar 11.y.y.104(BC4) seja o link entre R6 e BC4. Se o link entre R6 e BC4 falhar, não haverá rota disponível para obter os pacotes IP entre 11.x.x.141 e 11.y.y.104 para que o SlaveClock não receba Anúncios do BC4 e o BMCA selecione BC3 como o relógio pai. Consulte esta imagem.

Opção 2. Filtros IP

Todos os roteadores suportam algum nível de filtragem de IP. Os filtros podem ser usados para proteger o plano de controle do roteador contra mensagens indesejadas. Eles podem ser usados nesse caso para controlar a aceitação de mensagens PTP em um subconjunto das interfaces de roteamento.

Nesse caso, o R6 seria configurado para proteger o SlaveClock de mensagens PTP que estejam tomando a rota errada. Na interface em R6 voltada para BC3, um filtro pode ser aplicado para permitir mensagens somente para a porta UDP 319 ou 320 se o endereço de origem corresponder ao do processo PTP em BC3. Qualquer mensagem originada de BC4 recebida nessa interface seria descartada. Consulte esta imagem.

Opção 3. Processamento BC de todas as mensagens PTP

Um BC pode encerrar todas as mensagens PTP recebidas em qualquer uma de suas portas para todos os domínios usados pelo BC. Em seguida, as mensagens PTP podem ser descartadas ou encaminhadas com base em decisões dentro do próprio processo PTP. As opções podem ser descartar a mensagem se o endereço de destino da mensagem PTP não for um endereço de propriedade do BC ou entregá-la ao mecanismo de encaminhamento para ser enviada adiante ao destino. O último caso pode ser usado se a mensagem PTP for para um domínio diferente do BC. Também neste último caso, o elemento de rede que contém o BC também pode atualizar o campo de correção de quaisquer mensagens de evento encaminhadas para compensar a extração e o processamento de mensagens PTP, ou seja, suportar a função de relógio transparente para essas mensagens. A extração de mensagens do plano IP pode ser realizada se o roteador suportar o roteamento baseado em políticas de pacotes IP.

Este exemplo é mostrado nesta imagem.

Opção 4. Uso do mecanismo Time to Live (TTL) do transporte IP:

Um nó PTP pode enviar pacotes PTP com o cabeçalho IP/Transport carregando um campo TTL definido para o número mínimo de saltos de roteamento necessários para alcançar a porta PTP do peer com a qual ele tem um contrato PTP. Em uma rede típica não sensível a PTP que tem roteadores não cientes entre MasterClock e SlaveClock, se o número de roteadores não cientes a PTP for maior que o valor TTL da mensagem PTP, a mensagem PTP será descartada por um dos roteadores não cientes a PTP. Isso pode ser usado para limitar o número de saltos IP percorridos por pacotes PTP entre roteadores adjacentes e evitar a comunicação através de caminhos mais longos indesejados.

Esse comportamento pode ser por porta PTP ou por relógio PTP e é específico da implementação. Supõe-se que, em tal topologia de anel, o roteamento IP terá o cuidado de garantir que um caminho mais curto para o PTP MasterClock seja considerado como uma rota melhor do que o caminho mais longo em torno do anel.

Por exemplo, se um SlaveClock tem um MasterClock diretamente conectado que também pode ser alcançado por um caminho mais longo, ele pode usar o valor TTL de 1 para garantir que os pacotes PTP alcancem o MasterClock apenas por meio do caminho diretamente conectado, em vez do caminho mais longo ao redor do anel.

Algoritmo Servo

Descrição dos modos:

• Modo de Execução Livre:

O relógio PTP nunca foi sincronizado com uma origem de tempo e não está no processo de sincronização com uma origem de tempo.

• Modo de aquisição:

O relógio PTP está em processo de sincronização com uma origem de tempo. A duração e a funcionalidade deste modo são específicas da implementação. Este modo não é necessário na implementação.

• Modo Freq/Phase Bloqueado:

Bloqueio de Fase - O relógio PTP é sincronizado de fase com uma origem de tempo e está dentro de alguma precisão interna aceitável.

Bloqueio de frequência - O relógio é sincronizado com uma fonte de tempo e está dentro de alguma precisão interna aceitável.

Em relação ao estado da porta PTP definido em [IEEE 1588], um relógio estará no modo Bloqueado se houver uma porta PTP no estado SLAVE.

• Modo de espera:

O relógio PTP não está mais sincronizado com uma fonte de tempo e está usando informações obtidas enquanto estava sincronizado anteriormente ou outras fontes de informações ainda estavam disponíveis, para manter o desempenho dentro da especificação desejada ou não podem manter o desempenho dentro da especificação desejada. O nó pode depender exclusivamente de suas próprias instalações para o período remanescente ou pode usar algo como uma entrada de frequência da rede para obter um período remanescente de tempo e/ou fase.

Exemplo de configuração para 8275.1/8275.2 no NCS 540 (Cisco IOS XR)

O roteador permite a capacidade de selecionar fontes separadas para frequência e hora do dia (ToD). A seleção de frequência pode ser entre qualquer fonte de frequência disponível para o roteador, como BITS, GPS, SyncE ou PTP IEEE 1588. A seleção ToD é entre a origem selecionada para frequência e PTP, se disponível (a seleção ToD é de GPS, DTI ou PTP). Isso é conhecido como modo híbrido, onde uma fonte de frequência física (BITS ou SyncE) é usada para fornecer sincronização de frequência, enquanto o PTP é usado para fornecer sincronização ToD.

SyncE (para transferência de frequência) e ptp (transferência de fase/horário do dia) podem ser usados juntos na rede durante a implantação do 8275.1 para obter maior precisão (chamado de modo híbrido e é o único modo suportado para o NCS a partir da versão 7.3.x)

O atributo de prioridade local não é transmitido em mensagens de anúncio. Este atributo é utilizado como elemento de desempate no algoritmo de comparação do conjunto de dados, no caso de todos os outros atributos anteriores dos conjuntos de dados comparados serem iguais

8275.1 :

	Relógio de limite
	Configuração	Explicação
PTP	PTP
	Relógio
	domínio 24
	profile g.8275.1 clock-type T-BC	O perfil 8275.1 está sendo usado com a função de relógio para ser o relógio de limite de telecomunicações T-BC
	!
	profile T-BC-MasterClock	Defina uma função para a porta ptp.
	multicast target-address ethernet 01-80-C2-00-00-0E	Um endereço multicast não encaminhável está sendo usado (opcional)
	Ethernet de transporte	o transporte ethernet está sendo usado
	estado da porta MasterClock-only	o estado da porta a ser usada é somente MasterClock
	sync frequency 16 (frequência de sincronização)	Pacotes síncronos serão enviados com uma frequência de pacotes por segundo
	frequência de anúncio 8	Os pacotes de anúncio serão enviados com uma frequência de pacotes por segundo
	delay-request frequency 16	Os pacotes Delay_Req serão enviados com uma frequência de pacotes por segundo
	!
	profile T-BC-SLAVE	Defina uma função para a porta ptp.
	multicast target-address ethernet 01-80-C2-00-00-0E	Um endereço multicast não encaminhável está sendo usado (opcional)
	Ethernet de transporte	o transporte ethernet está sendo usado
	port state SlaveClock-only	o estado da porta a ser usada é SlaveClock apenas
	sync frequency 16 (frequência de sincronização)	Pacotes síncronos serão enviados com uma frequência de pacotes por segundo
	frequência de anúncio 8	Os pacotes de anúncio serão enviados com uma frequência de pacotes por segundo
	delay-request frequency 16	Os pacotes Delay_Req serão enviados com uma frequência de pacotes por segundo
	!
	!
	interface TenGigE0/0/0/18	Interface MasterClock. Porta conectada ao SlaveClock de downstream
	PTP	ptp habilitado para esta porta
	profile T-BC-MasterClock	A função definida pelo usuário é chamada nesta porta PTP
	local-priority 120	atributo localPriority usado como desempate no algoritmo de comparação de conjunto de dados, caso todos os outros atributos anteriores dos conjuntos de dados que estão sendo comparados sejam iguais
	!
	!
	interface TenGigE0/0/0/19	Interface SlaveClock. Porta conectada ao MasterClock de upstream
	PTP	ptp habilitado para esta porta
	profile T-BC-SLAVE	A função definida pelo usuário é chamada nesta porta PTP
	local-priority 130
	!
	!
SyncE	sincronização de frequência	Habilitando globalmente
	opção 1 de ITU-T de qualidade	O QL do relógio recebido é de acordo com a opção 1 do itu-t
	alterações de seleção de log
	!
	interface TenGigE0/0/0/19	Interface SlaveClock. Porta conectada ao MasterClock de upstream
	sincronização de frequência	Habilitar syncE na interface
	entrada de seleção	Interface no estado SlaveClock para SyncE
	prioridade 15	significativo localmente. gerenciar a seleção do relógio alterando a prioridade das fontes de relógio
	wait-to-restore 0	A quantidade de tempo que o roteador aguarda antes de incluir uma origem de relógio Ethernet síncrona recentemente ativa na seleção de relógio. O valor padrão é de 300 segundos
	!
	interface TenGigE0/0/0/18	Interface MasterClock. Porta conectada ao SlaveClock de downstream
	sincronização de frequência	Habilitar syncE na interface
	wait-to-restore 0	A quantidade de tempo que o roteador aguarda antes de incluir uma origem de relógio Ethernet síncrona recentemente ativa na seleção de relógio. O valor padrão é de 300 segundos
	GrãoMestreRelógio
	Configuração	Explicação
PTP	PTP	Habilitando o ptp globalmente
	relógio
	domínio 24
	profile g.8275.1 clock-type T-GM	O perfil 8275.1 está sendo usado com a função de relógio para ser T-GM telecom grand MasterClock
	!
	profile T-MasterClock	Defina uma função para a porta ptp.
	multicast target-address ethernet 01-80-C2-00-00-0E	Um endereço multicast não encaminhável está sendo usado (opcional)
	Ethernet de transporte	o transporte ethernet está sendo usado
	estado da porta MasterClock-only	o estado da porta a ser usada é somente MasterClock
	sync frequency 16 (frequência de sincronização)	Pacotes síncronos serão enviados com uma frequência de pacotes por segundo
	frequência de anúncio 8	Os pacotes de anúncio serão enviados com uma frequência de pacotes por segundo
	delay-request frequency 16	Os pacotes Delay_Req serão enviados com uma frequência de pacotes por segundo
	!
	!
	interface TenGigE0/0/0/18	Interface MasterClock. Porta conectada ao SlaveClock de downstream
	PTP	ptp habilitado para esta porta
	profile T-MasterClock	A função definida pelo usuário é chamada nesta porta PTP
	local-priority 120	atributo localPriority usado como desempate no algoritmo de comparação de conjunto de dados, caso todos os outros atributos anteriores dos conjuntos de dados que estão sendo comparados sejam iguais
	!
	!
	!
SyncE	sincronização de frequência	Habilitando globalmente
	opção 1 de ITU-T de qualidade	Para configurar as opções de nível de qualidade (QL) do ITU-T. A opção 1 do ITU-T também é o padrão
	alterações de seleção de log	ativar registro
	!
	interface TenGigE0/0/0/18	Interface MasterClock. Porta conectada ao SlaveClock de downstream
	sincronização de frequência	Habilitar syncE na interface
	wait-to-restore 0	A quantidade de tempo que o roteador aguarda antes de incluir uma origem de relógio Ethernet síncrona recentemente ativa na seleção de relógio. O valor padrão é de 300 segundos
	SlaveClock
	Configuração	Explicação
PTP	PTP	Habilitando o ptp globalmente
	relógio
	domínio 24
	profile g.8275.1 clock-type T-TSC	O perfil 8275.1 está sendo usado com a função de relógio para ser T-TSC telecom SlaveClock
	!
	perfil T-SLAVE	Defina uma função para a porta ptp.
	multicast target-address ethernet 01-80-C2-00-00-0E	Um endereço multicast não encaminhável está sendo usado (opcional)
	Ethernet de transporte	o transporte ethernet está sendo usado
	port state SlaveClock-only	o estado da porta a ser usada é SlaveClock apenas
	sync frequency 16 (frequência de sincronização)	Pacotes síncronos serão enviados com uma frequência de pacotes por segundo
	frequência de anúncio 8	Os pacotes de anúncio serão enviados com uma frequência de pacotes por segundo
	delay-request frequency 16	Os pacotes Delay_Req serão enviados com uma frequência de pacotes por segundo
	!
	!
	interface TenGigE0/0/0/19	Interface SlaveClock. Porta conectada ao MasterClock de upstream
	PTP	ptp habilitado para esta porta
	perfil T-SLAVE	A função definida pelo usuário é chamada nesta porta PTP
	local-priority 120	atributo localPriority usado como desempate no algoritmo de comparação de conjunto de dados, caso todos os outros atributos anteriores dos conjuntos de dados que estão sendo comparados sejam iguais
	!
	!
	!
SyncE	sincronização de frequência	Habilitando globalmente
	opção 1 de ITU-T de qualidade	Para configurar as opções de nível de qualidade (QL) do ITU-T. A opção 1 do ITU-T também é o padrão
	alterações de seleção de log	ativar registro
	!
	interface TenGigE0/0/0/19	Interface SlaveClock. Porta conectada ao MasterClock de upstream
	sincronização de frequência	Habilitar syncE na interface
	entrada de seleção	Interface no estado SlaveClock para SyncE
	prioridade 15	significativo localmente. gerenciar a seleção do relógio alterando a prioridade das fontes de relógio
	wait-to-restore 0	A quantidade de tempo que o roteador aguarda antes de incluir uma origem de relógio Ethernet síncrona recentemente ativa na seleção de relógio. O valor padrão é de 300 segundos
	!

8275.2 :

	Relógio de limite
	Configuração	Explicação
PTP	PTP
	relógio
	domínio 44
	profile g.8275.2 clock-type T-BC	O perfil 8275.2 está sendo usado com a função de relógio para ser o relógio de limite de telecomunicações T-BC
	!
	profile T-BC-MasterClock	Defina uma função para a porta ptp.
	multicast target-address ethernet 01-80-C2-00-00-0E	Um endereço multicast não encaminhável está sendo usado (opcional)
	transport ipv4	o transporte ethernet está sendo usado
	estado da porta MasterClock-only	o estado da porta a ser usada é somente MasterClock
	sync frequency 16 (frequência de sincronização)	Pacotes síncronos serão enviados com uma frequência de pacotes por segundo
	frequência de anúncio 8	Os pacotes de anúncio serão enviados com uma frequência de pacotes por segundo
	delay-request frequency 16	Os pacotes Delay_Req serão enviados com uma frequência de pacotes por segundo
	!
	profile T-BC-SLAVE	Defina uma função para a porta ptp.
	multicast target-address ethernet 01-80-C2-00-00-0E	Um endereço multicast não encaminhável está sendo usado (opcional)
	transport ipv4	o transporte ethernet está sendo usado
	port state SlaveClock-only	o estado da porta a ser usada é SlaveClock apenas
	sync frequency 16 (frequência de sincronização)	Pacotes síncronos serão enviados com uma frequência de pacotes por segundo
	frequência de anúncio 8	Os pacotes de anúncio serão enviados com uma frequência de pacotes por segundo
	delay-request frequency 16	Os pacotes Delay_Req serão enviados com uma frequência de pacotes por segundo
	!
	!
	interface TenGigE0/0/0/18	Interface MasterClock. Porta conectada ao SlaveClock de downstream
	PTP	ptp habilitado para esta porta
	profile T-BC-MasterClock	A função definida pelo usuário é chamada nesta porta PTP
	local-priority 120	atributo localPriority usado como desempate no algoritmo de comparação de conjunto de dados, caso todos os outros atributos anteriores dos conjuntos de dados que estão sendo comparados sejam iguais
	!
	!
	interface TenGigE0/0/0/19	Interface SlaveClock. Porta conectada ao MasterClock de upstream
	ip address 10.0.0.1 255.255.255.252
	PTP	ptp habilitado para esta porta
	profile T-BC-SLAVE	A função definida pelo usuário é chamada nesta porta PTP
	local-priority 130
	MasterClock ipv4 10.0.0.2 255.255.255.252	Mencione explicitamente o IP MasterClock
	!
	GrãoMestreRelógio
	Configuração	Explicação
PTP	PTP	Habilitando o ptp globalmente
	relógio
	domínio 44
	profile g.8275.2 clock-type T-GM	O perfil 8275.1 está sendo usado com a função de relógio para ser T-GM telecom grand MasterClock
	!
	profile T-MasterClock	Defina uma função para a porta ptp.
	multicast target-address ethernet 01-80-C2-00-00-0E	Um endereço multicast não encaminhável está sendo usado (opcional)
	transport ipv4	o transporte ethernet está sendo usado
	estado da porta MasterClock-only	o estado da porta a ser usada é somente MasterClock
	sync frequency 16 (frequência de sincronização)	Pacotes síncronos serão enviados com uma frequência de pacotes por segundo
	frequência de anúncio 8	Os pacotes de anúncio serão enviados com uma frequência de pacotes por segundo
	delay-request frequency 16	Os pacotes Delay_Req serão enviados com uma frequência de pacotes por segundo
	!
	!
	interface TenGigE0/0/0/18	Interface MasterClock. Porta conectada ao SlaveClock de downstream
	PTP	ptp habilitado para esta porta
	profile T-MasterClock	A função definida pelo usuário é chamada nesta porta PTP
	local-priority 120	atributo localPriority usado como desempate no algoritmo de comparação de conjunto de dados, caso todos os outros atributos anteriores dos conjuntos de dados que estão sendo comparados sejam iguais
	!
	!
	!
	SlaveClock
	Configuração	Explicação
PTP	PTP	Habilitando o ptp globalmente
	relógio
	domínio 44
	profile g.8275.2 clock-type T-TSC	O perfil 8275.1 está sendo usado com a função de relógio para ser T-TSC telecom SlaveClock
	!
	perfil T-SLAVE	Defina uma função para a porta ptp.
	multicast target-address ethernet 01-80-C2-00-00-0E	Um endereço multicast não encaminhável está sendo usado (opcional)
	transport ipv4	o transporte ethernet está sendo usado
	port state SlaveClock-only	o estado da porta a ser usada é SlaveClock apenas
	sync frequency 16 (frequência de sincronização)	Pacotes síncronos serão enviados com uma frequência de pacotes por segundo
	frequência de anúncio 8	Os pacotes de anúncio serão enviados com uma frequência de pacotes por segundo
	delay-request frequency 16	Os pacotes Delay_Req serão enviados com uma frequência de pacotes por segundo
	!
	!
	interface TenGigE0/0/0/19	Interface SlaveClock. Porta conectada ao MasterClock de upstream
	ip address 10.0.0.1 255.255.255.252
	PTP	ptp habilitado para esta porta
	perfil T-SLAVE	A função definida pelo usuário é chamada nesta porta PTP
	local-priority 120	atributo localPriority usado como desempate no algoritmo de comparação de conjunto de dados, caso todos os outros atributos anteriores dos conjuntos de dados que estão sendo comparados sejam iguais
	MasterClock ipv4 10.0.0.2 255.255.255.252	mencionar explicitamente o comando MasterClock ip
	!
	!
	!

Caso você não receba pacotes ESMC na interface ou se SyncE não estiver configurado na extremidade da porta, mas você ainda deseja habilitar o syncE. Você pode fazer isso definindo estaticamente o valor QL na interface e desabilitando o SSM.

SyncE	sincronização de frequência
	opção 1 de ITU-T de qualidade
	alterações de seleção de log
	!
	interface TenGigE0/0/0/19
	sincronização de frequência
	ssm disable
	quality receive exact itu-t option 1 PRC
	entrada de seleção
	prioridade 15
	wait-to-restore 0
	!

Para usar o modo Híbrido com 8275.2, use ‘physical-layer-frequency’ na interface. Isso habilita SyncE para frequência e ptp para fase.

Para habilitar o modo híbrido com 8275.2, ‘physical-layer-frequency’ deve ser configurado no ptp global.

PTP

relógio

domínio 44

profile g.8275.2 clock-type T-BC

!

82752 de perfil

transport ipv4

sync frequency 16 (frequência de sincronização)

frequência de anúncio 8

delay-request frequency 16

!

physical-layer-frequency

registro

servo events

!

!

Exemplo de topologia 8275.1:

Dispositivo A:

ptp

 clock

  domain 24

  profile g.8275.1 clock-type T-BC

 !

 profile T-BC-SLAVE

  multicast target-address ethernet 01-80-C2-00-00-0E

  transport ethernet

  port state SlaveClock-only

  sync frequency 16

  announce frequency 8

  delay-request frequency 16

 !

 profile T-BC-MasterClock

  multicast target-address ethernet 01-80-C2-00-00-0E

  transport ethernet

  port state MasterClock-only

  sync frequency 16

  announce frequency 8

  delay-request frequency 16

 !

!

frequency synchronization

 quality itu-t option 1

 log selection changes

!

interface TenGigE0/0/0/23

 description ***to PTP GM***

 ptp

  profile T-BC-SLAVE

 !

 frequency synchronization

  selection input

  priority 10

  wait-to-restore 0

!

!



interface TenGigE0/0/0/19

ptp

  profile T-BC-MasterClock

 !

 frequency synchronization

  wait-to-restore 0

 !

!

Dispositivo B:

ptp

 clock

  domain 24

  profile g.8275.1 clock-type T-BC

 !

 profile T-BC-SLAVE

  multicast target-address ethernet 01-80-C2-00-00-0E

  transport ethernet

  port state SlaveClock-only

  sync frequency 16

  announce frequency 8

  delay-request frequency 16

 !

 profile T-BC-MasterClock

  multicast target-address ethernet 01-80-C2-00-00-0E

  transport ethernet

  port state MasterClock-only

  sync frequency 16

  announce frequency 8

  delay-request frequency 16

 !

!

interface TenGigE0/0/0/23

 ptp

  profile T-BC-MasterClock

 !

!

interface TenGigE0/0/0/19

 ptp

  profile T-BC-SLAVE

 !

 frequency synchronization

  selection input

 !

!

Exemplo de topologia 8275.2:

Dispositivo A:

ptp

 clock

  domain 44

  profile g.8275.2 clock-type T-BC

 !

 profile T-BC-SLAVE

  multicast target-address ethernet 01-80-C2-00-00-0E

  transport ipv4

  port state SlaveClock-only

  sync frequency 16

  clock operation one-step

  announce frequency 8

  delay-request frequency 16

 !

 profile T-BC-MasterClock

  multicast target-address ethernet 01-80-C2-00-00-0E

  transport ipv4

  port state MasterClock-only

  sync frequency 16

  announce frequency 8

  delay-request frequency 16

 !

!

frequency synchronization

 quality itu-t option 1

 log selection changes

!

interface TenGigE0/0/0/23

 description ***to PTP GM***

 ptp

  profile T-BC-SLAVE

 !

 frequency synchronization

  selection input

  priority 10

  wait-to-restore 0

!

!

interface TenGigE0/0/0/19

ip address 10.0.0.1 255.255.255.252

 ptp

  profile T-BC-MasterClock

  MasterClock ipv4 10.0.0.2 255.255.255.252

 !

 frequency synchronization

  wait-to-restore 0

 !

!

Dispositivo B:

ptp

 clock

  domain 44

  profile g.8275.2 clock-type T-BC

 !

 profile T-BC-SLAVE

  multicast target-address ethernet 01-80-C2-00-00-0E

  transport ipv4

  port state SlaveClock-only

  sync frequency 16

  announce frequency 8

  delay-request frequency 16

 !

 profile T-BC-MasterClock

  multicast target-address ethernet 01-80-C2-00-00-0E

  transport ipv4

  port state MasterClock-only

  sync frequency 16

  announce frequency 8

  delay-request frequency 16

 !

!

interface TenGigE0/0/0/19

  mtu 9216

 ptp

  profile T-BC-SLAVE

 !

 frequency synchronization

  selection input

 !

!

Identificar e Solucionar Problemas do PTP

Alguns comandos show e descrevem suas saídas.

1. O status do servidor no final do algoritmo servo deve ser Phase_Locked. Você pode ver o para o fluxo de status do servo. Se o modo de servidor for Híbrido, o fluxo de SyncE também deve ser cuidado, pois o bloqueio de fase acontece somente após Freq_Lock. Se o dispositivo de execução de PTP for um MasterClock comum, a saída acima pode não ser válida, pois o algoritmo Servo não será executado e não precisará obter a sincronização de fase/frequência de outra fonte MasterClock.

O status do dispositivo não vai para LOCK, a menos que o deslocamento esteja dentro de um intervalo aceitável. Marque também a opção "Offset from MasterClock".

Status do dispositivo:

FREE-RUN/HOLDOVER: Não bloqueado para qualquer fonte de tempo. 
FREQ_LOCKED: Frequência sincronizada com MasterClock

PHASE_LOCKED: Frequência e fase sincronizadas com MasterClock

Modo de servidor:

Híbrido: use SyncE para sincronização de frequência. O PTP é usado somente para sincronização de fase.

Padrão: usar o PTP para sincronizar a frequência e a fase

Diferença de tempo observada pelo servo algoritmo b/w SlaveClock e MasterClock.

Contadores de carimbos de data/hora extraídos de pacotes PTP. Deve continuar aumentando.

Últimos carimbos de data/hora T1/T2/T3/T4 (seg.nanossegundos) extraídos de pacotes PTP. Deve estar perto um do outro e aumentar uniformemente.

T1/T4: Enviado por MasterClock, T2/T3: Calculado em SlaveClock

Deslocamento calculado com base nos carimbos de data/hora do PTP.

Ajustes grosseiros (setTime, stepTime) e finos (adjustFreq) feitos por um servo para se alinhar com o MasterClock.

3. show ptp interfaces brief mostra o estado da porta de saída. Deve ser o estado MasterClock/SlaveClock.

4. As quedas de pacotes por ptp devem ser significativamente baixas.

5. Verifique a razão de queda do pacote:

6. Os pacotes não alcançam o PTP.

Os pacotes atingem a NPU?

NCS (DNX) platforms: show controllers npu stats traps-all instance all location 0/0/CPU0  | inc 1588

RxTrap1588                                    0    71   0x47        32040   7148566              0

ASR9000 platform: show controller np counters <np> location 0/0/cpu0 | inc PTP

Check for PTP_ETHERNET / PTP_IPV4 counters

Packet drops at NPU (not specific to PTP)

NCS (DNX) platforms: show controllers fia diagshell <np> "diag counters g" location 0/0/cpu0

Shows Rx/TX path statistics along with any drops happening in the NPU 

ASR9000 platform: show drops all location <LC>

Verifique os pontos na SPP:

show spp node-counters location 0/0/cpu0    

# Check for any drop-counters incrementing

NCS (DNX) platforms: show spp trace platform common error last 20 location 0/0/cpu0

Dec 10 02:29:38.322 spp/fretta/err 0/0/CPU0 t2902 FRETTA SPP classify RX: 
Failed in dpa_punt_mapper; ssp: 0x1e, inlif: 0x2000, rif: 0x11; 
trap_code:FLP_IEEE_1588_PREFIX punt_reason:PTP-PKT pkt_type:L2_LOCALSWITCH rc: 
'ixdb' detected the 'fatal' condition 'Not found in database': No such file or directory

ASR9000 platforms:

SPP punt path is simpler in ASR9000 with no risk of a lookup failure.

Drops not expected during packet classification.

7. show ptp packet-counters <interface-id> mostra o fluxo do pacote. Certifique-se de que syncàDelay_ReqàDelay_Resp seja seguido (e Follow_Up se for um relógio de 2 etapas).

8. Verifique o(s) indicador(es) da interface selecionada.

9. Verifique o QL recebido. Na interface selecionada, o QLsnd será DNU para evitar loops. Para alterar sua preferência de interface, você pode alterar o atributo de prioridade, que é 100 por padrão.

10. Certifique-se de que "Output Driven by" seja a interface SyncE escolhida.

11. A saída show ptp foreign-MasterClocks brief é a lista de dispositivos ptp que participam do BMCA para se tornarem MasterClocks. Verifique os sinalizadores correspondentes para ver o MasterClock selecionado. Você pode ver mensagens de anúncio recebidas dessas portas através de show ptp packet-counters <interface-id>. O dispositivo com os melhores atributos ganhará o BMCA. Se várias portas tiverem os mesmos atributos, a prioridade local será o último desempate. No entanto, o estabelecimento automático de topologia também é possível com o ptp sem usar a prioridade local.

12. O Ptp não seleciona o MasterClock (BMCA) pretendido.

Verifique o relógio anunciado pelo nó remoto:

show ptp foreign-MasterClocks 

Interface TenGigE0/9/0/2 (PTP port number 1)

  IPv4, Address X.X.X.X, Unicast

    Configured priority: None (128)

    Configured clock class: None

    Configured delay asymmetry: None

    Announce granted:   every 16 seconds,  1000 seconds

    Sync granted:       every 16 seconds,  1000 seconds

    Delay-resp granted: 64 per-second,     1000 seconds

    Qualified for 4 hours, 50 minutes, 6 seconds

    Clock ID: 1

    Received clock properties:

      Domain: 44, Priority1: 128, Priority2: 128, Class: 6

      Accuracy: 0x21, Offset scaled log variance: 0x4e5d

      Steps-removed: 1, Time source: Atomic, Timescale: PTP

      Frequency-traceable, Time-traceable

      Current UTC offset: 38 seconds (valid)

    Parent properties:

      Clock ID: 1

      Port number: 1

Lista de MasterClocks qualificados e selecionados:

show ptp foreign-MasterClocks brief 

M=Multicast,X=Mixed-mode,Q=Qualified,D=QL-DNU,

GM=GrandMasterClock,LA=PTSF_lossAnnounce,LS=PTSF_lossSync

Interface         Transport Address                   Cfg-Pri  Pri1   State

----------------------------------------------------------------------------

Te0/0/0/12        Ethernet  008a.9691.3830            None     128    M,Q,GM

Verifique o relógio anunciado no MasterClock:

show ptp advertised-clock

Clock ID: 8a96fffe9138d8

Clock properties:

  Domain: 24, Priority1: 128, Priority2: 128, Class: 6

  Accuracy: 0xfe, Offset scaled log variance: 0xffff

  Time Source: Internal (configured, overrides Internal)

  Timescale: PTP (configured, overrides PTP)

  No frequency or time traceability

  Current UTC offset: 0 seconds

13. Ptp não sincronizando com MasterClock:

•Intended PTP MasterClock selected.

•PTP session established

•But not able to synchronize with the MasterClock

show ptp interface brief

Intf                    Port              Port            Line

Name              Number       State          Encap       State         Mechanism

--------------------------------------------------------------------------------

Te0/0/0/12        1            Uncalibrated Ethernet   up            1-step DRRM


OR occasional PTP flap in the field

Jul 31 09:29:43.114 UTC: ptp_ctrlr[1086]: %PLATFORM-PTP-6-SERVO_EVENTS : PTP Servo state transition from state PHASE_LOCKED to state HOLDOVER 

Jul 31 09:30:23.116 UTC: ptp_ctrlr[1086]: %PLATFORM-PTP-6-SERVO_EVENTS : PTP Servo state transition from state HOLDOVER to state FREQ_LOCKED 

ul 31 09:35:28.134 UTC: ptp_ctrlr[1086]: %PLATFORM-PTP-6-SERVO_EVENTS : PTP Servo state transition from state FREQ_LOCKED to state PHASE_LOCKED

14. Verifique se o PTP não foi sincronizado devido à perda de pacotes:

show ptp trace last 100 location 0/rp0/cpu0

Aug  1 02:35:01.616 ptp/ctrlr/det 0/RP0/CPU0 t18625 [BMC] Removed clock 0x8a96fffe9138d8 (Ethernet 008a.9691.3830) from node 0/0/CPU0(0x0) from BMC list

Aug  1 02:35:01.616 ptp/ctrlr/det 0/RP0/CPU0 t18625 [BMC] Updated checkpoint record for clock 0x8a96fffe9138d8 (Ethernet 008a.9691.3830) from node 0/0/CPU0(0x0): Checkpoint ID 0x40002f60

Aug  1 02:35:01.616 ptp/ctrlr/det 0/RP0/CPU0 t18625 [BMC] Inserted clock 0x8a96fffe9138d8 (Ethernet 008a.9691.3830) from node 0/0/CPU0(0x0) into BMC list at position 0

Aug  1 02:35:46.035 ptp/ctrlr/sum 0/RP0/CPU0 t18625 [Comms] Received BMC message from node 0/0/CPU0. Comms is active

Aug  1 02:35:46.035 ptp/ctrlr/det 0/RP0/CPU0 t18625 [BMC] Removed clock 0x8a96fffe9138d8 (Ethernet 008a.9691.3830) from node 0/0/CPU0(0x0) from BMC list

Aug  1 02:35:46.035 ptp/ctrlr/det 0/RP0/CPU0 t18625 [BMC] GrandMasterClock removed, local clock better than foreign MasterClock(s)

Aug  1 02:35:46.035 ptp/ctrlr/sum 0/RP0/CPU0 t18625 [Leap Seconds] GrandMasterClock lost

Aug  1 02:35:46.035 ptp/ctrlr/sum 0/RP0/CPU0 t18625 [Platform] Stopping servo

Aug  1 02:35:46.035 ptp/ctrlr/det 0/RP0/CPU0 t18625 [BMC] BMC servo stopped, BMC servo not synced

Aug  1 02:35:46.035 ptp/ctrlr/det 0/RP0/CPU0 t18625 [Comms] Started grandMasterClock message damping timer

Aug  1 02:35:46.035 ptp/ctrlr/sum 0/RP0/CPU0 t18625 [Platform] Sending SlaveClock update to platform. No grandMasterClock available

Aug  1 02:35:46.059 ptp/ctrlr/det 0/RP0/CPU0 t18625 [BMC] Received clock update from the platform. Clock active, not using PTP for frequency, using PTP for time. Current local clock is not a primary ref, sync state is 'Sync' and QL is 'Opt-I/PRC'

15. Verifique a saída de show ptp configuration-errors para qualquer erro de configuração.

Exemplos de capturas de pacotes de mensagens Sync, Announce, Delay_Req e Delay_Resp

A captura da mensagem de anúncio (8275.1) mostra as características do relógio transmitido:

A captura da mensagem Sync mostra a geração do carimbo de data/hora (uma etapa).

Informações Relacionadas

• https://www.itu.int/rec/T-REC-G.8275.1/en
• https://www.itu.int/rec/T-REC-G.8275.2/en
• Padrão IEEE para 1588v2
• https://www.cisco.com/c/en/us/td/docs/routers/asr9000/software/asr9k_r5-3/sysman/configuration/guide/b-sysman-cg-53xasr9k/b-sysman-cg-53xasr9k_chapter_01100.html
• Suporte Técnico e Documentação - Cisco Systems