Automatic device assignment through programmable device discovery for policy based network management

FIELD

P-0001[0001] The invention generally relates to policy based network management and more particularly to an automatic device assignment through a programmable device discovery for policy based network management.

BACKGROUND

P-0002[0002] Networks and distributed processing systems are of critical importance in business, government and other organizations. The growing trend is towards larger and more complex networks, which support more applications and more users. As these networks grow in size and complexity, the management and control of these networks becomes more difficult.

P-0003[0003] Current techniques for network management allow for the automatic identification of nodes in a network, the retrieval of information or statistics from each node, and setting or initializing one or more parameters at a node. More recently, policy based network management systems provide a more sophisticated control technique that allows for control policies to be distributed and used for controlling the operation of various network nodes or devices. The COPS (Common Open Policy Service) Protocol, RFC2748, January, 2000 even describes a common protocol to be used to exchange policy information between a policy server and its clients (e.g., devices).

P-0004[0004] Unfortunately, for policy based network management, the identification and assignment of devices to different device proxies (to receive different control policies) has been largely a manual process, which is unmanageable for larger networks.

BRIEF DESCRIPTION OF THE DRAWINGS

P-0005[0005] The foregoing and a better understanding of the present invention will become apparent from the following detailed description of exemplary embodiments and the claims when read in connection with the accompanying drawings, all forming a part of the disclosure of this invention. While the foregoing and following written and illustrated disclosure focuses on disclosing example embodiments of the invention, it should be clearly understood that the same is by way of illustration and example only and is not limited thereto. The spirit and scope of the present invention is limited only by the terms of the appended claims.

P-0006[0006] The following represents brief descriptions of the drawings, wherein:

P-0007[0007]FIG. 1 is a block diagram of a network according to an example embodiment.

P-0008[0008]FIG. 2 is a flow chart illustrating an example operation according to an example embodiment.

DETAILED DESCRIPTION

P-0009[0009] A technique for automatically assigning devices to device proxies in a policy based network management system is described. Each device proxy registers a filter (or set of filters) with a device discovery. The filter may identify the characteristics of devices it can (or would like to) policy manage. The device discovery then obtains device specific information from devices to identify devices in the network that match the filters. The device discovery may obtain the device specific information using a communications protocol specified by the filter. The device discovery notifies each device proxy of which devices match the proxy's filter. Each device proxy updates its list of devices that it can policy manage based on the notification from the device discovery. Control policies are distributed from a policy server to each of the device proxies. Each device proxy then sends to the devices specified within the policy (e.g., this may include the devices which matched the filter for the proxy, or some other devices).

P-0010[0010] Referring to the Figures in which like numerals indicate like elements, FIG. 1 is a block diagram illustrating a network <b>100</b> according to an example embodiment. A policy console <b>110</b> is provided for creating policies. Typically, these policies may be created by an administrator, but could be automatically created as well. These policies can include a wide variety of control policies (or business policies) for controlling the operation of a wide variety of devices (e.g., switches, routers, network interface controllers or NICs, and other network devices). According to an example control policy, all packets (or traffic) received from a specific range of source Internet Protocol (IP) addresses will be blocked (will not be forwarded) when received between the hours of 9am to 5pm. This is just a very simple policy, but much more elaborate or complicated control policies are commonly used to control the operation of network devices. Other types of example control policies include, firewall or security policies, Virtual Private Network (VPN) policies, priority policies (e.g., where certain traffic is given priority over other traffic), quality of service (QoS) policies, Internet Protocol (IP) security policies, etc.

P-0011[0011] A policy server <b>112</b> receives policies from the policy console <b>110</b>. Policy server <b>112</b> then selectively distributes (or deploys) various policies to one or more device proxies <b>116</b>. Device proxies <b>116</b>A, <b>116</b>B, . . . and <b>116</b>Z are shown in FIG. 1. However, there may be any number of device proxies <b>116</b>. Each proxy <b>116</b> may be a software program running on a computer or server, and generally operates as an interface between the policy server <b>112</b> and one or more devices <b>120</b> to be controlled using various control policies. Thus, each device proxy <b>116</b> can policy manage one or more devices. Devices <b>116</b> can be, for example, a router, a switch, a NIC, or other type of network device.

