本備忘錄狀態(tài)
ThismemoPRovidesinformationfortheInternetcommunity.Itdoes
notspecifyanInternetstandardofanykind.Distributionofthis
memoisunlimited.

版權(quán)聲明
Copyright(C)TheInternetSociety(2001).

摘要
本備忘錄定義了在Internet社區(qū)中用于網(wǎng)絡(luò)治理協(xié)議的治理信息庫（MIB）的一部分，非凡是定義了治理實時傳輸協(xié)議（RTP）系統(tǒng)（RFC1889）的對象。












目錄
1.SNMP治理框架 2
2.概述 3
2.1組件 3
2.2MIB對于RTP系統(tǒng)應(yīng)用的適用性 3
2.3RTPMIB的結(jié)構(gòu) 4
3.定義 5
4.安全考慮（SecurityConsiderations） 24
5.致謝（Acknowledgements） 25
6.知識產(chǎn)權(quán)（IntellectualProperty） 25
7.引用（References） 25
8.作者地址（Authors'Addresses） 27
9.版權(quán)聲明 28


1.SNMP治理框架
*SNMP治理框架目前包括五個主要的組成部分：
*總體框架，參見RFC2571[RFC2571]的敘述。
*用于治理目的的對象及事件的描述和命名機制。這個治理信息結(jié)構(gòu)（SMI）的第一個版本稱為SMIv1，參見STD16,RFC1155,STD16,RFC1212和RFC1215。第二版稱為SMIv2，參見STD58,RFC2578[RFC2578],RFC2579[RFC2579]和RFC2580的描述。
*用于傳輸治理信息的消息協(xié)議。SNMP消息協(xié)議的第一版稱為SNMPv1，由STD15,RFC1157[RFC1157]描述。SNMP消息協(xié)議的第二版——不是一項Internet標準跟蹤協(xié)議——稱為SNMPv2c，由RFC1901[RFC1901]andRFC1906[RFC1906]描述。消息協(xié)議的第三版稱為SNMPv3，由RFC1906[RFC1906],RFC2572[RFC2572]和RFC2574[RFC2574]描述。
*訪問治理信息的協(xié)議操作。采用PDU格式的第一個協(xié)議操作集合由STD15,RFC1157[RFC1157]描述，采用PDU格式的第二個協(xié)議操作集合由RFC1905[RFC1905]描述。
*RFC2573[RFC2573]描述了一系列基礎(chǔ)應(yīng)用，RFC2575[RFC2575]描述了基于視圖的訪問控制機制。

關(guān)于SNMP治理框架的更加具體的描述參見RFC2570[RFC2570]。
通過虛擬信息存儲訪問治理對象稱為治理信息庫或者MIB。MIB的對象使用SMI定義的機制定義。

本備忘錄描述了適應(yīng)SMIv2的MIB模型。通過適當?shù)霓D(zhuǎn)化可以得到遵循SMIv1的MIB。轉(zhuǎn)換后的MIB必須在語義上式等價的，除非不可能轉(zhuǎn)換而不得不忽略的對象及事件（Counter64的使用)。SMIv2的一些機器易讀的信息在轉(zhuǎn)換的過程中必須轉(zhuǎn)化成SMIv1的文本描述。不過這種極其易讀信息的損失不認為是改變了MIB的語義。

2.概述

一個“RTP系統(tǒng)”可能是運行著發(fā)送或者接受RTP數(shù)據(jù)包的應(yīng)用程序的主機終端系統(tǒng)，也可能是轉(zhuǎn)發(fā)RTP包的中介系統(tǒng)。接收方和發(fā)送方通過發(fā)送RTP控制協(xié)議（RTCP）包交換RTP包傳輸和接收的信息[RFC1889]。RTP監(jiān)視器可以在接收方或發(fā)送方上采集發(fā)往或者來自主機/中介系統(tǒng)的RTCP信息。
本文檔中的要害字“必須”、“不能”、“需要”、“應(yīng)”、“不應(yīng)”、“應(yīng)該”、“不應(yīng)該”、“建議”、“可以”和“可選”的含義與RFC2119的解釋一致。

2.1組件

RTPMIB是圍繞著“session”、“Receiver”和“Sender”等抽象概念建立的。

2.1.1按照[RFC1889]節(jié)3的定義，“RTP會話”是“...參與者與RTP通信的連接。每個參與者都有一個會話，會話是由一個特定的目標傳輸?shù)刂穼Χx的（網(wǎng)絡(luò)地址和用于RTP及RTCP的一對端口）。可能所有的參與者使用同一個目標傳輸?shù)刂罚热?a >ip多點傳送的情況；也可能每個參與者都有不同的目標傳輸?shù)刂罚热鐔蝹€的單點傳送地址加上一個通用的端口對。”
2.1.2在RTP會話中“發(fā)送方”表示為一個32位的數(shù)字——“同步資源”或者“SRRC”，根據(jù)[RFC1889]節(jié)3的定義，它是“......RTP數(shù)據(jù)包流的源頭”。
2.1.3如前面2.1.1節(jié)所述，“RTP數(shù)據(jù)包流”的“接收方”可以是單點傳送，也可以是多點傳送的接受者。RTP接收方有對于該會話唯一的SSRC值。如[RFC1889]節(jié)6所述，RTP接收方是RTCP接收方報告的一個來源。

2.2MIB對于RTP系統(tǒng)應(yīng)用的適用性

RTPMIB可用于兩種類型的RTP應(yīng)用：
1、RTP主機系統(tǒng)（終端系統(tǒng)）和RTP監(jiān)視器，參見[RFC1889]節(jié)3；
2、RTPMIB在RTP翻譯器（Translators）和混合器中（Mixers）的應(yīng)用——參見[RFC1889]節(jié)7——還有待于進一步研究。

2.2.1RTP主機系統(tǒng)是可以使用RTPMIB采集主機發(fā)送/接收RTP會話和RTP流數(shù)據(jù)的終端系統(tǒng)，網(wǎng)絡(luò)治理員可以利用這些數(shù)據(jù)——比如在“幫助桌面”中——檢查和診斷RTP會話生命期中出現(xiàn)的故障。

2.2.2多點傳送RTP會話中的RTP監(jiān)視器可以是第三方，也可以放在RTP主機上。RTP監(jiān)視器可以使用RTPMIB采集RTP會話和流的統(tǒng)計數(shù)據(jù)，網(wǎng)絡(luò)治理員可以利用這些數(shù)據(jù)編制網(wǎng)絡(luò)容量計劃或者用于其他的網(wǎng)絡(luò)治理目標。RTP監(jiān)視器可以通過RTPMIB采集數(shù)據(jù)以便網(wǎng)絡(luò)治理員檢查和診斷RTP會話故障或者設(shè)置其操作。

