erstand a system. My firm belief is that we would all vastly benefit if standards and implementors' solutions to standards were expressed as models instead. The potential benefits of a model-driven development process are enor- mous, in particular if models are created in the early phases, preferably already in the standardization phase: instead of interpreting documents, an implementor can build a model of his solution to standards by refining the standard model (using the same modeling technique). The potential for requirement tracing, shorter time-to- market, and many other benefits should be obvious to everybody. I guess that you already know a lot of today's networks (or at least some aspects of them), SO I am not trying to teach you anything about them Once you have read this book, you will find that now you are also the expert on modeling, at least as network modeling is concerned. You will then be the one who defines the require- ments on the languages and tools you badly need, instead of being told what to use (by software system modeling experts). When modeling has become the general method in your work, you will also experience the satisfaction of being a system expert yourself. The basic prerequisite for being able to enter the model driven path for network system development is a suitable modeling language, which is the subject of this book and my contribution in this respect. There is only one thing I must ask from you: you have to understand what modeling in general, and network modeling in specific, is about. Until now you have trusted and relied on (software) modeling specialists to provide the design languages and tools you use in your daily design work. This is just too much to ask. These specialist know how to design languages in general and they can design the most sophisticated tools for you. But you cannot expect from them specialist knowledge in your particular knowledge domain (i.e., networking). This is the reason that all you have been receiving are languages and tools for hardware and 