WO2017123254A1

WO2017123254A1 - Storage area network management packets

Info

Publication number: WO2017123254A1
Application number: PCT/US2016/013710
Authority: WO
Inventors: Rupin T MOHAN; Krishna PUTTAGUNTA; Vivek Agarwal; Sukhinder Singh Sahota
Original assignee: Hewlett Packard Enterprise Development Lp
Priority date: 2016-01-15
Filing date: 2016-01-15
Publication date: 2017-07-20

Abstract

Various examples described herein provide for a method that generates, at a storage area network (SAN) device, a Link Layer Discovery Protocol (LLDP) frame that includes an optional type-length-value (TLV) containing a SAN management packet. According to the method, this LLDP frame may be transmitted from the SAN device to a SAN switch.

Description

STORAGE AREA NETWORK MANAGEMENT PACKETS BACKGROUND

[1] A computing network can include any number of devices connected by data links, and can be specialized to perform specific types of tasks. For example, a Storage Area Network (SAN) is generally a computing network configured to enable access to data storage devices such as disk arrays, tape libraries, jukeboxes, etc.. A SAN can utilize a set of storage protocols, which can include Fibre Channel over-Ethernet (FCoE) and Internet Small Computer System Interface (iSCSI). Generally, iSCSI uses Ethernet as for network communication between computers and peripheral devices for transferring data.

BRIEF DESCRIPTION OF THE DRAWINGS

[2] Certain examples are described in the following detailed description in sampled to the following drawings.

[3] FIGs. 1 and 2 are flowcharts illustrating example methods for storage area network (SAN) management packets according to the present disclosure.

[4] FIG. 3 is a block diagram illustrating an example Link Layer Discovery Protocol (LLDP) Ethernet frame according to the present disclosure.

[5] FIG. 4 is a block diagram illustrating an example storage area network (SAN) switch according to the present disclosure.

[6] FIG. 5 is a block diagram illustrating an example storage area network (SAN) device according to the present disclosure.

DETAILED DESCRIPTION

[7] Managing a Storage Area Networks (SANs) can be a complex activity performed using specialized management applications and out-of-band data networks. Example approaches to managing a SAN can involve manual configuration of a set of devices, which may be error-prone and time-consuming. This is particularly true for SANs that utilize the Internet Small Computer System Interface (iSCSI) protocol, which does not enable management of end devices in a SAN (e.g., host bus adapters [HBAs] or targets) and generally does not support enterprise class datacenter features like zoning, security, quality-of-service (QoS), and Diagnostics.

[8] Various examples described herein facilitate exchange of information between components of a storage area network (SAN) to assist in the management of the SAN or a specific SAN device included by the SAN. in particular, various examples utilize Link Layer Discovery Protocol (LLDP) frames to implement a SAN management protocol in a SAN. According to some examples, a LLDP frame between communicated between a plurality of SAN devices can include a SAN management packet to implement the SAN management protocol. The SAN management packet can permit the exchange of SAN management information between a plurality of SAN devices, and such information can include a SAN management command or response being exchanged between the plurality of SAN devices.

[9] As used herein, a storage area network (SAN) device can include a computer system (e.g., desktop, laptop, server, or mobile device), a piece of networking equipment (e.g., network router or switch in a SAN), a network- enabled storage device (e.g., data storage device array, which may comprise a plurality of disk or solid-state-based storage devices). For instance, a SAN device may be a data storage device array supporting an Internet Small Computer System Interface (iSCSI) protocol. In another instance, the SAN device may be a network switch included by an Ethernet network that helps implement the storage area network (SAN). The different hardware components (e.g., SAN devices) that help implement the storage area network can collectively be referred to as the SAN fabric. Though various examples are described herein with respect to a SAN switch, for other examples, the SAN switch is replaced by another type of SAN device, such as a network router or network gateway.

[10] By utiiizing LLDP frames as described herein, the SAN management protocol described herein can be implemented in-band with LLDP-based communication that a storage area network (SAN) utilizes for other purposes. Accordingly, use of a SAN management packet as described herein can implement an in-band command/response SAN management protocol within a SAN. Certain examples can be employed in conjunction with LLDP frames that utilize the Data Center Bridging exchange (DCBX) protocol to exchange information between SAN devices in a SAN (e.g., DCBX LLDP frames between an iSCSI host bus adapter and a SAN switch).