P-0012[0012] Policy server <b>112</b> may send or distribute policies to various device proxies <b>116</b> using a common protocol. According to an example embodiment, policy server <b>112</b> distributes policies to proxies <b>116</b> using the COPS (Common Open Policy Service) protocol, which uses the Transport Control Protocol (TCP) as a reliable transport to exchange messages between the policy server <b>112</b> and the device proxies <b>116</b>. Other protocols or techniques can be used as well for distributing the policies to proxies <b>116</b>.

P-0013[0013] Each device proxy <b>116</b> can policy manage one or more devices <b>120</b> (e.g., each device proxy <b>116</b> may control or manage the devices by distributing specific policies to the controlled devices <b>120</b>). For example, device proxy <b>116</b>A policy manages or controls devices <b>120</b>A, <b>120</b>B and <b>120</b>C, while device proxy <b>116</b>Z policy manages or controls devices <b>120</b>D and <b>120</b>E. Although not specifically shown in FIG. 1, proxy <b>116</b>B also may policy control or manage one or more devices <b>120</b> as well.

P-0014[0014] A device proxy <b>116</b> (or other interface program) can be used (or may be necessary) for one of several reasons. For example, policy server <b>112</b> may distribute policies using a common protocol (such as COPS) or another protocol which may not be understood by the devices <b>120</b> (e.g., the protocol used by policy server <b>112</b> may be incompatible with one or more devices <b>120</b>). For example, the devices <b>120</b> may include a wide range of device types from different manufacturers, which may use different device-specific communication protocols (such as Simple Network Management Protocol or SNMP, Telnet, etc.), which may be incompatible from the protocol used by the policy server <b>112</b> (e.g., COPs). Thus, in many cases, policy server <b>112</b> may not be able to directly communicate to the various types of devices <b>120</b> in the network <b>100</b>. Also, certain devices <b>120</b> may be able to receive policies only in a specific format or configuration, which may be different from the policy configuration output by the policy server <b>112</b>. Thus, in many cases, there will be a need for a device proxy <b>116</b> to operate as an interface between the policy server <b>112</b> and the different types of devices in the network <b>100</b>.

P-0015[0015] As an example, devices <b>120</b>A, <b>120</b>B and <b>120</b>C could be, for example, Cisco routers, while devices <b>120</b>D and <b>120</b>E could be, for example, Intel NICs.

P-0016[0016] Therefore, according to an example embodiment, device proxies <b>116</b> can receive a policy from the policy server <b>112</b>, convert the policy to a device-specific configuration (i.e., a configuration that is native to the device) and then distribute the policy to one or more devices <b>120</b> within network <b>100</b> using native or device-specific communication protocols. Each proxy may perform these functions for one or more received policies and for one or more groups of policy managed devices.

P-0017[0017] In the above described Cisco/Intel example, device proxy <b>116</b>A would receive a first policy from the policy server <b>112</b> using a common protocol, such as COPS (or other protocol), convert the first proxy to a first device-specific configuration (e.g., a configuration that is native to these Cisco routers), and then distribute the policy to the Cisco routers (<b>120</b>A-<b>120</b>C) using a device-specific communications protocol, such as SNMP in this example. Likewise, the device proxy <b>116</b>Z will receive a second policy from the policy server <b>112</b> using COPs (or other protocol), convert the second policy to a second device-specific configuration (e.g., a configuration that is native to the Intel NICs) and then send (or distribute) the second policy to the Intel NICs(<b>120</b>D-<b>120</b>E) using a device-specific communications protocol that is specific or native to the Intel NICs (such as Distributed Component Object Model or DCOM in this example).

P-0018[0018] Thus, it can be seen that the policy server <b>112</b> can manage multiple device proxies <b>116</b>, with each device proxy <b>116</b> policy managing multiple devices (e.g., proxy <b>116</b>A policy manages all Cisco routers <b>120</b>A-<b>120</b>C, while proxy <b>116</b>Z policy manages all Intel NICs <b>120</b>D-<b>120</b>E in the network <b>100</b>). This example description above is merely provided to explain some features according to an example embodiment, and the invention is not limited thereto.

P-0019[0019] As noted above, each device proxy <b>116</b> may be designed to manage devices of a specific type, such as devices from a specific manufacturer (e.g., Intel or Cisco), devices having a specific model or ID, devices having specific capabilities or attributes (within an IP address range, etc.). Some devices may only be able to receive a policy or communicate with a proxy using a particular device-specific communications protocol. Also, some policies may be specifically designed for specific types of devices. In fact, some devices may not even be able to receive a policy and be policy managed. As a result, it can be important to properly match devices (and device types) to specific types of policies and to specific proxies.

