Network Working Group                                        N. Schaller
Request for Comments: nnnn                                       LDV TUM
Category: Experimental                                     25 April 1995


                    The Meta-Management MIB (SNMPv1)
                   Network Topology and Set of Agents

Status of this Memo

   This memo defines an Experimental MIB for the Internet community.
   This memo does not specify an Internet standard of any kind.
   Discussion and suggestions for improvement are requested.
   Distribution of this memo is unlimited.

Keywords

   Autodiscovery, Configuration, Components, Connections, Domains,
   Hierarchy, MIB, Set of Agents, SNMP, Topology

Table of Contents

   Introduction ....................................................   2
   1. Motivation ...................................................   2
   2. Overview .....................................................   2
   2.1 Networks and Network Management .............................   2
   2.2 Domains and the DNS .........................................   3
   2.3 Topology ....................................................   5
   2.4 Set of Agents ...............................................   5
   2.5 The Meta-MIB objects ........................................   5
   2.5.1 Components ................................................   6
   2.5.2 Component types ...........................................   7
   2.5.3 Ports .....................................................   7
   2.5.4 Connections ...............................................   7
   2.5.5 Agents ....................................................   7
   2.6 Operation ...................................................   8
   2.6.1 Using the Meta-MIB ........................................   8
   2.6.2 Autodiscovery .............................................   8
   2.6.3 Distributed Meta-MIBs to connect domains ..................   9
   2.6.4 Component and port addressing scheme ......................   9
   3. Definitions ..................................................  11
   4. Security Considerations ......................................  22
   5. References ...................................................  22
   6. Author's Address .............................................  23







Schaller                                                        [Page 1]





RFC nnnn                The Meta-Management MIB            25 April 1995


Introduction

   This memo describes an experimental portion of the Management
   Information Base (MIB) for use in the network management protocols in
   the Internet community.  In particular, it defines objects for
   managing the physical network topology and the set of agents allowing
   the management of the complete management system.  The design and
   definition is currently limited to the Internet-standard Network
   Management Framework SNMP version 1 ([RFC-1155, RFC-1156, RFC-1157,
   RFC-1212]).  The extension to SNMP version 2 ([RFC-1442, RFC-1445,
   RFC-1448, others]) has to be studied.  This memo also includes a MIB
   module.

1. Motivation

   Within the WILMA project at Lehrstuhl fuer Datenverarbeitung,
   Technical University of Munich, we have studied Internet Management.
   While trying to map the internet management functions onto the
   functional areas of OSI management (fault, configuration, accounting,
   performance, security), we observed, that configuration management in
   the Internet is limited to interface and component management. But
   the interactions between components, interfaces and cables, i.e. the
   physical topology, isn't managed at all or by proprietary methods.
   Although there are powerful autodiscovery tools available within
   management platforms, they use tricky protocol analysis and reasoning
   on logical information found in routing tables to provide a picture
   of the network.

   Because we thought, that this information must be provided to
   managers in a standardized form by the network itself, we began to
   develop a Configuration-MIB that stores the configuration of a local
   area network and provides information missing in other MIBs.  A
   configuration monitor displays this information in a neat layout and
   allows the user to issue manual change commands.

   By redesigning this Configuration-MIB and stripping off all
   component-related configuration information, the basis for the Meta-
   MIB was laid. The next step was to extend the design to cover not
   only a single local area network, but connected domains, and as a
   result a whole Internet of any size.

   Now, we view the Meta-MIB as a central starting point for retrieving
   management information of a local or remote domain. This allows to
   use a single Meta-MIB for the automatical configuration of different,
   cooperating management applications removing the burden of editing
   and checking consistency of individual configuration files.

   This memo is intended to stimulate discussion and further development



Schaller                                                        [Page 2]





RFC nnnn                The Meta-Management MIB            25 April 1995


   for a Proposed Standard Protocol.  Some conecepts underlying the
   Meta-MIB have been described in [Scha 95].  A demo agent is available
   for some UNIX platforms (see section 6).

2. Overview

2.1 Networks and Network Management

   Internetworks are built from local area networks by using a layer 3
   network protocol like IP.  Routers connect several local area
   networks by directing received IP datagrams over known links to the
   desired destination.  These local area networks consist of a small
   number of hosts and interconnection hardware (bridges).

   These networks, wide area and local area, are managed by using a
   management system that is usually compatible to the Internet Network
   Management Framework.  This consists of the definition of structure
   for management information, management information bases and
   management protocols.

   Components within the Internet are managed by using the protocol SNMP
   over UDP/IP to access the management information base (MIB) of the
   agent processes running in the components.  Management information
   usually covers configuration information and operation statistics
   about the processes running in the component to be managed.  There
   are many general and vendor specific MIBs defined for the components
   already in use.

   But there is no MIB for the configuration of the network as a whole
   system.  So, a new MIB, the Meta-MIB is developed with the following
   design goals:

      - it must fit within the existing MIBs,
      - it should work with forthcoming and most future MIBs,
      - it must be universal enough to describe configurations
        of any size and with any component,
      - it must support decentralized management.


