Internet Draft NMSIG/OIW WORKING IAs May 16, 1990 Working Implementation Agreements On Network Management Functions, Services and Protocols May 16, 1990 Network Management Special Interest Group (NMSIG) of the OSI Implementors Workshop (OIW) Robert Aronoff (Editor) National Institute of Standards and Technology (NIST) Gaithersburg, MD 20899 Status of this Draft This is the Working Document of the Network Management Special Interest Group (NMSIG) of the OSI Implementors Workshop (OIW). The OSI Internet Management (OIM) Working Group agreements on CMIS/CMIP reference this document. Currently this OIW document is not stable. However, section 18.6, which is referenced by the OIM Agreements, is anticipated to become stable in June, 1990. At that time, section 18.6 will be entered into the OIW Stable Implementation Agreements for Open Systems Interconnection Protocols. At the request of the IETF OIM WG, this OIW Working Document is being made available to the Internet community. The Appendix to this document is under continuing development by the NMSIG to provide the basis for a Management Information Library (MIL) of managed object class definitions. The NMSIG MIL needs refinement. It is anticipated that it will be the basis of an International Registry and International Management Information Library that is under consideration by the committee coordinating the work of the three regional workshops: OIW (OSI Implementors Workshop), EWOS (European Workshop for Open Systems) and AOW (Asia Oceania Workshop). A future version of GOSIP will point to a new Network Management FIPS that will likely include the NMSIG MIL or its international successor. For information about the MIL contact Pranati Kapadia (kapadia%hpindda@hplabs.hp.com). Abstract These agreements pertain to the exchange of management information and management commands between open systems operating in a multivendor environment. The goal is to ensure that a management system built by one vendor can manage network objects built by another vendor. In progressing work on OSI management in the NIST/OSI NMSIG, the OSI management framework specified in ISO 7498/Part 4 (as presented in reference [FRMWK]) is used as the basis for concepts and terminology relevant (a) to OSI management activities, and (b) to management services supported by OSI management protocols. These agreements are based on, and employ, protocols developed in accord with the OSI Reference Model (CMIP/CMIS). Furthermore, they attempt to eliminate ambiguities in interpretations of management protocol standards and management information standards. Section 18.6, in particular, is referenced by the IETF OIM Working Agreements on CMIS/CMIP. 18. NETWORK MANAGEMENT Editor's Note: There is currently no text for subsections 8, 9, and 10 (described below). Editor's Note: The notes in this section are meant to be placeholders for future text. They are included here to reflect SIG activity in these areas. 18.1 INTRODUCTION Within the community of OSI researchers, users, and vendors, there is a recognized need to address the problems of initiating, terminating, monitoring, and controlling communication activities and assisting in their harmonious operation, as well as handling abnormal conditions. The activities that address these problems are collectively called network management. Network management can then be viewed as the set of operational and administrative mechanisms necessary to: a. bring up, enroll, and/or alter network resources, b. keep network resources operational, c. fine tune these resources and/or plan for their expansion, d. manage the accounting of their usage, and e. manage their protection from unauthorized use/tampering. As such, network management is typically concerned with management activities in at least the following five functional areas: configuration management, fault management, performance management, accounting management, and security management. In order to accomplish these management activities, information must be exchanged among management processes. Managing processes have the responsibility for carrying out one or more management activities. Agent processes act on behalf of managing processes, forwarding notifications from and manipulating managed objects. In this section, there are Implementation Agreements (IA's) for providing interoperable OSI management information communication services among OSI systems. Also contained here are agreements on management information, or pointers to other sections of this document or other documents where such additional agreements appear. These agreements pertain to the exchange of management information and management commands between open systems operating in a multivendor environment. Therefore, the goal is to ensure that a management system built by one vendor can manage network objects built by another vendor. In progressing work on OSI management in the NIST/OSI NMSIG, the OSI management framework specified in ISO 7498/Part 4 (as presented in reference [FRMWK]) shall be used as the basis for concepts and terminology relevant (a) to OSI management activities, and (b) to management services supported by OSI management protocols. Thus, these agreements are based on, and employ, protocols developed in accord with the OSI Reference Model. Furthermore, they attempt to eliminate ambiguities in interpretations of management protocol standards and management information standards. 18.1.1 References The following documents are referenced in the statements of the agreements relating to NIST/OSI network management. OSI Systems Management References: [ADDRMVP] ISO/IEC 9596/DAD 2, Common Management Information Protocol Specification: Addendum 2 (Add/Remove Protocol), ISO/IEC JTC1/SC21, 1 February 1990. [ADDRMVS] ISO/IEC 9595/DAD 2, Common Management Information Service Definition: Addendum 2 (Add/Remove Service), ISO/IEC JTC1/SC21, 1 February 1990. [ALS] ISO/IEC DIS 9545, Information Processing Systems - Open Systems Interconnection - Application Layer Structure, 15 March 1989. [AMWD] Information Processing Systems - Open Systems Interconnection - Accounting Management Working Document (Third Version), ISO/IEC JTC1/SC21 N4085, November 1989. [ARF] ISO/IEC 2nd DP 10164-4, Information Processing Systems - Open Systems Interconnection - Systems Management - Part 4: Alarm Reporting Function, ISO/IEC JTC1/SC21 N4070, November 1989. [CANGETP] ISO/IEC 9596/DAD 1, Common Management Information Protocol Specification: Addendum 1 (CancelGet Protocol), ISO/IEC JTC1/SC21, 1 February 1990. [CANGETS] ISO/IEC 9595/DAD 1, Common Management Information Service Definition: Addendum 1 (CancelGet Service), ISO/IEC JTC1/SC21, 1 February 1990. [CDTF] ISO/IEC DP 10164-*, Information Processing Systems - Open Systems Interconnection - Systems Management - Part x: Confidence and Diagnostic Testing Function (First Working Draft), ISO/IEC JTC1/SC21 N4078, December 1989. [CMIP] ISO/IEC 9596-2, Information Processing Systems - Open Systems Interconnection - Management Information Protocol Specification - Part 2: Common Management Information Protocol, 6 December l989. [CMIS] ISO/IEC 9595-2, Information Processing Systems - Open Systems Interconnection - Management Information Service Definition - Part 2: Common Management Information Service, 6 December 1989. [CMO] Information Processing Systems - Open Systems Interconnection - Working Draft of the Configuration Management Overview, ISO/IEC JTC1/SC21 N3311, 16 January 1989. [DMI] ISO/IEC DP 10165-2, Information Processing Systems - Open Systems Interconnection - Structure of Management Information - Part 2: Definition of Management Information, ISO/IEC JTC1/SC21 N4072, December 1989. [ERMF] ISO/IEC 2nd DP 10164-5, Information Processing Systems - Open Systems Interconnection - Systems Management - Event Report Management Function, ISO/IEC JTC1/SC21 N4071, November 1989. [FMWD] Information Processing Systems - Open Systems Interconnection - Systems Management - Fault Management Working Document, ISO/IEC JTC1/SC21 N4077, December 1989. [FRMWK] ISO 7498-4, Information Processing Systems - Open Systems Interconnection - Basic Reference Model - Part 4: Management Framework, 1989. [GDMO] ISO/IEC DP 10165-4, Information Processing Systems - Open Systems Interconnection - SMI - Part 4: Guidelines for the Definition of Managed Objects, ISO/IEC JTC1/SC21 N4065, 20 November 1989. [LCF] ISO/IEC DP 10164-6, Information Processing Systems - Open Systems Interconnection - Systems Management - Part 6: Log Control Function, ISO/IEC JTC1/SC21 N4063, November 1989. [MIM] ISO/IEC DP 10165-1, Information Processing Systems - Open Systems Interconnection - Management Information Services - Structure of Management Information - Part 1: Management Information Model, ISO/IEC JTC1/SC21 Nxxxx, February 1990. [MSF] ISO/IEC DP 10164-*, Information Processing Systems - Open Systems Interconnection - Systems Management - Part x: Measurement Summarization Function (First Working Draft), ISO/IEC JTC1/SC21 N4081, December 1989. [OMF] ISO/IEC 2nd DP 10164-1, Information Processing Systems - Open Systems Interconnection - Systems Management - Part 1: Object Management Function, ISO/IEC JTC1/SC21 N4067, 23 November 1989. [OSIMIL] Management Information Library (MIL) - Revision 3.0, OSI MIB Working Group of NMSIG of NIST/OSI Implementors Workshop, 10 March 1990. [PMWD] Information Processing Systems - Open Systems Interconnection - Performance Management Working Document (Fifth Draft), ISO/IEC JTC1/SC21 N4079, December 1989. [RMF] ISO/IEC 2nd DP 10164-3, Information Processing Systems - Open Systems Interconnection - Systems Management - Part 3: Relationship Management Function, ISO/IEC JTC1/SC21 N4069, 23 November 1989. [SARF] ISO/IEC DP 10164-7, Information Processing Systems - Open Systems Interconnection - Systems Management - Part 7: Security Alarm Reporting Function, ISO/IEC JTC1/SC21 N6064, 20 November 1989. [SATF] ISO/IEC DP 10164-*, Information Processing Systems - Open Systems Interconnection - Systems Management - Part x: Security Audit Trail Function, ISO/IEC JTC1/SC21 N4092, 20 November 1989. [SMF] ISO/IEC 2nd DP 10164-2, Information Processing Systems - Open Systems Interconnection - Systems Management - Part 2: State Management Function, ISO/IEC JTC1/SC21 N4068, 23 November 1989. [SMO] ISO/IEC 2nd DP 10040, Information Processing Systems - Open Systems Interconnection - Systems Management Overview, ISO/IEC JTC1/SC21 N4066, December 1989. [SMWD] Information Processing Systems - Open Systems Interconnection - Systems Management - OSI Security Management Working Document - 7th Draft, ISO/IEC JTC1/SC21 N4091, 15 November 1989. [WMF] ISO/IEC DP 10164-*, Information Processing Systems - Open Systems Interconnection - Systems Management - Part x: Workload Monitoring Function, ISO/IEC JTC1/SC21 N4080, December 1989. Other OSI References: [ACSEP] ISO 8650, Information Processing Systems - Open Systems Interconnection - Protocol Specification for the Association Control Service Element (Revised Final Text of DIS 8650), ISO/IEC JTC1/SC21 N2327, 21 April 1988. [ACSES] ISO 8649, Information Processing Systems - Open Systems Interconnection - Service Definition for the Association Control Service Element (Revised Final Text of DIS 8649), ISO/IEC JTC1/SC21 N2326, 21 April 1988. [ASN1] ISO 8824, Information Processing Systems - Open System Interconnection - Specification of Abstract Syntax Notation One (ASN.1), 19 May 1987. [BER] ISO 8825, Information Processing Systems - Open Systems Interconnection - Basic Encoding Rules for Abstract Syntax Notation One (ASN.1), 19 May 1987. [DIR] ISO 9594 - Information Processing Systems - Open Systems Interconnection - The Directory, 1988. [PPS] ISO/IEC DIS 8823, Information Processing Systems - Open Systems Interconnection - Connection Oriented Presentation Protocol Specification, ISO/IEC JTC1/SC21 N2336, 5 April 1988. [PSD] ISO/IEC Final Text of DIS 8822, Information Processing Systems - Open Systems Interconnection - Connection Oriented Presentation Service Definition, ISO/IEC JTC1/SC21 N2335, 5 April 1988. [ROSEP] ISO/IEC 9072-2 - Information Processing Systems - Text Communications - Remote Operations Part 2: Protocol Specification, 19 September 1989. [ROSES] ISO/IEC 9072-1, Information Processing Systems - Text Communications - Remote Operations Part 1: Model, Notation and Service Definition, 19 September 1989. Other References [MAP30] MAP 3.0 Network Management Specification, August 1988. Editor's Note: Section editors whose text cites these references will keep them up-to-date and will provide additional references as needed, e.g., most recent ISO "N" number and date will be provided. 18.2 SCOPE AND FIELD OF APPLICATION The purpose of this section (sec. 18), is to provide implementation agreements that will enable independent vendors to supply customers with a diverse set of networking products that can be managed as part of an integrated environment. Where possible, these agreements are based upon OSI Network Management standards. Due to the broad scope of the subject, and given that OSI Management standards are still evolving, it is reasonable to assume that a comprehensive set of network management implementors agreements will take a number of years to develop. In order to arrive at an initial set of implementation agreements in a timely fashion, a phased approach has been adopted. As a first step in this phased approach, the NMSIG has targeted that the initial, Phase 1, interim agreements will be completed by December, 1989. These Phase 1 agreements provide limited interoperable management in a heterogeneous vendor environment. They are the cornerstone of our eventual comprehensive inventory of OSI- compatible management agreements. Furthermore, these initial agreements allow the community to gain experience with OSI management standards as they emerge. The scope of the problem addressed in Phase 1 has been constrained in several ways. The sections below outline the nature of these constraints and thereby serve to clarify the scope and field of application associated with this version of the implementors agreements (December 1989). Subsequent phases of these agreements (post December 1989) will expand the scope of problems addressed. Editor's Note: The following phase definitions and milestones represent the current workplan of the NMSIG. The target dates are the earliest dates at which the milestones could possibly be accomplished and depend (in part) on optimistic assumptions about the progress of relevant standards. The scope of Phase 1 IA's will be the following: Management Functions: Object Management, State Management, Relationship Management, Error Reporting and Event Control Management Information: Information Model, Naming, Guidelines and Template for Defining Managed Objects Management Communication: CMIS/P, Association Policies, and Services Required Management Object: Support Objects required for above and 14 Managed Object Definitions under development by the OSI MIB WG Conformance Criteria: TBD depending on the progress of relevant ISO documents. The milestones for Phase 1 IAs and earliest target dates are: Milestone A: [12/89] Freeze the scope of Phase 1 and approve first draft text for Ongoing IAs that cover all of Phase 1 except Managed Objects and Conformance Criteria. Milestone B: [3/90] Add the Phase 1 Managed Objects to the Ongoing IAs. Milestone C: [6/90] Align the Ongoing IAs pertaining to Phase 1 with ISO DIS documents. Add conformance criteria pertaining to Phase I to the Ongoing IAs. Milestone D: [9/90] Progress the Ongoing IAs pertaining to Phase 1 into Stable IAs. The preliminary milestones and earliest target dates for Phase 2 are: Milestone E: [3/90] Define the Scope of Phase 2 IAs. Milestone F: [9/90] Freeze the Scope of Phase 2 IAs and approve the first draft text covering all of Phase 2. It is the intention of the NMSIG to freeze the content of Phase 1 at Milestone A. Only those changes required to align with the ISO DIS's will be made. It is the intention of the NMSIG to define Phase 2 functionality as a compatible superset of Phase 1. The following is an outline of the information provided in these agreements (sec. 18): Section 18.2-- SCOPE AND FIELD OF APPLICATION (This sec.): This section covers several areas. Specifically: o Section 18.2.1 describes the relationship between these agreements and the evolving international management standards. o Section 18.2.2.1 provides a brief overview of the management architecture described in the standards documents. o Section 18.2.2.2 identifies the constraints imposed on Phase 1 of these agreements. o Section 18.2.2.3 addresses migration strategies regarding subsequent phases of these agreements. o Section 18.2.2.4 addresses interoperability with systems associated with other management specifications (including MAP/TOP) [MAP30]. o Section 18.2.3 presents an overview of the functionality supported by Phase 1 of these agreements. Section 18.3 -- STATUS: This section describes the current status of these agreements. Section 18.4 -- ERRATA: Once this document is incorporated into a version of the Stable Implementation Agreements for Open System Interconnection Protocols, this section will contain corrections to the stable management agreements. In addition, this section documents interim resolutions to defects found in the management standards. Section 18.5 -- MANAGEMENT FUNCTIONS: This section documents agreements pertaining to the Systems Management Functions. In addition, it identifies agreements pertaining to the use of other application service elements (e.g. the Common Management Information Service Element (CMISE)). Section 18.6 -- MANAGEMENT COMMUNICATIONS: This section identifies, in detail, the following: o Agreements on Association Policies o Agreements on the Common Management Information Services (CMIS) offered. o Common Management Information Protocol (CMIP) agreements. o Agreements pertaining to the services required by CMIP. Section 18.7 -- MANAGEMENT INFORMATION: This section is based on evolving ISO documents [MIM] and [GDMO], and provides tutorial material and agreements for management information related concepts and modelling techniques. Sub-sections introduce the information model, list principles for naming managed objects and attributes, and provide guidelines for defining management information. Managed object definitions are outside the scope of this section, and are provided in the Management Information Library (MIL). (The MIL is produced by the OSI MIB Working Group, a subgroup of the NMSIG.) Section 18.8 -- IMPLEMENTATION PROFILES/CONFORMANCE CLASSES: This section describes the implementation profiles/conformance classes that are used to categorize management products. At the highest level, products fall into two broad categories: systems that take on a managing system role and systems that take on an agent system role representing managed objects. (Refer to sec. 18.2.2 for further clarification regarding these categories.) Phase 1 of these agreements defines implementation profiles/conformance classes only for systems that take on an agent system role. Editor's Note: The NMSIG intends for Phase 1 to ensure that the interface between managing processes and agent processes is adequately specified, thereby enabling the development of interoperable managing processes and agent processes. It is believed that, by identifying implementation profiles/conformance classes only for systems that take on an agent system role, we will also have sufficiently identified the expected behavior of systems that take on a managing system role. Section 18.9 -- CONFORMANCE: For each of the classes identified in section 18.8, this section outlines the criteria used to determine whether or not a given product conforms to the class specification that it purports to be. More to the point, in conjunction with Phase 1: o Systems that take on an agent system role will be tested, via interactions with a test managing system to ensure that they appropriately represent those managed objects that they purport to represent. Editor's Note: Although systems that take on a managing system role are not to be tested for conformance in Phase 1, it is believed that market presence of conformant systems that take on an agent system role will provide an adequate climate for determining the suitability of systems that take on a managing system role. Section 18.10 -- REGISTRATION REQUIREMENTS: This section identifies the management entities that must be registered. This includes a listing of those managed objects that must be defined in order to satisfy the functional requirements outlined in the Phase 1 agreements. In addition, this section describes the mechanisms used to register management entities and the means by which one can obtain information about a registered entity. 18.2.1 Use of Evolving Standards In general, it is the intent of the NMSIG to base these implementors agreements on existing international management standards. Editor's Note: Table 18.1 below shows the relevant standards documents and the current schedules for progressing these documents to the IS status. The table describes the work items and associated target dates approved at the Sixth SC 21/WG 4 Meeting in Florence, October 31 - November 9, 1989. Table 18.1. RELEVANT STANDARDS DOCUMENTS AND THE CURRENT SCHEDULES FOR PROGRESSING THESE DOCUMENTS TO IS STATUS Target Dates Document DP DIS IS Management Framework 9/86 6/87 10/88 Systems Management Overview 7/90 4/91 Structure of Management Information Part 1: Management Information Model 5/89 1/90 1/91 Part 2: Definition of Management 7/90 4/91 Information Part 4: Guidelines for the Definition of 11/89 1/91 1/92 Managed Objects Common Management Information Service 1/90 Addendum 1: CancelGet 9/89 7/90 Addendum 2: Add/Remove 9/89 7/90 Common Management Information Protocol 1/90 Addendum 1: CancelGet 9/89 7/90 Addendum 2: Add/Remove 9/89 7/90 Configuration Management Systems Management - Part 1: 7/90 7/91 Object Management Function Systems Management - Part 2: 7/90 7/91 State Management Function Systems Management - Part 3: 7/90 7/91 Relationship Management Function Fault Management Systems Management - Part 4: 7/90 7/91 Alarm Reporting Function Systems Management - Part 5: 7/90 7/91 Event Report Management Function Systems Management - Part *: 7/90 4/91 4/92 Confidence and Diagnostic Testing Function Systems Management - Part 6: 11/89 7/90 7/91 Log Control Function Security Management Systems Management - Part 7: 11/89 7/90 7/91 Security Alarm Reporting Function Systems Management - Part *: 7/90 4/91 4/92 Security Audit Trail Function Accounting Management Systems Management - Part *: 7/90 4/91 4/92 Accounting Metering Function Performance Management Systems Management - Part *: 7/90 4/91 4/92 Workload Monitoring Function Systems Management - Part *: 7/90 4/91 4/92 Measurement Summarization Function Given the current state of the standards, the ongoing Phase 1 implementors' agreements are based on documents, some of which are not yet at the DIS level. In addition, in order to meet the stated objectives of the Phase 1 agreements, some agreements have been formed in advance of the availability of DP's in the relevant areas. As the relevant standards documents progress to DIS and IS, the agreements will be aligned. Thus subsequent phases of these agreements will incorporate the relevant standards information as the standards become available. In general, the NMSIG will attempt to incorporate information from a standard that has progressed to the DIS or IS state into the subsequent phases of the implementors' agreements. When a defect is found in any of the management related standards, the reported defect may be technically resolved by the appropriate international technical committee with likely approval by the voting members pending for several months. Since relevant defects can't be ignored in an implementation, these agreements will note defect resolutions which have the tentative approval of the appropriate standards committee. These interim resolutions will be recorded in section 18.4. Once a defect resolution has been finalized by the appropriate standards body, the agreed upon resolution will be incorporated into the next phase of these implementors agreements. If appropriate, a previous phase that relied on an interim resolution will be examined to determine whether or not errata should be issued to bring the original phase into line with the final resolution. 18.2.2 Management Architecture 18.2.2.1 Systems Management Overview Editor's Note: This section is tutorial. Reference [SMO] provides an overview of the OSI Systems Management Architecture. What follows is a brief summary of the information contained therein. The material contained here (i.e. sec. 18.2.2.1) is tutorial in nature. It is not intended to correct deficiencies that may exist in the standards themselves. This information is primarily intended to serve as an aid to the casual reader of these requirements. For more detail, please refer to the management standards referenced below. STANDARDS The OSI System management standards are grouped as follows: o References [FRMWK] and [SMO] address the general concepts. o References [ALS], [CMIS], and [CMIP] address the communications standards. o References [MIM], [DMI], [DMI], and [GDMO] pertain to the definition of management information (managed objects). o References [CMO], [FMWD], [SMWD], [AMWD], and [PMWD] document functional area standards. Editor's Note: Due to reorganization of documents as a result of the December 1988 SC21/WG4 meeting in Sydney, functions have been separated from the management functional areas which originally developed them. The documents which describe these functions include [OMF], [SMF], [RMF], [ARF], and [ERMF]. GENERAL CONCEPTS Viewed abstractly, a communications environment is made up of a collection of managed objects. Management of the communications environment is viewed as being an information processing application. Management activities are carried out by using the information processing application to manipulate and monitor the managed objects that make up the environment. Because the environment being managed is physically distributed, the components of the information processing application are themselves distributed. These distributed components take the form of management application processes. These distributed application processes may be organized in many ways, as for example, in a hierarchical manner or on a peer-to-peer basis. Management processes are divided into two categories: managing processes and agent processes. A managing process is that part of a distributed application process that is responsible for carrying out one or more management activities. An agent process is responsible for manipulating and monitoring an associated set of managed objects. A managing process interacts with an agent process to carry out the management activities for which it is responsible. An agent process performs the management function upon receipt of a message specifying management operations on managed objects. Agent processes may also forward messages to managing processes to convey information generated by managed objects. APPLICATION LAYER COMMUNICATIONS A systems management application entity (SMAE) is that portion of a management process that is responsible for communicating with other management processes (or more specifically, other SMAE's). A SMAE is made up of a collection of cooperating application service elements (ASE's). The association control service element (ACSE) is used to establish associations with other SMAE's. Once this is done, a systems management application service element (SMASE) is used to exchange information between the associated SMAE's. The SMASE realizes the abstract notion of messages exchanged between management processes. The SMASE relies on other (standard) ASE's to effect communications. Notably, the services of the common management information service element (CMISE) are used. Taken as a whole, a SMAE ultimately relies on presentation layer services to communicate. FUNCTIONAL AREAS Systems manAgement activities are grouped into five functional areas that are intended to capture the user requirements imposed on management. These functional areas are: o Configuration Management o Fault Management o Security Management o Performance Management o Accounting Management Each of these functional areas is referred to as a Specific Management Functional Area (SMFA). Each SMFA gives rise to a standard that identifies the following: o A set of functions that support the functionality within the scope of the SMFA. o The procedures associated with the provision of each function. o The services required to support these procedures. o The use of the underlying OSI services to provide the communications needs. o The classes of managed objects that the procedures will operate upon in order to provide the functionality defined by the SMFA. 18.2.2.2 Constraints/Assumptions for Phase 1 The focus of the Phase 1 agreements is to enable a managing process provided by one vendor to interoperate with an agent process provided by a different vendor for the purpose of performing limited management on a set of managed objects. Specifically, these agreements focus on the managing process/agent process interface and the techniques used to define managed objects. These agreements do not address (nor constrain) the mechanisms used by agent processes to manipulate managed objects. Nor should these agreements inhibit our ability to provide post-Phase 1 agreements that meet the long term goals associated with the area of network management. In order to accomplish this goal in a timely fashion, several simplifying constraints have been imposed on these agreements. These constraints are summarized below. 1. These agreements support only a limited set of functionality. Refer to sections 18.2.3 and 18.5 for a description of the functionality supported by these agreements. 2. No agreements are provided in support of managing process to managing process communications. 3. No agreements are provided regarding management domains. 4. All communications supported by these agreements rely on the use of the following application service elements: the association control service element (ACSE), the common management information service element (CMISE), Remote Operations Service Element (ROSE), and the system management application service element (SMASE) identified in section 18.6. 5. All communications between managing processes/agent processes are based on connection- oriented presentation services. 6. These agreements do not rely on the use of Directory Services. 7. No agreements regarding the security of management are provided except for the use of access control on association initialization. Editor's Note: The NMSIG has requested, via a liaison statement, that the Security SIG suggest appropriate security agreements to address this area. In the absence of input from the Security SIG, it should be noted that individual management products may implement proprietary security policies that do not interfere with interoperability. For example, a given managing process or agent process may decide to refuse an A-Associate request based on the calling presentation address and some locally defined criteria. 8. It is assumed that every managed object instance will be associated with exactly one agent process. This agent process is responsible for acting as the agent for the managed object with regard to all interactions with the managing systems. 18.2.2.3 Migration to Future Phases Editor's Note: This section will document the migration plans with regard to ensuring that Phase N products can interact with Phase 1 products. 18.2.2.4 Relationship to Other Management Specifications Editor's Note: This section will describe the degree to which implementations that conform to these agreements will interoperate with implementations that conform to the other management specifications (including MAP/TOP). 18.2.3 Management Scenarios Editor's Note: The intent of this section is to amplify the high level NM requirements to be met by these IAs. In particular, this section will provide a high level view of the functionality supported by Phase 1 of these agreements. Based on these scenarios, one should be able to determine the scope of managed object classes that are required to satisfy these scenarios. 18.3 STATUS Section 18 is currently a working draft of the Phase 1 Network Management Implementors Agreements. Editor's Note: The intention is to possibly move at least some of this material to stability in 1990. Therefore, the content of this chapter should be closely examined. 18.4 ERRATA (None as yet) 18.5 MANAGEMENT FUNCTIONS AND SERVICES Editor's Note: The text in this section (sec. 18.5) is currently undergoing a major revision, to be completed by the June 1990 OIW. Because the current text in this section will be replaced, citations in this section have not been revised to reflect the current updated references in section 18.1.1. Consequently, references cited in the text of section 18.5 may be incorrect. However, the revised text of this section, to be completed by June 1990, will include proper reference citations. Editor's Note: To aid the casual reader, parts of this section have been written in a tutorial fashion, explaining unclear or obscure areas in the base standards. This material will be deleted when transition to the Stable Agreements Document occurs. The remaining material contains agreements relative to the base standards or to areas deemed important for interoperability but not contained in the base standards. Editor's Note: Tutorial Material. ISO has partitioned network management into five Specific Management Functional Areas (SMFAs) as a convenience for developing requirements particular to configuration management (CM), fault management (FM), performance management (PM), security management (SM), and accounting management (AM). These requirements are specified in five separate SMFA standards ([CMO], [FMWD], [SMWD], [AMWD], and [PMWD]). Due to reorganization of documents as a result of the December 1988 SC21/WG4 meeting in Sydney, functions have been separated from the management functional areas which originally developed them. The documents which describe these functions include [OMF], [SMF], [RMF], [ERIRF], [LCF], and [MSC]. Since the SMFAs have overlapping requirements, management functions and management information applicable to one SMFA are often applicable to other SMFAs. Therefore, the SMFAs point to separate standards that contain the management functions needed to satisfy particular requirements. This set of management functions is referred to as the System Management Functions (SMFs). They provide a generic platform of common network management capabilities available to any management application. For example, the management services control function [MSC] may be used to report events to satisfy FM, PM, AM, and SM requirements. The log control function [LCF] may be used to satisfy both FM and SM requirements. The following schematic depicts the functional hierarchy of SMFs and SMFAs. There are seven common SMFs. They provide much of the network management capabilities needed by CM and FM. When additional requirements are identified in other SMFAs, additional SMFs may be developed. Applications | various requirements result in | various groupings of functional | management areas +--------+--------+---------+--------+ | | | | | =================================================================== | | +----+ +----+ +----+ +----+ +----+ SMFAs | | FM | | CM | | PM | | SM | | AM | | +----+ +----+ +----+ +----+ +----+ | | | | | | =================================================================== SMFs | PLATFORM | +-------------+ +----------------------+ +-----------+ | |Event Control| |Service Access Control| |Log Control| | +-------------+ +----------------------+ +-----------+ | | +---------------+ +-----------------+ +------------+ | |Error Reporting| |Error Information| |Relationship| | +---------------+ | Retrieval | | management | | +-----------------+ +------------+ | | +----------------+ +-----------------+ +--------------+ | |State Management| |Object Management| | Confidence & | | +----------------+ +-----------------+ | Diagnostic | | | Test | | +--------------+ | (etc ....) ================================================================== | | CMIS | ================================================================ | Lower Layer Services The following System Management Functions are undergoing standardization: (1) Object Management Function [OMF] (2) State Management Function [SMF] (3) Relationship Management Function [RMF] (4) Error Reporting and Information Retrieval Function [ERIRF]: a. Error Reporting Service b. Information Retrieval Service (5) Management Service Control Function [MSC]: a. Event Control Service b. Service Access Control Service (6) Event Log Control Function [LCF] (7) Confidence and Diagnostic Test Function [FMWD]. For the NIST NMSIG Phase 1 network management agreements, it is agreed that only the first six functions will be supported. For each supported System Management Function (secs. 18.5.1-18.5.6, below), agreements pertinent to the accompanying management communication services are given. 18.5.1 Object Management Function Agreements Editor's Note: Tutorial Material. This System Management Function provides the management of Objects in an Open System Environment. In this environment, a managed object (MO) can be identified as an abstraction of a data processing resource or a data communications resource that can be remotely managed through the use of OSI management communication Services (sec. 18.6). An MO may be a physical item of equipment, a software component, or a combination of such. Each MO has a set of management information associated with it and an MO identifier by which the set of management information can be manipulated through the use of the OSI management communications services. The NMSIG Phase 1 network management agreements support all the operations and services in the object management standard [OMF], i.e., o Object creation operation o Object deletion operation o Object renaming operation o Attribute reading operation o Attribute changing operation o Object listing operation o Enrol Object Service o Deenrol Object Service o Reenrol Object Service o Attribute Change Event Report Service o Add Value Event Report Service o Remove Value Event Report Service For the last three services listed above, the Event Reporting Control Model (sec. 18.5.5) applies. 18.5.1.1 Object Creation Operation Agreements: Editor's Note: Tutorial Material. The Object Creation operation is used by a managing system to ask a managed system to create an instance of a managed object in the managed system. The following agreements and clarifications pertinent to section 8.1 of the base standard [OMF] and regarding the semantics of the confirmed CMIS M-CREATE service (sec. 8.3.4 in [CMIS]) are supported by the Phase 1 network management IAs. All CMIS parameters are mandatory, except where noted below. CMIS M-CREATE request parameters: (1) If this parameter is used in the request, it will identify the distinguished name of the object instance to be created. The distinguished name of a managed object instance is created by concatenating in sequence (ordered list) the relative distinguished names of its superiors in the containment tree starting at the root and working downward towards the managed object instance to be identified. (2) Otherwise, the performing CMISE-service-user will assign a value to this identification of this instance. The managed object definition will specify whether the manager or agent will provide the value. This means that for a given object class either (1) must always be used or (2) must always be used (refer to sec. 6.1.5.2.1 of [MIM]). Refer to sections 18.6.2.4 and 18.6.3.1.2 (Management Communications) of this chapter for agreements pertaining to this parameter. When this parameter is used by the invoking CMISE-service-user, it must specify an existing object instance of the same class as the object being created. This parameter must provide the attribute(s) and their initial value(s) for the object instance if they are neither provided as defaults in the object definition nor obtained from the reference object. Otherwise, a CMIS error of will be returned (sec. 8.3.4.1.8 of [CMIS]). Editor's Note: If an error code of is defined in the standard in the future, it will be adopted here. Editor's Note: The standards as written do not show any way (via the ATTRIBUTE macro) to define a default value for an attribute. We are assuming that it is possible to define such default values. However, it is not required that this be done for EVERY attribute. CMIS M-CREATE response parameters: Refer to section 18.6.3.2.8 (Management Communications) of this chapter for agreements pertaining to this parameter. This parameter specifies all of the created object attributes and values. Editor's Note: It is anticipated that section 18.6 of this chapter will define this in common for all M-CREATE's, at which time, the text here can refer to that section directly. Refer to section 18.6.2.3 and 18.6.3.1.3 (Management Communications) of this chapter for agreements pertaining to this parameter. Editor's Note: Can any manager other than the manager that created the object manage this new object? Over which association(s) can this new object be managed? o the current association? o other extant associations? o new associations? This issue is to be determined as part of the general association policy. Note that there is a more general problem which applies to access rights and ownership of the created objects. Maybe the protocol section should set the policy for the CMIS M-CREATE service? 18.5.1.2 Object Deletion Operation Agreements: Editor's Note: Tutorial Material. The Object Deletion operation is used by a managing system to ask a managed system to delete an instance of a managed object in the managed system. The following agreements and clarifications pertinent to section 8.3 of the base standard [OMF] and regarding the semantics of the confirmed CMIS M-DELETE service (sec. 8.3.5 in [CMIS]) are supported by the Phase 1 network management IAs. All CMIS parameters are mandatory, except where noted below. CMIS M-DELETE request parameters: (1) If scoping is used for multiple object selection, this parameter identifies the managed object class that is to be used as the starting point for the selection of managed objects on which the filter is to be applied. (2) If scoping is used to select the base object only, this parameter identifies the class of the object instance to be deleted. Editor's Note: level delete is to be discussed further. (1) If scoping is used for multiple object selection, this parameter identifies the instance of the managed object that is to be used as the starting point for the selection of managed objects defined by on which the filter is to be applied. (2) When a single object is targeted for deletion (i.e. the scope is base managed object alone), this parameter specifies the managed object instance to be deleted. Editor's Note: level delete is to be discussed further. Refer to sections 18.6.2.4 and 18.6.3.1.2 (Management Communications) of this chapter for agreements pertaining to this parameter. is required. This parameter defines the level(s) relative to the base managed object from which objects will be deleted. This is used for deleting multiple object instances. It will be set to if single object selection is used, or set to to specify the depth of the search, or specify the whole subtree. Editor's Note: level delete is to be discussed further. CMIS M-DELETE response parameters: Refer to section 18.6 (Management Communications) of this chapter for agreements pertaining to these parameters. Refer to sections 18.6.2.3 and 18.6.3.1.3 (Management Communications) of this chapter for agreements pertaining to this parameter. 18.5.1.3 Object Renaming Operation Agreements: Editor's Note: Tutorial Material. The Object Renaming operation is used by a managing system to ask a managed system to rename an instance of a managed object in the managed system. Editor's Note: This section is very controversial. We do not feel that we have a clear understanding of what an OBJECT NAME is. The standard seems to imply that the OBJECT NAME is the distinguishing attribute defined in the object definition. If this is so, it is a attribute, and cannot be changed by a CMIS M-SET service. The group feels that it is more appropriate to use a specific CMIS M-ACTION service to carry out this specific operation. The group will submit comments, in this regard, to ISO by the March 1989 ANSI meeting. The following section aligns with the current standard and may change. Editor's Note: It is anticipated that this service will have side effects, especially with regard to associations where objects existed with old names, regarding operations with the objects under old names, and regarding discriminator object changes at the managed object's systems as well as the destination system. The Object Renaming Operation is not supported in the network management Phase 1 IAs. 18.5.1.4 Attribute Reading Operation Agreements: Editor's Note: Tutorial Material. The Attribute Reading operation is used by a managing system to ask a managed system to return the specified attribute values for an instance of a managed object in the managed system. The following agreements and clarifications pertinent to section 8.8 of the base standard [OMF] and regarding the semantics of the confirmed CMIS M-GET service (sec. 8.3.1 in [CMIS]) are supported by the Phase 1 network management IAs. All CMIS parameters are mandatory, except where noted below. CMIS M-GET request parameters: Refer to section 18.6.2.4 and 18.6.3.1.2 (Management Communications) of this chapter for agreements pertaining to this parameter. is required. This parameter list will contain the list of attributes to be retrieved. If the list is not provided, all attributes will be retrieved. CMIS M-GET response parameters: Refer to section 18.6 (Management Communications) of this chapter for agreements pertaining to these parameters. Refer to sections 18.6.2.3 and 18.6.3.1.3 (Management Communications) of this chapter for agreements pertaining to this parameter. This parameter, provided by the managed system, returns the list of ids of these requested attributes and the values of these attributes. If an error occurs in the retrieval process, a CMIS ERROR will be reported. The list will include all requested attributes, and for each attribute there will be chosen either the attribute value (choice of Tag [1]) for the successful retrieval of an attribute, or an attributeIdError (choice of Tag [0]) for the failure case. Refer to section 8.3.1.1.14 in [CMIS] for more information. 18.5.1.5 Attribute Changing Operation Agreements: Editor's Note: Tutorial Material. The Attribute Changing operation is used by a managing system to ask a managed system to change the values of one or more specified attributes for a managed object instance in the managed system. The following agreements and clarifications pertinent to section 8.9 of the base standard [OMF] and regarding the semantics of the confirmed CMIS M-SET service (sec. 8.3.2 in [CMIS]) are supported by the Phase 1 network management IAs. All CMIS parameters are mandatory, except where noted below. CMIS M-SET request parameters: This parameter will be set to 'confirmed'. Refer to sections 18.6.2.4 and 18.6.3.1.2 (Management Communica- tions) of this chapter for agreements pertaining to this parameter. is required. This parameter will contain the list of attributes whose values are to be modified and the desired new values. CMIS M-SET response parameters: Refer to section 18.6 (Management Communications) of this chapter for agreements pertaining to these parameters. Refer to sections 18.6.2.3 and 18.6.3.1.3 (Management Communications) of this chapter for agreements pertaining to this parameter. This parameter, provided by the managed system, returns the list of attribute ids of the modified attributes and their modified values. If an error occurs in the process, a CMIS ERROR will be reported. The list will include all attributes requested for modification, and for each one, choose either an (choice of Tag [1]) for the successful modification of an attribute, or an (choice of Tag [0]) for the failure case. Refer to (sec. 8.3.2.1.14 in [CMIS]) for more information. 18.5.1.6 Object Listing Operation Agreements: Editor's Note: Tutorial Material. The Object Listing operation is used by a managing system to ask a managed system to retrieve the names of a defined set of managed objects in the managed system. Other attributes can also be retrieved by specifying the attribute names in the request. The following agreements and clarifications pertinent to section 8.7 of the base standard [OMF] and regarding the semantics of the confirmed CMIS M-GET service (sec. 8.3.1 in [CMIS]) are supported by the Phase 1 network management IAs. All CMIS parameters are mandatory, except where noted below. Editor's Note: This section is controversial because we must again work with the problematic definition of an OBJECT NAME. Comments will be submitted to the ANSI meeting in March 1989. The following section assumes that the OBJECT NAME is the same as the attribute which represents the distinguished Name. CMIS M-GET request parameters: Refer to section 18.6.2.4 and 18.6.3.1.2 (Management Communications) of this chapter for agreements pertaining to this parameter. is required. (1) If this parameter is used, the list will include at least the attribute. (2) If the list is not provided, all attributes including the attribute will be retrieved. CMIS M-GET response parameters: Refer to section 18.6 (Management Communications) of this chapter for agreements pertaining to these parameters. Refer to sections 18.6.2.3 and 18.6.3.1.3 (Management Communications) of this chapter for agreements pertaining to this parameter. This parameter, provided by the managed system, returns the attribute ids and values for the specified attributes (including the object name(s) of the requested managed object's attribute). If an error occurs in the retrieval process, a CMIS ERROR will be reported. (sec. 8.3.1.1.14 in [CMIS]) 18.5.1.7 Object Management Services Agreements Editor's Note: Tutorial Material. Each of the Object Management Services uses an unconfirmed M- EVENT-REPORT CMIS service (sec. 8.3.1 in [CMIS]) to convey its information. The Event Reporting Model (see sec. 18.5.5 in this chapter and [ERIRF], [MSC], [DSO]) defines the following procedure: The agent receives notifications from the appropriate managed objects and causes these potential event reports to be checked against all Event Forwarding Discriminators. The result of this sieve process will yield zero, one or more event reports to be transmitted to the destination systems (according to the attributes of the relevant discriminators) according to the services defined in the subsequent sub-sections. One discriminator may cause the sending of multiple event reports, if the multi-valued attribute ManagementUserIdentification contains multiple AEtitles. Additionally, multiple discriminators may filter the same potential event reports and hence generate multiple event reports. Editor's Note: Some of the text in this paragraph should be moved to the discussion of the Event Reporting Model in 18.5.4, while retaining some here. The following agreements and clarifications pertinent to sections 8.2, 8.4, 8.6, 8.10, 8.11, and 8.12 of the base standard [OMF] and regarding the semantics of the CMIS M- EVENT-REPORT parameters are supported by the Phase 1 network management agreements for all the Object Management Services sections 8.5.1.7.1 through 8.5.1.7.6, below: This parameter is set to . Refer to section 18.6 (Management Communications) of this chapter for agreements pertaining to these parameters. 18.5.1.7.1 Enrol Object Service Agreements Editor's Note: Tutorial Material. The Enrol Object Service is used by the managed system to report a creation event of a new managed object instance to a managing system. In addition to the agreements and clarifications in section 18.5.1.7, the following agreements and clarifications pertinent to section 8.2 of the base standard [OMF] and regarding the semantics of the CMIS M-EVENT-REPORT parameters are supported by the Phase 1 network management agreements: CMIS M-EVENT-REPORT request parameters: This parameter identifies the Event whose object identifier is defined in [OMF]. This parameter specifies the time when the new instance was created. Refer to sections 18.6.2.3 and 18.6.3.1.3 (Management Communications) of this chapter for agreements pertaining to this parameter. This parameter is not used for this service. 18.5.1.7.2 Deenrol Object Service Agreements: Editor's Note: Tutorial Material. The Deenrol Object Service is used by the managed system to report the deletion of a managed object instance to a managing system. In addition to the agreements and clarifications in section 18.5.1.7, the following agreements and clarifications pertinent to section 8.4 of the base standard [OMF] and regarding the semantics of the CMIS M-EVENT-REPORT parameters are supported by the Phase 1 network management agreements: This parameter identifies the Event whose object identifier is defined in [OMF]. This parameter specifies the time when the object instance was deleted. Refer to sections 18.6.2.3 and 18.6.3.1.3 (Management Communications) of this chapter for agreements pertaining to this parameter. This parameter is not used for this service. 18.5.1.7.3 Reenrol Object Service Agreements: Editor's Note: Tutorial Material. The Reenrol Object Service is used by the managed system to report the renaming of a managed object instance to a managing system. The Reenrol Object Sevice is not supported in the network management Phase 1 IAs. 18.5.1.7.4 Attribute Change Event Report Service Agreements: Editor's Note: Tutorial Material. The Attribute Change Event Report Service is used by the managed system to report an attribute change event to the managing system. The attribute change event indicates a change in the value(s) of one or more attributes of a managed object. In addition to the agreements and clarifications in section 18.5.1.7, the following agreements and clarifications pertinent to section 8.10 of the base standard [OMF] and regarding the semantics of the CMIS M-EVENT-REPORT parameters are supported by the Phase 1 network management agreements: This parameter identifies the Event whose object identifier is defined in [OMF]. This parameter specifies the time when the attribute value was changed in the object instance. Refer to sections 18.6.2.3 and 18.6.3.1.3 (Management Communications) of this chapter for agreements pertaining to this parameter. This parameter will contain the tuple (sec. 9 in [OMF]). The oldAttributeValue must be presented. 18.5.1.7.5 Add Value Event Report Service Agreements: Editor's Note: Tutorial Material. The Add Value Event Report Service is used by the managed system to report the addition of a value to a multi-valued attribute of a managed object at an open system. In addition to the agreements and clarifications in section 18.5.1.7, the following agreements and clarifications pertinent to section 8.11 of the base standard [OMF] and regarding the semantics of the CMIS M-EVENT-REPORT parameters are supported by the Phase 1 network management agreements: This parameter identifies the Event whose object identifier is defined in [OMF]. This parameter specifies the time when the new attribute value was added to the object instance. Refer to sections 18.6.2.3 and 18.6.3.1.3 (Management Communications) of this chapter for agreements pertaining to this parameter. This parameter will contain the tuple , where is the attribute value just added. (sec. 9 of [OMF]). 18.5.1.7.6 Remove Value Event Report Service Agreements: Editor's Note: Tutorial Material. The Remove Value Event Report Service is used by the managed system to report the removal of a value from a multi-valued attribute of a managed object at an open system. In addition to the agreements and clarifications in section 18.5.1.7, the following agreements and clarifications pertinent to section 8.12 of the base standard [OMF] and regarding the semantics of the CMIS M-EVENT-REPORT parameters are supported by the Phase 1 network management agreements: This parameter identifies the Event whose object identifier is defined in [OMF]. This parameter specifies the time when the attribute value was deleted from the object instance. Refer to sections 18.6.2.3 and 18.6.3.1.3 (Management Communications) of this chapter for agreements pertaining to this parameter. This parameter will contain the tuple , where is the attribute value just deleted. (sec. 9 of [OMF]). 18.5.2 State Management Function Agreements Editor's Note: Tutorial Material. The State Management Function provides for the examination, setting and notification of changes in the management state of existing managed objects. The managed state of a managed object represents its instantaneous condition of availability and operability from the point of view of configuration management. The managed state consists of (1) operational state, and (2) administrative state. A list of the possible combinations of the operational and administrative states is given in (table 1, sec. 7.2, [SMF]). The purpose of this list is to control the availability of a managed object, and to make visible information about the general availability of a managed object. The Phase 1 network management agreements support the two operations and one service defined in the base standard (sec. 8 of [SMF]), i.e., o State reading operation o State changing operation o State change reporting service. For the State change reporting Service, the Event Reporting Control Model (sec. 18.5.5.1.1) applies. 18.5.2.1 State Reading Operation Agreements: Editor's Note: Tutorial Material. The state reading operation enables the managing system to request the managed system to return the values of the configuration state attributes which include the operational and/or administrative state(s) of one or more instances of managed object(s). The following agreements and clarifications pertinent to section 8.1 of the base standard [SMF] and regarding the semantics of CMIS M-GET service (sec. 8.3.1 in [CMIS]) are supported by the Phase 1 network management IAs. All CMIS parameters are mandatory, except where noted below. CMIS M-GET request parameters: Refer to sections 18.6.2.4 and 18.6.3.1.2 (Management Communications) of this chapter for agreements pertaining to this parameter. is required. This parameter list will include the list of state attribute(s) (, ) which the managing system would like to obtain. If the list is not provided, all attributes including the state attributes will be retrieved. CMIS M-GET response paramaters: Refer to section 18.6 (Management Communications) of this chapter for agreements pertaining to these parameters. Refer to sections 18.6.2.3 and 18.6.3.1.3 (Management Communications) of this chapter for agreements pertaining to this parameter. This parameter, provided by the managed system, returns the list of requested state attributes and their values. If an error occurs in the retrieval process, a CMIS ERROR will be reported. (sec. 8.3.1.1.14 in [CMIS]) 18.5.2.2 State Changing Operation Agreements: Editor's Note: Tutorial Material. The state changing operation enables the managing system to request the managed system to change the value of the administrative state attribute of one or more instances of a managed object(s). The following agreements and clarifications pertinent to section 8.2 of the base standard [SMF] and regarding the semantics of CMIS M-SET service (sec. 8.3.2 in [CMIS]) are supported by the Phase 1 network management IAs. All CMIS parameters are mandatory, except where noted below. CMIS M-SET request parameters: 'Confirmed' is to be used. Refer to section 18.6.2.4 and 18.6.3.1.2 (Management Communications) of this chapter for agreements pertaining to this parameter. is required. This parameter will include the state attribute () and its desired new value. CMIS M-SET response parameters: Refer to section 18.6 (Management Communications) of this chapter for agreements pertaining to these parameters. Refer to sections 18.6.2.3 and 18.6.3.1.3 (Management Communications) of this chapter for agreements pertaining to this parameter. This parameter, provided by the managed system, returns the attribute ids and values for the specified attributes (including the modified state attribute). If an error occurs in the process, a CMIS ERROR will be reported. (sec. 8.3.2.1.14 in [CMIS]) 18.5.2.3 State Change Reporting Service Agreements: Editor's Note: Tutorial Material. The state change reporting service enables the managed system to report the change of a state attribute (i.e. either the operational state or administrative state) of a managed object to a managing system. The following agreements and clarifications pertinent to section 8.3 of the base standard [SMF] and regarding the semantics of CMIS M-EVENT-REPORT service (sec. 8.2.1 in [CMIS]) are supported by the Phase 1 network management IAs. All CMIS parameters are mandatory, except where noted below. This parameter is set to . Refer to section 18.6 (Management Communications) of this chapter for agreements pertaining to these parameters. This parameter identifies the Event whose object identifier is defined in [DMA]. This parameter specifies the time when the object instance state attribute value was changed. Refer to sections 18.6.2.3 and 18.6.3.1.3 (Management Communications) of this chapter for agreements pertaining to this parameter. This parameter will contain the tuple for the newly changed state object instance [DMA]. 18.5.3 Relationship Management Function Editor's Note: Tutorial material. A relationship is a set of rules that describe how the operation of one part of an open system affects the operation of another part of an open system. The operation of a managed object may affect its related managed object directly or indirectly. A direct relationship exists between two managed objects when some portion of the management information associated with one managed object expressly identifies the other managed object with which it has a relationship. Indirect relationship information can be deduced from the concatenation of two or more direct relationships. In order to manage the relationship information of two directly related managed objects, a relationship can be modelled as a third object, or a pair of bound attributes, one for each of the related managed objects. The latter approach is the one currently taken by the ISO OSI management standard [RMF]. The relationship is presented by explicitly including, as one of a set of values of each bound attribute of the pair, the name of the other managed object to which it is related. This binding is called an explicit relationship. Therefore, an explicit relationship between a pair of managed objects can be represented by a pair of conjugate values of the bound relationship attributes of the two managed objects. At any given time, within an open systems environment, one managed object may be a part of several different types of relationships. For each type of relationship, depending on the roles of the managed objects (i.e. the set of rules governing the interactions between the two related managed objects), the relationship can be symmetric or asymmetric. If the roles of the two managed objects are the same, then the relationship (role) is symmetric, otherwise it is asymmetric. For every possible relationship role of a managed object, there exists a corresponding relationship attribute. Hence, in order to describe a symmetric relationship, two bound attributes of the same role-type of relationship attributes are needed. To describe an asymmetric relationship, two role-types of bound relationship attributes are needed. The name of a relationship attribute of a managed object implies the relationship role of the related managed objects and the type of the explicit relationship. The value of a relationship attribute for a managed object may be multi-valued or "null". These values are the names of the associated managed objects having the same type of explicit relationship with the managed object. The types of explicit relationships defined in the standards [RMF] are: 1) Service relationship which can be described by relationship attributes of the Service Provider and the Service User; 2) Peer relationship which is a symmetric relationship and is described by the Peer attribute type; 3) Backup relationship which can be described by relationship attributes of the "Primary" operation object and the "Secondary" backup object; and 4) Group relationship which can be described by relationship attributes of "Member" and "Owner". The collection of all relationship attributes of one managed object can be named under a group attribute. If defined, this named group attribute will be an attribute of all of the managed object classes. Between two managed objects there may exist containment relationships in addition to the explicit relationships. A containment relationship is automatically created when the containing/contained managed objects are created. A containment relationship is implicitly reflected in the name (i.e. a sequence of AVAs) of the contained managed object. Managed object naming is part of SMI and is specified during the managed object definition. Therefore, no relationship management service is required to manage containment relationship information. The Relationship Management Function specified by [RMF] provides the following services to add, remove, change and display the relationship attribute information for managed objects, and to report events of relationship activities. Relationship Creation is a service which allows the managing process (or the invoker) to request the managed process (or the performer) to add a value to the specified relationship attribute of the specified managed objects in order to reflect a newly created (or to be created) relationship. Relationship Deletion is a service which allows the invoker to request the performer to remove the value(s) from the set of its relationship attributes of specified managed objects in order to reflect a newly removed (or to be removed) relationship. Relationship Changing is a service which allows the invoker to request the performer to replace one or more value(s) of the specified relationship attributes of the specified managed objects. Relationship Listing is a service which allows the invoker to request the performer to return the value(s) of the specified relationship attribute(s) of the specified / selected managed object. Related Object Listing is a service which allows the invoker to request the performer to return the name(s) and the other specified attribute(s) and value(s) of the selected managed objects which have the specified relationship attribute(s) value(s) which match successfully to the target managed object. Relationship Creation Reporting is a service which allows a managed process to report the relationship creation event to the managing process(es) (not necessarily the original managing process). Relationship Deletion Reporting is a service which allows the managed process to report the relationship deletion event to the other process(es) (not necessarily the original managing process). Relationship Change Reporting is a service which allows the managed process to report the Relationship Change Event to the managing process (not necessarily the original managing process). Since a relationship is represented by a pair of bound relationship attributes, in order to keep the integrity of relationship management information, it takes at least two services to complete a transaction. The transaction processing and the commitment control are outside the scope of this section. Editor's Note: The following sections are to be agreed upon. 18.5.3.1 Relationship Creation Service Agreements Editor's Note: This service is mapped to M-SET CMIS Services. It is assumed that the CMIS Add/Remove of attribute value function is supported in Phase 1 here. CMIS M-SET Request parameters clarifications: is to be used. This parameter specifies a set of (at least one) tuples: for the relationship to be created. CMIS M-SET Response parameters clarifications: This parameter shall not be returned. Refer to section 18.6. This parameter specifies a set of for the relation- ship created. Refer to section 18.6. 18.5.3.2 Relationship Deletion Service Agreements This Service shall use the M-SET CMIS service to carry its information with the following clarification: CMIS M-SET request parameters: This parameter specifies the base of the Class of the managed objects with whose instance a relationship with another managed object is to be deleted. This parameter specifies the instance of the base of managed object with whom a relationship with another managed object is to be deleted. This parameter specifies a set of . CMIS M-SET Response parameters: Refer to section 18.6. This parameter specifies a set of . Refer to section 18.6. 18.5.3.3 Relationship Change Service Agreements This Service shall use M-SET CMIS service to carry its information with the following clarification: CMIS M-SET request parameters: This parameter specifies the base of the Class of the managed objects with whose instance a relationship with another Managed Object is to be changed. This parameter specifies the instance of the base managed object with whom a relationship with another managed object is to be changed. This parameter specifies a set of . Editor's Note: This has to be verified, i.e., whether the CMIS DAD2 supports this old and new value syntax. If this is the case, we have to replace the whole set-value of the attribute. CMIS M-SET Response parameters: This parameter shall not be returned. Refer to section 18.6. This parameter specifies a set of . Refer to section 18.6. 18.5.3.4 Relationship Listing Service Agreements This Service shall use M-GET CMIS service to carry its information with the following clarification: CMIS M-GET request parameters: This parameter specifies the base of the managed object class with which instances, the value(s) of their specified relationship attributes, are to be listed. This parameter specifies the instance of the managed objects. This parameter specifies the list of relationship attributes with their relationship value(s) which is(are) to be returned. CMIS M-GET Response parameters: Refer to section 18.6. This parameter returns a set of . Refer to section 18.6. 18.5.3.5 Related Object Listing Service Agreements: This Service shall use M-GET CMIS service to carry its information with the following clarification: CMIS M-GET request parameters: This parameter specifies the Class of the base managed object from which the related object instances are to be selected for filtering. This parameter specifies the instance of the base Managed Object from which the related object instances are to be selected for filtering. All 3 options are allowed and supported. The filter should specify the relationship attribute name and its value to be matched (i.e. the name of the target object to which the selected objects are related). Refer to section 18.6. CMIS M-GET Response parameters: Refer to section 18.6. This parameter returns a set of . Refer to section 18.6. 18.5.3.6 Relationship Creation Report Service Agreements This service uses the unconfirmed M-EVENT-REPORT CMIS service to convey its reporting information. It also uses the event reporting control Function specified in section 18.5.5.1 to report the events. CMIS M-EVENT-REPORT request parameters Refer to section 18.6. Refer to section 18.6. This parameter should identify the Event with the object identifier defined in [OMF]. This parameter will include a set of . 18.5.3.7 Relationship Deletion Report Service Agreements This service uses the unconfirmed M-EVENT-REPORT CMIS service to convey its reporting information. It also uses the event reporting control Function specified in section 18.5.5.1 to report the events. CMIS M-EVENT-REPORT request parameters Refer to section 18.6. Refer to section 18.6. This parameter should identify the event type with the object identifier defined in [OMF]. This parameter will include a set of . 18.5.3.8 Relationship Change Report Service Agreements This service uses the unconfirmed M-EVENT-REPORT CMIS service to convey its reporting information. It also uses the event reporting control Function specified in section 18.5.5.1 to report the events. CMIS M-EVENT-REPORT request parameters: Refer to section 18.6. Refer to section 18.6. This parameter should identify the Event with the object identifier defined in [OMF]. This parameter will include a set of tuples of . 18.5.3.9 The usage of compound Relationship attributes `Group' Agreements No Relationship attribute is to be used in Relationship Creation and Relationship Changing management. When a relationship attribute is used in Relationship Deletion management, all relationship attribute values of the group of the selected managed object instances will be set to "null". Use of the Relationship attribute is permitted for Relationship listing and Related Object Listing. Refer to [RMF] for more detail. 18.5.3.10 The usage of the combined Add/Change/Delete Services It is possible to combine the Add, Change, Delete services in one CMIS operation, but until its complications are fully understood, it is not to be used in Phase 1. Editor's Note: Need an example here to show the ordering operations on attributes, etc. 18.5.4 Error Reporting and Information Retrieval Function: Editor's Note: Tutorial Material. Currently there are two services within the Error Reporting and Information Retrieval Function standard [ERIRF] that provide the ability to report errors from one open system to another system and to retrieve information from an open system. The two services are: (1) the Error Reporting Service, and (2) the Information Retrieval Service. For the NMSIG Phase 1 IAs, only the Error Reporting Service of the [ERIRF] is required. 18.5.4.1 Error Reporting Service Agreements: Editor's Note: Tutorial Material. The Structure of Management Information standard [MIM] specifies that managed objects may emit notifications. CMIS/CMIP provides the facility for reporting such notifications to a managing system. The Event Forwarding Control Function of the Management Service Control standard [MSC] provides the capability of forwarding event reports to specified destinations. This forwarding is based on information contained within the event. The Error Reporting Service defines information to be contained in the event report. This information is provided to help with understanding the cause of faults, and other information related to its side effects. This information may also be referenced within an event forwarding discriminator of the Event Forwarding Control Function for determining if and where error reports should be sent. The type of possible errors defined in [ERIRF] are: (1) communication failure: errors associated with the process of sending information from one system to another. Some examples are: loss of signal, framing error, transmission error, and call establishment error. (2) quality of service failure: errors associated with the degradation in the quality of performing a specific service by a service provider to a service user. Some examples are: response time excessive, queue size exceeded, bandwidth reduced, and retransmission rate excessive. (3) processing failure: errors associated with processing input to produce the desired output. This is related to a software fault. Some examples are: storage capacity problem, version mismatch, corrupted data, CPU cycle limit exceeded, software error, and out of memory error. (4) equipment failure: errors associated with equipment fault. Some examples are: power problem, timing problem, trunk card problem, line card problem, processor problem, terminal problem, external device problem, dataset problem, and multiplexer problem. (5) environmental failure: errors associated with a condition relating to an enclosure in which the communications equipment resides. The errors may affect the performance of the equipment. Some examples are: smoke detection, enclosure door is open, high/low ambient temperature, high/low humidity, and intrusion is detected. Editor's Note: The above description is very general. We need contributions to further define the ProbableCauseCode. If we follow the standard, we may bite off having to explain how to categorize every error type, when to use each, when not to use each, what precedence order should be employed, etc. This is not a small task. The following sections specify the Model, the Support Managed Object and the Error Reporting Service for the Phase 1 IAs. 18.5.4.1.1 Error Reporting Model Agreements: For the Error Reporting Service, the Event Reporting Control Model [sec. 18.5.5.1.1] applies. 18.5.4.1.2 Support Managed Object Agreements: The Event Forwarding Discriminator object is defined in [DSO]. 18.5.4.1.3 Error Reporting Service Agreements: The following agreements and clarifications pertinent to section 8.1 of the base standard [ERIRF] and regarding the semantics of the unconfirmed CMIS M- Event-Report service (sec. 8.2.1 of [CMIS]) are supported by the Phase 1 network management IAs. All CMIS parameters are mandatory, except where noted below. CMIS M-EVENT-REPORT request parameters: -------------------------------------- This parameter specifies the M-Event-Report operation invocation identifier, it is to be used to distinguish this operation from others. This parameter is set to . This parameter specifies the managed object class of the managed object instance which is reporting an error(s). This parameter specifies the instance of the managed object that is reporting an error(s). This parameter specifies the type of error being reported. The five possible types are: - Communication Error - Quality of Service Error - Processing Error - Equipment Error - Environment Error The values for the error type are defined in [ERIRF]. This parameter specifies the time the error(s) occurred. Reference section 18.6.2.3 for further IAs. For the network management Phase 1 IAs, this parameter is optional. The fields within the parameter are also optional, except where defined by the managed object class definition [MIL] or specified in the [ERIRF], [DMO] or [DMA] standards. The parameter is present if at least one of the fields below is present. The possible fields are: , , , , , , , , and . This field contains the most probable reason for the error indicated in the eventType. This field contains the level of network degradation caused by the named error. Five levels of severity are defined by the base standard; they are: critical, major, minor, warning, and indeterminate. The values for the Severity code are defined in Annex A of [DMA]. This field contains the current trend in the type of error being reported. There are two values for this attribute: TRUE, implies increase in severity, FALSE, implies decrease in severity, as defined in Annex A of [DMA]. This field contains a value which indicates whether the failed object has been backed up or not. There are two possible values for this field: TRUE, implies backed up, and FALSE, implies not backed up, as defined in Annex A of [DMA]. This field contains information which may assist to diagnose the fault. Editor's Note: Tutorial Material. Examples of such information may include counter values, threshold values, and configuration state, etc. as defined by managed object class. This field contains the values of the threshold which caused the error to be generated. The subfields are defined in [DMA]. This field contains information, defined in Annex A of [DMA], about the administrative and operational state of the managed object at the time the error occurred. This field contains information which may propose action to correct the fault. Editor's Note: Tutorial Material. This information is defined by the managed object class. This field contains other relevant information about the managed object at the time the error occurred. Editor's Note: Tutorial Material. This information is defined by the managed object. 18.5.4.2 Information Retrieval Function Agreements: 18.5.4.2.1 Information Retrieval Service Agreements: 18.5.5 Management Service Control Functions Agreements: Editor's Note: Tutorial Material. There are two control functions in this category to provide the ability to specify criteria under which event operations can be controlled. The two functions are: (1) Event Reporting Control Function, and (2) Service Access Control Function. The NMSIG Phase 1 network management agreements support only the Event Reporting Control Function. The Service Access Control Function is for further study. 18.5.5.1 Event Reporting Control Function Agreements: Editor's Note: Tutorial Material. The Event Reporting Control function provides services by which event reporting can be distributed and controlled. Event report distribution means the selection of chosen events to be reported to some designated system(s) or process(es) within some selected time period. These selections are done by a filtering process using the "DiscriminatorConstruct" attribute of the "Event Forwarding Discriminator" object. Event Reporting Control is the ability to initiate, terminate, suspend, or resume event reporting through the manipulation of an Event Forwarding Discriminator object specified in section 18.5.5.1.1. In addition, Event Reporting Control can further alter event report distribution behavior by changing the distribution attributes in an Event Forwarding Discriminator object (DiscriminatorConstruct, BeginTime and EndTime etc...). The following sections contain the NMSIG Phase 1 network management agreements pertaining to the Event Reporting Control Model [RMF], the Support Managed Object to facilitate the Event Reporting Control Function [RMF], and the following services (defined in [RMF]): o Initiate event reporting service o Terminate event reporting service o Suspend event reporting service o Resume event reporting service o Modify event forwarding discriminator attributes service o Retrieve event forwarding discriminator attributes service. 18.5.5.1.1 Event Reporting Control Model Agreements: The Event Reporting Control function is based on the following assumptions, pictured below: (1) There is (at least) one managed object capable of generating notifications. (2) There exists a conceptual event detection and processing function which receives the local notifications and forms potential event reports. (3) There exist Event Forwarding Discriminator objects which are used for determining whether potential event reports can become real event reports which are then emitted from the open system. (4) There exists a conceptual process which guides all potential event reports to all Event Forwarding Discriminators for evaluation. (5) There exists a conceptual process which evaluates the potential event reports using the Event Forwarding Discriminator attributes (DiscriminatorConstruct, BeginTime, EndTime, Destination ...) to determine whether the potential event reports are to be reported to the specified destination system(s). Event Forwarding Discriminator Control Functions +--------------+ (Initiate, Terminate, Suspend, +---------------+ M.O. | Resume, Update, etc...) | Managed Object|------+ | | +---------------+ | | | | | | | | Notifications | | | | | | | | | | +--------|-----------|--------------------| |---------+ | Agent v v v v | | +----------------+ +--------------+ | | | Event Detection|----------> | Event Fwding |--------> | | and | potential | Discriminator| |Event | | Processing | Events | Processing | |Reports | | |----------> | |--------> | +----------------+ +--------------+ | | | +------------------------------------------------------+ 18.5.5.1.2 Support Managed Object - Event Forwarding Discriminator Agreements Editor's Note: Tutorial Material. The Event Report Discriminator is a management service control discriminator which is a managed object providing for specification of criteria relevant to selecting events of interest to be reported to other open systems. The criteria must be satisfied by potential event reports related to managed objects before the event report is forwarded to a particular destination. That destination is also specified by the discriminator and is the address of a remote managing process. Editor's Note: Tutorial Material. The Event Forwarding Discriminator has the following attributes: (1) DiscriminatorID: This attribute uniquely identifies the discriminator. (2) DiscriminatorConstruct: This attribute specifies the conditions which define when an event report should be generated after a event occurs. Each event which occurs in an event generating system has to be evaluated for passing the filter construct. Only those events that pass (match) the filter will result in an event report being sent to the destination system(s). (3) ManagementUserIdentification: This attribute identifies the systems on whose behalf the event report is performed. This usually indicates the managing system. Editor's Note: Should the Phase 1 network management IA's limit this to containing only a single system at a time? This would mean we would not require use of PDAD2 for CMIS/P. (4) Discriminator State: This attribute specifies the state in which the Event Report Discriminator object is to be created. The Discriminator object may be created in a "locked" or "unlocked" state. (5) Begin Time: This attribute identifies the beginning time of a 24 hour interval during which the event report service is active. (6) End Time: This attribute identifies the ending time of a 24 hour interval during which the event report service is available. An example: If Begin Time = 8:00 AM and End Time = 5 PM, then event reports will only be sent between the hours of 8:00 AM through 5:00 PM on the basis of this discriminator. In Phase 1, one Event Forwarding Discriminator is defined for each destination process to which the event reports are to be sent. 18.5.5.1.3 Initiate Event Reporting Service Agreements: Note to the Editor: Tutorial material in all subsequent sections needs to be scanned for scenario information and that material should be provided to the scenario section editor. Editor's Note: Tutorial Material. A user at a managing system may desire that particular events generated at an event generating system be reported to a destination system. To achieve this, the user, from the managing system, will need to create Event Forwarding Discriminator objects for those particular events with the proper parameters at the event generating system. Each Event Forwarding Discriminator object must include a DiscriminatorConstruct which specifies the desired filtering conditions under which the designated event should be reported to the destination system. A managing system must issue a single M-CREATE CMIS service request to an event generating system to create a single Event Forwarding Discriminator. Multiple discriminators require multiple M-CREATE CMIS service requests. Editor's Note: Once the Event Forwarding Discriminator object is created, is there an implicit assumption that the newly created object forms part of the context implied by the current association context? Can the Event Forwarding discriminator object be managed by applications using other associations other than the one over which the CMIS M-CREATE request was issued, or do they need to reassociate? This issue will be determined during the association policy discussions. The following agreements and clarifications pertinent to section 8.1 of the base standard [MSC] and regarding the semantics of the confirmed CMIS M-CREATE service (sec. 8.3.4 of [CMIS]) are supported by the Phase 1 network management IAs. All CMIS parameters are mandatory, except where noted below. CMIS M-CREATE request parameters: The parameter value will always be the class. This parameter must be included in the request. (1) If this parameter is used in the request, it will identify the instance of the discriminator class by providing the DiscriminatorID and names of any superiors. (2) Otherwise, the performing CMISE- service-user will assign a value to identify the instance. Editor's Note: Should we agree on using (1) always in the request? Note to the Editor: Incorporate comments from the Object Creation section, later on. Refer to section 18.6.2.4 and 18.6.3.1.2 (Management Communications) of this chapter for agreements pertaining to this parameter. Refer to section 18.6 (Management Communications) of this chapter for agreements pertaining to this parameter. This field refers to the Event Forwarding Discriminator object attributes (sec. 18.5.5.1.2 of this chapter). Any attributes provided by the CMIS-service-user will be used to initialise the corresponding attributes for the newly created instance. The attribute is set to "unlocked" by default. CMIS M-CREATE response parameters: Same as request This parameter is always returned by the response to indicate the instance name of the newly created object. This parameter specifies ALL the object attributes and values for the NEWLY created Event Forwarding Discriminator. Refer to section 18.6.2.3 and 18.6.3.1.3 (Management Communications) of this chapter for agreements pertaining to parameter. 18.5.5.1.4 Terminate Event Reporting Service Agreements: Editor's Note: Tutorial Material. A user in a managing system can use this service to turn off the reporting of events from a specific event generating system. To achieve that, the user will need to delete the Event Forwarding discriminator object(s) of the unwanted event(s) on the system. The absence of such a discriminator will not stop the generation of potential event reports caused by the managed object, it simply disables event reporting of the particular potential events from the event generating system. A managing system must issue a single M-DELETE CMIS service request to the event generating system to delete exactly one Event Forwarding Discriminator. Multiple M-DELETE CMIS service requests are needed to delete multiple discriminators. The following agreements and clarifications pertinent to section 8.2 of the base standard [MSC] and regarding the semantics of the confirmed CMIS M-DELETE service (sec. 8.3.5 of [CMIS]) are supported by the Phase 1 network management IAs. All CMIS parameters are mandatory, except where noted below. CMIS M-DELETE request parameters: Refer to section 18.6.2.4 and 18.6.3.1.2 (Management Communications) of this chapter for agreements pertaining to this parameter. is required. CMIS M-DELETE response parameters: Refer to section 18.6 (Management Communications) of this chapter for agreements pertaining to these parameters. Refer to section 18.6.2.3 and 18.6.3.1.3 (Management Communications) of this chapter for agreements pertaining to this parameter. 18.5.5.1.5 Suspend Event Reporting Service Agreements: Editor's Note: Tutorial Material. This service temporarily stops event reports from being sent from the event generating system to the destination system, yet retains the ability to resume the reporting if desired. To suspend event reporting, a managing system must issue an M-SET CMIS service request to the event generating system to change the value of the attribute to "locked". When the attribute is "locked", any events that would normally occur for this discriminator are discarded and NOT queued up for later transmission. The following agreements and clarifications pertinent to section 8.3 of the base standard [MSC] and regarding the semantics of the confirmed CMIS M-SET service (sec. 8.3.2 of [CMIS]) are supported by the Phase 1 network management IAs. All CMIS parameters are mandatory, except where noted below. CMIS M-SET request parameters: This parameter will be set to . Refer to section 18.6.2.4 and 18.6.3.1.2 (Management Communications) of this chapter for agreements pertaining to this parameter. is required. This parameter will include the Event Forwarding Discriminator attribute with the value of the attribute to be "locked". (See sec. 18.5.5.1.2 of this chapter). CMIS M-SET response parameters: Refer to section 18.6 (Management Communica- tions) of this chapter for agreements pertaining to these parameters. Refer to section 18.6.2.3 and 18.6.3.1.3 (Management Communications) of this chapter for agreements pertaining to this parameter. 18.5.5.1.6 Resume Event Reporting Service Agreements: Editor's Note: Tutorial Material. This service enables event reporting for particular types of events, thereby permitting events to be sent from a specific event generating system to a specific destination system. This operation is used to resume the reporting of events that was previously suspended. To resume event reporting, the managing system must issue an M-SET CMIS service request to an event generating system to change the attribute to . The following agreements and clarifications pertinent to section 8.4 of the base standard [MSC] and regarding the semantics of the confirmed CMIS M-SET service (sec. 8.3.2 of [CMIS]) are supported by the Phase 1 network management IAs. All CMIS parameters are mandatory and are as specified in section 18.5.5.1.5, with the following difference: This parameter will contain the Event Forwarding Discriminator attribute . (See sec. 18.5.5.1.2 of this chapter). The value of the attribute will be set to "unlocked". 18.5.5.1.7 Modify Event Forwarding Discriminator Attributes Service Agreements: Editor's Note: Tutorial Material. A managing system can change the conditions of event reporting for some selected events by changing the values of the Event Forwarding Discriminator attributes which are used in the processing associated with event distribution and control. For example, the user may want to move/modify the reporting of a specific type of event to a different destination system, or change the frequency of the event reporting. To achieve such results, a managing system will need to modify the value of the and/or attributes to reflect the new needs. This service can be used for locked or unlocked Event Forwarding Discriminator objects. To change attributes of one specific Event Forwarding Discriminator in one specific event generating system, a managing system must issue a single M-SET CMIS service request to the event generating system. Changes to multiple discriminators in a single event generating system require multiple M-SET CMIS service requests. The following agreements and clarifications pertinent to section 8.5 of the base standard [MSC] and regarding the semantics of the confirmed CMIS M-SET service (sec. 8.3.2 of [CMIS]) are supported by the Phase 1 network management IAs. All CMIS parameters are mandatory, except where noted below. CMIS M-SET request parameters: This parameter will be set to . Refer to sections 18.6.2.4 and 18.6.3.1.2 (Management Communications) of this chapter for agreements pertaining to this parameter. is required. This parameter will specify the Event Forwarding Discriminator attributes to be modified. The modifiable attributes are: , , , , . Editor's note: This parameter is going to be replaced by the parameter, once PDAD2 for CMIS/P is adopted. CMIS M-SET response parameters: Refer to section 18.6 (Management Communications) of this chapter for agreements pertaining to these parameters. This parameter will specify the Event Forwarding Discriminator attributes that were modified. Refer to sections 18.6.2.3 and 18.6.3.1.3 (Management Communications) of this chapter for agreements pertaining to this parameter. 18.5.5.1.8 Retrieve Event Forwarding Discriminator Attributes Service Agreements: To examine the Event Reporting Discriminator parameters associated with a specific event, a managing system must issue an M-GET CMIS service request to an event generating system to retrieve the values of specific discriminator attributes. The following agreements and clarifications pertinent to section 8.5 of the base standard [MSC] and regarding the semantics of the confirmed CMIS M-GET service (sec. 8.3.1 of [CMIS]) are supported by the Phase 1 network management IAs. All CMIS parameters are mandatory, except where noted below. CMIS M-GET request parameters: Refer to sections 18.6.2.4 and 18.6.3.1.2 (Management Communications) of this chapter for agreements pertaining to this parameter. is required. This parameter will specify the Event Forwarding Discriminator attributes to be retrieved. The readable attributes are: , , , , , . Default gets all attributes. CMIS M-GET response parameters: Refer to section 18.6 (Management Communications) of this chapter for agreements pertaining to these parameters. This parameter will specify the retrieved Event Forwarding Discriminator attributes. Refer to sections 18.6.2.3 and 18.6.3.1.3 (Management Communications) of this chapter for agreements pertaining to this parameter. 18.5.5.2 Service Access Control Function Agreements: Editor's Note: This section is for future study. 18.5.6 Event Logging Control Function Agreements: 18.5.6.1 Event Logging Model Agreements: 18.5.6.2 Support Managed Object Agreements: 18.5.6.2.1 Log Discriminator Agreements: 18.5.6.2.2 LOG Agreements: 18.5.6.3 Log Control Services Agreements: 18.5.6.3.1 Initiate Event Logging Service Agreements: 18.5.6.3.2 Terminate Event Logging Service Agreements: 18.5.6.3.3 Suspend Event Logging Service Agreements: 18.5.6.3.4 Resume Event Logging Service Agreements: 18.5.6.3.5 Modify Event Logging Parameters Service Agreements: 18.5.6.3.6 Event Log Parameters Retrieval Service Agreements: 18.6 MANAGEMENT COMMUNICATIONS This section identifies, in detail, use of the management communications services and protocols, based on the standards defined in [CMIS], [CMIP], [ADDRMVS/P] and [CANGETS/P]. This section covers the agreements pertaining to the use of associations over which to carry management PDUs, agreements pertaining to the services offered to a CMIS Service User (in terms of the functions defined in sec. 18.5), agreements pertaining to the protocol used to convey the management PDUs, and agreements pertaining to the services required of other layers in order to convey the management PDUs defined. 18.6.1 Association Policies Editor's note: Tutorial Material: This draft of the Association Policy section of the Phase 1 IAs represents the output from an interim NMSIG meeting held in Peabody MA in November 1989. The purpose of the meeting was to align the draft section from the July Workshop with output from the Florence meetings and with the issues from the NMSIG Issue Log. As a result of review by the December 1989 OIW NMSIG Meeting, some additional changes were made to this text. The participants at the interim meeting summarized the issues into 8 items. These are listed here to enable reviewers to understand the premise for the subsequent text. Issue 1: Should there be agreements about arbitration among competing requests where agents allow multiple associations to managing systems? It was decided that this was really a matter for an agent implementation. If an agent does some form of arbitration (eg; temporarily lock out a request to modify an object while a prior request is being honored), it must indicate this in some agreed upon way so that the managing system can distinguish between this situation and some other error, such as access denied or no such object. This issue is not related to association types or to access control. The recommendation was placed in an appropriate section of the CMIS/P agreements in 18.6.3. Issue 2: What is the retry policy, if any? It was proposed that we make some suggestions and have them reviewed by the Workshop. See section 18.6.1.4. Issue 3: What are the connect and disconnect policies, if any? See section 18.6.1.4. Issue 4: How are the roles of managing and managed system determined? It was felt that it was necessary to determine which role a system is playing on an association and that the Application Context Name work in the Arhus output for SMO fit the bill. See section 18.6.1.2. Issue 5: Handling of events vs command/control. Issue 6: Handling of monitoring vs control. Re Issues 5 and 6, it was felt that managed and managing systems may wish to restrict the types of functions that may be performed on a particular association. The proposal for addressing this issue is in section 18.6.1.2. Issue 7: Views of a MIB on an association. It was decided to keep the output from the July workshop which states that we make no agreements regarding the scope of an association as it applies to the objects made accessible over that association. The arbitration process adds a slight wrinkle though. See section 18.6.1.4. Issue 8: Are we making recommendations or requirements? This draft has both. It was never really decided if recommendations are appropriate in these agreements. If they aren't then we will have to decide whether to drop the recommendations in this draft or make them requirements. Associations are established using the procedures described in [ACSEP] with recommendations and extensions described in these implementation agreements. Phase 1 IAs specify the different types of associations that may be established between managing and managed systems (see 18.6.1.2). The type of a given association is determined by the exchange of appropriate application context information between the systems using a negotiation process. Phase 1 IAs recommend that managed systems reserve resources for at least one association for event reporting (see 18.6.1.3). Phase 1 IAs require the use of A-RELEASE instead of A-ABORT. Phase 1 IAs also make recommendations regarding parameters affecting the scope of managed objects and span of time for an association and synchronization among multiple associations (see 18.6.1.4). Phase 1 IAs specify the access control information to be used in the establishment of an association (see 18.6.1.5). 18.6.1.1 ACSE Services The A-ASSOCIATE and A-RELEASE ACSE services are used as specified in [ACSE]. The Phase 1 IAs make certain requirements as to the use of the APDU fields noted below. Usage of all other fields is left to the implementor. AE-TITLE (Calling AP Title and Calling AE Qualifier) usage is specified in 18.6.1.2. Application Context Name usage is specified in 18.6.1.2. ACSE User Information consists of three parameters (specified in [CMIS]): Functional Units, Access Control and CMIS User Information. Refer to section 18.6.3 for agreements relating to Functional Units. Refer to section 18.6.1.5 for agreements relating to Access Control. The Phase 1 IAs make no agreements relating to CMIS User Information. 18.6.1.2 Association Types The Phase 1 IAs specify that four types of association may be negotiated between managing and managed systems. These types are: Event M-EVENT-REPORTs may be sent by the managed system; no other CMIP PDUs are allowed Event/Monitor same as Event type except that, in addition, the managing system may also issue M-GET requests and receive M-GET responses over the association Monitor/Control managing system may issue M-GET, M-SET, M-CREATE, M-DELETE and M-ACTION requests over the association; no event reporting is allowed Full Mgr/Agent all functions must be supported The negotiation process specified for the Phase 1 IAs uses the A-ASSOCIATE and A-RELEASE services as specified in [ACSEP]. Application Context Name [SMO] is used to determine the requestor's "role" in an association (managing or managed system) and to determine the type of the association. The following negotiation rules are specified by the Phase 1 IAs: Editor's Note: The SIG left open the question of using Application Context Names for both role and type determination. The editor investigated further to find out if there were any restrictions that would prevent such usage. Having found no restrictions, the editor updated the text to provide more detail in this direction. Editor's Note: We need to assign Application Context Names. I suggest that we register appropriate object names under the NMSIG arc. I'll take a stab at the proper format (see RASIG output...sec. 6 of the Working Document) and propose some names as a placeholder until we determine the actual format/names. (Wordsmithing and format advice are welcome.) {iso(1) identified-organization(3) oiw(14) nmsig(2) manager-event-association(x)} {iso(1) identified-organization(3) oiw(14) nmsig(2) manager-event-monitor-association(x)} {iso(1) identified-organization(3) oiw(14) nmsig(2) manager-monitor-control-association(x)} {iso(1) identified-organization(3) oiw(14) nmsig(2) manager-full-association(x)} {iso(1) identified-organization(3) oiw(14) nmsig(2) agent-event-association(x)} Editor's Note: Tutorial Material: Ref: [SMO] Annex A The Application Context Name (ACN) indicates the role of the initiator of an association. The responder may alter the type indication to request a change in the type. Note that the proposed ACNs above follow the agreements on which system may request a particular type of association. Thus there is a single agent initiated ACN since agents (managed systems) may only initiate event reporting associations. The ACNs in these agreements refine those defined in Annex A [SMO] and are used in the same fashion. Editor's Note: We will need to add text relating to negotiation of System Management Function functional units as changes to this section as the relevant standards (10164-*) are updated. It is anticipated that the work in N740 will be used as the basis. 1. A managed system may only request an Event association and, in fact, must create an Event association if it has an event to report and no suitable association already exists. 2. Managing systems may request any association type. 3. An association is created by the requesting system issuing an A-ASSOCIATE request with the requestor's AE-TITLE and the desired application context. The responding system then returns either 1) an A-ASSOCIATE response with the requestor's AE-TITLE and the application context which it wishes to accept or 2) an A-ASSOCIATE response rejecting the association. 4. Managed systems may negotiate "downward" from Full to Monitor/Control, Event/Monitor or Event by returning the new application context in the A-ASSOCIATE response to the managing system during the association creation process. In the same fashion, managed systems may negotiate from Event/Monitor to Event. 5. When a managing system receives an application context in an A-ASSOCIATE response that differs from the context sent in an A-ASSOCIATE request it may either proceed with the new context or refuse the new context by issuing an A-RELEASE request. Editor's Note: A-RELEASE is used when the requestor does not agree with the new context. A-ABORT is used for invalid negotiation. Note that a system may play both managing and managed system roles, but not on the same association. 18.6.1.3 Events Phase 1 IAs recommend that managed systems make resources available for at least one association for the purposes of event reporting. The resources allocated to an association should be re-useable. That is, if the system must report an event to multiple managers, it may have to repeatedly utilize the resources for an association to each of the managing systems. This recommendation is made to ensure that events are not lost due to a lack of associations. Editor's Note: The status of 18.6.1.3 as a recommendation rather than a requirement is open for comments. 18.6.1.4 Scope/Span of an Association Editor's Note: Discussions at the Florence meeting indicate the potential for an "association policy object". This object would allow for the maintenance of parameters pertaining to the behavior of an association. These parameters would include such things as number of retries and inactivity timers. This version of section 18.6 was written so that if this proposal comes to fruition, the agreements can be migrated to the ap-object by "transferring" the parameters to the object itself. The Phase 1 IAs specify no process for negotiating the scope of an association as it pertains to the objects that may be managed within the context of that association. Editor's Note: Text in the December 1989 Workshop draft document regarding arbitration between requests from multiple managers was moved from this section to the CMIS/P section (sec. 18.6.3). The Phase 1 IAs specify no process for negotiating a time span of an association. The managing or managed system may terminate an association based upon an implementation specific algorithm governing association durations. Editor's Note: Text in the December 1989 Workshop draft document regarding potential parameters for managing time span and retries for associations was removed from this section. The text has been retained "off-line" at the direction of the NMSIG. Underlying services such as ACSE may also cause the termination of an association. The Phase 1 IAs require that associations be terminated with A-RELEASE to avoid loss of information in an association. Editor's Note: Tutorial Material: If A-ABORT is used to terminate an association, there exists a potential for loss of information such as pending events or confirmations. A-ABORT must be used, however, when a protocol violation occurs or where an association is not yet established. 18.6.1.5 Other Aspects of Associations Editor's Note: The access control information in this section is based on some notes from a joint NMSIG/Security SIG meeting that took place some time ago. We should review this with the Security SIG to make sure we are still in agreement and get more information on usage and encoding. This review is tentatively planned for the March 1990 OIW. The Phase 1 IAs specify that the following information may be used in establishing an association. A managed system, if it requires access control information, must use this format. Unused fields must contain nulls. Field Name Purpose ----- -------------- ---------------------------- 1 Length length of access control data 2 Initiating Person 3 Process Type 4 Process ID 5 Authorization password 6 Access Privileges 7 Audit Requirements 8 Integrity universal closed community Seal checksum; message authenti- cation code 9 Optional 0-n bytes of optional data Information 18.6.2 General Agreements on Users of CMIS These agreements are based on the standard defined in [CMIS] and [CMIP] and constrain the users of CMIS services and not the implementation of CMIP itself. 18.6.2.1 Object Naming Object Naming will be accomplished using Distinguished Names as specified in section 18.7.2. 18.6.2.2 Multiple Object Selection Multiple Object Selection applies to all management operations except Event Report and Create. 18.6.2.2.1 Scoping These network management IAs specify that scoping will be used as specified in [CMIS] 6.5.1, 8.3.1.1.5, 8.3.2.1.6, 8.3.3.1.6, 8.3.5.1.5. 18.6.2.2.2 Filtering These network management IAs specify that filtering will be used as specified in [CMIS] 6.5.2, 8.3.1.1.6, 8.3.2.1.7, 8.3.3.1.7, 8.3.5.1.6. If a system receives a filter parameter that it is unable to process, it must return the error 'complexityLimitation', including the CMISFilter requested. If, in the process of filtering from a set of selected entities, there are no managed objects selected, the system must return an empty reply consisting of an Invoke ID and no response argument. 18.6.2.2.3 Synchronization In order to support interoperability between managing systems and managed systems, these network management IAs define that the default synchronization (i.e., BestEffort) must be supported by all conforming systems. Atomic synchronization may also be supported as an option. If a performer is unable to comply with a synchronization request specified by an invoker, the performer must return the error 'syncNotSupported' with the parameter indicating the synchronization not supported. 18.6.2.2.4 Linked Replies These network management IAs specify the use of linked replies as specified in [CMIS] 7.1, 7.2.3. 18.6.2.2.5 Request Collision Handling A managed system may optionally implement an algorithm for preventing collision among multiple requests. If this algorithm temporarily rejects one or more requests, the managed system must reject with a `resourceLimitation' error. 18.6.2.3 Current/Event Time The time if provided, should be as close as possible to, but not before, the actual time the operation occurred in order to provide the most accurate timestamp for temporal ordering of operations and events on a single open system. For these network management IAs, the encoding of the Current Time parameters is ASN.1 Generalised Time, UTC Type, as specified in [ASN1] clause 32.3, b) and c), with the precision of the time representation indicating the granularity of the time measurement. For example, the string 19890613123012.333-0500 represents a local time of 12:30:12 (and 333 msecs) on 13th June 1989, in a time zone which is 5 hours behind GMT. 18.6.2.4 Access Control Conformant implementations are not required to use this field. The Access Control field, if provided by the invoker in CMIP PDUs, may be ignored by responding systems which do not support access control. These systems must not reject a PDU on the basis of the presence of access information. The invoker may interpret this as acceptance of the access control parameter. 18.6.2.5 CMIS Functional Units Only the Kernel Functional Unit must be supported. Other functional units except Extended Service are optional and their use must be negotiated as specified in [CMIS]. Extended Service is not within the scope of these agreements. Negotiation for its "non use" must be supported. 18.6.2.6 CMIP Parameters The CMIP globalForm must be used for the following parameters: action type id attribute id event type id object class Use of localForm is outside the scope of these agreements. 18.6.3 Specific Agreements on Users of CMIS These agreements are based on the standard defined in [CMIS]. The agreements in this section have been defined in terms of those capabilities necessary to support the functions and services defined in section 18.5 (Management Functions and Services) and in terms of the Association Policies defined in section 18.6.1. These agreements constrain the users of CMIS services and not the implementation of CMIP itself. The parameter presence information in the tables in this section are repeated from [CMIS] and have the same meaning as in the standard. They are repeated for reader convenience. 18.6.3.1 M-Event-Report The following agreements and clarifications, pertinent to section 8.2.1 of the base standard [CMIS] and section 6.3 of the base standard [CMIP] and regarding the M-EVENT-REPORT service, are included within these network management IAs. Section 18.5 (Management Functions and Services) defines the various types of Event Reports that may be sent. 18.6.3.1.1 Event Argument All arguments defined for the particular event type of the managed object class (see sec. 18.7, Management Information Agreements) for the M-EVENT-REPORT must be supplied in the Event Argument parameter. 18.6.3.1.2 Parameter Agreements Table 18.1. M-EVENT REPORT Parameters Item Parameter Name Req/Ind Rsp/Conf Text Reference 1 Invoke Identifier M M= 18.6.4 2 Mode M - 3 Managed Object Class M U 18.6.2.6 4 Managed Object Instance M U 18.6.2.1 5 Event Type M C= 18.6.2.6 6 Event Time U - 18.6.2.3 7 Event Information U - 18.6.3.1.1 8 Current Time - U 18.6.2.3 9 Event Reply - C 10 Errors - C 18.6.3.2 M-Get The following agreements and clarifications, pertinent to section 8.3.1 of the base standard [CMIS] and section 6.4 of the base standard [CMIP] and regarding the M-GET service, are included within these network management IAs. 18.6.3.2.1 Successful Response For a successful M-GET operation, the performer shall return (in the Attribute List parameter) either the attribute values for all attributes explicitly requested (in the Attribute Identifier List parameter), or the attribute values for all attributes defined for the managed object(s) selected (if the Attribute Identifier List is omitted). 18.6.3.2.2 Partially Successful Response For a partially successful M-GET operation, where only some attribute values were retrieved, the performer shall return (in the Errors parameter, specifically encoded as GetListError) all attribute ids and their corresponding values that were successfully retrieved from the set of attributes selected as described above, together with all attribute ids, and the corresponding error codes, for each of the attributes for which errors were detected. All attributes requested by the invoker must be processed, with either a value or an error code returned for each. 18.6.3.2.3 Linked Replies For the final reply of a series of linked relies or the single reply where no objects were selected when filtering has been specified, the GetResult is omitted. Hence Managed Object Class, Managed Object Instance, Current Time, Attribute List and Errors are all omitted in these cases. 18.6.3.2.4 Parameter Agreements Table 18.2. M-GET Parameters Item Parameter Name Req/Ind Rsp/Conf Text Reference 1 Invoke Identifier M M 18.6.4 2 Linked Identifier - C 18.6.4 3 Base Object Class M - 18.6.2.6 4 Base Object Instance M - 18.6.2.1 5 Scope U - 18.6.2.2.1 6 Filter U - 18.6.2.2.2 7 Access control U - 18.6.2.4 8 Synchronization U - 18.6.2.2.3 9 Attribute Identifier List U - 18.6.2.6 10 Managed Object Class - C 18.6.2.6 11 Managed Object Instance - C 18.6.2.1 12 Current Time - U 18.6.2.3 13 Attribute list - C 18.6.2.6, 18.6.3.2.1, 18.6.3.2.3 14 Errors - C 18.6.3.2.2 18.6.3.3 M-Set The following agreements and clarifications, pertinent to section 8.3.2 of the base standard [CMIS] and section 6.5 of the base standard [CMIP] and regarding the M-SET service, are included within these network management IAs. 18.6.3.3.1 Successful Response For a successful M-SET confirmed operation, the performer shall return (in the Attribute List parameter) the attribute values for all attributes explicitly specified (in the Attribute List parameter) indicating their new values. 18.6.3.3.2 Partially Successful Response For a partially successful M-SET operation, where only some attribute values were modified, the performer shall return (in the Errors parameter, specifically encoded as SetListError) all attribute ids and their corresponding values that were successfully modified from the set of attributes ids and values supplied, and all attribute ids and the corresponding error codes for each of the attributes for which errors were detected. All attributes requested by the invoker must be processed, with either a value of an error code returned for each. 18.6.3.3.3 Linked Replies For the final reply of a series of linked relies or the single reply where no objects were selected when filtering has been specified, the SetResult is omitted. Hence Managed Object Class, Managed Object Instance, Current Time, Attribute List and Errors are all omitted in these cases. 18.6.3.3.4 DAD2 Response Where multi-valued attributes are involved in an M-SET operation, the values returned after any modification operation must be the full set of values of that attribute and not just the values that were modified (e.g., added or removed). 18.6.3.3.5 Parameter Agreements Table 18.3. M-SET Parameters Item Parameter Name Req/Ind Rsp/Conf Text Reference 1 Invoke Identifier M M 18.6.4 2 Linked Identifier - C 18.6.4 3 Mode M - 4 Base Object Class M - 18.6.2.6 5 Base Object Instance M - 18.6.2.1 6 Scope U - 18.6.2.2.1 7 Filter U - 18.6.2.2.2 8 Access Control U - 18.6.2.4 9 Synchronization U - 18.6.2.2.3 10 Managed Object Class - C 18.6.2.6 11 Managed Object Instance - C 18.6.2.1 12 Modification List M - 18.6.2.6, 18.6.3.3.1, 18.6.3.3.3, 18.6.3.3.4 13 Attribute List - U 18.6.2.6, 18.6.3.3.1, 18.6.3.3.3 14 Current Time - U 18.6.2.3 15 Errors - C 18.6.3.3.2 18.6.3.4 M-Action The following agreements and clarifications, pertinent to section 8.3.3 of the base standard [CMIS] and section 6.6 of the base standard [CMIP] and regarding the M-ACTION service, are included within these network management IAs. 18.6.3.4.1 When multiple objects are selected for an M-ACTION operation, there is no ordering implied between selected objects. If the ordering is important, the requesting system may use separate operations, for individual object instances, in the desired order. Table 18.4. M-ACTION Parameters Item Parameter Name Req/Ind Rsp/Conf Text Reference 1 Invoke Identifier M M 18.6.4 2 Linked Identifier - C 18.6.4 3 Mode M - 4 Base Object Class M - 18.6.2.6 5 Base Object Instance M - 18.6.2.1 6 Scope U - 18.6.2.2.1 7 Filter U - 18.6.2.2.2 8 Managed Object Class - C 18.6.2.6 9 Managed Object Instance - C 18.6.2.1 10 Access Control U - 18.6.2.4 11 Synchronization U - 18.6.2.2.3 12 Action Type M C(=) 18.6.2.6 13 Action Information U - 14 Current Time - U 18.6.2.3 15 Action Reply - C 16 Errors - C 18.6.3.3.2 18.6.3.5 M-Create The following agreements and clarifications, pertinent to section 8.3.4 of the base standard [CMIS] and section 6.7 of the base standard [CMIP] and regarding the M-CREATE service, are included within these network management IAs. 18.6.3.5.1 Managed Object Instance The Managed Object Instance request parameter may be present or absent depending on whether the invoker supplies the instance name or the performer assigns the instance name automatically. The definition of each Managed Object Class shall define whether the instance name may be supplied by the invoker, or must be assigned by the performer. This definition shall apply to every management-initiated creation of instances of that managed object class. 18.6.3.5.2 Attribute Values The values of each of the attributes of the newly created object are derived in the following order, where each bullet may overide a value provided in a previous bullet: o From the default value defined for the attribute in the managed object class definition, if any o From the corresponding value, if any, derived from the reference object, if provided o From the value provided in the Attribute List request parameter. If none of these methods provides a value for any one attribute, then the operation shall be considered to have failed, i.e., no new instance is created, and the error code `Missing Attribute Value' shall be returned. 18.6.3.5.3 Parameter Agreements Table 18.5. M-CREATE Parameters Item Parameter Name Req/Ind Rsp/Conf Text Reference 1 Invoke Identifier M M(=) 18.6.4 2 Managed Object Class M C 18.6.2.6 3 Managed Object Instance U C 18.6.2.1, 18.6.3.5.1 4 Superior Object Instance U - 5 Access Control U - 18.6.2.4 6 Reference Object Instance U - 18.6.2.6 7 Attribute List U C 18.6.2.6, 18.6.3.5.2 14 Current Time - U 18.6.2.3 16 Errors - C 18.6.3.5.2 18.6.3.6 M-Delete The following agreements and clarifications, pertinent to section 8.3.5 of the base standard [CMIS] and section 6.8 of the base standard [CMIP] and regarding the M-DELETE service, are included within these Phase 1 network management IAs. 18.6.3.6.1 Deletion of Objects Containing Objects The error `Processing Failure' must be returned if a managed object has existing contained objects and the behavior defined for that object prohibits its deletion unless all contained objects have been deleted. 18.6.3.6.2 Parameter Agreements Table 18.6. M-DELETE Parameters Item Parameter Name Req/Ind Rsp/Conf Text Reference 1 Invoke Identifier M M 18.6.4 2 Linked Identifier - C 18.6.4 4 Base Object Class M - 18.6.2.6 5 Base Object Instance M - 18.6.2.1 6 Scope U - 18.6.2.2.1 7 Filter U - 18.6.2.2.2 8 Access Control U - 18.6.2.4 9 Synchronization U - 18.6.2.2.3 10 Managed Object Class - C 18.6.2.6 11 Managed Object Instance - C 18.6.2.1 12 Current Time - U 18.6.2.3 13 Errors - C 18.6.3.6.1 18.6.4 Specific Agreements on CMIP These agreements are based on the standard defined in [CMIP]. The agreements in this section have been defined in terms of those capabilities necessary to support the functions and services defined in section 18.5 (Management Functions and Services) and in terms of the Association Policies defined in section 18.6.1. These network management IAs make no agreements beyond the specifications in [CMIP] except the following: 18.6.4.1 Invoke/Linked Identifier Size Invoke Identifiers and Linked Identifiers must be encoded in a four (4) octet integer. 18.6.4.2 Version Version 2 (only) is supported. 18.6.4.3 Linked Reply Values Responder must send a linked reply value that corresponds to the original invoke operation value. 18.6.4.4 Error Codes Responder must send error types that correspond to the operation definition for the original invoke. 18.6.5 Services Required by CMIP CMIP requires the services provided by ACSE and ROSE. The conformance requirements for these services, and the underlying communication required to support them, are specified in section 5.12.1.5. Editor's Note: Proposed text for the ULSIG section 5.12.1.5. No agreements beyond the standards are made except where noted. 5.12.1.5 Network Management ROSE Requirements: The ROSE requirements are as specified in ISO 9596 section 5.2: Underlying Services, and section 6.2 Remote Operations. Operations Classes o 1, 2, and 5 Association Classes o 3 ACSE Requirements: all Editor's Note: All means what is specified in the Stable OIW agreements for ACSE in section 5.5. Application Contexts: o as defined by ISO/DP 10040 ANNEX A Editor's Note: Pending a DIS Version of the Standard. This is beyond the standard. Abstract Syntaxes o {joint-iso-ccitt(2) association-control(2) abstract-syntax(1) apdus(0) version1(1)} Editor's Note: ISSUE - Will there be a version2(2) syntax when the addendum on authentication becomes a standard? Associated Transfer Syntax: o {joint-iso-ccitt(2) asn1(1) basic-encod- ing(1)} "Basic Encoding of a single ASN.1 Type" o {joint-iso-ccitt ms(9) cmip(1) version2(2) abstractSyntax(4)} Editor's Note: Pending approval of the CMIP Addendum, the version2(2) is beyond the current DIS standard. As per ISO/IEC 9596 section 7.5, this abstract syntax incudes "all data types resolved by the ANY DEFINED BY X productions, in which X is of type OBJECT IDENTIFIER." Associated Transfer Syntax: o {joint-iso-ccitt asn1(1) basic-encoding(1)} "Basic Encoding of a single ASN.1 Type" Mode-Selection o Normal Mode Presentation Requirements: Presentation Functional Units: o kernel Presentation Contexts o at least two presentation contexts must be supported Mode-Selection o Normal mode (non-X.410) shall be supported. Session Requirements Session Functional Units o kernel o full duplex Version Number: 2 Maximum Size of User Data Parameter field: Shall be 10,240 octets. Implementations may specify in their PICS a maximum size down to 1024 octets Editor's Note: This is beyond the current standard. ASN.1 Encoding Rules Some INTEGER types of the CMIP PCI may exceed the maximum size specified in the UNIVERSAL ASN.1 ENCODING RULES, section 5.10. See the range of values for INTEGER type Parameters in the Network Management chapter. Editor's Note: For example: a 32 bit unsigned integer, as specified for IEEE 802.x management statistics, can represent 2**32-1. This would require 5 octets for ASN.1 encoding. The current 4 octet restriction in the OIW ASN.1 agreements only allows integers up to 2**31-1. Specific agreements are needed in section 18.6 regarding the length of INTEGERs. 18.7 MANAGEMENT INFORMATION This section, which is based on ISO standards' documents [MIM] and [GDMO], deals with basic concepts and modelling techniques related to management information. It discusses (i) the information model (sec. 18.7.1), (ii) principles for naming managed objects and their attributes (sec. 18.7.2), and (iii) guidelines for defining management information (sec. 18.7.3). It is not within the scope of this section to define specific elements of management information - such definitions can be obtained via the Management Information Library (MIL) produced by the OSI MIB Working Group ( a subgroup of the NMSIG ). Editor's Note: Tutorial Material: Management information comprises all information in the network that is of interest to network management. A computer node in a network, a transport connection, an event log are all examples of network resources for which management information can be defined. Management information is collectively referred to as the MIB or Management Information Base. 18.7.1 The Information Model This subsection contains agreements related to the information model as specified in clause 5 of [MIM]. Editor's Note: Tutorial Material: Management information is modelled using object-oriented techniques. All "things" in the network that are to be managed, are represented in terms of managed objects. A managed object is an abstraction (or a logical view) of a "manageable" physical or logical network resource. "Manageable", in this context, means that the particular resource can be managed by using OSI Management Services and Protocols. Examples of managed objects include protocol layer entities, modems, connections, etc. Each managed object belongs to a particular object class. An object class represents a collection of managed objects with the same, or similar properties. Each object class has a pre-defined identifier assigned to it by a standards' registration authority. A particular managed object existing in a particular network can be regarded as an instance of the object class to which it belongs. Thus, an object instance represents an actual realisation of an object class. A managed object is identified by specifying its object class and object instance. Managed objects contain properties which are referred to as attributes. Managed objects participate in relationships with each other. The relationships that are of particular concern to the Management Information Model are a) the containment relationship, and b) the inheritance relationship. These relationships are used to construct management information hierarchies, as described below. Managed objects do participate in relationships other than the two mentioned above; e.g. the Service relationship, where a managed object uses the services provided by another managed object, as in the case of a Transport Layer object using the services provided by a Network Layer object. These relationships, however, are not particularly significant for the Information Model. They can be easily represented as either managed objects or attributes, contained within the managed objects participating in the relationship. MANAGEMENT INFORMATION HIERARCHIES The following Management Information Hierarchies are identified: THE CONTAINMENT HIERARCHY This hierarchy is constructed by applying the relationship "is contained in" to objects and attributes. Objects of one class may contain objects of the same or different class. Attributes are contained within objects at any level of the containment hierarchy. Attributes cannot contain objects or other attributes. All object classes must have at least one possible superior in the containment tree. The definition of a class may permit it to have more than one such superior. However, individual instances of such a class are nevertheless contained in only one instance of a possible containing class. A special object called "root" is the ultimate superior in the containment hierarchy. The containment hierarchy is important because it is used for naming object instances. It also defines an existence dependency among its components; i.e. an object or attribute can 'exist' only if the containing object also 'exists'. If an object contains other objects, it cannot be deleted until the contained objects have been deleted. The contained objects may be deleted automatically, if this is specified in the definition of the managed object class(es) of the contained objects. THE INHERITANCE OR OBJECT CLASS HIERARCHY This hierarchy is constructed by applying the relationship "inherits properties of" to object classes. An object class may inherit properties of another object class, with refinement obtained by adding additional properties. The inheriting class is called the subclass in this relationship, and the parent the superclass. For example, the class "Network Entity" may be a subclass of "Layer Entity" and a superclass of "X.25 Network Entity". Each class may have zero, one or more subclasses. Subclasses may in turn have furthur subclasses, to any degree. A special object called "top" is the ultimate superclass. The inheritance hierarchy is useful in that it leads to a manageable and extensible technique for the definition of object classes. The inheritance hierarchy has NO relevance to object and/or instance naming. THE REGISTRATION HIERARCHY This hierarchy is not based on any particular relationship, and is independent of both the inheritance and containment hierarchies. It contains Object Identifiers for object classes and attributes, as assigned by the standards' registration authority. The registration hierarchy is important because it is used for identifying object classes and attributes. It is used to ensure global uniqueness and to permit extensions without a centralized registration authority. 18.7.1.1 Basic Concepts The following concepts/features of the information model are supported, as specified in clause 5 of [MIM]. managed object managed object class managed object instance attribute group attribute set-valued attribute attribute value assertion management operation encapsulation behaviour notification 18.7.1.2 Management Operations Supported The following management operations are supported, as specified in clause 5.2 of [MIM]. Operations that apply to attributes : Get attribute value Replace attribute value Set-to-default value Add attribute value Remove attribute value Operations that apply to managed objects : Create Delete Action 18.7.1.3 Filter The concept of filter is supported as specified in clause 5.3 of [MIM]. Restrictions on its usage are specified in section 18.6.2.2.2 of these agreements. 18.7.1.4 Inheritance All the inheritance related concepts (refinement, subclass, superclass, inheritance hierarchy, etc) presented in clause 5.5 of [MIM] are supported. The following additional constraints need to be enforced for the Phase 1 IAs in order to remove potential ambiguities: Subclasses must inherit ALL the optional attributes of their respective superclasses. Once inherited, these attributes may remain as optional attributes of the subclass or may become mandatory attributes of the subclass. When an instance of a managed object class is created, it must support all the mandatory attributes defined for that class. The instance may support some or none of the optional attributes defined for its class. Once created, the managed object instance must support , throughout its lifetime, exactly the same set of attributes that were assigned to it at the time of creation, i.e. dynamic creation/deletion of attributes within an object instance is not allowed. During the lifetime of a managed object instance, each of its attributes must have a value that is valid for the attribute syntax of that attribute. The range of the attribute values for any attribute may not be redefined in the process of refinement. If it is anticipated that the range of attribute values may change, then the use of the ASN.1 enumerated type for the attribute syntax is discouraged. Multiple inheritance is not supported for the Phase 1 IAs, since no requirements for it have been voiced within the NMSIG. 18.7.1.5 Polymorphism Editor's Note: Polymorphism is a very useful concept insofar as it facilitates interoperability across different versions and vendor extensions of a managed object class. However, issues and problems related to it, especially those dealing with the naming of polymorphic classes, have not been thoroughly examined or resolved in the standards. Given this, does NMSIG feel the need to incorporate polymorphism into the Phase 1 IAs ? Polymorphism is not supported for the Phase 1 IAs, since no requirements for it have been voiced within the NMSIG. 18.7.2 Principles of Naming This subsection contains agreements about principles of naming as specified in clause 6 of [MIM]. 18.7.2.1 Containment Hierarchy All concepts about the containment hierarchy presented in clause 6.1 of [MIM] are supported. 18.7.2.2 Name Structure 18.7.2.2.1 Object Class Identification A managed object class is identified by an ASN.1 object identifier, as specified in clause 6.2.1 of [MIM]. 18.7.2.2.2 Object Instance Identification The distinguished name approach is supported for the identification of managed object instances. Editor's Note: Many issues/questions regarding the naming of managed object instances have arisen because the related standards' text (clause 6.2.2 of [MIM]) is somewhat unclear. The following issues related to naming managed object instances are identified : a) Referring to the first sentence of clause 6.2.2 of [MIM], which starts with "The definition of each managed object class ...", does "an" identification attribute imply "only one" or "at least one" ? Can different name bindings for the same managed object class specify different distinguishing attributes, or is there just one distinguishing attribute per managed object class ? b) Do name bindings get inherited ? c) Is the distinguishing attribute of a subclass the same or different from distinguishing attribute of its superclass? If the superclass and its subclass have the same distinguishing attribute, there could be ambiguities in situations where instances of both the superclass and its subclass exist in the containment tree. If the superclass and its subclass do not have the same distinguishing attribute, polymorphism cannot be supported. d) What is the point of reference from which managed object instances are defined - full distinguished name or partial distinguished name? 18.7.2.2.3 Selection Of Distinguishing Attributes The distinguishing attribute for a managed object class must be very carefully selected. It must be able to distinguish not only between instances of the object class for which it is defined, but also between instances of all other object classes that have the same superior object class. For example, consider the following figure which shows the structure of a containment tree : A / \ / \ B C / / C Here, A represents instances of Object Class A, B represents instances of Object Class B and C represents instances of Object Class C. As can be seen from the figure, instances of Object Class C may be contained in either instances of Object Class A, or in instances of Object Class B. When the RDN of Object Class C is defined, it is necessary to make sure that it is different from the RDN for Object Class B. If Object Class B and Object Class C were to support the same RDN, it would not be possible to unambiguously traverse down the containment tree from A. The above example shows a simple containment tree. In the real world, however, containment trees could be much more complex, and the selection of distinguishing attributes could involve extensive checking and verification over multiple object classes. Editor's Note: Consider the following proposal : "The process of selecting the correct distinguishing attribute can be made simpler if every object class supports an additional distinguishing attribute called "My Object Class", whose value identifies the object class it is contained in. If this is done, the process of selecting and verifying the RDN of an object class would not require the consideration of object classes other than the one defining the RDN." The above proposal will be worked on by the NMSIG and submitted to the standards. 18.7.2.2.4 Attribute Identification Each individual attribute of a managed object is identified by an ASN.1 object identifier, as specified in clause 6.2.4 of [SMI Part 1]. 18.7.3 Guidelines for the Definition of Management Information This subsection contains agreements about guidelines for the definition of management information, as specified in [GDMO]. These guidelines form a normative part of the standard; hence they must be strictly followed while defining management information. 18.7.3.1 Syntactical Definitions of Management Information 18.7.3.1.1 Managed Object Class Template For Phase 1 IAs, the template supported by NMSIG for defining managed object classes is the same as the Managed Object Class template defined in clause 10.3.2 of [GDMO], with the agreement that the optional clause POLYMORPHIC SET is not to be used. The POLYMORPHIC SET clause is not supported, as per the agreements on polymorphism specified in 18.7.1.5. Supporting productions for "propertylist" and "modifier" are adopted as specified in clause 10.3.2 of [GDMO]. Supporting definitions of the DERIVED FROM, POLYMORPHIC SET, ATTRIBUTES, GROUP ATTRIBUTES, CREATE, DELETE, ACTIONS, NOTIFICATIONS, and PACKAGE clauses of the managed object class template are adopted as defined in clause 10.3.3 of [GDMO] with the following exceptions: The shall not be used because the managed object class template allows for multiple specific errors to be defined within an object class, and it is not possible to unambiguously communicate over CMIP multiple specific errors pertaining to a single managed object class. For the GROUP ATTRIBUTES clause, new attributes shall not be added to the group attribute from within the managed object class template because this can lead to ambiguities. Hence, the [] portion of the supporting definition for the GROUP ATTRIBUTE clause shall not be used. For the PACKAGE clause the shall only reflect the capabilities of the underlying resource that the managed object class is representing. 18.7.3.1.2 Conditional Package Template The CONDITIONAL PACKAGE template specified in clause 10.4 of [GDMO] is supported. The agreements listed in 18.7.3.1.1 for the supporting definitions of the MANAGED OBJECT CLASS template are to be applied to the CONDITIONAL PACKAGE template, too. 18.7.3.1.3 Specific Error Template The SPECIFIC ERROR template is not supported for the reasons given in 18.7.3.1.1 18.7.3.1.4 Name Binding Template The NAME BINDING template is supported as described in clause 10.6 of [GDMO] except that the CONSTRAINTS clause shall not be used because its usage has not been clearly specified in the standard. 18.7.3.1.5 Attribute Template The ATTRIBUTE template described in clause 10.7 of [GDMO] is supported. The DERIVED FROM and PERMITTED VALUES clauses of the ATTRIBUTE template are not supported, in general, because their usage could lead to major ambiguities. However, usage of attributes defined in [DMI] that use the DERIVED FROM clause and are registered is allowed. The PERMITTED VALUES clause can only be used if the ATTRIBUTE SYNTAX has been previously defined; e.g., in [DMI]. The REGISTERED AS clause, which has been defined as optional, is made mandatory. The BEHAVIOUR clause is made mandatory. 18.7.3.1.6 Group Attribute Template The GROUP ATTRIBUTE template is supported as described in clause 10.8 of [GDMO]. 18.7.3.1.7 Action Template The ACTION template is supported as described in clause 10.10 of [GDMO]. 18.7.3.1.8 Notification Template The NOTIFICATION template is supported as described in clause 10.11 of [GDMO]. 18.7.3.2 Guidelines For Defining Behaviour The following details should be provided in the definition of each managed object class : - a textual description of the network resource it represents, including its functional role. - a description of the relationships that instances of this managed object class participate in with instances of the same or other managed object classes. - a description of the operations that are supported by it, with precise definition of the effects, side effects if any, constraints, response notifications, failure modes, etc. - specification of how instances of this managed object class are created and deleted, particularly whether they can be created/deleted via the management CREATE/DELETE operations. - a description of notifications that can be generated, the conditions that generate them (e.g., crossing of a threshold), their contents and side-effects, if any. In particular, identify all the attributes that are subject to the AttributeChange and StateChange notifications, if these notifications are supported. - other constraints, including those involving other managed object classes. 18.7.3.3 Other Guidelines The Systems Management functions have defined various attributes and events, as indicated in section 18.5 of these agreements. Object Definers are encouraged to make use of these attributes and events wherever applicable. 18.8 APPENDIX A -- Management Information Library (MIL) MANAGEMENT INFORMATION LIBRARY (MIL) OSI MIB Working Group Version 4.0 March 29, 1990 TABLE OF CONTENTS 1. INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2. RULES AND PROCEDURES . . . . . . . . . . . . . . . . . . . . . . 8 3. GENERAL GUIDELINES . . . . . . . . . . . . . . . . . . . . . . . 9 4. OBJECT CLASSES . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.1. Discriminator . . . . . . . . . . . . . . . . . . . . . . . 10 4.2. Event Forwarding Discriminator . . . . . . . . . . . . . . 10 4.3. NMSIG Agent . . . . . . . . . . . . . . . . . . . . . . . . 10 4.3.1. NMSIG Agent Definition . . . . . . . . . . . . . . 10 4.3.2. NMSIG Agent Behaviour . . . . . . . . . . . . . . . 10 4.4. NMSIG Computer System . . . . . . . . . . . . . . . . . . . 10 4.4.1. NMSIG Computer System Definition . . . . . . . . . 11 4.4.2. NMSIG Computer System Behaviour . . . . . . . . . . 12 4.5. NMSIG Connection Oriented Tranport Protocol Layer Entity . 12 4.5.1. NMSIG CO Transport Protocol Layer Entity Definition 12 4.5.2. NMSIG CO Transport Protocol Layer Entity Behaviour 13 4.6. NMSIG Connectionless Network Protocol Layer Entity . . . . 14 4.6.1. NMSIG Connectionless Network Protocol Layer Entity Definition . . . . . . . . . . . . . . . . . . . . . . 14 4.6.2. NMSIG Connectionless Network Protocol Layer Entity Behaviour . . . . . . . . . . . . . . . . . . . . . . . 15 4.6.3. NMSIG CL Network Protocol Layer Entity Redirection Package . . . . . . . . . . . . . . . . . . . . . . . . 16 4.7. NMSIG Equipment . . . . . . . . . . . . . . . . . . . . . . 17 4.7.1. NMSIG Equipment Definition . . . . . . . . . . . . 17 4.7.2. NMSIG Equipment Behaviour . . . . . . . . . . . . . 17 4.8. NMSIG IEEE 802.3 . . . . . . . . . . . . . . . . . . . . . 18 4.8.1. NMSIG IEEE 802.3 Definition . . . . . . . . . . . . 18 4.8.2. NMSIG IEEE 802.3 Behaviour . . . . . . . . . . . . 19 4.9. NMSIG IEEE 802.3 RCV . . . . . . . . . . . . . . . . . . . 19 4.9.1. NMSIG IEEE RCV Definition . . . . . . . . . . . . . 20 4.9.2. NMSIG IEEE 802.3 RCV Behaviour . . . . . . . . . . 20 4.10. NMSIG IEEE 802.3 XMT . . . . . . . . . . . . . . . . . . . 21 4.10.1. NMSIG IEEE 802.3 XMT Definition . . . . . . . . . 21 4.10.2. NMSIG IEEE 802.3 XMT Behaviour . . . . . . . . . . 22 4.11. NMSIG LAN MAC Bridge . . . . . . . . . . . . . . . . . . . 23 4.11.1. NMSIG LAN MAC Bridge Definition . . . . . . . . . 23 4.11.2. NMSIG LAN MAC Bridge Behaviour . . . . . . . . . . 23 4.12. NMSIG MAC Port . . . . . . . . . . . . . . . . . . . . . . 24 4.12.1. NMSIG MAC Port Definition . . . . . . . . . . . . 24 4.12.2. NMSIG MAC Port Behaviour . . . . . . . . . . . . . 25 4.13. NMSIG Network . . . . . . . . . . . . . . . . . . . . . . 25 4.13.1. NMSIG Network Definition . . . . . . . . . . . . . 25 4.13.2. NMSIG Network Behaviour . . . . . . . . . . . . . 26 4.14. NMSIG Processing Entity . . . . . . . . . . . . . . . . . 26 4.14.1. NMSIG Processing Entity Definition . . . . . . . . 26 4.14.2. NMSIG Processing Entity Behaviour . . . . . . . . 26 4.15. NMSIG Root . . . . . . . . . . . . . . . . . . . . . . 27 4.15.1. NMSIG Root Definition . . . . . . . . . . . . . . 27 4.15.2. NMSIG Root Behaviour . . . . . . . . . . . . . . . 27 4.16. NMSIG Transport Connection . . . . . . . . . . . . . . . . 28 4.16.1. NMSIG Transport Connection Definition . . . . . . 28 4.16.2. NMSIG Transport Connection Behaviour . . . . . . . 28 4.16.3. NMSIG Transport Connection Retransmission Package 29 4.17. NMSIG Transport Connection Profile . . . . . . . . . . . . 30 4.17.1. NMSIG Transport Connection Profile Definition . . 30 4.17.2. NMSIG Transport Connection Profile Behaviour . . . 30 4.18. NMSIG Transport Connection Retransmission Profile . . . . 31 4.18.1. NMSIG Transport Connection Retransmission Profile Definition . . . . . . . . . . . . . . . . . . . . . . 31 4.18.2. NMSIG Transport Connection Retransmission Profile Behaviour . . . . . . . . . . . . . . . . . . . . . . . 31 4.19. Top . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 5. NAME BINDINGS . . . . . . . . . . . . . . . . . . . . . . . . . . 32 5.1. Event Forwarding Discriminator Name Bindings . . . . . . . 32 5.2. NMSIG Agent Name Bindings . . . . . . . . . . . . . . . . . 32 5.3. NMSIG Computer System Name Bindings . . . . . . . . . . . . 32 5.4. NMSIG CO Transport Protocol Layer Entity Name Bindings . . 33 5.5. NMSIG CL Network Protocol Layer Entity Name Bindings . . . 33 5.6. NMSIG Equipment Name Bindings . . . . . . . . . . . . . . . 33 5.7. NMSIG IEEE 802.3 Name Bindings . . . . . . . . . . . . . . 34 5.8. NMSIG IEEE 802.3 RCV Name Bindings . . . . . . . . . . . . 34 5.9. NMSIG IEEE 802.3 XMT Name Bindings . . . . . . . . . . . . 34 5.10. NMSIG LAN MAC Bridge Name Bindings . . . . . . . . . . . . 34 5.11. NMSIG MAC Port Name Bindings . . . . . . . . . . . . . . . 35 5.12. NMSIG Network Name Bindings . . . . . . . . . . . . . . . 35 5.13. NMSIG Processing Entity Name Bindings . . . . . . . . . . 35 5.14. NMSIG Transport Connection Name Bindings . . . . . . . . . 35 5.15. NMSIG Transport Connection Profile Name Bindings . . . . . 35 5.16. NMSIG Transport Connection Retransmission Profile Name Bindings . . . . . . . . . . . . . . . . . . . . . . . . . . 36 6. ATTRIBUTES . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 6.1. Administrative State . . . . . . . . . . . . . . . . . . . 37 6.2. Begin Time . . . . . . . . . . . . . . . . . . . . . . . . 37 6.3. Destination Address . . . . . . . . . . . . . . . . . . . . 37 6.4. Discriminator Construct . . . . . . . . . . . . . . . . . . 37 6.5. Discriminator Id . . . . . . . . . . . . . . . . . . . . . 37 6.6. End Time . . . . . . . . . . . . . . . . . . . . . . . . . 37 6.7. Health State . . . . . . . . . . . . . . . . . . . . . . . 37 6.8. Incoming Connection Reject Error Counter . . . . . . . . . 37 6.9. Incoming Connection Requests Counter . . . . . . . . . . . 37 6.10. Incoming Disconnect Error Counter . . . . . . . . . . . . 38 6.11. Incoming Temporal Error Counter . . . . . . . . . . . . . 38 6.12. NMSIG Alignment Error Threshold . . . . . . . . . . . . . 38 6.13. NMSIG Agent Id . . . . . . . . . . . . . . . . . . . . . . 38 6.14. NMSIG Broadcast Forwarding State . . . . . . . . . . . . . 38 6.15. NMSIG Broadcast PDUs Rcv Counter . . . . . . . . . . . . 39 6.16. NMSIG Broadcast PDUs Xmt Counter . . . . . . . . . . . . 39 6.17. NMSIG Carrier Sense Errors Counter . . . . . . . . . . . . 39 6.18. NMSIG Carrier Sense Errors Threshold . . . . . . . . . . . 40 6.19. NMSIG Checksum TPDUs Discarded Counter . . . . . . . . . 40 6.20. NMSIG Collision PDUs Counter . . . . . . . . . . . . . . . 41 6.21. NMSIG Collision PDUs Threshold . . . . . . . . . . . . . . 41 6.22. NMSIG CO Transport Protocol Layer Entity Id . . . . . . . 41 6.23. NMSIG Connectionless Network Protocol Layer Entity Id . . 42 6.24. NMSIG Contact Names . . . . . . . . . . . . . . . . . . . 42 6.25. NMSIG CPU Type . . . . . . . . . . . . . . . . . . . . . . 42 6.26. NMSIG Enable Promiscuous State . . . . . . . . . . . . . . 43 6.27. NMSIG Entity Up Time . . . . . . . . . . . . . . . . . . . 43 6.28. NMSIG Equipment Id . . . . . . . . . . . . . . . . . . . . 43 6.29. NMSIG Equipment Purpose . . . . . . . . . . . . . . . . . 44 6.30. NMSIG Excessive Deferral Threshold . . . . . . . . . . . . 44 6.31. NMSIG FCS Error Threshold . . . . . . . . . . . . . . . . 44 6.32. NMSIG IEEE 802.3 Id . . . . . . . . . . . . . . . . . . . 45 6.33. NMSIG IEEE 802.3 RCV Id . . . . . . . . . . . . . . . . . 45 6.34. NMSIG IEEE 802.3 State . . . . . . . . . . . . . . . . . . 45 6.35. NMSIG IEEE 802.3 XMT Id . . . . . . . . . . . . . . . . . 46 6.36. NMSIG In-Range Threshold . . . . . . . . . . . . . . . . . 46 6.37. NMSIG Inactivity Timeout . . . . . . . . . . . . . . . . . 47 6.38. NMSIG Incoming Normal Disconnect Counter . . . . . . . . . 47 6.39. NMSIG Internal MAC Rcv Error Threshold . . . . . . . . . . 47 6.40. NMSIG Internal MAC Rcv Error Counter . . . . . . . . . . . 48 6.41. NMSIG Internal MAC Xmt Error Threshold . . . . . . . . . . 48 6.42. NMSIG Late Collision Counter . . . . . . . . . . . . . . . 49 6.43. NMSIG Late Collisions Threshold . . . . . . . . . . . . . 49 6.44. NMSIG Local Network Address . . . . . . . . . . . . . . . 49 6.45. NMSIG Local Network Addresses . . . . . . . . . . . . . . 50 6.46. NMSIG Local Transport Addresses . . . . . . . . . . . . . 50 6.47. NMSIG Local Transport Connection Endpoint . . . . . . . . 50 6.48. NMSIG Location Name . . . . . . . . . . . . . . . . . . . 51 6.49. NMSIG MAC Address . . . . . . . . . . . . . . . . . . . . 51 6.50. NMSIG MAC Port Id . . . . . . . . . . . . . . . . . . . . 51 6.51. NMSIG MAC Port In Non-Unicast Packets Counter . . . . . . 52 6.52. NMSIG MAC Port In Octet Rate . . . . . . . . . . . . . . . 52 6.53. NMSIG MAC Port In Octet Rate Threshold . . . . . . . . . . 53 6.54. NMSIG MAC Port In Unicast Packets Counter . . . . . . . . 53 6.55. NMSIG MAC Port Out Delay Discarded Packets Counter . . . . 53 6.56. NMSIG MAC Port Out Non-Unicast Packets . . . . . . . . . . 54 6.57. NMSIG MAC Port Out Queue Length . . . . . . . . . . . . . 54 6.58. NMSIG MAC Port Out Unicast Packets Counter . . . . . . . . 54 6.59. NMSIG Max Connections . . . . . . . . . . . . . . . . . . 55 6.60. NMSIG Max Retransmissions . . . . . . . . . . . . . . . . 55 6.61. NMSIG Max TPDU Size . . . . . . . . . . . . . . . . . . . 55 6.62. NMSIG Memory Size . . . . . . . . . . . . . . . . . . . . 56 6.63. NMSIG Multicast Address List . . . . . . . . . . . . . . . 56 6.64. NMSIG Multicast Forwarding State . . . . . . . . . . . . . 56 6.65. NMSIG Multicast PDUs Rcv Counter . . . . . . . . . . . . . 57 6.66. NMSIG Multicast PDUs Xmt Counter . . . . . . . . . . . . . 57 6.67. NMSIG Multicast Receive State . . . . . . . . . . . . . . 57 6.68. NMSIG Multiple Collision PDU Counter . . . . . . . . . . . 58 6.69. NMSIG Network Entity Type . . . . . . . . . . . . . . . . 58 6.70. NMSIG Network Id . . . . . . . . . . . . . . . . . . . . . 58 6.71. NMSIG Network Purpose . . . . . . . . . . . . . . . . . . 59 6.72. NMSIG NPDU Time To Live . . . . . . . . . . . . . . . . . 59 6.73. NMSIG Octets Retransmitted Error Counter . . . . . . . . . 59 6.74. NMSIG OS Info . . . . . . . . . . . . . . . . . . . . . . 60 6.75. NMSIG Open Connections . . . . . . . . . . . . . . . . . . 60 6.76. NMSIG Out-Range Threshold . . . . . . . . . . . . . . . . 61 6.77. NMSIG Outgoing Normal Disconnect Counter . . . . . . . . . 61 6.78. NMSIG Packet Loss Rate . . . . . . . . . . . . . . . . . . . . 61 6.79. NMSIG Packet Loss Rate Threshold . . . . . . . . . . . . . 62 6.80. NMSIG PDU Too Long Threshold . . . . . . . . . . . . . . . 62 6.81. NMSIG PDUs Aborted Excessive Collisions Counter . . . . . 63 6.82. NMSIG PDUs Aborted Excessive Collisions Threshold . . . . 63 6.83. NMSIG PDUs Alignment Error Counter . . . . . . . . . . . . 63 6.84. NMSIG PDUs Excessive Deferral Counter . . . . . . . . . . 64 6.85. NMSIG PDUs Discarded Counter . . . . . . . . . . . . . . . 64 6.86. NMSIG PDUs FCS Error Counter . . . . . . . . . . . . . . . 64 6.87. NMSIG PDUs Forwarded Counter . . . . . . . . . . . . . . . 65 6.88. NMSIG PDUs In-Range Length Error Counter . . . . . . . . . 65 6.89. NMSIG PDUs Lost Internal MAC Xmt Error Counter . . . . . . 65 6.90. NMSIG PDUs Out-Range Error Counter . . . . . . . . . . . . 66 6.91. NMSIG PDUs Reassemble Fail Counter . . . . . . . . . . . . 66 6.92. NMSIG PDUs Reassembled OK Counter . . . . . . . . . . . . 67 6.93. NMSIG PDUs Too Long Error Counter . . . . . . . . . . . . 67 6.94. NMSIG Peripheral Names . . . . . . . . . . . . . . . . . . 67 6.95. NMSIG Product Info . . . . . . . . . . . . . . . . . . . . 68 6.96. NMSIG Promiscuous Receive State . . . . . . . . . . . . . 68 6.97. NMSIG Remote Network Address . . . . . . . . . . . . . . . 68 6.98. NMSIG Remote Transport Connection Endpoint . . . . . . . . 69 6.99. NMSIG Retransmission Timer Initial Value . . . . . . . . . 69 6.100. NMSIG Single Collision PDUs Counter . . . . . . . . . . . 69 6.101. NMSIG Source Address Last Alignment Error PDU . . . . . . 70 6.102. NMSIG Source Address Last FCS Error PDU . . . . . . . . . 70 6.103. NMSIG Source Address Last In-Range Length Error PDU . . . 70 6.104. NMSIG Source Address Last Out-Range Length Error PDU . . 71 6.105. NMSIG Source Address Last Too Long Error PDU . . . . . . 71 6.106. NMSIG System Id . . . . . . . . . . . . . . . . . . . . . 71 6.107. NMSIG System Time . . . . . . . . . . . . . . . . . . . . 72 6.108. NMSIG Transport Connection Id . . . . . . . . . . . . . . 72 6.109. NMSIG Transport Connection Profile Id . . . . . . . . . . 72 6.110. NMSIG Transport Connection Reference . . . . . . . . . . 73 6.111. NMSIG Transport Entity Type . . . . . . . . . . . . . . . 73 6.112. NMSIG User Friendly Label . . . . . . . . . . . . . . . . 73 6.113. NMSIG Vendor Name . . . . . . . . . . . . . . . . . . . . 74 6.114. NMSIG Xmt State . . . . . . . . . . . . . . . . . . . . . 74 6.115. Object Class . . . . . . . . . . . . . . . . . . . . . . 75 6.116. Octets Received Counter . . . . . . . . . . . . . . . . . 75 6.117. Octets Sent Counter . . . . . . . . . . . . . . . . . . . 75 6.118. Operational State . . . . . . . . . . . . . . . . . . . . 75 6.119. Outgoing Connection Reject Error Counter . . . . . . . . 75 6.120. Outgoing Connections Request Counter . . . . . . . . . . 75 6.121. Outgoing Disconnect Error Counter . . . . . . . . . . . . 75 6.122. Outgoing Temporal Error Counter . . . . . . . . . . . . . 75 6.123. PDUs Received Counter . . . . . . . . . . . . . . . . . . 75 6.124. PDUs Sent Counter . . . . . . . . . . . . . . . . . . . . 75 6.125. PDUs Retransmitted Error Counter . . . . . . . . . . . . 76 7. ACTIONS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 7.1. NMSIG Execute Self Test . . . . . . . . . . . . . . . . . . 77 8. NOTIFICATIONS . . . . . . . . . . . . . . . . . . . . . . . . . . 78 8.1. Attribute Change Unconfirmed . . . . . . . . . . . . . . . 78 8.2. Communication Alarm Unconfirmed . . . . . . . . . . . . . . 78 8.3. Equipment Alarm Unconfirmed . . . . . . . . . . . . . . . . 78 8.4. Environmental Alarm Unconfirmed . . . . . . . . . . . . . . 78 8.5. NMSIG Counter Wrap Unconfirmed . . . . . . . . . . . . . . 78 8.6. Object Creation Unconfirmed . . . . . . . . . . . . . . . . 78 8.7. Object Deletion Unconfirmed . . . . . . . . . . . . . . . . 78 8.8. Processing Error Alarm Unconfirmed . . . . . . . . . . . . 79 8.9. Relationship Change Unconfirmed . . . . . . . . . . . . . . 79 8.10. State Change Unconfirmed . . . . . . . . . . . . . . . . . 79 9. REFERENCES . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 1. INTRODUCTION This document is produced by the OSI MIB Working Group (a subgroup of the NMSIG). It provides definitions of management information - managed object classes, name bindings, attributes, actions and notifications. Provision of these definitions is made by: a) references to standards' documents that contain these definitions, or b) inclusion of the actual definitions in this document; in which case they will be registered in the NMSIG arc of the ISO ASN.1 Object Identifier Tree. Management information definitions provided by the OSI MIB Working Group have been introduced to accelerate the process of defining management information. They are intended to be implementable but also serve as a basis from which other implementations may define refinements or alternatives. These definitions do not override those provided by standards' groups or other OIW SIGs. Editor's Note: The intention is to progress these definitions to an International Management Information Library. 2. RULES AND PROCEDURES The following rules and procedures apply to managed object class definitions that are to be included in the MIL : (i) All managed object class definitions provided by the MIL must comply with the NMSIG (ISO) object templates. (ii) A managed object class definition provided by the MIL must represent an abstraction of an identifiable logical or physical resource that can be managed via OSI management. (iii) All managed object classes in the MIL will have registered ASN.1 object identifiers assigned either by a standards' body if it is defining the managed object class, or, if the managed object class definition is being progressed within the NMSIG, by the NMSIG in its branch of the ISO Registration Tree. (iv) A managed object class will be selected as a candidate for inclusion into the MIL if there are at least two NMSIG members from different companies who express a requirement (strong interest) for the managed object class. If this is not a standards' defined managed object class, then there must be at least one NMSIG member who is committed to developing the definition of the managed object class. (v) A managed object class selected for the MIL will be given a priority based on the number of members who express interest in it. (vi) All managed object class definitions that are proposed for inclusion into the MIL will undergo a review process within the NMSIG. NMSIG member defined managed object classs will additionally undergo a ballotting process. If problems are found with a standards' defined managed object class, the appropriate standards' body will be approached. If problems are found with a member defined managed object class, it will be returned with comments. (vii) Based on its priority, there will be a call for contributions on the definition of a managed object class at an NMSIG meeting. Contributions could be in the form of: a) identification of a standards' body that is currently working on the definition, or b) an NMSIG member definition of the managed object class. (viii) There will be no obsolescence of any managed object class specified in the MIL. 3. GENERAL GUIDELINES It is recommended that the following guidelines be used in general for all managed object definitions, unless there is a specific exception condition: a) For the ObjectCreation Notification, send all the attributes of the created managed object instance in the CreateInfo field. 4. OBJECT CLASSES 4.1. Discriminator This managed object class is used to define the criteria for controlling management services. Refer to [ISO Doc x] for the definition of this managed object class. 4.2. Event Forwarding Discriminator This managed object class is used to define the criteria that must be satisfied by potential event reports before the event reports are forwarded to a particular destination. Refer to [ISO Doc x] for the definition of this managed object class. 4.3. NMSIG Agent 4.3.1. NMSIG Agent Definition nmsig-agent MANAGED OBJECT CLASS DERIVED FROM {top} CHARACTERISED BY BEHAVIOUR DEFINITIONS agent-behaviour ATTRIBUTES nmsig-agentId GET, REGISTERED AS {obj-class} 4.3.2. NMSIG Agent Behaviour agent-behaviour BEHAVIOUR DEFINED AS This managed object class represents an NMSIG agent system, which is an open system that supports the NMSIG agreements to make one or more managed objects visible to other open systems that support the NMSIG agreements. An NMSIG agent system may not support more than one instances of the NMSIG Agent managed object class. If supported, this instance is assumed to be pre-existent when the NMSIG agent system comes up; i.e., management CREATE or DELETE is not supported. At this time, the NMSIG Agent managed object class only serves to name management support managed objects (e.g., EventForwardingDiscriminator). 4.4. NMSIG Computer System Editor's Note: A model has been proposed for defining managed object classes related to computers, as follows: The philosophy behind the proposed model is to define a composite or aggregrate managed object class called "computerSystem" that provides a high level view of a computer system, including its physical and logical, as well as its hardware and software components. Detailed views of these components are then modelled as object classes contained within the computerSystem object class, as shown in the CONTAINMENT TREE below. (NOTE : This is NOT an inheritance tree.) computerSystem | | -----------------------------------------------------....... | | | | | | | tapeDrive | printer | | | applicationX ........ discDrive processing | os Entity | | coTransportProtocolLayerEntity | transportConnection A great benefit provided by this model is flexibility. As and when more computer components need to be specified, they can be defined as individual object classes and "plugged" into the above structure under computerSystem, without upsetting the other object classes. The 'system' managed object class defined in [DMI] was not used because it's definition was considered to be inappropriate. 4.4.1. NMSIG Computer System Definition nmsig-computerSystem MANAGED OBJECT CLASS DERIVED FROM {top} CHARACTERISED BY BEHAVIOUR DEFINITIONS computerSystem-behaviour ATTRIBUTES nmsig-systemId GET, AdministrativeState GET-REPLACE HealthState GET, OperationalState GET, nmsig-systemTime GET, nmsig-peripheralNames GET, nmsig-userFriendlyLabel GET-REPLACE NOTIFICATIONS ObjectCreationUnConfirmed, ObjectDeletionUnConfirmed, AttributeChangeUnConfirmed, StateChangeUnConfirmed, ProcessingErrorAlarmUnConfirmed, EnvironmentalAlarmUnConfirmed, EquipmentAlarmUnConfirmed REGISTERED AS {obj-class} 4.4.2. NMSIG Computer System Behaviour computerSystem-behaviour BEHAVIOUR DEFINED AS The nmsig-computerSystem managed object class is a composite or aggregate object class that provides a high level view of a general purpose business computer system, including its physical, logical, hardware and software components. The Computer System managed object class supports all the values of the administrative state. It supports only the 'enabled' and 'disabled' values of the operational state. The 'enabled' value of the operational state indicates that the underlying computer system resources are together capable of providing minimal computing services. These enabled resources may or may not be modelled as managed objects, and may or may not include the entire set of resources which together are viewed as the computer system. The 'disabled' value of the operational state indicates that the underlying computer system resources are incapable of providing minimal services at the current time. The peripheralNames attribute specifies the names of auxiliary devices that are used by the underlying computer system resource. The CreateInfo field of the ObjectCreation notification shall contain all the attributes of the created computer sytem instance. The DeleteInfo field of the ObjectDeletion notification shall be NULL. Attributes that are subject to the AttributeChange notification are: nmsig-peripheralNames, nmsig-userFriendlyLabel, HealthState. Attributes that are subject to the StateChange notification are: AdministrativeState and OperationalState. 4.5. NMSIG Connection Oriented Tranport Protocol Layer Entity 4.5.1. NMSIG CO Transport Protocol Layer Entity Definition nmsig-coTransportProtocolLayerEntity MANAGED OBJECT CLASS DERIVED FROM {top} CHARACTERIZED BY BEHAVIOUR DEFINITIONS coTransportProtocolLayerEntity-behaviour ATTRIBUTES nmsig-coTransportProtocolLayerEntityId GET, AdministrativeState GET-REPLACE, OperationalState GET, HealthState GET, nmsig-localTransportAddresses GET, nmsig-maxConnections GET, nmsig-openConnections GET, OutgoingConnectionsRequestCounter GET, IncomingConnectionsRequestCounter GET, OutgoingConnectionRejectErrorCounter GET, IncomingConnectionRejectErrorCounter GET, OutgoingDisconnectErrorCounter GET, IncomingDisconnectErrorCounter GET, nmsig-incomingNormalDisconnectCounter GET, nmsig-outgoingNormalDisconnectCounter GET, OctetsSentCounter GET, OctetsReceivedCounter GET, IncomingTemporalErrorCounter GET, OutgoingTemporalErrorCounter GET, nmsig-checksumTPDUsDiscardedCounter GET, nmsig-transportEntityType GET, nmsig-productInfo GET, nmsig-entityUpTime GET NOTIFICATIONS ObjectCreationUnConfirmed, ObjectDeletionUnConfirmed, AttributeChangeUnConfirmed, StateChangeUnConfirmed, ProcessingErrorAlarmUnConfirmed, nmsig-counterWrapUnConfirmed REGISTERED AS {obj-class} 4.5.2. NMSIG CO Transport Protocol Layer Entity Behaviour coTransportProtocolLayerEntity-behaviour BEHAVIOUR DEFINED AS The managed object class nmsig-coTransportProtocolLayerEntity represents an instantiation of any connection-oriented transport layer protocol e.g. the ISO Transport Protocol layer or the Internet Transmission Control Protocol (TCP). The transport protocol layer is layer four of the OSI Reference model. It provides for the transparent transference of data between two peer entities. It relieves its users from any concerns about the detailed way in which supporting communication media are utilized to achieve this transfer. The connection oriented transport protocol layer entity makes use of a transport connection for the purpose of transferring data. This managed object class represents a "generic" view of a connection oriented transport protocol layer entity. It does not concern itself with the details of specific transport protocols like ISO TP or TCP. Transport entities that are tied to a specific protocol can be defined as its subclasses; in fact their definitions are being progressed within various standards' bodies. The purpose of defining this managed object class, however, is to provide a common base that will facilitate the high level management of similar but slightly differing resources. The connection oriented transport protocol layer entity supports all values of the administrative and operational states. The 'enabled' value of the operational state indicates that the underlying transport protocol layer entity resource is capable of supporting transport connections but currently has no open transport connections. The 'disabled' value of the operational state indicates that the underlying transport protocol layer entity resource is not capable of supporting any transport connections. The 'active' value of the operational state indicates that the underlying transport protocol layer entity resource is currently supporting at least one transport connections and is capable of supporting additional transport connections. The 'busy' value of the operational state indicates that the underlying transport protocol layer entity resource is supporting the maximum number of transport connections that it is capable of supporting. The CreateInfo field of the ObjectCreation notification shall contain all the attributes of the created connection-oriented transport protocol layer entity instance. The DeleteInfo field of the ObjectDeletion notification shall contain all the attributes of the deleted connection-oriented transport protocol layer entity instance. Attributes that are subject to the AttributeChange notification are: nmsig-localTransportAddresses, nmsig-maxConnections, nmsig- productInfo, HealthState. Attributes that are subject to the StateChange notification are: AdministrativeState and OperationalState. The counterWrap notification is emitted when any of the counter attributes wrap. 4.6. NMSIG Connectionless Network Protocol Layer Entity 4.6.1. NMSIG Connectionless Network Protocol Layer Entity Definition nmsig-clNetworkProtocolLayerEntity MANAGED OBJECT CLASS DERIVED FROM {top} CHARACTERIZED BY BEHAVIOUR DEFINITIONS clNetworkProtocolLayerEntity-behaviour ATTRIBUTES nmsig-clNetworkProtocolLayerEntityId GET, AdministrativeState GET-REPLACE, OperationalState GET, HealthState GET, nmsig-localNetworkAddresses GET, nmsig-nPDUTimeToLive GET-REPLACE, PDUsSentCounter GET, PDUsReceivedCounter GET, nmsig-PDUsForwardedCounter GET, nmsig-PDUsReasmbldOKCounter GET, nmsig-PDUsReasmblFailCounter GET, nmsig-PDUsDiscardedCounter GET, nmsig-networkEntityType GET, nmsig-productInfo GET, nmsig-entityUpTime GET NOTIFICATIONS ObjectCreationUnConfirmed, ObjectDeletionUnConfirmed, AttributeChangeUnConfirmed, ProcessingAlarmUnConfirmed, StateChangeUnConfirmed, nmsig-counterWrapUnConfirmed PACKAGE nmsig-clNetworkProtocolLayerEntityRedirection PRESENT IF connectionless network protocol layer entity supports redirection of recd PDUs REGISTERED AS {obj-class} 4.6.2. NMSIG Connectionless Network Protocol Layer Entity Behaviour clNetworkProtocolLayerEntity-behaviour BEHAVIOUR DEFINED AS The managed object class nmsig-clNetworkProtocolEntity represents an instantiation of a connectionless network protocol layer. The network layer is layer three of the OSI Reference Model. It provides network services for the transparent transfer of data between peer transport entities. It relieves the transport protocol layer from the need to know anything about the underlying network technologies used to achieve data transfer. The connectionless network protocol layer does not make use of a network connection for the purposes of transferring data. No dynamic peer to peer agreement is involved in the process of data transfer. An instance of this managed object class supports only one type of protocol and one address domain. This managed object class represents a "generic" view of a connectionless network protocol layer entity. It does not concern itself with the details of specific network protocols. Network entities that are tied to a specific network protocol can be defined as its subclasses; in fact their definitions are being progressed within various standards' bodies. The purpose of defining this managed object class, however, is to provide a common base that will facilitate the high level management of similar but slightly differing resources. The NMSIG connectionless network protocol layer entity managed object class supports all the values of the administrative state attribute. It supports only the 'disabled' and 'enabled' values of the operational state attribute. The 'enabled' value of the operational state indicates that the underlying connectionless network protocol layer entity resource is capable of providing connectionless network layer services. The 'disabled' value of the operational state indicates that the underlying connectionless network protocol layer entity resource is incapable of supporting any network services at the current time. The CreateInfo field of the ObjectCreation notification shall contain all the attributes of the created connectionless network protocol layer entity instance. The DeleteInfo field of the ObjectDeletion notification shall contain all the attributes of the deleted connectionless network protocol layer entity instance. Attributes that are subject to the AttributeChange notification are: nmsig-localNetworkAddresses, nmsig-nPDUTimeToLive, nmsig- productInfo, and HealthState Attributes that are subject to the StateChange notification are: AdministrativeState and OperationalState. The counterWrap notification is emitted when any of the counter attributes wrap. 4.6.3. NMSIG CL Network Protocol Layer Entity Redirection Package nmsig-clNetworkProtocolLayerEntityRedirection CONDITIONAL PACKAGE BEHAVIOUR DEFINITIONS clNetworkProtocolLayerEntityRedirection- behaviour ATTRIBUTES nmsig-PDUsRedirected GET REGISTERED AS {package} clNetworkProtocolLayerEntityRedirection-behaviour BEHAVIOUR DEFINED AS This package reflects the redirection capability of the underlying connectionless network protocol layer entity resource. 4.7. NMSIG Equipment 4.7.1. NMSIG Equipment Definition nmsig-equipment MANAGED OBJECT CLASS DERIVED FROM {top} CHARACTERIZED BY BEHAVIOUR DEFINITIONS equipment-behaviour ATTRIBUTES nmsig-equipmentId GET, OperationalState GET, HealthState GET, AdministrativeState GET-REPLACE, nmsig-locationName GET-REPLACE, nmsig-contactNames ADD-REMOVE, nmsig-equipmentPurpose GET-REPLACE, nmsig-productInfo GET, nmsig-vendorName GET-REPLACE, nmsig-userFriendlyLabel GET-REPLACE NOTIFICATIONS EnvironmentalAlarmUnConfirmed, EquipmentAlarmUnConfirmed, ObjectCreationUnConfirmed, ObjectDeletionUnConfirmed, AttributeChangeUnConfirmed, StateChangeUnconfirmed REGISTERED AS {obj-class} 4.7.2. NMSIG Equipment Behaviour equipment-behaviour BEHAVIOUR DEFINED AS The NMSIG equipment managed object class represents physical entities. Instances of this managed object class are located in specific geographic locations and support some type of functions. For example, a PBX, which may be regarded as an instance of this managed object class, performs switching functions. Multiplexers, amplifiers, and repeaters which can also be regarded as instances of this managed object class perform transmission functions. Equipment may be nested in equipment, thereby creating a containment relationship. For example, a line card is contained in an equipment shelf which is nested in a relay rack which is part of a switch. Instances of this managed object class may be endpoints of a circuit or facility. The NMSIG Contact Names attribute specifies who (persons or organizations) are to be contacted about the equipment. The NMSIG Location Name attribute identifies where the equipment is located. The NMSIG Vendor Name attribute identifies the organization from whom the equipment was obtained (i.e., purchased, leased, etc.). The NMSIG equipment managed object class supports all permissible values of the administrative and operational states. The CreateInfo field of the ObjectCreation notification shall contain all the attributes of the created equipment instance. The DeleteInfo field of the ObjectDeletion notification shall contain all the attributes of the deleted equipment instance. Attributes that are subject to the AttributeChange notification are: nmsig-locationName, nmsig-contactNames, nmsig- equipmentPurpose, nmsig-productInfo, nmsig-vendorName, nmsig- userFriendlyLabel, HealthState. Attributes that are subject to the StateChange notification are: AdministrativeState and OperationalState. 4.8. NMSIG IEEE 802.3 4.8.1. NMSIG IEEE 802.3 Definition nmsig-IEEE-802.3 MANAGED OBJECT CLASS DERIVED FROM {top} CHARACTERIZED BY BEHAVIOUR DEFINITIONS iEEE-802.3-behaviour ATTRIBUTES nmsig-IEEE-802.3Id GET, OperationalState GET, AdministrativeState GET-REPLACE, nmsig-macAddress GET-REPLACE, nmsig-IEEE-802.3State GET-REPLACE, nmsig-multicastAddressList GET-REPLACE, HealthState GET OPERATIONS DELETE ACTIONS nmsig-executeSelfTest NOTIFICATIONS ObjectCreationUnConfirmed, ObjectDeletionUnConfirmed, AttributeChangeUnConfirmed, StateChangeUnconfirmed REGISTERED AS {obj-class} 4.8.2. NMSIG IEEE 802.3 Behaviour iEEE-802.3-behaviour BEHAVIOUR DEFINED AS The managed object class nmsig-IEEE-802.3 represents an instantiation of an IEEE 802.3 CSMA/CD MAC. It may contain either an nmsig-IEEE-802.3-XMT managed object, an nmsig-802.3-RCV managed object, or both of these subordinate objects, as shown in the following figure. +-----------------------------------------+ | NMSIG IEEE 802.3 | | | | +---------------+ +---------------+ | | | NMSIG IEEE | | NMSIG IEEE | | | | 802.3 XMT | | 802.3 RCV | | | +---------------+ +---------------+ | | | +-----------------------------------------+ The NMSIG IEEE 802.3 managed object class supports only the 'enabled' and 'disabled' values of the operational state attribute. The 'enabled' value indicates that the underlying IEEE 802.3 resource is available for use, and the 'disabled' value indicates that the underlying IEEE 802.3 resource is not available for use. The NMSIG IEEE 802.3 managed object class supports the DELETE operation; this operation serves to reinitialize the CSMA/CD MAC. The NMSIG IEEE 802.3 managed object class supports an nmsig-executeSelfTest ACTION; this action causes a self test to be performed on the referenced managed object instance. The CreateInfo field of the ObjectCreation notification shall contain all the attributes of the created IEEE 802.3 instance. The DeleteInfo field of the ObjectDeletion notification shall contain all the attributes of the deleted IEEE 802.3 instance. Attributes that are subject to the AttributeChange notification are: nmsig-macAddress, nmsig-multicastAddressList, HealthState. Attributes that are subject to the StateChange notification are: AdministrativeState and OperationalState. 4.9. NMSIG IEEE 802.3 RCV 4.9.1. NMSIG IEEE RCV Definition nmsig-IEEE-802.3-RCV MANAGED OBJECT CLASS DERIVED FROM {top} CHARACTERIZED BY BEHAVIOUR DEFINITIONS iEEE-802.3-RCV-behaviour ATTRIBUTES nmsig-IEEE-802.3-RCVId GET, OperationalState GET, AdministrativeState GET-REPLACE, HealthState GET, nmsig-multicastRcvState GET-REPLACE, PDUsReceivedCounter GET, nmsig-PDUsFCSErrorCounter GET, nmsig-PDUsAlignmentErrorCounter GET, nmsig-PDUsInRangeLengthErrorCounter GET, nmsig-PDUsOutRangeLengthErrorCounter GET, nmsig-PDUsTooLongErrorCounter GET OctetsReceivedCounter GET, nmsig-multicastPDUsRcvCounter GET, nmsig-broadcastPDUsRcvCounter GET, nmsig-internalMACRcvErrorCounter GET, nmsig-sourceAddrLastFCSErrorPDU GET, nmsig-sourceAddrLastAlignmentErrorPDU GET, nmsig-sourceAddrLastInRangeLengthErrorPDU GET, nmsig-sourceAddrLastOutRangeLengthErrorPDU GET, nmsig-sourceAddrLastTooLongErrorPDU GET, nmsig-FCSErrorThreshold GET-REPLACE, nmsig-alignmentErrorThreshold GET-REPLACE, nmsig-inRangeThreshold GET-REPLACE, nmsig-outRangeThreshold GET-REPLACE, nmsig-frameTooLongThreshold GET-REPLACE, nmsig-internalMACRcvErrorThreshold GET-REPLACE, nmsig-enablePromiscuousState GET-REPLACE NOTIFICATIONS ObjectCreationUnConfirmed, ObjectDeletionUnConfirmed, AttributeChangeUnConfirmed, StateChangeUnConfirmed, ProcessingAlarmUnConfirmed, nmsig-counterWrapUnConfirmed, CommunicationAlarmUnConfirmed REGISTERED AS {obj-class} 4.9.2. NMSIG IEEE 802.3 RCV Behaviour iEEE-802.3-RCV-behaviour BEHAVIOUR DEFINED AS The managed object class nmsig-IEEE-802.3-RCV represents an instantiation of an IEEE 802.3 CSMA/CD MAC receiver. This object may be contained within an nmsig-IEEE-802.3 managed object. The NMSIG IEEE 802.3 RCV managed object class supports only the 'enabled' and 'disabled' values of the operational state attribute. The 'enabled' value indicates that the underlying IEEE 802.3 RCV resource is available for use, and the 'disabled' value indicates that the underlying IEEE 802.3 RCV resource is not available for use. The definitive description of the counter attributes, their operation and precedence is specified in the [IEEE Doc X]. The NMSIG IEEE 802.3 RCV managed object class supports several threshold attributes; all are associated with the generation of a Communication Alarm notification. The CreateInfo field of the ObjectCreation notification shall contain all the attributes of the created IEEE 802.3 RCV instance. The DeleteInfo field of the ObjectDeletion notification shall contain all the attributes of the deleted IEEE 802.3 RCV instance. Attributes that are subject to the AttributeChange notification are: nmsig-multicastRcvState, nmsig-promiscuousRcvState, nmsig- FCSErrorThreshold, nmsig-alignmentErrorThreshold, nmsig-inRan- geThreshold, nmsig-outRangeThreshold, HealthState, nmsig- frameTooLongThreshold and nmsig-internalMACRcvErrorThreshold. Attributes that are subject to the StateChange notification are: AdministrativeState and OperationalState. The counterWrap notification is emitted when any of the counter attributes wrap. 4.10. NMSIG IEEE 802.3 XMT 4.10.1. NMSIG IEEE 802.3 XMT Definition nmsig-IEEE-802.3-XMT MANAGED OBJECT CLASS DERIVED FROM {top} CHARACTERIZED BY BEHAVIOUR DEFINITIONS iEEE-802.3-XMT-behaviour ATTRIBUTES nmsig-IEEE-802.3-XMTId GET, OperationalState GET, AdministrativeState GET-REPLACE, HealthState GET, nmsig-XmtState GET-REPLACE, PDUsSentCounter GET, nmsig-singleCollisionPDUsCounter GET, nmsig-multipleCollisionPDUsCounter GET, nmsig-lateCollisionsCounter GET, nmsig-PDUsAbortedExcessiveCollisionsCounter GET, nmsig-carrierSenseErrorsCounter GET, nmsig-collisionPDUsCounter GET, OctetsSentCounter GET, nmsig-multicastPDUsXmtCounter GET, nmsig-broadcastPDUsXmtCounter GET, nmsig-PDUsLostInternalMACXmtErrorCounter GET, nmsig-PDUsExcessiveDeferralCounter GET, nmsig-collisionPDUsThreshold GET-REPLACE, nmsig-lateCollisionsThreshold GET-REPLACE, nmsig-PDUsAbortedExcessColThreshold GET-REPLACE, nmsig-carrierSenseErrorsThreshold GET-REPLACE, nmsig-internalMACXmtErrorThreshold GET-REPLACE, nmsig-excessiveDeferralThreshold GET-REPLACE NOTIFICATIONS ObjectCreationUnConfirmed, ObjectDeletionUnConfirmed, AttributeChangeUnConfirmed, CommunicationAlarmUnConfirmed, StateChangeUnConfirmed, ProcessingAlarmUnConfirmed, nmsig-counterWrapUnConfirmed REGISTERED AS {obj-class} 4.10.2. NMSIG IEEE 802.3 XMT Behaviour iEEE-802.3-XMT-behaviour BEHAVIOUR DEFINED AS The managed object class nmsig-IEEE-802.3-XMT represents an instantiation of an IEEE 802.3 CSMA/CD MAC transmitter. This object may be contained within an nmsig-IEEE-802.3 managed object. The NMSIG IEEE 802.3 XMT managed object class supports only the 'enabled' and 'disabled' values of the operational state attribute. The 'enabled' value indicates that the underlying IEEE 802.3 XMT resource is available for use, and the 'disabled' value indicates that the underlying IEEE 802.3 XMT resource is not available for use. The NMSIG IEEE 802.3 XMT managed object class supports both the 'locked' and 'unlocked' values of the administrative state attribute. Unlocking the administrative state serves to enable transmit on the underlying IEEE 802.3 XMT resource. The definitive description of the counter attributes, their operation and precedence is specified in the [IEEE Doc X]. The NMSIG IEEE 802.3 XMT managed object class supports several threshold attributes; all are associated with the generation of a CommunicationAlarm notification. The CreateInfo field of the ObjectCreation notification shall contain all the attributes of the created IEEE 802.3 XMT instance, including those inherited from the nmsig-equipment managed object class. The DeleteInfo field of the ObjectDeletion notification shall contain all the attributes of the deleted IEEE 802.3 XMT instance, including those inherited from the nmsig-equipment managed object class. Attributes that are subject to the AttributeChange notification are: nmsig-collisionPDUsThreshold, nmsig- lateCollisionsThreshold, nmsig-PDUsAbortedExcessColThreshold, nmsig-carrierSenseErrorThreshold, nmsig- internalMACXmtErrorThreshold, nmsig-excessiveDeferralThreshold, HealthState. Attributes that are subject to the StateChange notification are: AdministrativeState and OperationalState. The counterWrap notification is emitted when any of the counter attributes wrap. 4.11. NMSIG LAN MAC Bridge 4.11.1. NMSIG LAN MAC Bridge Definition nmsig-LAN-MAC-Bridge MANAGED OBJECT CLASS DERIVED FROM {nmsig-equipment} CHARACACTERIZED BY BEHAVIOUR DEFINITIONS lAN-MAC-Bridge-behaviour ATTRIBUTES nmsig-packetLossRate GET, nmsig-packetLossRateThreshold GET-REPLACE NOTIFICATIONS CommunicationAlarm REGISTERED AS {obj-class} 4.11.2. NMSIG LAN MAC Bridge Behaviour lAN-MAC-Bridge-behaviour BEHAVIOUR DEFINED AS A LAN MAC bridge is a device which interconnects two or more MAC domains. A MAC domain is an instance of a MAC algorithm (e.g., a Collision Domain or a Token Domain). The LAN MAC bridge contains two or more MAC ports each associated with a MAC Domain and operating at layer two of the OSI Model. The function of the LAN MAC bridge is to forward frames from any one MAC Domain to one or more of the other MAC domains. This managed object class represents the LAN MAC bridge device. The definition of this managed object class is based upon the IEEE 802.1 D specification. The NMSIG LAN MAC bridge managed object class supports only the 'enabled' and 'disabled' values of the operational state attribute. The 'enabled' value indicates that the underlying LAN MAC bridge resource is available for use, and the 'disabled' value indicates that the underlying LAN MAC bridge resource is not available for use. The CreateInfo field of the ObjectCreation notification shall contain all the attributes of the created LAN MAC Bridge instance. The DeleteInfo field of the ObjectDeletion notification shall contain all the attributes of the deleted LAN MAC Bridge instance. Attributes, additioal to those that have been inherited from Equipment, that are subject to the AttributeChange notification are: nmsig-packetLossRateThreshold. 4.12. NMSIG MAC Port 4.12.1. NMSIG MAC Port Definition nmsig-MAC-Port MANAGED OBJECT CLASS DERIVED FROM {top} CHARACTERIZED BY BEHAVIOUR DEFINITIONS mAC-Port-behaviour ATTRIBUTES nmsig-MAC-PortId GET, nmsig-MAC-PortInNonUCastPktsCounter GET, nmsig-MAC-PortOutNonUCastPktsCounter GET, nmsig-MAC-PortInUCastPktsCounter GET, nmsig-MAC-PortOutUCastPktsCounter GET, nmsig-MAC-PortOutDelayDiscPktsCounter GET, nmsig-MAC-PortOutQLen GET, nmsig-MAC-PortInOctetRate GET, nmsig-MAC-PortInOctetRateThreshold GET-REPLACE, AdministrativeState GET-REPLACE, OperationalState GET, HealthState GET, nmsig-broadcastForwardingState GET-REPLACE, nmsig-multicastForwardingState GET-REPLACE NOTIFICATIONS ObjectCreationUnConfirmed, ObjectDeletionUnConfirmed, AttributeChangeUnConfirmed, StateChangeUnConfirmed, nmsig-counterWrapUnConfirmed, CommunicationAlarmUnConfirmed REGISTERED AS {obj-class} 4.12.2. NMSIG MAC Port Behaviour mAC-Port-behaviour BEHAVIOUR DEFINED AS This managed object class represents a MAC Port. A MAC Port is contained in a LAN MAC Bridge. It provides the physical connection to a MAC Domain. The NMSIG MAC Port managed object class supports only the 'enabled' and 'disabled' values of the operational state attribute. The 'enabled' value indicates that the underlying MAC Port resource is available for use, and the 'disabled' value indicates that the underlying MAC port resource is not available for use. The CreateInfo field of the ObjectCreation notification shall contain all the attributes of the created MAC Port instance. The DeleteInfo field of the ObjectDeletion notification shall contain all the attributes of the deleted MAC Port instance. Attributes that are subject to the AttributeChange notification are: HealthState, nmsig-MAC-PortInOctetsRateThreshold, nmsig- broadcastForwardingState and nmsig-multicastForwardingState. Attributes that are subject to the StateChange notification are: AdministrativeState and OperationalState. The counterWrap notification is emitted when any of the counter attributes wrap. 4.13. NMSIG Network 4.13.1. NMSIG Network Definition nmsig-network MANAGED OBJECT CLASS DERIVED FROM {top} CHARACTERIZED BY BEHAVIOUR DEFINITIONS network-behaviour ATTRIBUTES nmsig-networkId GET, nmsig-networkPurpose GET, nmsig-userFriendlyLabel GET-REPLACE NOTIFICATIONS ObjectCreationUnConfirmed, ObjectDeletionUnConfirmed, AttributeChangeUnConfirmed REGISTERED AS {obj-class} 4.13.2. NMSIG Network Behaviour network-behaviour BEHAVIOUR DEFINED AS The NMSIG Network managed object class represents a collection of connecting and interconnected resources (logical and physical) capable of exchanging information. A network may be contained in another network, thereby creating a superior/subordinate relationship. The CreateInfo field of the ObjectCreation notification shall contain all the attributes of the created network instnace. The DeleteInfo field of the ObjectDeletion notification shall contain all the attributes of the deleted network instance. Attributes that are subject to the AttributeChange notification are: nmsig-networkPurpose, nmsig-userFriendlyLabel 4.14. NMSIG Processing Entity 4.14.1. NMSIG Processing Entity Definition nmsig-processingEntity MANAGED OBJECT CLASS DERIVED FROM {nmsig-equipment} CHARACTERIZED BY BEHAVIOUR DEFINITIONS processingEntity-behaviour ATTRIBUTES nmsig-cPU-Type GET, nmsig-memorySize GET, nmsig-osInfo GET, nmsig-entityUpTime GET OPERATIONS DELETE NOTIFICATIONS ProcessingAlarmUnConfirmed REGISTERED AS {obj-class} 4.14.2. NMSIG Processing Entity Behaviour processingEntity-behaviour BEHAVIOUR DEFINED AS The NMSIG processing entity managed object class represents the physical portion of the computer system that performs the processing function. A processing entity may be composed of such components as arithmetic logic units (ALUs) registers for processing memory, limited storage often in the form of Random Access Memory (RAM), and various other types of memory used in the processing function. It does not include components such as disk drives, data bases, etc. Some processing entities may have input/output channels, particularly when hardware is shared between elements of the processing entity. In other cases, the input/output may be viewed as components of a superior object, e.g. a computer system, or even shared among several computer systems. The NMSIG processing entity managed object class supports all the values of the administrative state. It supports only the enabled and disabled values of the operational state. An instance of the NMSIG Processing Entity managed object class must be created before any of its subordinates are created. The CreateInfo field of the ObjectCreation notification shall contain all the attributes of the created processing entity instance. The DeleteInfo field of the ObjectDeletion notification shall contain all the attributes of the deleted processing entity instance. Attributes, additional to those inherited from Equipment, that are subject to the AttributeChange notification are: nmsig- cPU-Type, nmsig-memorySize, nmsig-osInfo 4.15. NMSIG Root 4.15.1. NMSIG Root Definition nmsig-root MANAGED OBJECT CLASS DERIVED FROM top CHARACTERIZED BY BEHAVIOUR DEFINITIONS root-behaviour REGISTERED AS {obj-class} 4.15.2. NMSIG Root Behaviour root-behaviour BEHAVIOUR DEFINED AS This managed object class is used to represent the most superior object instance in the containment tree. The purpose of this managed object class is to serve as the common point from which all instances of managed object classes are named. A single instance of this managed object class is always present in every system, with a distinguished name that is a null sequence (i.e. a SEQUENCE OF with a length of zero). 4.16. NMSIG Transport Connection 4.16.1. NMSIG Transport Connection Definition nmsig-transportConnection MANAGED OBJECT CLASS DERIVED FROM {top} CHARACTERIZED BY BEHAVIOUR DEFINITIONS transportConnection-behaviour ATTRIBUTES nmsig-transportConnectionId GET, nmsig-localTransportConnectionEndpoint GET, nmsig-remoteTransportConnectionEndpoint GET, nmsig-transportConnectionReference GET, nmsig-localNetworkAddress GET, nmsig-remoteNetworkaddress GET, nmsig-inactivityTimeout GET, nmsig-maxPDuSize GET, PDUsSentCounter GET, PDUsReceivedCounter GET, OctetsSentCounter GET, OctetsReceivedCounter GET, Peer GET OPERATIONS DELETE deletes contained objects NOTIFICATIONS ObjectCreationUnConfirmed, ObjectDeletionUnConfirmed, RelationshipChangeUnConfirmed, nmsig-counterWrapUnConfirmed PACKAGE nmsig-transportConnectionRetransmission PRESENT IF transport protocol supports retransmission REGISTERED AS {obj-class} 4.16.2. NMSIG Transport Connection Behaviour transportConnection-behaviour BEHAVIOUR DEFINED AS The managed object class nmsig-transportConnection represents an active transport connection (e.g., an OSI transport connection or a TCP connection). A transport connection is established and used by two peer connection oriented transport protocol layer entities for the purpose of transferring data. A connection oriented transport protocol layer entity may support multiple transport connections. This managed object class represents a "generic" view of a transport connection. It does not concern itself with the details of specific transport protocols like ISO TP or TCP. Transport connections that are tied to a specific protocol can be defined as its subclasses; in fact their definitions are being progressed within various standards' bodies. The purpose of defining this managed object class, however, is to provide a common base that will facilitate the high level management of similar but slightly differing resources. The expected real effect of the DELETE operation when applied to an instance of the NMSIG transport connection managed object class is that the underlying transport connection resource is aborted. The CreateInfo field of the ObjectCreation notification shall contain all the attributes of the created transport connection instance. The DeleteInfo field of the ObjectDeletion notification shall contain all the attributes of the created transport connection instance. In addition it shall also contain a 'cause' parameter defined as follows: cause ::= SEQUENCE { INTEGER (unknown (0), user (1), provider (2)), INTEGER (unknown (0), local (1), remote (2)), INTEGER (unknown (0), excessiveIdle (1), excessiveRtx (2)) } The counterWrap notification is emitted when any of the counter attributes wrap. The RelationshipChange notification is emitted whenever the peer attribute changes in value. 4.16.3. NMSIG Transport Connection Retransmission Package nmsig-transportConnectionRetransmission CONDITIONAL PACKAGE BEHAVIOUR DEFINITIONS transportConnectionRetransmission- behaviour ATTRIBUTES nmsig-maxRetransmissions GET, nmsig-retransmissionTimerInitialValue GET, PDUsRetransmittedErrorCounter GET, PDUsRetransmittedRate GET, PDUsRetransmittedRateThreshold GET-REPLACE, nmsig-octetsRetransmitted GET NOTIFICATIONS AttributeChange CommunicationAlarmUnConfirmed REGISTERED AS {package} transportConnectionRetransmission-behaviour BEHAVIOUR DEFINED AS This package reflects the retransmitting capability of the underlying transport protocol resource. Attributes that are subject to the AttributeChange notification are: PDUsRetransmittedRateThreshold. 4.17. NMSIG Transport Connection Profile 4.17.1. NMSIG Transport Connection Profile Definition nmsig-transportConnectionProfile MANAGED OBJECT CLASS DERIVED FROM {top} CHARACTERIZED BY BEHAVIOUR DEFINITIONS trasnportConnectionProfile-behaviour ATTRIBUTES nmsig-transportConnectionProfileId GET, nmsig-inactivityTimeout GET-REPLACE, nmsig-maxTPDuSize GET-REPLACE OPERATIONS CREATE, DELETE NOTIFICATIONS ObjectCreation ObjectDeletion AttributeChange REGISTERED AS {obj-class} 4.17.2. NMSIG Transport Connection Profile Behaviour transportConnectionProfile-behaviour BEHAVIOUR DEFINED AS This managed object class represents the collection of characteristic attributes which supply default and initially advertised attribute values to be used by instances of the NMSIG Transport Connection managed object class when they are created. There can be only one instance of the NMSIG Transport Connection Profile managed object class for each instance of the NMSIG CO Transport Protocol Layer Entity managed object class. The CreateInfo field of the ObjectCreation notification shall contain all the attributes of the created transport connection profile instance. The DeleteInfo field of the ObjectDeletion notification shall contain all the attributes of the deleted transport connection profile instance. Attributes that are subject to the AttributeChange notification are: nmsig-inactivityTimeout, nmsig-maxTPDuSize. 4.18. NMSIG Transport Connection Retransmission Profile 4.18.1. NMSIG Transport Connection Retransmission Profile Definition nmsig-transportConnectionRetransmissionProfile MANAGED OBJECT CLASS DERIVED FROM nmsig-transportConnectionProfile CHARACTERIZED BY BEHAVIOUR DEFINITIONS transportConnectionProfile-behaviour ATTRIBUTES nmsig-maxRetransmissions GET-REPLACE, nmsig-retransmissionTimerInitialValue GET-REPLACE REGISTERED AS {obj-class} 4.18.2. NMSIG Transport Connection Retransmission Profile Behaviour transportConnectionRetransmissionProfile-behaviour BEHAVIOUR DEFINED AS This managed object class represents the collection of characteristic attributes which supply default and initially advertised attribute values to be used by instances of the NMSIG Transport Connection managed object class that support retransmission, when they are created. There can be only one instance of the NMSIG Transport Connection Retransmission Profile managed object class for each instance of the NMSIG CO Transport Protocol Layer Entity managed object class. Attributes, additional to those inherited from the transport connection profile managed object class, that are subject to the AttributeChange notification are : nmsig- maxRetransmissions, nmsig-retransmissionTimerInitialValue 4.19. Top This managed object class represents the root of the inheritance tree. Refer to [ISO Doc x] for the definition of this managed object class. 5. NAME BINDINGS This section provides definitions of NAME BINDINGS for the managed object classes defined by the OSI MIB Working Group. NAME BINDINGs for managed object classes defined by other groups can be found in the document referenced under the managed object class definition in Section 3. 5.1. Event Forwarding Discriminator Name Bindings EventForwardingDiscriminator-nb-1 NAME BINDING EventForwardingDiscriminator IS NAMED BY nmsig-agent WITH ATTRIBUTE DiscriminatorId REGISTERED AS {nmsig-nb} 5.2. NMSIG Agent Name Bindings nmsig-agent-nb-1 NAME BINDING nmsig-agent IS NAMED BY nmsig-root WITH ATTRIBUTE nmsig-agentId REGISTERED AS {nmsig-nb} 5.3. NMSIG Computer System Name Bindings nmsig-computerSystem-nb-1 NAME BINDING nmsig-computerSystem IS NAMED BY nmsig-network WITH ATTRIBUTE nmsig-systemId REGISTERED AS {nmsig-nb} nmsig-computerSystem-nb-2 NAME BINDING nmsig-computerSystem IS NAMED BY nmsig-computerSystem WITH ATTRIBUTE nmsig-systemId REGISTERED AS {nmsig-nb} nmsig-computerSystem-nb-3 NAME BINDING nmsig-computerSystem IS NAMED BY nmsig-root WITH ATTRIBUTE nmsig-systemId REGISTERED AS {nmsig-nb} 5.4. NMSIG CO Transport Protocol Layer Entity Name Bindings nmsig-coTransportProtocolLayerEntity-nb-1 NAME BINDING nmsig-coTransportProtocolLayerEntity IS NAMED BY nmsig- computerSystem WITH ATTRIBUTE nmsig-coTransportEntityId REGISTERED AS {nmsig-nb} nmsig-coTransportProtocolLayerEntity-nb-2 NAME BINDING nmsig-coTransportProtocolLayerEntity IS NAMED BY nmsig-equipment WITH ATTRIBUTE nmsig-coTransportEntityId REGISTERED AS {nmsig-nb} 5.5. NMSIG CL Network Protocol Layer Entity Name Bindings nmsig-clNetworkProtocolLayerEntity-nb-1 NAME BINDING nmsig-clNetworkProtocolLayerEntity IS NAMED BY nmsig-computerSystem WITH ATTRIBUTE nmsig-clNetworkProtocolEntityId REGISTERED AS {nmsig-nb} nmsig-clNetworkProtocolLayerEntity-nb-2 NAME BINDING nmsig-clNetworkProtocolLayerEntity IS NAMED BY nmsig-equipment WITH ATTRIBUTE nmsig-clNetworkProtocolEntityId REGISTERED AS {nmsig-nb} 5.6. NMSIG Equipment Name Bindings nmsig-equipment-nb-1 NAME BINDING nmsig-equipment IS NAMED BY nmsig-equipment WITH ATTRIBUTE nmsig-equipmentId REGISTERED AS {nmsig-nb} nmsig-equipment-nb-2 NAME BINDING nmsig-equipment IS NAMED BY nmsig-network WITH ATTRIBUTE nmsig-equipmentId REGISTERED AS {nmsig-nb} nmsig-equipment-nb-3 NAME BINDING nmsig-equipment IS NAMED BY nmsig-root WITH ATTRIBUTE nmsig-equipmentId REGISTERED AS {nmsig-nb} 5.7. NMSIG IEEE 802.3 Name Bindings nmsig-IEEE-802.3-nb-1 NAME BINDING nmsig-IEEE-802.3 IS NAMED BY nmsig-network WITH ATTRIBUTE nmsig-IEEE-802.3Id REGISTERED AS {nmsig-nb} nmsig-IEEE-802.3-nb-2 NAME BINDING nmsig-IEEE-802.3 IS NAMED BY nmsig-computerSystem WITH ATTRIBUTE nmsig-IEEE-802.3Id REGISTERED AS {nmsig-nb} 5.8. NMSIG IEEE 802.3 RCV Name Bindings nmsig-IEEE-802.3-RCV-nb-1 NAME BINDING nmsig-IEEE-802.3-RCV IS NAMED BY nmsig-IEEE-802.3 WITH ATTRIBUTE nmsig-IEEE-802.3-RCVId REGISTERED AS {nmsig-nb} 5.9. NMSIG IEEE 802.3 XMT Name Bindings nmsig-IEEE-802.3-XMT-nb-1 NAME BINDING nmsig-IEEE-802.3-XMT IS NAMED BY nmsig-IEEE-802.3 WITH ATTRIBUTE nmsig-IEEE-802.3-XMTId REGISTERED AS {nmsig-nb} 5.10. NMSIG LAN MAC Bridge Name Bindings nmsig-LAN-MAC-Bridge-nb-1 NAME BINDING nmsig-LAN-MAC-Bridge IS NAMED BY nmsig-network WITH ATTRIBUTE nmsig-equipmentId REGISTERED AS {nmsig-nb} 5.11. NMSIG MAC Port Name Bindings nmsig-MAC-Port-nb-1 NAME BINDING nmsig-MAC-Port IS NAMED BY nmsig-LAN-MAC-Bridge WITH ATTRIBUTE nmsig-MAC-PortId REGISTERED AS {nmsig-nb} 5.12. NMSIG Network Name Bindings nmsig-network-nb-1 NAME BINDING nmsig-network IS NAMED BY nmsig-network WITH ATTRIBUTE nmsig-networkId REGISTERED AS {nmsig-nb} nmsig-network-nb-2 NAME BINDING nmsig-network IS NAMED BY nmsig-root WITH ATTRIBUTE nmsig-networkId REGISTERED AS {nmsig-nb} 5.13. NMSIG Processing Entity Name Bindings nmsig-processingEntity-nb-1 NAME BINDING nmsig-processingEntity IS NAMED BY nmsig-computerSystem WITH ATTRIBUTE nmsig-equipmentId REGISTERED AS {nmsig-nb} 5.14. NMSIG Transport Connection Name Bindings nmsig-transportConnection-nb-1 NAME BINDING nmsig-transportConnection IS NAMED BY nmsig-coTransportProtocolLayerEntity WITH ATTRIBUTE nmsig-transportConnectionId REGISTERED AS {nmsig-nb} 5.15. NMSIG Transport Connection Profile Name Bindings nmsig-transportConnectionProfile-nb-1 NAME BINDING nmsig-transportConnectionProfile IS NAMED BY nmsig-coTransportProtocolLayerEntity WITH ATTRIBUTE nmsig-transportConnectionProfileId REGISTERED AS {nmsig-nb} 5.16. NMSIG Transport Connection Retransmission Profile Name Bindings nmsig-transportConnectionRetransmissionProfile-nb-1 NAME BINDING nmsig-transportConnectionRetransmissionProfile IS NAMED BY nmsig-coTransportProtocolLayerEntity WITH ATTRIBUTE nmsig-transportConnectionProfileId REGISTERED AS {nmsig-nb} 6. ATTRIBUTES This section provides definitions of attributes contained in the managed object classes defined by the OSI MIB Working Group. Attribute definitions for managed object classes defined by other groups can be found in the document referenced under the managed object class definition in section 3. 6.1. Administrative State Refer to [ISO Doc x] for the definition of this attribute. 6.2. Begin Time Refer to [ISO Doc x] for the definition of this attribute. 6.3. Destination Address Refer to [ISO Doc x] for the definition of this attribute. 6.4. Discriminator Construct Refer to [ISO Doc x] for the definition of this attribute. 6.5. Discriminator Id Refer to [ISO Doc x] for the definition of this attribute. 6.6. End Time Refer to [ISO Doc x] for the definition of this attribute. 6.7. Health State Refer to [ISO Doc x] for the definition of this attribute. 6.8. Incoming Connection Reject Error Counter Refer to [ISO Doc X] for the definition of this attribute. 6.9. Incoming Connection Requests Counter Refer to [ISO Doc X] for the definition of this attribute. 6.10. Incoming Disconnect Error Counter Refer to [ISO Doc X] for the definition of this attribute. 6.11. Incoming Temporal Error Counter Refer to [ISO Doc X] for the definition of this attribute. 6.12. NMSIG Alignment Error Threshold nmsig-alignmentErrorThreshold ATTRIBUTE WITH ATTRIBUTE SYNTAX GaugeThreshold MATCHES FOR Equality BEHAVIOUR alignmentErrorThreshold-behaviour REGISTERED AS {nmsig-attr} GaugeThreshold ::= {as defined in ISO Doc X} alignmentErrorThreshold-behaviour BEHAVIOUR DEFINED AS This attribute specifies a threshold which is applied against the alignment error rate. The alignment error rate is defined as the number of PDUs received with alignment errors divided by the total number of PDUs received. A communication alarm notification is emitted when the alignment error rate exceeds the threshold value. 6.13. NMSIG Agent Id nmsig-agentId ATTRIBUTE WITH ATTRIBUTE SYNTAX PrintableString BEHAVIOUR agentId-behaviour REGISTERED AS {nmsig-attr} agentId-behaviour BEHAVIOUR DEFINED AS This is the distinguishing attribute for the managed object class NMSIG Agent. 6.14. NMSIG Broadcast Forwarding State nmsig-broadcastForwardingState ATTRIBUTE WITH ATTRIBUTE SYNTAX State MATCHES FOR Equality BEHAVIOUR broadcastForwardingState-behaviour REGISTERED AS {nmsig-attr} State ::= ENUMERATED {off (0), on (1)} broadcastForwardingState-behaviour BEHAVIOUR DEFINED AS This attribute specifies whether broadcast PDUs are being forwarded. 6.15. NMSIG Broadcast PDUs Rcv Counter nmsig-broadcastPDUsRcvCounter ATTRIBUTE WITH ATTRIBUTE SYNTAX Count MATCHES FOR Equality, Ordering BEHAVIOUR broadcastPDUsRcvCounter-behaviour REGISTERED AS {nmsig-attr} Count ::= {as defined in ISO Doc X} broadcastPDUsRcvCounter-behaviour BEHAVIOUR DEFINED AS This attribute specifies the number of broadcast PDUs received ok by the underlying NMSIG IEEE 802.3 RCV resource. 6.16. NMSIG Broadcast PDUs Xmt Counter nmsig-broadcastPDUsXmtOkCounter ATTRIBUTE WITH ATTRIBUTE SYNTAX Count MATCHES FOR Equality, Ordering BEHAVIOUR broadcastPDUsXmtOkCounter-behaviour REGISTERED AS {nmsig-attr} Count ::= {as defined in ISO Doc X} broadcastPDUsXmtOkCounter-behaviour BEHAVIOUR DEFINED AS This attribute specifies the number of broadcast PDUs which were transmitted ok by the underlying NMSIG IEEE 802.3 XMT resource. 6.17. NMSIG Carrier Sense Errors Counter nmsig-carrierSenseErrorsCounter ATTRIBUTE WITH ATTRIBUTE SYNTAX Count MATCHES FOR Equality, Ordering BEHAVIOUR carrierSenseErrorsCounter-behaviour REGISTERED AS {nmsig-attr} Count ::= {as defined in ISO Doc X} carrierSenseErrorsCounter-behaviour BEHAVIOUR DEFINED AS This attribute specifies the number of carrier sense Errors which were detected by the underlying NMSIG IEEE 802.3 XMT resource. 6.18. NMSIG Carrier Sense Errors Threshold nmsig-carrierSenseErrorsThreshold ATTRIBUTE WITH ATTRIBUTE SYNTAX GaugeThreshold MATCHES FOR Equality BEHAVIOUR carrierSenseErrorsThreshold-behaviour REGISTERED AS {nmsig-attr} GaugeThreshold ::= {as defined in ISO Doc X} carrierSenseErrorsThreshold-behaviour BEHAVIOUR DEFINED AS This attribute specifies a threshold which is applied against the carrier sense error rate. The carrier sense error rate is defined as the carrier sense errors detected per second. A communication alarm notification is emitted when the carrier sense error rate exceeds the threshold value. 6.19. NMSIG Checksum TPDUs Discarded Counter nmsig-checksumTPDUsDiscardedCounter ATTRIBUTE WITH ATTRIBUTE SYNTAX Count MATCHES FOR Equality, Ordering BEHAVIOUR checksumTPDUsDiscardedCounter-behaviour REGISTERED AS {nmsig-attr} Count ::= {as defined in ISO Doc X} checksumTPDUsDiscardedCounter-behaviour BEHAVIOUR DEFINED AS This attribute specifies the number of TPDUs discarded due to a bad checksum. 6.20. NMSIG Collision PDUs Counter nmsig-collisionPDUsCounter ATTRIBUTE WITH ATTRIBUTE SYNTAX Count MATCHES FOR Equality, Ordering BEHAVIOUR collisionPDUsCounter-behaviour REGISTERED AS {nmsig-attr} Count ::= {as defined in ISO Doc X} collisionPDUsCounter-behaviour BEHAVIOUR DEFINED AS This attribute specifies the number of collision PDUs which were detected by the underlying NMSIG IEEE 802.3 XMT resource. 6.21. NMSIG Collision PDUs Threshold nmsig-collisionPDUsThreshold ATTRIBUTE WITH ATTRIBUTE SYNTAX GaugeThreshold MATCHES FOR Equality BEHAVIOUR collisionPDUsThreshold-behaviour REGISTERED AS {nmsig-attr} GaugeThreshold ::= {as defined in ISO Doc X} collisionPDUsThreshold-behaviour BEHAVIOUR DEFINED AS This attribute specifies a threshold which is applied against the collision PDU rate. The collision PDU rate is defined as the collision PDUs detected per second. A communication alarm notification is emitted when the collision PDU rate exceeds the threshold value. 6.22. NMSIG CO Transport Protocol Layer Entity Id nmsig-coTransportEntityId ATTRIBUTE WITH ATTRIBUTE SYNTAX PrintableString MATCHES FOR Equality BEHAVIOUR coTransportEntityId-behaviour REGISTERED AS {nmsig-attr} coTransportEntityID-behaviour BEHAVIOUR DEFINED AS This is the distinguishing attribute for the managed object class connection oriented transport protocol layer entity. 6.23. NMSIG Connectionless Network Protocol Layer Entity Id nmsig-clNetworkProtocolLayerEntityId ATTRIBUTE WITH ATTRIBUTE SYNTAX PrintableString MATCHES FOR Equality BEHAVIOUR clNetworkProtocolLayerEntityId-behaviour REGISTERED AS {nmsig-attr} clNetworkProtocolLayerEntityId-behaviour BEHAVIOUR DEFINED AS This attribute is the distinguishing attribute for the managed object class clNetworkProtocolLayerEntity. 6.24. NMSIG Contact Names nmsig-contactNames ATTRIBUTE WITH ATTRIBUTE SYNTAX AnyName MATCHES FOR Set Comparison, Set Intersection BEHAVIOUR contactNames-behaviour REGISTERED AS {nmsig-attr} AnyName ::= SET OF (CHOICE {dn DistinguishedName, ps PrintableString}) contactNames-behaviour BEHAVIOUR DEFINED AS This attribute specifies name(s) of one or more contacts. 6.25. NMSIG CPU Type nmsig-cPU-Type ATTRIBUTE WITH ATTRIBUTE SYNTAX PrintableString MATCHES FOR Equality BEHAVIOUR cPU-Type-behaviour REGISTERED AS {nmsig-attr} cPU-Type-behaviour BEHAVIOUR DEFINED AS This attribute specifies the type of the Central Processor Unit in a processing entity. 6.26. NMSIG Enable Promiscuous State nmsig-enablePromiscuousState ATTRIBUTE WITH ATTRIBUTE SYNTAX State MATCHES FOR Equality BEHAVIOUR enablePromiscuousState-behaviour REGISTERED AS {nmsig-attr} State ::= ENUMERATED {off (0), on (1)} enablePromiscuousState-behaviour BEHAVIOUR DEFINED AS This attribute specifies whether the IEEE 802.3 RCV is operating in promiscuous mode. 6.27. NMSIG Entity Up Time nmsig-entityUpTime ATTRIBUTE WITH ATTRIBUTE SYNTAX INTEGER MATCHES FOR Equality, Ordering BEHAVIOUR entityUpTime-behaviour REGISTERED AS {nmsig-attr} entityUpTime-behaviour BEHAVIOUR DEFINED AS This attribute specifies the time interval (in seconds) that has elapsed since the time that the value of the entity's operational state changed from 'disabled' to some other value, or since the time that the entity was created into a non disabled state. 6.28. NMSIG Equipment Id nmsig-equipmentId ATTRIBUTE WITH ATTRIBUTE SYNTAX PrintableString MATCHES FOR Equality BEHAVIOUR equipmentId-behaviour REGISTERED AS {nmsig-attr} equipmentId-behaviour BEHAVIOUR DEFINED AS This is the distinguishing attribute of the NMSIG equipment managed object class. 6.29. NMSIG Equipment Purpose nmsig-equipmentPurpose ATTRIBUTE WITH ATTRIBUTE SYNTAX PrintableString MATCHES FOR Equality BEHAVIOUR equipmentPurpose-behaviour REGISTERED AS {nmsig-attr} equipmentPurpose-behaviour BEHAVIOUR DEFINED AS This attribute specifies what the equipment is used for (e.g., switching, processing, etc.). 6.30. NMSIG Excessive Deferral Threshold nmsig-excessiveDeferralThreshold ATTRIBUTE WITH ATTRIBUTE SYNTAX GaugeThreshold MATCHES FOR Equality BEHAVIOUR excessiveDeferralThreshold-behaviour REGISTERED AS {nmsig-attr} GaugeThreshold ::= {as defined in ISO Doc X} excessiveDeferralThreshold-behaviour BEHAVIOUR DEFINED AS This attribute specifies a threshold which is applied against the excessive deferral rate. The excessive deferral rate is defined as the number of excessive deferral PDUs transmitted per second. A communication alarm notification is emitted when the excessive deferral rate exceeds the threshold value. 6.31. NMSIG FCS Error Threshold nmsig-FCSErrorThreshold ATTRIBUTE WITH ATTRIBUTE SYNTAX GaugeThreshold MATCHES FOR Equality BEHAVIOUR fCSErrorThreshold-behaviour REGISTERED AS {nmsig-attr} GaugeThreshold ::= {as defined by ISO Doc X} fCSErrorThreshold-behaviour BEHAVIOUR DEFINED AS This attribute specifies a threshold which is applied against the FCS error rate. The FCS error rate is defined as the number of PDUs received which had FCS errors divided by the total number of PDUs received. A communication alarm notification is emitted when the FCS error rate exceeds the threshold value. 6.32. NMSIG IEEE 802.3 Id nmsig-IEEE-802.3Id ATTRIBUTE WITH ATTRIBUTE SYNTAX PrintableString MATCHES FOR Equality BEHAVIOUR iEEE-802.3Id-behaviour REGISTERED AS {nmsig-attr} iEEE-802.3Id-behaviour BEHAVIOUR DEFINED AS This attribute is the distinguishing attribute of the NMSIG IEEE 802.3 managed object class. 6.33. NMSIG IEEE 802.3 RCV Id nmsig-IEEE-802.3-RCVId ATTRIBUTE WITH ATTRIBUTE SYNTAX PrintableString MATCHES FOR Equality BEHAVIOUR iEEE-802.3-RCVId-behaviour REGISTERED AS {nmsig-attr} iEEE-802.3-RCVId-behaviour BEHAVIOUR DEFINED AS This attribute is the distinguishing attribute of the NMSIG IEEE 802.3 RCV managed object class. 6.34. NMSIG IEEE 802.3 State nmsig-IEEE-802.3State ATTRIBUTE WITH ATTRIBUTE SYNTAX EnableState MATCHES FOR Equality BEHAVIOUR iEEE-802.3State-behaviour REGISTERED AS {nmsig-attr} EnableState ::= ENUMERATED {disable (0), enable (1)} iEEE-802.3State-behaviour BEHAVIOUR DEFINED AS This attribute specifies whether the IEEE 802.3 object is enabled or not. The 'enabled' and 'disabled' values of this attribute correspond to the 'enabled' and 'disabled' values of the OperationalState attribute. (This attribute was introduced as a GET-REPLACE attribute which can be used by management to enable or disable the underlying IEEE 802.3 resource.) 6.35. NMSIG IEEE 802.3 XMT Id nmsig-IEEE-802.3-XMTId ATTRIBUTE WITH ATTRIBUTE SYNTAX PrintableString MATCHES FOR Equality BEHAVIOUR iEEE-802.3-XMTId-behaviour REGISTERED AS {nmsig-attr} iEEE-802.3-XMTId-behaviour BEHAVIOUR DEFINED AS This attribute is the distinguishing attribute of the NMSIG IEEE 802.3 XMT managed object class. 6.36. NMSIG In-Range Threshold nmsig-inRangeThreshold ATTRIBUTE WITH ATTRIBUTE SYNTAX GaugeThreshold MATCHES FOR Equality BEHAVIOUR inRangeTheshold-behaviour REGISTERED AS {nmsig-attr} GaugeThreshold ::= {as defined by ISO Doc X} inRangeTheshold-behaviour BEHAVIOUR DEFINED AS This attribute specifies a threshold which is applied against the in-range length error rate. The in-range length error rate is defined as the number of PDUs received that had in-range length errors divided by the total number of PDUs received. A communication alarm notification with the specified severity is emitted when the in-range length error rate exceeds the threshold value. 6.37. NMSIG Inactivity Timeout nmsig-inactivityTimeout ATTRIBUTE WITH ATTRIBUTE SYNTAX INTEGER MATCHES FOR Equality, Ordering BEHAVIOUR inactivityTimeout-behaviour REGISTERED AS {nmsig-attr} inactivityTimeout-behaviour BEHAVIOUR DEFINED AS This attribute specifies the maximum amount of time (in 1/100ths of a second) that the transport connection can remain up when there is no activity ( i.e. data flow ) on it. A value of 0 for this attribute indicates that an inactivity timeout is not supported on the transport connection. 6.38. NMSIG Incoming Normal Disconnect Counter nmsig-incomingNormalDisconnectCounter ATTRIBUTE WITH ATTRIBUTE SYNTAX Count MATCHES FOR Equality, Ordering BEHAVIOUR incomingNormalDisconnectCounter-behaviour REGISTERED AS {nmsig-attr} Count ::= {as defined in ISO Doc X} incomingNormalDisconnectCounter-behaviour BEHAVIOUR DEFINED AS This attribute specifies the number of incoming transport connections that were disconnected due to normal reasons. 6.39. NMSIG Internal MAC Rcv Error Threshold nmsig-internalMACRcvErrorThreshold ATTRIBUTE WITH ATTRIBUTE SYNTAX GaugeThreshold MATCHES FOR Equality BEHAVIOUR internalMACRcvErrorThreshold REGISTERED AS {nmsig-attr} GaugeThreshold ::= {as defined in ISO Doc X} internalMACRcvErrorThreshold BEHAVIOUR DEFINED AS This attribute specifies a threshold which is applied against the internal MAC receive error rate. This rate is defined as the number of internal MAC receive errors detected per second. A communication alarm notification is emitted when the internal MAC receive error rate exceeds the threshold value. 6.40. NMSIG Internal MAC Rcv Error Counter nmsig-internalMACRcvErrorCounter ATTRIBUTE WITH ATTRIBUTE SYNTAX Count MATCHES FOR Equality, Ordering BEHAVIOUR internalMACRcvErrorCounter REGISTERED AS {nmsig-attr} Count ::= {as defined in ISO Doc X} internalMACRcvErrorCounter BEHAVIOUR DEFINED AS This attribute specifies the number of internal MAC receive errors detected by the underlying NMSIG IEEE 802.3 RCV resource. 6.41. NMSIG Internal MAC Xmt Error Threshold nmsig-internalMACXmtErrorThreshold ATTRIBUTE WITH ATTRIBUTE SYNTAX GaugeThreshold MATCHES FOR Equality BEHAVIOUR internalMACXmtErrorThreshold-behaviour REGISTERED AS {nmsig-attr} GaugeThreshold ::= {as defined in ISO Doc X} internalMACXmtErrorThreshold-behaviour BEHAVIOUR DEFINED AS This attribute specifies a threshold which is applied against the internal MAC transmit error rate. This rate is defined as the number of internal MAC transmit errors detected per second. A communication alarm notification is emitted when the internal MAC transmit error rate exceeds the threshold value. 6.42. NMSIG Late Collision Counter nmsig-lateCollisionsCounter ATTRIBUTE WITH ATTRIBUTE SYNTAX Count MATCHES FOR Equality, Ordering BEHAVIOUR lateCollisionsCounter-behaviour REGISTERED AS {nmsig-attr} Count ::= {as defined in ISO Doc X} lateCollisionsCounter-behaviour BEHAVIOUR DEFINED AS This attribute specifies the number of late collisions detected by the underlying NMSIG IEEE 802.3 XMT resource. 6.43. NMSIG Late Collisions Threshold nmsig-lateCollisionThreshold ATTRIBUTE WITH ATTRIBUTE SYNTAX GaugeThreshold MATCHES FOR Equality BEHAVIOUR lateCollisionThreshold-behaviour REGISTERED AS {nmsig-attr} GaugeThreshold ::= {as defined in ISO Doc X} lateCollisionThreshold-behaviour BEHAVIOUR DEFINED AS This attribute specifies a threshold which is applied against the late collision rate. The late collision rate is defined as the number of late collision PDUs transmitted divided by the total number of PDUs transmitted. A communication alarm notification is emitted when the late collision rate exceeds the threshold value. 6.44. NMSIG Local Network Address nmsig-localNetworkAddress ATTRIBUTE WITH ATTRIBUTE SYNTAX OCTET STRING MATCHES FOR Equality BEHAVIOUR localNetworkAddress-behaviour REGISTERED AS {nmsig-attr} localNetworkAddress-behaviour BEHAVIOUR DEFINED AS This attribute identifies the local network address of the transport connection (e.g., the local IP address for TCP or the local NSAP for OSI TP). 6.45. NMSIG Local Network Addresses nmsig-localNetworkAddresses ATTRIBUTE WITH ATTRIBUTE SYNTAX LocalNetworkAddresses MATCHES FOR Set Comparison, Set Intersection BEHAVIOUR localNetworkAddresses-behaviour REGISTERED AS {nmsig-attr} LocalNetworkAddresses ::= SET OF OCTET STRING localNetworkAddresses-behaviour BEHAVIOUR DEFINED AS This attribute specifies a set of local network addresses supported by a network protocol layer entity. 6.46. NMSIG Local Transport Addresses nmsig-localTransportAddresses ATTRIBUTE WITH ATTRIBUTE SYNTAX TransportAddresses MATCHES FOR Set Comparison, Set Intersection BEHAVIOUR localTransportAddresses-behaviour REGISTERED AS {nmsig-attr} TransportAddresses ::= SET OF SEQUENCE { transportConnectionEndpoint OCTET STRING, networkAddress OCTET STRING} localTransportAddresses-behaviour BEHAVIOUR DEFINED AS This attribute specifies the set of transport addresses that a connection oriented transport protocol layer entity provides to its users. A transport address consists of a transport connection endpoint and a network address. 6.47. NMSIG Local Transport Connection Endpoint nmsig-localTransportConnectionEndpoint ATTRIBUTE WITH ATTRIBUTE SYNTAX OCTET STRING MATCHES FOR Equality BEHAVIOUR localTransportConnectionEndpoint-behaviour REGISTERED AS {nmsig-attr} localTransportConnectionEndpoint-behaviour BEHAVIOUR DEFINED AS This attribute identifies the local transport connection endpoint (e.g., it represents the source port for TCP or the local t-selector for OSI TP). 6.48. NMSIG Location Name nmsig-locationName ATTRIBUTE WITH ATTRIBUTE SYNTAX AnyName MATCHES FOR Equality BEHAVIOUR locationName-behaviour REGISTERED AS {nmsig-attr} AnyName ::= CHOICE {dn DistinguishedName, ps PrintableString} locationName-behaviour BEHAVIOUR DEFINED AS This attribute specifies the name of a location (e.g., Hilo Hawaii USA). 6.49. NMSIG MAC Address nmsig-macAddress ATTRIBUTE WITH ATTRIBUTE SYNTAX OctetString MATCHES FOR Equality BEHAVIOUR macAddress-behaviour REGISTERED AS {nmsig-attr} macAddress-behaviour BEHAVIOUR DEFINED AS This attribute specifies a MAC address. 6.50. NMSIG MAC Port Id nmsig-MAC-PortId ATTRIBUTE WITH ATTRIBUTE SYNTAX PrintableString MATCHES FOR Equality BEHAVIOUR mAC-PortID-behaviour REGISTERED AS {nmsig-attr} mAC-PortID-behaviour BEHAVIOUR DEFINED AS This attribute is the distinguishing attribute of the NMSIG MAC Port managed object class. 6.51. NMSIG MAC Port In Non-Unicast Packets Counter nmsig-MAC-PortInNonUCastPktsCounter ATTRIBUTE WITH ATTRIBUTE SYNTAX Count MATCHES FOR Equality, Ordering BEHAVIOUR mAC-PortInNonUCastPktsCounter-behaviour REGISTERED AS {nmsig-attr} Count ::= {as defined in ISO Doc X} mAC-PortInNonUCastPktsCounter-behaviour BEHAVIOUR DEFINED AS This attribute specifies the number of non-unicast (i.e., subnet broadcast or subnet multicast) packets that were received at the MAC port. 6.52. NMSIG MAC Port In Octet Rate nmsig-MAC-PortInOctetRate ATTRIBUTE WITH ATTRIBUTE SYNTAX Gauge MATCHES FOR Equality, Ordering BEHAVIOUR mAC-PortInOctetRate REGISTERED AS {nmsig-attr} Gauge ::= {as defined in ISO doc X} mAC-PortInOctetRate BEHAVIOUR DEFINED AS This attribute specifies the rate of octets arriving at the MAC port per second. 6.53. NMSIG MAC Port In Octet Rate Threshold nmsig-MAC-PortInOctetRateThreshold ATTRIBUTE WITH ATTRIBUTE SYNTAX GaugeThreshold MATCHES FOR Equality BEHAVIOUR mAC-PortInOctetRateThreshold REGISTERED AS {nmsig-attr} GaugeThreshold ::= {as defined in ISO Doc X} mAC-PortInOctetRateThreshold BEHAVIOUR DEFINED AS This attribute specifies a threshold which is applied against the in octet rate. A communication alarm notification is emitted when the in octet rate exceeds the threshold value. 6.54. NMSIG MAC Port In Unicast Packets Counter nmsig-MAC-PortInUCastPktsCounter ATTRIBUTE WITH ATTRIBUTE SYNTAX Count MATCHES FOR Equality, Ordering BEHAVIOUR mAC-PortInUCastPktsCounter REGISTERED AS {nmsig-attr} Count ::= {as defined in ISO Doc X} mAC-PortInUCastPktsCounter BEHAVIOUR DEFINED AS This attribute specifies the number of unicast packets received on the MAC port. 6.55. NMSIG MAC Port Out Delay Discarded Packets Counter nmsig-MAC-PortOutDelayDiscPktsCounter ATTRIBUTE WITH ATTRIBUTE SYNTAX Count MATCHES FOR Equality, Ordering BEHAVIOUR mAC-PortOutDelayDiscPktsCounter REGISTERED AS {nmsig-attr} Count ::= {as defined in ISO Doc X} mAC-PortOutDelayDiscPktsCounter BEHAVIOUR DEFINED AS This attribute specifies the number of packets that were discarded at the MAC port because the maximum packet hold time was exceeded. 6.56. NMSIG MAC Port Out Non-Unicast Packets nmsig-MAC-PortOutNonUCastPktsCounter ATTRIBUTE WITH ATTRIBUTE SYNTAX Count MATCHES FOR Equality, Ordering BEHAVIOUR mAC-PortOutNonUCastPktsCounter REGISTERED AS {nmsig-attr} Count ::= {as defined in ISO Doc X} mAC-PortOutNonUCastPktsCounter BEHAVIOUR DEFINED AS This attribute specifies the number of non-unicast packets that were sent out of the MAC port. 6.57. NMSIG MAC Port Out Queue Length nmsig-MAC-PortOutQLen ATTRIBUTE WITH ATTRIBUTE SYNTAX INTEGER MATCHES FOR Equality, Ordering BEHAVIOUR mAC-PortOutQLen REGISTERED AS {nmsig-attr} mAC-PortOutQLen BEHAVIOUR DEFINED AS This attribute specifies the number of packets that are currently queued for output on the MAC port. 6.58. NMSIG MAC Port Out Unicast Packets Counter nmsig-MAC-PortOutUCastPktsCounter ATTRIBUTE WITH ATTRIBUTE SYNTAX Count MATCHES FOR Equality, Ordering BEHAVIOUR mAC-PortOutUCastPktsCounter REGISTERED AS {nmsig-attr} Count ::= {as defined in ISO Doc X} mAC-PortOutUCastPktsCounter BEHAVIOUR DEFINED AS This attribute specifies the number of unicast packets that were sent out of this MAC port. 6.59. NMSIG Max Connections nmsig-maxConnections ATTRIBUTE WITH ATTRIBUTE SYNTAX INTEGER MATCHES FOR Equality, Ordering BEHAVIOUR maxConnections-behaviour REGISTERED AS {nmsig-attr} maxConnections-behaviour BEHAVIOUR DEFINED AS This attribute specifies the maximum number of simultaneously open transport connections allowed by the transport protocol layer entity. 6.60. NMSIG Max Retransmissions nmsig-maxRetransmissions ATTRIBUTE WITH ATTRIBUTE SYNTAX INTEGER MATCHES FOR Equality, Ordering BEHAVIOUR maxRetransmissions-behaviour REGISTERED AS {nmsig-attr} maxRetransmissions-behaviour BEHAVIOUR DEFINED AS This attribute specifies the maximum number of times a TPDU is to be retransmitted before the transport connection is aborted. 6.61. NMSIG Max TPDU Size nmsig-maxTPDUSize ATTRIBUTE WITH ATTRIBUTE SYNTAX INTEGER MATCHES FOR Equality, Ordering BEHAVIOUR maxTPDUSize-behaviour REGISTERED AS {nmsig-attr} maxTPDUSize-behaviour BEHAVIOUR DEFINED AS This attribute specifies the maximum TPDU size (in terms of octets) that can be handled by the local transport protocol layer entity. 6.62. NMSIG Memory Size nmsig-memorySize ATTRIBUTE WITH ATTRIBUTE SYNTAX INTEGER MATCHES FOR Equality, Ordering BEHAVIOUR memorySize-behaviour REGISTERED AS {nmsig-attr} memorySize-behaviour BEHAVIOUR DEFINED AS This attribute specifies the amount of random access memory (in kilobytes) that is owned by a processing entity. (1 Kilobyte = 1024 bytes.) 6.63. NMSIG Multicast Address List nmsig-multicastAddressList ATTRIBUTE WITH ATTRIBUTE SYNTAX AddressList MATCHES FOR Set Comparison, Set Intersection BEHAVIOUR multicastAddressList-behaviour REGISTERED AS {nmsig-attr} AddressList ::= SET OF OCTET STRING multicastAddressList-behaviour BEHAVIOUR DEFINED AS This attribute specifies a multicast address list. 6.64. NMSIG Multicast Forwarding State nmsig-multicastForwardingState ATTRIBUTE WITH ATTRIBUTE SYNTAX State MATCHES FOR Equality, Ordering BEHAVIOUR multicastForwardingState-behaviour REGISTERED AS {nmsig-attr} State ::= ENUMERATED {off (0), on (1)} multicastForwardingState-behaviour BEHAVIOUR DEFINED AS This attribute specifies whether multicast PDUs are being forwarded. 6.65. NMSIG Multicast PDUs Rcv Counter nmsig-multicastPDUsRcvCounter ATTRIBUTE WITH ATTRIBUTE SYNTAX Count MATCHES FOR Equality, Ordering BEHAVIOUR multicastPDUsRcvCounter-behaviour REGISTERED AS {nmsig-attr} Count ::= {as defined in ISO Doc X} multicastPDUsRcvCounter-behaviour BEHAVIOUR DEFINED AS This attribute specifies the number of multicast PDUs received ok by the underlying NMSIG IEEE 802.3 RCV resource. 6.66. NMSIG Multicast PDUs Xmt Counter nmsig-multicastPDUsXmtCounter ATTRIBUTE WITH ATTRIBUTE SYNTAX Count MATCHES FOR Equality, Ordering BEHAVIOUR multicastPDUsXmtCounter-behaviour REGISTERED AS {nmsig-attr} Count ::= {as defined in ISO Doc X} multicastPDUsXmtCounter-behaviour BEHAVIOUR DEFINED AS This attribute specifies the number of multicast PDUs which were transmitted ok by the underlying NMSIG IEEE 802.3 XMT resource. 6.67. NMSIG Multicast Receive State nmsig-multicastReceiveState ATTRIBUTE WITH ATTRIBUTE SYNTAX State MATCHES FOR Equality, Ordering BEHAVIOUR multicastReceiveState-behaviour REGISTERED AS {nmsig-attr} State ::= ENUMERATED {off (0), on (1)} multicastReceiveState-behaviour BEHAVIOUR DEFINED AS This attribute specifies the multicast receive state of the underlying NMSIG IEEE 802.3 RCV resource. 6.68. NMSIG Multiple Collision PDU Counter nmsig-multipleCollisionPDUCounter ATTRIBUTE WITH ATTRIBUTE SYNTAX Count MATCHES FOR Equality, Ordering BEHAVIOUR multipleCollisionPDUCounter REGISTERED AS {nmsig-attr} Count ::= {as defined in ISO Doc X} multipleCollisionPDUCounter BEHAVIOUR DEFINED AS This attribute specifies the number of multiple collision PDUs detected by the underlying NMSIG IEEE 802.3 XMT resource. 6.69. NMSIG Network Entity Type nmsig-networkEntityType ATTRIBUTE WITH ATTRIBUTE SYNTAX NetworkEntityType MATCHES FOR Equality BEHAVIOUR networkEntityType-behaviour REGISTERED AS {nmsig-attr} NetworkEntityType ::= INTEGER {other(0), oSI CLNP (1), internet IP (2)} (0..256) networkEntityType-behaviour BEHAVIOUR DEFINED AS This attribute specifies the type of the network protocol layer entity. 6.70. NMSIG Network Id nmsig-networkId ATTRIBUTE WITH ATTRIBUTE SYNTAX PrintableString MATCHES FOR Equality BEHAVIOUR networkId-behaviour REGISTERED AS {nmsig-attr} networkId-behaviour BEHAVIOUR DEFINED AS This is the distinguishing attribute of the NMSIG network managed object class. 6.71. NMSIG Network Purpose nmsig-networkPurpose ATTRIBUTE WITH ATTRIBUTE SYNTAX PrintableString MATCHES FOR Equality BEHAVIOUR networkPurpose-behaviour REGISTERED AS {nmsig-attr} networkPurpose-behaviour BEHAVIOUR DEFINED AS This attribute specifies what the network is used for (e.g., manufacturing control, airline reservation, etc.) 6.72. NMSIG NPDU Time To Live nmsig-nPDUTimeToLive ATTRIBUTE WITH ATTRIBUTE SYNTAX INTEGER MATCHES FOR Equality, Ordering BEHAVIOUR nPDUTimeToLive-behaviour REGISTERED AS {nmsig-attr} nPDUTimeToLive-behaviour BEHAVIOUR DEFINED AS This attribute specifies the maximum amount of time (in units of 10 ms) that an NPDU can exist in the network. This attribute is used to limit the lifetime of NPDUs during unstable network situations. 6.73. NMSIG Octets Retransmitted Error Counter nmsig-octetsRetransmittedErrorCounter ATTRIBUTE WITH ATTRIBUTE SYNTAX Count MATCHES FOR Equality, Ordering BEHAVIOUR octetsRetransmitterErrorCounter-behaviour REGISTERED AS {nmsig-attr} Count ::= {as defined in ISO Doc X} octetsRetransmitterErrorCounter-behaviour BEHAVIOUR DEFINED AS This attribute specifies the total number of octets that were retransmitted. 6.74. NMSIG OS Info nmsig-osInfo ATTRIBUTE WITH ATTRIBUTE SYNTAX OsInfo MATCHES FOR Set Comparison, Set Intersection BEHAVIOUR osInfo-behaviour REGISTERED AS {nmsig-attr} OsInfo ::= SET OF (CHOICE {osName [0] DistingishedName, osSpec [1] ProductInfo}) ProductInfo ::= SEQUENCE {manufacturer PrintableString, productLabel PrintableString, release PrintableString, serialNumber PrintableString} osInfo-behaviour BEHAVIOUR DEFINED AS This attribute specifies the names and releases of operating systems supported by the processing entity 6.75. NMSIG Open Connections nmsig-openConnections ATTRIBUTE WITH ATTRIBUTE SYNTAX INTEGER MATCHES FOR Equality, Ordering BEHAVIOUR openConnections-behaviour REGISTERED AS {nmsig-attr} openConnections-behaviour BEHAVIOUR DEFINED AS This attribute specifies the number of currently established transport connections. 6.76. NMSIG Out-Range Threshold nmsig-outRangeThreshold ATTRIBUTE WITH ATTRIBUTE SYNTAX GaugeThreshold MATCHES FOR Equality BEHAVIOUR outRangeThreshold-behaviour REGISTERED AS {nmsig-attr} GaugeThreshold ::= {as defined in ISO Doc X} outRangeThreshold-behaviour BEHAVIOUR DEFINED AS This attribute specifies a threshold which is applied against the out-range length error rate. This rate is defined as the number of PDUs received with out-range length errors divided by the total number of PDUs received. A communication alarm notification is emitted when the out-range length error rate exceeds the threshold value. 6.77. NMSIG Outgoing Normal Disconnect Counter nmsig-outgoingNormalDisconnectCounter ATTRIBUTE WITH ATTRIBUTE SYNTAX Count MATCHES FOR Equality, Ordering BEHAVIOUR outgoingNormalDisconnectCounter-behaviour REGISTERED AS {nmsig-attr} Count ::= {as defined in ISO Doc X} outgoingNormalDisconnectCounter-behaviour BEHAVIOUR DEFINED AS This attribute specifies the number of outgoing transport connections that were disconnected due to normal reasons. 6.78. NMSIG Packet Loss Rate nmsig-packetLossRate ATTRIBUTE WITH ATTRIBUTE SYNTAX Gauge MATCHES FOR Equality, Ordering BEHAVIOUR packetLossRate-behaviour REGISTERED AS {nmsig-attr} Gauge ::= {as defined in ISO Doc X} packetLossRate-behaviour BEHAVIOUR DEFINED AS This attribute specifies the rate of packets dropped per second. 6.79. NMSIG Packet Loss Rate Threshold nmsig-packetLossRateThreshold ATTRIBUTE WITH ATTRIBUTE SYNTAX GaugeThreshold MATCHES FOR Equality BEHAVIOUR packetLossRateThreshold REGISTERED AS {nmsig-attr} GaugeThreshold ::= {as defined in ISO Doc X} packetLossRateThreshold BEHAVIOUR DEFINED AS This attribute specifies a threshold which is applied against the packet loss rate. A communication alarm notification is emitted when the packet loss rate exceeds the threshold value. 6.80. NMSIG PDU Too Long Threshold nmsig-PDUTooLongThreshold ATTRIBUTE WITH ATTRIBUTE SYNTAX GaugeThreshold MATCHES FOR Equality BEHAVIOUR pDUTooLongThreshold-behaviour REGISTERED AS {nmsig-attr} GaugeThreshold ::= {as defined by ISO Doc X} pDUTooLongThreshold-behaviour BEHAVIOUR DEFINED AS This attribute specifies a threshold which is applied against the "PDU too long" error rate. The PDU too long error rate is defined as the number of PDUs received that were too long divided by the total number of PDUs received. A communication alarm notification is emitted when the "PDU too long" error rate exceeds the threshold value. 6.81. NMSIG PDUs Aborted Excessive Collisions Counter nmsig-PDUsAbortedExcessiveCollisionsCounter ATTRIBUTE WITH ATTRIBUTE SYNTAX Count MATCHES FOR Equality, Ordering BEHAVIOUR pDUsAbortedExcessiveCollisionsCounter-behaviour REGISTERED AS {nmsig-attr} Count ::= {as defined in ISO Doc X} pDUsAbortedExcessiveCollisionsCounter-behaviour BEHAVIOUR DEFINED AS This attribute specifies the number of PDUs which were aborted by the underlying NMSIG IEEE 802.3 XMT resource due to excessive collisions. 6.82. NMSIG PDUs Aborted Excessive Collisions Threshold nmsig-PDUsAbortedExcessColThreshold ATTRIBUTE WITH ATTRIBUTE SYNTAX GaugeThreshold MATCHES FOR Equality BEHAVIOUR pDUsAbortedExcessColThreshold-behaviour REGISTERED AS {nmsig-attr} GaugeThreshold ::= {as defined in ISO Doc X} pDUsAbortedExcessColThreshold-behaviour BEHAVIOUR DEFINED AS This attribute specifies a threshold which is applied against the PDUs aborted due to excessive collision rate. This rate is defined as the number of PDUs aborted due to excessive collision divided by the total number of PDUs transmitted. A communication alarm notification is emitted when the PDUs aborted due to excessive collision rate exceeds the threshold value. 6.83. NMSIG PDUs Alignment Error Counter nmsig-PDUsAlignmentErrorCounter ATTRIBUTE WITH ATTRIBUTE SYNTAX Count MATCHES FOR Equality, Ordering BEHAVIOUR pDUsAlignmentErrorCounter-behaviour REGISTERED AS {nmsig-attr} Count ::= {as defined in ISO Doc X} pDUsAlignmentErrorCounter-behaviour BEHAVIOUR DEFINED AS This attribute specifies the number of PDUs with an alignment error detected by the underlying NMSIG IEEE 802.3 RCV resource. 6.84. NMSIG PDUs Excessive Deferral Counter nmsig-PDUsExcessiveDeferralCounter ATTRIBUTE WITH ATTRIBUTE SYNTAX Count MATCHES FOR Equality, Ordering BEHAVIOUR pDUsExcessiveDeferralCounter-behaviour REGISTERED AS {nmsig-attr} Count ::= {as defined in ISO Doc X} pDUsExcessiveDeferralCounter-behaviour BEHAVIOUR DEFINED AS This attribute specifies the number of PDUs for which the underlying NMSIG IEEE 802.3 XMT resource detected excessive deferral. 6.85. NMSIG PDUs Discarded Counter nmsig-PDUsDiscardedCounter ATTRIBUTE WITH ATTRIBUTE SYNTAX Count MATCHES FOR Equality, Ordering BEHAVIOUR pDUsDiscardedCounter-behaviour REGISTERED AS {nmsig-attr} Count ::= {as defined in ISO Doc X} pDUsDiscardedCounter-behaviour BEHAVIOUR DEFINED AS This attribute specifies the number of PDUs that were discarded by a network protocol layer entity. 6.86. NMSIG PDUs FCS Error Counter nmsig-PDUsFCSErrorCounter ATTRIBUTE WITH ATTRIBUTE SYNTAX Count MATCHES FOR Equality, Ordering BEHAVIOUR pDUsFCSErrorCounter-behaviour REGISTERED AS {nmsig-attr} Count ::= {as defined in ISO Doc X} pDUsFCSErrorCounter-behaviour BEHAVIOUR DEFINED AS This attribute specifies the number of PDUs with an FCS error detected by the underlying NMSIG IEEE 802.3 RCV resource. 6.87. NMSIG PDUs Forwarded Counter nmsig-PDUsForwardedCounter ATTRIBUTE WITH ATTRIBUTE SYNTAX Count MATCHES FOR Equality, Ordering BEHAVIOUR pDUsForwardedCounter-behaviour REGISTERED AS {nmsig-attr} Count ::= {as defined in ISO Doc X} pDUsForwardedCounter-behaviour BEHAVIOUR DEFINED AS This attribute specifies the number of PDUs forwarded by a network protocol layer entity. 6.88. NMSIG PDUs In-Range Length Error Counter nmsig-PDUsInRangeLengthErrorCounter ATTRIBUTE WITH ATTRIBUTE SYNTAX Count MATCHES FOR Equality, Ordering BEHAVIOUR pDUsInRangeLengthErrorCounter-behaviour REGISTERED AS {nmsig-attr} Count ::= {as defined in ISO Doc X} pDUsInRangeLengthErrorCounter-behaviour BEHAVIOUR DEFINED AS This attribute specifies the number of PDUs with an in-range length error detected by the underlying NMSIG IEEE 802.3 RCV resource. 6.89. NMSIG PDUs Lost Internal MAC Xmt Error Counter nmsig-PDUsLostInternalMACXmtErrorCounter ATTRIBUTE WITH ATTRIBUTE SYNTAX Count MATCHES FOR Equality, Ordering BEHAVIOUR pDUsLostInternalMACXmtErrorCounter-behaviour REGISTERED AS {nmsig-attr} Count ::= {as defined in ISO Doc X} pDUsLostInternalMACXmtErrorCounter-behaviour BEHAVIOUR DEFINED AS This attribute specifies the number of PDUs which were lost by the underlying NMSIG IEEE 802.3 XMT resource due to an internal MAC transmit error. 6.90. NMSIG PDUs Out-Range Error Counter nmsig-PDUsOutRangeLengthErrorCounter ATTRIBUTE WITH ATTRIBUTE SYNTAX Count MATCHES FOR Equality, Ordering BEHAVIOUR pDUsOutRangeLengthErrorCounter-behaviour REGISTERED AS {nmsig-attr} Count ::= {as defined in ISO Doc X} pDUsOutRangeLengthErrorCounter-behaviour BEHAVIOUR DEFINED AS This attribute specifies the number of PDUs with an out-range length error detected by the underlying NMSIG IEEE 802.3 RCV resource. 6.91. NMSIG PDUs Reassemble Fail Counter nmsig-PDUsReasmblFailCounter ATTRIBUTE WITH ATTRIBUTE SYNTAX Count MATCHES FOR Equality, Ordering BEHAVIOUR pDUsReasmblFailCounter-behaviour REGISTERED AS {nmsig-attr} Count ::= {as defined in ISO Doc X} pDUsReasmblFailCounter-behaviour BEHAVIOUR DEFINED AS This attribute specifies the number of PDUs that could not be reassembled successfully by a network protocol layer entity. 6.92. NMSIG PDUs Reassembled OK Counter nmsig-PDUsReasmbldOKCounter ATTRIBUTE WITH ATTRIBUTE SYNTAX Count MATCHES FOR Equality, Ordering BEHAVIOUR pDUsReasmbldOKCounter-behaviour REGISTERED AS {nmsig-attr} Count ::= {as defined in ISO Doc X} pDUsReasmbldOKCounter-behaviour BEHAVIOUR DEFINED AS This attribute specifies the number of PDUs that were reassembled successfully by a network protocol layer entity. 6.93. NMSIG PDUs Too Long Error Counter nmsig-PDUsTooLongErrorCounter ATTRIBUTE WITH ATTRIBUTE SYNTAX Count MATCHES FOR Equality, Ordering BEHAVIOUR pDUsTooLongErrorCounter-behaviour REGISTERED AS {nmsig-attr} Count ::= {as defined in ISO Doc X} pDUsTooLongErrorCounter-behaviour BEHAVIOUR DEFINED AS This attribute specifies the number of PDUs with a "PDU too long" error detected by the underlying NMSIG IEEE 802.3 RCV resource. 6.94. NMSIG Peripheral Names nmsig-peripheralNames ATTRIBUTE WITH ATTRIBUTE SYNTAX PeripheralNames MATCHES FOR Set Comparison, Set Intersection BEHAVIOUR peripheralNames-behaviour REGISTERED AS {nmsig-attr} PeripheralNames ::= SET OF AnyName AnyName ::= CHOICE {dn DistinguishedName, ps PrintableString} peripheralNames-behaviour BEHAVIOUR DEFINED AS This attribute specifies the names of auxiliary devices. 6.95. NMSIG Product Info nmsig-productInfo ATTRIBUTE WITH ATTRIBUTE SYNTAX ProductInfo MATCHES FOR Equality BEHAVIOUR productInfo-behaviour REGISTERED AS {nmsig-attr} ProductInfo ::= SEQUENCE {manufacturer PrintableString, productLabel PrintableString, release PrintableString, serialNumber PrintableString} productInfo-behaviour BEHAVIOUR DEFINED AS This attribute specifies product information of the underlying resource. 6.96. NMSIG Promiscuous Receive State nmsig-promiscuousReceiveState ATTRIBUTE WITH ATTRIBUTE SYNTAX State MATCHES FOR Equality, Ordering BEHAVIOUR promiscuousReceiveState-behaviour REGISTERED AS {nmsig-attr} State ::= ENUMERATED {off (0), on (1)} promiscuousReceiveState-behaviour BEHAVIOUR DEFINED AS This attribute specifies the promiscuous receive state of the underlying NMSIG IEEE 802.3 RCV resource. 6.97. NMSIG Remote Network Address nmsig-remoteNetworkAddress ATTRIBUTE WITH ATTRIBUTE SYNTAX OCTET STRING MATCHES FOR Equality BEHAVIOUR remoteNetworkAddress-behaviour REGISTERED AS {nmsig-attr} remoteNetworkAddress-behaviour BEHAVIOUR DEFINED AS This attribute identifies the remote network address of the transport connection (e.g., it represents the remote IP address for TCP or the remote NSAP for OSI TP). 6.98. NMSIG Remote Transport Connection Endpoint nmsig-remoteTransportConnectionEndpoint ATTRIBUTE WITH ATTRIBUTE SYNTAX OCTET STRING MATCHES FOR Equality BEHAVIOUR remoteTransportConnectionEndpoint-behaviour REGISTERED AS {nmsig-attr} remoteTransportConnectionEndpoint-behaviour BEHAVIOUR DEFINED AS This attribute identifies the remote transport connection endpoint ( It represents the destination port for TCP or the remote t-selector for OSI TP). 6.99. NMSIG Retransmission Timer Initial Value nmsig-retransmissionTimerInitialValue ATTRIBUTE WITH ATTRIBUTE SYNTAX INTEGER MATCHES FOR Equality, Ordering BEHAVIOUR retransmissionTimerInitialValue-behaviour REGISTERED AS {nmsig-attr} retransmissionTimerInitialValue-behaviour BEHAVIOUR DEFINED AS This attribute specifies the initial value (in 1/100ths of a second) of the retransmission timer used by a transport connection. 6.100. NMSIG Single Collision PDUs Counter nmsig-singleCollisionPDUsCounter ATTRIBUTE WITH ATTRIBUTE SYNTAX Count MATCHES FOR Equality, Ordering BEHAVIOUR singleCollisionPDUsCounter-behaviour REGISTERED AS {nmsig-attr} Count ::= {as defined in ISO Doc X} singleCollisionPDUsCounter-behaviour BEHAVIOUR DEFINED AS This attribute specifies the number of single collision PDUs detected by the underlying NMSIG IEEE 802.3 XMT resource. 6.101. NMSIG Source Address Last Alignment Error PDU nmsig-sourceAddrLastAlignmentErrorPDU ATTRIBUTE WITH ATTRIBUTE SYNTAX OCTET STRING MATCHES FOR Equality BEHAVIOUR sourceAddrLastAlignmentErrorPDU-behaviour REGISTERED AS {nmsig-attr} sourceAddrLastAlignmentErrorPDU-behaviour BEHAVIOUR DEFINED AS This attribute specifies the source address of the last alignment error PDU detected by the underlying NMSIG IEEE 802.3 RCV resource. 6.102. NMSIG Source Address Last FCS Error PDU nmsig-sourceAddrLastFCSErrorPDU ATTRIBUTE WITH ATTRIBUTE SYNTAX OCTET STRING MATCHES FOR Equality BEHAVIOUR sourceAddrLastFCSErrorPDU-behaviour REGISTERED AS {nmsig-attr} sourceAddrLastFCSErrorPDU-behaviour BEHAVIOUR DEFINED AS This attribute specifies the source address of the last FCS error PDU detected by the underlying NMSIG IEEE 802.3 RCV resource. 6.103. NMSIG Source Address Last In-Range Length Error PDU nmsig-sourceAddrLastInRangeLengthErrorPDU ATTRIBUTE WITH ATTRIBUTE SYNTAX OCTET STRING MATCHES FOR Equality BEHAVIOUR sourceAddrLastInRangeLengthErrorPDU-behaviour REGISTERED AS {nmsig-attr} sourceAddrLastInRangeLengthErrorPDU-behaviour BEHAVIOUR DEFINED AS This attribute specifies the source address of the last in-range length error PDU detected by the underlying NMSIG IEEE 802.3 RCV resource. 6.104. NMSIG Source Address Last Out-Range Length Error PDU nmsig-sourceAddrLastOutRangeLengthErrorPDU ATTRIBUTE WITH ATTRIBUTE SYNTAX OCTET STRING MATCHES FOR Equality BEHAVIOUR sourceAddrLastOutRangeLengthErrorPDU-behaviour REGISTERED AS {nmsig-attr} sourceAddrLastOutRangeLengthErrorPDU-behaviour BEHAVIOUR DEFINED AS This attribute specifies the source address of the last out-range length error PDU detected by the underlying NMSIG IEEE 802.3 RCV resource. 6.105. NMSIG Source Address Last Too Long Error PDU nmsig-sourceAddrLastTooLongErrorPDU ATTRIBUTE WITH ATTRIBUTE SYNTAX OCTET STRING MATCHES FOR Equality BEHAVIOUR sourceAddrLastTooLongErrorPDU REGISTERED AS {nmsig-attr} sourceAddrLastOutRangeLengthErrorPDU-behaviour BEHAVIOUR DEFINED AS This attribute specifies the source address of the last "PDU too long" error PDU detected by the underlying NMSIG IEEE 802.3 RCV resource. 6.106. NMSIG System Id nmsig-systemId ATTRIBUTE WITH ATTRIBUTE SYNTAX PrintableString MATCHES FOR Equality BEHAVIOUR systemId-behaviour REGISTERED AS {nmsig-attr} systemId-behaviour BEHAVIOUR DEFINED AS This is the distinguishing attribute of the NMSIG computer system managed object class. 6.107. NMSIG System Time nmsig-systemTime ATTRIBUTE WITH ATTRIBUTE SYNTAX GeneralizedTime MATCHES FOR Equality, Ordering BEHAVIOUR systemTime-behaviour REGISTERED AS {nmsig-attr} systemTime-behaviour BEHAVIOUR DEFINED AS This attribute specifies the current time clocked at the computer system. 6.108. NMSIG Transport Connection Id nmsig-transportConnectionId ATTRIBUTE WITH ATTRIBUTE SYNTAX PrintableString MATCHES FOR Equality BEHAVIOUR transportConnectionId-behaviour REGISTERED AS {nmsig-attr} transportConnectionId-behaviour BEHAVIOUR DEFINED AS This attribute is the distinguishing attribute for the managed object class transportConnection. 6.109. NMSIG Transport Connection Profile Id nmsig-transportConnectionProfileId ATTRIBUTE WITH ATTRIBUTE SYNTAX PrintableString MATCHES FOR Equality BEHAVIOUR transportConnectionProfileId-behaviour REGISTERED AS {nmsig-attr} transportConnectionProfileId-behaviour BEHAVIOUR DEFINED AS This attribute is the distinguishing attribute for the managed object class nmsig-transportConnectionProfile. 6.110. NMSIG Transport Connection Reference nmsig-transportConnectionReference ATTRIBUTE WITH ATTRIBUTE SYNTAX OCTET STRING MATCHES FOR Equality BEHAVIOUR transportConnectionReference-behaviour REGISTERED AS {nmsig-attr} transportConnectionReference-behaviour BEHAVIOUR DEFINED AS This attribute identifies the local transport connection reference that is established by the two transport connection endpoints (e.g., the local socket number for TCP or the local connection reference for OSI). 6.111. NMSIG Transport Entity Type nmsig-transportEntityType ATTRIBUTE WITH ATTRIBUTE SYNTAX TransportEntityType MATCHES FOR Equality BEHAVIOUR transportEntityType-behaviour REGISTERED AS {nmsig-attr} TransportEntityType ::= INTEGER {other(0), oSI TP (1), tCP (2), sNA (3)} (0..256) transportEntityType-behaviour BEHAVIOUR DEFINED AS This attribute specifies the type of the transport protocol layer entity. 6.112. NMSIG User Friendly Label nmsig-userFriendlyLabel ATTRIBUTE WITH ATTRIBUTE SYNTAX PrintableString MATCHES FOR Equality BEHAVIOUR userFriendlyLabel-behaviour REGISTERED AS {nmsig-attr} userFriendlyLabel-behaviour BEHAVIOUR DEFINED AS This attribute specifies a user friendly name. 6.113. NMSIG Vendor Name nmsig-vendorName ATTRIBUTE WITH ATTRIBUTE SYNTAX AnyName MATCHES FOR Equality BEHAVIOUR vendorName-behaviour REGISTERED AS {nmsig-attr} AnyName ::= CHOICE {dn DistinguishedName, ps PrintableString} vendorName-behaviour BEHAVIOUR DEFINED AS This attribute specifies the name of a vendor. 6.114. NMSIG Xmt State nmsig-XmtState ATTRIBUTE WITH ATTRIBUTE SYNTAX EnableState MATCHES FOR Equality, Ordering BEHAVIOUR xmtState-behaviour REGISTERED AS {nmsig-attr} EnableState ::= ENUMERATED {disable (0), enable (1)} xmtState-behaviour BEHAVIOUR DEFINED AS This attribute specifies whether the transmitting capability of the unserlying IEEE 802.3 resource is enabled or not. The 'enabled' and 'disabled' values of this attribute correspond to the 'enabled' and 'disabled' values of the OperationalState attribute of the IEEE 802.3 XMT managed object class. (This attribute was introduced as a GET-REPLACE attribute which can be used by management to enable or disable the transmitting capability of the underlying IEEE 802.3 resource.) 6.115. Object Class Refer to [ISO Doc x] for the definition of this attribute. 6.116. Octets Received Counter Refer to [ISO Doc X] for the definition of this attribute. 6.117. Octets Sent Counter Refer to [ISO Doc X] for the definition of this attribute. 6.118. Operational State Refer to [ISO Doc x] for the definition of this attribute. 6.119. Outgoing Connection Reject Error Counter Refer to [ISO Doc X] for the definition of this attribute. 6.120. Outgoing Connections Request Counter Refer to [ISO Doc X] for the definition of this attribute. 6.121. Outgoing Disconnect Error Counter Refer to [ISO Doc X] for the definition of this attribute. 6.122. Outgoing Temporal Error Counter Refer to [ISO Doc X] for the definition of this attribute. 6.123. PDUs Received Counter Refer to [ISO Doc X] for the definition of this attribute. 6.124. PDUs Sent Counter Refer to [ISO Doc X] for the definition of this attribute. 6.125. PDUs Retransmitted Error Counter Refer to [ISO Doc X] for the definition of this attribute. 7. ACTIONS This section provides definitions of actions supported by managed object classes defined by the OSI MIB Working Group. Action definitions for managed object classes defined by other groups can be found in the document referenced under the managed object class definition in section 3. 7.1. NMSIG Execute Self Test nmsig-executeSelfTest ACTION ACTION BEHAVIOUR selfTestBehaviour WITH RESULT SYNTAX SelfTestResult REGISTERED AS {nmsig-action} selfTestBehaviour BEHAVIOUR DEFINED AS This action requests a self test sequence be executed on the referenced managed object instance. This action is always confirmed. The confirmation contains the operational state of the managed object under test following test completion, and optionally indicates the success or failure of the self test. SelfTestResult ::= SEQUENCE { operationalState OperationalState, testResult BOOLEAN OPTIONAL } 8. NOTIFICATIONS This section provides definitions of notifications emitted by managed object classes defined by the OSI MIB Working Group. Notification definitions for managed object classes defined by other groups can be found in the document referenced under the managed object class definition in section 3. 8.1. Attribute Change Unconfirmed Refer to [ISO Doc x] for the definition of this notification. 8.2. Communication Alarm Unconfirmed Refer to [ISO Doc x] for the definition of this notification. 8.3. Equipment Alarm Unconfirmed Refer to [ISO Doc x] for the definition of this notification. 8.4. Environmental Alarm Unconfirmed Refer to [ISO Doc x] for the definition of this notification. 8.5. NMSIG Counter Wrap Unconfirmed nmsig-counterWrapUnconfirmed NOTIFICATION BEHAVIOUR counterWrap-behaviour WITH DATA SYNTAX WrapInfo REGISTERED AS {notification} counterWrap-behaviour BEHAVIOUR DEFINED AS This notification indicates that a counter has wrapped. WrapInfo ::= Attribute { -- attribute ID and value of counter attribute that wrapped } 8.6. Object Creation Unconfirmed Refer to [ISO Doc x] for the definition of this notification. 8.7. Object Deletion Unconfirmed Refer to [ISO Doc x] for the definition of this notification. 8.8. Processing Error Alarm Unconfirmed Refer to [ISO Doc x] for the definition of this notification. 8.9. Relationship Change Unconfirmed Refer to [ISO Doc x] for the definition of this notification. 8.10. State Change Unconfirmed Refer to [ISO Doc x] for the definition of this notification. 9. REFERENCES This section lists the names of documents that were referenced in the earlier sections.