Presentation on theme: "21-04-0305-00-0000 IEEE 802.21 MEDIA INDEPENDENT HANDOVER DCN: 21-05-0305-00-0000 Title: XML framework for component communication Date Submitted: July."— Presentation transcript:
21-04-0305-00-0000 IEEE 802.21 MEDIA INDEPENDENT HANDOVER DCN: 21-05-0305-00-0000 Title: XML framework for component communication Date Submitted: July 19, 2005 Presented at IEEE 802.21 session #9 in San Francisco Authors or Source(s): Ania Halliop, Michael Montemurro Abstract: Chantry Networks's message based middleware is XML-based framework created to provide a publish/subscribe message bus used for local and remote inter-process communication
21-04-0305-00-0000 IEEE 802.21 presentation release statements This document has been prepared to assist the IEEE 802.21 Working Group. It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein. The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution, and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEEs name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEEs sole discretion to permit others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and accepts that this contribution may be made public by IEEE 802.21. The contributor is familiar with IEEE patent policy, as outlined in Section 6.3 of the IEEE-SA Standards Board Operations Manual and in Understanding Patent Issues During IEEE Standards Development http://standards.ieee.org/board/pat/guide.html> Section 6.3 of the IEEE-SA Standards Board Operations Manualhttp://standards.ieee.org/guides/opman/sect6.html#6.3 http://standards.ieee.org/board/pat/guide.html
21-04-0305-00-0000 Table of Contents 1.An XML-based communication engine 2.What is XML? 3.Why use XML? 4.Disadvantages of XML 5.Flexible software development 6.Example XML message 7.Services & transport mechanism 8.Communication topology 9.Registration process 10.Security 11.Error Handling 12.Communication Engine message flow 13.Message Flow Example 1 14.Message Flow Example 2 15.Application to IEEE 802.21 16.Appendix & References
21-04-0305-00-0000 An XML-based communication engine Chantrys publish/subscribe mechanism consists of: a message processing engine a set of messages that forms a protocol a transport layer (in our case, we use sockets over TCP/IP) The communication framework is based on XML. Chantry uses only a small subset of XML capabilities It provides an flexible framework for defining or modifying new messages It provides a simple mechanism for implementing protocol changes
21-04-0305-00-0000 What is XML? XML (Extensible Markup Language) is a specification developed by the W3C XML is a simpler version of SGML, originally designed for Web documents but now extended for use in a variety of applications XML allows developers to create their own customized tags, enabling the definition, transmission, validation, and interpretation of data between applications XML allows users to define their own markup languages (in this case, for communication protocols) XML libraries are widely available and portable for many systems
21-04-0305-00-0000 Why use XML? Advantages: extensibility easy to revise (can add new fields, messages anytime) easy to troubleshoot (not binary), easy to test and write test apps transport agnostic supported by many languages well-known standard supported on many systems free to use!
21-04-0305-00-0000 Disadvantages of XML Flexibility has a cost: text-based – not efficient encoding required to create message parsing required to extract data need to well define markups to use (need to agree on tags)
21-04-0305-00-0000 Flexible software development XML provides flexibility in the software: can define new tags, attributes, and attribute values: new fields can be added easily without needing to rewrite the message communication protocol client can read properties in any order client only needs to read properties it is interested in new messages can be added anytime developer can create optional or required tags XML can easily represent hierarchical data structures (for example, arrays or arrays within array) can use DTD (Document Type Definitions) to define markups to use and verify sent/received data is valid can use DOM (Document Object Model) to convert XML document to collection of objects, accessible in any order for manipulation
21-04-0305-00-0000 Example XML message An example XML message: 40 0 880 Entrance
21-04-0305-00-0000 Services & transport mechanism Services: Publish and Subscribe can be used as an event interface, API, or protocol provides a mechanism to distribute messages to multiple clients Transport Mechanism: L2, L3, or L4 mechanisms take advantage of existing standards Chantry's messaging system uses TCP stream sockets
21-04-0305-00-0000 Communication topology Hub & Spoke topology: central communication component to which multiple components can connect supports local and remote connections (on and off box) sender does not need to know all interested receivers can send messages privately or multicast/broadcast client can connect multiple times to framework framework can accommodate multiple Hubs that are interconnected
21-04-0305-00-0000 Registration process using provided APIs, clients securely connect to XML communication engine, set options, and subscribe for messages options include specifying whether client wants to have received messages queued or processed right away communication engine can generate messages as well (i.e., inform subscribed clients that another client has registered) clients only need to register for the messages for which they are interested clients can have multiple connections to communication engine and subscribe for different messages on each connection (useful in multi-threaded applications)
21-04-0305-00-0000 Security communication engine can use a variety of authentication options such as certificates, or shared secrets encryption keys can be derived based on authentication material support for security can be built into the APIs used by clients depending on transport layer, can make use of standards such as IPSec, SSL, etc. can accept only local connections (127.0.0.1) and have communication engine act as proxy for connections to remote communicate engines. Then, only need to add security to remote connection.
21-04-0305-00-0000 Error handling can build-in error handling into APIs or take advantage of existing error handling, such as in the case of TCP sockets clients can close and re-open connection to XML communication framework anytime, and vice-versa, if concern regarding state of connection higher layer protocol enhancement could accommodate more robust error handling
21-04-0305-00-0000 Communication Engine message flow The following message flow examples depicts components connecting to the communication engine and sending and receiving messages, using a series of TCP-based APIs. At the beginning of start-up or after a breakdown in communication, a component: connects (comm_connect) to the communication engine and receives a socket and subscribes (comm_subscribe) for specific messages The component can then: send (comm_send) and receive (comm_recv) messages To disconnect from the communication engine, the component uses the comm_close API to clean up its session and close its socket.
21-04-0305-00-0000 Application to 802.21 XML-based publish/subscribe mechanisms could be used for: MIH Event Service MIH Information Service MIH Event Service Distribution of link events to all subscribed components MIH Information Service Query/Distribution information on handover candidates.
21-04-0305-00-0000 802.21 Topology and Communications There are two topology options which are independent of the messaging: A centralized mobility server that all participating MIH MACs connect Each participating MAC acts as a publish/subscribe service The protocol could run on top of: L2 with an appropriate SAP definition L3? Dont know why you would do this. L4 likely on top of either TCP/IP or UDP/IP During the connection process, each MAC subscribes to the events that it needs
21-04-0305-00-0000 Discovery and Registration MIH MAC discovery procedure would be out of scope of 802.21, however: Could be provisioned on Access Points Could use Service Location Protocol (SLP) Could use a multicast mechanism. Secure authentication procedure based on certificates, or shared keys Connected MIH MACs would subscribe to messages MIH MAC would send messages to the appropriate HUB to send a message or indicate a state change.
21-04-0305-00-0000 Message Definitions MIH Event Service Definitions: Treat as publish/subscribe service Could use MIH Event Service Definitions to build the neighbour graph. MIH Information Service: Create request/response messages Use XML schema as defined.