網絡管理技術開發范文

本站小編為你精心準備了網絡管理技術開發參考范文，愿這些范文能點燃您思維的火花，激發您的寫作靈感。歡迎深入閱讀并收藏。

一、網絡管理技術概述

網絡管理已經成為計算機網絡和電信網研究中最重要的內容之一。網絡中采用的先進技術越多，規模越大，網絡的維護和管理工作也就越復雜。計算機網絡和電信網的管理技術是分別形成的，但到后來漸趨同化，差不多具有相同的管理功能和管理原理，只是在網絡管理上的具體對象上有些差異。

通常，一個網絡由許多不同廠家的產品構成，要有效地管理這樣一個網絡系統，就要求各個網絡產品提供統一的管理接口，即遵循標準的網絡管理協議。這樣，一個廠家的網絡管理產品就能方便地管理其他廠家的產品，不同廠家的網絡管理產品之間還能交換管理信息。

在簡單網絡管理協議SNMP（SimpleNetworkManagementProtocol）設計時，就定位在是一種易于實施的基本網絡管理工具。在網管領域中，它扮演了先鋒的角色，因OSI的CMIP發展緩慢同時在Internet的迅猛發展和多廠商環境下的網絡管理解決方案的驅動下，而很快成為了事實上的標準。

SNMP的管理結構如圖1所示。它的核心思想是在每個網絡節點上存放一個管理信息庫MIB（ManagementInformationBase），由節點上60（agent）負責維護，管理者通過應用層協議對這些進行輪詢進而對管理信息庫進行管理。SNMP最大的特點就是其簡單性。它的設計原則是盡量減少網絡管理所帶來的對系統資源的需求，盡量減少agent的復雜性。它的整個管理策略和體系結構的設計都體現了這一原則。

SNMP的主要優點是：

·易于實施；

·成熟的標準；

·C／S模式對資源要求較低；

·廣泛適用，代價低廉。

簡單性是SNMP標準取得成功的主要原因。因為在大型的、多廠商產品構成的復雜網絡中，管理協議的明晰是至關重要的；但同時這又是SNMP的缺陷所在——為了使協議簡單易行，SNMP簡化了不少功能，如：

·沒有提供成批存取機制，對大塊數據進行存取效率很低；

·沒有提供足夠的安全機制，安全性很差；

·只在TCP／IP協議上運行，不支持別的網絡協議；

·沒有提供管理者與管理者之間通信的機制，只適合集中式管理，而不利于進行分布式管理；

·只適于監測網絡設備，不適于監測網絡本身。

針對這些問題，對它的改進工作一直在進行。如1991年11月，推出了RMON（RernoteNetworkMonitor）MIB，加強SNMP對網絡本身的管理能力。它使得SNMP不僅可管理網絡設備，還能監測局域網和互聯網上的數據流量等信息，1992年7月，針對SNMP缺乏安全性的弱點，又公布了S-SNMP（SecureSNMP）草案。到1993年初，又推出了SNMPVersion2即SNMPv2（推出了SNMPv2以后，SNMP就被稱為SNMPv1）。SNM-Pv2包容了以前對SNMP的各項改進工作，并在保持了SNMP清晰性和易于實現的特點以外，吸取了CMIP的部分優點，功能更強，安全性更好，具體表現為：

·提供了驗證機制，加密機制，時間同步機制等，安全性大大提高；

·提供了一次取回大量數據的能力，效率大大提高；

·增加了管理者和管理者之間的信息交換機制，從而支持分布式管理結構，由位于中間層次（intermediate）的管理者來分擔主管理者的任務，增加了遠地站點的局部自主性。

·可在多種網絡協議上運行，如OSI、AppleTalk和IPX等，適用多協議網絡環境（但它的缺省網絡協議仍是UDP）。

·擴展了管理信息結構的很多方面。特別是對象類型的定義引入了幾種新的類型。另外還規范了一種新的約定用來創建和刪除管理表（managementbrs）中的“行”（rows）。

·定義了兩種新的協議數據單元PDU（ProtocolDataUnit）。Get-Bulk-Request協議數據單元允許檢索大數據塊（largedatablocks），不必象SNMP那樣逐項（itembyitem）檢索；Inform-Request協議數據單元允許在管理者之間交換陷阱（tran）信息。

