GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc4188

Network Working Group K. Norseth, Ed. Request for Comments: 4188 L-3 Communications Obsoletes: 1493 E. Bell, Ed. Category: Standards Track 3Com Europe Limited

                                                        September 2005
             Definitions of Managed Objects for Bridges

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 (2005).

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 objects for managing MAC bridges based on
 the IEEE 802.1D-1998 standard between Local Area Network (LAN)
 segments.  Provisions are made for the support of transparent
 bridging.  Provisions are also made so that these objects apply to
 bridges connected by subnetworks other than LAN segments.
 The MIB module presented in this memo is a translation of the
 BRIDGE-MIB defined in RFC 1493 to the SMIv2 syntax.
 This memo obsoletes RFC 1493.

Norseth & Bell, Eds. Standards Track [Page 1] RFC 4188 Bridge MIB September 2005

Table of Contents

 1. The Internet-Standard Management Framework ......................2
 2. Conventions .....................................................2
 3. Overview ........................................................3
    3.1. Structure of the MIB Module ................................3
         3.1.1. The dot1dBase Subtree ...............................6
         3.1.2. The dot1dStp Subtree ................................6
         3.1.3. The dot1dSr Subtree .................................6
         3.1.4. The dot1dTp Subtree .................................6
         3.1.5. The dot1dStatic Subtree .............................6
    3.2. Relationship to Other MIB Modules ..........................6
         3.2.1. Relationship to the SNMPv2-MIB ......................7
         3.2.2. Relationship to the IF-MIB ..........................7
 4. Definitions .....................................................8
 5. IANA Considerations ............................................39
 6. Security Considerations ........................................39
 7. Acknowledgements ...............................................40
 8. Contact Information ............................................41
 9. Changes from RFC 1493 ..........................................42
 10. References ....................................................42
    10.1. Normative References .....................................42
    10.2. Informative References ...................................43

1. The Internet-Standard Management Framework

 For a detailed overview of the documents that describe the current
 Internet-Standard Management Framework, please refer to section 7 of
 RFC 3410 [RFC3410].
 Managed objects are accessed via a virtual information store, termed
 the Management Information Base or MIB.  MIB objects are generally
 accessed through the Simple Network Management Protocol (SNMP).
 Objects in the MIB are defined using the mechanisms defined in the
 Structure of Management Information (SMI).  This memo specifies a MIB
 module that is compliant to the SMIv2, which is described in STD 58,
 RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580
 [RFC2580].

2. Conventions

 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
 "OPTIONAL", when they appear in this document, are to be interpreted
 as described in BCP 14, RFC 2119 [RFC2119].

Norseth & Bell, Eds. Standards Track [Page 2] RFC 4188 Bridge MIB September 2005

3. Overview

 A common device present in many networks is the Bridge.  This device
 is used to connect Local Area Network segments below the network
 layer.
 There are two major modes defined for this bridging: transparent and
 source route.  The transparent method of bridging is defined in the
 IEEE 802.1D specification [IEEE8021D].  This memo defines those
 objects needed for the management of a bridging entity that operates
 in the transparent mode, as well as some objects that apply to all
 types of bridges.
 To be consistent with IAB directives and good engineering practices,
 an explicit attempt was made to keep this MIB module as simple as
 possible.  This was accomplished by applying the following criteria
 to objects proposed for inclusion:
 1. Start with a small set of essential objects and add only as
    further objects are needed.
 2. Require that objects be essential for either fault or
    configuration management.
 3. Consider evidence of current use and/or utility.
 4. Limit the total number of objects.
 5. Exclude objects that are simply derivable from others in this or
    other MIB modules.
 6. Avoid causing critical sections to be heavily instrumented.  The
    guideline that was followed is one counter per critical section
    per layer.

3.1 Structure of the MIB Module

 Objects in this MIB module are arranged into subtrees.  Each subtree
 is organized as a set of related objects.  The overall structure and
 assignment of objects to their subtrees is shown below.  Where
 appropriate, the corresponding IEEE 802.1D [IEEE8021D] management
 object name is also included.

Norseth & Bell, Eds. Standards Track [Page 3] RFC 4188 Bridge MIB September 2005

 Bridge MIB Name                  IEEE 802.1D Name
 dot1dBridge
   dot1dBase
     BridgeAddress                Bridge.BridgeAddress
     NumPorts                     Bridge.NumberOfPorts
     Type
     PortTable
       Port                       BridgePort.PortNumber
       IfIndex
       Circuit
       DelayExceededDiscards        .DiscardTransitDelay
       MtuExceededDiscards          .DiscardOnError
   dot1dStp
     ProtocolSpecification
     Priority                     SpanningTreeProtocol
                                    .BridgePriority
     TimeSinceTopologyChange        .TimeSinceTopologyChange
     TopChanges                     .TopologyChangeCount
     DesignatedRoot                 .DesignatedRoot
     RootCost                       .RootCost
     RootPort                       .RootPort
     MaxAge                         .MaxAge
     HelloTime                      .HelloTime
     HoldTime                       .HoldTime
     ForwardDelay                   .ForwardDelay
     BridgeMaxAge                   .BridgeMaxAge
     BridgeHelloTime                .BridgeHelloTime
     BridgeForwardDelay             .BridgeForwardDelay
     PortTable
       Port                        SpanningTreeProtocolPort
                                     .PortNumber
       Priority                      .PortPriority
       State                         .SpanningTreeState
       Enable
       PathCost                      .PortPathCost
       DesignatedRoot                .DesignatedRoot
       DesignatedCost                .DesignatedCost
       DesignatedBridge              .DesignatedBridge
       DesignatedPort                .DesignatedPort
       ForwardTransitions

Norseth & Bell, Eds. Standards Track [Page 4] RFC 4188 Bridge MIB September 2005

   dot1dTp
     LearnedEntryDiscards          BridgeFilter.DatabaseSize
                                     .NumDynamic,NumStatic
     AgingTime                     BridgeFilter.AgingTime
     FdbTable
       Address
       Port
       Status
     PortTable
       Port
       MaxInfo
       InFrames                    BridgePort.FramesReceived
       OutFrames                     .ForwardOutbound
       InDiscards                    .DiscardInbound
   dot1dStatic
     StaticTable
       Address
       ReceivePort
       AllowedToGoTo
       Status
 The following IEEE 802.1D management objects have not been included
 in the BRIDGE-MIB module for the indicated reasons.
 IEEE 802.1D Object              Disposition
 Bridge.BridgeName               Same as sysDescr (SNMPv2-MIB)
 Bridge.BridgeUpTime             Same as sysUpTime (SNMPv2-MIB)
 Bridge.PortAddresses            Same as ifPhysAddress (IF-MIB)
 BridgePort.PortName             Same as ifDescr (IF-MIB)
 BridgePort.PortType             Same as ifType (IF-MIB)
 BridgePort.RoutingType          Derivable from the implemented
                                 subtrees
 SpanningTreeProtocol
     .BridgeIdentifier           Combination of dot1dStpPriority
                                 and dot1dBaseBridgeAddress
     .TopologyChange             Since this is transitory, it
                                 is not considered useful.
 SpanningTreeProtocolPort
     .Uptime                     Same as ifLastChange (IF-MIB)
     .PortIdentifier             Combination of dot1dStpPort
                                 and dot1dStpPortPriority
     .TopologyChangeAcknowledged Since this is transitory, it
                                 is not considered useful.
     .DiscardLackOfBuffers       Redundant

Norseth & Bell, Eds. Standards Track [Page 5] RFC 4188 Bridge MIB September 2005

 Transmission Priority           These objects are not required
                                 as per the Pics Proforma and
                                 are not considered useful.
     .TransmissionPriorityName
     .OutboundUserPriority
     .OutboundAccessPriority

3.1.1 The dot1dBase Subtree

 This subtree contains the objects that are applicable to all types of
 bridges.

3.1.2 The dot1dStp Subtree

 This subtree contains the objects that denote the bridge's state with
 respect to the Spanning Tree Protocol.  If a node does not implement
 the Spanning Tree Protocol, this subtree will not be implemented.

3.1.3 The dot1dSr Subtree

 This subtree contains the objects that describe the entity's state
 with respect to source route bridging.  This subtree described in RFC
 1525 [RFC1525] is applicable only to source route bridging.

3.1.4 The dot1dTp Subtree

 This subtree contains objects that describe the entity's state with
 respect to transparent bridging.  If transparent bridging is not
 supported, this subtree will not be implemented.  This subtree is
 applicable to transparent-only and SRT bridges.

3.1.5 The dot1dStatic Subtree

 This subtree contains objects that describe the entity's state with
 respect to destination-address filtering.  If destination-address
 filtering is not supported, this subtree will not be implemented.
 This subtree is applicable to any type of bridge that performs
 destination-address filtering.

3.2 Relationship to Other MIB Modules

 As described above, some IEEE 802.1D management objects have not been
 included in this MIB module because they overlap with objects in
 other MIB modules that are applicable to a bridge implementing this
 MIB module.

Norseth & Bell, Eds. Standards Track [Page 6] RFC 4188 Bridge MIB September 2005

3.2.1 Relationship to the SNMPv2-MIB

 The SNMPv2-MIB [RFC3418] defines objects that are generally
 applicable to managed devices.  These objects apply to the device as
 a whole, irrespective of whether the device's sole functionality is
 bridging, or whether bridging is only a subset of the device's
 functionality.
 As explained in Section 3.1, full support for the 802.1D management
 objects requires that the SNMPv2-MIB objects sysDescr and sysUpTime
 be implemented.  Note that compliance with the current SNMPv2-MIB
 module requires additional objects and notifications to be
 implemented, as specified in RFC 3418 [RFC3418].

3.2.2 Relationship to the IF-MIB

 The IF-MIB [RFC2863] defines managed objects for managing network
 interfaces.  A network interface is thought of as being attached to a
 `subnetwork'.  Note that this term is not to be confused with
 `subnet', which refers to an addressing partitioning scheme used in
 the Internet suite of protocols.  The term 'segment' is used in this
 memo to refer to such a subnetwork, whether it be an Ethernet
 segment, a 'ring', a WAN link, or even an X.25 virtual circuit.
 As explained in Section 3.1, full support for the 802.1D management
 objects requires that the IF-MIB objects ifIndex, ifType, ifDescr,
 ifPhysAddress, and ifLastChange are implemented.  Note that
 compliance to the current IF-MIB module requires additional objects
 and notifications to be implemented as specified in RFC 2863
 [RFC2863].
 Implicit in this BRIDGE-MIB is the notion of ports on a bridge.  Each
 of these ports is associated with one interface of the 'interfaces'
 subtree, and in most situations, each port is associated with a
 different interface.  However, there are situations in which multiple
 ports are associated with the same interface.  An example of such a
 situation would be several ports, each corresponding, one-to-one,
 with several X.25 virtual circuits that are all on the same
 interface.
 Each port is uniquely identified by a port number.  A port number has
 no mandatory relationship to an interface number, but in the simple
 case, a port number will have the same value as the corresponding
 interface's interface number.  Port numbers are in the range
 (1..dot1dBaseNumPorts).

Norseth & Bell, Eds. Standards Track [Page 7] RFC 4188 Bridge MIB September 2005

 Some entities perform other functionalities as well as bridging
 through the sending and receiving of data on their interfaces.  In
 such situations, only a subset of the data sent/received on an
 interface is within the domain of the entity's bridging
 functionality.  This subset is considered to be delineated according
 to a set of protocols, with some protocols being bridged, and other
 protocols not being bridged.  For example, in an entity that
 exclusively performs bridging, all protocols would be considered as
 bridged, whereas in an entity that performs IP routing on IP
 datagrams and only bridges other protocols, only the non-IP data
 would be considered as having been bridged.
 Thus, this BRIDGE-MIB (and in particular, its counters) are
 applicable only to that subset of the data on an entity's interfaces
 that is sent/received for a protocol being bridged.  All such data is
 sent/received via the ports of the bridge.

4. Definitions

 BRIDGE-MIB DEFINITIONS ::= BEGIN
  1. - ———————————————————- –
  2. - MIB for IEEE 802.1D devices
  3. - ———————————————————- –

IMPORTS

     MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE,
     Counter32, Integer32, TimeTicks, mib-2
         FROM SNMPv2-SMI
     TEXTUAL-CONVENTION, MacAddress
         FROM SNMPv2-TC
     MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP
         FROM SNMPv2-CONF
     InterfaceIndex FROM IF-MIB
     ;
 dot1dBridge MODULE-IDENTITY
     LAST-UPDATED "200509190000Z"
     ORGANIZATION "IETF Bridge MIB Working Group"
     CONTACT-INFO
         "Email: bridge-mib@ietf.org
                  K.C. Norseth (Editor)
                  L-3 Communications
             Tel: +1 801-594-2809
           Email: kenyon.c.norseth@L-3com.com
          Postal: 640 N. 2200 West.
                  Salt Lake City, Utah 84116-0850

Norseth & Bell, Eds. Standards Track [Page 8] RFC 4188 Bridge MIB September 2005

                  Les Bell (Editor)
                  3Com Europe Limited
           Phone: +44 1442 438025
           Email: elbell@ntlworld.com
          Postal: 3Com Centre, Boundary Way
                  Hemel Hempstead
                  Herts.  HP2 7YU
                  UK
          Send comments to <bridge-mib@ietf.org>"
     DESCRIPTION
         "The Bridge MIB module for managing devices that support
         IEEE 802.1D.
         Copyright (C) The Internet Society (2005).  This version of
         this MIB module is part of RFC 4188; see the RFC itself for
         full legal notices."
     REVISION     "200509190000Z"
     DESCRIPTION
          "Third revision, published as part of RFC 4188.
          The MIB module has been converted to SMIv2 format.
          Conformance statements have been added and some
          description and reference clauses have been updated.
          The object dot1dStpPortPathCost32 was added to
          support IEEE 802.1t and the permissible values of
          dot1dStpPriority and dot1dStpPortPriority have been
          clarified for bridges supporting IEEE 802.1t or
          IEEE 802.1w.
          The interpretation of dot1dStpTimeSinceTopologyChange
          has been clarified for bridges supporting the Rapid
          Spanning Tree Protocol (RSTP)."
     REVISION     "199307310000Z"
     DESCRIPTION
          "Second revision, published as part of RFC 1493."
     REVISION     "199112310000Z"
     DESCRIPTION
          "Initial revision, published as part of RFC 1286."
     ::= { mib-2 17 }
  1. - ———————————————————- –
  2. - Textual Conventions
  3. - ———————————————————- –
 BridgeId ::= TEXTUAL-CONVENTION

Norseth & Bell, Eds. Standards Track [Page 9] RFC 4188 Bridge MIB September 2005

     STATUS      current
     DESCRIPTION
         "The Bridge-Identifier, as used in the Spanning Tree
         Protocol, to uniquely identify a bridge.  Its first two
         octets (in network byte order) contain a priority value,
         and its last 6 octets contain the MAC address used to
         refer to a bridge in a unique fashion (typically, the
         numerically smallest MAC address of all ports on the
         bridge)."
     SYNTAX      OCTET STRING (SIZE (8))
 Timeout ::= TEXTUAL-CONVENTION
     DISPLAY-HINT "d"
     STATUS      current
     DESCRIPTION
         "A Spanning Tree Protocol (STP) timer in units of 1/100
         seconds.  Several objects in this MIB module represent
         values of timers used by the Spanning Tree Protocol.
         In this MIB, these timers have values in units of
         hundredths of a second (i.e., 1/100 secs).
         These timers, when stored in a Spanning Tree Protocol's
         BPDU, are in units of 1/256 seconds.  Note, however, that
         802.1D-1998 specifies a settable granularity of no more
         than one second for these timers.  To avoid ambiguity,
         a conversion algorithm is defined below for converting
         between the different units, which ensures a timer's
         value is not distorted by multiple conversions.
         To convert a Timeout value into a value in units of
         1/256 seconds, the following algorithm should be used:
             b = floor( (n * 256) / 100)
         where:
             floor   =  quotient [ignore remainder]
             n is the value in 1/100 second units
             b is the value in 1/256 second units
         To convert the value from 1/256 second units back to
         1/100 seconds, the following algorithm should be used:
             n = ceiling( (b * 100) / 256)
         where:
             ceiling = quotient [if remainder is 0], or
                       quotient + 1 [if remainder is nonzero]
             n is the value in 1/100 second units

Norseth & Bell, Eds. Standards Track [Page 10] RFC 4188 Bridge MIB September 2005

             b is the value in 1/256 second units
         Note: it is important that the arithmetic operations are
         done in the order specified (i.e., multiply first,
         divide second)."
     SYNTAX      Integer32
  1. - ———————————————————- –
  2. - subtrees in the Bridge MIB
  3. - ———————————————————- –
 dot1dNotifications  OBJECT IDENTIFIER ::= { dot1dBridge 0 }
 dot1dBase           OBJECT IDENTIFIER ::= { dot1dBridge 1 }
 dot1dStp            OBJECT IDENTIFIER ::= { dot1dBridge 2 }
 dot1dSr             OBJECT IDENTIFIER ::= { dot1dBridge 3 }
 -- documented in RFC 1525
 dot1dTp             OBJECT IDENTIFIER ::= { dot1dBridge 4 }
 dot1dStatic         OBJECT IDENTIFIER ::= { dot1dBridge 5 }
  1. - Subtrees used by Bridge MIB Extensions:
  2. - pBridgeMIB MODULE-IDENTITY ::= { dot1dBridge 6 }
  3. - qBridgeMIB MODULE-IDENTITY ::= { dot1dBridge 7 }
  4. - Note that the practice of registering related MIB modules
  5. - below dot1dBridge has been discouraged since there is no
  6. - robust mechanism to track such registrations.
 dot1dConformance    OBJECT IDENTIFIER ::= { dot1dBridge 8 }
  1. - ———————————————————- –
  2. - the dot1dBase subtree
  3. - ———————————————————- –
  4. - Implementation of the dot1dBase subtree is mandatory for all
  5. - bridges.
  6. - ———————————————————- –
 dot1dBaseBridgeAddress OBJECT-TYPE
     SYNTAX      MacAddress
     MAX-ACCESS  read-only
     STATUS      current
     DESCRIPTION
         "The MAC address used by this bridge when it must be
         referred to in a unique fashion.  It is recommended
         that this be the numerically smallest MAC address of
         all ports that belong to this bridge.  However, it is only

