Contents

Introduction

Informações de Apoio

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

Sincronização de relógio de rede

Sincronização de frequência

Sincronização de Fase

Sincronização de horário

SyncE

Princípio básico do SyncE

Canal de Mensagens de Sincronização Ethernet

Sincronização com LAG

PTPv2/1588v2

Princípio básico de trabalho do PTP

Funcionamento do PTP

Domínios PTP

Padrão de troca de mensagens

Vários tipos de pacotes

Tipos de dispositivos PTP

Estabelecer a hierarquia MasterClock-SlaveClock

Perfis

8275.1

8275.2

Algoritmo Servo

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

Solucionar problemas de PTP

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

Informações Relacionadas

Introduction

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 telecom 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 alternativos que é usado para amostra 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 com 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.) ao gerar o sinal de clock. Então, o ideal é que o relógio não seja completamente periódico, mas seja suficiente para a exigência de amostragem dos sinais de dados das interfaces.

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

- Uma opção é instalar um GPS em todas as estações base, o que é muito caro e menos seguro à medida que 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. Esta opção é muito econômica, uma vez que os dados já estão a ser transferidos por NEs e a utilização de NEs para a transferência de sinal de relógio irá torná-los mais baratos e mais seguros. No entanto, a qualidade do relógio pode não ser tão boa quanto a opção GPS anterior e varia no perfil/protocolo usado em 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 qualquer alteração/desvio na frequência ou fase da onda portadora ocorrer 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 segura, a mesma chave deve ser usada para desbloquear a caixa na extremidade do receptor. Se a chave da 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 à 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 chamada como a mesma taxa), sincronização de fase (ao mesmo tempo) e sincronização de horário (hora do dia).

Sincronização de frequência

Todas as NEs devem corresponder a frequência do 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 funciona na derivação da frequência dos pacotes de dados recebidos na interface (funciona na camada física) junto com os pacotes ESMC recebidos (um pacote por segundo aproximadamente) na interface que descreve a qualidade do relógio. Portanto, 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, de modo que haverá um fluxo de pacotes de controle e os pacotes serão afetados pelo congestionamento, o que aumenta o atraso.

Sincronização de Fase

A sincronização de fase é sobre o alinhamento desses sinais de 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 pela rede.

Sincronização de horário

A sincronização de tempo, também chamada de Hora do dia, simplesmente tem o mesmo tempo em todos os NEs. Ou seja, t_1=t_2.

O NTP e o PTP são usados para transferir informações de tempo na rede. Embora o NTP forneça precisão de milissegundo, o PTP pode fornecer precisão de até sub-microssegundo.

A sincronização de tempo e a sincronização de fase são frequentemente usadas de forma sinônima em redes, já que o PTP usado para 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 de clock 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 clock está presente no sinal de dados transmitido na porta. O SyncE funciona com base no princípio de processamento reverso do sinal recebido na porta Rx e obtendo as 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 mencionado anteriormente. O relógio que será distribuído na cadeia é designado relógio de referência primário (PRC) e todos os relógios na rede devem ser rastreáveis até 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 síncrono (EEC) de acordo com as recomendações do SyncE. O desempenho do relógio recuperado não dependerá da carga da rede, pois não sincroniza com nenhum pacote específico.

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

No SlaveClock NE, 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. O relógio é então enviado através do backplane para acessar a placa central de temporização do SlaveClock. Esta referência temporal torna-se então uma referência à CEE (também conhecida como referência de cronometragem por linha). Como indicado no SlaveClock NE, uma CEE pode aceitar referências de linha e externas, bem como a entrada de um oscilador local de ±4,6 ppm (utilizado em situações em que não existem referências de linha ou externas disponíveis). A partir desse ponto, o SlaveClock NE torna-se então o MasterClock NE para o próximo NE downstream, e a sincronização é transportada de nó para nó, onde cada nó participa da recuperação e distribuição.

Canal de Mensagens de Sincronização Ethernet