2.2.3許多主機系統(tǒng)需要保留自身收發(fā)數(shù)據(jù)以外的流的記錄。在主機監(jiān)視系統(tǒng)中，主機代理可以利用來自主機的RTP數(shù)據(jù)維護主機發(fā)送流和接收流的數(shù)據(jù)，利用其RTCP數(shù)據(jù)采集會話中其它主機的數(shù)據(jù)。舉例來說，發(fā)送流的主機代理可以利用其RTP系統(tǒng)數(shù)據(jù)維護表rtpSenderTable，但是可能還需要為接收流的對方維護rtpRcvrTable表。要做到這一點，RTP代理必須從流的接收方采集RTCP數(shù)據(jù)構(gòu)造rtpRcvrTable表。主機監(jiān)視器系統(tǒng)必須（MUST）把對象rtpSessionMonitor設(shè)定為“true(1)”，但不一定要接受在其表中創(chuàng)建或者清除行的治理操作。

2.3RTPMIB的結(jié)構(gòu)

在RTPMIB中有6個表。表rtpSessionTable包括描述主機或者監(jiān)視器上的活動會話的對象。表tpSenderTable保存了RTP會話中發(fā)送方的信息。表rtpRcvrTable包含RTP會話數(shù)據(jù)中接收方的信息。表rtpSessionInverseTable、表rtpSenderInverseTable和表rtpRcvrInverseTable分別保存了有效查找rtpSessionTable，rtpSenderTable，和rtpRcvrTable索引的信息。

逆序檢索表(rtpSessionInverseTable，rtpSenderInverseTable，和rtpRcvrInverseTable)是可選的表，用于幫助治理程序有效的訪問其他表中的邏輯行。假如不能從其他方的MIB訪問表索引（rtpSessionTable表的索引rtpSessionIndex、rtpSenderTable的索引rtpSenderssRC、rtpRcvrTable的SSRC對），執(zhí)行MIB的這一方應(yīng)該為多點傳送的RTP會話實現(xiàn)這些表。否則，治理程序就得遍歷巨大的包括會話、發(fā)送方和接收方的樹。

對于一些非凡的RTP會話，對象rtpSessionMonitor標明了是否需要對RTP會話中的遠程的接收方或者發(fā)送方進行監(jiān)視。假如rtpSessionMonitor為真（1），那么會話中的發(fā)送方和接收方都必須在rtpSenderTable和rtpRcvrTable中建立相應(yīng)的條目予以監(jiān)視。RTP代理負責監(jiān)視RTP會話，根據(jù)來自遠程發(fā)送方或者接收方的RTCP報告的信息分別更新相應(yīng)的rtpSenderTable和rtpRcvrTable對象。

RtpSessionNewIndex是一個全局對象，使網(wǎng)絡(luò)治理程序能夠為在rtpSessionTable中創(chuàng)建的邏輯行保持一個索引。這樣就可以使用SNMP的SET操作配置監(jiān)視器。

3.定義

RTP-MIBDEFINITIONS::=BEGIN
IMPORTS
Counter32,Counter64,Gauge32,mib-2,Integer32,MODULE-IDENTITY,
OBJECT-TYPE,Unsigned32FROMSNMPv2-SMI
RowStatus,TAddress,
TDomain,TestAndIncr,
TimeStamp,TruthValueFROMSNMPv2-TC
OBJECT-GROUP,MODULE-COMPLIANCEFROMSNMPv2-CONF
Utf8StringFROMSYSAPPL-MIB
InterfaceIndexFROMIF-MIB;

rtpMIBMODULE-IDENTITY
LAST-UPDATED"200010020000Z"--2000年10月2日
ORGANIZATION
"IETFAVTWorkingGroup
Email:rem-conf@es.net"
CONTACT-INFO
"MarkBaugher
Postal:IntelCorporation
2111NE25thAvenue
Hillsboro,OR97124
UnitedStates
Tel:+15034668406
Email:mbaugher@passedge.com

BillStrahm
Postal:IntelCorporation
2111NE25thAvenue
Hillsboro,OR97124
UnitedStates
Tel:+15032644632
Email:bill.strahm@intel.com

IrinaSUConick
Postal:EnnovateNetworks
60CodmanHillRd.,
Boxboro,Ma01719
Tel:+1781-505-2155
Email:irina@ennovatenetworks.com"

說明
“RTP系統(tǒng)的治理對象。MIB是基于三種類型的信息建立的。
1.RTP會話的通用信息，如會話的地址。
2.關(guān)于某個特定的發(fā)送方發(fā)送到RTP會話的RTP流的信息。
3.關(guān)于某個特定的接收方通過RTP會話從特定的發(fā)送方接收的RTP流的信息。
RTP系統(tǒng)有兩種類型，RTP主機和RTP監(jiān)視器。如后面所講的，特定的對象適用于特定類型的RTP系統(tǒng)。RTP主機也可以像RTP監(jiān)視器一樣運行。定義參見RFC1889“RTP：實時程序的傳輸協(xié)議”第三節(jié)。”
REVISION"200010020000Z"--2October2000
說明“MIB初始版本，公布為RFC2959”"

::={mib-287}

--
--OBJECTS
--
rtpMIBObjectsOBJECTIDENTIFIER::={rtpMIB1}
rtpConformanceOBJECTIDENTIFIER::={rtpMIB2}

--
--新會話索引（SESSIONNEWINDEX）
--
rtpSessionNewIndex對象類型
語法TestAndIncr
最高訪問限制讀寫
狀態(tài)當前
說明
“按照“SMIv2文本約定”的描述，這個對象用來為rtpSessionIndex賦值。對于支持創(chuàng)建行的RTP系統(tǒng)，網(wǎng)絡(luò)治理員可以讀取這個對象，然后使用SET方法回寫創(chuàng)建新的rtpSessionEntry實例。假如SET返回錯誤碼“inconsistentValue”，必須重復(fù)這個過程；假如SET成功，對象就增加了，按照治理員的指示創(chuàng)建了新的實例。但是假如RTP代理不是擔任監(jiān)視器的角色，只有RTP代理能夠在RTP會話表中創(chuàng)建邏輯行。”
::={rtpMIBObjects1}

--
--會話逆序表（SESSIONINVERSETABLE）
--
rtpSessionInverseTable對象類型
語法SEQUENCEOFRtpSessionInverseEntry
最高訪問限制不可訪問
狀態(tài)當前
說明
“把rtpSessionDomain,rtpSessionRemAddr和rtpSessionLocAddrTaddress對映射為一個或多個rtpSessionIndex值，每個值對應(yīng)rtpSessionTable表的一行。這樣不需要遍歷整個（可能是巨大的）rtpSessionTable表，就可以獲得與給定的會話對應(yīng)的一行或者幾行。”
::={rtpMIBObjects2}

rtpSessionInverseEntry對象類型
語法RtpSessionInverseEntry
最高訪問限制不可訪問
狀態(tài)當前
說明
“每個條目與表rtpSessionTable一個確定的條目相對應(yīng)——每個條目包括元組、rtpSessionDomain、rtpSessionRemAddr、rtpSessionLocAddr和rtpSessionIndex。”
INDEX{rtpSessionDomain,rtpSessionRemAddr,rtpSessionLocAddr,
rtpSessionIndex}
::={rtpSessionInverseTable1}
RtpSessionInverseEntry::=SEQUENCE{
rtpSessionInverseStartTimeTimeStamp
}

rtpSessionInverseStartTime對象類型
語法TimeStamp
最高訪問限制只讀
狀態(tài)當前
說明
“本行創(chuàng)建時SysUpTime的值。”
::={rtpSessionInverseEntry1}

--
--會話表（SESSIONTABLE）
--
rtpSessionTable對象類型
語法SEQUENCEOFRtpSessionEntry
最高訪問限制不個訪問
狀態(tài)當前
說明
“每個RTP會話——發(fā)送包、接收包和/或監(jiān)視的會話——在rtpSessionTable表中都有對應(yīng)的條目。”
::={rtpMIBObjects3}

rtpSessionEntry對象類型
語法RtpSessionEntry
最高訪問限制不可訪問
狀態(tài)當前
說明
“rtpSessionTable中的數(shù)據(jù)唯一的標志了一個RTP會話。主機的RTP代理必須為每個發(fā)送包或接收包的會話建立一個只讀的行。RTP代理必須在會話的一開始——在檢測到一個或者多個發(fā)送方/接收方之前——創(chuàng)建行。會話結(jié)束后必須刪除RTP創(chuàng)建的行，不應(yīng)再有這個會話的rtpRcvrEntry和rtpSenderEntry條目。假如rtpSessionMonitor值為真“True（1）”，應(yīng)監(jiān)視會話中所有發(fā)送和接收的RTP流創(chuàng)建治理信息。RTP監(jiān)視器應(yīng)答應(yīng)創(chuàng)建行，這樣做的影響是造成RTP系統(tǒng)加入多點傳送會話以收集治理信息（在rtpRcvrTable和rtpSenderTable表中增加額外的概念行）。因此表rtpSessionTable應(yīng)只包含用于監(jiān)視RTP會話的行，治理程序創(chuàng)建的行應(yīng)通過SNMP操作刪除，治理操作創(chuàng)建的行應(yīng)由治理操作通過把rtpSessionRow的狀態(tài)設(shè)為“destroy(6)”刪除。”
INDEX{rtpSessionIndex}
::={rtpSessionTable1}

RtpSessionEntry::=SEQUENCE{
rtpSessionIndexInteger32,
rtpSessionDomainTDomain,
rtpSessionRemAddrTAddress,
rtpSessionLocAddrTAddress,
rtpSessionIfIndexInterfaceIndex,
rtpSessionSenderJoinsCounter32,
rtpSessionReceiverJoinsCounter32,
rtpSessionByesCounter32,
rtpSessionStartTimeTimeStamp,
rtpSessionMonitorTruthValue,
rtpSessionRowStatusRowStatus
}

rtpSessionIndex對象類型
語法Integer32(1..2147483647)
最高訪問限制不可訪問
狀態(tài)當前
說明
“邏輯行的索引，僅用于SNMP，與任何協(xié)議值無關(guān)。沒有必要繼續(xù)創(chuàng)建或者維護這些行。”
::={rtpSessionEntry1}

rtpSessionDomain對象類型
語法TDomain
最高訪問限制讀/創(chuàng)建
狀態(tài)當前
說明
“該會話發(fā)送或者接受RTP數(shù)據(jù)包流的傳輸層協(xié)議。假如rtpSessionRow處于激活（active）狀態(tài)，不可改變。”
::={rtpSessionEntry2}

rtpSessionRemAddr對象類型
語法TAddress
最高訪問限制讀/創(chuàng)建
狀態(tài)當前
說明
“RTP系統(tǒng)發(fā)送RTP包的目標地址。在IP多點傳送RTP會話中，這是RTP會話數(shù)據(jù)的所有發(fā)送方和接收方使用的唯一地址。在單點傳送RTP會話中，這是遠程RTP系統(tǒng)的單點傳送地址。‘所有的參與者可能共享一個目標地址，比如IP多點傳送的情況；也可能各自具有不同的目標地址，比如單個的單點傳送網(wǎng)絡(luò)地址對’。參見RFC1889[RTP：實時程序的傳輸協(xié)議]第三節(jié)。傳輸服務(wù)由rtpSessionDomain標志。對于snmpUDPDomain，它是一個IP地址和一個偶數(shù)UDP端口，相鄰較大的奇數(shù)端口發(fā)送RTCP，見RFC1889第五節(jié)。”
::={rtpSessionEntry3}

rtpSessionLocAddr對象類型
語法TAddress
最高訪問限制只讀
狀態(tài)當前
說明
“RTP系統(tǒng)使用的本地地址。在IP多點傳送RTP會話中，rtpSessionRemAddr是與rtpSessionLocAddr相同的IP多點傳送地址。在單點傳送RTP會話中，rtpSessionRemAddr和rtpSessionLocAddr具有不同的單點傳送地址。參見RFC1889，‘RTP:實時程序的傳輸協(xié)議’第三節(jié)。傳輸服務(wù)由rtpSessionDomain標志。對于snmpUDPDomain，它是一個IP地址和一個偶數(shù)UDP端口，相鄰較大的奇數(shù)端口發(fā)送RTCP，見RFC1889第五節(jié)。”
::={rtpSessionEntry4}

rtpSessionIfIndex對象類型
語法InterfaceIndex
最高訪問限制讀/創(chuàng)建
狀態(tài)當前
說明
“ifIndex的值被設(shè)為IF-MIB的響應(yīng)值(見RFC2233,‘應(yīng)用SMIv2的界面組（InterfacesGroup）MIB’)。這是RTP流發(fā)送和接收的界面，對于RTP監(jiān)視器則是接收RTCP包的界面。假如rtpSessionRowStatus為‘a(chǎn)ctive’不可修改。”
::={rtpSessionEntry5}

rtpSessionSenderJoins對象類型
語法Counter32
最高訪問限制只讀
狀態(tài)當前
說明
“自本概念行創(chuàng)建（rtpSessionStartTime）起檢測到的參與會話的發(fā)送方的數(shù)目。發(fā)送方通過向會話發(fā)送數(shù)據(jù)參與會話。在RTCPBYE（見RFC1889，‘RTP：實時程序的傳輸協(xié)議’6.6節(jié)）之后中途離開又重新參與的發(fā)送方或者會話超時可能被重復(fù)計數(shù)。只要檢測到新的RTP發(fā)送方，無論使用RTP還是RTCP，這個計數(shù)都會增加。”
::={rtpSessionEntry6}

rtpSessionReceiverJoins對象類型
語法Counter32
最高訪問限制只讀
狀態(tài)當前
說明
“自本概念行創(chuàng)建（rtpSessionStartTime）起檢測到的參與會話的接收方的數(shù)目。接收方通過向會話發(fā)送RTCP接收報告參與會話。在RTCPBYE（見RFC1889，‘RTP：實時程序的傳輸協(xié)議’6.6節(jié)）之后中途離開又重新參與的接收方或者會話超時可能被重復(fù)計數(shù)。”
::={rtpSessionEntry7}

