PTP Next Steps

[troglobit]

This issue tracks known limitations and planned future work for the PTP/gPTP subsystem
introduced in v26.04. It is intended as a living reference for discussions about scope,
priority, and design. Items are grouped by theme; dependencies are called out explicitly.

---

Time source management (phc2sys / ts2phc / timemaster)

Phase 1 (silent PHC companion for BC/TC) landed in v26.04. The remaining phases require
new YANG and user-facing configuration.

Tool	Direction	Use case
phc2sys	PHC → system clock	OS timestamps follow PTP
phc2sys -s CLOCK_REALTIME	system → PHC	chrony/GPS feeds a ptp4l GM
ts2phc	PPS/GPS → PHC	dedicated GPS hardware, best accuracy
timemaster	all of the above	coordinated ensemble, avoids double-disciplining

Phase 2 — PHC → system clock (user-facing YANG)

Add infix-phc2sys.yang augmenting /ietf-system:system/clock with a phc-sync
presence container (source-instance, step-threshold, poll-interval). A second
Finit template phc2sys-sys@N runs phc2sys -a -rr to add CLOCK_REALTIME as a
sync target. Keep the Phase 1 phc2sys@N service separate so BC/TC PHC coherence
remains independent of any user decision to sync the system clock.

Caution: if chrony is also disciplining CLOCK_REALTIME the two servos will fight.
Emit a CLI warning; the proper fix is Phase 4.

Phase 3 — GM time source: ts2phc and phc2sys reverse

Two paths to discipline the PHC of a grandmaster instance:

• Path A — GPS with PPS (/dev/pps0): ts2phc → PHC → ptp4l GM (~tens of ns).
  Proposed infix-ts2phc.yang augment per-instance with source-type, pps-device,
  nmea-serial, pin-index. Finit template ts2phc@N.conf.

• Path B — NMEA/NTP only, no PPS hardware (~µs): chrony → CLOCK_REALTIME →
  phc2sys reverse → PHC → ptp4l GM. Add a direction leaf to the Phase 2
  phc-sync container (phc-to-system | system-to-phc).

Phase 4 — timemaster: coordinated multi-source time

timemaster conducts ptp4l + phc2sys + chrony as an ensemble, solving double-discipline
conflicts and providing automatic source fallback. Proposed YANG: a single presence
container time-coordination synthesized from existing ptp/ntp/ts2phc YANG data. When
enabled, standalone ptp4l@/phc2sys@/chrony plugins become no-ops; timemaster@
owns everything.

Prerequisite: Phase 2 must be stable first.

---

Additional PTP profiles

The profile enum in infix-ptp.yang is designed for extension — a new enum value, a
new branch in emit_profile_globals(), and documentation. Known candidates:

Automotive (AUTOSAR / OpenAlliance TC10)

Builds on gPTP (L2/P2P/majorSdoId=1) but replaces BMCA with static roles
(BMCA=noop, serverOnly/clientOnly, inhibit_announce, inhibit_delay_req).
linuxptp ships automotive-master.cfg and automotive-slave.cfg as reference.

Design note: automotive roles are port-level, not instance-level. A dedicated role
leaf on the port is likely cleaner than encoding master/slave into the instance profile.
Needs design work before adding.

Telecom G.8275.1 (L2 multicast) and G.8275.2 (UDP unicast)

ITU-T profiles with an alternative BMCA comparison algorithm (dataset_comparison G.8275.x), per-port local priorities (localPriority), and domain 24. G.8275.1 is L2;
G.8275.2 uses unicast negotiation over UDP — transport is not fully implied by profile
name alone. A standalone network-transport augment leaf alongside these enum values is
likely needed.

Both also require new YANG leaves with no standard equivalent today: localPriority
(per-port) and dataset-comparison (per-instance). The profile alone is not sufficient;
companion augments are required first.

IEEE 802.1DP (Aerospace / SAE AS6675-2025)

Standard is still maturing; linuxptp support is pending. The profile slot is reserved.
See the Emerging standards section below for hard prerequisites.

Power (IEEE C37.238)

linuxptp has partial support via power_profile.* options. Niche use case; low priority.

