tech-invite   World Map     

3GPP     Specs     Glossaries     Architecture     IMS     UICC       IETF     RFCs     Groups     SIP     ABNFs       Search

RFC 1559

Draft STD
Pages: 69
Top     in Index     Prev     Next
in Group Index     No Prev: Lowest Number in Group     No Next: Highest Number in Group     Group: DECNETIV

DECnet Phase IV MIB Extensions

Part 1 of 3, p. 1 to 4
None       Next RFC Part

Obsoletes:    1289


Top       ToC       Page 1 
Network Working Group                                         J. Saperia
Request for Comments: 1559                 Digital Equipment Corporation
Obsoletes: 1289                                            December 1993
Category: Standards Track


                     DECnet Phase IV MIB Extensions

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.

Table of Contents

   1. Introduction ................................................  1
   2. The Network Management Framework ............................  2
   2.1 Object Definitions .........................................  2
   3. Selected Objects ............................................  3
   4. Textual Conventions .........................................  4
   5. Definitions .................................................  4
   6. Changes from RFC 1289 ....................................... 67
   7. Acknowledgements ...........................................  68
   8. References .................................................  68
   9. Security Considerations ....................................  69
   10. Author's Address ..........................................  69

1.  Introduction

   This memo defines a set of DECnet Phase IV extensions that have been
   created for the Internet MIB.  It reflects changes which are the
   result of operational experience based on RFC 1289.

   When used in conjunction with the structure of management information
   (STD 16, RFC 1155), the management information base for network
   management of TCP/IP-based internets (STD 17, RFC 1213) and the
   Simple Network Management Protocol (STD 15, RFC 1157), it will be
   possible to provide integrated network management of combined TCP/IP
   and DECnet Phase IV based internets.  This document was produced by
   the DECnet Phase IV MIB working group of the Internet Engineering
   Task Force (IETF).

   With the adoption of The Simple Network Management Protocol (STD 15,
   RFC 1157), the management information base for network management of
   TCP/IP-based internets (STD 17, RFC 1213), and the structure of

Top      ToC       Page 2 
   management information (STD 16, RFC 1155), by the Internet, and a
   large number of vendor implementations of these standards in
   commercially available products, it became possible to provide a
   higher level of effective network management in TCP/IP-based
   internets than previously available. With the growth in the use of
   these standards, network managers desired to use this environment as
   a base for providing integrated network management of multi-protocol
   networks.

   DECnet Phase IV is one widely used protocol which often coexists in
   IP-based internets. This memo provides the mechanisms by which IP-
   based management stations can effectively manage DECnet Phase IV
   based systems (especially router products) in an integrated fashion
   through the use of the standard Internet SMI, MIB and Simple Network
   Management Protocol.

   DECnet Phase IV objects have been defined to be used in conjunction
   with the Internet MIB to allow access and control of these new
   objects by the Internet community. Additional support for other
   DECnet-based protocols such as RBMS (Remote Bridge Management
   Software) or other Digital Equipment Corporation specific hardware
   platforms is not included in this document.

2.  The Network Management Framework

   The Internet-standard Network Management Framework consists of three
   components.  They are:

   o STD 16, RFC 1155 which defines the SMI, the mechanisms used for
     describing and naming objects for the purpose of management.
     STD 16, RFC 1212 defines a more concise description mechanism,
     which is wholly consistent with the SMI.

   o STD 17, RFC 1213 defines MIB-II, the core set of managed objects
     for the Internet suite of protocols.

   o STD 15, RFC 1157 which defines the SNMP, the protocol used for
     network access to managed objects.

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

2.1  Object Definitions

   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)
   defined in the SMI.  In particular, each object type is named by an

Top      ToC       Page 3 
   OBJECT IDENTIFIER, an administratively assigned name.  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 descriptor, to refer to the
   object type.

3.  Selected Objects

   The objects included in this memo have been created from the DIGITAL
   Network Architecture Network Management Functional Specification
   Version 4.0.0, dated July 1983. An attempt has been made to provide a
   reasonable ordering of these variables into groups. These groups are:

        System Group
        Network Management Group
        Session Group
        End Group
        Routing Group
        Circuit Group
        DDCMP Group
        DDCMP Multipoint Control Group
        Ethernet Group
        Counters Group
        Adjacency Group
        Line Group
        Non Broadcast Line Group
        Area Group

   An effort has also been made to preserve the original syntax of each
   object wherever possible, for example, a DECnet Phase IV object is
   Executor State. This was originally coded as a NICE (Network
   Information and Control Exchange) data type which is a coded single
   field object of 1 byte in length. When converted for inclusion into
   the Internet MIB using the Internet SMI, it became an enumerated
   integer.

   All objects in this memo are described using the standard Internet
   SMI and BER of STD 16, RFC 1155. A complete description of an object
   will include the name, syntax and encoding. Just as with objects
   supported in the MIB (STD 17, RFC 1213), an object name is identified
   with an object identifier which has been administratively assigned.
   This identifies an Object Type. When an object type is combined with
   a specific instance, the particular object is uniquely identified.
   The use of Object Descriptors in this memo is consistent with that of
   STD 17, RFC 1213 - they are text strings meant to be read by humans.
   The descriptors have been taken from the original DIGITAL Network
   Architecture Network Management Functional Specification Version
   4.0.0 Dated July 1983 which defined DECnet Phase IV objects. These

Top      ToC       Page 4 
   names were then massaged to put them in a form as consistent as
   possible with object type names listed in the standard Internet MIB.
   Object defintion information is also taken directly from the Network
   Architecture Network Managment Functional Specification cited above
   wherever possible. In this document, EXECUTOR is intended to
   reference only the DECnet software and is not intended to effect any
   other protocols which may be running on the system.

4.  Textual Conventions

   New datatypes have been introduced as a textual conventions in this
   DECnet Phase IV MIB document. The purpose of these additions is to
   facilitate understanding of new objects in this MIB. No changes to
   the SMI or the SNMP are necessary to support these conventions which
   are described in 5 (Definitions).



(page 4 continued on part 2)

Next RFC Part