要約

  • TALI 2.0の実装は、moniメッセージで相手が2.0だと確認するまで、接続先を1.0として扱わなければならなかった。新しいopcodeの送信は、その確認に結び付いていた。
  • RFC 3094はTekelecのInformational提案であり、IESG注記はSIGTRAN標準化作業との関係と、IETFが技術的健全性や完全性を審査していないことを明示した。

境界はSS7メッセージを交換する前から存在する。RFC 3094が記述するTransport Adapter Layer Interface（TALI）は、回線交換網とIP網の間で信号を運ぶためにTekelecが提案したインターフェースである。Signaling GatewayはTCP/IP上でSCCP、ISUP、MTP関連メッセージを運び、管理機能や回線の動的登録も担う。文書にはメッセージ形式、タイマー、ピアの状態機械、TALI 1.0と2.0の動作が細かく書かれている。しかし、詳細な仕様書であることと、標準や配備された技術であることは別だ。RFCの冒頭はその点を隠していない。

IESG注記は、TALIをIETF SIGTRANワーキンググループが当時開発中だった標準化技術に対するベンダーの代替案と位置付ける。さらに、IETFは技術的健全性や完全性を審査しておらず、利用候補者は採用を決める前にSIGTRANの成果も検討するよう勧めている。これはTALIが不健全だと判定した、拒否した、あるいは使われなかったと証明した、という意味ではない。注記が示すのは審査の限界と比較の必要性だ。

TALIの最も具体的な工学上の課題は後方互換性である。1.0には簡単なバージョン識別方法がなかった。2.0は既存のmoni（monitor）メッセージを再利用し、データ先頭の12オクテットを固定のバージョンラベルにする。後続部分は実装固有の用途に残されるが、データ全体は200オクテットを超えてはならない。moniは往復時間測定などに使えるエコー機能も引き続き担う。

この短いラベルが送信可能な操作を左右する。接続時、2.0実装はfar_end_versionを1.0に初期化する。自分の版は通知できても、相手も同じ機能を持つと推定してはならない。受信したmoniを調べ、既知のバージョン文字列を認識する必要がある。識別メッセージが届かない、またはラベルが一致しない場合、相手は1.0として扱い続ける。

この状態値は、2.0で追加されたmgmt、xsrv、spclという三つのopcodeを制御する。1.0実装はそれらを無効なopcodeと見なし、直ちにソケットを切断する。したがって2.0ノードは、相手が2.0以上だと確認するまでは送信できない。相手が1.0なら、1.0の機能だけに戻る。RFCによれば、1.0実装は拡張されたmoniデータを無視し、従来のmonitor／acknowledgement交換を続けられる。互換性とはすべての機能を両方が理解する保証ではない。相手が拒否するopcodeを送らず、接続を使える状態に保つ規則である。

これは抽象的な互換性の標語ではなく、観測可能な制御面である。ローカル実装が版を通知し、遠端が宣言を返し、状態機械が観測を保持し、opcodeゲートがソケットを通せる機能を決める。仕様書の版番号やローカル設定だけでは、相手から届いた宣言の代わりにならない。

周辺の標準化史にも同じ慎重さが必要だ。RFC 2719はすでにSIGTRANのアーキテクチャを記述していた。その後の標準化文書はM2UA、M3UA、SUAなどの適応層を定義し、関連作業ではSCTPもトランスポートとして使われた。RFC 3094自身もSCTPを使う代替スタックを論じている。これらは関連する並行・後続の仕様化を示すが、TALIが置き換えられたこと、特定のネットワークが移行したこと、異なる実装同士が相互運用したことまでは証明しない。

2001年4月のRFC 3094はInformationalであり、インターネット標準を定めるものではないと明記している。出版、記述された機構、審査の境界はそれぞれ異なる事実だ。状態機械が詳しいことも、IESGが注意書きを付けたことも、配備や品質の結論にはならない。それには稼働実装、試験結果、運用記録、または観測されたトラフィックが必要である。

出典