rtpSessionByes對象類型
語法Counter32
最高訪問限制只讀
狀態(tài)當前
說明
“該實體收到的RTCPBYE（見RFC1889，‘RTP：實時程序的傳輸協(xié)議’6.6節(jié)）消息的計數(shù)。”
::={rtpSessionEntry8}

rtpSessionStartTime對象類型
語法TimeStamp
最高訪問限制只讀
狀態(tài)當前
說明
“該行創(chuàng)建時SysUpTime的值。”
::={rtpSessionEntry9}

rtpSessionMonitor對象類型
語法TruthValue
最高訪問限制只讀
狀態(tài)當前
說明
“布爾值，假如除了本地RTP系統(tǒng)之外，還需要使用RTCP監(jiān)視遠程的發(fā)送方或者接收方，將該值設(shè)為真‘true(1)’。RTP監(jiān)視器必須初始化為‘true(1)’，RTP主機則應(yīng)初始化為‘false(2)’。注重，‘主機監(jiān)視器’從遠程伙伴接收RTCP，因此必須把這個值設(shè)為‘true(1)’。”
::={rtpSessionEntry10}

rtpSessionRowStatus對象類型
語法RowStatus
最高訪問限制讀/創(chuàng)建
狀態(tài)當前
說明
“在一個RTP系統(tǒng)發(fā)送/接收RTP或RTCP消息時其值為‘Active’。新建的概念行在其所有讀/創(chuàng)建對象初始化完成之前不會處于激活狀態(tài)‘Active’。處于‘notReady’或者‘notInService’狀態(tài)的概念行可能在5分鐘之后刪除。”
::={rtpSessionEntry11}

--
--發(fā)送方逆序表（SENDERINVERSETABLE）
--
rtpSenderInverseTable對象類型
語法SEQUENCEOFRtpSenderInverseEntry
最高訪問限制不可訪問
狀態(tài)當前
說明
“把rtpSenderAddr和rtpSessionIndex映射成rtpSenderTable表的rtpSenderSSRC索引。該表答應(yīng)治理程序根據(jù)rtpSenderAddr排序而不是根據(jù)rtpSessionIndex排序查找條目。給定了rtpSessionDomain和rtpSenderAddr，可以通過遍歷樹返回一系列的rtpSessionIndex和rtpSenderSSRC值。假如在SNMP的Get-Next操作中指定rtpSessionIndex，可以返回一個或多個rtpSenderSSRC值。”
::={rtpMIBObjects4}

rtpSenderInverseEntry對象類型
語法RtpSenderInverseEntry
最高訪問限制不可訪問
狀態(tài)當前
說明
“每個條目都和rtpSenderTable表中確定的條目相對應(yīng)——條目包含索引對、rtpSessionIndex和rtpSenderSSRC。”
INDEX{rtpSessionDomain,rtpSenderAddr,rtpSessionIndex,
rtpSenderSSRC}
::={rtpSenderInverseTable1}

RtpSenderInverseEntry::=SEQUENCE{
rtpSenderInverseStartTimeTimeStamp
}

rtpSenderInverseStartTime對象類型
語法TimeStamp
最高訪問限制只讀
狀態(tài)當前
說明
“改行創(chuàng)建時SysUpTime的值。“
::={rtpSenderInverseEntry1}

--
--發(fā)送方表（SENDERSTABLE）
--
rtpSenderTable對象類型
語法SEQUENCEOFRtpSenderEntry
最高訪問限制不可訪問
狀態(tài)當前
說明
“保存RTP會話中發(fā)送方的信息的表。必須為每個RTP流的發(fā)送主機在該表中建立相應(yīng)的條目，該表還可能包含這些發(fā)送流的接收方主機的條目。假如rtpSessionTable的一個概念行被治理器（manager）激活（Active），則RTP監(jiān)視器必須為多點傳送會話中的每個檢測到的發(fā)送方建立相應(yīng)的條目。
::={rtpMIBObjects5}

rtpSenderEntry對象類型
語法RtpSenderEntry
最高訪問限制不可訪問
狀態(tài)當前
說明
“每個條目包含一個RTP發(fā)送方同步資源（SSRC，見RFC1889‘RTP：實時程序的傳輸協(xié)議’）的信息。會話作為SNMP實體使用rtpSessionIndex區(qū)分。假如受到來自發(fā)送方的BYE消息，或者發(fā)送方超時（見RFC18896.2.1節(jié)），或者rtpSessionEntity被刪除，RTP代理就刪掉這一行。”
INDEX{rtpSessionIndex,rtpSenderSSRC}
::={rtpSenderTable1}

RtpSenderEntry::=SEQUENCE{
rtpSenderSSRCUnsigned32,
rtpSenderCNAMEUtf8String,
rtpSenderAddrTAddress,
rtpSenderPacketsCounter64,
rtpSenderOctetsCounter64,
rtpSenderToolUtf8String,
rtpSenderSRsCounter32,
rtpSenderSRTimeTimeStamp,
rtpSenderPTINTEGER,
rtpSenderStartTimeTimeStamp
}

rtpSenderSSRC對象類型
語法Unsigned32
最高訪問限制不可訪問
狀態(tài)當前
說明
“RTPSSRC，或者說發(fā)送方的同步資源標識符。RTP會話地址加上SSRC唯一確定了某個RTP會話中的一個發(fā)送方（見RFC1889，‘RTP：實時程序的傳輸協(xié)議’第3節(jié)）。”
::={rtpSenderEntry1}

rtpSenderCNAME對象類型
語法Utf8String
最高訪問限制只讀
狀態(tài)當前
說明
“發(fā)送方的RTP規(guī)范名稱。”
::={rtpSenderEntry2}

rtpSenderAddr對象類型
語法TAddress
最高訪問限制只讀
狀態(tài)當前
說明
“發(fā)送方的單點傳送資源地址，對于RTP監(jiān)視器它是發(fā)送方用來發(fā)送‘RTCP發(fā)送報告’的地址。”
::={rtpSenderEntry3}

rtpSenderPackets對象類型
語法Counter64
最高訪問限制只讀
狀態(tài)當前
說明
“自rtpSenderStartTime起，該發(fā)送方發(fā)出的RTP包的個數(shù)，或者RTP監(jiān)視器監(jiān)測到的RTP包的個數(shù)。”
::={rtpSenderEntry4}

rtpSenderOctets對象類型
語法Counter64
最高訪問限制只讀
狀態(tài)當前
說明
“自rtpSenderStartTime起，該發(fā)送方發(fā)出的非報頭RTP8位字節(jié)數(shù)，或者RTP監(jiān)視器監(jiān)測到的字節(jié)數(shù)”
::={rtpSenderEntry5}

rtpSenderTool對象類型
語法Utf8String(SIZE(0..127))
最高訪問限制只讀
狀態(tài)當前
說明
“流的應(yīng)用程序資源名稱。”
::={rtpSenderEntry6}

rtpSenderSRs對象類型
語法Counter32
最高訪問限制只讀
狀態(tài)當前
說明
“自rtpSenderStartTime起，該發(fā)送方發(fā)出的‘RTCP發(fā)送報告’個數(shù)，假如RTP實體是一個監(jiān)視器就是檢測到的發(fā)送報告數(shù)。”
::={rtpSenderEntry7}

