As mentioned in the background, the manner in which each phase of device discovery is completed is substantially user-defined. Typically, switch fabric interconnections or topologies are complex and may frequently change due to device removals/additions (e.g., hot swapping), communication link failures, device failovers, etc. Therefore, implementing a device discovery scheme that is slow or inefficient may be problematic to meeting stringent reliability needs of telecommunication and/or data centers that commonly employ switch fabrics to rapidly move data.
In one example, a fabric manager implements a scheme to discover one or more devices coupled to the switch fabric. The scheme to include the fabric manager locating a device coupled to the fabric manager via a path routed through the switch fabric. The fabric manager to also collect information via the path to determine one or more memory locations at the device that stores information associated with a plurality of capabilities for the device to operate on the switch fabric. The fabric manager to read the one or more memory locations at the device based on the determination. This reading is to occur such that the information associated with the plurality of capabilities is read in a parallel manner via the path. A table is maintained by the fabric manager for the device, the table to include the information associated with the plurality of capabilities that was read from the one or more memory locations. The fabric manager is to use the table to configure the device for operating on the switch fabric. The fabric manager is to also enter the device in a fabric map for the switch fabric.
In one example, switch fabric 100 is operated in compliance with the ASI specification, although this disclosure is not limited to only switch fabrics that operate in compliance with the ASI specification. In
In one example, as depicted in
As depicted in
In one implementation, following the selection/election of endpoint node 116 as the host for fabric manager 150, fabric manager 150 implements a device discovery scheme. This discovery scheme, for example, includes locating one or more devices coupled to or within switch fabric 100, e.g., endpoints 110-115 and 117 and switches 102-106. In one example, fabric manager 150 locates endpoint 110 via one or more paths routed through the switch fabric.
In this implementation, fabric manager 150 may collect information via path 141 and/or 142 to determine the memory location(s) for information associated with endpoint 110's capabilities. This information, for example, is collected via read request and corresponding read completion data packets (described more below) that are routed via path 141 and/or path 142. Based on the information collected, for example, fabric manager 150 reads the memory location(s) in a parallel manner to obtain the capability information.
In one example, this parallel manner may include fabric manager 150 sending one or more read request data packets to endpoint 110 via path 141 and/or 142 to obtain information for a plurality of capabilities. These read request data packets, for example, may each include block read requests that enable fabric manager 150 to read a multitude of memory locations (e.g., blocks of memory) in memory 160 at endpoint 110. Or a plurality of read request data packets in composite may allow fabric manager 150 to read a multitude of memory locations should endpoint 110 not support a block read functionality or should information associated with the plurality of capabilities be located in blocks of memory that are non-contiguous (e.g., located in different apertures) and/or too large to fit within a given block of memory.
In one example, fabric manager 150 maintains a table (e.g., at endpoint 116's memory 160) for endpoint 110 that includes the information associated with the plurality of capabilities that was read from endpoint 110's memory 160. This information maintained in the table for endpoint 110, for example, is used to configure endpoint 110 for operating on switch fabric 100. Endpoint 110 may also be added by fabric manager 150 to a switch fabric 100 map, e.g., maintained at a memory resident on endpoint 116 and/or responsive to fabric manager 150. The switch fabric 100 map includes each device discovered by fabric manager 150, for example, as described above for discovering endpoint 110. The switch fabric 100 map may also include an indication of at least a portion of the capabilities read from memory location(s) at each device and maintained in a respective capability table for each discovered device. In one example, the switch fabric 100 map is used by fabric manager 150 to facilitate its management/control of switch fabric 100.
In one implementation, switch fabric 100 operates in compliance with the ASI specification. In this implementation, a unique identification for endpoint 110 may have not been initialized at endpoint 110 prior to fabric manager 150 collecting, reading and maintaining a table for endpoint 110 via a path that is a non-primary path. According to the ASI specification a primary path provides privileged access for a fabric manager to configure or initialize a capability of a device. Initialization of a unique identification, according to the ASI specification is part of configuring the device.
In one example, following selection/election of endpoint 116 to host fabric manager 150, fabric manager 150 gains ownership of a given spanning tree (ST) path coupled between fabric manager 150 and each device in switch fabric 100, e.g., endpoint 110. That ST path is known, for example, by each device and fabric manager 150 and is considered as the primary path. For example, the ST path may be path 141 and fabric manager 150 can forward management/control instructions to endpoint 110 via path 141. Thus, ownership of path 141 grants fabric manager 150 privileged access to endpoint 110 to configure endpoint 110 to operate on switch fabric 100, e.g., write information into endpoint 10's configuration memory locations that are port of its memory 160. Thus if endpoint 110 receives a configuration request (e.g., initialization of a unique identification) it ignores the request if the request was not routed via path 141. Since fabric manager 150 is the ST path owner of path 141 and in this example path 142 is not an ST path owned by fabric manager 150, path 142 is a non-primary path.
In this ASI compliant implementation, fabric manager 150 may maintain a device capability table for information obtained via path 141 and maintain an other device capability table for information obtained via path 142. This may result in endpoint 110 having two entries in the switch fabric 100 map. Thus, in one example, fabric manager 150 consolidates the information into a single capability table for endpoint 110 and removes the redundant/duplicate entry associated with the non-primary path from the switch fabric 100 map.
In one implementation, control logic 220 is a resource resident on endpoint 116 and controls the overall operation of endpoint 116 and may represent any of a wide variety of logic device(s) or executable content an endpoint node allocates to host fabric manager 150. Control logic 220 may be a microprocessor, network processor, microcontroller, field programmable gate array (FPGA), application specific integrated chip (ASIC), or any combination thereof
In
According to one example, as mentioned above for
I/O interfaces 240 provide a communications interface via a communication medium or link between endpoint 116 and other devices coupled to or remote to switch fabric 100. As a result, I/O interfaces 240 enable control logic 220 to receive a series of instructions from application software running on endpoint 116 or external to endpoint node 116. The series of instructions may cause control logic 220 to activate fabric manager 150 to implement a scheme to discover one or more devices coupled to switch fabric 100.
In one example, endpoint 116 includes one or more applications 250 to provide internal instructions to control logic 220. Such applications 250 may be activated to generate a user interface, e.g., a graphical user interface (GUI), to enable administrative features, and the like. For example, a GUI provides a user access to memory 160 to modify or update information to facilitate fabric manager 150's discovery of devices coupled to switch fabric 100.
In an other example, applications 250 include one or more application interfaces to enable external applications to provide instructions to control logic 220. One such external application could be a GUI as described above.
In one example, aperture 310 includes capability pointer 312, capability record 314 and capability structures 316. In one implementation, capability pointer 312 includes a pointer to indicate where in aperture 310 (e.g., via an offset) that capability record 314 is located. Capability record 314, for example, includes basic device or component information that may be used by a fabric manager (e.g., fabric manager 150) to uniquely identify a device coupled to a switch fabric. Capability record 314, in one example, also includes a pointer to a location in aperture 310 that includes capability structures 316. In one example, these capability structures are portrayed in
In one implementation, each capability structure of capability structures 316 includes information to identify a given capability that a device can support. For example, in an ASI compliant switch fabric 100, devices coupled to switch fabric 100 may indicate ASI capabilities in these capability structures. As portrayed in
In one example, each capability structure of capability structures 316 may also include an indication of a memory location where information associated with the given capability is stored at a device. That information, for example, may be located at memory blocks 326 or 336 at aperture 320 and aperture 330, respectively or located at an other portion of memory 160. In one example, the arrows connecting capability structure 316A to capability data 326A at aperture 320 illustrates an indication of a memory location for information associated with a capability identified in capability structure 316A. The arrow connecting capability structure 316C to capability data 326C at aperture 320, for example, illustrates an indication of a memory location for information associated with a capability identified in capability structure 316C. Also an arrow connecting capability structure 316D to capability data 336D at aperture 330, for example, illustrates yet an other indication of a memory location for information associated with a capability identified in capability structure 316D.
In one example, capability data for a plurality of capabilities may be encompassed within a range of physical memory locations or blocks of memory. Thus as depicted in
In one example, collected capability information can be used by fabric manager 150 to read one or more memory locations of memory 160 (e.g., at apertures 300) at endpoint 110. The memory locations, for example, are to include information or data associated with a plurality of capabilities for endpoint 110 to operate on switch fabric 100.
In the diagram depicted in
In one example, at circle 1.0, fabric manager 150 generates and sends a message (e.g., a PI-4 read request) depicted as “Request_Capability_Pointer.” This message, for example, results in endpoint 110 generating and sending a response message (e.g., a PI-4 read completion) depicted as “Capability_Pointer_Location” at circle 1.1. For example, the “Capability_Pointer_Location” may include the location of capability pointer 312 in aperture 310 as described for
At circle 2.0, for example, fabric 150 generates and sends a message depicted as “Read_Capability_Pointer.” In response, endpoint 110 generates and sends a “Capability_Pointer_Information” message. In one example, the capability pointer information in this message indicates the memory location of capability record 314 described above for
At circle 3.0, for example, fabric manager 150 generates and sends a message depicted as “Read_Capability_Record.” In response, endpoint 110 generates and sends a “Capability_Record_Information” message. In one example, the capability record information in this message includes basic device or component information that may enable fabric manager 150 to uniquely identify endpoint 110. Capability record 314, in one example, also includes an indication of a location in aperture 310 that includes the first capability structure (e.g., capability structure 316A) of capability structures 316. In one example, fabric manager 150 retains (e.g., in a portion of memory 160 at endpoint 116) the basic device information for a capability table to be maintained for endpoint 110. This capability table, for example, is to include information associated with one or more capabilities for endpoint 110. As described below, based on the information included in each capability structure of capability structures 316, the memory location of this information is determined by fabric manager 150.
At circle 4.0, for example, fabric manager 150 generates and sends a “Read_First_Capability_Structure” message. This message for example, includes the memory location included in the “Capability_Record_Information” message depicted at circle 3.1. In response, endpoint 110 generates and sends a “First_Capability_Structure_Information” message. In one example, the first capability structure is capability structure 316A and it includes information that identifies a given capability for endpoint 111 (e.g., event reporting capabilities). Capability structure 316A, in this example, also includes a pointer or offset to indicate where capability structure 316B is located within aperture 310.
In one example, at circles 5.0, 6.0 and 7.0 and corresponding circles 5.1, 6.1 and 7.1, messages are exchanged between fabric manager 150 and endpoint 110 in a similar manner to obtain information from capability structures 316B-D. In this example, one difference is that since capability structure 316D is the last capability structure, it will include an indication that it is the last capability structure and this is denoted at circle 7.1 as a “Last_Capability_Structure_Information” message.
In one example, based on the exchange of messages at circles 1.0 to 7.0, fabric manager 150 has collected enough information to determine the memory locations at endpoint 110 where information associated with the capabilities described in capability structures 116A-116D are located. In one implementation, fabric manager 150 may determine that information for a plurality of capabilities are stored in one or more blocks of physical memory locations. As shown in
In one implementation, fabric manager 110 has determined that endpoint 110 does not have the capability to support a block read request. In this implementation, fabric manager 150 generates a plurality of “Read_Cap—1_to—3” messages that cause endpoint 110 to respond with a corresponding number of “Capability—1_to—3_Information” messages as depicted as an alternative at circle 8.1 and at circles 8.2 to 8.9. Each “Read_Capability—1_to—3” message may have an identification number (see
In one example, information for one or more capabilities may be located in disparate apertures and thus a single read request may not be able to read the different apertures. At circle 9.0, for example, a “Read_Capability—4” is depicted, where “4” represents ASI capability 4 data. As depicted in
In one example, whether sending one or a plurality of “Read_Capability—1_to—3” messages, or sending both a “Read_Capability—1—3” and a “Read_Capability—4” message, the effect is that fabric manager 150 is enabled to read the one or more memory locations associated with a plurality of capabilities of endpoint 110 in a parallel manner. This is in contrast to the serial manner that the capability structures were read via the messages exchanged at circles 1.0 through 7.1. This parallel manner is depicted in
In one example, the fields in message formats 510, 520 and 530 that include an “R” are reserved.
Message format 510 depicted in
Field 512, in one example, includes an indication that the data packet is a read request data packet. Field 513, in one example, includes an indication of the number of dwords (e.g., blocks of memory locations) that are to be read to complete the read request. Field 514, in one example, includes a transaction identification so that a fabric manager can identify a response message that is associated with the read request. In one example, a corresponding read completion message for a given read request will include the same transaction number in the read completion message. Also, for example, the transaction identification may be included in error messages (e.g., malformed data packet) so that the fabric manager can resend or regenerate a new read request.
Field 515, in one example, includes an aperture number to which the read request is being made. For example, as shown in
Field 517, in one example, includes an indication of whether the read request is a block read request or a single dword read request.
Message format 520 depicted in
Field 522, in one example, includes an indication that the data packet is a read completion data packet. Field 523, in one example, includes an indication of the number of dwords that are included in the payload of a data packet in format of message format 520. Field 524, in one example, includes a transaction identification so that a fabric manager can match the read completion message with that of the read request. As mentioned for field 514 in message format 510, in one example, a corresponding read completion message for a given read request will include the same transaction number in the read completion message. Field 525, in one example, includes an aperture number from which the read completion is read from.
Field 526, in one example, contains the payload for a read completion data packet in the format of message format 520. This payload, for example, may include 1 to 8 dwords and thus field 526 can include dword 3 for a 1 dword payload or dwords 3-10 for an 8 dword payload.
Message format 530 depicted in
Field 532, in one example, includes an indication that the data packet is a write request data packet. Field 533, in one example, includes an indication of the number of dwords that are to be written to a memory location. Field 534, in one example, includes a transaction identification so that a fabric manager can identify possible error messages received and associated with the write request (e.g., malformed data packet or invalid write request) so that the fabric manager can resend or regenerate a new write request.
Field 535, in one example, includes an aperture number to which the write request is being made. Field 536, for example, is used to indicate the memory location offset in the aperture indicated in filed 535. This offset, for example, points to a memory location at the aperture where the write request is to begin.
Field 537, in one example, contains the payload for a write request data packet in the format of message format 530. This payload, for example, may include 1 to 8 dwords and thus field 537 can include dword 3 for a 1 dword payload or dwords 3-10 for an 8 dword payload. The payload included in a data packet in the format of message format 530, for example, may include capability information that a fabric manager uses to configure or initialize a device for operating on a switch fabric.
At state 610, in one example, once a device is located, fabric manager 150 activates communicate feature 212 to generate a read request message in the format of message format 510. While in state 610, for example, fabric manager 150 is seeking to read the capability pointer 312 as depicted in aperture 310 in
At state 620, in one example, fabric manager 150 receives a read completion message in the format of message format 520 in response to the read request for capability pointer 312. Communicate feature 212, for example, extracts information from that response to determine the memory location for capability record 314 that is also in aperture 310. A read request message, for example, is then generated in the format of message format 510 by communicate feature 212 to read capability record 314 in aperture 310.
At state 630, in one example, fabric manager 150 receives a read completion message in the format of message format 520 in response to the read request for capability record 314. Fabric manager 150, for example, activates capability feature 214. Capability feature 214, for example, extracts basic device information from the response message. In one example this basic device information includes identification information for the device being discovered. In one example, capability feature 214 retains that information to start a capability table for the device. As mentioned above, in one example, this capability table may include information associated with a plurality of capabilities for the device to operate on switch fabric 100. This capability table, for example, is at least temporarily stored or maintained in a memory (e.g., a portion of memory 160) responsive to fabric manager 150.
Also while in state 630, in one example, fabric manager 150 seeks to read one or more capability structures of capability structures 316 in aperture 310. Communicate feature 212, for example, extracts information from the response received for reading capability record 314 to determine the memory location for the first capability structure of capability structures 316, e.g., capability structure 316A. A read request message, for example, is then generated in the format of message format 510 by communicate feature 212 to read capability structure 316A in region 2 of aperture 310.
At state 632, in one example, fabric manager 150 receives a read completion message in the format of message format 520 in response to the read request for capability structure 316A. Capability feature 214, for example, extracts any applicable capability information from the response message for reading capability structure 316A. This applicable capability information, for example, may include one or more memory locations where capability data is stored at the device. This capability data may be associated with a given capability, e.g., multicasting routing capabilities if the device is a switch or has switching capabilities. Capability feature 214 may collect this information in a parallel read table and at least temporarily store that parallel read table in a memory (e.g., a portion of memory 160). Communicate feature 212, for example, then extracts information from the response received for reading capability structure 316A to determine the memory location for the next capability structure of capability structures 316, e.g., capability structure 316B. A read request message, for example, is then generated in the format of message format 510 by communicate feature 212 to read capability structure 316B.
At states 634, 636 and 638, in one example, in order to read information at capability structures 326B-D the same extraction, collecting and generating processes are carried out by capability feature 214 and communicate feature 212. In one example, at state 638, communicate feature 212 determines that capability structure 316D is the last capability structure. Thus, in this example, no further read requests to read capability structures 316 are generated.
At state 640, in one example, capability feature 214 obtains the applicable memory locations for the capability data collected and temporarily stored in the parallel read table. As mentioned above, those memory locations were read from capability structures 316A-D. Communicate feature 212, in one example, based on the data collected in the parallel read table, determines capability data that can be read via one or more read requests and generates the one or more read request messages in the format of message format 510 in order to read the capability data in a parallel manner.
At states 642, 644, 646 and 648, in one example, communicate feature 212 generates and sends two read request messages in the format of message format 510. These two read request messages, for example, are to read the memory locations holding the capability data or information associated with the capabilities indicated in capability structures 316A-D. In one example, as shown in
At state 650, in one example, in response to the two read request messages, fabric manager 150 receives two read completion messages in the format of message format 520. These read completion messages include the information associated with the 4 ASI capabilities indicated in capability structures 316A-D. Configuration feature 214, for example, extracts the capability information in the read completion messages and updates the capability table and at least temporarily stores or maintains the capability table in a memory responsive to fabric manager 150.
At state 660, in one example, fabric manager 150 activates configuration feature 216. Configuration feature 216, for example, enters the device in a switch fabric 100 map. The switch fabric 100 map, for example, is at least temporarily stored or maintained in a memory (e.g., a portion of memory 160) responsive to fabric manager 150. The switch fabric 100 map, for example, will serve as a mapping of the devices coupled to switch fabric 100 and discovered by fabric manager 150. This mapping, for example, may include the paths (primary and/or non-primary) via which communications can be routed though switch fabric 100 between fabric manager 150 and the discovered devices coupled to switch fabric 100. The mapping, for example, may also be associated with or includes a connection table that could be used by fabric manager 150 or other switch fabric 100 management services (e.g., a topology service) to calculate communication paths between devices coupled to switch fabric 100.
At state 670, in one example, configuration feature 216 may need to initialize the device for operation on switch fabric 100. Initialization, for example, includes assigning event reporting requirements for a device to monitor and report the results of the monitoring (e.g., data traffic congestion, link or port malfunctions, etc.). Configuration feature 216, for example, may use the information maintained in the device's capability table and the switch fabric 100 map to determine if the device has the capability to monitor and report on a given event and where the memory locations for configuring that capability are stored at the device. If it has the capability, configuration feature 216, for example, relays the monitoring and reporting requirements and the associated memory locations to communicate feature 212. Communicate feature 212, for example, generates and sends a write request message in the format of message format 530 that will write the monitoring and event reporting requirements to those memory locations.
As mentioned above for
In one implementation, endpoint 116 that hosts fabric manager 150 is a primary fabric manager for switch fabric 100. Although not shown in
Referring again to memory 160 in
In the previous descriptions, for the purpose of explanation, numerous specific details were set forth in order to provide an understanding of this disclosure. It will be apparent that the disclosure can be practiced without these specific details. In other instances, structures and devices were shown in block diagram form in order to avoid obscuring the disclosure.
References to the term “responsive to” are not limited to responsiveness to only a particular feature and/or structure. A feature may also be “responsive to” an other feature and/or structure and also be located within that feature and/or structure. Additionally, the term “responsive to” may also be synonymous with other terms such as “communicatively coupled to” or “operatively coupled to,” although the term is not limited in this regard.
This application is related to commonly assigned U.S. application Ser. No. 11/173,784, filed by Victoria V. Genovker, Ward McQueen, Mo Rooholamini and Mark Sullivan on Mar. 31, 2004 and entitled “Advanced Switching Fabric Discovery Protocol.”