Creating virtual private connections between end points across a SAN

[00002] The present invention relates to storage area networks (SANs) and, more particularly, to a method and architecture for establishing virtual, private storage area sub-networks within storage area networks.

[00003] According to the Storage Network Industry Association (SNIA), A Storage Area Network (SAN) is a network whose primary purpose is the transfer of data between computer systems and storage elements and among storage elements. A SAN consists of a communication infrastructure, which provides physical connections, and a management layer, which organizes the connections, storage elements, and computer systems so that data transfer is secure and robust.

[00004] A SAN consists of computer systems (i.e., hosts or initiators) and storage devices, usually referred to simply as devices. Because every initiator on the SAN may have access to any device physically connected to the SAN, it becomes necessary to both control and secure the access of each host initiator to the target devices. An example of this is switch zoning which is used to limit the set of physically connected devices an initiator may see.

[00005] Fibre Channel zoning utilizes Fibre Channel switches having ports that allow hosts and devices to be interconnected. These switch ports can be configured into zones. A zone is essentially a list of which ports are connected to which other ports. With a switch having 12 ports, for example, one can configure a single, 12-port network, six two-port networks, or any other combination of exclusive and/or shared access networks. Because each interface connected to a shared port can see every device connected to the other shared ports, connections cannot be restricted at the level of an individual initiator or target device. Soft zoning is available on some switches, which controls access to individual targets on the basis of the unique worldwide port name that is part of the Fibre Channel protocol. Still, there is no ability to control connections to logical units within a target device.

[00006] Because many of today's devices may present themselves as multiple individual logical units, it becomes desirable to deliver these controls on the basis of individual Logical Unit Numbers (LUNs) and not simply at the level of a single physical target device. This is generally accomplished in one of three ways: Manual Configuration; Distributed Software Applications; and Target Device Access Controls.

[00007] Manual host configuration depends on the configuration abilities of the host platforms to control access at the level of individual logical units. In order to configure access for the SAN, the administrator must manually configure each system on the SAN. The administrator must maintain his own access maps, and must access each host individually to verify, change, and maintain the configuration. This approach cannot be considered to be trusted or secure because someone with access to and knowledge of an individual host system can remove or reconfigure the access restrictions for that host, thus violating the security of the network. Some operating systems provide LUN level configuration by default; others require the development and installation of special drivers. An example of the manual configuration type of access control is found in the Solaris™ operating system by Sun Microsystems. Solaris™ uses manually edited configuration files to control which devices and LUNs to which a host is allowed to connect. Another example can be found in the Windows 95/98, NT, and Solaris™ SSA driver and adapter products shipped by the assignee of the instant invention as early as 1995. A further example is referred to as LUN masking and is found in some of the currently shipping FC Adapters and drivers by JNI and Emmulex.

[00008] Distributed software application configuration is similar to the manual approach, the major difference being that platform specific agents or services, running under the direction of a central application, perform required low-level configuration tasks. The advantage of this approach over manual configuration is that an administrator now has the ability to perform SAN configuration tasks from one physical location, using one software application package. Host and adapter specific behavior is encapsulated in the application and its agents.

[00009] Systems of this type require the development of host and driver specific software for each supported platform and interface. Software development of this nature involves a high degree of specialized knowledge about each platform and driver. Furthermore, because this approach is tightly coupled with host drivers, ongoing maintenance effort may be high. Device drivers often go through intensive testing before they are released. Similarly, an application which is driver dependent may require extensive testing before it can be released into the field as a reliable product. Another drawback to this approach is that adding access checking to the drivers may result in decreased performance due to the need for the driver to do additional work for each command processed. Also, because solutions of this nature still rely upon the correct software and configuration to be installed on each host system, they can be easily circumvented and do not provide the level of host independent trusted access security that is needed.

[00010] Target device access controls provide most sophisticated degree of control found in the access control methods of the prior art. For example, most advanced RAID controllers present themselves as multi-LUN devices containing multiple volumes, providing the ability to map these logical devices onto their physical host interconnections. The limitations to this method are similar to those of the manual host configuration method. Specifically, this capability must be separately supported for each type of target device and must include a target-specific control application. As with the two access control methods previously described, the administrator must manually configure each individual device to create the overall SAN. As with manual host configuration, the next step along this path is the development of a distributed application with the ability to interact with the access controls of the target devices to allow administration to be performed from a central location.

[00011] None of these three methods provides a satisfactory means for creating trusted, secure, reliable sub-networks (virtual private SANs) within a SAN. The inventive method and architecture provides an architecture and method which overcome each of the limitations found in prior art methods.

[00012] In U.S. Pat. No. 5,613,141 for DATA STORAGE SUBSYSTEM HAVING DEDICATED LINKS CONNECTING A HOST ADAPTER, CONTROLLER AND DIRECT ACCESS STORAGE DEVICES, issued Mar. 18, 1997 to Michael J. Szatkowski, teaches an intelligent disk controller using multiple serial links carrying data and commands in packets to and from host adapters. Multiple serial links also carry data and commands in packets to and from storage devices. The controller contains data buffers and DMA channels to handle data input and output. The inventive VPS architecture, on the other hand, uses no data storage subsystems. In addition, sophisticated connection control between host initiators and target storage devices are disclosed. This allows secure, rapid connection between specific host initiators and target storage devices.

[00013] U.S. Pat. No. 5,802,366 for PARALLEL I/O NETWORK FILE SERVER ARCHITECTURE, issued Sep. 1, 1998 to Edward John Row, et al., teaches a file server architecture comprising a network control unit, a separate file controller unit, and a storage processor unit. These units incorporate their own processors and operate in parallel with a local units host processor. All network components are connected to the network controller which performs all protocol processing up to the NFS layer. The Row, et al. system architecture operates specifically with UNIX and NFS operating systems and is strictly a file server. The inventive architecture, on the other hand, implements management functions far more sophisticated than those taught by Row, et al. For example, the virtual connection cache memory allows very rapid establishment of connections between host initiators and target storage devices whereby total end-to-end management of a secure connection is guaranteed.

[00014] U.S. Pat. No. 5,862,404 for NETWORK DEVICE DISCOVERY AND STATUS INFORMATION DISTRIBUTION USING INDEPENDENT INFORMATION DISTRIBUTION PROCESSES, issued Jan. 19, 1999 to Tyson N. Onaga, teaches management server architecture for networked devices. In the Onaga system, intelligent peripheral devices create or update files containing their current status on a file server accessible from all network work stations. Attached work stations may then request this information from the file server rather than by polling the intelligent devices directly. The VPS architecture of the present invention, on the other hand, does not centralize data in this way but rather utilizes a virtual connection cache to ensure extremely fast establishment of connections between a host initiator and a target storage device.

[00015] Because some emerging present generation devices such as the Pathlight SAN Gateway and SAN Router can now parse the upper level protocol, it becomes possible to describe virtual networks as a list of virtual private connections between a host initiator interface and a specific logical and/or physical target device. A virtual private connection does not depend upon the physical network topography for its definition.

[00016] It is, therefore, an object of the invention to provide a virtual private SAN (VPS) wherein multiple virtual storage networks may co-exist over a physical SAN.

[00017] It is another object of the invention to provide a VPS which enables multiple hosts to share a single channel to a shared storage device, while protecting the security of each host's end-to-end access.

[00018] It is an additional object of the invention to provide a VPS which is completely host-independent; requires no additional software, middleware, driver, OS or other modifications anywhere within the SAN; and therefore provides a level of security that is independent of the security of the individual hosts.

[00019] It is still a further object of the invention to provide a VPS which is also completely independent of connected storage elements and requires no changes to legacy or new storage devices.

[00020] It is yet another object of the invention to provide a VPS which is free of interface dependencies and provides direct support for Fibre Channel, SCSI, and other SAN interfaces.

[00021] It is still a further object of the invention to provide a VPS which supports all classes of SAN connectivity products, including hubs and switches.

[00022] It is another object of the invention to provide a VPS including an optional, platform specific registration service that is able to collect and transmit the host and initiator specific information necessary to provide extra functionality, including automatic host initiator interface identification and configuration.

[00023] It is yet another object of the invention to provide a VPS that includes an automatic health monitoring feature that automatically keeps track of the dynamic health status of each host initiator connected to the SAN.

[00024] It is still another object of the invention to provide a VPS that utilizes the caching of virtual connection objects to enforce access controls without incurring the performance penalties inherent in repetitive database accesses.

[00025] It is a still further object of the invention to provide a VPS that has the ability to automatically capture an existing, configuration, as manifest in the connection cache at the time, and use it to configure persistent access controls automatically.

[00026] It is an additional object of the invention to provide a VPS platform wherein any device or group of interconnected devices, such as the Pathlight SAN GATEWAY and the Pathlight SAN ROUTER products that implement VPS technology of the invention, operate together seamlessly.

[00027] In accordance with the present invention there is provided a method and architecture for establishing independent, secure, trusted sub-networks within a storage area network (SAN). These virtual, private SANs (VPS) allow secure, managed interconnections between an initiator host and a target storage device or a logical unit sub-portion of a target storage device. A table of allowable configurations along with a connection database are used to ensure that proper, allowable data connections are established.

[00038] For purposes of both clarity and brevity, like elements and components will bear the same designations and numbering throughout the FIGURES.

[00039] Generally speaking, the invention features an architecture and method for interconnecting multiple host computer systems to multiple storage devices in a storage area network (SAN) and, more specifically, to the configuration and implementation of secure, reliable sub-networks (i.e., virtual private SANs) within the SAN. The virtual private SAN (VPS) is the implementation and administration of multiple physical interconnections between host initiators and storage devices.

[00040] Referring first to FIG. 1, there is shown a high-level system block diagram of the inventive VPS architecture, generally at reference number 100. This VPS platform contains several components including: host administration and management functions 102, a virtual connection manager 104, A virtual connection cache 106, an initiator accounts data base 108, an administrative accounts data base 110, an administration tool kit 112 that provides user interface functions, and VPS administrative management functions 114. Each of these components will be described in detail hereinbelow.

[00041] Host administration and management functions 102 include a host registration service (HRS) as well as other administrative and management host services provided on an as-needed basis. These services include provisions for handling functions such as security, statistic gathering, data encryption, data compression, etc.

[00042] The HRS issues three registration/de-registration commands which are interpreted within the VPS platform: the full registration command, the periodic registration command, and the de-registration command. For each host initiator interface 116, the HRS packages the configuration information into a standard full registration VPS command and sends the command to each connected VPS platform. This is typically done only once when the host registration service is started. The service may also be run manually to send a full registration command at any time.

[00043] If the registration service is enabled for the periodic function, it will schedule itself to run once during each designated registration interval. The default interval is 15 minutes, but the administrator may change this if desired. During each interval the service constructs a periodic registration command which contains only the period value itself. It sends the periodic registration command to the VPS platform. This command is used by the VPS platform to maintain an accurate record of the online state of each registered host initiator interface 116. When the HRS is terminated or receives a shutdown indication from the operating system, it sends a de-registration command to the VPS platform. This informs the platform that the designated interface is going to be shut down shortly.

[00044] The HRS is also able to display configuration information for all of the devices visible at each of the host initiator interfaces 116.

[00045] The initiator accounts data base 108 creates and maintains a persistent account for each host initiator interface 116 that sends a command to a VPS platform. These accounts contain: I/O access permissions, initiator interface registration information, and initiator interface specific configuration parameters.

[00046] Referring now also to FIG. 2, there is shown a state diagram of an account in the initiator account data base 108, generally at reference number 200. If an initiator has never been connected to a VPS platform, there is no persistent account in the initiator account database. This is referred to as a null state 202. When a host initiator is attached to a VPS platform, the host issues an exploratory command 208. When this exploratory command 208 reaches the VPS platform, a default account is created in the initiator account database and that account enters the Default state, 204 for that initiator. This default account contains only the initiator information that is available to the system at the time the account is created. Access to the command and control logical unit number (LUN) of the VPS platform is the only access allowed to a host initiator while its account is in the default state. Access to I/O target devices is not permitted. A Report LUNs command issued by an initiator with a default account will reflect access to the command and control LUN only. Either administrative action or the automatic VPS enabling process 210 described in more detail hereinbelow is required to add I/O access permissions to the account. This moves the account to the configured access state 206. In this state, the account is said to be configured. This means that the associated host initiator has been given access to all of the target devices that it is intended to interact with. At this point a Report LUNs issued through the corresponding initiator will reflect access to all of LUNs for which permission is configured.

[00047] Administrative action 212 returns the account to default access state and removes access permissions to all LUNs but the command and control LUN. Administrative action deleting the account 214 and 216 returns the account to the null account state. Any further administrative actions that change these permissions do not alter the state of the account.

