The Concepts and Principles to Design a Performance Management Framework for the ODP-NGN

Transcription

1 The Concepts and Principles to Design a Performance Management Framework for the ODP-NGN D. Magaya and H.E. Hanrahan Centre for Telecommunications Access and Services University of the Witwatersrand, Johannesburg. DMagaya@CellC.net Abstract: The provision of information and communication anytime, anywhere and in any form becomes a reality through the introduction of Next Generation Networks (NGN). The NGN is an evolving reference architecture, which defines a QoS enabled and integrated network to carry realtime, multimedia, multiparty and distributed services. We refer to a NGN that uses RM-ODP concepts and principles as an ODP-NGN. A weakness of the ODP-NGN is the complexity of management. Unfortunately, there is a lack of framework that simplify the design and development of ODP-NGN management applications. This paper is part of an on-going project which aims to develop a management framework for the ODP-NGN. This paper presents the concepts and principles that can be used to design a management framework for the ODP-NGN. The RM-ODP enterprise, information and computational view points are employed for this purpose. An experiment in which management application developed using the PMF is used to manage parts of the SATINA platform will be carried out. Keywords: TINA, DPE, RM-ODP, Concepts, Principles, Performance Management, Framework, Objects, Architecture. I. INTRODUCTION The next generation network (NGN) is an evolving reference architecture, which uses a QoS enabled and integrated transport network to carry real-time, multimedia, multiparty and distributed services. The NGN service architecture comprises a set of concepts, principles and guidelines for constructing, deploying, operating services in the NGN environment. Although the NGN provides an advanced architecture, its disadvantage is the heterogeneity of services and transport networks. The NGN addresses this problem through the use of Open Distributed Processing (ODP) concepts to implement a distributed processing environment (DPE) that abstracts complexities of the underlying heterogeneous networks. A NGN that uses ODP concepts is referred to as an ODP-NGN. Although the ODP-NGN employs better and advanced concepts in its service architecture (SA), unfortunately, it introduces complex Performance Management (PM) problems. For instance, the use of ODP leads to PM problems inherent in both open systems and distributed computing environments. A companion paper presents a framework that is used to simplify the design and development of ODP- NGN PM applications for the ODP-NGN [105]. A management framework (PMF) is a reusable design of all or part of a system that provides some generic guidelines and basic functionality in a specific domain such that applications developers can customize and increase functionality by extending the framework. The ODP-NGN PMF is made up of a hierarchy of abstraction levels as shown in figure 1. A detailed explanation of figure 1 is found in [105]. Framework Definition PM Concepts, Principles, Policies PM Facilities PM Applications ODP View Points and ODP-NGN system Formal Specification Techniques Programming Language Figure 1. The Performance Management Hierarchy of Levels The second level comprises of the concepts, policies and principles that are employed to define a PMF. The RM-ODP View Points and the ODP-NGN system definition are used for this purpose. The benefits of using viewpoints as an abstraction method are explained in [105]. The ODP-NGN PMF utilises the first three viewpoints of the RM-ODP namely, the Enterprise, Information and Computational viewpoints. The other view points are outside the scope of the project. The rest of the paper is organised as follows. Sections II, III and IV present the enterprise, information and computational view points respectively. Section V provides the ODP-NGN network definition i.e. the details of the CA, NA and SA. Section VI presents the conclusions. II. THE PMF ENTERPRISE VIEW POINT The Enterprise View Point (EVP) defines PM objectives, rules, roles and policies from an enterprise perspective. The scope refers to the extend to which

