多媒體通信技術多媒體通信服務質量與管理

多媒體通信技術多媒體通信服務質量與管理第1頁/共85頁7.1引言

服務質量（QualityofService,QoS）是一種抽象概念,用于說明網絡服務的“良好”程度。由于不同的應用對網絡性能的要求不同,對網絡所提供的服務質量期望值也不同。這種期望值可以用一種統(tǒng)一的QoS概念來描述。在不同應用系統(tǒng)中,QoS參數集的定義方法可能是不同的,經常使用吞吐量、差錯率、端到端延遲、延遲抖動等網絡性能參數來定義QoS。對連續(xù)媒體傳輸來說,端到端延遲和延遲抖動是兩個關鍵的性能參數。多媒體應用,特別是交互式多媒體應用對延遲有嚴格的限制,不能超過人所能容忍的極限,否則將會嚴重地影響服務質量。同樣,延遲抖動也必須維持在嚴格的界限內,否則將會嚴重地影響人對語音和圖像信息的識別。第2頁/共85頁7.2QoS參數體系結構圖7.1QoS參數體系結構應用層QOS傳輸層網絡層數據鏈路層第3頁/共85頁1.應用層表7.1一個視頻QoS分級的例子QoS級視頻幀傳輸速率/(幀/秒)分辨率/%主觀評價損害程度525～3065～100很好細微415～2450～64好可察覺36～1435～49一般可忍受23～520～34較差很難忍受11～21～9差不可忍受第4頁/共85頁2.傳輸層傳輸層協議主要提供端到端的、面向連接的數據傳輸服務。通常,這種面向連接的服務能夠保證數據傳輸的正確性和順序性,但以較大的網絡帶寬和延遲開銷為代價。傳輸層QoS必須由支持QoS的傳輸層協議提供可選擇和定義的QoS參數。傳輸層QoS參數主要有:吞吐量、端到端延遲、端到端延遲抖動、分組差錯率和傳輸優(yōu)先級等。國際標準化組織(ISO)在1986年頒布的ISO/OSI8072標準中明確地定義了傳輸層QoS參數:第5頁/共85頁

·建立連接延遲:用戶發(fā)出連接請求到接收到連接確認之間的時間間隔。

·建立連接失敗率:在最大建立連接延遲內不能建立連接的可能性。

·吞吐量:每秒接收的用戶數據字節(jié)數。

·傳輸延遲:發(fā)送方發(fā)出數據到接收方接收到該數據所經歷的時間間隔。

·固有差錯率:在取樣時間段內丟失和出錯的信息數占總信息數的比率。第6頁/共85頁

·傳輸失敗率:在數據傳輸階段因各種原因所造成失敗的信息占總信息數的比率。

·釋放連接延遲:一方發(fā)出釋放請求到對方執(zhí)行釋放之間的時間間隔。

·保護:用于說明建立安全連接需求的參數,如沒有竊聽或修改。

·優(yōu)先級:規(guī)定在該連接上傳輸的優(yōu)先級。

·彈性:用于說明傳輸層自動終結的可能性。第7頁/共85頁3.網絡層網絡層協議主要提供路由選擇和數據報轉發(fā)服務。通常,這種服務是無連接的,通過中間點（路由器）的“存儲-轉發(fā)”機制來實現。在數據報轉發(fā)過程中,路由器將會產生延遲（如排隊等待轉發(fā)）、延遲抖動（選擇不同的路由）、分組丟失及差錯等。網絡層QoS同樣也要由支持QoS的網絡層協議提供可選擇和定義的QoS參數,如吞吐量、延遲、延遲抖動、分組丟失率和差錯率等。第8頁/共85頁

網絡層協議主要是IP協議,其中IPv6可以通過報頭中優(yōu)先級和流標識字段支持QoS。一些連接型網絡層協議,如RSVP和STⅡ等可以較好地支持QoS,其QoS參數通過保證服務(GS)和被控負載服務(CLS)兩個QoS類來定義。它們都要求路由器也必須具有相應的支持能力,為所承諾的QoS保留資源（如帶寬、緩沖區(qū)等）。第9頁/共85頁4.數據鏈路層數據鏈路層協議主要實現對物理介質的訪問控制功能,也就是解決如何利用介質傳輸數據問題,與網絡類型密切相關,并不是所有網絡都支持QoS,即使支持QoS的網絡其支持程度也不盡相同。各種Ethernet都不支持QoS。TokenRing、FDDI和100VG-AnyLAN等是通過介質訪問優(yōu)先級定義QoS參數的。ATM網絡能夠較充分地支持QoS,它是一種面向連接的網絡,在建立虛連接時可以使用一組QoS參數來定義QoS。第10頁/共85頁

國際電信聯合會(ITU)制定了有關ATM網絡QoS參數,它允許用戶指定如下的參數:

·峰值信元速率(PCR):用戶發(fā)送信元的最大瞬間速率。

