RFC2669 日本語訳
2669 DOCSIS Cable Device MIB Cable Device Management Information Base for DOCSIS compliant Cable Modems and Cable Modem TerminationSystems. M. St. Johns, Ed.. August 1999. (Format: TXT=112880 bytes) (Obsoleted by RFC4639) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group M. St. Johns, Ed. Request for Comments: 2669 @Home Network Category: Proposed Standard August 1999
ワーキンググループM.通りジョーンズ、エドをネットワークでつないでください。コメントのために以下を要求してください。 2669年の@Home Networkカテゴリ: 提案された標準1999年8月
DOCSIS Cable Device MIB
Cable Device Management Information Base
for DOCSIS compliant Cable Modems and
Cable Modem Termination Systems
DOCSISの言いなりになっているCable ModemsとCable Modem Termination SystemsのためのDOCSIS Cable Device MIB Cable Device Management Information基地
Status of this Memo
このMemoの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 All rights reserved。
Abstract
要約
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a basic set of managed objects for SNMP- based management of DOCSIS 1.0 compliant Cable Modems and Cable Modem Termination Systems.
ネットワーク管理プロトコルがインターネットコミュニティにある状態で、このメモは使用のために、Management Information基地の一部(MIB)を定義します。 特に、それはDOCSIS1.0対応することのCable ModemsとCable Modem Termination SystemsのSNMPのベースの管理のために基本的なセットの管理オブジェクトを定義します。
This memo specifies a MIB module in a manner that is compliant to the SNMP SMIv2 [5][6][7]. The set of objects is consistent with the SNMP framework and existing SNMP standards.
このメモはSNMP SMIv2[5][6][7]に対応である方法でMIBモジュールを指定します。 オブジェクトのセットはSNMPフレームワークと既存のSNMP規格と一致しています。
This memo is a product of the IPCDN working group within the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at ipcdn@terayon.com and/or the author.
このメモはインターネット・エンジニアリング・タスク・フォースの中のIPCDNワーキンググループの製品です。 コメントは、請求されて、 ipcdn@terayon.com 、そして/または、作者でワーキンググループのメーリングリストに扱われるべきです。
Table of Contents
目次
1 The SNMP Management Framework ................................... 2 2 Glossary ........................................................ 3 2.1 CATV .......................................................... 3 2.2 CM ............................................................ 3 2.3 CMTS .......................................................... 4 2.4 DOCSIS ........................................................ 4
1 SNMP管理フレームワーク… 2 2用語集… 3 2.1CATV… 3 2.2CM… 3 2.3CMTS… 4 2.4DOCSIS… 4
St. Johns Standards [Page 1] RFC 2669 DOCSIS Cable Device MIB August 1999
ジョーンズStandards[1ページ]の聖RFC2669DOCSISは1999年8月にデバイスMIBに電報を打ちます。
2.5 Downstream .................................................... 4 2.6 Head-end ...................................................... 4 2.7 MAC Packet .................................................... 4 2.8 MCNS .......................................................... 4 2.9 RF ............................................................ 4 2.10 Upstream ..................................................... 4 3 Overview ........................................................ 4 3.1 Structure of the MIB .......................................... 5 3.2 Management requirements ....................................... 6 3.2.1 Handling of Software upgrades ............................... 6 3.2.2 Events and Traps ............................................ 6 3.2.3 Trap Throttling ............................................. 8 3.2.3.1 Trap rate throttling ...................................... 8 3.2.3.2 Limiting the trap rate .................................... 8 3.3 Protocol Filters .............................................. 9 3.3.1 Inbound LLC Filters - docsDevFilterLLCTable ................ 10 3.3.2 Special Filters ............................................ 10 3.3.2.1 IP Spoofing Filters - docsDevCpeTable .................... 10 3.3.2.2 SNMP Access Filters - docsDevNmAccessTable ............... 10 3.3.3 IP Filtering - docsDevIpFilterTable ........................ 11 3.3.4 Outbound LLC Filters ....................................... 13 4 Definitions .................................................... 13 5 Acknowledgments ................................................ 51 6 References ..................................................... 51 7 Security Considerations ........................................ 52 8 Intellectual Property .......................................... 54 9 Author's Address ............................................... 54 10 Full Copyright Statement ...................................... 55
2.5川下… 4 2.6 ヘッドで終わってください… 4 2.7MACパケット… 4 2.8MCNS… 4 2.9rf… 4 2.10上流… 4 3概要… 4 3.1 MIBの構造… 5 3.2 管理要件… 6 3.2 .1 Softwareの取り扱いはアップグレードします… 6 3.2 .2のイベントと罠… 6 3.2 .3 罠阻止… 8 3.2 .3 .1 罠レート阻止… 8 3.2 .3 罠を制限する.2が評価します… 8 3.3 フィルタについて議定書の中で述べてください… 9 .1の本国行きのLLCがフィルターにかける3.3--docsDevFilterLLCTable、… 10 3.3 .2 特別なフィルタ… 10 3.3 .2 .1 IPのパロディーのフィルタ(docsDevCpeTable)… 10 3.3 .2 .2 SNMPはフィルタにアクセスします--docsDevNmAccessTable 10 3.3 .3IPフィルタリング--、docsDevIpFilterTable… 11 3.3 .4 外国行きのLLCフィルタ… 13 4つの定義… 13 5つの承認… 51 6つの参照箇所… 51 7 セキュリティ問題… 52 8知的所有権… 54 9作者のアドレス… 54 10の完全な著作権宣言文… 55
1. The SNMP Management Framework
1. SNMP管理フレームワーク
The SNMP Management Framework presently consists of five major components:
SNMP Management Frameworkは現在、5個の主要コンポーネントから成ります:
o An overall architecture, described in RFC 2571 [1].
o RFC2571[1]で説明された総合的なアーキテクチャ。
o Mechanisms for describing and naming objects and events for the
purpose of management. The first version of this Structure of
Management Information (SMI) is called SMIv1 and described in STD
16, RFC 1155 [2], STD 16, RFC 1212 [3] and RFC 1215 [4]. The
second version, called SMIv2, is described in STD 58, RFC 2578
[5], STD 58, RFC 2579 [6] and STD 58, RFC 2580 [7].
o オブジェクトを説明して、命名するためのメカニズムと管理の目的のためのイベント。 Management情報(SMI)のこのStructureの最初のバージョンは、STD16、RFC1155[2]、STD16、RFC1212[3]、およびRFC1215[4]でSMIv1と呼ばれて、説明されます。 SMIv2と呼ばれる第2バージョンはSTD58、RFC2578[5]、STD58、RFC2579[6]、およびSTD58(RFC2580[7])で説明されます。
o Message protocols for transferring management information. The
first version of the SNMP message protocol is called SNMPv1 and
described in STD 15, RFC 1157 [8]. A second version of the SNMP
message protocol, which is not an Internet standards track
protocol, is called SNMPv2c and described in RFC 1901 [9] and RFC
o 経営情報を移すためのメッセージプロトコル。 SNMPメッセージプロトコルの最初のバージョンは、STD15、RFC1157[8]でSNMPv1と呼ばれて、説明されます。 SNMPメッセージプロトコルの第2のバージョンは、RFC1901[9]とRFCでSNMPv2cと呼ばれて、説明されます。(プロトコルはインターネット標準化過程プロトコルではありません)。
St. Johns Standards [Page 2] RFC 2669 DOCSIS Cable Device MIB August 1999
ジョーンズStandards[2ページ]の聖RFC2669DOCSISは1999年8月にデバイスMIBに電報を打ちます。
1906 [10]. The third version of the message protocol is called
SNMPv3 and described in RFC 1906 [10], RFC 2572 [11] and RFC 2574
[12].
1906 [10]. メッセージプロトコルの第3バージョンは、RFC1906[10]、RFC2572[11]、およびRFC2574[12]でSNMPv3と呼ばれて、説明されます。
o Protocol operations for accessing management information. The
first set of protocol operations and associated PDU formats is
described in STD 15, RFC 1157 [8]. A second set of protocol
operations and associated PDU formats is described in RFC 1905
[13].
o 経営情報にアクセスするための操作について議定書の中で述べてください。 プロトコル操作と関連PDU形式の第一セットはSTD15、RFC1157[8]で説明されます。 2番目のセットのプロトコル操作と関連PDU形式はRFC1905[13]で説明されます。
o A set of fundamental applications described in RFC 2573 [14] and
the view-based access control mechanism described in RFC 2575
[15].
o 1セットの基礎的応用はRFCで2573[14]について説明しました、そして、視点ベースのアクセス管理機構はRFCで2575[15]について説明しました。
Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the mechanisms defined in the SMI.
管理オブジェクトはManagement Information基地と呼ばれた仮想情報店かMIBを通してアクセスされます。 MIBのオブジェクトは、SMIで定義されたメカニズムを使用することで定義されます。
This memo specifies a MIB module that is compliant to the SMIv2. A MIB conforming to the SMIv1 can be produced through the appropriate translations. The resulting translated MIB must be semantically equivalent, except where objects or events are omitted because no translation is possible (use of Counter64). Some machine readable information in SMIv2 will be converted into textual descriptions in SMIv1 during the translation process. However, this loss of machine readable information is not considered to change the semantics of the MIB.
このメモはSMIv2に対応であるMIBモジュールを指定します。 適切な翻訳でSMIv1に従うMIBは生産できます。 どんな翻訳も可能でないので(Counter64の使用)、結果として起こる翻訳されたMIBはオブジェクトかイベントが省略されるところで意味的に同等でなければなりません。 SMIv2の何らかのマシンの読み込み可能な情報が翻訳プロセスの間、SMIv1の原文の記述に変換されるでしょう。 しかしながら、マシンの読み込み可能な情報のこの損失がMIBの意味論を変えると考えられません。
2. Glossary
2. 用語集
The terms in this document are derived either from normal cable system usage, or from the documents associated with the Data Over Cable Service Interface Specification process.
用語はノーマル・ケーブルシステム使用、または、Data Over Cable Service Interface Specificationプロセスに関連しているドキュメントから本書では引き出されます。
2.1. CATV
2.1. CATV
Originally "Community Antenna Television", now used to refer to any cable or hybrid fiber and cable system used to deliver video signals to a community.
元々、「共聴アンテナ式テレビ」は今や、以前はよくビデオ信号を共同体に提供するのに使用されるどんなケーブルやハイブリッドファイバーとケーブルシステムも示していました。
2.2. CM Cable Modem.
2.2. CMケーブルモデム。
A CM acts as a "slave" station in a DOCSIS compliant cable data system.
CMはDOCSIS対応することのケーブルデータ・システムの「奴隷」ステーションとして機能します。
St. Johns Standards [Page 3] RFC 2669 DOCSIS Cable Device MIB August 1999
ジョーンズStandards[3ページ]の聖RFC2669DOCSISは1999年8月にデバイスMIBに電報を打ちます。
2.3. CMTS Cable Modem Termination System.
2.3. CMTSはモデム終了システムに電報を打ちます。
A generic term covering a cable bridge or cable router in a head-end. A CMTS acts as the master station in a DOCSIS compliant cable data system. It is the only station that transmits downstream, and it controls the scheduling of upstream transmissions by its associated CMs.
ギヤエンドでケーブル専用橋かケーブルルータをカバーする総称。 CMTSはDOCSIS対応することのケーブルデータ・システムの主局として機能します。 それは川下に伝わる唯一のステーションです、そして、関連CMは上流のトランスミッションのスケジューリングを制御します。
2.4. DOCSIS
2.4. DOCSIS
"Data Over Cable Interface Specification". A term referring to the ITU-T J.112 Annex B standard for cable modem systems [20].
「ケーブルの上のデータは仕様を連結します。」 ケーブルモデムシステム[20]のITU-T J.112 Annex B規格について言及する用語。
2.5. Downstream
2.5. 川下
The direction from the head-end towards the subscriber.
加入者に向かったギヤエンドからの方向。
2.6. Head-end
2.6. ギヤエンド
The origination point in most cable systems of the subscriber video signals. Generally also the location of the CMTS equipment.
加入者ビデオのほとんどのケーブルシステムの創作ポイントは合図します。 一般にCMTS設備の位置も。
2.7. MAC Packet
2.7. MACパケット
A DOCSIS PDU.
DOCSIS PDU。
2.8. MCNS
2.8. MCNS
"Multimedia Cable Network System". Generally replaced in usage by DOCSIS.
「マルチメディアケーブルネットワークシステム。」 一般に、用法で、DOCSISに取り替えます。
2.9. RF
2.9. rf
Radio Frequency.
無線周波数。
2.10. Upstream
2.10. 上流
The direction from the subscriber towards the head-end.
ギヤエンドに向かった加入者からの方向。
3. Overview
3. 概要
This MIB provides a set of objects required for the management of DOCSIS compliant Cable Modems (CM) and Cable Modem Termination Systems (CMTS). The specification is derived from the DOCSIS Radio Frequency Interface specification [16]. Please note that the DOCSIS 1.0 standard only requires Cable Modems to implement SNMPv1 and to
このMIBはDOCSISの言いなりになっているCable Modems(CM)とCable Modem Termination Systems(CMTS)の管理に必要である1セットのオブジェクトを提供します。 DOCSIS Radio Frequency Interface仕様[16]から仕様を得ます。 そしてDOCSIS1.0規格が、Cable ModemsがSNMPv1を実装するのが必要であるだけである。
St. Johns Standards [Page 4] RFC 2669 DOCSIS Cable Device MIB August 1999
ジョーンズStandards[4ページ]の聖RFC2669DOCSISは1999年8月にデバイスMIBに電報を打ちます。
process IPv4 customer traffic. Design choices in this MIB reflect those requirements. Future versions of the DOCSIS standard are expected to require support for SNMPv3 and IPv6 as well.
IPv4顧客トラフィックを処理してください。 このMIBでのデザイン選択はそれらの要件を反映します。 DOCSIS規格の将来のバージョンがまた、SNMPv3とIPv6に支持を要すると予想されます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [19].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[19]で説明されるように本書では解釈されることであるべきですか?
3.1. Structure of the MIB
3.1. MIBの構造
This MIB is structured into seven groups:
このMIBは7つのグループに構造化されます:
o The docsDevBase group extends the MIB-II 'system' group with
objects needed for cable device system management.
o オブジェクトがケーブルデバイスシステム管理に必要である状態でdocsDevBaseグループはMIB-II'システム'グループを広げます。
o The docsDevNmAccessGroup provides a minimum level of SNMP
access security (see Section 3 of [18]).
o docsDevNmAccessGroupは最低水準のSNMPアクセス保護を提供します。([18])のセクション3を見てください。
o The docsDevSoftware group provides information for network-
downloadable software upgrades. See "Handling of Software
Upgrades" below..
o docsDevSoftwareグループはネットワークのダウンローダブルなソフトウェアの更新のための情報を提供します。 以下の「ソフトウェアの更新の取り扱い」を見てください。
o The docsDevServer group provides information about the
progress of the interaction between the CM or CMTS and
various provisioning servers.
o docsDevServerグループはCMかCMTSと様々な食糧を供給するサーバとの相互作用の進歩の情報を提供します。
o The docsDevEvent group provides control and logging for event
reporting.
o docsDevEventグループはイベント報告のためのコントロールと伐採を提供します。
o The docsDevFilter group configures filters at link layer and
IP layer for bridged data traffic. This group consists of a
link-layer filter table, docsDevFilterLLCTable, which is used
to manage the processing and forwarding of non-IP traffic; an
IP packet classifier table, docsDevFilterIpTable, which is
used to map classes of packets to specific policy actions; a
policy table, docsDevFilterPolicyTable, which maps zero or
more policy actions onto a specific packet classification,
and one or more policy action tables.
o docsDevFilterグループは、リンクレイヤとIPのフィルタがブリッジしているデータ通信量に層にされるのを構成します。 このグループはリンクレイヤフィルタテーブル、docsDevFilterLLCTableから成ります。(docsDevFilterLLCTableは非IPトラフィックの処理と推進を管理するのに使用されます)。 IPパケットクラシファイアテーブル、docsDevFilterIpTable(docsDevFilterIpTableはパケットのクラスを特定保険証券動作に写像するのに使用されます)。 方針テーブルかdocsDevFilterPolicyTableかどれがゼロを写像するか、そして、特定のパケット分類、および1個以上の政策的措置テーブルへの、より多くの政策的措置。
At this time, this MIB specifies only one policy action
table, docsDevFilterTosTable, which allows the manipulation
of the type of services bits in an IP packet based on
matching some criteria. The working group may add additional
policy types and action tables in the future, for example to
allow QOS to modem service identifier assignment based on
destination.
このとき、このMIBは1個の政策的措置テーブルだけ、docsDevFilterTosTableを指定します。(いくつかの評価基準を合わせることに基づいてdocsDevFilterTosTableはIPパケットのサービスビットのタイプの操作を許します)。 ワーキンググループは、将来、例えば目的地に基づくモデムサービス識別子課題にQOSを許容するために追加方針タイプと動作テーブルを加えるかもしれません。
St. Johns Standards [Page 5] RFC 2669 DOCSIS Cable Device MIB August 1999
ジョーンズStandards[5ページ]の聖RFC2669DOCSISは1999年8月にデバイスMIBに電報を打ちます。
o The docsDevCpe group provides control over which IP addresses
may be used by customer premises equipment (e.g. PCs)
serviced by a given cable modem. This provides anti-spoofing
control at the point of origin for a large cable modem
system. This group is separate from docsDevFilter primarily
as this group is only implemented on the Cable Modem (CM) and
MUST NOT be implemented on the Cable Modem Termination System
(CMTS).
o docsDevCpeグループは与えられたケーブルモデムによって修理された顧客端末(例えば、PC)によってIPアドレスが使用されるかもしれないコントロールを提供します。 これは原産地での反スプーフィングコントロールを大きいケーブルモデムシステムに供給します。 このグループは主として、このグループはCable Modem(CM)で実装するだけであり、Cable Modem Termination System(CMTS)で実装してはいけないようにdocsDevFilterから別々です。
3.2. Management requirements
3.2. 管理要件
3.2.1. Handling of Software upgrades
3.2.1. Softwareアップグレードの取り扱い
The Cable Modem software upgrade process is documented in [16]. From a network management station, the operator:
Cable Modemソフトウェアの更新プロセスは[16]に記録されます。 ネットワークマネージメントステーション、オペレータから:
o sets docsDevSwServer to the address of the TFTP server for
software upgrades
o ソフトウェアの更新のためのTFTPサーバのアドレスにdocsDevSwServerを設定します。
o sets docsDevSwFilename to the file pathname of the software
upgrade image
o ソフトウェアの更新イメージのファイルパス名にdocsDevSwFilenameを設定します。
o sets docsDevSwAdminStatus to upgrade-from-mgt
o docsDevSwAdminStatusにmgtからアップグレードするように設定します。
One reason for the SNMP-initiated upgrade is to allow loading of a temporary software image (e.g., special diagnostic software) that differs from the software normally used on that device without changing the provisioning database.
SNMPによって開始されたアップグレードの1つの理由は通常、そのデバイスで変化しないで使用されるソフトウェアと異なっている一時的なソフトウェアイメージ(例えば、特別な診断ソフトウェア)のローディングに食糧を供給するデータベースを許容することです。
Note that software upgrades should not be accepted blindly by the cable device. The cable device may refuse an upgrade if:
ソフトウェアの更新がケーブルデバイスによって盲目的に受け入れられるべきでないことに注意してください。 ケーブルデバイスがアップグレードを拒否するかもしれない、:
o The download is incomplete.
o ダウンロードは不完全です。
o The file contents are incomplete or damaged.
o ファイルコンテンツは、不完全であるか破損されています。
o The software is not intended for that hardware device (may
include the case of a feature set that has not been purchased
for this device).
o ソフトウェアはそのハードウェアデバイス(このデバイスに取得されていない1つの特徴セットに関するケースを含むかもしれない)のために意図しません。
3.2.2. Events and Traps
3.2.2. イベントと罠
This MIB provides control facilities for reporting events through syslog, traps, and non-volatile logging. If events are reported through traps, the specified conventions must be followed. Other means of event reporting are outside the scope of this document.
このMIBはsyslog、罠、および非揮発性の伐採でイベントを報告するのに制御機能を提供します。 イベントが罠を通して報告されるなら、指定されたコンベンションに続かなければなりません。 このドキュメントの範囲の外にイベントが報告する他の手段があります。
St. Johns Standards [Page 6] RFC 2669 DOCSIS Cable Device MIB August 1999
ジョーンズStandards[6ページ]の聖RFC2669DOCSISは1999年8月にデバイスMIBに電報を打ちます。
The definition and coding of events is vendor-specific. In deference to the network operator who must troubleshoot multi-vendor networks, the circumstances and meaning of each event should be reported as human-readable text. Vendors SHOULD provide time-of-day clocks in CMs to provide useful timestamping of events.
イベントの定義とコード化はベンダー特有です。 マルチベンダネットワークを障害調査しなければならないネットワーク・オペレータを重んじて、それぞれのイベントの事情と意味は人間読み込み可能なテキストとして報告されるべきです。 ベンダーSHOULDは、イベントの役に立つtimestampingを提供するために時刻時計をCMに提供します。
For each vendor-specific event that is reportable via TRAP, the vendor must create an enterprise-specific trap definition. Trap definitions MUST include the event reason encoded as DisplayString and should be defined as:
それぞれのTRAPを通して報告可能なベンダー特有のイベントのために、ベンダーは企業特有の罠定義を作成しなければなりません。 罠定義は、DisplayStringとしてコード化されたイベント理由を含めなければならなくて、以下と定義されるべきです。
trapName NOTIFICATION-TYPE
OBJECTS {
ifIndex,
eventReason,
other useful objects
}
STATUS current
DESCRIPTION
"trap description"
::= Object Id
trapName NOTIFICATION-TYPE OBJECTS、ifIndex、eventReason、他の役に立つオブジェクト、STATUSの現在の記述「罠記述」:、:= オブジェクトイド
Note that ifIndex is only included if the event or trap is interface related.
ifIndexがイベントか罠がインタフェースである場合にだけ含まれているというメモは関係しました。
An example (fake) vendor defined trap might be:
例の(にせ)のベンダー定義された罠は以下の通りです。
xyzVendorModemDropout NOTIFICATION-TYPE
OBJECTS {
eventReason,
xyzModemHighWatermarkCount
}
STATUS current
DESCRIPTION
"Sent by a CMTS when a configurable number of modems
(xyzModemHysteresis) de-register or become unreachable during
the sampling period (5 minutes). Used to warn a management
station about a catastrophic cable plant outage."
::= { xyzTraps 23 }
xyzVendorModemDropout NOTIFICATION-TYPE OBJECTS、eventReason、STATUSの現在の記述が「構成可能な数のモデム(xyzModemHysteresis)がサンプリング周期(5分)の間反-登録するか、または手が届かなくなるときCMTSで送った」xyzModemHighWatermarkCount。 「壊滅的なケーブルプラント供給停止に関して管理ステーションに警告するのにおいて、中古です」。 ::= xyzTraps23
In this example eventReason is a DisplayString providing a human readable error message, and xyzModemHighWatermarkCount is a Gauge32 which indicates the maximum number of modems during the epoch.
この例では、eventReasonは人間の読み込み可能なエラーメッセージを提供するDisplayStringです、そして、xyzModemHighWatermarkCountは時代の間にモデムの最大数を示すGauge32です。
St. Johns Standards [Page 7] RFC 2669 DOCSIS Cable Device MIB August 1999
ジョーンズStandards[7ページ]の聖RFC2669DOCSISは1999年8月にデバイスMIBに電報を打ちます。
The last digit of the trap OID for enterprise-specific traps must match docsDevEvId. For SNMPv1-capable Network Management systems, this is necessary to correlate the event type to the trap type. Many Network Management systems are only capable of trap filtering on an enterprise and single-last-digit basis.
企業特有の罠のための罠OIDの下ケタはdocsDevEvIdに合わなければなりません。 SNMPv1できるNetwork Managementシステムに、これが、罠タイプにイベントタイプを関連させるのに必要です。 多くのNetwork Managementシステムは単に企業と下ただ一つのケタベースで罠フィルタリングができます。
3.2.3. Trap Throttling
3.2.3. 罠阻止
The CM and CMTS MUST provide support for trap message throttling as described below. The network operator can employ message rate throttling or trap limiting by manipulating the appropriate MIB variables.
CMとCMTS MUSTは以下で説明されるようにトラップメッセージ阻止のサポートを提供します。 ネットワーク・オペレータは、適切なMIB変数を操ることによって、メッセージレート阻止か罠制限を使うことができます。
3.2.3.1. Trap rate throttling
3.2.3.1. 罠レート阻止
Network operators may employ either of two rate control methods. In the first method, the device ceases to send traps when the rate exceeds the specified maximum message rate. It resumes sending traps only if reactivated by a network management station request.
ネットワーク・オペレータは2つの速度制御メソッドのどちらかを使うかもしれません。 最初のメソッドで、レートが指定された最大のメッセージレートを超えていると、デバイスは、罠を送るのをやめます。 それは、ネットワークマネージメントステーション要求で現役に戻される場合にだけ罠を送るのを再開します。
In the second method, the device resumes sending traps when the rate falls below the specified maximum message rate.
2番目のメソッドで、デバイスは、レートが指定された最大のメッセージレートの下まで下がるとき、罠を送るのを再開します。
The network operator configures the specified maximum message rate by setting the measurement interval (in seconds), and the maximum number of traps to be transmitted within the measurement interval. The operator can query the operational throttling state (to determine whether traps are enabled or blocked by throttling) of the device, as well as query and set the administrative throttling state (to manage the rate control method) of the device.
測定間隔(秒の)、および罠の最大数に測定間隔中に伝えられるように設定することによって、ネットワーク・オペレータは指定された最大のメッセージレートを構成します。 オペレータは、デバイスの管理阻止状態(速度制御メソッドを管理する)をデバイスの操作上の阻止状態(罠が阻止することによって可能にされるか、または妨げられるかを決定する)について質問して、質問して、設定できます。
3.2.3.2. Limiting the trap rate
3.2.3.2. 罠レートを制限します。
Network operators may wish to limit the number of traps sent by a device over a specified time period. The device ceases to send traps when the number of traps exceeds the specified threshold. It resumes sending traps only when the measurement interval has passed.
ネットワーク・オペレータは指定された期間、デバイスによって送られた罠の数を制限したがっているかもしれません。 罠の数が指定された敷居を超えていると、デバイスは、罠を送るのをやめます。 それは、測定間隔が過ぎたときだけ、罠を送るのを再開します。
The network operator defines the maximum number of traps he is willing to handle and sets the measurement interval to a large number (in hundredths of a second). For this case, the administrative throttling state is set to stop at threshold which is the maximum number of traps.
ネットワーク・オペレータは、彼が扱っても構わないと思っている罠の最大数を定義して、多く(1秒の100分の1における)に測定間隔を設定します。 このような場合、管理阻止状態が罠の最大数である敷居で止まるように設定されます。
See "Techniques for Managing Asynchronously Generated Alerts" [17] for further information.
詳細のための「非同期に発生している警戒を管理するためのテクニック」[17]を見てください。
St. Johns Standards [Page 8] RFC 2669 DOCSIS Cable Device MIB August 1999
ジョーンズStandards[8ページ]の聖RFC2669DOCSISは1999年8月にデバイスMIBに電報を打ちます。
3.3. Protocol Filters
3.3. プロトコルフィルタ
The Cable Device MIB provides objects for both LLC and IP protocol filters. The LLC protocol filter entries can be used to limit CM forwarding to a restricted set of network-layer protocols (such as IP, IPX, NetBIOS, and Appletalk).
Cable Device MIBはLLCとIPプロトコルフィルタの両方にオブジェクトを供給します。 CM推進を制限されたセットのネットワーク層プロトコル(IPや、IPXや、NetBIOSや、Appletalkなどの)に制限するのにLLCプロトコルフィルタエントリーを使用できます。
The IP protocol filter entries can be used to restrict upstream or downstream traffic based on source and destination IP addresses, transport-layer protocols (such as TCP, UDP, and ICMP), and source and destination TCP/UDP port numbers.
ソースと送付先IPアドレスに基づく、上流の、または、川下のトラフィック、トランスポート層プロトコル(TCPや、UDPや、ICMPなどの)、ソース、および目的地TCP/UDPポートナンバーを制限するのにIPプロトコルフィルタエントリーを使用できます。
In general, a cable modem applies filters (or more properly, classifiers) in an order appropriate to the layering model. Specifically, the inbound MAC (or LLC) layer filters are applied first, then the "special" filters, then the IP layer inbound filters, then the IP layer outbound filters, then any final LLC outbound filters. Since the cable modem does not generally do any IP processing (other than that specified by the filters) the processing of the IP in filters and IP out filters can usually be combined into a single step.
または、一般に、ケーブルモデムがフィルタを適用する、(より適切に、クラシファイア) オーダーがレイヤリングに当てるコネはモデル化されます。 明確に、本国行きのMAC(または、LLC)層のフィルタが最初に、適用されて、次に、次に、「特別な」フィルタでありIPが本国行きのフィルタを層にして、次に、IP層が外国行きのフィルタであり、次に、どんな最終的なLLCも外国行きのフィルタです。 以来、一般に、ケーブルモデムはどんなIP処理(フィルタによって指定されるのを除いて)にもフィルタでのIPの処理をしません、そして、通常、IPの出ているフィルタはシングルステップに結合できます。
***************
* LLC Filters *
***************
| | |
v | v
************ | ***************
* IP Spoof * | * SNMP Access *
************ | ***************
| | |
v v v
****************
* IP Filter In *
****************
|
v
*****************
* IP Filter Out *
*****************
|
v
***********
* LLC Out *
***********
*************** * LLCフィルタ****************| | | v| ************に対して| *************** * IPパロディー*| * SNMPアクセス*************| *************** | | | v対*****************IP Filter In*****************に| ******************IP Filter Out******************に対して| ************LLC Out************に対して
St. Johns Standards [Page 9] RFC 2669 DOCSIS Cable Device MIB August 1999
ジョーンズStandards[9ページ]の聖RFC2669DOCSISは1999年8月にデバイスMIBに電報を打ちます。
3.3.1. Inbound LLC Filters - docsDevFilterLLCTable
3.3.1. 本国行きのLLCフィルタ--docsDevFilterLLCTable
The inbound LLC (or MAC or level-2) filters are contained in the docsDevFilterLLCTable and are applied to level-2 frames entering the cable modem from either the RF MAC interface or from one of the CPE (ethernet or other) interfaces. These filters are used to prohibit the processing and forwarding of certain types of level-2 traffic that may be disruptive to the network. The filters, as currently specified, can be set to cause the modem to either drop frames which match at least one filter, or to process a frame which matches at least filter. Some examples of possible configurations would be to only permit IP (and ARP) traffic, or to drop NETBUEI traffic.
本国行きのLLC(または、MACかレベル-2)フィルタは、RF MACインタフェースかCPE(何らかのイーサネット)インタフェースの1つからケーブルモデムを入れながら、docsDevFilterLLCTableに含まれていて、レベル-2個のフレームに適用されます。 これらのフィルタは、あるタイプのネットワークに破壊的であるかもしれないレベル-2トラフィックの処理と推進を禁止するのに使用されます。 現在指定されているとして、少なくとも1個のフィルタに合っているコマ落ちにモデムを引き起こすか、またはフィルタがマッチが少なくともフィルターにかけるフレームを処理するように設定できます。 可能な構成に関するいくつかの例は、IP(そして、ARP)にトラフィックを可能にするだけであるか、またはNETBUEIトラフィックを下げるだろうことです。
3.3.2. Special Filters
3.3.2. 特別なフィルタ
Special filters are applied after the packet is accepted from the MAC layer by the IP module, but before any other processing is done. They are filters that apply only to a very specific class of traffic.
MAC層からIPモジュールでパケットを受け入れた後にもかかわらず、いかなる他の処理もする前を除いて、特別なフィルタは適用されています。 それらは非常に特定のクラスのトラフィックだけに適用されるフィルタです。
3.3.2.1. IP Spoofing Filters - docsDevCpeTable
3.3.2.1. IPスプーフィングフィルタ--docsDevCpeTable
IP spoofing filters are applied to packets entering the modem from one of the CPE interfaces and are intended to prevent a subscriber from stealing or mis-using IP addresses that were not assigned to the subscriber. If the filters are active (enabled), the source address of the IP packet must match at least one IP address in this table or it is discarded without further processing.
IPスプーフィングフィルタは、CPEインタフェースの1つからモデムを入れながらパケットに適用されて、加入者が加入者に割り当てられなかったIPアドレスを横取りするか、または誤用するのを防ぐことを意図します。 フィルタがアクティブであるなら(可能にされます)、IPパケットのソースアドレスがこのテーブルの少なくとも1つのIPアドレスに合わなければならない、さもなければ、それはさらなる処理なしで捨てられます。
The table can be automatically populated where the first N different IP addresses seen from the CPE side of the cable modem are used to automatically populate the table. The spoofing filters are specified in the docsDevCpeTable and the policy for automatically creating filters in that table is controlled by docsDevCpeEnroll and docsDevCpeMax as well as the network management agent.
見られた最初のNケーブルモデムのCPE側面と異なったIPアドレスが自動的にテーブルに居住するのに使用されるところで自動的にテーブルに居住できます。 スプーフィングフィルタはdocsDevCpeTableで指定されます、そして、そのテーブルで自動的にフィルタを作成するための方針はネットワークマネージメントエージェントと同様にdocsDevCpeEnrollとdocsDevCpeMaxによって制御されます。
3.3.2.2. SNMP Access Filters - docsDevNmAccessTable
3.3.2.2. SNMPアクセスフィルタ--docsDevNmAccessTable
The SNMP access filters are applied to SNMP packets entering from any interface and destined for the cable modem. If the packets enter from a CPE interface, the SNMP filters are applied after the IP spoofing filters. The filters only apply to SNMPv1 or SNMPv2c traffic, and are not consulted for SNMPv3 traffic (and need not be implemented by a v3 only agent). SNMPv3 access control is specified in the User Security Model MIB in [12].
SNMPアクセスフィルタは、どんなインタフェースからも入るSNMPパケットに適用されて、ケーブルモデムのために運命づけられています。 パケットにCPEインタフェースから入るなら、SNMPフィルタはIPスプーフィングフィルタの後に適用されます。 フィルタだけがSNMPv1かSNMPv2cトラフィックに申し込んで、SNMPv3トラフィックのために相談されない、(v3だけによって実装される必要はない、エージェント) SNMPv3アクセスコントロールは[12]のUser Security Model MIBで指定されます。
St. Johns Standards [Page 10] RFC 2669 DOCSIS Cable Device MIB August 1999
ジョーンズStandards[10ページ]の聖RFC2669DOCSISは1999年8月にデバイスMIBに電報を打ちます。
3.3.3. IP Filtering - docsDevIpFilterTable
3.3.3. IPフィルタリング--docsDevIpFilterTable
The IP Filtering table acts as a classifier table. Each row in the table describes a template against which IP packets are compared. The template includes source and destination addresses (and their associated masks), upper level protocol (e.g. TCP, UDP), source and destination port ranges, TOS and TOS mask. A row also contains interface and traffic direction match values which have to be considered in combination. All columns of a particular row must match the appropriate fields in the packet, and must match the interface and direction items for the packet to result in a match to the packet.
IP Filteringテーブルはクラシファイアテーブルとして作動します。 テーブルの各行はIPパケットが比較されるテンプレートについて説明します。 テンプレートは範囲、TOS、およびTOSがマスクをかけるソース、送付先アドレス(そして、それらの関連マスク)、上側の平らなプロトコル(例えば、TCP、UDP)、ソース、および仕向港を含んでいます。 また、行はインタフェースと組み合わせで考えられなければならないトラフィック方向マッチ値を含んでいます。 特定の行に関するすべてのコラムが、パケットの適切な分野を合わせなければならなくて、パケットがパケットへのマッチをもたらすように、インタフェースと方向項目に合わなければなりません。
When classifying a packet, the table is scanned beginning with the lowest number filter. If the agent finds a match, it applies the group of policies specified. If the matched filter has the continue bit set, the agent continues the scan possibly matching additional filters and applying additional policies. This allows the agent to take one set of actions for the 24.0.16/255.255.255.0 group and one set of actions for telnet packets to/from 24.0.16.30 and these sets of actions may not be mutually exclusive.
パケットを分類するとき、テーブルは、最も低い数のフィルタで始まりながら、スキャンされています。 エージェントがマッチを見つけるなら、それは指定された方針のグループを適用します。 照合フィルタが続けていた、噛み付いているセット(ことによると追加フィルタに合っているスキャンを続けて、追加方針を適用しているエージェント)を続けてください。 エージェントはこれで.0グループと1つが/へのtelnetパケットのための動作をセットした24.0.16/255.255.255のための1セットの行動を取ることができます。24.0 .16 .30とこれらのセットの機能は互いに排他的でないかもしれません。
Once a packet is matched, one of three actions happen based on the setting of docsDevFilterIpControl in the row. The packet may be dropped, in which case no further processing is required. The packet may be accepted and processing of the packet continues. Lastly, the packet may have a set of policy actions applied to it. If docsDevFilterIpContinue is set to true, scanning of the table continues and additional matches may result.
パケットがいったん取り組むようになると、docsDevFilterIpControlの設定に基づいて3つの動作の1つは行で起こります。 パケットは下げられるかもしれません、その場合、どんなより遠い処理も必要ではありません。 パケットを受け入れるかもしれません、そして、パケットの処理は続きます。 最後に、パケットで、1セットの政策的措置をそれに適用するかもしれません。 docsDevFilterIpContinueが本当に用意ができているなら、テーブルのスキャンは続きます、そして、追加マッチは結果として生じるかもしれません。
When a packet matches, and docsDevFilterIpControl in the filter matched is set to 'policy', the value of docsDevFilterIpPolicyId is used as a selector into the docsDevFilterPolicyTable. The first level of indirection may result in zero or more actions being taken based on the match. The docsDevFilterPolicyTable is scanned in row order and all rows where docsDevFilterPolicyId equals docsDevFilterIpPolicyId have the action specified by docsDevFilterPolicyValue 'executed'. For example, a value pointing to an entry in the docsDevFilterTosTable may result in the re-writing of the TOS bits in the IP packet which was matched. Another possibility may be to assign an output packet to a specific output upstream queue. An even more complex action might be to re-write the TOS value, assign the packet to an upstream service ID, and drop it into a particular IPSEC tunnel.
パケットが合っていて、合わせられたフィルタのdocsDevFilterIpControlが'方針'に用意ができているとき、docsDevFilterIpPolicyIdの値はセレクタとしてdocsDevFilterPolicyTableに使用されます。 最初のレベルの間接指定がゼロをもたらすかもしれませんか、または取られるより多くの行動がマッチを基礎づけました。 docsDevFilterPolicyTableは行オーダーでスキャンされます、そして、docsDevFilterPolicyIdがdocsDevFilterIpPolicyIdと等しいすべての行で、'実行された'docsDevFilterPolicyValueは動作を指定します。 例えば、docsDevFilterTosTableにエントリーを示す値は合わせられたIPパケットのTOSビットの書き直しをもたらすかもしれません。 別の可能性は特定の出力上流待ち行列に出力パケットを割り当てることであるかもしれません。 さらに複雑な動きは、TOS値を書き直して、上流のサービスIDにパケットを割り当てて、特定のIPSECトンネルにそれを下げることであるかもしれません。
St. Johns Standards [Page 11] RFC 2669 DOCSIS Cable Device MIB August 1999
ジョーンズStandards[11ページ]の聖RFC2669DOCSISは1999年8月にデバイスMIBに電報を打ちます。
Example:
例:
docsDevFilterIpTable
docsDevFilterIpTable
# Index, SrcIP/Mask, DstIP/Mask,ULP, SrcPts,DstPts,Tos/Mask, # Int/Dir, Pgroup, [continue] # drop any netbios traffic 10, 0/0, 0/0, TCP, any, 137-139, 0/0, any/any, drop
# Index, SrcIP/Mask, DstIP/Mask,ULP, SrcPts,DstPts,Tos/Mask, # Int/Dir, Pgroup, [continue] # drop any netbios traffic 10, 0/0, 0/0, TCP, any, 137-139, 0/0, any/any, drop
# traffic to the proxy gets better service - other matches possible 20, 0/0, proxy/32, TCP, any,any, 0/0, cpe/in, 10, continue
# traffic to the proxy gets better service - other matches possible 20, 0/0, proxy/32, TCP, any,any, 0/0, cpe/in, 10, continue
# Traffic from CPE 1 gets 'Gold' service, other matches possible 30, cpe1/32, 0/0, any, any,any, 0/0, cpe/in, 20, continue
# Traffic from CPE 1 gets 'Gold' service, other matches possible 30, cpe1/32, 0/0, any, any,any, 0/0, cpe/in, 20, continue
# Traffic from CPE2 to work goes, other traffic dropped 40, cpe2/32, workIPs/24, any, 0/0, cpe/in, accept 45, cpe2/32, 0/0, any, any,ayn, 0/0, cpe/in, drop
# Traffic from CPE2 to work goes, other traffic dropped 40, cpe2/32, workIPs/24, any, 0/0, cpe/in, accept 45, cpe2/32, 0/0, any, any,ayn, 0/0, cpe/in, drop
# Traffic with TOS=4 gets queued on the "silver" queue. 50, 0/0, 0/0, any, any,any, 4/255, cpe/in, 30
# Traffic with TOS=4 gets queued on the "silver" queue. 50, 0/0, 0/0, any, any,any, 4/255, cpe/in, 30
# Inbound "server" traffic to low numbered ports gets dropped. 60, 0/0, 0/0, TCP, any,1-1023, 0/0, cpe/out, drop 65, 0/0, 0/0, UDP, any,1-1023, 0/0, cpe/out, drop
# Inbound "server" traffic to low numbered ports gets dropped. 60, 0/0, 0/0, TCP, any,1-1023, 0/0, cpe/out, drop 65, 0/0, 0/0, UDP, any,1-1023, 0/0, cpe/out, drop
docsDevFilterIpPolicyTable
docsDevFilterIpPolicyTable
# # index, policy group, policy 10, 10, queueEntry.20 -- special queue for traffic to proxy
# # index, policy group, policy 10, 10, queueEntry.20 -- special queue for traffic to proxy
15, 20, queueEntry.15 -- Gold Service queue 20, 20, docsDevFilterTosStatus.10 -- Mark this packet with TOS 5
15, 20, queueEntry.15 -- Gold Service queue 20, 20, docsDevFilterTosStatus.10 -- Mark this packet with TOS 5
25, 30, queueEntry.10 -- Silver service queue
25, 30, queueEntry.10 -- Silver service queue
This table describes some special processing for packets originating from either the first or second CPE device which results in their queuing on to special upstream traffic queues and for the "gold" service results in having the packets marked with a TOS of 5. The 10, 20, 60 and 65 entries are generic entries that would generally be applied to all traffic to this CM. The 30, 40 and 45 entries are specific to a particular CPE's service assignments. The ordering here is a bit contrived, but is close to what may actually be required by the operator to control various classes of customers.
This table describes some special processing for packets originating from either the first or second CPE device which results in their queuing on to special upstream traffic queues and for the "gold" service results in having the packets marked with a TOS of 5. The 10, 20, 60 and 65 entries are generic entries that would generally be applied to all traffic to this CM. The 30, 40 and 45 entries are specific to a particular CPE's service assignments. The ordering here is a bit contrived, but is close to what may actually be required by the operator to control various classes of customers.
St. Johns Standards [Page 12] RFC 2669 DOCSIS Cable Device MIB August 1999
St. Johns Standards [Page 12] RFC 2669 DOCSIS Cable Device MIB August 1999
3.3.4. Outbound LLC Filters
3.3.4. Outbound LLC Filters
Lastly, any outbound LLC filters are applied to the packet just prior to it being emitted on the appropriate interface. This MIB does not specify any outbound LLC filters, but it is anticipated that the QOS additions to the DOCSIS standard may include some outbound LLC filtering requirements. If so, those filters would be applied as described here.
Lastly, any outbound LLC filters are applied to the packet just prior to it being emitted on the appropriate interface. This MIB does not specify any outbound LLC filters, but it is anticipated that the QOS additions to the DOCSIS standard may include some outbound LLC filtering requirements. If so, those filters would be applied as described here.
4. Definitions
4. Definitions
DOCS-CABLE-DEVICE-MIB DEFINITIONS ::= BEGIN
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
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: +1 650 569 5368
E-mail: stjohns@corp.home.net"
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: +1 650 569 5368 E-mail: stjohns@corp.home.net"
St. Johns Standards [Page 13] RFC 2669 DOCSIS Cable Device MIB August 1999
St. Johns Standards [Page 13] RFC 2669 DOCSIS Cable Device MIB August 1999
DESCRIPTION
"This is the MIB Module for MCNS-compliant cable modems and
cable-modem termination systems."
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 }
DESCRIPTION "This is the MIB Module for MCNS-compliant cable modems and cable-modem termination systems." 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 }
docsDevMIBObjects OBJECT IDENTIFIER ::= { docsDev 1 } docsDevBase OBJECT IDENTIFIER ::= { docsDevMIBObjects 1 }
-- -- For the following object, there is no concept in the -- RFI specification corresponding to a backup CMTS. The -- enumeration is provided here in case someone is able -- to define such a role or device. --
-- -- For the following object, there is no concept in the -- RFI specification corresponding to a backup CMTS. The -- enumeration is provided here in case someone is able -- to define such a role or device. --
docsDevRole OBJECT-TYPE
SYNTAX INTEGER {
cm(1),
cmtsActive(2),
cmtsBackup(3)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Defines the current role of this device. cm (1) is
a Cable Modem, cmtsActive(2) is a Cable Modem Termination
System which is controlling the system of cable modems,
and cmtsBackup(3) is a CMTS which is currently connected,
but not controlling the system (not currently used).
docsDevRole OBJECT-TYPE SYNTAX INTEGER { cm(1), cmtsActive(2), cmtsBackup(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "Defines the current role of this device. cm (1) is a Cable Modem, cmtsActive(2) is a Cable Modem Termination System which is controlling the system of cable modems, and cmtsBackup(3) is a CMTS which is currently connected, but not controlling the system (not currently used).
In general, if this device is a 'cm', its role will not
change during operation or between reboots. If the
device is a 'cmts' it may change between cmtsActive and
cmtsBackup and back again during normal operation. NB:
At this time, the DOCSIS standards do not support the
concept of a backup CMTS, cmtsBackup is included for
completeness."
::= { docsDevBase 1 }
In general, if this device is a 'cm', its role will not change during operation or between reboots. If the device is a 'cmts' it may change between cmtsActive and cmtsBackup and back again during normal operation. NB: At this time, the DOCSIS standards do not support the concept of a backup CMTS, cmtsBackup is included for completeness." ::= { docsDevBase 1 }
docsDevDateTime OBJECT-TYPE
SYNTAX DateAndTime
MAX-ACCESS read-write
STATUS current
docsDevDateTime OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-write STATUS current
St. Johns Standards [Page 14] RFC 2669 DOCSIS Cable Device MIB August 1999
St. Johns Standards [Page 14] RFC 2669 DOCSIS Cable Device MIB August 1999
DESCRIPTION
"The date and time, with optional timezone
information."
::= { docsDevBase 2 }
DESCRIPTION "The date and time, with optional timezone information." ::= { docsDevBase 2 }
docsDevResetNow OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"Setting this object to true(1) causes the device to reset.
Reading this object always returns false(2)."
::= { docsDevBase 3 }
docsDevResetNow OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "Setting this object to true(1) causes the device to reset. Reading this object always returns false(2)." ::= { docsDevBase 3 }
docsDevSerialNumber OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The manufacturer's serial number for this device."
::= { docsDevBase 4 }
docsDevSerialNumber OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "The manufacturer's serial number for this device." ::= { docsDevBase 4 }
docsDevSTPControl OBJECT-TYPE
SYNTAX INTEGER {
stEnabled(1),
noStFilterBpdu(2),
noStPassBpdu(3)
}
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This object controls operation of the spanning tree
protocol (as distinguished from transparent bridging).
If set to stEnabled(1) then the spanning tree protocol
is enabled, subject to bridging constraints. If
noStFilterBpdu(2), then spanning tree is not active,
and Bridge PDUs received are discarded.
If noStPassBpdu(3) then spanning tree is not active
and Bridge PDUs are transparently forwarded. Note that
a device need not implement all of these options,
but that noStFilterBpdu(2) is required."
::= { docsDevBase 5 }
docsDevSTPControl OBJECT-TYPE SYNTAX INTEGER { stEnabled(1), noStFilterBpdu(2), noStPassBpdu(3) } MAX-ACCESS read-write STATUS current DESCRIPTION "This object controls operation of the spanning tree protocol (as distinguished from transparent bridging). If set to stEnabled(1) then the spanning tree protocol is enabled, subject to bridging constraints. If noStFilterBpdu(2), then spanning tree is not active, and Bridge PDUs received are discarded. If noStPassBpdu(3) then spanning tree is not active and Bridge PDUs are transparently forwarded. Note that a device need not implement all of these options, but that noStFilterBpdu(2) is required." ::= { docsDevBase 5 }
-- -- The following table provides one level of security for access -- to the device by network management stations. -- Note that access is also constrained by the -- community strings and any vendor-specific security.
-- -- The following table provides one level of security for access -- to the device by network management stations. -- Note that access is also constrained by the -- community strings and any vendor-specific security.
St. Johns Standards [Page 15] RFC 2669 DOCSIS Cable Device MIB August 1999
St. Johns Standards [Page 15] RFC 2669 DOCSIS Cable Device MIB August 1999
--
--
docsDevNmAccessTable OBJECT-TYPE
SYNTAX SEQUENCE OF DocsDevNmAccessEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table controls access to SNMP objects by network
management stations. If the table is empty, access
to SNMP objects is unrestricted. This table exists only
on SNMPv1 or v2c agents and does not exist on SNMPv3
agents. See the conformance section for details.
Specifically, for v3 agents, the appropriate MIBs and
security models apply in lieu of this table."
::= { docsDevMIBObjects 2 }
docsDevNmAccessTable OBJECT-TYPE SYNTAX SEQUENCE OF DocsDevNmAccessEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table controls access to SNMP objects by network management stations. If the table is empty, access to SNMP objects is unrestricted. This table exists only on SNMPv1 or v2c agents and does not exist on SNMPv3 agents. See the conformance section for details. Specifically, for v3 agents, the appropriate MIBs and security models apply in lieu of this table." ::= { docsDevMIBObjects 2 }
docsDevNmAccessEntry OBJECT-TYPE
SYNTAX DocsDevNmAccessEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry describing access to SNMP objects by a
particular network management station. An entry in
this table is not readable unless the management station
has read-write permission (either implicit if the table
is empty, or explicit through an entry in this table.
Entries are ordered by docsDevNmAccessIndex. The first
matching entry (e.g. matching IP address and community
string) is used to derive access."
INDEX { docsDevNmAccessIndex }
::= { docsDevNmAccessTable 1 }
docsDevNmAccessEntry OBJECT-TYPE SYNTAX DocsDevNmAccessEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry describing access to SNMP objects by a particular network management station. An entry in this table is not readable unless the management station has read-write permission (either implicit if the table is empty, or explicit through an entry in this table. Entries are ordered by docsDevNmAccessIndex. The first matching entry (e.g. matching IP address and community string) is used to derive access." INDEX { docsDevNmAccessIndex } ::= { docsDevNmAccessTable 1 }
DocsDevNmAccessEntry ::= SEQUENCE {
docsDevNmAccessIndex Integer32,
docsDevNmAccessIp IpAddress,
docsDevNmAccessIpMask IpAddress,
docsDevNmAccessCommunity OCTET STRING,
docsDevNmAccessControl INTEGER,
docsDevNmAccessInterfaces OCTET STRING,
docsDevNmAccessStatus RowStatus
}
DocsDevNmAccessEntry ::= SEQUENCE { docsDevNmAccessIndex Integer32, docsDevNmAccessIp IpAddress, docsDevNmAccessIpMask IpAddress, docsDevNmAccessCommunity OCTET STRING, docsDevNmAccessControl INTEGER, docsDevNmAccessInterfaces OCTET STRING, docsDevNmAccessStatus RowStatus }
docsDevNmAccessIndex OBJECT-TYPE
SYNTAX Integer32 (1..2147483647)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Index used to order the application of access
docsDevNmAccessIndex OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Index used to order the application of access
St. Johns Standards [Page 16] RFC 2669 DOCSIS Cable Device MIB August 1999
St. Johns Standards [Page 16] RFC 2669 DOCSIS Cable Device MIB August 1999
entries."
::= { docsDevNmAccessEntry 1 }
entries." ::= { docsDevNmAccessEntry 1 }
docsDevNmAccessIp OBJECT-TYPE
SYNTAX IpAddress
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The IP address (or subnet) of the network management
station. The address 255.255.255.255 is defined to mean
any NMS. If traps are enabled for this entry, then the
value must be the address of a specific device."
DEFVAL { 'ffffffff'h }
::= { docsDevNmAccessEntry 2 }
docsDevNmAccessIp OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-create STATUS current DESCRIPTION "The IP address (or subnet) of the network management station. The address 255.255.255.255 is defined to mean any NMS. If traps are enabled for this entry, then the value must be the address of a specific device." DEFVAL { 'ffffffff'h } ::= { docsDevNmAccessEntry 2 }
docsDevNmAccessIpMask OBJECT-TYPE
SYNTAX IpAddress
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The IP subnet mask of the network management stations.
If traps are enabled for this entry, then the value must
be 255.255.255.255."
DEFVAL { 'ffffffff'h }
::= { docsDevNmAccessEntry 3 }
docsDevNmAccessIpMask OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-create STATUS current DESCRIPTION "The IP subnet mask of the network management stations. If traps are enabled for this entry, then the value must be 255.255.255.255." DEFVAL { 'ffffffff'h } ::= { docsDevNmAccessEntry 3 }
docsDevNmAccessCommunity OBJECT-TYPE
SYNTAX OCTET STRING
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The community string to be matched for access by this
entry. If set to a zero length string then any community
string will match. When read, this object SHOULD return
a zero length string."
DEFVAL { "public" }
::= { docsDevNmAccessEntry 4 }
docsDevNmAccessCommunity OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-create STATUS current DESCRIPTION "The community string to be matched for access by this entry. If set to a zero length string then any community string will match. When read, this object SHOULD return a zero length string." DEFVAL { "public" } ::= { docsDevNmAccessEntry 4 }
docsDevNmAccessControl OBJECT-TYPE
SYNTAX INTEGER {
none(1),
read(2),
readWrite(3),
roWithTraps(4),
rwWithTraps(5),
trapsOnly(6)
}
MAX-ACCESS read-create
docsDevNmAccessControl OBJECT-TYPE SYNTAX INTEGER { none(1), read(2), readWrite(3), roWithTraps(4), rwWithTraps(5), trapsOnly(6) } MAX-ACCESS read-create
St. Johns Standards [Page 17] RFC 2669 DOCSIS Cable Device MIB August 1999
St. Johns Standards [Page 17] RFC 2669 DOCSIS Cable Device MIB August 1999
STATUS current
DESCRIPTION
"Specifies the type of access allowed to this NMS. Setting
this object to none(1) causes the table entry to be
destroyed. Read(2) allows access by 'get' and 'get-next'
PDUs. ReadWrite(3) allows access by 'set' as well.
RoWithtraps(4), rwWithTraps(5), and trapsOnly(6)
control distribution of Trap PDUs transmitted by this
device."
DEFVAL { read }
::= { docsDevNmAccessEntry 5 }
STATUS current DESCRIPTION "Specifies the type of access allowed to this NMS. Setting this object to none(1) causes the table entry to be destroyed. Read(2) allows access by 'get' and 'get-next' PDUs. ReadWrite(3) allows access by 'set' as well. RoWithtraps(4), rwWithTraps(5), and trapsOnly(6) control distribution of Trap PDUs transmitted by this device." DEFVAL { read } ::= { docsDevNmAccessEntry 5 }
-- The syntax of the following object was copied from RFC1493, -- dot1dStaticAllowedToGoTo.
-- The syntax of the following object was copied from RFC1493, -- dot1dStaticAllowedToGoTo.
docsDevNmAccessInterfaces OBJECT-TYPE
SYNTAX OCTET STRING
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Specifies the set of interfaces from which requests from
this NMS will be accepted.
Each octet within the value of this object specifies a set
of eight interfaces, with the first octet specifying ports
1 through 8, the second octet specifying interfaces 9
through 16, etc. Within each octet, the most significant
bit represents the lowest numbered interface, and the least
significant bit represents the highest numbered interface.
Thus, each interface is represented by a single bit within
the value of this object. If that bit has a value of '1'
then that interface is included in the set.
docsDevNmAccessInterfaces OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-create STATUS current DESCRIPTION "Specifies the set of interfaces from which requests from this NMS will be accepted. Each octet within the value of this object specifies a set of eight interfaces, with the first octet specifying ports 1 through 8, the second octet specifying interfaces 9 through 16, etc. Within each octet, the most significant bit represents the lowest numbered interface, and the least significant bit represents the highest numbered interface. Thus, each interface is represented by a single bit within the value of this object. If that bit has a value of '1' then that interface is included in the set.
Note that entries in this table apply only to link-layer
interfaces (e.g., Ethernet and CATV MAC). Upstream and
downstream channel interfaces must not be specified."
-- DEFVAL is the bitmask corresponding to all interfaces
::= { docsDevNmAccessEntry 6 }
Note that entries in this table apply only to link-layer interfaces (e.g., Ethernet and CATV MAC). Upstream and downstream channel interfaces must not be specified." -- DEFVAL is the bitmask corresponding to all interfaces ::= { docsDevNmAccessEntry 6 }
docsDevNmAccessStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Controls and reflects the status of rows in this
table. Rows in this table may be created by either the
create-and-go or create-and-wait paradigms. There is no
restriction on changing values in a row of this table while
the row is active."
docsDevNmAccessStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "Controls and reflects the status of rows in this table. Rows in this table may be created by either the create-and-go or create-and-wait paradigms. There is no restriction on changing values in a row of this table while the row is active."
St. Johns Standards [Page 18] RFC 2669 DOCSIS Cable Device MIB August 1999
St. Johns Standards [Page 18] RFC 2669 DOCSIS Cable Device MIB August 1999
::= { docsDevNmAccessEntry 7 }
::= { docsDevNmAccessEntry 7 }
-- -- Procedures for using the following group are described in section -- 3.2.1 of the DOCSIS Radio Frequence Interface Specification --
-- -- Procedures for using the following group are described in section -- 3.2.1 of the DOCSIS Radio Frequence Interface Specification --
docsDevSoftware OBJECT IDENTIFIER ::= { docsDevMIBObjects 3 }
docsDevSoftware OBJECT IDENTIFIER ::= { docsDevMIBObjects 3 }
docsDevSwServer OBJECT-TYPE
SYNTAX IpAddress
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The address of the TFTP server used for software upgrades.
If the TFTP server is unknown, return 0.0.0.0."
::= { docsDevSoftware 1 }
docsDevSwServer OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-write STATUS current DESCRIPTION "The address of the TFTP server used for software upgrades. If the TFTP server is unknown, return 0.0.0.0." ::= { docsDevSoftware 1 }
docsDevSwFilename OBJECT-TYPE
SYNTAX SnmpAdminString (SIZE (0..64))
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The file name of the software image to be loaded into this
device. Unless set via SNMP, this is the file name
specified by the provisioning server that corresponds to
the software version that is desired for this device.
If unknown, the string '(unknown)' is returned."
::= { docsDevSoftware 2 }
docsDevSwFilename OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..64)) MAX-ACCESS read-write STATUS current DESCRIPTION "The file name of the software image to be loaded into this device. Unless set via SNMP, this is the file name specified by the provisioning server that corresponds to the software version that is desired for this device. If unknown, the string '(unknown)' is returned." ::= { docsDevSoftware 2 }
docsDevSwAdminStatus OBJECT-TYPE
SYNTAX INTEGER {
upgradeFromMgt(1),
allowProvisioningUpgrade(2),
ignoreProvisioningUpgrade(3)
}
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"If set to upgradeFromMgt(1), the device will initiate a
TFTP software image download using docsDevSwFilename.
After successfully receiving an image, the device will
set its state to ignoreProvisioningUpgrade(3) and reboot.
If the download process is interrupted by a reset or
power failure, the device will load the previous image
and, after re-initialization, continue to attempt loading
the image specified in docsDevSwFilename.
docsDevSwAdminStatus OBJECT-TYPE SYNTAX INTEGER { upgradeFromMgt(1), allowProvisioningUpgrade(2), ignoreProvisioningUpgrade(3) } MAX-ACCESS read-write STATUS current DESCRIPTION "If set to upgradeFromMgt(1), the device will initiate a TFTP software image download using docsDevSwFilename. After successfully receiving an image, the device will set its state to ignoreProvisioningUpgrade(3) and reboot. If the download process is interrupted by a reset or power failure, the device will load the previous image and, after re-initialization, continue to attempt loading the image specified in docsDevSwFilename.
St. Johns Standards [Page 19] RFC 2669 DOCSIS Cable Device MIB August 1999
St. Johns Standards [Page 19] RFC 2669 DOCSIS Cable Device MIB August 1999
If set to allowProvisioningUpgrade(2), the device will
use the software version information supplied by the
provisioning server when next rebooting (this does not
cause a reboot).
If set to allowProvisioningUpgrade(2), the device will use the software version information supplied by the provisioning server when next rebooting (this does not cause a reboot).
When set to ignoreProvisioningUpgrade(3), the device
will disregard software image upgrade information from the
provisioning server.
When set to ignoreProvisioningUpgrade(3), the device will disregard software image upgrade information from the provisioning server.
Note that reading this object can return upgradeFromMgt(1).
This indicates that a software download is currently in
progress, and that the device will reboot after
successfully receiving an image.
Note that reading this object can return upgradeFromMgt(1). This indicates that a software download is currently in progress, and that the device will reboot after successfully receiving an image.
At initial startup, this object has the default value of
allowProvisioningUpgrade(2)."
::= { docsDevSoftware 3 }
At initial startup, this object has the default value of allowProvisioningUpgrade(2)." ::= { docsDevSoftware 3 }
docsDevSwOperStatus OBJECT-TYPE
SYNTAX INTEGER {
inProgress(1),
completeFromProvisioning(2),
completeFromMgt(3),
failed(4),
other(5)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"InProgress(1) indicates that a TFTP download is underway,
either as a result of a version mismatch at provisioning
or as a result of a upgradeFromMgt request.
CompleteFromProvisioning(2) indicates that the last
software upgrade was a result of version mismatch at
provisioning. CompleteFromMgt(3) indicates that the last
software upgrade was a result of setting
docsDevSwAdminStatus to upgradeFromMgt.
Failed(4) indicates that the last attempted download
failed, ordinarily due to TFTP timeout."
REFERENCE
"DOCSIS Radio Frequency Interface Specification, Section
8.2, Downloading Cable Modem Operating Software."
::= { docsDevSoftware 4 }
docsDevSwOperStatus OBJECT-TYPE SYNTAX INTEGER { inProgress(1), completeFromProvisioning(2), completeFromMgt(3), failed(4), other(5) } MAX-ACCESS read-only STATUS current DESCRIPTION "InProgress(1) indicates that a TFTP download is underway, either as a result of a version mismatch at provisioning or as a result of a upgradeFromMgt request. CompleteFromProvisioning(2) indicates that the last software upgrade was a result of version mismatch at provisioning. CompleteFromMgt(3) indicates that the last software upgrade was a result of setting docsDevSwAdminStatus to upgradeFromMgt. Failed(4) indicates that the last attempted download failed, ordinarily due to TFTP timeout." REFERENCE "DOCSIS Radio Frequency Interface Specification, Section 8.2, Downloading Cable Modem Operating Software." ::= { docsDevSoftware 4 }
docsDevSwCurrentVers OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS read-only
STATUS current
docsDevSwCurrentVers OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current
St. Johns Standards [Page 20] RFC 2669 DOCSIS Cable Device MIB August 1999
St. Johns Standards [Page 20] RFC 2669 DOCSIS Cable Device MIB August 1999
DESCRIPTION
"The software version currently operating in this device.
This object should be in the syntax used by the individual
vendor to identify software versions. Any CM MUST return a
string descriptive of the current software load. For a
CMTS, this object SHOULD contain either a human readable
representation of the vendor specific designation of the
software for the chassis, or of the software for the
control processor. If neither of these is applicable,
this MUST contain an empty string."
::= { docsDevSoftware 5 }
DESCRIPTION "The software version currently operating in this device. This object should be in the syntax used by the individual vendor to identify software versions. Any CM MUST return a string descriptive of the current software load. For a CMTS, this object SHOULD contain either a human readable representation of the vendor specific designation of the software for the chassis, or of the software for the control processor. If neither of these is applicable, this MUST contain an empty string." ::= { docsDevSoftware 5 }
-- -- The following group describes server access and parameters used for -- initial provisioning and bootstrapping. --
-- -- The following group describes server access and parameters used for -- initial provisioning and bootstrapping. --
docsDevServer OBJECT IDENTIFIER ::= { docsDevMIBObjects 4 }
docsDevServer OBJECT IDENTIFIER ::= { docsDevMIBObjects 4 }
docsDevServerBootState OBJECT-TYPE
SYNTAX INTEGER {
operational(1),
disabled(2),
waitingForDhcpOffer(3),
waitingForDhcpResponse(4),
waitingForTimeServer(5),
waitingForTftp(6),
refusedByCmts(7),
forwardingDenied(8),
other(9),
unknown(10)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"If operational(1), the device has completed loading and
processing of configuration parameters and the CMTS has
completed the Registration exchange.
If disabled(2) then the device was administratively
disabled, possibly by being refused network access in the
configuration file.
If waitingForDhcpOffer(3) then a DHCP Discover has been
transmitted and no offer has yet been received.
If waitingForDhcpResponse(4) then a DHCP Request has been
transmitted and no response has yet been received.
If waitingForTimeServer(5) then a Time Request has been
transmitted and no response has yet been received.
docsDevServerBootState OBJECT-TYPE SYNTAX INTEGER { operational(1), disabled(2), waitingForDhcpOffer(3), waitingForDhcpResponse(4), waitingForTimeServer(5), waitingForTftp(6), refusedByCmts(7), forwardingDenied(8), other(9), unknown(10) } MAX-ACCESS read-only STATUS current DESCRIPTION "If operational(1), the device has completed loading and processing of configuration parameters and the CMTS has completed the Registration exchange. If disabled(2) then the device was administratively disabled, possibly by being refused network access in the configuration file. If waitingForDhcpOffer(3) then a DHCP Discover has been transmitted and no offer has yet been received. If waitingForDhcpResponse(4) then a DHCP Request has been transmitted and no response has yet been received. If waitingForTimeServer(5) then a Time Request has been transmitted and no response has yet been received.
St. Johns Standards [Page 21] RFC 2669 DOCSIS Cable Device MIB August 1999
St. Johns Standards [Page 21] RFC 2669 DOCSIS Cable Device MIB August 1999
If waitingForTftp(6) then a request to the TFTP parameter
server has been made and no response received.
If refusedByCmts(7) then the Registration Request/Response
exchange with the CMTS failed.
If forwardingDenied(8) then the registration process
completed, but the network access option in the received
configuration file prohibits forwarding. "
REFERENCE
"DOCSIS Radio Frequency Interface Specification, Figure
7-1, CM Initialization Overview."
::= { docsDevServer 1 }
If waitingForTftp(6) then a request to the TFTP parameter server has been made and no response received. If refusedByCmts(7) then the Registration Request/Response exchange with the CMTS failed. If forwardingDenied(8) then the registration process completed, but the network access option in the received configuration file prohibits forwarding. " REFERENCE "DOCSIS Radio Frequency Interface Specification, Figure 7-1, CM Initialization Overview." ::= { docsDevServer 1 }
docsDevServerDhcp OBJECT-TYPE
SYNTAX IpAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The IP address of the DHCP server that assigned an IP
address to this device. Returns 0.0.0.0 if DHCP was not
used for IP address assignment."
::= { docsDevServer 2 }
docsDevServerDhcp OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The IP address of the DHCP server that assigned an IP address to this device. Returns 0.0.0.0 if DHCP was not used for IP address assignment." ::= { docsDevServer 2 }
docsDevServerTime OBJECT-TYPE
SYNTAX IpAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The IP address of the Time server (RFC-868). Returns
0.0.0.0 if the time server IP address is unknown."
::= { docsDevServer 3 }
docsDevServerTime OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The IP address of the Time server (RFC-868). Returns 0.0.0.0 if the time server IP address is unknown." ::= { docsDevServer 3 }
docsDevServerTftp OBJECT-TYPE
SYNTAX IpAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The IP address of the TFTP server responsible for
downloading provisioning and configuration parameters
to this device. Returns 0.0.0.0 if the TFTP server
address is unknown."
::= { docsDevServer 4 }
docsDevServerTftp OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The IP address of the TFTP server responsible for downloading provisioning and configuration parameters to this device. Returns 0.0.0.0 if the TFTP server address is unknown." ::= { docsDevServer 4 }
docsDevServerConfigFile OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The name of the device configuration file read from the
docsDevServerConfigFile OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "The name of the device configuration file read from the
St. Johns Standards [Page 22] RFC 2669 DOCSIS Cable Device MIB August 1999
St. Johns Standards [Page 22] RFC 2669 DOCSIS Cable Device MIB August 1999
TFTP server. Returns an empty string if the configuration
file name is unknown."
::= { docsDevServer 5 }
TFTP server. Returns an empty string if the configuration file name is unknown." ::= { docsDevServer 5 }
-- -- Event Reporting --
-- -- Event Reporting --
docsDevEvent OBJECT IDENTIFIER ::= { docsDevMIBObjects 5 }
docsDevEvent OBJECT IDENTIFIER ::= { docsDevMIBObjects 5 }
docsDevEvControl OBJECT-TYPE
SYNTAX INTEGER {
resetLog(1),
useDefaultReporting(2)
}
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"Setting this object to resetLog(1) empties the event log.
All data is deleted. Setting it to useDefaultReporting(2)
returns all event priorities to their factory-default
reporting. Reading this object always returns
useDefaultReporting(2)."
::= { docsDevEvent 1 }
docsDevEvControl OBJECT-TYPE SYNTAX INTEGER { resetLog(1), useDefaultReporting(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "Setting this object to resetLog(1) empties the event log. All data is deleted. Setting it to useDefaultReporting(2) returns all event priorities to their factory-default reporting. Reading this object always returns useDefaultReporting(2)." ::= { docsDevEvent 1 }
docsDevEvSyslog OBJECT-TYPE
SYNTAX IpAddress
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The IP address of the Syslog server. If 0.0.0.0, syslog
transmission is inhibited."
::= { docsDevEvent 2 }
docsDevEvSyslog OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-write STATUS current DESCRIPTION "The IP address of the Syslog server. If 0.0.0.0, syslog transmission is inhibited." ::= { docsDevEvent 2 }
docsDevEvThrottleAdminStatus OBJECT-TYPE
SYNTAX INTEGER {
unconstrained(1),
maintainBelowThreshold(2),
stopAtThreshold(3),
inhibited(4)
}
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"Controls the transmission of traps and syslog messages
with respect to the trap pacing threshold.
unconstrained(1) causes traps and syslog messages to be
transmitted without regard to the threshold settings.
docsDevEvThrottleAdminStatus OBJECT-TYPE SYNTAX INTEGER { unconstrained(1), maintainBelowThreshold(2), stopAtThreshold(3), inhibited(4) } MAX-ACCESS read-write STATUS current DESCRIPTION "Controls the transmission of traps and syslog messages with respect to the trap pacing threshold. unconstrained(1) causes traps and syslog messages to be transmitted without regard to the threshold settings.
St. Johns Standards [Page 23] RFC 2669 DOCSIS Cable Device MIB August 1999
St. Johns Standards [Page 23] RFC 2669 DOCSIS Cable Device MIB August 1999
maintainBelowThreshold(2) causes trap transmission and
syslog messages to be suppressed if the number of traps
would otherwise exceed the threshold.
stopAtThreshold(3) causes trap transmission to cease
at the threshold, and not resume until directed to do so.
inhibited(4) causes all trap transmission and syslog
messages to be suppressed.
maintainBelowThreshold(2) causes trap transmission and syslog messages to be suppressed if the number of traps would otherwise exceed the threshold. stopAtThreshold(3) causes trap transmission to cease at the threshold, and not resume until directed to do so. inhibited(4) causes all trap transmission and syslog messages to be suppressed.
A single event is always treated as a single event for
threshold counting. That is, an event causing both a trap
and a syslog message is still treated as a single event.
単一の出来事は敷居勘定のためにいつも単一の出来事として扱われます。 すなわち、罠とsyslogメッセージの両方を引き起こす出来事はまだ単一の出来事として扱われています。
Writing to this object resets the thresholding state.
この物に書くのはthresholding状態をリセットします。
At initial startup, this object has a default value of
unconstrained(1)."
::= { docsDevEvent 3 }
「初期の始動では、この物は自由な(1)のデフォルト値を持っています。」 ::= docsDevEvent3
docsDevEvThrottleInhibited OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"If true(1), trap and syslog transmission is currently
inhibited due to thresholds and/or the current setting of
docsDevEvThrottleAdminStatus. In addition, this is set to
true(1) if transmission is inhibited due to no
syslog (docsDevEvSyslog) or trap (docsDevNmAccessEntry)
destinations having been set."
::= { docsDevEvent 4 }
docsDevEvThrottleInhibited OBJECT-TYPE SYNTAX TruthValueのマックス-ACCESSの書き込み禁止のSTATUSの現在の記述、「本当の(1)、罠、およびsyslogトランスミッションが現在敷居、そして/または、docsDevEvThrottleAdminStatusの現在の設定のため抑制されるなら」。 「トランスミッションが設定されていないsyslog(docsDevEvSyslog)か罠(docsDevNmAccessEntry)の目的地の全くため抑制されるなら、さらに、これは本当の(1)に設定されます。」 ::= docsDevEvent4
docsDevEvThrottleThreshold OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"Number of trap/syslog events per docsDevEvThrottleInterval
to be transmitted before throttling.
docsDevEvThrottleThreshold OBJECT-TYPE SYNTAX Unsigned32マックス-ACCESSは「数の阻止の前に伝えられるべきdocsDevEvThrottleIntervalあたりの罠/syslog出来事」をSTATUSの現在の記述に読書して書きます。
A single event is always treated as a single event for
threshold counting. That is, an event causing both a trap
and a syslog message is still treated as a single event.
単一の出来事は敷居勘定のためにいつも単一の出来事として扱われます。 すなわち、罠とsyslogメッセージの両方を引き起こす出来事はまだ単一の出来事として扱われています。
At initial startup, this object returns 0."
::= { docsDevEvent 5 }
「初期の始動では、この物は0を返します。」 ::= docsDevEvent5
docsDevEvThrottleInterval OBJECT-TYPE
SYNTAX Integer32 (1..2147483647)
docsDevEvThrottleIntervalオブジェクト・タイプ構文Integer32(1..2147483647)
St. Johns Standards [Page 24] RFC 2669 DOCSIS Cable Device MIB August 1999
ジョーンズStandards[24ページ]の聖RFC2669DOCSISは1999年8月に装置MIBに電報を打ちます。
UNITS "seconds"
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The interval over which the trap threshold applies.
At initial startup, this object has a value of 1."
UNITS「秒」マックス-ACCESSは「罠敷居が適用される間隔」をSTATUSの現在の記述に読書して書きます。 「初期の始動では、この物は1の値を持っています。」
::= { docsDevEvent 6 }
::= docsDevEvent6
-- -- The following table controls the reporting of the various classes of -- events. --
-- -- 以下は様々の報告が属するコントロールを見送ります--出来事。 --
docsDevEvControlTable OBJECT-TYPE
SYNTAX SEQUENCE OF DocsDevEvControlEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table allows control of the reporting of event classes.
For each event priority, a combination of logging and
reporting mechanisms may be chosen. The mapping of event types
to priorities is vendor-dependent. Vendors may also choose to
allow the user to control that mapping through proprietary
means."
::= { docsDevEvent 7 }
「このテーブルはイベントのクラスの報告のコントロールを許す」docsDevEvControlTable OBJECT-TYPEのSYNTAX SEQUENCE OF DocsDevEvControlEntryのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述。 それぞれのイベント優先権において、メカニズムを登録して、報告する組み合わせは選ばれるかもしれません。 プライオリティへのイベントタイプのマッピングは業者依存しています。 「また、業者は、ユーザが独占手段でそのマッピングを制御するのを許容するのを選ぶかもしれません。」 ::= docsDevEvent7
docsDevEvControlEntry OBJECT-TYPE
SYNTAX DocsDevEvControlEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Allows configuration of the reporting mechanisms for a
particular event priority."
INDEX { docsDevEvPriority }
::= { docsDevEvControlTable 1 }
docsDevEvControlEntry OBJECT-TYPE SYNTAX DocsDevEvControlEntryのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述は「特定のイベント優先のための報告メカニズムの構成を許します」。 docsDevEvPriorityに索引をつけてください:、:= docsDevEvControlTable1
DocsDevEvControlEntry ::= SEQUENCE {
docsDevEvPriority INTEGER,
docsDevEvReporting BITS
}
DocsDevEvControlEntry:、:= 系列docsDevEvPriority整数、docsDevEvReportingビット
docsDevEvPriority OBJECT-TYPE
SYNTAX INTEGER {
emergency(1),
alert(2),
critical(3),
docsDevEvPriority OBJECT-TYPE SYNTAX INTEGER、非常時(1)、警戒(2)、批判的な(3)
St. Johns Standards [Page 25] RFC 2669 DOCSIS Cable Device MIB August 1999
ジョーンズStandards[25ページ]の聖RFC2669DOCSISは1999年8月に装置MIBに電報を打ちます。
error(4),
warning(5),
notice(6),
information(7),
debug(8)
}
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The priority level that is controlled by this
entry. These are ordered from most (emergency) to least
(debug) critical. Each event with a CM or CMTS has a
particular priority level associated with it (as defined
by the vendor). During normal operation no event more
critical than notice(6) should be generated. Events between
warning and emergency should be generated at appropriate
levels of problems (e.g. emergency when the box is about to
crash)."
::= { docsDevEvControlEntry 1 }
(5) 通知(6)、情報(7)が(8)をデバッグすると警告する誤り(4) マックス-ACCESSのアクセスしやすくないSTATUS現在の記述、「このエントリーで制御される優先順位。」 これらは大部分(非常時)から最少(デバッグする)批判的になるまで命令されます。 CMかCMTSがある各出来事には、それに関連している特定の優先順位があります(業者によって定義されるように)。 通常の操作の間、通知(6)より批判的などんなイベントも発生するべきではありません。 「警告と非常時の間の出来事は適正水準の問題(例えば、箱がクラッシュしようとしている非常時)で発生するべきです。」 ::= docsDevEvControlEntry1
docsDevEvReporting OBJECT-TYPE
SYNTAX BITS {
local(0),
traps(1),
syslog(2)
}
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"Defines the action to be taken on occurrence of this
event class. Implementations may not necessarily support
all options for all event classes, but at minimum must
allow traps and syslogging to be disabled. If the
local(0) bit is set, then log to the internal log, if the
traps(1) bit is set, then generate a trap, if the
syslog(2) bit is set, then send a syslog message
(assuming the syslog address is set)."
::= { docsDevEvControlEntry 2 }
docsDevEvReporting OBJECT-TYPE SYNTAX BITS、地方の(0)、罠(1)、マックス-ACCESSが現在の記述が「このイベントのクラスの発生で取って、動作を定義する」STATUSに読書して書くsyslog(2)。 実現は、罠とsysloggingが無効にされるのをすべてのイベントのクラスのために必ずすべてのオプションをサポートするかもしれないというわけではありませんが、最小限で許容しなければなりません。 「地方の(0)ビットがセット、内部のログへの当時のログであるなら、罠(1)ビットが設定されるなら、syslog(2)ビットが設定されるなら、罠を発生させてください、そして、次に、syslogメッセージ(syslogがアドレスであると仮定するのが設定される)を送ってください。」 ::= docsDevEvControlEntry2
docsDevEventTable OBJECT-TYPE
SYNTAX SEQUENCE OF DocsDevEventEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Contains a log of network and device events that may be
of interest in fault isolation and troubleshooting."
::= { docsDevEvent 8 }
docsDevEventTable OBJECT-TYPE SYNTAX SEQUENCE OF DocsDevEventEntryのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述は「欠点孤立への関心があるかもしれなくて、障害調査されているネットワークと装置出来事に関するログを含んでいます」。 ::= docsDevEvent8
St. Johns Standards [Page 26] RFC 2669 DOCSIS Cable Device MIB August 1999
ジョーンズStandards[26ページ]の聖RFC2669DOCSISは1999年8月に装置MIBに電報を打ちます。
docsDevEventEntry OBJECT-TYPE
SYNTAX DocsDevEventEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Describes a network or device event that may be of
interest in fault isolation and troubleshooting. Multiple
sequential identical events are represented by
incrementing docsDevEvCounts and setting
docsDevEvLastTime to the current time rather than creating
multiple rows.
docsDevEventEntry OBJECT-TYPE SYNTAX DocsDevEventEntryのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述は「欠点孤立への関心があるかもしれなくて、障害調査されているネットワークか装置出来事について説明します」。 複数の連続した同じ出来事が、複数の列を作成するよりむしろ現在の時間にdocsDevEvCountsを増加して、docsDevEvLastTimeを設定することによって、表されます。
Entries are created with the first occurrance of an event.
docsDevEvControl can be used to clear the table.
Individual events can not be deleted."
INDEX { docsDevEvIndex }
出来事の最初のoccurranceでエントリーを作成します。テーブルをきれいにするのにdocsDevEvControlを使用できます。 「個人種目を削除できません。」 インデックスdocsDevEvIndex
::= { docsDevEventTable 1 }
::= docsDevEventTable1
DocsDevEventEntry ::= SEQUENCE {
docsDevEvIndex Integer32,
docsDevEvFirstTime DateAndTime,
docsDevEvLastTime DateAndTime,
docsDevEvCounts Counter32,
docsDevEvLevel INTEGER,
docsDevEvId Unsigned32,
docsDevEvText SnmpAdminString
}
DocsDevEventEntry:、:= 系列docsDevEvIndex Integer32、docsDevEvFirstTime DateAndTime、docsDevEvLastTime DateAndTime、docsDevEvCounts Counter32、docsDevEvLevel整数、docsDevEvId Unsigned32、docsDevEvText SnmpAdminString
docsDevEvIndex OBJECT-TYPE
SYNTAX Integer32 (1..2147483647)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Provides relative ordering of the objects in the event
log. This object will always increase except when
(a) the log is reset via docsDevEvControl,
(b) the device reboots and does not implement non-volatile
storage for this log, or (c) it reaches the value 2^31.
The next entry for all the above cases is 1."
::= { docsDevEventEntry 1 }
docsDevEvIndex OBJECT-TYPE SYNTAX Integer32(1 .2147483647)のマックス-ACCESSのアクセスしやすくないSTATUS現在の記述は「イベントログにおける、物の相対的な注文を提供します」。 (a) ログがdocsDevEvControlを通してリセットされるか、(b) 装置がリブートして、このログのために非揮発性記憶装置を実行しないか、または(c) それが値2^31に達する時を除いて、この物はいつも増加するでしょう。 「すべての上のケースのための次のエントリーは1です。」 ::= docsDevEventEntry1
docsDevEvFirstTime OBJECT-TYPE
SYNTAX DateAndTime
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The time that this entry was created."
「このエントリーが作成された時間」の間のdocsDevEvFirstTime OBJECT-TYPE SYNTAX DateAndTimeのマックス-ACCESSの書き込み禁止のSTATUSの現在の記述。
St. Johns Standards [Page 27] RFC 2669 DOCSIS Cable Device MIB August 1999
ジョーンズStandards[27ページ]の聖RFC2669DOCSISは1999年8月に装置MIBに電報を打ちます。
::= { docsDevEventEntry 2 }
::= docsDevEventEntry2
docsDevEvLastTime OBJECT-TYPE
SYNTAX DateAndTime
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"If multiple events are reported via the same entry, the
time that the last event for this entry occurred,
otherwise this should have the same value as
docsDevEvFirstTime. "
::= { docsDevEventEntry 3 }
docsDevEvLastTime OBJECT-TYPE SYNTAX DateAndTimeのマックス-ACCESSの書き込み禁止のSTATUSの現在の記述、「複数の出来事が同じエントリーを通って報告されるなら、これには、さもなければ、このエントリーへの最後の出来事が起こった時に、docsDevEvFirstTimeと同じ値があるべきです」。 " ::= docsDevEventEntry3
-- This object was renamed from docsDevEvCount to meet naming
-- requirements for Counter32
docsDevEvCounts OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of consecutive event instances reported by
this entry. This starts at 1 with the creation of this
row and increments by 1 for each subsequent duplicate
event."
::= { docsDevEventEntry 4 }
-- この物は命名を満たすためにdocsDevEvCountから改名されました--Counter32 docsDevEvCounts OBJECT-TYPE SYNTAX Counter32のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述のための「このエントリーで報告された連続したイベント例の数」という要件。 「これは1時にその後の写し出来事毎あたり1時までにこの列と増分の創造から始まります。」 ::= docsDevEventEntry4
docsDevEvLevel OBJECT-TYPE
SYNTAX INTEGER {
emergency(1),
alert(2),
critical(3),
error(4),
warning(5),
notice(6),
information(7),
debug(8)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The priority level of this event as defined by the
vendor. These are ordered from most serious (emergency)
to least serious (debug)."
::= { docsDevEventEntry 5 }
docsDevEvLevel OBJECT-TYPE SYNTAX INTEGER、非常時(1)、警戒(2)、批判的な(3)、誤り(4)、警告(5)、通知(6)、情報(7)が(8)をデバッグする、マックス-ACCESSの書き込み禁止のSTATUSの現在の記述、「定義されるとしての業者によるこの出来事の優先順位。」 「これらを最も重大な(非常時)から最も重大でない(デバッグ)に取り寄せます。」 ::= docsDevEventEntry5
-- -- Vendors will provide their own enumerations for the following. -- The interpretation of the enumeration is unambiguous for a
-- -- 業者は以下のためのそれら自身の列挙を提供するでしょう。 -- aに、列挙の解釈は明白です。
St. Johns Standards [Page 28] RFC 2669 DOCSIS Cable Device MIB August 1999
ジョーンズStandards[28ページ]の聖RFC2669DOCSISは1999年8月に装置MIBに電報を打ちます。
-- particular value of the vendor's enterprise number in sysObjectID. --
-- sysObjectIDの業者の企業番号の特定の値。 --
docsDevEvId OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"For this product, uniquely identifies the type of event
that is reported by this entry."
::= { docsDevEventEntry 6 }
docsDevEvId OBJECT-TYPE SYNTAX Unsigned32のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述、「この製品、唯一このエントリーで報告される出来事のタイプを特定する、」 ::= docsDevEventEntry6
docsDevEvText OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Provides a human-readable description of the event,
including all relevant context (interface numbers,
etc.)."
::= { docsDevEventEntry 7 }
docsDevEvText OBJECT-TYPE SYNTAX SnmpAdminStringのマックス-ACCESSの書き込み禁止のSTATUSの現在の記述は「すべての関連文脈(インタフェース番号など)を含む出来事の人間読み込み可能な記述を提供します」。 ::= docsDevEventEntry7
docsDevFilter OBJECT IDENTIFIER ::= { docsDevMIBObjects 6 }
docsDevFilter物の識別子:、:= docsDevMIBObjects6
-- -- Link Level Control Filtering --
-- -- レベルコントロールフィルタリングをリンクしてください--
-- docsDevFilterLLCDefault renamed to docsDevFilterLLCUnmatchedAction
-- docsDevFilterLLCUnmatchedActionに改名されたdocsDevFilterLLCDefault
docsDevFilterLLCUnmatchedAction OBJECT-TYPE
SYNTAX INTEGER {
discard(1),
accept(2)
}
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"LLC (Link Level Control) filters can be defined on an
inclusive or exclusive basis: CMs can be configured to
forward only packets matching a set of layer three
protocols, or to drop packets matching a set of layer
three protocols. Typical use of these filters is to
filter out possibly harmful (given the context of a large
metropolitan LAN) protocols.
docsDevFilterLLCUnmatchedAction OBJECT-TYPE SYNTAX INTEGERは(1)を捨てて、(2)を受け入れます。マックス-ACCESSは「包括的であるか唯一のベースでLLC(リンクLevel Control)フィルタを定義できること」をSTATUSの現在の記述に読書して書きます。 合っているaが設定した層のパケットだけに3つのプロトコルを送るためにCMを構成できます、または、低下するために、合っているaがセットしたパケットは3つのプロトコルを層にします。 これらのフィルタの典型的な使用はことによると有害な(大きい首都のLANの文脈を与える)プロトコルを無視することです。
If set to discard(1), any L2 packet which does not match at
(1)、合っていないどんなL2パケットも捨てるために設定
St. Johns Standards [Page 29] RFC 2669 DOCSIS Cable Device MIB August 1999
ジョーンズStandards[29ページ]の聖RFC2669DOCSISは1999年8月に装置MIBに電報を打ちます。
least one filter in the docsDevFilterLLCTable will be
discarded. If set to accept(2), any L2 packet which does not
match at least one filter in the docsDevFilterLLCTable
will be accepted for further processing (e.g., bridging).
At initial system startup, this object returns accept(2)."
::= { docsDevFilter 1 }
docsDevFilterLLCTableの最少の1個のフィルタが捨てられるでしょう。 (2)を受け入れるように設定すると、さらなる処理(例えば、橋を架ける)のためにdocsDevFilterLLCTableの少なくとも1個のフィルタに合っていないどんなL2パケットも受け入れるでしょう。 「初期のシステム起動では、この物のリターンは(2)を受け入れます。」 ::= docsDevFilter1
docsDevFilterLLCTable OBJECT-TYPE
SYNTAX SEQUENCE OF DocsDevFilterLLCEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A list of filters to apply to (bridged) LLC
traffic. The filters in this table are applied to
incoming traffic on the appropriate interface(s) prior
to any further processing (e.g. before handing the packet
off for level 3 processing, or for bridging). The
specific action taken when no filter is matched is
controlled by docsDevFilterLLCUnmatchedAction."
::= { docsDevFilter 2 }
「Aは(橋を架けられます)LLC交通に適用するためにフィルタについて記載する」docsDevFilterLLCTable OBJECT-TYPEのSYNTAX SEQUENCE OF DocsDevFilterLLCEntryのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述。 このテーブルのフィルタはどんなさらなる処理(例えば、レベル3 処理、または橋を架けるためにパケットを渡す前の)の前にも適切なインタフェースにおける入って来る交通に適用されます。 「どんなフィルタも取り組んでいないとき取られた特定の行動はdocsDevFilterLLCUnmatchedActionによって制御されます。」 ::= docsDevFilter2
docsDevFilterLLCEntry OBJECT-TYPE
SYNTAX DocsDevFilterLLCEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Describes a single filter to apply to (bridged) LLC traffic
received on a specified interface. "
INDEX { docsDevFilterLLCIndex }
::= { docsDevFilterLLCTable 1 }
docsDevFilterLLCEntry OBJECT-TYPE SYNTAX DocsDevFilterLLCEntryのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述は「指定されたインタフェースで受けられた(橋を架けられます)LLC交通に適用するために単一のフィルタについて説明します」。 「docsDevFilterLLCIndexに索引をつけてください:、:、」= docsDevFilterLLCTable1
DocsDevFilterLLCEntry ::= SEQUENCE {
docsDevFilterLLCIndex Integer32,
docsDevFilterLLCStatus RowStatus,
docsDevFilterLLCIfIndex InterfaceIndexOrZero,
docsDevFilterLLCProtocolType INTEGER,
docsDevFilterLLCProtocol Integer32,
docsDevFilterLLCMatches Counter32
}
DocsDevFilterLLCEntry:、:= 系列docsDevFilterLLCIndex Integer32、docsDevFilterLLCStatus RowStatus、docsDevFilterLLCIfIndex InterfaceIndexOrZero、docsDevFilterLLCProtocolType整数、docsDevFilterLLCProtocol Integer32、docsDevFilterLLCMatches Counter32
docsDevFilterLLCIndex OBJECT-TYPE
SYNTAX Integer32 (1..2147483647)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Index used for the identification of filters (note that LLC
filter order is irrelevant)."
::= { docsDevFilterLLCEntry 1 }
「インデックスはフィルタ(LLCフィルタオーダーが無関係であることに注意する)の識別に使用した」docsDevFilterLLCIndex OBJECT-TYPE SYNTAX Integer32(1 .2147483647)のマックス-ACCESSのアクセスしやすくないSTATUS現在の記述。 ::= docsDevFilterLLCEntry1
St. Johns Standards [Page 30] RFC 2669 DOCSIS Cable Device MIB August 1999
ジョーンズStandards[30ページ]の聖RFC2669DOCSISは1999年8月に装置MIBに電報を打ちます。
docsDevFilterLLCStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Controls and reflects the status of rows in this
table. There is no restriction on changing any of the
associated columns for this row while this object is set
to active."
docsDevFilterLLCStatus OBJECT-TYPE SYNTAX RowStatusマックス-ACCESSはSTATUSの現在の記述を読書して作成します。「このテーブルの列の状態を制御して、反映します」。 「この物がアクティブに設定されている間、この列のための関連コラムのどれかを変えるときの制限が全くありません。」
::= { docsDevFilterLLCEntry 2}
::= docsDevFilterLLCEntry2
docsDevFilterLLCIfIndex OBJECT-TYPE
SYNTAX InterfaceIndexOrZero
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The entry interface to which this filter applies.
The value corresponds to ifIndex for either a CATV MAC
or another network interface. If the value is zero, the
filter applies to all interfaces. In Cable Modems, the
default value is the customer side interface. In Cable
Modem Termination Systems, this object has to be
specified to create a row in this table."
::= { docsDevFilterLLCEntry 3 }
docsDevFilterLLCIfIndex OBJECT-TYPE SYNTAX InterfaceIndexOrZeroマックス-ACCESSは「エントリーはこのフィルタが適用するものに連結する」STATUSの現在の記述を読書して作成します。 値はCATV MACかネットワーク・インターフェースのどちらかへの別ifIndexに対応しています。 値がゼロであるなら、フィルタはすべてのインタフェースに適用されます。 Cable Modemsでは、デフォルト値は顧客サイドインタフェースです。 「Cable Modem Termination Systemsでは、この物はこのテーブルの列を作成するために指定されなければなりません。」 ::= docsDevFilterLLCEntry3
docsDevFilterLLCProtocolType OBJECT-TYPE
SYNTAX INTEGER {
ethertype(1),
dsap(2)
}
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The format of the value in docsDevFilterLLCProtocol:
either a two-byte Ethernet Ethertype, or a one-byte
802.2 SAP value. EtherType(1) also applies to SNAP-
encapsulated frames."
DEFVAL { ethertype }
::= { docsDevFilterLLCEntry 4 }
docsDevFilterLLCProtocolType OBJECT-TYPE SYNTAX INTEGER、ethertype(1)、マックス-ACCESSがSTATUS現在に読書して作成するdsap(2)、記述、「docsDevFilterLLCProtocolの価値の形式:」 2バイトのイーサネットEthertypeか1バイトの802.2SAP価値のどちらか。 「また、EtherType(1)はSNAPの要約のフレームに適用します。」 DEFVALは以下をethertypeします:= docsDevFilterLLCEntry4
docsDevFilterLLCProtocol OBJECT-TYPE
SYNTAX Integer32 (0..65535)
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The layer three protocol for which this filter applies.
The protocol value format depends on
docsDevFilterLLCProtocol OBJECT-TYPE SYNTAX Integer32(0 .65535)マックス-ACCESSは「層threeはこのフィルタが適用するもののために議定書の中で述べる」STATUSの現在の記述を読書して作成します。 形式が依存するプロトコル値
St. Johns Standards [Page 31] RFC 2669 DOCSIS Cable Device MIB August 1999
ジョーンズStandards[31ページ]の聖RFC2669DOCSISは1999年8月に装置MIBに電報を打ちます。
docsDevFilterLLCProtocolType. Note that for SNAP frames,
etherType filtering is performed rather than DSAP=0xAA."
DEFVAL { 0 }
::= { docsDevFilterLLCEntry 5 }
docsDevFilterLLCProtocolType。 「SNAPフレームに関して、etherTypeフィルタリングがDSAP=0xAAよりむしろ実行されることに注意してください。」 DEFVAL0:、:= docsDevFilterLLCEntry5
docsDevFilterLLCMatches OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Counts the number of times this filter was matched."
::= { docsDevFilterLLCEntry 6 }
docsDevFilterLLCMatches OBJECT-TYPE SYNTAX Counter32のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述は「このフィルタが合わせられたという回の数を数えます」。 ::= docsDevFilterLLCEntry6
-- The default behavior for (bridged) packets that do not match IP -- filters is defined by -- docsDevFilterIpDefault.
-- IPに合っていない(橋を架けられます)パケットのためのデフォルトの振舞い--フィルタは定義されます--docsDevFilterIpDefault。
docsDevFilterIpDefault OBJECT-TYPE
SYNTAX INTEGER {
discard(1),
accept(2)
}
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"If set to discard(1), all packets not matching an IP filter
will be discarded. If set to accept(2), all packets not
matching an IP filter will be accepted for further
processing (e.g., bridging).
At initial system startup, this object returns accept(2)."
::= { docsDevFilter 3 }
docsDevFilterIpDefault OBJECT-TYPE SYNTAX INTEGERは(1)を捨てて、(2)を受け入れます。マックス-ACCESSは「(1)を捨てるように設定されると、IPフィルタに合っていないすべてのパケットが捨てられること」をSTATUSの現在の記述に読書して書きます。 (2)を受け入れるように設定すると、さらなる処理(例えば、橋を架ける)のためにIPフィルタに合っていないすべてのパケットを受け入れるでしょう。 「初期のシステム起動では、この物のリターンは(2)を受け入れます。」 ::= docsDevFilter3
docsDevFilterIpTable OBJECT-TYPE
SYNTAX SEQUENCE OF DocsDevFilterIpEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An ordered list of filters or classifiers to apply to
IP traffic. Filter application is ordered by the filter
index, rather than by a best match algorithm (Note that
this implies that the filter table may have gaps in the
index values). Packets which match no filters will have
policy 0 in the docsDevFilterPolicyTable applied to them if
it exists. Otherwise, Packets which match no filters
are discarded or forwarded according to the setting of
docsDevFilterIpDefault.
docsDevFilterIpTable OBJECT-TYPEのSYNTAX SEQUENCE OF DocsDevFilterIpEntryのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述、「IP交通に適用するフィルタかクラシファイアの規則正しいリスト。」 フィルタアプリケーションは最も良いマッチアルゴリズムでというよりむしろフィルタインデックスによって注文されます(これが、フィルタテーブルにはインデックス値におけるギャップがあるかもしれないのを含意することに注意してください)。 フィルタに全く合っていないパケットが存在しているならそれらに適用されたdocsDevFilterPolicyTableに方針0を持つでしょう。 さもなければ、docsDevFilterIpDefaultの設定に応じて、フィルタに全く合っていないPacketsを捨てるか、または進めます。
Any IP packet can theoretically match multiple rows of
缶が理論的に複数の列に合っているどんなIPパケット
St. Johns Standards [Page 32] RFC 2669 DOCSIS Cable Device MIB August 1999
ジョーンズStandards[32ページ]の聖RFC2669DOCSISは1999年8月に装置MIBに電報を打ちます。
this table. When considering a packet, the table is
scanned in row index order (e.g. filter 10 is checked
before filter 20). If the packet matches that filter
(which means that it matches ALL criteria for that row),
actions appropriate to docsDevFilterIpControl and
docsDevFilterPolicyId are taken. If the packet was
discarded processing is complete. If
docsDevFilterIpContinue is set to true, the filter
comparison continues with the next row in the table
looking for additional matches.
このテーブル。 パケットを考えるとき、テーブルは列のインデックスオーダーでスキャンされます(例えばフィルタ10はフィルタ20の前でチェックされます)。 パケットがそのフィルタ(その列のすべての評価基準を合わせることを意味する)に合っているなら、docsDevFilterIpControlとdocsDevFilterPolicyIdに適切な行動を取ります。 パケットが捨てられたなら、処理は完全です。 docsDevFilterIpContinueが本当に用意ができているなら、フィルタ比較は、追加マッチを探しながら、テーブルの次の列を続行します。
If the packet matches no filter in the table, the packet
is accepted or dropped for further processing based on
the setting of docsDevFilterIpDefault. If the packet is
accepted, the actions specified by policy group 0
(e.g. the rows in docsDevFilterPolicyTable which have a
value of 0 for docsDevFilterPolicyId) are taken if that
policy group exists.
パケットがテーブルでフィルタに全く合っていないなら、docsDevFilterIpDefaultの設定に基づくさらなる処理のために、パケットを受け入れるか、または落とします。 パケットを受け入れるなら、その方針グループが存在するなら、方針グループ0(例えば、docsDevFilterPolicyIdのための0の値を持っているdocsDevFilterPolicyTableの列)によって指定された行動を取ります。
Logically, this table is consulted twice during the
processing of any IP packet - once upon its acceptance
from the L2 entity, and once upon its transmission to the
L2 entity. In actuality, for cable modems, IP filtering
is generally the only IP processing done for transit
traffic. This means that inbound and outbound filtering
can generally be done at the same time with one pass
through the filter table."
::= { docsDevFilter 4 }
論理的に、このテーブルはどんなIPパケットの処理の間も、トランスミッションに関してL2実体に二度L2実体からの承認と、一度一度相談されます。 現実では、ケーブルモデムに関して、一般に、IPフィルタリングはトランジット交通に行われた唯一のIP処理です。 「これは、一般に、同時にフィルタテーブルを通して1個のパスで本国行きの、そして、外国行きのフィルタリングができることを意味します。」 ::= docsDevFilter4
docsDevFilterIpEntry OBJECT-TYPE
SYNTAX DocsDevFilterIpEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Describes a filter to apply to IP traffic received on a
specified interface. All identity objects in this table
(e.g. source and destination address/mask, protocol,
source/dest port, TOS/mask, interface and direction) must
match their respective fields in the packet for any given
filter to match.
docsDevFilterIpEntry OBJECT-TYPE SYNTAX DocsDevFilterIpEntryのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述は「指定されたインタフェースで受けられたIP交通に適用するためにフィルタについて説明します」。 このテーブル(例えば、ソース、目的地アドレス/マスク、プロトコル、ソース/destポート、TOS/マスク、インタフェース、および指示)のすべてのアイデンティティ物がどんな与えられたフィルタも合っているパケットの彼らのそれぞれの分野に合わなければなりません。
To create an entry in this table, docsDevFilterIpIfIndex
must be specified."
INDEX { docsDevFilterIpIndex }
::= { docsDevFilterIpTable 1 }
「このテーブルでエントリーを作成するために、docsDevFilterIpIfIndexを指定しなければなりません。」 docsDevFilterIpIndexに索引をつけてください:、:= docsDevFilterIpTable1
DocsDevFilterIpEntry ::= SEQUENCE {
docsDevFilterIpIndex Integer32,
DocsDevFilterIpEntry:、:= 系列、docsDevFilterIpIndex Integer32
St. Johns Standards [Page 33] RFC 2669 DOCSIS Cable Device MIB August 1999
ジョーンズStandards[33ページ]の聖RFC2669DOCSISは1999年8月に装置MIBに電報を打ちます。
docsDevFilterIpStatus RowStatus,
docsDevFilterIpControl INTEGER,
docsDevFilterIpIfIndex InterfaceIndexOrZero,
docsDevFilterIpDirection INTEGER,
docsDevFilterIpBroadcast TruthValue,
docsDevFilterIpSaddr IpAddress,
docsDevFilterIpSmask IpAddress,
docsDevFilterIpDaddr IpAddress,
docsDevFilterIpDmask IpAddress,
docsDevFilterIpProtocol Integer32,
docsDevFilterIpSourcePortLow Integer32,
docsDevFilterIpSourcePortHigh Integer32,
docsDevFilterIpDestPortLow Integer32,
docsDevFilterIpDestPortHigh Integer32,
docsDevFilterIpMatches Counter32,
docsDevFilterIpTos OCTET STRING,
docsDevFilterIpTosMask OCTET STRING,
docsDevFilterIpContinue TruthValue,
docsDevFilterIpPolicyId Integer32
}
docsDevFilterIpStatus RowStatus、docsDevFilterIpControl整数、docsDevFilterIpIfIndex InterfaceIndexOrZero、docsDevFilterIpDirection整数、docsDevFilterIpBroadcast TruthValue、docsDevFilterIpSaddr IpAddress、docsDevFilterIpSmask IpAddress、docsDevFilterIpDaddr IpAddress、docsDevFilterIpDmask IpAddress、docsDevFilterIpProtocol Integer32; docsDevFilterIpSourcePortLow Integer32、docsDevFilterIpSourcePortHigh Integer32、docsDevFilterIpDestPortLow Integer32、docsDevFilterIpDestPortHigh Integer32、docsDevFilterIpMatches Counter32、docsDevFilterIpTos八重奏ストリング、docsDevFilterIpTosMask八重奏ストリング、docsDevFilterIpContinue TruthValue、docsDevFilterIpPolicyId Integer32
docsDevFilterIpIndex OBJECT-TYPE
SYNTAX Integer32 (1..2147483647)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Index used to order the application of filters.
The filter with the lowest index is always applied
first."
::= { docsDevFilterIpEntry 1 }
「インデックスはフィルタのアプリケーションを注文するのに使用した」docsDevFilterIpIndex OBJECT-TYPE SYNTAX Integer32(1 .2147483647)のマックス-ACCESSのアクセスしやすくないSTATUS現在の記述。 「最も低いインデックスがあるフィルタは最初に、いつも適用されます。」 ::= docsDevFilterIpEntry1
docsDevFilterIpStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Controls and reflects the status of rows in this
table. Specifying only this object (with the appropriate
index) on a CM is sufficient to create a filter row which
matches all inbound packets on the ethernet interface,
and results in the packets being
discarded. docsDevFilterIpIfIndex (at least) must be
specified on a CMTS to create a row. Creation of the
rows may be done via either create-and-wait or
create-and-go, but the filter is not applied until this
object is set to (or changes to) active. There is no
restriction in changing any object in a row while this
object is set to active."
docsDevFilterIpStatus OBJECT-TYPE SYNTAX RowStatusマックス-ACCESSはSTATUSの現在の記述を読書して作成します。「このテーブルの列の状態を制御して、反映します」。 CMでこの物(適切なインデックスがある)だけを指定すると、捨てられて、イーサネットインタフェースのすべての本国行きのパケット、およびパケットの結果に合っているフィルタ列は作成できます。列を作成するためにCMTSでdocsDevFilterIpIfIndexを(少なくとも)指定しなければなりません。 または、どちらかを通して列の創造をするかもしれない、作成して、待ち、作成して、行く、この物が設定されるまでフィルタが適用されていない、(変化する、)、アクティブです。 「この物がアクティブに設定されている間、並んでいるどんな物も変えるのにおいて制限が全くありません。」
St. Johns Standards [Page 34] RFC 2669 DOCSIS Cable Device MIB August 1999
ジョーンズStandards[34ページ]の聖RFC2669DOCSISは1999年8月に装置MIBに電報を打ちます。
::= { docsDevFilterIpEntry 2 }
::= docsDevFilterIpEntry2
docsDevFilterIpControl OBJECT-TYPE
SYNTAX INTEGER {
discard(1),
accept(2),
policy(3)
}
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"If set to discard(1), all packets matching this filter
will be discarded and scanning of the remainder of the
filter list will be aborted. If set to accept(2), all
packets matching this filter will be accepted for further
processing (e.g., bridging). If docsDevFilterIpContinue
is set to true, see if there are other matches, otherwise
done. If set to policy (3), execute the policy entries
matched by docsDevIpFilterPolicyId in
docsDevIpFilterPolicyTable.
docsDevFilterIpControl OBJECT-TYPE SYNTAX INTEGERは(1)を捨てて、(2)、方針(3)を受け入れます。「セットして、(1)を捨ててください、そして、このフィルタに合っているすべてのパケットが捨てられて、フィルタリストの残りのスキャンは中止される」なら、マックス-ACCESSがSTATUSの現在の記述を読書して作成します。 (2)を受け入れるように設定すると、さらなる処理(例えば、橋を架ける)のためにこのフィルタに合っているすべてのパケットを受け入れるでしょう。 docsDevFilterIpContinueが本当に用意ができているなら、別の方法で行われた他のマッチがあるかどうかを見てください。 方針(3)に設定されるなら、docsDevIpFilterPolicyTableでdocsDevIpFilterPolicyIdによって合われていた方針エントリーを実行してください。
If is docsDevFilterIpContinue is set to true, continue
scanning the table for other matches, otherwise done."
DEFVAL { discard }
::= { docsDevFilterIpEntry 3 }
「docsDevFilterIpContinueが本当に用意ができているということであり、別の方法で行われた他のマッチのためにテーブルをスキャンし続けている、」 DEFVALは以下を捨てます:= docsDevFilterIpEntry3
docsDevFilterIpIfIndex OBJECT-TYPE
SYNTAX InterfaceIndexOrZero
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The entry interface to which this filter applies. The
value corresponds to ifIndex for either a CATV MAC or
another network interface. If the value is zero, the
filter applies to all interfaces. Default value in Cable
Modems is the index of the customer-side (e.g. ethernet)
interface. In Cable Modem Termination Systems, this
object MUST be specified to create a row in this table."
::= { docsDevFilterIpEntry 4 }
docsDevFilterIpIfIndex OBJECT-TYPE SYNTAX InterfaceIndexOrZeroマックス-ACCESSは「エントリーはこのフィルタが適用するものに連結する」STATUSの現在の記述を読書して作成します。 値はCATV MACかネットワーク・インターフェースのどちらかへの別ifIndexに対応しています。 値がゼロであるなら、フィルタはすべてのインタフェースに適用されます。 Cable Modemsのデフォルト値は顧客サイド(例えば、イーサネット)インタフェースのインデックスです。 「Cable Modem Termination Systemsでは、このテーブルの列を作成するためにこの物を指定しなければなりません。」 ::= docsDevFilterIpEntry4
docsDevFilterIpDirection OBJECT-TYPE
SYNTAX INTEGER {
inbound(1),
outbound(2),
both(3)
}
MAX-ACCESS read-create
STATUS current
docsDevFilterIpDirection OBJECT-TYPE SYNTAX INTEGER、本国行きの(1)、外国行きの(2)、両方、(3)、マックス-ACCESSはSTATUS海流を読書して引き起こします。
St. Johns Standards [Page 35] RFC 2669 DOCSIS Cable Device MIB August 1999
ジョーンズStandards[35ページ]の聖RFC2669DOCSISは1999年8月に装置MIBに電報を打ちます。
DESCRIPTION
"Determines whether the filter is applied to inbound(1)
traffic, outbound(2) traffic, or traffic in both(3)
directions."
DEFVAL { inbound }
::= { docsDevFilterIpEntry 5 }
記述は「フィルタが両方の(3)指示で本国行きの(1)交通、外国行きの(2)交通、または交通に適用されるかどうか決定します」。 DEFVAL、本国行き:、:= docsDevFilterIpEntry5
docsDevFilterIpBroadcast OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"If set to true(1), the filter only applies to multicast
and broadcast traffic. If set to false(2), the filter
applies to all traffic."
DEFVAL { false }
::= { docsDevFilterIpEntry 6 }
docsDevFilterIpBroadcast OBJECT-TYPE SYNTAX TruthValueマックス-ACCESSは「本当の(1)に設定されて、フィルタがマルチキャストに適用されるだけであるか、そして、放送は取引する」STATUSの現在の記述を読書して作成します。 「誤った(2)に設定されるなら、フィルタはすべての交通に適用されます。」 DEFVAL偽:、:= docsDevFilterIpEntry6
docsDevFilterIpSaddr OBJECT-TYPE
SYNTAX IpAddress
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The source IP address, or portion thereof, that is to be
matched for this filter. The source address is first
masked (and'ed) against docsDevFilterIpSmask before being
compared to this value. A value of 0 for this object
and 0 for the mask matches all IP addresses."
DEFVAL { '00000000'h }
::= { docsDevFilterIpEntry 7 }
docsDevFilterIpSaddr OBJECT-TYPE SYNTAX IpAddressマックス-ACCESSは「このフィルタのために合わせられて、ソースIPは記述するか、またはすなわちそれについて分配される」STATUSの現在の記述を読書して作成します。 ソースアドレスはそうです。最初に、仮面の(and'教育) この値と比較される前のdocsDevFilterIpSmaskに対して。 「この物のための0とマスクのための0の値はすべてのIPアドレスに合っています。」 DEFVAL'00000000'h:、:= docsDevFilterIpEntry7
docsDevFilterIpSmask OBJECT-TYPE
SYNTAX IpAddress
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"A bit mask that is to be applied to the source address
prior to matching. This mask is not necessarily the same
as a subnet mask, but 1's bits must be leftmost and
contiguous."
DEFVAL { '00000000'h }
::= { docsDevFilterIpEntry 8 }
docsDevFilterIpSmask OBJECT-TYPE SYNTAX IpAddressマックス-ACCESSはSTATUSの現在の記述を読書して作成します。「マッチングの前にソースアドレスに適用されることになっているしばらくマスク。」 「このマスクが必ずサブネットマスクと同じであるというわけではありませんが、1のビットは、一番左にあって、隣接でなければなりません。」 DEFVAL'00000000'h:、:= docsDevFilterIpEntry8
docsDevFilterIpDaddr OBJECT-TYPE
SYNTAX IpAddress
MAX-ACCESS read-create
STATUS current
DESCRIPTION
docsDevFilterIpDaddr OBJECT-TYPE SYNTAX IpAddressマックス-ACCESSはSTATUSの現在の記述を読書して作成します。
St. Johns Standards [Page 36] RFC 2669 DOCSIS Cable Device MIB August 1999
ジョーンズStandards[36ページ]の聖RFC2669DOCSISは1999年8月に装置MIBに電報を打ちます。
"The destination IP address, or portion thereof, that is
to be matched for this filter. The destination address is
first masked (and'ed) against docsDevFilterIpDmask before
being compared to this value. A value of 0 for this
object and 0 for the mask matches all IP addresses."
DEFVAL { '00000000'h }
::= { docsDevFilterIpEntry 9 }
「それのこのフィルタのために合わせられることになっている送付先IPアドレス、または部分。」 送付先アドレスはそうです。最初に、仮面の(and'教育) この値と比較される前のdocsDevFilterIpDmaskに対して。 「この物のための0とマスクのための0の値はすべてのIPアドレスに合っています。」 DEFVAL'00000000'h:、:= docsDevFilterIpEntry9
docsDevFilterIpDmask OBJECT-TYPE
SYNTAX IpAddress
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"A bit mask that is to be applied to the destination
address prior to matching. This mask is not necessarily
the same as a subnet mask, but 1's bits must be leftmost
and contiguous."
DEFVAL { '00000000'h }
::= { docsDevFilterIpEntry 10 }
docsDevFilterIpDmask OBJECT-TYPE SYNTAX IpAddressマックス-ACCESSはSTATUSの現在の記述を読書して作成します。「マッチングの前に送付先アドレスに適用されることになっているしばらくマスク。」 「このマスクが必ずサブネットマスクと同じであるというわけではありませんが、1のビットは、一番左にあって、隣接でなければなりません。」 DEFVAL'00000000'h:、:= docsDevFilterIpEntry10
docsDevFilterIpProtocol OBJECT-TYPE
SYNTAX Integer32 (0..256)
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The IP protocol value that is to be matched. For example:
icmp is 1, tcp is 6, udp is 17. A value of 256 matches
ANY protocol."
DEFVAL { 256 }
::= { docsDevFilterIpEntry 11 }
docsDevFilterIpProtocol OBJECT-TYPE SYNTAX Integer32(0 .256)マックス-ACCESSはSTATUSの現在の記述を読書して作成します。「合わせられるためにあるIPプロトコル価値。」 例えば: icmpが1である、tcpが6である、udpは17です。 「256の値はどんなプロトコルにも合っています。」 DEFVAL256:、:= docsDevFilterIpEntry11
docsDevFilterIpSourcePortLow OBJECT-TYPE
SYNTAX Integer32 (0..65535)
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"If docsDevFilterIpProtocol is udp or tcp, this is the
inclusive lower bound of the transport-layer source port
range that is to be matched, otherwise it is ignored
during matching."
DEFVAL { 0 }
::= { docsDevFilterIpEntry 12 }
docsDevFilterIpSourcePortLow OBJECT-TYPE SYNTAX Integer32(0 .65535)マックス-ACCESSはSTATUSの現在の記述を読書して作成します。「docsDevFilterIpProtocolがudpかtcpであるなら、これが取り組むことになっているトランスポート層ソースのポート範囲の包括的な下界である、さもなければ、それはマッチングの間、無視されます」。 DEFVAL0:、:= docsDevFilterIpEntry12
docsDevFilterIpSourcePortHigh OBJECT-TYPE
SYNTAX Integer32 (0..65535)
MAX-ACCESS read-create
STATUS current
DESCRIPTION
docsDevFilterIpSourcePortHigh OBJECT-TYPE SYNTAX Integer32(0 .65535)マックス-ACCESSはSTATUSの現在の記述を読書して作成します。
St. Johns Standards [Page 37] RFC 2669 DOCSIS Cable Device MIB August 1999
ジョーンズStandards[37ページ]の聖RFC2669DOCSISは1999年8月に装置MIBに電報を打ちます。
"If docsDevFilterIpProtocol is udp or tcp, this is the
inclusive upper bound of the transport-layer source port
range that is to be matched, otherwise it is ignored
during matching."
DEFVAL { 65535 }
::= { docsDevFilterIpEntry 13 }
「docsDevFilterIpProtocolがudpかtcpであるなら、これが取り組むことになっているトランスポート層ソースのポート範囲の包括的な上限である、さもなければ、それはマッチングの間、無視されます。」 DEFVAL65535:、:= docsDevFilterIpEntry13
docsDevFilterIpDestPortLow OBJECT-TYPE
SYNTAX Integer32 (0..65535)
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"If docsDevFilterIpProtocol is udp or tcp, this is the
inclusive lower bound of the transport-layer destination
port range that is to be matched, otherwise it is ignored
during matching."
DEFVAL { 0 }
::= { docsDevFilterIpEntry 14 }
docsDevFilterIpDestPortLow OBJECT-TYPE SYNTAX Integer32(0 .65535)マックス-ACCESSはSTATUSの現在の記述を読書して作成します。「docsDevFilterIpProtocolがudpかtcpであるなら、これが取り組むことになっているトランスポート層仕向港の範囲の包括的な下界である、さもなければ、それはマッチングの間、無視されます」。 DEFVAL0:、:= docsDevFilterIpEntry14
docsDevFilterIpDestPortHigh OBJECT-TYPE
SYNTAX Integer32 (0..65535)
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"If docsDevFilterIpProtocol is udp or tcp, this is the
inclusive upper bound of the transport-layer destination
port range that is to be matched, otherwise it is ignored
during matching."
DEFVAL { 65535 }
::= { docsDevFilterIpEntry 15 }
docsDevFilterIpDestPortHigh OBJECT-TYPE SYNTAX Integer32(0 .65535)マックス-ACCESSはSTATUSの現在の記述を読書して作成します。「docsDevFilterIpProtocolがudpかtcpであるなら、これが取り組むことになっているトランスポート層仕向港の範囲の包括的な上限である、さもなければ、それはマッチングの間、無視されます」。 DEFVAL65535:、:= docsDevFilterIpEntry15
docsDevFilterIpMatches OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Counts the number of times this filter was matched.
This object is initialized to 0 at boot, or at row
creation, and is reset only upon reboot."
::= { docsDevFilterIpEntry 16 }
docsDevFilterIpMatches OBJECT-TYPE SYNTAX Counter32のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述は「このフィルタが合わせられたという回の数を数えます」。 「この物は、ブーツにおいて、または、列の創造において0に初期化されて、単にリブートのときにリセットされます。」 ::= docsDevFilterIpEntry16
docsDevFilterIpTos OBJECT-TYPE
SYNTAX OCTET STRING ( SIZE (1))
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is the value to be matched to the packet's
TOS (Type of Service) value (after the TOS value
docsDevFilterIpTos OBJECT-TYPE SYNTAX OCTET STRING、(SIZE(1))マックス-ACCESSがSTATUSの現在の記述を読書して作成する、「これがパケットのTOS(Serviceのタイプ)値に合わせられるべき値である、(TOS値の後、」
St. Johns Standards [Page 38] RFC 2669 DOCSIS Cable Device MIB August 1999
ジョーンズStandards[38ページ]の聖RFC2669DOCSISは1999年8月に装置MIBに電報を打ちます。
is AND'd with docsDevFilterIpTosMask). A value for this
object of 0 and a mask of 0 matches all TOS values."
DEFVAL { '00'h }
::= { docsDevFilterIpEntry 17 }
あって、docsDevFilterIpTosMaskと共にあるだろう、) 「0のこの物と0のマスクのための値はすべてのTOS値に合っています。」 DEFVAL'00'h:、:= docsDevFilterIpEntry17
docsDevFilterIpTosMask OBJECT-TYPE
SYNTAX OCTET STRING ( SIZE (1) )
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The mask to be applied to the packet's TOS value before
matching."
DEFVAL { '00'h }
::= { docsDevFilterIpEntry 18 }
SIZE(1) )マックス-ACCESSはSTATUSの現在の記述を読書して作成します。docsDevFilterIpTosMask OBJECT-TYPE SYNTAX OCTET STRING、(「マッチングの前にパケットのTOS値に適用されるべきマスク。」 DEFVAL'00'h:、:= docsDevFilterIpEntry18
docsDevFilterIpContinue OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"If this value is set to true, and docsDevFilterIpControl
is anything but discard (1), continue scanning and
applying policies."
DEFVAL { false }
::= { docsDevFilterIpEntry 19 }
docsDevFilterIpContinue OBJECT-TYPE SYNTAX TruthValueマックス-ACCESSは、「この値が本当に設定されます、そして、docsDevFilterIpControlは何かですが、(1)を捨てて、スキャンするのを存続させて、政策を申し込み」ながら、STATUSの現在の記述を読書して作成します。 DEFVAL偽:、:= docsDevFilterIpEntry19
docsDevFilterIpPolicyId OBJECT-TYPE
SYNTAX Integer32 (0..2147483647)
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This object points to an entry in docsDevFilterPolicyTable.
If docsDevFilterIpControl is set to policy (3), execute
all matching policies in docsDevFilterPolicyTable.
If no matching policy exists, treat as if
docsDevFilterIpControl were set to accept (1).
If this object is set to the value of 0, there is no
matching policy, and docsDevFilterPolicyTable MUST NOT be
consulted."
DEFVAL { 0 }
::= { docsDevFilterIpEntry 20 }
docsDevFilterIpPolicyId OBJECT-TYPE SYNTAX Integer32(0 .2147483647)マックス-ACCESSは「この物はdocsDevFilterPolicyTableのエントリーに指す」STATUSの現在の記述を読書して作成します。 docsDevFilterIpControlが方針(3)に用意ができているなら、docsDevFilterPolicyTableのすべての合っている方針を実行してください。 合っている方針が全く存在しないなら、まるでdocsDevFilterIpControlが(1)を受け入れるように用意ができているかのように、扱ってください。 「この物が0の値に設定されるなら、合っている方針が全くありません、そして、docsDevFilterPolicyTableは相談されてはいけません。」 DEFVAL0:、:= docsDevFilterIpEntry20
-- --
-- --
docsDevFilterPolicyTable OBJECT-TYPE
SYNTAX SEQUENCE OF DocsDevFilterPolicyEntry
MAX-ACCESS not-accessible
アクセスしやすくないdocsDevFilterPolicyTable OBJECT-TYPE SYNTAX SEQUENCE OF DocsDevFilterPolicyEntryマックス-ACCESS
St. Johns Standards [Page 39] RFC 2669 DOCSIS Cable Device MIB August 1999
ジョーンズStandards[39ページ]の聖RFC2669DOCSISは1999年8月に装置MIBに電報を打ちます。
STATUS current
DESCRIPTION
"A Table which maps between a policy group ID and a set of
policies to be applied. All rows with the same
docsDevFilterPolicyId are part of the same policy group
and are applied in the order in which they are in this
table.
「方針グループの間でIDを写像するTableとaは適用されるように方針を設定する」STATUSの現在の記述。 同じdocsDevFilterPolicyIdがあるすべての列が、同じ方針グループの一部であり、オーダーでそれらがこのテーブルで中である適用されます。
docsDevFilterPolicyTable exists to allow multiple policy
actions to be applied to any given classified packet. The
policy actions are applied in index order For example:
docsDevFilterPolicyTableは、複数の政策的措置がどんな与えられた分類されたパケットにも適用されるのを許容するために存在しています。 政策的措置はインデックスオーダーForの例で適用されます:
Index ID Type Action
1 1 TOS 1
9 5 TOS 1
12 1 IPSEC 3
1インデックスIDタイプ動作1 1TOS1 9 5TOS1 12IPSEC3
This says that a packet which matches a filter with
policy id 1, first has TOS policy 1 applied (which might
set the TOS bits to enable a higher priority), and next
has the IPSEC policy 3 applied (which may result in the
packet being dumped into a secure VPN to a remote
encryptor).
これは、方針イド1にフィルタを合わせて、次に最初に方針1が当てはまったTOS(TOSビットにより高い優先度を可能にするように設定するかもしれない)を持っているパケットでIPSEC方針3を適用すると言います(リモート暗号化する人への安全なVPNにどさっと落とされるパケットをもたらすかもしれません)。
Policy ID 0 is reserved for default actions and is
applied only to packets which match no filters in
docsDevIpFilterTable."
::= { docsDevFilter 5 }
「方針ID0は、デフォルト動作のために予約されて、docsDevIpFilterTableでフィルタに全く合っていないパケットだけに適用されます。」 ::= docsDevFilter5
docsDevFilterPolicyEntry OBJECT-TYPE
SYNTAX DocsDevFilterPolicyEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in the docsDevFilterPolicyTable. Entries are
created by Network Management. To create an entry,
docsDevFilterPolicyId and docsDevFilterPolicyAction
must be specified."
INDEX { docsDevFilterPolicyIndex }
::= { docsDevFilterPolicyTable 1 }
docsDevFilterPolicyEntry OBJECT-TYPE SYNTAX DocsDevFilterPolicyEntryのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述、「docsDevFilterPolicyTableのエントリー。」 エントリーはNetwork Managementによって作成されます。 「エントリー、docsDevFilterPolicyId、およびdocsDevFilterPolicyActionを作成するのは指定していなければなりません。」 docsDevFilterPolicyIndexに索引をつけてください:、:= docsDevFilterPolicyTable1
DocsDevFilterPolicyEntry ::= SEQUENCE {
docsDevFilterPolicyIndex Integer32,
docsDevFilterPolicyId Integer32,
-- docsDevFilterPolicyType INTEGER,
-- docsDevFilterPolicyAction Integer32,
docsDevFilterPolicyStatus RowStatus,
docsDevFilterPolicyPtr RowPointer
DocsDevFilterPolicyEntry:、:= 系列、docsDevFilterPolicyIndex Integer32、docsDevFilterPolicyId Integer32--docsDevFilterPolicyType整数--docsDevFilterPolicyAction Integer32、docsDevFilterPolicyStatus RowStatus、docsDevFilterPolicyPtr RowPointer
St. Johns Standards [Page 40] RFC 2669 DOCSIS Cable Device MIB August 1999
ジョーンズStandards[40ページ]の聖RFC2669DOCSISは1999年8月に装置MIBに電報を打ちます。
}
}
docsDevFilterPolicyIndex OBJECT-TYPE
SYNTAX Integer32 (1..2147483647)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "Index value for the table."
::= { docsDevFilterPolicyEntry 1 }
docsDevFilterPolicyIndex OBJECT-TYPE SYNTAX Integer32(1 .2147483647)のマックス-ACCESSのアクセスしやすくないSTATUS現在の記述は「テーブルのために値に索引をつけます」。 ::= docsDevFilterPolicyEntry1
docsDevFilterPolicyId OBJECT-TYPE
SYNTAX Integer32 (0..2147483647)
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Policy ID for this entry. A policy ID can apply to
multiple rows of this table, all relevant policies are
executed. Policy 0 (if populated) is applied to all
packets which do not match any of the filters. N.B. If
docsDevFilterIpPolicyId is set to 0, it DOES NOT match
policy 0 of this table. "
::= { docsDevFilterPolicyEntry 2 }
docsDevFilterPolicyId OBJECT-TYPE SYNTAX Integer32(0 .2147483647)マックス-ACCESSはSTATUSの現在の記述「このエントリーへのPolicy ID」を読書して作成します。 このテーブルの複数の列に方針IDは適用できて、すべての関連方針が実行されます。 方針0(居住されるなら)はフィルタのいずれにも合っていないすべてのパケットに適用されます。 docsDevFilterIpPolicyIdがあるなら、N.B.は0にセットして、それはこのテーブルのDOES NOTマッチ方針0です。 " ::= docsDevFilterPolicyEntry2
-- docsDevFilterPolicyType ::= { docsDevFilterPolicyEntry 3} Removed
-- docsDevFilterPolicyAction ::= { docsDevFilterPolicyEntry 4 } removed
-- docsDevFilterPolicyType:、:= docsDevFilterPolicyEntry3は取り外しました--、docsDevFilterPolicyAction:、:= docsDevFilterPolicyEntry4は取り外しました。
docsDevFilterPolicyStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Object used to create an entry in this table."
::= { docsDevFilterPolicyEntry 5 }
docsDevFilterPolicyStatus OBJECT-TYPE SYNTAX RowStatusマックス-ACCESSは「物はこのテーブルでエントリーを作成するのに使用した」STATUSの現在の記述を読書して作成します。 ::= docsDevFilterPolicyEntry5
docsDevFilterPolicyPtr OBJECT-TYPE
SYNTAX RowPointer
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This object points to a row in an applicable filter policy
table. Currently, the only standard policy table is
docsDevFilterTosTable. Per the textual convention, this
object points to the first accessible object in the row.
E.g. to point to a row in docsDevFilterTosTable with an
index of 21, the value of this object would be the object
identifier docsDevTosStatus.21.
docsDevFilterPolicyPtr OBJECT-TYPE SYNTAX RowPointerマックス-ACCESSは「この物は適切なフィルタ方針テーブルの列に指す」STATUSの現在の記述を読書して作成します。 現在、唯一の標準約款テーブルがdocsDevFilterTosTableです。 原文のコンベンションに従って、この物は列に最初のアクセスしやすい物を示します。 例えば、21のインデックスでdocsDevFilterTosTableの列を示すために、この物の値は物の識別子docsDevTosStatus.21でしょう。
Vendors must adhere to the same convention when adding
加えるとき、業者は同じコンベンションを固く守らなければなりません。
St. Johns Standards [Page 41] RFC 2669 DOCSIS Cable Device MIB August 1999
ジョーンズStandards[41ページ]の聖RFC2669DOCSISは1999年8月に装置MIBに電報を打ちます。
vendor specific policy table extensions.
業者特定保険証券テーブル拡大。
The default upon row creation is a null pointer which
results in no policy action being taken."
DEFVAL { zeroDotZero }
::= { docsDevFilterPolicyEntry 6 }
「列の創造でのデフォルトは取られない政策的措置を全くもたらすヌルポインタです。」 DEFVAL zeroDotZero:、:= docsDevFilterPolicyEntry6
-- -- TOS Policy action table --
-- -- TOS Policy動作テーブル--
docsDevFilterTosTable OBJECT-TYPE
SYNTAX SEQUENCE OF DocsDevFilterTosEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Table used to describe Type of Service (TOS) bits
processing.
「テーブルはService(TOS)ビット処理のTypeについて説明するのに使用した」docsDevFilterTosTable OBJECT-TYPEのSYNTAX SEQUENCE OF DocsDevFilterTosEntryのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述。
This table is an adjunct to the docsDevFilterIpTable, and
the docsDevFilterPolicy table. Entries in the latter
table can point to specific rows in this (and other)
tables and cause specific actions to be taken. This table
permits the manipulation of the value of the Type of
Service bits in the IP header of the matched packet as
follows:
Set the tosBits of the packet to
(tosBits & docsDevFilterTosAndMask) |
docsDevFilterTosOrMask
このテーブルはdocsDevFilterIpTable、およびdocsDevFilterPolicyテーブルへの付属物です。 後者のテーブルのエントリーで、中のこれ(別である)が見送る詳細列を示して、特定の行動を取ることができます。 このテーブルは以下の取り組んでいるパケットのIPヘッダーでのServiceビットのTypeの価値の操作を可能にします: (tosBits&docsDevFilterTosAndMask)にパケットのtosBitsを設定してください。| docsDevFilterTosOrMask
This construct allows you to do a clear and set of all
the TOS bits in a flexible manner."
::= { docsDevFilter 6 }
「この構造物で、あなたはフレキシブルな態度で明確なビットとセットのすべてのTOSビットができます。」 ::= docsDevFilter6
docsDevFilterTosEntry OBJECT-TYPE
SYNTAX DocsDevFilterTosEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A TOS policy entry."
INDEX { docsDevFilterTosIndex }
::= { docsDevFilterTosTable 1 }
アクセスしやすくないdocsDevFilterTosEntry OBJECT-TYPE SYNTAX DocsDevFilterTosEntryの現在の記述マックス-ACCESS STATUS「A TOS方針エントリー。」 docsDevFilterTosIndexに索引をつけてください:、:= docsDevFilterTosTable1
DocsDevFilterTosEntry ::= SEQUENCE {
docsDevFilterTosIndex Integer32,
docsDevFilterTosStatus RowStatus,
docsDevFilterTosAndMask OCTET STRING (SIZE (1)),
docsDevFilterTosOrMask OCTET STRING (SIZE (1))
DocsDevFilterTosEntry:、:= 系列、docsDevFilterTosIndex Integer32、docsDevFilterTosStatus RowStatus、docsDevFilterTosAndMask八重奏ストリング、(サイズ(1))、docsDevFilterTosOrMask八重奏ストリング(サイズ(1))
St. Johns Standards [Page 42] RFC 2669 DOCSIS Cable Device MIB August 1999
ジョーンズStandards[42ページ]の聖RFC2669DOCSISは1999年8月に装置MIBに電報を打ちます。
}
}
docsDevFilterTosIndex OBJECT-TYPE
SYNTAX Integer32 (1..2147483647)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The unique index for this row. There are no ordering
requirements for this table and any valid index may be
specified."
::= { docsDevFilterTosEntry 1 }
「これのためのユニークなインデックスはこぐ」docsDevFilterTosIndex OBJECT-TYPE SYNTAX Integer32(1 .2147483647)のマックス-ACCESSのアクセスしやすくないSTATUS現在の記述。 「注文要件は全くこのテーブルのためにありません、そして、どんな有効なインデックスも指定されるかもしれません。」 ::= docsDevFilterTosEntry1
docsDevFilterTosStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The object used to create and delete entries in this
table. A row created by specifying just this object
results in a row which specifies no change to the TOS
bits. A row may be created using either the create-and-go
or create-and-wait paradigms. There is no restriction on
the ability to change values in this row while the row is
active."
::= { docsDevFilterTosEntry 2 }
docsDevFilterTosStatus OBJECT-TYPE SYNTAX RowStatusマックス-ACCESSは「物はこのテーブルでエントリーを作成して、削除するのに使用した」STATUSの現在の記述を読書して作成します。 まさしくこの物を指定することによって作成された列はTOSビットへの変化を全く指定しない列をもたらします。 パラダイムを作成して、待ってください。または、「列がどちらかを使用することで作成されるかもしれない、作成して、行く、制限が全く列がアクティブである間にこの列で値を変える能力にありません」 ::= docsDevFilterTosEntry2
docsDevFilterTosAndMask OBJECT-TYPE
SYNTAX OCTET STRING (SIZE (1))
MAX-ACCESS read-create
STATUS current
DESCRIPTION
docsDevFilterTosAndMask OBJECT-TYPE SYNTAX OCTET STRING、(SIZE(1))マックス-ACCESSはSTATUSの現在の記述を読書して作成します。
"This value is bitwise AND'd with the matched packet's
TOS bits."
DEFVAL { 'ff'h }
::= { docsDevFilterTosEntry 3 }
「bitwiseすることであり、この値は取り組んでいるパケットのTOSビットでことでしょう。」 DEFVAL'ff'h:、:、'= docsDevFilterTosEntry3
docsDevFilterTosOrMask OBJECT-TYPE
SYNTAX OCTET STRING (SIZE (1))
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"After bitwise AND'ing with the above bits, the packet's
TOS bits are bitwise OR'd with these bits."
DEFVAL { '00'h }
::= { docsDevFilterTosEntry 4 }
docsDevFilterTosOrMask OBJECT-TYPE SYNTAX OCTET STRING、(SIZE(1))マックス-ACCESSがSTATUSの現在の記述を読書して作成する、「上のビットがあるbitwise AND'ingの後にパケットのTOSビットがそうである、bitwiseする、ORがこれらのビットでそうするだろう、」 DEFVAL'00'h:、:= docsDevFilterTosEntry4
St. Johns Standards [Page 43] RFC 2669 DOCSIS Cable Device MIB August 1999
ジョーンズStandards[43ページ]の聖RFC2669DOCSISは1999年8月に装置MIBに電報を打ちます。
-- -- CPE IP Management and anti spoofing group. Only implemented on -- Cable Modems. --
-- -- CPE IP Managementと反スプーフィングは分類されます。 実行されるだけである、--Modemsに電報を打ってください、--
docsDevCpe OBJECT IDENTIFIER ::= { docsDevMIBObjects 7}
docsDevCpe物の識別子:、:= docsDevMIBObjects7
docsDevCpeEnroll OBJECT-TYPE
SYNTAX INTEGER {
none(1),
any(2)
}
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This object controls the population of docsDevFilterCpeTable.
If set to none, the filters must be set manually.
If set to any, the CM wiretaps the packets originating
from the ethernet and enrolls up to docsDevCpeIpMax
addresses based on the source IP addresses of those
packets. At initial system startup, default value for this
object is any(2)."
::= { docsDevCpe 1 }
docsDevCpeEnroll OBJECT-TYPE SYNTAX INTEGER、なにも、(1)、どんな(2)、もマックス-ACCESSは「この物はdocsDevFilterCpeTableの人口を制御すること」をSTATUSの現在の記述に読書して書きます。 なにもに設定されないなら、手動でフィルタを設定しなければなりません。 いずれかに設定されるなら、CMは、イーサネットから発するパケットを盗聴して、それらのパケットのソースIPアドレスに基づくdocsDevCpeIpMaxアドレスまで登録されます。 「初期のシステム起動では、この物のためのデフォルト値はあらゆる(2)です。」 ::= docsDevCpe1
docsDevCpeIpMax OBJECT-TYPE
SYNTAX Integer32 (-1..2147483647)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This object controls the maximum number of CPEs allowed to
connect behind this device. If set to zero, any number of
CPEs may connect up to the maximum permitted for the device.
If set to -1, no filtering is done on CPE source addresses,
and no entries are made in the docsDevFilterCpeTable. If an
attempt is made to set this to a number greater than that
permitted for the device, it is set to that maximum.
At iniitial system startup, default value for this object
is 1."
::= { docsDevCpe 2 }
docsDevCpeIpMax OBJECT-TYPE SYNTAX Integer32(-1 .2147483647)マックス-ACCESSは「この物はこの装置の後ろで接続できたCPEsの最大数を制御すること」をSTATUSの現在の記述に読書して書きます。 ゼロに設定されるなら、いろいろなCPEsが装置のために受入れられた最大まで接続するかもしれません。 -1に設定するなら、CPEソースアドレスでフィルターにかけないことをします、そして、docsDevFilterCpeTableでエントリーを全くしません。 それが装置のために可能にしたより大きい数にこれを設定するのを試みをするなら、その最大にそれを設定します。 「iniitialシステム起動では、この物のためのデフォルト値は1です。」 ::= docsDevCpe2
docsDevCpeTable OBJECT-TYPE
SYNTAX SEQUENCE OF DocsDevCpeEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table lists the IP addresses seen (or permitted) as
source addresses in packets originating from the customer
interface on this device. In addition, this table can be
「顧客から発するパケットのソースアドレスがこの装置に接続するので見られて(または、受入れられます)、このテーブルリストIPは記述する」docsDevCpeTable OBJECT-TYPE SYNTAX SEQUENCE OF DocsDevCpeEntryのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述。 さらに、このテーブルはそうであることができます。
St. Johns Standards [Page 44] RFC 2669 DOCSIS Cable Device MIB August 1999
ジョーンズStandards[44ページ]の聖RFC2669DOCSISは1999年8月に装置MIBに電報を打ちます。
provisioned with the specific addresses permitted for the
CPEs via the normal row creation mechanisms."
::= { docsDevCpe 3 }
「特定のアドレスがCPEsのために正常な列の創造メカニズムで受入れられている状態で、食糧を供給される」、:、:= docsDevCpe3
docsDevCpeEntry OBJECT-TYPE
SYNTAX DocsDevCpeEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in the docsDevFilterCpeTable. There is one entry
for each IP CPE seen or provisioned. If docsDevCpeIpMax
is set to -1, this table is ignored, otherwise: Upon receipt
of an IP packet from the customer interface of the CM, the
source IP address is checked against this table. If the
address is in the table, packet processing continues.
If the address is not in the table, but docsDevCpeEnroll
is set to any and the table size is less than
docsDevCpeIpMax, the address is added to the table and
packet processing continues. Otherwise, the packet is
dropped.
docsDevCpeEntry OBJECT-TYPE SYNTAX DocsDevCpeEntryのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述、「docsDevFilterCpeTableのエントリー。」 IP CPEが見たか、または食糧を供給したそれぞれのための1つのエントリーがあります。 docsDevCpeIpMaxが-1に用意ができているなら、このテーブルは別の方法で無視されます: CMの顧客インタフェースからのIPパケットを受け取り次第、ソースIPアドレスはこのテーブルに対してチェックされます。 アドレスがテーブルにあるなら、パケット処理は続きます。 アドレスがテーブルにありませんが、docsDevCpeEnrollがいずれかに用意ができて、テーブル・サイズがdocsDevCpeIpMaxより少ないなら、アドレスはテーブルに加えられます、そして、パケット処理は続きます。 さもなければ、パケットは落とされます。
The filtering actions specified by this table occur after
any LLC filtering (docsDevFilterLLCTable), but prior
to any IP filtering (docsDevFilterIpTable,
docsDevNmAccessTable)."
INDEX { docsDevCpeIp }
::= {docsDevCpeTable 1 }
「このテーブルによって指定されたフィルタリング動作は、(docsDevFilterLLCTable)をフィルターにかけるどんなLLCの後にも起こりますが、どんなIPフィルタリング(docsDevFilterIpTable、docsDevNmAccessTable)の前にも起こります。」 docsDevCpeIpに索引をつけてください:、:= docsDevCpeTable1
DocsDevCpeEntry ::= SEQUENCE {
docsDevCpeIp IpAddress,
docsDevCpeSource INTEGER,
docsDevCpeStatus RowStatus
}
DocsDevCpeEntry:、:= 系列docsDevCpeIp IpAddress、docsDevCpeSource整数、docsDevCpeStatus RowStatus
docsDevCpeIp OBJECT-TYPE
SYNTAX IpAddress
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The IP address to which this entry applies."
::= { docsDevCpeEntry 1 }
「IPはこのエントリーが適用するものに記述する」docsDevCpeIp OBJECT-TYPE SYNTAX IpAddressのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述。 ::= docsDevCpeEntry1
docsDevCpeSource OBJECT-TYPE
SYNTAX INTEGER {
other(1),
manual(2),
learned(3)
}
docsDevCpeSourceオブジェクト・タイプ構文整数他の(1)(マニュアル(2))は(3)を学びました。
St. Johns Standards [Page 45] RFC 2669 DOCSIS Cable Device MIB August 1999
ジョーンズStandards[45ページ]の聖RFC2669DOCSISは1999年8月に装置MIBに電報を打ちます。
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object describes how this entry was created. If the
value is manual(2), this row was created by a network
management action (either configuration, or SNMP set).
If set to learned(3), then it was found via
looking at the source IP address of a received packet."
::= { docsDevCpeEntry 2 }
マックス-ACCESSの書き込み禁止のSTATUSの現在の記述は「このエントリーがどう作成されたかを説明これが反対するします」。 値がマニュアル(2)であるなら、この列はネットワークマネージメント動作で作成されました(構成かSNMPのどちらかがセットしました)。 「学術的(3)に設定されるなら、容認されたパケットのソースIPアドレスを見ることを通してそれは見つけられました。」 ::= docsDevCpeEntry2
docsDevCpeStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Standard object to manipulate rows. To create a row in this
table, you only need to specify this object. Management
stations SHOULD use the create-and-go mechanism for
creating rows in this table."
::= { docsDevCpeEntry 3 }
docsDevCpeStatus OBJECT-TYPE SYNTAX RowStatusマックス-ACCESSはSTATUSの現在の記述を読書して作成します。「列を操る標準の物。」 このテーブルの列を作成するために、あなたは、この物を指定する必要があるだけです。 「管理局SHOULDが使用する、作成して、行く、このテーブルの列を作成するためのメカニズム、」 ::= docsDevCpeEntry3
--
-- Placeholder for notifications/traps.
--
docsDevNotification OBJECT IDENTIFIER ::= { docsDev 2 }
-- -- 通知/罠のためのプレースホルダ。 -- docsDevNotification物の識別子:、:= docsDev2
--
-- Conformance definitions
--
docsDevConformance OBJECT IDENTIFIER ::= { docsDev 3 }
docsDevGroups OBJECT IDENTIFIER ::= { docsDevConformance 1 }
docsDevCompliances OBJECT IDENTIFIER ::= { docsDevConformance 2 }
-- -- 順応定義--、docsDevConformance OBJECT IDENTIFIER:、:= docsDev3docsDevGroups物の識別子:、:= docsDevConformance1docsDevCompliances物の識別子:、:= docsDevConformance2
docsDevBasicCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The compliance statement for MCNS Cable Modems and
Cable Modem Termination Systems."
docsDevBasicCompliance MODULE-COMPLIANCE STATUSの現在の記述「MCNS Cable Modemsのための承諾声明とCable Modem Termination Systems。」
MODULE -- docsDev
モジュール--docsDev
-- conditionally mandatory groups
-- 条件付きに義務的なグループ
GROUP docsDevBaseGroup
DESCRIPTION
"Mandatory in Cable Modems, optional in Cable Modem
Termination Systems."
「Cable Modemsで義務的で、Cable Modem Termination Systemsで任意」のGROUP docsDevBaseGroup記述。
St. Johns Standards [Page 46] RFC 2669 DOCSIS Cable Device MIB August 1999
ジョーンズStandards[46ページ]の聖RFC2669DOCSISは1999年8月に装置MIBに電報を打ちます。
GROUP docsDevEventGroup
DESCRIPTION
"Mandatory in Cable Modems, optional in Cable Modem
Termination Systems."
「Cable Modemsで義務的で、Cable Modem Termination Systemsで任意」のGROUP docsDevEventGroup記述。
GROUP docsDevFilterGroup
DESCRIPTION
"Mandatory in Cable Modems, optional in Cable Modem
Termination Systems."
「Cable Modemsで義務的で、Cable Modem Termination Systemsで任意」のGROUP docsDevFilterGroup記述。
GROUP docsDevNmAccessGroup
DESCRIPTION
"This group is only implemented in devices which do not
implement SNMPv3 User Security Model. It SHOULD NOT be
implemented by SNMPv3 conformant devices.
GROUP docsDevNmAccessGroup記述、「このグループはSNMPv3 User Security Modelを実行しない装置で実行されるだけです」。 それ、SHOULD NOT、SNMPv3 conformant装置で、実行されてください。
For devices which do not implement SNMPv3 or later, this
group is Mandatory in Cable Modems and is optional
in Cable Modem Termination Systems."
「SNMPv3以降を実行しない装置に関して、このグループは、Cable ModemsのMandatoryであり、Cable Modem Termination Systemsで任意です。」
GROUP docsDevServerGroup
DESCRIPTION
"This group is implemented only in Cable Modems and is
not implemented in Cable Modem Termination Systems."
「このグループはCable Modemsだけで実行されます、そして、実行されたコネはCable Modem Termination Systems GROUP docsDevServerGroup記述ではありませんか?」
GROUP docsDevSoftwareGroup
DESCRIPTION
"This group is Mandatory in Cable Modems and optional in
Cable Modem Termination Systems."
「このグループはCable Modem Termination SystemsでCable Modemsで任意のMandatory GROUP docsDevSoftwareGroup記述です」。
GROUP docsDevCpeGroup
DESCRIPTION
"This group is Mandatory in Cable Modems, and is
not implemented in Cable Modem Termination Systems. A
similar capability for CMTS devices may be proposed later
after study."
このグループは、Cable ModemsのMandatoryであり、Cable Modem Termination Systemsで実行されません。GROUP docsDevCpeGroup記述、「CMTS装置のための同様の能力は研究の後に後で提案されるかもしれません」。
OBJECT docsDevSTPControl
MIN-ACCESS read-only
DESCRIPTION
"It is compliant to implement this object as read-only.
Devices need only support noStFilterBpdu(2)."
OBJECT docsDevSTPControl MIN-ACCESS書き込み禁止記述、「書き込み禁止としてこの物を実行するのは言いなりになります」。 「装置はサポートnoStFilterBpdu(2)だけを必要とします。」
OBJECT docsDevEvReporting
MIN-ACCESS read-only
DESCRIPTION
"It is compliant to implement this object as read-only.
Devices need only support local(0)."
OBJECT docsDevEvReporting MIN-ACCESS書き込み禁止記述、「書き込み禁止としてこの物を実行するのは言いなりになります」。 「装置は地方の(0)を支持するだけでよいです。」
St. Johns Standards [Page 47] RFC 2669 DOCSIS Cable Device MIB August 1999
ジョーンズStandards[47ページ]の聖RFC2669DOCSISは1999年8月に装置MIBに電報を打ちます。
::= { docsDevCompliances 1 }
::= docsDevCompliances1
docsDevBaseGroup OBJECT-GROUP
OBJECTS {
docsDevRole,
docsDevDateTime,
docsDevResetNow,
docsDevSerialNumber,
docsDevSTPControl
}
STATUS current
DESCRIPTION
"A collection of objects providing device status and
control."
::= { docsDevGroups 1 }
docsDevBaseGroup OBJECT-GROUP OBJECTS、docsDevRole、docsDevDateTime、docsDevResetNow、docsDevSerialNumber、docsDevSTPControl、STATUSの現在の記述、「装置状態とコントロールを提供する物の収集。」 ::= docsDevGroups1
docsDevNmAccessGroup OBJECT-GROUP
OBJECTS {
docsDevNmAccessIp,
docsDevNmAccessIpMask,
docsDevNmAccessCommunity,
docsDevNmAccessControl,
docsDevNmAccessInterfaces,
docsDevNmAccessStatus
}
STATUS current
DESCRIPTION
"A collection of objects for controlling access to SNMP
objects."
::= { docsDevGroups 2 }
docsDevNmAccessGroup OBJECT-GROUP OBJECTS、docsDevNmAccessIp、docsDevNmAccessIpMask、docsDevNmAccessCommunity、docsDevNmAccessControl、docsDevNmAccessInterfaces、docsDevNmAccessStatus、「制御するためのオブジェクトのA収集はSNMPオブジェクトにアクセスする」STATUSの現在の記述。 ::= docsDevGroups2
docsDevSoftwareGroup OBJECT-GROUP
OBJECTS {
docsDevSwServer,
docsDevSwFilename,
docsDevSwAdminStatus,
docsDevSwOperStatus,
docsDevSwCurrentVers
}
STATUS current
DESCRIPTION
"A collection of objects for controlling software
downloads."
::= { docsDevGroups 3 }
docsDevSoftwareGroup OBJECT-GROUP OBJECTS、docsDevSwServer、docsDevSwFilename、docsDevSwAdminStatus、docsDevSwOperStatus、docsDevSwCurrentVers、「ソフトウェアを制御するためのオブジェクトのA収集はダウンロードする」STATUSの現在の記述。 ::= docsDevGroups3
docsDevServerGroup OBJECT-GROUP
OBJECTS {
docsDevServerBootState,
docsDevServerGroupオブジェクト群対象、docsDevServerBootState
St. Johns Standards [Page 48] RFC 2669 DOCSIS Cable Device MIB August 1999
ジョーンズStandards[48ページ]の聖RFC2669DOCSISは1999年8月にデバイスMIBに電報を打ちます。
docsDevServerDhcp,
docsDevServerTime,
docsDevServerTftp,
docsDevServerConfigFile
}
STATUS current
DESCRIPTION
"A collection of objects providing status about server
provisioning."
::= { docsDevGroups 4 }
docsDevServerDhcp、docsDevServerTime、docsDevServerTftp、docsDevServerConfigFile STATUSの現在の記述、「サーバの食糧を供給するのに関する状態を提供するオブジェクトの収集。」 ::= docsDevGroups4
docsDevEventGroup OBJECT-GROUP
OBJECTS {
docsDevEvControl,
docsDevEvSyslog,
docsDevEvThrottleAdminStatus,
docsDevEvThrottleInhibited,
docsDevEvThrottleThreshold,
docsDevEvThrottleInterval,
docsDevEvReporting,
docsDevEvFirstTime,
docsDevEvLastTime,
docsDevEvCounts,
docsDevEvLevel,
docsDevEvId,
docsDevEvText
}
STATUS current
DESCRIPTION
"A collection of objects used to control and monitor
events."
::= { docsDevGroups 5 }
docsDevEventGroup OBJECT-GROUP OBJECTS、docsDevEvControl、docsDevEvSyslog、docsDevEvThrottleAdminStatus、docsDevEvThrottleInhibited、docsDevEvThrottleThreshold、docsDevEvThrottleInterval、docsDevEvReporting、docsDevEvFirstTime、docsDevEvLastTime、docsDevEvCounts、docsDevEvLevel、docsDevEvId、docsDevEvText、「オブジェクトの収集はイベントを制御して、モニターするのに使用した」STATUSの現在の記述。 ::= docsDevGroups5
docsDevFilterGroup OBJECT-GROUP
OBJECTS {
docsDevFilterLLCUnmatchedAction,
docsDevFilterIpDefault,
docsDevFilterLLCStatus,
docsDevFilterLLCIfIndex,
docsDevFilterLLCProtocolType,
docsDevFilterLLCProtocol,
docsDevFilterLLCMatches,
docsDevFilterIpControl,
docsDevFilterIpIfIndex,
docsDevFilterIpStatus,
docsDevFilterIpDirection,
docsDevFilterIpBroadcast,
docsDevFilterIpSaddr,
docsDevFilterGroupオブジェクト群対象、docsDevFilterLLCUnmatchedAction、docsDevFilterIpDefault、docsDevFilterLLCStatus、docsDevFilterLLCIfIndex、docsDevFilterLLCProtocolType、docsDevFilterLLCProtocol、docsDevFilterLLCMatches、docsDevFilterIpControl、docsDevFilterIpIfIndex、docsDevFilterIpStatus、docsDevFilterIpDirection、docsDevFilterIpBroadcast、docsDevFilterIpSaddr
St. Johns Standards [Page 49] RFC 2669 DOCSIS Cable Device MIB August 1999
ジョーンズStandards[49ページ]の聖RFC2669DOCSISは1999年8月にデバイスMIBに電報を打ちます。
docsDevFilterIpSmask,
docsDevFilterIpDaddr,
docsDevFilterIpDmask,
docsDevFilterIpProtocol,
docsDevFilterIpSourcePortLow,
docsDevFilterIpSourcePortHigh,
docsDevFilterIpDestPortLow,
docsDevFilterIpDestPortHigh,
docsDevFilterIpMatches,
docsDevFilterIpTos,
docsDevFilterIpTosMask,
docsDevFilterIpContinue,
docsDevFilterIpPolicyId,
docsDevFilterPolicyId,
docsDevFilterPolicyStatus,
docsDevFilterPolicyPtr,
docsDevFilterTosStatus,
docsDevFilterTosAndMask,
docsDevFilterTosOrMask
}
STATUS current
DESCRIPTION
"A collection of objects to specify filters at link layer
and IP layer."
::= { docsDevGroups 6 }
docsDevFilterIpSmask、docsDevFilterIpDaddr、docsDevFilterIpDmask、docsDevFilterIpProtocol、docsDevFilterIpSourcePortLow、docsDevFilterIpSourcePortHigh、docsDevFilterIpDestPortLow、docsDevFilterIpDestPortHigh、docsDevFilterIpMatches、docsDevFilterIpTos、docsDevFilterIpTosMask、docsDevFilterIpContinue、docsDevFilterIpPolicyId、docsDevFilterPolicyId、docsDevFilterPolicyStatus、docsDevFilterPolicyPtr、docsDevFilterTosStatus、docsDevFilterTosAndMask、docsDevFilterTosOrMask 「リンクレイヤでフィルタを指定するオブジェクトとIPの収集は層にする」STATUSの現在の記述。 ::= docsDevGroups6
docsDevCpeGroup OBJECT-GROUP
OBJECTS {
docsDevCpeEnroll,
docsDevCpeIpMax,
docsDevCpeSource,
docsDevCpeStatus
}
STATUS current
DESCRIPTION
"A collection of objects used to control the number
and specific values of IP addresses allowed for
associated Customer Premises Equipment (CPE)."
::= { docsDevGroups 7 }
docsDevCpeGroup OBJECT-GROUP OBJECTS、docsDevCpeEnroll、docsDevCpeIpMax、docsDevCpeSource、docsDevCpeStatus、「数を制御するのに使用されるオブジェクトの収集とIPアドレスの特定の値は関連Customer Premises Equipment(CPE)のために許容した」STATUSの現在の記述。 ::= docsDevGroups7
END
終わり
St. Johns Standards [Page 50] RFC 2669 DOCSIS Cable Device MIB August 1999
ジョーンズStandards[50ページ]の聖RFC2669DOCSISは1999年8月にデバイスMIBに電報を打ちます。
5. Acknowledgments
5. 承認
This document was produced by the IPCDN Working Group. It is based on a document written by Pam Anderson from CableLabs, Wilson Sawyer from BayNetworks, and Rich Woundy from Continental Cablevision. The original working group editor, Guenter Roeck of cisco Systems, did much of the grunt work of putting the document into its current form.
このドキュメントはIPCDN作業部会によって製作されました。 それはパム・アンダーソンによってCableLabs、BayNetworksからのウィルソン・ソーヤー、およびコンチネンタルCablevisionからのリッシュWoundyから書かれたドキュメントに基づいています。 元のワーキンググループのエディタ(コクチマスSystemsのギュンターRoeck)は現在のフォームにドキュメントを入れる不平仕事の多くのことをしました。
Special thanks is also due to Azlina Palmer, who helped a lot reviewing the document.
特別な感謝はAzlinaパーマーのもためです。(パーマーは、ドキュメントを大いに再検討するのを助けました)。
6. References
6. 参照
[1] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for
Describing SNMP Management Frameworks", RFC 2571, April 1999.
[1] ハリントンとD.とPresuhnとR.とB.Wijnen、「SNMP管理フレームワークについて説明するためのアーキテクチャ」、RFC2571、1999年4月。
[2] Rose, M. and K. McCloghrie, "Structure and Identification of
Management Information for TCP/IP-based Internets", STD 16, RFC
1155, May 1990.
[2] ローズ、M.、およびK.McCloghrie、「TCP/IPベースのインターネットのための経営情報の構造と識別」(STD16、RFC1155)は1990がそうするかもしれません。
[3] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16,
RFC 1212, March 1991.
[3] ローズとM.とK.McCloghrie、「簡潔なMIB定義」、STD16、RFC1212、1991年3月。
[4] Rose, M., "A Convention for Defining Traps for use with the
SNMP", RFC 1215, March 1991.
[4] ローズ、1991年3月、M.、「SNMPとの使用のためのDefining TrapsのためのConvention」RFC1215。
[5] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Structure of
Management Information for Version 2 (SMIv2)", STD 58, RFC 2578,
April 1999.
[5]McCloghrieとK.とパーキンス、D.とJ.Schoenwaelder、「バージョン2(SMIv2)のための経営情報の構造」STD58、RFC2578(1999年4月)。
[6] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Textual
Conventions for SMIv2", STD 58, RFC 2579, April 1999.
[6]McCloghrieとK.とパーキンスとD.とJ.Schoenwaelder、「SMIv2"、STD58、RFC2579、1999年4月の原文のコンベンション。」
[7] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Conformance
Statements for SMIv2", STD 58, RFC 2580, April 1999.
[7]McCloghrieとK.とパーキンスとD.とJ.Schoenwaelder、「SMIv2"、STD58、RFC2580、1999年4月のための順応声明。」
[8] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple
Network Management Protocol", STD 15, RFC 1157, May 1990.
[8] ケース、J.、ヒョードル、M.、Schoffstall、M.、およびJ.デーヴィン(「簡単なネットワーク管理プロトコル」、STD15、RFC1157)は1990がそうするかもしれません。
[9] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,
"Introduction to Community-based SNMPv2", RFC 1901, January
1996.
[9]ケース、J.、McCloghrie、K.、ローズ、M.、およびS.Waldbusser、「地域密着型のSNMPv2"への紹介、RFC1901、1996年1月。」
[10] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Transport
Mappings for Version 2 of the Simple Network Management Protocol
(SNMPv2)", RFC 1906, January 1996.
[10]ケース、J.、McCloghrie、K.、ローズ、M.、およびS.Waldbusser、「簡単なネットワークマネージメントのバージョン2のための輸送マッピングは(SNMPv2)について議定書の中で述べます」、RFC1906、1996年1月。
St. Johns Standards [Page 51] RFC 2669 DOCSIS Cable Device MIB August 1999
ジョーンズStandards[51ページ]の聖RFC2669DOCSISは1999年8月にデバイスMIBに電報を打ちます。
[11] Case, J., Harrington D., Presuhn R. and B. Wijnen, "Message
Processing and Dispatching for the Simple Network Management
Protocol (SNMP)", RFC 2572, April 1999.
[11]ケース、J.、ハリントンD.、Presuhn R.、およびB.Wijnen、「メッセージ処理と簡単なネットワークマネージメントのために急いでいるのは(SNMP)について議定書の中で述べます」、RFC2572、1999年4月。
[12] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM)
for version 3 of the Simple Network Management Protocol
(SNMPv3)", RFC 2574, April 1999.
[12] ブルーメンソルとU.とB.Wijnen、「Simple Network Managementプロトコル(SNMPv3)のバージョン3のためのユーザベースのSecurity Model(USM)」、RFC2574、1999年4月。
[13] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Protocol
Operations for Version 2 of the Simple Network Management
Protocol (SNMPv2)", RFC 1905, January 1996.
[13] ケース、J.、McCloghrie(K.、ローズ、M.、およびS.Waldbusser)は「簡単なネットワーク管理プロトコル(SNMPv2)のバージョン2のための操作について議定書の中で述べます」、RFC1905、1996年1月。
[14] Levi, D., Meyer, P. and B. Stewart, "SNMP Applications", RFC
2573, April 1999.
[14] レビとD.とマイヤーとP.とB.スチュワート、「SNMPアプリケーション」、RFC2573、1999年4月。
[15] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access
Control Model (VACM) for the Simple Network Management Protocol
(SNMP)", RFC 2575, April 1999.
[15] Wijnen、B.、Presuhn、R.、およびK.McCloghrie、「簡単なネットワークマネージメントのための視点ベースのアクセス制御モデル(VACM)は(SNMP)について議定書の中で述べます」、RFC2575、1999年4月。
[16] "Data-Over-Cable Service Interface Specifications: Cable Modem
Radio Frequency Interface Specification SP-RFI-I04-980724",
DOCSIS, July 1998,
http://www.cablemodem.com/public/pubtechspec/SP-RFI-I04-
980724.pdf.
[16] 「データ過剰ケーブルサービスは仕様を連結します」。 「ケーブルモデム無線周波数インターフェース仕様SP-RFI-I04-980724」、DOCSIS、1998年7月、 http://www.cablemodem.com/public/pubtechspec/SP-RFI-I04- 980724.pdf。
[17] Steinberg, L., "Techniques for Managing Asynchronously Generated
Alerts", RFC 1224, May 1991.
[17] スタインバーグ(L.、「管理するためのテクニックは警戒を非同期に生成した」RFC1224)は1991がそうするかもしれません。
[18] "Data-Over-Cable Service Interface Specifications: Operations
Support System Interface Specification RF Interface SP-OSSI-RF-
I02-980410", DOCSIS, April 1998,
http://www.cablemodem.com/public/pubtechspec/ossi/sp-ossi.PDF.
[18] 「データ過剰ケーブルサービスは仕様を連結します」。 「操作サポート・システムインターフェース仕様rfインタフェースSP-オッシrf-I02-980410」、DOCSIS、1998年4月、 http://www.cablemodem.com/public/pubtechspec/ossi/sp-ossi.PDF 。
[19] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[19] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[20] "Data-Over-Cable Service Interface Specifications: Baseline
Privacy Interface Specification SP-BPI-I01-970922", DOCSIS,
September 1977,
http://www.cablemodem.com/public/pubtechspec/ss/SP-BPI-I01-
970922.pdf
[20] 「データ過剰ケーブルサービスは仕様を連結します」。 「基線プライバシーインターフェース仕様SP BPI I01-970922」、DOCSIS、1977年9月、 http://www.cablemodem.com/public/pubtechspec/ss/SP-BPI-I01- 970922.pdf
7. Security Considerations
7. セキュリティ問題
This MIB relates to a system which will provide metropolitan public internet access. As such, improper manipulation of the objects represented by this MIB may result in denial of service to a large number of end-users. In addition, manipulation of the
このMIBは首都の公共のインターネットアクセサリーを提供するシステムに関連します。 そういうものとして、このMIBによって表されたオブジェクトの不適当な操作は多くのエンドユーザに対するサービスの否定をもたらすかもしれません。 追加、操作
St. Johns Standards [Page 52] RFC 2669 DOCSIS Cable Device MIB August 1999
ジョーンズStandards[52ページ]の聖RFC2669DOCSISは1999年8月にデバイスMIBに電報を打ちます。
docsDevNmAccessTable, docsDevFilterLLCTable, docsDevFilterIpTable and the elements of the docsDevCpe group may allow an end-user to increase their service levels, spoof their IP addresses, change the permitted management stations, or affect other end-users in either a positive or negative manner.
docsDevCpeグループのdocsDevNmAccessTable、docsDevFilterLLCTable、docsDevFilterIpTable、および要素で、エンドユーザは、それらのサービスレベルを増強するか、それらのIPアドレスを偽造するか、受入れられた管理局を変えるか、または肯定しているか否定している態度で他のエンドユーザに影響するかもしれません。
There are a number of management objects defined in this MIB that have a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. In addition to those mentioned above:
aがあります。読書して書くことのマックス-ACCESS節を持っているこのMIBで定義された管理オブジェクトに付番する、そして/または、読書して作成します。 そのようなオブジェクトはいくつかのネットワーク環境で敏感であるか、または被害を受け易いと考えられるかもしれません。 適切な保護のない非安全な環境におけるSET操作のサポートはネットワーク操作のときにマイナスの影響がある場合があります。 上に言及されたものに加えて:
o The use of docsDevNmAccessTable to specify management stations
is considered to be only limited protection and does not protect
against attacks which spoof the management station's IP address.
The use of stronger mechanisms such as SNMPv3 security should be
considered where possible. Specifically, SNMPv3 VACM and USM
MUST be used with any v3 agent which implements this MIB.
Administrators may also wish to consider whether even read
access to docsDevNmAccessTable may be undesirable under certain
circumstances.
o 管理局を指定するdocsDevNmAccessTableの使用は、限定保護だけであると考えられて、管理局のIPアドレスを偽造する攻撃から守りません。 SNMPv3セキュリティなどの、より強いメカニズムの使用は可能であるところで考えられるべきです。 明確にSNMPv3 VACMとUSM MUST、このMIBを実装するあらゆるv3エージェントと共に使用されてください。 また、管理者は、読まれるか否かに関係なくさえ、docsDevNmAccessTableへのアクセスが、ある状況で望ましくないかもしれないと考えたがっているかもしれません。
o The CM may have its software changed by the actions of the
management system. An improper software load may result in
substantial vulnerabilities and the loss of the ability of the
management system to control the cable modem.
o CMで、マネージメントシステムの機能でソフトウェアを変えるかもしれません。 不適当なソフトウェア負荷はマネージメントシステムがケーブルモデムを制御する能力のかなりの脆弱性と損失をもたらすかもしれません。
o The device may be reset by setting docsDevResetNow = true(1).
This causes the device to reload its configuration files as well
as eliminating all previous non-persistent network management
settings. As such, this may provide a vector for attacking the
system.
o デバイスは、本当のdocsDevResetNow=(1)を設定することによって、リセットされるかもしれません。 これで、デバイスは前のすべての非永続的なネットワークマネージメント設定を排除することと同様に構成ファイルを再び積みます。 そういうものとして、これはシステムを攻撃するのにベクトルを提供するかもしれません。
o Setting docsDevEvThrottleAdminStatus = unconstrained(1) (which
is also the DEFVAL) may cause flooding of traps, which can
disrupt network service.
o 自由なdocsDevEvThrottleAdminStatusを設定する=(1)(また、DEFVALである)は罠の氾濫を引き起こすかもしれません。(罠はネットワーク・サービスを中断できます)。
This MIB does not affect confidentiality of services on a cable modem system. [20] specifies the implementation of the DOCSIS Baseline privacy mechanism. The working group expects to issue a MIB for the management of this mechanism at a later time.
このMIBはケーブルモデムシステムの上でサービスの秘密性に影響しません。 [20]はDOCSIS Baselineプライバシーメカニズムの実装を指定します。 ワーキンググループは、このメカニズムの管理のために後でMIBを発行すると予想します。
SNMPv1 by itself is not a secure environment. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB.
それ自体でSNMPv1は安全な環境ではありません。 ネットワーク自体が安全であっても(例えば、IPSecを使用するのによる)、その時でさえ、アクセスとGET/SET(読むか、変える、作成する、または削除する)へのオブジェクトがこのMIBに安全なネットワークにだれに許容されているかに関してコントロールが全くありません。
St. Johns Standards [Page 53] RFC 2669 DOCSIS Cable Device MIB August 1999
ジョーンズStandards[53ページ]の聖RFC2669DOCSISは1999年8月にデバイスMIBに電報を打ちます。
It is recommended that the implementers consider the security features as provided by the SNMPv3 framework. Specifically, the use of the User-based Security Model [12] and the View-based Access Control Model [15] is recommended.
implementersがSNMPv3フレームワークで提供するようにセキュリティ機能を考えるのは、お勧めです。 明確に、UserベースのSecurity Model[12]とViewベースのAccess Control Model[15]の使用はお勧めです。
It is then a customer/user responsibility to ensure that the SNMP entity giving access to an instance of this MIB, is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them.
そして、本当にGETに正当な権利を持っている校長(ユーザ)をそれらだけへのオブジェクトへのアクセスに与えるか、または(変えるか、作成する、または削除します)それらをSETに与えるために構成されて、それはこのMIBのインスタンスへのアクセスを与えるSNMP実体が適切にそうであることを保証する顧客/ユーザ責任です。
8. Intellectual Property
8. 知的所有権
The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat.
IETFはどんな知的所有権の正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 どちらも、それはそれを表しません。どんなそのような権利も特定するためにいずれも取り組みにしました。 BCP-11で標準化過程の権利と規格関連のドキュメンテーションに関するIETFの手順に関する情報を見つけることができます。 権利のクレームのコピーで利用可能に作られるべきライセンスの保証、または一般的なライセンスか許可が作成者によるそのような所有権の使用に得させられた試みの結果が公表といずれにも利用可能になったか、またはIETF事務局からこの仕様のユーザを得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETFはこの規格を練習するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 IETF専務に情報を扱ってください。
9. Author's Address
9. 作者のアドレス
Michael StJohns @Home Network 425 Broadway Redwood City, CA 94063 U.S.A
レッドウッドシティー、マイケルStJohns@Home Network425ブロードウェイカリフォルニア94063U.S.A
Phone: +1 650 569 5368 EMail: stjohns@corp.home.net
以下に電話をしてください。 +1 5368年の650 569メール: stjohns@corp.home.net
St. Johns Standards [Page 54] RFC 2669 DOCSIS Cable Device MIB August 1999
ジョーンズStandards[54ページ]の聖RFC2669DOCSISは1999年8月にデバイスMIBに電報を打ちます。
10. Full Copyright Statement
10. 完全な著作権宣言文
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
St. Johns Standards [Page 55]
聖ジョーンズの規格[55ページ]
一覧
スポンサーリンク