2.2 Domains and the DNS

   It is obviously impractical to manage a wide area network like the
   Internet with millions of physical components in a single management
   system.  Because of this, we adopt the well known concept of domains.
   A domain is a certain area of responsibility for components and is
   described by the set of components and its border to 'the outside
   world' as shown in Fig. 1.




Schaller                                                        [Page 3]





RFC nnnn                The Meta-Management MIB            25 April 1995


    outside      *************
    world    \ **             ***
             *\  +---+           **
            *  \-O A |             *
           *     +-O-+     +---+    *
           *       |     /-O C |    *
           *     +-O-+  /  +---+    *
            *  /-O B O-/           *
             */  +---+    local   *
             / **         domain *
                 ****************

      Fig. 1  Components and Domains

   In this example, the local domain contains the components A, B, and
   C, that are connected to the outside world.

   Domains may be connected or can contain other domains (subdomains)
   and may be members of superdomains.  This allows to build hierarchies
   of domains, so that A, B, or C can represent a whole domain itself
   instead of a component.

   The concept of domains is already used in the Internet in the Domain
   Name System (DNS) [RFC-1034, RFC-1035] for the resolution of host
   names in readable notation into machine addresses (dotted address)
   and other purposes like mapping mailboxes.  In essence, the DNS is a
   distributed database for ressource names, consisting of Domain Name
   Servers and Domain Name Resolvers.  There are MIBs defined for
   managing both of them [RFC-1611, RFC-1612].

   The Meta-MIB approach tries to imitate this for Internet Management.
   This is achieved by assigning a Meta-MIB agent (server) to each
   domain and storing enough information in the Meta-MIBs to allow
   following links from one domain to the other.  A manager can resolve,
   beginning at a well known Meta-MIB, all the links until the desired
   managed node is found. This is described in more detail in section
   2.6.3.

   Note, that this general procedure is not restricted to containment
   hierarchies of domains but can be used for any relation between
   domains.  The introduction of hierarchies is not required technically
   in this case, but makes life easier since organizations are usually
   of hierarchical structure.








Schaller                                                        [Page 4]





RFC nnnn                The Meta-Management MIB            25 April 1995


2.3 Topology

   A network is built up of physical components (called nodes) and
   physical connections.  These are used to build a logical network by
   using protocols like Ethernet and IP.

   To represent the physical topology of a domain in the Meta-MIB, we
   take from VLSI design the concept of modules with connection pins and
   signals connecting them electrically.  This results in abstract
   components with ports and connections between two ports as shown
   below.

     Abstract component              Connection C1:A-C2:B
       with ports

      +-----------+
      | Component |                 +-------+     +-------+
     -O A       B O-                | C1  A O-----O B  C2 |
      |    C      |                 +-------+     +-------+
      +----O------+
           |

      Fig. 2  Components and connections

   A port is an abstract connector of the component.  This may be a plug
   for a single wire, for a twisted pair, a bus or the power supply and
   even - for the water connection for cooling a supercomputer. The
   properties of each port of a component has to be described
   separately.

   Although we are free to define 'a connection' as a physical cable
   (like in VLSI design) or alternatively as an electrical joining
   point, we prefer the latter method of description, since this allows
   us to store the physical properties of cables explicitly in MIBs,
   similar to configuration data of any other component.  Therefore, a
   connection can connect just two distinct ports and a solder point
   connecting several wires or an Ethernet cable with taps has to be
   described as a component with several ports.  Note, that each port
   may be connected only once.

   The names of the ports are arbitrary but must be unique. The choice
   of a name is sometimes obvious, like the name of the interface of a
   computer (tty, lan1, COM1 etc.). But the ends of a cable for example
   or a solder joint can be numbered consecutively.

   The description of a VLSI chip is clearly a subset of this
   description technique.  So, we can principally describe the internal
   hardware of network components (bridges etc.) down to any level



Schaller                                                        [Page 5]





RFC nnnn                The Meta-Management MIB            25 April 1995


   desired (from printed circuit boards over ICs, logical function
   units, gates down to transistors) to make it a white box.  But it
   must be admitted that this is usually not required for network and
   system management purposes.

2.4 Set of Agents

   The topology of a network is not enough information to do network
   management.  Therefore, we have to correlate the components of the
   topology description to the components to be managed and their
   management information.  In Internet Management, management
   information of any kind is provided by accessing agent processes with
   the Simple Network Management Protocol (SNMP) over UDP/IP.  So, we
   store for each component in a domain the set of agent processes
   providing further management information. For sub- and superdomains,
   we store how to access the Meta-MIB of the sub- or superdomain.

2.5 The Meta-MIB objects

   The Meta-MIB defines objects in four tables and a component
   registration tree.  Three tables together with the registration tree
   build the topology graph, while the fourth table stores the set of
   agents. Only the combination of both groups in a single MIB makes a
   Meta-MIB that can describe both, the configuration of the network and
   the management system.