---

CMLDS (Common Mean Link Delay Service)

IEEE 1588-2019 §16.6. A shared link-delay service for multiple PTP instances on the same
physical link. linuxptp supports it via a two-process model (dedicated ptp4l in P2P
free-running mode + client instances using delay_mechanism COMMON_P2P).

Remaining work: cmlds@ Finit template, infix-ptp augment for server/client UDS
address pair on /ptp/common-services, and ptp.c wiring. The standard YANG container
exists but is deviated not-supported in Phase 1.

---

Advanced IEEE 1588-2019 features

• Unicast Negotiation (§16.1): TLV-based session negotiation for networks without
  multicast. ptp4l supports it; YANG nodes are deviated not-supported. Low priority for
  TSN/Ethernet use cases.

• Performance Monitoring (Annex J): 15-minute and 24-hour performance monitoring
  records. Requires persistent ring-buffer storage, a periodic collection daemon, and
  significant YANG coverage. pmc does not expose this directly.

• Grandmaster Cluster (§17.2): Faster GM selection from a pre-configured candidate
  set. Rarely used outside telecom profiles.

• Alternate Time Transmitter (§17.3): Non-master ports track alternate time
  transmitters for faster failover. Not in standard ptp4l configurations.

• Fault Log (§8.2.6): Structured fault-record-list and reset action. ptp4l does
  not expose a structured fault log via pmc; would require syslog parsing or a custom hook.

• sdoId full 12-bit support: ptp4l 4.4 only exposes majorSdoId (4 bits) via
  transportSpecific. The YANG sdo-id leaf (range 0–4095) is deviated not-supported.
  If minorSdoId becomes necessary, either patch ptp4l or add an infix-ptp:major-sdo-id
  leaf (range 0–15).

---

Observability

show ptp network — proper YANG/sysrepo modelling

The current show ptp network broadcasts a pmc discovery query from the CLI formatter
(cli-pretty) and is unavailable over NETCONF/RESTCONF. Two options:

• a) YANG action on the PTP instance: on-demand discovery, result as action output
  (clean, standard approach).
• b) Operational data with background polling: statd runs pmc -b 4 periodically,
  results cached in infix-ptp:network-topology.

Until this is modelled, show ptp network is a CLI-only debug hatch.

Timestamping capability opt-out leaf

Probing and reporting hardware timestamping capability landed in v26.04. Follow-on: add
infix-ptp:timestamping leaf with values auto (default), hardware (force, fail if
unavailable), software (force regardless). Useful when a driver incorrectly reports
hardware support but delivers broken timestamps.

---

Emerging standards

IEEE 802.1ASdm-2024 (Multi-Domain Amendment)

Formalises how multiple PTP instances share the same physical ports simultaneously
(domain multiplexing per port). Standardises CMLDS as the shared link-delay service and
is a required foundation for 802.1DP compliance.

IEEE P802.1DP / SAE AS6675-2025 — TSN for Aerospace

Targets replacement of ARINC 429/664 and MIL-STD-1553 with deterministic Ethernet.
Synchronous Type 1/2 bridges must support at least 3 simultaneous PTP instances on every
physical port (per 802.1ASdm).

Prerequisites before Infix can target Synchronous bridge compliance, in dependency order:

1. CMLDS in upstream linuxptp — hard prerequisite; three independent Pdelay exchanges
   per port is non-compliant.
2. PHC sharing across ptp4l processes — exclusive ownership model must change
   upstream before two ptp4l instances can co-own one PHC.
3. YANG model for CMLDS — reinstate the deviated /ptp/common-services/cmlds
   container once (1) is resolved.
4. infix-ptp:profile enum extension — add ieee802-dot1dp with the ratified
   transportSpecific value.

Track upstream linuxptp and the 802.1DP ratification in parallel; (1) and (2) are not
actionable in Infix until they land upstream.

---

Test infrastructure

• Regression fixtures: capture pmc output (yanger --capture) for offline unit
  testing of ieee1588_ptp.py — minimum: OC slave (E2E), OC GM, BC (multi-port),
  802.1AS slave, P2P TC.