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
<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.
<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.
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.
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
The replay is defined by the following parameters in the
<startTime>- Indicates that the subscription request is for a replay of the event notifications starting at the specified
<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
<stopTime> parameters are present, the subscription
request is for a replay of the event notifications starting at the
<startTime> and ending at
<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
<startTime> parameter is
present but the
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
It is invalid for
exist without the corresponding
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
<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.