7 IRPAgent’s Behaviour

32.106-33GPPCommon Object Request Broker Architecture (CORBA) Solution Set (SS)Configuration Management (CM)Part 3: Notification Integration Reference Point (IRP)Telecommunication managementTS

This clause describes some IRPAgent’s behaviour not captured by IDL.

7.1 Subscription

IRPManager can invoke multiple attach_push, multiple attach_push_b or multiple attach_pull using different manager_reference(s). As far as IRPAgent is concerned, the IRPAgent will emit notifications to multiple "places" with their independent filter requirements. IRPAgent will not know if the notifications are going to the same IRPManager.

If IRPManager invokes multiple attach_push, attach_push_b or attach_pull using the same manager_reference and with an already subscribed notification_category, IRPAgent shall raise AlreadySubscribed exception to all invocations except one.

IRPManager can invoke multiple attach_push using the same manager_reference and with one or more not-yet-subscribed notification_categories. In this case, if IRPAgent supports all the notification categories requested, IRPAgent shall accept the invocation; otherwise, it raises AtLeastOneNotificationCategoryNotSupported exception. IRPAgent shall have similar behaviour for attach_push_b and attach_pull.

When IRPManager is in subscription by invoking attach_push, IRPManager can change the filter constraint, using change_subscription_filter, applicable to the notification categories specified in the attach_push.

When IRPManager is in subscription by invoking attach_push_b, IRPManager can change the filter constraint during subscription using the OMG defined Notification Service Filter Interface. IRPManager shall not use change_subscription_filter; otherwise it shall get an exception.

7.2 IRPAgent supports multiple categories of Notifications

IRPAgent may emit multiple categories of Notifications. IRPAgent may have mechanism for IRPManager to pull for notifications of multiple categories.

IRPManager can query IRPAgent about the categories of notifications supported by using get_notification_categories.

IRPManager uses a parameter, notification_categories, in attach_push, attach_push_b and attach_pull to specify one or more categories of notifications wanted.

IRPManager uses a zero-length sequence in notification_categories of attach_push, attach_push_b and attach_pull to specify that all IRPAgent supported categories of notifications are wanted. If IRPManager uses attach_push with zero-length sequence in notification_categories and if the operation is successful, IRPAgent shall reject subsequent attach_push operation, regardless if the notification_categories contains a zero-length sequence or one or more specific notification categories. IRPAgent shall have similar behaviour for attach_push_b and attach_pull.

7.3 IRPAgent’s integrity risk of attach_push_b Method

In the case that IRPAgent implements this method by extending or using OMG compliant Notification Service, the following IRPManager behaviour illustrates a risk to IRPAgent’s integrity.

Given the object reference (IOR) of the SequenceProxyPushSupplier (as the mandatory output parameter of the subject method), IRPManager can invoke sequenceProxyPushSupplier.MyAdmin method.

IRPManager can then obtain the consumer admin object of the proxy. Then IRPManager can invoke consumerAdmin.MyChannel to get the IOR of the Notification Channel. IRPManager then can call eventChannel.MyFactory which will provide IRPManager the IOR of the EventChannelFactory itself. IRPManager can then able to invoke methods directly on the EventChannelFactory, like get_all_channels which lists all channel numbers and create_channel which allows IRPManager to create any number of additional channels.

A malicious IRPManager can, given access to the EventChannelFactory, get a list of existing channels and start connecting them together at random thus compromising the IRPAgent’s integrity. Deployment of this attach_push_b needs strong authentication and authorisation mechanism in place.

attach_push is mandatory. IRPAgent compliant to this IRP shall implement it.

attach_push_b is optional. It is recommended that IRPAgent concerned with integrity risk should not implement the attach_push_b option.

7.4 Quality of Service Parameters

The OMG Notification Service [2] supports a variety of Quality of Service (QoS) properties, such as reliability and priority, that may be expressed to indicate the delivery characteristics of notifications. While many of these QoS parameters need to be based on Service Level Agreements, a number of them need to be specified as required.
The following OMG Notification Service QoS parameter settings are required:

  1. The order policy shall be set to FifoOrder (First-in, First-out) [2].
  2. The message priority shall be set to 0, i.e., no priority [2].
  3. The Start Time Supported shall be set to false, i.e., do not use Start Time [2].
  4. The Stop Time Supported shall be set to false, i.e., do not use Stop Time [2].

When the OMG Notification Service is used, the IRPAgent has the responsibility of setting the OMG Notification Service Quality of Service parameters.

When the OMG Notification Service is not used, the IRPAgent has the responsibility to provide First-in, First-out notification ordering and to not provide priority to one Event Type and/or Extended Event Type over others.