Why Use an EMS?
| In this section, you learn about the main functions of an EMS. First, let's answer the question "Why do you need an EMS?" A well-designed EMS can have a profound impact on decreasing operational expenses, thereby increasing profitability. A well-designed EMS increases the efficiency of network resources and reduces the cost of operating the network by automating tasks and eliminating the need for manual intervention. A well-designed EMS includes capabilities for the following:
Using the ONS 15454 Element Management SystemCTM is an EMS that manages a full line of optical products, including the ONS 15454. CTM provides fault-, configuration-, performance-, and security-management (FCPS) functions for thousands of 15454s using a Java-based graphical user interface (GUI) and the TMF 814 interface to provide connectivity to a service provider's OSS. As an example, CTM enables a user to monitor alarms from all the 15454s in the network using an alarm table that displays the highest alarm severity, NE ID, probable cause, physical location, and date/time stamp. CTM uses an alarm table to identify standing conditions on the ONS 15454 and automatically moves the alarm to an alarm history table when it clears. CTM also enables a user to configure 15454 shelf, card, interface, and port parameters. The EMS functions that CTM supports include these:
CTM ArchitectureCTM uses a client/server architecture. This means that there are two software components to CTM: client software and server software. Figure 15-2 shows the architecture for CTM. Figure 15-2. CTM Architecture The client software runs on Windows-based computers or Solaris workstations; the server software uses a dedicated Sun Solaris server. The client uses CORBA as the application protocol to communicate to the CTM server. CTM also communicates to a higher-layer OSS by using the protocols CORBA, TL1, and SNMP. It is important to note that the CORBA interface manages all the services available on the MSPP, such as shared Ethernet services. CTM communicates to the MSPP and other Cisco optical NEs by using Transmission Control Protocol/Internet Protocol (TCP/IP) communications. This requires CTM to have IP connectivity to each MSPP to perform its management functions. Various types of networks support connectivity between CTM and the MSPPs. Typically, service providers use a network of routers and Ethernet switches. Figure 15-3 shows an example of a network connecting CTM to an MSPP ring. Figure 15-3. CTM Network Connectivity Example CTM needs to know only the IP address of the target MSPP, normally the Gateway Network Element (GNE); it is not concerned with how the IP packets get delivered to the MSPPs. Figure 15-3 shows how CTM connects to the GNE using a network of routers and switches. CTM must also communicate with the other MSPPs on the ring. These NEs are called External Network Elements (ENEs). CTM communicates directly with each ENE to carry out FCPS functions described earlier in this chapter. CTM uses the SONET data communications channel (DCC) link or the optical supervisory channel (OSC) for dense wavelength-division multiplexing (DWDM) to communicate with ENEs. CTM carries out a regular health poll check that continuously verifies that the communications path to each individual 15454 is available. If a disruption occurs on this path, CTM resynchronizes with the NE's alarm, inventory, and configuration state after connectivity is re-established. System Management CapabilitiesCTM is capable of monitoring its own health by generating thresholds on certain possible bottlenecks. This information can be used when a service provider wants to know when the CTM server is beginning to reach the maximum number of NE support with its current hardware configuration. A service provider using high availability can force the redundant server to be used while the active server is upgraded or replaced. CTM generates alarms for the following performance bottlenecks:
CTM also monitors and reports internal alarms for loss of communication to 15454s, memory backup failures, and login security violations. These alarms help the user to quickly isolate fault conditions within CTM. Fault-Management CapabilitiesCTM detects, isolates, and reports faults on MSPP rings. CTM uses these capabilities, collectively referred to as fault management, to maximize the availability of network services. CTM discovers and helps to localize the faults in a 15454 network. Figure 15-4 shows the alarm table that displays the faults generated by the 15454. Figure 15-4. CTM Alarm Table This alarm table is called an alarm browser, and each alarm is sorted by severity. If CTM is integrated into a higher-layer OSS through either TL1 or CORBA, these same alarms are forwarded to the OSS. CTM's fault-management capabilities include these:
Fault management and performance management are closely tied together. Certain performance-monitoring (PM) data is forwarded to the alarm window in CTM and onto CTM's northbound interfaces. This is important to ensure that the degradation of service is identified as quickly as possible. Performance management is discussed in the section "Performance-Management Capabilities." Configuration-Management CapabilitiesConfiguration management deals with network discovery and the provisioning of NE resources and services. CTM performs network discovery. This means that CTM can discover changes in the network autonomously. As an example, CTM discovers new 15454s and updates its database and user interfaces with the new network information; this can include both physical topology and logical circuits. As a result, the network map view in CTM dynamically updates with new 15454s if a new 15454 is added to an existing ring. In addition, CTM updates its database and user interfaces (for example, alarm table and inventory table) with changes such as inventory, alarms, service and common control cards, and protection mechanisms in any one of the 15454s in the network that might contain up to as many as 3000 NEs. CTM can configure 15454 shelves, cards, interfaces, and port parameters. A useful feature that CTM supports and service providers commonly use is scheduling tasks. Software downloads to update thousands of 15454s can be scheduled at a specific time. It is important to note that there are no management or service interruptions during the software-download process. Keep in mind, however, that downloading software to a 15454 only stores the software in memory; it does not activate it. The software must be activated one by one. CTM can also schedule other tasks, such as automatically backing up memory for the 15454s once a day. The Job Monitor table in CTM provides information about scheduled tasks. This table identifies the username of the person who entered a specific task, the time that the task began, and the time that the task ended. Performance-Management CapabilitiesA key aspect of performance management is monitoring SLAs. In many cases, a service provider has a contractual obligation to its customer to provide a consistent service delivery or a certain level of SLA. This service could be a point-to-point GigE service using an underlying MSPP ring to deliver this service. In some situations, customers require compensation in case of service delivery failure. Therefore, performance-management mechanisms must be accurate and traceable. Collecting, filtering, and correlating performance data collected from the NEs is part of performance management. The EMS aids in carrying out these tasks. Performance monitoring permits users to view the performance of a service on an MSPP ring. In a service-provider environment, the user can be either the service-provider customer or a network administrator within the service-provider organization. Several service providers enable the end customer to view this data and the status of their network, which is referred to as customer network management (CNM). This is being offered for traditionally TDM services, such as DS1 and DS3 services. Service providers are beginning to offer these same services with MSPP rings. An EMS should support CNM applications by collecting the appropriate metrics. As an example, an EMS can simply pass the raw PM data collected from the MSPP to higher-layer OSS components. Those components, in turn, pass this data to the CNM application. The EMS can massage this PM data by correlating, aggregating, and filtering it before passing it to a higher-layer OSS. Alternatively, the service provider might decide to simply pass the raw PM data directly to the CNM application and let the end customer analyze the data and create meaningful reports and graphs to help monitor the service provided by the service provider. Before collecting this data, the first step is to identify the data that the MSPP network must collect. This particular task should be allocated a lot of time to ensure that the correct information is collected from the network so that it can be used to help in accurately monitoring the service. Note The service provider can use other sources of information resident in another OSS to help determine the accuracy of the information collected. However, keep in mind that the NEs must have the data available to accomplish this. The ONS 15454 from Cisco provides detailed data that it makes available for CTM to collect. In addition, the 15454 can be set up so that autonomous messages can be sent to identify when certain performance thresholds are crossed. These are commonly referred to as threshold-crossing alerts (TCAs). For more information on TCAs, see Chapter 14, "Monitoring Multiple Services on a Multiservice Provisioning Platform Network." Because PM data must be collected to help the service provider validate that the service is operating correctly, the collecting intervals for PM data should not be missed. CTM recovers from any gaps in PM data collection that can occur from communication failure between CTM and the ONS 15454. In this event, when CTM detects a gap in the PM data, it retrieves the missing data from the PM history registers on the 15454. CTM can collect PM data from the 15454s. The user interface called the PM Query Wizard performs this task. The type of PM data collected is defined within this wizard and includes the following options:
CTM forwards all alarms, including TCA events that are received from the 15454s, to the CORBA northbound interface. In addition, CTM displays all TCAs in the Alarm Log Table. Figure 15-5 shows the PM Query Wizard. Figure 15-5. PM Query Wizard Security-Management CapabilitiesMore than ever, security management is a high priority for service providers. Security mechanisms must be built into the network along with the OSS components to provide effective security to protect revenue-generating services. Support for security management within the EMS is no exception. An EMS must be capable of preventing and detecting inappropriate use of network resources and services. CTM accomplishes this task by controlling user access and NE access, and keeping an audit of actions performed on the CTM server and on the NE. CTM implements this task at two levels:
CTM application-level security functions include the following:
The Audit Log table in CTM contains the following information:
Creating custom user security profiles allows CTM to be customized to a particular service provider environment. By default, CTM supports five user levels: SuperUser, SysAdmin, NetworkAdmin, Provisioner, and Operator. In today's environment, an EMS needs to provide further granularity in terms of which CTM functions a user can use. CTM supports this additional granularity. CTM defines a list of operations that can be assigned to a user. After a user profile is created, this profile can be assigned to a new CTM user. As an example, a user profile can be created to restrict a CTM user to provision circuits of only a certain size and to provision only Layer 2 Ethernet services. In addition, you can restrict users to carry out certain capabilities relating to Layer 2 Ethernet management. Any one of the following capabilities can be assigned to a custom user profile:
CTM also supports NE application security management. Centralized management of 15454 user accounts is one important NE security-management function. When an administrator creates a new user in CTM user, a username and password can be entered to give the user access to the 15454, thus eliminating the need for the administrator to create these accounts individually on each of the 15454s. This is a significant savings in time, especially when there are thousands of 15454s in the network. Another important NE application-level security function is uploading, storing, and viewing 15454 audit logs to enable tracking for all user actions that are performed locally at the NE. CTM logs all requests and any 15454 notifications, such as adding a new service card. This information can be used for auditing purposes later. The Audit Trail table in CTM displays ONS 15454 activities and violations related to security. This table contains the following fields:
High AvailabilityEMS high availability (HA) supports a protection scheme that can protect against a failure on the CTM server. This is an essential requirement with large service providers, especially incumbent local exchange carriers (ILECs). CTM supports HA at two levels: local redundancy and geographic redundancy. The local redundancy solution is implemented with two identical Sun servers to provide automatic failover in case the primary Sun server fails. CTM has software that is always running, called an HA agent, to determine when the primary Sun server is no longer operational. When the primary server fails, the HA agent activates the secondary Sun server and acts as the primary server. If this scenario occurs, all CTM clients automatically reconnect to the secondary server. This 1:1 protection configuration is nonrevertive. This means that the secondary server does not automatically switch back to the primary server when the primary server becomes operational. CTM also supports geographical redundancy, which consists of two 1:1 protected CTM servers that are located in two different sites. The strongest type of redundancy is a combination of local and geographical redundancy. Many service providers implement this type of redundancy to respond to local or regional catastrophes, such as hurricanes and tornadoes. Special software is used to keep the two CTM servers at the different sites synchronized. In addition, this software communicates with the HA agent at each site to determine when to fail over to the other site. CTM clients and the OSS higher-layer system interface to a virtual IP address so that the switching from the primary to secondary server is transparent. Figure 15-6 shows CTM using an HA configuration. Figure 15-6. CTM HA Architecture Ethernet ManagementWith the advent of new services being offered by MSPPs, it is necessary to provision and monitor these new services. As a result, it is important for the EMS to carry out these functions because a legacy OSS that has traditionally managed DS1, DS3, and SONET services cannot manage data services, such as shared Ethernet LAN services. The ONS 15454 implements shared Ethernet services, as discussed in Chapter 7. Shared Ethernet service can be provisioned by CTM either by the using CTM's user interfaces or by CTM's CORBA northbound interface. CTM uses a configuration wizard that guides you step-by-step in setting up a shared Ethernet LAN service. The wizard supports provisioning advanced QoS mechanisms that are supported by the 15454's Ethernet cards. Layer 1 ProvisioningCTM is capable of separating Layer 1 circuit provisioning from Layer 2 Ethernet service provisioning. This means that TL1 messages from an external system, such as a legacy OSS, can set up the cross-connects in the 15454s to create a point-to-point Ethernet circuit or to create the SONET circuits for a shared Ethernet ring. A shared Ethernet ring is a contiguous series of ML Ethernet cards interconnected by SONET circuits that is used to create an Ethernet LAN service so that multiple users can share the bandwidth on the MSPP ring. Figure 15-7 shows five ML cards interconnected by SONET circuits forming an Ethernet ring topology. Figure 15-7. Shared Ethernet Ring Using ONS 15454 ML Cards Layer 1 service provisioning is the first step required to set up a shared Ethernet service. ILECs use their existing legacy OSS to provision cross-connects on the MSPP to set up the SONET circuits. When this is accomplished, the EMS should be capable of discovering that the Ethernet cards have been stitched together with the series of cross-connects issued by the legacy OSS. CTM supports this discovery. Whenever CTM discovers a ring of Ethernet cards, CTM creates an entry in a table. This entry is called a Layer 2 topology. The next step required to create a shared Ethernet LAN service is to configure RPR on the individual ML cards. This is accomplished in CTM by simply highlighting the entry in the Layer 2 Topology table and then selecting Upgrade L2 Topology. This action tells CTM to issue Cisco IOS Software commands to the ML card to set up a RPR. At this point, a shared Ethernet ring topology is created using RPR; now VLANs can be set up. Note 15454 Ethernet cards can be added or removed in an Ethernet ring after a Layer 2 Ethernet service has been established, without affecting service. CTM uses a wizard to guide a user in adding or removing ML Ethernet cards. Layer 2 ProvisioningCTM uses another setup wizard called an L2 Service Wizard to create a virtual LAN (VLAN) on the Ethernet ring or point-to-point circuit. When using this wizard, you do not need to issue any specific command-line interface commands on the ML card. All VLAN and QoS provisioning is accomplished using the L2 Service Wizard. In summary, the following steps are required to set up a shared Ethernet LAN service on the 15454:
As part of setting up Step 1, CTM can provision bandwidth settings on a RPR. Figure 15-8 shows the bandwidth settings. Figure 15-8. Bandwidth Settings for Layer 2 Topology These settings are defined as follows:
The steps necessary in creating a Layer 2 service (Step 4 in the shared Ethernet LAN service setup process on the 15454) are as follows:
Note When setting the connection type to QinQ, CTM automatically configures L2-tunneling stp, cdp, and vtp, and mode Dot1Q-tunnel. In addition, Spanning Tree Protocol (STP) is not configurable and is always set to Disabled. The reason is that STP is not needed for RPR because RPR provides a much faster ring protection (less than 50 ms restoration time) than STP. Figures 15-9 through 15-12 show how to set up a Layer 2 service. Each user interface screen identifies which Layer 2 provisioning steps it accomplishes. Figure 15-9. Layer 2 Ethernet Wizard (Steps 2 and 3) Figure 15-10. Layer 2 Ethernet Wizard (Step 4) Figure 15-11. Layer 2 Ethernet Wizard (Steps 5 and 6) Figure 15-12. Layer 2 Ethernet Wizard (Step 7) After a L2 service is created, it is identified in the Layer 2 Ethernet service table in CTM, as shown in Figure 15-13. Figure 15-13. Layer 2 Ethernet Service Table At this point, the following parameters associated with the Layer 2 service can be modified:
It is also important to understand that Ethernet service drops can be added or deleted from existing Layer 2 services without affecting the existing services on the Ethernet ring. Integrating to an OSS Using the Northbound InterfaceAs explained earlier in this chapter, CTM provides a standard interface to integrate into a higher-layer OSS, such as an NMS. The interface addressed in this section is the CORBA Northbound Interface (NBI), also referred to as the CTM GateWay. The CTM NBI enables a service provider to integrate CTM with an existing OSS. This has recently become important because many large service providers, including many ILECs, have implemented or are implementing a new OSS to provision and monitor Layer 2 and Layer 3 services. It is worth noting that ILECs have traditionally used Telcordia legacy systems that are not capable of provisioning these new services. Figure 15-14 shows the northbound interfaces required on an EMS to support flow-through provisioning for Ethernet Layer 2 services. Figure 15-14. Separation of Layer 1 and Layer 2 The CORBA NBI conforms to TMF 814 with additional extensions, allowing the interface to provide Layer 2 Ethernet provisioning, fault, and inventory management. CTM's CORBA NBI supports most of the Ethernet management functions discussed in the previous section:
|
EAN: 2147483647
Pages: 140