Management of Dynamic Networks and Services Olivier Festor, Radu State

To cite this version:

Olivier Festor, Radu State. Management of Dynamic Networks and Services. Concordia Summer Workshop on Services Engineering and Network Management, Concordia Institute for Information Systems Engineering (CIISE), Aug 2003, Montréal, Canada, 23 p. inria-00107670

HAL Id: inria-00107670 https://hal.inria.fr/inria-00107670 Submitted on 19 Oct 2006

HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. Preamble : Management • All one does to keep the subject : Management of Dynamic – Healthy (up and running efficiently)

– Evolving positively Users Networks & Services • Fundamental operations Customers – Monitoring A sample of candidate technologies and a case study • Observe the subject at work ☺ – Control Objectives •Act Commerciaux Olivier Festor, Radu State (e.g. Gold • change or constrain the behavior of the Service) Ph.D., Hab. Ph.D. managed subject – Plan its evolution Services •Why ? (e.g. Virtual The MADYNES Research Team Private Network) LORIA – INRIA Lorraine – Service quality 615, rue du Jardin Botanique – Reduce costs 54602 Villers-lès-Nancy Network – With limited risks Elements France (e.g. PHD • Keeping the right level of quality configuration, {Olivier.Festor,Radu.State}loria.fr …)

Preamble : “management” wording in the presentation Tutorial Outline

• Growing Dynamics and their • SyncML-DM : an Approach for Management Impact on Management (20 minutes) Managing Dynamic Devices (60 min) – Dynamics – Representation Protocol for Device – Collapsing time scales Management Device Management Network Management – The need for automation and – Device Management Protocol autonomy – Standardized Objects Service Management Application Management – Management solutions for the – Device Management Tree dynamic world – Security for Device Management – Standardized approaches • Case studies (40 min) – Emerging alternatives Configuration Management – Ad hoc networks management • JMX : Dynamic Management Fault Management • Conclusion & discussion (15 min) for/through the Java World (60 min) Accounting Management – Basic Concepts Performance Management – Dynamic components • Attribute, method & notification Security Management level • Managed Object level – Remoting – Unless explicitly stated otherwise. – Implementations – Application domains & instrumentation patterns

Dynamic systems we are interested in : Dynamics Everywhere in Networks and Services ! • Topology related dynamics • In general : – Ad hoc networks : connectivity, reachability, autonomy – P2P networks & overlays : availability, presence, contribution, « A system that changes its state over time » topology [Jakobson 2001] – Mobile networks : mobility, power, usage • From a management plane point of view : • Capacity related dynamics – Constrained power environments « A system that changes its state over time in such a – Vertical handoff & Associated QoS variation way that changes cannot be detected or processed • Services & Service Infrastructure level dynamics – Software radio, extensible terminals efficiently by the management plane » – P2P networks & overlays – Because they occur too fast – Active networks : protocols change, functionality extension, … – Service platforms : service life cycle, hot deployment, update, … – Because they occur too often – Service usage : discovery, trading, late binding, lease, subscribtion – Because they occur too slowly • Device, Network & Service Management Dynamics – Because their processing requires changes in the – Online SLA parameters (re)-negociation management plane – Management interfaces tailoring –…

1 Collapsing Time scales Management solutions for the dynamic world

System • Static Management name status – Manager/MIB/Agent 1. Change to a static world and keep the … – Manual configuration of participating entities – Homogeneous management domains management frameworks as they are ! – Pre-sharing of management information models • 1-6 years to build a management interface – Size : 1 to a few hundred – Time Scale • Accept that you will at some time end in state #2 ! • Few minutes up to a few month • 1-8 years for information models (standards) 2. Consider management as a useless interface and service and stop working on it ! Jain, J2EE, … • Dynamic Management • Start thinking about other ways to QoSing – Infrastructures, services, usage & mobility • Trust webs, in-band probing, signalling, … – Multiple, shared evolving administrative domains – Variable information models and management interfaces 3. Make management as dynamic as the entities – Negociable & evolutive management functions – Size : 1 to several millions/billions it manages ! – Time Scale • Rethinking everything • ms up to a few seconds

New management solutions are needed!

Mgmt & dynamics (1): the static option Mgmt & dynamics (2): the empty chair option

• Networks and services do not need management anymore ! • « Many aspects of dynamic systems are often – They adapt themselves to the provided conditions perceived as static » [Jakobson 2001] – 90’s ALF philosophy with an extension to the active networks community • So lets consider them as static • As long as theses dynamic aspects do not alter the external enveloppe. • Keep the management frameworks as they are • But « Nature abhors a vacuum » • Mapping in the networking world – Benedict Spinoza (1632-1677) – Focus on the service or application level only – End2End monitoring & performance measurment – As soon as something becomes too dynamic : ignore It • Thus traditional management will be replaced by smart solutions • History tells us that this is not a good approach – From management to signalling • The case of an evolution : ATM VPC, SVC – Often micro-dynamics highly impact the world – DHCP was an evolution in IP address management • « Butterfly Effect » by E. Lorentz MIT (1961) • but not a sufficient one since DHCP needs to be managed and DNS is • Maybe not the best example … required too for the translation (Dynamic DNS is a partial solution) – In highly dynamic environments, even management of – Zeroconf, zerouter are other « management free » efforts within IETF the static parts becomes almost impossible using the • No management entity needed usual paradigms • Initially focused on IP address (unicast, multicast) and name assignment

• Because Unmanaged entities are part of the Chaos !

Mgmt & dynamics (3): make management dynamic Standardized approaches support

• Divide ut imperes! (Divide & conquer !) • Mostly focused on Delegation & Distribution – Julius Cesar (102-40 BJC) – RMON & RMON2 – Manage smaller worlds to manage each better – SNMP’s INFORM Service • Get compliant with each degree of encountered dynamicity – Build an adequate hierarchy to manage the interactions among the worlds – SNMP DISMAN initiative • This is NOT an easy task! • Script MIB, Event MIB, Schedule MIB, Remote Operations MIB, • Foster Management Autonomy & Automation • Adaptation to emerging constraints – Avoid human interference – Dynamic MIB extensibility support • Self-Anything for the management plane • AgentX & previous efforts like SNMP-DPI or SMUX • E.g. self-configuration of the management plane • CIM Provider in the WBEM Architecture – Avoid time costly operations – Asynchronous messaging • Like long interface standardization efforts • MOM’s gain acceptance as a management communication channel • New dedicated management languages & models learning, •… • Current limits (self-ing) • Equivalent to the consequence of the previous option – Self-configuration • Accept & Integrate new constraints in the management plane • Service, network, device & MANAGEMENT PLANE ! – Low connectivity – Self-provisioning – Shared / cooperative management, new security models, negociation services – Self-instrumentation of services, – Unstable domains & entities – Self monitoring – Evolving and changing management interface – Self-healing – Self-optimizing

2 Emerging alternatives Summary • Delegation support and management interactions remain a • Automation is the focus of many efforts Self- Self- Configuring Healing strong focus – Autonomic Computing by IBM

– Active networks based management is one approach Self- Self- – N1 for Farmed resources by Sun Optimizing Protecting – Mobile agents are another solution – CISCO CNS Configuration Engine & Intelligence Engine … – Dynamic Managed objects loading & distribution become common – SelfCon initiative (Nortel & Waterloo U.) • Dynamic instrumentation is growing fast – Self-aware networks (Alcatel) – CORBA interceptors –… – Web Services Proxies • Promising future – J2EE management introspection – Several technologies cover parts of the needs –OSGi service interface monitoring • But do not cover all needs at the same degree • Automation is increasing • We will examine 2 different ones with different features in the next – Closed-loop management processes sections • E.g. Self optimizing performance (smart scheduling in Web Farms, – Research proposals in automated management are very promising storage networks, …) • New « to-be managed environments » appear : – SLA/SLM automation – On demand, self-service, home service platforms and environments • Formal SLA parameters & automated mapping to monitoring & reporting procedures – Ad hoc, sensor, home, wearable networks – Context sensitive services, including management onces

Tutorial Outline JMX : Java Management Extensions

• Growing Dynamics and their • SyncML-DM : an Approach for Impact on Management (20 minutes) Managing Dynamic Devices (60 min) • Why JMX in a tutorial on Management of – Dynamics – Representation Protocol for Device – Collapsing time scales Management Dynamic Networks and Services ? – The need for automation and – Device Management Protocol autonomy – Standardized Objects 1. Used in dynamic service environments – Management solutions for the – Device Management Tree – Inspired misuses ! dynamic world – Security for Device Management – Standardized approaches 2. Interesting features : • Case studies (40 min) – Emerging alternatives – Ad hoc networks management – Multi-level dynamics • JMX : Dynamic Management • Conclusion & discussion (15 min) – Great learning curve for/through the Java World (60 min) – Basic Concepts 3. Part of the evolution of the management species – Dynamic components – Strong heritage from the management roots • Attribute, method & notification level 4. Excellent Open Source implementations • Managed Object level – Remoting – Implementations – Application domains & instrumentation patterns

JMX : Java Management Extensions JMX global architecture • Java-based Management Agent Architecture – Enables Java applications/components to be easily instrumented in Java Management – Fosters the use of the Java technology to manage non- Applications Java environments • Information Models JMX Distributed – Set of MBean objects Services Protocol and InfoModel independent • Managed Objects JMX Agent – Name + MBean Services • X.500 like naming JMX Instrumentation – But not exactly the same ! Instrumentation MBeans • Decoupling of instrumentation / export / access protocols Managed Source: JMX™: Status, Roadmap and Directions Resources Session TS 720, JavaOne 2000

3 JMX : Managed Objects JMX : Managed Objects • Simplified vision • Standard MBean MBeanServer A management interface = – Management interface defined at 3: management MBeanInfo compile-time Managed Object 1:Register() Management • Exposed Attributes – Interface discovered by the agent at Interface • « invokable » methods on the object registration time MBeanServer management interface –+ /- 2:Discovery / • 3 levels of MO programmability • Simple model Managed Object Introspection() – Who builds the management • Interface is Static instance Management interface ? Interface of exported • Dynamic MBean Application resource Resources • The agent through introspection – Exposed Management interface is • The application as a demand built at run-time made by the agent MBeanServer • The agent through an external Managed Object – Management interface delegated by the agent to the MO 1:Register() Managed Object order Instance Management – What is the dynamics of the –+/- Interface interface ? • Coding Overhead 2:Discovery / • Defined at compile-time – MBeanInfo, get, set, invoke, … Introspection() • At run-time • Context sensitive management interface setup made possible Managed Object 3: management – Who build the Managed Object (remember the conditional packages instance that supports the interface Managed in the OSI management framework • Application developper Application ☺) • The agent, through delegation Resource Application Resources

JMX : Managed Objects JMX : a small Standard MBean example

• Open MBean MBeanServer // Interface public class MonApplication { public interface PrinterMBean { – Dynamic MBean with : Exposed managed public Integer getMaxCopies(); // The agent Resource private MBeanServer myMBeanServer = interface public void setMaxCopies(Integer n); • Restrictions on possible types public PrinterStatus getStatus(); MBeanServerFactory.createMBeanServer(); public void reset(); } – Method parameters public MonApplication { – Return types (2) Creation MBeanInstance // The MBean CommunicatorServer htmlAdaptor = new • Extended MBeanInfo & Creation Interface public class StandardPrinter implements PrinterMBean { HtmlAdaptorServer(); private Integer supCopies = 2; try { • Model MBean private PrinterStatus fStatus; ObjectInstance htmlAdaptorInstance = Managed Object … myMBeanServer.registerMBean(htmlAdaptor, null); – Resource delegates the Instance public Integer getMaxCopies() « coding » of the MBean to the {return supCopies;} ObjectName mbeanObjectName = new ObjectName(’’madynes:id=MyFirstMBean’’); MBeanServer public void setMaxCopies(Integer pSubCopies) {fSupCopies = pSubCopies;} myMBeanServer.createMBean( – Interface defined at MO run-time 1:createModelMBean(MetaData,RequiredModelMBean) public PrinterStatus getStatus() ’’PrinterMBean’’, – + /- {return fStatus;} PrinterMBean); • Ideal model for NON- public reset() {setStatus(’’down’’,’’other’’); sendReboot();}; } (4) Link with catch(Exception e) { e.printStackTrace();} management specialists public Printer() resources } { fStatus = new PrinterStatus(); • Marvelous free services : }; – Cache management – Persistance // not visible at the Mgmt Interface Application public Integer getTemerature() {return fTemperature;}; – Logging, … } Resource

JMX : agent services JMX : event model

