WO2016018242A1

WO2016018242A1 - Three-dimensional view of network mapping

Info

Publication number: WO2016018242A1
Application number: PCT/US2014/048553
Authority: WO
Inventors: Vivek Agarwal; Krishna PUTTAGUNTA; Rupin T. Mohan; Kyle Fransham; Andrew E.S. Mackay
Original assignee: Hewlett-Packard Development Company, L.P.
Priority date: 2014-07-29
Filing date: 2014-07-29
Publication date: 2016-02-04

Abstract

A system includes multiple devices in a storage area network (SAN). Each device includes at least one network port, at least one processor, a management module, and a three-dimensional interface module. The management module is to receive announcements generated by ports included in an announcement group, where the ports are included in the other devices, and where each announcement includes port metadata for a particular port. The management module is also to determine, based on the announcements, a network mapping of the ports and the devices. The three-dimensional interface module is to generate a three-dimensional view based on the network mapping.

Description

THREE-DIMENSIONAL VIEW OF NETWORK MAPPING

Background

[0001] A computing network can include any number of devices connected by data links. Some computing networks may be specialized to perform specific types of tasks. For example, a Storage Area Network (SAN) is generally configured to enable access to data storage devices such as disk arrays, tape libraries, jukeboxes, etc.

Brief Description Of The Drawings

[0002] Some implementations are described with respect to the following figures.

[0003] Fig. 1 is a schematic diagram of an example network, in accordance with some implementations .

[0004] Fig. 2 is a schematic diagram of an example network device, in accordance with some implementations.

[0005] Fig. 3 is an illustration of application flow information according to an example implementation.

[0006] Figs. 4A-4C are illustrations of three dimensional views according to some example implementations.

[0007] Fig. 5 is a flow diagram of a network mapping process according to some example implementations .

[0008] Fig. 6 is a flow diagram of a network management process according to some example implementations.

[0009] Fig. 7 is a flow diagram of a network management process according to some example implementations. Detailed Description

[0010] Storage Area Networks (SANs) can include a variety of devices, and can utilize a variety of applications including virtualization applications. In some examples, managing a SAN is a complex activity that is performed using specialized management applications and out-of-band data networks. Such example approaches may involve manual configurations at multiple places, and may thus be error-prone and time-consuming.

[0011] In accordance with some implementations, techniques or mechanisms are provided for network management using announcements (e.g., messages) generated by the ports of the network devices. Such announcements can be used to generate a mapping of ports and network devices, as well as their associated capabilities, services, etc. Further, the mapping can be used to generate a three-dimensional view of the network. The three- dimensional view can be presented to a user (e.g., a network manager, a system

administrator, an end user, etc.).

[0012] Fig. 1 is a schematic diagram of an example network 100, in accordance with some implementations. As shown, the network 100 can include any number and type of network devices, including hosts 110(A,B), targets 120(A,B), and/or switches 130(A,B,C). For example, target 120A may access host 110A, which can store data. Further, switch 130A may transfer data between endpoints, such as host 110A and target 120 A. Such devices may be coupled by any number and configuration of interconnections.

[0013] The network 100 can be configured for a particular task or purpose. For example, in some implementations, the network 100 may be a Storage Area Network (SAN) including storage devices. In such implementations, the hosts 110(A,B) and/or the targets 120(A,B) may include, for example, disk arrays, tape libraries, optical jukeboxes, servers, etc.

[0014] In accordance with some implementations, some or all of the devices of the network 100 may be configured to transmit announcements, and to receive announcements from other devices. Such announcements can be used to generate a mapping of the network 100. Further, such a mapping may be used to generate a three-dimensional view of the network 100. These features will be described further below with reference to Figs. 2-7. [0015] Referring now to Fig. 2, shown is a schematic diagram of an example network device 210, in accordance with some implementations. In some implementations, the network device 210 may correspond generally to any of the network devices shown in Fig. 1 (e.g., hosts 110(A,B), targets 120(A,B), switches 130(A,B,C), etc.). In other

implementations, the network device 210 may be a management device, and may manage a group of other devices included in a network (e.g., network 100 shown in Fig. 1).

