Abstract:
Both link-level and path-level performance monitoring is obtained in any point of a multi-link network where transmitting points in the network are adapted to transmit codes only from a subset of the codes that receiving points in the network are adapted to receive, with one of the codes that transmitting points are adapted to transmit being chosen to represent an error-reporting code, and substituting, at monitoring points, any received code that is not one of the codes in the subset with the error-reporting code. By measuring the number of received codes that are in error, a link-level error measure is obtained, and by measuring the number of error-reporting codes, a path-level measure is obtained.

Description:
BACKGROUND OF THE INVENTION 
   This invention relates to link-to-link and end-to-end transmission error monitoring and, more particularly, to such error monitoring in systems that employ coded data communication protocols. 
   SONET systems provide both link-level and path-level performance monitoring through use of a special framing technique in which data is inserted into multiple conceptual ‘containers’. There are ‘path’-level containers that are only ‘opened’ at the ends of a path, and there are ‘section’-level containers that are opened at each ‘section’. Error calculations are made independently at path and section level. Error correction is not provided. ATM transmission also contains certain capabilities for error checking that are built-into the overhead bytes of cells of the ATM system. 
   As data transmission employing Ethernet over extended distances becomes more prevalent, and such transmission is effected through paths composed of multiple links, it becomes more and more desirable to have both link-level and path-level performance monitoring at any selected point. Such monitoring permits one to locally trouble shoot paths where some links are remote and, perhaps, belong to a different entity. Unfortunately, Ethernet equipment does not provide for the desirable bit error rate (BER) monitoring on a link-by-link and end-to-end (path) basis. 
   SUMMARY OF THE INVENTION 
   An advance in the art is realized in systems that employ a coding schema that employs less than the full capacity of the code for communicating information, by providing a mechanism for both link-level and path-level performance monitoring at any point of a multi-link path. Specifically, in accord with the principles of this invention, communication of information is carried out through an arrangement wherein one of the codes that is not used for communicating information is employed as a special code (Error-Reporting code, or ER code), and that code is substituted for receptions that contain an error. 
   Illustratively, the principles of this invention are employed in a block coding arrangement, where equipment at each ingress port of each node in the multi-node network determines the number of link errors in the received signal by evaluating the incoming signal relative to the valid codes, and counting the number of data blocks that contain other than valid codes. Concurrently, the equipment replaces each such block with an ER code. The link error corresponds to the number of errors introduced by a link immediately preceding the equipment of a node, and which are replaced with ER codes. The path error, which corresponds to the number of path errors, is indicated by the sum of the ER codes that the node replaces for blocks that contain an error, plus the number of the received ER codes. 

   
     BRIEF DESCRIPTION OF THE DRAWINGS 
       FIG. 1  presents a block diagram of an error monitoring module within a network node; and 
       FIG. 2  illustrates a network with a primary and a secondary path that benefits from the principles of this invention. 
   

   DETAILED DESCRIPTION 
   The disclosed approach operates in a system with a coding schema that inherently supports a given set of available codes, but where the system employs only a subset of the available codes in the schema for communicating valid data. See, for example, Sklar, Digital Communications, 1988, ISBN 0-13-211939-0. For ease of reference, the codes within the subset are termed PUGS codes (because they are members of a Partially Used Coded Space), and the coding schema codes that are outside the subset are termed non-PUGS codes. When a receiver receives a code that is a non-PUGS code, the conclusion is reached that a transmission error occurred in the transmission of the code. Similarly, when a block of codes that contains a code that is a non-PUGS code, the conclusion is reached that a transmission error occurred in the transmission of the block. Of course, it is possible for an error to occur whereby one PUGS code is transmitted, and another PUGS code is received. Such an error cannot be detected when the error detection scheme looks only at the individual codes that are received. That suggests that the PUGS codes, each of which containing a number of bits, should be selected to have as large a Hamming distance as possible. 
   All systems that employ error detection are systems wherein the transmitter employs only PUGS codes, whereas the receiver detects all of the coding schema codes. This concept encompasses all coding schemas, including, for example, block coding schemas, convolutional coding schemas, etc. 
   In accord with the principles disclosed herein, network arrangements are enhanced by employing a selected non-PUGS code for error reporting (ER code), and allowing a transmitter to transmit the ER code. As shown below, this enhancement enables the system to provide information about both link errors and path errors. Stated in other words, in accord with the principles of this invention a network that employs a set of PUGS codes is enhanced by adding one additional code to the PUGS code set, that being the ER code. 
   To define formally, a link is the communication conduit that connects one node to another node, and a path comprises a plurality of links that form a conduit from any one selected node of the network to another selected node of the network. 
     FIG. 1  presents a block diagram of a network node that provides the desired error reporting capability by including an error-monitoring module  100  at each ingress port of the node that is coupled to an inbound link. Module  100  comprises a minimally modified conventional receiver element  10  that determines which of the coding schema has been received and, consequently, whether a PUGS code, an ER code, or some other non-PUGS code was received. It is minimally modified, illustratively, to provide output line  11  that outputs the detected superset codes, output line  12  that outputs a pulse every time a communication error is detected (that is, when the output of line  11  corresponds to neither a PUGS code nor the ER code), and output line  13  that outputs a pulse every time the output of line  11  corresponds to the ER code. Line  13  is connected to conventional up-counter  20 , line  12  is connected to conventional up-counter  30 , and line  11  is coupled to selector  40 . Thus, counter  20  counts the number of received ER codes and provides an indication of the path errors up to but not including the last link, and counter  30  counts the number of errors introduced by the last link. Selector  40  either passes to its output the codes detected by receiver  10  or, the ER code. The ER code is selected whenever control line  23  indicates that a communication error has been detected. The output signal of selector  40  is forwarded to subsequent (conventional) node elements that, in  FIG. 1 , are coalesced into element  200 . Element  200  is coupled to other incoming links of the node, through other modules  100 , and to outgoing links. 
   Controller  50  is coupled to counters  20  and  30 . At a specified rate, for example, every 15 minutes, controller  50  reads the count of counters  20  and  30  and resets the counters. The information that is thus captured is maintained in a memory that is associated with controller  50  (not shown). In addition to keeping a record of link and path errors at the preselected time intervals, controller  50  may also keep more aggregate information, for example, daily records that correspond to the sum of the error counts within a day. Controller  50 , which advantageously is a stored-program controller, is adapted to be polled by users, other nodes, or network administrators, to output the error counts that are stored in the controller&#39;s memory. Controller  50  also includes a module for analyzing the stored counts, and for outputting an alarm signal when a preselected error condition is detected by the analyzing module (e.g., when a threshold that is exceeded). Alternatively, the controller outputs a directive signal, instructing some other component, or components, to take action. 
   In some embodiments, controller  50  maintains a number of error-reporting “buckets.” For example, a quarter-hourly bucket, an hourly bucket, and a daily bucket that can be polled individually. 
   To illustrate a commercial embodiment, gigabit Ethernet carries a physical line coding known as 8b/10b code. A description of this code may be found in A. X. Widmer, P. A. Franaszek, “A dc-balanced, partitioned-block 8b/10b transmission code,”  IBM J. Res. Dev . V.27(5), 1983 pp. 440–451. Given sufficient data processing capability, a receiver can determine whether any invalid 8b/10b code has been detected. Invalid 8b/10b/codes can be assumed to arise from link transmission errors. In such a link, the above-described concept of “valid code” refers to the fundamental “word” or “byte” level of the 8b/10b code, which is a 10-bit sequence. Correlations required of sequential bytes of the code can be employed to further determine errored blocks, as described in the cited reference. Any technique suitable for isolation of error is appropriate. 
   In addition to providing a specific set of valid transmission codes (PUGS codes), the gigabit Ethernet standard for 8b/10b coding (standard IEEE 802.3-2000) provides special codes that are not permitted to arise anywhere in the transmission of valid data (non-PUGS codes). One of these codes (the ‘/V/’ code) is specified in the standard for ‘invalid’ code detection. By choosing the ‘/V/’ code to be the ER code disclosed above, means are provided to provide error reporting, fault isolation, and end-to-end path performance measurement. 
     FIG. 2  presents a block diagram of a network where the principles disclosed herein are used to an advantage. For illustrative purposes it is assumed that communication is desired from node A to node G, and that it is further desired that an alternate path should be used if the primary path between nodes A and G suffers from an error rate that is deemed too high. Thus, illustratively, the primary path in  FIG. 2  consists of links A–I (link that connects lone A to node I), I–H, and H–G, and the alternate path consists of links A–E, E–F, and F–G. 
   For sake of simplicity, it is assumed that the same links that are used for the primary/secondary path from node A to node G are used for the primary/secondary path from node G to node A. In accordance with the principles disclosed herein, therefore, node A has a module  100  that is coupled to link I–A, and a module  100  that is coupled to link A–E. Likewise, node G has a module  100  that is coupled to link H–G, and a module  100  that is coupled to link F–G. The modules  100  in node G handle the flow of traffic into node G over the primary and alternate paths, and the modules  100  in node A handle the flow of traffic into node A, also over the primary and alternate paths. Since the operations in both directions are identical, the following description focuses only on node G and the traffic that arrives from node A by going through the primary path as well as the traffic that arrives from node A by going through the secondary path. 
   Different modes of operation are possible for the  FIG. 2  arrangement. One mode, for example, runs valid data through both the primary and the secondary paths, and controller  50  in node G decides whether the behavior of the primary path is sufficiently error free to continue directing element  200  of node G to use the data provided by link H–G and to ignore the data provided by link F–G. Another mode employs the secondary path for some other—lower priority—data. When the primary path is deemed to be poor, the lower priority traffic is preempted and the traffic that flowed through the primary path is caused to flow through the secondary path. 
   To realize this capability, controller  50  in node G includes the facility to control its associated element  200  so that a given traffic flow (for example, from link F–G) is ignored, or a different traffic flow is ignored (in a system that operates according to the first mode). This is easily achieved in element  200  in a conventional manner. The decision as to which traffic flow to accept is based, in accord with the principles disclosed herein, on evaluations of the error counts in the counters in module  100  that is coupled to the primary path&#39;s inbound link H–G, and the error counts of the counters in module  100  that is coupled to the secondary path&#39;s inbound link F–G. When the primary path&#39;s error rate is higher than a preselected threshold, and the secondary path&#39;s error rate is lower than another preselected threshold, controller  50  causes the secondary path to become the primary path. Of course, alarms may be raised in such a circumstance to alert administrators of the primary path&#39;s poor error rate performance. 
   Also in accord with the principles disclosed herein, controller  50  can poll the intermediate nodes of the paths under consideration, fore example, nodes I and H, to determine where the bulk of the errors are introduced, and to take possible remedial action. To illustrate, if the report from node H reveals that link I–H is responsible for the bulk of errors along the primary path, a system administration module can be initiated so that, while the secondary path serves as a temporary primary path, a new primary path is established that bypasses link I–H; for example, establishing a path consisting of link A–I, then link I–D, and then link D–G. Also a report to the entity that is responsible for maintaining the integrity of link I–H can be sent out. 
   It is noted that the signal output of line  11  is a sequence of codes, and that it is codes that are replaced when line  12  outputs a pulse to indicate that the code is invalid. It is possible, however, to have an embodiment where the unit of information of interest is a data block that consists of a number of codes, in which case it may be desired to replace an entire data block with the ER code whenever one or more of the codes in the data block are invalid. Error determination and the precise location of the error (in the block) depend on the method employed to ascertain the error. However, when the entire block is replaced with an ER code, the location of the error is unimportant, easing the need to merely detect the error or errors. Of course, if a data block is received with two invalid codes, one must decide whether to have the link error counter ( 30 ) increase by 1 or by two, and whether to have the received ER code counter ( 20 ) increase by 1 or by two, or by some other combination. A skilled artisan would have no difficulty in implementing whatever regimen is selected. 
   The above disclosed the principles of this invention with an illustrative embodiment, but it should be realized that various modifications could be incorporated without departing from the spirit and scope of this invention. To illustrate, the above-disclosed embodiments employ error monitoring at the terminal end of each link. Indeed, because of that, the error monitoring from one monitoring point to the next monitoring point is dubbed herein as link-level monitoring. However, monitoring can be carried out at any selected connection point within the network. Accordingly, in the context of this disclosure, the term link-level refers to the communication equipment between monitoring points. To give another example, counters  20  and  30  are read by controller  50  at a preselected rate, but embodiments can be envisioned where the counters evaluate an error rate, and trigger their own reporting to controller  50 . To give still another embodiment, the circuitry within receiver element  10  that detects ER code signals at the input of element  10  and outputs corresponding pulses on line  13  can be made responsive to the output of multiplexer  40 . In such an embodiment, the count within counter  20  provides the path error count.