[11] For some examples, use of the SAN management packet as described herein can provide a set of functions that permit effective management of an SAN, especially an Ethernet-based SAN that may include SAN devices supporting the Internet Small Computer System Interface (iSCSI) protocol. Depending on the example, the set of functions may incorporate various configuration, security, and performance (e.g., enterprise-class) features to an iSCSI SAN fabric. For instance, various example may enable an iSCSI target to orchestrate configuration or management of a SAN.

[12] Through a SAN management packet described herein, various examples allow a device announcement or change notifications by a SAN device, such as an Internet Small Computer System Interface (iSCSI) host bus adapter (HBA) or iSCSI target. A SAN management packet described herein can facilitate zoning (e.g., configuration or management of zoning) on an Ethernet-based SAN, which can include SAN devices supporting the Internet Small Computer System Interface (iSCSI) protocol. For instance, a SAN management packet according to an example can permit an iSCSI target to orchestrate zoning (e.g., through a SAN management packet from the iSCSI target to a SAN switch). Additionally, a SAN management packet described herein can facilitate management of security settings on a SAN, management of quality-of-service (QoS) (e.g., iSCSI target- based QoS) on the SAN, or performance of diagnostics on the SAN.

[13] The following provides a detailed description of examples illustrated by FIGs. 1-5.

[14] FIG. 1 is a flowchart illustrating an example method 100 for storage area network (SAN) management packets according to the present disclosure. According some examples, the method 100 is performed by a SAN device comprising a data storage device array. The SAN device may be one that is operating as an Internet Small Computer System Interface (iSCSI) target within a SAN. Although execution of the method 100 is described below in the context of a SAN device and a SAN switch {e.g., an Ethernet switch), the SAN device performing the method 100 may be any type of SAN device, including another SAN switch (e.g., a second Ethernet switch). The method 100 may be implemented in the form of executable instructions (e.g., firmware or software) stored on a machine-readable medium or in the form of electronic circuitry.

[15] In FIG. 1 , the method 100 may begin at block 102, with generation of a Link Layer Discovery Protocol (LLDP) frame, at a storage area network (SAN) device, where the LLDP frame includes an optional type-length-value (TLV) containing a SAN management packet. Depending on the example, the SAN management packet may comprise a command from the SAN device to a SAN switch, or a response from the SAN device to the SAN switch.

[16] According to various examples, the LLDP frame generated at block 102 is in accordance with Institute of Electrical and Electronics Engineers (IEEE) 802.1 AB standard. Additionally, for some examples, the optional TLV containing the SAN management packet is an organizationally specific TLV (i.e., TLV type 127) as defined by IEEE 802.1AB standard. In such examples, an organizationally defined subtype of the organizationally specific TLV may be used to specify a type for the SAN management packet, and an organizationally defined information string of the organizationally specific TLV contains a data payioad of the SAN management packet. Where examples utilize the LLDP frame with the Data Center Bridging exchange (DCBX) protocol, the set of organizationally defined subtypes not utilized by the DCBX protocol (e.g., a set of subtypes within a range of subtypes [0D through FF] under IEEE 802.1Qaz/D2.5 standard) may be used to specify different a SAN management packet type for the SAN management packet.

[17] The method 100 may continue to block 104, with the SAN device transmitting the Link Layer Discovery Protocol (LLDP) frame generated at block 102 to a SAN switch. For various examples, the SAN device and the SAN switch are part of the same SAN. A SAN including the SAN device and the SAN switch may comprise an Ethernet network (IEEE 802.3), and the SAN switch may be an Ethernet switch. The LLDP frame may be an Ethernet frame containing a Link Layer Discovery Protocol Data Unit (LLDPDU). [18] According to some examples, in order for the LOOP frame to reach the SAN switch, the LLDP frame generated at block 102 may comprise a destination Media Access Control (MAC) address of 01 -80-C2-00-00-0E, which in accordance with the Institute of Electrical and Electronics Engineers (IEEE) 802.1 AB standard, is the destination MAC address used to route the LLDP frame to the network bridge that is nearest to the SAN device on the SAN.