[0016] As shown, the network device 210 can include a display device 215, processor(s) 220, memory 230, machine-readable storage 250, and a network interface 245. The display device 215 can include a display screen, a touch screen, a projector, a stereoscopic display, a volumetric display, a holographic display, a head-mounted display, a graphics card, a video processor, etc. The processor(s) 220 can include a microprocessor, microcontroller, processor module or subsystem, programmable integrated circuit, programmable gate array, multiple processors, a microprocessor including multiple processing cores, or another control or computing device. The memory 230 can be any type of computer memory (e.g., dynamic random access memory (DRAM), static random-access memory (SRAM), etc.). The machine-readable storage 250 can include non-transitory storage media such as hard drives, flash storage, optical disks, etc.

[0017] In some implementations, the network interface 245 can include any number of ports 240(A-N). The ports 240(A-N) can provide "in-band" data transmission (i.e., using the primary data interconnections between the network devices 210). In some implementations, the ports 240(A-N) can provide "out-of-band" data transmission (i.e., using a channel reserved for system management data). The network interface 245 can use any network standard or protocol (e.g., Ethernet, Fibre Channel, Fibre Channel over Ethernet (FCoE), Internet Small Computer System Interface (iSCSI), a wireless network standard or protocol, etc.).

[0018] As shown, the machine -readable storage 250 can include a management module 260, a network mapping 270, a three-dimensional (3D) interface module 280, and

application(s) 290. In some implementations, the management module 260 can send a request for the network device 210 to join an announcement group (i.e., a specified group of devices that are to send and receive announcements). For example, in some implementations, the management module 260 may send an Internet Group Management Protocol (IGMP) message to join a multicast group in which members are to receive announcements.

[0019] An example listing of a multicast announcement message is provided below: message FSCHost {

extensions 100 to max;

enum Type {

UNKNOWN = 0;

ISCSI TARGET = 1;

ISCSI INITIATOR = 2;

SWITCH = 3;

}

message CustomFields {

required string key = 1 ;

required string value = 2;

}

required Type type = 1 ;

required string ip_address = 2;

optional string name = 3;

optional string state = 4;

optional string vendor = 5;

optional string model = 6;

repeated CustomFields custom fields = 7;

}

[0020] After joining an announcement group, the management module 260 can automatically send announcements to members of the announcement group. Further, the announcements may be transmitted periodically, or according to a defined schedule, or in response to an event, etc. The announcements may be, for example, multicast packets, broadcast packets, and so forth. In addition, the announcements may be transmitted via in- band data connections (e.g., using primary data interconnections that are not dedicated to management data).

[0021] In some implementations, the management module 260 can receive other announcements from members of the announcement group. For example, in some implementations, the management module 260 can use IGMP snooping at layer 2 to optimize the flow of announcements only to ports that have joined a multicast group. In this manner, other ports that do not use the announcements will not be flooded by the announcements. [0022] In some implementations, each announcement may be transmitted by a single port of the network device 210. Further, each announcement can include "port metadata," which can refer to data describing the network device 210 and/or the transmitting port. In some implementations, the port metadata can include attributes and/or capabilities of the network device 210 and/or the transmitting port. For example, an announcement transmitted by port 240B may include metadata describing attributes of network device 210 and/or port 240B (e.g., device identifier, port name, physical port address, Internet Protocol (IP) address, software version, manufacturer identifier, network zoning or partitioning, etc.). In another example, an announcement transmitted by port 240A may include metadata describing capabilities of network device 210 and/or port 240A, such as storage capacity, disk speed, redundancy, data transfer rates, error correction capabilities, Quality of Service capabilities, security/encryption capabilities, legal compliance standards (e.g., Payment Card Industry Data Security Standard (PCI DSS), Federal Risk and Authorization Management Program (FedRAMP), Health Insurance Portability and Accountability Act (HIPAA), etc.), application services, protocol or API services, application business level impact level, and so forth.

