網(wǎng)絡(luò )管理技術(shù)論文三篇
網(wǎng)絡(luò )管理的目的就是確保一定范圍內的網(wǎng)絡(luò )及其網(wǎng)絡(luò )設備能夠穩定、可靠、高效地運行，使所有的網(wǎng)絡(luò )資源處于良好的運行狀態(tài)，達到用戶(hù)預期的要求。接下來(lái)小編為你帶來(lái)網(wǎng)絡(luò )管理技術(shù)論文，希望對你有幫助。
篇一：網(wǎng)絡(luò )管理技術(shù)論文
過(guò)去有一些簡(jiǎn)單的工具用來(lái)幫助網(wǎng)管人員管理網(wǎng)絡(luò )資源，但隨著(zhù)網(wǎng)絡(luò )規模的擴大和復雜度的增加，對強大易用的管理工具的需求也日益顯得迫切，管理人員需要依賴(lài)強大的工具完成各種各樣的網(wǎng)絡(luò )管理任務(wù)，而網(wǎng)絡(luò )管理系統就是能夠實(shí)現上述目的系統。
1WBM技術(shù)介紹
隨著(zhù)應用Intranet的企業(yè)的增多，同時(shí)Internet技術(shù)逐漸向Intranet的遷移，一些主要的網(wǎng)絡(luò )廠(chǎng)商正試圖以一種新的形式去應用MIS。因此就促使了Web(Web-BasedManagement)網(wǎng)管技術(shù)的產(chǎn)生[2]。它作為一種全新的網(wǎng)絡(luò )管理模式—基于Web的網(wǎng)絡(luò )管理模式，從出現伊始就表現出強大的生命力，以其特有的靈活性、易操作性等特點(diǎn)贏(yíng)得了許多技術(shù)專(zhuān)家和用戶(hù)的青睞，被譽(yù)為是“將改變用戶(hù)網(wǎng)絡(luò )管理方式的革命性網(wǎng)絡(luò )管理解決方案”。
WBM融合了Web功能與網(wǎng)管技術(shù)，從而為網(wǎng)管人員提供了比傳統工具更強有力的能力。WBM可以允許網(wǎng)絡(luò )管理人員使用任何一種Web瀏覽器，在網(wǎng)絡(luò )任何節點(diǎn)上方便迅速地配置、控制以及存取網(wǎng)絡(luò )和它的各個(gè)部分。因此，他們不再只拘泥于網(wǎng)管工作站上了，并且由此能夠解決很多由于多平臺結構產(chǎn)生的互操作性問(wèn)題。WBM提供比傳統的命令驅動(dòng)的遠程登錄屏幕更直接、更易用的圖形界面，瀏覽器操作和Web頁(yè)面對WWW用戶(hù)來(lái)講是非常熟悉的，所以WBM的結果必然是既降低了MIS全體培訓的費用又促進(jìn)了更多的用戶(hù)去利用網(wǎng)絡(luò )運行狀態(tài)信息。所以說(shuō)，WBM是網(wǎng)絡(luò )管理方案的一次革命。
2基于WBM技術(shù)的網(wǎng)管系統設計
2.1系統的設計目標
在本系統設計階段，就定下以開(kāi)發(fā)基于園區網(wǎng)、Web模式的具有自主版權的中文網(wǎng)絡(luò )管理系統軟件為目標，采用先進(jìn)的WBM技術(shù)和高效的算法，力求在性能上可以達到國外同類(lèi)產(chǎn)品的水平。
本網(wǎng)管系統提供基于WEB的整套網(wǎng)管解決方案。它針對分布式IP網(wǎng)絡(luò )進(jìn)行有效資源管理，使用戶(hù)可以從任何地方通過(guò)WEB瀏覽器對網(wǎng)絡(luò )和設備，以及相關(guān)系統和服務(wù)實(shí)施應變式管理和控制，從而保證網(wǎng)絡(luò )上的資源處于最佳運行狀態(tài)，并保持網(wǎng)絡(luò )的可用性和可靠性。
2.2系統的體系結構
在系統設計的時(shí)候，以國外同類(lèi)的先進(jìn)產(chǎn)品作為參照物，同時(shí)考慮到技術(shù)發(fā)展的趨勢，在當前的技術(shù)條件下進(jìn)行設計。我們采用三層結構的設計，融合了先進(jìn)的WBM技術(shù)，使系統能夠提供給管理員靈活簡(jiǎn)便的管理途徑。
三層結構的特點(diǎn)[2]：1)完成管理任務(wù)的軟件作為中間層以后臺進(jìn)程方式實(shí)現，實(shí)施網(wǎng)絡(luò )設備的輪詢(xún)和故障信息的收集；2)管理中間件駐留在網(wǎng)絡(luò )設備和瀏覽器之間，用戶(hù)僅需通過(guò)管理中間層的主頁(yè)存取被管設備；3)管理中間件中繼轉發(fā)管理信息并進(jìn)行SNMP和HTTP之間的協(xié)議轉換三層結構無(wú)需對設備作任何改變。
3網(wǎng)絡(luò )拓撲發(fā)現算法的設計
為了實(shí)施對網(wǎng)絡(luò )的管理，網(wǎng)管系統必須有一個(gè)直觀(guān)的、友好的用戶(hù)界面來(lái)幫助管理員。其中最基本的一個(gè)幫助就是把網(wǎng)絡(luò )設備的拓撲關(guān)系以圖形的方式展現在用戶(hù)面前，即拓撲發(fā)現。目前廣泛采用的拓撲發(fā)現算法是基于SNMP的拓撲發(fā)現算法�；赟NMP的拓撲算法在一定程度上是非常有效的，拓撲的速度也非�？�。但它存在一個(gè)缺陷[3]。那就是，在一個(gè)特定的域中，所有的子網(wǎng)的信息都依賴(lài)于設備具有SNMP的特性，如果系統不支持SNMP，則這種方法就無(wú)能為力了。還有對網(wǎng)絡(luò )管理的不重視，或者考慮到安全方面的原因，人們往往把網(wǎng)絡(luò )設備的SNMP功能關(guān)閉，這樣就難于取得設備的MIB值，就出現了拓撲的不完整性，嚴重影響了網(wǎng)絡(luò )管理系統的功能。針對這一的問(wèn)題，下面討論本系統對上述算法的改進(jìn)—基于ICMP協(xié)議的拓撲發(fā)現。
.1PING和路由建立
PING的主要操作是發(fā)送報文，并簡(jiǎn)單地等待回答。PING之所以如此命名，是因為它是一個(gè)簡(jiǎn)單的回顯協(xié)議，使用ICMP響應請求與響應應答報文。PING主要由系統程序員用于診斷和調試實(shí)現PING的過(guò)程主要是：首先向目的機器發(fā)送一個(gè)響應請求的ICMP報文，然后等待目的機器的應答，直到超時(shí)。如收到應答報文，則報告目的機器運行正常，程序退出。
路由建立的功能就是利用IP頭中的TTL域。開(kāi)始時(shí)信源設置IP頭的TTL值為0，發(fā)送報文給信宿，第一個(gè)網(wǎng)關(guān)收到此報文后，發(fā)現TTL值為0，它丟棄此報文，并發(fā)送一個(gè)類(lèi)型為超時(shí)的ICMP報文給信源。信源接收到此報文后對它進(jìn)行解析，這樣就得到了路由中的第一個(gè)網(wǎng)關(guān)地址。然后信源發(fā)送TTL值為1的報文給信宿，第一個(gè)網(wǎng)關(guān)把它的TTL值減為0后轉發(fā)給第二個(gè)網(wǎng)關(guān)，第二個(gè)網(wǎng)關(guān)發(fā)現報文TTL值為0，丟棄此報文并向信源發(fā)送超時(shí)ICMP報文。這樣就得到了路由中和第二個(gè)網(wǎng)關(guān)地址。如此循環(huán)下去，直到報文正確到達信宿，這樣就得到了通往信宿的路由。
3.2網(wǎng)絡(luò )拓撲的發(fā)現算法具體實(shí)現的步驟：
(1)于給定的IP區間，利用PING依次檢測每個(gè)IP地址，將檢測到的IP地址記錄到IP地址表中。
(2)對第一步中查到的每個(gè)IP地址進(jìn)行traceroute操作，記錄到這些IP地址的路由。并把每條路由中的網(wǎng)關(guān)地址也加到IP表中。(3)對IP地址表中的每個(gè)IP地址，通過(guò)發(fā)送掩碼請求報文與接收掩碼應答報文，找到這些IP地址的子網(wǎng)掩碼。
(4)根據子網(wǎng)掩碼，確定對應每個(gè)IP地址的子網(wǎng)地址，并確定各個(gè)子網(wǎng)的網(wǎng)絡(luò )類(lèi)型。把查到的各個(gè)子網(wǎng)加入地址表中。
(5)試圖得到與IP地址表中每個(gè)IP地址對應的域名(DomainName)，如具有相同域名，則說(shuō)明同一個(gè)網(wǎng)絡(luò )設備具有多個(gè)IP地址，即具有多個(gè)網(wǎng)絡(luò )接口。
(6)根據第二步中的路由與第四步中得到的子網(wǎng)，產(chǎn)生連接情況表。
4結語(yǔ)
本文提出的ICMP協(xié)議的拓撲發(fā)現方法能夠較好的發(fā)現網(wǎng)絡(luò )拓撲，但是它需要占用大量的帶寬資源。本系統進(jìn)行設計時(shí)，主要考慮的是對園區網(wǎng)絡(luò )的網(wǎng)絡(luò )管理，所有的被管理設備和網(wǎng)管系統處于同一段網(wǎng)絡(luò )上，也就是說(shuō)，系統可以直接到達被管理的網(wǎng)絡(luò )，所以對遠程的局域網(wǎng)就無(wú)能為力了。在做下一步工作的時(shí)候，可以添加系統對遠程局域網(wǎng)絡(luò )的管理功能。
參考文獻
[1]晏蒲柳.大規模智能網(wǎng)絡(luò )管理模型方法[J].計算機應用研究.2005,03.
[2]周楊,家海,任憲坤,王沛瑜.網(wǎng)絡(luò )管理原理與實(shí)現技術(shù)[M].北京:清華大學(xué)出版社.2000.
[3]李佳石,冰心著(zhù).網(wǎng)絡(luò )管理系統中的自動(dòng)拓撲算法[J].華中科技大學(xué)學(xué)報.2002,06.
篇二：網(wǎng)絡(luò )管理技術(shù)論文
1應用局域網(wǎng)絡(luò )管理軟件平臺
(1)面向業(yè)務(wù)操作者的業(yè)務(wù)工具。工作人員可以借助、使用應用局域網(wǎng)絡(luò )管理軟件平臺進(jìn)行器具收集、器具發(fā)放、證書(shū)制作、證書(shū)審核、證書(shū)打印、財務(wù)收費和證書(shū)領(lǐng)取等操作。(2)面向客戶(hù)的器具送檢工具。應用局域網(wǎng)絡(luò )管理軟件平臺實(shí)現了局域網(wǎng)上送檢業(yè)務(wù)受理功能，可以及時(shí)了解送檢客戶(hù)計量?jì)x器檢定情況。(3)高效的證書(shū)制作流程。應用局域網(wǎng)絡(luò )管理軟件平臺充分考慮了制作證書(shū)環(huán)節各要素間的邏輯關(guān)系，通過(guò)關(guān)聯(lián)匹配關(guān)系的設置，最大化減少了人為操作，提高了檢定員制作證書(shū)的工作效率，同時(shí)可根據用戶(hù)的要求合并多個(gè)器具到一張證書(shū)。(4)完整的財務(wù)管理。應用局域網(wǎng)絡(luò )管理軟件平臺有到賬確認、證書(shū)領(lǐng)取、發(fā)票關(guān)聯(lián)等財務(wù)模塊，成功地解決了證書(shū)領(lǐng)取不規范、到賬確認不嚴謹、收費統計不準確等問(wèn)題，實(shí)現了規范和靈活的高度統一。(5)方便的內檢委托單生成功能。對于內檢計量器具，應用局域網(wǎng)絡(luò )管理軟件平臺可以自動(dòng)生成相關(guān)的單據，規范和簡(jiǎn)化了工作流程。(6)有效的監管功能。通過(guò)建立和計量監督機構的數據共享，應用局域網(wǎng)絡(luò )管理軟件平臺可以實(shí)現監督、檢定(校準)的聯(lián)動(dòng)，提高了監督部門(mén)的工作效率，降低了工作強度，加強了計量技術(shù)機構的工作針對性。(7)資料的規范化管理。通過(guò)對計量標準、計量?jì)x器信息及時(shí)補充，實(shí)現了業(yè)務(wù)管理部門(mén)對各種考核、認證資料電子化管理和自動(dòng)生成、更新，從而降低了業(yè)務(wù)人員的工作強度。(8)高效方便的操作體驗。批量錄入送檢儀器、檢定任務(wù)自動(dòng)分配、鼠標滾輪滾動(dòng)加減數字輸入，系統盡最大可能減少了用戶(hù)操作鍵盤(pán)的輸入強度。
2應用局域網(wǎng)絡(luò )管理軟件功能
應用局域網(wǎng)絡(luò )管理軟件由九大模塊構成，分別為:基礎信息、計量標準、標準器、儀器收發(fā)、檢定業(yè)務(wù)、證書(shū)制作、統計查詢(xún)、系統管理和消息平臺。
2.1基礎信息
基礎信息模塊包括專(zhuān)業(yè)類(lèi)別信息、人員管理信息、格式模板管理信息、數據模板管理信息、規程規范管理、開(kāi)展項目信息、授權簽字人權限、客戶(hù)管理、個(gè)性化設置等，為系統的運營(yíng)提供了基本的數據支持。(1)專(zhuān)業(yè)類(lèi)別信息。對檢定專(zhuān)業(yè)以及對應的證書(shū)序號進(jìn)行管理。(2)人員管理信息。對工作人員進(jìn)行管理，對人員所使用的規程、設備、模板、開(kāi)展項目和專(zhuān)業(yè)類(lèi)別進(jìn)行管理，并且可以設置人員是否為登錄用戶(hù)。(3)格式模板管理、數據模板管理信息。對證書(shū)的首頁(yè)模板和續頁(yè)模板文件進(jìn)行管理。其中首頁(yè)模板文件根據國家對檢定證書(shū)的統一要求來(lái)管理。續頁(yè)模板是指輸出檢定數據的模板，是采用Word文件形式制作的模板，方便用戶(hù)自己設置模板文件。(4)規程規范管理。對計量標準考核規范信息進(jìn)行管理，可以保證使用的是現行有效規程規范。(5)開(kāi)展項目信息。對機構可以開(kāi)展的檢定項目進(jìn)行管理，并對其相關(guān)聯(lián)的規范、設備和模板進(jìn)行維護。(6)授權簽字人權限。對科室中規定時(shí)間段內具有審核權限的人員進(jìn)行管理。
2.2計量標準
計量標準模塊包括計量標準名稱(chēng)分類(lèi)、計量器具名稱(chēng)與分類(lèi)代碼、計量標準三個(gè)部分，主要是為制作證書(shū)提供必要的計量標準數據。根據JJF1022—1991《計量標準命名技術(shù)規范》，JJF1051—2009《計量器具命名與分類(lèi)編碼》對命名進(jìn)行規范。計量標準主要對所建的考核標準進(jìn)行管理，并對標準的重復性、穩定性和考核復查信息進(jìn)行記錄。建標時(shí)對其中所規定的標準器、配套設備、配套設施和規程都建立了對應關(guān)系。
2.3標準器
標準器模塊包括標準器分類(lèi)、標準器管理、標準器維護、上級溯源單位和制造廠(chǎng)商五個(gè)部分。(1)標準器分類(lèi)。對標準器分類(lèi)信息進(jìn)行管理。(2)標準器管理。對標準器的基本信息、標準器對應的參數、附件和附件的參數信息進(jìn)行管理。(3)標準器維護。對標準器的動(dòng)態(tài)信息，包括對過(guò)期或報廢的標準器進(jìn)行更換、修理記錄、量值溯源信息、期間考核計劃、使用記錄進(jìn)行管理。
2.4儀器收發(fā)
儀器收發(fā)包括委托單管理、器具分發(fā)、退檢管理、器具返回、證書(shū)打印、發(fā)放證書(shū)和報價(jià)單管理等。(1)委托單管理是指對客戶(hù)送檢器具所填寫(xiě)的委托協(xié)議書(shū)相關(guān)信息進(jìn)行管理，主要包括客戶(hù)器具信息的管理、客戶(hù)單位的添加、送檢器具的信息一覽表，實(shí)現了對送檢過(guò)的器具的管理，方便快速錄入和查詢(xún)相關(guān)信息。委托單中的“流水號管理”指的是儀器收發(fā)室的手寫(xiě)單上的流水號;信息“是否連續”指的是手寫(xiě)單上的流水號是否連續沒(méi)有斷號。在手寫(xiě)單多頁(yè)的情況下能自動(dòng)生成相應的流水號，不需要錄入人員輸入每個(gè)流水號。用戶(hù)可以通過(guò)流水號對送檢器具信息進(jìn)行查詢(xún)。委托單中，將計量器具分到相應科室的一系列信息，如“檢定科室”、“到樣日期”、“客戶(hù)要求”，“附件”、“備注”自動(dòng)變?yōu)榭删庉嫚顟B(tài)。系統可以對多條信息的列(如“檢定科室”、“客戶(hù)要求”、“備注”等)設置相同內容，方便用戶(hù)錄入。根據客戶(hù)實(shí)際要求在“客戶(hù)要求”中選擇相應的選項，“附件”用于記錄客戶(hù)送檢器具的附帶物品。(2)器具分發(fā)是指對客戶(hù)的送檢器具指定相應的檢定科室，系統會(huì )根據委托單的信息進(jìn)行自動(dòng)分發(fā)。(3)證書(shū)打印、發(fā)放證書(shū)是指證書(shū)的打印以及給用戶(hù)發(fā)放的記錄。(4)報價(jià)單管理是指打印用戶(hù)送檢器具的報價(jià)單信息。
2.5檢定業(yè)務(wù)
檢定業(yè)務(wù)包括分配任務(wù)、個(gè)人任務(wù)管理、領(lǐng)取器具、規程規范領(lǐng)用記錄、報價(jià)管理和證書(shū)費用修改。(1)分配任務(wù)是指科室負責人把科室任務(wù)分配給相應的檢定人員。(2)個(gè)人任務(wù)管理是指檢定員對分配給自己的任務(wù)進(jìn)行查看和管理。(3)領(lǐng)取器具是指檢定人員從儀器收發(fā)室領(lǐng)取個(gè)人任務(wù)中的客戶(hù)送檢器具。(4)證書(shū)費用修改是指對沒(méi)有生成繳費單的證書(shū)，檢定員自己修改證書(shū)的費用。
2.6證書(shū)制作
證書(shū)制作包括證書(shū)管理信息，制作證書(shū)信息，證書(shū)的核驗、審核和審批，證書(shū)廢棄審核，這些均應符合質(zhì)量管理體系要求。
3結束語(yǔ)
應用局域網(wǎng)絡(luò )管理軟件在很大程度上滿(mǎn)足了計量技術(shù)機構對日益增長(cháng)的業(yè)務(wù)管理的需求，滿(mǎn)足了JJF1069—2012《法定計量檢定機構考核規范》中對計量技術(shù)機構管理體系的要求，完全實(shí)現了檢定、校準各個(gè)環(huán)節工作的信息化、統一化、規范化，保證了機構內部建立適宜的溝通機制，提高了工作效率，將計量機構業(yè)務(wù)管理推向一個(gè)新的高度。
篇三：網(wǎng)絡(luò )管理技術(shù)論文
摘 要：網(wǎng)絡(luò )管理已經(jīng)成為計算機網(wǎng)絡(luò )和電信網(wǎng)研究中最重要的內容之一。本文首先介紹當前幾種網(wǎng)絡(luò )管理技術(shù)和TMN基本概念，然后討論了TMN開(kāi)發(fā)中的關(guān)鍵技術(shù)及TMN開(kāi)發(fā)工具引入的必要性，并結合自己的開(kāi)發(fā)實(shí)踐討論了TMN管理者和代理的開(kāi)發(fā)，最后對電信管理網(wǎng)的未來(lái)發(fā)展趨勢進(jìn)行了展望。
一、網(wǎng)絡(luò )管理技術(shù)概述
網(wǎng)絡(luò )管理已經(jīng)成為計算機網(wǎng)絡(luò )和電信網(wǎng)研究中最重要的內容之一。網(wǎng)絡(luò )中采用的先進(jìn)技術(shù)越多，規模越大，網(wǎng)絡(luò )的維護和管理工作也就越復雜。計算機網(wǎng)絡(luò )和電信網(wǎng)的管理技術(shù)是分別形成的，但到后來(lái)漸趨同化，差不多具有相同的管理功能和管理原理，只是在網(wǎng)絡(luò )管理上的具體對象上有些差異。
通常，一個(gè)網(wǎng)絡(luò )由許多不同廠(chǎng)家的產(chǎn)品構成，要有效地管理這樣一個(gè)網(wǎng)絡(luò )系統，就要求各個(gè)網(wǎng)絡(luò )產(chǎn)品提供統一的管理接口，即遵循標準的網(wǎng)絡(luò )管理協(xié)議。這樣，一個(gè)廠(chǎng)家的網(wǎng)絡(luò )管理產(chǎn)品就能方便地管理其他廠(chǎng)家的產(chǎn)品，不同廠(chǎng)家的網(wǎng)絡(luò )管理產(chǎn)品之間還能交換管理信息。
在簡(jiǎn)單網(wǎng)絡(luò )管理協(xié)議SNMP（Simple Network Management Protocol）設計時(shí)，就定位在是一種易于實(shí)施的基本網(wǎng)絡(luò )管理工具。在網(wǎng)管領(lǐng)域中，它扮演了先鋒的角色，因OSI的CMIP發(fā)展緩慢同時(shí)在Internet的迅猛發(fā)展和多廠(chǎng)商環(huán)境下的網(wǎng)絡(luò )管理解決方案的驅動(dòng)下，而很快成為了事實(shí)上的標準。
SNMP的管理結構如圖1所示。它的核心思想是在每個(gè)網(wǎng)絡(luò )節點(diǎn)上存放一個(gè)管理信息庫MIB（Management Information Base），由節點(diǎn)上60代理（agent）負責維護，管理者通過(guò)應用層協(xié)議對這些代理進(jìn)行輪詢(xún)進(jìn)而對管理信息庫進(jìn)行管理。SNMP最大的特點(diǎn)就是其簡(jiǎn)單性。它的設計原則是盡量減少網(wǎng)絡(luò )管理所帶來(lái)的對系統資源的需求，盡量減少agent的復雜性。它的整個(gè)管理策略和體系結構的設計都體現了這一原則。
SNMP的主要優(yōu)點(diǎn)是：
·易于實(shí)施；
·成熟的標準；
· C／S模式對資源要求較低；
·廣泛適用，代價(jià)低廉。
簡(jiǎn)單性是SNMP標準取得成功的主要原因。因為在大型的、多廠(chǎng)商產(chǎn)品構成的復雜網(wǎng)絡(luò )中，管理協(xié)議的明晰是至關(guān)重要的；但同時(shí)這又是SNMP的缺陷所在——為了使協(xié)議簡(jiǎn)單易行，SNMP簡(jiǎn)化了不少功能，如：
·沒(méi)有提供成批存取機制，對大塊數據進(jìn)行存取效率很低；
·沒(méi)有提供足夠的安全機制，安全性很差；
·只在TCP／IP協(xié)議上運行，不支持別的網(wǎng)絡(luò )協(xié)議；
·沒(méi)有提供管理者與管理者之間通信的機制，只適合集中式管理，而不利于進(jìn)行分布式管理；
·只適于監測網(wǎng)絡(luò )設備，不適于監測網(wǎng)絡(luò )本身。
針對這些問(wèn)題，對它的改進(jìn)工作一直在進(jìn)行。如1991年11月，推出了RMON（Rernote Network Monitor）MIB，加強SNMP對網(wǎng)絡(luò )本身的管理能力。它使得SNMP不僅可管理網(wǎng)絡(luò )設備，還能監測局域網(wǎng)和互聯(lián)網(wǎng)上的數據流量等信息，1992年7月，針對SNMP缺乏安全性的弱點(diǎn)，又公布了S-SNMP（Secure SNMP）草案。到1993年初，又推出了SNMP Version 2即SNMPv2（推出了SNMPv2以后，SNMP就被稱(chēng)為SNMPv1）。SNM-Pv2包容了以前對SNMP的各項改進(jìn)工作，并在保持了SNMP清晰性和易于實(shí)現的特點(diǎn)以外，吸取了CMIP的部分優(yōu)點(diǎn)，功能更強，安全性更好，具體表現為：
·提供了驗證機制，加密機制，時(shí)間同步機制等，安全性大大提高；
·提供了一次取回大量數據的能力，效率大大提高；
·增加了管理者和管理者之間的信息交換機制，從而支持分布式管理結構，由位于中間層次（intermediate）的管理者來(lái)分擔主管理者的任務(wù)，增加了遠地站點(diǎn)的局部自主性。
·可在多種網(wǎng)絡(luò )協(xié)議上運行，如OSI、AppleTalk和IPX等，適用多協(xié)議網(wǎng)絡(luò )環(huán)境（但它的缺省網(wǎng)絡(luò )協(xié)議仍是UDP）。
·擴展了管理信息結構的很多方面。特別是對象類(lèi)型的定義引入了幾種新的類(lèi)型。另外還規范了一種新的約定用來(lái)創(chuàng )建和刪除管理表（management tables）中的“行”（rows）。
·定義了兩種新的協(xié)議數據單元PDU（Protocol Data Unit）。Get-Bulk-Request協(xié)議數據單元允許檢索大數據塊（large data blocks），不必象SNMP那樣逐項（item by item）檢索； Inform-Request協(xié)議數據單元允許在管理者之間交換陷阱（tran）信息。
CMIP協(xié)議是在OSI制訂的網(wǎng)絡(luò )管理框架中提出的網(wǎng)絡(luò )管理協(xié)議。CMIP與SNMP一樣，也是由管理者、代理、管理協(xié)議與管理信息庫組成。
CMIP是基于面向對象的管理模型的。這個(gè)管理模型表示了封裝的資源并標準化了它們所提供的接口。如圖2所示了四個(gè)主要的元素：
·系統管理應用進(jìn)程是在擔負管理功能的設備（服務(wù)器或路由器等〕中運行的軟件：
·管理信息庫MIB是一組從各個(gè)接點(diǎn)收集來(lái)的與網(wǎng)絡(luò )管理有關(guān)的數據；
·系統管理應用實(shí)體（system management application entities）負責網(wǎng)絡(luò )管理工作站間的管理信息的交換，以及與網(wǎng)絡(luò )中其它接點(diǎn)之間的信息交換；
·層管理實(shí)體（layer management entities）表示在OSI體系結構設計中必要的邏輯。
CMIP模型也是基于C／S結構的�？蛻�(hù)端是管理系統，也稱(chēng)管理者，發(fā)起操作并接收通知；服務(wù)器是被管系統，也稱(chēng)代理，接收管理指令，執行命令并上報事件通知。一個(gè)CMIP操作臺（console）可以和一個(gè)設備建立一個(gè)會(huì )話(huà)，并用一個(gè)命令就可以下載許多不同的信息。例如，可以得到一個(gè)設備在一段特定時(shí)間內所有差錯統計信息。
CMIP采用基于事件而不是基于輪詢(xún)的方法來(lái)獲得網(wǎng)絡(luò )組件的相關(guān)數據。
CMIP已經(jīng)得到主要廠(chǎng)商，包括IBM、HP及AT&T的支持。用戶(hù)和廠(chǎng)商已經(jīng)認識到CMIP在企業(yè)級網(wǎng)絡(luò )管理領(lǐng)域是一個(gè)比較好的選擇。它能夠滿(mǎn)足企業(yè)級網(wǎng)管對橫跨多個(gè)管理域的對等相互作用（peer to peer interactions）的要求。CMIP特別適合對要求提供集中式管理的樹(shù)狀系統，尤其是對電信網(wǎng)（telecommunications network）的管理。這就是下面提到的電信管理網(wǎng)。
二、電信管理網(wǎng)TMN
電信管理網(wǎng)TMN是國際電聯(lián)ITU-T借鑒0SI中有關(guān)系統管理的思想及技術(shù)，為管理電信業(yè)務(wù)而定義的結構化網(wǎng)絡(luò )體系結構，TMN基于OSI系統管理（ITU-U X.700／ISO 7498-4）的概念，并在電信領(lǐng)域的應用中有所發(fā)展.它使得網(wǎng)絡(luò )管理系統與電信網(wǎng)在標準的體系結構下，按照標準的接口和標準的信息格式交換管理信息，從而實(shí)現網(wǎng)絡(luò )管理功能。TMN的基本原理之一就是使管理功能與電信功能分離。網(wǎng)絡(luò )管理者可以從有限的幾個(gè)管理節點(diǎn)管理電信網(wǎng)絡(luò )中分布的電信設備。
國際電信聯(lián)盟（ITU）在M.3010建議中指出，電信管理網(wǎng)的基本概念是提供一個(gè)有組織的網(wǎng)絡(luò )結構，以取得各種類(lèi)型的操作系統（OSs）之間、操作系統與電信設備之間的互連。它采用商定的具有標準協(xié)議和信息的接口進(jìn)行管理信息交換的體系結構。提出TMN體系結構的目的是支撐電信網(wǎng)和電信業(yè)務(wù)的規劃、配置、安裝、操作及組織。
電信管理網(wǎng)TMN的目的是提供一組標準接口，使得對網(wǎng)絡(luò )的操作、管理和維護及對網(wǎng)絡(luò )單元的管理變得容易實(shí)現，所以，TMN的提出很大程度上是為了滿(mǎn)足網(wǎng)管各部分之間的互連性的要求。集中式的管理和分布式的處理是TMN的突出特點(diǎn)。
ITU-T從三個(gè)方面定義了TMN的體系結構（Architecture），即功能體系結構（Functional Architecture），信息體系結構（Information Architecture）和物理體系結構（Physical Architecture）。它們分別體現在管理功能塊的劃分、信息交互的方式和網(wǎng)管的物理實(shí)現。我們按TMN的標準從這三個(gè)方面出發(fā)，對TMN系統的結構進(jìn)行設計。
功能體系結構是從邏輯上描述TMN內部的功能分布。引入了一組標準的功能塊（Functional block）和可能發(fā)生信息交換的參考點(diǎn)（reference points）。整個(gè)TMN系統即是各種功能塊的組合。
信息體系結構包括兩個(gè)方面：管理信息模型和管理信息交換。管理信息模型是對網(wǎng)絡(luò )資源及其所支持的管理活動(dòng)的抽象表示，網(wǎng)絡(luò )管理功能即是在信息模型的基礎上實(shí)現的。管理信息交換主要涉及到TMN的數據通信功能和消息傳遞功能，即各物理實(shí)體和功能實(shí)體之間的通信。
物理體系結構是為實(shí)現TMN的功能所需的各種物理實(shí)體的組織結構。TMN功能的實(shí)現依賴(lài)于具體的物理體系結構，從功能體系結構到物理體系結構存在著(zhù)映射關(guān)系。物理體系結構隨具體情況的不同而千差萬(wàn)別。在物理體系結構和功能體系結構之間有一定的映射關(guān)系。物理體系結構中的一個(gè)物理塊實(shí)現了功能體系結構中的一個(gè)或多個(gè)功能塊，一個(gè)接口實(shí)現了功能體系結構中的一組參考點(diǎn)。
仿照OSI網(wǎng)絡(luò )分層模型，ITU-T進(jìn)一步在TMN中引入了邏輯分層。如圖3所示：
TMN的邏輯分層是將管理功能針對不同的管理對象映射到事務(wù)管理層BML（Business Management Layer），業(yè)務(wù)管理層SML（Service Management Layer），網(wǎng)絡(luò )管理層NML（Network Management Layer）和網(wǎng)元管理層EML（Element Management Layer）。再加上物理存在的網(wǎng)元層NEL（Network Element Layer），就構成了TMN的邏輯分層體系結構。從圖2-6可以看到，TMN定義的五大管理功能在每一層上都存在，但各層的側重點(diǎn)不同。這與各層定義的管理范圍和對象有關(guān)。
三、TMN開(kāi)發(fā)平臺和開(kāi)發(fā)工具
1．利用TMN的開(kāi)發(fā)工具開(kāi)發(fā)TMN的必要性
TMN的信息體系結構應用OSI系統管理的原則，引入了管理者和代理的概念，強調在面向事物處理的信息交換中采用面向對象的技術(shù)。如前所述，TMN是高度強調標準化的網(wǎng)絡(luò )，故基于TMN標準的產(chǎn)品開(kāi)發(fā)，其標準規范要求嚴格復雜，使得TMN的實(shí)施成為一項具有難度和挑戰性的工作；再加上OSI系統管理專(zhuān)業(yè)人員的相對缺乏，因此，工具的引入有助于簡(jiǎn)化TMN的開(kāi)發(fā)，提高開(kāi)發(fā)效率。目前比較流行的基于TMN標準的開(kāi)發(fā)平臺有HPOV DM、SUN SEM、IBM TMN平臺和DSET的DSG及其系列工具。這些平臺可以用于開(kāi)發(fā)全方位的TMN管理者和代理應用，大大降低TMN／Q3應用系統的編程復雜性，并且使之符合開(kāi)放系統互連（OSI）網(wǎng)絡(luò )管理標準，這些標準包括高級信息模型定義語(yǔ)言GDM0，OSI標準信息傳輸協(xié)議CMIP，以及抽象數據類(lèi)型定義語(yǔ)言ASN.1。其中DSET的DSG及工具系列除了具備以上功能外，還具有獨立于硬件平臺的優(yōu)點(diǎn)。下面將比較詳細論述DSET的TMN開(kāi)發(fā)工具及其在TMN開(kāi)發(fā)中的作用。
2．DSET的TMN開(kāi)發(fā)工具的基本組成
DSET的TMN開(kāi)發(fā)工具從功能上來(lái)講可以構成一個(gè)平臺和兩大工具箱。一個(gè)平臺：分布式系統生成器DSG（Distributed System Generator）；兩個(gè)工具箱：管理者工具箱和代理工具箱。
分布式系統生成器DSG
DSG是用于頂層TCP／IP、OSI和其它協(xié)議上構筑分布式并發(fā)系統的高級對象請求代理0RB。 DSG將復雜的通信基礎設施和面向對象技術(shù)相結合，提供構筑分布式計算的軟件平臺。通信基礎設施支持分布式計算中通信域的通信要求。如圖4所示，它提供了四種主要的服務(wù)：透明遠程操作、遠程過(guò)程調用和消息傳遞、抽象數據服務(wù)及命名服務(wù)。借助于并發(fā)的面向對象框架，一個(gè)復雜的應用可以分解成一組相互通信的并發(fā)對象worker，除了支持例如類(lèi)和多重繼承等重要的傳統面向對象特征外，為了構筑新的worker類(lèi)，DSG也支持分布式對象。在一個(gè)開(kāi)放系統中，一個(gè)worker可以和其它worker進(jìn)行通信，而不必去關(guān)心它們所處的物理位置。
DSG提供給用戶(hù)用以開(kāi)發(fā)應用的構造塊（building block）稱(chēng)為worker。一個(gè)worker可以有自己的控制線(xiàn)程，也可以和別的線(xiàn)程共享一個(gè)控制線(xiàn)程，每個(gè)Worker都有自己的服務(wù)訪(fǎng)問(wèn)點(diǎn)SAP（Service Access Point），通過(guò)SAP與其它worker通信。Worker是事件驅動(dòng)的。在Worker內部，由有限狀態(tài)機FSM（Finite State Machine〕定義各種動(dòng)作及處理例程，DSG接受外部事件并分發(fā)到相應的動(dòng)作處理例程進(jìn)行處理。如圖5所示，獨占線(xiàn)程的此worker有三個(gè)狀態(tài)，兩個(gè)SAPs，并且每個(gè)SAP的'消息隊列中都有兩個(gè)事件。DSG環(huán)境通過(guò)將這些事件送到相應的事件處理程序中來(lái)驅動(dòng)worker的有限狀態(tài)機。
Worker是分布式的并發(fā)對象，DSG用它來(lái)支持面向對象的特點(diǎn)，如：類(lèi)，繼承等等。Worker由worker class定義。Worker可以根據需要由應用程序動(dòng)態(tài)創(chuàng )建。在一個(gè)UNIX進(jìn)程中可以創(chuàng )建的Worker個(gè)數僅受內存的限制。
管理者工具箱由ASN.C／C＋＋編譯器、CMIP／ROSE協(xié)議和管理者代碼生成器MCG構成，如圖6所示。
其中的CMIP／ROSE協(xié)議提供全套符合Q3接口選用的OSI七層協(xié)議棧實(shí)施。由于TMN在典型的電信環(huán)境中以面向對象的信息模型控制和管理物理資源，所有被管理的資源均被抽象為被管對象（M0），被管理系統中的代理幫助管理者通過(guò)MO訪(fǎng)問(wèn)被管理資源，又根據ITU-T M.3010建議：管理者與代理之間通過(guò)Q3接口通信。為此管理者必須產(chǎn)生與代理通信的CMIP請求。管理者代碼生成器讀取信息模型（GDMO文件和ASN.1文件），創(chuàng )立代碼模板來(lái)為每個(gè)被定義的MO類(lèi)產(chǎn)生CMIP請求和CMIP響應。由于所有CMIP數據均由ASN.1符號定義，而上層管理應用可能采用C／C++，故管理者應用需要包含ASN.1數據處理代碼，管理者工具箱中的ASN C／ C++編譯器提供ASN.1數據到C／C++語(yǔ)言的映射，并采用“預處理技術(shù)“生成ASN.1數據的低級代碼，可見(jiàn)利用DSET工具用戶(hù)只需編寫(xiě)網(wǎng)管系統的信息模型和相關(guān)的抽象數據類(lèi)型定義文件，然后利用DSET的ASN C／C++編譯器，管理者代碼生成器即可生成管理者部分代碼框架。
代理工具箱包括可硯化代理生成器VAB、CMIP翻譯器、ASN.C／C++ Toolkit，其結構見(jiàn)圖7。用來(lái)開(kāi)發(fā)符合管理目標定義指南GDMO和通用管理信息協(xié)議CMIP規定的代理應用.使用DSET獨具特色的代理工具箱的最大的好處就是更快、更容易地進(jìn)行代理應用的開(kāi)發(fā)。DSET在代理應用的開(kāi)發(fā)上為用戶(hù)做了大量的工作。
一個(gè)典型的GDMO／CM1P代理應用包括三個(gè)代碼模塊：
·代理、MIT、MIB的實(shí)施
·被管理資源的接口代碼
·后端被管理資源代碼
第一個(gè)模塊用于處理代理與MO實(shí)施。代理工具箱通過(guò)對過(guò)濾、特性處理、MO實(shí)例的通用支持，自動(dòng)構作這一個(gè)模塊。DSET的這一部分做得相當完善，用戶(hù)只需作少量工作即可完成本模塊的創(chuàng )建。對于mcreate、m-、m-get、m-cancel-get、m-set、m-set-confirmed、m-action、m-action-confirmed這些CMIP請求，第一個(gè)模塊中包含有缺省的處理代碼框架。這些缺省代碼都假定管理者的CMIP請求只與MO打交道。為了適應不同用戶(hù)的需求，DSET代理工具箱又提供在缺省處理前后調用用戶(hù)程序的接入點(diǎn)（稱(chēng)為User hooks）。當某CMIP請求需與實(shí)際被管資源或數據庫打交道時(shí)，用戶(hù)可在相應的PRE-或POST-函數中加入自己的處理代碼。例如，當你需要在二層管理應用中發(fā)CMIP請求，需望獲取實(shí)際被管資源的某屬性，而該屬性又不在相應MO中時(shí)你只需在GDMO預定義模板中為此屬性定義一PRE-GET函數，并在你自己的定制文件中為此函數編寫(xiě)從實(shí)際被管設備取到該屬性值的代碼即可。DSET的Agent代碼在執行每個(gè)CMIP請求前都要先檢查用戶(hù)是否在GDMO預定義文件中為此清求定義了PRE-函數，若是，則光執行PRE-函數，并根據返回值決定是否執行缺省處理（PRE-函數返回D-OK則需執行缺省處理，否則Agent向管理者返回正確或錯誤響應）。同樣當Agent執行完缺省處理函數時(shí)，也會(huì )檢查用戶(hù)是否為該請求定義了POST-函數，若是則繼續執行POST-函數。至于A(yíng)gent與MO之間具體是如何實(shí)現通信的，用戶(hù)不必關(guān)心，因為DSET已為我們實(shí)現了。用戶(hù)只需關(guān)心需要與設備交互的那一部分CMIP請求，為其定制PRE-／POST函數即可。
第二個(gè)模塊實(shí)現MO與實(shí)際被管資源的通信。它的實(shí)現依賴(lài)于分布式系統生成器DSG所提供“網(wǎng)關(guān)處理單元”（gateway）、遠程過(guò)程調用（RPC）與消息傳遞機制及MSL語(yǔ)言編譯器。通信雙方的接口定義由用戶(hù)在簡(jiǎn)化的ROSE應用中定義，在DSG中也叫環(huán)境，該環(huán)境定義了雙方的所有操作和相關(guān)參數。DSG的CTX編譯器編譯CTX格式的接口定義并生成接口表。DSG的MSL語(yǔ)言編譯器用以編譯分布式對象類(lèi)的定義并生成事件調度表。采用DSG的網(wǎng)關(guān)作為MO與實(shí)際被管資源間的通信橋梁，網(wǎng)關(guān)與MO之間通過(guò)定義接口定義文件及各自的MSL文件即可實(shí)現通信，網(wǎng)關(guān)與被管設備之間采用設備所支持的通信協(xié)議來(lái)進(jìn)行通信，例如采用TCP／IP協(xié)議及Socket機制實(shí)現通信。
第三個(gè)模塊對被管理資源進(jìn)行實(shí)際處理。這一模塊根據第二個(gè)模塊中定義的網(wǎng)關(guān)與被管設備間的通信機制來(lái)實(shí)現，與工具沒(méi)有多大聯(lián)系。
四、TMN開(kāi)發(fā)的關(guān)鍵技術(shù)
電信管理網(wǎng)技術(shù)蘊含了當今電信、計算機、網(wǎng)絡(luò )通信和軟件開(kāi)發(fā)的最新技術(shù)，如OSI開(kāi)放系統互連技術(shù)、OSI系統管理技術(shù)、計算機網(wǎng)絡(luò )技術(shù)及分布式處理、面向對象的軟件工程方法以及高速數據通信技術(shù)等。電信管理網(wǎng)應用系統的開(kāi)發(fā)具有巨大的挑戰性。
工具的引入很大程度上減輕了TMN的開(kāi)發(fā)難度。留給開(kāi)發(fā)人員的最艱巨工作就是接口（interface）的信息建模。尤其是Q3接日的信息建模問(wèn)題。
Q3接口是TMN接口的“旗艦”，Q3接口包括通信模型和信息模型兩個(gè)部分，通信模型（0SI系統管理）的規范制定的十分完善，并且工具在這方面所作的工作較多，因此，當我們設計和開(kāi)發(fā)各種不同管理業(yè)務(wù)的TMN系統時(shí)，主要是采用一定的方法學(xué)，遵循一定的指導原則，針對不同電信領(lǐng)域的信息建模問(wèn)題。
為什么說(shuō)建模是TMN開(kāi)發(fā)中的關(guān)鍵技術(shù)呢？從管理的角度而言，在那些先有國際標準（或事實(shí)上的標準），后有設備的情況下，是有可能存在一致性的信息模型的，例如目前SDH和七號信令網(wǎng)的TMN系統存在這樣的信息模型標準。但即使這樣，在這些TMN系統的實(shí)施過(guò)程，有可能由于管理需求的不同而對這些模型進(jìn)行進(jìn)一步的細化。在那些先有設備而后才有國際標準（或事實(shí)上的標準）的設備，而且有的電信設備就無(wú)標準而言，由于不同廠(chǎng)家的設備千差萬(wàn)別，這種一致性的信息模型的制定是非常困難的。
例如，近年來(lái)標準化組織國際電信聯(lián)盟（ITU-T）、歐洲電信標準組織（ETSI）、網(wǎng)絡(luò )管理論壇（NMF）和ATM論壇等相繼頒布了一些Q3信息模型。但至今沒(méi)有一個(gè)完整的穩定的交換機網(wǎng)元層的Q3信息模型。交換機的Q3信息模型提供了交換機網(wǎng)元的一個(gè)抽象的、一般的視圖，它應當包含交換機的管理的各個(gè)方面。但這是不可能的。因為隨著(zhù)電信技術(shù)的不斷發(fā)展，交換機技術(shù)也在不斷的發(fā)展，交換機的類(lèi)型不斷增加，電信業(yè)務(wù)不斷的引入。我們很難設計一個(gè)能夠兼容未來(lái)交換機的信息模型。如今的交換機已不再是僅僅提供電話(huà)的窄帶業(yè)務(wù)，而且也提供象ISDN這樣的寬帶業(yè)務(wù)。交換機趨向寬帶窄帶一體化發(fā)展，因此交換機的Q3信息模型是很復雜的，交換機Q3信息建模任務(wù)是很艱巨的。
五、TMN管理者和代理的開(kāi)發(fā)
下面結合我們的開(kāi)發(fā)工作，探討一下TMN管理者和代理的開(kāi)發(fā)。
1．管理者的開(kāi)發(fā)
基于OSI管理框架的管理者的實(shí)施通常被認為是很困難的事，通常，管理者可以劃分為三個(gè)部分。第一部分是位于人機之間的圖形用戶(hù)接口GUI（Graphical User Interfaces），接收操作人員的命令和輸入并按照一種統一的格式傳送到第二部分——管理功能。管理功能提供管理功能服務(wù)，例如故障管理，性能管理、配置管理、記費管理，安全管理及其它特定的管理功能。接收到來(lái)GUI的操作命令，管理功能必須調用第三部分——CMSI API來(lái)發(fā)送CMIP請求到代理。CMIS API為管理者提供公共管理信息服務(wù)支持。
大多數的網(wǎng)管應用是基于UNIX平臺的，如Solaris，AIX and HP-UX。若GUI是用X-Window來(lái)開(kāi)發(fā)的，那么GUI和管理功能之間的接口就不存在了，從實(shí)際編程的的角度看，GUI和管理功能都在同一個(gè)進(jìn)程中。
上面的管理者實(shí)施方案盡管有許多優(yōu)點(diǎn)，但也存在著(zhù)不足。首先是費用昂貴。所有的管理工作站都必須是X終端，服務(wù)器必須是小型機或大型機。這種方案比采用PC機作客戶(hù)端加上UNIX服務(wù)器的方案要昂貴得多。其次，擴展性不是很好，不同的管理系統的范圍是不同的，用戶(hù)的要求也是不一樣的，不是所有的用戶(hù)都希望在X終端上來(lái)行使管理職責。因此，PC機和調終端都應該向用戶(hù)提供。最后由于X-Window的開(kāi)發(fā)工具比在PC機上的開(kāi)發(fā)工具要少得多。因此最終在我們的開(kāi)發(fā)中，選擇了PC機作為管理工作站，SUN Ultral作為服務(wù)器。
在實(shí)際工作中我們將管理者劃分為兩個(gè)部分——管理應用（management application）和管理者網(wǎng)關(guān)（manager gateway）。如圖8所示。
管理應用向用戶(hù)提供圖形用戶(hù)接口GUI并接受用戶(hù)的命令和輸入，按照定義好的消息格式送往管理者網(wǎng)關(guān)，由其封裝成CMIP請求，調用CMIS API發(fā)往代理。同時(shí)，管理者網(wǎng)關(guān)還要接收來(lái)自代理的響應消息和事件報告并按照一定的消息格式送往管理應用模塊。
但是這種方案也有缺點(diǎn)。由于管理應用和管理者網(wǎng)關(guān)的分離，前者位于PC機上，后者位于Ultral工作站上。它們之間的相互作用須通過(guò)網(wǎng)絡(luò )通信來(lái)完成。它們之間的接口不再是一個(gè)參考點(diǎn)（Reference Point），而是一個(gè)物理上的接口，在電信管理網(wǎng)TMN中稱(chēng)為F接口。迄今為止ITU-T一直沒(méi)能制定出有關(guān)F接口的標準，這一部分工作留給了TMN的開(kāi)發(fā)者。鑒于此，我們制定了管理應用和管理者網(wǎng)關(guān)之間通信的協(xié)議。
在開(kāi)發(fā)中，我們選擇了PC機作為管理工作站，SUN Ultral作為我們的管理者網(wǎng)關(guān)。所有的管理應用都在PC機上。開(kāi)發(fā)人員可以根據各自的喜好來(lái)選擇不同開(kāi)發(fā)工具，如Java，VC++，VB，PB等。管理者網(wǎng)關(guān)執行部分的管理功能并調用CMIS API來(lái)發(fā)送CMIP請求，接收來(lái)自代理的響應消息和事件報告并送往相應的管理應用。
管理者網(wǎng)關(guān)的數據結構是通過(guò)編譯信息模型（GDMO文件和ASN.1文件）獲得的。它基于DSG環(huán)境的。管理者網(wǎng)關(guān)必須完成下列轉換：
數據類(lèi)型轉換：GUI中的數據類(lèi)型與ASN.1描述的數據類(lèi)型之間的相互轉換；
消息格式轉換：GUI和管理者網(wǎng)關(guān)之間的消息格式與CMIP格式之間的相互轉換；
協(xié)議轉換：TCP／IP協(xié)議與OSI協(xié)議之間的相互轉換。
這意味著(zhù)管理者網(wǎng)關(guān)接收來(lái)自管理應用的消息。將其轉換為ASN.1的數據格式，并構造出CMIS的參數，調用CMIS API發(fā)送CMIP請求。反過(guò)來(lái)，管理者收到來(lái)自代理的消息，解讀CMIS參數，構造消息格式，然后送往GUI。GUI和管理者網(wǎng)關(guān)之間的消息格式是由我們自己定義的。由于管理應用的復雜性，消息格式的制定參考了CMIS的參數定義和ASN.1的數據類(lèi)型。
管理者網(wǎng)關(guān)是采用多線(xiàn)程（multi-thread）編程來(lái)實(shí)現的。
2．代理的開(kāi)發(fā)
代理的結構如圖9所示。
為了使代理部分的設計和實(shí)現模塊化、系統化和簡(jiǎn)單化，將agent分成兩大模塊——通用代理模塊和MO模塊——進(jìn)行設計和實(shí)現。如圖所示，通用agent向下只與MO部分直接通信，而不能與被管資源MR直接進(jìn)行通信及操作，即通用agent將manager發(fā)來(lái)的CMIP請求解析后投遞給相應的M0，并從MO接收相應的應答信息及其它的事件報告消息。
代理的作用是代表管理者管理MO。利用工具的支持，采用面向對象的技術(shù)，分為八個(gè)步驟進(jìn)行agent的設計和實(shí)現，這八個(gè)步驟是：
第一步：對信息模型既GDMO文件和ASN.1文件的理解，信息模型是TMN系統開(kāi)發(fā)的基礎和關(guān)鍵。特別是對信息模型中對象類(lèi)和其中各種屬性清晰的認識和理解，對于實(shí)際的TMN系統來(lái)說(shuō)，其信息模型可能很復雜，其中對象類(lèi)在數量上可能很多。也就是說(shuō)，在設計和實(shí)現agent之前，必須作到對MO心中有數。
第二步：被管對象MO的定制。這一部分是agent設計和實(shí)現中的關(guān)鍵部分，工具對這方面的支持也不是很多，特別是涉及到MO與MR之間的通信，更為復雜，故將MO專(zhuān)門(mén)作為一個(gè)模塊進(jìn)行設計和實(shí)現MO和MR之間的通信以及數據和消息格式的轉換問(wèn)題，利用網(wǎng)關(guān)原理設計一個(gè)網(wǎng)關(guān)來(lái)解決。
第三步：創(chuàng )建內置的M0。所謂內置MO就是指在系統運行時(shí)，已經(jīng)存在的物理實(shí)體的抽象。為了保證能對這些物理實(shí)體進(jìn)行管理，必須將這些被管對象的各種固有的屬性值和操作預先加以定義。
第四步：創(chuàng )建外部服務(wù)訪(fǎng)問(wèn)點(diǎn)SAP。如前所述，TMN系統中各個(gè)基于分布式處理的worker之間通過(guò)SAP進(jìn)行通信，所以要為agent與管理者manager之間、agent與網(wǎng)關(guān)之間創(chuàng )建SAP。
第五步：SAP同內置MO的捆綁注冊。由于在TMN系統中，agent的所有操作是針對MO的，即所有的CMIP請求經(jīng)解析后必須送到相應的M0，而基于DSG平臺的worker之間的通信是通過(guò)SAP來(lái)實(shí)現的。因而，在系統處理過(guò)程中，當進(jìn)行信息的傳輸時(shí)，必須知道相應MO的SAP，所以，在agent的設計過(guò)程中，必須為內置MO注冊某一個(gè)SAP。
第六步：agent配置。對agent中有些參數必須加以配置和說(shuō)明。如隊列長(cháng)度、流量控制門(mén)限值、agent處理單元組中worker的最大／最小數目。報告的處理方式、同步通信方式中超時(shí)門(mén)限等。
第七步：agent用戶(hù)函數的編寫(xiě)，如agent worker初始化函數、子代理函數等的編寫(xiě)。
第八步：將所有函數編譯，連接生成可運行的agent。
MO模塊是agent設計中的一個(gè)重要而又復雜的部分。這是由于，一方面工具對該部分的支持不是很多：另一方面，用戶(hù)的大部分處理函數位于這一部分；最主要的還在于它與被管資源要跨平臺，在不同的環(huán)境下進(jìn)行通信。MO模塊的設計思想是在MO和MR之間設計一個(gè)網(wǎng)關(guān)（gateway），來(lái)實(shí)現兩者之間的消息、數據、協(xié)議等轉換。
MO部分的主要功能是解析，執行來(lái)自管理者的CMIP請求，維持各MO的屬性值同被管資源的一致性，生成CMIP請求結果，并上報通用agent模塊，同時(shí)與MR通信，接收和處理來(lái)自MR的事件報告信息，并轉發(fā)給通用agent。
MO部分有大量的用戶(hù)定制工作。工具只能完成其中一半的工作，而另一半工作都需要用戶(hù)自己去定制。用戶(hù)定制分為兩大類(lèi)；
第一類(lèi)是PRE-／POST-函數。PRE-／POST-函數的主要功能是在agent正式處理CMIP請求之前／之后與被管資源打交道，傳送數據到MR或從MR獲取數據并做一些簡(jiǎn)單的處理。通過(guò)對這些PRE-／POST-函數的執行，可以確保代理能夠真實(shí)地反映出被管資源的運行狀態(tài)。PRE-／POST-函數分為兩個(gè)層次：MO級別和屬性級別。MO級別層次較高，所有對該對象類(lèi)的CMIP操作都會(huì )調用MO級別的PRE-／POST-函數。屬性級別層次低，只有對該屬性的CMIP操作才會(huì )調用這些函數。DSET工具只提供了PRE-／POST-函數的人口參數和返回值，具體的代碼需要完全由用戶(hù)自己編寫(xiě)。由于agent與被管資源有兩種不同的通信方式，不同的方式會(huì )導致不同的編程結構和運行效率，如果是同步方式，編程較為簡(jiǎn)單，但會(huì )阻塞被管資源，適合于由大量數據返回的情況。異步方式不會(huì )阻塞被管資源，但編程需要作特殊處理，根據不同的返回值做不同的處理，適合于數據不多的情況，在選擇通信方式時(shí)還要根據MO的實(shí)現方式來(lái)確定。比如，MO若采用Doer來(lái)實(shí)現，則只能用同步方式。
第二類(lèi)是動(dòng)作、事件報告和通知的處理，動(dòng)作的處理相對比較容易，只需考慮其通信方式采用同步還是異步方式。對事件報告和通知的處理比較復雜。首先，需要對事件進(jìn)行分類(lèi)，對不同類(lèi)別的事件采用不同的處理方法，由哪一個(gè)事件前向鑒別器EFD（Event Forwarding Discriminator）來(lái)處理等等。比如，告警事件的處理就可以單獨成為一類(lèi)。其次，對每一類(lèi)事件需要確定相應的EFD的條件是什么，哪些需要上報管理應用，哪些不需要。是否需要記入日志，這些日志記錄的維護策略等等。
除了這兩類(lèi)定制外，MO也存在著(zhù)優(yōu)化問(wèn)題。比如MO用worker還是Doer來(lái)實(shí)現，通信方式采用同步還是異步，面向連接還是無(wú)連接等等，都會(huì )影響整個(gè)代理的性能。
如果MO要永久存儲，我們采用文件方式。因為目前DSET的工具只支持Versant、ODI這兩種面向對象數據庫管理系統OODBMS，對于0racle，Sybase等數據庫的接口還需要用戶(hù)自己實(shí)現。MO定制的工作量完全由信息模型的規模和復雜程度決定，一個(gè)信息模型的對象類(lèi)越多，對象之間的關(guān)系越復雜（比如一個(gè)對象類(lèi)中的屬性改變會(huì )影響別的類(lèi)），會(huì )導致定制工作的工作量和復雜程度大大增加。
代理者agent在執行管理者發(fā)來(lái)的CMIP請求時(shí)必須保持與被管資源MR進(jìn)行通信，將manager傳送來(lái)的消息和數據轉發(fā)給MR，并要從MR獲取必要的數據來(lái)完成其操作，同時(shí)，它還要接收來(lái)自MR的事件報告，并將這些事件上報給manager。
由上述可知，代理與被管資源MR之間的通信接口實(shí)際上是指MO與MR之間的通信接口。大部分MO是對實(shí)際被管資源的模擬，這些MO要與被管資源通信。若讓這些MO直接與被管資源通信，則存在以下幾個(gè)方面的弊端：
·由于MO模塊本身不具備錯誤信息檢測功能（當然也可在此設計該項功能，但增加了MO模塊的復雜性），如果將上向發(fā)來(lái)的所有信息（包括某些不恰當的信息）全部轉發(fā)給MR，不僅無(wú)此必要，而且增加了數據通信量；同理MR上發(fā)的信息也無(wú)必要全部發(fā)送給MO。
·當被管資源向MO發(fā)消息時(shí)，由于MIT對于被管資源來(lái)說(shuō)是不可知的，被管資源不能確定其相應MO在MIT中所處的具體位置，從而也就無(wú)法將其信息直接送到相應的MO，因而只能采用廣播方式發(fā)送信息。這樣一來(lái)，每當有消息進(jìn)入MO模塊時(shí)，每個(gè)MO都要先接收它，然后對此消息加以判斷，看是否是發(fā)給自己的。這樣一方面使編程復雜化，使軟件系統繁雜化，不易控制，調試困難；另一方面也使通信開(kāi)銷(xiāo)增大。
·MO直接與被管資源通信，使得系統在安全性方面得不到保障，在性能方面也有所下降，為此，采用計算機網(wǎng)絡(luò )中中網(wǎng)關(guān)（gateway）的思想，在MO與被管資源建立一個(gè)網(wǎng)關(guān)，即用一個(gè)gateway worker作為MO與被管資源通信的媒介。網(wǎng)關(guān)在代理的進(jìn)程處理中起到聯(lián)系被管資源與MO之間的“橋梁”作用。
六、總結與展望
Q3接口信息建模是TMN開(kāi)發(fā)中的關(guān)鍵技術(shù)。目前，各標準化組織針對不同的管理業(yè)務(wù)制定和發(fā)布了許多信息模型。這些模型大部分是針對網(wǎng)元層和網(wǎng)絡(luò )層，業(yè)務(wù)層和事務(wù)層的模型幾乎沒(méi)有，還有相當的標準化工作正在繼續研究。業(yè)務(wù)層和事務(wù)層的模型是將來(lái)研究的重點(diǎn)。
除了Q3接口外，TMN的接口還包括X，F，Qx接口。它們的Q3接口相同也包括通信模型和信息模型兩個(gè)部分。各標準化組織幾乎沒(méi)有發(fā)布針對這些接口的規范。F接口和具體的一個(gè)TMN系統的實(shí)施密切相關(guān)，沒(méi)有必要對其的通信模型和信息模型進(jìn)行規范化。Qx是不完善的Q3接口，它是非標準的廠(chǎng)家專(zhuān)用的Q接口，雖然在管理系統的實(shí)施中，很多產(chǎn)品采用Qx接口作為Q3接口的過(guò)渡，但是隨著(zhù)標準化進(jìn)程的推進(jìn)，Qx接口將逐步被拋棄。電信工業(yè)的變化日新月異，寬帶網(wǎng)絡(luò )使得分布系統互連成為可能，使得不同的電信服務(wù)公司和運營(yíng)公司相互競爭、相互合作來(lái)向用戶(hù)提供服務(wù)。在這種環(huán)境下，整個(gè)電信網(wǎng)絡(luò )管理將涉及到不同的組織以及它們的管理系統�；赥MN的多域管理（TMN-Based Multi-Domain Management）將成為未來(lái)電信網(wǎng)管的重要研究方向。X接口位于兩個(gè)TMN系統之間，對它研究是基于TMN的多域管理系統的重點(diǎn)。
TMN有技術(shù)上的先進(jìn)、強調公認的標準和接口等優(yōu)點(diǎn)。但它也有目標太大、抽象化要求太高、信息模型的標準化進(jìn)程太慢、OSI滿(mǎn)協(xié)議棧的效率不高等問(wèn)題。TMN自身需要進(jìn)一步發(fā)展。在網(wǎng)絡(luò )管理技術(shù)方面，除了TMN一種體系結構以外，還有ITU & ISO的開(kāi)放分布處理（ODP），OSF的分布處理和管理環(huán)境（DCE／DME），NMF的OMNIPoint，OMG的公共對象請求代理體系結構（CORBA）以及TINA-C的電信信息網(wǎng)絡(luò )體系結構（TINA）。目前，CORBA技術(shù)越來(lái)越被電信、網(wǎng)絡(luò )部門(mén)接受和采用。CORBA體系結構是對象管理組織OMG為解決分布式處理環(huán)境中，硬件和軟件系統的互連而提出的一種解決方案。CORBA適用于業(yè)務(wù)層和事務(wù)層的管理應用。對于下幾層（網(wǎng)元層、網(wǎng)元管理層和網(wǎng)絡(luò )管理層）而言，還沒(méi)有比TMN更好的體系結構。TINA體系結構是基于分布式計算，面向對象以及電信和計算機業(yè)界的其它和標準，如ODP，IN，TMN和CORBA；它將電信業(yè)務(wù)和管理業(yè)務(wù)綜合到同一種體系結構中，是電信業(yè)務(wù)與電信網(wǎng)絡(luò )技術(shù)無(wú)關(guān)，從而使電信業(yè)務(wù)的開(kāi)放與管理不受多廠(chǎng)商設備的影響。雖然TINA處于發(fā)展中，還不很成熟，但它是未來(lái)電信體系結構的最終方向。
【網(wǎng)絡(luò )管理技術(shù)論文三篇】相關(guān)文章：
網(wǎng)絡(luò )技術(shù)維護服務(wù)合同11-27
網(wǎng)絡(luò )的議論文04-15
網(wǎng)絡(luò )利與弊議論文02-16
網(wǎng)絡(luò )管理自查報告01-11
網(wǎng)絡(luò )管理專(zhuān)業(yè)求職信04-22
計算機網(wǎng)絡(luò )安全維護及管理辦法論文01-18
數控技術(shù)論文致謝04-20
生態(tài)護坡技術(shù)分析論文04-08