[00048] The creation and caching of a virtual connection for every I/O path provides the basis of trusted end-to-end access control without the performance degradation that would be incurred without this feature. This is one of the most significant advantages of the instant invention. A virtual connection is the connection between a specific initiator and a specific logical or physical target LUN or device. A virtual connection may be in one of three states: null state, valid state, and invalid state.

[00049] Referring now to FIG. 3, there is a state diagram 300 showing the relationships of these three states. Any nonexistent connection is said to be in null state 302. This indicates that no I/O requests have been sent from the associated host initiator to the specific logical or physical target device since the VPS platform was initialized.

[00050] A connection is created and put in the valid state 304 when an I/O request is received from a specific host initiator to a specific target device for which the initiator account holds access permissions 308. A valid connection may return to the null state 302 either if the logical link over which the request was made is lost 310, or if an administrative action results in a change of permissions 312. A connection is created and put in the invalid state 306 when an I/O request is received from a specific host initiator to a specific target device for which the initiator account does not hold access permissions 314. An invalid connection may be returned to null state 302 if either the logical link over which the request was made is lost 316 or if an administrative action results in a change of permissions 318.

[00051] Referring now to FIG. 4, there is shown a flow chart illustrating the operation of the virtual connection manager 104, generally at reference number 400. Virtual connection manager 104 creates and maintains a virtual connection object in the virtual connection cache for each I/O path that is exercised through the VPS platform. Virtual connection manager 104 waits for a command from a host initiator 116, block 402. When a command arrives, virtual connection manager 104 queries the virtual connection cache 106 to determine whether a connection already exists for the requested I/O path, block 404.

[00052] If this connection exists, the virtual connection manager 104 examines the connection to determine whether it is valid, block 406. If the connection is valid, the command is executed and the completion status is returned to the initiator, block 408. If, however, the command is invalid, the command is rejected and a failed status is returned to the initiator, block 410.

[00053] Referring again to block 404, if no connection exists in the virtual connection cache 106, virtual connection manager 106 queries the initiator account database 108 to determine whether the initiator holds the necessary permissions block 412. If the necessary permissions are found in the initiator accounts database 108, then a valid connection is created in the virtual connection cache 106 and the command is executed, and completion status returned to the initiator block 416. If, however, permissions are not found for the connection in the initiator accounts database, then an invalid connection is created in the virtual connection cache 106, block 420, the command is rejected, and failed status is returned to the initiator, block 418.

[00054] The steps illustrated in FIG. 4 as well as those illustrated in FIG. 3 the virtual connection state diagram show how the inventive architecture is able to enforce complete end-to-end access control with no performance degradation. This is one of the most significant advantages realized by the instant invention. It should be obvious that the maintenance of the virtual connection cache 106 renders it unnecessary to query the account initiator database each time an I/O request arrives from the host initiator. Further more, the architecture allows initiators not running the inventive registration software to function at full speed, although the difficulty of configuring the access for these initiators is increased, due to the degree of manual intervention required to correctly identify them.

[00055] The VPS administration management functions include three features. First, the VPS full host registration engine is run within the administrative maintenance functions. The host initiator health status and the VPS automatic access configuration capture features also are run by the VPS administration management functions.

[00056] The VPS platform receives a full registration command from the host registration service. The associated initiator account is updated with the information contained in the command. This information includes: hosts name (i.e., the name by which this host is identified on the network); host operating system (OS) type (i.e., the name of the operating system running on the host); the host version; the host network address (i.e., the address by which this host is addressed on the network); host connection identification (i.e., the means by which this initiator is identified on the host); the host initiator type; a unique host initiator identification (i.e., a means by which this host initiator is uniquely identified to the SAN in general and to the VPS platform specifically; it depends upon the link protocol used to attach this initiator to the VPS platform.); any other information pertinent to the operation or administration of the host in general or of this specific host initiator; and periodic registration field (i.e., the time interval for the periodic registration).

[00057] Full host registration constitutes one of the most significant functions of the inventive architecture. Before an administrator may configure a network, it is necessary that all devices attached thereto be correctly identified and configured. While the VPS of the instant invention does not require the use of full registration, its enablement completely automates the process of discovering and identifying all initiators connected to the same. This greatly simplifies the process of configuring the SAN and also removes the possibility of problems due to incorrect or out of date configuration information being entered into or retained by the system.

