[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-morin-l3vpn-ppvpn-mcast-reqts) 00 01 02 03 04 05 06 07 08 09 10 RFC 4834

l3vpn Working Group                                        T. Morin, Ed.
Internet-Draft                                        France Telecom R&D
Expires: June 18, 2006                                 December 15, 2005


       Requirements for Multicast in L3 Provider-Provisioned VPNs
                 draft-ietf-l3vpn-ppvpn-mcast-reqts-03

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on June 18, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This document presents a set of functional requirements for network
   solutions that allow the deployment of IP multicast within 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.

Working group




Morin                     Expires June 18, 2006                 [Page 1]


Internet-Draft              L3VPN Mcast Reqs               December 2005


   This document is a product of the IETF's Layer 3 Virtual Private
   Network (l3vpn) working group.  Comments should be addressed to WG's
   mailing list at <mailto:l3vpn@ietf.org>.  The charter for l3vpn may
   be found at <http://www.ietf.org/html.charters/l3vpn-charter.html>

Contributors

   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@francetelecom.com [3]

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

   o

         Jean-Louis Le Roux

         France Telecom R & D

         2, avenue Pierre-Marzin

         22307 Lannion Cedex

         France




Morin                     Expires June 18, 2006                 [Page 2]


Internet-Draft              L3VPN Mcast Reqs               December 2005


         Email: jeanlouis.leroux@francetelecom.com [5]

   o

         Nicolai Leymann

         T-Systems International GmbH

         Engineering Networks, Products & Services

         Goslarer Ufer 35

         10589 Berlin, Germany

         Email: nicolai.leymann@t-systems.com [6]

   o

         Renaud Moignard

         France Telecom R & D

         2, avenue Pierre-Marzin

         22307 Lannion Cedex

         France

         Email: renaud.moignard@francetelecom.com [7]

   o

         Thomas Morin

         France Telecom R & D

         2, avenue Pierre-Marzin

         22307 Lannion Cedex

         France

         Email: thomas.morin@francetelecom.com [8]








Morin                     Expires June 18, 2006                 [Page 3]


Internet-Draft              L3VPN Mcast Reqs               December 2005


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  6
   2.  Conventions used in this document  . . . . . . . . . . . . . .  7
     2.1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  7
     2.2.  Conventions  . . . . . . . . . . . . . . . . . . . . . . .  8
   3.  Problem Statement  . . . . . . . . . . . . . . . . . . . . . .  9
     3.1.  Motivations  . . . . . . . . . . . . . . . . . . . . . . .  9
     3.2.  General Requirements . . . . . . . . . . . . . . . . . . .  9
     3.3.  Scaling vs. Optimizing Resource Utilization  . . . . . . .  9
   4.  Use cases  . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     4.1.  Scenarios  . . . . . . . . . . . . . . . . . . . . . . . . 11
       4.1.1.  Live content broadcast . . . . . . . . . . . . . . . . 11
       4.1.2.  Symetric applications  . . . . . . . . . . . . . . . . 12
       4.1.3.  Data distribution  . . . . . . . . . . . . . . . . . . 13
       4.1.4.  Generic multicast VPN offer  . . . . . . . . . . . . . 13
     4.2.  Scalability orders of magnitude  . . . . . . . . . . . . . 14
       4.2.1.  Number of VPNs with multicast enabled  . . . . . . . . 14
       4.2.2.  Number of multicast VPNs per PE  . . . . . . . . . . . 14
       4.2.3.  Number of CEs per multicast VPN per PE . . . . . . . . 14
       4.2.4.  PEs per multicast VPN  . . . . . . . . . . . . . . . . 14
       4.2.5.  PEs with multicast VRFs  . . . . . . . . . . . . . . . 15
       4.2.6.  Number of streams sourced  . . . . . . . . . . . . . . 15
   5.  Requirements for supporting IP multicast within L3 PPVPNs  . . 16
     5.1.  End user/customer standpoint . . . . . . . . . . . . . . . 16
       5.1.1.  Service definition . . . . . . . . . . . . . . . . . . 16
       5.1.2.  CE-PE Multicast routing and management protocols . . . 16
       5.1.3.  Quality of Service (QoS) . . . . . . . . . . . . . . . 16
       5.1.4.  SLA parameters measurement . . . . . . . . . . . . . . 18
       5.1.5.  Security Requirements  . . . . . . . . . . . . . . . . 18
       5.1.6.  Monitoring and Troubleshooting . . . . . . . . . . . . 19
       5.1.7.  Extranet . . . . . . . . . . . . . . . . . . . . . . . 19
       5.1.8.  Internet Multicast . . . . . . . . . . . . . . . . . . 20
       5.1.9.  Carrier's carrier  . . . . . . . . . . . . . . . . . . 20
       5.1.10. Multi-homing, load balancing and resiliency  . . . . . 21
       5.1.11. RP Engineering . . . . . . . . . . . . . . . . . . . . 21
       5.1.12. Addressing . . . . . . . . . . . . . . . . . . . . . . 21
       5.1.13. Minimum MTU  . . . . . . . . . . . . . . . . . . . . . 22
     5.2.  Service provider standpoint  . . . . . . . . . . . . . . . 22
       5.2.1.  Scalability  . . . . . . . . . . . . . . . . . . . . . 22
       5.2.2.  Resource optimization  . . . . . . . . . . . . . . . . 24
       5.2.3.  Tunneling Requirements . . . . . . . . . . . . . . . . 25
       5.2.4.  Control mechanisms . . . . . . . . . . . . . . . . . . 26
       5.2.5.  Support of Inter-AS, inter-provider deployments  . . . 27
       5.2.6.  Quality of Service Differentiation . . . . . . . . . . 27
       5.2.7.  Infrastructure security  . . . . . . . . . . . . . . . 27
       5.2.8.  Robustness . . . . . . . . . . . . . . . . . . . . . . 28
       5.2.9.  Management tools, OAM  . . . . . . . . . . . . . . . . 28



Morin                     Expires June 18, 2006                 [Page 4]


Internet-Draft              L3VPN Mcast Reqs               December 2005


       5.2.10. Architectural Considerations . . . . . . . . . . . . . 29
       5.2.11. Compatibility and migration issues . . . . . . . . . . 29
       5.2.12. Troubleshooting  . . . . . . . . . . . . . . . . . . . 30
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 31
   7.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 32
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 33
     8.1.  Normative references . . . . . . . . . . . . . . . . . . . 33
     8.2.  Informative references . . . . . . . . . . . . . . . . . . 34
   Appendix A.  Requirements summary  . . . . . . . . . . . . . . . . 38
     A.1.  General Requirements (Section 3) . . . . . . . . . . . . . 38
     A.2.  Scalability orders of magnitude (Section 4.2)  . . . . . . 38
     A.3.  Requirements from mutlicast VPN customer standpoint
           (Section 5.1)  . . . . . . . . . . . . . . . . . . . . . . 38
     A.4.  Requirements from provider standpoint  . . . . . . . . . . 42
   Appendix B.  Changelog . . . . . . . . . . . . . . . . . . . . . . 47
     B.1.  Changes between -00 and -01  . . . . . . . . . . . . . . . 47
     B.2.  Changes between -01 and -02  . . . . . . . . . . . . . . . 47
     B.3.  Changes between -02 and -03  . . . . . . . . . . . . . . . 48
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 49
   Intellectual Property and Copyright Statements . . . . . . . . . . 50































Morin                     Expires June 18, 2006                 [Page 5]


Internet-Draft              L3VPN Mcast Reqs               December 2005


1.  Introduction

   VPN services satisfying requirement 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 VPN
   technologies deployed in the provider network.  They scale well for
   the following reasons:

   o  because P-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 done in
   standardization bodies which has led, in particular, to the
   definition of the PIM and IGMP protocols.

   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 L3 VPN requirements [RFC4031]
   document, by specifying additional requirements specific to the
   deployment of IP multicast-based services within PPVPNs.  It
   clarifies the needs from both VPN client and provider standpoints and
   formulates the problems that should be addressed by technical
   solutions with as a key objective to stay solution agnostic.  There
   is no intent to either specify solution-specific details in this
   document or application-specific requirements.  Also this document
   does NOT aim at expressing multicast-inferred 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                     Expires June 18, 2006                 [Page 6]


Internet-Draft              L3VPN Mcast Reqs               December 2005


2.  Conventions used in this document

2.1.  Terminology

   Although the reader is assumed to be familiar with the terminology
   defined in [RFC4031], [RFC2547] and RFC2547bis [I-D.ietf-l3vpn-
   rfc2547bis], PIM-SM [RFC2362], PIM-SSM [I-D.ietf-ssm-arch] the
   following glossary of terms may be worthwhile.

   Moreover we also propose here generic terms for concept that
   naturally appears when multicast in VPNs is discussed.

   ASM: Any Source Multicast.  One of the two multicast service models
      that denotes the source/receiver heuristic.

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

   PPVPN: Provider-Provisioned Virtual Private Network

   PE/CE: Provider/Customer edge Equipment ([RFC4026])

   VRF or VR: By this phrase, we refer to the entity defined in a PE
      dedicated to a specific VPN instance.  "VRF" refers to [RFC2547]
      terminology, and "VR" to the VR [I-D.ietf-l3vpn-vpn-vr]
      terminology.

   MD Tunnel: Multicast Distribution Tunnel, the means by which the
      customer's multicast traffic will be conveyed 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 seems to assume that distribution tunnels are
      unidirectional, but the wording encompasses bi-directional tunnels
      as well.

   G: Denotes a multicast group

   Multicast channel: (S,G) in the SSM model

   Participating device: Refers to any network device that not only
      participates to the deployment and the maintenance of the VPN
      infrastructure, but also to the establishment and the maintenance
      of the MD Tunnel (see above).






Morin                     Expires June 18, 2006                 [Page 7]


Internet-Draft              L3VPN Mcast Reqs               December 2005


   S: Denotes a multicast source

   SP: Service provider

   SSM: Source Specific Multicast.  One of the two multicast service
      models where each corresponding service relies upon the use of a
      single source.

   RP: Rendez-vous point (PIM-SM [RFC2362])

   Please refer to [RFC4026] for details about terminology specifically
   relevant to VPN aspects, and to [RFC2432] for multicast performance
   or 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                     Expires June 18, 2006                 [Page 8]


Internet-Draft              L3VPN Mcast Reqs               December 2005


3.  Problem Statement

3.1.  Motivations

   More and more L3 VPN 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 would consist in using point-
   to-point tunnels across the provider network and requiring the PE
   routers (provider's routers) to replicate traffic.  This is obviously
   sub-optimal as it places the replication burden on the PE and hence
   has very poor scaling characteristics.  It may also waste bandwidth
   and control plane resources in the provider's network.

   Thus, to provide multicast services for L3 VPN networks in an
   efficient manner (that is, with scalable impact on signaling and
   protocol state as well as bandwidth usage), in a large scale
   environment, new mechanisms are required to enhance existing L3 VPN
   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 requirements
   documented in [RFC4031]: as far as possible, a multicast service
   should have the same flavor as the unicast equivalent, including the
   same simplicity (technology unaware), the same quality of service (if
   any), the same management (e.g. monitoring of performances), etc.

   Moreover, it also has to be clear that a multicast VPN solution MUST
   interoperate seamlessly with current unicast 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, RFC2547bis [I-D.ietf-l3vpn-rfc2547bis] or VR [I-D.ietf-
   l3vpn-vpn-vr]) and retain consistency with those, although this is
   not a core requirement.

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 likely requires maintaining



Morin                     Expires June 18, 2006                 [Page 9]


Internet-Draft              L3VPN Mcast Reqs               December 2005


   multicast state in the core network.

   Consequently, some trade-off has to be made and this document will
   express some requirements related to this trade-off.















































Morin                     Expires June 18, 2006                [Page 10]


Internet-Draft              L3VPN Mcast Reqs               December 2005


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 content of these sections originates from a survey done among
   institutions and providers that expect to deploy such solutions, in
   summer 2005.  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 were such high expectations were expressed only in few
   answers.

4.1.  Scenarios

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

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

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.  A
   typical application are broadcast TV, production studios
   connectivity, 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



Morin                     Expires June 18, 2006                [Page 11]


Internet-Draft              L3VPN Mcast Reqs               December 2005


      handled

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

   o  bandwidth depend on the application, but may vary between a few
      tens/hundreds 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 requirement 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 applications: 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, but this will depend on audience and
      capillarity of provider equipments

4.1.2.  Symetric applications

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

   Their characteristics is 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 impact a lot how the bandwidth/state is managed,
   because :

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





Morin                     Expires June 18, 2006                [Page 12]


Internet-Draft              L3VPN Mcast Reqs               December 2005


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

   indicate that optimizing bandwidth may require introducing dedicated
   states in the core network (typically as much as the number of
   groups).

   Last, some of these application may involve realtime interactions,
   and will be highly sensitive to packet loss, jitter and delay.

4.1.3.  Data distribution

   Some applications which are expected to be deployed on multicast VPN
   are non-realtime applications aiming at distributing data from few
   sources and 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
   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).

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 longer term).

   The per mVPN traffic behaviour is not predictable because it's
   completely up to the customer how the service is used.  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 a such 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.






Morin                     Expires June 18, 2006                [Page 13]


Internet-Draft              L3VPN Mcast Reqs               December 2005


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 the mere deployments known
   as of today.

4.2.1.  Number of VPNs with multicast enabled

   From the survey results, we see an 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
   -tens of VPNs- (7 answers) or in 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.

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 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 thus 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
   number of PEs per multicast VPNs 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



Morin                     Expires June 18, 2006                [Page 14]


Internet-Draft              L3VPN Mcast Reqs               December 2005


   multicast VPN, and MAY usefully scale up to thousands.

4.2.4.1.  ... with sources

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

   Typical numbers are of tens of source-connected-PEs (6 responses), or
   hundreds (4 responses).  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).

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













Morin                     Expires June 18, 2006                [Page 15]


Internet-Draft              L3VPN Mcast Reqs               December 2005


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 two different
   standpoints of two different important entities: the end user (the
   customer using the VPN) and the service provider.

   In the rest of the document, we mean by "a solution" or "a multicast
   VPN solution", a solution that allows to perform 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's devices (CE) to support any extra
   feature compared to those required for multicast in a non-VPN
   context.

5.1.2.  CE-PE Multicast routing and management protocols

   Consequently to Section 3.1, the CEs and PEs SHOULD employ existing
   multicast protocols.

   Such protocols SHOULD include : PIM-SM [RFC2362] (including PIM-SSM
   [I-D.ietf-ssm-arch]), bidirectional PIM [I-D.ietf-pim-bidir], PIM-DM
   [RFC3973], and IGMP (v1 [RFC1112], v2 [RFC2236] and v3 [RFC3376]).

   Among those protocols, the support of PIM-SM (including SSM model)
   and IGMP is REQUIRED (and MLD support is REQUIRED for IPv6
   implementations).  Bidir-PIM Support at the PE-CE interface is
   RECOMMENDED.  And considering deployments, PIM-DM is considered as
   OPTIONAL.

   When IPv6 is supported by a VPN solution, relevant IPv6 corresponding
   protocols MUST also be supported, e.g.  Multicast Listener Discovery
   Protocol (MLD) (v1 [RFC2710]], v2 [RFC3810]]).

5.1.3.  Quality of Service (QoS)

   First, general considerations about QoS in L3 VPNs as developed in
   section 5.5 of [RFC4031] are also relevant to this section.

   QoS is measured in terms of delay, jitter, packet loss, and



Morin                     Expires June 18, 2006                [Page 16]


Internet-Draft              L3VPN Mcast Reqs               December 2005


   availability.  These metrics are already defined for the current
   unicast PPVPN services, and are included in Service Level
   Agreements(SLA).  In some cases, provided SLA may be different
   between unicast and multicast, which will need service
   differentiation mechanisms as such.

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

   A multicast in VPN solution shall allow to define at least the same
   level of quality of service than what exists for unicast, and than
   what exists for multicast in a non-VPN context.  From this
   perspective, the deployment of multicast-based services within an L3
   PPVPN 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, the solution should have 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 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.

   Last, 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 have also to
   be considered when a new source starts to send traffic to a group:



Morin                     Expires June 18, 2006                [Page 17]


Internet-Draft              L3VPN Mcast Reqs               December 2005


   any receiver interested in receiving such traffic SHOULD be serviced
   accordingly.

5.1.4.  SLA parameters measurement

   As Service Level Agreement (SLA) parameters are part of the service
   that is sold, they are often monitored.  The monitoring is used for
   technical reasons by the service provider and is often sold to the
   customer for end-to-end service purposes.

   The solution MUST support SLA monitoring capabilities, which MAY
   possibly rely upon similar techniques (than those used by the unicast
   for the same monitoring purposes).

   Multicast specific characteristics that may be monitored are, for
   instance, multicast statistics per stream, end-to-end delay and group
   join delay (time to start receiving a multicast group traffic across
   the VPN, as defined in [RFC2432] section 3).

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

5.1.5.  Security Requirements

   Security is a key point for a customer who uses subscribes to a VPN
   service.  The RFC2547bis [I-D.ietf-l3vpn-rfc2547bis] 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.

   Moreover, the activation of multicast features SHOULD be possible:

   o  with a VRF or VR granularity

   o  with a CE granularity (when multiple CE of a same VPN are
      connected to a common VRF)

   o  with a distinction between multicast reception and emission

   o  with a multicast group and/or channel granularity

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



Morin                     Expires June 18, 2006                [Page 18]


Internet-Draft              L3VPN Mcast Reqs               December 2005


   this for specific customers (and/or specific customer multicast
   streams).

5.1.6.  Monitoring and Troubleshooting

   A service provider and its customers MUST be able to manage the
   capabilities and characteristics of their multicast VPN services.
   Automated operations and interoperability with standard management
   platforms SHOULD be supported.

   Service management should also include the TMN 'FCAPS'
   functionalities, as follows: Fault, Configuration, Accounting,
   Provisioning, and Security.

   The monitoring of multicast specific parameters and statistics SHOULD
   include :

   o  multicast traffic statistics: total traffic conveyed, incoming,
      outgoing, dropped, etc., by period of time (as a MUST)

   o  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. (as a MAY)

   Apart from statistics on multicast traffic, customers of a multicast
   VPN will need information concerning the status of their multicast
   resource usage (state and bandwidth).  Indeed, as mentioned in
   Section 5.2.4, for scalability purposes, a service provider may limit
   the number (and/or throughput) of multicast streams that are received
   and produced at a client site, and so a multicast VPN solution SHOULD
   allow customers to find out their current resource usage (state and
   throughput), and to receive some kind of feedback if their usage
   exceed bounds.  Whether this issue will be better handled at the
   protocol level at the PE-CE interface or via the ISP customer
   support, needs further discussion.

5.1.7.  Extranet

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

   A multicast VPN solution MUST support such deployments.

   More precisely this means that a multicast VPN solution MUST offer
   means so that:



Morin                     Expires June 18, 2006                [Page 19]


Internet-Draft              L3VPN Mcast Reqs               December 2005


   o  receivers behind attached CEs can receive multicast traffic
      sourced in any of the VPNs (if security policy permits)

   o  sources behind attached CEs can reach multicast traffic receivers
      located in any of the VPNs

   o  multicast can be independently enabled for the different VPNs (and
      multicast reception and emission can also be independently
      enabled)

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

   For instance, it must be possible to configure a VRF so that an
   enterprise site participating to 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.

5.1.8.  Internet Multicast

   Connectivity with Internet Multicast (as a source or receiver)
   somehow fits in the context of the previous section.

   It should be considered OPTIONAL given additional considerations
   needed to fulfill requirements for Internet side, such as security
   treatment.

5.1.9.  Carrier's carrier

   Many L3 PPVPN solutions, such as RFC2547bis [I-D.ietf-l3vpn-
   rfc2547bis] and VR [I-D.ietf-l3vpn-vpn-vr] define the "Carrier's
   Carrier" model, where a "carrier's carrier" service provider supports
   one or more customer ISP, 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.3.

   In the context of MPLS-based L3VPN deployments, such as BGP/MPLS VPNs
   [I-D.ietf-l3vpn-rfc2547bis], this means that MPLS label distribution
   SHOULD happen at the PE-CE level, giving the ability to the sub-



Morin                     Expires June 18, 2006                [Page 20]


Internet-Draft              L3VPN Mcast Reqs               December 2005


   carrier to use multipoint LSPs as a tunneling mechanism.

5.1.10.  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 failover.  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 failover.

   On the other hand, it is also necessary to care about failover
   mechanisms that are unique to multicast routing control.  For
   instance, if the customer uses some control mechanism for RP
   redundancy on PIM-SM (e.g.  BSR), it SHOULD work transparently
   through that VPN.

5.1.11.  RP Engineering

   When PIM-SM (or bidir-PIM) is used in ASM mode on the VPN customer
   side, the location of the RP has to be chosen.  In some cases this
   engineering problem is not trivial: for instance, if sources and
   receivers are located in VPN sites that are different than that of
   the RP, then traffic may 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 is obviously not ideal.  A multicast VPN solution
   SHOULD propose a way to help on solving this RP engineering issue.

   Moreover, some service providers offer to manage customer's multicast
   protocol operation on behalf of them.  This implies that it is needed
   to consider cases where the customer's RPs are outsourced (e.g., on
   PEs).

5.1.12.  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.  If the ASM model is used, this
   implies the use of the multicast administratively scoped range,
   (239/8 as per [RFC2365]) for services which are to be used only



Morin                     Expires June 18, 2006                [Page 21]


Internet-Draft              L3VPN Mcast Reqs               December 2005


   inside the VPN, and of globally assigned group addresses for services
   for which traffic may be transmitted outside the VPN (e.g.  GLOP
   [RFC3180]).

5.1.13.  Minimum MTU

   For customers, it is often a serious issue whether transmitted
   packets will be fragmented or not.  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 let customers' devices be
   free of any fragmentation or reassembly activity.

   A committed minimum path MTU size SHOULD be provided to customers.
   Moreover, since Ethernet LAN segments are often located at first and
   last hops, a minimum 1500 bytes IP MTU SHOULD be provided.

   It SHOULD also be compatible with Path MTU discovery mechanisms, such
   as those defined in [RFC1191] or [I-D.mathis-frag-harmful].

5.2.  Service provider standpoint

   Note: please remember that, 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.  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
   RFC2547bis [I-D.ietf-l3vpn-rfc2547bis] and VR [I-D.ietf-l3vpn-vpn-vr]
   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 customers'
   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                     Expires June 18, 2006                [Page 22]


Internet-Draft              L3VPN Mcast Reqs               December 2005


   It is expected that multicast VPN solutions will use some kind of
   point point-to-multipoint technology to efficiently carry multicast
   VPN traffic, and that such technologies require maintaining state
   information, and will use resources in the control plane (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 the
   number of any of the following:

   o  the number of PEs

   o  the number of customers 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. signalling throughput)

   o  the amount of control plane processing required on PE and P to add
      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 impacts
      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                     Expires June 18, 2006                [Page 23]


Internet-Draft              L3VPN Mcast Reqs               December 2005


   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 in VPNs solution should address both P and
   PE routers as far as scalability is concerned.

5.2.2.  Resource optimization

5.2.2.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 same data travels
   twice or more on a same 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.2.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 the
   service providers appropriate configuration settings that let them
   tune the trade-off according to their peculiar constraints (network
   topology, platforms, customer applications, level of service offered
   etc.).

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

   Bandwidth optimization: setting up somehow optimal core MDTunnels
      whose topology (PIM or P2MP LSP trees, etc.) precisely follows
      customer's multicast routing changes.  This requires managing an
      important quantity of states 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 bad in terms



Morin                     Expires June 18, 2006                [Page 24]


Internet-Draft              L3VPN Mcast Reqs               December 2005


      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.2.3.  Traffic engineering

   If the VPN service provides traffic engineering 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 a 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.3.  Tunneling Requirements

5.2.3.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 inter-dependent: 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
   by the design of the solution.  The solution SHOULD also 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 privileged: such a
   solution SHOULD allow the use of the same tunneling technology for
   multicast as for unicast.  Deployment consistency, ease of operation



Morin                     Expires June 18, 2006                [Page 25]


Internet-Draft              L3VPN Mcast Reqs               December 2005


   and potential migrations are the main motivations behind this
   requirement.

   For MDTunnels (multicast distribution tunnels, the means used to
   carry VPNs' multicast traffic over the provider's network), a
   solution SHOULD be able to use a range of tunneling technologies,
   including point-to-point and point-to-multipoint, such as GRE
   [RFC2784] (including GRE in multicast IP trees), MPLS [RFC3031]
   (including P2P or MP2P tunnels, and multipoint tunnels signaled with
   MPLS P2MP extensions to RSVP [I-D.ietf-mpls-rsvp-te-p2mp] or LDP
   [I-D.leroux-mpls-mp-ldp-reqs][I-D.minei-wijnands-mpls-ldp-p2mp]),
   L2TP (including L2TP for multicast [RFC4045]), IPsec [RFC2401], IP-
   in-IP [RFC1853], etc.

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

5.2.3.2.  MTU and Fragmentation

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

   o  fragmentation inside the MDTunnel -even when allowed by the
      tunneling technology used- does not happen

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

5.2.4.  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.




Morin                     Expires June 18, 2006                [Page 26]


Internet-Draft              L3VPN Mcast Reqs               December 2005


   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.5.  Support of Inter-AS, inter-provider deployments

   A solution MUST support inter-AS multicast VPNs, and SHOULD support
   inter-provider mutlicast VPNs.  Considerations about coexistence with
   unicast inter-AS VPN Options A, B and C (as described in section 10
   of RFC2547bis [I-D.ietf-l3vpn-rfc2547bis]) 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 co-ordination to setup such a tunnel is
      minimized

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

5.2.6.  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.7.  Infrastructure security

   The solution shall provide the same level of security for the service
   provider as what currently exist for unicast VPNs.  For instance,
   that means that the intrinsic protection against DOS and DDOS attacks
   of the BGP/MPLS VPN solution must be equally supported by the
   multicast solution.




Morin                     Expires June 18, 2006                [Page 27]


Internet-Draft              L3VPN Mcast Reqs               December 2005


   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 L3 VPN MAY represent a superset of the
   participating devices that are also involved in the establishment and
   the 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.

   Unwanted multicast traffic (e.g. multicast traffic that may be sent
   by a source located somewhere in the Internet and for which there is
   no interested receiver connected to a given VPN infrastructure) MUST
   NOT be propagated within a multicast-enabled VPN.

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

   Last, control mechanisms described in previous section are also to be
   considered from this infrastructure security point of view.

5.2.8.  Robustness

   Resiliency is also crucial to infrastructure security, thus a
   multicast VPN solution SHOULD whether avoid single points of failures
   or propose some technical solution making 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 setup MDTunnels.  In such a case, the
   PIM RP might be a single point of failure.  Such a solution should
   thus be compatible with a solution implementing RP resiliency.

5.2.9.  Management tools, OAM

   The operation of a multicast VPN solution SHALL be as light as
   possible and providing automatic configuration and discovery SHOULD



Morin                     Expires June 18, 2006                [Page 28]


Internet-Draft              L3VPN Mcast Reqs               December 2005


   be prioritized.  Particularly the operational cost of setting up
   multicast on a PE should be as low as possible.

   Moreover, monitoring of multicast specific parameters and statistics
   SHOULD be offered to the service provider.

   Most notably the provider SHOULD have access to:

   o  Multicast traffic statistics (total traffic conveyed, incoming,
      outgoing, dropped, etc., by period of time) - Information about
      client multicast resource usage (state and throughput)

   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  Alarms when limits are reached on such resources - 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

   All or part of this information SHOULD be made available through
   standardized SNMP ([RFC1157]) MIBs (Management Information Base).

5.2.10.  Architectural Considerations

   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 unicast VPN, the
   balance between their advantage and operation burden should be
   examined thoroughly.

5.2.11.  Compatibility and migration issues

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

   Likewise, the introduction of IP multicast VPN capabilities in
   devices that participate to the deployment and the maintenance of a
   multicast VPN SHOULD be as smooth as possible, i.e. without affecting
   the overall quality provided with the services that are already
   supported by the underlying infrastructure.

   A multicast VPN solution SHOULD prevent compatibility and migration



Morin                     Expires June 18, 2006                [Page 29]


Internet-Draft              L3VPN Mcast Reqs               December 2005


   issues, for instance by prioritizing mechanisms facilitating forward
   compatibility.  Most notably a solution supporting only a subset of
   those requirements SHOULD be designed to be compatible with future
   enhanced revisions.

   It SHOULD be an aim of any multicast VPN solution to offer as much
   backward compatibility as possible.  Ideally a solution would have be
   the ability to offer multicast VPN services across a network
   containing some legacy routers not supporting 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 such and such
   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 usefully provide some mechanism letting
   network operators check that all VPN sites that advertised interest
   in a particular customer multicast stream are properly associated
   with the corresponding MDTunnel.  Providing the operators with means
   to check the proper setup and operation of MDTunnels MAY also be
   provided (e.g. when MPLS is used for MDTunnels, integrating
   mechanisms such as LSPPing[I-D.ietf-mpls-lsp-ping][I-D.ietf-mpls-
   p2mp-lsp-ping] into the L3VPN troubleshooting functionalities will be
   desirable).  Depending on the implementation such verification could
   be initiated by source-PE or receiver-PE.














Morin                     Expires June 18, 2006                [Page 30]


Internet-Draft              L3VPN Mcast Reqs               December 2005


6.  Security Considerations

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

   A set of security issues have been identified that MUST be addressed
   when considering the design and deployment of multicast-enabled VPN
   networks.  Such issues have been described in Section 5.1.5 and
   Section 5.2.7.











































Morin                     Expires June 18, 2006                [Page 31]


Internet-Draft              L3VPN Mcast Reqs               December 2005


7.  Acknowledgments

   The authors would like to thank, by rough chronological order,
   Vincent Parfait (Equant), Zubair Ahmad (Equant), Elodie Hemon-
   Larreur, Sebastien Loye (France Telecom), Rahul Aggarwal (Juniper),
   Hitoshi Fukuda (NTT Communications), Luyuan Fang (AT&T), Adrian
   Farrel, Daniel King, Yiqun Cai (Cisco), Ronald Bonica, Len Nieman,
   Satoru Matsushima (Japan Telecom), Netzahualcoyotl Ornelas (Renater),
   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.







































Morin                     Expires June 18, 2006                [Page 32]


Internet-Draft              L3VPN Mcast Reqs               December 2005


8.  References

