sibly accompa- nied by some ad-hoc figures. A development process that is based on this way of describing a system is docu- ment-driven. It does not take much imagination to see the problems this creates for a network system designer: the facts the designer needs reside in hundreds of large documents that are far from easy to survey. In reality, the designer relies heavily on the few experts who have been engaged in standardization and early system-devel- oping phases, and must repeatingly attend seminars and courses given by them, in order to understand a network system and its evolution. Moreover, it is also practi- cally impossible to keep system documents updated since accurate tracing of requirements is very difficult. The architecture of the system therefore tends to deteriorate, its purposes get veiled in obscurity as time goes by, its evolution slows down, and the introduction of even minor improvements and service enhancements become major design projects. After being exposed for several decades to the rather intuitive and ad hoc way we describe networks and systems, I decided to write this book in an attempt to make life easier for most network designers, whether you are a manager with tech- nical background, whether you work with standardization, the architecture of implementors' solutions to standards, product design (constructing the software and hardware parts of operator networks), system testing, or whether you are an operator responsible for the configuration and maintenance of a network. Modeling as a basic principle for producing specifications turns design from being document driven to model-driven. As humans, our creative thinking is based on modeling of almost everything we can think of (e.g., an artifact or a sociological system). In the context of this book, however, the only model type that is discussed is the information model that describes the purpose, structure, and behavior of a network. Preface Today we must deal with hundreds of documents and many thousands of pages in order to und