2.5.1 Components

   The set of physical components in the domain are stored in the
   component table.  Each component is identified by an unique index.
   The name and the description are arbitrary, but the name will be used
   to address individual components by the network manager. Therefore,
   component names should follow the preferred syntax of names as
   defined in [RFC-1034] to augment the DNS tree by a tree of Meta-MIBs.
   Note, that domains (groups of components) are treated exactly like
   physical components.

   The physical component type is indicated by an OBJECT IDENTIFIER. The
   component status may be used to notify certain emergency states to
   managers.  Both values, which need not to be accurate, are mostly
   intended to be used for display tools, like a configuration monitor.

   A configuration monitor may select the appearance and color of the
   icon representing the component depending on this information.  More
   accurate information must be retrieved from the set of agents
   responsible for the component.





Schaller                                                        [Page 6]





RFC nnnn                The Meta-Management MIB            25 April 1995


2.5.2 Component types

   Values permitted for the component type are registered in an OBJECT
   IDENTIFIER tree.  Note, that component types must be defined vendor
   independent and are only technology dependent. The operating system,
   the processor, and the protocols used, etc. can be defined in MIBs
   describing the component in detail.  The special component type
   'domain' is reserved for super- or subdomains.

2.5.3 Ports

   Each component has at least one port. All ports are collected in the
   ports table. Ports are uniquely identified by a component and a port
   index.

   Each port has a name and a status. The name must be used to correlate
   the port to interfaces defined in other MIBs. This may be the
   interface index (ifIndex) or the interface description string
   (ifDescr) in the interfaces table (ifTable) of the MIB-II [RFC-1158].

2.5.4 Connections

   This table provides a set of connections between the ports of
   components.  Each connection is stored twice, representing both
   directions of a connection.  The connection status is positive for
   the forward direction and negative for the backwards direction.

   Although this scheme is redundant, it provides a simple algorithm for
   answering quesions like "who is connected to port A?", without
   knowing if the port 'A' is the first or the second endpoint and
   checking both directions separately.

2.5.5 Agents

   For each component, the Meta-MIB stores a set of agents providing the
   full management information for this component. This closes the gap
   between the topology and logical and physical management information
   of components.

   Agent processes are specified by their Internet Address and the UDP-
   Port they are listening on. An OBJECT IDENTIFIER may restrict the
   access to a certain subtree (MIB View).  Note, that the same agent
   process may be registered several times with different OBJECT
   IDENTIFIERS.

   Components can be registered in the Meta-MIB, that have no agents
   associated, like cables or connectors.




Schaller                                                        [Page 7]





RFC nnnn                The Meta-Management MIB            25 April 1995


   For remote domains, the Meta-MIB agent should be added for the
   domain-component.

2.6 Operation

2.6.1 Using the Meta-MIB

   It has not yet been specified, where to install agents with Meta-
   MIBs.  Obviously, there should be at least one agent capable of
   storing Meta-MIBs in each subnet of the Internet. Since subnets are
   usually connected to routers, a router MIB is a good place. This
   Meta-MIB stores the configuration of all subnets connected to the
   router.

   But we are not restricted to this granularity and can add the Meta-
   MIB to all components of the network that are manageable by SNMP.
   Thus, each Router, Bridge, Hub and each Host have their own Meta-MIBs
   to describe their local configuration topology and how they are
   connected to their neighbours.  This results in a fine grain
   distrbution of the data that reduces the amout of data to be stored
   in a Meta-MIB and simplifies autodiscovery (see below).

   Now, a manager process can use the data found in the Meta-MIB, as in
   the following example:

      The Network Manager wants to view the number of received IP
      datagrams of all components in his local domain.

   With a Meta-MIB he starts his network monitor and specifies the
   address of the Meta-MIB agent.  The network monitor reads out the
   tables of the Meta-MIB, thus determining the names of the components
   and how to access the agents responsible.  Then, the network monitor
   will retrieve and display the parameter ipInReceives of the MIB-II
   [RFC-1158] from all agents it is aware of.

   The benefits of the Meta-MIB are obvious. The configuration of the
   Network Monitor becomes simple and is always consistent with other
   management tools.

2.6.3 Autodiscovery

   A different issue is the automatic detection of the network topology
   ("autodiscovery").  An autodiscovery function can be part of a
   managed system.  Then, it can use the Meta-MIB to present its
   findings to managers in a standardized way. This means that the
   Meta-MIB serves as the result data structure for autodiscovery
   processes.




Schaller                                                        [Page 8]





