Device Management

发表于 2008-8-14 11:00

SyncML device management Article Outline [url href=http://www.aepona.com/learn_about/whitepapers3.html#why]Why device management?[/url] [url href=http://www.aepona.com/learn_about/whitepapers3.html#why2]Why SyncML?[/url] [url href=http://www.aepona.com/learn_about/whitepapers3.html#sync]SyncML Device Management Protocol[/url] [url href=http://www.aepona.com/learn_about/whitepapers3.html#imp]Implementing SyncML[/url] [url href=http://www.aepona.com/learn_about/whitepapers3.html#notes]Final notes[/url] [url href=http://www.aepona.com/learn_about/whitepapers3.html#about]About the author[/url] With pervasive devices overwhelming today's market, developers need a standard protocol to set up and reconfigure devices, update software, and register new services remotely. The SyncML Device Management Protocol helps you do just that without having to commit to a proprietary protocol Why device management? "... a billion people interacting with a million e-businesses with a trillion intelligent devices interconnected..." --Lou Gerstner, Chairman IBM Ubiquitous access to information is vital in today's fast-moving computing world. If it isn't already, the market will soon be flooded with different types of pervasive devices. These include Personal Digital Assistants (PDAs) with network access, as well as a new class of not-so-personal, but more consumer-oriented devices, such as in-vehicle information systems, home service gateways, kiosks, and set-top boxes. And as those devices become more popular and more complicated, the task of setting up and reconfiguring devices, updating software, and registering new services automatically becomes more challenging. Therefore, we need a standard protocol that will allow service providers, device manufacturers, and corporate information management departments to perform the following tasks remotely:<UL><li>Configure new devices <li>Upgrade software on devices <li>Upload new applications <li>Perform backup and restoration <li>Track hardware inventory <li>Collect data from the devices <li>Control devices remotely <li>Implement service discovery and provisioning </li></UL> This article gives you an under-the-hood look into the SyncML (Synchronization Markup Language) Device Management Protocol -- an emerging and efficient solution that has gained wide support among major industry players. [url href=http://www.aepona.com/learn_about/whitepapers3.html#top]Back to top[/url] Why SyncML? Currently, there are several proprietary protocols you can use to manage devices, but there is no current standard device management protocol. If you consider the non-interoperability issues that come with multiple proprietary protocols, this is a disconcerting fact. Unless the industry proposes a standard device management protocol, a plethora of incompatible protocols will consume it, whereas a standard device management protocol would cater to all industry segments. The SyncML Initiative, led by more than 640 companies, including Ericsson, IBM, Nokia, and Motorola, has designed a highly-interoperable device management (DM) protocol. The initiative successfully created an industry standard data synchronization protocol. Now industry leaders in both the client and server segment are in the process of designing and promoting the SyncML Device Management Protocol, in hopes of making it the future standard. The SyncML Initiative is now a part of the Open Mobile Alliance (OMA), which consists of groups like WAP Forum, Location Interoperability Forum, and MMS Interoperability Group. By being a part of this widespread industry organization, SyncML's acceptance as a standard device management solution will likely increase significantly. [url href=http://www.aepona.com/learn_about/whitepapers3.html#top]Back to top[/url] SyncML Device Management Protocol The history The initiative's team of designers began developing SyncML DM in 2001, while later holding its first public real-time demonstration in Amsterdam in January 2002. At that time, the team instantly implemented changes to preferences and settings of five different handsets via live connections to five different servers. The team released SyncML DM 1.1 in February 2002 and held the first engineering event of SyncML DM in Las Vegas the following September. SyncML Device Management 1.1.1 is the current version. SyncML design SyncML DM is a client-server protocol where the server manages the software on the client device. The protocol's designers created it with the following in mind:<UL><li>Mobile devices, which have limited resources such as processing power and memory <li>Wireless networks, which have low bandwidth and high network latency </li></UL> The protocol is generic and designed to reuse the SyncML DataSync document type definition (DTD). Figure 1 shows a typical scenario of a SyncML server managing any networked device implementing SyncML. Figure 1. Seamless management of devices through SyncML <img src="file:///E:/Study/work%20doc/Arm%20study/Device%20Management.files/1_fig1.gif"> SyncML consists of the following parts:<UL><li>Data model: The data offered for remote manipulation (for example, browser and mail settings). <li>Protocols: The protocols used between a management server and a mobile device. <li>Policy: The policy that decides who can manipulate a particular parameter or update a particular object in the device. <li>Security: The authentication mechanism between the client and the server, the integrity of message exchanges, and the confidentiality of the message exchanged. <li>Bootstrap: How the management server provisions a new client to enable it to start a management session. <li>Notification: The way the server notifies the client to start a management session. </li></UL> Data model There are two elements in the SyncML's data model: a device management tree, which contains objects for manipulation, and the Device Description Framework, which consists of meta-information about the tree. Device management tree: To be managed, a device must expose its internal data to the management server. The management tree organizes all the management objects in the device as a hierarchical tree structure, where a URI can uniquely address the management object. SyncML DM standardizes three things:<UL><li>The rules for adding, deleting, modifying, and retrieving the node's contents <li>The way in which you specify access control rights for adding, modifying, deleting, and accessing the nodes <li>The different type of nodes in the tree and their properties </li></UL> Device Description Framework: If the server manages the device, then it needs to know the device's tree structure. That tree structure cannot be standardized because of the countless devices with different functionality in the market. Hence, you must enable the management server to know the tree structure and its properties. To do so, the client vendor describes the internal tree structure when it releases the device to market. The SyncML DM Device Description Framework describes a common tree format, so the management server can easily understand the devices. Protocols As with any protocol, SyncML specifies the syntax and semantics of messages exchanged between a client and a server. The Representation Protocol specification describes the syntax; the Device Management Protocol specifies the semantics. Representation Protocol: SyncML's Representation Protocol defines the syntax of the exchanged message. SyncML DM operations are bound into a SyncML package, which is a conceptual frame for one or more SyncML DM messages. Those messages are well-formed XML documents identified by the SyncML root or document element type. Each message consists of a header (SyncHdr) and a message body (SyncBody). The header specifies routing, versioning, and session information, while the message body acts as a container for one or more SyncML DM commands. The commands are containers for other element types that describe the command's specifics. The server sends commands like Add, Copy, Delete, and Replace to manipulate the management tree, and uses the Get command to retrieve the contents of a particular node. The client returns the contents through a Result command. And a Status command conveys another command's execution results. The Representation Protocol defines two DTDs:<UL><li>SyncML DTD, which specifies the basic SyncML message format. SyncML specifies various commands; the elements of these commands are specified in this DTD. <li>Meta-Information DTD, which contains the data formats. Different SyncML commands carry data in different formats. Information about this data sits in a meta-element formatted according to this DTD. </li></UL> Figure 2 illustrates a conceptual SyncML message. Figure 2. Conceptual SyncML message <img src="file:///E:/Study/work%20doc/Arm%20study/Device%20Management.files/1_fig2.gif"> Device Management Protocol: SyncML Device Management Protocol specifies the handshake mechanism and the rules to follow for a successful management session, including the:<UL><li>State machine for the client and server <li>Commands that the server and the client can send <li>Method by which the client and server authenticate each other <li>Process for checking the integrity of the message exchanged <li>Mechanisms for sending objects greater than the transport message size </li></UL> Figure 3 describes the two phases of a management session: the setup phase and the management phase. Figure 3. Message sequence diagram <img src="file:///E:/Study/work%20doc/Arm%20study/Device%20Management.files/1_fig3.gif"> Setup phase: Package 0, from the server, is an optional package wherein the server uses an out-of-band signaling mechanism to notify the client to connect and establish a management session. Package 1, from the client, contains the session information, the credentials, an alert specifying if the client connected voluntarily or if the server asked it to connect, and the device information. Package 2, from the server, contains status codes for the commands the client sent in with package 1. It contains credential information if required by the client and management commands. If the server does not send any management commands in this package, the session ends. If the credential information is incorrect or not specified, the setup phase may go through several iterations. Management phase: Package 3, from the client, contains responses to the management commands the server sent in package 2. The response includes status of a management operation and results if the server requested any information. If the server did not send any commands in package 2 and did not request the client to send the next message, then the client does not send this package and the session ends. Package 4 from the server contains management commands. The management phase might go through several iterations, during which the server sends the commands and the client responds to them. Policy To manage different objects, a device could connect to different servers. For example, it could connect to a service provider's management server in order to manage the service operator's settings, or it could connect to a device manufacturer's management server to manage some applications. Therefore, you need a policy that allows you to have specific servers for specific operations on the tree nodes. Access Control Lists (ACL) specify this policy in SyncML DM. SyncML DM specifies the ACL syntax, its setting rules, inheritance properties, and more. Security Security plays an important role in device management because of the sensitive information transferred from the server to the client. A malicious management server can take complete control of the client if you don't ensure its security. SyncML DM has the following provisions to implement a secure solution:<UL><li>Authentication: Validates either the device or management server identity. You achieve authentication through a mechanism where both the client and the server can challenge each other for the credential information, such as a user ID and password. You can send credentials using B64 encoding of a user ID and password, or a more secure Message Digest Algorithm (MD5), which includes a nonce. The challenger specifies the scheme that will be used while the SyncML message header carries the credential information. <li>Integrity: A message ascertains its content or, at a minimum, can detect whether its content has been modified or corrupted. You'll need integrity when the client uses an insecure transport. By computing a keyed Hashing for Message Authentication (HMAC) of the entire message with a shared secret and sending them in the transport header, you'll achieve integrity of the message exchanged between the client and server. The message recipient then recomputes the HMAC based on the received message and the shared secret. If the hash matches, it implies that the message has not been tampered with; otherwise, the message is discarded. <li> Confidentiality: Keeps contents secret from all but the two entities exchanging the message. It does not limit the message's visibility (open to eavesdropping), but it does prevent a third entity from interpreting the transmitted data. Effectively, this prevents anyone but the intended sender and intended recipient from understanding the message's contents. There are two types of confidentiality in SyncML DM:<li> Confidentiality of information being transferred over a transport protocol. SyncML DM does not specify how to maintain this type of confidentiality. However, you can achieve it in one of two ways: using a transport protocol that supports encryption like Transport Layer Security (TLS) or HTTPS or encrypting the management objects, which the client or server can decrypt.<li> Confidentiality of information between device management servers. You can use ACLs to control a server's rights to access, update, or delete information in the client's management tree.</li></UL>

[ARM程序分析与设计] Device Management

相关帖子

浏览过的版块