Internet DRAFT - draft-adwankar-netconf-symple
draft-adwankar-netconf-symple
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: <Guard>
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
+------------------------------------------------------------------+
|<Synclet> |
| <Guard> |
| <Attribute> ./DevDetail/EnergyLevel </Attribute> |
| <Condition> greaterThan </Condition> |
| <Threshold> 5 </Threshold> |
| </Guard> |
| <Replace> |
| <CmdID>1</CmdID> |
| <Meta> |
| <Format xmlns="syncml:metinf"> text/plain </Format> |
| </Meta> |
| <Item> |
| <Target><LocURI>./Ext/Settings/Security</LocURI></Target> |
| <Data> SECURITY CODE </Data> |
| </Item> |
| </Replace> |
|<Synclet> |
+------------------------------------------------------------------+
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.
+------------------------------------------------------------------+
|<Synclet> |
| <Guard> |
| <Attribute> |
| ./Ext/Applications/App1/ExecutionCount |
| </Attribute> |
| <Condition> lessThan </Condition> |
| <Threshold> 2 </Threshold> |
| </Guard> |
| <Exec> |
| <CmdID>1</CmdID> |
| <Meta> |
| <Format xmlns="syncml:metinf"> text/plain </Format> |
| </Meta> |
| <Item> |
| <Target> |
| <LocURI> |
| http://www.symple.org/scripts/assetMgmt |
| </LocURI> |
| </Target> |
| </Item> |
| </Exec> |
|<Synclet> |
+------------------------------------------------------------------+
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: <Schedule>
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
+------------------------------------------------------------------+
|<Synclet> |
| <CmdID>1</CmdID> |
| <Schedule> |
| <CmdID>2</CmdID> |
| <Meta> |
| <URI>http://www.symple.org</URI> |
| </Meta> |
| <Date>1032795720000</Date> |
| <Period>1</Period> |
| <Repeat>1</Repeat> |
| <Get> |
| <Item> |
| <Target> |
| <LocURI> |
| ./Sync/DM/Performance/Network/Latency |
| </LocURI> |
| </Target> |
| <Meta> |
| <Type xmlns='syncml:metinf'> |
| application/vnd.syncml-devinf-devicemanagement+xml |
| </Type> |
| </Meta> |
| </Item> |
| </Get> |
| </Schedule> |
|</Synclet> |
+------------------------------------------------------------------+
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: <Diagnostics>
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.
+------------------------------------------------------------------+
|<Synclet> |
| <CmdID>1</CmdID> |
| <Diagnostics> |
| <CmdID>2</CmdID> |
| <Assert> |
| <Item> |
| <Target> |
| <LocURI>./Sync/DM/WAP/WAPSTNG1/GPRS_APN</LocURI> |
| </Target> |
| <Data>internet.operator.com</Data> |
| </Item> |
| </Assert> |
| <Exception> |
| <Replace> |
| <Item> |
| <Target> |
| <LocURI>./Sync/DM/WAP/DEFAULTWEBSESSION</LocURI>|
| </Target> |
| <Data>www.symple.org/web_settings</Data> |
| </Item> |
| </Replace> |
| <Exception> |
| </Diagnostics> |
|</Synclet> |
+------------------------------------------------------------------+
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: <Log>
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.
+------------------------------------------------------------------+
|<Synclet> |
| <CmdID>1</CmdID> |
| <Log> |
| <CmdID>2</CmdID> |
| <Attribute> |
| ./Ext/Settings/LockState |
| </Attribute> |
| <Command> |
| start |
| </Command> |
| <Duration> |
| 86400 |
| </Duration> |
| </Log> |
|</Synclet> |
+------------------------------------------------------------------+
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.
+------------------------------------------------------------------+
| <Get> |
| <CmdID>2</CmdID> |
| <Meta> |
| <Format xmlns="syncml:metinf"> text/plain </Format> |
| </Meta> |
| <Item> |
| <Target><LocURI>./DevInfo/Man</LocURI></Target> |
| </Item> |
| </Get> |
+------------------------------------------------------------------+
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
+------------------------------------------------------------------+
|<!-- Attribute --> |
|<!ELEMENT Attribute (#PCDATA)> |
|<!-- Condition --> |
|<!ELEMENT Condition (#PCDATA)> |
|<!-- Threshold --> |
|<!ELEMENT Threshold (#PCDATA)> |
|<!-- Command --> |
|<!ELEMENT Command (#PCDATA)> |
|<!-- Duration --> |
|<!ELEMENT Duration (#PCDATA)> |
|<!-- Guard operation --> |
|<!ELEMENT Guard (CmdID, NoResp?, Cred?, Meta?, Attribute, |
| Condition, Threshold )> |
|<!-- start time and date to schedule operation --> |
|<!ELEMENT Date (#PCDATA)> |
|<!-- repeat interval with periodic execution --> |
|<!ELEMENT Period (#PCDATA)> |
|<!-- repeat count with periodic execution --> |
|<!ELEMENT Repeat (#PCDATA)> |
|<!-- Schedule operation --> |
|<!ELEMENT Schedule (CmdID, NoResp?, Cred?, Meta?, Date?, Period?, |
| Repeat?, URI?, |
| (Get|Replace|Add|Delete|Exec))> |
|<!ELEMENT Assert (CmdID, Target?, NoResp?, Cred?, Meta?, Item+)> |
|<!ELEMENT Exception (CmdID, NoResp?, Cred?, Meta?, |
| (Get|Replace|Add|Delete|Exec))> |
adwankar et al Expires April 20, 2004 [Page 22]
Internet Draft SYMPLE Scripting Protocol October 20, 2003
|<!ELEMENT CatchAll (CmdID, NoResp?, Cred?, Meta?, |
| (Get|Replace|Add|Delete|Exec))> |
|<!-- Diagnostics operation --> |
|<!ELEMENT Diagnostics (CmdID, Assert+, Exception+, CatchAll?)> |
|<!-- Log operation --> |
|<!ELEMENT Log (CmdID, NoResp?, Cred?, Meta?, Attribute, |
| Command, Duration )> |
|<!-- Synclet --> |
|<!ELEMENT Synclet (CmdID, NoResp?, Meta?, (Schedule | Assert | |
| Postpone | Alert | Guard | Get | Replace | Add | Delete |
| Exception | Diagnostics | Exec | Seqeunce | Atomic )+)> |
|<!-- End of DTD Definition --> |
+------------------------------------------------------------------+
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]
