1 / 8

Rule-based Systems Programmability

Rule-based Systems Programmability. Michael Smirnov smirnow@fokus.fraunhofer.de. Roadmap. What‘s a rule-based system? Behaviour definitions: safe and secure Run-time updates Self-organisation of rule-bases Impacts and new architectures. What‘s RBS?.

danno
Télécharger la présentation

Rule-based Systems Programmability

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Rule-based Systems Programmability Michael Smirnov smirnow@fokus.fraunhofer.de NeXtworking’03 June 23-25,2003, Chania, Crete, Greece The First COST-IST(EU)-NSF(USA) Workshop on EXCHANGES & TRENDS IN NETWORKING

  2. Roadmap • What‘s a rule-based system? • Behaviour definitions: safe and secure • Run-time updates • Self-organisation of rule-bases • Impacts and new architectures NeXtworking’03 June 23-25,2003, Chania, Crete, Greece The First COST-IST(EU)-NSF(USA) Workshop on EXCHANGES & TRENDS IN NETWORKING

  3. What‘s RBS? • RBS behaviour is defined by openly exposed rules rather than by ‘hidden’ state transitions (as in client-server) • RBS is typically a control plane implementation that controls invocation of Functional Primitives (FP), it has zero functionality • RBS is typically securing FP invocation, we want to make RBS securely programmable Rules Rules BD Events Rules Rules Events Client-Server Messages e.g. midcom FP FP Data traffic NeXtworking’03 June 23-25,2003, Chania, Crete, Greece The First COST-IST(EU)-NSF(USA) Workshop on EXCHANGES & TRENDS IN NETWORKING

  4. Common framework Service Domain (SD) Behaviour Definition Design SD Component SD Component request (T,a) BA+ | Ob (a) Su | BO+ EAA EAS Security Policy Design M | NO+ M | NO+ Monitoring Policy Design Legend: Su - subject, Ob – target object; M – montor; BO – behaviour obligation; BA – behaviour authorisation; EA – event authorisation; NO – notification obligation NeXtworking’03 June 23-25,2003, Chania, Crete, Greece The First COST-IST(EU)-NSF(USA) Workshop on EXCHANGES & TRENDS IN NETWORKING

  5. Safe and secure behaviour updates • Ruling behaviour • Filtering, classification, SLA conformance, etc. • Can we also define new behaviours for run-time service creation? • Programmability: • Creation of new services • Service: A Logical Element that contains the information necessary to represent and manage the functionality provided by a Device and/or Software Feature. A Service is a general-purpose object to configure and manage the implementation of functionality. It is not the functionality itself [DMTF] • Responding to the unexpected • Designing security policies and a framework for policy management that will allow necessary access to systems and data in previously unplanned ways, and by persons and systems not normally permitted to do so[URL http://crue.isi.edu/research/report.html] NeXtworking’03 June 23-25,2003, Chania, Crete, Greece The First COST-IST(EU)-NSF(USA) Workshop on EXCHANGES & TRENDS IN NETWORKING

  6. Run-time updates • Need to change rule-base at run-time • Conflicts with already installed rules • Feasibility conflicts • Local and global conflicts • Possible approach: conflict resolution rules • Convention? Yes, but allowing proof-based engineering • Automatic conflict resolution is possible • Do we need to chnage the world? • Need also to detect and resolve automatically rules violation • Rule-base auditing! NeXtworking’03 June 23-25,2003, Chania, Crete, Greece The First COST-IST(EU)-NSF(USA) Workshop on EXCHANGES & TRENDS IN NETWORKING

  7. Self-organisation • The need to have high performance of rule bases • E.g. rule heaps optimised for usage frequencies • Rule injector has to be synchronised with a rule-base • Rule life-cycle management is not feasible • Too many potential rule injectors • Want to have a radically distributed system • Theory does exist (e.g. Adaptive Huffman, FGK) • Need negative modalities for rules • Security and safety: • Fine grained access control: • Event authorisation • Behaviour authorisation and obligation • Notification authorisation NeXtworking’03 June 23-25,2003, Chania, Crete, Greece The First COST-IST(EU)-NSF(USA) Workshop on EXCHANGES & TRENDS IN NETWORKING

  8. Impacts and new architectures • Even more promises in non-conventional infrastructureless networking • wireless sensor, ad hoc, ‘ambient’ networking, etc • New architectures: role-based architecture (RBA) • Role as a network service, controlling FP • event-action type of reasoning • role-based addressing • group communication within network control plane NeXtworking’03 June 23-25,2003, Chania, Crete, Greece The First COST-IST(EU)-NSF(USA) Workshop on EXCHANGES & TRENDS IN NETWORKING

More Related