·長期承受信元速率(SCR):經過一個長時期測量到的平均信元速率。

·信元丟失率(CLR):在信元傳輸過程中丟失的信元所占的百分比。

·信元傳輸延遲(CTD):一個信元從進入網絡到離去所經歷的延遲。

·信元延遲變化范圍(CDV):CTD的變化范圍。

·突發(fā)容許(BT):允許以PCR發(fā)出的最大突發(fā)長度。

·最小信元速率(MCR):用戶期望至少要達到的最小信元速率。第11頁/共85頁7.3QoS管理機制QoS管理機制應當提供如下QoS管理特性:①QoS管理應是可配置的。②QoS管理應是可協商的。③QoS管理應是動態(tài)的。④QoS管理應是端到端的。⑤QoS管理應是層次化的。第12頁/共85頁7.3.1QoS分類和保證機制(1)確定型（Deterministic）QoS

在數據傳輸過程中,網絡提供“硬”的QoS保證,即對所承諾的QoS必須嚴格保證,否則可能會造成嚴重的后果。這類服務一般用于硬實時應用,如在遠程醫(yī)療系統(tǒng)中,X光照片數據必須采用實時無差錯的傳輸。Internet綜合服務中的保證服務（GS）和區(qū)分服務中的快速轉發(fā)均屬于這一類QoS。第13頁/共85頁(2)統(tǒng)計型（Statistical）QoS

在數據傳輸過程中,網絡提供“軟”的QoS保證,即對所承諾的QoS允許一定范圍的波動,并且不會造成不良的后果。這類服務一般用于軟實時應用,如遠程多媒體點播（VOD）系統(tǒng)。Internet綜合服務中的被控負載服務（CLS）和區(qū)分服務中的保證轉發(fā)均屬于這一類QoS。

(3)盡力型（BestEffort）QoS

盡力型QoS也稱最佳效果傳輸,網絡不提供任何QoS保證,網絡性能將隨著負載的增加而明顯下降。由于受到帶寬的限制,現有Internet上的分布式多媒體應用大多提供這類服務。第14頁/共85頁7.3.2802.1p圖7.2802.1p/Q幀格式和被標記數據流的優(yōu)先級處理(a)802.1QTaggedFrame;(b)基于802.1p優(yōu)先級的數據流處理第15頁/共85頁表7.2802.1p的優(yōu)先級標記值及對應的流量類型標記值流量類型1Background2Standard(Spare)0BestEffort3ExcellentEffort(BusinessCritical)4ControlledLoad(StreamingMultimedia)5Video(Interactivemedia),lessthan100mslatencyandjitter6Voice(Interactivevoice),lessthan10mslatencyandjitter7NetworkControl(ReservedTraffic)第16頁/共85頁7.3.3DiffServIETF提出了兩種QoS保證機制,一是由RSVP提供的保證型服務;二是在區(qū)分服務(Diff-Serv,DS)中定義的區(qū)分型服務。由于保證型服務具有面向連接的特性,并通過QoS協商、接納控制、保留帶寬和實時調度等機制來實現。區(qū)分型服務具有無連接的特性,主要通過緩沖管理和優(yōu)先級調度機制來實現,而無需進行QoS協商和保留帶寬等控制。隨著網絡規(guī)模的增長,保證型服務的復雜性將會迅速增加,并難以擴展。由于IP網絡的發(fā)展仍然是基于無連接的,區(qū)分型服務與之相適應,更適合在大型IP網絡(如Internet)中應用。第17頁/共85頁IETF的DiffServ工作組在RFC2474和RFC2475中發(fā)布了區(qū)分服務標準草案。其中,RFC2474定義了IPv4和IPv6報頭中的區(qū)分服務(DS)字段及其支持機制;RFC2475定義了區(qū)分服務體系結構;RFC（RequestForComments）是Internet研究和開發(fā)機構所發(fā)布的有關網絡協議及標準的注釋性公文系列。區(qū)分服務規(guī)定了一個網絡內部轉發(fā)報文分組的傳輸特性,這些特性可以用定量或靜態(tài)項來指定,如吞吐量、丟失率、延時及延時抖動等;也可以用訪問網絡資源的相對優(yōu)先級項來指定。第18頁/共85頁實現一種區(qū)分服務的要素是:·該服務是提供給一個流量聚集的;·調節(jié)功能和PHB用于實現服務;·DS字段用于標記報文分組,以選擇一個PHB;·特定節(jié)點實現PHB機制。第19頁/共85頁1.DS字段定義

RFC2474定義了IP報頭中的DS字段:在IPv4報頭中,重定義了服務類型(TOS)字段;在IPv6報頭中,重定義了流量級別(TC)字段。并且還規(guī)定了各個網絡節(jié)點上轉發(fā)報文分組的命令集,或稱為逐跳行為(PHB)。在8位的DS字段中,定義了如下的結構和內容:DSCodePointCU第20頁/共85頁

