rfc2024.txt
来自「RFC 的详细文档！」· 文本 代码 · 共 1,660 行 · 第 1/5 页
TXT
1,660 行
Network Working Group D. Chen, Editor
Request for Comments: 2024 P. Gayek
Category: Standards Track IBM
S. Nix
Metaplex, Inc.
October 1996
Definitions of Managed Objects for Data Link Switching
using SMIv2
Status of this 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.
Abstract
This specification defines an extension to the Management Information
Base (MIB) for use with SNMP-based network management. In
particular, it defines objects for configuring, monitoring, and
controlling Data Link Switches (DLSw) [1].
This memo specifies a MIB module in a manner that is both compliant
to the SNMPv2 SMI [2], and semantically identical to the SNMPv1
definitions [3].
Table of Contents
1.0 The SNMPv2 Network Management Framework . . . . . . . . . 2
1.1 Object Definitions . . . . . . . . . . . . . . . . . . . . 2
2.0 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.1 Relation to Interface Group (RFC 1573) [8] . . . . . . . . . 2
2.2 Relation to Underlying DLC Layer . . . . . . . . . . . . . 3
2.3 Relation to SDLC MIB (RFC 1747) . . . . . . . . . . . . . 3
2.4 DLSw MIB Structure . . . . . . . . . . . . . . . . . . . . 4
2.4.1 Compliance . . . . . . . . . . . . . . . . . . . . . . 4
2.5 DLSw MIB Usage . . . . . . . . . . . . . . . . . . . . . . 5
2.5.1 Cooperative DLSw nodes . . . . . . . . . . . . . . . . 5
2.5.2 Setting capabilities exchange-related objects . . . . 5
2.5.3 Examples of Tasks Using This MIB . . . . . . . . . . . 6
3.0 Definitions . . . . . . . . . . . . . . . . . . . . . . . 11
4.0 Acknowledgements . . . . . . . . . . . . . . . . . . . . . 89
5.0 References . . . . . . . . . . . . . . . . . . . . . . . . 89
6.0 Security Considerations . . . . . . . . . . . . . . . . . 90
Chen, et. al. Standards Track [Page 1]
RFC 2024 DLSw MIB using SMIv2 October 1996
7.0 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 90
1.0 The SNMPv2 Network Management Framework
The SNMP Network Management Framework presently consists of three
major components. They are:
RFC 1902 [2] which defines the SMI, the mechanisms used for
describing and naming objects for the purpose of management.
STD 17, RFC 1213 [4] defines MIB-II, the core set of managed
objects for the Internet suite of protocols.
STD 15, RFC 1157 [5] and RFC 1905 [6] which define two versions of
the protocol used for network access to managed objects.
The Framework permits new objects to be defined for the purpose of
experimentation and evaluation.
1.1 Object Definitions
Managed objects are accessed via a virtual information store, termed
the Management Information Base or MIB. Objects in the MIB are
defined using the subset of Abstract Syntax Notation One (ASN.1)
defined in the SMI. In particular, each object type is named by an
OBJECT IDENTIFIER, an administratively assigned name. The object
type together with an object instance serves to uniquely identify a
specific instantiation of the object. For human convenience, we
often use a textual string, termed the descriptor, to refer to the
object type.
2.0 Overview
This memo identifies the set of objects for configuring, monitoring,
and controlling Data Link Switches.
2.1 Relation to Interface Group (RFC 1573) [8]
o ifIndex is used as the index into dlswIfTable, which shows and
controls the interfaces that DLSw is active on.
o Local entries in the MAC address and NetBIOS (NB) name caches can
point to an ifEntry to indicate the interface through which DLSw can
reach that MAC address or NB name. See the objects
dlswDirMacLocation and dlswDirNBLocation.
o Local entries in the circuit table use ifIndex to indicate the
interface through which DLSw is connected to the local end station.
Chen, et. al. Standards Track [Page 2]
RFC 2024 DLSw MIB using SMIv2 October 1996
See the object dlswCircuitS1Index.
o ifIndex is the primary index into dlswSdlcLsTable, which lists the
SDLC stations DLSw is serving.
2.2 Relation to Underlying DLC Layer
The DLSw MIB does not duplicate the information in the MIBs for the
DLC layer underneath it. Instead, each circuit table entry contains
a pointer to a conceptual row in an underlying enterprise-specific or
standard DLC MIB.
Using the 802.2 LLC management as an example, the following rules
should be considered when developing new DLSw related DLC MIBs, and
when implementing the interactions between DLSw MIB and DLC MIBs:
o The referenced row should represent the local LLC-2 (and/or LLC-1,
if supported) link station that DLSw is using. In the current 802.2
LLC MIB draft, this might be a row of one of the tables
llcCcAdminTable, llcCcOperTable, or llcCcStatsTable.
A circuit using local LLC services will therefore have
dlswCircuitS1DlcType = llc, and dlswCircuitS1Dlc = pointer to an LLC
MIB table row.
o Because DLSw is the user of LLC services, it is generally preferable
to initiate administrative actions using the DLSw MIB and allow DLSw
to control LLC directly, rather than starting with LLC MIB
administrative actions. For example, a hung circuit should be
disconnected by setting dlswCircuitState, as opposed to setting
llcCcAdminStatus to disable the LLC part of the circuit. Similarly,
setting bits in dlswIfSapList will cause row creation in
llcSapOperTable as well as set the necessary DLSw-LLC relationship.
2.3 Relation to SDLC MIB (RFC 1747)
The general comments stated in 2.2, "Relation to Underlying DLC
Layer" apply to the SDLC MIB. The following apply if the DLSw MIB is
implemented in a product that also implements RFC 1747 [9]:
o The row referenced from dlswCircuitS1Dlc should represent the local
SDLC link station that DLSw is using. This might be a row of one of
the tables sdlcLSAdminTable, sdlcLSOperTable, or sdlcLSStatsTable.
A circuit using local SDLC services will therefore have
dlswCircuitS1DlcType = sdlc, and dlswCircuitS1Dlc = OID of one of
these table rows.
Chen, et. al. Standards Track [Page 3]
RFC 2024 DLSw MIB using SMIv2 October 1996
o dlswSdlcLsTable uses the same indices that are used to index link
station information in RFC 1747. This table provides a mapping
between this native SDLC addressing (interface, link station
address) and the addressing used in the DLSw domain (local MAC and
SAP).
2.4 DLSw MIB Structure
See 3 .0, "Definitions" on page 11 for a diagram outlining the DLSw
MIB structure. The following groups of objects are included:
dlswNode Objects related to this DLSw node's configuration,
monitoring and control.
dlswTConn Objects relating to transport connections to this
DLSw's partner nodes.
dlswInterface Objects configured for this DLSw relating to its local
interfaces.
dlswDirectory Objects reflecting this DLSw's view of where
end-station resources (MAC addresses and NetBIOS names)
are located.
dlswCircuit Objects showing the end-station connections that
DLSw currently has established, or that are coming up
or have gone down.
dlswSDLC Objects configured for this DLSw's SDLC-attached end
stations.
2.4.1 Compliance
The MIB provides the following compliance statements:
dlswCoreCompliance Defines the minimum support required of all
implementations. Note that for this and the
other compliance statements, NetBIOS-related
objects are grouped separately because the
DLSw Version 1 Standard [1] does not require
NetBIOS support.
dlswTConnTCPCompliance Defines the minimum support required of
implementations that use TCP as a transport
protocol.
dlswDirCompliance Defines the minimum support required of
implementations that support some sort of
Chen, et. al. Standards Track [Page 4]
RFC 2024 DLSw MIB using SMIv2 October 1996
directory function.
dlswDirLocateCompliance Defines the minimum support required of
implementations that support a directory
function and also support the ordered
retrieval of the entries that match a given
resource.
dlswSdlcCompliance Defines the minimum support required of
implementations that support SDLC-attached
end stations.
2.5 DLSw MIB Usage
2.5.1 Cooperative DLSw nodes
To reduce the size of the MIB, thus the amount of data that each
agent needs to keep, the information that usually could be made
available in two partner nodes (e.g., information exchanged between
them) is only defined in the MIB as the info received. That is,
there are no objects defined for the info sent. In order to form the
complete picture of the state of a resource, the manager needs to
retrieve info from multiple DLSw nodes. An example is that the SAP
list, NETBIOS list and MAC list are kept at the receiving end of a
DLSw capabilities exchange (the sender does not save what it sent to
each partner).
Note well: The DLSw protocol does not specify a technique for a
manager to correlate the transport address of the partner managed
DLSw node and the transport address that the management protocol
uses.
2.5.2 Setting capabilities exchange-related objects
This MIB supports changes to DLSw variables whose change should be
reported to DLSw partner nodes in a "run-time" capabilities exchange.
Since a DLSw node normally unicasts these capabilities messages to
all its active partners, frequent changes to these variables can
result in excessive network traffic. To avoid this problem,
developers of network management applications using this MIB should
try to group all such changes in a few SNMP SET requests, and should
send them in bulk. Agent developers should implement a technique to
group a number of changes into a single capabilities exchange
message. One possible approach is to send a run-time capabilities
message only if no capabilities-related changes have been received
for a pre-defined period of time.
Chen, et. al. Standards Track [Page 5]
RFC 2024 DLSw MIB using SMIv2 October 1996
2.5.3 Examples of Tasks Using This MIB
2.5.3.1 Configuring DLSw to actively connect to a specific TCP/IP
partner
Create a conceptual row in dlswTConnConfigTable with: Index = the
highest the managed station has used so far + 1; TDomain =
dlswTCPDomain; LocalTAddr = this node's DLSw IP address; RemoteTAddr
= the partner's DLSw IP address; EntryType = individual; SetupType =
activePersistent. Note that determining the index to use may require
dumping the TConnConfigTable, but this will not typically be a large
table. If the DLSw node rejects the row creation due to index
collision, the management station should increment its index value
and try again.
2.5.3.2 Configuring DLSw to passively accept any partner
Create a conceptual row in dlswTConnConfigTable as above but with:
RemoteTAddr = 0; EntryType = global; SetUpType = passive. Every
individual transport connection accepted as a result of this global
row will inherit the configuration values from this row.
To prevent a specific remote node from being passively accepted as a
partner, create another row with: RemoteTAddr = that node's IP
address; EntryType = individual; SetupType = excluded.
2.5.3.3 Configuring DLSw to allow or connect to a group of partners
Define a conceptual row in dlswTConnConfigTable as above but with:
EntryType = group; GroupDefinition = pointer to an enterprise-
specific representation of a group. For example, a group definition
might consist of an IP address value and mask, or a multicast IP
address. Every individual transport connection accepted as a result
of this group row will inherit the configuration values from this
row.
When a group is created that has some overlap with entries where
EntryType = individual (there will always be this overlap when a
global row exists), the DLSw node must use the configured rows using
a "most specific match wins" rule. That is, the entry in
TConnConfigTable with the remote address most nearly matching an
incoming connection should be used to provide the values for the new
connection. For equal matches, the choice of TConnConfigTable entry
is up to the DLSw node implementation. Note that the management
station should never create two TConnConfig rows with duplicate
remote addressing values.
⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?