[19] For some examples, the SAN shared by the SAN device and the SAN switch may utilize the Internet Small Computer System Interface (iSCSI) protocol (e.g., the SAN Is ISCSI SAN fabric) and, as such, the SAN management packet may relate to the management of that iSCSI SAN fabric. Depending on the example, the SAN device may be one that is directly coupled to the SAN switch, or may be one coupled to the SAN switch by way of set of intermediary SAN devices.

[20] The SAN management packet may relate to registration of the SAN device wrth the SAN switch. For instance, the SAN device may comprise an Internet Small Computer System Interface (ISCSI) target adapter (e.g., host bus adapter) that is registering with the SAN switch. Accordingly, the SAN management packet may comprise a registration (e.g., host bus adapter or port registration) command from the SAN device to the SAN switch, and may further comprise parameters to for the registration. The SAN management packet may relate to zoning configuration of a SAN including the SAN device and the SAN switch. For instance, the SAN management packet may comprise a command requesting zoning status, creating a zone (e.g., a set of zones), activating a zone, querying for the active zone, adding an active zone, removing an active zone, or replacing an active zone. The SAN management packet may relate to diagnostic information of a SAN including the SAN device and the SAN switch. For instance, the SAN management packet may comprise a command requesting diagnostic parameters for the SAN from the SAN switch. The SAN management packet may relate to querying a status of a SAN including the SAN device and the SAN switch. For instance, the SAN management packet may comprise a command querying for a list of initiators (e.g., Internet Small Computer System Interface [iSCSI] initiators) or for a list of targets (e.g., iSCSI targets) included by the SAN. The SAN management packet may relate to a notification involving the SAN device. For instance, the SAN management packet may comprise a notification or registration of a state change of the SAN device.

[21] FIG.2 is a flowchart illustrating an example method 200 for storage area network (SAN) management packets according to the present disclosure. Similar to the method 100 described above with respect to FIG. 1 , the method 200 may be performed by a SAN device comprising a data storage device array, and the SAN device may be one that is operating as an Internet Small Computer System Interface (iSCSI) target within a SAN. Although execution of the method 100 is described below in the context of a SAN device and a SAN switch (e.g., an Ethernet switch), the SAN device performing the method 200 may be any type of SAN device, including another SAN switch (e.g., a second Ethernet switch). The method 200 may be implemented in the form of executable instructions stored on a machine-readable medium or in the form of electronic circuitry.

[22] According to some examples, blocks 202 and 204 of the method 200 may be respectively similar to blocks 102 and 104 of the method 100 as described above with respect to FIG. 1. After block 204, the method 200 may continue to block 206, with the with the SAN device receiving a second Link Layer Discovery Protocol (LLDP) frame from the SAN switch.

[23] The method 200 may continue to block 206, with the SAN device receiving a second Link Layer Discovery Protocol (LLDP) frame from the SAN switch, where the second LLDP frame includes a second optional type-length- value (TLV) containing a second SAN management packet. Depending on the example, the second SAN management packet may comprise a command from the SAN switch to the SAN device, or a response from the SAN switch to the SAN device. For some example, the second LLDP frame is generated at the SAN switch. For instance, the second LLDP frame may be generated based on (e.g., in response to) the LLDP frame generated at block 202 and transmitted to the SAN switch from the SAN device at block 204.

[24] Like the LLDP frame generated at block 202, the second LLDP frame may be in accordance with Institute of Electrical and Electronics Engineers (IEEE) 802.1 AB standard. Additionally, like the LLDP frame generated at block 202, the second LLDP frame may be may be an Ethernet frame containing a Link Layer Discovery Protocol Data Unit (LLDPDU). For some examples, the second optional TLV containing the second SAN management packet is an organizationally specific TLV (i.e., TLV type 127) as defined by IEEE 802.1AB standard. Similar to the LLDP frame of block 202, an organizationally defined subtype of the organizationally specific TLV may be used to specify a type for the second SAN management packet, and an organizationally defined information string of the organizationally specific TLV contains a data payload of the second SAN management packet. Where examples utilize the second LLDP frame with the Data Center Bridging exchange (DCBX) protocol, the set of organizationally defined subtypes not utilized by the DCBX protocol (e.g., a set of subtypes within a range of subtypes (0D through FF] under IEEE 802.1Qaz/D2.5 standard) may be used to specify a SAN management packet type for the second SAN management packet.

