low the remote management of several disparate devices. SNMP turned out to be a large and heavy protocol; therefore, it was often implemented only on a limited scale by vendors who tried to minimize the computation and memory load that was allocated purely for SNMP processing inside a network device. In conjunction with private MIBs, this often created undesirable results with SNMP compatibility between devices from different vendors. SNMP also suffered from a lack of scalability. Polling generates significant network management traffic, which only exacerbates network congestion problems by eating away useful bandwidth. To address this capacity concern, the IETF defined Remote MONitoring (RMON) as an addition to SNMP. RMON was intended to go beyond just using intelligent agents (something SNMP pioneered) and use these same agents (called probes in RMON jargon) to collect filtered data and information about a whole network segment for subsequent proactive transmission to the network manager when needed. RMON would reconstruct the data and the environment at the network management station, thereby enabling human operators to play back an incident to understand exactly what happened. The introduction of RMON drastically reduced the problems associated with polling and extended the range of information it sent back to the SNMP manager. The interested reader can find more information in William Stallings's book SNMP, SNMPv2, SNMPv3, and RMON 1 and 215 and David Perkins and Evan McGinnis's book Understanding SNMP MIBs. 16 SWITCHED LANS, FAST ETHERNET, AND FIBER-DISTRIBUTED DATA INTERFACE (FDDI) As a result of the increase in desktop computing capabilities, the proliferation of the client-server com- puting model sparked a phenomenon. LAN bandwidth was being rapidly eaten away, and local congestion became a common problem. The frustration this caused among users put pressure on ven- dors to come up with a faster LAN. The most notable of the achievements that addressed this concern was the development of 100 Mbps Etherne