P-0020[0020] Determining the device-specific information for each device and then assigning each device to a particular device proxy can be a complicated and time consuming process. Presently, the assignment of devices to device proxies is primarily a manual process. The process typically requires an administrator to keep track of each device that is added and removed from the network, the device's attributes and then manually assign each device to a specific device proxy, which is a burdensome process for larger networks.

P-0021[0021] According to an example embodiment, a technique is provided for automatically assigning devices to device proxies through a programmable device discovery for policy based network management. A device discovery <b>114</b> (FIG. 1) is provided to facilitate the dynamic and automatic assignment of devices to device proxies within network <b>100</b>.

P-0022[0022] According to an example embodiment, device discovery <b>114</b> can receive one or more filters from one or more device proxies <b>116</b>. The filters provide device-specific attributes or characteristics that identify devices to be policy managed by that device proxy <b>116</b>. There can be many types of filters. Example filters include:

P-0023[0023] A device-specific communications protocol (e.g., DCOM, SNMP, Telnet) to communicate with the device (e.g., to obtain device specific information or distribute policies to the device, etc.). Some devices may be able to communicate using only certain or specific communications protocols

P-0024[0024] Manufacturer: Devices from a specific manufacturer (e.g., Cisco, Intel)

P-0025[0025] Type or Model: All devices of a specific type or model, etc.

P-0026[0026] All devices having a specific capability (e.g., ability to receive and be managed by specific types of policies such as security policies, VPN policies, etc.)

P-0027[0027] An IP Address Range (or even a specific IP address): This filter is satisfied when device discovery <b>114</b> finds a devices with an IP address which is within the specified range.

P-0028[0028] Wild filter: all the devices found by the discovery satisfy this filter.

P-0029[0029] SNMP filter: This is a name-value pair specifying an object identifier and the value in SNMP.

P-0030[0030] DCOM filter: Specifies the DCOM class GUID (globally unique identifier)

P-0031[0031] Boolean combinations of above filters/conditions

P-0032[0032] These are just some example filters. A wide variety of filters can be used, including combinations or Boolean combinations of various filters or conditions. An example filter may specify the device specific information that should be obtained (to indicate a match with the filter) as well as the communications protocol that should be used by device discovery <b>114</b> to obtain this information. As a result, device discovery <b>114</b> is fully programmable by each proxy <b>116</b>. For example, device proxy <b>116</b>A may policy manage all Cisco routers of a specific IP address range, while device proxy <b>116</b>Z may policy manage all Intel NICs in the network within a specific IP address range. Each proxy <b>116</b> may send a corresponding filter (e.g., Cisco routers within address range A for proxy <b>116</b>A, Intel NICs within address range B for proxy <b>116</b>Z) indicating the types of devices that the device discovery <b>114</b> should identify and return. The filters may also specify the communications protocol that should be used (e.g., SNMP, DCOM) to obtain the device specific information from the devices.

P-0033[0033] According to an example embodiment, the device discovery <b>114</b> automatically discovers the IP addresses for the devices in the network <b>100</b>. This can be done by using, for example, Internet Control Message Protocol (ICMP) or other well known technique. Under ICMP, the device discovery <b>114</b> can “Ping” each of the devices <b>120</b> in the network <b>100</b> by sending out ICMP messages and awaiting replies.

P-0034[0034] After obtaining an IP address for each device in the network <b>100</b>, the device discovery <b>114</b> obtains device specific information (e.g., device characteristics or attributes) from each device <b>120</b> using a device specific (or native) communications protocol. Each proxy <b>116</b> will register one or more filters with the device discovery <b>114</b>. The registered filters will specify to device discovery <b>114</b> the device-specific information to be obtained from the devices (or which match the filter) as well as the communications protocol that should be used by device discovery <b>114</b> to obtain this information for each filter.

P-0035[0035] Device discovery <b>114</b> can then match the device-specific information for each device <b>120</b> to the filters. According to one embodiment, a match indicates a device that a proxy <b>116</b> can policy manage the device. According to another embodiment, each policy provided to a proxy includes an enforcement list—which is a list of devices to be policy managed using the policy. According to yet another embodiment, the proxy <b>116</b> can determine which devices to policy manage (e.g., independent of the matching devices). The device discovery <b>114</b> then sends messages to the device proxies <b>116</b> identifying devices <b>120</b> that match their filters (e.g., in one embodiment, this list identifies devices that each proxy <b>116</b> can policy manage).

P-0036[0036]FIG. 2 is a flow chart illustrating an example operation according to an example embodiment. All blocks of FIG. 2 are not necessarily required.

P-0037[0037] At block <b>205</b>, each device proxy <b>116</b> registers a filter <b>140</b> (FIG. 1) with the device discovery <b>114</b> (e.g., sends a filter to the device discovery <b>114</b> for matching to devices). The registering of a filter <b>140</b> from a device proxy <b>116</b>Z to device discovery <b>114</b> is shown for example in FIG. 1 by line <b>160</b>. Each device proxy <b>116</b> also registers a callback function with the device discovery <b>114</b> to create an obligation on the device discovery <b>114</b> to identify devices that match the filter and then to notify the device proxy <b>116</b> of the matching devices.

P-0038[0038] At block <b>210</b>, device discovery <b>114</b> uses ICMP or other protocol to identify the IP addresses of one or more of the devices in the network <b>100</b>. This may involve detecting only newly added or removed devices, or may involve detecting the address of all devices in the network, etc.

P-0039[0039] At block <b>215</b>, device discovery <b>114</b> obtains device specific information (e.g., device characteristics or attributes such as device model, device manufacturer, device GUIDs, DCOM class-GUID for the device, IP address of the device, an SNMP name-value pair, medium access control or MAC address for the device and so on) through a device-specific communications protocol specified by the registered filter. If only the specified device-specific communications protocol (the protocol specified by the registered filter) is used by device discovery <b>114</b>, this operates to select or identify devices that can communicate using that protocol. This is because devices without the ability to communicate using that protocol will not communicate with device discovery <b>114</b> (e.g., the incompatible devices will not detect or respond to the protocol specific messages). Blocks <b>210</b> and <b>215</b> are typically not performed through proxies <b>116</b>, but the communication or these blocks occurs directly between device discovery <b>114</b> and the devices <b>120</b>.

P-0040[0040] At block <b>215</b>, device discovery <b>114</b> may generally obtain device specific information for one or more devices, or may retrieve only device specific information that is related to (or which matches) the one or more filters registered with the device discovery <b>114</b>. The second option (selective retrieval of information) is preferable as it is less burdensome and still allows the device discovery <b>114</b> to determine if a match exists between a filter and a device.

P-0041[0041] At block <b>220</b>, the device discovery <b>114</b> compares the device specific information of the devices <b>120</b> in the network <b>100</b> to each of the filters and identifies those devices that match the filters. Device discovery may also recognize a device <b>120</b> matching a filter that has been removed from the network <b>100</b>.

P-0042[0042] At block <b>225</b>, pursuant to the registration of the callback (block <b>205</b>), the device discovery <b>114</b> sends one or more messages to notify each device proxy <b>116</b> of devices <b>120</b> in the network <b>100</b> that match the proxy's filter, and provides at least the IP address of each of the matching devices <b>120</b>. These messages can typically be used to identify matching devices that have been added to the network <b>100</b>, or to identify to the proxy previously managed devices <b>120</b> (matching the filter) that have been removed or which have failed. Each proxy <b>116</b> maintains a list of devices which it can policy manage using a specific type (or types) of policy. Each proxy <b>116</b> will update its list of devices <b>120</b> it can policy manage based on the messages from the device discovery <b>114</b> that identify updated or new devices which match the proxy's filter, or which identify devices which can no longer be managed by the proxy <b>116</b> (e.g., have been removed or have failed). The new devices are added to the list while devices that can no longer be policy managed are removed.

P-0043[0043] The list of the matching devices maintained by the proxy <b>116</b> identifies the possible devices <b>120</b> in the network <b>100</b> that can be policy managed by the proxy <b>116</b>. According to an embodiment, the proxy <b>116</b> makes the final decision as to which matching devices to policy manage. For instance, proxy <b>116</b>Z may have 100 Intel NICs on its list (all of which matched its Intel NIC filter). However, due to limited resources or the required overhead, for example, the proxy <b>116</b>Z (or an administrator at the policy console <b>110</b>) may decide to policy manage only 10 of the 100 Intel NICs that match the filter. This is just an example.

