
ネットワーク構成プロトコル(NETCONF)は、IETFによって開発・標準化されたネットワーク管理プロトコルです。NETCONFワーキンググループ[ 1 ]で開発され、2006年12月にRFC 4741 [ 2 ]として公開されました。その後、2011年6月に改訂され、RFC 6241 [ 3 ]として公開されました。NETCONFプロトコル仕様は、インターネット標準化過程の文書です。
NETCONFは、ネットワークデバイスの設定をインストール、操作、削除するためのメカニズムを提供します。その操作は、シンプルなリモートプロシージャコール(RPC)層上で実現されます。NETCONFプロトコルは、設定データとプロトコルメッセージに拡張マークアップ言語(XML)ベースのデータエンコーディングを使用します。プロトコルメッセージは、安全なトランスポートプロトコル上で交換されます。
NETCONF プロトコルは概念的に 4 つの層に分割できます。
NETCONFプロトコルは、大手機器ベンダーによってルーターやスイッチなどのネットワークデバイスに実装されています。NETCONFの大きな強みの一つは、複数のデバイスにまたがるトランザクションを用いた堅牢な設定変更をサポートしていることです。
IETFは1980年代後半に簡易ネットワーク管理プロトコル(SNMP)を開発し、非常に普及したネットワーク管理プロトコルであることが証明されました。21世紀初頭、当初の意図に反して、SNMPはネットワーク機器の設定には使用されず、主にネットワークの監視に使用されていることが明らかになりました。2002年6月、インターネットアーキテクチャ委員会とIETFのネットワーク管理コミュニティの主要メンバーは、ネットワークオペレータと集まり、状況について話し合いました。この会議の結果はRFC 3535に文書化されています。各ネットワークオペレータは、デバイスの設定に主に異なる独自のコマンドラインインターフェイス(CLI)を使用していることが判明しました。これには、 BERエンコードされたSNMPではなくテキストベースであるなど、オペレータが好む機能がいくつかありました。さらに、多くの機器ベンダーは、SNMPを介してデバイスを完全に設定するオプションを提供していませんでした。オペレータは一般的にボックスの管理を支援するスクリプトを作成することを好んでいたため、SNMP CLIにはいくつかの点で欠陥があることに気付きました。最も顕著だったのは、出力の予測不可能な性質でした。出力の内容とフォーマットは、予期せぬ形で変化する傾向がありました。
ジュニパーネットワークスは、この頃、XMLベースのネットワーク管理アプローチを採用していました。このアプローチはIETFに持ち込まれ、より広範なコミュニティと共有されました。これら2つの出来事が重なり、2003年5月にIETFはNETCONFワーキンググループを設立しました。このワーキンググループは、ネットワーク事業者と機器ベンダーのニーズにより合致するネットワーク構成プロトコルの開発に取り組むことになりました。NETCONFの基本プロトコルの最初のバージョンは、2006年12月にRFC 4741として公開されました。その後、いくつかの拡張が公開されました(通知は2008年7月にRFC 5277、部分ロックは2009年12月にRFC 5717、デフォルト付きプロトコルは2011年6月にRFC 6243、システム通知は2012年2月にRFC 6470、アクセス制御は2012年3月にRFC 6536で公開されました)。基本 NETCONF プロトコルの改訂版は、2011 年 6 月に RFC 6241 として公開されました。
NETCONFオペレーションの内容は整形式XMLです。ほとんどの内容はネットワーク管理に関連しています。その後、 JavaScript Object Notation (JSON)でのエンコードのサポートも追加されました。
NETMODワーキンググループは、運用データ、構成データ、通知、および操作のセマンティクスを定義するための「人間に優しい」モデリング言語であるYANGの定義作業を完了しました。YANGはRFC 6020(バージョン1)およびRFC 7950(バージョン1.1)で定義されており、RFC 6991に記載されている「共通YANGデータ型」が付属しています。
2010 年の夏、NETMOD ワーキング グループは、コア構成モデル (システム、インターフェイス、ルーティング) の作業と、SNMPモデリング言語との互換性の作業を行うために再任命されました。
基本プロトコルは、次のプロトコル操作を定義します。
| 手術 | 説明 |
|---|---|
| <取得> | 実行中の構成とデバイスの状態情報を取得する |
| <get-config> | 指定された構成データストアの全部または一部を取得します |
| <編集設定> | コンテンツを作成、削除、マージ、または置換して構成データストアを編集します |
| <コピー設定> | 構成データストア全体を別の構成データストアにコピーする |
| <設定を削除> | 構成データストアを削除する |
| <ロック> | デバイスの構成データストア全体をロックする |
| <ロック解除> | <lock> 操作で以前に取得した構成データストアのロックを解除します。 |
| <セッション終了> | NETCONFセッションの正常な終了を要求する |
| <セッションを終了> | NETCONFセッションを強制的に終了する |
NETCONFの基本機能は、NETCONF機能の定義によって拡張できます。実装がサポートする追加のプロトコル機能は、セッションセットアップにおける機能交換の際に、サーバーとクライアント間で通信されます。必須のプロトコル機能は、前提とされているため、機能交換には含まれません。RFC 4741では、: xpathや:validateなど、いくつかのオプション機能が定義されています。なお、RFC 6241はRFC 4741を廃止するものです。
非同期イベント通知のサブスクライブと受信をサポートする機能は、RFC 5277 で公開されています。このドキュメントでは、リアルタイムサブスクリプションとリプレイサブスクリプションの作成を可能にする <create-subscription> オペレーションを定義しています。通知は <notification> 構造を使用して非同期的に送信されます。また、:interleave 機能も定義されています。この機能は、基本の :notification 機能と併用することで、サブスクリプションがアクティブな間に他の NETCONF 操作の処理を容易にします。
実行コンフィギュレーションの部分的なロックをサポートする機能は、RFC 5717で定義されています。これにより、複数のセッションで実行コンフィギュレーション内の重複しないサブツリーを編集できるようになります。この機能がない場合、ロックできるのはコンフィギュレーション全体のみです。
NETCONFプロトコルを監視する機能は、RFC 6022で定義されています。このドキュメントには、NETCONFデータストア、セッション、ロック、統計情報に関する情報を含むデータモデルが含まれており、NETCONFサーバーの管理を容易にします。また、NETCONFクライアントがNETCONFサーバーでサポートされているデータモデルを検出するための方法と、それらを取得するための<get-schema>操作も定義されています。
NETCONFメッセージ層は、エンコードのためのシンプルでトランスポートに依存しないフレーミングメカニズムを提供します。
すべてのNETCONFメッセージは整形式のXMLドキュメントです。RPCの結果は、message-id属性によってRPC呼び出しにリンクされます。NETCONFメッセージはパイプライン化できます。つまり、クライアントはRPCの結果メッセージを待つことなく、複数のRPCを呼び出すことができます。RPCメッセージはRFC 6241で定義されており、通知メッセージはRFC 5277で定義されています。