RFC 1285

FDDI Management Information Base

📅 published January 1992, from ietf

RFC 1285: FDDI Management Information Base 💖

Okay bestie, this one is by J. Case from SNMP Research, Incorporated, dated January 1992 🌸. It's an IAB standards track thing, and it's an extension to the SNMP MIB. It doesn't obsolete anything and doesn't update anything either, so it's a clean fresh start ✨.

Status of This Memo 📜

This memo is an extension to the SNMP MIB. This RFC specifies an IAB standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol. Distribution of this memo is unlimited.

Table of Contents 🗂️

   1. Abstract ..............................................    1
   2. The Network Management Framework.......................    1
   3. Objects ...............................................    2
   3.1 Format of Definitions ................................    2
   4. Overview ..............................................    3
   4.1 Textual Conventions ..................................    3
   5. Object Definitions ....................................    4
   5.1 The SMT Group ........................................    5
   5.2 The MAC Group ........................................   15
   5.3 The PATH Group .......................................   27
   5.4 The PORT Group .......................................   27
   5.5 The ATTACHMENT Group .................................   38
   5.6 The Chip Set Group ...................................   42
   6. Acknowledgements ......................................   43
   7. References ............................................   45
   Security Considerations...................................   46
   Author's Address..........................................   46

1. 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 devices which implement the FDDI 🔥.

2. The Network Management Framework 🧚

Okay so the Internet-standard Network Management Framework is made of three components 👑:

RFC 1155 defines the SMI, the mechanisms used for describing and naming objects for the purpose of management. RFC 1212 defines a more concise description mechanism, which is wholly consistent with the SMI.
RFC 1156 defines MIB-I, the core set of managed objects for the Internet suite of protocols. RFC 1213, defines MIB-II, an evolution of MIB-I based on implementation experience and new operational requirements.
RFC 1157 defines the SNMP, the protocol used for network access to managed objects.

The Framework also permits new objects to be defined for the purpose of experimentation and evaluation 🌈.

3. Objects 🦋

Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the subset of Abstract Syntax Notation One (ASN.1) [5] defined in the SMI. In particular, each object has a name, a syntax, and an encoding. The name is an object identifier, an administratively assigned name, which specifies an object type. The object type together with an object instance serves to uniquely identify a specific instantiation of the object. For human convenience, we often use a textual string, termed the OBJECT DESCRIPTOR, to also refer to the object type.

The syntax of an object type defines the abstract data structure corresponding to that object type. The ASN.1 language is used for this purpose. However, the SMI [1] purposely restricts the ASN.1 constructs which may be used. These restrictions are explicitly made for simplicity.

The encoding of an object type is simply how that object type is represented using the object type's syntax. Implicitly tied to the notion of an object type's syntax and encoding is how the object type is represented when being transmitted on the network.

The SMI specifies the use of the basic encoding rules of ASN.1 [6], subject to the additional requirements imposed by the SNMP.

3.1. Format of Definitions 🎀

Section 5 contains contains the specification of all object types contained in this MIB module. The object types are defined using the conventions defined in the SMI, as amended by the extensions specified in [7].

4. Overview 🌸

This document defines the managed objects for FDDI devices which are to be accessible via the Simple Network Management Protocol (SNMP). At present, this applies to these values of the ifType variable in the Internet-standard MIB:

               fddi(15)

For these interfaces, the value of the ifSpecific variable in the MIB-II [4] has the OBJECT IDENTIFIER value:

               fddi    OBJECT IDENTIFIER ::= { transmission 15 }

The definitions of the objects presented here draws heavily from related work in the ANSI X3T9.5 committee and the SMT subcommittee of that committee [8]. In fact, the definitions of the managed objects in this document are, to the maximum extent possible, identical to those identified by the ANSI committee. The semantics of each managed object should be the same with syntactic changes made as necessary to recast the objects in terms of the Internet-standard SMI and MIB so as to be compatible with the SNMP. Examples of these syntactic changes include remapping booleans to enumerated integers, remapping bit strings to octet strings, and the like. In addition, the naming of the objects was changed to achieve compatibility.

These minimal syntactic changes with no semantic changes should allow implementations of SNMP manageable FDDI systems to share instrumentation with other network management schemes and thereby minimize implementation cost. In addition, the translation of information conveyed by managed objects from one network management scheme to another is eased by these shared definitions.

Only the essential variables, as indicated by their mandatory status in the ANSI specification were retained in this document. The importance of variables which have an optional status in the ANSI specification were perceived as being less widely accepted.

4.1. Textual Conventions 💅

Several new datatypes are introduced as a textual convention in this MIB document. These textual conventions enhance the readability of the document and ease comparisons with its ANSI counterpart. It should be noted that the introduction of the following textual conventions has no effect on either the syntax nor the semantics of any managed objects. The use of these is merely an artifact of the explanatory method used. Objects defined in terms of one of these methods are always encoded by means of the rules that define the primitive type. Hence, no changes to the SMI or the SNMP are necessary to accommodate these textual conventions which are adopted merely for the convenience of readers and writers in pursuit of the elusive goal of clear, concise, and unambiguous MIB documents.

5. Object Definitions 👑

Here's the actual MIB module, the part with all the object definitions 🫶. The module is written with the extended OBJECT-TYPE macro from [7]:

          RFC1285-MIB DEFINITIONS ::= BEGIN

          IMPORTS
                  Counter
                      FROM RFC1155-SMI
                  transmission
                      FROM RFC1213-MIB
                  OBJECT-TYPE
                      FROM RFC-1212;

          --  This MIB module uses the extended OBJECT-TYPE macro as
          --  defined in [7].


          -- this is the FDDI MIB module

          fddi    OBJECT IDENTIFIER ::= { transmission 15 }


          -- textual conventions

          FddiTime ::= INTEGER (0..2147483647)
          -- This data type specifies octet units of 80 nanoseconds as
          -- an integer value.  It is used for Path Latency  and
          -- Synchronous Bandwidth values.  The encoding is normal
          -- integer representation (not twos complement).

          FddiResourceId ::= INTEGER (0..65535)
          -- This data type is used to refer to an instance of a  MAC,
          -- PORT, PATH, or ATTACHMENT Resource ID.  Indexing begins
          -- at 1.  Zero is used to indicate the absence of a resource.

          FddiSMTStationIdType ::= OCTET STRING (SIZE (8))
          -- The unique identifier for the FDDI station.  This is a
          -- string of 8 octets, represented as
          --                                X' yy yy xx xx xx xx xx xx'
          -- with the low order 6 octet (xx) from a unique IEEE
          -- assigned address.  The high order two bits of the IEEE
          -- address, the group address bit and the administration bit
          -- (Universal/Local) bit should both be zero.  The first two
          -- octets, the yy octets, are implementor-defined.
          --
          -- The representation of the address portion of the station id
          -- is in the IEEE (ANSI/IEEE P802.1A) canonical notation for
          -- 48 bit addresses.  The canonical form is a 6-octet string
          -- where the first octet contains the first 8 bits of the
          -- address, with the I/G(Individual/Group) address bit as the
          -- least significant bit and the  U/L (Universal/Local) bit
          -- as the next more significant bit, and so on.  Note that
          -- addresses in the ANSI FDDI standard SMT frames are
          -- represented in FDDI MAC order.

          FddiMACLongAddressType ::= OCTET STRING (SIZE (6))
          -- The representation of long MAC addresses as management
          -- values is in the IEEE (ANSI/IEEE P802.1A) canonical
          -- notation for 48 bit addresses.  The canonical form is a
          -- 6-octet string where the first octet contains the first 8
          -- bits of the address, with the I/G (Individual/Group)
          -- address bit as the least significant bit and the  U/L
          -- (Universal/Local) bit as the next more significant bit,
          -- and so on.  Note that the addresses in the SMT frames are
          -- represented in FDDI MAC order.

          -- groups in the FDDI MIB module

          snmpFddiSMT        OBJECT IDENTIFIER ::= { fddi 1 }

          snmpFddiMAC        OBJECT IDENTIFIER ::= { fddi 2 }

          snmpFddiPATH       OBJECT IDENTIFIER ::= { fddi 3 }

          snmpFddiPORT       OBJECT IDENTIFIER ::= { fddi 4 }

          snmpFddiATTACHMENT OBJECT IDENTIFIER ::= { fddi 5 }

          snmpFddiChipSets    OBJECT IDENTIFIER ::= { fddi 6 }

5.1. The SMT Group 🦋

Okay the SMT group is the first one, and it's mandatory for every system that implements a manageable FDDI subsystem 💖. Here are its first two objects:

          -- the SMT group
          -- Implementation of the SMT group is mandatory for all
          -- systems which implement manageable FDDI subsystems.

          snmpFddiSMTNumber OBJECT-TYPE
              SYNTAX  INTEGER (0..65535)
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION

                      "The number of SMT implementations (regardless of
                      their current state) on this network management
                      application entity.  The value for this variable
                      must remain constant at least from one re-
                      initialization of the entity's network management
                      system to the next re-initialization."
              ::= { snmpFddiSMT  1 }


          -- the SMT table

          snmpFddiSMTTable OBJECT-TYPE
              SYNTAX  SEQUENCE OF SnmpFddiSMTEntry
              ACCESS  not-accessible
              STATUS  mandatory
              DESCRIPTION
                      "A list of SMT entries.  The number of entries is
                      given by  the value of snmpFddiSMTNumber."
              ::= { snmpFddiSMT  2 }