2 the managed system is influenced by the management system. The roles refer to the task performed by the management system to ensure that the elements specified in the scope meet the management objectives. Policies refer to the broad generic rules that must be met in the process of achieving the management objectives. Enterprise (PM) specifications can be placed on the enterprise objects and/or their interactions. The EVP of the PMF shows the functions that are provided without prescribing how these functions are implemented. An EVP is the at the most abstract level of detail appropriate for modelling the ODP-NGN PM system concerns. A system is a grouping of objects intended to achieve a specified management purpose. Roles of objects within the system are governed by policies where a policy is permission, prohibition or obligations. The EVP is concerned with performative activities that influence the PMF policy. These are activities that result in obligations, prohibition or permission. The ODP-NGN PMF EVP is effected by designing a template which is populated according to the PM requirements (table 1). The table variables can be changed to suit the particular ODP-NGN PM circumstances. The EVP PM Modelling Template The EVP Variable User Inputs i. Performance system members ii. PM objective for system iii. PM scope for system and members iv. PM role for system and members v. PM policy for system and members Obligations Permissions Prohibitions Table 1: The EVP PM Modelling template The EVP may also specify management domains. A domain gives the means for describing management policy for a group of managed objects rather than having to do this for each object. III. THE INFORMATION VIEW POINT The Information View Point (IVP) models relevant information that flows between service components, users, network providers and service providers. Essentially, the IVP seeks to define how management is specified relative to information flow in the system. This viewpoint specification captures the enterprise level PM requirements and information required to support PM policy (table 2). The IVP allows the modelling of information in an application, technology and system independent manner. It facilitates the production of a PM information model for the ODP- NGN. Once the information model is available, the data can be manipulated in an application specific manner. Table 3 relates a PM objective to the corresponding information model. For instance, an objective to reduce access delay requires an information model for delay response time. An analysis of the ODP-NGN PMF IVP results in the definition of the information objects. There are many ODP-NGN information objects that can be identified and the relationship between them established using concepts such as GDMO, GRM and OMT[80]. PM Objective IVP information Model Reduce Access Delay Delay Increase Service Speed Throughput Reduce Service Variability Jitter Table 2: The Information View Point Objectives The key elements of the ODP-NGN PMF information view points are the relevant component, the relevant event and the relevant packet unit. 1. The Performance Relevant Component The Performance Relevant Component (PrC) represents the ODP-NGN component that is affected by commands. Table 3 shows the typical PrC in the service architecture and computational architecture. Monitoring will be done on the PrC. The PrC represents a managed object. PrC Consumer Retailer SA Consumer Domain Terminal Retailer Domain Server CA Node Capsule Service COG Node Capsule Service COG Table 3: The relevant components 2. The relevant event We propose to measure the PrC behaviour in terms of events, which we generically call a Performance Relevant Event (PrE). The PrE reflects changes that are of significance to management. Event driven monitoring is based on obtaining information about the occurrences of PrEs which provide a dynamic view of the ODP-NGN activities since only data relating to changes in the system are collected. The PrE is used to model and calculate time-based specifications e.g. the response time of a service access request. We acknowledge that an approach based on defining a Performance relevant Status (PrS) and using the status to measure PrC behaviour can also be employed. A more elaborate solution can be developed by combining the PrE and PrS to determine PrC behaviour. However we decided to use PrE only for two major reasons. Firstly, it is simpler since we only have to deal with a change in status (PrE occurs whenever there is a change in status). Secondly, the tools (PEPA and fuzzy logic) used in the PMF Facilities modelling can be easily related to the PrE. 2. The Performance relevant Packet Unit (PrPU)

