Loading article…
ネットワーク構成プロトコル（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年代後半にSimple Network Management Protocol （SNMP）を開発し、これは非常に人気のあるネットワーク管理プロトコルとなりました。21世紀初頭には、当初の意図とは異なり、SNMPはネットワーク機器の設定には使用されず、主にネットワーク監視に使用されていることが明らかになりました。2002年6月、インターネットアーキテクチャ委員会とIETFのネットワーク管理コミュニティの主要メンバーは、ネットワークオペレーターと集まり、この状況について話し合いました。この会議の結果はRFC 3535に文書化されています。各ネットワークオペレーターは、主に独自のコマンドラインインターフェイス（CLI）を使用してデバイスを設定していることが判明しました。このCLIには、BERエンコードされたSNMPとは異なり、テキストベースであるなど、オペレーターが好む多くの機能がありました。さらに、多くの機器ベンダーは、SNMPを介してデバイスを完全に設定するオプションを提供していませんでした。オペレーターは一般的に、機器の管理に役立つスクリプトを作成することを好むため、SNMP CLIには多くの点で不十分だと感じていました。最も顕著な点は、出力の予測不可能性であった。出力の内容と形式は、予測不可能な形で変化しやすかった。
ほぼ同時期に、ジュニパーネットワークスはXMLベースのネットワーク管理手法を採用していました。この手法はIETFに持ち込まれ、より広範なコミュニティに共有されました。これら2つの出来事がきっかけとなり、IETFは2003年5月にNETCONFワーキンググループを設立しました。このワーキンググループは、ネットワーク事業者や機器ベンダーのニーズにより合致するネットワーク構成プロトコルの開発に取り組むことになりました。NETCONF基本プロトコルの最初のバージョンは、2006年12月にRFC 4741として公開されました。その後、いくつかの拡張機能が公開されました（2008年7月のRFC 5277の通知、2009年12月のRFC 5717の部分ロック、2011年6月のRFC 6243のwith-defaults、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モデリング言語との互換性に取り組むために再編成された。
基本プロトコルでは、以下のプロトコル操作を定義します。
NETCONF の基本機能は、NETCONF 機能の定義によって拡張できます。実装がサポートする追加のプロトコル機能のセットは、セッション設定の機能交換部分でサーバーとクライアント間で通信されます。必須のプロトコル機能は、当然のこととして想定されているため、機能交換には含まれません。RFC 4741 では、 : xpathや :validate など、いくつかのオプション機能が定義されています。なお、 RFC 6241 はRFC 4741 を廃止しています。
非同期イベント通知の購読と受信をサポートする機能は、RFC 5277で公開されています。この文書では、リアルタイムおよびリプレイ購読を作成できる<create-subscription>操作を定義しています。通知は、<notification>構文を使用して非同期で送信されます。また、基本的な:notification機能と併用することで、購読がアクティブな間に他のNETCONF操作の処理を容易にする:interleave機能も定義しています。
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で定義されています。