[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Some thoughts about Call-home
Hello,
Here are some thoughts about the call-home function. Sadly I was unable to complete it,
but it might be still useful.
=========================================================================
[NOTE]
Subscription based notification is good if
- the management application wants to receive notifications for a short period of time
- if the set of notifications the management application is interested in changes
frequently (changing filter)
Statically configured notification delivery is best for management applications if
- the manager is interested in the same set of notifications for a long time.
- it does not want to reconfigure the managed device after eventual restarts, loss of
connections etc.
- the manager does not want to maintain a Netconf connection permanently, but still needs
some notifications
- the manager handles a big number of devices, so establishing Netconf session to each
would be a major task
0. Call-Home Capability
0.1. Description
0.1.1 Overview
Call-Home capability allows a Netconf server to send notifications to a
client even if there is no Netconf live session between the client and the
server initially when the server wants to send a notification.
The capability can be useful for NAT traversal as in this model, the
Netconf server initiates the Notification session. Another use case is
when a manager handles a large number of devices that it
only wants to deal with when there is a known issue. It is useful if it would be to much
work for the manager to set up Netconf sessions to every device after
e.g. a manager restart.
The device has to configured with data about which clients(targets) should be
contacted. Data about each target will include:
- Target Name (key)
- Target Transport Address
- Transport type (SSH, BEEP, SOAP)
- Target Security name to use
- Security Credential Type
- Security Credential
- Notifications Filter associated
- Use Mixed Notification Sessions (boolean)
- Active/Passive
- Removed With Session (sessionId)
- Currently used sessionId (read-only)
- Inactivity Timeout
The above data will be stored for each target in non-volatile memory.
[NOTE] This should be the same data model as used for subscriptions.
Target name (human readable string) is the key that identifies the target.
Transport Address is an IPv4 or IPv6 address or a fully qualified
domain name and an optional port number. If the Netconf default
port is used port can be set to zero.
Transport Type identifies the underlying transport in case when
multiple types are supported by the Netconf server.
Security Name defines the security name to use when initiating
a new session.
Security credential type can be something like plain password, a
certificate, [TODO]
Security credential will be used to set up the session
Filter will be used to decide whether an individual notification
shall be sent to a target.
Use Mixed Notification Sessions [TODO] Needed ?
Active/Passive indicates whether notifications should be sent to
this target. This allows managers to configure the Netconf
server but still temporarily suspend notification delivery.
Removed With Session indicates that the target was created by
a subscription by the indicated session and it should be deleted
when that session is closed.
SessionId indicates the current session used for delivering
notifications. This maybe null [TODO how to really indicate null]
if there is no such session.
Inactivity Timeout indicates that the time when the session
should be automatically closed if it is not used. The session will
be removed only if Removed With Session is null i.e. the session
is not subscription based.
Targets are created by normal configuration operations
(<edit-config>, <copy-config>). Any referenced filters must be created
before the notification target. For short lived subscriptions either
the Removed With Session field shall be used or the target shall be
removed with a subsequent configuration operation.
When an event of interest happens the Netconf server should go
through the following steps:
For each event {
determine the targets,
apply filters,
send message request to message processing
}
For each message request {
build notification,
send message to transport mapping
}
For each message {
Check if you have a CurrentlyUsedSessionId
If not, create session UseMixedNotifictionSessions=false,
RemovedWithSession=null,
store used sessionId
send message
}
If session setup fails, the target is simply skipped for this
notification. The Netconf server may notify the individual
targets in any order.
[NOTE] A session for notifications can be started in two ways.
- By call-home in which case we can reuse the session.
- By subscription in which case we can again reuse the session.
- However if there is a session to the same manager entity, but
it did not subscriber to the target, it probably does not want to
receive notifications, so we should not reuse that session
i.e. we should not try to search for a session with the same
transport address, security name etc.
[NOTE] A slightly different approach then in SNMP TMSM was chosen.
In TMSM session can be identified by transportAddress, securityName,
securityModel, and securityLevel while In Netconf there is a
possibility to have multiple logically separate sessions between a
manager and an agent with the same security and transport data
but e.g. different filters or one with need for notifications and
one which does not want to receive notifications.
Similarly to the SNMP TMSM Netconf Applications typically have no
knowledge of whether the session
that will be used to carry notifications was initially established due
to a subscription or due to call-home, and SHOULD NOT make any
assumptions based on knowing the direction of establishment of the session.
0.1.1.1 Session Lifecycle
Session setup including authentication is seen as a somewhat expensive
activity, so similarly to SNMP TMSM Netconf will allow the cost of
authentication to be amortized over potentially many notification transfers.
In order to avoid situations in which a session is continuously
setup and torn down, an inactivity timer is configured on the server.
By default the timeout interval is the same for all sessions (but can
be modified) and each session has its own timer. Upon expiration of the
inactivity timer, the connection is terminated, otherwise if a notification
is sent on the session, the timer is reset.
The session establishment procedure is as follows:
1) The NETCONF server initiates a session using a recognized
application protocol (SSH, Beep, SOAP, etc). In order to "activate"
this reverse behavior a new SSH subsystem may need to be defined.
This is for further study. In addition, the NE hosting the NETCONF
server must support both client and server modes in the case of SSH.
2) Client and server are authenticated according to the underlying
application protocol (e.g. SSH, BEEP)
3) If using BEEP, as described in [NETCONF-BEEP] either party may
initiate the BEEP session. Once this occurs, the assumption is that
both parties know their roles. At this point, the NETCONF client,
initiates NETCONF session establishment whether running SSH or BEEP.
0.2. Dependencies
Possible dependencies dependent on other parts of the draft:
- simple notifications (subscription based) without call-home
- mixed session capability
0.3. Capability Identifier
urn:ietf:params:xml:ns:netconf:callHomeNotification:1.0
0.4. New Operations
None
First information rpc ?
0.5 Modifications to Existing Operations
None
0.6 New Data Model
[TODO]
0.7 Interactions with Other Capabilities
Simple notifications and Call-home notifications use the same data model.
==============================================================================
who is the other side ?
transport mapping ?
SSH
netconf-reverse subsystem ?
agent should be able to act as client
serverkey, password
BEEP
BEEP profiles plus some indication of
role (either within protocol or outside)o
SOAP
Initial message needed ?
--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>