3 We introduce the concept of a PrPU (Performance relevant Packet Unit). A PrPU is any packet of data e.g. cell, frame, byte, message or octet which posses some relevance information. The size of the PrPU is undefined because it depends on the data type, the application type, the architecture etc. The PM facilities such as monitoring are performed on PrPU. The PrPU is used to model and calculate flowbased specifications e.g. throughput. The information obtained from the PrPU is used to develop a specification (figure 1). Input/Output layer Softer PM Layer Soft PM Layer Hard PM Layer Profile - Characteristic User PM Specifications Good Audio, Clear Colour, Fast Speed Set of Selected Characteristics Audio - {throughput, delay,jitter} Video - {throughput, delay, Jitter} - Set of PM Measurements Delay - {Maximum, Mean, Minimum} Throughput - {Maximum, Mean, Minimum} Measurement - Measured PM values response time, delivery time, frequency Figure 1: The Performance specification hierarchy Figure 1 shows a model for the PM profiles, signatures and measurement. The input/output layer shows how the user specifies using linguistic variables such as audio, colour, and speed and waiting time. These specifications are made at the input/output interface or the terminal equipment. The softer control layer maps the user specifications into profiles. The soft control layer maps the profile information into characteristics. The hard control layer maps the characteristics into real PrPU measurements. Measurement: A measurement is an identifiable or measurable aspect of a PrE. Several measurements such as response time, frequencies etc constitute the hard PM layer of information. Characteristic: A characteristic is a set calculated or derived from one or more measurements. Characteristics such as delay, throughput etc form the soft PM layer Profile: A profile is a set of one or more characteristics per given application or data stream. Profiles such as video throughput, video and delay form the softer PM of information. IV. THE COMPUTATIONAL VIEW P OINT The Computational View Point (CVP) is a progression of the EVP and the IVP described in sections (II) and.(iii) respectively. The CVP addresses the functional decomposition of the PM system into units of distribution and the interactions required to manage. The units of functional decomposition are called objects and are used to develop PM applications. The three object definitions that we explore are: - Object: An object is a unit of encapsulation and provides abstraction. Its characterised by its behaviour and its state. Encapsulation means that changes in the state can only occur as a result of internal actions or interactions [11,80,85]. An abstraction means that the internal details are hidden from other objects, allowing them to be implemented in different ways. - Object behaviour and state: Behaviour is something that happens and is a set of one or more actions [80]. The state of an object at any given time is the information that influences the set of all actions in which the object takes part [85]. - Object Interface: The notion of an interface is key to distributed systems particularly those based on object oriented technology. Interfaces are behaviours of objects when focus is placed on a subset of the interactions of the objects i.e. an interface is an abstraction of object behaviour [68,85]. The behaviour exhibited by the interface is what we observe when all actions outside the set of observable actions that compose the interface are made internal. Like objects, interfaces can be instantiated or deleted. Objects can only interact provided that their interfaces allow them to do so. 1. The PMF object model The PMF object model refers to three object categories which are; Managed Objects (M d O), Manager Objects (M r O) and Management Objects (M t O) (figure 2). This project primarily focuses on defining M r O and M t O objects. Managed objects (M d O) : The M d O, is an abstraction of the CA, NA or SA objects from a PMF point of view. It represents the resources of interest in the aspects relevant for management purposes. For an example, the objects of a service implementation in the SA, the network elements in the NA and the capsule in the CA. Each M d O has got a service interface that sends management operations on to the underlying resource and that recjeives management information such as attribute values and notifications. A managed object is an entity to which a management policy applies and whose behaviour can be monitored or changed by a manager object Manager Objects M r O : The M r O is an abstraction of the management application as seen from a PMF point of view. Manager objects administer one or more M d Os through their management interfaces. Manager objects monitor the activities of managed objects, make management decisions based on that information, and perform control actions on managed objects. A manager may be human or automated. Managers may also be managed objects for higher level managers. Specific manager objects are the monitoring, control and analysis facilities [105]. Management Objects M t O: They represent the PMF from an implementation perspective. They give the possibility to intervene in the management process by the authorized user. To this end, management objects provide graphical user interface for the human user

