Network Management for Microsoft Networks Using SNMP

Article
02/20/2014

Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

By Karanjit S. Siyan, Ph.D.

networkm

Chapter 11 from Windows NT : TCP/IP, published by New Riders Publishing

TCP/IP networks use a standard management protocol called Simple Network Management Protocol (SNMP). The SNMP protocol is widely used in the industry. While SNMP was developed as a solution for network management on TCP/IP networks, it is not limited to TCP/IP networks. The SNMP protocol can be run on other transport protocols such as IPX, AppleTalk, and OSI.

Windows 9x and Windows NT Workstations and Servers can be configured with an SNMP agent. This SNMP agent is automatically installed when the TCP/IP protocol is installed for Windows NT version 5 and later. For Windows NT Server 4 and earlier, you can add the SNMP agent for Windows NT_as a seperate step. After you configure the SNMP agent, the Windows station management variables can be accessed and set from a central SNMP Network Management Station.

In this chapter, the fundamental concepts of SNMP are reviewed. These concepts apply to SNMP implementations on any platform including Microsoft operating system platforms. Before discussing SNMP a model for network management is presented. This model describes the goal of network management and is applicable for most modern network management protocols including SNMP.

Obtaining the Network Management System Software

Windows 9x and Windows NT ships only with the SNMP agent software and not with the Network Management System software. However, a number of SNMP vendors supply the Network Management System software.

A Model for Network Management

Figure 11.1 shows a model for network management. In this model, the network consists of several devices that have a management agent running in them. The management agent has knowledge of the device parameters it runs on. Some of the device parameters are specific to the device that is managed. For instance, router devices will have parameters that describe the routing table. All devices can be expected to have some common parameters such as the name of device, how long the device has been active (up time), and so on.

Figure 11.1 shows that the agents can be managed by a special device called the Network Management Station (NMS). The Network Management Station can issue specific requests to a device for information about its network parameters. The agent for the device will receive these requests, and send back the requested information. The Network Management Station, upon receiving the reply, knows the value of the requested parameters. It can use this information to deduce information on the state of the device and whether the device requires attention.

It might also be important to prevent an unauthorized Network Management Station from obtaining information on the devices on the network. This requires that some authentication scheme be implemented that will prevent unauthorized access.

Figure 11.1: Model for network management.

Figure 11.2 shows the goal of network management. The network is shown as a "cloud" that has both input and output. The network input is the shared data and the activity generated by users of the network. The network output is the increased efficiency that results from information sharing. The network is subject to disturbances in the form of computers, devices and network links becoming inoperational. The goal of network management is to monitor the status of the network, and use control mechanisms to achieve the desired output (increased efficiency) despite the network disturbances.

The mechanisms used for monitoring and controlling the network should be such as to have a minimal impact on the network. In other words, the protocols used to collect information should not impact the performance of the network and the devices that are managed. If the network management mechanism uses up most of the network bandwidth, very little will be available for the network users. In this case the network traffic will be disrupted or the network will slow down because user network traffic must compete with network management traffic for bandwidth. The network agents running on the devices should not consume a great deal of processing power on their devices; otherwise, the device may not be able to perform its normal functions in the desired time.

The Managed Node

The device that is being managed by the Network Management Station is called the managed node. The managed node (see Figure 11.3) has parameters that the Network Management Station can query and obtain values for. A management protocol is used as the means to establish communications between the Network Management Station and the managed node and send queries and receive responses. An example of this management protocol is SNMP (Simple Network Management Protocol).

Figure 11.2: The goal of network management is to achieve desired output with minimum disturbance to the network.

Figure 11.2: The goal of network management is to achieve desired output with minimum disturbance to the network.

Figure 11.3: The managed node.

The management protocol interfaces with the network management instrumentation within the managed node. The management instrumentation has internal knowledge of the parameters and memory locations within the managed node. When a query is received through the management protocol, such as SNMP, the network management instrumentation receives the request and accesses the managed node's parameters. The results are reported back to the Network Management Station by the management instrumentation by using the network management protocol.

There has been considerable activity in the development of SNMP and MIBs (see the following section) for various devices. The following are some of the more recent and relevant RFCs as they pertain to SNMP:

