Cisco Cisco Prime Optical 10.3 Technical References
MTNM IMPLEMENTATION STATEMENT TEMPLATES AND GUIDELINES
3 Non-Functional Interoperability
Statements (NIS)
The EMS may have trouble fulfilling a getLength request when the data is scattered across a number of systems
and its volume is not readily measurable and/or where the volume of data available for transfer may change after
the request and during the iteration process. Under these circumstances it is acceptable for the EMS to throw a
CAPACITY_EXCEEDED exception. In order to assist the NMS, the EMS vendor shall state clearly in which
cases the getLength operation may throw the CAPACITY_EXCEEDED exception.
and its volume is not readily measurable and/or where the volume of data available for transfer may change after
the request and during the iteration process. Under these circumstances it is acceptable for the EMS to throw a
CAPACITY_EXCEEDED exception. In order to assist the NMS, the EMS vendor shall state clearly in which
cases the getLength operation may throw the CAPACITY_EXCEEDED exception.
style in document.
This section covers interoperability issues related to the non-functional aspects of the MTNM interface.
3.1 Iterator
Implementation
Issues
The EMS vendor should state how many iterators can be open at any one point in time. The MTNM team has
agreed that 10 is a reasonable number. Any timer behavior associated with an iterator should be stated, e.g., the
EMS automatically deletes an iterator if it has not been used in the last 5 minutes.
agreed that 10 is a reasonable number. Any timer behavior associated with an iterator should be stated, e.g., the
EMS automatically deletes an iterator if it has not been used in the last 5 minutes.
3.2 Timing
Issues
None of the MTNM documents address timing. An EMS and NMS could follow all the MTNM standards as well
as an agreed to interoperability statement (such as the one suggested in Section 2 of this document) and still fail
to interoperate because of timing issues.
as an agreed to interoperability statement (such as the one suggested in Section 2 of this document) and still fail
to interoperate because of timing issues.
For example, if the NMS uses are large value of how_many in the next_n operation, the EMS may take too long
to prepare the result, leading to a CORBA message timeout. So, the NMS and EMS need to agree on a
reasonable range of values for how_many. Another example of a potential timeout would be SNC establishment.
to prepare the result, leading to a CORBA message timeout. So, the NMS and EMS need to agree on a
reasonable range of values for how_many. Another example of a potential timeout would be SNC establishment.
In general, the maximum time an NMS is designed to wait for a response to a particular type operation request
should be greater than expected maximum time the EMS takes to fulfill the operation request. It is suggested
that the EMS vendor provide the following table as guidance:
should be greater than expected maximum time the EMS takes to fulfill the operation request. It is suggested
that the EMS vendor provide the following table as guidance:
Table Error! No text of specified
-83. Operations Response Times and Timeouts
Operation Type
Maximum Expected EMS
Response Time
Suggested Timeout
Setting for NMS
Comments
Iterators (if various iterators
have different
characteristics, then
multiple entries in this table
are needed)
have different
characteristics, then
multiple entries in this table
are needed)
A Maximum Value for
how_many should be
provided
how_many should be
provided
Data Retrieval of a Data
Structure for a Second-
Level Object
Structure for a Second-
Level Object
Other operations can be
listed on a case-by-case
basis (createAndActivate),
or groups of operations that
listed on a case-by-case
basis (createAndActivate),
or groups of operations that
TMF814Av3.1
TeleManagement Forum 2007
Page 85 of 115