draft-ietf-bridge-ext-v2-02.txt   draft-ietf-bridge-ext-v2-03.txt 
Internet Draft V. Ngai
Internet Draft Editor of this version: Expires April 2005 Enterasys Networks
Expires August 2004 V. Ngai draft-ietf-bridge-ext-v2-03.txt L. Bell
draft-ietf-bridge-ext-v2-02.txt Enterasys Networks
Authors of previous version:
E. Bell
3Com Corp. 3Com Corp.
A. Smith October 2004
Beijing Harbour Networks
P. Langille
Newbridge Networks
A. Rijhsinghani
Enterasys Networks
K. McCloghrie
Cisco Systems
March 2004
Definitions of Managed Objects for Bridges with Traffic Definitions of Managed Objects for Bridges with Traffic
Classes, Multicast Filtering and Virtual LAN Extensions Classes, Multicast Filtering and Virtual LAN Extensions
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions By submitting this Internet-Draft, I certify that any applicable
of Section 10 of RFC2026. Internet-Drafts are working documents of patent or other IPR claims of which I am aware have been disclosed,
the Internet Engineering Task Force (IETF), its areas, and its or will be disclosed, and any of which I become aware will be
working groups. Note that other groups may also distribute working disclosed, in accordance with RFC 3668.
documents as Internet-Drafts.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 15, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract Abstract
This memo defines a portion of the Management Information Base (MIB) This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in TCP/IP based internets. for use with network management protocols in TCP/IP based internets.
In particular, it defines two MIB modules for managing the new In particular, it defines two MIB modules for managing the new
capabilities of MAC bridges defined by the IEEE 802.1D-1998 MAC capabilities of MAC bridges defined by the IEEE 802.1D-1998 MAC
Bridges and the IEEE 802.1Q-1998 Virtual LAN (VLAN) standards for Bridges and the IEEE 802.1Q-2003 Virtual LAN (VLAN) standards for
bridging between Local Area Network (LAN) segments. One MIB module bridging between Local Area Network (LAN) segments. One MIB module
defines objects for managing the 'Traffic Classes' and 'Enhanced defines objects for managing the 'Traffic Classes' and 'Enhanced
Multicast Filtering' components of IEEE 802.1D-1998 and P802.1t-2001. Multicast Filtering' components of IEEE 802.1D-1998 and P802.1t-2001.
The other MIB module defines objects for managing VLANs, as specified The other MIB module defines objects for managing VLANs, as specified
in IEEE 802.1Q-1998, P802.1u and P802.1v. in IEEE 802.1Q-2003, P802.1u and P802.1v.
Provisions are made for support of transparent bridging. Provisions Provisions are made for support of transparent bridging. Provisions
are also made so that these objects apply to bridges connected by are also made so that these objects apply to bridges connected by
subnetworks other than LAN segments. This memo also includes several subnetworks other than LAN segments. This memo also includes several
MIB modules in a manner that is compliant to the SMIv2 [V2SMI]. MIB modules in a manner that is compliant to the SMIv2 [RFC2578].
This memo supplements RFC 1493 [BRIDGEMIB] and (to a lesser extent) This memo supplements RFC 1493 [RFC1493] and (to a lesser extent) RFC
RFC 1525 [SBRIDGEMIB]. 1525 [RFC1525].
Table of Contents Table of Contents
1 The SNMP Management Framework ................................... 3 1. The Internet-Standard Management Framework
2 Overview ........................................................ 4
2.1 Scope ......................................................... 5
3 Structure of MIBs ............................................... 5
3.1 Structure of Extended Bridge MIB module ....................... 6
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 ..................................... 8
3.1.5 The dot1dGarp Group ......................................... 8
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 ...........................................14
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 .......................................17
3.4.3.2 The dot1dStp Group ........................................17
3.4.3.3 The dot1dTp Group .........................................17
3.4.3.4 The dot1dStatic Group .....................................18
3.4.3.5 Additions to the Original Bridge MIB ......................18
4 Definitions for Extended Bridge MIB .............................19
5 Definitions for Virtual Bridge MIB ..............................38
6 Acknowledgments .................................................81
7 Security Considerations .........................................81
8 References ......................................................82
9 Authors' Addresses ..............................................85
10 Intellectual Property ..........................................87
11 Full Copyright Statement .......................................88
1. The SNMP Management Framework
The SNMP Management Framework presently consists of five major
components:
o An overall architecture, described in RFC 2571 [RFC2571].
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 [RFC1155], STD 16, RFC 1212 [RFC1212] and RFC
1215 [RFC1215]. The second version, called SMIv2, is described
in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and
STD 58, RFC 2580 [RFC2580].
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 [RFC1157]. A second version of
the SNMP message protocol, which is not an Internet standards
track protocol, is called SNMPv2c and described in RFC 1901
[RFC1901] and RFC 1906 [RFC1906]. The third version of the
message protocol is called SNMPv3 and described in RFC 1906
[RFC1906], RFC 2572 [RFC2572] and RFC 2574 [RFC2574].
o Protocol operations for accessing management information. The
first set of protocol operations and associated PDU formats is
described in STD 15, RFC 1157 [RFC1157]. A second set of
protocol operations and associated PDU formats is described in
RFC 1905 [RFC1905].
o A set of fundamental applications described in RFC 2573
[RFC2573] and the view-based access control mechanism described
in RFC 2575 [RFC2575].
A more detailed introduction to the current SNMP Management Framework For a detailed overview of the documents that describe the current
can be found in RFC 2570 [RFC2570]. Internet-Standard Management Framework, please refer to section 7 of
RFC 3410 [RFC3410].
Managed objects are accessed via a virtual information store, termed Managed objects are accessed via a virtual information store, termed
the Management Information Base or MIB. Objects in the MIB are the Management Information Base or MIB. MIB objects are generally
defined using the mechanisms defined in the SMI. accessed through the Simple Network Management Protocol (SNMP).
Objects in the MIB are defined using the mechanisms defined in the
This memo specifies a MIB module that is compliant to the SMIv2. A Structure of Management Information (SMI). This memo specifies a MIB
MIB conforming to the SMIv1 can be produced through the appropriate module that is compliant to the SMIv2, which is described in STD 58,
translations. The resulting translated MIB must be semantically RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580
equivalent, except where objects or events are omitted because no [RFC2580].
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.
2. Overview 2. Overview
A common device present in many networks is the Bridge. This device A common device present in many networks is the Bridge. This device
is used to connect Local Area Network segments below the network is used to connect Local Area Network segments below the network
layer. These devices are often known as 'layer 2 switches'. layer. These devices are often known as 'layer 2 switches'.
There are two major modes defined for this bridging: Source-Route and There are two major modes defined for this bridging: Source-Route and
transparent. Source-Route bridging is described by IEEE 802.5 transparent. Source-Route bridging is described by IEEE 802.5
[802.5]. and is not discussed further in this document. [802.5], and is not discussed further in this document.
The transparent method of bridging is defined by IEEE 802.1D-1998 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] which is an update to the original IEEE 802.1D specification
[802.1D-ORIG]. Managed objects for that original specification of [802.1D-ORIG]. Managed objects for that original specification of
transparent bridging were defined in RFC 1493 [BRIDGEMIB]. transparent bridging were defined in RFC 1493 [RFC1493].
The original IEEE 802.1D is augmented by IEEE 802.1Q-1998 [802.1Q] to The original IEEE 802.1D is augmented by IEEE 802.1Q-2003 [802.1Q] to
provide support for 'virtual bridged LANs' where a single bridged provide support for 'virtual bridged LANs' where a single bridged
physical LAN network may be used to support multiple logical bridged physical LAN network may be used to support multiple logical bridged
LANs, each of which offers a service approximately the same as that LANs, each of which offers a service approximately the same as that
defined by IEEE 802.1D. Such virtual LANs (VLANs) are an integral 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 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 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 were on a single LAN. IEEE 802.1Q defines port-based Virtual LANs
where membership is determined by the bridge port on which data where membership is determined by the bridge port on which data
frames are received. This memo defines the objects needed for the frames are received. This memo defines the objects needed for the
management of port-based VLANs in bridge entities. management of port-based VLANs in bridge entities.
This memo defines those objects needed for the management of a This memo defines those objects needed for the management of a
bridging entity operating in the transparent mode, as well as some bridging entity operating in the transparent mode, as well as some
objects applicable to all types of bridges. Managed objects for objects applicable to all types of bridges. Managed objects for
Source-Route bridging are defined in RFC 1525 [SRBRIDGEMIB]. Source-Route bridging are defined in RFC 1525 [RFC1525].
2.1. Scope 2.1. Scope
This MIB includes a comprehensive set of managed objects which This MIB includes a comprehensive set of managed objects which
attempts to match the set defined in IEEE 802.1D and IEEE 802.1Q. 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 However, to be consistent with the spirit of the SNMP Framework, a
subjective judgement was made to omit the objects from those subjective judgement was made to omit the objects from those
standards most 'costly' to implement in an agent and least are standards most 'costly' to implement in an agent and least
described in section 3 below. 'essential' for fault and configuration management. The omissions
are described in section 3 below.
Historical note: Historical note:
The original bridge MIB [BRIDGEMIB] used the following principles for The original bridge MIB [RFC1493] used the following principles for
determining inclusion of an object in the BRIDGE-MIB module: determining inclusion of an object in the BRIDGE-MIB module:
(1) Start with a small set of essential objects and add only as (1) Start with a small set of essential objects and add only as
further objects are needed. further objects are needed.
(2) Require objects be essential for either fault or configuration (2) Require objects be essential for either fault or configuration
management. management.
(3) Consider evidence of current use and/or utility. (3) Consider evidence of current use and/or utility.
skipping to change at page 5, line 44 skipping to change at page 5, line 42
(5) Exclude objects which are simply derivable from others in this (5) Exclude objects which are simply derivable from others in this
or other MIBs. or other MIBs.
(6) Avoid causing critical sections to be heavily instrumented. (6) Avoid causing critical sections to be heavily instrumented.
The guideline that was followed is one counter per critical The guideline that was followed is one counter per critical
section per layer. section per layer.
3. Structure of MIBs 3. Structure of MIBs
This document defines additional objects, on top of those existing in This document defines additional objects, on top of those existing in
the original BRIDGE-MIB module defined in [BRIDGEMIB]: that MIB the original BRIDGE-MIB module defined in [RFC1493]: that MIB module
module is to be maintained unchanged for backwards compatibility. is to be maintained unchanged for backwards compatibility. Section
Section 3.4.3 of the present document contains some recommendations 3.4.3 of the present document contains some recommendations regarding
regarding usage of objects in the original bridge MIB by devices usage of objects in the original bridge MIB by devices implementing
implementing the enhancements defined here. the enhancements defined here.
Two MIB modules are defined here: Two MIB modules are defined here:
(1) Managed objects for an extended bridge MIB module P-BRIDGE-MIB (1) Managed objects for an extended bridge MIB module P-BRIDGE-MIB
for the traffic class and multicast filtering enhancements for the traffic class and multicast filtering enhancements
defined by IEEE 802.1D-1998 [802.1D], including the Restricted defined by IEEE 802.1D-1998 [802.1D], including the Restricted
Group Registration control defined by IEEE P802.1t [802.1t]. Group Registration control defined by IEEE P802.1t [802.1t].
(2) Managed objects for a virtual bridge MIB module Q-BRIDGE-MIB (2) Managed objects for a virtual bridge MIB module Q-BRIDGE-MIB
for the Virtual LAN bridging enhancements defined by IEEE for the Virtual LAN bridging enhancements defined by IEEE
802.1Q-1998 [802.1Q], including the Restricted VLAN 802.1Q-2003 [802.1Q], including the Restricted VLAN
Registration control defined by IEEE P802.1u [802.1u] and the Registration control defined by IEEE P802.1u [802.1u] and the
VLAN Classification by Protocol and Port enhancement defined by VLAN Classification by Protocol and Port enhancement defined by
IEEE P802.1v [802.1v]. IEEE P802.1v [802.1v].
3.1. Structure of Extended Bridge MIB module 3.1. Structure of Extended Bridge MIB module
Objects in this MIB are arranged into groups. Each group is Objects in this MIB are arranged into groups. Each group is
organized as a set of related objects. The overall structure and organized as a set of related objects. The overall structure and
assignment of objects to their groups is shown below. assignment of objects to their groups is shown below.
skipping to change at page 8, line 11 skipping to change at page 8, line 20
(e.g. per-VLAN, per-Group). (e.g. per-VLAN, per-Group).
Only per-{device,port,application} Only per-{device,port,application}
control is provided in this MIB. control is provided in this MIB.
notify group registration failure not considered useful notify group registration failure not considered useful
(IEEE 802.1t 14.10.1.2) (IEEE 802.1t 14.10.1.2)
3.1.2. Relationship to IEEE 802.1Q Manageable Objects 3.1.2. Relationship to IEEE 802.1Q Manageable Objects
This section contains section number cross-references to manageable This section contains section number cross-references to manageable
objects defined in IEEE 802.1Q-1998 [802.1Q]. These objects have objects defined in IEEE 802.1Q-2003 [802.1Q]. These objects have
been included in this MIB as they provide a natural fit with the IEEE been included in this MIB as they provide a natural fit with the IEEE
802.1D objects with which they are co-located. 802.1D objects with which they are co-located.
Extended Bridge MIB Name IEEE 802.1Q-1998 Section and Name Extended Bridge MIB Name IEEE 802.1Q-2003 Section and Name
dot1dExtBase Bridge dot1dExtBase Bridge
dot1dDeviceCapabilities dot1dDeviceCapabilities
dot1qStaticEntryIndividualPort 5.2 implementation options dot1qStaticEntryIndividualPort 5.2 implementation options
dot1qIVLCapable dot1qIVLCapable
dot1qSVLCapable dot1qSVLCapable
dot1qHybridCapable dot1qHybridCapable
dot1qConfigurablePvidTagging 12.10.1.1 read bridge vlan dot1qConfigurablePvidTagging 12.10.1.1 read bridge vlan
config config
dot1dLocalVlanCapable dot1dLocalVlanCapable
skipping to change at page 9, line 13 skipping to change at page 9, line 26
operation of the Generic Attribute Registration Protocol (GARP). operation of the Generic Attribute Registration Protocol (GARP).
3.1.6. The dot1dGmrp Group 3.1.6. The dot1dGmrp Group
This group contains the objects for configuring and reporting on This group contains the objects for configuring and reporting on
operation of the GARP Multicast Registration Protocol (GMRP). operation of the GARP Multicast Registration Protocol (GMRP).
3.1.7. The dot1dTpHCPortTable 3.1.7. The dot1dTpHCPortTable
This table extends the dot1dTp group from the original bridge MIB This table extends the dot1dTp group from the original bridge MIB
[BRIDGEMIB] and contains the objects for reporting port bridging [RFC1493] and contains the objects for reporting port bridging
statistics for high capacity network interfaces. statistics for high capacity network interfaces.
3.1.8. The dot1dTpPortOverflowTable 3.1.8. The dot1dTpPortOverflowTable
This table extends the dot1dTp group from the original bridge MIB This table ex
[BRIDGEMIB] and contains the objects for reporting the upper bits of tends the dot1dTp group from the original bridge MIB
[RFC1493] and contains the objects for reporting the upper bits of
port bridging statistics for high capacity network interfaces for port bridging statistics for high capacity network interfaces for
when 32-bit counters are inadequate. when 32-bit counters are inadequate.
3.2. Structure of Virtual Bridge MIB module 3.2. Structure of Virtual Bridge MIB module
Objects in this MIB are arranged into groups. Each group is Objects in this MIB are arranged into groups. Each group is
organized as a set of related objects. The overall structure and organized as a set of related objects. The overall structure and
assignment of objects to their groups is shown below. Some assignment of objects to their groups is shown below. Some
manageable objects defined in the original bridge MIB [BRIDGEMIB] manageable objects defined in the original bridge MIB [RFC1493] need
need to be indexed differently when they are used in a VLAN bridging to be indexed differently when they are used in a VLAN bridging
environment: these objects are, therefore, effectively duplicated by environment: these objects are, therefore, effectively duplicated by
new objects with different indexing which are defined in the Virtual new objects with different indexing which are defined in the Virtual
Bridge MIB. Bridge MIB.
3.2.1. Relationship to IEEE 802.1Q Manageable Objects 3.2.1. Relationship to IEEE 802.1Q Manageable Objects
This section contains section-number cross-references to manageable This section contains section-number cross-references to manageable
objects defined in clause 12 of IEEE 802.1Q-1998 [802.1Q]. It also objects defined in clause 12 of IEEE 802.1Q-2003 [802.1Q]. It also
details those objects that are not considered necessary in this MIB details those objects that are not considered necessary in this MIB
module. module.
Note: unlike IEEE 802.1D-1998, IEEE 802.1Q-1998 [802.1Q] did not Note: unlike IEEE 802.1D-1998, IEEE 802.1Q-2003 [802.1Q] did not
define exact syntax for a set of managed objects: the following define exact syntax for a set of managed objects: the following
cross-references indicate the section numbering of the descriptions cross-references indicate the section numbering of the descriptions
of management operations from clause 12 in the latter document. of management operations from clause 12 in the latter document.
Virtual Bridge MIB object IEEE 802.1Q-1998 Reference Virtual Bridge MIB object IEEE 802.1Q-2003 Reference
dot1qBase dot1qBase
dot1qVlanVersionNumber 12.10.1.1 read bridge vlan config dot1qVlanVersionNumber 12.10.1.1 read bridge vlan config
dot1qMaxVlanId 12.10.1.1 read bridge vlan config dot1qMaxVlanId 12.10.1.1 read bridge vlan config
dot1qMaxSupportedVlans 12.10.1.1 read bridge vlan config dot1qMaxSupportedVlans 12.10.1.1 read bridge vlan config
dot1qNumVlans dot1qNumVlans
dot1qGvrpStatus 12.9.2.1/2 read/set garp dot1qGvrpStatus 12.9.2.1/2 read/set garp
applicant controls applicant controls
dot1qTp dot1qTp
dot1qFdbTable dot1qFdbTable
skipping to change at page 12, line 33 skipping to change at page 13, line 5
dot1vProtocolGroupId 8.6.3 Protocol Group Identifier dot1vProtocolGroupId 8.6.3 Protocol Group Identifier
dot1vProtocolGroupRowStatus dot1vProtocolGroupRowStatus
dot1vProtocolPortTable 8.4.4 VID Set for each Port dot1vProtocolPortTable 8.4.4 VID Set for each Port
dot1vProtocolPortGroupId dot1vProtocolPortGroupId
dot1vProtocolGroupVid dot1vProtocolGroupVid
dot1vProtocolPortRowStatus dot1vProtocolPortRowStatus
The following IEEE 802.1Q management objects have not been included The following IEEE 802.1Q management objects have not been included
in the Bridge MIB for the indicated reasons. in the Bridge MIB for the indicated reasons.
IEEE 802.1Q-1998 Operation Disposition IEEE 802.1Q-2003 Operation Disposition
reset bridge (12.4.1.4) not considered useful reset bridge (12.4.1.4) not considered useful
reset vlan bridge (12.10.1.5) not considered useful reset vlan bridge (12.10.1.5) not considered useful
read forwarding port counters (12.6.1.1) read forwarding port counters (12.6.1.1)
discard on error details not considered useful discard on error details not considered useful
read permanent database (12.7.6.1) read permanent database (12.7.6.1)
permanent database size not considered useful permanent database size not considered useful
number of static filtering count rows in number of static filtering count rows in
entries dot1qStaticUnicastTable + entries dot1qStaticUnicastTable +
dot1qStaticMulticastTable dot1qStaticMulticastTable
number of static VLAN count rows in number of static VLAN count rows in
registration entries dot1qVlanStaticTable registration entries dot1qVlanStaticTable
read filtering entry range use GetNext operation. read filtering entry range use GetNext operation.
(12.7.7.4) (12.7.7.4)
read filtering database (12.7.1.1) read filtering database (12.7.1.1)
skipping to change at page 14, line 16 skipping to change at page 14, line 33
The datatypes MacAddress, BridgeId, Timeout, EnabledStatus, PortList, The datatypes MacAddress, BridgeId, Timeout, EnabledStatus, PortList,
VlanIndex and VlanId are used as textual conventions in this VlanIndex and VlanId are used as textual conventions in this
document. These textual conventions have NO effect on either the document. These textual conventions have NO effect on either the
syntax nor the semantics of any managed object. Objects defined syntax nor the semantics of any managed object. Objects defined
using these conventions are always encoded by means of the rules that using these conventions are always encoded by means of the rules that
define their primitive type. Hence, no changes to the SMI or the define their primitive type. Hence, no changes to the SMI or the
SNMP are necessary to accommodate these textual conventions which are SNMP are necessary to accommodate these textual conventions which are
adopted merely for the convenience of readers. adopted merely for the convenience of readers.
Various Working Groups have defined standards-track MIB documents
(for example [RFC2613] and [RFC3318]), that contain objects and
Textual Conventions to represent a Virtual Local Area Network
Identifier (VLAN-ID) [802.1Q]. New definitions are showing up in
various Internet-Drafts (for example [I-D.ietf-ipcdn-qos-mib], [I-
D.ietf-rmonmib-sspm-mib]). Unfortunately the result is a set of
different definitions for the same piece of management information.
This may lead to confusion and unnecessary complexity. In order to
address this situation, three new textual conventions are defined in
the Q-BRIDGE-MIB, called VlanIdOrAny, VlanIdOrNone, and
VlanIdOrAnyOrNone. These new textual conventions should be (re-)used
in MIB modules, so that they all represent a VLAN-ID in the same way.
In fact, PIB modules can and should also use these TCs when then need
to represent a VLAN-ID.
These textual conventions provide a means to specify MIB objects that
refer to either a specific VLAN, to any VLAN, or to no VLAN. For an
example of how these textual conventions might be used, consider a
MIB object, with SYNTAX of VlanIdOrAnyOrNone, that specifies the VLAN
on which to accept incoming packets of a particular protocol. Such
an object would allow the device to be configured to accept packets
of this protocol received with a specific 802.1q tag value, with any
802.1q tag value, or with no 802.1q tag. Note that a MIB object that
is defined using one of these textual conventions should clarify the
meaning of 'any VLAN' and/or 'no VLAN' in its DESCRIPTION clause.
3.4. Relationship to Other MIBs 3.4. Relationship to Other MIBs
As described above, some IEEE 802.1D management objects have not been As described above, some IEEE 802.1D management objects have not been
included in this MIB because they overlap with objects in other MIBs included in this MIB because they overlap with objects in other MIBs
applicable to a bridge implementing this MIB. In particular, it is applicable to a bridge implementing this MIB. In particular, it is
assumed that a bridge implementing this MIB will also implement (at assumed that a bridge implementing this MIB will also implement (at
least) the 'system' group defined in MIB-II [MIB2], the 'interfaces' least) the 'system' group defined in MIB-II [RFC1213], the
group defined in [INTERFACEMIB] and the original bridge MIB 'interfaces' group defined in [RFC2863] and the original bridge MIB
[BRIDGEMIB]. [RFC1493].
3.4.1. Relationship to the 'system' group 3.4.1. Relationship to the 'system' group
In MIB-II, the 'system' group is defined as being mandatory for all In MIB-II, the 'system' group is defined as being mandatory for all
systems such that each managed entity contains one instance of each systems such that each managed entity contains one instance of each
object in the 'system' group. Thus, those objects apply to the object in the 'system' group. Thus, those objects apply to the
entity as a whole irrespective of whether the entity's sole entity as a whole irrespective of whether the entity's sole
functionality is bridging, or whether bridging is only a subset of functionality is bridging, or whether bridging is only a subset of
the entity's functionality. the entity's functionality.
3.4.2. Relation to Interfaces MIB 3.4.2. Relation to Interfaces MIB
The Interfaces Group MIB [INTERFACEMIB], requires that any MIB which The Interfaces Group MIB [RFC2863], requires that any MIB which is an
is an adjunct of the Interfaces Group MIB, clarify specific areas adjunct of the Interfaces Group MIB, clarify specific areas within
within the Interfaces Group MIB. These areas were intentionally left the Interfaces Group MIB. These areas were intentionally left vague
vague in the Interfaces Group MIB to avoid over-constraining the MIB, in the Interfaces Group MIB to avoid over-constraining the MIB,
thereby precluding management of certain media-types. thereby precluding management of certain media-types.
The Interfaces Group MIB enumerates several areas which a media- The Interfaces Group MIB enumerates several areas which a media-
specific MIB must clarify. Each of these areas is addressed in a specific MIB must clarify. Each of these areas is addressed in a
following subsection. The implementor is referred to the Interfaces following subsection. The implementor is referred to the Interfaces
Group MIB in order to understand the general intent of these areas. Group MIB in order to understand the general intent of these areas.
In the Interfaces Group MIB, the 'interfaces' group is defined as In the Interfaces Group MIB, the 'interfaces' group is defined as
being mandatory for all systems and contains information on an being mandatory for all systems and contains information on an
entity's interfaces, where each interface is thought of as being entity's interfaces, where each interface is thought of as being
skipping to change at page 15, line 26 skipping to change at page 16, line 30
all on the same interface. all on the same interface.
Each port is uniquely identified by a port number. A port number has Each port is uniquely identified by a port number. A port number has
no mandatory relationship to an interface number, but in the simple no mandatory relationship to an interface number, but in the simple
case a port number will have the same value as the corresponding case a port number will have the same value as the corresponding
interface's interface number. Port numbers are in the range interface's interface number. Port numbers are in the range
(1..dot1dBaseNumPorts). (1..dot1dBaseNumPorts).
Some entities perform other functionality as well as bridging through Some entities perform other functionality as well as bridging through
the sending and receiving of data on their interfaces. In such the sending and receiving of data on their interfaces. In such
situations, only a subset of the data sent/received on an interface situations, only a subset of the data sent/recei
ved on an interface
is within the domain of the entity's bridging functionality. This is within the domain of the entity's bridging functionality. This
subset is considered to be delineated according to a set of subset is considered to be delineated according to a set of
protocols, with some protocols being bridged, and other protocols not protocols, with some protocols being bridged, and other protocols not
being bridged. For example, in an entity which exclusively performed being bridged. For example, in an entity which exclusively performed
bridging, all protocols would be considered as being bridged, whereas bridging, all protocols would be considered as being bridged, whereas
in an entity which performed IP routing on IP datagrams and only in an entity which performed IP routing on IP datagrams and only
bridged other protocols, only the non-IP data would be considered as bridged other protocols, only the non-IP data would be considered as
being bridged. Thus, this Extended Bridge MIB (and in particular, being bridged. Thus, this Extended Bridge MIB (and in particular,
its counters) is applicable only to that subset of the data on an its counters) is applicable only to that subset of the data on an
entity's interfaces which is sent/received for a protocol being entity's interfaces which is sent/received for a protocol being
bridged. All such data is sent/received via the ports of the bridge. bridged. All such data is sent/received via the ports of the bridge.
3.4.2.1. Layering Model 3.4.2.1. Layering Model
This memo assumes the interpretation of the Interfaces Group to be in This memo assumes the interpretation of the Interfaces Group to be in
accordance with the Interfaces Group MIB [INTERFACEMIB] which states accordance with the Interfaces Group MIB [RFC2863] which states that
that the interfaces table (ifTable) contains information on the the interfaces table (ifTable) contains information on the managed
managed resource's interfaces and that each sub-layer below the resource's interfaces and that each sub-layer below the internetwork
internetwork layer of a network interface is considered an interface. layer of a network interface is considered an interface.
This document recommends that, within an entity, VLANs which are This document recommends that, within an entity, VLANs which are
instantiated as an entry in dot1qVlanCurrentTable by either instantiated as an entry in dot1qVlanCurrentTable by either
management configuration through dot1qVlanStaticTable or by dynamic management configuration through dot1qVlanStaticTable or by dynamic
means (e.g. through GVRP), are NOT also represented by an entry in means (e.g. through GVRP), are NOT also represented by an entry in
ifTable. ifTable.
Where an entity contains higher-layer protocol entities e.g. IP-layer Where an entity contains higher-layer protocol entities e.g. IP-layer
interfaces that transmit and receive traffic to/from a VLAN, these interfaces that transmit and receive traffic to/from a VLAN, these
should be represented in the ifTable as interfaces of type should be represented in the ifTable as interfaces of type
propVirtual(53). Protocol-specific types such as l3ipxvlan(137) propVirtual(53). Protocol-specific types such as l3ipxvlan(137)
should not be used here since there is no implication that the bridge should not be used here since there is no implication that the bridge
will perform any protocol filtering before delivering up to these will perform any protocol filtering before delivering up to these
virtual interfaces. virtual interfaces.
3.4.2.2. ifStackTable 3.4.2.2. ifStackTable
In addition, the Interfaces Group MIB [INTERFACEMIB] defines a table In addition, the Interfaces Group MIB [RFC2863] defines a table
'ifStackTable' for describing the relationship between logical
interfaces within an entity. It is anticipated that implementors
will use this table to describe the binding of e.g. IP interfaces to will use this table to describe the binding of e.g. IP interfaces to
physical ports, although the presence of VLANs makes the physical ports, although the presence of VLANs makes the
representation less than perfect for showing connectivity: the representation less than perfect for showing connectivity: the
ifStackTable cannot represent the full capability of the IEEE 802.1Q ifStackTable cannot represent the full capability of the IEEE 802.1Q
VLAN bridging standard since that makes a distinction between VLAN VLAN bridging standard since that makes a distinction between VLAN
bindings on 'ingress' to and 'egress' from a port: these bindings on 'ingress' to and 'egress' from a port: these
relationships may or may not be symmetrical whereas Interface MIB relationships may or may not be symmetrical whereas Interface MIB
Evolution assumes a symmetrical binding for transmit and receive. Evolution assumes a symmetrical binding for transmit and receive.
This makes it necessary to define other manageable objects for This makes it necessary to define other manageable objects for
configuring which ports are members of which VLANs. configuring which ports are members of which VLANs.
skipping to change at page 16, line 44 skipping to change at page 18, line 9
contained in ifRcvAddressAddress, is the same as for ifPhysAddress. contained in ifRcvAddressAddress, is the same as for ifPhysAddress.
This table does not include unicast or multicast addresses which are This table does not include unicast or multicast addresses which are
accepted for possible forwarding out some other port. This table is accepted for possible forwarding out some other port. This table is
explicitly not intended to provide a bridge address filtering explicitly not intended to provide a bridge address filtering
mechanism. mechanism.
3.4.3. Relation to Original Bridge MIB 3.4.3. Relation to Original Bridge MIB
This section defines how objects in the original bridge MIB module This section defines how objects in the original bridge MIB module
[BRIDGEMIB] should be represented for devices which implement the [RFC1493] should be represented for devices which implement the
extensions: some of the old objects are less useful in such devices extensions: some of the old objects are less useful in such devices
but must still be implemented for reasons of backwards compatibility. but must still be implemented for reasons of backwards compatibility.
Note that formal conformance statements for that MIB module do not Note that formal conformance statements for that MIB module do not
exist since it is defined in SMIv1. exist since it is defined in SMIv1.
3.4.3.1. The dot1dBase Group 3.4.3.1. The dot1dBase Group
This mandatory group contains the objects which are applicable to all This mandatory group contains the objects which are applicable to all
types of bridges. Interpretation of this group is unchanged. types of bridges. Interpretation of this group is unchanged.
skipping to change at page 18, line 29 skipping to change at page 19, line 46
of the Filtering Databases. Entries for the same MAC address of the Filtering Databases. Entries for the same MAC address
and receive port in more than one Filtering Database must appear and receive port in more than one Filtering Database must appear
only once since these are the indices of this table. This table only once since these are the indices of this table. This table
should be implemented as read-only in devices that support should be implemented as read-only in devices that support
multiple Forwarding Databases - instead, write access should be multiple Forwarding Databases - instead, write access should be
provided through dot1qStaticUnicastTable and provided through dot1qStaticUnicastTable and
dot1qStaticMulticastTable, as defined in this document. dot1qStaticMulticastTable, as defined in this document.
3.4.3.5. Additions to the Original Bridge MIB 3.4.3.5. Additions to the Original Bridge MIB
In addition to the objects in the original bridge MIB [BRIDGEMIB], In addition to the objects in the original bridge MIB [RFC1493], this
this document contains: document contains:
(1) support for multiple traffic classes and dynamic multicast (1) support for multiple traffic classes and dynamic multicast
filtering as per IEEE 802.1D-1998 [802.1D]. filtering as per IEEE 802.1D-1998 [802.1D].
(2) support for bridged Virtual LANs as per IEEE 802.1Q-1998 (2) support for bridged Virtual LANs as per IEEE 802.1Q-2003
[802.1Q]. [802.1Q].
(3) support for 64-bit versions of original bridge MIB [BRIDGEMIB] (3) support for 64-bit versions of original bridge MIB [RFC1493]
port counters. port counters.
4. Definitions for Extended Bridge MIB 4. Definitions for Extended Bridge MIB
P-BRIDGE-MIB DEFINITIONS ::= BEGIN P-BRIDGE-MIB DEFINITIONS ::=
BEGIN
-- ------------------------------------------------------------- -- -------------------------------------------------------------
-- MIB for IEEE 802.1p devices -- MIB for IEEE 802.1p devices
-- ------------------------------------------------------------- -- -------------------------------------------------------------
IMPORTS IMPORTS
MODULE-IDENTITY, OBJECT-TYPE, Counter32, Counter64 MODULE-IDENTITY, OBJECT-TYPE, Counter32, Counter64
FROM SNMPv2-SMI FROM SNMPv2-SMI
TruthValue, TimeInterval, MacAddress, TEXTUAL-CONVENTION TruthValue, TimeInterval, MacAddress, TEXTUAL-CONVENTION
FROM SNMPv2-TC FROM SNMPv2-TC
skipping to change at page 23, line 4 skipping to change at page 25, line 12
REFERENCE REFERENCE
"ISO/IEC 15802-3 Section 5.2, "ISO/IEC 15802-3 Section 5.2,
IEEE 802.1Q/D11 Section 5.2" IEEE 802.1Q/D11 Section 5.2"
::= { dot1dPortCapabilitiesEntry 1 } ::= { dot1dPortCapabilitiesEntry 1 }
-- ------------------------------------------------------------- -- -------------------------------------------------------------
-- the dot1dPriority group -- the dot1dPriority group
-- ------------------------------------------------------------- -- -------------------------------------------------------------
-- ------------------------------------------------------------- -- -------------------------------------------------------------
-- Port Priority Table -- Port Priority Table
-- ------------------------------------------------------------- -- -------------------------------------------------------------
dot1dPortPriorityTable OBJECT-TYPE dot1dPortPriorityT
able OBJECT-TYPE
SYNTAX SEQUENCE OF Dot1dPortPriorityEntry SYNTAX SEQUENCE OF Dot1dPortPriorityEntry
MAX-ACCESS not-accessible MAX-ACCESS not-accessible
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"A table that contains information about every port that "A table that contains information about every port that
is associated with this transparent bridge." is associated with this transparent bridge."
::= { dot1dPriority 1 } ::= { dot1dPriority 1 }
dot1dPortPriorityEntry OBJECT-TYPE dot1dPortPriorityEntry OBJECT-TYPE
SYNTAX Dot1dPortPriorityEntry SYNTAX Dot1dPortPriorityEntry
skipping to change at page 27, line 33 skipping to change at page 29, line 50
dot1dPortGarpTable OBJECT-TYPE dot1dPortGarpTable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot1dPortGarpEntry SYNTAX SEQUENCE OF Dot1dPortGarpEntry
MAX-ACCESS not-accessible MAX-ACCESS not-accessible
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"A table of GARP control information about every bridge "A table of GARP control information about every bridge
port. This is indexed by dot1dBasePort." port. This is indexed by dot1dBasePort."
::= { dot1dGarp 1 } ::= { dot1dGarp 1 }
Bell et. al Expires April 2005
dot1dPortGarpEntry OBJECT-TYPE dot1dPortGarpEntry OBJECT-TYPE
SYNTAX Dot1dPortGarpEntry SYNTAX Dot1dPortGarpEntry
MAX-ACCESS not-accessible MAX-ACCESS not-accessible
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"GARP control information for a bridge port." "GARP control information for a bridge port."
AUGMENTS { dot1dBasePortEntry } AUGMENTS { dot1dBasePortEntry }
::= { dot1dPortGarpTable 1 } ::= { dot1dPortGarpTable 1 }
Dot1dPortGarpEntry ::= Dot1dPortGarpEntry ::=
skipping to change at page 32, line 4 skipping to change at page 34, line 31
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"Count of valid frames that have been received by this "Count of valid frames that have been received by this
port from its segment which were discarded (i.e., port from its segment which were discarded (i.e.,
filtered) by the Forwarding Process." filtered) by the Forwarding Process."
REFERENCE REFERENCE
"ISO/IEC 15802-3 Section 14.6.1.1.3" "ISO/IEC 15802-3 Section 14.6.1.1.3"
::= { dot1dTpHCPortEntry 3 } ::= { dot1dTpHCPortEntry 3 }
-- ---------------------------------------------------- -- ----------------------------------------------------
-- Upper part of High Capacity Port Table for Transparent Bridges -- Upper part of High Capacity Port Table for Transparent Bridges
-- ---------------------------------------------------- -- ----------------------------------------------------
dot1dTpPortOverflowTable OBJECT-TYPE dot1dTpPortOverflowTable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot1dTpPortOverflowEntry SYNTAX SEQUENCE OF Dot1dTpPortOverflowEntry
MAX-ACCESS not-accessible MAX-
ACCESS not-accessible
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"A table that contains the most-significant bits of "A table that contains the most-significant bits of
statistics counters for ports that are associated with this statistics counters for ports that are associated with this
transparent bridge that are on high capacity interfaces, as transparent bridge that are on high capacity interfaces, as
defined in the conformance clauses for this table. This table defined in the conformance clauses for this table. This table
is provided as a way to read 64-bit counters for agents which is provided as a way to read 64-bit counters for agents which
support only SNMPv1. support only SNMPv1.
Note that the reporting of most-significant and Note that the reporting of most-significant and
skipping to change at page 37, line 27 skipping to change at page 40, line 18
GROUP pBridgePriorityGroup GROUP pBridgePriorityGroup
DESCRIPTION DESCRIPTION
"This group is mandatory only for devices supporting "This group is mandatory only for devices supporting
the priority forwarding operations defined by IEEE 802.1D." the priority forwarding operations defined by IEEE 802.1D."
GROUP pBridgeAccessPriorityGroup GROUP pBridgeAccessPriorityGroup
DESCRIPTION DESCRIPTION
"This group is optional and is relevant only for devices "This group is optional and is relevant only for devices
supporting the priority forwarding operations defined by supporting the priority forwarding operations defined by
IEEE 802.1D and which have interface media types that support IEEE 802.1D and which have interface media types that
native Access Priority e.g. IEEE 802.5." support native Access Priority e.g. IEEE 802.5."
GROUP pBridgePortGarpGroup GROUP pBridgePortGarpGroup
DESCRIPTION DESCRIPTION
"This group is mandatory for devices supporting any "This group is mandatory for devices supporting any
of the GARP applications: e.g. GMRP, defined by the of the GARP applications: e.g. GMRP, defined by the
extended filtering services of 802.1D; or GVRP, extended filtering services of 802.1D; or GVRP,
defined by 802.1Q (refer to the Q-BRIDGE-MIB for defined by 802.1Q (refer to the Q-BRIDGE-MIB for
conformance statements for GVRP)." conformance statements for GVRP)."
GROUP pBridgePortGmrpGroup GROUP pBridgePortGmrpGroup
skipping to change at page 39, line 14 skipping to change at page 42, line 10
TimeFilter TimeFilter
FROM RMON2-MIB; FROM RMON2-MIB;
qBridgeMIB MODULE-IDENTITY qBridgeMIB MODULE-IDENTITY
LAST-UPDATED "200209170000Z" LAST-UPDATED "200209170000Z"
ORGANIZATION "IETF Bridge MIB Working Group" ORGANIZATION "IETF Bridge MIB Working Group"
CONTACT-INFO CONTACT-INFO
"Email: Bridge-mib@ietf.org" "Email: Bridge-mib@ietf.org"
DESCRIPTION DESCRIPTION
"The VLAN Bridge MIB module for managing Virtual Bridged "The VLAN Bridge MIB module for managing Virtual Bridged
Local Area Networks, as defined by IEEE 802.1Q-1998, Local Area Networks, as defined by IEEE 802.1Q-2003,
including Restricted Vlan Registration defined by including Restricted Vlan Registration defined by
IEEE 802.1u-2001 and Vlan Classification defined by IEEE 802.1u-2001 and Vlan Classification defined by
IEEE 802.1v-2001." IEEE 802.1v-2001."
-- revision history -- revision history
REVISION "200209170000Z" REVISION "200209170000Z"
DESCRIPTION DESCRIPTION
"Draft 1 (RFC 2674 update)." "Draft 1 (RFC 2674 update)."
skipping to change at page 40, line 16 skipping to change at page 43, line 14
global scope within a given bridged domain (see VlanId global scope within a given bridged domain (see VlanId
textual convention). If the value is greater than 4095 textual convention). If the value is greater than 4095
then it represents a VLAN with scope local to the then it represents a VLAN with scope local to the
particular agent, i.e. one without a global VLAN-ID particular agent, i.e. one without a global VLAN-ID
assigned to it. Such VLANs are outside the scope of assigned to it. Such VLANs are outside the scope of
IEEE 802.1Q but it is convenient to be able to manage them IEEE 802.1Q but it is convenient to be able to manage them
in the same way using this MIB." in the same way using this MIB."
SYNTAX Unsigned32 SYNTAX Unsigned32
VlanId ::= TEXTUAL-CONVENTION VlanId ::= TEXTUAL-CONVENTION
DISPLAY-HINT "d"
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"A 12-bit VLAN ID used in the VLAN Tag header." "The VLAN ID that uniquely identifies a VLAN. This
is the 12-bit VLAN ID used in the VLAN Tag header.
The range is defined by the REFERENCEd specification."
REFERENCE
"IEEE Std 802.1Q 2003 Edition, Virtual Bridged
Local Area Networks."
SYNTAX INTEGER (1..4094) SYNTAX INTEGER (1..4094)
VlanIdOrAny ::= TEXTUAL-CONVENTION
DISPLAY-HINT "d"
STATUS current
DESCRIPTION
"The VLAN ID that uniquely identifies a specific VLAN,
or any VLAN. The special value of 4095 is used to
indicate a wildcard, i.e. any VLAN. This can be used
in any situation where an object or table entry must
refer either to a specific VLAN or to any VLAN."
SYNTAX Integer32 (1..4094 | 4095)
VlanIdOrNone ::= TEXTUAL-CONVENTION
DISPLAY-HINT "d"
STATUS current
DESCRIPTION
"The VLAN ID that uniquely identifies a specific VLAN,
or no VLAN. The special value of zero is used to
indicate that no VLAN ID is present or used. This can
be used in any situation where an object or a table entry
must refer either to a specific VLAN, or to no VLAN."
SYNTAX Integer32 (0 | 1..4094)
VlanIdOrAnyOrNone ::= TEXTUAL-CONVE
NTION
DISPLAY-HINT "d"
STATUS current
DESCRIPTION
"The VLAN ID that uniquely identifies a specific VLAN,
any VLAN, or no VLAN. The special values 0 and 4095
have the same meaning as described in the VlanIdOrAny
and VlanIdOrNone TEXTUAL-CONVENTIONs."
SYNTAX Integer32 (0 | 1..4094 | 4095)
-- ------------------------------------------------------------- -- -------------------------------------------------------------
-- groups in the Q-BRIDGE MIB -- groups in the Q-BRIDGE MIB
-- ------------------------------------------------------------- -- -------------------------------------------------------------
dot1qBase OBJECT IDENTIFIER ::= { qBridgeMIBObjects 1 } dot1qBase OBJECT IDENTIFIER ::= { qBridgeMIBObjects 1 }
dot1qTp OBJECT IDENTIFIER ::= { qBridgeMIBObjects 2 } dot1qTp OBJECT IDENTIFIER ::= { qBridgeMIBObjects 2 }
dot1qStatic OBJECT IDENTIFIER ::= { qBridgeMIBObjects 3 } dot1qStatic OBJECT IDENTIFIER ::= { qBridgeMIBObjects 3 }
dot1qVlan OBJECT IDENTIFIER ::= { qBridgeMIBObjects 4 } dot1qVlan OBJECT IDENTIFIER ::= { qBridgeMIBObjects 4 }
dot1vProtocol OBJECT IDENTIFIER ::= { qBridgeMIBObjects 5 } dot1vProtocol OBJECT IDENTIFIER ::= { qBridgeMIBObjects 5 }
skipping to change at page 48, line 34 skipping to change at page 52, line 40
for which the Service Requirement attribute Forward All for which the Service Requirement attribute Forward All
Multicast Groups may not be dynamically registered by Multicast Groups may not be dynamically registered by
GMRP. This value will be restored after the device is GMRP. This value will be restored after the device is
reset. A port may not be added in this set if it is reset. A port may not be added in this set if it is
already a member of the set of ports in already a member of the set of ports in
dot1qForwardAllStaticPorts. The default value is a dot1qForwardAllStaticPorts. The default value is a
string of zeros of appropriate length." string of zeros of appropriate length."
::= { dot1qForwardAllEntry 3 } ::= { dot1qForwardAllEntry 3 }
dot1qForwardUnregisteredTable OBJECT-TYPE dot1qForwardUnregisteredTable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot1qForwardUnregisteredEntry SYNTAX SEQUENCE OF Dot1qForwardUnregistered
Entry
MAX-ACCESS not-accessible MAX-ACCESS not-accessible
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"A table containing forwarding information for each "A table containing forwarding information for each
VLAN, specifying the set of ports to which forwarding of VLAN, specifying the set of ports to which forwarding of
multicast group-addressed frames for which there is no multicast group-addressed frames for which there is no
more specific forwarding information applies. This is more specific forwarding information applies. This is
configured statically by management and determined configured statically by management and determined
dynamically by GMRP. An entry appears in this table for dynamically by GMRP. An entry appears in this table for
all VLANs that are currently instantiated." all VLANs that are currently instantiated."
skipping to change at page 52, line 28 skipping to change at page 56, line 40
applies to ports that are members of the VLAN, defined applies to ports that are members of the VLAN, defined
by dot1qVlanCurrentEgressPorts. The default value of by dot1qVlanCurrentEgressPorts. The default value of
this object is a string of ones of appropriate length." this object is a string of ones of appropriate length."
REFERENCE REFERENCE
"IEEE 802.1Q/D11 Table 8-5, ISO/IEC 15802-3 Table 7-5" "IEEE 802.1Q/D11 Table 8-5, ISO/IEC 15802-3 Table 7-5"
::= { dot1qStaticUnicastEntry 3 } ::= { dot1qStaticUnicastEntry 3 }
dot1qStaticUnicastStatus OBJECT-TYPE dot1qStaticUnicastStatus OBJECT-TYPE
SYNTAX INTEGER { SYNTAX INTEGER {
other(1), other(1),
invalid(2), invalid(2
),
permanent(3), permanent(3),
deleteOnReset(4), deleteOnReset(4),
deleteOnTimeout(5) deleteOnTimeout(5)
} }
MAX-ACCESS read-write MAX-ACCESS read-write
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"This object indicates the status of this entry. "This object indicates the status of this entry.
other(1) - this entry is currently in use but other(1) - this entry is currently in use but
the conditions under which it will remain the conditions under which it will remain
skipping to change at page 56, line 20 skipping to change at page 60, line 40
MAX-ACCESS not-accessible MAX-ACCESS not-accessible
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"A table containing current configuration information "A table containing current configuration information
for each VLAN currently configured into the device by for each VLAN currently configured into the device by
(local or network) management, or dynamically created (local or network) management, or dynamically created
as a result of GVRP requests received." as a result of GVRP requests received."
::= { dot1qVlan 2 } ::= { dot1qVlan 2 }
dot1qVlanCurrentEntry OBJECT-TYPE dot1qVlanCurrentEntry OBJECT-TYPE
SYNTAX Dot1qVlanCurrentEntry SYNTAX Dot1qV
lanCurrentEntry
MAX-ACCESS not-accessible MAX-ACCESS not-accessible
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"Information for a VLAN configured into the device by "Information for a VLAN configured into the device by
(local or network) management, or dynamically created (local or network) management, or dynamically created
as a result of GVRP requests received." as a result of GVRP requests received."
INDEX { dot1qVlanTimeMark, dot1qVlanIndex } INDEX { dot1qVlanTimeMark, dot1qVlanIndex }
::= { dot1qVlanCurrentTable 1 } ::= { dot1qVlanCurrentTable 1 }
Dot1qVlanCurrentEntry ::= Dot1qVlanCurrentEntry ::=
skipping to change at page 68, line 43 skipping to change at page 73, line 43
its segment which were classified as belonging to this its segment which were classified as belonging to this
VLAN which were discarded due to VLAN related reasons. VLAN which were discarded due to VLAN related reasons.
Specifically, the IEEE 802.1Q counters for Discard Specifically, the IEEE 802.1Q counters for Discard
Inbound and Discard on Ingress Filtering." Inbound and Discard on Ingress Filtering."
REFERENCE REFERENCE
"IEEE 802.1Q/D11 Section 12.6.1.1.3" "IEEE 802.1Q/D11 Section 12.6.1.1.3"
::= { dot1qPortVlanHCStatisticsEntry 3 } ::= { dot1qPortVlanHCStatisticsEntry 3 }
-- ------------------------------------------------------------- -- -------------------------------------------------------------
-- The VLAN Learning Constraints Table -- The VLAN Learning Constraints Table
-- --------------------------------------------------------
-----
dot1qLearningConstraintsTable OBJECT-TYPE dot1qLearningConstraintsTable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot1qLearningConstraintsEntry SYNTAX SEQUENCE OF Dot1qLearningConstraintsEntry
MAX-ACCESS not-accessible MAX-ACCESS not-accessible
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"A table containing learning constraints for sets of "A table containing learning constraints for sets of
Shared and Independent VLANs." Shared and Independent VLANs."
REFERENCE REFERENCE
"IEEE 802.1Q/D11 Section 12.10.3.1" "IEEE 802.1Q/D11 Section 12.10.3.1"
skipping to change at page 78, line 16 skipping to change at page 83, line 35
::= { qBridgeGroups 12 } ::= { qBridgeGroups 12 }
qBridgeLearningConstraintDefaultGroup OBJECT-GROUP qBridgeLearningConstraintDefaultGroup OBJECT-GROUP
OBJECTS { OBJECTS {
dot1qConstraintSetDefault, dot1qConstraintSetDefault,
dot1qConstraintTypeDefault dot1qConstraintTypeDefault
} }
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"A collection of objects defining the default Filtering "A collection of objects defining the default Filtering
Database constraints for VLANs which have no specific Database constraints for VLANs which
have no specific
constraints defined." constraints defined."
::= { qBridgeGroups 13 } ::= { qBridgeGroups 13 }
qBridgeClassificationDeviceGroup OBJECT-GROUP qBridgeClassificationDeviceGroup OBJECT-GROUP
OBJECTS { OBJECTS {
dot1vProtocolGroupId, dot1vProtocolGroupId,
dot1vProtocolGroupRowStatus dot1vProtocolGroupRowStatus
} }
STATUS current STATUS current
DESCRIPTION DESCRIPTION
skipping to change at page 81, line 8 skipping to change at page 87, line 8
"Write access is not required as this is an optional "Write access is not required as this is an optional
capability in IEEE 802.1Q." capability in IEEE 802.1Q."
::= { qBridgeCompliances 1 } ::= { qBridgeCompliances 1 }
END END
6. Acknowledgments 6. Acknowledgments
This document expands upon previous work which resulted in the This document expands upon previous work which resulted in the
original bridge MIB [BRIDGEMIB]. original bridge MIB [RFC1493].
Much of the groundwork for this document was performed by the IEEE Much of the groundwork for this document was performed by the IEEE
802.1 working group during the definition of the IEEE 802.1D updates 802.1 working group during the definition of the IEEE 802.1D updates
[802.1D] and IEEE 802.1Q [802.1Q]. [802.1D] and IEEE 802.1Q [802.1Q].
The authors wish to thank the members of the Bridge Working Group and The authors wish to thank the members of the Bridge Working Group,
David Harrington and Anders SW Christensen in particular for their and David Harrington, Anders SW Christensen, Andrew Smith, Paul
comments and suggestions which improved this effort. Langille, Anil Rijhsinghani, and Keith McCloghrie in particular for
their comments and suggestions which improved this effort.
7. Security Considerations Editing for the final draft was done by David Levi.
The new textual conventions related to VLAN-IDs were produced as a
result of a review of the use of VLAN-ID in several MIB modules.
Further investigation found that VLAN-ID objects were defined in a
few other MIB modules. The editor would like to thank all who
contributed to the discussion which resulted in these new textual
conventions. Specifically Bert Wijnen, Les Bell, Andrew Smith, Mike
Heard, Randy Presuhn, Dan Romascanu, Eduardo Cardona, Tom Petch,
Juergen Schoenwaelder, Richard Woundy, Tony Jeffree and William
Murwin. We also received input and feedback from IEEE confirming
that the values 0 and 4095 are not used for identifying a specific
VLAN-ID and so can be used to represent none or a wildcard (see
Appendix A).
7. IANA Considerations
There are no special considerations for IANA related to this draft.
8. Security Considerations
There are a number of management objects defined in this MIB that 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 have a MAX-ACCESS clause of read-write and/or read-create. Such
objects may be considered sensitive or vulnerable in some network objects may be considered sensitive or vulnerable in some network
environments. The support for SET operations in a non-secure environments. The support for SET operations in a non-secure
environment without proper protection can have a negative effect on environment without proper protection can have a negative effect on
network operations. network operations.
SNMPv1 by itself is not a secure environment. Even if the network 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 itself is secure (for example by using IPSec), even then, there is no
skipping to change at page 81, line 40 skipping to change at page 88, line 18
GET/SET (read/change/create/delete) the objects in this MIB. GET/SET (read/change/create/delete) the objects in this MIB.
It is recommended that the implementers consider the security It is recommended that the implementers consider the security
features as provided by the SNMPv3 framework. Specifically, the use features as provided by the SNMPv3 framework. Specifically, the use
of the User-based Security Model [USM] and the View-based Access of the User-based Security Model [USM] and the View-based Access
Control Model [VACM] is recommended. Control Model [VACM] is recommended.
It is then a customer/user responsibility to ensure that the SNMP It is then a customer/user responsibility to ensure that the SNMP
entity giving access to an instance of this MIB, is properly entity giving access to an instance of this MIB, is properly
configured to give access to the objects only to those principals configured to give access to the objects only to those principals
(users) that have legitimate rights to indeed GET or SET (users) that have l
egitimate rights to indeed GET or SET
(change/create/delete) them. (change/create/delete) them.
8. References 9. Normative References
[ARCH] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for
Describing SNMP Management Frameworks", RFC 2571, April 1999.
[V1PROTO] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple
Network Management Protocol", STD 15, RFC 1157, May 1990.
[V1SMI] Rose, M. and K. McCloghrie, "Structure and Identification of
Management Information for TCP/IP-based Internets", STD 16, RFC
1155, May 1990.
[V1CONCISE] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD
16, RFC 1212, March 1991.
[V1TRAPS] Rose, M., "A Convention for Defining Traps for use with the
SNMP", RFC 1215, March 1991.
[V2SMI] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose,
M. and S. Waldbusser, "Structure of Management Information
Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
[V2TC] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose,
M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58,
RFC 2579, April 1999.
[V2CONFORM] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
Rose, M. and S. Waldbusser, "Conformance Statements for SMIv2",
STD 58, RFC 2580, April 1999.
[V2COMMUNITY] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,
"Introduction to Community-based SNMPv2", RFC 1901, January
1996.
[V2TRANS] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, [RFC1213] McCloghrie K. and M. Rose, Editors, "Management Information
"Transport Mappings for Version 2 of the Simple Network Base for Network Management of TCP/IP-based internets", STD
Management Protocol (SNMPv2)", RFC 1906, January 1996. 17, RFC 1213, March 1991.
[V2PROTO] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, [RFC1493] Decker, E., Langille, P., Rijsinghani, A. and K.
"Protocol Operations for Version 2 of the Simple Network McCloghrie, "Definitions of Managed Objects for Bridges",
Management Protocol (SNMPv2)", RFC 1905, January 1996. RFC 1493, July 1993.
[V3INTRO] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction [RFC1525] Decker, E., McCloghrie, K., Langille, P. and A.
to Version 3 of the Internet-standard Network Management Rijsinghani, "Definitions of Managed Objects for Source
Framework", RFC 2570, April 1999. Routing Bridges", RFC 1525, September 1993.
[V3MPC] Case, J., Harrington D., Presuhn, R. and B. Wijnen, "Message [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
Processing and Dispatching for the Simple Network Management Rose, M., and S. Waldbusser, "Structure of Management
Protocol (SNMP)", RFC 2572, April 1999. Information Version 2 (SMIv2)", STD 58, RFC 2578, April
1999.
[V3USM] Blumenthal, U. and B. Wijnen, "The User-Based Security Model [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
(USM) for Version 3 of the Simple Network Management Protocol Rose, M., and S. Waldbusser, "Textual Conventions for
(SNMPv3)", RFC 2574, April 1999. SMIv2", STD 58, RFC 2579, April 1999.
[V3APPS] Levi, D., Meyer, P. and B. Stewart, "SNMP Applications", RFC [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
2573, April 1999. Rose, M., and S. Waldbusser, "Conformance Statements for
SMIv2", STD 58, RFC 2580, April 1999.
[V3VACM] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access [RFC2674] Bell, E., Smith, A., Langille, P., Rijhsinghani, A. and
Control Model for the Simple Network Management Protocol McCloghrie, "Definitions of Managed Objects for Bridges
(SNMP)", RFC 2575, April 1999. with Traffic Classes, Multicast Filtering and Virtual LAN
Extensions", RFC 2674, August 1999.
[ASN1] Information processing systems - Open Systems Interconnection - [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group
Specification of Abstract Syntax Notation One (ASN.1), MIB", RFC 2863, June 2000.
International Organization for Standardization, International
Standard 8824, December 1987.
[ASN1BER] Information processing systems - Open Systems Interconnection [802.1D] "Information technology - Telecommunications and
- Specification of Basic Encoding Rules for Abstract Notation information exchange between systems - Local and
One (ASN.1), International Organization for Standardization, metropolitan area networks - Common specifications - Part
International Standard 8825, December 1987. 3: Media Access Control (MAC) Bridges: Revision. This is
a revision of ISO/IEC 10038: 1993, 802.1j-1992 and 802.6k-
1992. It incorporates P802.11c, P802.1p and P802.12e."
ISO/IEC 15802-3: 1998.
[802.1D-ORIG] ISO/IEC 10038, ANSI/IEEE Std 802.1D-1993 "MAC Bridges". [802.1D-ORIG] ISO/IEC 10038, ANSI/IEEE Std 802.1D-1993 "MAC Bridges".
[802.1D] "Information technology - Telecommunications and information
exchange between systems - Local and metropolitan area networks
- Common specifications - Part 3: Media Access Control (MAC)
Bridges: Revision. This is a revision of ISO/IEC 10038: 1993,
802.1j-1992 and 802.6k-1992. It incorporates P802.11c, P802.1p
and P802.12e." ISO/IEC 15802-3: 1998.
[802.1Q] ANSI/IEEE Standard 802.1Q, "IEEE Standards for Local and [802.1Q] ANSI/IEEE Standard 802.1Q, "IEEE Standards for Local and
Metropolitan Area Networks: Virtual Bridged Local Area Metropolitan Area Networks: Virtual Bridged Local Area
Networks", 1998. Networks", 2003.
[802.1t] IEEE 802.1t-2001, "(Amendment to IEEE Standard 802.1D) IEEE [802.1t] IEEE 802.1t-2001, "(Amendment to IEEE Standard 802.1D) IEEE
Standard for Information technology - Telecommunications and Standard for Information technology - Telecommunications
information exchange between systems - Local and metropolitan and information exchange between systems - Local and
area networks - Common specifications - Part 3: Media Access metropolitan area networks - Common specifications - Part
Control (MAC) Bridges: Technical and Editorial Corrections". 3: Media Access Control (MAC) Bridges: Technical and
Editorial Corrections".
[802.1u] IEEE 802.1u-2001, "(Amendment to IEEE Standard 802.1Q) IEEE [802.1u] IEEE 802.1u-2001, "(Amendment to IEEE Standard 802.1Q) IEEE
Standard for Local and metropolitan area networks - Virtual Standard for Local and metropolitan area networks - Virtual
Bridged Local Area Networks - Amendment 1: Technical and Bridged Local Area Networks - Amendment 1: Technical and
Editorial Corrections". Editorial Corrections".
[802.1v] IEEE 802.1v-2001, "(Amendment to IEEE Standard 802.1Q) IEEE [802.1v] IEEE 802.1v-2001, "(Amendment to IEEE Standard 802.1Q) IEEE
Standards for Local and Metropolitan Area Networks: Virtual Standards for Local and Metropolitan Area Networks: Virtual
Bridged Local Area Networks--Amendment 2: VLAN Classification by Bridged Local Area Networks--Amendment 2: VLAN
Protocol and Port". Classification by Protocol and Port".
[BRIDGEMIB] Decker, E., Langille, P., Rijsinghani, A. and K. [802.1w] IEEE 802.1w-2001, "(Amendment to IEEE Standard 802.1D) IEEE
McCloghrie, "Definitions of Managed Objects for Bridges", RFC Standard for Information technology--Telecommunications and
1493, July 1993. information exchange between systems--Local and
metropolitan area networks--Common Specifications--Part 3:
Media Access Control (MAC) Bridges: Rapid Reconfiguation".
[INTERFACEMIB] McCloghrie, K. and F. Kastenholz, "The Interfaces Group 10. Informative References
MIB using SMIv2", RFC 2233, November 1997.
[SRBRIDGEMIB] Decker, E., McCloghrie, K., Langille, P. and A. [I-D.ietf-ipcdn-qos-mib] Patrick, M. and W. Murwin, "Data Over Cable
Rijsinghani, "Definitions of Managed Objects for Source Routing System Interface Specification Quality of Service
Bridges", RFC 1525, September 1993. Management Information Base (DOCSIS-QOS MIB)", draft-ietf-
ipcdn-qos-mib-10 (work in progress), September 2004.
[MIB2] McCloghrie K. and M. Rose, Editors, "Management Information Base [I-D.ietf-rmonmib-sspm-mib] Kalbfleisch, C., Cole, R. and D. Romascanu,
for Network Management of TCP/IP-based internets", STD 17, RFC "Definition of Managed Objects for Synthetic Sources for
1213, March 1991. Performance Monitoring Algorithms.", draft-ietf-rmonmib-
sspm-mib-12 (work in progress), June 2004.
9. Authors' Addresses [RFC2613] Waterman, R., Lahaye, B., Romascanu, D. and S. Waldbusser,
"Remote Network Monitoring MIB Extensions for Switched
Networks Version 1.0", RFC 2613, June 1999.
[RFC3318] Sahita, R., Hahn, S., Chan, K. and K. McCloghrie,
"Framework Policy Information Base", RFC 3318, March 2003.
[RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart,
"Introduction and Applicability Statements for Internet-
Standard Management Framework", RFC 3410, December 2002.
[802.5] ANSI/IEEE P802.5M-Draft 7, "Source Routing Transparent
Bridge Operation", IEEE Project 802 (1991).
11. Contact Information
Vivian Ngai Vivian Ngai
Enterasys Networks Enterasys Networks
2691 South Decker Lake Lane 2691 South Decker Lake Lane
Salt lake City, UT 84119 Salt lake City, UT 84119
USA USA
Phone: +1 801 556 5652 Phone: +1 801 556 5652
Email: vivian_ngai@acm.org Email: vivian_ngai@acm.org
skipping to change at page 87, line 5 skipping to change at page 94, line 5
Keith McCloghrie Keith McCloghrie
Cisco Systems, Inc. Cisco Systems, Inc.
170 West Tasman Drive 170 West Tasman Drive
San Jose, CA 95134-1706 San Jose, CA 95134-1706
USA USA
Phone: +1 408 526 5260 Phone: +1 408 526 5260
EMail: kzm@cisco.com EMail: kzm@cisco.com
10. Intellectual Property Appendix A. Email from Tony Jeffrey from IEEE
-----Original Message-----
From: Tony Jeffree [mailto:tony@jeffree.co.uk]
Sent: Friday, 6th of June 2003 17:16
To: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
Subject: RE: VLAn ID
Bert et al -
We have concluded that the use of 4095 as a wildcard is acceptable
to 802.1, and we will make any necessary changes to 802.1Q in due
course to relax the current stated restriction. However, we need
to know whether that is all that needs to be done to 802.1Q - i.e.,
is there any need to change our definitions of the managed objects
in the document (Clause 12) to reflect the interpretation of 4095
as a wildcard, or is this simply an issue for the SNMP machinery
to handle?
Regards,
Tony
Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
This document and the informati
on contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM 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.
Disclaimer of Validity
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it might or might not be available; nor does it represent that it has
has made any effort to identify any such rights. Information on the made any independent effort to identify any such rights. Information
IETF's procedures with respect to rights in standards-track and on the procedures with respect to rights in RFC documents can be
standards-related documentation can be found in BCP-11. Copies of found in BCP 78 and BCP 79.
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to Copies of IPR disclosures made to the IETF Secretariat and any
obtain a general license or permission for the use of such assurances of licenses to be made available, or the result of an
proprietary rights by implementors or users of this specification can attempt made to obtain a general license or permission for the use of
be obtained from the IETF Secretariat. such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF Executive this standard. Please address the information to the IETF at ietf-
Director. ipr@ietf.org.
11. Full Copyright Statement
Copyright (C) The Internet Society (2004). 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.
The limited permissions granted above are perpetual and will not be Table of Contents
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an 1 The Internet-Standard Management Framework ................... 4
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 2 Overview ..................................................... 4
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 2.1 Scope ...................................................... 5
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 3 Structure of MIBs ............................................ 5
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 3.1 Structure of Extended Bridge MIB module .................... 6
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 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 ........... 10
3.2.2 The dot1qBase Group ...................................... 13
3.2.3 The dot1qTp Group ........................................ 13
3.2.4 The dot1qStatic Group .................................... 14
3.2.5 The dot1qVlan Group ...................................... 14
3.3 Textual Conventions ........................................ 14
3.4 Relationship to Other MIBs ................................. 15
3.4.1 Relationship to the 'system' group ....................... 15
3.4.2 Relation to Interfaces MIB ............................... 15
3.4.2.1 Layering Model ......................................... 16
3.4.2.2 ifStackTable ........................................... 17
3.4.2.3 ifRcvAddressTable ...................................... 17
3.4.3 Relation to Original Bridge MIB .......................... 18
3.4.3.1 The dot1dBase Group .................................... 18
3.4.3.2 The dot1dStp Group ..................................... 18
3.4.3.3 The dot1dTp Group ...................................... 18
3.4.3.4 The dot1dStatic Group .................................. 19
3.4.3.5 Additions to the Original Bridge MIB ................... 19
4 Definitions for Extended Bridge MIB .......................... 21
5 Definitions for Virtual Bridge MIB ........................... 41
6 Acknowledgments .............................................. 87
7 IANA Considerations .......................................... 87
8 Security Considerations ...................................... 87
9 Normative References ......................................... 89
10 Informative References ...................................... 90
11 Contact Information ......................................... 92
Appendix A. Email from Tony Jeffrey from IEEE .................. 94
Copyright Statement ........................................... 94
Disclaimer of Validity ........................................ 94
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/