RFC 2021 PS. S. Waldbusser, "Remote Network Monitoring Management Information Base Version 2 using SMIv2," 01/16/1997. 130 pages, .txt format.
RFC 2012 PS. K. McCloghrie, "SNMPv2 Management Information Base for the Transmission Control Protocol," 11/12/1996. 10 pages, .txt format, updates RFC1213.
RFC 1910 E. G. Waters, "User-based Security Model for SNMPv2," 02/28/1996. 44 pages, .txt format.
RFC 1909 E. K. McCloghrie, "An Administrative Infrastructure for SNMPv2," 02/28/1996. 19 pages, .txt format.

Managed Node versus Managed Device

In the discussion on SNMP, the managed node is often called the managed device. These terms are used interchangeably in this chapter.

RFC 1907 DS. J. Case, K. McCloghrie, M. Rose, S. Waldbusser, "Management Information Base for Version 2 of the Simple Network Management Protocol (SNMPv2), " 01/22/1996. 20 pages, .txt format, obviates RFC1450.
RFC 1757 DS. S. Waldbusser, "Remote Network Monitoring Management Information Base," 02/10/1995. 91 pages, .txt format, obviates RFC1271.
RFC 1451 PS. J. Case, K. McCloghrie, M. Rose, S. Waldbusser, "Manager to Manager Management Information Base," 05/03/1993. 36 pages, .txt format.
RFC 1446 PS. J. Galvin, K. McCloghrie, "Security Protocols for Version 2 of the Simple Network Management Protocol (SNMPv2), " 05/03/1993. 51 pages, .txt format.

Management Information Base (MIB)

The parameters in the managed node are called management objects. The set of these management objects is called the Management Information Base (MIB). The MIB can be conceptually regarded as a database. The objects in the MIB, also called variables, have a number associated with them that is used to uniquely identify the object. This number is called the object id. The object id is based on a hierarchical numbering scheme and allows the variable in the MIB to be ordered. The ordering of the variables means that given an object id for a variable, you can determine the "next" variable that follows. The ordering of the MIB variables is conceptually similar to the indexing that orders records in a database.

A MIB variable also includes a status flag indicating whether the variable is read-only or has read-write access.

A certain set of standard MIB variables exists for the different protocol elements of TCP/IP. These MIB variables deal with parameter values for IP, ICMP, TCP, SNMP, EGP (Exterior Gateway Protocol) and Address Translation tables.

Data-link interfaces such as Ethernet, Token-Ring, SMDS, and ATM have their own set of MIB variables. It is even possible for a vendor of a special device to have MIB variables specific to that device. MIB variables that are specific to a vendor's device are called proprietary MIBs. There are interface mechanisms that enable an SNMP manager to take a description of a proprietary MIB and compile it to so that it becomes part of the MIB variables known to the SNMP Manager. For example, many of the Windows NT specific parameters such as those for DHCP and WINS have their own MIB definitions. These Windows NT–specific parameters can be monitored and controlled using a Network Management Station.

The Management Paradigm in SNMP

The Network Management Station for SNMP is called the SNMP Manager. The SNMP Manager uses a management paradigm that is called the remote debugging paradigm (see Figure 11.4). In this paradigm, the SNMP Manager is similar to a programmer at a workstation debugging programs from a remote location. Such a hypothetical programmer would be interested in reading the values of variables in the program and changing the values of certain critical variables. Likewise, the SNMP Manager should be able to read and update values of MIB variables on the managed devices. The SNMP Manager should be able to perform the following actions:

Read or read-write of MIB variables
Trap-directed polls
Simple traversal of variables in the managed node

When an exceptional condition occurs at a managed device, such as failure of a link or a critical change in status of a device, the managed device sends a trap SNMP message to the SNMP Manager. The trap message contains an indication of the event that caused the generation of the message. It is up to the SNMP Manager to respond to the trap message. The SNMP Manager can simply log the message in a trap log file, or take more extensive action. The SNMP Manager can, for instance, request additional information from the device that generated the trap message. The additional information can be obtained through read requests for specific MIB variables. If the SNMP Manager is programmed for control of the device, it can issue a write request to modify the value of a MIB variable.

All control actions within SNMP occur as a "side effect" of modifying a MIB variable. For example, if a device is to be powered-off remotely from an SNMP Manager, the SNMP Manager could send a write request to modify a MIB variable called the

Figure 11.4: SNMP Manager paradigm.

