software that can control many individual network elements (usually in the range 10-1000), but it can only control them as individual elements and does not have any view of the traffic relationships between them. Normally it is located remotely from the elements it is controlling, and more often than not, it runs on some form of workstation. The interface between the element manager and the network elements is an obvious area for standardization because without this there is little chance of a single element manager controlling network elements from more than one manufacturer. Despite the progress that has been made in rigorously describing the network element atomic functions, it has still proved very difficult to agree on a software description of them. The approach adopted by ITU-T, ANSI, and ETSI has been to describe complete network elements as collections of "objects" in line with the rules of "object-oriented" programming. The idea is that an object is a software entity that has both attributes and behavior. External stimuli (i.e., information, commands, etc.) trigger an object to behave in a certain way-for example, change its attributes, transmit information, obey commands, and SO on. The claim is that a standardized object could be looked on as the software equivalent of a hardware integrated circuit. One of the biggest areas of disagreement in generating an agreed on standard set of SDH objects is the question of whether an object should represent Control and Management a piece of functionality or a (small) piece of hardware. Although ITU-T G.783 functionally decomposes SDH equipment, its says almost nothing about the way such atomic functions are split or combined in any real hardware implementation. The current view within both ITU-T and ETSI is that the set of objects (collectively known as the information model) should present both a functional and a physical view of the network element that they represent. This view is given in ITU-T G.774, a very large recommendation that describes not only the i