[00058] Another significant feature of the inventive architecture is a health monitoring capability that maintains a representation of the current status of all initiators represented in the initiator accounts database. This feature is the host initiator health status monitor. A simple static, two-state monitor exists by default for all initiators. A dynamic, multi-state monitor becomes active when the host registration service is running on an attached host computer.

[00059] Referring now to FIG. 5, there is shown a state diagram illustrating the static health monitor, generally at reference number 500. All initiators are placed in the off line status 502 as a result of system initialization 504. Any command 506 issued from an initiator through the VPS platform causes the initiator to move to online status 508. Online status 508 indicates that the associated initiator has sent at least one command to or through the VPS platform since the initiator was offline. A specific initiator may be returned to offline status 502 as a result of an administrative action 510.

[00060] Referring now to FIG. 6, there is shown a state diagram of the dynamic health status monitoring system, generally at reference number 600. The use of the dynamic monitor represents a significant improvement over the static monitor illustrated in FIG. 5 because it keeps track of the current status associated with each participating initiator and provides the administrator with the current status of all attached interfaces. It will be noted that offline status 502, online status 508, administrative actions 510, commands 506, and initialization 504 appear identically in the dynamic health status state machine as in the two-status state machine illustrated in FIG. 5.

[00061] The dynamic health monitor status values have the following meanings: If a status is online, the initiator has issued I/O commands but has not registered. This is the state of an active initiator running on a host that does not support the VPS host registration service of the present invention.

[00062] Registered status indicates that an initiator has issued a full registration command with a health period of zero and, therefore, has not activated periodic registration. This is typical of a situation where the registration is run manually but is not installed on the host as an active service. The initiator remains in this state until either the VPS platform is reinitialized or another registration command is received.

[00063] Periodic status indicates that the initiator has sent a full registration command with a health period greater than zero and has activated periodic registration. The initiator remains in this state as long as a periodic or full registration command is received once within every health period.

[00064] Idle status indicates that the initiator was in periodic mode but a full or periodic registration command was not received within the allotted time (i.e., the health period). This is normally indicative of an initiator that has been disconnected from the VPS platform.

[00065] Shutdown status indicates the initiator has issued a de-registration command. The initiator remains in this state until one period expires without another registration command being received by the registration engine.

[00066] Offline status indicates no command has been issued by this initiator since the VPS platform was last initialized; or the registration period has expired while the initiator was in the idle or shutdown state; or the initiator was taken offline by administrative action.

[00067] All initiators are placed in the offline status 502 as the result of system initialization 504. Any command issued 506 from an initiator through the VPS platform causes the initiator to move to an online status 508. Online status indicates that the associated initiator has sent at least one command to or through the VPS platform since the initiator was offline 502. The status of online also indicates that no registration command has been received from this initiator since its status was indicated as offline 502. The issuance of a full registration command 602 causes the status to become registered 604.

[00068] A periodic registration command 606 moves the status to periodic 608. A de-registration command 610 moves the status to shutdown 612. A specific initiator may be returned from online status 508 to offline status 502 by an administrative action 510.

[00069] Registered status 604 indicates that the associated host initiator at some time has sent a full registration command 602 to the VPS platform. This is also true for all of the subsequent dynamic status conditions that may occur following registered status namely, periodic 608, idle 614, and shutdown 612. If the health period is greater than zero 616, then periodic registration 608 is enabled and the initiator is placed in periodic status 608. In addition, the issuance by the host of the periodic registration command 618 also places the initiator in periodic status 608. A de-registration command 620 places the initiator in shutdown status 612. Administrative action 622 may place the initiator in offline status 502.

[00070] Periodic status 608 indicates that the VPS host registration service is running on the host in which this initiator is installed. While the initiator is in periodic status, the dynamic health monitor expects to receive a periodic registration command 606 once during every registration period. If the periodic timer for this initiator expires 624, the initiator is placed in idle status 614. The receipt of either a full registration command 626 or a periodic registration command 628 resets the periodic timer 654 for this initiator and does not change the status. A de-registration command 630 places the host in shutdown status 612. An administrative action 632 may place the initiator in offline status 502.

[00071] When an initiator is in idle status 614, this indicates that one health period has expired without the issuance of either a full registration, a periodic registration or a de-registration command. If the periodic timer for this initiator expires 634, the initiator is placed in offline status 502. This means that two health periods have expired, the first moving the initiator from periodic status 608 to idle status 614, the second moving the initiator from idle status 614 to offline status 502. The second health period provides a grace period to compensate for the possibility of slow response within the VPS network. A full registration or periodic registration command 636 resets the periodic timer for this initiator and places the initiator back in periodic status 608. A de-registration command 638 moves the initiator to shutdown status 612. Administrative action 640 moves the initiator from idle status 614 to offline status 502.

