In-band Network Telemetryとは

In-band Network Telemetryとは？

データプレーンを活用したTelemetry技術

In-band Network Telemetryを語る前に、、、
まずベーシックなStreaming Telemetryの理解がある前提で話を進める。
そもそもTelemetryってなんぞやという方は以下記事から先に参照ください。

In-band Network TelemetryとはIn-bandと表現している通り、データプレーンのヘッダー部にTelemetryデータをカプセル化する技術。

NTT P4ユーザ会資料を引用

データプレーンのヘッダ部にINT情報を格納するカプセル化を行う
INT対応ルータが必要

なにわリーマンゆうき

INTヘッダを読み取って、それに基づく応答を返すとなると、

Streaming Telemetryと違って読み取りから応答までの処理遅延が気になるな

なにわリーマンゆうき

事前に応答内容を知っているから

低負荷で動作出来てたけど、これ大丈夫なのか？

なにわリーマンゆうき

INT使ったら通信性能（主にレイテンシ）劣化しないか？

訳わからなくなってきたぞー！

NTT P4ユーザ会資料を引用

SourceノードはINTで取得する情報を規定
中継ノードはSourceで規定された指示に従いINTデータを追加していく
Sinkノードはデータプレーンに付加されたINT情報を取り除く
（転送先にデータプレーンにINTデータが付加されたままはまずいので、後処理として綺麗にしておく）

なにわリーマンゆうき

Streaming Telemetryでノードに

事前設定したData Modelが

INTヘッダに書かれているイメージね。

なにわリーマンゆうき

受け取ったデータプレーンのINTヘッダを読み取って、

次のノードはアウトプットしたいデータを追記していく

イメージですね。

INTはデータプレーンに影響を及ぼすのか？

INTの動作のポイントおさらいは以下の通り。

INTはデータプレーンにNEへの要求指示を組み込む
NEはINTヘッダを参照して、要求に応じた返答をする
Streaming Telemetryのメリット（事前に要求を知っていて、定型処理を続けるのみ）が帳消しされる

なにわリーマンゆうき

結局INTはTelemetryの良さを帳消しにする悪手なんじゃないの？

実際、INT対応ルータはまだ少ない状況。確かに実装状況によっては、高スペックなルータが必要になる可能性もあるが、それだとTelemetryの旨味がないことはベンダも理解している。
何より、データプレーンの通信自体へ影響が出ると本末転倒なので、そうならない作り込みを検討している。

種類	実装	処理速度
M-Plane	CPU	遅い
C-Plane	CPU	遅い
D-Plane	ASIC,FPGA等のハードウェア	高速

M/C/Dプレーンについて

今回のINTだとCPU処理の機構まで処理を委託してしまうと処理遅延がかなり大きく影響してしまうため、D-Plane処理のASIC、FPGAのハードウェア部でプログラマブルな領域を設けて処理遅延が乗らないような実装がされているらしい。

なにわリーマンゆうき

各社馬鹿じゃ無いから工夫はしているけど、本来機械的な処理をさせて安価かつ高速で実装できていた部分にメスを入れる形になるから、Telemetryの高速で軽いメリットはやはりINTでは失われているね。

INTはデータプレーン影響が出ないような作り込みがされている　
データプレーン処理のASIC、FPGA処理部に少し手を加えることで遅延影響が出るCPU処理を避けるアーキテクチャが考えられている。

In-band Telemetryは本当に使えない技術なのか？

Streaming Telemetryの特徴のおさらい

あらかじめコレクタ側でノード側へ収集項目を事前通知しておく
ノード側は決められた要求に対する解答を淡々と解答し続ける

In-band Network Telemetryの特徴のおさらい

データプレーンのヘッダ部にINT用領域を設け、そこにノードへの指示を組み込む　
ノードはデータプレーンのパケットを読み取った際INTヘッダ領域の指示を確認し、指示に応じた応答をINTヘッダ領域に追記して隣接ノードへ転送する。

「Streaming Telemetry」はPush型に対して、INT(In-band Network Telemetry)はSNMPに近い指示待ち型の動作になる。

一方で、INTの動作として、「データプレーンを処理する過程で各種ノードの情報を集めれる」というところがINTの最大の特徴になる。

データプレーン一緒にノード情報が集めれる特徴を活かした例

前提情報

ユーザA→ユーザBへ通信する
上周りルート（1→2→4）と下周りルート（1→3→4）は同一コストでロードバランス(ECPM:Equal Cost Multi Path)される

やりたいこと

ユーザ通信におけるネットワーク区間での遅延測定

INTが使えない場合

保守端末からノード１に入りノード４までの遅延測定パケット（ping等）にて遅延時間を測定する。

この場合、ユーザ通信（赤色）が下周りルートで流れたとして、遅延測定パケット（青色）がロードバランスされユーザ通信と異なる上周りルートになる可能性がある。
実際のユーザ通信とは異なるルートの測定になってしまう虞がある。

INTが使える場合

