rfc1525.txt
来自「RFC 的详细文档！」· 文本 代码 · 共 1,011 行 · 第 1/3 页
TXT
1,011 行
Network Working Group E. Decker
Request for Comments: 1525 cisco Systems, Inc.
Obsoletes: 1286 K. McCloghrie
Category: Standards Track Hughes LAN Systems, Inc.
P. Langille
DEC
A. Rijsinghani
DEC
September 1993
Definitions of Managed Objects for
Source Routing Bridges
Status of this Memo
This RFC 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" for the standardization state and status
of this protocol. Distribution of this memo is unlimited.
Table of Contents
1. Introduction ......................................... 2
2. The Network Management Framework ..................... 2
2.1 Object Definitions .................................. 2
3. Overview ............................................. 2
3.1 Structure of MIB .................................... 3
3.1.1 The dot1dSr Group ................................. 4
3.1.2 The dot1dPortPair Group ........................... 4
3.2 Relationship to Other MIBs .......................... 5
3.2.1 Relationship to the Bridge MIB .................... 5
3.2.2 Relationship to the 'system' group ................ 5
3.2.3 Relationship to the 'interfaces' group ............ 5
4. Changes from RFC 1286 ................................ 6
5. Definitions .......................................... 7
5.1 Groups in the SR MIB ................................ 7
5.2 The dot1dSr Group Definitions ....................... 7
5.3 The dot1dPortPair Group Definitions ................. 14
6. Acknowledgments ...................................... 16
7. References ........................................... 16
8. Security Considerations .............................. 18
9. Authors' Addresses ................................... 18
Decker, McCloghrie, Langille & Rijsinghani [Page 1]
RFC 1525 Source Routing Bridge MIB September 1993
1. Introduction
This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in TCP/IP based internets.
In particular, it defines objects for managing source routing and
source routing transparent bridges. These bridges are also required
to implement relevant groups in the Bridge MIB [6].
This MIB supersedes the dot1dSr group of objects published in an
earlier version of the Bridge MIB, RFC 1286. Changes have primarily
been made to track changes in the IEEE 802.5M SRT Addendum to the
IEEE 802.1D Standard for MAC Bridges.
2. The Network Management Framework
The Internet-standard Network Management Framework consists of three
components. They are:
o STD 16, RFC 1155 which defines the SMI, the mechanisms used for
describing and naming objects for the purpose of
management. STD 16, RFC 1212 defines a more concise description
mechanism, which is wholly consistent with the SMI.
o STD 17, RFC 1213 defines MIB-II, the core set of managed objects
for the Internet suite of protocols.
o STD 15, RFC 1157 which defines the SNMP, the protocol used for
network access to managed objects.
The Framework permits new objects to be defined for the purpose of
experimentation and evaluation.
2.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 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.
3. Overview
A common device present in many networks is the Bridge. This device
is used to connect Local Area Network segments below the network
Decker, McCloghrie, Langille & Rijsinghani [Page 2]
RFC 1525 Source Routing Bridge MIB September 1993
layer. There are two major modes defined for this bridging;
transparent and source route. The transparent method of bridging is
defined in the IEEE 802.1d MAC Bridge specification [11]. Source
route bridging has been defined by I.B.M. and is described in the
Token Ring Architecture Reference [12], as well as the IEEE 802.5M
SRT Bridge Operations Addendum [14] to 802.1d. This memo defines
objects needed for management of a source routing bridge, and is an
extension to the SNMP Bridge MIB [6].
An explicit attempt was made to keep this MIB as simple as possible.
This was accomplished by applying the following criteria to objects
proposed for inclusion:
(1) Start with a small set of essential objects and add only
as further objects are needed.
(2) Require objects be essential for either fault or
configuration management.
(3) Consider evidence of current use and/or utility.
(4) Limit the total of objects.
(5) Exclude objects which are simply derivable from others in
this or other MIBs.
(6) Avoid causing critical sections to be heavily
instrumented. The guideline that was followed is one
counter per critical section per layer.
3.1. Structure of MIB
Objects in this MIB are arranged into groups. Each group is
organized as a set of related objects. The overall structure and
assignment of objects to their groups is shown below. Where
appropriate, the corresponding management object name found in IEEE
802.1d [11] and IEEE 802.5M [14] is also included.
SR Bridge MIB Name IEEE Name
dot1dSr
PortTable
Port
HopCount SourceRoutingPort
.PortHopCount
LocalSegment .SegmentNumber
BridgeNum .BridgeNumber
TargetSegment
Decker, McCloghrie, Langille & Rijsinghani [Page 3]
RFC 1525 Source Routing Bridge MIB September 1993
LargestFrame .LargestFrameSize
STESpanMode .LimitedBroadcastMode
SpecInFrames BridgePort
.ValidSRFramesReceived
SpecOutFrames .ValidSRForwardedOutbound
ApeInFrames
ApeOutFrames .BroadcastFramesForwarded
SteInFrames
SteOutFrames .BroadcastFramesForwarded
SegmentMismatchDiscards .DiscardInvalidRI
DuplicateSegmentDiscards .LanIdMismatch
HopCountExceededDiscards .FramesDiscardedHopCountExceeded
The following IEEE management objects have not been included in the
SR Bridge MIB for the indicated reasons.
IEEE Object Disposition
SourceRoutingPort
The following objects were NOT
included in this MIB because they
are redundant or not considered
useful.
.LimitedBroadcastEnable
.DiscardLackOfBuffers
.DiscardErrorDetails
.DiscardTargetLANInoperable
.ValidSRDiscardedInbound
.BroadcastBytesForwarded
.NonBroadcastBytesForwarded
.FramesNotReceivedDueToCongestion
.FramesDiscardedDueToInternalError
3.1.1. The dot1dSr Group
This group contains the objects that describe the entity's state with
respect to source route bridging. If source routing is not
supported, this group will not be implemented. This group is
applicable to source route only, and SRT bridges.
3.1.2. The dot1dPortPair Group
Implementation of this group is optional. This group is implemented
by those bridges that support the port-pair multiport model of the
source route bridging mode as defined in the IEEE 802.5M SRT Addendum
to 802.1d.
Decker, McCloghrie, Langille & Rijsinghani [Page 4]
RFC 1525 Source Routing Bridge MIB September 1993
3.2. Relationship to Other MIBs
As described above, some IEEE 802.1d management objects have not been
included in this MIB because they overlap with objects in other MIBs
applicable to a bridge implementing this MIB. In particular, it is
assumed that a bridge implementing this MIB will also implement (at
least) the Bridge MIB and the 'system' group and the 'interfaces'
group defined in MIB-II [4].
3.2.1. Relationship to the Bridge MIB
The Bridge MIB [6] must be implemented by all bridges, including
transparent, SR and SRT bridges. The SR bridge MIB is an extension
to the Bridge MIB.
3.2.2. Relationship to the 'system' group
In MIB-II, the 'system' group is defined as being mandatory for all
systems such that each managed entity contains one instance of each
object in the 'system' group. Thus, those objects apply to the
entity as a whole irrespective of whether the entity's sole
functionality is bridging, or whether bridging is only a subset of
the entity's functionality.
3.2.3. Relationship to the 'interfaces' group
In MIB-II, the 'interfaces' group is defined as being mandatory for
all systems and contains information on an entity's interfaces, where
each interface is thought of as being attached to a `subnetwork'.
(Note that this term is not to be confused with `subnet' which refers
to an addressing partitioning scheme used in the Internet suite of
protocols.) The term 'segment' is used in this memo to refer to such
a subnetwork.
Implicit in this MIB is the notion of ports on a bridge. Each of
these ports is associated with one interface of the 'interfaces'
group, and in most situations, each port is associated with a
different interface. However, there are situations in which multiple
ports are associated with the same interface. An example of such a
situation would be several ports, each corresponding one-to-one with
several X.25 virtual circuits, but all on the same interface.
Each port is uniquely identified by a port number. A port number has
no mandatory relationship to an interface number, but in the simple
case, a port number will have the same value as the corresponding
interface's interface number.
Decker, McCloghrie, Langille & Rijsinghani [Page 5]
RFC 1525 Source Routing Bridge MIB September 1993
Some entities provide other services in addition to bridging with
respect to the data sent and received by their interfaces. In such
situations, only a subset of the data sent/received on an interface
is within the domain of the entity's bridging functionality. This
subset is considered to be delineated according to a set of
protocols, with some protocols being bridged, and other protocols not
being bridged. For example, in an entity which exclusively performed
bridging, all protocols would be considered as being bridged, whereas
in an entity which performed IP routing on IP datagrams and only
bridged other protocols, only the non-IP data would be considered as
being bridged.
Thus, this MIB (and in particular, its counters) are applicable only
to that subset of the data on an entity's interfaces which is
sent/received for a protocol being bridged. All such data is
sent/received via the ports of the bridge.
4. Changes from RFC 1286
In addition to being separated from the Bridge MIB into a separate
document, the following changes were implemented as a result of
feedback from IEEE 802.5M:
(1) Changed syntax of dot1dSrPortLargestFrame to INTEGER in
order to allow for having 64 possible values as described
in draft 7 of the SR Addendum. Listed all legal values
in description.
(2) Updated syntax of dot1dSrPort, used to index into
dot1dSrPortTable, to use the range (1..65535).
(3) Added a counter to dot1dSrPortTable to count occurrences
of duplicate LAN IDs or Tree errors.
(4) Added a counter to dot1dSrPortTable to count LAN ID
mismatches.
(5) Added text to dot1dSrPortSpecInFrames and
dot1dSrPortSpecOutFrames clarifying that they are also
referred to as Source Routed Frames.
(6) Added text to dot1dSrPortApeInFrames and
dot1dSrPortApeOutFrames clarifying that they are also
referred to as All Routes Explorer frames.
(7) Added a scalar variable to the dot1dSr group to indicate
whether the bridge uses 3 bit or 6 bit length negotiation
fields.
⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?