其中,DSCodePoint(DSCP)占6位,用于指定該報文分組在各個節(jié)點上的PHB;CU(CurrentlyUnused)占2位,為系統(tǒng)保留,支持DS的節(jié)點將忽略CU值。由于DSCP字段采用無結構字段定義的,便于將來PHB的定義和擴展。DSCP字段的基本特性如下:

·從DSCP到PHB的映射是可配置的,每個支持DS的節(jié)點都要實現這種可配置的映射;

·PHB規(guī)范空間必須包含一個推薦的缺省DSCP,且是惟一的,在節(jié)點所實現的缺省配置中應支持缺省DSCP到PHB的映射;

·如果一個報文分組使用了不可識別的DSCP值,則節(jié)點應當原樣轉發(fā)該報文分組,無需改變DSCP值,并且不會引起節(jié)點故障;·DSCP字段必須與當前慣有方法保持向后兼容。第21頁/共85頁2.PHB

一個PHB是一個節(jié)點為一個特定的DS行為集而采取的轉發(fā)行為(如吞吐量、丟失率、延遲及抖動等),一個DS行為集占用一個連接,其轉發(fā)行為將取決于該連接上的負荷。當多個DS行為集競爭一個節(jié)點上的緩沖區(qū)和帶寬資源時,該節(jié)點將根據不同的PHB來分配網絡資源。區(qū)分服務采用基于逐跳(hopbyhop)的資源分配機制。

PHB可以用下列項目定義:相對資源(如緩沖區(qū)和帶寬)優(yōu)先級,或者相對流量特性(如延遲、丟失率)。遵守共同約束(例如分組調度和緩沖區(qū)管理策略)的PHB可以組成一個PHB組,組內的PHB之間的關系可以使用絕對或相對優(yōu)先級,例如采用固定或隨機閾值的丟棄優(yōu)先級,但不是必須的。單獨定義的單一PHB是一個PHB組的特例。第22頁/共85頁

例如,一個簡單的PHB可定義如下:在一個連接上,保證為一個行為集分配x%的最小帶寬。這個PHB可以在任何流量調節(jié)下進行簡單而公平的測量。一個復雜的PHB可定義如下:在一個連接上,保證為一個行為集分配x%的最小帶寬,并且按比例公平地共享多余的連接容量。各個節(jié)點可利用某種分組調度和緩沖區(qū)管理機制來實現PHB。PHB是根據有關服務供應策略的行為特征定義的,而并非特定的實現機制。各種實現機制一般適合實現一個特定的PHB組,并且在一個節(jié)點上可以實現多個PHB組。在一個節(jié)點上,通過對所接收報文分組的DSCP的映射來選擇PHB。標準化的PHB應具有一個推薦的DSCP,它們之間存在著一一對應的映射關系。第23頁/共85頁目前,IETF已定義了三個標準的PHB:(1)快速轉發(fā)(2)保證轉發(fā)(3)盡力服務第24頁/共85頁3.DS域模型圖7.3區(qū)分服務工作模型第25頁/共85頁4.流量分類

流量分類是實現區(qū)分服務的首要條件,其基本原理是根據IP報頭中某些字段的內容來選擇和標記分組流中的報文分組。流量分類可以采用兩種分類器來實現:一是BA(BehaviorAggregate)分類器,它僅基于DSCP字段對報文分組進行分類;二是MF(MultiField)分類器,它基于一個或多個字段的組合值(如源地址、目的地址、DS、協議號以及源和目的端口號等)對報文分組進行分類。第26頁/共85頁5.流量調節(jié)圖7.4分組分類器和流量調節(jié)器框圖第27頁/共85頁6.分類器和流量調節(jié)器的位置(1)在源域內部源域是指包含產生流量節(jié)點的域。一個源域內部的流量源節(jié)點和中間節(jié)點可以執(zhí)行流量分類、標記和調節(jié)功能,從源域到一個邊界的流量可以直接由流量源節(jié)點來標記,也可以在離開源域之前由中間節(jié)點來標記,這就是初始標記或預標記。例如,一個企業(yè)網絡的HPR主機所輸出的報文分組應具有較高的優(yōu)先級?？梢圆捎脙煞N方法來標記HPR分組:一是由HPR主機(流量源節(jié)點)用DSCP=“高優(yōu)先級”來標記所有輸出分組的DS字段;二是由HPR主機所直接連接的第1跳路由器(中間節(jié)點)用適當的DSCP來為所有的HPR分組。第28頁/共85頁(2)在DS域邊界在一個上游域的DS出口節(jié)點或下游域的DS入口節(jié)點上可以對流量進行分類、標記和調節(jié)。在DS入口節(jié)點上,如果輸入的流量不符合TCA,則要按本地策略強制執(zhí)行TCA。如果一個DS入口節(jié)點所連接的上游域是一個不支持DS的域,則該節(jié)點必須對輸入的流量執(zhí)行流量調節(jié)功能。第29頁/共85頁(3)在不支持DS域在一個不支持DS的域中,流量源節(jié)點或中間節(jié)點可以在流量到達下游DS域入口之前對流量進行預標記。在這種情況下,可以掩蓋本地的分類和標記策略。由此可見,區(qū)分服務基于一種簡單的域模型,在網絡邊界上,對輸入網絡的流量進行分類和調節(jié),并指派給不同的行為集,而每個行為集則由一個單一的DSCP來標識;在網絡核心,將根據DSCP字段定義的PHB來轉發(fā)分組。這樣就使得網絡具有對不同報文分組流提供有區(qū)別服務的能力,而且便于功能的擴展,并降低了實現的復雜度。第30頁/共85頁7.4QoS管理協議7.4.1SNMP管理技術SNMP管理的基本原理是,通過兩個管理實體,即管理器（Manager）和代理（Agent）之間的相互合作,以分布方式執(zhí)行網絡管理活動。管理器負責管理網絡中各種資源和設備,并采用輪詢（Polling）方式向遠程的一個或多個代理發(fā)布管理命令,以獲取信息或實施控制。代理駐留在網絡設備上,負責設備的實際管理,響應和執(zhí)行管理器的管理命令,并返回應答信息。各種網絡資源被抽象成被管對象,通過管理信息庫(MIB)變量定義成標準的信息格式,以便于存儲、交換和訪問。每個網絡設備上的MIB由其代理負責維護。SNMP標準主要由三部分組成:網絡管理協議（SimpleNetworkManagementProtocol,SNMP）,管理信息結構（StructureofManagementInformation,SMI）和管理信息庫（ManagementInformationBase,MIB）。第31頁/共85頁7.4.1.1SNMP1.SNMP協議圖7.5SNMP體系結構第32頁/共85頁在SNMP中,管理器和代理之間的通信采用了如下的報文格式:versioncommunitydata(PDU)