[0023] In some implementations, the port metadata can describe services and/or applications associated with the transmitting port. For example, an announcement transmitted by port 240B may include metadata describing a service or application that is provisioned on (or assigned to) port 240B. Further, the port metadata can include logical address information (e.g., a Virtual Port, a Virtual Machine (VM), a Virtual Local Area Network (VLAN) identifier, a Logical Unit Number (LUN) identifier, etc.) associated with the transmitting port. For example, an announcement transmitted by port 240B may include metadata describing a VLAN and/or a LUN associated with a service or application provisioned on port 240B. This announcement can allow downstream devices to make automated decisions using the metadata.

[0024] In some implementations, the management module 260 can build and update the network mapping 270 based on received announcements. The network mapping 270 may include a topology map of the connections between the ports 240(A-N) and/or network devices 210. Further, the network mapping 270 may include information about the attributes and/or capabilities associated with the ports 240(A-N) and/or network devices 210. In addition, the network mapping 270 may include information about "flows," which can be the particular data paths between applications and/or services and their target devices.

[0025] Further, the network mapping 270 may include information about the attributes and/or capabilities associated with the ports 240(A-N) and/or network devices 210. In addition, the network mapping 270 may include information about "flows," which can be the particular data paths between applications and/or services and their target devices.

[0026] In some implementations, the management module 260 can associate the network mapping 270 with physical location information for the ports 240(A-N) and/or network devices 210. For example, the management module 260 can obtain information about the physical location of each network device 210, and can include this information in the network mapping 270. The physical location information can be specified in terms of a 3D reference space. For example, the physical location of a device 210 can be specified as coordinates along three spatial axes (e.g., "depth X, width Y, height Z"), as defined physical locations (e.g., "slot A, shelf B, rack C, room D"), and so forth. In some implementations, the physical location information may be obtained from a database or other data structure.

[0027] In some implementations, the physical location information can include information about physical zones that are defined as having a particular property or characteristic. For example, the physical location information can specify that a given zone (e.g., room, rack(s), shelf, slot, area, volume, etc.) is designated for a particular use or characteristic (e.g., enhanced network security, required service level, dedicated cooling system, protected/conditioned power source, controlled/locked physical access, and so forth).

[0028] In some implementations, the management module 260 can evaluate and execute management policies using announcements and/or the network mapping 270. For example, the management module 260 can determine whether any trigger conditions included in a management policy are satisfied by received announcements and/or the information or state of the network mapping 270. By executing a defined management policy, each network device 210 can manage its own network configuration. Further, a management policy may specify actions to enable an application or service to configure the network devices 210 which provide the flow of the application or service. For example, a management policy can specify that an application is to be assigned to a storage device based on disk speed, encryption level, redundancy, etc. Further, executing a management policy can include, e.g., creating a Virtual Local Area Network (VLAN), creating Fibre Channel zones, enforcing Quality of Service (QoS) specifications, implementing an Access Control List (ACL), checking for inconsistencies in network configuration or mapping information, performing audits, matching capabilities across a flow, grouping devices into a zone, etc. In some implementations, the network device 210 may be a specialized management device, and may execute management policies to manage a group of other devices included in a network.

[0029] The network device 210 shown in Fig. 2 may be referred to as an "enabled device," which can be a device that includes the network mapping and management features described herein (e.g., the features of the management module 260). Further, the term "non- enabled device" may refer to a device that does not include the network mapping and management features described herein.

[0030] In some implementations, the announcements may be formatted as standard multicast or broadcast messages that are automatically forwarded by non-enabled devices. For example, referring again to Fig. 1, assume that switch 130B is a non-enabled device, and that switch 130C is an enabled device. In this example, an announcement sent by the host 110B is received by the non-enabled switch 130B, and is then forwarded to the enabled switch 130C.

[0031] In some implementations, the management module 260 can update the network mapping 270 using information from non-enabled devices. For example, the management module 260 can use join requests from new members (e.g., an IGMP message) to notify a layer 3 protocol (e.g., Distance Vector Multicast Routing Protocol (DVMRP), Protocol- Independent Multicast (PIM), etc.). The layer 3 protocol can then build a short path tree between all receivers and senders of the group, including both enabled and non-enabled devices. This path tree information can be used to update the network mapping 270.

