What is the name of the computer that queries agents and gathers responses by sending messages?

Fault management

The NMS manages every alarm, alerts, events and status information forwarded by the SLTE and the PFE including equipment fault, transmission fault (e.g. loss of signal (LOS) and loss of frame (LOF) alarms), transmission degradation alert, optical degradation alert, electrical degradation alert… Other items may be generated by the NMS to raise threshold crossing alert based on repeater (REP), branching unit (BU), ROADM measures. And some NMS system alerts may be raised by the NMS on its own operations like data quota management.

Those items, often called alarms, are managed by the NMS in current alarm list and historical alarm bases. The NMS offers various facilities to user: search, filtering, audible alert, acknowledgment, export, print, archive/retrieve, quota, backup/restore, purge…

Those root items coming from equipment are used by the NMS to provide various system functions to the user.

2.3 Problems with current interfaces for network management

Current network management systems rely heavily on forms in their user interfaces. Forms are easy the develop and customize. They are usually simple to understand and to start using. But complex systems require so many forms that screens quickly become cluttered with dozens of overlapping forms (windows), and window-management becomes a real burden (Figure 2). Operators need to learn the names of all the forms. The problem is often aggravated by the fact that unrelated forms look similar, while there is no visual connection between related forms. The design of forms could be substantially improved in terms of meaningful layout, consistency, and efficient utilization of screen space. The user interfaces of current systems reflect the intricacies of the network hardware components but provide little support for guiding users through tasks. Each task typically consists of a sequence of forms that need to be filled. No feedback is given as to how much of the task has been completed and how much of the task remains to be done. This is important since operators often have to simultaneously work on several tasks and handle emergency calls as they come. There is a clear need for the ability to group windows together, iconize them and re-open them simultaneously.

Data remains mainly displayed in tables and lists; some of the data is even in incomprehensible hexadecimal format. Better visualization techniques are needed. Many network management systems provide area maps showing the location of the remotes and lines indicating the communication links. In one system that we saw, remotes were represented as dots on a map of the U.S., and the operator could zoom in and out. These maps were seldom used by operators because the drawing of the map was too slow and the information shown was not useful enough. The latter is especially true for satellite networks which have a star topology, i.e., each remote is linked to the hub and it communicates with other remotes through the hub only.

Operators are given written instructions (suggested ports and inroutes) which are the results of studies of performance data and planning information, always done off-line. The instructions are updated on an irregular basis and operators sometimes have to take decisions based on outdated information. Thus, the process of selection of hardware components is often one of trial and error: configurations are used as long as problems are not encountered. There is a need for the user interface to provide this information on-line so that decisions can be based on current information.

8.1.3 Management Protocols

Most network management systems use a master-slave sort of relationship between a manager and the agents managed by the manager. The manager queries the agent to obtain the status of parameters in the network element (called the get operation). For example, the manager may query the agent periodically for performance monitoring information. The manager can also change the values of variables in the network element (called the set operation) and uses this method to effect changes within the network element. For example, the manager may use this method to change the configuration of the switches inside a network element such as a multidegree ROADM. In addition to these methods, sometimes it is necessary for the agent to initiate a message to its manager. This is essential if the agent detects problems in the network element and wants to alert its manager. The agent then sends a notification message to its manager. Notifications also take the form of alarms if the condition is serious and are sometimes called traps.

There are multiple standards relating to network management and perhaps thousands of acronyms describing them. Here is a brief summary. In most cases, the physical management interface to the network element is usually through an Ethernet or RS-232 serial interface.

The Internet world uses a management framework based on the simple network management protocol (SNMP). SNMP is an application protocol that runs over a standard Internet Protocol stack. The manager communicates with the agents using SNMP. The information model in SNMP is called a management information base (MIB).

In North America, the carrier world has been using a simple textual (or ASCII) command and control language called Transaction Language-1 (TL-1). TL-1 was invented in the days when the primary means of managing network elements was through a simple terminal interface using textual command sets. However, it is still widely used today and will probably remain for a while, as many of the existing legacy management systems still mainly support only TL-1.

Another management framework for the carrier world is called the telecommunications management network (TMN). TMN defines a hierarchy of management systems and object-oriented ways to model the information to be managed, and also specifies protocols for communicating between managers and their agents. The protocol is called the common management information protocol (CMIP), which usually runs over an open systems interconnection (OSI) protocol stack; the associated management interface is called a Q3 interface. Adaptations have also been defined for running CMIP over the more commonly used TCP/IP protocol stack. The specific object model is based on a standard called guidelines for description of managed objects (GDMO). The first two concepts of TMN—namely, the hierarchical management view and the object-oriented way of modeling information—are widely used today, but the specific protocols, interfaces, and object models defined in TMN have not yet been widely adopted, mostly because of the perceived complexity of the entire system.

Yet another management framework that allows network elements from different vendors to come with their own element management systems is based on the common object request broker (CORBA) model. CORBA is a software industry standard developed to allow diverse systems to exchange and jointly process information and communicate with each other. This framework uses CORBA as the interface between the element management systems and a centralized network management system.

5.1.3 Lightweight Network Management

