TCPIP Management


TCP/IP Management

Management of IP-based devices is accomplished via the Internet Standard Management Framework (ISMF). The ISMF and supporting specifications are summarized in IETF RFC 3410. Many people erroneously refer to the Simple Network Management Protocol (SNMP) when they really mean to refer to the ISMF. While SNMP is a key component of the framework, several other components are required for the framework to be of any use. The five major components of the framework are as follows:

  • A modeling language, called the Structure of Management Information (SMI), for describing management data

  • A virtual store, called the Management Information Base (MIB), for organizing and storing management data

  • A protocol (SNMP) for communication between management stations and managed devices

  • A security model to provide authentication, authorization, and data protection services (such as data confidentiality)

  • Management applications to manipulate the information retrieved from managed devices

SMI is based on the ISO's Abstract Syntax Notation One (ASN.1). The most recent version of the SMI is called SMIv2. It is defined in RFC 2578. SMIv2 defines data types, an object model, and syntax rules for MIB module creation. The framework views each management datum as an object. Management objects are stored in the MIB. The most recent version of the MIB is called MIB-II. It is defined in RFC 1213. Many proprietary extensions have been made to the MIB without compromising the standard object definitions. This is possible because the MIB is modular. The internal structure of the MIB is an inverted tree in which each branch represents a group of related management objects (called a module). MIB modules are sometimes called MIBs. Vendors can define their own MIB modules and graft those modules onto the standard MIB. An agent in a managed device uses the MIB to organize management data retrieved from hardware instrumentation. Management stations access the MIB in managed devices via SNMP requests sent to agents. SNMP version 2 (SNMPv2) is the most recent and capable version of the communication protocol. SNMPv2 is defined in RFC 3416.

Chapter 12, "Storage Network Security," states that SNMPv2 uses a community-based security model, whereas SNMPv3 uses a user-based security model. More accurately stated, SNMPv2 combined with a community-based security model is called SNMPv2c, and SNMPv2 combined with a user-based security model is called SNMPv3. The fact that the same communication protocol (SNMPv2) is used by SNMPv2c and SNMPv3 is commonly misunderstood. SNMPv2 typically operates over UDP, but TCP is also supported. However, the RFC that defines a mapping for SNMP over TCP is still in the experimental state. Another common misconception is the notion that SNMP is a management application. In actuality, SNMP is an enabling technology (a protocol) for management applications. Most SNMP operations occur at the direction of a management application layered on top of SNMP.

Management stations can read MIB object values by issuing the GetRequest Protocol Data Unit (PDU) or one of its variants. Management stations can modify MIB object values by issuing the SetRequest PDU. The SetRequest PDU can be used to configure device operations, clear counters, and so on. Note that SNMP supports limited device configuration functionality. Each GetRequest PDU, variant of the GetRequest PDU, and SetRequest PDU elicits a Response PDU. Managed devices can also initiate communication. When an event transpires or a threshold is reached, a managed device can reactively send notification to the management station via the Trap PDU. A Trap PDU does not elicit a Response PDU (unacknowledged). Alternately, reactive notification can be sent via the InformRequest PDU. Each InformRequest PDU elicits a Response PDU (acknowledged).

Worthy of mention is a class of MIB modules used for Remote Network Monitoring (RMON). In the past, network administrators had to deploy physical devices to remotely monitor the performance of a network. To manage those specialized devices, a MIB module (the RMON MIB) was developed. Over time, the functionality of remote network monitoring devices was integrated into the actual network devices, thus eliminating the need for physically separate monitoring devices. The RMON MIB was also integrated into the self-monitoring network devices. As new classes of network devices came to market, self-monitoring functionality adapted. New MIB modules were defined to manage the new devices, and the RMON MIB module was also augmented. Today, several variants of the RMON MIB are defined and in widespread use.

Another management framework, called Web-Based Enterprise Management (WBEM), was developed by the Distributed Management Task Force (DMTF). WBEM seeks to unify the management of all types of information systems including storage arrays, servers, routers, switches, protocol gateways, firewalls, transaction load balancers, and even applications. WBEM aspires to go beyond the limits of SNMP. One example is WBEM's support for robust provisioning and configuration. WBEM uses the Common Information Model (CIM) as its object model. Like the MIB object model, CIM supports vendor extensions without compromising interoperability. However, CIM goes beyond the MIB object model by supporting the notion of relationships between objects. CIM also supports methods (operations) that can be invoked remotely. CIM enables a wide variety of disparate management applications to share management data in a common format. WBEM is modular so that any modeling language and communication protocol can be used. The Extensible Markup Language (XML) is the most commonly used modeling language to implement CIM, which is defined in the xmlCIM Encoding specification. HTTP is the most commonly used communication protocol, which is defined in the CIM Operations Over HTTP specification. The CIM-XML specification brings together the xmlCIM Encoding specification and the CIM Operations Over HTTP specification. WBEM supports discovery via SLP, which is generally preferred over the direct probing behavior of SNMP-based management stations. In the WBEM framework, an agent is called a CIM provider or a CIM server, and a management station is called a CIM client.