ifPowerOn variable. The managed device can be programmed so that the ifPowerOn variable causes the following side effect: the value of the variable is normally 1; if the value is 0, the device will be powered off. The managed device, upon sensing a value of 0 in its ifPowerOn variable, can initiate a device shutdown.

Because the MIB variables are ordered according to their object identifiers, the SNMP manager can traverse all the variables in the device using an SNMP command called GetNext. This is called a simple traversal of the MIB.

Because SNMP uses side effects to initiate control actions, the SNMP commands consist of only the following:

Get (Read a MIB variable)
Set (Write a MIB variable)
GetNext (Return the next MIB variable)
Trap (Sent to SNMP manager to report exceptional conditions)

Note that the terms trap and event are synonymous because the occurrence of an SNMP event generates an SNMP trap message.

SNMP Commands and Protocols

Figure 11.5 shows the SNMP commands and the transport and protocols SNMP depends on. The SNMP Manager can issue any of the following commands:

Get
GetNext
Set

Figure 11.5: SNMP architecture.

These commands are sent using the UDP/IP protocols to the SNMP agent. The SNMP agent can send a GetNext_Response SNMP command in reply to the SNMP Get request or GetNext request from the SNMP Manager. The SNMP Set command from the SNMP Manager is not explicitly acknowledged. In other words, there is no such command as a Set_Response command sent from the SNMP agent to the SNMP Manager. The trap events are sent from the SNMP agent to the SNMP Manager when exceptional conditions occur in the managed device.

SNMP Traps

When an unusual condition occurs in the SNMP device, the SNMP agent alerts the SNMP Manager through SNMP traps. Figure 11.6 shows a sample network showing some of the trap messages that can be generated by SNMP agents.

The EGP protocol was at one time widely used on the Internet. Its inclusion as an SNMP trap message is to support those sites that may still be using it. The SNMP agent must be configured to send trap messages to an SNMP Manager station.

Table 11.1 summarizes the different SNMP trap messages that can occur.

Figure 11.6: SNMP Traps.

Table 11.1 SNMP Trap Messages

Parameter	Description
Link up or link down	When a network interface on the managed device fails, a link down trap message is generated; if the network interface comes back to life, a link up trap message is generated.
Cold start or warm start	When an SNMP agent starts, a cold start trap message is generated. If the SNMP initializes its table, a warm start trap message is generated.
Authentication failure	When an SNMP agent receives an SNMP request with a community name that does not match the community name the device is configured with, an authentication failure trap message is generated.
Loss of EGP neighbor	When an SNMP agent cannot communicate with its EGP (Exterior Gateway Protocol) neighbor, a loss of EGP _neighbor trap message is generated.

On a NetWare network, any of these trap messages can occur except for the loss of EGP neighbor trap.

SNMP Object Identifiers and Messages

The following sections discuss the structure of SNMP messages. In this treatment, only the widely used SNMP version 1 message structure is discussed. SNMP version 2 currently is not widely used.

Many SNMP messages and replies contain the name of the MIB object whose value is being sought. Before discussing the SNMP message structure, the names used to describe MIB objects are discussed.

SNMP Versions 1, 2 and 3

SNMP version 2 provides for better authentication and a more uniform syntax for SNMP messages, in which trap messages are similar to other messages. SNMP version 2 provides better support for non-TCP/IP protocols and mechanisms for communication between SNMP manager stations. SNMP version 2 defines a new get_bulk SNMP message that is used to make a request for all of the MIB variables in a device. This is an improvement over SNMP version 1, in which repeated get_next messages must be sent to read all of the MIB variables for a device. SNMP version 2 had not been widely implemented because of acrimonious disagreements over the standard between the major authors of SNMP. SNMP version 3 is expected to resolve these differences. SNMP version 3 is expected to include support for IP version 6, the replacement for the current IP protocol, called IP version 4.

MIB Object Identifiers

In SNMP, MIB objects are given a unique object identifier consisting of a sequence of numbers separated by a period (.). These sequences of numbers are read from left to right and correspond to nodes of the object name tree. Figure 11.7 shows a partial object name tree that shows the object identifiers for the MIB objects sysDescr and sysLocation. The topmost nodes in the tree represent different committees and high-level organizations responsible for the composition of the name underneath its tree branch. The following topmost nodes are defined:

ccitt(0). The nodes under the ccitt(0) branch are administered by the International Telegraph and Telephone Consultative Committee.
iso(1). The nodes under the iso(1) branch are administered by the International Organization for Standardization and the International Electrotechnical Committee (ISO/IEC).
joint-iso-ccitt(2). The nodes under the joint-iso-ccitt(1) branch are jointly administered by the International Telegraph and Telephone Consultative Committee, the International Organization for Standardization, and the International Electrotechnical Committee.

Figure 11.7: Object name tree.

Network management is defined under the iso(1) tree branch. Under this tree branch are a number of subordinate organization definitions. Network Management falls under the org(3) node.

Under the org(3) node are a number of subordinate organizations. Network Management falls under the dod(6) node for the Department of Defense (DoD).

Under the dod(6) node are a number of subordinate networks. Network Management falls under the internet(1) node for the Internet.

Under the internet(1) node are a number of subordinate nodes representing different standardization efforts in the area of directory, management, experimental and private MIBs. Network Management objects that have been standardized fall under the mgmt(2) node.

Under the mgmt(2) node are a number of subordinate nodes representing different standardization efforts. Network Management objects that have been standardized fall under the mib-2(1) node.

Under the mib-2(1) node are a number of subordinate nodes representing groupings of MIB variables. Figure 11.7 shows the system(1) and interfaces(2) MIB variable groupings.

Under the system(1) node are shown the two MIB variables: sysDescr(1) and sysLocation(2). The object identifiers for these variables are defined by enumerating the node numbers starting from the top of the object name tree to the MIB variable object. These numbers are written from left to right and are separated by periods. Therefore, the object identifiers for these MIB variables have the following names:

sysDescr:	1.3.6.1.2.1.1.1
sysLocation:	1.3.6.1.2.1.1.2

Notice that there is a natural ordering of the MIB variables. The "next" variable after sysDescr is sysLocation because the last number in the object identifier representation changes from 1 to 2.

SNMP Messages

SNMP message formats are variable in length and are complex. A subset of the ASN.1 (Abstract Syntax Notation, version 1) language is used to describe the SNMP message structure. ASN.1 is a fairly intuitive language, although its rigorous definition is beyond the scope of this book. As an example of the intuitive nature of this language, consider the following, which describes the structure of an Ethernet frame using ASN.1:

Ethernet-Frame ::= SEQUENCE {

destAddr OCTET STRING (SIZE(6)),

srcAddr OCTET STRING (SIZE(6)),

etherType INTEGER (1501..65535),

data ANY(SIZE(46-1500)),

crc OCTET STRING(SIZE(4))

}

Note that the information following the double colon (::=) defines the variable listed before the double colon—in this case, Ethernet-Frame. The SEQUENCE {} represents an ordered list of items inside the braces ({}). The ordered list is the fields of the Ethernet frame, such as the destination address, source address, Ethernet type, data, and CRC.

The type of each field is named immediately after the name of the field variable. For example, destAddr and srcAddr are each defined as the type OCTET STRING, which defines a data type taking 0 or more octets as its value. Each octet in the octet string can vary in value from 0 to 255. The size of the octet string is placed after the OCTET STRING type.

etherType is defined to be an INTEGER that is an integer value of arbitrary size and precision. The (1501..65535) placed immediately after the INTEGER defines its size.

The data field is of type ANY, and is between 46 and 1500 octets long.

The crc field is a 4-octet OCTET STRING.

Using the ASN.1 notation, all SNMP messages can be considered to have the following format:

SNMP-message ::= SEQUENCE {

version INTEGER {version-1(1)},

community OCTET STRING,

data ANY}

This message format is shown in Figure 11.8, which explains the meanings of the fields.

Figure 11.8: SNMP message format.

version is the version number of the message format. community is a string value that is sent in every SNMP message. An agent receiving an SNMP message checks the community name against its configured community name value. If there is a match, the operation requested in the SNMP message is performed. If there is no match, the SNMP agent sends an SNMP trap message indicating authentication failure. This is a very simple authentication scheme because the community name is like a password. The problem with this authentication scheme is that the password is not encrypted and is sent in the clear.

Note that in most SNMP implementations, including the one in Windows NT, the SNMP agent will only send an authentication failure if it is configured to do so.

The data field represents the details of the different SNMP messages such as the GetRequest, GetNextRequest, GetResponse, SetRequest, and Trap. The format of these message types is described in Figures 11.9 and 11.10.