Based on earlier discussed network management systemSNMS[42], a lightweight and transparent management framework for TinyOS sensor networks, called L-SNMS is designed in [48]. L-SNMS minimizes the overhead of management functions including memory usage overhead, network traffic overhead, and integration overhead. Remote Procedure Call (RPC) in network management allows the PC to access the functions and variables of a statically-compiled program on a wireless embedded device at runtime. Figure 11 shows the generation process of an RPC during compile time, and the Remote Procedure Calls during runtime. The compile time actions are supported by TinyOS, which adds the RPC function stub to the SNMS server. The Lightweight network management tools have been designed and used in an air-dropped wireless sensor network for volcano hazard monitoring [38].

Performance Management

Network operators are faced with challenges when it comes to understanding those possible artifacts which may cause a decrease in performance experienced by subscribers. When a network is architected, the operator must make decisions on how the service provisioned will be “oversubscribed.” What this means is that an operator must make a capital decision on how much capacity will be available to all subscribers within the network compared to how much bandwidth is “offered” or “provisioned.” The concept of oversubscription has been around for generations, even well outside of the telecommunications world. For example, when a road is to be built a decision has to be made on how many lanes need to be provided, and in Atlanta, GA, with all the traffic there is never enough. However, it would not be prudent of the local governing authority to build a road such that there is never congestion. The governing authority just needs to continually monitor the situation such that if the situation becomes overbearing then the road must be expanded or new roads constructed. Planning is crucial because construction work takes time and taking too much time could present a series of other challenges and delays in completing the road.

The same concept must be employed by a network operator. A network must be continually monitored at all potential congestion points to determine traffic utilization. Many times operators find their highest network utilization starts around 7:00 p.m. and does not begin to taper off until much later into the evening, around midnight. People are home from work, school, and sporting activities and looking to watch the news or browse the Internet or possibly do some gaming. Performance management is the key to ensuring the network is performing at all times across the defined set of “oversubscription” levels the operator is expecting.

The performance management activities must be reviewed on a regular basis and consistently compared during each review period. Changing how data are reviewed can only mask certain data unless historical information is available to show trends. This exercise allows an operator to plan accordingly in understanding when additional capacity is required at different points in the network. Many times the addition of capacity could take a lot of time and money. This importance of tracking capacity utilization, predicting how usages may change over the next 6 months, must be part of performance management. The trick is to provide enough capacity so that subscribers don’t notice congestion, while not overprovisioning the network, which will raise cost for no offsetting revenue. Chapter 8 discusses oversubscription and the effect of quality of service (QoS) management. It suggests some good-practice numbers you might consider.

An FTTx NMS/EMS typically supports the following performance management functions:

Give the status of platform resources such as CPU usage and memory usage.

Gather real-time per-port or per-service transmit/receive frame and byte counts. For example, a service provider may want to verify that its business data subscriber can actually reach the contracted bandwidth throughput. Many FTTx NMS/EMS systems now support 15-min and 1-day performance management counters at the ONT subscriber ports.

Gather aggregate OLT data usages—service providers will need to know the percent data usages of each PON or network interface port over a day, a week, or a month. It is also desirable to have such PM data on a per-service basis.

Modern deep packet inspection (DPI) technologies make it possible to report subscriber data usage across selected URLs, protocols, and other user-defined metadata fields. These collected metadata statistics can be used to optimize network usage based on applications, lawful interception (e.g., within emails), or for marketing or research purposes.

Controlling Access via SNMP

SNMP is a protocol used by network management systems to monitor and control network-attached devices. Ciscoworks, HP Openview, and other management stations all use SNMP.

SNMP access can be granted on a network device in two ways—read-only and read-write. Read-only access allows the management station to poll the device for statistics and other information, but it does not allow anything to be changed. Read-write access allows the management station to make changes to the configuration of the device.

It's obviously a good idea to make sure you trust the devices allowed to make changes to your configuration, but some versions of SNMP use only a simple shared password to permit access. To make this more secure, an ACL can be applied, which limits the source IP addresses that can use SNMP.

The following example limits read-write SNMP access to a management virtual local area network (VLAN) (10.100.20.0/24) and a single host (10.2.2.2). This uses a numbered standard ACL that limits access based on the source of the SNMP request. An extended ACL can't be used with SNMP because the destination of the request will always be the router itself.

access-list 99 permit 10.100.20.0 0.0.0.255

access-list 99 permit host 10.2.2.2

!

snmp-server community MySecret RW 99

9.1 Threats and Issues

SNMPv1 recognized the need for security of the network management system. Because of technology limitations at the time, SNMPv1 only specified clear-text reusable passwords, which are known as community strings. A given managed device will typically support several concurrent community strings, each having its own permissions. In SNMPv1, a given community string can have either read-only permission or read-write permission. SNMPv1 does not support multiple views or stronger authentication. If an adversary were able to discover the community string of some network device, the adversary could then change the configuration of that network device and cause significant damage. For example, if the device were a packet filtering router, the adversary might be able to remove or alter packet filters critical to the security policy of the network operator. As passive attacks became more widespread on the Internet, the limitations of the community string approach became more widely understood. This caused many operators to configure their SNMP agents to only provide read-only access, which limited the operator’s ability to use SNMP to actually manage the device remotely.

MPLS-TP Supports Both Static and Dynamic Signaling

MPLS-TP can operate in two modes:

Through a network management system for static provisioning of primary and backup connections with fast protection switching. Provisioning a static MPLS-TP connection typically involves selecting the port and VLAN (if the interface is Ethernet) and manually assigning incoming and outgoing labels for the connection. This action is independently performed on both ends of the connection.

Through a G-MPLS control plane for dynamic provisioning of primary and recovery paths with fast reroute.

To meet transport-network compatibility requirements, MPLS-TP restricts LSPs to bi-directional paths that are co-routed, meaning both directions follow the same path.

13.5.1 SNMP Overview

As specified in Internet RFCs and various best-practices documents, a network management system comprises the following:

Network elements. Hardware devices such as computers, routers, and terminal servers that are connected to form networks.

Agents. Software modules that reside in network elements. They collect and store manage-ment information, such as the number of error packets received by a network element.

Managed objects. Characteristics of a network element that can be managed. For example, a list of currently active TCP circuits in a particular host computer is a managed object. Managed objects differ from variables, which are particular object instances. Using our example, an object instance is a single active TCP circuit in a particular host computer. Managed objects can be scalar (defining a single object instance) or tabular (defining multiple, related instances).

Management information base (MIB). A collection of managed objects residing in a virtual information store. Collections of related managed objects are defined in specific MIB modules.

Syntax notation. A language used to describe an MIB’s managed objects in a machine-independent format. Consistent use of a syntax notation allows various types of computers to share information. Internet management systems use a subset of the International Organization for Standardization (ISO) Open System Interconnection (OSI) Abstract Syntax Notation (ASN.1) to define both the packets exchanged by the management protocol and the objects that are to be managed.

Structure of Management Information (SMI). Defines the rules for describing management information. The SMI is defined using ASN.1.

Network management stations (NMSs). Sometimes called consoles, these devices execute management applications that monitor and control network elements. Physically, NMSs are usually engineering workstation-caliber computers with fast CPUs, megapixel color displays, substantial memory, and abundant disk space. At least one NMS must be present in each managed environment.

Parties. Defined in the SNMPv2 standards as logical SNMPv2 entities that can initiate or receive SNMPv2 communication. Each SNMPv2 party comprises a single, unique party identity, a logical network location, a single authentication protocol, and a single privacy protocol. SNMPv2 messages are communicated between two parties. An SNMPv2 entity can define multiple parties, each with different parameters. For example, different parties can use different authentication and/or privacy protocols.

Management protocol. Used to convey management information between agents and NMSs. SNMP is the Internet community’s de facto standard management protocol.

The SNMP protocol operates at the application layer (Layer 7) of the OSI model. It specifies five core Protocol Data Units (PDUs) as follows:

GET REQUEST. Used to retrieve a piece of management information.

GETNEXT REQUEST. Used iteratively to retrieve sequences of management information.

GET RESPONSE. Used by the agent to respond with data to get and set requests from the manager.

SET REQUEST. Used to initialize and make a change to a value of the network element.

TRAP. Used to report an alert or other asynchronous event about a managed subsystem.

In SNMPv1, asynchronous event reports are called traps, whereas they are called notifications in later versions of SNMP. In SMIv1 MIB modules, traps are defined using the TRAP-TYPE macro; in SMIv2 MIB modules, traps are defined using the NOTIFICATION-TYPE macro.

Additional PDUs were added in SNMPv2, as follows:

GETBULK REQUEST. A faster iterator used to retrieve sequences of management information.

INFORM. Similar to a trap, but the receiver must respond with an acknowledgment RESPONSE message.

REPORT. Definable by an administrative framework.

Interactions

Interactions within network management may include interactions among components of the management system; between the network management system and network devices; and between the network management system and the OSS.

If there are multiple network management systems, or if the network management system is distributed or hierarchical, then there will be multiple components to the management system. The network architecture should include the potential locations for each component and/or management system, as well as the management data flows between components and/or management systems. The interactions here may be in the form of SNMP or CMIP/CMOT queries/responses, CORBA, HTTP, file transfers, or a proprietary protocol.

Part of network management inheres in each managed network device, in the form of management data (e.g., MIB variables) and software that allows access and transport of management data to and from the management system (e.g., SNMP agent software). Therefore, interactions between network management components (particularly monitoring devices) and managed network devices can also be considered here. We may choose to consider all of the managed network devices, depending on how many of them are expected in the network; however, we usually do not consider all managed devices in the network, as there can be quite a large number of them. As we discussed in flow analysis (Chapter 5), the devices that are most likely to be considered are those that interact with several users, such as servers and specialized equipment. Interactions here are likely to be in the form of SNMP or CMIP/CMOT queries/responses.

If your environment includes an OSS, there will likely be some interactions between network management and the OSS, for flow-through provisioning, service management, and inventory control. The network management architecture should note where the OSS would be located, which components of the network management system will interact with the OSS, and where they will be located in the network. Interactions here are likely to use CORBA, but may use SNMP or HTTP (see dependencies below).