A Formal Specification and Verification of TINA Architecture Service with The Accounting Management Module

1. A Formal Specification and Verification of TINA Architecture Service with The Accounting Management Module Abderrahim Sekkaki1,2, Carlos Becker Westphall2, Ivanise Volpato De Souza2, Leila Liliane Rossi2 1Departement de Mathématiques et d’Informatique. Faculté des sciences – Ain Chock. Université Hassan II, Casablanca, Maroc 2Network and Management Laboratory. Post-Graduate Program in Computer Science. Technological Center. Federal University of Santa Catarina. Florianopolis, Brazil GRES Décembre 2001 Marrakech Maroc

2. Index 1. Introduction 2. TINA Overview 3. Informal description of the TINA service architecture with the AcctMgmtCtxt Module 4. TINA Accounting Management Architecture and Components 5. Conclusion and Future Works 6. Most Important References

3. 1. Introduction • TINA is a comprehensive architecture for multi-service networks that will help multimedia communications and give access to information for business and private consumers. • TINA is based in a Distributed Processing Environment (DPE) and CORBA as infrastructure. • The service is carried out as distributed applications and provided within a distributed computing environment. • TINA has defined the Network Resource Architecture (NRA) that covers the management areas of connection, configuration, fault and accounting management (FCAPS).

4. 2.TINA Overview2.1 TINA Service Architecture

5. 2.TINA Overview2.2 TINA Service Management • The service management is associated by four conceptual axes: • Partitioning axis: TINA is partitioned into three layers (service, resource and DPE). • Functional axis: is represented most notably by FCAPS functions to support the FCAPS integrity of a service session;constructs such as management context and service transaction are provided. • Computational axis: represents computational support for management needs. • Life cycle axis: represents the life cycle issues, including service life cycle management and user (consumer) life cycle management.

6. 2.TINA Overview2.3 TINA Accounting Architecture • TINA accounting management consists of four cycles namely: Metering, Classification, Tariffing and Billing. • It introduces a concept of Accounting Management Context (AcctMgmtCtxt) associated with Service Transaction (ST). • The purpose of AcctMgmtCtxt is to guarantee that accountability can be preserved through a set of activities of distributed objects, which constitute the service.

7. 2.TINA Overview2.3 TINA Accounting Architecture • The Service Transaction (ST) concept consists of three phases: • Set-up phase: Is a phase of negotiation between the user and the provider (e.g. Tariff structure, etc.). The agreed scheme is submitted as AcctMgmtCtxt of the ST. • Execution phase: The service is being offered to the user, as it was specified in the first phase. The description of information of the service session is specified as a part of AcctMgmtCtxt. • Wrap-up phase: The service is concluded, account record or charging information may be sent to the user at the conclusion of the transaction, if specified in AcctMgmtCtxt.

8. 3. Informal description of the TINA service architecture with the AcctMgmtCtxt Module • Our system is constituted the basic components of the TINA service architecture and the AcctMgmtCtxt component • We illustrate just the interfaces describing the behavior of the TINA system by introducing the TINA accounting Management

9. 3. Informal description of the TINA service architecture with the AcctMgmtCtxt Module

10. 3. Informal description of the TINA service architecture with the AcctMgmtCtxt Module 3.1 LOTOS formal specification of the model • The specification demonstrates the behavior between the user domain and the provider domain through the Ret Reference Point which is separated in access and use. • The access part was totally specified while the use part only the accounting service was specified.

11. 3. Informal description of the TINA service architecture with the AcctMgmtCtxt Module 3.1 LOTOS formal specification of the model Specification1s[req,initial1,providerinitial,initial2,userinvite,providerauthenticate,initial3,userinitial,providernamedaccess,setup,useraccess,access1,accountingpull1,accountingpull2,access2,accountingpull3,access3,subscriberinfonotify,subscribernotify,providerpasbreq,accountingpushmanagement1,accountingpushmanagement2,accountingpush1,accountingpush2,accountingpushmanagement3,accountingpush3,accountingpush4,accountingpushmanagement4,accountingpush5,accountingpushmanagement5,accountingpush6,execution,wrapup1,wrapup2]:noexit behaviour 1s[. . .] where process 1s[. . .]:noexit:= req;(i;initial1;providerinitial;initial2;userinvite;providerauthenticate;initial3;userinitial;providernamedaccess;setup;useraccess;access1;accountingpull1;accountingpull2;access2;accountingpull3;access3;1s[. . .] []i;account[. . .] ) where process account[. . .]:noexit:= req;(i;subscriberinfonotify;subscribernotify;providerpasbreq;accountingpushmanagement1;accountingpushmanagement2;accountingpush1;accountingpush2;accountingpushmanagement3;accountingpush3;accountingpush4;accountingpushmanagement4;accountingpush5;accountingpushmanagement5;accountingpush6;execution;wrapup1;wrapup2;account[. . .] []i; 1s[. . .] ) endproc endproc endspec

12. 3. Informal description of the TINA service architecture with the AcctMgmtCtxt Module 3.1 LOTOS formal specification of the model • In the protocols specification , two processes are detailed : access and account processes. • In the process access the user authentication is performed allowing it to request services. • The process account provides the control and the accounting of the service used.

13. 3. Informal description of the TINA service architecture with the AcctMgmtCtxt Module 3.1 LOTOS formal specification of the model specification 1p [req,initial1, providerinitial, initial2, userinvite, providerauthenticate, initial3, userinitial, providernamedaccess, setup, useraccess, access1, accountingpull1, accountingpull2, access2, accountingpull3, access3, subscriberinfonotify, subscribernotify, providerpasbreq, accountingpushmanagement1, accountingpushmanagement2, accountingpush1, accountingpush2, accountingpushmanagement3, accountingpush3, accountingpush4, accountingpushmanagement4, accountingpush5, accountingpushmanagement5, accountingpush6, execution, wrapup1, wrapup2] : noexit behaviour  1p[. . .] where process 1p[. . .]:noexit:= access [. . .] >> account [. . .] endproc process access [. . .]:exit:= req;(i;initial1; providerinitial; initial2; userinvite; providerauthenticate; initial3; userinitial; providernamedaccess; setup; useraccess; access1;accountingpull1; accountingpull2; access2; accountingpull3; access3;acesso [. . .] []i;exit ) endproc process account[. . .]:noexit:= req;(i;subscriberinfonotify;subscribernotify;providerpasbreq;accountingpushmanagement1;accountingpushmanagement2;accountingpush1;accountingpush2;accountingpushmanagement3;accountingpush3;accountingpush4;accountingpushmanagement4;accountingpush5;accountingpushmanagement5;accountingpush6;execution;wrapup1;wrapup2;account[. . .] []i;1p[. . .] ) endproc endspec

14. 3. Informal description of the TINA service architecture with the AcctMgmtCtxt Module 3.2 Verification of the model • The verification is the formal test that the specification satisfies the desirable propreties using rigorous mathematical methods • To validate the formal specification we used the Encalyptus tool that integrates CADP and Aldèbaran.

15. 3. Informal description of the TINA service architecture with the AcctMgmtCtxt Module 3.2 Verification of the model

16. The Accountable Events Collecting component receives, collects and collates the accounting events associated with the Session Component. The Billing component may be automatically issued at the end of a billing period as negotiated and defined in the customer's contract (souscription). 4. TINA Accounting Management Architecture and Components 4.1 Architectural Model

17. Tariffing Recovery Module, it converts the collected accountable events to a charging record and stores it in the charging record database. Tariff Module, It calculates the tariff, using the charging formula according to the contract of subscription and stores it into the billing record. Usage Metering Collects and controls data acquisition concerned with the utilization of network resources generated by the LNC (Layer Network Coordinator). 4. TINA Accounting Management Architecture and Components 4.1 Architectural Model

18. The model of implementation uses the CORBA objects on Visibroker 3.04. The objects are defined as interfaces in IDL, so that they can access and be accessed by any other CORBA object regardless of the programming language. The data-bases register the events of Tariffing component while the service execution is carried out. . 4. TINA Accounting Management Architecture and Components 4.2 Definition of the AccMgmtCtxt Components

19. 5. Conclusion and Future Works • We presented in this paper an overview of TINA service architecture with the integration of the accounting management context module and their component. • By showing the formal description and validation of our model through the formal description LOTOS and using the Aldèbaran tool, we showed that the model is correct. • This model becomes thus,’basic model’ for the specification and the implementation of the others management functions in future works.

20. 5. Conclusion and Future Works • We described the accounting components in IDL, their roles and their interactions to accomplish the accounting functionality • This work provides an overview of the TINA concept specifying the accounting management context. We described accounting features, requirements, and some accounting issues.

21. 5. Conclusion and Future Works • We proposed the accounting management architecture specifying an architectural model that contains specific components such as AcctMgmtCtxt, Session Component, etc., covering different aspects of service control and management • In the future it will become necessary to implement a model that includes, in addition to management accounting, the management of security, failure and performance, so that the service mode will be in real-time and on a level of reliability defined by international standards

22. 6. Most Important References • Pavlou G. et al., “Issues in Realizing the TINA Network Resource Architecture”, in: Interoperable Communication Networks Journal,” Vol. 2, No. 1, March 1999. • Kristiansen L. et al., “TINA Service Architecture 5.0”, TINA-C, 1997. • Mulder H. et al., “TINA Business Model and Reference Points”, TINA-C, 1997. • Farley P. et al,. “TINA Retailer Reference Point Specification,” v. 1.0, TINA-C, 1998. • Abarca C. et al., “TINA Service Component Specification”, v. 1.0b, TINA-C, 1998.

23. 6. Most Important References • Kormann L. F. et al., “OSI Usage Metering Function for OSIMIS Management Platform”, in: Journal of Network and Systems Management, Vol. 4, No. 3, 1996. • Notare M. S. M. A et al, “Formal Design of a Platform for Telecommunication Heterogeneous Network Management”, DSOM’97 – Sydney, Oct 1997. • Sekkaki A. et al., ., “Development of a Prototype Based on TINA Accounting Management Architecture”, IEEE/IFIP International Symposium on Integrated Network Management. Seattle, Washington, USA, 14-18 May 2001. • Sekkaki A. et al, “Development of Accounting Management based Service Environment in TINA, JAVA and CORBA Architectures”, International Conference on Networking. July 9-13, 2001, CREF, Colmar, France. Springer LNCS (Lecture Notes in Computer Science).