·version域:表示SNMP的版本,在SNMPv1中為version-1(0);

·community域:主要是為增加系統(tǒng)安全性而設置的,代理可以要求管理器在發(fā)送請求報文時填寫該域,以驗證管理器是否有權訪問它的MIB。

·data域:用于存放實際要傳送的報文。第33頁/共85頁

在SNMP報文中,定義了五種網絡管理操作原語:①GetRequest:管理器使用該操作向代理請求取回某些變量值,如管理器請求取回某個路由器的某端口狀態(tài)。它要求代理響應具體的變量值。②GetNextRequest:管理器使用該操作向代理請求取回某變量的下一個變量值,它要求代理給予響應。管理器使用該操作可遍歷一個網絡設備MIB庫中某個對象的一系列參數。③GetResponse:代理使用該操作向管理器發(fā)送響應,回送相應的變量值。④SetRequest:管理器使用該操作向代理請求設置某些變量值,如管理器請求將某個路由器的某端口狀態(tài),由“Enable”設置成“Disable”。它要求代理設置本地MIB中相應的變量值。⑤Trap:代理使用該操作向管理器報告某一異常事件的發(fā)生,如連接的接通或斷開以及各種報警狀態(tài)等。這是由代理主動向管理器發(fā)出的報文。第34頁/共85頁

對應上述的五種操作,有五種報文類型,且使用了兩種協議數據單元(PDU)格式:①GetRequest、GetNextRequest、SetRequest和GetResponse的PDU格式都是相同的,即:PDUtypeRequestIDerrorstatuserrorindexvariablebinding第35頁/共85頁其中:

·PDUtype域:指明報文的PDU類型,即五種報文中的哪一種。

·RequestID域:指明請求的標識號,它是一個整數。每個請求都有惟一的標識號。

·errorstatus域:在GetResponse報文中,用于指明操作失敗的原因或狀態(tài)。

·errorindex域:在GetResponse報文中,用于指向引起操作失敗的那個變量。

·variablebinding域:包含一組變量名（對象標識符）和變量值,其結構如下:name1value1name2value2…namenvaluen第36頁/共85頁②Trap的PDU格式如下:EnterpriseAgentaddressGenerictraptypeSpecifictrapcodeTimestampvariable-binding

其中:

·Enterprise域:當Trap報文為特定的Trap報文類型時,則要指明定義該特定Trap報文類型的企業(yè)或廠家名。

·Agentaddress域:指明發(fā)送該Trap報文的Agent的IP地址。

·Generictraptype域:指明通用Trap報文類型,參見表7.3。

·Specifictrapcode域:指明特定Trap報文類型代碼,由廠家定義。

