plies that a model user can just refer the network level (or levels) to be displayed, and the modeling tool will do the rest. In order to facilitate model maintenance it is also wise to keep the network level structure of models strictly hierarchical, i.e., only allow sub relations between adjacent network levels (e.g., an SRi=1/3 should not be allowed). 5 Management and Traffic Systems Introduction The structuring principles that have been defined in previous chapters are applica- ble on every network system. When applied on a model, they result in: The separation of layer structures from node structures. The separation of control structures from connectivity structures. For control layers, the separation of layer-state machines (LSM) from layer pro- tocol machines (LPM). One separation principle is however still missing: the separation of management functions from traffic functions. No network can function without the existence of management functions that supervise its performance and manages (under control of operators) the resources (tables, devices, etc.) used by traffic-handling functions. Identifying management functions separately from the traffic functions that deliver services to users is therefore also a general modeling principle (although with many different solutions). In this chapter we deal with the management functions, their relations to traffic resources, how to model this in AMLn, and, to some extent, how existing standards deal with the problem. Two Systems2 and Two planes We define traffic system as a network system that provides network services for end-users. In previous chapters we have seen many examples of traffic systems structures, and also touched on some management functions (e.g., "layer manage- ment functions"). So far we have not mentioned the system that defines all man- agement functions for a traffic system, the management system. The number of functions of a management system often exceeds the number of functions in the traffic system that is managed. 1 Most structural featu