Network Working Group E. Bell Request for Comments: 2674 3Com Corp. Category: Standards Track A. Smith Extreme Networks P. Langille Newbridge Networks A. Rijhsinghani Cabletron Systems K. McCloghrie cisco Systems August 1999 Definitions of Managed Objects for Bridges with Traffic
Classes, Multicast Filtering and Virtual LAN Extensions
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. Copyright Notice
Copyright (C) The Internet Society (1999). All Rights Reserved. Abstract
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 two MIB modules for managing the new
capabilities of MAC bridges defined by the IEEE 802.1D-1998 MAC
Bridges and the IEEE 802.1Q-1998 Virtual LAN (VLAN) standards for
bridging between Local Area Network (LAN) segments. One MIB module
defines objects for managing the ’Traffic Classes’ and ’Enhanced
Multicast Filtering’ components of IEEE 802.1D-1998. The other MIB
尼龙扣
module defines objects for managing IEEE 802.1Q VLANs.
Provisions are made for support of transparent bridging. Provisions
废渣4
are also made so that these objects apply to bridges connected by
subnetworks other than LAN segments. This memo also includes several MIB modules in a manner that is compliant to the SMIv2 [V2SMI].
This memo supplements RFC 1493 [BRIDGEMIB] and (to a lesser extent)
RFC 1525 [SBRIDGEMIB].
Bell, et al. Standards Track [Page 1]
Table of Contents
1 The SNMP Management Framework (3)
2 Overview (4)
2.1 Scope (4)
3 Structure of MIBs (5)
3.1 Structure of Extended Bridge MIB module (5)
3.1.1 Relationship to IEEE 802.1D-1998 Manageable Objects (6)
3.1.2 Relationship to IEEE 802.1Q Manageable Objects (8)
3.1.3 The dot1dExtBase Group (8)
3.1.4 The dot1dPriority Group (9)
3.1.5 The dot1dGarp Group (9)
3.1.6 The dot1dGmrp Group (9)
3.1.7 The dot1dTpHCPortTable (9)
3.1.8 The dot1dTpPortOverflowTable (9)
3.2 Structure of Virtual Bridge MIB module (9)
3.2.1 Relationship to IEEE 802.1Q Manageable Objects (9)
3.2.2 The dot1qBase Group (13)
3.2.3 The dot1qTp Group (13)
3.2.4 The dot1qStatic Group (13)
3.2.5 The dot1qVlan Group (13)
3.3 Textual Conventions (13)
3.4 Relationship to Other MIBs (14)
3.4.1 Relationship to the ’system’ group (14)
3.4.2 Relation to Interfaces MIB (14)
3.4.2.1 Layering Model (15)
3.4.2.2 ifStackTable (16)
3.4.2.3 ifRcvAddressTable (16)
3.4.3 Relation to Original Bridge MIB (16)
3.4.3.1 The dot1dBase Group (16)
3.4.3.2 The dot1dStp Group (17)
3.4.3.3 The dot1dTp Group (17)万次火柴
3.4.3.4 The dot1dStatic Group (17)
3.4.3.5 Additions to the Original Bridge MIB (18)
4 Definitions for Extended Bridge MIB (18)
5 Definitions for Virtual Bridge MIB (39)
6 Acknowledgments (80)
7 Security Considerations (80)
8 References (81)
9 Authors’ Addresses (84)
10 Intellectual Property (85)
11 Full Copyright Statement (86)
Bell, et al. Standards Track [Page 2]
1. The SNMP Management Framework
The SNMP Management Framework presently consists of five major
components:
o An overall architecture, described in an Architecture for
Describing SNMP Management Frameworks [ARCH].
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 [V1SMI], STD 16, RFC 1212 [V1CONCISE] and RFC 1215
[V1TRAPS]. The second version, called SMIv2, is described in STD 58, RFC 2578 [V2SMI], STD 58, RFC 2579 [V2TC] and STD 58, RFC
2580 [V2CONFORM].
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 [V1PROTO]. A second version of the SNMP message protocol, which is not an Internet standards track
protocol, is called SNMPv2c and described in RFC 1901
[V2COMMUNITY] and RFC 1906 [V2TRANS]. The third version of the
message protocol is called SNMPv3 and described in RFC 1906
[V2TRANS], Message Processing and Dispatching [V3MPC] and User-
based Security Model [V3USM].
o Protocol operations for accessing management information. The
first set of protocol operations and associated PDU formats is
described in STD 15, RFC 1157 [V1PROTO]. A second set of
protocol operations and associated PDU formats is described in
RFC 1905 [V2PROTO].
o A set of fundamental applications described in SNMPv3
Applications [V3APPS] and the view-based access control mechanism described in View-based Access Control Model [V3VACM].
隐私
保护通话Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB aredefined using the mechanisms defined in the 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 Bell, et al. Standards Track [Page 3]
SMIv1 during the translation process. However, this loss of machine readable information is not considered to change the semantics of the MIB.
2. Overview
A common device present in many networks is the Bridge. This device is used to connect Local Area Network segments below the network
layer. These devices are often known as ’layer 2 switches’.
There are two major modes defined for this bridging: Source-Route and transparent. Source-Route bridging is described by IEEE 802.5
[802.5]. and is not discussed further in this document.
The transparent method of bridging is defined by IEEE 802.1D-1998
[802.1D] which is an update to the original IEEE 802.1D specification [802.1D-ORIG]. Managed objects for that original specification of
transparent bridging were defined in RFC 1493 [BRIDGEMIB].
The original IEEE 802.1D is augmented by IEEE 802.1Q-1998 [802.1Q] to provide support for ’virtual bridged LANs’ where a single bridged
physical LAN network may be used to support multiple logical bridged LANs, each of which offers a service approximately the same as that
defined by IEEE 802.1D. Such virtual LANs (VLANs) are an integral
feature of switched LAN networks. A VLAN can be viewed as a group of end-stations on multiple LAN segments and can communicate as if they were on a single LAN. IEEE 802.1Q defines port-based Virtual LANs
where membership is determined by the bridge port on which data
frames are received. This memo defines the objects needed for the
management of port-based VLANs in bridge entities.
This memo defines those objects needed for the management of a
bridging entity operating in the transparent mode, as well as some
objects applicable to all types of bridges. Managed objects for
Source-Route bridging are defined in RFC 1525 [SRBRIDGEMIB].
This MIB includes a comprehensive set of managed objects which
attempts to match the set defined in IEEE 802.1D and IEEE 802.1Q.
However, to be consistent with the spirit of the SNMP Framework, a
subjective judgement was made to omit the objects from those载人旅行箱
standards most ’costly’ to implement in an agent and least
’essential’ for fault and configuration management. The omissions
are described in section 3 below.
Bell, et al. Standards Track [Page 4]
Historical note:
The original bridge MIB [BRIDGEMIB] used the following principles for determining inclusion of an object in the BRIDGE-MIB module:
(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. Structure of MIBs
This document defines additional objects, on top of those existing in the original BRIDGE-MIB module defined in [BRIDGEMIB]: that MIB
module is to be maintained unchanged for backwards compatibility.
Section 3.4.3 of the present document contains some recommendations
regarding usage of objects in the original bridge MIB by devices
implementing the enhancements defined here.
Two MIB modules are defined here:
(1) Managed objects for an extended bridge MIB module P-BRIDGE-MIB for the traffic class and multicast filtering enhancements
defined by IEEE 802.1D-1998 [802.1D].
(2) Managed objects for a virtual bridge MIB module Q-BRIDGE-MIB
for the Virtual LAN bridging enhancements defined by IEEE
802.1Q-1998 [802.1Q].
3.1. Structure of Extended Bridge MIB module
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.
Bell, et al. Standards Track [Page 5]
3.1.1. Relationship to IEEE 802.1D-1998 Manageable Objects
This section contains a cross-reference to the objects defined in
IEEE 802.1D-1998 [802.1D]. It also details those objects that are
not considered necessary in this MIB module.
Some objects defined by IEEE 802.1D-1998 have been included in the
virtual bridge MIB module rather than this one: entries in
dot1qTpGroupTable, dot1qForwardAllTable and
dot1qForwardUnregisteredTable are required for virtual bridged LANs
with additional indexing (e.g. per-VLAN, per-FDB) and so are not
defined here. Instead, devices which do not implement virtual
bridged LANs but do implement the Extended Forwarding Services
defined by IEEE 802.1D (i.e. dynamic learning of multicast group
addresses and group service requirements in the filtering database)
should implement these tables with a fixed value for dot1qFdbId (the value 1 is recommended) or dot1qVlanIndex (the value 1 is
recommended). Devices which support Extended Filtering Services
should support dot1qTpGroupTable, dot1qForwardAllTable and
dot1qForwardUnregisteredTable.
Bell, et al. Standards Track [Page 6]
豫公网安备41160202000603
站长QQ:729038198
关于我们
投诉建议