RFC nnnn                The Meta-Management MIB            25 April 1995


   If, contrary to this, autodiscovery is part of a management system,
   it writes its findings into a Meta-MIB agent by using SET requests.
   This makes the Meta-MIB a simple database, that is not connected to a
   physical managed component.

   Both architectures can be used simultaneously, as long as some
   coordination is done.  A router, for example, could automatically
   identify its interfaces and the domains and hosts it is directly
   connected to and provide all this data dynamically in a Meta-MIB. A
   manager can additionally edit and extend this information.

   The Meta-MIB can be edited manually, by a configuration monitor.
   This has typically a graphical user interface (GUI) which translates
   component names and types into appropriate icons and connections to
   lines presented to the user. The user can use the mouse and menues to
   select individual components and issue commands to create, modify,
   and delete components, ports, and connections.  These are translated
   into SET-REQUESTs to the Meta-MIB.

   It is permitted to edit the Meta-MIB simultaneously through several
   configuration monitors to support a cooperative group of managers,
   but consistency (transaction management) can not guaranteed through
   SNMP.

2.6.3 Distributed Meta-MIBs to connect domains

   Because remote domains are handled like all components, we get
   automatically a distributed configuration database.  To use this
   feature effectively, a configuration monitor can use the technique of
   hyperlinks for remote domains to let the network manager click
   through the domains (i.e. the Meta-MIBs) until he reaches the desired
   components.

   This feature can also be used for a naming scheme to identify single
   components in a WAN as defined below.

2.6.3 Component and port addressing scheme

   The naming convention of components can adopt the scheme defined by
   the DNS [RFC-1034]. This leads to the following name resolving rules:

      - A component name consists of one or several substrings separated
        by dots,
      - the last substring identifies a component in the local domain,
      - if this component is a domain, the other substrings (to the
        left side) refer to a components in this domain (recursion), and
      - if this component is not a domain, it must be the only
        substring.



Schaller                                                        [Page 9]





RFC nnnn                The Meta-Management MIB            25 April 1995


   For example, the component C in Fig. 1 is addressed by
   'C.local-domain' from outside and by 'C' inside of the local domain.
   Note, that circles are allowed, i.e. 'A.subdomain.superdomain' refers
   to the same component as 'A', assuming corresponsing data in both
   Meta-MIBs.  And note, that since there is no root of a distributed
   network topology, names are always relative to the local domain or
   must be postfixed by the identifier of a well known root.

   Ports of a component are specified by addresing the component and
   adding a colon and the port name.  So the connection in Fig. 2
   connects 'C1:A' and 'C2:B'.








































Schaller                                                       [Page 10]





RFC nnnn                The Meta-Management MIB            25 April 1995


3. Definitions

   META-MIB DEFINITIONS ::= BEGIN

           IMPORTS
             enterprises, IpAddress FROM RFC1155-SMI
             OBJECT-TYPE FROM RFC1212
             DisplayString FROM RFC1213-MIB;

           wilma   OBJECT IDENTIFIER ::= { enterprises 860 }
           meta    OBJECT IDENTIFIER ::= { wilma 6 }
                                   -- 1.3.6.1.4.1.860.6

   -- component table

   componentTable OBJECT-TYPE
           SYNTAX SEQUENCE OF ComponentEntry
           ACCESS not-accessible
           STATUS mandatory
           DESCRIPTION
           "The component table stores a list of all components in the
           managed domain. A component is identified by an unique
           componentIndex, while the name should be unique to relate
           the data to entries in other MIBs.
           The componentDescription is optional and may be used as a
           comments field.
           The componentType and componentStatus fields are intended
           to be used as a preclassification of the component, to aid
           display tools in selecting the appropriate icon.
           The real type and status of the components can be
           determined by examining the MIBs found in the agentTable
           for the component."
           ::= { meta 1 }

   componentEntry OBJECT-TYPE
           SYNTAX ComponentEntry
           ACCESS not-accessible
           STATUS mandatory
           INDEX { componentIndex }
           ::= { componentTable 1 }

   ComponentId ::= INTEGER

   ComponentEntry  ::=
           SEQUENCE {
           componentIndex ComponentId,
           componentName DisplayString,    -- unique name of the
                                           -- component



Schaller                                                       [Page 11]





RFC nnnn                The Meta-Management MIB            25 April 1995


           componentType ComponentType,    -- component type hint for
                                           -- display tools
           componentDescr DisplayString,   -- optional description
           componentStatus INTEGER         -- status hint for display
                                           -- tools
           }

   componentIndex OBJECT-TYPE
           SYNTAX ComponentId
           ACCESS read-write
           STATUS mandatory
           DESCRIPTION
           "The unique component number. Must be >0"
           ::= { componentEntry 1 }

   componentName OBJECT-TYPE
           SYNTAX DisplayString (SIZE(0..255))
           ACCESS read-write
           STATUS mandatory
           DESCRIPTION
           "The name of a component, which should be unique to relate
           the data to entries in other MIBs.
           Component names should follow RFC1034/3.5"
           ::= { componentEntry 2 }

   ComponentType ::= OBJECT IDENTIFIER

   component-registration OBJECT IDENTIFIER ::= { meta 5 }

           other OBJECT IDENTIFIER ::=
                   { component-registration 1 }    -- other type not
                                                   -- listed here
           invalid OBJECT IDENTIFIER ::=
                   { component-registration 2 }    -- invalid (or
                                                   -- deleted)
           domain OBJECT IDENTIFIER ::=
                   { component-registration 3 }    -- other domain
                                                   -- (sub- or
                                                   -- superdomain)
           unspecified OBJECT IDENTIFIER ::=
                   { component-registration 4 }    -- not specified
                                                   -- here

           network OBJECT IDENTIFIER ::=
                   { component-registration 5 }    -- network specific

           medium OBJECT IDENTIFIER ::=
                   { network 0 }           -- electronical or optical



Schaller                                                       [Page 12]





RFC nnnn                The Meta-Management MIB            25 April 1995


                                           -- medium
           cable OBJECT IDENTIFIER ::=
                   { medium 1 }            -- generic cable
           bus OBJECT IDENTIFIER ::=
                   { medium 2 }            -- general bus
           joint OBJECT IDENTIFIER ::=
                   { medium 3 }            -- solder joint/splice
           ring OBJECT IDENTIFIER ::=
                   { medium 4 }            -- token ring structure
           fiber OBJECT IDENTIFIER ::=
                   { medium 5 }            -- glass fiber

           layer1 OBJECT IDENTIFIER ::= { network 1 }
           connector OBJECT IDENTIFIER ::= { layer1 1 }
           repeater OBJECT IDENTIFIER ::= { layer1 2 }
           transceiver OBJECT IDENTIFIER ::= { layer1 3 }
           modem OBJECT IDENTIFIER ::= { layer1 4 }

           layer2 OBJECT IDENTIFIER ::= { network 2 }
           bridge OBJECT IDENTIFIER ::= { layer2 1 }

           layer3 OBJECT IDENTIFIER ::= { network 3 }
           router OBJECT IDENTIFIER ::= { layer3 1 }

           layer4 OBJECT IDENTIFIER ::= { network 4 }
           layer5 OBJECT IDENTIFIER ::= { network 5 }
           layer6 OBJECT IDENTIFIER ::= { network 6 }

           layer7 OBJECT IDENTIFIER ::= { network 7 }
           gateway OBJECT IDENTIFIER ::= { layer7 1 }

           generic OBJECT IDENTIFIER ::= { network 8 }
           rmon OBJECT IDENTIFIER ::=
                   { generic 1 }   -- netprobe device with
                                   -- RMON-MIB [RFC1271]
           hub OBJECT IDENTIFIER ::= { generic 2 }

           computersystem OBJECT IDENTIFIER ::=
                   { component-registration 6 }    -- host specific

           central OBJECT IDENTIFIER ::= { computersystem 1 }
           cpu OBJECT IDENTIFIER ::= { central 1 }
           fpu OBJECT IDENTIFIER ::= { central 2 }
           memory OBJECT IDENTIFIER ::= { central 3 }

           peripheral OBJECT IDENTIFIER ::= { computersystem 2 }
           interface OBJECT IDENTIFIER ::= { peripheral 1 }
           serial OBJECT IDENTIFIER ::= { interface 1 }



Schaller                                                       [Page 13]





RFC nnnn                The Meta-Management MIB            25 April 1995


           parallel OBJECT IDENTIFIER ::= { interface 2 }
           printer OBJECT IDENTIFIER ::= { peripheral 2 }
           diskdrive OBJECT IDENTIFIER ::= { peripheral 3 }
           floppy OBJECT IDENTIFIER ::= { diskdrive 1 }
           harddisk OBJECT IDENTIFIER ::= { diskdrive 2 }
           cd-rom OBJECT IDENTIFIER ::= { diskdrive 3 }
           tapedrive OBJECT IDENTIFIER ::= { peripheral 4 }
           keyboard OBJECT IDENTIFIER ::= { peripheral 5 }
           mouse OBJECT IDENTIFIER ::= { peripheral 6 }
           display OBJECT IDENTIFIER ::= { peripheral 7 }

   componentType OBJECT-TYPE
           SYNTAX ComponentType
           ACCESS read-write
           STATUS mandatory
           DESCRIPTION
           "The component type as registered in
           wilma(860).meta(6).component-registration(5).
           The component type is intended to be used as a
           preclassification of the component just to aid display
           tools in selecting the appropriate icon.
           The real type of the component must be determined by
           examining the MIBs found in the agentTable for the
           component.
           The component and all its ports and connections are deleted
           when the type is set to ...component-registration(5).invalid(2)
           or the componentStatus is set to invaild(2).
           It is the agent's responsibility to keep the database
           consistent."
           ::= { componentEntry 3 }

   componentDescr OBJECT-TYPE
           SYNTAX DisplayString (SIZE(0..255))
           ACCESS read-write
           STATUS mandatory
           DESCRIPTION
           "An optional component description that may be used as a
           comments field."
           ::= { componentEntry 4 }

   componentStatus OBJECT-TYPE
           SYNTAX INTEGER {
           other(1),
           invalid(2),     -- invalid (or deleted)
           on-line(3),     -- may indicate green (example)
           off-line(4),    -- may indicate yellow (example)
           unknown(5),     -- may blink yellow (example)
           error(6),       -- may indicate red (example)



Schaller                                                       [Page 14]





RFC nnnn                The Meta-Management MIB            25 April 1995


           alert(7),       -- may blink red (example)
           busy(8)         -- may blink green (example)
           }
           ACCESS read-write
           STATUS mandatory
           DESCRIPTION
           "The status of the component.
           It is intended to be used as a preclassification of the
           component status just to aid display tools in selecting an
           appropriate icon attribute.
           The real status of the component can be determined by
           examining the MIBs found in the agentTable for this
           component.
           The component and all its ports and connections are deleted
           when the status is set to invalid(2).
           It is the agent's responsibility to keep the database
           consistent."
           ::= { componentEntry 5 }

   -- port table

   portTable OBJECT-TYPE
           SYNTAX SEQUENCE OF PortEntry
           ACCESS not-accessible
           STATUS mandatory
           DESCRIPTION
           "The port table stores a list of all ports the components
           have.
           The componentIndex refers to the component in the
           componentTable while the portIndex is a unique identifier
           of the port. Both have been included in the table index to
           derive by walking through the subtrees
             a) portTable.portEntry.<C>
             b) portTable.portEntry.<C>.<component>
           the column C of
             a) all ports in the domain
             b) all ports of the specified component."
           ::= { meta 2 }

   portEntry OBJECT-TYPE
           SYNTAX PortEntry
           ACCESS not-accessible
           STATUS mandatory
           INDEX { portComponent,portIndex }
           ::= { portTable 1 }

   PortId ::= INTEGER