rtpSenderSRTime對象類型
語法TimeStamp
最高訪問限制只讀
狀態(tài)當前
說明
“對于監(jiān)視器或者接收主機而言，rtpSenderSRTime是最后一個SR收到的那一刻SysUpTime的值，對于發(fā)送主機則是發(fā)出最后一個SR的那一刻。”
::={rtpSenderEntry8}

rtpSenderPT對象類型
語法INTEGER(0..127)
最高訪問限制只讀
狀態(tài)當前
說明
“最近收到的RTP包的RTP頭中的有效載荷類型（見RFC1889‘RTP：實時程序的傳輸協(xié)議’）。”
::={rtpSenderEntry9}

rtpSenderStartTime對象類型
語法TimeStamp
最高訪問限制只讀
狀態(tài)當前
說明
“該行創(chuàng)建時SysUpTime的值。”
::={rtpSenderEntry10}

--
--接收方逆序表（RECEIVERINVERSETABLE）
--
rtpRcvrInverseTable對象類型
語法SEQUENCEOFRtpRcvrInverseEntry
最高訪問限制不可訪問
狀態(tài)當前
說明
“把rtpRcvrAddr和rtpSessionIndex映射成rtpRcvrTable的索引表rtpRcvrSRCSSRC和rtpRcvrSSRC。該表答應(yīng)治理程序根據(jù)rtpRcvrAddr排序查找條目，而不是根據(jù)rtpSessionIndex。對于給定的rtpSessionDomain和rtpRcvrAddr，通過遍歷樹可以返回一系列的rtpSessionIndex、rtpRcvrSRCSSRC和rtpRcvrSSRC值。假如在SNMP的Get-Next操作中指定了rtpSessionIndex，則返回一個或多個rtpRcvrSRCSSRC/rtpRcvrSSRC對。”
::={rtpMIBObjects6}

rtpRcvrInverseEntry對象類型
語法RtpRcvrInverseEntry
最高訪問限制不可訪問
狀態(tài)當前
說明
“每一項恰恰與表rtpRcvrTable的一項對應(yīng)，包括索引對、rtpSessionIndex、rtpRcvrSSRC。”
INDEX{rtpSessionDomain,rtpRcvrAddr,rtpSessionIndex,
rtpRcvrSRCSSRC,rtpRcvrSSRC}
::={rtpRcvrInverseTable1}

RtpRcvrInverseEntry::=SEQUENCE{
rtpRcvrInverseStartTimeTimeStamp
}

rtpRcvrInverseStartTime對象類型
語法TimeStamp
最高訪問限制只讀
狀態(tài)當前
說明
“該行創(chuàng)建時SysUpTime的值。”
::={rtpRcvrInverseEntry1}

--
--接收方表（RECEIVERSTABLE）
--
rtpRcvrTable對象類型
語法SEQUENCEOFRtpRcvrEntry
最高訪問限制不可訪問e
狀態(tài)當前
說明
“保存RTP會話數(shù)據(jù)中接收方（可能有多個）信息的表。必須為收/發(fā)對中接收RTP會話包的RTP主機在該表中創(chuàng)建相應(yīng)的條目，使用RTP組的RTCP反饋信息，該表也可以為每個接收方創(chuàng)建相應(yīng)的發(fā)送RTP會話包的主機條目。假如rtpSessionTable的某個概念行被治理器（manager）激活‘Active’，RTP監(jiān)視器就為該會話中每個檢測到的接收方創(chuàng)建相應(yīng)的條目。”
::={rtpMIBObjects7}

rtpRcvrEntry對象類型
語法RtpRcvrEntry
最高訪問限制不可訪問
狀態(tài)當前
說明
“每一項都保存了一個接收包的RTP同步資源的信息，相應(yīng)的發(fā)送方由rtpRcvrSRCSSRC標識（SSRC，見RFC1889，‘RTP：實時程序的傳輸協(xié)議’節(jié)6）。RTP代理實體使用rtpSessionIndex標識會話。假如收到發(fā)送方的BYE消息、或者發(fā)送方超時、或者rtpSessionEntity被刪除，RTP代理將刪除該行。”
INDEX{rtpSessionIndex,rtpRcvrSRCSSRC,rtpRcvrSSRC}
::={rtpRcvrTable1}

RtpRcvrEntry::=SEQUENCE{
rtpRcvrSRCSSRCUnsigned32,
rtpRcvrSSRCUnsigned32,
rtpRcvrCNAMEUtf8String,
rtpRcvrAddrTAddress,
rtpRcvrRTTGauge32,
rtpRcvrLostPacketsCounter64,
rtpRcvrJitterGauge32,
rtpRcvrToolUtf8String,
rtpRcvrRRsCounter32,
rtpRcvrRRTimeTimeStamp,
rtpRcvrPTINTEGER,
rtpRcvrPacketsCounter64,
rtpRcvrOctetsCounter64,
rtpRcvrStartTimeTimeStamp
}

rtpRcvrSRCSSRC對象類型
語法Unsigned32
最高訪問限制不可訪問
狀態(tài)當前
說明
“RTPSSRC，或者說發(fā)送方的同步資源標識符。RTP會話地址加上SSRC唯一確定了某個RTP會話中的一個發(fā)送方（見RFC1889，‘RTP：實時程序的傳輸協(xié)議’第3節(jié)）。”
::={rtpRcvrEntry1}

rtpRcvrSSRC對象類型
語法Unsigned32
最高訪問限制不可訪問
狀態(tài)當前
說明
“RTPSSRC，或者說接收方的同步資源標識符。RTP會話地址加上SSRC唯一確定了某個RTP流中的一個發(fā)送方（見RFC1889，‘RTP：實時程序的傳輸協(xié)議’第3節(jié)）。”
::={rtpRcvrEntry2}

rtpRcvrCNAME對象類型
語法Utf8String
最高訪問限制只讀
狀態(tài)當前
說明
“接收方的RTP規(guī)范名稱。“
::={rtpRcvrEntry3}

rtpRcvrAddr對象類型
語法TAddress
最高訪問限制只讀
狀態(tài)當前
說明
“接收方接收RTP包和/或RTCP接受報告的單點傳送地址。”
::={rtpRcvrEntry4}

rtpRcvrRTT對象類型
語法Gauge32
最高訪問限制只讀
狀態(tài)當前
說明
“基于RFC1889‘RTP：實時程序的傳輸協(xié)議’節(jié)6描述的算法，RTP流的源對往返時間的測度。假如RTP代理和流的發(fā)送方使用相同的時鐘（對于特定的接收方來說RTP監(jiān)視器同時也是發(fā)送主機），該算法能夠產(chǎn)生有意義的結(jié)果。否則，該實體返回‘noSuchInstance’響應(yīng)對rtpRcvrRTT的查詢。”
::={rtpRcvrEntry5}

rtpRcvrLostPackets對象類型
語法Counter64
最高訪問限制只讀
狀態(tài)當前
說明
“自rtpRcvrStartTime起該接收方檢測到的丟失的RTP包的數(shù)量。”
::={rtpRcvrEntry6}

rtpRcvrJitter對象類型
語法Gauge32
最高訪問限制只讀
狀態(tài)當前
說明
“對該接收方檢測到的延遲變化的評估。（見RFC1889,‘RTP:實施程序的傳輸協(xié)議’節(jié)6.3.1及A.8）”
::={rtpRcvrEntry7}

rtpRcvrTool對象類型
語法Utf8String(SIZE(0..127))
最高訪問限制只讀
狀態(tài)當前
說明
“流的應(yīng)用程序資源名稱。”
::={rtpRcvrEntry8}

rtpRcvrRRs對象類型
語法Counter32
最高訪問限制只讀
狀態(tài)當前
說明
“自rtpRcvrStartTime起，該接收方發(fā)出的RTCP接收方報告的數(shù)量，對于RTP監(jiān)視器則是其檢測到的接收方報告數(shù)量。”
::={rtpRcvrEntry9}

rtpRcvrRRTime對象類型
語法TimeStamp
最高訪問限制只讀
狀態(tài)當前
說明
“對于監(jiān)視器或者RR接收方（RTP的發(fā)出者），rtpRcvrRRTime是收到最后一份RTCP接收方報告的那一刻SysUpTime的值。假如是RTP接收方發(fā)送RR的情況，它就是該接收方發(fā)出最后也各RR時SysUpTime的值。”
::={rtpRcvrEntry10}

rtpRcvrPT對象類型
語法INTEGER(0..127)
最高訪問限制只讀
狀態(tài)當前
說明
“RTP頭中動態(tài)或靜態(tài)的有效載荷的類型。（見RFC1889，‘RTP：實時程序的傳輸協(xié)議’節(jié)5）”
::={rtpRcvrEntry11}

rtpRcvrPackets對象類型
語法Counter64
最高訪問限制只讀
狀態(tài)當前
說明
“自rtpRcvrStartTime起，該RTP主機接收方收到的RTP包的數(shù)量。”
::={rtpRcvrEntry12}

rtpRcvrOctets對象類型
語法Counter64
最高訪問限制只讀
狀態(tài)當前
說明
“自rtpRcvrStartTime起，該RTP接收主機收到的非RTP頭的8位字節(jié)數(shù)。”
::={rtpRcvrEntry13}

rtpRcvrStartTime對象類型
語法TimeStamp
最高訪問限制只讀
狀態(tài)當前
說明
“該行創(chuàng)建時SysUpTime的值。”
::={rtpRcvrEntry14}

--
--模型組（ODULEGROUPS）
--
--
--有兩種類型的RTP系統(tǒng)：RTP主機和RTP監(jiān)視器。因而有三種對象：1）適用于兩種系統(tǒng)--的通用對象；2）僅用于RTP主機的對象；3）僅用于RTP監(jiān)視器的對象。另外還有一組，--4）將用于多點傳送主機和RTP監(jiān)視器的對象

rtpGroupsOBJECTIDENTIFIER::={rtpConformance1}
rtpSystemGroupOBJECT-GROUP
OBJECTS{
rtpSessionDomain,
rtpSessionRemAddr,
rtpSessionIfIndex,
rtpSessionSenderJoins,
rtpSessionReceiverJoins,
rtpSessionStartTime,
rtpSessionByes,
rtpSessionMonitor,
rtpSenderCNAME,
rtpSenderAddr,
rtpSenderPackets,
rtpSenderOctets,
rtpSenderTool,
rtpSenderSRs,
rtpSenderSRTime,
rtpSenderStartTime,
rtpRcvrCNAME,
rtpRcvrAddr,
rtpRcvrLostPackets,
rtpRcvrJitter,
rtpRcvrTool,
rtpRcvrRRs,
rtpRcvrRRTime,
rtpRcvrStartTime
}
狀態(tài)當前
說明
“適用于所有RTP系統(tǒng)的對象”
::={rtpGroups1}

rtpHostGroupOBJECT-GROUP
OBJECTS{
rtpSessionLocAddr,
rtpSenderPT,
rtpRcvrPT,
rtpRcvrRTT,
rtpRcvrOctets,
rtpRcvrPackets
}
狀態(tài)當前
說明
“適用于RTP主機系統(tǒng)但可能不是用于RTP監(jiān)視器系統(tǒng)的對象。”
::={rtpGroups2}

rtpMonitorGroupOBJECT-GROUP
OBJECTS{
rtpSessionNewIndex,
rtpSessionRowStatus
}
狀態(tài)當前
說明
“在RTP會話表中創(chuàng)建行的對象，假如系統(tǒng)不創(chuàng)建行則不需要這些對象。”
::={rtpGroups3}

rtpInverseGroupOBJECT-GROUP
OBJECTS{
rtpSessionInverseStartTime,
rtpSenderInverseStartTime,
rtpRcvrInverseStartTime
}
狀態(tài)當前
說明
“用于逆序查找表（InverseLookupTable）的對象。”
::={rtpGroups4}

--
--一致性（Compliance）
--
rtpCompliancesOBJECTIDENTIFIER::={rtpConformance2}

rtpHostComplianceMODULE-COMPLIANCE
狀態(tài)當前
說明
“主機系統(tǒng)必須遵循。”
MODULERTP-MIB
MANDATORY-GROUPS{
rtpSystemGroup,
rtpHostGroup
}
GROUPrtpMonitorGroup
說明
“主機系統(tǒng)可以選擇支持創(chuàng)建和刪除行，從而可以作為RTP監(jiān)視器使用。”
GROUPrtpInverseGroup
說明
“多點傳送RTP系統(tǒng)應(yīng)實現(xiàn)這個可選的表。”
OBJECTrtpSessionNewIndex
最低訪問限制不可訪問
說明
“RTP系統(tǒng)對創(chuàng)建行與刪除行的支持是可選的，因而該對象的實現(xiàn)也是可選的。”
OBJECTrtpSessionDomain
最低訪問限制只讀
說明
“RTP系統(tǒng)對創(chuàng)建行與刪除行的支持是可選的。假如不支持，寫操作也是可選的。“
OBJECTrtpSessionRemAddr
最低訪問限制只讀
說明
“RTP系統(tǒng)對創(chuàng)建行與刪除行的支持是可選的，因而該對象的讀/創(chuàng)建操作也是可選的。”
OBJECTrtpSessionIfIndex
最低訪問限制只讀
說明
“行的創(chuàng)建與刪除是可選的，因而該對象的讀/創(chuàng)建操作也是可選的。”
OBJECTrtpSessionRowStatus
最低訪問限制不可訪問
說明
“行的創(chuàng)建與刪除是可選的，因而該對象的讀/創(chuàng)建操作也是可選的。”
OBJECTrtpSessionInverseStartTime
最低訪問限制不可訪問
說明
“多點傳送RTP系統(tǒng)應(yīng)實現(xiàn)該可選表。”
OBJECTrtpSenderInverseStartTime
最低訪問限制不可訪問
說明
“多點傳送RTP系統(tǒng)應(yīng)實現(xiàn)該可選表。”
OBJECTrtpRcvrInverseStartTime
最低訪問限制不可訪問
說明
“多點傳送RTP系統(tǒng)應(yīng)實現(xiàn)該可選表。”
::={rtpCompliances1}