[25] FIG. 3 is a block diagram illustrating an example Link Layer Discovery Packet (LLDP) Ethernet frame 300 according to the present disclosure. As described herein, the LLDP Ethernet frame 300 may be generated at a SAN device and transmitted to a SAN switch, or may be generated at a SAN switch and transmitted to a SAN device. The LLDP frame utilized by various examples may be similar (e.g., in structure, content, or usage) to the LLDP Ethernet frame 300 as described herein. In FIG. 3, the LLDP Ethernet frame 300 includes a LLDP Data Unit (LLDPDU) 302. According to various examples, the LLDP Ethernet frame 300 may conform to the Institute of Electrical and Electronics Engineers (IEEE) 802.3 standard, and the LLDPDU 302 may conform to the IEEE 802.1 AB standard. The LLDP Ethernet frame 300 comprises an Ethernet header 304, a chassis ID type-length-value (TLV) 306, a port ID TLV 308, a time-to-live TLV 310, a set of optional TLVs 312 that includes an organizationally specific TLV 314, and an end of LLDPDU TLV 316. As shown in FIG. 3, the organizationally specific TLV 314 comprises a TLV type 318, a TLV info string length 320, an organizationally unique identifier (OUI) 322, an organizationally defined subtype 324, and an organizationally defined information string 326. [26] According to some examples, the Ethernet header 304 comprises a preamble, a destination Media Access Control (MAC) address, a source MAC address, and an EtherType. The chassis ID type-length-value (TLV) 306 may represent the chassis identification for the device that transmuted the LLDP Ethernet frame 300. The port ID TLV 306 may represent the identification of the specific port that transmitted the LLDP Ethernet frame 300. The time-to-live TLV 310 may represent the length of time that information contained in the LLDP Ethernet frame 300 shall be considered valid. The set of optional TLVs 312, which includes the organizationally specific TLV 314, may represent custom TLVs in accordance with the Institute of Electrical and Electronics Engineers (IEEE) 802.1 AB standard. The end of LLDPDU TLV 316 may mark the end of data within the LLDPDU 302.

[27] With respect to the organizationally specific type-length-value (TLV) 314, the type-length-value (TLV) type 318 may be set to 127 to represent that the organizationally specific TLV 314 is of an organizationally specific type of optional TLV in accordance with the Institute of Electrical and Electronics Engineers (IEEE) 802.1AB standard. The TLV info string length may represent the data length of the organizationally specific TLV 314. The organizationally unique identifier (OUI) 322 may contain an identifier (e.g., number) that represents an association between the organizationally specific TLV 314 and a specific organization, such as a company (e.g., HEWLETT PACKARD ENTERPRISE). For some examples, the OUI 322 is utilized to distinguish an optional TLV (e.g., an organizationally specific TLV) containing a SAN management packet from other possible optional TLVs in the LLDP Ethernet frame 300 (e.g., other possible organizationally specific TLVs) that do not contain a SAN management packet.

[28] According to some examples, the organizationally defined subtype 324 and the organizationally defined information string 326 contain a SAN management packet as described herein. For some examples, the organizationally defined subtype 324 specifies a SAN management packet type 328 for the SAN management packet 332 contained by the organizationally specific type-length-value (TLV) 314. Further, according to some examples, the organizationally defined information string 326 comprises a SAN management packet data payioad 330 for the SAN management packet 332 contained by the organizationally specific TLV 314. The type of data contained in the SAN management packet data payioad 330 may correspond to the SAN management packet type 328 specified by the organizationally defined subtype 324. Additionally, as described herein, an organizationally defined subtype used to specify a type of SAN management packet may be one that is reserved by an Institute of Electrical and Electronics Engineers (IEEE) 802.1 standard (e.g., one reserved under the IEEE 802.1 Qaz/D2.5 standard).

[29] Table 1 represents an example mapping that may be utilized (as described herein) between a set of different types of SAN management packets and a range of different organizationally defined subtypes. Where applicable, Table 1 also indicates example SAN management packet data payloads for a corresponding SAN management packet type. For various examples, the SAN management packet type mappings and data payioads may differ from those shown in Table 1. For some examples, the mapping provided in Table 1 is utilized in conjunction with the Internet Small Computer System Interface (ISCSI) protocol.

[30] FIG. 4 is a block diagram illustrating an example storage area network (SAN) switch 400 according to the present disclosure. For various examples, the SAN switch 400 comprises an Ethernet switch that resides on an Ethernet network included as part of a SAN. As shown, the SAN switch 400 includes a network interface 402, a SAN management packet decoder 404, and a SAN management packet responder 406. In various examples, the components or the arrangement of components in the SAN switch 400 may differ from what is depicted in FIG. 4. For instance, the SAN switch 400 may include more or less components than those depicted in FIG. 4.

[31] As used herein, components of various examples may comprise, in whole or in part, hardware (e.g., electronic circuitry), programming (e.g., machine- readable instructions), or a combination of both to implement functionalities described herein. For instance, an interface, decoder, or responder may comprise machine-readable instructions executable by a processor (e.g., a computer processor) to perform one or more functions in accordance with various examples described herein. In another instance, an interface, decoder, or responder may comprise electronic circuitry to perform one or more functions in accordance with various examples described herein. In yet another instance, an interface, decoder, or responder may comprise a combination of machine-readable instructions, stored on at least one non-transitory machine-readable storage medium, and at least one processing resource (e.g., controller) to execute those instructions.

[32] A network interface 402 may facilitate data communication between the SAN switch 400 and a SAN device over a communications network comprising a set of data links. The communications network may comprise, in whole or in part, a storage area network (SAN). The communications network may comprise a set of SAN switches or other SAN devices coupled by a set of data links, such as Ethernet interface connections, and, more specifically, Internet Small Computer System Interface (iSCSI) interface connections.

[33] According to various examples, by way of the network interface 402, the SAN switch 400 may receive a Layer Discovery Protocol (LLDP) frame from the SAN device. Additionally, by way of the network interface 402, the SAN switch 400 may transmit a LLDP frame to the SAN device, or may receive a LLDP frame from the SAN device. Through the network interface 402, the SAN switch 400 may be directly coupled to the SAN device over a direct physical data link. Further, the communication network may comprise an Ethernet network and the LLDP frame may be an Ethernet frame.

[34] The SAN switch 400 and the SAN device to which the SAN switch 400 transmits the Layer Discovery Protocol (LLDP) frame may support Internet Small Computer System Interface (iSCSI) protocol. As described herein, the use of the LLDP frame described herein may enable various features, including but not limited to zoning, security, quality-of-service (QoS), and diagnostics. In the context of iSCSI, the SAN device may be an iSCSI target device (e.g., iSCSI target adapter).

[35] The SAN management packet decoder 404 may decode a SAN management packet included by an optional type-length-value (TLV) contained by the LLDP frame received through the network interface 402. For various examples, the LLDP frame received or transmitter through the network interface 402 may be similar (e.g., in structure, content, or usage) to the LLDP Ethernet frame 300 as described above with respect to FIG. 3.

[36] The SAN management packet decoder 404 may decode the SAN management packet frame by first locating the optional TLV in the LLDP frame that contains the SAN management packet. For instance, where the LLDP frame is similar to the LLDP Ethernet frame 300 of FIG.3, the SAN management packet decoder 404 may locate the optional TLV by locating a set of optional TLVs in the LLDP frame that have a type of 127, which designates them as organizationally specific TLVs. For examples where the LLDP frame can contain a plurality of organizationally specific TLVs, an organizationally specific TLV containing a SAN management packet may be distinguished from other organizationally specific TLVs (that do not contain a SAN management packet) by using distinguishing value in the organizationally unique identifier (QUI). For some examples, the type of optional TLV that contains SAN management packets may be different from the organizationally specific type or may include more than the organizationally specific type.

