(57)【要約】本願は、ネットワーク構成プロトコルに基づくデバイス構成方法、装置およびシステムを開示し、通信技術の分野に属する。方法は：ネットワーク管理装置によって、あらかじめ定義されたYANGモデルを使って構成データのモデルを確立し；NETCONFに基づいて前記構成データを、管理されるデバイスに送ることを含む。前記あらかじめ定義されたYANGモデルはn個の参照フィールドおよび各参照フィールドに別個に対応する一つまたは複数のオブジェクト・フィールドを含む。本願は、デバイス縦続シナリオにおいてNETCONFメッセージにおいて構成データの、目標となる、より低レベルのデバイスを示すためにNETCONFメッセージに拡張フィールドが追加されるときに、解決策の普遍性が比較的貧弱であり、構成処理効率が比較的低く、データ記憶処理手順が比較的複雑であるという従来技術の問題を解決する。
2019514297.tif 000002
【特許請求の範囲】
【請求項１】
ネットワーク構成プロトコルNETCONFに基づくデバイス構成方法であって、当該方法はネットワーク管理デバイスに適用され、前記ネットワーク管理デバイスは管理されるデバイスに接続され、前記管理されるデバイスはいくつかの、より低レベルのデバイスに接続され、前記ネットワーク管理デバイスおよび前記管理されるデバイスはNETCONFをサポートし；
当該方法は：
あらかじめ定義されたYANGモデルを使って構成データのモデルを確立する段階であって、前記あらかじめ定義されたYANGモデルはn個の参照フィールドおよび各参照フィールドに別個に対応するいくつかのオブジェクト・フィールドを含み、前記参照フィールドは、前記あらかじめ定義されたYANGモデルにおいて参照されるYANGモデルを示すために使われ、i番目の参照フィールドに対応するオブジェクト・フィールドは、前記i番目の参照フィールドにおいて参照されるYANGモデルを使ってモデリングされる目標構成データに対応する、目標となる、より低レベルのデバイスおよび／または目標となる、より低レベルのデバイスのグループを示すために使われ、前記より低レベルのデバイスのグループは、いくつかのより低レベルのデバイスを含むグループであり、1≦i≦nであり、iおよびnは正の整数である、段階と；
NETCONFに基づいて前記構成データを前記管理されるデバイスに送る段階とを含む、
方法。
【請求項２】
前記参照フィールドが、第一の文を使って定義され、前記第一の文は、あるYANGモデルにおいて、別のYANGモデルによって定義される模式木を参照するために使われる、請求項１記載の方法。
【請求項３】
前記オブジェクト・フィールドがlaef-list特徴を使って定義され、該leaf-list特徴は、同じ型のリーフ・ノードのグループを記述するために使われる、請求項１記載の方法。
【請求項４】
前記i番目の参照フィールドに対応する前記オブジェクト・フィールドは：いくつかの第一のオブジェクト・フィールドおよび／またはいくつかの第二のオブジェクト・フィールドを含み；
各第一のオブジェクト・フィールドは、前記i番目の参照フィールドにおいて参照される前記YANGモデルを使ってモデリングされる前記目標構成データが送達されるべき、より低レベルのデバイスを示すために使われ；
各第二のオブジェクト・フィールドは、前記i番目の参照フィールドにおいて参照される前記YANGモデルを使ってモデリングされる前記目標構成データが送達されるべき、より低レベルのデバイスのグループを示すために使われる、
請求項１ないし３のうちいずれか一項記載の方法。
【請求項５】
ネットワーク構成プロトコルNETCONFに基づくデバイス構成方法であって、当該方法は管理されるデバイスに適用され、前記管理されるデバイスはネットワーク管理デバイスに接続され、前記管理されるデバイスはさらに、いくつかの、より低レベルのデバイスに接続され、前記ネットワーク管理デバイスおよび前記管理されるデバイスはNETCONFをサポートし；
当該方法は：
NETCONFに基づいて前記ネットワーク管理デバイスによって送られた構成データを受信する段階であって、前記構成データは、あらかじめ定義されたYANGモデルを使って前記ネットワーク管理デバイスによってモデリングされており、前記あらかじめ定義されたYANGモデルはn個の参照フィールドおよび各参照フィールドに別個に対応するいくつかのオブジェクト・フィールドを含み、前記参照フィールドは、前記あらかじめ定義されたYANGモデルにおいて参照されるYANGモデルを示すために使われ、i番目の参照フィールドに対応するオブジェクト・フィールドは、前記i番目の参照フィールドにおいて参照されるYANGモデルを使ってモデリングされる目標構成データの、目標となる、より低レベルのデバイスおよび／または目標となる、より低レベルのデバイスのグループを示すために使われ、前記より低レベルのデバイスのグループは、いくつかのより低レベルのデバイスを含むグループであり、1≦i≦nであり、iおよびnは正の整数である、段階と；
前記あらかじめ定義されたYANGモデルに従って前記構成データをパースする段階と；
パースから得られた前記構成データに従って、より低レベルのデバイスを構成する段階とを含む、
方法。
【請求項６】
パースから得られた前記構成データに従って、より低レベルのデバイスを構成する前記段階は：
前記i番目の参照フィールドにおいて参照される前記YANGモデルを使ってモデリングされる前記目標構成データについて、前記i番目の参照フィールドに対応する前記オブジェクト・フィールドに従って前記目標構成データの、目標となる、より低レベルのデバイスを決定する段階であって、前記目標となる、より低レベルのデバイスは、前記i番目の参照フィールドに対応するオブジェクト・フィールドによって示される、より低レベルのデバイスおよび／または前記i番目の参照フィールドに対応するオブジェクト・フィールドによって示される、より低レベルのデバイスのグループにおける、より低レベルのデバイスである、段階と；
目標構成管理プロトコルに基づいて、前記目標構成データを前記目標となる、より低レベルのデバイスに送る段階であって、前記目標構成管理プロトコルは、前記管理されるデバイスおよび前記目標となる、より低レベルのデバイスによってサポートされる構成管理プロトコルである、段階とを含む、
請求項５記載の方法。
【請求項７】
前記あらかじめ定義されたYANGモデルに従って前記構成データをパースした後、当該方法はさらに：
パースから得られた前記構成データを、同じ構成データベースに記憶することを含む、
請求項５または６記載の方法。
【請求項８】
ネットワーク構成プロトコルNETCONFに基づくデバイス構成装置であって、当該装置はネットワーク管理デバイスに適用され、前記ネットワーク管理デバイスは管理されるデバイスに接続され、前記管理されるデバイスはいくつかの、より低レベルのデバイスに接続され、前記ネットワーク管理デバイスおよび前記管理されるデバイスはNETCONFをサポートし；
当該装置は：
あらかじめ定義されたYANGモデルを使って構成データのモデルを確立するよう構成されたモデリング・ユニットであって、前記あらかじめ定義されたYANGモデルはn個の参照フィールドおよび各参照フィールドに別個に対応するいくつかのオブジェクト・フィールドを含み、前記参照フィールドは、前記あらかじめ定義されたYANGモデルにおいて参照されるYANGモデルを示すために使われ、i番目の参照フィールドに対応するオブジェクト・フィールドは、前記i番目の参照フィールドにおいて参照されるYANGモデルを使ってモデリングされる目標構成データに対応する、目標となる、より低レベルのデバイスおよび／または目標となる、より低レベルのデバイスのグループを示すために使われ、前記より低レベルのデバイスのグループは、いくつかのより低レベルのデバイスを含むグループであり、1≦i≦nであり、iおよびnは正の整数である、モデリング・ユニットと；
NETCONFに基づいて前記構成データを前記管理されるデバイスに送るよう構成された送信ユニットとを有する、
装置。
【請求項９】
前記参照フィールドが、第一の文を使って定義され、前記第一の文は、あるYANGモデルにおいて、別のYANGモデルによって定義される模式木を参照するために使われる、請求項８記載の装置。
【請求項１０】
前記オブジェクト・フィールドがlaef-list特徴を使って定義され、該leaf-list特徴は、同じ型のリーフ・ノードのグループを記述するために使われる、請求項８記載の装置。
【請求項１１】
前記i番目の参照フィールドに対応する前記オブジェクト・フィールドは：いくつかの第一のオブジェクト・フィールドおよび／またはいくつかの第二のオブジェクト・フィールドを含み；
各第一のオブジェクト・フィールドは、前記i番目の参照フィールドにおいて参照される前記YANGモデルを使ってモデリングされる前記目標構成データが送達されるべき、より低レベルのデバイスを示すために使われ；
各第二のオブジェクト・フィールドは、前記i番目の参照フィールドにおいて参照される前記YANGモデルを使ってモデリングされる前記目標構成データが送達されるべき、より低レベルのデバイスのグループを示すために使われる、
請求項８ないし１０のうちいずれか一項記載の装置。
【請求項１２】
ネットワーク構成プロトコルNETCONFに基づくデバイス構成装置であって、当該装置は管理されるデバイスに適用され、前記管理されるデバイスはネットワーク管理デバイスに接続され、前記管理されるデバイスはさらに、いくつかの、より低レベルのデバイスに接続され、前記ネットワーク管理デバイスおよび前記管理されるデバイスはNETCONFをサポートし；
当該装置は：
NETCONFに基づいて前記ネットワーク管理デバイスによって送られた構成データを受信するよう構成された受信ユニットであって、前記構成データは、あらかじめ定義されたYANGモデルを使って前記ネットワーク管理デバイスによってモデリングされており、前記あらかじめ定義されたYANGモデルはn個の参照フィールドおよび各参照フィールドに別個に対応するいくつかのオブジェクト・フィールドを含み、前記参照フィールドは、前記あらかじめ定義されたYANGモデルにおいて参照されるYANGモデルを示すために使われ、i番目の参照フィールドに対応するオブジェクト・フィールドは、前記i番目の参照フィールドにおいて参照されるYANGモデルを使ってモデリングされる目標構成データの、目標となる、より低レベルのデバイスおよび／または目標となる、より低レベルのデバイスのグループを示すために使われ、前記より低レベルのデバイスのグループは、いくつかのより低レベルのデバイスを含むグループであり、1≦i≦nであり、iおよびnは正の整数である、受信ユニットと；
前記あらかじめ定義されたYANGモデルに従って前記構成データをパースするよう構成されたパース・ユニットと；
パースから得られた前記構成データに従って、より低レベルのデバイスを構成するよう構成された構成ユニットとを有する、
装置。
【請求項１３】
前記構成ユニットが具体的には：
前記i番目の参照フィールドにおいて参照される前記YANGモデルを使ってモデリングされる前記目標構成データについて、前記i番目の参照フィールドに対応する前記オブジェクト・フィールドに従って前記目標構成データの、目標となる、より低レベルのデバイスを決定する段階であって、前記目標となる、より低レベルのデバイスは、前記i番目の参照フィールドに対応するオブジェクト・フィールドによって示される、より低レベルのデバイスおよび／または前記i番目の参照フィールドに対応するオブジェクト・フィールドによって示される、より低レベルのデバイスのグループにおける、より低レベルのデバイスである、段階と；
目標構成管理プロトコルに基づいて、前記目標構成データを前記目標となる、より低レベルのデバイスに送る段階であって、前記目標構成管理プロトコルは、前記管理されるデバイスおよび前記目標となる、より低レベルのデバイスによってサポートされる構成管理プロトコルである、段階とを実行するよう構成されている、
請求項１２記載の装置。
【請求項１４】
当該装置がさらに：
パースから得られた前記構成データを、同じ構成データベースに記憶するよう構成された記憶ユニットを有する、
請求項１２または１３記載の装置。
【発明の詳細な説明】
【技術分野】
【０００１】
関連出願への相互参照
本願は2016年4月15日に中国特許庁に出願された「ネットワーク構成プロトコルに基づくデバイス構成方法および装置」と題する中国特許出願第201610234776.9号の優先権を主張するものである。同出願の内容はここに参照によってその全体において組み込まれる。
【０００２】
技術分野
本願は通信技術の分野に、詳細にはネットワーク構成プロトコルに基づくデバイス構成方法および装置に関する。
【背景技術】
【０００３】
ネットワーク構成プロトコル（英語：Network  Configuration  Protocol、略NETCONF）は、拡張可能マークアップ言語（英語：Extensible  Markup  Language、略XML）に基づくネットワーク管理プロトコルである。NETCONFは、安全トランスポート（英語：Secure  Transport）層、メッセージ（英語：Messages）層、動作（英語：Operations）層およびコンテンツ（英語：Content）層を含む四層アーキテクチャーを使う。現在のところ、NETCONFの安全トランスポート層、メッセージ層および動作層は標準で定義されているが、コンテンツ層には、標準的なデータ・モデリング言語または関係したデータ・モデルがない。これは、NETCONFの実際の普及および応用を制約する重要な要因である。
【０００４】
近年、YANG（英語：Yet  Another  Next  Generation）データ・モデリング言語（英語：data  modeling  language）が、インターネット技術特別調査委員会（英語：Internet  Engineering  Task  Force、略IETF）によって標準的なNETCONFデータ・モデリング言語として使われている。YANGデータ・モデリング言語は、構成データのモデル（英語：model  configuration  data）を確立するのみならず、さまざまな動作および通知のモデルを確立するためにも使われることができ、よって、良好な可読性およびスケーラビリティーをもつ。現在のところ、YANG言語は、NETCONFのコンテンツ層、動作層およびメッセージ層のためのデータ・モデリングを実行するために使用できる。
【０００５】
NETCONFは、クライアント／サーバー（英語：Client/Server、略C/S）アーキテクチャーを使う。図１に示されるように、図１はNETCONFとYANGとの間の関係の概略図である。NETCONFクライアントおよびNETCONFサーバーは、NETCONFに基づいて互いと通信する。NETCONFクライアントはYANG言語を使って構成データのモデルを確立し、モデリング後に得られた構成データを、XMLを使ってエンコードして、XMLファイルを得る。NETCONFクライアントによってNETCONFサーバーに送達されるNETCONFメッセージは、XMLファイルを担持する。NETCONFクライアントからNETCONFメッセージを受信後、NETCONFサーバーは、該メッセージのコンテンツに対してパース処理を実行して、構成データを得る。
【０００６】
図２に示されるように、図２は、デバイス縦続シナリオの概略図を示している。ネットワーク管理デバイス２１は、管理されるデバイス２２に接続されており、管理されるデバイス２２はいくつかのより低レベルのデバイス２３に接続される。ネットワーク管理デバイス２１はNETCONFクライアントのはたらきをし、管理されるデバイス２２はNETCONFサーバーのはたらきをする。ネットワーク管理デバイス２１および管理されるデバイス２２はNETCONFに基づいて互いと通信する。管理されるデバイス２２およびより低レベルのデバイス２３は、任意の構成管理プロトコルに基づいて互いと通信しうる。たとえば、管理されるデバイス２２およびより低レベルのデバイス２３は、無線アクセス・ポイントのコントロールおよびプロビジョニング（英語：Control  And  Provisioning  of  Wireless  Access  Points  Protocol  Specification、略CAPWAP）に基づいて互いと通信する。ネットワーク管理デバイス２１は、NETCONFを使って、管理されるデバイス２２およびより低レベルのデバイス２３を構成する。より低レベルのデバイス２３は、ネットワーク管理デバイス２１に直接接続されてはいないが、管理されるデバイス２２によって送られた構成データを、CAPWAPを使って受信する。管理されるデバイス２２は、ネットワーク管理デバイス２１によって送られた構成データを受信する。該構成データは、管理されるデバイス２２のための構成データおよびより低レベルのデバイス２３のための構成データを含む。より低レベルのデバイス２３のためにネットワーク管理デバイス２１によって送られた構成データについては、管理されるデバイス２２は、ネットワーク管理デバイス２１によって送達されたNETCONFの終着点になり、該メッセージのコンテンツに対してパース処理を実行して前記構成データを取得し、前記構成データをCAPWAPパケットにカプセル化し直して、該CAPWAPパケットを、より低レベルのデバイス２３に送る。
【０００７】
図２に示されるデバイス縦続シナリオでは、構成および管理のためにNETCONFが使われるとき、次の問題が存在する。標準的なNETCONFメッセージでは、構成データと構成されるデバイスとの間の関係が反映されない。すなわち、管理されるデバイス２２は、NETCONFメッセージにおいて担持される構成データが届けられる、より低レベルのデバイス２３（単数または複数）を知ることができない。上記の問題を解決するために、従来技術においては、NETCONFメッセージに拡張フィールドが追加され、該拡張フィールドが追加的な情報を転送するために使われる。具体的には、ネットワーク管理デバイス２１によって管理されるデバイス２２に送達されるNETCONFメッセージは、コンテンツ・フィールドおよび拡張フィールドを含む。コンテンツ・フィールドは、YANG言語を使って定義されるデータ・モデルに従って構成データを担持する。拡張フィールドは、デバイス情報を担持し、デバイス情報は、NETCONFメッセージにおける構成データの、目標となる、より低レベルのデバイスを示すために使われる。
【０００８】
しかしながら、従来技術には、少なくとも以下の技術的問題がある。
【０００９】
１．プライベートなデバイス情報を加えるためにNETCONFメッセージに拡張フィールドが追加される必要がある。結果として、ネットワーク管理デバイスと、サードパーティー・プロバイダーによって提供される管理されるデバイスは、互いと連係動作することができず、この解決策の普遍性は比較的貧弱である。
【００１０】
２．一つのNETCONFメッセージは、一つのより低レベルのデバイスのための構成データまたはいくつかのより低レベルのデバイスのための同じ構成データを担持することしかできない。異なる構成データは、複数のNETCONFメッセージにおいて複数回で送られる必要がある。結果として、構成処理の効率は比較的低い。
【００１１】
３．管理されるデバイスが、拡張フィールドに従って異なるより低レベルのデバイスのための複数の異なるデータベースを生成して、対応する構成データを別々に記憶するようにする必要がある。結果として、データ記憶処理手順が比較的複雑である。
【発明の概要】
【００１２】
本願の実施形態は、デバイス縦続シナリオにおいてNETCONFメッセージにおいて構成データの、目標となる、より低レベルのデバイスを示すためにNETCONFメッセージに拡張フィールドが追加されるときに、解決策の普遍性が比較的貧弱であり、構成処理効率が比較的低く、データ記憶処理手順が比較的複雑であるという従来技術の問題を解決するための、ネットワーク構成プロトコルに基づくデバイス構成方法および装置を提供する。技術的解決策は次のとおり。
【００１３】
第一の側面によれば、NETCONFに基づくデバイス構成方法が提供され、該方法はネットワーク管理デバイスに適用される。ネットワーク管理デバイスは管理されるデバイスに接続されており、管理されるデバイスはいくつかの、より低レベルのデバイスに接続されており、ネットワーク管理デバイスおよび管理されるデバイスはNETCONFをサポートする。本方法は、あらかじめ定義されたYANGモデルを使って構成データのモデルを確立する段階であって、前記あらかじめ定義されたYANGモデルはn個の参照フィールドおよび各参照フィールドに別個に対応するいくつかのオブジェクト・フィールドを含み、前記参照フィールドは、前記あらかじめ定義されたYANGモデルにおいて参照されるYANGモデルを示すために使われ、i番目の参照フィールドに対応するオブジェクト・フィールドは、i番目の参照フィールドにおいて参照されるYANGモデルを使ってモデリングされる目標構成データに対応する、目標となる、より低レベルのデバイスおよび／または目標となる、より低レベルのデバイスのグループを示すために使われ、前記より低レベルのデバイスのグループは、いくつかのより低レベルのデバイスを含むグループであり、1≦i≦nであり、iおよびnは正の整数である、段階と；NETCONFに基づいて前記構成データを前記管理されるデバイスに送る段階とを含む。
【００１４】
第一の側面の第一の可能な実装では、参照フィールドは、第一の文を使って定義され、前記第一の文は、あるYANGモデルにおいて、別のYANGモデルによって定義される模式木を参照するために使われる。
【００１５】
第一の側面または第一の側面の第一の可能な実装を参照するに、第一の側面の第二の可能な実装では、オブジェクト・フィールドは、laef-list〔リーフ・リスト〕特徴を使って定義され、該leaf-list特徴は、同じ型のリーフ・ノードのグループを記述するために使われる。
【００１６】
第一の側面、第一の側面の第一の可能または第一の側面の第二の可能を参照するに、第一の側面の第三の可能な実装では、i番目の参照フィールドに対応するオブジェクト・フィールドは：いくつかの第一のオブジェクト・フィールドおよび／またはいくつかの第二のオブジェクト・フィールドを含む。各第一のオブジェクト・フィールドは、i番目の参照フィールドにおいて参照されるYANGモデルを使ってモデリングされる目標構成データが送達される、より低レベルのデバイスを示すために使われる。各第二のオブジェクト・フィールドは、i番目の参照フィールドにおいて参照されるYANGモデルを使ってモデリングされる目標構成データが送達される、より低レベルのデバイスのグループを示すために使われる。
【００１７】
第二の側面によれば、NETCONFに基づくデバイス構成方法が提供され、該方法は管理されるデバイスに適用される。管理されるデバイスはネットワーク管理デバイスに接続されており、管理されるデバイスはさらに、いくつかの、より低レベルのデバイスに接続されており、ネットワーク管理デバイスおよび管理されるデバイスはNETCONFをサポートする。本方法は、NETCONFに基づいてネットワーク管理デバイスによって送られた構成データを受信する段階であって、前記構成データは、あらかじめ定義されたYANGモデルを使ってネットワーク管理デバイスによってモデリングされている、段階と；前記あらかじめ定義されたYANGモデルに従って前記構成データをパースする段階と；パースから得られた前記構成データに従って、より低レベルのデバイスを構成する段階とを含む。
【００１８】
第二の側面の第一の可能な実装では、パースから得られた前記構成データに従って、より低レベルのデバイスを構成する前記段階は、i番目の参照フィールドにおいて参照されるYANGモデルを使ってモデリングされる目標構成データについて、i番目の参照フィールドに対応するオブジェクト・フィールドに従って前記目標構成データの、目標となる、より低レベルのデバイスを決定する段階であって、前記目標となる、より低レベルのデバイスは、i番目の参照フィールドに対応するオブジェクト・フィールドによって示される、より低レベルのデバイスおよび／またはi番目の参照フィールドに対応するオブジェクト・フィールドによって示される、より低レベルのデバイスのグループにおける、より低レベルのデバイスである、段階と；目標構成管理プロトコルに基づいて、前記目標構成データを前記目標となる、より低レベルのデバイスに送る段階であって、前記目標構成管理プロトコルは、前記管理されるデバイスおよび前記目標となる、より低レベルのデバイスによってサポートされる構成管理プロトコルである、段階とを含む。
【００１９】
第二の側面または第二の側面の第一の可能な実装を参照するに、第二の側面の第二の可能な実装では、前記あらかじめ定義されたYANGモデルに従って前記構成データをパースした後、本方法はさらに：パースから得られた前記構成データを、同じ構成データベースに記憶することを含む。
【００２０】
第三の側面によれば、NETCONFに基づくデバイス構成装置が提供され、該装置は、少なくとも一つのユニットを含み、該少なくとも一つのユニットは、前記第一の側面または第一の側面のいずれかの可能な実装において提供されるデバイス構成方法を実装するよう構成される。
【００２１】
第四の側面によれば、NETCONFに基づくデバイス構成装置が提供され、該装置は、少なくとも一つのユニットを含み、該少なくとも一つのユニットは、前記第二の側面または第二の側面のいずれかの可能な実装において提供されるデバイス構成方法を実装するよう構成される。
【００２２】
第五の側面によれば、NETCONFに基づくデバイス構成システムが提供され、該システムは、ネットワーク管理デバイスと、管理されるデバイスと、いくつかの、より低レベルのデバイスとを含む。ネットワーク管理デバイスは管理されるデバイスに接続されており、管理されるデバイスはいくつかの、より低レベルのデバイスに接続されており、ネットワーク管理デバイスおよび管理されるデバイスはNETCONFをサポートする。ネットワーク管理デバイスは、第三の側面で記載されたデバイス構成装置を含む。管理されるデバイスは、第四の側面で記載されたデバイス構成装置を含む。
【００２３】
第六の側面によれば、ネットワーク管理デバイスが提供される。ネットワーク管理デバイスは、プロセッサと、メモリと、トランシーバとを含む。メモリは、一つまたは複数の命令を記憶するよう構成される。命令は、プロセッサによって実行されるよう構成される。該命令は、前記第一の側面または第一の側面のいずれかの可能な実装において提供されるデバイス構成方法を実装するために使われる。
【００２４】
第七の側面によれば、管理されるデバイスが提供される。管理されるデバイスは、プロセッサと、メモリと、トランシーバとを含む。メモリは、一つまたは複数の命令を記憶するよう構成される。命令は、プロセッサによって実行されるよう構成される。該命令は、前記第二の側面または第二の側面のいずれかの可能な実装において提供されるデバイス構成方法を実装するために使われる。
【００２５】
本願の実施形態において提供される技術的解決策は、以下の有益な効果をもたらす。
【００２６】
構成データのモデルは、あらかじめ定義されたYANGモデルを使ってネットワーク管理デバイスによって確立され、構成データはNETCONFに基づいて、管理されるデバイスに送られ、管理されるデバイスは、あらかじめ定義されたYANGモデルに従って該構成データをパースし、パースから得られた構成データに従って、より低レベルのデバイスを構成する。これは、デバイス縦続シナリオにおいてNETCONFメッセージにおいて構成データの、目標となる、より低レベルのデバイスを示すためにNETCONFメッセージに拡張フィールドが追加されるときに、解決策の普遍性が比較的貧弱であり、構成処理効率が比較的低く、データ記憶処理手順が比較的複雑であるという従来技術の問題を解決する。
【００２７】
構成データを参照し、構成データの、目標となる、より低レベルのデバイスおよび／または目標となる、より低レベルのデバイスのグループを示すために、前記あらかじめ定義されたYANGモデルにおける参照フィールドおよびオブジェクト・フィールドを設計することによって、定義されているYANGモデルを修正することなく、あらかじめ定義されたYANGモデルが使用される。
【００２８】
第一に、NETCONFメッセージに対して拡張フィールドが追加されず、よって、NETCONFは拡張される必要がない。よって、ネットワーク管理デバイスおよび管理されるデバイスは、いまだに標準的なNETCONFに基づいて互いと通信し、解決策の普遍性がよくなる。
【００２９】
第二に、複数のYANGモデルを使ってモデリングされる構成データが、複数の参照フィールドを使うことによって、あらかじめ定義されたYANGモデルにおいて参照されることができ、構成データの各片の、目標となる、より低レベルのデバイスおよび／または目標となる、より低レベルのデバイスのグループが別個に同定されることができる。よって、一つのNETCONFメッセージが、異なる、より低レベルのデバイス／より低レベルのデバイスのグループのために送達される異なる構成データを担持することができ、それにより、構成処理効率を改善する。
【００３０】
第三に、あらかじめ定義されたYANGモデルが、ネットワーク管理デバイスによって送達されるNETCONFメッセージにおいて担持されるすべての構成データについてモデリングを実行するために使われる。よって、管理されるデバイスは、異なる、より低レベルのデバイスおよびより低レベルのデバイスのグループのための複数の異なるデータベースを別個に維持することなく、あらかじめ定義されたYANGモデルに対応するデータベースを維持するだけでよい。これは、データベース構成および管理を単純化し、データ記憶処理手順を単純化する。
【図面の簡単な説明】
【００３１】
本願の実施形態におけるおよび従来技術における技術的解決策をより明瞭に記述するために、下記は、実施形態または従来技術を記述するために必要とされる付属の図面を手短かに説明する。
【００３２】
【図１】NETCONFとYANGの間の関係の概略図である。
【００３３】
【図２】デバイス縦続シナリオの概略図である。
【００３４】
【図３Ａ】本願のある実施形態に基づく応用シナリオの概略図である。
【００３５】
【図３Ｂ】本願のある実施形態に基づく別の応用シナリオの概略図である。
【００３６】
【図４】無線ローカルエリアネットワークにおけるデバイス縦続シナリオのネットワーク・アーキテクチャーの図である。
【００３７】
【図５】図５Ａおよび図５Ｂは、本願のある実施形態に基づくネットワーク・デバイスのブロック図である。
【００３８】
【図６】本願のある実施形態に基づくNETCONFに基づくデバイス構成方法のフローチャートである。
【００３９】
【図７】本願の別の実施形態に基づくNETCONFに基づくデバイス構成方法のフローチャートである。
【００４０】
【図８】本願の別の実施形態に基づくNETCONFに基づくデバイス構成方法のフローチャートである。
【００４１】
【図９】本願のある実施形態に基づくNETCONFに基づくデバイス構成装置のブロック図である。
【００４２】
【図１０】本願の別の実施形態に基づくNETCONFに基づくデバイス構成装置のブロック図である。
【発明を実施するための形態】
【００４３】
本願の目的、技術的解決策および利点を一層明瞭にするために、下記は、付属の図面を参照して本願の実装をより詳細に記述する。
【００４４】
本明細書において言及される「モジュール」は、いくつかの機能を実装することのできる、メモリに記憶されるプログラムまたは命令である。本明細書において言及される「ユニット」は、論理に従って分割された機能的な構造である。「ユニット」は、ハードウェアのみによって実装されるか、ソフトウェアとハードウェアの組み合わせによって実装されることができる。
【００４５】
本明細書において言及される「いくつかの」は一つまたは複数であり、「複数」は二つ以上である。用語「および／または」は、関連するオブジェクトを記述するための関連関係を記述し、三つの関係が存在しうることを表わす。たとえば、Aおよび／またはBは、以下の三つの場合を表わしうる：Aのみが存在、AおよびBの両方が存在、およびBのみが存在。記号「／」は一般に、関連するオブジェクトの間の「または」の関係を示す。
【００４６】
本願の実施形態において提供される技術的解決策は、図２に示されるデバイス縦続シナリオに適用される。ある可能な実装では、図３Ａに示されるように、ネットワーク管理デバイス２１がNETCONFクライアントのはたらきをし、管理されるデバイス２２がNETCONFサーバーのはたらきをする。ネットワーク管理デバイス２１および管理されるデバイス２２はNETCONFに基づいて互いと通信し、管理されるデバイス２２およびより低レベルのデバイス２３は、非NETCONFプロトコルに基づいて互いと通信する。たとえば、デバイス縦続シナリオが無線ローカルエリアネットワーク（英語：wireless  local  area  network、略WLAN）に適用されるとき、非NETCONFプロトコルはCAPWAPであってもよい。
【００４７】
もう一つの可能な実装では、図３Ｂに示されるように、ネットワーク管理デバイス２１がNETCONFクライアントのはたらきをし、管理されるデバイス２２がNETCONFプロキシのはたらきをし、より低レベルのデバイス２３がNETCONFサーバーのはたらきをする。ネットワーク管理デバイス２１にとっては、NETCONFプロキシはNETCONFサーバーの機能を実装する。より低レベルのデバイス２３にとっては、NETCONFプロキシはNETCONFクライアントの機能を実装する。ネットワーク管理デバイス２１および管理されるデバイス２２はNETCONFに基づいて互いと通信し、管理されるデバイス２２およびより低レベルのデバイス２３も、NETCONFプロトコルに基づいて互いと通信する。
【００４８】
NETCONFクライアント、NETCONFサーバーおよびNETCONFプロキシのすべては、デバイスにおいて走っているソフトウェア・プロセスであり、ハードウェアではないことを注意しておくべきである。
【００４９】
図４に示されるように、WLANにおけるデバイス縦続シナリオが例として使われる。ネットワーク・アーキテクチャーは：コントローラ４１と、ローカル・コントローラ（英語：local  access  controller、略LAC）４２と、いくつかのアクセス・ポイント（英語：access  point、略AP）とを含む。コントローラ４１およびLAC  ４２はNETCONFに基づいて互いと通信する。LAC  ４２およびAPは、CAPWAPに基づいて互いと通信する。
【００５０】
コントローラ４１はNETCONFクライアントのはたらきをする。コントローラ４１は、NETCONFを使ってLAC  ４２および各APを構成するよう構成される。コントローラ４１は、中央集中式コントローラまたは敏捷コントローラと称されてもよく、コントローラ４１に従属するすべてのAPを管理するよう構成される。コントローラ４１に従属させられ、コントローラ４１によって管理されるAPの数は、数十万またはさらには数百万に達することもできる。
【００５１】
LAC  ４２はNETCONFサーバーのはたらきをする。LAC  ４２は、コントローラ４１によって送られた構成データを受信するよう構成され、該構成データは、LAC  ４２のための構成データおよびLAC  ４２によって管理されるAPのための構成データを含む。コントローラ４１によって送達されるNETCONFメッセージについて、LAC  ４２は該NETCONFメッセージの終着点になり、該メッセージのコンテンツをパースして前記構成データを取得し、該構成データをCAPWAPパケットにカプセル化し直して、該CAPWAPパケットを対応するAPに送る。LAC  ４２は、軽量アクセス・コントローラ（英語：light  access  controller）と称されてもよい。LAC  ４２およびAPは、ローカルエリアネットワークを使って通信接続を確立する。たとえば、LAC  ４２は、一つまたは複数のレベルのスイッチを使ってAPに接続されてもよい。もう一つの例として、LAC  ４２は、一つまたは複数のレベルのルーターを使ってAPに接続されてもよい。
【００５２】
APは、コントローラ４１に直接接続されるのではなく、LAC  ４２によって送られた構成データをCAPWAPを使って受信する。
【００５３】
さらに、各LAC  ４２は、いくつかのAPおよび／またはいくつかのAPグループを管理するよう構成されてもよい。各APグループは少なくとも一つのAPを含む。たとえば、図４の左側のLAC  ４２はAP3および二つのAPグループ（グループ１およびグループ２）を管理するよう構成される。グループ１はAP1およびAP2を含み、グループ２はAP4を含む。
【００５４】
拡張フィールドがNETCONFメッセージに追加される従来技術の仕方がAPの特徴、たとえば動的ホスト構成プロトコル（英語：Dynamic  Host  Configuration  Protocol、略DHCP）およびドメイン名システム（Domain  Name  System、略DNS）を構成するために使われる場合には、具体的な手順は次のようになる。
【００５５】
１．コントローラがYANGモデルを使って構成データのモデルを確立する。
【００５６】
APのDHCP特徴を構成する例では、対応するYANGモデルはhw-dhcp.yangであると想定され、コントローラは、hw-dhcp.yangによって定義されるデータ・モデルを使ってDHCP構成データに対してモデリングを実行する。
【００５７】
２．コントローラがNETCONFメッセージを生成する。
【００５８】
NETCONFメッセージは、コンテンツ・フィールドおよび拡張フィールドを含む。コンテンツ・フィールドは、YANGモデルを使って構築された構成データ、たとえばhw-dhcp.yangを使ってモデリングされたDHCP構成データを担持する。拡張フィールドは、デバイス情報を担持する。デバイス情報は、NETCONFメッセージ中の構成データが送達されるべきAPおよび／またはAPグループを示すために使われる。たとえば、DHCP構成データがAP3ならびにグループ１内のAP1およびAP2のすべてに適用可能であるとき、拡張フィールドは、AP3およびグループ１に対応する識別情報を担持する。
【００５９】
たとえば、NETCONFメッセージは次のようなものである：
<rpc  message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<device-grouop>  group1  </device-grouop>
<device-name>  ap3  </device-name>
<edit-config>
<!--  method  parameters  here...  -->
</  edit-config  >
</rpc>
【００６０】
３．コントローラがNETCONFメッセージをLACに送る。
【００６１】
対応して、LACはNETCONFメッセージをコントローラから受信する。
【００６２】
４．LACがNETCONFメッセージをパースして、拡張フィールドに担持されているデバイス情報およびコンテンツ・フィールドに担持されている構成データを取得する。
【００６３】
５．LACが構成データを、拡張フィールドによって示されるAPおよび／またはAPグループに対応するデータベースに別個に記憶する。
【００６４】
たとえば、LACは、グループ１に対応するデータベースDB1に前記DHCP構成データを記憶し、AP3に対応するデータベースDB2に前記DHCP構成データを記憶する。
【００６５】
６．LACは、デバイス情報および構成データに従ってAPを構成する。
【００６６】
データベース中の構成データが変更されたことを検出した後、APを構成および管理するよう構成された、LAC内の機能モジュールが、データベースから構成データを読み、該構成データを対応するAPおよび／またはAPグループに別個に送る。
【００６７】
したがって、デバイス縦続シナリオにおいて、より低レベルのデバイスを構成するために拡張フィールドがNETCONFメッセージに追加される従来技術の仕方が使われるときには、解決策の普遍性が比較的貧弱であり、構成処理効率が比較的低く、データ記憶処理手順が比較的複雑であるという問題がある。
【００６８】
下記は、本願で提供される技術的解決策を、いくつかの実施形態を使って記述する。
【００６９】
図５Ａおよび図５Ｂを参照するに、図５Ａおよび図５Ｂは、本願のある実施形態に基づくネットワーク・デバイスのブロック図である。ネットワーク・デバイス５００は、本願の実施形態におけるネットワーク管理デバイス（たとえば、図４に示したネットワーク・アーキテクチャーにおけるコントローラ）であってもよく、あるいは本願の実施形態における管理されるデバイス（たとえば図４に示したネットワーク・アーキテクチャーにおけるLAC）であってもよい。
【００７０】
ネットワーク・デバイス５００は：プロセッサ５１０と、メモリ５２０と、トランシーバ５３０と、バス５４０とを含んでいてもよい。メモリ５２０およびトランシーバ５３０は、バス５４０を使ってプロセッサ５１０に接続される。
【００７１】
プロセッサ５１０は、一つまたは複数の処理コアを含む。プロセッサ５１０は、ソフトウェア・プログラムおよびモジュールを実行することによって、さまざまな機能アプリケーションおよびデータ処理を実行する。プロセッサ５１０は、BizLetコンポーネント、レジスタ・コンポーネント、制御コンポーネントなどを含む。プロセッサ５１０は、独立した中央処理ユニットであってもよく、あるいは埋め込み型のプロセッサ、たとえばマイクロプロセッサ（英語：micro  processor  unit、略MPU）、マイクロコントローラ（英語：micro-controller  unit、略MCU）またはデジタル信号プロセッサ（英語：embedded  digital  signal  processor、略EDSP）であってもよい。
【００７２】
メモリ５２０は、いかなる型の揮発性または不揮発性記憶デバイスまたはそれらの組み合わせであってもよく、静的ランダムアクセスメモリ（英語：static  random  access  memory、略SRAM）、電気的に消去可能なプログラム可能型読み出し専用メモリ（英語：electrically  erasable  programmable  read-only  memory、略EEPROM）、消去可能なプログラム可能型読み出し専用メモリ（英語：erasable  programmable  read-only  memory、略EPROM）、プログラム可能型読み出し専用メモリ（英語：programmable  read-only  memory、略PROM）、読み出し専用メモリ（英語：read-only  memory、略ROM）、磁気メモリ、フラッシュメモリ、ディスクまたは光ディスクなどであってもよい。メモリ５２０は、ソフトウェア・プログラムおよびモジュールのような実行可能命令を記憶するよう構成されてもよい。
【００７３】
プロセッサ５１０は、メモリ５２０に記憶された命令を実行するよう構成される。ネットワーク・デバイス５００がネットワーク管理デバイスであるとき、プロセッサ５１０は、命令を実行することによって次の方法を実装する：あらかじめ定義されたYANGモデルを使って構成データのモデルを確立し；トランシーバ５３０を制御して該構成データをNETCONFに基づいて、管理されるデバイスに送る。あらかじめ定義されたYANGモデルは、n個の参照フィールドと、各参照フィールドに別個に対応するいくつかのオブジェクト・フィールドとを含む。参照フィールドは、あらかじめ定義されたYANGモデルにおいて参照されるYANGモデルを示すために使われる。i番目の参照フィールドに対応するオブジェクト・フィールドが、i番目の参照フィールドにおいて参照されるYANGモデルを使ってモデリングされる目標構成データの、目標となる、より低レベルのデバイスおよび／または目標となる、より低レベルのデバイスのグループを示すために使われる。より低レベルのデバイスのグループは、いくつかの、より低レベルのデバイスを含むグループである。1≦i≦nであり、iおよびnは正の整数である。ネットワーク・デバイス５００が管理されるデバイスであるときは、プロセッサ５１０は、命令を実行することによって次の方法を実装する：トランシーバ５３０を制御して、ネットワーク管理デバイスからNETCONFに基づいて送られた構成データを受信し；あらかじめ定義されたYANGモデルに従って該構成データをパースし；パースから得られた構成データに従って、より低レベルのデバイスを構成する。
【００７４】
トランシーバ５３０は、外部通信を実行するよう構成され、トランシーバ５３０は、複数の型のインターフェースを含んでいてもよい。たとえば、ネットワーク・デバイス５００がネットワーク管理デバイスであるとき、トランシーバ５３０は、構成データを管理されるデバイスにNETCONFに基づいて送るよう構成される。ネットワーク・デバイス５００が管理されるデバイスであるときは、トランシーバ５３０は、NETCONFに基づいてネットワーク管理デバイスによって送られた構成データを受信するよう構成される。
【００７５】
任意的に、メモリ５２０は、オペレーティング・システム５２２および少なくとも一つの機能によって要求されるアプリケーション・プログラム・モジュール５２４を記憶していてもよい。オペレーティング・システム５２２は、リアルタイム・オペレーティング・システムまたはLinux、Unix、WindowsまたはOS  Xのようなオペレーティング・システムであってもよい。ネットワーク・デバイス５００がネットワーク管理デバイスであるとき、図５Ａに示されるように、アプリケーション・プログラム・モジュール５２４はモデリング・モジュール５２４ａおよび送信モジュール５２４ｂを含んでいてもよい。モデリング・モジュール５２４ａは、あらかじめ定義されたYANGモデルを使って構成データのモデルを確立するよう構成される。送信モジュール５２４ｂは、構成データをNETCONFに基づいて、管理されるデバイスに送るよう構成される。ネットワーク・デバイス５００が管理されるデバイスであるときは、図５Ｂに示されるように、アプリケーション・プログラム・モジュール５２４は、受信モジュール５２４ｃ、パース・モジュール５２４ｄおよび構成モジュール５２４ｅを含んでいてもよい。受信モジュール５２４ｃは、ネットワーク管理デバイスによってNETCONFに基づいて送られた構成データを受信するよう構成される。パース・モジュール５２４ｄは、あらかじめ定義されたYANGモデルに従って該構成データをパースするよう構成される。構成モジュール５２４ｅは、パースから得られた構成データに従って、より低レベルのデバイスを構成するよう構成される。
【００７６】
任意的に、ネットワーク・デバイス５００はさらに、入出力コンポーネント（図示せず）を含んでいてもよい。入出力コンポーネントは、情報を表示するよう構成されたディスプレイおよびユーザーによって情報を入力するよう構成された入力デバイス、たとえばマウスまたはキーボードを含む。ディスプレイおよび入力デバイスはいずれも、バス５４０を使ってプロセッサ５１０に接続される。
【００７７】
図６を参照するに、図６は、本願のある実施形態に基づく、NETCONFに基づくデバイス構成方法のフローチャートである。この実施形態で与えられる方法は、ネットワーク管理デバイスに適用される。ネットワーク管理デバイスは管理されるデバイスに接続されており、管理されるデバイスはいくつかの、より低レベルのデバイスに接続されており、ネットワーク管理デバイスおよび管理されるデバイスはNETCONFをサポートする。本方法は、下記のいくつかの段階を含む。
【００７８】
段階６０２：あらかじめ定義されたYANGモデルを使って構成データのモデルを確立する。
【００７９】
前記あらかじめ定義されたYANGモデルはn個の参照フィールドおよび各参照フィールドに別個に対応するいくつかのオブジェクト・フィールドを含む。前記参照フィールドは、前記あらかじめ定義されたYANGモデルにおいて参照されるYANGモデルを示すために使われる。i番目の参照フィールドに対応するオブジェクト・フィールドは、i番目の参照フィールドにおいて参照されるYANGモデルを使ってモデリングされる目標構成データの、目標となる、より低レベルのデバイスおよび／または目標となる、より低レベルのデバイスのグループを示すために使われる。前記より低レベルのデバイスのグループは、いくつかのより低レベルのデバイスを含むグループである。1≦i≦nであり、iおよびnは正の整数である。
【００８０】
段階６０４：NETCONFに基づいて前記構成データを前記管理されるデバイスに送る。
【００８１】
結論として、この実施形態で提供される方法によれば、構成データのモデルは、あらかじめ定義されたYANGモデルを使ってネットワーク管理デバイスによって確立され、構成データはNETCONFに基づいて、管理されるデバイスに送られる。これは、デバイス縦続シナリオにおいてNETCONFメッセージにおいて構成データの、目標となる、より低レベルのデバイスを示すためにNETCONFメッセージに拡張フィールドが追加されるときに、解決策の普遍性が比較的貧弱であり、構成処理効率が比較的低く、データ記憶処理手順が比較的複雑であるという従来技術の問題を解決する。構成データを参照し、構成データの、目標となる、より低レベルのデバイスおよび／または目標となる、より低レベルのデバイスのグループを示すために、前記あらかじめ定義されたYANGモデルにおける参照フィールドおよびオブジェクト・フィールドを設計することによって、定義されているYANGモデルを修正することなく、あらかじめ定義されたYANGモデルが使用される。これは、下記の技術的効果を達成する。
【００８２】
第一に、NETCONFメッセージに対して拡張フィールドが追加されず、よって、NETCONFは拡張される必要がない。よって、ネットワーク管理デバイスおよび管理されるデバイスは、いまだに標準的なNETCONFに基づいて互いと通信し、解決策の普遍性がよくなる。
【００８３】
第二に、複数のYANGモデルを使ってモデリングされる構成データが、複数の参照フィールドを使うことによって、あらかじめ定義されたYANGモデルにおいて参照されることができ、構成データの各片の目標となる、より低レベルのデバイスおよび／または目標となる、より低レベルのデバイスのグループが別個に同定されることができる。よって、一つのNETCONFメッセージが、異なる、より低レベルのデバイス／より低レベルのデバイスのグループのために送達される異なる構成データを担持することができ、それにより、構成処理効率を改善する。
【００８４】
第三に、あらかじめ定義されたYANGモデルが、ネットワーク管理デバイスによって送達されるNETCONFメッセージにおいて担持されるすべての構成データについてモデリングを実行するために使われる。よって、管理されるデバイスは、異なる、より低レベルのデバイスおよびより低レベルのデバイスのグループのための複数の異なるデータベースを別個に維持することなく、あらかじめ定義されたYANGモデルに対応するデータベースを維持するだけでよい。これは、データベース構成および管理を単純化し、データ記憶処理手順を単純化する。
【００８５】
図７を参照するに、図７は、NETCONFに基づくデバイス構成方法のフローチャートである。この実施形態において提供される方法は、管理されるデバイスに適用される。管理されるデバイスはネットワーク管理デバイスに接続されており、管理されるデバイスはさらに、いくつかの、より低レベルのデバイスに接続されており、ネットワーク管理デバイスおよび管理されるデバイスはNETCONFをサポートする。本方法は、下記のいくつかの段階を含む。
【００８６】
段階７０２：NETCONFに基づいてネットワーク管理デバイスによって送られた構成データを受信する。
【００８７】
前記構成データは、あらかじめ定義されたYANGモデルを使ってネットワーク管理デバイスによって構築されている。前記あらかじめ定義されたYANGモデルはn個の参照フィールドおよび各参照フィールドに別個に対応するいくつかのオブジェクト・フィールドを含む。前記参照フィールドは、前記あらかじめ定義されたYANGモデルにおいて参照されるYANGモデルを示すために使われる。i番目の参照フィールドに対応するオブジェクト・フィールドは、i番目の参照フィールドにおいて参照されるYANGモデルを使ってモデリングされる目標構成データの、目標となる、より低レベルのデバイスおよび／または目標となる、より低レベルのデバイスのグループを示すために使われる。前記より低レベルのデバイスのグループは、いくつかのより低レベルのデバイスを含むグループである。1≦i≦nであり、iおよびnは正の整数である。
【００８８】
段階７０４：あらかじめ定義されたYANGモデルに従って前記構成データをパースする。
【００８９】
段階７０６：パースから得られた前記構成データに従って、より低レベルのデバイスを構成する。
【００９０】
結論として、この実施形態で提供される方法によれば、NETCONFに基づいてネットワーク管理デバイスによって送られた構成データが、管理されるデバイスによって受信され、前記構成データは、あらかじめ定義されたYANGモデルを使ってネットワーク管理デバイスによって構築されており、管理されるデバイスが、あらかじめ定義されたYANGモデルに従って前記構成データをパースし、パースから得られた前記構成データに従って、より低レベルのデバイスを構成する。これは、デバイス縦続シナリオにおいてNETCONFメッセージにおいて構成データの、目標となる、より低レベルのデバイスを示すためにNETCONFメッセージに拡張フィールドが追加されるときに、解決策の普遍性が比較的貧弱であり、構成処理効率が比較的低く、データ記憶処理手順が比較的複雑であるという従来技術の問題を解決する。構成データを参照し、構成データの、目標となる、より低レベルのデバイスおよび／または目標となる、より低レベルのデバイスのグループを示すために、前記あらかじめ定義されたYANGモデルにおける参照フィールドおよびオブジェクト・フィールドを設計することによって、定義されているYANGモデルを修正することなく、あらかじめ定義されたYANGモデルが使用される。これは、解決策の普遍性を改善し、構成処理効率を高め、データベース構成および管理ならびにデータ記憶処理手順を単純化する。
【００９１】
図８を参照するに、図８は、本願の別の実施形態に基づく、NETCONFに基づくデバイス構成方法のフローチャートである。
【００９２】
段階８０１：ネットワーク管理デバイスが、あらかじめ定義されたYANGモデルを使って構成データのモデルを確立する。
【００９３】
前記あらかじめ定義されたYANGモデルはn個の参照フィールドおよび各参照フィールドに別個に対応するいくつかのオブジェクト・フィールドを含む。前記参照フィールドは、前記あらかじめ定義されたYANGモデルにおいて参照されるYANGモデルを示すために使われる。i番目の参照フィールドに対応するオブジェクト・フィールドは、i番目の参照フィールドにおいて参照されるYANGモデルを使ってモデリングされる目標構成データの、目標となる、より低レベルのデバイスおよび／または目標となる、より低レベルのデバイスのグループを示すために使われる。前記より低レベルのデバイスのグループは、いくつかのより低レベルのデバイスを含むグループである。1≦i≦nであり、iおよびnは正の整数である。前記あらかじめ定義されたYANGモデルは、NETCONFに基づいて互いと通信するピア・デバイス（すなわち、この実施形態では当該ネットワーク管理デバイスおよび管理されるデバイス）上であらかじめ定義されたYANGモデル、すなわちNETCONFクライアントおよびNETCONFサーバーの両方であらかじめ定義されているYANGモデルである。
【００９４】
前記参照フィールドは、第一の文を使って定義され、前記第一の文は、あるYANGモデルにおいて、別のYANGモデルによって定義される模式木（英語：schema  tree〔スキーマ・ツリー〕）を参照するために使われる。
【００９５】
ある可能な実装では、YANG言語シンタックスを拡張して、前記第一の文は、新たに追加されたrefer文である。前記参照フィールドは、refer文を使って定義される。refer文は、あるYANGモデルにおいて、別のYANGモデルによって定義される模式木を参照するために使われる。refer文のパラメータは、参照されるYANGモデルの名前である。たとえば、YANGモデルmodule  yが別のYANGモデルmodule  xによって定義されている模式木を参照するとする。この場合、module  yにおける参照フィールドはrefer  xとして表現されうる。
【００９６】
前記あらかじめ定義されたYANGモデルがmodule  yであり、参照されるYANGモデルがmodule  xであるとする。module  xのシンタックス構造は次のようになる：
module  x  {
………………………………………………………………………………
container  a  {
leaf  b;
list  c  {
key  d;
leaf  d;
leaf  list  e;
}
}
}
【００９７】
module  yのシンタックス構造は次のようになる：
module  y  {
………………………………………………………………………………
import  x;
………………………………………………………………………………
list  x-instance  {
key  instance-name;
leaf  instance-name;
refer  x;
}
}
【００９８】
module  yのシンタックス構造は次と等価である：
module  y  {
………………………………………………………………………………
import  x;
………………………………………………………………………………
list  x-instance  {
key  instance-name;
leaf  instance-name;
container  a  {
leaf  b;
list  c  {
key  d;
leaf  d;
leaf  list  e;
}
}
}
}
【００９９】
任意的に、オブジェクト・フィールドは、laef-list〔リーフ・リスト〕特徴を使って定義される。該leaf-list特徴は、同じ型のリーフ・ノードのグループを記述するために使われ、該leaf-list特徴の機能はC言語における配列と同様である。一つまたは複数の、より低レベルのデバイスまたは一つまたは複数の、より低レベルのデバイスのグループが、leaf-list特徴を使って定義されてもよい。たとえば、「leaf-list  devices」が、構成データの、目標となる、より低レベルのデバイスを記述するために使われ、「leaf-list  device-groups」が、構成データの、目標となる、より低レベルのデバイスのグループを記述するために使われる。
【０１００】
さらに、i番目の参照フィールドに対応するオブジェクト・フィールドは：いくつかの第一のオブジェクト・フィールドおよび／またはいくつかの第二のオブジェクト・フィールドを含む。各第一のオブジェクト・フィールドは、i番目の参照フィールドにおいて参照されるYANGモデルを使ってモデリングされる目標構成データが送達されるべき、より低レベルのデバイスを示すために使われる。たとえば、第一のオブジェクト・フィールドは、「leaf-list  devices」を使って表現される。各第二のオブジェクト・フィールドは、i番目の参照フィールドにおいて参照されるYANGモデルを使ってモデリングされる目標構成データが送達される、より低レベルのデバイスのグループを示すために使われる。たとえば、第二のオブジェクト・フィールドは、「leaf-list  device-groups」を使って表現される。
【０１０１】
図４に示したネットワーク・アーキテクチャーを参照するに、コントローラは、APのDHCPおよびDNSのような特徴を構成する。APのDHCP特徴を構成することは、ここでは例として使われており、別の特徴の構成設定が同様に実装されてもよい。APの種々の特徴に基づいて、APのDHCP特徴を構成するために使われるYANGモデルhw-dhcp.yangを含む一連のYANGモデルがすでに定義されている。hw-dhcp.yangでは、APによって使用されるDHCPサーバー・グループの名前およびDHCPサーバーに対応するIPアドレスのような特徴に対応するデータ・モデルが定義される。たとえば、hw-dhcp.yangのシンタックス構造は次のようになる：
module  hw-dhcp  {
namespace  "urn:hw:params:xml:ns:yang:hw-dhcp";
prefix  hw-dhcp;
……
/*config  and  state  data*/
container  dhcp  {
list  dhcp-server-group  {
key  name;
leaf  name  {
description  "the  name  of  the  group";
type  string  {
length  "1..31";
}
}
leaf-list  ip-address  {
description  "ip  addresses  of  dhcp  servers  in  the  group";
max-elements  8;
type  inet:ip-address;
}
……
}
……
}  /*end  of  container  dhcp*/
……
}  /*end  of  module  hw-dhcp*/
【０１０２】
前記あらかじめ定義されたYANGモデルがmaster-device.yangであると想定され、master-device.yangのシンタックス構造は次のようになる：
module  master-device  {
……
container  master  {
list  dhcp-config{
key  dhcp-config-id;  //list型のデータは一意的なkey値を必要とする
leaf  dhcp-config-id  {
type  string  {
length  "1..31";
}
}
refer  hw-dhcp;  //デバイスのDHCP構成データを記述するためにhw-dhcp.yangが参照される
leaf-list  devices;  //DHCP構成データの目標デバイスを記述
leaf-list  device-groups;  //DHCP構成データの目標デバイス・グループを記述
}
list  dns-config{
key  dns-config-id;  //list型のデータは一意的なkey値を必要とする
……                //DNS特徴の記述
}
……
}  /*end  of  container  master  */
……
}  /*  end  of  module  master-device  */
【０１０３】
複数のYANGモデルを使ってモデリングされる構成データが、前記あらかじめ定義されたYANGモデルにおいて、複数の参照フィールドを使うことによって、参照されてもよく、構成データの各片の、目標となる、より低レベルのデバイスおよび／または目標となる、より低レベルのデバイスのグループが、別個に識別されてもよい。したがって、一つのNETCONFメッセージが、異なる、より低レベルのデバイス／より低レベルのデバイスのグループのために送達される異なる構成データを担持することができ、それにより構成処理効率を改善する。
【０１０４】
段階８０２：ネットワーク管理デバイスが、NETCONFに基づいて、管理されるデバイスに前記構成データを送る。
【０１０５】
ネットワーク管理デバイスは、モデリングが完了した前記構成データをエンコードするためにXML言語を使い、次いで、前記ネットワーク管理デバイスは、NETCONFメッセージを前記管理されるデバイスに送る。前記NETCONFメッセージは、エンコードされた構成データを担持する。
【０１０６】
対応して、管理されるデバイスは、NETCONFに基づいてネットワーク管理デバイスによって送られた構成データを受信する。
【０１０７】
段階８０３：管理されるデバイスが、あらかじめ定義されたYANGモデルに従って前記構成データをパースする。
【０１０８】
ネットワーク管理デバイスからNETCONFメッセージを受信した後、管理されるデバイスは、前記構成データを得るよう前記メッセージのコンテンツをパースするために前記あらかじめ定義されたYANGモデルを使う。
【０１０９】
任意的に、管理されるデバイスは、パースから得られた前記構成データを同じ構成データベースに記憶する。前記あらかじめ定義されたYANGモデルは、前記ネットワーク管理デバイスによって送達される前記NETCONFメッセージにおいて担持されるすべての構成データについてモデリングを実行するために使われる。それにより、管理されるデバイスは、異なる、より低レベルのデバイスおよびより低レベルのデバイスのグループについて複数の異なるデータベースを別個に維持することなく、あらかじめ定義されたYANGモデルに対応するデータベースを維持するだけでよい。これは、データベース構成および管理を単純化し、データ記憶処理手順を単純化する。
【０１１０】
段階８０４：管理されるデバイスが、パースから得られた前記構成データに従って、より低レベルのデバイスを構成する。
【０１１１】
i番目の参照フィールドにおいて参照されるYANGモデルを使ってモデリングされる目標構成データについて、管理されるデバイスは、i番目の参照フィールドに対応するオブジェクト・フィールドに従って前記目標構成データが送達されるべき、目標となる、より低レベルのデバイスを決定する。前記目標となる、より低レベルのデバイスは、i番目の参照フィールドに対応するオブジェクト・フィールドによって示される、より低レベルのデバイスおよび／またはi番目の参照フィールドに対応するオブジェクト・フィールドによって示される、より低レベルのデバイスのグループにおける、より低レベルのデバイスである。管理されるデバイスは、目標構成管理プロトコルに基づいて、前記目標構成データを前記目標となる、より低レベルのデバイスに送る。前記目標構成管理プロトコルは、前記管理されるデバイスおよび前記目標となる、より低レベルのデバイスによってサポートされる構成管理プロトコルである。
【０１１２】
管理されるデバイスと、より低レベルのデバイスとの間で使われる構成管理プロトコルは、本願の実施形態において限定されない。可能な実装では、図３のＡを参照するに、管理されるデバイスおよび目標となる、より低レベルのデバイスは、非NETCONFプロトコルに基づいて互いと通信する。たとえば、図３のＡに示されるデバイス縦続シナリオがWLANに適用されるとき、非NETCONFプロトコルはCAPWAPであってもよい。目標となる、より低レベルのデバイスに送達される必要がある目標構成データについて、管理されるデバイスは、目標構成データをCAPWAPパケットにカプセル化して、該CAPWAPパケットを目標となる、より低レベルのデバイスに送る。もう一つの可能な構成では、図３のＢを参照するに、管理されるデバイスは、NETCONFプロキシのはたらきをする。管理されるデバイスおよび目標となる、より低レベルのデバイスは、NETCONFに基づいて互いと通信する。目標となる、より低レベルのデバイスに送達される必要のある目標構成データについて、管理されるデバイスは、目標構成データをNETCONFメッセージにカプセル化して、該NETCONFメッセージを目標となる、より低レベルのデバイスに送る。もちろん、CAPWAPおよびNETCONFに加えて、目標構成管理プロトコルは、さらに、別の型の構成管理プロトコルであってもよい。前記別の型の構成管理プロトコルについては、目標となる、より低レベルのデバイスを構成し、管理するときに、管理されるデバイスによって実行される処理は、基本的に同様である。ここで詳細を再び述べることはしない。
【０１１３】
さらに、管理されるデバイスは、前記より低レベルのデバイスを構成した後、ネットワーク管理デバイスに応答メッセージをフィードバックしてもよい。応答メッセージをフィードバックする手順は、NETCONFにおいて指定された既存の機構を使って実装されてもよい。
【０１１４】
結論として、この実施形態で提供される方法によれば、構成データのモデルは、あらかじめ定義されたYANGモデルを使ってネットワーク管理デバイスによって確立され、構成データはNETCONFに基づいて、管理されるデバイスに送られ、管理されるデバイスが前記あらかじめ定義されたYANGモデルに従って前記構成モデルをパースし、パースから得られた構成データに従って前記より低レベルのデバイスを構成する。これは、デバイス縦続シナリオにおいてNETCONFメッセージにおいて構成データの、目標となる、より低レベルのデバイスを示すためにNETCONFメッセージに拡張フィールドが追加されるときに、解決策の普遍性が比較的貧弱であり、構成処理効率が比較的低く、データ記憶処理手順が比較的複雑であるという従来技術の問題を解決する。
【０１１５】
構成データを参照し、構成データの、目標となる、より低レベルのデバイスおよび／または目標となる、より低レベルのデバイスのグループを示すために、前記あらかじめ定義されたYANGモデルにおける参照フィールドおよびオブジェクト・フィールドを設計することによって、定義されているYANGモデルを修正することなく、あらかじめ定義されたYANGモデルが使用される。これは、下記の技術的効果を達成する。
【０１１６】
第一に、NETCONFメッセージに対して拡張フィールドが追加されず、よって、NETCONFは拡張される必要がない。よって、ネットワーク管理デバイスおよび管理されるデバイスは、いまだに標準的なNETCONFに基づいて互いと通信し、解決策の普遍性がよくなる。
【０１１７】
第二に、複数のYANGモデルを使ってモデリングされる構成データが、複数の参照フィールドを使うことによって、あらかじめ定義されたYANGモデルにおいて参照されることができ、構成データの各片の、目標となる、より低レベルのデバイスおよび／または目標となる、より低レベルのデバイスのグループが別個に同定されることができる。よって、一つのNETCONFメッセージが、異なる、より低レベルのデバイス／より低レベルのデバイスのグループのために送達される異なる構成データを担持することができ、それにより、構成処理効率を改善する。
【０１１８】
第三に、あらかじめ定義されたYANGモデルが、ネットワーク管理デバイスによって送達されるNETCONFメッセージにおいて担持されるすべての構成データについてモデリングを実行するために使われる。よって、管理されるデバイスは、異なる、より低レベルのデバイスおよびより低レベルのデバイスのグループのための複数の異なるデータベースを別個に維持することなく、あらかじめ定義されたYANGモデルに対応するデータベースを維持するだけでよい。これは、データベース構成および管理を単純化し、データ記憶処理手順を単純化する。
【０１１９】
さらに、YANGモデルにおいて、任意の定義されたYANGモデルの模式木を便利に参照するようYANG言語シンタックスを拡張するために、前記第一の文が追加される。これは、デバイス縦続シナリオにおけるYANGモデル再利用問題を解決し、NETCONFおよびYANGモデルを使うことによる、デバイス縦続シナリオにおける、より低レベルのデバイス構成を実装する。
【０１２０】
さらに、一つまたは複数の、より低レベルのデバイスまたは一つまたは複数の、より低レベルのデバイスのグループは、leaf-list特徴を使って定義できる。それにより、構成データの、目標となる、より低レベルのデバイスおよび／またはより低レベルのデバイスのグループを便利かつ柔軟に定義する。
【０１２１】
さらに、既存のYANG言語シンタックスにおいて、二つのYANGモデル再利用機構があることを注意しておくべきである。module-submoduleとuses-groupingである。
【０１２２】
module-submodule式に実装されるYANGモデル再利用機構は、次のようなものである：第一に、submodule〔サブモジュール〕が定義され、該submoduleがmodule〔モジュール〕に属する（belongs-to）ことを陳述し、該submoduleに対応する模式木が定義される；次いで、moduleが定義され、該moduleは先に定義されたsubmoduleを含む（include）。このようにして、submoduleによって定義された模式木がmoduleにおいて参照される。module-submodule式に実装されるYANGモデル再利用は、次の欠点をもつ：任意のsubmoduleまたはmoduleではなく、moduleに属する定義されたsubmoduleのみが、該moduleにおいて参照されることができる。しかしながら、定義されたYANGモデルでは、独立したmoduleは一般に、YANGモデルにおいて構成される機能特徴に従って形成される。したがって、あるmoduleにおいて、別のmoduleにおいて定義されている模式木を参照することは不可能である。
【０１２３】
さらに、uses-grouping式に実装されるYNAGモデル再利用は次のような欠点をもつ：usesはgroupingを使って定義されており、かつ現在のモデルまたは導入されたモデルにある模式木の再利用をサポートするのみである。しかしながら、定義されたYANGモデルにおけるどのYANGモデルも、YANGモデルのすべてのフィールドを含むgroupingを定義しない。したがって、uses-grouping式にデバイス縦続シナリオにおけるYANGモデル再利用問題を解決することも不可能である。
【０１２４】
上記の分析に基づいて、定義されたYANGモデルを修正することなくしては、module-submodule式またはuses-grouping式のいずれでも、デバイス縦続シナリオにおけるYANGモデル再利用問題を解決することは不可能である。本願のこの実施形態において提供される技術的解決策によれば、あるYANGモデルにおいて、任意の定義されたYANGモデルにおける模式木を便利に参照するよう、YANG言語シンタックスを拡張することによって、refer文が追加される。これは、デバイス縦続シナリオにおけるYANGモデル再利用問題を効果的に解決し、NETCONFおよびYANGモデルを使って、デバイス縦続シナリオにおける、より低レベルのデバイス構成の構成および管理を実装する。
【０１２５】
本願のこの実施形態において、YANG言語シンタックスにおいて追加される文の型が「refer文」と名付けられているのは単に記述のための例として使われていることをさらに注意しておくべきである。実際の応用では、追加される文の型は、参照文またはユーザー定義文などといった別の異なる名前を名付けられてもよい。本願のこの実施形態は、それに制限を設定するものではない。追加された文の型がどんな名前を付けられようとも、追加される文の機能は上記の「refer文」と同じである。つまり、追加される文は、あるYANGモデルにおいて、別のYANGモジュールによって定義された模式木を参照するために使われる。
【０１２６】
下記は、具体例を使って構成データのインスタンスを記述する。
【０１２７】
APのDHCP特徴を構成するために使われるYANGモデルhw-dhcp.yangに対応する構成データ・インスタンスは次のようになる：
<dhcp  xmlns="urn:hw:params:xml:hw-dhcp">
<dhcp-server-group>
<name>dhcp-cfg1<name>
<ip-address>10.163.18.1<ip-address>
<ip-address>10.163.23.6<ip-address>
<dhcp-server-group>
</dhcp>
【０１２８】
あらかじめ定義されたYANGモデルはlac-device.yangであるとする。lac-device.yangにおいて、hw-dhcp.yangは、LACの、より低レベルのデバイスであるAPのDHCP特徴を構成するためにrefer文を使って参照される。IPアドレス10.163.18.1および10.163.23.6は、名前がdhcp-cfg1である一つのdhcp-server-groupに属する。コントローラが、LACの、より低レベルのデバイスを構成するとき、dhcp-server-groupの構成データは、より低レベルのデバイスAP3およびより低レベルのデバイスのグループであるgroup1およびgroup2に、適用のために送達される。lac-device.yangに対応する構成データ・インスタンスは次のようなものである：
<lac  xmlns="urn:hw:params:xml:lac-dhcp">
<dhcp-config>
<dhcp-config-id>dhcp-id1<dhcp-config-id>
<hw-dhcp>
<hw-dhcp:dhcp>
<hw-dhcp:dhcp-server-group>
<hw-dhcp:name>dhcp-cfg1</hw-dhcp:name>
<hw-dhcp:ip-address>10.163.18.1</hw-dhcp:ip-address>
<hw-dhcp:ip-address>10.163.23.6</hw-dhcp:ip-address>
</hw-dhcp:dhcp-server-group>
</hw-dhcp:dhcp>
</hw-dhcp>
<aps>ap3</aps>
<ap-groups>group1</ap-groups>
<ap-groups>group2</ap-groups>
</dhcp-config>
……
</lac>
【０１２９】
下記は、本願の装置実施形態であり、該装置実施形態は、本願の方法実施形態を実行するために使われてもよい。本願の装置実施形態に開示されていない詳細については、本願の方法実施形態を参照されたい。
【０１３０】
図９を参照するに、図９は、本願のある実施形態に基づくNETCONFに基づくデバイス構成装置のブロック図である。この実施形態において提供される装置は、ネットワーク管理デバイスの一部または全体であってもよい。ネットワーク管理デバイスは、管理されるデバイスに接続されており、管理されるデバイスはいくつかの、より低レベルのデバイスに接続されており、ネットワーク管理デバイスおよび管理されるデバイスはNETCONFをサポートする。本装置は：モデリング・ユニット（英語：modeling  unit）９１０および送信ユニット９２０を含んでいてもよい。
【０１３１】
モデリング・ユニット９１０は、あらかじめ定義されたYANGモデルを使って構成データのモデルを確立する。
【０１３２】
前記あらかじめ定義されたYANGモデルはn個の参照フィールドおよび各参照フィールドに別個に対応するいくつかのオブジェクト・フィールドを含む。前記参照フィールドは、前記あらかじめ定義されたYANGモデルにおいて参照されるYANGモデルを示すために使われる。i番目の参照フィールドに対応するオブジェクト・フィールドは、i番目の参照フィールドにおいて参照されるYANGモデルを使ってモデリングされる目標構成データの、目標となる、より低レベルのデバイスおよび／または目標となる、より低レベルのデバイスのグループを示すために使われる。前記より低レベルのデバイスのグループは、いくつかのより低レベルのデバイスを含むグループである。1≦i≦nであり、iおよびnは正の整数である。
【０１３３】
送信ユニット９２０は、NETCONFに基づいて、前記モデリング・ユニット９１０によってモデリングされた前記構成データを、前記管理されるデバイスに送るよう構成される。
【０１３４】
結論として、この実施形態で提供される方法によれば、構成データのモデルは、あらかじめ定義されたYANGモデルを使ってネットワーク管理デバイスによって確立され、構成データはNETCONFに基づいて、管理されるデバイスに送られる。これは、デバイス縦続シナリオにおいてNETCONFメッセージにおいて構成データの、目標となる、より低レベルのデバイスを示すためにNETCONFメッセージに拡張フィールドが追加されるときに、解決策の普遍性が比較的貧弱であり、構成処理効率が比較的低く、データ記憶処理手順が比較的複雑であるという従来技術の問題を解決する。構成データを参照し、構成データの、目標となる、より低レベルのデバイスおよび／または目標となる、より低レベルのデバイスのグループを示すために、前記あらかじめ定義されたYANGモデルにおける参照フィールドおよびオブジェクト・フィールドを設計することによって、定義されているYANGモデルを修正することなく、あらかじめ定義されたYANGモデルが使用される。これは、解決策の普遍性を改善し、構成処理効率を高め、データベース構成および管理ならびにデータ記憶処理手順を単純化する。
【０１３５】
図９に示される実施形態に基づいて提供されるある任意的な実施形態では、参照フィールドが、第一の文を使って定義され、前記第一の文は、あるYANGモデルにおいて、別のYANGモデルによって定義される模式木を参照するために使われる。
【０１３６】
図９に示される実施形態に基づいて提供されるもう一つの任意的な実施形態では、オブジェクト・フィールドが、laef-list〔リーフ・リスト〕特徴を使って定義され、該leaf-list特徴は、同じ型のリーフ・ノードのグループを記述するために使われる。
【０１３７】
図９に示される実施形態に基づいて提供されるもう一つの任意的な実施形態では、i番目の参照フィールドに対応するオブジェクト・フィールドは：いくつかの第一のオブジェクト・フィールドおよび／またはいくつかの第二のオブジェクト・フィールドを含む。各第一のオブジェクト・フィールドは、i番目の参照フィールドにおいて参照されるYANGモデルを使ってモデリングされる目標構成データが送達される、より低レベルのデバイスを示すために使われる。各第二のオブジェクト・フィールドは、i番目の参照フィールドにおいて参照されるYANGモデルを使ってモデリングされる目標構成データが送達される、より低レベルのデバイスのグループを示すために使われる。
【０１３８】
図１０を参照するに、図１０は、本願のもう一つの実施形態に基づくNETCONFに基づくデバイス構成装置のブロック図である。この実施形態において提供される装置は、管理されるデバイスの一部または全体であってもよい。管理されるデバイスは、ネットワーク管理デバイスに接続されており、管理されるデバイスはさらに、いくつかの、より低レベルのデバイスに接続されており、ネットワーク管理デバイスおよび管理されるデバイスはNETCONFをサポートする。本装置は：受信ユニット１０１０、パース・ユニット１０２０および構成ユニット１０３０を含んでいてもよい。
【０１３９】
受信ユニット１０１０は、NETCONFに基づいてネットワーク管理デバイスによって送られた構成データを受信するよう構成される。
【０１４０】
前記構成データは、あらかじめ定義されたYANGモデルを使ってネットワーク管理デバイスによって構築されている。前記あらかじめ定義されたYANGモデルはn個の参照フィールドおよび各参照フィールドに別個に対応するいくつかのオブジェクト・フィールドを含む。前記参照フィールドは、前記あらかじめ定義されたYANGモデルにおいて参照されるYANGモデルを示すために使われる。i番目の参照フィールドに対応するオブジェクト・フィールドは、i番目の参照フィールドにおいて参照されるYANGモデルを使ってモデリングされる目標構成データの、目標となる、より低レベルのデバイスおよび／または目標となる、より低レベルのデバイスのグループを示すために使われる。前記より低レベルのデバイスのグループは、いくつかのより低レベルのデバイスを含むグループである。1≦i≦nであり、iおよびnは正の整数である。
【０１４１】
パース・ユニット１０２０は、前記あらかじめ定義されたYANGモデルに従って前記構成データをパースするよう構成される。
【０１４２】
構成ユニット１０３０は、パースから得られた前記構成データに従って、より低レベルのデバイスを構成するよう構成されている。
【０１４３】
結論として、この実施形態で提供される装置によれば、NETCONFに基づいてネットワーク管理デバイスによって送られた構成データが、管理されるデバイスによって受信され、前記構成データは、あらかじめ定義されたYANGモデルを使ってネットワーク管理デバイスによって構築されており、管理されるデバイスが、あらかじめ定義されたYANGモデルに従って前記構成データをパースし、パースから得られた前記構成データに従って、より低レベルのデバイスを構成する。これは、デバイス縦続シナリオにおいてNETCONFメッセージにおいて構成データの、目標となる、より低レベルのデバイスを示すためにNETCONFメッセージに拡張フィールドが追加されるときに、解決策の普遍性が比較的貧弱であり、構成処理効率が比較的低く、データ記憶処理手順が比較的複雑であるという従来技術の問題を解決する。構成データを参照し、構成データの、目標となる、より低レベルのデバイスおよび／または目標となる、より低レベルのデバイスのグループを示すために、前記あらかじめ定義されたYANGモデルにおける参照フィールドおよびオブジェクト・フィールドを設計することによって、定義されているYANGモデルを修正することなく、あらかじめ定義されたYANGモデルが使用される。これは、解決策の普遍性を改善し、構成処理効率を高め、データベース構成および管理ならびにデータ記憶処理手順を単純化する。
【０１４４】
図１０に示される実施形態に基づいて提供されるある任意的な実施形態では、構成ユニット１０３０は具体的には：
i番目の参照フィールドにおいて参照されるYANGモデルを使ってモデリングされる目標構成データについて、i番目の参照フィールドに対応するオブジェクト・フィールドに従って前記目標構成データが送達されるべき、目標となる、より低レベルのデバイスを決定する段階であって、前記目標となる、より低レベルのデバイスは、i番目の参照フィールドに対応するオブジェクト・フィールドによって示される、より低レベルのデバイスおよび／またはi番目の参照フィールドに対応するオブジェクト・フィールドによって示される、より低レベルのデバイスのグループにおける、より低レベルのデバイスである、段階と；
目標構成管理プロトコルに基づいて、前記目標構成データを前記目標となる、より低レベルのデバイスに送る段階であって、前記目標構成管理プロトコルは、前記管理されるデバイスおよび前記目標となる、より低レベルのデバイスによってサポートされる構成管理プロトコルである、段階とを実行するよう構成される。
【０１４５】
図１０に示される実施形態に基づいて提供されるもう一つの任意的な実施形態では、本装置はさらに、パースから得られた前記構成データを、同じ構成データベースに記憶するよう構成された記憶ユニットを含む。
【０１４６】
本願のある実施形態はさらに、NETCONFに基づくデバイス構成システムを提供する。図２を参照するに、該システムは、ネットワーク管理デバイスと、管理されるデバイスと、いくつかの、より低レベルのデバイスとを含む。ネットワーク管理デバイスは管理されるデバイスに接続されており、管理されるデバイスは上記のいくつかの、より低レベルのデバイスに接続されている。ネットワーク管理デバイスおよび管理されるデバイスはNETCONFをサポートする。ネットワーク管理デバイスは、図９に示される実施形態において提供されるデバイス構成装置を含む。管理されるデバイスは、図１０に示される実施形態において提供されるデバイス構成装置を含む。
【０１４７】
上記の実施形態において提供される装置がその機能を実装するとき、上記の機能ユニットの分割は単に、記述のための例として使われていることを注意しておくべきである。実際の応用では、上記の機能は、必要に応じて実装のための種々の機能ユニットに割り当てられてもよい。すなわち、デバイスの内部構造が、上記の機能の全部または一部を実装するために種々の機能ユニットに分割される。さらに、上記の実施形態において提供される装置実施形態および方法実施形態は、同じ概念に基づく、装置実施形態の具体的な実装プロセスについては、方法実施形態を参照されたい。ここで再び詳細を述べることはしない。
【０１４８】
当業者は、実施形態の段階の全部または一部がハードウェアまたは関係したハードウェアに命令するプログラムによって実装されうることを理解しうる。プログラムは、コンピュータ可読記憶媒体に記憶されてもよい。記憶媒体は、読み出し専用メモリ、磁気ディスク、光ディスクなどであってもよい。
【０１４９】
上記の記述は単に、本願の例示的実施形態であり、本願を限定することは意図されていない。本願の原理から外れることなくなされるいかなる修正、等価な置換または改善も、本願の保護範囲内にはいるべきである。
【図１】
2019514297.tif 000003
【図２】
2019514297.tif 000004
【図３Ａ】
2019514297.tif 000005
【図３Ｂ】
2019514297.tif 000006
【図４】
2019514297.tif 000007
【図５】
2019514297.tif 000008
【図６】
2019514297.tif 000009
【図７】
2019514297.tif 000010
【図８】
2019514297.tif 000011
【図９】
2019514297.tif 000012
【図１０】
2019514297.tif 000013
【手続補正書】
【提出日】平成30年10月26日(2018.10.26)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
ネットワーク構成プロトコルNETCONFに基づくデバイス構成方法であって、当該方法はネットワーク管理デバイスに適用され、前記ネットワーク管理デバイスは管理されるデバイスに接続され、前記管理されるデバイスは一つまたは複数の、より低レベルのデバイスに接続され、前記ネットワーク管理デバイスおよび前記管理されるデバイスはNETCONFをサポートし；
当該方法は：
あらかじめ定義されたYANGモデルを使って構成データのモデルを確立する段階であって、前記あらかじめ定義されたYANGモデルはn個の参照フィールドおよび各参照フィールドに別個に対応するオブジェクト・フィールドを含み、前記参照フィールドは、前記あらかじめ定義されたYANGモデルにおいて参照されるYANGモデルを示すために使われ、i番目の参照フィールドに対応するオブジェクト・フィールドは、前記i番目の参照フィールドにおいて参照されるYANGモデルを使ってモデリングされる目標構成データに対応する、目標となる、より低レベルのデバイスまたは目標となる、より低レベルのデバイスのグループを示すために使われ、前記目標となる、より低レベルのデバイスのグループは、一つまたは複数のより低レベルのデバイスを含むグループであり、1≦i≦nであり、iおよびnは正の整数である、段階と；
NETCONFに基づいて前記構成データを前記管理されるデバイスに送る段階とを含む、
方法。
【請求項２】
前記参照フィールドが、第一の文を使って定義され、前記第一の文は、あるYANGモデルにおいて、別のYANGモデルによって定義される模式木を参照するために使われる、請求項１記載の方法。
【請求項３】
前記オブジェクト・フィールドがlaef-list特徴を使って定義され、該leaf-list特徴は、同じ型のリーフ・ノードのグループを記述するために使われる、請求項１または２記載の方法。
【請求項４】
前記i番目の参照フィールドに対応する前記オブジェクト・フィールドは：第一のオブジェクト・フィールドまたは第二のオブジェクト・フィールドを含み；
前記第一のオブジェクト・フィールドは、前記i番目の参照フィールドにおいて参照される前記YANGモデルを使ってモデリングされる前記目標構成データが送達されるべき、より低レベルのデバイスを示すために使われ；
前記第二のオブジェクト・フィールドは、前記i番目の参照フィールドにおいて参照される前記YANGモデルを使ってモデリングされる前記目標構成データが送達されるべき、より低レベルのデバイスのグループを示すために使われる、
請求項１ないし３のうちいずれか一項記載の方法。
【請求項５】
ネットワーク構成プロトコルNETCONFに基づくデバイス構成方法であって、当該方法は管理されるデバイスに適用され、前記管理されるデバイスはネットワーク管理デバイスに接続され、前記管理されるデバイスはさらに、一つまたは複数の、より低レベルのデバイスに接続され、前記ネットワーク管理デバイスおよび前記管理されるデバイスはNETCONFをサポートし；
当該方法は：
NETCONFに基づいて前記ネットワーク管理デバイスによって送られた構成データを受信する段階と；
前記あらかじめ定義されたYANGモデルに従って前記構成データをパースする段階であって、前記あらかじめ定義されたYANGモデルはn個の参照フィールドおよび各参照フィールドに別個に対応するオブジェクト・フィールドを含み、前記参照フィールドは、前記あらかじめ定義されたYANGモデルにおいて参照されるYANGモデルを示すために使われ、i番目の参照フィールドに対応するオブジェクト・フィールドは、前記i番目の参照フィールドにおいて参照されるYANGモデルを使ってモデリングされる目標構成データに対応する、目標となる、より低レベルのデバイスまたは目標となる、より低レベルのデバイスのグループを示すために使われ、前記目標となる、より低レベルのデバイスのグループは、一つまたは複数のより低レベルのデバイスを含むグループであり、1≦i≦nであり、iおよびnは正の整数である、段階と；
パースから得られた前記構成データに従って、より低レベルのデバイスを構成する段階とを含む、
方法。
【請求項６】
パースから得られた前記構成データに従って、より低レベルのデバイスを構成する前記段階は：
前記i番目の参照フィールドにおいて参照される前記YANGモデルを使ってモデリングされる前記目標構成データについて、前記i番目の参照フィールドに対応する前記オブジェクト・フィールドに従って前記目標構成データの、目標となる、より低レベルのデバイスを決定する段階であって、前記目標となる、より低レベルのデバイスは、前記i番目の参照フィールドに対応するオブジェクト・フィールドによって示される、より低レベルのデバイスまたは前記i番目の参照フィールドに対応するオブジェクト・フィールドによって示される、より低レベルのデバイスのグループにおける、より低レベルのデバイスである、段階と；
目標構成管理プロトコルに基づいて、前記目標構成データを前記目標となる、より低レベルのデバイスに送る段階であって、前記目標構成管理プロトコルは、前記管理されるデバイスおよび前記目標となる、より低レベルのデバイスによってサポートされる構成管理プロトコルである、段階とを含む、
請求項５記載の方法。
【請求項７】
前記あらかじめ定義されたYANGモデルに従って前記構成データをパースした後、当該方法はさらに：
パースから得られた前記構成データを、前記あらかじめ定義されたYANGモデルに対応する構成データベースに記憶することを含む、
請求項５または６記載の方法。
【請求項８】
ネットワーク構成プロトコルNETCONFに基づくデバイス構成装置であって、当該装置はネットワーク管理デバイスに適用され、前記ネットワーク管理デバイスは管理されるデバイスに接続され、前記管理されるデバイスは一つまたは複数の、より低レベルのデバイスに接続され、前記ネットワーク管理デバイスおよび前記管理されるデバイスはNETCONFをサポートし；
当該装置は：
あらかじめ定義されたYANGモデルを使って構成データのモデルを確立するよう構成されたモデリング・ユニットであって、前記あらかじめ定義されたYANGモデルはn個の参照フィールドおよび各参照フィールドに別個に対応するオブジェクト・フィールドを含み、前記参照フィールドは、前記あらかじめ定義されたYANGモデルにおいて参照されるYANGモデルを示すために使われ、i番目の参照フィールドに対応するオブジェクト・フィールドは、前記i番目の参照フィールドにおいて参照されるYANGモデルを使ってモデリングされる目標構成データに対応する、目標となる、より低レベルのデバイスまたは目標となる、より低レベルのデバイスのグループを示すために使われ、前記より低レベルのデバイスのグループは、一つまたは複数のより低レベルのデバイスを含むグループであり、1≦i≦nであり、iおよびnは正の整数である、モデリング・ユニットと；
NETCONFに基づいて前記構成データを前記管理されるデバイスに送るよう構成された送信ユニットとを有する、
装置。
【請求項９】
参照フィールドが、第一の文を使って定義され、前記第一の文は、あるYANGモデルにおいて、別のYANGモデルによって定義される模式木を参照するために使われる、請求項８記載の装置。
【請求項１０】
オブジェクト・フィールドがlaef-list特徴を使って定義され、該leaf-list特徴は、同じ型のリーフ・ノードのグループを記述するために使われる、請求項８または９記載の装置。
【請求項１１】
前記i番目の参照フィールドに対応する前記オブジェクト・フィールドは：第一のオブジェクト・フィールドまたは第二のオブジェクト・フィールドを含み；
前記第一のオブジェクト・フィールドは、前記i番目の参照フィールドにおいて参照される前記YANGモデルを使ってモデリングされる前記目標構成データが送達されるべき、より低レベルのデバイスを示すために使われ；
前記第二のオブジェクト・フィールドは、前記i番目の参照フィールドにおいて参照される前記YANGモデルを使ってモデリングされる前記目標構成データが送達されるべき、より低レベルのデバイスのグループを示すために使われる、
請求項８ないし１０のうちいずれか一項記載の装置。
【請求項１２】
ネットワーク構成プロトコルNETCONFに基づくデバイス構成装置であって、当該装置は管理されるデバイスに適用され、前記管理されるデバイスはネットワーク管理デバイスに接続され、前記管理されるデバイスはさらに、一つまたは複数の、より低レベルのデバイスに接続され、前記ネットワーク管理デバイスおよび前記管理されるデバイスはNETCONFをサポートし；
当該装置は：
NETCONFに基づいて前記ネットワーク管理デバイスによって送られた構成データを受信するよう構成された受信ユニットと；
前記あらかじめ定義されたYANGモデルに従って前記構成データをパースするよう構成されたパース・ユニットであって、前記あらかじめ定義されたYANGモデルはn個の参照フィールドおよび各参照フィールドに別個に対応するオブジェクト・フィールドを含み、前記参照フィールドは、前記あらかじめ定義されたYANGモデルにおいて参照されるYANGモデルを示すために使われ、i番目の参照フィールドに対応するオブジェクト・フィールドは、前記i番目の参照フィールドにおいて参照されるYANGモデルを使ってモデリングされる目標構成データに対応する、目標となる、より低レベルのデバイスまたは目標となる、より低レベルのデバイスのグループを示すために使われ、前記より低レベルのデバイスのグループは、一つまたは複数のより低レベルのデバイスを含むグループであり、1≦i≦nであり、iおよびnは正の整数である、パース・ユニットと；
パースから得られた前記構成データに従って、より低レベルのデバイスを構成するよう構成された構成ユニットとを有する、
装置。
【請求項１３】
前記構成ユニットが具体的には：
前記i番目の参照フィールドにおいて参照される前記YANGモデルを使ってモデリングされる前記目標構成データについて、前記i番目の参照フィールドに対応する前記オブジェクト・フィールドに従って前記目標構成データの、目標となる、より低レベルのデバイスを決定する段階であって、前記目標となる、より低レベルのデバイスは、前記i番目の参照フィールドに対応するオブジェクト・フィールドによって示される、より低レベルのデバイスまたは前記i番目の参照フィールドに対応するオブジェクト・フィールドによって示される、より低レベルのデバイスのグループにおける、より低レベルのデバイスである、段階と；
目標構成管理プロトコルに基づいて、前記目標構成データを前記目標となる、より低レベルのデバイスに送る段階であって、前記目標構成管理プロトコルは、前記管理されるデバイスおよび前記目標となる、より低レベルのデバイスによってサポートされる構成管理プロトコルである、段階とを実行するよう構成されている、
請求項１２記載の装置。
【請求項１４】
当該装置がさらに：
パースから得られた前記構成データを、前記あらかじめ定義されたYANGモデルに対応する構成データベースに記憶するよう構成された記憶ユニットを有する、
請求項１２または１３記載の装置。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【発明の詳細な説明】
【技術分野】
【０００１】
関連出願への相互参照
本願は2016年4月15日に中国特許庁に出願された「ネットワーク構成プロトコルに基づくデバイス構成方法および装置」と題する中国特許出願第201610234776.9号の優先権を主張するものである。同出願の内容はここに参照によってその全体において組み込まれる。
【０００２】
技術分野
本願は通信技術の分野に、詳細にはネットワーク構成プロトコルに基づくデバイス構成方法および装置に関する。
【背景技術】
【０００３】
ネットワーク構成プロトコル（英語：Network  Configuration  Protocol、略NETCONF）は、拡張可能マークアップ言語（英語：Extensible  Markup  Language、略XML）に基づくネットワーク管理プロトコルである。NETCONFは、安全トランスポート（英語：Secure  Transport）層、メッセージ（英語：Messages）層、動作（英語：Operations）層およびコンテンツ（英語：Content）層を含む四層アーキテクチャーを使う。現在のところ、NETCONFの安全トランスポート層、メッセージ層および動作層は標準で定義されているが、コンテンツ層には、標準的なデータ・モデリング言語または関係したデータ・モデルがない。これは、NETCONFの実際の普及および応用を制約する重要な要因である。
【０００４】
近年、YANG（英語：Yet  Another  Next  Generation）データ・モデリング言語（英語：data  modeling  language）が、インターネット技術特別調査委員会（英語：Internet  Engineering  Task  Force、略IETF）によって標準的なNETCONFデータ・モデリング言語として使われている。YANGデータ・モデリング言語は、構成データのモデル（英語：model  configuration  data）を確立するのみならず、さまざまな動作および通知のモデルを確立するためにも使われることができ、よって、良好な可読性およびスケーラビリティーをもつ。現在のところ、YANG言語は、NETCONFのコンテンツ層、動作層およびメッセージ層のためのデータ・モデリングを実行するために使用できる。
【０００５】
NETCONFは、クライアント／サーバー（英語：Client/Server、略C/S）アーキテクチャーを使う。図１に示されるように、図１はNETCONFとYANGとの間の関係の概略図である。NETCONFクライアントおよびNETCONFサーバーは、NETCONFに基づいて互いと通信する。NETCONFクライアントはYANG言語を使って構成データのモデルを確立し、モデリング後に得られた構成データを、XMLを使ってエンコードして、XMLファイルを得る。NETCONFクライアントによってNETCONFサーバーに送達されるNETCONFメッセージは、XMLファイルを担持する。NETCONFクライアントからNETCONFメッセージを受信後、NETCONFサーバーは、該メッセージのコンテンツに対してパース処理を実行して、構成データを得る。
【０００６】
図２に示されるように、図２は、デバイス縦続シナリオの概略図を示している。ネットワーク管理デバイス２１は、管理されるデバイス２２に接続されており、管理されるデバイス２２はいくつかのより低レベルのデバイス２３に接続される。ネットワーク管理デバイス２１はNETCONFクライアントのはたらきをし、管理されるデバイス２２はNETCONFサーバーのはたらきをする。ネットワーク管理デバイス２１および管理されるデバイス２２はNETCONFに基づいて互いと通信する。管理されるデバイス２２およびより低レベルのデバイス２３は、任意の構成管理プロトコルに基づいて互いと通信しうる。たとえば、管理されるデバイス２２およびより低レベルのデバイス２３は、無線アクセス・ポイントのコントロールおよびプロビジョニング（英語：Control  and  Provisioning  of  Wireless  Access  Points、略CAPWAP）に基づいて互いと通信する。ネットワーク管理デバイス２１は、NETCONFを使って、管理されるデバイス２２およびより低レベルのデバイス２３を構成する。より低レベルのデバイス２３は、ネットワーク管理デバイス２１に直接接続されてはいないが、管理されるデバイス２２によって送られた構成データを、CAPWAPを使って受信する。管理されるデバイス２２は、ネットワーク管理デバイス２１によって送られた構成データを受信する。該構成データは、管理されるデバイス２２のための構成データおよびより低レベルのデバイス２３のための構成データを含む。より低レベルのデバイス２３のためにネットワーク管理デバイス２１によって送られた構成データについては、管理されるデバイス２２は、ネットワーク管理デバイス２１によって送達されたNETCONFの終着点になり、該メッセージのコンテンツに対してパース処理を実行して前記構成データを取得し、前記構成データをCAPWAPパケットにカプセル化し直して、該CAPWAPパケットを、より低レベルのデバイス２３に送る。
【０００７】
図２に示されるデバイス縦続シナリオでは、構成および管理のためにNETCONFが使われるとき、次の問題が存在する。標準的なNETCONFメッセージでは、構成データと構成されるデバイスとの間の関係が反映されない。すなわち、管理されるデバイス２２は、NETCONFメッセージにおいて担持される構成データが届けられる、より低レベルのデバイス２３（単数または複数）を知ることができない。上記の問題を解決するために、従来技術においては、NETCONFメッセージに拡張フィールドが追加され、該拡張フィールドが追加的な情報を転送するために使われる。具体的には、ネットワーク管理デバイス２１によって管理されるデバイス２２に送達されるNETCONFメッセージは、コンテンツ・フィールドおよび拡張フィールドを含む。コンテンツ・フィールドは、YANG言語を使って定義されるデータ・モデルに従って構成データを担持する。拡張フィールドは、デバイス情報を担持し、デバイス情報は、NETCONFメッセージにおける構成データの、目標となる、より低レベルのデバイスを示すために使われる。
【０００８】
しかしながら、従来技術には、少なくとも以下の技術的欠点がある。
【０００９】
１．プライベートなデバイス情報を加えるためにNETCONFメッセージに拡張フィールドが追加される必要がある。結果として、ネットワーク管理デバイスと、サードパーティー・プロバイダーによって提供される管理されるデバイスは、互いと連係動作することができず、この解決策の普遍性は比較的貧弱である。
【００１０】
２．一つのNETCONFメッセージは、一つのより低レベルのデバイスのための構成データまたはいくつかのより低レベルのデバイスのための同じ構成データを担持することしかできない。異なる構成データは、複数のNETCONFメッセージにおいて複数回で送られる必要がある。結果として、構成処理の効率は比較的低い。
【００１１】
３．管理されるデバイスが、拡張フィールドに従って異なるより低レベルのデバイスのための複数の異なるデータベースを生成して、対応する構成データを別々に記憶するようにする必要がある。結果として、データ記憶処理手順が比較的複雑である。
【発明の概要】
【００１２】
本願の実施形態は、デバイス縦続シナリオにおいてNETCONFメッセージにおいて構成データの、目標となる、より低レベルのデバイスを示すためにNETCONFメッセージに拡張フィールドが追加されるときに、解決策の普遍性が比較的貧弱であり、構成処理効率が比較的低く、データ記憶処理手順が比較的複雑であるという従来技術の問題を解決するための、ネットワーク構成プロトコルに基づくデバイス構成方法および装置を提供する。技術的解決策は次のとおり。
【００１３】
第一の側面によれば、NETCONFに基づくデバイス構成方法が提供され、該方法はネットワーク管理デバイスに適用される。ネットワーク管理デバイスは管理されるデバイスに接続されており、管理されるデバイスはいくつかの、より低レベルのデバイスに接続されており、ネットワーク管理デバイスおよび管理されるデバイスはNETCONFをサポートする。本方法は、あらかじめ定義されたYANGモデルを使って構成データのモデルを確立する段階であって、前記あらかじめ定義されたYANGモデルはn個の参照フィールドおよび各参照フィールドに別個に対応するいくつかのオブジェクト・フィールドを含み、前記参照フィールドは、前記あらかじめ定義されたYANGモデルにおいて参照されるYANGモデルを示すために使われ、i番目の参照フィールドに対応するオブジェクト・フィールドは、i番目の参照フィールドにおいて参照されるYANGモデルを使ってモデリングされる目標構成データに対応する、目標となる、より低レベルのデバイスおよび／または目標となる、より低レベルのデバイスのグループを示すために使われ、前記より低レベルのデバイスのグループは、いくつかのより低レベルのデバイスを含むグループであり、1≦i≦nであり、iおよびnは正の整数である、段階と；NETCONFに基づいて前記構成データを前記管理されるデバイスに送る段階とを含む。
【００１４】
第一の側面の第一の可能な実装では、参照フィールドは、第一の文を使って定義され、前記第一の文は、あるYANGモデルにおいて、別のYANGモデルによって定義される模式木を参照するために使われる。
【００１５】
第一の側面または第一の側面の第一の可能な実装を参照するに、第一の側面の第二の可能な実装では、オブジェクト・フィールドは、laef-list〔リーフ・リスト〕特徴を使って定義され、該leaf-list特徴は、同じ型のリーフ・ノードのグループを記述するために使われる。
【００１６】
第一の側面、第一の側面の第一の可能または第一の側面の第二の可能を参照するに、第一の側面の第三の可能な実装では、i番目の参照フィールドに対応するオブジェクト・フィールドは：いくつかの第一のオブジェクト・フィールドおよび／またはいくつかの第二のオブジェクト・フィールドを含む。各第一のオブジェクト・フィールドは、i番目の参照フィールドにおいて参照されるYANGモデルを使ってモデリングされる目標構成データが送達される、より低レベルのデバイスを示すために使われる。各第二のオブジェクト・フィールドは、i番目の参照フィールドにおいて参照されるYANGモデルを使ってモデリングされる目標構成データが送達される、より低レベルのデバイスのグループを示すために使われる。
【００１７】
第二の側面によれば、NETCONFに基づくデバイス構成方法が提供され、該方法は管理されるデバイスに適用される。管理されるデバイスはネットワーク管理デバイスに接続されており、管理されるデバイスはさらに、いくつかの、より低レベルのデバイスに接続されており、ネットワーク管理デバイスおよび管理されるデバイスはNETCONFをサポートする。本方法は、NETCONFに基づいてネットワーク管理デバイスによって送られた構成データを受信する段階であって、前記構成データは、あらかじめ定義されたYANGモデルを使ってネットワーク管理デバイスによってモデリングされている、段階と；前記あらかじめ定義されたYANGモデルに従って前記構成データをパースする段階と；パースから得られた前記構成データに従って、より低レベルのデバイスを構成する段階とを含む。
【００１８】
第二の側面の第一の可能な実装では、パースから得られた前記構成データに従って、より低レベルのデバイスを構成する前記段階は、i番目の参照フィールドにおいて参照されるYANGモデルを使ってモデリングされる目標構成データについて、i番目の参照フィールドに対応するオブジェクト・フィールドに従って前記目標構成データの、目標となる、より低レベルのデバイスを決定する段階であって、前記目標となる、より低レベルのデバイスは、i番目の参照フィールドに対応するオブジェクト・フィールドによって示される、より低レベルのデバイスおよび／またはi番目の参照フィールドに対応するオブジェクト・フィールドによって示される、より低レベルのデバイスのグループにおける、より低レベルのデバイスである、段階と；目標構成管理プロトコルに基づいて、前記目標構成データを前記目標となる、より低レベルのデバイスに送る段階であって、前記目標構成管理プロトコルは、前記管理されるデバイスおよび前記目標となる、より低レベルのデバイスによってサポートされる構成管理プロトコルである、段階とを含む。
【００１９】
第二の側面または第二の側面の第一の可能な実装を参照するに、第二の側面の第二の可能な実装では、前記あらかじめ定義されたYANGモデルに従って前記構成データをパースした後、本方法はさらに：パースから得られた前記構成データを、同じ構成データベースに記憶することを含む。
【００２０】
第三の側面によれば、NETCONFに基づくデバイス構成装置が提供され、該装置は、少なくとも一つのユニットを含み、該少なくとも一つのユニットは、前記第一の側面または第一の側面のいずれかの可能な実装において提供されるデバイス構成方法を実装するよう構成される。
【００２１】
第四の側面によれば、NETCONFに基づくデバイス構成装置が提供され、該装置は、少なくとも一つのユニットを含み、該少なくとも一つのユニットは、前記第二の側面または第二の側面のいずれかの可能な実装において提供されるデバイス構成方法を実装するよう構成される。
【００２２】
第五の側面によれば、NETCONFに基づくデバイス構成システムが提供され、該システムは、ネットワーク管理デバイスと、管理されるデバイスと、いくつかの、より低レベルのデバイスとを含む。ネットワーク管理デバイスは管理されるデバイスに接続されており、管理されるデバイスはいくつかの、より低レベルのデバイスに接続されており、ネットワーク管理デバイスおよび管理されるデバイスはNETCONFをサポートする。ネットワーク管理デバイスは、第三の側面で記載されたデバイス構成装置を含む。管理されるデバイスは、第四の側面で記載されたデバイス構成装置を含む。
【００２３】
第六の側面によれば、ネットワーク管理デバイスが提供される。ネットワーク管理デバイスは、プロセッサと、メモリと、トランシーバとを含む。メモリは、一つまたは複数の命令を記憶するよう構成される。命令は、プロセッサによって実行されるよう構成される。該命令は、前記第一の側面または第一の側面のいずれかの可能な実装において提供されるデバイス構成方法を実装するために使われる。
【００２４】
第七の側面によれば、管理されるデバイスが提供される。管理されるデバイスは、プロセッサと、メモリと、トランシーバとを含む。メモリは、一つまたは複数の命令を記憶するよう構成される。命令は、プロセッサによって実行されるよう構成される。該命令は、前記第二の側面または第二の側面のいずれかの可能な実装において提供されるデバイス構成方法を実装するために使われる。
【００２５】
本願の実施形態において提供される技術的解決策は、以下の有益な効果をもたらす。
【００２６】
構成データのモデルは、あらかじめ定義されたYANGモデルを使ってネットワーク管理デバイスによって確立され、構成データはNETCONFに基づいて、管理されるデバイスに送られ、管理されるデバイスは、あらかじめ定義されたYANGモデルに従って該構成データをパースし、パースから得られた構成データに従って、より低レベルのデバイスを構成する。これは、デバイス縦続シナリオにおいてNETCONFメッセージにおいて構成データの、目標となる、より低レベルのデバイスを示すためにNETCONFメッセージに拡張フィールドが追加されるときに、解決策の普遍性が比較的貧弱であり、構成処理効率が比較的低く、データ記憶処理手順が比較的複雑であるという従来技術の問題を解決する。
【００２７】
構成データを参照し、構成データの、目標となる、より低レベルのデバイスおよび／または目標となる、より低レベルのデバイスのグループを示すために、前記あらかじめ定義されたYANGモデルにおける参照フィールドおよびオブジェクト・フィールドを設計することによって、定義されているYANGモデルを修正することなく、あらかじめ定義されたYANGモデルが使用される。
【００２８】
第一に、NETCONFメッセージに対して拡張フィールドが追加されず、よって、NETCONFは拡張される必要がない。よって、ネットワーク管理デバイスおよび管理されるデバイスは、いまだに標準的なNETCONFに基づいて互いと通信し、解決策の普遍性がよくなる。
【００２９】
第二に、複数のYANGモデルを使ってモデリングされる構成データが、複数の参照フィールドを使うことによって、あらかじめ定義されたYANGモデルにおいて参照されることができ、構成データの各片の、目標となる、より低レベルのデバイスおよび／または目標となる、より低レベルのデバイスのグループが別個に同定されることができる。よって、一つのNETCONFメッセージが、異なる、より低レベルのデバイス／より低レベルのデバイスのグループのために送達される異なる構成データを担持することができ、それにより、構成処理効率を改善する。
【００３０】
第三に、あらかじめ定義されたYANGモデルが、ネットワーク管理デバイスによって送達されるNETCONFメッセージにおいて担持されるすべての構成データについてモデリングを実行するために使われる。よって、管理されるデバイスは、異なる、より低レベルのデバイスおよびより低レベルのデバイスのグループのための複数の異なるデータベースを別個に維持することなく、あらかじめ定義されたYANGモデルに対応するデータベースを維持するだけでよい。これは、データベース構成および管理を単純化し、データ記憶処理手順を単純化する。
【図面の簡単な説明】
【００３１】
本願の実施形態における技術的解決策をより明瞭に記述するために、下記は、実施形態または従来技術を記述するために必要とされる付属の図面を手短かに説明する。
【００３２】
【図１】NETCONFとYANGの間の関係の概略図である。
【００３３】
【図２】デバイス縦続シナリオの概略図である。
【００３４】
【図３Ａ】本願のある実施形態に基づく応用シナリオの概略図である。
【００３５】
【図３Ｂ】本願のある実施形態に基づく別の応用シナリオの概略図である。
【００３６】
【図４】無線ローカルエリアネットワークにおけるデバイス縦続シナリオのネットワーク・アーキテクチャーの図である。
【００３７】
【図５】図５Ａおよび図５Ｂは、本願のある実施形態に基づくネットワーク・デバイスのブロック図である。
【００３８】
【図６】本願のある実施形態に基づくNETCONFに基づくデバイス構成方法のフローチャートである。
【００３９】
【図７】本願の別の実施形態に基づくNETCONFに基づくデバイス構成方法のフローチャートである。
【００４０】
【図８】本願の別の実施形態に基づくNETCONFに基づくデバイス構成方法のフローチャートである。
【００４１】
【図９】本願のある実施形態に基づくNETCONFに基づくデバイス構成装置のブロック図である。
【００４２】
【図１０】本願の別の実施形態に基づくNETCONFに基づくデバイス構成装置のブロック図である。
【発明を実施するための形態】
【００４３】
本願の目的、技術的解決策および利点を一層明瞭にするために、下記は、付属の図面を参照して本願の実装をより詳細に記述する。
【００４４】
本明細書において言及される「モジュール」は、いくつかの機能を実装することのできる、メモリに記憶されるプログラムまたは命令である。本明細書において言及される「ユニット」は、論理に従って分割された機能的な構造である。「ユニット」は、ハードウェアのみによって実装されるか、ソフトウェアとハードウェアの組み合わせによって実装されることができる。
【００４５】
本明細書において言及される「いくつかの」は一つまたは複数であり、「複数」は二つ以上である。用語「および／または」は、関連するオブジェクトを記述するための関連関係を記述し、三つの関係が存在しうることを表わす。たとえば、Aおよび／またはBは、以下の三つの場合を表わしうる：Aのみが存在、AおよびBの両方が存在、およびBのみが存在。記号「／」は一般に、関連するオブジェクトの間の「または」の関係を示す。
【００４６】
本願の実施形態において提供される技術的解決策は、図２に示されるデバイス縦続シナリオに適用される。ある可能な実装では、図３Ａに示されるように、ネットワーク管理デバイス２１がNETCONFクライアントのはたらきをし、管理されるデバイス２２がNETCONFサーバーのはたらきをする。ネットワーク管理デバイス２１および管理されるデバイス２２はNETCONFに基づいて互いと通信し、管理されるデバイス２２およびより低レベルのデバイス２３は、非NETCONFプロトコルに基づいて互いと通信する。たとえば、デバイス縦続シナリオが無線ローカルエリアネットワーク（英語：wireless  local  area  network、略WLAN）に適用されるとき、非NETCONFプロトコルはCAPWAPであってもよい。
【００４７】
もう一つの可能な実装では、図３Ｂに示されるように、ネットワーク管理デバイス２１がNETCONFクライアントのはたらきをし、管理されるデバイス２２がNETCONFプロキシのはたらきをし、より低レベルのデバイス２３がNETCONFサーバーのはたらきをする。ネットワーク管理デバイス２１にとっては、NETCONFプロキシはNETCONFサーバーの機能を実装する。より低レベルのデバイス２３にとっては、NETCONFプロキシはNETCONFクライアントの機能を実装する。ネットワーク管理デバイス２１および管理されるデバイス２２はNETCONFに基づいて互いと通信し、管理されるデバイス２２およびより低レベルのデバイス２３も、NETCONFプロトコルに基づいて互いと通信する。
【００４８】
NETCONFクライアント、NETCONFサーバーおよびNETCONFプロキシのすべては、デバイスにおいて走っているソフトウェア・プロセスであり、ハードウェアではないことを注意しておくべきである。
【００４９】
図４に示されるように、WLANにおけるデバイス縦続シナリオが例として使われる。ネットワーク・アーキテクチャーは：コントローラ４１と、ローカル・アクセス・コントローラ（英語：local  access  controller、略LAC）４２と、いくつかのアクセス・ポイント（英語：access  point、略AP）とを含む。コントローラ４１およびLAC  ４２はNETCONFに基づいて互いと通信する。LAC  ４２およびAPは、CAPWAPに基づいて互いと通信する。
【００５０】
コントローラ４１はNETCONFクライアントのはたらきをする。コントローラ４１は、NETCONFを使ってLAC  ４２および各APを構成するよう構成される。コントローラ４１は、中央集中式コントローラまたは敏捷コントローラと称されてもよく、コントローラ４１に従属するすべてのAPを管理するよう構成される。コントローラ４１に従属させられ、コントローラ４１によって管理されるAPの数は、数十万またはさらには数百万に達することもできる。
【００５１】
LAC  ４２はNETCONFサーバーのはたらきをする。LAC  ４２は、コントローラ４１によって送られた構成データを受信するよう構成され、該構成データは、LAC  ４２のための構成データおよびLAC  ４２によって管理されるAPのための構成データを含む。コントローラ４１によって送達されるNETCONFメッセージについて、LAC  ４２は該NETCONFメッセージの終着点になり、該メッセージのコンテンツをパースして前記構成データを取得し、該構成データをCAPWAPパケットにカプセル化し直して、該CAPWAPパケットを対応するAPに送る。LAC  ４２は、軽量アクセス・コントローラ（英語：light  access  controller）と称されてもよい。LAC  ４２およびAPは、ローカルエリアネットワークを使って通信接続を確立する。たとえば、LAC  ４２は、一つまたは複数のレベルのスイッチを使ってAPに接続されてもよい。もう一つの例として、LAC  ４２は、一つまたは複数のレベルのルーターを使ってAPに接続されてもよい。
【００５２】
APは、コントローラ４１に直接接続されるのではなく、LAC  ４２によって送られた構成データをCAPWAPを使って受信する。
【００５３】
さらに、各LAC  ４２は、いくつかのAPおよび／またはいくつかのAPグループを管理するよう構成されてもよい。各APグループは少なくとも一つのAPを含む。たとえば、図４の左側のLAC  ４２はAP3および二つのAPグループ（グループ１およびグループ２）を管理するよう構成される。グループ１はAP1およびAP2を含み、グループ２はAP4を含む。
【００５４】
拡張フィールドがNETCONFメッセージに追加される従来技術の仕方がAPの特徴、たとえば動的ホスト構成プロトコル（英語：Dynamic  Host  Configuration  Protocol、略DHCP）およびドメイン名システム（Domain  Name  System、略DNS）を構成するために使われる場合には、具体的な手順は次のようになる。
【００５５】
１．コントローラがYANGモデルを使って構成データのモデルを確立する。
【００５６】
APのDHCP特徴を構成する例では、対応するYANGモデルはhw-dhcp.yangであると想定され、コントローラは、hw-dhcp.yangによって定義されるデータ・モデルを使ってDHCP構成データに対してモデリングを実行する。
【００５７】
２．コントローラがNETCONFメッセージを生成する。
【００５８】
NETCONFメッセージは、コンテンツ・フィールドおよび拡張フィールドを含む。コンテンツ・フィールドは、YANGモデルを使って構築された構成データ、たとえばhw-dhcp.yangを使ってモデリングされたDHCP構成データを担持する。拡張フィールドは、デバイス情報を担持する。デバイス情報は、NETCONFメッセージ中の構成データが送達されるべきAPおよび／またはAPグループを示すために使われる。たとえば、DHCP構成データがAP3ならびにグループ１内のAP1およびAP2のすべてに適用可能であるとき、拡張フィールドは、AP3およびグループ１に対応する識別情報を担持する。
【００５９】
たとえば、NETCONFメッセージは次のようなものである：
<rpc  message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<device-group>  group1  </device-group>
<device-name>  ap3  </device-name>
<edit-config>
<!--  method  parameters  here...  -->
</  edit-config  >
</rpc>
【００６０】
３．コントローラがNETCONFメッセージをLACに送る。
【００６１】
対応して、LACはNETCONFメッセージをコントローラから受信する。
【００６２】
４．LACがNETCONFメッセージをパースして、拡張フィールドに担持されているデバイス情報およびコンテンツ・フィールドに担持されている構成データを取得する。
【００６３】
５．LACが構成データを、拡張フィールドによって示されるAPおよび／またはAPグループに対応するデータベースに別個に記憶する。
【００６４】
たとえば、LACは、グループ１に対応するデータベースDB1に前記DHCP構成データを記憶し、AP3に対応するデータベースDB2に前記DHCP構成データを記憶する。
【００６５】
６．LACは、デバイス情報および構成データに従ってAPを構成する。
【００６６】
データベース中の構成データが変更されたことを検出した後、APを構成および管理するよう構成された、LAC内の機能モジュールが、データベースから構成データを読み、該構成データを対応するAPおよび／またはAPグループに別個に送る。
【００６７】
したがって、デバイス縦続シナリオにおいて、より低レベルのデバイスを構成するために拡張フィールドがNETCONFメッセージに追加される従来技術の仕方が使われるときには、解決策の普遍性が比較的貧弱であり、構成処理効率が比較的低く、データ記憶処理手順が比較的複雑であるという問題がある。
【００６８】
下記は、本願で提供される技術的解決策を、いくつかの実施形態を使って記述する。
【００６９】
図５Ａおよび図５Ｂを参照するに、図５Ａおよび図５Ｂは、本願のある実施形態に基づくネットワーク・デバイスのブロック図である。ネットワーク・デバイス５００は、本願の実施形態におけるネットワーク管理デバイス（たとえば、図４に示したネットワーク・アーキテクチャーにおけるコントローラ）であってもよく、あるいは本願の実施形態における管理されるデバイス（たとえば図４に示したネットワーク・アーキテクチャーにおけるLAC）であってもよい。
【００７０】
ネットワーク・デバイス５００は：プロセッサ５１０と、メモリ５２０と、トランシーバ５３０と、バス５４０とを含んでいてもよい。メモリ５２０およびトランシーバ５３０は、バス５４０を使ってプロセッサ５１０に接続される。
【００７１】
プロセッサ５１０は、一つまたは複数の処理コアを含む。プロセッサ５１０は、ソフトウェア・プログラムおよびモジュールを実行することによって、さまざまな機能アプリケーションおよびデータ処理を実行する。プロセッサ５１０は、BizLetコンポーネント、レジスタ・コンポーネント、制御コンポーネントなどを含む。プロセッサ５１０は、独立した中央処理ユニットであってもよく、あるいは埋め込み型のプロセッサ、たとえばマイクロプロセッサ（英語：microprocessor  unit、略MPU）、マイクロコントローラ（英語：micro-controller  unit、略MCU）またはデジタル信号プロセッサ（英語：digital  signal  processor、略DSP）であってもよい。
【００７２】
メモリ５２０は、いかなる型の揮発性または不揮発性記憶デバイスまたはそれらの組み合わせであってもよく、静的ランダムアクセスメモリ（英語：static  random  access  memory、略SRAM）、電気的に消去可能なプログラム可能型読み出し専用メモリ（英語：electrically  erasable  programmable  read-only  memory、略EEPROM）、消去可能なプログラム可能型読み出し専用メモリ（英語：erasable  programmable  read-only  memory、略EPROM）、プログラム可能型読み出し専用メモリ（英語：programmable  read-only  memory、略PROM）、読み出し専用メモリ（英語：read-only  memory、略ROM）、磁気メモリ、フラッシュメモリ、ディスクまたは光ディスクなどであってもよい。メモリ５２０は、ソフトウェア・プログラムおよびモジュールのような実行可能命令を記憶するよう構成されてもよい。
【００７３】
プロセッサ５１０は、メモリ５２０に記憶された命令を実行するよう構成される。ネットワーク・デバイス５００がネットワーク管理デバイスであるとき、プロセッサ５１０は、命令を実行することによって次の方法を実装する：あらかじめ定義されたYANGモデルを使って構成データのモデルを確立し；トランシーバ５３０を制御して該構成データをNETCONFに基づいて、管理されるデバイスに送る。あらかじめ定義されたYANGモデルは、n個の参照フィールドと、各参照フィールドに別個に対応するいくつかのオブジェクト・フィールドとを含む。参照フィールドは、あらかじめ定義されたYANGモデルにおいて参照されるYANGモデルを示すために使われる。i番目の参照フィールドに対応するオブジェクト・フィールドが、i番目の参照フィールドにおいて参照されるYANGモデルを使ってモデリングされる目標構成データの、目標となる、より低レベルのデバイスおよび／または目標となる、より低レベルのデバイスのグループを示すために使われる。より低レベルのデバイスのグループは、いくつかの、より低レベルのデバイスを含むグループである。1≦i≦nであり、iおよびnは正の整数である。ネットワーク・デバイス５００が管理されるデバイスであるときは、プロセッサ５１０は、命令を実行することによって次の方法を実装する：トランシーバ５３０を制御して、ネットワーク管理デバイスからNETCONFに基づいて送られた構成データを受信し；あらかじめ定義されたYANGモデルに従って該構成データをパースし；パースから得られた構成データに従って、より低レベルのデバイスを構成する。
【００７４】
トランシーバ５３０は、外部通信を実行するよう構成され、トランシーバ５３０は、複数の型のインターフェースを含んでいてもよい。たとえば、ネットワーク・デバイス５００がネットワーク管理デバイスであるとき、トランシーバ５３０は、構成データを管理されるデバイスにNETCONFに基づいて送るよう構成される。ネットワーク・デバイス５００が管理されるデバイスであるときは、トランシーバ５３０は、NETCONFに基づいてネットワーク管理デバイスによって送られた構成データを受信するよう構成される。
【００７５】
任意的に、メモリ５２０は、オペレーティング・システム５２２および少なくとも一つの機能によって要求されるアプリケーション・プログラム・モジュール５２４を記憶していてもよい。オペレーティング・システム５２２は、リアルタイム・オペレーティング・システムまたはLinux、Unix、WindowsまたはOS  Xのようなオペレーティング・システムであってもよい。ネットワーク・デバイス５００がネットワーク管理デバイスであるとき、図５Ａに示されるように、アプリケーション・プログラム・モジュール５２４はモデリング・モジュール５２４ａおよび送信モジュール５２４ｂを含んでいてもよい。モデリング・モジュール５２４ａは、あらかじめ定義されたYANGモデルを使って構成データのモデルを確立するよう構成される。送信モジュール５２４ｂは、構成データをNETCONFに基づいて、管理されるデバイスに送るよう構成される。ネットワーク・デバイス５００が管理されるデバイスであるときは、図５Ｂに示されるように、アプリケーション・プログラム・モジュール５２４は、受信モジュール５２４ｃ、パース・モジュール５２４ｄおよび構成モジュール５２４ｅを含んでいてもよい。受信モジュール５２４ｃは、ネットワーク管理デバイスによってNETCONFに基づいて送られた構成データを受信するよう構成される。パース・モジュール５２４ｄは、あらかじめ定義されたYANGモデルに従って該構成データをパースするよう構成される。構成モジュール５２４ｅは、パースから得られた構成データに従って、より低レベルのデバイスを構成するよう構成される。
【００７６】
任意的に、ネットワーク・デバイス５００はさらに、入出力コンポーネント（図示せず）を含んでいてもよい。入出力コンポーネントは、情報を表示するよう構成されたディスプレイおよびユーザーによって情報を入力するよう構成された入力デバイス、たとえばマウスまたはキーボードを含む。ディスプレイおよび入力デバイスはいずれも、バス５４０を使ってプロセッサ５１０に接続される。
【００７７】
図６を参照するに、図６は、本願のある実施形態に基づく、NETCONFに基づくデバイス構成方法のフローチャートである。この実施形態で与えられる方法は、ネットワーク管理デバイスに適用される。ネットワーク管理デバイスは管理されるデバイスに接続されており、管理されるデバイスはいくつかの、より低レベルのデバイスに接続されており、ネットワーク管理デバイスおよび管理されるデバイスはNETCONFをサポートする。本方法は、下記のいくつかの段階を含む。
【００７８】
段階６０２：あらかじめ定義されたYANGモデルを使って構成データのモデルを確立する。
【００７９】
前記あらかじめ定義されたYANGモデルはn個の参照フィールドおよび各参照フィールドに別個に対応するいくつかのオブジェクト・フィールドを含む。前記参照フィールドは、前記あらかじめ定義されたYANGモデルにおいて参照されるYANGモデルを示すために使われる。i番目の参照フィールドに対応するオブジェクト・フィールドは、i番目の参照フィールドにおいて参照されるYANGモデルを使ってモデリングされる目標構成データの、目標となる、より低レベルのデバイスおよび／または目標となる、より低レベルのデバイスのグループを示すために使われる。前記より低レベルのデバイスのグループは、いくつかのより低レベルのデバイスを含むグループである。1≦i≦nであり、iおよびnは正の整数である。
【００８０】
段階６０４：NETCONFに基づいて前記構成データを前記管理されるデバイスに送る。
【００８１】
結論として、この実施形態で提供される方法によれば、構成データのモデルは、あらかじめ定義されたYANGモデルを使ってネットワーク管理デバイスによって確立され、構成データはNETCONFに基づいて、管理されるデバイスに送られる。これは、デバイス縦続シナリオにおいてNETCONFメッセージにおいて構成データの、目標となる、より低レベルのデバイスを示すためにNETCONFメッセージに拡張フィールドが追加されるときに、解決策の普遍性が比較的貧弱であり、構成処理効率が比較的低く、データ記憶処理手順が比較的複雑であるという従来技術の問題を解決する。構成データを参照し、構成データの、目標となる、より低レベルのデバイスおよび／または目標となる、より低レベルのデバイスのグループを示すために、前記あらかじめ定義されたYANGモデルにおける参照フィールドおよびオブジェクト・フィールドを設計することによって、定義されているYANGモデルを修正することなく、あらかじめ定義されたYANGモデルが使用される。これは、下記の技術的効果を達成する。
【００８２】
第一に、NETCONFメッセージに対して拡張フィールドが追加されず、よって、NETCONFは拡張される必要がない。よって、ネットワーク管理デバイスおよび管理されるデバイスは、いまだに標準的なNETCONFに基づいて互いと通信し、解決策の普遍性がよくなる。
【００８３】
第二に、複数のYANGモデルを使ってモデリングされる構成データが、複数の参照フィールドを使うことによって、あらかじめ定義されたYANGモデルにおいて参照されることができ、構成データの各片の目標となる、より低レベルのデバイスおよび／または目標となる、より低レベルのデバイスのグループが別個に同定されることができる。よって、一つのNETCONFメッセージが、異なる、より低レベルのデバイス／より低レベルのデバイスのグループのために送達される異なる構成データを担持することができ、それにより、構成処理効率を改善する。
【００８４】
第三に、あらかじめ定義されたYANGモデルが、ネットワーク管理デバイスによって送達されるNETCONFメッセージにおいて担持されるすべての構成データについてモデリングを実行するために使われる。よって、管理されるデバイスは、異なる、より低レベルのデバイスおよびより低レベルのデバイスのグループのための複数の異なるデータベースを別個に維持することなく、あらかじめ定義されたYANGモデルに対応するデータベースを維持するだけでよい。これは、データベース構成および管理を単純化し、データ記憶処理手順を単純化する。
【００８５】
図７を参照するに、図７は、NETCONFに基づくデバイス構成方法のフローチャートである。この実施形態において提供される方法は、管理されるデバイスに適用される。管理されるデバイスはネットワーク管理デバイスに接続されており、管理されるデバイスはさらに、いくつかの、より低レベルのデバイスに接続されており、ネットワーク管理デバイスおよび管理されるデバイスはNETCONFをサポートする。本方法は、下記のいくつかの段階を含む。
【００８６】
段階７０２：NETCONFに基づいてネットワーク管理デバイスによって送られた構成データを受信する。
【００８７】
前記構成データは、あらかじめ定義されたYANGモデルを使ってネットワーク管理デバイスによって構築されている。前記あらかじめ定義されたYANGモデルはn個の参照フィールドおよび各参照フィールドに別個に対応するいくつかのオブジェクト・フィールドを含む。前記参照フィールドは、前記あらかじめ定義されたYANGモデルにおいて参照されるYANGモデルを示すために使われる。i番目の参照フィールドに対応するオブジェクト・フィールドは、i番目の参照フィールドにおいて参照されるYANGモデルを使ってモデリングされる目標構成データの、目標となる、より低レベルのデバイスおよび／または目標となる、より低レベルのデバイスのグループを示すために使われる。前記より低レベルのデバイスのグループは、いくつかのより低レベルのデバイスを含むグループである。1≦i≦nであり、iおよびnは正の整数である。
【００８８】
段階７０４：あらかじめ定義されたYANGモデルに従って前記構成データをパースする。
【００８９】
段階７０６：パースから得られた前記構成データに従って、より低レベルのデバイスを構成する。
【００９０】
結論として、この実施形態で提供される方法によれば、NETCONFに基づいてネットワーク管理デバイスによって送られた構成データが、管理されるデバイスによって受信され、前記構成データは、あらかじめ定義されたYANGモデルを使ってネットワーク管理デバイスによって構築されており、管理されるデバイスが、あらかじめ定義されたYANGモデルに従って前記構成データをパースし、パースから得られた前記構成データに従って、より低レベルのデバイスを構成する。これは、デバイス縦続シナリオにおいてNETCONFメッセージにおいて構成データの、目標となる、より低レベルのデバイスを示すためにNETCONFメッセージに拡張フィールドが追加されるときに、解決策の普遍性が比較的貧弱であり、構成処理効率が比較的低く、データ記憶処理手順が比較的複雑であるという従来技術の問題を解決する。構成データを参照し、構成データの、目標となる、より低レベルのデバイスおよび／または目標となる、より低レベルのデバイスのグループを示すために、前記あらかじめ定義されたYANGモデルにおける参照フィールドおよびオブジェクト・フィールドを設計することによって、定義されているYANGモデルを修正することなく、あらかじめ定義されたYANGモデルが使用される。これは、解決策の普遍性を改善し、構成処理効率を高め、データベース構成および管理ならびにデータ記憶処理手順を単純化する。
【００９１】
図８を参照するに、図８は、本願の別の実施形態に基づく、NETCONFに基づくデバイス構成方法のフローチャートである。
【００９２】
段階８０１：ネットワーク管理デバイスが、あらかじめ定義されたYANGモデルを使って構成データのモデルを確立する。
【００９３】
前記あらかじめ定義されたYANGモデルはn個の参照フィールドおよび各参照フィールドに別個に対応するいくつかのオブジェクト・フィールドを含む。前記参照フィールドは、前記あらかじめ定義されたYANGモデルにおいて参照されるYANGモデルを示すために使われる。i番目の参照フィールドに対応するオブジェクト・フィールドは、i番目の参照フィールドにおいて参照されるYANGモデルを使ってモデリングされる目標構成データの、目標となる、より低レベルのデバイスおよび／または目標となる、より低レベルのデバイスのグループを示すために使われる。前記より低レベルのデバイスのグループは、いくつかのより低レベルのデバイスを含むグループである。1≦i≦nであり、iおよびnは正の整数である。前記あらかじめ定義されたYANGモデルは、NETCONFに基づいて互いと通信するピア・デバイス（すなわち、この実施形態では当該ネットワーク管理デバイスおよび管理されるデバイス）上であらかじめ定義されたYANGモデル、すなわちNETCONFクライアントおよびNETCONFサーバーの両方であらかじめ定義されているYANGモデルである。
【００９４】
前記参照フィールドは、第一の文を使って定義され、前記第一の文は、あるYANGモデルにおいて、別のYANGモデルによって定義される模式木（英語：schema  tree〔スキーマ・ツリー〕）を参照するために使われる。
【００９５】
ある可能な実装では、YANG言語シンタックスを拡張して、前記第一の文は、新たに追加されたrefer文である。前記参照フィールドは、refer文を使って定義される。refer文は、あるYANGモデルにおいて、別のYANGモデルによって定義される模式木を参照するために使われる。refer文のパラメータは、参照されるYANGモデルの名前である。たとえば、YANGモデルmodule  yが別のYANGモデルmodule  xによって定義されている模式木を参照するとする。この場合、module  yにおける参照フィールドはrefer  xとして表現されうる。
【００９６】
前記あらかじめ定義されたYANGモデルがmodule  yであり、参照されるYANGモデルがmodule  xであるとする。module  xのシンタックス構造は次のようになる：
module  x  {
………………………………………………………………………………
container  a  {
leaf  b;
list  c  {
key  d;
leaf  d;
leaf  list  e;
}
}
}
【００９７】
module  yのシンタックス構造は次のようになる：
module  y  {
………………………………………………………………………………
import  x;
………………………………………………………………………………
list  x-instance  {
key  instance-name;
leaf  instance-name;
refer  x;
}
}
【００９８】
module  yのシンタックス構造は次と等価である：
module  y  {
………………………………………………………………………………
import  x;
………………………………………………………………………………
list  x-instance  {
key  instance-name;
leaf  instance-name;
container  a  {
leaf  b;
list  c  {
key  d;
leaf  d;
leaf  list  e;
}
}
}
}
【００９９】
任意的に、オブジェクト・フィールドは、laef-list〔リーフ・リスト〕特徴を使って定義される。該leaf-list特徴は、同じ型のリーフ・ノードのグループを記述するために使われ、該leaf-list特徴の機能はC言語における配列と同様である。一つまたは複数の、より低レベルのデバイスまたは一つまたは複数の、より低レベルのデバイスのグループが、leaf-list特徴を使って定義されてもよい。たとえば、「leaf-list  devices」が、構成データの、目標となる、より低レベルのデバイスを記述するために使われ、「leaf-list  device-groups」が、構成データの、目標となる、より低レベルのデバイスのグループを記述するために使われる。
【０１００】
さらに、i番目の参照フィールドに対応するオブジェクト・フィールドは：いくつかの第一のオブジェクト・フィールドおよび／またはいくつかの第二のオブジェクト・フィールドを含む。各第一のオブジェクト・フィールドは、i番目の参照フィールドにおいて参照されるYANGモデルを使ってモデリングされる目標構成データが送達されるべき、より低レベルのデバイスを示すために使われる。たとえば、第一のオブジェクト・フィールドは、「leaf-list  devices」を使って表現される。各第二のオブジェクト・フィールドは、i番目の参照フィールドにおいて参照されるYANGモデルを使ってモデリングされる目標構成データが送達される、より低レベルのデバイスのグループを示すために使われる。たとえば、第二のオブジェクト・フィールドは、「leaf-list  device-groups」を使って表現される。
【０１０１】
図４に示したネットワーク・アーキテクチャーを参照するに、コントローラは、APのDHCPおよびDNSのような特徴を構成する。APのDHCP特徴を構成することは、ここでは例として使われており、別の特徴の構成設定が同様に実装されてもよい。APの種々の特徴に基づいて、APのDHCP特徴を構成するために使われるYANGモデルhw-dhcp.yangを含む一連のYANGモデルがすでに定義されている。hw-dhcp.yangでは、APによって使用されるDHCPサーバー・グループの名前およびDHCPサーバーに対応するIPアドレスのような特徴に対応するデータ・モデルが定義される。たとえば、hw-dhcp.yangのシンタックス構造は次のようになる：
module  hw-dhcp  {
namespace  "urn:hw:params:xml:ns:yang:hw-dhcp";
prefix  hw-dhcp;
……
/*config  and  state  data*/
container  dhcp  {
list  dhcp-server-group  {
key  name;
leaf  name  {
description  "the  name  of  the  group";
type  string  {
length  "1..31";
}
}
leaf-list  ip-address  {
description  "ip  addresses  of  dhcp  servers  in  the  group";
max-elements  8;
type  inet:ip-address;
}
……
}
……
}  /*end  of  container  dhcp*/
……
}  /*end  of  module  hw-dhcp*/
【０１０２】
前記あらかじめ定義されたYANGモデルがmaster-device.yangであると想定され、master-device.yangのシンタックス構造は次のようになる：
module  master-device  {
……
container  master  {
list  dhcp-config{
key  dhcp-config-id;  //list型のデータは一意的なkey値を必要とする
leaf  dhcp-config-id  {
type  string  {
length  "1..31";
}
}
refer  hw-dhcp;  //デバイスのDHCP構成データを記述するためにhw-dhcp.yangが参照される
leaf-list  devices;  //DHCP構成データの目標デバイスを記述
leaf-list  device-groups;  //DHCP構成データの目標デバイス・グループを記述
}
list  dns-config{
key  dns-config-id;  //list型のデータは一意的なkey値を必要とする
……                //DNS特徴の記述
}
……
}  /*end  of  container  master  */
……
}  /*  end  of  module  master-device  */
【０１０３】
複数のYANGモデルを使ってモデリングされる構成データが、前記あらかじめ定義されたYANGモデルにおいて、複数の参照フィールドを使うことによって、参照されてもよく、構成データの各片の、目標となる、より低レベルのデバイスおよび／または目標となる、より低レベルのデバイスのグループが、別個に識別されてもよい。したがって、一つのNETCONFメッセージが、異なる、より低レベルのデバイス／より低レベルのデバイスのグループのために送達される異なる構成データを担持することができ、それにより構成処理効率を改善する。
【０１０４】
段階８０２：ネットワーク管理デバイスが、NETCONFに基づいて、管理されるデバイスに前記構成データを送る。
【０１０５】
ネットワーク管理デバイスは、モデリングが完了した前記構成データをエンコードするためにXML言語を使い、次いで、前記ネットワーク管理デバイスは、NETCONFメッセージを前記管理されるデバイスに送る。前記NETCONFメッセージは、エンコードされた構成データを担持する。
【０１０６】
対応して、管理されるデバイスは、NETCONFに基づいてネットワーク管理デバイスによって送られた構成データを受信する。
【０１０７】
段階８０３：管理されるデバイスが、あらかじめ定義されたYANGモデルに従って前記構成データをパースする。
【０１０８】
ネットワーク管理デバイスからNETCONFメッセージを受信した後、管理されるデバイスは、前記構成データを得るよう前記メッセージのコンテンツをパースするために前記あらかじめ定義されたYANGモデルを使う。
【０１０９】
任意的に、管理されるデバイスは、パースから得られた前記構成データを同じ構成データベースに記憶する。前記あらかじめ定義されたYANGモデルは、前記ネットワーク管理デバイスによって送達される前記NETCONFメッセージにおいて担持されるすべての構成データについてモデリングを実行するために使われる。それにより、管理されるデバイスは、異なる、より低レベルのデバイスおよびより低レベルのデバイスのグループについて複数の異なるデータベースを別個に維持することなく、あらかじめ定義されたYANGモデルに対応するデータベースを維持するだけでよい。これは、データベース構成および管理を単純化し、データ記憶処理手順を単純化する。
【０１１０】
段階８０４：管理されるデバイスが、パースから得られた前記構成データに従って、より低レベルのデバイスを構成する。
【０１１１】
i番目の参照フィールドにおいて参照されるYANGモデルを使ってモデリングされる目標構成データについて、管理されるデバイスは、i番目の参照フィールドに対応するオブジェクト・フィールドに従って前記目標構成データが送達されるべき、目標となる、より低レベルのデバイスを決定する。前記目標となる、より低レベルのデバイスは、i番目の参照フィールドに対応するオブジェクト・フィールドによって示される、より低レベルのデバイスおよび／またはi番目の参照フィールドに対応するオブジェクト・フィールドによって示される、より低レベルのデバイスのグループにおける、より低レベルのデバイスである。管理されるデバイスは、目標構成管理プロトコルに基づいて、前記目標構成データを前記目標となる、より低レベルのデバイスに送る。前記目標構成管理プロトコルは、前記管理されるデバイスおよび前記目標となる、より低レベルのデバイスによってサポートされる構成管理プロトコルである。
【０１１２】
管理されるデバイスと、より低レベルのデバイスとの間で使われる構成管理プロトコルは、本願の実施形態において限定されない。可能な実装では、図３のＡを参照するに、管理されるデバイスおよび目標となる、より低レベルのデバイスは、非NETCONFプロトコルに基づいて互いと通信する。たとえば、図３のＡに示されるデバイス縦続シナリオがWLANに適用されるとき、非NETCONFプロトコルはCAPWAPであってもよい。目標となる、より低レベルのデバイスに送達される必要がある目標構成データについて、管理されるデバイスは、目標構成データをCAPWAPパケットにカプセル化して、該CAPWAPパケットを目標となる、より低レベルのデバイスに送る。もう一つの可能な構成では、図３のＢを参照するに、管理されるデバイスは、NETCONFプロキシのはたらきをする。管理されるデバイスおよび目標となる、より低レベルのデバイスは、NETCONFに基づいて互いと通信する。目標となる、より低レベルのデバイスに送達される必要のある目標構成データについて、管理されるデバイスは、目標構成データをNETCONFメッセージにカプセル化して、該NETCONFメッセージを目標となる、より低レベルのデバイスに送る。もちろん、CAPWAPおよびNETCONFに加えて、目標構成管理プロトコルは、さらに、別の型の構成管理プロトコルであってもよい。前記別の型の構成管理プロトコルについては、目標となる、より低レベルのデバイスを構成し、管理するときに、管理されるデバイスによって実行される処理は、基本的に同様である。ここで詳細を再び述べることはしない。
【０１１３】
さらに、管理されるデバイスは、前記より低レベルのデバイスを構成した後、ネットワーク管理デバイスに応答メッセージをフィードバックしてもよい。応答メッセージをフィードバックする手順は、NETCONFにおいて指定された既存の機構を使って実装されてもよい。
【０１１４】
結論として、この実施形態で提供される方法によれば、構成データのモデルは、あらかじめ定義されたYANGモデルを使ってネットワーク管理デバイスによって確立され、構成データはNETCONFに基づいて、管理されるデバイスに送られ、管理されるデバイスが前記あらかじめ定義されたYANGモデルに従って前記構成モデルをパースし、パースから得られた構成データに従って前記より低レベルのデバイスを構成する。これは、デバイス縦続シナリオにおいてNETCONFメッセージにおいて構成データの、目標となる、より低レベルのデバイスを示すためにNETCONFメッセージに拡張フィールドが追加されるときに、解決策の普遍性が比較的貧弱であり、構成処理効率が比較的低く、データ記憶処理手順が比較的複雑であるという従来技術の問題を解決する。
【０１１５】
構成データを参照し、構成データの、目標となる、より低レベルのデバイスおよび／または目標となる、より低レベルのデバイスのグループを示すために、前記あらかじめ定義されたYANGモデルにおける参照フィールドおよびオブジェクト・フィールドを設計することによって、定義されているYANGモデルを修正することなく、あらかじめ定義されたYANGモデルが使用される。これは、下記の技術的効果を達成する。
【０１１６】
第一に、NETCONFメッセージに対して拡張フィールドが追加されず、よって、NETCONFは拡張される必要がない。よって、ネットワーク管理デバイスおよび管理されるデバイスは、いまだに標準的なNETCONFに基づいて互いと通信し、解決策の普遍性がよくなる。
【０１１７】
第二に、複数のYANGモデルを使ってモデリングされる構成データが、複数の参照フィールドを使うことによって、あらかじめ定義されたYANGモデルにおいて参照されることができ、構成データの各片の、目標となる、より低レベルのデバイスおよび／または目標となる、より低レベルのデバイスのグループが別個に同定されることができる。よって、一つのNETCONFメッセージが、異なる、より低レベルのデバイス／より低レベルのデバイスのグループのために送達される異なる構成データを担持することができ、それにより、構成処理効率を改善する。
【０１１８】
第三に、あらかじめ定義されたYANGモデルが、ネットワーク管理デバイスによって送達されるNETCONFメッセージにおいて担持されるすべての構成データについてモデリングを実行するために使われる。よって、管理されるデバイスは、異なる、より低レベルのデバイスおよびより低レベルのデバイスのグループのための複数の異なるデータベースを別個に維持することなく、あらかじめ定義されたYANGモデルに対応するデータベースを維持するだけでよい。これは、データベース構成および管理を単純化し、データ記憶処理手順を単純化する。
【０１１９】
さらに、YANGモデルにおいて、任意の定義されたYANGモデルの模式木を便利に参照するようYANG言語シンタックスを拡張するために、前記第一の文が追加される。これは、デバイス縦続シナリオにおけるYANGモデル再利用問題を解決し、NETCONFおよびYANGモデルを使うことによる、デバイス縦続シナリオにおける、より低レベルのデバイス構成を実装する。
【０１２０】
さらに、一つまたは複数の、より低レベルのデバイスまたは一つまたは複数の、より低レベルのデバイスのグループは、leaf-list特徴を使って定義できる。それにより、構成データの、目標となる、より低レベルのデバイスおよび／またはより低レベルのデバイスのグループを便利かつ柔軟に定義する。
【０１２１】
さらに、既存のYANG言語シンタックスにおいて、二つのYANGモデル再利用機構があることを注意しておくべきである。module-submoduleとuses-groupingである。
【０１２２】
module-submodule式に実装されるYANGモデル再利用機構は、次のようなものである：第一に、submodule〔サブモジュール〕が定義され、該submoduleがmodule〔モジュール〕に属することを陳述し、該submoduleに対応する模式木が定義される；次いで、moduleが定義され、該moduleは先に定義されたsubmoduleを含む。このようにして、submoduleによって定義された模式木がmoduleにおいて参照される。module-submodule式に実装されるYANGモデル再利用は、次の欠点をもつ：任意のsubmoduleまたはmoduleではなく、moduleに属する定義されたsubmoduleのみが、該moduleにおいて参照されることができる。しかしながら、定義されたYANGモデルでは、独立したmoduleは一般に、YANGモデルにおいて構成される機能特徴に従って形成される。したがって、あるmoduleにおいて、別のmoduleにおいて定義されている模式木を参照することは不可能である。
【０１２３】
さらに、uses-grouping式に実装されるYNAGモデル再利用は次のような欠点をもつ：usesはgroupingを使って定義されており、かつ現在のモデルまたは導入されたモデルにある模式木の再利用をサポートするのみである。しかしながら、定義されたYANGモデルにおけるどのYANGモデルも、YANGモデルのすべてのフィールドを含むgroupingを定義しない。したがって、uses-grouping式にデバイス縦続シナリオにおけるYANGモデル再利用問題を解決することも不可能である。
【０１２４】
上記の分析に基づいて、定義されたYANGモデルを修正することなくしては、module-submodule式またはuses-grouping式のいずれでも、デバイス縦続シナリオにおけるYANGモデル再利用問題を解決することは不可能である。本願のこの実施形態において提供される技術的解決策によれば、あるYANGモデルにおいて、任意の定義されたYANGモデルにおける模式木を便利に参照するよう、YANG言語シンタックスを拡張することによって、refer文が追加される。これは、デバイス縦続シナリオにおけるYANGモデル再利用問題を効果的に解決し、NETCONFおよびYANGモデルを使って、デバイス縦続シナリオにおける、より低レベルのデバイス構成の構成および管理を実装する。
【０１２５】
本願のこの実施形態において、YANG言語シンタックスにおいて追加される文の型が「refer文」と名付けられているのは単に記述のための例として使われていることをさらに注意しておくべきである。実際の応用では、追加される文の型は、参照文またはユーザー定義文などといった別の異なる名前を名付けられてもよい。本願のこの実施形態は、それに制限を設定するものではない。追加された文の型がどんな名前を付けられようとも、追加される文の機能は上記の「refer文」と同じである。つまり、追加される文は、あるYANGモデルにおいて、別のYANGモジュールによって定義された模式木を参照するために使われる。
【０１２６】
下記は、具体例を使って構成データのインスタンスを記述する。
【０１２７】
APのDHCP特徴を構成するために使われるYANGモデルhw-dhcp.yangに対応する構成データ・インスタンスは次のようになる：
<dhcp  xmlns="urn:hw:params:xml:hw-dhcp">
<dhcp-server-group>
<name>dhcp-cfg1<name>
<ip-address>10.163.18.1<ip-address>
<ip-address>10.163.23.6<ip-address>
<dhcp-server-group>
</dhcp>
【０１２８】
あらかじめ定義されたYANGモデルはlac-device.yangであるとする。lac-device.yangにおいて、hw-dhcp.yangは、LACの、より低レベルのデバイスであるAPのDHCP特徴を構成するためにrefer文を使って参照される。IPアドレス10.163.18.1および10.163.23.6は、名前がdhcp-cfg1である一つのdhcp-server-groupに属する。コントローラが、LACの、より低レベルのデバイスを構成するとき、dhcp-server-groupの構成データは、より低レベルのデバイスAP3およびより低レベルのデバイスのグループであるgroup1およびgroup2に、適用のために送達される。lac-device.yangに対応する構成データ・インスタンスは次のようなものである：
<lac  xmlns="urn:hw:params:xml:lac-dhcp">
<dhcp-config>
<dhcp-config-id>dhcp-id1<dhcp-config-id>
<hw-dhcp>
<hw-dhcp:dhcp>
<hw-dhcp:dhcp-server-group>
<hw-dhcp:name>dhcp-cfg1</hw-dhcp:name>
<hw-dhcp:ip-address>10.163.18.1</hw-dhcp:ip-address>
<hw-dhcp:ip-address>10.163.23.6</hw-dhcp:ip-address>
</hw-dhcp:dhcp-server-group>
</hw-dhcp:dhcp>
</hw-dhcp>
<aps>ap3</aps>
<ap-groups>group1</ap-groups>
<ap-groups>group2</ap-groups>
</dhcp-config>
……
</lac>
【０１２９】
下記は、本願の装置実施形態であり、該装置実施形態は、本願の方法実施形態を実行するために使われてもよい。本願の装置実施形態に開示されていない詳細については、本願の方法実施形態を参照されたい。
【０１３０】
図９を参照するに、図９は、本願のある実施形態に基づくNETCONFに基づくデバイス構成装置のブロック図である。この実施形態において提供される装置は、ネットワーク管理デバイスの一部または全体であってもよい。ネットワーク管理デバイスは、管理されるデバイスに接続されており、管理されるデバイスはいくつかの、より低レベルのデバイスに接続されており、ネットワーク管理デバイスおよび管理されるデバイスはNETCONFをサポートする。本装置は：モデリング・ユニット（英語：modeling  unit）９１０および送信ユニット９２０を含んでいてもよい。
【０１３１】
モデリング・ユニット９１０は、あらかじめ定義されたYANGモデルを使って構成データのモデルを確立する。
【０１３２】
前記あらかじめ定義されたYANGモデルはn個の参照フィールドおよび各参照フィールドに別個に対応するいくつかのオブジェクト・フィールドを含む。前記参照フィールドは、前記あらかじめ定義されたYANGモデルにおいて参照されるYANGモデルを示すために使われる。i番目の参照フィールドに対応するオブジェクト・フィールドは、i番目の参照フィールドにおいて参照されるYANGモデルを使ってモデリングされる目標構成データの、目標となる、より低レベルのデバイスおよび／または目標となる、より低レベルのデバイスのグループを示すために使われる。前記より低レベルのデバイスのグループは、いくつかのより低レベルのデバイスを含むグループである。1≦i≦nであり、iおよびnは正の整数である。
【０１３３】
送信ユニット９２０は、NETCONFに基づいて、前記モデリング・ユニット９１０によってモデリングされた前記構成データを、前記管理されるデバイスに送るよう構成される。
【０１３４】
結論として、この実施形態で提供される方法によれば、構成データのモデルは、あらかじめ定義されたYANGモデルを使ってネットワーク管理デバイスによって確立され、構成データはNETCONFに基づいて、管理されるデバイスに送られる。これは、デバイス縦続シナリオにおいてNETCONFメッセージにおいて構成データの、目標となる、より低レベルのデバイスを示すためにNETCONFメッセージに拡張フィールドが追加されるときに、解決策の普遍性が比較的貧弱であり、構成処理効率が比較的低く、データ記憶処理手順が比較的複雑であるという従来技術の問題を解決する。構成データを参照し、構成データの、目標となる、より低レベルのデバイスおよび／または目標となる、より低レベルのデバイスのグループを示すために、前記あらかじめ定義されたYANGモデルにおける参照フィールドおよびオブジェクト・フィールドを設計することによって、定義されているYANGモデルを修正することなく、あらかじめ定義されたYANGモデルが使用される。これは、解決策の普遍性を改善し、構成処理効率を高め、データベース構成および管理ならびにデータ記憶処理手順を単純化する。
【０１３５】
図９に示される実施形態に基づいて提供されるある任意的な実施形態では、参照フィールドが、第一の文を使って定義され、前記第一の文は、あるYANGモデルにおいて、別のYANGモデルによって定義される模式木を参照するために使われる。
【０１３６】
図９に示される実施形態に基づいて提供されるもう一つの任意的な実施形態では、オブジェクト・フィールドが、laef-list〔リーフ・リスト〕特徴を使って定義され、該leaf-list特徴は、同じ型のリーフ・ノードのグループを記述するために使われる。
【０１３７】
図９に示される実施形態に基づいて提供されるもう一つの任意的な実施形態では、i番目の参照フィールドに対応するオブジェクト・フィールドは：いくつかの第一のオブジェクト・フィールドおよび／またはいくつかの第二のオブジェクト・フィールドを含む。各第一のオブジェクト・フィールドは、i番目の参照フィールドにおいて参照されるYANGモデルを使ってモデリングされる目標構成データが送達される、より低レベルのデバイスを示すために使われる。各第二のオブジェクト・フィールドは、i番目の参照フィールドにおいて参照されるYANGモデルを使ってモデリングされる目標構成データが送達される、より低レベルのデバイスのグループを示すために使われる。
【０１３８】
図１０を参照するに、図１０は、本願のもう一つの実施形態に基づくNETCONFに基づくデバイス構成装置のブロック図である。この実施形態において提供される装置は、管理されるデバイスの一部または全体であってもよい。管理されるデバイスは、ネットワーク管理デバイスに接続されており、管理されるデバイスはさらに、いくつかの、より低レベルのデバイスに接続されており、ネットワーク管理デバイスおよび管理されるデバイスはNETCONFをサポートする。本装置は：受信ユニット１０１０、パース・ユニット１０２０および構成ユニット１０３０を含んでいてもよい。
【０１３９】
受信ユニット１０１０は、NETCONFに基づいてネットワーク管理デバイスによって送られた構成データを受信するよう構成される。
【０１４０】
前記構成データは、あらかじめ定義されたYANGモデルを使ってネットワーク管理デバイスによって構築されている。前記あらかじめ定義されたYANGモデルはn個の参照フィールドおよび各参照フィールドに別個に対応するいくつかのオブジェクト・フィールドを含む。前記参照フィールドは、前記あらかじめ定義されたYANGモデルにおいて参照されるYANGモデルを示すために使われる。i番目の参照フィールドに対応するオブジェクト・フィールドは、i番目の参照フィールドにおいて参照されるYANGモデルを使ってモデリングされる目標構成データの、目標となる、より低レベルのデバイスおよび／または目標となる、より低レベルのデバイスのグループを示すために使われる。前記より低レベルのデバイスのグループは、いくつかのより低レベルのデバイスを含むグループである。1≦i≦nであり、iおよびnは正の整数である。
【０１４１】
パース・ユニット１０２０は、前記あらかじめ定義されたYANGモデルに従って前記構成データをパースするよう構成される。
【０１４２】
構成ユニット１０３０は、パースから得られた前記構成データに従って、より低レベルのデバイスを構成するよう構成されている。
【０１４３】
結論として、この実施形態で提供される装置によれば、NETCONFに基づいてネットワーク管理デバイスによって送られた構成データが、管理されるデバイスによって受信され、前記構成データは、あらかじめ定義されたYANGモデルを使ってネットワーク管理デバイスによって構築されており、管理されるデバイスが、あらかじめ定義されたYANGモデルに従って前記構成データをパースし、パースから得られた前記構成データに従って、より低レベルのデバイスを構成する。これは、デバイス縦続シナリオにおいてNETCONFメッセージにおいて構成データの、目標となる、より低レベルのデバイスを示すためにNETCONFメッセージに拡張フィールドが追加されるときに、解決策の普遍性が比較的貧弱であり、構成処理効率が比較的低く、データ記憶処理手順が比較的複雑であるという従来技術の問題を解決する。構成データを参照し、構成データの、目標となる、より低レベルのデバイスおよび／または目標となる、より低レベルのデバイスのグループを示すために、前記あらかじめ定義されたYANGモデルにおける参照フィールドおよびオブジェクト・フィールドを設計することによって、定義されているYANGモデルを修正することなく、あらかじめ定義されたYANGモデルが使用される。これは、解決策の普遍性を改善し、構成処理効率を高め、データベース構成および管理ならびにデータ記憶処理手順を単純化する。
【０１４４】
図１０に示される実施形態に基づいて提供されるある任意的な実施形態では、構成ユニット１０３０は具体的には：
i番目の参照フィールドにおいて参照されるYANGモデルを使ってモデリングされる目標構成データについて、i番目の参照フィールドに対応するオブジェクト・フィールドに従って前記目標構成データが送達されるべき、目標となる、より低レベルのデバイスを決定する段階であって、前記目標となる、より低レベルのデバイスは、i番目の参照フィールドに対応するオブジェクト・フィールドによって示される、より低レベルのデバイスおよび／またはi番目の参照フィールドに対応するオブジェクト・フィールドによって示される、より低レベルのデバイスのグループにおける、より低レベルのデバイスである、段階と；
目標構成管理プロトコルに基づいて、前記目標構成データを前記目標となる、より低レベルのデバイスに送る段階であって、前記目標構成管理プロトコルは、前記管理されるデバイスおよび前記目標となる、より低レベルのデバイスによってサポートされる構成管理プロトコルである、段階とを実行するよう構成される。
【０１４５】
図１０に示される実施形態に基づいて提供されるもう一つの任意的な実施形態では、本装置はさらに、パースから得られた前記構成データを、同じ構成データベースに記憶するよう構成された記憶ユニットを含む。
【０１４６】
本願のある実施形態はさらに、NETCONFに基づくデバイス構成システムを提供する。図２を参照するに、該システムは、ネットワーク管理デバイスと、管理されるデバイスと、いくつかの、より低レベルのデバイスとを含む。ネットワーク管理デバイスは管理されるデバイスに接続されており、管理されるデバイスは上記のいくつかの、より低レベルのデバイスに接続されている。ネットワーク管理デバイスおよび管理されるデバイスはNETCONFをサポートする。ネットワーク管理デバイスは、図９に示される実施形態において提供されるデバイス構成装置を含む。管理されるデバイスは、図１０に示される実施形態において提供されるデバイス構成装置を含む。
【０１４７】
上記の実施形態において提供される装置がその機能を実装するとき、上記の機能ユニットの分割は単に、記述のための例として使われていることを注意しておくべきである。実際の応用では、上記の機能は、必要に応じて実装のための種々の機能ユニットに割り当てられてもよい。すなわち、デバイスの内部構造が、上記の機能の全部または一部を実装するために種々の機能ユニットに分割される。さらに、上記の実施形態において提供される装置実施形態および方法実施形態は、同じ概念に基づく、装置実施形態の具体的な実装プロセスについては、方法実施形態を参照されたい。ここで再び詳細を述べることはしない。
【０１４８】
当業者は、実施形態の段階の全部または一部がハードウェアまたは関係したハードウェアに命令するプログラムによって実装されうることを理解しうる。プログラムは、コンピュータ可読記憶媒体に記憶されてもよい。記憶媒体は、読み出し専用メモリ、磁気ディスク、光ディスクなどであってもよい。
【０１４９】
上記の記述は単に、本願の例示的実施形態であり、本願を限定することは意図されていない。本願の原理から外れることなくなされるいかなる修正、等価な置換または改善も、本願の保護範囲内にはいるべきである。
【国際調査報告】
2019514297.tif 000014
2019514297.tif 000015
2019514297.tif 000016
2019514297.tif 000017
2019514297.tif 000018
2019514297.tif 000019