Patent Publication Number: US-8526821-B2

Title: Transceivers for testing networks and adapting to device changes

Description:
CROSS-REFERENCE TO RELATED APPLICATIONS 
     This application claims the benefit of U.S. Provisional Patent Application 60/882,805 filed Dec. 29, 2006, the contents of which are hereby incorporated by reference herein. This application also claims the benefit of U.S. Provisional Patent Application 60/913,158 filed May 1, 2007, the contents of which are hereby incorporated by reference herein. 
    
    
     BACKGROUND 
     Fiber-optics and optoelectronics are important aspects of modern networks at least in part since they allow for efficient, accurate and rapid transmission of optical data between various components in the network system. Optical transceiver modules (“transceivers”) are an example of devices used in networks (“network devices”). Since there are many different types of network devices, error testing each type of network device typically requires expensive equipment, and may not be easily accomplished. 
     Currently, there is no easy, relatively inexpensive, and repeatable way to test network devices to insure that they operate in accordance with their specifications. As such, a consumer using a network device, such as a serializer/deserializer (“SERDES”), a host bus adapter (“HBA”), switch, and any network device that interoperates with a transceiver, has been unable to verify the ability of the network device to handle a specific error (or specific level of error). In particular, there is no consumer device that can easily or efficiently test a network device&#39;s ability to deal with specific conditions within a network in a logical and/or repeatable manner. As a result, and since errors in a network are not always repeatable, a technician may often spend several days of random pattern testing to identify errors. 
     BRIEF SUMMARY 
     Implementations of the present invention include network devices configured to identify errors in the network with specificity, and without necessarily requiring undue experimental procedures or expensive apparatus. In addition, implementations of the present invention include network devices that can accommodate or otherwise operate with errantly operating devices for such time as sufficient until the errant network devices are replaced or modified. 
     For example, at least one transceiver in accordance with an implementation of the present invention includes a feature for introducing a predetermined, known, controlled, and/or repeatable error into the network (a “test transceiver”). The test transceivers may be any form factor, such as SFP, SFX, GBIC, XFP, XAUI, SFF, 1x9 Transceivers, 300pin Transponders, XFP Transceivers, and SFP+ Transceivers. Using the test transceiver, another network device with which the test transceiver is communicating can be monitored to identify its reaction to the introduced error. Since the introduced error from the test transceiver is known, controlled, specific and repeatable, the reaction to the introduced error by the network device can be easily determined and isolated. 
     In addition, another transceiver (a “corrective transceiver”) in accordance with an implementation of the present invention can be configured to accommodate operating errors in other transceivers on the network. In one implementation, for example, a corrective transceiver can communicate out of band with another transceiver to identify a change in operating parameters of another transceiver, such as due to error or malfunction. The corrective transceiver can identify any new operating parameters in order to sync (and ultimately continue communications) with the errant transceiver, and further report the changes and/or new operating parameters to a listening portal. 
     Accordingly, implementations of the present invention can not only identify errors with great specificity, but also accommodate operating errors with other transceivers on the network until the errant hardware are replaced or fixed. 
     This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       In order to describe the manner in which the above-recited and other advantages and features of the invention can be obtained, a more particular description of the invention briefly described above will be rendered by reference to specific embodiments thereof which are illustrated in the appended drawings. Understanding that these drawings depict only typical embodiments of the invention and are not therefore to be considered to be limiting of its scope, the invention will be described and explained with additional specificity and detail through the use of the accompanying drawings in which: 
         FIG. 1  illustrates a method for error testing a network; 
         FIG. 2  illustrates a method for error testing of a switch (or other network device) to determine if an output of a port of the switch has synced up at a determined speed; 
         FIG. 3  illustrates a method for testing a series of test transceivers with varied levels of transmission output levels to verify that a switch is monitoring transceiver output level satisfactorily; 
         FIG. 4  illustrates a flowchart regarding what occurs inside an embodiment of a test transceiver in at least one implementation; 
         FIG. 5  illustrates a method for using a test transceiver to check if a network device is actually checking information sent to the network device by a transceiver; 
         FIG. 6  illustrates another method for introducing an error into a network; 
         FIG. 7  illustrates a method for introducing one or more errors into a network to error test network devices within the network; 
         FIG. 8  illustrates a method for using a calibrated set of test transceivers that degrade a received signal a specified amount to verify that a network device notes such degradation type of error; 
         FIG. 9  illustrates a perspective view of a test transceiver for use in error testing a network; and 
         FIG. 10  illustrates a schematic diagram in which a test transceiver and a corrective transceiver are used in a network setting with a plurality of other network devices. 
     
    
    
     DETAILED DESCRIPTION 
     Implementations of the present invention extend to network devices configured to identify errors in the network with specificity, and without necessarily requiring undue experimental procedures or expensive apparatus. In addition, implementations of the present invention include network devices that can accommodate or otherwise operate with errantly operating devices for such time as sufficient until the errant network devices are replaced or modified. 
     For example, at least one transceiver in accordance with an implementation of the present invention includes a feature for introducing a predetermined, known, controlled, and/or repeatable error into the network (a “test transceiver”). The test transceivers may be any form factor, such as SFP, SFX, GBIC, XFP, XAUI, SFF, 1x9 Transceivers, 300pin Transponders, XFP Transceivers, and SFP+Transceivers. Using the test transceiver, another network device with which the test transceiver is communicating can be monitored to identify its reaction to the introduced error. Since the introduced error from the test transceiver is known, controlled, specific and repeatable, the reaction to the introduced error by the network device can be easily determined and isolated. 
     In addition, another transceiver (a “corrective transceiver”) in accordance with an implementation of the present invention can be configured to accommodate operating errors in other transceivers on the network. In one implementation, for example, a corrective transceiver can communicate out of band with another transceiver to identify a change in operating parameters of another transceiver, such as due to error or malfunction. The corrective transceiver can identify any new operating parameters in order to sync (and ultimately continue communications) with the errant transceiver, and further report the changes and/or new operating parameters to a listening portal. 
     In general, one will appreciate that virtually any function of a conventional transceiver can be varied in a test transceiver to introduce an error into a network, including any function disclosed in any multi-source agreement (“MSA”). For example, examples of MSAs that disclose various functions of transceivers that can be varied to create test transceivers include: (1) the “10 Gigabit Small Form Factor Pluggable Module,” XFP MSA Rev.3.1, April 2003, (2) the “Gigabit Interface Converter” MSA Rev. 5.4, Aug. 16, 1999, (3) the “Diagnostic Monitoring Interface for Optical Xcvrs,” SFF-8472, MSA Rev 9.3, Aug. 1, 2002, (4) the “Small Form Factor Transceiver Multisource Agreement,” MSA Jul. 5, 2000, (5) the “Small Form Factor Transceiver Multisource Agreement,” MSA Sep. 14, 2000, and (6) the “DWDM Pluggable Transceiver MSA,” May 30, 2003. 
     The content of each of the above-mentioned MSAs is hereby incorporated by reference herein in their entirety. Other MSAs further disclose additional functions that may be varied in test transceivers according to the embodiments disclosed herein, and can be included for purposes of illustrating various embodiments of the test transceivers. The test transceivers may be varied in the form of changes to components, hardware, software, programming, mechanical variance or other changes to a conventional transceiver thereby resulting in a test transceiver that is configured to introduce an error into a network. 
     Examples of the functions of the test transceivers that may be used to introduce errors into a network include control functions, monitoring functions, transmit fault conditions, loss of signal fault conditions, optical signal functions, interoperability functions, mechanical function, electrical functions, data fields, and hardware of the test transceiver. Additional functions of the test transceivers that can be used to introduce errors include control of the test transceiver, identifier values, connector values, transceiver codes, encoding codes, checksum values, error/status bytes, a command structure, a module busy function, a transmitted data parameter, and generation of corrupt or false information. 
     Furthermore, a tester can modify in the test transceivers a function associated with an eye profile, an eye mask parameter, a threshold, a sensitivity, a parameter of a transmitted signal, a parameter of a received signal, an operating rate, a rise time, an output fall time, a bus frequency, a transmit disable function, a bandwidth function, and a transmit alarm function. For example, the tester can send a function control signal to the test transceiver via a contact or other interface to modify the function. Still further, a tester can modify a receive loss alarm function, a module sense function, a module enable function, a digital diagnostic function, an error in a command set, a temperature monitoring function, a temperature control function, a current monitoring function, and a current supply function. Yet still further, a tester can modify a power monitoring function, an alarm, a flag, warning, trip point, an attenuation, a power consumption, a function related to generation of electromagnetic energy, a function related to protection from electromagnetic energy, mechanical interoperability, or electrical interoperability. 
     Such test transceivers may allow anyone to test SERDES, HBAs, switches, or any network device (e.g., a transceiver) that has a required response to the data carried by the test transceivers, and any network device that uses a test transceiver for its response, to specific errors under perfect conditions other than that particular error introduced by the test transceiver. As such, these test transceivers allow a new point of network testing where a tester that is troubleshooting a network may simply introduce such transceiver(s) into the network, and monitor how other network devices react. 
     This can thus enable the tester to identify which network devices do not perform to their specifications. For example, a network device may be designed to react in a fail-safe manner (or simply fail) when an error (or level of error) is introduced into the network by another network device. Moreover, a network device may be designed to indicate that an error, or a particular error, was encountered when such error exists within the network. The network device may react to the error introduced by the test transceiver according to the network device&#39;s specification by providing information indicating that the error was encountered, and performing in a manner consistent with the network device&#39;s specification, or within a tolerance of a desired performance parameter. The network device may also react according to a specification or industry standard, or otherwise react as intended. 
     If the network device being monitored during introduction of a network error by a test transceiver does not react as intended, the network device can be identified. In addition, subsequent measures can be taken to insure that the network device, or similar network devices, react as intended in the future. For example, the particular network device that did not react as intended can be returned to a manufacturer of the particular network device for further analysis, or can be otherwise discarded. 
     Referring now to the figures,  FIG. 1  illustrates a method for error testing a network. According to this embodiment, a network is error tested to see if a SERDES (or other network device) can handle an eye profile generated by a test transceiver in the manner that the specification of the SERDES specifies. Testing the SERDES, according to one embodiment of the invention, can include obtaining a set of specially programmed test transceivers that are programmed in steps with varying eye diameters ( 100 ). The method can also include connecting an output of the SERDES to a monitoring device ( 105 ). 
     The method further includes connecting a first of the series of transceivers having the best eye diameter that is least likely to cause failure is connected to the SERDES ( 100 ). The method further includes monitoring the SERDES to determine if the output of the SERDES is operating satisfactorily ( 115 ). If the output signal of the SERDES is satisfactory, the method includes replacing the transceiver with the next transceiver in the series of transceivers, where the next transceiver has a different eye diagram parameter ( 120 ). For example, the eye diagram parameter can be a narrower eye diagram, a different power level (amplitude), a different modulation (phase), a different rise time/fall time (polarization response as a function of frequency, and/or different pre-emphasis of the signal creating the eye diagram. Thus, while the eye diagram may appear the same on a scope, the eye diagram may have different eye diagram parameters. The method further includes again monitoring the SERDES to determine if the output of the SERDES is operating satisfactorily. 
     The tests are repeated by systematically introducing test transceivers into the network one at a time each subsequent transceiver producing an eye that is more likely to cause the SERDES to fail until the output of the SERDES is not operating satisfactory. If the SERDES does not operate satisfactorily an eye deviation that the SERDES cannot tolerate is known from the last test transceiver connected to the SERDES ( 125 ). Similarly, an approximate worst-case eye deviation that the SERDES can tolerate is known from the next-to-last test transceiver connected to the SERDES. 
     For example, where the test transceiver connected to the SERDES when the SERDES fails has been calibrated at the factory such that the exact parameters are known, the settings of the test transceiver and specific errors introduced thereby may be printed on a label, or on a certification, that is provided along with the test transceiver. Similarly, the settings of the next-to-last test transceiver and specific errors introduced thereby can be printed on the next-to-last test transceiver&#39;s label, or on a certification, provided with the next-to-last test transceiver. Thus, the eye deviation what the SERDES can (and cannot) handle will be known from the information provided with the test transceivers. Therefore, according to this example, the result received from the test transceiver in use when the SERDES failed can be compared to a specification of the SERDES to determine if the SERDES is reacting to the error (i.e., the eye profile of the test transceiver) as expected (i.e., according to a specification of the SERDES in this example). 
     A single test transceiver may also be used where the single test transceiver is reprogrammed to provide various levels of eye diameter and different eye diagram parameters. Thus, the method can include an act of reprogramming the test transceiver outside of the factory in place of the act replacing the test transceiver with a next transceiver ( 120 ). In this example, the test transceiver can be analyzed to determine the eye deviation and eye parameters the SERDES can handle. 
     According to another example illustrated in  FIG. 2 , error testing of a switch (or other network device) may be conducted to determine if an output of a port of the switch has synced up at a determined speed. According to this example, a test transceiver sends information to the fabric layer switch introducing an error into a network. In this example, the information indicates to the switch that the test transceiver can handle a faster data rate than the test transceiver can actually handle ( 200 ). For example, a test transceiver that can only operate at one gigabits per second (“gbps”) is inserted that reports that it can sync at one, two and four gbps with a switch that can handle four gbps traffic. The test transceiver plugs into the switch using its method of communication, (e.g., as defined in the type of transceiver&#39;s MSA) and is thus connected electrically with the data paths to its registers, and further obtains power from the switch. The test transceiver, when asked for the its digital diagnostics or its operational parameters informs the switch that the test transceiver can handle 1, 2, and 4 gbps. One test setup includes sending 4 gbps data to the port that the test transceiver is plugged into causing an auto speed sense switch to set the port to 4 gbps. The switch can also be manually set to put the port to 4 gbps. It can be verified that the switch obtained the identification information from the test transceiver that the test transceiver is configured to handle four gbps by verifying that the switch allows the port to be configured to 4 gbps. 
     In addition, traffic is sent to the test transceiver at the faster data rate reported by the test transceiver ( 205 ). For example, by sending traffic through the test transceiver either by mapping the test transceiver to a port with four gbps traffic or sending four gbps to the test transceiver. The switch is monitored to determine if the switch reports that the port connected to the test transceiver has lost synchronization ( 210 ). If the switch does not report that the port connected to the test transceiver has lost synchronization the switch may be considered to operate unsatisfactorily. If the switch does report that the port connected to the test transceiver has lost synchronization, the switch may be considered to operate satisfactorily. 
     In some embodiments, a second rate of traffic may be sent to the test transceiver either by mapping the test transceiver to a port associated with traffic at the second rate (e.g., a lower rate) of traffic. For example, the second rate of traffic may have a rate of 2 gbps, which is slower then the previously sent 4 gbps rate of traffic sent. The switch may again be monitored to determine if the switch reports that the port coupled to the test transceiver has lost synchronization. If the switch indicates that the port coupled to the test transceiver has lost synchronization the switch is operating according to its specification. If the switch does not report a loss of synchronization at the port coupled to the test transceiver the switch fails. 
     According to another example illustrated in  FIG. 3 , a series of test transceivers with varied levels of transmission output levels are used to verify that a switch is monitoring transceiver output level satisfactorily. For example, a first test transceiver having a first level of optical output is coupled to the switch ( 300 ). The switch is monitored to see if the switch sets an alarm indicating that the output is less than a predetermined level ( 305 ). If the switch indicates that the output level is less than a predetermined level, the test transceiver is checked to see at what output level (or drop in output level) the switch identified the error ( 310 ). If the transceiver has been calibrated at the factory, the exact parameters are known, for example, from a label or certification that comes with the test transceiver. Thus, the drop in output level that resulted in an error is known. On the other hand, if the switch does not indicate an error, the test transceiver is replaced with another test transceiver having a level of output that is lower than the level of output of the previous test transceiver ( 315 ). 
     The switch is again monitored to check if the switch indicates that the output is less than a predetermined level ( 305 ). If the switch returns an error, the test transceiver is checked to see at what output level the switch is identifying an error ( 310 ). If the switch does not return an error, the test transceiver is again replaced with a test transceiver having a level of output that is lower than the level of output of the previous test transceiver ( 315 ) and so forth until the switch indicates that the output is less than the predetermined level ( 310 ). 
     If a transceiver is used that produces a zero level of output (and the switch does not indicate an error), it is verified that the switch is not verifying an output level from the transceiver at all. If the switch does not identify an output level according to its specification, then the switch can be identified as not conforming to the switch&#39;s specification. The same set of tests can also be conducted using a single test transceiver that is reprogrammed to produce an output having various levels of power thereby introducing the various levels of error into the network. In each example disclosed herein where a series of transceivers are used, it should be appreciated that a single transceiver can be used and reprogrammed to introduce the series of errors in place of the series of transceivers. 
     A major difference between a series of transceivers and one programmable transceiver is that the series of transceivers can be calibrated at the factory and their exact parameters known. Due to the nature of the hardware, a programmable transceiver will typically be slightly different each time it is set to the same parameters. This means that the programmable transceiver may need to be measured when the failure occurs to get an exact point reference of the failure point. However, as technology improves this difference may not apply and the programmable test transceiver can be as consistent in reproducing the error as the calibrated set of transceivers. 
       FIG. 4  illustrates a flow diagram showing what can occur inside an embodiment of a test transceiver. For example, a configuration inside the test transceiver is set so that the test transceiver is configured to introduce a predetermined error into a network ( 400 ). The configuration within the test transceiver can be changed by changing a configuration bit within the test transceiver from a 0 to a 1 or vice versa. A change in a configuration setting can also include changing a configuration register value within the test transceiver from a ‘valid’ value to a ‘non-valid’ value. These configuration registers or bits would either: (i) provide false data about the module, and/or, alternatively, (ii) the change in configuration setting can cause the module to function differently. 
     Examples of the former include identifying false information to a network device (such as a host coupled to the test transceiver). For example, the false information may indicate that the transceiver operates differently than it actual operates. Changing this configuration setting may not change the function of the test transceiver from when the test transceiver is manufactured, but rather, include a change in software or hardware. As such, additional tooling and/or manufacturing steps may not be required. 
     In any event, the test transceiver is then operated within the network so that an error is introduced into the network by the test transceiver ( 405 ). The test transceiver may be operated within the network by transferring data or information to another network device according to any of the functions discussed in the MSAs above, wherein the operation of the test transceiver introduces at least one error into the network. For example, the test transceiver can transmit a signal to a switch or an HBA type of network device. A network device operating in the network is monitored to determine if the network device identifies the error ( 410 ). If the network device performs as intended (e.g., identifying the error), the network device passes. If the network device does not perform as intended (e.g., not identifying the error), the network device fails. 
       FIG. 5  illustrates yet another example in which a test transceiver can be used to check if a network device is actually checking information sent to the network device by a transceiver. For example, a checksum value stored within a test transceiver can be changed, thereby configuring the test transceiver to introduce an error into a network ( 500 ). The altered checksum may be specified in an MSA (such as those incorporated herein, as well as others) and indicates that some data has changed. This checksum does not change the operation of the test transceiver in this embodiment; however, a network device (such as a host device coupled to the test transceiver) can read the altered checksum. 
     The network device communicating with the transceiver is monitored to determine if the network device reacts as intended (e.g., according to a specification or industry requirement) ( 505 ). If the network device does not operate as intended, the network device may be further analyzed (or returned to the manufacturer of the network device) to determine why the network device did not operate as expected. For example, where the checksum value has been changed an HBA should report that the checksum value of the test transceiver is bad. 
       FIG. 6  illustrates a method for introducing an error into a network. For example, a network device queries a test transceiver ( 600 ). The test transceiver is introduced into a network that includes the network device (such as a host coupled to the test transceiver). The network device receives a response from a test transceiver that includes an error, such as data falsely identifying the test transceiver ( 605 ). The network device then verifies the data (if the network device is capable) or the network device attempts to operate using that data provided by the test transceiver ( 610 ). In addition, the network device is monitored ( 615 ). If the network device reacts (e.g., operates or identifies the error) as expected, then the network device passes the requirements of the network device&#39;s specification. If the network device reacts (e.g., operates or fails to identify the error) different than expected, then the network device fails the requirements of the network devices specification. 
     According to another example, a test transceiver is configured not to communicate to the host via a serial interface. According to another example, a laser of a test transceiver is configured not to operate. According to another example, laser operating conditions are configured to have poor mask, margin, jitter, extinction ratio, average power, and/or receive amplitude that introduce an error into a network. In each of these examples, an error is introduced into a network by operating the test transceiver within the network and monitoring at least one network device within the network. 
       FIG. 7  illustrates another method for introducing one or more errors into a network to error test network devices within the network. For example, step  700  shows that, within a test transceiver, firmware indicates to the microcontroller to alter one or more laser operation configurations. A microcontroller causes the laser to be operated in a faulty or marginal manner, thereby introducing an error into a network ( 705 ). A network device then attempts to operate under the error introduced by the test transceiver ( 710 ) (e.g., a marginal or faulty condition of the test transceiver). The network device is monitored ( 715 ). If the network device reacts (e.g., operates as expected in accordance with a specification or industry parameter), then the network device is considered to be in accordance with its specification. If the network device does not react as expected, then the network device is considered not to be in accordance with its specification. 
     Changes in a test transceiver can be changes in a conventional transceiver. For example, the changes can be entirely new and different firmware (or microcode) designed to operate in a specific way. These changes can be configured so that the conventional transceiver introduces a predetermined error into a network, and thereby operates according to any of the embodiments disclosed herein. In particular, any standardized operating parameter of a conventional transceiver can be altered to create a test transceiver that is subsequently used to introduce errors into a network to test devices of the network. 
       FIG. 8  illustrates a method for using a calibrated set of test transceivers configured to degrade a received signal a specified amount in order to verify that a network device notes such degradation type of error. For example, a first test transceiver is coupled to the network device having a first minimal level of receive degradation ( 800 ). The network device is monitored to determine whether the network device identifies the receive degradation ( 805 ). If the network device identifies the receive degradation according to its specification the network device passes the test ( 810 ). 
     If the network device does not identify the received degraded receive signal, a second test transceiver is inserted that increases the level of signal receive degradation type of error ( 815 ). The network device is again monitored to see if the network device identifies the degraded receive signal ( 805 ), and so on. Once the network device identifies the degraded receive signal ( 810 ), the test transceiver is checked to determine at what level the network device reported the error. It should be noted that a single test transceiver can be used and reprogrammed to introduce the different levels of signal degradation. 
     According to any of the tests disclosed herein, the level of error introduced into the network can be gradually increased (and/or gradually decreased) in order to determine a point at which the error is discovered by the network device, or to discover a point at which the network device no longer performs according to the network device&#39;s specification. 
       FIG. 9  depicts a perspective view of a test transceiver, generally designated at  900 , for use in error testing a network. As depicted, the test transceiver  900  includes various components, including an optical receiver implemented as a receiver optical subassembly (“ROSA”)  910 , an optical transmitter implemented as a transmitter optical subassembly (“TOSA”)  920 , electrical interfaces  930 , various electronic components  940 , and a printed circuit board  950 . 
     In detail, two electrical interfaces  930  are included in the test transceiver  900 , one each used to electrically connect the ROSA  910  and the TOSA  920  to a plurality of conductive pads located on the PCB  950 . The electronic components  940  are also operably attached to the PCB  950 . An edge connector  960  is located on an end of the PCB  950  to enable the test transceiver  900  to electrically interface with a host (not shown here). As such, the PCB  950  facilitates electrical communication between the ROSA  910 /TOSA  920 , and the host. In addition, the above-mentioned components of the test transceiver  900  are partially housed within a housing portion  970 . Though not shown, a shell can cooperate with the housing portion  970  to define a covering for the components of the test transceiver  900 . 
     The test transceiver  900  is configured to introduce an error into a network. The test transceiver can include a component (or lack of component), firmware, software or other executable means for introducing an error in to a network in which the test transceiver operates. Any other network device in the network in which the test transceiver  900  operates can be monitored in order to determine how the network device reacts when the network device encounters the error introduced by the test transceiver  900 . 
     Examples of the functions of the test transceiver  900  that may be used to introduce errors into a network include, as previously described, control functions, monitoring functions, transmit fault conditions, loss of signal fault conditions, optical functions, interoperability functions, mechanical function, electrical function, or a data field. In addition, components that can be modified to introduce an error also include hardware of the test transceiver, control of the test transceiver, an identifier value, a connector value, a transceiver code, and encoding code, an optional value, a date code, a data field, a checksum value, an error/status byte, a command structure, a module busy function, or an a transmitted data parameter. 
     Furthermore, a tester can (in the test transceiver) corrupt information, modify a function associated with an eye profile, an eye mask parameter, a threshold, a sensitivity, a parameter of a transmitted signal, a parameter of a received signal, an operating rate, a rise time, an output fall time, or a bus frequency. Still further, the tester can modify (in the test transceiver) a transmit disable function, a bandwidth function, a transmit alarm function, a receive loss alarm function, a module sense function, a module enable function, a digital diagnostic function, an error in a command set, a temperature monitoring or supply function, or a current monitoring or supply function. Yet still further, the tester can modify a power monitoring function, an alarm, a flag, a warning, a trip point, an attenuation, a power consumption, an function related to generation of electromagnetic energy or protection from electromagnetic energy, and mechanical or electrical interoperability. 
     While  FIG. 9  illustrates a particular type and form factor of transceiver it is appreciated that the teachings herein are applicable to any network device. For example, any network device may be configured to introduce an error into a network to error test other network devices within the network, including, for example transceivers in the form of SFP, SFX, GBIC, XFP, XAUI, SFF, 1x9 Transceivers, 300pin Transponders, XFP Transceivers, and SFP+Transceivers, or the like. Such transceivers as those listed can be particularly advantageous for error testing networks, at least for the reason that they may include controllers, active devices, and various functions that have a wide range of ability to introduce errors into a network. 
     In addition to the foregoing, implementations of the present invention can also include one or more transceivers configured to accommodate (or adjust to) known errors on the network due to another transceiver that is functioning in an unexpected or errant manner. In particular, implementations of the present invention can include a “corrective transceiver,” which is in communication with one or more other transceivers in a network using both in-band and out-of-band communications. Specifically, the corrective transceiver can be configured at least in part to communicate out-of-band with one or more other transceivers on a communication network (e.g., fiber optic network, or the like) to identify, for example, the operating metrics of other network devices (over the network connection between them), such as due to error, malfunction, or simply a loss in transmission power due to aging. Identifying such information can allow the corrective transceiver to adjust its own operating parameters (much like a test transceiver) pursuant to re-syncing, and also to push various reporting information to a listening portal. 
     For example,  FIG. 10  illustrates a schematic diagram in which a test transceiver and a corrective transceiver are used in a network setting with a plurality of other network devices. As shown, one implementation of a network can include a plurality of different network devices, such as test transceiver  900 , corrective transceiver  903 , and network devices  907   a  and  907   b . Each of these devices can be communicating with each other in one form or another, such as shown with “general communication”  980   a ,  980   b , and  980   c  (e.g., general send/receive messages). In general, the general communication messages comprise communication that occurs between devices that are appropriately synchronized with respect to power and speed settings. 
     In addition to the foregoing, however,  FIG. 10  shows that corrective transceiver  903  initiates one or more out-of-band communications, such as shown in the dotted lines with communication  985 . Corrective transceiver  903  can establish this communication  985  without necessarily requiring stringent power and speed settings, which are typically required with conventional communication between two different network devices. This out-of-band communication allows corrective transceiver  903  to periodically ascertain any changes in the communication patterns of a given network device. For example, corrective transceiver  903  can use the out-of-band communication channel to identify that network device  907   a  is operating at reduced power or speed/throughput settings (e.g., due to some device malfunction, failure, or simply due to aging), or that network device  907   a  has paused momentarily during communication. 
     Upon detecting any change to network device  907   a , corrective transceiver  903  can perform one or more settings queries via communication  985  with network device  907   a . In one implementation, communication  985  allows corrective transceiver  903  to determine with precision, for example, such critical information as the network device&#39;s transmission power and speed/throughput settings (or other relevant operational metrics) in network device  907   a . In response, corrective transceiver  903 , can adjust its own settings in order to sync with network device  907   a  under the new settings for the network device. Furthermore, corrective transceiver  903  can instruct other network devices that might be communicating with a changed (or modified, errant, or malfunctioning) network device  907   a  to meet the newer, detected settings. For example, corrective transceiver  903  can also send instructions to one or more other network devices (e.g.,  900 ,  907   b ) to adjust their respective operating parameters pursuant to syncing with network device  907   a.    
     Upon detecting a drop in receive power, the corrective transceiver can query the transceiver that is upstream from it (sending to it) to see if this transceiver is sending at reduced power, or if the cabling between them has developed a problem. The problem could be, for example, that someone stepped on the cable and shattered the glass therein, or that someone plugged and unplugged a cable without cleaning it (where dirt caused a power drop). Alternatively, the problem could be a bend in the cable that was tightened, and the angle of the bend is now causing a power loss. The two transceivers can thus coordinate how much the upstream transceiver can update its parameters (e.g., increase its power) as a temporary solution until the problem can be fixed. Then the downstream transceiver (e.g., corrective transceiver) can push the error to the listening portal (e.g.,  995 ) for analysis. In at least one implementation, all corrective transceivers can pass or push a message (e.g.,  990 ) along the optical fiber to ensure that the message eventually arrives at an appropriate listening portal (e.g.,  995 ). 
     In particular, and in addition to adjusting its own parameters or the parameters of other network devices, corrective transceiver  903  can continually pass this various operational information (e.g.,  990 ), or other general information it detects about network devices, to a listening portal  995 . For example, corrective transceiver  903  can send (generally via push mechanisms) one or more reports to listening portal  995  that network device  907   a  paused in operation, or that network device  907   a  or test transceiver  900  are operating at less (or greater) than expected operating parameters. 
     In at least one implementation, corrective transceiver  903  pushes this reporting information  990  to listening portal  995  over one or more wireless communication links. Similarly, any corrective transceiver  903  can also communicate out-of-band communication with any other network device (e.g.,  907   a - b ), and can further communicate over wireless communication links. For example, corrective transceiver  903  can include (or be included with) one or more wireless transceiver modules. In one implementation, the corrective transceiver  903  can communicate in-band or out-of-band with any other network device (e.g., transceiver) through optical communication, and can further communicate wirelessly with one or more other network devices, including the listening portal  995 . 
     In any event, a tester (e.g., user/operator, or monitoring system) that is monitoring the listening portal  995 , in turn, can take a number of actions upon receiving reporting information  990 . For example, the tester might tell corrective transceiver  903  to ignore unexpected results found in test transceiver  900 , since test transceiver  900  may be purposefully manipulating its communications as described herein for testing purposes. Alternatively, the tester might be able to quickly identify from the report  990  that network device  907   a  may be malfunctioning, but that network communication is continuing due to the accommodations or corrective changes implemented by corrective transceiver  903 . 
     Thus, the tester may recognize from information  990  that the network device  907   a  may need to be replaced soon, and that network traffic will be operating at a sub-optimum level in the meantime due to the errant or sub-optimum network device. Similarly, the tester may be able to notice from reporting information  990  that there has been an intrusion in the network. For example, the tester may deduce from a reported pause in communications with network device  907   a  that the pause may be the result of a malicious party installing a “listener” or some other form of patch on network device  907   a . Alternatively, the tester might identify that the change in operational parameters or perceived errors are due entirely to actions by test transceiver  900 , and thus can instruct corrective transceiver  903  to ignore settings from test transceiver  900 . 
     Accordingly, a tester may desire to employ a number of different corrective transceivers  903  in addition to any number of different test transceivers  900  for a variety of ends. For example, a tester could employ any number of different test transceivers  900  configured to push out information that the test transceiver finds out about other network devices. In one implementation, the test transceiver can use discovered information to request that the other network devices tweak their transmit power, so the test transceiver  900  can set up a fail point to be another (corrective or test) transceiver on the network. 
     Along these lines, the test transceiver  900  can be configured to turn a corrective transceiver  903  into another form of test transceiver that is operating at sub-optimal levels, and still pushing data to listening portal  995 . In addition, test transceiver  900  can be configured to ignore settings queries from corrective transceiver, or to ignore synchronization requests from corrective transceiver  903 , such as by sending one or more cease and desist signals to corrective transceiver  903 . In many cases, therefore, what constitutes a test transceiver  900  or a corrective transceiver  903  may be blurred in some cases where both may be adjusting their operating parameters, albeit primarily for different purposes. In any event, since at least corrective transceiver  903  is continually pushing reporting data  990  to a listening portal  995  regarding its out-of-band network communications, a tester can always determine if the reported actions and messages should raise any concern. 
     As such, one will appreciate that corrective transceiver  903  and test transceiver  900  can be used to provide a variety of metrics about physical layer communications, which were either impractical or impossible to deduce using prior art mechanisms and components without undue costs. 
     The present invention may be embodied in other specific forms without departing from its spirit or essential characteristics. The described embodiments are to be considered in all respects only as illustrative and not restrictive. The scope of the invention is, therefore, indicated by the appended claims rather than by the foregoing description. All changes which come within the meaning and range of equivalency of the claims are to be embraced within their scope.