Internet Engineering Task Force A. Smith INTERNET-DRAFT Extreme Networks Expires December 2000 June 2000 draft-smith-bridge-qosmib-00.txt Management Information Base for QoS Extensions for Bridges based on the Differentiated Services Architecture Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. 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 and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright (C) The Internet Society (2000). All Rights Reserved. Distribution of this memo is unlimited. Abstract This memo describes a SMIv2 MIB module for a device implementing bridging functions with Quality-of-Service mechanisms similar to those described for the Differentiated Services Architecture [DSARCH] which are described in detail by the Differentiated Services Router Conceptual Model [MODEL]. A MIB module for routers, the Diffserv MIB [DSMIB], has been developed that uses this model. The MIB module defined in this memo is designed to work in conjunction with that module: it defines usage for objects in that module and defines some new objects specific to MAC- layer bridges (a.k.a. Layer-2 switches). Specifically, if defines layer-2 classifier and packet marking functionality. Smith Expires December 2000 [Page 1] Internet Draft Bridge QoS MIB June 2000 1. The SNMP Management Framework The SNMP Management Framework presently consists of five major components: o An overall architecture, described in RFC 2571 [1]. 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 RFC 1155 [2], RFC 1212 [3] and RFC 1215 [4]. The second version, called SMIv2, is described in RFC 2578 [5], RFC 2579 [6] and RFC 2580 [7]. o Message protocols for transferring management information. The first version of the SNMP message protocol is called SNMPv1 and described in RFC 1157 [8]. A second version of the SNMP message protocol, which is not an Internet standards track protocol, is called SNMPv2c and described in RFC 1901 [9] and RFC 1906 [10]. The third version of the message protocol is called SNMPv3 and described in RFC 1906 [10], RFC 2572 [11] and RFC 2574 [12]. o Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats is described in RFC 1157 [8]. A second set of protocol operations and associated PDU formats is described in RFC 1905 [13]. o A set of fundamental applications described in RFC 2573 [14] and the view-based access control mechanism described in RFC 2575 [15]. A more detailed introduction to the current SNMP Management Framework can be found in RFC 2570 [16]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the mechanisms defined in the SMI. This memo specifies a MIB module that is compliant to the SMIv2. A MIB conforming to the SMIv1 can be produced through the appropriate translations. The resulting translated MIB must be semantically equivalent, except where objects or events are omitted because no translation is possible (use of Counter64). Some machine-readable information in SMIv2 will be converted into textual descriptions in SMIv1 during the translation process. However, this loss of machine readable information is not considered to change the semantics of the MIB. Smith Expires December 2000 [Page 2] Internet Draft Bridge QoS MIB June 2000 2. Structure of this MIB This MIB module is consistent with the Conceptual Model (for Diffserv routers) documented in [MODEL] and is designed to work in conjunction with the Differentiated Services MIB [DSMIB]. That MIB defines a basic structure for the QoS components of generalised "packet routers", as well as specific objects for representing IP- and some higher-layer constructs. The Conceptual Model and Diffserv MIB structures are general enough to represent the QoS components of the current generation of multi-layer switches which often incorporate both layer-3 and layer-2 functionality e.g. they are a combination of the traditional IP router and MAC bridge. Such devices, therefore, fit well with this conceptual model. 2.1. Overview The Conceptual Model discusses how ingress and egress interfaces of an 'n'-port router are to be modelled in the same way as each other. This is derived from the requirement, in general, to be able to perform the same traffic conditioning functions on individual ingress interfaces (e.g. from a particular location/customer/machine) as on egress interfaces (e.g. to a particular location/customer/machine). This model is shown in Figure 1 which is taken from [MODEL]. Each interface then performs the following high-level functions in each Interface A Interface B +-------------+ +---------+ +-------------+ | ingress i/f | | | | egress i/f | | classify, | | | | classify, | --->| meter, |---->| |---->| meter, |---> | action, | | | | action, | | queueing | | | | queueing | +-------------+ | routing | +-------------+ | core | +-------------+ | | +-------------+ | egress i/f | | | | ingress i/f | | classify, | | | | classify, | <---| meter, |<----| |<----| meter, |<--- | action, | | | | action, | | queueing | +---------+ | queueing | +-------------+ +-------------+ Figure 1. Traffic Conditioning and Queueing Elements Smith Expires December 2000 [Page 3] Internet Draft Bridge QoS MIB June 2000 direction: o Classify each packet according to some set of rules o Determine whether the data stream the packet is part of is within or outside its rate o Perform a set of resulting actions, possibly including counting the traffic, application of an appropriate drop policy and marking of the traffic in some way. o Enqueue the traffic for output in the appropriate queue, whose scheduler may shape the traffic or simply forward it with some minimum rate or maximum latency. Note that any of these operations may be a no-op or use default settings in a particular implementation. Thus, a standard 802.1D-1998 bridge [802.1D] can be modelled as in Figure 2 where the term ".1p" or "802.1p" is used to represent the user_priority value used to identify traffic classes both on the wire as a 3-bit user_priority packet field, often known as the "802.1p priority bits", as well as within the 802.1D bridge architecture (as an internal parameter). Interface A Interface B +-------------+ +---------+ +-------------+ | ingress i/f | | | | egress i/f | | - classify | | | | - priority | --->| using .1p |---->| |---->| queuing |---> | priority, | | | | | | - mark .1p | | | | | +-------------+ |bridging | +-------------+ | core | +-------------+ | | +-------------+ | egress i/f | | | | ingress i/f | | - priority | | | | - classify | <---| queuing |<----| |<----| using .1p |<--- | | | | | priority, | | | +---------+ | - mark .1p | +-------------+ +-------------+ Figure 2. QoS Elements of a 802.1D Bridge Smith Expires December 2000 [Page 4] Internet Draft Bridge QoS MIB June 2000 In addition, this MIB also supports the concept of "QoS classification by VLAN" where appropriate local QoS treatment is applied based on the IEEE 802.1Q VLAN with which a given packet is associated - this may be either a direct classification of the packet based on a 802.1Q VLAN-ID field present in the packet or else it may be the VLAN to which the packet has been assigned, based on IEEE 802.1Q ingress VLAN classification rules. See [802.1Q] for further details of this process: [BRIDGEMIB] uses the same concepts and, in fact, the present MIB borrows indexing variables from that MIB. This MIB, therefore, adds to the contents of [DSMIB] as follows: Classifier and Filter Tables A user_priority classifier element table, dot1dQosUserPriTable, and an 802.1Q VLAN classifier element table, dot1dQosVlanClfrTable. Each of these table's elements are intended to be pointed at by diffServClassifierFilter pointers in diffServClassifierTable entries. Meter Tables No additions are required here - the meters in the Diffserv MIB are defined in a layer-neutral way that can be used for MAC-layer bridges. Action Tables Absolute Drop and Count actions are sufficiently defined in Diffserv MIB. For Markers, a user_priority Marker element can be achieved by re-using entries in dot1dQosUserPriTable: these are intended also to be pointed at by diffServActionSpecific pointers of entries in diffServActionTable. Queue, Scheduler and Algorithmic Dropper Tables No additions are required here - the Queue, Scheduler and Algorithmic Dropper Table are all defined in a layer-neutral way. They offer a superset of the default queuing behaviours defined by IEEE 802.1D-1998. 2.2. MIB Representation of 802.1D Bridge Figure 3 illustrates how the basic functions of a 802.1D bridge implementing priority queuing on 2 queues on each of 2 ports, numbered as ports 1 and 2, are represented in the structures of the Diffserv MIB and this MIB. The diagram shows just one half of the structures representing the bridge (just one "direction" of traffic flow through the bridge). Note that most of the elements of the Diffserv MIB are indexed by a tuple of {ifIndex, direction, uniqueid}. In addition, classifier elements include a "level" index as well. Smith Expires December 2000 [Page 5] Internet Draft Bridge QoS MIB June 2000 The 802.1D user_priority classifier is represented here by pointers into dot1dQosUserPriTable which is indexed by the user_priority value itself. This table is statically populated with the 8 values. Note that IEEE 802.1D has no concept of re-marking of packets that are already marked with a user_priority value. The "user priority regeneration" functions of 802.1D are outside the scope of this memo - they are assumed to have occured prior to the classifier stage described here i.e. packets that did not have an incoming user_priority marking have one assigned to them before they are passed to the classifier described here (this process may be managed using the MIB objects already defined in [BRIDGEMIB]). There are no additional functional elements on the ingress side of a standard 802.1D bridge. On the egress side, there are no classification, meter or action elements (counter action elements are omitted in this discussion for clarity - the standard only defines these on a per-interface basis, not per-traffic-class so they are of marginal use in QoS monitoring). Queueing elements are limited to FIFO queues, possibly preceded by an Algorithmic Dropper implementing a tail-drop algorithm - the standard is silent on this behaviour and, according to the 802.1D defaults, a strict priority scheduler between the traffic classes. 2.3. MIB Representation of More Complex Bridge Many devices exist that perform a superset of the QoS functions of a standard IEEE 802.1D bridge. The additional capabilities are often of a similar form to the capabilities of Diffserv routers [MODEL] and these devices are often deployed in situations similar to traditional routers e.g. service-provider networks, where similar functions to Diffserv routers are required. It is advantageous to be able to use the same management tools to control and monitor such devices. Additional capabilities that such devices may offer include, but are not limited to: (o) The capability of more complex Scheduler behaviours than the basic strict-priority scheduler which is the default behaviour defined in 802.1D. Examples might include weighted round-robin or non-work- conserving schedulers that can apply limits on the bandwidth allowed to a given traffic class. o Metering capabilities on its input ports in order to apply rate- limiting and policing. o user_priority (re-)marking capabilities, either static or else based on metering results. Smith Expires December 2000 [Page 6] Internet Draft Bridge QoS MIB June 2000 +-----------------+ --->|Next -------------+ |Prec=1 | | |Filt=dot1dPri.0 | | +-----------------+ | Class.1.In.1.1 | | +-----------------+ | --->|Next -------------+ |Prec=1 | | |Filt=dot1dPri.1 | | +-----------------+ | Class.1.In.1.2 | | +-----------------+ | --->|Next -------------+ |Prec=1 | | |Filt=dot1dPri.2 | | +-----------------+ | Class.1.In.1.3 | | +----------+ +-----------------+ +--->|Next ------+ --->|Next -------------+ |Min=none | | |Prec=1 | |Max=none | | |Filt=dot1dPri.3 | |Pri=1 | | +-----------------+ |Type=fifo | | +---------+ Class.1.In.1.4 +----------+ +--->|Next -------> Queue.2.Out.1 | |Alg=pri | +-----------------+ | +---------+ --->|Next -------------+ +----------+ | Scheduler.2.1 |Prec=1 | +--->|Next ------+ |Filt=dot1dPri.4 | | |Min=none | +-----------------+ | |Max=none | Class.1.In.1.5 | |Pri=2 | | |Type=fifo | +-----------------+ | +----------+ --->|Next -------------+ Queue.2.Out.2 |Prec=1 | | |Filt=dot1dPri.5 | | +-----------------+ | Class.1.In.1.6 | | +-----------------+ | --->|Next -------------+ |Prec=1 | | |Filt=dot1dPri.6 | | Smith Expires December 2000 [Page 7] Internet Draft Bridge QoS MIB June 2000 +-----------------+ | Class.1.In.1.7 | | +-----------------+ | --->|Next -------------+ |Prec=1 | |Filt=dot1dPri.7 | +-----------------+ Class.1.In.1.8 Figure 3: Example Use of this MIB for a Basic 802.1D Bridge o user_priority (re-)marking capabilities based on higher-layer classification e.g. DSCP. Such capabilities may be easily modelled by the Diffserv MIB without further additions. 3. Editorial information 3.1. Open issues (1) Should this MIB use user_priority with masks instead of a flat list of 8 read-only values? This would require read-write capability on the table. (NO). (2) Should this MIB use VlanIndex with masks or ranges instead of a list of individual values? This would be more complex but could be more efficient for scenarios where ranges of VLAN-ID were meaningful. (NO). Smith Expires December 2000 [Page 8] Internet Draft Bridge QoS MIB June 2000 4. MIB Definition QOS-BRIDGE-MIB DEFINITIONS ::= BEGIN IMPORTS OBJECT-TYPE, MODULE-IDENTITY, mib-2 FROM SNMPv2-SMI TEXTUAL-CONVENTION, RowStatus FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF dot1qVlanIndex FROM Q-BRIDGE-MIB; dot1dQosMib MODULE-IDENTITY LAST-UPDATED "200006070000Z" ORGANIZATION "Extreme Networks" CONTACT-INFO " Andrew Smith (author) Extreme Networks 3585 Monroe St. Santa Clara, CA 95051, USA E-mail: andrew@extremenetworks.com" DESCRIPTION "This MIB defines the additional objects necessary to manage the Quality-of-Service aspects of a bridge device that uses the IETF's Differentiated Services Architecture described in RFC 2475 and the Conceptual Model for DiffServ Routers in draft-ietf- diffserv-model-03.txt. It is to be used in conjunction with the Diffserv MIB described in draft-ietf-diffserv-mib-03.txt." REVISION "200006070000Z" DESCRIPTION "Initial version, published as RFC xxxx." ::= { mib-2 12346 } -- anybody who uses this unassigned -- number deserves the wrath of IANA dot1dQosObjects OBJECT IDENTIFIER ::= { dot1dQosMib 1 } dot1dQosTables OBJECT IDENTIFIER ::= { dot1dQosMib 2 } dot1dQosMIBConformance OBJECT IDENTIFIER ::= { dot1dQosMib 3 } -- These textual conventions have no effect on either the syntax -- nor the semantics of any managed object. Objects defined -- using this convention are always encoded by means of the -- rules that define their primitive type. Smith Expires December 2000 [Page 9] Internet Draft Bridge QoS MIB June 2000 Dot1dUserPri ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "The IEEE 802.1 user_priority that may be used for discriminating or marking a traffic stream." SYNTAX INTEGER (0..7) -- -- IEEE 802.1D user_priority Table -- dot1dQosUserPriTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot1dQosUserPriEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of user_priority entries that each signifies a traffic class in 802.1D bridges. All entries exist in this table at all times. Its entries may be used as destinations for diffServClassifierFilter pointers for traffic classification purposes and for diffServActionSpecific pointers for traffic marking purposes." REFERENCE "[MODEL] section 4.2.4" ::= { dot1dQosTables 1 } dot1dQosUserPriEntry OBJECT-TYPE SYNTAX Dot1dQosUserPriEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry that describes a single 802.1D user_priority filter." INDEX { dot1dQosUserPri } ::= { dot1dQosUserPriTable 1 } Dot1dQosUserPriEntry ::= SEQUENCE { dot1dQosUserPri Dot1dUserPri } dot1dQosUserPri OBJECT-TYPE SYNTAX Dot1dUserPri MAX-ACCESS read-only STATUS current DESCRIPTION "A user_priority value for the filter. Filters may be shared by multiple interfaces in the same system." Smith Expires December 2000 [Page 10] Internet Draft Bridge QoS MIB June 2000 ::= { dot1dQosUserPriEntry 1 } -- -- IEEE 802.1Q Vlan Classification Table -- dot1dQosVlanClfrTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot1dQosVlanClfrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of VLAN entries for use in QoS classification in bridges. Its entries may be used as destinations for diffServClassifierFilter pointers for traffic classification purposes." REFERENCE "[MODEL] section 4.2.4, [BRIDGEMIB] dot1qVlanCurrentTable." ::= { dot1dQosTables 2 } dot1dQosVlanClfrEntry OBJECT-TYPE SYNTAX Dot1dQosVlanClfrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry that describes a classifier element for a single 802.1Q VLAN." INDEX { dot1qVlanIndex } ::= { dot1dQosVlanClfrTable 1 } Dot1dQosVlanClfrEntry ::= SEQUENCE { dot1dQosVlanStatus RowStatus } dot1dQosVlanStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The RowStatus variable controls the activation, deactivation, or deletion of a filter for a VLAN for use in QoS classification. Note that, even though this table is indexed by dot1qVlanIndex, this does not imply that there must be an equivalent entry in either dot1qVlanCurrentTable or dot1qVlanStaticTable." ::= { dot1dQosVlanClfrEntry 1 } Smith Expires December 2000 [Page 11] Internet Draft Bridge QoS MIB June 2000 -- -- Usage of this MIB module in conjunction with the Diffserv MIB. -- -- Classifiers - this MIB defines two new classifier filter -- element types: -- -- - to compare the IEEE 802.1D user_priority value -- from a packet. Classifier elements are each one of the -- entries from dot1dQosUserPriTable and may be pointed to -- by diffServClassifierFilter values. -- -- - to compare the IEEE 802.1Q VLAN with which a packet is -- associated. Note that this classification is considered -- to take place on all packets that pass through this -- particular element regardless of their incoming or outgoing -- tagged/untagged status: i.e. the QoS classifier is considered -- to take place "after" the IEEE 802.1Q VLAN ingress rules have -- been applied. Therefore, the VLAN identifier implied is the -- one which the Bridge MIB considers to be attached to each -- packet. Such classifier filter elements are each one of the -- entries from dot1dQosVlanClfrTable and may be pointed to by -- diffServClassifierFilter values. -- -- Meters - this MIB includes no new definitions or usage for Meters. -- -- Actions - this MIB includes no new definitions for Actions. -- -- A Marker action, to mark packets with an 802.1D user_priority -- value, may be defined by creating a diffServActionEntry -- which has a diffServActionSpecific pointing at one of the -- entries in dot1dQosUserPriTable. Note that this remarking -- action, which is considered to take place for all packets that -- pass through this particular element regardless of their -- incoming or outgoing tagged/untagges status, is not one that is -- supported by the standard IEEE 802.1D model. -- -- Note that remarking with a VLAN-ID is not considered to be a -- QoS action - facilities for handling VLAN-ID tags in -- accordance with IEEE 802.1Q are provided in the Bridge MIB -- [BRIDGEMIB]. -- -- Queues, Algorithmic Droppers and Schedulers - this MIB includes no -- new definitions or usage for these elements. -- Smith Expires December 2000 [Page 12] Internet Draft Bridge QoS MIB June 2000 -- -- MIB Compliance statements. -- dot1dQosMIBCompliances OBJECT IDENTIFIER ::= { dot1dQosMIBConformance 1 } dot1dQosMIBGroups OBJECT IDENTIFIER ::= { dot1dQosMIBConformance 2 } dot1dQosMIBCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "This MIB may be implemented as a read-only or as a read-create MIB." MODULE -- This Module MANDATORY-GROUPS { dot1dQosMIBUserPriGroup } GROUP dot1dQosMIBVlanGroup DESCRIPTION "This group is mandatory for devices that implement QoS classification based upon VLAN assignment." OBJECT dot1dQosVlanStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." ::= { dot1dQosMIBCompliances 1 } dot1dQosMIBUserPriGroup OBJECT-GROUP OBJECTS { dot1dQosUserPri } STATUS current DESCRIPTION "The user_priority Group defines the MIB Objects that represent 802.1D user_priority values and describe a table of entries that may be used as destinations for diffServClassifierFilter and diffServActionSpecific pointers." ::= { dot1dQosMIBGroups 1 } dot1dQosMIBVlanGroup OBJECT-GROUP OBJECTS { dot1dQosVlanStatus } STATUS current DESCRIPTION "The VLAN Group defines the MIB Objects that represent VLANs and describe a table of entries that may be used as destinations for diffServClassifierFilter pointers." ::= { dot1dQosMIBGroups 2 } Smith Expires December 2000 [Page 13] Internet Draft Bridge QoS MIB June 2000 END 5. Security Considerations It is clear that this MIB is potentially useful for configuration, and anything that can be configured can be misconfigured, with potentially disastrous effect. At this writing, no security holes have been identified beyond those that SNMP Security is itself intended to address. These relate primarily to controlled access to sensitive information and the ability to configure a device - or which might result from operator error, which is beyond the scope of any security architecture. 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 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. The use of SNMP Version 3 is recommended over prior versions for configuration control as its security model is improved. There are a number of managed objects in this MIB that may contain information that may be sensitive from a business perspective, in that they may represent a customer's service contract or the filters that the service provider chooses to apply to a customer's ingress or egress traffic. There are no objects which are sensitive in their own right, such as passwords or monetary amounts. It may be important to control even GET access to these objects and possibly to even encrypt the values of these object when sending them over the network via SNMP. Not all versions of SNMP provide features for such a secure environment. 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 control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB. It is recommended that the implementers consider the security features as provided by the SNMPv3 framework. Specifically, the use of the User- based Security Model [12] and the View-based Access Control Model [15] is recommended. It is then a customer/user responsibility to ensure that the SNMP entity giving access to an instance of this MIB, is properly configured to give Smith Expires December 2000 [Page 14] Internet Draft Bridge QoS MIB June 2000 access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. 6. References [1] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", RFC 2571, Cabletron Systems, Inc., BMC Software, Inc., IBM T. J. Watson Research, April 1999 [2] Rose, M., and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", RFC 1155, STD 16, Performance Systems International, Hughes LAN Systems, May 1990 [3] Rose, M., and K. McCloghrie, "Concise MIB Definitions", RFC 1212, STD 16, Performance Systems International, Hughes LAN Systems, March 1991 [4] M. Rose, "A Convention for Defining Traps for use with the SNMP", RFC 1215, Performance Systems International, March 1991 [5] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", RFC 2578, STD 58, Cisco Systems, SNMPinfo, TU Braunschweig, SNMP Research, First Virtual Holdings, International Network Services, April 1999 [6] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Textual Conventions for SMIv2", RFC 2579, STD 58, Cisco Systems, SNMPinfo, TU Braunschweig, SNMP Research, First Virtual Holdings, International Network Services, April 1999 [7] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Conformance Statements for SMIv2", RFC 2580, STD 58, Cisco Systems, SNMPinfo, TU Braunschweig, SNMP Research, First Virtual Holdings, International Network Services, April 1999 [8] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network Management Protocol", RFC 1157, STD 15, SNMP Research, Performance Systems International, Performance Systems International, MIT Laboratory for Computer Science, May 1990. [9] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, SNMP Research, Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., International Network Services, January 1996. Smith Expires December 2000 [Page 15] Internet Draft Bridge QoS MIB June 2000 [10] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1906, SNMP Research, Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., International Network Services, January 1996. [11] Case, J., Harrington D., Presuhn R., and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2572, SNMP Research, Inc., Cabletron Systems, Inc., BMC Software, Inc., IBM T. J. Watson Research, April 1999 [12] Blumenthal, U., and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2574, IBM T. J. Watson Research, April 1999 [13] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1905, SNMP Research, Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., International Network Services, January 1996. [14] Levi, D., Meyer, P., and B. Stewart, "SNMPv3 Applications", RFC 2573, SNMP Research, Inc., Secure Computing Corporation, Cisco Systems, April 1999 [15] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC 2575, IBM T. J. Watson Research, BMC Software, Inc., Cisco Systems, Inc., April 1999 [16] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction to Version 3 of the Internet-standard Network Management Framework", RFC 2570, SNMP Research, Inc., TIS Labs at Network Associates, Inc., Ericsson, Cisco Systems, April 1999 [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 Metropolitan Area Networks: Virtual Bridged Local Area Networks", 1998. Smith Expires December 2000 [Page 16] Internet Draft Bridge QoS MIB June 2000 [BRIDGEMIB] E. Bell, A. Smith, P. Langille, A. Rijsinghani, K. McCloghrie, "Definitions of Managed Objects for Bridges with Traffic Classes, Multicast Filtering and Virtual LAN Extensions", RFC 2674, August 1999. [DSARCH] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, W. Weiss, "An Architecture for Differentiated Service", RFC 2475, December 1998. [DSMIB] F. Baker, A. Smith, K. Chan, "Differentiated Services MIB", Internet Draft , May 2000. [IFMIB] K. McCloghrie, F. Kastenholz, "The Interfaces Group MIB using SMIv2", RFC 2233, November 1997. [MODEL] Y. Bernet, S. Blake, A. Smith, D. Grossman, "A Conceptual Model for Diffserv Routers", Internet Draft , May 2000. [ORIGBRIDGEMIB] Decker, E., Langille, P., Rijsinghani, A. and K. McCloghrie, "Definitions of Managed Objects for Bridges", RFC 1493, July 1993. 7. Authors' Addresses Andrew Smith Extreme Networks 3585 Monroe Street Santa Clara, CA 95051 USA andrew@extremenetworks.com Table of Contents 1 The SNMP Management Framework ................................... 2 2 Structure of this MIB ........................................... 3 2.1 Overview ...................................................... 3 2.2 MIB Representation of 802.1D Bridge ........................... 5 2.3 MIB Representation of More Complex Bridge ..................... 6 Smith Expires December 2000 [Page 17] Internet Draft Bridge QoS MIB June 2000 3 Editorial information ........................................... 8 3.1 Open issues ................................................... 8 4 MIB Definition .................................................. 9 5 Security Considerations ......................................... 14 6 References ...................................................... 15 7 Authors' Addresses .............................................. 17 Smith Expires December 2000 [Page 18] Internet Draft Bridge QoS MIB June 2000 8. Full Copyright Copyright (C) The Internet Society (2000). 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 implmentation 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 revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. Smith Expires December 2000 [Page 19]