The SNMPv3 engine is made up of four subcomponents:

Two important points to note about the engine subcomponents are that they:

The SNMPv3 architecture is flexible and modular. It remains to be seen whether this facility will be used over time, but one area where change is quite likely is that of security. Another security model could be added to the architecture by extending the security subsystem and adding an extra value in the security model number field (as illustrated in Figure 2-1 with the MessageSecurity parameter). Such a change would require a potentially costly software upgrade, but the benefits of extra security may become a necessity.

Figure 2-1. SNMPv3 message format.

The first field in the message is the SNMP version. This is located in the same position for all versions of SNMP to allow differentiation during message processing. This provides for backwards and forwards compatibility. A value of 3 in this field indicates an SNMPv3 message. A value of 2 indicates SNMPv2c and a value of 1 indicates SNMPv1.

The MessageID is a number used between two entities for message correlation. So, if a manager sends a GetRequest with MessageID x, then it is important that the manager does not re-use x until the outstanding message is answered or timed out. The PDU contains a request ID field, which was used for the same purpose in SNMPv1 and SNMPv2c, but since SNMPv3 allows for encrypted PDUs, the MessageID is in the (unencrypted) header. The MessageID also provides a means by which multiple copies of a response (e.g., if the underlying datagram service duplicates a message) can be distinguished. Messages re-transmitted by a manager should use a new MessageID.

The MaxMessageSize is the maximum message size supported by the sender of the message. This is the largest size packet that the transport protocol can carry without having to use fragmentation. The receiver uses the value of MaxMessageSize to ensure that its reply is within the allowed size range.

The MessageFlags object is 1-byte long and determines the authentication and privacy settings for the message. It also indicates if this message requires a (report) response from the receiver. The three right-most bit positions are used when encoding this object, and the following are the allowed combinations:

All three of the above may have the report option set. This indicates that a response is required.

The MessageSecurity is an integer object that indicates the security setting associated with the message. The range of values supported is as follows:

Values above 255 can be used to specify enterprise-specific security models. The receiver must use the same security model when executing its security processing. The security subsystem handles the processing of this section of the SNMPv3 message.

The general section of the security model data contains the following fields:

The above fields precede the authentication and privacy data areas. EngineID and UserName are used to form an index into a table called usmUserTable. This table stores the security model data for a given engine ID and user pair.

Two authentication protocols are supported in SNMPv3, namely MD5 and SHA. Both protocols serve the same purpose: that of authenticating the SNMPv3 message. The MD5 algorithm calculates a 16-byte (128-bit) digest and the first 12 bytes (96 bits) are included as part of the message in the Authentication field in Figure 2-1. The user must select a 16-octet secret key for use in the MD5 algorithm. If the user opts for the SHA authentication algorithm, then the (SHA) algorithm calculates a 20-byte (160-bit) digest and again the first 12 bytes (96 bits) are included as part of the message in the Authentication field in Figure 2-1. The user must select a 20-octet secret key for use in the SHA algorithm.

Whichever algorithm is used, the authentication protocol field is a 12-byte octet string used as an electronic fingerprint (or message authentication code) to authenticate the message. It is similar to the cyclic redundancy check (CRC) codes used in many applications (ATM, disk drives, etc.) to verify that data has not been modified in transit. When an SNMP entity (i.e., a manager) wants to send an SNMP request to another entity (i.e., an agent), it must use a secret authentication key (described in the previous paragraph) known to both parties. This key is used to generate the fingerprint. When the authenticated message is received, the fingerprint is recalculated, and if the two match, then the message is deemed to be authentic.

The privacy protocol field is an 8-byte octet string used for the Data Encryption Standard (DES) algorithm. The encryption uses a 16-byte key. The first 8 octets of the 16-octet secret key are used as a DES key. The second 8 octets are used as an initialization vector; this is a unique 8-octet value that is manipulated to ensure the same value is not used for encrypting different packets. Again, both parties use a secret private key to encrypt and decrypt messages.

The historical background for SNMPv3 context is interesting. It arose from discussions about how to deal with cases in which a given MIB table already exists with a specific indexing scheme, but the indexing scheme must be extended. Some tables in the Bridge MIB are indexed by port number, and in a rack-based system or a stacked system, there may be multiple cards or units with the same port numbering. Contexts were invented to allow multiple instances of the same MIB table within the same SNMP agent in order to handle cases like this.

ContextName is an octet string, and ContextID uniquely identifies an entity that may recognize an instance of a context with a particular context name. The context details are considered part of the PDU field.

