Note: Descriptions are shown in the official language in which they were submitted.
CA 02680599 2009-10-16
A METHOD AND SYSTEM FOR AUTOMATICALLY CONFIGURING AN IPsec-BASED
VIRTUAL PRIVATE NETWORK
FIELD OF THE INVENTION
100011 The invention relates generally to computer networks, and more
particularly, to a
method and system for automatically configuring an IPsec-based Virtual Private
Network
(VPN).
BACKGROUND
100021 Communication networks might be either private or public. In private
networks,
communications between multiple computers occur through a permanent or
switched network,
such as a telephone network. These computers are typically connected to each
other via a dial-
up or leased telephone line, thereby emulating their physical attachment to
one another. This
type of network is usually considered as being private and "trusted" because
the
communication signals travel directly from one computer to another.
100031 Public networks such as the Internet, on the other hand, are
"untrusted" networks
because the communication over these networks is not private and is
susceptible to interception
by other computers. In addition, the public networks cannot guarantee the
delivery of the data
packets being sent. Such networks allow packets to be injected into, or
ejected out of, the
networks indiscriminately, and analyzed while in transit. To keep data
communicated on such
networks private, data sent from a first party to a second party is encrypted
in a security
gateway of the first party, sent in encrypted form over the public network to
the second party,
where the transmitted data is decrypted in a security gateway and the
decrypted data is
forwarded to the recipient. These private channels, which are established on
top of another
network, are referred to as "tunnels."
CA920090026CA 1 1
CA 02680599 2009-10-16
100041 A virtual private network (VPN) is a private data network that makes
use of tunnels to
maintain privacy when communicating over a public telecommunication
infrastructure, such as
the Internet. The purpose of VPNs is to give server operators, such as
corporations, the same
capabilities that they would have if they had a private permanent or switched
network. The
Virtual Private Networks also cost much less to operate than other private
networks, as they use
a shared public infrastructure rather than a private one.
[0005] A Virtual Private Network is typically transparent to the computers
that are
communicating between each other through the Virtual Private Network. The
encryption and
decryption of the data flow between the computers depend on the configuration
of the Virtual
Private Network between these computers. However, the security gateways to
which the
computers are connected must have information about the configuration of the
other end of the
network in order to be able to encrypt and decrypt the traffic correctly. The
configuration
includes items like the addresses of the networks that the computers belong
to, the encryption
algorithm used and key information about the other end security gateway. The
configuration
information is usually conveyed between the site administrators by telephone.
The
administrators then input the configuration to the security gateways of their
sites in order to
enable VPN connections between the sites. The actual encryption keys are
exchanged in VPN
communication, but the configuration that is needed for initiating VPN
connection needs to be
conveyed by some other means.
[0006] Keeping the information about the structure of the VPN up to date at
each site
(computer nodes and networks connected to the VPN) is a complex task. Every
site must have
the correct configuration for all the other sites in order to communicate with
them. In large
Virtual Private Networks, there may be dozens or hundreds of sites and the
configuration may
vary in time rather frequently, such as when a new network or computer joins
the VPN. When
the configuration of one VPN site changes, all sites need to be updated. As a
result, contacting
the administrators of all other sites by telephone to communicate a
configuration change would
not be practicable.
CA920090026CA 1 2
CA 02680599 2009-10-16
[0007] An alternative solution to notifying the network administrators is to
automatically
configure an IPsec-based Virtual Private Network using dynamic routing. In
order to configure
a network with dynamic routing, a routing table must be maintained at each
network that
defines the destination for all outgoing traffic. However, an IPsec-based
network requires the
routing information for both incoming and outgoing network traffic. As a
result, an IPsec-
based Virtual Private Network cannot be automatically configured based on the
routing table
alone.
[0008] Another option for automatically configuring an IPsec-based Virtual
Private Network is
to build a second layer of tunnels on top of the IPsec VPN tunnels. However,
this approach
adds additional system overheads and is also less secure because the traffic
flow through
second-layer tunnels is not controlled by the IPsec security policy database.
See, for example,
the Internet-Draft document entitled "Use of IPsec Transport Mode for Dynamic
Routing" by J.
Touch et al., the Internet Engineering Task Force, 2004, and the Internet-
Draft document
entitled "A Method to Provide Dynamic Routing in IPsec VPNs" by P. Knight et
al., the
Internet Engineering Task Force, 2003.
[0009] Automatic provisioning of IPSec customer edge devices is another
process that might
be used in a Virtual Private Network that has centralized network management.
See, for
example, the Internet-Draft document entitled "Routing Support in CE-based
IPsec VPNs" by
C. Wang et al., the Internet Engineering Task Force, 2001. A configuration
based on the IPsec
customer edge devices, however, requires a central authority for distributing
a policy
configuration to all other nodes in the Virtual Private Network.
100101 In light of the above shortcomings, it is appreciated that there exists
a need for a method
and system for automatically configuring an IPsec-based Virtual Private
Network.
CA920090026CA 1 3
CA 02680599 2009-10-16
SUMMARY
[0011] The present invention describes a method and system for automatically
configuring an
IPsec-based Virtual Private Network. Each node in the Virtual Private Network
is configured
as an IPsec peer node and is associated with a primary network and one or more
secondary
networks. Each primary or secondary network in the Virtual Private Network
includes other
computers referred to as host computers, or simply as "hosts". The hosts in
the Virtual Private
Network communicate with each other through their associated IPsec peer nodes
(i.e., the
network gateways) and networks. Each IPsec peer node intercepts all
advertisement packets
sent to its primary network. An IPsec peer node also maintains a Security
Policy Database that
includes information about the data flow between each pair of networks within
the Virtual
Private Network that are known to this particular peer node.
[0012] When a first peer node in the Virtual Private Network detects a new
network in its
network configuration, it sends an advertisement packet to the other peer
nodes in the Virtual
Private Network. As a second peer node in the Virtual Private Network receives
the
advertisement packet, it adds information about the new network to its
Security Policy
Database if this information is not already in the database.
100131 In addition, the second peer node updates its Security Policy Database
with a new
metric about the network path between the new network and the first peer node
if the new
network is already in the database, but the new metric is lower than a
previously recorded
metric for this particular network. The new metric is included in the
advertisement packet and
relates to the number of intermediary nodes between the new network and the
first node. A
lower metric corresponds to a smaller number of intermediary nodes and thus a
shorter network
path. If the advertisement packet concerns a new host in a trusted network
connected to the
first a peer node, rather than about a new network, then the second peer node
adds the new host
to a list of host names that are known to and maintained by the second peer
node.
CA920090026CA1 4
CA 02680599 2009-10-16
[0014] The first IPsec peer node also sends an advertisement packet whenever
it detects a new
IPsec connection between any two IPsec peer nodes in the Virtual Private
Network. In
addition, an advertisement packet is distributed to other IPsec peer nodes
when a first IPsec
peer node in the Virtual Private Network detects a change in its network
configuration or a
change in the list of the trusted networks known to the first peer node.
[0015) In another aspect of the invention, all IPsec peer nodes in the Virtual
Private Network
periodically distribute advertisement packets to other nodes in the Virtual
Private Network to
compensate for data packet loss among the nodes. Each advertisement packet
includes a list of
the trusted networks known to the sending peer node, and a network path metric
for each
trusted network. The network metric relates to the number of intermediary
nodes between the
trusted network and the sending node. The advertisement packet further
includes a list of host
names that are known to the sending IPsec peer node.
[0016] To avoid data fragmentation, each advertisement packet distributed by
the IPsec peer
nodes is split into several Universal Datagram Protocol (UDP) packets. Each
UDP packet is
smaller than the maximum transmission unit permitted by the protocol. The
advertisement
packet is addressed to an arbitrary network address that is known to the
sending peer node,
rather than to a specific address, because the actual address of a receiving
peer node is not
known to the sending peer node.
[0017] In still another aspect of the invention, a system is described for
automatically
configuring an IPsec-based Virtual Private Network having multiple computer
peer nodes.
Each IPsec peer node maintains a Security Policy Database that has the network
configurations
of the peer nodes in the Virtual Private Network. The system further includes
logic for
distributing, receiving and processing the advertisement packets concerning
the peer nodes in
the Virtual Private Networks and the network configurations known to the peer
nodes. An
advertisement is distributed whenever a peer node detects a new network in its
network
configuration or a new IPsec connection between two peer nodes in the Virtual
Private
Network.
CA920090026CA 1 5
CA 02680599 2009-10-16
[0018] In addition, the system includes logic in each peer node to distribute
an advertisement
packet to other peer nodes in the Virtual Private Network whenever the peer
node detects a
change in its network configuration or a change in the list of trusted
networks that are known to
the peer node. The system further includes logic in the peer node for adding
information about
the new network to the Security Policy Database if this information is not
already in the
database or the network path metric for this network is shorter than what is
currently in the
database.
[0019] In yet another aspect of the invention, a computer program product for
use with a
computer is described, for automatically configuring an IPsec-based Virtual
Private Network
(VPN) having multiple computer nodes. The computer program product includes a
component
operable to receive an advertisement packet concerning a new network detected
by the first
node, and add information about the new network to the Security Policy
Database of a second
node if the information is not already in the database.
[0020] Further details of the present invention, both as to its structure and
operation, are
described below in the Detailed Description section in reference to the
accompanying
drawings, in which like reference numerals refer to like parts. This Summary
is intended to
identify key features of the claimed subject matter, but it is not intended to
be used to limit the
scope of the claimed subject matter.
BRIEF DESCRIPTION OF THE DRAWINGS
[0021] FIG. 1 is a block diagram illustrating two trusted networks in an IPsec-
based Virtual
Private Network tunnel established over the Internet in which aspects of the
invention might be
used.
[0022] FIG. 2 is a diagram illustrating a typical format of a data packet
transmitted through an
IPsec-based Virtual Private Network tunnel.
CA920090026CA 1 6
CA 02680599 2009-10-16
[0023] FIG. 3 is a diagram illustrating a typical format of an advertisement
packet transmitted
through an IPsec-based Virtual Private Network tunnel in which aspects of the
invention might
be used.
[0024] FIG. 4 is a block diagram illustrating the trusted networks connected
to a node X in an
IPsec-based Virtual Private Network in which aspects of the invention might be
used.
[0025] FIG. 5 is a block diagram illustrating the trusted networks connected
to two nodes X
and Y in an IPsec-based Virtual Private Network and the computer hosts in
these trusted
networks.
100261 FIG. 6 is a block diagram illustrating the trusted networks connected
to three peer
nodes X, Y and Z in an IPsec-based Virtual Private Network and their
associated primary
networks, secondary networks and host computers.
[0027] FIG. 7 is a flow chart representing a process for automatically
configuring the nodes in
an IPsec-based Virtual Private Network in accordance with the invention.
[0028] FIG. 8 is a flow chart representing a process for updating the host
names, as part of the
automatic configuration of an IPsec-based Virtual Private Network in
accordance with the
invention.
DETAILED DESCRIPTION OF THE INVENTION
[0029] The invention relates generally to computer networks. More
specifically, the present
invention provides a method and system for automatically configuring a Virtual
Private
Network that are based on the IPsec communication protocol.
[0030] As will be appreciated by one skilled in the art, the present invention
may be embodied
as a method, system or computer program product. Accordingly, the present
invention may
CA920090026CA 1 7
CA 02680599 2009-10-16
take the form of an entirely software embodiment (including firmware, resident
software,
micro-code, etc.), an entirely hardware embodiment, or an embodiment of any
combination of
software and hardware components. Furthermore, the present invention may take
the form of a
computer program product embodied in any tangible medium of expression having
computer-
usable program code embodied in the medium.
[0031] Any combination of one or more computer usable or computer readable
media may be
utilized. The computer-usable or computer-readable media may be, for example
but not limited
to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor
system, apparatus,
device, or propagation medium. An example of a computer-readable medium is a
hard disk
drive.
[0032] Referring now to the drawings, in which like numerals represent like
elements, aspects
of the present invention and exemplary operating environments will be
described.
100331 FIG. 1 is a block diagram representing an IPsec-based Virtual Private
Network 100 that
is established through the public Internet by two trusted networks I10 and
119. The trusted
network 110 includes multiple computers 111 which are connected with each
other through a
network 112. The trusted network 119 includes multiple computers 117 which are
connected
with each other through a network 118. The computers 111 and 117 are often
referred to as
"hosts". The networks 112 and 118 are typically local area networks (LANs)
such as the
Ethernet networks. The networks 112 and 118 are further connected to the
public Internet
through an IPsec security gateway computers 113 and 116, respectively. The
gateway
computers 113 and 116 are often referred to as IPsec peer nodes in the Virtual
Private Network
100. In order to securely communicate with each other through the public
Internet 114, the
trusted networks I10 and 119 establish an IPsec-based Virtual Private Network
(VPN) 115
between them through the Internet 114.
[0034] Once the IPsec-based Virtual Private Network 115 is established, a host
computer 111
in the trusted network 110 might securely communicate with a host computer 117
in the trusted
CA920090026CA 1 8
CA 02680599 2009-10-16
network 119 through the Virtual Private Network 115. The data packets sent
through the
Virtual Private Network 115 are included in other data packets with additional
packet
identification and security information to keep the contents of the original
packets from being
exposed to other computers on the Internet. The secure communication path
between the two
networks I 10 and 119 over the public Internet 114 is referred to as a
"tunnel". Since it is based
on the Internet Protocol (IP), this secure path is called an IPsec-based
Virtual Private Network
(VPN) tunnel. Examples of the contents of the data packets that are sent and
received over an
IPsec-based Virtual Private Network tunnel 115 are described below in
reference to FIG. 2.
[0035] FIG. 2 illustrates an example of the contents in an IPsec data packet.
The data packet
210 represents a packet that might be sent by a host computer I11 or host
computer 117 to
other computers in the Virtual Private Network. The data packet 210 includes
an IP header 211
and a data field 212. The IP header 211 contains the data type, a packet
number, the total
number of packets being transmitted, and the sender and receiver's IP
addresses. To keep the
contents of the IP header 211 and the data field 212 private to the sending
and receiving host
computers, these contents are included in a larger data packet 213 when they
are sent over the
Internet.
[0036] In addition to the original IP header 211 and data field 212, the
packet 213 includes a
new IP header 214 and an Encapsulating Security Payload (ESP) header 215. The
new IP
header 214 and the ESP header 215 are collectively referred to as the Outer IP
header (216) of
the packet 213 while the original IP header 211 is referred to as an Inner IP
header (219) of the
packet 213. To provide additional security to the data being transmitted and
received over the
IPsec Virtual Private Network tunnel, the Inner IP header 219 and the original
data field 212
might be encrypted before transmission by the sending node 113 (or node 117)
and then
decrypted once received by the receiving node 117 (or node 113).
[0037] FIG. 3 is a block diagram that illustrates a preferred format of an
advertisement packet
that is sent or received by a peer node over an IPsec-based Virtual Private
Network tunnel. The
packet 310 typically includes a Universal Datagram Protocol (UDP) header 311,
a protocol
header 312 and a payload 313. The Universal Datagram Protocol header 311
contains the
CA920090026CA 1 9
CA 02680599 2009-10-16
network addresses of sending and receiving nodes. The protocol header 312
contains
information about the protocol version and the type of data being transmitted
over the network.
The various types of data in the protocol header 312 are shown in block 314.
They typically
includes a magic number which is an arbitrary number used by the receiving
node to confirm
that the packet came from another peer node in the Virtual Private Network.
The protocol
version field is used to confirm that both nodes are supporting same network
protocol. The
data type field indicates whether the advertisement packet concerns a new
network connected
to the sending node or a new host in its networks. The protocol header 312
also includes a
packet length field that indicates total size of the packet and the number of
data items in the
packet. The payload 313 contains an advertisement packet 316 which includes a
network ID, a
mask that shows the number of bits in the network ID, and a metric that
represents the network
distance between the newly detected network and the node that sends the
advertisement packet.
The network ID field is typically 32 bits long. The mask and network metric
are typically 8
bits long each. The payload 313 further includes a 32-bit host address field
and a 256-byte host
name field.
[0038) FIG. 4 is a block diagram showing a simple IPsec-based Virtual Private
Network 400 in
which aspects of the invention might be used to automatically configure the
nodes in the
Virtual Private Network. A node X (410) is connected to a primary network 416
and a
secondary network 418. The node X(410) and node Y (411) are two peer nodes in
the Virtual
Private Network 400. The Virtual Private Network 400 is based on an IPsec
tunnel 413 that has
been established over the Internet 414. The trusted primary network 416 (with
IP address
1.2.3.0) and secondary network 418 (with IP address 1.2.4.0) are connected to
the peer node X
(410) through a router 415 (i.e., an internal network interface). The primary
network 416 is
connected to the secondary network 418 through a router 417. A host computer
419 in the
primary network 416, or a host computer 420 in the secondary network 418,
might
communicate to other host computers connected to the networks associated with
the peer node
Y (411) through the IPsec-based VPN 413 between nodes X (410) and Y (411). For
clarity, the
networks and their respective hosts that are associated with the peer node Y
(411) are not
shown in FIG. 4.
CA920090026CA 1 10
CA 02680599 2009-10-16
100391 FIG. 5 is a block diagram illustrating another IPsec-based Virtual
Private Network 500
with multiple IPsec-based tunnels among three peer nodes X, Y and Z, in which
aspects of the
invention might be used to automatically configure the peer nodes. An IPsec
tunnel 514 is
established between node Y (513) and node X (517). Node Y (513) also
communicates with
node Z (516) through an IPsec tunnel 515. Another IPsec tunnel 518 is
established between
node Z (516) and node X (517). Node X (517) is further connected to a trusted
network 519
which is shown with three host computers 520, 521 and 522. The hosts 520, 521
and 522 have
the host names of "Sun", "Moon" and "Earth", respectively.
[0040] The peer node Y (513) is connected to a trusted network 512, which is
shown with two
host computers 510 and 511 having the host names of "Mars" and "Venus",
respectively. The
host "Mars" 510 might securely communicate with the host "Earth" 522 through
peer nodes Y
(513) and X (517), and the IPsec tunnel 514. Alternatively, the hosts "Mars"
510 and "Earth"
522 might communicate with each other through the IPsec tunnel 515 between
peer nodes Y
(513) and Z (516), and the tunnel 518 between peer nodes Z (516) and X (517).
100411 FIG. 6 is a block diagram showing a more complex IPsec-based Virtual
Private
Network 600 in which aspects of the invention might be used to automatically
configure the
peer nodes in the network. The Virtual Private Network 600 is shown with three
primary nodes
X, Y and Z. Node X (614) is connected to a primary network A (613), which in
turn is
connected to a secondary network A1 (611) through a router 612. The secondary
network A1
(611) might have one or more host computers 610. Similarly, the primary node Y
(616) is
connected to a primary network B (620), a secondary network B 1(622), and a
router 621. A
host computer 623 is shown as part of the secondary network B 1(622). The node
Z (618) is
likewise connected to a primary network C (617), a secondary network C l(624),
and a router
625. A host 626 is shown as part of the secondary network C 1(624). Node X
(614) and node
Y (616) communicate with each other through an IPsec tunnel 615 which has been
established
over the Internet 119. Similarly, the IPsec tunnels 627 and 628 are
established between nodes
X and Z, and nodes Z and Y, respectively.
CA920090026CA 1 11
CA 02680599 2009-10-16
[0042] FIG. 7 is a flow chart of an exemplary process for automatically
configuring an IPsec
Virtual Private Network in accordance with the invention. At step 710, an
advertisement
packet sent by a first node in the Virtual Private Network is received by a
second node in the
Virtual Private Network. At step 711, the second node determines whether the
advertisement
packet has originated from the primary network associated with an IPsec peer
node that is
known to the second node. A preferred method for validating the source of the
advertisement
packet is to examine the data records of the Security Policy Database
maintained at the second
node. As described below in reference to Table 1, the Security Policy Database
includes
information about the trusted networks that are connected to the IPsec peer
nodes known to the
second node. This database has continuously been updated with information
about the new
trusted networks as well as their shortest network paths to the sending nodes
as the second node
receives the advertisement packets from the sending nodes in the network.
100431 If the advertisement packet has originated from an IPsec peer node in
the Virtual
Private Network, then the process continues at step 713; otherwise, the
advertisement packet is
discarded at step 712. At step 713, the process determines whether the
advertisement packet
concerns a network associated with a peer node in the Virtual Private Network
or the
advertisement is about a host computer. If the advertisement packet concerns a
host, then the
flow continues with the host name update process at step 714.
[00441 If the advertisement packet concerns a network, then at step 715, the
process
determines whether the information about this network is already in the
Security Policy
Database of the second node. The network information in the advertisement
packet includes
the identification of the network and a metric relating to the number of
intermediary nodes
between this network and the node that has sent the advertisement. If the
information about the
particular network in the advertisement packet is not yet in the Security
Policy Database of the
second node, then this information is added to the Security Policy Database at
step 716.
Otherwise, the process continues at step 717.
[0045] The Security Policy Database of each node in the Virtual Private
Network includes
information on the flow of data traffic between each pair of trusted networks
in the Virtual
CA920090026CA 1 12
CA 02680599 2009-10-16
Private Network. As an example, referring to FIG. 6, the Security Policy
Database for node X
(614) might have data records concerning the data flow between each pair of
trusted networks
known to node X, as shown in Table 1.
Pairs Of Trusted Networks Known to Node X Data Flow Information
A to B, A to B 1, Al to B, Al to B 1 SEND via Tunnel X-Y
B to A, B 1 to A, B to Al, B 1 to Al RECEIVE from Tunnel Y-X
A to C, A to Cl, Al to C, Al to Cl SEND via Tunnel X-Z
C to A, Cl to A, C to Al, Cl to Al RECEIVE from Tunnel Z-X
Table 1.
[0046) At step 717, the process determines whether the advertisement packet
includes
information about a shorter network path between this particular network and
the sending (first)
node that has not been known to the second node. The determination of the
network path
length of a network being processed is described below in reference to FIG. 8.
If the
advertisement packet indicates a network path that is not shorter that what
currently shown for
this network in the Security Policy Database of the second node, then the
advertisement packet
is discarded at step 718. Otherwise, the current data record concerning the
network path for the
subject network in the Security Policy Database of the second node is updated
with the
information about the shorter path, as shown in the advertisement packet, at
step 719.
CA920090026CA 1 13
CA 02680599 2009-10-16
[0047] As an example, consider the Virtual Private Network 600 shown in FIG. 6
that was
described previously. Assume that the peer node Y (616) receives an
advertisement packet
from the peer node X (614), and the packet concerns the secondary network Al
(611)
associated with the node X (614). Assume further that the Security Policy
Database of node Y
(616) currently contains a record on the shortest path to the secondary
network Al (611) that is
known to node Y (616) as the path through node Z (618); i.e., the path through
the IPsec
tunnels 627 and 628. Since the new path from network Al (611) to node Y
(through the tunnel
615) is shorter than the previously known path (through node Z), the record
for the network Al
(611) in the Security Policy Database of node Y (616) will be updated with the
new path
through node X (614).
[0048] A preferred method for evaluating a network path might be based on a
network metric
corresponding to the path between a network in the Virtual Private Network and
a particular
node. The metric preferably represents the number of intermediary nodes
between this network
and the node that is sending the advertisement packet.
100491 FIG. 8 is a flow chart of an exemplary process for updating the host
names known to a
peer node in the Virtual Private Network. This process continues from step 715
in FIG. 7. At
step 810, the process determines whether the host name in the advertisement
packet is for a
host in a trusted network connected to a peer node in the Virtual Private
Network. As an
example, refer again to the Virtual Private Network 500 shown in FIG. 5.
Assume that the peer
node X (517) is processing an advertisement packet that has originated from
the peer node Y
(513) concerning the "Mars" host computer 510. Since the "Mars" host 510
belongs to the
trusted network B (512) connected to the peer node Y (513), the receiving node
X (517)
concludes that the host name "Mars" is for a host in a trusted network of a
peer node (i.e., node
Y) in the Virtual Private Network 500. In this case, the host name "Mars"
would be added to a
local list of host names maintained at the peer node X (517), which is the
"Earth" host 522 in
the example, at step 811. Otherwise, the advertisement packet is discarded at
step 812.
100501 In order to avoid data fragmentation, each advertisement packet might
be split into a
number of Universal Datagram Protocol (UDP) packets. Each UDP packet is
smaller than the
CA920090026CA 1 14
CA 02680599 2009-10-16
maximum transmission unit (MTU) being used by the network communication
protocol. The
User Datagram Protocol is one of the protocols used for the Internet. It
allows computer
applications to send messages, referred to as diagrams, to other hosts on an
Internet Protocol
(IP) network without requiring prior communications to set up special
transmission channels or
data paths.
[0051] The subject matter described above is provided by way of illustration
only and should
not be construed as limiting. Various modifications and substitutions of the
described
components and operations can be made by those skilled in the art without
departing from the
spirit and scope of the present invention defined in the following claims, the
scope of which is
to be accorded the broadest interpretation so as to encompass such
modifications and
equivalent structures. As will be appreciated by those skilled in the art, the
systems, methods,
and procedures described herein can be embodied in a programmable computer,
computer
executable software, or digital circuitry. The software can be stored on
computer readable
media. For example, computer readable media can include a floppy disk, RAM,
ROM, hard
disk, removable media, flash memory, a "memory stick", optical media, magneto-
optical
media, CD-ROM, etc.
CA920090026CA 1 15
