Internet Engineering Task Force Yunyong Zhang IPv6 Working Group Yunjie Liu INTERNET-DRAFT Zhijiang Zhang Expires: October 1, 2004 China United Telecommunications Corporation April 1, 2004 Minimum TCP connections based anycast routing protocol draft-zhangyy-ipv6-anycast-routing-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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.'' To view the list Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html. Distribution of this memo is unlimited. The internet-draft will expire in 6 months. The date of expiration will be July 1, 2004. Abstract The memo tries to construct a minimum TCP connections based IPv6 anycast routing protocol, so as to avoid the congestion problem of the nearest server and improve the network performance. Table of Contents 1. Introduction................................................2 2. Terminology.................................................2 3. New Message.................................................3 3.1 Anycast Routing Table Update Request Message...............3 3.2 Anycast Routing Table Update Advertisement Message.........3 4. Description of Process......................................4 4.1. Client-Anycast Routers Process............................5 4.2. Server-Local Anycast Routers Process......................5 4.3. Local Anycast Router-Anycast Routers Process..............5 ZHANG, LIUú¼ZHANG Expires: October 1, 2004 [Page 1] INTERNET-DRAFT draft-zhangyy-ipv6-anycast-routing-00.txt Apr 2004 4.3.1 ARU Advertisement Process................................5 4.3.2 ARU Require Process......................................6 5. Analysis of minimum TCP connections based anycast routing protocol....................................................6 6.IANA Considerations .........................................7 7. Security Considerations.....................................7 8. Acknowledgments.............................................7 9. References..................................................7 10. Authors' addresses.........................................8 11. Intellectual Property Rights Notice........................8 12. Full Copyright Statement...................................9 1. Introduction "Anycast" is a communication model for IP, just like unicast and multicast are. Anycast can be understood best by comparing with unicast and multicast. IP unicast allows a source node to transmit IP datagrams to a single destination node. The destination node is identified by a unicast address. IP multicast allows a source node to transmit IP datagrams to a group of destination nodes. The destination nodes are identified by a multicast group, and we use a multicast address to identify the multicast group. IP anycast allows a source node to transmit IP datagrams to a single destination node, out of a group of destination nodes. IP datagrams will reach the closest destination node in the set of destination nodes, based on the routing measure of distance. The source node does not need to care about how to pick the closest destination node, as the routing system will figure it out (in other words, the source node has no control over the selection). The set of destination nodes is identified by an anycast address. But sometimes the closet destination node is not the best node (for example, its processing capability is not the best one) and even cannot process any request extremely, so it will cause network congestion. In this draft, we modify traditional IPv6 anycast routing protocol to be based on minimum TCP connections routing measure. 2. Terminology 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 [Bradner, 1997]. Anycast Router Routers which is assigned anycast address. Local Anycast Router Anycast router linked to a specified server. Anycast Routing Table Routing table of anycast router,includes anycast address, unicast ZHANG, LIUú¼ZHANG Expires: October 1, 2004 [Page 2] INTERNET-DRAFT draft-zhangyy-ipv6-anycast-routing-00.txt Apr 2004 address and numbers of connections N. Anycast Routing Table Update Message Packet used to update anycast routing table in anycast routers, includes request message and advertisement message. 3. New Message In this draft, a new message ARU(Anycast Routing table Update) is introduced. It is comprised of ARU request message and ARU advertisement message. Local anycast router sends ARU advertisement message periodically to update the routing table which has the same anycast address. Anycast router can also update its routing table using ARU request message to request its corresponding local anycast router to send ARU advertisement message. According to ICMPv6 format [Conta, 2001], structures of ARU request and advertisement message are shown in figure 1 and figure 2. 3.1. Anycast Routing Table Update Request Message 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identifier | Reserved |A| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1 Anycast Routing Table Update Request Message format ICMPv6 Fields: Type type of ICMP message and is allocated by IANA. Code depends on the message type. It is used to create an additional level of message granularity, and is set to zero. Checksum is used to detect data corruption in the ICMPv6 message and parts of the IPv6 header. Identifier an identifier used to match advertisement message to this request message. Reserved unsed field. It MUST be initialized to zero. A one anycast bit, initialized to 1 to indicate that the following is 128 bits anycast address(With RFC 2373, anycast address can not be distinguishable from unicast address). 3.2. Anycast Routing Table Update Advertisement Message ZHANG, LIUú¼ZHANG Expires: October 1, 2004 [Page 3] INTERNET-DRAFT draft-zhangyy-ipv6-anycast-routing-00.txt Apr 2004 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identifier | Reserved |A| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Anycast address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Unicast address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2 Anycast Routing Table Update Advertisement Message format ICMPv6 Fields: Type type of ICMP message and is allocated by IANA. Code depends on the message type. It is used to create an additional level of message granularity, and is set to zero. Checksum is used to detect data corruption in the ICMPv6 message and parts of the IPv6 header. Identifier an identifier used to match advertisement message to this request message. Reserved unsed field. It MUST be initialized to zero. A one anycast bit, initialized to 1 to indicate that the following is 128 bits anycast address(With RFC 2373, anycast address can not be distinguishable from unicast address). Anycast address anycast of anycast router. Unicast address unicast address item in anycast routing table. Data number of connections item in anycast routing table. 4. Description of Process Minimum TCP connections based anycast routing protocol comprises of three-communication process shown in figure 3. ZHANG, LIUú¼ZHANG Expires: October 1, 2004 [Page 4] INTERNET-DRAFT draft-ietf-zhangyy-ipv6-anycast-routing-00.txt Apr 2004 Client Anycast Router Local Anycast Router Server + + + + | | | | | | | | | 4.1 | | 4.2 | | íµ========í¸ | | íµ======== | | | | | | | 4.3 | | | | íµ========í¸ | | | | | | + + + + Figure 3 Three-communication process in anycast routing protocol 4.1. Client-Anycast Routers Process Alorithm of Client: ICMP ECHO request message_sending If a Client needs anycast service Then Let source address field of ICMP ECHO request message be the IP address of Client Let destination address field of ICMP ECHO request message be anycast address corresponding to the servie. Algorithm of Anycast Routers:ICMP ECHO reply message_receiving If a Anycast router receives the ICMP ECHO request message Then Let source address field of ICMP ECHO reply message be the IP address of sending interface Let destination address field of ICMP ECHO request message be source address field of the corresponding request message. 4.2. Server-Local Anycast Routers Process Algorithm of server:current TCP Connection number_reporting The server termly reports its current TCP connection number to Local anycast router Algorithm of local anycast router:TCP connection number_receiving If TCP connection number received>TCP connection maintained in anycast routing table Then keep current anycast routing table Else Update corresponding unicast address field and connection number items of the anycast routing table. 4.3. Local Anycast Router-Anycast Routers Process 4.3.1 ARU Advertisement Process Algorithm of Local anycast router: ARU advertisement message_sending If a client needs anycast service Then ZHANG, LIUú¼ZHANG Expires: October 1, 2004 [Page 5] INTERNET-DRAFT draft-zhangyy-ipv6-anycast-routing-00.txt Apr 2004 Let source address field of ARU advertisement message be the IP address of sending interface Destination address field of ARU advertisement message is FF02:2 Algorithm of anycast router: ARU advertisement message_receiving If TCP connection number received> TCP connection number maintained in anycast routing table Then keep current anycast routing table Else update corresponding unicast address item and connection number item of the anycast routing table 4.3.2 ARU Request Process If anycast router needs to update its anycast routing table, it can also send ARU request message, and the local anycast router which receives this request message sends ARU advertisement message. The algorithm is shown as the following: Algorithm of some anycast router;ARU request message_sending If some anycast router needs to update its anycast routing table Then Let source address field of ARU request message be the IP address of sending interface Let destination address field of ARU request message be anycast address corresponding to the service Algorithm of local anycast routers: ARU request message_receiving Let source address field of ARU advertisement message be the IP address of sending interface Destination address field of ARU advertisement message is FF02::2. Let anycast address field of ARU advertisement message be the anycast address corresponding its anycast service Let unicast address field of ARU advertisement message be the unicast item of the anycast routing table Let data field of ARU advertisement message be the TCP connection number item of anycast routing table 5. Analysis of minimum TCP connections based anycast routing protocol Minimum TCP connections based anycast routing protocol has following advantages; Responding time of serverí¯s address is reduced. Unicast address of server is not provided by server but anycast router. Overload of server is also reduced. Performance of network transportation is increased. Congestion is partly avoided and usage of network resource is also increased. The new anycast routing protocol is transparent to client. ZHANG, LIUú¼ZHANG Expires: October 1, 2004 [Page 6] INTERNET-DRAFT draft-zhangyy-ipv6-anycast-routing-00.txt Apr 2004 6.IANA Considerations Following the policies outlined in [Nartenú¼ 1998], new values of the type field in the New Message (section 3) and the Code field of the New Message (section 3) are to be allocated by IETF consensus only. 7. Security consideration The document should introduce no new security issues. When anycast address is used to discover a server and then switch to unicast address for the server, upper-layer protocols need to make sure that the two addresses actually belong to the same node. Otherwise, there could be a chance for malicious nodes to hijack the communication[Haginoú¼2003]. One possible way to achieve this is to use public-key based authentication in the upper-layer protocol. For secure anycast operation, we may need to enable security mechanisms in other protocols. For example, if we were to inject /128 routes from end hosts by using a routing protocol, we may need to configure the routing protocol to exchange routes securely, to prevent malicious parties from injecting bogus routes. 8. Acknowledgments The authors would like to thank professor Jinde Liu and for his careful review. 9. References Bradner, 1997 S. Bradner, í—Key words for use in RFCs to Indicate Requirement Levelsí˜ in RFC (Best Current Practice) 2119(March 1997). ftp://ftp.isi.edu/in-notes/rfc2119.txt. Hinden, 1998. R. Hinden and S. Deering, "IP Version 6 Addressing Architecture" in RFC2373 (July 1998). http://www.ietf.org/rfc/rfc2373.txt. Haginoú¼ 2003. Jun-ichiro itojun Hagino, " An analysis of IPv6 anycast " in draft-ietf-ipngwg-ipv6-anycast-analysis-02.txt (June 2003). work in progress material. Nartenú¼ 1998. Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. Conta, 2001 Conta ,í—Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specificationí˜ in draft-ietf-ipngwg-icmp- v3-02.txt(November 2001). work in progress material. ZHANG, LIUú¼ZHANG Expires: October 1, 2004 [Page 7] INTERNET-DRAFT draft-zhangyy-ipv6-anycast-routing-00.txt Apr 2004 10. Authors' addresses Yunyong Zhang Department of Technologyú¼ China United Telecommunications Corporationú¼ No.133A, Xidan North Street,Xichen Districtú¼ Beijingú¼100032ú¼China P. R Tel: +86-10-6650-5740 Fax: +86-10-6650-4252 E-mail: zhangyy@chinaunicom.com.cn Yunjie Liu China United Telecommunications Corporationú¼ No.133A, Xidan North Street,Xichen Districtú¼ Beijingú¼100032ú¼China P. R Tel: +86-10-6650-5115 Fax: +86-10-6650-4252 E-mail: liuyj@chinaunicom.com.cn Zhijiang Zhang Department of Technologyú¼ China United Telecommunications Corporationú¼ No.133A, Xidan North Street,Xichen Districtú¼ Beijingú¼100032ú¼China P. R Tel: +86-10-6650-5120 Fax: +86-10-6650-4252 E-mail: zhangzhj@chinaunicom.com.cn 11. Intellectual Property Rights Notice The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. ZHANG, LIUú¼ZHANG Expires: October 1, 2004 [Page 8] INTERNET-DRAFT draft-zhangyy-ipv6-anycast-routing-00.txt Apr 2004 12. Full Copyright Statement Copyright (C) The Internet Society (2004). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. This document expires October 1, 2004. ZHANG, LIUú¼ZHANG Expires: October 1, 2004 [Page 9]