SNMP Support for Windows NT

Although SNMP has its origins on TCP/IP networks, it has been adapted for use over IPX, DECNET, and OSI protocols. On a Windows NT network, SNMP is typically used over the TCP/IP protocol.

Windows NT computers include support for SNMP and define MIB objects for Windows NT, DHCP, and WINS servers. The following sections discuss installation and configuration of basic SNMP services.

Figure 11.9: SNMP PDU format.

Figure 11.10: Trap PDU format.

Installing SNMP on Windows NT

Normally, the SNMP agent is installed on the NT computer at the time you install and configure the TCP/IP protocol. This is true if you are running Windows NT Server 5 and later. For Windows NT Server 4 and earlier, you can add the SNMP agent for Windows NT as a separate step. In case the SNMP agent is not installed, you install the SNMP service by adding the SNMP Service option in the Windows NT Network Services dialog box.

The following is an outline of the procedure for installing SNMP on Windows NT if you have not installed it on the computer. To install SNMP, you must have the TCP/IP protocol installed.

Log on to the Windows NT Server as an Administrator user.
Double-click the Network icon in the Control Panel.
Choose the Services tab from the Network dialog box.
Click the Add button.
Highlight the SNMP Service option and choose OK.

You should see a dialog box prompting you for the path of the distribution files. If you have a CD-ROM on the Windows NT Server, the path contains the path to the CD-ROM distribution files.
Ensure that you have the appropriate distribution media in the install device and click Continue.

You should see a status of the copy operation as files are copied. At the end of the file copy, the SNMP Service Properties dialog box appears.
You must reboot for changes to take effect.

The following sections discuss configuring various SNMP properties.

Configuring the SNMP Agent

All SNMP devices have MIB values for information on the contact, location, and type of service. You can specify these values by configuring the SNMP agent running on the Windows NT computer.

The following is an outline of the procedure for configuring SNMP agents in Windows NT version 5 and later:

Log on to the Windows NT Server as an Administrator user.
Select Start, Programs, Administrative Tools, SNMP Service (see Figure 11.11).
Choose the Agent tab in the SNMP Properties dialog box, if this is not already selected.
In the Contact field, enter the name of the person or organization responsible for the Windows NT computer. For example, if Bob Smith is the owner or administrator responsible for the Windows NT computer, you can enter his name here.
In the Location field, enter the location of the Windows NT computer. For example, if the Windows NT computer is on the 3rd floor of the Financial Services building you can enter a value of "Floor #3, Financial Services Bldg".
In the Service box, select all options that apply to the Windows NT computer.
Choose the Physical option if the Windows NT computer manages a physical device, such as a repeater (Windows NT can be used as an embedded system).
Choose the Applications option if the Windows NT computer runs TCP/IP applications, such as FTP. This option should be selected for all Windows NT computers.
Enable the Datalink/Subnetwork option if the Windows NT computer manages a datalink device, such as a bridge or TCP/IP subnetwork.
the Internet option if the Windows NT computer acts as a router (also called IP gateway).
Check the End-to-End option if the Windows NT computer acts as a host (called end-system in the OSI model). This option should be selected for all Windows NT computers.
You can choose OK on successive screens to complete the SNMP service configuration, or go on to the next tab, Traps, discussed in the following section.

Configuring SNMP Traps

To configure SNMP traps, follow these steps:

Use the steps described in the previous section, "Configuring the SNMP Agent," to access the SNMP Services.
Select the SNMP Properties Traps tab, which identifies the communities and trap destinations (see Figure 11.12).

Community names are used for authentication purposes. An SNMP agent responds to an SNMP command only if the command includes a community name of which it is aware. In other words, the community name acts as a simple password scheme.

When the Windows NT SNMP service receives a request for information that does not contain a valid community name and does not match an accepted host name for the service, the SNMP service sends an authentication-failure trap message to the trap destinations for the community name.
To add community names that the Windows NT computer knows about, enter the community name in the Community Names field and click the Add button. When the Windows NT computer sends trap messages, it includes the community name in the SNMP packet when the trap is sent. To delete a community name, highlight it and click the Remove button.

You can use any alphanumeric characters for community names. Community names are case-sensitive. All hosts typically belong to the community name _public, which is the standard name for the common community of all hosts.