P-0044[0044] If a proxy <b>116</b> includes multiple registered filters, the device discovery <b>114</b> provides the IP addresses to the proxy <b>116</b> for matching devices <b>120</b> for each such filter, and the proxy <b>116</b> updates each corresponding list of devices that can be policy managed. According to an example embodiment, a proxy <b>116</b> may policy manage one set of devices <b>120</b> (matching a first filter) using a first policy and may policy manage a second set of devices <b>120</b> (matching a second filter) using a second policy.

P-0045[0045] According to an embodiment, the device discovery <b>114</b> sends a message to the policy console <b>110</b> and/or the policy server <b>112</b> identifying the devices that match each filter. An administrator at policy console <b>110</b> or policy server <b>112</b> may then add an enforcement list of devices to the policy which identifies the devices to be policy managed using the policy. The enforcement list of devices to be policy managed (added to the policy) is typically based upon the devices that match a corresponding registered filter. For example, the enforcement list of devices to be policy managed using the policy may be the same as the devices that match the corresponding registered filter, or the enforcement list could be a subset of the matching devices, etc.

P-0046[0046] At block <b>230</b>, policies received by the policy server <b>112</b> from the policy console <b>110</b> are distributed or sent to the appropriate device proxies <b>116</b>. This can occur at any time. For example, a policy <b>130</b> is shown in FIG. 1 as being distributed to the device proxy <b>116</b>Z at line <b>150</b>. As noted above, each of the policies can include an enforcement list of devices to be policy managed using the policy.

P-0047[0047] At block <b>235</b>, Each proxy <b>116</b> then sends or distributes a policy to one or more devices <b>120</b>. According to one embodiment, each proxy <b>116</b> sends the policy to the devices to be managed identified by the enforcement list from the policy server <b>112</b>. According to another embodiment, each proxy <b>116</b> uses a policy (or distributes the policy) to policy manage one or more devices that match the registered filter (e.g., the proxy <b>116</b> policy manages one or more of the devices <b>120</b> from the proxy's updated list that identifies which devices the proxy <b>116</b> can policy manage). According to yet another embodiment, the proxy <b>116</b> policy manages one or more devices <b>120</b> regardless of which devices matched the registered filter. This allows the proxy <b>116</b> to policy manage the automatically assigned (or automatically identified) devices <b>120</b>. Thus, according to an example embodiment, this allows the proxy <b>116</b> to policy manage one or more of those devices <b>120</b> that were automatically assigned (or identified) by the device discovery <b>114</b> to the proxy <b>116</b> based on the device matching the proxy's filter. This is a much more efficient and configurable (or adaptable) technique than manually assigning devices to proxies. This is repeated for each policy (e.g., distribute the first policy to the first group of devices, and distribute the second policy to the second set of device).

P-0048[0048] At block <b>240</b>, at various points during the operation of the network <b>100</b>, the network <b>100</b> may be updated or changed to add or remove devices <b>120</b>, reconfigure devices, assign new IP addresses to a device <b>120</b>, etc. Likewise, each proxy <b>16</b> can update its filter(s) or add or remove filters. For example, a device proxy <b>116</b> may be policy managing a first group of devices <b>120</b> (matching a first filter) using a first type of policy. However, a network administrator using a local console at the proxy <b>116</b> (for example) may re-assign the device proxy <b>116</b> to instead policy manage a second group of devices <b>120</b> (which match a new or second filter) using a second type of policy. Thus, to effect this update, the second filter <b>140</b> is sent from the proxy <b>116</b> to the device discovery <b>114</b>, and the first filter is canceled. The policy server <b>112</b> sends the second type of policy to the proxy <b>116</b>. The device discovery <b>114</b> then matches devices in the network <b>100</b> to the second filter and notifies the proxy <b>116</b> (and the policy console <b>110</b>) of the matching devices <b>120</b>, including their IP addresses. This new (or second) policy can then be distributed to this second group of devices.

P-0049[0049] In this manner, an embodiment of the present invention allows for the automatic discovery of devices and the dynamic or programmable matching of devices to specific proxy filters in order to automatically assign devices to device proxies. Policy server <b>112</b>, device discovery <b>114</b> and device proxies <b>116</b> can be implemented as software programs or modules running on different computers or servers or a common computer.

P-0050[0050] Several embodiments of the present invention are specifically illustrated and/or described herein. However, it will be appreciated that modifications and variations of the present invention are covered by the above teachings and within the purview of the appended claims without departing from the spirit and intended scope of the invention.