8.1.  Normative references

   [RFC3978]  Bradner, S., "IETF Rights in Contributions", BCP 78,
              RFC 3978, March 2005.

   [RFC2026]  Bradner, S., "The Internet Standards Process -- Revision
              3", BCP 9, RFC 2026, October 1996.

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

   [RFC2362]  Estrin, D., Farinacci, D., Helmy, A., Thaler, D., Deering,
              S., Handley, M., and V. Jacobson, "Protocol Independent
              Multicast-Sparse Mode (PIM-SM): Protocol Specification",
              RFC 2362, June 1998.

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

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

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

   [RFC2710]  Deering, S., Fenner, W., and B. Haberman, "Multicast
              Listener Discovery (MLD) for IPv6", RFC 2710,
              October 1999.

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






Morin                     Expires June 18, 2006                [Page 33]


Internet-Draft              L3VPN Mcast Reqs               December 2005


8.2.  Informative references

   [RFC2547]  Rosen, E. and Y. Rekhter, "BGP/MPLS VPNs", RFC 2547,
              March 1999.

   [I-D.ietf-l3vpn-rfc2547bis]
              Rosen, E., "BGP/MPLS IP VPNs",
              draft-ietf-l3vpn-rfc2547bis-03 (work in progress),
              October 2004.

   [I-D.ietf-l3vpn-vpn-vr]
              Knight, P., Ould-Brahim, H., and B. Gleeson, "Network
              based IP VPN Architecture using Virtual Routers",
              draft-ietf-l3vpn-vpn-vr-02 (work in progress), April 2004.

   [I-D.ietf-ssm-arch]
              Holbrook, H. and B. Cain, "Source-Specific Multicast for
              IP", draft-ietf-ssm-arch-07 (work in progress),
              October 2005.

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

   [I-D.ietf-mpls-rsvp-te-p2mp]
              Aggarwal, R., "Extensions to RSVP-TE for Point to
              Multipoint TE LSPs", draft-ietf-mpls-rsvp-te-p2mp-03 (work
              in progress), October 2005.

   [I-D.minei-wijnands-mpls-ldp-p2mp]
              Minei, I., "Label Distribution Protocol Extensions for
              Point-to-Multipoint and  Multipoint-to-Multipoint Label
              Switched Paths", draft-minei-wijnands-mpls-ldp-p2mp-00
              (work in progress), October 2005.

   [I-D.leroux-mpls-mp-ldp-reqs]
              Roux, J., "Requirements for point-to-multipoint extensions
              to the Label Distribution  Protocol",
              draft-leroux-mpls-mp-ldp-reqs-02 (work in progress),
              October 2005.

   [I-D.ietf-pim-bidir]
              Handley, M., "Bi-directional Protocol Independent
              Multicast (BIDIR-PIM)", draft-ietf-pim-bidir-08 (work in
              progress), October 2005.




Morin                     Expires June 18, 2006                [Page 34]


Internet-Draft              L3VPN Mcast Reqs               December 2005


   [RFC1853]  Simpson, W., "IP in IP Tunneling", RFC 1853, October 1995.

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

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

   [RFC2401]  Kent, S. and R. Atkinson, "Security Architecture for the
              Internet Protocol", RFC 2401, November 1998.

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

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

   [RFC1157]  Case, J., Fedor, M., Schoffstall, M., and J. Davin,
              "Simple Network Management Protocol (SNMP)", STD 15,
              RFC 1157, May 1990.

   [I-D.ietf-mpls-lsp-ping]
              Kompella, K. and G. Swallow, "Detecting MPLS Data Plane
              Failures", draft-ietf-mpls-lsp-ping-12 (work in progress),
              December 2005.



Morin                     Expires June 18, 2006                [Page 35]


Internet-Draft              L3VPN Mcast Reqs               December 2005


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

   [I-D.ietf-mpls-p2mp-lsp-ping]
              Yasukawa, S., "Detecting Data Plane Failures in Point-to-
              Multipoint MPLS Traffic  Engineering - Extensions to LSP
              Ping", draft-ietf-mpls-p2mp-lsp-ping-00 (work in
              progress), September 2005.

   [I-D.mathis-frag-harmful]
              Mathis, M., "Fragmentation Considered Very Harmful",
              draft-mathis-frag-harmful-00 (work in progress),
              July 2004.

   [RFC2629]  Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
              June 1999.



































Morin                     Expires June 18, 2006                [Page 36]


Internet-Draft              L3VPN Mcast Reqs               December 2005


URIs

   [3]  <mailto:christian.jacquenet@francetelecom.com>

   [4]  <mailto:y.kamite@ntt.com>

   [5]  <mailto:jeanlouis.leroux@francetelecom.com>

   [6]  <mailto:nicolai.leymann@t-systems.com>

   [7]  <mailto:renaud.moignard@francetelecom.com>

   [8]  <mailto:thomas.morin@francetelecom.com>






































Morin                     Expires June 18, 2006                [Page 37]


Internet-Draft              L3VPN Mcast Reqs               December 2005


Appendix A.  Requirements summary

   This section is a summary of all requirements expressed as MUST or
   SHOULD, proposed for quick reference.

   Please keep in mind that the full text of corresponding sections is
   the one reference, and refer to it to uncover any ambiguity in the
   summaries below.

A.1.  General Requirements (Section 3)

   o  SHOULD satisfy requirements documented in RFC4031 "Service
      Requirements for Layer 3 Provider Provisioned Virtual Private
      Networks (PPVPNs)"

   o  MUST interoperate seamlessly with current unicast solutions

A.2.  Scalability orders of magnitude (Section 4.2)

   A multicast VPN solution...

   o  SHOULD support a number of multicast VPNs ranging from one to
      several thousands

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

   o  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)

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

   o  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)

   o  SHOULD support hundreds or even thousands of streams sourced per
      VPN

   o  SHOULD support hundreds of streams sourced per PE

A.3.  Requirements from mutlicast VPN customer standpoint (Section 5.1)






Morin                     Expires June 18, 2006                [Page 38]


Internet-Draft              L3VPN Mcast Reqs               December 2005


   o  Service definition

      *  the multicast service MUST be provider provisioned and SHALL
         NOT require customer's devices (CE) to support any extra
         feature compared to those required for multicast in a non-VPN
         context

   o  CE-PE Protocols

      *  CEs and PEs SHOULD employ existing multicast protocols

      *  the support of PIM-SM (including SSM model) and IGMP is
         REQUIRED

      *  Bidir-PIM support is RECOMMENDED

      *  when IPv6 is supported by a VPN solution, relevant IPv6
         corresponding protocols SHOULD also be supported / MLD support
         is REQUIRED for IPv6 implementations

   o  QoS Requirements

      *  the level of availability for the multicast service SHOULD be
         on par with what exists for unicast traffic

      *  same traffic protection mechanisms SHOULD be available for
         customer multicast traffic when it is carried over the service
         provider's network.

      *  DiffServ mechanisms that include multicast traffic
         identification, classification and marking capabilities, as
         well as multicast traffic policing, scheduling and conditioning
         capabilities, MUST be supported

      *  it is RECOMMENDED that a multicast VPN solution be designed
         appropriately with regards to group join delay performance

      *  it SHOULD be possible to tune the multicast routing or group
         management protocol used on the PE-CE adjacency to reduce the
         group leave delay to the minimum

      *  a multicast VPN solution SHOULD as much as possible ensure that
         client multicast 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 have to be considered when a new source
         starts to send traffic to a group: any receiver interested in



Morin                     Expires June 18, 2006                [Page 39]


Internet-Draft              L3VPN Mcast Reqs               December 2005


         receiving such traffic SHOULD be serviced accordingly

   o  SLA Parameters measurements

      *  a multicast VPN solution MUST support SLA monitoring
         capabilities

   o  Security Requirements

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

      *  the activation of multicast features SHOULD be possible:

         +  with a VRF or VR granularity

         +  with a CE granularity (when multiple CE of a same VPN are
            connected to a common VRF)

         +  with a distinction between multicast reception and emission

         +  with a multicast group and/or channel granularity

   o  Monitoring and troubleshooting

      *  a service provider and its customers MUST be able to manage the
         capabilities and characteristics of their multicast VPN
         services

      *  automated operations and interoperability with standard
         management platforms SHOULD be supported

      *  the monitoring of multicast specific parameters and statistics
         MUST include multicast traffic statistics: total traffic
         conveyed, incoming, outgoing, dropped, etc., by period of time

      *  a multicast VPN solution SHOULD allow customers to find out
         their current resource usage and to receive some kind of
         feedback if their usage exceed bounds

   o  Extranet

      *  a multicast VPN solution MUST support deployments where VRFs or
         VR are part of more than one multicast VPN

      *  a multicast VPN solution MUST offer means so that:




Morin                     Expires June 18, 2006                [Page 40]


Internet-Draft              L3VPN Mcast Reqs               December 2005


         +  receivers behind attached CEs can receive multicast traffic
            sourced in any of the VPNs

         +  sources behind attached CEs can reach multicast traffic
            receivers located in any of the VPNs

         +  multicast can be independently enabled for the different
            VPNs

      *  support for this feature SHOULD not require replicating
         multicast traffic on a PE-CE link

   o  Carrier's carrier

      *  A multicast VPN solution SHOULD support the carrier's carrier
         model in a scalable and efficient manner

      *  the protocols that may be used at the PE-CE level SHOULD NOT be
         restricted to protocols required as per Section 5.1.2 (CE-PE
         Multicast routing and management protocols) and SHOULD include
         some of the protocols listed in Section 5.2.3 (Tunneling
         Requirements)

      *  in the context of MPLS-based L3VPN deployments, some MPLS label
         distribution SHOULD happen at the PE-CE level

   o  Multihoming

      *  a multicast VPN solution SHOULD be able to offer multi-homing,
         CE-PE link load balancing and failover

      *  a multicast VPN solution SHOULD support redundant topology of
         CE-PE links

      *  a multicast VPN solution SHOULD minimize multicast traffic
         disruption and failover

      *  if the customer uses some control mechanism for RP redundancy
         on PIM-SM (e.g.  BSR), it SHOULD work transparently through
         that VPN

   o  RP Engineering

      *  a multicast VPN solution SHOULD propose a way to help on
         solving the RP engineering issue in a VPN context






Morin                     Expires June 18, 2006                [Page 41]


Internet-Draft              L3VPN Mcast Reqs               December 2005


   o  Addressing

      *  a multicast VPN solution SHOULD NOT impose restrictions on
         multicast group addresses used by VPN customers

      *  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

   o  Minimum MTU

      *  a multicast VPN solution SHOULD let customers' devices be free
         of any fragmentation or reassembly activity

      *  a committed minimum path MTU size SHOULD be provided to
         customers

      *  a minimum 1500 bytes IP MTU SHOULD be provided

      *  a multicast VPN solution SHOULD also be compatible with Path
         MTU discovery mechanisms

A.4.  Requirements from provider standpoint

   o  Scalability

      *  solutions MUST be designed to scale well with an increase in
         the number of any of the following:

         +  the number of PEs

         +  the number of customers VPNs (total and per PE)

         +  the number of PEs and sites in any VPN

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

      *  scalability of both performance and operation MUST be
         considered

      *  key considerations SHOULD include:

         +  the processing resources required by the control plane
            (neighborhood or session maintenance messages, keep-alives,



Morin                     Expires June 18, 2006                [Page 42]


Internet-Draft              L3VPN Mcast Reqs               December 2005


            timers, etc.)

         +  the memory resources needed for the control plane

         +  the amount of protocol information transmitted to manage a
            multicast VPN (e.g. signalling throughput)

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

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

         +  other particular elements inherent to each solution that
            impacts 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)

      *  solutions SHOULD offer the possibility of sharing core
         resources between different multicast streams

   o  Resource optimization

      *  a multicast VPN solution SHOULD offer the service providers
         appropriate configuration settings that let them tune the
         bandwidth/state trade-off according to their peculiar
         constraints

   o  Traffic Engineering

      *  a multicast VPN solution supporting TE for unicast traffic
         SHOULD also be able to provide traffic engineering features for
         the MDTunnels

      *  a solution SHOULD offer means to support key TE objectives as
         defined in RFC3272 "Overview and Principles of Internet Traffic
         Engineering"

   o  Tunnelling

      *  a multicast VPN solution SHOULD be designed so that control and
         forwarding planes are not inter-dependent

      *  the control plane SHALL NOT depend on which forwarding plane is
         used (and vice versa)





Morin                     Expires June 18, 2006                [Page 43]


Internet-Draft              L3VPN Mcast Reqs               December 2005


      *  the choice of forwarding plane SHOULD NOT be limited by the
         design of the solution

      *  solution SHOULD also NOT be tied to a specific tunneling
         technology

      *  a multicast VPN solution extending a unicast L3 PPVPN solution,
         consistency in the tunneling technology has to be privileged:
         such a solution SHOULD allow the use of the same tunneling
         technology for multicast as for unicast

      *  a solution SHOULD be able to use a range of tunneling
         technologies for MDTunnels, including point-to-point and point-
         to-multipoint, such as [please refer to section Section 5.2.3]

      *  it is RECOMMENDED that a solution is built so that it can use
         the point to multipoint variants of these techniques

      *  a solution SHOULD support a method that provides the minimum
         path MTU of the MDTunnel

   o  Control mechanisms

      *  a solution MUST provide some mechanisms to control the sources
         within a VPN

      *  a solution MUST 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

   o  Inter-As, inter-provider

      *  a multicast VPN solution MUST support inter-AS VPNs

      *  a multicast VPN solution SHOULD support inter-provider VPNs

      *  a multicast VPN solution SHOULD provide inter-AS mechanisms
         requiring the least possible coordination between providers

      *  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




Morin                     Expires June 18, 2006                [Page 44]


Internet-Draft              L3VPN Mcast Reqs               December 2005


      *  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 co-ordination to setup such a tunnel is
         minimized

      *  such support SHOULD be possible without compromising other
         requirements expressed in this requirement document, and SHALL
         NOT incur penalty on scalability and bandwidth usage

   o  QoS differentiation

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

   o  Infrastructure security

      *  some mechanism SHOULD be proposed so that the frequency of
         changes in the way client traffic is carried over the core can
         be bounded

      *  a multicast VPN solution SHOULD whether avoid single points of
         failures or propose some technical solution making possible to
         implement a failover mechanism

      *  it is RECOMMENDED that a multicast VPN solution support means
         to ensure the integrity and authenticity of multicast-related
         exchanges across inter-ASes or inter-provider borders

   o  Robustness

      *  a multicast VPN solution SHOULD whether avoid single points of
         failures or propose some technical solution making possible to
         implement a failover mechanism

   o  Management tools, OAM

      *  automatic configuration and discovery SHOULD be prioritized

      *  monitoring of multicast specific parameters and statistics
         SHOULD be offered to the service provider

      *  the provider SHOULD have access to:

         +  multicast traffic statistics

         +  IP Performance Metrics-related information that is relevant
            to the multicast traffic usage



Morin                     Expires June 18, 2006                [Page 45]


Internet-Draft              L3VPN Mcast Reqs               December 2005


         +  alarms when limits are reached

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

      *  this information SHOULD be made available through standardized
         SNMP

   o  Compatibility and migration issues

      *  unicast and multicast services MUST be able to co-exist within
         the same VPN

      *  the introduction of IP multicast VPN capabilities in devices
         that participate to the deployment and the maintenance of a
         multicast VPN SHOULD be as smooth as possible

      *  a multicast VPN solution SHOULD prevent compatibility and
         migration issues

      *  it SHOULD be an aim of any multicast VPN solution to offer as
         much backward compatibility as possible

      *  a solution SHOULD state a migration policy from possibly
         existing deployments

   o  Troubleshooting

      *  a multicast VPN solution SHOULD provide monitoring information
         describing how client traffic is carried over the network





















Morin                     Expires June 18, 2006                [Page 46]


Internet-Draft              L3VPN Mcast Reqs               December 2005


Appendix B.  Changelog

   This section lists changes made to this document (minor or editorial
   changes excepted) between major revisions.

   It shall be removed before publication as an RFC.

B.1.  Changes between -00 and -01

   o  integrated comments made on L3VPN WG mailing list after -00
      submission

   o  completed Carrier's carrier section (5.1.9)

   o  updates in sections 5.1 and 5.2 about minimum MTU

   o  added a section about "Quality of Service Differentiation" as ISP
      requirement (section 5.2.5)

   o  added P2MP LDP extensions as possible MDTunnels techniques
      (section 5.2.3.1)

   o  started to build section 4 "Use Case"

   o  detailed section 5.1.3 "QoS", most notably about group join and
      leave delays

   o  additions to section 5.2.12 "Inter-AS, inter-provider"

   o  added MDTunnel verification requirement to section 5.2.11

   o  moved "Architectural Considerations" section

   o  moved contributors to top of document

   o  made draft content agnostic to unicast L3VPN solutions

   o  added two appendixes: "Changelog" and "Requirement summary"

   o  conversion to XML [RFC2629] with the help of some scripting and
      Bill Fenner's xml2rfc XMLMind plugin

   o  lot's of editorial changes

B.2.  Changes between -01 and -02






Morin                     Expires June 18, 2006                [Page 47]


Internet-Draft              L3VPN Mcast Reqs               December 2005


   o  based on survey results:

      *  restructure use case scenario section

      *  fill in Scalability orders of magnitude section

      *  better detail requirements for protocols at the PE-CE level

      *  add considerations about PEs with scarce connectivity to
         section 5.2.2.3

      *  step up requirement level for Extranet (Section 5.1.7)

   o  some editorial changes

   o  use capitalized wording for some requirements

   o  fill in requirements summary (Appendix A)

B.3.  Changes between -02 and -03

   o  made inter-AS a MUST (and moved the whole section up)

   o  add a requirement about security of multicast-related exchanges
      across providers/ASes, in Section 5.2.7

   o  some editorial changes and fixed typos
























Morin                     Expires June 18, 2006                [Page 48]


Internet-Draft              L3VPN Mcast Reqs               December 2005


Author's Address

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

   Email: thomas.morin@rd.francetelecom.com










































Morin                     Expires June 18, 2006                [Page 49]


Internet-Draft              L3VPN Mcast Reqs               December 2005


Intellectual Property Statement

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

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

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


Disclaimer of Validity

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


Copyright Statement

   Copyright (C) The Internet Society (2005).  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.


Acknowledgment

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




Morin                     Expires June 18, 2006                [Page 50]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/