Title of Invention

A METHOD FOR LOAD SHARING USING IPV6 ANYCAST ADDRESSING

Abstract

The present invention mainly focuses on the efficient utilization of the anycasting technique available with IPv6. Although anycasting is already an improvement over its predecessor the multicasting of IPv4 but still there are a limitations in its use. In the present invention, a protocol is designed whereby these limitations are overcome hence enabling the Anycast service provider to install the servers in cost effective way on same network without rejecting or canceling any of the requests due to overloading. In IPv6, an Anycast Address is assigned to more than one interface (typically belonging to different nodes), with the property that a packet sent to an Anycast address is routed to the "nearest" Anycast Member, according to the routing protocols' measure of distance. Hence, the request from the service user always goes to the nearest Anycast Member/Server ir~espective of its current load, as per the current routing protocol behavior/architecture. So, this new method provides Load Sharing between the Anycast Members belonging to same Anycast Group. This method also provides extensions to the existing protocols to maintain the Anycast Member List with all Anycast Members.

Full Text

FIELD OF INVENTION This invention relates to the field of IPv6 technology and Anycast communication in IPv6. Further this invention relates to a method of Load Sharing for Ipv6 Anycast Addressing. More particularly this invention compasses an efficient method for load sharing between servers using IPv6 anycast addressing. IPv6 is the Next Generation Network Layer Protocol that surpasses the shortcomings of its predecessor IPv4. DESCRIPTION OF THE RELATED ART An IPv6 Anycast address is an address that is assigned to more than one interface (typically belonging to different nodes), with the property that a packet sent to an Anycast address is routed to the "nearest" interface having that address, according to the routing protocols* measure of distance. Hence, the request from the service user always goes to the nearest Anycast Member/Server irrespective of its current load, as per the current routing protocol behavior/architecture. Anycast is contra distinct from multicast and unicast in that, any packet sent to an Anycast address is routed to the 'nearest' interface having that address (Anycast member), nearest from the routing protocols' measure, unlike multicast where it is sent to all the members of multicast group. The [ADDR_ARCH] introduces the concept of Anycast Addressing and its use in IPv6. But, it restricts the Anycast Address assignment to only Routers. The [ANALYSIS] has brought out the issues/problems with Anycast for hosts. Anycasting in IPv4 follows [H0STANYv4] for the registration and de-registration purpose using IGMP. The same concept has been brought into IPv6 by [H0STANYv6], The current Routing Architecture does not treat Anycast addresses as different from unicast address. Hence, the packets destined to an Anycast Address always reach the nearest Anycast Member. This invention is based on the assumption that Anycast addressing can be used for Hosts also. In the existing IPv6 networks the Anycast packets are always delivered to the nearest Anycast Server based on the routing protocols' measure of distance. The Anycast address is generally used to identify a particular service and after identifying a server that can provide the service, the unicast address of the server is used for the intended communication. LIMITATIONS The current routing architecture and anycast addressing in combination has the following limitations: a. The routers always deliver the packets to the nearest Anycast Member (the one that has first given the response for Neighbor Discovery by router, in case two anycast members are on same-link) irrespective of its current load, so there is no Load Sharing among the Anycast member Group. The other Anycast Members are idle. The new request to an overloaded Anycast member will be dropped, even though the other group members can service the request. b. The Anycast members do not have knowledge of other members of the same Anycast address group and hence the members cannot communicate with each other for sharing the load. c. With the existing Architecture, the Anycast Service Provider will not be able to utilize his network infrastructure fully and therefore the returns on investment are considerably low. d. The service provider needs to distribute the Anycast Servers geographically based on distribution of customer density, whereby the infrastructure and deployment cost is substantially increased. OBJECTS OF THE INVENTION It is the primary object of the invention to provide a method for communication between Anycast Members for load sharing using IPv6 Anycast addressing. It is another object of the invention to mal^e IPv6 anycast address members to have the knowledge of other anycast members. It is another object of the invention to provide a method of anycast group management with the provision that router and anycast members l^now about other members of the same anycast address. SUMMARY OF THE INVENTION Anycast Communication is one of the features that IPv6 supports better than its predecessor IPv4, In IPv6, an Anycast Address is assigned to more than one interface (typically belonging to different nodes), with the property that a packet sent to an Anycast address is routed to the "nearest" Anycast Member, according to the routing protocols* measure of distance. Hence, the request from the service user always goes to the nearest Anycast Member/Server irrespective of its current load, as per the current routing protocol behavior/architecture. So, this new method provides Load Sharing between the Anycast IVIembers belonging to same Anycast Group. This method also provides extensions to the existing protocols to maintain the Anycast l\/1ember List with all Anycast IVIembers. The other objects, features and advantages of the present invention will be apparent from the accompanying drawings and the detailed description as follows: Operation of the Invention Load sharing Using IPv6 Anycast Addressing A node, which is configured to serve as an Anycast member, needs to register with its on-iink Router, If there are other members that are already registered for this Anycast address, the Router updates the newly joining Anycast members. This method ensures that the nodes belonging to particular Anycast service can access Information about all other members of the same Anycast group. All members of an Anycast Group are required to join the Solicited Node Multicast Address derived from the Anycast Address, so that the router can send updates to all the members of the Anycast Group. The scope of this IVIulticast should be dependent on how the Anycast address members are distributed. If it is a Centralized Anycast Cluster management and all Anycast Members are on a single linl The service user, who wants to find and use the service, will send the service request (e.g. TCP - SYN Segment) to the Anycast address. The request goes to the nearest Anycast member as per normal routing. The Anycast member will check the requirements for this service and compares against its current load [Section 1- Load Balancing Trigger]; If the server is already fully loaded and cannot service the user, it identifies the next nearest Anycast Member belonging to same Anycast Group [Section 2 - Member Selection Algorithm] and forwards the request with Routing Header Type Zero, so that the higher layers (Layer 4 and Applications) at the next Anycast member will treat this request as if it is coming directly from the Service User [Section 3 - FonA^arding the request and Transparency to the upper layers]. The next nearest member receives the forwarded request and after processing the Routing Header and checks if it can service the request. If this member is also overloaded, it fonA/ards the request to the next nearest member. While fonA/arding the request, the forwarding Anycast Member includes its own unicast address as well as the addresses of the previous Anycast members who have fonwarded the request, so that the receiving Anycast Member knows where the request is coming from and will not foHA/ard the request to these members. This method prevents the loops in forwarding the request. If all the members in this group are fully loaded then the request will be dropped. The IPv6 Layer gives to the upper layer, if the current load permits, the new user request. Then the higher layers send the service response (e.g. TCP - SYN + ACK, probably with Source Identifier Option) and, the further communication goes on with unicast address in the traditional manner. BRIEF DESCRIPTION OF THE ACCOMPANYING DRAWINGS ' Further description of the invention is given with reference to the accompanying drawings. Figl: relates to Current Distributed Anycast Cluster Management; Fig 2 : relates to Current Centralized Anycast Cluster Management; Fig 2A : relates to Current Anycast Address Resolution; Fig 3 : relates to Current Anycast member registration and router behaviour; Fig 4 : relates to Current Anycast member De-registration and router behaviour; Fig 5 : relates to Distributed Anycast Cluster Management, with this invention; Fig 6 : relates to Centralized Anycast Cluster Management, with this invention; Fig 7 : relates to Anycast Member Registration and Router, with this invention; Fig 8 : relates to Anycast Member De-Registration and Router, with this invention; Fig 9 : relates to Load Sharing between Anycast members, with this invention. DETAILED DESCRIPTION OF THE INVENTION 1, Load Balancing Trigger The decision whether a node can process the received request or not, can be based on how many more packets per second a node can process with current load. If the current rate of processing is beyond a threshold value, it means that it is already loaded and cannot process any more. The threshold value should be configurable by administrator. There can be different mechanisms and parameters for different kinds of services to determine if this node can serve the new request. Load balancing Trigger can also be raised from Transport Layer if it Is connection-oriented protocol. It can be decided upon how many sessions are actively running now. If the number of opened sessions is beyond a certain threshold value, it means that it is already loaded and cannot process any more. The threshold value should be configurable by administrator. However, the load balancing trigger from the network layer is preferred because of Transparency to the upper layers and total processing capacity is more accurate at networl 2. Member Selection Algorithm Legend for the algorithm: AA - Anycast address of the received request UAr- Unicast Address of the node, which is currently processing the Anycast request UAm - Unicast address of the Anycast Member Set "Next Anycast Member List" to empty. For each Anycast Member *m' in Anycast member database of 'AA' other than 'UA' If UAm is not in Routing Header Address List AND IF UAm and UAr are of same scope then ADD UAm to 'Next Anycast Member List'. IF 'Next Anycast Member List' is EMPTY For each Anycast Member 'm' in Anycast member database of 'AA' other than 'UA' If UAm is not in Routing Header Address List AND IF scope of UAm is greater than scope of UAr then ADD UAm to 'Next Anycast Member List'. IF 'Next Anycast Member List' is EMPTY Report FAILURE Select the Longest Prefix Match from 'Next Anycast Member List' as compared with 'UAr'. Report the selected Address. 3. Forwarding the request and Transparency to the upper layers If the Load Balancing Trigger informs to fonA/ard the request, the request will be foHA^arded to the next nearest Anycast Member [Section 2 - Member Selection Algorithm] with the Routing Header constructed as follows: If the received request does not have ROUTING HEADER TYPE ZERO, It means this is the first Anycast member to receive the request. Include Routing Header Type Zero, with the following: Destination Address = Next Nearest Anycast Member Address Routing Header Address [1] = Its Unicast Address UAr Routing Header Address [2]= Anycast Address, AA If the received request has already got ROUTING HEADER TYPE ZERO, It means some other Anycast member has forwarded this request to this Anycast member. And, this Anycast member is going to fon/vard it again to another Anycast member that is not already there in the Routing Header address list. Last = Hdr Extn Length / 2 Destination Address = Next Nearest Anycast Member Address Copy the Routing Header Address List from the received Request Routing HeaderAddress [Last] = Its Unicast Address UAr Routing HeaderAddress [Last+1] = Anycast Address, AA At receiving side, by the end of Routing Header processing as per rules specified in [IPV6], the request becomes as if the request has come directly from the service user. This way it is transparent to upper layers. 4. Anycast Address Member Management Other than the following sections, everything else is followed as per [MLD]: 4.1. Registering to an Anycast Address / Sending MLD Report Message The node that wants to register to an Anycast address sends out MLD Report message with the following contents: IPv6 Source Address = Unicast Address of appropriate scope IPv6 Destination Address = Link Local All Routers Address MLD Report Multicast Address = Interested Anycast Address 4.2. De-Registering to an Anycast Address / Sending MLD Done Message The node that wants to de-register to an Anycast address sends out MLD Done message with the following contents: IPv6 Source Address = Unicast Address of appropriate scope IPv6 Destination Address = Link Local All Routers Address MLD Done Multicast Address = Interested Anycast Address 4.3. Updating Anycast Database and Sending MLD General Query Message The Querier updates its Anycast Database periodically by sending MLD General Query message. For this purpose, just before sending out MLD General Query Message it starts a 'Member Report Wait Timer' for each member of each Anycast address with a timeout value of MaxResponseDelay. If this timer expires, it means that the member is no more interested in this Anycast address and does the processing specified in [section 4.4- MLD Report Message Processing]. The Querier sends out MLD General Query message with the following contents: IPv6 Destination Address = Link Local All Nodes Address MLD Done Multicast Address = Unspecified Address Tine Router updates all the Anycast Members with the new LIST. 4.4. MLD Report Message Processing Only Routers Process this message. • Legend: ? AA = MLD Report Message.Anycast Address ? UAm = IPv6 Source Address • Sends out MLD Member Update Message with following contents ? IPv6 Destination Address = Solicited Node Multicast Address of appropriate scope ? MLD Member Update Message-Update Type = ADD ? MLD Member Update Message-Anycast Address = 'AA' ? MLD Member Update Message-Member Address = *UAm' • The router looks up the Anycast database for 'AA'. • If the entry exists, ■ If 'UAm* is already present in 'AA' member list o Stop the Member Report Wait Timer ■ If 'UAm' is not present in 'AA' member list o ADD 'UAm' to 'AA' member list o Updates 'UAm' by sending MLD Member Update Message with the following contents: - IPv6 Destination Address = 'UAm' - MLD Member Update Message-Update Type = LIST - MLD Member Update Message-Anycast Address = *AA' - MLD Member Update Message-Member Address List = 'AA' Member List • If the entry does NOT exist, ■ CREATE Anycast database entry for 'AA' and ADD 'UAm' to 'AA' member list. 4.5. MLD Done Message Processing Only routers process this message. • Legend: ? AA = MLD Report Message.Anycast Address ? UAm = IPv6 Source Address • Sends out MLD Member Update Message with following contents ? IPv6 Destination Address = Solicited Node Multicast Address of appropriate scope ? MLD Member Update Message-Update Type = DELETE ? MLD Member Update Message-Anycast Address = 'AA' ? MLD Member Update Message-Member Address = 'UAm' • The router lool^s up the Anycast database for 'AA'. • If the entry exists, ■ If 'UAm' is already present in 'AA' member list o Stop the Member Report Wait Timer o DELETE 'UAm' from 'AA' member list ■ If 'UAm' is not present in 'AA' member list o IGNORE the message • If the entry does NOT exist, ■ IGNORE the message 4.6. MLD Query Message Processing Only Querier sends this message and only Nodes process this message, • Legend: ? AA = MLD Query Message Anycast Address ? UAm = Its own address that is reported to Router ? Delay = MLD Query Message Maximum Response Delay • The node looks up the Anycast database for 'AA'. • If the entry exists, ■ If 'UAm' is present in 'AA' member list o Sends out a MLD Report as per [section 4.1] after a random interval chosen from [0, Delay] ■ if 'UAm' is not present in 'AA' member list o IGNORE the message • If the entry does NOT exist, " IGNORE the message 4.7. MLD Update Message Processing MLD Update Message ICMP Header fields Type = MLD Update Message Type Code =ZERO Checksum = Checksum of the packet starting from Type'. MLD Header fields Update Type = ADD / DELETE / LIST (ADD is 1, DELETE is 2, LIST is 3) No.of Members = No.of Member Addresses listed after Anycast Address (valid only for LIST) • Legend: ? AA = MLD Member Update Message.Anycast Address ? UAm = MLD Member Update Message.Member Address ? Type = MLD Member Update Message.Update Type ? N = MLD Member Update Messages.No.of Members Receiver of Member Update Message processes the message as per the following steps: • Lookup the Anycast Database for the Anycast address 'AA' • If the entry is found, ? If Type is ADD, add *UAm' to the Anycast Member Database of 'AA ? If Type is DELETE, delete 'UAm' from the Anycast Member Database of'AA' ? IfTypeisLIST, o If N is ZERO, PURGE the Anycast Member Database of 'AA'. o Otherwise, OVERWRITE the existing member list with the new member list of'AA'. • If the entry is NOT found, ? If Type is ADD, CREATE and ADD 'UAm' to the Anycast Member Database of 'AA' ? If Type is DELETE, IGNORE the message. ? IfTypeisLIST, o If N is ZERO, IGNORE the message. o OthenA/lse, CREATE and ADD the 'N' members to Member Database of'AA'. 5. Anycast Database The Anycast Database, which routers connected to link with Anycast members maintain, will be in the form specified below: For each Anycast Address, For each Member Member's Unicast Address Member Report Wait Timer The Anycast Database, which Anycast members maintain, will be in the form specified below: For each Anycast Address, Report Delay Timer For each Member Member's Unicast Address This information is in addition to tlie information specified in [IVILD]. ADVANTAGES OF THE INVENTION a. Load sharing among the Anycast IVIembers is achieved even if the Routing Architecture always delivers the packets to the nearest Anycast IVIember. b. All members of an Anycast Address know & reach each other and hence, they can communicate for sharing the load, in case a particular member is overloaded. c. Anycast Service Provider can utilize his network infrastructure fully under peak load, and so can get good return on investment. There is no geographical restriction on placement of the Anycast Servers. They can be either centralized or distributed and this invention works for all types of geographical scenarios. With Centralized Anycast Server Cluster, deployment cost gets reduced. This will also reduce the maintenance cost. DETAILED DESCRIPTION OF THE ACCOMPANYING DRAWINGS Figure 1: it is usual that the service user base may not be same at all the geographical areas. Assume that the following are percentage of users for particular Anycast service at an instant of time. Out of 100 requests, 40% requests go to Anycast Server A1 10% requests go to Anycast Server A2 20% requests go to Anycast Server A3 30% requests go to Anycast Server A4 With 40% of users near A1 connected to Anycast Server A1, and it is fully loaded. If any new user near A1 service area wants to access the service then the request will be delivered to A1. Because A1 is already fully loaded, it will drop the request even though other Anycast servers of the same group are not fully loaded. Figure 2: Once Router 'R' gets a packet to Anycast Address *A' (for which A1 and A2 belong to), it resolves the Anycast Address to one of the MAC Addresses as per [NDP]. For example, let us assume that Router Neighbor cache will have the entry for A1. In this case, Router *R' keeps on sending the packets destined to Anycast address to 'A1' even if it is overloaded. Router 'R' is not aware that it Is an Anycast address and there is another member for the same Anycast Address. Figure 2A: It depicts the message exchange that takes place between the Anycast hosts and the router before the router gets a NA message as part of address resolution as per [NDP]. The router sends a solicitation message, which is received by all the Anycast members. The members start an Anycast Random Delay Timer. The host whose timer expires will send a Neighbour Advertisement message with Override flag = 0. The router updates its Neighbour Cache to the one whose message it receives first as per [NDP]. The other NA messages that are received for this Anycast address are ignored. Figure 3: It depicts the existing Anycast address registration mechanism. Here the newly joining Anycast member sends out unsolicited MLD Report. The Router receives the report and creates or updates the Anycast Database. Here, the router does not store the Anycast members' list belonging to same Anycast Group, Figure 4: It depicts the existing Anycast address de-registration mechanism. The leaving Anycast member sends out MLD Done. The Router receives the MLD Done and starts Last Listener Query Process as per [H0STANYv6] as it does not have the members list. This process makes sure that there are no members left for that Anycast address on this link. Legend for Figure 5 & 6: Solid arrow indicates original request from service user and dashed arrow is the forwarded request from the overloaded Anycast Member to another Anycast Member Figure 5: This figure illustrates the manner in which load sharing will be done with this invention in Distributed Anycast cluster management. The service user sends out the service request to an Anycast address, which eventually will be routed to the nearest Anycast Member by the current routing architecture. As A1 is the nearest Anycast server, it gets the request. Anycast member *A1' finds that it is already fully loaded and cannot service any more requests until some service user quits as per Section 1 - [Load Balancing Trigger]. So, it forwards the request to the next nearest Anycast Member selected as per Section 3 -[Forwarding the Request & Transparency to Upper Layers]. Figure 6: This figure illustrates the manner in which load sharing will be done with this invention with Centralized Anycast Cluster Management. Service user request destined to Anycast address 'AA' get routed to router 'R' by our current routing architecture/behaviour. Router 'R' resolves the address and (say) Router Neighbour Cache for 'AA', points to 'A1\ Router does not know that *A1' is already fully loaded and forwards the request to 'A1'. *A1' finds that it is overloaded and cannot service any more users as per Section 1 - [Load Balancing Trigger] and fon/vards the request to 'A2' as per Section 2 - [Member Selection Algorithm], which can service the new user request. For both Figure (5) & Figure (6), The next nearest Anycast Member 'A2' gets the packet. The current conventional Routing Header processing makes the 'A2' upper layers to see the request as if it has come directly from the service user. It finds that it can service the request, it then sends the service request response back to the service user. The further processing goes on with conventional methods. Figure 7: it depicts Anycast address registration with this invention. Whenever a node wants to register to an Anycast Address 'AA', it sends out "MLD Report" message as specified in Section 4.1- [Registering to an Anycast Address/Sending MLD Report Message] and Router processes it as specified in Section 4,4 - [MLD Report Message Processing]. Eventually, all the members of the Anycast address 'AA' get this MLD Update and process the message as per Section 4.7 - [MLD Update Message Processing]. Figure 8: It depicts Anycast address de-registration with this invention. Whenever a node wants to de-register to an Anycast Address 'AA\ it sends out "MLD Done" message as specified in Section 4,2 - [De-Registering to an Anycast Address/Sending MLD Done Message] and Router processes it as specified in Section 4.5 - [MLD Done Message Processing]. Eventually, all the members of the Anycast address 'A' get this MLD Update and process the message as per Section 4.7 - [MLD Update Message Processing]. Figure 9: This figure depicts the sequence chart with this invention with any Anycast cluster management. The service user sends out the service request to an Anycast address, which eventually will be routed to the nearest Anycast Member by the current routing architecture. As A1 is the nearest Anycast server, it gets the request. Anycast member 'A1' finds that it is already fully loaded and cannot service any more requests until some service user quits as per Section 1 - [Load Balancing Trigger]. So, it fonA^ards the request to the next nearest Anycast Member The next nearest Anycast Member 'A2' gets the packet. 'A2' finds that it can service the request. It then sends the service request response back to the service user. The further processing goes on with conventional methods. While the invention has been particularly described with reference to a preferred embodiment, it will be understood by those skilled in the art that various changes in form and detail may be made therein without departing from the spirit and scope of the invention. References [IPV6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [NDP] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for IPv6", RFC 2461, December 1998. [H0STANYV4] Partridge, C, Mendez, T. and W. Milliken, "Host Anycasting Service", RFC 1546, November 1993. [ADDR-ARCH] Hinden, R., and Deering, S., "Internet Protocol, Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003. [H0STANYV6] Haberman, H., and Thaler, D., "Host based Anycast using MLD", , May 2002 "work in progress" [ANALYSIS] Hagino, J., and Ettikan, T., "An Analysis of IPv6 Anycast," , February 2001 "work in progress". Glossary of Terms and their definitions Anycasting Sending out the packet to Anycast Address (i.e. with Destination Address as Anycast Address) Anycast Address An IPv6 Anycast address is an address that is assigned to more than one interface (typically belonging to different nodes), with the property that a packet sent to an Anycast address is routed to the "nearest" interface / host having that address, according to the routing protocols' measure of distance. Anycast Group / Anycast Cluster The group of interfaces (typically belonging to different nodes) that have been assigned same Anycast address. Anycast member Any host which has been configured with the Anycast address. Anycast Group Member. The node that belongs to an Anycast Group. Done Done is the message in l\/1LD Protocol that a node sends to routers informing that it is not interested in that group. MLD IVIulticast Listener Discovery for IPv6 - [MLD] NOP Neighbor Discovery for IPv6 - [NDP] Report Report is the message in MLD Protocol that a node sends to routers informing that it is interested in that group. Session Conceptual name for a connection. TCP Transmission Control Protocol - A connection oriented transport layer protocol of TCP/IP Stack UDP User Datagram Protocol - A connection less transport layer protocol of TCP/IP Stack WE CLAIM 1. A method for communication between Anycast Members for load sharing using IPv6 Anycast addressing comprising the steps of: a) Keeping track of the current load of the Anycast Member through the service request sent by the Anycast address; b) Checking if the new request can be serviced; c) Identifying the next nearest Anycast Member based on the scope and longest prefix matching; and d) Transparent fonA^arding of the request to next Anycast Member using Routing Header Type Zero, thereby, avoiding the Loops in fon/varding the request using the List of Anycast Members in the Routing Header, 2. A method as claimed in claim 1 wherein to determine if a node can serve a new request, a load balancing trigger mechanism is used. 3. A method of communication between IPv6 Anycast Member and Router, and between the Router and Anycast Members for maintaining the list of Anycast Members belonging to Same Anycast Group comprising of the steps: a) registering of the IPv6 Unicast Address of the Anycast Member with the Router b) updating of Anycast Members by router with the List of Anycast Members belonging to a particular Anycast Group c) maintaining the Database of Anycast Group with the Routers and the corresponding Anycast members and d) de-registering of the IPv6 Unicast Address of the Anycast Member with the Router 4. A method for placing two or more Anycast Servers on same link or within a site and sharing the load between them, wherein a centralized cluster management of hosts bound by the same IPV6 Anycast address is provided in that each member of the Anycast group keeps track of its load state and information it can handle, where the Anycast member itself rather than the router decides as to which member takes up the load next, wherein: a) a request is sent to the particular Anycast address; b) the request is processed by the nearest router; and c) the router sends a multicast message as part of address resolution for Anycast address to MAC address and delivers the packet to the node that responds first. A method for communication between Anycast Members for load sharing using IPv6 Anycast addressing, such as herein described. A Method for placing two or more Anycast Servers on Same Link or within a site and sharing the load between them substantially as herein described

Documents:

988-che-2003-abstract.pdf

988-che-2003-claims duplicate.pdf

988-che-2003-claims original.pdf

988-che-2003-correspondence others.pdf

988-che-2003-correspondence po.pdf

988-che-2003-description complete duplicate.pdf

988-che-2003-description complete original.pdf

988-che-2003-drawings.pdf

988-che-2003-form 1.pdf

988-che-2003-form 19.pdf

988-che-2003-form 26.pdf