rtpMonitorComplianceMODULE-COMPLIANCE
狀態(tài)當前
說明
“監(jiān)視器應(yīng)用必須遵循。不要求RTP監(jiān)視器支持創(chuàng)建和刪除。”
MODULERTP-MIB
MANDATORY-GROUPS{
rtpSystemGroup,
rtpMonitorGroup
}
GROUPrtpHostGroup
說明
“監(jiān)視器應(yīng)用可能無法訪問rtpHostGroup的值。”
GROUPrtpInverseGroup
說明
“多點傳送RTP系統(tǒng)應(yīng)實現(xiàn)該可選表。”
OBJECTrtpSessionLocAddr
最低訪問限制不可訪問
說明
“RTP監(jiān)視器追蹤RTP或者RTCP包的來源是可選的，因而該對象的應(yīng)用也是可選的。”
OBJECTrtpRcvrPT
最低訪問限制不可訪問
說明
“RTP監(jiān)視器可能不支持從RTP頭中訪問RTP由載荷類型（僅僅接收RTCP消息）。用于獲取有效載荷類型信息。”
OBJECTrtpSenderPT
最低訪問限制不可訪問
說明
"RTPmonitorsystemsmaynotsupport
retrievaloftheRTPPayloadTypefromtheRTP
header(andmayreceiveRTCPmessagesonly).When
queriedforthepayloadtypeinformation."
OBJECTrtpRcvrOctets
最低訪問限制不可訪問
說明
“RTP監(jiān)視器可能只接收RTCP消息，而不接收包含8位字節(jié)個數(shù)的RTP消息，因而該對象的應(yīng)用是可選的。”
OBJECTrtpRcvrPackets
最低訪問限制不可訪問
說明
“RTP監(jiān)視器可能只接收RTCP消息，而不接收包含8位字節(jié)個數(shù)的RTP消息，因而該對象的應(yīng)用是可選的。”
OBJECTrtpSessionIfIndex
最低訪問限制不可訪問
說明
“行的創(chuàng)建和刪除是可選的，因而該對象的讀/創(chuàng)建訪問也是可選的。”
OBJECTrtpSessionInverseStartTime
最低訪問限制不可訪問
說明
“多點傳送RTP系統(tǒng)應(yīng)實現(xiàn)這個可選的表。”
OBJECTrtpSenderInverseStartTime
最低訪問限制不可訪問
說明
“多點傳送RTP系統(tǒng)應(yīng)實現(xiàn)這個可選的表。”
OBJECTrtpRcvrInverseStartTime
最低訪問限制不可訪問
說明
“多點傳送RTP系統(tǒng)應(yīng)實現(xiàn)這個可選的表。”
::={rtpCompliances2}
END
4.安全考慮（SecurityConsiderations）

大多數(shù)情況下，MIB本身沒有安全性風(fēng)險；假如計劃處理SNMP的安全性，查看系統(tǒng)的信息或者修改系統(tǒng)的某些參數(shù)時，MIB是一個工具而不是一個威脅。不過本MIB定義的治理對象中，由幾個帶有標明讀寫和/或讀-創(chuàng)建的最高訪問限制子句。這些對象可能被認為在某些網(wǎng)絡(luò)環(huán)境下是敏感的或者說輕易受到攻擊。在不安全的、缺乏適當保護的環(huán)境下，對SET操作的支持可能對網(wǎng)絡(luò)操作帶來負面的影響。

本MIB中沒有一個只讀對象會報告密碼，盡管一些SDES[RFC1889]項如CANME——規(guī)范名——可能被認為敏感地依靠于某個特定公司的安全策略。假如沒有適宜的訪問控制策略限制對這些對象的訪問，這些對象可能造成對系統(tǒng)配置信息和系統(tǒng)服務(wù)的攻擊。有些企業(yè)既查看網(wǎng)絡(luò)和系統(tǒng)配置，又瀏覽使用和性能的信息，甚至還有企業(yè)的資產(chǎn)狀況，這樣的企業(yè)可能會希望限制對MIB中大部分對象的SNMP訪問。本MIB支持對rtpSessionNewIndex的讀寫操作，帶來的副作用是在對該項進行寫操作時，需要在表rtpSessionTable中創(chuàng)建相應(yīng)的條目。rtpSessionEntry中有5個對象可以進行讀/創(chuàng)建訪問：rtpSessionDomain、rtpSessionRemAddr、rtpSessionIfIndex、rtpSessionRowStatus、和rtpSessionIfAddr確定了在特定界面上（interface）監(jiān)視的一個RTP會話。這些對象的值一經(jīng)創(chuàng)建就不能改變，對這些對象的初始化僅僅影響對會話的監(jiān)視，而不影響主機終端系統(tǒng)對RTP會話的操作。因為rtpSessionNewIndex的寫操作和rtpSessionEntry中的5個對象影響監(jiān)視器的操作，對這些對象的寫操作應(yīng)該遵從適宜的訪問控制策略。

RTP和RTCP數(shù)據(jù)包的機密性在RTP規(guī)范[RTP1899]中的節(jié)9中定義。可以對RTP包或者RTCP包加密，也可以對二者都加密。對RTCP包加密可能對第三方監(jiān)視器帶來問題，盡管“對于RTCP，答應(yīng)把混合RTCP包分解成兩個低層的包，一個加密而另一個明文發(fā)送。比如，可以把SDES信息加密，而接受報告則以明文發(fā)送以適應(yīng)第三方監(jiān)視器[RFC1889]。”

SNMPv1本身不是一個安全的環(huán)境。即使網(wǎng)絡(luò)本身是可靠的（比如使用了IPSec），仍然沒有這樣的控制，以許可這個安全的網(wǎng)絡(luò)上的某人訪問并讀寫（GET/SET）MIB中的對象。建議應(yīng)用者考慮SNMPv3框架提供的安全特性。非凡推薦使用基于用戶的安全模型[RFC2574]和基于視圖的訪問控制模型[RFC2575]。最后，消費者/用戶有責任保證用于訪問本MIB實例的SNMP實體必須正確設(shè)置，以保證只有那些具有合法權(quán)限的主要用戶才能訪問這些對象并真正地讀取（GET）或設(shè)定（SET）——更新、創(chuàng)建、刪除——這些對象。

5.致謝（Acknowledgements）

筆者感謝BertWijnen和來自ITUSG-16治理計劃的同仁，他們提出了很好的建議。Intel公司的AlanBatie和BillLewis也為RTPMIB作出了巨大的貢獻，他們審閱了多份MIB草案并致力于SNMPRTP監(jiān)視器的實現(xiàn)。3Com的StanNaudus和Intel的JohnDu為RTPMIB的最初設(shè)計作出了貢獻，他們也參與了RTPMIB最初草案的寫作；他們的工作仍然體現(xiàn)在現(xiàn)在的RTPMIB版本中。BillFenner為最終文本的完善提供了極好的資料。