Norseth & Bell, Eds. Standards Track [Page 11] RFC 4188 Bridge MIB September 2005

         required to be unique.  When concatenated with
         dot1dStpPriority, a unique BridgeIdentifier is formed,
         which is used in the Spanning Tree Protocol."
     REFERENCE
         "IEEE 802.1D-1998: clauses 14.4.1.1.3 and 7.12.5"
     ::= { dot1dBase 1 }
 dot1dBaseNumPorts OBJECT-TYPE
     SYNTAX      Integer32
     UNITS       "ports"
     MAX-ACCESS  read-only
     STATUS      current
     DESCRIPTION
         "The number of ports controlled by this bridging
         entity."
     REFERENCE
         "IEEE 802.1D-1998: clause 14.4.1.1.3"
     ::= { dot1dBase 2 }
 dot1dBaseType OBJECT-TYPE
     SYNTAX      INTEGER {
                     unknown(1),
                     transparent-only(2),
                     sourceroute-only(3),
                     srt(4)
                 }
     MAX-ACCESS  read-only
     STATUS      current
     DESCRIPTION
         "Indicates what type of bridging this bridge can
         perform.  If a bridge is actually performing a
         certain type of bridging, this will be indicated by
         entries in the port table for the given type."
     ::= { dot1dBase 3 }
  1. - ———————————————————- –
  2. - The Generic Bridge Port Table
  3. - ———————————————————- –

dot1dBasePortTable OBJECT-TYPE

     SYNTAX      SEQUENCE OF Dot1dBasePortEntry
     MAX-ACCESS  not-accessible
     STATUS      current
     DESCRIPTION
         "A table that contains generic information about every
         port that is associated with this bridge.  Transparent,
         source-route, and srt ports are included."
     ::= { dot1dBase 4 }

Norseth & Bell, Eds. Standards Track [Page 12] RFC 4188 Bridge MIB September 2005

 dot1dBasePortEntry OBJECT-TYPE
     SYNTAX      Dot1dBasePortEntry
     MAX-ACCESS  not-accessible
     STATUS      current
     DESCRIPTION
         "A list of information for each port of the bridge."
     REFERENCE
         "IEEE 802.1D-1998: clause 14.4.2, 14.6.1"
     INDEX  { dot1dBasePort }
     ::= { dot1dBasePortTable 1 }
 Dot1dBasePortEntry ::=
     SEQUENCE {
         dot1dBasePort
             Integer32,
         dot1dBasePortIfIndex
             InterfaceIndex,
         dot1dBasePortCircuit
             OBJECT IDENTIFIER,
         dot1dBasePortDelayExceededDiscards
             Counter32,
         dot1dBasePortMtuExceededDiscards
             Counter32
     }
 dot1dBasePort OBJECT-TYPE
     SYNTAX      Integer32 (1..65535)
     MAX-ACCESS  read-only
     STATUS      current
     DESCRIPTION
         "The port number of the port for which this entry
         contains bridge management information."
     ::= { dot1dBasePortEntry 1 }
 dot1dBasePortIfIndex OBJECT-TYPE
     SYNTAX      InterfaceIndex
     MAX-ACCESS  read-only
     STATUS      current
     DESCRIPTION
         "The value of the instance of the ifIndex object,
         defined in IF-MIB, for the interface corresponding
         to this port."
     ::= { dot1dBasePortEntry 2 }
 dot1dBasePortCircuit OBJECT-TYPE
     SYNTAX      OBJECT IDENTIFIER
     MAX-ACCESS  read-only

Norseth & Bell, Eds. Standards Track [Page 13] RFC 4188 Bridge MIB September 2005

     STATUS      current
     DESCRIPTION
         "For a port that (potentially) has the same value of
         dot1dBasePortIfIndex as another port on the same bridge.
         This object contains the name of an object instance
         unique to this port.  For example, in the case where
         multiple ports correspond one-to-one with multiple X.25
         virtual circuits, this value might identify an (e.g.,
         the first) object instance associated with the X.25
         virtual circuit corresponding to this port.
         For a port which has a unique value of
         dot1dBasePortIfIndex, this object can have the value
         { 0 0 }."
     ::= { dot1dBasePortEntry 3 }
 dot1dBasePortDelayExceededDiscards OBJECT-TYPE
     SYNTAX      Counter32
     MAX-ACCESS  read-only
     STATUS      current
     DESCRIPTION
         "The number of frames discarded by this port due
         to excessive transit delay through the bridge.  It
         is incremented by both transparent and source
         route bridges."
     REFERENCE
         "IEEE 802.1D-1998: clause 14.6.1.1.3"
     ::= { dot1dBasePortEntry 4 }
 dot1dBasePortMtuExceededDiscards OBJECT-TYPE
     SYNTAX      Counter32
     MAX-ACCESS  read-only
     STATUS      current
     DESCRIPTION
         "The number of frames discarded by this port due
         to an excessive size.  It is incremented by both
         transparent and source route bridges."
     REFERENCE
         "IEEE 802.1D-1998: clause 14.6.1.1.3"
     ::= { dot1dBasePortEntry 5 }
  1. - ———————————————————- –
  2. - the dot1dStp subtree
  3. - ———————————————————- –
  4. - Implementation of the dot1dStp subtree is optional. It is
  5. - implemented by those bridges that support the Spanning Tree
  6. - Protocol.
  7. - ———————————————————- –

Norseth & Bell, Eds. Standards Track [Page 14] RFC 4188 Bridge MIB September 2005

 dot1dStpProtocolSpecification OBJECT-TYPE
     SYNTAX      INTEGER {
                     unknown(1),
                     decLb100(2),
                     ieee8021d(3)
                 }
     MAX-ACCESS  read-only
     STATUS      current
     DESCRIPTION
         "An indication of what version of the Spanning Tree
         Protocol is being run.  The value 'decLb100(2)'
         indicates the DEC LANbridge 100 Spanning Tree protocol.
         IEEE 802.1D implementations will return 'ieee8021d(3)'.
         If future versions of the IEEE Spanning Tree Protocol
         that are incompatible with the current version
         are released a new value will be defined."
     ::= { dot1dStp 1 }
 dot1dStpPriority OBJECT-TYPE
     SYNTAX      Integer32 (0..65535)
     MAX-ACCESS  read-write
     STATUS      current
     DESCRIPTION
         "The value of the write-able portion of the Bridge ID
         (i.e., the first two octets of the (8 octet long) Bridge
         ID).  The other (last) 6 octets of the Bridge ID are
         given by the value of dot1dBaseBridgeAddress.
         On bridges supporting IEEE 802.1t or IEEE 802.1w,
         permissible values are 0-61440, in steps of 4096."
     REFERENCE
         "IEEE 802.1D-1998 clause 8.10.2, Table 8-4,
         IEEE 802.1t clause 8.10.2, Table 8-4, clause 14.3."
     ::= { dot1dStp 2 }
 dot1dStpTimeSinceTopologyChange OBJECT-TYPE
     SYNTAX      TimeTicks
     UNITS       "centi-seconds"
     MAX-ACCESS  read-only
     STATUS      current
     DESCRIPTION
         "The time (in hundredths of a second) since the
         last time a topology change was detected by the
         bridge entity.
         For RSTP, this reports the time since the tcWhile
         timer for any port on this Bridge was nonzero."
     REFERENCE
         "IEEE 802.1D-1998 clause 14.8.1.1.,
         IEEE 802.1w clause 14.8.1.1."

Norseth & Bell, Eds. Standards Track [Page 15] RFC 4188 Bridge MIB September 2005

     ::= { dot1dStp 3 }
 dot1dStpTopChanges OBJECT-TYPE
     SYNTAX      Counter32
     MAX-ACCESS  read-only
     STATUS      current
     DESCRIPTION
         "The total number of topology changes detected by
         this bridge since the management entity was last
         reset or initialized."
     REFERENCE
         "IEEE 802.1D-1998 clause 14.8.1.1."
     ::= { dot1dStp 4 }
 dot1dStpDesignatedRoot OBJECT-TYPE
     SYNTAX      BridgeId
     MAX-ACCESS  read-only
     STATUS      current
     DESCRIPTION
         "The bridge identifier of the root of the spanning
         tree, as determined by the Spanning Tree Protocol,
         as executed by this node.  This value is used as
         the Root Identifier parameter in all Configuration
         Bridge PDUs originated by this node."
     REFERENCE
         "IEEE 802.1D-1998: clause 8.5.3.1"
     ::= { dot1dStp 5 }
 dot1dStpRootCost OBJECT-TYPE
     SYNTAX      Integer32
     MAX-ACCESS  read-only
     STATUS      current
     DESCRIPTION
         "The cost of the path to the root as seen from
         this bridge."
     REFERENCE
         "IEEE 802.1D-1998: clause 8.5.3.2"
     ::= { dot1dStp 6 }
 dot1dStpRootPort OBJECT-TYPE
     SYNTAX      Integer32
     MAX-ACCESS  read-only
     STATUS      current
     DESCRIPTION
         "The port number of the port that offers the lowest
         cost path from this bridge to the root bridge."
     REFERENCE
         "IEEE 802.1D-1998: clause 8.5.3.3"

Norseth & Bell, Eds. Standards Track [Page 16] RFC 4188 Bridge MIB September 2005

     ::= { dot1dStp 7 }
 dot1dStpMaxAge OBJECT-TYPE
     SYNTAX      Timeout
     UNITS       "centi-seconds"
     MAX-ACCESS  read-only
     STATUS      current
     DESCRIPTION
         "The maximum age of Spanning Tree Protocol information
         learned from the network on any port before it is
         discarded, in units of hundredths of a second.  This is
         the actual value that this bridge is currently using."
     REFERENCE
         "IEEE 802.1D-1998: clause 8.5.3.4"
     ::= { dot1dStp 8 }
 dot1dStpHelloTime OBJECT-TYPE
     SYNTAX      Timeout
     UNITS       "centi-seconds"
     MAX-ACCESS  read-only
     STATUS      current
     DESCRIPTION
         "The amount of time between the transmission of
         Configuration bridge PDUs by this node on any port when
         it is the root of the spanning tree, or trying to become
         so, in units of hundredths of a second.  This is the
         actual value that this bridge is currently using."
     REFERENCE
         "IEEE 802.1D-1998: clause 8.5.3.5"
     ::= { dot1dStp 9 }
 dot1dStpHoldTime OBJECT-TYPE
     SYNTAX      Integer32
     UNITS       "centi-seconds"
     MAX-ACCESS  read-only
     STATUS      current
     DESCRIPTION
         "This time value determines the interval length
         during which no more than two Configuration bridge
         PDUs shall be transmitted by this node, in units
         of hundredths of a second."
     REFERENCE
         "IEEE 802.1D-1998: clause 8.5.3.14"
     ::= { dot1dStp 10 }
 dot1dStpForwardDelay OBJECT-TYPE
     SYNTAX      Timeout
     UNITS       "centi-seconds"

Norseth & Bell, Eds. Standards Track [Page 17] RFC 4188 Bridge MIB September 2005

     MAX-ACCESS  read-only
     STATUS      current
     DESCRIPTION
         "This time value, measured in units of hundredths of a
         second, controls how fast a port changes its spanning
         state when moving towards the Forwarding state.  The
         value determines how long the port stays in each of the
         Listening and Learning states, which precede the
         Forwarding state.  This value is also used when a
         topology change has been detected and is underway, to
         age all dynamic entries in the Forwarding Database.
         [Note that this value is the one that this bridge is
         currently using, in contrast to
         dot1dStpBridgeForwardDelay, which is the value that this
         bridge and all others would start using if/when this
         bridge were to become the root.]"
     REFERENCE
         "IEEE 802.1D-1998: clause 8.5.3.6"
     ::= { dot1dStp 11 }
 dot1dStpBridgeMaxAge OBJECT-TYPE
     SYNTAX      Timeout (600..4000)
     UNITS       "centi-seconds"
     MAX-ACCESS  read-write
     STATUS      current
     DESCRIPTION
         "The value that all bridges use for MaxAge when this
         bridge is acting as the root.  Note that 802.1D-1998
         specifies that the range for this parameter is related
         to the value of dot1dStpBridgeHelloTime.  The
         granularity of this timer is specified by 802.1D-1998 to
         be 1 second.  An agent may return a badValue error if a
         set is attempted to a value that is not a whole number
         of seconds."
     REFERENCE
         "IEEE 802.1D-1998: clause 8.5.3.8"
     ::= { dot1dStp 12 }
 dot1dStpBridgeHelloTime OBJECT-TYPE
     SYNTAX      Timeout (100..1000)
     UNITS       "centi-seconds"
     MAX-ACCESS  read-write
     STATUS      current
     DESCRIPTION
         "The value that all bridges use for HelloTime when this
         bridge is acting as the root.  The granularity of this
         timer is specified by 802.1D-1998 to be 1 second.  An
         agent may return a badValue error if a set is attempted

Norseth & Bell, Eds. Standards Track [Page 18] RFC 4188 Bridge MIB September 2005

         to a value that is not a whole number of seconds."
     REFERENCE
         "IEEE 802.1D-1998: clause 8.5.3.9"
     ::= { dot1dStp 13 }
 dot1dStpBridgeForwardDelay OBJECT-TYPE
     SYNTAX      Timeout (400..3000)
     UNITS       "centi-seconds"
     MAX-ACCESS  read-write
     STATUS      current
     DESCRIPTION
         "The value that all bridges use for ForwardDelay when
         this bridge is acting as the root.  Note that
         802.1D-1998 specifies that the range for this parameter
         is related to the value of dot1dStpBridgeMaxAge.  The
         granularity of this timer is specified by 802.1D-1998 to
         be 1 second.  An agent may return a badValue error if a
         set is attempted to a value that is not a whole number
         of seconds."
     REFERENCE
         "IEEE 802.1D-1998: clause 8.5.3.10"
     ::= { dot1dStp 14 }
  1. - ———————————————————- –
  2. - The Spanning Tree Port Table
  3. - ———————————————————- –
 dot1dStpPortTable OBJECT-TYPE
     SYNTAX      SEQUENCE OF Dot1dStpPortEntry
     MAX-ACCESS  not-accessible
     STATUS      current
     DESCRIPTION
         "A table that contains port-specific information
         for the Spanning Tree Protocol."
     ::= { dot1dStp 15 }
 dot1dStpPortEntry OBJECT-TYPE
     SYNTAX      Dot1dStpPortEntry
     MAX-ACCESS  not-accessible
     STATUS      current
     DESCRIPTION
         "A list of information maintained by every port about
         the Spanning Tree Protocol state for that port."
     INDEX   { dot1dStpPort }
     ::= { dot1dStpPortTable 1 }
 Dot1dStpPortEntry ::=
     SEQUENCE {

Norseth & Bell, Eds. Standards Track [Page 19] RFC 4188 Bridge MIB September 2005

         dot1dStpPort
             Integer32,
         dot1dStpPortPriority
             Integer32,
         dot1dStpPortState
             INTEGER,
         dot1dStpPortEnable
             INTEGER,
         dot1dStpPortPathCost
             Integer32,
         dot1dStpPortDesignatedRoot
             BridgeId,
         dot1dStpPortDesignatedCost
             Integer32,
         dot1dStpPortDesignatedBridge
             BridgeId,
         dot1dStpPortDesignatedPort
             OCTET STRING,
         dot1dStpPortForwardTransitions
             Counter32,
         dot1dStpPortPathCost32
             Integer32
     }
 dot1dStpPort OBJECT-TYPE
     SYNTAX      Integer32 (1..65535)
     MAX-ACCESS  read-only
     STATUS      current
     DESCRIPTION
         "The port number of the port for which this entry
         contains Spanning Tree Protocol management information."
     REFERENCE
         "IEEE 802.1D-1998: clause 14.8.2.1.2"
     ::= { dot1dStpPortEntry 1 }
 dot1dStpPortPriority OBJECT-TYPE
     SYNTAX      Integer32 (0..255)
     MAX-ACCESS  read-write
     STATUS      current
     DESCRIPTION
         "The value of the priority field that is contained in
         the first (in network byte order) octet of the (2 octet
         long) Port ID.  The other octet of the Port ID is given
         by the value of dot1dStpPort.
         On bridges supporting IEEE 802.1t or IEEE 802.1w,
         permissible values are 0-240, in steps of 16."
     REFERENCE
         "IEEE 802.1D-1998 clause 8.10.2, Table 8-4,

Norseth & Bell, Eds. Standards Track [Page 20] RFC 4188 Bridge MIB September 2005

         IEEE 802.1t clause 8.10.2, Table 8-4, clause 14.3."
     ::= { dot1dStpPortEntry 2 }
 dot1dStpPortState OBJECT-TYPE
     SYNTAX      INTEGER {
                     disabled(1),
                     blocking(2),
                     listening(3),
                     learning(4),
                     forwarding(5),
                     broken(6)
                 }
     MAX-ACCESS  read-only
     STATUS      current
     DESCRIPTION
         "The port's current state, as defined by application of
         the Spanning Tree Protocol.  This state controls what
         action a port takes on reception of a frame.  If the
         bridge has detected a port that is malfunctioning, it
         will place that port into the broken(6) state.  For
         ports that are disabled (see dot1dStpPortEnable), this
         object will have a value of disabled(1)."
     REFERENCE
         "IEEE 802.1D-1998: clause 8.5.5.2"
     ::= { dot1dStpPortEntry 3 }
 dot1dStpPortEnable OBJECT-TYPE
     SYNTAX      INTEGER {
                     enabled(1),
                     disabled(2)
                 }
     MAX-ACCESS  read-write
     STATUS      current
     DESCRIPTION
         "The enabled/disabled status of the port."
     REFERENCE
         "IEEE 802.1D-1998: clause 8.5.5.2"
     ::= { dot1dStpPortEntry 4 }
 dot1dStpPortPathCost OBJECT-TYPE
     SYNTAX      Integer32 (1..65535)
     MAX-ACCESS  read-write
     STATUS      current
     DESCRIPTION
         "The contribution of this port to the path cost of
         paths towards the spanning tree root which include
         this port.  802.1D-1998 recommends that the default
         value of this parameter be in inverse proportion to

Norseth & Bell, Eds. Standards Track [Page 21] RFC 4188 Bridge MIB September 2005

         the speed of the attached LAN.
         New implementations should support dot1dStpPortPathCost32.
         If the port path costs exceeds the maximum value of this
         object then this object should report the maximum value,
         namely 65535.  Applications should try to read the
         dot1dStpPortPathCost32 object if this object reports
         the maximum value."
     REFERENCE "IEEE 802.1D-1998: clause 8.5.5.3"
         ::= { dot1dStpPortEntry 5 }
 dot1dStpPortDesignatedRoot OBJECT-TYPE
     SYNTAX      BridgeId
     MAX-ACCESS  read-only
     STATUS      current
     DESCRIPTION
         "The unique Bridge Identifier of the Bridge
         recorded as the Root in the Configuration BPDUs
         transmitted by the Designated Bridge for the
         segment to which the port is attached."
     REFERENCE
         "IEEE 802.1D-1998: clause 8.5.5.4"
     ::= { dot1dStpPortEntry 6 }
 dot1dStpPortDesignatedCost OBJECT-TYPE
     SYNTAX      Integer32
     MAX-ACCESS  read-only
     STATUS      current
     DESCRIPTION
         "The path cost of the Designated Port of the segment
         connected to this port.  This value is compared to the
         Root Path Cost field in received bridge PDUs."
     REFERENCE
         "IEEE 802.1D-1998: clause 8.5.5.5"
     ::= { dot1dStpPortEntry 7 }
 dot1dStpPortDesignatedBridge OBJECT-TYPE
     SYNTAX      BridgeId
     MAX-ACCESS  read-only
     STATUS      current
     DESCRIPTION
         "The Bridge Identifier of the bridge that this
         port considers to be the Designated Bridge for
         this port's segment."
     REFERENCE
         "IEEE 802.1D-1998: clause 8.5.5.6"
     ::= { dot1dStpPortEntry 8 }

Norseth & Bell, Eds. Standards Track [Page 22] RFC 4188 Bridge MIB September 2005

 dot1dStpPortDesignatedPort OBJECT-TYPE
     SYNTAX      OCTET STRING (SIZE (2))
     MAX-ACCESS  read-only
     STATUS      current
     DESCRIPTION
         "The Port Identifier of the port on the Designated
         Bridge for this port's segment."
     REFERENCE
         "IEEE 802.1D-1998: clause 8.5.5.7"
     ::= { dot1dStpPortEntry 9 }
 dot1dStpPortForwardTransitions OBJECT-TYPE
     SYNTAX      Counter32
     MAX-ACCESS  read-only
     STATUS      current
     DESCRIPTION
         "The number of times this port has transitioned
         from the Learning state to the Forwarding state."
     ::= { dot1dStpPortEntry 10 }
 dot1dStpPortPathCost32 OBJECT-TYPE
     SYNTAX      Integer32 (1..200000000)
     MAX-ACCESS  read-write
     STATUS      current
     DESCRIPTION
         "The contribution of this port to the path cost of
         paths towards the spanning tree root which include
         this port.  802.1D-1998 recommends that the default
         value of this parameter be in inverse proportion to
         the speed of the attached LAN.
         This object replaces dot1dStpPortPathCost to support
         IEEE 802.1t."
     REFERENCE
         "IEEE 802.1t clause 8.10.2, Table 8-5."
     ::= { dot1dStpPortEntry 11 }
  1. - ———————————————————- –
  2. - the dot1dTp subtree
  3. - ———————————————————- –
  4. - Implementation of the dot1dTp subtree is optional. It is
  5. - implemented by those bridges that support the transparent
  6. - bridging mode. A transparent or SRT bridge will implement
  7. - this subtree.
  8. - ———————————————————- –
 dot1dTpLearnedEntryDiscards OBJECT-TYPE
     SYNTAX      Counter32

Norseth & Bell, Eds. Standards Track [Page 23] RFC 4188 Bridge MIB September 2005

     MAX-ACCESS  read-only
     STATUS      current
     DESCRIPTION
         "The total number of Forwarding Database entries that
         have been or would have been learned, but have been
         discarded due to a lack of storage space in the
         Forwarding Database.  If this counter is increasing, it
         indicates that the Forwarding Database is regularly
         becoming full (a condition that has unpleasant
         performance effects on the subnetwork).  If this counter
         has a significant value but is not presently increasing,
         it indicates that the problem has been occurring but is
         not persistent."
     REFERENCE
         "IEEE 802.1D-1998: clause 14.7.1.1.3"
     ::= { dot1dTp 1 }
 dot1dTpAgingTime OBJECT-TYPE
     SYNTAX      Integer32 (10..1000000)
     UNITS       "seconds"
     MAX-ACCESS  read-write
     STATUS      current
     DESCRIPTION
         "The timeout period in seconds for aging out
         dynamically-learned forwarding information.
         802.1D-1998 recommends a default of 300 seconds."
     REFERENCE
         "IEEE 802.1D-1998: clause 14.7.1.1.3"
     ::= { dot1dTp 2 }
  1. - ———————————————————- –
  2. - The Forwarding Database for Transparent Bridges
  3. - ———————————————————- –
 dot1dTpFdbTable OBJECT-TYPE
     SYNTAX      SEQUENCE OF Dot1dTpFdbEntry
     MAX-ACCESS  not-accessible
     STATUS      current
     DESCRIPTION
         "A table that contains information about unicast
         entries for which the bridge has forwarding and/or
         filtering information.  This information is used
         by the transparent bridging function in
         determining how to propagate a received frame."
     ::= { dot1dTp 3 }
 dot1dTpFdbEntry OBJECT-TYPE

Norseth & Bell, Eds. Standards Track [Page 24] RFC 4188 Bridge MIB September 2005

     SYNTAX      Dot1dTpFdbEntry
     MAX-ACCESS  not-accessible
     STATUS      current
     DESCRIPTION
         "Information about a specific unicast MAC address
         for which the bridge has some forwarding and/or
         filtering information."
     INDEX   { dot1dTpFdbAddress }
     ::= { dot1dTpFdbTable 1 }
 Dot1dTpFdbEntry ::=
     SEQUENCE {
         dot1dTpFdbAddress
             MacAddress,
         dot1dTpFdbPort
             Integer32,
         dot1dTpFdbStatus
             INTEGER
     }
 dot1dTpFdbAddress OBJECT-TYPE
     SYNTAX      MacAddress
     MAX-ACCESS  read-only
     STATUS      current
     DESCRIPTION
         "A unicast MAC address for which the bridge has
         forwarding and/or filtering information."
     REFERENCE
         "IEEE 802.1D-1998: clause 7.9.1, 7.9.2"
     ::= { dot1dTpFdbEntry 1 }
 dot1dTpFdbPort OBJECT-TYPE
     SYNTAX      Integer32
     MAX-ACCESS  read-only
     STATUS      current
     DESCRIPTION
         "Either the value '0', or the port number of the port on
         which a frame having a source address equal to the value
         of the corresponding instance of dot1dTpFdbAddress has
         been seen.  A value of '0' indicates that the port
         number has not been learned, but that the bridge does
         have some forwarding/filtering information about this
         address (e.g., in the dot1dStaticTable).  Implementors
         are encouraged to assign the port value to this object
         whenever it is learned, even for addresses for which the
         corresponding value of dot1dTpFdbStatus is not
         learned(3)."
     ::= { dot1dTpFdbEntry 2 }

Norseth & Bell, Eds. Standards Track [Page 25] RFC 4188 Bridge MIB September 2005

 dot1dTpFdbStatus OBJECT-TYPE
     SYNTAX      INTEGER {
                     other(1),
                     invalid(2),
                     learned(3),
                     self(4),
                     mgmt(5)
                 }
     MAX-ACCESS  read-only
     STATUS      current
     DESCRIPTION
         "The status of this entry.  The meanings of the
         values are:
             other(1) - none of the following.  This would
                 include the case where some other MIB object
                 (not the corresponding instance of
                 dot1dTpFdbPort, nor an entry in the
                 dot1dStaticTable) is being used to determine if
                 and how frames addressed to the value of the
                 corresponding instance of dot1dTpFdbAddress are
                 being forwarded.
             invalid(2) - this entry is no longer valid (e.g.,
                 it was learned but has since aged out), but has
                 not yet been flushed from the table.
             learned(3) - the value of the corresponding instance
                 of dot1dTpFdbPort was learned, and is being
                 used.
             self(4) - the value of the corresponding instance of
                 dot1dTpFdbAddress represents one of the bridge's
                 addresses.  The corresponding instance of
                 dot1dTpFdbPort indicates which of the bridge's
                 ports has this address.
             mgmt(5) - the value of the corresponding instance of
                 dot1dTpFdbAddress is also the value of an
                 existing instance of dot1dStaticAddress."
     ::= { dot1dTpFdbEntry 3 }
  1. - ———————————————————- –
  2. - Port Table for Transparent Bridges
  3. - ———————————————————- –
 dot1dTpPortTable OBJECT-TYPE
     SYNTAX      SEQUENCE OF Dot1dTpPortEntry
     MAX-ACCESS  not-accessible
     STATUS      current
     DESCRIPTION
         "A table that contains information about every port that
         is associated with this transparent bridge."

Norseth & Bell, Eds. Standards Track [Page 26] RFC 4188 Bridge MIB September 2005

     ::= { dot1dTp 4 }
 dot1dTpPortEntry OBJECT-TYPE
     SYNTAX      Dot1dTpPortEntry
     MAX-ACCESS  not-accessible
     STATUS      current
     DESCRIPTION
         "A list of information for each port of a transparent
         bridge."
     INDEX   { dot1dTpPort }
     ::= { dot1dTpPortTable 1 }
 Dot1dTpPortEntry ::=
     SEQUENCE {
         dot1dTpPort
             Integer32,
         dot1dTpPortMaxInfo
             Integer32,
         dot1dTpPortInFrames
             Counter32,
         dot1dTpPortOutFrames
             Counter32,
         dot1dTpPortInDiscards
             Counter32
     }
 dot1dTpPort OBJECT-TYPE
     SYNTAX      Integer32 (1..65535)
     MAX-ACCESS  read-only
     STATUS      current
     DESCRIPTION
         "The port number of the port for which this entry
         contains Transparent bridging management information."
     ::= { dot1dTpPortEntry 1 }
  1. - It would be nice if we could use ifMtu as the size of the
  2. - largest INFO field, but we can't because ifMtu is defined
  3. - to be the size that the (inter-)network layer can use, which
  4. - can differ from the MAC layer (especially if several layers
  5. - of encapsulation are used).
 dot1dTpPortMaxInfo OBJECT-TYPE
     SYNTAX      Integer32
     UNITS       "bytes"
     MAX-ACCESS  read-only
     STATUS      current
     DESCRIPTION
         "The maximum size of the INFO (non-MAC) field that