CMIP協議是在OSI制訂的網絡管理框架中提出的網絡管理協議。CMIP與SNMP一樣，也是由管理者、、管理協議與管理信息庫組成。

CMIP是基于面向對象的管理模型的。這個管理模型表示了封裝的資源并標準化了它們所提供的接口。如圖2所示了四個主要的元素：

·系統管理應用進程是在擔負管理功能的設備（服務器或路由器等〕中運行的軟件：

·管理信息庫MIB是一組從各個接點收集來的與網絡管理有關的數據；

·系統管理應用實體（systemmanagementapplicationentities）負責網絡管理工作站間的管理信息的交換，以及與網絡中其它接點之間的信息交換；

·層管理實體（layermanagemententities）表示在OSI體系結構設計中必要的邏輯。

CMIP模型也是基于C／S結構的。客戶端是管理系統，也稱管理者，發起操作并接收通知；服務器是被管系統，也稱，接收管理指令，執行命令并上報事件通知。一個CMIP操作臺（console）可以和一個設備建立一個會話，并用一個命令就可以下載許多不同的信息。例如，可以得到一個設備在一段特定時間內所有差錯統計信息。

CMIP采用基于事件而不是基于輪詢的方法來獲得網絡組件的相關數據。

CMIP已經得到主要廠商，包括IBM、HP及AT&T的支持。用戶和廠商已經認識到CMIP在企業級網絡管理領域是一個比較好的選擇。它能夠滿足企業級網管對橫跨多個管理域的對等相互作用（peertopeerinteractions）的要求。CMIP特別適合對要求提供集中式管理的樹狀系統，尤其是對電信網（telecommunicationsnetwork）的管理。這就是下面提到的電信管理網。

二、電信管理網TMN

電信管理網TMN是國際電聯ITU-T借鑒0SI中有關系統管理的思想及技術，為管理電信業務而定義的結構化網絡體系結構，TMN基于OSI系統管理（ITU-UX.700／ISO7498-4）的概念，并在電信領域的應用中有所發展.它使得網絡管理系統與電信網在標準的體系結構下，按照標準的接口和標準的信息格式交換管理信息，從而實現網絡管理功能。TMN的基本原理之一就是使管理功能與電信功能分離。網絡管理者可以從有限的幾個管理節點管理電信網絡中分布的電信設備。

國際電信聯盟（ITU）在M.3010建議中指出，電信管理網的基本概念是提供一個有組織的網絡結構，以取得各種類型的操作系統（OSs）之間、操作系統與電信設備之間的互連。它采用商定的具有標準協議和信息的接口進行管理信息交換的體系結構。提出TMN體系結構的目的是支撐電信網和電信業務的規劃、配置、安裝、操作及組織。

電信管理網TMN的目的是提供一組標準接口，使得對網絡的操作、管理和維護及對網絡單元的管理變得容易實現，所以，TMN的提出很大程度上是為了滿足網管各部分之間的互連性的要求。集中式的管理和分布式的處理是TMN的突出特點。

ITU-T從三個方面定義了TMN的體系結構（Architecture），即功能體系結構（FunctionalArchitecture），信息體系結構（InformationArchitecture）和物理體系結構（PhysicalArchitecture）。它們分別體現在管理功能塊的劃分、信息交互的方式和網管的物理實現。我們按TMN的標準從這三個方面出發，對TMN系統的結構進行設計。

功能體系結構是從邏輯上描述TMN內部的功能分布。引入了一組標準的功能塊（Functionalblock）和可能發生信息交換的參考點（referencepoints）。整個TMN系統即是各種功能塊的組合。

信息體系結構包括兩個方面：管理信息模型和管理信息交換。管理信息模型是對網絡資源及其所支持的管理活動的抽象表示，網絡管理功能即是在信息模型的基礎上實現的。管理信息交換主要涉及到TMN的數據通信功能和消息傳遞功能，即各物理實體和功能實體之間的通信。

物理體系結構是為實現TMN的功能所需的各種物理實體的組織結構。TMN功能的實現依賴于具體的物理體系結構，從功能體系結構到物理體系結構存在著映射關系。物理體系結構隨具體情況的不同而千差萬別。在物理體系結構和功能體系結構之間有一定的映射關系。物理體系結構中的一個物理塊實現了功能體系結構中的一個或多個功能塊，一個接口實現了功能體系結構中的一組參考點。

