RFC 9232: ネットワーク・テレメトリ・フレームワーク

要旨

ネットワーク・テレメトリとは、ネットワークの洞察を高め、効率的で自動化されたネットワーク管理を促進する技術である。遠隔データの生成、収集、相関、消費のためのさまざまな手法を網羅している。本文書では、ネットワークの運用中に遭遇する課題と、それに伴う要件に動機付けられたネットワーク・テレメトリのアーキテクチャ・フレームワークについて説明する。この文書では、用語を明確にし、ネットワーク・テレメトリ・システムのモジュールとコンポーネントをさまざまな観点から分類する。フレームワークと分類法は、関連する作業群に共通の基盤を設定し、関連する手法と標準開発のための指針を提供するのに役立つ。

本文書の位置付け

本文書はインターネット標準化過程の仕様書ではなく、情報提供を目的で公開する。

本文書は、インターネット・リサーチ・タスクフォース(IRTF)の成果物である。IRTFは、インターネット関連の研究開発活動の成果を公開している。これらの成果は、展開に適さないかも知れない。このRFCは、インターネット・リサーチ・タスクフォース(IRTF)のQIRG研究グループの合意を表す。IRSGによって公開が承認された文書は、インターネット標準のいかなるレベルにも該当しない。RFC 7841のセクション2を参照のこと。

文書の現在の位置付け、正誤表、フィードバックの提供方法に関する情報は、<https://www.rfc-editor.org/info/rfc9232>で入手できる。

著作権に関する通知

Copyright (c) 2022 IETFトラストおよび文書の著者として特定された人物。無断転載を禁じる。

本文書は、BCP 78および文書の発行日において有効なIETF文書に関するIETFトラストの法的規定(<https://trustee.ietf.org/license-info>)に従うものとする。これらの文書には、本文書に関するあなたの権利と制限が記載されているため、注意深く確認して欲しい。文書から抽出されたコード・コンポーネントには、トラスト法的条項のセクション4.eに記載されている改訂BSDライセンスのテキストを含まなければならず、改訂BSDライセンスに記載されているように保証なしで提供する。

1. はじめに

ネットワークの可視性とは、ネットワークの状態と挙動を確認する管理ツールの能力であり、ネットワークの正常な運用に不可欠である。ネットワーク・テレメトリは、1) ネットワーク・デバイス、フォワーディング、コントロール、マネジメント・プレーンを含む、ネットワークの現在の状態についての洞察を提供するのに役立ち、2) ネットワークの計測と測定を含むがこれに限定されないさまざまな手法で生成され、取得され、3) さまざまなデータ分析手法を使用してサービス保証からネットワーク・セキュリティに至るまでさまざまな目的のために処理されるネットワーク・データを中心に展開する。この文書では、ネットワーク・テレメトリとは、そのデータ自体(つまり、「ネットワーク・テレメトリ・データ」)と、自動化された管理アプリケーションで使用するために、データを生成、エクスポート、収集、消費するために使用される手法とプロセスの両方を指す。ネットワーク・テレメトリは、従来のネットワーク運用・統治・マネジメント(OAM)手法を超えて拡張され、より優れた柔軟性、スケーラビリティ、精度、カバレッジ、パフォーマンスを支援することが期待されている。

しかし、「ネットワーク・テレメトリ」という用語には明確な定義がない。その範囲と対象が混乱と誤解を引き起こしている。概念を明確にし、ネットワーク・テレメトリの明確なアーキテクチャ・フレームワークを提供することは、技術分野を明確にし、関連する技術や標準化作業をより適切に調整するために有益である。

このような取り組みを実現するために、まず、従来のネットワークOAMと明確に区別されるネットワーク・テレメトリの主要な特徴について説明し、従来のOAM技術のいくつかはネットワーク・テレメトリ技術の一部と考えられることを示す。次に、4つのモジュールを含むネットワーク・テレメトリのアーキテクチャ・フレームワークを提供する。各モジュールは異なるカテゴリのテレメトリ・データと対応する手順に関連付けられている。どのようなデータを生成し、それをどのようにクライアント・アプリケーションで利用できるようにするかについて、オペレータがデータ・ソースを設定できるようにするコンポーネント、基礎となるデータ・ソースを計測するコンポーネント、生成されたデータの実際のレンダリング、エンコード、エクスポートを実行するコンポーネントなど、すべてのモジュールは内部的に同じ構造になっている。私たちは、ネットワーク・テレメトリ・フレームワークが現在および将来のネットワーク運用にどのように役立つかを示し、モジュールと機能コンポーネントの特徴に基づいて、既存および新しい技術とプロトコルをフレームワークにマッピングする。このフレームワークは、ネットワーク・テレメトリ・システムの設計、保守、理解も簡略化することができる。さらに、ネットワーク・テレメトリ・システムの進化段階の概説し、潜在的なセキュリティ上の懸念について説明する。

このフレームワークと分類法の目的は、関連する作業の収集のための共通基盤を確立し、将来の技術と標準開発の指針を提供することである。私たちの知る限り、本文書は、業界標準化団体におけるネットワーク・テレメトリに関する最初の取り組みである。なお、この文書は特定の技術を定義するものではない。

1.1. 適用性に関する声明

大規模なネットワーク・データの収集は、ユーザのプライバシーに対する大きな脅威であり、広範な監視と区別がつかない場合がある[RFC7258]。本文書で紹介されているネットワーク・テレメトリ・フレームワークは、同意なしに個々のユーザデータやエンドユーザを特定したり、その行動を特徴付けることができるデータの生成、エクスポート、収集、分析、保持に適用されてはならない。この原則に基づき、ネットワーク・テレメトリ・フレームワークは、汎用アクセス・ネットワークのような、エンドポイントが個々のユーザを示すネットワークには適用されない。

1.2. 用語集

詳しい説明の前に、この文書で使われている主な用語と略語を列挙する。ネットワーク・テレメトリとOAMの用語には、意図的な区別がある。しかし、この2つの概念に明確な区別があるわけではないことを理解する必要がある。むしろ、ネットワーク・テレメトリはOAMの拡張と見なすことができる。ネットワーク・テレメトリは、既存のOAMプロトコルをすべてカバーしているが、取得から消費までのあらゆる側面に関する、より新しい技術とプロトコルに重点を置いている。

AI: 人工知能。ネットワーク分野において、AIはネットワーク運用や他のタスクを自動化するための機械学習ベースの技術を指す。

AM: 代替マーキング。[RFC8321]で規定されているフロー性能測定方法。

BMP: BGP監視プロトコル。[RFC7854]で規定されている。

DPI: ディープ・パケット・インスペクション。パケットのL3/L4ヘッダのさらに上位層を分析する技術を指す。

gNMI: gRPCネットワーク管理インタフェース。OpenConfig Operator Working Groupのネットワーク管理プロトコルで、主にGoogleが貢献している。詳細については[gnmi]を参照のこと。

GPB: Google Protocol Buffer。構造化データをシリアル化(シリiアライズ)するための拡張可能なメカニズム。詳細は[gpb]を参照のこと。

gRPC: gRPCリモート・プロシージャ・コール。gNMIのベースとなるオープンソースの高性能RPCフレームワーク。詳細については[grpc]を参照のこと。

IPFIX: IPフロー情報エクスポート・プロトコル。[RFC7011]で規定されている。

IOAM: In situ OAM [RFC9197]。データプレーンのオンパス・テレメトリ技術。

JSON: JavaScriptオブジェクト表記法。[RFC8259]で規定されている、データ・オブジェクトの保存と送信に人間が読めるテキストを使用するオープン標準のファイル・フォーマットおよびデータ交換フォーマット。

MIB: 管理情報ベース。ネットワーク上のエンティティを管理するために使用されるデータベース。

NETCONF: ネットワーク構成プロトコル。[RFC6241]で規定されている。

NetFlow: [RFC3954]で説明されているように、フロー・レコード収集に使用されるCiscoのプロトコル。

ネットワーク・テレメトリ: ネットワークの監視と運用のために、ネットワーク・データをリモートで取得し、利用するためのプロセスと計測機器。データの生成、収集、相関、消費などの側面に関する、ネットワーク可視化技術とプロトコルの総称。ネットワーク・テレメトリは、現在のネットワーク運用の問題に対処し、将来のインテント・ドリブンな自律ネットワークへのスムーズな進化を可能にする。

NMS: ネットワーク管理システム。ネットワーク管理者がネットワークを管理するためのアプリケーションを指す。

OAM: 運用(operations)、運営管理(administration)、保守(maintenance)の頭文字をとったもの。ネットワークの障害表示、障害の特定、パフォーマンス情報、データおよび診断機能を提供するネットワーク管理機能のグループ。従来のネットワーク監視技術やプロトコルのほとんどはネットワークOAMに属する。

PBT: ポストカード・ベースのテレメトリ。データ・プレーンのオンパス・テレメトリ技術。代表的な技術は[IPPM-IOAM-DIRECT-EXPORT]に記載されている。

RESTCONF: [RFC8040]で規定されているように、NETCONFで定義されたデータストアの概念を使用して、YANGで定義されたデータにアクセスするためのプログラム・インタフェースを提供するHTTPベースのプロトコル。

SMIv2: 管理情報構造バージョン2。[RFC2578]で規定されているMIBオブジェクトを定義する。

SNMP: シンプル・ネットワーク管理プロトコル。バージョン1、2、3は[RFC1157]、[RFC3416]、[RFC3411]で規定されている。

XML: 拡張マークアップ言語。W3C[W3C.REC-xml-20081126]で規定されている、人間が読むことも機械が読むこともできるデータ・エンコードのマークアップ言語。

YANG: 送信されるデータを定義するためのデータ・モデリング言語である。YANGは[RFC6020]と[RFC7950]で定義されている。

YANG ECA: [NETMOD-ECA-POLICY]で定義されているイベント条件アクション・ポリシーのYANGモデル。

YANG-Push: サブスクライバ・アプリケーションがネットワーク・デバイス上のYANGデータストアにアップデートのストリームを要求できるようにするメカニズム。詳細は[RFC8639]と[RFC8641]で規定されている。

2. 背景

「ビッグ・データ」という用語は、パターン、トレンド、関連性を明らかにするためにコンピュータで分析できる非常に大量のデータセットを表すために使われる。ネットワークは、その規模と転送するネットワーク・トラフィックの量から、間違いなくビッグ・データの情報源である。ネットワークのエンドポイントが個々のユーザを代表しない場合(例えば、産業、データセンター、インフラストラクチャの文脈)、ネットワーク運用は、ユーザのプライバシーを侵害することなく、大規模なデータ収集の恩恵を受けることができる。

今日、多数の商用およびオープンソース・プラットフォーム(Apache Hadoopなど)、ツール(Apache Sparkなど)、テクニック(機械学習など)を利用することで、高度なビッグデータ分析機能にアクセスすることができる。コンピューティングとストレージ技術の進歩により、ネットワークのビッグデータ分析は、ネットワーク事業者にネットワークの洞察を与え、ネットワークの自律化に向かっている。一部の事業者は、ネットワーク・データを理解するために人工知能(AI)の適用を模索し始めている。ソフトウェア・ツールは、ネットワーク・データを使用して、ネットワークの障害、異常、ポリシー違反を検出して対処するだけでなく、将来の出来事を予測することができる。その結果、計画、侵入防止、最適化、自己修復のためのネットワーク・ポリシーの更新が可能になる。

自律ネットワーク[RFC7575]は、人的労力を削減(あるいは無く)し、ネットワーク・リソースをより効率的に利用し、顧客の要件に沿ったより優れたサービスを提供することを目的としたソフトウェア定義ネットワーク(SDN)に続く、ネットワーク進化の論理的な次のステップだと考えられる。IETF ANIMAワーキング・グループは、自動化されたネットワーク管理と専門的に管理されたネットワーク制御のためのプロトコルと手順の開発と保守に専念している。関連する技術であるインテント・ベース・ネットワーキング(IBN)[NMRG-IBN-CONCEPTS-DEFINITIONS]は、ネットワークが意図したとおりに動作していることを確認するために、ネットワークの可視性とテレメトリ・データを必要とする。

しかし、データ処理能力が向上し、アプリケーションがより多くのデータを必要とする一方で、ネットワーク・データをより効率的な方法で有用かつ実用的な情報に抽出・変換する点で、ネットワークは遅れをとっている。システムのボトルネックは、データの消費からデータの供給へと移行しつつある。ネットワーク・ノード数もトラフィック帯域幅は急速に増え続けている。ネットワーク構成とポリシーは、以前よりも短い時間枠で変化している。すべてのネットワーク・プレーンを通過する、より捉えにくいイベントやきめ細かなデータをリアルタイムでキャプチャし、エクスポートする必要がある。一言で言えば、効率的でタイムリかつ柔軟な方法で、ネットワークから十分な高品質のデータを取り出すことが課題である。したがって、既存の技術やプロトコルを調査し、潜在的なギャップを特定する必要がある。

このセクションの残りの部分ではまず、この文書で扱うネットワーク・データ(つまり、テレメトリ・データ)の範囲を明確にする。そして、現在および将来のネットワーク運用におけるいくつかの重要なユースケースについて説明する。次に、現在のネットワークOAM技術とプロトコルが、これらのユースケースに対して不十分である理由を示す。この説明では、新しい手法、技術、プロトコルと既存の手法の拡張の必要性を強調し、これを「ネットワーク・テレメトリ」という包括的な用語で呼ぶことにする。

2.1. テレメトリ・データの範囲

ネットワーク(データ・プレーン、コントロール・プレーン、マネジメント・プレーンを含む)から抽出でき、可視性を得るため、またはアクションの根拠として使用できる情報はすべて、テレメトリ・データと見なされる。これには、統計、イベント・レコードやログ、状態のスナップショット、設定データなどが含まれる。また、アクティブおよびパッシブな測定の出力も含まれる[RFC7799]。一部の例では、生データはデータ・コンシューマに送られる前にネットワークで処理される。このような処理済みのデータもテレメトリ・データと見なされる。テレメトリ・データの価値はさまざまである。場合によっては、コストが許容できるのであれば、低品質データを大量に送信するよりも、少量でも高品質のデータを送信する方が好まれる。テレメトリ・データの分類は、セクション3に記載している。エンドユーザのプライバシーを保護するために、ユーザ・パケット・コンテンツは収集すべきではない。具体的には、ネットワーク・テレメトリ・アプリケーションによって生成、エクスポート、収集されるデータ・オブジェクトには、エンド・ユーザ・システムに関連するトラフィックのいかなるパケット・ペイロードも含むべきではない。

2.2. ユースケース

以下のユースケースは、ネットワーク運用に不可欠なものである。このリストはすべてを網羅した完璧なものではないが、ネットワークにおけるビッグデータの特性であるデータの速度、多様性、量、正確さ(veracity)の要件を強調するには十分である。

• セキュリティ: ネットワーク侵入検知や防御システムは、ネットワーク・トラフィックとアクティビティを監視し、異常に対処する必要がある。攻撃ベクトルが巧妙化し、セキュリティ侵害が深刻化する状況を考えると、ネットワークをより広範かつ深く可視化するために、新しいツールや技術を開発する必要がある。最終的な目標は、人間の介入を一切あるいは最小限に抑え、正当なトラフィック・フローを中断することなくセキュリティを実現することである。

• ポリシーとインテントのコンプライアンス: ネットワーク・ポリシーとは、ネットワーク・アクセスのサービスを制限したり、サービスの差別化を提供したり、トラフィックに特定の処理を強制したりするルールのことである。例えば、サービス・ファンクション・チェーンは、選択されたフローが順序付けられたネットワーク・ファンクションを通過することを要求するポリシーである。[NMRG-IBN-CONCEPTS-DEFINITIONS]で定義されているように、インテントとは、ネットワークが達成すべき運用目標と、ネットワークが提供すべき成果を宣言的な方法で定義したものであり、その達成方法や実装方法を明記しない。インテントをネットワークに適用するには、複雑な変換とマッピングのプロセスを必要とする。ポリシーやインテントが適用されている間、ネットワーク・テレメトリ・データを通じて提供される可視性を頼りにすることで、コンプライアンスを継続的に検証し、監視する必要がある。違反は直ちに報告されなければならない。これにより、ネットワーク管理者にポリシーまたはインテント違反が警告され、ポリシーまたはインテントが引き続き有効であることを保証するために、ネットワークにおけるポリシーまたはインテントの適用方法を更新する可能性がある。

• SLAコンプライアンス: サービス・レベル・アグリーメント(SLA)は、サービス・プロバイダとクライアントとの間のサービス契約であり、サービス測定のための測定基準やサービス・レベルが契約を満たさない場合の救済/ペナルティの手続きなどが含まれる。ユーザは、約束どおりのサービスが提供されているかどうかを確認する必要があり、ネットワーク事業者は、ネットワーク測定データを含むリアルタイムのネットワーク・テレメトリ・データに基づいて、SLAを満たすサービスを提供できているかを評価する必要がある。

• 根本原因の分析: ネットワーク障害の多くは、一連の連鎖的イベントの影響の可能性がある。トラブルシューティングと復旧には、目に見える問題の根本原因を迅速に特定する必要がある。しかし、特に障害が散発的で、同じ原因に関連するイベント・メッセージと関連しないイベント・メッセージの数が膨大な場合、根本原因を特定するのは必ずしも容易ではない。機械学習などの技術は根本原因の分析に利用することはできるが、根本原因を分析するアプリケーションに能動的に入力するか、受動的に取得する関連診断データを識別して提供するかはネットワーク次第である。

• ネットワーク最適化: これはロード・バランシング、トラフィック・エンジニアリング(TE)、ネットワーク計画など、短期・長期のネットワーク最適化手法をすべて網羅する。ネットワーク事業者は、ネットワークの稼働率を最適化し、サービスを差別化して投資収益率(ROI)を向上させたり、資本支出(CAPEX)を削減したりすることに意欲的だ。最初のステップは、トラフィック操作のポリシーを適用する前に、ネットワークの状態をリアルタイムに把握することである。場合によっては、非常に短い時間枠でマイクロバーストを検出して、きめ細かなトラフィック制御を適用し、ネットワークの輻輳を回避する必要がある。ネットワーク容量とトポロジーの長期計画には、長期間にわたって取得した実ネットワークのテレメトリ・データの分析が必要である。

• イベントの追跡と予測: トラフィック・パスとパフォーマンスの可視化は、健全なネットワーク運用に依存するサービスやアプリケーションにとって極めて重要である。ネットワーク事業者にとって、関連する数多くのネットワーク・イベントは気になる事柄である。例えば、ネットワーク事業者は、アプリケーション・フローのパケットがドロップされた場所と理由を知りたがっている。また、問題を事前に警告することで、壊滅的な被害を回避するための予防措置を講じることも望んでいる。

2.3. 課題

長い間、ネットワーク事業者はネットワークを監視するためにSNMP[RFC3416]、コマンド・ライン・インタフェース(CLI)、Syslog[RFC5424]に依存してきた。また、[RFC7276]で説明されている他のOAM技術も、ネットワークのトラブルシューティングを容易にするために使われている。これらの従来の技術は、以下の理由により、これまでのユースケースをサポートするには不十分である。

• ほとんどのユースケースでは、ネットワークを継続的に監視し、リアルタイムにデータ収集を大胆に改善する必要がある。ポーリング・ベースの低頻度のデータ収集は、このようなアプリケーションには適していない。十分なデータ量と精度を大規模に提供するには、データソース(例えば、フォワーディング・チップ)から直接プッシュされるサブスクリプション・ベースのストリーミング・データが適している。

• パケット処理エンジンからトラフィック・マネージャ、ラインカードからメイン・コントロール・ボード、ユーザ・フローから制御プロトコル・パケット、デバイス設定から運用、物理層からアプリケーション層まで、包括的なデータが必要である。従来のOAMでは狭い範囲のデータしか扱えない(例えば、SNMPでは管理情報ベース(MIB)のデータしか扱えない)。従来のネットワーク機器では、必要なプローブをすべて提供することはできない。そのため、よりオープンでプログラム可能なネットワーク機器を必要としている。

• 多くのアプリケーション・シナリオでは、複数のソース(分散ネットワーク・デバイス、ネットワーク・デバイスのさまざまなコンポーネント、またはさまざまなネットワーク・プレーン)からネットワーク全体のデータを相関させる必要がある。断片的なソリューションでは、複数のソースからのデータを統合する機能が欠けていることが多い。自律リソース制御アーキテクチャ(ARCA) [NMRG-ANTICIPATED-ADAPTATION]で部分的に提案されているように、完全なソリューションを構成するには、包括的なフレームワークによって強化され、進められることになる。

• いくつかの従来のOAM技術(CLIやSyslogなど)は、標準化されたデータモデルを欠いている。非構造化データは、ツールの自動化やアプリケーションの拡張性を妨げている。標準化されたデータモデルは、プログラム可能なネットワークをサポートするためには不可欠である。

• いくつかの従来のOAM技術の中にはデータプッシュをサポートするものもあるが(例: SNMPトラップ[RFC2981] [RFC3877]、Syslog、sFlow[RFC3176])、プッシュされるデータは定義済みのコントロール・プレーンの警告(例: SNMPトラップ)か、サンプリングされたユーザ・パケット(例: sFlow)に限定される。ネットワーク事業者は任意のソース、粒度、精度のデータを必要とするが、これは既存の技術の能力を超えている。

• 従来のパッシブ測定技術は、過剰なネットワーク・リソースを消費し、必要以上に冗長なデータを生成するか、または不正確な結果をもたらす可能性がある。一方、従来のアクティブ測定技術は、ユーザ・トラフィックに干渉する可能性があり、その結果は二次的である。ユーザ・トラフィックから直接かつオンデマンドでデータを収集できる技術の方が有利である。

これらの課題は、新しい標準や技術(IPFIX/Netflow、パケット・サンプリング(PSAMP)、IOAM、YANG-Pushなど)によって解決されており、さらに多くの標準と技術が登場している。これらの標準と技術は、新しいフレームワークの中で認識し、対応する必要がある。

2.4. ネットワーク・テレメトリ

ネットワーク・テレメトリは、ネットワーク・データの収集と消費技術を指す主流の技術用語として登場した。いくつかのネットワーク・テレメトリ技術とプロトコル(例えば、IPFIX[RFC7011]やgRPC[grpc])が広く導入されている。ネットワーク・テレメトリは、個別のエンティティがネットワーク・デバイスからデータを取得し、データを視覚化して分析することで、ネットワークの監視と運用をサポートできる。ネットワーク・テレメトリは従来のネットワークOAMをカバーし、より広い範囲をカバーする。事例を挙げると、ネットワーク・テレメトリは、自律型ネットワークに必要なネットワークの洞察を提供し、従来のOAM技術の欠点に対処できることが期待されている。

ネットワーク・テレメトリは通常、人間の運用者ではなく、マシンをデータ・コンシューマとして想定している。そのため、ネットワーク・テレメトリは自動化されたネットワーク運用の直接的なきっかけとなる。一方、これとは対照的に、従来のOAMツールは、人間の運用者がネットワークを監視・診断し、手動によるネットワーク運用をガイドするように設計され、使用されてきた。このようなやり方は、まったく異なる技術につながる。

新しいネットワーク・テレメトリ技術が出現しており、継続的な進化を遂げているが、ネットワーク・テレメトリのいくつかの特徴は広く受け入れられている。ネットワーク・テレメトリは、幅広い技術をカバーする包括的な用語として意図されているため、以下の特徴がすべての特定の技術に備わっているとは限らないことに留意すること。

• プッシュとストリーミング: テレメトリ・コレクタは、ネットワーク・デバイスからデータをポーリングする代わりに、ネットワーク・デバイスのデータソースからプッシュされるストリーミング・データをサブスクライブする。
• 量と速度: テレメトリ・データは、人間ではなくマシンによって消費されることを目的としている。そのため、データ量は膨大になり、処理はリアルタイムで自動化のニーズに合わせて最適化される。
• 正規化と統合: テレメトリは、ネットワーク全体の自動化のニーズに対応することを目的としている。データ表現の正規化とプロトコルの統合により、データ分析を簡素化し、ネットワーク全体の異種デバイスとデータソースにまたがる統合分析を提供する取り組みが行われている。
• モデル・ベース: テレメトリ・データは事前にモデル化されているため、アプリケーションはデータを簡単に設定し、利用することができる。
• データ・フュージョン: 1つのアプリケーションのデータは、共通の名前/IDに基づく複数のデータソース(クロスドメイン、クロスデバイス、クロスレイヤなど)から取得される可能性があり、効果を発揮するには相関分析が必要である。
• 動的でインタラクティブ: ネットワーク・テレメトリは、ネットワーク・オートメーションの閉制御ループで使用されるため、継続的に実行され、ネットワーク運用コントローラからの動的でインタラクティブなクエリに適応する必要がある。

さらに、理想的なネットワーク・テレメトリ・ソリューションは、以下の特徴や特性も備えている:

• ネットワーク内でのカスタマイズ: 生成されたデータは、アプリケーションの特定のニーズに対応するために、実行時にネットワーク内でカスタマイズすることができる。これには、プログラミング可能なデータ・プレーンのサポートが必要で、これによりカスタム機能を持つプローブを柔軟な場所に展開することができる。
• ネットワーク内のデータの集約と相関分析: ネットワーク・デバイスと集約ポイントは、どのイベントとデータを保存、報告、または破棄する必要があるかを判断できるため、適切な情報がタイムリーに処理される状態を確保しながら、中央の収集と処理ポイントの負荷を軽減することができる。
• ネットワーク内処理: 場合によっては、すべての情報を中央に集めて処理し、対応することが必ずしも必要であったり、実行可能であったりするわけではない。データ処理をネットワーク上で行うことで、ローカルでリアクティブなアクションを取ることも可能になる。
• ダイレクト・データ・プレーン・エクスポート: データ・プレーンのフォワーディング・チップで生成されたデータは、特にデータ帯域幅が大きく、リアルタイム処理が必要な場合、効率性を高めるためにデータ・コンシューマに直接エクスポートすることができる。
• インバンド・データ収集: パッシブおよびアクティブなデータ収集アプローチに加え、新しいハイブリッド・アプローチでは、フォワーディング・パス全体における任意のターゲット・フローのデータを直接収集することができる[OPSAWG-IFIT-FRAMEWORK]。

ネットワーク・テレメトリ・システムは、「オブザーバ効果」の落とし穴を回避することで、通常のネットワーク運用に干渉しないようにすべきである。つまり、ネットワークの動作を変更したり、フォワーディング性能に影響を与えたりしてはならない。さらに、適切な分離またはトラフィック・エンジニアリング技術が導入されていない場合、あるいはネットワーク容量を超えるテレメトリ・トラフィックが発生した場合に、輻輳制御メカニズムがテレメトリ・トラフィックをバックオフさせることを保証しない場合、大量のテレメトリ・トラフィックはネットワークの輻輳を引き起こす可能性がある。[RFC8084]および[RFC8085]は、この分野における関連するベスト・カレント・プラクティス(BCP)である。

⚠️ オブザーバ効果

観察するという行為が観察される現象に与える変化を指す。例えば、プロセスの進行状況を記録するデータログを採取すると、プロセスはその採取処理の負荷分だけ低速になる。さらに、プロセス実行中にそのファイルを見るという行為によって、対象プロセスでI/Oエラーが生じる可能性があり、結果としてプロセスが停止することにもなる。

多くの場合、ネットワーク・テレメトリのシステムは、リモートでデータを収集し、消費するエンティティを含むが、システムをどのように構築すべきかについて、固有の前提条件がないことを理解することが重要である。集中型コントローラー(SDNなど)によるネットワーク・アーキテクチャはネットワーク・テレメトリに適しているように思えるが、ネットワーク・テレメトリは分散型でも機能する。例えば、テレメトリ・データのプロデューサとコンシューマはピア・ツー・ピアの関係を持つことができ、ネットワーク・ノードは他のノードからのテレメトリ・データを直接コンシューマとなることも可能である。

2.5. ネットワーク・テレメトリ・フレームワークの必要性

ネットワーク・データ分析(例えば、機械学習)は、ネットワークから得られる豊富で一貫性のあるデータに依存して、ネットワーク運用自動化に適用される。単一のソースに限定され、静的な性質を持つデータ取得は、多くの場合、アプリケーションのテレメトリ・データ要件を満たすのに不十分である。その結果、さまざまな技術や標準規格を含む複数のデータ・ソースを統合する必要がある。さまざまなテレメトリ・データ・ソースとタイプを分類・整理し、ネットワーク・テレメトリ・システムのさまざまなコンポーネントとその相互作用を定義し、レイヤ全体にわたる複数のテレメトリ・アプローチの調整・統合を支援するフレームワークが必要である。これにより、インタフェースを正規化および簡素化しながら、さまざまなアプリケーション向けのデータの柔軟な組み合わせが可能になる。詳細に説明すると、このようなフレームワークは、以下の理由によりネットワーク運用アプリケーションの開発に役立つ。

