Download Chapter 12: Network Management and more Exercises Computer Systems Networking and Telecommunications in PDF only on Docsity!
Chapter 12: Network Management
Jian Ren and Tongtong Li, Michigan State University
Introduction 2 OSI Network Management Model.. 3 Network Management Layers.... 4 ISO Network Management Functions 6 Configuration Management..... 6 Fault Management.......... 6 Security Management........ 7 Accounting Management....... 7 Performance Management...... 7 Network Management Protocols 7 SNMP/SNMPv1........... 8 SNMPv2................ 13 SNMPv3................ 15 Remote Network Monitoring (RMON) 23 Network Management Tools 24 Network Monitors.......... 25
Network Scanners........... 25 Packet Filters............. 26 Wireless Network Management 26 Cellular Networks........... 27 Location Management for Cellular Networks............... 28 Policy-based Network Management 29 What Is a Policy?.......... 30 Benefits of PBNM.......... 31 Architecture of a PBNM System.. 31 Conclusion 32 Glossary 33 Acknowledgements 34 Acronyms 37
Abstract: The continuous growth in scale and diversity of computer networks and network components has made network management one of the most challenging issues facing network administrators. It has become impossible to carry out network management functions without the support of automated tools and applications. In this chapter, the major network management issues, including network management requirements, functions, techniques, security, some well- known network management protocols and tools, will be discussed. Location management for the wireless cellular networks will also be briefly described. Finally, policy-based network management, which is a promising direction for the next generation of network management, will be briefly described. Keywords: network management, Simple Network Management Protocol (SNMP), Struc- ture of Management Information (SMI), Management Information Base (MIB), Remote Network Monitoring (RMON), network monitor, network scanner, packet filter, policy-based network man- agement (PBNM)
1 Introduction
Network management, in general, is a service that employs a variety of protocols, tools, applications, and devices to assist human network managers in monitoring and controlling of the proper network resources, both hardware and software, to address service needs and the network objectives. When transmission control protocol/internet protocol (TCP/IP) was developed, little thought was given to network management. Prior to the 1980s, the practice of network management was largely proprietary because of the high development cost. The rapid development in the 1980s towards larger and more complex networks caused a significant diffusion of network management technologies. The starting point in providing specific network management tools was in Novem- ber 1987, when Simple Gateway Monitoring Protocol (SGMP) was issued. In early 1988, the Internet Architecture Board (IAB) approved Simple Network Management Protocol (SNMP) as a short-term solution for network management. Standards like SNMP and Common Management In- formation Protocol (CMIP) paved the way for standardized network management and development of innovative network management tools and applications. A network management system (NMS) refers to a collection of applications that enable network components to be monitored and controlled. In general, network management systems have the same basic architecture, as shown in Figure 12.1. The architecture consists of two key elements: a managing device, called a management station, or a manager and the managed devices, called management agents or simply an agent. A management station serves as the interface between the human network manager and the network management system. It is also the platform for man- agement applications to perform management functions through interactions with the management agents. The management agent responds to the requests from the management station and also provides the management station with unsolicited information. Given the diversity of managed elements, such as routers, bridges, switches, hubs and so on, and the wide variety of operating systems and programming interfaces, a management protocol is critical for the management station to communicate with the management agents effectively. SNMP and CMIP are two well-known network management protocols. A network management system is generally described using the Open System Interconnection (OSI) network management model. As an OSI network management protocol, CMIP was proposed as a replacement for the
Application Presentation Session Transport Network Data Link Layer 1 Physical
Layer 2
Layer 3
Layer 4
Layer 5
Layer 6
Layer 7
Network Interface and Hardware
TCP/UDP Internetwork
Application
OSI Model (^) TCP/IP Model
Not presented in this model
Figure 12.2: The OSI and TCP/IP Reference Models
- Functional Model comprises five functional areas of network management, which are dis- cussed in more detail in the next section.
1.2 Network Management Layers
Two protocol architectures have served as the basis for the development of interoperable communi- cations standards: the International Organization for Standardization (ISO) OSI reference model and the TCP/IP reference model, which are compared in Figure 12.2 [3]. The OSI reference model was developed based on the promise that different layers of the protocol provide different services and functions. It provides a conceptual framework for communications among different network elements. The OSI model has seven layers. Network communication occurs at different layers, from the application layer to the physical layer; however, each layer can only communicate with its adjacent layers. The primary functions and services of the OSI layers are described in Table 12.1. The OSI and TCP/IP reference models have much in common. Both are based on the concept of a stack of independent protocols. Also, the functionality of the corresponding layers is roughly similar. However, the difference does exist between the two reference models. The concepts that are central to the OSI model include service, interface, and protocol. The OSI reference model makes the distinction among these three concepts explicit. The TCP/IP model, however, does not clearly distinguish among these three concepts. As a consequence, the protocols in the OSI model are better hidden than in the TCP/IP model and can be replaced relatively easily as the technology changes. The OSI model was devised before the corresponding protocols were invented. Therefore,
Table 12.1: OSI Layers and Functions Layer Functions Application • Provides the user application process with access to OSI facilities
Presentation
- Responsible for data representation, data compression, data encryption and decryption
- Ensures communication between systems with different data representation
- Allows the application layer to access the session layer services Session
- Allows users on different machines to establish sessions between them
- Establishes and maintains connections between processes, and data transfer services
Transport
- Establishes, maintains and terminates connections between end systems
- Provides reliable, transparent data transfer between end systems, or hosts
- Provides end-to-end error recovery and flow control
- Multiplexes and de-multiplexes messages from applications
Network
- Builds end-to-end route through the network
- Datagram encapsulation, fragmentation and reassembly
- Error handling and diagnostics
Data Link
- Composed of two sublayers: logical link control (LLC) and and media access control (MAC)
- Provides a well-defined service interface to the network layer
- Deals with transmission errors
- Regulates data flow Physical •^ Handles the interface to the communication medium
- Deals with various medium characteristics
it is not biased toward one particular set of protocols, which makes it quite general. With TCP/IP, the reverse is true: the protocols came first, and the model was really just a description of the existing protocols. Consequently, this model does not fit any other protocol stacks [3]. The rest of the chapter is organized as follows. In the section on ISO Network Management Functions, ISO network management functions are briefly described. Network management proto- cols are discussed in the Section on Network Management Protocols. In the next section, network management tools are briefly described. Wireless network management is discussed next. Policy- based network management is introduced in the following section. The final section draws general conclusions.
2.3 Security Management
Security management protects the networks and systems from unauthorized access and security attacks. The mechanisms for security management include authentication, encryption and au- thorization. Security management is also concerned with generation, distribution, and storage of encryption keys as well as other security-related information. Security management may include security systems such as firewalls and intrusion detection systems that provide real-time event monitoring and event logs.
2.4 Accounting Management
Accounting management enables charge for the use of managed objects to be measured and the cost for such use to be determined. The measure may include the resources consumed, the facilities used to collect accounting data, and set billing parameters for the services used by customers, the maintenance of the databases used for billing purposes, and the preparation of resource usage and billing reports.
2.5 Performance Management
Performance management is concerned with evaluating and reporting the behavior and the effec- tiveness of the managed network objects. A network monitoring system can measure and display the status of the network, such as gathering the statistical information on traffic volume, network availability, response times, and throughput.
3 Network Management Protocols
In this section, different versions of SNMP and RMON will be introduced. SNMP is the most widely used data network management protocol. Most of the network components used in enterprise network systems have built-in network agents that can respond to an SNMP network management system. This enables new components to be automatically monitored. Remote network monitoring (RMON) is, on the other hand, the most important addition to the basic set of SNMP standards. It defines a remote network monitoring MIB that supplements MIB-2 and provides the network manager with vital information about the internetwork.
3.1 SNMP/SNMPv
The objective of network management is to build a single protocol that manages both OSI and TCP/IP networks. Based on this goal, SNMP, or SNMPv1 [4–6] was first recommended as an interim set of specifications for use as the basis of common network management throughout the system, whereas the ISO CMIP over TCP/IP (CMOT) was recommended as the long term solution [7, 8]. SNMP consists of three specifications: the SMI, which describes how managed objects contained in the MIB are defined; the MIB, which describes the managed objects contained in the MIB; and the SNMP itself, which defines the protocol used to manage these objects.
3.1.1 SNMP Architecture
The model of network management that is used for TCP/IP network management includes the following key elements:
- Management station: hosts the network management applications.
- Management agent: provides information contained in the MIB to management applica- tions and accepts control information from the management station.
- Management information base: defines the information that can be collected and con- trolled by the management application.
- Network management protocol: defines the protocol used to link the management station and the management agents. The architecture of SNMP, shown in Figure 12.3, demonstrates the key elements of a network management environment. SNMP is designed to be a simple message-based application-layer pro- tocol. The manager process achieves network management using SNMP, which is implemented over the User Datagram Protocol (UDP) [9, 10]. SNMP agent must also implement SNMP and UDP protocols. SNMP is a connectionless protocol, which means that each exchange between a management station and an agent is a separate transaction. This design minimizes the complexity of the management agents. Figure 12.3 also shows that SNMP supports five types of protocol data units (PDUs). The manager can issue three types of PDUs on behalf of a management application: GetRequest,
Version Community Name SNMP PDU (a) SNMP message TypePDU RequestID^ ErrorStatus^ ErrorIndex^ Name 1 Value 1 ... Name N Value N
VariableBindings
(b) Get/Set Type of PDUs TypePDU Enterprise^ AddressAgent- Generic-Trap Specific-Trap Timestamp^ Name 1 Value 1 ... Name N Value N
VariableBindings
(c) Trap PDUs Figure 12.4: SNMP Message Formats
agement system is a management information base (MIB) containing a set of network objects to be managed. Each managed resource is represented as an object. The MIB is in fact a database structure of such objects in the form of a tree [11]. Each system in a network environment maintains a MIB that keeps the status of the resources to be managed at that system. The information can be used by the network management entity for resource monitoring and controlling. SMI defines the syntax and semantics used to describe the SNMP management information [12].
MIB Structure. For simplicity and extensibility, SMI avoids complex data types. Each type of objects in a MIB has a name, syntax, and an encoding scheme. An object is uniquely identified by an OBJECT IDENTIFIER. The identifier is also used to identify the structure of object types. The term OBJECT DESCRIPTOR may also be used to refer to the object type [5]. The syntax of an object type is defined using Abstract Syntax Notation One (ASN.1) [13]. Basic encoding rules (BER) have been adopted as the encoding scheme for data type transfer between network entities. The set of defined objects has a tree structure. Beginning with the root of the object identifier tree, each object identifier component value identifies an arc in the tree. The root has three nodes: itu (0), iso (1), and joint-iso-itu (2). Some of the nodes in the SMI object tree, starting from the root, are shown in Figure 12.5. The identifier is constructed by the set of numbers, separated by a dot that defines the path to the object from the root. Thus, the internet node, for example, has its OBJECT IDENTIFIER value of 1.3.6.1. It can also be defined as follows: internet OBJECT IDENTIFIER ::= { iso (1) org (3) dod (6) 1 }.
Table 12.2: SNMP Message Fields Field Functions Version SNMP version (RFC 1157 is version 1) Community Name
A pairing of an SNMP agent with some arbitrary set of SNMP applica- tion entities (Community name serves as the password to authenticate the SNMP message) PDU Type
The PDU type for the five messages is application data type, which is defined in RFC 1157 as GetRequest ( 0 ), GetNextRequest ( 1 ), SetRequest ( 2 ), GetResponse ( 3 ), trap ( 4 ) RequestID Used to distinguish among outstanding requests by a unique ID ErrorStatus A non-zerowhile processing a request^ ErrorStatus^ is used to indicate that an exception occurred ErrorIndex Used to provide additional information on the error status VariableBindings A list of variable names and corresponding values Enterprise Type of object generating trap AgentAddress Address of object generating trap GenericTrap
Generic trap type; values are coldStart ( 0 ), warmStart ( 1 ), linkDown ( 2 ), linkUp ( 3 ), authenticationFailure ( 4 ), egpNeighborLoss ( 5 ), enterpriseSpecific ( 6 ) SpecificTrap Specific trap code not covered by the enterpriseSpecific type Timestamp Time elapsed since last re-initialization
Any object in the internet node will start with the prefix 1.3.6.1 or simply internet. SMI defines four nodes under internet: directory, mgmt, experimental, and private. The mgmt subtree contains the definitions of MIBs that have been approved by the IAB. Two versions of the MIB with the same object identifier have been developed, mib-1 and its extension mib-2. Additional objects can be defined in one of the following three mechanisms [4, 11]:
- The mib-2 subtree can be expanded or replaced by a completely new revision.
- An experimental MIB can be constructed for a particular application. Such objects may subsequently be moved to the mgmt subtree.
- Private extensions can be added to the private subtree.
Object Syntax. The syntax of an object type defines the abstract data structure corresponding to that object type. ASN.1 is used to define each individual object and the entire MIB structure. The definition of an object in SNMP contains the data type, its allowable forms and value ranges, and its relationship with other objects within the MIB.
Table 12.3: Objects Contained in MIB- Groups Description system Contains system description and administrative information interfaces Contains information about each of the interfaces from the system to a subnet at
Contains address translation table for Internet-to-subnet address mapping. This group is deprecated in MIB-2 and is included solely for compatibility with MIB-1 nodes ip Contains information relevant to the implementation and operation of IP at anode icmp Contains information relevant to the implementation and operation of ICMPat a node tcp Contains information relevant to the implementation and operation of TCP ata node udp Contains information relevant to the implementation and operation of UDP ata node egp Contains information relevant to the implementation and operation of EGP ata node transmission Contains information about the transmission schemes and access protocols ateach system interface snmp Contains information relevant to the implementation and operation of SNMPon this system
the management system. Furthermore, SNMP cannot authenticate the source of a management message. Therefore, it is possible for unauthorized users to exercise SNMP network management functions and to eavesdrop on management information as it passes from the managed systems to the management system. Because of these deficiencies, many SNMP implementations have chosen not to implement the Set command. This reduces their utility to that of a network monitor and no network control applications can be supported.
3.2 SNMPv
SNMP was originally developed as an interim management protocol and CMIP over TCP/IP (CMOT), which essentially enables the OSI system management protocols to operate on top of the TCP protocol, as the ultimate network management protocol. However, the later never came about in reality. At the same time, SNMP has been incorporated widely and enhancement was ex- pected. SNMPv2 was developed when it was obvious that the OSI network management standards were not going to be implemented in the foreseeable future.
TypePDU RequestID^ ErrorStatus^ ErrorIndex^ Name 1 Value 1 ... Name N Value N
VariableBindings
(a) All but Bulk Type of PDUs TypePDU RequestID^ NonRepeaters^ MaxRepetitions^ Name 1 Value 1 ... Name N Value N
VariableBindings
(b) GetBulkRequest PDU Figure 12.6: SNMPv2 PDU Formats
3.2.1 Major Changes in SNMPv
The SNMPv2 system architecture is essentially the same as that of SNMP. The key enhancement in SNMPv2 can be summarized as follows:
- Bulk data transfer capability: The most noticeable change in SNMPv2 is the inclusion of two new PDUs. The first PDU is the GetBulkRequest PDU, which enables the manager to retrieve large blocks of data efficiently, and therefore, speeds up the GetNextRequest process.
- Manager-to-manager capability: The second PDU is the InformRequest PDU, which enables one manager to send trap type of information to another, and thus makes network management systems interoperable.
- Structure of management information: The SMI defined in SNMP has been consolidated and rewritten.
3.2.2 SNMPv2 Protocol Specifications
To improve the efficiency and performance of message exchange between systems, the PDU data structure in SNMPv2 has been standardized to a common format for all messages given in Fig- ure 12.6. In the GetBulkRequest PDU, NonRepeaters field indicates the number of non-repetitive field values requested and the MaxRepetitions field designates the maximum number of table rows requested.
3.2.3 SNMPv2 Structure of Management Information
The SMI for SNMPv2 is based on the SMI for SNMP. It is nearly a proper superset of the SNMP SMI. The SNMPv2 SMI is divided into three parts: module definitions, object definitions, and
SNMP Engine (identified by snmpEngineID) Dispatcher ProcessingSubsystemMessage SubsystemSecurity Access ControlSubsystem
Application(s) CommandGenerator
CommandResponder
NotificationReceiver Proxy Forwarder NotificationOriginator Other
Figure 12.7: SNMP Entity
and future development in SNMP with minimum impacts on existing operations.
3.3.1 SNMPv3 Architecture
An SNMP management network consists of a distributed, interacting collection of SNMP entities. Each entity consists of a collection of modules that interact with each other to provide services. The architecture of an entity is defined as the elements of that entity and the names associated with them. There are three kinds of naming: naming of entities, naming of identities, and naming of management information.
SNMP Entities. The elements of the architecture associated with an SNMP entity, shown in Figure 12.7, consist of an SNMP engine, named snmpEngineID, and a set of applications which use the services provided by the SNMP engine. A brief definition of each of the modules is described below.
- Dispatcher: Allows for concurrent support of multiple versions of SNMP messages in the SNMP engine. It performs three sets of functions. First, it sends and receives SNMP messages from the network. Secondly, it determines the version of the message and interacts with the corresponding message processing model. Thirdly, it provides an abstract interface to SNMP applications to deliver an incoming PDU to the local application, and to send a PDU from the local application to a remote entity.
- Message Processing Subsystem: Responsible for preparing messages for sending, and
Component Primitive Table 12.4: List of PrimitivesService Provided
Dispatcher
sendPdu Sends an SNMP request or notification to anotherSNMP entity processPdu Passes an incoming SNMP PDU to an application returnResponsePdu Returns an SNMP response PDU to the PDU dis-patcher processResponsePdu Passes an incoming SNMP response PDU to anapplication registerContextEngineID Registers contextEngineID^ responsibility, for specific^ forpduTypes^ a^ specific unregisterContextEngineID Unregisters contextEngineID^ responsibility, for specific^ pduTypesfor^ a^ specific
Message Process Subsystem
prepareOutgoingMessage Prepares an outgoing SNMP request or notifica-tion message prepareResponseMessage Prepares an outgoing SNMP response message prepareDataElements Prepares the abstract data elements from an in-coming SNMP message Access Control Subsystem
isAccessAllowed Checks if access is allowed
Security Subsystem
generateRequestMsg Generates a request or notification message processIncomingMsg Processes an incoming message generateResponseMsg Generates a response message User-based Security Model
authenticateOutgoingMsg Authenticates an outgoing message authenticateIncomingMsg Authenticates an incoming message encryptData Encrypts data decryptData Decrypts data
extracting data from received messages.
- Security Subsystem: Provides security services such as authentication and privacy of mes- sages. It potentially contains multiple Security Models.
- Access Control Subsystem: Provides authorization services by means of one or more Access Control Models.
SNMP Names. The names associated with the identities include principal, securityName and a model-dependent security ID. A principal indicates to “whom” services are provided. A principal can either be a person or an application. A securityName is a human readable string which represents a principal. A model-dependent security ID is the model-specific representation of a
The command generator uses returnResponsePdu to deliver the message back to the dispatcher.
Notification Originators. A notification originator application follows the same general pro- cedures used for a command generator application to generate either a trap or an Inform. If an Inform PDU is to be sent, both the sendPDU and processResponse primitives are used. If a trap PDU is to be sent, only the sendPDU primitive is used.
Notification Receiver. A notification receiver application follows a subset of the general proce- dures as for a command responder application to receive SNMP notification messages. Both types of PDUs are received by means of a processPdu primitive. For an Inform PDU, a returnResponsePdu primitive is used to respond.
Proxy Forwarder. A proxy forwarder application makes use of dispatcher primitives to forward SNMP messages. The proxy forwarder application handles four types of messages: messages con- taining PDU types generated by a command generator application, messages containing PDU types generated by a command responder application, messages containing PDU types generated by a notification originator application, and messages containing a report indicator.
3.3.3 SNMPv3 Management Information Base
Three separate MIB modules have been defined in [17] to support SNMPv3 applications: the management target MIB, the notification MIB, and the proxy MIB. The SNMP-TARGET-MIB module contains objects for defining management targets. It consists of two tables. The first table, the snmpTargetAddrTable, contains information about transport domains and addresses. The second table, the snmpTargetParamsTable, contains information about SNMP version and security information to be used when sending messages to particular transport domains and addresses. The SNMP-NOTIFICATION-MIB module contains objects for remote configuration of the param- eters used by an SNMP entity for the generation of notifications. It consists of three tables. The first table, the snmpNotifyTable, selects one or more entries in snmpTargetAddrTable to be used for notifications generation. The second table, the snmpNotifyFilterProfileTable, sparsely aug- ments the snmpTargetParamsTable so as to associate a set of filters with a particular management
msgID msgMaxSize msgFlags msgSecurityModel
msgAuthoritativeEngineID msgAuthoritativeEngineBoots msgAuthoritativeEngineTime msgUserName msgAuthenticationParameters msgPrivacyParameters
msgVersion msgGlobalData msgSecurityParameters msgData
contextEngineID contextName PDU
msgGloboData=HeaderData Scope of encryption
Figure 12.8: SNMPv3 Message Format
target. The third table, the snmpNotifyFilterTable, defines filters used to limit the number of notifications generated for a particular management target. The SNMP-PROXY-MIB contains objects for the remote configuration of the parameters used by an SNMP entity for proxy forwarding operations. It contains a single table, snmpProxyTable, which is used to define the translations between management targets for forwarding messages.
3.3.4 SNMPv3 Message Format
Each SNMPv3 message includes four data groups: msgVersion, msgGlobaGata, msgSecurityParameters, and msgPDU, as shown in Figure 12.8. The msgVersion field is set to snmpv3 (3) and identifies the message as an SNMP version 3 Message. The msgGlobaGata field contains the header information. The msgSecurityParameters field is used exclusively by the Security Model. The contents and format of the data are defined by the Security Model. The msgData is the scoped PDU field containing information to identify an administratively unique context and a PDU.
3.3.5 Security Enhancement
One of the main objectives in developing SNMPv3 is the addition of security services for network management. SNMPv3 is intended to address four types of security threats: modification of in- formation, masquerade, disclosure, and message stream modification. The first two are identified as principal threats, while the last two are identified as secondary threats. A User-based Secu- rity Model (USM) is proposed in SNMPv3. This model reflects the traditional concept of a user identified by a userName [18].