[0032] The management module 260 can include Application Programming Interfaces (API) for external management frameworks (e.g., Software Defined Networking (SDN) frameworks, OpenStack frameworks, etc.). Such APIs can enable external management systems to access the network mapping 270, and to manage network devices using defined management policies.

[0033] In some implementations, the 3D interface module 280 can generate a 3D view based on the network mapping 270. The 3D view can be a representation of a 3D space or geometry. In some implementations, the 3D interface module 280 can generate the 3D view to include information related to the network mapping 270. For example, the 3D view can include the physical locations of network devices 210, the physical paths of application flows, physical zones, etc. Further, the 3D view can use a particular dimension to represent values or settings associated with attributes or capabilities of the ports 240(A-N) and the network devices 210. Such examples of the 3D view are described further below with reference to Figs. 4A-4C.

[0034] The 3D view can be displayed using two-dimensional (2D) displays and/or 3D displays. For example, the 3D view can be shown on a 2D display (e.g., a flat-panel display), and can be rendered with techniques that convey the perception of three dimensions to a viewer of the 2D display. Such techniques may include wire-framing, ray tracing, texture mapping, lighting/shading effects, depth of field, perspective, parallax effects, depth cues, etc. In another example, the 3D view can be shown on a 3D display such as a stereoscopic display, a volumetric display, a holographic display, etc.

[0035] In some implementations, the 3D view can be displayed to a user of the network device 210 using the display device 215. The display device 215 can be a 2D display, a 3D display, or a combination thereof. The user may interact with the network device 210 to modify or control the 3D view. For example, the user may specify which elements of the network mapping 270 to include in the 3D view, the level of detail to include in the 3D view, and so forth. Further, the user can rotate the 3D view along multiple axes, can zoom the 3D view in or out, can highlight specific devices or flows, and so forth. In some

implementations, the display device 215 can be a touch screen, and the user can touch the display device 215 to enter commands to control the 3D view.

[0036] In some implementations, the 3D view can be provided as part of a management console for a network. For example, a management console can include the 3D view, and can enable a user to control a device, a port, a connection, an application, a service, a flow, a zone, a management policy, and so forth.

[0037] Various tasks of the management module 260 and/or the 3D interface module 280 are discussed further below with reference to Figs. 3, 4A-4C, 5, 6, and 7. Note that any of the tasks described herein in relation to the management module 260 and/or the 3D interface module 280 can be implemented in any suitable manner. For example, any of these tasks can be hard-coded as circuitry included in the processor(s) 220 and/or the network device 210. In other examples, the management module 260 and/or the 3D interface module 280 can be implemented as circuitry and/or machine-readable instructions included in the network interface 245. Further, the tasks of the management module 260 and the 3D interface module 280 can be combined or implemented in a single module, in other additional modules, and so forth.

[0038] Fig. 3 is an illustration of application flow information according to some example implementations. Specifically, Fig. 3 illustrates example flows in a network including a host 310, a switch 330, a target 340, and a target 350. Any of the devices can correspond generally to the network device 210 shown in Fig. 2.

[0039] Assume that, in the example of Fig. 3, application 313 is provisioned to target 340, and application 315 is provisioned to target 350. In some implementations, a flow 380 between application 313 and target 340 may be determined from announcements generated by any of the ports included in the data path between application 313 and target 340 (e.g., by ports 314, 334, 335, and 345). Similarly, a flow 385 between application 315 and target 350 may be determined from announcements generated by the ports included in the data path between application 315 and target 350 (e.g., by ports 316, 336, 337, and 357).

[0040] In some implementations, the determination of flows 380 and 385 may be performed by any device including the network mapping features described herein (e.g., host 310, switch 330, target 340, and/or target 350). Further, each device can store information describing the flows 380 and 385 in its network mapping (e.g., network mapping 270 shown in Fig. 2). For example, the network mapping may identify each location along a flow, and may associate each location with a unique flow identifier. Further, the network mapping can include attribute values associated with each location. For example, the network mapping can include attribute values associated with a port, a device, a flow segment, a flow origin/destination, an entire flow, and so forth. Such attributes can include signal latency, data transfer rates, error correction information, storage capacity, disk speed, redundancy, service level, security/encryption information, network load/capacity, collision information, network protocol, data format, temperature, and so forth.