• 自律型であろうとなかろうと、全体的かつ包括的なネットワークの可視性に依存する。可能な限り、統合された集中型のメカニズムと共通のテレメトリ・データ表現を使用して、均一かつ一貫性のあるサポートが得られる場合、ユースケースとアプリケーションはより効果的になる。したがって、プロトコルとメカニズムは、最小限かつ包括的なセットに統合する必要がある。テレメトリ・フレームワークは、技術開発の標準化に役立つ。
• ネットワークの可視性には、複数の視点がある。例えば、デバイスの視点では、ネットワーク・インフラストラクチャを監視対象として、そこからネットワーク・トポロジーとデバイスのステータスを取得できる。また、トラフィックの視点では、フローまたはパケットを監視対象として、そこからトラフィックの品質とパスを取得できる。アプリケーションは、動作中に視点の切り替えが必要になる場合がある。また、包括的な情報を取得するために、サービスとユーザ体験(UE)への影響を関連付ける必要がある。
• アプリケーションは、ネットワーク・リソースを効率的に利用し、ネットワーク・テレメトリに関連する処理がネットワーク性能に与える影響を軽減するために、ネットワーク・テレメトリは融通性が求められる。例えば、日常的なネットワーク監視は、低いデータ・サンプリング・レートでネットワーク全体をカバーし、問題が発生したり、重要な傾向が明らかになった場合にのみ、テレメトリ・データ・ソースを変更し、必要に応じてテレメトリ・データ・レートを引き上げる必要がある。
• アプリケーションにとって、効率的なデータ集約は、データの全体的なデータ量を削減し、分析の精度を向上させるために極めて重要である。

テレメトリ・フレームワークは、IETF内のさまざまな情報源やワーキング・グループからテレメトリ関連の作業をすべて収集する。これにより、包括的なネットワーク・テレメトリ・システムの構築が可能になり、繰り返し作業や冗長作業を回避することができる。フレームワークは、標準化の観点から概念とコンポーネントをカバーすべきである。本文書では、ネットワーク・テレメトリ・フレームワークを構成するモジュールについて説明し、既存および将来の作業が容易にマッピングできる個別のコンポーネントにテレメトリ・システムを分解する。

3. ネットワーク・テレメトリ・フレームワーク

最上位のネットワーク・テレメトリ・フレームワークは、テレメトリ・データ・オブジェクトの発信元に基づいてネットワーク・テレメトリを4つのモジュールに分割し、それらの関係性を表す。ネットワーク運用アプリケーションがこれらのモジュールからデータを取得すると、データ分析を適用してアクションを実行できる。次のレベルでは、このフレームワークは各モジュールを個別のコンポーネントに分解する。これらの各モジュールは、データ・サブスクリプションとデータ・ソースの設定に特化した1つ目のコンポーネント、データのエンコードとエクスポートに特化した2つ目のコンポーネント、基本リソースに関連するテレメトリの生成を計測する3つ目のコンポーネントという、同じ基本構造に従っている。フレームワーク全体を通して、同じ抽象データ取得メカニズムとデータ・タイプ(セクション3.3)が適用される。統一されたデータ抽象化を備えた2レベルのアーキテクチャは、ネットワーク・テレメトリ・システム内のポジションを正確に特定するのに、プロトコルまたは技術が役立つ。また、ネットワーク・テレメトリ・システムを管理可能な部分に分解するのにも役立つ。

3.1. トップ・レベルのモジュール

テレメトリは、図1に示すように、ネットワーク内のフォワーディング・プレーン、コントロール・プレーン、マネジメント・プレーン、およびネットワーク外の他の情報に適用できる。したがって、ネットワーク・テレメトリは、マネジメント・プレーン、コントロール・プレーン、フォワーディング・プレーン、外部データおよびイベント・テレメトリの4つの異なるモジュールに分類され、それぞれがネットワーク運用アプリケーションへの独自のインタフェースを持つ。

図1: ネットワーク・テレメトリ・フレームワークのレイヤ・カテゴリのモジュール

このパーティションの根拠は、データ・ソースとエクスポート先が異なるテレメトリ・データ・オブジェクトにある。このような違いは、ネットワーク内でのデータ・プログラミングと処理機能、データ・エンコーディングとトランスポート・プロトコル、必要なデータ帯域幅とレイテンシに重大な影響を及ぼす。データは直接送信することも、コントロール・プレーンとマンジメント・プレーンを経由して送信することもできる。どちらのアプローチにも利点と欠点がある。

場合によっては、ネットワーク・コントローラ自体が、そのコントローラに固有の、またはネットワーク・エレメントから収集したテレメトリ・データから派生したテレメトリ・データのソースとなる可能性があることに留意すべきである。また、コントロール・プレーンおよびマネジメント・プレーンのテレメトリに特有の原則と分類法の一部は、コントローラが外部でホストされているネットワーク運用アプリケーションにテレメトリ・データを提供する必要がある場合にも適用できる。本文書の対象はネットワーク・エレメントのテレメトリに重点が置かれており、コントローラに関連する詳細については対象外である。

表1に4つのモジュールの主な相違点をまとめた。以下の6つの角度から比較している:

• データ・オブジェクト
• データのエクスポート先
• データ・モデル
• データのエンコーディング
• テレメトリ・アプリケーション・プロトコル
• データ転送方法

データ・オブジェクトは、各モジュールのターゲットでありソースでもある。データ・ソースはさまざまであるため、データを最も役に立つようにエクスポートできる場所もさまざまである。例えば、フォワーディング・プレーン・データは主にフォワーディングASIC(特定用途向け集積回路)からエクスポートされたデータであり、一方、コントロール・プレーン・データは主に制御CPU上で実行されているプロトコル・デーモンから生成されたデータである。利便性と効率性を考慮すると、デバイスからデータをエクスポートする場所はソースに近い場所が推奨される。データをエクスポートできる場所にはさまざまな機能があるため、パフォーマンスとコストのバランスをとるために、データ・モデル、エンコーディング、転送方法のさまざまな選択肢が用意されている。例えば、フォワーディング・チップはスループットが高いが、複雑なデータの処理や状態の維持には容量が限られている。一方、メイン制御CPUは複雑なデータや状態の処理が可能だが、高スループットのデータには帯域幅が限られている。その結果、各モジュールに適したテレメトリ・プロトコルは異なる場合がある。各モジュールの技術的多様性を強調するために、代表的な手法を対応する表のブロックに示している。選択した技術は、事実上の最先端技術を反映したものに過ぎず、決して網羅的なものではないことに留意すること(例えば、IPFIXはTCPおよびSCTP経由でも実装可能だが、フォワーディング・プレーンには推奨されない)。重要な点は、すべてのネットワーク・テレメトリ要件をカバーする汎用プロトコルを使用できると期待してはならない。

モジュール	マネジメント・プレーン	コントロール・プレーン	フォワーディング・プレーン	外部データ
オブジェクト	設定と動作状態	制御プロトコルとシグナリング、RIB	フローおよびパケットQoS、トラフィック統計、バッファおよびキュー統計、FIB、アクセス制御リスト(ACL)	ターミナル、社会的、環境的
エクスポートする場所	メイン制御CPU	メイン制御CPU、ラインカードCPU、またはフォワーディング・チップ	フォワーディング・チップまたはラインカードCPU。メイン制御CPUは使用できない	様々
データ・モデル	YANG、MIB、syslog	YANG、カスタム	YANG、カスタム	YANG、カスタム
データのエンコード	GPB、JSON、XML	GPB、JSON、XML、プレーン・テキスト	プレーン・テキスト	GPB、JSON、XML、プレーン・テキスト
アプリケーション・プロトコル	gRPC、NETCONF、RESTCONF	gRPC、NETCONF、IPFIX、トラフィック・ミラーリング	IPFIX、トラフィック・ミラーリング、gRPC、NETFLOW	gRPC
データ転送	HTTP(S)、TCP	HTTP(S)、TCP、UDP	UDP	HTTP(S)、TCP、UDP

表1: データ・オブジェクト・モジュールの比較

ネットワーク・テレメトリ・データを消費するアプリケーションとのやり取りは間接的な場合があることに留意する。デバイス内でのデータ転送は可能である。例えば、マネジメント・プレーン・テレメトリでは、マネジメント・プレーンはデータ・プレーンからデータを取得する必要がある。インタフェースの状態や統計などのデータ・プレーンのデータ・ソースからしか導き出せない運用状態もある。別の例として、コントロール・プレーンのテレメトリ・データを取得するには、データ・プレーンのフォワーディング情報ベース(FIB)にアクセスする必要がある。

一方、アプリケーションは複数のプレーンを含み、複数のプレーンと同時にやり取りを行う場合もある。例えば、SLA準拠アプリケーションでは、データ・プレーン・テレメトリとコントロール・プレーン・テレメトリの両方が必要になることがある。

各モジュールに対する要件と課題は以下のようにまとめることができる(要件はすべてのテレメトリ・モジュールに適用される可能性があることに留意する。ただし、個々のプレーンで最も顕著なものに重点を置いている)。

3.1.1. マネジメント・プレーン・テレメトリ

ネットワーク・エレメントのマネジメント・プレーンは、ネットワーク管理システム(NMS)とやり取りし、パフォーマンス・データ、ネットワークのログ・データ、ネットワークの警告および障害データ、ネットワークの統計および状態データなどの情報を提供する。マネジメント・プレーンには、従来のSNMPやsyslogなど、多くのプロトコルが含まれている。プロトコルに関係なく、マネジメント・プレーン・テレメトリは以下の要件に対応しなければならない。