Schaller                                                       [Page 15]





RFC nnnn                The Meta-Management MIB            25 April 1995


   PortEntry ::=
           SEQUENCE {
           portComponent ComponentId,  -- component the port belongs to
           portIndex PortId,       -- number of the port (1...)
           portName DisplayString, -- unique name of the port
           portStatus INTEGER      -- status of the port
           }

   portComponent OBJECT-TYPE
           SYNTAX ComponentId
           ACCESS read-write
           STATUS mandatory
           DESCRIPTION "The component, the port belongs to."
           ::= { portEntry 1 }

   portIndex OBJECT-TYPE
           SYNTAX PortId
           ACCESS read-write
           STATUS mandatory
           DESCRIPTION "The port number. Port numbers must be >0."
           ::= { portEntry 2 }

   portName OBJECT-TYPE
           SYNTAX DisplayString (SIZE(0..255))
           ACCESS read-write
           STATUS mandatory
           DESCRIPTION
           "The port name. This name must be used to relate
           the connections to managed object information found in
           other MIBs. It can be an interface name or number for
           example."
           ::= { portEntry 3 }

   portStatus OBJECT-TYPE
           SYNTAX INTEGER {
           valid(1),
           invalid(2)                      -- invalid (or deleted)
           }
           ACCESS read-write
           STATUS mandatory
           DESCRIPTION
           "The status of the port.
           The port and its connections are deleted when the status
           is set to invalid(2).
           It is the agent's responsibility to keep the database
           consistent."
           ::= { portEntry 4 }




Schaller                                                       [Page 16]





RFC nnnn                The Meta-Management MIB            25 April 1995


   -- connection table

   connectionTable OBJECT-TYPE
           SYNTAX SEQUENCE OF ConnectionEntry
           ACCESS not-accessible
           STATUS mandatory
           DESCRIPTION
           "The connection table stores the connection graph between
           ports. The graph is stored as a directed graph, i.e.
           'from -> to', but the agent is responsible to mirror entries
           'to -> from' with negated status. Creating a new entry
           A:1->B:2 will result in a morror row B:2->A:1, deleting one
           removes the mirror entry. Modifying the status of one
           entry modifies the status of the mirrored entry.
           Self-connections are forbidden.
           This scheme and using both component&port pairs as the
           index allows to walk through the subtrees
             a) connectionTable.connectionEntry.<C>
             b) connectionTable.connectionEntry.<C>.<C1>
             c) connectionTable.connectionEntry.<C>.<C1>.<P1>
             d) connectionTable.connectionEntry.<C>.<C1>.<P1>.<C2>
             e) connectionTable.connectionEntry.<C>.<C1>.<P1>.<C2>.<P2>
           to fetch column C of
             a) all connections in the domain
             b) all connections of component C1
             c) the component and port the port C1:P1 is connected to
             d) the port of C2 the port C1:P1 is connected to
             e) the connection if it exists."
           ::= { meta 3 }

   connectionEntry OBJECT-TYPE
           SYNTAX ConnectionEntry
           ACCESS not-accessible
           STATUS mandatory
           INDEX { connectionComponent1,connectionPort1,
                   connectionComponent2,connectionPort2 }
           ::= { connectionTable 1 }

   ConnectionEntry ::=
           SEQUENCE {
           connectionComponent1 ComponentId,
           connectionPort1 PortId,
           connectionComponent2 ComponentId,
           connectionPort2 PortId,
           connectionStatus INTEGER
           }

   connectionComponent1 OBJECT-TYPE



