This section identifies the components comprising a hierarchically structured MSNL internetwork, and associates with each layer of the hierarchy a set of functions which implement the management and control plane for MSNA at that layer.
We define a network entity to be an object which has one or more network interfaces. We wish to depart from the restrictive requirement that each network entity must implement the functions of the management and control planes as well as those of the user plane. We therefore define an MSNL Management Domain (MD) as a collection of one or more network entities grouped together for the purposes of management and control. Each MD implements those functions of the management and control planes which are required to ensure that the network entities in the MD can achieve their communication needs both within the domain and between management domains. Although the grouping of entities into a domain may be arbitrary, in practice a MD will probably reflect a logical group of entities, such as a switch. Within a MD the boundaries between entities are preserved - this is required because each entity is still capable of independent communication. At the MD level each entity is abstracted as a set of interfaces which provide the management and control functions access to the MSNL, MSDL and MS-Access instances in the entity. An entity exports via these interfaces information regarding its physical connectivity and capabilities, and also its status.
Each network interface (also referred to as a pod) attached to an entity is assigned an interface address which is unique in the MSNL internetwork. An entity is responsible for implementing the user plane of the MSNL protocol stack for each of its pods. Thus an entity should be able to terminate the MS-Access, MSDL, MSNL and MSSAR protocol layers in the user plane for each pod, according to its needs. In addition an entity may provide support for the external implementation of the control and management plane functions for each layer of the protocol stack. For instance at the MS-Access layer an entity may export an interface which permits the management function to detect the error rate for the pod, or measure its performance. The control and management functions for each layer of the protocol are implemented on behalf of the entity by a set of co-operating management and control services which are instantiated per MD and which interact via well defined interfaces. The definition of the interfaces exported by each entity to permit the external implementation of the management and control planes is dealt with in the sections which follow. Figure 2 illustrates a MD composed of 3 entities. Entity 0 is a Fairisle Port Controller (FPC) with an Ethernet interface. Entity 1 is an ATM camera, and entity 2 is a Fairisle Port Controller and an attached Null Port Controller. This entity has 4 interfaces.
Figure 2: An Example MSNL Management Domain
Some entities in a MD may be incapable of exporting the management and control interfaces mentioned above. An example is the ATM camera, which exports a control interface which is entity specific. Since the management and control services expect each entity to export the appropriate interfaces, however, they must be implemented for each entity within the MD, possibly by a proxy object which translates calls from the management and control services into the entity specific control protocol to achieve the management and control functions.
A MD is regarded as a single functional unit insofar as management and control are concerned. The configuration of an MD is fixed, and known when the MD is initialised. When an entity in an MD fails (crashes), then the MD is considered to have failed, and must be restarted. This restriction is motivated mostly for reasons of network consistency, but it may be possible in practice to relax it so that an MD is considered to have failed when any of its essential control and managment services fails.
To permit the definition of the terms used to describe MSNL networks, we define the type of an MSDL instance to be the type of the physical layer on which it is implemented, for example CFR, CBN or YES/MAYBE. Different physical interfaces may exist for an instance of the same type, for example ethernet interfaces could be of kinds DEQNA or LANCE, but they interface to an instance of type ETHERNET. Note that these definitions are at odds with the current Wanda definitions.
The physical layer type frequently prescribes the class of MSDL which is implemented upon it. For instance the common cell size on the CBN and CFR can most efficiently support the MSDL class MDL, whilst the YES/MAYBE type efficiently supports the class FDL. Note, however that a network of type ETHERNET could easily support several MSDL classes. Within a class, different subclasses of an MSDL instance are permitted, however we do not distinguish between them here.
For the purposes of this document we define an MSNL subnetwork as follows: A single instance of MSDL, of any type, represents a (primitive) subnetwork. A set of MSDL instances (primitive subnetworks) of the same type which are directly interconnected also comprise a subnetwork. MSDL instances are interconnected by the MDs which are attached to them. According to this definition a set of Fairisle switches linked together by point-to-point links constitute an MSNL subnetwork; similarly a CFR is an MSNL subnetwork.
Each network interface within an MSNL subnetwork is given a unique MSNL interface address. Associated with each MSNL interface address is a mask which can be applied to the address to identify the subnetwork to which the interface is attached. A MD is assigned a primary address which is the address of one of its interfaces, and its other interface addresses are known as aliases.
The point of interconnection of two MSDL instances of different types will, in general, delimit two subnetworks. Two or more interconnected subnetworks form an internetwork. The terms network and subnetwork can be used interchangeably. Administrative or logical boundaries may be imposed on the network structure. Administrative boundaries are authoritative in the sense that they can impose subnetwork boundaries which are in contrast with the rules above. As an example two CBNs with a single host MD which is a router between them could be regarded as a single subnetwork, however it may be more convenient to view them as being separate subnetworks based on their physical connectivity or for other administrative reasons.
Entity 2 in Figure 2 has interfaces onto two MSNL subnetworks. Where an administrative boundary exists between two subnetworks, the management and control functions for the network entity bridging the two subnetworks may be split between two MDs. In this case each MD will implement management and control functions for the interface(s) and associated protocol layers which lie within its administrative boundary.