[0041] Figs. 4A-4C are illustrations of 3D views according to some example

implementations. Referring now to Fig. 4A, shown is an example 3D view 400.

Specifically, the 3D view 400 includes a floor-plan 410, which can represent the floor plan of an actual physical space (e.g., a server room). As shown, in this example, the 3D view 400 also includes racks 420, 440, and 460. Assume that, in this example, the locations of the racks 420, 440, and 460 on the floor-plan 410 represent the actual physical locations of racks 420, 440, and 460.

[0042] As shown, the 3D view 400 also includes network devices 425, 445, and 465. Note that each of the network devices 425, 445, and 465 is shown to be located in a particular vertical position within one of the racks 420, 440, and 460. Assume that, in this example, the vertical positions of the of the network devices 425, 445, and 465 shown in Fig. 4A correspond to their actual physical positions within the racks 420, 440, and 460.

[0043] In the example of Fig. 4, the 3D view 400 also includes flow segments 430 and 450. Note that the flow segment 430 is shown as connecting a specific port of the network device 425 to a specific port of the network device 445. Further, the flow segment 450 is shown as connecting a second port of the network device 445 to a port of the network device 465. Assume that, in this example, the flow segments 430 and 450 represent two segments of a flow for an application that is hosted on the network device 425, and that is provided to the network device 465. Assume further that the port connections and paths of the flow segments 430 and 450 shown in Fig. 4A correspond to the actual port connections and physical paths of the flow segments 430 and 450.

[0044] In some implementations, the flow segments 430 and 450 can be associated with status indicators (not shown). For example, the flow segments 430 and 450 can be shown with status indicators associated with signal latency, data transfer rate, security level, load, temperature, and so forth. The status indicators can include color coding, text labels, symbols, animation effects, highlighting, etc.

[0045] In some implementations, the 3D view 400 can enable a user to view the network devices and/or ports associated with an application flow. Further, the 3D view 400 can enable the user to visualize the physical locations and paths associated with the application flow and the network devices within a three-dimensional space.

[0046] Referring now to Fig. 4B, shown is an example 3D view 402. Specifically, the 3D view 402 corresponds generally to 3D view 400 shown in Fig. 4A. However, the 3D view 402 further includes a zone 470. As shown, in this example, the rack 440 is located in the zone 470. In some implementations, the zone 470 can represent a physical zone that is specified for a particular use or characteristic. For example, the zone 470 may represent an area or volume that includes a dedicated cooling system, a protected power source, enhanced physical and/or network security, etc. In some implementations, the 3D view 402 can enable the user to view the network devices, ports, and flow segments that are included or located in the zone 470.

[0047] Referring now to Fig. 4C, shown is an example 3D view 404. Specifically, the 3D view 404 includes devices 480, 482, 484, and 486. Assume that the positions of the devices 480, 482, 484, and 486 on the floor-plan 410 indicate the actual locations of the devices 480, 482, 484, and 486 in the two physical dimensions represented by the floor-plan 410.

[0048] As shown, the 3D view 404 includes segments 470, 473, and 476, representing network connections between the devices 480, 482, 484, and 486. The 3D view 404 also includes an axis indicator 415, which is shown as extending vertically from the floor-plan 410. As shown, the axis indicator 415 can include markings to indicate the vertical distance above the floor-plan 410. Assume that, in the 3D view 404, the vertical distance above the floor-plan 410 indicates a value or setting associated with at least one attribute. [0049] Note that, in the 3D view 404, each of the segments 470, 473, and 476 is shown to be aligned with a particular vertical position along the axis indicator 415. In some

implementations, the vertical positions of the segments 470, 473, and 476 can indicate attribute values or settings associated with the segments 470, 473, and 476. For example, the vertical position of segment 470 can indicate that the value of an attribute associated with the segment 470, such as latency value, transfer rate, connection type/status, protocol type, load level, error rate, security status, redundancy level, service level, and so forth. In some implementations, the 3D view 404 can enable the user to visualize attribute values associated with locations along an application flow.