Schaller                                                       [Page 17]





RFC nnnn                The Meta-Management MIB            25 April 1995


           SYNTAX ComponentId
           ACCESS read-write
           STATUS mandatory
           DESCRIPTION "The 'from' component of a connection."
           ::= { connectionEntry 1 }

   connectionPort1 OBJECT-TYPE
           SYNTAX PortId
           ACCESS read-write
           STATUS mandatory
           DESCRIPTION "The 'from' port of a connection."
           ::= { connectionEntry 2 }

   connectionComponent2 OBJECT-TYPE
           SYNTAX ComponentId
           ACCESS read-write
           STATUS mandatory
           DESCRIPTION "The 'to' component of a connection."
           ::= { connectionEntry 3 }

   connectionPort2 OBJECT-TYPE
           SYNTAX PortId
           ACCESS read-write
           STATUS mandatory
           DESCRIPTION "The 'to' port of a connection."
           ::= { connectionEntry 4 }

   connectionStatus OBJECT-TYPE
           SYNTAX INTEGER {
           -- backward direction
           neg-unknown(-5),                -- we don't know
           neg-open(-4),                   -- momentarily disconnected
           neg-connected(-3),              -- connected
           neg-invalid(-2),                -- invalid (or deleted)
           neg-other(-1),
           -- forward direction
           other(1),
           invalid(2),                     -- invalid (or deleted)
           connected(3),                   -- connected
           open(4),                        -- momentarily disconnected
           unknown(5)                      -- we don't know
           }
           ACCESS read-write
           STATUS mandatory
           DESCRIPTION
           "The status of a connection. Since the connection graph
           is stored as a directed graph, both vertices are included
           and distingushed by the sign of the status indicator. A



Schaller                                                       [Page 18]





RFC nnnn                The Meta-Management MIB            25 April 1995


           manager can filter out the mirrored entries by skipping
           all negative (or positive) entries.
           A connection is deleted by setting the status to
           invalid(2) or neg-invalid(-2). The agent is responsible
           for removing the mirrored entry (with C1:P1 and C2:P2
           swapped) to keep the database consistent.
           Modifying the status must also modify the mirror entry.
           The definition of forward and backward is arbitrary."
           ::= { connectionEntry 5 }

   -- agent table

   agentTable OBJECT-TYPE
           SYNTAX SEQUENCE OF AgentEntry
           ACCESS not-accessible
           STATUS mandatory
           DESCRIPTION
           "The agent tables lists all agent processes that provide
           management information for a given component. Finding and
           correltating the data in these MIBs with the components
           in the Meta-MIB is the job of the management application
           and is not specified here.
           An OBJECT IDENTIFER identifies the MIBs or Views provided
           by the agents.
           Note, that an agent may be listed several times for
           different OBJECT IDENTIFIERS."
           ::= { meta 4 }

   agentEntry OBJECT-TYPE
           SYNTAX AgentEntry
           ACCESS not-accessible
           STATUS mandatory
           INDEX { agentComponent, agentIndex }
           ::= { agentTable 1 }

   AgentId ::= INTEGER

   AgentEntry ::=
           SEQUENCE {
           agentComponent ComponentId,     -- component
           agentIndex AgentId,             -- agent number for
                                           -- component
           agentObjId OBJECT IDENTIFIER,   -- View for this component
           agentAddress IpAddress,         -- agent address for this
                                           -- component
           agentPort INTEGER,              -- UDP port for accessing
                                           -- the agent process
           agentStatus INTEGER             -- the status of the agent



Schaller                                                       [Page 19]





RFC nnnn                The Meta-Management MIB            25 April 1995


           }

   agentComponent OBJECT-TYPE
           SYNTAX ComponentId
           ACCESS read-write
           STATUS mandatory
           DESCRIPTION "The component this agent is responsible for."
           ::= { agentEntry 1 }

   agentIndex OBJECT-TYPE
           SYNTAX AgentId
           ACCESS read-write
           STATUS mandatory
           DESCRIPTION
           "The agent number to distinguish several entreis in the
           table for the same component. The index must be >0."
           ::= { agentEntry 2 }

   agentObjId OBJECT-TYPE
           SYNTAX OBJECT IDENTIFIER
           ACCESS read-write
           STATUS mandatory
           DESCRIPTION
           "The OBJECT IDENTIFIER of a MIB or object in a MIB with
           data for the component. This may be the root of a MIB,
           a table entry or a row of a table or a single object.
           The interpretation depends on the MIB specified here.
           In the case of a domain component, the Meta-MIB
           (1.3.6.1.4.1.860.6) must be specified."
           ::= { agentEntry 3 }

   agentAddress OBJECT-TYPE
           SYNTAX IpAddress
           ACCESS read-write
           STATUS mandatory
           DESCRIPTION "The Internet Address of the agent process."
           ::= { agentEntry 4 }

   agentPort OBJECT-TYPE
           SYNTAX INTEGER
           ACCESS read-write
           STATUS optional
           DESCRIPTION "The UDP port for the agent process. This is
           usually port 161. Range 0..65535."
           ::= { agentEntry 5 }

   agentStatus OBJECT-TYPE
           SYNTAX INTEGER {



Schaller                                                       [Page 20]





RFC nnnn                The Meta-Management MIB            25 April 1995


           valid(1),
           invalid(2),                     -- invalid (or deleted)
           unknown(3)                      -- sorry, but we don't know
           }
           ACCESS read-write
           STATUS mandatory
           DESCRIPTION "The status of the entry in the agent table."
           ::= { agentEntry 6 }


   END








