This object represents either an unencrypted (plaintext) PDU or an encrypted PDU. The value of the MessageFlags object dictates which one is the case.

An important point to note about the SNMPv3 USM is that it provides authentication and privacy at the message level. The view-based access control mechanism operates at the PDU level and determines if access to a given MIB object should be granted to a principal (or user). These issues are comprehensively covered in [Zeltserman1999].

We now look at some SNMPv3 message exchanges, using Figure 2-2. In an effort to solidify the above concepts, Figure 2-2 has a good deal of detail—hopefully not too much.

Figure 2-2. SNMP GetRequest and GetResponse messages.

Figure 2-2 illustrates a network with a management system (containing SNMP Manager A) connected to an IP router. The router has three network interfaces: A, B, and C. It hosts an SNMP agent (Agent A). The management system host is connected to Interface B on the IP router. Router interface A is connected to another network segment on which a server is located. The server hosts SNMP Agent C. Router Interface C is connected to a PC that hosts SNMP Agent B.

An important point to note is that the PDU fields in Figure 2-2 are SNMPv2c PDUs; that is, SNMPv3 introduced no new PDUs. So, let's take a look at Figure 2-2 starting with a GetRequest-GetResponse message exchange.

Manager A in Figure 2-2 wants to retrieve the value of the ipInReceives.0 object instance from Agent B. So, Manager A builds a GetRequest message. The network operator is a little worried about hackers, so the message is authenticated and encrypted before being sent across the network. Step 1 is now complete. Agent B receives the message, processes it (applying the required security processing), and retrieves the required MIB object instance. Next, Agent B builds a response message, applies the required security, and sends the message back to Manager A. Step 2 is now complete. After verifying the message security, Manager A will now extract the required data and store it in some application-specific fashion (usually in a database). A few points can be made about Figure 2-2:

Manager A now has the required data. Usually, an NMS makes many such requests simultaneously, often requesting entire tables at a time.

If Manager A wants to perform a getNextRequest on the ipInReceives.0 object, then the only differences required in Figure 2-2 are as follows:

After this message exchange, Manager A has the required data.

GetBulkRequest is a clever way of retrieving a range of objects from a table. The required objects are provided in a variable-bindings list. The objects are retrieved based on the values of two numbers:

So, let's say we want to retrieve the number of interfaces on a given NE and then use that number to retrieve the speed of those interfaces. This can be done with one or more getRequests, but we can do it in one step using getBulkRequest. Our non-repeater is the object interfaces.ifNumber. This value will also be used to specify the max-repetitions for the object interfaces.ifTable.ifEntry.ifSpeed. So, the call to a conceptual GetBulkRequest API might look like the following:

GetBulkRequest(non-repeaters = 1, max-repetitions = interfaces.ifNumber,
   varBindList = {interfaces.ifNumber, interfaces.ifTable.ifEntry.ifSpeed } )

GetBulkRequestNonRepeater = interfaces.ifNumber.0
Type and Value = Integer32      5 =====> So, the number of interfaces is 5

GetBulkRequestMaxRepetitions of 5 =====> We now get the 5 interface speeds

Variable = interfaces.ifTable.ifEntry.ifSpeed.1
Value    = Gauge32 155000000
Variable = interfaces.ifTable.ifEntry.ifSpeed.2
Value    = Gauge32 155000000
Variable = interfaces.ifTable.ifEntry.ifSpeed.3
Value    = Gauge32 100000000
Variable = interfaces.ifTable.ifEntry.ifSpeed.4
Value    = Gauge32 4294967295
Variable = interfaces.ifTable.ifEntry.ifSpeed.5
Value    = Gauge32 4294967295

From this, we can see that the host (in this case, an MPLS label edge router) to which the GetBulkRequest was sent has five high-speed interfaces supporting bit rates of 155Mbps (155000000), 100Mbps (100000000), and 4Gbps (4294967295) respectively.

If Manager A wants to execute a getBulkRequest on the IP table, then the only differences required in Figure 2-2 are the following:

After this message exchange, Manager A has the required data. Typically, this type of operation might occur during a discovery procedure; that is, NE x has been found, so we discover its attributes (number and type of interfaces, speeds, etc.).

A SetRequest message follows a very similar set of steps. The only differences required in Figure 2-2 are the following:

After this message exchange, Manager A has modified the required data. Typically, this type of operation might occur during a provisioning procedure; that is, we wish to alter some data in NE x, so we execute a set (e.g., add a new row to a MIB table or reset a counter to zero). We will see examples of this in the MPLS MIB tables in Chapters 8 and 9.

We now describe the notification mechanism. A notification message can be either a trap or an inform. Let's now look at an example of a notification. Agent A on the IP router in Figure 2-2 now detects that one of its three network interfaces has gone into the down state (link failure is a commonly occurring hardware fault). This is illustrated in Figure 2-2 with an X on Interface A. It can no longer send or receive network traffic on that interface. The IP router agent has to notify its registered manager of this event, so it sends a notification message to Manager A. Manager A receives the notification, processes it, and realizes that the host for Agent A now has only two working network interfaces. Unfortunately, Manager A can no longer contact SNMP Agent C. Typically, this event would be propagated upwards to a GUI topology, where the associated network link icon (for the link attached to Interface A) would change color to red. Or, the subnet containing the router could change color. Manager A could then poll the router MIB to verify the interface state. The notification has fulfilled its purpose, because the problem can now be resolved. This is the power of notifications: Intelligence is distributed in the SNMP agents, and they emit notifications if and when problems occur. It is then up to the management system to try to resolve the problem if one exists. Notifications do present scalability concerns, particularly as network sizes increase. Many notifications occurring simultaneously can have unforeseen consequences for both the network and the management system.

We now briefly describe the notification PDU and start with a look at an SNMPv1 Trap PDU, illustrated in Figure 2-3.

Figure 2-3. SNMPv1 trap.

The trap PDU fields in Figure 2-3 have the following meanings:

Chapter 7 has an example of some SNMPv1 traps that occur during a security violation (Figure 7-11). We now briefly look at an SNMPv2 trap PDU in Figure 2-4.

Figure 2-4. SNMPv2 trap.

The fields in Figure 2-4 are identical to those of a get, get-next, or set PDU. The only difference is the type value of 0xA7. The main difference between this message and an SNMPv1 trap is that the variable-bindings field (often called the varbind) is made up of:

Each SNMPv2 trap is defined in the MIB using the NOTIFICATION-TYPE macro [Zeltserman1999]. Typically, an NE emits a notification when it wants to inform the manager of some important event or fault, such as a link going into the down state.

The last PDU we will look at is the SNMPv2 inform. The only difference between an inform and an SNMPv2 trap is that the type value for an inform is 0xA6. Informs use a timeout/retry mechanism in an effort to ensure delivery to the manager. By their nature, notifications occur at undefined moments in time. Once a notification message is received, the NMS must decode it and then try to figure out the origin of the problem. This is sometimes called root-cause analysis, which when successful, allows the network operator to understand the exact nature of the problem that caused the notification. Root-cause analysis should also help the user in fixing the problem (if one exists).

An important point to note is that for get and set operations to succeed, the manager must have the appropriate access rights. This means that the access policy (mentioned earlier) must be configured to allow the manager appropriate read and write access. If a manager attempts an operation for which it does not have access privileges, then the operation will fail.

Another important point is that SNMP management messages can refer to many objects, not just to one, as in the preceding examples. In other words, the SNMP GetRequest message in Figure 2-2 can include more objects than just the ipInReceives object (up to the maximum size allowed by the transport service). However, agents will generally have a maximum packet size that they can handle. A manager must be prepared to handle the case in which an agent packet-size limit is too small for it to return instances of all objects which the manager requested. In this case, the manager will probably need to separate the requests into multiple packets.

As we saw in Figure 2-2, SNMPv3 provides both authentication and encryption (privacy). Authentication is provided by the industry-standard MD5 hashing scheme or by Secure Hash Algorithm (SHA), and privacy is provided by DES. The configuration settings required on the agent side are generally as follows:

The settings for Figure 2-2 consist of authPriv (i.e., both authentication and privacy). The two passwords are used during message encryption and authentication. For enhanced security, it is important that network operators change these passwords regularly.

Like all great ideas, MIBs are fairly simple to understand. They provide a detailed description of the managed objects supported by a given device. As mentioned earlier, the MIB defines managed objects in a conceptual way, including the syntax and semantic information about each object. These managed objects can then be instantiated as real objects in an agent host device. Figure 2-5 is an extract from one of the draft MPLS MIBs [IETF-TE-MPLS] taken from the IETF Web site. As usual, we try to present the overall picture of a complete MIB. We will examine this MIB more closely in Chapter 8, “Case Study: MPLS Network Management.” It illustrates most of the general detail needed to understand MIBs. From Figure 2-5, we can see that MIBs are made up of just a few sections clearly identified by keywords. The main points of Figure 2-5 (identified by numbers and corresponding arrowheads) are the following:

Figure 2-5. An extract from one of the draft-standard MPLS MIBs.

Figure 2-5 therefore includes most the elements of a MIB structure that will be encountered in practice.

MIB objects can be scalar (such as integers) or tabular (rows of other objects). In Chapter 8 we look closely at tables, particularly the MPLS MIB tables. The objects defined in the MIB are instantiated in the agent host and can be retrieved using a get operation via a MIB browser. Similarly (if they are read-write), they can be modified using a set operation. The SNMP agent asynchronously dispatches device notifications. Notifications are sent to a preconfigured IP address, usually that of the NMS.

Managed objects are the basic unit of exchange between an NMS and NEs. The managed objects are defined in the MIB and deployed in the network. The NMS provides software that, combined with the managed objects, gives the user the means of operating and maintaining the network. The importance of MIBs and managed objects cannot be overstated. The managed objects defined in the MIB must match the user's needs: not too detailed and also not too coarse-grained.

One merit of a standard MIB is ease of extension. As new technologies are invented and deployed, the associated managed objects must be defined in new MIB modules. The latter can then be added to the standard MIB in an orderly fashion, e.g., by using enterprise-specific numbers. New objects can be defined and included in MIB module files, such as the MPLS MIB files we will see in Chapter 8. The objects in such files are implemented in the NEs that support the associated technology (e.g., MPLS). The important point to note is that these are extensions to the standard MIB, i.e., there is only one MIB.

It may be helpful to draw some comparisons between a standard operating system (such as UNIX or Windows 2000) and an NMS. Both provide a set of abstractions to assist in the end use and management of the system. In the case of operating systems, some of the abstract objects are:

These abstract entities map onto real objects that users and applications employ for getting work done. NMS also employ the above objects in addition to other objects specific to network management. These NMS abstract objects are:

These objects are used for managing networks. The NMS employs these objects and provides additional abstractions (GUI, software wizards, etc.) to assist the network operator.

As we've seen, an LSP is an automatically or manually configured (optionally traffic-engineered with optional QoS) path through an MPLS network. An LSP originates on an LER, passes through zero or more LSRs, and terminates on another LER. The path taken by the LSP can be set by the operator or computed by the LER. Network resources, such as bandwidth, can be reserved along the path, or the LSP can offer a best-effort service.

With reference to the MIBs examined in Chapter 8, an LSP is comprised of the following components on the originating LER:

Each LSR in the core then supports the LSP by providing the following components:

Finally, the terminating LER provides the endpoint for the LSP using the following components:

So, a notional network made up of two LERs and one LSR with an LSP spanning all three nodes might look like Figure 2-8.

Figure 2-8. LSP components.

Figure 2-8 illustrates the above components as well as another important concept: the IP/MPLS boundary. This boundary is the edge of the MPLS cloud; that is, on the IP side of the boundary there is only IP—all MPLS labels have been stripped off. On the MPLS side of the boundary there can be both IP and MPLS. In other words, there is no reason why pure IP traffic cannot traverse an MPLS core. Why might this arise? One possibility is that a packet arrives with a destination IP address that is not served by any existing LSP. In this case, the packet can be routed hop by hop through the MPLS core.

Packets arriving on the edge of the IP/MPLS boundary are subjected to a normal IP lookup, but if their destination address is served by an LSP, then they are MPLS-encapsulated and pushed into the appropriate tunnel (as illustrated in Figure 2-8). The encapsulated packets then pass through the segments and cross-connects of the LSP path, consuming any of the resources reserved on that path. One important part of LSP setup is the programming of the hardware. One of the major drivers of MPLS is that the MPLS management plane hides the platform-specific details. In this way, the platform-specific protocols impose the required labels, traffic engineering requirements, and QoS settings on the relevant interfaces across the network. The network operator employs the management interface to initiate this process. SNMP, in this context, is just another management interface, as is a CLI.

LSPs are set up from edge to edge traversing the LSRs in the core. LSPs serve as a conduit for transporting MPLS traffic from the point of ingress at the edge to the point of egress on another edge. We will see the structure illustrated in Chapter 8. One final important point about MPLS is that it is not restricted to carrying just IP traffic. The traffic landing at LER1 can also be Ethernet, ATM, and TDM. Carrying legacy traffic is an important part of MPLS.