rfcrfc2669.txt

本程序为在linux下实现FTP传输文件的实现

组织：中国互动出版网（http://www.china-pub.com/）
RFC文档中文翻译计划（http://www.china-pub.com/compters/emook/aboutemook.htm）
E-mail：[e-mail]
译者：Careon（careon muzi   [e-mail]）
译文发布时间：2001-12-28
版权：本中文翻译文档版权归中国互动出版网所有。可以用于非商业用途自由转载，但必须
保留本文档的翻译及版权信息。



Network Working Group                                   M. St. Johns, Ed.
Request for Comments: 2669                                 @Home Network
Category: Proposed Standard                                  August 1999              

基于DOCSIS标准CM和CMTS的电缆设备 MIB库定义
（RFC2669 ——DOCSIS Cable Device MIB Cable Device Management Information 
Base for DOCSIS compliant Cable Modems and Cable Modem Termination Systems） 


本备忘录的状态
本文档讲述了一种Internet社区的Internet标准跟踪协议，它需要进一步进行讨论和建
议以得到改进。请参考最新版的“Internet正式协议标准” (STD1)来获得本协议的标准化
程度和状态。本备忘录的发布不受任何限制。
版权声明
Copyright (C) The Internet Society (1999).

摘要
本文档为在Internet设区中所使用的网络管理协议定义了部分管理信息库（MIB），
具体为基于DOCSIS1.0标准的兼容CM和CMTS定义了基本管理对象集，该管理方
法基于SNMP协议。
本文档所定义的MIB模块符合SNMP SMIv2 [5][6][7]标准描述方法，所使用的
SNMP框架结构和现有SNMP标准保持一致。
目录
1.  SNMP管理架构	2
2. 术语	2
2.1. 有线电视（CATV）	3
2.2. 电缆调制解调器（CM）	3
	2.3 电缆调制解调器前端系统（CMTS）………………………………………………….
	2.4 DOCSIS………………………………………………………………………………..
	2.5 下行传输………………………………………………………………………………….
	2.6 前端……………………………………………………………………………………..
	2.7 MAC包……………………………………………………………………………………
	2.8 电缆多媒体网络系统……………………………………………………………………
	2.9 射频………………………………………………………………………………………..
	2.10上行传输…………………………………………………………………………………
3. 概览	4
	3.1 管理信息库结构………………………………………………………………………….
	3.2 管理要求……………………………………………………………………………….
	3.2.1 软件升级…………………..
	3.2.2 事件和陷阱………………..
	3.2.3 Trap限制……………………………………………………………………………….
	3.2.3 .1 Trap速率级别…………………………………………………………………………
	3.2.3.2 限制Trap速率…………………………………………………………………………
	3.3 协议过滤…………………………………………………………………………………
	3.3.1入内的链路层包过滤（LLC filter）…………………………………………………….
	3.3.2 专有过滤………………………………………………………………………………
	3.3.2.1 IP盗用过滤……………………………………………………………………………..
	3.3.2.2 SNMP访问过滤……………………………………………………………………….
	3.3.3 IP包过滤………………………………………………………………………………..
	3.3.4 出外的链路层过滤(LLC filter)……………………………………………………….
	4 定义…………………………………………………………………………………………
	5 鸣谢…………………………………………………………………………………………
	6 参考…………………………………………………………………………………………
	7 安全事项…………………………………………………………………………………….
	8 知识产权……………………………………………………………………………………
	9 作者地址…………………………………………………………………………………….
	10 版权声明………………………………………………………………………………….


1.  SNMP管理架构
SNMP当前的管理架构可从五个方面来描述。
0	总体结构描述，可参照 RFC2571[1]。
0	网络管理目标和MIB对象的命名和描述。
0	传输管理信息所需消息协议描述。
0	访问管理信息的协议操作
0	   基本应用集描述和网络管理访问控制机制
2. 术语
本节既讨论了 IETF 协议指定的一般性术语，也讨论了本文档要用到的一些术语。 
2.1.  有线电视（CATV）
最初称为公用天线电视系统，现在不管是普通的电缆系统或是HFC系统都可以统
称为CATV系统
2.2. 电缆调制解调器（Cable Modem）
在DOCSIS兼容电缆数据传输系中被称为"slave"的调制解调器。
2.3 电缆调制解调器终端系统（CMTS）
	工作在头端的覆盖电缆桥接或电缆路由的一般性术语，CMTS在DOCSIS电容电缆数据
