累積誤差を排除した2代目PTP「IEEE 1588-2008」、LAN内機器での時間同期の精度を向上

　前回からは、LAN内のネットワークにつながった機器同士の時間の同期を取るのが目的の「PTP（Precision Time Protocol）」を紹介している。もっとも、PTPには以下3つの「IEEE 1588」しかなく、基本的には相互の互換性はない。

　今回は2代目PTPである「IEEE 1588-2008」について。

　PTPv1こと「IEEE 1588-2002」は、確かに想定通りの性能を発揮したものの、実際に使ってみると、いろいろと制約が多いことも明らかになってきた。具体的にはスケーラビリティと安定性・精度不足である。中でも特に、大規模ネットワークにおける問題解決を目指したのが、PTPv2ということになる。

　つまり、PTPv1ではマルチキャストを用いてSync Messageを送信するため、大規模ネットワークとなった時点で伝達遅延が問題になる。

　具体的に言えば、PTP MasterとPTP Slaveが1つのスイッチにぶら下がっているような環境であれば、それほど問題はない。

　ところがスイッチが多段で入り、しかもPTP MasterとSlaveの間でスイッチの数が変動するような環境では、伝達遅延に起因する精度の悪化が割と問題になりやすい。

　これは通常のL3スイッチが、方向性のある遅延が生じることが多く、またスイッチのレイテンシーが安定しないことにも起因する。

　解決策の1つが「BC（Boundary Clock）」という方法だ。図1はPTPv1の基本的な通信方式であるが、Boundary Clockは図2のように、途中に1段「PTP SlaveとしてもPTP Masterとしても動作するものを入れてやる」方法で、まずPTP Masterとの間で時刻合わせを行い、次いでターゲットのPTP Slaveに対して、自身がPTP Masterとなって時刻合わせを行う。

　これはこれで1つの解決策ではあるが、そもそもPTP MasterとBoundary Clockの間にも、わずかとはいえ誤差があるから、1段だけならともかく多段に積み重ねると誤差が蓄積していくことになり、これは好ましくない。

　また、PTPv1ではTCP/UDP IPのみが対象となっており、ほかのネットワークでは利用できないし、PTPv1ではプロトコルのオーバーヘッドが大きく、時間が掛かるという問題点もあった。

　PTPv1は、2002年11月にIEEEでの標準化が完了した（IECは2004年5月にIEC 61588としてこれを標準化した）ものの、実際に対応機器が出荷され始めたのは2003年末になってからのことだった。

　そして実際に使われ始めたことで、上述のようにさまざまな不都合が出てくることとなった。PTPv2のPARが出たのは2005年3月だから、製品出荷開始から1年半弱ということになる。意外に早い気もするのだが、それだけPTPv1への期待が高かった反面、不都合が気になった、というあたりかもしれない。

　PTPv2の技術的な検討は2007年2月に終了し、最終的には2008年3月に承認され、2008年7月に標準化が完了している。

　さてそのPTPv2、基本的な測定方法そのものはPTPv1と同じなのだが、あまりに変更点が多く、結果PTPv1とは全く互換性がなくなっている。まずプロトコルで言えば、以下のようにMessageの種類が5から10へ増えている。

　Delay_Req/Delay_Respに、新たにPdelay_Req/PDelay_Follow_Up/PDelay_Respが追加されたほか、PTPv1のSync MessageはPTPv2でSyncとAnnounceの2つのMessageに分割された。これをもう少し仔細に説明しよう。

　PTPv1では、Sync Messageが124Bytesと結構な大きさであった。PTPv2ではこれを44Bytesまで減らしている。PTPv1におけるSync Messageの詳細がTable 1、PTPv2がTable 2となるが、そもそもHeader部の構造が全く異なるし、PTPv2ではMessage BodyにはoriginTimestampしか入っていないことが分かる。

　もともと、PTPv1のSync Messageでは、「BMCA（Best Master Clock Algorithm）」と呼ばれるアルゴリズムを利用し、ネットワーク中で誰がPTP Masterなのかを判別するアルゴリズムを採用している。

　この関係で、PTP Masterの判別に必要な全ての情報がSync Message内へ格納されていた。PTPv2ではこのアルゴリズムが変わると同時に、Master判別は新しく追加されたAnnounceというMessage（Table 3）を利用することになった。

　PTPv1では、Syncを一定以上の頻度で送出するとネットワークトラフィックが増え、これがむしろ精度を落とす要因となっていたが、PTPv2ではSync Messageのサイズが最小限になったことで、より頻度を上げて送出することも可能になった。実際、802.1 ASのプロファイルではSync Messageはおおむね8ms間隔、一方のAnnounce Messageは1秒間隔で送出することになっている。

　また、対応するネットワークが増えたのもPTPv2の特徴である。IEEE 1588-2002（上）とIEEE 1588-2008（下）のAnnexの一覧を見ると、後者では以下の項目が増えている。

• IPv4/Ethernetに加えてIPv6/DeviceNet/ControlNet/PROFINETへのMappingの追加
• Profileの追加

　このうち、セキュリティオプションとcumulative frequency（Transport of cumulative frequency scale factor offset）はどちらも"experimental"となっていることからも分かるように、今後の拡張向けオプションとされる。

　大きく変わったのがTransparent Clockのサポートで、図3としてこれを簡単にまとめてみた。要するに、Boundary Clockを利用した場合には、ここで誤差が累積するので、もともとのPTP Masterのクロックをそのまま利用し、PTP Slaveの時刻を合わせるようにする仕組みだ。

　つまり、流れてきたパケットが何かを一切考慮せずにルーティングするスイッチングハブとは話が異なり、Transparent Clockの場合は、内部でパケットを蓄積している時間を計測し、それをSyncあるいはFollow-up MessageのCorrection Fieldに加算する（PTPv2 Headerの8Bytesのフィールド）。

　これを利用することで、複数のTransparent Clockを経由した場合にも累積の遅延時間が計測できるので、これを加味して補正が可能になるというわけだ。

　このTransparent Clockには、「E2E（End to End） TC」と「P2P（Peer to Peer） TC」の2種類がある。E2E TCは従来と同じく、SyncとDelay Request/Delay Responseを使って測定する方法である。一方のP2P TCはPTPv2で追加された新しい方式で、E2E TCの手順に加えてPSyncとPDelay Request/PDalay Responseを利用してする方式となる。

　図4がその手順で、Sync/Follow-upはPTP Masterと行うが、その後のDelay Request/Delay Response（と必要ならDelay Follow-up）は、Transparent Clockとの間で行う方法だ。この方式であっても、通信の遅延時間およびPTP Masterとの時間の差は問題なく計算できるので、これを元に補正できることになる。

　Syncの後は、最後のTransparent ClockとP2P Slaveの間で行うので、PTP Slaveの数が増えてもPTP Masterに負荷が掛かりにくいほか、PTP MasterとTransparent Clockとの間の経路が動的に変化しても再測定の必要がないのがP2P TC方式のメリットだ。ただ逆に、P2Pを利用したい場合は、全てをP2P TC対応にする必要がある。

　こうした工夫により、PTPv2ではPTPv1で見られた累積誤差の排除がかなり可能になり、PTPv1と比較して構成次第では1～2桁の精度向上が可能になったとされている。