Norseth & Bell, Eds. Standards Track [Page 27] RFC 4188 Bridge MIB September 2005

         this port will receive or transmit."
     ::= { dot1dTpPortEntry 2 }
 dot1dTpPortInFrames OBJECT-TYPE
     SYNTAX      Counter32
     UNITS       "frames"
     MAX-ACCESS  read-only
     STATUS      current
     DESCRIPTION
         "The number of frames that have been received by this
         port from its segment.  Note that a frame received on the
         interface corresponding to this port is only counted by
         this object if and only if it is for a protocol being
         processed by the local bridging function, including
         bridge management frames."
     REFERENCE
         "IEEE 802.1D-1998: clause 14.6.1.1.3"
     ::= { dot1dTpPortEntry 3 }
 dot1dTpPortOutFrames OBJECT-TYPE
     SYNTAX      Counter32
     UNITS       "frames"
     MAX-ACCESS  read-only
     STATUS      current
     DESCRIPTION
         "The number of frames that have been transmitted by this
         port to its segment.  Note that a frame transmitted on
         the interface corresponding to this port is only counted
         by this object if and only if it is for a protocol being
         processed by the local bridging function, including
         bridge management frames."
     REFERENCE
         "IEEE 802.1D-1998: clause 14.6.1.1.3"
     ::= { dot1dTpPortEntry 4 }
 dot1dTpPortInDiscards OBJECT-TYPE
     SYNTAX      Counter32
     UNITS       "frames"
     MAX-ACCESS  read-only
     STATUS      current
     DESCRIPTION
         "Count of received valid frames that were discarded
         (i.e., filtered) by the Forwarding Process."
     REFERENCE
         "IEEE 802.1D-1998: clause 14.6.1.1.3"
     ::= { dot1dTpPortEntry 5 }
  1. - ———————————————————- –

Norseth & Bell, Eds. Standards Track [Page 28] RFC 4188 Bridge MIB September 2005

  1. - The Static (Destination-Address Filtering) Database
  2. - ———————————————————- –
  3. - Implementation of this subtree is optional.
  4. - ———————————————————- –
 dot1dStaticTable OBJECT-TYPE
     SYNTAX      SEQUENCE OF Dot1dStaticEntry
     MAX-ACCESS  not-accessible
     STATUS      current
     DESCRIPTION
         "A table containing filtering information configured
         into the bridge by (local or network) management
         specifying the set of ports to which frames received
         from specific ports and containing specific destination
         addresses are allowed to be forwarded.  The value of
         zero in this table, as the port number from which frames
         with a specific destination address are received, is
         used to specify all ports for which there is no specific
         entry in this table for that particular destination
         address.  Entries are valid for unicast and for
         group/broadcast addresses."
     REFERENCE
         "IEEE 802.1D-1998: clause 14.7.2"
     ::= { dot1dStatic 1 }
 dot1dStaticEntry OBJECT-TYPE
     SYNTAX      Dot1dStaticEntry
     MAX-ACCESS  not-accessible
     STATUS      current
     DESCRIPTION
         "Filtering information configured into the bridge by
         (local or network) management specifying the set of
         ports to which frames received from a specific port and
         containing a specific destination address are allowed to
         be forwarded."
     REFERENCE
         "IEEE 802.1D-1998: clause 14.7.2"
     INDEX   { dot1dStaticAddress, dot1dStaticReceivePort }
     ::= { dot1dStaticTable 1 }
 Dot1dStaticEntry ::=
     SEQUENCE {
         dot1dStaticAddress       MacAddress,
         dot1dStaticReceivePort   Integer32,
         dot1dStaticAllowedToGoTo OCTET STRING,
         dot1dStaticStatus        INTEGER
     }

Norseth & Bell, Eds. Standards Track [Page 29] RFC 4188 Bridge MIB September 2005

 dot1dStaticAddress OBJECT-TYPE
     SYNTAX      MacAddress
     MAX-ACCESS  read-create
     STATUS      current
     DESCRIPTION
         "The destination MAC address in a frame to which this
         entry's filtering information applies.  This object can
         take the value of a unicast address, a group address, or
         the broadcast address."
     REFERENCE
         "IEEE 802.1D-1998: clause 7.9.1, 7.9.2"
     ::= { dot1dStaticEntry 1 }
 dot1dStaticReceivePort OBJECT-TYPE
     SYNTAX      Integer32 (0..65535)
     MAX-ACCESS  read-create
     STATUS      current
     DESCRIPTION
         "Either the value '0', or the port number of the port
         from which a frame must be received in order for this
         entry's filtering information to apply.  A value of zero
         indicates that this entry applies on all ports of the
         bridge for which there is no other applicable entry."
     ::= { dot1dStaticEntry 2 }
 dot1dStaticAllowedToGoTo OBJECT-TYPE
     SYNTAX      OCTET STRING (SIZE (0..512))
     MAX-ACCESS  read-create
     STATUS      current
     DESCRIPTION
         "The set of ports to which frames received from a
         specific port and destined for a specific MAC address,
         are allowed to be forwarded.  Each octet within the
         value of this object specifies a set of eight ports,
         with the first octet specifying ports 1 through 8, the
         second octet specifying ports 9 through 16, etc.  Within
         each octet, the most significant bit represents the
         lowest numbered port, and the least significant bit
         represents the highest numbered port.  Thus, each port
         of the bridge is represented by a single bit within the
         value of this object.  If that bit has a value of '1',
         then that port is included in the set of ports; the port
         is not included if its bit has a value of '0'.  (Note
         that the setting of the bit corresponding to the port
         from which a frame is received is irrelevant.)  The
         default value of this object is a string of ones of
         appropriate length.

Norseth & Bell, Eds. Standards Track [Page 30] RFC 4188 Bridge MIB September 2005

         The value of this object may exceed the required minimum
         maximum message size of some SNMP transport (484 bytes,
         in the case of SNMP over UDP, see RFC 3417, section 3.2).
         SNMP engines on bridges supporting a large number of
         ports must support appropriate maximum message sizes."
     ::= { dot1dStaticEntry 3 }
 dot1dStaticStatus OBJECT-TYPE
     SYNTAX      INTEGER {
                     other(1),
                     invalid(2),
                     permanent(3),
                     deleteOnReset(4),
                     deleteOnTimeout(5)
                 }
     MAX-ACCESS  read-create
     STATUS      current
     DESCRIPTION
         "This object indicates the status of this entry.
         The default value is permanent(3).
             other(1) - this entry is currently in use but the
                 conditions under which it will remain so are
                 different from each of the following values.
             invalid(2) - writing this value to the object
                 removes the corresponding entry.
             permanent(3) - this entry is currently in use and
                 will remain so after the next reset of the
                 bridge.
             deleteOnReset(4) - this entry is currently in use
                 and will remain so until the next reset of the
                 bridge.
             deleteOnTimeout(5) - this entry is currently in use
                 and will remain so until it is aged out."
     ::= { dot1dStaticEntry 4 }
  1. - ———————————————————- –
  2. - Notifications for use by Bridges
  3. - ———————————————————- –
  4. - Notifications for the Spanning Tree Protocol
  5. - ———————————————————- –
 newRoot NOTIFICATION-TYPE
     -- OBJECTS     { }
     STATUS      current
     DESCRIPTION
         "The newRoot trap indicates that the sending agent has
         become the new root of the Spanning Tree; the trap is
         sent by a bridge soon after its election as the new

Norseth & Bell, Eds. Standards Track [Page 31] RFC 4188 Bridge MIB September 2005

         root, e.g., upon expiration of the Topology Change Timer,
         immediately subsequent to its election.  Implementation
         of this trap is optional."
     ::= { dot1dNotifications 1 }
 topologyChange NOTIFICATION-TYPE
     -- OBJECTS     { }
     STATUS      current
     DESCRIPTION
         "A topologyChange trap is sent by a bridge when any of
         its configured ports transitions from the Learning state
         to the Forwarding state, or from the Forwarding state to
         the Blocking state.  The trap is not sent if a newRoot
         trap is sent for the same transition.  Implementation of
         this trap is optional."
     ::= { dot1dNotifications 2 }
  1. - ———————————————————- –
  2. - IEEE 802.1D MIB - Conformance Information
  3. - ———————————————————- –
 dot1dGroups         OBJECT IDENTIFIER ::= { dot1dConformance 1 }
 dot1dCompliances    OBJECT IDENTIFIER ::= { dot1dConformance 2 }
  1. - ———————————————————- –
  2. - units of conformance
  3. - ———————————————————- –
  1. - ———————————————————- –
  2. - the dot1dBase group
  3. - ———————————————————- –
 dot1dBaseBridgeGroup OBJECT-GROUP
     OBJECTS {
         dot1dBaseBridgeAddress,
         dot1dBaseNumPorts,
         dot1dBaseType
     }
     STATUS      current
     DESCRIPTION
         "Bridge level information for this device."
     ::= { dot1dGroups 1 }
 dot1dBasePortGroup OBJECT-GROUP
     OBJECTS {
         dot1dBasePort,
         dot1dBasePortIfIndex,
         dot1dBasePortCircuit,

Norseth & Bell, Eds. Standards Track [Page 32] RFC 4188 Bridge MIB September 2005

         dot1dBasePortDelayExceededDiscards,
         dot1dBasePortMtuExceededDiscards
     }
     STATUS      current
     DESCRIPTION
         "Information for each port on this device."
     ::= { dot1dGroups 2 }
  1. - ———————————————————- –
  2. - the dot1dStp group
  3. - ———————————————————- –
 dot1dStpBridgeGroup OBJECT-GROUP
     OBJECTS {
         dot1dStpProtocolSpecification,
         dot1dStpPriority,
         dot1dStpTimeSinceTopologyChange,
         dot1dStpTopChanges,
         dot1dStpDesignatedRoot,
         dot1dStpRootCost,
         dot1dStpRootPort,
         dot1dStpMaxAge,
         dot1dStpHelloTime,
         dot1dStpHoldTime,
         dot1dStpForwardDelay,
         dot1dStpBridgeMaxAge,
         dot1dStpBridgeHelloTime,
         dot1dStpBridgeForwardDelay
     }
     STATUS      current
     DESCRIPTION
         "Bridge level Spanning Tree data for this device."
     ::= { dot1dGroups 3 }
 dot1dStpPortGroup OBJECT-GROUP
     OBJECTS {
         dot1dStpPort,
         dot1dStpPortPriority,
         dot1dStpPortState,
         dot1dStpPortEnable,
         dot1dStpPortPathCost,
         dot1dStpPortDesignatedRoot,
         dot1dStpPortDesignatedCost,
         dot1dStpPortDesignatedBridge,
         dot1dStpPortDesignatedPort,
         dot1dStpPortForwardTransitions
     }
     STATUS      current