6.知識產(chǎn)權(quán)（IntellectualProperty）

TheIETFtakesnopositionregardingthevalidityorscopeofany
intellectualpropertyorotherrightsthatmightbeclaimedto
pertaintotheimplementationoruSEOfthetechnologydescribedin
thisdocumentortheextenttowhichanylicenseundersuchrights
mightormightnotbeavailable;neitherdoesitrepresentthatit
hasmadeanyefforttoidentifyanysuchrights.Informationonthe
IETF'sprocedureswithrespecttorightsinstandards-trackand
standards-relateddocumentationcanbefoundinBCP-11.Copiesof
claimsofrightsmadeavailableforpublicationandanyassurancesof
licensestobemadeavailable,ortheresultofanattemptmadeto
oBTainagenerallicenseorpermissionfortheuseofsuch
proprietaryrightsbyimplementorsorusersofthisspecificationcan
beobtainedfromtheIETFSecretariat.

TheIETFinvitesanyinterestedpartytobringtoitsattentionany
copyrights,patentsorpatentapplications,orotherproprietary
rightswhichmaycovertechnologythatmayberequiredtopractice
thisstandard.PleaseaddresstheinformationtotheIETFExecutive
Director.
7.引用（References）

[RFC1889]Shulzrinne,H.,Casner,S.,Frederick,R.andV.
Jacobson,"RTP:ATransportProtocolforreal-time
applications,"RFC1889,January1996.

[RFC2571]Harrington,D.,Presuhn,R.andB.Wijnen,"An
ArchitectureforDescribingSNMPManagementFrameworks",
RFC2571,April1999.

[RFC1155]Rose,M.andK.McCloghrie,"StructureandIdentification
ofManagementInformationforTCP/IP-basedInternets",
STD16,RFC1155,May1990.

[RFC1212]Rose,M.andK.McCloghrie,"ConciseMIBDefinitions",
STD16,RFC1212,March1991.

[RFC1215]Rose,M.,"AConventionforDefiningTrapsforusewith
theSNMP",RFC1215,March1991.

[RFC2578]McCloghrie,K.,Perkins,D.,Schoenwaelder,J.,Case,J.,
Rose,M.andS.Waldbusser,"StructureofManagement
InformationVersion2(SMIv2)",STD58,RFC2578,April
1999.

[RFC2579]McCloghrie,K.,Perkins,D.,Schoenwaelder,J.,Case,J.,
Rose,M.andS.Waldbusser,"TextualConventionsfor
SMIv2",STD58,RFC2579,April1999.

[RFC2580]McCloghrie,K.,Perkins,D.,Schoenwaelder,J.,Case,J.,
Rose,M.andS.Waldbusser,"ConformanceStatementsfor
SMIv2",STD58,RFC2580,April1999.

[RFC1157]Case,J.,Fedor,M.,Schoffstall,M.andJ.Davin,
"SimpleNetworkManagementProtocol",STD15,RFC1157,
May1990.

[RFC1901]Case,J.,McCloghrie,K.,Rose,M.andS.Waldbusser,
"IntroductiontoCommunity-basedSNMPv2",RFC1901,
January1996.

[RFC1906]Case,J.,McCloghrie,K.,Rose,M.andS.Waldbusser,
"TransportMappingsforVersion2oftheSimpleNetwork
ManagementProtocol(SNMPv2)",RFC1906,January1996.
[RFC2572]Case,J.,HarringtonD.,PresuhnR.andB.Wijnen,
"MessageProcessingandDispatchingfortheSimple
NetworkManagementProtocol(SNMP)",RFC2572,April
1999.

[RFC2574]Blumenthal,U.andB.Wijnen,"User-basedSecurityModel
(USM)forversion3oftheSimpleNetworkManagement
Protocol(SNMPv3)",RFC2574,April1999.

[RFC1905]Case,J.,McCloghrie,K.,Rose,M.andS.Waldbusser,
"ProtocolOperationsforVersion2oftheSimpleNetwork
ManagementProtocol(SNMPv2)",RFC1905,January1996.

[RFC2573]Levi,D.,Meyer,P.andB.Stewart,"SNMPv3
Applications",RFC2573,April1999.

[RFC2575]Wijnen,B.,Presuhn,R.andK.McCloghrie,"View-based
accessControlModel(VACM)fortheSimpleNetwork
ManagementProtocol(SNMP)",RFC2575,April1999.

[RFC2570]Case,J.,Mundy,R.,Partain,D.andB.Stewart,
"IntroductiontoVersion3oftheInternet-standard
Network
ManagementFramework",RFC2570,April1999.

8.作者地址（Authors'Addresses）

MarkBaugher
IntelCorporation
2111N.E.25thAvenue
Hillsboro,Oregon97124
U.S.A.

EMail:mbaugher@passedge.com


BillStrahm
IntelCorporation
2111N.E.25thAvenue
Hillsboro,Oregon97124
U.S.A.

EMail:Bill.Strahm@intel.com


IrinaSuconick
EnnovateNetworks
60CodmanHillRd.,
Boxboro,Ma01719
U.S.A.

EMail:irina@ennovatenetworks.com

9.版權(quán)聲明

Copyright(C)TheInternetSociety(2000).AllRightsReserved.

Thisdocumentandtranslationsofitmaybecopiedandfurnishedto
others,andderivativeworksthatcommentonorotherwiseeXPlainit
orassistinitsimplementationmaybeprepared,copied,published
anddistributed,inwholeorinpart,withoutrestrictionofany
kind,providedthattheabovecopyrightnoticeandthisparagraphare
includedonallsuchcopiesandderivativeworks.However,this
documentitselfmaynotbemodifiedinanyway,suchasbyremoving
thecopyrightnoticeorreferencestotheInternetSocietyorother
Internetorganizations,exceptasneededforthepurposeof
developingInternetstandardsinwhichcasetheproceduresfor
copyrightsdefinedintheInternetStandardsprocessmustbe
followed,orasrequiredtotranslateitintolanguagesotherthan
English.

Thelimitedpermissionsgrantedaboveareperpetualandwillnotbe
revokedbytheInternetSocietyoritssuccessorsorassigns.

Thisdocumentandtheinformationcontainedhereinisprovidedonan
"ASIS"basisandTHEINTERNETSOCIETYANDTHEINTERNETENGINEERING
TASKFORCEDISCLAIMSALLWARRANTIES,EXPRESSORIMPLIED,INCLUDING
BUTNOTLIMITEDTOANYWARRANTYTHATTHEUSEOFTHEINFORMATION
HEREINWILLNOTINFRINGEANYRIGHTSORANYIMPLIEDWARRANTIESOF
MERCHANTABILITYORFITNESSFORAPARTICULARPURPOSE.

感謝

FundingfortheRFCEditorfunctioniscurrentlyprovidedbythe
InternetSociety.