传输系统中一般作为主设备（master），而且它是唯一的传输下行和控制上行传输的设备。
2.4 DOCSIS
	基于Cable的数据传输接口规范，可参考 ITU-T J.112 Annex B。
2.5 下行（Downstream）
	从头端（CMTS）传向用户端的方向称为下行。
2.6 头端
	用户端数据的发源地，一般指CMTS设备的所在位置。
2.7 MAC包
	符合DOCSIS标准的数据单元。
2.8 MCNS
	多媒体电缆网络系统，一般被DOCSIS来代替表示。
2.9 射频
	表示射频信号。
2.10 上行
	从用户端传输到头端的方向称为上行。
3概览
	本MIB库提供了满足DOCSIS兼容CableModem和CMTS的管理需求的管理子集，该
管理需求来源于DOCSIS射频接口规范标准（DOCSIS Radio Frequency Interface 
specification）。需要留意的是DOCSIS1.0标准仅仅要求CableModem实现SnmpV1和处理
IPv4的通信数据，未来的DOCSIS版本将会支持SnmpV3和Ipv6。 
3.1 MIB结构
	本MIB结构被划分为七个组（groups）：
0	Cable设备系统管理组docsDevBase
0	网络访问控制组docsDevNmAccessGroup
0	软件升级所需信息处理组docsDevSoftware
0	事件报告控制和记录组docsDevEvent
0	链路层和IP层过滤器配置组docsDevFilter
0	客户端设备IP控制组docsDevCpe
3.2管理要求
3.2.1 软件升级处理
	CableModem的软件升级处理可以通过DOCSIS射频接口规范标准中描述的方法进行操
作，作为网络管理者可以通过下列步骤升级CableModem：
0	设置docsDevSwServer为软件升级TFTP服务器的IP地址
0	设置docsDevSwFilename为软件升级映像文件的文件名
0	设置docsDevSwAdminiStatus为upgrade-from-mgt
注意软件升级在下列情况下应禁止：
0	软件升级文件未完全下载
0	软件升级文件内容不完整或已被破坏
0	软件升级文件并不是针对本设备的硬件标识
3.2.2 事件和Traps
	本MIB库为系统事件的报告提供了灵活的控制机制，包括在日志服务器（syslog）、Traps、
非易失性本地记录等。如果事件通过Traps报告应符合相应的规范。其他非Traps事件报告
的机制本文不加论述。
	Trap事件报告的定义和编码规则可以有厂商自定义。不过为了多厂家设备的通用性考
虑，各厂家CableModem应当提供TOD（Time of day）时钟以便于网络故障的检修。
	每一个通过Trap报告的厂商自定义事件必须定义企业指定的定义，Trap定义必须包括
事件发生的原因而且为DisplayString编码。如下所示：
	trapName NOTIFICATION-TYPE
			OBJECTS {
				ifIndex,
				EventReason,
				Other useful objects
			}
			STATUS current
			DESCRIPTION 
					"trap description"
				：：= Object Id
	注意ifIndex 仅在接口相关时有具体含义。
3.2.3 Trap限制
	CM和CMTS必须按如下所述方法提供对Trap消息的扼制或限制机制，网络操作员可
以方便的通过调整部分MIB来实现缩减Trap消息速率和限制Trap消息。
3.2.3.1 Trap速率级别
	Trap速率限制可以通过两种方法实现，第一种方法是设置Trap消息的最大速率，当
Trap消息的发送超过该极限速率时，CM或CMTS主动停止发送Trap消息直到网络管理站
点有信的请求。
	在第二种方法中当Trap消息的产生低于最大速率时CM或CMTS恢复Trap消息的发
送。
	限制Trap速率通过限制在一定的时间间隔（秒）发送Trap消息的个数和设置超标的动
