要約

  • RFC 9760 は企業 PTP のオプション、メッセージ方式、時刻源選出を共通化するが、時間性能の要件は規定しない。
  • Best TimeTransmitter Clock Algorithm は Announce の属性からドメイン内の役割を決める。選出は外部基準や経路の正しさを独立に証明しない。
  • 複数ドメイン、異なる経路、許可表、受信側測定、アプリ側記録を分離して初めて、ひとつの緑色表示を検証可能な証拠へ変えられる。

一秒ごとの正常が誤差を隠した

Announce は既定どおり一秒ごとに届いた。Clock Identity も親も変わらず、Best timeTransmitter は同じ Grandmaster のままだった。ところが Sync と Delay Request の物理経路が分かれ、片方向のキューだけが伸びていた。

RFC 9760 は、この状態を「選出失敗」とは呼ばない。Enterprise Profile は IEEE 1588-2019 の選択肢を絞り、End-to-End 遅延測定とメッセージ方式をそろえ、ドメイン内の参照を選ぶ。経路の非対称性を自動で測り切る仕様ではない。

選出状態が安定していることと、時刻誤差が小さいことは別の事実である。正しい運用は両方を記録し、どちらかをもう一方の代理にしない。

Profile は相互接続条件である

PTP Profile は、必須、許可、禁止の機能と属性値を定める。RFC 9760 は UDP 上の IPv4 または IPv6、End-to-End 方式、共通情報の multicast、受信者固有処理の限定的な unicast を組み合わせる。

金融ネットワークの動機として、Grandmaster に対し 100 マイクロ秒から 1 ナノ秒の精度需要が挙げられる。しかし本文は、この Profile が時間性能要件を定めないと明記する。Profile 適合は、ある機器同士が同じ文法で動ける証拠であり、現場の SLA を満たした証明ではない。

IANA のサービス名・ポート番号レジストリと IPv6 multicast address registry は、転送面の共通番号を調整する。登録された番号は、パケットが本物の PTP であることも、正しい時刻を運んだことも保証しない。

Announce が決めるのは相対順位

Announce は送信時計の属性を運ぶ。Best TimeTransmitter Clock Algorithm がそれらを比較し、ポート状態と時計ツリーを作り、ドメインの Grandmaster を決める。標準アルゴリズムに従うことで、結果を説明し再現しやすくなる。

しかし、アルゴリズムは外部アンテナや発振器を検査しない。許可された時計が誤った外部時刻を受け取っても、同じ identity と属性で選ばれ続けることがある。rogue ノードは選出入力そのものを操作しようとする。

RFC 7384 は、改ざん、spoofing、replay、rogue master による選出操作、遅延攻撃、Grandmaster の外部時刻源攻撃を別々に扱う。外部源への攻撃では PTP の正規ノードが偽の時刻を配るため、identity の一致は反証にならない。

送信状態には現在の UTC leap-second 値が必要で、受信側は Acceptable TimeTransmitter Table を使える。前者は候補資格、後者はローカル許可である。どちらも現在誤差の測定値ではない。

multicast と unicast は責務を分ける

Sync と Announce は multicast で送る。two-step clock の Follow-up も multicast である。Delay Request は multicast または unicast、Delay Response は要求と同じ方式になる。多数に共通する状態は一度配り、一台だけに必要な応答は個別化できる。

大規模環境では、他の受信者向け multicast を大量に捨てる負担を減らせる。それでも、受信者数は独立した時刻源の数ではない。同じ Sync を千台が受け取っても、その千台が基準を検証したことにはならない。

証拠には domain、Clock Identity、sequence、メッセージ方式、Correction Field、送受信アドレスを結合する必要がある。単独の Delay Response は計算の一部でしかない。

Clock Identity と IP は違う層にある

Transparent Clock は通過時間を測って correction を更新し、別の IP または Layer 2 source でパケットを送り直すことがある。RFC 9760 は、そのようなネットワークで address だけでなく 64-bit Clock Identity を追跡するよう求める。

IP は現在の転送地点を示す。Clock Identity は PTP 上の時計を示す。Acceptable Table はその時計を許すか決める。selected parent は今どの時計に従うか示す。同じ列に並べられても意味は異なる。

NAT はアドレスを隠し、利用できる topology を制限し得るが、実装詳細は Profile の範囲外である。受信アドレス、Clock Identity、中間時計、interface、domain を一つの custody chain に残さなければ、障害時にパケットと時計を結び直せない。

本物のパケットも遅らせられる

End-to-End の offset 計算は、往路と復路の one-way delay が等しいと仮定する。IP network では Sync と Delay Request が同じ物理経路を通る保証はない。RFC 9760 は可能なら経路を一致させるよう勧める一方、traffic engineering は範囲外とする。

片方向の queue、ECMP、policy routing、firewall を通れば、内容を変えずに時刻計算を偏らせられる。受信者は path delay を clock offset と解釈する。

RFC 8915 は NTP 用 NTS の仕様であり、この PTP Profile へ直接適用する文書ではない。それでも、真正な packet を非対称に遅らせる攻撃は内容を改変せず、暗号だけでは現実的に除去できないという境界を明示する。integrity と punctuality は別である。

往復 delay、correction、offset、variance、経路変更を一緒に残して初めて、正しい identity から誤った時刻が生まれた理由を説明できる。

複数ドメインは独立性の入口

同時に複数の Grandmaster を持つなら、それぞれ別 domain で動かす。leaf device は複数の PTP instance を比較または組み合わせられる。可能なら domain ごとに異なる network path を使うことも推奨される。

この冗長性は、healthy と報告する faulty transmitter、asymmetry、interception、manipulation、delay attack の範囲を狭める。ただし二つの domain が同じ GNSS antenna、switch、power、firmware、設定担当者を共有すれば、一つの原因で同時に誤る。

Boundary Clock は複数 domain を支援しても、それらの timing information を混ぜてはならない。leaf の ensemble と境界での再配布は異なる権限である。

NTP の運用指針である RFC 8633 は、十分な源、多様な reference clock、継続監視を求める。NTP と PTP の選択ロジックを同一視せず、「独立性は台数ではなく依存関係で決まる」という原則を参照すべきである。

許可と正確さを一つにしない

timeReceiver は rogue timeTransmitter がいても正常動作できなければならず、domain で Best ではない送信者には同期すべきでない。Acceptable Table はさらに許可済み identity へ候補を絞る。これは重要な admission control だが、許可済みの源が真である保証ではない。

RFC 9760 は追加 security mechanism を範囲外とし、保護機構のない PTP management message を使わないよう勧める。安全な標準管理として NETCONF を例示する。管理経路を認証しても、外部源や packet path の物理状態までは証明しない。

RFC 5905 の NTPv4 は別の source selection と clock discipline を持つ。独立確認に利用するなら、どの reference と path を共有するか記録する必要がある。プロトコル名の違いだけでは多様性にならない。

アプリケーションが最後の境界を決める

OS clock が正しくても、application は別の瞬間を記録できる。queue に入る前、buffer を出た後、database commit より前に timestamp を採れば、表示形式は正しくても業務イベントの順序を表さない。

RFC 8877 は timestamp format の epoch、precision、range、rollover を設計する指針を与える。表現の整合性は必要だが、時計の由来や capture point の証明ではない。

Heng Lu の現実レイヤーを使えば、RFC、registry、loaded profile、Announce、election、path、correction、servo、system clock、business event を混同せずに済む。running-code primacy は実際に動く clock process と network device を一次資料に戻す。最小初期仕様とローカルな将来判断は、相互接続の共通部分だけを固定し、精度と利用判断を現場へ残す。

Grandmaster が選ばれた事実は消すべきではない。ただし、その事実が語れる範囲も消してはならない。