組織：中國互動出版網(wǎng)（http://www.china-pub.com/）
RFC文檔中文翻譯計劃（http://www.china-pub.com/compters/emook/aboutemook.htm）
E-mail：ouyang@china-pub.com
譯者：王安鵬（anpengwang  anpengwnag@263.net）
譯文發(fā)布時間：2001-4-20
版權：本中文翻譯文檔版權歸中國互動出版網(wǎng)所有。可以用于非商業(yè)用途自由轉(zhuǎn)載，但必須保留本文檔的翻譯及版權信息。


Network Working Group                                        M. Baugher
Request for Comments: 2959                                    B. Strahm
Category: Standards Track                                   Intel Corp.
                                                            I. Suconick
                                                      VideoServer Corp.
                                                           October 2000


實時傳輸協(xié)議管理信息庫
(RFC2959 Real-Time Transport Protocol Management Information Base)

本備忘錄狀態(tài)
   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

版權聲明
Copyright (C) The Internet Society (2001).

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












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


1.  SNMP管理框架
* SNMP管理框架目前包括五個主要的組成部分：
* 總體框架，參見RFC 2571[RFC2571]的敘述。
* 用于管理目的的對象及事件的描述和命名機制。這個管理信息結構（SMI）的第一個版本稱為SMIv1，參見STD 16, RFC 1155, STD 16, RFC 1212和RFC 1215。第二版稱為SMIv2，參見STD 58, RFC 2578 [RFC2578], RFC 2579 [RFC2579] 和RFC 2580的描述。
* 用于傳輸管理信息的消息協(xié)議。SNMP消息協(xié)議的第一版稱為SNMPv1，由STD 15,   RFC 1157 [RFC1157]描述。SNMP消息協(xié)議的第二版——不是一項Internet標準跟蹤協(xié)議——稱為SNMPv2c，由RFC 1901 [RFC1901] and RFC 1906 [RFC1906]描述。消息協(xié)議的第三版稱為SNMPv3，由RFC 1906[RFC1906], RFC 2572 [RFC2572]和 RFC 2574 [RFC2574]描述。
* 訪問管理信息的協(xié)議操作。采用PDU格式的第一個協(xié)議操作集合由STD 15, RFC 1157 [RFC1157]描述，采用PDU格式的第二個協(xié)議操作集合由RFC 1905 [RFC1905]描述。
* RFC 2573 [RFC2573]描述了一系列基礎應用，RFC 2575 [RFC2575]描述了基于視圖的訪問控制機制。

關于SNMP管理框架的更加詳細的描述參見RFC 2570 [RFC2570]。  
通過虛擬信息存儲訪問管理對象稱為管理信息庫或者MIB。MIB的對象使用SMI定義的機制定義。

本備忘錄描述了適應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ù)包的應用程序的主機終端系統(tǒng)，也可能是轉(zhuǎn)發(fā)RTP包的中介系統(tǒng)。接收方和發(fā)送方通過發(fā)送RTP控制協(xié)議（RTCP）包交換RTP包傳輸和接收的信息 [RFC1889]。RTP監(jiān)視器可以在接收方或發(fā)送方上采集發(fā)往或者來自主機/中介系統(tǒng)的RTCP信息。
本文檔中的關鍵字“必須”、 “不能”、“需要”、“應”、“不應”、“應該”、“不應該”、“建議”、“可以”和“可選”的含義與RFC 2119的解釋一致。

2.1 組件

   RTP MIB是圍繞著“Session”、“Receiver”和“Sender”等抽象概念建立的。

   2.1.1  按照[RFC1889]節(jié)3的定義，“RTP會話”是“...參與者與RTP通信的連接。每個參與者都有一個會話，會話是由一個特定的目標傳輸?shù)刂穼Χx的（網(wǎng)絡地址和用于RTP及RTCP的一對端口）。可能所有的參與者使用同一個目標傳輸?shù)刂罚热鏘P多點傳送的情況；也可能每個參與者都有不同的目標傳輸?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.2 MIB對于RTP系統(tǒng)應用的適用性

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

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

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

   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ù)構造rtpRcvrTable表。主機監(jiān)視器系統(tǒng)必須（MUST）把對象rtpSessionMonitor設定為“true(1)”，但不一定要接受在其表中創(chuàng)建或者清除行的管理操作。

2.3  RTP MIB的結構

在RTP MIB中有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的這一方應該為多點傳送的RTP會話實現(xiàn)這些表。否則，管理程序就得遍歷巨大的包括會話、發(fā)送方和接收方的樹。  

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

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

3. 定義

RTP-MIB DEFINITIONS ::= BEGIN
IMPORTS
       Counter32, Counter64, Gauge32, mib-2, Integer32, MODULE-IDENTITY,
       OBJECT-TYPE, Unsigned32                     FROM SNMPv2-SMI
       RowStatus, TAddress,
       TDomain, TestAndIncr,
       TimeStamp, TruthValue                       FROM SNMPv2-TC
       OBJECT-GROUP, MODULE-COMPLIANCE             FROM SNMPv2-CONF
       Utf8String                                  FROM SYSAPPL-MIB
       InterfaceIndex                              FROM IF-MIB;

rtpMIB MODULE-IDENTITY
    LAST-UPDATED "200010020000Z"  -- 2000年10月2日
    ORGANIZATION
                 "IETF AVT Working Group
    Email:   rem-conf@es.net"
    CONTACT-INFO
            "Mark Baugher
    Postal: Intel Corporation
            2111 NE 25th Avenue
            Hillsboro, OR   97124
            United States
    Tel:    +1 503 466 8406
    Email:  mbaugher@passedge.com

            Bill Strahm
    Postal: Intel Corporation
            2111 NE 25th Avenue
            Hillsboro, OR   97124
            United States
    Tel:    +1 503 264 4632
    Email:  bill.strahm@intel.com

            Irina Suconick
    Postal: Ennovate Networks
            60 Codman Hill Rd.,
            Boxboro, Ma 01719
    Tel:    +1 781-505-2155
    Email:  irina@ennovatenetworks.com"

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

::= { mib-2 87 }

--
-- OBJECTS
--
rtpMIBObjects OBJECT IDENTIFIER ::= { rtpMIB 1 }
rtpConformance OBJECT IDENTIFIER ::= { rtpMIB 2 }

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

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

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

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

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

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

RtpSessionEntry ::= SEQUENCE {
        rtpSessionIndex         Integer32,
        rtpSessionDomain        TDomain,
        rtpSessionRemAddr       TAddress,
        rtpSessionLocAddr       TAddress,
        rtpSessionIfIndex       InterfaceIndex,
        rtpSessionSenderJoins   Counter32,
        rtpSessionReceiverJoins Counter32,
        rtpSessionByes          Counter32,
        rtpSessionStartTime     TimeStamp,
        rtpSessionMonitor       TruthValue,
        rtpSessionRowStatus     RowStatus
        }

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

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