rfc-4363

Definitions of Managed Objects for Bridges with Traffic Classes, Multicast Filtering, and Virtual LAN Extensions

D. Levi, D. Harrington
date2006-01 streamIETF areaops wgbridge statusPROPOSED STANDARD pages99 canonicalhttps://www.rfc-editor.org/rfc/rfc4363 doi10.17487/RFC4363 errataview
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 capabilities of MAC bridges defined by the IEEE 802.1D-1998 (TM) MAC Bridges and the IEEE 802.1Q-2003 (TM) 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 and P802.1t-2001 (TM). The other MIB module defines objects for managing VLANs, as specified in IEEE 802.1Q-2003, P802.1u (TM), and P802.1v (TM). Provisions are made for support of transparent bridging. Provisions are also made so that these objects apply to bridges connected by subnetworks other than LAN segments. This memo supplements RFC 4188 and obsoletes RFC 2674. [STANDARDS-TRACK]

obsoletes

Extracted elements (27)

design-rationale §3.1.1

Devices that implement Extended Forwarding Services (IEEE 802.1D) but not virtual bridged LANs should implement dot1qTpGroupTable, dot1qForwardAllTable, and dot1qForwardUnregisteredTable with a fixed dot1qFdbId or dot1qVlanIndex of 1, rather than omitting these tables entirely.

snmp

design-rationale §3.4.2.2

ifStackTable from IF-MIB cannot fully represent IEEE 802.1Q VLAN bridging because 802.1Q distinguishes VLAN bindings on ingress from those on egress (asymmetric), whereas IF-MIB assumes a symmetric transmit/receive binding. This necessitates separate per-port VLAN membership objects in Q-BRIDGE-MIB.

snmp

design-rationale §3.3

Three new textual conventions (VlanIdOrAny, VlanIdOrNone, VlanIdOrAnyOrNone) were defined in Q-BRIDGE-MIB to address a proliferation of incompatible VLAN-ID representations appearing across standards-track MIB documents (e.g., RFC 2613, RFC 3318, RFC 4323, RFC 4149), reducing confusion and unnecessary complexity.

snmp

interoperability-note §3.4.2.1

Higher-layer protocol entities (e.g., IP interfaces) on a VLAN should be represented in ifTable as interfaces of type propVirtual(53). Protocol-specific types such as l3ipxvlan(137) should not be used, as no protocol filtering before delivery to these virtual interfaces is implied.

snmp

interoperability-note §3.4.3.3

In devices supporting multiple Filtering Databases, dot1dTpFdbTable must report each MAC address only once per port even if learned in multiple FDBs; if learned on multiple ports across multiple FDBs, it may be reported on any one valid port. dot1dTpLearnedEntryDiscards counts overflow of any FDB, and dot1dTpAgingTime applies to all FDBs.

snmp

interoperability-note §3.4.3.4

In multi-FDB devices, dot1dStaticTable should be implemented as read-only (static entries from all FDBs, deduplicated by MAC+port index). Write access to static unicast and multicast entries should instead be provided through dot1qStaticUnicastTable and dot1qStaticMulticastTable.

snmp

normative-requirement §4 MUST

The pBridgeHCPortGroup and pBridgePortOverflowGroup are mandatory for bridge ports whose corresponding interface has ifSpeed greater than 650,000,000 bits/second.

snmp

normative-requirement §4 MUST

The values of numerous configuration objects—including dot1dTrafficClassesEnabled, dot1dGmrpStatus, dot1dPortGmrpStatus, dot1dPortDefaultUserPriority, dot1dPortNumTrafficClasses, dot1dRegenUserPriority, dot1dTrafficClass, GARP timers, dot1dPortRestrictedGroupRegistration, and VLAN/port settings—MUST be retained across reinitializations of the management system.

snmp

protocol-element §4

dot1dDeviceCapabilities is a BITS object indicating optional device-level capabilities including dot1dExtendedFilteringServices (GMRP-controlled multicast), dot1dTrafficClasses (multiple traffic classes), dot1qIVLCapable, dot1qSVLCapable, dot1qHybridCapable, dot1qConfigurablePvidTagging, and dot1dLocalVlanCapable.

snmp

protocol-element §4

dot1dPortCapabilities is a per-port BITS object indicating support for dot1qDot1qTagging (802.1Q tagging and GVRP), dot1qConfigurableAcceptableFrameTypes, and dot1qIngressFiltering. It augments dot1dBasePortEntry.

snmp

protocol-element §4

dot1dPortGarpTable configures per-port GARP timers: JoinTime (default 20 centiseconds), LeaveTime (default 60 centiseconds), and LeaveAllTime (default 1000 centiseconds). These control GARP protocol timing for both GMRP and GVRP applications.

snmp

protocol-element §4

dot1dPortRestrictedGroupRegistration (TruthValue, default false) controls Restricted Group Registration on a per-port basis: when true, creation of a new dynamic GMRP entry is permitted only if a Static Filtering Entry with Normal Registration exists for that VLAN. Defined per IEEE 802.1t clause 10.3.2.3.

