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