[00072] Shutdown status 612 indicates that the host has announced its intention to shut down this interface. This is done by issuing a de-registration command 610, 620, 630, 638. A de-registration command moves the initiator to shutdown status 612 regardless of its prior status. If the periodic timer for this initiator expires 642, the initiator is placed in offline status 502. The receipt of either a full registration command 644 or a periodic registration command 648 resets timer 650 and does not change the status. The initiator may be moved from shutdown status 612 to offline status 502 by administrative action 652.

[00073] Referring now to FIG. 7, there is shown a generalized state diagram of the VPS state machine, generally at reference number 700. Generally speaking, the VPS state machine may exist in one of three states: disabled 702, enabling 704, or enabled 706. When in the enabled state 706, the operation of the system is in accordance with the flow chart of FIG. 4.

[00074] Referring now also to FIG. 8, there is shown a flow chart of the VPS operation in disabled state 702, generally at reference number 800. While in disabled state 702, the VPS is operating in the manner of a prior art SAN. In this state, the VPS capabilities are dormant and the virtual connection manager processes I/O as shown in FIG. 8. The VPS platform first waits for an I/O request, block 802. When a command is received 804, the virtual connection manager 104 queries the virtual connection cache 106 to determine if the connection exists, block 806. If the connection exists, the command is executed and completion status is returned, block 810. If the connection does not exist, the connection is created in the virtual connection cache 106, block 812, the request is executed block 814, and status is returned. Because VPS is operating in disabled state 702, no permission checks are performed; the connections are created blindly.

[00075] An administrative action 708 is required to move the VPS from disabled state 702 to an enabling state 704. A prerequisite to this action is that the administrator ensures that no new initiators are added to the SAN during the enabling process 708.

[00076] Referring now to FIG. 9, there is shown a flow chart of the enabling process, generally at reference number 900. The VPS enabling process is started by an administrative action 902. The enabling process tests to determine whether the virtual connection cache 106 is empty, block 904. If the virtual connection cache 106 is empty when VPS is enabled, block 906, then no initiator accounts are created during the enabling process and VPS passes directly to the enabled state 706. VPS is now enabled and all subsequent initiator accounts are first created in the default state 204 (FIG. 2), requiring an administrative action 210 to pass into the configured account state. If, however, the virtual connection cache 106 is not empty, then the enabling process creates an account in the default state 204 (FIG. 2) for each host initiator that has one or more connections in the virtual connection cache 106, block 908. Finally, permissions for each connection in the virtual connection cache is entered into the corresponding accounts, block 910. This is equivalent to the administrative action 210 and the accounts thus created are automatically put into the configured state 206.

[00077] The administrative tool kit 112 (FIG. 1) provides administrative and user interface functions in one of three forms, over the available interfaces: SCSI commands over the in-band SAN interfaces or over the out-of-band network interface; service port commands over the serial I/O control interface; and control methods such as SNMP MIBs over the out-of-band network interface or over the SAN interface using Fibre Channel IP protocol methods. Several functions are provided via one or more of these interfaces. The host initiator interface list may be displayed, for example. The host initiator properties may be either displayed or set. The host initiator access configuration likewise may be either displayed or set. The administrative access privileges may also be displayed or set. These interfaces provide for manual configuration through the service port or through SAN management platforms such as Pathlights SAN DIRECTOR software. The in band interface allows dynamic SAN configuration functions to be incorporated into third-party software products easily.

[00078] The administrative accounts database 110 (FIG. 1) creates and maintains a persistent account for each known administrator. This process is accomplished in conjunction with the administrative tool kit 112. Accounts in the administration accounts database 110 are used to validate the administrative commands submitted through the administrative tool kit.

[00079] Since other modifications and changes varied to fit particular operating requirements and environments will be apparent to those skilled in the art, the invention is not considered limited to the example chosen for purposes of disclosure, and covers all changes and modifications which do not constitute departures from the true spirit and scope of this invention.

[00080] Having thus described the invention, what is desired to be protected by Letters Patent is presented in the subsequently appended claims.