Web Services is a technology suite produced by the Organization for the Advancement of Structured Information Standards (OASIS). The Web Services architecture is built upon the Simple Object Access Protocol (SOAP), the Universal Description, Discovery and Integration (UDDI) protocol, the Web Service Definition Language (WSDL), and XML. The DMTF began work in 2005 to map the Web Services for Management (WS-Management) specification and the Web Services Distributed Management (WSDM) specification onto WBEM. Upon completion, WS-Management and WSDM will be able to manage resources modeled with CIM.

The first CIM-based storage management technology demonstration occurred in October 1999 at an industry trade show called Storage Networking World. Various working groups within the Storage Networking Industry Association (SNIA) continued work on CIM-based management projects. Simultaneously, a group of 16 SNIA member companies developed a WBEM-based storage management specification called Bluefin. The goal of Bluefin was to unify the storage networking industry on a single management interface. The group of 16 submitted Bluefin to SNIA in mid-2002. SNIA subsequently created the Storage Management Initiative (SMI) to streamline the management projects of the various SNIA working groups and to incorporate those efforts with Bluefin to produce a single storage management standard that could be broadly adopted.

The resultant standard is called the Storage Management Initiative Specification (SMI-S), which leverages WBEM to provide a high degree of interoperability between heterogeneous devices. Storage and networking vendors have developed object models for storage devices and storage networking devices, and work continues to extend those models. Additionally, object models for storage services (such as backup/restore, snapshots, clones, and volume management) are being developed. SNIA continues to champion SMI-S today in the hopes of fostering widespread adoption of the new standard. Indeed, most storage and storage networking vendors have already adopted SMI-S to some extent. ANSI has also adopted SMI-S v1.0.2 via the INCITS 388-2004 specification. SNIA also conducts conformance testing to ensure vendor compliance.

Another common function supported on storage and storage networking devices is call home. Call home is similar to SNMP traps in that they both reactively notify support personnel when certain events transpire. Unlike SNMP traps, call home is usually invoked only in response to hardware or software failures. That said, some devices allow administrators to decide which events generate a call home. Many devices support call home over modem lines, which explains the name of the feature. Call home functionality is not standardized, so the communication protocols and message formats are usually proprietary (unlike SNMP traps). That said, some devices support call home via the Simple Mail Transfer Protocol (SMTP), which operates over TCP/IP in a standardized manner as defined in IETF RFC 2821.

Similar to SNMP traps and call home, the Syslog protocol can be used to log details about device operation. The Syslog protocol was originally developed by University of California at Berkeley for use on UNIX systems. The popularity of the Syslog protocol precipitated its adoption on many other operating systems and even on networking devices. Though Syslog was never standardized, IETF RFC 3164 documents the behavior of many Syslog implementations in the hopes of improving interoperability. Like SNMP traps, Syslog messages are not acknowledged. Another useful management tool is the accounting function of the AAA model discussed in Chapter 12, "Storage Network Security." Accounting data can be logged centrally on an AAA server or locally on the managed device. Today, most devices support some level of accounting.

IP operates over every major OSI Layer 2 protocol including FC. The ANSI T11 Fibre Channel Link Encapsulation (FC-LE) specification defines a mapping for IP and ARP onto FC. However, the FC-LE specification fails to adequately define all necessary aspects of IP operation over FC. So, the IETF filled in the gaps by producing RFC 2625. Together, the two specifications provide sufficient guidance for IP over FC (IPFC) to be implemented reliably.

IPFC originally was envisioned as a server-oriented transport for use in clustered server environments, localized grid computing environments, tiered application environments, High Performance Computing (HPC) environments, and so on. However, IPFC can also be used for management purposes. Any given device (server or otherwise) that is attached to a FC fabric is inevitably also attached to an IP network. If a device loses its primary IP connection (perhaps because of a hardware failure), IPFC can be used to access the device over the FC fabric. This "back door" approach ensures that management stations can access devices continuously even in the presence of isolated communication failures. However, very few administrators are willing to compromise the reliability of SCSI operations by introducing a second ULP into their FC-SANs. Moreover, modern server platforms are commonly configured with dual Ethernet NICs for improved redundancy on the LAN. Consequently, IPFC is rarely used for management access. In fact, IPFC is rarely used for any purpose. Low latency Ethernet switches and InfiniBand switches are generally preferred for high performance server-to-server communication. Thus, IPFC is currently relegated to niche applications.




Storage Networking Protocol Fundamentals
Storage Networking Protocol Fundamentals (Vol 2)
ISBN: 1587051605
EAN: 2147483647
Year: 2007
Pages: 196
Authors: James Long

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net