Patent Application
20080147885
The present invention relates generally to IP address resolution and finds particular utility in resolving universal resource identifiers (URIs) to IP addresses and port numbers for host processing nodes constituting a local intranet. In the distributed processing to implement various services and protocols in packet switched processing systems and networks, many protocols run over the Internet Protocol (IP). Examples include session initiation protocol (SIP) used in providing IP multimedia subsystem (IMS) services, in which individual call instances require interoperation of many SIP components to provide the desired multimedia services. In a typical scenario, many of the SIP components are members of a local data center or intranet sharing a common domain, for example, within a single office complex or building. When each component requires a service from another component, the services is requested using a URI which is resolved to a specific IP address and port number using a domain name system (DNS) server in the intranet. If two or more of the local processing host nodes are capable of providing a particular service, the DNS server returns a list of IP addresses, and rotates the ordering of the list for each query so as to attempt to distribute the traffic evenly among the identified servers. The conventional DNS URI resolution technique, however, suffers from a number of shortcomings, including expenditure of network and CPU resources on both the client and the DNS server to obtain the necessary data using asynchronous queries that require a waiting state. Furthermore, the obtained data may be obsolete and does not reflect the actual availability of the identified peer processing node. In the situation where several peer nodes can fulfill a given request, for example, the “round robin” type load distribution implemented by the conventional DNS server does not take into account the actual loading of the peer host processing nodes of the intranet, wherein overloaded host nodes will continue to be used even though other nodes are less loaded. In this regard, the local DNS server is rarely updated in real time with the operational state of the resources it resolves to, and furthermore, the DNS caching mechanism may considerably delay the availability of the status information to the processing node. Moreover, the current DNS approach does not provide for load shedding or admission control, whereby the DNS server continues to resolve to a peer node even if it is overloaded. In addition, adding or removing a resource from the network is complicated in a DNS architecture because even though a resource could be removed from the DNS server immediately, the caching mechanism used by the other (requesting) nodes will retain the record of this resource and will continue to attempt to use it for a significant time. Also, the local DNS server must be closely provisioned and managed to maintain an accurate URI to IP address translation capability. Thus, there is a need for improved methods and systems for resolving resource names or URIs to IP addresses in an intranet.
The following is a summary of one or more aspects of the invention provided in order to facilitate a basic understanding thereof, wherein this summary is not an extensive overview of the invention, and is intended neither to identify certain elements of the invention, nor to delineate the scope of the invention. The primary purpose of the summary is, rather, to present some concepts of the invention in a simplified form prior to the more detailed description that is presented hereinafter.
The various aspects of the present disclosure relate to systems and methods for resolving URIs to IP addresses and port numbers in an intranet, wherein host processing nodes or peers maintain a local data store with entries indicating the status of service application ports (SAPs) provided by the other hosts of the intranet. URIs within the intranet are resolved at the host processing nodes without DNS server consultation by local address resolution components that can provide load shedding and load balancing according to the data store entries. The local hosts provide regular reports that are broadcast throughout the intranet to provide up to date status information for the SAPs, allowing a host requiring a particular URI to locally resolve the URI to one or more IP addresses and port numbers based on the locally stored status information, and to also implement load shedding and balancing. By locally caching the address resolution information as well as the status information, URIs can be resolved to local IP addresses and port numbers within the intranet quickly using less processing resources and also mitigating host processor overloading to balance the loading of host processing nodes that are able to service a given request.
One or more aspects of the disclosure relate to a system for resolving a unified resource identifier to an Internet address and a port number in an intranet formed by a plurality of host processing nodes. The system comprises an address resolution system of a first host processing node having a service application port data store and a client component. The data store includes entries corresponding to SAPs of other host nodes, with the individual entries indicating an Internet address and a port number for the corresponding service application port. The client component resolves a URI for the first host to an Internet address and a port number according to the entries of the service application port data store. The resolution system may further include a server component that broadcasts reports indicating a status of one or more service application ports associated with the first host processing node to address resolution systems associated with other host processing nodes of the intranet. The client component in the first host receives the reports broadcast by other host processing nodes and updates the SAP data store entries accordingly, wherein the entries in certain embodiments may include loading indicators according to which the client component performs load balancing and/or load shedding when servicing URI resolution requests.
The local address resolution system may be interoperative with a local DNS server of the intranet, with the client component of the local host processing system referring address resolution requests to the DNS server for URIs that are not associated with a local SAP, whereby the local address resolution system can support conventional DNS requests and client applications need not be changed. In this manner, the service can locally resolve URIs to SAPs within the intranet quickly and efficiency to provide load balancing and overload protection, and can refer non-local URI resolution requests to the conventional DNS resolution system. Moreover, the local DNS server also receives the reports broadcast by host processing nodes of the intranet, and can then transfer the status information from the reports to a second DNS server outside the intranet, such as by notifying an upper layer DNS server that status information has been received to initiate transfer of local zone information.
Further aspects of the invention provide a data center for supporting multimedia services, comprising a plurality of host processing components, some of which providing SAPs for supporting multimedia services via a session initiation protocol (SIP) infrastructure, as well as address resolution systems individually associated with at least some of the data center hosts. The individual address resolution systems comprise a SAP data store with Internet address and port number entries corresponding to SAPs of the data center, as well as a client component providing URI resolution according to the SAP data store entries.
Still other aspects relate to a method for resolving a URI to an IP address and port number in an intranet. The method includes providing a SAP data store in one or more host processing nodes, which includes SAP entries indicating an IP address and a port number for the corresponding SAP, as well as broadcasting reports to host processing nodes of the intranet indicating a status of SAPs of the broadcasting host processing node. The method further comprises updating the entries of the service application port data store according to the received reports at host processing nodes having a SAP data store, and resolving URIs associated with SAPs of the intranet to corresponding IP addresses and port numbers according to the SAP data store entries. The method may further include load balancing and/or load shedding at least partially according to the loading indicators, and referring resolution requests to a DNS server for URIs that are not associated with an intranet SAP.
The following description and drawings set forth in detail certain illustrative implementations of the invention, which are indicative of several exemplary ways in which the principles of the invention may be carried out. Various objects, advantages and novel features of the invention will become apparent from the following detailed description of the invention when considered in conjunction with the drawings. The present invention may be embodied in the construction, configuration, arrangement, and combination of the various system components and acts or events of the methods, whereby the objects contemplated are attained as hereinafter more fully set forth, specifically pointed out in the claims, and illustrated in the accompanying drawings in which:
Referring now to the figures, wherein the showings are for purposes of illustrating the exemplary embodiments only and not for purposes of limiting the claimed subject matter,
Applications as clients running on these hosts 12 may request access to a service application port (SAP) 13 hosted by a different host node 12 within the intranet 10, wherein a SAP 13 may be any interface port of a host 12 where a specific service is provided to a client, with each SAP 13 being assigned a URI which when resolved gives a unique IP address and port number combination used by a client in obtaining the requested service. Furthermore, there may be more than one SAP within the intranet that is capable of providing a desired service to an application. One or more of the processing nodes 12 include or are otherwise operatively associated with a Load Distribution and Admission Control (LD-AC) type address resolution system 20 for resolving URIs to an Internet address and a port number in the intranet 10, which also forwards URI resolution requests to the local DNS server 30 to resolve URIs of SAPs that are not part of the intranet 10 using one or more DNS servers 30a that are not part of the intranet 10.
Referring also to
In the illustrated IMS data center 110, a single server 112 of the IMS data center 110 may provide one or more instances of a Proxy Call Session Control Function (P-CSCF) 113, an Interrogation CSCF (I-CSCF) 113, a Serving CSCF (S-CSCF) 113, and/or other SAPs 113 available to provide certain services to one or more clients of the application servers 118 and the host processing nodes 112. In addition, one, some, or all of the NGSS server host nodes 112 comprises an LD-AC type address resolution system 20 for resolving URIs to an Internet address and a port number in the data center intranet 110. In the course of processing a call from the mobile 104, for instance, the P-CSCF 113 servicing the call may be provisioned to utilize the services of one of the available l-CSCFs 113 in the data center 110, and will accordingly request such services for SIP processing using a general URI label specifying the particular SAP type of ICSCF to service a SIP invite for authenticating the mobile 104 with an HSS function of the data center 110. The LD-AC system 20 of the P-CSCF resolves the URI to one or more pairs of IP addresses and port numbers for a suitable l-CSCF in the data center 110 and the requesting P-CSCF forwards the SIP invite to a selected I-CSCF. The l-CSCF, in turn, may be provisioned with a URI for a S-CSCF for processing SIP invites, and the I-CSCF uses its local LD-AC to resolve this URI to one or more suitable IP address/port number pairs from which the I-CSCF can direct the invite to an S-CSCF for downloading a user profile from an HSS function in the data center 110.
In performing various multimedia services for processing a call to or from the mobile 104 or other user devices, the host processing nodes 112 of the data center 110 thus need to resolve provisioned or non-provisioned URIs to IP addresses and port numbers, wherein the local LD-AC systems 20 provide this service using locally cached status information for URIs corresponding to SAPs within the datacenter intranet 110, and then refer such resolution tasks to the DNS server 30 for external SAPs. Moreover, the applications running on the host processing nodes 112, as clients, request the services and process the calls using suitable protocols, such as SIP and the conventional DNS URI resolution calls except as noted herein. In particular, the calls to the LD-AC address resolution systems 20 are the same as those made to conventional DNS URI resolution systems, wherein the applications themselves need not be modified in order to employ the LD-AC features set forth herein. For a typical URI resolution request, a client in one of the host processing nodes (NGSSS) 112 may submit a URI in the form SAP type.LZD with no service label (e.g., host IP address) and with the LZD label representing a local zone domain shared by the components of the intranet 110. In servicing this form of request, the LD-AC systems 20 note the lack of a service label and may thus resolve to any suitable host, and can therefore employ load distribution to select the best candidate host in resolving the URI. The local LD-AC system 20, in turn, will resolve this URI, if possible, into one or more sets of IP address and port number components for SAPs within the data center intranet 110 and otherwise will forward the URI to the DNS server 30 for resolution to SAPs outside the data center 110. In another possible request, a service label (host IP address) is provided, in which case the LD-AC system 20 performs a URI to IP address/port number resolution with no load distribution.
Referring also to
As best seen in
In one implementation shown in
Using this information 210 from the report 200, the detect and tracking component 22 of the LD-AC client 20a (
In the illustrated implementation, each LD-AC 20 thus reports to each of the other LD-AC systems 20 of the intranet 110, and each SAP data store 23 is thus maintained and updated locally at the host nodes 112. As a result, each SAP data store 23 provides a local cache of SAP status information from which the LD-AC client components 20a can provide URI resolution for URIs in the intranet 110, and can also perform load balancing and shedding functions so as to evenly distribute loads among the possible SAPs adapted for a requested service. As shown in
In addition, the exemplary client 20a includes a load distribution-load balancing component 25 that uses the loading entries 264 to compute a load balancing factor or value Si 268 for each SAP 113, which is then indicated in the data store 23. In the illustrated LD-AC system 20, each SAP 113 that was previously “in service” but which is not in service anymore will trigger an re-calculation of the load distribution algorithm, the load distribution computation only considers SAPs 113 that are in service, and the SAP/Host Name to IP and port number resolution considers all SAPs 113 in the data store 23 that are not “Out Of Service”.
For overload protection (load shedding), the client component 20a computes a shedding ratio P for each SAP group or cluster 250, and may employ any suitable algorithm or computation that prevents or inhibits resource overloading in operation of the SAPs 113. One possible implementation is set forth in U.S. Pat. No. 4,974,256 to Cyr et al., assigned to the assignee of the present invention, the entirety of which is hereby incorporated by reference as if fully set forth herein, although any other algorithm that provides load shedding can be used. In addition, while the load distribution and load shedding algorithms may be performed locally as shown in the illustrated implementations, these can alternatively be performed in one location with the results being replicated to the local SAP data stores 23. Likewise, the LD-AC session distribution processing can either be centralized in one place in the intranet 110 or can be distributed in the local LD-AC systems 20 which have a client component 20a. The load shedding feature advantageously ensures that the overall CPU resources for a given SAP 113 are not saturated, and is generally implemented by selectively shedding all or part of the incoming processing load (e.g., for new calls in an IMS data center intranet implementation 110) to protect the SAP cluster 250, and the load shedding is done at the source according to the calculated load shedding ratio P. In one example, the ratio P for each SAP cluster 250 is computed according to the following equation, in which P(t+1) is the calculated shedding at time “t+1”, and P(t) is the previous shedding ratio at time “t”:
In this implementation, Pt is the load shedding ratio at time “t”, T is a threshold for load shedding (e.g. which may be provisioned for the LD-AC system 20), G2 is a dimensionless (provisioned) gain factor, and A is the average CPU load in all the hosts 112 of a SAP cluster 250 (e.g., all the hosts 112 with SAPs 113 able to perform a given SAP service type). In one possible example, the threshold value T defaults to 85%, although any suitable value can be used. The result of the calculation (P) gives the ratio of new call requests in an IMS data center implementation that should be rejected (e.g., call load shedding).
For load distribution (access control), the load balancing component 25 employs the host loading information 264 from the SAP data store 23 in computing Si values 268 so as to distribute traffic (e.g., new sessions) to the surrounding processing hosts 112 of the intranet 110 with the goal of equalizing the CPU resource occupancy in each SAP cluster 250. Any suitable computation can be used that tends to evenly distribute the load for the services provided by the SAPs 113 in the intranet 110. The load balancing computation in one possible embodiment provides a value Si for each processing node “i” computed according to the following formula, where S(t+1, i) is the calculated ratio at time “t+1” for node “i” and S(t,i) is the previous ratio at time “t” for node “i”.
In this example, St,i is the fraction of new traffic allowed or provided to a given host processing node “i” 112 at time “t”, A is the average CPU load (ratio) in all the hosts 112 available for the considered SAP 113, ai is the last known CPU load (ratio) of node “i”, G1 is a unitless gain factor (e.g. provisioned with a default of 1), and N is the number of processing hosts 112 available in a given cluster or group to process the considered SAP 113 (e.g., the number of hosts 112 within the considered SAP cluster 250 in
In the illustrated implementation, once the data store 23 has been updated with received reports 200, the client 20a of a given local host processing node 112 performs selective URI resolution services for the local host 112 to resolve a URI associated with a SAP 113 of the intranet 110 to an IP address and a port number according to the entries 252 of the SAP data store 23, using the load shedding and balancing factors P and Si. A spreading algorithm can then be employed to distribute the new sessions to hosts 112 during the subsequent interval until another set of reports 200 are received in the LD-AC system 20, wherein any suitable spreading algorithm or methodology can be employed by which the resulting distribution of URI resolution results is close to the determined ratios P and S, or to at least tend to ensure that an overloaded host processing node 112 does not receive new requests, wherein the distribution to a particular (non-overloaded) node 112 is preferably spread as far as possible over the entire time interval. Simple embodiments can be employed in this regard to spread the incoming URI resolution request load, for instance, wherein the next available and not previously used SAP 113 is selected for which if the CPU load is less than a SAP CPU overload value, where the overload value threshold can be any suitable provisioned or dynamically adjusted value, such as about 85% in one example. In this case, the LD-AC advantageously excludes ‘out-of-service’ SAPs 113 from the spreading. In another possible implementation, a simple distribution mechanism may be employed for which the load distribution factors Si are calculated at the LD-AC updates and an interval is assigned to each SAP “SAPi” of a SAP cluster, with the interval beginning with 1+ the sum of all the SAP “Si” with a lower index”, and ends with this previous number plus the “Si” of this SAP (e.g., P-CSCF 1: 0-14; P-CSCF 2: 15-26; P-CSCF 3: 27-64; P-CSCF 4: 65-93; P-CSCF 5: 94-100, for a total of 100). Thus, each available SAP will be apportioned appropriate portions of the range from 0 to 100 according to the load distribution factors Si. In this example, each time a node is to be resolved or selected for the SAP cluster type, the resolving LD-AC system 20 obtains a random number from 0 to 100 and resolves to (e.g., selects) the P-CSCF SAP node having the interval corresponding to the random number. In this manner, the least loaded SAPs 113 will have the highest probability of being selected and efficient load balancing is achieved.
Referring to
Referring also to
Beginning at 302 in
By the above described techniques, the local LD-AC systems 20 facilitate overload protection and load balancing within the intranet 110, along with expeditious URI resolution for services provided by SAPs 113 within the intranet 110. In this regard, the various aspects of the present disclosure are generally applicable to any system in which URI resolution is utilized, and can be implemented so as to avoid any changes in the DNS type interface provided to requesting applications or SIP stacks 18. Moreover, the disclosure finds particular utility in systems where a significant amount of services are provided locally within a given intranet, such as the exemplary IMS data center 110 illustrated and described above. In this respect, where a large number of requested URIs are resolved within the requesting host's intranet, the LD-AC systems 20 provide fast URI resolution to applications or SIP stacks 18 without requiring access to the local DNS server 30 or external DNS servers 30a (
Referring also to
By this closer integration of the DNS system and one or more local LD-AC systems, other nodes in remote locations can benefit by knowledge of accessibility and load information related to SAPs they need to utilize. Thus, even though the DNS information may not be updated and distributed in real time (e.g., every few seconds in certain embodiments) as can be done locally through the LD-AC systems 20 within a given intranet 10, the DNS information can nevertheless be updated or refreshed in “quasi-real-time”, for instance, every few minutes using local zone transfers 400. Remote requesting applications can thus be aware of the accessibility of local SAPs 113 and hosts 12 since non-responsive local component records can be quickly removed from the DNS system at large, thereby enhancing the overload protection and load distribution capabilities throughout the system 2. Furthermore, the “weight” in the SRV records can be updated frequently using the server occupancy information broadcast by the LD-AC systems 20.
In the illustrated example of
Although the invention has been illustrated and described with respect to one or more exemplary implementations or embodiments, equivalent alterations and modifications will occur to others skilled in the art upon reading and understanding this specification and the annexed drawings. In particular regard to the various functions performed by the above described components (assemblies, devices, systems, circuits, and the like), the terms (including a reference to a “means”) used to describe such components are intended to correspond, unless otherwise indicated, to any component which performs the specified function of the described component (i.e., that is functionally equivalent), even though not structurally equivalent to the disclosed structure which performs the function in the herein illustrated exemplary implementations of the invention. In addition, although a particular feature of the invention may have been disclosed with respect to only one of several implementations, such feature may be combined with one or more other features of the other implementations as may be desired and advantageous for any given or particular application. Also, to the extent that the terms “including”, “includes”, “having”, “has”, “with”, or variants thereof are used in the detailed description and/or in the claims, such terms are intended to be inclusive in a manner similar to the term “comprising”.
