8.3 The Internet Network Management Framework

Contrary to what the name SNMP (Simple Network Management Protocol) might suggest, network management in the Internet  is much more than just a protocol for moving management data between a management entity and its agents, and has grown to be more complex than the word "simple" might suggest. The current Internet Standard Management Framework traces it roots back to the Simple Gateway Monitoring Protocol , SGMP [RFC 1028]. that was designed by a group of university network researchers, users, and manager; their experience with SGMP allowed them to design, implement, and deploy SNMP in just a few months [Lynch 1993] - a far cry from today's rather drawn out standardization process.  Since then, SNMP has evolved from SNMPv1 through SNMPv2 to the most recent version, SNMPv3 [RFC2570], released in April 1999.

When describing any framework for network management, certain questions must inevitably be addressed:

Recall our human organizational analogy from the previous section.  The boss and the branch managers will need to agree on the measures of activity, productivity and budget used to report the branch office's status.  Similarly, they'll need to agree on the actions the boss can take (e.g., cut budget, order the branch manager to change some aspect of the office's operation).  At a lower level of detail, they'll need to agree on the form in which this data is reported (e.g., In what currency (dollars, euros?) will the budget be reported? In what units will productivity be measured?).  While these are trivial details, but they be agreed upon, nonetheless.  Finally, the manner in which information is conveyed between the main office and the branch offices (i.e., their communication protocol) must be specified.

The Internet Network Management Framework exactly addresses the the questions posed above. The framework consists of four parts:

The Internet network management architecture is thus modular by design, with a protocol-independent data definition language and MIB, and a MIB-independent protocol. Interestingly, this modular architecture was first put in place to ease the transition from an SNMP-based network management to a network management framework being developed by the International Organization for Standardization (ISO), the competing network management architecture when SNMP was first conceived - a transition that never occurred. Over time,  however, SNMP's design  modularity has allowed it to evolve through three major revisions, with each of the four majors parts of SNMP discussed above evolving independently.  Clearly, the right decision about modularity was made, if even for the wrong reason!

In the following four sections, we cover the four major components of the Internet network management framework in more detail.
 

8.3.1 Structure of Management Information: SMI

The Structure of Management Information, SMI, (a rather oddly named component of the network management  framework whose name gives no hint of its functionality) is the language used to define the management information residing in a managed network entity. Such a definition language is needed to ensure that the syntax and semantics of the defined network management data are well-defined and unambiguous. Note that the SMI does not define a specific instance the data in a managed network entity, but rather the language in which such information is specified. The documents describing the SMI for SNMPv3 (which rather confusingly, is called SMIv2) are [RFC 2578, RFC 2579, RFC 2580]. Let us examine the SMI in a bottom-up manner, starting with the base data types in the SMI.  We'll then  look at how managed objects are described in SMI, and then how related managed  managed objects are grouped into modules.

SMI Base Data Types

RFC 2578 [RFC 2578] specifies the basic data types in the SMI MIB module-definition language.   Although the SMI is based on the ASN.1 (Abstract Syntax Notation One) [ISO 1987, ISO X.680] object definition language (see section 8.4) developed by the ISO in the 1980, enough  SMI-specific data types have been added that SMI should be considered a data definition language in its own right. The eleven basic data types defined in RFC 2578 are shown in Table 8.3-1.  In addition to these scalar objects, it is also possible to impose a tabular structure on an ordered collection of MIB objects using the SEQUENCE OF construct;  see [RFC 2578] for details.  Most of the data types in Table 8.3-1 will be familiar (or self-explanatory) to most readers.  The one data type we will discuss in more detail shortly is the OBJECT IDENTIFIER data type, which is used to name an object.
 
 

Data type Description
INTEGER 32 bit integer, as defined in ASN.1, with a value between  -2^31 and 2^31-1 inclusive, or a value from a list of possible named constant values
Integer32 32 bit integer with a value between -2^31 and 2^31-1 inclusive
Unsigned32 Unsigned 32 bit integer in the range 0 to 2^23-1 inclusive
OCTET STRING ASN.1-format byte string representing arbitrary binary or textual data, up to 65535 bytes long
OBJECT IDENTIFIER ASN.1-format administratively assigned (structured name); see section 8.3
IPaddress 32-bit Internet address, in network byte order
Counter32 32-bit counter that increases from 0 to 2^32-1 and then wraps around to 0.
Counter64 64-bit counter
Gauge32 32-bit integer that will not count above 2^31-2 nor decrease beyond 0 when increased or decreased
TimeTicks time, measured in 1/100ths of seconds since some event
Opaque uninterpreted ASN.1 string, needed for backward compatibility
Table 8.3-1: Basic data types of the SMI

SMI Higher Level Constructs

In addition to the basic data types, the SMI  data definition language also provides higher level language constructs:

8.3.2 Management Information Base: MIB

As noted above, the Management Information Base, MIB,  can be thought of as a virtual information store, holding managed objects whose values collectively reflect the current "state" of the network. These values may be queried and/or set by a managing entity by sending SNMP messages to the agent that is executing in a managed node on behalf of the managing entity.  Managed objects are specified using the OBJECT-TYPE SMI construct discussed above and gathered into MIB modules using the MODULE-IDENTITY construct.

The IETF has been busy standardizing the MIB modules (i.e., the management information) associated with routers, hosts and other network equipment.  This includes basic identification data about a particular piece of hardware, and management information about the device's network interfaces and protocols. As of the release of SNMPv3 (mid-1999), there were nearly 100 standards-based MIB modules and an even larger number of vendor-specific (private) MIB modules. With all of these standards, the IETF needed a way to identify and name the standardized modules, as well as the specific managed objects within a module.  Rather than start from scratch, the IETF adopted a standardized object identification (naming) framework that had already been put in place by the International Organization for Standardization (ISO).  As is the case with many standards bodies, the ISO had "grand plans" for their standardized object identification framework - to identify every possible standardized object (e.g., data format, protocol, or piece of information) in any network, regardless of the network standards organization  (e.g., Interne IETFt, ISO, IEEE, or ANSI), equipment manufacturer, or network owner. A lofty goal indeed! The object identification framework adopted by ISO is part of the ASN.1 (Abstract Syntax Notation One) [ISO 1987, ISO X.680] object definition language (see section 8.4). Standardized MIB modules have their own cozy corner in the all encompassing naming framework, as discussed below.

As shown in Figure 8.3-1, objects are identified in the ISO naming framework in a hierarchical manner.  Note that each branch point in the tree has both a name and a number (shown in parenthesis); any point in the tree is thus identifiable by the sequence of names or numbers that specify the path from the root to that point in the identifier tree. A fun, but incomplete and unofficial, WWW-based utility for traversing part of the object identifier tree (using branch information contributed by volunteers) is http://www.alvestrand.no/harald/objectid/top.html.

Object Identifier Tree
Figure 8.3-1: ASN.1 Object Identifier Tree



At the top of the hierarchy are the International Organization for Standardization (ISO)  and the Telecommunication Standardization Sector of the International Telecommunication Union (ITU-T), the two main standards organizations dealing with ASN.1, as well as a brach for joint efforts by these two organizations.  Under the ISO branch of the tree, we find entries for all ISO standards (1.0) and for standards issued by standards bodies of various ISO-member countries (1.2). Although not shown in Figure 8.3-1, under (ISO ISO-Member-Body, a.k.a. 1.2) we would find USA (1.2.840), under which we would find a number of IEEE, ANSI, and company-specific standards. These include RSA (1.2.840.11359) and Microsoft (1.2.840.113556), under which we find the Microsoft File Formats (1.2.840.112556.4) for various Microsoft products, such as Word (1.2.840.11356.4.2).  But we are interested here in networking (not Microsoft Word files), so let us turn our attention to the branch labeled 1.3 - the standards issued by bodies recognized by the ISO. These include the US  Department of Defense (6) (under which we will find the Internet standards), the Open Software Foundation (22), the airline association SITA (69) and NATO-identified bodies (57), as well as many other organizations.

Under the Internet branch of the tree (1.3.6.1), there are seven categories. Under the private (1.3.6.1.4) branch, we will find a list [IANA 1999b] of the names and private enterprise codes of more than 4000 private companies that have registered with the Internet Assigned Numbers Authority (IANA) [IANA 99].  Under the management (1.3.6.1.2) and MIB-2 branch (1.3.6.1.2.1) of the object identifier tree, we find the definitions of the standardized MIB modules.

Standardized MIB modules

The lowest level of the tree in Figure 8.3-1 shows some of the important hardware-oriented MIB modules (system and interface) as well as modules associated with some of the most important Internet protocols.  [RFC 2400] lists all of the standardized MIB modules.  While MIB-related RFC's make for rather tedious and dry reading, it is instructive (i.e., line eating vegetables, it is "good for you") to consider a few MIB module definitions to get a flavor for the type of information  in a module.

The managed objects falling under system contain general information about the device being managed; all managed devices must support the system MIB objects. Table 8.3-2 defines the objects in the system group, as defined in [RFC 1213].
 
 

Object Identifier Name Type Description (from RFC 1213)
1.3.6.1.2.1.1.1 sysDescr OCTET STRING "full name and version identification of the system's hardware type, software operating-system, and networking software"
1.3.6.1.2.1.1.2 sysObjectID OBJECT IDENTIFIER Vendor assigned object ID that "provides an easy and unambiguous means for determining `what kind of box' is being managed."
1.3.6.1.2.1.1.3 sysUpTime TimeTicks "The time (in hundredths of a second) since the network management portion of the system was last re-initialized."
1.3.6.1.2.1.1.4 sysContact OCTET STRING "The contact person for this managed node, together with information on how to contact this person."
1.3.6.1.2.1.1.5 sysName OCTET STRING "An administratively-assigned name for this managed node.  By convention, this is the node's fully-qualified domain name"
 1.3.6.1.2.1.1.6 sysLocation OCTET STRING "The physical location of this node."
1.3.6.1.2.1.1.7 sysServices Integer32 A coded value that indicates the set of services available at this node: physical (e.g., a repeater), datalinkl/subnet (e.g., bridge), internet (e.g., IP gateway), end-end (e.g., host), applications.
Table 8.3-2: Managed Objects in the MIB-2 system group

 Table 8.3-3 defines the managed objects in the MIB module for the UDP protocol at a managed entity.
 
 

Object Identifier Name Type Description (from RFC 2013)
1.3.6.1.2.1.7.1 udpInDatagrams Counter32 "total number of UDP datagrams delivered to UDP users"
1.3.6.1.2.1.7.2 udpNoPorts Counter32 "total number of received UDP datagrams for which there was no application at the destination port"
1.3.6.1.2.1.7.3 udpInErrors Counter32 "number of received UDP datagrams that could not be delivered for reasons other than the lack of an application at the destination port"
1.3.6.1.2.1.7.4 udpOutDatagrams Counter32 "total number of UDP datagrams sent from this entity"
1.3.6.1.2.1.7.5 udpTable SEQUENCE of UdpEntry a sequence of UdpEntry objects, one for each port that is currently open by an application, giving the IP address and the port number used by application
Table 8.3-3: Managed Objects in the MIB-2 udp module


8.3.3 SNMP Protocol Operations and Transport Mappings

The Simple Network Management Protocol Version 2 (SNMPv2) [RFC 1905] is used to convey MIB information that has been specified in the SMI among managing entities and agents executing on behalf of managing entities. The most common usage of SNMP is in a request-response mode -  an SNMPv2 managing entity sends a request to an SNMPv2 agent, who receives the request, performs some action and sends a reply to the request. Typically, a request will be used to query (retrieve) or modify (set)  MIB object values associated with a managed device. A second common usage of SNMP is for an agent to send an unsolicited message, known as a trap message, to a managing entity. Trap messages are used to notify a managing entity of an exceptional situation that has resulted in changes to MIB object values. We saw earlier in section 8.1 that the network administrator might want to receive a trap message, for example, when an interface goes down, congestion reaches a predefined level on a link, or some other noteworthy event occurs.  Note that there are a number of important tradeoffs between polling (request-response interaction) and trapping; see the homework problems.
 
 
SNMPv2 PDU Type sender-reciever Description
GetRequest manager-to-agent get value of one or more MIB object instances 
GetNextRequest manager-to-agent get value of next MIB object instance in list or table
GetBulkRequest manager-to-agent get values in large block of data, e.g. values in a large table
InformRequest manager-to-manager inform remote managing entity of MIB values remote to its access
SetRequest manager-to-agent set value of one or more MIB object instances
Response agent-to-manager 
or 
manager-to-manager		 generated in response to GetRequest, GetNextRequest, GetBulkRequest, SetRequestPDU, or InformRequest,
SNMPv2-Trap agent-to-manager  inform manager of an exceptional event
Table 8.3-4: SNMPv2 PDU types
SNMP PDU format
Figure 8.3-2: SNMP PDU format

SNMPv2 defines seven types of messages, known generically as Protocol Data Units - PDUs, as shown in Table 8.3-4. The format of  the PDU is shown in Figure 8.3-2.  The GetRequest, GetNextRequest, and GetBulkRequest PDUs are all sent from a managing entity to an agent to request the value of one or more MIB objects at the agent's managed device. The object identifiers of the MIB objects whose values are being requested are specified in the variable binding portion of the PDU.  GetRequest, GetNextRequest, and GetBulkRequest differ in the granularity of their data requests. GetRequest can request an arbitrary set of MIB values; multiple GetNextRequests can be used to sequence through a list or table of MIB objects; GetBulkRequest allows a large block of data to be returned, avoiding the overhead  incurred if multiple GetRequest or GetNextRequest messages were to be sent.  In all three cases, the agent responds  with a Response PDU containing the object identifiers and their associated values.

The SetRequest PDU is used by a managing entity to set the value of one or more MIB objects in a managed device. An agent replies with a Response PDU with the 'noError' Error Status to confirm that the value has indeed been set.
The InformRequest PDU is used by a managing entity to notify another managing entity of  MIB information that is  remote to the receiving entity.  The receiving entity replies with a Response PDU with the 'noError' Error Status to acknowledge receipt of the InformRequest PDU.

Given the request-response nature of SNMPv2, it is worth noting here that although SNMP PDU's can be carried via many different transport protocols, the SNMP PDU is typically carried in the payload of  a UDP datagram.  Indeed, [RFC 1906] states that UDP is "the preferred transport mapping."  Since UDP is an unreliable transport protocol, there is no guarantee that a request, or its response will be received at the intended destination.  The Request ID field of the PDU is used by the managing entity to number its requests to an agent; an agent's response takes its Request ID from that of the received request.  Thus, the Request ID field can be used by the managing entity to detect lost requests or replies. It is up to the managing entity to decide whether to retransmit a request if no corresponding response is received after a given amount of time.  In particular, the SNMP standard does not mandate any particular procedure for retransmission, or even if retransmission is to be done in the first place.  It only requires that the managing entity "needs to act responsibly in respect to the frequency and duration of re-transmissions." Which, of course, leads one to wonder how a "responsible" protocol should behave!

The final type of SNMPv2 PDU is the trap message.  Trap message are generated asynchronously, i.e., not in response to a received request but rather in response to an event for which the managing entity requires notification.  [RFC 1907] defines well-known trap types that include a cold or warm start by a device, a link going up or down, the loss of a neighbor, or an authentication failure event.  A received trap request has no required response from a managing entity.
 

8.3.4 Security and Administration.

The designers of SNMPv3 have said that "SNMPv3 can be thought of as SNMPv2 with additional security and administration capabilities." [RFC2570]  Certainly, there are changes in SNMPv3 over SNMPv2, but nowhere are those changes more evident than in the area of administration and security.

As SNMP has matured through three versions, its functionality has grown but so too, alas, has the number of SNMP-related standards documents. This is evidenced by the fact that there is even now an RFC [RFC 2571] that " describes an architecture for describing SNMP Management Frameworks"!  While the notion of an "architecture" for "describing a framework" might be a bit much to wrap one's mind around, the goal of RFC 2571 is an admirable one -  to introduce a common language for describing the functionality and actions taken by an SNMPv3 agent or managing entity. The architecture of an SNMPv3 entity is straightforward, and tour through the architecture will serve to solidify our understanding of SNMP.

The so-called SNMP applications consist of a command generator, notification receiver and proxy forwarder (all of which are typically found in a managing entity); a command responder and notification originator (both of which are typically found in an agent); and the possibility of other applications.  The command generator generates the GetRequest, GetNextRequest, GetBulkRequest and SetRequest PDUs that we examined above in section 8.3.3 and handles the received responses to these PDUs.  The command responder executes in an agent and receives, processes and replies (using the Response message) to received GetRequest, GetNextRequest, GetBulkRequest and SetRequest PDUs. The notification originator application in an agent generates Trap PDUs; these PDUs are eventually received an processed in a notification receiver application at a managing entity.  The proxy forwarder application forwards request, notification, and response PDUs.

A PDU sent by an SNMP application next passes through the SNMP "engine" before it is sent via the appropriate transport protocol.  Figure 8.3-3 shows how a PDU generated by the command generator application first enters the dispatch module, where the SNMP version is determined.  The PDU is then processed in the message processing system, where the PDU is wrapped in a message header containing the SNMP version number, a message ID and message size information.  If encryption or authentication is needed then the appropriate header fields for this information is included as well; see [RFC 2571] for details.  Finally, the SNMP message (the application-generated PDU plus the message header information) is passed to the appropriate transport protocol.  The preferred transport protocol for carrying SNMP messages is UDP (i.e., SNMP messages  are carried as the payload in a UDP datagram), and the preferred port number for the SNMP is port 161.


Figure 8.3-3: SNMPv3 engine and applications

We have seen above that SNMP messages are used to not just monitor, but also to control (e.g., through the SetRequest command) network elements.  Clearly, an intruder that could intercept SNMP messages and/or generate its own SNMP packets into the management infrastructure could wreak havoc in the network. Thus, it is crucial that SNMP messages be transmitted securely.  Surprisingly, it is only in the most recent version of SNMP that security has received the attention that it deserves.  SNMPv3 provides for encryption, authentication, protection against playback attacks (see sections 7.2 and 7.3), and access control. SNMPv3 security is known as  user-based security [RFC 2574] in that there is the traditional concept of a user, identified by a user name, with which security information such as a password, key value, or access privileges are associated.

References

[IANA 1999] Internet Assigned Number Authority homepage, http://www.iana.org/
[IANA 1999b]   Internet Assigned Number Authority, Private Enterprise Numbers, ftp://ftp.isi.edu/in-notes/iana/assignments/enterprise-numbers
[ISO 1987]  Information processing systems - Open Systems Interconnection -  Specification of Abstract Syntax Notation One (ASN.1),  International Organization for Standardization.  International Standard 8824, (December, 1987).
[ISO X.680] X.680 : ITU-T Recommendation X.680 (1997) | ISO/IEC 8824-1:1998, Information Technology - Abstract Syntax Notation One (ASN.1): Specification of Basic Notation
[Lynch 1993] D. Lynch, M. Rose, "Internet System Handbook", Addison Wesley, 1993.
[RFC 1213] K. McCloghrie, M.T. Rose, "Management Information Base for Network Management of TCP/IP-based internets:MIB-II, " RFC 1213, March 1991.
[RFC 1905] J. Case, K. McCloghrie, M. Rose, S. Waldbusser, "Protocol Operations for Version 2 of the Simple Network Management Protocol  (SNMPv2)," RFC 1905, Jan. 1996.
[RFC 1906] J. Case, K. McCloghrie, M. Rose, S. Waldbusser, "Transport Mappings for Version 2 of the Simple
Network Management Protocol  (SNMPv2)," RFC 1906, Jan. 1996.
[RFC 1907] J. Case, K. McCloghrie, M. Rose,  and  S. Waldbusser, "Management Information Base for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1907, January 1996.
[RFC 2011] K. McCloghrie, "SNMPv2 Management Information Base the Internet Protocol using  SMIv2," RFC 2011, Nov. 1996.
[RFC 2012] K. McCloghrie, "SNMPv2 Management Information Base for the Transmission Control Protocol using  SMIv2," RFC 2012, Nov. 1996.
[RFC 2013] K. McCloghrie, "SNMPv2 Management Information Base for the User Datagram Protocol using SMIv2," RFC 2013, Nov. 1996
[RFC 2021] S. Waldbusser, "Remote Network Monitoring Management Information Base Version 2 using SMIv2," RFC 2021, Jan. 1997.
[RFC 2104] H. Krawczyk, M. Bellare, R. Canetti, "MHAC: Keyed hashing for Message Authentication," RFC 2104, Feb. 1997.
[RFC 2400] J. Postel, J. Reynolds, "Internet Official Protocol Standards," RFC 2400, Oct. 1998.
[RFC 2570] J. Case, R. Mundy, D. Partain, B. Stewart, "Introduction to Version 3 of the Internet-standard Network Management Framework,"  RFC 2570, April 1999.
[RFC 2571]   B. Wijnen, D. Harrington, R. Presuhn, "An Architecture for Describing SNMP Management Frameworks," RFC 2571, April 1999.
[RFC 2574]  U. Blumenthal, B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3), " RFC 2574, April 1999.
[RFC 2575] B. Wijnen, R. Presuhn, K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network  Management Protocol (SNMP)," RFC 2575,  April 1999.
[RFC 2578] K. McCloghrie, D. Perkins, J. Schoenwaelder,  "Structure of Management Information Version 2 (SMIv2)," RFC 2578, April 1999.
[RFC 2579] K. McCloghrie, D. Perkins, J. Schoenwaelder, "Textual Conventions for SMIv2," RFC 2579, April 1999.
[RFC 2580] K. McCloghrie, D. Perkins, J. Schoenwaelder, "Conformance Statements for SMIv2," RFC 2580, April 1999.
 

Return to Table Of Contents

Copyright Keith W. Ross and Jim Kurose 1996-1999