INTでは各々のノードのTimeStamp情報を付加するようにINTヘッダへ指示を組み込むことで、流れたパケットがノードに届いたタイミングでその時の時間を追記していくことができる。
コレクタへの情報の渡し方は大別して2種類あるが、図の例はPostCardモードの例。

実際の流れているパケットの到着時刻がリアルに観測可能。

なにわリーマンゆうき

INTが使えない場合で仮に同一ルートになったとして・・・

ネットワークは時事刻々とユーザ通信量は変化しているため

マイクロバーストのような影響を後から

遅延測定パケットで測っても観測することはできない。

INTはデータプレーンのパケットが流れた生の状態を観測可能　
ノード単体の情報収集は不向き。
NW全体で流れるパケットの動きの観測に特化

本題のJANOG発表内容について

In-band Telemetry-データプレーンの遅延時間観測-

ここまで前段情報がかなり長かったけど、ここからがようやく本題です。

今回のARISTAの土屋さんの内容をまとめると以下になります。

そもそもテレメトリーとは？　（←超ざっくり）
ARISTAのStreaming Telemetryコレクタ（Vendor Nativeの方）の製品紹介（←広告）
INTでの可視化

なにわリーマンゆうき

上２つはTelemetry知ってるよの人向けに書いた触りになっているので、

そもそもTelemetryって何ぞやという方は自分の記事で内容確認しよう。

JANOG資料：-In-band Telemetry -データプレーン遅延時間観測-
JANOG より引用

INTでの遅延情報収集手段について

コレクタが情報を収集する手段はパスポートモードとポストカードモードの２種類存在します。

PassPortモード

PassPortモードでは大別して以下の役割毎の動きをすることでコレクタへ情報を集める。

Source：コレクタへ予定の各ノードから取りたい情報の指示をINTヘッダへつける
Transport:INTヘッダの指示内容に応じてINTヘッダのデータ格納領域へ自身の情報を追記する
Sink：転送されてきたINTヘッダ情報をデータプレーンから取り除き、自分の情報を追記したレポートをコレクタへ出力する

なにわリーマンゆうき

PassPortモードは最後にSource君がコレクタにまとめて提出するよ

PostCardモード

PassPortモードでは大別して以下の役割毎の動きをすることでコレクタへ情報を集める。

Source：取りたい情報の指示をINTヘッダへつける +自身のレポートを個別でコレクタへ出力
Transport:INTヘッダの指示内容に応じて自身のレポートを個別でコレクタへ出力
Sink：転送されてきたINTヘッダ情報をデータプレーンから取り除き、自身のレポートを個別でコレクタへ出力

なにわリーマンゆうき

Postcardモードはレポートは個別で上げていくスタイル

ARISTAが実現したこと

遅延データとNWトポロジーのマッピング

実際に流れたデータプレーンの遅延時間をGUIのトポロジー画面に重ねて表示する

なにわリー
マンゆうき

こんな感じで遅延時間が遅いところが視覚的に確認できるみたい。

なにわリーマンゆうき

GUI可視化ツール（OSS:Kibana,Grafana等）を使えば、

ベンダ製品を使わなくても同じようなことは出来るよ！

ノードマッピングまでは作り込みな気がするので、

トポロジー図に描画出来ているというのが、

ARISTAのPRポイントなのかな？

トラフィックフローとINTの関連付け

フロー情報別に遅延時間を表示する

Source	Dst	最大遅延時間(msec)	最小遅延時間(msec)	平均遅延時間(msec)
10.10.10.x	10.10.11.x	1000	20	100
10.10.11.x	10.10.11.x	100	10	50
10.52.10.x	10.10.11.x	30	5	10
10.56.22.x	10.10.11.x	50	5	20

トラフィックフローとの関連づけ

なにわリーマンゆうき

データプレーンの情報から宛先情報等が分かるので、

それと遅延データを組み合わせたマッピング表や、

いろいろな組み合わせでの表示が出来るみたい。

なにわリーマンゆうき

特定の宛先やプロトコル単位での遅延を分析したり

保守者としてはデータ分析には持ってこいの情報が取れるな！

JANOG会場での議論模様

Q:ASICのQueueの取得をする場合HW依存ないのか？（KDDI総合研究所　M様

* A:ASIC自身はパケット処理しているので知っている。
　トライデント、ジェリコとか有名どころは見れる。
　それを見るためのSWをベンダが実装しているかが問題。
　AgentがASICのカウンタを見る実装をしているのかが問題です。

Q:INTでレポート出来る情報、コレクタ側で受け取れる情報はベンダ色が強いのか？受け側はOSSで実装できるのか？（LINE　S様

* A:INTはRT側のサポート対応が必須なので、ベンダ色が強い。
　OPENConfigで定義されたものしかマルチベンダーでは出来ない。
　OSSでやりたいのは理解するが、Telemetlyの良さはトポロジとかと組み合わせるのが大事。
　OSSでそこまで出す人が居ないと思う。マッピング実装まで綺麗にこだわってやってくれる
　善人はどこまでいるのかな？