作状态设置（Trap消息发送使能）。
3.2.3.2 限制Trap速率
	网络管理希望限制在一定时间内发送的Trap个数，当CM或CMTS发送的Trap个数
超过指定的限制时CM或CMTS停止发送Trap。
3.3协议过滤 
	Cable设备MIB库提供了链路层和IP层的协议过滤控制。链路层协议过滤机制可以限
制一系列网络层协议包的转发（例如IP,IPX,NetBios,AppleTalk等）。
	IP层协议过滤机制可以限制CM和CMTS上下行基于源目标IP和目标IP的包过滤、
传输层协议包（例如TCP,UDP,和ICMP等）、基于TCP/UDP协议的源和目的端口号等。
	通常，Cable设备按照下列顺序使用过滤器：


				************************
				* INBOUND LLC FILTER *
				************************
				|			|		   |	
				V			|		   V
		   ***********      |      ***************   
		   * IP Spoof  *      |      * SNMP Access *
		   ***********      |      ***************
                |		    |			   | 
				V          V              V
		       ******************************
			   *  IP   Filter   In				*
			   ******************************
							|
						   V	 
				****************************
			    *    IP    Filter　Out       *
				****************************
							|
							V
		*****************************
	    * LLC FILTER OUTBOUND   * 
	    *****************************
3.3.1 入内的链路层过滤-docsDevFilterLLCTable
	入内的链路层（MAC层或第二层）过滤在docsDevFilterLLCTable中实现，该表的内容
应用于RF口和任何一个CPE接口。该过滤器用于限制处理或转发第二层可能对网络造成
负担的协议包族。
	就目前而言，该过滤器可以被设置为这两种情况：当符合Filter表中的至少一个filter
时丢弃该帧（在第二层上我们称之为帧）或者是匹配表中的至少一个filter时处理该帧。
	在链路层上的过滤器可能的应用例子：限制IP通信（包括arp包）或者丢弃NetBeuI
协议的通信帧。
3.3.2 特殊过滤器
	特殊的过滤器被应用在MAC帧经过处理后已经被IP层所接受但其他的任何处理过程
都未进行时。特殊过滤器一般被应用在特殊的通信网络系统当中。
3.3.2.1 IP spoofing filters-docsDevCpeTable
	IP盗用过滤器应用在当IP包从任何一个CPE接口进入CM时，为了防止用户盗用他人
IP地址或者是误用了非服务运营商所提供的IP地址。若该filter被激活，从任何一个CPE
接口进入的IP包的源地址（src addr）必须符合该Filter表中的至少一个IP地址，否则该IP
包将被不加任何的进一步处理而丢弃。
	该表的内容可以根据最先使用CM的N个CPE的IP地址自动创建，也可以根据实际情
况采用一定的策略来进行进一步的网络控制。例如使用docsDevCpeEnroll和docsDevCpeMax
等。
3.3.2.2 SNMP Access filters-docsDevNmAccessTable
	SNMP 访问控制过滤器被用作过滤从任何接口进入的snmp 包（不管是以太网口或是
RF口）。如果该报是从CPE接口进入的则该过滤器应用在IP spoof filter之后，而且仅考虑
过滤SNMPv1和v2的包，至于SNMPv3的包则不在考虑之内。有关SNMPv3的访问控制
可以参考USM MIB[12]。
3.3.3 IP Filters-docsDevIpFilterTable
	IP层的过滤器实际上是一个分类器表，表中的每一行描述了过滤IP包的模板。模板中
包括IP包的源地址、目的地址（以及相关联的掩码）、上层协议（例如TCP、UDP）、源端
口和目的端口、服务类型（TOS）及服务类型掩码。并且每一行还包括接口索引和通信方向
的结合来比较。在进行包比较时只有匹配该表中其中一行的所有列项时才认为匹配该行，当
然接口索引值和传输方向也必须在比较考虑之内。
	当分拣一个包时，首先扫描索引值较小的过滤行，若发现有匹配的行，对应该行的处理
动作就会被指定。若所匹配过滤器的继续扫描位（continue bit set）被置位，IP过滤器会继
续扫描其他可能的匹配和相应的处理动作。这样就可以在匹配条件较宽松的情况下帧对某些
特殊包进行过滤（例如在条件24.0.16/255.255.255.0下可以对24.0.16.30进行不同的控制）。
	一旦某个IP包在表中找到对应的匹配行，通过docsDevFilterIpControl的设置可以有三
