- Email: [email protected]
MAX: advanced network management capabilities in a standard MAN system
MAX: advanced network management capabilities in a standard MAN system G Carabellb, L Gavi and R Vercelli
set of relevant programmes. In particular, within the framework of the ESPRIT and RACE Programmes, a number of projects are currently related to MANs. Among such projects MAX (Metropolitan Area Network Communication System) has played a fundamental role, identifying a standard-compliant system which is now being developed in two follow-up projects. As described in this paper, the MAX system has been conceived taking advantage of most advanced technological and engineering solutions, but also bearing in mind the features required for a commercial system. Actually, MAX is expected to impact the MAN European market in the years to come.
This paper aims to provide an overview on the characteristics of the MAX system, focusing on aspects concerning network management. MAX is a MAN system conceived in the framework of the ESPRIT Programme. promoted by the Commission of European Communities to support European R&D activities in the IT area. MAX implements the solutions defined by the European Telecommunication Standard Institute, relevant standards on MANs. and is able to provide integration of services and very high speeds. The management capabilities envisaged for MAX are based on the ETSI MAN management documents, and are compliant with the CCITT TMN Reference Model. An object-oriented approach has been followed within MAX to develop the management software, ensuring modularity and portability. Different management areas have been covered including aspects related to Customer Network Management. i.e. the possibility for customers to interact with the MAN management system.
MAX A N D R E L A T E D E S P R I T P R O J E C T S
Keywords: MAN management, MAX, customer network management, O-O software
MANs are today considered as the first solution able to offer broadband communication capabilities to users in Europe. Therefore deployment of MAN systems is underway in several European countries based on equipment provided by different manufacturers and commercial services that will be soon available. To ensure flexibility and interoperability a standardization activity was started in Europe early on within the European Telecommunication Standard Institute. Such an activity has resulted in a number of standard documents which are to represent the reference point leading the installation of MAN systems all across Europe I. Additionally, the Commission of the European Communities has been promoting the introduction of broadband facilities for some years (IBCN) through a SIRTI SpA. Network Technologies Division, Via Vlda 19, 1-20127, Milan, Italy
The MAX project started in 1989, and finished in 1991 within the framework of the ESPRIT II Programme. The main goal of MAX was to design and specify the architecture of a complete system to operate in metropolitan areas, and to provide very high speeds and integration of services. Subsequently, a development phase started based on the adoption of innovative system solutions and the exploitation of new switching and transmission techniques. Given the excellent results achieved in MAX, two other projects have been conceived to complete, refine and integrate the system development: MAXI and MANTIS. MAXI (Metropolitan Area Communication System Integration) is an ESPRIT II project (started in 1992 and to end by 1994) specifically devoted to the completion of work according to the original plans identified in MAX. MANTIS (Metropolitan Area NeTwork for Integrated Services) is an ESPRIT III project running almost in parallel with MAXI aimed at improving the MAX system in the light of commercial developments. The CEC decided to fund the MAX follow-up
0140-3664193/020116-12 © 1993 Butterworth- Hei nemann Ltd 116
computer communications volume 16 number 2 february 1993
MAX: advanced network management capabilities in a standard MAN: G Carabell6 et al.
activities to support the implementation of a MAN system able to enlarge the set of capabilities offered by MAX, while the split of the work in two projects is due to CEC organizational issues. When MAX was conceived the role of MANs in the evolution towards the B-ISDN was not yet clear, the situation in the market for broadband systems was rather uncertain, and the adoption of standard solutions was still missing. Moreover, at that time the ESPRIT Programme was more oriented to pre-competitive projects aimed at making pure R&D investigations. All such considerations influenced the initial decisions taken in MAX and the system that is emerging is obviously somewhat lacking. Thus, while MAXI is in charge of showing the effectiveness of the choices undertaken in MAX. MANTIS will capitalize on such choices adding new elements more appropriae from a market-oriented point of view.
ETSI
REFERENCE
MODEL
FOR
MANs
ETSI has standardized 2 a reference model for the introduction of MANs in the public network (see Figure 1). The two key elements of the communication architecture are the MAN Switching Systems (MSS) and the Access Facilities (AF). The AFs collect the traffic coming from customer networks (CN) and transfer it to the MSS they are attached to. The MSS provides the routing towards other local AFs or remote MSSs. The MSSs are interconnected via the transit network (by means ofthe inter-MAN systems interface, IMSI) and can be implemented either in a distributed or in a centralized way. In the former case, MAN nodes based on the DQDB 3 technology can be deployed to perform the switching functions; in the latter case, a centralized switch (e.g. based on the ATM technology) can be used. The following two kinds of AF are envisaged: •
AFI: a simple link, constituted by a DQDB pair of buses, connects the MSS with a so-called Access
I
CcN v
Figure I ETSI MAN Reference Model. AF: Access Facility: CN: Customer Network: IMSI: InterMAN Systems Interface: MSS: MAN Switching System: Q*: Generic MAN Management Interface: TMN: Telecom. Management Network: UMI: User MAN Interface
NOde (part of the CN), terminating the DQDB link and interfacing other customer equipment: the interface between MSS and AN is called the UMI (User MAN Interface). AF2: a gathering network, constituted by a collection of DQDB MAN nodes, connects the MSS with the CNs: the interface at the TM reference point could be the specific customer equipment interface (e.g. IEEE 802.3, Ethernet) or a DQDBbased interface. In the first case. AF2a, the interface is called USI (User Specific Interface): in the second case, AF2b, the interface is called UMI (User MAN Interface). As depicted in Figure 1, the MSSs and, if it is the case, the AF2s, are connected for management purposes to the rest of the public TMN through generic management interfaces called Q*. These interfaces can be either CCITT Q or Q3 interfaces (defined in CCITT Rec. G.773 and Rec. Q.961 and Q.962) or MAN Management specific QMAN interfaces (defined by ETSI). Further details on ETSI MAN Management aspects are provided below.
MAX G E N E R A L A R C H I T E C T U R E AND CHARACTERISTICS The MAX architecture is based on the MAX node concept. Each node collects the traffic coming from external networks and is attached to other nodes through DQDB links. To perform such duties two basic node components can be identified: •
the Communication Subsystem(CS) implementing layer 1 and 2a functionalities a set of Network Access Modules (NAM) in charge of connecting external networks to MAX by means of appropriate protocol translation.
•
A number of different MANs are being developed that are able to connect facilities such as Ethernet, FDDI and 2 Mbit/s isochronous links to MAX. Actually.
A 121
"
" I UbiI
,' ~..----.-.~' 7
1
,~'2 ( I A ~
computer communications volume 16 number 2 february 1993
,
;
/
" 7I" ,
~
•
'
"
~*
/
/
',
..., I '%
/
~
~
.'L~A" /
NETWORK
] I
I
117
MAX: advanced network management capabilities in a standard MAN: G Carabellb et al.
flexibility appears to be one of the most outstanding features of the MAX nodes: • •
different external facilities can share a node at the same time different transmission systems (either traditional PDH or new SDH systems) can be adopted to support MAX communications.
MAX is remarkably well-suited for implementing configurations in line with the ETSI reference scenarios. As described in Figure2, a set of MAX nodes can give rise to a distributed MSS while appropriate NAMs performing DQDB-DQDB bridging functions enable the connection of both AF1 and AF2 subnetworks. Such networks may in turn be constituted by MAX nodes. Moreover, the dialogue with the transit network is ensured by appropriate NAMs supporting DQDB links, still in compliance with ETSI standards. It is worth noting how the MAX node enables the realization of all the complex ETSI scenarios by making use of very simple architectural solutions. Different configurations can be supported by simply combining the appropriate node modules that can be replaced or upgraded when required. Furthermore, it needs to be emphasized that the adoption of DQDB as the communications protocol provides integrated services capabilities, and ensures full interoperability to MAX nodes with the future cell-based public networks.
its functional and physical architectures, the management services it supports, and the managed objects representing the managed network resources. In particular, the TMN (Telecommunications Management Network) model has been specified by CCITT in Draft Rec. M.30104 to define general functional and physical architectures for public network management systems. Following the TMN model, ETSI has defined the architectures for a MAN management system. These architectures are briefly discussed below.
ETSI MAN management functional architecture The management system functional architecture consists of the specification of required management functions and of their relationships. In general, the management functions are grouped in functional blocks with reference points in between. The following general functional blocks are foreseen in the TMN model: •
•
ETSI MAN M A N A G E M E N T REFERENCE MODEL A network management system can be specified according to the relevant CCITT standards providing
•
OSF (Operations System Functions)-this block includes functions required to process information related to the telecommunication management for the .purpose of monitoring/coordinating and controlling of telecommunication functions (including management functions). MF (Mediation Functions)-this block acts on information passing between an OSF and NEFs to ensure that the information conforms to the expectations of the functional blocks attached to the MF. NEF (Network Element Functions)- includes all the functions required for the Network Element
Figure 2
@@ 118
MAX in the ETSI MAN Reference Model. CS: Communication Subsystem: DBN: DQDB NAM: EAM: Ethernet NAM" FDN: FDDI NAM: OSN: Operations System NAM: USI: User Specific Interface
computer communications volume 16 number 2 february 1993
MAX: advanced network m a n a g ~ n t
(NE) to permit the management of its telecommunications capability. DCF (Data Communication Functions) - used by the T M N functional blocks for exchanging information (i.e. it provides the means to transport information related to telecommunications management between management functional blocks). A reference point, called the q reference point, is foreseen between two of the blocks mentioned. To define MAN management functional blocks, ETSI has considered the correspondence between elements of the MAN reference model described above and the TMN management functional blocks. On this basis, the following MAN management functional blocks have been identified (see Figure 3): •
• •
M M F (MSS Management Functions), managing the MSS resources A2MF (AF2 Management Functions), providing .management of the AF2 subnetwork as a whole N M F (Node Management Functions), managing the single AF2 Node resources.
Each MAN management functional block consists of one or more T M N functional block(s), as indicated in Figure 3. In particular, the M M F is constituted by N E F (related to the management of a single, internal MSS component), MF (for the collective management of the whole MSS and connected AF1 resources), and optionally, OSF (when T M N OSF external functions are not available for MAN management). It is assumed that the functions needed to manage the AFis are part of the MMF. The A2MF is constituted by MF (for the management of the set of MAN nodes belonging to the AF2 itself) and, optionally, by OSF (when TMN OSF external functions are not available for MAN management). The N M F is composed by N E F and MF related to the management of node resources. Depending on the actual management solution, the N M F can be managed by the MF and OSF belonging
MAN M A N A G E M E N T Functional Blocks MAN Reference Model Elements MMF: A2MF:
NMF: X: Fipre 3
MMF
MSS (+ AFI)
A2MF
NMF
X
AF2 MN
(X)
X X
MSS Management Functions AF 2 Management Functions
NodeManagement Functions foreseen
capabilities in a standard MAN: G Carabellb et al.
either to A2MF or MMF, or even to an external TMN entity. These three management solutions are considered in the MAN management reference functional configuration, which is described below. The ETSI MAN management functional architecture. defined starting from the MAN Reference Model and the CCITT TMN model, is depicted in Figure 4 (where the functions related to the MAN Customer Network Management, described later, are not shown). According to this architecture, four environments are envisaged composing the whole TMN. The first includes the MAN-specific management functions. The second and the third, here respectively called TMN OSF and MF environment, deal with OSF and MF, which are in charge of managing and coordinating the MAN resources with other parts of the public network. The last environment concerns all the other management parts of the public network not relevant to MAN management. Different solutions are considered in the model. depending on how the management functionality of a MAN node (NMF) interacts with a TMN OSF. Four different, alternative paths have been identified: •
• •
•
Connection of N M F to TMN MF (path E), in turn connected to the TMN OSF: the A2MF are in this case not required. Connection of N M F to A2MF (path C) and connection of A2MF to TMN OFS (path A). Connection of N M F to M M F OSF (path D) or to M M F M F (path G) and connection of M M F and TMN OSF (path F): the A2MF are not required. Connection of N M F to A2MF (path C) and connection of A2MF to M M F OSF (path B), in turn connected to TMN OSF (path F).
Among the MAN management functional blocks and TMN OSF mentioned the functional architecture foresees q reference points. The DCF (Data Communication Functions) TMN functional block is implicit in Figure 4. The communications functions, required to allow interactions between
MAN Management Functional Blocks TMN Functional Blocks
OSF: MF: NEF: (X):
MMF
A2MF
OSF
(X)
(X)
MF
X
X
NEF
X
NMF
X X
Operations System Function MediationFunction NetworkElement Function optional
Relationships among MAN Reference Model elements and MAN management functional blocks defined by ETSI
computer communications volume 16 number 2 february 1993
119
MAX: advanced network management capabilities in a standard MAN: G Carabellb et al.
TMNOSF Eavixonm¢nt
. . . .
:osF',
,
. . . . .
q ~-
(A) q =
(OSF...1" .l.
qT
q I
OSF7,
,
J:
A2MF
ii
"~" t~
c..2L
°-
I (G)
I
NM F N
q-L
E
(D)
120
~
I I
Z .~
,
~
,
C
I
Z
I
"
-.3 .-
Hgure4
I
MIVlT
NMF
•
management physical architecture
The management system physical architecture consists of a collection of physical managed elements controlled by physical managing elements via communication facilities making use of proper interfaces. The TMN model's physical representation of the telecommunication system to be managed is a collection of Network Elements (NE) controlled by Operations Systems (OS) either directly or via Mediation Devices (MD). A Data Communication Network (DCN) provides communication facilities for information exchanges between these physical components. Proper interfaces, called 'Q' interfaces, are envisaged. The same approach has been adopted by ETSI specifying the MAN management physical architecture. Four solutions have been identified for the physical architecture, related to the different communication paths indicated in the MAN management functional architecture, and these are depicted in Figure 5. In all the solutions the MSS is connected to the T M N via either CCITT Q or Q3 interfaces, or the MAN management-specific QMANinterface, while differences among the solutions are related to the way in which the MAN Nodes (MN) of the AF2 are managed by the TMN OS(s). The A2-MD and A2-OS are the physical elements implementing the A2MF. respectively, when only MF or MF and OSF are included: •
m
E
A2MF or N M F and M M F through the q reference points, could be provided either by a separate network or by the MAN itself. ETSI M A N
I I q°l" I
i NMF
I
q -" (E~ q
-lI I I I
I
.~E
I
..
q
q
. . . . . .
I
/ S'L
, ~OSFI I
q,
Type 1 solution: the AF2 MNs are connected to a TMN M D via a 'short stack' QMAN; the TMN M D
•
•
ETSIMAN management functional reference configuration (with implicit DCF)
is in turn connected to the rest of the TMN via a CCITT Q or Q3 interface. Type 2 solution: the AF2 MNs are connected to an A2-MD/A2-OS via a 'short stack' QMAN: the A2MD/A2-OS is in turn connected to the rest of the TMN via a CCITT Q or Q3 interface, or via an ETSI QMAN interface. Type 3 solution: the AF2 MNs are connected to an A2-MD/A2-OS via a 'short stack" QMAN: the A2-MD/A2-OS is connected to the MSS via an ETSI QMAN:the MSS is then managed by the TMN OS(s). Type 4 solution: the AF2 MNs are connected to the MSS via a 'short stack" QMANwhile the MSS is managed by the TMN OS(s).
Note that in Figure 5 the physical elements are indicated with double line boxes and the DCN is implicit. The above-mentioned QMAN interfaces have been defined by ETSI for MAN management-specific purposes. Two kinds of protocol suite have been identifed: "full stack' QMAN and 'short stack" QMAN. Both the protocol suites are derived by CCITT specifications, respectively, for Q3 (Rec. Q.961 and Q.962)5. 6 and Q (G.773) 7 interfaces, changing the MAC layer (IEEE 802.6 instead of IEEE 802.3) and Physical Layer (MAN instead of LAN-specific). The "full stack' QMAN can be optionally used by the MSS and/or the A2-MD/A2-OS depending on the physical architecture and is only 'suggested' by ETSI. The "short stack" QMAN is instead mandatory on each AF's MAN node, and has been completely standardized by ETSI with the following protocol suite:
computer communications volume 16 number 2 february 1993
MAX: advanced network management capabilities in a standard MAN: G Carabellb et al. Q/Q3/Q ~d¢
q~3~Ma~
Q/Q 3/Q MAH
Q/Q3/Q~um
Type 2
~3/qmm
I Figure5
Type B
I
Type 4
ETSIMANmanagementphysicalarchitectures
Mapping functions ISO 9596 CMIP, ISO 8649 ACSE, ISO 9072 !.2 ROSE Mapping functions between Layer 7 and Layer 3 Layer 3: ISO 8473 Inactive Subset Protocol Layer 2: ISO 8802.2/3 LLC and IEEE 802.6 DQDB MAC Layer l" PDH or SDH MAN Physical Layer.
m a n a ~ e n t traffic is then transferred along the MAX network as far as the node the OS is connected to. The management information.is here forwarded to the OS via a NAM called the 'OS NAM'. According to the most recent advances in international standards, the management software has been designed in MAX following the object-oriented (OO) paradigm. According to such a paradigm all the physical and logical network resources to be managed are modelled as objects and correspondent attributes. All management activities give rise to a number of interactions between involved objects on the basis of well-defined rules. Though use of OO methods implies considerable overhead with respect to traditional methods, advantages are remarkable in terms of modularity, efficiency and readibility. Two management applications have been developed by SIRTI for MAX. The first, performing Operations System Functions (OSF), has been developed on a RISC workstation with a UNIX operating system. The software modules are written using C and C + + programming languages. The second application, in charge of the management functionalities local to each node, is called the NCME (Node Controller Management Entity), and is developed on a microprocessor board with a real-time operating system. The software modules are written in C. In the following sections a short description of the software architecture of both the applications is given.
MAX M A N A G E M E N T SYSTEM Architecture and characteristics The MAX management system is based on functionalities located both in the central operations system and in the various nodes. The structure that comes out is hierarchical, according to the TMN Reference Model and to the ETSI MAN Management architectures, and distributed, taking advantage of the processing capabilities inside each node. The dialogues between the OS and the nodes occur through standard interfaces in compliance with the above-described ETSi standards. Actually, inside each node both the CS and the NAMs are equipped with simple local management applications (respectively called Communication Subsystem Management Entities, CSMEs, and NAM Management Entities, NMEs); a specific node module, called the Node Controller (NC), converses with them through an internal node bus. The NC is then in charge of communicating with the OS through a 'short stack' QMAN interface. To carry out this activity, the NC makes use of the communication facilities provided by the CS (DQDB MAC and Physical Layer). The
computer communications volume 16 number 2 february 1993
OSF application The analysis carried on the requirement of the MAX management system has lead to the identification of the following three components: The Human-Machine Interface, allowing the application user to interact with the system: via a set of graphic objects, shown on the workstation monitor, the user accesses both remote network resources and local resources. Two different classes of users were identified: the Network Manager and the Network Operator. The Network Manager is responsible for the MAN and the OS and is therefore allowed to modify the configuration of the network resources ('read and write permission'). The Network Operator is staff personnel under the control of the Network Manager, who is only allowed to monitor the network resources ('readonly permission'). The local database that constitutes the local mass storage where the management information are kept. This information may either be local or remote; typical local information is a users account (login and password). Typical global information is given by tables representing the image of the remote managed objects. The communication stack, implementing the
121
MAX: advanced network management capabilities in a standard MAN: G Carabellb et al.
interface through which the management data flow.
•
For each of these components a set of processes has been identified and developed: among them a key role is played by: • •
the software, portability (X W I N D O W is the de.[acto standard for graphic user interfaces) an object-oriented approach to the software development (as the X W I N D O W libraries are based on the widget concept: a widget, WInDow objGET, is a graphic object which reacts to input events from keyboard or mouse, and produces outputs typically invoking user-defined routines).
PR__TERM process, the human interface handler PR__DB process, which takes care of the database management PR___FAULT process, which manages all the fault situations that occur in the network PR__STACK process, responsible for all the communications through the protocol stack.
.form and function of a widget. The form describes the
All the interactions among the processes are achieved using the Inter-Process Communication (IPC) mechanisms offered by the UNIX operating system. Figure 6 gives a schematic description of the OSF application software architecture. In the following a brief description of the above processes is given.
PR_._DB process The PR__DB process manages all
• •
The main characteristic of X Window is to separate the graphic attributes of the widget such as colour, size, text, font, and so on. The function is the action taken when the user makes a selection using an input device (mouse or keyboard). Generally, a function is a user written routine. The linking between functions and widgets is obtained by a callback mechanism.
the network data. It supports all the operations system procedures requiring interactions with the local database, and keeps the image of the network parameters updated. Therefore, the P R _ D B process takes care of:
PRmTERM process The operator interacts with the management system through the Human-Machine Interface in order to monitor and control the whole network and its elements. The HMI is "what the operator sees' of the whole application and therefore has been developed in a graphic environment that, using a set of simple symbols, allows the execution of management commands on the network. The PR___TERM process implements this interface in the X W I N D O W graphic environment, using the XII libraries toolkit. The use of the Xll toolkit libraries provides: •
a graphic representation of the specific managed
•
• • •
storing data related to the network configuration, performance, tariffing, accounting and billing procedures checking and executing data queries and manipulation operations performing the required stored data elaboration (e.g. billing evaluation, etc.) offering an object-oriented interface between the relational database that really manages the network data at a low level, and the other procedures or processes.
The P R m D B process consists mainly of a library of classes where both the data type definitions and the database access method definitions are contained. The former are essentially a subset of the columns defined in the corresponding relational database tables: the latter are the procedures used to access the database tables via embedded SQL commands. In this way, procedures and processes do not need to know the database configuration to instantiate an object: the knowledge of the database is confined to the class methods provided by the P R _ D B process.
PR__FAULT process PR__FAULT is the process • ..3 .......
m o t * i o o i o = o l g l l l m J = m = l = = e a a o = . l l l
Figure 6
122
i
...........
o
~ = s J l l = .
OSF application software architecture
i = l e e J e g = e l i e . =
which manages fault situations that occur on the network. It performs this activity by collecting and analysing all the alarms coming from the remote nodes. An alarm can be generated as a consequence of autonomous or controlled events. Autonomous events report problems that could seriously reduce the quality of service offered by the network: for such a reason they are 'autonomously" generated by remote agents. Controlled events are reports generated in answer to an
computer communications volume 16 number 2 february 1993
MAX: advanced network management capabilities in a standard MAN: G Carabell6 et al.
enquiry previously emitted by PR__FAULT: they usually carry information about the status of a remote managed object. Each alarm received by PR__FAULT is processed to determine its impact on the network and offered services. Depending on the event, the process undertakes recovery or test actions. In any case, a log of the event is stored in the local database and a communication is sent to the PR___TERM process which graphically informs the operator. PR_..STACK process PR__STACK is the process which, using the QMANprotocol profile described above, acts as communication server for the whole OSF application. The other OSF processes interact with PR___STACK by system queues. When a process needs to interact with a remote entity, it delivers the proper message to the P L S T A C K queue. PR__STACK takes this message, formats the appropriate CMIP protocol primitive, and sends it to the remote peer entity. Afterwards, PR__STACK informs the requesting process about the success or failure of the operation. The interaction with the network takes place through the standard communication interface previously described. The PR..._STACK main body is an endless loop which sequentially performs the following tasks: listening to the network for a given period of time; after reception of an incoming message, PR__STACK checks the integrity and correctness of the message fields, completes its local elaborations and, if it is the case, delivers the message to the proper process for further elaborations. listening to the queue to handle service requests coming from other OSF processes. PR__STACK detects the emitting process and the required operation by looking at the proper fields of the message. If the request can be met, the appropriate CMIP primitive is formatted by filling the fields of the appropriate 'C" structure, and sent to the remote process. This "C" structure (which represents the software description of the managed object class involved in the operation) has been previously obtained by an off-line 'compilation phase'. During this phase, the abstract ASN.1 syntax of the managed object class is translated into an equivalent 'C" structure by means of an ASN.1 compiler.
1
The:local management component, which includes the mechanism that allows the data exchange among the node management entities (NCME, CSME and NMEs). This data transfer takes place via an ad hoc defined protocol. The VME communication bus is used as physical medium to carry the information among the entities. The remote management component, where the local received information is properly formatted and sent to the remote operation system. Within this block the QMAN protocol profile is implemented.
2
Two main processes are foreseen for the NCME appliration software architecture to implement the above described components (see Figure 7): PR__LOC process which handles the communication with the local boards of the node, and PR__REM process, which interacts with the remote operations system. A queue mechanism has been implemented for the data exchange between the processes. In the following a brief description of the processes is provided. PR__LOC process The PR__LOC process takes care of the management data transfer mechanism among the node controller, CS and NAM modules. The mechanism involves the PR__LOC and the management entities of CS and NAMs, and makes use of the node's high-speed communication bus. Whenever a process sends a message to another, it uses a notification procedure based on software interrupts. In such a way the receiving process is informed of the incoming message and can undertake the proper action. In particular, P R _ L O C receives, through PR__REM, the configuration setup data coming from the remote operations system and sends them to the CS and the NAMs. Moreover, PR__LOC waits for alarm notifications or data related to the accounting computation and sends them to the OS via PR__REM.
• ..,.a,,0..,.,....o, 1 I PR(~N~I~ 0.o,o.,...,..,..o.....,.,o.., PRLO~ 1
[
iiiiiiiiiiiiiiiiilIiiiiiii! iiiiiiiiiiiiiiiii 2
MAX NODE
I ,xu
I~AL
I MARPING CMEP-AC~F.-ROSE ~S ]
BUS
,
NCME application
NETW~J~LSO8473
The Node Controller Management Entity application is developed on a microprocessor board which is inserted within each MAX node, and performs the control of all the local resources (managed objects). Two components have been envisaged for this application:
computer communications volume 16 number 2 february 1993
LLC ISO 11102.2TYPE 3
,, o°°°°o°,ol o,,.oo°e° °ml~.H°~°° °,o °o.°°°°o,,°° °.
K F'~
7
NCME application software architecture
123
MAX: advanced network management capabilities in a standard MAN: G Carabellb et al.
PR_,REMproce,~s The PR__REM process represents
CSME, NME and NCME applications collectively implement the ETSI NMF functional block. In more detail, the CSME and NME implement part of the NEF part of the NMF, while the NCME implements the other NEF part and the MF. The MAX management physical architecture (depicted in Figure 9) is aligned with ETSI Type 4 solution. In fact:
the object-oriented interface towards the operations system. In fact, it receives the rough management data coming from the PR__LOC process and formats them using the appropriate CMIP primitive. Afterwards, it forwards the primitive to the OS through the MAN network. Furthermore, it waits for the arrival of data coming from the operations system. Every time a CMIP primitive is received. PR__REM identifies the incoming request, extracts the data contained in the PDU, and then properly informs PR__LOC of the event. In such a way the command originated from the OS can be executed.
•
•
Comparison between MAX and ETS! management architectures
•
Both the functional and the physical architectures of the MAX management system have been defined according to the relevant ETSI specifications. Regarding the functional architecture, it should be noted that by using MAX nodes a distributed MSS can be implemented. Therefore, the MMF are distributed over the MSS nodes and no centralized MF or OSF is envisaged within the MMF (see Figure 8). As far as the management of the AF's MAN nodes is concerned, an ETSI path G plus path F solution (see Figure 8) is adopted in MAX for NMF to TMN OSF connection. Since no centralized MF is present in the MMF, only communication facilities are provided by the MSS for the management of the MAN nodes. The solution adopted in MAX is the simplest and more integrated among those identified by ETSI. While discussing software implementation, the
MAX OSF Eavimamcnt
As a consequence of the adopted solution, no differences are requested in the implementation of the management applications in the MAX nodes depending on their use in AFs or MSSs. All the management communications employ the MAX network as data communication network. From the above analysis, it is clear that the MAX management system is being developed in alignment with the ETSI current specifications (and therefore with CCITT TMN recommendations). The compliance with standards will enable easy connection with other management systems, providing operators with the desired integration capabilities.
SF~
i
the MAX Operations System (MOS) can be seen as the physical implementation of the TMN OSF of the controlling the (MAX) MAN the AFs MAN Nodes (MAX nodes) are managed by the TMN OS (MAX OS) through the MSS via 'short stack" QMAN interfaces the MSS itself(here constituted by a collection of MAX nodes) is connected to the TMN OS (MAX OS) via either a Q o r a QMANinterface (depending) on the NAM used for the connection of the OS to the MAX network which implements the MSS).
!
I
X
OSF
q"
..
°.
MMF
124
m
NMF
Fipre8 MAX management functional configuration (with implicit DCF)
computer communications volume 16 number 2 february 1993
MAX: advanced network management capabilities in a standard MAN: G Carabell6 et al.
Physical Architecture
Qmm I
i
MAX~ = g m m
Mss
Figure 9
AF2
The C N M S manager could be a functional block constituted by specific customer management functions. In this case anxMc (MC MAN CNMS) reference point is envisaged between the CNMS manager (in the customer environment) and the CNMS agent (in the public network management system). If the customer is not provided by CNMS manager functions, he can access the CNMS via Customer Terminal (CT) functions. This block is connected to the CNMS manager, belonging to the MAN CNMS access functions, through afMc reference point. The CNMS manager in turn is connected to the CNMS agent (in the public network management system) through an XMc reference point. The ETSI MAN CNM functional architecture foresees two possible solutions: 1
MAX management physical architectures
2 CUSTOMER NETWORK MANAGEMENT Taking into account new requirements emerging from business customers, a further management area has been considered in CCITT, ETSI and MAX. This area, called Customer Network Management (CNM), covers all aspects related to communications between customers (or their own management system) and the public network management system. E T S ! view of C N M Referring to the ETSI specifications, the MAN Customer Network Management Services (MAN CNMS) are services that permit interaction between a customer and the MAN management system: the customer can handle (get, set and change) related information or request some MAN management actions through a proper interface. In any case, a CNMS user should not be able either to affect another customers traffic or to reach data pertaining to another user. MAN customers can only access well defined CNMSs on the basis of the subscribed rights. According to the relevant ETSI documents, the provider of these services, namely the CNMS agent in the MAN management system, can either accept or refuse customer requests (on the basis of a customer identification process and control of related rights). When the request is accepted, the agent selects the proper information retrieval and processing to offer the CNMS to the customer, namely the CNMS manager. To this end, the CNMS agent interacts with the proper operation system function blocks, which collect and control the required information. These interactions are not depicted in Figure 10, which instead shows one of the functional and physical architectures defined by ETSI for MAN CNM.
customer connected through a XMc interface (based on CMIP application layer): customer connected through a FMC interface (simplified terminal interface). Two sub-cases are envisaged for the first solution: The CNMS manager in the customer domain accesses the CNMS agent belonging to the MAN/ public network management system. The CNMS manager in the customer domain accesses the CNMS agent in a dedicated MAN CNMS provision unit (MC-PU). This unit interacts with the MAN/public network management system via proper interfaces (X interface when the MC-PU and the OSs belong to different responsibility domains, while it is not defined when they belong to the same responsibility domain). The MC-PU could be owned by the MAN provider or by a VASP (Value Added Services Provider).
Three sub-cases are envisaged for the second solution: The customer, via the Customer Terminal (CT), accesses the CNMS manager in the MAN/public network management system, which in turn interacts with the CNMS agent. This solution is depicted in Figure lOa. The customer, via the CT, accesses the CNMS manager in a dedicated MAN CNMS access unit (MC-AU). This unit interacts with the CNMS agent belonging to the MAN/public network management system via an XMC interface. The MC-AU could be owned by the MAN provider or by VASP. The customer, via the CT, accesses the CNMS manager in a dedicated MC-AU. This unit interacts with the CNMS agent in a MC-PU, which in turns interacts with the MAN/public network management system via proper interfaces. Both ii
computer communications volume 16 number 2 february 1993
125
MAX: advanced network management capabilities in a standard MAN: G Carabellb et al.
[MAXC me,1 Tenn.,
rC SM='g. 1
;
J
,'
f
'
[,in NCME Appl.,I
'
L,
TenninaJ
in OSF Appl. )
x
MC
Customer
[ CNMAge= "1
t
MC
CNMS
[
CNMS Agent MAN Management Functions
Manager
I
N
I
Customer
'
MAN CNMS
]
M~nagemcnt
'
Access
I
f
MC
MC
]
,, 'I
NCME
' ' MC Type !
MAXCr
C•l.qtomcr•
MAX Node
I
OSF I ' MAX OS X MC Type
MAN Management System
Domaia
i
@ill
I I
,
'
F
/
I
~
t
I
MC
X
MC
MC-AU and M C - P U could be owned by the MAN provider or by VASPs.
MAX CNM In the projects the provision o f C N M S has been studied 8 even if, due to budget limitations, the implementation o f related facilities is at the m o m e n t not guaranteed. In the MAX system customers can access C N M S services via both XMc-type and FMc-type interfaces. In the former case, a p r o p e r NAM connects the customer C N M S m a n a g e r to the MAX network, providing a c o m m u n i c a t i o n path to the MAX OS, where applications playing the role o f C N M S agent are implemented. In the latter case (depicted in Figure lOb) dedicated terminal-links are envisaged a m o n g customers terminals and the MAX node controller, where applications playing the role o f the C N M S managers are implemented. As in the first case, the C N M S managers converse with the MAX OS ( C N M S agent).
126
;~.~
=
Figare 10 (a) ETSI and MAX customer network management comparison of equivalent functional architectures: (b) ETSI and MAX customer network management cornparian of equivalent physical architectures (CT: Customer Terminal: M: MAN CNMS manager: A: MAN CNMS agent)
CONCLUSIONS This paper has illustrated the features o f the MAX m a n a g e m e n t system, covering both architectural and functional aspects. A description o f the system software architecture has been given, with particular emphasis on the advanced tools and methodologies employed. Taking ETSI d o c u m e n t a t i o n as the reference point, a detailed analysis has shown that MAX is aligned with the standards, and can represent a real implementation o f the ETS| concepts.
REFERENCES I 2 3
4
Gad, L and Vereelli0R 'Metropolitan area network management issues', RACE Conf., Paris, France (1991) ETS! ETS 300211 Metropolitan Area Network l%'nciples and Architecture, ETSI, France (1991) IEEESO2.6Standard, DistributedQueueDualBussubnetworkofa MAN. IEEE. New York. USA (1991) CCITT Draft Recommendation M.3010 l~inciplevfor a Telecommunications Management Network. CCITT. Geneva. Switzerland (1991)
computer communications volume 16 number 2 february 1993
MAX: advanced network management capabilities in a standard MAN: G Carabellb et al. 5 6
CCITT Draft Recommendation Q.311 Lower Laver Protocol Profiles for the Q3 Interface. CCITT, Geneva, Switzerland (1992) CCI'Vr Draft Recommendation Q.312 Upper Layer Protocol Profiles for the Q3 Interface. CCITT. Geneva. Switzerland (1992)
computer communications volume 16 number 2 february 1993
7 8
CCITT Recommendation G.773. Protocol Suites for Q Interfaces for Management of Transmission System. CCI'FI', Geneva, Switzerland (1990) Gavi, L and Veredli, R 'User management services in a metropolitan area network environment'. Prac. EFOC/LAN. London. UK (1991)
127
set of relevant programmes. In particular, within the framework of the ESPRIT and RACE Programmes, a number of projects are currently related to MANs. Among such projects MAX (Metropolitan Area Network Communication System) has played a fundamental role, identifying a standard-compliant system which is now being developed in two follow-up projects. As described in this paper, the MAX system has been conceived taking advantage of most advanced technological and engineering solutions, but also bearing in mind the features required for a commercial system. Actually, MAX is expected to impact the MAN European market in the years to come.
This paper aims to provide an overview on the characteristics of the MAX system, focusing on aspects concerning network management. MAX is a MAN system conceived in the framework of the ESPRIT Programme. promoted by the Commission of European Communities to support European R&D activities in the IT area. MAX implements the solutions defined by the European Telecommunication Standard Institute, relevant standards on MANs. and is able to provide integration of services and very high speeds. The management capabilities envisaged for MAX are based on the ETSI MAN management documents, and are compliant with the CCITT TMN Reference Model. An object-oriented approach has been followed within MAX to develop the management software, ensuring modularity and portability. Different management areas have been covered including aspects related to Customer Network Management. i.e. the possibility for customers to interact with the MAN management system.
MAX A N D R E L A T E D E S P R I T P R O J E C T S
Keywords: MAN management, MAX, customer network management, O-O software
MANs are today considered as the first solution able to offer broadband communication capabilities to users in Europe. Therefore deployment of MAN systems is underway in several European countries based on equipment provided by different manufacturers and commercial services that will be soon available. To ensure flexibility and interoperability a standardization activity was started in Europe early on within the European Telecommunication Standard Institute. Such an activity has resulted in a number of standard documents which are to represent the reference point leading the installation of MAN systems all across Europe I. Additionally, the Commission of the European Communities has been promoting the introduction of broadband facilities for some years (IBCN) through a SIRTI SpA. Network Technologies Division, Via Vlda 19, 1-20127, Milan, Italy
The MAX project started in 1989, and finished in 1991 within the framework of the ESPRIT II Programme. The main goal of MAX was to design and specify the architecture of a complete system to operate in metropolitan areas, and to provide very high speeds and integration of services. Subsequently, a development phase started based on the adoption of innovative system solutions and the exploitation of new switching and transmission techniques. Given the excellent results achieved in MAX, two other projects have been conceived to complete, refine and integrate the system development: MAXI and MANTIS. MAXI (Metropolitan Area Communication System Integration) is an ESPRIT II project (started in 1992 and to end by 1994) specifically devoted to the completion of work according to the original plans identified in MAX. MANTIS (Metropolitan Area NeTwork for Integrated Services) is an ESPRIT III project running almost in parallel with MAXI aimed at improving the MAX system in the light of commercial developments. The CEC decided to fund the MAX follow-up
0140-3664193/020116-12 © 1993 Butterworth- Hei nemann Ltd 116
computer communications volume 16 number 2 february 1993
MAX: advanced network management capabilities in a standard MAN: G Carabell6 et al.
activities to support the implementation of a MAN system able to enlarge the set of capabilities offered by MAX, while the split of the work in two projects is due to CEC organizational issues. When MAX was conceived the role of MANs in the evolution towards the B-ISDN was not yet clear, the situation in the market for broadband systems was rather uncertain, and the adoption of standard solutions was still missing. Moreover, at that time the ESPRIT Programme was more oriented to pre-competitive projects aimed at making pure R&D investigations. All such considerations influenced the initial decisions taken in MAX and the system that is emerging is obviously somewhat lacking. Thus, while MAXI is in charge of showing the effectiveness of the choices undertaken in MAX. MANTIS will capitalize on such choices adding new elements more appropriae from a market-oriented point of view.
ETSI
REFERENCE
MODEL
FOR
MANs
ETSI has standardized 2 a reference model for the introduction of MANs in the public network (see Figure 1). The two key elements of the communication architecture are the MAN Switching Systems (MSS) and the Access Facilities (AF). The AFs collect the traffic coming from customer networks (CN) and transfer it to the MSS they are attached to. The MSS provides the routing towards other local AFs or remote MSSs. The MSSs are interconnected via the transit network (by means ofthe inter-MAN systems interface, IMSI) and can be implemented either in a distributed or in a centralized way. In the former case, MAN nodes based on the DQDB 3 technology can be deployed to perform the switching functions; in the latter case, a centralized switch (e.g. based on the ATM technology) can be used. The following two kinds of AF are envisaged: •
AFI: a simple link, constituted by a DQDB pair of buses, connects the MSS with a so-called Access
I
CcN v
Figure I ETSI MAN Reference Model. AF: Access Facility: CN: Customer Network: IMSI: InterMAN Systems Interface: MSS: MAN Switching System: Q*: Generic MAN Management Interface: TMN: Telecom. Management Network: UMI: User MAN Interface
NOde (part of the CN), terminating the DQDB link and interfacing other customer equipment: the interface between MSS and AN is called the UMI (User MAN Interface). AF2: a gathering network, constituted by a collection of DQDB MAN nodes, connects the MSS with the CNs: the interface at the TM reference point could be the specific customer equipment interface (e.g. IEEE 802.3, Ethernet) or a DQDBbased interface. In the first case. AF2a, the interface is called USI (User Specific Interface): in the second case, AF2b, the interface is called UMI (User MAN Interface). As depicted in Figure 1, the MSSs and, if it is the case, the AF2s, are connected for management purposes to the rest of the public TMN through generic management interfaces called Q*. These interfaces can be either CCITT Q or Q3 interfaces (defined in CCITT Rec. G.773 and Rec. Q.961 and Q.962) or MAN Management specific QMAN interfaces (defined by ETSI). Further details on ETSI MAN Management aspects are provided below.
MAX G E N E R A L A R C H I T E C T U R E AND CHARACTERISTICS The MAX architecture is based on the MAX node concept. Each node collects the traffic coming from external networks and is attached to other nodes through DQDB links. To perform such duties two basic node components can be identified: •
the Communication Subsystem(CS) implementing layer 1 and 2a functionalities a set of Network Access Modules (NAM) in charge of connecting external networks to MAX by means of appropriate protocol translation.
•
A number of different MANs are being developed that are able to connect facilities such as Ethernet, FDDI and 2 Mbit/s isochronous links to MAX. Actually.
A 121
"
" I UbiI
,' ~..----.-.~' 7
1
,~'2 ( I A ~
computer communications volume 16 number 2 february 1993
,
;
/
" 7I" ,
~
•
'
"
~*
/
/
',
..., I '%
/
~
~
.'L~A" /
NETWORK
] I
I
117
MAX: advanced network management capabilities in a standard MAN: G Carabellb et al.
flexibility appears to be one of the most outstanding features of the MAX nodes: • •
different external facilities can share a node at the same time different transmission systems (either traditional PDH or new SDH systems) can be adopted to support MAX communications.
MAX is remarkably well-suited for implementing configurations in line with the ETSI reference scenarios. As described in Figure2, a set of MAX nodes can give rise to a distributed MSS while appropriate NAMs performing DQDB-DQDB bridging functions enable the connection of both AF1 and AF2 subnetworks. Such networks may in turn be constituted by MAX nodes. Moreover, the dialogue with the transit network is ensured by appropriate NAMs supporting DQDB links, still in compliance with ETSI standards. It is worth noting how the MAX node enables the realization of all the complex ETSI scenarios by making use of very simple architectural solutions. Different configurations can be supported by simply combining the appropriate node modules that can be replaced or upgraded when required. Furthermore, it needs to be emphasized that the adoption of DQDB as the communications protocol provides integrated services capabilities, and ensures full interoperability to MAX nodes with the future cell-based public networks.
its functional and physical architectures, the management services it supports, and the managed objects representing the managed network resources. In particular, the TMN (Telecommunications Management Network) model has been specified by CCITT in Draft Rec. M.30104 to define general functional and physical architectures for public network management systems. Following the TMN model, ETSI has defined the architectures for a MAN management system. These architectures are briefly discussed below.
ETSI MAN management functional architecture The management system functional architecture consists of the specification of required management functions and of their relationships. In general, the management functions are grouped in functional blocks with reference points in between. The following general functional blocks are foreseen in the TMN model: •
•
ETSI MAN M A N A G E M E N T REFERENCE MODEL A network management system can be specified according to the relevant CCITT standards providing
•
OSF (Operations System Functions)-this block includes functions required to process information related to the telecommunication management for the .purpose of monitoring/coordinating and controlling of telecommunication functions (including management functions). MF (Mediation Functions)-this block acts on information passing between an OSF and NEFs to ensure that the information conforms to the expectations of the functional blocks attached to the MF. NEF (Network Element Functions)- includes all the functions required for the Network Element
Figure 2
@@ 118
MAX in the ETSI MAN Reference Model. CS: Communication Subsystem: DBN: DQDB NAM: EAM: Ethernet NAM" FDN: FDDI NAM: OSN: Operations System NAM: USI: User Specific Interface
computer communications volume 16 number 2 february 1993
MAX: advanced network m a n a g ~ n t
(NE) to permit the management of its telecommunications capability. DCF (Data Communication Functions) - used by the T M N functional blocks for exchanging information (i.e. it provides the means to transport information related to telecommunications management between management functional blocks). A reference point, called the q reference point, is foreseen between two of the blocks mentioned. To define MAN management functional blocks, ETSI has considered the correspondence between elements of the MAN reference model described above and the TMN management functional blocks. On this basis, the following MAN management functional blocks have been identified (see Figure 3): •
• •
M M F (MSS Management Functions), managing the MSS resources A2MF (AF2 Management Functions), providing .management of the AF2 subnetwork as a whole N M F (Node Management Functions), managing the single AF2 Node resources.
Each MAN management functional block consists of one or more T M N functional block(s), as indicated in Figure 3. In particular, the M M F is constituted by N E F (related to the management of a single, internal MSS component), MF (for the collective management of the whole MSS and connected AF1 resources), and optionally, OSF (when T M N OSF external functions are not available for MAN management). It is assumed that the functions needed to manage the AFis are part of the MMF. The A2MF is constituted by MF (for the management of the set of MAN nodes belonging to the AF2 itself) and, optionally, by OSF (when TMN OSF external functions are not available for MAN management). The N M F is composed by N E F and MF related to the management of node resources. Depending on the actual management solution, the N M F can be managed by the MF and OSF belonging
MAN M A N A G E M E N T Functional Blocks MAN Reference Model Elements MMF: A2MF:
NMF: X: Fipre 3
MMF
MSS (+ AFI)
A2MF
NMF
X
AF2 MN
(X)
X X
MSS Management Functions AF 2 Management Functions
NodeManagement Functions foreseen
capabilities in a standard MAN: G Carabellb et al.
either to A2MF or MMF, or even to an external TMN entity. These three management solutions are considered in the MAN management reference functional configuration, which is described below. The ETSI MAN management functional architecture. defined starting from the MAN Reference Model and the CCITT TMN model, is depicted in Figure 4 (where the functions related to the MAN Customer Network Management, described later, are not shown). According to this architecture, four environments are envisaged composing the whole TMN. The first includes the MAN-specific management functions. The second and the third, here respectively called TMN OSF and MF environment, deal with OSF and MF, which are in charge of managing and coordinating the MAN resources with other parts of the public network. The last environment concerns all the other management parts of the public network not relevant to MAN management. Different solutions are considered in the model. depending on how the management functionality of a MAN node (NMF) interacts with a TMN OSF. Four different, alternative paths have been identified: •
• •
•
Connection of N M F to TMN MF (path E), in turn connected to the TMN OSF: the A2MF are in this case not required. Connection of N M F to A2MF (path C) and connection of A2MF to TMN OFS (path A). Connection of N M F to M M F OSF (path D) or to M M F M F (path G) and connection of M M F and TMN OSF (path F): the A2MF are not required. Connection of N M F to A2MF (path C) and connection of A2MF to M M F OSF (path B), in turn connected to TMN OSF (path F).
Among the MAN management functional blocks and TMN OSF mentioned the functional architecture foresees q reference points. The DCF (Data Communication Functions) TMN functional block is implicit in Figure 4. The communications functions, required to allow interactions between
MAN Management Functional Blocks TMN Functional Blocks
OSF: MF: NEF: (X):
MMF
A2MF
OSF
(X)
(X)
MF
X
X
NEF
X
NMF
X X
Operations System Function MediationFunction NetworkElement Function optional
Relationships among MAN Reference Model elements and MAN management functional blocks defined by ETSI
computer communications volume 16 number 2 february 1993
119
MAX: advanced network management capabilities in a standard MAN: G Carabellb et al.
TMNOSF Eavixonm¢nt
. . . .
:osF',
,
. . . . .
q ~-
(A) q =
(OSF...1" .l.
qT
q I
OSF7,
,
J:
A2MF
ii
"~" t~
c..2L
°-
I (G)
I
NM F N
q-L
E
(D)
120
~
I I
Z .~
,
~
,
C
I
Z
I
"
-.3 .-
Hgure4
I
MIVlT
NMF
•
management physical architecture
The management system physical architecture consists of a collection of physical managed elements controlled by physical managing elements via communication facilities making use of proper interfaces. The TMN model's physical representation of the telecommunication system to be managed is a collection of Network Elements (NE) controlled by Operations Systems (OS) either directly or via Mediation Devices (MD). A Data Communication Network (DCN) provides communication facilities for information exchanges between these physical components. Proper interfaces, called 'Q' interfaces, are envisaged. The same approach has been adopted by ETSI specifying the MAN management physical architecture. Four solutions have been identified for the physical architecture, related to the different communication paths indicated in the MAN management functional architecture, and these are depicted in Figure 5. In all the solutions the MSS is connected to the T M N via either CCITT Q or Q3 interfaces, or the MAN management-specific QMANinterface, while differences among the solutions are related to the way in which the MAN Nodes (MN) of the AF2 are managed by the TMN OS(s). The A2-MD and A2-OS are the physical elements implementing the A2MF. respectively, when only MF or MF and OSF are included: •
m
E
A2MF or N M F and M M F through the q reference points, could be provided either by a separate network or by the MAN itself. ETSI M A N
I I q°l" I
i NMF
I
q -" (E~ q
-lI I I I
I
.~E
I
..
q
q
. . . . . .
I
/ S'L
, ~OSFI I
q,
Type 1 solution: the AF2 MNs are connected to a TMN M D via a 'short stack' QMAN; the TMN M D
•
•
ETSIMAN management functional reference configuration (with implicit DCF)
is in turn connected to the rest of the TMN via a CCITT Q or Q3 interface. Type 2 solution: the AF2 MNs are connected to an A2-MD/A2-OS via a 'short stack' QMAN: the A2MD/A2-OS is in turn connected to the rest of the TMN via a CCITT Q or Q3 interface, or via an ETSI QMAN interface. Type 3 solution: the AF2 MNs are connected to an A2-MD/A2-OS via a 'short stack" QMAN: the A2-MD/A2-OS is connected to the MSS via an ETSI QMAN:the MSS is then managed by the TMN OS(s). Type 4 solution: the AF2 MNs are connected to the MSS via a 'short stack" QMANwhile the MSS is managed by the TMN OS(s).
Note that in Figure 5 the physical elements are indicated with double line boxes and the DCN is implicit. The above-mentioned QMAN interfaces have been defined by ETSI for MAN management-specific purposes. Two kinds of protocol suite have been identifed: "full stack' QMAN and 'short stack" QMAN. Both the protocol suites are derived by CCITT specifications, respectively, for Q3 (Rec. Q.961 and Q.962)5. 6 and Q (G.773) 7 interfaces, changing the MAC layer (IEEE 802.6 instead of IEEE 802.3) and Physical Layer (MAN instead of LAN-specific). The "full stack' QMAN can be optionally used by the MSS and/or the A2-MD/A2-OS depending on the physical architecture and is only 'suggested' by ETSI. The "short stack" QMAN is instead mandatory on each AF's MAN node, and has been completely standardized by ETSI with the following protocol suite:
computer communications volume 16 number 2 february 1993
MAX: advanced network management capabilities in a standard MAN: G Carabellb et al. Q/Q3/Q ~d¢
q~3~Ma~
Q/Q 3/Q MAH
Q/Q3/Q~um
Type 2
~3/qmm
I Figure5
Type B
I
Type 4
ETSIMANmanagementphysicalarchitectures
Mapping functions ISO 9596 CMIP, ISO 8649 ACSE, ISO 9072 !.2 ROSE Mapping functions between Layer 7 and Layer 3 Layer 3: ISO 8473 Inactive Subset Protocol Layer 2: ISO 8802.2/3 LLC and IEEE 802.6 DQDB MAC Layer l" PDH or SDH MAN Physical Layer.
m a n a ~ e n t traffic is then transferred along the MAX network as far as the node the OS is connected to. The management information.is here forwarded to the OS via a NAM called the 'OS NAM'. According to the most recent advances in international standards, the management software has been designed in MAX following the object-oriented (OO) paradigm. According to such a paradigm all the physical and logical network resources to be managed are modelled as objects and correspondent attributes. All management activities give rise to a number of interactions between involved objects on the basis of well-defined rules. Though use of OO methods implies considerable overhead with respect to traditional methods, advantages are remarkable in terms of modularity, efficiency and readibility. Two management applications have been developed by SIRTI for MAX. The first, performing Operations System Functions (OSF), has been developed on a RISC workstation with a UNIX operating system. The software modules are written using C and C + + programming languages. The second application, in charge of the management functionalities local to each node, is called the NCME (Node Controller Management Entity), and is developed on a microprocessor board with a real-time operating system. The software modules are written in C. In the following sections a short description of the software architecture of both the applications is given.
MAX M A N A G E M E N T SYSTEM Architecture and characteristics The MAX management system is based on functionalities located both in the central operations system and in the various nodes. The structure that comes out is hierarchical, according to the TMN Reference Model and to the ETSI MAN Management architectures, and distributed, taking advantage of the processing capabilities inside each node. The dialogues between the OS and the nodes occur through standard interfaces in compliance with the above-described ETSi standards. Actually, inside each node both the CS and the NAMs are equipped with simple local management applications (respectively called Communication Subsystem Management Entities, CSMEs, and NAM Management Entities, NMEs); a specific node module, called the Node Controller (NC), converses with them through an internal node bus. The NC is then in charge of communicating with the OS through a 'short stack' QMAN interface. To carry out this activity, the NC makes use of the communication facilities provided by the CS (DQDB MAC and Physical Layer). The
computer communications volume 16 number 2 february 1993
OSF application The analysis carried on the requirement of the MAX management system has lead to the identification of the following three components: The Human-Machine Interface, allowing the application user to interact with the system: via a set of graphic objects, shown on the workstation monitor, the user accesses both remote network resources and local resources. Two different classes of users were identified: the Network Manager and the Network Operator. The Network Manager is responsible for the MAN and the OS and is therefore allowed to modify the configuration of the network resources ('read and write permission'). The Network Operator is staff personnel under the control of the Network Manager, who is only allowed to monitor the network resources ('readonly permission'). The local database that constitutes the local mass storage where the management information are kept. This information may either be local or remote; typical local information is a users account (login and password). Typical global information is given by tables representing the image of the remote managed objects. The communication stack, implementing the
121
MAX: advanced network management capabilities in a standard MAN: G Carabellb et al.
interface through which the management data flow.
•
For each of these components a set of processes has been identified and developed: among them a key role is played by: • •
the software, portability (X W I N D O W is the de.[acto standard for graphic user interfaces) an object-oriented approach to the software development (as the X W I N D O W libraries are based on the widget concept: a widget, WInDow objGET, is a graphic object which reacts to input events from keyboard or mouse, and produces outputs typically invoking user-defined routines).
PR__TERM process, the human interface handler PR__DB process, which takes care of the database management PR___FAULT process, which manages all the fault situations that occur in the network PR__STACK process, responsible for all the communications through the protocol stack.
.form and function of a widget. The form describes the
All the interactions among the processes are achieved using the Inter-Process Communication (IPC) mechanisms offered by the UNIX operating system. Figure 6 gives a schematic description of the OSF application software architecture. In the following a brief description of the above processes is given.
PR_._DB process The PR__DB process manages all
• •
The main characteristic of X Window is to separate the graphic attributes of the widget such as colour, size, text, font, and so on. The function is the action taken when the user makes a selection using an input device (mouse or keyboard). Generally, a function is a user written routine. The linking between functions and widgets is obtained by a callback mechanism.
the network data. It supports all the operations system procedures requiring interactions with the local database, and keeps the image of the network parameters updated. Therefore, the P R _ D B process takes care of:
PRmTERM process The operator interacts with the management system through the Human-Machine Interface in order to monitor and control the whole network and its elements. The HMI is "what the operator sees' of the whole application and therefore has been developed in a graphic environment that, using a set of simple symbols, allows the execution of management commands on the network. The PR___TERM process implements this interface in the X W I N D O W graphic environment, using the XII libraries toolkit. The use of the Xll toolkit libraries provides: •
a graphic representation of the specific managed
•
• • •
storing data related to the network configuration, performance, tariffing, accounting and billing procedures checking and executing data queries and manipulation operations performing the required stored data elaboration (e.g. billing evaluation, etc.) offering an object-oriented interface between the relational database that really manages the network data at a low level, and the other procedures or processes.
The P R m D B process consists mainly of a library of classes where both the data type definitions and the database access method definitions are contained. The former are essentially a subset of the columns defined in the corresponding relational database tables: the latter are the procedures used to access the database tables via embedded SQL commands. In this way, procedures and processes do not need to know the database configuration to instantiate an object: the knowledge of the database is confined to the class methods provided by the P R _ D B process.
PR__FAULT process PR__FAULT is the process • ..3 .......
m o t * i o o i o = o l g l l l m J = m = l = = e a a o = . l l l
Figure 6
122
i
...........
o
~ = s J l l = .
OSF application software architecture
i = l e e J e g = e l i e . =
which manages fault situations that occur on the network. It performs this activity by collecting and analysing all the alarms coming from the remote nodes. An alarm can be generated as a consequence of autonomous or controlled events. Autonomous events report problems that could seriously reduce the quality of service offered by the network: for such a reason they are 'autonomously" generated by remote agents. Controlled events are reports generated in answer to an
computer communications volume 16 number 2 february 1993
MAX: advanced network management capabilities in a standard MAN: G Carabell6 et al.
enquiry previously emitted by PR__FAULT: they usually carry information about the status of a remote managed object. Each alarm received by PR__FAULT is processed to determine its impact on the network and offered services. Depending on the event, the process undertakes recovery or test actions. In any case, a log of the event is stored in the local database and a communication is sent to the PR___TERM process which graphically informs the operator. PR_..STACK process PR__STACK is the process which, using the QMANprotocol profile described above, acts as communication server for the whole OSF application. The other OSF processes interact with PR___STACK by system queues. When a process needs to interact with a remote entity, it delivers the proper message to the P L S T A C K queue. PR__STACK takes this message, formats the appropriate CMIP protocol primitive, and sends it to the remote peer entity. Afterwards, PR__STACK informs the requesting process about the success or failure of the operation. The interaction with the network takes place through the standard communication interface previously described. The PR..._STACK main body is an endless loop which sequentially performs the following tasks: listening to the network for a given period of time; after reception of an incoming message, PR__STACK checks the integrity and correctness of the message fields, completes its local elaborations and, if it is the case, delivers the message to the proper process for further elaborations. listening to the queue to handle service requests coming from other OSF processes. PR__STACK detects the emitting process and the required operation by looking at the proper fields of the message. If the request can be met, the appropriate CMIP primitive is formatted by filling the fields of the appropriate 'C" structure, and sent to the remote process. This "C" structure (which represents the software description of the managed object class involved in the operation) has been previously obtained by an off-line 'compilation phase'. During this phase, the abstract ASN.1 syntax of the managed object class is translated into an equivalent 'C" structure by means of an ASN.1 compiler.
1
The:local management component, which includes the mechanism that allows the data exchange among the node management entities (NCME, CSME and NMEs). This data transfer takes place via an ad hoc defined protocol. The VME communication bus is used as physical medium to carry the information among the entities. The remote management component, where the local received information is properly formatted and sent to the remote operation system. Within this block the QMAN protocol profile is implemented.
2
Two main processes are foreseen for the NCME appliration software architecture to implement the above described components (see Figure 7): PR__LOC process which handles the communication with the local boards of the node, and PR__REM process, which interacts with the remote operations system. A queue mechanism has been implemented for the data exchange between the processes. In the following a brief description of the processes is provided. PR__LOC process The PR__LOC process takes care of the management data transfer mechanism among the node controller, CS and NAM modules. The mechanism involves the PR__LOC and the management entities of CS and NAMs, and makes use of the node's high-speed communication bus. Whenever a process sends a message to another, it uses a notification procedure based on software interrupts. In such a way the receiving process is informed of the incoming message and can undertake the proper action. In particular, P R _ L O C receives, through PR__REM, the configuration setup data coming from the remote operations system and sends them to the CS and the NAMs. Moreover, PR__LOC waits for alarm notifications or data related to the accounting computation and sends them to the OS via PR__REM.
• ..,.a,,0..,.,....o, 1 I PR(~N~I~ 0.o,o.,...,..,..o.....,.,o.., PRLO~ 1
[
iiiiiiiiiiiiiiiiilIiiiiiii! iiiiiiiiiiiiiiiii 2
MAX NODE
I ,xu
I~AL
I MARPING CMEP-AC~F.-ROSE ~S ]
BUS
,
NCME application
NETW~J~LSO8473
The Node Controller Management Entity application is developed on a microprocessor board which is inserted within each MAX node, and performs the control of all the local resources (managed objects). Two components have been envisaged for this application:
computer communications volume 16 number 2 february 1993
LLC ISO 11102.2TYPE 3
,, o°°°°o°,ol o,,.oo°e° °ml~.H°~°° °,o °o.°°°°o,,°° °.
K F'~
7
NCME application software architecture
123
MAX: advanced network management capabilities in a standard MAN: G Carabellb et al.
PR_,REMproce,~s The PR__REM process represents
CSME, NME and NCME applications collectively implement the ETSI NMF functional block. In more detail, the CSME and NME implement part of the NEF part of the NMF, while the NCME implements the other NEF part and the MF. The MAX management physical architecture (depicted in Figure 9) is aligned with ETSI Type 4 solution. In fact:
the object-oriented interface towards the operations system. In fact, it receives the rough management data coming from the PR__LOC process and formats them using the appropriate CMIP primitive. Afterwards, it forwards the primitive to the OS through the MAN network. Furthermore, it waits for the arrival of data coming from the operations system. Every time a CMIP primitive is received. PR__REM identifies the incoming request, extracts the data contained in the PDU, and then properly informs PR__LOC of the event. In such a way the command originated from the OS can be executed.
•
•
Comparison between MAX and ETS! management architectures
•
Both the functional and the physical architectures of the MAX management system have been defined according to the relevant ETSI specifications. Regarding the functional architecture, it should be noted that by using MAX nodes a distributed MSS can be implemented. Therefore, the MMF are distributed over the MSS nodes and no centralized MF or OSF is envisaged within the MMF (see Figure 8). As far as the management of the AF's MAN nodes is concerned, an ETSI path G plus path F solution (see Figure 8) is adopted in MAX for NMF to TMN OSF connection. Since no centralized MF is present in the MMF, only communication facilities are provided by the MSS for the management of the MAN nodes. The solution adopted in MAX is the simplest and more integrated among those identified by ETSI. While discussing software implementation, the
MAX OSF Eavimamcnt
As a consequence of the adopted solution, no differences are requested in the implementation of the management applications in the MAX nodes depending on their use in AFs or MSSs. All the management communications employ the MAX network as data communication network. From the above analysis, it is clear that the MAX management system is being developed in alignment with the ETSI current specifications (and therefore with CCITT TMN recommendations). The compliance with standards will enable easy connection with other management systems, providing operators with the desired integration capabilities.
SF~
i
the MAX Operations System (MOS) can be seen as the physical implementation of the TMN OSF of the controlling the (MAX) MAN the AFs MAN Nodes (MAX nodes) are managed by the TMN OS (MAX OS) through the MSS via 'short stack" QMAN interfaces the MSS itself(here constituted by a collection of MAX nodes) is connected to the TMN OS (MAX OS) via either a Q o r a QMANinterface (depending) on the NAM used for the connection of the OS to the MAX network which implements the MSS).
!
I
X
OSF
q"
..
°.
MMF
124
m
NMF
Fipre8 MAX management functional configuration (with implicit DCF)
computer communications volume 16 number 2 february 1993
MAX: advanced network management capabilities in a standard MAN: G Carabell6 et al.
Physical Architecture
Qmm I
i
MAX~ = g m m
Mss
Figure 9
AF2
The C N M S manager could be a functional block constituted by specific customer management functions. In this case anxMc (MC MAN CNMS) reference point is envisaged between the CNMS manager (in the customer environment) and the CNMS agent (in the public network management system). If the customer is not provided by CNMS manager functions, he can access the CNMS via Customer Terminal (CT) functions. This block is connected to the CNMS manager, belonging to the MAN CNMS access functions, through afMc reference point. The CNMS manager in turn is connected to the CNMS agent (in the public network management system) through an XMc reference point. The ETSI MAN CNM functional architecture foresees two possible solutions: 1
MAX management physical architectures
2 CUSTOMER NETWORK MANAGEMENT Taking into account new requirements emerging from business customers, a further management area has been considered in CCITT, ETSI and MAX. This area, called Customer Network Management (CNM), covers all aspects related to communications between customers (or their own management system) and the public network management system. E T S ! view of C N M Referring to the ETSI specifications, the MAN Customer Network Management Services (MAN CNMS) are services that permit interaction between a customer and the MAN management system: the customer can handle (get, set and change) related information or request some MAN management actions through a proper interface. In any case, a CNMS user should not be able either to affect another customers traffic or to reach data pertaining to another user. MAN customers can only access well defined CNMSs on the basis of the subscribed rights. According to the relevant ETSI documents, the provider of these services, namely the CNMS agent in the MAN management system, can either accept or refuse customer requests (on the basis of a customer identification process and control of related rights). When the request is accepted, the agent selects the proper information retrieval and processing to offer the CNMS to the customer, namely the CNMS manager. To this end, the CNMS agent interacts with the proper operation system function blocks, which collect and control the required information. These interactions are not depicted in Figure 10, which instead shows one of the functional and physical architectures defined by ETSI for MAN CNM.
customer connected through a XMc interface (based on CMIP application layer): customer connected through a FMC interface (simplified terminal interface). Two sub-cases are envisaged for the first solution: The CNMS manager in the customer domain accesses the CNMS agent belonging to the MAN/ public network management system. The CNMS manager in the customer domain accesses the CNMS agent in a dedicated MAN CNMS provision unit (MC-PU). This unit interacts with the MAN/public network management system via proper interfaces (X interface when the MC-PU and the OSs belong to different responsibility domains, while it is not defined when they belong to the same responsibility domain). The MC-PU could be owned by the MAN provider or by a VASP (Value Added Services Provider).
Three sub-cases are envisaged for the second solution: The customer, via the Customer Terminal (CT), accesses the CNMS manager in the MAN/public network management system, which in turn interacts with the CNMS agent. This solution is depicted in Figure lOa. The customer, via the CT, accesses the CNMS manager in a dedicated MAN CNMS access unit (MC-AU). This unit interacts with the CNMS agent belonging to the MAN/public network management system via an XMC interface. The MC-AU could be owned by the MAN provider or by VASP. The customer, via the CT, accesses the CNMS manager in a dedicated MC-AU. This unit interacts with the CNMS agent in a MC-PU, which in turns interacts with the MAN/public network management system via proper interfaces. Both ii
computer communications volume 16 number 2 february 1993
125
MAX: advanced network management capabilities in a standard MAN: G Carabellb et al.
[MAXC me,1 Tenn.,
rC SM='g. 1
;
J
,'
f
'
[,in NCME Appl.,I
'
L,
TenninaJ
in OSF Appl. )
x
MC
Customer
[ CNMAge= "1
t
MC
CNMS
[
CNMS Agent MAN Management Functions
Manager
I
N
I
Customer
'
MAN CNMS
]
M~nagemcnt
'
Access
I
f
MC
MC
]
,, 'I
NCME
' ' MC Type !
MAXCr
C•l.qtomcr•
MAX Node
I
OSF I ' MAX OS X MC Type
MAN Management System
Domaia
i
@ill
I I
,
'
F
/
I
~
t
I
MC
X
MC
MC-AU and M C - P U could be owned by the MAN provider or by VASPs.
MAX CNM In the projects the provision o f C N M S has been studied 8 even if, due to budget limitations, the implementation o f related facilities is at the m o m e n t not guaranteed. In the MAX system customers can access C N M S services via both XMc-type and FMc-type interfaces. In the former case, a p r o p e r NAM connects the customer C N M S m a n a g e r to the MAX network, providing a c o m m u n i c a t i o n path to the MAX OS, where applications playing the role o f C N M S agent are implemented. In the latter case (depicted in Figure lOb) dedicated terminal-links are envisaged a m o n g customers terminals and the MAX node controller, where applications playing the role o f the C N M S managers are implemented. As in the first case, the C N M S managers converse with the MAX OS ( C N M S agent).
126
;~.~
=
Figare 10 (a) ETSI and MAX customer network management comparison of equivalent functional architectures: (b) ETSI and MAX customer network management cornparian of equivalent physical architectures (CT: Customer Terminal: M: MAN CNMS manager: A: MAN CNMS agent)
CONCLUSIONS This paper has illustrated the features o f the MAX m a n a g e m e n t system, covering both architectural and functional aspects. A description o f the system software architecture has been given, with particular emphasis on the advanced tools and methodologies employed. Taking ETSI d o c u m e n t a t i o n as the reference point, a detailed analysis has shown that MAX is aligned with the standards, and can represent a real implementation o f the ETS| concepts.
REFERENCES I 2 3
4
Gad, L and Vereelli0R 'Metropolitan area network management issues', RACE Conf., Paris, France (1991) ETS! ETS 300211 Metropolitan Area Network l%'nciples and Architecture, ETSI, France (1991) IEEESO2.6Standard, DistributedQueueDualBussubnetworkofa MAN. IEEE. New York. USA (1991) CCITT Draft Recommendation M.3010 l~inciplevfor a Telecommunications Management Network. CCITT. Geneva. Switzerland (1991)
computer communications volume 16 number 2 february 1993
MAX: advanced network management capabilities in a standard MAN: G Carabellb et al. 5 6
CCITT Draft Recommendation Q.311 Lower Laver Protocol Profiles for the Q3 Interface. CCITT, Geneva, Switzerland (1992) CCI'Vr Draft Recommendation Q.312 Upper Layer Protocol Profiles for the Q3 Interface. CCITT. Geneva. Switzerland (1992)
computer communications volume 16 number 2 february 1993
7 8
CCITT Recommendation G.773. Protocol Suites for Q Interfaces for Management of Transmission System. CCI'FI', Geneva, Switzerland (1990) Gavi, L and Veredli, R 'User management services in a metropolitan area network environment'. Prac. EFOC/LAN. London. UK (1991)
127