仿照OSI網絡分層模型，ITU-T進一步在TMN中引入了邏輯分層。如圖3所示：

TMN的邏輯分層是將管理功能針對不同的管理對象映射到事務管理層BML（BusinessManagementLayer），業務管理層SML（ServiceManagementLayer），網絡管理層NML（NetworkManagementLayer）和網元管理層EML（ElementManagementLayer）。再加上物理存在的網元層NEL（NetworkElementLayer），就構成了TMN的邏輯分層體系結構。從圖2-6可以看到，TMN定義的五大管理功能在每一層上都存在，但各層的側重點不同。這與各層定義的管理范圍和對象有關。

三、TMN開發平臺和開發工具

1．利用TMN的開發工具開發TMN的必要性

TMN的信息體系結構應用OSI系統管理的原則，引入了管理者和的概念，強調在面向事物處理的信息交換中采用面向對象的技術。如前所述，TMN是高度強調標準化的網絡，故基于TMN標準的產品開發，其標準規范要求嚴格復雜，使得TMN的實施成為一項具有難度和挑戰性的工作；再加上OSI系統管理專業人員的相對缺乏，因此，工具的引入有助于簡化TMN的開發，提高開發效率。目前比較流行的基于TMN標準的開發平臺有HPOVDM、SUNSEM、IBMTMN平臺和DSET的DSG及其系列工具。這些平臺可以用于開發全方位的TMN管理者和應用，大大降低TMN／Q3應用系統的編程復雜性，并且使之符合開放系統互連（OSI）網絡管理標準，這些標準包括高級信息模型定義語言GDM0，OSI標準信息傳輸協議CMIP，以及抽象數據類型定義語言ASN.1。其中DSET的DSG及工具系列除了具備以上功能外，還具有獨立于硬件平臺的優點。下面將比較詳細論述DSET的TMN開發工具及其在TMN開發中的作用。

2．DSET的TMN開發工具的基本組成

DSET的TMN開發工具從功能上來講可以構成一個平臺和兩大工具箱。一個平臺：分布式系統生成器DSG（DistributedSystemGenerator）；兩個工具箱：管理者工具箱和工具箱。

分布式系統生成器DSG

DSG是用于頂層TCP／IP、OSI和其它協議上構筑分布式并發系統的高級對象請求0RB。DSG將復雜的通信基礎設施和面向對象技術相結合，提供構筑分布式計算的軟件平臺。通信基礎設施支持分布式計算中通信域的通信要求。如圖4所示，它提供了四種主要的服務：透明遠程操作、遠程過程調用和消息傳遞、抽象數據服務及命名服務。借助于并發的面向對象框架，一個復雜的應用可以分解成一組相互通信的并發對象worker，除了支持例如類和多重繼承等重要的傳統面向對象特征外，為了構筑新的worker類，DSG也支持分布式對象。在一個開放系統中，一個worker可以和其它worker進行通信，而不必去關心它們所處的物理位置。

DSG提供給用戶用以開發應用的構造塊（buildingblock）稱為worker。一個worker可以有自己的控制線程，也可以和別的線程共享一個控制線程，每個Worker都有自己的服務訪問點SAP（ServiceAccessPoint），通過SAP與其它worker通信。Worker是事件驅動的。在Worker內部，由有限狀態機FSM（FiniteStateMachine〕定義各種動作及處理例程，DSG接受外部事件并分發到相應的動作處理例程進行處理。如圖5所示，獨占線程的此worker有三個狀態，兩個SAPs，并且每個SAP的消息隊列中都有兩個事件。DSG環境通過將這些事件送到相應的事件處理程序中來驅動worker的有限狀態機。

Worker是分布式的并發對象，DSG用它來支持面向對象的特點，如：類，繼承等等。Worker由workerclass定義。Worker可以根據需要由應用程序動態創建。在一個UNIX進程中可以創建的Worker個數僅受內存的限制。

管理者工具箱由ASN.C／C＋＋編譯器、CMIP／ROSE協議和管理者代碼生成器MCG構成，如圖6所示。