4 and mediate user input to manager object as well as information emitted from the manager. Manager Object Managed Object Performance Relevant Component Management Object and the node that supports the capsule. Figure 4 shows the three types of operations provided by a management interface which are: - Control commands - Requests for status information - Monitoring information generated by the object The control commands are directed by the manager object to the managed object; requests for information are issued by the managing object and result in a reply from the managed object. Monitoring information generated by the object allows the transfer of unsolicited notifications from the managed object to the manager. Figure 3: The PMF Computational Objects 2. The PMF Object Behaviour and interface Specification Management Interface Control Commands Status Requests Monitoring Information We use the template object model (figure 3) to describe the ODP-NGN PMF object behaviour and interface specifications. Interfaces in the computational viewpoint consist of a signature, a profile, behaviour and an environment contract. An interface signature and profile represent the syntactic aspects of the functionality (behaviour) found in the interface. The behaviour specification represents what the effects are of invoking the actions described in the signature. The environment contract represents aspects associated with the interface that its signature and behaviour specification alone do not capture. These might relate to management contracts Object Template Object Behaviour Spec. Contract Specifications M x O, Function,Method PM Object M x O Template PM Binding Object End-to-end PM Interface Template Object Interface Spec. Contract Specifications Jitter, Throughput, Delay PM Object Figure 4: The Performance Management Framework Object template The object behaviour and interface specification determines whether an object behaves as a M r O or as a M d O. We describe the management interface, operational interface, stream interface and binding interface. The design of management applications requires the specification of management interfaces. The level of specification granularity is depends on the requirements of the management application. For instance, the management application may require behaviour modification which entails, invoking management operations on individual services, the objects that build the applications, the cluster that contains the object, the capsule that contain the cluster Managed Object Operational Interface Information Processing Operations Figure 5: The managed Object Interfaces The second interface shown in figure 5 is an operational interface. The Operational Interface supports the normal information processing operations, fulfilling the main purpose of the service provided by the object. 3.. The M x O PMF Contract PM is defined and managed using environment contracts of the object behaviour and its interface specifications. The environment contract expresses the requirements that have to be fulfilled and it addresses issues such as of objects and indications on how behaviour can invalidate the contract. Every M x O has got a management contract that is a definition of the access rights for attributes, executable operations and imitable notifications. Thus a contract object controls the transparency of management services interface with respect to a certain user or user role and a dedicated service. There are a few things that form part of a management contract and these are, the relation, the requirements, the capabilities and the offers. The contracts are based on signatures and profile i.e. a contract to meet given signatures or profiles (figure 1). V. T HE ODP-NGN DEFINITION An essential part of the concepts, principles and roles implementation layer (figure 1) is a framework that defines the ODP-NGN. A detailed definition of the ODP-NGN is provided in [105]. The ODP-NGN can be sub-divided into three architectural components which are, the computational architecture (CA), network architecture (NA) and service architecture (SA). RM-ODP CA NA SA

5 Enterprise Model Information Model Computation model The purpose and of scope of in the CA A model of the information for the CA. The computational objects required to manage the CA. The purpose and of scope of in the SA A model of the information for the NA. The computational objects required to manage the SA. The purpose and of scope of in the SA A model of the information for the SA. The computational objects required to manage the SA. Table 4: The PMF view points and the ODP-NGN architecture components Table 4 illustrates how the RM-ODP view points are applied to the components of the ODP-NGN from a PMF concepts, policies and principles perspective. The view points are applied to the ODP-NGN S CA, NA and SA. 1. The SA, CA and NA Performance management The SA management The ODP-NGN and TINA service architectures are similar in that they provide a framework to offer a generic set of functionalities in a stake-holder and service independent manner. This is achieved by defining service components [1]. Performance management in the SA is achieved through the management of service components to meet the required specifications. The SA specifies components that provide a framework for subdividing the functionality of ODP-NGN systems. The service components are high-level abstractions which can be decomposed into COs and COGs. The CO is defined as a unit of distribution over the DPE node. In cases where the service component completely maps to a CO, it means a single DPE node supports the service component functionality. The CO can be grouped into Computational Object Group (COG) which is shown in figure 15. COGS are not a unit of DPE distribution but are defined in terms of their internal COs and/or COGs. Describing the CO types that form the group specifies a COG type. However, the COG do not encapsulate their internal structure. Service components and their interfaces map into COs and COGs and CO interfaces and COG group contracts respectively (figure 6). There are several CO mappings of a service component thus allowing for flexibility in design. Each mapping may provide some benefit to the designer e.g. improving system by allowing a special type of deployment of COs. Figure 15 shows an example of a COG. The SA management is effectively achieved by managing the COG provided that the COG maps in the SA service components which are of relevance i.e. PrCs. Contract A COG 1 CO1 COG 2 CO2 CO3 Contract B Figure 6: A Computational Object Group CA Performance Management: The CA management is subdivided into the management of the software, DPE, computing systems and the kernel transport network. DPE management includes the management of the components of the DPE model i.e. the management of nodes, clusters, capsules and eco. Computing systems management includes the management of computing systems that are supporting the DPE and that provide the communications and computing capabilities used by the DPE, generically called the Native Computing and Communications Environment (NCCE). The kernel transport network deals with the management of the telecommunication network that is interconnecting the DPE nodes. The software management deals with activities such as deployment, configuration and instantiation of software. The ODP-NGN PMF is limited to the of the nodes, clusters and capsules. The NA management The network architecture comprises of the resources required to transport, transmit, switch route and relay the ODP-NGN traffic. The TINA network resource architecture provides a comprehensive description of the NA. Performance management in the NA involves the setting up of appropriate network elements, network layers and network domains to achieve the specified QoS. VI. CONCLUSION The concepts, principles and policies required to design an ODP-NGN PMF have been presented. The RM-ODP enterprise view point, information view point and computational view point are used to achieve this objective. The principles that define the ODP-NGN components are presented. The TINA computational architecture, the network architecture and the service architecture are employed. Experimental work to verify the ODP-NGN PMF concepts and principles is in progress. VII. REFERENCES [1] Service Component Specifications, Version 1.0b, TINA- Consortium, January 1998 [2] Open Distributed Processing- Reference Model Quality of Service. ISO/IEC JTC1/SC7 N1996, [3] IETF PINT, bell-labs.com/mailing-list/pint [4] SofStswitch Consortium, Softswitch.org CO4

6 [5] Mapaey M. TINA for Service and Advanced Signaling and Control in Next-Generation Networks. IEEE Communication Magazine, October [6] J. Sperryn, S. Mohapi, R. Achterberg, H.E. Hanrahan, Performance Issues and Load Monitoring in the TINA ntifiable DPE. TINA Conference 2000, Paris, [7] Milosevic Z., Phillips M. Some new considerations in open distributed Environments. IEEE Publication pp [8] Blair G., Cloulson G. Standards and Platforms for Open Distributed Processing. IEEE Com. pp , [9] Roberts T., Hargrave P. A Vision of the Next Generation Public Network Architecture. IEEE, pp.1-5, [10] Sessions R. COM and DCOM: Microsoft s Vision for Distributed Objects. J. Wiley & Sons, ] Koskimies K., Mossenbock H., Designing a Framework by Stepwise Generalisation. University of Linz [32] Pryce G.N., Component Interaction in Distributed Systems. PhD Thesis, University of London, [33] Lorcy S., Plouzeau N., Jezequel J., A Framework Managing Quality of Service Contracts in Distributed Systems. Proceedings of TOOLS-26 98, August [35] Hillston J., Herzog U., Hermanns H., Stochastic Process Algebra A Formal Approach to Performance Modelling. [36] Hillston J., Gilmore S., Clark G., Specifying Performance Measures for PEPA. IEEE, [37] Anglano C. Performance Modelling of Heterogeneous Distributed Applications. MASCOTS [38] Ribaudo M. Understanding Stochatic Process Algebras via their Stochastic Petri Nets Semantics. ESPRIT- BRA Project number 7269 QMIPS, 8 Sept [39] Lakos C.The Object Orientation of Object Petri Nets. [40] Hillston J., Herzog U., Hermanns H., Stochatic Process Algebras: Integrating Qualitative and Quantitative Modelling. [41]Gokhale S.S., Trivedi K.S., Analytical Modelling. In the Encyclopedia of Distributed Systems, Kluwer Academic Publishers, [42] Anagnostakis K.G., Vasilakos A.V., Pitsillides A., An Evolutionary Fuzzy Algorithm for QoS and Policy- Based Inter-Domain Routing in Heterogeneous ATM and SDH/SONET Networks. [43] Bohme T., Unger H., A fuzzy Based Load Sharing Mechanism for Distributed Systems. International Computer Science Institute, TR August [44] Godjevac J., Comparison between PID and Fuzzy Control. Ecole Polytechnique Federale Lausanne, Internal Report R [45] Tsang D.H.K., Bensaou B., Lam S.T.C., Fuzzy Based Rate Control for Real-Time MPEG Video. [46] Smith D.G., Fontaine M., Fuzzy Logic for Controlling Call Admission in ATM networks. [47] Haring G., Luthi J., Fuzzy Queueing Network Models of Computing Systems. [48] Nahrstedt K., Li B., A Control-Based Middleware Framework for Quality of Service Adaptations [52] Pooley R., Hillston J., Stochastic Process Algebras and their Application to Performance Modelling. [53] Hillston J., A Compositional Approach to Performance Modelling. PhD Thesis, University of Edinburgh, January [56] Sloman M., Chalmers D. Survey of QoS in Mobile Computing Environments. Report 98/10, Feb [70] Kim J-S., Hong J. W-K., A CORBA-Based Quality of Service Management Framework for Distributed Multimedia Services and Applications. [71] Milosevic Z. Service provisioning and Quality of Service Metrics: the TINA enterprise viewpoint. [72] Popien C., Meyer B. Defining Policies for Performance Management in Open Distributed Systems. [73] Znaty S., Boutaba R. An Architectural Approach for Integrated Network and Systems Management. [74] Scourias J. Distributed Object Management Systems. IEEE Transactions, September [75] Clark G. Formalising the Specification of Rewards with PEPA. Proceedings of the 4 th Workshop on Process Algebra for Performance Modelling, July [76] Bernardo M. Using EMPA for the Performance Evaluation of an ATM Switch. [79] Derrick J., Bryans J.W., Bowman H., Analysis of a Multimedia Stream Using Stochatic Process Algebra. [82] Trommler P., Schade A. A CORBA-Based Model for Distributed Applications Management. Proceedings of DSOM 96, [83] Boutaba R., Bochmann G.V., Dini P. Performance Evaluation for Distributed Systems. IEEE Proc [84] Kramer T.J., Magee J., Sloman M. An Architecture for Managing Distributed Systems. IEEE Proc [85] de Pina X. R., Oueichek I., An Object Model for Distributed Systems Management. IEEE [89] Genilloud G. An Analysis of the OSI Systems Management Architecture from an ODP Perspective. IEEE Transactions [90] ITU-T Recommendation G.851.1, Management of the Transport Network Application of the RM-OPD Framework. [91] Sorenson P., Liu L., Hoover J.H., Froehlich G. Designing Object-Oriented Frameworks. [92] Sloman M., Lupu E.C. Towards a Role Based Framework for Distributed Systems Management. [93] Sloman M., Mansouri-Samani M., Monitoring Distributed Systems (A Survey) Imperial College of Research Report No. DOC92/23, 22 September [94] Nuemair B., Keller A. Distributed Applications Management based on ODP View Points and CORBA. Proceedings of the 4 th Worksop of the Open View University ASSOCIATION, April [95] Arnold D., Bond A. Visualising Service Interaction in Open Distributed System. CRC for Distributed Systems Technology, University of Queensland, December [96] Znaty S., Arsenis S., Sclavos J., ODP Viewpoints of QoS Management Application [97] Aksit M., van Sinderen M., Ferreira L., van Halteren A., Bergamans L. A QoS-Control Architecture for Object Middleware. [98] Dssouli R., von Bochmann G., Hafid A. Distributed Multimedia Application and Quality of Service : A Review. Electronic Journal on Networks and Distributed Processing. NO. 6, , pp1-50. [99] Chein A., Taura K. A heuristic Algorithm for Mapping Communication Tasks on Heterogeneous Resources. IEEE Transaction [100] Parekh S., Gandhi N., Helleerstein J., Tilbury D., Jayram T., Bigus J. Using Control Theory to Achieve Service Level Objectives in Performance Management. IEEE Transactions 2001 [101] Jalnapurkar A., N. Shousha C., Petriu D. Architecture based Performance Analysis Applied to a Tecommunication System [103] Kauffels F-J. Network Management Problems, Standards and Strategies.Addison Wesley Ltd, [105] Magaya D., Hanrahan H. A Performance Management Framework for Signalling and Bearer Traffic in an NGN Deployed using Open Distributed Systems Concepts. SATNAC 2001.