public class StandardPrinter implements PrinterMBean, • Events are part of the NotificationListener • MBeanServer JMX model { – MBeans container public void handleNotification(Notification notification, Object – Are thus well integrated handBack) – Ensures MBeans naming & registering { in the framework System.out.println(notification.getMessage(); • Advanced services – Are used in many } – Monitoring ..... fundamental services public PrinterMBean(SystemMbean systemBean) • Objects attributes of the framework {.... – Numerical values & character chains • Java’s Event/Listener NotificationFilterSupport nf = new –Timer NotificationFilterSupport(); Model nf.enableType(new String(« PC.alarm »)); • Periodical, « one shot » systemBean.addNotificationListener(this,nf,hb); – Emitters } – MLet } • Dynamic loading of MBeans • Broadcaster interface – Query – Event consumers public class SystemMBean extends NotificationBroadcasterSupport implements MyPCMBean • Selection operation on MBeans • Subscription & listeners {

• OSI style Scoping & Filtering • Done within one } – Relationship MBean Server ..... • Setup and maintain relationships among managed objects

4 JMX : event components JMX & related proposals in the JCP • Notification (CL can be subclassed) – type: character string which defines the notification type ex. JMX Remoting fr.loria.office.fire WBEM Services : JMX Discovery (Agent & MBean) – seq number: in the context of the source Remote access, proxying, Provider Protocol Adapter IIOP Protocol JMX / TMN JMX2CIM, JMX seen as a Context, connectors, alarm – Time stamp distribution, … Adapter for JMX CIM Provider JSR 146 JSR 160 – message: string describing the cause RMI; IIOP, HTTP JSR 70 JSR 71 – userData: additional data provided by the sender (Java Object) • NotificationListener (IF) MBeanServer – handelNotification(Notification n, Object handback) & Agent Services Standard, Dynamic, • NotificationFilter (IF) JSR 003 Open, Model MBean – isNotificationEnabled (invoqué par le broadcaster) • NotificationBroadcaster (IF) – getNotificationInfo: lists all notifications that the source can send JVM Management J2EE Management & Monitoring – add/RemoveNotificationListener J2SE 1.5 MEJB MBeanServer – sendNotification JSR 174 alike JSR 77

JMX : platforms JMX Users (source JMXperience) • AdventNet: Agent Toolkit - Java/JMX Edition + • Media style GmbH • Open Source platforms Manage Engine + Middleware Manager + – MX4J (mx4j.sourceforge.net) – MC4J (mc4j.sourceforge.net) Middleware Manager WebLogic Edition + • Misys International Banking Systems Ltd: WebNMS Meridian • JMX management console • Full toolkit integration • BEA: WebLogic • ObjectWeb: JOnAS 2.5, JORAM 3.1 • Several extensions • Compatible with : • Compiere Open Source ERP & CRM • Pramati Technologies – Additional connectors –MX4J • Critical Path: Internet File Server, Presentation – Extended Meta-models (MBeansInfo) in – JBOSSMX Server, Registered Mail Server, System Console • Resonate Inc: Resonate Commander standard MBeans –JDMK • CSC (Scandinavia): LABKA II • Schmid Telecommunication: Pegasus Element • Apache License • Dirig Software: Dirig Agent Manager – Open JMX : MX4J predecessor • Hewlett Packard: Core Services Framework + • Sonic Software: SonicXQ HPAS + OpenView • SpiritSoft: SpiritWave 5.1 + SpiritWave – JBOSSMX : • IBM/Tivoli Integration Server • Core of the J2EE JBOSS platform • IBM: Web Services Toolkit 3.1 , + WebSphere • A genious « misuse » of JMX Business Components + WebSphere Business • Sun Microsystems: Java Dynamic Management Integrator +WebSphere Voice Server Kit (JDMK) + Netra CT Managed Object – XMOJO (xmojo.org, LGPL) • Innovative Systems Design: ITVerify Hierarchy (MOH) + Netra HA Suite + Netra T1 • Others • IONA Technologies PLC: iPortal + Orbix + Orbix + DReAM, Distributed Resource Allocation E2A XMLBus Edition Technology 2.0 –TMX4J Manager + SunONE Application Server + • iReasoning Networks: iReasoning JMX SNMP SunONE Portal Server • Tivoli, alphaworks Agent BUILDER –JMXRI • The Jakarta Project (Apache): Phoenix • Sybase: EAServer 4.0 • TCC: Rexip AppServer 1.0 • Reference implementation •JBoss • Log4j • Tomcat –JDMK • Lutris: EAS • Wily Technologies: Introscope • Sun’s offer • Macromedia: FlashMX, JRun 4 • XadrA's VelocityAdaptorServer – Advent Net JMX Studio • Manage.com: FrontLine Java Management Edition • Zareus, Inc: Zareus Application Platform • Development environment & applications (JME)

JMX Deployment Models [KregerHW 03] JMX Deployment Models [KregerHW 03]

• MBean • Component – MBS is part of & controlled •JVM Relationship ? Who owns what ? by the application Application MBS • MBeanServer Who initiates what ? – + access to fine grained JVM MBean MBean • Application instrumentation Application – - needs to be designed in Application strong relationship with the • Daemon application – Remote Managed Resources •Driver – Agent & MBean can survive JVM MBS – Component with inversed authority role the application & its JVM MBean MBean – MBS bootstraps the – Application must integrate Ressource access application & its MBeans MBS MBS remote communication protocol JVM – Ideal way of using JMX Bootstrap services with the agent JVM Service Application – Easy for application lifecycle • RMI, SNMP, HTTP, … Resource management MBean Application

Application MBean

5 JMX Instrumentation Pattern [KregerHW 03] JMX Dynamics (1)

• Application is its own MBean – MyApplication implements…. MBean • Managed Object Interface level – Usually Standard, Open or Dynamic MBeans – MBean life-cycle usually bound to the application life-cycle & conversely – Dynamic MBean • Application is separated from its MBean(s) • Exposed management interface can be built at run – 1 –n MBeans represent the application – Model MBeans are well suited time ! • Especially due to the services they offer • Full control of the interface by the MBean programmer – All other (standard, dynamic, open) as well – MBean Life-cycle can be independent of the application (depends on who • Invocation behavior can change over time instanciates the MBean) – If (methodInvocation = “getStatus”) then • 2 additional Instrumentation Patterns defined in [KregerHW 03] – Publish-only • if (lunchTime == true) return this.busy() • MBeans used to offer read-only data information to the management • Else return this.getStatus() console with a well constrained overhead • Data caching is needed… ModelMBeans can do the work – Model MBean – Facades • Management interface is build incrementally • MBean that aggregates interfaces to other (even remote) MBeans • Behavior can be tailored (cache management , persistence, …)

JMX Dynamics (2) JMX Dynamics (3)

• Remote dynamic loading of MBeans • Notification driven management – Using the MLet service orchestration – Well designed for – Every MO can be a notification emitter • delegation • Just become a notification broadcaster • Managament interface update – Every MO can subscribe to notifications • Subsription on a per (source, notificationType) basis – Entire management behavior can be build on notification exchange • Even one MO can be a listener of its own broadcasted notifications and implement its behavior entirely in the listener

JMX Dynamics (4) : all together JMX Security (1) Access control • Full part of JMX 1.2 • Fancy automated management scenarios – Permission-based access control are possible • MBeanServer permission policies – What operations of the MBeanServer are allowed to which – Setup a listener on the create/delete & application registration of MBeans • create an MBeanServer in/outside a MBeanServer factory – When a specific MBean appears • Release an MBeanServer • Find an MBeanServer • Remote load the corresponding monitoring MBean • Get/set a builder – Manage the application – Grant given to applications – Implemented in the MBeanServerPermissionClass

This is Autonomous Management ! grant MyApplicationArchive.jar { permission javax.management.MBeanServerPermission “findMBeanServer, releaseMBeanServer”; };

6 JMX Security (1) Access control JMX Security (3) • MBean level operations under permission policies – Instanciation, register/de-register • MBean Trust – Instance & name search, get, querying – Add/remove NotificationListener – Grant trust to MBeans signed by an authority – MO Attributes get/set – Only trusted MBeans can register in the server – MO Metadata access (MBeanInfo) – Operation invocation • Security violation => SecurityException – Class Loader reference • MBeanPermission Target • Uses the Java security services – ClassName of the MBean to which the policy applies – Java Authentication & Authorization Service – ClassMember to which the policy applies (attribute, operation) (JAAS) – ObjectName to which the policy applies • User authentication grant MyApplicationArchive.jar { • Access control to methods & objects permission javax.management.MBeanPermission “StandardPrinter”, “instanciate registerMBean”; – Simple Authentication & Security Layer API permission javax.management.MBeanPermission “StandardPrinter:reset”, “invoke”); permission javax.management.MBeanPermission “StandardPrinter:Status”, “getAttribute”); – Java Secure Socket Extension permission javax.management.MBeanPermission “StandardPrinter:Status[name=“hp1”]”, “setAttribute”); • TLS & SSL implementation };

JMX Remoting : JSR 160 JSR 160's goals • From the text: • Unclear JSR 03 (JMX) concerning the Client/Agent interactions : –"interoperability, transparency, security, and flexibility." – (RMI) connectors under specified – operational model for remote listener • Standardizes at least one protocol between –… client and agent (over RMI) • JSR 160 (JMX Remote API) clarifies these points ⇒ client independancy from agent implementation – public draft june 2003 support (sun, MX4J, …) – applies to JMX 1.2 • Remote client side operations mostly like local Mbean server interface ones Upper Layer Interface of a JMX Agent Client MBean MBean MBean connection Server Server MBean JMX Agent Connection MBean Services MBean

A matter of Connectors Directories of (server) Connectors • No "JMX directory of services" • Means to feed existing ones… JMXConnectorServerFactory 2 – text mode (JMXServiceURL): SLP, JNDI/LDPA JMXConnectorFactory newJMXConne ctorServer – Stub to JMXServerConnector: JINI, (JNDI/LDPA) "jmxmp" – Basic attributes for (JMX) Services lookup. 1 newJMXConnector JMXConnectorServer service:jmx:jmxmp://host1:9876 agentName=… 4 start MBeanServer JMXConnector Agent 1 instanciate Mngr 2 connect 3 register Dir. of Services 3 getMBeanServerConnection MBeanServerAd 2 register(agentName=…) 1 findServices(agentName=..) 4 getAttribute JMXServerURL MBeanServerConnection 1 getAddress Agent Mngr JMXServerURL JMXConnectorServer

2 newJMXConnector

manager side agent side (on host1) JMXConnectorFactory

7 Notification handling (1) Notification handling (2)

• Client/Server context: where are things done ? – Filtering: on agent (⇒serialization occurs) Id on l f h – Listeners on manager JMXConnectorServer – Handback data on manager (usual case) Notif buffer – State data linked on Connector connection ("session") 1 add(on, l, f, h) 2 add(on, f) 3 emits • On client Add/remove Listener: 4 fetchNotifications on Id Id on f – Filter serialization ⇒ dedicated ListenerID management session • Implemention hints in JSR160: global Notification Mngr buffer linked to a given JMXConnectorServer MBeanServerConnection – Remote fetch method in a JMXConnect (client) scope 1 add

Manager side Agent side

Implementations JSR 160 : Summary

• A mandatory RMI implementation • +++++ • A generic Connector: « pluggable transport » – Very clear and precise specification • JMX Message Protocol (JMXMP) – HTTP connectors are no longer part of the standard – Optional in conformant implementations – Generic notification subscriber • Server connector subscribes to all possible MBean broadcasters that – A « meta » transport protocol appear in a MBeanServer • Handshake phase and profil negociation (I.e: type of authentification) • What is not detailled – Messages and interactions are clearly described – Security aspects – Object wrapping (serialization) is hookable • Use of security subject for some interactions – Classes loading issues – Not mandatory • On manager side (how to ensure which class loader does a – Concrete sample implementation JMXConnector use ?) • Full duplex stream oriented communication interface over TCP • On agent side – If you have time during your next vacation : – MBean do not need to know all possible Filter class • Do the SOAP implementation of JMXMP? – How to ensure which class loader does a JMXServerConnector use ? – All we forgot ;-) …

Usefulness for Dynamic Networks JMX Remoting : JMXP [draft-harold-jmxp00]

• Connectors are MBeans + Mlet ⇒ • Application protocol to access JMX agents Management infrastructure connectivity is easily Client configurable • BEEP-based – BEEP profile – E.g. dynamic download & setup of connectors • 3 profiles MBEANSERVER, can be context specific ! MBEAN, NOTIFICATION Communication • 3 allocated channels Channels – Still a bootstrap issue – MBEANServer interactions • RMI is there to solve the problem : CH1 – NOTIFICATION interaction CH2 • Better security support – MBEAN interaction : CH3 JMX – authorization policies Agent • Java 2 platform security – provisioning rules

8 A sample exchange scenario The MBean Profile (Channel #3 operations)

MBeanServer Operations Service C:MSG 1 1 . 52 120 • Operation on MBeans C:Content-Type: application/beep+xml Manager JMXP Adapter • CreateMBean C: Beep Session Establishment • getObjectInstance • Get/Set values on MBeans Profile • isInstanceOf – Invoke Parameters : C: • queryMBeans • Mbean instance name C: • queryNames Open MBeanServer (#1) Channel • (attributeName, [AttributeValue] (set C: 5 • unregisterMBeann only))* C: QueryMBeans MBeanServer • GetDefaultDomain Ch#1 Profile • GetMbeanCount – OK Response parameters : C: Response code=« 200 » Ch#1 • Notification Subscription Service C:END •AddNotificationListener • Mbean instance name Add Notification Listener Ch#1 •RemoveNotificationListener • (attributeName, Attribute Value)* Start Notification Channel (#2) C:MSG 1 1 . 52 120 • MBeanInfo profile C:Content-Type: application/beep+xml Ch#2 Ready C: – Download a MBean metadata (MBean Response code=« 200 » Ch#1 C: definition) C: • Parameter : target MBean instance CreateMBean Ch#1 C: javax.management.Timer name C: timers:id=alarms Response code=« 200 » Ch#1 • MBean Invocation profile C: S:RPY 1 1 . 221 87 C: – Invoke a method (operation) on a Notification Ch#2 S:Content-Type: application/beep+xml C:END remote MBean • Parameters S: S:RPY 1 1 . 221 87 S: – MBeanInstance Name S:Content-Type: application/beep+xml S: – Operation name (e.g. reboot) S: S: S: – Operation parameters Notification Ch#2 S:END S: – parameterName + Parameter Value time S: timers:id=alarms S: S: S:END © MADYNES 2003 -49- © MADYNES 2003 -50-

Notification profile Encoding & security S:ANS 2 23 . 652 98 •Scalartypes S:Content-Type: application/beep+xml • Security Required profiles • JMX Notifications S: – All OpenMBean like standard Types – MD5 (authentication) S: • Void, Boolean, Byte, Character, String, – TLS (confidentiality) S: Long, … are issued by a S: – Combination and other algorithms for S: • Structured types both authentication & confidentiality server to clients S: – OpenMBean types S: String S: • Tabular • Clients register first S: • composite S: Long – Arrays S: • S: • Notification S: Long – ….. S: – …. components S: – Attribute (AVA) S: String • S: – Notification S: – Composite S: Integer • Simple or structured type (e.g. a struct), description S: i.e. the description of the type S: • + member element (the value of the S: type) • metadata S: A PC related alarm S: 42 – Tabular – Notification instance S: 102045873000000 • Simple or structured type S: pc.alarm • +one or more rows S: 13 • values S: – Dedicated JMX types S: • MBeanInfo Value S: • ObjectInstance (class + ObjectName) S: S:END

JMX & Legacy JMXP : pros & cons

• Example of integration with legacy • An excellent initiative management – A first proposal of a BEEP-based management protocol – CMIS/JMX Gateway • Notification subscription – Good to have it available ! JTMN CMIS Browser – Missing items • No Filtering, scoping in the JMXP parameters •«The Blues Brothers » syndrome

Simple – No NotificationType based subscription in the current approach Dynamic • Not even in JMX

Simple – Impossible to subscribe to the following Standard • I am interested in all Alarms Mbean1 – Possible • I am interested in alarms from instance1, instance2, …. Mbean2 Mbean3 – How to deal with optional data in notifications ? • Change the metadata in each invocation. – Not part of the standard protocol so far ☺

9 JMX : + & - JMX future • A marvelous wedding Source : ’’JavaTM Management Extensions (JMXTM): Recent Changes and Ongoing Applications’’ –ManyJavavores, & some OSIrists TS-2074 presentation at JavaOne 2003 by Eammon Mc. Manus • Result: – OSI management without its limits • Excellent ideas to come – An Agent-toolkit • Trivial in usage (Ideal learning curve) – Metadata support • Easy to integrate (Especially if the application is in Java) • @management tag to automate the generation of the – High quality OpenSource implementations • …especially MX4J et MC4J, TMX4J, … MBean interface – Outstanding Documentation • Specs & books & examples – Hiearchical Management architecture • Real Support of Dynamics • Proxy agent (proxy’s remote MBeans in one • Any limits ? – No neutral information model specification & language JMXServer) • Well : Java is one and a link to UML is always there – Reliable Notification Delivery – Agents (or at least the agent part of an application) are necessary in Java … I like that ☺ – Client (Manager) side or at least remote access (remoting) took time to appear (JSR 160) • Now proprietary approaches are deployed (interoperability ?) • The specification took time but the standard is of great help and very well described

Tutorial Outline Synchronization in the early days (before 2000 A.D.)

• Growing Dynamics and their • SyncML-DM : an Approach for Impact on Management (20 minutes) Managing Dynamic Devices (60 min) – Dynamics – Representation Protocol for Device – Collapsing time scales Management – The need for automation and – Device Management Protocol Islands of disconnected Information autonomy – Standardized Objects – Management solutions for the – Device Management Tree Device-Vendor-Product-Application specific synchronization: dynamic world – Security for Device Management – Standardized approaches • Case studies (40 min) Multiple devices – Emerging alternatives – Ad hoc networks management (Phones, PDAs, WebTV) • JMX : Dynamic Management • Conclusion & discussion (15 min) for/through the Java World (60 min) Major Manufacturers (Alcatel, Nokia, Ericsson, …) – Basic Concepts – Dynamic components Several synchronization products • Attribute, method & notification (TrueSync, FoneSync, Intellisync level Anywhere) • Managed Object level – Remoting Server Applications (Lotus Notes, ODBC databases, yahoo…) – Implementations – Application domains & instrumentation patterns The Babel-Synchronization framework

Towards open data synchronization Use cases for Device Management

2000: creation of the SyncML consortium (www.syncml.org).

Members : More than 600 companies-IBM, Nokia, Motorola, Ericsson, Matsushita, Symbian, Openwave ….. • Remote service management

Objective : Develop an Open Standard for data •Troubleshooting • Personal Management Synchronization • Storage Management Additional Results : Device Management Framework for managing devices . • Monitoring

• Software download Synchronization Markup Language is an Open Specification for universal synchronization •Over the air Mass Configuration

10 Challenges in Device Management Requirements for Device Management

• Operate effectively over wireless and wired networks • Heterogeneous devices • Support a variety of transport protocols • Many applications • Support arbitrary networked data • Multiple network connectivity • Enable data access from a variety of applications

• Address the resource limitations of the mobile device • Limited resources • Build upon existing Internet and Web technologies

Wireless/Wired Network Operations Transport Protocols

Several transport protocols are already used by wireless devices Ubiquitous wireless access Redefine Management

• HTTP (i.e. the Internet) 1. High network latency 1. Management might be to late • WSP (the Wireless Session 2. Limited bandwidth 2. Manage efficiently (whenever Protocol, part of the WAP 3. Low reliability of both data it’s required without wasting protocol suite) resources) and connectivity • OBEX (i.e. Bluetooth, IrDA, and 4. Dynamic Addresses and 3. Connection Oriented other local connectivity) management network connectivity • Pure TCP/IP networks 4. Application level naming and 5. Firewall, Nats – several • Proprietary wireless management domains addressing communication protocols 6. Out of coverage factors 5. Device initiated management 6. Different Fault behavior management All of them are connection oriented ……..

Multiple Applications Scope of SyncML

• Allow common data representation – Common personal data formats, such as vCard, todo etc. XML based framework for data synchronization – Collaborative objects Relational data – HTML documents Message oriented data – Binary data exchange protocol

• Support extensions towards new data formats Transport agnostic

• Programming Language Independent Universal deployment – No API (re) definition Extension for device – No Communication Middleware dependency management – XML Message exchanges as a glue

11 SyncML Specifications – More than just XML Representation Protocol - Objective

Container Element

SyncML Message Device Description 1. Specifies the structure of Container Element Framework Synchronization Device Information SyncML messages Protocol SyncML Header DTD 2. Defines a vocabulary to describe management data and operations Container Element Bootstrapping 3. Core component of the SyncML Body Representation Protocol SyncML framework on which all others components are based Data description elements

Device Management Synchronization Framework Protocol Common Use We will cover them in this order: Commands Elements •Common Use Elements Device Management •Protocol Management Elements Framework Protocol Management •Command Elements Elements Transport Technology •Data Description Elements HTTP OBEX WSP Bindings •Message Container Elements

Common Use Elements Identification Mechanisms

Sub-elements of Command or SyncHdr used to provide a set of common Source : Who is starting the operation or from where data originates functions Target : Where operations are performed or where data is copied/replaced/requested

……………………. Requesting a specific credentials ……………………. ASCII name of a command http://www.syncml.org/Server …………….... Identifier for a command …………… ID of a command to which reference is made URI can represent : …………….. Identifies the target/source for an operation ………………. Where an operation applies ……………. Data/Operation Source for an operation 1. a server End of package flag 1. Chal 11. MsgID 2. device 2. Cmd 12. MsgRef 1 3. CmdID 13. NoResp 4. CmdRef 14. NoResults 3. one data store IMEI:383/Rings 5. Cred 15. Source 1 6. Final 16. SourceRef 7. Lang 17. Target 4. data item IMEI:383/Rings/ToneA …… 8. LocName 18. TargetRef 9. LocURI 19. VerDTD 10. MoreData 20. VerProto IMEI:383581748 Complete list of common use elements

Protocol Management Element(s) Status Codes (excerpts)

1 •Add 1 – (200) OK : Command Completed successfully – (414) URI in command too long ./Contacts/John – (500) Command failed –generic code for failures •Atomic Management Operations (one SyncML Message) – (507) Error occurred when performing an individual command •Copy – (420) Device Full – no space left on device – (425) Permission Denied – no proper ACL Agent •Delete Result for each operation – (425) Permission Denied – no proper ACL Manager – (403) Forbidden –node in use 4 1 1 1. Each command is associated to one or several status codes Get ./Contacts/John 2. If you know HTTP then you almost know the Status codes Status Code 401

12 Command Elements –functional classification The Duo: Get and Results 1. Data Command Elements – used to change application data

Add - creates a new interior node 1 Copy –copies values from a node to another at the client side 2 Delete – deletes a node (and all its subnodes) Exec – process execution on the target ./Contacts/John Replace – overwites value for an existing node Get – retrieves data from the target

1. DataStore Command Elements – Actions for an entire datastore

Alert – used for notifications, text displays Results – contains results from a Get 1 2 2 2. Process Flow Commands – enhanced processing control ./Contacts/John Tel:01564433 Atomic – all subcommands must be executed Sequence – subcommands must be executed in order

Data Description Elements Meta Information

1. …. encloses SyncML payload data Meta-information related to a SyncML command or data item 2. …. • isolates a command from the underlying data • Contains Data, Identification and Metadata 1 Command to add a calendar entry

3. ….. provides meta-information about the Tag indicating Meta Information data chr Data encoding is character (non-binary) • Type of the data 200 Size of the entry is 200 bytes text/x-calendar MIME calendar format for the entry • Size of the data ./2 Location of the entry

Meta Data …………………….

Item

Container Elements Device Management Framework

Message Container 1.0 Describes the management information and how to access it • SyncML is message 1 1 oriented Header Container Management Tree 1. Framework for • Structure of a SyncML http://www.syncml.org/Server describing message is similar to management HTTP IMEI:383581748 information • Three types of containers: 2. Management Tree 1. Message 1 Body Container Container 3. Standardized Objects 2. Header Container 3. Body Container ./Contacts/John Managed Object © MADYNES 2003 -77- © MADYNES 2003 -78-

13 Purpose of the Device Management Framework Modeling Management Information in SyncML

Generic device description framework SyncML Describes methodology for describing managed device

Dynamic self-described management Device Model specific to an equipment information A

XML Tree Node captures information Uses B C models about : •Name of the managed object Management Protocol •ACL •Subtrees E F G •Value Management Application Managed Device •Data Type of the Managed Object Management Information © MADYNES 2003 -79- © MADYNES 2003 -80-

Framework properties of a Managed Object Information Modeling with framework properties

DFProperties Occurence DFProperties Occurence OneOrN value=3 Node AccessType DFType DFFormat Description NodeName At least one node must occur, but no more than three times Data Format of the Other possibilities: Which operations are possible ? node Add, Copy, Delete, Exec, Mime type Eg. bool, chr, int, Description of the node Get, Replace of the node value node, null, xml •ZeroOrMore : Node can occur unlimited number of times or not at all

•ZeroORN : Node can occur up to N times, or not at all Framework properties do not change at run-time. Analogous to a MIB2 definition •OneOrMore : Node can occur unlimited number of times, at least once

Runtime Properties of the Managed Object Runtime Properties vs Framework Properties

If used, indicates ACL (Internal Node) Runtime Property Type ACL Instantiated MO Represents the name of a device Vendor Document RTProperties description framework document. describing the Managed Object. Node Name Same as NodeName The Framework Property (Terminal Node) Runtime Property Type NodeName DFType indicates Mime Format Format of the value equals DFType from the device description framework document type of the node Size Size of the node in bytes Runtime Property Format describes the DFFormat indicates data Tstamp Timestamp of last change data format of the node. Obviously must format of the node be equal to the DFFormat property Type type of the node Objective : Describe instantiated Managed Object Do not confuse the two types of properties !

14 Access Control Lists (ACL) ACLs vs AccessType

ACL Property regulate access to a MO • ACL is Runtime property – AccessType is a device framework property. ACL A A • AccessType specifies what operations are supported – the ACL MO specifies who is allowed to perform these operations ACL B B • ACL – AccessType interaction in case of dynamic (runtime created) nodes C D Get=Server A&Replace=Server B ACL C ACL D Direct Delete Indirect Delete Command Command ACL operation Delete allowed Deleted Deleted 1. Internal Nodes – access to ACL is Access Type regulated by the ACL itself Delete not allowed Not deleted Deleted 2. Terminal Nodes – Parent Node ACL regulates ACL modifications 3. If ACL empty then closest ancestor Indirect delete occurs when an ancestor of the node has to deleted Server A Server B ACL is used

Addressing Object Values and Properties Device Management Standardized Objects

Addressing node values : A Mandatory Device Management Objects for any SyncML device Object is identified by complete path to the root of the management tree B Example : NodeA/NodeB Management Information Regarding :

Extended usage of the tags: 1. Connectivity information (protocol Meta, Format, Type Meta to indicate metainformation IPv4/IPV6, addresses, ports) Format (string in this example) for the data format via 2. Accepted authentication methods Runtime property Format 3. Bearer type (eg. Obex, GSM, CDMA) Type =value for the Mime type chr 4. Management server ID text/plain 5. Manufacturer ID, 6. Model and Device ID 7. Software version Addressing Property values : node URI+?prop= Example : addressing ACL property of Node B : /SyncML/NodeA/NodeB?prop=ACL Think MIB 2 for device management…..

Requirements for the Device Management Protocol Approach for the Device Management Protocol

Requirement: Ability to deal with dynamic environments Objective: Perform Device Management and allow user interaction in the management process

• Dynamic network connectivity Management Traffic Features : • Use the Representation Protocol • Unreliable communication • Re-use security framework from the Device Management medium Application Synchronization Protocol • Not always on-line devices due • Un-symmetric since only a server manages to out of coverage or limited a client

mobility management Foreign Access Network Firewall 1 Home Network • Limited incoming connections WAN Router Management Functionality : … for devices BT ‘URI of MO…..

Access network WAN Management Home Network • Read/Write/Replace Managed Object ’New value for MO’ Management domain domain Management domain properties • Create Managed Object • Remove Managed Object

15 Design choices for the Device Management Protocol A Management Session

Server 1. Session Oriented Package 0 Optional Notification 2. Client initiated Notification I want to manage you ! Package 1 3. Out of band notification Client Client initiates session •Five logical packages support Package 2 Management Server initiatialisation+mgt requests 4. XML encoded Session •In most cases one package is a

5. User interaction enabled Package 3 SyncML message Client initiated Results (for mgt requests) •Oversized packages can be included Rationale Package 4 Mgt. Requests in several message

1. Devices might not be always online Package 3 { Results (for mgt requests) •Protocol state (each site) is 2. Most firewalls will allow only device initiated connections Package 4 determined by current protocol 3. Notification support needed for “server initiated “ sessions Mgt. Requests

4. User might have other priorities Package 3 { Results (for mgt requests)

Wireless Access Protocol based notification Client initialization

Access network technology specific 1.1 DM/1.1 1 Package 1 Device is provided information 1 Push over the air Push Access protocoll Protocol about : Managed Device http://www.server.com Management Managed Device Server • Required User interaction Push Initiator IMEI:03839028 Push Proxy Gateway Information about : Management Server • Background operation • Server Identifier • Protocol Version 4000 • Session ID (equal to the … • Session Identifier Package 0 notification) ….. • MD5 authentication Delivery • Maximum message size accepted •Vendor specific by client • Client credentials 1 200 • Client and Server IDs (URI) • Initiator - is this a reply to a notification or a pure client initiated session ? © MADYNES 2003 -93- © MADYNES 2003 -94-

Server initialization Client Response

….. ………………. 1 2 Package 2 Package 3 http://www.server.com 5 Managed Device Management 2 Management Server 0 Server IMEI:03839028 SyncHdr 212 Information about : Information about : • Session ID syncml:auth-basic • Server Authentication (package 2) • Protocol Version b64 • Session ID (equal to the package 1,2) 6 • Session ID (equal to the package 1 1) base64 formated userid:password • Status of management operations 2 • Results if package 2 contained a Get Get •Server credentials Request .. Additional status information about • Last message in this package must Returned value 10 package 1 commands and header. contain the tag to mark the end SyncHdr of the package http://www.server.com Additional commands IMEI:03839028 …. 212 (Remember error codes) ….

16 Management goes on Bootstrapping

Basic initial configuration of the “Management” agent and transport connection ………………. Package 4 Existing Approaches : Managed Device …… Management Server 8 • Out of band signaling (WAP Push) • SIM card b64 • Pre-programmed Mime type of MO SyncML Bootstrap Protocol : Provides Management Server address to Client 1. Status information about message Authentication settings (Proof of Server ID) header in package 3 URI of MO Network level configuration setting for the communication (TCP/HTTP) 2. Additional Commands B64 encoded value for 3. Format and Type of the managed the MO object (MO) 4. Last message contains the tag ….

Security in SyncML Management Manage you wherever you are

• Ubiquitous management protocol • Transport independent Device Server • Bindings defined for short-range communication technologies as well as over IP/HTTP connections 1. Authentication of Server Package 0 POST ./servlet/syncit HTTP/1/.1 Optional Notification 2. Integrity check of the message Host: www.mydevice.com SyncML SyncML Content-Type : Package 1 (MD5/basic authentication) Client initiates session application/vnd.syncml+xm; OBEX OBEX Package 2 Charset=“utf-8” Server initiatialisation+mgt requests 1. Two way authentication Content-Length: 1023 2. Integrity check of the IrDA Bluetooth Accept: application/vnd.syncml+xml Package 3 Results (for mgt requests) message

Package 4 Mgt. Requests } 3. Access Control List HTTP SyncML ….. mechanism …. Package 3 { Results (for mgt requests) 4. Confidentiality provided by Package 4 Mgt. Requests transport level

Package 3 (HTTPS, SSL, OBEX) { Results (for mgt requests) SyncML /HTTP example Simple Idea : Embed any SyncML message in a POST request

Existing Implementations SyncML DM summary Proprietary implementations : • SyncML DM is more than just XML based configuration • Framework for describing management information Major actors and contributors to the standard. • A set of standard Managed Objects • Transaction oriented Management Protocol Open Source : • Network level transport agnostic • Flexible Access Control • Adaptation of conceptual design approaches from the SNMP Sync4J (http://sync4j.sourceforge.net) for the data framework towards device mobility synchronization. – Similar building blocks to the SMI, MIB2 and SNMP and Get/Set semantics No device management functionality. – Reversed roles : a managed Device initiates a management session – Power for the users : allow/deny management actions LORIA/MADYNES : • What to expect – More OpenSource implementations – Interoperability studies SyncML toolkit available : – Performance analysis and large scale deployment tests http://www.madynes.org/software.html

17 Menu

• Growing Dynamics and their • SyncML-DM : an Approach for Impact on Management (20 minutes) Managing Dynamic Devices (60 min) – Dynamics – Representation Protocol for Device – Collapsing time scales Management Case Study of Dynamic Networks – The need for automation and – Device Management Protocol autonomy – Standardized Objects Ad Hoc Networks – Management solutions for the – Device Management Tree dynamic world – Security for Device Management – Standardized approaches • Case studies (40 min) – Emerging alternatives – Ad hoc networks management • JMX : Dynamic Management • Conclusion & discussion (15 min) for/through the Java World (60 min) – Basic Concepts 1. ANMP – Dynamic components 1. SNMP clustering • Attribute, method & notification 2. GMA level 1. Clustering & active code • Managed Object level 3. Policy-based approaches – Remoting 1. COPS-PR Clustering for QoS provisionning – Implementations 2. A node-to-node policy exchange model – Application domains & instrumentation patterns

Ad hoc networks Ad hoc networks dynamics & Management Requirements • Topology & connectivity • Autonomous wireless – Connectivity among elements networks – Connectivity with an Internet Gateway • Element capacity & constraints – No infrastructure (predefined) – Power variation & constaints over time – No pre-configuration – Limited CPU & storage capacity – With OR without connectivity • Management Requirements to a fixed network – Automation WiredWired Internet – Dynamic Configuration/Reconfiguration • Dual role entities Internet – Varying management roles & capacity in participating entities – Any entity is both a terminal • From minimal participants (e.g. sensors, PDAs) and a router • To full fledged management entities (e.g. gateway, PC-based terminal, …) – Management needs to be lightweight • Dynamic features • Management overhead needs to be balanced against its cost – Limited & variable bandwidth • Limit the management trafic & processing – Power availability • Efficient management – Security (including a secure management plane) • Why accept management ? – Management of a timely limited (temporary) world – Entities in the network are – Poor connectivity & high packet loss volunteers to interact and • Management plane must be robust provide the best possible – Some traditional faults are NOT necessarilly faults anymore service • E.g. disappearing node

ANMP : Ad hoc Network Management Protocol [ChenJS 00] ANMP architecture & solution • 3 level management hierarchy • Focused functions – Top-level Manager – Configuration management • Can be an agent towards a wired Manager manager • Network partitions, merge – Cluster heads (1st level agents & • Node connect, disconnect, Join, leave, death, birth, Managers) power on/off, • SNMP compatibility – Data is exchanged via SNMP – Fault Management compatible PDUs – Managament information is located in – Monitoring (Data collection) SNMP MIBs • Manager rooted Spanning tree for polling • Clusters of neighbors Cluster head guest • Trap-based update (on change data propagation) – 2 clustering algorithms – Limit the communication on data change • Graph-based clustering algorithm – One hop neighbors (direct) • Geographical clustering algorithm – Up to 3 hop neighbors in a cluster

18 ANMP : Graph-based clustering Geographical clustering algorithm • Distributed clustering algorithm & protocol • 2 level clustering algorithm Cluster computation – Node positions are known through GPS – Link between 2 nodes = in transmission range – A centralized / Periodical processing for cluster definition 9 – Clusterhead = node with the smallest ID – A distributed processing algorithm to manage node • ID is a unique identifier mobility 4 – Static : • Central periodic clustering algorithm •MAC @, – Periodically initiated by the Manager 9 • Serial Number • Calculation of stripes • Valley selection & division 6 – Dynamic : • Max distance for a box = 3x transmission range 5 3 645 3 • EnergyLevel + MAC@ • Density adjustment facilities •IP@ – Node density sensitive • min, max # of nodes / cluster • Node internal data structures • Distributed mobility processing algorithm 9 – Done at the cluster level – List of neighbors, Cluster head guest • Leaving node send disjoin when leaving a cluster 4 – list of nodes in the cluster, • Joining node sends Join message to cluster head when joining a cluster 9 – Ping counter (last time, logical, a ping was • Guest facility in each box for nearby unmanaged nodes 6 received from the cluster head) • If node density changes (over nax, under min) recompute clustering 5 3 645 3

ANMP Management Information Base ANMP Management Information Base & applications • Power Usage MIB Group • Topology group – Neighbor table • External Power : Y/N • List of IP@ of all direct neighbors • Remaining Power (watts-hour) – List of supported topology • Current Power mode protocols • Clustering protocols : graphical, • Power mode costs geographical – Power mode table (sleep, idle, active, …) – # of current used topology – Consumption in each mode maintenance protocol • Battery – Cluster protocols specific data – Age, type, serial#, last recharge time • clusterID, #nodes in the cluster, … – Drain model (description, function) • Applications • Radio Interface Power table – MIB 2 monitoring – 1 Entry / interface – Topology discovery – 32 bytes transmit/receive power – Power monitoring & management 802.11a/b/g GPRS Bluetooth – Power consumed in idle mode • E.g.K forcing a device to stay in alive mode – Power consumption in sleep mode

ANMP Agent Information ANMP Security

• Maintained by the Manager & each cluster head • Level Based Access Control Model (LACM) – Information Update Interval (ms) • Each node has a Clearance Level – %managed agents, %managed agents updated info – The Higher the level the lower the security access available • 1 : access granted to manager with level 0 clearance certificates – Data collection tables (control + data tables) • 4 : access granted to manager with level 0,1,2,3 • Managed nodes power information – Clearance Ids are certificates – Control : number of samples stored, to be measured, sampling – Clearance Ids are distributed by the manager to the nodes interval, • Data (mib objects) is grouped into projects • M2M notification communication facility – Each project (set of managed objects) has a clearance level which – Manager configures events to be sent by the cluster defines who can access it heads • LACM effect on clustering – Manager delegates monitoring (e.g. threshold – Cluster heads should have clearance to access managed nodes monitoring) to clusterheads, through setting the control data tables – If Not, they are always bypassed by the node – Clusterhead selected alarm can lead to event issuance • Node encrypt data so it can only be decrypted by the manager to the manager

19 ANMP : Summary Guerilla Management Architecture [ShenSJ 02]

• A very complete SNMP compatible management architecture proposal • Management Architecture for ad hoc networks – Good information models • Goals : make management operational in highly dynamic • A first identification of a need for some active code facility networks – ftp download of code, – Maintain connectivity in the management plane within a managed ad – Association of the entry point of the code (function name) to alarms or event hoc network entries • An outstanding contribution to the field – Minimize Management costs on : – Interesting Clearance level based security model •CPU • Very good coverage of mobile ad hoc nodes • Memory – >90% cluster-level managed nodes • Power consumption •-: – Enable Disconnected Management ! – No configuration transfert among clusterheads in cluster formation • Approach • Everything is conditioned to manager operations – Multicasting service usage not clear in the context of management – « Context-Aware » Self-configuration of the management plane – No clear definition of the right cluster size and its relationship to the – Hierarchical Management Framework management operations – Management agency : a set of agents can speak as an agent for any • E.g. monitoring frequency other – Limited management functions • Topology discovery, + power status & management – Dynamic code deployment on active probes

GMA : Architecture GMA : Component details • SNMP Device (present in all devices) • Active Probe • Active probe Increasing – Extension to the SNMP Agent Device – EE for hosting monitoring scripts • Nomadic Manager Capacities • Both local monitoring and surrounding simple & SNMP devices • Management federation (agency) Intelligence Nomadic Manager Module – Deployed by Nomadic Managers & Guerilla MIB • Supervisor • Nomadic Manager Supervisor – Maintains connectivity in the Management Probe Plane with other Managers Agent Processing & MIB – Decides to update the management plane Engine Nomadic Nomadic Probe Manager Manager Agency configuration Probe Probe Probe Probe Nomadic • E.g. can spawn new managers in other nodes Network Layer LOGICAL Nomadic Probe Probe Probe Manager MANAGEMENT Probe Manager Probe PLANE Probe Probe – Holds management policies (rules) from the Active network layer Nomadic Nomadic Manager Nomadic Manager Manager Supervisor Probe Probe Link layer Probe Probe Probe Probe Probe – Maintains a Guerilla MIB Probe • Aggregation of data collected from the active probes • Supervisor – The manager

GMA : Protocol components GMA : Management plane clustering algorithm • Connectivity & management plane topology – Nodes send beacons (hello’s) • Relies on the CLTC algorithm – Nomadic Manager decides of its coverage domain – Initially a power management protocol • Can spawn a new nomadic manager to split a domain • Can rely on the Adaptive Dynamic Backbone clustering protocol for self- • k connectivity with minimized power consumption configuration of domains power assignment – Builds trees of nodes rooted in an Nomadic Manager – Cluster-based Topology Control – Maximize a utility function to select the management function to perform • 2 level topology control • U = f(powerUsage,CPU Load, ManagementGain, …) – Intra-cluster – Inter-cluster heads • 3 phase power level calculation Nomadic Manager Spawn – 1 : clusters establishment Nomadic Nomadic Nomadic Manager Manager Manager – 2: intra-cluster power assignment – 3 : inter cluster power assignment Probes Probes Probes Probes Probes Probes Probes Probes Probes • K connectivity enforcement among clusters Probes Probes Probes Probes Probes Probes Probes Probes Probes Probes Probes Probes

20 GMA : Summary Policy-based Approaches [Phanse 02]

• A MbD approach • Context : QoS management in the ad hoc plane : – Topology & power dynamics Super PDP

– Code mobility – Resource usage authorization PDP • Heterogeneous Devices considered – Policy-based admission control – ManagementRole = f(Device capacity) – Dynamic bandwidth allocation • Fundamental Good Assumptions – Differentiation provisioning – Monitoring – Self-organization of the management plane is necessary – Disconnected management can be done • Approach – Decentralized COPS-PR • Limits PEP • Hybrid Provisionning and Outsourcing – So far no value-added management service deployed on the model framework – Clustering & Cluster Management – Except the management of the management plane topology itself – Dynamic Service Redundancy – Scalability issues are not convincing yet – Service Location Discovery (find the • Open Questions PDP) – Why do we still need a manager ?

Clustering Extensions

Super PDP PDP • Multi-domain policy negociation • K-Clustering – Inter-PDP signaling HomePDP – Maximum K hops away from a (5 Policy Negociation) policy server – Home PDP + Last PDP fields in – A client can be served by a server COPS messages LastPDP that is less than k-hops away – If no policies found by the visited • Initial Deployment K hops PDP => negociation with the HomePDP (3 OPEN) – Super PDPs are present in the PEP network – Negociation = Policy download (4 ACCEPT) • Redirection service • Possible improvements (OF) – A server (PDP) can dynamically Cluster (2 ACCEPT) – Policy transfert during redirection Visited redirect a client to a less distant Delegation PDP – PEPs could « come with » their PEP (1 OPEN) PDP own policies – Redirection is Server initiated • Delegation Service Redirection – A PDP can delegate part of its decisions to another PDP

Node-to-node policy exchange approach [MunarettoAF 02] N2N addressed problems [MunarettoAF 02] • Context : Corporate ad hoc networks – Uniform management & company wide • 2 phases policy distribution & policies synchronization • Management function Device PDP – 1: feed the PIBs of connected devices – Diffserv-like QoS management in the ad- Applications • Manager is a PDP hoc network PEP • Approach •Ad-hoc nodes are in a PEP role

–Everyad-hoc device exports both Edge Router – 2: permament synchronization among Phase 1: Policy distribution by functions Element 2 meeting devices Prime network management • Edge router (marking, metering, policing, shaping) • Applied to new entrants Core Router – Acts on local applications Element • Policy authority • Core router (classifying, schedulling,…) – Acts on routed packets – Management Hierarchy with delegation

• Management Plane – Policies are tagged by managerID Policy Synchronization –Eachad-hoc device embeds both MAC QoS Elements – Each managerID has an authority level • PDP + Policy Repository known by all •PEP Policy Synchronization – The more authoritative policy always replaces less ones Phase 2: Policy snchronization

21 N2N Policy exchange approach Ad hoc management summary

• Summary • Other approaches – A focused approach –MARE • Corporate • Used mainly for service location – An interesting approach • Mobile agents + distributed tuple-space • Device level Policy Management Framework • Common vision of the problems • Current limits – Management overhead must be minimized – Synchronization protocol not described – Some open problems on policies consistency – No description of addressed policies & policy levels • Similar approaches – Hierarchical authority model is not sufficient to cover – Clustering (various algorithms) security issues at all ! – Delegation (agents, active code, extensible SNMP agent, …)

Menu Conclusion (1)

• Growing Dynamics and their • SyncML-DM : an Approach for • Dynamics is a growing parameter in the management Impact on Management (20 minutes) Managing Dynamic Devices (60 min) plane – Dynamics – Representation Protocol for Device – Dynamics is everywhere – Collapsing time scales Management – The need for automation and – Device Management Protocol – The research community is starting to address the problem autonomy – Standardized Objects • Ad-hoc management is one example – Management solutions for the – Device Management Tree – Few initiatives so far dynamic world – Security for Device Management – Standardized approaches – Similar approaches • Case studies (40 min) – Emerging alternatives – Ad hoc networks management • Clustering • JMX : Dynamic Management • Conclusion & discussion (15 min) • Delegation for/through the Java World (60 min) – Basic Concepts • Some approaches enable dynamic management – Dynamic components – Or at least some parts of it • Attribute, method & notification level • Other initiatives contribute as well to the field • Managed Object level – E.g. Debussmann’s auto-instrumentation proposals – Remoting – Jini-based federations of autonomous management architectures – Implementations –… – Application domains & instrumentation patterns

Conclusion (2): Is the answer in standards ? Conclusion (3) : The management future according to MADYNES

IBM CISCO JCP DMTF • Management will not disappear ! NORTEL ALCATEL TeleManagement Forum – At least we hope it will not. AT&T ITU-T MMA? SIEMENS ? OMG … • The management future will be a mixture of : LUCENT ITIL IEEE SUN ETSI JMX MICROSOFT NEC IETF Open Group – (option 1) management of static only parts IRTF NTT DEC-COMPAQ-HP SyncML – (option 3) smart & automated management techniques OASIS W3C TOSHIBA OSI • Efforts must be maintained in both directions – Standards can play a role in both options as well – But are not the overall success condition • How many standardization Consortia can be built from n proprietary solutions, given that a standard requires at least 2 companies to be • Research may be more “sexy” in option 3 established. • Be careful, everything you standardize today becomes the legacy of – Covers & integrates potentially many fields & techniques tomorrow !

22 References That’s all folks [WarnerBros☺] [Jakobson 01] G. Jakobson, Management of Dynamic Networks and Services : Correlation-based Solutions, Invited Presentation, IFIP DSOM’2001, october 2001, Nancy, France. [ChenJS 00] W. Chen, N. Jain, S. Singh, ANMP : Ad hoc network Management Protocol, IEEE JSAC, August 1999. [ShenSJ 02] C.C. Shen, C. Srisathapornphat, C. Jaikaeo, An Adaptive Management Architecture for Ad Hoc Networks, IEEE Communications Magazine, February 2002, pp 108-115. [Phanse 02] K. Phanse, Policy-Based Quality of Service Management in Wireless Ad Hoc Networks, Preliminary Research Document for the Ph.D. Degree, Faculty of the Virginia Polytechnic Institute and State University, 2002 [draft-harold-jmxp] W. Harold, Java ™Management Extensions Protocol, draft-harold-jmxp-00, may 2003. [MunarettoAF 02] A. Munaretto, N. Agoulmine, M. Fonseca, Policy-based Management of Ad Hoc Enterprise Networks, HPOVUA 2002? [KregerHW 03] H. Kreger, W. Harold, L. William, Java and JMX : Building Manageable Systems, Addison Wesley, 2003. [Hansmann02] U. Hansmann, R. Mettala, A. Purakayastha, P. Thompson, SYNCML : Synchronizing and Managing Your Mobile Data. Prentice Hall, 2002 [RepProt02] SyncML Representation Protocol v1.1. SyncML Forum (www.syncml.org), 2002 [RepDevProt02] SyncML Representation Protocol, Device Management Usage SyncML, Forum ??? ??? (www.syncml.org), 2002 ? [DevManagProt02] SyncML Device Management Protocol,SyncML Forum (www.syncml.org), 2002 [SyncMLNotif] SyncML Notification Initiated Session, SyncML Forum (www.syncml.org), 2002 [SyncMLBootstrap] SyncML Device Management Bootstrap, SyncML Forum (www.syncml.org), 2002 [SyncMLDevTree] SyncML Device Management Tree and Description Session, SyncML Forum (www.syncml.org), 2002 [SyncMLObjects] SyncML Device Management Standardised Objects, SyncML Forum (www.syncml.org), 2002 [SyncMLBinding] SyncML HTTP Binding, SyncML Forum (www.syncml.org), 2002

Conclusion (4) : advice

To young researchers & Ph.D. students in the discipline • Management needs NEW models and techniques • Be creative – Do not stick to standards and implementation details – Free your mind ! – Incremental research as a backup • Validate your ideas – Models exist, environments too Mordillo drawings – Formalize your protocols – Simulate their behavior – Evaluate the performance – Implement when sounded • Cooperate – There is a management discipline with an associated community of some very pleasant, motivated and competent people • Be hungry of history – IM, LISA, DSOM, NOMS, MMNS, – « The one that does not know where he comes from , does not know where he is heading to because he does not know where he is ! » from ????