GB/T 17143.3-1997 Information technology Open Systems Interconnection System management Part 3: Attributes representing relationships
Some standard content:
GB/T 17143.3—1997
This standard is equivalent to ISO/IEC10164-3:1993 "Information Technology Open Systems Interconnection".
System management: attributes of representation relationships
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 of representation 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. Drafting unit of this standard: Standardization Institute of the Ministry of Electronics Industry. The main drafters of this standard are Zheng Hongren, Zhou Xiaohua and Zhao Xiaofan. 500
GB/T 17143.3-1997
ISO/IEC Foreword
ISO (International Organization for Standardization) and IEC (International Electrotechnical Commission) are specialized organizations for standardization worldwide. National member bodies (all of which are members of ISO () or IEC) participate in the formulation of international standards for specific technical scopes through various technical committees established by international organizations. The technical committees of ISO) and IEC cooperate in areas of common interest. Other official and non-official international organizations in contact with ISO and IEC can also participate in the formulation of international standards. For information technology, ISO and IEC have established a joint technical committee, namely ISO/IEC JTC1. The draft international standard proposed by the joint technical committee needs to be circulated to national member bodies for voting. At least 75% of the national member bodies participating in the voting need to vote in favor of publishing an international standard.
ISO/IEC10164-3 was developed by the ISO/IECJTC1 Joint Technical Committee "Information Technology" in cooperation with CCITT. The equivalent text is CCITT X.732.
ISO/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 of representation 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 audit tracking function
Part 9: Access Objects and attributes of control Part 10: Accounting and metering functions Part 11: Workload monitoring functions Part 12: Test management functions Part 13: Summarization functions Part 14: Reliability and diagnostic test classification 501 GB/T17143.3—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: Information technology GB/T 16644
GB/T 17142
GB/T 17175
GB/T16645
Information technology
Information technology
Information technology
Open Systems Interconnection
Open Systems Interconnection
Open Systems Interconnection
Open Systems Interconnection
Public management information service definition
Systems management overview
Management information structure
Public management information protocol
1 Scope
National Standard of the People's Republic of China
Information technology Open Systems Interconnection
, Systems managementwwW.bzxz.Net
Part 3: Attributes for representing relationshipsGB/T 17143.3—1997
idt ISO/IEC 10164-3: 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 attributes of the representation relationship, 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 object management functions; establishes a model that links the services and class definitions provided by this function with user requirements; defines the services provided by this function;
Defines class attribute types, notification types and parameters compiled according to 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 class 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 this function; does not specify the way management is completed by users of this function; does not define any characteristics of interactions that lead to the use of this 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, and does not define managed objects.
2 Referenced standards
The provisions contained in the following standards constitute the provisions of this standard through reference in this standard. When this standard was published, the versions shown were valid. 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 Information Processing System Open System Interconnection Basic Reference Model (idtISO7498:1984,eqvCCITT X.200:1988)
GB/T9387.4—1996 Information Processing System Open System Interconnection
Approved by the State Administration of Technical Supervision on December 15, 1997 Basic Reference Model, Part 4: Management Framework 1998-08-01 Implementation
GB/T 17143.3--1997
(idt ISO/1EC 7498-4:1989,eqvCCITT X.700:1992)9—94 Information Processing System Open System Interconnection Service Agreement (idtISO/TR8509:1987,eqvCCITTGB/T 15129-
x.210:1988)
GB/T 16263—1996
Information technology Open Systems Interconnection Abstract Syntax Notation One (ASN.1) Basic Encoding Rules Specification
(idt ISO/IEC 8825:1990,eqv CCITT X.209:1988)Information technology Open Systems Interconnection Common Management Information Service Definition (idt ISO/IEC9595：GB/T 16644--1996
1991,eqv CCITT X.710:1991)
GB/T17142—1997 Information technology Open Systems Interconnection System management overview (idtISO/IEC10040:1992)GB/T17143.4-1997 Information technology Open Systems Interconnection System management Part 4: Alarm reporting function (idtISO)/IEC10164-4:1992)
GB/T 17143.5—1997
GB/T 17143.6—1997
Information technology Open Systems Interconnection
System management Part 5: Event reporting management function (idt ISO/IEC 10164-5:1993)
: System management Part 6: Logging control functions (idt ISO/Information technology Open Systems Interconnection
IEC 10164-6:1993)
GB/T 17175.1—1997
Information technology Open Systems Interconnection
Management information structure
(idt ISO/IEC 10165-1:1993)
Part 1: Management information model
GB/T 17175.2—1997
Information technology Open Systems Interconnection Management information structure Part 2: Management information definitions (idt ISO/IEC 10165-2:1992)
GB/T 17175.4—1997
Information technology Open Systems Interconnection, Management information structure Part 4: Guide to the definition of managed objects (idt ISO/IEC 10165-4:1992) Information technology Open Systems Interconnection Application Layer Architecture (idtISO/IEC9545:1994) GB/T 17176—1997
GB/T 17178.1—1997
Information technology Open Systems Interconnection
Conformance test methods and framework Part 1: Basic concepts (idt ISO/IEC 9646-1:1994)
3 Definitions
This standard adopts the following definitions.
3.1 Basic reference model definitions
This standard adopts the following terms defined in GB9387: a) open system;
b) system management.
3.2 Management framework definitions
This standard adopts the following terms defined in GB/T9387.4: managed object.
3.3 CMIS Definition
This standard adopts the following terms defined in GB/T16644: attribute.
3.4 System Management Overview Definition
This standard adopts the following terms defined in GB/T17142: a) agent;
b) agent role,
c) subordinate consistency;
d) -\- general consistency,
e) generic definition,
f) managed object class;
g) manager;
h) manager role;
i) notification;
j) 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.3—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);
b) Confirmed Service;
c) Indication (primitive):
d) Unconfirmed Service;
e) Request (primitive);
1) Response (primitive).
3.7 OSI Conformance Test Definition
This standard adopts the following terms defined in GB/T17178.1: System Conformance Statement.
3.8 Supplementary Definitions
This standard adopts the following definitions.
3.8.1 Service relationshipsservice relationships An asymmetric relationship that indicates that the first of a pair of managed objects is a provider object (provides services) to the second, and the second is a user object (uses services) of the first. 3.8.2 Peer relationshipspeer relationshipsA peer relationship is a symmetric relationship that describes the rules under which similar pairs of managed objects communicate. 3.8.3 Fallback relationshipsfallback relationshipsare an asymmetric relationship that indicates that the second (secondary) of a pair of managed objects can serve as a fallback or "next choice" for the first (primary).
3.8.4 Back-up relationshipsback-up relationshipsare an asymmetric relationship that indicates that the second (backup) of a pair of managed objects is currently active and is performing backup functions in place of the first (backed-up object). 3.8.5 Group relationships A group relationship is a relationship between two managed objects where one (member object) belongs to the group represented by the other (owner object) 4 Abbreviations
Abstract syntax notation
Common management information service
5 Conventions
GB/T 17143.3—1997
Management application protocol data unit
Open Systems Interconnection
System management application protocol machine
Management information structure
This standard defines services for relationship change reporting following the descriptive conventions defined in GB/T 15129. 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;
Use of this parameter is an option for the service user; This parameter is not present in the interaction described by the primitive; The parameter is conditional;
The parameter is subject to mandatory constraints of GB/T16644.
Note: The parameters marked with "\P" in the service table of this standard are directly mapped to the corresponding parameters of the CMIS service primitive without changing the semantics or syntax of the parameters. The remaining parameters are used to construct MAPDU. 6 Requirements
Management users need to have the ability to examine the relationships between system parts or systems in order to understand how the operation of a part of the system depends on or is affected by other parts. After knowing that a certain part exists, users need to locate other parts related to it. Users also need the ability to change this relationship and the ability to be notified when this change is caused by other reasons. This standard defines general attributes, operations, and notifications, which can be part of any managed object definition. Model
The definitions used in this standard are to help describe the model used to represent the attributes of a relationship. 7.1 General
Relationships are defined by a set of rules that describe an open How the operation of one part of an open system affects the operation of other parts of the open system. A relationship is said to exist between managed objects when the operation of one managed object affects the operation of other managed objects. For a relationship to be meaningful in the context of OSI management, there must be sufficient management information to enable users of management information services to identify the managed objects involved and the rules that govern their interactions. 7.1.1 Direct and indirect relationships
When some part of the management information associated with a managed object clearly indicates that it has a relationship with another managed object, a direct relationship exists between the two managed objects.
When such a relationship can be derived from two or more direct relationships, an indirect relationship exists. Figure 1 shows direct and indirect relationships.
Indirect relationship
Direct relationship
Direct relationship
Direct relationship
Direct and indirect relationships
GB/T 17143. 3--1997
In the figure, circles represent managed objects and solid lines represent direct relationships (AB and BC), which are expressed as explicit management information. Dashed lines represent indirect relationships (AC) that can be inferred from the existence of direct relationships. 7.1.2 Relationship roles
In a relationship between two managed objects, a relationship role is a description of the part played by one managed object in relation to the other managed object (i.e., the rules describing its behavior). 7.1.3 Role attributes
A role attribute is a single-valued or multi-valued attribute of a managed object whose values are the names of other managed objects that exist in a particular relationship role in relation to the managed object that processes the attribute. The role attribute is used to represent the relationship. The management object class definer may impose a limit on the number of values in a multi-valued role attribute. Figure 2 shows a service relationship, which includes two managed objects, one in the service provider role and the other in the service user role. A
(User object)
Provider
7.1.4 Symmetric and asymmetric relationships
Service relationships
Figure 2 Relationship roles
(Provider object)
A symmetric relationship exists between two managed objects when the roles and the set of generic rules governing their interaction are the same.
An asymmetric relationship exists between two managed objects when the perspectives and the set of generic rules governing their interaction are different.
7.1.5 Relationship types
Relationships between managed objects may be of several types. A relationship type is defined by a set of relationship roles that may be applied to the managed objects that make up the relationship.
7.2 Relationship classification
This standard defines interoperability relationships and unidirectional relationships. 7.2.1 Interoperability relations
7.2.1.1 Definition of interoperability relations
An interoperability relation between two managed objects is represented by including the name of the other managed object to which it is related as one of the values of the role attribute of the managed object. Figure 3 shows an interoperability relation. x
Figure 3 Interoperability relations
In the figure, two managed objects X and Y have a direct relation XY, which is expressed by the name of object Y as the value of the role attribute RAx of X and by the name of object X as the value of the role attribute RA of Y. The interoperability relation is identified by the names of the two related managed objects and the name of one of the two role attributes reflecting the existence of the relation. Therefore, in Figure 3, the relation XY can be represented by indicating the value of Y in the role attribute RAx in the management information, or by indicating the value of X in the role attribute RA.
A managed object can have multiple instances of similar interoperability relationships. These relationships are expressed using multi-valued role attributes. 7.2.1.2 Management of interoperability relationships
An interoperability relationship is formed by creating a managed object with a specific role attribute. Interoperability relationships can be changed by operations such as create, delete, replace (add and remove in the case of multi-valued attributes). When a managed object is deleted, all interoperability relationships attached to that managed object are deleted. The result of performing these operations on any managed object will cause changes to the relationships between managed objects. Due to the different behavior of managed objects, these operations may result in further operations on related managed objects that help maintain the consistency of the relationships. Information about interoperability relationships can be obtained through management operations or as a result of notifications. The relationships of a managed object can be read by performing a "get" operation on the role attribute of a managed object. Due to the different behavior of managed objects, they may generate a notification when they create, delete or change a relationship.
7.2.2 Unidirectional relations
7.2.2.1 Unidirectional relation definition
A unidirectional relation between two managed objects is represented by including the name of the other managed object to which it is related as one of the values of the role attribute of only one of the managed objects. 7.2.2.2 Management of unidirectional relations
Unidirectional relations are managed in the same way as interoperability relations, by operating on the specified role attributes at the boundaries of the managed objects. 7.2.3 Managed objects representing simultaneous relations
When two direct relations are concatenated to form an indirect relation, the managed object shared by the two direct relations (e.g., managed object B in Figure 1) can be considered to represent an (indirect) relation between two other managed objects (i.e., A and C in Figure 1). When managed object B contains information identifying the type of relation and other role attributes of the indirect relation, it represents a relation. By extension, such a relationship object can represent relationships between three or more managed objects that cannot be expressed unambiguously by means of containment or interoperability relationships alone.
7.3 Relationship Types
A relationship type describes the nature of a relationship between two or more managed objects. The type of relationship is implicit in the name of the role attribute. The following types of interoperability relationships are defined by this standard. 7.3.1 Service Relationships
A service relationship is an asymmetric relationship that specifies that the first of a pair of managed objects is a provider object (provides a service) with respect to the second, and the second is a user object (uses the service) of the first. The fact that a service relationship exists between managed objects does not necessarily mean that the service is available. Provider objects and user objects are two roles in a service relationship. A unidirectional service relationship exists if one managed object specifies that the second managed object is a user object role, or if the second managed object specifies that the first managed object is a provider object role. An interoperability service relationship exists if two managed objects specify complementary roles with respect to each other. The order in which provider objects choose to be served by user objects is expressed as a preference value attached to each user object. The order in which user objects choose to be served by provider objects is expressed as a preference value attached to each provider object. 7.3.2 Peer-to-peer relationships
A peer-to-peer relationship is a symmetric relationship in which a pair of similar managed objects communicate. Related managed objects are called peers. For management operations, attributes are restricted to read-only, although normal or abnormal layer operations may change attribute values. A unidirectional relationship exists if one managed object designates the other managed object as a peer. An interoperable peer relationship exists if two managed objects designate each other as peers. 7.3.3 Fallback relationships
A fallback relationship is an asymmetric relationship that specifies that the second object in a pair of managed objects (the secondary object) has been designated as the fallback, or "next best" for the first managed object (the object). The existence of a backup relationship means that when the primary resource cannot complete its function, the secondary resource508
GB/T17143.3--1997
can provide backup services for it. But this does not necessarily mean that the secondary resource is active at the time and is performing backup functions to replace the primary resource.
The primary role and the secondary role are two roles in the backup relationship. If one managed object designates the second managed object as the secondary role, or if the second managed object designates the first managed object as the primary role, a one-way backup relationship exists. If two managed objects designate each other as complementary roles, a mutual backup relationship exists. The priority order in which the primary object selects the secondary object to provide backup services is expressed as a priority value attached to each secondary object. The priority order in which the secondary object selects the primary object to provide backup services is expressed as a priority value attached to each primary object. 7.3.4 Backup Relationships
A backup relationship is an asymmetric relationship that specifies that the second of a pair of managed objects (the backup object) is currently active and is performing backup functions in place of the first managed object (the backed-up object). The backup object and the backed-up object are two roles in a backup relationship. If one managed object specifies the second managed object as the backup role, or if the second managed object specifies the first managed object as the backed-up role, a one-way backup relationship exists. If two managed objects specify each other as complementary roles, a mutual backup relationship exists. A backup relationship is created as a result of a pre-existing backup relationship between two managed objects. When the backed-up resource is unable to perform its function, the backup relationship is initiated and the backup resource is activated to provide the same service. When the backed-up resource resumes performing its function, the backup relationship disappears and the backup resource ceases to provide the service. The creation and deletion of a backup relationship does not affect the existing backup relationship between the two managed objects.
A backed-up object can be in a "disabled" or "allowed" operating state. The administrative state of a backup object must be "unlocked" for a backup relationship to be established. When a managed object is being backed up for any reason (i.e., a backup relationship exists), the backup object can be used as long as it is not "prohibited". Operational states and administrative states are defined in GB/T 17143.2. 7.3.5 Group relations
A group relation is a relationship between two managed objects, where one (member object) belongs to a group represented by the other (owner object). A group relation is used to represent the grouping of member objects of the same or different classes for some identification function or administrative purpose, which can change during the lifetime of the member object. Members in a group can overlap, i.e., a given member object can have multiple owners. Owner and member are two roles in a group relation. If one managed object specifies the second managed object as a member role, or if the second managed object specifies the first managed object as an owner role, then a one-way group relation exists. If two managed objects specify each other as complementary roles, an interoperability group relationship exists. 7.4 Relationship roles
This standard defines the following relationship role types. Definition for service relationship:
provider object;
user object.
Define for peer relationship:
peer.
Define for backup relationship:
—primary role;
—secondary role.
Define for backup relationship:
backup object,
backed-up object.
Define for group relationship:
owner,
—member.
8 Generic definition
GB/T17143.3—1997
This chapter specifies a set of generic attributes and notifications, as well as their available parameters and semantics. 8.1 Generic attributes
This standard defines the following specific management attributes and attribute groups, whose abstract syntax is specified in GB/T 17175.2. a) providerObject ;
b) user(Object;
c) peer;
d)primary；
e) secondary;
f) backUpObject ;
g)backedUpObject;
h)member;
i) owner;
j) relationships.
These standardized attribute definitions can be used to derive new attribute definitions to identify more specific roles for related managed object classes.
8.1.1 Provider Objects
A managed object definition shall use provider object attributes to identify one or more managed objects that play the role of service provider relative to that managed object, and the priority of their roles. If the same priority applies to multiple managed objects, the order of precedence between those managed objects is a local matter. Provider object attributes are set-valued and read-write. 8.1.2 User objects
A managed object definition shall use the user object attribute to identify one or more managed objects that play the role of service user relative to that managed object, and the order of precedence in which they act. If the same priority applies to multiple managed objects, the order of precedence between those managed objects is a local matter. User object attributes are set-valued and read-write. 8.1.3 Peer
A managed object definition shall use the peer attribute to identify another managed object that plays the role of peer relative to that managed object. The peer attribute is single-valued and read-only. The attribute value can be either null or the name of a managed object. 8.1.4 Primary Role
A managed object shall use the Primary Role attribute to identify one or more managed objects that play a primary role relative to that managed object, and the order in which they act. If the same priority applies to multiple managed objects, the order of precedence between those managed objects is a local state. The Primary Role attribute is a set of values and is read-write. 8.1.5 Secondary Role
A managed object shall use the Secondary Role attribute to identify one or more managed objects that play a secondary role relative to that managed object, and the order in which they act. If the same priority applies to multiple managed objects, the order in which they act is a local state. The Secondary Role attribute is a set of values and is read-write. 8.1.6 Backup Object
A managed object shall use the Backup Object attribute to identify the managed object that plays a backup role relative to it. The Backup Object attribute is single-valued and read-only. The attribute value can be either null (if the managed object with this attribute is currently active and does not require backup services) or a managed object name. The backup object attributes form the backup object parameters defined in GB/T 17143.4. 8.1.7 Backed-up object
-A managed object shall use the backed-up object attribute to identify the second managed object that plays the backup role relative to it. The backed-up object attribute is single-valued and read-only. The attribute value can be either null (if the managed object with this attribute is not currently active as a backup on behalf of any other object) or a managed object name. 8.1.8 Member
A managed object shall use the member attribute to identify one or more managed objects that play the member role relative to that managed object. The member attribute is a valued set and can be read and written. 8.1.9 Owner
A managed object shall use an owner attribute to identify the one or more managed objects that play the owner role with respect to that managed object. Owner attributes are set-valued and are readable and writable. 8.1.10 Relationship Attribute Group
The relationship attribute group is defined as an empty attribute group. It provides a means of referencing the set of all relationship attributes of a managed object. The relationship attribute group is intended to contain the generic and specific relationship attributes of a managed object when included in a managed object class definition. When a relationship attribute group is read, the set of attribute identifiers and values that are members of the relationship attribute group will be returned. 8.1.11 Rules Applying to Relationship Attributes
When a managed object is required to represent any of the above relationships as management information, it shall include the appropriate attribute type as part of the object class definition. If instances of that object class do not currently have an established relationship, the relevant attribute shall be assigned a null value. When multiple objects in a collection are related to a given object in a certain role, the objects in the collection can be given a priority that shows their priority order. This priority feature is provided for objects in the following roles: (Service) Provider Object: Priority shows which service provider objects are preferred; (Service) User Object: Priority shows which service user objects are preferred; Primary Role: Priority shows which primary objects are preferred for backup if more than one primary object is disabled; Secondary Role: Priority shows which backup objects are preferred. For each of the above four roles, in their relationship attributes, each value is a closely related value pair, including the name of the related object and the priority assigned to it. A smaller priority value indicates that the related object has a higher priority. 8.2 Generic Notifications
The generic notifications, parameters and semantics defined by this standard describe in detail the following common parameters of the M-EVENT-REPORT service defined by GB/T 16644:
Event Type;
Event Information;
Event Response.
All notifications are potential items for the system management log, and this standard defines a management object class for this purpose. GB/T 17175.2 defines: a generic event log record object class from which all items are derived, additional information specified by the event information, and event response parameters. 8.2.1 Event Type
This parameter defines the type of event. This standard defines the following event types. Relationship Change: This notification type is used to report changes in the values of one or more relationship attributes of a managed object, which are generated by internal operations of the resource or by management operations. It is also used to report changes in relationship attributes specific to the object class. 8.2.2 Event Information
The following parameters constitute the notification-specific event information. 8.2.2.1 Source indicator
When this parameter is present, it indicates the source of the operation that caused this notification type to be generated. It can have one of the following values. Resource operation: the notification is generated in response to a change in the value of a relationship attribute caused by an operation internal to the resource; Management operation: the notification is generated in response to a change in the value of a relationship attribute initiated by an SMI management operation number acting on a managed object by crossing the external boundary of the managed object;
Unknown: the source of the operation cannot be determined.
8.2.2.2 Attribute identifier table2. a) providerObject ;
b) user(Object;
c) peer;
d)primary；
e) secondary;
f) backUpObject ;
g)backedUpObject;
h)member;
i) owner;
j) relationships.
These standardized attribute definitions can be used to derive new attribute definitions to identify more specific roles for related managed object classes.
8.1.1 Provider Objects
A managed object definition shall use provider object attributes to identify one or more managed objects that play the role of service provider relative to that managed object, and the order in which they act. If the same precedence applies to multiple managed objects, the order of precedence between those managed objects is a local matter. Provider object attributes are sets of values and are read-write. 8.1.2 User Objects
A managed object definition shall use the user object attribute to identify one or more managed objects that play the role of service user relative to that managed object, and the order in which they act. If the same priority applies to multiple managed objects, the order of precedence between those managed objects is a local matter. The user object attribute is a set of values and is read-write. 8.1.3 Peer
A managed object definition shall use the peer attribute to identify another managed object that plays the role of peer relative to that managed object. The peer attribute is single-valued and read-only. The attribute value may be null or the name of a managed object. 8.1.4 Master Role
A managed object shall use the master role attribute to identify one or more managed objects that play the master role relative to that managed object, and the order in which they act. If the same priority applies to multiple managed objects, the order of precedence between those managed objects is a local matter. The primary role attribute is a set of values and is readable and writable. 8.1.5 Secondary role
A managed object shall use the secondary role attribute to identify one or more managed objects that play a secondary role relative to that managed object, and the priority of their role. If the same priority applies to multiple managed objects, the priority between these managed objects is a local matter. The secondary role attribute is a set of values and is readable and writable. 8.1.6 Backup object
A managed object shall use the backup object attribute to identify the managed object that plays a backup role relative to it. The backup object attribute is single-valued and read-only. The attribute value can be a null value (if the managed object with this attribute is currently active and does not require backup services) or a managed object name. The backup object attributes form the backup object parameters defined in GB/T17143.4. 8.1.7 Backup Object
- A managed object shall use the Backup Object attribute to identify the second managed object that plays the backup role relative to it. The Backup Object attribute is single-valued and read-only. The attribute value can be either null (if the managed object with this attribute is not currently active as a backup on behalf of any other object) or a managed object name. 8.1.8 Member
A managed object shall use the Member attribute to identify one or more managed objects that play the member role relative to that managed object. The Member attribute is a set of values and is read-write. 8.1.9 Owner
A managed object shall use the Owner attribute to identify one or more managed objects that play the owner role relative to that managed object. The Owner attribute is a set of values and is read-write. 8.1.10 Relationship Attribute Group
The Relationship Attribute Group is defined as an empty attribute group. It provides a means of referencing the set of all relationship attributes of a managed object. The Relationship Attribute Group is intended to contain the generic and specific relationship attributes of a managed object when included in a managed object class definition. When a Relationship Attribute Group is read, the set of attribute identifiers and values that are members of the Relationship Attribute Group shall be returned. 8.1.11 Rules Applying to Relationship Attributes
When a managed object is required to represent any of the above relationships as management information, it shall include the appropriate attribute type as part of the object class definition. If no instance of that object class currently has an established relationship, the associated attribute shall be assigned a null value. When multiple objects in a set are related to a given object in some role, objects in the set may be assigned a priority indicating their order of precedence. This priority feature is provided for objects in the following roles: (Service) Provider Object: Priority shows which service provider objects are preferred; (Service) User Object: Priority shows which service user objects are preferred; Primary Role: Priority shows which primary objects are preferred for backup if more than one primary object is disabled; Secondary Role: Priority shows which backup objects are preferred. For each of the above four roles, in their relationship attributes, each value is a closely related value pair, including the name of the related object and the priority assigned to it. A smaller priority value indicates that the related object has a higher priority. 8.2 Generic Notifications
The generic notifications, parameters and semantics defined by this standard describe in detail the following common parameters of the M-EVENT-REPORT service defined by GB/T 16644:
Event Type;
Event Information;
Event Response.
All notifications are potential items for system management logs, and this standard defines a management object class for this purpose. GB/T17175.2 defines: A generic event log record object class from which all items are derived, additional information specified by the event information, and event response parameters. 8.2.1 Event Type
This parameter defines the type of event. This standard defines the following event types. Relationship Change: This notification type is used to report changes in the values of one or more relationship attributes of a managed object, which are generated by internal operations of a resource or by management operations. It is also used to report changes in relationship attributes specific to an object class. 8.2.2 Event Information
The following parameters constitute notification-specific event information. 8.2.2.1 Source Indicator
When this parameter appears, it indicates the source of the operation that caused this notification type to be generated. It can have one of the following values. Resource Operation: Generates a notification in response to a change in the value of a relationship attribute caused by an internal operation of a resource; Management Operation: Generates a notification in response to a change in the value of a relationship attribute caused by an SMI management operation number that acts on a managed object by crossing the external boundary of the managed object;
Unknown: The source of the operation cannot be determined.
8.2.2.2 Attribute identifier table2. a) providerObject ;
b) user(Object;
c) peer;
d)primary；
e) secondary;
f) backUpObject ;
g)backedUpObject;
h)member;
i) owner;
j) relationships.
These standardized attribute definitions can be used to derive new attribute definitions to identify more specific roles for related managed object classes.
8.1.1 Provider Objects
A managed object definition shall use provider object attributes to identify one or more managed objects that play the role of service provider relative to that managed object, and the order in which they act. If the same precedence applies to multiple managed objects, the order of precedence between those managed objects is a local matter. Provider object attributes are sets of values and are read-write. 8.1.2 User Objects
A managed object definition shall use the user object attribute to identify one or more managed objects that play the role of service user relative to that managed object, and the order in which they act. If the same priority applies to multiple managed objects, the order of precedence between those managed objects is a local matter. The user object attribute is a set of values and is read-write. 8.1.3 Peer
A managed object definition shall use the peer attribute to identify another managed object that plays the role of peer relative to that managed object. The peer attribute is single-valued and read-only. The attribute value may be null or the name of a managed object. 8.1.4 Master Role
A managed object shall use the master role attribute to identify one or more managed objects that play the master role relative to that managed object, and the order in which they act. If the same priority applies to multiple managed objects, the order of precedence between those managed objects is a local matter. The primary role attribute is a set of values and is readable and writable. 8.1.5 Secondary role
A managed object shall use the secondary role attribute to identify one or more managed objects that play a secondary role relative to that managed object, and the priority of their role. If the same priority applies to multiple managed objects, the priority between these managed objects is a local matter. The secondary role attribute is a set of values and is readable and writable. 8.1.6 Backup object
A managed object shall use the backup object attribute to identify the managed object that plays a backup role relative to it. The backup object attribute is single-valued and read-only. The attribute value can be a null value (if the managed object with this attribute is currently active and does not require backup services) or a managed object name. The backup object attributes form the backup object parameters defined in GB/T17143.4. 8.1.7 Backup Object
- A managed object shall use the Backup Object attribute to identify the second managed object that plays the backup role relative to it. The Backup Object attribute is single-valued and read-only. The attribute value can be either null (if the managed object with this attribute is not currently active as a backup on behalf of any other object) or a managed object name. 8.1.8 Member
A managed object shall use the Member attribute to identify one or more managed objects that play the member role relative to that managed object. The Member attribute is a set of values and is read-write. 8.1.9 Owner
A managed object shall use the Owner attribute to identify one or more managed objects that play the owner role relative to that managed object. The Owner attribute is a set of values and is read-write. 8.1.10 Relationship Attribute Group
The Relationship Attribute Group is defined as an empty attribute group. It provides a means of referencing the set of all relationship attributes of a managed object. The Relationship Attribute Group is intended to contain the generic and specific relationship attributes of a managed object when included in a managed object class definition. When a Relationship Attribute Group is read, the set of attribute identifiers and values that are members of the Relationship Attribute Group shall be returned. 8.1.11 Rules Applying to Relationship Attributes
When a managed object is required to represent any of the above relationships as management information, it shall include the appropriate attribute type as part of the object class definition. If no instance of that object class currently has an established relationship, the associated attribute shall be assigned a null value. When multiple objects in a set are related to a given object in some role, objects in the set may be assigned a priority indicating their order of precedence. This priority feature is provided for objects in the following roles: (Service) Provider Object: Priority shows which service provider objects are preferred; (Service) User Object: Priority shows which service user objects are preferred; Primary Role: Priority shows which primary objects are preferred for backup if more than one primary object is disabled; Secondary Role: Priority shows which backup objects are preferred. For each of the above four roles, in their relationship attributes, each value is a closely related value pair, including the name of the related object and the priority assigned to it. A smaller priority value indicates that the related object has a higher priority. 8.2 Generic Notifications
The generic notifications, parameters and semantics defined by this standard describe in detail the following common parameters of the M-EVENT-REPORT service defined by GB/T 16644:
Event Type;
Event Information;
Event Response.
All notifications are potential items for system management logs, and this standard defines a management object class for this purpose. GB/T17175.2 defines: A generic event log record object class from which all items are derived, additional information specified by the event information, and event response parameters. 8.2.1 Event Type
This parameter defines the type of event. This standard defines the following event types. Relationship Change: This notification type is used to report changes in the values of one or more relationship attributes of a managed object, which are generated by internal operations of a resource or by management operations. It is also used to report changes in relationship attributes specific to an object class. 8.2.2 Event Information
The following parameters constitute notification-specific event information. 8.2.2.1 Source Indicator
When this parameter appears, it indicates the source of the operation that caused this notification type to be generated. It can have one of the following values. Resource Operation: Generates a notification in response to a change in the value of a relationship attribute caused by an internal operation of a resource; Management Operation: Generates a notification in response to a change in the value of a relationship attribute caused by an SMI management operation number that acts on a managed object by crossing the external boundary of the managed object;
Unknown: The source of the operation cannot be determined.
8.2.2.2 Attribute identifier table6 Backup object
A managed object shall use the backup object attribute to identify the managed object that plays the backup role relative to it. The backup object attribute is single-valued and read-only. The attribute value can be either null (if the managed object with this attribute is currently active and does not require backup services) or a managed object name. The backup object attributes form the backup object parameters defined in ISO 17143.4. 8.1.7 Backed-up object
-A managed object shall use the backed-up object attribute to identify the second managed object that plays the backup role relative to it. The backed-up object attribute is single-valued and read-only. The attribute value can be either null (if the managed object with this attribute is not currently active as a backup on behalf of any other object) or a managed object name. 8.1.8 Member
A managed object shall use the member attribute to identify one or more managed objects that play the member role relative to that managed object. The member attribute is a set of values and is read-write. 8.1.9 Owner
A managed object shall use the owner attribute to identify one or more managed objects that play the owner role relative to that managed object. The owner attribute is a set of values and is read-write. 8.1.10 Relationship Attribute Group
The relationship attribute group is defined as an empty attribute group. It provides a way to reference the set of all relationship attributes of a managed object. The relationship attribute group is intended to contain the generic and specific relationship attributes of a managed object when included in a managed object class definition. When the relationship attribute group is read, the set of attribute identifiers and values that are members of the relationship attribute group will be returned. 8.1.11 Rules Applying to Relationship Attributes
When a managed object is required to represent any of the above relationships as management information, it shall include the appropriate attribute types as part of the object class definition. If no instance of that object class currently has an established relationship, the related attribute shall be assigned a null value. When multiple objects in a collection are related to a given object in a certain role, the objects in the collection may be assigned a priority that indicates their precedence. This priority feature is provided for objects in the following roles: (Service) Provider Object: Priority indicates which service provider objects are preferred; (Service) User Object: Priority indicates which service user objects are preferred; Primary Role: Priority indicates which primary objects are preferred as backups if more than one primary object is disabled; Secondary Role: Priority indicates which backup objects are preferred. For each of the four roles above, in their relationship attributes, each value is a closely related value pair consisting of the name of the related object and the priority assigned to it. A smaller priority value indicates that the related object has a higher priority. 8.2 Generic Notifications
The generic notifications, parameters and semantics defined by this standard describe in detail the following common parameters of the M-EVENT-REPORT service defined by GB/T 16644:
Event Type;
Event Information;
Event Response.
All notifications are potential items for the system management log, and this standard defines a management object class for this purpose. GB/T 17175.2 defines: a generic event log record object class from which all items are derived, additional information specified by the event information, and event response parameters. 8.2.1 Event Type
This parameter defines the type of event. This standard defines the following event types. Relationship Change: This notification type is used to report changes in the values of one or more relationship attributes of a managed object, which are generated by internal operations of the resource or by management operations. It is also used to report changes in relationship attributes specific to the object class. 8.2.2 Event Information
The following parameters constitute the notification-specific event information. 8.2.2.1 Source indicator
When this parameter is present, it indicates the source of the operation that caused this notification type to be generated. It can have one of the following values. Resource operation: the notification is generated in response to a change in the value of a relationship attribute caused by an operation internal to the resource; Management operation: the notification is generated in response to a change in the value of a relationship attribute initiated by an SMI management operation number acting on a managed object by crossing the external boundary of the managed object;
Unknown: the source of the operation cannot be determined.
8.2.2.2 Attribute identifier table6 Backup object
A managed object shall use the backup object attribute to identify the managed object that plays the backup role relative to it. The backup object attribute is single-valued and read-only. The attribute value can be either null (if the managed object with this attribute is currently active and does not require backup services) or a managed object name. The backup object attributes form the backup object parameters defined in ISO 17143.4. 8.1.7 Backed-up object
-A managed object shall use the backed-up object attribute to identify the second managed object that plays the backup role relative to it. The backed-up object attribute is single-valued and read-only. The attribute value can be either null (if the managed object with this attribute is not currently active as a backup on behalf of any other object) or a managed object name. 8.1.8 Member
A managed object shall use the member attribute to identify one or more managed objects that play the member role relative to that managed object. The member attribute is a set of values and is read-write. 8.1.9 Owner
A managed object shall use the owner attribute to identify one or more managed objects that play the owner role relative to that managed object. The owner attribute is a set of values and is read-write. 8.1.10 Relationship Attribute Group
The relationship attribute group is defined as an empty attribute group. It provides a way to reference the set of all relationship attributes of a managed object. The relationship attribute group is intended to contain the generic and specific relationship attributes of a managed object when included in a managed object class definition. When the relationship attribute group is read, the set of attribute identifiers and values that are members of the relationship attribute group will be returned. 8.1.11 Rules Applying to Relationship Attributes
When a managed object is required to represent any of the above relationships as management information, it shall include the appropriate attribute types as part of the object class definition. If no instance of that object class currently has an established relationship, the related attribute shall be assigned a null value. When multiple objects in a collection are related to a given object in a certain role, the objects in the collection may be assigned a priority that indicates their precedence. This priority feature is provided for objects in the following roles: (Service) Provider Object: Priority indicates which service provider objects are preferred; (Service) User Object: Priority indicates which service user objects are preferred; Primary Role: Priority indicates which primary objects are preferred as backups if more than one primary object is disabled; Secondary Role: Priority indicates which backup objects are preferred. For each of the four roles above, in their relationship attributes, each value is a closely related value pair consisting of the name of the related object and the priority assigned to it. A smaller priority value indicates that the related object has a higher priority. 8.2 Generic Notifications
The generic notifications, parameters and semantics defined by this standard describe in detail the following common parameters of the M-EVENT-REPORT service defined by GB/T 16644:
Event Type;
Event Information;
Event Response.
All notifications are potential items for the system management log, and this standard defines a management object class for this purpose. GB/T 17175.2 defines: a generic event log record object class from which all items are derived, additional information specified by the event information, and event response parameters. 8.2.1 Event Type
This parameter defines the type of event. This standard defines the following event types. Relationship Change: This notification type is used to report changes in the values of one or more relationship attributes of a managed object, which are generated by internal operations of the resource or by management operations. It is also used to report changes in relationship attributes specific to the object class. 8.2.2 Event Information
The following parameters constitute the notification-specific event information. 8.2.2.1 Source indicator
When this parameter is present, it indicates the source of the operation that caused this notification type to be generated. It can have one of the following values. Resource operation: the notification is generated in response to a change in the value of a relationship attribute caused by an operation internal to the resource; Management operation: the notification is generated in response to a change in the value of a relationship attribute initiated by an SMI management operation number acting on a managed object by crossing the external boundary of the managed object;
Unknown: the source of the operation cannot be determined.
8.2.2.2 Attribute identifier table
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.