• 有用なデータ・サブスクリプション: アプリケーションは、エクスポートするデータ(セクション3.3を参照)と、そのデータをエクスポートする手段と頻度(変更時または定期的なサブスクリプションなど)を自由に選択できる。
• 構造化データ: 自動ネットワーク運用では、ネットワーク・データの理解において人間に代わってマシンが行う。YANGなどのデータ・モデリング言語は、構造化データを効率的に記述し、データ・エンコーディングと変換を正規化できる。
• 高速データ転送: 情報の速度に追いつくためには、データ・ソースは大量のデータを高い頻度で送信できなければならない。データ量を減らし、データ転送の効率を向上させるには、コンパクトなエンコーディング形式またはデータ圧縮方式が必要である。サブスクリプション・モードは、クエリ・モードを置き換えることで、クライアントとサーバ間のやり取りを減らし、データ・ソースの効率を向上させるのに役立つ。
• ネットワークの輻輳回避: アプリケーションは輻輳制御メカニズム、または少なくともサーキット・ブレーカーによって、ネットワークの輻輳を回避しなければならない。[RFC8084]および[RFC8085]では、この分野におけるいくつかのソリューションが提示されている。

3.1.2. コントロール・プレーン・テレメトリ

コントロール・プレーン・テレメトリとは、プロトコル・スタックの全レイヤにおける、さまざまなネットワーク制御プロトコルの正常状態の監視を指す。これらのプロトコルの稼働状況を追跡することは、さまざまなネットワークの問題を検出、特定、さらに予測することに役立つだけでなく、ネットワークの最適化をリアルタイムかつきめ細かく実行するためにも役立つ。コントロール・プレーン・テレメトリが直面するいくつかの課題と問題は以下の通りである。

• エンド・ツー・エンド(E2E)の重要業績評価指標(KPI)を特定のレイヤのKPIに関連付ける方法。例えば、IPTVユーザは、ビデオの滑らかさや鮮明度でUEを説明することができる。その場合、UEのKPIが異常に低かったり、サービスが切断されたりした場合に、原因となるプロトコル層(トランスポート層やネットワーク層など)、原因となるプロトコル(ネットワーク層のIS-ISやBGPなど)、そして原因となるデバイスを具体的な理由とともに区別し、特定することは容易ではない。
• コントロール・プレーンのKPI測定における従来のOAMベースのアプローチには、Ping(L3)、Traceroute(L3)、Y.1731[y1731]などがある。これらの方法に共通する問題の1つは、このプロトコルの実際の稼働状態を反映するものではなく、KPIのみを測定することであり、コントロール・プレーンのトラブルシューティングやネットワークの最適化の有効性や効率性が低下することである。
• BGPモニタリング・プロトコル(BMP)は、さらなる研究が必要である。BMPはコントロール・プレーン・テレメトリの一例であり、現在ではBGP経路のモニタリングに使用され、BGPピア分析、自律システム(AS)分析、プレフィックス分析、セキュリティ分析などの豊富なアプリケーションを可能にしている。しかし、他のレイヤ、プロトコル、およびレイヤ間、プロトコル間のKPI相関関係のモニタリングはまだ初期段階にあり(例えば、IGPモニタリングはBMPほど広範囲ではない)、さらなる研究が必要である。

ネットワークの輻輳回避の要件とソリューションは、コントロール・プレーン・テレメトリにも適用できることに留意すること。

3.1.3. フォワーディング・プレーン・テレメトリ

効果的なフォワーディング・プレーン・テレメトリ・システムは、ネットワーク・デバイスが公開できるデータに依存する。データの品質、量、適時性は、いくつかの厳しい要件を満たさなければならない。これは、一次データが生成されるネットワーク・データ・プレーン・デバイスにいくつかの課題が生じる。

• データ・プレーン・デバイスの主な機能は、ユーザ・トラフィックの処理とフォワーディングである。ネットワークの可視性をサポートすることは重要だが、テレメトリはあくまで補助的な機能であり、通常のトラフィック処理とフォワーディングを妨げないようにすべきである(つまり、フォワーディング動作を変更せず、フォワーディング性能とテレメトリのトレードオフをバランスよく調整する必要がある)。
• ネットワーク運用アプリケーションは、さまざまなソースにわたるエンド・ツー・エンドの可視性が求められ、その結果、膨大な量のデータが発生する可能性がある。ただし、データ配信方法(インバンドかアウト・オブ・バンドのチャネル経由か)に関係なく、データ量がネットワーク帯域幅が圧迫してはならない。
• データ・プレーン・デバイスは、可能な限り遅延を最小限に抑えてタイムリーなデータを提供しなければならない。処理、転送、保存、分析の遅延が長くなると、制御ループの有効性に影響を及ぼし、データが役に立たなくなることもある。
• データは構造化され、ラベル付けされ、アプリケーションが分析および利用しやすいものでなければならない。同時に、アプリケーションが必要とするデータ・タイプは大幅に異なる可能性がある。データ・プレーン・デバイスは、アプリケーションに正確なデータを提供できるよう、十分な柔軟性とプログラマビリティを備える必要がある。
• データ・プレーン・テレメトリは増分的な展開をサポートし、一部のデバイスがシステムを認識していなくても動作する必要がある。
• ネットワークの輻輳回避の要件とソリューションは、フォワーディング・プレーン・テレメトリにも適用できる。

これらの課題は、フォワーディング・プレーンに特有のものではないが、リソースと柔軟性が限られているため、フォワーディング・プレーンにとってより困難である。データ・プレーンのプログラマビリティは、ネットワーク・テレメトリをサポートするために不可欠である。新しいデータ・プレーンのフォワーディング・チップは、高度なテレメトリ機能が搭載されており、カスタマイズされたテレメトリ機能をサポートする柔軟性を提供する。

技術分類: これはテレメトリをどのように計測するかに関係する。フォワーディング・プレーンのテレメトリ技術を分類するには、複数の次元が考えられる。

• アクティブ、パッシブ、ハイブリッド: この次元は、エンド・ツー・エンドの測定に関するものである。アクティブおよびパッシブ方式(およびハイブリッド型)は、[RFC7799]に詳しく記載されている。パッシブ方式には、TCPDUMP、IPFIX [RFC7011]、sFlow、トラフィックのミラーリングなどがある。これらの方式は通常、データ・カバレッジが低い。データ・カバレッジを向上させるには、帯域幅コストが非常に高くなる。一方、アクティブ方式には、Ping、一方向アクティブ測定プロトコル(OWAMP)[RFC4656]、双方向アクティブ測定プロトコル(TWAMP)[RFC5357]、シンプル双方向アクティブ測定プロトコル(STAMP)[RFC8762]、およびCiscoのSLAプロトコル[RFC6812]などがある。これらの方法は、ネットワークに侵襲的であり、間接的なネットワーク測定しか提供しない。IOAM[RFC9197]、代替マーキング(AM)[RFC8321]、マルチポイント代替マーキング[RFC8889]などのハイブリッド方式は、バランスのとれた、より柔軟なアプローチを提供する。ただし、これらの方法は実装が複雑になる。
• イン・バンドとアウト・オブ・バンド: データコレクタにエクスポートされる前のユーザ・パケットで運ばれるテレメトリ・データは、イン・バンドと見なされる(例: IOAM[RFC9197])。ユーザ・パケットを変更せずにデータ・コレクタに直接エクスポートされるテレメトリ・データは、アウト・オブ・バンドと見なされる(例えば、付録A.3.5で説明しているポストカード・ベースのアプローチ)。また、テレメトリ命令または部分的なデータのみがユーザ・パケットで運ばれるハイブリッド方式もある(例えば、AM [RFC8321]) 。
• エンド・ツー・エンドとネットワーク内: エンド・ツー・エンドの方法は、ネットワーク・エンド・ホストを始点とし、そこを終点とする(例: Ping)。ネットワーク内の方法はネットワーク内で動作し、エンド・ホストに対して透過的である。ただし、必要であれば、ネットワーク内の方法はエンド・ホストに簡単に拡張できる。
• データ対象: テレメトリの目的に応じて、フロー・ベース(例: IOAM[RFC9197])、パス・ベース(例: Traceroute)、ノード・ベース (例: IPFIX [RFC7011])などの方法がある。さまざまなデータ・オブジェクトは、パケット、フロー・レコード、測定値、状態、信号などがある。

3.1.4. 外部データ・テレメトリ

ネットワーク・システムの境界外で発生するイベントも、ネットワーク・テレメトリの重要なソースである。[NMRG-ANTICIPATED-ADAPTATION]で提示されているように、内部テレメトリ・データと外部イベントの両方をネットワーク・システムの要件と相関させることで、管理運用に戦略的かつ機能的な利点をもたらしてくれる。

他のテレメトリ・ソースと同様に、データとイベントは厳しい要件を満たさなければならない。特に、外部イベント情報をネットワーク管理アプリケーションに適切に組み込むために、即時性が不可欠である。具体的な課題は以下のとおりである。

• 外部イベント検出器の役割は、ハードウェア(例えば、地震計などの物理センサー)やソフトウェア(例: Twitterメッセージなどの情報ストリームを分析できるビッグデータ・ソース)など、複数の要素によって果たすことができる。したがって、送信されるデータはさまざまな形式をサポートする必要があるが、同時に、共通でありながら拡張可能なスキーマに従う必要もある。
• 外部イベント検出器の主な機能は通知を実行することなので、即時性は当然のことである。しかし、メッセージがディスパッチされた後は、迅速に収集され、重要なソースやイベントに対して高く、二次的なものに対しては低い優先度でコントロール・プレーンに挿入する必要がある。
• 外部検出器で使用されるスキーマは、現在および将来のデバイスやアプリケーションに容易に採用できなければならない。そのため、YANGなどの観点から、現在のデータ・モデルに容易にマッピングできなければならない。
• プロバイダのネットワーク境界外にある外部エンティティとの通信はインターネット上で実現する可能性があるため、この文脈では輻輳のリスクがさらに重要となり、適切な対策を講じる必要がある。ネットワーク・トランスポート・サーキットブレーカーなどのソリューションも必要である。

