Internet Engineering Task Force PIM WG Internet-Draft Chunyan Yao/ASB Intended status:Proposed Standard draft-yao-pim-anycast-rp-autoconfiguration-00.txt March 2007 Expires: September 2007 Anycast RP auto-configuration Status of this Document By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of 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 16, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Yao [Page 1] INTERNET-DRAFT Expires: September 2007 March 2007 Abstract Anycast RP (Rendezvous Point) is widely supported by router vendors. Each RP in the anycast RP set is configured with the RP Address (RPA), and the addresses of all members/routers in the anycast-RP set. If the number of anycast RP members is more than 1, manual configuration of RP information is prone to inconsistency which can cause connectivity problems, especially when the addresses are IPv6 address or the members of anycast RP set need to be changed (e.g.some new members are added, or some old members are removed from the anycast RP set). Aiming to this problem, this document provides a mechanism to automatically configure anycast RP members/routers. In this mechanism,only one RP member/router in the anycast RP set needs to be configured firstly, so it knows the anycast RP address and the addresses of all members in the anycast RP set. It sends anycast RP configuration information (including the anycast RP address and an address list) to each of other member in the anycast-RP set. Other members will check the information and configure itself after receiving the anycast RP configuration information,and respond the firstly configured RP with checking results and configuration results. Yao [Page 2] INTERNET-DRAFT Expires: September 2007 March 2007 1. Introduction Anycast RP using PIM [N1] was specified in [N2]. It is a mechanism that ISP-based backbones have used to get load balance between RP members and fast convergence when a RP router fails. Anycast RP is widely supported by router vendors. Each RP in the anycast RP set is configured with the RP Address (RPA), and the addresses of all members/routers in the anycast RP set. If the number of anycast RP members is more than 1, manual configuration of RP information is prone to inconsistency which can cause connectivity problems, especially when the addresses are IPv6 address or the members of anycast RP set need to be changed (e.g. some new members are added, or some old members are removed from the anycast RP set). This document specifies an auto-configuration mechanism in anycast RP. In this mechanism, only one RP member/router in the anycast RP set needs to be configured firstly with the anycast RP address and the addresses of all members in the anycast RP set. Then it sends anycast RP configuration information (including the anycast RP address and an address list containing the addresses for all the anycast RP members) to each of other member in the anycast-RP set. After receiving the anycast RP configuration information, every anycast RP member configures itself and sends response to the firstly configured RP to inform the configuration results: done or error or no response. 1.1. Terminology The following terms have special significance for this document: Anycast RP Configuration Information (ACI): The information configured on all members of the anycast RP set to implement anycast RP relative function. Here it includes the anycast RP address and the addresses of all members in the anycast RP set. Firstly Configured RP (FCR):The member in the anycast RP set firstly configured with the ACI: anycast RP configuration information. Main RP In Anycast-RP, a set of Rendevous Points (RPs) are allowed per group in a PIM-SM domain, and an anycast address is used as the RP address of the set of RP. The unicast routing system will deliver the PIM Register message to the nearest RP, which is named as main RP. Yao [Page 3] INTERNET-DRAFT Expires:September 2007 March 2007 2. Problem definition The problem is detailed as follows: Anycast RP is widely supported by router vendors. Each RP in the anycast RP set is configured with the RP Address (RPA), and the addresses of all members/routers in the anycast-RP set. If the number of anycast-RP members is more than 1, manual configuration of RP information is prone to inconsistency which can cause connectivity problems, especially when the addresses are IPv6 address or the members of anycast RP set need to be changed (e.g. some new members are added, or some old members are removed from the anycast RP set). 3. Anycast RP auto-configuration mechanism The pre-condition of this auto-configuration mechanism is: 1. This function should be supported in every PIM routers in the PIM-SM domain; 2. This function should be used after all PIM routers in the PIM-SM domain have completed basic unicast routing configuration. The anycast RP auto-configuration procedure is detailed as follows : 1. Configuring FCR One member of the anycast RP set can become the Firstly Configured RP (FCR) by some way, e.g: the network administrator selects one anycast RP member suiting his/her convenience as the Firstly Configured RP (FCR), and configure it with the anycast RP configuration information (including the anycast RP address and the addresses of all members in the anycast RP set), or the selected member gets the anycast RP configuration information from other protocol module or other server, for example, anycast group management protocol or anycast service management server. Now the FCR knows the RP address and addresses of all anycast RP members. 2. FCR sending ACN and receiving ACE FCR sends anycast RP Configuration Notification (ACN) message including anycast-RP configuration information to each of other members in the anycast RP set. For each member, after receiving the anycast-RP configuration information, it configures itself and returns response with "anycast RP Configuration Echo (ACE)" message to FCR to inform the configuration results: done or error. If it returns error, the reason should be returned together. If there is no any ACE message in a period (e.g.60s), the FCR regards the member as "no response". All above messages should be sent in TCP connection. Yao [Page 4] INTERNET-DRAFT Expires: September 2007 March 2007 3. Configuration results processing After the FCR reaches a conclusion for each of the other members, "done " or "error" or "no response", it returns the results to network administrator. If there is "error" or "no response" returned to the network administrator, debugging should be done. 4. Adding a new member If a new member needs to be added into the anycast set, two methods can be used. The first one is: There is a new member's unicast address needing to be added into the anycast RP configuration information. The new member's unicast address can be added on any one member of the previous anycast RP set by manual configuration or other protocol module or some server. The reconfigured member becomes the FCR, then it sends ACN including the anycast RP configuration information change to the other members in this anycast RP set to update the anycast RP configuration information automatically. After the newly added one received the ACN, it will construct the anycast RP configuration information on itself and signal its routing system the anycast routing change, its routing system will declare the change to its routing peers. Other anycast RP members will update its anycast RP configuration information. The second one is: the new member is reconfigured with RPA and new address list, which will become the FCR, After the newly added one knows the configuration, it will construct the anycast RP configuration information on itself and send the new anycast RP configuration information to all other members in the new anycast member list by ACN message. Meanwhile, the FCR signals its routing system the anycast routing change, its routing system will declare the change to its routing peers. Other anycast RP members will update its anycast RP configuration information after receiving the new anycast RP configuration information. Configuration results will be returned to the network administrator. 5. Deleting a member If one member needs to be deleted from the anycast set, two methods can be used. The method 1 is: on any one member which is not the one to be deleted, the member's unicast address in the anycast RP configuration information is deleted. This member with changed anycast RP configuration information will become the FCR, then it sends ACN to all other members in this anycast RP set (including the one to be deleted) to update the anycast RP configuration information automatically. The change of the anycast RP configuration information is included in the ACN. When the anycast Yao [Page 5] INTERNET-DRAFT Expires: September 2007 March 2007 RP member to be deleted received this ACN, it deletes the anycast RP configuration information, and signal the anycast routing change to its routing system, its routing system updates anycast routing entry and declares the anycast routing entry change to its routing peers. After the main RP knows the change of anycast RP configuration information, it will cancel the timer for the deteled anycast RP member if the timer is still running, and update the anycast RP configuration information. After the other anycast RP members know the change of anycast RP configuration information, they will update their anycast RP configuration information respectively. The method 2 is that the anycast RP member to be deleted is Changed the anycast RP configuration information firstly. The anycast RP member to be deleted will send the configuration change to all other anycast RP members, then it deletes the anycast-RP configuration information, and signal the anycast routing change to its routing system.as described in method 1. The main RP and other anycat-RP members will process the configuration change in ACN sent from the anycast RP member to be deleted as described in method 1. In all above steps, after ACN or configuration is received by any one RP being in the anycast-RP set or to be deleted or to be added, the ACN will be checked at first. If the ACN is not valid, the error reason is included in the ACE and send to the FCR, and the anycast RP configuration information included in the received ACN can not be used to configure the equipment which received the ACN. 4. IANA Considerations This document makes no request to IANA. Note to RFC Editor: this section may be removed on publication as an RFC. 5. Security Consideration Messages (ACN and ACE) used in this patent can be protected by IP security. In PIM domains where all RPs are under a single administrative control, the same authentication algorithm parameters (including the key) can be used for all anycast RP auto-configuration messages (ACN and ACE) in a PIM-SM domain. Yao [Page 6] INTERNET-DRAFT Expires:September 2007 March 2007 6. Acknowledgments The authors would like to thank the following colleagues: Haibo Wen, Renxiang Yan for valuable comments and suggestions on the whole draft. 7. Author Information Yao Chunyan Alcatel Shanghai Bell Chunyan.yao@alcatel-sbell.com.cn 8. Normative References [N1] Fenner, Handley, Holbrook, Kouvelas, "Protocol Independent Multicast-Sparse Mode (PIM-SM):Protocol Specification (Revised)" ,RFC4601, August 2006. [N2] Dino Farinacci, Yiqun Cai,"Anycast RP mechanism using PIM ", RFC4610, August 2006. Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Yao [Page 6] INTERNET-DRAFT Expires:September 2007 March 2007 Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Yao [Page 7]