Network Working Group Wanming. Luo Internet-Draft X. Lee Intended status: Informational Wei. Mao Expires: September 23, 2009 CNNIC Mei. Wang Cisco Systems MARCH 22, 2009 Load Balancing based on IPv6 Anycast and pseudo-Mobility draft-luo-v6ops-6man-shim6-lbam-01.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on September 23, 2009. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Luo, et al. Expires September 23, 2009 [Page 1] Internet-Draft MARCH 2009 Abstract Load balancing is a key factor for both IPv4 to IPv6 transition mechnisms, e.g.NAT-PT or Tunnel broker, and Multihoming to improve their scalability and Robustness. In fact, that is a method, by which IP packet can be distributed across a pool of servers, instead of directing to a single server.Load balancing has been widely used by NAT, Web service and FTP service. However, current load balancing software and implementations have problems such as poor scalability, inability to balance session flow, long latency time and topological constraint on server pool. This document describes a method using pseudo-anycast and pseudo- mobility based on Mobile IPv6 to implement load balancing in session level in IPv6 network, by which those problems above can be solved. Futhermore, this method only need little modification to Mobile IPv6 in the servers' and agent's side; as for the general users, it need not any modification. Luo, et al. Expires September 23, 2009 [Page 2] Internet-Draft MARCH 2009 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Conventions used in this document . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. Overview of Mobility Support in IPv6 . . . . . . . . . . . 7 3.2. Overview of LBAM . . . . . . . . . . . . . . . . . . . . . 8 4. Modification of MIPv6 in Servers and LBAM Agent . . . . . . . 9 4.1. Modifying Binding Cache in LBAM Agent . . . . . . . . . . 9 4.2. Adding Load Balancing History Cache in LBAM Agent . . . . 10 4.3. Adding No Active Session Notice parameter . . . . . . . . 11 5. Operation of LBAM Agent . . . . . . . . . . . . . . . . . . . 12 5.1. LBAM Agent's process to tunnel the start of session . . . 12 5.2. LBAM Agent receiving Binding Update message . . . . . . . 13 5.3. Detecting dead host and announcing to CNs . . . . . . . . 14 5.4. Selecting the best server for a start session . . . . . . 14 6. Operation of correspondent nodes . . . . . . . . . . . . . . . 14 7. Operation of servers . . . . . . . . . . . . . . . . . . . . . 15 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 9. Normative References . . . . . . . . . . . . . . . . . . . . . 17 Appendix A. Appendix A: Load balancing algorithms . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 Luo, et al. Expires September 23, 2009 [Page 3] Internet-Draft MARCH 2009 1. Introduction The need for Load balancing arises when a single server is not able to cope with increasing demand for multiple sessions simultaneously. Clearly, load balancing across multiple servers would enhance responsiveness and scale well with session load. Both IPv4 to IPv6 transition mechnisms, e.g.NAT-PT,CGN(Carrier Grade NAT), NAT64 or Tunnel broker, and Multihoming require some kind of load balancing. Load balancing is not new and goes back many years. A variety of techniques, including software, hardware and both of them, were applied to address it and each of them presents interesting advantages but also solves different problems than the LBAM, or pose drawbacks not present in the LBAM: DNS Support for Load Balancing [RFC1794]is a simple mechanism to balance session flow. The problem with this approach is its long latency time, moreover, modifications to the widely deployed DNS protocol can introduce instability. This is not an acceptable option; Load Balancing using IP Network Address Translation (LSNAT) [RFC2391] inherently has the problems with Network Address Translation (NAT) [RFC3022] , including topological constrain on the server pool, the long latency time caused by several translations, triangle routing, and breaking the end-to-end significance intelligence [RFC3439] (That is, some application, such as FTP, H.323 and SIP, can not pass through the LSNAT router), moreover, the LSNAT itself might be a bottle-neck if the bindings of session flow are too many; Some layer 4 switch of Cisco and Extreme, can provide load balancing based on hardware, and the performance is much better than software, however, this approach is poor at scalability and has topological constrain. LBAM is an alternative approach using pseudo-anycast and pseudo- Mobility in IPv6 without those problems above. LBAM has two kinds of entity: agent and the pool of servers, and all of those entities have a same anycast address. When a client attempts to access a server in the pool, the agent selects a server in the pool based on load balancing algorithm and redirects the request to that server by pseudo-Mobility. In this view, the agent is functionally similar to Home Agent in Mobile IPv6[RFC3775]. The client will directly access the selected server during the session. Subsequently, the client will continue to interact with this server until the binding expires or the client receives a binding update. LBAM poses no restriction on the organization and rearrangement of servers in the pool. Server may be added and deleted easily, no matter where it is. Luo, et al. Expires September 23, 2009 [Page 4] Internet-Draft MARCH 2009 The draft does not need any changes to Mobile IPv6 in CN, and a little modification on Mobile IPv6 in the Server and LBA. The draft is structured as follows. Section 2 provides terminology and concepts used. Section 3 overviews the method. Section 4 briefly details the how to implement LBAM based on mobility support in IPv6; Section 5, 6 and 7 describe operation of LBAM agents, correspondent nodes and servers. Section outlines security consideration. The Appendix describes several load balancing algorithms. 1.1. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] . 2. Terminology Load balance Load balance for the purpose of this document is defined as the spread of session load amongst a cluster of servers, which are functionally similar or the same. In other words, each of the servers in cluster can support a client session equally well with no discernible difference in functionality. Once a server is assigned to service a session, that session is bound to that server till termination. Sessions are not allowed to swap between servers in the midst of session. Start of session for TCP, UDP and others The first packet of every TCP session tries to establish a session and contains connection startup information. The first packet of a TCP session may be recognized by the presence of SYN bit and absence of ACK bit in the TCP flags. All TCP packets, with the exception of the first packet must have the ACK bit set. However, there is no deterministic way of recognizing the start of a UDP session or any other non-TCP session. End of session for TCP, UDP and others The end of a TCP session is detected when FIN is acknowledged by both halves of the session or when either half receives RST bit in TCP flags field. Within a short period (say, a couple of seconds) after one of the session partners sets RST bit, the session can be safely assumed to have been terminated. For all other types of session, there is no deterministic way of determining the end of session unless you know the application protocol. Many heuristic approaches are used to terminate sessions. Another way to handle session terminations is to timestamp sessions and keep them as long as possible and retire the longest idle session when it becomes necessary. Luo, et al. Expires September 23, 2009 [Page 5] Internet-Draft MARCH 2009 Pseudo-anycast An anycast address assigned to many nodes. However, only one server (say node A) takes part in the routing system, the others are "dumb" in routing system. That is a simple packet destined to the pseudo-anycast will reach the node A, rather than the others. To reach one (say node B) of the other nodes which have their own global uncast addresses, as well as the "dumb" pseudo- anycast address, an IPv6 Routing header [RFC4861] must be used in the packet (its pseudo-anycast address is the packet's destination, while its global unicast address is the intermediate). In fact, a pseudo-anycast address is corresponding to a kind of service. Load Balance Address A pseudo-anycast address assigned to both of LBAM and the servers in the pool. We will call it LBA address as following. From the perspective of LBAM Agent, LBA address is its global unicast address, while from the perspective of all the servers in the pool, the LBA address just is a "dumb" address that functions as home address, and they have their own global exclusive unicast address that functions as care-of address. Server's unicast address In LBAM, this global unicast address is the care-of address for difference server, that is, all the servers in the pool have their own global unicast address (care-of address, CoA) besides the same anycast one (pseudo-anycast address) assigned to them. This address is functionally similar to care-of address in Mobile IPv6. Server pool A set of servers that are functionally similar or the same. They have at least two kinds of address: the global exclusive unicast address and the LBA address. Pseudo-mobility To implement LBAM, the LBAM Agent will tunnel a packets destined to the LBA address to the care-of address of one selected server, as if the very server changed its point, even through the very server is stationary in the same link (In the extreme case, all the servers stationary at the same link permanently). We call the false mobility as Pseudo-Mobility. When a server deployed, an entry for the LBAM Agent SHOULD be added in its Binding Update List, and then, Bind Update message SHOULD be sent out according to the Binding Update List. Or if the server is really away from it former point, the server will send out the Bind Update message according to the Binding Update List. LBAM Agent A node intercepts packets destined to the LBA address, encapsulates them, and tunnels them to the mobile node's registered care-of address. Indeed, it is functionally similar to Home Agent in Mobile IPv6. LBAM Agent may be a general host, rather than must be a Luo, et al. Expires September 23, 2009 [Page 6] Internet-Draft MARCH 2009 router, as well there is only one LBAM Agent, rather than many Home Agent in Mobile IPv6. LBAM Agent does nothing except balancing special load. The Agent may take charge in balancing several kinds of service, if it is assigned with several pseudo-anycast addresses. Extended Binding Cache In Mobile IPv6, the Home Agent only has one binding entry for a home address in the Binding Cache. While in LBAM, the LBAM Agent may have as many binding entry as the number of the servers in the pool; each one entry corresponds to a server. Load Balancing History Cache A cache to log all load balancing history for each server and the correspondent nodes the server is servicing This document is based on Mobile Ipv6, and for other terms appeared in this document please refers to Mobile IPv6[RFC3775]. 3. Overview 3.1. Overview of Mobility Support in IPv6 Each mobile node is always identified by its home address, regardless of its current point of attachment to the Internet. While situated away from its home, a mobile node is also associated with a care-of address, which provides information about the mobile node's current location. IPv6 packets addressed to a mobile node's home address are encapsulated and tunneled transparently to its care-of address [RFC2473]. When a mobile node receives a packet tunneled to it from its home agent, the mobile node uses that as an indication that the original sending correspondent node has no Binding Cache entry for the mobile node, since the correspondent node would otherwise have sent the packet directly to the mobile node using a Routing header, or when away from an area, a mobile node will send "Bind Update" message to those very nodes according to its "Binding Update List". After receiving the Bind Update message, those correspondent nodes will change its "Binding Cache" in response to the message. From then on, the node uses an IPv6 Routing header [RFC4861] (instead of IPv6 encapsulation) to route the packet to the mobile node by way of the care-of address indicated in this binding cache for the mobile node. Mobile IPv6 defines one additional IPv6 destination option. When a mobile node sends a packet while away from home, it will generally set the Source Address in the packet's IPv6 header to one of its Luo, et al. Expires September 23, 2009 [Page 7] Internet-Draft MARCH 2009 current care-of addresses, and will also include a "Home Address" destination option in the packet, giving the mobile node's home address. By using the care-of address as the Source Address in the IPv6 header, with the mobile node's home address instead in the Home Address option, the packet will be able to safely pass through any router implementing ingress filtering [RFC2460] . 3.2. Overview of LBAM Every server in the server pool has a unicast address called pseudo care-of-address, named A1, ..., Ai, ..., An. The LBAM agent and these servers have the same address called LBA address. These servers have the MN's function and the LBAM Agent has the Home Agent's function according to the Mobile IPv6 [RFC3775]. Firstly, when the CN sends initial IP packet to the LBA address, the LBAM agent receives this packet and tunnels this packet to a server (saying Server-i) by some load algorithm using IPv6 encapsulation [RFC2473]. Then, when the Server-i receives this tunneled packet, it will send Binding Update message to the CN. After receiving Binding Update message, CN will send the following packets to the server-i directly. Before sending any packet, the sending node SHOULD examine its Binding Cache for an entry for the destination address to which the packet is being sent. If the sending node has a Binding Cache entry for this address, the sending node SHOULD use Type 2 Routing header to route the packet to this server (the destination node) by way of the care-of address in the binding recorded in that Binding Cache entry. If a new server will join this server pool, it sends a Binding Update message to LBAM Agent for "Home" registration, to tell the LBAM its unicast address. Figure 1 gives a scenario of this method. Luo, et al. Expires September 23, 2009 [Page 8] Internet-Draft MARCH 2009 +---------+ +-------+ + Server-1+ + CN-1 + +---------+ +-------+ +---------+_Tunneled +------------+ 1st packet +-------+ + Server-i+ <----- + LBAM Agent + <----------+ CN-j + +---------+ Packet +------------+ +-------+ ^ | ^ | | | Binding Update | | | +-----------------------------------------------+ | +----------------------------------------------------+ Packets directly to Serveri by way of CoA +---------+ +-------+ + Server-n+ + CN-m + +---------+ +-------+ Figure 1 A scenario of the LBAM 4. Modification of MIPv6 in Servers and LBAM Agent Both of the LBAM Agent and the servers MUST modify their Mobile IPv6 little as follows. Note that except those modifications followed, the other parts of LBAM Agent and servers are same as Mobile IPv6. So, it is to easy to implement LBAM based on Mobile IPv6. 4.1. Modifying Binding Cache in LBAM Agent LBAM Agent needs some modifications including Binding Cache Agent and how to process Binding Update message received in LBAM Agent. Every IPv6 node with mobility support has a Binding Cache, which is used to send original packets by correspondent nodes (CN)or to tunnel intercepted packet destined to the mobile node. In Mobile IPv6, each Binding Cache only contain one entry for a mobile node, no matter the node is a correspondent node or Home Agent. In LBAM Agent, we redefine and name it as Extended Binding Cache, in which each entry conceptually contains the following fields: LBA address which acts as the home address of a server in the pool. If the destination address of the packet matches one or more LBA address in the Binding Cache entry, one entry selected by load balancing algorithm, SHOULD be used in routing that packet. The global unicast addresses of the servers in the pool, which act as care-of address in Mobile IPv6. If the destination address of a packet intercepted by the agent matches the LBA address of the LBAM Luo, et al. Expires September 23, 2009 [Page 9] Internet-Draft MARCH 2009 Agent, the packet SHOULD be tunneled to the unicast address of an entry selected from several entries by load balancing algorithm. Combination of both fields above is used as the key for searching the Binding Cache for the destination address of a packet being sent. - The maximum value of the Sequence Number field received in previous Binding Updates for this mobile node home address. The Sequence Number field is 8 bits long, and all comparisons between Sequence Number values MUST be performed modulo 2**8. For example, using an implementation in the C programming language, a Sequence Number value A is greater than another Sequence Number value B if ((char)((a) - (b)) > 0), if the "int" data type is a 8-bit signed integer. - The Binding Security Association (BSA) to be used when authenticating Binding Updates that are received for this Binding Cache entry. - The Binding Security Association (BSA) to be used when calculating authentication data for inclusion in Binding Acknowledgements in response to Binding Updates that are received for this Binding Cache entry. An entry for a server in the LBAM Agent's Extend Binding Cache SHOULD NOT be deleted by the agent, until the agent receives a Binding Update message from the server in which the lifetime is zero, or the agent finds out the server has died or can not offers service. We can find out that there is little difference with Binding Cache in Mobile IPv6, except the four fields at foreside; the rest fields are same as their corresponding ones in Binding Cache of MIPv6. 4.2. Adding Load Balancing History Cache in LBAM Agent The LBAM Agent SHOULD add Load Balancing History Cache to log all the load balancing history for each server and the correspondent nodes that the server is servicing. Each entry of Load Balancing History Cache has those fields as follows: - LBA address; - The global unicast address of a server in the pool. Combination of both fields above is used as the key to index; - Correspondent node list, which includes all the correspondent nodes directed to the very server; Firstly, the Load Balancing History Cache MAY be used in load balancing algorithm. Secondly, if the LBAM Agent finds out a sever Luo, et al. Expires September 23, 2009 [Page 10] Internet-Draft MARCH 2009 has died, it can send out Binding Update message to all the Correspondent Nodes binded to the server immediately, by which those Correspondent Nodes can get out the "black-hole " (the dead server) quickly, rather than have to wait until their very binding to the server time out. 4.3. Adding No Active Session Notice parameter No Active Session Notice parameter (alignment requirement: 8n+6) 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 6 | 50 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | LBA Address | + + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | Server Unicast Address | + + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | CN Address | + + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Luo, et al. Expires September 23, 2009 [Page 11] Internet-Draft MARCH 2009 The No Active Session Notice Header parameter is valid only in the Binding Update message sent from servers to LBAM Agent. The No Active Session Notice parameter contains 3 addresses (tri- tuple): LBA address, Server Unicast address and CN address which are used by LBAM Agent to index and delete the corresponding entries in Loading Balancing History Cache and Extended Binding Cache. 5. Operation of LBAM Agent 5.1. LBAM Agent's process to tunnel the start of session To redirect the start of session, the LBAM Agent MUST attempt to intercept packets on the LBA address, and MUST tunnel each intercepted packet to a server selected by load balancing algorithm using IPv6 encapsulation [RFC2473]. In order to intercept such packets on the home link, when a node begins serving as the LBAM Agent for a service (or say for a pool of servers), the LBAM Agent MUST receive all "pure" start packet of a session destined to the LBA address (Simply, a pure packet is a packet without Routing header). It is very easy to implement the process above, because it is the LBAM Agent who takes part in the routing system in the name of LBA address; so all the "pure" packet will reach the LBAM Agent. After intercepting the start packet of a session, the LBAM Agent MUST browse the Load Balancing History Cache, to see whether there is an entry according to the combination key of the correspondent's source address and the LBA address. If yes, that is the correspondent node ever requested a server and the binding between it and the server has been timeout, so the LBAM Agent Must delete the previous entry and selected a new server using load balancing algorithm, and then create an entry in the Load Balancing History Cache for the correspondent node; if not, the LBAM Agent just creates an entry in the Load Balancing History Cache for the correspondent node. In order to forward each intercepted packet to a selected server, the LBAM Agent MUST tunnel the packet to the selected server using IPv6 encapsulation [RFC2473], the tunnel entry point node is the LBAM Agent, and the tunnel exit point node is the selected server's global unicast address extracted from Extended Binding Cache. When the LBAM Agent encapsulates an intercepted packet for forwarding to the server, the agent sets the Source Address in the prepended tunnel IP header to the LBAM agent's own IP address (the LBA address), and sets the Destination Address in the tunnel IP header to the server's uncast address. When received by the server (using its unicast Luo, et al. Expires September 23, 2009 [Page 12] Internet-Draft MARCH 2009 address), normal processing of the tunnel header in [RFC2473] will result in decapsulation and processing of the original packet by the server. 5.2. LBAM Agent receiving Binding Update message From the perspective of other nodes except the LBAM Agent, the process for received Binding Update message is same as in Mobile IPv6. Only LBAM Agent processes received Binding message differently against Mobile IPv6, as follows (see [RFC3775]; for reference): Before accepting a Binding Update option received in any packet, the receiving node MUST validate the Binding Update according to the following tests: - The packet meets the specific authentication requirements for Binding Updates; - The packet MUST contain a Home Address option; - The Option Length field in the Binding Update option is greater than or equal to the length specified in of [RFC3775]; - The Sequence Number field in the Binding Update option is greater than the Sequence Number received in the previous Binding Update for this home address, if any. As noted in [RFC3775], this Sequence Number comparison MUST be performed modulo 2**8. If the server sends a sequence number which is not greater than the sequence number from the last successful Binding Update, then the LBAM Agent MUST send back a Binding Acknowledgement with status code 141, and the last accepted sequence number in the Sequence Number field of the Binding Acknowledgement. Any Binding Update which fails to satisfy all of these tests for any other reason (than insufficiency of the Sequence Number) MUST be silently ignored, and the packet carrying the Binding Update MUST be discarded. If the Binding Update is valid according to the tests above, then the Binding Update is processed further as follows: - If there is not the entry for the care-of address extracted from the message, and the Lifetime is not zero, then create a entry, in which LBA address is extracted from the Home option in the received Binding Update message, and the global care-of address is equal to the source address of the received Binding Update message (the server's global unicast address); Luo, et al. Expires September 23, 2009 [Page 13] Internet-Draft MARCH 2009 - If there is the entry for the care-of address and LBA address extracted from the message, and the Lifetime specified in the Binding Update is not zero, then ignore this Binding Update message; - If the Lifetime specified in the Binding Update is zero or the specified Care-of Address included in the Alternate Care-of address sub-option matches the LBA address in the Home option, then this is a request to delete entry. In other word, this server sent this message would not offer service now. - If LBAM Agent receives a Binding Update message carrying No Active Session Notice parameters, it will delete the two matched entries in Load Balancing History Cache and Extended Binding Cache according to the tri-tuple retrieved from the Binding Update message. 5.3. Detecting dead host and announcing to CNs As sessions are assigned to servers, it is important to detect the live-ness of the servers. Otherwise, sessions could simply be black- holed into a dead server. Many heuristic approaches are adopted. Meanwhile, LBAM Agent sending pings periodically would be one way to determine the live-ness. When the LBAM Agent detects a dead server, it should send Binding Update message according to its Load Balancing History Cache to relative correspondent nodes to reset the binding with the dead server. Meanwhile, the agent should delete the entry for the server in its Extended Binding Cache. 5.4. Selecting the best server for a start session Certainly, the LBAM SHOULD select a best server for a start session. The algorithms are described in appendix. The Load Balancing History Cache and the Extended Binding Cache MAY be a reference for selecting. 6. Operation of correspondent nodes First of all, the node should support Mobile IPv6, then load balancing and LBAM is transparent to it. Before sending any packet, the sending node SHOULD examine its Binding Cache for an entry for the destination address to which the packet is being sent. If the sending node has a Binding Cache entry for this address, the sending node SHOULD use a Routing header to route the packet to this server (the destination node) by way of the care-of address (the server's global unicast address) in the binding recorded in that Binding Cache entry. Luo, et al. Expires September 23, 2009 [Page 14] Internet-Draft MARCH 2009 Consequently, as long as there is a valid entry in the CN's Binding Cache for a LBA address, all the sessions originated from the same CN will be directed to the same server indicated by the valid entry. This is a constraint of LBAM. In addition, a correspondent node with a Binding Cache entry for a server may refresh this binding, for example if the binding's lifetime is near expiration, by sending a Binding Request to the mobile node. Normally, a correspondent node will only refresh a Binding Cache entry in this way if it is actively communicating with the server and has indications, such as an open TCP connection to the server, that it will continue this communication in the future [RFC3775]. After receiving a responding Binding Update message from the server, the correspondent node will refresh this binding. 7. Operation of servers First of all, when being deployed, all servers MUST send out Binding Update message to the LBAM Agent, so that LBAM Agent can register the binding in its Extended Binding Cache. This process is same as [RFC3775]. When receiving a tunneled packet by LBAM Agent, the server uses that as an indication that the original sending correspondent node has no Binding Cache entry for it, since the correspondent node would otherwise have directly sent the packet to the server using a Routing header. So, the server will send out a Binding Update to the correspondent node; this process is same as [RFC3775]. When receiving a packet with Routing Header, a server will process the Routing header as follows: - The server swaps the Destination Address in the packet's IPv6 header and the Address specified in the Routing header. This results in the packet's IP Destination Address being set to the server's LBA address. - The server then resubmits the packet to its IPv6 module for further processing, "looping back" the packet inside the server. Since the server recognizes its own LBA address as one of its current IP addresses, the packet is processed further within the server. When a server sends a packet, it will generally set the Source Address in the packet's IPv6 header to its current care-of address, the global unicast address, and will also include a "Home Address" destination option in the packet, giving the server's LBA address. By using the care-of address as the Source Address in the IPv6 Luo, et al. Expires September 23, 2009 [Page 15] Internet-Draft MARCH 2009 header, with the server's home address (LBA address) instead in the Home Address option, the packet will be able to safely pass through any router implementing ingress filtering [RFC2460]. Before shut down, the server SHOULD send out Binding Update message according to its Binding Update List by setting the Lifetime zero or specifying Care-of Address included in the Alternate Care-of address sub-option matches the LBA address in the Home option. Moreover, when a server receives a packet containing a Binding Request, it SHOULD return to the sender a packet containing a Binding Update. The Lifetime field in this Binding Update SHOULD be set to a new lifetime, refreshing current lifetime remaining from a previous Binding Update sent to this node. When sending this Binding Update, the server MUST update its Binding Update List in the same way as for any other Binding Update sent by the server. Please see [RFC3775] for reference. Note: the Default Lifetime in the Binding Update message MAY be defined according to different service the server provides. For example, if the server provides multimedia service using UDP, the Lifetime should not be too long; if the server provides FTP or WWW services, the Lifetime may be much long. In some senses, a short Lifetime means that perhaps the server would receive Binding Request message frequently, while a long Lifetime means the Binding will keep for more time even through a CN does not need the server no longer. So, it is a tradeoff to define the Lifetime in Binding Update message. At last, when a server detects no active session with some CN, it will send a Binding Update message carrying the No Active Session Notice parameters to LBAM Agent and it will delete the relative entries in its own Binding Cache and Binding Update List at the same time; meanwhile, the server sends a Binding Update message with LifeTime = 0, to tells the CN to delete corresponding entry of the sever in its Binding Cache. Note: As said in [RFC3775], if the sender knows that the Binding Cache entry is still in active use and the remain lifetime is near expiration, it MAY send a Binding Request option to the mobile. When the mobile node receives a packet from some sender containing a Binding Request option, it returns a Binding Update option to that sender, giving its current binding and a new lifetime. So, it implies that CN MAY or MAY not send a Binding Request option to the server when the binding is near expiration. Supposed that the CN sends Binding Request when the binding is near expiration; a server can definitely know that the binding is invalid when its remaining Lifetime in Binding Update List is equal 0; otherwise, the server has to depend on other methods to detect whether there is active session Luo, et al. Expires September 23, 2009 [Page 16] Internet-Draft MARCH 2009 with a CN when the remaining Lifetime is near expiration. How to detect the "no active session" is out of the scope of this document. 8. Security Considerations This document has no direct impact on Internet infrastructure security. The security of this document is dependent on the security mechanisms of Mobile IPv6. 9. Normative References [RFC1794] Brisco, T., "DNS Support for Load Balancing", RFC 1794, April 1995. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2391] Srisuresh, P. and D. Gan, "Load Sharing using IP Network Address Translation (LSNAT)", RFC 2391, August 1998. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, December 1998. [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001. [RFC3439] Bush, R. and D. Meyer, "Some Internet Architectural Guidelines and Philosophy", RFC 3439, December 2002. [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006. [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007. [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007. Luo, et al. Expires September 23, 2009 [Page 17] Internet-Draft MARCH 2009 Appendix A. Appendix A: Load balancing algorithms Many algorithms are available to select a host from a pool of servers to service a new session. The load distribution is based primarily on (a) resource availability and system load on the server, and (b) cost of accessing the network on which a server resides and load on the network interface used to access the server [RFC2391]. A.1 First criterion: resource availability on the server Ideally speaking, the selection process would have precise knowledge of real-time resource availability and system load for each host in server pool, so that the selection of host with maximum unutilized capacity would be the obvious choice. However, this is not so easy to achieve. We consider here two kinds of heuristic approaches to monitor session load on server pool members. The first kind is where the load balance selector tracks system load on individual servers in non- intrusive way. The second kind is where the individual members actively participate in communicating with the load balance selector, notifying the selector of their load capacity. Listed below are the most common selection algorithms adapted in the non-intrusive category. 1. Round-Robin algorithm This is the simplest scheme, where a server is selected simply on a round robin basis, without regard to load on the host. 2. Least Load first algorithm This is an improvement over round-robin approach, in that, the server with least number of sessions bound to it is selected to service a new session. This approach is not without its caveats. Each session is assumed to be as resource consuming as any other session, independent of the type of service the session represents and all servers in server pool are assumed to be equally resourceful. 3. Ping to find the most responsive host. Till now, capacity of a server is determined exclusively using heuristic approaches by the LBAM Agent. In reality, it is impossible to predict system capacity from remote, without interaction with those servers. A prudent approach would be to periodically ping those servers and measure the response time to determine how busy the servers really are. Use the response time in conjunction with the Luo, et al. Expires September 23, 2009 [Page 18] Internet-Draft MARCH 2009 heuristics to select the server most appropriate for the new session. A.2 Second criterion: cost of accessing server When server nodes are distributed geographically across different areas and cost to access them vary widely, the load balance selector could use that information in selecting a server to service a new session. In order to do this, the load balance selector would need to consult the routing tables maintained by routing protocols such as RIP and OSPF, to find the cost of accessing a server from the correspondent node to a server of the pool. To meet this criterion, the selector has to master the enough routing information to calculate the access cost. In fact, when the pool of servers distributes widely, and the correspondent node is far away from the LBAM Agent, the criterion is hard to implement. Simply, the LBAM can choose a server with the longest prefix match to the correspondent node. A.3 Weighted load balancing algorithm In fact, the selection criteria would be based on the two ones above. The product of the two facts would be evaluated to select the server with least weight for each new session. Say, cost of accessing server S1 is twice as much as that of server S2. In that case, S1 will be assigned twice as much load as that of S2 during the distribution process. When a server is not accessible due to network failure, the cost of access is set to infinity and hence no further load can be assigned to that server. As for how to assign the weight for each criterion, it is upon to what you want to get and what you afford. Authors' Addresses Wanming Luo CNNIC No.4 South 4th Street, Zhongguancun Beijing Phone: +86 10 58813213 Email: luowanming@cnnic.cn Luo, et al. Expires September 23, 2009 [Page 19] Internet-Draft MARCH 2009 Xiaodong LEE CNNIC No.4 South 4th Street, Zhongguancun Beijing Phone: +86 10 58813020 Email: lee@cnnic.cn Wei Mao CNNIC No.4 South 4th Street, Zhongguancun Beijing Phone: +86 10 58812230 Email: mao@cnnic.cn Mei Wang Cisco Systems 170 West Tasman Drive San Jose, CA,95134-1706 USA Phone: 408-853-5842 Email: mei@cisco.com Luo, et al. Expires September 23, 2009 [Page 20]