In Internet protocol (IP)-based communications networks, network traffic may be distributed or load-shared among multiple IP network servers. In order to facilitate better understanding and clarity when presenting the subject matter described herein, the embodiments shown and described below refer to session initiation protocol (SIP)-based network traffic being distributed across a plurality of SIP application servers (ASs) using a domain name system (DNS) lookup mechanism. However, it is appreciated that this is not intended to be limiting and that other types of communications networks, protocols, servers, and mechanisms may be used without departing from the scope of the subject matter described herein.
In a SIP network, a SIP proxy may be connected to a plurality of SIP application servers for distributing SIP traffic among the ASs. As used herein, a “SIP proxy” refers to an intermediary device in a SIP network that acts as both a server and a client for the purpose of making requests on behalf of other clients and primarily plays the role of routing messages to one or more associated devices. Also, as used herein, a “SIP AS” refers to an entity in a SIP network that carries out functions not directly related to layer 3 (or lower) routing and determines which SIP application on the server should be used for handling a particular SIP session. Exemplary functions that may be performed by a SIP AS include: session control, call processing language (CPL) services, call forwarding, call logging, presence management, instant messaging, conference services, interactive voice response (IVR) service, registration, prefix matching, and next hop routing.
In order to route traffic to a particular AS, a SIP proxy may query a DNS server to obtain network identity, priority, and other information regarding the network server. For example, a DNS server may maintain records for each of a plurality of application servers and provide the appropriate DNS record in response to a valid DNS query. One DNS record type is a service resource record (SRV RR) which includes information regarding services provided by a network server (e.g., SIP AS). A more detailed description of the SRV RR message type may be found in RFC 2782, which is incorporated by reference herein in its entirety.
During normal operation, network traffic may be distributed/load-shared among multiple network servers by associating a weight factor with each network server specified in a DNS SRV record list and, when the SRV RR is retrieved as part of normal DNS lookup procedures, traffic may be prioritized among the network servers based on their weight factors included in the SRV RR. Conventional DNS records provide a one-to-one association between hostname identifiers and network servers. Therefore, when a DNS query requesting information associated with a network server is sent to a DNS server, the DNS server returns a single hostname identifier for each network server in a DNS SRV record.
For example, in FIG. 1A, a conventional method for distributing/load-sharing network traffic between two different SIP ASs using weighted DNS records is shown. Referring to FIG. 1A, SIP proxy 100 may receive traffic to be load balanced among SIP AS 102 and 104. In order to determine where to route traffic, SIP proxy 100 may query DNS server 106 to obtain priority and weighting information for SIP AS 102 and 104. For example, SIP proxy 100 may send DNS query 108 to DNS server 106. In response, DNS server 106 may provide DNS response 110 that includes an ordered/prioritized list of contact addresses in an SRV record, where the first contact address in the list is the highest priority/most preferred network server and the second contact address in the list is the next most preferred, and so on.
As shown in FIG. 1A, SRV records maintained by DNS server 106 for SIP application server A 102 and SIP application server B 104 include an identical priority value (i.e., 10) for each AS 102 and 104, yet include different weight values of 45 for AS 102 and 55 for AS 104. After SIP proxy 100 has obtained priority and weight values for SIP AS 102 and 104, SIP proxy 100 may issue a second DNS query in order to obtain the IP addresses for each of AS 102 and 104. For example, SIP proxy 100 may issue DNS query 112 and receive DNS response 114 containing the IP addresses of SIP AS 102 and 104. As a result, 45% of traffic flows to AS A 102 and 55% of traffic flows to AS B 104 from the SIP Proxy under normal conditions.
FIG. 1B illustrates two types of conventional DNS records that may be provided by DNS server 106 in response to a query for information associated with SIP AS 102 and/or 104. Referring to FIG. 1B, SRV RR 110 may include a plurality of entries, where each entry has a plurality of fields. According to one possible embodiment, SRV RR 110 may have the following format “Service.Protocol.Name TTL Class Type Priority Weight Port Target”, where the “Service” field is the symbolic name of the desired service. For example, as shown in FIG. 1B, Service field 116 includes “SIP” indicating that the RR is associated with the session initiation protocol.
The “Protocol” field indicates the symbolic name of the desired protocol of the requested service. Example protocols include, but are not limited to, the transmission control protocol (TCP) and user datagram protocol (UDP). In FIG. 1B, protocol field 118 includes “tcp” indicating that TCP is used.
The “Name” field indicates the domain name for which the RR is valid. In this example, name field 120 includes the domain name “example.com.”
The “TTL” field indicates a standard DNS time-to-live value expressed in seconds. It is appreciated that in order to increase efficiency of the domain name system, nameservers are divided into “authoritative nameservers” and “caching nameservers,” where the ultimate authority for the validity of data for a particular resource record is set by the authoritative nameserver and a caching nameserver obtains a copy of an authoritative RR from an authoritative nameserver and caches the record for the time specified in TTL field 122. Therefore, if a caching nameserver receives a request for a record before the TTL for that record has expired, the caching server will reply with the cached resource record rather than retrieve it from the authoritative nameserver. The “Class” field indicates a class as defined in RFC 1035, which is incorporated by reference herein in its entirety. For example, class 124 indicates the IN class associated with the Internet.
The “Type” field indicates the DNS record type. Exemplary record types include a service record (SRV), an IPv4 address record type (A), and an IPv6 record type (AAAA) which are also defined in RFC 1035. It is appreciated that other DNS record types suitable for implementing the subject matter described herein may be used without departing from the scope of the subject matter described herein. As shown in FIG. 1B, because DNS record 110 is a service record, type field 126 includes SRV.
The “Priority” field indicates a preference for an entry wherein entries having lower priority values are always preferred over entries having higher priority values. Multiple entries may be associated with the same priority value, in which case, entries may be ordered based on their weights: the priority of the target host, lower value means more preferred. For example, priority field 128 includes identical values (i.e., 10) for each of the first and second entries in RR 110 corresponding to a preference of the first and second entries over entries having higher priority values (not shown).
The “Weight” field indicates a relative weight for records with the same priority, wherein higher weights are preferred over lower weights. For example, weight field 130 of the first entry in RR 110 includes a value of 45 and the second entry includes a weight of 55, corresponding to a relative preference for the second entry.
The “Port” field indicates port on which the requested service indicated in is found. For example, port field 132 includes port 5060 corresponding to tcp protocol indicated in protocol field 118.
The “Target”, or “target hostname,” field indicates the canonical hostname of the machine providing the service. For example, target hostname field 134 includes a first entry corresponding to SIP AS A 102 that is resolvable to its IP address 10.11.12.14 and a second entry corresponding to SIP AS B 104 resolvable to IP address 10.11.12.16.
Also shown in FIG. 1B, record 114 may be maintained by DNS server 106 that associates SIP application servers 102 and 104 with their respective IP addresses. For example, RR 114 may contain target hostname field 136 corresponding to SIP application servers 102 and 104, type field 138 indicating that DNS record 114 is an address (A) record, and a network/IP address field 140 indicating the network addresses of SIP application servers 102 and 104.
Also, during the congestion or partial failure of one of SIP AS 102 or 104, DNS server 106 may publish records that allow the network to manage failover. For example, in the event of the failure of one of network servers 102 or 104, all traffic to the affected network server is shed and redistributed among the remaining network servers according to the weights/priorities specified in the DNS SRV record list. So, when a network server becomes congested, congesting message traffic will continue to be directed to the network server until failure and, upon failure, send a message to neighboring network devices that it is no longer available. The key point to appreciate is that because the entire processing capacity of the network server is linked to the single hostname identifier provided in the DNS SRV record, the network server may only control the amount of traffic it receives in a binary all-or-nothing approach.
FIG. 1C illustrates the conventional use of DNS records for redistributing network traffic to unaffected network servers during congestion or partial failure of another network server. As shown in FIG. 1C, if SIP AS A 102 becomes severely congested or otherwise unavailable, AS A 102 may notify SIP Proxy 100 that no further traffic should be sent to AS A 102 (until a retry period has expired) by sending a SIP 5xx (Server Error) message to SIP proxy 100. SIP 5xx responses are failure responses given when a server has erred that indicate that the server is temporarily unable to process the request due to a temporary overloading or maintenance of the server. The server may then indicate when the client should retry the request in a Retry-After header field (e.g., a randomly chosen value of between 0 and 10 seconds). If no Retry-After is given, the client acts as if it had received a 500 (Server Internal Error) response which indicates that the server encountered an unexpected condition that prevented it from fulfilling the request. Upon receipt of a 5xx message, SIP proxy 100 directs 100% of its application traffic to AS B 104 as the only remaining AS in the list.
One problem associated with conventional methods for redirecting traffic among network servers in the event of congestion or partial failure of one of the network servers is that it is an all-or-nothing approach. Thus, even though a congested network server may be capable of processing some traffic (but less than its normal load), the DNS response which directs traffic to network servers simply shuts off all traffic to the congested network server. This results in a coarse, and therefore sub-optimal, utilization of network server resources in the event of network server congestion.
As such, a SIP network server would congest until total failure and: (1) only after total failure occurred would traffic be steered away from the server, and (2) once total failure has occurred, all traffic is steered away from the affected server.
Accordingly, in light of these difficulties, a need exists for improved methods and systems for throttling traffic received by/sent to an IP network server using DNS.
USPTO Backgrounds
USPTO Backgrounds