[要約] このRFCは、コンピューティング対応トラフィックステアリング (CATS) の問題を整理し、単一ドメイン内のユースケースを示したうえで、CATSフレームワークに求められる要件を導き出す情報提供の文書です。エッジコンピューティングでは、最も近いサイトが最適とは限らないため、接続性のメトリックだけに頼らず、コンピューティングの能力や負荷といったメトリックも考慮して、適切なサービスインスタンスへトラフィックをステアリングする必要があります。ユースケースとして拡張現実や仮想現実、AI推論などを挙げ、サービス識別子の解決、メトリックの収集と配布、インスタンスアフィニティ、セキュリティとプライバシーに関する要件を定めています。
Internet Engineering Task Force (IETF) K. Yao
Request for Comments: 10054 China Mobile
Category: Informational L. M. Contreras
ISSN: 2070-1721 Telefonica
H. Shi
Huawei Technologies
S. Zhang
China Unicom
Q. An
Alibaba Group
October 2026
Distributed computing enhances service response time and energy efficiency by utilizing diverse computing facilities for compute-intensive and delay-sensitive services. To optimize throughput and response time, Computing-Aware Traffic Steering (CATS) selects servers and directs traffic based on compute capabilities and resources, rather than static dispatch or connectivity metrics alone. This document outlines the problem statement and scenarios for CATS within a single domain and drives requirements for the CATS framework.
分散コンピューティングは、計算集約型で遅延に敏感なサービスに対して多様なコンピューティング設備を活用することで、サービスの応答時間とエネルギー効率を向上させます。スループットと応答時間を最適化するため、コンピューティング対応トラフィックステアリング (CATS) は、静的なディスパッチや接続性メトリックのみに頼るのではなく、計算能力とリソースに基づいてサーバを選択し、トラフィックを振り向けます。本文書は、単一ドメイン内での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/rfc10054.
本文書の現在の状態、正誤表、およびフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc10054 で入手できます。
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. Definition of Terms 3. Problem Statement 3.1. Multi-Deployment of Edge Service Sites and Service 3.2. Traffic Steering Among Edge Service Sites and Service Instances 4. Use Cases 4.1. Overview of Use Cases 4.2. Example 1: Computing-Aware AR or VR 4.3. Example 2: Computing-Aware Intelligent Transportation 4.4. Example 3: Computing-Aware Digital Twin 4.5. Example 4: Computing-Aware SD-WAN 4.6. Example 5: Computing-Aware Distributed AI Training and Inference 4.6.1. Distributed AI Inference 4.6.2. Distributed AI Training 5. Requirements 5.1. Support Dynamic and Effective Selection Among Multiple Service Instances 5.2. Support Agreement on Metric Representation and Definition 5.3. Use of CATS Metrics 5.4. Support Instance Affinity 5.5. Preserve Communication Confidentiality 5.6. Correlation Between Use Cases and Requirements 6. Security Considerations 7. IANA Considerations 8. References 8.1. Normative References 8.2. Informative References Appendix A. An Additional CATS Use Case A.1. Integrated Sensing and Communications (ISAC) A.1.1. Requirements Acknowledgments Contributors Authors' Addresses
Computing resources, particularly edge computing resources, are increasingly being deployed to support services that require low latency, high reliability, and dynamic resource scaling.
コンピューティングリソース、特にエッジコンピューティングリソースは、低遅延、高信頼性、動的なリソーススケーリングを必要とするサービスを支えるために、ますます展開が進んでいます。
Diversified service demands have brought key challenges to service deployment and traffic scheduling. A single-site service instance often lacks sufficient capacity to guarantee the required quality of service, especially during peak hours when local computing resources may fail to handle all incoming requests, leading to longer response times or even request drops. Regular capacity expansion of a single site is often neither practical nor economical. Additionally, relying solely on computing capability enhancements of client devices cannot meet the computing requirements of all applications.
サービス需要の多様化は、サービスの展開とトラフィックのスケジューリングに重要な課題をもたらしました。単一サイトのサービスインスタンスでは、必要なサービス品質を保証するための容量が不足することが多く、特にピーク時間帯には、ローカルのコンピューティングリソースがすべての着信要求を処理しきれず、応答時間の増大や要求の破棄にまで至ることがあります。単一サイトの容量を定期的に拡張することは、実用的でも経済的でもないことが少なくありません。さらに、クライアントデバイスの計算能力の強化だけに頼っても、すべてのアプリケーションの計算要件を満たすことはできません。
It is necessary to deploy services across multiple sites (either edge or central nodes) to improve availability and scalability. To this end, traffic should be steered to the "best" service instance based on factors like current computing load, where "best" is largely determined by application requirements.
可用性とスケーラビリティを向上させるには、複数のサイト (エッジノードまたは中央ノードのいずれか) にまたがってサービスを展開する必要があります。そのためには、現在のコンピューティング負荷などの要因に基づいて、トラフィックを「最良の」サービスインスタンスへステアリングすべきです。ここで「最良」とは、主にアプリケーションの要件によって決まります。
However, existing routing schemes and traffic engineering methods often fall short of addressing these challenges. The underlying networking infrastructures that include computing resources usually provide relatively static service dispatching or depend solely on connectivity metrics for traffic steering, failing to account for compute capabilities and resource status, which are critical for meeting the quality requirements of modern services.
しかし、既存のルーティング方式やトラフィックエンジニアリング手法では、これらの課題に十分に対処できないことがよくあります。コンピューティングリソースを含む基盤ネットワークインフラは、通常、比較的静的なサービスディスパッチを提供するか、トラフィックステアリングを接続性メトリックのみに依存しており、現代のサービスの品質要件を満たす上で重要な、計算能力とリソース状態を考慮できていません。
To tackle this issue, the choice of service instance and network resources should further consider compute-oriented metrics beyond connectivity metrics. The process of selecting service instances and locations based on metrics that are oriented towards compute capabilities and resources, and of directing traffic to them on chosen network resources, is called Computing-Aware Traffic Steering (CATS). It should be noted that CATS is not limited to edge computing scenarios; however, Section 3 of this document will focus on edge computing scenarios for problem statement.
この問題に取り組むには、サービスインスタンスとネットワークリソースの選択において、接続性メトリックに加えて、計算指向のメトリックをさらに考慮すべきです。計算能力とリソースを指向するメトリックに基づいてサービスインスタンスとロケーションを選択し、選択したネットワークリソース上でそれらへトラフィックを振り向けるプロセスは、コンピューティング対応トラフィックステアリング (CATS) と呼ばれます。CATSはエッジコンピューティングのシナリオに限定されるものではないことに注意すべきですが、本文書のセクション3では、問題定義のためにエッジコンピューティングのシナリオに焦点を当てます。
This document describes sample usage scenarios that drive CATS requirements and will help to identify candidate solution architectures and approaches. The use cases and requirements within this document are limited to single-domain scenarios.
本文書は、CATSの要件を導き、候補となるソリューションのアーキテクチャやアプローチの特定に役立つ、利用シナリオの例を記述します。本文書内のユースケースと要件は、単一ドメインのシナリオに限定されます。
This document uses the terms defined in [RFC10053], including service site, service instance, CATS Service ID (CS-ID), flow, and client.
本文書は、[RFC10053] で定義されている用語を使用します。これには、サービスサイト (service site)、サービスインスタンス (service instance)、CATS Service ID (CS-ID)、フロー (flow)、クライアント (client) が含まれます。
Edge Computing:
エッジコンピューティング (Edge Computing):
Edge computing is a computing pattern that moves computing infrastructures, i.e., servers, away from centralized data centers and instead places them close to the end users for low-latency communication.
エッジコンピューティングとは、コンピューティングインフラ、すなわちサーバを集中型データセンターから切り離し、低遅延通信のためにエンドユーザの近くに配置するコンピューティングパターンです。
Even though this document is not a protocol specification, it makes use of upper case key words to define requirements unambiguously.
本文書はプロトコル仕様ではありませんが、要件を曖昧さなく定義するために大文字のキーワードを使用します。
In edge computing environments, service instances typically adopt a multi-site deployment model. It should be clarified that specific service instance deployment strategies are not within the scope of CATS. However, there is a close correlation between service instance deployment and traffic scheduling, especially in the definition and selection of core metrics such as computing capabilities and resources. This dual applicability allows a common set of metrics to inform both traffic steering and higher-level service management decisions, without requiring CATS to define orchestration behavior.
エッジコンピューティング環境では、サービスインスタンスは通常、マルチサイト展開モデルを採用します。具体的なサービスインスタンスの展開戦略はCATSの対象範囲外であることを明確にしておくべきです。しかし、特に計算能力やリソースといった中核的なメトリックの定義と選択において、サービスインスタンスの展開とトラフィックのスケジューリングの間には密接な相関があります。この二重の適用性により、CATSがオーケストレーションの動作を定義することを必要とせずに、共通のメトリック群をトラフィックステアリングと上位レベルのサービス管理の判断の両方に活用できます。
Therefore, to present a clear and comprehensive problem statement, it is necessary to first introduce the relevant considerations for multi-edge service site deployment. This premise can better support the subsequent elaboration on CATS requirements and solutions.
したがって、明確かつ包括的な問題定義を示すためには、まずマルチエッジサービスサイト展開に関する考慮事項を紹介する必要があります。この前提により、その後のCATSの要件とソリューションに関する詳細な説明をよりよく支えることができます。
Before deploying edge service sites, the following factors need to be considered:
エッジサービスサイトを展開する前に、次の要因を考慮する必要があります。
* Geographic location, including the number of users, differences in service types, and the number of connection requests from users. For edge service sites located in densely populated areas with a large number of users and service requests, more service replicas can be deployed compared to other areas.
* 地理的位置。ユーザ数、サービスタイプの違い、ユーザからの接続要求数を含みます。ユーザ数とサービス要求数が多い人口密集地域にあるエッジサービスサイトには、他の地域と比べてより多くのサービスレプリカを展開できます。
* The type, scale, and usage frequency of required computing resources, for example, distributed AI inference services require the deployment of more Graphics Processing Unit (GPU) resources.
* 必要なコンピューティングリソースの種類、規模、使用頻度。たとえば、分散AI推論サービスでは、より多くのGraphics Processing Unit (GPU) リソースを展開する必要があります。
* The status of network resources associated with computing resources, such as network topology, network access methods, connectivity, link bandwidth, and path protection or redundancy information.
* コンピューティングリソースに関連付けられたネットワークリソースの状態。たとえば、ネットワークトポロジ、ネットワークアクセス方式、接続性、リンク帯域幅、パス保護または冗長性の情報などです。
To improve the overall quality of service, during the service deployment phase, it is necessary to analyze the approximate network and computing resource requirements of the service, comprehensively form a reasonable network and computing resource topology, and clarify the location, overall distribution, and relative position of computing resources in the network topology. This process relies on standardized consensus on computing and network resources related metrics, which is also the point most closely related to the problem space addressed by CATS traffic scheduling.
サービス全体の品質を向上させるには、サービス展開フェーズにおいて、サービスのおおよそのネットワークおよびコンピューティングリソース要件を分析し、合理的なネットワークとコンピューティングリソースのトポロジを総合的に構成し、ネットワークトポロジ内でのコンピューティングリソースの位置、全体的な分布、相対的な配置を明確にする必要があります。このプロセスは、コンピューティングリソースとネットワークリソースに関連するメトリックについての標準化されたコンセンサスに依存しており、これはCATSのトラフィックスケジューリングが扱う問題領域に最も密接に関連する点でもあります。
This section describes how existing edge computing systems do not provide all of the support needed for real-time or near-real-time services and how it is necessary to steer traffic to different sites considering changes in client distribution, different time slots, events, server loads, network capabilities, and some other factors that might not be directly measured (i.e., properties of edge service sites such as geographical location, etc.).
本セクションでは、既存のエッジコンピューティングシステムがリアルタイムまたはニアリアルタイムのサービスに必要なサポートをすべて提供しているわけではないこと、そして、クライアント分布の変化、時間帯の違い、イベント、サーバ負荷、ネットワーク能力、およびその他の直接測定できないかもしれない要因 (すなわち、地理的位置などのエッジサービスサイトの特性) を考慮して、トラフィックを異なるサイトへステアリングする必要があることを説明します。
It is assumed that service instances are multi-site deployed, and they are reachable through a network infrastructure.
サービスインスタンスはマルチサイトに展開され、ネットワークインフラを通じて到達可能であると想定します。
When a client issues a service request for a required service, the request is steered to one of the available service instances. Each service instance may act as a client towards another service, thereby seeing its own outbound traffic steered to a suitable service instance of the requested service and so on, achieving service composition and chaining as a result.
クライアントが必要なサービスに対するサービス要求を発行すると、その要求は利用可能なサービスインスタンスのいずれかへステアリングされます。各サービスインスタンスは、別のサービスに対するクライアントとして動作してもよく、その結果、自身の送信トラフィックが、要求されたサービスの適切なサービスインスタンスへステアリングされ、以下同様に続くことで、サービスの合成とチェーン化が実現されます。
The aforementioned selection of a service instance from the set of candidates is performed using traffic steering methods.
上記の候補集合からのサービスインスタンスの選択は、トラフィックステアリング手法を用いて行われます。
In edge computing, traffic is steered to an edge service site that is "closest" or to one of a few "close" sites using load balancing. Such traffic steering can be initiated either by the application layer or by the network layer: The application layer may actively query for the optimal node and guide traffic using mechanisms such as the Application-Layer Traffic Optimization (ALTO) protocol [RFC7285], while the network layer may leverage Anycast routing [RFC4786], where routing systems automatically distribute traffic according to routing tables in an application-transparent manner. However, regardless of whether the steering is performed by the application or the network, the core criteria for selecting "closest" or "close" sites often rely solely on communication metrics (such as physical distance, hop count, or network latency). This decision logic can easily lead to suboptimal choices, meaning that the "closest" site is not always the "best" one. This is because the computing resources and states of edge service sites can change in real time:
エッジコンピューティングでは、トラフィックは、ロードバランシングを用いて「最も近い」エッジサービスサイト、または「近い」いくつかのサイトのいずれかへステアリングされます。このようなトラフィックステアリングは、アプリケーション層またはネットワーク層のいずれかが開始できます。アプリケーション層は、Application-Layer Traffic Optimization (ALTO) プロトコル [RFC7285] などのメカニズムを用いて、最適なノードを能動的に問い合わせ、トラフィックを誘導することがあります。一方、ネットワーク層は、エニーキャスト(Anycast)ルーティング [RFC4786] を活用することがあり、そこではルーティングシステムが、アプリケーションに透過的な方法で、ルーティングテーブルに従ってトラフィックを自動的に分散します。しかし、ステアリングをアプリケーションが行うかネットワークが行うかにかかわらず、「最も近い」または「近い」サイトを選択する中核的な基準は、(物理的距離、ホップ数、ネットワーク遅延などの) 通信メトリックのみに依存していることが多くあります。この判断ロジックは、最適とはいえない選択につながりやすく、つまり「最も近い」サイトが常に「最良」とは限りません。これは、エッジサービスサイトのコンピューティングリソースと状態がリアルタイムで変化し得るためです。
* The closest site may not have sufficient resources.
* 最も近いサイトに十分なリソースがない場合があります。
* The closest site may not have the specific computing resources required.
* 最も近いサイトには、必要な特定のコンピューティングリソースがない場合があります。
To address these issues, enhancements to traffic steering mechanisms are needed to direct traffic to sites that can adequately support the requested services. Steering decisions may take into account more complex and possibly dynamic metric information, such as load of service instances, latency experienced, or similar, for selection of a more suitable service instance.
これらの問題に対処するには、要求されたサービスを適切にサポートできるサイトへトラフィックを誘導するよう、トラフィックステアリングのメカニズムを拡張する必要があります。ステアリングの判断では、より適切なサービスインスタンスを選択するために、サービスインスタンスの負荷や経験されたレイテンシなど、より複雑で、場合によっては動的なメトリック情報を考慮することがあります。
It is important to note that clients may move. This means that the service instance that was "best" at one moment might no longer be best when a new service request is issued. This creates a (physical) dynamicity that will need to be catered to in addition to the changes in server and network load. From a routing perspective, CATS is an application-transparent routing mechanism that can provide scheduling for both stateful and stateless services. However, in scenarios where clients move and the service is stateful, CATS requires the application to explicitly indicate whether it allows the routing system to enable CATS functionality. Otherwise, mid-session scheduling triggered by CATS may cause application context inconsistency among service sites or even service interruption.
クライアントは移動する可能性があることに注意することが重要です。これは、ある時点で「最良」だったサービスインスタンスが、新しいサービス要求が発行されるときにはもはや最良ではなくなっている可能性があることを意味します。これにより、サーバーおよびネットワークの負荷の変化に加えて、(物理的な) 動的性にも対応する必要が生じます。ルーティングの観点では、CATS はアプリケーションに対して透過的なルーティングメカニズムであり、ステートフルなサービスとステートレスなサービスの両方に対してスケジューリングを提供できます。しかし、クライアントが移動し、かつサービスがステートフルであるシナリオでは、CATS は、ルーティングシステムが CATS の機能を有効にすることを許可するかどうかを、アプリケーションが明示的に示すことを必要とします。そうしない場合、CATS によって引き起こされるセッション途中のスケジューリングにより、サービスサイト間でアプリケーションコンテキストの不整合が生じたり、サービスの中断さえ生じたりする可能性があります。
Figure 1 shows a common way to deploy edge service sites in the metro. Edge service sites are connected with Provider Edges (PEs). There is an edge data center for a metro area, which has high computing resources and provides the service to more User Equipment (UE) (UE1 to UEn) at the working time. This is because more office buildings are in the metro area. In addition, there are also some remote edge service sites that have limited computing resources and provide the service to the UE (UEa, UEb) close to them.
図1は、メトロにエッジサービスサイトを展開する一般的な方法を示しています。エッジサービスサイトは Provider Edge (PE) に接続されます。メトロエリアには1つのエッジデータセンターがあり、豊富なコンピューティングリソースを持ち、勤務時間中はより多くの User Equipment (UE) (UE1 から UEn) にサービスを提供します。これは、メトロエリアにはオフィスビルが多いためです。加えて、限られたコンピューティングリソースしか持たず、近くにある UE (UEa、UEb) にサービスを提供するリモートエッジサービスサイトもいくつかあります。
Applications to meet service demands could be deployed in both the edge data center in the metro area and the remote edge service sites. In this case, the service request and the resource are matched well. Some potential traffic steering may be needed just for a special service request or some small scheduling demand.
サービス需要を満たすアプリケーションは、メトロエリアのエッジデータセンターとリモートエッジサービスサイトの両方に展開される可能性があります。この場合、サービス要求とリソースはよく一致しています。特別なサービス要求や小規模なスケジューリング需要のためだけに、一部のトラフィックステアリングが必要になることがあります。
+----------------+ +---+ +------------+
+----------------+ |- - |UE1| +------------+ |
| +-----------+ | | +---+ +--| Edge | |
| |Edge server| | | +---+ +- - -|PE| | |
| +-----------+ | |- - |UE2| | +--| Site 1 |-+
| +-----------+ | | +---+ +------------+
| |Edge server| | | ... | |
| +-----------+ | +--+ Potential +---+ +---+
| +-----------+ | |PE|- - - - - - -+ |UEa| |UEb|
| |Edge server| | +--+ Steering +---+ +---+
| +-----------+ | | +---+ | |
| +-----------+ | |- - |UE3| +------------+
| | ... ... | | | +---+ | +------------+ |
| +-----------+ | | ... +--| Edge | |
| | | +---+ +- - -|PE| | |
|Edge data center|-+- - |UEn| +--| Site 2 |-+
+----------------+ +---+ +------------+
High computing resources Limited computing resources
and more UE at metro area and less UE at remote area
Figure 1: Common Deployment of Edge Service Sites
図1: エッジサービスサイトの一般的な展開
Figure 2 shows that during non-working hours (e.g., during the weekend or at night), more UE moves to the remote areas that are close to their house (e.g., for some weekend events). This means there will be more service requests at the remote areas, but with limited computing resources, whereas the rich computing resources might not be used with less UE in the metro area. It is possible for many people to request services at the remote area, but with the limited computing resource, moreover, as the people move from the metro area to the remote area, the edge service sites that serve common services will also change, so it may be necessary to steer some traffic back to the metro data center.
図2は、非勤務時間帯 (たとえば週末や夜間) には、より多くの UE が自宅に近いリモートエリアへ移動する (たとえば週末のイベントのため) ことを示しています。これは、リモートエリアではサービス要求が増える一方でコンピューティングリソースが限られており、メトロエリアでは UE が減るため豊富なコンピューティングリソースが使われない可能性があることを意味します。多くの人々がリモートエリアでサービスを要求する可能性がありますが、そこではコンピューティングリソースが限られています。さらに、人々がメトロエリアからリモートエリアへ移動するにつれて、一般的なサービスを提供するエッジサービスサイトも変化するため、一部のトラフィックをメトロのデータセンターへ戻してステアリングする必要が生じる可能性があります。
+----------------+ +------------+
+----------------+ | +------------+ |
| +-----------+ | | Steering traffic +--| Edge | |
| |Edge server| | | +-----------|PE| | |
| +-----------+ | | | +--| Site 1 |-+
| +-----------+ | |- - - - - - - -+ +-+----------+
| |Edge server| | | | | | |
| +-----------+ | +--+ | +---+ +---+ +---+ +---+ +---+
| +-----------+ | |PE|-------+ |UEa| |UEb| |UE1| |...| |UEn|
| |Edge server| | +--+ | +---+ +---+ +---+ +---+ +---+
| +-----------+ | | | | |
| +-----------+ | |- - - - - - - - - - -+ +------+
| | ... ... | | | | +------------+ |
| +-----------+ | | | +--| Edge | |
| | | +-----------|PE| | |
|Edge data center|-+ Steering traffic +--| Site 2 |-+
+----------------+ +------------+
High computing resources Limited computing resources
and less UE at metro area and more UE at remote area
Figure 2: Steering Traffic Among Edge Service Sites
図2: エッジサービスサイト間でのトラフィックのステアリング
There will also be the common variable of network and computing resources for someone who is not moving but experiences poor latency sometimes. Because of other UE moving, there will be a large number of requests for temporary events (e.g., vocal concerts, shopping festivals, and so on), and there will also be the normal change of the network and computing resource status. So for some fixed UE, the traffic is also expected to be steered to appropriate sites dynamically.
移動していなくても、ときどき低いレイテンシを経験する人にとっては、ネットワークリソースとコンピューティングリソースに一般的な変動もあります。他の UE が移動することにより、一時的なイベント (たとえば、ボーカルコンサートやショッピングフェスティバルなど) に対する大量の要求が発生し、ネットワークおよびコンピューティングリソースの状態にも通常の変化が生じます。したがって、一部の固定 UE についても、トラフィックは動的に適切なサイトへステアリングされることが期待されます。
Those problems indicate that traffic needs to be steered among different edge service sites, because of the mobility of the UE and the common variable of network and computing resources. Moreover, some use cases in the following section require both low latency and high computing resource usage or specific computing hardware capabilities (such as a local GPU); hence, joint optimization of network and computing resources is needed to guarantee the Quality of Experience (QoE).
これらの問題は、UE の移動性と、ネットワークおよびコンピューティングリソースの一般的な変動のために、異なるエッジサービスサイト間でトラフィックをステアリングする必要があることを示しています。さらに、以下の節のユースケースの中には、低レイテンシと高いコンピューティングリソース使用率の両方、または特定のコンピューティングハードウェア機能 (ローカル GPU など) を必要とするものがあります。したがって、Quality of Experience (QoE) を保証するには、ネットワークリソースとコンピューティングリソースの共同最適化が必要です。
The five use cases outlined in the sections below serve as examples to show the need for CATS. In particular, while these use cases may be solved in a simplistic way with current tools, CATS adds the ability to make dynamic selection between service sites and service instances to take account of network capabilities and status, compute capabilities and current load, and achieve load balancing.
以下の節で概説する5つのユースケースは、CATS の必要性を示す例として挙げています。特に、これらのユースケースは現在のツールを用いて単純な方法で解決できるかもしれませんが、CATS は、ネットワークの能力と状態、コンピューティング能力と現在の負荷を考慮してサービスサイトとサービスインスタンスの間で動的な選択を行い、ロードバランシングを実現する能力を追加します。
Considering that these use cases are enough to derive common requirements, this document only includes these five use cases in the main body, although there have been more similar use cases proposed in the CATS Working Group (e.g., [CATS-REQS]). The applicability of CATS may be further extended in future use cases brought to the working group and may possibly arise from work in other standards bodies such as ETSI and 3GPP, but it is believed that the five use cases presented here are sufficient to drive the requirements expressed in this document and future applicability.
これらのユースケースは共通の要件を導き出すのに十分であると考えられるため、CATS ワーキンググループではより多くの類似のユースケースが提案されている (たとえば [CATS-REQS]) ものの、本書では本文にこれら5つのユースケースのみを含めます。CATS の適用可能性は、今後ワーキンググループに持ち込まれるユースケースや、ETSI や 3GPP などの他の標準化団体での作業から生じる可能性のあるユースケースによって、さらに拡張される可能性があります。しかし、ここで示す5つのユースケースは、本書で述べる要件と将来の適用可能性を導くのに十分であると考えられています。
If new use cases do raise additional requirements, they will need to be documented separately and might necessitate modifications to the CATS framework [RFC10053].
新しいユースケースが追加の要件を生じさせる場合、それらは別途文書化する必要があり、CATS フレームワーク [RFC10053] の変更が必要になる可能性があります。
Further potential use cases are attached in Appendix A of this document.
その他の潜在的なユースケースは、本書の付録 A に添付しています。
Cloud Virtual Reality (VR) and Augmented Reality (AR) introduce the concept of cloud computing to the rendering of audiovisual assets in such applications. Here, the edge cloud helps encode/decode and render content. The edge cloud refers to cloud computing located at the edge of the network in order to be closer to users and applications. The client device usually only uploads posture or control information to the edge cloud, and then VR/AR contents are rendered in the edge cloud. The video and audio outputs generated from the edge cloud are encoded, compressed, and transmitted back to the client device or further transmitted to a central data center via high-bandwidth networks.
クラウド Virtual Reality (VR) および Augmented Reality (AR) は、こうしたアプリケーションにおける視聴覚アセットのレンダリングにクラウドコンピューティングの概念を導入します。ここでは、エッジクラウドがコンテンツのエンコード/デコードとレンダリングを支援します。エッジクラウドとは、ユーザーやアプリケーションにより近づけるために、ネットワークのエッジに配置されたクラウドコンピューティングを指します。クライアントデバイスは通常、姿勢情報や制御情報のみをエッジクラウドにアップロードし、VR/AR コンテンツはエッジクラウドでレンダリングされます。エッジクラウドで生成された映像および音声の出力は、エンコードおよび圧縮され、クライアントデバイスへ送り返されるか、高帯域幅ネットワークを介して中央データセンターへさらに送信されます。
A cloud VR service is delay sensitive and influenced by both network and computing resources. Therefore, the edge service site that executes the service has to be carefully selected to make sure it has sufficient computing resources and good network conditions to guarantee the end-to-end service delay. For example, for an entry-level cloud VR (panoramic 8K 2D video) with 110-degree Field of View (FOV) transmission, the typical network requirements are a bandwidth of 40Mbps, a 20ms motion-to-photon latency, and a packet loss rate of 2.4E-5; the typical computing requirements are 8K H.265 real-time decoding and 2K H.264 real-time encoding. Further, the 20ms latency can be categorized as:
クラウド VR サービスは遅延に敏感であり、ネットワークリソースとコンピューティングリソースの両方の影響を受けます。したがって、サービスを実行するエッジサービスサイトは、エンドツーエンドのサービス遅延を保証するのに十分なコンピューティングリソースと良好なネットワーク状態を備えていることを確実にするため、慎重に選択する必要があります。たとえば、110度の Field of View (FOV) 伝送によるエントリーレベルのクラウド VR (パノラマ 8K 2D 映像) では、典型的なネットワーク要件は、帯域幅 40Mbps、motion-to-photon レイテンシ 20ms、パケット損失率 2.4E-5 であり、典型的なコンピューティング要件は、8K H.265 リアルタイムデコードと 2K H.264 リアルタイムエンコードです。さらに、20ms のレイテンシは次のように分類できます。
1. The sensor sampling delay (client), which is considered imperceptible by users, is less than 1.5ms including an extra 0.5ms for digitalization and client device processing.
1. センサーのサンプリング遅延 (クライアント) はユーザーに知覚されないと考えられており、デジタル化とクライアントデバイスの処理のための追加の 0.5ms を含めて 1.5ms 未満です。
2. The display refresh delay (client), which takes 7.9ms based on the 144Hz display refreshing rate and a 1ms extra delay to light up.
2. ディスプレイのリフレッシュ遅延 (クライアント) は、144Hz のディスプレイリフレッシュレートに基づく 7.9ms と、点灯するための追加遅延 1ms です。
3. The image/frame rendering delay (server), which could be reduced to 5.5ms.
3. 画像/フレームのレンダリング遅延 (サーバー) は、5.5ms まで短縮できます。
4. The round-trip network delay, which is the remaining latency budget, is 5.1ms, calculated as 20-1.5-5.5-7.9 = 5.1ms.
4. 残りのレイテンシ予算であるネットワークのラウンドトリップ遅延は 5.1ms で、20-1.5-5.5-7.9 = 5.1ms と計算されます。
Therefore, the budgets for the server (computing) delay and the network delay are almost equivalent, which means it makes sense to consider both the delay for computing and the network. In addition, it could not meet the total delay requirements or find the best choice by either optimizing the network or computing resource.
したがって、サーバー (コンピューティング) 遅延とネットワーク遅延の予算はほぼ同等であり、コンピューティングとネットワークの両方の遅延を考慮することに意味があることを示しています。加えて、ネットワークまたはコンピューティングリソースのどちらか一方を最適化するだけでは、合計遅延要件を満たすことも、最良の選択肢を見つけることもできない可能性があります。
Based on the analysis, here are some further assumptions. As Figure 3 shows, the client could request any service instance among 3 edge service sites. The delay of the client could be the same, and the differences of edge service sites and corresponding network paths have different delays:
この分析に基づき、さらにいくつかの仮定を置きます。図3に示すように、クライアントは3つのエッジサービスサイトのうち任意のサービスインスタンスを要求できます。クライアントの遅延は同じである可能性がありますが、エッジサービスサイトと対応するネットワーク経路の違いにより、遅延は異なります。
* Edge service site 1: The computing delay is 4ms based on a light load, and the corresponding network delay is 9ms based on heavy traffic.
* エッジサービスサイト1: 軽い負荷に基づくコンピューティング遅延は 4ms であり、重いトラフィックに基づく対応するネットワーク遅延は 9ms です。
* Edge service site 2: The computing delay is 10ms based on a heavy load, and the corresponding network delay is 4ms based on light traffic.
* エッジサービスサイト2: 重い負荷に基づくコンピューティング遅延は 10ms であり、軽いトラフィックに基づく対応するネットワーク遅延は 4ms です。
* Edge service site 3: The computing delay is 5ms based on a normal load, and the corresponding network delay is 5ms based on normal traffic.
* エッジサービスサイト3: 通常の負荷に基づくコンピューティング遅延は 5ms であり、通常のトラフィックに基づく対応するネットワーク遅延は 5ms です。
In this case, the optimal network and computing delay total cannot be achieved if choosing the resource only based on either computing or network status:
この場合、コンピューティングの状態またはネットワークの状態のどちらか一方のみに基づいてリソースを選択すると、ネットワーク遅延とコンピューティング遅延の合計を最適にすることはできません。
* The edge service site based on the best computing delay will be the edge service site 1, and the end-to-end (E2E) delay is 22.4ms.
* 最良のコンピューティング遅延に基づくエッジサービスサイトはエッジサービスサイト1となり、エンドツーエンド (E2E) 遅延は 22.4ms です。
* The edge service site based on the best network delay will be the edge service site 2, and the E2E delay is 23.4ms.
* 最良のネットワーク遅延に基づくエッジサービスサイトはエッジサービスサイト2となり、E2E 遅延は 23.4ms です。
* The edge service site based on both of the statuses will be the edge service site 3, and the E2E delay is 19.4ms.
* 両方の状態に基づくエッジサービスサイトはエッジサービスサイト3となり、E2E 遅延は 19.4ms です。
Therefore, the best choice is edge service site 3, which has an E2E delay of 19.4ms and is less than 20ms. The differences between the E2E delays are only 3-4ms among the three, but some of them will meet the application demand while the others do not.
したがって、最良の選択肢はエッジサービスサイト3であり、その E2E 遅延は 19.4ms で 20ms 未満です。3つの間の E2E 遅延の差はわずか 3～4ms ですが、アプリケーションの要求を満たすものと満たさないものがあります。
In conclusion, AR/VR clients are increasingly produced as low-end devices with reduced compute capabilities, while the AR/VR services required are ever more complex and need more computation. It makes sense, therefore, to perform at least some of the computation on specialized servers across the network. As the computation work gets larger, it may make sense to break it into components that are processed at different and more specialized sites. All of the computations must, however, be performed in a way that enables the resulting streams to be delivered in a timely way. Thus, it is necessary to select service sites that can cooperate, can perform the correct work, are not already overloaded, and have sufficiently good network connectivity with the client. This needs to be coordinated through a CATS system.
結論として、AR/VR クライアントは、コンピューティング能力が低下した低価格帯のデバイスとして生産されることが増えている一方、必要とされる AR/VR サービスはますます複雑になり、より多くの計算を必要とします。したがって、計算の少なくとも一部を、ネットワーク上の特化したサーバーで実行することには意味があります。計算作業が大きくなるにつれて、それを異なるより特化したサイトで処理される構成要素に分割することに意味が出てくる場合があります。ただし、すべての計算は、結果として得られるストリームをタイムリーに配信できる方法で実行されなければなりません。したがって、協調でき、正しい作業を実行でき、すでに過負荷になっておらず、クライアントとの間で十分に良好なネットワーク接続性を持つサービスサイトを選択する必要があります。これは CATS システムを通じて調整される必要があります。
Light Load Heavy Load Normal Load
+------------+ +------------+ +------------+
| Edge | | Edge | | Edge |
| Site 1 | | Site 2 | | Site 3 |
+-----+------+ +------+-----+ +------+-----+
computing|delay(4ms) | computing|delay(5ms)
| computing|delay(10ms) |
+----+-----+ +-----+----+ +-----+----+
| Egress | | Egress | | Egress |
| Router 1 | | Router 2 | | Router 3 |
+----+-----+ +-----+----+ +-----+----+
network|delay(9ms) network|delay(4ms) network|delay(5ms)
| | |
| +--------+--------+ |
+-----------| Infrastructure |-----------+
+--------+--------+
|
+----+----+
| Ingress |
+---------------| Router |--------------+
| +----+----+ |
| | |
+--+--+ +--+---+ +---+--+
+------+| +------+ | +------+ |
|Client|+ |Client|-+ |Client|-+
+------+ +------+ +------+
Client delay is 1.5 + 7.9 = 9.4ms
Figure 3: Computing-Aware AR or VR
図3: コンピューティング対応 AR または VR
Furthermore, specific techniques may be employed to divide the overall rendering into base assets that are common across a number of clients participating in the service, while the client-specific input data is being utilized to render additional assets. When being delivered to the client, those two assets are being combined into the overall content being consumed by the client. The requirements for sending the client input data as well as the requests for the base assets may be different in terms of which service instances may serve the request. Base assets may be served from any nearby service instance (since those base assets may be served without requiring cross-request state being maintained), while the client-specific input data is being processed by a stateful service instance that changes, if at all, only slowly over time due to the stickiness of the service that is being created by the client-specific data. Other splits of rendering and input tasks can be found in [TR22.874] for further reading.
さらに、特定の技術を用いて、サービスに参加する多数のクライアントに共通する基本アセットと、追加のアセットをレンダリングするために利用されるクライアント固有の入力データとに、全体のレンダリングを分割することができます。クライアントに配信される際、これら2つのアセットは、クライアントが消費する全体のコンテンツに結合されます。クライアント入力データを送信するための要件と、基本アセットに対する要求とでは、どのサービスインスタンスが要求を処理してよいかという点で異なる場合があります。基本アセットは (リクエストをまたぐ状態を維持することなく提供できるため) 近くの任意のサービスインスタンスから提供できる一方、クライアント固有の入力データは、ステートフルなサービスインスタンスによって処理されます。このインスタンスは、クライアント固有のデータによって作り出されるサービスのスティッキネスのために、変化するとしても時間とともにゆっくりとしか変化しません。レンダリングと入力タスクのその他の分割方法については、さらに詳しく知りたい場合は [TR22.874] を参照してください。
When it comes to the service instances themselves, those may be instantiated on demand (e.g., driven by network or client demand metrics), while resources may also be released (e.g., after an idle timeout) to free up resources for other services. Depending on the utilized node technologies, the lifetime of such a "function as a service" may range from a scale of many minutes down to the millisecond. Therefore, computing resources across participating edges exhibit a distributed (in terms of location) as well as a dynamic (in terms of resource availability) nature. In order to achieve a satisfying service quality to end users, a service request will need to be sent to and served by an edge with sufficient computing resources and a good network path.
サービスインスタンス自体に関しては、(たとえば、ネットワークまたはクライアントの需要メトリックに基づいて) 需要に応じてインスタンス化される場合がある一方、他のサービスのためにリソースを解放する目的で (たとえば、アイドルタイムアウト後に) リソースが解放される場合もあります。利用されるノード技術によっては、このような「function as a service」の存続期間は、数分からミリ秒単位までの範囲に及ぶことがあります。したがって、参加するエッジ間のコンピューティングリソースは、(場所の面で) 分散しており、かつ (リソースの可用性の面で) 動的であるという性質を示します。エンドユーザーに満足のいくサービス品質を実現するためには、サービス要求は、十分なコンピューティングリソースと良好なネットワーク経路を備えたエッジに送られ、そこで処理される必要があります。
Urban intelligent transportation relies on a large number of high-quality video capture devices and light detection and ranging (LiDAR) devices, whose data needs to be processed at edge service sites (e.g., pedestrian flow statistics, vehicle tracking). This imposes stringent requirements on the computing capabilities of edge service sites and network performance, including high throughput for concurrent video stream decoding and AI inference, as well as low latency for real-time decision making. CATS can address the issue by coordinating network and computing resources.
都市部の高度道路交通は、多数の高品質なビデオ撮影装置および光検出と測距 (LiDAR) 装置に依存しており、そのデータはエッジサービスサイトで処理する必要があります (例: 歩行者流量の統計、車両追跡)。これにより、エッジサービスサイトのコンピューティング能力とネットワーク性能に対して厳しい要件が課されます。具体的には、複数のビデオストリームを並行してデコードしAI推論を行うための高いスループットと、リアルタイムの意思決定のための低遅延が求められます。CATSは、ネットワークリソースとコンピューティングリソースを連携させることで、この課題に対処できます。
In auxiliary driving scenarios (for example, "Extended Electronic Horizon" [HORITA]), edge service sites collect road and traffic data via Vehicle to Everything (V2X) to address blind spot and collision risks, and provide real-time warnings and maneuver guidance. Requests are typically sent preferentially to the closest edge node. However, if the closest node becomes overloaded, it may lead to response delays and safety risks, which requires CATS to perform traffic steering.
運転支援のシナリオ (例: 「Extended Electronic Horizon」 [HORITA]) では、エッジサービスサイトがVehicle to Everything (V2X) を介して道路および交通のデータを収集し、死角や衝突のリスクに対処するとともに、リアルタイムの警告や操作ガイダンスを提供します。リクエストは通常、最も近いエッジノードに優先的に送信されます。しかし、最も近いノードが過負荷になると、応答遅延や安全上のリスクにつながるおそれがあり、そのためCATSによるトラフィックステアリングが必要になります。
Specifically, delay-insensitive services (e.g., in-vehicle entertainment) can be offloaded via CATS to edge service sites with lighter loads (even if they are farther away), while delay-sensitive assisted driving services are preferentially processed at local service sites. As mentioned in the Problem Statement section (Section 3), CATS is an application-transparent network-layer solution. Unlike ALTO [RFC7285], it enables coordinated scheduling of network and computing resources without requiring application modifications. For moving vehicles, CATS supports smooth and proactive context migration between edge nodes, provided that the application allows it, to maintain service continuity. In addition, vehicle speed is a key factor: Faster movement requires higher frequency of metric updates (detailed in Section 5) to ensure that CATS steering decisions remain valid as vehicles switch services among base stations or edge service sites.
具体的には、遅延に敏感でないサービス (例: 車載エンターテインメント) は、CATSによって、(より遠くにあっても) 負荷の軽いエッジサービスサイトへオフロードできます。一方、遅延に敏感な運転支援サービスは、ローカルのサービスサイトで優先的に処理されます。問題定義のセクション (セクション3) で述べたとおり、CATSはアプリケーションに対して透過的なネットワーク層のソリューションです。ALTO [RFC7285] とは異なり、アプリケーションの変更を必要とせずに、ネットワークリソースとコンピューティングリソースの連携したスケジューリングを可能にします。移動する車両に対しては、アプリケーションが許容する場合に限り、CATSはエッジノード間でのスムーズかつ事前的なコンテキスト移行をサポートし、サービスの継続性を維持します。さらに、車両の速度は重要な要因です。車両が基地局やエッジサービスサイト間でサービスを切り替えても、CATSのステアリング判断が有効であり続けるようにするには、移動が速いほど、メトリックをより高い頻度で更新する必要があります (詳細はセクション5を参照)。
In video recognition scenarios, traffic surges (e.g., during rush hours or weekends) can easily overload the closest edge service sites. CATS addresses this scalability challenge by steering excess service requests to other appropriate sites, ensuring that processing capacity matches user demand.
ビデオ認識のシナリオでは、トラフィックの急増 (例: ラッシュアワーや週末) により、最も近いエッジサービスサイトが容易に過負荷になる可能性があります。CATSは、超過したサービスリクエストを他の適切なサイトへステアリングすることで、このスケーラビリティの課題に対処し、処理能力がユーザーの需要に見合うようにします。
A number of industry associations, such as the Industrial Digital Twin Association or the Digital Twin Consortium <https://www.digitaltwinconsortium.org/>, have been founded to promote the concept of Digital Twin (DT) for a number of use case areas, such as smart cities, transportation, and industrial control, among others. The core concept of the DT is the "administrative shell" [Industry4.0], which serves as a digital representation of the information and technical functionality pertaining to the "assets" (such as an industrial machinery, a transportation vehicle, an object in a smart city, or others) that are intended to be managed, controlled, and actuated.
Industrial Digital Twin AssociationやDigital Twin Consortium <https://www.digitaltwinconsortium.org/> などの業界団体が、スマートシティ、交通、産業用制御など、さまざまなユースケース分野でデジタルツイン (DT) の概念を推進するために設立されています。DTの中核となる概念は「管理シェル (administrative shell)」 [Industry4.0] であり、これは、管理、制御、作動の対象となる「アセット」(産業機械、輸送車両、スマートシティ内のオブジェクトなど) に関する情報および技術的機能をデジタルで表現するものです。
As an example for industrial control, the programmable logic controller (PLC) may be virtualized and the functionality aggregated across a number of physical assets into a single administrative shell for the purpose of managing those assets. PLCs may be virtualized in order to move the PLC capabilities from the physical assets to the edge cloud. Several PLC instances may exist to enable load balancing and fail-over capabilities while also enabling physical mobility of the asset and the connection to a suitable "nearby" PLC instance. With this, traffic dynamicity may be similar to that observed in the connected car scenario in the previous subsection. Crucial here is high availability and bounded latency, since a failure of the (overall) PLC functionality may lead to a production line stop, while boundary violations of the latency may lead to losing synchronization with other processes and, ultimately, to production faults, tool failures, or similar.
産業用制御の例として、プログラマブルロジックコントローラ (PLC) を仮想化し、複数の物理アセットにまたがる機能を、それらのアセットを管理する目的で単一の管理シェルに集約する場合があります。PLCは、PLCの機能を物理アセットからエッジクラウドへ移すために仮想化されることがあります。ロードバランシングやフェイルオーバーの機能を実現しつつ、アセットの物理的な移動と、適切な「近傍」のPLCインスタンスへの接続も可能にするため、複数のPLCインスタンスが存在することがあります。これにより、トラフィックの動的な変化は、前のサブセクションのコネクテッドカーのシナリオで見られるものと似たものになる可能性があります。ここで極めて重要なのは、高い可用性と上限のある遅延です。(全体の) PLC機能の障害は生産ラインの停止につながるおそれがあり、遅延の境界違反は他のプロセスとの同期の喪失を招き、最終的には生産上の不具合、工具の故障などにつながるおそれがあるためです。
Particular attention in DT scenarios is given to the problem of data storage. Here, decentralization plays an important role, which is not only driven by the scenario (such as what is outlined in the connected car scenario for cases of localized reasoning over data originating from driving vehicles), but also through proposed platform solutions (such as those in [GAIA-X]). With decentralization, endpoint relations between client and (storage) service instances may frequently change as a result.
DTのシナリオでは、データストレージの問題に特に注意が払われます。ここでは分散化が重要な役割を果たします。これは、シナリオ自体 (走行中の車両から発生するデータに対するローカルな推論の場合にコネクテッドカーのシナリオで概説したものなど) に起因するだけでなく、提案されているプラットフォームソリューション ([GAIA-X] のものなど) にも起因します。分散化の結果として、クライアントと (ストレージ) サービスインスタンスとの間のエンドポイントの関係が、頻繁に変化する可能性があります。
In this use case, CATS is required for selecting the optimal PLC instance and storage node, ensuring low latency and reliability for data processing in industrial scenarios, as well as low latency for data reading/writing during twin control processes.
このユースケースでは、最適なPLCインスタンスとストレージノードを選択するためにCATSが必要であり、産業シナリオにおけるデータ処理の低遅延と信頼性、およびツイン制御プロセス中のデータ読み書きの低遅延を確保します。
Software-Defined Wide-Area Network (SD-WAN) is an overlay connectivity service that optimizes the transport of IP packets over one or more underlay connectivity services by recognizing applications and determining forwarding behavior through the application of policies [MEF70.2]. SD-WAN can be deployed by both service providers and enterprises to support connectivity across branch sites, data centers, and cloud environments. Applications or services may be deployed at multiple locations to achieve performance, resiliency, or cost objectives.
Software-Defined Wide-Area Network (SD-WAN) は、アプリケーションを認識し、ポリシーの適用によって転送動作を決定することで、1つ以上のアンダーレイ接続サービス上でのIPパケットの転送を最適化するオーバーレイ接続サービスです [MEF70.2]。SD-WANは、サービスプロバイダーと企業の双方が展開でき、支社拠点、データセンター、クラウド環境にまたがる接続をサポートします。アプリケーションやサービスは、性能、回復力、またはコストの目標を達成するために、複数の場所に展開されることがあります。
In current SD-WAN deployments, forwarding decisions are primarily based on network-related metrics such as available bandwidth, latency, packet loss, or path availability. However, these decisions typically lack visibility into the computing resources available at the destination sites, such as CPU or GPU utilization, memory pressure, or other composite cost metrics.
現在のSD-WANの展開では、転送の判断は主に、利用可能な帯域幅、遅延、パケットロス、経路の可用性といったネットワーク関連のメトリックに基づいています。しかし、こうした判断では通常、宛先サイトで利用可能なコンピューティングリソース (CPUやGPUの使用率、メモリ負荷、その他の複合的なコストメトリックなど) を把握できません。
CATS metrics can complement existing SD-WAN network metrics by providing information about the availability and condition of computing resources associated with service instances at edge or cloud sites. Such metrics may be consumed by a centralized SD-WAN controller when deriving policies or computing preferred paths and/or by SD-WAN edge devices to make distributed, real-time traffic steering decisions among already deployed service instances. In both cases, the goal is to enable application traffic to be steered towards service instances and sites that best satisfy application requirements by jointly considering network and computing conditions.
CATSメトリックは、エッジサイトやクラウドサイトにあるサービスインスタンスに関連するコンピューティングリソースの可用性と状態に関する情報を提供することで、既存のSD-WANネットワークメトリックを補完できます。このようなメトリックは、ポリシーを導出したり優先経路を計算したりする際に集中型のSD-WANコントローラが利用することも、すでに展開されているサービスインスタンスの中から分散的かつリアルタイムにトラフィックステアリングの判断を行うためにSD-WANエッジデバイスが利用することもあります。いずれの場合も、目標は、ネットワークとコンピューティングの状況を併せて考慮することで、アプリケーションの要件を最もよく満たすサービスインスタンスおよびサイトへ、アプリケーショントラフィックをステアリングできるようにすることです。
For the scenario of enterprises deploying applications in the cloud, SD-WAN provides enterprises with centralized control over Customer Premises Equipment (CPE) in branch offices and the virtual CPE (vCPE) in the clouds. The CPE connects the clients in branch offices and the application servers in clouds. The same application server in different clouds is called an application instance. Different application instances have different computing resources.
企業がクラウドにアプリケーションを展開するシナリオでは、SD-WANにより、企業は支店にあるCustomer Premises Equipment (CPE) と、クラウド内の仮想CPE (vCPE) を集中制御できます。CPEは支店のクライアントとクラウド内のアプリケーションサーバを接続します。異なるクラウド内にある同一のアプリケーションサーバは、アプリケーションインスタンスと呼ばれます。アプリケーションインスタンスが異なれば、コンピューティングリソースも異なります。
SD-WAN is aware of the computing resources of applications deployed in the clouds by vCPE and selects the application instance for the client to visit according to the computing power and the network state of WAN.
SD-WANは、vCPEによってクラウドに展開されたアプリケーションのコンピューティングリソースを認識し、コンピューティング能力とWANのネットワーク状態に応じて、クライアントがアクセスするアプリケーションインスタンスを選択します。
Additionally, in order to provide cost-effective solutions, the SD-WAN may also consider cost (e.g., in terms of energy prices incurred or energy sources used) when selecting a specific application instance over another. For this, suitable metric information would need to be exposed (e.g., by the cloud provider), in terms of utilized energy or incurred energy costs per computing resource.
さらに、費用対効果の高いソリューションを提供するため、SD-WANは、特定のアプリケーションインスタンスを別のものより優先して選択する際に、コスト (例: 発生するエネルギー価格や使用されるエネルギー源の観点) も考慮することがあります。このためには、(例えばクラウドプロバイダーによって) コンピューティングリソースあたりの使用エネルギーまたは発生するエネルギーコストに関する、適切なメトリック情報が公開される必要があります。
Figure 4 below illustrates computing-aware SD-WAN for enterprise cloudification.
以下の図4は、企業のクラウド化のためのコンピューティング対応SD-WANを示しています。
+---------------+
+-------+ +----------+ | Cloud1 |
|Client1| /---------| WAN1 |------| vCPE1 APP1 |
+-------+ / +----------+ +---------------+
+-------+ +-------+
|Client2| ------ | CPE |
+-------+ +-------+ +---------------+
+-------+ \ +----------+ | Cloud2 |
|Client3| \---------| WAN2 |------| vCPE2 APP1 |
+-------+ +----------+ +---------------+
Figure 4: Illustration of Computing-Aware SD-WAN for Enterprise Cloudification
図4: 企業のクラウド化のためのコンピューティング対応SD-WANの図
The current computing load status of the application APP1 in Cloud1 and Cloud2 is as follows:
Cloud1とCloud2におけるアプリケーションAPP1の現在のコンピューティング負荷状況は次のとおりです。
* Each application uses 6 virtual CPUs (vCPUs).
* 各アプリケーションは6つの仮想CPU (vCPU) を使用しています。
* The load of the application in Cloud1 is 50%.
* Cloud1のアプリケーションの負荷は50%です。
* The load of the application in Cloud2 is 20%.
* Cloud2のアプリケーションの負荷は20%です。
* The computing resources of APP1 are collected by vCPE1 and vCPE2, respectively.
* APP1のコンピューティングリソースは、それぞれvCPE1とvCPE2によって収集されます。
* Client1 and Client2 are visiting APP1 in Cloud1.
* Client1とClient2は、Cloud1のAPP1にアクセスしています。
* WAN1 and WAN2 have the same network states.
* WAN1とWAN2のネットワーク状態は同じです。
* Considering a lightly loaded application, SD-WAN selects APP1 in Cloud2 for the Client3 in the branch office.
* 負荷の軽いアプリケーションを考慮して、SD-WANは支店のClient3に対してCloud2のAPP1を選択します。
* The traffic of Client3 follows this path: Client3 -> CPE -> WAN2 -> Cloud2 vCPE1 -> Cloud2 APP1.
* Client3のトラフィックは次の経路をたどります: Client3 -> CPE -> WAN2 -> Cloud2 vCPE1 -> Cloud2 APP1。
Artificial Intelligence (AI) large model refers to models that are characterized by their large size, high complexity, and high computational requirements. AI large models have become increasingly important in various fields, such as natural language processing for text classification, computer vision for image classification and object detection, and speech recognition.
人工知能 (AI) 大規模モデルとは、サイズが大きく、複雑性が高く、計算要件が高いという特徴を持つモデルを指します。AI大規模モデルは、テキスト分類のための自然言語処理、画像分類や物体検出のためのコンピュータビジョン、音声認識など、さまざまな分野でますます重要になっています。
AI large model contains two key phases: training and inference. Training refers to the process of developing an AI model by feeding it with large amounts of data and optimizing it to learn and improve its performance. On the other hand, inference is the process of using the trained AI model to make predictions or decisions based on new input data.
AI大規模モデルには、学習と推論という2つの主要なフェーズがあります。学習とは、大量のデータを与えてAIモデルを開発し、その性能を学習・向上させるよう最適化するプロセスを指します。一方、推論とは、学習済みのAIモデルを使用して、新しい入力データに基づいて予測や判断を行うプロセスです。
With the fast development of AI large language models, more lightweight models can be deployed at edge service sites. Figure 5 shows the potential deployment of this case.
AI大規模言語モデルの急速な発展に伴い、より軽量なモデルをエッジサービスサイトに展開できるようになっています。図5は、このケースで想定される展開を示しています。
AI inference contains two major steps: prefilling and decoding. Prefilling processes a user's prompt to generate the first token of the response in one step. Following it, decoding sequentially generates subsequent tokens step by step until the termination token. These stages consume many computing resources. Important metrics for AI inference are processor cores, which transform prompts to tokens, and memory resources, which are used to store key values and cache tokens. The generation and processing of tokens indicates the service capability of an AI inference system. Single site deployment of the prefilling and decoding might not provide enough resources when there are many clients sending requests (prompts) to access AI inference service.
AI推論には、プリフィルとデコードという2つの主要なステップがあります。プリフィルは、ユーザーのプロンプトを処理して、応答の最初のトークンを1ステップで生成します。その後、デコードが、終了トークンに至るまで、後続のトークンを1ステップずつ順に生成します。これらの段階は多くのコンピューティングリソースを消費します。AI推論の重要なメトリックは、プロンプトをトークンに変換するプロセッサコアと、キー値やキャッシュトークンの保存に使われるメモリリソースです。トークンの生成と処理は、AI推論システムのサービス能力を示します。多数のクライアントがAI推論サービスにアクセスするためにリクエスト (プロンプト) を送信する場合、プリフィルとデコードを単一サイトに展開するだけでは、十分なリソースを提供できない可能性があります。
More generally, we also see the use of cost information, specifically on the cost for energy expended on AI inferencing of the overall provided AI-based service, as a possible criterion for steering traffic. Here, we envision (AI) service tiers being exposed to end users, allowing them to prioritize "greener energy costs", for example, as a key criterion for service fulfillment. For this, the system would employ metric information (on utilized energy mix at the AI inference sites and costs for energy, for example) to prioritize a "greener" site over another while providing similar response times.
より一般的には、トラフィックをステアリングする際の判断基準の可能性として、コスト情報、具体的には、提供されるAIベースのサービス全体のAI推論に費やされるエネルギーのコストの利用も想定しています。ここでは、(AI) サービス階層をエンドユーザーに公開し、たとえば「よりグリーンなエネルギーコスト」を、サービス提供における主要な基準として優先できるようにすることを想定しています。このために、システムはメトリック情報 (たとえば、AI推論サイトで使用されているエネルギーミックスやエネルギーのコストに関するもの) を用いて、同程度の応答時間を提供しつつ、あるサイトを別のサイトより「グリーン」であるとして優先します。
+----------------------------------------------------------+
| +--------------+ +--------------+ +--------------+ |
| | Edge | | Edge | | Edge | |
| | +----------+ | | +----------+ | | +----------+ | |
| | | Prefill | | | | Prefill | | | | Prefill | | |
| | +----------+ | | +----------+ | | +----------+ | |
| | +----------+ | | +----------+ | | +----------+ | |
| | | Decode | | | | Decode | | | | Decode | | |
| | +----------+ | | +----------+ | | +----------+ | |
| +--------------+ +--------------+ +--------------+ |
+----------+-----------------------------+-----------------+
| Prompt | Prompt
| |
+----+-----+ +-+--------+
| Client_1 | ... | Client_2 |
+----------+ +----------+
Figure 5: Illustration of Computing-Aware AI Large Model Inference
図5: コンピューティング対応AI大規模モデル推論の図
Although large language models are nowadays confined to be trained with very large centers with computational, often GPU-based, resources, platforms for federated or distributed training are being positioned, specifically when employing edge computing resources [CAFL].
大規模言語モデルは、現在では、計算資源 (多くはGPUベース) を備えた非常に大規模なセンターで学習されるものに限られていますが、特にエッジコンピューティングリソースを利用する場合を中心に、連合学習または分散学習のプラットフォームが位置づけられつつあります [CAFL]。
While those approaches apply their own (collective) communication approach to steer the training and gradient data towards the various (often edge) computing sites, we also see a case for CATS traffic steering here. For this, the training clusters themselves may be multi-site (i.e., combining resources from more than one site) but acting as service instances in a CATS sense (i.e., providing the respective training round as a service to the overall distributed/ federated learning platform with the CATS system responsible for selecting service instances and steering traffic to them).
これらのアプローチは、学習データや勾配データを (多くはエッジの) さまざまなコンピューティングサイトへステアリングするために、独自の (集合的な) 通信方式を適用していますが、ここにはCATSによるトラフィックステアリングの出番もあると考えます。このために、学習クラスタ自体がマルチサイト (すなわち、複数のサイトのリソースを組み合わせたもの) であってもよく、その場合でもCATSの意味でのサービスインスタンスとして動作します (すなわち、サービスインスタンスの選択とそれらへのトラフィックのステアリングを担うCATSシステムとともに、分散学習または連合学習プラットフォーム全体に対して、それぞれの学習ラウンドをサービスとして提供します)。
One (cluster) site can be selected over another based on compute metrics, network metrics, cost metrics, or a combination thereof. For instance, training may be constrained based on the network resources to ensure timely delivery of the required training and gradient information to the cluster site, while computational load may also be considered, particularly when the cluster sites are multi-homed, thus hosting more than one application and therefore becoming (temporarily) overloaded. But equally to our inferencing use case in the previous section, the overall training service may also be constrained by cost, specifically energy aspects (e.g., when positioning the service utilizing the trained model is advertising its "green" credentials to the end users). For this, costs based on energy pricing (over time) as well as the energy mix may be considered. One could foresee, for instance, the coupling of surplus energy in renewable energy resources to a cost metric upon which traffic is steered preferably to those cluster sites that are merely consuming surplus and not grid energy.
あるクラスタサイトを別のクラスタサイトより優先して選択する際には、コンピュートメトリック、ネットワークメトリック、コストメトリック、またはそれらの組み合わせを基準にできます。たとえば、必要な学習情報と勾配情報をクラスタサイトへ適時に届けるために、ネットワークリソースに基づいて学習が制約されることがあります。一方、特にクラスタサイトがマルチホームで複数のアプリケーションをホストし、そのために(一時的に)過負荷になる場合には、計算負荷も考慮されることがあります。しかし、前節の推論のユースケースと同様に、学習サービス全体がコスト、特にエネルギーの側面によって制約されることもあります(たとえば、学習済みモデルを利用するサービスがエンドユーザーに対して「グリーン」であることを訴求している場合)。このため、(時間経過に伴う)エネルギー価格や電力構成に基づくコストを考慮することがあります。たとえば、再生可能エネルギー資源の余剰エネルギーをコストメトリックに結び付け、余剰分のみを消費し系統電力を消費しないクラスタサイトへ優先的にトラフィックをステアリングすることが考えられます。
Storage is also necessary for performing distributed/federated learning due to several key reasons. Firstly, it is needed to store model checkpoints produced throughout the training process, allowing for progress tracking and recovery in case of interruptions. Additionally, storage is used to keep samples of the dataset used to train the model, which often come from distributed sensors such as cameras, microphones, etc. Furthermore, storage is required to hold the models themselves, which can be very large and complex. Knowing the storage performance metrics is also important. For instance, understanding the I/O transfer rate of the storage helps in determining the latency of accessing data from the disk. Additionally, knowing the size of the storage is relevant to understanding how many model checkpoints can be stored or the maximum size of the model that can be locally stored.
分散学習・連合学習の実施にはストレージも、いくつかの主要な理由から必要です。第一に、学習の過程で生成されるモデルのチェックポイントを保存するために必要であり、これにより進捗の追跡と中断時の復旧が可能になります。加えて、モデルの学習に用いるデータセットのサンプルを保持するためにもストレージが使われ、これらはカメラやマイクなどの分散したセンサーに由来することが多くあります。さらに、非常に大規模で複雑になりうるモデルそのものを保持するためにもストレージが必要です。ストレージの性能メトリックを把握することも重要です。たとえば、ストレージのI/O転送速度を理解すると、ディスクからデータにアクセスする際のレイテンシを判断できます。また、ストレージの容量を把握することは、保存できるモデルのチェックポイントの数や、ローカルに保存できるモデルの最大サイズを理解するうえで重要です。
In the following section, we outline the requirements for the CATS system to overcome the observed problems in the realization of the use cases above.
以下の節では、上記のユースケースの実現において観察された問題を克服するために、CATSシステムに求められる要件を概説します。
The basic requirement of CATS is to support the dynamic access to different service instances residing in multiple computing sites and then being aware of their status, which is also the fundamental model to enable the traffic steering and to further optimize the network and computing services. A specific service is identified by a CATS Service ID (CS-ID). All instances of a specific service use the same CS-ID no matter at which edge service site they are located. The CS-ID is unique for the service so that it unambiguously identifies the service. The mapping of this CS-ID to a network locator is basic to steer traffic to any of the service instances deployed in various edge service sites.
CATSの基本的な要件は、複数のコンピューティングサイトに存在するさまざまなサービスインスタンスへの動的なアクセスをサポートし、それらの状態を把握することです。これは、トラフィックステアリングを可能にし、ネットワークサービスとコンピューティングサービスをさらに最適化するための基本モデルでもあります。特定のサービスは CATS Service ID (CS-ID) によって識別されます。特定のサービスのすべてのインスタンスは、どのエッジサービスサイトに配置されていても同じCS-IDを使用します。CS-IDはサービスに対して一意であり、そのサービスを曖昧さなく識別します。このCS-IDからネットワークロケータへのマッピングは、さまざまなエッジサービスサイトに展開されたいずれのサービスインスタンスへもトラフィックをステアリングするための基礎となります。
Moreover, according to CATS use cases, some applications require E2E low latency, which warrants a quick mapping of the service identifier to the network locator. This naturally leads to the in-band methods, involving the consideration of using metrics that are oriented towards compute capabilities and resources, and their correlation with services. Therefore, a desirable system:
さらに、CATSのユースケースによれば、一部のアプリケーションはE2Eの低レイテンシを必要とし、そのためにはサービス識別子からネットワークロケータへの迅速なマッピングが求められます。これは当然、インバンド方式につながり、コンピュート能力やリソースを指向したメトリックの利用と、それらとサービスとの対応付けを考慮することになります。したがって、望ましいシステムは次の条件を満たします。
R1:
R1:
MUST provide a dynamic discovery and resolution method for mapping the CS-ID to one or more current service instance addresses, based on up-to-date system state assuming the CS-ID is valid.
CS-IDが有効であると仮定したうえで、最新のシステム状態に基づき、CS-IDを現在の1つ以上のサービスインスタンスのアドレスにマッピングするための動的な検出・解決方式を提供しなければなりません (MUST)。
R2:
R2:
MUST provide a method to dynamically assess the availability of service instances, based on up-to-date status metrics (e.g., health, load, reachability).
最新のステータスメトリック(例: ヘルス、負荷、到達性)に基づき、サービスインスタンスの可用性を動的に評価する方式を提供しなければなりません (MUST)。
The term "up to date" herein refers to the latest metric information collected by the system in accordance with the preset metric update cycle. The principle for setting the cycle is generally pre-determined by the network. For example, based on historical statistical data, a relatively appropriate update cycle (either second level or millisecond level) is selected for a specific type or certain types of services.
ここでの「最新」とは、あらかじめ設定されたメトリック更新周期に従ってシステムが収集した最も新しいメトリック情報を指します。周期の設定方針は、一般にネットワークによってあらかじめ決められています。たとえば、過去の統計データに基づいて、特定の種類または複数の種類のサービスに対して比較的適切な更新周期(秒単位またはミリ秒単位)が選択されます。
Computing metrics can have many different semantics, particularly for being service specific. Even the notion of a "computing load" metric could be represented in many different ways, as with percentile-quantified metrics across various categories (e.g., latency, throughput). Such representation may entail information on the semantics of the metric, or it may be purely one or more semantic-free numerals. Agreement of the chosen representation among all service and network elements participating in the service instance selection decision is important. Therefore, in a desirable system:
コンピューティングメトリックには、特にサービス固有であることから、さまざまな意味付けがありえます。「計算負荷」というメトリックの概念ですら、さまざまなカテゴリ(例: レイテンシ、スループット)にわたるパーセンタイルで定量化されたメトリックのように、多様な方法で表現できます。こうした表現は、メトリックの意味に関する情報を伴うこともあれば、意味を持たない1つ以上の数値のみで構成されることもあります。サービスインスタンスの選択判断に関与するすべてのサービス要素とネットワーク要素の間で、選択された表現について合意することは重要です。したがって、望ましいシステムでは次のようになります。
R3:
R3:
The implementations MUST agree on using metrics that are oriented towards compute capabilities and resources and their representation among service instances in the participating edges, at both design time and runtime.
実装は、設計時と実行時の両方において、参加するエッジ内のサービスインスタンス間で、コンピュート能力やリソースを指向したメトリックとその表現を使用することに合意しなければなりません (MUST)。
To better understand the meaning of different metrics and to better support appropriate use of metrics:
さまざまなメトリックの意味をよりよく理解し、メトリックの適切な利用をよりよくサポートするために、次のようにします。
R4:
R4:
An information model of the compute and network resources MUST be defined. Such a model MUST characterize how metrics are abstracted out from the compute and network resources. We refer to this information model as the Resource Model.
コンピュートリソースとネットワークリソースの情報モデルを定義しなければなりません (MUST)。このモデルは、コンピュートリソースとネットワークリソースからメトリックがどのように抽象化されるかを特徴付けなければなりません (MUST)。この情報モデルをリソースモデルと呼びます。
R5:
R5:
The Resource Model MUST be implementable in an interoperable manner. That is, metrics generated by this resource model MUST be understood and interoperable across independent CATS implementations.
リソースモデルは、相互運用可能な方法で実装可能でなければなりません (MUST)。すなわち、このリソースモデルによって生成されるメトリックは、独立したCATS実装の間で理解され、相互運用可能でなければなりません (MUST)。
R6:
R6:
It MUST be possible to implement the Resource Model in a scalable manner. That is, the Resource Model MUST be capable of scaling in memory, energy, and processing no worse than linearly with an increase in the amount of CATS metrics and CATS service instances it supports.
リソースモデルをスケーラブルな方法で実装できなければなりません (MUST)。すなわち、リソースモデルは、サポートするCATSメトリックおよびCATSサービスインスタンスの量の増加に対して、メモリ、エネルギー、処理が線形より悪くならない形でスケールできなければなりません (MUST)。
We recognize that different network nodes (e.g., routers, switches, etc.) may have diversified capabilities even in the same routing domain, let alone in different administrative domains and from different vendors. Therefore, to work properly in a CATS system:
異なる管理ドメインやベンダーのノード間はもちろん、同一のルーティングドメイン内であっても、ネットワークノード(例: ルーター、スイッチなど)の能力は多様でありうることを認識しています。したがって、CATSシステムが適切に動作するためには、次のようにします。
R7:
R7:
CATS systems MUST support staleness handling for CATS metrics and provide indications of when metrics should be refreshed, so that CATS components can know if a metric value is valid or not.
CATSシステムは、CATSメトリックの陳腐化の処理をサポートし、メトリックをいつ更新すべきかの指示を提供しなければなりません (MUST)。これにより、CATSコンポーネントはメトリック値が有効かどうかを知ることができます。
R8:
R8:
All metric information used in CATS MUST be produced and encoded in a standardized format that is understood by all participating CATS components. For metrics that CATS components do not understand or support, CATS components will ignore them.
CATSで使用されるすべてのメトリック情報は、参加するすべてのCATSコンポーネントが理解できる標準化された形式で生成およびエンコードされなければなりません (MUST)。CATSコンポーネントが理解またはサポートしないメトリックについては、CATSコンポーネントはそれらを無視します。
R9:
R9:
CATS components SHOULD support a mechanism to advertise or negotiate supported metric types and encodings to ensure compatibility across implementations.
CATSコンポーネントは、実装間の互換性を確保するために、サポートするメトリックの種類とエンコーディングを通知またはネゴシエートする仕組みをサポートすべきです (SHOULD)。
R10:
R10:
The computation and use of metrics in CATS MUST be designed to avoid introducing routing loops or path oscillations when metrics are distributed and used for path selection.
CATSにおけるメトリックの計算と使用は、メトリックが配布され経路選択に使用される際に、ルーティングループや経路の振動を引き起こさないように設計されなければなりません (MUST)。
Compute metrics can change rapidly, which may lead to path oscillation if metrics are updated too frequently or become stale if updated too infrequently. R10 ensures that CATS components can negotiate metric types for consistent interpretation, while R11 requires that metrics be used in a way that avoids routing loops and path instability. Together, they balance responsiveness with stability.
コンピュートメトリックは急速に変化することがあり、メトリックの更新が頻繁すぎると経路の振動を招き、更新が少なすぎると陳腐化するおそれがあります。R10は、CATSコンポーネントが一貫した解釈のためにメトリックの種類をネゴシエートできるようにし、R11は、ルーティングループと経路の不安定性を避ける形でメトリックを使用することを求めています。両者が相まって、応答性と安定性のバランスをとります。
Network path costs in the current routing system usually do not change very frequently. Network traffic engineering metrics (such as available bandwidth) may change more frequently as traffic demands fluctuate, but distribution of these changes is normally damped so that only significant changes cause routing protocol messages.
現在のルーティングシステムにおけるネットワーク経路のコストは、通常それほど頻繁には変化しません。ネットワークトラフィックエンジニアリングのメトリック(利用可能帯域幅など)は、トラフィック需要の変動に伴ってより頻繁に変化することがありますが、これらの変化の配布は通常抑制されており、重要な変化のみがルーティングプロトコルメッセージを発生させます。
However, metrics that are oriented towards compute capabilities and resources in general can be highly dynamic (e.g., changing rapidly with the number of sessions, the CPU/GPU utilization, and the memory consumption, etc). Service providers must determine at what interval or based on what events such information needs to be distributed. Overly frequent distribution with more accurate synchronization may result in unnecessary overhead in terms of signaling.
しかし、コンピュート能力やリソースを指向したメトリックは、一般に非常に動的でありえます(例: セッション数、CPU/GPU使用率、メモリ消費量などに伴って急速に変化する)。サービスプロバイダーは、そのような情報をどの間隔で、またはどのイベントに基づいて配布する必要があるかを決定しなければなりません。過度に頻繁な配布によってより正確な同期を行うと、シグナリングの点で不要なオーバーヘッドが生じる可能性があります。
Moreover, depending on the service-related decision logic, one or more metrics need to be conveyed in a CATS domain (that is, between the clients, services, decision-making points, and traffic steering elements cooperating to perform CATS functions). The problem to be addressed here may be the frequency of such conveyance, and which CATS component is the decision maker for the service instance selection should also be considered. Therefore, choosing appropriate protocols for conveying CATS metrics is important. While existing routing protocols may serve as a baseline for signaling metrics, for example, BGP extensions [RFC4760] and the GeneRic Autonomic Signaling Protocol (GRASP) [RFC8990], these routing protocols may be more suitable for distributed systems. Considering some centralized approaches to select CATS service instances, other means to convey the metrics can equally be chosen and can even be realized, for example, leveraging RESTful APIs for the publication of CATS metrics to a centralized decision maker. Specifically, a desirable system:
さらに、サービスに関する判断ロジックによっては、CATSドメイン(すなわち、CATS機能を実行するために協調するクライアント、サービス、判断を行うポイント、トラフィックステアリング要素の間)で、1つ以上のメトリックを伝達する必要があります。ここで対処すべき問題は、そのような伝達の頻度であるかもしれず、サービスインスタンスの選択における意思決定者がどのCATSコンポーネントであるかも考慮すべきです。したがって、CATSメトリックを伝達するための適切なプロトコルを選択することは重要です。既存のルーティングプロトコル、たとえばBGP拡張 [RFC4760] や GeneRic Autonomic Signaling Protocol (GRASP) [RFC8990] は、メトリックをシグナリングするためのベースラインとなりえますが、これらのルーティングプロトコルは分散システムにより適しているかもしれません。CATSサービスインスタンスを選択する集中型のアプローチを考慮すると、メトリックを伝達する他の手段も同様に選択でき、さらに実現することもできます。たとえば、RESTful APIを利用してCATSメトリックを集中型の意思決定者に公開する方法です。具体的には、望ましいシステムは次の条件を満たします。
R11:
R11:
MUST provide mechanisms for metric collection, including specifying the responsible entity for collection.
メトリック収集のためのメカニズムを提供しなければならず (MUST)、収集を担当するエンティティの指定も含まれます。
Collecting metrics from all of the service instances may incur much overhead for decision makers. Hierarchical aggregation helps reduce this burden by consolidating metrics at intermediate nodes, providing a more scalable and efficient view of resource conditions.
すべてのサービスインスタンスからメトリックを収集すると、意思決定者に大きなオーバーヘッドが生じる可能性があります。階層的な集約は、中間ノードでメトリックを統合することでこの負担を軽減し、リソース状況をよりスケーラブルで効率的に把握できるようにします。
CATS components do not need to be aware of how metrics are collected behind the aggregator. The decision point may not be directly connected with service instances or metric collectors. Therefore, a system:
CATS コンポーネントは、アグリゲーターの背後でメトリックがどのように収集されるかを認識している必要はありません。決定ポイントは、サービスインスタンスやメトリックコレクターと直接接続されていない場合があります。したがって、システムは次のようにします。
R12:
R12:
MUST provide mechanisms to distribute the metrics.
メトリックを配布するためのメカニズムを提供しなければなりません (MUST)。
There may be various update frequencies for different computing metrics. Some of the metrics may be more dynamic, while others are relatively static. Accordingly, different distribution methods may need to be chosen with respect to different update frequencies of different metrics. Therefore, a system:
コンピューティングメトリックの種類によって、更新頻度は様々です。メトリックの中には変化が大きいものもあれば、比較的静的なものもあります。したがって、メトリックごとの更新頻度に応じて、異なる配布方式を選択する必要が生じる場合があります。したがって、システムは次のようにします。
R13:
R13:
MUST continue to operate (even if sub-optimally) if metric updates are delayed by low-frequency updates or by problems with the mechanisms used to distribute the metrics.
低頻度の更新、またはメトリックの配布に用いるメカニズムの問題によってメトリックの更新が遅延した場合でも、(最適ではない状態であっても) 動作を継続しなければなりません (MUST)。
For example, in highly mobile scenarios, such as the fast-moving vehicles mentioned in Section 4.3, compute metrics can quickly become outdated as the UE moves across base stations and edge service sites, potentially requiring more frequent updates. However, updates should remain stable and avoid excessive overhead.
たとえば、セクション 4.3 で述べた高速移動する車両のような移動性の高いシナリオでは、UE が基地局やエッジサービスサイトをまたいで移動するにつれて、コンピューティングメトリックがすぐに古くなる可能性があり、より頻繁な更新が必要になることがあります。ただし、更新は安定しており、過度なオーバーヘッドを避けるべきです。
In the CATS system, a service may be provided by one or more service instances that would be deployed at different locations in the network. Each instance provides equivalent service functionality to its respective clients. The decision logic of the instance selection is subject to the packet-level communication, and packets are forwarded based on the operating status of both network and computing resources. This resource status will likely change over time, leading to individual packets potentially being sent to different network locations, possibly segmenting individual service transactions and breaking service-level semantics. Moreover, when a client moves, the access point might change and successively lead to the migration of service instances. If execution changes from one (e.g., virtualized) service instance to another, state/context needs to be transferred to the new instance. Such required transfer of state/context makes it desirable to have instance affinity as the default, removing the need for explicit context transfer while also supporting an explicit state/context transfer (e.g., when metrics change significantly).
CATS システムでは、サービスは、ネットワーク内の異なる場所に配置される 1 つ以上のサービスインスタンスによって提供される場合があります。各インスタンスは、それぞれのクライアントに対して同等のサービス機能を提供します。インスタンス選択の判断ロジックはパケットレベルの通信に従い、パケットはネットワークリソースとコンピューティングリソースの双方の動作状況に基づいて転送されます。このリソース状況は時間とともに変化する可能性が高く、個々のパケットが異なるネットワーク上の場所に送られることにより、個々のサービストランザクションが分断され、サービスレベルのセマンティクスが損なわれるおそれがあります。さらに、クライアントが移動するとアクセスポイントが変わり、それに続いてサービスインスタンスのマイグレーションが生じることがあります。実行が (たとえば仮想化された) あるサービスインスタンスから別のインスタンスに切り替わる場合、状態/コンテキストを新しいインスタンスに転送する必要があります。このような状態/コンテキストの転送が必要になるため、インスタンスアフィニティをデフォルトとし、明示的なコンテキスト転送を不要にすることが望ましく、同時に (たとえば、メトリックが大きく変化したときなどに) 明示的な状態/コンテキストの転送もサポートすることが望まれます。
The nature of this affinity is highly dependent on the nature of the service, which could be seen as an "instance affinity" to represent the relationship. The minimal affinity of a single request represents a stateless service, where each service request may be responded to without any state being held at the service instance for fulfilling the request.
このアフィニティの性質はサービスの性質に大きく依存し、その関係を表すものとして「インスタンスアフィニティ」と捉えることができます。単一リクエストという最小のアフィニティは、ステートレスなサービスを表します。この場合、各サービスリクエストは、そのリクエストを処理するための状態をサービスインスタンスが保持することなく応答できます。
Providing any necessary information/state in the manner of in band as part of the service request (e.g., in the form of a multi-form body in an HTTP request or through the URL provided as part of the request) is one way to achieve such stateless nature.
必要な情報/状態を、サービスリクエストの一部としてインバンドで (たとえば、HTTP リクエストにおけるマルチフォームボディの形式や、リクエストの一部として与えられる URL を通じて) 提供することは、このようなステートレスな性質を実現する方法の 1 つです。
Alternatively, the affinity to a particular service instance may span more than one request, as in the AR/VR use case, where the previous client input is needed to render subsequent frames.
あるいは、特定のサービスインスタンスに対するアフィニティが、AR/VR のユースケースのように、複数のリクエストにまたがる場合もあります。このユースケースでは、後続のフレームをレンダリングするために、以前のクライアント入力が必要です。
However, a client (e.g., a mobile UE) may have many applications running. If all, or the majority, of the applications request the CATS-based services, then the runtime states that need to be created and accordingly maintained would require high granularity. In the extreme scenario, this granular requirement could reach the level of per-UE, per-APP, and per-(sub)flow with regard to a service instance, where a "flow" is 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) (see also [RFC10053]). Evidently, these fine-granular runtime states can potentially place a heavy burden on network devices if they have to dynamically create and maintain them. On the other hand, it is not appropriate either to place the state-keeping task on clients themselves.
しかし、クライアント (たとえばモバイル UE) では多数のアプリケーションが動作している場合があります。すべての、または大多数のアプリケーションが CATS ベースのサービスを要求する場合、作成され、それに応じて維持される必要のある実行時状態は、高い粒度を必要とします。極端なシナリオでは、この粒度の要件は、サービスインスタンスに関して UE 単位、APP 単位、(サブ) フロー単位のレベルに達する可能性があります。ここで「フロー」とは、ある時間間隔内のパケットの論理的なまとまりであり、5-tuple のトランスポート座標 (送信元アドレスと宛先アドレス、送信元ポート番号と宛先ポート番号、およびプロトコル) などのパケットヘッダーの一部のフィールドによって識別されます ([RFC10053] も参照してください)。明らかに、このような細かい粒度の実行時状態を動的に作成して維持しなければならない場合、ネットワークデバイスに重い負担がかかる可能性があります。一方で、状態を保持するタスクをクライアント自身に負わせることも適切ではありません。
Besides, there might be the case that the UE moves to a new (access) network or the service instance is migrated to another cloud, which causes unreachability or inconvenience of the original service instance. Hence, the UE and service instance mobility also need to be considered.
加えて、UE が新しい (アクセス) ネットワークに移動する場合や、サービスインスタンスが別のクラウドにマイグレーションされる場合があり、これにより元のサービスインスタンスに到達できなくなったり、不都合が生じたりします。したがって、UE とサービスインスタンスの移動性も考慮する必要があります。
Therefore, a desirable system:
したがって、望ましいシステムは次のようにします。
R14:
R14:
MUST maintain instance affinity for stateful sessions and transactions on a per-flow basis.
ステートフルなセッションとトランザクションに対して、フロー単位でインスタンスアフィニティを維持しなければなりません (MUST)。
R15:
R15:
MUST avoid maintaining per-flow states for specific applications in network nodes for providing instance affinity.
インスタンスアフィニティを提供するために、特定のアプリケーションに対するフロー単位の状態をネットワークノードで維持することを避けなければなりません (MUST)。
R16:
R16:
SHOULD support service continuity in the presence of UE or service instance mobility.
UE またはサービスインスタンスの移動が発生する場合でも、サービス継続性をサポートすべきです (SHOULD)。
Exposing CATS metrics to the network may lead to the leakage of application privacy. In order to prevent it, it is necessary to consider the methods to handle the sensitive information. Examples of this include using general anonymization methods, including hiding the key information representing the identification of devices, using an index to represent the service level of computing resources, or using customized information exposure strategies according to specific application requirements or network scheduling requirements. At the same time, when anonymity is achieved, it is important to ensure that the exposed computing information remains sufficient to enable effective traffic steering. Therefore, a CATS system:
CATS メトリックをネットワークに公開すると、アプリケーションのプライバシーが漏洩するおそれがあります。これを防ぐために、機微な情報を扱う方法を検討する必要があります。その例として、一般的な匿名化手法の利用があり、これにはデバイスの識別を表す主要な情報を隠すこと、コンピューティングリソースのサービスレベルをインデックスで表すこと、あるいは特定のアプリケーション要件やネットワークスケジューリング要件に応じてカスタマイズした情報公開戦略を用いることが含まれます。同時に、匿名性が確保されている場合でも、公開されるコンピューティング情報が効果的なトラフィックステアリングを可能にするのに十分であることを保証することが重要です。したがって、CATS システムは次のようにします。
R17:
R17:
MUST preserve the confidentiality of the communication relation between a user and a service provider by minimizing the exposure of user-relevant information according to user's demands but allowing for regulatory requirements in the environment where CATS is deployed. See also Section 6 for a discussion of confidentiality.
ユーザーの要求に応じてユーザー関連情報の公開を最小限に抑えることで、ユーザーとサービスプロバイダー間の通信関係の機密性を保持しなければなりません (MUST)。ただし、CATS が展開される環境における規制要件は考慮に入れます。機密性に関する議論については、セクション 6 も参照してください。
A table is presented in this section to better illustrate the correlation between CATS use cases and requirements; "X" is for marking that the requirement can be derived from the corresponding use case.
本セクションでは、CATS のユースケースと要件の対応関係をわかりやすく示すために表を提示します。「X」は、対応するユースケースからその要件を導き出せることを示します。
+==========================+================================+
| | Use Cases |
+==========================+=======+=====+====+========+====+
| Requirements | AR/VR | ITS | DT | SD-WAN | AI |
+====================+=====+=======+=====+====+========+====+
| Instance Selection | R1 | X | X | X | X | X |
| +-----+-------+-----+----+--------+----+
| | R2 | X | X | X | X | X |
+--------------------+-----+-------+-----+----+--------+----+
| Metric Definition | R3 | X | X | X | X | X |
| +-----+-------+-----+----+--------+----+
| | R4 | X | X | X | X | X |
| +-----+-------+-----+----+--------+----+
| | R5 | X | X | X | X | X |
| +-----+-------+-----+----+--------+----+
| | R6 | X | X | X | X | X |
| +-----+-------+-----+----+--------+----+
| | R7 | X | X | X | X | X |
| +-----+-------+-----+----+--------+----+
| | R8 | X | X | X | X | X |
| +-----+-------+-----+----+--------+----+
| | R9 | X | X | X | X | X |
| +-----+-------+-----+----+--------+----+
| | R10 | X | X | X | X | X |
+--------------------+-----+-------+-----+----+--------+----+
| Use of Metrics | R11 | X | X | X | X | X |
| +-----+-------+-----+----+--------+----+
| | R12 | X | X | X | X | X |
| +-----+-------+-----+----+--------+----+
| | R13 | X | X | X | X | X |
+--------------------+-----+-------+-----+----+--------+----+
| Instance Affinity | R14 | X | X | X | X | X |
| +-----+-------+-----+----+--------+----+
| | R15 | X | X | X | X | X |
| +-----+-------+-----+----+--------+----+
| | R16 | X | X | | | X |
+--------------------+-----+-------+-----+----+--------+----+
| Confidentiality | R17 | X | X | X | X | X |
+--------------------+-----+-------+-----+----+--------+----+
Table 1: Mapping Between CATS Use Cases and Requirements
表 1: CATS のユースケースと要件の対応
CATS decision making relies on real-time computing and network status as well as service information, requiring robust security safeguards to mitigate risks associated with dynamic service and resource scheduling, and cross-node data transmission.
CATS の意思決定は、リアルタイムのコンピューティングおよびネットワークの状態とサービス情報に依存します。そのため、動的なサービスおよびリソースのスケジューリングやノード間のデータ伝送に伴うリスクを軽減するために、堅牢なセキュリティ保護策が必要です。
Core security risks and requirements include:
主なセキュリティリスクと要件は次のとおりです。
* User Privacy Leakage Risk
* ユーザープライバシー漏洩のリスク
Description:
説明：
CATS involves user-related data (e.g., access patterns, service requests) across edge service sites. Unauthorized disclosure of user identifiers or per-user behavior tracking risks profiling or identity theft, especially in use cases with personal/context-rich data (e.g., AR/VR, vehicle trajectories, AI prompts), violating regulations and eroding trust.
CATS は、エッジサービスサイトにまたがるユーザー関連データ (たとえば、アクセスパターンやサービスリクエスト) を扱います。ユーザー識別子の不正な開示やユーザー単位の行動追跡は、特に個人情報やコンテキストが豊富なデータ (たとえば、AR/VR、車両の軌跡、AI プロンプト) を扱うユースケースにおいて、プロファイリングやなりすましのリスクを伴い、規制に違反して信頼を損ないます。
R18:
R18:
User activity privacy MUST be preserved by anonymizing identifying information. Per-user behavior pattern tracking is prohibited.
識別情報を匿名化することで、ユーザー活動のプライバシーを保持しなければなりません (MUST)。ユーザー単位の行動パターンの追跡は禁止されています。
* Service Instance Identity Spoofing and Traffic Hijacking
* サービスインスタンスの識別情報のなりすましとトラフィックのハイジャック
Description:
説明：
Attackers may spoof legitimate service instance identities or tamper with "CS-ID - instance address" mappings (per R1), diverting traffic to malicious nodes. This undermines CATS' core scheduling logic, causing service disruptions, data leaks, and potential physical harm in safety-critical scenarios.
攻撃者は、正当なサービスインスタンスの識別情報になりすましたり、(R1 に基づく) 「CS-ID - instance address」マッピングを改ざんしたりして、トラフィックを悪意のあるノードに迂回させる可能性があります。これは CATS の中核となるスケジューリングロジックを損ない、サービスの中断やデータ漏洩を引き起こし、安全性が重視されるシナリオでは物理的な被害を招くおそれがあります。
R19:
R19:
Service instances MUST be authenticated, and digital signatures SHOULD be used to provide proof of authentication. "CS-ID - instance address" mapping results MUST be encrypted.
サービスインスタンスは認証されなければなりません (MUST)。また、認証の証明を提供するためにデジタル署名を使用すべきです (SHOULD)。"CS-ID - instance address" のマッピング結果は暗号化されなければなりません (MUST)。
* Tampering and False Reporting of CATS Metrics
* CATSメトリックの改ざんと虚偽報告
Description:
説明:
Attackers may tamper with core scheduling metrics or submit false data (per R3-R17), misleading traffic steering decisions. This leads to node overload, link congestion, or "resource exhaustion attacks", directly degrading Quality of Experience (QoE).
攻撃者は、中核となるスケジューリングメトリックを改ざんしたり、虚偽のデータを送信したりして (R3〜R17に関連)、トラフィックステアリングの判断を誤らせる可能性があります。これにより、ノードの過負荷、リンクの輻輳、または「リソース枯渇攻撃」が発生し、体感品質 (QoE) が直接低下します。
R20:
R20:
Metric collection and distribution MUST employ integrity checks and encryption. Mechanisms for secondary validation and traceability of abnormal metrics MUST be supported, avoiding over-reliance on single-node reports.
メトリックの収集と配布では、完全性チェックと暗号化を採用しなければなりません (MUST)。単一ノードの報告に過度に依存しないよう、異常なメトリックに対する二次的な検証とトレーサビリティの仕組みをサポートしなければなりません (MUST)。
* Security of Cross-Node Context Migration Data
* ノード間コンテキスト移行データのセキュリティ
Description:
説明:
During user or terminal mobility, session states and computing context (e.g., AR rendering progress, vehicle status) may be intercepted or tampered with during cross-node migration. This impairs service continuity, leaks sensitive data, or causes state inconsistency.
ユーザまたは端末の移動中、セッション状態やコンピューティングのコンテキスト (例: ARのレンダリング進行状況、車両の状態) は、ノード間の移行中に傍受または改ざんされる可能性があります。これにより、サービスの継続性が損なわれたり、機微なデータが漏えいしたり、状態の不整合が生じたりします。
R21:
R21:
Migration data MUST use end-to-end encryption, accessible only to authorized target instances using, for example, Authenticated Encryption with Associated Data (AEAD). Migration instructions MUST include integrity check codes.
移行データは、エンドツーエンドの暗号化を使用しなければならず (MUST)、たとえば Authenticated Encryption with Associated Data (AEAD) を用いて、認可された移行先インスタンスだけがアクセスできるようにしなければなりません。移行の指示には、完全性チェックコードを含めなければなりません (MUST)。
This document has no IANA actions.
この文書には、IANAによる処理はありません。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, DOI 10.17487/RFC4760, January 2007, <https://www.rfc-editor.org/info/rfc4760>.
[RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast Services", BCP 126, RFC 4786, DOI 10.17487/RFC4786, December 2006, <https://www.rfc-editor.org/info/rfc4786>.
[RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S., Previdi, S., Roome, W., Shalunov, S., and R. Woundy, "Application-Layer Traffic Optimization (ALTO) Protocol", RFC 7285, DOI 10.17487/RFC7285, September 2014, <https://www.rfc-editor.org/info/rfc7285>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8990] Bormann, C., Carpenter, B., Ed., and B. Liu, Ed., "GeneRic Autonomic Signaling Protocol (GRASP)", RFC 8990, DOI 10.17487/RFC8990, May 2021, <https://www.rfc-editor.org/info/rfc8990>.
[RFC10053] Li, C., Ed., Du, Z., Boucadair, M., Ed., Contreras, L. M., and J. Drake, "A Framework for Computing-Aware Traffic Steering (CATS)", RFC 10053, DOI 10.17487/RFC10053, October 2026, <https://www.rfc-editor.org/info/rfc10053>.
[CAFL] Gu, Q., Jiang, K., Zhao, L., Zhou, H., and T. Jiang,
"Cost-Aware Federated Learning in Mobile Edge Networks",
FedEdge '24: Proceedings of the 3rd Workshop on Data
Privacy and Federated Learning Technologies for Mobile
Edge Network, pp. 13-18, DOI 10.1145/3694908.3696173,
2024, <https://doi.org/10.1145/3694908.3696173>.
[CATS-REQS]
Ngọc, T. M., Kiệm, N. T., and Y. Kim, "Additional CATS
requirements consideration for Service Segmentation-
related use cases", Work in Progress, Internet-Draft,
draft-dcn-cats-req-service-segmentation-03, 23 February
2026, <https://datatracker.ietf.org/doc/html/draft-dcn-
cats-req-service-segmentation-03>.
[ETSI-WI5] ETSI, "Details of 'DGR/ISC-005' Work Item", V0.1.0, ETSI
GR ISC 005, 30 January 2025,
<https://portal.etsi.org/eWPM/
index.html#/schedule?WKI_ID=74347>.
[GAIA-X] Gaia-X, "GAIA-X: A Federated Data Infrastructure for
Europe", 2023, <https://gaia-x.eu/>.
[HORITA] Horita, Y. and R. S. Schwartz, "Extended electronic
horizon for automated driving", Proceedings of 14th
International Conference on ITS Telecommunications (ITST),
pp. 32-36, DOI 10.1109/ITST.2015.7377396, 2015,
<https://doi.org/10.1109/ITST.2015.7377396>.
[Industry4.0]
Plattform Industrie 4.0, "Details of the Asset
Administration Shell, Part 1", 2022.
[MEF70.2] MEF, "SD-WAN Service Attributes and Service Framework",
MEF Standard, MEF 70.2, 2023,
<https://www.mplify.net/wp-content/uploads/MEF-70.2.pdf>.
[TR22.874] 3GPP, "5G System (5GS); Study on traffic characteristics
and performance requirements for AI/ML model transfer",
3GPP TR 22.874,
<https://portal.3gpp.org/desktopmodules/Specifications/
SpecificationDetails.aspx?specificationId=3721>.
This section presents an additional CATS use case, which is not included in the main body of this document. The reasons are that the use case may bring new requirements that are not considered in the initial charter of the CATS Working Group. The requirements impact the design of the CATS framework and may need further modification or enhancement on the initial CATS framework that serves all the existing use cases listed in the main body of this document. However, the Integrated Sensing and Communications (ISAC) use case is promising and has gained industry consensus. Therefore, this use case may be considered in future work of the CATS Working Group.
このセクションでは、この文書の本文には含まれていない追加のCATSユースケースを示します。含めなかった理由は、このユースケースが、CATSワーキンググループの当初の憲章では考慮されていない新たな要件をもたらす可能性があるためです。これらの要件はCATSフレームワークの設計に影響し、この文書の本文に挙げた既存のすべてのユースケースに対応する当初のCATSフレームワークに、さらなる修正や拡張が必要になる可能性があります。しかし、Integrated Sensing and Communications (ISAC) のユースケースは有望であり、業界のコンセンサスを得ています。したがって、このユースケースはCATSワーキンググループの今後の作業で検討される可能性があります。
Integrated Sensing and Communications (ISAC) enables wireless networks to perform simultaneous data transmission and environmental sensing. In a distributed sensing scenario, multiple network nodes (such as base stations, access points, or edge devices) collect raw sensing data from the environment. This data can include radio frequency (RF) reflections, Doppler shifts, channel state information (CSI), or other physical-layer features that provide insights into object movement, material composition, or environmental conditions. To extract meaningful information, the collected raw data must be aggregated and processed by a designated computing node with sufficient computational resources. This requires efficient coordination between sensing nodes and computing resources to ensure timely and accurate analysis, making it a relevant use case for Computing-Aware Traffic Steering (CATS) in the IETF.
Integrated Sensing and Communications (ISAC) により、無線ネットワークはデータ伝送と環境センシングを同時に実行できます。分散センシングのシナリオでは、複数のネットワークノード (基地局、アクセスポイント、エッジデバイスなど) が環境から生のセンシングデータを収集します。このデータには、無線周波数 (RF) の反射、ドップラーシフト、チャネル状態情報 (CSI)、あるいは物体の動き、物質の組成、環境条件に関する知見をもたらすその他の物理層の特徴が含まれる場合があります。意味のある情報を抽出するには、収集した生データを、十分な計算リソースを持つ指定のコンピューティングノードで集約して処理しなければなりません。そのためには、タイムリーかつ正確な分析を確保するために、センシングノードとコンピューティングリソースの間の効率的な連携が必要です。これにより、IETFにおけるコンピューティング対応トラフィックステアリング (CATS) に関連するユースケースとなっています。
This use case aligns with ongoing efforts in standardization bodies such as the ETSI ISAC Industry Specification Group (ISG), particularly Work Item #5 (WI #5), titled "Integration of Computing with ISAC" [ETSI-WI5]. WI #5 focuses on exploring different forms of computing integration within ISAC systems, including sensing combined with computing, communications combined with computing, and the holistic integration of ISAC with computing. The considerations outlined in this document complement ETSI's work by examining how computing-aware networking solutions, as developed within CATS, can optimize the processing and routing of ISAC sensing data.
このユースケースは、ETSI ISAC Industry Specification Group (ISG) などの標準化団体で進行中の取り組み、特に "Integration of Computing with ISAC" と題された Work Item #5 (WI #5) [ETSI-WI5] と整合しています。WI #5 は、センシングとコンピューティングの組み合わせ、通信とコンピューティングの組み合わせ、ISACとコンピューティングの全体的な統合など、ISACシステム内におけるコンピューティング統合のさまざまな形態の探究に重点を置いています。この文書で示す考慮事項は、CATSで開発されているようなコンピューティング対応のネットワーキングソリューションが、ISACのセンシングデータの処理とルーティングをどのように最適化できるかを検討することで、ETSIの作業を補完するものです。
As an example, we can consider a network domain with multiple sites capable of hosting the ISAC computing "service", each with potentially different connectivity and computing characteristics. Figure 6 shows an exemplary scenario. Considering the connectivity and computing latencies (just as an example of metrics), the best service site is #N-1 in the example used in Figure 6. Note that in the figure we still use the old terminology, in which "ICR" means "Ingress CATS-Forwarder" [RFC10053] and "ECR" means "Egress CATS-Forwarder".
一例として、ISACコンピューティングの「サービス」をホストできる複数のサイトを持つネットワークドメインを考えます。各サイトは、接続性とコンピューティングの特性がそれぞれ異なる可能性があります。図6に例示的なシナリオを示します。接続性とコンピューティングのレイテンシ (メトリックの一例にすぎません) を考慮すると、図6の例で最適なサービスサイトは #N-1 です。なお、この図では依然として古い用語を使用しており、"ICR" は "Ingress CATS-Forwarder" [RFC10053] を、"ECR" は "Egress CATS-Forwarder" を意味します。
_______________
( -------- )
( | | )
( -------- | )
________________ ( | | | ) ________________
( -------- ) ( --------- | | ) ( -------- )
( | | ) ( |service | |- ) ( | | )
( -------- | ) ( |contact | | ) ( -------- | )
( | | | ) ( |instance|- ) ( | | | )
( -------- | | ) ( --------- ) ( -------- | | )
( |service | |- ) ( Serv. site #N-1 ) ( |service | |- )
( |contact | | ) -------+--------- ( |contact | | )
( |instance|- ) Computing \ ( |instance|- )
( -------- ) delay:4ms \ ( -------- )
( Serv. site #1 ) ------+-- ( Serv. site #N )
-------+------- ----| ECR#N-1 |---- ---------+-----
\ Computing -- --------- -- Computing /
\ delay:10ms Networking delay:5ms /
--+---- delay:7ms -----+-
( | ECR#1 | // | ECR#N | )
( ------- // ------- )
( Networking // Networking )
( delay:5ms // delay:15ms )
( // )
( // )
( // )
( // )
( // )
( ------- ------- )
-------| ICR#1 |---------------------| ICR#2 |--------
------- __ -------
(.) (.) / ( ) (.)
(.) ----- - ( ) (.)
(.) | UE2 | / (__) \ (.)
(.) ----- / - -----
(.) / (sensing) \ | UE3 |
----- ----------- -----
| UE1 | /
-----
Figure 6: Exemplary ISAC Scenario
図6: ISACシナリオの例
In the distributed sensing use case, the sensed data collected by multiple nodes must be efficiently routed to a computing node capable of processing it. The choice of the computing node depends on several factors, including computational load, network congestion, and latency constraints. CATS mechanisms can optimize the selection of the processing node by dynamically steering the traffic based on computing resource availability and network conditions. Additionally, as sensing data is often time sensitive, CATS can ensure low-latency paths while balancing computational demands across different processing entities. This capability is essential for real-time applications such as cooperative perception for autonomous systems, industrial monitoring, and smart city infrastructure.
分散センシングのユースケースでは、複数のノードが収集したセンシングデータを、それを処理できるコンピューティングノードへ効率的にルーティングしなければなりません。コンピューティングノードの選択は、計算負荷、ネットワークの輻輳、レイテンシの制約など、いくつかの要因に依存します。CATSの仕組みは、コンピューティングリソースの可用性とネットワーク状況に基づいてトラフィックを動的にステアリングすることで、処理ノードの選択を最適化できます。さらに、センシングデータはしばしば時間的な制約が厳しいため、CATSは、さまざまな処理エンティティ間で計算需要のバランスを取りながら、低レイテンシの経路を確保できます。この能力は、自律システムの協調認識、産業用モニタリング、スマートシティのインフラストラクチャなど、リアルタイムのアプリケーションにとって不可欠です。
In addition to some of the requirements already identified for CATS in the main body of this document, there are several additional challenges and requirements that need to be addressed for efficient distributed sensing in ISAC-enabled networks.
この文書の本文でCATSについてすでに特定されている要件の一部に加えて、ISAC対応ネットワークにおける効率的な分散センシングのために対処が必要な、いくつかの追加の課題と要件があります。
CATS systems should be able to select an instance where multiple nodes can steer traffic simultaneously, ensuring that packets arrive within a maximum time period. This is required because there are distributed tasks in which there are multiple nodes acting as sensors that produce sensing data that has to then be processed by a sensing processing function, typically hosted at the edge. This implies that there is a multi-point to point kind of direction of the traffic, with connectivity and computing requirements associated (which can be very strict for some types of sensing schema).
CATSシステムは、複数のノードが同時にトラフィックをステアリングでき、パケットが最大許容時間内に到着することを保証できるインスタンスを選択できるべきです。これが必要なのは、複数のノードがセンサとして動作してセンシングデータを生成し、そのデータを、通常はエッジでホストされるセンシング処理機能が処理しなければならない分散タスクが存在するためです。これは、接続性とコンピューティングの要件 (センシング方式によっては非常に厳しい場合があります) を伴う、多地点から1地点へというトラフィックの方向性を意味します。
CATS systems should provide mechanisms that implement per node/flow security and privacy policies to adapt to the nature of the sensitive information that might be exchanged in a sensing task.
CATSシステムは、センシングタスクで交換される可能性のある機微な情報の性質に適応するために、ノード/フローごとのセキュリティおよびプライバシーポリシーを実装する仕組みを提供すべきです。
The authors would like to thank Adrian Farrel, Peng Liu, Joel Halpern, Jim Guichard, Cheng Li, Luigi Iannone, Christian Jacquenet, Xiaodong Duan, Yuexia Fu, Huijuan Yao, Zongpeng Du, Jing Wang, Erum Welling, Ines Robles, Linda Dunbar, Jim Reid, Zaheduzzaman Sarker, Tim Bray, Samier Barguil, Daniel Migault, Roni Even, Roman Danyliw, Gorry Fairhurst, Ketan Talaulikar, Andy Newton, Deb Cooley, Erik Kline, and Paul Wouters for their valuable suggestions to this document.
著者らは、この文書に対する貴重な提案をくださった Adrian Farrel、Peng Liu、Joel Halpern、Jim Guichard、Cheng Li、Luigi Iannone、Christian Jacquenet、Xiaodong Duan、Yuexia Fu、Huijuan Yao、Zongpeng Du、Jing Wang、Erum Welling、Ines Robles、Linda Dunbar、Jim Reid、Zaheduzzaman Sarker、Tim Bray、Samier Barguil、Daniel Migault、Roni Even、Roman Danyliw、Gorry Fairhurst、Ketan Talaulikar、Andy Newton、Deb Cooley、Erik Kline、Paul Wouters の各氏に感謝します。
The authors would like to thank Yizhou Li for her early IETF work of Compute First Network (CFN) and Dynamic Anycast (Dyncast), which inspired the CATS work.
著者らは、CATSの取り組みに着想を与えた、Compute First Network (CFN) と Dynamic Anycast (Dyncast) に関する Yizhou Li 氏の初期のIETFでの業績に感謝します。
The following people have substantially contributed to this document:
次の方々が、この文書に実質的な貢献をしました。
Yizhou Li
Huawei Technologies
Email: liyizhou@huawei.com
Dirk Trossen
Email: dirk@trossen.tech
Mohamed Boucadair
Orange
Email: mohamed.boucadair@orange.com
Carlos J. Bernardos
UC3M
Email: cjbc@it.uc3m.es
Peter Willis
Email: pjw7904@rit.edu
Philip Eardley
Email: ietf.philip.eardley@gmail.com
Tianji Jiang
China Mobile
Email: tianjijiang@chinamobile.com
Minh-Ngoc Tran
ETRI
Email: mipearlska@etri.re.kr
Markus Amend
Deutsche Telekom
Email: Markus.Amend@telekom.de
Guangping Huang
ZTE
Email: huang.guangping@zte.com.cn
Dongyu Yuan
ZTE
Email: yuan.dongyu@zte.com.cn
Xinxin Yi
China Unicom
Email: yixx3@chinaunicom.cn
Tao Fu
CAICT
Email: futao@caict.ac.cn
Jordi Ros-Giralt
Qualcomm Europe, Inc.
Email: jros@qti.qualcomm.com
Jaehoon Paul Jeong
Sungkyunkwan University
Email: pauljeong@skku.edu
Yan Wang
Migu Culture Technology Co., Ltd
Email: wangyan_hy1@migu.chinamobile.com
Kehan Yao
China Mobile
Email: yaokehan@chinamobile.com
Luis M. Contreras
Telefonica
Email: luismiguel.contrerasmurillo@telefonica.com
Hang Shi
Huawei Technologies
Email: shihang9@huawei.com
Shuai Zhang
China Unicom
Email: zhangs366@chinaunicom.cn
Qing An
Alibaba Group
Email: anqing.aq@alibaba-inc.com