[要約] RFC 9232は、ネットワークテレメトリの枠組みと分類を提供し、ネットワーク管理を効率化するための技術です。ネットワーク運用における課題と要件に基づいて、リモートデータ生成、収集、相関、消費のためのアーキテクチャフレームワークを説明しています。
Internet Engineering Task Force (IETF) H. Song
Request for Comments: 9232 Futurewei
Category: Informational F. Qin
ISSN: 2070-1721 China Mobile
P. Martinez-Julia
NICT
L. Ciavaglia
Rakuten Mobile
A. Wang
China Telecom
May 2022
Network Telemetry Framework
ネットワークテレメトリーフレームワーク
Abstract
概要
Network telemetry is a technology for gaining network insight and facilitating efficient and automated network management. It encompasses various techniques for remote data generation, collection, correlation, and consumption. This document describes an architectural framework for network telemetry, motivated by challenges that are encountered as part of the operation of networks and by the requirements that ensue. This document clarifies the terminology and classifies the modules and components of a network telemetry system from different perspectives. The framework and taxonomy help to set a common ground for the collection of related work and provide guidance for related technique and standard developments.
ネットワークテレメトリは、ネットワークの洞察を得て、効率的で自動化されたネットワーク管理を促進するためのテクノロジーです。リモートのデータ生成、収集、相関、および消費のためのさまざまな手法が含まれます。このドキュメントでは、ネットワークの運用の一部として遭遇する課題とその後の要件によって動機付けられたネットワークテレメトリのアーキテクチャフレームワークについて説明します。このドキュメントは、用語を明確にし、異なる視点からネットワークテレメトリシステムのモジュールとコンポーネントを分類します。フレームワークと分類法は、関連する作業の収集の共通の根拠を設定し、関連する手法と標準的な開発のガイダンスを提供するのに役立ちます。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。
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.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。IESGによって承認されたすべてのドキュメントが、インターネット標準のあらゆるレベルの候補者であるわけではありません。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/rfc9232.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9232で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2022 IETF Trustおよび文書著者として特定された人。全著作権所有。
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ドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、修正されたBSDライセンスで説明されているように保証なしで提供される修正されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction
1.1. Applicability Statement
1.2. Glossary
2. Background
2.1. Telemetry Data Coverage
2.2. Use Cases
2.3. Challenges
2.4. Network Telemetry
2.5. The Necessity of a Network Telemetry Framework
3. Network Telemetry Framework
3.1. Top-Level Modules
3.1.1. Management Plane Telemetry
3.1.2. Control Plane Telemetry
3.1.3. Forwarding Plane Telemetry
3.1.4. External Data Telemetry
3.2. Second-Level Function Components
3.3. Data Acquisition Mechanism and Type Abstraction
3.4. Mapping Existing Mechanisms into the Framework
4. Evolution of Network Telemetry Applications
5. Security Considerations
6. IANA Considerations
7. Informative References
Appendix A. A Survey on Existing Network Telemetry Techniques
A.1. Management Plane Telemetry
A.1.1. Push Extensions for NETCONF
A.1.2. gRPC Network Management Interface
A.2. Control Plane Telemetry
A.2.1. BGP Monitoring Protocol
A.3. Data Plane Telemetry
A.3.1. Alternate-Marking (AM) Technology
A.3.2. Dynamic Network Probe
A.3.3. IP Flow Information Export (IPFIX) Protocol
A.3.4. In Situ OAM
A.3.5. Postcard-Based Telemetry
A.3.6. Existing OAM for Specific Data Planes
A.4. External Data and Event Telemetry
A.4.1. Sources of External Events
A.4.2. Connectors and Interfaces
Acknowledgments
Contributors
Authors' Addresses
Network visibility is the ability of management tools to see the state and behavior of a network, which is essential for successful network operation. Network telemetry revolves around network data that 1) can help provide insights about the current state of the network, including network devices, forwarding, control, and management planes; 2) can be generated and obtained through a variety of techniques, including but not limited to network instrumentation and measurements; and 3) can be processed for purposes ranging from service assurance to network security using a wide variety of data analytical techniques. In this document, network telemetry refers to both the data itself (i.e., "Network Telemetry Data") and the techniques and processes used to generate, export, collect, and consume that data for use by potentially automated management applications. Network telemetry extends beyond the classical network Operations, Administration, and Management (OAM) techniques and expects to support better flexibility, scalability, accuracy, coverage, and performance.
ネットワークの可視性とは、ネットワークの状態と動作を確認する管理ツールの能力であり、これはネットワーク操作を成功させるために不可欠です。ネットワークテレメトリは、1）ネットワークデバイス、転送、制御、管理プレーンなど、ネットワークの現在の状態に関する洞察を提供できるネットワークデータを中心に展開します。 2）ネットワークの計装と測定を含むがこれらに限定されないさまざまな手法を通じて生成および取得することができます。 3）さまざまなデータ分析手法を使用して、サービス保証からネットワークセキュリティまでの範囲の目的で処理できます。このドキュメントでは、ネットワークテレメトリは、データ自体（つまり、「ネットワークテレメトリデータ」）と、潜在的に自動化された管理アプリケーションで使用するデータを生成、エクスポート、収集、および消費するために使用される手法とプロセスの両方を指します。ネットワークテレメトリは、古典的なネットワーク操作、管理、および管理（OAM）技術を超えて拡張され、柔軟性、スケーラビリティ、精度、カバレッジ、パフォーマンスの向上をサポートすることが期待されています。
However, the term "network telemetry" lacks an unambiguous definition. The scope and coverage of it cause confusion and misunderstandings. It is beneficial to clarify the concept and provide a clear architectural framework for network telemetry, so we can articulate the technical field and better align the related techniques and standard works.
ただし、「ネットワークテレメトリ」という用語には、明確な定義がありません。それの範囲と報道は、混乱と誤解を引き起こします。概念を明確にし、ネットワークテレメトリの明確なアーキテクチャフレームワークを提供することが有益であるため、技術分野を明確にし、関連するテクニックと標準作業をより適切に調整できます。
To fulfill such an undertaking, we first discuss some key characteristics of network telemetry that set a clear distinction from the conventional network OAM and show that some conventional OAM technologies can be considered a subset of the network telemetry technologies. We then provide an architectural framework for network telemetry that includes four modules, each associated with a different category of telemetry data and corresponding procedures. All the modules are internally structured in the same way, including components that allow the operator to configure data sources in regard to what data to generate and how to make that available to client applications, components that instrument the underlying data sources, and components that perform the actual rendering, encoding, and exporting of the generated data. We show how the network telemetry framework can benefit current and future network operations. Based on the distinction of modules and function components, we can map the existing and emerging techniques and protocols into the framework. The framework can also simplify designing, maintaining, and understanding a network telemetry system. In addition, we outline the evolution stages of the network telemetry system and discuss the potential security concerns.
このような取り組みを満たすために、最初に、従来のネットワークOAMから明確な区別を設定したネットワークテレメトリのいくつかの重要な特性を議論し、いくつかの従来のOAMテクノロジーがネットワークテレメトリテクノロジーのサブセットと見なすことができることを示します。次に、4つのモジュールを含むネットワークテレメトリのアーキテクチャフレームワークを提供し、それぞれが異なるカテゴリのテレメトリデータと対応する手順に関連付けられています。すべてのモジュールは、オペレーターがどのデータを生成するか、クライアントアプリケーションで利用可能にする方法に関してデータソースを構成できるコンポーネント、基礎となるデータソースを計測するコンポーネント、実行するコンポーネントを含む、同じ方法で内部的に構成されています。生成されたデータの実際のレンダリング、エンコード、エクスポート。ネットワークテレメトリーフレームワークが現在および将来のネットワーク操作にどのように役立つかを示します。モジュールと関数コンポーネントの区別に基づいて、既存の技術と新興の手法とプロトコルをフレームワークにマッピングできます。このフレームワークは、ネットワークテレメトリシステムの設計、維持、および理解を簡素化することもできます。さらに、ネットワークテレメトリシステムの進化段階の概要を説明し、潜在的なセキュリティの懸念について説明します。
The purpose of the framework and taxonomy is to set a common ground for the collection of related work and provide guidance for future technique and standard developments. To the best of our knowledge, this document is the first such effort for network telemetry in industry standards organizations. This document does not define specific technologies.
フレームワークと分類法の目的は、関連する作業の収集の共通の根拠を設定し、将来のテクニックと標準開発のガイダンスを提供することです。私たちの知る限り、このドキュメントは、業界標準組織におけるネットワークテレメトリのための最初のそのような取り組みです。このドキュメントは、特定のテクノロジーを定義しません。
Large-scale network data collection is a major threat to user privacy and may be indistinguishable from pervasive monitoring [RFC7258]. The network telemetry framework presented in this document must not be applied to generating, exporting, collecting, analyzing, or retaining individual user data or any data that can identify end users or characterize their behavior without consent. Based on this principle, the network telemetry framework is not applicable to networks whose endpoints represent individual users, such as general-purpose access networks.
大規模なネットワークデータ収集は、ユーザーのプライバシーに対する大きな脅威であり、広範な監視[RFC7258]と見分けがつかない場合があります。このドキュメントに示されているネットワークテレメトリフレームワークは、個々のユーザーデータまたはエンドユーザーを識別したり、同意なしに行動を特徴付けることができるデータの生成、エクスポート、収集、分析、または保持に適用してはなりません。この原則に基づいて、ネットワークテレメトリフレームワークは、汎用アクセスネットワークなど、エンドポイントが個々のユーザーを表すネットワークには適用されません。
Before further discussion, we list some key terminology and abbreviations used in this document. There is an intended differentiation between the terms of network telemetry and OAM. However, it should be understood that there is not a hard-line distinction between the two concepts. Rather, network telemetry is considered an extension of OAM. It covers all the existing OAM protocols but puts more emphasis on the newer and emerging techniques and protocols concerning all aspects of network data from acquisition to consumption.
さらに議論する前に、このドキュメントで使用されているいくつかの重要な用語と略語をリストします。ネットワークテレメトリとOAMの条件には、意図した区別があります。ただし、2つの概念の間には厳しい違いがないことを理解する必要があります。むしろ、ネットワークテレメトリはOAMの拡張と見なされます。既存のすべてのOAMプロトコルをカバーしていますが、ネットワークデータのすべての側面に関する新しいテクニックとプロトコルを、取得から消費までのすべての側面に関するより重視しています。
AI: Artificial Intelligence. In the network domain, AI refers to machine-learning-based technologies for automated network operation and other tasks.
AI：人工知能。ネットワークドメインでは、AIは、自動化されたネットワーク操作およびその他のタスクのためのマシンラーニングベースのテクノロジーを指します。
AM: Alternate Marking. A flow performance measurement method, as specified in [RFC8321].
AM：代替マーキング。[RFC8321]で指定されているフローパフォーマンス測定方法。
BMP: BGP Monitoring Protocol. Specified in [RFC7854].
BMP：BGPモニタリングプロトコル。[RFC7854]で指定されています。
DPI: Deep Packet Inspection. Refers to the techniques that examine packets beyond packet L3/L4 headers.
DPI：深いパケット検査。パケットL3/L4ヘッダーを超えてパケットを調べる手法を指します。
gNMI: gRPC Network Management Interface. A network management protocol from the OpenConfig Operator Working Group, mainly contributed by Google. See [gnmi] for details.
GNMI：GRPCネットワーク管理インターフェイス。主にGoogleが貢献したOpenConFigオペレーターワーキンググループのネットワーク管理プロトコル。詳細については、[gnmi]を参照してください。
GPB: Google Protocol Buffer. An extensible mechanism for serializing structured data. See [gpb] for details.
GPB：Googleプロトコルバッファー。構造化データをシリアル化するための拡張可能なメカニズム。詳細については、[GPB]を参照してください。
gRPC: gRPC Remote Procedure Call. An open-source high-performance RPC framework that gNMI is based on. See [grpc] for details.
GRPC：GRPCリモートプロシージャコール。GNMIが基づいているオープンソースの高性能RPCフレームワーク。詳細については、[GRPC]を参照してください。
IPFIX: IP Flow Information Export Protocol. Specified in [RFC7011].
IPFIX：IPフロー情報エクスポートプロトコル。[RFC7011]で指定されています。
IOAM: In situ OAM [RFC9197]. A data plane on-path telemetry technique.
IOAM：in situ OAM [RFC9197]。データプレーンオンパステレメトリテクニック。
JSON: JavaScript Object Notation. An open standard file format and data interchange format that uses human-readable text to store and transmit data objects, as specified in [RFC8259].
JSON：JavaScriptオブジェクト表記。[RFC8259]で指定されているように、人間が読み取り可能なテキストを使用してデータオブジェクトを保存および送信するオープン標準ファイル形式とデータインターチェンジ形式。
MIB: Management Information Base. A database used for managing the entities in a network.
MIB：管理情報ベース。ネットワーク内のエンティティの管理に使用されるデータベース。
NETCONF: Network Configuration Protocol. Specified in [RFC6241].
NetConf：ネットワーク構成プロトコル。[RFC6241]で指定されています。
NetFlow: A Cisco protocol used for flow record collecting, as described in [RFC3954].
Netflow：[RFC3954]で説明されているように、フローレコード収集に使用されるシスコプロトコル。
Network Telemetry: The process and instrumentation for acquiring and utilizing network data remotely for network monitoring and operation. A general term for a large set of network visibility techniques and protocols, concerning aspects like data generation, collection, correlation, and consumption. Network telemetry addresses current network operation issues and enables smooth evolution toward future intent-driven autonomous networks.
ネットワークテレメトリ：ネットワーク監視と操作のためにネットワークデータをリモートで取得および利用するためのプロセスと機器。データ生成、収集、相関、消費などの側面に関するネットワーク可視性技術とプロトコルの大規模なセットの一般的な用語。ネットワークテレメトリは、現在のネットワーク操作の問題に対処し、将来の意図駆動型の自律ネットワークに向けてスムーズな進化を可能にします。
NMS: Network Management System. Refers to applications that allow network administrators to manage a network.
NMS：ネットワーク管理システム。ネットワーク管理者がネットワークを管理できるようにするアプリケーションを指します。
OAM: Operations, Administration, and Maintenance. A group of network management functions that provide network fault indication, fault localization, performance information, and data and diagnosis functions. Most conventional network monitoring techniques and protocols belong to network OAM.
OAM：運用、管理、およびメンテナンス。ネットワーク障害の表示、障害のローカリゼーション、パフォーマンス情報、およびデータと診断機能を提供するネットワーク管理機能のグループ。ほとんどの従来のネットワーク監視手法とプロトコルは、ネットワークOAMに属します。
PBT: Postcard-Based Telemetry. A data plane on-path telemetry technique. A representative technique is described in [IPPM-IOAM-DIRECT-EXPORT].
PBT：はがきベースのテレメトリー。データプレーンオンパステレメトリテクニック。代表的な手法は、[IPPM-Ioam-Direct-Export]で説明されています。
RESTCONF: An HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG, using the datastore concepts defined in NETCONF, as specified in [RFC8040].
RestConf：[RFC8040]で指定されているように、NetConfで定義されたデータストアの概念を使用して、Yangで定義されたデータにアクセスするためのプログラムインターフェイスを提供するHTTPベースのプロトコル。
SMIv2: Structure of Management Information Version 2. Defines MIB objects, as specified in [RFC2578].
SMIV2：管理情報の構造バージョン2。[RFC2578]で指定されているMIBオブジェクトを定義します。
SNMP: Simple Network Management Protocol. Versions 1, 2, and 3 are specified in [RFC1157], [RFC3416], and [RFC3411], respectively.
SNMP：シンプルなネットワーク管理プロトコル。バージョン1、2、および3は、それぞれ[RFC1157]、[RFC3416]、および[RFC3411]で指定されています。
XML: Extensible Markup Language. A markup language for data encoding that is both human readable and machine readable, as specified by W3C [W3C.REC-xml-20081126].
XML：拡張可能なマークアップ言語。W3C [W3C.REC-XML-20081126]で指定されているように、人間の読み取り可能であり読み取り可能なデータエンコードのマークアップ言語。
YANG: YANG is a data modeling language for the definition of data sent over network management protocols such as NETCONF and RESTCONF. YANG is defined in [RFC6020] and [RFC7950].
Yang：Yangは、NetConfやRestConfなどのネットワーク管理プロトコルを介して送信されるデータの定義のデータモデリング言語です。Yangは[RFC6020]および[RFC7950]で定義されています。
YANG ECA: A YANG model for Event-Condition-Action policies, as defined in [NETMOD-ECA-POLICY].
Yang ECA：[netmod-eca-policy]で定義されているイベント条件とアクションポリシーのヤンモデル。
YANG-Push: A mechanism that allows subscriber applications to request a stream of updates from a YANG datastore on a network device. Details are specified in [RFC8639] and [RFC8641].
Yang-Push：サブスクライバーアプリケーションがネットワークデバイス上のYangデータストアから更新のストリームを要求できるメカニズム。詳細は[RFC8639]および[RFC8641]で指定されています。
The term "big data" is used to describe the extremely large volume of data sets that can be analyzed computationally to reveal patterns, trends, and associations. Networks are undoubtedly a source of big data because of their scale and the volume of network traffic they forward. When a network's endpoints do not represent individual users (e.g., in industrial, data-center, and infrastructure contexts), network operations can often benefit from large-scale data collection without breaching user privacy.
「ビッグデータ」という用語は、パターン、トレンド、および関連付けを明らかにするために計算的に分析できる非常に大量のデータセットを記述するために使用されます。ネットワークは、間違いなく、スケールと転送されるネットワークトラフィックの量があるため、ビッグデータのソースです。ネットワークのエンドポイントが個々のユーザー（産業、データセンター、インフラストラクチャのコンテキストなど）を表していない場合、ネットワーク操作は、ユーザーのプライバシーに違反することなく、大規模なデータ収集の恩恵を受けることがよくあります。
Today, one can access advanced big data analytics capability through a plethora of commercial and open-source platforms (e.g., Apache Hadoop), tools (e.g., Apache Spark), and techniques (e.g., machine learning). Thanks to the advance of computing and storage technologies, network big data analytics give network operators an opportunity to gain network insights and move towards network autonomy. Some operators start to explore the application of Artificial Intelligence (AI) to make sense of network data. Software tools can use the network data to detect and react on network faults, anomalies, and policy violations, as well as predict future events. In turn, the network policy updates for planning, intrusion prevention, optimization, and self-healing may be applied.
今日、多くの商用およびオープンソースプラットフォーム（Apache Hadoopなど）、ツール（Apache Sparkなど）、およびテクニック（たとえば、機械学習）を通じて、高度なビッグデータ分析機能にアクセスできます。コンピューティングとストレージテクノロジーの進歩のおかげで、ネットワークビッグデータ分析は、ネットワークオペレーターがネットワークの洞察を得て、ネットワークの自律性に向かって移動する機会を与えます。一部のオペレーターは、ネットワークデータを理解するために人工知能（AI）の適用を探求し始めます。ソフトウェアツールは、ネットワークデータを使用して、ネットワーク障害、異常、およびポリシー違反を検出および反応させ、将来のイベントを予測できます。次に、計画、侵入防止、最適化、および自己修復のためのネットワークポリシーの更新を適用することができます。
It is conceivable that an autonomic network [RFC7575] is the logical next step for network evolution following Software-Defined Networking (SDN), which aims to reduce (or even eliminate) human labor, make more efficient use of network resources, and provide better services more aligned with customer requirements. The IETF ANIMA Working Group is dedicated to developing and maintaining protocols and procedures for automated network management and control of professionally managed networks. The related technique of Intent-Based Networking (IBN) [NMRG-IBN-CONCEPTS-DEFINITIONS] requires network visibility and telemetry data in order to ensure that the network is behaving as intended.
自律的ネットワーク[RFC7575]は、人間の労働を削減（または排除する）、さらにはネットワークリソースをより効率的に使用し、より良い提供を提供することを目的としたソフトウェア定義ネットワーキング（SDN）に続くネットワーク進化の論理的な次のステップであると考えられます。顧客の要件にもっと合わせたサービス。IETF Animaワーキンググループは、プロが管理したネットワークの自動化されたネットワーク管理と制御のためのプロトコルと手順の開発と維持に専念しています。関連する意図ベースのネットワーキング（IBN）[NMRG-IBN Concepts-definitions]には、ネットワークが意図されたとおりに動作していることを確認するために、ネットワークの可視性とテレメトリデータが必要です。
However, while the data processing capability is improved and applications require more data to function better, the networks lag behind in extracting and translating network data into useful and actionable information in efficient ways. The system bottleneck is shifting from data consumption to data supply. Both the number of network nodes and the traffic bandwidth keep increasing at a fast pace. The network configuration and policy change at smaller time slots than before. More subtle events and fine-grained data through all network planes need to be captured and exported in real time. In a nutshell, it is a challenge to get enough high-quality data out of the network in a manner that is efficient, timely, and flexible. Therefore, we need to survey the existing technologies and protocols and identify any potential gaps.
ただし、データ処理機能は改善され、アプリケーションはより多くのデータをより良く機能させるためにより多くのデータを必要としますが、ネットワークは、ネットワークデータを効率的な方法で有用で実用的な情報に抽出および変換することに遅れをとっています。システムのボトルネックは、データ消費からデータの供給に移行しています。ネットワークノードの数とトラフィック帯域幅の両方が、ペースが速く増加し続けます。ネットワークの構成とポリシーは、以前よりも小さな時間スロットで変更されます。すべてのネットワークプレーンを介したより微妙なイベントときめの細かいデータをリアルタイムでキャプチャしてエクスポートする必要があります。一言で言えば、効率的でタイムリーで柔軟な方法で、ネットワークから十分な高品質のデータを取得することは挑戦です。したがって、既存のテクノロジーとプロトコルを調査し、潜在的なギャップを特定する必要があります。
In the remainder of this section, we first clarify the scope of network data (i.e., telemetry data) relevant in this document. Then, we discuss several key use cases for network operations of today and the future. Next, we show why the current network OAM techniques and protocols are insufficient for these use cases. The discussion underlines the need for new methods, techniques, and protocols, as well as the extensions of existing ones, which we assign under the umbrella term "Network Telemetry".
このセクションの残りの部分では、まずこのドキュメントに関連するネットワークデータ（つまり、テレメトリデータ）の範囲を明確にします。次に、今日と未来のネットワーク操作に関するいくつかの重要なユースケースについて説明します。次に、現在のネットワークOAM技術とプロトコルがこれらのユースケースに不十分である理由を示します。この議論は、新しい方法、テクニック、プロトコルの必要性と、傘の用語「ネットワークテレメトリ」の下で割り当てる既存の方法の拡張の必要性を強調しています。
Any information that can be extracted from networks (including the data plane, control plane, and management plane) and used to gain visibility or as a basis for actions is considered telemetry data. It includes statistics, event records and logs, snapshots of state, configuration data, etc. It also covers the outputs of any active and passive measurements [RFC7799]. In some cases, raw data is processed in network before being sent to a data consumer. Such processed data is also considered telemetry data. The value of telemetry data varies. In some cases, if the cost is acceptable, less but higher-quality data are preferred rather than a lot of low-quality data. A classification of telemetry data is provided in Section 3. To preserve the privacy of end users, no user packet content should be collected. Specifically, the data objects generated, exported, and collected by a network telemetry application should not include any packet payload from traffic associated with end-user systems.
ネットワーク（データプレーン、コントロールプレーン、および管理プレーンを含む）から抽出できる情報は、可視性を獲得するために、またはアクションの基礎として使用される情報がテレメトリーデータと見なされます。統計、イベントの記録とログ、状態のスナップショット、構成データなどが含まれます。また、アクティブおよびパッシブ測定の出力もカバーしています[RFC7799]。場合によっては、データ消費者に送信される前に、生データがネットワークで処理されます。このような処理されたデータもテレメトリーデータと見なされます。テレメトリーデータの値は異なります。場合によっては、コストが受け入れられる場合、多くの低品質データよりも高品質のデータが優先されますが、高品質のデータが優先されます。テレメトリデータの分類をセクション3で提供します。エンドユーザーのプライバシーを保存するには、ユーザーパケットコンテンツを収集する必要はありません。具体的には、ネットワークテレメトリアプリケーションによって生成、エクスポート、および収集されたデータオブジェクトには、エンドユーザーシステムに関連付けられたトラフィックからのパケットペイロードを含めるべきではありません。
The following set of use cases is essential for network operations. While the list is by no means exhaustive, it is enough to highlight the requirements for data velocity, variety, volume, and veracity, the attributes of big data, in networks.
次のユースケースのセットは、ネットワーク操作に不可欠です。リストは決して網羅的ではありませんが、ネットワークのビッグデータの属性であるデータ速度、多様性、量、真実性の要件を強調するだけで十分です。
* Security: Network intrusion detection and prevention systems need to monitor network traffic and activities and act upon anomalies. Given increasingly sophisticated attack vectors coupled with increasingly severe consequences of security breaches, new tools and techniques need to be developed, relying on wider and deeper visibility into networks. The ultimate goal is to achieve security with no, or only minimal, human intervention and without disrupting legitimate traffic flows.
* セキュリティ：ネットワーク侵入検出および予防システムは、ネットワークのトラフィックと活動を監視し、異常に基づいて行動する必要があります。セキュリティ侵害のますます深刻な結果と相まってますます洗練された攻撃ベクトルを考慮すると、新しいツールとテクニックを開発する必要があり、ネットワークへのより広くより深い可視性に依存する必要があります。究極の目標は、正当な交通の流れを混乱させることなく、または最小限の人間の介入なしでセキュリティを達成することです。
* Policy and Intent Compliance: Network policies are the rules that constrain the services for network access, provide service differentiation, or enforce specific treatment on the traffic. For example, a service function chain is a policy that requires the selected flows to pass through a set of ordered network functions. Intent, as defined in [NMRG-IBN-CONCEPTS-DEFINITIONS], is a set of operational goals that a network should meet and outcomes that a network is supposed to deliver, defined in a declarative manner without specifying how to achieve or implement them. An intent requires a complex translation and mapping process before being applied on networks. While a policy or intent is enforced, the compliance needs to be verified and monitored continuously by relying on visibility that is provided through network telemetry data. Any violation must be reported immediately - this will alert the network administrator to the policy or intent violation and will potentially result in updates to how the policy or intent is applied in the network to ensure that it remains in force.
* ポリシーと意図のコンプライアンス：ネットワークポリシーは、ネットワークアクセスのサービスを制限したり、サービスの差別化を提供したり、トラフィックの特定の治療を実施するルールです。たとえば、サービス関数チェーンは、選択したフローが一連の順序付けられたネットワーク関数を通過する必要があるポリシーです。 [NMRG-IBN Concepts-Definitions]で定義されている意図は、ネットワークが満たすべき運用目標のセットであり、ネットワークが提供することになっている結果と、それらを達成または実装する方法を指定せずに宣言的な方法で定義します。意図には、ネットワークに適用される前に、複雑な翻訳とマッピングプロセスが必要です。ポリシーまたは意図が強制されますが、ネットワークテレメトリデータを介して提供される可視性に依存することにより、コンプライアンスを検証および監視する必要があります。違反はすぐに報告する必要があります - これにより、ネットワーク管理者にポリシーまたは意図違反を警告し、ネットワークでポリシーまたは意図が適用される方法の更新が可能になるため、潜在的に有効であることが保証されます。
* SLA Compliance: A Service Level Agreement (SLA) is a service contract between a service provider and a client, which includes the metrics for the service measurement and remedy/penalty procedures when the service level misses the agreement. Users need to check if they get the service as promised, and network operators need to evaluate how they can deliver services that meet the SLA based on real-time network telemetry data, including data from network measurements.
* SLAコンプライアンス：サービスレベル契約（SLA）は、サービスプロバイダーとクライアントの間のサービス契約です。これには、サービスレベルが契約を逃した場合のサービス測定と救済/ペナルティ手順のメトリックが含まれます。ユーザーは、約束どおりにサービスを取得するかどうかを確認する必要があり、ネットワークオペレーターは、ネットワーク測定からのデータを含むリアルタイムネットワークテレメトリデータに基づいてSLAを満たすサービスを提供する方法を評価する必要があります。
* Root Cause Analysis: Many network failures can be the effect of a sequence of chained events. Troubleshooting and recovery require quick identification of the root cause of any observable issues. However, the root cause is not always straightforward to identify, especially when the failure is sporadic and the number of event messages, both related and unrelated to the same cause, is overwhelming. While technologies such as machine learning can be used for root cause analysis, it is up to the network to sense and provide the relevant diagnostic data that are either actively fed into or passively retrieved by the root cause analysis applications.
* 根本原因分析：多くのネットワーク障害は、連鎖イベントのシーケンスの効果になる可能性があります。トラブルシューティングと回復には、観察可能な問題の根本原因を迅速に識別する必要があります。ただし、根本的な原因は、特に障害が散発的であり、同じ原因に関連していて無関係のイベントメッセージの数が圧倒的である場合、必ずしも簡単ではありません。機械学習などのテクノロジーは根本原因分析に使用できますが、根本原因分析アプリケーションによって積極的に供給されるか、受動的に取得された関連する診断データを感知して提供するのはネットワーク次第です。
* Network Optimization: This covers all short-term and long-term network optimization techniques, including load balancing, Traffic Engineering (TE), and network planning. Network operators are motivated to optimize their network utilization and differentiate services for better Return on Investment (ROI) or lower Capital Expenditure (CAPEX). The first step is to know the real-time network conditions before applying policies for traffic manipulation. In some cases, microbursts need to be detected in a very short time frame so that fine-grained traffic control can be applied to avoid network congestion. Long-term planning of network capacity and topology requires analysis of real-world network telemetry data that is obtained over long periods of time.
* ネットワークの最適化：これは、負荷分散、交通工学（TE）、ネットワーク計画など、すべての短期および長期ネットワーク最適化手法をカバーしています。ネットワークオペレーターは、ネットワークの使用率を最適化し、サービスをより良い投資収益率（ROI）または低価格支出（CAPEX）のために区別する動機を持っています。最初のステップは、トラフィック操作にポリシーを適用する前に、リアルタイムネットワーク条件を知ることです。場合によっては、ネットワークの輻輳を避けるために、細かい密集した交通制御を適用できるように、非常に短い時間枠でマイクロバーストを検出する必要があります。ネットワーク容量とトポロジの長期計画には、長期間にわたって取得される実際のネットワークテレメトリデータの分析が必要です。
* Event Tracking and Prediction: The visibility into traffic path and performance is critical for services and applications that rely on healthy network operation. Numerous related network events are of interest to network operators. For example, network operators want to learn where and why packets are dropped for an application flow. They also want to be warned of issues in advance, so proactive actions can be taken to avoid catastrophic consequences.
* イベントの追跡と予測：トラフィックパスとパフォーマンスへの可視性は、健康的なネットワーク操作に依存するサービスとアプリケーションにとって重要です。ネットワークオペレーターにとって、多くの関連するネットワークイベントが興味深いものです。たとえば、ネットワークオペレーターは、アプリケーションフローのためにパケットがドロップされる場所と理由を学びたいと考えています。彼らはまた、事前に問題について警告されることを望んでいるので、壊滅的な結果を避けるために積極的な行動をとることができます。
For a long time, network operators have relied upon SNMP [RFC3416], Command-Line Interface (CLI), or Syslog [RFC5424] to monitor the network. Some other OAM techniques as described in [RFC7276] are also used to facilitate network troubleshooting. These conventional techniques are not sufficient to support the above use cases for the following reasons:
長い間、ネットワークオペレーターはSNMP [RFC3416]、コマンドラインインターフェイス（CLI）、またはSyslog [RFC5424]に依存してネットワークを監視してきました。[RFC7276]で説明されている他のいくつかのOAM技術は、ネットワークのトラブルシューティングを促進するためにも使用されます。これらの従来の手法は、以下の理由で上記のユースケースをサポートするのに十分ではありません。
* Most use cases need to continuously monitor the network and dynamically refine the data collection in real time. Poll-based low-frequency data collection is ill-suited for these applications. Subscription-based streaming data directly pushed from the data source (e.g., the forwarding chip) is preferred to provide sufficient data quantity and precision at scale.
* ほとんどのユースケースは、ネットワークを継続的に監視し、データ収集をリアルタイムで動的に改良する必要があります。投票ベースの低周波データ収集は、これらのアプリケーションには不適切です。データソース（たとえば、転送チップなど）から直接プッシュされたサブスクリプションベースのストリーミングデータは、十分なデータの量と精度を大規模に提供するために推奨されます。
* Comprehensive data is needed, ranging from packet processing engines to traffic managers, line cards to main control boards, user flows to control protocol packets, device configurations to operations, and physical layers to application layers. Conventional OAM only covers a narrow range of data (e.g., SNMP only handles data from the Management Information Base (MIB)). Classical network devices cannot provide all the necessary probes. More open and programmable network devices are therefore needed.
* パケット処理エンジンからトラフィックマネージャー、ラインカード、メインコントロールボード、プロトコルパケットを制御するためのユーザーフロー、操作へのデバイス構成、およびアプリケーションレイヤーへの物理レイヤーまで、包括的なデータが必要です。従来のOAMは、狭い範囲のデータのみをカバーしています（たとえば、SNMPは管理情報ベース（MIB）からのデータのみを処理します）。クラシックネットワークデバイスは、必要なすべてのプローブを提供することはできません。したがって、よりオープンでプログラム可能なネットワークデバイスが必要です。
* Many application scenarios need to correlate network-wide data from multiple sources (i.e., from distributed network devices, different components of a network device, or different network planes). A piecemeal solution is often lacking the capability to consolidate the data from multiple sources. The composition of a complete solution, as partly proposed by Autonomic Resource Control Architecture (ARCA) [NMRG-ANTICIPATED-ADAPTATION], will be empowered and guided by a comprehensive framework.
* 多くのアプリケーションシナリオは、複数のソース（つまり、分散ネットワークデバイス、ネットワークデバイスの異なるコンポーネント、または異なるネットワークプレーンからのネットワーク全体のデータを相関させる必要があります。断片的なソリューションには、多くの場合、複数のソースからデータを統合する機能が欠けています。自律的なリソース制御アーキテクチャ（ARCA）[NMRGで予想される適応]によって部分的に提案されている完全なソリューションの構成は、包括的なフレームワークによって力を与えられ、導かれます。
* Some conventional OAM techniques (e.g., CLI and Syslog) lack a formal data model. The unstructured data hinder the tool automation and application extensibility. Standardized data models are essential to support the programmable networks.
* 一部の従来のOAM技術（CLIやSyslogなど）には、正式なデータモデルがありません。構造化されていないデータは、ツールの自動化とアプリケーションの拡張性を妨げます。標準化されたデータモデルは、プログラム可能なネットワークをサポートするために不可欠です。
* Although some conventional OAM techniques support data push (e.g., SNMP Trap [RFC2981][RFC3877], Syslog, and sFlow [RFC3176]), the pushed data are limited to only predefined management plane warnings (e.g., SNMP Trap) or sampled user packets (e.g., sFlow). Network operators require the data with arbitrary source, granularity, and precision, which is beyond the capability of the existing techniques.
* 一部の従来のOAM技術はデータプッシュ（例：SNMPトラップ[RFC2981] [RFC3877]、Syslog、およびSFLOW [RFC3176]）をサポートしていますが、プッシュされたデータは、事前定義された管理プレーン警告（例：SNMPトラップ）またはサンプルされたユーザーパケットのみに限定されます。（例えば、sflow）。ネットワークオペレーターには、既存の手法の能力を超えた任意のソース、粒度、および精度を持つデータが必要です。
* Conventional passive measurement techniques can either consume excessive network resources and produce excessive redundant data or lead to inaccurate results; on the other hand, conventional active measurement techniques can interfere with the user traffic, and their results are indirect. Techniques that can collect direct and on-demand data from user traffic are more favorable.
* 従来のパッシブ測定技術は、過剰なネットワークリソースを消費し、過度の冗長データを生成するか、不正確な結果につながる可能性があります。一方、従来のアクティブ測定技術はユーザートラフィックを妨げる可能性があり、その結果は間接的です。ユーザートラフィックから直接およびオンデマンドデータを収集できる手法がより有利です。
These challenges were addressed by newer standards and techniques (e.g., IPFIX/Netflow, Packet Sampling (PSAMP), IOAM, and YANG-Push), and more are emerging. These standards and techniques need to be recognized and accommodated in a new framework.
これらの課題は、新しい標準とテクニック（例：IPFIX/Netflow、パケットサンプリング（PSAMP）、IOAM、YANG-PUSHなど）で対処されています。これらの標準とテクニックは、新しいフレームワークに認識され対応する必要があります。
Network telemetry has emerged as a mainstream technical term to refer to the network data collection and consumption techniques. Several network telemetry techniques and protocols (e.g., IPFIX [RFC7011] and gRPC [grpc]) have been widely deployed. Network telemetry allows separate entities to acquire data from network devices so that data can be visualized and analyzed to support network monitoring and operation. Network telemetry covers the conventional network OAM and has a wider scope. For instance, it is expected that network telemetry can provide the necessary network insight for autonomous networks and address the shortcomings of conventional OAM techniques.
ネットワークテレメトリは、ネットワークデータの収集と消費技術を指すための主流の技術用語として浮上しています。いくつかのネットワークテレメトリテクニックとプロトコル（例：IPFIX [RFC7011]およびGRPC [GRPC]）が広く展開されています。ネットワークテレメトリを使用すると、個別のエンティティがネットワークデバイスからデータを取得できるため、データを視覚化および分析してネットワークの監視と操作をサポートできるようにします。ネットワークテレメトリは、従来のネットワークOAMをカバーし、より広いスコープを持っています。たとえば、ネットワークテレメトリは、自律ネットワークに必要なネットワーク洞察を提供し、従来のOAM技術の欠点に対処できることが期待されています。
Network telemetry usually assumes machines as data consumers rather than human operators. Hence, network telemetry can directly trigger the automated network operation, while in contrast, some conventional OAM tools were designed and used to help human operators to monitor and diagnose the networks and guide manual network operations. Such a proposition leads to very different techniques.
ネットワークテレメトリーは通常、マシンを人間のオペレーターではなくデータ消費者として想定しています。したがって、ネットワークテレメトリは自動化されたネットワーク操作を直接トリガーできますが、対照的に、いくつかの従来のOAMツールが設計され、人間のオペレーターがネットワークを監視および診断し、マニュアルネットワーク操作をガイドするのに役立ちます。このような命題は、非常に異なるテクニックにつながります。
Although new network telemetry techniques are emerging and subject to continuous evolution, several characteristics of network telemetry have been well accepted. Note that network telemetry is intended to be an umbrella term covering a wide spectrum of techniques, so the following characteristics are not expected to be held by every specific technique.
新しいネットワークテレメトリテクニックが登場し、連続的な進化の影響を受けますが、ネットワークテレメトリのいくつかの特性がよく受け入れられています。ネットワークテレメトリは、幅広い技術をカバーする包括的な用語であることに注意してください。したがって、次の特性はすべての特定の手法によって保持されるとは予想されていません。
* Push and Streaming: Instead of polling data from network devices, telemetry collectors subscribe to streaming data pushed from data sources in network devices.
* プッシュとストリーミング：ネットワークデバイスからデータを投票する代わりに、テレメトリーコレクターは、ネットワークデバイスのデータソースからプッシュされたストリーミングデータを購読します。
* Volume and Velocity: Telemetry data is intended to be consumed by machines rather than by human beings. Therefore, the data volume can be huge, and the processing is optimized for the needs of automation in real time.
* 体積と速度：テレメトリーデータは、人間ではなく機械によって消費されることを目的としています。したがって、データ量は膨大であり、処理はリアルタイムで自動化のニーズに合わせて最適化されます。
* Normalization and Unification: Telemetry aims to address the overall network automation needs. Efforts are made to normalize the data representation and unify the protocols, so as to simplify data analysis and provide integrated analysis across heterogeneous devices and data sources across a network.
* 正規化と統一：Telemetryは、ネットワーク自動化のニーズ全体に対処することを目的としています。データ分析を簡素化し、ネットワーク全体の異種デバイスとデータソースを介した統合分析を提供するために、データ表現を正規化してプロトコルを統合する努力がなされます。
* Model-Based: Telemetry data is modeled in advance, which allows applications to configure and consume data with ease.
* モデルベース：テレメトリデータは事前にモデル化されているため、アプリケーションはデータを簡単に構成して消費できます。
* Data Fusion: The data for a single application can come from multiple data sources (e.g., cross-domain, cross-device, and cross-layer) that are based on a common name/ID and need to be correlated to take effect.
* データ融合：単一のアプリケーションのデータは、共通名/IDに基づいており、有効にするために相関する必要がある複数のデータソース（クロスドメイン、クロスデバイス、クロスレイヤーなど）から得られます。
* Dynamic and Interactive: Since the network telemetry means to be used in a closed control loop for network automation, it needs to run continuously and adapt to the dynamic and interactive queries from the network operation controller.
* ダイナミックとインタラクティブ：ネットワークテレメトリは、ネットワーク自動化のためのクローズドコントロールループで使用することを意味するため、継続的に実行し、ネットワーク操作コントローラーからの動的およびインタラクティブなクエリに適応する必要があります。
In addition, an ideal network telemetry solution may also have the following features or properties:
さらに、理想的なネットワークテレメトリソリューションには、次の機能またはプロパティがある場合があります。
* In-Network Customization: The data that is generated can be customized in network at runtime to cater to the specific need of applications. This needs the support of a programmable data plane, which allows probes with custom functions to be deployed at flexible locations.
* ネットワーク内のカスタマイズ：生成されるデータは、アプリケーションの特定のニーズに応えるために、実行時にネットワークでカスタマイズできます。これには、プログラム可能なデータプレーンのサポートが必要です。これにより、カスタム関数を備えたプローブを柔軟な場所に展開できます。
* In-Network Data Aggregation and Correlation: Network devices and aggregation points can work out which events and what data needs to be stored, reported, or discarded, thus reducing the load on the central collection and processing points while still ensuring that the right information is ready to be processed in a timely way.
* ネットワーク内のデータの集約と相関：ネットワークデバイスと集約ポイントは、どのイベントと保存、報告、または廃棄する必要があるかを解決することができるため、中央の収集ポイントと処理ポイントの負荷が削減され、適切な情報が確実になります。タイムリーに処理する準備ができています。
* In-Network Processing: Sometimes it is not necessary or feasible to gather all information to a central point to be processed and acted upon. It is possible for the data processing to be done in network, allowing reactive actions to be taken locally.
* ネットワーク内処理：すべての情報を、処理および行動するための中央のポイントにすべての情報を収集する必要がない場合もありません。データ処理をネットワークで実行することが可能であるため、リアクティブアクションをローカルで実行できます。
* Direct Data Plane Export: The data originated from data plane forwarding chips can be directly exported to the data consumer for efficiency, especially when the data bandwidth is large and real-time processing is required.
* ダイレクトデータプレーンのエクスポート：データプレーン転送チップから発信されたデータは、特にデータ帯域幅が大きく、リアルタイム処理が必要な場合、効率のためにデータ消費者に直接エクスポートできます。
* In-Band Data Collection: In addition to the passive and active data collection approaches, the new hybrid approach allows to directly collect data for any target flow on its entire forwarding path [OPSAWG-IFIT-FRAMEWORK].
* インバンドデータ収集：パッシブおよびアクティブなデータ収集アプローチに加えて、新しいハイブリッドアプローチにより、転送パス全体のターゲットフローのデータを直接収集できます[Opsawg-ifit-framework]。
It is worth noting that a network telemetry system should not be intrusive to normal network operations by avoiding the pitfall of the "observer effect". That is, it should not change the network behavior and affect the forwarding performance. Moreover, high-volume telemetry traffic may cause network congestion unless proper isolation or traffic engineering techniques are in place, or congestion control mechanisms ensure that telemetry traffic backs off if it exceeds the network capacity. [RFC8084] and [RFC8085] are relevant Best Current Practices (BCPs) in this space.
「オブザーバー効果」の落とし穴を避けて、ネットワークテレメトリシステムは通常のネットワーク操作に邪魔になるべきではないことに注意してください。つまり、ネットワークの動作を変更したり、転送パフォーマンスに影響を与えたりする必要はありません。さらに、適切な分離またはトラフィックエンジニアリング手法が整っていない限り、大量のテレメトリトラフィックがネットワークの混雑を引き起こす可能性があります。または、渋滞制御メカニズムにより、ネットワーク容量を超えた場合、テレメトリトラフィックが後退することが保証されます。[RFC8084]および[RFC8085]は、このスペースで関連する最高の現在のプラクティス（BCP）です。
Although in many cases a system for network telemetry involves a remote data collecting and consuming entity, it is important to understand that there are no inherent assumptions about how a system should be architected. While a network architecture with a centralized controller (e.g., SDN) seems to be a natural fit for network telemetry, network telemetry can work in distributed fashions as well. For example, telemetry data producers and consumers can have a peer-to-peer relationship, in which a network node can be the direct consumer of telemetry data from other nodes.
多くの場合、ネットワークテレメトリのシステムにはリモートデータの収集と消費エンティティが含まれますが、システムをどのようにアーキテッドするべきかについての固有の仮定がないことを理解することが重要です。集中コントローラー（SDNなど）を備えたネットワークアーキテクチャは、ネットワークテレメトリに自然に適合しているようですが、ネットワークテレメトリも分散ファッションでも機能します。たとえば、テレメトリーデータ生産者と消費者はピアツーピア関係を持つことができます。この関係では、ネットワークノードは他のノードからのテレメトリデータの直接的な消費者になります。
Network data analytics (e.g., machine learning) is applied for network operation automation, relying on abundant and coherent data from networks. Data acquisition that is limited to a single source and static in nature will in many cases not be sufficient to meet an application's telemetry data needs. As a result, multiple data sources, involving a variety of techniques and standards, will need to be integrated. It is desirable to have a framework that classifies and organizes different telemetry data sources and types, defines different components of a network telemetry system and their interactions, and helps coordinate and integrate multiple telemetry approaches across layers. This allows flexible combinations of data for different applications, while normalizing and simplifying interfaces. In detail, such a framework would benefit the development of network operation applications for the following reasons:
ネットワークデータ分析（機械学習など）は、ネットワークの豊富でコヒーレントなデータに依存して、ネットワーク操作自動化に適用されます。単一のソースに限定され、本質的に静的なデータ収集は、多くの場合、アプリケーションのテレメトリデータのニーズを満たすのに十分ではありません。その結果、さまざまな手法と標準を含む複数のデータソースを統合する必要があります。さまざまなテレメトリデータソースとタイプを分類および整理し、ネットワークテレメトリシステムとその相互作用のさまざまなコンポーネントを定義し、レイヤー間で複数のテレメトリアプローチを調整および統合するのに役立つフレームワークを持つことが望ましいです。これにより、インターフェイスを正規化および簡素化しながら、さまざまなアプリケーションのデータの柔軟な組み合わせが可能になります。詳細には、このようなフレームワークは、次の理由でネットワーク操作アプリケーションの開発に利益をもたらすでしょう。
* Future networks, autonomous or otherwise, depend on holistic and comprehensive network visibility. Use cases and applications are better when supported uniformly and coherently using an integrated, converged mechanism and common telemetry data representations wherever feasible. Therefore, the protocols and mechanisms should be consolidated into a minimum yet comprehensive set. A telemetry framework can help to normalize the technique developments.
* 自律的またはその他の将来のネットワークは、全体的かつ包括的なネットワークの可視性に依存します。ユースケースとアプリケーションは、統合され、収束したメカニズムと一般的なテレメトリデータ表現を実行可能な場合は、均一かつ一貫したサポートすると、より良いものです。したがって、プロトコルとメカニズムは、最小限でありながら包括的なセットに統合する必要があります。テレメトリフレームワークは、手法の開発を正常化するのに役立ちます。
* Network visibility presents multiple viewpoints. For example, the device viewpoint takes the network infrastructure as the monitoring object from which the network topology and device status can be acquired, and the traffic viewpoint takes the flows or packets as the monitoring object from which the traffic quality and path can be acquired. An application may need to switch its viewpoint during operation. It may also need to correlate a service and its impact on user experience (UE) to acquire the comprehensive information.
* ネットワークの可視性は、複数の視点を示します。たとえば、デバイスの視点は、ネットワークインフラストラクチャをネットワークトポロジとデバイスのステータスを取得できる監視オブジェクトとして使用し、トラフィックビューポイントは、トラフィックの品質とパスを取得できる監視オブジェクトとしてフローまたはパケットを使用します。アプリケーションは、操作中に視点を切り替える必要がある場合があります。また、包括的な情報を取得するために、サービスとユーザーエクスペリエンスへの影響（UE）への影響を相関させる必要がある場合があります。
* Applications require network telemetry to be elastic in order to make efficient use of network resources and reduce the impact of processing related to network telemetry on network performance. For example, routine network monitoring should cover the entire network with a low data sampling rate. Only when issues arise or critical trends emerge should telemetry data sources be modified and telemetry data rates be boosted as needed.
* アプリケーションでは、ネットワークリソースを効率的に使用し、ネットワークテレメトリに関連する処理の影響をネットワークパフォーマンスに与える影響を減らすために、ネットワークテレメトリを弾力性にする必要があります。たとえば、ルーチンネットワーク監視は、ネットワーク全体を低データサンプリングレートでカバーする必要があります。問題が発生した場合のみ、テレメトリデータソースを変更し、必要に応じてテレメトリデータレートを引き上げる必要がある場合にのみ。
* Efficient data aggregation is critical for applications to reduce the overall quantity of data and improve the accuracy of analysis.
* 効率的なデータ集約は、アプリケーションがデータ全体の量を減らし、分析の精度を向上させるために重要です。
A telemetry framework collects all the telemetry-related works from different sources and working groups within the IETF. This makes it possible to assemble a comprehensive network telemetry system and to avoid repetitious or redundant work. The framework should cover the concepts and components from the standardization perspective. This document describes the modules that make up a network telemetry framework and decomposes the telemetry system into a set of distinct components that existing and future work can easily map to.
Telemetryフレームワークは、IETF内のさまざまなソースとワーキンググループからテレメトリ関連のすべての作業を収集します。これにより、包括的なネットワークテレメトリシステムを組み立て、繰り返しまたは冗長な作業を避けることができます。フレームワークは、標準化の観点から概念とコンポーネントをカバーする必要があります。このドキュメントでは、ネットワークテレメトリフレームワークを構成するモジュールについて説明し、テレメトリシステムを既存および将来の作業が簡単にマッピングできる個別のコンポーネントのセットに分解します。
The top-level network telemetry framework partitions the network telemetry into four modules based on the telemetry data object source and represents their relationship. Once the network operation applications acquire the data from these modules, they can apply data analytics and take actions. At the next level, the framework decomposes each module into separate components. Each of these modules follows the same underlying structure, with one component dedicated to the configuration of data subscriptions and data sources, a second component dedicated to encoding and exporting data, and a third component instrumenting the generation of telemetry related to the underlying resources. Throughout the framework, the same set of abstract data-acquiring mechanisms and data types (Section 3.3) are applied. The two-level architecture with the uniform data abstraction helps accurately pinpoint a protocol or technique to its position in a network telemetry system or disaggregates a network telemetry system into manageable parts.
トップレベルのネットワークテレメトリフレームワークは、ネットワークテレメトリをテレメトリデータオブジェクトソースに基づいて4つのモジュールに分割し、その関係を表します。ネットワーク操作アプリケーションがこれらのモジュールからデータを取得すると、データ分析を適用してアクションを実行できます。次のレベルでは、フレームワークは各モジュールを別々のコンポーネントに分解します。これらの各モジュールは、データサブスクリプションとデータソースの構成、データのエンコードとエクスポート専用の2番目のコンポーネント、および基礎となるリソースに関連するテレメトリーの生成を計装する3番目のコンポーネントに特化した同じ基礎構造に従います。フレームワーク全体を通して、同じ抽象的なデータを取得するメカニズムとデータ型（セクション3.3）のセットが適用されます。均一なデータ抽象化を備えた2レベルのアーキテクチャは、ネットワークテレメトリシステムでのプロトコルまたはテクニックを正確に特定するのに役立ちます。
Telemetry can be applied on the forwarding plane, control plane, and management plane in a network, as well as on other sources out of the network, as shown in Figure 1. Therefore, we categorize the network telemetry into four distinct modules (management plane, control plane, forwarding plane, and external data and event telemetry) with each having its own interface to network operation applications.
図1に示すように、ネットワーク内の他のソースだけでなく、ネットワーク内の転送面、コントロールプレーン、および管理プレーンにテレメトリを適用できます。したがって、ネットワークテレメトリを4つの異なるモジュール（管理プレーンに分類します。、コントロールプレーン、転送プレーン、および外部データおよびイベントテレメトリ）は、それぞれがネットワーク操作アプリケーションへの独自のインターフェースを持っています。
+------------------------------+
| |
| Network Operation |<-------+
| Applications | |
| | |
+------------------------------+ |
^ ^ ^ |
| | | |
V V | V
+--------------+-----------|---+ +-----------+
| | Control | | | |
| | Plane | | | External |
| <---> | | | Data and |
| | Telemetry | | | Event |
| Management | ^ V | | Telemetry |
| Plane +-------|-------+ | |
| Telemetry | V | +-----------+
| | Forwarding |
| | Plane |
| <---> |
| | Telemetry |
| | |
+--------------+---------------+
Figure 1: Modules in Layer Category of the Network Telemetry Framework
図1：ネットワークテレメトリーフレームワークのレイヤーカテゴリのモジュール
The rationale of this partition lies in the different telemetry data objects that result in different data sources and export locations. Such differences have profound implications on in-network data programming and processing capability, data encoding and the transport protocol, and required data bandwidth and latency. Data can be sent directly or proxied via the control and management planes. There are advantages/disadvantages to both approaches.
このパーティションの理論的根拠は、さまざまなデータソースとエクスポート場所をもたらすさまざまなテレメトリデータオブジェクトにあります。このような違いは、ネットワーク内のデータプログラミングと処理能力、データエンコードと輸送プロトコル、および必要なデータの帯域幅とレイテンシに大きな影響を与えます。データは直接送信したり、制御および管理機を介してプロキシを送信したりできます。両方のアプローチには利点/短所があります。
Note that in some cases, the network controller itself may be the source of telemetry data that is unique to it or derived from the telemetry data collected from the network elements. Some of the principles and taxonomy specific to the control plane and management plane telemetry could also be applied to the controller when it is required to provide the telemetry data to network operation applications hosted outside. The scope of this document is focused on the network elements telemetry, and further details related to controllers are thus out of scope.
場合によっては、ネットワークコントローラー自体が、ネットワーク要素から収集されたテレメトリデータから派生したテレメトリーデータのソースである可能性があることに注意してください。コントロールプレーンおよび管理プレーンのテレメトリに固有の原則と分類法の一部は、外部でホストされているネットワーク操作アプリケーションにテレメトリデータを提供するために必要な場合に、コントローラーに適用できます。このドキュメントの範囲は、ネットワーク要素のテレメトリに焦点を当てており、コントローラーに関連する詳細は範囲外です。
We summarize the major differences of the four modules in Table 1. They are compared from six angles:
表1の4つのモジュールの大きな違いを要約します。これらは、6つの角度から比較されます。
* Data Object
* データオブジェクト
* Data Export Location
* データエクスポートの場所
* Data Model
* データ・モデル
* Data Encoding
* データエンコーディング
* Telemetry Application Protocol
* テレメトリーアプリケーションプロトコル
* Data Transport Method
* データ輸送方法
Data Object is the target and source of each module. Because the data source varies, the location where data is mostly conveniently exported also varies. For example, forwarding plane data mainly originates as data exported from the forwarding Application-Specific Integrated Circuits (ASICs), while control plane data mainly originates from the protocol daemons running on the control CPU(s). For convenience and efficiency, it is preferred to export the data off the device from locations near the source. Because the locations that can export data have different capabilities, different choices of data models, encoding, and transport methods are made to balance the performance and cost. For example, the forwarding chip has high throughput but limited capacity for processing complex data and maintaining state, while the main control CPU is capable of complex data and state processing but has limited bandwidth for high throughput data. As a result, the suitable telemetry protocol for each module can be different. Some representative techniques are shown in the corresponding table blocks to highlight the technical diversity of these modules. Note that the selected techniques just reflect the de facto state of the art and are by no means exhaustive (e.g., IPFIX can also be implemented over TCP and SCTP, but that is not recommended for the forwarding plane). The key point is that one cannot expect to use a universal protocol to cover all the network telemetry requirements.
データオブジェクトは、各モジュールのターゲットとソースです。データソースは異なるため、データがほとんど便利にエクスポートされる場所も異なります。たとえば、転送面データは、主に転送アプリケーション固有の統合回路（ASIC）からエクスポートされるデータとして発生しますが、コントロールプレーンデータは、主にコントロールCPUで実行されるプロトコルデーモンに由来します。便利さと効率のために、ソースの近くの場所からデバイスからデータをエクスポートすることが推奨されます。データをエクスポートできる場所には異なる機能があるため、データモデル、エンコード、およびトランスポート方法の選択が異なるため、パフォーマンスとコストのバランスを取ることができます。たとえば、転送チップは高いスループットですが、複雑なデータを処理して状態を維持するための容量が限られていますが、メインコントロールCPUは複雑なデータと状態処理が可能ですが、高いスループットデータの帯域幅は限られています。その結果、各モジュールに適したテレメトリプロトコルが異なる場合があります。これらのモジュールの技術的多様性を強調するために、対応するテーブルブロックにいくつかの代表的な手法が示されています。選択された手法は、事実上の最先端を反映しており、決して網羅的ではないことに注意してください（たとえば、IPFIXもTCPとSCTPを介して実装できますが、転送面には推奨されません）。重要なポイントは、すべてのネットワークテレメトリ要件をカバーするためにユニバーサルプロトコルを使用することを期待できないということです。
+=============+===============+==========+==========+===============+
|Module |Management |Control |Forwarding|External Data |
| |Plane |Plane |Plane | |
+=============+===============+==========+==========+===============+
|Object |configuration |control |flow and |terminal, |
| |and operation |protocol |packet |social, and |
| |state |and |QoS, |environmental |
| | |signaling,|traffic | |
| | |RIB |stat., | |
| | | |buffer and| |
| | | |queue | |
| | | |stat., | |
| | | |FIB, | |
| | | |Access | |
| | | |Control | |
| | | |List (ACL)| |
+-------------+---------------+----------+----------+---------------+
|Export |main control |main |forwarding|various |
|Location |CPU |control |chip or | |
| | |CPU, |linecard | |
| | |linecard |CPU; main | |
| | |CPU, or |control | |
| | |forwarding|CPU | |
| | |chip |unlikely | |
+-------------+---------------+----------+----------+---------------+
|Data Model |YANG, MIB, |YANG, |YANG, |YANG, custom |
| |syslog |custom |custom | |
+-------------+---------------+----------+----------+---------------+
|Data Encoding|GPB, JSON, XML |GPB, JSON,|plain text|GPB, JSON, XML,|
| | |XML, plain| |plain text |
| | |text | | |
+-------------+---------------+----------+----------+---------------+
|Application |gRPC, NETCONF, |gRPC, |IPFIX, |gRPC |
|Protocol |RESTCONF |NETCONF, |traffic | |
| | |IPFIX, |mirroring,| |
| | |traffic |gRPC, | |
| | |mirroring |NETFLOW | |
+-------------+---------------+----------+----------+---------------+
|Data |HTTP(S), TCP |HTTP(S), |UDP |HTTP(S), TCP, |
|Transport | |TCP, UDP | |UDP |
+-------------+---------------+----------+----------+---------------+
Table 1: Comparison of Data Object Modules
表1：データオブジェクトモジュールの比較
Note that the interaction with the applications that consume network telemetry data can be indirect. Some in-device data transfer is possible. For example, in the management plane telemetry, the management plane will need to acquire data from the data plane. Some operational states can only be derived from data plane data sources such as the interface status and statistics. As another example, obtaining control plane telemetry data may require the ability to access the Forwarding Information Base (FIB) of the data plane.
ネットワークテレメトリデータを消費するアプリケーションとの相互作用は間接的である可能性があることに注意してください。一部のデバイス内データ転送が可能です。たとえば、管理プレーンテレメトリでは、管理プレーンはデータプレーンからデータを取得する必要があります。一部の運用状態は、インターフェイスステータスや統計などのデータプレーンデータソースからのみ導出できます。別の例として、コントロールプレーンのテレメトリデータを取得するには、データプレーンの転送情報ベース（FIB）にアクセスする機能が必要になる場合があります。
On the other hand, an application may involve more than one plane and interact with multiple planes simultaneously. For example, an SLA compliance application may require both the data plane telemetry and the control plane telemetry.
一方、アプリケーションには複数の平面が含まれ、複数の平面と同時に相互作用する場合があります。たとえば、SLAコンプライアンスアプリケーションには、データプレーンテレメトリとコントロールプレーンテレメトリの両方が必要になる場合があります。
The requirements and challenges for each module are summarized as follows (note that the requirements may pertain across all telemetry modules; however, we emphasize those that are most pronounced for a particular plane).
各モジュールの要件と課題は次のように要約されています（要件はすべてのテレメトリモジュールに関係する可能性があることに注意してください。ただし、特定の平面で最も顕著なものを強調しています）。
The management plane of network elements interacts with the Network Management System (NMS) and provides information such as performance data, network logging data, network warning and defects data, and network statistics and state data. The management plane includes many protocols, including the classical SNMP and syslog. Regardless the protocol, management plane telemetry must address the following requirements:
ネットワーク要素の管理プレーンは、ネットワーク管理システム（NMS）と対話し、パフォーマンスデータ、ネットワークロギングデータ、ネットワーク警告および欠陥データ、ネットワーク統計と状態データなどの情報を提供します。管理プレーンには、古典的なSNMPやSyslogを含む多くのプロトコルが含まれています。プロトコルに関係なく、管理プレーンのテレメトリは次の要件に対処する必要があります。
* Convenient Data Subscription: An application should have the freedom to choose which data is exported (see Section 3.3) and the means and frequency of how that data is exported (e.g., on-change or periodic subscription).
* 便利なデータサブスクリプション：アプリケーションには、どのデータがエクスポートされるか（セクション3.3を参照）と、そのデータのエクスポート方法の平均と頻度（例：変更または定期的なサブスクリプションなど）を選択できる必要があります。
* Structured Data: For automatic network operation, machines will replace humans for network data comprehension. Data modeling languages, such as YANG, can efficiently describe structured data and normalize data encoding and transformation.
* 構造化データ：自動ネットワーク操作のために、マシンはネットワークデータの理解のために人間を置き換えます。Yangなどのデータモデリング言語は、構造化されたデータを効率的に説明し、データのエンコードと変換を正規化できます。
* High-Speed Data Transport: In order to keep up with the velocity of information, a data source needs to be able to send large amounts of data at high frequency. Compact encoding formats or data compression schemes are needed to reduce the quantity of data and improve the data transport efficiency. The subscription mode, by replacing the query mode, reduces the interactions between clients and servers and helps to improve the data source's efficiency.
* 高速データ輸送：情報の速度に追いつくために、データソースは高頻度で大量のデータを送信できる必要があります。データの量を減らし、データ輸送効率を改善するには、コンパクトなエンコード形式またはデータ圧縮スキームが必要です。クエリモードを交換することにより、サブスクリプションモードは、クライアントとサーバー間の相互作用を減らし、データソースの効率を改善するのに役立ちます。
* Network Congestion Avoidance: The application must protect the network from congestion with congestion control mechanisms or, at minimum, with circuit breakers. [RFC8084] and [RFC8085] provide some solutions in this space.
* ネットワークの輻輳回避：アプリケーションは、輻輳制御メカニズム、または少なくとも回路ブレーカーを使用した混雑からネットワークを保護する必要があります。[RFC8084]および[RFC8085]は、このスペースにいくつかのソリューションを提供します。
The control plane telemetry refers to the health condition monitoring of different network control protocols at all layers of the protocol stack. Keeping track of the operational status of these protocols is beneficial for detecting, localizing, and even predicting various network issues, as well as for network optimization, in real time and with fine granularity. Some particular challenges and issues faced by the control plane telemetry are as follows:
コントロールプレーンテレメトリは、プロトコルスタックのすべてのレイヤーでのさまざまなネットワーク制御プロトコルの健康状態監視を指します。これらのプロトコルの運用状況を追跡することは、さまざまなネットワークの問題、ネットワークの最適化、リアルタイム、細かい粒度を検出、ローカライズ、さらには予測するのに有益です。コントロールプレーンのテレメトリが直面するいくつかの特定の課題と問題は次のとおりです。
* How to correlate the End-to-End (E2E) Key Performance Indicators (KPIs) to a specific layer's KPIs. For example, IPTV users may describe their UE by the video smoothness and definition. Then in case of an unusually poor UE KPI or a service disconnection, it is non-trivial to delimit and pinpoint the issue in the responsible protocol layer (e.g., the transport layer or the network layer), the responsible protocol (e.g., IS-IS or BGP at the network layer), and finally the responsible device(s) with specific reasons.
* エンドツーエンド（E2E）キーパフォーマンスインジケーター（KPI）を特定のレイヤーのKPIに相関させる方法。たとえば、IPTVユーザーは、ビデオの滑らかさと定義によってUEを説明することができます。次に、異常に不十分なUE KPIまたはサービスの切断の場合、責任あるプロトコル層（たとえば、輸送層またはネットワーク層など）の問題を区切って特定することは重要ではありません。ネットワークレイヤーのISまたはBGP）、そして最後に、特定の理由を持つ責任デバイス。
* Conventional OAM-based approaches for control plane KPI measurement, which include Ping (L3), Traceroute (L3), Y.1731 [y1731] (L2), and so on. One common issue behind these methods is that they only measure the KPIs instead of reflecting the actual running status of these protocols, making them less effective or efficient for control plane troubleshooting and network optimization.
* Ping（L3）、Traceroute（L3）、Y.1731 [Y1731]（L2）などを含むコントロールプレーンKPI測定のための従来のOAMベースのアプローチ。これらの方法の背後にある一般的な問題の1つは、これらのプロトコルの実際の実行ステータスを反映するのではなく、KPIを測定するだけで、制御プレーンのトラブルシューティングとネットワークの最適化に効果が低下または効率的であることです。
* How more research is needed for the BGP monitoring protocol (BMP). BMP is an example of the control plane telemetry; it is currently used for monitoring BGP routes and enables rich applications, such as BGP peer analysis, Autonomous System (AS) analysis, prefix analysis, and security analysis. However, the monitoring of other layers, protocols, and the cross-layer, cross-protocol KPI correlations are still in their infancy (e.g., IGP monitoring is not as extensive as BMP), which requires further research.
* BGPモニタリングプロトコル（BMP）には、より多くの研究が必要な方法。BMPは、コントロールプレーンテレメトリの例です。現在、BGPルートの監視に使用されており、BGPピア分析、自律システム（AS）分析、プレフィックス分析、セキュリティ分析などの豊富なアプリケーションを有効にしています。ただし、他の層、プロトコル、およびクロスレイヤー、クロスプロトコールKPI相関の監視はまだ初期段階にあります（たとえば、IGPモニタリングはBMPほど広範囲ではありません）。
Note that the requirement and solutions for network congestion avoidance are also applicable to the control plane telemetry.
ネットワーク輻輳回避の要件とソリューションは、コントロールプレーンのテレメトリにも適用できることに注意してください。
An effective forwarding plane telemetry system relies on the data that the network device can expose. The quality, quantity, and timeliness of data must meet some stringent requirements. This raises some challenges for the network data plane devices where the first-hand data originates.
効果的な転送面のテレメトリシステムは、ネットワークデバイスが公開できるデータに依存しています。データの品質、量、および適時性は、いくつかの厳しい要件を満たす必要があります。これにより、直接のデータが発生するネットワークデータプレーンデバイスにいくつかの課題が生じます。
* A data plane device's main function is user traffic processing and forwarding. While supporting network visibility is important, the telemetry is just an auxiliary function, and it should strive to not impede normal traffic processing and forwarding (i.e., the forwarding behavior should not be altered, and the trade-off between forwarding performance and telemetry should be well-balanced).
* データプレーンデバイスの主な機能は、ユーザートラフィックの処理と転送です。ネットワークの可視性をサポートすることは重要ですが、テレメトリは単なる補助関数であり、通常のトラフィック処理と転送を妨げないように努力する必要があります（つまり、転送挙動を変更するべきではなく、転送パフォーマンスとテレメトリ間のトレードオフはバランスが取れています）。
* Network operation applications require end-to-end visibility across various sources, which can result in a huge volume of data. However, the sheer quantity of data must not exhaust the network bandwidth, regardless of the data delivery approach (i.e., whether through in-band or out-of-band channels).
* ネットワーク操作アプリケーションでは、さまざまなソースでエンドツーエンドの可視性が必要であるため、膨大な量のデータが生じる可能性があります。ただし、データ配信アプローチ（つまり、インバンドまたはバンド外チャネルを介して）に関係なく、データの膨大な量をネットワーク帯域幅を使い果たしてはなりません。
* The data plane devices must provide timely data with the minimum possible delay. Long processing, transport, storage, and analysis delay can impact the effectiveness of the control loop and even render the data useless.
* データプレーンデバイスは、最小限の遅延を備えたタイムリーなデータを提供する必要があります。長い処理、輸送、ストレージ、および分析遅延は、制御ループの有効性に影響を与える可能性があり、データを役に立たないことさえあります。
* The data should be structured, labeled, and easy for applications to parse and consume. At the same time, the data types needed by applications can vary significantly. The data plane devices need to provide enough flexibility and programmability to support the precise data provision for applications.
* データは、構造化、ラベル付けされ、アプリケーションが解析および消費するために簡単にする必要があります。同時に、アプリケーションで必要なデータ型は大幅に異なる場合があります。データプレーンデバイスは、アプリケーションの正確なデータ提供をサポートするために、十分な柔軟性とプログラマ性を提供する必要があります。
* The data plane telemetry should support incremental deployment and work even though some devices are unaware of the system.
* 一部のデバイスがシステムを認識していない場合でも、データプレーンテレメトリは、インクリメンタルな展開と動作をサポートする必要があります。
* The requirement and solutions for network congestion avoidance are also applicable to the forwarding plane telemetry.
* ネットワーク輻輳回避の要件とソリューションは、転送面のテレメトリにも適用されます。
Although not specific to the forwarding plane, these challenges are more difficult for the forwarding plane because of the limited resources and flexibility. Data plane programmability is essential to support network telemetry. Newer data plane forwarding chips are equipped with advanced telemetry features and provide flexibility to support customized telemetry functions.
転送面に固有のものではありませんが、これらの課題は、リソースと柔軟性が限られているため、転送面ではより困難です。データプレーンのプログラマ性は、ネットワークテレメトリをサポートするために不可欠です。新しいデータプレーン転送チップには、高度なテレメトリ機能が装備されており、カスタマイズされたテレメトリ関数をサポートする柔軟性を提供します。
Technique Taxonomy: This pertains to how one instruments the telemetry; there can be multiple possible dimensions to classify the forwarding plane telemetry techniques.
テクニック分類法：これは、1つの機器がテレメトリをどのように器具にするかに関係しています。転送面のテレメトリ技術を分類するための複数の可能な寸法があります。
* Active, Passive, and Hybrid: This dimension pertains to the end-to-end measurement. Active and passive methods (as well as the hybrid types) are well documented in [RFC7799]. Passive methods include TCPDUMP, IPFIX [RFC7011], sFlow, and traffic mirroring. These methods usually have low data coverage. The bandwidth cost is very high in order to improve the data coverage. On the other hand, active methods include Ping, the One-Way Active Measurement Protocol (OWAMP) [RFC4656], the Two-Way Active Measurement Protocol (TWAMP) [RFC5357], the Simple Two-way Active Measurement Protocol (STAMP) [RFC8762], and Cisco's SLA Protocol [RFC6812]. These methods are intrusive and only provide indirect network measurements. Hybrid methods, including IOAM [RFC9197], Alternate Marking (AM) [RFC8321], and Multipoint Alternate Marking [RFC8889], provide a well-balanced and more flexible approach. However, these methods are also more complex to implement.
* アクティブ、パッシブ、およびハイブリッド：この次元は、エンドツーエンドの測定に関係しています。アクティブおよびパッシブな方法（およびハイブリッドタイプ）は、[RFC7799]で十分に文書化されています。受動的な方法には、TCPDUMP、IPFIX [RFC7011]、SFLOW、およびトラフィックミラーリングが含まれます。これらのメソッドは通常、データカバレッジが低いです。データカバレッジを改善するために、帯域幅コストは非常に高くなっています。一方、アクティブな方法には、PING、一元配置活性測定プロトコル（OWAMP）[RFC4656]、双方向活性測定プロトコル（TWAMP）[RFC5357]、単純な双方向活性測定プロトコル（スタンプ）[RFC5357] [RFC5357] [RFC5357] [RFC5357] [RFC5357] [RFC5357] [RFC5357] [RFC5357] [RFC5357] [RFC5357] [RFC5357] [RFC5357] [STAMP）が含まれます。RFC8762]、およびシスコのSLAプロトコル[RFC6812]。これらの方法は邪魔になり、間接的なネットワーク測定のみを提供します。IOAM [RFC9197]、代替マーキング（AM）[RFC8321]、およびマルチポイントの代替マーキング[RFC8889]を含むハイブリッド方法は、バランスのとれた、より柔軟なアプローチを提供します。ただし、これらの方法は、実装する方が複雑です。
* In-Band and Out-of-Band: Telemetry data carried in user packets before being exported to a data collector is considered in-band (e.g., IOAM [RFC9197]). Telemetry data that is directly exported to a data collector without modifying user packets is considered out-of-band (e.g., the postcard-based approach described in Appendix A.3.5). It is also possible to have hybrid methods, where only the telemetry instruction or partial data is carried by user packets (e.g., AM [RFC8321]).
* インバンドおよびバンド外：データコレクターにエクスポートされる前にユーザーパケットに携帯されるテレメトリーデータは、帯域内（例：IOAM [RFC9197]）と見なされます。ユーザーパケットを変更せずにデータコレクターに直接エクスポートされるテレメトリーデータは、帯域外（例えば、付録A.3.5で説明したはがきベースのアプローチ）と見なされます。また、テレメトリ命令または部分データのみがユーザーパケットによって運ばれるハイブリッドメソッドを使用することも可能です（例：AM [RFC8321]）。
* End-to-End and In-Network: End-to-end methods start from, and end at, the network end hosts (e.g., Ping). In-network methods work in networks and are transparent to end hosts. However, if needed, in-network methods can be easily extended into end hosts.
* エンドツーエンドおよびネットワーク：エンドツーエンドのメソッドは、ネットワークエンドホスト（Pingなど）から始まり、エンドで終了します。ネットワーク内のメソッドはネットワークで機能し、エンドホストに対して透明です。ただし、必要に応じて、ネットワーク内のメソッドをエンドホストに簡単に拡張できます。
* Data Subject: Depending on the telemetry objective, the methods can be flow based (e.g., IOAM [RFC9197]), path based (e.g., Traceroute), and node based (e.g., IPFIX [RFC7011]). The various data objects can be packet, flow record, measurement, states, and signal.
* データ主題：テレメトリの目的に応じて、メソッドはフローベースにすることができます（例：IOAM [RFC9197]）、パスベース（例：Traceroute）、およびノードベース（例：IPFIX [RFC7011]）。さまざまなデータオブジェクトは、パケット、フローレコード、測定、状態、および信号です。
Events that occur outside the boundaries of the network system are another important source of network telemetry. Correlating both internal telemetry data and external events with the requirements of network systems, as presented in [NMRG-ANTICIPATED-ADAPTATION], provides a strategic and functional advantage to management operations.
ネットワークシステムの境界外で発生するイベントは、ネットワークテレメトリのもう1つの重要なソースです。[nmrgで予想される適応]で提示されているように、内部テレメトリデータと外部イベントの両方をネットワークシステムの要件と相関させると、管理操作に戦略的および機能的な利点が提供されます。
As with other sources of telemetry information, the data and events must meet strict requirements, especially in terms of timeliness, which is essential to properly incorporate external event information into network management applications. The specific challenges are described as follows:
テレメトリー情報の他のソースと同様に、データとイベントは、特に適時性の観点から、外部イベント情報をネットワーク管理アプリケーションに適切に組み込むために不可欠な厳しい要件を満たす必要があります。特定の課題は次のように説明されています。
* The role of the external event detector can be played by multiple elements, including hardware (e.g., physical sensors, such as seismometers) and software (e.g., big data sources that can analyze streams of information, such as Twitter messages). Thus, the transmitted data must support different shapes but, at the same time, follow a common but extensible schema.
* 外部イベント検出器の役割は、ハードウェア（たとえば、地震計などの物理センサー）やソフトウェア（たとえば、Twitterメッセージなどの情報のストリームを分析できるビッグデータソースなど）を含む複数の要素によって再生できます。したがって、送信されたデータはさまざまな形状をサポートする必要がありますが、同時に、一般的ではあるが拡張可能なスキーマに従います。
* Since the main function of the external event detectors is to perform the notifications, their timeliness is assumed. However, once messages have been dispatched, they must be quickly collected and inserted into the control plane with variable priority, which is higher for important sources and events and lower for secondary ones.
* 外部イベント検出器の主な機能は通知を実行することであるため、その適時性が想定されます。ただし、メッセージが発送されたら、それらをすばやく収集して、さまざまな優先順位を持つコントロールプレーンに挿入する必要があります。これは、重要なソースとイベントの場合は高く、二次的なソースでは低くなります。
* The schema used by external detectors must be easily adopted by current and future devices and applications. Therefore, it must be easily mapped to current data models, such as in terms of YANG.
* 外部検出器が使用するスキーマは、現在および将来のデバイスとアプリケーションで簡単に採用する必要があります。したがって、Yangという点では、現在のデータモデルに簡単にマッピングする必要があります。
* As the communication with external entities outside the boundary of a provider network may be realized over the Internet, the risk of congestion is even more relevant in this context and proper countermeasures must be taken. Solutions such as network transport circuit breakers are needed as well.
* プロバイダーネットワークの境界外の外部エンティティとのコミュニケーションがインターネットを介して実現される可能性があるため、このコンテキストでは混雑のリスクがさらに関連し、適切な対策を講じなければなりません。ネットワーク輸送回路ブレーカーなどのソリューションも必要です。
Organizing both internal and external telemetry information together will be key for the general exploitation of the management possibilities of current and future network systems, as reflected in the incorporation of cognitive capabilities to new hardware and software (virtual) elements.
内部と外部のテレメトリ情報の両方を整理することは、新しいハードウェアおよびソフトウェア（仮想）要素への認知機能の組み込みに反映されているように、現在および将来のネットワークシステムの管理可能性を一般的に活用するための鍵となります。
The telemetry module at each plane can be further partitioned into five distinct conceptual components:
各平面のテレメトリモジュールは、さらに5つの異なる概念コンポーネントに分割できます。
* Data Query, Analysis, and Storage: This component works at the network operation application block in Figure 1. It is normally a part of the network management system at the receiver side. On one hand, it is responsible for issuing data requirements. The data of interest can be modeled data through configuration or custom data through programming. The data requirements can be queries for one-shot data or subscriptions for events or streaming data. On the other hand, it receives, stores, and processes the returned data from network devices. Data analysis can be interactive to initiate further data queries. This component can reside in either network devices or remote controllers. It can be centralized and distributed and involve one or more instances.
* データクエリ、分析、およびストレージ：このコンポーネントは、図1のネットワーク操作アプリケーションブロックで機能します。通常、レシーバー側のネットワーク管理システムの一部です。一方では、データ要件を発行する責任があります。関心のあるデータは、構成を介してデータをモデル化したり、プログラミングを通じてカスタムデータをモデル化できます。データ要件は、ワンショットデータのクエリまたはイベントまたはストリーミングデータのサブスクリプションにすることができます。一方、ネットワークデバイスから返されたデータを受信、保存、処理します。データ分析は、さらなるデータクエリを開始するためにインタラクティブにすることができます。このコンポーネントは、ネットワークデバイスまたはリモートコントローラーのいずれかに存在できます。集中および配布し、1つ以上のインスタンスを含むことができます。
* Data Configuration and Subscription: This component manages data queries on devices. It determines the protocol and channel for applications to acquire desired data. This component is also responsible for configuring the desired data that might not be directly available from data sources. The subscription data can be described by models, templates, or programs.
* データ構成とサブスクリプション：このコンポーネントは、デバイスのデータクエリを管理します。アプリケーションのプロトコルとチャネルを決定して、目的のデータを取得します。このコンポーネントは、データソースから直接利用できない可能性のある目的のデータを構成する責任もあります。サブスクリプションデータは、モデル、テンプレート、またはプログラムで説明できます。
* Data Encoding and Export: This component determines how telemetry data is delivered to the data analysis and storage component with access control. The data encoding and the transport protocol may vary due to the data export location.
* データエンコーディングとエクスポート：このコンポーネントは、テレメトリデータがアクセス制御を備えたデータ分析とストレージコンポーネントに配信される方法を決定します。データエクスポートの場所により、データエンコーディングと輸送プロトコルは異なる場合があります。
* Data Generation and Processing: The requested data needs to be captured, filtered, processed, and formatted in network devices from raw data sources. This may involve in-network computing and processing on either the fast path or the slow path in network devices.
* データ生成と処理：要求されたデータを、生データソースからネットワークデバイスでキャプチャ、フィルタリング、処理、およびフォーマットする必要があります。これには、ネットワークデバイスの高速パスまたはスローパスのいずれかでネットワーク内のコンピューティングと処理が含まれる場合があります。
* Data Object and Source: This component determines the monitoring objects and original data sources provisioned in the device. A data source usually just provides raw data that needs further processing. Each data source can be considered a probe. Some data sources can be dynamically installed, while others will be more static.
* データオブジェクトとソース：このコンポーネントは、デバイスにプロビジョニングされた監視オブジェクトと元のデータソースを決定します。通常、データソースは、さらに処理する必要がある生データを提供するだけです。各データソースはプローブと見なすことができます。一部のデータソースは動的にインストールできますが、他のデータソースはより静的になります。
+----------------------------------------+
+----------------------------------------+ |
| | |
| Data Query, Analysis, & Storage | |
| | +
+-------+++ -----------------------------+
||| ^^^
||| |||
||V |||
+--+V--------------------+++------------+
+-----V---------------------+------------+ |
+---------------------+-------+----------+ | |
| Data Configuration | | | |
| & Subscription | Data Encoding | | |
| (model, template, | & Export | | |
| & program) | | | |
+---------------------+------------------| | |
| | | |
| Data Generation | | |
| & Processing | | |
| | | |
+----------------------------------------| | |
| | | |
| Data Object and Source | |-+
| |-+
+----------------------------------------+
Figure 2: Components in the Network Telemetry Framework
図2：ネットワークテレメトリーフレームワークのコンポーネント
Broadly speaking, network data can be acquired through subscription (push) and query (poll). A subscription is a contract between publisher and subscriber. After initial setup, the subscribed data is automatically delivered to registered subscribers until the subscription expires. There are two variations of subscription. The subscriptions can be predefined, or the subscribers are allowed to configure and tailor the published data to their specific needs.
大まかに言えば、ネットワークデータは、サブスクリプション（プッシュ）とクエリ（投票）を介して取得できます。サブスクリプションは、出版社とサブスクライバーの間の契約です。最初のセットアップ後、購読されたデータは、サブスクリプションの有効期限が切れるまで登録済みサブスクライバーに自動的に配信されます。サブスクリプションには2つのバリエーションがあります。サブスクリプションは事前に定義されるか、サブスクライバーが公開されたデータを特定のニーズに合わせて構成および調整することを許可されます。
In contrast, queries are used when a client expects immediate and one-off feedback from network devices. The queried data may be directly extracted from some specific data source or synthesized and processed from raw data. Queries work well for interactive network telemetry applications.
対照的に、クライアントがネットワークデバイスから即時および1回限りのフィードバックを期待する場合、クエリは使用されます。クエリデータは、特定のデータソースから直接抽出されるか、生データから合成および処理される場合があります。クエリは、インタラクティブなネットワークテレメトリアプリケーションに適しています。
In general, data can be pulled (i.e., queried) whenever needed, but in many cases, pushing the data (i.e., subscription) is more efficient, and it can reduce the latency of a client detecting a change. From the data consumer point of view, there are four types of data from network devices that a telemetry data consumer can subscribe or query:
一般に、必要なときにデータを引く（つまり、照会）することができますが、多くの場合、データ（つまり、サブスクリプション）をプッシュすることがより効率的であり、変更を検出するクライアントの遅延を減らすことができます。データ消費者の観点から、ネットワークデバイスからの4つのタイプのデータがあり、テレメトリデータコンシューマーがサブスクライブまたはクエリすることができます。
* Simple Data: Data that are steadily available from some datastore or static probes in network devices.
* 簡単なデータ：一部のデータストアまたはネットワークデバイスの静的プローブから着実に利用できるデータ。
* Derived Data: Data that need to be synthesized or processed in the network from raw data from one or more network devices. The data processing function can be statically or dynamically loaded into network devices.
* 派生データ：1つ以上のネットワークデバイスからの生データからネットワーク内で合成または処理する必要があるデータ。データ処理機能は、静的または動的にネットワークデバイスにロードできます。
* Event-triggered Data: Data that are conditionally acquired based on the occurrence of some events. An example of event-triggered data could be an interface changing operational state between up and down. Such data can be actively pushed through subscription or passively polled through query. There are many ways to model events, including using Finite State Machine (FSM) or Event Condition Action (ECA) [NETMOD-ECA-POLICY].
* イベントトリガーデータ：一部のイベントの発生に基づいて条件付きで取得されるデータ。イベントトリガーされたデータの例は、上下の間に動作状態を変えるインターフェイスである可能性があります。このようなデータは、サブスクリプションを介して積極的にプッシュするか、クエリを通じて受動的にポーリングすることができます。有限状態マシン（FSM）またはイベント状態アクション（ECA）[NetMod-ECA-Policy]を使用するなど、イベントをモデル化する方法はたくさんあります。
* Streaming Data: Data that are continuously generated. It can be a time series or the dump of databases. For example, an interface packet counter is exported every second. The streaming data reflect real-time network states and metrics and require large bandwidth and processing power. The streaming data are always actively pushed to the subscribers.
* ストリーミングデータ：継続的に生成されたデータ。時系列またはデータベースのダンプである場合があります。たとえば、インターフェイスパケットカウンターは毎秒エクスポートされます。ストリーミングデータは、リアルタイムネットワークの状態とメトリックを反映しており、大きな帯域幅と処理能力が必要です。ストリーミングデータは、常に加入者に積極的にプッシュされます。
The above telemetry data types are not mutually exclusive. Rather, they are often composite. Derived data is composed of simple data; event-triggered data can be simple or derived; and streaming data can be based on some recurring event. The relationships of these data types are illustrated in Figure 3.
上記のテレメトリデータ型は相互に排他的ではありません。むしろ、それらはしばしば複合です。派生データは単純なデータで構成されています。イベントトリガーデータは単純であるか、導き出されます。ストリーミングデータは、いくつかの繰り返しイベントに基づいています。これらのデータ型の関係を図3に示します。
+----------------------+ +-----------------+
| Event-Triggered Data |<----+ Streaming Data |
+-------+---+----------+ +-----+---+-------+
| | | |
| | | |
| | +--------------+ | |
| +-->| Derived Data |<--+ |
| +------+------ + |
| | |
| V |
| +--------------+ |
+------>| Simple Data |<------+
+--------------+
Figure 3: Data Type Relationship
図3：データ型の関係
Subscription usually deals with event-triggered data and streaming data, and query usually deals with simple data and derived data. But the other ways are also possible. Advanced network telemetry techniques are designed mainly for event-triggered or streaming data subscription and derived data query.
サブスクリプションは通常、イベントトリガーされたデータとストリーミングデータを扱い、クエリは通常、単純なデータと派生データを扱います。しかし、他の方法も可能です。高度なネットワークテレメトリテクニックは、主にイベントトリガーまたはストリーミングデータサブスクリプションと派生データクエリ向けに設計されています。
The following table shows how the existing mechanisms (mainly published in IETF and with the emphasis on the latest new technologies) are positioned in the framework. Given the vast body of existing work, we cannot provide an exhaustive list, so the mechanisms in the tables should be considered as just examples. Also, some comprehensive protocols and techniques may cover multiple aspects or modules of the framework, so a name in a block only emphasizes one particular characteristic of it. More details about some listed mechanisms can be found in Appendix A.
次の表は、既存のメカニズム（主にIETFで公開され、最新の新しいテクノロジーに重点を置いている）がフレームワークにどのように位置するかを示しています。既存の作業の膨大な量を考えると、徹底的なリストを提供することはできないため、テーブル内のメカニズムは単なる例として考慮する必要があります。また、一部の包括的なプロトコルと手法は、フレームワークの複数の側面またはモジュールをカバーする場合があるため、ブロック内の名前は、その特定の特性の1つだけを強調しています。いくつかのリストされたメカニズムの詳細については、付録Aをご覧ください。
+===============+=================+================+============+
| | Management | Control Plane | Forwarding |
| | Plane | | Plane |
+===============+=================+================+============+
| data | gNMI, NETCONF, | gNMI, NETCONF, | NETCONF, |
| configuration | RESTCONF, SNMP, | RESTCONF, | RESTCONF, |
| and subscribe | YANG-Push | YANG-Push | YANG-Push |
+---------------+-----------------+----------------+------------+
| data | MIB, YANG | YANG | IOAM, |
| generation | | | PSAMP, |
| and process | | | PBT, AM |
+---------------+-----------------+----------------+------------+
| data encoding | gRPC, HTTP, TCP | BMP, TCP | IPFIX, UDP |
| and export | | | |
+---------------+-----------------+----------------+------------+
Table 2: Existing Work Mapping
表2：既存の作業マッピング
Although the framework is generally suitable for any network environments, the multi-domain telemetry has some unique challenges that deserve further architectural consideration, which is out of the scope of this document.
フレームワークは一般にあらゆるネットワーク環境に適していますが、マルチドメインテレメトリには、このドキュメントの範囲外であるさらなるアーキテクチャの考慮に値するいくつかの独自の課題があります。
Network telemetry is an evolving technical area. As the network moves towards the automated operation, network telemetry applications undergo several stages of evolution, which add a new layer of requirements to the underlying network telemetry techniques. Each stage is built upon the techniques adopted by the previous stages plus some new requirements.
ネットワークテレメトリは、進化する技術分野です。ネットワークが自動操作に向かって移動すると、ネットワークテレメトリアプリケーションは進化のいくつかの段階を遂げ、基礎となるネットワークテレメトリテクニックに新しい要件を追加します。各段階は、前の段階で採用された手法といくつかの新しい要件に基づいて構築されています。
Stage 0 - Static Telemetry: The telemetry data source and type are determined at design time. The network operator can only configure how to use it with limited flexibility.
ステージ0-静的テレメトリ：テレメトリデータソースとタイプは、設計時に決定されます。ネットワークオペレーターは、柔軟性が限られている方法のみを構成することができます。
Stage 1 - Dynamic Telemetry: The custom telemetry data can be dynamically programmed or configured at runtime without interrupting the network operation, allowing a trade-off among resource, performance, flexibility, and coverage.
ステージ1-動的テレメトリ：カスタムテレメトリデータは、ネットワーク操作を中断することなく、実行時に動的にプログラムまたは構成し、リソース、パフォーマンス、柔軟性、およびカバレッジ間のトレードオフを可能にすることができます。
Stage 2 - Interactive Telemetry: The network operator can continuously customize and fine tune the telemetry data in real time to reflect the network operation's visibility requirements. Compared with Stage 1, the changes are frequent based on the real-time feedback. At this stage, some tasks can be automated, but human operators still need to sit in the middle to make decisions.
ステージ2-インタラクティブテレメトリ：ネットワークオペレーターは、ネットワーク操作の可視性要件を反映するために、テレメトリデータをリアルタイムで継続的にカスタマイズおよび微調整できます。ステージ1と比較して、変更はリアルタイムフィードバックに基づいて頻繁に発生します。この段階では、一部のタスクを自動化できますが、人間のオペレーターはまだ決定を下すために中央に座る必要があります。
Stage 3 - Closed-Loop Telemetry: The telemetry is free from the interference of human operators, except for generating the reports. The intelligent network operation engine automatically issues the telemetry data requests, analyzes the data, and updates the network operations in closed control loops.
ステージ3-閉ループテレメトリ：テレメトリは、レポートを生成することを除いて、人間のオペレーターの干渉がありません。インテリジェントネットワーク操作エンジンは、テレメトリデータ要求を自動的に発行し、データを分析し、閉じた制御ループでネットワーク操作を更新します。
Existing technologies are ready for Stages 0 and 1. Individual applications for Stages 2 and 3 are also possible now. However, the future autonomic networks may need a comprehensive operation management system that works at Stages 2 and 3 to cover all the network operation tasks. A well-defined network telemetry framework is the first step towards this direction.
既存のテクノロジーは、ステージ0および1のために準備ができています。ステージ2および3の個々のアプリケーションも現在可能です。ただし、将来の自治ネットワークには、すべてのネットワーク操作タスクをカバーするためにステージ2および3で機能する包括的な操作管理システムが必要になる場合があります。明確に定義されたネットワークテレメトリーフレームワークは、この方向への最初のステップです。
The complexity of network telemetry raises significant security implications. For example, telemetry data can be manipulated to exhaust various network resources at each plane as well as the data consumer; falsified or tampered data can mislead the decision-making process and paralyze networks; and wrong configuration and programming for telemetry is equally harmful. The telemetry data is highly sensitive, which exposes a lot of information about the network and its configuration. Some of that information can make designing attacks against the network much easier (e.g., exact details of what software and patches have been installed) and allows an attacker to determine whether a device may be subject to unprotected security vulnerabilities.
ネットワークテレメトリの複雑さは、重大なセキュリティへの影響をもたらします。たとえば、テレメトリデータを操作して、各プレーンとデータ消費者のさまざまなネットワークリソースを排出できます。偽造または改ざんされたデータは、意思決定プロセスを誤解させ、ネットワークを麻痺させる可能性があります。また、テレメトリの間違った構成とプログラミングは同様に有害です。テレメトリデータは非常に敏感であり、ネットワークとその構成に関する多くの情報を公開します。その情報の一部は、ネットワークに対する攻撃の設計をはるかに簡単にすることができます（たとえば、ソフトウェアとパッチがインストールされていることの正確な詳細）により、攻撃者はデバイスが保護されていないセキュリティの脆弱性の影響を受けるかどうかを判断できます。
Given that this document has proposed a framework for network telemetry and the telemetry mechanisms discussed are more extensive (in both message frequency and traffic amount) than the conventional network OAM concepts, we must also anticipate that new security considerations that may also arise. A number of techniques already exist for securing the forwarding plane, control plane, and management plane in a network, but it is important to consider if any new threat vectors are now being enabled via the use of network telemetry procedures and mechanisms.
このドキュメントがネットワークテレメトリのフレームワークを提案しており、議論されたテレメトリメカニズムは、従来のネットワークOAMの概念よりも広範囲に（メッセージ頻度とトラフィック量の両方）であることを考えると、また発生する可能性のある新しいセキュリティの考慮事項も予測する必要があります。ネットワーク内の転送面、コントロールプレーン、および管理プレーンを固定するための多くの手法が既に存在していますが、ネットワークテレメトリー手順とメカニズムを使用して新しい脅威ベクターが有効になっているかどうかを考慮することが重要です。
This document proposes a conceptual architectural for collecting, transporting, and analyzing a wide variety of data sources in support of network applications. The protocols, data formats, and configurations chosen to implement this framework will dictate the specific security considerations. These considerations may include:
このドキュメントは、ネットワークアプリケーションをサポートするさまざまなデータソースを収集、輸送、分析するための概念的なアーキテクチャを提案しています。このフレームワークを実装するために選択されたプロトコル、データ形式、および構成は、特定のセキュリティに関する考慮事項を決定します。これらの考慮事項には次のものが含まれます。
* Telemetry framework trust and policy models;
* テレメトリーフレームワークの信頼とポリシーモデル。
* Role management and access control for enabling and disabling telemetry capabilities;
* テレメトリ機能を有効にし、無効にするためのロール管理とアクセス制御。
* Protocol transport used for telemetry data and its inherent security capabilities;
* テレメトリーデータとその固有のセキュリティ機能に使用されるプロトコルトランスポート。
* Telemetry data stores, storage encryption, methods of access, and retention practices;
* テレメトリーデータストア、ストレージ暗号化、アクセス方法、および保持慣行。
* Tracking telemetry events and any abnormalities that might identify malicious attacks using telemetry interfaces.
* テレメトリイベントと、テレメトリーインターフェイスを使用して悪意のある攻撃を特定する可能性のある異常を追跡します。
* Authentication and integrity protection of telemetry data to make data more trustworthy; and
* テレメトリデータの認証と整合性保護データをより信頼できるものにします。と
* Segregating the telemetry data traffic from the data traffic carried over the network (e.g., historically management access and management data may be carried via an independent management network).
* ネットワーク上にあるデータトラフィックからのテレメトリデータトラフィックの分離（たとえば、歴史的に管理アクセスと管理データは、独立した管理ネットワークを介して運ばれる場合があります）。
Some security considerations highlighted above may be minimized or negated with policy management of network telemetry. In a network telemetry deployment, it would be advantageous to separate telemetry capabilities into different classes of policies, i.e., Role-Based Access Control and Event-Condition-Action policies. Also, potential conflicts between network telemetry mechanisms must be detected accurately and resolved quickly to avoid unnecessary network telemetry traffic propagation escalating into an unintended or intended denial-of-service attack.
上記で強調されたいくつかのセキュリティ上の考慮事項は、ネットワークテレメトリのポリシー管理により最小化または否定される場合があります。ネットワークテレメトリの展開では、テレメトリ機能をさまざまなクラスのポリシーに分離することが有利です。また、ネットワークテレメトリメカニズム間の潜在的な競合を正確に検出し、迅速に解決する必要があります。
Further study of the security issues will be required, and it is expected that the security mechanisms and protocols are developed and deployed along with a network telemetry system.
セキュリティの問題のさらなる研究が必要であり、セキュリティメカニズムとプロトコルがネットワークテレメトリシステムとともに開発および展開されることが予想されます。
This document has no IANA actions.
このドキュメントにはIANAアクションがありません。
[gnmi] Shakir, R., Shaikh, A., Borman, P., Hines, M., Lebsack, C., and C. Marrow, "gRPC Network Management Interface", IETF 98, March 2017, <https://datatracker.ietf.org/meeting/98/materials/slides-98-rtgwg-gnmi-intro-draft-openconfig-rtgwg-gnmi-spec-00>.
[Gnmi] Shakir、R.、Shaikh、A.、Borman、P.、Hines、M.、Lebsack、C。、およびC. Marrow、「Grpc Network Management Interface」、Ietf 98、2017年3月、<https：//datatracker.ietf.org/meeting/98/materials/slides-98-rtgwg-gnmi-intro-draft-openconfig-rtgwg-gnmi-spec-00>。
[gpb] Google Developers, "Protocol Buffers", <https://developers.google.com/protocol-buffers>.
[GPB] Google開発者、「プロトコルバッファー」、<https://developers.google.com/protocol-buffers>。
[grpc] gRPC, "gPPC: A high performance, open source universal RPC framework", <https://grpc.io>.
[GRPC] GRPC、「GPPC：高性能、オープンソースユニバーサルRPCフレームワーク」、<https://grpc.io>。
[IPPM-IOAM-DIRECT-EXPORT] Song, H., Gafni, B., Zhou, T., Li, Z., Brockners, F., Bhandari, S., Ed., Sivakolundu, R., and T. Mizrahi, Ed., "In-situ OAM Direct Exporting", Work in Progress, Internet-Draft, draft-ietf-ippm-ioam-direct-export-07, 13 October 2021, <https://datatracker.ietf.org/doc/html/ draft-ietf-ippm-ioam-direct-export-07>.
[IPPM-Ioam-Direct-Export] Song、H.、Gafni、B.、Zhou、T.、Li、Z.、Brockners、F.、Bhandari、S.、Ed。、Sivakolundu、R。、およびT.Mizrahi、ed。、「In-Situ OAM Direct Exporting」、Work in Progress、Internet-Draft、Draft-ITITM-Ioam-Direct-Export-07、2021年10月13日、<https://datatracker.ietf.org/doc/html/draft-iitf-ippm-ioam-direct-export-07>。
[IPPM-POSTCARD-BASED-TELEMETRY] Song, H., Mirsky, G., Filsfils, C., Abdelsalam, A., Zhou, T., Li, Z., Mishra, G., Shin, J., and K. Lee, "In-Situ OAM Marking-based Direct Export", Work in Progress, Internet-Draft, draft-song-ippm-postcard-based-telemetry-12, 12 May 2022, <https://datatracker.ietf.org/doc/html/draft-song-ippm-postcard-based-telemetry-12>.
[IPPM-Postcardベースのテレメトリー] Song、H.、Mirsky、G.、Filsfils、C.、Abdelsalam、A.、Zhou、T.、Li、Z.、Mishra、G.、Shin、J。K. Lee、「In-situ OAMマーキングベースの直接輸出」、作業中のインターネットドラフト、ドラフトソン-Song-IPPM-Postcardベースのテレメトリー-12、2022年5月12日、<https：//datatracker.ietf.org/doc/html/draft-song-ippm-postcardベースのテレメトリー-12>。
[NETCONF-DISTRIB-NOTIF] Zhou, T., Zheng, G., Voit, E., Graf, T., and P. Francois, "Subscription to Distributed Notifications", Work in Progress, Internet-Draft, draft-ietf-netconf-distributed-notif-03, 10 January 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-netconf-distributed-notif-03>.
[netconf-distrib-notif] Zhou、T.、Zheng、G.、Voit、E.、Graf、T。、およびP. Francois、「分散通知のサブスクリプション」、作業中、インターネットドラフト、Draft-Itf-netconf-distributed-notif-03、2022年1月10日、<https://datatracker.ietf.org/doc/html/draft-ietf-netconf-distribued-notif-03>。
[NETCONF-UDP-NOTIF] Zheng, G., Zhou, T., Graf, T., Francois, P., Feng, A. H., and P. Lucente, "UDP-based Transport for Configured Subscriptions", Work in Progress, Internet-Draft, draft-ietf-netconf-udp-notif-05, 4 March 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-netconf-udp-notif-05>.
[netconf-udp-notif] Zheng、G.、Zhou、T.、Graf、T.、Francois、P.、Feng、A。H.、およびP. Lucente、「構成されたサブスクリプションのUDPベースの輸送」、進行中の作業、Internet-Draft、Draft-Iitf-NetConf-UUDP-NOTIF-05、2022年3月4日、<https://datatracker.ietf.org/doc/html/draft-ietf-netconf-uudp-notif-05>。
[NETMOD-ECA-POLICY] Wu, Q., Bryskin, I., Birkholz, H., Liu, X., and B. Claise, "A YANG Data model for ECA Policy Management", Work in Progress, Internet-Draft, draft-ietf-netmod-eca-policy-01, 19 February 2021, <https://datatracker.ietf.org/doc/html/ draft-ietf-netmod-eca-policy-01>.
[NetMod-Eca-Policy] Wu、Q.、Bryskin、I.、Birkholz、H.、Liu、X。、およびB. Claise、「ECAポリシー管理のYangデータモデル」、進行中の作業、インターネットドラフト、ドラフト-ITEF-NETMOD-ECA-POLICY-01、2021年2月19日、<https://datatracker.ietf.org/doc/html/ draft-ietf-netmod-eca-policy-01>。
[NMRG-ANTICIPATED-ADAPTATION] Martinez-Julia, P., Ed., "Exploiting External Event Detectors to Anticipate Resource Requirements for the Elastic Adaptation of SDN/NFV Systems", Work in Progress, Internet-Draft, draft-pedro-nmrg-anticipated-adaptation-02, 29 June 2018, <https://datatracker.ietf.org/doc/html/ draft-pedro-nmrg-anticipated-adaptation-02>.
[NMRG予期測定適応] Martinez-Julia、P.、ed。、「SDN/NFVシステムの弾力性適応のためのリソース要件を予測するために外部イベント検出器を利用する」、進行中の作業、インターネットドラフト、ドラフト-PEDRO-NMRG-Stentipated-Adaptation-02、2018年6月29日、<https://datatracker.ietf.org/doc/html/ draft-pedro-nmrg-ntictipated-adaptation-02>。
[NMRG-IBN-CONCEPTS-DEFINITIONS] Clemm, A., Ciavaglia, L., Granville, L. Z., and J. Tantsura, "Intent-Based Networking - Concepts and Definitions", Work in Progress, Internet-Draft, draft-irtf-nmrg-ibn-concepts-definitions-09, 24 March 2022, <https://datatracker.ietf.org/doc/html/draft-irtf-nmrg-ibn-concepts-definitions-09>.
[NMRG-IBN Concepts-Definitions] Clemm、A.、Ciavaglia、L.、Granville、L。Z.、およびJ. Tantsura、「Intent Based Networking-概念と定義」、作業中の作業、インターネットドラフト、ドラフト-IRTFF-NMRG-IBNCONCEPTS-DEFINITIONS-09、2022年3月24日、<https://datatracker.ietf.org/doc/html/draft-irtf-nmrg-ibnconcts-definitions-09>。
[OPSAWG-DNP4IQ] Song, H., Ed. and J. Gong, "Requirements for Interactive Query with Dynamic Network Probes", Work in Progress, Internet-Draft, draft-song-opsawg-dnp4iq-01, 19 June 2017, <https://datatracker.ietf.org/doc/html/draft-song-opsawg-dnp4iq-01>.
[opsawg-dnp4iq] Song、H.、ed。J. Gong、「ダイナミックネットワークプローブを使用したインタラクティブクエリの要件」、作業中の作業、インターネットドラフト、ドラフトソンオプグ-dnp4iq-01、2017年6月19日、<https://datatracker.ietf.org/doc/html/draft-song-opsawg-dnp4iq-01>。
[OPSAWG-IFIT-FRAMEWORK] Song, H., Qin, F., Chen, H., Jin, J., and J. Shin, "A Framework for In-situ Flow Information Telemetry", Work in Progress, Internet-Draft, draft-song-opsawg-ifit-framework-17, 22 February 2022, <https://datatracker.ietf.org/doc/html/draft-song-opsawg-ifit-framework-17>.
[Opsawg-ifit-framework] Song、H.、Qin、F.、Chen、H.、Jin、J。、およびJ. Shin、「In-situ Flow Information Telemetryのフレームワーク」、進行中の作業、インターネット - ドラフト、ドラフトソングオプセグ - イフィットフレームワーク17、2022年2月22日、<https://datatracker.ietf.org/doc/html/draft-song-opsawg-ifit-framework-17>。
[RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network Management Protocol (SNMP)", RFC 1157, DOI 10.17487/RFC1157, May 1990, <https://www.rfc-editor.org/info/rfc1157>.
[RFC1157] Case、J.、Fedor、M.、Schoffstall、M.、およびJ. Davin、「Simple Network Management Protocol（SNMP）」、RFC 1157、DOI 10.17487/RFC1157、1990年5月、<https：// wwwwwww.rfc-editor.org/info/rfc1157>。
[RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, DOI 10.17487/RFC2578, April 1999, <https://www.rfc-editor.org/info/rfc2578>.
[RFC2578] McCloghrie、K.、Ed。、Perkins、D.、ed。、およびJ. Schoenwaelder、ed。、「管理情報の構造バージョン2（SMIV2）」、STD 58、RFC 2578、DOI 10.17487/RFC2578、1999年4月、<https://www.rfc-editor.org/info/rfc2578>。
[RFC2981] Kavasseri, R., Ed., "Event MIB", RFC 2981, DOI 10.17487/RFC2981, October 2000, <https://www.rfc-editor.org/info/rfc2981>.
[RFC2981] Kavasseri、R.、ed。、 "Event Mib"、RFC 2981、doi 10.17487/rfc2981、2000年10月、<https://www.rfc-editor.org/info/rfc2981>。
[RFC3176] Phaal, P., Panchen, S., and N. McKee, "InMon Corporation's sFlow: A Method for Monitoring Traffic in Switched and Routed Networks", RFC 3176, DOI 10.17487/RFC3176, September 2001, <https://www.rfc-editor.org/info/rfc3176>.
[RFC3176] Phaal、P.、Panchen、S。、およびN. McKee、「Inmon CorporationのSflow：Switched and Routed Networksのトラフィックを監視する方法」、RFC 3176、DOI 10.17487/RFC3176、2001年9月、<https：//www.rfc-editor.org/info/rfc3176>。
[RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, DOI 10.17487/RFC3411, December 2002, <https://www.rfc-editor.org/info/rfc3411>.
[RFC3411] Harrington、D.、Presuhn、R。、およびB. Wijnen、「単純なネットワーク管理プロトコル（SNMP）管理フレームワークを説明するためのアーキテクチャ」、Std 62、RFC 3411、DOI 10.17487/RFC3411、2002年12月、<：//www.rfc-editor.org/info/rfc3411>。
[RFC3416] Presuhn, R., Ed., "Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3416, DOI 10.17487/RFC3416, December 2002, <https://www.rfc-editor.org/info/rfc3416>.
[RFC3416] Presuhn、R.、ed。、「Simple Network Management Protocol（SNMP）のプロトコル操作のバージョン2」、STD 62、RFC 3416、DOI 10.17487/RFC3416、2002年12月、<https：// www。rfc-editor.org/info/rfc3416>。
[RFC3877] Chisholm, S. and D. Romascanu, "Alarm Management Information Base (MIB)", RFC 3877, DOI 10.17487/RFC3877, September 2004, <https://www.rfc-editor.org/info/rfc3877>.
[RFC3877] Chisholm、S。およびD. Romascanu、「アラーム管理情報ベース（MIB）」、RFC 3877、DOI 10.17487/RFC3877、2004年9月、<https://www.rfc-editor.org/info/rfc3877>。
[RFC3954] Claise, B., Ed., "Cisco Systems NetFlow Services Export Version 9", RFC 3954, DOI 10.17487/RFC3954, October 2004, <https://www.rfc-editor.org/info/rfc3954>.
[RFC3954] Claise、B.、ed。、「Cisco Systems Netflow Services Exportバージョン9」、RFC 3954、DOI 10.17487/RFC3954、2004年10月、<https://www.rfc-editor.org/info/rfc3954>
[RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. Zekauskas, "A One-way Active Measurement Protocol (OWAMP)", RFC 4656, DOI 10.17487/RFC4656, September 2006, <https://www.rfc-editor.org/info/rfc4656>.
[RFC4656] Shalunov、S.、Teitelbaum、B.、Karp、A.、Boote、J。、およびM. Zekauskas、「一元配置活動測定プロトコル（OWAMP）」、RFC 4656、DOI 10.17487/RFC4656、9月2006、<https://www.rfc-editor.org/info/rfc4656>。
[RFC5085] Nadeau, T., Ed. and C. Pignataro, Ed., "Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires", RFC 5085, DOI 10.17487/RFC5085, December 2007, <https://www.rfc-editor.org/info/rfc5085>.
[RFC5085] Nadeau、T.、ed。and C. Pignataro、ed。、「Pseudowire Virtual Circuit Connectivity Verification（VCCV）：Pseudowiresの制御チャネル」、RFC 5085、DOI 10.17487/RFC5085、2007年12月、<https://www.rfc-editor.org/info/RFC5085>。
[RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", RFC 5357, DOI 10.17487/RFC5357, October 2008, <https://www.rfc-editor.org/info/rfc5357>.
[RFC5357] Hedayat、K.、Krzanowski、R.、Morton、A.、Yum、K。、およびJ. Babiarz、「双方向活性測定プロトコル（Twamp）」、RFC 5357、DOI 10.17487/RFC5357、10月2008、<https://www.rfc-editor.org/info/rfc5357>。
[RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, DOI 10.17487/RFC5424, March 2009, <https://www.rfc-editor.org/info/rfc5424>.
[RFC5424] Gerhards、R。、「Syslog Protocol」、RFC 5424、DOI 10.17487/RFC5424、2009年3月、<https://www.rfc-editor.org/info/rfc5424>。
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10.17487/RFC6020, October 2010, <https://www.rfc-editor.org/info/rfc6020>.
[RFC6020] Bjorklund、M.、ed。、 "Yang -Yang-ネットワーク構成プロトコル（NetConf）のデータモデリング言語、RFC 6020、DOI 10.17487/RFC6020、2010年10月、<https：//www.rfc -editor。org/info/rfc6020>。
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, <https://www.rfc-editor.org/info/rfc6241>.
[RFC6241] Enns、R.、ed。、ed。、Bjorklund、M.、ed。、Schoenwaelder、J.、ed。、およびA. Bierman、ed。、「ネットワーク構成プロトコル（NetConf）」、RFC 6241、DOI 10.17487/RFC6241、2011年6月、<https://www.rfc-editor.org/info/rfc6241>。
[RFC6812] Chiba, M., Clemm, A., Medley, S., Salowey, J., Thombare, S., and E. Yedavalli, "Cisco Service-Level Assurance Protocol", RFC 6812, DOI 10.17487/RFC6812, January 2013, <https://www.rfc-editor.org/info/rfc6812>.
[RFC6812] Chiba、M.、Clemm、A.、Medley、S.、Salowey、J.、Thombare、S.、およびE. Yedavalli、「Cisco Service-Revel Assurance Protocol」、RFC 6812、DOI 10.17487/RFC6812、2013年1月、<https://www.rfc-editor.org/info/rfc6812>。
[RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information", STD 77, RFC 7011, DOI 10.17487/RFC7011, September 2013, <https://www.rfc-editor.org/info/rfc7011>.
[RFC7011] Claise、B.、Ed。、Trammell、B.、Ed。、およびP. Aitken、「流れ情報の交換のためのIPフロー情報エクスポート（IPFIX）プロトコルの仕様」、STD 77、RFC 7011、doi 10.17487/rfc7011、2013年9月、<https://www.rfc-editor.org/info/rfc7011>。
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 2014, <https://www.rfc-editor.org/info/rfc7258>.
[RFC7258] Farrell、S。およびH. Tschofenig、「広範な監視は攻撃です」、BCP 188、RFC 7258、DOI 10.17487/RFC7258、<https：//www.rfc-editor.org/info/rfc72588>。
[RFC7276] Mizrahi, T., Sprecher, N., Bellagamba, E., and Y. Weingarten, "An Overview of Operations, Administration, and Maintenance (OAM) Tools", RFC 7276, DOI 10.17487/RFC7276, June 2014, <https://www.rfc-editor.org/info/rfc7276>.
[RFC7276] Mizrahi、T.、Sprecher、N.、Bellagamba、E.、およびY. Weingarten、「運用、管理、メンテナンス（OAM）ツールの概要」、RFC 7276、DOI 10.17487/RFC7276、2014年6月、<https://www.rfc-editor.org/info/rfc7276>。
[RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext Transfer Protocol Version 2 (HTTP/2)", RFC 7540, DOI 10.17487/RFC7540, May 2015, <https://www.rfc-editor.org/info/rfc7540>.
[RFC7540] Belshe、M.、Peon、R。、およびM. Thomson、ed。、「HyperText Transfer Protocolバージョン2（HTTP/2）」、RFC 7540、DOI 10.17487/RFC7540、2015年5月、<https：///www.rfc-editor.org/info/rfc7540>。
[RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic Networking: Definitions and Design Goals", RFC 7575, DOI 10.17487/RFC7575, June 2015, <https://www.rfc-editor.org/info/rfc7575>.
[RFC7575] Behringer、M.、Pritikin、M.、Bjarnason、S.、Clemm、A.、Carpenter、B.、Jiang、S.、およびL. Ciavaglia、「自律的ネットワーキング：定義と設計目標」、RFC 7575、doi 10.17487/rfc7575、2015年6月、<https://www.rfc-editor.org/info/rfc7575>。
[RFC7799] Morton, A., "Active and Passive Metrics and Methods (with Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, May 2016, <https://www.rfc-editor.org/info/rfc7799>.
[RFC7799]モートン、A。、「アクティブおよびパッシブメトリックとメソッド（中間ハイブリッドタイプを含む）」、RFC 7799、DOI 10.17487/RFC7799、2016年5月、<https://www.rfc-editor.org/info/RFC7799>。
[RFC7854] Scudder, J., Ed., Fernando, R., and S. Stuart, "BGP Monitoring Protocol (BMP)", RFC 7854, DOI 10.17487/RFC7854, June 2016, <https://www.rfc-editor.org/info/rfc7854>.
[RFC7854] Scudder、J.、Ed。、Fernando、R.、およびS. Stuart、「BGPモニタリングプロトコル（BMP）」、RFC 7854、DOI 10.17487/RFC7854、2016年6月、<https：//www.rfc-editor.org/info/rfc7854>。
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016, <https://www.rfc-editor.org/info/rfc7950>.
[RFC7950] Bjorklund、M.、ed。、「Yang 1.1 Data Modeling Language」、RFC 7950、DOI 10.17487/RFC7950、2016年8月、<https://www.rfc-editor.org/info/rfc7950>。
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, <https://www.rfc-editor.org/info/rfc8040>.
[RFC8040] Bierman、A.、Bjorklund、M。、およびK. Watsen、「RestConf Protocol」、RFC 8040、DOI 10.17487/RFC8040、2017年1月、<https://www.rfc-editor.org/info/rfc8040>。
[RFC8084] Fairhurst, G., "Network Transport Circuit Breakers", BCP 208, RFC 8084, DOI 10.17487/RFC8084, March 2017, <https://www.rfc-editor.org/info/rfc8084>.
[RFC8084] Fairhurst、G。、「ネットワーク輸送回路ブレーカー」、BCP 208、RFC 8084、DOI 10.17487/RFC8084、2017年3月、<https://www.rfc-editor.org/info/rfc84>
[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, March 2017, <https://www.rfc-editor.org/info/rfc8085>.
[RFC8085] Eggert、L.、Fairhurst、G.、およびG. Shepherd、「UDP使用ガイドライン」、BCP 145、RFC 8085、DOI 10.17487/RFC8085、2017年3月、<https://www.rfc-editor.org/info/rfc8085>。
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, <https://www.rfc-editor.org/info/rfc8259>.
[RFC8259] Bray、T.、ed。、「JavaScriptオブジェクト表記（JSON）データインターチェンジ形式」、STD 90、RFC 8259、DOI 10.17487/RFC8259、2017年12月、<https：//www.rfc-editor.org/info/rfc8259>。
[RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli, L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, "Alternate-Marking Method for Passive and Hybrid Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321, January 2018, <https://www.rfc-editor.org/info/rfc8321>.
[RFC8321] Fioccola、G.、Ed。、Capello、A.、Cociglio、M.、Castaldelli、L.、Chen、M.、Zheng、L.、Mirsky、G。、およびT. Mizrahi、 "Alternate-marking受動的およびハイブリッドパフォーマンス監視の方法」、RFC 8321、DOI 10.17487/RFC8321、2018年1月、<https://www.rfc-editor.org/info/rfc8321>。
[RFC8639] Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard, E., and A. Tripathy, "Subscription to YANG Notifications", RFC 8639, DOI 10.17487/RFC8639, September 2019, <https://www.rfc-editor.org/info/rfc8639>.
[RFC8639] Voit、E.、Clemm、A.、Gonzalez Prieto、A.、Nilsen-Nygaard、E.、およびA. Tripathy、「Yang通知のサブスクリプション」、RFC 8639、DOI 10.17487/RFC8639、2019年9月、<<<<https://www.rfc-editor.org/info/rfc8639>。
[RFC8641] Clemm, A. and E. Voit, "Subscription to YANG Notifications for Datastore Updates", RFC 8641, DOI 10.17487/RFC8641, September 2019, <https://www.rfc-editor.org/info/rfc8641>.
[RFC8641] CLEMM、A。およびE. Voit、「データストアアップデートのYang通知のサブスクリプション」、RFC 8641、DOI 10.17487/RFC8641、2019年9月、<https://www.rfc-editor.org/info/RFC8641>。
[RFC8671] Evens, T., Bayraktar, S., Lucente, P., Mi, P., and S. Zhuang, "Support for Adj-RIB-Out in the BGP Monitoring Protocol (BMP)", RFC 8671, DOI 10.17487/RFC8671, November 2019, <https://www.rfc-editor.org/info/rfc8671>.
[RFC8671] Evens、T.、Bayraktar、S.、Lucente、P.、Mi、P.、およびS. Zhuang、「BGPモニタリングプロトコル（BMP）におけるadj-rib-outのサポート」、RFC 8671、doi10.17487/rfc8671、2019年11月、<https://www.rfc-editor.org/info/rfc8671>。
[RFC8762] Mirsky, G., Jun, G., Nydell, H., and R. Foote, "Simple Two-Way Active Measurement Protocol", RFC 8762, DOI 10.17487/RFC8762, March 2020, <https://www.rfc-editor.org/info/rfc8762>.
[RFC8762] Mirsky、G.、Jun、G.、Nydell、H.、およびR. Foote、「単純な双方向活性測定プロトコル」、RFC 8762、DOI 10.17487/RFC8762、2020年3月、<https：// wwwwwwwww.rfc-editor.org/info/rfc8762>。
[RFC8889] Fioccola, G., Ed., Cociglio, M., Sapio, A., and R. Sisto, "Multipoint Alternate-Marking Method for Passive and Hybrid Performance Monitoring", RFC 8889, DOI 10.17487/RFC8889, August 2020, <https://www.rfc-editor.org/info/rfc8889>.
[RFC8889] Fioccola、G.、Ed。、Cociglio、M.、Sapio、A。、およびR. Sisto、「パッシブおよびハイブリッドパフォーマンス監視のためのマルチポイント代替マーク法」、RFC 8889、DOI 10.17487/RFC8889、20202020202020202020、<https://www.rfc-editor.org/info/rfc8889>。
[RFC8924] Aldrin, S., Pignataro, C., Ed., Kumar, N., Ed., Krishnan, R., and A. Ghanwani, "Service Function Chaining (SFC) Operations, Administration, and Maintenance (OAM) Framework", RFC 8924, DOI 10.17487/RFC8924, October 2020, <https://www.rfc-editor.org/info/rfc8924>.
[RFC8924] Aldrin、S.、Pignataro、C.、Ed。、Kumar、N.、Ed。、Krishnan、R.、およびA. Ghanwani、「サービス関数チェーン（SFC）運用、管理、およびメンテナンス（OAM）フレームワーク "、RFC 8924、doi 10.17487/rfc8924、2020年10月、<https://www.rfc-editor.org/info/rfc8924>。
[RFC9069] Evens, T., Bayraktar, S., Bhardwaj, M., and P. Lucente, "Support for Local RIB in the BGP Monitoring Protocol (BMP)", RFC 9069, DOI 10.17487/RFC9069, February 2022, <https://www.rfc-editor.org/info/rfc9069>.
[RFC9069] Evens、T.、Bayraktar、S.、Bhardwaj、M.、およびP. Lucente、「BGPモニタリングプロトコル（BMP）のローカルリブのサポート」、RFC 9069、DOI 10.17487/RFC9069、2022年2月、<<<<https://www.rfc-editor.org/info/rfc9069>。
[RFC9197] Brockners, F., Ed., Bhandari, S., Ed., and T. Mizrahi, Ed., "Data Fields for In Situ Operations, Administration, and Maintenance (IOAM)", RFC 9197, DOI 10.17487/RFC9197, May 2022, <https://www.rfc-editor.org/info/rfc9197>.
[RFC9197] Brockners、F.、ed。、Bhandari、S.、ed。、およびT. Mizrahi、ed。、「現場操作、管理、メンテナンスのデータフィールド（IOAM）」、RFC 9197、DOI 10.17487/RFC9197、2022年5月、<https://www.rfc-editor.org/info/rfc9197>。
[W3C.REC-xml-20081126] Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., and F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth Edition)", World Wide Web Consortium Recommendation REC-xml-20081126, November 2008, <https://www.w3.org/TR/2008/REC-xml-20081126>.
[W3C.REC-XML-20081126] Bray、T.、Paoli、J.、Sperberg-Mcqueen、M.、Maler、E.、およびF. Yergeau、「拡張可能なマークアップ言語（XML）1.0（第5版）」、World Wide Web Consortiumの推奨REC-XML-20081126、2008年11月、<https://www.w3.org/tr/2008/REC-XML-20081126>。
[y1731] ITU-T, "Operations, administration and maintenance (OAM) functions and mechanisms for Ethernet-based networks", ITU-T Recommendation G.8013/Y.1731, August 2015, <https://www.itu.int/rec/T-REC-Y.1731/en>.
[Y1731] ITU-T、「イーサネットベースのネットワークの操作、管理およびメンテナンス（OAM）機能とメカニズム」、ITU-T推奨G.8013/Y.1731、2015年8月、<https：//www.itu。int/rec/t-rec-y.1731/en>。
In this non-normative appendix, we provide an overview of some existing techniques and standard proposals for each network telemetry module.
この非規範的な付録では、各ネットワークテレメトリモジュールのいくつかの既存の手法と標準提案の概要を説明します。
NETCONF [RFC6241] is a popular network management protocol recommended by IETF. Its core strength is for managing configuration, but it can also be used for data collection. YANG-Push [RFC8639] [RFC8641] extends NETCONF and enables subscriber applications to request a continuous, customized stream of updates from a YANG datastore. Providing such visibility into changes made upon YANG configuration and operational objects enables new capabilities based on the remote mirroring of configuration and operational state. Moreover, a distributed data collection mechanism [NETCONF-DISTRIB-NOTIF] via a UDP-based publication channel [NETCONF-UDP-NOTIF] provides enhanced efficiency for the NETCONF-based telemetry.
NetConf [RFC6241]は、IETFが推奨する一般的なネットワーク管理プロトコルです。そのコア強度は構成の管理用ですが、データ収集にも使用できます。Yang-Push [RFC8639] [RFC8641]はNetConfを拡張し、サブスクライバーアプリケーションがYangデータストアから継続的でカスタマイズされた更新ストリームを要求できるようにします。Yang構成と動作オブジェクトに加えられた変更をこのような可視性を提供すると、構成と動作状態のリモートミラーリングに基づいて新しい機能が可能になります。さらに、UDPベースの出版チャネル[NetConf-UUDP-NOTIF]を介した分散データ収集メカニズム[NetConf-Distrib-Notif]は、NetConfベースのテレメトリの効率を高めます。
gRPC Network Management Interface (gNMI) [gnmi] is a network management protocol based on the gRPC [grpc] Remote Procedure Call (RPC) framework. With a single gRPC service definition, both configuration and telemetry can be covered. gRPC is an open-source micro-service communication framework based on HTTP/2 [RFC7540]. It provides a number of capabilities that are well-suited for network telemetry, including:
GRPCネットワーク管理インターフェイス（GNMI）[GNMI]は、GRPC [GRPC]リモートプロシージャコール（RPC）フレームワークに基づくネットワーク管理プロトコルです。単一のGRPCサービス定義では、構成とテレメトリの両方をカバーできます。GRPCは、HTTP/2 [RFC7540]に基づくオープンソースマイクロサービス通信フレームワークです。以下を含む、ネットワークテレメトリに適した多くの機能を提供します。
* A full-duplex streaming transport model; when combined with a binary encoding mechanism, it provides good telemetry efficiency.
* 全二重ストリーミングトランスポートモデル。バイナリエンコーディングメカニズムと組み合わせると、良好なテレメトリ効率を提供します。
* A higher-level feature consistency across platforms that common HTTP/2 libraries typically do not provide. This characteristic is especially valuable for the fact that telemetry data collectors normally reside on a large variety of platforms.
* 一般的にHTTP/2ライブラリが提供しないプラットフォーム間の高レベルの機能の一貫性。この特性は、テレメトリデータコレクターが通常、多種多様なプラットフォームに存在するという事実にとって特に価値があります。
* A built-in load-balancing and failover mechanism.
* 組み込みの負荷分散およびフェイルオーバーメカニズム。
BMP [RFC7854] is used to monitor BGP sessions and is intended to provide a convenient interface for obtaining route views.
BMP [RFC7854]は、BGPセッションを監視するために使用され、ルートビューを取得するための便利なインターフェイスを提供することを目的としています。
BGP routing information is collected from the monitored device(s) to the BMP monitoring station by setting up the BMP TCP session. The BGP peers are monitored by the BMP Peer Up and Peer Down notifications. The BGP routes (including Adj_RIB_In [RFC7854], Adj_RIB_out [RFC8671], and local RIB [RFC9069]) are encapsulated in the BMP Route Monitoring Message and the BMP Route Mirroring Message, providing both an initial table dump and real-time route updates. In addition, BGP statistics are reported through the BMP Stats Report Message, which could be either timer triggered or event-driven. Future BMP extensions could further enrich BGP monitoring applications.
BGPルーティング情報は、BMP TCPセッションをセットアップすることにより、監視対象のデバイスからBMP監視ステーションに収集されます。BGPピアは、BMPのピアアップと覗き見によって監視されます。BGPルート（adj_rib_in [rfc7854]、adj_rib_out [rfc8671]、およびローカルリブ[RFC9069]）は、BMPルート監視メッセージとBMPルートミラーリングメッセージにカプセル化され、初期のテーブルダンプとリアルタイムルートの更新の両方を提供します。さらに、BGP統計は、BMP Statsレポートメッセージを介して報告されます。これは、タイマートリガーまたはイベント駆動型のいずれかです。将来のBMP拡張機能は、BGPモニタリングアプリケーションをさらに強化する可能性があります。
The Alternate-Marking method enables efficient measurements of packet loss, delay, and jitter both in IP and Overlay Networks, as presented in [RFC8321] and [RFC8889].
代替マルキング方法により、[RFC8321]および[RFC8889]に示されているように、IPとオーバーレイネットワークの両方でパケット損失、遅延、およびジッターの効率的な測定が可能になります。
This technique can be applied to point-to-point and multipoint-to-multipoint flows. Alternate Marking creates batches of packets by alternating the value of 1 bit (or a label) of the packet header. These batches of packets are unambiguously recognized over the network, and the comparison of packet counters for each batch allows the packet loss calculation. The same idea can be applied to delay measurement by selecting ad hoc packets with a marking bit dedicated for delay measurements.
この手法は、ポイントツーポイントおよびマルプポイントからマルチポイントフローに適用できます。代替マーキングは、パケットヘッダーの1ビット（またはラベル）の値を交互に交互に行うことにより、パケットのバッチを作成します。これらのパケットのバッチは、ネットワークに対して明確に認識されており、各バッチのパケットカウンターの比較により、パケット損失計算が可能になります。同じアイデアを適用して、遅延測定に専念するマークビットを持つアドホックパケットを選択することにより、遅延測定を適用できます。
The Alternate-Marking method needs two counters each marking period for each flow under monitor. For instance, by considering n measurement points and m monitored flows, the order of magnitude of the packet counters for each time interval is n*m*2 (1 per color).
代替マークメソッドには、モニターの下の各フローの各マーキング期間が2つのカウンターが必要です。たとえば、n測定点とm監視されたフローを考慮することにより、各時間間隔のパケットカウンターの大きさの順序はn*m*2（色あたり1）です。
Since networks offer rich sets of network performance measurement data (e.g., packet counters), conventional approaches run into limitations. The bottleneck is the generation and export of the data and the amount of data that can be reasonably collected from the network. In addition, management tasks related to determining and configuring which data to generate lead to significant deployment challenges.
ネットワークは、ネットワークパフォーマンス測定データのリッチセット（パケットカウンターなど）を提供するため、従来のアプローチは制限に遭遇します。ボトルネックは、データの生成とエクスポート、およびネットワークから合理的に収集できるデータの量です。さらに、生成するデータの決定と構成に関連する管理タスクは、重要な展開の課題につながります。
The Multipoint Alternate-Marking approach, described in [RFC8889], aims to resolve this issue and make the performance monitoring more flexible in case a detailed analysis is not needed.
[RFC8889]に記載されているマルチポイントの代替マークアプローチは、この問題を解決し、詳細な分析が必要ない場合にパフォーマンス監視をより柔軟にすることを目的としています。
An application orchestrates network performance measurement tasks across the network to allow for optimized monitoring. The application can choose how roughly or precisely to configure measurement points depending on the application's requirements.
アプリケーションは、ネットワーク全体のネットワークパフォーマンス測定タスクを組み立てて、最適化された監視を可能にします。アプリケーションは、アプリケーションの要件に応じて測定ポイントを構成するために、大まかにまたは正確に選択できます。
Using Alternate Marking, it is possible to monitor a Multipoint Network without in-depth examination by using Network Clustering (subnetworks that are portions of the entire network that preserve the same property of the entire network, called clusters). So in the case where there is packet loss or the delay is too high, the specific filtering criteria could be applied to gather a more detailed analysis by using a different combination of clusters up to a per-flow measurement as described in the Alternate-Marking document [RFC8321].
代替マーキングを使用して、ネットワーククラスタリング（クラスターと呼ばれるネットワーク全体のプロパティ全体を保存するネットワーク全体の一部であるサブネットワーク）を使用して、詳細な調査なしでマルチポイントネットワークを監視することができます。したがって、パケットの損失または遅延が高すぎる場合、特定のフィルタリング基準を適用して、代替マークに記載されているように、フローごとの測定値までのクラスターの異なる組み合わせを使用して、より詳細な分析を収集することができます。文書[RFC8321]。
In summary, an application can configure end-to-end network monitoring. If the network does not experience issues, this approximate monitoring is good enough and is very cheap in terms of network resources. However, in case of problems, the application becomes aware of the issues from this approximate monitoring and, in order to localize the portion of the network that has issues, configures the measurement points more extensively, allowing more detailed monitoring to be performed. After the detection and resolution of the problem, the initial approximate monitoring can be used again.
要約すると、アプリケーションはエンドツーエンドネットワーク監視を構成できます。ネットワークの問題が発生しない場合、この近似監視は十分であり、ネットワークリソースの点で非常に安価です。ただし、問題が発生した場合、アプリケーションはこの近似モニタリングの問題を認識し、問題があるネットワークの部分をローカライズするために、測定ポイントをより広範囲に構成し、より詳細な監視を実行できるようにします。問題の検出と解決後、最初の近似モニタリングを再度使用できます。
A hardware-based Dynamic Network Probe (DNP) [OPSAWG-DNP4IQ] provides a programmable means to customize the data that an application collects from the data plane. A direct benefit of DNP is the reduction of the exported data. A full DNP solution covers several components including data source, data subscription, and data generation. The data subscription needs to define the derived data that can be composed and derived from raw data sources. The data generation takes advantage of the moderate in-network computing to produce the desired data.
ハードウェアベースのダイナミックネットワークプローブ（DNP）[OPSAWG-DNP4IQ]は、アプリケーションがデータプレーンから収集するデータをカスタマイズするプログラム可能な手段を提供します。DNPの直接的な利点は、エクスポートされたデータの削減です。完全なDNPソリューションは、データソース、データサブスクリプション、データ生成など、いくつかのコンポーネントをカバーしています。データサブスクリプションは、生データソースから構成および導出される可能性のある派生データを定義する必要があります。データ生成は、中程度のネットワークコンピューティングを利用して、目的のデータを生成します。
While DNP can introduce unforeseeable flexibility to the data plane telemetry, it also faces some challenges. It requires a flexible data plane that can be dynamically reprogrammed at runtime. The programming Application Programming Interface (API) is yet to be defined.
DNPは、データプレーンテレメトリに予測不可能な柔軟性を導入できますが、いくつかの課題にも直面しています。実行時に動的に再プログラムできる柔軟なデータプレーンが必要です。プログラミングアプリケーションプログラミングインターフェイス（API）はまだ定義されていません。
Traffic on a network can be seen as a set of flows passing through network elements. IPFIX [RFC7011] provides a means of transmitting traffic flow information for administrative or other purposes. A typical IPFIX-enabled system includes a pool of Metering Processes that collects data packets at one or more Observation Points, optionally filters them, and aggregates information about these packets. An Exporter then gathers each of the Observation Points together into an Observation Domain and sends this information via the IPFIX protocol to a Collector.
ネットワーク上のトラフィックは、ネットワーク要素を通過する一連のフローと見なすことができます。IPFIX [RFC7011]は、管理またはその他の目的でトラフィックフロー情報を送信する手段を提供します。典型的なIPFIX対応システムには、1つ以上の観測ポイントでデータパケットを収集し、オプションでフィルターし、これらのパケットに関する情報を集約する計測プロセスのプールが含まれます。その後、輸出国は各観測ポイントを観察ドメインに集め、IPFIXプロトコルを介してコレクターにこの情報を送信します。
Classical passive and active monitoring and measurement techniques are either inaccurate or resource consuming. It is preferable to directly acquire data associated with a flow's packets when the packets pass through a network. IOAM [RFC9197], a data generation technique, embeds a new instruction header to user packets, and the instruction directs the network nodes to add the requested data to the packets. Thus, at the path's end, the packet's experience gained on the entire forwarding path can be collected. Such firsthand data is invaluable to many network OAM applications.
古典的なパッシブおよびアクティブな監視および測定技術は、不正確またはリソース消費のいずれかです。パケットがネットワークを通過するときに、フローのパケットに関連付けられたデータを直接取得することが望ましいです。データ生成手法であるIOAM [RFC9197]は、ユーザーパケットに新しい命令ヘッダーを埋め込み、命令はネットワークノードに要求されたデータをパケットに追加するよう指示します。したがって、パスの終わりに、転送パス全体で得られたパケットのエクスペリエンスを収集できます。このような直接のデータは、多くのネットワークOAMアプリケーションにとって非常に貴重です。
However, IOAM also faces some challenges. The issues on performance impact, security, scalability and overhead limits, encapsulation difficulties in some protocols, and cross-domain deployment need to be addressed.
ただし、IOAMはいくつかの課題にも直面しています。パフォーマンスへの影響、セキュリティ、スケーラビリティ、オーバーヘッドの制限、一部のプロトコルのカプセル化の困難、およびドメインのクロス展開に関する問題に対処する必要があります。
The postcard-based telemetry, as embodied in IOAM Direct Export (DEX) [IPPM-IOAM-DIRECT-EXPORT] and IOAM Marking [IPPM-POSTCARD-BASED-TELEMETRY], is a complementary technique to the passport-based IOAM [RFC9197]. PBT directly exports data at each node through an independent packet. At the cost of higher bandwidth overhead and the need for data correlation, PBT shows several unique advantages. It can also help to identify packet drop location in case a packet is dropped on its forwarding path.
IOAM Direct Export（DEX）[IPPM-Ioam-Direct-Export]およびIOAMマーク[IPPM-Postcardベースのテレメトリ]で具体化されたハガキベースのテレメトリは、パスポートベースのIOAM [RFC9197]に対する補完的な手法です。。PBTは、独立したパケットを介して各ノードでデータを直接エクスポートします。帯域幅のオーバーヘッドが高く、データ相関の必要性を犠牲にして、PBTはいくつかのユニークな利点を示しています。また、パケットが転送パスでドロップされた場合にパケットドロップの場所を識別するのに役立ちます。
Various data planes raise unique OAM requirements. IETF has published OAM technique and framework documents (e.g., [RFC8924] and [RFC5085]) targeting different data planes such as Multiprotocol Label Switching (MPLS), L2 Virtual Private Network (VPN), Network Virtualization over Layer 3 (NVO3), Virtual Extensible LAN (VXLAN), Bit Index Explicit Replication (BIER), Service Function Chaining (SFC), Segment Routing (SR), and Deterministic Networking (DETNET). The aforementioned data plane telemetry techniques can be used to enhance the OAM capability on such data planes.
さまざまなデータプレーンが一意のOAM要件を上げています。IETFは、マルチプロトコルラベルスイッチング（MPLS）、L2仮想プライベートネットワーク（VPN）、ネットワーク仮想化レイヤー3（NVO3）、仮想化などのさまざまなデータプレーンを対象としたOAMテクニックおよびフレームワークドキュメント（[RFC8924]および[RFC5085]など）を公開しています。拡張可能なLAN（VXLAN）、ビットインデックス明示的複製（BIER）、サービス関数チェーン（SFC）、セグメントルーティング（SR）、および決定論的ネットワーキング（DETNET）。前述のデータプレーンテレメトリテクニックを使用して、このようなデータプレーンのOAM機能を強化できます。
To ensure that the information provided by external event detectors and used by the network management solutions is meaningful for management purposes, the network telemetry framework must ensure that such detectors (sources) are easily connected to the management solutions (sinks). This requires the specification of a list of potential external data sources that could be of interest in network management and matching it to the connectors and/or interfaces required to connect them.
外部イベント検出器によって提供され、ネットワーク管理ソリューションで使用される情報が管理目的で意味があることを確認するには、ネットワークテレメトリフレームワークは、そのような検出器（ソース）が管理ソリューション（シンク）に簡単に接続されていることを確認する必要があります。これには、ネットワーク管理に関心があり、それらを接続するために必要なコネクタおよび/またはインターフェイスに一致させる可能性のある潜在的な外部データソースのリストの指定が必要です。
Categories of external event sources that may be of interest to network management include:
ネットワーク管理に興味があるかもしれない外部イベントソースのカテゴリには、以下が含まれます。
* Smart objects and sensors. With the consolidation of the Internet of Things (IoT), any network system will have many smart objects attached to its physical surroundings and logical operation environments. Most of these objects will be essentially based on sensors of many kinds (e.g., temperature, humidity, and presence), and the information they provide can be very useful for the management of the network, even when they are not specifically deployed for such purpose. Elements of this source type will usually provide a specific protocol for interaction, especially one of the protocols related to IoT, such as the Constrained Application Protocol (CoAP).
* スマートオブジェクトとセンサー。モノのインターネット（IoT）の統合により、どのネットワークシステムも、物理的な環境と論理的な操作環境に多くのスマートオブジェクトが付属しています。これらのオブジェクトのほとんどは、基本的に多くの種類のセンサー（温度、湿度、存在など）に基づいており、それらが提供する情報は、そのような目的のために具体的に展開されていない場合でも、ネットワークの管理に非常に役立ちます。。このソースタイプの要素は通常、相互作用のための特定のプロトコル、特に制約付きアプリケーションプロトコル（COAP）などのIoTに関連するプロトコルの1つを提供します。
* Online news reporters. Several online news services have the ability to provide an enormous quantity of information about different events occurring in the world. Some of those events can have an impact on the network system managed by a specific framework; therefore, such information may be of interest to the management solution. For instance, diverse security reports, such as Common Vulnerabilities and Exposures (CVEs), can be issued by the corresponding authority and used by the management solution to update the managed system, if needed. Instead of a specific protocol and data format, the sources of this kind of information usually follow a relaxed but structured format. This format will be part of both the ontology and information model of the telemetry framework.
* オンラインニュース記者。いくつかのオンラインニュースサービスには、世界で発生しているさまざまなイベントに関する膨大な量の情報を提供する機能があります。これらのイベントの一部は、特定のフレームワークによって管理されるネットワークシステムに影響を与える可能性があります。したがって、そのような情報は管理ソリューションにとって興味深いかもしれません。たとえば、一般的な脆弱性や露出（CVE）などの多様なセキュリティレポートを、対応する権限によって発行し、管理ソリューションで使用されて管理されたシステムを必要とする場合（必要に応じて）使用できます。特定のプロトコルとデータ形式の代わりに、この種の情報のソースは通常、リラックスしたが構造化された形式に従います。この形式は、テレメトリーフレームワークのオントロジーモデルと情報モデルの両方の一部になります。
* Global event analyzers. The advance of big data analyzers provides a huge amount of information and, more interestingly, the identification of events detected by analyzing many data streams from different origins. In contrast with the other types of sources, which are focused on specific events, the detectors of this source type will detect generic events. For example, during a sports event, some unexpected movement makes it fascinating, and many people connect to sites that are reporting on the event. The underlying networks supporting the services that cover the event can be affected by such situation, so their management solutions should be aware of it. In contrast with the other source types, a new information model, format, and reporting protocol is required to integrate the detectors of this type with the management solution.
* グローバルイベントアナライザー。ビッグデータアナライザーの進歩は、膨大な量の情報を提供し、さらに興味深いことに、異なる起源から多くのデータストリームを分析することで検出されたイベントの識別を提供します。特定のイベントに焦点を当てた他のタイプのソースとは対照的に、このソースタイプの検出器は一般的なイベントを検出します。たとえば、スポーツイベント中に、予想外の動きが魅力的になり、多くの人々がイベントで報告しているサイトに接続します。イベントをカバーするサービスをサポートする基礎となるネットワークは、そのような状況の影響を受ける可能性があるため、管理ソリューションはそれに注意する必要があります。他のソースタイプとは対照的に、このタイプの検出器を管理ソリューションと統合するには、新しい情報モデル、形式、およびレポートプロトコルが必要です。
Additional detector types can be added to the system, but generally they will be the result of composing the properties offered by these main classes.
追加の検出器タイプをシステムに追加できますが、通常、これらのメインクラスが提供するプロパティを作成した結果になります。
For allowing external event detectors to be properly integrated with other management solutions, both elements must expose interfaces and protocols that are subject to their particular objective. Since external event detectors will be focused on providing their information to their main consumers, which generally will not be limited to the network management solutions, the framework must include the definition of the required connectors for ensuring the interconnection between detectors (sources) and their consumers within the management systems (sinks) are effective.
外部イベント検出器を他の管理ソリューションと適切に統合できるようにするには、両方の要素が特定の目的の対象となるインターフェイスとプロトコルを公開する必要があります。外部イベント検出器は、一般的にネットワーク管理ソリューションに限定されない主要な消費者に情報を提供することに焦点を当てているため、フレームワークには、検出器（ソース）とその消費者間の相互接続を確保するために必要なコネクタの定義を含める必要があります。管理システム内（シンク）が効果的です。
In some situations, the interconnection between external event detectors and the management system is via the management plane. For those situations, there will be a special connector that provides the typical interfaces found in most other elements connected to the management plane. For instance, the interfaces could accomplish this with a specific data model (YANG) and specific telemetry protocol, such as NETCONF, YANG-Push, or gRPC.
状況によっては、外部イベント検出器と管理システムとの相互接続は、管理プレーンを介して行われます。これらの状況では、管理プレーンに接続された他のほとんどの要素に見られる典型的なインターフェイスを提供する特別なコネクタがあります。たとえば、インターフェイスは、特定のデータモデル（Yang）およびNetConf、Yang-Push、GRPCなどの特定のテレメトリプロトコルでこれを達成できます。
Acknowledgments
謝辞
We would like to thank Rob Wilton, Greg Mirsky, Randy Presuhn, Joe Clarke, Victor Liu, James Guichard, Uri Blumenthal, Giuseppe Fioccola, Yunan Gu, Parviz Yegani, Young Lee, Qin Wu, Gyan Mishra, Ben Schwartz, Alexey Melnikov, Michael Scharf, Dhruv Dhody, Martin Duke, Roman Danyliw, Warren Kumari, Sheng Jiang, Lars Eggert, Éric Vyncke, Jean-Michel Combes, Erik Kline, Benjamin Kaduk, and many others who have provided helpful comments and suggestions to improve this document.
ロブ・ウィルトン、グレッグ・ミルスキー、ランディ・プレスフン、ジョー・クラーク、ビクター・リュー、ジェームズ・ギチャード、ウリ・ブルーメンタール、ジュゼッペ・フィオッコラ、ユナン・グ、パルヴィス・イェガニ、ヤング・リー、チン・ウー、ギャン・ミシュラ、ベン・シュワルツ、アレクシー・メルニコフ、マイケル・シャーフ、ドゥルフ・ドディ、マーティン・デューク、ローマン・ダニリウ、ウォーレン・クマリ、シェン・ジャン、ラース・エッガート、エリック・ヴィンケ、ジャン・ミシェル・コーム、エリック・クライン、ベンジャミン・カドゥク、その他この文書を改善するために有益なコメントや提案を提供した多くの人々。
Contributors
貢献者
The other contributors of this document are Tianran Zhou, Zhenbin Li, Zhenqiang Li, Daniel King, Adrian Farrel, and Alexander Clemm.
この文書のもう1つの貢献者は、Tianran Zhou、Zhenbin Li、Zhenqiang Li、Daniel King、Adrian Farrel、およびAlexander Clemmです。
Authors' Addresses
著者のアドレス
Haoyu Song Futurewei United States of America Email: haoyu.song@futurewei.com
haoyu song futureweiiunity of America Email：haoyu.song@futurewei.com
Fengwei Qin China Mobile China Email: qinfengwei@chinamobile.com
Fengwei Qin China Mobile China Email：Qinfengwei@chinamobile.com
Pedro Martinez-Julia NICT Japan Email: pedro@nict.go.jp
Pedro Martinez-Julia Nict Japaneail：pedro@nict.go.jp
Laurent Ciavaglia Rakuten Mobile France Email: laurent.ciavaglia@rakuten.com
Laurent Ciavaglia Rakuten Mobile Franceメール：laurent.ciavaglia@rakuten.com
Aijun Wang China Telecom China Email: wangaj3@chinatelecom.cn
Aijun Wang China Telecom China Email：wangaj3@chinatelecom.cn