Network Working Group Sandeep Adwankar Internet-Draft Motorola, Inc. Expires: April 20, 2004 Venu Vasudevan Motorola, Inc. Sangita Mohan University Of Illinois at Chicago October 20, 2003 SYMPLE Scripting Protocol and architecture for seamless management of XML based mobile devices and SNMP based devices draft-adwankar-netconf-symple-00.txt Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 20, 2004. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract There is a need for XML based scripting mechanism that allows ease of script construction and delegation with standardized mechanism. A management script composed of a set of instructions will allow periodic, coordinated and policy based management action. This memo describes a method of expressing management script and architecture for seamless management of XML based mobile devices along with SNMP based devices. adwankar et al Expires April 20, 2004 [Page 1] Internet Draft SYMPLE Scripting Protocol October 20, 2003 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3 2. Architecture . . . . . . . . . . . . . . . . . . . . . . . 4 3. SYMPLE Protocol . . . . . . . . . . . . . . . . . . . . . 6 3.1 SyncML Introduction .. . . . . . . . . . . . . . . . . . 6 3.2 Synclet . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.3 Synclet Engine. . . . . . . . . . . . . . . . . . . . . . 9 4 SYMPLE Commands. . . . . . . . . . . . . . . . . . . . . 10 4.1 Policy Commands. . . . . . . . . . . . . . . . . . . . . 10 4.1.1 Guard Policy Element. . . . . . . . . . . . . . . . . . . 10 4.2 Action Commands. . . . . . . . . . . . . . . . . . . . . 12 4.2.1 Schedule Element. . . . . . . . . . . . . . . . . . . . . 12 4.2.2 Diagnostics Element. . . . . . . . . . . . . . . . . . . . 14 4.2.3 Log Element. . . . . . . . . . . . . . . . . . . . . . . 15 5. Seamless Management. . . . . . . . . . . . . . . . . . . 16 5.1 Multi-Protocol Gateway . . . . . . . . . . . . . . . . . . 17 5.2 Seamless Management Flow. . . . . . . . . . . . . . . . . 19 6. Conclusion. . . . . . . . . . . . . . . . . . . . . . . . 21 7. Security Considerations . . . . . . . . . . . . . . . . . 21 References . . . . . . . . . . . . . . . . . . . . . . . . 22 A. SYMPLE DTD. . . . . . . . . . . . . . . . . . . . . . . . 22 B. Management tree to MIB Mapping. . . . . . . . . . . . . . 23 adwankar et al Expires April 20, 2004 [Page 2] Internet Draft SYMPLE Scripting Protocol October 20, 2003 1. Introduction The SYMPLE (SYncML Programming LanguagE) is a SyncML-derived scripting language that extends SyncML semantics [1][2] in a lightweight manner suitable for resource-constrained devices. The SYMPLE provides support for the scheduling, evaluation and lifecycle management of scripts called as Synclets. To strike a balance between capabilities and deployment costs, SYMPLE is designed according to the following principles: 1. Embeddable within SyncML. SYMPLE scripts can be embedded within standard SyncML packages, allowing reuse of SyncML as a script distribution protocol. 2. Lightweight. SYMPLE is easy-to-learn, requiring only a small amount of code to define complex requirements that can be interpreted by a lightweight extension of SyncML platform. 3. Extensible. Devices can support different variants of Symple in accordance with their resources and computing capabilities, with Synclets being discarded without error by SYMPLE-unaware (but SyncML-aware) devices. There is a need to manage SYMPLE based mobile devices from widely used management protocol such as SNMP[3][4]. This allows problem diagnostics involving combination of mobile and non-mobile devices. The manager can initiate software upgrade that spans mobile and non-mobile devices. It allows manager to install and configure enterprise applications simultaneously. The architecture allows use of conventional enterprise management protocol such as SNMP as the unified management platform, while at the same time supporting a diversity of management protocols. This allows a unified view of the enterprise without expecting enterprise management agents to be supported on mobile devices. The method uses a multi-protocol gateway that translates between the management operations dispatched from a management station, and the specific management protocol that enacts it. The rest of the document is organized as follows. Section 2 introduces the architecture of the SYMPLE for management scripting and seamless management of devices that support different protocols. Section 3 introduces synclet that extends SyncML DM. Section 4 describes various Symple commands with examples. Section 5 details multi-protocol gateway and seamless management flow. adwankar et al Expires April 20, 2004 [Page 3] Internet Draft SYMPLE Scripting Protocol October 20, 2003 2. Architecture +------------------------------------------------------------+ | +--------------+ | | | SNMP | | | | MIB | | | +--------------+ | | ^ | | | | | v | | +-------------+ +----------------+ +-------------+ | | | SNMP | | Multi-Protocol | | SYMPLE | | | | Manager |<-->| Gateway |<--> | Manager | | | +-------------+ +----------------+ +-------------+ | | ^ ^ | | | | | | v v | | +----------------+ +----------------+ | | | | | | | | | +------------+ | | +------------+ | | | | | SNMP | | | | SYMPLE | | | | | | Management | | | | Management | | | | | | Agent | | | | Agent | | | | | +------------+ | | +------------+ | | | |----------------| |----------------| | | | | | | | | | | | | | | | Non-mobile | | Mobile | | | | Device | | Device | | | | | | | | | +----------------+ +----------------+ | +------------------------------------------------------------+ As shown in figure above, the universal manager spans the network controlled by the enterprise and a core communications network such as the Internet to manage devices connected to each of these networks. A user controlled PAN in this case is considered part of the enterprise network. Enterprises maintain Management Information Base (MIB) [6] that consists of collection of managed objects for each type of enterprise device. The enterprise management system (EMS) provides a complete view of entire enterprise including all devices, hosts and routers in the enterprise. adwankar et al Expires April 20, 2004 [Page 4] Internet Draft SYMPLE Scripting Protocol October 20, 2003 SNMP based devices are located through discovery mechanisms and the SNMP Manager directly executes the requested management action. Mobile devices advertise their presence with their capabilities data to the multi-protocol gateway. The multi-protocol gateway acts as a proxy and represents mobile device to the SNMP manager. The management action on a mobile device will be routed through the multi-protocol gateway. A mobile device has a SYMPLE terminal management (TM) agent that is customized for its capabilities. The TM agent has access to firmware specific details and can perform management operations such as getting or setting configuration data, software image installation, and fault and security management. The TM agent talks with a SYMPLE Manager using a protocol that the device can support. For example a mobile device that supports only Short Message Service (SMS), management actions and results/responses are sent over SMS between TM agent and TM server. The multi-protocol gateway maps the destination of a management action to a particular mobile device. For example the multi-protocol gateway advertises a GSM terminal with International Mobile Equipment Identity (IMEI) "000000011234564" as IP address 10.1.100.212 in the enterprise network. For management action of mass software upgrade for all devices in 10.1.100 subnet, the management action destined for 10.1.100.212 is routed to the multi-protocol gateway. The multi-protocol gateway then maps it to the corresponding IMEI and from the capabilities data of the device, it converts management action Protocol Data Unit (PDU) to terminal management protocol specific PDU. The multi-protocol gateway then schedules the management action on the corresponding SYMPLE manager. The SYMPLE manager participates in management protocol exchanges with terminal management agent to perform management action such as software upgrade. The multi-protocol gateway converts management atomicity requirements to individual device protocol levels as shown table below. +-----------------------------------------------------------------+ | Entity | Atomic Operation | +----------------+------------------------------------------------+ | Device | Device software upgrade with change in | | | corresponding configuration. | +----------------+------------------------------------------------+ | Group | Changes in group protocol such as multicast. | +----------------+------------------------------------------------+ | Enterprise | Business process change. | +----------------+------------------------------------------------+ adwankar et al Expires April 20, 2004 [Page 5] Internet Draft SYMPLE Scripting Protocol October 20, 2003 The following characteristics make this architecture scalable: o Support for diverse terminal management protocols o Distributed terminal management servers based on protocols supported o Scheduling management actions on SYMPLE Manager based on availability of resources o Terminal management agent specific to a device based on hardware, software capabilities o Using layer 2 routing to advertise presence of intermittently connected devices 3 SYMPLE Protocol The SYMPLE provide the ability to postpone management operations, to allow effective completion of operations. It allows schedule coordinated terminal management operations across collections of terminals. It adds a powerful computing abstraction to SyncML-DM to facilitate comprehensive, automated, scalable systems management. For growing number of sophisticated mobile devices scripting allows optimized local management actions. 3.1 SyncML Protocol Introduction The SyncML standard was developed as an XML-based information synchronization standard designed specifically for the needs of the wireless industry. Thus, the SyncML protocol is lightweight to cater to device limitations, language-neutral and protocol-neutral. To suit device limitations, SyncML language constructs are kept fairly minimal, with the protocol not using some features (e.g., server sockets) that are yet to become pervasive on mobile devices. Because SyncML is XML-based, it is inherently language-neutral, and supports OEM-specific extensibility. In addition, the SyncML protocol can run over a number of underlying transport protocols including HTTP, WSP, and OBEX. SyncML's popularity in information synchronization led to its scope being expanded via SyncML-DM to include device management. SyncML-DM allows management actions to be performed on management objects, where a management object might represent a device configuration or the run-time software application environment. Actions taken against the former might include reading and setting parameter keys and values, while actions taken against the latter might include installing, upgrading, or uninstalling software elements. The signatures of the Get and Set methods on a management object are type-specific and may vary substantially in complexity. For instance, a management action for setting the device clock accepts a simple textual MIME type (text/plain) while an action to change the WAP browser settings requires new WAP provisioning blobs to be transmitted as part of the Set operation. Software upgrades present another example of a management action with significant payload adwankar et al Expires April 20, 2004 [Page 6] Internet Draft SYMPLE Scripting Protocol October 20, 2003 complexity. As shown in Figure below, SyncML-DM is a 2-phase protocol consisting of a setup phase for authentication and device information exchange, followed by a management phase that can be repeated multiple times to support complex manager-to-mobile sessions. A management session may also start with Packet 0 (the trigger), where the trigger may be out-of-band depending on the environment. Mobile Device Management Server | | | | |<-------------------------------------------------| | Package 0: Alert from server | | | |------------------------------------------------->| | Client initialization with client | Setup | credentials and device information | Phase |<-------------------------------------------------| | Server initialization with server | | credentials and management operations | |------------------------------------------------->| | Client response to management operations | Mgmt | | Phase |<-------------------------------------------------| | Server response to client management | | operation, and more management operations | | if session is to be continued | | | 3.2 Synclet A Synclet is an executable script consisting of Symple commands. A Synclet specification comprises of two parts: a policy and an action routine. The Synclet policy specifies non-functional aspects of the Synclet such as if, when and how often it should be executed. The action routine is the management script that makes up the Synclet. The policy, action routine separation allows the same functional Synclet to be reused in different circumstances. adwankar et al Expires April 20, 2004 [Page 7] Internet Draft SYMPLE Scripting Protocol October 20, 2003 The figure below shows the architecture of Symple management agent. As shown in the figure the policy engine enforces policy that can act as trigger condition for synclet. The Symple parser along with XML parser parses the SyncML package (that encapsulates synclets) received by the device. The result of parsing is a set of synclets that are interpreted and executed by the Synclet Engine. +---------------------+ | Synclet Engine | | | +---------------------+ | Policy Engine | | | +---------------------+ | Sync Engine | | | +---------------------+ | Symple Parser | | | +---------------------+ | XML Parser | | | +---------------------+ | Firmware | | | +---------------------+ Synclets are transported over the SyncML protocol, which in turn is bearer-agnostic. Thus Synclets may be transported over HTTP, SMTP or other IP-based protocols. To be compatible with Synclet unaware clients, Synclets are carried as the payload i.e., as nested tags in a Synclet XML element within the SyncML body. Standard SyncML engines that are not Synclet-enabled will simply ignore the Synclet scripts within the enclosing Synclet tags. As Synclet upload and execution are decoupled, multiple Synclets with differing execution policies may be carried in a single SyncML session, i.e. nested within the same Synclet tag. Synclet bundles are a convenience mechanism that allows a group of Synclets to be loaded in a single SyncML session, and be henceforth accessed by the remote operator using a single bundle name. The bundle notion facilitates packaging, distribution and policy management of Synclets. adwankar et al Expires April 20, 2004 [Page 8] Internet Draft SYMPLE Scripting Protocol October 20, 2003 3.3 Synclet Engine Synclet Engine is terminal resident container layered over the standard client-side Sync Engine. They host and manage Synclets that are dispatched to the terminal. Synclet Engine perform functions relating to Synclet lifecycle management, and serve as secure sandboxes for Synclet execution. Lifecycle functions include (de) activation, multitasking between concurrently executing Synclets, and the suspension and the revival of Synclets that were stopped due to adverse terminal conditions (e.g. deteriorating battery level). To avoid race conditions on the device, Synclet Engine support virtual multitasking where multiple terminal-resident Synclets might have partially executed at any point in time, but only one Synclet is actually executing at any instant. The SYMPLE specifications include a model of conditional, policy-based execution. The policy engine determines the subset of Activatable Synclets based on evaluating individual Synclet policies. Policies could be based on absolute time, invocation cardinality (number of times a Synclet should be run), and device state. More sophisticated Synclet Engine could support the interleaved execution of multiple synclets. These could include allowing a certain maximum number of concurrent synclets, deadlock avoidance or resolution between concurrent synclets, and fairness policies for Synclet swap-out whereby idle synclets are swapped out for other waiting synclets. Synclet Engine provide a constrained environment to executing synclets, bounding and monitoring their access to the underlying terminal. Synclets are privileged applications have limited access to retrieving and modifying the device state via a special set of closed classes in Java. Two factors simplify sandboxing in Synclet. First, the Synclet dispatching capability is accessible only to a small number of trusted parties (namely service operators). So authentication solutions such as digital signatures can check the signature against a very small universe of trusted sources. Secondly, the use of a scripting language allows for language safety verifiers to be developed, and for sandboxes to suspend (and resume) the script at arbitrary points in the program. Synclets face the unique situation in executing on mobile devices, namely that the device may be powered off at any time without operator control. Synclet Engine lifecycle management techniques need to allow for script re-entrancy in such adverse situations. Script re-entrancy might involve re-prioritizing Synclets when they are restarted, to reflect the new environment (analogous to adjusting the nice value of processes in Unix). This is handled by re-evaluating Synclet policies of awakening Synclets in the changed environment. adwankar et al Expires April 20, 2004 [Page 9] Internet Draft SYMPLE Scripting Protocol October 20, 2003 4 SYMPLE Commands This section elaborates on the kinds of policies supported in Symple, and the SyncML extensions supported in an action routine. SyncML is extended in two ways in the action routine language: the addition of a few new commands, and support for conditional command execution (guarded commands) environment. 4.1 Policy Commands Policies are specifiable at three levels of granularity: device, synclet bundle, and synclet. Device level policies apply to all scripts that will execute on the device from the time the policy is installed. For instance, a device policy may dictate that only one Synclet shall be active at a time. Synclet bundle policies apply to a collection of synclets that were loaded as an aggregate, perhaps because they collectively perform a single cohesive task. Synclet policies govern the execution of the Synclet's action routine, and may include the maximum time a Synclet is allowed to run, resources that should be allocated before the Synclet should be activated, or recovery actions when Synclet execution is interrupted. Device policies tend to be more static and persistent than Synclet bundle and Synclet level policies. 4.1.1 Guard Policy Element The semantics of guard policy element is as below: Element: Description: Conditionally executes a management action based on result of guard route execution Parameters: Attribute: Management Tree Node URI Condition: (greaterThan | lessThan | equals) Threshold: trigger threshold. Example1: The following synclet is an example of guard policy in which the security code is changed only if the device has sufficient energy level to satisfy the management action of changing the security code. adwankar et al Expires April 20, 2004 [Page 10] Internet Draft SYMPLE Scripting Protocol October 20, 2003 +------------------------------------------------------------------+ | | | | | ./DevDetail/EnergyLevel | | greaterThan | | 5 | | | | | | 1 | | | | text/plain | | | | | | ./Ext/Settings/Security | | SECURITY CODE | | | | | | | +------------------------------------------------------------------+ Example2: The following synclet is an example of guard policy in which if the App1 execution count is less than 2 then the assetMgmt script is downloaded and executed. +------------------------------------------------------------------+ | | | | | | | ./Ext/Applications/App1/ExecutionCount | | | | lessThan | | 2 | | | | | | 1 | | | | text/plain | | | | | | | | | | http://www.symple.org/scripts/assetMgmt | | | | | | | | | | | +------------------------------------------------------------------+ adwankar et al Expires April 20, 2004 [Page 11] Internet Draft SYMPLE Scripting Protocol October 20, 2003 The above example shows policy based asset management where assets on a terminal are managed based on operator defined sets of rules. The assets on a device include user data, applications, and user purchased applications and games. The operator-defined rules will result in managing assets in such a way as that extends the capabilities of the resource constrained devices. The assetMgmt script in such a case will transparently back up the asset information on the server. The assets are restored to the device when they are needed. The backup and restore of assets from terminal to server is achieved using extension of SyncML protocol. The user and assets are transparent to the asset management process. Thus the policy will make the device memory bigger than the actual physical memory. With extended memory, device is able to hold more assets than that can be possible physically. 4.2 Action Commands 4.2.1 Schedule Element The semantics of schedule management command is as below: Element: Description: Schedules the management commands specified as per the parameters Parameters: CmdID: Id for the command Meta: Meta Information parameters Date: Date and Time to schedule the management action Period: Interval between schedule operations Repeat: Number of times the schedule operation will be repeated (Get|Replace|Add|Delete|Exec): Management actions Example: The following synclet (policy element not shown) is an example of management action of periodically scheduling performance management operation of gathering network latency information. adwankar et al Expires April 20, 2004 [Page 12] Internet Draft SYMPLE Scripting Protocol October 20, 2003 +------------------------------------------------------------------+ | | | 1 | | | | 2 | | | | http://www.symple.org | | | | 1032795720000 | | 1 | | 1 | | | | | | | | | | ./Sync/DM/Performance/Network/Latency | | | | | | | | | | application/vnd.syncml-devinf-devicemanagement+xml | | | | | | | | | | | | | +------------------------------------------------------------------+ The service performance measurement involves measurement of various performance metrics over period of time. The typical measurements taken from the device include 1.Success Rate in terms of user logons 2.Delays: Initial access, Round Trip, Server Response Time 3.Availability: Is Server responding? 4.Quality: Latency (average), Bandwidth (average) 5.Report application "performance", e.g. browser/MP3 player reports download speed In this scenario, the operator sends Synclet to the device that is configured to take measurements, i.e. to monitor local conditions such as local storage usage, application performance, network performance, authentication failures, etc. At an appropriate time, the synclet may initiate a management session in which it would relay such information up to the management server for further processing. An example of an application performance measurement is that of web page availability. If the availability of a web page to a mobile terminal is guaranteed to be a certain rate, such as 99%, it might be desirable to measure the availability of the page from the terminal directly, so as to ensure that an end-to-end measurement is taken. This is the only way, in fact, to guarantee that that are adwankar et al Expires April 20, 2004 [Page 13] Internet Draft SYMPLE Scripting Protocol October 20, 2003 no broken links in the chain of applications, middleware, and network elements between the web server and the terminal. The terminal could be configured to test the availability of a particular URL periodically. An exceptional condition, such as that network connectivity is available but the particular URL cannot be fetched, might trigger a local event that ultimately causes a management server to be informed of the situation. Presumably, the management server would, upon receipt of this data, present it to an administrator who could take action to prevent the service level agreement from being broken, and the service provider losing revenue. Such a measurement taken along with GPS coordinates will provide operator with "rough" spots in the network. Before any active measurements are taken, the management system may be used to configure the device regarding which measurements to record, as well as under which circumstances a management session should be initiated. In other words, the device may store local measurements that are not considered important enough to warrant a client-initiated session with a management server. Sometimes the recording of local measurements is equated with the generation of local events. An event might be, for example, that a particular measurement exceeds a particular value. Such an event might be stored locally, possibly for later retrieval by a management server during an explicit diagnostic session in which the administrator wishes to see these events. Or, a particular event may be important enough (determined by some configuration parameters or a policy) to warrant the client initiating a session with a management server. 4.2.2 Diagnostics Element The semantics of diagnostics management command is as below: Element: Description: Performs multiple checks for various configuration nodes Parameters: Assert: A single check for a configuration node Parameters: Item: Container with management node URI and desired data Exception: Fix for failed check Parameters: (Replace|Add|Delete|Exec) Management actions CatchAll: Fix for all failed checks Parameters: (Replace|Add|Delete|Exec) Management actions adwankar et al Expires April 20, 2004 [Page 14] Internet Draft SYMPLE Scripting Protocol October 20, 2003 Example: The following synclet (policy element not shown) is an example of management action of diagnosing reported problem with browser. The diagnostics synclet will perform series of checks with series of asserts and will determine cause of problem. For example, if there is problem with GPRS settings, it will download web_settings and replace existing default web session. +------------------------------------------------------------------+ | | | 1 | | | | 2 | | | | | | | | ./Sync/DM/WAP/WAPSTNG1/GPRS_APN | | | | internet.operator.com | | | | | | | | | | | | | | ./Sync/DM/WAP/DEFAULTWEBSESSION| | | | www.symple.org/web_settings | | | | | | | | | | | +------------------------------------------------------------------+ The diagnostics scenario demonstrates the ability for the customer representative to download a diagnostic Synclet into a suspected faulty device. The diagnostics Synclet once downloaded will automatically execute and perform perfunctory or sophisticated diagnostic checks of the device. The results of the diagnostic checks can be relayed to the customer representative as part of catchall handling who can then better assist the user with their problems. 4.2.3 Log Element The semantics of log management command is as below: Element: Description: Start or stops logging adwankar et al Expires April 20, 2004 [Page 15] Internet Draft SYMPLE Scripting Protocol October 20, 2003 Parameters: Attribute: Management Tree Node URI Action: (start | stop) Duration: Time to log (Optional parameter, valid for start) Example: The following synclet (policy element not shown) is an example of management action of logging security lock state of the device. The log duration is for 24 hours and will help in finding out any possible security violations. The event log can consists of call processing events, application execution events, signal strength readings, location readings, local conditions like battery charge state, output power level etc. +------------------------------------------------------------------+ | | | 1 | | | | 2 | | | | ./Ext/Settings/LockState | | | | | | start | | | | | | 86400 | | | | | | | +------------------------------------------------------------------+ Appendix A presents the SYMPLE DTD. 5. Seamless Management The management protocols like SNMP and SyncML differ in a number of attributes such as o Security Mechanism o Access Control Lists o Addressing Mechanism o MIB o Protocol Representation Format o Protocol layers o Notifications adwankar et al Expires April 20, 2004 [Page 16] Internet Draft SYMPLE Scripting Protocol October 20, 2003 5.1 Multi-Protocol Gateway The multi-protocol gateway is a software entity that represents a terminal (having its own terminal specific management protocol) in the enterprise management system. The multi-protocol gateway makes the enterprise management system believe that the terminal is like any other manageable entity in the enterprise. At the same time it uses terminal specific management protocols for management of terminals. Following are the main components of the Multi-protocol gateway as shown in Figure below. +-----------------------------+ | | | Notifier | | | +-----------------------------+ | | | Address Mapper | | | +-----------------------------+ | | | MIB Mapper | | | +-----------------------------+ | | | Job Scheduler | | | +-----------------------------+ | | | Protocol Converter | | | +-----------------------------+ Protocol Converter: This component is responsible for the conversion of the SNMP protocol to the Symple-SyncML protocol. This includes mapping atomicity requirements on to the terminal specific protocol. This component transforms SNMP PDU's to SyncML packages. In this transformation process, SNMP security credentials are converted to SyncML based security credentials required by Symple Manager. adwankar et al Expires April 20, 2004 [Page 17] Internet Draft SYMPLE Scripting Protocol October 20, 2003 Address Mapper: The Multi-protocol gateway maintains a list of the mobile devices that can be reached. This list is populated by a handshake or a discovery mechanism that is exchanged between the Multi-Protocol Gateway and the device. The Mapper maps the address of the device on the enterprise address space. For example, in the case of a GSM terminal, it allows the mapping of a terminal IMEI to the enterprise local private IP address space. The Mapper advertises reach-ability to this local private IP address space from the enterprise address space. It then provides translation from the local private IP address space to the terminal IMEI. MIB Mapper Appendix B presents the mapping of management tree of a mobile device to SNMP MIB. Job Scheduler: This component is responsible for the load balancing of terminal management activities. It schedules TM operations depending on the Symple manager availability and availability of scarce wireless resources in case of wireless devices. Notifier: Since the time taken for Symple protocol over wireless bearer will be more than that expected in the SNMP management, the Notifier allows notifying the SNMP manager after the terminal management task is complete. adwankar et al Expires April 20, 2004 [Page 18] Internet Draft SYMPLE Scripting Protocol October 20, 2003 5.2 Seamless Management Flow Figure below shows a sequence of exchanges between various components of the Universal Manager. These sequences of steps are explained below. +------------+ +-----------+ +------------+ +----------+ | SNMP | | Multi | | SYMPLE | | Mobile | | Manager | | Protocol | | Manager | | Terminal | | | | Gateway | | | | | +------------+ +-----------+ +------------+ +----------+ | (1)Terminal | Resolve to | | | Management | terminal | | |------------------->|--- address. | | | Operation | | credentials| | | |<-- check | | | | | Trigger message | | (3)Notify status | (2)Schedule new| to activate agent |<-------------------|--------------->|---------------> | | | TM | | | | | Credentials, | | | |<--------------->|(4) | | | Capabilities |Execute | | | exchange | TM | | | |operation | | | Send TM task | | | |---------------->|--- | | | Send Results | | | | |<----------------|<-- | | | | | | | Send Status | | |(5)Send Results |---------------->| | (6)Results to |<---------------| | |<-------------------| | | | Enterprise | | | | Manager | | | 1. Terminal Management Operation For a terminal management action, such as the querying of the manufacturer name of a GSM terminal, the SNMP manager is unaware of the presence of such a terminal and either of the following operations take place. a] The enterprise management system based on additional information such IMEI decides to route management action to multi-protocol gateway, or b] Multi-protocol gateway advertises addressability to that IMEI as a certain IP address and terminal management actions take place on this proxy IP address. adwankar et al Expires April 20, 2004 [Page 19] Internet Draft SYMPLE Scripting Protocol October 20, 2003 In either case the enterprise management system routes the SNMP PDU for the corresponding management action to the Multi-Protocol Gateway instead of sending the SNMP PDU directly to the mobile device. The SNMP PDU's host and port are set to the host and port that the Multi-Protocol Gateway is listening on as opposed to the host and port of the mobile device. The SNMP PDU thus sent contains the Operation Name (e.g. Get, Get Next, Set), the OID to be queried, (optionally IMEI of the GSM terminal and the value of the OID if it is a Set Operation), SNMP credentials and a request ID of the SNMP PDU. 2. Protocol Conversion On receiving a SNMP Packet, the Multi-Protocol Gateway extracts the required information from the SNMP PDU. The Multi-Protocol gateway performs a credentials check and maps the SNMP OID to the corresponding Symple management tree node. In case the IMEI is not sent, it maps the destination IP address to the IMEI of the device. The Protocol Converter after fetching the corresponding SyncML parameter hands the same over to the Scheduler that schedules the task on the Symple manager. The parameters sent as part of the request to the Symple Manager include the Operation Name i.e. (Get, Get Next, Set), SyncML management tree node, the value of the SyncML parameter if it is a Set Operation, Unique Id for the device (e.g. IMEI in case of GSM terminal) and the Request ID (associated with each SNMP PDU) of the operation. Figure below shows a part of the SyncML command actually sent to the mobile device to retrieve the manufacturer name from the management tree of the device. +------------------------------------------------------------------+ | | | 2 | | | | text/plain | | | | | | ./DevInfo/Man | | | | | +------------------------------------------------------------------+ 3. Status Notification The Notifier component of the Multi-Protocol Gateway now sends back a status to the SNMP manager informing it that the task has been added to the Symple Manager and hence prevents time outs and retransmission of SNMP PDUs. The status information is sent to the port where the SNMP manager is listening for information from the Multi-Protocol Gateway. adwankar et al Expires April 20, 2004 [Page 20] Internet Draft SYMPLE Scripting Protocol October 20, 2003 4. SyncML Protocol exchanges The Symple manager exchanges credentials and capabilities (after sending optional trigger message ) with the TM agent. The Symple manager then sends a management action to the TM agent as part of the SyncML package. The TM agent at the mobile terminal executes the requested operation and sends back the results and status to the Symple manager. 5. Notification of results The Protocol Converter at the Multi-Protocol Gateway converts results from the Symple manager to SNMP PDUs and sends the SNMP packet to the SNMP manager listening on a different port for response SNMP PDUs. The response PDU also contains information on the requested Command either Get/Get Next/Set, the request ID associated with the request SNMP Packet, SNMP OID, value associated with the OID and the status if the operation executed on the phone was successful or not. On receiving the response SNMP Packet from the Multi-Protocol Gateway the packet information is extracted for the results. The performance results of dispatch of Symple scripts and seamless management is presented in [5][6]. 5. Conclusion The Symple aims to provide XML based complex scripting mechanism to device management. It allows sophisticated set of management capabilities to be supported in resource-constrained devices. It allows easy authoring of coordinated operations involving performance management and diagnostics. A uniform protocol across all mobile and non-mobile devices is infeasible as management protocols are optimized for a certain family of devices. The architecture for seamless management enables atomic transactions that are executed across diverse devices. It allows distributed diagnostics across heterogeneous hosts and protocols. Security Considerations The Symple scripting protocol relies on SyncML DM Security specification [7]. adwankar et al Expires April 20, 2004 [Page 21] Internet Draft SYMPLE Scripting Protocol October 20, 2003 References 1. The SyncML Device Management Protocol, version 1.1.2, Open Mobile Alliance Ltd. June 2003 2. The SyncML Representation Protocol Device Management Usage, version 1.1.2, Open Mobile Alliance Ltd. June 2003 3. J. Case, M. Fedor, M. Schoffstall, J. Davin. A Simple Network Management Protocol. RFC 1157, Internet Engineering Task Force, May 1990. 4. K. McCloghrie, M. Rose. Management Information Base for Network Management of TCP/IP-based internets:MIB-II. RFC 1213, Internet Engineering Task Force, March 1991. 5. MobiMan: Bringing Scripted Agents to Wireless Terminal Management, V. Vasudevan, S. Adwankar, N. Narsimhan, DSOM 2003 6. Universal Manager: Seamless Management of enterprise mobile and non-mobile devices, S. Adwankar, S. Mohan, V. Vasudevan, MDM 2004 7. The SyncML Device Management Security, version 1.1.2, Open Mobile Alliance Ltd. June 2003 Appendix A.SYMPLE DTD +------------------------------------------------------------------+ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | adwankar et al Expires April 20, 2004 [Page 22] Internet Draft SYMPLE Scripting Protocol October 20, 2003 | | | | | | | | | | | | | | | | +------------------------------------------------------------------+ Appendix B. Management tree to MIB Mapping MOBILE-MIB DEFINITIONS ::= BEGIN IMPORTS mgmt, NetworkAddress, IpAddress, Counter, Gauge, TimeTicks FROM RFC1155-SMI OBJECT-TYPE FROM RFC-1212; mgmt OBJECT IDENTIFIER ::= { iso org(3) dod(6) internet(1) mgmt(2) } directory OBJECT IDENTIFIER ::= { internet 1 } experimental OBJECT IDENTIFIER ::= { internet 3 } private OBJECT IDENTIFIER ::= { internet 4 } enterprises OBJECT IDENTIFIER ::= { private 1 } Company OBJECT IDENTIFIER ::= { enterprises xxx } -- textual conventions DisplayString ::= OCTET STRING -- This data type is used to model textual information taken -- from the NVT ASCII character set. By convention, objects -- with this syntax are declared as having -- (SIZE (0..255)) PhysAddress ::= OCTET STRING -- This data type is used to model media addresses. For many -- types of media, this will be in a binary representation. -- For example, an ethernet address would be represented as -- a string of 6 octets. -- groups in MOBILE-MIB DevInfo OBJECT IDENTIFIER ::= { Company 1 } adwankar et al Expires April 20, 2004 [Page 23] Internet Draft SYMPLE Scripting Protocol October 20, 2003 DevDetail OBJECT IDENTIFIER ::= { Company 2 } Ext OBJECT IDENTIFIER ::= { DevDetail 1 } Settings OBJECT IDENTIFIER ::= { Ext 1 } WAP OBJECT IDENTIFIER ::= { Ext 2 } Log OBJECT IDENTIFIER ::= { Ext 3 } Applications OBJECT IDENTIFIER ::= { Ext 4 } App1 OBJECT IDENTIFIER ::= { Applications 1 } -- the DevInfo group -- Directory which holds device info Man OBJECT-TYPE SYNTAX DisplayString (SIZE (0..255)) ACCESS read-only STATUS mandatory DESCRIPTION "Manufacture name." ::= { DevInfo 1 } Mod OBJECT-TYPE SYNTAX DisplayString (SIZE (0..255)) ACCESS read-only STATUS mandatory DESCRIPTION "Model name." ::= { DevInfo 2 } DevID OBJECT-TYPE SYNTAX DisplayString (SIZE (0..255)) ACCESS read-only STATUS mandatory DESCRIPTION "Device serial number." ::= { DevInfo 3 } Lang OBJECT-TYPE SYNTAX DisplayString (SIZE (0..255)) ACCESS read-write STATUS mandatory DESCRIPTION "Device language." ::= { DevInfo 4 } DmV OBJECT-TYPE SYNTAX DisplayString (SIZE (0..255)) ACCESS read-only STATUS mandatory adwankar et al Expires April 20, 2004 [Page 24] Internet Draft SYMPLE Scripting Protocol October 20, 2003 DESCRIPTION "Device version." ::= { DevInfo 5 } -- the DevDetail group OEM OBJECT-TYPE SYNTAX DisplayString (SIZE (0..255)) ACCESS read-only STATUS mandatory DESCRIPTION "Specify OEM of the device (ex, Motorola)." ::= { DevDetail 1 } FwV OBJECT-TYPE SYNTAX DisplayString (SIZE (0..255)) ACCESS read-only STATUS mandatory DESCRIPTION "Firmware version." ::= { DevDetail 2 } SwV OBJECT-TYPE SYNTAX DisplayString (SIZE (0..255)) ACCESS read-only STATUS mandatory DESCRIPTION "Software version." ::= { DevDetail 3 } HwV OBJECT-TYPE SYNTAX DisplayString (SIZE (0..255)) ACCESS read-only STATUS mandatory DESCRIPTION "Hardware version." ::= { DevDetail 4 } DevTyp OBJECT-TYPE SYNTAX DisplayString (SIZE (0..255)) ACCESS read-only STATUS mandatory DESCRIPTION "Device type." ::= { DevDetail 5 } Bearer OBJECT-TYPE SYNTAX DisplayString (SIZE (0..255)) ACCESS read-only STATUS mandatory DESCRIPTION "Bearer." ::= { DevDetail 6 } EnergyLevel OBJECT-TYPE adwankar et al Expires April 20, 2004 [Page 25] Internet Draft SYMPLE Scripting Protocol October 20, 2003 SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "Energy Level. e.g Battery level" ::= { DevDetail 7 } -- the Settings group -- Parent Settings directory clock OBJECT-TYPE SYNTAX DisplayString (SIZE (0..255)) ACCESS read-write STATUS mandatory DESCRIPTION "Set date and time." ::= { Settings 1 } ActiveRing OBJECT-TYPE SYNTAX INTEGER ACCESS read-write STATUS mandatory DESCRIPTION "Replace active ring tone type setting." ::= { Settings 2 } ActiveAlert OBJECT-TYPE SYNTAX INTEGER ACCESS read-write STATUS mandatory DESCRIPTION "Replace active alert type setting (Silent, Vibrate, Loud, etc)." ::= { Settings 3 } AlertLevel OBJECT-TYPE SYNTAX INTEGER ACCESS read-write STATUS mandatory DESCRIPTION "Replace alert level setting." ::= { Settings 4 } DTMF OBJECT-TYPE SYNTAX INTEGER ACCESS read-write STATUS mandatory DESCRIPTION "Replace DTMF settings (Short, Long, Off)." ::= { Settings 5 } SecurityCode OBJECT-TYPE SYNTAX DisplayString (SIZE (0..255)) ACCESS read-write adwankar et al Expires April 20, 2004 [Page 26] Internet Draft SYMPLE Scripting Protocol October 20, 2003 STATUS mandatory DESCRIPTION "Replace the security code." ::= { Settings 6 } LockState OBJECT-TYPE SYNTAX INTEGER ACCESS read-write STATUS mandatory DESCRIPTION "Security lock state (Locked, Unlocked)." ::= { Settings 7 } -- the WAP group -- WAP folder settings Defaultwebsession OBJECT-TYPE SYNTAX DisplayString (SIZE (0..255)) ACCESS read-write STATUS optional DESCRIPTION "Set default web session on phone." ::= { WAP 1 } -- the Log group -- Directory which holds Log Mgmt Node CallProcessing OBJECT-TYPE SYNTAX DisplayString (SIZE (0..255)) ACCESS read-write STATUS optional DESCRIPTION "Call Processing Log." ::= { Log 1 } Location OBJECT-TYPE SYNTAX DisplayString (SIZE (0..255)) ACCESS read-write STATUS optional DESCRIPTION "Location Log." ::= { Log 2 } -- the Applications group -- Directory which holds Applications Info ExecutionCount OBJECT-TYPE SYNTAX INTEGER ACCESS read-write STATUS optional DESCRIPTION adwankar et al Expires April 20, 2004 [Page 27] Internet Draft SYMPLE Scripting Protocol October 20, 2003 "App1 Execution Count." ::= { App1 1 } END Author's Address Sandeep Adwankar Motorola 1301 East Algonquin Rd, MS IL02-2240, Schaumburg, IL 60196 USA EMail: sandeep.adwankar@motorola.com adwankar et al Expires April 20, 2004 [Page 28]