Patent Application
20100260174
The present application relates to message routing in a message relay system and, more particularly, to implicit registration and session establishment between client devices that do not support session-based communications.
Message relay systems are known in the art for transferring messages between hosted or enterprise servers and wireless mobile devices. Legacy client-server protocols used in such relay systems typically do not support ad hoc or session-based connections between endpoints, such as provided by peer-to-peer (P2P) computer networks. A P2P computer network uses diverse connectivity between participants in a network and the cumulative bandwidth of network participants rather than conventional centralized resources where a relatively low number of servers provide services to clients. Thus, a pure P2P network is not based on clients or servers but uses only equal peer nodes that simultaneously function as both clients and servers to the other nodes on the network.
Overlay networks are also known in the art for providing custom message routing, increased fault tolerance, and special message delivery semantics such as custodial delivery. An overlay network is a computer network that provides functionality on top of another network, and is typically used when the underlying network infrastructure and protocol characteristics do not match application requirements. A number of different approaches have been explored for message routing in overlay networks. One approach adopts a standard layer-3 routing algorithm for use at layer 7 of the OSI layering model (e.g. routing protocols such as Open Shortest Path First (OSPF), Routing Information Protocol (RIP), and Border Gateway Protocol (BGP)). However, layer-3 algorithms do not handle non-hierarchical addressing very efficiently and are not highly scalable. Another approach is to use ad hoc routing in wireless networks. Unfortunately, ad hoc routing is not scalable beyond several hundred or several thousand nodes. Yet another approach is to use a routing algorithm that is based on a distributed hash table. However, numerous issues remain to be resolved in connection with manageability and scalability of such distributed hash table systems.
Recent developments in P2P and overlay networks present opportunities for enhanced scalability and reliability in the design and implementation of message relay systems, but are subject to the constraints of legacy client-server protocols, as discussed above.
Reference will now be made, by way of example, to the accompanying drawings which show example embodiments of the present application, and in which:
Similar reference numerals may have been used in different figures to denote similar components.
In one aspect, the present application provides a message routing overlay system for control and management of communications between endpoints, comprising a plurality of access nodes for communication with associated endpoints, each of said the access nodes including a transport gateway for transport-layer transfer of data between the endpoints using a protocol that does not support session-based communications, and a transport gateway control for application-layer control of message routing of the transfer of data by establishing a communication session that is uniquely identified using source and destination identifiers and payload type of the data; and a plurality of relay services for facilitating implicit session registration and implicit session establishment between a first one of the access nodes and a second one of the access nodes to initiate the communication session responsive to the first one of the access nodes receiving said the source and destination identifiers and payload type from an associated endpoint and terminating the communication session responsive to determining that the transfer of data has stopped.
In another aspect, the present application provides an access node for connecting one of either a client or a server to a message relay system, comprising a transport gateway for transport-layer transfer of data between the one of either client or server and the message relay system using a protocol that does not support session-based communications, and a transport gateway control for application-layer control of message routing of the transfer of data by establishing a communication session that is uniquely identified using source and destination identifiers and payload type of the data.
In yet another aspect, the present application provides a method of control and management of communications between endpoints, comprising receiving data at a first access node from a first one of the endpoints using a protocol that does not support session-based communications, initiating a communication session between the first access node and a second access node associated with a second endpoint using a transport-independent signaling protocol, wherein the session is uniquely identified using source and destination identifiers and payload type of the data received from the first one of the endpoints, during the communication session between the first access node and the second access node controlling routing of data transfer between the first and second endpoints, and terminating the communication session responsive to determining that the transfer of data has stopped.
Other aspects of the present application will be apparent to those of ordinary skill in the art from a review of the following detailed description in conjunction with the drawings.
Embodiments of the present application are not limited to any particular operating system, mobile device architecture, server architecture, or computer programming language.
As discussed in greater detail below with reference to
Unlike prior art overlay networks discussed above, the distributed message-routing overlay set forth herein handles non-hierarchical addressing, is scalable to millions of client endpoints, supports client authentication and authorization as well as enabling (billable) QoS mechanism, and also supports legacy client protocols.
Referring now to
The enterprise server 120 preferably integrates with one or more additional servers (not shown), such as Microsoft Exchange® IBM® Lotus®, Domino®, Novell® GroupWise®, etc., to enable push-based access to wireless email and data. Enterprise server 120 communicates with a server infrastructure 135 via a router 150 and the Internet 155, through firewall 140. The server infrastructure 135 in turn communicates with a plurality of hand-held mobile communication devices, one such device 130 being illustrated, connected to the server infrastructure 135 through firewall 145 via a wireless network 160 (e.g. GSM/GPRS/EDGE, IDEN, DataTAC, Mobitex, CDMA/EVDO, etc.). Server infrastructure 135 therefore serves as a link between the wired and wireless networks. Data communicated between endpoints (i.e. enterprise server 120 and mobile communication device 130) is preferably encapsulated within messages using a secure protocol (e.g. Secure Multipurpose Internet Mail Extensions (S/MIME)) such that the data remains encrypted at all points between the endpoints (e.g. using FIPS 140-2 validated cryptography).
The message relay system 100 therefore functions essentially as a network of message routing elements that spans the enterprise server 120, the carrier wireless access network 160, server infrastructure 135 and the Internet 155.
Turning briefly to
Network Management System 205 functions in a known manner to monitor relay components through the exchange of Simple Network Management Protocol (SNMP) messages, for identifying conditions that require administrative attention.
Within the User Plane, a plurality of Relay Clients, such as enterprise server 120 and handheld mobile communication devices 130, communicate with a plurality of Transport Gateways 220 at associated Relay Tier-1 access nodes, via load balancers 210 for evenly distributing packet traffic across each access node. Data transport between access nodes in Relay Tier-1 (i.e. between the Transport Gateways 220) conforms to a suitable protocol (e.g. Message Session Relay Protocol (MSRP)).
Communication between each endpoint and the associated access node depends on the type of Relay Client. For example, service entities such as enterprise server 120 may use a protocol such as Simple Mail Transfer Protocol (SMTP) or Extensible Messaging and Presence Protocol (XMPP) whereas mobile communication devices 130 may use a protocol such as Reliable UDP. As discussed above, such legacy protocols do not separate control signals from user data. Therefore, according to an aspect of the exemplary embodiment each Relay Tier-1 access node (separately identified in
According to the exemplary embodiment, SIP is used as the Control Plane protocol for communication between access nodes 300 and relay services (Relay Tier-2), such as a Registrar 240, a Message Store 250 and a Presence Server 310 (
The Service Transport Gateway Control (Service TGCF 230A) implements control plane functions for the access node functioning as handler of connections from Enterprise Servers 120 whereas the Device Transport Gateway Control (Device TGCF 230B) implements control plane functions for the access node functioning as handler of connections from Mobile Devices 130. Each Transport Gateway Control 230 is a ‘stateful’ function in that it maintains state for each and every session in which it is involved.
As discussed above, the User Plane functions of access nodes 300 include transport gateways, wherein the Service Transport Gateway (Service TGF 220A) implements the data transport functions for the access node functioning as handler of connections from Enterprise Servers 120 while the Device Transport Gateway (Device TGF 220B) implements the data transport functions for the access node functioning as handler of connections from Mobile Devices 130.
According to legacy protocols, relay clients are identified using application-specific identifiers (e.g. Email address in the case of SMPT or Jabber ID in the case of XMPP). However, in order to be used in SIP messages these addressing identifiers must be mapped to URIs. Therefore, according to the exemplary embodiment a SIP URI is generated from the application-specific identifiers according to the following format: sip:<email-address> or sip:<jabber-id>.
The term “session” as used in this specification means a set of two relay clients (e.g. enterprise server 120 and mobile communication device 130) and the data streams passing between them. A session is uniquely identified by the following attributes: the identifier of the relay client in the role of SIP caller, the identifier of the relay client in the role of SIP called party or callee, and the (set of) message payload type(s) carried by the session A consequence of the foregoing definition of “session” is that the establishment of sessions results in the exchange of routing information between a communicating pair of access nodes. As long as a session is active, each access node for a relay client participating in that session sends messages to the other access node in order to communicate with the other associated relay client. Furthermore, when the session is terminated, the routing information is automatically deleted. By using SIP, routing updates are explicitly signaled in the Control Plane. Caching of routing information is not required, since a session is established whenever a route needs to be discovered. Moreover, because routes are deleted upon session termination, ‘stale’ routes are not cached.
Since the legacy protocols used by Relay Clients (such as enterprise server 120 and mobile device 130) are stateless (i.e. not session-based), such protocols do not provide any mechanism for session initiation or termination. Therefore, according to an aspect of the exemplary embodiment implicit session registration and implicit session establishment are provided for session initiation and termination. More particularly, a SIP session is initiated in response to an access node 300 receiving the first message with a given source and destination addressing identifier and payload type. Likewise, a session is terminated responsive to a relay access node 300 determining that the traffic for a given source and destination addressing identifier and payload type has stopped, for example, responsive to an explicit message conforming to the legacy protocol for indicating the end of communication. Alternatively, if the legacy protocol uses a connection-oriented transport protocol (such as TCP), the access node may determine that data traffic has stopped when the transport connection is closed. Otherwise, the access node can use a simple time-out mechanism such that if no traffic has been received for a predetermined period of time, the access node determines that traffic has stopped.
In response to receiving a first message, denoted in
A 200 response from the Registrar 240 returns the result of the location query, wherein the Contact header contains the address of the egress node at which the destination client is currently registered, an example of which is as follows:
The Service TGCF 230A then sends a SIP INVITE to the located egress node (i.e. Device TGCF 230B) to initiate SIP session establishment, an example of which is as follows:
It will be noted that SIP session timer support is indicated through Supported, Require and Session-Expires headers and that period refreshes are performed by the Service TGCF 230A in the role of user agent client (i.e. refresher=uac). The body of the INVITE request describes the Service TGCF 230A endpoint of the transport channel (using Session Description Protocol (SDP)), wherein the media type is “application”, the port number is 40001, the protocol is “tcp” and the encoding is “msrp”.
An optional 100 response indicates that the Device TGCF 230B has received and is processing the SIP INVITE request, for example as follows:
A 200 response from the Device TGCF 230B indicates that it is willing to complete the session establishment, for example as follows.
The body of the 200 response describes the Device TGCF 230B endpoint of the transport channel (using Session Description Protocol (SDP)), wherein the media type is “application”, the port number is 40002, the protocol is “top” and the encoding is “msrp”.
The three-way handshaking required for SIP session establishment is completed by a SIP ACK from the Service TGCF 230A to the Device TGCF 230B, an example of which is as follows:
Once the SIP session has been established, the transport channel is open such that data and status messages can be exchanged directly between the Service TGF 220A and Device TGF 220B using a suitable protocol (e.g. Message Session Relay Protocol (MSRP)).
Upon receipt from mobile device 130 of the first data packet at the device TGF 220B, a mutual authentication message exchange sequence occurs. Normally, SIP authentication involves only two REGISTER transactions. The conventional SIP authentication model is extended to three REGISTER transactions, as shown in
An example of the first REGISTER request sent from the Device TGCF 230B to Registrar 240 is as follows:
This first REGISTER request has two Contact headers. The first Contact header serves to clear all existing registrations, while the second Contact header contains new registration information. The Authorization header indicates that the device supports and requires authentication.
The Registrar 240 returns a 401 response, an example of which is as follows:
The exemplary 401 response returns an authentication challenge to the Device TGCF 230B. The WWW-Authenticate header contains id and challenge parameters, including a challenge string, ChallengeMessage( ), that is sent to the device 130 via Device TGF 220B.
An exemplary second REGISTER request from the Device TGCF 230B to Registrar 240 is as follows:
The second REGISTER request carries an Authentication header with three parameters: id, challenge and response. The challenge parameter contains the challenge string that was sent to the device 130 and the response parameter contains the response string generated by the device 130.
The 200 Response from Registrar 240 indicates that the authentication and registration was successful. An example of the 200 Response is as follows:
Upon completion of the authentication procedure, Registrar 240 publishes the new registration state of handheld device 130 to the Presence Server 310, for example as follows:
The exemplary PUBLISH message contains an XML document in PIDF format that provides the new state of the handheld device 130. In the example above, the state is indicated as “open”, thereby indicating that the device 130 is in range of a wireless network 160. The Event header indicates a presence event, while the Expires header indicates the lifetime of the presence information.
An exemplary 200 response from PF 310 to Registrar 240 indicates that the PUBLISH request was successful, as follows;
Next, the ingress access node (Device TGCF 230B) needs to discover the egress access node to which the handheld data should be forwarded. Accordingly, a Device TGCF 230B sends a SIP REGISTER request to the Registrar 240 to query the location of the egress node. As discussed above in connection with
The 200 response from the Registrar 240 returns the result of the location query, wherein the Contact header contains the address of the egress node at which the destination client is currently registered, an example of which is as follows:
The Device TGCF 230B then sends a SIP INVITE to the located egress node (i.e. Service TGCF 230A) to initiate SIP session establishment, an example of which is as follows.
It will be noted that SIP session timer support is indicated through Supported. The body of the INVITE request describes the Device TGCF 230B endpoint of the transport channel, wherein the media type is “application”, the port number is 40002, the protocol is “tcp” and the encoding is “msrp”.
An optional 100 response indicates that the Service TGCF 230A has received and is processing the SIP INVITE request, for example as follows:
A 200 response from the Service TGCF 230A indicates that it is willing to complete the session establishment, for example as follows:
The 200 response contains timer support indicated through Supported, Require and Session-Expires headers, wherein Service TGCF 230A is identified as performing periodic refreshes (in the role of user agent server (uas)). The body of the 200 response describes the Service TGCF 230A endpoint of the transport channel, wherein the media type is “application”, the port number is 40001, the protocol is “tcp” and the encoding is “msrp”.
A SIP acknowledgment (SIP ACK Request) completes the three-way handshaking procedure for SIP session establishment, as follows:
Once the SIP session has been established, the transport channel is open such that data and status messages can be exchanged directly between the Service TGF 220A and Device TGF 220B using a suitable protocol (e.g. Message Session Relay Protocol (MSRP)).
Certain adaptations and modifications of the described embodiments can be made. For example, although each message flow (uniquely identified by source and destination addressing identifiers and payload types) is associated with a unique SIP session it is not necessary that each session utilize a separate and distinct transport channel. Instead, since each message flow carries its own addressing identifiers, multiple flows can be multiplexed onto a single transport channel. However, for reasons of efficiency, in the exemplary embodiment all message flows between an ingress access node and an egress access node are carried in a single transport channel (e.g. a single UDP or TCP flow). Thus, a TCP connection can be established between the ingress and egress access nodes when the first SIP session is established such that subsequent SIP sessions between the same pair of nodes use the same TCP connection. In this way, datagram message flow between the pair of access nodes is multiplexed onto the single TCP connection.
Also, although SIP is used in the exemplary embodiment, other session-based communication protocols (e.g. H.323 or as yet un-established protocols) may be used.
The above discussed embodiments are considered to be illustrative and not restrictive.
