要約

  • RFC 5133は2007年12月のProposed Standardで、RFC 4233を更新する。
  • RFC 4129はDUAのDLC Status Requestに管理メッセージtype 5を割り当てていた。
  • RFC 4233はIUAのTEI Query Requestにも同じ管理type 5を割り当てた。
  • class 0/type 5が二つの操作を表すため、ヘッダーだけでは区別できなかった。
  • RFC 5133はTEI Query Requestをtype 8で符号化するよう要求した。
  • 現在のIANA登録はDLC Status Requestを5、TEI Query Requestを8としている。
  • 登録の一意性は配備済み実装の更新や相互運用性を証明しない。
  • SCTP association成立はトランスポートの証拠であり、ASP ACTIVEやtype 8対応の証拠ではない。
  • RFC 4129はDUAのPPID 10を推奨するが、複合backhaulではIUAのPPID 1も許す。
  • SCTP自身はPPIDを直接解釈せず、PPIDは認証や意味の強制ではない。
  • ASSIGNEDはQ.921がTEIを割当済みとみなす状態で、加入者や機器の本人確認ではない。
  • 登録、build、設定、transport、wire、decode、response、link、serviceを別々に検証する必要がある。

フィールドがあることと、使ってよいことは違う

観測基盤は、見えるフィールドを保存したくなる。それ自体は正しい。危険なのは、保存した値にその操作が定義していない意味を与えることだ。TEI Queryは共通ヘッダーとIUAヘッダーから成るが、DLCIはSGによって無視されなければならない。

したがって、そのDLCIを「照会対象」と表示し、顧客や回線に結び付けるダッシュボードは、精密に見えてもプロトコル上の根拠を欠く。生の値として保持し、「この操作では解釈しない」と明示するのが正しい。

メッセージtypeの衝突は、この教訓の逆側を示す。意味を決めるべきフィールドが一意でなければ、受信側は設定や期待から意味を補うしかない。RFC 5133はその余地を減らすため、TEI Queryを5から8へ移した。

二つの仕様が同じ番地を使った

初期のRFC 3057にはTEI Queryがなかった。RFC 4129はDPNSS/DASS 2向けDUAを定義し、管理クラスでDLC Status Request=5、Confirm=6、Indication=7を導入した。その後RFC 4233がIUAにTEI Query Requestを追加し、同じ管理type 5を使用した。

class 0/type 5という一組のビットが、DLC状態照会とTEI照会の両方になった。受信者の意図推測では解決できない。メッセージが持っていない区別は、ログ解析の巧妙さから生まれない。

RFC 5133はTEI Queryをtype 8に変更し、IANAも現在その割当を示す。最小の修正だが、効果は明確だ。新しい規則に従うwire imageなら、操作を一意に選べる。

ただし、仕様は古い装置へ自動配信されない。能力交渉や移行期間、downgrade規則も追加されていない。規範が一意になった日と、fleetが一意になった日は別である。

PPIDは補助線であって境界壁ではない

RFC 4129はDUAにSCTP PPID 10、IUAに1を使う分離を推奨する。一方、ISDNとDPNSSを同じassociationでbackhaulする場合などに、DUAがIUAのPPIDを使うことも許す。またPPIDはSCTPが直接使用するのではなく、上位情報を識別するため一部のentityが利用し得ると説明する。

つまりPPIDは有用な文脈だが、SCTPが施行する型安全性ではない。許可された複合配備では同じ値を共有できる。設定ミスもあり得る。capture pipelineがPPIDを落とすこともある。内側のclass/typeが衝突したままなら、外側の任意ラベルだけに依存できない。

逆に、PPID 1とclass 0/type 8を観測すれば、現在の登録に沿うIUA TEI Queryという強い証拠になる。しかしそれは送信組織の認証、照会権限、受信build、応答完全性、サービス成功を意味しない。

associationが上がっていても、契約は一致しない

RFC 4233ではSCTP association、ASPの可用性、application trafficの有効性が別状態である。associationがupでもASP-INACTIVEならtrafficは停止している。interface identifierからassociation/streamへのmappingはASP状態で変わり、failover中に一時的に無効にもなり得る。

したがって「SCTP up」は必要なtransport receiptであるが、RFC 5133対応を含まない。移行試験ではpeer、association、stream、PPID、version、class、type、length、方向、両端build、parser branch、errorまたはTEI Status Indicationを一つの記録へ結ぶ。

Unsupported Message TypeとUnexpected Messageは違う。前者は型の未対応、後者は状態や手順上の不意を示す。無応答も成功ではない。silent discard、観測欠落、interface lookup失敗を区別できないからだ。

ASSIGNEDの主語はQ.921である

TEI StatusのASSIGNEDは、Q.921がそのTEIを割当済みとみなすという意味である。端末証明書、加入者名、物理的存在、契約関係、現在のdata link trafficを表さない。

この状態は運用上重要だ。ASPはsignaling準備やdata link確立要求の判断に使える。未知のTEIでlinkが確立した場合の確認にも使える。しかし状態を受け取ることとlinkを確立すること、signalingを通すこと、applicationが成功することは別の出来事だ。

完全な主張には、queryとresponse setの対応、interfaceと時刻、indicationの完全性、Q.921状態、Establish手順、signaling trace、最終service outcomeが必要になる。途中の不明を緑色で塗らない。

type 5への親切なfallback

新しいsenderがtype 8を送り、古いreceiverが拒否したとき、type 5で再試行するshimは便利に見える。しかしtype 5は衝突の原因そのものである。DUA contextではDLC Status Requestであり、PPID 1を共有する構成なら外側でも区別できない。

legacy対応が必要なら、対象peerを限定し、IUA-onlyを証明し、全fallbackを計測し、DUA/combined associationでは拒否し、終了日を設ける。type 5が誤ったhandlerへ入らないnegative testも必要だ。

見えない互換層は、最後の古い装置を温存するインセンティブになる。短期の可用性改善が、将来すべての障害解析へ曖昧さを課す。

一次資料が証明する範囲

RFC EditorとDatatrackerはRFC 5133の地位、日付、更新関係を示す。RFC 5133は衝突と5→8を示す。RFC 4129はDLC typeとPPID条件、RFC 4233はIUA header、error、TEI手順、ASP stateを示す。IANAは現在の割当、SCTP文書はtransportを示す。

これらは特定vendorの修正、実運用packet、端末identity、応答完全性、service resultを証明しない。標準は正しい問いを符号化できるようにした。現実の答えはrunning codeと観測から得る。

Sources