内部および外部のテレメトリ情報をまとめて整理することは、新しいハードウェアとソフトウェア(仮想)要素に認知機能を組み込むことに反映されるように、現在と将来のネットワーク・システムの管理可能性を全般的に活用するための鍵となる。

3.2. 第2レベルの機能コンポーネント

各プレーンのテレメトリ・モジュールは、さらに5つの異なる概念的コンポーネントに分割することができる:

• データ・クエリ、分析、保存: このコンポーネントは、図1のネットワーク運用アプリケーション・ブロックで動作する。通常は、受信側のネットワーク管理システムの一部である。その一方で、データ要件を発行する役割を担当する。対象となるデータは、構成にるモデル化データ、またはプログラミングによるカスタム・データである。データ要件は、単発のデータ・クエリ、またはイベントやストリーミング・データのサブスクリプションである。一方、ネットワーク・デバイスから返されたデータを受信、保存、処理も行う。データ分析は、さらなるデータ・クエリを開始するために対話的に行うこともできる。このコンポーネントは、ネットワーク・デバイスまたはリモート・コントローラのいずれかに配置できる。集中型または分散型とすることができ、1つ以上のインスタンスが含まれる。
• データ構成とサブスクリプション: このコンポーネントは、デバイス上のデータ・クエリを管理する。アプリケーションが目的のデータを取得するためのプロトコルとチャネルを決定する。このコンポーネントは、データソースから直接取得できない可能性のある目的のデータの構成も担当する。サブスクリプション・データは、モデル、テンプレート、またはプログラムで記述できる。
• データのエンコーディングとエクスポート: このコンポーネントは、アクセス制御を使用してデータ分析およびストレージ・コンポーネントにテレメトリ・データを配信する方法を決定する。データのエクスポート先によって、データのエンコーディングとトランスポート・プロトコルは異なる場合がある。
• データ生成と処理: 要求されたデータは、生データソースからネットワーク・デバイスでキャプチャ、フィルタリング、処理、フォーマットされる必要がある。これには、ネットワーク・デバイスの高速パスまたは低速パスでのネットワーク内コンピューティングと処理が含まれる場合がある。
• データ・オブジェクトとソース: このコンポーネントは、デバイスにプロビジョニングされた監視オブジェクトと元のデータソースを決定する。データソースは通常、さらなる処理が必要な生データを提供するだけである。各データソースはプローブと見なすことができる。データソースの中には動的にインストールできるものもあるが、静的なものもある。

図2: ネットワーク・テレメトリ・フレームワークのコンポーネント

3.3. データ取得メカニズムと型抽象化

大まかに言えば、ネットワーク・データはサブスクリプション(プッシュ)とクエリ(ポーリング)を通じて取得できる。サブスクリプションとは、パブリッシャとサブスクライバ間の契約である。初期設定後、サブスクリプションの有効期限が切れるまで、サブスクライブされたデータは登録されたサブスクライバに自動的に配信される。サブスクリプションには2つのバリエーションがある。サブスクリプションはあらかじめ定義しておくこともできれば、サブスクライバが特定のニーズに合わせて公開データを設定し、カスタマイズすることもできる。

これに対して、クエリは、クライアントがネットワーク・デバイスから即時かつ単発のフィードバックを期待する場合に使用される。クエリされたデータは、特定のデータソースから直接抽出されるか、生データから合成および処理される。クエリは、インタラクティブなネットワーク・テレメトリ・アプリケーションに適している。

一般的に、データは必要なときにいつでもプル(つまり、クエリ)できるが、多くの場合、データをプッシュ(つまり、サブスクリプション)する方が効率的であり、クライアントが変化を検出するまでの待ち時間を短縮できる。データ・コンシューマの観点では、テレメトリ・データ・コンシューマがサブスクライブまたはクエリできるネットワーク・デバイスのデータには以下の4つのタイプがある:

• シンプル・データ: ネットワーク・デバイス内のデータストアまたは静的プローブから安定して入手できるデータ。
• 派生データ: 1つ以上のネットワーク・デバイスから生データをネットワーク内で合成または処理する必要があるデータ。データ処理機能は、ネットワーク・デバイスに静的または動的にロードすることができる。
• イベントトリガ・データ: 何らかのイベントの発生を条件として取得されるデータ。イベントトリガ・データの例としては、インタフェースの動作状態がアップとダウンの間で変化するような場合が挙げられる。このようなデータは、サブスクリプションを通じてアクティブにプッシュすることも、クエリを通じてパッシブにポーリングすることもできる。イベントのモデル化には、有限ステートマシン(FSM)やイベント条件アクション(ECA)[NETMOD-ECA-POLICY]を使用するなど、さまざまな方法がある。
• ストリーミング・データ: 継続的に生成されるデータ。時系列データやデータベースのダンプなどがある。例えば、インタフェース・パケット・カウンタは1秒ごとにエクスポートされる。ストリーミング・データは、リアルタイムのネットワーク状態とメトリックを反映し、大きな帯域幅と処理能力を必要とする。ストリーミング・データは常にアクティブにサブスクライバにプッシュされる。

上記のテレメトリ・データのタイプは、相互に排他的ではない。むしろ、複合的な場合が多い。派生データは単純なデータで構成され、イベントトリガ・データは単純な場合も派生データの場合もあり、ストリーミング・データは何らかの反復的なイベントに基づく場合もある。これらのデータタイプの関係を図3に示す。

図3: データタイプの関係

通常、サブスクリプションは、イベントトリガ・データとストリーミング・データを扱い、クエリは単純なデータと派生データを対象とする。ただし、他の方法も可能である。高度なネットワーク・テレメトリ技術は、主にイベントトリガまたはストリーミング・データのサブスクリプションと派生データのクエリを対象として設計されている。

3.4. 既存のメカニズムをフレームワークにマッピングする

以下の表は、既存のメカニズム(主にIETFで公開され、最新のテクノロジーに重点を置いている)がフレームワーク内でどのように位置付けられているかを示している。膨大な既存の作業を考慮すると、網羅的なリストを提供することはできない。したがって、表中のメカニズムは単なる例として考えてほしい。また、包括的なプロトコルやテクニックの中には、フレームワークの複数の側面やモジュールをカバーしている場合があるため、ブロック内の名称は、個々の特性を強調しているに過ぎない。リストされているメカニズムの詳細については、付録Aを参照のこと。

	マネジメント・プレーン	コントロール・プレーン	フォワーディング・プレーン
データ構成とサブスクライブ	gNMI、NETCONF、RESTCONF、SNMP、YANG-Push	gNMI、NETCONF、RESTCONF、YANG-Push	NETCONF、RESTCONF、YANG-Push
データの生成と処理	MIB、YANG	YANG	IOAM、PSAMP、PBT、AM
データのエンコーディングとエクスポート	gRPC、HTTP、TCP	BMP、TCP	IPFIX、UDP

表2: 既存のタスク・マッピング

このフレームワークは一般的にあらゆるネットワーク環境に適しているが、マルチドメイン・テレメトリには、さらなるアーキテクチャの検討が必要ないくつかの固有の課題があり、それは本文書の範囲外である。

4. ネットワーク・テレメトリ・アプリケーションの進化

ネットワーク・テレメトリは進化を続ける技術分野である。ネットワークの運用が自動化に移行するにつれて、ネットワーク・テレメトリ・アプリケーションはいくつかの進化段階を経て、基盤となるネットワーク・テレメトリ技術に新たな要件が追加される。各段階は、前の段階で採用された技術と新たな要件を追加して構築される。

ステージ0 - 静的テレメトリ:
テレメトリ・データのソースとタイプは設計時に決定される。ネットワーク事業者は、その使用方方法を限られた柔軟性の範囲でしか設定できない。

ステージ1 - 動的テレメトリ:
カスタム・テレメトリ・データは、ネットワークの動作を中断することなく実行時に動的にプログラムまたは設定することができるため、リソース、パフォーマンス、柔軟性、およびカバレッジの間でトレードオフが可能になる。

ステージ2 - インタラクティブ・テレメトリ:
ネットワーク事業者は、ネットワーク運用における可視性の要件を反映させるために、テレメトリ・データをリアルタイムで継続的にカスタマイズし、微調整することができる。ステージ1と比較すると、リアルタイムのフィードバックに基づく変更が頻繁に行われる。この段階では、一部のタスクは自動化できるが、人間のオペレータが意思決定を行う必要がある。

ステージ3 - 閉ループ・テレメトリ:
レポートの作成を除いて、テレメトリは人間のオペレータの干渉を受けない。インテリジェントなネットワーク運用エンジンが自動的にテレメトリ・データの要求を発行し、データを分析し、閉ループ制御でネットワーク運用を更新する。

既存のテクノロジーはステージ0と1に対応している。ステージ2と3の個々のアプリケーションも現在可能である。しかし、将来的な自律型ネットワークでは、ネットワーク運用のすべてのタスクをカバーするために、ステージ2と3で動作する包括的な運用管理システムが必要になる可能性がある。明確に定義されたネットワーク・テレメトリ・フレームワークは、この方向への第一歩である。

5. セキュリティに関する考慮事項

ネットワーク・テレメトリの複雑性は、セキュリティに重大な影響を及ぼす。例えば、テレメトリ・データは、各プレーンおよびデータ・コンシューマのネットワーク・リソースを枯渇させるように操作される可能性がある。偽造または改ざんされたデータは、意思決定プロセスを誤らせ、ネットワークを麻痺させる可能性がある。また、テレメトリの誤った設定とプログラミングも同様に有害である。テレメトリ・データは非常に機密性が高く、ネットワークとその構成に関する多くの情報を公開してしまう。その情報の一部は、ネットワークに対する攻撃の設計を大幅に容易にする可能性がある(例えば、インストールされているソフトウェアとパッチの正確な詳細など)。また、攻撃者は、デバイスが保護されていないセキュリティ脆弱性の対象となる可能性があるかどうかを判断することができる。