Schaller                                                       [Page 21]





RFC nnnn                The Meta-Management MIB            25 April 1995


4. Security Considerations

   The lack of SNMPv2 support is an obvious security hole.  This opens
   unauthorized access to the network topology which may be used as the
   central initializaton data of whole network management systems.
   Additionally, the organizational structure of institutions is usually
   kept secret to the public.

5. References


  [RFC-1034] Mockapetris, P. V., "Domain Names - Concepts and
             Facilities", STD 13, RFC1034, ISI, November 1987.

  [RFC-1035] Mockapetris, P. V., "Domain Names - Implementation and
             Specification", STD 13, RFC1035, ISI, November 1987.

  [RFC-1155] Rose M., and K. McCloghrie, "Structure and Identification
             of Management Information for TCP/IP-based internets", STD
             16, RFC 1155, Performance Systems International, Hughes LAN
             Systems, May 1990.

  [RFC-1156] McCloghrie K., and M. Rose, "Management Information Base
             for Network Management of TCP/IP-based internets", RFC
             1156, Hughes LAN Systems, Performance Systems
             International, May 1990.

  [RFC-1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple
             Network Management Protocol", STD 15, RFC 1157, SNMP
             Research, Performance Systems International, Performance
             Systems International, MIT Laboratory for Computer Science,
             May 1990.

  [RFC-1158] Rose M., Editor, "Management Information Base for Network
             Management of TCP/IP-based internets: MIB-II", RFC 1158,
             Performance Systems International, May 1990.

  [RFC-1212] Rose, M., and K. McCloghrie, Editors, "Concise MIB
             Definitions", STD 12, RFC 1212, Performance Systems
             International, Hughes LAN Systems, March 1991.

  [RFC-1213] McCloghrie K., and M. Rose, Editors, "Management
             Information Base for Network Management of TCP/IP-based
             internets", STD 17, RFC 1213, Performance Systems
             International, March 1991.

  [RFC-1442] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser,
             "Structure of Management Information for version 2 of the



Schaller                                                       [Page 22]





RFC nnnn                The Meta-Management MIB            25 April 1995


             Simple Network Management Protocol (SNMPv2)", RFC 1442,
             SNMP Research, Inc., Hughes LAN Systems, Dover Beach
             Consulting, Inc., Carnegie Mellon University, April 1993.

  [RFC-1445] Galvin, J., and K. McCloghrie, "Administrative Model for
             version 2 of the Simple Network Management Protocol
             (SNMPv2)", RFC 1445, Trusted Information Systems, Hughes
             LAN Systems, April 1993.

  [RFC-1448] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser,
             "Protocol Operations for version 2 of the Simple Network
             Management Protocol (SNMPv2)", RFC 1448, SNMP Research,
             Inc., Hughes LAN Systems, Dover Beach Consulting, Inc.,
             Carnegie Mellon University, April 1993.

  [RFC-1611] Austein, R., and J. Saperia, "DNS Server MIB Extensions",
             RFC1611, Epilogue Technology Corporation, Digital Equipment
             Corporation, May 1994.

  [RFC-1612] Austein, R., and J. Saperia, "DNS Resolver MIB Extensions",
             RFC1611, Epilogue Technology Corporation, Digital Equipment
             Corporation, May 1994.

   [Scha 95] Schaller, H.N., "A concept for hierarchical, decentralized
             management of the physical configuration in the Internet",
             Proc. of KiVS'95, Chemnitz, Springer-Verlag Berlin, 1995,
             ISBN 3-540-58960-0, pp 203-216.


6. Author's Address

   H. Nikolaus Schaller
   Lehrstuhl fuer Datenverarbeitung
   Technical University of Munich
   Arcisstr. 21
   D-80290 Muenchen, Germany
   Phone: +49-89-2105-3601
   Fax: +49-89-2105-3600
   E-Mail contact: wilma@ldv.e-technik.tu-muenchen.de

   Demo agents for some UNIX platforms are available via anonymous FTP
   at the date of publication of this memo on the host:
        ftp.ldv.e-technik.tu-muenchen.de

   as the files
        /dist/WILMA/programs/Agents/Meta-1.0.tar.Z
        /dist/WILMA/programs/Agents/Meta-1.0.hp.pa.tar.Z
        etc.



Schaller                                                       [Page 23]