Patent Application
20050097196
The present invention relates in general to register insertion networks having a plurality of nodes and, more particularly, to a method for operating such networks wherein each node generates status messages that are periodically transmitted so that all other nodes in a network can determine the status of the network. Typically, a network comprises a closed ring, i.e., nodes in a closed ring are connected so that each node in the ring can receive its own messages. The status of the network, including the topology of the closed ring, can then be determined by any ring node from the status messages. The status of the network, including the topology of the closed ring, can also be determined by at least one node that is not connected into the ring but is connected to the ring to receive the status messages. Such a node will be referred to herein as a monitor node.
Register insertion networks typically utilize unique network identifications (IDs) for each node of the network. Removal of packets from the network may be performed using destination removal or source removal. Broadcast networks typically utilize source removal where the packet is removed when the incoming packet's ID matches the local node's ID. It is also common to utilize an “age” field that is modified (for example incremented or decremented) as the packet is retransmitted. When the age of a packet reaches a maximum value (or minimum value if the age field is decremented on each retransmission), the packet is removed from the network to eliminate unwanted packets referred to as “expired” packets. When source removal is used, the age field of a node's own packets received back for removal can be used to calculate the network size, i.e., if the initial age is set to 0 and the age of a node's own packets come back as X, then there are X+1 nodes in the network. Network latency can also be determined by setting a timer when a packet is sent out and then stopping the timer when the packet is received back by the source and removed from the network so that the resulting timer reading is the network latency.
While network size and latency are important for control and management of a network, they do not provide knowledge of the actual structure of the network or the status of other nodes within the network. Further, if network changes are made between times that packets are sent by a node, the information determined from previous transmissions may be inaccurate, particularly for nodes that are not very active.
Accordingly, there is a need for a method for operating a network that enables monitoring of many aspects of the network including not only size and latency but also network structure and status of nodes within the network. In one form, the network could be monitored by a node that is not within a network ring but is connected to the network ring so that monitoring can be performed in a manner that is not ring invasive.
This need is met by the invention of the present application wherein each node of a network having a plurality of nodes generates status messages including at least an identification of the node that generated the status message and a message age. These status messages are periodically transmitted by each node of the network and received at each node of the network. When received, the status messages are aged and retransmitted unless the receiving node was the source of the status message in which case it is removed from the network. Node statuses, determined from the status messages, can be used at each node to enable the determination of network size, structure or topology of the network and status of the nodes in the network to assist in monitoring and testing the network.
Other features and advantages of the invention will be apparent from the following description, the accompanying drawings and the appended claims.
Reference will now be made to the drawings wherein
Network data packets are illustrated as being transmitted around the closed ring of the network 100 in a counterclockwise direction as indicated by the arrows extending between the nodes 102-108. Data packets are formatted and transmitted in a conventional manner within the network 100 and source removal is used so that packets are removed by the nodes when an incoming packet's ID matches the local node's ID. An “age” field is included in each data packet with the age field being modified (incremented in the illustrated embodiment, although age decrementing can also be used in the present invention) as the packet is retransmitted by each node. When the age of a packet reaches a maximum value, such as 255, (or minimum value if the age field is decremented on each retransmission), the packet is removed to eliminate unwanted packets, referred to as “expired” packets, from the network 100.
A register insertion network having a plurality of nodes, such as the network 100, can be operated in accordance with the present invention by generating status messages at each node of the network 100 with the status messages each including at least an identification of its generating node (node ID) and a message age. Preferably, the status messages also include data representative of operating characteristics of the nodes that generate them. Accordingly, in addition to node ID and message age, the status messages can also include data representing the node ID of the node immediately preceding or upstream of the node that generated the message. An indication of whether or not a redundant link is available to the node can be included. The status of data transmission can be included, for example by indicating whether the laser(s) on transmission link(s) from the node are enabled or shut down and whether or not transmission from the node by a node host computer onto the network is enabled or disabled. The status of data reception can be included, for example by identification of the link being used by the node for reception, whether the node is enabled to receive data from the network, whether retransmission of incoming network data received by the node is enabled, whether the link currently being used by the node for reception is up and whether signals are being detected on reception links. Of course, any type of node control and/or status information that would be beneficial for operation of the network can be included in the status messages.
Each of the nodes 102-110 periodically transmits its status messages, for example, a status message can be transmitted from each node of the network 100 with a periodicity of about one millisecond (status messages for the monitor node 110 do not reach the closed ring of the network 100 since it is not connected into the ring). While any reasonable period can be selected for status message transmissions, the period should ensure that the status messages are received back by their originating nodes before another status message is sent.
Status messages in accordance with the present invention can be generated in a number of ways, however, the most efficient and effective way is for network logic 100L at each node to automatically transmit status messages at a fixed interval, see
These three data sources are selectively multiplexed onto the transmit data stream TDS by a multiplexer MUX. Since retransmission traffic has the highest priority, any time data is available in the RT FIFO, it will be sent out as soon as possible. A network status message timer, part of the network logic 100L, determines when to send status messages, for example, approximately every millisecond as previously noted. If there is no retransmission traffic and it is time to send a status message, the network logic takes the network status, frames it, and it is driven out on the transmit link. If there is no retransmission traffic and no network status message is to be sent, the network logic selects the TX FIFO as the data source. If there is no data in the TX FIFO, the network logic 100L sends idle patterns to the network fabric.
Accordingly, for the illustrated arrangement, transmission of the status messages is a decision made locally within the network logic 100L with the only delay possible being a waiting time for completion of an in-progress message or retransmission of data received from the network. Having the network logic generate and transmit the status messages results in a symmetric arrangement where no special node or configuration is required. In addition, the decision to transmit a status message is only based on local status, elapsed time and any necessary wait for a message in progress or retransmission traffic to be finished so that no centralized coordination of these tasks is necessary across the network.
The status messages are received at each node 102-110 of the network 100, the messages are then aged and retransmitted onto the network 100 in the same manner as other data packets traveling around the network 100 (the node 110 ages and retransmits the messages, however, since the node 110 is not connected into the ring of the network 100 or to another node, i.e., nothing is connected to the output of the node 110, the retransmitted data is effectively discarded). Received status messages can be stored at each node; however, it is currently preferred to process the status messages with resulting node statuses being stored. As will be apparent, it is also possible to utilize the status messages of the present invention in status routines that would not directly or indirectly store the status messages. The node statuses are stored at addresses corresponding to the ages of the status messages and hence the node statuses. In other words, if a status message has an age of 0, it's node status is stored in an address corresponding to an age of 0 (for sake of simplicity, herein address 0), if a status message has an age of 1, it's node status is stored in an address corresponding to an age of 1 (for sake of simplicity, herein address 1), etc.
Node statuses are stored in a lookup table (LUT) 111, 112, 114, 116, 118 in each of the nodes 102-110, respectively. Illustrative data for the node statuses is shown in
Operation of the network 100 utilizing the present invention will now be described with reference again to
When the node 104 receives the status message SM102 from the node 102, it processes it to form a node status and stores the node status in address 0 of the LUT 112 since the age of SM102 is 0. As shown in
When the node 110 receives the status message SM102 from the node 102, the node 110 processes the status message SM102 to form a node status and stores the node status in address 0 of LUT 118, since SM102 has an age of 0 when received by the node 110. As shown in
When the node 106 receives the status message SM102, the node 106 processes it to form a node status and stores the node status in address 1 of LUT 114, since SM102 has an age of 1 when received by the node 106. As shown in
When the node 108 receives the status message SM102, the node 108 processes the status message to form a node status and stores the node status in address 2 of LUT 116, since SM102 has an age of 2 when received by the node 108. As shown in
When the node 102 receives the status message SM102, the node 102 processes the status message to form a node status and stores the node status in address 3 of LUT 111, since SM102 has an age of 3 when received by the node 102. As shown in
If a node's own status message is not received back by the node within a defined time period, for example two times the periodic rate of transmission of status messages, an error is indicated and the node age is set to an illegal age, for example in a network that can have up to 255 nodes, 0-254, the age could be set to 255 (FF-hexadecimal). The node 110 never receives its status messages back from the network 100 because the node 110 is not connected into the closed ring of the network 100 so that it cannot receive its own messages. Accordingly, the node 110 sets its node age 130 to 255.
By following network operation in response to status messages generated by the nodes 104, 106 and 108 in the same manner as described above with regard to the node 102, the lookup table entries shown in
With reference to the illustrated embodiment, the node ID stored in address 0 receives data from the node ID stored in address 1 which receives data from the node ID stored in address 2 which receives data from the node ID stored in address 3, etc. Thus, from the entries in any of the lookup tables 111, 112, 114, 116 the structure or topology of the closed ring of the network 100 can be determined to be node ID 10 transmits to (→) node ID 20 which transmits to (→) node ID 30 which transmits to (→) node ID 40 which transmits to (→) node ID 10 so that the closed ring of the register insertion network 100 is configured as shown in
The network structure indicated in the lookup table 118 of the monitor node 110 indicates a partial ring with node ID 20→node ID 30→node ID 40→node ID 10 but there is no indication of closure of the ring; however, the ring can be considered to be closed by presuming that the node ID stored in address 0 transmits to the node ID stored in the highest valid address, in the present example, node ID 10 transmits to node ID 20. More specifically, the ring connection for node 110 is not closed (node age set to FF), but given the structure in the lookup table 118 of the node 110, it can be inferred that the node's 110 connection is a segment off of a closed ring of the network 100, which includes the nodes 102, 108, 106, and 104. It is again noted that a closed ring of a network consists of a complete path of the node's transmission, i.e., data transmitted from a node's transmitter is received back by its receiver. Typically this transmission is through other nodes, however, a one node closed ring can be defined by connecting a node's transmitter to its receiver.
In addition to network size and structure or topology, the status messages of the present invention enable the network to be monitored and tested. If one or more monitor nodes, like the node 110 of
Since it is not generally practical to invalidate the extraneous entries produced by reducing the size of the network automatically via hardware, when the processing node encounters a situation where the number of entries marked valid in the lookup table exceeds the current ring size, it is currently preferred to clear each of the respective entries in the lookup table. In a working embodiment, writing to lookup table entries by the node clears the contents of the table entry, including the data valid bit. After the offending entries, or the entire lookup table, has been cleared, the node waits for a time period greater than the status message update period, and rereads the lookup table. If the condition persists, a network error is indicated.
Network latency can also be automatically checked using the status messages. It is currently preferred to deploy a timer which is cleared and enabled on transmission of a local network status message. The timer value is latched on reception of a node's own network status message and presented to a register which allows the node or other network control system to determine network transmission latency around the ring for the current network loading. The timer automatically updates on reception of its own native status messages and requires no additional network traffic to determine network latency.
An example of network testing using the status messages of the present application is remote measurement of the clock frequency of each of the nodes on a network. All clocks within a network have to be within given specifications. In the past, each of the clocks of the individual nodes had to be measured to determine compliance with the clock specifications. But by repeatedly introducing a node ID error into any one of the network nodes, for example as described with regard to a node ID error relative to
Of course, by monitoring the operating characteristics of the individual nodes that are stored in the lookup tables of the individual network nodes, a wide variety of network problems can be detected. Once detected, the status messages of the present application can be used to assist in diagnostics, including locations of cable breaks, duplicate node IDs, incorrectly configured nodes, and the like. Further, problem detection can be used to direct routine maintenance of a network so that detected problems can be corrected before they create network failures. In addition, network nodes can be interconnected using switched connections so that detected network problems, even those that create network failures, can be corrected by controlling the switch connections to bypass the detected problems. Numerous other uses of the status messages of the present application will be apparent to those skilled in the art from the disclosure of the present application.
Having thus described the invention of the present application in detail and by reference to preferred embodiments thereof, it will be apparent that modifications and variations are possible without departing from the scope of the invention defined in the appended claims.
