Network Working Group
Internet Draft Maria Napierala
Document: draft-mnapierala-mvpn-part-reqt-02.txt AT&T
Expires: December 24 2008 June 24 2008
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 - December 2008 [Page 1]
Requirement for Multicast MPLS/BGP VPN Partitioning
Table of Contents
1. Introduction................................................2
2. Terminology.................................................3
3. General Requirements........................................3
4. Multicast VPN Partitioning..................................4
4.1 Support of Anycast C-RP..................................5
4.2 Support of Redundant P-Tunnels...........................6
5. Preserving Customer Multicast Traffic Patterns..............7
5.1 Support of Source-Specific Host Reports in PIM-SM........8
6. Support of PIM-Bidir in MVPN................................8
6.1 Preventing Packet Loops..................................8
6.2 Support of Source-Only Branches..........................9
7. IANA Considerations.........................................9
8. Security Considerations....................................10
9. References.................................................10
10. Acknowledgments............................................10
11. Author's Addresses.........................................10
12. Intellectual Property Statement............................11
13. Copyright Notice...........................................11
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) and
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
Napierala Expires - December 2008 [Page 2]
Requirement for Multicast MPLS/BGP VPN Partitioning
network. The document formulates the generic aspects of this
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 Requirements
The MVPN solution MUST 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 would 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
prevent different multicast VRF's of the same VPN to have different
routing policies and choose different paths to reach C-RP or the C-
source. As a result it would break any kind of "anycast" sourcing of
a multicast stream in IP VPN, including Anycast RP operation by not
allowing multiple RP's to send traffic in parallel to their closest
receivers.
The solution MUST NOT result in creating duplicates to customer
receivers, except during routing transients. The amount of duplicates
during routing convergence should be minimized and should be
compatible to that of standard PIM operation. When preventing
duplicates to receivers, the solution MUST NOT waste provider's
network resources by discarding, at network egress, already
transmitted duplicate traffic. Only a single copy of any C-multicast
stream should reach any egress mVRF in a converged network. This
includes PIM-SM C-streams that are either flowing on C-shared tree
or C-shortest-path tree. An egress PE should receive a PIM-SM C-
Napierala Expires - December 2008 [Page 3]
Requirement for Multicast MPLS/BGP VPN Partitioning
stream either from the C-RP or directly from the C-source but never
from both.
There are two exceptions to the requirement of not wasting
provider's network bandwidth and discarding duplicates at network
egress. One exception is when providing fast convergence for certain
multicast VPN traffic on failures in access or in provider's
network. This requirement is described in section 4.2. The other
exception is in case of aggregation of different C-streams on to the
same multicast distribution tree (i.e., P-tunnel) in provider's
network. These two exceptions should be implemented by MVPN solution
as optional behavior, based on provider's discretion.
In addition, these two exceptions apply only to traffic from anycast
sources/RP's but not to PIM-SM C-streams flowing on C-shared tree vs.
C-shortest-path tree. In other words, a PIM-SM C-stream should never
be delivered to an egress PE from both, the C-RP and directly from
the C-source.
These requirements SHOULD be supported for all tunnel technologies
and SHOULD work with all protocols used for multicast signaling among
PE's. However, it is desirable that the solution is "generic" i.e.,
it is independent of multicast tunnel technology used by the service
provider. Independence from tunneling technology will allow
different transport methods to be used for different multicast
applications without overloading the transport technology itself.
This, in turn, will simplify provider's network maintenance
operations.
Moreover, the solution MUST NOT impose any restrictions on
customer's multicast routing or requirements on multicast service
offering. For example, it cannot require a customer to outsource its
RP functionality to the service provider or a service provider to
participate in customer's RP protocol by running MSDP with the
customer.
These requirements SHOULD be supported for the following PIM modes
in customer domain: PIM-SM [v], PIM-SSM [vii], and PIM-Bidir [vi].
The MVPN procedures SHOULD support all Rendezvous Point solutions
currently used by VPN customers.
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 the customers control
Napierala Expires - December 2008 [Page 4]
Requirement for Multicast MPLS/BGP VPN Partitioning
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 a customer expectation that multicast traffic in
a VPN can be subject to similar partitioning by multicast source or
Rendezvous Point location. The partitioning of multicast VPN by
multicast source or Rendezvous Point location is based on "anycast
souring". "Anycast" allows a group of destinations to be identified
with the same address so that data packets destined for that address
can be delivered to any member of the group. Anycast routing is
implemented via announcements of the same address prefix from
multiple origins. IP VPN customers often inject into VPN the same
route(s) at different VPN sites. These could be default or summary
routes, or specific routes. If these routes are routes to C-RP's or
C-sources, they are examples of "anycast sourcing" of multicast
traffic in MVPN. Anycast sourcing includes multi-homed sites with C-
sources or C-RP(A)'s, as well as Anycast C-RP's.
Lack of support for MVPN partitioning can deteriorate application's
performance, introduce latencies and variable delays that impact
users and applications. Typically, large enterprises have 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.
4.1 Support of Anycast C-RP
Napierala Expires - December 2008 [Page 5]
Requirement for Multicast MPLS/BGP VPN Partitioning
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. Anycast RP's are often used in large enterprise
networks.
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 addressing
behavior is that different PE's could choose different upstream PE's
as the next-hops to the customer RP or source.
The MVPN solution SHOULD support Anycast C-RP in the following two
ways: based on provider's network IGP/routing 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 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.
4.2 Support of Redundant P-Tunnels
Certain multicast applications are not tolerant to packet loss. To
minimize multicast traffic disruption during network or access
failures, the solution should provide a capability to pre-build
redundant P-tunnels in case of multi-homed C-RP's or C-sources. In
addition to "primary" tunnel, a "secondary" or redundant P-tunnel
could be triggered for C-Group or C-Source traffic. For example, the
primary P-tunnel could be based on mVRF's best route to C-RP or C-
source, while the secondary P-tunnel could be based on the next best
route (or another equal cost path) to C-RP or C-source. The redundant
P-tunnel should function in a "warm-standby" or a "hot-standby" mode.
In a "warm-standby" mode the redundant P-tunnel should be triggered
but the traffic should not be forwarded to it from the ingress PE,
the root of the tunnel. In a "hot-standby" mode the traffic should be
carried on both primary and standby tunnels and allow duplicates to
be received at egress PE's. The egress PE's should accept the traffic
only from either the primary tunnel or from the secondary tunnel.
Redundant tunnel capability should be implemented as a per-tunnel
configuration option to service provider.
Napierala Expires - December 2008 [Page 6]
Requirement for Multicast MPLS/BGP VPN Partitioning
5. Preserving Customer Multicast Traffic Patterns
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 the amount of multicast 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 Rendezvous
Point from carrying too much traffic while at the same time
controlling the number of (S,G) states created in the network. In
fact, last-hop CE's 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 not affect this PIM-SM
behavior in customer's network.
In native PIM-SM mode the same multicast traffic does not necessarily
flow over a single tree but it can simultaneously flow on both shared
and shortest path trees, without duplicates being sent to receivers.
The MVPN solution SHOULD allow egress PE's (i.e., PE's with
receivers) receive a specific PIM-SM C-stream either via the C-RP or
directly from the C-source. As it was stated in section 3, a PIM-SM
C-stream should never be delivered to an egress PE from both the C-RP
and directly from the C-source.
Moreover, the MVPN solution should not base multicast routing
decisions on provider's backbone internal infrastructure, like IP
addressing of PE routers. Rather the MVPN solution MUST preserve the
multicast routing policies as defined in customer's VPN. More
precisely, a multicast VRF with receivers of (C-*, C-G) or (C-S, C-G)
should receive multicast traffic from its best next-hop to C-RP or C-
S, respectively. The only two exceptions to this requirement are: (1)
the existence of multiple equal cost paths to customer source or
customer RP, which forces the provider's network to impose a tie-
breaker, and (2) the existence of a configuration knob that provides
an optional multicast behavior, based on provider's discretion (for
example, Anycast C-RP selection based on provider's network routing
cost).
In summary, the MVPN procedures should not alter customer's
multicast traffic patterns as defined by customer's PIM
infrastructure as well as by MVPN routing policies. More precisely,
MVPN solution MUST:
- preserve PIM-SM shared trees in customer network if CE's do not
switch traffic to SPT's or if they prune previously triggered (C-S,
Napierala Expires - December 2008 [Page 7]
Requirement for Multicast MPLS/BGP VPN Partitioning
C-G) states; i.e. MVPN solution MUST:
+ not trigger unexpected (C-S, C-G) states in customer's
network
+ not retain pruned (C-S, C-G) states in customer's network;
- support multi-homed C-receiver sites where shared tree and
shortest path tree diverge;
- preserve multicast routing policies of customer's VPN.
5.1 Support of Source-Specific Host Reports in PIM-SM
PIM-SM [v] permits "a receiver to join a group and specify that it
only wants to receive traffic for a group if that traffic comes from
a particular source. If a receiver does this, and no other receiver
on the LAN requires all the traffic for the group, then the DR may
omit performing a (*,G) join to set up the shared tree, and instead
issue a source-specific (S,G) join only."
Such a behavior of PIM-SM means that any PE can receive Join (C-S, C-
G) for a sparse mode group even if no PE has ever received Join (C-*,
C-G) in an MVPN. It also means that (as in PIM-SSM) source trees
might be triggered even for sources that are not active. The MVPN
solution SHOULD support source-specific host requests but it SHOULD
prevent useless S-PMSI creation for C-sources which are not active.
6. Support of PIM-Bidir in MVPN
Many enterprises use multicast applications that scale or even
operate correctly only with PIM-Bidir [vi]. For example, 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.
6.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
Napierala Expires - December 2008 [Page 8]
Requirement for Multicast MPLS/BGP VPN Partitioning
all routers on network segment, and during periods of ambiguity or
routing convergence the traffic forwarding is suspended.
The standard DF election procedure used in plain IP environments
would not yield the desired results in MVPN context. This is because
the DF election in MVPN would have to be based on the provider's
internal IP addressing of PE routers instead of on routing policy in
customer's VPN.
In MVPN context a Designated Forwarder for Bidir C-RPA is a PE
attached to C-RPA. Different mVRF's in a given MVPN might have
different best next-hop PE's to C-RPA due to different routing
policies or they might have temporarily different next-hop PE's to C-
RPA due to routing transients. The MVPN solution for C-Bidir MUST
prevent multicast packet looping during routing convergence. The MVPN
solution for C-Bidir SHOULD NOT rely on all mVRF's in a given MVPN to
either have common routing view to C-RPA or to reach a 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, each having a distinct view of converged network.
As an option, the MVPN implementation of C-Bidir SHOULD allow to
ignore specific multicast routing policy in mVRF, and instead make
all PE's in a given MVPN choose the same next-hop PE to C-RPA. Among
all candidate next-hop PE's, the single chosen upstream PE to C-RPA
could be the PE with the highest IP address. This approach to C-Bidir
might be desirable to customers that do not want a permanent
splitting of their MVPN's into disjoined C-Bidir trees.
6.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 traversing
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 [vi]. The MVPN solutions MUST 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. IANA Considerations
None.
Napierala Expires - December 2008 [Page 9]
Requirement for Multicast MPLS/BGP VPN Partitioning
8. Security Considerations
None.
9. 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.
10.Acknowledgments
The author would like to thank Eric Rosen, Yakov Rekhter, and Ron
Bonica for their comments.
11.Author's Addresses
Maria Napierala
AT&T Labs
200 Laurel Avenue, Middletown, NJ 07748
Napierala Expires - December 2008 [Page 10]
Requirement for Multicast MPLS/BGP VPN Partitioning
Email: mnapierala@att.com
12. 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 ietf-
ipr@ietf.org.
13. Copyright Notice
Copyright (C) The IETF Trust (2008).
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.
Napierala Expires - December 2008 [Page 11]