RFC 10053が描くComputing-Aware Traffic Steering（CATS）のアーキテクチャと基本概念を整理する

ネットワーク・RFCカテゴリを表すパンダのイラスト ネットワーク・RFC

この記事について
この記事は、生成AIを活用した自動生成フローで作成しています。参照元の情報をもとに整理していますが、筆者による実機確認は行っていません。

検証ステータス：unverified（実機未確認）

RFC 10053は、ネットワークの状態だけでなくエッジやクラウド側の計算リソース（CPUや負荷状況など）の変動を考慮して動的に通信を振り分けるComputing-Aware Traffic Steering（CATS）の基本フレームワークを定めたInformational RFCです。本仕様では、単一サービスプロバイダのネットワーク内において、クライアントからのサービス要求を最適なサービスコンタクトインスタンスへ誘導するための機能エンティティや識別子、およびプレーン間の連携が定義されています。

CATSが策定された背景と従来のトラフィック制御の課題

近年のコンピューティングサービスは、単一の拠点から、地理的に分散した複数拠点（オンプレミスやクラウド事業者環境など）による協調構成へと移行しています。AR/VRなどの超低遅延が要求される没入型サービスにおいては、応答時間の短縮やリソースの枯渇防止が不可欠です。

しかし、従来のルーティングインフラでは、ルーティング観点で最も近いサイトへ静的に振り分けるか、あるいはネットワーク輻輳などの状態のみを考慮したディスパッチが行われる傾向にありました。このアプローチでは、接続先のサービス拠点側で計算資源が逼迫している場合や、拠点間で負荷の偏りが発生している場合に、適切な処理性能を維持できないという問題が生じます。

一次情報に記載されている通り、CATSは計算リソース（Compute/Storage）の動的な状態メトリクスとネットワーク状態の双方を入力とし、特定のリクエストを処理するのに適したインスタンスへトラフィックを導くトラフィックエンジニアリング手法です。これにより、特定拠点のリソース制限を動的に回避し、インフラ全体の最適な活用を図ることを目的としています。

CATSを構成する主要な識別子と基本概念

CATSフレームワークを理解する上で重要となるのが、論理的なサービスと物理的なインスタンスを分離して扱う概念モデルと識別子です。一次情報では以下の主要要素が規定されています。

1. 識別子（ID）の分類

  • CS-ID（CATS Service ID）
    クライアントがアクセス対象のサービスを識別するために使用するIDです。配置場所や背後で動作する複数のインスタンスを意識することなく、同一のサービス全体を代表します。グローバルな一意性までは求められませんが、CATSシステム内で衝突なく識別できる一意性が必要です。

  • CSCI-ID（CATS Service Contact Instance ID）
    特定のサービスコンタクトインスタンスを一意に識別するためのIDです。一次情報では内部構造やセマンティクスは限定されておらず、例としてユニキャストIPアドレスなどが挙げられています。

2. サービスを構成する機能的実体

  • サービスインスタンス（Service Instance）
    サービスのロジックに従って動作する計算リソースの集合体です。1つのサービスサイト内に1つまたは複数稼働します。

  • サービスコンタクトインスタンス（Service Contact Instance）
    クライアントと直接対向するフロントエンド機能です。クライアントからのサービス要求を直接受け取り、背後にある1つ以上のサービスインスタンスへ処理を振り分ける（ロードバランサのように機能する）役割を持ちます。クライアントやCATSネットワークのコンポーネントからは、このコンタクトインスタンスの背後にある内部構成は見えません。

  • サービスサイト（Service Site）
    1つまたは複数のサービスインスタンスを収容するノードまたはノード群の設置拠点です。

CATSアーキテクチャのプレーン設計と機能コンポーネント

一次情報では、CATSのネットワーク全体を「管理プレーン」「制御プレーン」「データプレーン」の3層に分類し、それぞれに専用の機能コンポーネントを配置しています。

各プレーンの責務

  • CATS Management Plane（管理プレーン）
    CATSに関わるネットワーク機器の監視、設定、保守を行います。

  • CATS Control Plane（制御プレーン）
    コンピューティングリソースおよびネットワークの情報に基づいてサービスのスケジューリングを実施します。パケットの転送方針を決定し、データプレーンへ通知します。

  • CATS Data Plane（データプレーン）
    パケットの分類（Classification）、選択されたパスに沿ったステアリング、および目的のサービスコンタクトインスタンスに向けた転送処理を担当します。

主要な機能コンポーネント

一次情報に記載されている主要なコンポーネントの役割は以下の通りです。

  • C-SMA（CATS Service Metric Agent）
    サービスサイトやサーバーのリソース情報、各サービスインスタンスの稼働状態を収集し、C-PSへ報告します。

  • C-NMA（CATS Network Metric Agent）
    ネットワークの能力および状態情報を収集し、C-PSへ報告します。

  • C-PS（CATS Path Selector）
    C-SMAおよびC-NMAから得られた情報をもとに、サービス要求の要件を満たす最適なサービスコンタクトインスタンスおよびパスを選択するエンジンです。

  • C-TC（CATS Traffic Classifier）
    特定サービスのフローに属するパケットを識別し、Ingress CATS-Forwarderと協調して選択されたパスへパケットを投入します。

  • CATS-Forwarder
    C-PSの決定に基づいてトラフィックを転送するネットワークエンティティです。

    • Ingress CATS-Forwarder: クライアント側のトラフィックを受け、適切なEgress CATS-Forwarderへ向かうCATS計算済みパスにトラフィックを投入します。

    • Egress CATS-Forwarder: CATSパスの終端に位置し、サービスサイトおよびサービスコンタクトインスタンスへ接続します。

CATSにおける制御およびデータ転送シーケンス

一次情報の記述に基づく、メトリクス収集からフォワーディングまでの標準的な機能間連携の流れを以下のシーケンス図に示します。

sequenceDiagram
    participant SMA as C-SMA
    participant NMA as C-NMA
    participant CPS as C-PS
    participant Client as Client
    participant Ingress as Ingress CATS-Forwarder / C-TC
    participant Egress as Egress CATS-Forwarder
    participant SCI as Service Contact Instance

    SMA->>CPS: サービス／計算メトリクスを通知
    NMA->>CPS: ネットワーク状態メトリクスを通知
    CPS->>Ingress: パス選択ポリシー／転送ルールを設定
    Client->>Ingress: サービス要求パケットを送信 (CS-ID宛て)
    Ingress->>Ingress: C-TCによるフロー識別と転送パス適用
    Ingress->>Egress: CATSオーバーレイカプセル化転送
    Egress->>SCI: サービス要求パケットを配送

制御プレーンでは、C-SMAが計算リソースの負荷や空き容量などのメトリクスを、C-NMAがネットワークの遅延や輻輳状況を収集してC-PSに集約します。C-PSはこれらを総合的に評価し、要求ごとのステアリング方針を決定してIngress CATS-Forwarderに指示します。データプレーンでは、クライアントから届いたCS-ID宛ての要求をC-TCが検出し、指定されたパスに沿ってオーバーレイカプセル化を行ってEgress CATS-Forwarder経由で対象のサービスコンタクトインスタンスへ届けます。

CATSが前提とするネットワーク環境と境界条件

一次情報において、本フレームワークを適用する範囲と境界条件がいくつか明確に規定されています。

  1. 単一サービスプロバイダ網の前提
    RFC 10053が対象とする範囲は「単一のサービスプロバイダ網（Single Service Provider）」に限定されています。複数事業者をまたがるインタードメインでの連携や調整は本仕様の対象外です。

  2. クライアント側のCATS非認識
    クライアント端末自体はCATSの存在や内部のCATS-Forwarderを認識しません。クライアントは通常のサービスプロトコルに従ってCS-ID宛てにリクエストを送信するだけであり、CATS機能エンティティがクライアント端末内に同居する構成は想定スコープ外とされています。

  3. オーバーレイ方式の採用
    CATSによるステアリングは、CATS-Forwarder間のカプセル化を用いたオーバーレイネットワークとして実現されます。下位ネットワークの物理トポロジ全体をCATS専用に刷新することなく導入できる構造が意図されています。

  4. 内部ロジックの隠蔽
    サービスコンタクトインスタンスから先で実際にどのサービスインスタンスが処理を実行するかは、CATSコンポーネントおよびクライアントの双方から隠蔽されます。コンタクトインスタンスから得られるメトリクスが複数の内部インスタンスの集約値となる場合があることも一次情報で言及されています。

CATSフレームワークを活用・検討する際の注意点

CATSアーキテクチャの導入や検討を行う際には、以下の点に留意する必要があります。

  • Informational RFCとしての位置づけ
    RFC 10053はStandards TrackではなくInformationalとして発行された文書です。特定のプロトコルヘッダフォーマットや具体的なカプセル化プロトコル（SRv6、Geneve、VXLANなど）を1つに固定するものではなく、機能要件とアーキテクチャの枠組みを示しています。具体的なパケット構造や伝送プロトコルは個別の拡張仕様を参照する必要があります。

  • メトリクス収集の更新頻度とオーバーヘッドのトレードオフ
    計算リソースの状態（CPU使用率、キュー滞留数など）はネットワーク状態よりも短時間で激しく変動する可能性があります。C-SMAからC-PSへの報告頻度を高くしすぎると制御トラフィックの増大やフラッピングを招き、低くしすぎると古い情報に基づいて過負荷な拠点へリクエストを誘導するリスクがあります。

  • セッションの一貫性とフロー識別
    ステートレスな通信であればリクエストごとに最適な拠点を選定できますが、一連のトランザクションを維持する必要があるステートフルな通信の場合、C-TCによるフロー識別（5-tuple等）に基づいて同一セッションが同一のサービスコンタクトインスタンスへ維持されるような考慮が求められます。

まとめ

RFC 10053（CATSフレームワーク）の要点は以下の通りです。

  • 目的: ネットワークの品質だけでなく、拠点の計算リソース状態を併味した動的なトラフィックステアリングを実現すること。

  • アーキテクチャ: C-SMA（計算メトリクス収集）、C-NMA（ネットワークメトリクス収集）、C-PS（パス決定）、C-TC（フロー識別）、CATS-Forwarder（オーバーレイ転送）の連携で構成。

  • 抽象化レイヤー: クライアントはCS-IDに対して要求を送り、内部ではCSCI-IDを持つサービスコンタクトインスタンスへカプセル化転送されるため、バックエンドの具体的な構成は隠蔽される。

設計や導入を検討する際は、以下の点を確認することが推奨されます。

  • 対象ネットワークが単一事業者網の要件に合致しているか。

  • C-SMAおよびC-NMAのメトリクス収集方式と制御プレーンの負荷境界が設計されているか。

  • 実際のデータプレーン転送に利用するカプセル化技術および下位ネットワーク仕様との整合性が取れているか。

参考情報

文書情報

記事タイトル
RFC 10053が描くComputing-Aware Traffic Steering（CATS）のアーキテクチャと基本概念を整理する
作成日
更新日
Source URL
https://papanda925.com/?p=18032

ライセンス: 本記事のうち、当サイトが権利を有する本文・自作図表は、特記なき限り CC BY 4.0 で利用できます。生成AIを活用して作成・編集した内容を含みます。コードについて、別途ライセンス表示またはリンク先GitHubリポジトリのライセンスがある場合は、その条件を優先します。引用・第三者資料・画像・商標等は本ライセンスの対象外です。 利用ポリシー

タイトルとURLをコピーしました