Cisco Cisco Transport Manager 9.1 Technical References

Page of 151
MTNM IMPLEMENTATION STATEMENT TEMPLATES AND GUIDELINES  
TMF 814Av3.0 
  TeleManagement Forum 2003 
98 
example has the same advantages as Example 1 and also allows the NMS to request userLabel 
uniqueness from the EMS as in Example 2. The main disadvantage is that the EMS domain 
cannot be subdivided into multiple subnetworks.  
 
 
Name: AcmeTech_3274293785 
NativeEMSName: AbcInc_3837 
UserLabel: AbcInc_3837 
EMS Domain 1 
 
Subnetwork B 
EMS Domain 2 
 
Name: AcmeTech_9393987589 
NativeEMSName: AbcInc_3837 
UserLabel: AbcInc_3837 
Name: AcmeTech_1993754343 
NativeEMSName: AbcInc_3837 
UserLabel: AbcInc_3837 
Subnetwork A 
Subnetwork C 
EMS Domain 2
 
 
Figure 4-3. SNC Naming Example 3: Same name for userLabel and nativeEMSName 
4.4  SNC State Representations – Modes 
The member companies comprising the MTNM team have varying opinions concerning the SNC 
state model, and agreement could not be reached on a single state representation model. 
Consequently, it was agreed to allow four different SNC state modes: 
Table 4-1. SNC State Representation Modes 
Mode 
Support for Pending state, and allow SNC 
conflicts on creation, i.e., shared Cross 
Connections (CCs) 
Allow for sharing of Active CCs 
 
 
 
 
 
 
 
 
The various modes in the above table are explained in the following subsections.  
4.4.1  Mode A 
In Mode A, the goal is for the EMS to represent only the current network configuration, to limit as 
much as possible sharing of resources (i.e., cross connections) among SNCs, and to attempt to 
have a one-to-one correspondence between the network configurations and the SNC 
configurations. This mode does not support the pending state. An SNC that does not have any 
non-shared, active CCs in the network is considered non-existent.  Consequently, when the last 
non-shared cross-connect of an SNC is deactivated in the network, the SNC is deleted by the 
EMS.