2. プログラムに関する基本的な概念#

ここでは、YANG、NETCONF、RESTCONF の詳細な学習に先立ち、理解しておくべきプログラムに関する重要な概念について説明します。

クライアントとサーバという語は、文脈によって異なる意味合いを持ち得る用語です。たとえばプログラムインターフェイスと API 動作では、それぞれ意味が変わってきます。 - サーバはデバイス上で実行されるソフトウェア（またはサービス）であり、着信をリッスンして応答します。 - クライアントはサーバに接続するアプリケーションであり、何らかの要求を行います。

クライアントとサーバの関係についての典型的な例としては、Web サイトの閲覧が挙げられます。ブラウザで http://learninglabs.cisco.com を開くと、ブラウザが「クライアント」になって Nginx「サーバ」に接続し、それにより Web ページが表示されます。

ネットワーク管理プロトコルとして NETCONF を使用する場合、デバイスは「NETCONF エージェント」と呼ばれるサーバを実行しています。管理者（またはネットワーク管理システム）は、「NETCONF マネージャ」と呼ばれるクライアントを利用してデバイスに接続します。

アプリケーションがネットワーク上で通信する際には、関連するデータがネットワーク上でのトランスポート用にパッケージ化されます。この部分を、上記の画像に示しています。多くの場合、このような違いについて考えることはありません。HTTP、TELNET、SMTP などのアプリケーションで作業するため、幸いにも考える必要がないからです。しかし、NETCONF/YANG に関しては、このような違いを理解することが重要です。 NETCONF、RESTCONF、gRPC は、ネットワーク管理データのトランスポート用のプロトコルとメソッドを記述します。 YANG は、ネットワーク要素が利用するデータモデルを記述します。内部的な場合にも、伝送用にパッケージ化された場合にも該当します。

「データモデル」の具体的な意味#

データモデルとは、「何か」を表現するために取り決められた、誰もが理解できる手法です。次の例は、人を表現する簡単な「データモデル」です。

人
性別 - 男性、女性、その他
身長 - フィート/インチまたはメートル
体重 - ポンドまたはキロ
髪の色 - 茶色、金色、黒色、赤色、その他
目の色 - 茶色、青色、緑色、薄茶色、その他

一般的なデータモデルを使用することにより、他者が理解しやすい方法で個人を記述することができます。

データ形式#

ネットワークデバイス（またはプログラム要素）とやり取りする際には、データが送受信されます。これは、NETCONF などの API インターフェイスに限ったことではありません。CLI インターフェイスでも、使用データが返されます。

クリアテキスト#

switch# show the int bri
--------------------------------------------------------------------------------
Ethernet      VLAN    Type Mode   Status  Reason                   Speed     Port
Interface                                                                    Ch #
--------------------------------------------------------------------------------
Eth1/1        1       eth  fabric down    SFP not inserted            10G(D) --

CLI の一般的な形式はクリアテキストで、人間にとっては読みやすく解釈しやすい形式です。しかし、コンピュータプログラムにとっては解釈が困難です。なぜなら、「構造」が定まっていなかったり、空白や位置情報を使って意味が表されることが多かったりするためです。クリアテキストのデータに複数のプラットフォーム共通の一貫性を持たせることはほぼ不可能です。ましてや複数のベンダーにまたがっている場合はなおさらです。クリアテキストは、プログラムのユースケースには適していないデータ形式です。

XML#

<?xml version="1.0" encoding="ISO-8859-1"?>
<nf:rpc-reply xmlns:nf="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns="http://www.cisco.com/nxos:1.0:if_manager">
 <nf:data>
  <show>
   <interface>
    <__XML__INTF_ifeth_brf>
     <__XML__PARAM_value>
      <__XML__INTF_output>Ethernet1/1-3</__XML__INTF_output>
     </__XML__PARAM_value>
     <__XML__OPT_Cmd_show_interface_if_eth_brief___readonly__>
      <__readonly__>
       <TABLE_interface>
        <ROW_interface>
         <interface>Ethernet1/1</interface>
         <vlan>1</vlan>
         <type>eth</type>
         <portmode>fabric</portmode>
         <state>down</state>
         <state_rsn_desc>SFP not inserted</state_rsn_desc>
         <speed>10G</speed>
         <ratemode>D</ratemode>
        </ROW_interface>
       </TABLE_interface>
      </__readonly__>
     </__XML__OPT_Cmd_show_interface_if_eth_brief___readonly__>
    </__XML__INTF_ifeth_brf>
   </interface>
  </show>
 </nf:data>
</nf:rpc-reply>
]]>]]>

XML（Extensible Markup Language）は、1996 年に、人間とコンピュータの両方に判読しやすいデータエンコード形式規則セットとして開発されました。 XML の形式は高度に構造化されています。そのため、XML を利用するアプリケーションやスクリプトを作成する開発者は、探している情報を特定するために空白や位置を解析する必要はありません。XML では、「名前空間」（例の xmlns を参照）の概念とスキーマを利用します。スキーマでは、情報が使用するデータモデルとフォーマットが指定されます。 XML は、プログラムのデータ転送にとっては、まさに適した選択肢です。ただし、判読しにくくオーバーヘッドも大きいので、他の選択肢も存在しています。

JSON#

{
    "interfaces": [
        {
            "interface": "Ethernet1/1",
            "vlan": "1",
            "type": "eth",
            "portmode": "fabric",
            "state": "down",
            "state_rsn_desc": "SFP not inserted",
            "speed": "10G",
            "ratemode": "D"
        }
    ]
}

JavaScript Object Notation（JSON）は、プログラムのユースケースで多く利用されている代替データ形式です。 JSON は XML よりもはるかに人間が読みやすいと考えられていますが、XML のような強力な構造とスキーマの検証は備えていません。

ネットワーク管理との関連性#

多くの API では、開発者がデータ形式として XML または JSON を指定できます。そのため、個別のユースケースに最適なタイプを開発者やアプリケーションが選択できます。今回の使用方法では、NETCONF は XML を利用しますが、RESTCONF については XML または JSON を選択できます。