其中的CMIP／ROSE協議提供全套符合Q3接口選用的OSI七層協議棧實施。由于TMN在典型的電信環境中以面向對象的信息模型控制和管理物理資源，所有被管理的資源均被抽象為被管對象（M0），被管理系統中的幫助管理者通過MO訪問被管理資源，又根據ITU-TM.3010建議：管理者與之間通過Q3接口通信。為此管理者必須產生與通信的CMIP請求。管理者代碼生成器讀取信息模型（GDMO文件和ASN.1文件），創立代碼模板來為每個被定義的MO類產生CMIP請求和CMIP響應。由于所有CMIP數據均由ASN.1符號定義，而上層管理應用可能采用C／C++，故管理者應用需要包含ASN.1數據處理代碼，管理者工具箱中的ASNC／C++編譯器提供ASN.1數據到C／C++語言的映射，并采用“預處理技術“生成ASN.1數據的低級代碼，可見利用DSET工具用戶只需編寫網管系統的信息模型和相關的抽象數據類型定義文件，然后利用DSET的ASNC／C++編譯器，管理者代碼生成器即可生成管理者部分代碼框架。

工具箱包括可硯化生成器VAB、CMIP翻譯器、ASN.C／C++Toolkit，其結構見圖7。用來開發符合管理目標定義指南GDMO和通用管理信息協議CMIP規定的應用.使用DSET獨具特色的工具箱的最大的好處就是更快、更容易地進行應用的開發。DSET在應用的開發上為用戶做了大量的工作。

一個典型的GDMO／CM1P應用包括三個代碼模塊：

·、MIT、MIB的實施

·被管理資源的接口代碼

·后端被管理資源代碼

第一個模塊用于處理與MO實施。工具箱通過對過濾、特性處理、MO實例的通用支持，自動構作這一個模塊。DSET的這一部分做得相當完善，用戶只需作少量工作即可完成本模塊的創建。對于mcreate、m-delete、m-get、m-cancel-get、m-set、m-set-confirmed、m-action、m-action-confirmed這些CMIP請求，第一個模塊中包含有缺省的處理代碼框架。這些缺省代碼都假定管理者的CMIP請求只與MO打交道。為了適應不同用戶的需求，DSET工具箱又提供在缺省處理前后調用用戶程序的接入點（稱為Userhooks）。當某CMIP請求需與實際被管資源或數據庫打交道時，用戶可在相應的PRE-或POST-函數中加入自己的處理代碼。例如，當你需要在二層管理應用中發CMIP請求，需望獲取實際被管資源的某屬性，而該屬性又不在相應MO中時你只需在GDMO預定義模板中為此屬性定義一PRE-GET函數，并在你自己的定制文件中為此函數編寫從實際被管設備取到該屬性值的代碼即可。DSET的Agent代碼在執行每個CMIP請求前都要先檢查用戶是否在GDMO預定義文件中為此清求定義了PRE-函數，若是，則光執行PRE-函數，并根據返回值決定是否執行缺省處理（PRE-函數返回D-OK則需執行缺省處理，否則Agent向管理者返回正確或錯誤響應）。同樣當Agent執行完缺省處理函數時，也會檢查用戶是否為該請求定義了POST-函數，若是則繼續執行POST-函數。至于Agent與MO之間具體是如何實現通信的，用戶不必關心，因為DSET已為我們實現了。用戶只需關心需要與設備交互的那一部分CMIP請求，為其定制PRE-／POST函數即可。

第二個模塊實現MO與實際被管資源的通信。它的實現依賴于分布式系統生成器DSG所提供“網關處理單元”（gateway）、遠程過程調用（RPC）與消息傳遞機制及MSL語言編譯器。通信雙方的接口定義由用戶在簡化的ROSE應用中定義，在DSG中也叫環境，該環境定義了雙方的所有操作和相關參數。DSG的CTX編譯器編譯CTX格式的接口定義并生成接口表。DSG的MSL語言編譯器用以編譯分布式對象類的定義并生成事件調度表。采用DSG的網關作為MO與實際被管資源間的通信橋梁，網關與MO之間通過定義接口定義文件及各自的MSL文件即可實現通信，網關與被管設備之間采用設備所支持的通信協議來進行通信，例如采用TCP／IP協議及Socket機制實現通信。

第三個模塊對被管理資源進行實際處理。這一模塊根據第二個模塊中定義的網關與被管設備間的通信機制來實現，與工具沒有多大聯系。