# gNMI gNMI (gRPC Network Management Interface) は、OpenConfig が積極的に推進するネットワーク管理インターフェースであり、[[YANG]] ベースの OpenConfig モデルへの読み書き・購読を gRPC(その下層の HTTP/2)上で行う。データの specify にも Protocol Buffers を採用する。NETCONF も post-SNMP プロトコルの一つとして残るが、著者らは gNMI の方が業界の支持を集めていると評価し、管理プロトコルの未来として本書で強調する。(Source: [[@2021__SystemsApproach__Software-Defined Networks - A Systems Approach - Chapter 5 Switch OS]] ch.5 §5.3) ## 背景: MIB/SNMPからの移行 ネットワーク機器の構成・運用における中核的な課題は、オペレータが `GET`/`SET` できる変数の辞書を、デバイス間で統一(ベンダー非依存)された形で定義することである。インターネットは SNMP と組み合わせて使う Management Information Base (MIB) という形で、既に数十年がかりでこの辞書の定義を経験しているが、MIB は構成変数の書き込みよりも読み取りに重きを置いており、書き込みは歴史的に機器の CLI で行われてきた。SDN への移行は業界をプログラマティックな構成 API のサポートへ後押しし、これが gNMI・YANG・OpenConfig という新しい情報モデルの土台になっている。(Source: ch.5 §5.3) ## OpenConfig のモデル構造 OpenConfig はオブジェクトタイプの階層を定義する。各インターフェースは書き込み可能な構成状態(`rw`)と読み取り専用の運用状態(`ro`、クライアント側から見て読み取り専用)を持つ。このベースモデルは拡張可能であり、例えば Ethernet インターフェース向けの `mac-address`・`auto-negotiate`・`duplex-mode`・`port-speed`・`enable-flow-control` などのフィールドを追加した `openconfig-if-ethernet` が定義される。同様の拡張はリンクアグリゲーション・IP アドレス割り当て・VLAN タグなどにも定義され得る。宣言的な構成状態(`rw`)と実行時フィードバック状態(`ro`)の区別は、ネットワーク機器インターフェースに共通する基本的な性質であり、OpenConfig は特に後者をオペレータが追跡すべきネットワークテレメトリデータまで一般化することに注力する。(Source: ch.5 §5.3) ## gRPC メソッドとツールチェーン gNMI はこれらのモデルを操作する特定の gRPC メソッド群を定義する。protobuf 仕様上では `Service gNMI` として、`Capabilities`(デバイスがサポートするモデル定義の集合を取得する)・`Get`/`Set`(モデルで定義された変数を読み書きする)・`Subscribe`(デバイスからのテレメトリ更新のストリームを設定する)の4メソッドが集合的に定義される。特定のフィールドはデータモデルツリー内の完全修飾パス名で指定される。YANG ツールチェーンは、YANG ベースの OpenConfig モデルを client 側・server 側の gRPC スタブへ変換する。このツールチェーンは複数のターゲット言語をサポートし([[Stratum]] は C++ を使う)、gRPC のクライアント側とサーバ側は同じ言語で書かれる必要はない。YANG は gRPC や gNMI に縛られるものではなく、同じ OpenConfig モデルから XML や JSON 表現を生成し、NETCONF や RESTCONF で使うこともできる。(Source: ch.5 §5.3) ## Stratum が追跡するモデル範囲 Stratum のような Switch OS は OpenConfig モデルの全範囲を扱う必要はない。集権型コントローラをサポートする Switch OS として、Stratum はデータプレーンの諸側面を構成することには関心を持つが、BGP のようなコントロールプレーンプロトコルの構成には通常関与しない(SDN ベースのソリューションではこうしたプロトコルはもはやスイッチ上に実装されない)。具体的には、Stratum が追跡する OpenConfig モデルは Interfaces・VLANs・QoS・LACP(リンクアグリゲーション)、およびシステム・プラットフォーム変数群(ファン回転数がその定番の例)である。(Source: ch.5 §5.3) ## gNOI: 運用インターフェースとしての対 gNOI はネットワーク機器の運用インターフェースであり、その基盤機構は gNMI と全く同じである。一般に、永続的な状態は gNMI が扱い(対応する YANG モデルが定義される)、一時的な状態のクリア・設定は gNOI が扱う。reboot や ping のような非冪等な操作も gNOI の管轄に入る傾向がある。両者は密接に連携しており、まとめて gNXI と呼ばれる。gNOI の用途を示す例として、`System` サービスの protobuf 仕様には `Ping`・`Traceroute`・`Time`・`SetPackage`・`Reboot` などの RPC が定義され、`RebootRequest` メッセージは再起動方式(`COLD`・`POWERDOWN`・`HALT`・`WARM`・`NSF` など)・遅延時間・理由メッセージ・対象サブコンポーネント・サニティチェック失敗時の強制実行フラグを持つ。(Source: ch.5 §5.3) ## 関連 - [[YANG]] — gNMI が読み書きするデータモデルのモデリング言語 - [[Stratum]] — gNMI を主要ノースバウンドインターフェースの一つとして公開する Thin Switch OS - [[P4Runtime]] — Stratum が公開するもう一つの主要インターフェース(フォワーディング制御)。gNMI は構成担当という役割分担 - [[ネットワーク自動化]] — YANG/OpenConfig によるモデル駆動の構成管理という文脈 - [[@2021__SystemsApproach__Software-Defined Networks - A Systems Approach - Chapter 5 Switch OS]] ## 出典 - Peterson, Cascone, O'Connor, Vachuska, and Davie, *Software-Defined Networks: A Systems Approach*, 2021, Chapter 5: Switch OS, §5.3. https://sdn.systemsapproach.org/stratum.html