本文書ではネットワーク・テレメトリのフレームワークを提案しており、ここで説明するテレメトリ・メカニズムは従来のネットワークOAMの概念よりも広範囲(メッセージ頻度とトラフィック量の両方)であるため、新しいセキュリティ上の考慮事項も生じる可能性も想定しなければならない。ネットワーク内のフォワーディング・プレーン、コントロール・プレーン、およびマネジメント・プレーンを保護するための手法はすでにいくつか存在するが、ネットワーク・テレメトリの手順やメカニズムの使用によって新たな脅威ベクトルが有効になっているかどうかを考慮することが重要である。

この文書では、ネットワーク・アプリケーションをサポートするために、さまざまなデータソースを収集、転送、分析するための概念的アーキテクチャを提案する。このフレームワークを実装するために選択されたプロトコル、データ形式、および構成によって、具体的なセキュリティ上の考慮事項を決定づける。これらの考慮事項には以下が含まれる:

• テレメトリ・フレームワークの信頼性とポリシー・モデル
• テレメトリ機能を有効化と無効化するためのロール管理とアクセス制御
• テレメトリ・データに使用されるプロトコル・トランスポートとその固有のセキュリティ機能
• テレメトリ・データの保存、保存データの暗号化、アクセス方法、および保持方法
• テレメトリ・インタフェースを使用して、悪意のある攻撃を特定するテレメトリ・イベントと異常の追跡
• データの信頼性を高めるためのテレメトリ・データの認証と整合性の保護
• テレメトリ・データ・トラフィックを、ネットワーク経由で伝送されるデータ・トラフィックから分離する(例えば、従来、管理アクセスと管理データは、独立した管理ネットワーク経由で伝送されることがある)

上記で強調したセキュリティ上の考慮事項のいくつかは、ネットワーク・テレメトリのポリシー管理によって最小限に抑えられるか、または無効にされる可能性がある。ネットワーク・テレメトリの展開では、テレメトリ機能をロール・ベースのアクセス制御やイベント条件アクションのポリシーなどの異なるポリシー・クラスに分離することが望ましい。また、ネットワーク・テレメトリ・メカニズム間の潜在的な競合を正確に検出し、迅速に解決しなければ、意図しないあるいは意図的なサービス拒否攻撃にエスカレートする不要なネットワーク・テレメトリ・トラフィックの伝播を回避することができない。

セキュリティ問題に関するさらなる研究が必要であり、ネットワーク・テレメトリ・システムとともにセキュリティ・メカニズムやプロトコルが開発され、展開されることが期待される。

6. IANAに関する考慮事項

本文書にIANAのアクションはない。

7. 参考文献

