On Network Management
Network Management refers to the activities, methods, procedures, and tools that pertain to the operation, administration, maintenance, and provisioning of networked systems.
Operation deals with keeping the network (and the services that the network provides) up and running smoothly. It includes monitoring the network to spot problems as soon as possible, ideally before users are affected.
Administration deals with keeping track of resources in the network and how they are assigned. It includes all the “housekeeping” that is necessary to keep the network under control.
Maintenance is concerned with performing repairs and upgrades — for example: when equipment must be replaced, when a router needs a patch for an operating system image or when a new switch is added to a network. Maintenance also involves corrective and preventive measures to make the managed network run “better”, such as adjusting device configuration parameters.
Provisioning is concerned with configuring resources in the network to support a given service. For example, this might include setting up the network so that a new customer can receive voice service.
FCAPS
A common way of characterizing network management functions is FCAPS—Fault, Configuration, Accounting, Performance and Security. FCAPS is the ISO Telecommunications Management Network model and framework for network management. FCAPS represents the management categories into which the ISO model defines network management tasks. It commonly is used for teaching network management functions.
Functions that are performed as part of network management accordingly include controlling, planning, allocating, deploying, coordinating, and monitoring the resources of a network, network planning, frequency allocation, predetermined traffic routing to support load balancing, cryptographic key distribution authorization, configuration management, fault management, security management, performance management, bandwidth management, route analytics and accounting management.
Data for network management is collected through several mechanisms, including agents installed on infrastructure (software that acts as an agent for a user or other program. Such “action on behalf of” implies the authority to decide which (and if) action is appropriate); synthetic monitoring (a simulation of typical user behavior or navigation through a website) that simulates transactions, logs of activity, sniffers (computer software or computer hardware that can intercept and log traffic passing over a digital network or part of a network) and real user monitoring (passive web monitoring technology that records all user interaction with a website). In the past network management mainly consisted of monitoring whether devices were up or down. Performance management today has become a crucial part of the IT team’s role, which brings about a host of challenges — especially for global organizations.
Note: Network management does not include user terminal equipment
Technologies and Solutions
- A large number of access methods exist to support network and network device management. Access methods include the SNMP, command-line interface (CLIs), custom XML, CMIP, Windows Management Instrumentation (WMI), Transaction Language 1, CORBA, NETCONF, and the Java Management Extensions (JMX).
- Schemas include the WBEM, the Common Information Model, and MTOSI among others.
SNMP
- Simple Network Management Protocol (SNMP) is a UDP-based network protocol. It is used mostly in network management systems to monitor network-attached devices for conditions that warrant administrative attention. SNMP is a component of the Internet Protocol Suite as defined by the Internet Engineering Task Force (IETF). It consists of a set of standards for network management, including an application layer protocol, a database schema, and a set of data objects.[1]
SNMP exposes management data in the form of variables on the managed systems, which describe the system configuration. These variables can then be queried (and sometimes set) by managing applications.
Overview and Basic Concept
In typical SNMP use, one or more administrative computers have the task of monitoring or managing a group of hosts or devices on a computer network. Each managed system (also called Slave) executes, at all times, a software component called an agent (see below), which reports information via SNMP to the managing systems (also called Masters).
Essentially, SNMP agents expose management data on the managed systems (Slaves) as variables (such as “free memory”, “system name”, “number of running processes”, “default route”). But the protocol also permits active management tasks, such as modifying and applying a new configuration. The managing system (Master) can retrieve the information through the GET, GETNEXT and GETBULK protocol operations, or the agent (which is on Slave) will send data without being asked using TRAP or INFORM protocol operations. SNMPv3 INFORM messages are valuable because they provide a reliable way for this data to be acknowledged by the management system, which is important because SNMP is a UDP-based protocol. Management systems can also send configuration updates or controlling requests through the SET protocol operation to actively manage a system. Configuration and control operations are used only when changes are needed to the network infrastructure. The monitoring operations are usually performed on a regular basis.
The variables accessible via SNMP are organized in hierarchies. These hierarchies, and other metadata (such as type and description of the variable), are described by Management Information Bases (MIBs).
The SNMP protocol operates in the Application Layer of the Internet Protocol Suite (Layer 7 of the OSI model). Typically, SNMP uses UDP ports 161 for the agent and 162 for the manager. The manager may send requests from any available source port to port 161 in the agent (destination port). The agent response will be sent back to the source port. The manager typically receives notifications (TRAPs and INFORMs) on port 162. The agent may generate notifications from any available port.
Basic Components
An SNMP-managed network consists of three key components:
- Managed device = Slave device
- Agent = software which runs on Slave device
- Network management system (NMS) = software which runs on Master
A managed device is a network node that implements an SNMP interface that allows unidirectional (read-only) or bidirectional access to node-specific information. Managed devices exchange node-specific information with the NMSs. Sometimes called network elements, the managed devices can be any type of device, including, but not limited to, routers, access servers, switches, bridges, hubs, IP telephones, computer hosts, and printers.
An agent is a network-management software module that resides on a managed device or network element. An agent has local knowledge of management information and translates that information to or from an SNMP specific form. Agents collect and store management information such as the number of error packets received by a network element.
A network management system (NMS) executes applications that monitor and control managed devices. NMSs provide the bulk of the processing and memory resources required for network management. One or more NMSs may exist on any managed network
The Internet Management Model
SNMP is part of the Internet network management architecture. This architecture is based on the interaction of many entities. As specified in Internet RFCs and other documents, a network management system comprises:
Managed objects — A managed object is a characteristic of something 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 MIB is 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 syntax notation is a language used to describe a MIB’s managed objects in a machine-independent format. Consistent use of a syntax notation allows different types of computers to share information. Internet management systems use a subset of the International Organization for Standardization’s (ISO’s) 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) — The 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 — Newly defined in SNMPv2, a party is a logical SNMPv2 entity 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 — A management protocol is used to convey management information between agents and NMSs. SNMP is the Internet community’s de facto standard management protocol.
Command Line Interface
A command-line interface (CLI) is a mechanism for interacting with a computer operating system or software by typing commands to perform specific tasks. This text-only interface contrasts with the use of a mouse pointer with a graphical user interface (GUI) to click on options, or menus on a text user interface (TUI) to select options. This method of instructing a computer to perform a given task is referred to as “entering” a command: the system waits for the user to conclude the submitting of the text command by pressing the “Enter” key (a descendant of the “carriage return” key of a typewriter keyboard). A command-line interpreter then receives, analyses, and executes the requested command. The command-line interpreter may be run in a text terminal or in a terminal emulator window as a remote shell client such as PuTTY. Upon completion, the command usually returns output to the user in the form of text lines on the CLI. This output may be an answer if the command was a question, or otherwise a summary of the operation.
The concept of the CLI originated when teletype machines (TTY) were connected to computers in the 1950s, and offered results on demand, compared to batch oriented mechanical punch card input technology. Dedicated text-based CRT terminals followed, with faster interaction and more information visible at one time, then graphical terminals enriched the visual display of information. Currently personal computers encapsulate all three functions (batch processing, CLI, GUI) in software.
The CLI continues to co-evolve with GUIs like those provided by Microsoft Windows, Mac OS and the X Window System. In some applications, such as MATLAB and AutoCAD, a CLI is integrated with the GUI, with the benefits of both.
Usage
A CLI is used whenever a large vocabulary of commands or queries, coupled with a wide (or arbitrary) range of options, can be entered more rapidly as text than with a pure GUI. This is typically the case with operating system command shells. Also, some computer languages (such as Python, Forth, LISP and many dialects of BASIC) provide an interactive command-line mode to allow for experimentation.
CLIs are often used by programmers and system administrators, in engineering and scientific environments, and by technically advanced personal computer users. CLIs are also popular among people with visual disability, since the commands and feedbacks can be displayed using Refreshable Braille displays.
A program that implements such a text interface is often called a command-line interpreter or shell. Examples include the various Unix shells (sh, ksh, csh, tcsh, bash, etc.), the historical CP/M, and MS-DOS/IBM-DOS’s COMMAND.COM, the latter two based heavily on DEC’s RSX and RSTS CLIs. (DOS, i.e. MS-DOS/IBM-DOS, is actually is based on CP/M, DOS having been originally written as a substitute for CP/M-86 when its release was delayed.)
In November 2006, Microsoft released version 1.0 of Windows PowerShell (formerly codenamed Monad), which combined features of traditional Unix shells with their object-oriented .NET Framework. MinGW and Cygwin are open-source packages for Windows that offer a Unix-like CLI. Microsoft provides MKS Inc.’s ksh implementation MKS Korn shell for Windows through their Services for UNIX add-on.
The latest versions of the Macintosh operating system are based on a variation of Unix called Darwin. On these computers, users can access a Unix-like command-line interface called Terminal found in the Applications Utilities folder. (This terminal uses bash by default.)
MTOSI
Multi-Technology Operations System Interface (MTOSI) is a standard for implementing interfaces between OSSs. Service providers (carriers) use multiple Operational Support Systems (OSS) to manage complex networks. Since the various parts of the network must interact, so must the OSSs. Interaction is standardized by the Telemanagement Forum (TM Forum). The TMF NGOSS provides a set of reference models that aid in analyzing and designing next generation BSS and OSS solutions that may utilize the MTOSI interface specifications.
The MTOSI specifications are produced by the TM Forum mTOP program.
MTOSI standard is a unified open interface that can be used among multiple types of management systems to provide network and service management.
MTOSI standard covers all communication technologies (from layer 1, e.g., SONET/SDH, through higher layer technologies such as VoIP).
MTOSI facilitates application-to-application inter-working, reduces time to deployment, and lowers the cost of ownership of systems.
Current management and support system implementations employ diverse middleware technologies, a reality that is not likely to change in the immediate future. To be widely adopted, MTOSI cannot mandate specific middleware technologies for its implementation. Therefore the MTOSI interfaces are sufficiently abstract to be middleware neutral, yet rigorous enough that vendors can map them quickly to their middleware of choice. The CCV is the common middleware required to implement MTOSI.
CCV is a middleware abstraction that allows MTOSI interfaces to be bound to different middleware technologies as needed. By exploiting the expressive power of Web Services Description Language, MTOSI interfaces are composed of logical and physical definitions.
MTOSI standard offers a number of unique business advantages as well as advantages applicable to any well-designed and well-supported interface standard
MTOSI provides a standard interface between different systems for fulfillment and assurance functionality. In effect different instances of the same interface are reused at different reference points. Benefit: Knowledge can be re-used in the design of systems.
MTOSI uses XML (eXtended Mark-Up Language) based messaging. Benefit: XML technology is widely accepted and used technology.
MTOSI provides rules for versioning and for vendor extensions to the XML messages. Benefit: When MTOSI is deployed, the server and consumer application ends of the interfaces can be upgraded independently. Also, when several vendors’ equipment is deployed, the proprietary extensions are managed in a consistent manner.
MTOSI uses standard communication patterns to support business activities that can be implemented by a range of IT platforms and transport protocols. Benefit: The underlying platform can be changed the without propagating the change to the applications.
MTOSI allows service providers to implement management and support systems quickly. For example, without MTOSI, different EMS providers would need to define and agree upon a common interface (on a pair-wise basis), build the interface and then do interoperability testing. Benefit: MTOSI lowers the time and costs needed to integrate management and support system software from different suppliers.
MTOSI is designed to support service provider requirements for an open systems environment. Benefit: This allows service providers to more easily deploy management and support systems from multiple vendors and to replace existing ones. This increase in choice creates a more competitive environment for service providers, allowing them to choose products that best fit their functional and financial needs.
MTOSI encourages system integrators to pre-integrate products that are MTOSI-compliant. Benefit: This results in lower up-front costs and faster deployment for service providers.
MTOSI helps carriers to avoid wholesale replacements of legacy systems and instead allows them to introduce and integrate point applications that can address new solutions and services. Benefit: Allows a service provider to preserve its investment in legacy systems while still addressing the need to manage new technologies and services.
EMS
An Element Management System (EMS) consists of systems and applications that are concerned with managing network elements (NE) on the network element management layer (NEL) of the Telecommunication Management Network model.
As recommended by ITU-T, the Element Management System’s key functionality is divided into five key areas — Fault, Configuration, Accounting, Performance and Security (FCAPS). Portions of each of the FCAPS functionality fit into the TMN models. On the northbound the EMS interfaces to Network Management Systems and or Service Management Systems depending on the deployment scenario. Southbound the EMS talks to the devices.
An element management system (EMS) manages one or more of a specific type of telecommunications network element (NE). Typically, the EMS manages the functions and capabilities within each NE but does not manage the traffic between different NEs in the network. To support management of the traffic between itself and other NEs, the EMS communicates upward to higher-level network management systems (NMS) as described in the telecommunications management network (TMN) layered model. The EMS provides the foundation to implement TMN–layered operations support system (OSS) architectures that enable service providers to meet customer needs for rapid deployment of new services, as well as meeting stringent quality of service (QoS) requirements. The TeleManagement Forum common object request broker architecture (CORBA) EMS–to–NMS interface heralds a new era in OSS interoperability by making the TMN architecture a practical reality.
Various markets which can be managed through the EMS interfaces
- Cable Telephony Media Gateway
- Media Gateway
- Soft Switch
- Video Compression Technology Provider
Wireless Broadband Provider
Route Analytics
Route analytics is an emerging network monitoring technology specifically developed to analyze the routing protocols and structures in meshed IP Networks. Their main mode of operation is to passively listen to the Layer 3 routing protocol exchanges between routers for the purposes of network discovery, mapping, real-time monitoring and routing diagnosticsThe main features of a route analytics system are:
- Real-time and accurate discovery of routed networks
- Computation of Layer 3 network routing topology and visualization of primary and redundant paths
- Visibility into current and historical routing information (e.g. LSAs, AS Externals)
- Detection of routing events, failures or protocol anomalies (for example route flapping) impacting paths or reachability
- Ability to handle multiple protocols’ routing such as OSPF, ISIS, or BGP
Vendors
The Route analytics technology is being offered by a handful of vendors today who are addressing a growing market niche consisting of larger enterprises and carriers. These vendors include Packet Design, Alcatel-Lucent, Netcordia, Solana Networks and Iptivia. Hewlett Packard also offers a licensed version from Packet Design as an integrated option to its HP Network Node Manager.