Norseth & Bell, Eds. Standards Track [Page 33] RFC 4188 Bridge MIB September 2005

     DESCRIPTION
         "Spanning Tree data for each port on this device."
     ::= { dot1dGroups 4 }
 dot1dStpPortGroup2 OBJECT-GROUP
     OBJECTS {
         dot1dStpPort,
         dot1dStpPortPriority,
         dot1dStpPortState,
         dot1dStpPortEnable,
         dot1dStpPortDesignatedRoot,
         dot1dStpPortDesignatedCost,
         dot1dStpPortDesignatedBridge,
         dot1dStpPortDesignatedPort,
         dot1dStpPortForwardTransitions,
         dot1dStpPortPathCost32
     }
     STATUS      current
     DESCRIPTION
         "Spanning Tree data for each port on this device."
     ::= { dot1dGroups 5 }
 dot1dStpPortGroup3 OBJECT-GROUP
     OBJECTS {
         dot1dStpPortPathCost32
     }
     STATUS      current
     DESCRIPTION
         "Spanning Tree data for devices supporting 32-bit
          path costs."
     ::= { dot1dGroups 6 }
  1. - ———————————————————- –
  2. - the dot1dTp group
  3. - ———————————————————- –
 dot1dTpBridgeGroup OBJECT-GROUP
     OBJECTS {
         dot1dTpLearnedEntryDiscards,
         dot1dTpAgingTime
     }
     STATUS      current
     DESCRIPTION
         "Bridge level Transparent Bridging data."
     ::= { dot1dGroups 7 }
 dot1dTpFdbGroup OBJECT-GROUP
     OBJECTS {

Norseth & Bell, Eds. Standards Track [Page 34] RFC 4188 Bridge MIB September 2005

         dot1dTpFdbAddress,
         dot1dTpFdbPort,
         dot1dTpFdbStatus
     }
     STATUS      current
     DESCRIPTION
         "Filtering Database information for the Bridge."
     ::= { dot1dGroups 8 }
 dot1dTpGroup OBJECT-GROUP
     OBJECTS {
         dot1dTpPort,
         dot1dTpPortMaxInfo,
         dot1dTpPortInFrames,
         dot1dTpPortOutFrames,
         dot1dTpPortInDiscards
     }
     STATUS      current
     DESCRIPTION
         "Dynamic Filtering Database information for each port of
         the Bridge."
     ::= { dot1dGroups 9 }
  1. - ———————————————————- –
  2. - The Static (Destination-Address Filtering) Database
  3. - ———————————————————- –
 dot1dStaticGroup OBJECT-GROUP
     OBJECTS {
         dot1dStaticAddress,
         dot1dStaticReceivePort,
         dot1dStaticAllowedToGoTo,
         dot1dStaticStatus
     }
     STATUS      current
     DESCRIPTION
         "Static Filtering Database information for each port of
         the Bridge."
     ::= { dot1dGroups 10 }
  1. - ———————————————————- –
  2. - The Trap Notification Group
  3. - ———————————————————- –
 dot1dNotificationGroup NOTIFICATION-GROUP
     NOTIFICATIONS {
         newRoot,

Norseth & Bell, Eds. Standards Track [Page 35] RFC 4188 Bridge MIB September 2005

         topologyChange
     }
     STATUS      current
     DESCRIPTION
         "Group of objects describing notifications (traps)."
     ::= { dot1dGroups 11 }
  1. - ———————————————————- –
  2. - compliance statements
  3. - ———————————————————- –
 bridgeCompliance1493 MODULE-COMPLIANCE
     STATUS      current
     DESCRIPTION
         "The compliance statement for device support of bridging
         services, as per RFC1493."
     MODULE
         MANDATORY-GROUPS {
             dot1dBaseBridgeGroup,
             dot1dBasePortGroup
         }
     GROUP   dot1dStpBridgeGroup
     DESCRIPTION
         "Implementation of this group is mandatory for bridges
         that support the Spanning Tree Protocol."
     GROUP   dot1dStpPortGroup
     DESCRIPTION
         "Implementation of this group is mandatory for bridges
         that support the Spanning Tree Protocol."
     GROUP   dot1dTpBridgeGroup
     DESCRIPTION
         "Implementation of this group is mandatory for bridges
         that support the transparent bridging mode.  A
         transparent or SRT bridge will implement this group."
     GROUP   dot1dTpFdbGroup
     DESCRIPTION
         "Implementation of this group is mandatory for bridges
         that support the transparent bridging mode.  A
         transparent or SRT bridge will implement this group."
     GROUP   dot1dTpGroup
     DESCRIPTION
         "Implementation of this group is mandatory for bridges

Norseth & Bell, Eds. Standards Track [Page 36] RFC 4188 Bridge MIB September 2005

         that support the transparent bridging mode.  A
         transparent or SRT bridge will implement this group."
     GROUP   dot1dStaticGroup
     DESCRIPTION
         "Implementation of this group is optional."
     GROUP dot1dNotificationGroup
     DESCRIPTION
         "Implementation of this group is optional."
     ::= { dot1dCompliances 1 }
 bridgeCompliance4188 MODULE-COMPLIANCE
     STATUS      current
     DESCRIPTION
         "The compliance statement for device support of bridging
         services.  This supports 32-bit Path Cost values and the
         more restricted bridge and port priorities, as per IEEE
         802.1t.
         Full support for the 802.1D management objects requires that
         the SNMPv2-MIB [RFC3418] objects sysDescr, and sysUpTime, as
         well as the IF-MIB [RFC2863] objects ifIndex, ifType,
         ifDescr, ifPhysAddress, and ifLastChange are implemented."
     MODULE
         MANDATORY-GROUPS {
             dot1dBaseBridgeGroup,
             dot1dBasePortGroup
         }
     GROUP   dot1dStpBridgeGroup
     DESCRIPTION
         "Implementation of this group is mandatory for
         bridges that support the Spanning Tree Protocol."
     OBJECT dot1dStpPriority
     SYNTAX Integer32 (0|4096|8192|12288|16384|20480|24576
                      |28672|32768|36864|40960|45056|49152
                      |53248|57344|61440)
     DESCRIPTION
         "The possible values defined by IEEE 802.1t."
     GROUP   dot1dStpPortGroup2
     DESCRIPTION
         "Implementation of this group is mandatory for
         bridges that support the Spanning Tree Protocol."

Norseth & Bell, Eds. Standards Track [Page 37] RFC 4188 Bridge MIB September 2005

     GROUP   dot1dStpPortGroup3
     DESCRIPTION
         "Implementation of this group is mandatory for bridges
          that support the Spanning Tree Protocol and 32-bit path
          costs.  In particular, this includes devices supporting
          IEEE 802.1t and IEEE 802.1w."
     OBJECT dot1dStpPortPriority
     SYNTAX Integer32 (0|16|32|48|64|80|96|112|128
                      |144|160|176|192|208|224|240)
     DESCRIPTION
         "The possible values defined by IEEE 802.1t."
     GROUP   dot1dTpBridgeGroup
     DESCRIPTION
         "Implementation of this group is mandatory for
         bridges that support the transparent bridging
         mode.  A transparent or SRT bridge will implement
         this group."
     GROUP   dot1dTpFdbGroup
     DESCRIPTION
         "Implementation of this group is mandatory for
         bridges that support the transparent bridging
         mode.  A transparent or SRT bridge will implement
         this group."
     GROUP   dot1dTpGroup
     DESCRIPTION
         "Implementation of this group is mandatory for
         bridges that support the transparent bridging
         mode.  A transparent or SRT bridge will implement
         this group."
     GROUP   dot1dStaticGroup
     DESCRIPTION
         "Implementation of this group is optional."
     GROUP dot1dNotificationGroup
     DESCRIPTION
         "Implementation of this group is optional."
     ::= { dot1dCompliances 2 }
 END

Norseth & Bell, Eds. Standards Track [Page 38] RFC 4188 Bridge MIB September 2005