·Timestamp域:用于作時間標記。第37頁/共85頁表7.3通用Trap報文類型通用Trap報文類型報文產生說明冷啟動Trap報文的Agent重新初始化,其配置信息和Trap機制改變熱啟動Trap報文的Agent重新初始化,其配置信息和Trap機制不改變鏈路中止Trap報文的Agent發(fā)現配置中存在通信鏈路中止的錯誤鏈路啟動Trap報文的Agent發(fā)現配置中存在通信鏈路重新連通訪問權限失效Trap報文的Agent接收到某個超越權限的報文EGP對象中止Trap報文的Agent發(fā)現和EGP（外部網關協議）對象的連接中斷企業(yè)特定Trap報文的Agent發(fā)現已滿足企業(yè)特定的條件第38頁/共85頁SNMP報文使用ISO的ASN.1（AbstractSyntaxNotationOne）相關的BER（BasicEncodingRules）規(guī)則來編碼,形成其報文,并通過TCP/IP協議集中的UDP協議實現其報文傳送。ANS.1是一種用于描述結構化實體的結構和內容的語言,提供了描述抽象文法結構和內容的表示方法。ANS.1標準定義了一種稱為基本編碼規(guī)則BER的傳送文法,用于描述傳送過程中的報文內容。SNMP報文的傳送格式必須符合BER規(guī)范。下面是SNMP報文格式的ASN.1表示法:第39頁/共85頁SNMPDEFINITIONS::=BEGINMessage::=

SEQUENCE

{

version---version1forthisRFC

INTEGER

{

version1

(0)

},

community

---communityname

OCTETSTRING,

data---e.g.,PUDsiftrivial

ANY

---authenticationisbeingused

}第40頁/共85頁PUDs::=

CHOICE

{

get-request

GetRequest-PUD,

get-next-request

GetNextRequest-PUD,

get-response

GetResponse-PUD,

set-request

SetRequest-PUD,

trap

Trap-PUD

}END第41頁/共85頁2.SMI協議圖7.6對象標識符的分層結構及MIB-Ⅱ中的對象分類第42頁/共85頁3.MIB協議表7.4MIB-Ⅱ的被管對象類型類型對象標識符包含的信息systemmib-Ⅱ1主機或網關操作系統(tǒng),如:系統(tǒng)名稱、系統(tǒng)最后啟動時間、系統(tǒng)的物理位置等interfacesmib-Ⅱ2各種網絡接口,如:子網的接口數目、接口值表等atmib-Ⅱ3地址解釋,如:IP地址與物理地址對應表等Ipmib-Ⅱ4IP協議軟件,如:作為主機還是網關的標記、缺省的生存時間、IP的通信統(tǒng)計、IP的路徑表等Icmpmib-Ⅱ5ICMP協議軟件,如:接收到的ICMP消息數、發(fā)送的ICMP消息數、特定類型的消息數等tcpmib-Ⅱ6TCP協議軟件,如:TCP連接數最大值、接收的和發(fā)送的數據報數、有關連接信息(如IP地址、端口)等第43頁/共85頁類型對象標識符包含的信息Udpmib-Ⅱ7UDP協議軟件,如:接收到的正確的UDP報文數目、發(fā)送的UDP報文數、接收UDP報文的IP地址、端口等Egpmib-Ⅱ8EGP協議軟件,如:接收到的正確的EGP消息數目、本地產生的EGP消息數、相鄰的EGP信息表等Cmotmib-Ⅱ9CMOT協議軟件Transmissionmib-Ⅱ10傳輸介質,目前尚處于實驗階段snmpmib-Ⅱ11SNMP協議軟件,如:發(fā)送給本地SNMP的消息數、接收到的各類消息數、對各種錯誤的統(tǒng)計等表7.4MIB-Ⅱ的被管對象類型第44頁/共85頁MIB庫中的每個變量都符合ANS.1語法規(guī)則。在MIB庫中,每個被管對象或MIB變量將用五種特性來描述,它們是:

·對象描述符:表示被管對象的名字。

·語法:表示對應被管對象的抽象數據結構,如整數、八位位組串等。

·訪問權限:用readonly,readwrite,writeonly,notaccessible類型之一來描述,表示對該對象的訪問權限。

·狀態(tài):用mandatory,optional,obsolete類型之一來描述,表示該對象的當前狀態(tài)。

·描述：對象類型的文本描述和說明。第45頁/共85頁7.4.1.2SNMPv21.SNMPv2協議

SNMPv2協議規(guī)定了管理器和代理之間及管理器和管理器之間的通信方式、SNMP報文的格式與含義以及每種報文的處理方式等。SNMPv2定義了七種網絡管理的操作原語,除了支持SNMPv1的五種基本操作原語外,還新增加了兩種操作原語:①GetBulkRequest:管理器使用該操作向代理請求取回某變量下面幾個變量值,它要求代理對這些變量值給予響應。在一次報文交換中,管理器可使用該操作檢索大塊數據,以減少網絡通信開銷,提高效率。它克服了SNMPv1中不能對大數據塊進行有效查詢的弱點,一次可將一個對象的所有變量值全部讀出,也可以進行一些表格操作。這大大方便了管理器對信息的檢索,并有助于簡化高層管理程序。第46頁/共85頁②InformRequest:一個管理器使用該操作向另一個管理器發(fā)送一個Trap消息,并請求給予回應。接收方將使用GetResponse報文進行回應。這個操作原語的引入,使得SNMPv2能支持管理器-管理器的分布式網絡管理。在SNMPv2中,在什么條件下發(fā)送Trap報文,何時發(fā)送InformRequest報文都是可設定的。在SNMPv2中,GetRequest操作不再具有原子特性,即當一個SNMP報文中包括了對多個變量的操作時,如果代理在MIB庫中沒有找到某個變量,則可以用一個錯誤代碼作為該變量的應答。這樣,SNMPv2便允許對部分請求進行應答,這也是對SNMPv1的一大改進。但SetRequest操作仍具有原子特性。第47頁/共85頁SNMPv2的報文格式與SNMPv1基本相同,只是為新的GetBulkRequest操作增加了一種PDU格式,即:RDU-typeRequest-IDNon-repeatersMax-repetitionsVariable-binding其中:

·PDUtype域:指明報文的PDU類型,即七種報文中的哪一種。

·RequestID域:指明請求的標識號,是一個整數。每個請求都有惟一的標識號。

·errorstatus域:在GetResponse報文中,用于指明操作失敗的原因或狀態(tài)。第48頁/共85頁

·errorindex域:在GetResponse報文中,用于指向引起操作失敗的那個變量。

·variablebinding域:包含一組變量名(對象標識符)和變量值。

·nonrepeaters域:在GetBulkRequest報文中,用于指明在變量組中有多少個變量只要求一個后繼。

·maxrepetitions域:在GetBulkRequest報文中,用于指明變量組所剩余的變量中,每個變量能要求多少個后繼。第49頁/共85頁2.SMI協議與SNMPv1的SMI一樣,SNMPv2的SMI協議（RFC1442）詳細定義了MIB庫的組成結構,規(guī)定了定義和標識MIB變量的一組規(guī)則。它規(guī)定所有MIB變量必須用ANS.1來定義,每個MIB變量都要用一個對象標識符來標識。對象標識符的相互關聯,構成了一個樹型的分層結構。SNMPv2的SMI最主要的改進是它提供了用于描述被管對象的更詳細語法和語義,以及對二維數組表中的一行進行增刪的標準方法。第50頁/共85頁3.SNMPv2MIB協議

MIB協議規(guī)定了管理信息庫的被管對象類型、存儲格式以及對每個對象所允許的操作等。在SNMPv2標準中,除了兼容SNMPv1中所定義的所有的數據類型外,還增加了四種數據類型:UInteger、Counter64、BitString、NsapAddress。

SNMPv2標準還定義了SNMPv2管理系統(tǒng)自己使用的三種管理信息庫:SNMPv2MIB（RFC1450）、ManagerManagerMIB（RFC1451）和PartyMIB（RFC1447）。每個MIB又由一些組（Group）構成,一個組是一些對象的集合。協議規(guī)定:只有在實現中包含了一個組中所有的對象,才算是支持了這個組。第51頁/共85頁(1)SNMPv2MIB

SNMPv2MIB中的對象用于描述與SNMPv2管理系統(tǒng)有關的信息,這些信息能夠使管理器了解代理上有關SNMPv2系統(tǒng)活動和資源情況。這個MIB分為五個組:SNMPv2statistics組、SNMPv1statistics組、對象資源組、trap組和set組。①SNMPv2statistics組包括一組計數器,分別記錄發(fā)送和接收的SNMPv2報文的數量,以及因各種原因所造成的錯誤報文數量。第52頁/共85頁②SNMPv1statistics組也包括一組計數器,它們在SNMPv2系統(tǒng)與SNMPv1系統(tǒng)通信時才使用。③對象資源組表示代理上的動態(tài)配置資源,被表示成一個表,每種資源占用表中一項。④trap組由產生SNMPv2trap報文的對象組成。⑤set組只有一個對象:snmpSetSerialNo,用于解決SetRequest操作過程中的沖突問題。第53頁/共85頁(2)ManagerManagerMIB這種MIB可用于支持分布式網絡管理。高一級的管理器可以定義一些事件,當這些事件發(fā)生時,由低一級的管理器來通知它。這種MIB可以用來把一個中間的管理器當作監(jiān)測遠程網絡活動的監(jiān)視器,也可以用來報告中間管理器及其所管轄的各個代理的活動情況。它有兩個組:alarm組和event組。

alarm組用來定義一些報警用的閾值,每個閾值都與一個被監(jiān)測對象有關。當一個對象的取值超過它的閾值時,就會觸發(fā)一個事件的報告,即向高一級的管理器發(fā)送InformRequest報文。alarm組中的每一項都對應著event組中的一項,這個對應項定義了在InformRequest報文中應該傳送哪些信息。第54頁/共85頁(3)PartyMIB

這個MIB與網絡管理的安全性有關,它分為四個組:party組、context組、access組和privilegeMIBview組。第55頁/共85頁4.SNMPv2的分布式管理結構SNMPv2可以支持集中式和分布式兩種網絡管理結構。它對分布式網絡管理結構的支持主要表現在以下兩個方面:①InformRequest操作原語:一個管理器用來向另一個管理器發(fā)送Trap消息,并要求給予響應。

②ManagerManagerMIB:這個MIB有兩個小組:alarm組和event組。它們主要用來定義一些報警用的閾值,以及超過閾值時應向中心管理器報告的內容（通過InformRequest報文）。第56頁/共85頁圖7.7基于SNMPv2的分布式管理結構第57頁/共85頁5.SNMPv2與SNMPv1的共存關系在SNMPv2標準中,充分考慮了SNMPv1產品在SNMPv2環(huán)境中共存的問題（RFC1452）,以保護用戶已有的投資。解決與SNMPv1系統(tǒng)共存問題的最簡單辦法是將SNMPv1管理器升級為SNMPv2管理器,由SNMPv2管理器同時來管理SNMPv2代理和SNMPv1代理。由于SNMPv2的SMI協議是SMI協議的超集,因此SNMPv2管理器很容易理解SNMPv1代理上的MIB。需要解決的關鍵問題是SNMPv2和SNMPv1報文格式之間的差異。SNMPv2標準提出了兩種解決的方法:委托代理(Proxy)和雙協議管理器（Bilingualmanager）。第58頁/共85頁7.4.1.3SNMPv3協議SNMPv3將統(tǒng)一SNMPv2*和SNMPv2u中的概念和技術思想,并不考慮增加新的功能,而是回到SNMPv1簡單性（Simple）的老路上。SNMPv3的目標是:①盡量利用現有的成果,尤其是SNMPv2*和SNMPv2u;②達到SET安全標準的要求;③要盡可能地簡單;④支持大型網絡;⑤定義一個可長久使用的框架結構;⑥盡量使之標準化。第59頁/共85頁7.4.2基于策略的QoS管理技術1.策略管理框架通常,作為一個策略管理系統(tǒng)應具有如下三種能力:·允許一個用戶定義和修改策略規(guī)則的能力;·存儲和檢索策略規(guī)則的能力;·解釋和執(zhí)行策略規(guī)則的能力。第60頁/共85頁

因此,IETF提出了一種策略管理系統(tǒng)框架,它由如下功能元素組成:①策略管理工具:提供一種圖形化或命令/正本的用戶界面,允許用戶定義或修改策略規(guī)則,并實時監(jiān)視規(guī)則部署。②策略持久性:簡單而持久地保存策略規(guī)則,便于策略規(guī)則的持續(xù)存儲和檢索。③策略消費者:它是一種功能組合,主要負責獲取和部署策略規(guī)則,并且有選擇地將策略規(guī)則翻譯成一種策略目標可用的格式。④策略目標:它是一種功能元素,其行為受策略規(guī)則的控制,執(zhí)行由策略規(guī)則規(guī)定的動作。第61頁/共85頁圖7.8一個基于策略的管理系統(tǒng)框圖第62頁/共85頁2.策略規(guī)則的描述策略規(guī)則是用“ifthen”形式表示的,“if”表示條件集,與有關被管對象的屬性項相對應,“then”則表示一種動作集。例如,在為流量設置優(yōu)先級時,可采用如下策略:if源IP地址==192.168.34.2

then

Priority=5elseif目的IP地址==192.168.80.12

then

Priority=6elseif目的IP地址==192.168.80.0/255.255.255.248

then

Priority=7第63頁/共85頁3.策略規(guī)則的存儲和信息模型由于策略管理系統(tǒng)是以策略庫為核心構造的,因此策略規(guī)則必須采用公共的信息模型和數據結構存儲在策略庫中,以便于策略規(guī)則的定義、編輯、檢索和獲取。為了規(guī)范策略的信息模型,IETF定義了策略框架核心信息模型。它采用面向對象的信息模型來表示通用的策略信息,并規(guī)定了兩種對象類層次:一是表示策略信息和策略控制的結構化類;二是指示結構化類相互關系實例的關系類。這些對象類可以利用子類進行擴展,以表示特定類型的策略,例如,QoS管理策略或網絡安全策略。第64頁/共85頁IETF規(guī)定采用標準化的輕型目錄訪問協議(LDAP)來組織和訪問策略庫中的策略信息,并定義了從核心信息模型到LDAP目錄方案的映射方法。LDAP是IETF制定的一種基于目錄結構的信息存儲和訪問機制,為訪問和管理較大范圍(如Internet中)的網絡信息提供一種標準的方法。通常,LDAP采用LDAP服務器來實現。第65頁/共85頁圖7.9QoS信息模型定義的對象類及其層次關系第66頁/共85頁5.基于策略管理系統(tǒng)的實例在一個基于策略的管理系統(tǒng)中,從建立策略到執(zhí)行策略需要完成下列操作:

·管理員使用策略編輯器建立新的策略或編輯已有的策略,并建立該策略與PT的關系。策略與關系以指定的信息模型存儲在策略庫中。

·管理員采用一種主動通知機制通知PC接收該策略。

·PC從策略庫中檢索并獲取該策略,根據該策略與PT的關系來確定需要實施策略的PT。并且檢查該策略的有效性,如是否指定了一個未知的PT、是否發(fā)生策略沖突等。對于有效的策略,PC將該策略映射成該PT可執(zhí)行的信息格式,然后將策略信息傳送給該PT。

·PT執(zhí)行策略規(guī)定的動作,并將執(zhí)行的結果及其狀態(tài)信息返回給PC。由PC報告給管理員。第67頁/共85頁

下面是一個基于策略的配置路由器流量優(yōu)先級的例子。在這個例子中,PC采用策略服務器來實現,PT為一個路由器某端口的排隊優(yōu)先級,優(yōu)先級為0～7,7是最高優(yōu)先級。媒體流可采用下列特征來標識:

·目的IP地址、端口號或子網號;

·源IP地址、端口號或子網號;

·IPPrecedence值;·區(qū)分服務中的DSCP值。第68頁/共85頁

假如該路由器支持區(qū)分服務,并且媒體流已被分成三類:DSCP=0為盡力轉發(fā)、DSCP=1為保證轉發(fā)、DSCP=2為快速轉發(fā)。那么在基于策略的管理系統(tǒng)中,管理員可采用如下策略來配置該路由器端口的排隊優(yōu)先級:if源IP地址==192.168.34.2ANDDSCP==0

then

Priority=3elseif源IP地址==192.168.34.2ANDDSCP==1then

Priority=5elseif源IP地址==192.168.34.2ANDDSCP==2then

Priority=7

該策略采用QoS信息模型存儲在LDAP服務器中。管理員以適當的方式通知策略服務器去接收和處理該策略。第69頁/共85頁圖7.10基于策略的網絡系統(tǒng)構成第70頁/共85頁6.相關研究工作及產品Cisco公司的基于策略的網絡管理系統(tǒng)有QoSPolicyManager(QPM)和CiscoSecurityManager,其中QoS管理器和安全管理器分別是獨立的產品,但是共享一個通用的架構。QPM采用圖形用戶界面,簡化了QoS配置。在典型的會話中,用戶可以添加新的路由器,通過策略可以為每個路由器端口選擇排隊算法,設置為類型過濾器和轉發(fā)行為(設置IP優(yōu)先級)以及安排下載到路由器的方法。相同類型的端口可以按組分類,使策略既可以在單個端口級上實施,也可以在組級上實施。Cisco計劃在今后的QPM版本中增加對LDAP目錄和COPS的支持。第71頁/共85頁Nortel公司的基于策略的網絡管理系統(tǒng)稱為OptivityPolicyServices(OPS),OPS采用了IETF草案中描述的許多概念,包括策略服務器、COPS和存儲策略信息的LDAP兼容目錄。在典型OPS會話中,用戶可以添加路由器和單獨的端口,可以使用過濾器創(chuàng)建傳輸流模式、行為,以及與傳輸流模式、行為和端口相關的策略。相同類型的端口可以按組分類。OPS利用COPS進行PDP-PEP通信。它還支持包括Cisco路由器在內的其它設備。第72頁/共85頁Cabletron公司是最早開發(fā)基于策略的網絡管理技術的公司,其QoS策略管理器稱為SpectrumPolicyAware。策略信息將保存在LDAP兼容的目錄中,PDP與PEP之間的通信采用COPS以及其它協議。PEP也可以使用LDAP與目錄服務器進行通信。該公司的SmartSwitches支持802.1p和ToS/Diff-Serv等QoS標準并在每個端口上支持四個隊列和第二層到第四層分類和標記。這就意味著Cabletron的產品可以在布線室中提供高層的分類和標記技術,而其它多數廠商的產品則通過升級來實現。第73頁/共85頁3Com公司的策略服務器叫做TranscendPolicyService,該產品符合IETF正在開發(fā)的標準,其中包括策略架構和采用COPS。策略將被保存在LDAP兼容的目錄中,并且通過代理服務器來提供對傳統(tǒng)產品的支持。3Com公司通過向其第二層交換機中添加802.1p,向第三層路由器添加ToS/Diff-Serv和RSVP來開發(fā)具有QoS功能的網絡產品。此外,3Com公司的動態(tài)訪問產品還提供了在網絡接口卡(只要是3Com網卡)上提交報文分組分類和標記的功能。第74頁/共85頁7.5QoS管理模型和實現機制1.資源消費者-提供者協作管理模型在分布式多媒體環(huán)境中,端系統(tǒng)上的可用資源有CPU、緩沖區(qū)、I/O帶寬及網絡帶寬等,這些資源應當通過一種集成化的QoS管理機制實行統(tǒng)一的管理,提供端到端的、具有協作性、動態(tài)性和自適應性的