种可能性来处理该IP包：丢弃（该包不再被处理）、接受进而继续被处理、根据
docsDevFilterIpContinue的设置进行处理（若被设为true，继续扫描IP过滤器表和其他的可
能匹配的结果）。
	若IP包匹配表中的某一行，并且docsDevFilterIpControl被设为"policy"， 
docsDevFilterIpPolicyId就被作为docsDevFilterPolicyTable表的索引或选择，在该 
docsDevFilterPolicyTable表中可能有对匹配IP包的多种处理动作，通过
docsDevFilterIpPolicyId选择对应的处理行进行处理。
3.3.4 Outbound LLC Filters
	最后Outbound LLC Filters被应用于在前面处理中所释放出来的包，当然也对应于相应
的接口。本MIB库不指定任何的Outbound LLC Filters，因为在前面描述的各种过滤器应已
经考虑到未来的DOCSIS标准会包括服务质量保证（Qos）并且应该处理本应在Outbound 
LLC Filters过滤器中所做的处理。
4. 定义
DOCS-CABLE-DEVICE-MIB DEFINITIONS ::= BEGIN

IMPORTS
        MODULE-IDENTITY,
        OBJECT-TYPE,
-- do not import        BITS,
        IpAddress,
        Unsigned32,
        Counter32,
        Integer32,
        zeroDotZero,
        mib-2
                FROM SNMPv2-SMI
        RowStatus,
        RowPointer,
        DateAndTime,
        TruthValue
                FROM SNMPv2-TC
        OBJECT-GROUP,
        MODULE-COMPLIANCE
                FROM SNMPv2-CONF
        SnmpAdminString
                FROM SNMP-FRAMEWORK-MIB
        InterfaceIndexOrZero
                FROM IF-MIB;  -- RFC2233

docsDev MODULE-IDENTITY
        LAST-UPDATED    "9908190000Z" -- August 19, 1999
        ORGANIZATION    "IETF IPCDN Working Group"
        CONTACT-INFO
            "        Michael StJohns
             Postal: @Home Network
                     425 Broadway
                     Redwood City, CA 94063
                     U.S.A.
             Phone:  [phone]
             E-mail: [e-mail]"
        DESCRIPTION
            "MCNS兼容cable modems和cable-modem termination systems MIB库模块"
        REVISION "9908190000Z"
        DESCRIPTION
            "Initial Version, published as RFC 2669.
             Modified by Mike StJohns to add/revise filtering, TOS
             support, software version information objects."
        ::= { mib-2 69 }

docsDevMIBObjects  OBJECT IDENTIFIER ::= { docsDev 1 }
docsDevBase OBJECT IDENTIFIER ::= { docsDevMIBObjects 1 }

--
-- 下面所列举的某些MIB对象在目前的DOCSIS射频标准中并没有定义 
-- 但在这里定义出来，防止有人能够定义它或使用
-- （目前并没有这样的支持，仅作为保留的MIB对象）
--.
--

docsDevRole OBJECT-TYPE
        SYNTAX INTEGER {
            cm(1),
            cmtsActive(2),
            cmtsBackup(3)
        }
        MAX-ACCESS  read-only
        STATUS      current
        DESCRIPTION
"描述当前设备在网路中的扮演角色，cm(1)表示这是一个CableModem，
cmtsActiv(2)表示这是一个正在管理网路中Cablemodems的CMTS(正被激
活的)， cmtsBackup(3) 表示这是一个网路中但并不管理Cablemodem
的CMTS(当前并未使用)。
    一般来说，如果该设备是一个CM，在网路操作或重启后它的角色并不
改变。如果该设备是一个CMTS，则在网路操作中它可能在工作CMTS和备
份CMTS的角色中转换。 
注意：目前DOCSIS并不支持备份CMTS，此处有backup CMTS 完全是
为了完整性考虑。"
        ::= { docsDevBase 1 }
docsDevDateTime OBJECT-TYPE