(19)
&
(11)
EP 1 687 951 B1
EUROPEAN PATENT SPECIFICATION
(12)
(45) Date of publication and mention
(51) Int Cl.:
H04L 29/06 (2006.01)
of the grant of the patent:
24.08.2011 Bulletin 2011/34
H04L 29/12 (2006.01)
(86) International application number:
PCT/US2004/029798
(21) Application number: 04783854.5
(87) International publication number:
(22) Date of filing: 10.09.2004
WO 2005/046174 (19.05.2005 Gazette 2005/20)
(54) METHOD FOR COMMUNICATING OVER THE INTERNET WITH GEOGRAPHICALLY
DISTRIBUTED DEVICES
VERFAHREN ZUM KOMMUNIZIEREN ÜBER DAS INTERNET MIT GEOGRAPHISCH VERTEILTEN
EINRICHTUNGEN
PROCEDE POUR COMMUNIQUER SUR L’INTERNET AVEC DES DISPOSITIFS REPARTIS
GEOGRAPHIQUEMENT
(56) References cited:
(84) Designated Contracting States:
AT BE BG CH CY CZ DE DK EE ES FI FR GB GR
HU IE IT LI LU MC NL PL PT RO SE SI SK TR
US-A1- 2002 141 387
• DIAS D M ET AL: "A scalable and highly available
web server" 25 February 1996 (1996-02-25),
DIGEST OF PAPERS OF COMPCON (COMPUTER
SOCIETY CONFERENCE) 1996 TECHNOLOGIES
FOR THE INFORMATION SUPERHIGHWAY.
SANTA CLARA, FEB. 25 - 28, 1996, DIGEST OF
PAPERS OF THE COMPUTER SOCIETY
COMPUTER CONFERENCE COMPCON, LOS
ALAMITOS, IEEE COMP. SOC. PRESS, ,
XP010160879 ISBN: 0-8186-7414-8 page 87, lefthand column, line 11 - right-hand column, line 27
• SCHROEDER T ET AL: "SCALABLE WEB
SERVER CLUSTERING TECHNOLOGIES" IEEE
NETWORK, IEEE INC. NEW YORK, US, vol. 14, no.
3, May 2000 (2000-05), pages 38-45, XP001195395
ISSN: 0890-8044
(30) Priority: 27.10.2003 US 514672 P
16.06.2004 US 869208
(43) Date of publication of application:
09.08.2006 Bulletin 2006/32
(73) Proprietor: Rovi Solutions Corporation
Santa Clara, CA 95050 (US)
(72) Inventors:
• LEVIN, Steven, L.
Sunnyvale, CA 94086 (US)
• DISHER, Jonathan
Sunnyvale, CA 94086 (US)
(74) Representative: Beresford, Keith Denis Lewis
EP 1 687 951 B1
Beresford & Co.
16 High Holborn
London
WC1V 6BX (GB)
Note: Within nine months of the publication of the mention of the grant of the European patent in the European Patent
Bulletin, any person may give notice to the European Patent Office of opposition to that patent, in accordance with the
Implementing Regulations. Notice of opposition shall not be deemed to have been filed until the opposition fee has been
paid. (Art. 99(1) European Patent Convention).
Printed by Jouve, 75001 PARIS (FR)
1
EP 1 687 951 B1
Description
FIELD OF THE INVENTION
[0001] The present invention generally relates to communicating with devices of a decentralized network and
in particular, to a system and methods for communicating
over the Internet with geographically distributed devices
of a decentralized network using transparent asymmetric
return paths.
5
10
BACKGROUND OF THE INVENTION
[0002] A decentralized network such as peer-to-peer
file sharing networks employing the Internet may connect
millions of devices around the world together for the sharing of information. A system that monitors certain aspects
of such sharing should have a global presence that covers the geographical span of the decentralized network.
[0003] Because of the way most peer-to-peer networks function, efficiently of operation is best achieved
by the system having a presence on globally diverse networks, especially in major metropolitan areas where
there is a significant broadband penetration. This
presents a system architecture problem, however, where
a lean system is desired that is relatively cheap to implement and easy to maintain.
[0004] Traditional methods of structuring such a system involve either the deployment of large numbers of
expensive clusters, or backhauling expensive data circuits from many global points of presence back to a central datacenter. Each of these methods, however, is very
costly.
[0005] In particular, the deployment of many clusters
of machines in many locations around the world on diverse networks is extremely expensive to implement, difficult to manage, and highly inefficient. It also does not
scale well since a lack of resources in one point of presence cannot easily be compensated for with a glut of
resources in another location.
[0006] A backhauled data circuit, on the other hand,
that is deployed to peer with many networks on a global
scale is usually even more cost prohibitive since routers
and long-haul circuits are expensive, and peering arrangements generally take large amounts of time and
money to complete.
[0007] In addition, in monitoring the information sharing activity in a decentralized network, it may be useful
for a system to include agents to masquerade as one or
more devices in the decentralized network. In such a system, communications with the devices should use either
a symmetric return path (i.e., the agent receiving the original communication from a device returns any reply generated by a centralized data center back to the device)
or use a transparent asymmetric return path (i.e., the
centralized data center returns the reply to the device
directly, but in such a fashion that it appears to the device
that the reply is being sent by the agent) in order to main-
15
20
25
30
35
40
45
50
55
2
2
tain the agent’s masquerade.
As an example of a symmetric return path, "Impact of the
Evolution of the Metropolitan Network on the DSL Access
Architecture", 2003 IEEE, describes an ATM access network in which DSL access multiplexers (DSLAMS) connect customer premises equipment (CPE) to a broadband access server (BAS) through virtual circuits.
[0008] Dias, D.M. et al., "A Scalable and Highly Available web Server," 25 February 1996 (1996-02-25), Digest of Papers of COMPCON (Computer Society Conference) 1996 Technologies of the Information Superhighway, Santa Clara, Feb. 25-28, 1996, Digest of Papers of the Computer Society Computer Conference
COMPCON, Los Alamitos, IEEE Comp. Soc. Press,
XXP010160879 ISBN: 0-8186-7414-8, describes a scalable web server which provides load balancing by routing
packets received by a TCP router from a client to a different front-end web server nodes in a round-robin order.
The server nodes directly send the request back to the
client without using the router. However, the server nodes
change the source address on the packets sent back to
the client to be that of the router node. This makes the
entire routing action transparent to the clients.
[0009] Although Dias uses transparent asymmetric return paths, it also uses a cluster approach wherein the
TCP router and front-end web server nodes are part of
a same cluster. Thus, it is not resource efficient for the
present application of monitoring certain aspects of file
sharing activities in a decentralized network having a global presence. Also, it does not efficiently handle continued transmissions in the event of a line bounce. Because
of the load balancing between multiple web server nodes,
transmissions cannot continue from where it left off prior
to the line bounce, requiring the transmission to restart
from the beginning.
Aspects of the present invention are set out in the appended independent claims.
An embodiment comprises a method for communicating
with devices in a decentralised network, comprising: receiving a packet in a point of presence from a device;
routing the packet according to a virtual circuit from the
point of presence to an application computer of a centralised data center, wherein the virtual circuit is defined
such that subsequently received packets in the point of
presence from the device are also routed according to
the virtual circuit from the point of presence to the application computer; generating a reply packet by the application computer processing information in the packet;
and transmitting the reply packet back to the device from
the application computer in such a fashion that it appears
to the device that the reply packet is being sent by the
point of presence.
[0010] Features and advantages of the embodiments
of the present invention will become apparent from the
following description of its preferred embodiment, which
description should be taken in conjunction with the accompanying drawings.
3
EP 1 687 951 B1
BRIEF DESCRIPTION OF THE DRAWING
[0011] FIG. 1 illustrates a block diagram of a system
for communicating with devices of a decentralized network organized into geographical regions, according to
an embodiment of the present invention.
[0012] FIG. 2 illustrates a block diagram detailing a
portion of the system for communicating with devices of
one geographical region of the decentralized network,
according to an embodiment of the present invention.
[0013] FIG. 3 illustrates a flow diagram of a.method for
activating a virtual circuit, according to an embodiment
of the present invention.
[0014] FIG- 4 illustrates a flow diagram of a method
for releasing an active virtual circuits, according to an
embodiment of the present invention.
[0015] FIG. 5 illustrates a flow diagram of a first method
for transmitting information to set-up a virtual circuit, according to an embodiment of the present invention.
[0016] FIG. 6 illustrates a flow diagram of a method for
communicating over the Internet with devices of a decentralized network, corresponding Lo the virtual circuit
set-up described in FIG. 5 and according to an embodiment of the present invention.
[0017] FIG. 7 illustrates a flow diagram of a second
method for transmitting information to set-up a virtual circuit, according to an embodiment of the present invention.
[0018] FIG. 8 illustrates a flow diagram of a method for
communicating over the Internet with devices of a decentralized network, corresponding to the virtual circuit
set-up described in FIG. 7 and according to an embodiment of the present invention.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT
[0019] FIG. 1 illustrates, as an example, a block diagram of a system 100 configured to implement the various methods described herein that are applicable to communicating over the Internet with devices of a decentralized network over the Internet. The system 100 includes
a centralized data center 101 and a plurality of remote
capture centers such at 111∼113 that are geographically
distributed so as to receive communications from devices
in their respective geographical regions. Each remote
capture center may be thought of in this case as a conventional point of presence ("POP") that provides an access point to the Internet.
[0020] In the example, the locations of the devices are
organized into three geographical regions according to
their IP addresses. In a first geographical region 120, a
first remote capture center 111 is physically located so
as to receive packets of information from a number of
devises such as computers 121∼123. Likewise, in a second geographical region 130, a second remote capture
center 112 is physically located so as to receive packets
of information from a number of devices such as com-
5
10
15
20
25
30
35
40
45
50
55
3
4
puters 131∼133. Finally, in a third geographical region
140, a third remote capture center 113 is physically located so as to receive packets of information from a
number of devices such as computers 141∼143. In an
actual implementation, additional remote capture centers
may be deployed to cover additional geographical regions so as to provide a truly global presence for the
system.
[0021] The remote capture centers send their received
packets of information over the Internet to the centralized
data center 101 for processing. The transmission may
be over the public Internet or a Virtual Primate Network
("VPN") . In either case, since the Internet is used instead
of routers and a leased line, high costs associated with
a backhauled data circuit are avoided. Also, since the
processing of packets is performed at the centralized data center 101 instead of the remote capture centers, this
makes the system 100 relatively inexpensive to implement since it only requires deployment of a few relatively
cheap and less powerful machines in each of the remote
capture centers (usually 3 or 4 per POP).
[0022] The system 100 is also scaleable and relatively
more efficient to manage since processing can be easily
distributed between computation machines in the centralized data center 101 to balance their work loads. Further, resources can be added when overall system demands require it at one location (i.e., the centralized data
center 101) rather than at many distant locations (i.e.,
the remote capture centers) where they may wind up
being under or over utilized. Thus, the system 100 avoids
the drawbacks associated with an approach that deploys
many clusters of machines around the world without central processing.
[0023] After processing the packets, the centralized
data center 101 transmits reply packets back to the devices directly rather than sending them back through the
original routes from which they came. Thus, asymmetric
return path are used in the system 100 to avoid burdening
the remote capture centers with a relay function and to
save reply packet transit time. Since the devices receiving the reply packets expect the reply packets to come
from the destination IP addresses to which the original
packets were sent, the centralized data center 101 transmits these packets back to the devices in such a manner
that the reply packets appear to have come from their
respective destination IP addresses, thereby making the
asymmetric return paths transparent to these devices.
[0024] Thus, the system 100 transparently intercepts
and transits unidirectional or bidirectional streams of data
from one location to another with an asymmetric return
path. Its primary function is to allow a broad geographic
presence without deploying a large infrastructure in multiple remote locations around the globe. A secondary
benefit of the system 100 is its ability to masquerade it’s
processing and transmission location securely behind
the identity of the remote endpoint (i.e., an IP address
associate with one of its remote capture centers).
[0025] FIG. 2 illustrates, as an example, a block dia-
5
EP 1 687 951 B1
gram including a portion of the system 100 for communicating with device such as computer 121 in tne first
geographical region 120. In the example, multiple DSL
lines such as 201∼203 are brought in, usually using Pointto-Point Protocol over Ethernet ("PPPoE") as a transport,
from multiple DSL service providers (such as Speakeasy,
EarthLink, Covad, SBC, BT, Telewest, NTL, SingTel or
Telestra) to their respective DSL modems such as
211∼213 in the remote capture center 111. This arrangement provides TP address diversity while at the same
time allows realistic simulation of an average device in a
decentralized network of interest. Although the use of
DSL is shown throughout this example, other mediums
such as T1, ISDN, cable modem, Ethernet handoff, and
even dial-up may also be used.
[0026] The DSL moderns are connected over Ethernet
214 (e.g., 100BaseTX) to an aggregator computer 210,
which is also in the remote capture center 111. Although
only one such aggregator is shown in this example, in
practise, multiple aggregators may be used in each remote capture center. The aggregators may typically have
no more than 8 or 9 DSL modems connected to them
(using quad-port PCI Ethernet network interface cards
for port density) - Due to the nature of PPPoE, the DSL
modems are preferably connected to the Ethernet ports
on the aggregator 210, not aggregated by a switch.
[0027] The aggregator computer 210 takes each incoming packet off Ethernet 214 and its packet filter rewrites a destination address in the packet from an original
destination address associated with the remote capture
center 111 to an address associated with the centralized
data center 101 according to re-write rules previously
provided to the aggregator 210 as part of setting up a
virtual circuit between the aggregator computer 210 and
an application computer in the centralized data center
101 which is to process the packet. The original destination address in this case is the IP address of the DSL
modem that received the packet, which is typically provided by the DSL service provider.
[0028] The header of an IP packet conventionally includes both a source IP address indicating where the
packet originated from (i.e., the sending node), and a
destination IP address indicating where the packet is to
go (i.e., the receiving node). A header checksum is also
included to ensure IP header integrity. When replacing
the original destination address with the aliased address,
the checksum may also be changed accordingly to maintain header integrity.
[0029] After rewriting the destination address indicated
in the packet, the packet is passed to the kernel of the
aggregator computer 210 which determines that the destination address is not a local address so it routes the
packet over a VPN tunnel 220 (using IPSEC or PPTP)
to the demux computer 240 in the centralized data center
101 according to a static route defined in a routing table
of the aggregator computer 210 at the time that the virtual
circuit was set-up. In this case, the address associated
with the demux computer 240 is a private range address,
5
10
15
20
25
30
35
40
45
50
55
4
6
such as an aliased address dedicated to the virtual circuit.
Although use of a VPN tunnel is preferred for security
reasons, communications can also be performed by the
aggregator computer 210 routing the packet over the
public Internet without a VPN tunnel to a public range
address on the demux computer 240.
[0030] After receiving the packet, a packet filter of the
demux computer 240 rewrites the destination address
from the address associated with the demux computer
240 to an address associated with the application computer which is to process the packet, according to rewrite rules previously provided to the demux computer
240 as part of setting up the virtual circuit. The packet is
then passed to the kernel of the demux computer 240,
which determines that the destination address is not a
local address so it routes the packet over Ethernet 250
to the application computer that is to process the packet,
using another static route defined in a routing table of the
demux computer 240 at time that the virtual circuit was
set up. The application computer in this case has a resident application program which has initiated the virtual
circuit and will process the packet.
[0031] Once the packet is passed to the application
computer, its kernel determines that the destination address matches a local address, and passes the packet
to the application program which is to process the packet.
The application program in this case is the one that originally requested that the virtual circuit be set up, and the
kernel recognizes that application program, because it
is bound to the address currently in the destination address of the packet and to the proper port of the application computer.
[0032] After processing the packet to generate a reply
packet, the application program sends the reply packet
out the application computer’s public IP interface or default gateway (using, for example, a Gig-E or OC-48 uplink) back to the device that originally sent the packet to
the remote capture center 111. The reply packet received
by the device will have the source IP address in the originally received packet (i.e., the IP address of the computer 121 which originally sent the packet) as its destination
IP address, and the destination IP address in the originally received packet (i.e., the IP address of the receiving
DSL modem) as its source IP address. Thus, the reply
packet is returned using a transparent asymmetric return
path.
[0033] A key part of the system 100 is an automatic
circuit management function performed by an administrative node 230, which is also referred to herein as the
circuit keeper. The circuit keeper 230 maintains a list of
active virtual circuits (i.e., virtual circuits that are currently
in use) and a list of available virtual circuits (i.e., virtual
circuits that are currently available to be assigned for
use). Each virtual circuit defines a path of transmission
for a packet, starting with a computer in the remote capture center that is to receive packets from devices in a
decentralized network, and ending with an application
computer that is to process the packet.
7
EP 1 687 951 B1
[0034] The circuit keeper computer 230 includes automated administration tools, which are responsible for
building up and tearing down transit connections from
end to end on a dynamic basis. Since DSI, is not as reliable as the carrier class connectivity solutions (such as
T1), it is not unusual for a virtual circuit connection to
bounce up and down in a relatively short period of time.
Therefore, the automated administration tools are able
to automate the process of connecting to the DSL provider, authenticating, getting an IP address, setting up
the end-to-end rewrite rules and static routes on computers associated with the virtual circuit, and monitoring link
availability- To do so, the automated administration tools
are configured to bring up DSL connections on the aggregator computer 210, maintain tables of available and
active virtual circuits, IP addresses and rewrite rules, and
pass virtual circuit set-up information on to computers
associated with the virtual circuit.
[0035] FIG. 3 illustrates, as an example, a flow diagram
of a method for activating a virtual circuit that facilitates
setting up various static routes and re-write rules on computers associated with the virtual circuit. In 301, the circuit
keeper computer 230 receives a request to activate an
available virtual circuit. The request in this case commonly comes from an application program acting as an agent
that will process incoming packets through a designated
modem or remote capture center. In 302, if the virtual
circuit is available (i.e., not currently being used), then
the circuit keeper computer 230 activates the virtual circuit and updates the active and available virtual circuit
lists accordingly.
[0036] As previously described, the virtual circuit defines a path of transit for the packet, which is preferably
specified in the form of static routes. In 303, the circuit
keeper 230 transmits information to computers associated with the virtual circuit to set up the virtual circuit. The
specific information transmitted and the recipients of that
information depend upon the method being used to communicate with devices of a decentralized network using
transparent asymmetric return paths. As will be described below, an example of one such method is described in reference to FIGS. 5 and 6, and an example
of another such method is described in reference to
FIGS. 7 and 8.
[0037] In 304, a determination is made whether or not
the virtual circuit has bounced (i.e., the DSL link has been
dropped or lost). As long as the virtual circuit has not
bounced or been released, then no action with respect
to the virtual circuit is made by the circuit keeper computer
230.
On the other hand, if the virtual circuit is detected to have
been bounced, then the circuit keeper computer 230 proceeds back to 302 to activate another available virtual
circuit to take the bounced circuit’s place, and update the
active and available virtual circuit lists accordingly. The
circuit keeper computer 230 then sets up the new virtual
circuit by performing 303 again, and checks for another
circuit bounce by performing 304 again.
5
10
15
20
25
30
35
40
45
50
55
5
8
[0038] FIG. 4 illustrates, as an example, a flow diagram
of a method for releasing an active virtual circuit. The
method in this case comprises essentially reverse actions of those taken in activating and setting up the virtual
circuit. In 401, the circuit keeper computer 230 receives
a virtual circuit release request. In 402, it transmits information and/or instructions to tear down the virtual circuit
by removing, for example, all static routes and re-write
rules previously provided to computers associated with
the virtual circuit. In 403, the circuit keeper computer 230
then updates the virtual circuit lists by removing the virtual
circuit from the active circuits list and re-entering it in the
available circuits list.
[0039] FIG. 5 illustrates a flow diagram of a first method
for transmitting information to set-up a virtual circuit to
perform 303 of FIG. 3. Note that the following tasks may
be handled in the order shown in FIG. 5 or in another
order. Also, some or all of the tasks may be performed
around the same time so as to be performed substantially
concurrently.
[0040] In 501, the circuit keeper computer 230 sends
information to the aggregator computer 210 to update its
routing table to include a static route so that packets addressed to an address associated with the demux computer 240 are sent to the demux computer 240. As previously described, the address in this case may be an
aliased address assigned to the virtual circuit if communications to the demux computer 240 are to be sent over
the VPN tunnel 220, or it may be a public IP address if
communications to the demux computer 240 are to be
sent over the public Internet.
[0041] In 502, the circuit keeper computer 230 also
sends information to the aggregator computer 210 to update its iptables so that packets having a certain destination address associated with the aggregator computer
210 (such as the IP address assigned to one its DSL
modems) is re-written from the original destination address to the address associated with the demux computer 240.
[0042] In a similar manner, in 503, the circuit keeper
computer 230 sends information to the demux computer
240 to update its routing table to include a static route so
that packets addressed to an address associated with
the application computer associated with the virtual circuit are sent to that application computer. The address
in this case is the original destination address.
[0043] In 504, the circuit keeper computer 230 also
sends re-write information to the demux computer 240
to update its iptables so that packets having the address
associated with the demux computer 240 as their destination address are re-written back to the original destination address.
[0044] In 505, an application program residing on the
application computer that is associated with the virtual
circuit assigns the original destination address as an alias
to the loopback interface of the application computer,
modifies the routing table of the application computer to
include to the aliased address, and binds itself to the
9
EP 1 687 951 B1
original destination address and a port of the application
computer that is reserved for its use. Consequently, when
the application computer receives a packet with the original destination address (i.e., the IP address assigned to
a DSL modem of the aggregator computer 210) indicated
as its destination address, the kernel of the application
computer recognizes that the packet is to be processed
locally and passes the packet to the application program
that is bound to that original destination address and the
previously assigned port.
[0045] In order to tear down this virtual circuit, not only
are the routing tables and iptables of the aggregator computer 210 and the demux computer 240 placed back into
their original form (i.e., before adding the static routes
and re-write rules described in reference to FIG. 5), the
application computer is also instructed to delete the original destination address alias to its loopback interface,
and release the application program so that it is no longer
bound to the original destination address and assigned
port.
[0046] FIG. 6 illustrates, as an example, a flow diagram
of a method for communicating over the Internet with
devices in a decentralized network that corresponds to
the virtual circuit set-up described in reference to FIG. 5.
In 601, an IP packet is received at the aggregator computer 210 through its DSL modem 211 from a remote
user of client computer 121. The remote user in this example is physically located in Kansas with an IP address
of 1.1.1.1, and the aggregator computer 210 and its DSL
modem 211 are physically located in Colorado with an
IP address of 2.2.2.2 assigned to the DSL modem 211
by its ISP. Therefore, at this time, the IP packet has a
source IP address of 1.1.1.1 and a destination IP address
of 2.2.2.2.
[0047] In 602, before passing the packet to its kernel,
the packet header is modified by using the kernel-level
packet filter and mangling system iptables of the aggregator computer 210 so that the destination address is
rewritten in the IP packet to 172.16.0.3, which is an aliased address assigned during virtual circuit set-up to
point to the demux computer 240.
[0048] In 603, the packet is then passed to the kernel
ot the aggregator computer 210 which looks at the source
and destination IP addresses indicated in the packet. The
kernel, finding that the destination address is not a local
address, but one that is in its routing table, passes the
packet over the inter-site VPN tunnel 220 to the demux
computer 240. At this point, the IP packet has a source
IP address of 1.1.1.1 and a destination IP address of
172.16.0.3.
[0049] In 604, the packet is received at the demux computer 240, and in 605, its destination IP address is again
re-written, this time back to the original destination IP
address 2.2.2.2. After the destination IP address is rewritten in the packet, the packet is passed to the kernel
of the demux computer 240. The kernel sees that the
destination address of the packet is not a local address,
but one that is in its routing table,, so in 606, it routes the
5
10
15
20
25
30
35
40
45
50
55
6
10
packet over Ethernet 250 to the application computer
261 that is to process the packet. At this point, the IP
packet has its original source IP address of 1.1.1.1 and
original destination IP address of 2.2.2.2.
[0050] In 607, the application computer receives the
incoming packet from the demux computer 240, and its
kernel discovers that the packet has a destination IP address that is a local address defined in its routing table
as an alias to the loopback interface, and therefore, in
608, it delivers the packet to an application program that
resides on the application computer and is bound to the
original destination IP address and the correct port. In
609, the application program then processes the packet,
and generates a reply packet if appropriate. In 610, the
reply packet is then sent back out through the default
gateway of the application computer to remote user in
Kansas by the kernel of the application computer. The
reply packet at this time has a source IP address of
2.2.2.2 and destination IP address of 1.1.1.1, so that it
appears that the reply packet is being sent from the DSL
model 211 that originally received the packet.
[0051] FIG. 7 illustrates a flow diagram of a second
and preferred method for transmitting information to setup a virtual circuit to perform 303 of FIG. 3. One advantage of this method is that it allows the use of the same
remote IP address on multiple application computers by
including a destination port indication along with the destination address. This is particularly useful where computational sources are at a premium, and bandwidth is
available. In the method described in FIG. 7, note that
the following tasks may be handled in the order shown
or in another order. Also, some or all of the tasks may be
performed around the same time so as to be performed
substantially concurrently.
[0052] In 701, the circuit keeper computer 230 sends
information to the aggregator computer 210 to update its
routing table to include a static route so that packets addressed to an address associated with the demux computer 240 are sent to the demux computer 240. As previously described, the address in this case may be an
aliased address assigned to the virtual circuit if communications to the demux computer 240 are to be sent over
the VPN tunnel 220, or it may be a public IP address if
communications to the demux computer 240 are to be
sent over the public Internet.
[0053] In 702, the circuit keeper computer 230 also
sends information to the aggregator computer 210 to update its iptables so that packets having a certain destination address associated with the aggregator computer
210 (such as the IP address assigned to one its DSL
modems) is re-written from the original destination address to the address associated with the demux computer 240.
[0054] In a similar manner, in 703, the circuit keeper
computer 230 sends information to the demux computer
240 to update its routing table to include static routes
pointing to application computers that are associated with
the same destination IP address, but different destination
11
EP 1 687 951 B1
ports so that its kernel can determine which of the application computers to route the packet to by looking at the
destination port at OSI Layer 4 as well as the destination
address at OSI Layer 3.
[0055] In 704, the circuit keeper computer 230 also
sends re-write rules information to the demux computer
240 to update its iptables so that packets having the address associated with the demux computer 240 as their
destination address are re-written so that their respective
destination addresses are Ethernet addresses associated with application computers corresponding to their respective destination ports.
[0056] In 705, the circuit keeper computer 230 also
sends re-write rules information to a remux computer 271
to update its iptables so that packets having the addresses associated with the application computers as their
source addresses are re-written to the original destination IP address and destination port. The remux computer
271 in this example serves as a remultiplexing egress
router for a common default gateway of the application
computers.
[0057] In order to tear down this virtual circuit, the routing tables and iptables of the aggregator computer 210,
the demux computer 240 and the remux computer 271
are placed back into their original form (i.e., before adding
the static routes and re-write rules described in reference
to FIG. 7). The application computers are also instructed
to release their respective application programs so that
they are no longer bound to the original destination address and their assigned ports.
[0058] FIG. 8 illustrates, as an example, a flow diagram
of a method for communicating over the Internet with
devices in a decentralized network that corresponds to
the virtual circuit set-up described in reference to FIG. 7.
In this example, a first remote user using client computer
121 in the first geographical region 120 sends an IP packet having a source IP address of 1.1.1.1, destination IP
address of 2.2.2.2 and destination port 4000, and a second remote user using client computer 122 also in the
first geographical region 120 sends a packet having a
source IP address of 3.3.3.3, destination IP address of
2.2.2.2 and destination port 5000 to the aggregator computer 210.
[0059] Accordingly, there are two virtual circuits used
in this example. The first virtual circuit starts with the aggregator computer 210, and ends, for example, with application computer 261. An application program residing
on the application computer 261 has initiated this virtual
circuit and bound itself, for example, to an Ethernet address and assigned port of the application computer 261.
The second virtual circuit, on the other hand, starts with
the aggregator computer 210, and ends, for example,
with application computer 262. An application program
residing on the application computer 262 has initiated
this second virtual circuit and bound itself, for example,
to an Ethernet address and assigned port of the application computer 262.
[0060] In 801, the two IP packets are received at the
5
10
15
20
25
30
35
40
45
50
55
7
12
aggregator computer 210 respectively at its port 4000,
for example, from the remote user of client computer 121
through Ethernet 214 and DSL modem 211, and at its
port 5000, for example, from the remote user of client
computer 122 through Ethernet 214 and DSL modem
212. The first remote user in this example is physically
located in Kansas with an IP address of 1.1.1.1, the second remote user is physically located in Missouri with an
IP address of 3.3.3.3, and the aggregator computer 210
and its DSL modem 211 are physically located in Colorado with an IP address of 2.2.2.2 assigned to the DSL
modem 211 by its ISP. Therefore, at this time, the first
IP packet has a source IP address of 1.1.1.1 and a destination IP address of 2.2.2.2, port 4000, and the second
IP packet has a source IP address of 3.3.3.3 and a destination IP address of 2.2.2.2, port 5000.
[0061] In 802, before passing the packets to its kernel,
their packet headers are modified by using the kernellevel packet filter and mangling system iptables of the
aggregator computer 210 so that the destination address
for both packets is rewritten in the IP packet to 172.16.0.3,
which is an aliased address assigned during virtual circuit
set-up to point to the demux computer 240. The destination port addresses are not checked or changed at this
time.
[0062] In 803, the packets are then passed in serial
fashion on a first-come-first-served fashion to the kernel
of the aggregator computer 210 which looks at the source
and destination IP addresses indicated in each packet.
The kernel, finding that the destination address in each
packet is not a local address, but one that is in its routing
table in a static route to the demux computer 240, routes
the packets over the inter-site VPN tunnel 220 to the
demux computer 240. At this point, the first IP packet has
a source IP address of 1.1.1.1 and a destination IP address of 172.16.0.2 with destination port 4000, and the
second IP packet has a source IP address of 3.3.3.3 and
a destination IP address of 172.16.0.3 with destination
port 5000.
[0063] In 804, the packets are received at the demux
computer 240, and in 805, their destination IP addresses
are again re-written before passing the packets to the
kernel of the demux computer 240. This time, the destination ports for each of the packets is examined at OSI
Layer 4 to determine the application computer that is to
process the packet, as well as at OSI Layer 3 to determine
their destination IP addresses. For the first packet, its
destination port 4000 indicates that it is to be processed
by application computer 261, therefore its destination address is re-written to an Ethernet address 172.17.0.2 corresponding to the application computer 261. On the other
hand, for the second packet, its destination port 5000
indicates that it is to be processed by application computer 262, therefore its destination address is re-written
to an Ethernet address 172.17.0.3 corresponding to the
application computer 262.
[0064] After the destination IP addresses are rewritten
in the packets, the packets are passed to the kernel of
13
EP 1 687 951 B1
the demux computer 240. The kernel sees that the destination addresses of the packets are not a local addresses, but ones that are in its routing table, so in 806, it
routes the first packet over Ethernet 250 to the application
computer 261 that is to process that packet and it routes
the second packet over Ethernet 250 to the application
computer 262 that is to process that packet.
[0065] In 807, the application computer 261 receives
the first packet from the demux computer 240, and its
kernel determines that the packet has a destination IP
address that is a local address. Therefore, in 808, it delivers the packet to an application program that is bound
to its Ethernet address and the correct port. Also, in 807,
the application computer 262 receives the second packet
from the demux computer 240, and its kernel also determines that the packet has a destination IP address that
is a local address. Therefore, in 808, it also delivers its
packet to an application program that is bound to its Ethernet address and the correct port.
[0066] In 809; the application programs on the application computers 261 and 262 then process their respective packets, and generate reply packets if appropriate.
The reply packets are then passed back to their respective kernels, and in 810, each of the kernels sends its
respective reply packet out through a common default
gateway, which is pointed at the remultiplexing egress
router ("remux") computer 271. Each of the reply packets
at this point has its source and destination IP addresses
reversed so that the first reply packet has a source IP
address of 172.17.0.2 (i.e., the Ethernet address of the
application computer 261) with source port 4000 and a
destination IP address of 2.2.2.2 (i.e., the IP address of
the client computer 121), and the second reply packet
has a source IP address of 172.17.0.3 (i.e., the Ethernet
address of the application computer 262) with source
port 5000 and a destination IP address of 3.3.3.3 (i.e.,
the IP address of the client computer 122).
[0067] In 811, the reply packets are received at the
remux computer 271. Before passing the reply packets
to their respective kernels, in 812, the packet filter of the
remux computer 271 first re-writes their source addresses according to re-write rules previously provided to the
remux computer 271 during set up of the two virtual circuits. Accordingly, the source IP address of the first reply
packet is re-written from the Ethernet address 172.17.0.2
to 2.2.2.2, leaving the source port 4000 unchanged. Likewise, the source IP address of the second reply packet
is re-written from the Ethernet address of 172.17.0.3 to
2.2.2.2, leaving the source port 5000 unchanged.
[0068] In 813, the reply packets are then passed back
to the kernel of the remux computer 271. Since the kernel
determines that both reply packets have destination addresses that are not local, it passes both reply packets
out its default gateway to be sent back to their respective
destination IP addresses. At this time, the first reply packet has a source IP address of 2.2.2.2 with source port
4000 and destination IP address of 1.1.1.1, so that it appears to the client computer 121 at the destination IP
5
10
14
address that the reply packet is being sent from the DSL
modem 211 that received its corresponding original packet. Likewise, the second reply packet has a source IP
address of 2.2.2.2 with source port 5000 and destination
IP address of 3.3.3.3, so that it appears to the client computer 122 at the destination IP address that the reply
packet is being sent from the DSL modem 212 that received its corresponding original packet.
[0069] Although the various aspects of the present invention have been described with respect to a preferred
embodiment, it will be understood that the invention is
entitled to full protection within the full scope of the appended claims.
15
Claims
1.
20
receiving a packet from a device (121) in a point
of presence (111);
routing the packet according to a virtual circuit
(220) from the point of presence to an application computer (261) of a centralized data center
(101) wherein the virtual circuit is defined such
that subsequently received packets in the point
of presence (111) from the device are also routed according to the virtual circuit from the point
of presence (111) to the application computer
(261);
generating a reply packet by the application
computer (261) processing information in the
packet; and characterized in
passing the reply packet to a remux computer
(271) in a default gateway of the application
computer (261); and
re-writing the source IP address of the reply
packet so as to include the original destination
address associated with the point of presence
(111) according to re-write rules provided to the
remux compute (271); and
transmitting the reply packet with the re-written
source IP address back to the device from the
remux computer (271).
25
30
35
40
45
2.
The method according to claim 1, wherein the reply
packet indicates a destination IP address associated
with the device.
3.
The method according to claim 2, wherein the routing
of the packet to the application compute (261) of the
centralized data center includes rewriting a destination address in the packet from an original destination address to an address associated with the centralized data center (101).
50
55
8
A method for communicating with devices
(121-123,131-133,141-143) in a decentralized network, comprising:
15
4.
EP 1 687 951 B1
The method according to claim 3, wherein the rewriting of the destination address is performed in accordance with re-write rules provided to the point of
presence (111).
5
5.
6.
The method according to claim 3, wherein the routing
of the packet to the application computer (261) of
the centralized data center (101) includes routing the
packet to the centralized data center (101) according
to a first static route defined in a routing table of a
first computer (210) in the point of presence (111).
The method according to claim 3, wherein the routing
of the packet to the application computer (261) of
the centralised data centre (101) comprises:
rewriting the destination address in the packet
from the address associated with the centralized
data center (101) to an address associated with
the application computer (261) in the centralized
data center (101); and
routing the packet to the application computer
(261);
and generation of the reply packet comprises:
processing the packet with an application program residing on the application computer (261)
to generate the reply packet.
7.
8.
9.
The method according to claim 6, wherein the packet
is routed to the application computer (261) according
to a static route defined in a routing table of a second
computer (240) in the centralized data center (101)
The method according to claim 6, further comprising
designating the original destination address as an
alias on the loopback interface of the application
computer (261)
The method according to claim 8, wherein the address associated with the application computer (261)
is the original destination address.
10. The method according to claim 6, wherein a second
computer in the centralized data center (101) and
the application computer (261) communicate
through an Ethernet network (250), and the address
associated with the application computer (261) is an
Ethernet address assigned to the application computer (261).
10
15
presence (111), a second computer (240) in the
centralized data center (101), and the application computer (261) initiating the request; and
sending first re-write rules to the first computer
(210) and second re-write rules to the second
computer (240) when establishing the virtual circuit so that the first re-write rules cause the first
computer (210) to re-write a destination address
included in a packet of information received from
the device in the decentralized network to be rewritten from an original destination address to
an address associated with the second computer (240), and the second re-write rules cause
the second computer (240) to re-write the destination address from the address associated
with the second computer (240) to an address
associated with the application computer (261)
after receiving the packet from the first computer
(210).
20
25
30
35
40
45
13. The method according to claim 12, further comprising sending a first static route to the first computer
(210) and a second static route to the second computer (240) when establishing the virtual circuit so
that the first static route instructs the first computer
(210) to route the packet received from the device
to the second computer (240) and the second static
route instructs the second computer (240) to route
the packet to the application computer (261) after
receiving the packet from the first computer (210).
14. The method according to claim 12, further comprising designating the original destination address as
an alias on a loopback interface of the application
computer (261) so that the address associated with
the application computer (261) is the original destination address.
15. The method according to claim 12, wherein the address associated with the application computer (261)
is an Ethernet address, and further comprising sending third rewrite rules to a third computer (271) of a
default gateway of the application computer (261)
so that the third computer re-writes a source address
in a reply packet generated by the application computer (261) from the Ethernet address associated
with the application computer (261) to the original
destination address.
50
16. A method according to claim 1 wherein the generation of the reply packet by the application computer
(261) processing information of the packet comprises:
55
receiving a packet from the point of presence
(111) that has re-written a destination address
in the packet from an original destination address associated with the point of presence
11. The method according to claim 10, further comprising: determining the Ethernet address using information of a destination port indicated in the packet.
12. A method as claimed in claim 1, further comprising:
16
receiving a request to establish the virtual circuit
including a first computer (210) in the point of
9
17
EP 1 687 951 B1
(111) to an address associated with a first node
(240) of the centralized network;
re-writing the destination address from the address associated with the first node (240) to an
address associated with the application computer (261) of the centralized data centre (101);
routing the packet to the application computer
(261) according to a static route defined in a routing table of the first node (240); and generating
a reply packet by processing information in the
packet using an application program residing on
the application computes (261).
17. The method according to claim 16, wherein the centralized data centre (101) has an Ethernet network
(250) and the address associated with the application computer (261) is an Ethernet address.
18. The method according to claim 17, further comprising: determining the Ethernet address using information included in a destination port indicated in the
packet.
19. The method according to claim 16, wherein the receiving of the packet from the point of presence (111)
is received by the first node (240) of the centralized
data centre (101) over the Internet, and the address
associated with the first node (240) is an IP address.
20. The-method according to claim 16, wherein the receiving of the packet from the point of presence (111)
is received by the first node (240) of the centralized
data centre (101) through a virtual private network
over the Internet, and the address associated with
the first node (240) is an aliased address.
Verfahren zum Kommunizieren mit Geräten
(121-123; 131-133; 141-143) in einem dezentralisierten Netzwerk, umfassend:
Empfangen eines Pakets von einem Gerät (121)
an einem Präsenzpunkt (111);
Leiten des Pakets entsprechend einer virtuellen
Schaltung (220) vom Präsenzpunkt zu einem
Anwendungscomputer (261) eines zentralisierten Datenzentrums (101), wobei die virtuelle
Schaltung so definiert ist, dass aufeinanderfolgend empfangene Pakete vom Gerät am Präsenzpunkt (111) ebenfalls gemäß der virtuellen
Schaltung vom Anwesenheitspunkt (111) zum
Anwendungscomputer (261) geleitet werden;
Erzeugen eines Antwortpakets mittels der Verarbeitungsinformationen des Anwendungscomputers im Paket; und
gekennzeichnet durch
Weitergeben des Antwortpakets an einen Remux-Computer (271) in einem Default-Gateway
des Anwendungscomputers (261); und
erneutes Schreiben der Quellen-IP-Adresse
des Antwortpakets, so dass die mit dem Präsenzpunkt (111) verknüpfte ursprüngliche Zieladresse entsprechend dem Remux-Computer
(271) zur Verfügung gestellten Regeln für das
erneute Schreiben enthalten ist; und
Übertragen des Antwortpakets mit der erneut
geschriebenen Quellen-IP-Adresse vom Remux-Computer (271) zurück zum Gerät.
5
10
2.
Verfahren nach Anspruch 1, wobei das Antwortpaket
eine mit dem Gerät verknüpfte Ziel-IP-Adresse angibt.
3.
Verfahren nach Anspruch 2, wobei das Leiten des
Pakets zum Anwendungscomputer (261) des zentralisierten Datenzentrums das erneute Schreiben
einer Zieladresse im Paket von einer ursprünglichen
Zieladresse auf eine mit dem zentralisierten Datenzentrum (101) verknüpfte Adresse beinhaltet.
25
4.
Verfahren nach Anspruch 3, wobei das erneute
Schreiben der Zieladresse gemäß dem Präsenzpunkt (111) zur Verfügung gestellten Regeln für das
erneute Schreiben ausgeführt wird.
30
5.
Verfahren nach Anspruch 3, wobei das Leiten des
Pakets zum Anwendungscomputer (261) des zentralisierten Datenzentrums (101) das Leiten des Pakets zum zentralisierten Datenzentrum (101) gemäß
einer in einer Leittabelle eines ersten Computers
(210) am Anwesenheitspunkt (111) definierten ersten statischen Route beinhaltet.
6.
Verfahren nach Anspruch 3, wobei das Leiten des
Pakets zum Anwendungscomputer (261) des zentralisierten Datenzentrums (101) umfasst:
15
20
35
Patentansprüche
1.
18
40
erneutes Schreiben der Zieladresse im Paket
von der mit dem zentralisierten Datenzentrum
(101) verknüpften Adresse auf eine mit dem Anwendungscomputer (261) im zentralisierten Datenzentrum (101) verknüpfte Adresse; und
Leiten des Pakets zum Anwendungscomputer
(261);
und wobei die Erzeugung des Anwortpakets
umfasst:
Verarbeiten des Pakets mit einem im Anwendungscomputer (261) vorliegenden Anwendungsprogramm, um das Antwortpaket zu erzeugen.
45
50
55
7.
10
Verfahren nach Anspruch 6, wobei das Paket zum
Anwendungscomputer (261) gemäß einer in einer
Leittabelle eines zweiten Computers (240) im zen-
19
EP 1 687 951 B1
tralisierten Datenzentrum (101) definierten statischen Route geleitet wird.
8.
9.
Verfahren nach Anspruch 6, ferner umfassend das
Auszeichnen der ursprünglichen Zieladresse als ein
Alias auf der Rückkopplungs-Schnittstelle des Anwendungscomputers (261).
Verfahren nach Anspruch 8, wobei die mit dem Anwendungscomputer (261) verknüpfte Adresse die
ursprüngliche Zieladresse ist.
10. Verfahren nach Anspruch 6, wobei ein zweiter Computer im zentralisierten Datenzentrum (101) und der
Anwendungscomputer (261) durch ein EthernetNetzwerk (250) kommunizieren und die mit dem Anwendungscomputer (261) verknüpfte Adresse eine
dem Anwendungscomputer (261) zugeordnete
Ethernet-Adresse ist.
5
10
15
20
11. Verfahren nach Anspruch 10, ferner umfassend:
Bestimmen der Ethernet-Adresse mittels Informationen eines im Paket angegebenen Zielports.
25
12. Verfahren nach Anspruch 1, ferner umfassend:
Empfangen einer Anforderung auf das Einrichten der virtuellen Schaltung, die einen ersten
Computer (210) am Präsenzpunkt (111), einen
zweiten Computer (240) im zentralisierten Datenzentrum (101) und den Anwendungscomputer (261), von dem die Anforderung ausgeht,
enthält; und
Senden erster Regeln zum erneuten Schreiben
an den ersten Computer (210) und zweiter Regeln zum erneuten Schreiben an den zweiten
Computer (240), wenn die virtuelle Schaltung
eingerichtet wird, so dass die ersten Regeln zum
erneuten Schreiben den ersten Computer (210)
eine Zieladresse, die in einem Paket von Informationen enthalten ist, die von dem erneut zu
beschreibenden Gerät im dezentralisierten
Netzwerk empfangen worden sind, von einer ursprünglichen Zieladresse auf eine mit dem zweiten Computer (240) verknüpfte Adresse erneut
schreiben lassen, und die zweiten Regeln zum
erneuten Schreiben den zweiten Computer
(240) die Zieladresse von der mit dem zweiten
Computer (240) verknüpften Adresse auf eine
mit dem Anwendungscomputer (261) verknüpfte Adresse erneut schreiben lassen, nachdem
das Paket vom ersten Computer (210) empfangen worden ist.
20
Computer (210) und einer zweiten statischen Route
zum zweiten Computer (240), wenn die virtuelle
Schaltung eingerichtet wird, so dass die erste statische Route den ersten Computer (210) anweist, das
vom Gerät empfangene Paket zum zweiten Computer (240) zu leiten, und die zweite statische Route
den zweiten Computer (240) anweist, das Paket zum
Anwendungscomputer (261) zu leiten, nachdem das
Paket vom ersten Computer (210) empfangen worden ist.
14. Verfahren nach Anspruch 12, ferner umfassend das
Auszeichnen der ursprünglichen Zieladresse als einen Alias auf einer Rückkopplungs-Schnittstelle des
Anwendungscomputers (261), so dass die mit dem
Anwendungscomputer (261) verknüpfte Adresse die
ursprüngliche Zieladresse ist.
15. Verfahren nach Anspruch 12, wobei die mit dem Anwendungscomputer (261) verknüpfte Adresse eine
Ethernet-Adresse ist und das Verfahren ferner das
Senden dritter Regeln zum erneuten Schreiben an
einem dritten Computer (271) eines Default-Gateways des Anwendungscomputers (261) umfasst, so
dass der dritte Computer eine Quellenadresse in einem vom Anwendungscomputer (261) erzeugten
Antwortpaket von der mit dem Anwendungscomputer (261) verknüpften Ethernet-Adresse auf die ursprüngliche Zieladresse erneut schreibt.
30
16. Verfahren nach Anspruch 1, wobei die Erzeugung
des Antwortpakets mittels Verarbeitungsinformationen des Anwendungscomputers (261) des Pakets
umfasst:
35
40
45
50
55
13. Verfahren nach Anspruch 12, ferner umfassend das
Senden einer ersten statischen Route zum ersten
11
Empfangen eines Pakets vom Präsenzpunkt
(111), der eine Zieladresse im Paket von einer
mit dem Präsenzpunkt (111) verknüpften ursprünglichen Zieladresse auf eine mit einem ersten Knoten (240) des zentralisierten Netzwerks
verknüpfte Adresse erneut geschrieben hat;
erneutes Schreiben der Zieladresse von der mit
dem ersten Knoten (240) verknüpften Adresse
auf eine mit dem Anwendungscomputer (261)
des zentralisierten Datenzentrums (101) verknüpfte Adresse;
Leiten des Pakets zum Anwendungscomputer
(261) gemäß einer in einer Leittabelle des ersten
Knotens (240 definierten statischen Route und
Erzeugen eines Antwortpakets durch Verarbeiten von Informationen im Paket mittels eines auf
dem Anwendungscomputer (261) vorhandenen
Anwendungsprogramms.
17. Verfahren nach Anspruch 16, wobei das zentralisierte Datenzentrum (101) ein Ethernet-Netzwerk (250)
aufweist und die mit dem Anwendungscomputer
(261) verknüpfte Adresse eine Ethernet-Adresse ist.
21
EP 1 687 951 B1
18. Verfahren nach Anspruch 17, ferner umfassend: Bestimmen der Ethernet-Adresse mittels Informationen, die in einem im Paket angegebenen Zielport
enthalten sind.
quet de réponse indique une adresse IP de destination associée au dispositif.
3.
Procédé selon la revendication 2, dans lequel le routage du paquet vers l’ordinateur d’application (261)
du centre de données centralisé comporte la réécriture d’une adresse de destination dans le paquet en
passant d’une adresse de destination originale à une
adresse associée au centre de données centralisé
(101).
4.
Procédé selon la revendication 3, dans lequel la réécriture de l’adresse de destination est réalisée conformément aux règles de réécriture prévues au point
de présence (111).
5.
Procédé selon la revendication 3, dans lequel le routage du paquet vers l’ordinateur d’application (261)
du centre de données centralisé (101) comporte le
routage du paquet vers le centre de données centralisé (101) selon un premier trajet statique définit
dans une table de routage d’un premier ordinateur
(210) dans le point de présence (111).
6.
Procédé selon la revendication 3, dans lequel le routage du paquet vers l’ordinateur d’application (261)
du centre de données centralisé (101) comprend le
fait :
5
19. Verfahren nach Anspruch 16, wobei das Empfangen
des Pakets vom Präsenzpunkt (111) vom ersten
Knoten (240) des zentralisierten Datenzentrums
(101) über das Internet empfangen worden ist und
die mit dem ersten Knoten (240) verknüpfte Adresse
eine IP-Adresse ist.
20. Verfahren nach Anspruch 16, wobei das Empfangen
des Pakets vom Präsenzpunkt (111) vom ersten
Knoten (240) des zentralisierten Datenzentrums
(101) über ein virtuelles privates Netz über das Internet empfangen worden ist und die mit dem ersten
Knoten (240) verknüpfte Adresse eine Alias-Adresse ist.
10
15
20
Revendications
1.
Procédé pour communiquer avec des dispositifs
(121-123, 131-133, 141-143) dans un réseau décentralisé, comprenant le fait :
de recevoir un paquet à partir d’un dispositif
(121) dans un point de présence (111) ;
de router le paquet selon un circuit virtuel (220)
à partir du point de présence jusqu’à un ordinateur d’application (261) d’un centre de données
centralisé (101) dans lequel le circuit virtuel est
défini de telle sorte que des paquets reçus par
la suite dans le point de présence (111) en provenance du dispositif soient également routés
selon le circuit virtuel à partir du point de présence (111) jusqu’à l’ordinateur d’application
(261) ;
de générer un paquet de réponse par l’ordinateur d’application (261) qui traite une information
dans le paquet ; et caractérisé en ce qu’il :
fait passer le paquet de réponse à un ordinateur (271) de type routeur de sortie de
remultiplexage, dit ordinateur remux, dans
une passerelle par défaut de l’ordinateur
d’application (261) ; et
de réécrire l’adresse IP source du paquet
de réponse afin d’inclure l’adresse de destination originale associée au point de présence (111) selon des règles de réécriture
fournies à l’ordinateur remux (271) ; et
de renvoyer le paquet de réponse avec
l’adresse IP source réécrite au dispositif à
partir de l’ordinateur remux (271).
2.
22
25
de réécrire l’adresse de destination dans le paquet en passant de l’adresse associée au centre
de données centralisé (101) à une adresse associée à l’ordinateur d’application (261) dans le
centre de données centralisé (101) ; et
de router le paquet vers l’ordinateur d’application (261) ;
et la génération du paquet de réponse comprend
le fait :
30
35
de traiter le paquet avec un programme
d’application résidant sur l’ordinateur d’application (261) pour générer le paquet de
réponse.
40
45
7.
Procédé selon la revendication 6, dans lequel le paquet est routé vers l’ordinateur d’application (261)
selon un trajet statique définit dans une table de routage d’un deuxième ordinateur (240) dans le centre
de données centralisé (101).
8.
Procédé selon la revendication 6, comprenant en
outre le fait de désigner l’adresse de destination originale comme un alias sur l’interface de retour de
boucle de l’ordinateur d’application (261).
9.
Procédé selon la revendication 8, dans lequel
l’adresse associée à l’ordinateur d’application (261)
est l’adresse de destination originale.
50
55
Procédé selon la revendication 1, dans lequel le pa-
12
23
EP 1 687 951 B1
10. Procédé selon la revendication 6, dans lequel un
deuxième ordinateur dans le centre de données centralisé (101) et l’ordinateur d’application (261) communiquent par l’intermédiaire d’un réseau Ethernet
(250), et l’adresse associée à l’ordinateur d’application (261) est une adresse Ethernet attribuée à l’ordinateur d’application (261).
11. Procédé selon la revendication 10, comprenant en
outre le fait : de déterminer l’adresse Ethernet en
utilisant une information d’un port de destination indiqué dans le paquet.
12. Procédé selon la revendication 1, comprenant en
outre le fait :
de recevoir une demande pour établir le circuit
virtuel comportant un premier ordinateur (210)
dans le point de présence (111), un deuxième
ordinateur (240) dans le centre de données centralisé (101), et l’ordinateur d’application (261)
qui est l’initiateur de la demande ; et
d’envoyer des premières règles de réécriture au
premier ordinateur (210) et des deuxièmes règles de réécriture au deuxième ordinateur (240)
lors de l’établissement du circuit virtuel de sorte
que les premières règles de réécriture amènent
le premier ordinateur (210) à réécrire une adresse de destination incluse dans un paquet d’information reçu du dispositif dans le réseau décentralisé pour qu’elle soit réécrite en passant
d’une adresse de destination originale à une
adresse associée au deuxième ordinateur
(240), et les deuxièmes règles de réécriture
amènent le deuxième ordinateur (240) à réécrire
l’adresse de destination en passant de l’adresse
associée au deuxième ordinateur (240) à une
adresse associée à l’ordinateur d’application
(261) après la réception du paquet en provenance du premier ordinateur (210).
13. Procédé selon la revendication 12, comprenant en
outre le fait d’envoyer un premier trajet statique au
premier ordinateur (210) et un deuxième trajet statique au deuxième ordinateur (240) lors de l’établissement du circuit virtuel de sorte que le premier trajet
statique demande au premier ordinateur (210) de
router le paquet reçu du dispositif vers le deuxième
ordinateur (240), et le deuxième trajet statique demande au deuxième ordinateur (240) de router le
paquet vers l’ordinateur d’application (261) après la
réception du paquet en provenance du premier ordinateur (210).
14. Procédé selon la revendication 12, comprenant en
outre le fait de désigner l’adresse de destination originale comme étant un alias sur une interface de
retour de boucle de l’ordinateur d’application (261)
24
de sorte que l’adresse associée à l’ordinateur d’application (261) soit l’adresse de destination originale.
5
10
15. Procédé selon la revendication 12, dans lequel
l’adresse associée à l’ordinateur d’application (261)
est une adresse Ethernet, et comprenant en outre
le fait d’envoyer des troisièmes règles de réécriture
à un troisième ordinateur (271) d’une passerelle par
défaut de l’ordinateur d’application (261) de sorte
que le troisième ordinateur réécrive une adresse
source dans un paquet de réponse généré par l’ordinateur d’application (261) en passant de l’adresse
Ethernet associée à l’ordinateur d’application (261)
à l’adresse de destination originale.
15
16. Procédé selon la revendication 1, dans lequel la génération du paquet de réponse par l’ordinateur d’application (261) qui traite une information du paquet,
comprend le fait :
20
25
30
35
de recevoir un paquet à partir du point de présence (111) qui a réécrit une adresse de destination dans le paquet en passant d’une adresse
de destination originale associée au point de
présence (111) à une adresse associée à un
premier noeud (240) du réseau centralisé ;
de réécrire l’adresse de destination en passant
de l’adresse associée au premier noeud (240)
à une adresse associée à l’ordinateur d’application (261) du centre de données centralisé
(101) ;
de router le paquet vers l’ordinateur d’application (261) selon un trajet statique définit dans
une table de routage du premier noeud (240) ;
et de générer un paquet de réponse en traitant
une information dans le paquet en utilisant un
programme d’application résidant sur l’ordinateur d’application (261).
40
17. Procédé selon la revendication 16, dans lequel le
centre de données centralisé (101) comprend un réseau Ethernet (250) et l’adresse associée à l’ordinateur d’application (261) est une adresse Ethernet.
45
18. Procédé selon la revendication 17, comprenant en
outre le fait : de déterminer l’adresse Ethernet en
utilisant une information incluse dans un port de destination indiqué dans le paquet.
50
19. Procédé selon la revendication 16, dans lequel la
réception du paquet à partir du point de présence
(111) se fait par le premier noeud (240) du centre de
données centralisé (101) par l’intermédiaire de l’Internet, et l’adresse associée au premier noeud (240)
est une adresse IP.
55
20. Procédé selon la revendication 16, dans lequel la
réception du paquet à partir du point de présence
13
25
EP 1 687 951 B1
(111) se fait par le premier noeud (240) du centre de
données centralisé (101) par l’intermédiaire d’un réseau privé virtuel sur l’Internet, et l’adresse associée
au premier noeud (240) est une adresse sous forme
d’alias.
5
10
15
20
25
30
35
40
45
50
55
14
26
EP 1 687 951 B1
15
EP 1 687 951 B1
16
EP 1 687 951 B1
17
EP 1 687 951 B1
18
EP 1 687 951 B1
19
EP 1 687 951 B1
20
EP 1 687 951 B1
21
EP 1 687 951 B1
REFERENCES CITED IN THE DESCRIPTION
This list of references cited by the applicant is for the reader’s convenience only. It does not form part of the European
patent document. Even though great care has been taken in compiling the references, errors or omissions cannot be
excluded and the EPO disclaims all liability in this regard.
Non-patent literature cited in the description
•
•
Impact of the Evolution of the Metropolitan Network
on the DSL Access Architecture. IEEE, 2003 [0007]
22
A Scalable and Highly Available web Server. Dias,
D.M. et al. Digest of Papers of COMPCON (Computer Society Conference) 1996 Technologies of the Information Superhighway. IEEE Comp. Soc. Press,
25 February 1996 [0008]