📄 rfc2959.txt
字号:
组织:中国互动出版网(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)
译文发布时间:2001-4-20
版权:本中文翻译文档版权归中国互动出版网所有。可以用于非商业用途自由转载,但必须保留本文档的翻译及版权信息。
Network Working Group M. Baugher
Request for Comments: 2959 B. Strahm
Category: Standards Track Intel Corp.
I. Suconick
VideoServer Corp.
October 2000
实时传输协议管理信息库
(RFC2959 Real-Time Transport Protocol Management Information Base)
本备忘录状态
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社区中用于网络管理协议的管理信息库(MIB)的一部分,特别是定义了管理实时传输协议(RTP)系统(RFC1889)的对象。
目录
1. SNMP管理框架 2
2. 概述 3
2.1 组件 3
2.2 MIB对于RTP系统应用的适用性 3
2.3 RTP MIB的结构 4
3. 定义 5
4. 安全考虑(Security Considerations) 24
5. 致谢(Acknowledgements) 25
6. 知识产权(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的描述。
* 用于传输管理信息的消息协议。SNMP消息协议的第一版称为SNMPv1,由STD 15, RFC 1157 [RFC1157]描述。SNMP消息协议的第二版——不是一项Internet标准跟踪协议——称为SNMPv2c,由RFC 1901 [RFC1901] and RFC 1906 [RFC1906]描述。消息协议的第三版称为SNMPv3,由RFC 1906[RFC1906], RFC 2572 [RFC2572]和 RFC 2574 [RFC2574]描述。
* 访问管理信息的协议操作。采用PDU格式的第一个协议操作集合由STD 15, RFC 1157 [RFC1157]描述,采用PDU格式的第二个协议操作集合由RFC 1905 [RFC1905]描述。
* RFC 2573 [RFC2573]描述了一系列基础应用,RFC 2575 [RFC2575]描述了基于视图的访问控制机制。
关于SNMP管理框架的更加详细的描述参见RFC 2570 [RFC2570]。
通过虚拟信息存储访问管理对象称为管理信息库或者MIB。MIB的对象使用SMI定义的机制定义。
本备忘录描述了适应SMIv2的MIB模型。通过适当的转化可以得到遵循SMIv1的MIB。转换后的MIB必须在语义上式等价的,除非不可能转换而不得不忽略的对象及事件(Counter64的使用)。 SMIv2的一些机器易读的信息在转换的过程中必须转化成SMIv1的文本描述。不过这种极其易读信息的损失不认为是改变了MIB的语义。
2. 概述
一个“RTP系统”可能是运行着发送或者接受RTP数据包的应用程序的主机终端系统,也可能是转发RTP包的中介系统。接收方和发送方通过发送RTP控制协议(RTCP)包交换RTP包传输和接收的信息 [RFC1889]。RTP监视器可以在接收方或发送方上采集发往或者来自主机/中介系统的RTCP信息。
本文档中的关键字“必须”、 “不能”、“需要”、“应”、“不应”、“应该”、“不应该”、“建议”、“可以”和“可选”的含义与RFC 2119的解释一致。
2.1 组件
RTP MIB是围绕着“Session”、“Receiver”和“Sender”等抽象概念建立的。
2.1.1 按照[RFC1889]节3的定义,“RTP会话”是“...参与者与RTP通信的连接。每个参与者都有一个会话,会话是由一个特定的目标传输地址对定义的(网络地址和用于RTP及RTCP的一对端口)。可能所有的参与者使用同一个目标传输地址,比如IP多点传送的情况;也可能每个参与者都有不同的目标传输地址,比如单个的单点传送地址加上一个通用的端口对。”
2.1.2 在RTP会话中“发送方”表示为一个32位的数字——“同步资源”或者“SRRC”,根据[RFC1889]节3的定义,它是“......RTP数据包流的源头”。
2.1.3 如前面2.1.1节所述,“RTP数据包流”的“接收方”可以是单点传送,也可以是多点传送的接受者。RTP接收方有对于该会话唯一的SSRC值。如[RFC1889]节6所述,RTP接收方是RTCP接收方报告的一个来源。
2.2 MIB对于RTP系统应用的适用性
RTP MIB可用于两种类型的RTP应用:
1、 RTP主机系统(终端系统)和RTP监视器,参见[RFC1889]节3;
2、 RTP MIB在RTP翻译器(Translators)和混合器中(Mixers)的应用——参见[RFC1889]节7——还有待于进一步研究。
2.2.1 RTP主机系统是可以使用RTP MIB采集主机发送/接收RTP会话和RTP流数据的终端系统,网络管理员可以利用这些数据——比如在“帮助桌面”中——检查和诊断RTP会话生命期中出现的故障。
2.2.2 多点传送RTP会话中的RTP监视器可以是第三方,也可以放在RTP主机上。RTP监视器可以使用RTP MIB采集RTP会话和流的统计数据,网络管理员可以利用这些数据编制网络容量计划或者用于其他的网络管理目标。RTP监视器可以通过RTP MIB采集数据以便网络管理员检查和诊断RTP会话故障或者设置其操作。
2.2.3 许多主机系统需要保留自身收发数据以外的流的记录。在主机监视系统中,主机代理可以利用来自主机的RTP数据维护主机发送流和接收流的数据,利用其RTCP数据采集会话中其它主机的数据。举例来说,发送流的主机代理可以利用其RTP系统数据维护表rtpSenderTable,但是可能还需要为接收流的对方维护rtpRcvrTable表。要做到这一点,RTP代理必须从流的接收方采集RTCP数据构造rtpRcvrTable表。主机监视器系统必须(MUST)把对象rtpSessionMonitor设定为“true(1)”,但不一定要接受在其表中创建或者清除行的管理操作。
2.3 RTP MIB的结构
在RTP MIB中有6个表。表rtpSessionTable包括描述主机或者监视器上的活动会话的对象。 表tpSenderTable保存了RTP会话中发送方的信息。表rtpRcvrTable包含RTP会话数据中接收方的信息。表rtpSessionInverseTable、 表rtpSenderInverseTable和表 rtpRcvrInverseTable分别保存了有效查找rtpSessionTable, rtpSenderTable,和 rtpRcvrTable索引的信息 。
逆序检索表(rtpSessionInverseTable,rtpSenderInverseTable,和 rtpRcvrInverseTable) 是可选的表,用于帮助管理程序有效的访问其他表中的逻辑行。如果不能从其他方的MIB访问表索引(rtpSessionTable表的索引rtpSessionIndex、rtpSenderTable的索引rtpSenderSSRC、rtpRcvrTable的SSRC对),执行MIB的这一方应该为多点传送的RTP会话实现这些表。否则,管理程序就得遍历巨大的包括会话、发送方和接收方的树。
对于一些特殊的RTP会话,对象rtpSessionMonitor标明了是否需要对RTP会话中的远程的接收方或者发送方进行监视。如果rtpSessionMonitor为真(1),那么会话中的发送方和接收方都必须在rtpSenderTable和rtpRcvrTable中建立相应的条目予以监视。RTP代理负责监视RTP会话,根据来自远程发送方或者接收方的RTCP报告的信息分别更新相应的 rtpSenderTable和rtpRcvrTable对象。
RtpSessionNewIndex是一个全局对象,使网络管理程序能够为在rtpSessionTable中创建的逻辑行保持一个索引。 这样就可以使用SNMP的SET操作配置监视器。
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系统的管理对象。MIB是基于三种类型的信息建立的。
1. RTP会话的通用信息,如会话的地址。
2. 关于某个特定的发送方发送到RTP会话的RTP流的信息。
3. 关于某个特定的接收方通过RTP会话从特定的发送方接收的RTP流的信息。
RTP系统有两种类型,RTP主机和RTP监视器。如后面所讲的,特定的对象适用于特定类型的RTP系统。RTP主机也可以像RTP监视器一样运行。定义参见RFC 1889“RTP:实时程序的传输协议”第三节。 ”
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
最高访问限制 读写
状态 当前
说明
“按照“SMIv2文本约定”的描述,这个对象用来为rtpSessionIndex赋值。 对于支持创建行的RTP系统,网络管理员可以读取这个对象,然后使用SET方法回写创建新的rtpSessionEntry实例。如果SET返回错误码“inconsistentValue”,必须重复这个过程;如果SET成功,对象就增加了,按照管理员的指示创建了新的实例。但是如果RTP代理不是担任监视器的角色,只有RTP代理能够在RTP会话表中创建逻辑行。”
::= { rtpMIBObjects 1 }
--
-- 会话逆序表(SESSION INVERSE TABLE)
--
rtpSessionInverseTable 对象类型
语法 SEQUENCE OF RtpSessionInverseEntry
最高访问限制 不可访问
状态 当前
说明
“把rtpSessionDomain, rtpSessionRemAddr和rtpSessionLocAddr Taddress对映射为一个或多个rtpSessionIndex值,每个值对应rtpSessionTable表的一行。这样不需要遍历整个(可能是巨大的)rtpSessionTable表,就可以获得与给定的会话对应的一行或者几行。”
::= { rtpMIBObjects 2 }
rtpSessionInverseEntry 对象类型
语法 RtpSessionInverseEntry
最高访问限制 不可访问
状态 当前
说明
“每个条目与表rtpSessionTable一个确定的条目相对应——每个条目包括元组、 rtpSessionDomain、 rtpSessionRemAddr、 rtpSessionLocAddr和 rtpSessionIndex。”
INDEX { rtpSessionDomain, rtpSessionRemAddr, rtpSessionLocAddr,
rtpSessionIndex }
::= { rtpSessionInverseTable 1 }
RtpSessionInverseEntry ::= SEQUENCE {
rtpSessionInverseStartTime TimeStamp
}
rtpSessionInverseStartTime 对象类型
语法 TimeStamp
最高访问限制 只读
状态 当前
说明
“本行创建时SysUpTime的值 。”
::= { rtpSessionInverseEntry 1 }
--
-- 会话表(SESSION TABLE)
--
rtpSessionTable 对象类型
语法 SEQUENCE OF RtpSessionEntry
最高访问限制 不个访问
状态 当前
说明
“每个RTP会话——发送包、接收包和/或监视的会话——在rtpSessionTable表中都有对应的条目。”
::= { rtpMIBObjects 3 }
rtpSessionEntry 对象类型
语法 RtpSessionEntry
最高访问限制 不可访问
状态 当前
说明
“rtpSessionTable中的数据唯一的标志了一个RTP会话。主机的RTP代理必须为每个发送包或接收包的会话建立一个只读的行。RTP代理必须在会话的一开始——在检测到一个或者多个发送方/接收方之前——创建行。会话结束后必须删除RTP创建的行,不应再有这个会话的rtpRcvrEntry和rtpSenderEntry条目。如果rtpSessionMonitor值为真“True(1)”,应监视会话中所有发送和接收的RTP流创建管理信息。RTP监视器应允许创建行,这样做的影响是造成RTP系统加入多点传送会话以收集管理信息(在rtpRcvrTable和rtpSenderTable表中增加额外的概念行)。因此表rtpSessionTable应只包含用于监视RTP会话的行,管理程序创建的行应通过SNMP操作删除,管理操作创建的行应由管理操作通过把rtpSessionRow的状态设为“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)
最高访问限制 不可访问
状态 当前
说明
“逻辑行的索引,仅用于SNMP,与任何协议值无关。没有必要继续创建或者维护这些行。”
::= { rtpSessionEntry 1 }
rtpSessionDomain 对象类型
语法 TDomain
最高访问限制 读/创建
状态 当前
说明
“该会话发送或者接受RTP数据包流的传输层协议。如果rtpSessionRow处于激活(active)状态,不可改变。”
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -