GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc4834

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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc4834.txt · Last modified: 2007/04/14 01:57 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki