GB/T 17143.2-1997 Information technology Open Systems Interconnection System management Part 2: State management functions
Some standard content:
GB/T 17143.2--1997
This standard is equivalent to ISO/IEC10164-2:1993 "Information technology open systems interconnection system management: State management function" and ISO/IEC10164-2:1993/Cor, 1:1996 "Information technology open systems interconnection system management: State management function Technical amendment 1.
According to ISO/IEC10164-2:1993/Cor.1:1996, this standard modifies 8.1.2.3 and 8.1.2.5. GB/T17143, under the general title of "Information Technology Open Systems Interconnection System Management", currently includes the following 8 parts: Part 1 (i.e. GB/T17143.1): Object management function Part 2 (i.e. GB/T17143.2): State management function Part 3 (i.e. GB/T17143.3): Attributes representing relationships Part 4 (i.e. GB/T17143.4): Alarm reporting function Part 5 (i.e. GB/T17143.5): Event report management function Part 6 (i.e. GB/T17143.6): Log control function Part 7 (i.e. GB/T17143.7): Security alarm reporting function Part 8 (i.e. GB/T17143.8): Security audit tracking function This standard is proposed by the Ministry of Electronics Industry of the People's Republic of China. This standard is under the jurisdiction of the Standardization Institute of the Ministry of Electronics Industry. The drafting unit of this standard: Standardization Institute of the Ministry of Electronics Industry. The main drafters of this standard: Zheng Hongren, Zhou Xiaohua, Wu Kezhong. 4.80
GB/T 17143.2—1997
ISO/IEC Foreword
ISO (International Organization for Standardization) and IEC (International Electrotechnical Commission) are specialized organizations for standardization worldwide. National bodies (which are members of ISO or IEC) participate in the preparation of International Standards for specific technical areas through technical committees established by the international organizations. ISO and IEC technical committees cooperate in areas of common interest. Other official and non-official international organizations in liaison with ISO and IEC may also participate in the preparation of International Standards. For information technology, ISO and IEC have established a joint technical committee, ISO/IEC JTC1. Draft international standards proposed by the joint technical committee are circulated to national member bodies for voting. Publication of an international standard requires approval by at least 75% of the national member bodies that voted.
ISO/IEC10164-2 was prepared by the ISO/IEC JTC1 Joint Technical Committee "Information Technology" in cooperation with CCITT. The equivalent text is CCITT X.731.
IS0/IEC10164, under the general title of "Information Technology Open Systems Interconnection System Management", currently includes the following 14 parts: - Part 1: Object management function
Part 2: State management function
Part 3: Attributes representing relationships
Part 4: Alarm reporting function
Part 5: Incident report management function
Part 6: Log control function
- Part 7: Security alarm reporting function
- Part 8: Security Full audit trail function
Part 9: Objects and attributes of access control-Part 10: Accounting and metering function
Part 11: Workload monitoring function-Part 12: Test management function
Part 13: Summarization function
Part 14: Credibility and diagnostic test classification 481
GB/T17143.2-1997
GB/T17143 is a standard consisting of multiple parts formulated in accordance with GB9387 and GB/T9387.4. GB/T17143 is related to the following standards:
GB/T 16644
GB/T16645
GB/T 17142
GB/T 17175
Information technology
Information technology
Information technology
Information technology
Open systems interconnection
Open systems interconnection
Open systems interconnection
Open systems interconnection
Public management information service definition
Public management information protocol
System management overview
Management information structure
1 Scope
National Standard of the People's Republic of China
Information technology Open systems interconnection
System management
Part 2: State management functions
Information technology--Open Systems Interconnection--Systems Management-Part 2:State management functionGB/T 17143.2—1997
idt IS0/1EC 10164-2: 1993
This standard defines a system management function for application processes to interact in a centralized or decentralized management environment for system management as defined in GB/T9387.4. This standard defines the state management function, which consists of service and class definitions. This standard is located in the application layer of GB9387 and is defined according to the model provided by GB/T17176. The role of the system management function is described by GB/T17142. This standard
Establishes user requirements for the state management function; establishes a model that relates the services and generic definitions provided by this function to user requirements; defines the services provided by this function;
Defines generic attribute types, notification types and parameters compiled in accordance with GB/T17175.4 - specifies the protocols necessary to provide services; defines the relationship between services and management operations and notifications; specifies the requirements that other standards that use these generic definitions should comply with; defines the relationship with other system management functions: specifies consistency requirements.
This standard
Does not define the characteristics of any implementation intended to provide the state management function; - does not specify the way in which management is accomplished by users of the state management function; - does not define any characteristics of the interaction that leads to the use of the state management function - does not specify the services necessary to establish, normally release and abnormally release management connections; - does not exclude the definition of further notification types; does not define managed objects.
2 Referenced standards
The clauses contained in the following subscripts constitute the clauses of this standard through reference in this standard. The versions indicated are valid at the time of publication of this standard. All standards are subject to revision. Parties using this standard should explore the possibility of using the latest versions of the following standards. GB9387-88 Basic Reference Model for Open Systems Interconnection of Information Processing Systems (idtISO7498:1984,eqvCCITT X.200:1988)
GB/T 9387. 4-1996
Basic Reference Model for Open Systems Interconnection of Information Processing Systems Part 4: Management Framework (idtISO/IEC 7498-4:1989,eqvCCITT X.700:1992)GB/T15129-94 Service Agreement for Open Systems Interconnection of Information Processing Systems (idtISO/TR8509:1987, evCCITT State Administration of Technical Supervision approved on December 15, 1997 and implemented on August 1, 1998
X.210:1988)
GB/T 17143.2--1997
GB/T16263-1996 Information technology Open Systems Interconnection Abstract Syntax Notation - (ASN.1) Basic Encoding Rules Specification (idtISO/IEC8825:1990,eqvCCITT X.209:1988)GB/T 16644-1996
Information technology Open Systems Interconnection Common Management Information Service Definition (idtISO/IEC9595:1991,eqvCCITT X.710.1991)
Information technology Open Systems Interconnection System Management Overview (idtISO/IEC10040:1992)GB/T 17142-1997↑
GB/T17143.3-1997 Information technology Open Systems Interconnection System Management Part 3: Alarm Reporting Function (idtISO/JEC 10164-3:1993)
GB/T 17143. 4--1997
Information technology open systems interconnection
Part 4: Alarm reporting function (idtISO/System Management
IEC 10164-4:1992)
GB/T 17143. 5—1997
Master system management
Part 5: Event reporting management function (IDT Information technology Open Systems Interconnection
ISO/IEC 10164-5:1993)
GB/T 17143.6—1997
Information technology Open Systems Interconnection
IEC 10164-6:1993)
GB/T 17175.1—1997
Information technology Open Systems Interconnection
ISO/IEC 10165-1:1993)
GB/T 17175.2-1997
Information technology Open Systems Interconnection
ISO/IEC 10165-2:1992)
GB/T 17175.4—19971
Information technology Open Systems Interconnection
System management
Part 6: Log control function (idtISO/Management information structure Part 1: Management information model (idtManagement information structure Part 2: Management information definition (idtManagement information structure
Part 4: Definition of managed objects
Guidelines (idtISO/IEC10165-4:1992)
GB/T 17176-1997
Information technology Open Systems Interconnection Application layer architecture (idtISO/IEC9545:1994) Information technology Open Systems Interconnection
GB/T 17178.1-1997
Methods and framework for conformance testing Part 1: Basic concepts (idt ISO/IEC 9646-1:1994)
3 Definitions
This standard adopts the following definitions.
3.1 Basic reference model definition
This standard adopts the following terms defined in GB9387: a) open system;
b) system management.
3.2 Management framework definition
This standard adopts the following terms defined in GB/T9387.4: managed object.
3.3 CMIS Definitions
This standard adopts the following terms defined in GB/T16644: attribute.
3.4 System management overview definitions
This standard adopts the following terms defined in GB/T17142: a) agent;
b) agent role;
c) dependency-consistency;
d) general consistency;
e) generic definition,
f) managed object class;
g) manager;
h) manager role;
i) notification;
i) system management functional unit;
k) system management function;
1) system management application protocol;
m) (system management) operation.
3.5 Management Information Model Definition
GB/T 17143.2—1997
This standard adopts the following terms defined in GB/T17175.1: managed object boundary.
3.6 Service Agreement Definition
This standard adopts the following terms defined in GB/T15129: a) confirmation (primitive);wwW.bzxz.Net
b) confirmed service;
c) indication (primitive);
d) non-confirmed service;
e) request (primitive);
f) response (primitive).
3.7 SI Conformance Test Definition
This standard adopts the following terms defined in GB/T17178.1: system conformance statement.
Abbreviations
5 Conventions
Abstract Syntax Notation
Common Management Information Service
Management Application Protocol Data Unit
Open Systems Interconnection
System Management Application Protocol Machine
Management Information Structure
This standard defines services for state management functions following the descriptive conventions defined in GB/T15129. In clause 9, the definition of each service includes a table listing the service parameters. For a given service primitive, the presence of each parameter is described by one of the following values: M
The parameter is mandatory;
The parameter value is equal to the value of the parameter in the left column;
The use of this parameter is an option for the service user; The parameter is not present in the interaction described by this primitive; The parameter is conditional;
GB/T.17143.2--1997
The parameter is subject to the mandatory constraints of GB/T16644.
Note: Parameters marked with "P" in the service tables of this standard map directly to the corresponding parameters of the CMIS service primitives without changing the semantics or syntax of the parameters. The remaining parameters are used to construct the MAPDU. 6 Requirements
The management information service (MIS) user needs the ability to check and be notified of state changes in order to monitor the overall operability and use of resources at all times and to control the overall availability of specific resources. In order to provide standardized OSI management techniques for the management state involved, this standard defines general attributes and operations that can be part of any managed object.
State management provides:
Report changes in state attributes;
-Read state attributes;
-Change state attributes.
7 Model
The management state of a managed object describes the instantaneous condition of the availability and operability of the relevant resources from the management point of view. Different types of managed objects have various state attributes that are specific to each type of object in terms of expressing and controlling the operation of their relevant resources. However, it is desirable that the management state be common to a large number of resources and therefore standardized; it represents key aspects of their availability at any given time. Its purpose is to control the aggregate availability of resources and to obtain explicit information about this aggregate availability. 7.1 Generic state
There are three main factors that influence the management state of a managed object in terms of the availability of its corresponding resource. Some managed objects may not be affected by all three factors. These factors are: - Operation: whether the resource is actually set up and working, if applicable; - Usage: whether the resource is in use at a particular moment, and if so, whether it has spare capacity for other users at that moment. A resource is said to be in use when it has one or more outstanding service requests or when some of its capacity has been allocated and not yet restored as a result of previous service requests. Administrative: The permission or non-prohibition of the use of a resource imposed by management services. The state of a managed object does not affect the ability of management operations. 7.1.1 Operational state
The operation of a resource is described by the operational state attribute, which has two possible values: "prohibited" and "allowed". These values are described in 8.1.1.1. Some managed object classes only present a constant value of operational state. When a resource has no obvious dependencies on other resources and has no components that could exhibit an obvious defect, then the managed object may not assume the prohibited operation state. Similarly, a managed object that no longer exists does not assume the prohibited operation state that it had during its existence when the resource becomes inoperable. When a resource no longer exists, but there are still managed objects that manage the state attributes of that resource, then the operational state should be prohibited. The set of supported operational state values is specified in each individual managed object class definition.
When a managed object cannot reflect its related The operational state of a resource and the unknown state attribute defined in 8.1.2.6 is supported, then the unknown state attribute value is true.
It is the natural operation of the resource that causes the operational state to transition, so management cannot request a managed object to change from one operational state to another. Management can only collect information about the operational state of a managed object, that is, the nature of the operational state is read-only. Certain events related to the resource cause transitions from one operational state value to another. These events and transitions are summarized in Figure 1 and described as follows:
7.1.1 .1 Enable
GB/T17143.21997
Enable Disable
Figure 1 Operational state diagram
This event consists of actions taken to make the resource partially or completely operational. This event can only occur when the operational state of the managed object is "Prohibited". The "Enable" event causes the operational state to be transferred to "Enable". 7.1.1.2 Disable
This event consists of some actions that make the resource completely inoperable. The "Prohibit" event causes the operational state to be transferred to "Prohibited". 7.1.2 Usage Status
The usage of a resource is described by the usage status attribute, which has three possible values: idle, active, and busy. These status attribute values are described in 8.1.1.2. The set of supported usage status values is specified in each individual managed object class definition. Some managed object classes present only a subset of the possible usage status values. A managed object whose associated resource supports only one user has only the "idle" or "busy" usage status, but does not present the "active" usage status. A managed object whose resource has no practical limit on the number of users does not present the "busy" usage status.
When a managed object does not reflect the usage status of its associated resource and supports the unknown status attribute defined in 8.1.2.6, the value of the unknown status attribute is true.
It is the natural operation of the resource that causes the usage status to change, so management cannot request a managed object to change from one usage status to another. Management can only collect usage status information about managed objects; the nature of the usage status is read-only. Certain events associated with a resource cause transitions from one usage state value to another. These events and transitions are summarized in Figure 2 and described as follows:
Last user
User exit
User exit
(non-shared object)
New user
New user
(non-shared object)
New userNew user
Figure 2 Usage state diagram
7.1.2.1 New user
This event consists of some actions that start using a resource. It can only occur if the operating state of the managed object is "allowed" and its usage state is "idle" or "active". The new user event generates transitions as follows: - after the event, if the resource still has sufficient operating capacity to provide for another user, the usage state becomes or remains "active",
- after the event, if the resource has no operating capacity left for another user, the usage state becomes "busy". 7.1.2.2 User Exit
This event consists of an existing user of a resource ending its use. It can only occur when the usage state of the managed object is "active" or "busy". It can be generated by the change of the operating state from "allowed" to "prohibited". The user exit event generates a transition as follows: - after the event, if there are still users of the resource, the usage state becomes or remains "active"; - after the event, if there are no users of the resource, the usage state becomes "idle". 7.1.2.3 Capacity Increase (CI)
This event is formed by the increase of the maximum operating capacity of the resource. It is only meaningful when the usage state of the managed object is "busy". If the managed object is in the "busy" state, the capacity increase event causes a transition to the "active" state. 7.1.2.4 Capacity Decrease (CD)
This event is formed by the decrease of the maximum operating capacity of the resource. It is only meaningful if the usage state of the managed object is "active". A capacity reduction event causes the following transitions:
- If the resource still has spare capacity for operation after the event, the usage state remains "active"; - If the resource no longer has spare capacity for operation after the event, the usage state changes to "busy"; - If the managed object was in the "busy" state when the capacity reduction occurred, the managed object shall continue to be in the "busy" state until a capacity increase or user exit event occurs.
7.1.3 Administrative state
The administrative operation of a managed object is independent of the operability and use of the managed object and is described by the administrative state attribute, which has three values, as shown in Figure 3. These administrative states are called "locked", "unlocked" and "closed" and are described in 8.1.1.3. Some managed object classes present only a subset of the possible administrative state values. Some resources cannot be locked, so their corresponding managed objects only assume the "unlocked" state. Other resources cannot be closed perfectly, so their corresponding managed objects do not assume the "closed" state. The actual subset of administrative state values supported varies from one class of managed objects to another, and is specified in each individual managed object definition. Specific events related to managed objects cause specific transitions from one administrative state value to another, which depends on the original value of the administrative state, the specific event, and the number of resource users. These events and transitions are summarized in Figure 3 and described as follows: Unlocked
User exit
(if idle)
User exit
Last use
Locked User exit
Figure 3 Administrative state diagram
7.1.3.1 Unlock
This event consists of an operation that is performed on the managed object boundary to release the lock on the corresponding resource of the managed object. It can only occur when the administrative state of the managed object is "locked". or "closed", it causes the administrative state to transfer to "unlocked". 7.1.3.2 Lock
This event consists of an operation that is performed on the boundary of a managed object to lock the corresponding resource of the managed object. It can only occur when the administrative state of the managed object is "unlocked" or "closed", and it causes the administrative state to transfer to "locked". 7.1.3.3 Close
This event consists of an operation that is performed on the boundary of a managed object to close the corresponding resource of the managed object. It can only occur when the administrative state of the managed object is "unlocked", and it causes the state transition as follows: at the time of the event, if there is still a user of the resource, the administrative state becomes "closed"; at the time of the event, if there is no user of the resource, the administrative state becomes "locked". 7.1.3.4 User Exit
This event consists of an existing user of a resource ending its use. It can only occur when the administrative state of a managed object is "unlocked or "closed". 17143.2—1997
When the administrative state is "unlocked", no administrative state transition occurs. If the administrative state is "closed", the user exit event causes the transition as follows:
After the event, if there are still users of the resource, the administrative state remains "closed"; -After the event, if the resource no longer has a user, the administrative state becomes "locked". 7.1.4 Dependencies between generic states
It is the responsibility of the defined managed object class to specify which combinations of state values are supported and which are not supported for each individual managed object class.
When a managed object supports all three state attributes, the possible combinations of the three state attributes are as follows (see also Figure 4): -Disabled, Idle, Locked: The resource is completely inoperable, it does not serve any user and is administratively prohibited from use. To make it available, both administrative permission (unlock operation) and some corrective action are required. - Allowed, Free, Locked: The resource is partially or fully operational, it is not serving any user and its use is administratively prohibited. To make it available, only administrative permission (unlock operation) is required. - Allowed, Active, Closed: The resource is partially or fully operational and in use, but the use is administratively restricted to the current use instance. To allow an added user to gain access, administrative permission (unlock operation) is required. Otherwise, when all current users end their use of the resource, the managed object shall automatically transfer to the Allowed, Free, Locked state. - Allowed, Busy, Closed: The resource is partially or fully operational and in use, but the use is administratively restricted to the current use instance; in addition, it has no spare capacity to provide for another user. To allow another user to gain access, administrative permission (unlock operation) is required in addition to waiting for an existing user to end. Otherwise, when all current users end their use of the resource, the managed object shall automatically transfer to the Allowed, Free, Locked state.
Forbidden, Free, Unlocked: The resource is completely inoperable, it is not serving any user, but its use is not administratively prohibited. To make it available, some corrective action is required.
--Allowed, free, unlocked: The resource is partially or fully operational, it is not actually in use, and is not administratively prohibited from use. -Allowed, active, unlocked: The resource is partially or fully operational, it is in use, and is not administratively prohibited from use. At the same time, it has sufficient spare capacity to provide for other users. -Allowed, busy, unlocked: The resource is partially or fully operational, it is in use, and is not administratively prohibited from use. It currently has no spare capacity to provide for other users. In order for other users to gain access, they must wait for an existing user to end or a capacity increase event to occur
Figure 5 shows a combined state diagram of the operational and administrative states. Figure 6 shows a combined state diagram of the administrative and usage states. Figure 7 shows a combined state diagram of the operational and usage states. 489
GB/T 17143.2—1997
1—Unlock: 2—Lock, 3—Allow; 4—Disable, 5—New user, 6—User exit: 7—New user (non-shared resources); 8—Last user exit: 9—Capacity increase; 10—Capacity decrease, 11—Close Figure 4 Combined state diagram
Allow
Disable
Allow
Disable
Lock,
Last user exit
Figure 5 Operation and administrative state
7.2 Status attributes
GB/T17143.2—19 97
1--Unlock, 2--Lock; 3--New user; 4--User logout; 5--New user (non-shared resources); 6--Last user logout; 7--Capacity increase; 8-Capacity decrease; 9--Close Figure 6 Administrative and usage status
1---Enable: 2--Disable; 3--New user, 4--User logout, 5--New user (non-shared resources), 6--Last user logout; 7-Capacity increase; 8-Capacity decrease Figure 7 Operational and usage status
Status attributes may contain more detailed information about other aspects of the state of the corresponding resource that can affect its operability and use. They also contain more detailed information about administrative restrictions on operations controlled by the administrator. Status attributes are defined in 8.1.2. 7.3 Object class-specific status information
Managed objects may have some other class-specific attributes that describe aspects of the resource state but do not map to the generic state defined in this standard. Although different, these attributes may affect the value of the generic state attribute. Each individual managed object class definition shall specify applicable generic state values resulting from a specific combination of other attribute values. When a managed object is in the "disabled" operational state, other attributes may indicate why the corresponding resource is inoperable. Disabling operation may or may not be related to processes under administrative control. If a resource is inoperable because another resource on which it depends has been administratively disabled, or because of some other incompatibility of configuration information and operation, the resource may be made operational by administrative procedures. The handling of information indicating that a resource is inoperable due to some specific physical defect, and the method of remedying the defect, is outside the scope of the state management function. If the state of one resource is dependent on the state of another resource, this dependency may be specified by the behavior of the managed object representing the dependent resource or both. A state change in a supporting managed object may cause a specified state transition in a dependent managed object through a relationship.
Tip: This standard content only shows part of the intercepted content of the complete standard. If you need the complete standard, please go to the top to download the complete standard document for free.