| This chapter covers the following topics: |
Large-scale network management means that an operational support system (OSS) can manage thousands of network elements (NEs). For instance, some of these systems can manage more than 10,000 NEs. An OSS consists of various systems, including an element-management system (EMS), a network-management system (NMS), and a performance-monitoring system, to ensure that the correct level of service is being provided to end users. An OSS supports daily network operations functions, such as adding electrical drops on a customer Multiservice Provisioning Platform (MSPP) private ring. An OSS uses fault, configuration, performance, and accounting information to ensure that the customer service is performing properly. This means, for example, that if a point-to-point Gigabit Ethernet (GigE) service begins to degrade, the OSS detects the start of this degradation and generates an alarm that a network problem exists. Large service providers typically implement their own unique OSS. The different systems that make up an OSS should have standard interfaces. This is necessary for the different OSS components to communicate with each other. For example, many network manufacturers offer an EMS with their MSPP. Service providers expect a vendor's EMS to integrate with their existing OSS using standard interfaces, such as Tele-Management Forum (TMF) 814. TMF 814 uses a set of defined Common Object Request Broker Architecture (CORBA)-based messages to enable an OSS to provide end-to-end management and provisioning of multivendor networks. For example, the TMF standard enables an NMS to create and manage end-to-end connections and devices across TMF-compliant EMSs. Large service providers, such as incumbent local exchange carriers (ILECs), desire certain functions as part of their OSS. Reasons to have these functions include being able to turn up new services for customers in a timely manner, to ensure that the performance of the service does not differ from the contractual agreement that is in place between the customer and the service provider, to properly update the network in case of an outage, and, of course, to stay competitive with other service providers. Examples of these functions are listed here: Flow-through provisioning This enables a new service order (for example, Ethernet point-to-point service) to flow through the OSS automatically, without manual intervention. Policy management This associates network events with policy rules established by the service provider. As an example, bandwidth-on-demand service might be associated with certain policy rules. A private ring customer might want to add bandwidth during certain weeks within the year. The customer network management (CNM) application might enable the customer to perform this through software application. The rules for adding the extra bandwidth can be defined within the policy rules, which would be automatically checked when the user attempts to add this bandwidth. In this case, policy rules defines when the additional bandwidth can be added and how long the bandwidth can be used. CNM CNM provides service provider customers the ability to monitor and activate their own services. The CNM application receives the information from other OSS components, such as the NMS, which, in turn, gets information from the EMS. This information, such as alarms from an MSPP OC-48 ring, is conveyed to the customer through the user interface on the customer's CNM application. High availability (HA) Ensuring that the OSS components have high availability is important in a service provider environment. The daily operations that support customer services, such as Ethernet over Synchronous Optical Network (SONET), must never stop. In many cases, a service-level agreement (SLA) is established between the customer and the service provider when services are sold. This contract contains metrics that can be measured and that the service provider must meet. A service provider might have to pay substantial fees to the customer if these metrics are not met. As a result, it is important that the multiple systems that make up an OSS be capable of recovering from a failure. Local and geographical redundancy is often used to accomplish this. Number of NEs The number of NEs, such as MSPPs, is important when deploying an OSS, such as an EMS. Most service providers require a single EMS server to support more than 1000 NEs. Data discovery An EMS must automatically discover the configuration of the NE, as well as all NEs that make up the network. For example, Cisco's optical EMS, called Cisco Transport Manager (CTM) automatically discovers 15454s on a ring when the EMS begins communicating with the Gateway Network Element (GNE). This discovery includes detecting changes in configurations on the NE, as well as discovering new NEs and interface cards. For example, when you insert a GigE card into an MSPP node, the EMS detects this event and updates its inventory in near-real-time. Alarm correlation and suppression Alarm correlation and suppression might exist in the EMS, or in the NMS, or even in the NE. In fact, alarm correlation and suppression might exist in all these systems. Alarm correlation detects problems quickly and helps identify the root problem faster. This allows quicker resolution with less effort and faster mean-time-to-repair (MTTR). OSS and network being synchronized The OSS should always represent the current state of the network. In other words, all the databases residing in an OSS (such as EMS and NMS) must be synchronized with the network. If this is not the case, applications such as CNM will not be useful.
|
