要約

  • GAL 値 13 は転送のための通常ラベルではなく、例外的な関連チャネルの目印である。示された MPLS-TP の規則ではスタック最下部に置き、その後ろに ACH を置く。通常のユーザープレーン・パケットには現れず、二重に置かれず、受信者が GAL を根拠に別ノードへ転送してはならない。
  • ACH はバイナリ 0001 で始まり、バージョンと 16 ビットの Channel Type を持つ。Channel Type の相互運用上の意味は IETF レビュー済み仕様と IANA 登録によって定まり、登録されているだけで特定の受信装置が有効化済みであることや、送信者の利用が運用上許可されていることにはならない。
  • G-ACh はユーザートラフィックを運んではならない。擬似線、LSP、連結セグメント、セクションに共通の保守エンベロープを提供するが、OAM、シグナリング、管理プロトコルのセキュリティ、状態遷移、運用ポリシーまでは定義しない。

受信側は MPLS または擬似線のラベルを取り出した後、Channel Type を処理できない場合、範囲外の方法でサポートを示していない場合、ローカルで無効化した実験タイプである場合、GAL の直後の ACH の先頭 4 ビットが 0001 でない場合、または ACH バージョンを認識できない場合、その関連チャネル・パケットを破棄しなければならない。GAL は能力を自動的に交渉しない。RFC 5586 の LSP 例では、新しい G-ACh パケットを開始できるのは二つのラベルエッジルーターだけで、経路上のノードは処理と応答を行えるが、これは一般的な転送権限ではない。

RFC 7026 は ACH TLV を削除した。可変で予測しにくい形式と長さはハードウェア処理を難しくし、割り当て済みの Channel Type も TLV を使っていなかったためである。したがって、G-ACh メッセージの前に ACH TLV を置くことはできない。RFC 7214 は分散していた G-ACh レジストリを IANA の共通の場所へ統合し、汎用性が明確になるよう Channel Type レジストリの名称を変更したが、割り当て自体は変更していない。現行 IANA 表は IETF Review を採用し、保守、測定、シグナリング、管理の用途と専用の実験範囲を含む。

GAL と ACH は認証でも認可でもない。送信者の本人性を確認せず、能力を交渉せず、管理操作を許可せず、LSP を確立せず、転送権限を与えない。安全要件は各 Channel Type の仕様と運用者の方針に属する。特殊処理資源、輻輳、アプリケーション固有の防御も残る。資料にはベンダー別の実装率、現在の本番トラフィック量、有効化率、破棄頻度の定量値がないため、登録表から推測してはならない。

出典