WO2001039470A1 - Acheminement de demande optimal par exploitation d'informations topologiques de routeurs de paquets - Google Patents

Acheminement de demande optimal par exploitation d'informations topologiques de routeurs de paquets Download PDF

Info

Publication number
WO2001039470A1
WO2001039470A1 PCT/US2000/031990 US0031990W WO0139470A1 WO 2001039470 A1 WO2001039470 A1 WO 2001039470A1 US 0031990 W US0031990 W US 0031990W WO 0139470 A1 WO0139470 A1 WO 0139470A1
Authority
WO
WIPO (PCT)
Prior art keywords
server
content
name
address
anycast
Prior art date
Application number
PCT/US2000/031990
Other languages
English (en)
Inventor
Stephen Glines
John R. Loverso
Original Assignee
Infolibria, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Infolibria, Inc. filed Critical Infolibria, Inc.
Priority to AU17865/01A priority Critical patent/AU1786501A/en
Priority to EP00980633A priority patent/EP1236329A1/fr
Publication of WO2001039470A1 publication Critical patent/WO2001039470A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/45—Network directories; Name-to-address mapping
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1004—Server selection for load balancing
    • H04L67/101—Server selection for load balancing based on network conditions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1038—Load balancing arrangements to avoid a single path through a load balancer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/161—Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/163—In-band adaptation of TCP data exchange; In-band control procedures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/164—Adaptation or special uses of UDP protocol
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1004—Server selection for load balancing
    • H04L67/1017—Server selection for load balancing based on a round robin mechanism

Definitions

  • IP Internet Protocol
  • DNS Domain Name Service
  • a caching server replicates the services and content of an original or primary server.
  • the introduction of caching can therefore markedly increase the apparent bandwidth of the original server, and provide redundancy for the original server. If the cache is topologically close to the client, then overall amount of network traffic is reduced as well.
  • the user of a client computer may demand delivery of a content file associated with a particular URL.
  • the speed of delivery is determined by the ability of the remote host system to deliver the data and the ability of the network to transmit it.
  • Internet Service Providers ISPs
  • client computers can therefore improve client response by placing caching servers behind their routers. By caching the most popularly requested web sites (such as yahoo.com), an ISP can therefore significantly reduce its need for external network traffic.
  • the Guyton paper also recognizes that a messaging technique known as anycast might be useful in locating cache copies.
  • anycast message service is useful in situations where it is necessary to locate a host which supports a particular service, and where several servers may support the service.
  • IP Internet Protocol
  • Unicasting is the most common form of addressing. In the unicast address space, every interface to the Internet has a separate IP layer address. Most machines have only one interface, although other machines such as routers may have many such addresses.
  • Multicast messaging allows a single message to be addressed to a group of systems. It is a form of broadcast messaging in which a user may send a message to all listening recipients. Anycast messaging assumes there are multiple systems providing an identical service. Since all the machines in the anycast address space are identical, they can have the same IP address. Routing policies within the Internet Protocol can be depended upon to automatically route packets to the nearest anycast system, namely the one with the best distance metric (e.g. the least number of hops) from the client (at the current time or via the current routing topology).
  • the best distance metric e.g. the least number of hops
  • an anycast messaging construct can be used to locate one of several DNS resolvers in a network.
  • standard network protocols only guarantee that the route which an anycast message takes from its source to its destination is the best one at a given instant in time.
  • two packets sent to the same anycast IP address even if sent in sequence, one immediately after the other, may end up at two physically different anycast servers. If an anycast message comprises more than one packet, its component parts may thus actually take entirely different routes between a sender and receiver.
  • a client issues an anycast request to a service that returns a reply which requires two packets at the TCP layer.
  • the request was served by a first server and that the client's TCP stack has sent two acknowledgment packets. Because the acknowledgments are sent to an anycast address, routers may actually deliver them to different servers, causing the first server to constantly retransmit the second packet.
  • the technique should have minimal impact on existing network infrastructure and require as little reprogramming and rearranging of infrastructure such as routers and gateways as possible. In addition, the technique should not require alteration of standard network communication protocols.
  • content distribution is provided as a service where client requests are automatically routed to the closest available content server.
  • the performance of the system as a whole may be increased by simply adding more server resources to the parts of the network that need it, with minimal change or no change to the network existing infrastructure.
  • name servers are located throughout the network.
  • the name servers are addressable via a common anycast address, as well as being individually addressable via a unicast address unique to each such name server.
  • Each name server is peered with a nearby content server, cache server, or other file server that contains (or can serve) desired content file replicas via unicast addressing.
  • Each name server also advertises itself as being authoritative for the domains associated with the content files stored (or to be served from) the associated content server.
  • IP Internet Protocol
  • a user indicates the location of a content file such as by specifying a Uniform Resource Locator (URL) to a browser program, or by clicking on a hyperlink in a displayed document which has an embedded URL.
  • a URL may, for example, be "http://www.example.com/homepage.htmr'.
  • the browser then makes a request to a DNS service to resolve the IP address of the domain name (e.g. "example.com") specified by the URL.
  • This request is typically formulated as a message sent to a local address resolver.
  • example.com domain is not located in a local domain
  • the local resolver will then proceed to consult public name servers that have been defined as being authoritative for the "example.com” domain.
  • the root domain name servers defined, for example, by the Internic may be programmed to return the common address of the group of name server/content server peers that share a common anycast address.
  • the browser or local resolver Having now resolved an IP address for an authoritative name server (e.g., the previously defined server group address returned) for the "example.com" domain, the browser or local resolver then sends out a DNS request as a UDP datagram to an anycast message to the group. This will now resolve the IP address of www.example.com.
  • an authoritative name server e.g., the previously defined server group address returned
  • the UDP packet will find its way first to the server pair which is located along the shortest path from the requester.
  • the server pair that receives the request then responds by reporting the unique (unicast) address of the associated content replica server (or cluster address if the systems are arranged in a round robin fashion).
  • the user's browser then now make subsequent HTTP level requests to the IP address just received, to obtain the "homepage.html” file from the content server.
  • This content server should represent the “nearest” such server, according to whatever metric the network uses to resolve the anycast address.
  • each physical system which shares the anycast address must perform certain functions, such as a standard but customized name server function, as well as a content server, such as a cache server.
  • a name server is programmed to respond to the common anycast address of the peer content server.
  • the content server will typically never directly respond to the common anycast address (actually, it will never receive an anycast request because it does not have an anycast address).
  • the invention provides a solution to the problem of route discovery by avoiding it altogether. This is accomplished by using an anycast datagram to locate name servers placed on or placed logically near replicated content files.
  • the invention exploits the fact that implicit in the Internet routing mechanism is a concept of "nearness.” In this instance, nearness in the case of an anycast message, may be whatever system the Internet routing scheme first delivers a packet to.
  • Each name server returns the IP address of one or many (such as through round robin or other mechanisms) closely bound and topologically nearby content servers. As a result, a relatively nearby content server, from the perspective or the original requesting client is always located.
  • Fig. 1 is a block diagram of a computer network environment in which the invention may be implemented.
  • Fig. 2 is a flow diagram of a process which makes use of the invention.
  • a computer network 10 in which a mechanism is used to redirect client computer requests for content files to the closest replica of the requested content, by using anycast messaging to a name service provided by a group of name servers distributed in the network.
  • the network 10 may be a typical client-server distributed system, such as is now popularly implemented using personal computer platforms and web based file servers connected via an internetwork 30 such as the Internet.
  • a client computer 12 runs a web browser program that enables a user to submit requests for content files that are nominally located at an origin file server 40. For example, as the user types a Uniform Resource Locator (URL) into a web browser and or uses a pointing device, such as a mouse, to click on a hyperlink embedded in a previously viewed web page, the URL for a particular web site is specified to the browser 12.
  • URL Uniform Resource Locator
  • the URL In the standard scenario, which is well known in the prior art, if the URL is fully qualified, it will typically contain a domain name, a file name for the content file, and an access method.
  • the client browser 12 then makes a request to discover the correct Internet Protocol (IP) address of the origin server 40 that contains the requested content file.
  • IP Internet Protocol
  • DNS Domain Name Service
  • the browser program When the DNS returns an IP address for the origin server 40, the browser program then attempts to open a connection to the origin server 40. If all goes according to design, the origin server 40 complies with the request and delivers the requested content file.
  • replica content servers 50 may contain replicas of one or more content files that originate at the origin server 40.
  • These content servers 50 which may typically include so called cache servers, can eliminate the need for the origin server 40 to deal with traffic demands.
  • Prior art schemes may typically require the reprogramming of name services to allow the browsers 12 to locate the content servers 50, such as by reprogramming one or more Domain Name Service (DNS).
  • DNS Domain Name Service
  • the present invention uses a particular addressing scheme to advertise the availability of alternative or replica name servers 53-1, 53-2, 53-3 for the domain located at the origin server 40.
  • the name servers 53-1, 53-2, 53-3 are peered with content file servers 51-1, 51-2, 51-3 that contain replica copies of files stored at the origin server 40.
  • the name servers 53 advertise themselves as reachable at an anycast address.
  • the internetwork 30 then itself becomes responsible for delivery of a domain name request message to a closest possible name server 53.
  • the closest name server 53 then responds to the anycast message by returning a unique IP address for its associated content server 51.
  • This scheme permits the browser to subsequently establish the higher level protocol access method, such as a Hyper Text Transfer Protocol (HTTP) request, to open a connection and deliver the content file.
  • HTTP Hyper Text Transfer Protocol
  • the browser is then subsequently redirected to the associated nearest cache server 50-1, 50-2, 50-3 that can honor the remaining expected HTTP request message sequence, without adding any unnecessary traffic to the associated domain name server 53 and/or paths in the internetwork 30 to the origin server 40.
  • the environment 10 consists of a client computing device, such as a computer 12, that is running a data file retrieval program such as a web browser.
  • the personal computer 12 is connected through an internetwork device 16-1 to a first network segment 14.
  • the internetwork device 16-1 may be any or any combination of modem, network interface card, router, switch, bridge, gateway, or the like.
  • the internetwork devices 16 provide the ability for connections to be made between various computing system elements using network infrastructure such as the internetwork structure 30, which may be a corporate intranet or the Internet.
  • the client computer 12 is connected to a local area network (LAN) 14 that consists of internetwork devices 16-3 and 16-4, which in this instance are routers.
  • LAN local area network
  • a local name service such as Domain Name Service (DNS) resolver 18, a local content host 21, and local content storage device 22 also form part of the LAN 14.
  • DNS Domain Name Service
  • the local content server 21 may be any type of well known host computer that is adapted for efficiently storing content files on a mass storage device 22. These content files may include web pages, multimedia files, graphics, pictures, other computer files that are suitable for network transmission using well know protocols such as the HyperText Transfer Protocol (HTTP).
  • HTTP HyperText Transfer Protocol
  • the client computer 12 may also make connections through the local area network 14 and router 16-3 to the Internet 30 to access files located at various other computing systems.
  • One of these computer systems may provide a service such as a root domain name service 38.
  • Other systems serve as the origin web server 40.
  • the origin server 40 is similar to the local host 20, in that it consists of a file server 41 and content storage 42 as well as an internetwork device 16-40.
  • the replica content servers 50-1, 50-2, 50-3 store replicas of one or more of the content files that originate at the origin server 40.
  • Each content server 50 consists therefore also of a file server 5 land associated mass storage device 52.
  • replicas of content files that originate at the origin server 40 are distributed and stored in the replica content servers 50.
  • Content files may be propagated through any number of schemes to push content out to various locations in the network 10 and/or move content closer to requesting client computers 12 upon demand. The connections to accomplish this are indicated by the dashed lines shown in Fig. 1. It should be understood that these are typical network connections between the origin server 40, and replica content servers 51-1, 51-2, 51-3; however, these connections are only shown here as logical connections from the perspective of the browser user client computer 12.
  • the name servers 53-1, 53-2, 53-3 are addressable via both a common anycast address as well as a unique or unicast address.
  • a DNS request may be sent to the name servers 53 as an anycast datagram.
  • the internetwork 30 is then responsible for providing best effort delivery of the datagram to at least one, and preferably the closest one, of the machines that accept messages for the anycast address.
  • the replica name servers 53 have received appropriate information from an authoritative DNS 45 for the domains in server 40.
  • Each name server 53 and file server 51 associated with particular content server 50 are considered to be connected in a peering arrangement. That is, they operate quite closely together and, in fact, are preferably located physically near one another, such as on a common local area network segment sharing the same internetwork device 16-50-1.
  • Each replica name server 53 therefore actually has two IP addresses, a common anycast address which is common to all of the replica name servers 53, as well as a unique unicast address which is specific to each name server 53.
  • Each name server 53 is considered to be an authoritative DNS resolver for domain names associated with the replica content files stored in its associated replica content server 51.
  • Fig. 2 in connection with Fig. 1.
  • users specify a Uniform Resource Locator (URL) to a browser program running on the client computer 12.
  • URL Uniform Resource Locator
  • the user may specify the URL http://www.example/homepage.html.
  • the browser program makes an initial attempt to resolve an address for the specified domain "example.com.” For example, the browser program issues a DNS request message as a UDP datagram to a name server. In the case where the user is associated with an Internet Service Provider (ISP) operating the local area network 20, this first name request is made to a local DNS resolver 18, to determine the location of the domain "example.com".
  • the DNS resolver 18 determines whether or not the requested content file is available locally. For example, it determines if "example.com" is located in the local web server 20. In other configurations, the resolver 18 may even reside at the client 12.
  • step 104 if the content is available locally, then the local IP address is returned to the browser program in step 106.
  • step 104 If however, in step 104, the domain "example.com" is not available locally, then the process proceeds to step 108.
  • a request to resolve the location ofexample.com is then sent to a root DNS server 38 in step 108.
  • the request to the root DNS server 38 will be recursively worked through multiple root servers associated with the Internet 30 (not shown in Fig. 1) to resolve the IP address for a DNS server authoritative for the requested domain name.
  • the root DNS name server 38 would then return the IP address of the DNS server that is authoritative for "example.com". In the illustrated embodiment, this may take the form for example, of the four-digit address 62.104.11.12 associated with a particular origin server 40.
  • the root DNS name server 38 has been programmed to instead return the anycast address 50.100.20.1.
  • the name servers 53-1, 53-2, 53-3 have been designated as being the authoritative name servers for "example.com" through previous network management level configuration information. This can be done, for example, by having the parent name server (i.e. the root name server) configured to list which name servers are configured as being authoritative for the "example.com” domain. This may also be intiated at certain times, such as when the content servers 51-1, 51- 2, 51-3 are populated with content file replicas from origin server 40.
  • the primary name service listed by organizations responsible for maintaining the state of internetwork 30, such as the Internic will point to this common address 50.100.20.1 of the caching servers 50, instead of the origin server 40.
  • step 112 now thinking that it has resolved the IP address for the single authoritative name server for "example.com", the browser then sends out a DNS request for the IP address of "www.example.com".
  • This request message is formulated as a UDP datagram specifying the common anycast address 50.100.20.1 returned in the previous step.
  • the domain name request is then sent as a UDP datagram to the anycast address.
  • the anycast datagram will reach one of the name servers 53-1, 53-2, and 53-3 in the group associated with IP address 50.100.20.1, the one reached first being the one closest to the requesting client 12 or DNS resolver 18.
  • the number of hops and hence the distance between the client 12 or DNS resolver 18 (in the case where the client 12 has a local resolver) and each particular one of the content servers 50 will be different.
  • the name server 53-1 may appear to be five hops away
  • the name server 53-2 may appear to be only one hop away
  • the name server 53-3 may appear to be twelve hops away.
  • the specific server 50 that will first return with a response will be the name server 53-3, as it is the closest in terms of network hops. This result is guaranteed, since every router 16 that is connected to a respective one of the content serves 50, and participates in the standard Internet routing protocols.
  • the name server 53 associated with this closest rate will then respond by reporting the unique EP address of its associated replica content server 51. This address is reported as a unicast address rather than an anycast address.
  • the browser program may now make an HTTP level request for the file "homepage.html" using the standard TCP TP and HTTP network protocols.
  • This final request message is sent using the unicast address for the content server 51.
  • the requested file is then returned from the content server 51-2 that is peered with the name server 53-2 that responded as being closest to the particular client 12 at the time the anycast message was sent.
  • the name servers 53 be machines that are physically separate from the content servers 51. Indeed, in a preferred embodiment, they are running typically on the same machine with the name server 53 being of one of the processes running on the content replica server 51.
  • an anycast message service can be built into the internetwork 30 any of a number of known ways.
  • An anycast message service is provided for by certain types of network protocols, such as IPv6. More commonly deployed protocols, such as IPv4, do not technically have direct support for anycast. However, such protocols can be used to create a network of service groups that each act autonomously to advertise themselves as "the" gateway into a group.
  • routing protocol may have profound effects on the propogation and convergence of group membership changes. "Membership" in the group is contigent upon distributed routing state. In the case of deployment within a single provider, where the anycast routing is internal to that network (and transparent to the outside - the Internet), and an internal routing protocol like iBGP or OSPF is used, progation of changes should be fast. In the case of deployment across multiple providers, full fledged external BGP ("eBGP”) preferably would be used.
  • eBGP full fledged external BGP
  • a network anycast service be provided in some way that at least permits datagrams to be sent to defined groups of machines, over the best advertised route to a destination address.
  • the anycast service however also preferably provides functionalities such as join, withdraw, failover/fallback, and overload. Each such function should perform as follows.
  • join routing advertisement Once a join (“begin routing advertisement”) happens, the service group begins to see requests. No convergence is needed, and as the route propagates, work can be directed at the service group.
  • the local routing neighbor would need to depend upon the timeout facilities of the routing protocol in order to discover the outage and force the route to be removed. During this time, clients attempting to contact the anycast address would not get a response ("black-hole").
  • Solutions to this problem include: a. provide redundancy in the service group, such that a name lookup to the anycast address returns two or more IP address in the service group. This gives the client another address to try if the content server fails. b. provide a shorter than normal TTL on the name ->local IP address mapping, such that the client is not able to cache the local IP address of a content server for an extended period of time.
  • Requests get delivered to the DNS server at the anycast address purely by the topological closeness of the requesting clients.
  • standard load balancing and replication techniques can also apply, such as multiple content servers (returning multiple local IP addresses to a name lookup), layer 4 switches, etc.
  • Multiple DNS servers within the group all listening to the anycast address would also be possible.
  • Load balancing across service groups requires an additional mechanism.
  • the DNS server in the service group can advertise a load metric to other service groups, and it can measure the load of the local content servers.
  • the routers 16-50 actually advertise the fact to the routers in 30 that they know how to locate the content at "example.com” in one hop. Although they are not actually networked in this way, they advertise the availability of such content, and therefore can be considered to fool the browser into believing that a network connection is available in one hop from each of the content servers 51 to "example.com", when in fact the distance may be many hops.
  • the initial anycast datagram may actually return two IP addresses for the group of content servers 50. These two addresses point to the same anycast group.
  • the content replicas stored by the replica content servers 51 need not have all of the particular objects for the web site that they replicate.

Abstract

La présente invention concerne une technique permettant de réacheminer les demandes de données client pour des fichiers de contenus à la réplique la plus proche du contenu demandé, en utilisant la messagerie Anycast. La demande de résoudre un nom de domaine est acheminée comme un message Anycast à un service de nom assuré par un groupe de serveurs de nom répartis dans le réseau. Le serveur de nom le plus proche répond au message Anycast en renvoyant une adresse réseau unique à un serveur de contenu associé contenant une réplique du fichier de contenu demandé. Ce schéma permet à un ordinateur client d'établir ultérieurement un procédé d'accès à protocole à niveau plus élevé, notamment une demande de protocole de transfert hypertexte (HTTP), pour ouvrir une connexion et présenter la réplique du fichier de contenu, à partir d'un serveur de contenu proche du client du point de vue topologique, uniquement par des protocoles de réseaux standards.
PCT/US2000/031990 1999-11-23 2000-11-21 Acheminement de demande optimal par exploitation d'informations topologiques de routeurs de paquets WO2001039470A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
AU17865/01A AU1786501A (en) 1999-11-23 2000-11-21 Optimal request routing by exploiting packet routers topology information
EP00980633A EP1236329A1 (fr) 1999-11-23 2000-11-21 Acheminement de demande optimal par exploitation d'informations topologiques de routeurs de paquets

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US09/ 1998-09-22
US16712399P 1999-11-23 1999-11-23
US60/167,123 1999-11-23

Publications (1)

Publication Number Publication Date
WO2001039470A1 true WO2001039470A1 (fr) 2001-05-31

Family

ID=22606032

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2000/031990 WO2001039470A1 (fr) 1999-11-23 2000-11-21 Acheminement de demande optimal par exploitation d'informations topologiques de routeurs de paquets

Country Status (3)

Country Link
EP (1) EP1236329A1 (fr)
AU (1) AU1786501A (fr)
WO (1) WO2001039470A1 (fr)

Cited By (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2003005246A2 (fr) * 2001-07-06 2003-01-16 Intel Corporation Procede et appareil de services de pairs
WO2003017615A1 (fr) * 2001-08-15 2003-02-27 Nokia Corporation Equilibrage de charge destine a une batterie de serveurs
US7546363B2 (en) 2001-07-06 2009-06-09 Intel Corporation Adaptive route determination for peer-to-peer services
WO2009086373A2 (fr) 2007-12-28 2009-07-09 Yahoo! Inc. Équilibrage de charge de trafic mondial sans carte par diffusion aléatoire
US7562112B2 (en) 2001-07-06 2009-07-14 Intel Corporation Method and apparatus for peer-to-peer services for efficient transfer of information between networks
US8214524B2 (en) 2007-12-21 2012-07-03 Hostway Corporation System and method for selecting an optimal authoritative name server
US9015324B2 (en) 2005-03-16 2015-04-21 Adaptive Computing Enterprises, Inc. System and method of brokering cloud computing resources
US9075657B2 (en) 2005-04-07 2015-07-07 Adaptive Computing Enterprises, Inc. On-demand access to compute resources
US9112813B2 (en) 2005-03-16 2015-08-18 Adaptive Computing Enterprises, Inc. On-demand compute environment
US9231886B2 (en) 2005-03-16 2016-01-05 Adaptive Computing Enterprises, Inc. Simple integration of an on-demand compute environment
US9467506B2 (en) 2014-01-27 2016-10-11 Google Inc. Anycast based, wide area distributed mapping and load balancing system
US11467883B2 (en) 2004-03-13 2022-10-11 Iii Holdings 12, Llc Co-allocating a reservation spanning different compute resources types
US11494235B2 (en) 2004-11-08 2022-11-08 Iii Holdings 12, Llc System and method of providing system jobs within a compute environment
US11522952B2 (en) 2007-09-24 2022-12-06 The Research Foundation For The State University Of New York Automatic clustering for self-organizing grids
US11526304B2 (en) 2009-10-30 2022-12-13 Iii Holdings 2, Llc Memcached server functionality in a cluster of data processing nodes
US11630704B2 (en) 2004-08-20 2023-04-18 Iii Holdings 12, Llc System and method for a workload management and scheduling module to manage access to a compute environment according to local and non-local user identity information
US11652706B2 (en) 2004-06-18 2023-05-16 Iii Holdings 12, Llc System and method for providing dynamic provisioning within a compute environment
US11650857B2 (en) 2006-03-16 2023-05-16 Iii Holdings 12, Llc System and method for managing a hybrid computer environment
US11720290B2 (en) 2009-10-30 2023-08-08 Iii Holdings 2, Llc Memcached server functionality in a cluster of data processing nodes
US11960937B2 (en) 2004-03-13 2024-04-16 Iii Holdings 12, Llc System and method for an optimizing reservation in time of compute resources based on prioritization function and reservation policy parameter

Non-Patent Citations (4)

* Cited by examiner, † Cited by third party
Title
BHATTACHARJEE, S.; AMMAR, M.H.; ZEGURA, ELLEN; ZONGMING FEI: "Application-Layer Anycasting", IEEE INFOCOM 1997, vol. 3, 7 April 1997 (1997-04-07) - 11 April 1997 (1997-04-11), pages 1388 - 1396, XP002163033, ISBN: 0-8186-7780-5, Retrieved from the Internet <URL:http://www.ieee.org> [retrieved on 20010316] *
COLAJANNI M ET AL: "ADAPTIVE TTL SCHEMES FOR LOAD BALANCING OF DISTRIBUTED WEB SERVERS", PERFORMANCE EVALUATION REVIEW,ASSOCIATION FOR COMPUTING MACHINERY, NEW YORK, NY,US, vol. 25, no. 2, 1 September 1997 (1997-09-01), pages 36 - 42, XP000199853, ISSN: 0163-5999 *
KATZ E D ET AL: "A scalable HTTP server: The NCSA prototype", COMPUTER NETWORKS AND ISDN SYSTEMS,NORTH HOLLAND PUBLISHING. AMSTERDAM,NL, vol. 27, no. 2, 1 November 1994 (1994-11-01), pages 155 - 164, XP004037986, ISSN: 0169-7552 *
PARTIDGE C.; MENDEZ T.; MILLIKEN W.: "Host Anycasting Service", REQUEST FOR COMMENTS (RFC), November 1993 (1993-11-01), Internet Engineering Task Force (IETF), pages 1 - 9, XP002163034, Retrieved from the Internet <URL:http://www.ietf.org> [retrieved on 20010316] *

Cited By (46)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7921155B2 (en) 2001-07-06 2011-04-05 Intel Corporation Method and apparatus for peer-to-peer services
WO2003005246A3 (fr) * 2001-07-06 2003-08-21 Intel Corp Procede et appareil de services de pairs
WO2003005246A2 (fr) * 2001-07-06 2003-01-16 Intel Corporation Procede et appareil de services de pairs
US7440994B2 (en) 2001-07-06 2008-10-21 Intel Corporation Method and apparatus for peer-to-peer services to shift network traffic to allow for an efficient transfer of information between devices via prioritized list
US7499981B2 (en) 2001-07-06 2009-03-03 Intel Corporation Methods and apparatus for peer-to-peer services
US7546363B2 (en) 2001-07-06 2009-06-09 Intel Corporation Adaptive route determination for peer-to-peer services
US7562112B2 (en) 2001-07-06 2009-07-14 Intel Corporation Method and apparatus for peer-to-peer services for efficient transfer of information between networks
WO2003017615A1 (fr) * 2001-08-15 2003-02-27 Nokia Corporation Equilibrage de charge destine a une batterie de serveurs
US7644159B2 (en) 2001-08-15 2010-01-05 Nokia Corporation Load balancing for a server farm
US11960937B2 (en) 2004-03-13 2024-04-16 Iii Holdings 12, Llc System and method for an optimizing reservation in time of compute resources based on prioritization function and reservation policy parameter
US11467883B2 (en) 2004-03-13 2022-10-11 Iii Holdings 12, Llc Co-allocating a reservation spanning different compute resources types
US11652706B2 (en) 2004-06-18 2023-05-16 Iii Holdings 12, Llc System and method for providing dynamic provisioning within a compute environment
US11630704B2 (en) 2004-08-20 2023-04-18 Iii Holdings 12, Llc System and method for a workload management and scheduling module to manage access to a compute environment according to local and non-local user identity information
US11886915B2 (en) 2004-11-08 2024-01-30 Iii Holdings 12, Llc System and method of providing system jobs within a compute environment
US11861404B2 (en) 2004-11-08 2024-01-02 Iii Holdings 12, Llc System and method of providing system jobs within a compute environment
US11762694B2 (en) 2004-11-08 2023-09-19 Iii Holdings 12, Llc System and method of providing system jobs within a compute environment
US11709709B2 (en) 2004-11-08 2023-07-25 Iii Holdings 12, Llc System and method of providing system jobs within a compute environment
US11656907B2 (en) 2004-11-08 2023-05-23 Iii Holdings 12, Llc System and method of providing system jobs within a compute environment
US11537434B2 (en) 2004-11-08 2022-12-27 Iii Holdings 12, Llc System and method of providing system jobs within a compute environment
US11537435B2 (en) 2004-11-08 2022-12-27 Iii Holdings 12, Llc System and method of providing system jobs within a compute environment
US11494235B2 (en) 2004-11-08 2022-11-08 Iii Holdings 12, Llc System and method of providing system jobs within a compute environment
US11134022B2 (en) 2005-03-16 2021-09-28 Iii Holdings 12, Llc Simple integration of an on-demand compute environment
US9231886B2 (en) 2005-03-16 2016-01-05 Adaptive Computing Enterprises, Inc. Simple integration of an on-demand compute environment
US11356385B2 (en) 2005-03-16 2022-06-07 Iii Holdings 12, Llc On-demand compute environment
US10608949B2 (en) 2005-03-16 2020-03-31 Iii Holdings 12, Llc Simple integration of an on-demand compute environment
US10333862B2 (en) 2005-03-16 2019-06-25 Iii Holdings 12, Llc Reserving resources in an on-demand compute environment
US9015324B2 (en) 2005-03-16 2015-04-21 Adaptive Computing Enterprises, Inc. System and method of brokering cloud computing resources
US11658916B2 (en) 2005-03-16 2023-05-23 Iii Holdings 12, Llc Simple integration of an on-demand compute environment
US9112813B2 (en) 2005-03-16 2015-08-18 Adaptive Computing Enterprises, Inc. On-demand compute environment
US11765101B2 (en) 2005-04-07 2023-09-19 Iii Holdings 12, Llc On-demand access to compute resources
US11831564B2 (en) 2005-04-07 2023-11-28 Iii Holdings 12, Llc On-demand access to compute resources
US10277531B2 (en) 2005-04-07 2019-04-30 Iii Holdings 2, Llc On-demand access to compute resources
US11533274B2 (en) 2005-04-07 2022-12-20 Iii Holdings 12, Llc On-demand access to compute resources
US10986037B2 (en) 2005-04-07 2021-04-20 Iii Holdings 12, Llc On-demand access to compute resources
US11496415B2 (en) 2005-04-07 2022-11-08 Iii Holdings 12, Llc On-demand access to compute resources
US11522811B2 (en) 2005-04-07 2022-12-06 Iii Holdings 12, Llc On-demand access to compute resources
US9075657B2 (en) 2005-04-07 2015-07-07 Adaptive Computing Enterprises, Inc. On-demand access to compute resources
US11650857B2 (en) 2006-03-16 2023-05-16 Iii Holdings 12, Llc System and method for managing a hybrid computer environment
US11522952B2 (en) 2007-09-24 2022-12-06 The Research Foundation For The State University Of New York Automatic clustering for self-organizing grids
US8214524B2 (en) 2007-12-21 2012-07-03 Hostway Corporation System and method for selecting an optimal authoritative name server
EP2235885A4 (fr) * 2007-12-28 2013-05-29 Yahoo Inc Équilibrage de charge de trafic mondial sans carte par diffusion aléatoire
EP2235885A2 (fr) * 2007-12-28 2010-10-06 Yahoo! Inc. Équilibrage de charge de trafic mondial sans carte par diffusion aléatoire
WO2009086373A2 (fr) 2007-12-28 2009-07-09 Yahoo! Inc. Équilibrage de charge de trafic mondial sans carte par diffusion aléatoire
US11720290B2 (en) 2009-10-30 2023-08-08 Iii Holdings 2, Llc Memcached server functionality in a cluster of data processing nodes
US11526304B2 (en) 2009-10-30 2022-12-13 Iii Holdings 2, Llc Memcached server functionality in a cluster of data processing nodes
US9467506B2 (en) 2014-01-27 2016-10-11 Google Inc. Anycast based, wide area distributed mapping and load balancing system

Also Published As

Publication number Publication date
AU1786501A (en) 2001-06-04
EP1236329A1 (fr) 2002-09-04

Similar Documents

Publication Publication Date Title
US10476984B2 (en) Content request routing and load balancing for content distribution networks
WO2001039470A1 (fr) Acheminement de demande optimal par exploitation d&#39;informations topologiques de routeurs de paquets
US6901445B2 (en) Proximity-based redirection system for robust and scalable service-node location in an internetwork
Ballani et al. Towards a global IP anycast service
Stoica et al. Internet indirection infrastructure
US7908337B2 (en) System and method for using network layer uniform resource locator routing to locate the closest server carrying specific content
US7725596B2 (en) System and method for resolving network layer anycast addresses to network layer unicast addresses
US6182224B1 (en) Enhanced network services using a subnetwork of communicating processors
US20020007413A1 (en) System and method for using a mapping between client addresses and addresses of caches to support content delivery
US9154571B2 (en) Publish/subscribe networks
EP1433077B1 (fr) Systeme et procede d&#39;orientation de clients vers des serveurs optimaux dans des reseaux informatiques
EP2708011B1 (fr) Système et procédé d&#39;interconnexion de réseaux de distribution de contenus
EP1277327B1 (fr) Systeme et procede d&#39;utilisation d&#39;un localisateur de ressources universel dans des couches de reseau pour localiser le serveur le plus proche renfermant un contenu specifique
Ferreira et al. An IP address based caching scheme for peer-to-peer networks
Cojocar BBUFs: A new lookup mechanism based on IPV6
Qiu et al. A new Content Distribution Network architecture-Plenty-Cast
Garcia-Luna-Aceves System and Method forInformation Object Routing in Computer Networks
Garcia-Luna-Aceves System and Method for Discovering Information Objects and Information Object Repositories in Computer Networks
Peruru CHOReLLA±A Reliable and Scalable Addressing Scheme for Data Distribution
Cao A new Content Distribution Network architecture-PlentyCast
WO2001084802A2 (fr) Systeme et procede comprenant l&#39;utilisation de localisateurs de ressources universels pour mapper les noms de contenus de la couche application sur les adresses anycast de la couche reseau
Gupta et al. Large-scale reliable multicast of small messages
WO2001084803A2 (fr) Systeme et procede pour la transformation d&#39;adresses anycast de couche reseau en adresses unicast
Szymaniak et al. NetAirt: A Flexible Redirection System for Apache

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CR CU CZ DE DK DM DZ EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
WWE Wipo information: entry into national phase

Ref document number: 2000980633

Country of ref document: EP

WWP Wipo information: published in national office

Ref document number: 2000980633

Country of ref document: EP

REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

WWW Wipo information: withdrawn in national office

Ref document number: 2000980633

Country of ref document: EP

DPE2 Request for preliminary examination filed before expiration of 19th month from priority date (pct application filed from 20040101)