[要約] コンピューティング対応トラフィックステアリング (CATS) のフレームワークを示す情報提供のRFCで、CATSの機能コンポーネントとその相互作用、コントロールプレーンとデータプレーンの動作例を説明します。ネットワークの状態だけでなくコンピューティングリソースのメトリックも考慮して、複数のサービスサイトにあるサービスコンタクトインスタンスの中から適切なものにトラフィックを振り向けることを可能にします。対象は単一のサービスプロバイダの範囲に限られ、CATSの実現技術の網羅的な一覧は扱いません。
Internet Engineering Task Force (IETF) C. Li, Ed.
Request for Comments: 10053 Huawei Technologies
Category: Informational Z. Du
ISSN: 2070-1721 China Mobile
M. Boucadair, Ed.
Orange
L. M. Contreras
Telefonica
J. Drake
Independent
October 2026
This document describes a framework for Computing-Aware Traffic Steering (CATS). Specifically, the document identifies a set of CATS functional components, describes their interactions, and provides illustrative workflows of the control and data planes. The framework covers only the case of a single service provider.
この文書は、コンピューティング対応トラフィックステアリング (CATS) のフレームワークを説明します。具体的には、CATSの機能コンポーネントの集合を特定し、それらの相互作用を説明し、コントロールプレーンとデータプレーンのワークフロー例を示します。このフレームワークが対象とするのは、単一のサービスプロバイダの場合のみです。
This document is not an Internet Standards Track specification; it is published for informational purposes.
この文書はInternet Standards Trackの仕様ではありません。情報提供を目的として公開されます。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
この文書はInternet Engineering Task Force (IETF) の成果物です。IETFコミュニティのコンセンサスを表しています。この文書は公開レビューを受け、Internet Engineering Steering Group (IESG) により公開が承認されています。IESGが承認した文書のすべてが、あらゆるレベルのInternet Standardの候補となるわけではありません。RFC 7841のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc10053.
この文書の現在の状態、正誤表、およびフィードバックの方法に関する情報は、https://www.rfc-editor.org/info/rfc10053 で入手できます。
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright (c) 2026 IETF Trustおよび文書著者として特定された人々。All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
この文書は、BCP 78、および この文書の公開日時点で有効なIETF Trustの IETF文書に関する法的規定 (https://trustee.ietf.org/license-info) の適用を受けます。これらの文書は、この文書に関するあなたの権利と制限を記述しているため、注意深く確認してください。この文書から抽出されるコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているとおりRevised BSD Licenseの文面を含めなければならず、Revised BSD Licenseに記載されているとおり無保証で提供されます。
1. Introduction 2. Terminology 3. CATS Framework and Components 3.1. Assumptions 3.2. CATS Identifiers 3.3. Framework Overview 3.4. CATS Functional Components 3.4.1. Service Sites, Service Instances, and Service Contact Instances 3.4.2. CATS Service Metric Agent (C-SMA) 3.4.3. CATS Network Metric Agent (C-NMA) 3.4.4. CATS Path Selector (C-PS) 3.4.5. CATS Traffic Classifier (C-TC) 3.4.6. CATS-Forwarders 3.4.7. Underlay Infrastructure 4. CATS Framework Workflow 4.1. Service Announcement 4.2. Metrics Distribution 4.3. Service Access Processing 4.4. Service Contact Instance Affinity 5. Operational Considerations 5.1. Provisioning of CATS Components 5.2. Supervision of CATS Components and CATS OAM 5.3. Deployment Considerations 5.4. Implementation Considerations on Using CATS Metrics 5.5. Verifying Correct Operations 5.6. Impact on Network Operations 6. Security Considerations 7. Privacy Considerations 8. IANA Considerations 9. Informative References Appendix A. Deployment Examples A.1. Distributed Model A.2. Centralized Model A.3. Hybrid Model Acknowledgments Contributors Authors' Addresses
Computing service architectures evolved from a single service site to multiple, sometimes collaborative, service sites to address various issues such as long response times or suboptimal utilization of service and network resources (e.g., resource under-utilization or exhaustion).
コンピューティングサービスのアーキテクチャは、応答時間の長さや、サービスリソースおよびネットワークリソースの最適とは言えない利用 (例: リソースの低利用や枯渇) といったさまざまな問題に対処するため、単一のサービスサイトから、複数の、ときには協調する複数のサービスサイトへと進化してきました。
The underlying networking infrastructures that include computing resources usually provide relatively static service dispatching (e.g., the selection of the service instances for a request). In such infrastructures, service-specific traffic is often directed to the closest service site from a routing perspective without considering the actual network state (e.g., traffic congestion conditions) or the service site state.
コンピューティングリソースを含む基盤となるネットワークインフラストラクチャは、通常、比較的静的なサービスのディスパッチ (例: リクエストに対するサービスインスタンスの選択) を提供します。このようなインフラストラクチャでは、実際のネットワーク状態 (例: トラフィックの輻輳状況) やサービスサイトの状態を考慮せず、サービス固有のトラフィックがルーティングの観点で最も近いサービスサイトに向けられることがよくあります。
As described in [RFC10054], traffic steering that takes into account computing resource metrics would benefit several services, including latency-sensitive services such as immersive services that rely upon the use of augmented reality or virtual reality (AR/VR) techniques. This document provides an architectural framework that aims at facilitating the making of compute- and network-aware traffic steering decisions in dynamic networking environments with variable computing service resources.
[RFC10054] で説明されているように、コンピューティングリソースのメトリックを考慮するトラフィックステアリングは、拡張現実または仮想現実 (AR/VR) 技術の利用に依存する没入型サービスのような遅延に敏感なサービスをはじめ、いくつかのサービスに利益をもたらします。この文書は、コンピューティングサービスリソースが変動する動的なネットワーク環境において、コンピューティングとネットワークの双方を考慮したトラフィックステアリングの決定を容易にすることを目指す、アーキテクチャ上のフレームワークを提供します。
Today, organizations often distribute user services across on-premises and cloud service provider networks. To support both redundancy and responsiveness, the Computing-Aware Traffic Steering (CATS) framework supports single or multiple service instances providing one given service, which may exist in one or more service sites. Clients access service instances via client-facing service functions known as service contact instances. A single service site may host one or multiple service contact instances. A single service site may have limited computing resources available at a given time, whereas the various service sites may experience different resource availability issues over time. Therefore, steering traffic among different service sites can address resource limitations in a specific service site.
今日、組織はユーザーサービスをオンプレミスとクラウドのサービスプロバイダのネットワークにまたがって分散させることがよくあります。冗長性と応答性の両方をサポートするため、コンピューティング対応トラフィックステアリング (CATS) フレームワークは、ある1つのサービスを提供する単一または複数のサービスインスタンスをサポートします。これらは1つ以上のサービスサイトに存在することがあります。クライアントは、サービスコンタクトインスタンスと呼ばれるクライアント向けのサービス機能を介してサービスインスタンスにアクセスします。1つのサービスサイトが、1つまたは複数のサービスコンタクトインスタンスをホストすることがあります。1つのサービスサイトで特定の時点に利用できるコンピューティングリソースは限られていることがあり、また、各サービスサイトでは時間の経過とともに異なるリソース可用性の問題が生じることがあります。したがって、異なるサービスサイト間でトラフィックをステアリングすることで、特定のサービスサイトにおけるリソースの制約に対処できます。
Steering in CATS aims to select the appropriate service contact instance to service a request according to a set of network and computing metrics. This selection may not reveal the actual service instance that a client will invoke (e.g., in hierarchical or recursive contexts). Therefore, the metrics of the service contact instance may be aggregate metrics from multiple service instances.
CATSにおけるステアリングは、ネットワークメトリックとコンピューティングメトリックの集合に従って、リクエストに対応するのに適切なサービスコンタクトインスタンスを選択することを目的とします。この選択では、クライアントが実際に呼び出すサービスインスタンスが明らかにならない場合があります (例: 階層的または再帰的な状況)。したがって、サービスコンタクトインスタンスのメトリックは、複数のサービスインスタンスからの集約メトリックである場合があります。
The CATS framework is an overlay framework for the selection of the suitable service contact instances from a set of candidates. The overlay is realized by means of encapsulation between CATS-Forwarders. A combination of networking and computing metrics determines the exact characterization of services as "suitable" or not.
CATSフレームワークは、候補の集合から適切なサービスコンタクトインスタンスを選択するためのオーバーレイフレームワークです。このオーバーレイは、CATS-Forwarder間のカプセル化によって実現されます。サービスを「適切」とするか否かの正確な特徴付けは、ネットワークメトリックとコンピューティングメトリックの組み合わせによって決まります。
Furthermore, this document describes a workflow of the main CATS procedures (Section 4) executed in both the control and data planes. The framework covers only the case of a single service provider.
さらに、この文書は、コントロールプレーンとデータプレーンの両方で実行される主要なCATS手順 (セクション4) のワークフローを説明します。このフレームワークが対象とするのは、単一のサービスプロバイダの場合のみです。
This document assumes that CATS functional elements are hosted in a provider network. As such, it is out of scope to discuss deployment options where such elements are co-located with a client.
この文書は、CATSの機能要素がプロバイダネットワーク内でホストされることを前提とします。そのため、そのような要素がクライアントと同一の場所に配置される展開オプションについて論じることは、対象範囲外です。
It is out of the scope of this document to provide a comprehensive list of CATS realization techniques or assess how existing mechanisms meet all CATS requirements.
CATSの実現技術の網羅的な一覧を提供すること、または既存のメカニズムがCATSのすべての要件をどのように満たすかを評価することは、この文書の対象範囲外です。
This document makes use of the following terms:
この文書では、次の用語を使用します。
Client:
クライアント (Client):
An endpoint that connects to a service provider network.
サービスプロバイダネットワークに接続するエンドポイント。
Flow:
フロー (Flow):
A logical grouping of packets during a time interval, identified by some fields from the packet header, such as the 5-tuple transport coordinates (source address and destination address, source and destination port numbers, and protocol). Flow identification should also cover contexts where port numbers are not present (non-initial fragments, IP Encapsulating Security Payload (ESP) [RFC4303], etc.).
一定の時間間隔内のパケットの論理的なグループ化であり、5-tupleのトランスポート座標 (送信元アドレスと宛先アドレス、送信元と宛先のポート番号、およびプロトコル) など、パケットヘッダ内のいくつかのフィールドによって識別されます。フローの識別は、ポート番号が存在しない状況 (非先頭フラグメント、IP Encapsulating Security Payload (ESP) [RFC4303] など) も対象とすべきです。
Computing-Aware Traffic Steering (CATS):
コンピューティング対応トラフィックステアリング (CATS) (Computing-Aware Traffic Steering (CATS)):
A traffic engineering approach [RFC9522] that takes into account the dynamic nature of computing resources (e.g., compute and storage) and network state to optimize service-specific traffic forwarding towards a given service contact instance. The CATS framework leverages various metrics to enable CATS policies.
コンピューティングリソース (例: 計算とストレージ) の動的な性質とネットワーク状態を考慮して、特定のサービスコンタクトインスタンスに向かうサービス固有のトラフィック転送を最適化する、トラフィックエンジニアリングの手法 [RFC9522]。CATSフレームワークは、CATSポリシーを実現するためにさまざまなメトリックを活用します。
Metric:
メトリック (Metric):
A quantitative measure that provides suitable input to a selection mechanism for CATS decision making. It can be a network metric or a computing metric.
CATSの意思決定のための選択メカニズムに適切な入力を提供する、定量的な尺度。ネットワークメトリックまたはコンピューティングメトリックのいずれかになります。
Computing metric:
コンピューティングメトリック (Computing metric):
A metric specific to the computing resources in the underlying CATS systems as opposed to other metrics, such as network metrics. Examples of computing metrics are discussed in [CATS-METRICS].
ネットワークメトリックなどの他のメトリックとは対照的に、基盤となるCATSシステム内のコンピューティングリソースに固有のメトリック。コンピューティングメトリックの例は [CATS-METRICS] で議論されています。
Service:
サービス (Service):
An offering that is made available by a service provider by orchestrating a set of resources (networking, compute, storage, etc.).
サービスプロバイダが、一連のリソース (ネットワーキング、計算、ストレージなど) を編成することによって利用可能にする提供物。
The service provider retains control of internal resources and the service logic. For example, these resources may be:
サービスプロバイダは、内部リソースとサービスロジックの制御を保持します。たとえば、これらのリソースは次のようなものである場合があります。
* Exposed by one or multiple processes.
* 1つまたは複数のプロセスによって公開される。
* Provided by virtual instances, physical instances, or a combination thereof.
* 仮想インスタンス、物理インスタンス、またはそれらの組み合わせによって提供される。
* Hosted within the same or distinct nodes.
* 同一または別個のノード内でホストされる。
* Hosted within the same or multiple service sites.
* 同一または複数のサービスサイト内でホストされる。
* Chained to provide a service using a variety of means.
* さまざまな手段でチェーン化され、サービスを提供する。
How a service provider structures its services remains out of the scope of CATS.
サービスプロバイダがサービスをどのように構成するかは、CATSの適用範囲外です。
Service providers may provide the same service in many locations; each of them constitutes a service instance.
サービスプロバイダは、同じサービスを多数の場所で提供することがあります。それぞれがサービスインスタンスを構成します。
Computing service:
コンピューティングサービス：
A service offered to a client by a service provider by orchestrating a set of computing resources.
サービスプロバイダが、一連のコンピューティングリソースをオーケストレーションすることで、クライアントに提供するサービスです。
CATS Service ID (CS-ID):
CATS Service ID (CS-ID)：
An identifier representing a service, which the clients use to access it. See Section 3.2.
サービスを表す識別子であり、クライアントがサービスにアクセスするために使用します。3.2節を参照してください。
Service instance:
サービスインスタンス：
A collection of running resources that are orchestrated following a service logic. When invoked by a client request, these resources will collectively provide the intended service.
サービスロジックに従ってオーケストレーションされる、稼働中のリソースの集合です。クライアントの要求によって呼び出されると、これらのリソースが一体となって意図されたサービスを提供します。
A service provider may enable many service instances that adhere to the same service logic to provide the same service.
サービスプロバイダは、同じサービスロジックに従う多数のサービスインスタンスを有効にして、同じサービスを提供することがあります。
A service instance runs in a service site and one or more instances may service clients' requests.
サービスインスタンスはサービスサイトで稼働し、1つ以上のインスタンスがクライアントの要求に対応することがあります。
Service site:
サービスサイト：
A location that hosts the resources that implement one or more service instances.
1つ以上のサービスインスタンスを実装するリソースをホストする場所です。
A service site may be a node or a set of nodes.
サービスサイトは、ノードまたはノードの集合であることがあります。
Service contact instance:
サービスコンタクトインスタンス：
A client-facing function that is responsible for receiving requests in the context of a given service.
特定のサービスに関する要求を受け付ける責務を持つ、クライアント向けの機能です。
A service contact instance can handle one or more service instances.
サービスコンタクトインスタンスは、1つ以上のサービスインスタンスを扱うことができます。
Steering beyond a service contact instance is hidden to both clients and CATS components.
サービスコンタクトインスタンスより先のステアリングは、クライアントとCATSコンポーネントの両方から隠蔽されます。
A service contact instance processes a client's service request according to the service logic (e.g., handle locally or solicit backend resources).
サービスコンタクトインスタンスは、サービスロジックに従ってクライアントのサービス要求を処理します (例: ローカルで処理する、またはバックエンドリソースに処理を依頼する)。
A service contact instance is reachable via at least one Egress CATS-Forwarder.
サービスコンタクトインスタンスには、少なくとも1つのEgress CATS-Forwarder経由で到達できます。
Clients may access a service via multiple service contact instances running at the same or different locations (service sites).
クライアントは、同じ場所または異なる場所 (サービスサイト) で稼働する複数のサービスコンタクトインスタンスを介して、サービスにアクセスすることがあります。
A service contact instance may dispatch service requests to one or more service instances (e.g., a service contact instance that behaves as a service load balancer).
サービスコンタクトインスタンスは、サービス要求を1つ以上のサービスインスタンスに振り分けることがあります (例: サービスロードバランサとして動作するサービスコンタクトインスタンス)。
CATS Service Contact Instance ID (CSCI-ID):
CATS Service Contact Instance ID (CSCI-ID)：
An identifier of a specific service contact instance. See Section 3.2.
特定のサービスコンタクトインスタンスの識別子です。3.2節を参照してください。
Service request:
サービス要求：
A request to access or invoke a specific service. CATS-Forwarders steer a service request to a service contact instance.
特定のサービスにアクセスまたは起動するための要求です。CATS-Forwarderは、サービス要求をサービスコンタクトインスタンスへステアリングします。
Clients generate service requests using service-specific protocols.
クライアントは、サービス固有のプロトコルを使用してサービス要求を生成します。
Clients send service requests to a service instance (identified by a CS-ID), without explicit knowledge of CATS-Forwarders.
クライアントは、CATS-Forwarderを明示的に認識することなく、(CS-IDで識別される) サービスインスタンスにサービス要求を送信します。
CATS-Forwarder:
CATS-Forwarder：
A network entity that steers traffic specific to a service request towards a service contact instance according to forwarding decisions supplied by a CATS Path Selector (C-PS), which may or may not be part of a CATS-Forwarder.
CATS Path Selector (C-PS) から提供される転送判断に従って、サービス要求に固有のトラフィックをサービスコンタクトインスタンスへステアリングするネットワークエンティティです。C-PSは、CATS-Forwarderの一部であってもなくてもかまいません。
A CATS-Forwarder may behave as an Ingress or Egress CATS-Forwarder. See Section 3.4.6.
CATS-Forwarderは、Ingress CATS-ForwarderまたはEgress CATS-Forwarderとして動作することがあります。3.4.6節を参照してください。
Ingress CATS-Forwarder:
Ingress CATS-Forwarder：
An entity that steers service-specific traffic along a CATS-computed path that leads to an Egress CATS-Forwarder. Such an Egress CATS-Forwarder connects to the most suitable service site that hosts the service contact instance selected to satisfy the initial service request.
サービス固有のトラフィックを、CATSが計算したパスに沿ってEgress CATS-Forwarderへステアリングするエンティティです。このEgress CATS-Forwarderは、最初のサービス要求を満たすために選択されたサービスコンタクトインスタンスをホストする、最適なサービスサイトに接続します。
Egress CATS-Forwarder:
Egress CATS-Forwarder：
An entity located at the end of a CATS-computed path, which connects to a service site.
CATSが計算したパスの終端に位置し、サービスサイトに接続するエンティティです。
CATS Path Selector (C-PS):
CATS Path Selector (C-PS)：
A functional entity that selects paths towards service sites and instances (and thus service contact instances) in order to accommodate the requirements of service requests. The path selection engine takes into account the service and network status information. See Section 3.4.4.
サービス要求の要件に対応するため、サービスサイトとサービスインスタンス (ひいてはサービスコンタクトインスタンス) へ向かうパスを選択する機能エンティティです。パス選択エンジンは、サービスとネットワークの状態情報を考慮します。3.4.4節を参照してください。
CATS Service Metric Agent (C-SMA):
CATS Service Metric Agent (C-SMA)：
A functional entity that is responsible for collecting service capabilities and status and for reporting them to a C-PS. See Section 3.4.2.
サービスの能力と状態を収集し、C-PSに報告する責務を持つ機能エンティティです。3.4.2節を参照してください。
CATS Network Metric Agent (C-NMA):
CATS Network Metric Agent (C-NMA)：
A functional entity that is responsible for collecting network capabilities and status and for reporting them to a C-PS. See Section 3.4.3.
C-PSに対して、ネットワークの能力と状態を収集して報告する機能エンティティです。3.4.3節を参照してください。
CATS Traffic Classifier (C-TC):
CATS Traffic Classifier (C-TC):
A functional entity that is responsible for determining which packets belong to a traffic flow for a specific service request. It coordinates with the Ingress CATS-Forwarder so that such packets are placed onto a path computed by the C-PS that leads to the selected service contact instance. See Section 3.4.5.
特定のサービスリクエストに対するトラフィックフローに、どのパケットが属するかを判定する機能エンティティです。Ingress CATS-Forwarderと連携し、そのようなパケットを、C-PSが計算した、選択されたサービスコンタクトインスタンスへ至るパスに載せます。3.4.5節を参照してください。
CATS assumes that a service might be provided by one or multiple service instances. Such instances may be hosted within the same or distinct service sites. A given service is represented by the same service identifier (Section 3.2). CATS does not make any additional assumptions about these instances other than that they are reachable via one or multiple service contact instances.
CATSは、サービスが1つまたは複数のサービスインスタンスによって提供される場合があることを前提とします。これらのインスタンスは、同一のサービスサイトまたは異なるサービスサイトにホストされることがあります。あるサービスは、同一のサービス識別子 (3.2節) で表されます。CATSは、これらのインスタンスが1つまたは複数のサービスコンタクトインスタンスを介して到達可能であること以外には、それらについて追加の前提を置きません。
CATS uses the following identifiers:
CATSは次の識別子を使用します。
CATS Service ID (CS-ID):
CATS Service ID (CS-ID):
An identifier (ID) representing a service, which the clients use to access it. Such an ID identifies all the instances of a given service, regardless of their locations.
サービスを表す識別子 (ID) であり、クライアントがサービスにアクセスするために使用します。このIDは、所在地にかかわらず、あるサービスのすべてのインスタンスを識別します。
The CS-ID is independent of which service contact instance serves the service request.
CS-IDは、どのサービスコンタクトインスタンスがサービスリクエストを処理するかには依存しません。
Service requests are spread over the service contact instances that can accommodate them, considering the location of the initiator of the service request and the availability (in terms of resource/traffic load, for example) of the service instances resource wise, among other considerations like traffic congestion conditions.
サービスリクエストは、それを受け入れられるサービスコンタクトインスタンスに分散されます。その際、サービスリクエストの発信元の位置、およびサービスインスタンスのリソース面での可用性 (たとえばリソース負荷やトラフィック負荷の観点) のほか、トラフィックの輻輳状況などの他の考慮事項も勘案されます。
CATS Service Contact Instance ID (CSCI-ID):
CATS Service Contact Instance ID (CSCI-ID):
An identifier of a specific service contact instance.
特定のサービスコンタクトインスタンスの識別子です。
This document makes no assumptions about the structure or semantics of this identifier. One example of such an ID is a unicast IP address, which uniquely identifies the location of a service instance.
本書は、この識別子の構造や意味について何も前提を置きません。このようなIDの一例は、サービスインスタンスの位置を一意に識別するユニキャストIPアドレスです。
A high-level view of the CATS framework, without expanding the functional entities in the network, is illustrated in Figure 1.
ネットワーク内の機能エンティティを展開しない、CATSフレームワークの高レベルな見取り図を図1に示します。
.----------------------------------. | .---------.
| Management Plane | | | |
+----------------------------------+ |<=======>| C-SMA |
| Control Plane | | | |
'----------------------------------' | '---+-----'
^ | |
| | |
v | |
.----------------------------------. | .---+----.
| Data Plane | | | .------+-.
'----------------------------------' |<=======>| |Service |
| | |Contact |
| '-+Instance|
| '----+---'
| |
| .------+-.
| | .------+-.
| | |Service |
| '-+Instance|
| '--------'
Figure 1: Main CATS Interactions
図1: CATSの主要な相互作用
For the sake of illustration, "Service Instance" is shown as a single box in Figure 1. However, this does not imply that a service instance is hosted in a single node. Whether a service instance is realized by invoking resources within the same node or by chaining resources exposed by several nodes is deployment specific.
説明のため、図1では「Service Instance」を1つのボックスとして示しています。ただし、これはサービスインスタンスが単一のノードにホストされることを意味しません。サービスインスタンスが、同一ノード内のリソースを呼び出すことで実現されるのか、複数のノードが公開するリソースを連鎖させることで実現されるのかは、デプロイメントに依存します。
The following planes are defined:
次のプレーンが定義されています。
* CATS Management Plane: Responsible for monitoring, configuring, and maintaining CATS network devices.
* CATSマネジメントプレーン: CATSネットワークデバイスの監視、設定、保守を担当します。
* CATS Control Plane: Responsible for scheduling services based on computing and network information. It is also responsible for making decisions about how packets should be forwarded by involved forwarding nodes and communicating such decisions to the CATS Data Plane for execution.
* CATSコントロールプレーン: コンピューティング情報とネットワーク情報に基づくサービスのスケジューリングを担当します。また、関与する転送ノードがパケットをどのように転送すべきかを決定し、その決定を実行のためにCATSデータプレーンへ伝達することも担当します。
* CATS Data Plane: Responsible for computing-aware forwarding, including classifying packets, steering them onto chosen paths towards selected service contact instances, and forwarding the packets along the paths to the service contact instances.
* CATSデータプレーン: コンピューティング対応の転送を担当します。これには、パケットの分類、選択されたサービスコンタクトインスタンスへ向かう選択済みパスへのパケットのステアリング、およびそのパスに沿ったサービスコンタクトインスタンスへのパケットの転送が含まれます。
Depending on implementation and deployment, these planes may consist of several functional components, and the details will be described in the following sections. For example, the control plane may consist of C-PS, C-NMA, etc. The data plane may consist of CATS-Forwarders, C-TC, etc.
実装やデプロイメントによっては、これらのプレーンは複数の機能コンポーネントで構成されることがあり、その詳細は以降の節で説明します。たとえば、コントロールプレーンはC-PS、C-NMAなどで構成されることがあります。データプレーンはCATS-Forwarder、C-TCなどで構成されることがあります。
CATS nodes make forwarding decisions for a given service request that has been received from a client according to the capabilities and status information of both service contact instances and the network. The main CATS functional components and their interactions are shown in Figure 2. These components are described in the subsections that follow.
CATSノードは、クライアントから受信した特定のサービスリクエストに対して、サービスコンタクトインスタンスとネットワークの双方の能力および状態の情報に従って転送を決定します。CATSの主要な機能コンポーネントとその相互作用を図2に示します。これらのコンポーネントについては、以降の小節で説明します。
.------. .------. .------.
.-+----. | .-+----. | .-+----. |
|client+-' |client+-' |client+-'
'---+--' '---+--' '---+--'
| | |
| .----------------. | .-----+----------.
'-+ C-TC#1 +-' .-----+ C-TC#2 |
+-----+----------+ | +----------------+
| | C-PS#1 | .---+--. |CATS-Forwarder 4|
| '----------+ |C-PS#2| | |
......|CATS-Forwarder 2|....| |..| |...
: '----------------' '------' '----------------' :
: :
: .-------. :
: Underlay | C-NMA | :
: Infrastructure '-------' :
: :
: :
: .----------------. .----------------. :
: |CATS-Forwarder 1| .-------. |CATS-Forwarder 3| :
:.| |..|C-SMA#1|.....| |....:
'--------+-------' '-+-----' +----------------+
| | | C-SMA#2 |
| | '-------+--------'
| | |
| | |
.-+------------+-. .-----+-------.
.-+-------------. | .-+----------. |
| Service | | | Service | |
| Contact | | | Contact | |
| Instance +--' | Instance +--'
'--------+------' '------+-----'
| |
.-----+----. .-----+----.
.-+--------. | .-+--------. |
.-+--------. | | | Service | |
| Service | +-' | Instance +-'
| Instance +-' '----------'
'----------' Service Site 2
Service Site 1
Figure 2: CATS Functional Components
図2: CATSの機能コンポーネント
Service sites are locations that host resources (including computing resources) that are required to offer a service.
サービスサイトは、サービスを提供するために必要なリソース (コンピューティングリソースを含む) をホストする場所です。
A compute service (e.g., for face recognition purposes or a game server) is identified by a CATS Service ID (CS-ID). The CS-ID does not need to be globally unique but must be sufficiently unique to unambiguously identify the service at all of the components of a CATS system.
コンピュートサービス (たとえば顔認識用途やゲームサーバ) は、CATS Service ID (CS-ID) によって識別されます。CS-IDはグローバルに一意である必要はありませんが、CATSシステムのすべてのコンポーネントにおいてサービスを曖昧さなく識別できる程度に十分一意でなければなりません。
A single service can be represented and accessed via several contact instances that run in the same or different regions of a network.
1つのサービスは、ネットワークの同一または異なるリージョンで動作する複数のコンタクトインスタンスを介して、表現およびアクセスされることがあります。
As service instances are accessed via a service contact instance, a client will not see the service instances but only the service contact instance.
サービスインスタンスにはサービスコンタクトインスタンスを介してアクセスするため、クライアントにはサービスインスタンスは見えず、サービスコンタクトインスタンスだけが見えます。
Figure 2 shows two CATS nodes ("CATS-Forwarder 1" and "CATS-Forwarder 3") that provide access to service contact instances. These nodes behave as Egress CATS-Forwarders (Section 3.4.6).
図2は、サービスコンタクトインスタンスへのアクセスを提供する2つのCATSノード (「CATS-Forwarder 1」と「CATS-Forwarder 3」) を示しています。これらのノードは、Egress CATS-Forwarder (3.4.6節) として動作します。
Note: "Egress" is used here in reference to the direction of the service request placement. The directionality is called to explicitly identify the exit node of the CATS infrastructure.
注: ここでの「Egress」は、サービスリクエストの配置方向を基準にした用語です。この方向性は、CATSインフラストラクチャの出口ノードを明示的に識別するために示しています。
The CATS Service Metric Agent (C-SMA) is a functional component that gathers information about service sites and server resources, as well as the status of the different service instances. A C-SMA may be co-located or located adjacent to a service contact instance, hosted by or adjacent to an Egress CATS-Forwarder (Section 3.4.6), etc. There may be one or more C-SMAs in a deployment.
CATS Service Metric Agent (C-SMA) は、サービスサイトとサーバリソースに関する情報、および各サービスインスタンスの状態を収集する機能コンポーネントです。C-SMAは、サービスコンタクトインスタンスと同じ場所に配置されることも、それに隣接して配置されることも、Egress CATS-Forwarder (3.4.6節) にホストされる、またはそれに隣接することなどもあります。1つのデプロイメントに、1つ以上のC-SMAが存在することがあります。
Figure 2 shows one C-SMA embedded in "CATS-Forwarder 3" and another C-SMA that is adjacent to "CATS-Forwarder 1".
図2は、「CATS-Forwarder 3」に組み込まれた1つのC-SMAと、「CATS-Forwarder 1」に隣接するもう1つのC-SMAを示しています。
The CATS Network Metric Agent (C-NMA) is a functional component that gathers information about the state of the underlay network. The C-NMAs may be implemented as standalone components or may be hosted by other components, such as CATS-Forwarders or CATS Path Selectors (C-PSes) (Section 3.4.4).
CATS Network Metric Agent (C-NMA) は、アンダーレイネットワークの状態に関する情報を収集する機能コンポーネントです。C-NMAは、スタンドアロンのコンポーネントとして実装されることも、CATS-ForwarderやCATS Path Selector (C-PS) (3.4.4節) など他のコンポーネントにホストされることもあります。
Figure 2 shows a single, standalone C-NMA within the underlay network. There may be one or more C-NMAs for an underlay network.
図2は、アンダーレイネットワーク内の単一のスタンドアロンのC-NMAを示しています。1つのアンダーレイネットワークに対して、1つ以上のC-NMAが存在する場合があります。
The C-SMAs and C-NMAs share the collected information with C-PSes, which use such information to select the Egress CATS-Forwarders (and potentially the service contact instances) that the traffic should be forwarded to for a given service request. C-PSes also determine the best paths (possibly using tunnels) to forward traffic, according to various criteria that include network state and traffic congestion conditions. The collected information is encoded into one or more metrics that feed the C-PS path selection logic. Such information also includes CS-IDs and possibly CSCI-IDs.
C-SMAとC-NMAは、収集した情報をC-PSと共有します。C-PSは、その情報を用いて、特定のサービスリクエストに対してトラフィックを転送すべきEgress CATS-Forwarder（および場合によってはサービスコンタクトインスタンス）を選択します。C-PSはまた、ネットワーク状態や輻輳状況を含むさまざまな基準に従って、トラフィックを転送する最適なパス（トンネルを使用する場合もあります）を決定します。収集された情報は、C-PSのパス選択ロジックに入力される1つ以上のメトリックにエンコードされます。そのような情報には、CS-ID、および場合によってはCSCI-IDも含まれます。
There might be one or more C-PSes used to select CATS paths in a CATS infrastructure.
CATSインフラストラクチャでは、CATSパスの選択に使用されるC-PSが1つ以上存在する場合があります。
A C-PS can be integrated into CATS-Forwarders (e.g., "C-PS#1" in Figure 2) or may be deployed as a standalone component (e.g., "C-PS#2" in Figure 2). Generally, a standalone C-PS can be a functional component of a centralized controller (e.g., a Path Computation Element (PCE) [RFC4655] or a Software-Defined Networking (SDN) controller [RFC7149] [RFC7426]).
Refer to Section 4.2 for a discussion on metric distribution (including interaction with routing protocols).
メトリックの配布（ルーティングプロトコルとの相互作用を含む）に関する議論については、4.2節を参照してください。
The CATS Traffic Classifier (C-TC) is a functional component that is responsible for associating incoming packets from clients with service requests. C-TCs also ensure that packets that are bound to a specific service contact instance are all forwarded towards that same service contact instance, as instructed by a C-PS. To that aim, a C-TC uses CS-IDs (or their resolution of CS-ID to network locators) to classify service requests. Refer to Section 5.1 for more details about required provisioning actions.
CATSトラフィック分類器 (C-TC) は、クライアントからの着信パケットをサービスリクエストに関連付ける役割を担う機能コンポーネントです。C-TCはまた、特定のサービスコンタクトインスタンスに結び付けられたパケットが、C-PSの指示どおり、すべて同一のサービスコンタクトインスタンスへ転送されるようにします。そのためにC-TCは、CS-ID（またはCS-IDからネットワークロケータへの解決結果）を用いてサービスリクエストを分類します。必要なプロビジョニング作業の詳細については、5.1節を参照してください。
CS-IDs may be carried in packets if mechanisms such as TLS Server Name Indication (SNI) extensions (Section 3 of [RFC6066]) are used. Such exposure is not possible if extensions such as [RFC9849] are used. Relying upon non-volatile and explicit signals (e.g., [RFC8558]) is thus encouraged for efficient classification rules. Note that once classified, packets will be encapsulated as described in Section 4.3.
C-TCs are typically hosted in CATS-Forwarders.
C-TCは通常、CATS-Forwarderでホストされます。
Ingress CATS-Forwarders are responsible for steering service-specific traffic along a CATS-computed path that leads to an Egress CATS-Forwarder. Egress CATS-Forwarders are the elements that behave as an egress for service requests that are forwarded over a CATS infrastructure.
Ingress CATS-Forwarderは、サービス固有のトラフィックを、Egress CATS-Forwarderに至るCATS計算済みパスに沿ってステアリングする役割を担います。Egress CATS-Forwarderは、CATSインフラストラクチャを介して転送されるサービスリクエストのエグレスとして動作する要素です。
A service site that hosts service instances may be connected to one or more Egress CATS-Forwarders (e.g., multi-homing design). If a C-PS has selected a specific service contact instance and the C-TC has marked the traffic with the CSCI-ID related information, the Egress CATS-Forwarder then forwards the traffic to the relevant service contact instance accordingly.
サービスインスタンスをホストするサービスサイトは、1つ以上のEgress CATS-Forwarderに接続される場合があります（例: マルチホーミング設計）。C-PSが特定のサービスコンタクトインスタンスを選択し、C-TCがトラフィックにCSCI-IDに関連する情報を付与している場合、Egress CATS-Forwarderは、それに従って該当するサービスコンタクトインスタンスへトラフィックを転送します。
In some cases, the choice of the service contact instance may be left open to the Egress CATS-Forwarder (i.e., traffic is marked only with the CS-ID). In such cases, the Egress CATS-Forwarder selects a service contact instance using its knowledge of service and network capabilities as well as the current load as observed by the CATS-Forwarder, among other considerations. In the absence of an explicit policy, an Egress CATS-Forwarder must make sure to forward all packets that pertain to a given service request towards the same service contact instance.
場合によっては、サービスコンタクトインスタンスの選択がEgress CATS-Forwarderに委ねられることがあります（すなわち、トラフィックにCS-IDのみが付与されている場合）。そのような場合、Egress CATS-Forwarderは、サービスおよびネットワークの能力に関する自身の知識や、CATS-Forwarderが観測している現在の負荷などを考慮して、サービスコンタクトインスタンスを選択します。明示的なポリシーがない場合、Egress CATS-Forwarderは、特定のサービスリクエストに属するすべてのパケットを必ず同一のサービスコンタクトインスタンスへ転送しなければなりません。
Note that, depending on the design considerations and service requirements, per-service contact instance computing-related metrics or aggregated per-site computing-related metrics (and a combination thereof) can be used by a C-PS. Using aggregated per-site computing-related metrics appears as a preferred option scalability wise, but it relies on Egress CATS-Forwarders that connect to various service contact instances to select the proper service contact instance. An Egress CATS-Forwarder may choose to aggregate the metrics from different sites as well. In this case, the Egress CATS-Forwarder will choose the best site by itself when the packets arrive at it.
設計上の考慮事項やサービス要件によっては、C-PSが、サービスコンタクトインスタンスごとのコンピューティング関連メトリック、サイトごとに集約したコンピューティング関連メトリック、またはその組み合わせを使用できる点に注意してください。サイトごとに集約したコンピューティング関連メトリックの使用は、スケーラビリティの観点では好ましい選択肢に見えますが、複数のサービスコンタクトインスタンスに接続するEgress CATS-Forwarderが適切なサービスコンタクトインスタンスを選択することに依存します。Egress CATS-Forwarderは、異なるサイトのメトリックを集約することを選択する場合もあります。この場合、Egress CATS-Forwarderは、パケットが到着した時点で、自身で最適なサイトを選択します。
The "underlay infrastructure" in Figure 2 indicates an IP and/or MPLS network that is not necessarily CATS aware. The CATS paths that are computed by a C-PS will be distributed among the CATS-Forwarders (Section 3.4.6) and will not affect the underlay nodes. Underlay nodes are typically P routers (Section 5.3.1 of [RFC4026]).
図2の「アンダーレイインフラストラクチャ」は、必ずしもCATSに対応していないIPネットワークまたはMPLSネットワーク（あるいはその両方）を示します。C-PSによって計算されたCATSパスはCATS-Forwarder間で配布され（3.4.6節）、アンダーレイノードには影響しません。アンダーレイノードは通常、Pルータです（[RFC4026] の5.3.1節）。
The following subsections provide an overview of a typical CATS workflow. In order to enable CATS in a given domain, some provisioning is needed; see more details in Section 5.1. Section 5.3 describes several deployment options (distributed, centralized, and hybrid models) to accommodate a variety of contexts.
以下のサブセクションでは、典型的なCATSワークフローの概要を示します。特定のドメインでCATSを有効にするには、何らかのプロビジョニングが必要です。詳細は5.1節を参照してください。5.3節では、さまざまなコンテキストに対応するための複数のデプロイオプション（分散型、集中型、ハイブリッド型モデル）を説明します。
A service is associated by the service provider with a unique identifier called a CS-ID. A CS-ID may be a network identifier, such as an IP address. The mapping of CS-IDs to network identifiers may be learned through a name resolution service (e.g., DNS [RFC1034]). Note that the CATS framework does not assume or preclude any specific name resolution service.
サービスは、サービスプロバイダによって、CS-IDと呼ばれる一意の識別子に関連付けられます。CS-IDは、IPアドレスなどのネットワーク識別子である場合があります。CS-IDからネットワーク識別子へのマッピングは、名前解決サービス（例: DNS [RFC1034]）を通じて学習される場合があります。CATSフレームワークは、特定の名前解決サービスを前提とせず、また排除もしないことに注意してください。
As described in Section 3.4, a C-SMA collects both computing-related capabilities and metrics and associates them with a CS-ID that identifies the service. The C-SMA may aggregate the metrics for multiple service contact instances, maintain them separately, or both.
3.4節で説明したように、C-SMAはコンピューティング関連の能力とメトリックの両方を収集し、それらをサービスを識別するCS-IDに関連付けます。C-SMAは、複数のサービスコンタクトインスタンスのメトリックを集約してもよく、個別に保持してもよく、その両方を行ってもかまいません。
The C-SMA then advertises CS-IDs along with metrics to related C-PSes in the network. Depending on the deployment choice, CS-IDs with metrics may be distributed in different ways. Refer to Section 5.4 for more deployment considerations.
次にC-SMAは、CS-IDをメトリックとともに、ネットワーク内の関連するC-PSにアドバタイズします。デプロイの選択によっては、メトリック付きのCS-IDがさまざまな方法で配布される場合があります。デプロイに関するその他の考慮事項については、5.4節を参照してください。
The computing metrics include computing-related metrics and potentially other service-specific metrics like the number of clients that access the service contact instance at any given time, etc.
コンピューティングメトリックには、コンピューティング関連メトリックのほか、ある時点でサービスコンタクトインスタンスにアクセスしているクライアント数など、サービス固有の他のメトリックが含まれる場合があります。
Computing metrics may change very frequently (e.g., see Section 5.3 of [RFC10054] for a discussion). How frequently such information is distributed is to be determined as part of the specification of any communication protocol (including routing protocols) that may be used to distribute the information. Various options can be considered, such as (but not limited to) interval-based updates, threshold-triggered updates, policy-based updates, or using normalized metrics.
コンピューティングメトリックは非常に頻繁に変化する場合があります（議論については、例として [RFC10054] の5.3節を参照してください）。そのような情報をどの頻度で配布するかは、その情報の配布に使用される可能性のある通信プロトコル（ルーティングプロトコルを含む）の仕様の一部として決定されます。間隔ベースの更新、しきい値契機の更新、ポリシーベースの更新、正規化されたメトリックの使用など（ただしこれらに限定されません）、さまざまな選択肢が考えられます。
Additionally, the C-NMA collects network-related capabilities and metrics. These may be collected and distributed by existing measurement protocols and/or routing protocols, although extensions to such protocols may be required to carry additional information (e.g., link latency). The C-NMA distributes the network metrics to the C-PSes so that they can use the combination of service and network metrics to determine the best Egress CATS-Forwarder to provide access to a service contact instance and invoke the compute function required by a service request. Similar to computing-related metrics, the network-related metrics can be distributed using distributed, centralized, or hybrid schemes. This document does not describe such details since this is deployment specific.
さらにC-NMAは、ネットワーク関連の能力とメトリックを収集します。これらは、既存の測定プロトコルまたはルーティングプロトコル（あるいはその両方）によって収集・配布される場合がありますが、追加情報（例: リンクレイテンシ）を伝達するためには、それらのプロトコルの拡張が必要になる場合があります。C-NMAは、ネットワークメトリックをC-PSに配布します。これにより、C-PSはサービスメトリックとネットワークメトリックの組み合わせを用いて、サービスコンタクトインスタンスへのアクセスを提供し、サービスリクエストが必要とするコンピュート機能を呼び出すための最適なEgress CATS-Forwarderを決定できます。コンピューティング関連メトリックと同様に、ネットワーク関連メトリックも、分散型、集中型、またはハイブリッド型の方式で配布できます。この詳細はデプロイ固有であるため、本書では説明しません。
Network metrics may also change over time. Dynamic routing protocols may take advantage of some information or capabilities to prevent the network from being flooded with state change information (e.g., Partial Route Computation (PRC) of OSPFv3 [RFC5340]). C-NMAs should also be configured or instructed like C-SMAs to determine when and how often updates should be notified to the C-PSes.
ネットワークメトリックも時間とともに変化する場合があります。動的ルーティングプロトコルは、ネットワークが状態変化情報であふれることを防ぐために、一部の情報や機能を活用できる場合があります（例: OSPFv3 [RFC5340] のPartial Route Computation (PRC)）。C-NMAについても、C-SMAと同様に、C-PSに更新をいつ、どのくらいの頻度で通知するかを決定するための設定または指示を与えるべきです。
A C-PS selects paths that lead to Egress CATS-Forwarders according to both service and network metrics that were advertised. A C-PS may be collocated with an Ingress CATS-Forwarder or logically centralized (in the centralized or hybrid models (Section 5.3)).
C-PSは、アドバタイズされたサービスメトリックとネットワークメトリックの両方に従って、Egress CATS-Forwarderに至るパスを選択します。C-PSは、Ingress CATS-Forwarderと同じ場所に配置される場合もあれば、論理的に集中化される場合もあります（集中型またはハイブリッド型モデルにおいて（5.3節））。
This document does not specify any specific algorithm for path selection purposes to be supported by C-PSes so as not to constrain the CATS framework to one possible selection only. Instead, it is expected that a service request or local policy may feed the C-PS with appropriate information on that selection logic that takes the suitable metric information as input and the selected service contact instance as output. Such appropriate information may be utilized to differentiate selection mechanisms to enable service-specific selections.
本書は、CATSフレームワークを1つの選択方式に制約しないよう、C-PSがサポートするパス選択用の特定のアルゴリズムを規定しません。その代わりに、サービスリクエストまたはローカルポリシーが、適切なメトリック情報を入力とし、選択されたサービスコンタクトインスタンスを出力とする選択ロジックについて、適切な情報をC-PSに与えることが想定されます。そのような適切な情報は、選択メカニズムを区別して、サービス固有の選択を可能にするために利用される場合があります。
Note that a service request to access the service may consist of one or more service packets (e.g., Session Initiation Protocol (SIP) [RFC3261], HTTP [RFC9112], IPv6 [RFC8200], Segment Routing over IPv6 (SRv6) [RFC8754] [RFC8986], or Real-Time Streaming Protocol (RTSP) [RFC7826]) that carry the CS-ID and potential parameters. When a matching classification entry maintained by a C-TC is found for the packets, the Ingress CATS-Forwarder encapsulates and forwards them to the C-PS selected Egress CATS-Forwarder. When these packets reach the Egress CATS-Forwarder, the outer header of the possible overlay encapsulation will be removed and the inner packets will be sent to the relevant service contact instance.
サービスへアクセスするためのサービスリクエストは、CS-IDおよび場合によってはパラメータを伝達する1つ以上のサービスパケット（例: Session Initiation Protocol (SIP) [RFC3261]、HTTP [RFC9112]、IPv6 [RFC8200]、Segment Routing over IPv6 (SRv6) [RFC8754] [RFC8986]、Real-Time Streaming Protocol (RTSP) [RFC7826]）で構成される場合がある点に注意してください。C-TCが保持する一致する分類エントリがそれらのパケットに対して見つかると、Ingress CATS-Forwarderはそれらをカプセル化し、C-PSが選択したEgress CATS-Forwarderへ転送します。これらのパケットがEgress CATS-Forwarderに到達すると、オーバーレイカプセル化が行われていればその外側のヘッダが取り除かれ、内側のパケットが該当するサービスコンタクトインスタンスへ送信されます。
Service contact instance affinity means that packets that belong to a flow associated with a service request should always be sent to the same service contact instance. Furthermore, packets of a given flow should be forwarded along the same path to avoid misordering and to prevent the introduction of unpredictable latency variations. A CATS framework implementation must ensure that service instance selection and path steering decisions remain consistent for a flow. Specifically, the same Egress CATS-Forwarder needs to be solicited to forward the packets.
サービスコンタクトインスタンスのアフィニティとは、サービスリクエストに関連付けられたフローに属するパケットが、常に同一のサービスコンタクトインスタンスへ送信されるべきであることを意味します。さらに、順序の入れ替わりを避け、予測不能なレイテンシ変動の発生を防ぐために、特定のフローのパケットは同一のパスに沿って転送されるべきです。CATSフレームワークの実装は、サービスインスタンスの選択とパスステアリングの判断がフローに対して一貫していることを保証しなければなりません。具体的には、パケットを転送するために同一のEgress CATS-Forwarderが選ばれる必要があります。
Ensuring service affinity for flows is a feature that can be configured on the C-PS when the service is deployed (i.e., all flows bound to a service) or determined at the time of newly formulated service requests (i.e., a specific flow).
フローに対するサービスアフィニティの保証は、サービスのデプロイ時にC-PSで設定する（すなわち、サービスに結び付けられたすべてのフロー）か、新たに作成されたサービスリクエストの時点で決定する（すなわち、特定のフロー）ことができる機能です。
Note that different services may have different notions of what constitutes a "flow", and thus may identify a flow differently. Typically, a flow is identified by the 5-tuple transport coordinates (source address and destination address, source and destination port numbers, and protocol). However, for instance, an RTP video stream may use different port numbers for video and audio channels: In that case, affinity may be identified as a combination of the two 5-tuple flow identifiers so that both flows are addressed to the same service contact instance.
サービスによって「フロー」を何とみなすかの考え方が異なる場合があり、したがってフローの識別方法も異なる場合がある点に注意してください。通常、フローは5タプルのトランスポート座標（送信元アドレスと宛先アドレス、送信元ポート番号と宛先ポート番号、およびプロトコル）で識別されます。しかし、たとえばRTPビデオストリームでは、ビデオチャネルとオーディオチャネルで異なるポート番号が使用される場合があります。その場合、両方のフローが同じサービスコンタクトインスタンスに向けられるよう、アフィニティは2つの5タプルフロー識別子の組み合わせとして識別される場合があります。
Hence, when specifying a protocol to communicate information about service contact instance affinity to C-TCs in particular, the protocol should support flexible mechanisms for identifying flows. Or, from a more general perspective, there should be a mechanism to specify and identify the set of packets that are subject to a service contact instance affinity.
したがって、特にC-TCにサービスコンタクトインスタンスのアフィニティに関する情報を伝えるプロトコルを規定する際には、そのプロトコルはフローを識別するための柔軟なメカニズムをサポートすべきです。あるいは、より一般的な観点からは、サービスコンタクトインスタンスのアフィニティの対象となるパケットの集合を指定し識別するためのメカニズムが存在すべきです。
More importantly, the means for identifying a flow for ensuring instance affinity should be application independent to avoid the need for service-specific instance affinity methods. However, service contact instance affinity information may be configurable on a per-service basis. For each service, the information can include the flow or packet identification type and means, affinity timeout value, etc.
さらに重要なこととして、インスタンスアフィニティを保証するためのフローの識別手段は、サービス固有のインスタンスアフィニティ方式を必要としないよう、アプリケーションに依存しないものであるべきです。ただし、サービスコンタクトインスタンスのアフィニティ情報は、サービスごとに設定可能である場合があります。各サービスについて、この情報には、フローまたはパケットの識別タイプと手段、アフィニティのタイムアウト値などを含めることができます。
This document does not introduce any mechanism for defining or enforcing service contact instance affinity.
本書は、サービスコンタクトインスタンスのアフィニティを定義または強制するためのいかなるメカニズムも導入しません。
Enabling CATS in a network can be done incrementally. That is, not all ingress routers (Provider Edges (PEs), typically) need to be upgraded to support CATS.
ネットワークでのCATSの有効化は段階的に行うことができます。つまり、すべてのイングレスルータ（通常はプロバイダエッジ (PE)）をCATS対応にアップグレードする必要はありません。
In addition to the CATS steering policies that are communicated by a C-PS to an Ingress CATS-Forwarder, some provisioning tasks are required. These include, but are not limited to:
C-PSからIngress CATS-Forwarderに通知されるCATSステアリングポリシーに加えて、いくつかのプロビジョニング作業が必要です。これには次のものが含まれますが、これらに限定されません。
* Providing C-PS elements with the locators of available Ingress CATS-Forwarders/C-TCs. Such locators may also be discovered from the network.
* C-PS要素に、利用可能なIngress CATS-Forwarder/C-TCのロケータを提供すること。このようなロケータは、ネットワークから検出される場合もあります。
* Supplying information needed to connect C-PS elements with C-NMAs and C-SMAs.
* C-PS要素をC-NMAおよびC-SMAに接続するために必要な情報を供給すること。
* Allocating identifiers CS-ID/CSCI-ID and binding them to specific service contact instances.
* 識別子CS-ID/CSCI-IDを割り当て、特定のサービスコンタクトインスタンスに関連付けること。
* Providing C-PS elements with the set of optimization metrics (per service) and an optimization policy.
* C-PS要素に、（サービスごとの）最適化メトリックの集合と最適化ポリシーを提供すること。
* Configuring specific encapsulation capabilities of CATS-Forwarders for use, including any credentials for mutual authentication between peer CATS-Forwarders.
* CATS-Forwarderが使用する特定のカプセル化機能を設定すること。これには、ピアのCATS-Forwarder間の相互認証のための認証情報も含まれます。
* Resetting the classification table of C-TC elements.
* C-TC要素の分類テーブルをリセットすること。
* Providing C-TCs with initial classification rules based on the classification capabilities (Section 5.2).
* 分類機能（5.2節）に基づく初期の分類ルールをC-TCに提供すること。
* Setting the traffic counters at CATS-Forwarders to ease correlation between both Ingress and Egress CATS-Forwarders. Such a correlation is needed to help identify issues induced by the underlying encapsulation.
* Ingress CATS-ForwarderとEgress CATS-Forwarderの間の相関付けを容易にするため、CATS-Forwarderのトラフィックカウンタを設定すること。このような相関付けは、基盤となるカプセル化に起因する問題の特定を支援するために必要です。
Provisioning includes configuration as well as distribution through protocols. Specifically, the above tasks can be enabled using a variety of means (NETCONF [RFC6241], IPFIX [RFC7011], RESTCONF [RFC8040], YANG notifications [RFC8639], etc.). It is out of scope to discuss required CATS extensions to these protocols.
Also, companion supervision and Operations, Administration, and Maintenance (OAM) tools are needed to drive CATS provisioning but also to assess the overall CATS operations. These include, but are not limited to:
また、CATSのプロビジョニングを進めるため、さらにCATS運用全体を評価するために、監視ツールおよびOperations, Administration, and Maintenance (OAM) ツールが併せて必要です。これには次のものが含まれますが、これらに限定されません。
* Exposing classification capabilities of C-TC elements.
* C-TC要素の分類機能を公開すること。
* Exposing encapsulation capabilities supported by CATS-Forwarders.
* CATS-Forwarderがサポートするカプセル化機能を公開すること。
* Retrieving the active classification table of C-TC elements.
* C-TC要素のアクティブな分類テーブルを取得すること。
* Retrieving active steering rules in CATS-Forwarders.
* CATS-Forwarder内のアクティブなステアリングルールを取得すること。
* Retrieving active installed policies in C-PSes.
* C-PS内にインストールされているアクティブなポリシーを取得すること。
* Retrieving the traffic counters at CATS-Forwarders to ease correlation between both Ingress and Egress CATS-Forwarders.
* Ingress CATS-ForwarderとEgress CATS-Forwarderの間の相関付けを容易にするため、CATS-Forwarderのトラフィックカウンタを取得すること。
* Enabling OAM tools to check the correct behavior of various entities (e.g., classification rules, steering rules, and forwarding behavior). See also Section 5.5.
* さまざまなエンティティ（分類ルール、ステアリングルール、転送動作など）の正しい動作を確認するためのOAMツールを有効にすること。5.5節も参照してください。
* Enabling OAM tools for performance measurement.
* 性能測定のためのOAMツールを有効にすること。
This document does not make any assumptions about how the various CATS functional elements are implemented and deployed. Concretely, whether a CATS deployment follows a fully distributed design or relies upon a mix of centralized (e.g., a centralized C-PS) and distributed CATS functions (e.g., C-TCs) is deployment specific, which may reflect the preferences and policies of the (CATS) service provider. The deployment can also be informed by specific use case requirements [RFC10054].
本文書は、CATSの各機能要素がどのように実装・展開されるかについて、いかなる前提も置きません。具体的には、CATSの展開が完全な分散型の設計に従うか、集中型（例：集中型C-PS）と分散型のCATS機能（例：C-TC）を組み合わせて用いるかは展開ごとに異なり、これは（CATS）サービスプロバイダの意向やポリシーを反映したものとなる場合があります。展開は、特定のユースケースの要件 [RFC10054] によっても方向づけられる場合があります。
For example, in a centralized design, both the computing-related metrics from the C-SMAs and the network metrics are collected by a (logically) centralized path computation logic (e.g., a PCE). In this case, the CATS computation logic may process incoming service requests to compute paths to service contact instances. More generally, the paths might be computed before a service request comes. Based on the metrics and computed paths, the C-PS can select the most appropriate path and then synchronize with C-TCs.
例えば、集中型の設計では、C-SMAからのコンピューティング関連メトリックとネットワークメトリックの両方が、（論理的に）集中化された経路計算ロジック（例：PCE）によって収集されます。この場合、CATSの計算ロジックは、到着したサービス要求を処理して、サービスコンタクトインスタンスへの経路を計算することがあります。より一般的には、経路はサービス要求が到着する前に計算されている場合もあります。C-PSは、メトリックと計算済みの経路に基づいて最も適切な経路を選択し、その後C-TCと同期することができます。
According to the method of distributing and collecting the computing metrics, three deployment models can be considered for the deployment of the CATS framework:
コンピューティングメトリックの配布および収集の方法に応じて、CATSフレームワークの展開には3つの展開モデルが考えられます。
*Distributed model*:
*分散モデル*:
Computing metrics are distributed among network devices directly using distributed protocols without interactions with a centralized control element (e.g., network controller). The service scheduling function is performed by the CATS-Forwarders in the distributed model; therefore, the C-PS is integrated into an Ingress CATS-Forwarder.
コンピューティングメトリックは、集中型の制御要素（例：ネットワークコントローラ）とやり取りすることなく、分散プロトコルを用いてネットワークデバイス間で直接配布されます。分散モデルでは、サービススケジューリング機能はCATS-Forwarderが実行します。そのため、C-PSはIngress CATS-Forwarderに統合されます。
*Centralized model*:
*集中モデル*:
Computing metrics are collected by centralized control elements. These elements then compute the forwarding path for service requests and sync up with Ingress CATS-Forwarders. In this model, C-PS is implemented in a centralized control element.
コンピューティングメトリックは、集中型の制御要素によって収集されます。これらの要素は、その後サービス要求に対する転送経路を計算し、Ingress CATS-Forwarderと同期します。このモデルでは、C-PSは集中型の制御要素に実装されます。
*Hybrid model*:
*ハイブリッドモデル*:
This is a combination of distributed and centralized models.
これは、分散モデルと集中モデルを組み合わせたものです。
A part of computing metrics is distributed among involved network devices, and others may be collected by a centralized control element. For example, some static information (e.g., capabilities information) can be distributed among network devices since they are quite stable (i.e., change infrequently). Frequently changing information (e.g., resource utilization) can be collected by a centralized control element to avoid frequent flooding in the distributed control plane. Service scheduling functions can be performed by a centralized control element, Ingress CATS-Forwarders (co-located with a C-PS), or both depending on the specific deployment policies.
コンピューティングメトリックの一部は関係するネットワークデバイス間で配布され、それ以外は集中型の制御要素によって収集される場合があります。例えば、静的な情報（例：能力情報）は非常に安定している（つまり、変化が少ない）ため、ネットワークデバイス間で配布できます。頻繁に変化する情報（例：リソース使用率）は、分散コントロールプレーンでの頻繁なフラッディングを避けるため、集中型の制御要素で収集できます。サービススケジューリング機能は、具体的な展開ポリシーに応じて、集中型の制御要素、（C-PSと同居する）Ingress CATS-Forwarder、またはその両方が実行できます。
When path computation is distributed, centralized control elements have to communicate the path information they collect to Ingress CATS-Forwarders (co-located with a C-PS) so that they take into account the full set of metrics for service scheduling.
経路計算が分散されている場合、集中型の制御要素は、収集した経路情報を（C-PSと同居する）Ingress CATS-Forwarderに伝えて、サービススケジューリングのためにメトリックの全体が考慮されるようにしなければなりません。
Examples to illustrate these models are provided in Appendix A.
これらのモデルを説明する例を付録Aに示します。
The framework covers only the case of a single service provider. Deployment considerations about the case of multiple service providers are out of scope.
このフレームワークが対象とするのは、単一のサービスプロバイダの場合のみです。複数のサービスプロバイダの場合に関する展開上の考慮事項は、対象外です。
Advertising per-instance computing-related metrics instead of aggregating them into per-site advertisements has scalability implications on involved CATS elements. Special care should be considered by providers when enabling per-instance metric distribution.
コンピューティング関連メトリックをサイトごとの通知に集約せず、インスタンスごとに通知すると、関係するCATS要素のスケーラビリティに影響します。インスタンスごとのメトリック配布を有効にする際、プロバイダは特に注意を払うべきです。
Computing metrics need to be normalized (i.e., convert metric values with or without units into unitless scores), aggregated, or a combination thereof in order to soften the scalability impact while providing sufficient detail for effective CATS decision making. For example, see [CATS-METRICS] for a discussion on metrics and distribution approaches.
スケーラビリティへの影響を和らげつつ、効果的なCATSの意思決定に十分な詳細を確保するには、コンピューティングメトリックを正規化（つまり、単位の有無にかかわらずメトリック値を単位のないスコアに変換）するか、集約するか、またはその両方を行う必要があります。例えば、メトリックと配布アプローチに関する議論は [CATS-METRICS] を参照してください。
Depending on the resources and processing capabilities of CATS components, the normalization and aggregation functions can be located in different CATS components. An approach is to implement the normalization and aggregation functions located away from C-PSes, especially when C-PSes are co-located with CATS-Forwarders. With this in mind, the normalization and aggregation functions of CATS metrics can be placed at service contact instances or C-SMAs.
CATSコンポーネントのリソースと処理能力に応じて、正規化機能と集約機能は異なるCATSコンポーネントに配置できます。1つのアプローチは、正規化機能と集約機能をC-PSから離して実装することです。これは特に、C-PSがCATS-Forwarderと同居している場合に当てはまります。これを踏まえると、CATSメトリックの正規化機能と集約機能は、サービスコンタクトインスタンスまたはC-SMAに配置できます。
When C-SMAs are co-located with CATS-Forwarders where there are limited resources for processing, the placement of normalization functions in a C-SMA may bring too much overhead and may influence the routing efficiency. Therefore, this document suggests implementing the normalization function at the service contact instances. Regarding the aggregation functions, it can be implemented in a C-SMA or the service contact instances.
C-SMAが処理リソースの限られたCATS-Forwarderと同じ場所に配置されている場合、C-SMAに正規化機能を置くと、オーバーヘッドが大きくなりすぎ、ルーティング効率に影響する可能性があります。したがって、本文書では、正規化機能をサービスコンタクトインスタンスに実装することを提案します。集約機能については、C-SMAまたはサービスコンタクトインスタンスに実装できます。
In order to ensure consistent CATS decisions, the same normalization and aggregation functions must be enabled in all involved CATS components. Also, in the case that service contact instances and C-SMAs are provided by different vendors, it is necessary to use the same common normalization and aggregation functions, so that the service contact instance selection result can be fair among all the service contact instances. To that aim, a set of normalization and aggregation functions must be standardized. To accommodate contexts where multiple functions are supported, CATS implementations must expose a configuration parameter to control the activation of normalization and aggregation functions.
CATSの決定の一貫性を確保するため、関係するすべてのCATSコンポーネントで同じ正規化機能と集約機能を有効にしなければなりません。また、サービスコンタクトインスタンスとC-SMAが異なるベンダーによって提供されている場合、サービスコンタクトインスタンスの選択結果がすべてのサービスコンタクトインスタンス間で公平になるよう、同じ共通の正規化機能と集約機能を使用する必要があります。そのために、正規化機能と集約機能の集合を標準化しなければなりません。複数の機能がサポートされる状況に対応するため、CATSの実装は、正規化機能と集約機能の有効化を制御する設定パラメータを公開しなければなりません。
A CATS implementation must log error events for better network management and operation. The means to assess the reachability and trace CATS paths should be supported.
CATSの実装は、ネットワークの管理と運用を向上させるため、エラーイベントを記録しなければなりません。到達可能性を評価し、CATSパスをトレースする手段がサポートされるべきです。
Computing metrics are collected and distributed in CATS. A new function needs to be deployed to manage the cooperation between network elements and computing elements. For example, this function may be provided by an orchestrator connecting with C-SMA and C-NMA. This might bring more complexity of the network management, especially if this function is not leveraged for other purposes beyond CATS.
CATSでは、コンピューティングメトリックが収集され、配布されます。ネットワーク要素とコンピューティング要素の間の連携を管理する新しい機能を展開する必要があります。たとえば、この機能は、C-SMAおよびC-NMAと接続するオーケストレータによって提供される場合があります。特にこの機能がCATS以外の目的に活用されない場合、ネットワーク管理がより複雑になる可能性があります。
The computing resource information changes over time very frequently, especially with the creation and termination of service instances. When such information is carried in a routing protocol, too many updates may affect network stability. This issue could be exploited by an attacker (e.g., by spawning and deleting service instances very rapidly). CATS solutions must support guards against such misbehaviors. For example, these solutions should support aggregation techniques, dampening mechanisms, and threshold-triggered distribution updates.
コンピューティングリソース情報は、特にサービスインスタンスの作成と終了に伴い、時間とともに非常に頻繁に変化します。このような情報がルーティングプロトコルで運ばれる場合、更新が多すぎるとネットワークの安定性に影響を及ぼす可能性があります。この問題は、攻撃者に悪用される可能性があります（たとえば、サービスインスタンスを非常に高速に生成・削除する方法）。CATSソリューションは、このような不正な動作に対する防御をサポートしなければなりません。たとえば、これらのソリューションは、集約技術、ダンプニングメカニズム、しきい値トリガ型の配布更新をサポートすべきです。
The information distributed by the C-SMAs and C-NMAs may be sensitive. Such information could indeed disclose intelligence about the network and the location of compute resources hosted in service sites. This information may be used by an attacker to identify weak spots in an operator's network. Furthermore, such information may be modified by an attacker, resulting in disrupted service delivery for the clients, even including misdirection of traffic to an attacker's service implementation. CATS solutions must support authentication and integrity-protection mechanisms between C-SMAs/C-NMAs and C-PSes and between C-PSes and Ingress CATS-Forwarders. Also, C-SMAs need to support a mechanism to authenticate the services for which they provide information to C-PS computation logics, among other CATS functions.
C-SMAおよびC-NMAによって配布される情報は、機微である可能性があります。実際、そのような情報は、ネットワークに関する情報や、サービスサイトでホストされているコンピューティングリソースの場所を漏らす可能性があります。この情報は、攻撃者が事業者のネットワークの弱点を特定するために使用される可能性があります。さらに、そのような情報は攻撃者によって改ざんされる可能性があり、その結果、クライアントに対するサービス提供が妨害され、さらにはトラフィックが攻撃者のサービス実装へ誤って誘導されることさえあります。CATSソリューションは、C-SMA/C-NMAとC-PSの間、およびC-PSとIngress CATS-Forwarderの間で、認証および完全性保護のメカニズムをサポートしなければなりません。また、C-SMAは、他のCATS機能に加えて、C-PSの計算ロジックに情報を提供する対象のサービスを認証するメカニズムをサポートする必要があります。
This document focuses on the scenario of a single service provider. Hence, security considerations relevant to deployment with multiple service providers are out of scope.
本文書は、単一のサービスプロバイダのシナリオに焦点を当てています。したがって、複数のサービスプロバイダでの展開に関連するセキュリティ上の考慮事項は、スコープ外です。
CATS solutions must support preventing on-path nodes in the underlay infrastructure from fingerprinting and tracking clients (e.g., determining which client accesses which service). More generally, personal data must not be exposed to external parties by CATS beyond what is carried in the packet that was originally issued by a client.
CATSソリューションは、アンダーレイインフラストラクチャ内のオンパスノードがクライアントのフィンガープリンティングや追跡（たとえば、どのクライアントがどのサービスにアクセスするかの判別）を行うことを防止する機能をサポートしなければなりません。より一般的には、CATSは、クライアントが最初に発行したパケットで運ばれる内容を超えて、個人データを外部の関係者に公開してはなりません。
CATS involves user-related data (e.g., access patterns or service requests) across service sites. Identifying a service site does not necessarily identify the service that is being invoked (typically, a service site may host many services, let alone that service instances may be relocated to other sites). However, when unambiguous correlation can be established between a service request and a service site, the binding of a service request and a service contact instance is sensitive, and such information should be encrypted.
CATSでは、サービスサイト全体にわたるユーザ関連データ（たとえば、アクセスパターンやサービス要求）が扱われます。サービスサイトを特定しても、呼び出されているサービスが必ずしも特定されるわけではありません（通常、1つのサービスサイトは多くのサービスをホストしている可能性があり、サービスインスタンスが他のサイトへ移動される場合もあります）。しかし、サービス要求とサービスサイトとの間に明確な相関関係を確立できる場合、サービス要求とサービスコンタクトインスタンスの結び付きは機微であり、そのような情報は暗号化されるべきです。
To prevent the information leaking between CATS components, the C-PS computed path information should be encrypted in distribution. The specific encryption method may be applied at the network layer, transport layer, or application layer depending on the implementation. As such, the exact implementation details are out of the scope of this document.
CATSコンポーネント間での情報漏えいを防ぐため、C-PSが計算したパス情報は、配布時に暗号化されるべきです。具体的な暗号化方式は、実装に応じて、ネットワーク層、トランスポート層、またはアプリケーション層で適用される場合があります。このため、実装の詳細は本文書のスコープ外です。
This document focuses on the scenario of a single service provider. Hence, privacy considerations relevant to deployment with multiple service providers are out of scope.
本文書は、単一のサービスプロバイダのシナリオに焦点を当てています。したがって、複数のサービスプロバイダでの展開に関連するプライバシー上の考慮事項は、スコープ外です。
This document has no IANA actions.
本文書には、IANAによる処理はありません。
[CATS-METRICS]
Yao, K., Li, C., Contreras, L. M., Ros-Giralt, J., and G.
Zeng, "CATS Metrics Definition", Work in Progress,
Internet-Draft, draft-ietf-cats-metric-definition-13, 29
September 2026, <https://datatracker.ietf.org/doc/html/
draft-ietf-cats-metric-definition-13>.
[CNIA-CATS]
Yao, H., wang, X., Li, Z., Huang, D., and C. Lin,
"Computing and Network Information Awareness (CNIA) system
architecture for CATS", Work in Progress, Internet-Draft,
draft-yao-cats-awareness-architecture-02, 22 October 2023,
<https://datatracker.ietf.org/doc/html/draft-yao-cats-
awareness-architecture-02>.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, <https://www.rfc-editor.org/info/rfc1034>.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, July 2002, <https://www.rfc-editor.org/info/rfc3261>.
[RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual Private Network (VPN) Terminology", RFC 4026, DOI 10.17487/RFC4026, March 2005, <https://www.rfc-editor.org/info/rfc4026>.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, DOI 10.17487/RFC4303, December 2005, <https://www.rfc-editor.org/info/rfc4303>.
[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, DOI 10.17487/RFC4655, August 2006, <https://www.rfc-editor.org/info/rfc4655>.
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, <https://www.rfc-editor.org/info/rfc5340>.
[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) Extensions: Extension Definitions", RFC 6066, DOI 10.17487/RFC6066, January 2011, <https://www.rfc-editor.org/info/rfc6066>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, <https://www.rfc-editor.org/info/rfc6241>.
[RFC6462] Cooper, A., "Report from the Internet Privacy Workshop", RFC 6462, DOI 10.17487/RFC6462, January 2012, <https://www.rfc-editor.org/info/rfc6462>.
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, DOI 10.17487/RFC6973, July 2013, <https://www.rfc-editor.org/info/rfc6973>.
[RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information", STD 77, RFC 7011, DOI 10.17487/RFC7011, September 2013, <https://www.rfc-editor.org/info/rfc7011>.
[RFC7149] Boucadair, M. and C. Jacquenet, "Software-Defined Networking: A Perspective from within a Service Provider Environment", RFC 7149, DOI 10.17487/RFC7149, March 2014, <https://www.rfc-editor.org/info/rfc7149>.
[RFC7426] Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S., Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software- Defined Networking (SDN): Layers and Architecture Terminology", RFC 7426, DOI 10.17487/RFC7426, January 2015, <https://www.rfc-editor.org/info/rfc7426>.
[RFC7471] Giacalone, S., Ward, D., Drake, J., Atlas, A., and S. Previdi, "OSPF Traffic Engineering (TE) Metric Extensions", RFC 7471, DOI 10.17487/RFC7471, March 2015, <https://www.rfc-editor.org/info/rfc7471>.
[RFC7826] Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M., and M. Stiemerling, Ed., "Real-Time Streaming Protocol Version 2.0", RFC 7826, DOI 10.17487/RFC7826, December 2016, <https://www.rfc-editor.org/info/rfc7826>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, <https://www.rfc-editor.org/info/rfc8040>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, <https://www.rfc-editor.org/info/rfc8200>.
[RFC8558] Hardie, T., Ed., "Transport Protocol Path Signals", RFC 8558, DOI 10.17487/RFC8558, April 2019, <https://www.rfc-editor.org/info/rfc8558>.
[RFC8570] Ginsberg, L., Ed., Previdi, S., Ed., Giacalone, S., Ward, D., Drake, J., and Q. Wu, "IS-IS Traffic Engineering (TE) Metric Extensions", RFC 8570, DOI 10.17487/RFC8570, March 2019, <https://www.rfc-editor.org/info/rfc8570>.
[RFC8571] Ginsberg, L., Ed., Previdi, S., Wu, Q., Tantsura, J., and C. Filsfils, "BGP - Link State (BGP-LS) Advertisement of IGP Traffic Engineering Performance Metric Extensions", RFC 8571, DOI 10.17487/RFC8571, March 2019, <https://www.rfc-editor.org/info/rfc8571>.
[RFC8639] Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard, E., and A. Tripathy, "Subscription to YANG Notifications", RFC 8639, DOI 10.17487/RFC8639, September 2019, <https://www.rfc-editor.org/info/rfc8639>.
[RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, <https://www.rfc-editor.org/info/rfc8754>.
[RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 (SRv6) Network Programming", RFC 8986, DOI 10.17487/RFC8986, February 2021, <https://www.rfc-editor.org/info/rfc8986>.
[RFC9112] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP/1.1", STD 99, RFC 9112, DOI 10.17487/RFC9112, June 2022, <https://www.rfc-editor.org/info/rfc9112>.
[RFC9522] Farrel, A., Ed., "Overview and Principles of Internet Traffic Engineering", RFC 9522, DOI 10.17487/RFC9522, January 2024, <https://www.rfc-editor.org/info/rfc9522>.
[RFC9849] Rescorla, E., Oku, K., Sullivan, N., and C. A. Wood, "TLS Encrypted Client Hello", RFC 9849, DOI 10.17487/RFC9849, March 2026, <https://www.rfc-editor.org/info/rfc9849>.
[RFC10054] Yao, K., Contreras, L. M., Shi, H., Zhang, S., and Q. An, "Computing-Aware Traffic Steering (CATS) Problem Statement, Use Cases, and Requirements", RFC 10054, DOI 10.17487/RFC10054, October 2026, <https://www.rfc-editor.org/info/rfc10054>.
This section provides examples to illustrate CATS metrics distribution. These examples are not deployment recommendations.
本節では、CATSメトリックの配布を説明するための例を示します。これらの例は、展開に関する推奨事項ではありません。
The following example mainly describes a per-instance computing-related metric distribution for illustration purposes. Such information may be aggregated into a single advertisement.
以下の例は、説明のために、主にインスタンスごとのコンピューティング関連メトリックの配布を記述しています。このような情報は、1つのアドバタイズメントに集約される場合があります。
Figure 3 shows an example of how CATS metrics can be disseminated in the distributed model.
図3は、分散モデルでCATSメトリックを伝達する方法の例を示しています。
There is a client attached to the network via "CATS-Forwarder 1". There are three service contact instances of the service with "CS-ID 1": two service contact instances with CSCI-IDs "1" and "2", respectively, are located at "Service Site 2" attached via "CATS-Forwarder 2"; the third service contact instance is located at "Service Site 3" attached via "CATS-Forwarder 3" and with "CSCI-ID 3". There is also a second service with "CS-ID 2" with only one service contact instance located at "Service Site 3".
「CATS-Forwarder 1」を介してネットワークに接続されたクライアントが1つあります。「CS-ID 1」のサービスには3つのサービスコンタクトインスタンスがあります。CSCI-ID がそれぞれ「1」と「2」の2つのサービスコンタクトインスタンスは、「CATS-Forwarder 2」を介して接続された「Service Site 2」にあります。3つ目のサービスコンタクトインスタンスは、「CATS-Forwarder 3」を介して接続された「Service Site 3」にあり、CSCI-ID は「3」です。また、「CS-ID 2」の2つ目のサービスもあり、そのサービスコンタクトインスタンスは「Service Site 3」にある1つだけです。
The C-SMA collocated with "CATS-Forwarder 2" distributes the computing metrics for both service contact instances (i.e., (CS-ID 1, CSCI-ID 1) and (CS-ID 1, CSCI-ID 2)). Similarly, the C-SMA located at "Service Site 3" advertises the computing metrics for the two services hosted by "Service Site 3". The C-SMA may distribute the computing metrics to the Egress "CATS-Forwarder 3". Then, the computing metrics can be redistributed by the Egress CATS-Forwarder to the Ingress CATS-Forwarder. The C-SMA also may directly distribute the computing metrics to the Ingress CATS-Forwarder.
「CATS-Forwarder 2」と同じ場所に配置されたC-SMAは、両方のサービスコンタクトインスタンス（すなわち、(CS-ID 1, CSCI-ID 1) と (CS-ID 1, CSCI-ID 2)）のコンピューティングメトリックを配布します。同様に、「Service Site 3」にあるC-SMAは、「Service Site 3」がホストする2つのサービスのコンピューティングメトリックをアドバタイズします。C-SMAは、コンピューティングメトリックをEgress 「CATS-Forwarder 3」に配布してもよいです。その後、コンピューティングメトリックは、Egress CATS-ForwarderからIngress CATS-Forwarderへ再配布できます。C-SMAは、コンピューティングメトリックをIngress CATS-Forwarderに直接配布することもできます。
The computing metrics advertisements are processed by the C-PS hosted by "CATS-Forwarder 1". The C-PS also processes network metric advertisements sent by the C-NMA. All metrics are used by the C-PS to select the most relevant path that leads to the Egress CATS-Forwarder according to the initial client's service request, the service that is requested ("CS-ID 1" or "CS-ID 2"), the state of the service contact instances as reported by the metrics, and the state of the network.
コンピューティングメトリックのアドバタイズメントは、「CATS-Forwarder 1」がホストするC-PSによって処理されます。C-PSは、C-NMAから送信されるネットワークメトリックのアドバタイズメントも処理します。C-PSは、すべてのメトリックを使用して、最初のクライアントのサービス要求、要求されたサービス（「CS-ID 1」または「CS-ID 2」）、メトリックによって報告されるサービスコンタクトインスタンスの状態、およびネットワークの状態に基づいて、Egress CATS-Forwarderに至る最も適切なパスを選択します。
In the case of distributing aggregated per-site computing-related metrics, the per-instance CSCI-ID information will not be included in the advertisement. Instead, a per-site CSCI-ID may be used in case multiple sites are connected to the Egress CATS-Forwarder to explicitly indicate the site from where the aggregated metrics come.
サイトごとに集約されたコンピューティング関連メトリックを配布する場合、インスタンスごとのCSCI-ID情報はアドバタイズメントに含まれません。その代わりに、複数のサイトがEgress CATS-Forwarderに接続されている場合には、集約されたメトリックの送信元のサイトを明示的に示すために、サイトごとのCSCI-IDを使用してもよい。
Service CS-ID 1, contact instance CSCI-ID 1 <computing metrics>
Service CS-ID 1, contact instance CSCI-ID 2 <computing metrics>
:<----------------------:
: : .---------.
: : | CS-ID 1 |
: : .--+CSCI-ID 1|
: .----------------. | '---------'
: | C-SMA +----+ Service Site 2
: |----------------| | .---------.
: |CATS-Forwarder 2| '--+ CS-ID 1 |
: '---------+------' |CSCI-ID 2|
.--------. : | '---------'
| Client | : Network .-------------+--------.
'----+---' : metrics | .-------. |
| : :<-------)-+ C-NMA | |
| : : | '-------' |
.----+----------------. | |
|CATS-Forwarder 1|C-PS|----| |
'---------------------' | Underlay |
: | Infrastructure | .---------.
: | | | CS-ID 1 |
: '---------+------------' .---+CSCI-ID 3|
: | | '---------'
: .------------+---. .-----+-.
: <-----+CATS-Forwarder 3+----+ C-SMA | Service Site 3
: '----------------' '-----+-'
: ^ : |
: | : | .-------.
: '-----------: '---+CS-ID 2|
: : '-------'
:<-------------------------------:
Service CS-ID 1, contact instance CSCI-ID 3 <computing metrics>
Service CS-ID 2, <computing metrics>
Figure 3: An Example of CATS Metric Dissemination in the Distributed Model
図3: 分散モデルにおけるCATSメトリック伝達の例
An example of metrics distribution in the centralized model is illustrated in Figure 4.
集中モデルにおけるメトリック配布の例を図4に示します。
The C-SMA collocated with "CATS-Forwarder 2" distributes the computing metrics for both service contact instances (i.e., (CS-ID 1, CSCI-ID 1) and (CS-ID 1, CSCI-ID 2)) to the centralized C-PS. In this case, the C-PS is a logically centralized element deployed separately with the "CATS-Forwarder 1". Similarly, the C-SMA located at "Service Site 3" advertises the computing metrics for the two services hosted by "Service Site 3" to the centralized C-PS as well. Furthermore, the C-PS receives the network metrics sent from the C-NMA. All metrics are used by the C-PS to select the most relevant path that leads to the Egress CATS-Forwarder. The selected paths will be sent from the C-PS to "CATS-Forwarder 1" to indicate traffic steering.
「CATS-Forwarder 2」と同じ場所に配置されたC-SMAは、両方のサービスコンタクトインスタンス（すなわち、(CS-ID 1, CSCI-ID 1) と (CS-ID 1, CSCI-ID 2)）のコンピューティングメトリックを、集中型のC-PSに配布します。この場合、C-PSは、「CATS-Forwarder 1」とは別に展開された、論理的に集中化された要素です。同様に、「Service Site 3」にあるC-SMAも、「Service Site 3」がホストする2つのサービスのコンピューティングメトリックを、集中型のC-PSにアドバタイズします。さらに、C-PSは、C-NMAから送信されるネットワークメトリックを受信します。C-PSは、すべてのメトリックを使用して、Egress CATS-Forwarderに至る最も適切なパスを選択します。選択されたパスは、トラフィックステアリングを指示するために、C-PSから「CATS-Forwarder 1」へ送信されます。
Service CS-ID 1, instance CSCI-ID 1 <computing metrics>
Service CS-ID 1, instance CSCI-ID 2 <computing metrics>
Service CS-ID 1, instance CSCI-ID 3 <computing metrics>
Service CS-ID 2, <computing metrics>
.------.
:<------+ C-PS |<--------------------------------------.
: | |<-------. .---------. |
: '------' | .---+CS-ID 1 | |
: ^ | | |CSCI-ID 1| |
: | .--------+-------. | '---------' |
: | | C-SMA +---+ Service Site 2 |
: | +----------------+ | .---------. |
: | |CATS-Forwarder 2| '---+CS-ID 1 | |
: | '---------+------' |CSCI-ID 2| |
: | | '---------' |
.--------. : | | |
| Client | : Network | .----------+-----------. .-----. |
'----+---' : metrics | | .-------. | | +-----'
| : '--)--+ C-NMA | | | |
| : | '--+----' | |C-SMA|
.----+-----------. | | | | |<----.
|CATS-Forwarder 1+<------)-----' | '-----' |
| +-------+ | ^ |
'----------------' | Underlay | | |
| Infrastructure | .-----+---. |
| | |CS-ID 1 | |
'---------+------------' |CSCI-ID 3| |
| '-+-------' |
.-------------+--. | |
|CATS-Forwarder 3+----------------' |
'-------------+--' Service Site 3 |
| .-------. |
'--------------+CS-ID 2+-------'
'-------'
Figure 4: An Example of CATS Metric Distribution in the Centralized Model
図4: 集中モデルにおけるCATSメトリック配布の例
An example of metrics distribution in the hybrid model is illustrated in Figure 5.
ハイブリッドモデルにおけるメトリック配布の例を図5に示します。
For example, the metrics 1, 2, and 3 associated with the "CS-ID 1" are collected by the centralized C-PS, and the metrics 4 and 5 are distributed via distributed protocols to the Ingress CATS-Forwarder directly. For a service with "CS-ID 2", all the metrics are collected by the centralized C-PS. The CATS-computed path result will be distributed to the Ingress CATS-Forwarders from the C-PS by considering both the metrics from the C-SMA and C-NMA. Furthermore, the Ingress CATS-Forwarder may also have some ability to compute the path for subsequent packets accessing the same service.
たとえば、「CS-ID 1」に関連付けられたメトリック1、2、3は集中型のC-PSによって収集され、メトリック4と5は分散プロトコルを介してIngress CATS-Forwarderに直接配布されます。「CS-ID 2」のサービスについては、すべてのメトリックが集中型のC-PSによって収集されます。CATSで計算されたパスの結果は、C-SMAとC-NMAの両方からのメトリックを考慮して、C-PSからIngress CATS-Forwarderに配布されます。さらに、Ingress CATS-Forwarderも、同じサービスにアクセスする後続のパケットについて、パスを計算する何らかの能力を持つ場合があります。
Service CS-ID 1, instance CSCI-ID 1 <computing metric 1,2,3>
Service CS-ID 1, instance CSCI-ID 2 <computing metric 1,2,3>
Service CS-ID 1, instance CSCI-ID 3 <computing metric 1,2,3>
Service CS-ID 2, <computing metrics>
.------.
:<------+ C-PS |<----------------------------------------.
: | |<-------. |
: '------' | .---------. |
: ^ | .---+CS-ID 1 | |
: | | | |CSCI-ID 1| |
: | .--------+-------. | '---------' |
: | | C-SMA +---+ Service Site 2 |
: | +----------------+ | .---------. |
: | |CATS-Forwarder 2| '---+CS-ID 1 | |
: | '---------+------' |CSCI-ID 2| |
.--------. : | | '---------' |
| Client | : Network | .---------+------------. .-----. |
'----+---' : metrics | | .-------. | | +-----'
| : '---)--+ C-NMA | | | |
| : | '-+-----' | |C-SMA+-----.
| : | | | | |<--. |
.----+-----------. | | | '-----' | |
|CATS-Forwarder 1|<--------)----' | ^ | |
| +---------+ Underlay | | | |
+----+-----------' | Infrastructure | .-------+-. | |
|C-PS| : | | |CS-ID 1 | | |
'----' : '---------+------------' |CSCI-ID 3| | |
: | '-+-------' | |
: .-------------+--. | | |
: |CATS-Forwarder 3+--------------' | |
: '-------------+--' Service Site 3 | |
: | .-------. | |
: '--------------+CS-ID 2+------' |
: '-------' |
:<-------------------------------------------------------'
Service CS-ID 1, contact instance CSCI-ID 3, <computing metric 4,5>
Figure 5: An Example of CATS Metric Distribution in the Hybrid Model
図5: ハイブリッドモデルにおけるCATSメトリック配布の例
The authors would like to thank Joel Halpern, John Scudder, Dino Farinacci, Adrian Farrel, Cullen Jennings, Linda Dunbar, Jeffrey Zhang, Peng Liu, Fang Gao, Aijun Wang, Cong Li, Xinxin Yi, Jari Arkko, Mingyu Wu, Haibo Wang, Xia Chen, Jianwei Mao, Guofeng Qian, Zhenbin Li, Xinyue Zhang, Weier Li, Quan Xiong, Nagendra Kumar, and Taylor Paul for their comments and suggestions.
著者らは、コメントと提案をくださった Joel Halpern、John Scudder、Dino Farinacci、Adrian Farrel、Cullen Jennings、Linda Dunbar、Jeffrey Zhang、Peng Liu、Fang Gao、Aijun Wang、Cong Li、Xinxin Yi、Jari Arkko、Mingyu Wu、Haibo Wang、Xia Chen、Jianwei Mao、Guofeng Qian、Zhenbin Li、Xinyue Zhang、Weier Li、Quan Xiong、Nagendra Kumar、Taylor Paul の各氏に感謝します。
Some text about various deployment models was originally documented in [CNIA-CATS].
さまざまな展開モデルに関する一部の文章は、もともと [CNIA-CATS] に記載されていました。
Special thanks to Adrian Farrel for the careful shepherd review and various suggestions that enhanced this document.
本文書の質を高める入念なシェパードレビューと様々な提案をいただいたAdrian Farrelに深く感謝します。
Thanks to Ines Robles and Linda Dunbar for the RTGDIR reviews, Giuseppe Fioccola and Gyan Mishra for the OPSDIR reviews, Thomas Fossati for the GENART review, Linda Dunbar for the SECDIR review, and Tommy Pauly for the TSVDIR review.
RTGDIRレビューをいただいたInes RoblesとLinda Dunbar、OPSDIRレビューをいただいたGiuseppe FioccolaとGyan Mishra、GENARTレビューをいただいたThomas Fossati、SECDIRレビューをいただいたLinda Dunbar、TSVDIRレビューをいただいたTommy Paulyに感謝します。
Thanks to Éric Vyncke, Ketan Talaulikar, Christopher Inacio, and Deb Cooley for the IESG review.
IESGレビューをいただいたÉric Vyncke、Ketan Talaulikar、Christopher Inacio、Deb Cooleyに感謝します。
Guangping Huang
ZTE
Email: huang.guangping@zte.com.cn
Gyan Mishra
Verizon Inc.
Email: hayabusagsm@gmail.com
Huijuan Yao
China Mobile
Email: yaohuijuan@chinamobile.com
Yizhou Li
Huawei Technologies
Email: liyizhou@huawei.com
Dirk Trossen
DaPaDOT Tech UG (haftungsbeschränkt)
Email: dirk@dapadot-tech.eu
Luigi Iannone
Huawei Technologies
Email: luigi.iannone@huawei.com
Hang Shi
Huawei Technologies
Email: shihang9@huawei.com
Changwang Lin
New H3C Technologies
Email: linchangwang.04414@h3c.com
Xueshun Wang
CICT
Email: xswang@fiberhome.com
Xuewei Wang
Ruijie Networks
Email: wangxuewei1@ruijie.com.cn
Christian Jacquenet
Orange
Email: christian.jacquenet@orange.com
Cheng Li (editor)
Huawei Technologies
China
Email: c.l@huawei.com
Zongpeng Du
China Mobile
China
Email: duzongpeng@chinamobile.com
Mohamed Boucadair (editor)
Orange
France
Email: mohamed.boucadair@orange.com
Luis M. Contreras
Telefonica
Spain
Email: luismiguel.contrerasmurillo@telefonica.com
John E Drake
Independent
United States of America
Email: je_drake@yahoo.com