5. IANA Considerations

 The MIB module in this document uses the following IANA-assigned
 OBJECT IDENTIFIER values that are recorded in the SMI Numbers
 registry:
    Descriptor        OBJECT IDENTIFIER value
    ----------        -----------------------
    dot1dBridge       { mib-2 17 }

6. Security Considerations

 There are a number of management objects defined in this MIB module
 that have a MAX-ACCESS clause of read-write and/or read-create.  Such
 objects may be considered sensitive or vulnerable in some network
 environments.  The support for SET operations in a non-secure
 environment without proper protection can have a negative effect on
 network operations.
 Some of the readable objects in this MIB module (i.e., objects with a
 MAX-ACCESS other than not-accessible) may be considered sensitive or
 vulnerable in some network environments.  It is thus important to
 control even GET and/or NOTIFY access to these objects and possibly
 to even encrypt the values of these objects when sending them over
 the network via SNMP.
 These are the tables and objects and their sensitivity/vulnerability:
 o  The writable objects dot1dStpPriority, dot1dStpBridgeMaxAge,
    dot1dStpBridgeHelloTime, dot1dStpBridgeForwardDelay,
    dot1dStpPortPriority, dot1dStpPortEnable, dot1dStpPortPathCost,
    and dot1dStpPortPathCost32 influence the spanning tree protocol.
    Unauthorized write access to these objects can cause the spanning
    tree protocol to compute other default topologies or it can change
    the speed in which the spanning tree protocol reacts to failures.
 o  The writable object dot1dTpAgingTime controls how fast
    dynamically-learned forwarding information is aged out.  Setting
    this object to a large value may simplify forwarding table
    overflow attacks.
 o  The writable dot1dStaticTable provides a filtering mechanism
    controlling to which ports frames originating from a specific
    source may be forwarded.  Write access to this table can be used
    to turn provisioned filtering off or to add filters to prevent
    rightful use of the network.

Norseth & Bell, Eds. Standards Track [Page 39] RFC 4188 Bridge MIB September 2005

 o  The readable objects defined in the BRIDGE-MIB module provide
    information about the topology of a bridged network and the
    attached active stations.  The addresses listed in the
    dot1dTpFdbTable usually reveal information about the manufacturer
    of the MAC hardware, which can be useful information for mounting
    other specific attacks.
 o  The two notifications newRoot and topologyChange are emitted
    during spanning tree computation and may trigger management
    systems to inspect the status of bridges and to recompute internal
    topology information.  Hence, forged notifications may cause
    management systems to perform unnecessary computations and to
    generate additional SNMP traffic directed to the bridges in a
    network.  Therefore, forged notifications may be part of a denial
    of service attack.
 SNMP versions prior to SNMPv3 did not include adequate security.
 Even if the network itself is secure (for example by using IPSec),
 even then, there is no control as to who on the secure network is
 allowed to access and GET/SET (read/change/create/delete) the objects
 in this MIB module.
 It is RECOMMENDED that implementers consider the security features as
 provided by the SNMPv3 framework (see [RFC3410], section 8),
 including full support for the SNMPv3 cryptographic mechanisms (for
 authentication and privacy).
 Further, deployment of SNMP versions prior to SNMPv3 is NOT
 RECOMMENDED.  Instead, it is RECOMMENDED to deploy SNMPv3 and to
 enable cryptographic security.  It is then a customer/operator
 responsibility to ensure that the SNMP entity giving access to an
 instance of this MIB module is properly configured to give access to
 the objects only to those principals (users) that have legitimate
 rights to indeed GET or SET (change/create/delete) them.

7. Acknowledgements

 The MIB module presented in this memo is a translation of the
 BRIDGE-MIB defined in [RFC1493] to the SMIv2 syntax.  The original
 authors of the SMIv1 module were E. Decker, P. Langille, A.
 Rijsinghani, and K. McCloghrie.  Further acknowledgement is given to
 the members of the original Bridge Working Group in [RFC1493].
 This document was produced on behalf of the Bridge MIB Working Group
 in the Operations and Management area of the Internet Engineering
 Task Force.  The editors wish to thank the members of the Bridge MIB
 Working Group, especially Mike MacFadden, John Flick, and Bert
 Visscher for their many comments and suggestions that improved this

Norseth & Bell, Eds. Standards Track [Page 40] RFC 4188 Bridge MIB September 2005

 effort.  Juergen Schoenwaelder helped in finalizing the document for
 publication.

8. Contact Information

 The original version of this document was the result of significant
 work by four major contributors:
    E. Decker
    P. Langille
    A. Rijsinghan
    Accton Technology Corporation
    5 Mount Royal Ave
    Marlboro, MA 01752
    USA
    K. McCloghrie
    Cisco Systems, Inc.
    170 West Tasman Drive
    San Jose, CA 95134
    USA
 The conversion to the SMIv2 format is based on work done by the
 following two contributors:
    Kenyon C. Norseth
    L-3 Communications
    640 N. 2200 West
    Salt Lake City, Utah 84116-0850
    USA
    E. Bell
    3Com Europe Limited
    3Com Centre, Boundary Way
    Hemel Hempstead Herts. HP2 7YU
    UK

Norseth & Bell, Eds. Standards Track [Page 41] RFC 4188 Bridge MIB September 2005

9. Changes from RFC 1493

 The following changes have been made from RFC 1493.
 1. Translated the MIB definitions to use SMIv2.  This includes the
    introduction of conformance statements.  ASN.1 type definitions
    have been converted into textual-conventions and several UNITS
    clauses were added.
 2. The object dot1dStpPortPathCost32 was added to support IEEE
    802.1t.
 3. Permissible values for dot1dStpPriority and dot1dStpPortPriority
    have been clarified for bridges supporting IEEE 802.1t or IEEE
    802.1w.
 4. Interpretation of dot1dStpTimeSinceTopologyChange has been
    clarified for bridges supporting the rapid spanning tree protocol
    (RSTP).
 5. Updated the introductory boilerplate text, the security
    considerations section, and the references to comply with the
    current IETF standards and guidelines.
 6. Updated references to point to newer IEEE 802.1d documents.
 7. Additions and clarifications in various description clauses.

10. References

10.1 Normative References

 [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC 2119, March 1997.
 [RFC2578]   McCloghrie, K., Perkins, D., and J. Schoenwaelder,
             "Structure of Management Information Version 2 (SMIv2)",
             STD 58, RFC 2578, April 1999.
 [RFC2579]   McCloghrie, K., Perkins, D., and J. Schoenwaelder,
             "Textual Conventions for SMIv2", STD 58, RFC 2579, April
             1999.
 [RFC2580]   McCloghrie, K., Perkins, D., and J. Schoenwaelder,
             "Conformance Statements for SMIv2", STD 58, RFC 2580,
             April 1999.

Norseth & Bell, Eds. Standards Track [Page 42] RFC 4188 Bridge MIB September 2005

 [RFC3418]   Presuhn, R., "Management Information Base (MIB) for the
             Simple Network Management Protocol (SNMP)", STD 62, RFC
             3418, December 2002.
 [RFC2863]   McCloghrie, K. and F. Kastenholz, "The Interfaces Group
             MIB", RFC 2863, June 2000.
 [IEEE8021D] IEEE Project 802 Local and Metropolitan Area Networks,
             "ANSI/IEEE Standard 802.1D-1998 MAC Bridges", March 1998.

10.2 Informative References

 [RFC3410]   Case, J., Mundy, R., Partain, D., and B. Stewart,
             "Introduction and Applicability Statements for Internet-
             Standard Management Framework", RFC 3410, December 2002.
 [RFC1493]   Decker, E., Langille, P., Rijsinghani, A., and K.
             McCloghrie, "Definitions of Managed Objects for Bridges",
             RFC 1493, July 1993.
 [RFC1525]   Decker, E., McCloghrie, K., Langille, P., and A.
             Rijsinghani, "Definitions of Managed Objects for Source
             Routing Bridges", RFC 1525, September 1993.

Authors' Addresses

 Kenyon C. Norseth (editor)
 L-3 Communications
 640 N. 2200 West
 Salt Lake City, Utah 84116-0850
 USA
 Phone: +1 801-594-2809
 EMail: kenyon.c.norseth@L-3com.com
 E. Bell (editor)
 3Com Europe Limited
 3Com Centre, Boundary Way
 Hemel Hempstead Herts.  HP2 7YU
 UK
 Phone: +44 1442 438025
 EMail: elbell@ntlworld.com

Norseth & Bell, Eds. Standards Track [Page 43] RFC 4188 Bridge MIB September 2005

Full Copyright Statement

 Copyright (C) The Internet Society (2005).
 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 information 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.

Intellectual Property

 The IETF takes no position regarding the validity or scope of any
 Intellectual Property Rights or other rights that might be claimed to
 pertain to the implementation or use of the technology described in
 this document or the extent to which any license under such rights
 might or might not be available; nor does it represent that it has
 made any independent effort to identify any such rights.  Information
 on the procedures with respect to rights in RFC documents can be
 found in BCP 78 and BCP 79.
 Copies of IPR disclosures made to the IETF Secretariat and any
 assurances of licenses to be made available, or the result of an
 attempt made to obtain a general license or permission for the use of
 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
 copyrights, patents or patent applications, or other proprietary
 rights that may cover technology that may be required to implement
 this standard.  Please address the information to the IETF at ietf-
 ipr@ietf.org.

Acknowledgement

 Funding for the RFC Editor function is currently provided by the
 Internet Society.

Norseth & Bell, Eds. Standards Track [Page 44]

/data/webs/external/dokuwiki/data/pages/rfc/rfc4188.txt · Last modified: 2005/09/20 16:44 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki