Network Working Group Internet Draft M. Napierala Document: draft-mnapierala-mvpn-part-reqt-00.txt AT&T Expires: May 2008 November 2007 Requirement for Multicast MPLS/BGP VPN Partitioning Status of this Memo 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. Abstract This document describes a requirement for Multicast IP VPN solutions to allow the same multicast stream to flow simultaneously on multiple inter-PE paths without duplicates being sent to receivers. It is intended that existing and new solutions to MPLS/BGP Multicast IP VPN’s will support this requirement. Conventions used in this document 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 RFC-2119 [i]. Napierala Expires - May 2008 [Page 1] Requirement for Multicast MPLS/BGP VPN Partitioning Table of Contents 1. Introduction................................................2 2. Terminology.................................................3 3. General Requirement.........................................3 4. Multicast VPN Partitioning..................................4 5. Support of Anycast C-RP.....................................5 6. Preserving PIM-SM Traffic Patterns in MVPN..................6 7. Support of PIM-Bidir in MVPN................................6 7.1 Preventing Packet Loops..................................7 7.2 Support of Source-Only Branches..........................8 7.3 Bandwidth Optimization...................................8 8. IANA Considerations.........................................8 9. Security Considerations.....................................9 10. References..................................................9 11. Acknowledgments............................................10 12. Author's Addresses.........................................10 13. Intellectual Property Statement............................10 14. Copyright Notice...........................................10 1. Introduction Multicast VPN (cf.[ii]) extends MPLS/BGP VPN services (cf.[iii]) by enabling customers to run native IP multicast within their IP VPN’s. Multicast VPN’s enabled customers to use applications that were expensive or difficult, if not impossible, to operate in wide-area network before (e.g., voice/video conferencing, stock quotes, large file distribution). From VPN customer perspective there is no change in the multicast operational model. Multicast distribution trees are built in service provider network to carry VPN multicast traffic. Those trees are essentially point-to-multipoint (P2MP) or multipoint- to-multipoint (MP2MP) tunnels that encapsulate IP VPN multicast packets for transport across provider’s network. Throughout this document whenever we refer to a VPN we mean MPLS/BGP IP VPN and whenever we refer to an MVPN we mean MPLS/BGP Multicast IP VPN. The generic requirements for IP multicast services within IP VPN’s are specified in [iv]. This document defines additional multicast VPN requirements beyond those in [iv]. More precisely, it specifies the need of VPN customers to have multiple parallel paths to a Rendezvous Point or a multicast source across a service provider network. The document formulates the generic aspects of this Napierala Expires – May 2008 [Page 2] Requirement for Multicast MPLS/BGP VPN Partitioning requirement and states its specific issues that should be addressed by MVPN solution. It is expected that solutions that specify procedures and protocol extensions for multicast in IP VPN’s should satisfy this requirement. 2. Terminology In this document when we use the “C-“ prefix when we refer to the VPN customer multicast addresses and multicast trees. We will prefix VPN customer multicast trees, sources, groups, Rendezvous Points (RP), and PIM routes with “C-“, as in: C-tree, C-S, C-G, C-RP, (C-*, C-G), (C-S, C-G). When we use the “P-“ prefix when we refer to provider’s multicast addresses and multicast trees/tunnels. We assume familiarity with PIM protocol [v][vi][vii]. 3. General Requirement The MVPN solution should allow the same multicast traffic to flow simultaneously on multiple trees across provider’s network without duplicate packets sent to customer receivers. The solution has to allow for different downstream PE’s to choose different upstream PE’s to customer RP or customer source. As a result, customer multicast stream should be able to flow along multiple inter-PE trees and simultaneously utilize multiple paths in redundant topology. The lack of support of parallel paths for multicast traffic would remove one of the main benefits of IP VPN’s, namely, that different multicast VRF’s of the same VPN might have different routing policies and choose different paths to reach the RP or the source. It would also break Anycast RP operation in MVPN by not allowing multiple RP’s to send traffic in parallel to their closest receivers. The solution to duplicate-free operation of Multicast VPN’s has to be “generic” i.e., it has to be independent of multicast tunnel technology used by the service provider as well as of the protocol used to exchange multicast signaling among PE’s. When preventing duplicates to receivers, the solution should not waste provider’s network resources by discarding, at network egress, already transmitted duplicate traffic. One exception to this rule is when providing fast convergence for multicast VPN traffic on failures in access or in provider’s network. To minimize multicast traffic disruption during failures, the solution might provide a capability to pre-build “hot-standby” redundant P-tunnels and allow duplicates Napierala Expires – May 2008 [Page 3] Requirement for Multicast MPLS/BGP VPN Partitioning to be received at egress PE’s. Such a capability should be implemented as a configuration option to service provider. In addition, the inter-PE multicast signaling cannot impose any restrictions on customer’s multicast routing or requirements on multicast service offering, e.g., it cannot require a customer to outsource its RP functionality to the service provider. The MVPN solution cannot change multicast traffic patterns in customer network and has to be transparent to PIM routing in the customer domain. The requirement should be supported for the following PIM modes in customer domain: PIM-SM [v], PIM-SSM [vii], and PIM-Bidir [vi]. The MVPN procedures have to support all Rendezvous Point solutions currently available to customers: Static RP, Anycast-RP (IPv4 multicast only) [viii] [ix], BSR [x], and Auto-RP. 4. Multicast VPN Partitioning Service providers might allow VPN sites to have specific routing intelligence, giving the customers more granular control of their routing in the VPN. Site specific routing intelligence may include, for example, route preference or denial of routes. A VPN customer may partition its sites into groups that share the same routing policy. How these routing policies are defined and how customers control their routing may differ among service providers and it is outside the scope of this document. An example where customers need more granular control of their routing is in the selection of the Internet Gateway. Customers might access the Internet from their branch sites utilizing a default route or a summary route originating from their Internet Gateway site. A VPN might have multiple Internet Gateways. A customer may want to control which sites can access each of the gateways based on delay, application, security policy, etc. More generally, enterprises and firms often want to segment their VPN’s by data center or hub locations in order to meet specific performance, security, functionality, or application access requirements. Such partitioning of VPN’s has been possible for unicast transmission. It is customer expectation that multicast traffic in a VPN can be subject to similar partitioning by multicast source or Rendezvous Point location. Lack of such solution can deteriorate application performance, introduce latencies and variable delays that impact users and applications. Typically, large enterprises have Napierala Expires – May 2008 [Page 4] Requirement for Multicast MPLS/BGP VPN Partitioning multiple data centers and would like multicast applications to be simultaneously sourced from each data center to serve different sets of branch locations. For example, real-time market data distribution requires timely and simultaneous delivery to users. The differences in propagation delay might introduce unacceptable timing differences in the availability of data to users, and hence, unfairness in business competition. Locating sources close to receivers and partitioning of receivers by the source location is necessary in such business critical real-time data feeds. 5. Support of Anycast C-RP In Anycast RP, two or more RP’s are configured with the same IP address on loopback interfaces. IP routing automatically selects the topologically closest RP for each source and receiver. Anycast RP provides RP redundancy, fast RP failover, and load sharing of registering sources. With Anycast RP, RP failover is at the speed of unicast routing protocol. When RP goes down, sources and receivers are taken to new RP via unicast routing. Anycast RP’s are often used in large networks. PIM-SM has the capability for last-hop routers (i.e. routers with directly connected receivers) to switch to the shortest-path tree (SPT) and bypass the RP if the traffic rate is above a configured threshold called the “SPT-threshold”. If an SPT-threshold of “infinity” is specified for a group, the sources will not be switched to SPT and will always remain on the shared tree. In MVPN, customer multicast traffic might already be on optimal path across provider’s network while on C-shared trees. Hence, it might be beneficial to the customer not to switch to SPT’s but rather keep multicast traffic on C-shared trees. Typically, large enterprises have multiple data centers where Anycast RP’s and sources of multicast traffic are located. Such customers might require multicast applications to be simultaneously sourced from each data center and delivered via corresponding Anycast RP’s to different sets of branch locations. The expected Anycast C-RP behavior is that different PE’s could choose different upstream PE’s as the next-hops to the customer RP. As we described in section 4 such partitioning of VPN by Rendezvous Point and source location might be needed to assure required application performance. Hence, the support of multiple upstream PE’s for Anycast C-RP is required. The MVPN solution should support Anycast C-RP in two ways: based on provider’s network IGP cost or based on VPN customer routing. IGP cost-based next-hop selection provides PIM-like support of Anycast C- RP’s, i.e., C-receivers join the closest Anycast C-RP across Napierala Expires – May 2008 [Page 5] Requirement for Multicast MPLS/BGP VPN Partitioning provider’s network. The other option is to leave it up to the VPN routing policy to partition receivers by Anycast RP location. This allows multicast VPN customer to define its own Anycast C-RP selection, based on other criterion than the closest distance. 6. Preserving PIM-SM Traffic Patterns in MVPN MVPN solution that allows multicast traffic to flow simultaneously without duplicates across provider’s network should preserve customer multicast traffic patterns and multicast states in customer sites. PIM-SM has the capability for last-hop routers to switch to the shortest-path tree if the traffic rate is above a configured SPT- threshold. By switching to SPT, the optimal path is used to deliver the multicast traffic. Depending on the location of the source in relation to the RP, switching to the SPT can significantly reduce network latency. However, in networks with large numbers of senders, SPT’s can increase amount of state that must be kept in the routers. A VPN customer might set SPT-threshold to a value higher than zero in order to switch to SPT’s only for sources that cross certain traffic rate. This is done in order to alleviate RP from carrying too much traffic while at the same time controlling the number of (S,G) states created in the network. The inter-PE procedures in MVPN solution should not impact customer multicast traffic patterns and multicast states in customer’s sites. If there is any impact to customer multicast routing it should be negligible or it should be easily resolvable by straightforward routing adjustments in customer network. Those routing adjustments should be beneficial to customer i.e., result in better traffic patterns and/or decreased amount of multicast states on customer routers. Multicast VPN might never switch traffic to SPT’s for certain multicast groups if SPT-threshold of “infinity” is specified for those groups. The MVPN solution should preserve shared trees for such groups in customer domain if customer chooses not to switch traffic to SPT’s. 7. Support of PIM-Bidir in MVPN Some multicast applications use many-to-many model where each participant is the receiver as well as the sender. Using PIM-SM for such applications results in increased memory and protocol overhead. Napierala Expires – May 2008 [Page 6] Requirement for Multicast MPLS/BGP VPN Partitioning In PIM-SM, applications with large number of sources create a large amount of forwarding state. Typically, the more sources an application has, the less frequently traffic is sent from each sender. Each time a source starts to send packets, PIM-SM operations take place and forwarding state is established. For applications with a large number of sources, this state can time out before the source sends again, resulting in so called “bursty source” problem. Bi-directional PIM [xi] is the protocol that enables a scalable solution for many-to-many applications such as voice and video conferencing. PIM-Bidir eliminates both Register message encapsulation and source-specific states by allowing packets to be natively forwarded from a source to the Rendezvous Point using shared tree state only. Since PIM-Bidir relies only on shared tree forwarding it greatly reduces the amount of state which a router must maintain. Not only does PIM-Bidir avoid maintaining source-specific forwarding state but it also does not require any traffic signaling in the protocol. Thus, it prevents the “bursty source” problem, saving on CPU requirements for protocol operations and avoiding potential router internal performance limits. Many enterprises use multicast applications that scale or even operate correctly only with PIM-Bidir, e.g., financial firms use a business critical “always on” VoIP conferencing (so called ”hoot-n- holler”) to share market updates and trading orders. PIM-Bidir is already deployed in many of these networks and its support in MVPN context is required. This is a change from MVPN generic requirements document [iv] where PIM-Bidir support on PE-CE interfaces is only recommended. 7.1 Preventing Packet Loops In PIM-Bidir, the packet forwarding rules have been improved over PIM-SM, allowing traffic to be passed up the shared tree toward the RP Address (RPA). To avoid multicast packet looping, PIM-Bidir uses a mechanism called the designated forwarder (DF) election, which establishes a loop-free tree rooted at the RPA. Use of this method ensures that only one copy of every packet will be sent to an RPA, even if there are parallel equal cost paths to the RPA. To avoid loops the DF election process enforces consistent view of the DF on all routers on network segment, and during periods of ambiguity or routing convergence the traffic forwarding is suspended. The MVPN solution for C-Bidir should prevent multicast packet looping. Yet, standard DF election procedure which is optimized for plain IP environments might not work correctly in MVPN context due to routing convergence differences. This applies if MVPN were to Napierala Expires – May 2008 [Page 7] Requirement for Multicast MPLS/BGP VPN Partitioning function as a broadcast network, using LAN-based DF election process to prevent packets loops. In addition, C-Bidir over MVPN treated as a broadcast network prevents any possibility of resource optimization i.e., avoiding sending multicast traffic to PE’s with no participating sites (see section 7.3). Equally, the MVPN solution for C-Bidir cannot rely on all VRF’s in a VPN to reach common routing view to C-RPA in time to prevent packet looping. Rather, a VPN has to be treated as a collection of sets of multicast VRF’s, each having the same but distinct from other sets reachability information towards C-RPA. Hence, resolving C-Bidir packet loops in MVPN inevitably results in the ability to partition a VPN into disjoined sets of VRF’s, served by disjoined P-tunnels. Each such set would have a distinct view of converged network, i.e., it would have the same upstream PE as the best next-hop towards the C- RPA. 7.2 Support of Source-Only Branches PIM-Bidir supports source-only branches i.e., branches that do not lead to any receivers but that are used to forward packets traveling upstream from sources towards the RPA. In plain IP PIM-Bidir it is up to the implementation whether to maintain group state for source-only branches [xi]. The MVPN solutions have to assure that PE’s on source- only branches of C-Bidir tree are able to send and receive inter-PE MVPN traffic. In other words, PE’s on source-only branches have to be able to participate in P-tunnels triggered for C-Bidir trees. 7.3 Bandwidth Optimization The MVPN solution should be optimized for bandwidth i.e., it should prevent sending C-Bidir traffic across provider network to PE’s in MVPN that don’t require it, unless specifically allowed by the provider due to chosen P-tunnel aggregation technique. This means that C-Bidir implementation cannot be based on an overlay broadcast network. Broadcast network would require that customer Bidir traffic be sent to all PE’s in MVPN even if they are not on receiver- or sender-branches. 8. IANA Considerations To be supplied. Napierala Expires – May 2008 [Page 8] Requirement for Multicast MPLS/BGP VPN Partitioning 9. Security Considerations To be supplied. 10.References [i] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [ii] E. Rosen, R. Aggarwal, "Multicast in MPLS/BGP IP VPNs", draft-ietf-l3vpn-2547bis-mcast. Work in progress. [iii] E. Rosen, E., Rekhter, Y., "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006. [iv] T. Morin, Ed., “Requirements for Multicast in Layer 3 Provider-Provisioned Virtual Private Networks (PPVPNs)”, RFC 4834, April 2007. [v] B. Fenner et al., "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006. [vi] M. Handley, I. Kouvelas, T. Speakman, L. Vicisano, “Bi- directional Protocol Independent Multicast (Bidir-PIM)”, RFC 5015, October 2007. [vii] H. Holbrook, B. Cain, “Source-Specific Multicast for IP”, RFC 4607, August 2006. [viii] 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. [ix] Farinacci, D. and Y. Cai, "Anycast-RP Using Protocol Independent Multicast (PIM)", RFC 4610, August 2006. [x] N. Bhaskar, "Bootstrap Router (BSR) Mechanism for PIM”, Work in Progress, June 2006. Napierala Expires – May 2008 [Page 9] Requirement for Multicast MPLS/BGP VPN Partitioning 11.Acknowledgments To be supplied. 12.Author's Addresses Maria Napierala AT&T Labs 200 Laurel Avenue, Middletown, NJ 07748 Email: mnapierala@att.com 13. Intellectual Property Statement 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 ietfipr@ietf.org. 14. Copyright Notice 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 Napierala Expires – May 2008 [Page 10] Requirement for Multicast MPLS/BGP VPN Partitioning 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. Napierala Expires – May 2008 [Page 11]