[0050] In some implementations, the 3D views 400, 402, and 404 can be generated by the 3D interface module 280 using the network mapping 270. Further, the 3D views 400, 402, and 404 can be displayed using the display device 215 (e.g., a 2D display device or a 3D display device). Note that, while Figs 4A-4C illustrate examples of 3D views, other implementations are also possible. For example, the 3D views can include other information (e.g., management policy information, environmental information, power information, business information, planning information, and so forth). Further, the 3D views can have other configurations or presentations.

[0051] Referring now to Fig. 5, shown is a process 500 for generating a 3D view in accordance with some implementations. The process 500 may be performed by the processor(s) 220, the management module 260, and/or the 3D interface module 280 shown in Fig. 2. The process 500 may be implemented in hardware or machine -readable instructions (e.g., software and/or firmware). The machine-readable instructions are stored in a non- transitory computer readable medium, such as an optical, semiconductor, or magnetic storage device. For the sake of illustration, details of the process 500 may be described below with reference to Figs. 2 and 3, which show examples in accordance with some implementations. However, other implementations are also possible.

[0052] At 510, announcements from multiple ports included in an announcement group may be received. Each announcement may include port metadata describing a particular port. For example, referring to Fig. 3, port 314 of host 310 may receive announcements from ports 334, 345, and 357. Each announcement can include metadata describing the port that generated the announcement, including attributes, capabilities, services, and/or applications associated with the port. In addition, each announcement can describe a device including the port.

[0053] At 520, a network mapping of the multiple ports and their associated services may be determined based on the received announcements. For example, referring to Fig. 3, host 310 can use announcements received by port 314 to build or update a network mapping (e.g., network mapping 270 shown in Fig. 2) including ports 334, 345, and 357. The network mapping can also include services provided by ports 334, 345, and 357. Further, the network mapping can include switch 330, target 340, and target 350.

[0054] At 530, a 3D view can be generated using the network mapping. For example, referring to Fig. 2, the 3D interface module 280 can generate a 3D view based on the network mapping 270. In some implementations, the 3D view can include physical locations of devices/ports, physical paths of application flows, physical zones, attribute values, etc. After 530, the process 500 is completed.

[0055] Referring now to Fig. 6, shown is a process 600 for generating a 3D view in accordance with some implementations. The process 600 may be performed by the processor(s) 220, the management module 260, and/or the 3D interface module 280 shown in Fig. 2. The process 600 may be implemented in hardware or machine -readable instructions (e.g., software and/or firmware). The machine-readable instructions are stored in a non- transitory computer readable medium, such as an optical, semiconductor, or magnetic storage device. For the sake of illustration, details of the process 600 may be described below with reference to Figs. 2 and 3, which show examples in accordance with some implementations. However, other implementations are also possible.

[0056] At 610, announcements from multiple ports included in an announcement group may be received. Each announcement can include metadata describing the port that generated the announcement. For example, referring to Fig. 2, port 240A of network device 210 may receive announcements from ports included in other network devices. [0057] At 620, a network mapping of the multiple ports and their associated services may be determined based on the received announcements. For example, referring to Fig. 2, the management module 260 may generate or update the network mapping 270 based on announcements received by ports 240(A-N).

[0058] At 630, a user command associated with a 3D view can be received. For example, referring to Fig. 2, a user of the network device 210 can interact with the 3D interface module 280 to indicate a command associated with a 3D view. The command can specify which elements to include in the 3D view, the level of detail for the 3D view, the angle/zoom for the 3D view, etc.

[0059] At 640, the 3D view can be generated based at least on the network mapping and the user command. For example, referring to Fig. 2, the 3D interface module 280 can generate/update a 3D view based on the network mapping 270 and a user command.

[0060] At 650, the 3D view can be displayed to a user. For example, referring to Fig. 2, the 3D view can be presented using the display device 215. In some implementations, the displayed 3D view can enable the user to visualize physical locations of devices/ports, physical paths of application flows, physical zones, attribute values, and so forth. Further, in some implementations, the 3D view can be included in a management console for one or more networks. After 650, the process 600 is completed.