Figure 11.11: Microsoft SNMP Properties.

Figure 11.12: SNMP Traps configuration.
In the Trap Destination box, you enter the trap destinations for a selected community name that receives trap messages. Trap destinations are specified by listing the IP address of hosts (usually SNMP Managers) that receive the trap messages by the SNMP service running on the Windows NT computer.
To enter trap destinations, highlight the community name to which you want the Windows NT computer to send traps. Next, enter the IP address or IPX address of the host in the IP Host/Address Or IPX Address field. Click the Add button to add to the list of trap destinations. To delete a trap destination from the list, highlight it and click the Remove button.

Configuring SNMP Security

Windows NT SNMP Services enables you to specify the community names and hosts that the Windows NT computer will accept requests from. You also can specify whether to send an authentication trap when the Windows NT computer receives an unauthorized community in an SNMP command.

The following is an outline of the procedure for configuring SNMP security on Windows NT:

Use the steps described in the previous section "Configuring the SNMP Agent" to access the SNMP Services.
Select the SNMP Security tab, which identifies the security related parameters (see Figure 11.13).
If you want to enable the sending of SNMP trap messages for unsuccessful authentications, set the Send Authentication Trap option (see Figure 11.13); otherwise, clear the check box for this option. The default is to send authentication trap messages on unsuccessful authentication attempts.

Figure 11.13: SNMP Security.
In the Accepted Community Names list, enter the community names from whom the Windows NT computer accepts requests. By default, requests that have the community name public are always accepted, which is why you see the community name public already listed in Figure 11.13. To add additional community names, enter the community name in the Accepted Community Names field, and click the Add button. To remove a community name from the Accepted Community Names list, highlight it and click the Remove button.
You can select an option to accept SNMP packets from any host or only from specified hosts.

If the Accept SNMP Packets from Any Host option is selected, SNMP packets are not rejected on the basis of their address. This option is selected by default.

If the Only Accept SNMP Packets from These Hosts option is selected, SNMP packets are filtered based on their source address. Only those SNMP packets that are from the hosts listed are accepted; all other SNMP packets are rejected. In the Only Accept SNMP Packets from These Hosts box, enter the host name, IP, or IPX address of the hosts from which the Windows NT computer accepts SNMP requests. Next, click the Add button to add to the list of accepted hosts. To delete an entry in the host list, highlight it and click the Remove button.
Choose OK on successive screens to complete the SNMP Service Configuration.

About The Author

Karanjit S. Siyan, Ph.D., is an author of the original TCP/IP specification. Since its inception, Dr. Siyan has been actively involved in the technology and helped shape its evolution. This book is the result of many years of working with and developing TCP/IP applications on a variety of platforms, particularly Windows. Dr. Siyan has authored and presented international seminars on TCP/IP networks, Solaris and SunOS, PC Network Integration, Windows NT, Novell networks, and expert systems using fuzzy logic. He teaches these advanced technology seminars in the United States, Canada, Europe, and the Far East.

Dr. Siyan has worked extensively with UNIX®, NetWare, OS/2, and computer languages such as C/C++, Pascal, LISP, Algol, Ada, MSL, Jovial, and Java®. He has written compilers for a number of programming languages and is actively involved in Internet research. He also has published articles in Dr. Dobbs Journal, The C Users Journal, and Database Advisor. Dr. Siyan holds a Ph.D. in Computer Science, a Masters degree in Electrical Engineering and Computer Science, and a Bachelor's degree in Electronics and Electrical Communication Engineering. He is a member of IEEE and ACM, and his career achievements are recorded in Marquis' Who's Who in the World, Who's Who in America, Who's Who in Finance and Industry, and Who's Who in Science and Engineering.

We at Microsoft Corporation hope that the information in this work is valuable to you. Your use of the information contained in this work, however, is at your sole risk. All information in this work is provided "as -is", without any warranty, whether express or implied, of its accuracy, completeness, fitness for a particular purpose, title or non-infringement, and none of the third-party products or information mentioned in the work are authored, recommended, supported or guaranteed by Microsoft Corporation. Microsoft Corporation shall not be liable for any damages you may sustain by using this information, whether direct, indirect, special, incidental or consequential, even if it has been advised of the possibility of such damages. All prices for products mentioned in this document are subject to change without notice. International rights = English only.

International rights = English only.

Click to order