Cisco Cisco Transport Manager 9.1 Technical References
MTNM IMPLEMENTATION STATEMENT TEMPLATES AND GUIDELINES
TMF 814Av3.0
TeleManagement Forum 2003
103
are permitted on the specific NAD. Again, management of the FADs is outside the scope
of the MTNM interface.
of the MTNM interface.
A given resource with its NetworkAccessDomain parameter set to the empty string is intended to
be a “free” resource, i.e., any users can request only MTNM operation on the resource. A given
FAD can be defined to permit or refuse access to “free” resources.
be a “free” resource, i.e., any users can request only MTNM operation on the resource. A given
FAD can be defined to permit or refuse access to “free” resources.
Example use of NADs and FADs:
some resources are marked for the NetworkAccessDomain = ”owner23”
user44 is defined by the network administrator at the EMS to be associated with FAD =
“readonly” and to be given access to the “owner23” NAD. So, on the EMS side, “user44”
is granted readonly access to the TPs and SNCs belonging to NAD = “owner23”.
is granted readonly access to the TPs and SNCs belonging to NAD = “owner23”.
As another example, it is noted that the NAD/FAD mechanism can be used to define VPNs. In
fact, a given VPN could be seen as NAD, where the VPN operator can create/activate, and
deactivate/delete SNCs using only the routing resources belonging to such NAD/VPN (e.g., the
NMS could include the NAD identifier in the additionalCreationInfo parameter of the
createAndActivateSNC operation). At the EMS level, an SNC can be routed only on resources
(CTPs) which NetworkAccessDomain value is equal to such NAD/VPN (or is “free”, if the FAD
allows it).
fact, a given VPN could be seen as NAD, where the VPN operator can create/activate, and
deactivate/delete SNCs using only the routing resources belonging to such NAD/VPN (e.g., the
NMS could include the NAD identifier in the additionalCreationInfo parameter of the
createAndActivateSNC operation). At the EMS level, an SNC can be routed only on resources
(CTPs) which NetworkAccessDomain value is equal to such NAD/VPN (or is “free”, if the FAD
allows it).
4.8 Root Cause Alarm Indication
The Root Cause Alarm Indication (RCAI) feature allows the EMS to indicate a distinction between
raw (i.e., un-correlated) alarms, and root cause alarm indications.
raw (i.e., un-correlated) alarms, and root cause alarm indications.
The NMS can use the filtering capability of the Notification Service in conjunction with the RCAI
field to
field to
receive only raw alarms, i.e., alarms with the root cause alarm field set to FALSE,
receive only RCAIs, i.e., alarms with the root cause alarm field set to TRUE, or
receive both raw alarms and RCAIs.
receive only RCAIs, i.e., alarms with the root cause alarm field set to TRUE, or
receive both raw alarms and RCAIs.
The following suggestions are noted concerning usage of the RCAI:
1. If a single alarm persists but does not get correlated with any other alarm, two
notifications are expected (the raw alarm and the RCAI associated with the uncorrelated
raw alarm).
raw alarm).
2. There is no field in the RCAI or the raw alarms that points to the other correlated alarms.
The idea is to keep the interface as simple as possible and still allow for the reporting of
RCAIs.
RCAIs.
3. The raw alarms result in notifications immediately. The RCAI is generated after the
correlation window closes (the length of the correlation window is an implementation
issue for the EMS/NE vendor).
issue for the EMS/NE vendor).
4. RCAIs usually clear after all related raw alarms clear and stay cleared for a persistence
interval.
The above points are just suggestions concerning how the RCAI feature could work. Since these
suggestions relate to EMS implementation, they are not included in the requirements of the
Business Agreement document.
suggestions relate to EMS implementation, they are not included in the requirements of the
Business Agreement document.