[0061] Referring now to Fig. 7, shown is a process 700 for generating a 3D view in accordance with some implementations. The process 700 may be performed by the processor(s) 220, the management module 260, and/or the 3D interface module 280 shown in Fig. 2. The process 700 may be implemented in hardware or machine -readable instructions (e.g., software and/or firmware). The machine-readable instructions are stored in a non- transitory computer readable medium, such as an optical, semiconductor, or magnetic storage device. For the sake of illustration, details of the process 700 may be described below with reference to Figs. 2 and 3, which show examples in accordance with some implementations. However, other implementations are also possible. [0062] At 710, a request to join a multicast group may be sent from a port. For example, referring to Fig. 3 , port 314 of host 310 can send a join request to join a multicast group including ports 334, 345, and 357. In some implementations, the join request is an IGMP message. In response to the join request, a member of the multicast group may join the requesting port to the multicast group.

[0063] At 720, after joining the multicast group, announcements may be sent to other members of multicast group. For example, referring to Fig. 3, port 314 can send an announcement to other members of the multicast group (i.e., ports 334, 345, and 357). In some implementations, the announcement is a multicast message.

[0064] At 730, announcements from other members of the multicast group may be received at the port. For example, referring to Fig. 3, port 314 can receive announcements from ports 334, 345, and 357. The received announcements can include metadata describing ports 334, 345, and 357. Further, the announcements may be received via an in-band connection to ports 334, 345, and 357.

[0065] At 740, requests to join the multicast group may be received at the port from other devices. For example, referring to Fig. 3, port 314 may receive an IGMP from another device (not shown) to join a multicast group.

[0066] At 750, a network mapping of the multiple ports and their capabilities may be determined based on the received announcements and join requests. For example, referring to Fig. 3, host 310 can use received announcements to build or update a network mapping. In addition, host 310 can use received join requests to build a path tree, and can update the network mapping to include information from the path tree.

[0067] At 760, a 3D view can be generated using the network mapping. For example, referring to Fig. 2, the 3D interface module 280 can generate a 3D view based on the network mapping 270.

[0068] At 770, the 3D view can be displayed to a user. For example, referring to Fig. 2, the 3D view can be presented using the display device 215. In some implementations, the 3D view can be included in a management console for controlling devices, ports, flows, zones, management policies, facilities, etc. After 770, the process 700 is completed.

[0069] In accordance with some implementations, the announcements described herein may enable individual devices to build and maintain network mapping information automatically using "push" communication, and without employing out-of-band "pull" communication. The announcements can be used to enable "target orchestration," which can refer to individual network devices automatically controlling and managing the configuration of the network and application flows. Further, the announcements may be used to combine information from logical and physical domains in a single mapping, and may enable network management while maintaining compatibility with non-enabled devices. Furthermore, the network mapping may be used to generate a 3D view. The 3D view can enable a user to visualize physical locations of devices/ports, physical paths of application flows, physical zones, attribute values, and so forth.

[0070] In some implementations, the network mapping and/or the 3D view can enable automated management policy decisions by participating devices to include physical-to- logical and logical-to-physical relationships, and thereby enable enhanced levels of control, security, and/or energy efficiency. Further, the 3D view can enable a user or operator to visualize and/or select specific metadata elements and relationships between the logical and physical domains. Such visualization of metadata and relationships can enable the user or operator to make policy decisions that would not be possible without a visual representation of the model.

[0071] Data and instructions are stored in respective storage devices, which are implemented as one or multiple computer-readable or machine-readable storage media. The storage media include different forms of non-transitory memory including semiconductor memory devices such as dynamic or static random access memories (DRAMs or SRAMs), erasable and programmable read-only memories (EPROMs), electrically erasable and programmable read-only memories (EEPROMs) and flash memories; magnetic disks such as fixed, floppy and removable disks; other magnetic media including tape; optical media such as compact disks (CDs) or digital video disks (DVDs); or other types of storage devices. [0072] Note that the instructions discussed above can be provided on one computer- readable or machine-readable storage medium, or alternatively, can be provided on multiple computer-readable or machine-readable storage media distributed in a large system having possibly plural nodes. Such computer-readable or machine -readable storage medium or media is (are) considered to be part of an article (or article of manufacture). An article or article of manufacture can refer to any manufactured single component or multiple components. The storage medium or media can be located either in the machine running the machine-readable instructions, or located at a remote site from which machine -readable instructions can be downloaded over a network for execution.

