Using DNS for bootstrapping and load-balancing of P2P SIP networks Copyright Adrian Georgescu 2005-2006 AG Projects A P2P SIP network based on DHT contains elements necessary to perform building and maintains a DHT that stores SIP location information, SIP signaling, far-end NAT traversal and bootstrap servers. The P2P SIP Super Nodes (SN) behave like SIP Proxy servers in distributed proxy farm, which serve SIP UAs or ordinary nodes (ON). Lookup steps in C/S SIP networks Today, there are two types of lookups required for completing a session setup over a SIP network of client server model: Lookup 1. DNS lookup to locate the SIP Proxy/Registrar Lookup 2. SIP location lookup to locate the contact addresses for a given AoR Lookup steps in P2P SIP networks P2P SIP introduces an intermediary lookup step to locate the SIP Proxy/Registrar based on a DHT model. The final model becomes thus: Lookup 1. DNS lookup to locate the SN in the DHT domain Lookup 2. DHT lookup for SN to locate the responsable Registrar for the given AoR Lookup 3. SIP location lookup to locate the contact addresses for a given AoR Lookup 4. Media relay lookup based on geographical location of the caller For one, RFC3263 defines a model to locate the SIP Proxy/Registrar for a given domain It involves multiple queries into the DNS and in the SIP registrar responsable for the given domain to produce a set of contact addresses where the called party is found at the moment of the query. For two, the DHT provides the lookup of the SN based on AoR. It is however unrealistic to think that ordinary SIP UAs will have the capability to query directly such DHT. The diversity of DHT implementations will make it difficult to have UAs that are able to query directly in a ubiquitous mode any kind of P2P overlay network for SIP. The assumption is that a DHT network will be queried and managed only by the Super Nodes and the Ordinary Nodes will use standard DNS lookups as already defined RFC3263. So ONs will always use first lookup type to fing a SN in the DHT. Three and four are purely SIP server implementation issues. There are two functions that can be provided by the DNS in a P2P SIP model: 1. Boot-strapping of Super Nodes in the DHT 2. Load balancing of SIP requests generated by Ordinary Nodes DHT bootstrap A DHT introduces a new lookup necessary for bootstrap purposes. The bootstrap is necessary for a SN to take its place in its DHT. This document propose a model to reuse the first lookup type for this purpose. As DHT will not replace the DNS but will rather provide an overlay network for the SIP location service, we can reuse the DNS for other functions present in P2P SIP architecture, like bootstrapping. Bootstrapping implies that there is at least one resource available in the DHT overlay, which can provide the boot-up function for a new SN to join. This can be another SN. We assume the existing SNs available in the DHT have equal rights for allowing join and leave of other SN as requested. A dedicated login server should not be necessary for this task. What is necessary though is that a new SN using the bootstrap procedure finds an available other SN for booting. DNS is used anyway during a bootstrap procedure over the Internet to locate a host-name of the boot-server for instance. For economic reasons we can reuse this concept so that the DNS provides an available SN at the time of the query in the DHT domain requested. This implies that the DNS server itself must becomes DHT aware and must know in real-time the topology of the Super Nodes network. This does not require a change in the DNS protocol but rather requires a DNS server implementation that can generate responses dynamically based on information obtained from the DHT rather that static information obtained from a zone file or other storage container. Load balancing A natural consequence for using a DHT aware DNS server is that we can achieve a natural load balancing function for all ONs that submit SIP requests to the DHT network by using all available SNs. For example let's assume a network of 500 SNs behaving as SIP Proxy/Registrars for a large amount of ONs, like 5 million SIP subscribers. For an ON to locate an outbound Proxy it will perform a DNS set of queries based on the algorithm specified in RFC3263. The algorithm returns a set of possible targets, which can be also specified having an priority and weight. It is however not realistic to send back to a client a list of 500 nodes in the DNS response. The DNS server will simply return a smalled list with 2 or 3 entries. Because of the SIP and DNS timeouts the delay will be to long for the user to wait until a 4th is tried but this is subject to fine tuning. All responses will have the same priority and weight in case of SRV records or a list of A records will be provided which provides same effect. The effect of this arrangement is that given a large numbers of ON's will direct their requests to a all available SNs in a natural round robin fashion without involving any special purpose SIP load balancer. Let's assume a SN leaves the network. Once this happens the DHT migrates to a new configuration. The DNS server is also notified by this topology change and does not provide the host-name of the failed node in its responses. DNS caching can have an impact on this. It is therefore advisable to provide low TTLs with the records returned, like 60 seconds. Ultimately it is up to the SIP UA implementation to do proper lookups and deal with DNS timeouts in a manner that makes sense for the application and not for the underlaying operating system. Example Domain example.com server is a DHT that at the moment of the DNS query has hundreds of live Super Nodes. The preferred transport for this DHT is TLS. The following NAPTR and SRV records will be provided by the DNS server responsable for this DHT domain: example.com. IN NAPTR 10 10 "S" "SIPS+d2t" "" _sips._tcp.example.com. _sips._tcp.example.com. IN SRV 10 10 5060 sip.example.com. As a result of this DNS lookups the SIP UA must do a final lookup to obtain the A record(s) for sip.example.com. Here is where the DHT enabled DNS server plays its role. Should the DTH network contain hundreds of nodes, the DNS response will contain only a random list of three of those nodes. sip.example.com IN A 10.0.0.1 sip.example.com IN A 10.1.0.6 sip.example.com IN A 10.0.2.5 A different set of DNS records will be provided for each query received by the server and this will realize a perfect load balance over time. The SIP UAs will use any of the host-names present in the DNS response and will sent its SIP requests to it. The receiving SN will perform the validation of the SIP request, will perform an internal DHT lookup to locate the responsable SN for the callee and will fork the request as usual.