基於網絡配置協議的事件通知發送方法、系統及設備的製作方法
2023-05-31 00:39:36
專利名稱：基於網絡配置協議的事件通知發送方法、系統及設備的製作方法
技術領域：
本發明涉及移動通信技術，特別涉及一種基於網絡配置協議的事件通知發送方法、系統及設備。
背景技術：
簡單網絡管理協議(SNMP)從1988年提出到現在，已經有近二十年的歷史。從最早的版本1(Versionl，簡稱V1)到現在的V3，從幾乎沒有安全機制到基於用戶的安全模型(USM)，可以說SNMP在不斷地發展以滿足當前的需求。SNMP從被提出到被廣泛採用，最主要的一個原因就是它實現簡單，但是SNMP也有缺陷。比如，沒有明確的過濾機制、對於大多數表沒有鎖定機制以及安全性難以保證等。
針對SNMP的諸多缺陷，現有技術中提出了網絡配置協議(NETCONF)。NETCONF基本上解決了SNMP的缺點，適合大型且複雜的設備管理。NETCONF是一種分層管理的配置協議，用於提供網絡設備的配置安裝、維護以及刪除等機制，使用可擴展標識語言(XML)封裝配置數據，其協議操作承載在簡單的遠程過程調用(RPC)層上。
圖1為現有NETCONF的分層結構示意圖。如圖1所示，現有NETCONF從概念上共分為四層，其中第一層為傳輸協議層(Transport Protocol)，常用的協議有區塊擴展交換協議(BEEP)、安全外殼(SSH)、安全套接層協議(SSL)以及控制臺程序(console)等；第二層為RPC層，包括RPC以及RPC響應；第三層為操作層，常用的操作包括獲取配置(Get-config)、編輯配置(Edit-config)以及事件通知(Notifcation)等；第四層為內容層，或稱配置管理層，用於實現對配置數據(Configuration Data)的管理。
NETCONF協議中，為及時獲知系統中發生的事件，這裡所提到的事件是指一些設備發生的，應該引起注意的事情，比如配置改變、故障、狀態改變、門限越界以及異常侵入等，系統需要提供事件通知。為此，NETCONF客戶端需要向NETCONF伺服器訂閱事件通知，如果訂閱成功，則NETCONF伺服器將在訂閱列表中記錄下該NETCONF客戶端的訂閱消息。這樣，當系統內部有事件產生時，NETCONF伺服器會根據記錄的訂閱消息，向NETCONF客戶端發送事件通知，以便告知NETCONF客戶端當前事件的發生情況。如果發生以下情況，如NETCONF會話終止、事件不在訂閱範圍之內或者事件訂閱變更，則NETCONF伺服器將不再向NETCONF客戶端發送事件通知。需要說明的是，NETCONF伺服器中用於事件通知的會話，始終不用處理RPC請求。
但是，上述事件通知僅僅是針對NETCONF的底部三層進行的定義，現有技術中還沒有一種針對NETCONF的完整的四層結構進行定義的事件通知方式。所以，希望藉助於現有的其它應用環境中的類似的事件通知方式，來實現NETCONF中的事件通知。
目前，應用比較廣泛的事件通知方式主要有簡單網絡管理協議告警(Snmpn印)以及系統日誌(syslog)。其中SnmpTrap又具體分為三個版本，Snmpv1Trap、SnmpV2Trap以及Snmpv3Trap。
網絡草案(RFC)1157中具體描述了如何通過Snmpv1Trap印發送告警消息給上層應用，並定義了snmpv1nap協議數據單元(PDU)的格式，如表1所示 表1Snmpv1Trappdu組成格式 其中，Version，用於標識該Snmpv1 Trappdu消息的版本； Community，用於上層應用對告警消息發送方進行身份驗證； Enterprise，即企業代碼，比如1011； Agent-addr，用於標識告警消息發送方的網際網路協議(IP)地址； Generic-trap，用於標識需要告警的六種通常情況，包括冷啟動(coldStart)、熱啟動(warmStart)、連接故障(linkDown)、連接建立(linkUp)、認證失敗(anthenticationFailure)以及相鄰的外部路由器失效或關機(egpNeighborLoss)，在實際應用中，可以用整數0～5分別代表上述六種情況； Specific-trap，用於標識需要告警的特殊情況，比如，用戶自定義的某種情況； Time-stamp，用於標識告警時間； Variable-binding[n]，用於標識具體告警內容，一條告警消息中可以包括多個variable-binding； Name，用於標識告警對象，如接口或中央處理單元(CPU)等； Value，用於標識事件內容，如接口down或者過載等。
RFC1905中描述了如何通過Snmpv2Trap發送告警消息給上層應用，並定義了Snmpv2 Trappdu的具體格式，如表2所示 表2 Snmpv2 Trappdu組成格式 表2中各部分的含義與表1中類似，不再贅述。
Snmpv3Trappdu的格式與Snmpv2Trappdu類似，區別僅在於在Snmpv2Trappdu格式的基礎上增加一個上下文名稱(Contextname)以及一個上下文標識(ContextID)。
通過上述SnmpTrap雖然可以實現告警，但是，現有SnmpTrap使用用戶數據報協議(UDP)進行承載，而UDP本身並不是可靠協議，所以，採用SnmpTrap進行告警可能會造成報文無法可靠到達的問題；而且，由於SnmpTrap使用二進位的PDU報文進行封裝，解析時需要使用專門的函數庫，所以影響其通用性；再有，SnmpTrap無法兼容其它的事件通知方式。
RFC3164中描述了如何通過syslog發送系統日誌給上層應用，並規定syslog的具體格式，如表3所示 表3syslog組成格式 如表3所示，完整的syslog消息由三部分組成，即PRI、HEADER以及MSG。
其中，Facility，用於標識該日誌的來源，在實際應用中，用不同的代碼(Numerical Code)來代表不同的日誌來源，如表4所示 表4 不同代碼與不同Facility的對應關係 Severity，用於標識消息的嚴重程度，在實際應用中，用不同的代碼來代表不同等級的嚴重程度，如表5所示 表5 不同代碼與不同Severity的對應關係 在確定了Facility以及Severity之後，即可計算該syslog消息的優先級，計算方式為「Facility*8+Severity＝PRI」，其中的8為取值固定的係數。
HEADER具體包括TIMES TAMP以及HOSTNAME。其中的TIMES TAMP用於標識日誌發生時間；HOSTNAME用於標識產生該日誌的系統。
MSG的內容需要根據實際情況具體確定，所以在syslog消息格式中不作具體限定。
舉例說明 Oct11 221415 mymachine su″su root″failed for lonvick on/dev/pts/8 Facility＝4(security/authorization messages(note 1))，Severity＝2(Criticalcritical conditions) 上面這個例子所表示的含義是設備通知日誌主機，某用戶進行超級用戶的權限認證，但是認證失敗；因為屬於安全認證的事件，所以Facility＝4；此事件很重要，但是還沒有影響設備的正常運行，所以Severity＝2。
與SnmpTrap類似，syslog雖然可以實現系統日誌報告，但由於使用UDP進行承載，而UDP本身並不是可靠協議，所以存在報文無法可靠到達的問題，而且，syslog也無法兼容其它事件通知方式；此外，syslog雖然使用文本方式封裝，但由於該文本方式是簡單字符串格式，不容易解析，所以影響了其通用性。
前面已經提到，由於現有技術中還沒有一種針對NETCONF的完整的四層結構進行定義的事件通知方式，所以，希望藉助於現有的其它應用環境中的類似的事件通知方式，來實現NETCONF中的事件通知。但是，由於SnmpTrap和syslog都有其各自的缺陷，加上採用的協議以及報文格式等與NETCONF的區別，現有SnmpTrap以及syslog並不能被簡單地應用到NETCONF中。
發明內容
本發明實施例提供一種基於網絡配置協議的事件通知發送方法，能夠兼容各種事件通知方式，以實現網絡配置協議中的事件通知。
本發明實施例同時提供一種基於網絡配置協議的事件通知發送系統，能夠兼容各種事件通知方式，以實現網絡配置協議中的事件通知。
本發明實施例還提供一種基於網絡配置協議的事件通知發送設備，能夠兼容各種事件通知方式，以實現網絡配置協議中的事件通知。
本發明實施例的技術方案是這樣實現的 一種基於網絡配置協議NETCONF的事件通知發送方法，包括 NETCONF客戶端在NETCONF伺服器中訂閱事件通知； 當系統中有事件發生時，所述NETCONF伺服器生成事件通知，並將所述事件通知轉換為所述NETCONF客戶端能夠識別的格式，發送至所述NETCONF客戶端。
一種基於NETCONF的事件通知發送系統，該系統包括NETCONF客戶端和NETCONF伺服器； 所述NETCONF客戶端，用於在所述NETCONF伺服器中訂閱事件通知，並接收所述NETCONF伺服器發送的事件通知； 所述NETCONF伺服器，用於在系統中有事件發生時，生成事件通知，並將所述事件通知轉換為NETCONF客戶端能夠識別的格式後，發送至所述NETCONF客戶端。
一種基於NETCONF的事件通知發送設備，該設備為NETCONF伺服器，所述NETCONF伺服器包括會話處理模塊、通知管理模塊以及事件處理中心； 所述會話處理模塊，用於將接收自NETCONF客戶端的攜帶有訂閱事件通知類型的訂閱請求發送至所述通知管理模塊，並將接收自所述通知管理模塊的響應消息轉化為XML格式後發送至所述NETCONF客戶端；接收來自所述通知管理模塊的事件通知，將所述事件通知轉換為XML格式後發送至所述NETCONF客戶端； 所述通知管理模塊，用於將接收自所述會話處理模塊的訂閱請求加入預先保存的訂閱列表，同時向所述會話處理模塊回送訂閱成功與否的響應消息；接收來自所述事件處理中心的事件通知，根據所述訂閱列表過濾到訂閱所述類型事件通知的NETCONF客戶端，並將所述事件通知發送到所述會話處理模塊； 所述事件處理中心，用於在系統中有事件發生時，根據需要生成與所述事件對應的類型的事件通知，並將所述事件通知發送至所述通知管理模塊。
可見，採用本發明實施例的技術方案，當系統中有事件發生時，伺服器可以根據需要生成對應方式的事件通知，並將生成的事件通知轉換為客戶端要求的格式，進而發送給客戶端。這樣，對於整個系統來說，因為事件通知格式可以轉換，所以，對伺服器端生成的事件通知格式沒有嚴格限定，從而使得基於網絡配置協議的事件通知能夠兼容各種事件通知方式。
圖1為現有NETCONF的分層結構示意圖。
圖2為本發明方法實施例的總體流程圖。
圖3為本發明方法第一個較佳實施例的流程圖。
圖4為現有NETCONF協議事件通知模型示意圖。
圖5為本發明實施例SnmpTrap封裝為XML格式的模型示意圖。
圖6為本發明通過XSLT實現XML-Snmpv2trap和XML-Snmpv1trap之間的轉換的規則示意圖。
圖7為本發明方法第二個較佳實施例的流程圖。
圖8為本發明實施例syslog封裝為XML格式的模型示意圖。
圖9為本發明系統實施例的組成結構示意圖。
具體實施例方式 為使本發明的目的、技術方案及優點更加清楚明白，以下參照附圖並舉實施例，對本發明作進一步地詳細說明。
本發明的實施方式基於NETCONF協議，其中，NETCONF客戶端(以下簡稱客戶端)在NETCONF伺服器(以下簡稱伺服器)中訂閱事件通知；當系統中有事件發生時，伺服器生成事件通知，並將生成的事件通知轉換為客戶端能夠識別的格式，發送至客戶端。
圖2為本發明方法實施例的總體流程圖。如圖2所示，包括以下步驟 步驟201客戶端在伺服器中訂閱事件通知。
本步驟中，客戶端在伺服器中訂閱事件通知的方法為客戶端向伺服器發送攜帶有訂閱的事件通知類型的訂閱請求；訂閱成功後，伺服器將訂閱請求信息加入到預先設置的訂閱列表中，該訂閱列表用於存儲訂閱了事件通知的客戶端的相關信息，如上述訂閱的事件通知類型信息，當然，如果有其它的信息，也將相應地進行存儲；同時，伺服器生成訂閱成功與否的響應消息，並將該響應消息轉換為XML格式後發送給客戶端。
本步驟之前，進一步包括客戶端與伺服器之間建立基於傳輸控制協議(TCP)的會話，如SSH會話。
步驟202當系統中有事件發生時，伺服器生成事件通知，並將生成的事件通知轉換為客戶端能夠識別的格式，發送至客戶端。
當系統中有事件發生時，伺服器根據事件類型，生成對應類型的事件通知，並根據訂閱列表中存儲的訂閱的事件通知類型信息查找到訂閱該類型事件通知的客戶端，向其發送事件通知。
通常情況下，如果客戶端沒有特殊要求，伺服器會按照默認方式將該事件通知封裝為XML格式後，發送至客戶端。
如果客戶端希望接收其它格式的事件通知，那麼在步驟201中的訂閱請求中將進一步攜帶格式請求信息，相應地，本步驟中，伺服器將進一步將封裝為XML格式的事件通知轉化為客戶端所請求的格式。
上述事件通知可以是各種現有事件通知方式，如SnmpTrap或syslog。這種情況下，步驟201所述的訂閱請求中可以進一步攜帶有過濾類型以及所要求得到的過濾結果信息。其中，過濾類型包括子樹(SUBTREE)過濾以及XML路徑語言(Xpath)過濾，表示伺服器將採用何種過濾方式以獲取客戶端所要求的過濾結果；所要求得到的過濾結果信息根據客戶端訂閱的事件通知類型的不同而不同如果訂閱的事件通知類型為SnmpTrap，則所要求得到的過濾結果用於說明訂閱的具體SnmpTrap類型Snmpv1Trap、Snmpv2Trap或Snmpv3Trap；若訂閱的事件通知類型為syslog，則所要求得到的過濾結果用於說明訂閱的事件的優先級或優先級範圍。
相應地，步驟202中，伺服器將根據訂閱列表中存儲的過濾類型以及所要求得到的過濾結果信息過濾得到客戶端實際訂閱的事件通知。
下面通過較佳實施例對本發明方法作進一步地詳細說明 圖3為本發明方法第一個較佳實施例的流程圖。本實施例基於NETCONF協議，假設伺服器端生成的事件通知為SnmpTrap。本實施例中的伺服器包括會話處理模塊(Session handler)、通知管理模塊(NotificationManager)以及事件處理中心(Event Center)。
如圖3所示，A、B、C、E、F、G分別表示不同的處理線程，其中，A表示客戶端(Client)處理線程；B表示伺服器會話的消息接收處理線程；C表示伺服器會話的消息反饋處理線程；E表示伺服器訂閱處理線程；F表示伺服器會話Trap接收線程；G表示設備內部事件發生源。
如圖3所示，該實施例包括以下步驟 首先，Client與Session handler之間建立SSH會話，以用於Client與Session handler之間後續的信息交互。建立SSH會話的過程為現有技術，可參見相關協議，此處不再贅述。
步驟301Client向Session handler發送訂閱請求。
訂閱請求中攜帶有訂閱的事件通知類型、過濾類型以及所要求得到的過濾結果信息。假設本實施例中，Client訂閱的事件通知類型是流為「Snmptrapover netconf」的所有事件，過濾類型為子樹過濾，所要求得到的過濾結果為「Snmpv1trap」格式的事件。
現有技術中已經對NETCONF的事件通知訂閱請求的格式進行了明確定義，本步驟中發送的訂閱請求只是對現有技術的應用而已。舉例如下 snmpTrapPdu over netconf//訂閱流為「snmptrap over netconf」的所有事件//過濾類型為子樹過濾 過濾結果為「snmpvltrap」格式的事件 notification.profile 2001-12-24T12:23:45 步驟302Session handler將接收到的訂閱請求寫入到NotiflcationManager的待處理數據隊列中。
步驟303Notification Manager處理訂閱請求，並在訂閱成功後，將所述訂閱請求加入到預先設置的訂閱列表中。
步驟304Notification Manager向Session handler發送響應消息。
本步驟中，Notification Manager生成訂閱成功與否的響應消息，並寫入Session handler的待處理數據隊列中。
步驟305Session handler將該響應消息轉換為XML格式。
由於在步驟304中生成的響應消息可能為設備內部的語言格式，比如C，因此，本步驟中需要對響應消息的格式進行轉換。
步驟306Session handler向Client發送響應消息。
Session handler將生成的XML格式的訂閱成功與否的響應消息發送給Client。
步驟307Event Center向Notification Manager發送Snmptrap告警信息。
當系統中有事件發生時，Event Center根據該事件類型，生成相應類型的事件通知。比如，該事件為認證失敗，則生成Snmpv1trap告警信息。
假設本步驟中Event Center向Notification Manager發送的Snmptrap告警信息中同時包括Snmpv1trap和Snmpv2trap。
步驟308Notification Manager根據訂閱列表進行過濾。
Notification Manager根據訂閱列表中存儲的客戶端的訂閱事件通知類型信息找到訂閱Snmptrap類型事件通知的客戶端，並根據存儲的過濾類型以及所要求得到的過濾結果信息，通過子樹過濾，得到「Snmpv1trap」格式的事件通知。
也可以使用Xpath過濾方式，得到「Snmpv1trap」格式的事件通知。兩種過濾方式均為現有技術，不再詳細介紹。但是需要說明的是，本實施例中無論採用哪種過濾方式，都是以事件通知的一個完整PDU為基本單元進行過濾的，即不對信息內部進行過濾，以保證信息的完整性。
步驟309Notification Manager向Session handler發送過濾後的事件通知。
Notification Manager以響應消息的方式將該事件通知寫入到Sessionhandler的待處理數據隊列中。
步驟310Session handler將事件通知封裝為XML格式。
本發明實施例中將SnmpTrap格式的事件通知封裝為XML格式的方式為 依據現有NETCONF協議的事件通知模型，將SnmpTrap中攜帶的信息封裝到所述事件通知模型的標籤內容中，並且封裝後的內容也要符合現有NETCONF協議事件通知模型的層次結構。
圖4為現有NETCONF協議事件通知模型示意圖。如圖4所示，其中的「事件通知(notification)」和「數據(data)」分別表示該模型的標籤和子標籤；虛線方框表示標籤內容；data子標籤所屬標籤內容中的「任意(any)」表示該部分內容可按照需要任意添加信息；notification和data兩標籤之間的符號(包括data標籤後邊的符號)表示前後兩部分為序列化(sequence)結構。
由於現有技術中的SnmpTrap包括Snmpv1Trap、Snmpv2Trap以及Snmpv3Trap三種類型，而且已知Snmpv1Trap、Snmpv2Trap和Snmpv3Trap的各自構成。所以，本實施例中只需將SNMPTrap設置為標籤(相對於整個SNMPTrap而言稱為標籤，實際屬於data的子標籤)，將Snmpv1Trap、Snmpv2Trap以及Snmpv3Trap設置為SNMPTrap的子標籤；將Snmpv1Trap、Snmpv2Trap以及Snmpv3Trap中各自攜帶的信息按照表1或表2所示關係分別對應地設置為Snmpv1Trap、Snmpv2Trap以及Snmpv3Trap的第一級子標籤或第二、第三級子標籤即可。
圖5為本發明實施例SnmpTrap封裝為XML格式的模型示意圖。以Snmpv1Trap為例進行說明，如表1所示，PduData包括timestamp、agentaddr、eid、sid以及vbs，各部分為平行關係，所以，圖5所示的Snmpv1Trap的封裝方式中，將表1所示的timestamp、agentaddr、eid、sid以及vbs分別設置為Snmpv1Trap的同一級子標籤；而表1中所示的community，本實施例中會將其設置為一個屬性。Snmpv2Trap的封裝方式與Snmpv1Trap類似，即將表2所示的PduData中的內容如vb，分別設置為Snmpv2Trap的子標籤，將vb中進一步包括的內容，如oid和value分別設置為vb子標籤的下一級子標籤。而Snmpv3Trap的封裝方式則只是在Snmpv2Trap封裝方式的基礎上增加了contextname以及contextid。
需要說明的是，圖5所示Snmpv2Trap子標籤後進一步包括一個Snmpv2trapGroup子標籤，該子標籤的設置只是為了便於描述後續Snmpv3Trap的封裝方式，並無實際意義。
結合圖4和圖5，概括而言，本發明實施例所述的SnmpTrap封裝方式就是將圖5所示內容全部封裝在圖4所示「any」中，並且封裝在「any」中的內容也要符合圖4所示模型的層次結構。
舉例說明 本示例用於通知客戶端，系統中設備的1個接口故障(down)事件，對應生成的事件通知為Snmpv1trap告警。其中的community為「public」、timastamp為「3:40」、agentaddr為「10.111.64.12」、gid為「1.3.6.1.4.1.2011」、sid為「2」、sid為「0」；該告警有一個vb，且該vb的oid為「1.3.6.1.4.1.2011.2.1」，value為「2」。
將該示例所示Snmpv1trap告警封裝為XML格式的XML模型定義(XSD)文件文本為 3:40 10.111.64.12 1 .3.6.14.1.2011 2 0 1.3.6.1.4.1.2011.2.1 2(link down) 步驟311:Session handler將封裝為XML格式的事件通知發送給Client。
需要說明的是，本實施例中，Client發送的訂閱請求中還可以進一步攜帶有格式請求信息，用於說明Client希望接收到的事件通知格式。比如，伺服器生成的事件通知為XML-Snmpv1trap格式，但是Client希望接收到XML-Snmpv2trap格式的事件通知，則步驟310將進一步包括Session handler將XML-Snmpv1trap格式的事件通知轉換為XML-Snmpv2trap格式，所採用的轉換方式可以為可擴展類型表語言轉換(XSLT)方式。
XSLT是一種用於描述XML文檔之間如何轉換的語言，它同XPath標準緊密結合，二者共同致力於網絡數據管理的開發工作。XPath用於指定需要進行轉換的內容，而XSLT則提供了描述如何實現轉換的相應的互補語言。XSLT中規定了一系列將源XML文檔轉換為結果XML文檔的規則，對於本發明實施例來說，結果XML文檔可以為XML-Snmpv1trap、XML-Snmpv2trap、XML-Snmpv3trap以及XML-syslog等，通過XSLT處理器即可完成基於這些規則的轉換過程。當然，除了用於源XML文檔向結果XML文檔的轉換外，XSLT還可以用於實現XML文檔向其它格式文檔的轉換，比如超文本連結標識語言(HTML)等。
圖6為本發明實施例通過XSLT實現XML-Snmpv2trap和XML-Snmpv1trap之間轉換的規則示意圖。如圖6所示，兩種格式中的timestamp、community以及vbs進行對應轉換；XML-Snmpv1trap中的eid為固定值，為轉換腳本運行之前輸入的一個參數；而XML-Snmpv2trap中的trapoid和XML-Snmpv1trap中的gid以及sid將按照圖6中的程序段所示的規則進行轉換，即當trapoid為1.3.6.1.6.3.1.1.5.1時，對應轉換後的gid和sid均為0，當trapoid取其它值時，對應的gid和sid的轉換規則請參照下面的例子。
依圖6所示，本領域技術人員可以較為容易的實現XML-Snmpv2trap與XML-Snmpv1trap之間的轉換。舉例說明，XML-Snmpv2trap向XML-Snmpv1trap轉換的XSLT腳本如下 1.3.6.1.4.1.201 1 0.0.0.0 <xsl:when test″trapoid＝"；1.3.6.1.6.3.1.1.5.1"；″> 0 0 //當trapoid為1.3.6.1.6.3.1.1.5.1時，對應轉換後的gid和sid為0 <xsl:when test＝″trapoid＝"；1.3.6.1.6.3.1.1.5.2"；″> 1 0 //當trapoid為1.3.6.1.6.3.1.1.5.2時， 對應轉換後的gid為1，sid為0 <xsl:when test″trapoid＝"；1.3.6.1.6.3.1.1.5.3"；″> 2 0 //當trapoid為1.3.6.1.6.3.1.1.5.3時， 對應轉換後的gid為2，sid為0 <xsl:whentest″trapoid＝"；1.3.6.1.6.3.1.1.5.4"；″> 3 0 當trapoid為1.3.6.1.6.3.1.1.5.4時， 對應轉換後的gid為3，sid為0 <xsl:when test＝″trapoid＝"；1.3.6.1.6.3.1.1.5.5"；″> 4 0 //當trapoid為1.3.6.1.6.3.1.1.5.5時， 對應轉換後的gid為4，sid為0 <xsl:when test＝″trapoid＝"；1.3.6.1.6.3.1.1.5.6"；″> 5 0 //當trapoid為1.3.6.1.6.3.1.1.5.6時， 對應轉換後的gid為5，sid為0 6 當trapoid取其它值時，對應轉換後的gid為6，sid按照「select＝......」所述方式取值 圖7為本發明方法第二個較佳實施例的流程圖。本實施例與圖3所示實施例相比，區別在於，伺服器端生成的事件通知為syslog。
如圖7所示，該實施例包括以下步驟: 首先，Client與Session handler之間建立SSH會話，建立SSH會話的過程為現有技術。
步驟701Client向Session handler發送訂閱請求。
訂閱請求中攜帶有訂閱的事件通知類型、過濾類型以及所要求得到的過濾結果信息。假設本實施例中，Client訂閱的事件通知類型是流為「syslogover netconf」的所有事件，過濾類型為Xpath過濾，所要求的過濾結果為優先級8～15的事件。進一步地，還可以在訂閱請求中指定將事件通知存儲到syslog-subscription.profile文件中，指定訂閱開始時間為2001-12-24T122345。
現有技術中已經對NETCONF的事件通知訂閱請求的格式進行了明確定義，本步驟中發送的訂閱請求只是對現有技術的應用而已。舉例如下: syslog over netconf //訂閱流為「syslog over netconf」的所有事件 //採用Xpath過濾方式，得到優先級為8～15的事件 syslog-subscription.profile//存儲到指定文件 2001-12-24T12:23:45//訂閱開始時間 步驟702～706與步驟302～306相同，不再贅述。
步驟707Event Center向Notification Manager發送syslog信息。
當系統中有事件發生時，Event Center根據該事件類型，生成相應類型的事件通知。假設本步驟中Event Center向Notification Manager發送的syslog信息中同時包括各個優先級的事件。
步驟708Notification Manager根據訂閱列表進行過濾。
本步驟中，Notification Manager根據訂閱列表中存儲的客戶端的訂閱事件通知類型信息找到訂閱syslog類型事件通知的客戶端，並根據存儲的過濾類型以及所要求得到的過濾結果信息，通過Xpath過濾，得到只包括優先級為8～15的事件的事件通知。
也可以通過子樹過濾方式，得到「優先級為8～15的事件的事件通知」。兩種過濾方式均為現有技術，不再詳細介紹。但是需要說明的是，本實施例中無論採用哪種過濾方式，都是以一條完整的syslog為基本單元進行過濾的，即不對信息內部進行過濾，以保證信息的完整性。
步驟709Notification Manager向Session handler發送過濾後的事件通知。
步驟710Session handler將事件通知封裝為XML格式。
本發明實施例中將syslog格式的事件通知封裝為XML格式的方式為 依據現有NETCONF協議的事件通知模型，將syslog中攜帶的信息封裝到所述事件通知模型的標籤內容中，並且封裝後的內容也要符合現有NETCONF協議事件通知模型的層次結構。
如表3所示，syslog由PRI、HEADER以及MSG三部分組成，其中PRI進一步包括MsgSource以及Severity；HEADER進一步包括timestamp以及agentaddr；MSG中包括的信息根據實際需要進行設置。所以，本實施例中要實現將syslog格式的事件通知封裝為XML格式，只需將syslog設置為標籤，將syslog中攜帶的信息按照上述層次關係分別設置為syslog的第一級或第二級子標籤。
圖8為本發明實施例syslog封裝為XML格式的模型示意圖。如圖8所示，PRI、HEADER以及MSG三個組成部分被設置為syslog的三個子標籤，而PRI、HEADER以及MSG各自所包括的信息則被進一步設置為PRI、HEADER以及MSG的子標籤。圖8所示的syslog標籤之前進一步包括一個syslogs標籤，該標籤的作用是為了說明可以將多個syslog封裝在同一個syslogs中進行發送。
結合圖4和圖8，概括而言，本發明實施例所述的syslog封裝方式就是將圖8所示內容全部封裝在圖4所示「any」中，並且封裝在「any」中的內容也要符合圖4所示模型的層次結構。
舉例說明 本示例用於通知客戶端，系統中設備的1個接口down事件，生成的事件通知為syslog。其中PRI為8、timastamp為「2001-12-24T122345」、agentaddr為「10.111.64.12」、告警的接口索引為「1」，告警信息為「linkdown」。將該示例所述syslog封裝為XML格式的XSD文件文本為 1 0 2001-12-24T12:23:45 10.111.64.12 20111linkdown 步驟711Session handler將封裝為XML格式的事件通知發送給Client。
後續處理過程與圖3所示實施例相同，不再贅述。
依據上述方法，圖9為本發明系統實施例的組成結構示意圖。如圖9所示，該系統包括客戶端901和伺服器902； 客戶端901，用於在伺服器902中訂閱事件通知，並接收伺服器902發送的事件通知； 伺服器902，用於在系統中有事件發生時，生成事件通知，並將事件通知轉換為客戶端901能夠識別的格式後發送給客戶端901。
其中，伺服器具體包括會話處理模塊9021、通知管理模塊9022以及事件處理中心9023； 會話處理模塊9021，用於將接收自客戶端901的攜帶有訂閱事件通知類型的訂閱請求發送至通知管理模塊9022，並將接收自通知管理模塊9022的響應消息轉化為XML格式後發送至客戶端901；接收來自通知管理模塊9022的事件通知，將事件通知轉換為XML格式後發送至客戶端901； 通知管理模塊9022，用於將接收自會話處理模塊9021的訂閱請求加入預先保存的訂閱列表，同時向會話處理模塊9021回送訂閱成功與否的響應消息；接收來自事件處理中心9023的事件通知，根據訂閱列表過濾到訂閱該類型事件通知的客戶端，並將事件通知發送到會話處理模塊9021； 事件處理中心9023，用於在系統中有事件發生時，根據需要生成與事件對應的類型的事件通知，並將事件通知發送至通知管理模塊9022。
上述訂閱請求中可進一步攜帶有過濾類型以及所要求得到的過濾結果信息；相應地，通知管理模塊9022進一步用於，根據過濾類型以及所要求得到的過濾結果信息過濾得到客戶端901實際訂閱的事件通知。
如果需要，上述訂閱請求中還可進一步攜帶有格式請求信息；相應地，會話處理模塊9021進一步用於，將XML格式的事件通知轉換為客戶端901的格式請求信息中所請求的格式。
可見，採用本發明實施例的技術方案，實現了有效地兼容各種形式的事件通知方式；而且，由於客戶端和伺服器之間採用SSH連接承載協議，而SSH採用TCP連接，對內容進行了加密處理，所以保證了事件通知的可靠到達以及信息內容的安全性；此外，由於使用XML文本流的方式發送事件通知，在任何層面都能夠較為容易的使用XSLT對其進行轉換，從而方便了客戶端的後續處理；再有，本發明實施例中允許將多個事件通知批量放在同一XML文件中進行傳送，減少了傳送消耗，而且，本發明實施例要實現過濾訂閱非常方便，不但過濾方式靈活，而且可以實現針對每個目標(Target)的個性化過濾。
綜上所述，以上僅為本發明的較佳實施例而已，並非用於限定本發明的保護範圍。凡在本發明的精神和原則之內，所作的任何修改、等同替換、改進等，均應包含在本發明的保護範圍之內。
權利要求
1.一種基於網絡配置協議NETCONF的事件通知發送方法，其特徵在於，該方法包括以下步驟
NETCONF客戶端在NETCONF伺服器中訂閱事件通知；
當系統中有事件發生時，所述NETCONF伺服器生成事件通知，並將所述事件通知轉換為所述NETCONF客戶端能夠識別的格式，發送至所述NETCONF客戶端。
2.根據權利要求1所述的方法，其特徵在於，該方法之前進一步包括
所述NETCONF客戶端與NETCONF伺服器之間建立基於傳輸控制協議TCP的會話；
所述NETCONF客戶端通過所述會話在所述NETCONF伺服器中訂閱事件通知；當系統中有事件發生時，所述NETCONF伺服器通過所述會話將生成的事件通知發送至所述NETCONF客戶端。
3.根據權利要求1或2所述的方法，其特徵在於，所述NETCONF客戶端在NETCONF伺服器中訂閱事件通知的方法為
所述NETCONF客戶端向NETCONF伺服器發送訂閱請求，所述訂閱請求中攜帶有訂閱的事件通知類型信息；
所述NETCONF伺服器接收所述訂閱請求，並在訂閱成功後將所述訂閱請求加入預先設置的訂閱列表中。
4.根據權利要求3所述的方法，其特徵在於，該方法進一步包括
所述NETCONF伺服器生成訂閱成功與否的響應消息，並將所述響應消息轉換為可擴展標識語言XML格式後發送至所述NETCONF客戶端。
5.根據權利要求3所述的方法，其特徵在於，所述NETCONF伺服器生成事件通知的方法為
所述NETCONF伺服器根據所發生的事件類型，生成與所述事件類型對應類型的事件通知。
6.根據權利要求5所述的方法，其特徵在於，所述NETCONF伺服器將所述事件通知轉換為NETCONF客戶端能夠識別的格式之前，該方法進一步包括
所述NETCONF伺服器根據所述訂閱列表中存儲的訂閱的事件通知類型信息，查找到訂閱所述類型事件通知的NETCONF客戶端。
7.根據權利要求6所述的方法，其特徵在於，所述NETCONF伺服器將所述事件通知轉換為所述NETCONF客戶端能夠識別的格式的方法為
如果所述訂閱請求中沒有攜帶格式請求信息，則所述NETCONF伺服器將所述類型事件通知封裝為XML格式；
如果所述訂閱請求中進一步攜帶有格式請求信息，則所述NETCONF伺服器首先將所述類型事件通知封裝為XML格式，然後，將所述封裝為XML格式的事件通知轉換為所述NETCONF客戶端的格式請求信息中所請求的格式。
8.根據權利要求7所述的方法，其特徵在於，所述事件通知類型為簡單網絡管理協議告警SnmpTrap或系統日誌syslog。
9.根據權利要求8所述的方法，其特徵在於，所述訂閱請求中進一步攜帶有過濾類型以及所要求得到的過濾結果信息。
10.根據權利要求9所述的方法，其特徵在於，所述過濾類型包括子樹SUBTREE過濾以及XML路徑語言Xpath過濾。
11.根據權利要求9或10所述的方法，其特徵在於，所述NETCONF伺服器將所述事件通知轉換為NETCONF客戶端能夠識別的格式之前，該方法進一步包括
所述NETCONF伺服器根據所述訂閱列表中存儲的過濾類型以及所要求得到的過濾結果信息過濾得到所述NETCONF客戶端實際訂閱的事件通知。
12.根據權利要求8所述的方法，其特徵在於，若所述事件通知的類型為SnmpTrap，則所述NETCONF伺服器將事件通知封裝為XML格式的方法為
依據NETCONF協議的事件通知模型，所述事件通知模型為標籤、子標籤以及標籤內容的層次結構，所述子標籤為數據data標籤，其對應的標籤內容中可任意添加信息；
將所述SnmpTrap中攜帶的信息封裝到所述標籤內容中，並且封裝後的內容符合所述NETCONF協議事件通知模型的層次結構。
13.根據權利要求12所述的方法，其特徵在於，所述SnmpTrap包括Snmpv1Trap、Snmpv2Trap和Snmpv3Trap；
所述Snmpv1Trap由時間戳timestamp、代理地址agentaddr、通用標識eid、特定標識sid以及變量綁定對vbs信息組成；
所述Snmpv2Trap由timestamp、告警對象標識trapoid以及vbs信息組成；其中，所述vbs中包括一個或一個以上vb，所述每個vb中進一步包括oid和變量值value；
所述Snmpv3Trap包括Snmpv2Trap中的全部信息，且進一步包括上下文名稱contextname以及上下文標識contextid信息；
所述將SnmpTrap中攜帶的信息封裝到所述標籤內容中的方法為
將SnmpTrap設置為標籤，Snmpv1Trap、Snmpv2Trap以及Snmpv3Trap設置為SNMPTrap的子標籤；將所述Snmpv1Trap、Snmpv2Trap以及Snmpv3Trap中各自攜帶的信息按照所述包含關係分別對應地設置為所述Snmpv1Trap、Snmpv2Trap以及Snmpv3Trap的不同級別子標籤。
14.根據權利要求8所述的方法，其特徵在於，若所述事件通知的類型為syslog，則所述NETCONF伺服器將事件通知封裝為XML格式的方法為
依據NETCONF協議的事件通知模型，所述事件通知模型為標籤、子標籤以及標籤內容的層次結構，所述子標籤為data標籤，其對應的標籤內容中可任意添加信息；
將所述syslog中攜帶的信息封裝到所述標籤內容中，並且封裝後的內容符合所述NETCONF協議事件通知模型的層次結構。
15.根據權利要求14所述的方法，其特徵在於，所述syslog由優先級PRI、消息頭HEADER以及消息內容MSG三部分組成；其中，所述PRI中進一步包括日誌來源MsgSource以及嚴重程度Severity信息；所述HEADER中進一步包括timestamp以及agentaddr信息；所述MSG中包括的信息根據實際需要進行設置；
所述將syslog中攜帶的信息封裝到所述標籤內容中的方法為
將syslog設置為標籤；將所述syslog中攜帶的信息按照所述層次關係分別設置為所述syslog標籤的不同級別子標籤。
16.根據權利要求15所述的方法，其特徵在於，該方法進一步包括
設置一個標籤syslogs，將一個或一個以上的所述syslog標籤設置為所述syslogs的子標籤。
17.根據權利要求13或15所述的方法，其特徵在於，所述NETCONF伺服器將封裝為XML格式的事件通知轉換為NETCONF客戶端的格式請求信息中所請求的格式的方法為
所述NETCONF伺服器通過可擴展類型表語言轉換XSLT方式，將所述XML格式的事件通知轉換為NETCONF客戶端所請求的格式。
18.一種基於NETCONF的事件通知發送系統，其特徵在於，該系統包括NETCONF客戶端和NETCONF伺服器；
所述NETCONF客戶端，用於在所述NETCONF伺服器中訂閱事件通知，並接收所述NETCONF伺服器發送的事件通知；
所述NETCONF伺服器，用於在系統中有事件發生時，生成事件通知，並將所述事件通知轉換為NETCONF客戶端能夠識別的格式後，發送至所述NETCONF客戶端。
19.根據權利要求18所述的系統，其特徵在於，所述NETCONF伺服器具體包括會話處理模塊、通知管理模塊以及事件處理中心；
所述會話處理模塊，用於將接收自所述NETCONF客戶端的攜帶有訂閱事件通知類型的訂閱請求發送至所述通知管理模塊，並將接收自所述通知管理模塊的響應消息轉化為XML格式後發送至所述NETCONF客戶端；接收來自所述通知管理模塊的事件通知，將所述事件通知轉換為XML格式後發送至所述NETCONF客戶端；
所述通知管理模塊，用於將接收自所述會話處理模塊的訂閱請求加入預先保存的訂閱列表，同時向所述會話處理模塊回送訂閱成功與否的響應消息；接收來自所述事件處理中心的事件通知，根據所述訂閱列表過濾到訂閱所述類型事件通知的NETCONF客戶端，並將所述事件通知發送到所述會話處理模塊；
所述事件處理中心，用於在系統中有事件發生時，根據需要生成與所述事件對應的類型的事件通知，並將所述事件通知發送至所述通知管理模塊。
20.一種基於NETCONF的事件通知發送設備，該設備為NETCONF伺服器，其特徵在於，所述NETCONF伺服器包括會話處理模塊、通知管理模塊以及事件處理中心；
所述會話處理模塊，用於將接收自NETCONF客戶端的攜帶有訂閱事件通知類型的訂閱請求發送至所述通知管理模塊，並將接收自所述通知管理模塊的響應消息轉化為XML格式後發送至所述NETCONF客戶端；接收來自所述通知管理模塊的事件通知，將所述事件通知轉換為XML格式後發送至所述NETCONF客戶端；
所述通知管理模塊，用於將接收自所述會話處理模塊的訂閱請求加入預先保存的訂閱列表，同時向所述會話處理模塊回送訂閱成功與否的響應消息；接收來自所述事件處理中心的事件通知，根據所述訂閱列表過濾到訂閱所述類型事件通知的NETCONF客戶端，並將所述事件通知發送到所述會話處理模塊；
所述事件處理中心，用於在系統中有事件發生時，根據需要生成與所述事件對應的類型的事件通知，並將所述事件通知發送至所述通知管理模塊。
21.根據權利要求20所述的設備，其特徵在於，所述訂閱請求中進一步攜帶有過濾類型以及所要求得到的過濾結果信息；
所述通知管理模塊進一步用於，根據所述過濾類型以及所要求得到的過濾結果信息過濾得到所述NETCONF客戶端實際訂閱的事件通知。
22.根據權利要求20所述的設備，其特徵在於，所述訂閱請求中進一步攜帶有格式請求信息；
所述會話處理模塊進一步用於，將所述XML格式的事件通知轉換為所述NETCONF客戶端的格式請求信息中所請求的格式。
全文摘要
本發明實施例公開了一種基於網絡配置協議(NETCONF)的事件通知發送方法，包括NETCONF客戶端在NETCONF伺服器中訂閱事件通知；當系統中有事件發生時，NETCONF伺服器生成事件通知，並將所述事件通知轉換為NETCONF客戶端能夠識別的格式後，發送至NETCONF客戶端。本發明實施例同時公開了一種基於NETCONF的事件通知發送系統以及設備。應用本發明實施例所述的方法和系統以及設備，能夠兼容各種事件通知方式，以實現NETCONF中的事件通知。
文檔編號H04L12/24GK101110822SQ200710126058
公開日2008年1月23日 申請日期2007年7月6日 優先權日2007年7月6日
發明者紀曉峰 申請人:華為技術有限公司