Internet Engineering Task Force PIM WG Internet-Draft Chunyan Yao/ASB Intended status: Proposed Standard Haibo Wen/ASB draft-yao-pim-cooperation-register-00.txt March 2007 Expires: September 2007 Cooperation register mechanism in Anycast RP 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) protocol [N2] is designed to provide load balancing and failover for RP. However, there is no cooperation mechanism among anycast RP members when sending Register-Stop to DR and transferringRegisters among anycast RP members. The former results in the subscribers under some Anycast RP members having multicast service interruption and the latter leads to bandwidth waste among Anycast RP members due to trashy Registers. This specification solves these problems by giving the cooperation mechanism among anycast RP members. Yao [Page 2] INTERNET-DRAFT Expires: September 2007 March 2007 1. Introduction Anycast-RP was specified in [N2]as using PIM [N1]. As described 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. In [N2],the unicast routing system will deliver the PIM Register message to the nearest RP, which is named as the main RP, and the other Anycast RP members are named as the active RPs. There is no cooperation among main RP and active RPs specified in [N2] on sending Register-Stop. Further more, in [N2], the main RP transfers Registers to all active RPs without considering whether the active RP still needs Registers, which leads to bandwidth waste between main RP and the active RP. This document specifies processing actions in the main RP when it "Receiving Registers and Register-Stop": Before the main RP sends Register-Stop to DR and sends Registers to active RPs, it should judge whether the active RPs have sent it register-stop recently. Only if all the other anycast members have sent it register-stop recently, it can send Register-Stop to DR, and only if it has not received any Register-Stop recently from one specific active RP, it can send Registers to that specific RP. 1.1. Terminology The following terms have special significance for this document: 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. Active RP: The anycast RP members except the main RP are named active RPs. 2. Problem definition The problem is detailed as follows: According to [N2], Anycast RP mechanism works as following: As illustrated in Figure.1, it's assumed that R1, R1', R2 and R3 are receivers for a group, and S1 sends to that group. Assume RP1, RP2 and RP3 are are anycast RP members, and are all assigned the same IP address which is used as the Anycast-RP address. Yao [Page 3] INTERNET-DRAFT Expires: August 2007 March 2007 The following procedure is used when S1 starts sourcing traffic: o S1 sends a multicast packet. The DR directly attached to S1 will form a PIM Register message to send to the Anycast-RP Address (RPA). The unicast routing system will deliver the PIM Register message to the nearest RP, i.e. the main RP, in this case RP1. o RP1 will then send a copy of the Register message from S1's DR to both RP2 and RP3. RP1 will use its own IP address as the source address for the PIM Register message. o RP1 sends a Register-Stop back to the DR. o When RP2 and RP3 receive the Register message from RP1, they will send a Register-Stop back to the RP1 respectively. o RP1 processes the Register-Stop from each of RP2 and RP3. There is no specific action taken when processing Register-Stop messages. S1-----RP1 RP2 RP3 / \ | | / \ | | R1 R1' R2 R3 Figure 1. The problem is: RP1 sends Register-Stop to DR without considering that RP2 and RP3 may still need Register messages from RP1, because the shortest multicast delivery paths from sender's DR to RP2 and RP3 may haven't been established, which results in subscribers' multicast service could be interrupted. RP1 sends Registers to RP2 and RP3 without considering that RP2 and RP3 may not need them any more recently, because the shortest multicast delivery paths from the sender's DR to RP2 and RP3 may have been constructed, which results in RP1's CPU resource waste and bandwidth waste among Anycast RP members. 2.1 Problem scenario 1 As illustrated in Figure.1, the source tree from DR to RP1 has been completed but the source trees from DR to RP2 and RP3 have not been completed yet, according to PIM-SM, RP1 sends Register-Stop to DR when receiving native multicast from the sender. According to [N2], RP1 sends Register-Stop to DR without considering cooperation with RP2 and RP3's Register-Stop. If RP1 sends a Register-Stop before receiving Register-Stop from RP2 and RP3, DR will stop sending Registers to RP1 in Register- suppression time interval, so RP2 and RP3 cannot receive Registers from RP1, and R2 and R3's multicast service will be interrupted. Yao [Page 4] INTERNET-DRAFT Expires: September 2007 March 2007 2.2 Problem scenario 2 S1-----RP1 RP2 RP3 | | | | R2 R3 Figure 2. Another service interruption will occur as illustrated in Figure 2. In this situation, there is no any receiver under RP1 and the source trees from DR to RP2 and RP3 have not been completed constructing yet, but the source trees from DR to RP1 has been completed constructing. According to PIM-SM register mechanism in [N1] and [N2], after receiving a register from DR, RP1 sends a Register-Stop (for no receivers under it) to DR without receiving Register-Stop from RP2 and RP3. DR stops sending register to RP1 during its Register-suppression interval after it receiving the Register-Stop. Hence RP2 and RP3 can get neither registers nor native multicast packet during that period, which resulted the multicast services interruption for receiver R2 and R3. 2.3 Problem scenario 3 The third scenario can be illustrated with Figure.1. In the situation, the two source trees from DR to RP2 and RP3 have been established but the source tree from DR to RP1 has not been completed establishing yet. Hence RP1 can receive Registers from DR. According to [N2], RP1 will then send a copy of the Register message from S1's DR to both RP2 and RP3. According to [N1], RP2 and RP3 will send Register-Stop to RP1 because both have already received native multicast data packets from source tree from DR to them. According to [N2], there is no specific action taken when processing Register-Stop messages, which results in RP1 continues to send registers to RP2 and RP3 without thinking that RP2 and RP3 do not need Registers any more recently. Thus RP1 wastes its CPU resources and bandwidth to send trashy registers to RP2 and RP3. Obviously, some cooperation mechanism should be added to the main RP. To overcome multicast service interruption and the resource waste resulted from reason mentioned above, this document investigates an Cooperation register mechanism in Anycast RP. 3. Solution The basic idea of the solution is: Adding processing actions in the main RP when it "Receiving Registers and Register-Stop": Before the main RP sends Register-Stop to DR and send Registers to other anycast RP members,it should judge whether all the other anycast members have Yao [Page 5] INTERNET-DRAFT Expires: September 2007 March 2007 sent it register-stop recently. Only if all the other anycast members have sent it Register-Stop recently, it can send Register- Stop to DR, and only if it has not received any Register-Stop recently from one anycast RP member, it can send Registers to that Anycast RP member. 3.1 Mechanism The following functions are added in main RP: 1. After the main RP sending Registers to other anycast RP members, when it receives Register-Stop from an active RP, it starts a Register-Stop Collective Timer (RSCT, default 60s). If there is no Register-Stop arriving until RSCT expires, RSCT will be canceled. If there is Register-Stop arriving when RSCT is running, it will be reset. 2. One condition should be added when deciding whether to send a Register-Stop to DR. Originally, the conditions are described in part 4.4.2. of [N1]: if ((C1 OR C2 AND C3 ) is TRUE), a Register-Stop is sent to DR. C1 denotes source tree from DR to RP1 has been constructed; C2 denotes a policy function that is implementation defined. An "infinite threshold"policy can be implemented making C2 return false all the time. A "switch on first packet" policy can be implemented by making C2 return true once a single packet has been received for the source and group. C3 denotes the output-interface list that is relevant for forwarding a packet from S to G using both source-specific and group-specific state is NULL. Now we change the condition into: if ( ((C1 OR C2 AND C3 ) AND C4) is TRUE), a Register-Stop will be sent to DR from the main RP(RP1). C4 denotes every RSCT corresponding to each active RP (In Figure 1, they are RP2 and RP3) is running, which means all the other Anycast RP members have sent the main RP register-stop recently. 3. Before the main RP sends Registers received from DR to any Anycast RP member (active RP), it should see whether the corresponding RSCT is running. If it is,then the main RP need not send Registers to that active RP, or else the main RP should send registers to that active RP as specified in [N2]. As to how one RP knows itself is the main RP or active RP, the following method is used: According to RFC4610, each router in the Anycast-RP group is configured with the addresses of all other routers in the Anycast-RP group. This must be consistently configured in all RPs in the group. So one RP can see the received Register's Yao [Page 6] INTERNET-DRAFT Expires: September 2007 March 2007 source IP address, if the source IP address is not in the IP address list of anycast RP group members, then it thinks the Register comes from DR, if the source IP address is one in the IP address list of anycast RP group members, then it thinks itself is the active RP, and the anycast RP member with the source IP address is the main RP. 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 In this memo, there is a small difference in security consideration, and others are the same with [N2]. The small difference is:in part 5.1 of [N2], it says :"An attacker may also forge a Register-Stop message using one of the addresses in the Anycast-RP list. However, besides denial-of-service, the effect of such an attack is limited because an RP usually ignores Register- Stop messages. " But in this memo, Register-Stop messages from active RPs must be processed by the main RP, so the effect of above attack should be prevented. Fortunately, [N2] have provided security consideration for Register-Stop messages between Anycast-RPs. For the protection of Register messages and PIM messages between DR and RP,it is same as [N2]. 6. Acknowledgments The authors would like to thank the following colleagues for their comments on earlier drafts:Haibo Wen, Songwei Ma, Renxiang Yan, Qingshan Zhang, Fanxiang Bin. 7. Author Information Yao Chunyan Alcatel Shanghai Bell Chunyan.yao@alcatel-sbell.com.cn Wen Haibo Alcatel Shanghai Bell Haibo.wen@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. Yao [Page 7] INTERNET-DRAFT Expires: September 2007 March 2007 [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. 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 8]