tmnxPtpPeerConfigEntry
1.3.6.1.4.1.6527.3.1.2.74.2.3.1
The tmnxPtpPeerConfigEntry contains information pertaining to an
individual PTP 1588 peer.
Individual PTP peers are identified by the IP address of the peer PTP
clock.
If tmnxPtpClockClockType is 'ordinarySlave (1)', entries may be
created and deleted via SNMP set operations using tmnxPtpPeerRowStatus.
The tmnxPtpPeerRemoteMaster attribute will be created with a value of
'true', and the tmnxPtpPeerRemoteSlave attribute will be created with
a value of 'false'. Neither or these attributes may be subsequently
changed. These entries correspond to PTP grandmaster or boundary
clocks providing timing information to the local clock.
In order to delete an entry, tmnxPtpPeerAdminState must first be
set to 'outOfService (3)'.
If tmnxPtpClockClockType is 'ordinaryMaster (2)', entries are
automatically created upon receipt of PTP signaling packets requesting
unicast transmission of PTP packets. Entries cannot be created or
deleted via SNMP set operations. These entries correspond to PTP slave
boundary clocks receiving timing information from the local clock.
These entries are created by the system with tmnxPtpPeerRemoteMaster
set to 'false' and tmnxPtpPeerRemoteSlave set to 'true'.
If tmnxPtpClockClockType is 'boundary (3)', entries corresponding to
grandmaster or boundary PTP clocks providing timing to the local clock
may be created and deleted via SNMP set operations, in the same manner
as when tmnxPtpClockClockType is 'ordinarySlave (1)'.
As well, entries corresponding to slave or boundary PTP clocks
receiving timing from the local clock may be automatically created by
the system, in the same manner as when tmnxPtpClockClockType is
'ordinaryMaster (2)'.
For an individual entry, the value of tmnxPtpPeerRemoteMaster along
with tmnxPtpPeerRemoteSlave indicates the direction of flow of timing
information between the local PTP clock and the peer PTP clock.
There are three cases:
1) If tmnxPtpPeerRemoteMaster is 'true', and tmnxPtpPeerRemoteSlave
is 'false', the peer PTP clock is providing timing to the local
PTP clock.
In this case, PTP Announce, Sync, and Delay Reponse packets are
sent from the peer PTP clock to the local PTP clock, and PTP Delay
Request packets are sent from the local PTP clock to the peer PTP
clock.
This type of PTP peer may exist when tmnxPtpClockClockType is
either 'ordinarySlave (1)' or boundary (3)'.
2) If tmnxPtpPeerRemoteMaster is 'false', and tmnxPtpPeerRemoteSlave
is 'true', the local PTP clock is providing timing to the peer
PTP clock.
In this case, PTP Announce, Sync, and Delay Reponse packets are
sent from the local PTP clock to the peer PTP clock, and PTP Delay
Request packets are sent from the peer PTP clock to the local PTP
clock.
This type of PTP peer may exist when tmnxPtpClockClockType is
either 'ordinaryMaster (2)' or boundary (3)'.
3) If tmnxPtpPeerRemoteMaster and tmnxPtpPeerRemoteSlave are both
set to 'true', the local clock and remote PTP clock have a peer
relationship.
Timing information may flow in either direction, depending on the
decision of the PTP Best Master Clock Algorithm running on each
PTP clock.
This type of PTP peer may only exist when tmnxPtpClockClockType is
'boundary (3)'.
When tmnxPtpClockClockType is 'boundary (3)', a peer entry may be
changed from one that is only receiving timing from the local clock,
to one that may either receive or provide timing, by setting
tmnxPtpPeerRemoteMaster to 'true'.