[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>.

[gpb] Google Developers, "Protocol Buffers", <https://developers.google.com/protocol-buffers>.

[grpc] gRPC, "gPPC: A high performance, open source universal RPC framework", <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-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>.

[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-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>.

[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>.

[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-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>.

[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-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>.

[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>.

[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>.

[RFC2981] Kavasseri, R., Ed., "Event MIB", RFC 2981, DOI 10.17487/RFC2981, October 2000, <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>.

[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>.

[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>.

[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>.

[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>.

[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>.

[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>.

[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>.

[RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, DOI 10.17487/RFC5424, March 2009, <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>.

[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>.

[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>.

[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>.

[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>.

[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>.

[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>.

[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>.

[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>.

[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>.

[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>.

[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>.

[RFC8084] Fairhurst, G., "Network Transport Circuit Breakers", BCP 208, RFC 8084, DOI 10.17487/RFC8084, March 2017, <https://www.rfc-editor.org/info/rfc8084>.

[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>.

[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>.

[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>.

[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>.

[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>.

[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>.

[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>.

[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>.

[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>.

[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>.

[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>.

[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>.

[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>.

付録A. 既存のネットワーク・テレメトリ技術に関する調査

この非規範的な付録では、各ネットワーク・テレメトリ・モジュールに対する既存の技術と標準提案の概要を示す。

A.1. マネジメント・プレーン・テレメトリ

A.1.1. NETCONFのプッシュ拡張

NETCONF[RFC6241]は、IETFが推奨する一般的なネットワーク管理プロトコルである。その主な強みは構成管理だが、データ収集にも利用できる。YANG -Push[RFC8639] [RFC8641]はNETCONFを拡張し、サブスクライバ・アプリケーションがYANGデータストアから継続的にカスタマイズされた更新ストリームを要求できるようにする。YANG構成および運用オブジェクトに加えられた変更の可視化を提供することで、構成および運用状態のリモート・ミラーリングに基づく新たな機能が可能になる。さらに、 UDPベースの公開チャネル[NETCONF-UDP-NOTIF]を介した分散データ収集メカニズム[NETCONF-DISTRIB-NOTIF]により、NETCONFベースのテレメトリの効率が向上する。

A.1.2. gRPCネットワーク管理インタフェース

gRPCネットワーク管理インタフェース(gNMI)[gnmi]は、 gRPC[grpc]リモート・プロシージャ・コール(RPC)フレームワークに基づくネットワーク管理プロトコルである。単一のgRPCサービス定義を1つ用意するだけで、構成とテレメトリの両方をカバーできる。gRPCは、 HTTP/2[RFC7540]に基づくオープンソースのマイクロサービス通信フレームワークである。ネットワーク・テレメトリに適した以下のような機能が多数用意されている:

• 全二重ストリーミング・トランスポート・モデル: バイナリ・エンコーディング・メカニズムと組み合わせることで、優れたテレメトリ効率を実現する。
• 一般的なHTTP/2ライブラリが通常提供しない、プラットフォーム間での高レベルの機能の一貫性。この特性は、テレメトリ・データ・コレクタが通常、さまざまなプラットフォーム上に存在するという事実にとって特に価値がある。
• 組み込みの負荷分散およびフェイルオーバー・メカニズム。

A.2. コントロール・プレーン・テレメトリ

A.2.1. BGP監視プロトコル(BMP)

BMP[RFC7854]はBGPセッションの監視に使用され、経路ビューを取得するための便利なインタフェースを提供することを目的としている。

BMP TCPセッションを設定することで、BGPルーティング情報が監視対象デバイスからBMP監視ステーションに収集される。BGPピアは、BMPピア・アップ通知とピア・ダウン通知によって監視される。BGP経路(Adj_RIB_In[RFC7854]、Adj_RIB_out[RFC8671]、およびローカルRIB[RFC9069]を含む)は、BMP経路監視メッセージと BMP経路ミラーリング・メッセージにカプセル化され、初期テーブル・ダンプとリアルタイムの経路更新の両方を提供する。さらに、BGP統計は、タイマー起動またはイベント駆動のいずれかのBMP統計レポート・メッセージを通じて報告される。今後のBMP拡張により、BGP監視アプリケーションがさらに強化される可能性がある。

A.3. データ・プレーン・テレメトリ

A.3.1. 代替マーキング(AM)技術

代替マーキング方式は、[RFC8321]および[RFC8889]で提示されているように、IPネットワークとオーバーレイ・ネットワークの両方でパケット損失、遅延、ジッタを効率的に測定することを可能にする。

この技術は、ポイント・ツー・ポイントおよびマルチポイント・ツー・マルチポイントのフローに適用できる。代替マーキングは、パケット・ヘッダの1ビット(またはラベル)の値を交互に変更することでパケットのバッチを作成する。これらのパケットのバッチはネットワーク上で明確に認識され、各バッチのパケット・カウンタを比較することでパケット損失を計算できる。同じ考え方を遅延測定に適用するには、遅延測定専用のマーキング・ビットを持つアドホックなパケットを選択する。

代替マーキング方式では、監視対象のフローごと、マーキング期間ごとの2つのカウンタが必要となる。例えば、n個の測定ポイントとm個の監視対象フローを考慮すると、各時間間隔のパケット・カウンタの桁数はn*m*2(各色に1つ)となる。

ネットワークは豊富なネットワーク・パフォーマンス測定データ(パケット・カウンタなど)を提供するため、従来のアプローチには限界がある。ボトルネックとなるのは、データの生成とエクスポート、およびネットワークから無理なく収集できるデータ量である。さらに、生成するデータの決定と構成に関連する管理タスクは、実装上の大きな課題につながる。

[RFC8889]で説明しているマルチポイント代替マーキングのアプローチは、この問題の解決と、詳細な分析が必要ではない場合のパフォーマンス監視の柔軟性向上を目的としている。

アプリケーションは、ネットワーク全体にわたるネットワーク・パフォーマンス測定タスクを調整し、最適な監視を可能にする。アプリケーションは、アプリケーションの要件に応じて、測定ポイントをどの程度大まかに、または正確に構成するかを選択できる。

代替マーキングを使用すると、ネットワーク・クラスタリング(ネットワーク全体の同じプロパティを保持するネットワークの一部であるサブネットワークは、クラスタと呼ばれる)を使用して、詳細な調査を行わずにマルチポイント・ネットワークを監視できる。したがって、パケット損失がある場合や遅延が大き過ぎる場合は、代替マーキングの文書[RFC8321]で説明されているように、フローごとの測定値まで異なるクラスタの組み合わせを使用して、特定のフィルタリング基準を適用して、より詳細な分析を行うことができる。

まとめると、アプリケーションはエンド・ツー・エンドのネットワーク監視を構成できる。ネットワークに問題が発生していない場合、この近似監視で十分であり、ネットワーク・リソースの面でも非常に安価である。ただし、問題が発生した場合、アプリケーションはこの近似監視から問題を認識し、問題のあるネットワーク部分を特定するために、測定ポイントをより広範囲に設定し、より詳細な監視を実行できるようにする。問題が検出されて解決された後、最初の近似監視を再び使用することができる。

A.3.2. 動的ネットワーク・プローブ

ハードウェア・ベースのダイナミック・ネットワーク・プローブ(DNP)[OPSAWG-DNP4IQ]は、アプリケーションがデータ・プレーンから収集するデータをカスタマイズするためのプログラム可能な手段を提供する。DNPの直接的な利点は、エクスポートされるデータの削減である。完全なDNPソリューションは、データソース、データ・サブスクリプション、データ生成など、いくつかのコンポーネントをカバーする。データ・サブスクリプションは、生のデータソースから構成および派生できる派生データを定義する必要がある。データ生成では、適度なネットワーク内コンピューティングを利用して、目的のデータを生成する。

DNPはデータ・プレーン・テレメトリに予期せぬ柔軟性をもたらす可能性があるが、同時にいくつかの課題にも直面している。実行時に動的に再プログラムできる柔軟なデータ・プレーンが必要である。アプリケーション・プログラミング・インタフェース(API)のプログラミングはまだ定義されていない。

A.3.3. IPフロー情報エクスポート(IPFIX)プロトコル

ネットワーク上のトラフィックは、ネットワーク・エレメントを通過する一連のフローとしてみなすことができる。IPFIX[RFC7011]は、管理またはその他の目的でトラフィック・フロー情報を伝送する手段を提供する。典型的なIPFIX対応システムには、1つ以上の観測ポイントでデータ・パケットを収集し、必要に応じてフィルタリングし、それらのパケットに関する情報を集約するメータリング・プロセスのプールが含まれる。次に、エクスポータが各観測ポイントをまとめて観測ドメインに集め、その情報をIPFIXプロトコル経由でコレクタに送信する。

A.3.4. In Situ OAM

従来のパッシブおよびアクティブな監視および測定技術は不正確か、リソースを消費する。パケットがネットワークを通過するときに、フローのパケットに関連付けられたデータを直接取得することが望ましい。データ生成技術であるIOAM[RFC9197]は、ユーザ・パケットに新しい命令ヘッダを埋め込み、その命令は要求されたデータをパケットに追加するようにネットワーク・ノードに指示する。したがって、パスの終端で、転送パス全体で得られたパケットの経験を収集することができる。このような直接的なデータは、多くのネットワークOAMアプリケーションにとって非常に貴重である。

しかし、IOAMにはいくつかの課題もある。パフォーマンスへの影響、セキュリティ、スケーラビリティとオーバーヘッドの限界、一部のプロトコルにおけるカプセル化の難しさ、クロスドメイン展開などの問題に対処する必要がある。

A.3.5. ポストカード・ベースのテレメトリ

IOAMダイレクト・エクスポート(DEX)[IPPM-IOAM-DIRECT-EXPORT]およびIOAMマーキング[IPPM-POSTCARD-BASED-TELEMETRY]で具体化されているポストカード・ベースのテレメトリは、パスポート・ベースのIOAM[RFC9197]を補完する技術である。PBTは、各ノードで独立したパケットを通じてデータを直接エクスポートする。帯域幅のオーバーヘッドが大きくなり、データの相関が必要になるという代償はあるが、PBTにはいくつかのユニークな利点がある。また、パケットが転送パス上でドロップした場合に、パケット・ドロップの場所を特定するのにも役立つ。

A.3.6. 特定のデータ・プレーンに対する既存のOAM

さまざまなデータ・プレーンでは、独自のOAM要件が発生する。IETFは、マルチプロトコル・ラベル・スイッチング(MPLS)、L2仮想プライベート・ネットワーク(VPN)、レイヤ3上のネットワーク仮想化(NVO3) 、仮想拡張LAN(VXLAN)、ビット・インデックス明示的レプリケーション(BIER)、サービス機能連鎖(SFC)、セグメント・ルーティング(SR)、決定論的ネットワーク(DETNET)など、さまざまなデータ・プレーンを対象としたOAM技術とフレームワークの文書(例: [RFC8924]および[RFC5085]) を公開している。前述のデータ・プレーンのテレメトリ技術は、このようなデータ・プレーンのOAM機能を強化するために使用できる。

A.4. 外部データとイベントのテレメトリ

A.4.1. 外部イベントのソース

外部イベント検知器によって提供され、ネットワーク管理ソリューションによって使用される情報が、管理目的にとって意味のあるものになるようにするには、ネットワーク・テレメトリ・フレームワークで、そのような検知器(ソース)が管理ソリューション(受信側)に簡単に接続できるようにする必要がある。そのためには、ネットワーク管理に関係する可能性のある外部データソースのリストを指定し、それらを接続するために必要なコネクタやインタフェースとマッチングさせる必要がある。

ネットワーク管理に関係する可能性のある外部イベント・ソースのカテゴリには、以下のものがある:

• スマート・オブジェクトとセンサー。モノのインターネット(IoT)の統合により、あらゆるネットワーク・システムは、その物理的な環境と論理的な操作環境に、多くのスマート・オブジェクトを取り付けるようになっている。これらのオブジェクトのほとんどは、本来さまざまなタイプのセンサー(温度、湿度、存在など)に基づいており、それらが提供する情報はそのような目的のために特別に展開されていない場合でも、ネットワークの管理に非常に役立つ可能性がある。このソース・タイプの要素は通常、相互作用のための特定のプロトコル、特に制約付きアプリケーション・プロトコル(CoAP)などのIoTに関連するプロトコルを提供する。
• オンライン・ニュース・レポータ。いくつかのオンライン・ニュース・サービスは、世界で起きているさまざまなイベントに関する膨大な情報を提供する能力を持っている。これらのイベントの中には、個々のフレームワークが管理するネットワーク・システムに影響を与えるものもある。したがって、このような情報は管理ソリューションにとって関心が高いかもしれない。例えば、CVE(Common Vulnerabilities and Exposures)のようなさまざまなセキュリティ・レポートは、対応する機関によって発行され、必要に応じて管理ソリューションが管理対象システムを更新するために使用することができる。この種の情報源は、特定のプロトコルやデータ形式ではなく、通常、緩やかだが構造化された形式に従っている。この形式は、テレメトリ・フレームワークのオントロジーと情報モデルの一部になる。
• グローバル・イベント・アナライザ。ビッグデータ・アナライザの進歩により、膨大な量の情報と、さらに興味深いことに、さまざまなソースからの多くのデータ・ストリームを分析することによって検出されたイベントの識別を可能にする。特定のイベントに焦点を当てた他のタイプのソースとは対照的に、このソース・タイプの検出器は一般的なイベントを検出する。例えば、スポーツ・イベント中に予期しない動きが起こり、多くの人がイベントをレポートしているサイトに接続する。イベントをカバーするサービスをサポートする基盤となるネットワークは、そのような状況の影響を受ける可能性があるため、管理ソリューションはそれを認識する必要がある。他のソースタイプとは対照的に、このタイプの検出器を管理ソリューションと統合するには、新しい情報モデル、形式、およびレポート・プロトコルが必要である。

追加の検出器タイプをシステムに追加することもできるが、通常はこれらの主なクラスが提供するプロパティを組み合わせた結果となる。

A.4.2. コネクタとインタフェース

外部のイベント検出器を他の管理ソリューションと適切に統合されるようにするには、両方の要素がそれぞれの目的に応じたインタフェースとプロトコルを公開しなければならない。外部イベント検出器は、一般にネットワーク管理ソリューションに限定されないコンシューマに情報を提供することに重点を置くため、フレームワークは、検出器(ソース)と管理システム内のコンシューマ(受信側)間の相互接続が効果的であることを保証するために必要なコネクタの定義が含まれていなければならない。

状況によっては、外部イベント検出器と管理システム間の相互接続は、マネジメント・プレーンを介して行われる。このような状況では、マネジメント・プレーンに接続される他のほとんどの要素に見られる一般的なインタフェースを提供する特別なコネクタが存在する。例えば、インタフェースは、データ・モデル(YANG)、NETCONF、YANG-Push、gRPCのような、固有のテレメトリ・プロトコルを使用して実現することができる。

謝辞

この文書を改善するために有益なコメントや提案を提供してくれたロブ・ウィルトン、グレッグ・ミルスキー、ランディ・プレスーン、ジョー・クラーク、ビクター・リウ、ジェームズ・ギシャール、ユリ・ブルーメンソール、ジュゼッペ・フィオッコラ、ユナン・グー、パルヴィズ・イェガーニ、ヤング・リー、チン・ウー、ギャン・ミシュラ、ベン・シュワルツ、アレクセイ・メルニコフ マイケル・シャーフ、ドゥルヴ・ドディ、マーティン・デューク、ローマン・ダニリウ、ウォーレン・クマリ、シェン・ジアン、ラース・エガート、エリック・ヴィンケ、ジャン・ミッシェル・コンブ、エリック・クライン、ベンジャミン・カドゥクらに感謝する。

寄稿者

本文書の他の貢献者は、ティエンラン・ジョウ、ジェンビン・リー、ジェンチャン・リー、ダニエル・キング、エイドリアン・ファレル、アレクサンダー・クレムである。

著者のアドレス

ハオユ・ソン
Futurewei
アメリカ合衆国
メール・アドレス: [e-mail]

フェンウェイ・チン
China Mobile
中国
メール・アドレス: [e-mail]

ペドロ・マルティネス・フリア
NICT
日本
メール・アドレス: [e-mail]

ローラン・シアヴァリア
Rakuten Mobile
フランス
メール・アドレス: [e-mail]

アイジュン・ワン
China Telecom
中国
メール・アドレス: [e-mail]

更新履歴

• 2024.10.21
• 2024.10.27
• 2024.10.31