NETCONF

NETCONFプロトコルは、大きく四つの層に分けられる[2]。

メッセージを転送するためのプロトコルを規定した層である。RFC 6241 ではこの層については要件のみが規定され、特定のプロトコルには依存しない形になっている。SSH[3]、TLS[4]、SOAP[5]、BEEP[6]などの利用が想定されている。

NETCONFのRPCメッセージはXMLにコード化されてやり取りされる[7]。そのコード化方法を規定した層である。クライアントからのRPCリクエストは<rpc>要素を、サーバからのレスポンスは <rpc-reply>(エラーのときは<rpc-error>)要素をそれぞれルートとしたXMLメッセージを用いる。

<rpc message-id="1" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <get-config>
    <source>
      <running/>
    </source>
    <filter xmlns:t="http://example.com/schema/1.2/config" type="xpath"
            select="/t:top/t:users/t:user[t:name='fred']"/>
  </get-config>
</rpc>

<rpc-reply message-id="1" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
   <data>
     <!-- レスポンス -->
   </data>
</rpc-reply>

NETCONFプロトコルでは、設定データストアやNETCONFセッションに対する操作を定義している[8]。

設定データストア[9]とは、ネットワーク機器が動作中、あるいは起動時などそれぞれの状態にあるときに、読み込まれたり設定されたりする対象となる設定データ全体のことである。NETCONFプロトコルでは、動作中の設定データストアは<running/>と表され、NETCONFをサポートする機器は必ずこの設定データストアを持たなければならない。加えて、機器によっては起動時の設定データストア<startup/>などを持つことができる。

NETCONFプロトコルではこの層については特に規定しない。NETCONFでやり取りされるデータの定義は、YANGモデルによって行う[2]。

あるネットワーク機器が、標準的な機能に加え、その機器固有の機能をNETCONF経由でアクセスできるようにしたい場合がある。この機能または機能群のことを capability といい、URIを用いて表す。例えば、get-config操作のフィルタをXPathで記述できる機能の capability はurn:ietf:params:netconf:capability:xpath:1.0と表現される[10]。

ネットワーク機器とNETCONFクライアントの間でセッションが開かれた時、ネットワーク機器とクライアントは相手に対し利用可能な機能の capability のリストを、<hello>メッセージとして相手に広告する。これにより、そのセッションで利用する capability のバージョン調整などを行うことが可能となる。

以下は、その<hello>メッセージの例である。

   <hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
     <capabilities>
       <capability>urn:ietf:params:netconf:base:1.1</capability>
       <capability>urn:ietf:params:netconf:capability:startup:1.0</capability>
       <capability>http://example.net/router/2.3/myfeature</capability>
     </capabilities>
     <session-id>4</session-id>
   </hello>

• Cisco IOS[11]
• Juniper JUNOS[12]
• Alaxala AXシリーズ[13]

• Cisco NSO[14]

• libnetconf2[サイト 1]
• ncclient[サイト 2]
• JNC[サイト 3]