SipThorDescription

Version 48 (Adrian Georgescu, 09/20/2009 03:11 pm)

1 1 Adrian Georgescu
= SIP Thor description =
2 1 Adrian Georgescu
3 1 Adrian Georgescu
[[TOC(SipThorDescription, SipThorPreparations, SipThorInstallation, depth=2)]]
4 1 Adrian Georgescu
5 46 Adrian Georgescu
SIP Thor provides scalability, load-sharing  and resilience for [wiki:MSPPreparations Multimedia Service Platform]. Its implementation is mature and stable, having several years in production environments with a good track record.
6 33 Adrian Georgescu
7 42 Adrian Georgescu
SIP Thor platform is using the same software components for the interfaces with the end-user SIP devices, namely the SIP Proxy, Media relay and XCAP server used by [wiki:MSPPreparations Multimedia Service Platform] but it implements a different system architecture for them by using Peer-To-Peer concepts.
8 1 Adrian Georgescu
9 17 Adrian Georgescu
[[Image(http://www.ag-projects.com/images/stories/ag_images/thor-platform-big.png, width=500)]]
10 1 Adrian Georgescu
11 17 Adrian Georgescu
== Architecture ==
12 1 Adrian Georgescu
13 32 Adrian Georgescu
To implement its functions, SIP Thor introduces several new components to Multimedia Service Platform. SIP Thor implements a peer-to-peer overlay of several logical network entities called '''roles''' installed on multiple physical machines called '''nodes'''. 
14 1 Adrian Georgescu
15 34 Adrian Georgescu
Each node can run one or multiple roles set in a local configuration. Typical example of such roles are '''sip_proxy''' and '''media_relay'''. Nodes that advertise SIP Proxy or Media Relay capabilities, will handle the load associated with the SIP and RTP traffic respectively and will inherit the built-in resilience and load distribution provided by SIP Thor design.
16 32 Adrian Georgescu
17 32 Adrian Georgescu
SIP Thor operates at IP layer and the nodes can be installed at different IP locations, like different data centers, cities or countries.The sum of all nodes provide a consolidated single logical platform. 
18 32 Adrian Georgescu
19 34 Adrian Georgescu
The platform provides a fail-proof NAT traversal solution that impose no requirements in the SIP clients by using a revers-outbound technique for SIP signaling and geographically distributed relay function for RTP media streams.
20 24 Adrian Georgescu
21 35 Adrian Georgescu
== References ==
22 35 Adrian Georgescu
23 35 Adrian Georgescu
The closest standards based description for what SIP Thor implements is the [http://tools.ietf.org/html/draft-bryan-p2psip-usecases-00#section-3.4.2 Self-organizing SIP Proxy farm] described in the original P2P use cases draft produced by IETF [http://www.ietf.org/dyn/wg/charter/p2psip-charter.html P2PSIP Working Group]. SIP Thor started development during early 2005 and uses a slight variation of the terminology used later in the P2PSIP Working Group.
24 35 Adrian Georgescu
25 48 Adrian Georgescu
SIP Thor design has been explored in several white-papers and conferences:
26 35 Adrian Georgescu
27 35 Adrian Georgescu
 * [http://www.sipcenter.com/sip.nsf/html/AG+P2P+SIP Addressing survivability and scalability of SIP networks by using Peer-to-Peer protocols] published by SIP Center in September 2005
28 47 Adrian Georgescu
 * [http://ag-projects.com/docs/Present/20060518-ScalableSIP.pdf Building scalable SIP networks] presented by Adrian Georgescu at VON Conference held Stockholm in May 2006 
29 47 Adrian Georgescu
 * [http://ag-projects.com/docs/Present/20061004-IMSP2P.pdf Solving IMS problems using P2P technology] presented by Adrian Georgescu at Telecom Signalling World in October 2006
30 47 Adrian Georgescu
 * [http://ag-projects.com/docs/Present/20070227-P2PSIP.pdf  Overview of P2P SIP Principles and Technologies] presented by Dan Pascu at International SIP Conference 2007 in Paris 
31 35 Adrian Georgescu
 * [http://www.imsforum.org/search/imsforum/p2p P2PSIP and the IMS: Can they complement each other?] published by IMS forum June 2008 -  online accessible [http://www.ag-projects.com/content/view/519/176/ here]
32 1 Adrian Georgescu
33 21 Adrian Georgescu
== P2P design ==
34 21 Adrian Georgescu
35 34 Adrian Georgescu
SIP Thor is designed around the concept of a peer-to-peer overlay with equal peers. The overlay is a flat level logical network that handles multiple roles. The peers are dedicated servers than handle the application logic of each role. As peers are dedicated servers, low churn and good connectivity between peers is assumed in the normal operations of the overlay.
36 1 Adrian Georgescu
37 34 Adrian Georgescu
The nodes interface with native SIP clients that are unaware of the overlay logic employed by the servers. Internally to the SIP Thor network, the lookup of a resource (a node that handles a certain subscriber for a given role at the moment of the query) is a one step lookup in a hash table. 
38 31 Adrian Georgescu
39 43 Adrian Georgescu
The hash table is basically an address space with integers arranged on a circle where nodes and SIP addresses are mapped to. The concept can be found in DHT implementations like [http://en.wikipedia.org/wiki/Chord_(DHT) Chord]. Join and leave primitives take care for the addition and removal of nodes in the overlay in a self-organizing fashion.
40 1 Adrian Georgescu
41 21 Adrian Georgescu
== Security ==
42 17 Adrian Georgescu
43 27 Adrian Georgescu
Communication between SIP Thor nodes is encrypted by using Transport Level Security (TLS). Each node part of the SIP Thor network is uniquely identified by a X.509 certificate. The certificates are  signed by a Certificate Authority managed by the operator and can be revoked as necessary for example when a node has been compromised. 
44 27 Adrian Georgescu
45 44 Adrian Georgescu
The X.509 certificate and its attributes are used for authentication and authorization of the nodes when they exchange overlay messages over the SIP Thor network. 
46 12 Adrian Georgescu
47 16 Adrian Georgescu
== Scalability ==
48 17 Adrian Georgescu
49 44 Adrian Georgescu
SIP call flows over the SIP Thor overlay involves a maximum of two nodes, regardless of the number of nodes, subscribers or devices handled by the SIP Thor network. Shall SIP devices be 'SIP Thor aware' and able to make direct lookups in the overlay, this could greatly improve the overal efficiency of the system as less SIP traffic and less queries will be generated inside the SIP Thor network. A publicly reachable lookup interface is exposed by each node.
50 1 Adrian Georgescu
51 36 Adrian Georgescu
The current implementation allows SIP Thor to grow to accomodate thousands of physical nodes, which can handle the traffic of any size for a real-time communication service deployable in the real world today (e.g. if the SIP server node implementation can handle one hundred thousand subscribers then 100 nodes (roughly the equivalent of three 19 inch racks of data center equipment) are required to handle a 10 million subscriber base. The overlay lookup type is referred as O(1) in classic P2P terminology and SIP Thor's implementation handles up to half a million queries per second on a typically server processor, which is several order of magnitude higher than when is expected in normal operations.
52 31 Adrian Georgescu
53 31 Adrian Georgescu
The service scalability is in reality limited by the performance of accounting sub-system used by the operator or by the presence of centralized functions like prepaid.
54 5 Adrian Georgescu
55 10 Adrian Georgescu
== Load sharing ==
56 9 Adrian Georgescu
57 37 Adrian Georgescu
SIP Thor is designed to equally share the traffic between all available nodes. This is done by returning to the SIP clients that use standard RFC 3263 style lookups, a random and limited slice of the DNS records that point to actual live nodes that perform the SIP server role. DNS records are managed internally by a special role '''thor-dns''' on multiple nodes assigned as DNS servers in the network. This simple DNS query/response mechanism achieves a near perfect distribution without introducing any intermediate load balancer or latency. Internally to SIP Thor, similar principle is used for load balancing internal functions like XCAP queries or SOAP/XML provisioning requests.
58 17 Adrian Georgescu
59 37 Adrian Georgescu
By using a virtualization technique, the peer-to-peer network is able to function with a minimum number of nodes while still achieving fair equal distribution of load when using at least three physical servers.
60 29 Adrian Georgescu
61 29 Adrian Georgescu
== Zero configuration ==
62 29 Adrian Georgescu
63 30 Adrian Georgescu
There is no need to configure anything in the SIP Thor network for supporting the addition of a new node besides starting it with the right X.509 certificate.
64 1 Adrian Georgescu
65 2 Adrian Georgescu
== Thor Event server ==
66 1 Adrian Georgescu
67 1 Adrian Georgescu
'''thor-eventserver''' is an event server, which is the core of the messaging system that is used by the SIP Thor network to implement communication between the network
68 1 Adrian Georgescu
members.  The  messaging  system  is based on publish/subscribe messages that are exchanged between network members.  Each entity in the network publishes its own
69 1 Adrian Georgescu
capabilities and status for whomever is interested in the information. At the same time each entity may subscribe to certain types of information which  is  published by the other network members based on the entity's functionality in the network.
70 1 Adrian Georgescu
71 1 Adrian Georgescu
Multiple event servers can be run as part of a SIP Thor network (on different systems, that are preferably in different hosting facilities) which will improve the
72 1 Adrian Georgescu
redundancy of the SIP Thor network and its resilience in the face of network/system failures, at the expense of linearly increasing the  messaging  traffic  with
73 1 Adrian Georgescu
the number of the network members. It is recommended to run at least 3 event servers in a given SIP Thor network.
74 1 Adrian Georgescu
75 2 Adrian Georgescu
== Thor Manager ==
76 1 Adrian Georgescu
77 1 Adrian Georgescu
'''thor-manager''' is the SIP Thor network manager, which has the role of maintaining the consistency of the SIP Thor network as members join and leave the network. The manager  will  publish  the  SIP  Thor  network status regularly, or as events occur to inform all network members of the current network status, allowing them to adjust their internal state as the network changes.
78 1 Adrian Georgescu
79 1 Adrian Georgescu
Multiple managers can be run as part of a SIP Thor network (on different systems, that are preferably in different hosting  facilities), which  will  improve  the redundancy  of  the  SIP Thor network and its resilience in the face of network/system failures, at the expense of a slight increase in the messaging traffic with each new manager that is added. If multiple managers are run, they will automatically elect one of them as the active one and the others will be  idle until the active manager stops working or leaves the network. Then a new manager is elected and becomes the active manager.  It is recommended to run at least 3 managers in a given SIP Thor network preferably in separate hosting facilities.
80 1 Adrian Georgescu
81 2 Adrian Georgescu
== Thor Database ==
82 1 Adrian Georgescu
83 1 Adrian Georgescu
'''thor-database''' is a component of the SIP Thor network that runs on the central database(s) used by the SIP Thor network. Its purpose is to publish the location of the provisioning database in the network, so that other SIP Thor network members know where to find the central database if they need to access information from it.
84 2 Adrian Georgescu
85 1 Adrian Georgescu
== Thor DNS ==
86 1 Adrian Georgescu
87 9 Adrian Georgescu
'''thor-dns''' is a component of the SIP Thor network that runs on the authoritative name servers for the SIP Thor domain. Its purpose is to keep the  DNS  entries for the SIP Thor network in sync with the network members that are currently online. Each authoritative name-server needs to run a copy of the DNS manager in combination with a DNS server. The SIP Thor DNS manager will update the DNS backend database with the appropriate records as nodes join/leave the SIP Thor network,  making  it reflect the network status in realtime.
88 1 Adrian Georgescu
89 2 Adrian Georgescu
== Thor Node ==
90 1 Adrian Georgescu
91 1 Adrian Georgescu
'''thor-node''' is to be run on a system that wishes to become a SIP Thor network member. By running this program, the system will join the SIP Thor network and  become part of it, sharing its resources and announcing its capabilities to the other SIP Thor network members.
92 1 Adrian Georgescu
93 1 Adrian Georgescu
The network can accomodate one or more nodes with this role, SIP Thor takes care automatically of the additions and removal of each instance. The currently supported roles are '''sip_proxy''' in combination with OpenSIPS and '''voicemail_server''' in combination with Asterisk. Other roles are directly built in MediaProxy ('''media_relay'''), NGNPro ('''provisioning_server''') and OpenXCAP ('''xcap_server'''), for these resources no thor-node standalone component is required. 
94 1 Adrian Georgescu
95 2 Adrian Georgescu
== Thor Monitor ==
96 2 Adrian Georgescu
97 2 Adrian Georgescu
'''thor-monitor''' is a utility that shows the SIP Thor network state in a terminal. It can be used to monitor the SIP Thor network status and events. Example:
98 2 Adrian Georgescu
99 4 Adrian Georgescu
== NGNPro ==
100 4 Adrian Georgescu
101 38 Adrian Georgescu
NGNPro component performs the enrollment and provisioning server role. It saves all changes persistently in the bootstrap database and caches the data on the responsable node at the moment of the change. The network can accomodate multiple nodes with this role, SIP Thor takes care automatically of the additions and removal of each instance.
102 4 Adrian Georgescu
103 4 Adrian Georgescu
NGNPro exposes a [wiki:ProvisioningGuide SOAP/XML interface] to the outside world and bridges them with the distributed data structures employed by SIP Thor nodes.
104 2 Adrian Georgescu
105 1 Adrian Georgescu
== New roles ==
106 1 Adrian Georgescu
107 26 Adrian Georgescu
Adding new roles to the system can be realized programatically by obeying to the SIP Thor API and depending on the way of working of the component that needs to be integrated in the SIP Thor network. 
108 26 Adrian Georgescu
109 45 Adrian Georgescu
At a minimum, the software must implement a component that publishes its availability in the network (this task can be programmed outside of the specific software by adding it to the generic thor_node configuration and logic) and must be able to lookup resources in the SIP Thor network and use the returned results in its own application logic. 
110 26 Adrian Georgescu
111 26 Adrian Georgescu
Depending of the inner-working of the application performed by the new role, other roles may need  to be updated in order to serve it (e.g. adding specific entries into the DNS or moving provisioning data to it).