JP2019514297A - ネットワーク構成プロトコルに基づくデバイス構成方法および装置 - Google Patents

ネットワーク構成プロトコルに基づくデバイス構成方法および装置 Download PDF

Info

Publication number
JP2019514297A
JP2019514297A JP2018554012A JP2018554012A JP2019514297A JP 2019514297 A JP2019514297 A JP 2019514297A JP 2018554012 A JP2018554012 A JP 2018554012A JP 2018554012 A JP2018554012 A JP 2018554012A JP 2019514297 A JP2019514297 A JP 2019514297A
Authority
JP
Japan
Prior art keywords
configuration data
lower level
netconf
yang model
target
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2018554012A
Other languages
English (en)
Other versions
JP6704472B2 (ja
Inventor
ジャン，リン
ヤン，ジィシャン
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Huawei Technologies Co Ltd
Original Assignee
Huawei Technologies Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Huawei Technologies Co Ltd filed Critical Huawei Technologies Co Ltd
Publication of JP2019514297A publication Critical patent/JP2019514297A/ja
Application granted granted Critical
Publication of JP6704472B2 publication Critical patent/JP6704472B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/085—Retrieval of network configuration; Tracking network configuration history
    • H04L41/0853—Retrieval of network configuration; Tracking network configuration history by actively collecting configuration information or by backing up configuration information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0803—Configuration setting
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/02—Standardisation; Integration
    • H04L41/0213—Standardised network management protocols, e.g. simple network management protocol [SNMP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/02—Standardisation; Integration
    • H04L41/024—Standardisation; Integration using relational databases for representation of network management data, e.g. managing via structured query language [SQL]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0893—Assignment of logical groups to network elements
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/22—Indexing; Data structures therefor; Storage structures

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Databases & Information Systems (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Computer And Data Communications (AREA)

Abstract

本願は、ネットワーク構成プロトコルに基づくデバイス構成方法、装置およびシステムを開示し、通信技術の分野に属する。方法は：ネットワーク管理装置によって、あらかじめ定義されたYANGモデルを使って構成データのモデルを確立し；NETCONFに基づいて前記構成データを、管理されるデバイスに送ることを含む。前記あらかじめ定義されたYANGモデルはn個の参照フィールドおよび各参照フィールドに別個に対応する一つまたは複数のオブジェクト・フィールドを含む。本願は、デバイス縦続シナリオにおいてNETCONFメッセージにおいて構成データの、目標となる、より低レベルのデバイスを示すためにNETCONFメッセージに拡張フィールドが追加されるときに、解決策の普遍性が比較的貧弱であり、構成処理効率が比較的低く、データ記憶処理手順が比較的複雑であるという従来技術の問題を解決する。

Description

関連出願への相互参照
本願は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をサポートする。ネットワーク管理デバイスは、図９に示される実施形態において提供されるデバイス構成装置を含む。管理されるデバイスは、図１０に示される実施形態において提供されるデバイス構成装置を含む。
上記の実施形態において提供される装置がその機能を実装するとき、上記の機能ユニットの分割は単に、記述のための例として使われていることを注意しておくべきである。実際の応用では、上記の機能は、必要に応じて実装のための種々の機能ユニットに割り当てられてもよい。すなわち、デバイスの内部構造が、上記の機能の全部または一部を実装するために種々の機能ユニットに分割される。さらに、上記の実施形態において提供される装置実施形態および方法実施形態は、同じ概念に基づく、装置実施形態の具体的な実装プロセスについては、方法実施形態を参照されたい。ここで再び詳細を述べることはしない。
当業者は、実施形態の段階の全部または一部がハードウェアまたは関係したハードウェアに命令するプログラムによって実装されうることを理解しうる。プログラムは、コンピュータ可読記憶媒体に記憶されてもよい。記憶媒体は、読み出し専用メモリ、磁気ディスク、光ディスクなどであってもよい。
上記の記述は単に、本願の例示的実施形態であり、本願を限定することは意図されていない。本願の原理から外れることなくなされるいかなる修正、等価な置換または改善も、本願の保護範囲内にはいるべきである。
関連出願への相互参照
本願は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をサポートする。ネットワーク管理デバイスは、図９に示される実施形態において提供されるデバイス構成装置を含む。管理されるデバイスは、図１０に示される実施形態において提供されるデバイス構成装置を含む。
上記の実施形態において提供される装置がその機能を実装するとき、上記の機能ユニットの分割は単に、記述のための例として使われていることを注意しておくべきである。実際の応用では、上記の機能は、必要に応じて実装のための種々の機能ユニットに割り当てられてもよい。すなわち、デバイスの内部構造が、上記の機能の全部または一部を実装するために種々の機能ユニットに分割される。さらに、上記の実施形態において提供される装置実施形態および方法実施形態は、同じ概念に基づく、装置実施形態の具体的な実装プロセスについては、方法実施形態を参照されたい。ここで再び詳細を述べることはしない。
当業者は、実施形態の段階の全部または一部がハードウェアまたは関係したハードウェアに命令するプログラムによって実装されうることを理解しうる。プログラムは、コンピュータ可読記憶媒体に記憶されてもよい。記憶媒体は、読み出し専用メモリ、磁気ディスク、光ディスクなどであってもよい。
上記の記述は単に、本願の例示的実施形態であり、本願を限定することは意図されていない。本願の原理から外れることなくなされるいかなる修正、等価な置換または改善も、本願の保護範囲内にはいるべきである。

Claims (14)

  1. ネットワーク構成プロトコルNETCONFに基づくデバイス構成方法であって、当該方法はネットワーク管理デバイスに適用され、前記ネットワーク管理デバイスは管理されるデバイスに接続され、前記管理されるデバイスはいくつかの、より低レベルのデバイスに接続され、前記ネットワーク管理デバイスおよび前記管理されるデバイスはNETCONFをサポートし；
    当該方法は：
    あらかじめ定義されたYANGモデルを使って構成データのモデルを確立する段階であって、前記あらかじめ定義されたYANGモデルはn個の参照フィールドおよび各参照フィールドに別個に対応するいくつかのオブジェクト・フィールドを含み、前記参照フィールドは、前記あらかじめ定義されたYANGモデルにおいて参照されるYANGモデルを示すために使われ、i番目の参照フィールドに対応するオブジェクト・フィールドは、前記i番目の参照フィールドにおいて参照されるYANGモデルを使ってモデリングされる目標構成データに対応する、目標となる、より低レベルのデバイスおよび／または目標となる、より低レベルのデバイスのグループを示すために使われ、前記より低レベルのデバイスのグループは、いくつかのより低レベルのデバイスを含むグループであり、1≦i≦nであり、iおよびnは正の整数である、段階と；
    NETCONFに基づいて前記構成データを前記管理されるデバイスに送る段階とを含む、
    方法。
  2. 前記参照フィールドが、第一の文を使って定義され、前記第一の文は、あるYANGモデルにおいて、別のYANGモデルによって定義される模式木を参照するために使われる、請求項１記載の方法。
  3. 前記オブジェクト・フィールドがlaef-list特徴を使って定義され、該leaf-list特徴は、同じ型のリーフ・ノードのグループを記述するために使われる、請求項１記載の方法。
  4. 前記i番目の参照フィールドに対応する前記オブジェクト・フィールドは：いくつかの第一のオブジェクト・フィールドおよび／またはいくつかの第二のオブジェクト・フィールドを含み；
    各第一のオブジェクト・フィールドは、前記i番目の参照フィールドにおいて参照される前記YANGモデルを使ってモデリングされる前記目標構成データが送達されるべき、より低レベルのデバイスを示すために使われ；
    各第二のオブジェクト・フィールドは、前記i番目の参照フィールドにおいて参照される前記YANGモデルを使ってモデリングされる前記目標構成データが送達されるべき、より低レベルのデバイスのグループを示すために使われる、
    請求項１ないし３のうちいずれか一項記載の方法。
  5. ネットワーク構成プロトコルNETCONFに基づくデバイス構成方法であって、当該方法は管理されるデバイスに適用され、前記管理されるデバイスはネットワーク管理デバイスに接続され、前記管理されるデバイスはさらに、いくつかの、より低レベルのデバイスに接続され、前記ネットワーク管理デバイスおよび前記管理されるデバイスはNETCONFをサポートし；
    当該方法は：
    NETCONFに基づいて前記ネットワーク管理デバイスによって送られた構成データを受信する段階であって、前記構成データは、あらかじめ定義されたYANGモデルを使って前記ネットワーク管理デバイスによってモデリングされており、前記あらかじめ定義されたYANGモデルはn個の参照フィールドおよび各参照フィールドに別個に対応するいくつかのオブジェクト・フィールドを含み、前記参照フィールドは、前記あらかじめ定義されたYANGモデルにおいて参照されるYANGモデルを示すために使われ、i番目の参照フィールドに対応するオブジェクト・フィールドは、前記i番目の参照フィールドにおいて参照されるYANGモデルを使ってモデリングされる目標構成データの、目標となる、より低レベルのデバイスおよび／または目標となる、より低レベルのデバイスのグループを示すために使われ、前記より低レベルのデバイスのグループは、いくつかのより低レベルのデバイスを含むグループであり、1≦i≦nであり、iおよびnは正の整数である、段階と；
    前記あらかじめ定義されたYANGモデルに従って前記構成データをパースする段階と；
    パースから得られた前記構成データに従って、より低レベルのデバイスを構成する段階とを含む、
    方法。
  6. パースから得られた前記構成データに従って、より低レベルのデバイスを構成する前記段階は：
    前記i番目の参照フィールドにおいて参照される前記YANGモデルを使ってモデリングされる前記目標構成データについて、前記i番目の参照フィールドに対応する前記オブジェクト・フィールドに従って前記目標構成データの、目標となる、より低レベルのデバイスを決定する段階であって、前記目標となる、より低レベルのデバイスは、前記i番目の参照フィールドに対応するオブジェクト・フィールドによって示される、より低レベルのデバイスおよび／または前記i番目の参照フィールドに対応するオブジェクト・フィールドによって示される、より低レベルのデバイスのグループにおける、より低レベルのデバイスである、段階と；
    目標構成管理プロトコルに基づいて、前記目標構成データを前記目標となる、より低レベルのデバイスに送る段階であって、前記目標構成管理プロトコルは、前記管理されるデバイスおよび前記目標となる、より低レベルのデバイスによってサポートされる構成管理プロトコルである、段階とを含む、
    請求項５記載の方法。
  7. 前記あらかじめ定義されたYANGモデルに従って前記構成データをパースした後、当該方法はさらに：
    パースから得られた前記構成データを、同じ構成データベースに記憶することを含む、
    請求項５または６記載の方法。
  8. ネットワーク構成プロトコルNETCONFに基づくデバイス構成装置であって、当該装置はネットワーク管理デバイスに適用され、前記ネットワーク管理デバイスは管理されるデバイスに接続され、前記管理されるデバイスはいくつかの、より低レベルのデバイスに接続され、前記ネットワーク管理デバイスおよび前記管理されるデバイスはNETCONFをサポートし；
    当該装置は：
    あらかじめ定義されたYANGモデルを使って構成データのモデルを確立するよう構成されたモデリング・ユニットであって、前記あらかじめ定義されたYANGモデルはn個の参照フィールドおよび各参照フィールドに別個に対応するいくつかのオブジェクト・フィールドを含み、前記参照フィールドは、前記あらかじめ定義されたYANGモデルにおいて参照されるYANGモデルを示すために使われ、i番目の参照フィールドに対応するオブジェクト・フィールドは、前記i番目の参照フィールドにおいて参照されるYANGモデルを使ってモデリングされる目標構成データに対応する、目標となる、より低レベルのデバイスおよび／または目標となる、より低レベルのデバイスのグループを示すために使われ、前記より低レベルのデバイスのグループは、いくつかのより低レベルのデバイスを含むグループであり、1≦i≦nであり、iおよびnは正の整数である、モデリング・ユニットと；
    NETCONFに基づいて前記構成データを前記管理されるデバイスに送るよう構成された送信ユニットとを有する、
    装置。
  9. 前記参照フィールドが、第一の文を使って定義され、前記第一の文は、あるYANGモデルにおいて、別のYANGモデルによって定義される模式木を参照するために使われる、請求項８記載の装置。
  10. 前記オブジェクト・フィールドがlaef-list特徴を使って定義され、該leaf-list特徴は、同じ型のリーフ・ノードのグループを記述するために使われる、請求項８記載の装置。
  11. 前記i番目の参照フィールドに対応する前記オブジェクト・フィールドは：いくつかの第一のオブジェクト・フィールドおよび／またはいくつかの第二のオブジェクト・フィールドを含み；
    各第一のオブジェクト・フィールドは、前記i番目の参照フィールドにおいて参照される前記YANGモデルを使ってモデリングされる前記目標構成データが送達されるべき、より低レベルのデバイスを示すために使われ；
    各第二のオブジェクト・フィールドは、前記i番目の参照フィールドにおいて参照される前記YANGモデルを使ってモデリングされる前記目標構成データが送達されるべき、より低レベルのデバイスのグループを示すために使われる、
    請求項８ないし１０のうちいずれか一項記載の装置。
  12. ネットワーク構成プロトコルNETCONFに基づくデバイス構成装置であって、当該装置は管理されるデバイスに適用され、前記管理されるデバイスはネットワーク管理デバイスに接続され、前記管理されるデバイスはさらに、いくつかの、より低レベルのデバイスに接続され、前記ネットワーク管理デバイスおよび前記管理されるデバイスはNETCONFをサポートし；
    当該装置は：
    NETCONFに基づいて前記ネットワーク管理デバイスによって送られた構成データを受信するよう構成された受信ユニットであって、前記構成データは、あらかじめ定義されたYANGモデルを使って前記ネットワーク管理デバイスによってモデリングされており、前記あらかじめ定義されたYANGモデルはn個の参照フィールドおよび各参照フィールドに別個に対応するいくつかのオブジェクト・フィールドを含み、前記参照フィールドは、前記あらかじめ定義されたYANGモデルにおいて参照されるYANGモデルを示すために使われ、i番目の参照フィールドに対応するオブジェクト・フィールドは、前記i番目の参照フィールドにおいて参照されるYANGモデルを使ってモデリングされる目標構成データの、目標となる、より低レベルのデバイスおよび／または目標となる、より低レベルのデバイスのグループを示すために使われ、前記より低レベルのデバイスのグループは、いくつかのより低レベルのデバイスを含むグループであり、1≦i≦nであり、iおよびnは正の整数である、受信ユニットと；
    前記あらかじめ定義されたYANGモデルに従って前記構成データをパースするよう構成されたパース・ユニットと；
    パースから得られた前記構成データに従って、より低レベルのデバイスを構成するよう構成された構成ユニットとを有する、
    装置。
  13. 前記構成ユニットが具体的には：
    前記i番目の参照フィールドにおいて参照される前記YANGモデルを使ってモデリングされる前記目標構成データについて、前記i番目の参照フィールドに対応する前記オブジェクト・フィールドに従って前記目標構成データの、目標となる、より低レベルのデバイスを決定する段階であって、前記目標となる、より低レベルのデバイスは、前記i番目の参照フィールドに対応するオブジェクト・フィールドによって示される、より低レベルのデバイスおよび／または前記i番目の参照フィールドに対応するオブジェクト・フィールドによって示される、より低レベルのデバイスのグループにおける、より低レベルのデバイスである、段階と；
    目標構成管理プロトコルに基づいて、前記目標構成データを前記目標となる、より低レベルのデバイスに送る段階であって、前記目標構成管理プロトコルは、前記管理されるデバイスおよび前記目標となる、より低レベルのデバイスによってサポートされる構成管理プロトコルである、段階とを実行するよう構成されている、
    請求項１２記載の装置。
  14. 当該装置がさらに：
    パースから得られた前記構成データを、同じ構成データベースに記憶するよう構成された記憶ユニットを有する、
    請求項１２または１３記載の装置。
JP2018554012A 2016-04-15 2017-04-06 ネットワーク構成プロトコルに基づくデバイス構成方法および装置 Active JP6704472B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
CN201610234776.9 2016-04-15
CN201610234776.9A CN107302443B (zh) 2016-04-15 2016-04-15 基于网络配置协议的设备配置方法及装置
PCT/CN2017/079558 WO2017177856A1 (zh) 2016-04-15 2017-04-06 基于网络配置协议的设备配置方法及装置

Publications (2)

Publication Number Publication Date
JP2019514297A true JP2019514297A (ja) 2019-05-30
JP6704472B2 JP6704472B2 (ja) 2020-06-03

Family

ID=60041869

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2018554012A Active JP6704472B2 (ja) 2016-04-15 2017-04-06 ネットワーク構成プロトコルに基づくデバイス構成方法および装置

Country Status (6)

Country Link
US (1) US11323316B2 (ja)
EP (1) EP3432517B1 (ja)
JP (1) JP6704472B2 (ja)
CN (1) CN107302443B (ja)
ES (1) ES2806696T3 (ja)
WO (1) WO2017177856A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2022554262A (ja) * 2019-10-31 2022-12-28 華為技術有限公司 デバイス管理方法、装置、システム、及びデバイス、並びに記憶媒体

Families Citing this family (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3516824A4 (en) * 2016-09-19 2020-04-29 Telefonaktiebolaget LM Ericsson (PUBL) NETWORK MANAGEMENT METHOD BASED ON NETCONF PROTOCOL, AND ASSOCIATED NETWORK DEVICE
KR102424056B1 (ko) * 2017-10-31 2022-07-25 한국전자통신연구원 Netconf 기반의 네트워크 시스템 명령어를 yang 언어로 모델링하는 방법 및 장치
CN110351107B (zh) * 2018-04-03 2021-04-09 华为技术有限公司 配置管理方法及装置
CN110855459B (zh) * 2018-08-20 2021-07-09 华为技术有限公司 网络配置方法、装置及系统
CN109194519B (zh) * 2018-09-27 2021-11-16 锐捷网络股份有限公司 网络设备的配置方法、装置、控制器及计算机存储介质
CN109951315B (zh) * 2019-02-14 2022-02-22 烽火通信科技股份有限公司 一种实现yang模型到内部模型映射的方法及系统
US20200274753A1 (en) * 2019-02-26 2020-08-27 Huawei Technologies Co., Ltd. Method for creating and managing permissions for accessing yang data in yang-based datastores
CN112688794A (zh) * 2019-10-18 2021-04-20 华为技术有限公司 Yang模型的管理方法、装置、系统、设备及存储介质
CN111010305A (zh) * 2019-12-23 2020-04-14 烽火通信科技股份有限公司 一种基于netconf协议的配置管理系统及方法
CN111371601A (zh) * 2020-02-26 2020-07-03 苏州浪潮智能科技有限公司 一种服务器配置方法、装置、设备及计算机可读存储介质
CN113824573B (zh) * 2020-06-18 2022-12-13 华为技术有限公司 一种对象管理的方法及装置
CN112636973A (zh) * 2020-12-22 2021-04-09 南方电网深圳数字电网研究院有限公司 基于netconf协议的自动化云网融合方法
WO2022167837A1 (ja) 2021-02-04 2022-08-11 ラクテン・シンフォニー・シンガポール・プライベート・リミテッド ネットワークサービス管理システムおよびネットワークサービス管理方法
US20220294692A1 (en) * 2021-03-09 2022-09-15 Ciena Corporation Limiting the scope of a declarative configuration editing operation
CN113300888B (zh) * 2021-05-21 2022-07-22 刘超 一种yang模型浏览器及客户端设备
CN116185947A (zh) * 2021-11-29 2023-05-30 华为技术有限公司 一种yang模型文件的管理方法、装置及系统
CN117376122A (zh) * 2022-06-30 2024-01-09 中兴通讯股份有限公司 网络配置方法、装置以及存储介质、电子装置
CN117411759A (zh) * 2022-07-07 2024-01-16 中兴通讯股份有限公司 网元管理方法、电子设备、计算机可读介质

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2582092A3 (en) * 2007-09-26 2013-06-12 Nicira, Inc. Network operating system for managing and securing networks
CN102223291A (zh) * 2010-04-14 2011-10-19 华为技术有限公司 实现设备访问方法和设备及通信系统
US8817620B2 (en) * 2010-07-06 2014-08-26 Nicira, Inc. Network virtualization apparatus and method
US8838653B2 (en) * 2010-11-01 2014-09-16 Cisco Technology, Inc. Translating an object-oriented data model to a YANG data model
CN103281197B (zh) * 2013-04-08 2016-03-30 浙江工商大学 一种基于NETCONF的ForCES配置方法
CN104243198B (zh) * 2013-06-21 2019-07-26 中兴通讯股份有限公司 一种基于网络配置协议的网络管理方法和系统
US10084650B2 (en) * 2013-07-09 2018-09-25 Tail-f Systems AB Graphical user interface for customizing graphical representations based on registry data
CN103701653B (zh) * 2014-01-06 2016-09-07 迈普通信技术股份有限公司 一种接口热插拔配置数据的处理方法及网络配置服务器
CN104883266B (zh) 2014-02-28 2018-10-12 新华三技术有限公司 网络配置访问方法及装置
CN104065514A (zh) * 2014-07-02 2014-09-24 清华大学 一种基于netconf中继的家庭网络管理方法
US10797942B2 (en) * 2015-04-01 2020-10-06 Nokia Of America Corporation Provisioning network services for cable systems
US9900209B2 (en) * 2015-09-14 2018-02-20 Cisco Technology, Inc. Techniques for YANG model version control validation

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2022554262A (ja) * 2019-10-31 2022-12-28 華為技術有限公司 デバイス管理方法、装置、システム、及びデバイス、並びに記憶媒体
JP7418565B2 (ja) 2019-10-31 2024-01-19 華為技術有限公司 デバイス管理方法、装置、システム、及びデバイス、並びに記憶媒体

Also Published As

Publication number Publication date
EP3432517B1 (en) 2020-05-13
JP6704472B2 (ja) 2020-06-03
CN107302443A (zh) 2017-10-27
US11323316B2 (en) 2022-05-03
ES2806696T3 (es) 2021-02-18
WO2017177856A1 (zh) 2017-10-19
CN107302443B (zh) 2020-10-16
EP3432517A4 (en) 2019-02-27
US20190052526A1 (en) 2019-02-14
EP3432517A1 (en) 2019-01-23

Similar Documents

Publication Publication Date Title
JP6704472B2 (ja) ネットワーク構成プロトコルに基づくデバイス構成方法および装置
US10892952B2 (en) Supporting compilation and extensibility on unified graph-based intent models
US9083625B2 (en) Communication with components using component-independent driver
EP3709603A1 (en) Method for internet of things device to access network, apparatus, and system
US10382258B2 (en) Viral system discovery and installation for distributed networks
US10250437B2 (en) Method and system for configuring network devices
US8589589B2 (en) Method and system for creating an overlay structure for management information bases
US20200036589A1 (en) Concurrent transactions on netconf devices across network services
CN101035133B (zh) 网络管理的方法、系统及设备
US20230308348A1 (en) Server to support client data models from heterogeneous data sources
JP4473863B2 (ja) 複数のネットワーク構成要素およびそれらの複数の関連性を記述するシステムおよび方法
US9191286B2 (en) Adaptive centralized collection of performance management data using a metamodel
US20150193490A1 (en) Method and device for expressing address of node for device management
CN103532852A (zh) 一种路由调度方法、装置及网络设备
EP1479192B1 (en) Method and apparatus for managing configuration of a network
KR20210066114A (ko) 이기종 IoT 장치와 IoT 플랫폼의 연동을 위한 프록시, 방법 및 상기 프록시를 포함하는 시스템
US20140317255A1 (en) System and method for fast network discovery updating and synchronization using dynamic hashes and hash function values aggregated at multiple levels
Ngoupé et al. A data model for management of network device configuration heterogeneity
WO2020119824A1 (zh) 设备控制方法、装置、控制节点、网络设备、数据中心
US12009970B2 (en) Flexible network management system for configuring network devices
US11451440B1 (en) Sharing configuration resources for network devices among applications
Choudhury Crawling hardware for OpenTOSCA
Dalibalta SNMP MIB for OpenFlow-Capable Switch
JP2003318898A (ja) ダイナミックｓｎｍｐネットワークデバイス
Louca et al. Efficient message-passing and autonomic management architecture for NGNs

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20181026

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20181026

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20190829

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20190910

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20191202

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20200421

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20200512

R150 Certificate of patent or registration of utility model

Ref document number: 6704472

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250