path: root/doc/rfc/rfc4834.txt

Network Working Group                                      T. Morin, Ed.
Request for Comments: 4834                            France Telecom R&D
Category: Informational                                       April 2007


   Requirements for Multicast in Layer 3 Provider-Provisioned Virtual
                       Private Networks (PPVPNs)

Status of This Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

   This document presents a set of functional requirements for network
   solutions that allow the deployment of IP multicast within Layer 3
   (L3) Provider-Provisioned Virtual Private Networks (PPVPNs).  It
   specifies requirements both from the end user and service provider
   standpoints.  It is intended that potential solutions specifying the
   support of IP multicast within such VPNs will use these requirements
   as guidelines.
























Morin                        Informational                      [Page 1]
^L
RFC 4834                    L3VPN Mcast Reqs                  April 2007


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  5
     2.1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  5
     2.2.  Conventions  . . . . . . . . . . . . . . . . . . . . . . .  6
   3.  Problem Statement  . . . . . . . . . . . . . . . . . . . . . .  7
     3.1.  Motivations  . . . . . . . . . . . . . . . . . . . . . . .  7
     3.2.  General Requirements . . . . . . . . . . . . . . . . . . .  7
     3.3.  Scaling vs. Optimizing Resource Utilization  . . . . . . .  8
   4.  Use Cases  . . . . . . . . . . . . . . . . . . . . . . . . . .  8
     4.1.  Scenarios  . . . . . . . . . . . . . . . . . . . . . . . .  8
       4.1.1.  Live Content Broadcast . . . . . . . . . . . . . . . .  9
       4.1.2.  Symmetric Applications . . . . . . . . . . . . . . . . 10
       4.1.3.  Data Distribution  . . . . . . . . . . . . . . . . . . 10
       4.1.4.  Generic Multicast VPN Offer  . . . . . . . . . . . . . 11
     4.2.  Scalability Orders of Magnitude  . . . . . . . . . . . . . 11
       4.2.1.  Number of VPNs with Multicast Enabled  . . . . . . . . 11
       4.2.2.  Number of Multicast VPNs per PE  . . . . . . . . . . . 12
       4.2.3.  Number of CEs per Multicast VPN per PE . . . . . . . . 12
       4.2.4.  PEs per Multicast VPN  . . . . . . . . . . . . . . . . 12
       4.2.5.  PEs with Multicast VRFs  . . . . . . . . . . . . . . . 13
       4.2.6.  Number of Streams Sourced  . . . . . . . . . . . . . . 13
   5.  Requirements for Supporting IP Multicast within L3 PPVPNs  . . 13
     5.1.  End User/Customer Standpoint . . . . . . . . . . . . . . . 13
       5.1.1.  Service Definition . . . . . . . . . . . . . . . . . . 13
       5.1.2.  CE-PE Multicast Routing and Group Management
               Protocols  . . . . . . . . . . . . . . . . . . . . . . 14
       5.1.3.  Quality of Service (QoS) . . . . . . . . . . . . . . . 14
       5.1.4.  Operations and Management  . . . . . . . . . . . . . . 15
       5.1.5.  Security Requirements  . . . . . . . . . . . . . . . . 16
       5.1.6.  Extranet . . . . . . . . . . . . . . . . . . . . . . . 17
       5.1.7.  Internet Multicast . . . . . . . . . . . . . . . . . . 18
       5.1.8.  Carrier's Carrier  . . . . . . . . . . . . . . . . . . 18
       5.1.9.  Multi-Homing, Load Balancing, and Resiliency . . . . . 19
       5.1.10. RP Engineering . . . . . . . . . . . . . . . . . . . . 19
       5.1.11. Addressing . . . . . . . . . . . . . . . . . . . . . . 20
       5.1.12. Minimum MTU  . . . . . . . . . . . . . . . . . . . . . 20
     5.2.  Service Provider Standpoint  . . . . . . . . . . . . . . . 21
       5.2.1.  General Requirement  . . . . . . . . . . . . . . . . . 21
       5.2.2.  Scalability  . . . . . . . . . . . . . . . . . . . . . 21
       5.2.3.  Resource Optimization  . . . . . . . . . . . . . . . . 23
       5.2.4.  Tunneling Requirements . . . . . . . . . . . . . . . . 24
       5.2.5.  Control Mechanisms . . . . . . . . . . . . . . . . . . 26
       5.2.6.  Support of Inter-AS, Inter-Provider Deployments  . . . 26
       5.2.7.  Quality-of-Service Differentiation . . . . . . . . . . 27
       5.2.8.  Infrastructure security  . . . . . . . . . . . . . . . 27
       5.2.9.  Robustness . . . . . . . . . . . . . . . . . . . . . . 28



Morin                        Informational                      [Page 2]
^L
RFC 4834                    L3VPN Mcast Reqs                  April 2007


       5.2.10. Operation, Administration, and Maintenance . . . . . . 28
       5.2.11. Compatibility and Migration Issues . . . . . . . . . . 29
       5.2.12. Troubleshooting  . . . . . . . . . . . . . . . . . . . 30
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 30
   7.  Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 31
   8.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 31
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 32
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 33










































Morin                        Informational                      [Page 3]
^L
RFC 4834                    L3VPN Mcast Reqs                  April 2007


1.  Introduction

   Virtual Private Network (VPN) services satisfying the requirements
   defined in [RFC4031] are now being offered by many service providers
   throughout the world.  VPN services are popular because customers
   need not be aware of the VPN technologies deployed in the provider
   network.  They scale well for the following reasons:

   o  because P routers (Provider Routers) need not be aware of VPN
      service details

   o  because the addition of a new VPN member requires only limited
      configuration effort

   There is also a growing need for support of IP multicast-based
   services.  Efforts to provide efficient IP multicast routing
   protocols and multicast group management have been made in
   standardization bodies which has led, in particular, to the
   definition of Protocol Independent Multicast (PIM) and Internet Group
   Management Protocol (IGMP).

   However, multicast traffic is not natively supported within existing
   L3 PPVPN solutions.  Deploying multicast over an L3VPN today, with
   only currently standardized solutions, requires designing customized
   solutions which will be inherently limited in terms of scalability,
   operational efficiency, and bandwidth usage.

   This document complements the generic L3VPN requirements [RFC4031]
   document, by specifying additional requirements specific to the
   deployment within PPVPNs of services based on IP multicast.  It
   clarifies the needs of both VPN clients and providers and formulates
   the problems that should be addressed by technical solutions with the
   key objective being to remain solution agnostic.  There is no intent
   in this document to specify either solution-specific details or
   application-specific requirements.  Also, this document does NOT aim
   at expressing multicast-related requirements that are not specific to
   L3 PPVPNs.

   It is expected that solutions that specify procedures and protocol
   extensions for multicast in L3 PPVPNs SHOULD satisfy these
   requirements.










Morin                        Informational                      [Page 4]
^L
RFC 4834                    L3VPN Mcast Reqs                  April 2007


2.  Conventions Used in This Document

2.1.  Terminology

   Although the reader is assumed to be familiar with the terminology
   defined in [RFC4031], [RFC4364], [RFC4601], and [RFC4607], the
   following glossary of terms may be worthwhile.

   We also propose here generic terms for concepts that naturally appear
   when multicast in VPNs is discussed.

   ASM:
      Any Source Multicast.  One of the two multicast service models, in
      which a terminal subscribes to a multicast group to receive data
      sent to the group by any source.

   Multicast-enabled VPN, multicast VPN, or             mVPN:
      A VPN that supports IP multicast capabilities, i.e., for which
      some PE devices (if not all) are multicast-enabled and whose core
      architecture supports multicast VPN routing and forwarding.

   PPVPN:
      Provider-Provisioned Virtual Private Network.

   PE, CE:
      "Provider Edge", "Customer Edge" (as defined in [RFC4026]).  As
      suggested in [RFC4026], we will use these notations to refer to
      the equipments/routers/devices themselves.  Thus, "PE" will refer
      to the router on the provider's edge, which faces the "CE", the
      router on the customer's edge.

   VRF or VR:
      By these terms, we refer to the entity defined in a PE dedicated
      to a specific VPN instance.  "VRF" refers to "VPN Routing and
      Forwarding table" as defined in [RFC4364], and "VR" to "Virtual
      Router" as defined in [VRs] terminology.

   MDTunnel:
      Multicast Distribution Tunnel.  The means by which the customer's
      multicast traffic will be transported across the SP network.  This
      is meant in a generic way: such tunnels can be either point-to-
      point or point-to-multipoint.  Although this definition may seem
      to assume that distribution tunnels are unidirectional, the
      wording also encompasses bidirectional tunnels.







Morin                        Informational                      [Page 5]
^L
RFC 4834                    L3VPN Mcast Reqs                  April 2007


   S:
      Denotes a multicast source.

   G:
      Denotes a multicast group.

   Multicast channel:
      In the multicast SSM model [RFC4607], a "multicast channel"
      designates traffic from a specific source S to a multicast group
      G. Also denominated as "(S,G)".

   SP:
      Service provider.

   SSM:
      Source Specific Multicast.  One of the two multicast service
      models, where a terminal subscribes to a multicast group to
      receive data sent to the group by a specific source.

   RP:
      Rendezvous Point (Protocol Independent Multicast - Sparse Mode
      (PIM-SM) [RFC4601]).

   P2MP, MP2MP:
      Designate "Point-to-Multipoint" and "Multipoint-to-Multipoint"
      replication trees.

   L3VPN, VPN:
      Throughout this document, "L3VPN" or even just "VPN" will refer to
      "Provider-Provisioned Layer 3 Virtual Private Network" (PP
      L3VPNs), and will be preferred for readability.

   Please refer to [RFC4026] for details about terminology specifically
   relevant to VPN aspects, and to [RFC2432] for multicast performance
   or quality of service (QoS)-related terms.

2.2.  Conventions

   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 [RFC2119].










Morin                        Informational                      [Page 6]
^L
RFC 4834                    L3VPN Mcast Reqs                  April 2007


3.  Problem Statement

3.1.  Motivations

   More and more L3VPN customers use IP multicast services within their
   private infrastructures.  Naturally, they want to extend these
   multicast services to remote sites that are connected via a VPN.

   For instance, the customer could be a national TV channel with
   several geographical locations that wants to broadcast a TV program
   from a central point to several regional locations within its VPN.

   A solution to support multicast traffic could consist of point-to-
   point tunnels across the provider network and requires the PEs
   (Provider Edge routers) to replicate traffic.  This would obviously
   be sub-optimal as it would place the replication burden on the PE and
   hence would have very poor scaling characteristics.  It would also
   probably waste bandwidth and control plane resources in the
   provider's network.

   Thus, to provide multicast services for L3VPN networks in an
   efficient manner (that is, with a scalable impact on signaling and
   protocol state as well as bandwidth usage), in a large-scale
   environment, new mechanisms are required to enhance existing L3VPN
   solutions for proper support of multicast-based services.

3.2.  General Requirements

   This document sets out requirements for L3 provider-provisioned VPN
   solutions designed to carry customers' multicast traffic.  The main
   requirement is that a solution SHOULD first satisfy the requirements
   documented in [RFC4031]: as far as possible, a multicast service
   should have the same characteristics as the unicast equivalent,
   including the same simplicity (technology unaware), the same quality
   of service (if any), the same management (e.g., performance
   monitoring), etc.

   Moreover, it also has to be clear that a multicast VPN solution MUST
   interoperate seamlessly with current unicast VPN solutions.  It would
   also make sense that multicast VPN solutions define themselves as
   extensions to existing L3 provider-provisioned VPN solutions (such as
   for instance, [RFC4364] or [VRs]) and retain consistency with those,
   although this is not a core requirement.

   The requirements in this document are equally applicable to IPv4 and
   IPv6, for both customer- and provider-related matters.





Morin                        Informational                      [Page 7]
^L
RFC 4834                    L3VPN Mcast Reqs                  April 2007


3.3.  Scaling vs. Optimizing Resource Utilization

   When transporting multicast VPN traffic over a service provider
   network, there intrinsically is tension between scalability and
   resource optimization, since the latter is likely to require the
   maintenance of control plane states related to replication trees in
   the core network [RFC3353].

   Consequently, any deployment will require a trade-off to be made.
   This document will express some requirements related to this trade-
   off.

4.  Use Cases

   The goal of this section is to highlight how different applications
   and network contexts may have a different impact on how a multicast
   VPN solution is designed, deployed, and tuned.  For this purpose, we
   describe some typical use case scenarios and express expectations in
   terms of deployment orders of magnitude.

   Most of the content of these sections originates from a survey done
   in summer 2005, among institutions and providers that expect to
   deploy such solutions.  The full survey text and raw results (13
   responses) were published separately, and we only present here the
   most relevant facts and expectations that the survey exposed.

   For scalability figures, we considered that it was relevant to
   highlight the highest expectations, those that are expected to have
   the greatest impact on solution design.  For balance, we do also
   mention cases where such high expectations were expressed in only a
   few answers.

4.1.  Scenarios

   We don't provide here an exhaustive set of scenarios that a multicast
   VPN solution is expected to support -- no solution should restrict
   the scope of multicast applications and deployments that can be done
   over a multicast VPN.

   Hence, we only give here a short list of scenarios that are expected
   to have a large impact on the design of a multicast VPN solution.










Morin                        Informational                      [Page 8]
^L
RFC 4834                    L3VPN Mcast Reqs                  April 2007


4.1.1.  Live Content Broadcast

   Under this label, we group all applications that distribute content
   (audio, video, or other content) with the property that this content
   is expected to be consulted at once ("live") by the receiver.
   Typical applications are broadcast TV, production studio
   connectivity, and distribution of market data feeds.

   The characteristics of such applications are the following:

   o  one or few sources to many receivers

   o  sources are often in known locations; receivers are in less
      predictable locations (this latter point may depend on
      applications)

   o  in some cases, it is expected that the regularity of audience
      patterns may help improve how the bandwidth/state trade-off is
      handled

   o  the number of streams can be as high as hundreds, or even
      thousands, of streams

   o  bandwidth will depend on the application, but may vary between a
      few tens/hundreds of Kb/s (e.g., audio or low-quality video media)
      and tens of Mb/s (high-quality video), with some demanding
      professional applications requiring as much as hundreds of Mb/s.

   o  QoS requirements include, in many cases, a low multicast group
      join delay

   o  QoS of these applications is likely to be impacted by packet loss
      (some applications may be robust to low packet loss) and to have
      low robustness against jitter

   o  delay sensitivity will depend on the application: some
      applications are not so delay sensitive (e.g., broadcast TV),
      whereas others may require very low delay (professional studio
      applications)

   o  some of these applications may involve rapid changes in customer
      multicast memberships as seen by the PE, but this will depend on
      audience patterns and on the amount of provider equipments
      deployed close to VPN customers







Morin                        Informational                      [Page 9]
^L
RFC 4834                    L3VPN Mcast Reqs                  April 2007


4.1.2.  Symmetric Applications

   Some use cases exposed by the survey can be grouped under this label,
   and include many-to-many applications such as conferencing and server
   cluster monitoring.

   They are characterized by the relatively high number of streams that
   they can produce, which has a direct impact on scalability
   expectations.

   A sub-case of this scenario is the case of symmetric applications
   with small groups, when the number of receivers is low compared to
   the number of sites in the VPNs (e.g., video conferencing and
   e-learning applications).

   This latter case is expected to be an important input to solution
   design, since it may significantly impact how the bandwidth/state is
   managed.

   Optimizing bandwidth may require introducing dedicated states in the
   core network (typically as much as the number of groups) for the
   following reasons:

   o  small groups, and low predictability of the location of
      participants ("sparse groups")

   o  possibly significantly high bandwidth (a few Mb/s per participant)

   Lastly, some of these applications may involve real-time interactions
   and will be highly sensitive to packet loss, jitter, and delay.

4.1.3.  Data Distribution

   Some applications that are expected to be deployed on multicast VPNs
   are non-real-time applications aimed at distributing data from few
   sources to many receivers.

   Such applications may be considered to have lower expectations than
   their counterparts proposed in this document, since they would not
   necessarily involve more data streams and are more likely to adapt to
   the available bandwidth and to be robust to packet loss, jitter, and
   delay.

   One important property is that such applications may involve higher
   bandwidths (hundreds of Mb/s).






Morin                        Informational                     [Page 10]
^L
RFC 4834                    L3VPN Mcast Reqs                  April 2007


4.1.4.  Generic Multicast VPN Offer

   This ISP scenario is a deployment scenario where IP-multicast
   connectivity is proposed for every VPN: if a customer requests a VPN,
   then this VPN will support IP multicast by default.  In this case,
   the number of multicast VPNs equals the number of VPNs.  This implies
   a quite important scalability requirement (e.g., hundreds of PEs,
   hundreds of VPNs per PE, with a potential increase by one order of
   magnitude in the future).

   The per-mVPN traffic behavior is not predictable because how the
   service is used is completely up to the customer.  This results in a
   traffic mix of the scenarios mentioned in Section 4.1.  QoS
   requirements are similar to typical unicast scenarios, with the need
   for different classes.  Also, in such a context, a reasonably large
   range of protocols should be made available to the customer for use
   at the PE-CE level.

   Also, in such a scenario, customers may want to deploy multicast
   connectivity between two or more multicast VPNs as well as access to
   Internet Multicast.

4.2.  Scalability Orders of Magnitude

   This section proposes orders of magnitude for different scalability
   metrics relevant for multicast VPN issues.  It should be noted that
   the scalability figures proposed here relate to scalability
   expectations of future deployments of multicast VPN solutions, as the
   authors chose to not restrict the scope to only currently known
   deployments.

4.2.1.  Number of VPNs with Multicast Enabled

   From the survey results, we see a broad range of expectations.  There
   are extreme answers: from 5 VPNs (1 answer) to 10k VPNs (1 answer),
   but more typical answers are split between the low range of tens of
   VPNs (7 answers) and the higher range of hundreds or thousands of
   VPNs (2 + 4 answers).

   A solution SHOULD support a number of multicast VPNs ranging from one
   to several thousands.

   A solution SHOULD NOT limit the proportion of multicast VPNs among
   all (unicast) VPNs.







Morin                        Informational                     [Page 11]
^L
RFC 4834                    L3VPN Mcast Reqs                  April 2007


4.2.2.  Number of Multicast VPNs per PE

   The majority of survey answers express a number of multicast VPNs per
   PE of around tens (8 responses between 5 and 50); a significant
   number of them (4) expect deployments with hundreds or thousands (1
   response) of multicast VPNs per PE.

   A solution SHOULD support a number of multicast VPNs per PE of
   several hundreds, and may have to scale up to thousands of VPNs per
   PE.

4.2.3.  Number of CEs per Multicast VPN per PE

   Survey responses span from 1 to 2000 CEs per multicast VPN per PE.
   Most typical responses are between tens (6 answers) and hundreds (4
   responses).

   A solution SHOULD support a number of CEs per multicast VPN per PE
   going up to several hundreds (and may target the support of thousands
   of CEs).

4.2.4.  PEs per Multicast VPN

   People who answered the survey typically expect deployments with the
   number of PEs per multicast VPN in the range of hundreds of PEs (6
   responses) or tens of PEs (4 responses).  Two responses were in the
   range of thousands (one mentioned a 10k figure).

   A multicast VPN solution SHOULD support several hundreds of PEs per
   multicast VPN, and MAY usefully scale up to thousands.

4.2.4.1.  ... with Sources

   The number of PEs (per VPN) that would be connected to sources seems
   to be significantly lower than the number of PEs per VPN.  This is
   obviously related to the fact that many respondents mentioned
   deployments related to content broadcast applications (one to many).

   Typical numbers are tens (6 responses) or hundreds (4 responses) of
   source-connected PEs.  One respondent expected a higher number of
   several thousands.

   A solution SHOULD support hundreds of source-connected PEs per VPN,
   and some deployment scenarios involving many-to-many applications may
   require supporting a number of source-connected PEs equal to the
   number of PEs (hundreds or thousands).





Morin                        Informational                     [Page 12]
^L
RFC 4834                    L3VPN Mcast Reqs                  April 2007


4.2.4.2.  ... with Receivers

   The survey showed that the number of PEs with receivers is expected
   to be of the same order of magnitude as the number of PEs in a
   multicast VPN.  This is consistent with the intrinsic nature of most
   multicast applications, which have few source-only participants.

4.2.5.  PEs with Multicast VRFs

   A solution SHOULD scale up to thousands of PEs having multicast
   service enabled.

4.2.6.  Number of Streams Sourced

   Survey responses led us to retain the following orders of magnitude
   for the number of streams that a solution SHOULD support:

   per VPN:  hundreds or thousands of streams

   per PE:  hundreds of streams

5.  Requirements for Supporting IP Multicast within L3 PPVPNs

   Again, the aim of this document is not to specify solutions but to
   give requirements for supporting IP multicast within L3 PPVPNs.

   In order to list these requirements, we have taken the standpoint of
   two different important entities: the end user (the customer using
   the VPN) and the service provider.

   In the rest of the document, by "a solution" or "a multicast VPN
   solution", we mean a solution that allows multicast in an L3
   provider-provisioned VPN, and which addresses the requirements listed
   in this document.

5.1.  End User/Customer Standpoint

5.1.1.  Service Definition

   As for unicast, the multicast service MUST be provider provisioned
   and SHALL NOT require customer devices (CEs) to support any extra
   features compared to those required for multicast in a non-VPN
   context.  Enabling a VPN for multicast support SHOULD be possible
   with no impact (or very limited impact) on existing multicast
   protocols possibly already deployed on the CE devices.






Morin                        Informational                     [Page 13]
^L
RFC 4834                    L3VPN Mcast Reqs                  April 2007


5.1.2.  CE-PE Multicast Routing and Group Management Protocols

   Consequently to Section 5.1.1, multicast-related protocol exchanges
   between a CE and its directly connected PE SHOULD happen via existing
   multicast protocols.

   Such protocols include: PIM-SM [RFC4601], bidirectional-PIM
   [BIDIR-PIM], PIM - Dense Mode (DM) [RFC3973], and IGMPv3 [RFC3376]
   (this version implicitly supports hosts that only implement IGMPv1
   [RFC1112] or IGMPv2 [RFC2236]).

   Among those protocols, the support of PIM-SM (which includes the SSM
   model) and either IGMPv3 (for IPv4 solutions) and/or Multicast
   Listener Discovery Version 2 (MLDv2) [RFC3810] (for IPv6 solutions)
   is REQUIRED.  Bidir-PIM support at the PE-CE interface is
   RECOMMENDED.  And considering deployments, PIM-DM is considered
   OPTIONAL.

   When a multicast VPN solution is built on a VPN solution supporting
   IPv6 unicast, it MUST also support v6 variants of the above
   protocols, including MLDv2, and PIM-SM IPv6-specific procedures.  For
   a multicast VPN solution built on a unicast VPN solution supporting
   only IPv4, it is RECOMMENDED that the design favors the definition of
   procedures and encodings that will provide an easy adaptation to
   IPv6.

5.1.3.  Quality of Service (QoS)

   Firstly, general considerations regarding QoS in L3VPNs expressed in
   Section 5.5 of [RFC4031] are also relevant to this section.

   QoS is measured in terms of delay, jitter, packet loss, and
   availability.  These metrics are already defined for the current
   unicast PPVPN services and are included in Service Level Agreements
   (SLAs).  In some cases, the agreed SLA may be different between
   unicast and multicast, and that will require differentiation
   mechanisms in order to monitor both SLAs.

   The level of availability for the multicast service SHOULD be on par
   with what exists for unicast traffic.  For instance, comparable
   traffic protection mechanisms SHOULD be available for customer
   multicast traffic when it is carried over the service provider's
   network.

   A multicast VPN solution SHALL allow a service provider to define at
   least the same level of quality of service as exists for unicast, and
   as exists for multicast in a non-VPN context.  From this perspective,
   the deployment of multicast-based services within an L3VPN



Morin                        Informational                     [Page 14]
^L
RFC 4834                    L3VPN Mcast Reqs                  April 2007


   environment SHALL benefit from Diffserv [RFC2475] mechanisms that
   include multicast traffic identification, classification, and marking
   capabilities, as well as multicast traffic policing, scheduling, and
   conditioning capabilities.  Such capabilities MUST therefore be
   supported by any participating device in the establishment and the
   maintenance of the multicast distribution tunnel within the VPN.

   As multicast is often used to deliver high-quality services such as
   TV broadcast, a multicast VPN solution MAY provide additional
   features to support high QoS such as bandwidth reservation and
   admission control.

   Also, considering that multicast reception is receiver-triggered,
   group join delay (as defined in [RFC2432]) is also considered one
   important QoS parameter.  It is thus RECOMMENDED that a multicast VPN
   solution be designed appropriately in this regard.

   The group leave delay (as defined in [RFC2432]) may also be important
   on the CE-PE link for some usage scenarios: in cases where the
   typical bandwidth of multicast streams is close to the bandwidth of a
   PE-CE link, it will be important to have the ability to stop the
   emission of a stream on the PE-CE link as soon as it stops being
   requested by the CE, to allow for fast switching between two
   different high-throughput multicast streams.  This implies that it
   SHOULD be possible to tune the multicast routing or group management
   protocols (e.g., IGMP/MLD or PIM) used on the PE-CE adjacency to
   reduce the group leave delay to the minimum.

   Lastly, a multicast VPN solution SHOULD as much as possible ensure
   that client multicast traffic packets are neither lost nor
   duplicated, even when changes occur in the way a client multicast
   data stream is carried over the provider network.  Packet loss issues
   also have to be considered when a new source starts to send traffic
   to a group: any receiver interested in receiving such traffic SHOULD
   be serviced accordingly.

5.1.4.  Operations and Management

   The requirements and definitions for operations and management (OAM)
   of L3VPNs that are defined in [RFC4176] equally apply to multicast,
   and are not extensively repeated in this document.  This sub-section
   mentions the most important guidelines and details points of
   particular relevance in the context of multicast in L3VPNs.

   A multicast VPN solution SHOULD allow a multicast VPN customer to
   manage the capabilities and characteristics of their multicast VPN
   services.




Morin                        Informational                     [Page 15]
^L
RFC 4834                    L3VPN Mcast Reqs                  April 2007


   A multicast VPN solution MUST support SLA monitoring capabilities,
   which SHOULD rely upon techniques similar to those used for the
   unicast service for the same monitoring purposes.  Multicast SLA-
   related metrics SHOULD be available through means similar to the ones
   already used for unicast-related monitoring, such as Simple Network
   Management Protocol (SNMP) [RFC3411] or IPFIX [IPFIX-PROT].

   Multicast-specific characteristics that may be monitored include:
   multicast statistics per stream, end-to-end delay, and group join/
   leave delay (time to start/stop receiving a multicast group's traffic
   across the VPN, as defined in [RFC2432], Section 3).

   The monitoring of multicast-specific parameters and statistics MUST
   include multicast traffic statistics: total/incoming/outgoing/dropped
   traffic, by period of time.  It MAY include IP Performance Metrics
   related information (IPPM, [RFC2330]) that is relevant to the
   multicast traffic usage: such information includes the one-way packet
   delay, the inter-packet delay variation, etc.  See [MULTIMETRICS].

   A generic discussion of SLAs is provided in [RFC3809].

   Apart from statistics on multicast traffic, customers of a multicast
   VPN will need information concerning the status of their multicast
   resource usage (multicast routing states and bandwidth).  Indeed, as
   mentioned in Section 5.2.5, for scalability purposes, a service
   provider may limit the number (and/or throughput) of multicast
   streams that are received/sent to/from a client site.  In such a
   case, a multicast VPN solution SHOULD allow customers to find out
   their current resource usage (multicast routing states and
   throughput), and to receive some kind of feedback if their usage
   exceeds the agreed bounds.  Whether this issue will be better handled
   at the protocol level at the PE-CE interface or at the Service
   Management Level interface [RFC4176] is left for further discussion.

   It is RECOMMENDED that any OAM mechanism designed to trigger alarms
   in relation to performance or resource usage metrics integrate the
   ability to limit the rate at which such alarms are generated (e.g.,
   some form of a hysteresis mechanism based on low/high thresholds
   defined for the metrics).

5.1.5.  Security Requirements

   Security is a key point for a customer who uses a VPN service.  For
   instance, the [RFC4364] model offers some guarantees concerning the
   security level of data transmission within the VPN.

   A multicast VPN solution MUST provide an architecture with the same
   level of security for both unicast and multicast traffic.



Morin                        Informational                     [Page 16]
^L
RFC 4834                    L3VPN Mcast Reqs                  April 2007


   Moreover, the activation of multicast features SHOULD be possible:

   o  per VRF / per VR

   o  per CE interface (when multiple CEs of a VPN are connected to a
      common VRF/VR)

   o  per multicast group and/or per channel

   o  with a distinction between multicast reception and emission

   A multicast VPN solution may choose to make the optimality/
   scalability trade-off stated in Section 3.3 by sometimes distributing
   multicast traffic of a client group to a larger set of PE routers
   that may include PEs that are not part of the VPN.  From a security
   standpoint, this may be a problem for some VPN customers; thus, a
   multicast VPN solution using such a scheme MAY offer ways to avoid
   this for specific customers (and/or specific customer multicast
   streams).

5.1.6.  Extranet

   In current PP L3VPN models, a customer site may be set up to be part
   of multiple VPNs, and this should still be possible when a VPN is
   multicast-enabled.  In practice, it means that a VRF or VR can be
   part of more than one VPN.

   A multicast VPN solution MUST support such deployments.

   For instance, it must be possible to configure a VRF so that an
   enterprise site participating in a BGP/MPLS multicast-enabled VPN and
   connected to that VRF can receive a multicast stream from (or
   originate a multicast stream towards) another VPN that would be
   associated to that VRF.

   This means that a multicast VPN solution MUST offer means for a VRF
   to be configured so that multicast connectivity can be set up for a
   chosen set of extranet VPNs.  More precisely, it MUST be possible to
   configure a VRF so that:

   o  receivers behind attached CEs can receive multicast traffic
      sourced in the configured set of extranet VPNs

   o  sources behind attached CEs can reach multicast traffic receivers
      located in the configured set of extranet VPNs

   o  multicast reception and emission can be independently enabled for
      each of the extranet VPNs



Morin                        Informational                     [Page 17]
^L
RFC 4834                    L3VPN Mcast Reqs                  April 2007


   Moreover, a solution MUST allow service providers to control an
   extranet's multicast connectivity independently from the extranet's
   unicast connectivity.  More specifically:

   o  enabling unicast connectivity to another VPN MUST be possible
      without activating multicast connectivity with that VPN

   o  enabling multicast connectivity with another VPN SHOULD NOT
      require more than the strict minimal unicast routing.  Sending
      multicast to a VPN SHOULD NOT require having unicast routes to
      that VPN; receiving multicast from a VPN SHOULD be possible with
      nothing more than unicast routes to the relevant multicast sources
      of that VPN

   o  when unicast routes from another VPN are imported into a VR/VRF,
      for multicast Reverse Path Forwarding (RPF) resolution, this
      SHOULD be possible without making those routes available for
      unicast routing

   Proper support for this feature SHOULD NOT require replicating
   multicast traffic on a PE-CE link, whether it is a physical or
   logical link.

5.1.7.  Internet Multicast

   Connectivity with Internet Multicast is a particular case of the
   previous section, where sites attached to a VR/VRF would need to
   receive/send multicast traffic from/to the Internet.

   This should be considered OPTIONAL given the additional
   considerations, such as security, needed to fulfill the requirements
   for providing Internet Multicast.

5.1.8.  Carrier's Carrier

   Many L3 PPVPN solutions, such as [RFC4364] and [VRs], define the
   "Carrier's Carrier" model, where a "carrier's carrier" service
   provider supports one or more customer ISPs, or "sub-carriers".  A
   multicast VPN solution SHOULD support the carrier's carrier model in
   a scalable and efficient manner.

   Ideally, the range of tunneling protocols available for the sub-
   carrier ISP should be the same as those available for the carrier's
   carrier ISP.  This implies that the protocols that may be used at the
   PE-CE level SHOULD NOT be restricted to protocols required as per
   Section 5.1.2 and SHOULD include some of the protocols listed in
   Section 5.2.4, such as for instance P2MP MPLS signaling protocols.




Morin                        Informational                     [Page 18]
^L
RFC 4834                    L3VPN Mcast Reqs                  April 2007


   In the context of MPLS-based L3VPN deployments, such as BGP/MPLS VPNs
   [RFC4364], this means that MPLS label distribution SHOULD happen at
   the PE-CE level, giving the ability to the sub-carrier to use
   multipoint LSPs as a tunneling mechanism.

5.1.9.  Multi-Homing, Load Balancing, and Resiliency

   A multicast VPN solution SHOULD be compatible with current solutions
   that aim at improving the service robustness for customers such as
   multi-homing, CE-PE link load balancing, and fail-over.  A multicast
   VPN solution SHOULD also be able to offer those same features for
   multicast traffic.

   Any solution SHOULD support redundant topology of CE-PE links.  It
   SHOULD minimize multicast traffic disruption and fail-over.

5.1.10.  RP Engineering

   When PIM-SM (or bidir-PIM) is used in ASM mode on the VPN customer
   side, the RP function (or RP-address in the case of bidir-PIM) has to
   be associated to a node running PIM, and configured on this node.

5.1.10.1.  RP Outsourcing

   In the case of PIM-SM in ASM mode, engineering of the RP function
   requires the deployment of specific protocols and associated
   configurations.  A service provider may offer to manage customers'
   multicast protocol operation on their behalf.  This implies that it
   is necessary to consider cases where a customer's RPs are outsourced
   (e.g., on PEs).  Consequently, a VPN solution MAY support the hosting
   of the RP function in a VR or VRF.

5.1.10.2.  RP Availability

   Availability of the RP function (or address) is required for proper
   operation of PIM-SM (ASM mode) and bidir-PIM.  Loss of connectivity
   to the RP from a receiver or source will impact the multicast
   service.  For this reason, different mechanisms exist, such as BSR
   [PIM-BSR] or anycast-RP (Multicast Source Discovery Protocol (MSDP)-
   based [RFC3446] or PIM-based [RFC4610]).

   These protocols and procedures SHOULD work transparently through a
   multicast VPN, and MAY if relevant, be implemented in a VRF/VR.

   Moreover, a multicast VPN solution MAY improve the robustness of the
   ASM multicast service regarding loss of connectivity to the RP, by
   providing specific features that help:




Morin                        Informational                     [Page 19]
^L
RFC 4834                    L3VPN Mcast Reqs                  April 2007


   a) maintain ASM multicast service among all the sites within an MVPN
      that maintain connectivity among themselves, even when the site(s)
      hosting the RP lose their connectivity to the MVPN

   b) maintain ASM multicast service within any site that loses
      connectivity to the service provider

5.1.10.3.  RP Location

   In the case of PIM-SM, when a source starts to emit traffic toward a
   group (in ASM mode), if sources and receivers are located in VPN
   sites that are different than that of the RP, then traffic may
   transiently flow twice through the SP network and the CE-PE link of
   the RP (from source to RP, and then from RP to receivers).  This
   traffic peak, even short, may not be convenient depending on the
   traffic and link bandwidth.

   Thus, a VPN solution MAY provide features that solve or help mitigate
   this potential issue.

5.1.11.  Addressing

   A multicast provider-provisioned L3VPN SHOULD NOT impose restrictions
   on multicast group addresses used by VPN customers.

   In particular, like unicast traffic, an overlap of multicast group
   address sets used by different VPN customers MUST be supported.

   The use of globally unique means of multicast-based service
   identification at the scale of the domain where such services are
   provided SHOULD be recommended.  For IPv4 multicast, this implies the
   use of the multicast administratively scoped range (239/8 as defined
   by [RFC2365]) for services that are to be used only inside the VPN,
   and of either SSM-range addresses (232/8 as defined by [RFC4607]) or
   globally assigned group addresses (e.g., GLOP [RFC3180], 233/8) for
   services for which traffic may be transmitted outside the VPN.

5.1.12.  Minimum MTU

   For customers, it is often a serious issue whether or not transmitted
   packets will be fragmented.  In particular, some multicast
   applications might have different requirements than those that make
   use of unicast, and they may expect services that guarantee available
   packet length not to be fragmented.

   Therefore, a multicast VPN solution SHOULD be designed with these
   considerations in mind.  In practice:




Morin                        Informational                     [Page 20]
^L
RFC 4834                    L3VPN Mcast Reqs                  April 2007


   o  the encapsulation overhead of a multicast VPN solution SHOULD be
      minimized, so that customer devices can be free of fragmentation
      and reassembly activity as much as possible

   o  a multicast VPN solution SHOULD enable the service provider to
      commit to a minimum path MTU usable by multicast VPN customers

   o  a multicast VPN solution SHOULD be compatible with path MTU
      discovery mechanisms (see [RFC1191] and [RFC4459]), and particular
      care SHOULD be given to means to help troubleshoot MTU issues

   Moreover, since Ethernet LAN segments are often located at first and
   last hops, a multicast VPN solution SHOULD be designed to allow for a
   minimum 1500-byte IP MTU for VPN customers multicast packet, when the
   provider backbone design allows it.

5.2.  Service Provider Standpoint

   Note: To avoid repetition and confusion with terms used in solution
   specifications, we introduced in Section 2.1 the term MDTunnel (for
   Multicast Distribution Tunnel), which designates the data plane means
   used by the service provider to forward customer multicast traffic
   over the core network.

5.2.1.  General Requirement

   The deployment of a multicast VPN solution SHOULD be possible with no
   (or very limited) impact on existing deployments of standardized
   multicast-related protocols on P and PE routers.

5.2.2.  Scalability

   Some currently standardized and deployed L3VPN solutions have the
   major advantage of being scalable in the core regarding the number of
   customers and the number of customer routes.  For instance, in the
   [RFC4364] and Virtual Router [VRs] models, a P router sees a number
   of MPLS tunnels that is only linked to the number of PEs and not to
   the number of VPNs, or customer sites.

   As far as possible, this independence in the core, with respect to
   the number of customers and to customer activity, is recommended.
   Yet, it is recognized that in our context scalability and resource
   usage optimality are competing goals, so this requirement may be
   reduced to giving the possibility of bounding the quantity of states
   that the service provider needs to maintain in the core for
   MDTunnels, with a bound being independent of the multicast activity
   of VPN customers.




Morin                        Informational                     [Page 21]
^L
RFC 4834                    L3VPN Mcast Reqs                  April 2007


   It is expected that multicast VPN solutions will use some kind of
   point-to-multipoint technology to efficiently carry multicast VPN
   traffic, and because such technologies require maintaining state
   information, this will use resources in the control plane of P and PE
   routers (memory and processing, and possibly address space).

   Scalability is a key requirement for multicast VPN solutions.
   Solutions MUST be designed to scale well with an increase in any of
   the following:

   o  the number of PEs

   o  the number of customer VPNs (total and per PE)

   o  the number of PEs and sites in any VPN

   o  the number of client multicast channels (groups or source-groups)

   Please consult Section 4.2 for typical orders of magnitude up to
   which a multicast VPN solution is expected to scale.

   Scalability of both performance and operation MUST be considered.

   Key considerations SHOULD include:

   o  the processing resources required by the control plane
      (neighborhood or session maintenance messages, keep-alives,
      timers, etc.)

   o  the memory resources needed for the control plane

   o  the amount of protocol information transmitted to manage a
      multicast VPN (e.g., signaling throughput)

   o  the amount of control plane processing required on PE and P
      routers to add or remove a customer site (or a customer from a
      multicast session)

   o  the number of multicast IP addresses used (if IP multicast in ASM
      mode is proposed as a multicast distribution tunnel)

   o  other particular elements inherent to each solution that impact
      scalability (e.g., if a solution uses some distribution tree
      inside the core, topology of the tree and number of leaf nodes may
      be some of them)

   It is expected that the applicability of each solution will be
   evaluated with regards to the aforementioned scalability criteria.



Morin                        Informational                     [Page 22]
^L
RFC 4834                    L3VPN Mcast Reqs                  April 2007


   These considerations naturally lead us to believe that proposed
   solutions SHOULD offer the possibility of sharing such resources
   between different multicast streams (between different VPNs, between
   different multicast streams of the same or of different VPNs).  This
   means, for instance, if MDTunnels are trees, being able to share an
   MDTunnel between several customers.

   Those scalability issues are expected to be more significant on P
   routers, but a multicast VPN solution SHOULD address both P and PE
   routers as far as scalability is concerned.

5.2.3.  Resource Optimization

5.2.3.1.  General Goals

   One of the aims of the use of multicast instead of unicast is
   resource optimization in the network.

   The two obvious suboptimal behaviors that a multicast VPN solution
   would want to avoid are needless duplication (when the same data
   travels twice or more on a link, e.g., when doing ingress PE
   replication) and needless reception (e.g., a PE receiving traffic
   that it does not need because there are no downstream receivers).

5.2.3.2.  Trade-off and Tuning

   As previously stated in this document, designing a scalable solution
   that makes an optimal use of resources is considered difficult.
   Thus, what is expected from a multicast VPN solution is that it
   addresses the resource optimization issue while taking into account
   the fact that some trade-off has to be made.

   Moreover, it seems that a "one size fits all" trade-off probably does
   not exist either.  Thus, a multicast VPN solution SHOULD offer
   service providers appropriate configuration settings that let them
   tune the trade-off according to their particular constraints (network
   topology, platforms, customer applications, level of service offered
   etc.).

   As an illustration, here are some example bounds of the trade-off
   space:










Morin                        Informational                     [Page 23]
^L
RFC 4834                    L3VPN Mcast Reqs                  April 2007


   Bandwidth optimization:  setting up optimized core MDTunnels whose
      topology (PIM or P2MP LSP trees, etc.) precisely follows a
      customer's multicast routing changes.  This requires managing a
      large amount of state in the core, and also quick reactions of the
      core to customer multicast routing changes.  This approach can be
      advantageous in terms of bandwidth, but it is poor in terms of
      state management.

   State optimization:  setting up MDTunnels that aggregate multiple
      customer multicast streams (all or some of them, across different
      VPNs or not).  This will have better scalability properties, but
      at the expense of bandwidth since some MDTunnel leaves will very
      likely receive traffic they don't need, and because increased
      constraints will make it harder to find optimal MDTunnels.

5.2.3.3.  Traffic Engineering

   If the VPN service provides traffic engineering (TE) features for the
   connection used between PEs for unicast traffic in the VPN service,
   the solution SHOULD provide equivalent features for multicast
   traffic.

   A solution SHOULD offer means to support key TE objectives as defined
   in [RFC3272], for the multicast service.

   A solution MAY also usefully support means to address multicast-
   specific traffic engineering issues: it is known that bandwidth
   resource optimization in the point-to-multipoint case is an NP-hard
   problem, and that techniques used for unicast TE may not be
   applicable to multicast traffic.

   Also, it has been identified that managing the trade-off between
   resource usage and scalability may incur uselessly sending traffic to
   some PEs participating in a multicast VPN.  For this reason, a
   multicast VPN solution MAY permit that the bandwidth/state tuning
   take into account the relative cost or availability of bandwidth
   toward each PE.

5.2.4.  Tunneling Requirements

5.2.4.1.  Tunneling Technologies

   Following the principle of separation between the control plane and
   the forwarding plane, a multicast VPN solution SHOULD be designed so
   that control and forwarding planes are not interdependent: the
   control plane SHALL NOT depend on which forwarding plane is used (and
   vice versa), and the choice of forwarding plane SHOULD NOT be limited




Morin                        Informational                     [Page 24]
^L
RFC 4834                    L3VPN Mcast Reqs                  April 2007


   by the design of the solution.  Also, the solution SHOULD NOT be tied
   to a specific tunneling technology.

   In a multicast VPN solution extending a unicast L3 PPVPN solution,
   consistency in the tunneling technology has to be favored: such a
   solution SHOULD allow the use of the same tunneling technology for
   multicast as for unicast.  Deployment consistency, ease of operation,
   and potential migrations are the main motivations behind this
   requirement.

   For MDTunnels, a solution SHOULD be able to use a range of tunneling
   technologies, including point-to-point and point-to-multipoint, such
   as:

   o  Generic Routing Encapsulation (GRE) [RFC2784] (including GRE in
      multicast IP trees),

   o  MPLS [RFC3031] (including P2P or MP2P tunnels, and multipoint
      tunnels signaled with MPLS P2MP extensions to the Resource
      Reservation Protocol (RSVP) [P2MP-RSVP-TE] or Label Distribution
      Protocol (LDP) [P2MP-LDP-REQS] [P2MP-LDP]),

   o  Layer-2 Tunneling Protocol (L2TP) (including L2TP for multicast
      [RFC4045]),

   o  IPsec [RFC4031]

   o  IP-in-IP [RFC2003], etc.

   Naturally, it is RECOMMENDED that a solution is built so that it can
   leverage the point-to-multipoint variants of these techniques.  These
   variants allow for packet replications to happen along a tree in the
   provider core network, and they may help improve bandwidth efficiency
   in a multicast VPN context.

5.2.4.2.  MTU and Fragmentation

   A solution SHOULD support a method that provides the minimum MTU of
   the MDTunnel (e.g., to discover MTU, to communicate MTU via
   signaling, etc.) so that:

   o  fragmentation inside the MDTunnel does not happen, even when
      allowed by the underlying tunneling technology

   o  proper troubleshooting can be performed if packets that are too
      big for the MDTunnel happen to be encapsulated in the MDTunnel





Morin                        Informational                     [Page 25]
^L
RFC 4834                    L3VPN Mcast Reqs                  April 2007


5.2.5.  Control Mechanisms

   The solution MUST provide some mechanisms to control the sources
   within a VPN.  This control includes the number of sources that are
   entitled to send traffic on the VPN, and/or the total bit rate of all
   the sources.

   At the reception level, the solution MUST also provide mechanisms to
   control the number of multicast groups or channels VPN users are
   entitled to subscribe to and/or the total bit rate represented by the
   corresponding multicast traffic.

   All these mechanisms MUST be configurable by the service provider in
   order to control the amount of multicast traffic and state within a
   VPN.

   Moreover, it MAY be desirable to be able to impose some bound on the
   quantity of state used by a VPN in the core network for its multicast
   traffic, whether on each P or PE router, or globally.  The motivation
   is that it may be needed to avoid out-of-resources situations (e.g.,
   out of memory to maintain PIM state if IP multicast is used in the
   core for multicast VPN traffic, or out of memory to maintain RSVP
   state if MPLS P2MP is used, etc.).

5.2.6.  Support of Inter-AS, Inter-Provider Deployments

   A solution MUST support inter-AS (Autonomous System) multicast VPNs,
   and SHOULD support inter-provider multicast VPNs.  Considerations
   about coexistence with unicast inter-AS VPN Options A, B, and C (as
   described in Section 10 of [RFC4364]) are strongly encouraged.

   A multicast VPN solution SHOULD provide inter-AS mechanisms requiring
   the least possible coordination between providers, and keep the need
   for detailed knowledge of providers' networks to a minimum -- all
   this being in comparison with corresponding unicast VPN options.

   o  Within each service provider, the service provider SHOULD be able
      on its own to pick the most appropriate tunneling mechanism to
      carry (multicast) traffic among PEs (just like what is done today
      for unicast)

   o  If a solution does require a single tunnel to span P routers in
      multiple ASs, the solution SHOULD provide mechanisms to ensure
      that the inter-provider coordination to set up such a tunnel is
      minimized






Morin                        Informational                     [Page 26]
^L
RFC 4834                    L3VPN Mcast Reqs                  April 2007


   Moreover, such support SHOULD be possible without compromising other
   requirements expressed in this requirement document, and SHALL NOT
   incur penalties on scalability and bandwidth-related efficiency.

5.2.7.  Quality-of-Service Differentiation

   A multicast VPN solution SHOULD give a VPN service provider the
   ability to offer, guarantee and enforce differentiated levels of QoS
   for its different customers.

5.2.8.  Infrastructure security

   The solution SHOULD provide the same level of security for the
   service provider as what currently exists for unicast VPNs (for
   instance, as developed in the Security sections of [RFC4364] and
   [VRs]).  For instance, traffic segregation and intrinsic protection
   against DoS (Denial of Service) and DDoS (Distributed Denial of
   Service) attacks of the BGP/MPLS VPN solution must be supported by
   the multicast solution.

   Moreover, since multicast traffic and routing are intrinsically
   dynamic (receiver-initiated), some mechanism SHOULD be proposed so
   that the frequency of changes in the way client traffic is carried
   over the core can be bounded and not tightly coupled to dynamic
   changes of multicast traffic in the customer network.  For example,
   multicast route dampening functions would be one possible mechanism.

   Network devices that participate in the deployment and the
   maintenance of a given L3VPN MAY represent a superset of the
   participating devices that are also involved in the establishment and
   maintenance of the multicast distribution tunnels.  As such, the
   activation of IP multicast capabilities within a VPN SHOULD be
   device-specific, not only to make sure that only the relevant devices
   will be multicast-enabled, but also to make sure that multicast
   (routing) information will be disseminated to the multicast-enabled
   devices only, hence limiting the risk of multicast-inferred DOS
   attacks.

   Traffic of a multicast channel for which there are no members in a
   given multicast VPN MUST NOT be propagated within the multicast VPN,
   most particularly if the traffic comes from another VPN or from the
   Internet.

   Security considerations are particularly important for inter-AS and
   inter-provider deployments.  In such cases, it is RECOMMENDED that a
   multicast VPN solution support means to ensure the integrity and
   authenticity of multicast-related exchanges across inter-AS or inter-
   provider borders.  It is RECOMMENDED that corresponding procedures



Morin                        Informational                     [Page 27]
^L
RFC 4834                    L3VPN Mcast Reqs                  April 2007


   require the least possible coordination between providers; more
   precisely, when specific configurations or cryptographic keys have to
   be deployed, this shall be limited to ASBRs (Autonomous System Border
   Routers) or a subset of them, and optionally BGP Route Reflectors (or
   a subset of them).

   Lastly, control mechanisms described in Section 5.2.5 are also to be
   considered from this infrastructure security point of view.

5.2.9.  Robustness

   Resiliency is also crucial to infrastructure security; thus, a
   multicast VPN solution SHOULD either avoid single points of failures
   or propose some technical solution making it possible to implement a
   fail-over mechanism.

   As an illustration, one can consider the case of a solution that
   would use PIM-SM as a means to set up MDTunnels.  In such a case, the
   PIM RP might be a single point of failure.  Such a solution SHOULD be
   compatible with a solution implementing RP resiliency, such as
   anycast-RP [RFC4610] or BSR [PIM-BSR].

5.2.10.  Operation, Administration, and Maintenance

   The operation of a multicast VPN solution SHALL be as light as
   possible, and providing automatic configuration and discovery SHOULD
   be a priority when designing a multicast VPN solution.  Particularly,
   the operational burden of setting up multicast on a PE or for a VR/
   VRF SHOULD be as low as possible.

   Also, as far as possible, the design of a solution SHOULD carefully
   consider the number of protocols within the core network: if any
   additional protocols are introduced compared with the unicast VPN
   service, the balance between their advantage and operational burden
   SHOULD be examined thoroughly.

   Moreover, monitoring of multicast-specific parameters and statistics
   SHOULD be offered to the service provider, following the requirements
   expressed in [RFC4176].

   Most notably, the provider SHOULD have access to:

   o  Multicast traffic statistics (incoming/outgoing/dropped/total
      traffic conveyed, by period of time)

   o  Information about client multicast resource usage (multicast
      routing state and bandwidth usage)




Morin                        Informational                     [Page 28]
^L
RFC 4834                    L3VPN Mcast Reqs                  April 2007


   o  Alarms when limits are reached on such resources

   o  The IPPM (IP Performance Metrics [RFC2330])-related information
      that is relevant to the multicast traffic usage: such information
      includes the one-way packet delay, the inter-packet delay
      variation, etc.

   o  Statistics on decisions related to how client traffic is carried
      on distribution tunnels (e.g., "traffic switched onto a multicast
      tree dedicated to such groups or channels")

   o  Statistics on parameters that could help the provider to evaluate
      its optimality/state trade-off

   This information SHOULD be made available through standardized SMIv2
   [RFC2578] Management Information Base (MIB) modules to be used with
   SNMP [RFC3411], or through IPFIX [IPFIX-PROT].  For instance, in the
   context of BGP/MPLS VPNs [RFC4364], multicast extensions to MIBs
   defined in [RFC4382] SHOULD be proposed, with proper integration with
   [RFC3811], [RFC3812], [RFC3813], and [RFC3814] when applicable.

   Mechanisms similar to those described in Section 5.2.12 SHOULD also
   exist for proactive monitoring of the MDTunnels.

   Proposed OAM mechanisms and procedures for multicast VPNs SHOULD be
   scalable with respect to the parameters mentioned in Section 5.2.2.
   In particular, it is RECOMMENDED that particular attention is given
   to the impact of monitoring mechanisms on performances and QoS.

   Moreover, it is RECOMMENDED that any OAM mechanism designed to
   trigger alarms in relation to performance or resource usage metrics
   integrate the ability to limit the rate at which such alarms are
   generated (e.g., some form of a hysteresis mechanism based on low/
   high thresholds defined for the metrics).

5.2.11.  Compatibility and Migration Issues

   It is a requirement that unicast and multicast services MUST be able
   to coexist within the same VPN.

   Likewise, a multicast VPN solution SHOULD be designed so that its
   activation in devices that participate in the deployment and
   maintenance of a multicast VPN SHOULD be as smooth as possible, i.e.,
   without affecting the overall quality of the services that are
   already supported by the underlying infrastructure.

   A multicast VPN solution SHOULD prevent compatibility and migration
   issues, for instance, by focusing on providing mechanisms



Morin                        Informational                     [Page 29]
^L
RFC 4834                    L3VPN Mcast Reqs                  April 2007


   facilitating forward compatibility.  Most notably, a solution
   supporting only a subset of the requirements expressed in this
   document SHOULD be designed to allow compatibility to be introduced
   in further revisions.

   It SHOULD be an aim of any multicast VPN solution to offer as much
   backward compatibility as possible.  Ideally, a solution would have
   the ability to offer multicast VPN services across a network
   containing some legacy routers that do not support any multicast VPN-
   specific features.

   In any case, a solution SHOULD state a migration policy from possibly
   existing deployments.

5.2.12.  Troubleshooting

   A multicast VPN solution that dynamically adapts the way some client
   multicast traffic is carried over the provider's network may incur
   the disadvantage of being hard to troubleshoot.  In such a case, to
   help diagnose multicast network issues, a multicast VPN solution
   SHOULD provide monitoring information describing how client traffic
   is carried over the network (e.g., if a solution uses multicast-based
   MDTunnels, which provider multicast group is used for a given client
   multicast stream).  A solution MAY also provide configuration options
   to avoid any dynamic changes, for multicast traffic of a particular
   VPN or a particular multicast stream.

   Moreover, a solution MAY provide mechanisms that allow network
   operators to check that all VPN sites that advertised interest in a
   particular customer multicast stream are properly associated with the
   corresponding MDTunnel.  Providing operators with means to check the
   proper setup and operation of MDTunnels MAY also be provided (e.g.,
   when P2MP MPLS is used for MDTunnels, troubleshooting functionalities
   SHOULD integrate mechanisms compliant with [RFC4687], such as LSP
   Ping [RFC4379][LSP-PING]).  Depending on the implementation, such
   verification could be initiated by a source-PE or a receiver-PE.

6.  Security Considerations

   This document does not by itself raise any particular security issue.

   A set of security issues has been identified that MUST be addressed
   when considering the design and deployment of multicast-enabled L3
   PPVPNs.  Such issues have been described in Section 5.1.5 and
   Section 5.2.8.






Morin                        Informational                     [Page 30]
^L
RFC 4834                    L3VPN Mcast Reqs                  April 2007


7.  Contributors

   The main contributors to this document are listed below, in
   alphabetical order:

   o  Christian Jacquenet
      France Telecom
      3, avenue Francois Chateau
      CS 36901 35069 RENNES Cedex, France
      Email: christian.jacquenet@orange-ftgroup.com

   o  Yuji Kamite
      NTT Communications Corporation
      Tokyo Opera City Tower 3-20-2 Nishi Shinjuku, Shinjuku-ku
      Tokyo 163-1421, Japan
      Email: y.kamite@ntt.com

   o  Jean-Louis Le Roux
      France Telecom R&D
      2, avenue Pierre-Marzin
      22307 Lannion Cedex, France
      Email: jeanlouis.leroux@orange-ftgroup.com

   o  Nicolai Leymann
      Deutsch Telecom
      Engineering Networks, Products & Services
      Goslarer Ufer 3510589 Berlin, Germany
      Email: nicolai.leymann@t-systems.com

   o  Renaud Moignard
      France Telecom R&D
      2, avenue Pierre-Marzin
      22307 Lannion Cedex, France
      Email: renaud.moignard@orange-ftgroup.com

   o  Thomas Morin
      France Telecom R&D
      2, avenue Pierre-Marzin
      22307 Lannion Cedex, France
      Email: thomas.morin@orange-ftgroup.com

8.  Acknowledgments

   The authors would like to thank, in rough chronological order,
   Vincent Parfait, Zubair Ahmad, Elodie Hemon-Larreur, Sebastien Loye,
   Rahul Aggarwal, Hitoshi Fukuda, Luyuan Fang, Adrian Farrel, Daniel
   King, Yiqun Cai, Ronald Bonica, Len Nieman, Satoru Matsushima,
   Netzahualcoyotl Ornelas, Yakov Rekhter, Marshall Eubanks, Pekka



Morin                        Informational                     [Page 31]
^L
RFC 4834                    L3VPN Mcast Reqs                  April 2007


   Savola, Benjamin Niven-Jenkins, and Thomas Nadeau, for their review,
   valuable input, and feedback.

   We also thank the people who kindly answered the survey, and Daniel
   King, who took care of gathering and anonymizing its results.

9.  References

9.1.  Normative References

   [RFC2119]        Bradner, S., "Key words for use in RFCs to Indicate
                    Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC4031]        Carugi, M. and D. McDysan, "Service Requirements for
                    Layer 3 Provider-Provisioned Virtual Private
                    Networks (PPVPNs)", RFC 4031, April 2005.

   [RFC4026]        Andersson, L. and T. Madsen, "Provider-Provisioned
                    Virtual Private Network (VPN) Terminology",
                    RFC 4026, March 2005.

   [RFC4601]        Fenner, B., Handley, M., Holbrook, H., and I.
                    Kouvelas, "Protocol Independent Multicast - Sparse
                    Mode (PIM-SM): Protocol Specification (Revised)",
                    RFC 4601, August 2006.

   [RFC4607]        Holbrook, H. and B. Cain, "Source-Specific Multicast
                    for IP", RFC 4607, August 2006.

   [RFC3376]        Cain, B., Deering, S., Kouvelas, I., Fenner, B., and
                    A. Thyagarajan, "Internet Group Management Protocol,
                    Version 3", RFC 3376, October 2002.

   [RFC3810]        Vida, R. and L. Costa, "Multicast Listener Discovery
                    Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.

   [RFC4176]        El Mghazli, Y., Nadeau, T., Boucadair, M., Chan, K.,
                    and A. Gonguet, "Framework for Layer 3 Virtual
                    Private Networks (L3VPN) Operations and Management",
                    RFC 4176, October 2005.

   [RFC3973]        Adams, A., Nicholas, J., and W. Siadak, "Protocol
                    Independent Multicast - Dense Mode (PIM-DM):
                    Protocol Specification (Revised)", RFC 3973,
                    January 2005.






