Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

NETCONF Notifications

 

Notifications

The ACX6160 supports NETCONF notifications (RFC5277), an asynchronous event notification service between a NETCONF server and a NETCONF client. The ACX6160 acts a NETCONF server and sends device event notifications, asynchronously as the events occur, to all NETCONF clients that subscribe to the notification service.

To subscribe to the notifications service for events that occur on a specific ACX6160 device, a NETCONF client sends a <create-subscription> rpc to the ACX6160 indicating the following:

  • <stream> - The name of the stream that the client is interested in. If this parameter is missing, the ACX6160 treats the subscription request as a request for the NETCONF stream, which is the only stream that the ACX6160 supports. The ACX6160 returns an error if the subscription request is for any other stream.

  • <filter> - A subtree filter that indicates the subtree of interest. If this parameter is present, only those events passed by the filter are sent. If this parameter is missing, all events are sent. The ACX6160 does not support XPATH filters.

  • <startTime> and <stopTime> - Indicates that the subscription request is for a replay. See Replay. If the <startTime> parameter is not present, then the subscription request is for new notifications and not for a replay.

For a subscription that is not a replay, the ACX6160 sends event notifications as they occur. The notifications continue until the subscription or the session is terminated.

Interleave

The ACX6160 supports the interleave capability for NETCONF notifications. The interleave capability allows the client and the ACX6160 to exchange regular NETCONF commands and responses within the same NETCONF session used for sending notifications. This reduces the total number of NETCONF sessions used because a dedicated NETCONF session for notifications is not required.

Replay

The ACX6160 supports the notification replay feature. The replay feature enables a client to request the ACX6160 to send or resend notifications that have occurred in the past, subject to any <filter> parameters.

The replay is defined by the following parameters in the <create-subscription> rpc:

  • <startTime> - Indicates that the subscription request is for a replay of the event notifications starting at the specified <startTime>. The <startTime> must not be later than the current time.

  • <stopTime> - Indicates the end time of the replay request. The <stopTime> must not be earlier than the <startTime> but can refer to a time in the future.

If both the <startTime> and <stopTime> parameters are present, the subscription request is for a replay of the event notifications starting at the specified <startTime> and ending at the specified <stopTime>. Once the replay is complete (that is, once the replay has reached the indicated <stopTime>), the subscription terminates but the NETCONF session remains up, reverting to a normal NETCONF command-response session.

If the <startTime> parameter is present but the <stopTime> parameter is missing, the subscription request is for a replay followed by new notifications. The replay covers the period from the specified <startTime> up until the time the subscription request was received by the device. After the replay finishes, the device sends any event notifications that have occurred since the subscription request was received as well as all future event notifications as they occur. The notifications continue until the subscription or session is terminated.

It is invalid for <stopTime> to exist without the corresponding <startTime>.

In some situations, the client might want to know prior to creating a replay subscription how far back in time that the ACX6160 has stored event notifications. To get this information, the client can perform a <get> request on the <streams> element. Among other information, the ACX6160 responds with a message containing the following timestamps:

  • <replayLogCreationTime> - The timestamp of the creation of the log storing the notifications to be replayed. This places a bound on the earliest notification stored.

  • <replayLogAgedTime> - The timestamp of the last notification aged out of the log. If this parameter is missing, no notifications have been aged out.