[37] Upon locating within the LLDP frame the optional TLV that contains the SAN management packet, the SAN management packet decoder 404 may continue to decode the SAN management packet by accessing the portion(s) of the optional TLV that contain data associated with the SAN management packet. For instance, where the LLDP frame is similar to the LLDP Ethernet frame 300 of FIG. 3 and the optional TLV is an organizationally specific TLV, the SAN management packet decoder 404 may access the organizationally defined subtype of the organizationally specific TLV, the organizationally defined information string of the organizationally specific TLV, or both. According to some examples, the organizationally defined subtype specifies the type of SAN management packet contained by the organizationally TLV. Examples types of SAN management packets include, but are not limited to, commands, responses, and the like. For some examples, such commands or responses may to facilitate a SAN management function within a SAN. Additionally, for some examples, the organizationally defined information string contains a data payload of the SAN management packet. Example data payioads include, but are not limited to, command parameters, response data, configuration data, and the like.

[38] For some examples, the LLDP frame may contain a plurality of optional TLVs that include different SAN management packets, and the SAN management packet decoder 404 may perform the foregoing process for each optional TLV in the plurality.

[39] The SAN management packet responder 406 may perform an operation at the SAN switch 400 in response to the SAN management packet. According to some examples, operation comprises generating a second Layer Discovery Protocol (LLDP) frame based on the SAN management packet, where the second LLDP frame includes a second optional TLV containing a second SAN management packet. For instance, depending on the SAN management packet received by the SAN switch 400 from the SAN device, the second SAN management packet may be a response acknowledging a command received from the SAN device through the SAN management packet, in another instance, the second SAN management packet may be a response having a SAN management packet data payioad containing information (e.g., SAN diagnostic information, status information, zoning information, target and initiator information, etc.) requested by the SAN device through the SAN management packet. Further, depending on the example, the operation may comprise performing SAN operation at the SAN switch 400, such as creating, activating, adding, removing, or changing zoning for the SAN. In this way, the SAN device can orchestrate and manage zoning within the SAN.

[40] FIG. 5 is a block diagram illustrating an example storage area network (SAN) device 500 according to the present disclosure. For various examples, the SAN device 500 is data storage device array, which may support the Internet Small Computer System Interface (iSCSI) protocol. Additionally, for various examples, the SAN device 500 communicates data with a SAN switch over an Ethernet network included as part of a SAN. As shown, the SAN device 500 includes a machine-readable medium 502, a processor 504, and a network interface 506. In various examples, the components or the arrangement of components of the SAN device 500 may differ from what is depicted in FIG. 5. For instance, the SAN device 500 may include more or less components than those depicted in FIG. 5.

[41] The machine-readable medium 502 may be any electronic, magnetic, optical, or other physical storage device that stores executable instructions. For example, the machine-readable medium 502 may be a Random Access Memory (RAM), an Electrically-Erasable Programmable Read-Only Memory (EEPROM), a storage drive, an optical disc, or the like. The machine-readable medium 502 can be encoded to store executable instructions that cause the processor 504 to perform operations in accordance with various examples described herein. In various examples, the machine-readable medium 502 is non-transitory. As shown in FIG. 5, the machine-readable medium 502 includes instructions 508 to generate a Link Layer Discovery Protocol (LLDP) frame that includes a SAN management packet, and instructions 510 to transmit a LLDP frame to a SAN switch.

[42] The processor 504 may be one or more central processing units (CPUs), microprocessors, or other hardware devices suitable for retrieval and execution of one or more instructions stored in the machine-readable medium 502. The processor 504 may fetch, decode, and execute the instructions 508 and 510 to enable the SAN device 500 to perform operations in accordance with various examples described herein. For some examples, the processor 504 includes one or more electronic circuits comprising a number of electronic components for performing the functionality of one or more of the instructions 508 and 510.

[43] The network interface 506 may facilitate communication with another SAN device over a communications network comprising of a set of data links. The communications network may comprise, in whole or in part, a storage area network (SAN). The communications network may comprise a set of SAN switches or other SAN devices coupled by a set of data links, such as Ethernet interface connections, and, more specifically, Internet Small Computer System Interface (iSCSI) interface connections. Further, the communication network may comprise an Ethernet network and the LLDP frame may be an Ethernet frame. The network interface 506 may facilitate transmitting and receiving LLDP frames in accordance with various examples described herein. Through the network interface 506, the SAN device 500 may be directly coupled to a SAN switch over a direct physical data link.

[44] The instructions 508 may cause the processor 504 to generate a Link Layer Discovery Protocol (LLDP) frame that includes an organizationally specific type-length-value (TLV) containing a SAN management packet. As described herein, an organizationally defined subtype of the organizational specific TLV may specify a type for the SAN management packet, and an organizationally defined information string of the organizationally specific TLV may contain a data payload of the SAN management packet The instructions 510 may cause the processor 504 to transmit the LLDP frame to a SAN switch over a SAN that communicatively couples the SAN device to the SAN switch. As described herein, the processor 504 may transmit the LLDP frame to the SAN switch via the network interface 506.

[45] in the foregoing description, numerous details are set forth to provide an understanding of the subject disclosed herein. However, various examples may be practiced without some or all of these details. Some examples may include modifications and variations from the details discussed above. It is intended that the appended claims cover such modifications and variations.

Claims

1. A method, comprising:

generating, at a storage area network (SAN) device, a Link Layer Discovery Protocol (LLDP) frame that includes an optional type-length-value (TLV) , the optional TLV containing a SAN management packet; and

transmitting, from the SAN device, the LLDP frame to a SAN swftch.

2. The method of claim 1 , wherein the SAN management packet relates to management of an internet Small Computer System Interface (iSCSI) SAN fabric that includes the SAN device and the SAN switch.

3. The method of claim 1 , wherein the SAN management packet relates to registration of the SAN device, zoning configuration of a SAN that includes the SAN device and the SAN switch, diagnostic information involving the SAN, querying a status of the SAN, or a notification involving the SAN device.

4. The method of claim 1 , wherein the SAN device comprises an Internet Small Computer System Interface (iSCSI) target adapter.

5. The method of claim 1 , wherein the optional TLV comprises an organizationally specific TLV.

6. The method of claim 1 , wherein the SAN management packet comprises a command from the SAN device to the SAN switch.

7. The method of claim 1 , wherein the SAN management packet comprises a response from the SAN device to the SAN swftch.

8. The method of claim 1 , comprising receiving, at the SAN device, a second LLDP frame from the SAN switch, the second LLDP frame including a second optional TLV that contains a second SAN management packet.

9. The method of claim 8, wherein the second SAN management packet comprises a command from the SAN switch to the SAN device.

10. The method of claim 8, wherein the second SAN management packet comprises a response from the SAN switch to the SAN device.

11. A storage area network (SAN) switch, comprising:

a network interface to receive, from a SAN device, a Link Layer

Discovery Protocol (LLDP) frame over a SAN;

a SAN management packet decoder to decode a SAN management packet included in an optional type-length-value (TLV) contained by the LLDP frame; and

a SAN management packet responder to perform an operation at the SAN switch in response to the SAN management packet.

12. The SAN switch of claim 11 , wherein the operation comprises generating a second LLDP frame based on the SAN management packet, the second LLDP frame including a second optional TLV that contains a second SAN management packet.

13. A non-transitory machine-readabie medium having instructions stored thereon, the instructions being executable by a processor of a storage area network (SAN) device, the instructions causing the processor to:

generate a Link Layer Discovery Protocol (LLDP) frame that includes an organizationally specific type-length-value (TLV), the organizationally specific TLV containing a SAN management packet; and

transmit the LLDP frame to a SAN switch over a SAN that

communicatively couples the SAN device to the SAN switch.

14. The non-transitory machine-readabie medium of claim 13, wherein an organizationally defined subtype of the organizationally specific TLV specifies a type for the SAN management packet

15. The non-transitory machine-readable medium of claim 13, wherein an organizationally defined information string of the organizationally specific TLV contains a data payload of the SAN management packet.