Network Working Group Jianping Zheng Internet-Draft Yichuan Wu Intended Status: Experimental China Mobile Communications Corporation Expires: June 24, 2017 Weimin Lei Wei Zhang Hao Li Northeastern University December 24, 2016 An Extension for SIP Instant Message Using Publish/Subscribe Mode draft-zhengjp-sipcore-sipim-ext-00 Abstract SIMPLE (SIP for Instant Messaging and Presence Leveraging Extensions) is a protocol suite for instant messaging (IM) service, but it is inefficient in processing instant message in session mode due to its complex signaling processes and heavy header overheads, which makes it difficult to meet the QoE (quality of experience) requirement, especially in the usage scenario of mobile Internet and other traffic sensitive networks. This document describes an alternative Session Initiation Protocol (SIP) extension for instant messaging service. The extension uses the publish-subscribe mode to simplify signaling procedures and introduces message user agent (MUA) to publish and receive message, and message broker (MB) as an intermediary to exchange messages between MUAs. Message is tagged with a topic, and the lightweight message format is more suitable for traffic sensitive networks. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. 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." Zhengjp, et al Expires June 24, 2017 [Page 1] Internet-Draft sipim-ext December 24, 2016 This Internet-Draft will expire on June 22, 2017. The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3 Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5 Entities Behavior Description . . . . . . . . . . . . . . . . . 9 5.1 MUA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.1.1 Connection Maintenance . . . . . . . . . . . . . . . . 9 5.1.2 Topic Subscription and Message Publication . . . . . . 9 5.1.3 Message ID Generation . . . . . . . . . . . . . . . . . 9 5.1.4 Session Termination . . . . . . . . . . . . . . . . . . 9 5.2 MB . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 5.2.1 Request Authentication . . . . . . . . . . . . . . . . 10 5.2.2 Connection Maintenance . . . . . . . . . . . . . . . . 10 5.2.3 Sending Responses . . . . . . . . . . . . . . . . . . . 10 5.2.4 Processing Offline Messages . . . . . . . . . . . . . . 10 5.2.5 Other Capacities . . . . . . . . . . . . . . . . . . . 10 6 Topic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 6.1 Setting Topic Rules . . . . . . . . . . . . . . . . . . . . 11 6.2 Organization of Topic . . . . . . . . . . . . . . . . . . . 11 6.3 Message Routing Based on Topic . . . . . . . . . . . . . . 12 7 Message Types . . . . . . . . . . . . . . . . . . . . . . . . . 12 Zhengjp, et al Expires June 24, 2017 [Page 2] Internet-Draft sipim-ext December 24, 2016 7.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 12 7.1.1 Fixed Header . . . . . . . . . . . . . . . . . . . . . 13 7.1.2 Variable Header . . . . . . . . . . . . . . . . . . . . 14 7.2 CONNECT . . . . . . . . . . . . . . . . . . . . . . . . . . 14 7.3 CONNACK . . . . . . . . . . . . . . . . . . . . . . . . . . 15 7.4 PUBLISH . . . . . . . . . . . . . . . . . . . . . . . . . . 16 7.5 PUBACK . . . . . . . . . . . . . . . . . . . . . . . . . . 18 7.6 SUBSCRIBE . . . . . . . . . . . . . . . . . . . . . . . . . 19 7.7 SUBACK . . . . . . . . . . . . . . . . . . . . . . . . . . 20 7.8 UNSUBSCRIBE . . . . . . . . . . . . . . . . . . . . . . . . 22 7.9 UNSUBACK . . . . . . . . . . . . . . . . . . . . . . . . . 23 7.10 PINGREQ . . . . . . . . . . . . . . . . . . . . . . . . . 24 7.11 PINGRSEP . . . . . . . . . . . . . . . . . . . . . . . . . 24 7.12 DISCONNECT . . . . . . . . . . . . . . . . . . . . . . . . 25 8 Compatibility Considerations . . . . . . . . . . . . . . . . . 25 9 Security Considerations . . . . . . . . . . . . . . . . . . . . 26 10 References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 10.1 Normative Reference . . . . . . . . . . . . . . . . . . . 26 10.2 Informative References . . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 Zhengjp, et al Expires June 24, 2017 [Page 3] Internet-Draft sipim-ext December 24, 2016 1 Introduction Instant message (IM) refers to a kind of real-time message transfer service. The major service characteristics of IM include various media type (text, audio, video, picture, emoji etc.) and high interactivity (group chat, online game etc.). Besides some proprietary protocols, IM service can be implemented by some open protocol suites, such as Extensible Messaging and Presence Protocol (XMPP) (RFC 3920, RFC 3921)[1][2], Common Profile for Instant Messaging (CPIM) (RFC 3860, RFC 3922)[3][4], SIP[7] for Instant Messaging and Presence Leveraging Extensions (SIMPLE)[8]. And SIMPLE is well-developed among these protocols and has been adopted by many vendors as the standard of instant messaging applications. SIMPLE is a SIP-based protocol suite, which has been applied in many applications, such as the presence and the instant messaging. However, with the development of the multimedia and related storage technology, the increasing user requirement and the changing of usage scenario, the existing SIMPLE framework limits the further application and development of IM service which is mainly embodied as follow. 1) Currently, store-and-forward mode turns to be the main application patterns of message service, however, SIMPLE framework still use Peer-to-Peer mode which is lagging behind the development of instant message. 2) SIMPLE uses SIP and MSRP (The Message Session Relay Protocol) as the core protocols, and provides three kinds of transmission modes to achieve instant message: page mode, large message mode and session mode. Page mode is suitable for transmitting short messages by the way of SIP MESSAGE, in which the cost of message header is more than message content in most case. Large message mode adopts SIP and MSRP to transmit long messages. It firstly creates a session between participants through SIP signaling and transmits data through MSRP. As for session mode, it requires to establish a SIP session and IM session, and keeps them for a period of time. Message transmitting by SIP and MSRP is based on a session, and the procedure of session establishing and terminating add extra overhead, and thus affects the overall efficiency of message transfer. MSRP is a text-based connection oriented protocol and the extra overhead of the message is big, which will also reduce execution efficiency to some extent. 3) The main usage scenario of instant message is mobile Internet. In mobile Internet, the IP address of the mobile device is time- varying as it moves. To provide the addressability of the endpoint, the mobile device must register to server constantly Zhengjp, et al Expires June 24, 2017 [Page 4] Internet-Draft sipim-ext December 24, 2016 when its address changes. For a SIP-based instant message application, the vibrating registration which caused by the changing IP address will cause a huge overhead of traffic and power. The mobile device is sensitive to the traffic and power consumption of terminal equipment in mobile Internet, and the vibrating registration will decrease the quality of experience of users. 4) Group chatting is an important feature of IM service, and the implementation of group chatting by SIMPLE uses the SIP Conference service for references. RFC7701[5] provides a group messaging frame based on SIP and MSRP, which requires all participants maintain a MSRP connection with MSRP Switch. However, maintaining connection with the Switch over a length of time would cause a great waste of network resources when there is no traffic transfer and the re-establishment of the connection will waste more when a short message needs to be transmitted. This method will cause a higher traffic and power consumption and thus reduce service experience of user. 5) The group chatting in SIMPLE works in the peer-to-peer (P2P) mode, and the routing problem of P2P have negative influence on the extensibility and the promotion of execution efficiency. The above issues have impeded the development of group chatting service. Although much of the functions can be realized through SIMPLE, there are many disadvantages like low data transfer rate, network resource waste and inefficient execution. Peer-to-peer mode limits the development of IM service. In addition, instant messaging applications based on SIMPLE or other related protocol suites are primarily enterprise-oriented, which don't apply to use on a large scale. To solve these problems, this document extends the current SIP, adding two kinds of logical entities named Message User Agent (MUA) and Message Broker (MB). MUA is an agent of user, which is responsible for publishing and receiving messages, creating, modifying and deleting a group. MB is in charge of message receiving, storing and forwarding, and in the meanwhile it manages the group. Each message is associated with a related topic and the transfer method is based on the publish/subscribe mode which decouples publisher and receiver dependencies and reduce the system develop difficulty. 2 Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119[6]. Zhengjp, et al Expires June 24, 2017 [Page 5] Internet-Draft sipim-ext December 24, 2016 3 Definitions To extend SIP, this document defines: 1)MUA (Message User Agent): has functions of SIP User Agent. It is responsible for producing, subscribing and publishing messages to relevant Topic. At the same time, it receives messages from MB, manages the users' configuration files and participates in creation, modification and deletion of a group. It's also used for authentication and register of user. 2) MB (Message Broker): deals the authentication, registration and Topic subscribing request of MUA and manages user configuration files. At the same time, it manages Topic, receives, stores and forwards the messages and manages the group chat as well. It is able to interact with other SIP entities to complete authentication and registration for users. 3) Topic: is structured as a layered organization. Topic name is the label of a kind of or a set of instant message. It is generated in MUA, and published to MB, and finally stored in MB. MUA updates the message contents of a Topic, and MB will match the subscribers of the Topic and push the message to those subscribers. And the group chatting topic is generated in MB and must be be globally unique. 4) Message Configuration Files: includes the users' basic information and messaging strategy and group information. When the users start registering, they will upload the configuration documents to MB and MB will complete the subscription of relevant Topic for the users according to it. 4 Overview SIMPLE framework implements the function of instant message based on SIP and MSRP, but there are existing shortcomings in complex system design, low execution efficiency and transmission efficiency and unsuitable for large-scale usage scenario and so on. To solve these problems, this document introduces two logical entities: MUA and MB, which are responsible for SIP message service. This scheme uses store-and-forward mode to transmit messages instead of the peer-to- peer mode. And each message is associated with a related topic and transmitted as the publish/subscribe mode. Publish/subscribe mode, also called Observer mode, is a kind of messages transport pattern which can be applied to store-and-forward mode effectively. The messages are defined as the form of topic. The users or MUAs generate topics according to some specific rules and Zhengjp, et al Expires June 24, 2017 [Page 6] Internet-Draft sipim-ext December 24, 2016 then publish to the MB. Users or MUAs can subscribe a topic from MB and become relevant subscribers. When the message publisher publishes the messages to topic, MB publishes the messages to all the relevant subscribers. And the advantages of this solution are: (1) Decoupling a. Decoupling publisher from receiver i. Space decoupling When sending messages, the publisher and receiver don't need to know the exist of each other, a relevant topic subscriptions relationships will help the MB publish the messages that the publisher published to MB to all relevant subscribers. ii. Time decoupling The publisher and receiver don't need to establish connection simultaneously to assure the immediacy and efficiency. iii. Synchronization decoupling The publisher doesn't need to establish the synchronization relationship with the receiver. It publishes the messages to MB and the receiver receives in an asynchronous way, i.e., MUA-to-MB, MB-to-MUA, by keeping a connection with MB. b. Decoupling the user from terminal device For multi-terminal user, the user just keeps the weak relation with the terminal device. The terminal device keeps the synchronization relationship with MB and subscribes topic independently. (2) Reducing the complexity of implementation All the messages including one-to-one messages, one-to-many messages and group messages can be defined as the form of topic and transmitted as the publish/subscribe mode. This method makes different kinds of messages have the approximate cost. Furthermore, it reduces the implementation complexity of group chatting messages. (3) Stateless processing In the store-and-forward mode based on publish/subscribe pattern, publishing the messages is asynchronous with receiving the messages, so MB doesn't need to keep the state- transition relationship for publishing and forwarding. Moreover, this mode gets rid of the dependence of transaction and reduces the cost. Zhengjp, et al Expires June 24, 2017 [Page 7] Internet-Draft sipim-ext December 24, 2016 (4) Expansibility Publish/subscribe mode achieves distributed architecture, parallel operations, message buffer and tree routing or mesh routing. Therefore, it could achieve a high expansibility, and suit for the large-scale usage scenario and improve the insufficiency caused by the tightly coupled and data-center service. (5) Environmental suitability Publish/subscribe mode is more suitable for current mobile Internet. The publisher and receiver are loosely coupled, which makes it free from P2P connection and reduces the network resource consumption. In addition, combining publishing with forwarding, it lowers the cost of transmitting the messages. Furthermore, MUA just needs to keep a connection with MB and don't need to request registration frequently because of IP address changes. (6) Service openness Current SIMPLE frame has the session negotiation through SIP/SDP, but the SDP is fit for audio and video session not suitable for message service. For the purpose of supporting the message service, SDP has to be extended, so it brings more difficulty to realize. As for topic mode, users can generate different Topics in terms of the requirement and the other can subscribe the topics that they are interested in. Therefore, this method enables the definition of service to be more flexible from the standard and it is good for new message service and service openness. To support mobile Internet scenario, the communication between MUA and MB breaks the limit that SIP is a test-based protocol. SIP is an open protocol, which can be extended according to the requirement of service. Mobile device is sensitive to traffic and we must pay more attention to the efficiency of messages. So this document defines a kind of lightweight and binary protocol for the communication between MUA and MB. This protocol refers to the design and message format of MQTT which will be described in more detail in the subsequent sections. The registration mechanism of SIP system is integrated. MUA and MB's authentication and registration adopt this mechanism to ease the work. MB needs to register to the Proxy or the application server (AS) in charge of message service for the purpose of legality. The registration mechanism of MUA is similar with SIP UA but not the same, the difference is that MUA is responsible for message service and needs to request authentication to Proxy or AS. Proxy or AS would assign a MB for MUA, both of which will be informed. What's more, this registration mechanism is beneficial to load balancing. Zhengjp, et al Expires June 24, 2017 [Page 8] Internet-Draft sipim-ext December 24, 2016 5 Entities Behavior Description 5.1 MUA The entity address, i.e., user ID, in network communication is unique. The User ID is distributed by MB, but the username can be defined by the user himself, such as Email address, SIP URL and telephone number. 5.1.1 Connection Maintenance A TCP connection needs to be established between MUA and MB. The heartbeat mechanism with PINGREQ and PINGRESP messages is employed to maintain the long-lived connection between client and MB. Communication among MUAs is based on Topic. This topic-based transport pattern gets a loose coupling between the publisher and receiver and achieves one-to-one message service and group message service easily. On the other hand, it's also helpful to make the user and terminal decoupled and support multi-terminal mode easily. 5.1.2 Topic Subscription and Message Publication By sending SUBSCRIBE message to MB, MUA subscribes the Topics which it is interested in. About publishing, MUA adopts PUBLISH message which includes the Topic information and message content. There are some differences in the receiving and sending different types of messages. For text message, MUA sends data to MB directly, and then MB sends it to MUA who has subscribed this Topic before. For multimedia message such as picture, document and so on, the transmission mode is a little complex. Referring to the offline file, The MUA of sender sends data to specialized multimedia data server and the server returns relevant URL link. Then MUA puts the URL link in the payload of PUBLISH message and send to MB. When MB receives, it sends the message to all relevant subscribers. Finally, the subscribers will parse the message to get the URL and downloads multimedia data from the multimedia data server. 5.1.3 Message ID Generation MUA needs to generate a new and unique message ID when constructing some messages, such as PUBLISH (in cases where QoS > 0), SUBSCRIBE, and UNSUBSCRIBE. The message ID is used to associate response messages with their corresponding request messages and thus ensure the transmission reliability. 5.1.4 Session Termination Zhengjp, et al Expires June 24, 2017 [Page 9] Internet-Draft sipim-ext December 24, 2016 When terminating session for some reason, the MUA will send DISCONNET message to MB and turn to offline state itself. 5.2 MB MB is responsible for complicated processing logic. It manages the forwarding of messages and the storage of users' offline messages and buddy list information. 5.2.1 Request Authentication When MUA sends CONNECT message to request connection, MB must authenticate the request by comparing the Token value in CONNECT message with the token in uniform authentication platform. If the comparison result is equal, MB will pre-subscribe the Topics of user's buddy list and relevant Topics of user's behavior. If failed, MB will reject to the CONNECT message. 5.2.2 Connection Maintenance MB maintains the connection with client and replies to the MUA's heartbeat request. When beyond the keep-alive time expires but no data packet from MUA is received, the MB will mark the MUA as unreachable. 5.2.3 Sending Responses When receiving a request message from MUA, MB will send a corresponding response message back according to different message types. And the response message has the same message ID with the corresponding request message. For example, when receiving a SUBSCRIBE message, MB will send a SUBACK message as a response. According to whether receiving SUBACK message or not, MUA will know whether subscribe successfully or not. 5.2.4 Processing Offline Messages For some reason, MUA has disconnected MB and its user state is offline. At that time, if someone sends messages to it, the MB will be responsible for receiving and storing these offline messages until it is online again. What's more, the MB will push these offline messages to MUA as soon as it is online. 5.2.5 Other Capacities MB has some other capacities: Semantic Parsing: MB is responsible for parsing the Topic semantic Zhengjp, et al Expires June 24, 2017 [Page 10] Internet-Draft sipim-ext December 24, 2016 and determining the Topic behavior according to the Topic information of MUA. For example, by parsing the user ID included in Topic, MB finds the receiver of messages and sends the messages to him. Message Routing: when MUA publishes messages, if the destination sets are not null, MB will forward the messages to the destination, i.e., the MB or the MUA who is interested in this Topic. Permission Checking: MB performs ACL permission checkout and filters the messages in relevant Topic of MUA. The filtering operation can be set by system as well as its user. For example, if a Topic is set "read", its user will only have the permission of receiving. On the contrast, if a Topic is set "write", its user will only have the permission of sending. (definition rules: username topic rw) State Presenting: all the states are presented by user presence. The function of presence is presenting the state of any terminal. State is related to the type of terminal. When a user's presence state changes, MB will inform all his friends. Broker to Broker: it is the connection between two MBs and is considered as the communicating extension between client and server. 6 Topic 6.1 Setting Topic Rules Topic can be considered as the identification of message data. As for receiving messages, the MUA of receiver needs to subscribe the Topic of interest to MB. To different message types, MB's processing logic is different. So this document defines that the first part of Topic is the service profile identifiers which is used to distinguish different message types. For example, the one-to-one messages' service profile identifier is defined as 110 while the group messages' is 200. The one-to-one messages' Topic is /100/UID while the group messages' is /200/GID. For one-to-one messages service, MUA subscribes the Topic it is interested in for itself, while for group messages service, all the users in the group subscribe the same Topic. 6.2 Organization of Topic The organization of Topic is related to the user behavior. Some Topics are defined according to the user behavior, such as the Topic of adding friends is user/friend/new, deleting friends corresponds to user/friend/delete, user's IM Topic is user/chat while the Topic of state presenting is presence/user. Typically, the users transmit instant messages with each other in user/chat. Zhengjp, et al Expires June 24, 2017 [Page 11] Internet-Draft sipim-ext December 24, 2016 Using adding friends as an example, when Alice wants Bob to become a friend of hers, she needs to send requesting to the Topic of Bob's adding friends, i.e., Bob@example.com/friend/new. Then Bob sends response to Alice's Topic, i.e., Alice@example.com/friend/new. If Bob agree with this requesting, Alice will send the information both of them to relevant Topic and at last they will communicate with each other in this Topic. 6.3 Message Routing Based on Topic MB achieves the functions of filtering and routing based on Topic. In Publish/subscribe message system, the publisher publishes the messages to MB and the subscriber subscribes the Topic which it is interested in through MB. And MB stores and forwards these messages. When a client subscribes a Topic, the MB at which the client located will notify all the other MBs that the Topic has been subscribed by it. When a client publishes a message, the MB located will route this message to the MB which subscribed the Topic and the latter message will be routed to the client. The message routing based on Topic supports the user-defined Topic, which requires the user to register the Topic. This way is beneficial to service opening and diversity. 7 Message Types 7.1 Overview Referring to MQTT protocol [9], this scheme defines 11 kinds of message types expressed in 4 bits. These 11 kinds of messages types are CONNECT, CONNACK, PUBLISH, PUBACK, SUBSCRIBE, SUBACK, UNSUBSCRIBE, UNSUBACK, PINGREQ, PINGRESP and DISCONNECT. They can be divided into 4 categories according to different functions: 1) Connection Class: CONNECT (value =1), and MUA sends it to MB to request connection. CONNACK (value =2), and MB sends it to MUA as the response of CONNECT. DISCONNECT (value =14), and MUA sends it MB to request disconnection. 2) Keep-alive Class: PINGREQ (value =12), and MUA sends it to MB to ask whether the connection still exist. PINGRESP (value =13), and MB sends it to MUA in response to PINGREQ. 3) Subscription Class: SUBSCRIBE (value =8), and MUA sends it to Zhengjp, et al Expires June 24, 2017 [Page 12] Internet-Draft sipim-ext December 24, 2016 MB to subscribe Topic. SUBACK (value =9), and MB sends it to MUA in response to subscribe. UNSUBSCRIBE (value =10), and MUA sends it to MB to cancel the SUBSCRIBE. UNSUBACK (value =11), and MB sends it to MUA in response to UNSUBSCRIBE. 4) Publishing Class: PUBLISH (value =3), and MUA and MB can send it to each other to publish messages in a Topic. PUBACK (value =4), and it is the response of PUBLISH. The message contains 3 components: Fixed header, Variable header and Payload as illustrated in Figure 7.1. +-------------------------------+ | Fixed header | +-------------------------------+ | Variable header | +-------------------------------+ | Payload | +-------------------------------+ Figure 7.1 - Message structure 7.1.1 Fixed Header Each message contains a fixed header. Figure 7.2 illustrates the fixed header format. +---------------------------------------+ |Bit | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | +---------------------------------------+ |byte 1 | Message Type | Flags | +---------------------------------------+ |byte 2 | Remaining Length | +---------------------------------------+ Figure 7.2 - Fixed header format Message Type: byte 1, bits 7-4. Represented as a 4-bit unsigned value, different value expresses different message type. For example, value 1 expresses the CONNECT message while value 2 expresses the CONNACK message. Flags: remaining bits 3-0 of byte 1, specific to each kind message. Remaining Length: starts at byte 2, bits 7-0, the number of bytes remaining within the current message, including data in the variable header and the payload. The fixed header can be extended to four bytes at most. Zhengjp, et al Expires June 24, 2017 [Page 13] Internet-Draft sipim-ext December 24, 2016 7.1.2 Variable Header Some types of messages contain a variable header component. It resides between the fixed header and the payload. The content of the variable header varies depending on the message type. The Message Identifier field of variable header is common in several message types as illustrated in Figure 7.3. +-----------------------------------+ |Bit | 7 | 6 | 5 | 4 | 3 | 2 | 1 | +-----------------------------------+ |byte 1 | Message Identifier MSB | +-----------------------------------+ |byte 2 | Message Identifier LSB | +-----------------------------------+ Figure 7.3 - Message Identifier bytes Message Identifier: two bytes, non-zero, unique identification of a message. This document refers to MQTT protocol to define the message types, however, not using the message header whose QoS is 2, this specification defines 11 kinds of message types, including CONNECT, CONNACK, PUBLISH, PUBACK, SUBSCRIBE, SUBACK, UNSUBSCRIBE, UNSUBACK, PINGREQ, PINGRES and DISCONNECT. 7.2 CONNECT CONNECT, requesting connection, the fixed header as illustrated in Figure 7.4. +----------------------------------------+ |Bit | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | +----------------------------------------+ |byte 1 |Message Type (1)| Reserved | +----------------------------------------+ | | 0 | 0 | 0 | 1 | 0 | 0 | 0 | 0 | +----------------------------------------+ |byte 2 | Remaining Length | +----------------------------------------+ Figure 7.4 - CONNECT message fixed header Message Type: 1, represent the CONNECT message; Flags: 0, reserved for future use; Zhengjp, et al Expires June 24, 2017 [Page 14] Internet-Draft sipim-ext December 24, 2016 Remaining Length: uncertain, depend on the data in the variable header and the payload. The variable header carries the protocol version information as illustrated in Figure 7.5. The protocol version is a UTF-8 encoded string that represents the protocol version "IM01". +------------------------------------------------------+ | | Description | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | +------------------------------------------------------+ |Protocol Version Information | +------------------------------------------------------+ |byte 1 |Length MSB (0)| 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | +------------------------------------------------------+ |byte 2 |Length LSB (4)| 0 | 0 | 0 | 0 | 0 | 1 | 0 | 0 | +------------------------------------------------------+ |byte 3 | 'I' | 0 | 1 | 0 | 0 | 1 | 0 | 0 | 1 | +------------------------------------------------------+ |byte 4 | 'M' | 0 | 1 | 0 | 0 | 1 | 1 | 0 | 1 | +------------------------------------------------------+ |byte 5 | '0' | 0 | 0 | 1 | 1 | 0 | 0 | 0 | 0 | +------------------------------------------------------+ |byte 6 | '1' | 0 | 0 | 1 | 1 | 0 | 0 | 0 | 1 | +------------------------------------------------------+ Figure 7.5 - CONNECT message variable header As for the payload, it mainly includes personal information of user, such as username and authentication Token and heart beats information. Username and authentication Token are the UTF-8 encoded strings. 7.3 CONNACK CONNACK is the MB's response of CONNECT, the fixed forehead as illustrated in Figure 7.6. Zhengjp, et al Expires June 24, 2017 [Page 15] Internet-Draft sipim-ext December 24, 2016 +--------------------------------------+ |Bit |7 |6 |5 |4 |3 |2 |1 |0 | +--------------------------------------+ |byte 1|Message Type(2)| Reserved | +--------------------------------------+ | |0 |0 |1 |0 |0 |0 |0 |0 | +--------------------------------------+ |byte 2|Remaining Length (2) | +--------------------------------------+ | |0 |0 |0 |0 |0 |0 |1 |0 | +--------------------------------------+ Figure 7.6 - CONNACK message fixed header Message Type: 2, represent the CONNACK message; Flags: 0, reserved for future use; Remaining Length: 2, represent that there are 2 bytes remaining within this message. The variable header mainly contains 2 components: CONNECT Acknowledge Flags and CONNECT Return code and its format is illustrated in Figure 7.7. +----------------------------------------------------------+ | | Description | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | +----------------------------------------------------------+ |CONNECT Acknowledge Flags | Reserved |SP1| +----------------------------------------------------------+ | byte 1 | | 0 | 0 | 0 | 0 | 0 | 0 | 0 | X | +----------------------------------------------------------+ |CONNECT Return code | +----------------------------------------------------------+ | byte 2 | | X | X | X | X | X | X | X | X | +----------------------------------------------------------+ Figure 7.7 - CONNACK message variable header CONNECT Acknowledge Flags: Bits 7-1 are reserved and MUST be set to 0. Bit 0 (SP1) is the Session Present Flag. CONNECT Return code: represent the responding situation. 0 represents that the connection is successful, 1 represents that the connection is failed because of the unacceptable protocol version and 2 represents that connection is failed because of rejected user ID. 7.4 PUBLISH Zhengjp, et al Expires June 24, 2017 [Page 16] Internet-Draft sipim-ext December 24, 2016 PUBLISH, sent from MUA to MB or from MB to MUA to transport an application message, the fixed header as illustrated in Figure 7.8. Typically, DUM = Duplicate delivery of a PUBLISH message; QoS = PUBLISH quality of service; RETAIN = PUBLISH retain flag. +------------------------------------------------------------+ | Bit | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | +------------------------------------------------------------+ | byte 1 | Message Type (3) |DUM flag| QoS level |RETAIN| +------------------------------------------------------------+ | | 0 | 0 | 1 | 1 | X | X | X | X | +------------------------------------------------------------+ | byte 2 | Remaining Length | +------------------------------------------------------------+ Figure 7.8 - PUBLISH message fixed header Message Type: 3, represent the PUBLISH message; DUM flag: 0 indicates that it isn't a retransmission message and 1 indicates it is. QoS level: indicate the level of assurance for delivery of an Application Message. RETAIN: 0 indicates that MB must not store the application message and must not remove or replace any existing retained message, while 1indicates that the MB must store it. Remaining Length: uncertain, depend on the data in the variable header and the payload. The variable header mainly contains 2 components: Topic Name and Message Identifier. Figure 7.9 shows a non normative example variable header, typically, the value of Topic Name set "a/b" and the value of Message Identifier set 10. Zhengjp, et al Expires June 24, 2017 [Page 17] Internet-Draft sipim-ext December 24, 2016 +----------------------------------------------------------------------+ | |Description | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | +----------------------------------------------------------------------+ | Topic Name | +----------------------------------------------------------------------+ | byte 1 |Length MSB (0) | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | +----------------------------------------------------------------------+ | byte 2 |Length LSB (3) | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 1 | +----------------------------------------------------------------------+ | byte 3 | 'a' (0x61) | 0 | 1 | 1 | 0 | 0 | 0 | 0 | 1 | +----------------------------------------------------------------------+ | byte 4 | '/' (0x2F) | 0 | 0 | 1 | 0 | 1 | 1 | 1 | 1 | +----------------------------------------------------------------------+ | byte 5 | 'b' (0x62) | 0 | 1 | 1 | 0 | 0 | 0 | 1 | 0 | +----------------------------------------------------------------------+ | Message Identifier | +----------------------------------------------------------------------+ | byte 6 |Message Identifier MSB (0) | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | +----------------------------------------------------------------------+ | byte 7 |Message Identifier LSB (10) | 0 | 0 | 0 | 0 | 1 | 0 | 1 | 0 | +----------------------------------------------------------------------+ Figure 7.9 - PUBLISH message variable header non normative example Topic Name: indicate which Topic is going to send data; Message Identifier: is only present in PUBLISH message where the QoS level is 1 or 2. Payload in PUBLISH carries the data which is described in Topic, i.e., the message content. 7.5 PUBACK If QoS is 1 in PUBLISH, PUBACK will as the response and expresses that the message is received successfully by Broker. The fixed forehead is illustrated in Figure 7.10. +---------------------------------------+ | Bit | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | +---------------------------------------+ | byte 1|Message Type(4)| Reserved | +---------------------------------------+ | | 0 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | +---------------------------------------+ | byte 2| Remaining Length (2) | +---------------------------------------+ | | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 0 | +---------------------------------------+ Figure 7.10 - PUBACK message fixed header Zhengjp, et al Expires June 24, 2017 [Page 18] Internet-Draft sipim-ext December 24, 2016 Except the Message Type, the description of message field is the same as CONNACK. The value of Message Type is 4. The variable header of PUBACK is a message descriptor as same as PUBLISH: +-----------------------------------------+ | Bit | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | +-----------------------------------------+ | byte 1 | Message Identifier MSB | +-----------------------------------------+ | byte 2 | Message Identifier LSB | +-----------------------------------------+ Figure 7.11 - PUBACK message variable header 7.6 SUBSCRIBE SUBSCRIBE expresses the subscription of Topic and the specification allows to define more than one Topic in a SUBSCRIBE. The fixed forehead is illustrated in Figure 7.12. +---------------------------------------+ | Bit | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | +---------------------------------------+ | byte 1|Message Type(8)| Reserved | +---------------------------------------+ | | 1 | 0 | 0 | 0 | 0 | 0 | 1 | 0 | +---------------------------------------+ | byte 2| Remaining Length | +---------------------------------------+ Figure 7.12 - SUBSCRIBE message fixed header Message Type: 8, represent the SUBSCRIBE message; Flags: 2, reserved for future use. Attention, it must be set to 2 respectively. The MB must treat any other value as malformed and close the network connection; Remaining Length: uncertain, depend on the data in the variable header and the payload. The variable header contains a Message Identifier. Figure 7.13 shows a variable header with Packet Identifier set to 10. Zhengjp, et al Expires June 24, 2017 [Page 19] Internet-Draft sipim-ext December 24, 2016 +------------------------------------------------------------------+ | | Description | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | +------------------------------------------------------------------+ |Message Identifier | +------------------------------------------------------------------+ |byte 1|Message Identifier MSB (0) | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | +------------------------------------------------------------------+ |byte 2|Message Identifier LSB (10)| 0 | 0 | 0 | 0 | 1 | 0 | 1 | 0 | +------------------------------------------------------------------+ Figure 7.13 - SUBSCRIBE message variable header The payload of a SUBSCRIBE message contains a list of Topic Filters indicating the Topics to which the Client wants to subscribe. The Topic Filters in a SUBSCRIBE message payload MUST be UTF-8 encoded strings. The payload is illustrated in Figure 7.14. +-------------------------------------------+ |Description| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | +-------------------------------------------+ |Topic Filter | +-------------------------------------------+ |byte 1 |Length MSB | +-------------------------------------------+ |byte 2 |Length LSB | +-------------------------------------------+ |bytes 3..N |Topic Filter | +-------------------------------------------+ |Requested QoS | +-------------------------------------------+ | | Reserved | QoS | +-------------------------------------------+ |byte N+1 | 0 | 0 | 0 | 0 | 0 | 0 | X | X | +-------------------------------------------+ Figure 7.14 - SUBSCRIBE message payload Typically, the upper 6 bits of the Requested QoS byte are not used in the current version of the protocol. They are reserved for future use. The MB must treat a SUBSCRIBE packet as malformed and close the network connection if any of Reserved bits in the payload are non- zero, or QoS is not 0, 1 or 2. 7.7 SUBACK SUBACK is MB's response of SUBSCRIBE. The fixed forehead is illustrated in Figure 7.15. Zhengjp, et al Expires June 24, 2017 [Page 20] Internet-Draft sipim-ext December 24, 2016 +-------------------------------------------------------+ | Bit | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | +-------------------------------------------------------+ | byte 1| MQTT Message Type (9) | Reserved | +-------------------------------------------------------+ | | 1 | 0 | 0 | 1 | 0 | 0 | 0 | 0 | +-------------------------------------------------------+ | byte 2| Remaining Length | +-------------------------------------------------------+ Figure 7.15 - SUBSCRIBE message fixed header Except the Message Type, the description of message field is the same as PUBLISH. The value of Message Type is 9. The variable header contains the Message Identifier from the SUBSCRIBE Packet that is being acknowledged. Figure 7.16 below illustrates the format of the variable header. +-------------------------------------------------------+ | Bit | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | +-------------------------------------------------------+ | byte 1| Message Identifier MSB | +-------------------------------------------------------+ | byte 2| Message Identifier LSB | +-------------------------------------------------------+ Figure 7.16 - SUBSCRIBE message variable header The payload contains a list of return codes. Each return code corresponds to a Topic Filter in the SUBSCRIBE message being acknowledged. The order of return codes in the SUBACK message must match the order of Topic Filters in the SUBSCRIBE message. Figure 7.17 below illustrates the format of the variable header. +-------------------------------------------------------+ | Bit | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | +-------------------------------------------------------+ | | Return Code | +-------------------------------------------------------+ | byte 1| X | 0 | 0 | 0 | 0 | 0 | X | X | +-------------------------------------------------------+ Figure 7.17 - SUBSCRIBE message payload Allowed return codes: Zhengjp, et al Expires June 24, 2017 [Page 21] Internet-Draft sipim-ext December 24, 2016 0x00 - Success - Maximum QoS 0 ; 0x01 - Success - Maximum QoS 1 ; 0x02 - Success - Maximum QoS 2 ; 0x80 - Failure . 7.8 UNSUBSCRIBE UNSUBSCRIBE expresses canceling the subscription of a Topic and the specification allows canceling subscription of different Topics at a time. The fixed forehead is illustrated in Figure 7.18. +-------------------------------------------------------+ | Bit | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | +-------------------------------------------------------+ | byte 1| Message Type (10) | Reserved | +-------------------------------------------------------+ | | 1 | 0 | 1 | 0 | 0 | 0 | 1 | 0 | +-------------------------------------------------------+ | byte 2| Remaining Length | +-------------------------------------------------------+ Figure 7.18 - UNSUBSCRIBE message fixed header Except the Message Type, the description of message field is the same as he UNSUBSRIBE. The value of Message Type is 10. The variable header is the message descriptor, as illustrated in Figure 7.19. +-------------------------------------------------------+ | Bit | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | +-------------------------------------------------------+ | byte 1| Message Identifier MSB | +-------------------------------------------------------+ | byte 2| Message Identifier LSB | +-------------------------------------------------------+ Figure 7.19 - UNSUBSCRIBE message variable header The payload for the UNSUBSCRIBE message contains the list of Topic Filters that the Client wishes to unsubscribe from. The Topic Filters in an UNSUBSCRIBE message must be UTF-8 encoded strings. Figure 7.20 shows a non normative example payload, typically, it set two Topic Filters, the one is "a/b" and the other one is "c/d". Zhengjp, et al Expires June 24, 2017 [Page 22] Internet-Draft sipim-ext December 24, 2016 +-----------------------------------------------------------+ | | Description | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | +-----------------------------------------------------------+ |Topic Filter | +-----------------------------------------------------------+ | byte 1 |Length MSB (0)| 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | +-----------------------------------------------------------+ | byte 2 |Length LSB (3)| 0 | 0 | 0 | 0 | 0 | 0 | 1 | 1 | +-----------------------------------------------------------+ | byte 3 | 'a' (0x61) | 0 | 1 | 1 | 0 | 0 | 0 | 0 | 1 | +-----------------------------------------------------------+ | byte 4 | '/' (0x2F) | 0 | 0 | 1 | 0 | 1 | 1 | 1 | 1 | +-----------------------------------------------------------+ | byte 5 | 'b' (0x62) | 0 | 1 | 1 | 0 | 0 | 0 | 1 | 0 | +-----------------------------------------------------------+ |Topic Filter | +-----------------------------------------------------------+ | byte 6 |Length MSB (0)| 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | +-----------------------------------------------------------+ | byte 7 |Length LSB (3)| 0 | 0 | 0 | 0 | 0 | 0 | 1 | 1 | +-----------------------------------------------------------+ | byte 8 | 'c' (0x63) | 0 | 1 | 1 | 0 | 0 | 0 | 1 | 1 | +-----------------------------------------------------------+ | byte 9 | '/' (0x2F) | 0 | 0 | 1 | 0 | 1 | 1 | 1 | 1 | +-----------------------------------------------------------+ | byte 10 | 'd' (0x64) | 0 | 1 | 1 | 0 | 0 | 1 | 0 | 0 | +-----------------------------------------------------------+ Figure 7.20 - UNSUBSCRIBE message payload non normative example 7.9 UNSUBACK UNSUBACK is MB's response of UNSUBSCRIBE. The fixed forehead is illustrated in Figure 7.21. +-------------------------------------------------------+ | Bit | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | +-------------------------------------------------------+ | byte 1| Message Type (11) | Reserved | +-------------------------------------------------------+ | | 1 | 0 | 1 | 1 | 0 | 0 | 0 | 0 | +-------------------------------------------------------+ | byte 2| Remaining Length (2) | +-------------------------------------------------------+ | | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 0 | +-------------------------------------------------------+ Figure 7.21 - UNSUBSACK message fixed header Zhengjp, et al Expires June 24, 2017 [Page 23] Internet-Draft sipim-ext December 24, 2016 Except the Message Type, the description of message field is the same as CONNACK. The value of Message Type is 11. The variable header is the message descriptor, as illustrated in Figure. +-------------------------------------------------------+ | Bit | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | +-------------------------------------------------------+ | byte 1| Message Identifier MSB | +-------------------------------------------------------+ | byte 2| Message Identifier LSB | +-------------------------------------------------------+ Figure 7.22 - UNSUBACK message variable header. 7.10 PINGREQ Heartbeat packet, which the client sent to MB, only has fixed forehead. The fixed forehead is illustrated in Figure 7.23. +-------------------------------------------------------+ | Bit | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | +-------------------------------------------------------+ | byte 1| Message Type (12) | Reserved | +-------------------------------------------------------+ | | 1 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | +-------------------------------------------------------+ | byte 2| Remaining Length (0) | +-------------------------------------------------------+ | | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | +-------------------------------------------------------+ Figure 7.23 - PINGREQ message fixed header Message Type: 12, represent the PINGREQ message; Flags: 0, reserved for future use; Remaining Length: 0, no variable header or the payload. 7.11 PINGRSEP The response of PINGREQ message, only has fixed forehead which is illustrated in Figure 7.24. Zhengjp, et al Expires June 24, 2017 [Page 24] Internet-Draft sipim-ext December 24, 2016 +-------------------------------------------------------+ | Bit | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | +-------------------------------------------------------+ | byte 1| Message Type (13) | Reserved | +-------------------------------------------------------+ | | 1 | 1 | 0 | 1 | 0 | 0 | 0 | 0 | +-------------------------------------------------------+ | byte 2| Remaining Length (0) | +-------------------------------------------------------+ | | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | +-------------------------------------------------------+ Figure 7.24 - PINGRSEP message fixed header Except the Message Type, the description of message field is the same as PINGREQ. The value of Message Type is 13. 7.12 DISCONNECT The DISCONNECT message indicates that the MUA is disconnecting cleanly. It has fixed forehead only as illustrated in Figure 7.25 with no variable header or payload. +-------------------------------------------------------+ | Bit | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | +-------------------------------------------------------+ | byte 1| Message Type (14) | Reserved | +-------------------------------------------------------+ | | 1 | 1 | 1 | 0 | 0 | 0 | 0 | 0 | +-------------------------------------------------------+ | byte 2| Remaining Length (0) | +-------------------------------------------------------+ | | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | +-------------------------------------------------------+ Figure 7.25 - DISCONNECT message fixed header Except the Message Type, the description of message field is the same as PINGREQ. The value of Message Type is 14. 8 Compatibility Considerations The proposed scheme follows the extension logic of SIP protocol. Newly defined entity MUA provides backwards compatibility with SIP UA and has the same functions as SIP UA. The definition of MUA and MB meets the extension demand of SIP entity, furthermore, MUA and MB can interact with SIP logical entity normally. For example, when MUA Zhengjp, et al Expires June 24, 2017 [Page 25] Internet-Draft sipim-ext December 24, 2016 requests authentication and registration, it sends registration message to application server firstly, and then application server would assign the most suitable MB for MUA and notify MUA if the message is matched. The message used in this process is in accordance with the method in SIP, which maintains compatibility about messages. 9 Security Considerations Although the message publisher and receiver are loosely-coupled while transmitting messages, the security can be ensured. Firstly, before subscribing or publishing, MUAs need to authenticate and register user authentication information with AS. In the process, the username and password must be encrypted to prevent interception of assertions. Secondly, the username and password stored in AS are also encrypted to prevent identity leakage. Thirdly, MB only sends messages of a Topic to the MUA which has been authenticated and subscribed the related Topic. The authentication and topic management belongs to different entities, and it could avoid network attacks and was under firm security. When the IP address changes, current transmitting will stop and MUAs need to send a CONNECT message to MB to create a new connection. The message content should be encrypted by the encryption algorithm to ensure integrality and reliability of the message. 10 References 10.1 Normative Reference [1] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 6120, March 2011. [2] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence", RFC 6121, March 2011. [3] Peterson, J., "Common Profile for Instant Messaging (CPIM)", RFC3860, August 2004. [4] Saint-Andre, P., "Mapping Extensible Messaging and Presence Protocol (XMPP) to Common Presence and Instant Messaging (CPIM)", RFC 3922, October 2004. [5] Niemi, A., Garcia-Martion, M., and G. Sandbakken, "Multi-party Chat Using the Message Session Relay Protocol (MSRP)", RFC7701, December 2015. [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 10.2 Informative References Zhengjp, et al Expires June 24, 2017 [Page 26] Internet-Draft sipim-ext December 24, 2016 [7] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [8] Rosenberg, J., "SIMPLE Made Simple: An Overview of the IETF Specifications for Instant Messaging and Presence Using the Session Initiation Protocol (SIP)", RFC6914, April 2013. [9] International Business Machines Corporation (IBM), "MQTT V3.1 Protocol Specification", http://public.dhe.ibm.com/software/dw/webservices/ws-mqtt/mqtt- v3rl.html, August 2010. Authors' Addresses Jianping Zheng China Mobile Communications Corporation China Mobile Research Institute Beijing, 100031 P. R. China Email: zhengjianping@chinamobile.com Yichuan Wu China Mobile Communications Corporation China Mobile Research Institute Beijing, 100031 P. R. China Email: wuyichuan@chinamobile.com Weimin Lei Northeastern University School of Computer Science and Engineering Shenyang, China, 110819 P. R. China Email: leiweimin@mail.neu.edu.cn Wei Zhang Northeastern University School of Computer Science and Engineering Shenyang, China, 110819 P. R. China Zhengjp, et al Expires June 24, 2017 [Page 27] Internet-Draft sipim-ext December 24, 2016 Email: zhangwei1@mail.neu.edu.cn Hao Li Northeastern University School of Computer Science and Engineering Shenyang, China, 110819 P. R. China Email: haoli2015@stumail.neu.edu.cn Zhengjp, et al Expires June 24, 2017 [Page 28]