4 System Management Functions
Last update
PvD
4 SMF
Attributes for Representing Relationships
Recommendation X.732.
Overview
Though going into details, this recommendation is very interesting for managing objects.
As we are concerned with managed objects, we are considering the relationship between two managed objects. Obviously there can be a direct relationship: 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.
In many cases however, there will be an indirect relationship: An indirect relationship exists when such a relationship can be deduced from the concatenation of two or more direct relationships.
Role attribute: A role attribute is a single valued or a set-valued attribute of a managed object whose values are the names of other managed objects that exist in a particular relationship role with respect to the managed object possessing the attribute. Role attributes are used to represent such relationships. The managed object class definer may impose a limit on the number of values in a set-valued role attribute.
Symmetry:
A symmetric relationship exists between two managed objects when the set of generic rules governing their interactions with each other and the roles of the two managed objects are identical {e.g. a peer-to-peer relationship}.
An asymmetric relationship exists between two managed objects when the set of generic rules governing their interactions with each other and the roles of the two managed objects differ {e.g. client/server relationship}.
A reciprocal relationship between two managed objects is represented by including, as one of the values of a role attribute of each of the managed objects, the name of the other managed object to which it is related {i.e. a direct relationship, but not necessarily a symmetric relationship, e.g. a client/server relationship}.
A managed object may have multiple instances of similar reciprocal relationships. These relationships are expressed using a set valued role attribute.
Management of reciprocal relationships: Reciprocal relationships result from the creation of a managed object with specific role attribute(s). They may be changed through the create, delete, replace (add and remove in the case of set-valued attributes) operations. When a managed object is deleted, all reciprocal relationships pertaining to that managed object are deleted. The result of carrying out these operations on any one managed object causes a change to the relationships between managed objects {!}. Depending on the behaviour of the managed object, these may result in further operations on related managed objects which assist in maintaining the consistency of the relationships.
Information about reciprocal relationships may be obtained through management operations or as a result of notifications. The relationships of a managed object can be read by applying get operations to the role attribute(s) of the managed object. Dependent upon the behaviour of managed objects, they may generate a notification whenever a relationship is created, deleted or changed.
A one-way relationship between two managed objects is represented by including, as one of the values of a role attribute of only one of the managed object, the name of the other managed object to which it is related.
Management of one-way relationships: One-way relationships are managed in the same manner as reciprocal relationships, by means of operations at the managed object boundary addressed to the role attribute.
When two direct relationships are concatenated to form an indirect relationship, the managed object that is common to both the direct relationships {i.e. the 'object in the middle'} can be regarded as representing the (indirect) relationship between the other two managed objects. The managed object 'in the middle' represents a relationship when it contains the information identifying the type of the relationship and other role attributes of the indirect relationships. By extension, such relationship objects may represent relationships between three or more managed objects which cannot be represented unambiguously through containment or reciprocal relationships alone.
An asymmetric relationship denoting that the first of a pair of managed objects is a provider object (providing services) to the second, and that the second is a user object (using services) of the first {i.e. the client/server relationship}.
The fact that a service relationship exists between managed objects does not necessarily imply that the service is available.
Provider object and user object are two roles in a service relationship. A one-way service relationship exists if a managed object designates a second managed object to be in the user object role, or if the second managed object designates the first managed object to be in the provider object role. A reciprocal service relationship exists if both managed objects designate each other to be in the complementary roles.
The order of preference in which the user objects are selected for the provision of service by the provider object is expressed as a priority value attached to each user object. The order of preference in which the provider objects are selected to provide service to the user object is expressed as a priority value attached to each provider object.
A peer relationship is a symmetric relationship under which pairs of similar managed objects communicate. The related managed objects are termed peers. The attribute is constrained to be read-only for management operations though the value of the attribute may be changed by the normal or abnormal operation of the layer. {?}
A one-way relationship exists if one managed object designates another managed object to be in the peer role {which seems to be odd as it is a symmetric relationship}. A reciprocal peer relationship exists if both managed objects designate each other to be in the peer role.
A fallback relationship is an asymmetric relationship denoting that the second of a pair of managed objects (the secondary object) is capable of serving as a fallback or 'next preferred choice' to the first managed object (the primary object). The existence of a fall back relationship implies that the secondary resource is capable of providing Back-up service to the primary resource if the latter is unable to fulfil its function {i.e. the secondary resource must be ready to take over, otherwise the relationship must be deleted}. It does not necessarily imply that the secondary resource is currently active and performing its Back-up function in place of the primary resource.
Primary and secondary are two roles in a fallback relationship. A one-way fallback relationship exists if a managed object designates a second managed object to be in the secondary role, or if the second managed object designates the first managed object to be in the primary role. A reciprocal fallback relationship exists if both managed objects designate each other to be in the complementary roles.
The order of preference in which the secondary objects are selected to provide Back-up service to the primary object is expressed as a priority value attached to each secondary object. The order of preference in which the primary objects are selected for the provision of Back-up service by the secondary object is expressed as a priority value attached to each primary object.
A back-up relationship is an asymmetric relationship denoting that the second of a pair of managed objects (the back-up object) is currently active and performing a back-up function in place of the first (the backed-up object).
Back-up object and backed-up object are two roles in a back-up relationship. A one-way back-up relationship exists if a managed object designates a second managed object to be in the back-up role, or if the second managed object designates the first managed object to be in the backed-up role. A reciprocal back-up relationship exists if both managed objects designate each other to be in the complementary roles.
A back-up relationship is created as a result of a pre-existing fallback relationship between two managed objects. The back-up relationship comes into existence when the backed-up resource is not fulfilling its function, and the back-up resource is activated to provide the same service. The back-up relationship ceases to exist when the backed-up resource resumes fulfilling its function, and the back-up resource ceases to provide that service. Creation and deletion of the back-up relationship has no effect on the existence of the fallback relationship between the two managed objects.
A backed-up object may be in the disabled or enabled operational state. The administrative state of the back-up object must be unlocked to allow the back-up relationship to exist. When a managed object is being backed-up for any reason (i.e., a back-up relationship exists), the back-up object is in use as long as it is not disabled. The operational and administrative states are defined in X.731 State Management function.
{So the fallback relationship defines that there is a backup available and ready, and the backup relationship indicates that the primary service is actually down and the backup is active.}
A group relationship is a relationship between two managed objects where one, the member object, belongs to a group represented by the other, the owner object. Group relationships are used to express the grouping of the same or different classes of member objects for some identified functional or administrative purpose, and can be changed during the lifetime of the member objects. Membership in groups can overlap, i.e., a given member object can have multiple owners.
Owner and member are the two roles in a group relationship. A one-way group relationship exists if a managed object designates a second managed object to be in the member role, or if the second managed object designates the first managed object to be in the owner role. A reciprocal group relationship exists if both managed objects designate each other to be in the complementary roles.
Generic attributes
| Type | properties | |
|---|---|---|
| providerObject | Service | set-valued, read/write, priority |
| userObject | Service | set-valued, read/write, priority |
| peer | Peer | single-valued, read-only |
| primary | Fallback | set-valued, read/write, priority |
| secondary | Fallback | set-valued, read/write, priority |
| backUpObject | Back-up | single-valued, read-only |
| backedUpObject | Back-up | single-valued, read-only |
| member | Group | set-valued, read/write |
| owner | Group | set-valued{!}, read/write |
| relationships | set-valued (see next paragraph) |
A special attribute is relationships: it is actually an relationship attribute group. It provides a means of referring to the collection of all relationship attributes of a managed object. The intent of the relationships attribute group is to contain the generic and specific relationship attributes of a managed object when included in the managed object class definition. When the relationships attribute group is read, the set of attribute identifiers and values which are members of the relationships attribute group will be returned.
Priority: When there is a set of multiple objects related in a certain role to a given object, the objects in the set can be assigned a priority value showing the order of preference. Such a priority feature is provided for objects in the following roles:
(service:) providerObject & userObject, and
(fallback:) primary & secondary.
In the relationship attributes for each of these four roles, each value is a bound pair of values comprising the related object name and the priority value assigned to that related object.
A lower numerical priority value indicates that the related object has a higher preference.
Notification of a change of relationship follows the general CMIP rules (X.710).
The event type will be 'relationship change': This notification type is used to report the change in the value of one or more relationship attributes of a managed object, that result through either the internal operation of the resource or via management operation. It is also used to report changes in object class specific relationship attributes.
All notifications are potential entries in a systems management log (X.721). See also X.734 Event report management function.
Source indicator: This parameter, when present, indicates the source of the operation that led to the generation of this notification type. It can have one of the following values.
Attribute identifier list: This parameter, when present, identifies the set of relationship attributes whose value changes are being reported. This parameter set consists of a set of sequences of the three parameters:
Each individual sequence describes a single relationship attribute value change. At least one new relationship attribute value shall be present in this list.
Other information: The following parameters are also utilised (e.g. defined by X.733 Alarm Reporting function):
No Event reply is specified.
Next section: Event Report management function
Up to Contents
Up to Index
=O=