[0073] In the foregoing description, numerous details are set forth to provide an understanding of the subject disclosed herein. However, implementations may be practiced without some of these details. Other implementations may include modifications and variations from the details discussed above. It is intended that the appended claims cover such modifications and variations.

Claims

What is claimed 1. A system comprising:

a plurality of devices for a storage area network (SAN), each device of the plurality of devices comprising:

at least one network port;

at least one processor;

a management module executable on the at least one processor to:

receive, at the at least one network port, a plurality of announcements generated by a plurality of ports included in an announcement group, wherein the plurality of ports are included in other devices of the plurality of devices, wherein each announcement of the plurality of announcements includes port metadata for a particular port of the plurality of ports, and

determine, based on the plurality of announcements, a network mapping of the plurality of ports and the plurality of devices; and a three-dimensional interface module executable on the at least one processor to:

generate, based on the network mapping, a three-dimensional view for display to a user of the system.

2. The system of claim 1, the management module further to:

generate a request to join the at least one network port to the announcement group.

3. The system of claim 1, wherein the plurality of announcements are

automatically transmitted as in-band messages by the plurality of ports according to a repeating period or schedule.

4. The system of claim 1, wherein the three-dimensional view comprises a representation of at least one application flow included in the network mapping.

5. The system of claim 1, wherein the three-dimensional view comprises a representation of a physical location of at least one device of the plurality of devices.

6. The system of claim 1, wherein the three-dimensional view comprises:

a first dimension and a second dimension to represent at least a portion of the network mapping; and

a third dimension to represent at least one value of a parameter associated with the network mapping.

7. The system of claim 1, wherein the three-dimensional view comprises a representation of a defined physical zone, wherein the defined physical zone includes a portion of the plurality of devices.

8. A method comprising:

receiving a plurality of announcements generated by a plurality of devices, wherein the plurality of devices comprise a plurality of ports connected to a network, wherein each announcement of the plurality of announcements includes port metadata for a particular port of the plurality of ports, the port metadata including capability and application information associated with the particular port;

determining a network mapping of the plurality of ports and the plurality of devices based on the received plurality of announcements; and

generating a three-dimensional view based at least on the network mapping of the plurality of ports and the plurality of devices, the three-dimensional view to be presented to at least one user of the plurality of devices.

9. The method of claim 8, wherein generating the three-dimensional view comprises generating a representation of a data path between an application and a target.

10. The method of claim 8, wherein generating the three-dimensional view comprises generating a representation of a three-dimensional location of each device of the plurality of devices.

11. The method of claim 8, wherein the three-dimensional view comprises:

a first dimension and a second dimension to represent at least a portion of the topology mapping; and

a third dimension to represent at least one value of an attribute associated with the network mapping.

12. The method of claim 8, wherein determining the network mapping is further based on path tree information, wherein the path tree information describes both enabled and non-enabled devices connected by the network.

13. An article comprising at least one non-transitory machine -readable storage medium storing instructions that upon execution cause a network device to:

receive a plurality of announcements generated by a plurality of devices, wherein the plurality of devices comprise a plurality of ports connected to a network, wherein each announcement of the plurality of announcements is periodically generated by a particular port of the plurality of ports and includes port metadata for the particular port, the port metadata including capability and application information associated with the particular port;

determine a network mapping of the plurality of ports and the plurality of devices based on the received plurality of announcements, wherein the plurality of ports are members of an announcement group;

generate a three-dimensional view using the network mapping of the plurality of ports and the plurality of devices; and

display the three-dimensional view to a user of the network device.

14. The article of claim 13, wherein the instructions further cause the network device to:

receive a selection of a particular application from the user of the network device; and display, in the three-dimensional view, a representation of a data path associated with the particular application.

15. The article of claim 14, wherein the instructions further cause the network device to:

receive a selection of a particular parameter from the user of the network device; and display, in a particular dimension of the three-dimensional view, a representation of at least one value of the particular parameter.