O ESMC (Ethernet Synchronization Messaging Channel) é um protocolo lento Ethernet definido pela ITU-T (ou seja, 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 de Sincronization Status Message (SSM), que é o nível de qualidade (QL) do relógio de transmissão. Por exemplo: Se o dispositivo upstream estiver em sincronização com um relógio PRC, o valor de QL recebido será QL-PRC e o valor de 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 do ESMC em um período de cinco segundos resulta no SSF=true (QL=QL=QL-FAILED). O valor padrão (inicial) para o QL é DNU (SSM=1111) e deve ser alterado somente quando um QL TLV válido é 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. Por isso, precisamos priorizar os links em conformidade para escolher o dispositivo upstream correto em relação aos saltos, links, etc.

A sincronização MasterClock-SlaveClock em vários NEs com várias entradas possíveis de sincronização 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 fonte de sincronização real para o relógio NE.

Sincronização com LAG

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

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

Idealmente, é suficiente executá-lo no link de membro único do pacote, mas, caso contrário, é deixado aos 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. Ele é chamado de Precision Time Protocol (PTP) para abreviar.

O IEEE 1588v1 aplica-se aos 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 temporal em redes de telecomunicações aumentou. Para satisfazer essa necessidade, o IEEE redigiu 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 a sincronização de frequência e fase em níveis de submicrossegundos, com recursos de distribuição de ToD por meio do mecanismo eficiente de trocas de pacotes

A principal 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 retardo de quadro (latência), variação de retardo de quadro (jitter de pacote) e perda de quadro. Mesmo com a melhor prática 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 fora de sequência e oscilações de rota.

Princípio básico de trabalho do PTP

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

Funcionamento do PTP

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

Ele especifica como os relógios em tempo real no sistema se sincronizam 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 que o MasterClock determina 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-se 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 supõe que as mensagens de Anúncio sejam enviadas periodicamente por uma porta e entregues a todas as outras portas dos relógios comuns ou de limite dentro de um caminho de comunicação. Se o caminho de comunicação consistir em mais de duas portas, suponha-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 em um escopo lógico chamado de domínio. Todas as mensagens PTP, conjuntos de dados, máquinas de estado e todas as outras entidades PTP estão sempre associadas a uma ID de domínio específica

O protocolo define o evento e as mensagens PTP gerais. As mensagens de evento são mensagens cronometradas, ou seja, um timestamp preciso (tempo gravado 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 no recebimento. As mensagens gerais não exigem timestamps 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 PTP e os conjuntos de dados estão associados a um domínio e, portanto, o protocolo PTP é independente para domínios diferentes.

Padrão de troca de mensagens

1. O MasterClock envia uma mensagem de sincronização para o SlaveClock e anota a hora em que foi enviado.

2. O SlaveClock recebe a mensagem Sync e anota a hora da recepção.

3. O MasterClock transmite ao SlaveClock o carimbo de data/hora através de:

- Incorporando o carimbo de data e hora na mensagem de sincronização. Isso exige algum tipo de processamento de hardware para obter a maior precisão e precisão.

- Incorporando o carimbo de data e hora em uma mensagem de acompanhamento.

4. O SlaveClock envia uma mensagem Delay_Req ao MasterClock e anota a hora em que foi enviado.

5. O MasterClock recebe a mensagem Delay_Req e anota a hora da recepção.

6. O MasterClock transmite ao SlaveClock o carimbo de data e hora incorporando-o em uma mensagem Delay_Resp.

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

A 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, por meio de assimetria de meios de transmissão, por bridges e roteadores, e em grandes sistemas pelos caminhos de encaminhamento e reverso atravessados por mensagens de eventos que seguem diferentes rotas através da rede. Os sistemas devem ser configurados e os componentes selecionados para minimizar esses efeitos, guiados pela precisão de temporização necessária. Em sistemas de sub-rede única com distâncias de alguns metros, a assimetria não costuma ser 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. Sincronização - Usado para sincronização do tempo entre MasterClock e SlaveClock. Em duas etapas, as mensagens de sincronização não exibem tempo, mas a hora será marcada no MasterClock e serão transportadas na mensagem de acompanhamento_up. Em uma etapa, a mensagem de sincronização levará tempo. Dispositivos/hardware antigos não podiam suportar medir e transportar o ponto de tempo de saída quando uma mensagem foi entregue por uma porta, portanto, duas etapas foram devido à limitação de hardware. Atualmente, o hardware pode gravar o ponto de tempo de saída e enviá-lo para dentro da mensagem de sincronização. Uma etapa é compatível com duas etapas.

2. Delay_Req - Uma mensagem Delay_Req é uma solicitação do nó de recebimento/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 data e hora no 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 porta a porta para determinar o atraso no link entre elas. É usado pelo relógio transparente P2P para calcular o atraso de 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:

- Anúncio - Esta mensagem é usada pelo Best MasterClock Algorithm (BMCA) para gerar a topologia MasterClock-SlaveClock. É usado para eleger o melhor MasterClock e mantê-lo no lugar.

- Follow_Up - Este tipo de mensagem é usado no modo de duas etapas. Ele leva tempo. (Sincronizar hora de saída no nó MasterClock) em sua mensagem.

- Delay_Resp - É usado para calcular o tempo de trânsito de MasterClock para SlaveClock. Ele transporta o tempo (hora de saída da mensagem Delay_Resp) na mensagem.

- Pdelay_Resp_Follow_Up - É semelhante à mensagem Follow_Up, mas é gerada por um relógio P2P transparente.

- Gerenciamento: Não faz parte da 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 cronometragem necessárias para sincronizar relógios comuns e de limite usando o mecanismo delay request-response.

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 retardo de peer. O retardo de 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 ordinários e de limite que implementam o mecanismo de retardo de peer podem ser sincronizados 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 e relógios de gerenciamento (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 dispositivos PTP

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

1. Relógio comum - Só pode ser um Grand MasterClock (GM) ou apenas um SlaveClock.

2. Relógio de limite - Pode ser SlaveClock e GM

3. Relógio transparente de ponta a ponta - O relógio transparente de ponta a ponta encaminha todas as mensagens como uma bridge, roteador ou repetidor normal. No entanto, para mensagens de eventos PTP, a ponte do tempo de residência, mostrada na Figura abaixo, mede o tempo de residência (o tempo que a mensagem leva para atravessar o relógio transparente) das mensagens de eventos 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 e hora gerado quando a mensagem de evento entra e sai do relógio transparente.

4. Relógio transparente ponto-a-ponto - Adiciona o tempo de residência, bem como o tempo de atraso de trânsito do link às mensagens ptp usando o mecanismo de retardo do peer (gera seus próprios pacotes delay-req-resp para calcular o retardo do link do peer).

5. Nó de gerenciamento (não 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 MasterClock, o conteúdo da mensagem Announce e o conteúdo dos conjuntos de dados associados ao relógio normal ou 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 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 mensagens de Anúncio). Os estados da porta que determinam a hierarquia do MasterClock-SlaveClock são os seguintes:

- INIT - A porta ainda não está pronta para participar do PTP.

- OUVINDO - Primeiro estado quando uma porta se torna pronta para participar do PTP: escutas de portas para PTP MasterClocks por um período (configurável)

- PRE-MasterClock - A porta está prestes a entrar no estado MasterClock.

- MasterClock - A porta fornece carimbos de data e hora para qualquer relógio SlaveClock/limite de escuta.

- DESCALIBRADO - A porta recebe timestamps de um MasterClock, mas o relógio do roteador ainda não está sincronizado com esse MasterClock

- SLAVE - A porta recebe timestamps 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á desligando esse relógio

Melhor algoritmo MasterClock

O melhor algoritmo MasterClock compara dados que descrevem dois relógios para determinar quais dados descrevem o relógio melhor. 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 do que o próprio relógio local. Os dados que descrevem um MasterClock estrangeiro estão contidos nos campos GrandMasterClock de uma mensagem de Anúncio.

O algoritmo de comparação do conjunto de dados é baseado em comparações de atributos em par 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 dos quais um MasterClock é selecionado

2. clockClass - Um atributo que define o rastreamento 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 pedidos mais detalhados entre relógios equivalentes de outros modos

6. clockIdentity - Um disjuntor 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 estrangeiro é usada quando duas mensagens de Anúncio refletem o mesmo MasterClock estrangeiro. A distância é indicada no campo Etapas removidas 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 inequivocamente um dos dois relógios como "melhor" ou "topologicamente melhor".

Perfis

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

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 PTP e membros do conjunto de dados

- Os mecanismos de transporte necessários, 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 alcançar a sincronização de frequência com PTP.

8275.x é usado para sincronização de horário/fase usando PTP.  O NCS5xx/55xx atualmente suporta 8265.1, 8275.1, 8275.2 e 8273.2.

O 8265.1 foi usado anteriormente para sincronização de clock 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 temporização total da rede.

Modelo de Sincronização:

O perfil G.8275.1 adota o modelo de sincronização salto a salto. Cada dispositivo de rede no caminho do relógio do servidor para o cliente sincroniza seu relógio local com os dispositivos upstream e fornece sincronização com 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:

As IDs de domínio de 24 a 43 podem ser usadas. O 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 tratar 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 necessários, 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, tanto o endereço multicast não encaminhável, 01-80-C2-00-00-0E, quanto o endereço multicast encaminhável, 01-1B-19-00-00-00, precisam ser suportados para conformidade com este perfil

Mensagens unicast/multicast:

Todas as mensagens são enviadas 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:

Este 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 de BMCA do perfil Telcom

Parâmetro

Descrição

Prioridade 1

NÃO usado em perfis de telecom

Classe de relógio

Medida da 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 do relógio do GM para referência primária?

p. ex.: com precisão de 25 ns.

Variância de log dimensionada de deslocamento (OSLV)

Medida de precisão do relógio. Quanto o clock-output varia quando não está sincronizado com outra fonte.

Prioridade 2

Prioridade definida pelo usuário no nó MasterClock se todos os parâmetros acima corresponderem

Prioridade de porta local

Prioridade definida pelo usuário por porta no DUT

identidade de relógio GM

ID de relógio do GrandMasterClock usado como um disjuntor de gravata

Etapas removidas

Caminho mais curto escolhido se GrandMasterClock estiver acessí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 neste 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 é criada após essa operação. Nesse 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 será criado sem exigir 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 de seu valor padrão permite criar manualmente a topologia de rede de sincronização, de forma semelhante à que as redes SDH (Synchronous Digital Hierarchy) são operadas normalmente 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 reconfiguração de 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 prioridade2:

A prioridade de atributo PTP2 é configurável neste 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 casos são para estudo posterior.

- Caso 1.

Os operadores podem configurar a prioridade de atributo PTP2 para tornar todos os T-BCs (Telecom Boundary Clock) rastreáveis para um Telecom Grand MasterClock (T-GM) ou rastreáveis 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 prioridade 2, cada T-BC selecionará o T-GM com o caminho mais curto. Se os dois T-GMs estiverem 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 a prioridade de atributo PTP2 para impedir que os T-BCs de uma rede upstream sincronizem com os T-BCs de uma rede downstream quando o T-GM estiver em falha.

Por exemplo, na figura, se todos os outros atributos PTP de todos os T-BCs forem iguais, e a prioridade de atributo PTP2 de todos os T-BCs for 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 estiverem 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 serão sincronizados 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 são conectados através 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 avanço e de inversão são entregues em links diferentes pertencentes ao LAG.

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

Este 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; a seguir, são apresentadas outras considerações.

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 corretamente 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 não compatíveis com PTP.

O uso do endereço multicast não encaminhável 01-80-C2-00-00-0E garante essa propriedade na maior parte do tempo (há 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 PTP não estiverem habilitadas em equipamentos de rede com reconhecimento de PTP), o uso desse endereço multicast impede a distribuição incorreta da sincronização, já que as mensagens PTP serão bloqueadas pelo equipamento de rede sem reconhecimento de PTP.

- Opção 2 - Uso do endereço multicast encaminhável 01-1B-19-00-00-00.

Alguns operadores de rede consideram que o uso de um endereço multicast encaminhável é mais flexível e que é preferível encaminhar as mensagens PTP para manter o link de sincronização em execução caso algum equipamento esteja configurado 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 a configuração incorreta e enviará alarmes.

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

8275.2

Esta recomendação define outro perfil de PTP para permitir a distribuição da fase e do tempo com o suporte de temporização parcial (PTS) da rede (ou seja, sem 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 é habilitada por padrão.

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

Domínios:

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

Melhores opções de algoritmo MasterClock:

Este perfil usa o BMCA alternativo.

Propriedades Opção de medição de retardo lPath (solicitação de retardo/resposta de retardo), estabelecimento automático de topologia e Considerações sobre o uso da prioridade2 são iguais ao perfil de telecom 8275.1

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

Ao usar a mensagem PTP sobre uma camada de transporte IP, há alguns aspectos do protocolo da camada 3 que precisam ser considerados. A camada PTP fornece mensagens para a camada IP com um endereço IP de destino. A camada IP 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 seguido 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 otimizados 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 do BC3 e do BC4. Depois de receber as mensagens de Anúncio de BC3 e BC4, o SlaveClock executará o BMCA e selecionará o BC4 como seu relógio pai com base no fato de que as etapas- o valor removido de BC4 é 1, em comparação com um valor de 3 para BC3 removido por etapas. O SlaveClock solicitaria mensagens de sincronização do BC4.

Se a conexão entre BC4 e R6 quebrar (consulte a Figura abaixo), o BC4 não é 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. O BC4 é mantido como o relógio pai porque ainda é considerado melhor pelo BMCA.

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

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

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

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

Opção 2. Filtros IP

Todos os roteadores suportam algum nível de filtragem IP. Os filtros podem ser usados para proteger o plano de controle do roteador contra mensagens indesejadas. Nesse caso, eles podem ser usados 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 das mensagens PTP que estão tomando a rota errada. Na interface do R6 para BC3, um filtro pode ser aplicado para permitir apenas mensagens para a porta UDP 319 ou 320 se o endereço de origem corresponder ao do processo PTP no BC3. Qualquer mensagem originada do 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 quaisquer domínios usados pelo BC. Em seguida, as mensagens PTP podem ser descartadas ou encaminhadas com base em decisões no 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á-lo ao mecanismo de encaminhamento a ser enviado para o 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 qualquer mensagem de evento encaminhado para compensar a extração e o processamento da mensagem 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/Transporte transportando um campo TTL definido para o número mínimo de saltos de roteamento necessários para alcançar a porta PTP peer com a qual ele tem um contrato PTP. Em uma rede típica sem reconhecimento de PTP com roteadores sem reconhecimento entre MasterClock e SlaveClock, se o número de roteadores sem reconhecimento de PTP for maior que o valor TTL da mensagem de PTP, a mensagem de PTP será liberada por um dos roteadores sem reconhecimento de PTP. Isso pode ser usado para limitar o número de saltos IP atravessados por pacotes PTP entre roteadores adjacentes e evitar a comunicação por 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, nessa topologia em anel, o roteamento IP cuidará de garantir que um caminho mais curto para o PTP MasterClock seja considerado uma rota melhor do que o caminho mais longo ao redor do anel.

Por exemplo, se um SlaveClock tiver um MasterClock diretamente conectado que também possa ser alcançado por um caminho mais longo, ele poderá usar o valor TTL de 1 para garantir que os pacotes PTP cheguem ao MasterClock somente através 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 fonte de tempo e não está no processo de sincronização com uma fonte de tempo.

- Modo de aquisição:

O relógio PTP está em processo de sincronização com uma fonte 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:

Phase Lock - O relógio PTP é sincronizado em fase com uma fonte de tempo e está dentro de alguma precisão interna aceitável.

Frequency Lock - (Bloqueio de frequência) O relógio é a frequência sincronizada a uma fonte de tempo e está dentro de alguma precisão interna aceitável.

Como se refere ao estado da porta PTP definido em [IEEE 1588], um relógio está no modo Bloqueado se houver uma porta PTP no estado SLAVE.

- Modo holdover:

O relógio PTP não está mais sincronizado com uma fonte de tempo e está usando informações obtidas enquanto ele 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 conseguem manter o desempenho dentro da especificação desejada. O nó pode depender apenas de suas próprias instalações para transferência ou pode usar algo como uma entrada de frequência da rede para obter uma transferência de tempo e/ou fase.

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

O roteador permite selecionar fontes separadas para frequência e hora do dia (ToD). A seleção de frequência pode ser feita entre qualquer fonte de frequência disponível para o roteador, como BITS, GPS, SyncE ou IEEE 1588 PTP. A seleção ToD está 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/hora do dia) podem ser usados juntos na rede enquanto se implanta 8275.1 para obter melhores precisões (chamadas de modo híbrido e são 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 é usado como um desempate no algoritmo de comparação do conjunto de dados, no caso de todos os outros atributos anteriores dos conjuntos de dados em comparação serem iguais

8275.1 :

Relógio de limite

Configuração

Explicação

ptp

ptp

Relógio

domínio 24

perfil g.8275.1 tipo de relógio T-BC

O perfil 8275.1 está sendo usado com função de relógio para ser um relógio de limite de telecom T-BC

!

perfil 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 ethernet

o transporte ethernet está sendo usado

port state MasterClock-only

o estado da porta a ser usado é somente MasterClock

frequência de sincronização 16

Os pacotes de sincronização 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

!

perfil 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 ethernet

o transporte ethernet está sendo usado

port state SlaveClock-only

o estado da porta a ser usado é apenas SlaveClock

frequência de sincronização 16

Os pacotes de sincronização 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 ativado para esta porta

perfil T-BC-MasterClock

A função definida pelo usuário é chamada nesta porta ptp

prioridade local 120

atributo localPriority usado como um desempate no algoritmo de comparação do conjunto de dados, caso todos os outros atributos anteriores dos conjuntos de dados em comparação sejam iguais

!

!

interface TenGigE0/0/0/19

Interface SlaveClock. Porta conectada ao MasterClock de upstream

ptp

ptp ativado para esta porta

perfil T-BC-SLAVE

A função definida pelo usuário é chamada nesta porta ptp

prioridade local 130

!

!

SyncE

sincronização de frequência

Ativando globalmente

quality itu-t option 1

QL do relógio recebido é conforme a opção 1 de 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

Ativar sincronização na interface

entrada de seleção

Interface no estado SlaveClock para SyncE

prioridade 15

localmente significativo.

gerenciar a seleção de relógio alterando a prioridade das fontes de relógio

wait-to-restore 0

A quantidade de tempo que o roteador espera antes de incluir uma fonte de tempo 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

Ativar sincronização na interface

wait-to-restore 0

A quantidade de tempo que o roteador espera antes de incluir uma fonte de tempo Ethernet síncrona recentemente ativa na seleção de relógio. O valor padrão é de 300 segundos

GrandMasterClock

Configuração

Explicação

ptp

ptp

Ativando o ptp globalmente

relógio

domínio 24

perfil g.8275.1 tipo de relógio T-GM

O perfil 8275.1 está sendo usado com função de relógio para ser T-GM telecom Grand MasterClock

!

perfil 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 ethernet

o transporte ethernet está sendo usado

port state MasterClock-only

o estado da porta a ser usado é somente MasterClock

frequência de sincronização 16

Os pacotes de sincronização 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 ativado para esta porta

perfil T-MasterClock

A função definida pelo usuário é chamada nesta porta ptp

prioridade local 120

atributo localPriority usado como um desempate no algoritmo de comparação do conjunto de dados, caso todos os outros atributos anteriores dos conjuntos de dados em comparação sejam iguais

!

!

!

SyncE

sincronização de frequência

Ativando globalmente

quality itu-t option 1

Para configurar as opções de nível de qualidade (QL) ITU-T. A opção 1 de 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

Ativar sincronização na interface

wait-to-restore 0

A quantidade de tempo que o roteador espera antes de incluir uma fonte de tempo Ethernet síncrona recentemente ativa na seleção de relógio. O valor padrão é de 300 segundos

RelógioSlave

Configuração

Explicação

ptp

ptp

Ativando o ptp globalmente

relógio

domínio 24

perfil g.8275.1 tipo relógio T-TSC

O perfil 8275.1 está sendo usado com 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 ethernet

o transporte ethernet está sendo usado

port state SlaveClock-only

o estado da porta a ser usado é apenas SlaveClock

frequência de sincronização 16

Os pacotes de sincronização 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 ativado para esta porta

perfil T-SLAVE

A função definida pelo usuário é chamada nesta porta ptp

prioridade local 120

atributo localPriority usado como um desempate no algoritmo de comparação do conjunto de dados, caso todos os outros atributos anteriores dos conjuntos de dados em comparação sejam iguais

!

!

!

SyncE

sincronização de frequência

Ativando globalmente

quality itu-t option 1

Para configurar as opções de nível de qualidade (QL) ITU-T. A opção 1 de 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

Ativar sincronização na interface

entrada de seleção

Interface no estado SlaveClock para SyncE

prioridade 15

localmente significativo.

gerenciar a seleção de relógio alterando a prioridade das fontes de relógio

wait-to-restore 0

A quantidade de tempo que o roteador espera antes de incluir uma fonte de tempo 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

perfil g.8275.2 tipo relógio T-BC

O perfil 8275.2 está sendo usado com função de relógio para ser um relógio de limite de telecom T-BC

!

perfil 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

port state MasterClock-only

o estado da porta a ser usado é somente MasterClock

frequência de sincronização 16

Os pacotes de sincronização 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

!

perfil 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 usado é apenas SlaveClock

frequência de sincronização 16

Os pacotes de sincronização 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 ativado para esta porta

perfil T-BC-MasterClock

A função definida pelo usuário é chamada nesta porta ptp

prioridade local 120

atributo localPriority usado como um desempate no algoritmo de comparação do conjunto de dados, caso todos os outros atributos anteriores dos conjuntos de dados em comparação sejam iguais

!

!

interface TenGigE0/0/0/19

Interface SlaveClock. Porta conectada ao MasterClock de upstream

endereço ip 10.0.0.1 255.255.255.252

ptp

ptp ativado para esta porta

perfil T-BC-SLAVE

A função definida pelo usuário é chamada nesta porta ptp

prioridade local 130

MasterClock ipv4 10.0.0.2 255.255.255.252

Mencione explicitamente o ip do MasterClock

!

GrandMasterClock

Configuração

Explicação

ptp

ptp

Ativando o ptp globalmente

relógio

domínio 44

perfil g.8275.2 tipo relógio T-GM

O perfil 8275.1 está sendo usado com função de relógio para ser T-GM telecom Grand MasterClock

!

perfil 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

port state MasterClock-only

o estado da porta a ser usado é somente MasterClock

frequência de sincronização 16

Os pacotes de sincronização 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 ativado para esta porta

perfil T-MasterClock

A função definida pelo usuário é chamada nesta porta ptp

prioridade local 120

atributo localPriority usado como um desempate no algoritmo de comparação do conjunto de dados, caso todos os outros atributos anteriores dos conjuntos de dados em comparação sejam iguais

!

!

!

RelógioSlave

Configuração

Explicação

ptp

ptp

Ativando o ptp globalmente

relógio

domínio 44

perfil g.8275.2 tipo relógio T-TSC

O perfil 8275.1 está sendo usado com 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 usado é apenas SlaveClock

frequência de sincronização 16

Os pacotes de sincronização 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

endereço ip 10.0.0.1 255.255.255.252

ptp

ptp ativado para esta porta

perfil T-SLAVE

A função definida pelo usuário é chamada nesta porta ptp

prioridade local 120

atributo localPriority usado como um desempate no algoritmo de comparação do conjunto de dados, caso todos os outros atributos anteriores dos conjuntos de dados em comparação sejam iguais

MasterClock ipv4 10.0.0.2 255.255.255.252

mencionar explicitamente o ip do MasterClock

!

!

!

Caso você não receba pacotes ESMC na interface ou se SyncE não estiver configurado na extremidade da porta, mas ainda assim desejar habilitar a sincronizaçãoE. Você pode fazer isso definindo estaticamente o valor de QL na interface e desativando o SSM.

SyncE

sincronização de frequência

quality itu-t option 1

alterações de seleção de log

!

interface TenGigE0/0/0/19

sincronização de frequência

ssm disable

qualidade de recepção exata itu-t opção 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’ sob a interface. Isso habilita o 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

perfil g.8275.2 tipo relógio T-BC

!

perfil 82752

transport ipv4

frequência de sincronização 16

frequência de anúncio 8

delay-request frequency 16

!

physical-layer-frequency

registro

eventos servo

!

!

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

!

!

Solucionar problemas de PTP

Alguns comandos show e descrevem suas saídas.

1. O status Servo no final do algoritmo servo deve ser Phase_Locked. Você pode ver o para o fluxo de status do servo. Se o modo Servo for Híbrido, o fluxo de SyncE também deverá ser cuidado quando o bloqueio de Fase ocorrer apenas após o Freq_Lock. Se o dispositivo de execução 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 será necessário sincronizar fase/frequência a partir de outra origem MasterClock.

O status do dispositivo não vai para LOCK a menos que o deslocamento esteja dentro de um intervalo aceitável. Verifique também "Deslocamento do MasterClock".

Status do dispositivo:

FREE-RUN/HOLDOVER: não bloqueado para nenhuma fonte de tempo.

FREQ_LOCKED: Frequência sincronizada para MasterClock

FASE_BLOQUEADO: Frequência e fase sincronizadas com o MasterClock

Modo servo:

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

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

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

Contadores de timestamps extraídos de pacotes PTP. Deve continuar crescendo.

Últimos timestamps T1/T2/T3/T4 (s.nanossec) extraídos de pacotes PTP. Devem estar próximos um do outro e aumentar uniformemente.

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

Deslocamento Calculado com base nos timestamps PTP.

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

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

4. O pacote descartado pelo ptp deve ser significativamente baixo.

5. Verifique o motivo da queda do pacote:

6. Pacotes não chegam ao PTP.

Os pacotes estão chegando à 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>

Verificar quedas no 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. Assegure-se de que a sincàDelay_ReqàDelay_Resp seja seguida (e Follow_Up se for um relógio de 2 etapas).

8. Verifique o sinalizador (S) 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 "Saída controlada por" seja a interface SyncE selecionada.

11. show ptp foreign-MasterClocks brief output é a lista de dispositivos ptp que participam do BMCA para se tornarem MasterClocks. Marque os sinalizadores correspondentes para ver o MasterClock selecionado. Você pode ver mensagens de anúncio recebidas dessas portas por meio 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 da 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. O Ptp não está sincronizando com o 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 oscilou 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 verificar se há erros 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 datador de 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