draft-ietf-mboned-anycast-rp-08.txt   rfc3446.txt 
MBONED Working Group Dorian Kim
Internet Draft Verio
David Meyer
Henry Kilmer
Dino Farinacci
Procket Networks
Category Experimental
May, 2001
Anycast RP mechanism using PIM and MSDP
<draft-ietf-mboned-anycast-rp-08.txt>
1. Status of this Memo Network Working Group D. Kim
Request for Comments: 3446 Verio
Category: Informational D. Meyer
H. Kilmer
D. Farinacci
Procket Networks
January 2003
This document is an Internet-Draft and is in full conformance with Anycast Rendevous Point (RP) mechanism using
all provisions of Section 10 of RFC 2026. Protocol Independent Multicast (PIM)
and Multicast Source Discovery Protocol (MSDP)
Internet Drafts are working documents of the Internet Engineering Status of this Memo
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 This memo provides information for the Internet community. It does
and may be updated, replaced, or obsoleted by other documents at any not specify an Internet standard of any kind. Distribution of this
time. It is inappropriate to use Internet-Drafts as reference memo is unlimited.
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at Copyright Notice
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at Copyright (C) The Internet Society (2003). All Rights Reserved.
http://www.ietf.org/shadow.html.
2. Abstract Abstract
This document describes a mechanism to allow for an arbitrary number This document describes a mechanism to allow for an arbitrary number
of RPs per group in a single shared-tree PIM-SM domain. of Rendevous Points (RPs) per group in a single shared-tree Protocol
Independent Multicast-Sparse Mode (PIM-SM) domain.
This memo is a product of the MBONE Deployment Working Group (MBONED)
in the Operations and Management Area of the Internet Engineering
Task Force. Submit comments to <mboned@ns.uoregon.edu> or the
authors.
3. Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved.
4. Introduction 1. Introduction
PIM-SM as defined in RFC 2362 allows for only a single active RP per PIM-SM, as defined in RFC 2362, allows for only a single active RP
group, and as such the decision of optimal RP placement can become per group, and as such the decision of optimal RP placement can
problematic for a multi-regional network deploying PIM-SM. become problematic for a multi-regional network deploying PIM-SM.
Anycast RP relaxes an important constraint in PIM-SM, namely, that Anycast RP relaxes an important constraint in PIM-SM, namely, that
there can be only one group to RP mapping can be active at any time. there can be only one group to RP mapping can be active at any time.
The single mapping property has several implications, including The single mapping property has several implications, including
traffic concentration, lack of scalable register decapsulation (when traffic concentration, lack of scalable register decapsulation (when
using the shared tree), slow convergence when an active RP fails, using the shared tree), slow convergence when an active RP fails,
possible sub-optimal forwarding of multicast packets, and distant RP possible sub-optimal forwarding of multicast packets, and distant RP
dependencies. These properties of PIM-SM have been demonstrated in dependencies. These properties of PIM-SM have been demonstrated in
native continental or inter-continental scale multicast deployments. native continental or inter-continental scale multicast deployments.
As a result, it is clear that ISP backbones require a mechanism that As a result, it is clear that ISP backbones require a mechanism that
allows definition of multiple active RPs per group in single PIM-SM allows definition of multiple active RPs per group in a single PIM-SM
domain. Further, any such mechanism should also address the issues domain. Further, any such mechanism should also address the issues
addressed above. addressed above.
The mechanism described here is intended to address the need for The mechanism described here is intended to address the need for
better fail-over (convergence time) and sharing of the register better fail-over (convergence time) and sharing of the register
decapsulation load (again, when using the shared-tree) among RPs in a decapsulation load (again, when using the shared-tree) among RPs in a
domain. It is primarily intended for applications within those domain. It is primarily intended for applications within those
networks which are using MBGP, Multicast Source Discovery Protocol networks using MBGP, Multicast Source Discovery Protocol [MSDP] and
[MSDP] and PIM-SM protocols for native multicast deployment, although PIM-SM protocols, for native multicast deployment, although it is not
it not limited to those protocols. In particular, Anycast RP is limited to those protocols. In particular, Anycast RP is applicable
applicable in any PIM-SM network that also supports MSDP (MSDP is in any PIM-SM network that also supports MSDP (MSDP is required so
required so that the various RPs in the domain maintain a consistent that the various RPs in the domain maintain a consistent view of the
view of the sources that are active). Note however, a domain sources that are active). Note however, a domain deploying Anycast
deploying Anycast RP is not required to run MBGP. Finally, a general RP is not required to run MBGP. Finally, a general requirement of
requirement of the Anycast RP scheme is that the anycast address MUST the Anycast RP scheme is that the anycast address MUST NOT be used as
NOT be used as the RP address in the RP's SA messages. the RP address in the RP's SA messages.
The keywords MUST, MUST NOT, MAY, OPTIONAL, REQUIRED, RECOMMENDED, The keywords MUST, MUST NOT, MAY, OPTIONAL, REQUIRED, RECOMMENDED,
SHALL, SHALL NOT, SHOULD, SHOULD NOT are to be interpreted as defined SHALL, SHALL NOT, SHOULD, SHOULD NOT are to be interpreted as defined
in RFC 2119 [RFC2119]. in BCP 14, RFC 2119 [RFC2119].
5. Problem Definition 2. Problem Definition
The anycast RP solution provides a solution for both fast fail-over The anycast RP solution provides a solution for both fast fail-over
and shared-tree load balancing among any number of active RPs in a and shared-tree load balancing among any number of active RPs in a
domain. domain.
5.1. Traffic Concentration and Distributing Decapsulation Load Among RPs 2.1. Traffic Concentration and Distributing Decapsulation Load Among RPs
While PIM-SM allows for multiple RPs to be defined for a given group, While PIM-SM allows for multiple RPs to be defined for a given group,
only one group to RP mapping can active at a given time. A only one group to RP mapping can be active at a given time. A
traditional deployment mechanism for balancing register decapsulation traditional deployment mechanism for balancing register decapsulation
load between multiple RPs covering the multicast group space is to load between multiple RPs covering the multicast group space is to
split up the 224.0.0.0/4 space between multiple defined RPs. This is split up the 224.0.0.0/4 space between multiple defined RPs. This is
an acceptable solution as long as multicast traffic remains low, but an acceptable solution as long as multicast traffic remains low, but
has problems as multicast traffic increases, especially because the has problems as multicast traffic increases, especially because the
network operator defining group space split between RPs does not network operator defining group space split between RPs does not
always have a priori knowledge of traffic distribution between always have a priori knowledge of traffic distribution between
groups. This can be overcome via periodic reconfigurations, but groups. This can be overcome via periodic reconfigurations, but
operational considerations cause this type of solution to scale operational considerations cause this type of solution to scale
poorly. poorly.
5.2. Sub-optimal Forwarding of Multicast Packets 2.2. Sub-optimal Forwarding of Multicast Packets
When a single RP serves a given multicast group, all joins to that When a single RP serves a given multicast group, all joins to that
group will be sent to that RP regardless of the topological distance group will be sent to that RP regardless of the topological distance
between the RP and the sources and receivers. Initial data will be between the RP and the sources and receivers. Initial data will be
sent towards the RP also until configured shortest path tree switch sent towards the RP also until configured the shortest path tree
threshold is reached, or the data will always be sent towards the RP switch threshold is reached, or the data will always be sent towards
if the network is configured to always use RP rooted shared tree. the RP if the network is configured to always use the RP rooted
This holds true even if all the sources and the receivers are in any shared tree. This holds true even if all the sources and the
given single region, and RP is topologically distant from the sources receivers are in any given single region, and RP is topologically
and the receivers. This is an artifact of the dynamic nature of distant from the sources and the receivers. This is an artifact of
multicast group members, and of the fact that operators may not the dynamic nature of multicast group members, and of the fact that
always have a priori knowledge of the topological placement of the operators may not always have a priori knowledge of the topological
group members. placement of the group members.
Taken together, these effects can mean that (for example) although Taken together, these effects can mean that (for example) although
all the sources and receivers of a given group are in Europe, they all the sources and receivers of a given group are in Europe, they
are joining towards the RP in USA and the data will be traversing are joining towards the RP in the USA and the data will be traversing
relatively expensive pipe(s) twice, once to get to RP, and back down a relatively expensive pipe(s) twice, once to get to RP, and back
the RP rooted tree again, creating inefficient use of expensive down the RP rooted tree again, creating inefficient use of expensive
resources. resources.
5.3. Distant RP Dependencies 2.3. Distant RP Dependencies
As outlined above, a single active RP per group may cause local As outlined above, a single active RP per group may cause local
sources and receivers to become dependent on a topologically distant sources and receivers to become dependent on a topologically distant
RP. In addition, when multiple RPs are configured, there can be RP. In addition, when multiple RPs are configured, there can be
considerable convergence delay involved in switching to the backup considerable convergence delay involved in switching to the backup
RP. This delay may exist independent of the toplogical location of RP. This delay may exist independent of the toplogical location of
the primary and backup RPs. the primary and backup RPs.
6. Solution 3. Solution
Given the problem set outlined above, a good solution would allow an Given the problem set outlined above, a good solution would allow an
operator to configure multiple RPs per group, and distribute those operator to configure multiple RPs per group, and distribute those
RPs in a topologically significant manner to the sources and RPs in a topologically significant manner to the sources and
receivers. receivers.
6.1. Mechanisms 3.1. Mechanisms
All the RPs serving a given group or set of groups are configured All the RPs serving a given group or set of groups are configured
with identical anycast address, using a numbered interface on the RPs with an identical anycast address, using a numbered interface on the
(frequently a logical interface such as a loopback is used). RPs then RPs (frequently a logical interface such as a loopback is used). RPs
advertise group to RP mappings using this interface address. This then advertise group to RP mappings using this interface address.
will cause group members (senders) to join (register) towards the This will cause group members (senders) to join (register) towards
topologically closest RP. RPs MSDP peer with each other using an the topologically closest RP. RPs MSDP peer with each other using an
address unique to each RP. Since the anycast address is not a unique address unique to each RP. Since the anycast address is not a unique
address (by definition), a router MUST NOT choose the anycast unicast address (by definition), a router MUST NOT choose the anycast unicast
address as the router ID as this can prevent peerings and/or address as the router ID, as this can prevent peerings and/or
adjacencies from being established. adjacencies from being established.
In summary then, the following steps are required: In summary then, the following steps are required:
6.1.1. Create the set of group-to-anycast-RP-address mappings 3.1.1. Create the set of group-to-anycast-RP-address mappings
The first step is to create the set of group-to-anycast-RP-address The first step is to create the set of group-to-anycast-RP-address
mappings to be used in the domain. Each RP participating in a anycast mappings to be used in the domain. Each RP participating in an
RP set must be configured with a consistent set of group to RP anycast RP set must be configured with a consistent set of group to
address mappings. This mapping will be used by the non-RP routers in RP address mappings. This mapping will be used by the non-RP routers
the domain. in the domain.
6.1.2. Configure each RP for the group range with the anycast RP address 3.1.2. Configure each RP for the group range with the anycast RP address
The next step is to configure each RP for the group range with the The next step is to configure each RP for the group range with the
anycast RP address. If a dynamic mechanism such as auto-RP or the anycast RP address. If a dynamic mechanism, such as auto-RP or the
PIMv2 bootstrap mechanism is being used to advertise group to RP PIMv2 bootstrap mechanism, is being used to advertise group to RP
mappings, the anycast IP address should be used for the RP address. mappings, the anycast IP address should be used for the RP address.
6.1.3. Configure MSDP peerings between each of the anycast RPs in the 3.1.3. Configure MSDP peerings between each of the anycast RPs in the
set set
Unlike the group to RP mapping advertisements, MSDP peerings must use Unlike the group to RP mapping advertisements, MSDP peerings must use
an IP address that is unique to the endpoints; that is, the MSDP an IP address that is unique to the endpoints; that is, the MSDP
peering endpoints MUST use a unicast rather than anycast address. A peering endpoints MUST use a unicast rather than anycast address. A
general guideline is to follow the addressing of the BGP peerings, general guideline is to follow the addressing of the BGP peerings,
e.g., loopbacks for iBGP peering, physical interface addresses for e.g., loopbacks for iBGP peering, physical interface addresses for
eBGP peering. Note that the anycast address MUST NOT be used as the eBGP peering. Note that the anycast address MUST NOT be used as the
RP address in SA messages (as this would case the peer-RPF check to RP address in SA messages (as this would case the peer-RPF check to
fail). fail).
6.1.4. Configure the non-RP's with the group-to-anycast-RP-address 3.1.4. Configure the non-RP's with the group-to-anycast-RP-address
mappings mappings
Finally, each non-RP router must learn the set of group to RP Finally, each non-RP router must learn the set of group to RP
mappings. This could be done via static configuration, auto-RP, or by mappings. This could be done via static configuration, auto-RP, or
PIMv2 bootstrap mechanism. by PIMv2 bootstrap mechanism.
6.1.5. Ensure that the anycast IP address is reachable by all routers in 3.1.5. Ensure that the anycast IP address is reachable by all routers in
the domain the domain
This is typically accomplished by causing each RP to inject the /32 This is typically accomplished by causing each RP to inject the /32
into the domain's IGP. into the domain's IGP.
6.2. Interaction with MSDP Peer-RPF check 3.2. Interaction with MSDP Peer-RPF check
Each MSDP peer receives and forwards the message away from the RP Each MSDP peer receives and forwards the message away from the RP
address in a "peer-RPF flooding" fashion. The notion of peer-RPF address in a "peer-RPF flooding" fashion. The notion of peer-RPF
flooding is with respect to forwarding SA messages [MSDP]. The BGP flooding is with respect to forwarding SA messages [MSDP]. The BGP
routing tables are examined to determine which peer is the next hop routing tables are examined to determine which peer is the next hop
towards the originating RP of the SA message. Such a peer is called towards the originating RP of the SA message. Such a peer is called
an "RPF peer". See [MSDP] for details of the Peer-RPF check. an "RPF peer". See [MSDP] for details of the Peer-RPF check.
6.3. State Implications 3.3. State Implications
It should be noted that using MSDP in this way forces the creation of It should be noted that using MSDP in this way forces the creation of
(S,G) state along the path from the receiver to the source. This (S,G) state along the path from the receiver to the source. This
state may not be present if a single RP was used and receivers were state may not be present if a single RP was used and receivers were
forced to stay on the shared tree. forced to stay on the shared tree.
7. Security considerations 4. Security considerations
Since the solution described here makes heavy use of anycast Since the solution described here makes heavy use of anycast
addressing, care must be taken to avoid spoofing. In particular addressing, care must be taken to avoid spoofing. In particular
unicast routing and PIM RPs must be protected. unicast routing and PIM RPs must be protected.
7.1. Unicast Routing 4.1. Unicast Routing
Both internal and external unicast routing can be weakly protected Both internal and external unicast routing can be weakly protected
with keyed MD5 [RFC1828], as implemented in an internal protocol such with keyed MD5 [RFC1828], as implemented in an internal protocol such
as OSPF [RFC2382] or in BGP [RFC2385]. More generally, IPSEC as OSPF [RFC2328] or in BGP [RFC2385]. More generally, IPSEC
[RFC1825] could be used to provide protocol integrity for the unicast [RFC2401] could be used to provide protocol integrity for the unicast
routing system. routing system.
7.1.1. Effects of Unicast Routing Instability 4.1.1. Effects of Unicast Routing Instability
While not a security issue, it is worth noting that if unicast While not a security issue, it is worth noting that if unicast
routing is unstable, then the actual RP that source or receiver is routing is unstable, then the actual RP that source or receiver is
using will be subject to the same instability. using will be subject to the same instability.
7.2. Multicast Protocol Integrity 4.2. Multicast Protocol Integrity
The mechanisms described in [RFC2362] should be used to provide The mechanisms described in [RFC2362] should be used to provide
protocol message integrity protection and group-wise message origin protocol message integrity protection and group-wise message origin
authentication. authentication.
7.3. MSDP Peer Integrity 4.3. MSDP Peer Integrity
As is the the case for BGP, MSDP peers can be protected using keyed As is the the case for BGP, MSDP peers can be protected using keyed
MD5 [RFC1828]. MD5 [RFC1828].
8. Acknowledgments 5. Acknowledgments
John Meylor, Bill Fenner, Dave Thaler and Tom Pusateri provided John Meylor, Bill Fenner, Dave Thaler and Tom Pusateri provided
insightful comments on earlier versions for this idea. insightful comments on earlier versions for this idea.
9. Author's Address This memo is a product of the MBONE Deployment Working Group (MBONED)
in the Operations and Management Area of the Internet Engineering
Task Force. Submit comments to <mboned@ns.uoregon.edu> or the
authors.
Dorian Kim 6. References
Verio, Inc.
2361 Lancashire Dr. #2A
Ann Arbor, MI 48015
Email: dorian@blackrose.org
Hank Kilmer [MSDP] D. Meyer and B. Fenner, Editors, "Multicast Source
Email: hank@rem.com Discovery Protocol (MSDP)", Work in Progress.
Dino Farinacci [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
Procket Networks Internet Protocol", RFC 2401, August 1995.
Email: dino@procket.com
David Meyer [RFC1828] Metzger, P. and W. Simpson, "IP Authentication using Keyed
Email: dmm@maoz.com MD5", RFC 1828, August 1995.
10. References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[MSDP] D. Meyer and B. Fenner, Editors, "Multicast Source Discovery [RFC2362] Estrin, D., Farinacci, D., Helmy, A., Thaler, D., Deering,
Protocol (MSDP)", draft-ietf-msdp-spec-10.txt, S., Handley, M., Jacobson, V., Liu, C., Sharma, P. and L.
May, 2001. Work in Progress. Wei, "Protocol Independent Multicast-Sparse Mode (PIM-SM):
Protocol Specification", RFC 2362, June 1998.
[RFC1825] Atkinson, R., "IP Security Architecture", August 1995. [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC1828] P. Metzger and W. Simpson, "IP Authentication using Keyed [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5
MD5", RFC 1828, August, 1995. Signature Option", RFC 2385, August 1998.
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate [RFC2403] Madson, C. and R. Glenn, "The Use of HMAC-MD5-96 within
Requirement Levels", RFC 2119, March, 1997. ESP and AH", RFC 2403, November 1998.
[RFC2362] D. Estrin, et. al., "Protocol Independent Multicast- 7. Author's Address
Sparse Mode (PIM-SM): Protocol Specification", RFC
2362, June, 1998.
[RFC2382] Moy, J., "OSPF Version 2", RFC 2382, April 1998. Dorian Kim
Verio, Inc.
EMail: dorian@blackrose.org
[RFC2385] Herrernan, A., "Protection of BGP Sessions via the TCP Hank Kilmer
MD5 Signature Option", RFC 2385, August, 1998. EMail: hank@rem.com
[RFC2403] C. Madson and R. Glenn, "The Use of HMAC-MD5-96 within Dino Farinacci
ESP and AH", RFC 2403, November, 1998. Procket Networks
EMail: dino@procket.com
11. Full Copyright Statement David Meyer
EMail: dmm@maoz.com
Copyright (C) The Internet Society (2001). All Rights Reserved. 8. Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
skipping to change at line 321 skipping to change at page 7, line 32
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 69 change blocks. 
146 lines changed or deleted 133 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/