diff options
Diffstat (limited to 'doc/rfc/rfc4610.txt')
| -rw-r--r-- | doc/rfc/rfc4610.txt | 675 |
1 files changed, 675 insertions, 0 deletions
diff --git a/doc/rfc/rfc4610.txt b/doc/rfc/rfc4610.txt new file mode 100644 index 0000000..7a1804e --- /dev/null +++ b/doc/rfc/rfc4610.txt @@ -0,0 +1,675 @@ + + + + + + +Network Working Group D. Farinacci +Request for Comments: 4610 Y. Cai +Category: Standards Track Cisco Systems + August 2006 + + + Anycast-RP Using Protocol Independent Multicast (PIM) + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2006). + +Abstract + + This specification allows Anycast-RP (Rendezvous Point) to be used + inside a domain that runs Protocol Independent Multicast (PIM) only. + Other multicast protocols (such as Multicast Source Discovery + Protocol (MSDP), which has been used traditionally to solve this + problem) are not required to support Anycast-RP. + +1. Introduction + + Anycast-RP as described in [I1] is a mechanism that ISP-based + backbones have used to get fast convergence when a PIM Rendezvous + Point (RP) router fails. To allow receivers and sources to + Rendezvous to the closest RP, the packets from a source need to get + to all RPs to find joined receivers. + + This notion of receivers finding sources is the fundamental problem + of source discovery that MSDP was intended to solve. However, if one + would like to retain the Anycast-RP benefits from [I1] with less + protocol machinery, removing MSDP from the solution space is an + option. + + This memo extends the Register mechanism in PIM so Anycast-RP + functionality can be retained without using MSDP. + + + + + + + +Farinacci & Cai Standards Track [Page 1] + +RFC 4610 Anycast-RP using PIM August 2006 + + +1.1. 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 [N2]. + +2. Overview + + o A unicast IP address is chosen to use as the RP address. This + address is statically configured, or distributed using a dynamic + protocol, to all PIM routers throughout the domain. + + o A set of routers in the domain is chosen to act as RPs for this RP + address. These routers are called the Anycast-RP set. + + o Each router in the Anycast-RP set is configured with a loopback + interface using the RP address. + + o Each router in the Anycast-RP set also needs a separate IP address, + to be used for communication between the RPs. + + o The RP address, or a prefix that covers the RP address, is injected + into the unicast routing system inside of the domain. + + o Each router in the Anycast-RP set is configured with the addresses + of all other routers in the Anycast-RP set. This must be + consistently configured in all RPs in the set. + +3. Mechanism + + The following diagram illustrates a domain using 3 RPs where + receivers are joining to the closest RP according to where unicast + routing metrics take them and 2 sources sending packets to their + respective RPs. + + The rules described in this section do not override the rules in + [N1]. They are intended to blend with the rules in [N1]. If there + is any question on the interpretation, precedent is given to [N1]. + + + S1-----RP1 RP2 RP3------S3 + / \ | + / \ | + R1 R1' R2 + + + + + + + +Farinacci & Cai Standards Track [Page 2] + +RFC 4610 Anycast-RP using PIM August 2006 + + + Assume the above scenario is completely connected where R1, R1', and + R2 are receivers for a group, and S1 and S3 send to that group. + Assume RP1, RP2, and RP3 are all assigned the same IP address, which + is used as the Anycast-RP address (let's say the IP address is RPA). + + Note, the address used for the RP address in the domain (the + Anycast-RP address) needs to be different than the addresses used by + the Anycast-RP routers to communicate with each other. + + The following procedure is used when S1 starts sourcing traffic: + + o S1 sends a multicast packet. + + o The designated router (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, in this case RP1. + + o RP1 will receive the PIM Register message, decapsulate it, and send + the packet down the shared-tree to get the packet to receivers R1 + and R1'. + + o RP1 is configured with RP2 and RP3's IP address. Since the + Register message did not come from one of the RPs in the anycast-RP + set, RP1 assumes the packet came from a DR. If the Register is not + addressed to the Anycast-RP address, an error has occurred and it + should be rate-limited logged. + + 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 MAY join back to the source-tree by triggering a (S1,G) Join + message toward S1. However, RP1 MUST create (S1,G) state. + + o RP1 sends a Register-Stop back to the DR. If, for some reason, the + Register messages to RP2 and RP3 are lost, then when the Register + suppression timer expires in the DR, it will resend Registers to + allow another chance for all RPs in the Anycast-RP set to obtain + the (S,G) state. + + o RP2 receives the Register message from RP1, decapsulates it, and + also sends the packet down the shared-tree to get the packet to + receiver R2. + + o RP2 sends a Register-Stop back to RP1. RP2 MAY wait to send the + Register-Stop if it decides to join the source-tree. RP2 should + wait until it has received data from the source on the source-tree + + + +Farinacci & Cai Standards Track [Page 3] + +RFC 4610 Anycast-RP using PIM August 2006 + + + before sending the Register-Stop. If RP2 decides to wait, the + Register-Stop will be sent when the next Register is received. If + RP2 decides not to wait, the Register-Stop is sent now. + + o RP2 MAY join back to the source-tree by triggering a (S1,G) Join + message toward S1. However, RP2 MUST create (S1,G) state. + + o RP3 receives the Register message from RP1, decapsulates it, but + since there are no receivers joined for the group, it can discard + the packet. + + o RP3 sends a Register-Stop back to RP1. + + o RP3 creates (S1,G) state so when a receiver joins after S1 starts + sending, RP3 can join quickly to the source-tree for S1. + + o RP1 processes the Register-Stop from each of RP2 and RP3. There is + no specific action taken when processing Register-Stop messages. + + The procedure for S3 sending follows the same as above but it is RP3 + that sends a copy of the Register originated by S3's DR to RP1 and + RP2. Therefore, this example shows how sources anywhere in the + domain, associated with different RPs, can reach all receivers, also + associated with different RPs, in the same domain. + +4. Observations and Guidelines about This Proposal + + o An RP will send a copy of a Register only if the Register is + received from an IP address not in the Anycast-RP list (i.e., the + Register came from a DR and not another RP). An implementation + MUST safeguard against inconsistently configured Anycast-RP sets in + each RP by copying the Time to Live (TTL) from a Register message + to the Register messages it copies and sends to other RPs. + + o Each DR that PIM registers for a source will send the message to + the Anycast-RP address (which results in the packet getting to the + closest physical RP). Therefore, there are no changes to the DR + logic. + + o Packets flow to all receivers no matter what RP they have joined + to. + + o The source gets Registered to a single RP by the DR. It's the + responsibility of the RP that receives the PIM Register messages + from the DR (the closest RP to the DR based on routing metrics) to + get the packet to all other RPs in the Anycast-RP set. + + + + + +Farinacci & Cai Standards Track [Page 4] + +RFC 4610 Anycast-RP using PIM August 2006 + + + o Logic is changed only in the RPs. The logic change is for sending + copies of Register messages. Register-Stop processing is + unchanged. However, an implementation MAY suppress sending + Register-Stop messages in response to a Register received from an + RP. + + o The rate-limiting of Register and Register-Stop messages are done + end-to-end. That is from DR -> RP1 -> {RP2 and RP3}. There is no + need for specific rate-limiting logic between the RPs. + + o When topology changes occur, the existing source-tree adjusts as it + does today according to [N1]. The existing shared-trees, as well, + adjust as they do today according to [N1]. + + o Physical RP changes are as fast as unicast route convergence, + retaining the benefit of [I1]. + + o An RP that doesn't support this specification can be mixed with RPs + that do support this specification. However, the non-supporter RP + should not have sources registering to it, but may have receivers + joined to it. + + o If Null Registers are sent (Registers with an IP header and no IP + payload), they MUST be replicated to all of the RPs in the + Anycast-RP set so that source state remains alive for active + sources. + + o The number of RPs in the Anycast-RP set should remain small so the + amount of non-native replication is kept to a minimum. + + o Since the RP, who receives a Register from the DR, will send copies + of the Register to the other RPs at the same time it sends a + Register-Stop to the DR, there could be packet loss and lost state + in the other RPs until the time the DR sends Register messages + again. + +5. Interaction with MSDP Running in an Anycast-PIM Router + + The objective of this Anycast-PIM proposal is to remove the + dependence on using MSDP. This can be achieved by removing MSDP + peering between the Anycast-RPs. However, to advertise internal + sources to routers outside of a PIM routing domain and to learn + external sources from other routing domains, MSDP may still be + required. + + + + + + + +Farinacci & Cai Standards Track [Page 5] + +RFC 4610 Anycast-RP using PIM August 2006 + + +5.1. Anycast-PIM Stub Domain Functionality + + In this capacity, when there are internal sources that need to be + advertised externally, an Anycast-RP that receives a Register + message, either from a DR or an Anycast-RP, should process it as + described in this specification as well as how to process a Register + message as described in [N1]. That means a Source-Active (SA) for + the same internal source could be originated by multiple Anycast-RPs + doing the MSDP peering. There is nothing inherently wrong with this + other than that the source is being advertised into the MSDP + infrastructure from multiple places from the source domain. However, + if this is not desirable, configuration of one or more (rather than + all) Anycast-RP MSDP routers would allow only those routers to + originate SAs for the internal source. And in some situations, there + is a good possibility not all Anycast-RPs in the set will have MSDP + peering sessions so this issue can be mitigated to a certain extent. + + From an Anycast-RP perspective, a source should be considered + internal to a domain when it is discovered by an Anycast-RP through a + received Register message, regardless of whether the Register message + was sent by a DR, another Anycast-RP member, or the router itself. + + For learning sources external to a domain, the MSDP SA messages could + arrive at multiple MSDP-peering Anycast-RPs. The rules for + processing an SA, according to [I1], should be followed. That is, if + G is joined in the domain, an (S,G) join is sent towards the source. + And if data accompanies the SA, each Anycast-PIM RP doing MSDP + peering will forward the data down each of its respective shared- + trees. + + The above assumes each Anycast-RP has external MSDP peering + connections. If this is not the case, the Anycast-PIM routers with + the MSDP peering connections would follow the same procedure as if a + Data-Register or Null-Register was received from either a DR or + another Anycast-RP. That is, they would send Registers to the other + members of the Anycast-RP set. + + If there is a mix of Anycast-RPs that do and do not have external + MSDP peering connections, then the ones that do must be configured + with the set that do not. So Register messages are sent only to the + members of the Anycast-RP set that do not have external MSDP peering + connections. + + The amount of Register traffic generated by this MSDP-peering RP + would be equal to the number of active sources external to the + domain. The Source-Active state would have to be conveyed to all + other RPs in the Anycast-RP set since the MSDP-peering RP would not + know about the group membership associated with the other RPs. To + + + +Farinacci & Cai Standards Track [Page 6] + +RFC 4610 Anycast-RP using PIM August 2006 + + + avoid this periodic control traffic, it is recommended that all + Anycast-RPs be configured with external MSDP peering sessions so no + RP in the Anycast-RP set will have to originate Register messages on + behalf of external sources. + +5.2. Anycast-PIM Transit Domain Functionality + + Within a routing domain, it is recommended that an Anycast-RP set + defined in this specification should not be mixed with MSDP peering + among the members. In some cases, the source discovery will work but + it may not be obvious to the implementations which sources are local + to the domain and which are not. This may affect external MSDP + advertisement of internal sources. + + Having said that, this document makes no attempt to connect MSDP + peering domains together by using Anycast-PIM inside a transit + domain. + +6. Security Consideration + + This section describes the security consideration for Register and + Register-Stop messages between Anycast-RPs. For PIM messages between + DR and RP, please see [N1]. + +6.1. Attack Based On Forged Messages + + An attacker may forge a Register message using one of the addresses + in the Anycast-RP list in order to achieve one or more of the + following effects: + + 1. Overwhelm the target RP in a denial-of-service (DoS) attack + 2. Inject unauthorized data to receivers served by the RP + 3. Inject unauthorized data and create bogus SA entries in other + PIM domains if the target RP has external MSDP peerings + + 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. + +6.2. Protect Register and Register-Stop Messages + + The DoS attack using forged Register or Register-Stop messages cannot + be prevented. But the RP can still be protected. For example, the + RP can rate-limit incoming messages. It can also choose to refuse to + process any Register-Stop messages. The actual protection mechanism + is implementation specific. + + + + +Farinacci & Cai Standards Track [Page 7] + +RFC 4610 Anycast-RP using PIM August 2006 + + + The distribution of unauthorized data and bogus Register messages can + be prevented using the method described in section 6.3.2 of [N1]. + When RP1 sends a copy of a register to RP2, RP1 acts as [N1] + describes the DR and RP2 acts as [N1] describes the RP. + + As described in [N1], an RP can be configured using a unique SA and + Security Parameter Index (SPI) for traffic (Registers or Register- + Stops) to each member of Anycast-RPs in the list, but this results in + a key management problem; therefore, it may be preferable in PIM + domains where all Rendezvous Points are under a single administrative + control to use the same authentication algorithm parameters + (including the key) for all Registered packets in a domain. + +7. Acknowledgements + + The authors prototyped this document in the cisco IOS and Procket + implementations, respectively. + + The authors would like to thank John Zwiebel for doing + interoperability testing of the two prototype implementations. + + The authors would like to thank Thomas Morin from France Telecom for + having an extensive discussion on Multicast the Registers to an SSM- + based full mesh among the Anycast-RP set. This idea may come in a + subsequent document. + + And finally, the authors would like to thank the following for their + comments on earlier drafts: + + Greg Shepherd (Procket Networks (now Cisco Systems)) + Lenny Giuliano (Juniper Networks) + Prashant Jhingran (Huawei Technologies) + Pekka Savola (CSC/FUNET) + Bill Fenner (AT&T) + James Lingard (Data Connection) + Amit Shukla (Juniper Networks) + Tom Pusateri (Juniper Networks) + + + + + + + + + + + + + + +Farinacci & Cai Standards Track [Page 8] + +RFC 4610 Anycast-RP using PIM August 2006 + + +8. References + +8.1. Normative References + + [N1] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, + "Protocol Independent Multicast - Sparse Mode (PIM-SM): + Protocol Specification (Revised)", RFC 4601, August 2006. + + [N2] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + +8.2. Informative References + + [I1] Kim, D., Meyer, D., Kilmer, H., and D. Farinacci, "Anycast + Rendevous Point (RP) mechanism using Protocol Independent + Multicast (PIM) and Multicast Source Discovery Protocol (MSDP)", + RFC 3446, January 2003. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Farinacci & Cai Standards Track [Page 9] + +RFC 4610 Anycast-RP using PIM August 2006 + + +Appendix A: Possible Configuration Language + + A possible set of commands to be used could be: + + ip pim anycast-rp <anycast-rp-addr> <rp-addr> + + Where: + + <anycast-rp-addr> describes the Anycast-RP set for the RP that is + assigned to the group range. This IP address is the address that + first-hop and last-hop PIM routers use to register and join to. + + <rp-addr> describes the IP address where Register messages copies + are sent to. This IP address is any address assigned to the RP + router not including the <anycast-rp-addr>. + + Example: + + From the illustration above, the configuration commands would be: + + ip pim anycast-rp RPA RP1 + ip pim anycast-rp RPA RP2 + ip pim anycast-rp RPA RP3 + + Comment: + + It may be useful to include the local router IP address in the + command set so the above lines can be cut-and-pasted or scripted + into all the RPs in the Anycast-RP set. + + But the implementation would have to be aware of its own address + and not inadvertently send a Register to itself. + + + + + + + + + + + + + + + + + + + +Farinacci & Cai Standards Track [Page 10] + +RFC 4610 Anycast-RP using PIM August 2006 + + +Authors' Addresses + + Dino Farinacci + Cisco Systems + + EMail: dino@cisco.com + + + Yiqun Cai + Cisco Systems + + EMail: ycai@cisco.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Farinacci & Cai Standards Track [Page 11] + +RFC 4610 Anycast-RP using PIM August 2006 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2006). + + 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 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. + +Acknowledgement + + Funding for the RFC Editor function is provided by the IETF + Administrative Support Activity (IASA). + + + + + + + +Farinacci & Cai Standards Track [Page 12] + |