SYSTEMS AND METHODS FOR IMPLEMENTING A QUANTUM - CRYPTOGRAPHIC COMMUNICATIONS NETWORK
TECHNICAL FIELD
The present invention relates generally to systems and methods for maintaining secure communications in communications networks and, more particularly, to systems and methods for maintaining secure communications in communications networks using quantum- cryptographic techniques.
BACKGROUND
Conventional packet-switching networks permit cheap and reliable communications independent of the distance between a source node and a destination node in the network. These conventional networks often rely upon either public keys or shared private keys to provide privacy for messages that pass through the network's links. Public keys have the drawback that they have never been proven to be difficult to decipher. Therefore, it is possible that a method of efficiently cracking public keys may one day be discovered. Such a discovery would make all public key technology obsolete. All supposedly "secure" networks based on public key technology would thus become vulnerable. Shared private keys also have the drawback that the logistics of distributing the private keys can be prohibitive. Quantum cryptography represents a recent technological development that provides for the assured privacy of a communications link. Quantum cryptography is founded upon the laws of quantum physics and permits the detection of eavesdropping across a link. Quantum cryptography, thus, ensures the security of keys distributed across the link. Quantum cryptographic techniques have been
conventionally applied across single links in a network. Quantum cryptography requires the reliable transmission and receipt of single photons for distributing encryption/ decryption keys. However, single photons cannot be reliably transmitted over large distances. Single quantum cryptographic links are, therefore, distance limited. For example, a single quantum cryptographic link cannot be any longer than some tens of miles when transmitting through fiber optic cabling.
Therefore, there exists a need for a system and method that combines the assured privacy achieved with quantum cryptography with the distance independent communication achieved with conventional multi-node, multi-link packet switching networks.
SUMMARY
Systems and methods consistent with the present invention address this need by implementing a quantum-cryptographic communications network that permits privacy assured communication over long distances. The communications network of the present invention implements quantum cryptographic techniques that can ensure the privacy of encrypted data transmitted across multiple nodes and links within a packet-switching network. A host can thus send encrypted data in a quantum-cryptographic communications network consistent with the present invention and be assured of the security of the data received at a destination host.
In accordance with the purpose of the invention as embodied and broadly described herein, a method of maintaining link security information in a network includes transmitting link state information from a first node to a second node across an intervening link. The link state information includes a link security indicator that indicates the security of the link. The method further includes receiving the link state information at the second node. The method additionally includes updating a forwarding table stored in a memory of the second node to
indicate that the link is at least one of secure and un-secure based on the link security indicator.
In another implementation consistent with the present invention, a method of forwarding a message received at a node in a network includes receiving a message at the node, the message including data indicating link security requirements of the message. The method further includes forwarding the message over at least one of a secure and an un-secure link based on the data.
In a further implementation consistent with the present invention, a method of indicating security requirements of a message in a network, including a plurality of nodes interconnected by a plurality of links, includes receiving a message at a node in the network, determining whether the message requires protected links in the network, marking the message as secure if the message requires protected links, marking the message as un-secure if the message does not require protected links, transmitting the message across protected links in the network if the message is marked as secure, and transmitting the message across unprotected links in the network if the message is marked as un-secure.
BRIEF DESCRIPTION OF THE DRAWINGS
The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate an embodiment of the invention and, together with the description, explain the invention. In the drawings, FIG. l illustrates an exemplary network consistent with the present invention;
FIG. 2 illustrates exemplary components of a host/router consistent with the present invention;
FIG. 3 illustrates an exemplary database stored in memory of a host/router consistent with the present invention;
FIG. 4 illustrates an exemplary forwarding table consistent with the present invention;
FIG. 5 illustrates an exemplary protected link forwarding table consistent with the present invention;
5 FIG. 6 illustrates exemplary components of a quantum cryptographic (QC) link interface consistent with the present invention;
FIG. 7 illustrates an exemplary database stored in memory of a quantum cryptographic link interface consistent with the present invention; l o FIG. 8 illustrates exemplary system processing for QC-link initialization consistent with the present invention;
FIGS. 9-10 illustrate exemplary system processing for QC-link security detection consistent with the present invention;
FIG. li illustrates exemplary link state distribution consistent with 15 the present invention;
FIG. 12 illustrates exemplary system processing for transmitting a host message consistent with the present invention;
FIGS. 13-15 illustrate exemplary system processing for transmitting an encrypted message from a source host to a destination host in a 20 quantum cryptographic network; and
FIG. 16 illustrates exemplary system processing for forwarding a message received at a router in a quantum cryptographic network.
DETAILED DESCRIPTION
25 The following detailed description of the invention refers to the accompanying drawings. The same reference numbers in different drawings identify the same or similar elements. Also, the following detailed description does not limit the invention. Instead, the scope of the invention is defined by the appended claims.
Systems and methods, consistent with the present invention, permit the implementation of quantum cryptographic techniques in multi-node packet-switching networks. In quantum cryptography, encryption keys are derived from random bit sequences that are encoded in the 5 phase/polarization states of single photons transmitted from one node to the next. Based on the known Heisenberg Uncertainty principle, any attempt to eavesdrop upon the transmitted encryption keys will induce error rates in the received encryption keys that can be detected at the receiving node. Quantum cryptography can thus detect eavesdropping, l o and in accordance with the present invention, provide link security information that can be used in forwarding encrypted messages across a network.
EXEMPLARY NETWORK
FIG. l is a diagram of an exemplary quantum cryptographic
15 network (QC-network) 100 implementing quantum cryptographic techniques in accordance with the present invention. Network 100 includes routers 105, 110, 115, 120 and 125 and hosts 135, 140, 145 and 150 interconnected via links 152 - 178. Routers 105, 110, 115, 120 and 125 can include Internet routers, multi-protocol routers, Ethernet
20 switches, ATM switches or the like. Routers 105, 110, 115, 120 and 125 can further include "trusted" routers that are either installed in secure facilities or constructed with high-assurance software and hardware for the prevention of tampering. Hosts 135, 140, 145 and 150 can include personal computers, telephones based on microprocessors (e.g., cellular
25 telephones, voice over IP telephones), computer game machines (e.g., Gameboy), small network-resident devices (e.g., thermostats, sensors, actuators, or other network appliances) or the like. Links 152- 178 may comprise one or more wireless, wire-line, or optical links. The number of hosts, routers and specific link connections shown in FIG. 1 are for
30 illustrative purposes only. One skilled in the art will recognize that QC- network 100 can include any number of hosts and routers and any number of link connections between the hosts and routers.
In the exemplary network illustrated in FIG. 1, host 135 (node A) connects to router 105 (node B) via link 152. Router 105 connects to router 110 (node C), router 120 (node F), and router 125 (node G) via links 154? 156 and 178, respectively. Router 110 connects to routers 115 (node D) and 125 (node G) via links 158 and 160, respectively. Router 115 connects to host 140 (node E) and router 125 via links 162 and 164, respectively. Host 140 connects to router 125 via link 166. Router 120 connects to router 125 and local area network (LAN) 180 via links 168 and 170, respectively. Router 125 connects to LAN 180 via link 172. Hosts 145 (node H) and 150 (node I) connect to LAN 180 via links 174 and 176, respectively. Links 154, 170 and 178, shown as dashed links in FIG. 1, depict links unprotected by quantum cryptographic techniques. All other links, shown as solid lines in FIG. 1, depict links protected by quantum cryptographic techniques. EXEMPLARY HOST/ROUTER
FIG. 2 illustrates components of an exemplary router 105 in which quantum cryptographic techniques can be implemented. Routers 110, 115, 120 and 125 and hosts 135, 140, 145 and 150 may be similarly configured to router 105. Router 105 may include a processing unit 205, a memory 210, an input device 215, an output device 220, one or more network interfaces 225, one or more quantum cryptographic link interfaces (QCLI 1 230 - QCLI N 235) and a bus 240.
Processing unit 205 may perform all data processing functions for inputting, outputting, and processing of data. Memory 210 may include Random Access Memory (RAM) that provides temporary working storage of data and instructions for use by processing unit 205 in performing processing functions. Memory 210 may additionally include Read Only Memory (ROM) that provides permanent or semi-permanent storage of data and instructions for use by processing unit 205. Memory 210 can include large-capacity storage devices, such as a magnetic and/or optical recording medium and its corresponding drive.
Input device 215 permits entry of data into router 105 and includes a user interface (not shown). Output device 220 permits the output of data in video, audio, or hard copy format. Network interface(s) 225 interconnect router 105 with QC-network 100 via links unprotected by quantum cryptographic techniques. QCLI 1 230 through QCLI 235 interconnect host 135 with network 100 via links protected by quantum cryptographic techniques. Bus 240 interconnects the various components of router 105 to permit the components to communicate with one another.
EXEMPLARY ROUTER DATABASE FIG. 3 illustrates an exemplary database 300 stored in memory 210 of router 105. Database 300 may include an optional Application Programmer Interface (API) 305, a routing engine 310, an optional forwarding engine 315, a forwarding table 320, and a protected link forwarding table 325. API 305 includes sequences of instructions for execution by processing unit 205 that interface conventional network transport protocols to application programs being executed by processing unit 205. API 305 defines the syntax for communication between the conventional network transport protocols and the application programs. Routing engine 310 includes sequences of instructions for execution by processing unit 205. Among other functions, these instructions determine how network traffic received at router 105 should be directed to other nodes in QC-network 100. Routing engine 310 also includes instructions for monitoring the conditions of the links in QC-network 100, exchanging control messages with peer routing engines of other nodes in QC-network 100 and building forwarding tables that can be used to direct received messages towards their intended destination nodes.
Forwarding engine 315 includes sequences of instructions for execution by processing unit 205. Among other functions, these instructions perform the processing involved in forwarding message traffic through the appropriate interface of router 105 and toward the
appropriate next-hop in QC-network 100.
Forwarding table 320 includes a table of destination nodes in network 100 and an indication of a next hop for a message to reach each destination node via either protected or unprotected links. Forwarding table 320 may also include a QC-link protection variable associated with each next hop indicating whether the message will traverse an unprotected or a protected link if forwarded on to the indicated next hop to reach a destination node.
Protected link forwarding table 325 includes a table of destination nodes in network 100 and an indication of a next hop for a message to reach each destination node via protected links. If QC-network 100 handles only secure message traffic, then database 300 may only store protected link forwarding table 325. Database 300 would not require forwarding table 320. EXEMPLARY FORWARDING TABLE
FIG. 4 illustrates an exemplary forwarding table 320 containing data for forwarding packet data, received at router 105 (node B), to any other node within QC-network 100 via either protected or unprotected links. Forwarding table 320 may include next hop entries 405 and QC- link protection variable entries 410 indexed to destination node entries
415. Destination node entries 415 indicate the destination nodes reachable from the current node (e.g., node B). Next hop entries 405 indicate the next node to which the current node should forward a message to reach a desired destination node. QC-link protection variable entries 410 indicate the protective state of the link between a current node and a next hop node.
EXEMPLARY UNPROTECTED LINK FORWARDING TABLE
FIG. 5 illustrates an exemplary protected link forwarding table 325 containing data for forwarding packet data, received at router 105 (node B), to any other node within QC-network 100 via only protected links.
Protected link forwarding table 325 may include next hop entries 505 and QC-link protection variable entries 510 indexed to destination node entries 515. Destination node entries 515 indicate the destination nodes reachable from the current node (e.g., node B). Next hop entries 505 indicate the next node to which the current node should forward a message to reach a desired destination node. QC-link protection variable entries 510 indicate the protective state of the link between a current node and a next hop node.
EXEMPLARY QUANTUM CRYPTOGRAPHIC LINK INTERFACE FIG. 6 is a diagram illustrating exemplary components of quantum cryptographic link interface QCLI 1 230. Other QCLI's in routers 105, 110, 115, 120 and 125 may be configured similarly to router QCLI 230 shown in FIG. 6. QCLI 230 may include an optional memory 605, an optional processing unit 610, a photon source 615, a phase/polarization modulator 620, a photon detector 625, a photon evaluator 630, and a bus 205.
Memory 605 may include RAM that provides temporary working storage of data and instructions for use by processing unit 205 in performing processing functions. Memory 605 may additionally include ROM that provides permanent or semi-permanent storage of data and instructions for use by processing unit 610. Memory 605 may include large-capacity storage devices, such as a magnetic and/or optical recording medium and its corresponding drive.
Processing unit 610 may perform all data processing functions for inputting, outputting, and processing of data, including execution of instructions stored in memory 605 or memory 210 for implementing conventional quantum cryptographic protocols.
Photon source 615 can include, for example, a conventional semiconductor laser. Photon source 615 produces photon signals according to instructions provided by either processing unit 610 or processing unit 205.
Phase/polarization modulator 620 can include, for example, conventional semiconductor phase modulators or conventional liquid crystal polarization modulators. Phase/polarization modulator 620 encodes outgoing photon signals from photon source 615 according to commands received from processing unit 605 or processing unit 205 for transmission across conventional quantum cryptographic key (QC-key) or traffic channel(s).
Photon detector 625 can include, for example, conventional avalanche photo diodes (APDs) or conventional photo-multiplier tubes (PMTs). Photon detector 625 detects photon signals received across conventional QC-key or traffic channel(s) from other QCLI's in QC-network 100.
Photon evaluator 630 can include conventional circuitry for processing and evaluating output signals from photon detector 625 in accordance with conventional quantum cryptographic techniques.
EXEMPLARY QUANTUM CRYPTOGRAPHIC LINK INTERFACE DATABASE
FIG. 7 illustrates an exemplary database 700 that may be stored in memory 605 of QCLI 230. Database 700 may optionally include Application Programmer Interface (API) 305 and may further include quantum cryptographic protocols 705.
Quantum cryptographic protocols 705 include all protocols for implementing quantum cryptographic encryption across a link connected to router 105. These conventional protocols are known to one-skilled in the art. As such, they will not be described in further detail herein. EXEMPLARY QC-LINK INITIALIZATION PROCESSING
FIG. 8 illustrates a flowchart of exemplary quantum cryptographic link initialization processing consistent with the present invention. The initialization processing shown in FIG. 8 establishes the operational status of a quantum cryptographic link between any two QC-nodes in network 100. As one skilled in the art will appreciate, the method exemplified by
FIG. 8 can, for example, be implemented as a sequence of instructions and stored in memory 210 of router 105 for execution by processing unit 205.
Initialization processing begins with each QC-node in network 100 preparing a unique identifier for identifying itself [step 805]. This identifier may be preset in memory 210 by the node manufacturer, selected by a node administrator, derived from a random or pseudorandom process, or derived by any other appropriate method. Each QC- node then transmits its unique identifier to all connected nodes over a traffic channel [step 810]. Transmission of the unique identifier from each QC-node may be repeated, staggered in time, or acknowledged in accordance with conventional message transmission techniques.
Each QC-node in network 100 waits a fixed period of time to receive all unique identifiers transmitted from connected nodes [step 815]. This fixed period of time may be preset or periodically updated according to network topology. Each QC-node selects a "master" node according to an algorithm common to all nodes in network 100 [step 820]. The common algorithm can, for example, determine which identifier of all of the identifiers received from connected nodes is the arithmetic minimum. Other algorithms will be apparent to one skilled in the art for selecting an identifier from a set of identifiers received from nodes connected to a node in network 100.
Each QC-node then marks an internal database in its QCLI that the master node has the selected identifier [step 825]. The QC-node with the selected identifier then begins acting as the master node and all other connected nodes begin to act as slave nodes. The node acting as the master node transmits the QC key to the slave nodes. The slave nodes perform the quantum cryptographic algorithms that enable the link to function.
EXEMPLARY QC-LINK SECURITY DETECTION PROCESSING
FIGS. 9-10 illustrate flowcharts of exemplary quantum cryptographic link security detection processing consistent with the present invention. The processing illustrated in FIGS. 9-10 uses
conventional quantum cryptographic protocols to determine if eavesdropping has occurred on a link attached to a given QCLI or whether there has been a QCLI or link failure.
Link security detection processing begins with a QCLI (e.g., QCLI 230 of router 105 connected to link 154 acting as a "master") transmitting a sequence of photons in accordance with conventional quantum cryptographic protocols [step 905] (FIG. 9). A receiving QCLI (e.g., a QCLI of router 110 acting as a "slave") receives the transmitted photons and evaluates the phase and/or polarization of the photons using conventional quantum cryptographic protocols [step 910]. Based on the evaluation, the receiving QCLI determines, using conventional quantum cryptographic protocols, if eavesdropping has occurred on the link [step 915].
For example, QCLI 230 of router 105 can randomly generate and store a sequence of phase or polarization values (e.g., 0, 45, 90 or 135 degree values for polarization) and apply these values, via phase/polarization modulator 620, to a sequence of photons produced by photon source 615. After transmission across link 154, the receiving QCLI of router 110 receives each photon at photon detector 625 and measures each photon's polarization or phase. The QCLI of router 110 then reports the measurement results back to the QCLI of router 105. If no eavesdropping has occurred on link 154, then the measured polarization or phase of each photon received at the QCLI of router 110 should correspond to the actual polarization or phase of each photon transmitted from the QCLI of router 105. Based on quantum physics, however, if a rate of error in the measured polarization or phases of received photons exceeds a certain threshold, then eavesdropping on link 154 is indicated and can be noted at the QCLIs of routers 105 and 110. The above described eavesdropping detection technique merely represents one possible example of conventional quantum cryptographic eavesdropping detection. One skilled in the art will recognize that other conventional QC-techniques may be equivalently used. Furthermore, the various links in QC-network 100 can each be protected by different quantum cryptographic
techniques, as long as each QCLI at either end of a given link are compatible. Thus, each node in QC-network 100 can "bridge" differing quantum encryption technologies.
Returning to FIG. 9, if conventional QC-protocols indicate that eavesdropping has occurred on the link, processing proceeds to step 935 below. If there has been no eavesdropping, the QCLI of router no then determines if there has been a failure of the QCLI itself [step 920]. For example, QCLI hardware and/or software failures may be noted at processing units 205 or 610 using conventional error messages. If there has been no QCLI failure, the QCLI of router 110 may further determine if there has been a link failure on the quantum key channel [step 925]. For example, the receiving QCLI may note the complete cessation of key transmissions over a link and conclude that the link has failed. If the QCLI of router 110 determines that there has been a link failure, processing proceeds to step 935 described below. If there has been no link failure, the receiving QCLI sets the QC-link protection variable to "protected" and updates the appropriate entries of forwarding tables 320 and 325. At step 935, the receiving QCLI sets the QC-link protection variable to "unprotected" and updates the appropriate entries of forwarding tables 320 and 325.
At step 1005 (FIG. ιo), the QCLI of router 110 reports the QC link protection variable to the routing engine 310 being executed in processing unit 205. Routing engine 310 then distributes the QC-link protection variable to other nodes in network 100 [step 1010]. Additionally, the router with the receiving QCLI may report the QC link protection variable to a network management entity responsible for administering QC- network 100 [step 1015]. The network management entity can store the QC link protection variable in a centralized database [step 1020] and signal an alarm if the received QC link protection variable indicates a link is unprotected [step 1025].
EXEMPLARY FORWARDING TABLE UPDATE PROCESSING
FIG. 11 illustrates a flowchart of exemplary forwarding table update processing consistent with the present invention. In accordance with conventional routing protocols, a node (e.g., router 105) in QC-network 100 receives link state information from other nodes [step 1105]. The node 105 extracts a QC-link protection variable from the received link state information [step 1110]. If QC-network 100 handles only secure traffic, node 105 may then update protected link forwarding table 325 based on the extracted QC-link protection variable [step 1115]. For example, node 105 may remove a link from service using conventional routing techniques if the extracted QC-link protection variable indicates that the link is unprotected.
Node 105 then may update forwarding table 320 and/or forwarding table 325 by storing the extracted QC link protection variable with the appropriate node in either forwarding table [step 1120]. As an example, during QC-link security detection processing (describe above), router 125 (node G) determines that eavesdropping has occurred on the link between it and host 140 (node E). Router 125 therefore distributes an "unprotected" QC-link protection variable to other nodes in QC-network 100. The nodes that receive the link state information containing the
"unprotected" QC-link protection variable update their forwarding tables accordingly.
EXEMPLARY HOST MESSAGE PROCESSING
FIG. 12 illustrates a flowchart of exemplary host message transmission processing consistent with the present invention. A host (e.g., host 135) in QC-network 100 receives a message from input device 215 [step 1205]. In response thereto, the host 135 determines whether the message requires protected links [step 1210]. For example, a host operator may specify, via input device 215, that the received message contains highly sensitive information and therefore requires protected links. If the message does not require protected links, the host 135 inserts an "un-
secure" marking in the header of the message [step 1220]. For example, the host may insert an "un-secure" marking in a "type of service" (TOS) indicator in the message header. However, if the message does require protected links, the host 135 inserts a "secure" marking in the header of the message [step 1215]. The host 135 completes the message processing by transmitting the message towards the intended destination node [step 1225] .
EXEMPLARY QC-NETWORK END-TO-END MESSAGE PROCESSING
FIGS. 12-14 illustrate flowcharts of exemplary end-to-end quantum cryptographic network message transmission processing, consistent with the present invention, in the case where the source host requests transmission across protected links in a QC-network, such as QC-network 100. A source host (e.g., host 135) formulates a message for transmission, using for example, user input from input device 215 [step 1305]. The source host 135 then may optionally encrypt the formulated message [step 1310]. The host 135 may, for example, apply end-to-end encryption to the formulated message in accordance with conventional encryption techniques. The source host 135 then passes the message to the QCLI, such as QCLI 230 [step 1315]. The source host's QCLI 230 applies QC-link encryption to the message [step 1320]. The QCLI 230 may apply any conventional quantum cryptographic encryption technique. The source host's QCLI 230 then transmits the QC-link encrypted message on the QCLFs traffic channel [step 1325].
At step 1330, a router (e.g., router 105) in QC-network 100 receives the QC-link encrypted message on a traffic channel [step 1330]. The router's QCLI decrypts the QC-link encrypted message using conventional quantum cryptographic decryption techniques [step 1335]. The router's QCLI passes the message to the router's forwarding engine 315 [step 1405] (FIG. 14). At step 1410, the router's forwarding engine 315 determines a next hop for the message using information from protected link forwarding
table 325 [step 1410]. The router's forwarding engine 315 passes the message to an appropriate outgoing QCLI [step 1415]. The outgoing QCLI applies QC-link encryption to the message [step 1420]. The router's QCLI transmits the link-encrypted message on the QCLI's traffic channel to the 5 next hop node determined by forwarding table 325 [step 1425].
When the next hop node receives the message, the node determines if it is the message's intended destination host [step 1430]. For example, the next hop node may compare the destination address in the message header with the address assigned to the next hop node. If the next hop node o determines that it is not the destination host, processing returns to step 1410 above. If the next hop node determines that it is the intended destination host, then the host's QCLI decrypts the QC-link-encrypted message using conventional quantum cryptographic techniques [step 1505]- The destination host's QCLI passes the decrypted message to 5 processing unit 205 [step 1510]. The destination host then may optionally decrypt any end-to-end encryption applied at the source host [step 1515]. The processing unit 205 of the destination host then receives the decrypted message [step 1520].
EXEMPLARY ROUTER FORWARDING PROCESSING 0 FIG. 16 illustrates a flowchart of exemplary router forwarding processing consistent with the present invention. A router (e.g., router 105) in QC-network 100 receives an incoming message either from another router or from a host [step 1605]. In one exemplary embodiment of the present invention, QC-network 100 may only handle secure 5 messages and no secure/un-secure "type of service" marking may therefore be included in message headers. Therefore, if QC-network 100 handles only secure traffic [step 1610], processing continues at step 1625. If QC-network 100 handles both secure and un-secure traffic, processing continues at step 1615. 0 At step 1615, the router 105 inspects the "type of service" (TOS) indicator in the message header [step 1615]. The router 105 determines
whether the TOS indicates that secure links are required for transmission of the message [step 1620]. If secure links are not required, the router's forwarding engine 315 determines the next hop for the message using forwarding table 320 [1630]. However, if secure links are required, the router's forwarding engine 315 determines the next hop for the message using protected link forwarding table 325 [step 1625]. The router's forwarding engine 315 then forwards the message towards the determined next hop [step 1635].
CONCLUSION Systems and methods consistent with the present invention implement quantum cryptographic techniques that can ensure the privacy of encrypted data transmitted across multiple nodes and links within a packet-switching network. A host can thus send encrypted data in a quantum-cryptographic communications network consistent with the present invention and be assured of the security of the data received at a destination host.
The foregoing description of exemplary embodiments of the present invention provides illustration and description, but is not intended to be exhaustive or to limit the invention to the precise form disclosed. Modifications and variations are possible in light of the above teachings or may be acquired from practice of the invention. No element, step, or instruction used in the description of the present application should be construed as critical or essential to the invention unless explicitly described as such. The scope of the invention is defined by the following claims and their equivalents.