snmp

protocol-element §4

dot1dTpHCPortTable provides Counter64 statistics (InFrames, OutFrames, InDiscards) for high-capacity transparent bridge ports, extending dot1dTpPortTable from the BRIDGE-MIB. Only frames for protocols being processed by the local bridging function are counted.

snmp, measurement

protocol-element §4

dot1dTpPortOverflowTable provides the most-significant 32 bits of the port statistics counters (InFrames, OutFrames, InDiscards) for SNMPv1 agents that cannot use Counter64. Managers must account for possible overflow of the lower-32-bit counter between samples when combining the two tables.

snmp, measurement

protocol-element §4

dot1dTrafficClassTable maps evaluated User Priority (0..7) to a Traffic Class in the range 0..(dot1dPortNumTrafficClasses-1) per port. For untagged Ethernet frames, the evaluated priority equals dot1dPortDefaultUserPriority; for other untagged media, it equals dot1dRegenUserPriority.

snmp, qos

protocol-element §4

dot1dUserPriorityRegenTable maps each incoming User Priority (0..7) to a Regenerated User Priority (0..7) on a per-port basis. This only affects media that support native User Priority. The default mapping is identity (each priority maps to itself).

snmp, qos

protocol-element §5

dot1qForwardAllTable and dot1qForwardUnregisteredTable control per-VLAN multicast forwarding: ForwardAllPorts (all multicast forwarded), ForwardAllStaticPorts (statically configured), ForwardAllForbiddenPorts (forbidden), and the equivalent for unregistered addresses. Both tables are indexed by dot1qFdbId and group address.

snmp, multicast

protocol-element §5

dot1qLearningConstraintsTable manages VLAN learning constraints specifying whether pairs of VLANs share a Filtering Database (Shared VLAN Learning) or use independent databases (Independent VLAN Learning), controlled per constraint set. dot1qConstraintSetDefault and dot1qConstraintTypeDefault give system-wide defaults.

snmp

protocol-element §5

dot1qVlanCurrentTable provides a time-filtered (using TimeFilter via dot1qVlanTimeMark) view of all currently known VLANs, including their FDB association (dot1qVlanFdbId), egress port set, untagged port set, status (permanent, dynamicGvrp, etc.), and creation time.

snmp

protocol-element §5

dot1vProtocolGroupTable (IEEE 802.1v) defines the Protocol Group Database, mapping FrameType and ProtocolValue to a ProtocolGroupId. dot1vProtocolPortTable then maps each protocol group to a VLAN ID per port, enabling protocol-based VLAN classification.

snmp

protocol-element §4

P-BRIDGE-MIB (OID dot1dBridge 6) defines managed objects for the Traffic Classes and Enhanced Multicast Filtering components of IEEE 802.1D-1998 and P802.1t-2001, including GARP and GMRP control, priority queuing, and high-capacity port statistics. It obsoletes the priority/multicast portions of RFC 2674.

snmp, registry

protocol-element §5

Q-BRIDGE-MIB (OID dot1dBridge 7) defines managed objects for port-based VLANs as specified in IEEE 802.1Q-2003, P802.1u (Restricted VLAN Registration), and P802.1v (VLAN Classification by Protocol and Port). It includes filtering databases, static and dynamic VLAN tables, and VLAN learning constraints.

snmp, registry

protocol-element §3.3

Three textual conventions—VlanIdOrAny (1..4094 | 4095, where 4095 means any VLAN), VlanIdOrNone (0..4094, where 0 means no VLAN), and VlanIdOrAnyOrNone—are defined to unify VLAN-ID representation across MIB modules. Objects using these TCs must clarify the meaning of the special values in their DESCRIPTION clause.

snmp

protocol-element §5

VlanId is a textual convention representing the 12-bit VLAN-ID used in 802.1Q Tag headers, with valid range 1..4094. Values 0 and 4095 are excluded from this TC.

snmp

protocol-element §5

VlanIndex extends VLAN indexing beyond 802.1Q: values 1..4094 represent standard 802.1Q VLAN-IDs with global scope; values greater than 4095 represent agent-local VLANs without a globally assigned VLAN-ID. Values 0 and 4095 are not permitted.

snmp

security-consideration §7

Section 7 identifies writable objects in P-BRIDGE-MIB and Q-BRIDGE-MIB (such as traffic class mappings, VLAN membership, GARP timers, and GMRP administrative controls) as security-sensitive: unauthorized write access could disrupt bridge forwarding, alter VLAN topology, or suppress multicast group registration. SNMPv3 with authentication and privacy is recommended.

snmp, security

wire-format §5

PortList is an OCTET STRING textual convention where each octet encodes eight ports: the first octet covers ports 1–8, with the most significant bit representing the lowest-numbered port and the least significant bit representing the highest. A bit value of '1' includes the port in the set.

snmp