Morin                        Informational                     [Page 32]
^L
RFC 4834                    L3VPN Mcast Reqs                  April 2007


9.2.  Informative References

   [RFC4364]        Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual
                    Private Networks (VPNs)", RFC 4364, February 2006.

   [VRs]            Ould-Brahim, H., "Network based IP VPN Architecture
                    Using Virtual Routers", Work in Progress,
                    March 2006.

   [RFC2432]        Dubray, K., "Terminology for IP Multicast
                    Benchmarking", RFC 2432, October 1998.

   [RFC3031]        Rosen, E., Viswanathan, A., and R. Callon,
                    "Multiprotocol Label Switching Architecture",
                    RFC 3031, January 2001.

   [RFC1112]        Deering, S., "Host extensions for IP multicasting",
                    STD 5, RFC 1112, August 1989.

   [RFC2236]        Fenner, W., "Internet Group Management Protocol,
                    Version 2", RFC 2236, November 1997.

   [P2MP-RSVP-TE]   Aggarwal, R., "Extensions to RSVP-TE for Point-to-
                    Multipoint TE LSPs", Work in Progress, August 2006.

   [PIM-BSR]        Bhaskar, N., "Bootstrap Router (BSR) Mechanism for
                    PIM", Work in Progress, June 2006.

   [RFC4610]        Farinacci, D. and Y. Cai, "Anycast-RP Using Protocol
                    Independent Multicast (PIM)", RFC 4610, August 2006.

   [RFC3446]        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.

   [P2MP-LDP]       Minei, I., "Label Distribution Protocol Extensions
                    for Point-to-Multipoint and Multipoint-to-Multipoint
                    Label Switched Paths", Work in Progress,
                    October 2006.

   [P2MP-LDP-REQS]  Roux, J., "Requirements for point-to-multipoint
                    extensions to the Label Distribution Protocol",
                    Work in Progress, June 2006.






Morin                        Informational                     [Page 33]
^L
RFC 4834                    L3VPN Mcast Reqs                  April 2007


   [RFC4687]        Yasukawa, S., Farrel, A., King, D., and T. Nadeau,
                    "Operations and Management (OAM) Requirements for
                    Point-to-Multipoint MPLS Networks", RFC 4687,
                    September 2006.

   [BIDIR-PIM]      Handley, M., "Bi-directional Protocol Independent
                    Multicast (BIDIR-PIM)", Work in Progress,
                    October 2005.

   [RFC2003]        Perkins, C., "IP Encapsulation within IP", RFC 2003,
                    October 1996.

   [RFC3353]        Ooms, D., Sales, B., Livens, W., Acharya, A.,
                    Griffoul, F., and F. Ansari, "Overview of IP
                    Multicast in a Multi-Protocol Label Switching (MPLS)
                    Environment", RFC 3353, August 2002.

   [RFC3272]        Awduche, D., Chiu, A., Elwalid, A., Widjaja, I., and
                    X. Xiao, "Overview and Principles of Internet
                    Traffic Engineering", RFC 3272, May 2002.

   [RFC2784]        Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
                    Traina, "Generic Routing Encapsulation (GRE)",
                    RFC 2784, March 2000.

   [IPFIX-PROT]     Claise, B., "Specification of the IPFIX Protocol for
                    the Exchange", Work in Progress, November 2006.

   [RFC4045]        Bourdon, G., "Extensions to Support Efficient
                    Carrying of Multicast Traffic in Layer-2 Tunneling
                    Protocol (L2TP)", RFC 4045, April 2005.

   [RFC3809]        Nagarajan, A., "Generic Requirements for Provider-
                    Provisioned Virtual Private Networks (PPVPN)",
                    RFC 3809, June 2004.

   [RFC3811]        Nadeau, T. and J. Cucchiara, "Definitions of Textual
                    Conventions (TCs) for Multiprotocol Label Switching
                    (MPLS) Management", RFC 3811, June 2004.

   [RFC3812]        Srinivasan, C., Viswanathan, A., and T. Nadeau,
                    "Multiprotocol Label Switching (MPLS) Traffic
                    Engineering (TE) Management Information Base (MIB)",
                    RFC 3812, June 2004.







Morin                        Informational                     [Page 34]
^L
RFC 4834                    L3VPN Mcast Reqs                  April 2007


   [RFC3813]        Srinivasan, C., Viswanathan, A., and T. Nadeau,
                    "Multiprotocol Label Switching (MPLS) Label
                    Switching Router (LSR) Management Information Base
                    (MIB)", RFC 3813, June 2004.

   [RFC3814]        Nadeau, T., Srinivasan, C., and A. Viswanathan,
                    "Multiprotocol Label Switching (MPLS) Forwarding
                    Equivalence Class To Next Hop Label Forwarding Entry
                    (FEC-To-NHLFE) Management Information Base (MIB)",
                    RFC 3814, June 2004.

   [RFC2365]        Meyer, D., "Administratively Scoped IP Multicast",
                    BCP 23, RFC 2365, July 1998.

   [RFC2330]        Paxson, V., Almes, G., Mahdavi, J., and M. Mathis,
                    "Framework for IP Performance Metrics", RFC 2330,
                    May 1998.

   [MULTIMETRICS]   Stephan, E., "IP Performance Metrics (IPPM) for
                    spatial and multicast", Work in Progress,
                    October 2006.

   [RFC2475]        Blake, S., Black, D., Carlson, M., Davies, E., Wang,
                    Z., and W. Weiss, "An Architecture for
                    Differentiated Services", RFC 2475, December 1998.

   [RFC3180]        Meyer, D. and P. Lothberg, "GLOP Addressing in
                    233/8", BCP 53, RFC 3180, September 2001.

   [RFC3411]        Harrington, D., Presuhn, R., and B. Wijnen, "An
                    Architecture for Describing Simple Network
                    Management Protocol (SNMP) Management Frameworks",
                    STD 62, RFC 3411, December 2002.

   [RFC2578]        McCloghrie, K., Ed., Perkins, D., Ed., and J.
                    Schoenwaelder, Ed., "Structure of Management
                    Information Version 2 (SMIv2)", STD 58, RFC 2578,
                    April 1999.

   [RFC1191]        Mogul, J. and S. Deering, "Path MTU discovery",
                    RFC 1191, November 1990.

   [RFC4382]        Nadeau, T. and H. van der Linde, "MPLS/BGP Layer 3
                    Virtual Private Network (VPN) Management Information
                    Base", RFC 4382, February 2006.






Morin                        Informational                     [Page 35]
^L
RFC 4834                    L3VPN Mcast Reqs                  April 2007


   [RFC4379]        Kompella, K. and G. Swallow, "Detecting Multi-
                    Protocol Label Switched (MPLS) Data Plane Failures",
                    RFC 4379, February 2006.

   [LSP-PING]       Farrel, A. and S. Yasukawa, "Detecting Data Plane
                    Failures in Point-to-Multipoint Multiprotocol",
                    Work in Progress, September 2006.

   [RFC4459]        Savola, P., "MTU and Fragmentation Issues with In-
                    the-Network Tunneling", RFC 4459, April 2006.

Author's Address

   Thomas Morin (editor)
   France Telecom R&D
   2, avenue Pierre Marzin
   Lannion  22307
   France

   EMail: thomas.morin@orange-ftgroup.com































Morin                        Informational                     [Page 36]
^L
RFC 4834                    L3VPN Mcast Reqs                  April 2007


Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.







Morin                        Informational                     [Page 37]
^L