INTERNET DRAFT Expires August 27, 1993 ISO/CCITT and Internet Management Coexistence (IIMC): Translation of Internet MIBs to ISO/CCITT GDMO MIBs (IIMCIMIBTRANS) March 26, 1993 Lee LaBarre (Editor) The MITRE Corporation Burlington Road Bedford, MA 01730 cel@mbunix.mitre.org Status of this Memo This document provides information to the network and systems management community. This document is intended as a contribution to ongoing work in the area of multi-protocol management coexistence and interworking. This document is part of a package; see also [IIMCOMIBTRANS] [IIMCMIB-II] [IIMCPROXY] and [IIMCSEC]. Distribution of this document is unlimited. Comments should be sent to the Network Management Forum IIMC working group (iimc@thumper.bellcore.com). This document is an Internet Draft. 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. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a ``working draft'' or ``work in progress.'' Please check the 1id-abstracts.txt listing contained in the internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net,nic.nordu.net, ftp.nisc.sri.com, munnari.oz.au to learn the current status of any Internet Draft. LaBarre Expires August 27, 1993 Page i Draft Translation of Internet MIBs to ISO/CCITT MIBs 3/26/93 Abstract This document is intended to facilitate the multi-protocol management coexistence and interworking for networks that are managed using the ISO/CCITT Common Management Information Protocol (CMIP) and networks that are managed using the Internet Simple Network Management Protocol (SNMP). This document contains translation and registration procedures that are applicable to translation of Internet MIBs, defined according to the Internet Structure of Management Information (SMI), into ISO/CCITT SMI-defined MIBs. This document also defines and registers generic management information that may be used with the translation procedures to facilitate interoperability. Table of Contents Status of this Memo ......................................i Abstract .................................................ii Table of Contents ........................................ii Revision History .........................................iv 1.Introduction ...........................................1 1.1 Background ...........................................1 1.2 Overview .............................................2 1.3 Scope ................................................4 1.4 Terms andConventions .................................5 2. Registration and Naming Procedures ....................5 2.1 Registration Procedures ..............................5 2.1.1 Automated Registration Procedures ..................6 2.1.2 IIMC Explicit Registration Procedures ..............7 2.1.2.1 Object Classes and Attributes Registration .......7 2.1.2.2 Trap/Notification Registration ...................7 2.1.2.3 NAME BINDINGs Registration .......................8 2.1.2.4 Registration of ASN.1 Modules and IIMC Documents ................................................9 2.2 Naming Procedures ....................................9 2.2.1 Naming Attribute ...................................9 2.2.2 ISO/CCITT-Internet Naming Tree .....................10 2.2.3 Distinguished Names ................................11 2.3 OID Translation ......................................11 2.3.1 OID/Name Translation ISO to Internet ...............11 2.3.2 OID/Name Translation Internet to ISO ...............14 2.4 Inheritance for Object Classes .......................14 2.5 Reference Labels for Derived Entities ................15 3. Internet to ISO/CCITT MIB Translation Procedures ......16 3.1 Pre-translation Procedures ...........................16 3.2 GDMO Translation Procedures ..........................19 3.2.1 Translation of Groups ..............................19 3.2.2 Translation of Table Objects .......................21 3.2.3 Translation of Table Entry Objects .................22 3.2.4 Translation of Other OBJECT-TYPES ..................23 3.2.5 Translation of Notifications .......................26 3.2.6 Translation of Internet Attribute Types ............30 LaBarre Expires August 27, 1993 Page ii Draft Translation of Internet MIBs to ISO/CCITT MIBs 3/26/93 3.3 Post-translation Procedures ..........................31 3.3.1 Post-translation of BEHAVIOUR Cause ................32 3.3.2 Deletion of Derived MIB Elements ...................32 3.3.3 Creation of NAME BINDING Templates .................32 4. Common SNMP Derived Attribute Types ...................35 5. ASN.1 Definitions .....................................42 6. Acknowledgments .......................................46 References ...............................................47 Annex A ..................................................50 LaBarre Expires August 27, 1993 Page iii Draft Translation of Internet MIBs to ISO/CCITT MIBs 3/26/93 Revision History Draft 0 - October 9, 1992 Initial draft of this document. Draft 1 - March 26, 1993 Current draft of this document (replaces Draft 0). Major Changes Since Last Revision 1. Deleted proxy MIB (moved to [IIMCPROXY]). 2. Revised OID translation procedure. 3. Revised generic notification replaces previous notifications. 4. Updated to reflect SNMPv2 changes. 5. Added parsing capability to templates. 6. Removed NOTIFICATIONS clause from templates. All notifications shall be emitted by the objects in the Proxy MIB defined in [IIMCPROXY]. 7. Revised naming hierarchy for MIBs. 8. Only single name bindings may now be allowed for objects. 9. Revised pre and post processing procedures. 10.Defined document automatic and explicit registration procedures, and registered IIMC docs. 11.Added temporary annex describing the editor's proposal for the naming hierarchy relative to agents and a proxy. This proposal is reflected throughout this document. 12.Corrected numerous errors. Action Item Proposals Contained In This Document #13 Registration of documents (proposed). #17 Parsable behaviour clause (proposed). #7 & #12 Generic Internet notification (proposed). #14 & #15 Alternate naming hierarchy (proposed). Outstanding Issues 1. What should the naming hierarchy be, especially for proxy? This document contains in Annex A a description of the editor's proposed naming hierarchy and its characteristics. The [IIMCPROXY] contains a description of an alternative naming hierarchy proposal. Both proposals should be considered by reviewers, and comments are solicited. 2. Should multiple name-bindings be accommodated for object classes derived from Internet MIBs? LaBarre Expires August 27, 1993 Page iv Draft Translation of Internet MIBs to ISO/CCITT MIBs 3/26/93 1.Introduction The past decade has witnessed the development of enterprise wide networks composed of a multi-vendor environment containing heterogeneous protocol and hardware suites. Organizations have become increasingly dependent on these enterprise networks for their daily operations. This dependence has focused attention on the need for operation, administration, maintenance, and provisioning (OAM&P) of the multi-vendor enterprise network on an end-to-end basis. 1.1 Background This document is part of a package of ISO/CCITT and Internet Management Coexistence (IIMC) drafts. Other documents included in this package are: [IIMCMIB-II] Translation of Internet MIB-II (RFC1213) to ISO/CCITT GDMO MIB [IIMCOMIBTRANS] Translation of ISO/CCITT GDMO MIBs to Internet MIBs [IIMCSEC] ISO/CCITT to Internet Management Security [IIMCPROXY] ISO/CCITT to Internet Management Proxy These documents together comprise a package aimed at integrating ISO/CCITT-based and Internet-based management systems. These documents represent coexistence and interworking efforts underway within the IIMC working group, chartered under the auspices of the Network Management Forum Architecture Integration ISO/Internet technical team. This work was initiated, in part, by NM Forum efforts to translate RFC 1214 for use with OMNIPoint 1 implementations. Through this effort, it became obvious that end-to-end management requires an integrated, unified view of the managed network, despite differences in management protocol and information structure. Integrated management can be facilitated by the development of "proxy" mechanisms which translate between functionally equivalent service, protocol, and SMI differences to create this unified view. MIB translation procedures can be used to support proxy management, as well as to take advantage of existing MIB definition and avoid duplication of effort. In this way, commercial investment in both ISO/CCITT and Internet-based management technologies can be preserved through deployment of common methods and tools which support integration. This overall strategy was outlined in a joint publication developed by the NM Forum and X/Open entitled "ISO/CCITT and Internet Management: Coexistence and Interworking Strategy" LaBarre Expires August 27, 1993 Page 1 Draft Translation of Internet MIBs to ISO/CCITT MIBs 3/26/93 [NMFMC92]. The documents included in the IIMC package are the next level of detailed specifications which implement several of the methodologies identified in the strategy. 1.2 Overview The response to the need for OAM&P of enterprise networks has been the development of network management standards within various networking communities - most notably the ISO/CCITT and Internet communities. However, coordination of standards activities between these two communities has not occurred. As a result, although they share a nearly common management model, differences in their management protocols and structures of management information (SMIs) have developed due to differing management philosophies. The ISO/CCITT community has developed the Common Management Information Protocol (CMIP) [ISO9596-1], and related SMI documents [ISO10165-1,2,4]. The Internet community has developed the Simple Network Management Protocol (SNMP) [RFC1157], and its successor, SNMPv2 [SNMPv2PROT]. The Internet SMI is defined in [RFC1155] and [SNMPv2SMI]. Although functionally similar, the Internet and ISO/CCITT protocols and SMIs differ in terms of their complexity and specific operations. The focus on the need for end-to-end enterprise management has indicated the need to integrate the management of components accessed by ISO/CCITT management, Internet management and proprietary management mechanisms in a manner which presents a unified view of the network, despite protocol and SMI differences. One way to integrate management is by the development of "proxy" mechanisms which translate between functionally equivalent services, protocol and SMI differences to create this unified view. A body of telecommunications and computer vendors, represented by organizations such as the Network Management Forum (NMF), and the U.S. government, as specified in the Government Network Management Profile (GNMP) have based their integrated management model on the ISO/CCITT management model using CMIP and the ISO/CCITT SMI. These organizations are particularly interested in the development of proxies for devices that use the Internet management protocols and SMI. Their interest is primarily due to the widespread commercial implementation and use of such devices within their enterprises, especially devices that use the Internet TCP/IP protocol suite. LaBarre Expires August 27, 1993 Page 2 Draft Translation of Internet MIBs to ISO/CCITT MIBs 3/26/93 The basic model for ISO/CCITT-Internet proxy management is illustrated in the following diagram. Manager Proxy Agent +-----------------------+ +---------------------+ +------ ----------------+ |+---------------------+| |+------+ +----------+| |+----- --------------+ | || Management || || GDMO | | Internet || || Managed | | || Applications || || MIB | | MIB || || Resources | | |+---------------------+| |+------+ +----------+| |+----- --------------+ | | | | |+-------------------+| | | | | | | || Service || | | | | | | || Emulation || | | | | | | ||(scoping) || | | | | | | || (filtering) || | | | | | || (operations)|| | | | |+-----------+---------+| |+-------------------+| |+----- -----+---------+| || ISO/CCITT | GDMO || || Protocols Mapping || || Internet | Internet|| || Manager | MIB || || CMIS |...| SNMP || || Agent | MIB || |+-----------+---------+| |+-------------------+| |+----- -----+---------+| | | | | |CMIS | | | | | | | CMIS Services | | |Services | | | | SNMP "Services" | | | | | | | | | | | | | | | | SNMP| | | | | | | | | | "Services"| | | | | +-----------------------+ +---------------------+ +------ ----------------+ | CMIP | | CMIP | SNMP | | SNMP | +-----------------------+ +---------------------+ +------ ----------------+ ^ ^ ^ ^ LaBarre Expires August 27, 1993 Page 3 Draft Translation of Internet MIBs to ISO/CCITT MIBs 3/26/93 | | | | +---------------------+ +--------------- ----+ CMIP Messages SNMP Messages The proxy architecture provides emulation of CMIS services by mapping to the corresponding SNMP message(s) necessary to carry out the service request. The service emulation allows management of Internet objects by an ISO/CCITT manager. The left hand side of the proxy behaves like an ISO/CCITT agent, communicating with the ISO/CCITT manager using CMIP protocols. The right hand side of the proxy behaves like an Internet manager, communicating with the Internet agent using SNMP protocols. The proxy relies on the existence of a pair of directly- related MIB definitions, where the Internet MIB has been translated into ISO/CCITT GDMO using the procedures specified in [IIMCIMIBTRANS]. The proxy defined in [IIMCPROXY] uses these MIB definitions and rules to provide run-time translation of management information carried in service requests and responses. The proxy architecture is designed with a specified interface between the proxy and the underlying protocol stacks, and so deals primarily in terms of CMIS services and SNMP "services". The proxy emulates services such as CMIS scoping and filtering, processing of CMIS operations, and forwarding/logging of CMIS notifications by performing a mapping process which must be tailored for each protocol (for example, SNMP and SNMPv2 are variants of the same protocol mapping process). In addition, [IIMCOMIBTRANS] specifies translation procedures for converting ISO/CCITT GDMO MIBs into Internet MIBs. MIBs generated by this translation process cannot be utilized by the Proxy defined in [IIMCPROXY], although another kind of Proxy could be defined for this purpose in the future. Finally, note that MIBs translated by procedures such as those defined by [IIMCIMIBTRANS] and [IIMCOMIBTRANS] may also be used without a proxy. For example, a translated MIB may be used to take advantage of existing MIB definitions when business needs require deployment in a different management environment. Translated MIBs may also be used to provide uniformity when multiple management environments are supported by a single system (e.g., dual stack managers). 1.3 Scope LaBarre Expires August 27, 1993 Page 4 Draft Translation of Internet MIBs to ISO/CCITT MIBs 3/26/93 A major reason for the rapid commercialization of devices manageable via the Internet management protocol is due to the speed with which the vendors in the Internet community have been able to develop MIBs based on the Internet SMI. To capitalize on this continuing Internet MIB development and their deployment in commercial devices, communities interested in integrated management via ISO/CCITT-Internet proxies require that procedures be defined for translation of Internet MIBs into ISO/CCITT GDMO MIBs, i.e., MIBs defined according to the ISO/CCITT SMI Guidelines for Definition of Managed Objects [ISO10165-4]. Communities interested in using ISO/CCITT management protocols to directly manage resources using the Internet defined MIB elements are also interested in MIB translation procedures. Such MIB translations may also minimize the independent development of ISO/CCITT GDMO MIBs for the same resources and thereby reduce the incompatibilities with the Internet MIBs. Translation procedures which may be automated to a high degree, and include unambiguous automated registration procedures, are of particular interest to the communities interested in using GDMO translations of Internet MIBs. This document defines such procedures. This document also defines generic SNMP trap to CMIS notification mappings, common naming conventions, and ASN.1 modules applicable to translated Internet MIBs. This document assumes that the reader is familiar with the ISO/CCITT SMI and Internet SMI, and the terminology of each. The term SNMP will be used throughout the document to indicate either SNMPv1 or SNMPv2, unless a distinction needs to be made. Editor's Note: [As of the date of this document, the SNMPv2 SMI and protocol are considered stable drafts. It is expected that the[SNMPv2PROT], [SNMPv2SMI], [SNMPv2MIB], [SNMPv2TC] and related documents will become RFCs and proposed Internet standards before the final publication of this document, and that changes will not significantly affect the registration, naming, and translation procedures described in this document.] Many, but not all, of the procedures defined in this document are subject to automation. Comments are provided concerning possible aids to automation; however, it is not the intent of this document to provide automated translation algorithms. This document is allocated the following registration identifier for purposes of referencing material contained herein. LaBarre Expires August 27, 1993 Page 5 Draft Translation of Internet MIBs to ISO/CCITT MIBs 3/26/93 iimcIIMCIMIBTRANS OBJECT IDENTIFIER ::={iimcManagementDocMan 1} Editor's Note: [The iimcManagementDocMan will be resolved before the final publication of this document.] 1.4 Terms and Conventions Editor's Note: [To Be Provided.] 2. Registration and Naming Procedures Registration and naming procedures are crucial to the unique identification of management information. Registration assures the uniqueness of management information element types, while naming provides a way of distinguishing instances of a type and locating them within the MIB. 2.1 Registration Procedures Registration procedures specify that changes in the syntax or semantics of registered entities require them to be registered as new entities. The process of converting Internet MIBs into the ISO/CCITT GDMO MIBs inevitably introduces subtle semantic changes in how data can be operated on, and changes in the content of the MIB element. For example, ISO/CCITT attributes that are converted from Internet Object Types acquire matching rules for use in filtering operations. ISO/CCITT object classes that are created from Internet groups acquire semantics related to their inheritance of new attributes from the "top" managed object class. The end result is that all the new ISO/CCITT object classes, attributes, and notifications created during the translation process must be registered. In addition, name bindings for inserting object instances into the naming hierarchy must be registered. 2.1.1 Automated Registration Procedures Registration procedures are critical to the goals of automating the translation of Internet MIBs to ISO/CCITT GDMO format, and the efficient implementation of ISO/CCITT- Internet proxies. Registration involves assignment of an ASN.1 Object Identifier (OID) to the entity. Management entities defined according to the principles of the Internet SMI may be registered under the IAB's "internet" arc, or registered under an arc in another organization's proprietary registration subtree. Since OIDs can be guaranteed to be unique across organizations only within the context of the uppermost registration hierarchy, this document uses the entire OID to prevent ambiguity. The effect of the registration procedure specified in this document is to graft the entire OID to LaBarre Expires August 27, 1993 Page 6 Draft Translation of Internet MIBs to ISO/CCITT MIBs 3/26/93 another part of the registration tree, without changing the OID structure. Registration is accomplished by the following procedure: a) determine the sequence of sub-identifiers of the OID assigned to the internet management entity, beginning at the root of the registration tree, and identify that sequence as , NOTE: Remember, the first part of the ASN.1 encoded OID must be translated into two sub-identifiers. b) determine the translated OID {} as: {} = { } where is the OID dedicated for ISO/CCITT- Internet automated registration procedures. This procedure preserves the unique identification of the entities within the Internet subtree, and entities identified by OIDs that are registered by other organizations. Internet defined groups and objects must be registered as ISO/CCITT object classes and attributes; and Internet traps must be registered for inclusion in as ISO/CCITT notifications. This document allocates an arc in the registration hierarchy for use in ISO/CCITT-Internet automated registration. The arc is named "iimcAutoTrans". iimcAutoTrans OBJECT IDENTIFIER ::= {#.#.# ...} 2.1.2 IIMC Explicit Registration Procedures Automated registration procedures alone are not sufficient to support the translation process. ISO/CCITT management entities other than translated objects, attributes, and Internet traps, need to be explicitly registered. These entities include: - name bindings for object classes, - ASN.1 modules that may be referenced for inclusion in other ASN.1 modules of other documents, - documents to enable MIB elements and attribute types defined in one document to be referenced within other documents, - IIMC defined management elements, such as notifications and the IIMC proxy MIB. LaBarre Expires August 27, 1993 Page 7 Draft Translation of Internet MIBs to ISO/CCITT MIBs 3/26/93 This document allocates an arc in the registration hierarchy for explicitly registering IIMC management entities. The arc is named "iimcManagement". This document assigns sub-arcs under the "iimcManagement" arc in the ASN.1 module in 5. The following paragraphs describe registration procedures to facilitate automated translation and assure uniqueness of registered ASN.1 object identifiers for ISO/CCITT object classes and attributes derived from internet entities; and a registration procedure for their name bindings. 2.1.2.1 Object Classes and Attributes Registration Follow the procedure described in 2.1 for OIDs associated with Internet groups, conceptual tables, conceptual table entries, and objects. 2.1.2.2 Trap/Notification Registration Internet traps/notifications and informRequests are not considered by the Internet SMI to be associated with any one object or group. The ISO/CCITT SMI, however, requires that a notification be emitted by a specific object instance. Therefore, determining which ISO/CCITT managed object class should emit specific internet traps/notifications is problematic. This document defines a generic IIMC notification, internetAlarm(see 3.2.5) that is used to carry all Internet traps/notifications. This notification is to be emitted by the internetSystem managed object as defined in [IIMCMIB-II] and derived from the internet system group defined in RFC1213. However, each Internet defined trap/notification must be registered such that they may be differentiated within the IIMC generic notification. Internet traps/notifications are registered using the OID corresponding to the value of the Internet snmpTrapOID object defined in [SNMPv2MIB]. For SNMPv1 trap PDUs, the snmpTrapOID is derived as stated in the SNMPv1/SNMPv2 Coexistence document [SNMPv2COEX] 4.1.2(2). That definition is repeated below: "... if the value of the generic-trap field is 'enterpriseSpecific' then the value used is the concatenation of the enterprise field from the trap PDU with additional sub-identifiers, '0', and the value of the specific-trap field." LaBarre Expires August 27, 1993 Page 8 Draft Translation of Internet MIBs to ISO/CCITT MIBs 3/26/93 For notifications, informRequests, defined according to the SNMPv2 SMI, the registered OID is the value of the snmpTrapOID. The registered OID for the Internet trap/notification is then used as the value for the probableCause field of the IIMC generic notification, internetAlarm, as defined in 3.2.5. 2.1.2.3 NAME BINDINGs Registration As described in 2.2.2 , the ISO/CCITT SMI requires that managed object instances be bound into a naming hierarchy, or tree, for purposes of naming. ISO/CCITT NAME BINDING templates are used to register the manner in which such instances may be bound. These name bindings shall be registered. The Internet SMI does not include the concept of a naming tree and name binding. Thus, there exists no registered internet entity from which an OID for the ISO/CCITT NAME BINDING template can be derived. One solution is to use the object class OID to register name bindings under a special registration arc {iimcManagementNB}. The following procedure is recommended for registration of name bindings for an object class to be inserted into the naming hierarchy, i.e., the subordinate object class: o Assign each new name binding an OID, using the following rules. Start with the OID for the subordinate object class, derived using the procedures in 2.1.1. Within the class OID, extract the (c) portion of the OID. Prepend iimcManagementNB to the (c) so that the OID for the name binding is of the form: {iimcManagementNB (c)} 2.1.2.4 Registration of ASN.1 Modules and IIMC Documents ASN.1 modules defined in IIMC documents are registered under the {iimcManagementModule} arc. Documents derived from MIBs defined in Internet RFC are automatically registered under the iimcManagementModAutoarc by concatenating the RFC number onto that arc. If multiple RFCs are included in the translation, then the RFC numbers shall be concatenated to iimcManagementModAuto in ascending sequence. Explicit registration of other ASN.1 modules within the IIMC sub-tree shall be under the iimcManagementModMan arc. IIMC documents are registered under the {iimcManagementDoc} arc. Documents derived from MIBs defined in Internet RFC are automatically registered under the iimcManagementDocAuto arc by concatenating the RFC number onto that arc. If multiple LaBarre Expires August 27, 1993 Page 9 Draft Translation of Internet MIBs to ISO/CCITT MIBs 3/26/93 RFCs are included in the translation, then the RFC numbers shall be concatenated to iimcManagementDocAuto in ascending sequence. Explicit registration of other documents within the IIMC sub-tree shall be under the iimcManagementDocMan arc. Editor's Note: [Who is the registration authority for explicit registration of other documents?] 2.2 Naming Procedures ISO/CCITT object are identified by specifying read-only attributes within the object class as naming attributes. The naming attribute is used to form the relative distinguished name of the object instance. The sequence of relative distinguished names that trace the path in the naming hierarchy from the root to the object forms a distinguished name that uniquely identifies the object instance. 2.2.1 Naming Attribute The conversion of Internet MIBs into ISO/CCITT GDMO MIBs requires that naming attributes be defined and registered for each ISO/CCITT object class derived from internet management entities. This paper specifies a generic naming attribute, and the conventions for its value definition, to facilitate automated generation of naming attributes for object classes derived from Internet MIBs. This generic naming attribute is applicable to all ISO/CCITT object classes derived from Internet defined MIBs. internetClassId ATTRIBUTE WITH ATTRIBUTE SYNTAX IimcCommonDef.ObjectIdentifier; BEHAVIOUR internetClassIdBehaviour BEHAVIOUR DEFINED AS !This is a generic naming attribute intended to be used for naming all object classes derived from Internet MIB translation. For ISO/CCITT object classes that may have only a single instance per managed system, the value is the OID for the object class concatenated with the sub-identifier "0". Object classes derived from the Internet TCP, UDP, and IP groups are examples of such object classes. For object classes that may have multiple instances per managed system, such as table entries, the value is the concatenation of the ISO/CCITT object class OID and the Internet object LaBarre Expires August 27, 1993 Page 10 Draft Translation of Internet MIBs to ISO/CCITT MIBs 3/26/93 instance identifier (an OID) of the form specified for the table entry instance identification in the original Internet MIB definition. The Internet object instance identification is the concatenation of the values of the Internet OBJECT- TYPE(s) identified in the conceptual table entry OBJECT-TYPE INDEX clause. If an SNMPv2 AUGMENTS clause is present, the instance identification is the concatenation of the values of the OBJECT- TYPE(s) identified in the INDEX clause of the conceptual table entry referenced in the value of the AUGMENTS clause.!;; MATCHES FOR EQUALITY; REGISTERED AS {iimcManagementNot 1}; The formats for naming attributes of table entries are compatible with instance identification conventions used by the Internet, thereby facilitating the automated conversion of Internet MIBs into ISO/CCITT SMI format and the name mapping required for proxy management. 2.2.2 ISO/CCITT-Internet Naming Tree The ISO/CCITT SMI requires that managed object instances (conventionally just called managed objects) be bound into a naming hierarchy, or tree, for purposes of naming. This hierarchy is often called the containment hierarchy. The binding must specify for each managed object class: the object class which is superior to it in the containment hierarchy; and a naming attribute in the object class that is used to distinguish instances of the object class at a given level in the hierarchy. The name binding is specified after the object class has been defined. 2.2.3 Distinguished Names The distinguished name (DN) of a managed object consists of a sequence of relative distinguished names (RDN), one for each managed object on the naming path from the root to the managed object. Each relative distinguished name contains exactly one attribute, the "naming" attribute for the corresponding class, as specified by a NAME BINDING template. This DN is used as the CMIP ManagedObjectInstance or BaseObjectInstance parameter for identifying managed objects. For example, a distinguished name designating a particular routing table entry (of class ipRouteEntry) might be: { {systemId = {troi.mitre.org} LaBarre Expires August 27, 1993 Page 11 Draft Translation of Internet MIBs to ISO/CCITT MIBs 3/26/93 -- ISO/CCITT system {internetClassId = {iimcAutoTrans 1 3 6 1 2 1 4 0}} -- ip {internetClassId = {iimcAutoTrans 1 3 6 1 2 1 4 21 0}} -- ipRouteTable {internetClassId = {iimcAutoTrans 1 3 6 1 2 1 4 21 1 129 83 217}} -- ipRouteEntry } 2.3 OID Translation The procedures required to translate between Internet registered OIDs and names, and ISO/CCITT registered attribute and class OIDs are described in this section. 2.3.1 OID/Name Translation ISO/CCITT to Internet The general procedure for deriving ISO/CCITT registered OIDs from Internet OIDs was explained in 2.1, and the structure of the naming attribute value was explained in 2.2. This paragraph explains how the information used in an ISO/CCITT class OID, attribute OID, and the naming attribute value may be used to create the identifier for naming Internet objects. The following definitions apply: ((c) and (a) refer to class and attribute, respectively) From 2.1, {classOID} ::= {iimcAutoTrans (c)} and {attributeOID} ::= {iimcAutoTrans (a)} For example, examine the ipRouteEntry object class OID: ipRouteEntry ::= {iimcAutoTrans 1 3 6 1 2 1 4 21 1} where (c) ::= 1 3 6 1 2 1 4 21 1, and an attribute that belongs ipRouteEntry, ipRouteNextHop: ipRouteNextHop ::= {iimcAutoTrans 1 3 6 1 2 1 4 21 1 7} where (a) ::= 1 3 6 1 2 1 4 21 1 7. Note that the attribute (a) foripRouteNextHop is equal to (c) for its associated object class, ipRouteEntry, with the sub- LaBarre Expires August 27, 1993 Page 12 Draft Translation of Internet MIBs to ISO/CCITT MIBs 3/26/93 identifier (7) appended to it. Most of the time the relationship: (a) ::= (c) is true for translated MIB attributes. This property is useful for determining the object class and object instance with which an attribute may be associated during run-time translation of Internet object instances contained in SNMP response PDUs and traps/notifications. However, when attributes that were not a part of the original Internet group, table, or table entry, are included in a translated object class, then this relationship is not valid. For example, derived attributes assigned to an object class because their inclusion was indicated by an SNMPv2 AUGMENTS clause, as discussed in 3.1, or because post processing procedures added new attributes. From 2.2, the ISO/CCITT naming attribute value contains the OID formed as, (the "( )" indicates "contents of"): (naming attribute) ::= {iimcAutoTrans (c) } where the , the OID created uniquely for each Internet object instance, is "0" for object classes that may only have a single instance. The for object classes that may have multiple instances is an OID fragment derived from the values of the internet objects identified in the INDEX (or AUGMENTS) clause of the Internet Macro from which the object class is derived, as defined in [RFC1155] or [SNMPv2SMI]. For example, the ISO/CCITT naming attribute value for the instance of ipRouteEntry specific to IP address 129 83 2 17 is{iimcAutoTrans 1 3 6 1 2 1 4 21 1 129 83 2 17}, where (c) ::= 1 3 6 1 2 1 4 21 1, and ::= 129 83 2 17. The Internet uses the following convention to uniquely identify an Internet object instance: {internet object name}::= {(a) } For example, the internet object name for ipRouteNextHop corresponding to IP address 129 83 2 17 is {1 3 6 1 2 1 4 21 1 7 129 83 217}, where (a) ::= 1 3 6 1 2 1 4 21 1 7, ::=129 83 2 17. LaBarre Expires August 27, 1993 Page 13 Draft Translation of Internet MIBs to ISO/CCITT MIBs 3/26/93 Therefore, given the contents of the naming attribute for the ISO/CCITT object instance being accessed, the is extracted. Given the attributeOID for the attribute being operated upon, the(a) is extracted. The {internet object name} is then formed from the results. For example, assume that a CMIS request is issued specifying a distinguished name for an ipRouteEntry managed object as illustrated in 2.2.3; and an attribute for ipRouteEntry, say ipRouteNextHop. The ipRouteNextHop attribute has been assigned the identifier {iimcAutoTrans 1 3 6 1 2 1 4 21 1 7} in the MIB defined in [IIMCMIB-II]. Therefore, the ipRouteNextHop attribute identifier would first have to be translated into the corresponding Internet identifier {1 3 6 1 2 1 4 21 1 7} by stripping off the iimcAutoTrans portion of the OID. Then, from the RDN value for the ipRouteEntry extract the {129 83 217}. Finally the Internet identification for this piece of management information would be constructed according to RFC1213 as {ipRouteNextHop 129 83 2 17}, or equivalently, {1 3 6 1 2 1 4 21 1 7 129 83 2 17}. The agent with which this information resides is identified (see 2.2.3), either in the "cmipsnmpProxyAgent" RDN, or the "systemId", as "troi.mitre.org." 2.3.2 OID/Name Translation Internet to ISO/CCITT Internet to ISO/CCITT OID/name translation is only necessary when used during run-time proxy translation. At run-time internet identifiers are provided as internet object names in SNMP responses and traps/notifications. The internet object names are of the form described in 2.3.1. Although actual translation is required only during run-time in proxy implementations, the translation properties, and information that may be obtained, must be understood in order to properly define the structure of the IIMC generic notification, internetAlarm, defined in 3.2.5. Given the definitions shown in 2.3.1, and knowledge of the IIMC naming hierarchy (name bindings), the ISO/CCITT {classOID},{attributeOID}, and distinguished name can be derived from Internet names and the Internet agent address. - The iimcAutoTrans OID is known. - Using knowledge of the internet name structure as described in 2.3.1, and knowledge of valid (a) values known to the proxy, the (a) and may be extracted from the internet name. Note: The extraction process is not possible if the valid (a) value is not known to the LaBarre Expires August 27, 1993 Page 14 Draft Translation of Internet MIBs to ISO/CCITT MIBs 3/26/93 proxy. The translation process cannot be performed. - The ISO/CCITT attribute OID is formed as: {iimcAutoTrans (a)} - the ISO/CCITT class OID may be determined in one of two ways: i) assume that the (a) contains the object class OID, (c), with which the attribute may be associated, as discussed in 2.3.1. Then stripping off the final component of the OID will yield the (c). The object class OID is then formed as {iimcAutoTrans (c)}. ii) use a safer approach, and determine the class OID by looking up the ISO/CCITT object class OID to which the attribute identified as {iimcAutoTrans (a)} belongs. - The managed object instance value, the object's DN, may be determined as follows: i) the value of the naming attribute associated with the object class may be formed as: {iimcAutoTrans (c) } ii) the naming attribute value, and the internetClass OID defined in 2.2.1, are used to form the final RDN for the object's DN. The sequence of other RDNs for the DN are determined from knowledge of the naming hierarchy defined for proxy [IIMCPROXY], i.e., the IIMC proxy name bindings, and the Internet agent's address. Note: if the Internet agent's address cannot be determined, then it may not be possible to associate a response or notification with a specific agent. This may be a problem if multiple Internet agents are associated with the same network address. 2.4 Inheritance for Object Classes The "top" class defined by [ISO10165-2] is the ultimate superior in the ISO/CCITT inheritance hierarchy. The class "top" contains attributes which are inherited by all managed object classes that are defined using the ISO/CCITT SMI and GDMO templates. Not all attributes of "top" need to be instantiated in any single managed object. All objects shall instantiate the mandatory "objectClass", and "nameBindings" attributes. If LaBarre Expires August 27, 1993 Page 15 Draft Translation of Internet MIBs to ISO/CCITT MIBs 3/26/93 conditional packages may apply, an object shall instantiate the "packages" attribute. 2.5 Reference Labels for Derived Entities The labels used to reference Internet entities (groups, objects, traps) shall be used to reference the corresponding templates for the derived ISO/CCITT entity (object class, attribute, notification). 3. Internet to ISO/CCITT MIB Translation Procedures The procedures for translating Internet SMI MIBs into ISO/CCITT SMI MIBs consist of pre-translation procedures, GDMO template translation procedures, and post-translation procedures. Many of the procedures are subject to automation; some are not. Comments are provided concerning possible aids to automation; however, it is not the intent of this document to provide automated translation algorithms. 3.1 Pre-translation Procedures Pre-translation procedures are outlined below. The rationale for steps (a) - (e) is that the ISO/CCITT object classes and associated attributes must be identified. The rationale for steps (f) - (g) is that all ASN.1 syntax references in templates must be an ASN.1Externaltypereference or Externalvaluereference, i.e., must reference a label that appears on the left side of an ASN.1 construct within some ASN.1 module that appears in the document that defines the derived MIB. Internet MIBs often reference basic ASN.1 constructs, such as INTEGER and OCTET STRING, which must be converted into an Externaltypereference. Default values must reference an Externalvaluereference. (a) Identify Internet groups and OBJECT-TYPEs associated with each group. For SNMPv2 defined MIBs, the OBJECT-GROUP macro includes this information. For SNMPv1 defined MIBs, the group may be identified manually and then the members of the group identified by the fact that their OIDs contain the group object identifier. For SNMPv1 defined MIBs, procedure (c) must be followed. (b) Identify conceptual table OBJECT-TYPEs, conceptual table entry (row) OBJECT-TYPEs associated with each table, and columnar OBJECT-TYPEs associated with each conceptual table entry. Note: For SNMPv2 defined MIBs, the MAX-ACCESS clause of the conceptual table and entry OBJECT-TYPES macro will have a LaBarre Expires August 27, 1993 Page 16 Draft Translation of Internet MIBs to ISO/CCITT MIBs 3/26/93 value of 'not-accessible', and the convention often used is to include the word "Table" or "Entry" in the macro label. Once a conceptual table has been identified, the corresponding conceptual entry OBJECT-TYPE macro can be identified via its registered object identifier through the convention of appending a 1 to the table object identifier. Alternatively, the conceptual table's SYNTAX clause may be examined to determine the label of the corresponding conceptual entry Macro. SNMPv1 defined MIBs are not so consistent in their use of "not-accessible"; however, the other conventions apply. Note: For SNMPv2 defined MIBs, tables may be defined with table entries that augment (SNMPv2 AUGMENT clause) entries for an existing table. The table object classes derived from such tables will be deleted from the ISO/CCITT MIB during post-translation (see 3.3.3). The table entry object class for the deleted table will be bound to the table entry object class that corresponds to the reference in the AUGMENTS clause. (c) For each group, the OBJECT-TYPEs not identified in procedure (b), and not having an ACCESS or MAX-ACCESS clause value of "not-accessible", are identified for translation into attributes of an ISO/CCITT object class associated with the group. The OBJECT-TYPEs that have an ACCESS or MAX- ACCESS clause of 'not-accessible' are not translated. (d) For each conceptual table entry OBJECT-TYPE, the set (set1) of columnar OBJECT-TYPEs associated with the table entry are identified for translation into ISO/CCITT attributes of an ISO/CCITT object class associated with the entry. Another set (set2) of OBJECT-TYPES identified in the INDEX clause of the conceptual table entry OBJECT-TYPE are also identified for inclusion in the class. If the AUGMENTS clause is present, then the INDEX clause of the conceptual table entry OBJECT-TYPE pointed to by the AUGMENTS clause identifies the elements of (set2). The union of these two sets constitutes the set of ISO/CCITT attributes associated with the table entry object class. All OBJECT-TYPEs are translated, including those that have an ACCESS or MAX- ACCESS clause of 'not-accessible'. Note: The set of columnar OBJECT-TYPES associated with a table entry can be identified by the SYNTAX clause for the OBJECT-TYPE for the conceptual table entry. The SYNTAX clause is of the form: SEQUENCE OF where includes the label of an OBJECT-TYPE included in the conceptual table entry. LaBarre Expires August 27, 1993 Page 17 Draft Translation of Internet MIBs to ISO/CCITT MIBs 3/26/93 (e) For each conceptual table, an ISO/CCITT object class is created that contains the generic naming attribute "internetClassId". OBJECT-TYPES, if any, that are directly associated with the table become attributes of that table. (f) Create an ASN.1 module for use in the GDMO template translations. For each OBJECT-TYPE that is to be translated into an ISO/CCITT attribute, check the value of the SYNTAX clause, and if it is not one of the Internet attribute types defined by the SNMPv1 or SNMPv2 SMI (e.g., Counter, IpAddress, Gauge, TimeTicks, Opaque, Counter32, Gauge32, Counter64, NsapAddress), or defined using an SNMPv2 TEXTUAL- CONVENTION macro, then do one of the following: i) If the value is not an Externaltypereference: create an Externaltypereference for the value in the SYNTAX clause and put it into the ASN.1 module. The label for the Externaltypereference shall be the attribute label with the first letter capitalized. ii) If the value is an Externaltypereference: put the Externaltypereference syntax into the ASN.1 module. g) If a DEFVAL clause is present, create an Externalvaluereference which has the type indicated by the OBJECT-TYPE SYNTAX clause and is assigned the value of the DEFVAL clause. The label for the Externalvaluereference shall be the attribute label preceded by "c_" (lower case letter "c"). Place the Externalvaluereference into the ASN.1 module created in f). Note: automatic translation of some DEFVAL clauses into valid Externalvaluereferences may not be possible. Placeholders may be put into the ASN.1 module, e.g., reference label and DEFVAL clause value, for later manual translation during post processing. Also, repeated values may then be collapsed into a single reference. h) If the ASN.1 module for the Internet MIB definition contains ASN.1 value assignments, then the syntax for those value assignments pertinent to the translation shall either be placed in the ASN.1 module created in (f) or imported into the module using an Externalvaluereference. Note: A syntax that is used more than once in the MIB to be translated shall be defined just once in the new ASN.1 module created in(f) and referenced repeatedly. For convenience, an ASN.1 module of common definitions for Externaltypereferences of the basic ASN.1 types included in the SNMPv1 SMI and SNMPv2 SMI (e.g., INTEGER, OCTET STRING) LaBarre Expires August 27, 1993 Page 18 Draft Translation of Internet MIBs to ISO/CCITT MIBs 3/26/93 is defined in 4.5. The Externaltypereferences in this module must either be imported into a local ASN.1 module within the document that defines the derived MIB, or appropriate equivalent references need to be declared within the local ASN.1 module. 3.2 GDMO Translation Procedures Readers of this document are assumed to have familiarity with the GDMO templates and their format. The templates presented here should be considered exemplar, and not definitive. The GDMO templates in this paragraph contain elements indicated by "< x >", where "x" is to be interpreted and the result substituted into the template. The "||" symbol indicates concatenation of elements. Adjacent elements that are not concatenated shall be separated by at least one space. The "[ ]" symbols surrounding a construct indicate that it maybe present or absent in any particular instance of the template. The "[ ]*" symbols surrounding a construct indicate that it may be present or absent in any particular instance of the template an undefined number of times. An "|" symbol is used to indicate that a choice must be made between alternate constructs. The "!" symbol is used to delimit text strings in the templates. Other delimiters may be used, as specified by the GDMO. The delimiter may not be used in the text string unless it is "doubled", e.g.,"!!". Elements that are defined in one template are not repeated for other templates unless its interpretation has changed. Note: other SNMPv2 SMI macro clauses contain textual or other information that may be inserted into the BEHAVIOUR clause of the an ISO/CCITT template, e.g., UNITS, REFERENCE. Provisions for including information in these macro clauses are not explicitly described in the translation procedures below, however the contents of these clauses should be included in the BEHAVIOUR clause. The Internet SNMPv2 SMI also includes macros for specifying compliance with the MIBs. These macros are similar to ISO/CCITT managed object conformance statements (MOCS), and are not addressed here. LaBarre Expires August 27, 1993 Page 19 Draft Translation of Internet MIBs to ISO/CCITT MIBs 3/26/93 3.2.1 Translation of Groups Internet groups may be translated to ISO/CCITT managed object classes by filling in the following GDMO template: MANAGED OBJECT CLASS DERIVED FROM "Rec. X.721 | ISO/IEC 10165-2 : 1992" :top; CHARACTERIZED BY || "Pkg" PACKAGE [BEHAVIOUR || "PkgBehaviour" BEHAVIOUR DEFINED AS !!;;] ATTRIBUTES {iimcManagementDoc 1}:internetClassId GET ["," [DEFAULT VALUE ]]*;;; REGISTERED AS { iimcAutoTrans (c) }; The following definitions apply: - The label associated with the Internet group. - Any textual description that is applicable to the resource modeled by this group, and the resource's management behaviour. Text in the SNMPv2 DESCRIPTION clause of the OBJECT-GROUP macro may be used. To facilitate parsing of BEHAVIOUR clauses for classes derived from groups, the following parsable structure is recommended (the [] indicate optionality, keywords must be in caps, keywords shall be excluded from the descriptive text): [PARSE [REFERENCE !!!!;] ]; ENDPARSE ] If used, the parsable structure shall be the first text in the BEHAVIOUR clause. - The label of an Internet OBJECT-TYPE which is included in the group and does not represent a conceptual table, a conceptual table entry, or an OBJECT-TYPE included in a conceptual table entry. These become attributes of the object class. - The mapping of the ACCESS (or SNMPv2 MAX-ACCESS) clause LaBarre Expires August 27, 1993 Page 20 Draft Translation of Internet MIBs to ISO/CCITT MIBs 3/26/93 value as defined below (multi-valued attributes are not permitted in the Internet SMI): OBJECT-TYPE ACCESS Clause Value* ISO/CCITT read-only GET read-write GET-REPLACE write-only REPLACE read-create GET-REPLACE - The value of the DEFVAL clause in the form of an Externalvaluereference, i.e., ., where the module-name is the name of an ASN.1 module within the document in which this object class is defined, and the value-name is the label assigned to the ASN.1 value definition contained in the DEFVAL clause. Where it is necessary to refer to the label of a definition contained in another document this may be achieved by means of a local ASN.1 module which makes use of the ASN.1 IMPORTS mechanism to import the appropriate value definition. 3.2.2 Translation of Table Objects Internet conceptual table objects may be translated to ISO/CCITT managed object classes by filling in the following GDMO template: MANAGED OBJECT CLASS DERIVED FROM "Rec. X.721 | ISO/IEC 10165-2 : 1992" :top; CHARACTERIZED BY || "Pkg" PACKAGE [BEHAVIOUR || "PkgBehaviour" BEHAVIOUR DEFINED AS !!;;] ATTRIBUTES {iimcManagementDoc 1}:internetClassId GET;;; REGISTERED AS { iimcAutoTrans (c) }; The following definitions apply: - The label associated with the OBJECT-TYPE macro. - The text in the DESCRIPTION clause and any additional text deemed appropriate to defining the behaviour of the object class. To facilitate parsing of BEHAVIOUR clauses for classes derived from tables, the following LaBarre Expires August 27, 1993 Page 21 Draft Translation of Internet MIBs to ISO/CCITT MIBs 3/26/93 parsable structure is recommended (the [] indicate optionality, keywords must be in caps, keywords shall be excluded from the descriptive text): [PARSE [REFERENCE !!!!;] ]; ENDPARSE ] If used, the parsable structure shall be the first text in the BEHAVIOUR clause. 3.2.3 Translation of Table Entry Objects Internet conceptual table entry objects may be translated to ISO/CCITT managed object classes by filling in the following GDMO template: MANAGED OBJECT CLASS DERIVED FROM "Rec. X.721 | ISO/IEC 10165-2 : 1992" :top; CHARACTERIZED BY || "Pkg" PACKAGE BEHAVIOUR || "PkgBehaviour" BEHAVIOUR DEFINED AS !!;; ATTRIBUTES {iimcManagementDoc 1}:internetClassId GET ["," [DEFAULT VALUE ]]*;;; REGISTERED AS {iimcAutoTrans (c) }; The following definitions apply: - The label of an Internet OBJECT-TYPE which represents a conceptual table entry. - The label of an Internet OBJECT-TYPE which represents an OBJECT-TYPE included in a conceptual table entry. These become attributes of the table entry managed object. - The text in the DESCRIPTION clause and any additional text deemed appropriate to defining the behaviour of the object class. To facilitate parsing of BEHAVIOUR clauses for classes derived from table entries, the following parsable structure is recommended (the [] indicate LaBarre Expires August 27, 1993 Page 22 Draft Translation of Internet MIBs to ISO/CCITT MIBs 3/26/93 optionality, keywords must be in caps, keywords shall be excluded from the descriptive text): [PARSE [REFERENCE !!!!;] [MULTIPLEINSTANCES INDEX ; [AUGMENTS ;] [CREATEDELETEATT