[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
Category: Informational                                    February 2005




       Requirements for Multicast in L3 Provider-Provisioned VPNs

              <draft-ietf-l3vpn-ppvpn-mcast-reqts-00.txt>




Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 3 of RFC3667 [RFC3667].  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 become aware will be disclosed,
   in accordance with RFC 3668.

   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 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 l3vpn@ietf.org. The charter for l3vpn may be found
   at http://www.ietf.org/html.charters/l3vpn-charter.html

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.


Morin et al.      Informational - Expires August 2005           [Page 1]


Internet Draft  Requirements for multicast in L3 PPVPNs    February 2005


Table of Contents

   1.      Introduction...............................................3
   2.      Conventions used in this document..........................3
   2.1.    Terminology................................................3
   2.2.    Conventions................................................4
   3.      Problem Statement..........................................5
   3.1.    Motivations................................................5
   3.2.    General Requirements.......................................5
   3.3.    Scalability vs. Optimality.................................5
   4.      Use cases..................................................6
   5.      Requirements for supporting IP multicast within L3 PPVPNs..6
   5.1.    End user/customer standpoint...............................6
   5.1.1.  Service definition.........................................6
   5.1.2.  CE-PE Multicast routing and management protocols...........6
   5.1.3.  Quality of Service (QoS)...................................6
   5.1.4.  SLA parameters measurement.................................7
   5.1.5.  Security Requirements......................................8
   5.1.6.  Monitoring and Troubleshooting.............................8
   5.1.7.  Extranet...................................................9
   5.1.8.  Internet Multicast.........................................9
   5.1.9.  Carrier's carrier..........................................9
   5.1.10. Multi-homing, load balancing and resiliency................9
   5.1.11. RP Engineering............................................10
   5.1.12. Addressing................................................10
   5.1.13. Fragmentation.............................................10
   5.2.    Service provider standpoint...............................11
   5.2.1.  Scalability...............................................11
   5.2.2.  Resource optimization.....................................12
   5.2.3.  Tunneling Requirements....................................13
   5.2.4.  Control mechanisms........................................14
   5.2.5.  Infrastructure security...................................14
   5.2.6.  Robustness................................................15
   5.2.7.  Management tools, OAM.....................................15
   5.2.8.  Compatibility and migration issues........................16
   5.2.9.  Troubleshooting...........................................16
   5.2.10. Inter-AS, inter-provider..................................16
   5.2.11. Architectural Considerations..............................17
   6.      Security Considerations...................................17
   7.      Acknowledgments...........................................17
   8.      References................................................17
   8.1.    Normative references......................................17
   8.2.    Informative references....................................18
   9.      Contributors..............................................19
   10.     Editor's addresses........................................19
   11.     Intellectual Property Notice..............................20







Morin et al.       Informational - Expires August 2005          [Page 2]


Internet Draft  Requirements for multicast in L3 PPVPNs    February 2005


1. Introduction

   VPN services satisfying requirement defined in [VPN-REQ] are now
   being offered by many service providers worldwide.  The success of
   those VPN services is due to intrinsic characteristics of the
   solutions:
      - Customers are unaware of the deployed network technology and do
   not need to activate specific mechanisms to support traffic being
   carried across L3VPN services,
      - P-routers in the core do not need to be explicitly aware of the
   L3VPN services which allows the P-routers to remain unaware of the
   number of VPN customers and so facilitates scalability,
      - Operator's configuration actions when adding new customers are
   minimized by the dynamic configuration of the VPNs.

   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
   PP IP VPN solutions.  A simple solution to support multicast-based
   services in L3 PPVPNs consists in establishing unicast tunnels across
   the core network, and replicating traffic on PEs.  Such a technique,
   despite the advantage of keeping the core unaware of multicast-
   specific issues has obvious drawbacks, which include scalability
   issues, operational costs, and bandwidth usage.

   This document complements the generic L3 VPN requirement document
   [VPN-REQ], 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.

2. Conventions used in this document

2.1. Terminology

   Although the reader is assumed to be familiar with the terminology
   defined in [VPN-REQ], [RFC2547bis], [PIM-SM], [PIM-SSM] the following
   glossary of terms may be worthwhile.


Morin et al.       Informational - Expires August 2005          [Page 3]


Internet Draft  Requirements for multicast in L3 PPVPNs    February 2005


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

   Please refer to the [PPVPN-TERM] document for details about
   terminology specifically relevant to VPN aspects.

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

   - Multicast-enabled VPN: a VPN which supports IP multicast
     capabilities, i.e. whose 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 [PPVPN-TERM]

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

   - 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] and [bidir-PIM])

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



Morin et al.       Informational - Expires August 2005          [Page 4]


Internet Draft  Requirements for multicast in L3 PPVPNs    February 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, it 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 [VPN-REQ]: 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] or [VR]) and retain consistency with
   those, although this is not a core requirement.

3.3. Scalability vs.  Optimality

   When transporting multicast VPN traffic over a service provider
   network, there intrinsically is tension between resource optimization
   and minimizing the number of protocol states maintained.  Thus, some
   trade-off has to be made, and this document will express some
   requirements related to this trade-off.




Morin et al.       Informational - Expires August 2005          [Page 5]


Internet Draft  Requirements for multicast in L3 PPVPNs    February 2005


4. Use cases

   This section aims at presenting a few representative examples of
   multicast deployments in a VPN context.  The goal is to highlight how
   different applications and network contexts may have a different
   impact on how a trade-off is made.

   [to be completed]

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", a solution that
   allows to perform multicast in an L3 provider provisioned VPN, 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 the customer's devices (CE) to support some
   extra features.

5.1.2. CE-PE Multicast routing and management protocols

   Consequently to section 3.1, the CEs and PEs SHOULD be able to
   operate existing multicast protocols.

   Such protocols SHOULD include : PIM-SM [PIM-SM] (including PIM-SSM
   [PIM-SSM], and bidirectional PIM [BIDIR-PIM]), PIM-DM [PIM-DM], and
   IGMP (v1, v2 and v3 [IGMPv1] [IGMPv2] [IGMPv3]).

   Among those protocols, PIM-SM is considered a MUST.

   When IPv6 is supported by a VPN solution, the Multicast Listener
   Discovery Protocol (MLD) SHOULD also be supported (v1, v2 [MLD]
   [MLDv2]).

5.1.3. Quality of Service (QoS)

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

   QoS includes various parameters such as delay, jitter, packet loss,
   and service availability expressed in percentage of time.  These

Morin et al.       Informational - Expires August 2005          [Page 6]


Internet Draft  Requirements for multicast in L3 PPVPNs    February 2005


   parameters are already defined for the current unicast provider
   provider-provisioned VPN services, are sold by the service provider
   to the customers and defined in the SLA (Service Level Agreements).
   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.  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 call admission control.

   Moreover, 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: any receiver interested in
   receiving such traffic SHOULD be serviced accordingly.

5.1.4. SLA parameters measurement

   As 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, delay and latency time
   (time to start receiving a multicast group traffic across the VPN).

   A generic discussion of SLAs is provided in [PPVPN-GR].

Morin et al.       Informational - Expires August 2005          [Page 7]


Internet Draft  Requirements for multicast in L3 PPVPNs    February 2005



5.1.5. Security Requirements

   Security is a key point for a customer who uses subscribes to a VPN
   service.  The RFC2547 model [RFC2547bis] offers some guarantees
   concerning the security level of data transmission within the VPN.

   A multicast VPN solution MUST provide an architecture that can
   provide the same level of security both for both the unicast and
   multicast traffics.

   Moreover, the activation of multicast features SHOULD be possible:
   - with a VRF 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

   A multicast VPN solution may choose to make the optimality/scal-
   ability 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
   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 :
      - multicast traffic statistics: total traffic conveyed, incoming,
   outgoing, dropped, etc., by period of time (as a MUST)
      - 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

Morin et al.       Informational - Expires August 2005          [Page 8]


Internet Draft  Requirements for multicast in L3 PPVPNs    February 2005


   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. The need for a corresponding multicast feature will
   need to be assessed in further revisions of this document.

   If this is the case, a multicast solution SHOULD offer means so that:
   - receivers behind attached CEs can receive multicast traffic sourced
     in any of the VPNs (if security policy permits)
   - sources behind attached CEs can reach multicast traffic receivers
     located in any of the VPNs
   - 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, an enterprise using a multicast-enabled VPN should be
   able to receive multicast streams sent by a source in another VPN,
   and should also be able to be a source for a multicast stream towards
   another VPN.

   In any case a solution not supporting such a feature MUST be
   compatible with setups where a VRF is part of multiple VPNs and MUST
   document how it operates on multicast traffic in such a context.

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

   This issue is to be examined in a further revision.

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

Morin et al.       Informational - Expires August 2005          [Page 9]


Internet Draft  Requirements for multicast in L3 PPVPNs    February 2005

   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
   inside the VPN, and of globally assigned group addresses for services
   for which traffic may be transmitted outside the VPN (e.g. GLOP
   [GLOP]).

5.1.13. Fragmentation

   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, VPN multicast
   solution SHOULD consider the control and management of MTU,
   especially independently from of unicast.

Morin et al.       Informational - Expires August 2005         [Page 10]


Internet Draft  Requirements for multicast in L3 PPVPNs    February 2005


   Any tunneling mode used to carry multicast VPN customer traffic MUST
   properly handle fragmentation, and permit proper path MTU discovery
   for multicast traffic.

5.2. Service provider standpoint

   Note: please remember that, to avoid repetition and confusion with
   terms used in solution draft, 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] model, a P-router sees a number of MPLS tunnels that is
   only linked to the number of PEs and not to the number of customers.

   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.

   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:
       - 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, timers, etc.)
       - the memory resources needed for the control plane


Morin et al.       Informational - Expires August 2005         [Page 11]


Internet Draft  Requirements for multicast in L3 PPVPNs    February 2005


       - the amount of protocol information transmitted to manage
         a multicast VPN (e.g. signaling 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)

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

   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, and that the most sensible approach is a versatile
   solution offering the service providers appropriate configuration
   settings that let them tune the trade-off according to their peculiar


Morin et al.       Informational - Expires August 2005         [Page 12]


Internet Draft  Requirements for multicast in L3 PPVPNs    February 2005


   constraints (network topology, platforms, customer applications,
   level of service offered etc.).

   As an illustration here are some example bounds of the tradeoff
   space:
   - Bandwidth optimization: setting up somehow optimal core MDTunnels
   whose topology (PIM tree or P2MP LSP, etc.) whose topology precisely
   follows customer's multicast routing.  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 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 [RFC 3272], 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.

5.2.3. Tunneling Requirements

   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.  Migration and operations ease are the main
   motivations behind this requirement.



Morin et al.       Informational - Expires August 2005         [Page 13]


Internet Draft  Requirements for multicast in L3 PPVPNs    February 2005


   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 L2TP
   (including L2TP for multicast [L2TP-MCAST]), IPsec [IPSEC], GRE [GRE]
   (including GRE in multicast IP trees), IP-in-IP, MPLS (including P2MP
   [P2MP]), etc.  Naturally, using the point-to-multipoint variants
   mentioned here may help improve bandwidth use in our multicast VPN
   context.

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.

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

   Moreover, since multicast traffic and routing are intrinsically
   dynamic (receiver-initiated), some mechanism must be proposed so that
   the frequency of changes in the way client traffic is carried over
   the core is 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

Morin et al.       Informational - Expires August 2005         [Page 14]


Internet Draft  Requirements for multicast in L3 PPVPNs    February 2005


   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.

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

5.2.6. Robustness

   Resiliency is also crucial to infrastructure security, thus a
   multicast VPN solution shall whether avoid single points of failures
   or propose some technical solution making possible to implement a
   failover 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.7. Management tools, OAM

   The operation of a multicast VPN solution SHALL be as light as
   possible and providing automatic configuration and discovery SHOULD
   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:
      - Multicast traffic statistics (total traffic conveyed, incoming,
   outgoing, dropped, etc., by period of time)
      - Information about client multicast resource usage (state and
   throughput)
      - 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.
      - 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")


Morin et al.       Informational - Expires August 2005         [Page 15]


Internet Draft  Requirements for multicast in L3 PPVPNs    February 2005


      - 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.8. 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 capabilities in devices
   that participate to the deployment and the maintenance of a 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
   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 into VPN solution to offer as
   much backward compatibility as possible.  Ideally, although
   improbable, would be the ability to offer multicast VPN services
   across a network containing some legacy routers not supporting
   multicast VPN specific features.

5.2.9. 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.  Depending on the implementation
   such verification could be initiated by source-PE or receiver-PE.

5.2.10. Inter-AS, inter-provider



Morin et al.       Informational - Expires August 2005         [Page 16]


Internet Draft  Requirements for multicast in L3 PPVPNs    February 2005


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

   Moreover such support should be possible without compromising other
   requirements expressed in this requirement document, and should not
   incur penalty on scalability and bandwidth resource usage.

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

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 sections 4.2.4 and
   4.1.5.

7. Acknowledgments

   The authors would like to thank Vincent Parfait (Equant), Zubair
   Ahmad (Equant), Elodie Hemon-Larreur, Sebastien Loye (France
   Telecom), Rahul Aggarwal (Juniper), Hitoshi Fukuda (NTT
   Communications), Adrian Farrel, Daniel King, for their review,
   valuable input and feedback.

8. References

8.1. Normative references

   [RFC3667]    S.Bradner, "IETF Rights in Contributions", BCP 78, RFC
   3667, February 2004.

   [RFC3668]    S.Bradner, Ed., "Intellectual Property Rights in IETF
   Technology", BCP 79, RFC 3668, February 2004.

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

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

   [VPN-REQ]    M. Carugi, et. al., "Service requirements for Layer 3
   PPVPNs", draft-ietf-l3vpn-requirements-02 (work in progress)

Morin et al.       Informational - Expires August 2005         [Page 17]


Internet Draft  Requirements for multicast in L3 PPVPNs    February 2005



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

   [IGMPv1]     S. Deering, "Host extensions for IP multicasting", RFC
   1112

   [IGMPv2]     W. Fenner, "Internet Group Management Protocol, IGMP
   version 2", RFC 2236, November 1997.

   [IGMPv3]     B. Cain, "Internet Group Management Protocol, Version
   3", RFC 3376


8.2. Informative references

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

   [VR]           P. Knight et al., "Network based IP VPN Architecture
   using Virtual Routers", August 2004, draft-ietf-l3vpn-vpn-vr-02 (work
   in progress)

   [PIM-SSM]      H. Holbrook, B. Cain, "Source-Specific Multicast for
   IP" September 2004, draft-ietf-ssm-arch-06 (work in progress)

   [BIDIR-PIM]    Mark Handley, Isidor Kouvelas, Tony Speakman, Lorenzo
   Vicisano "Bi-directional Protocol Independent Multicast", July 2004,
   draft-ietf-pim-bidir-07 (work in progress)

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

   [P2MP]         R. Aggarwal, D. Papadimitriou, S. Yasukawa, "Extended
   RSVP-TE for Point-to-Multipoint LSP Tunnels", July 2004, draft-
   yasukawa-mpls-rsvp-p2mp-04 (work in progress)

   [L2TP-MCAST]   G. Bourdon, "Extensions to support efficient carrying
   of multicast traffic in Layer-2 Tunneling Protocol (L2TP)", draft-
   ietf-l2tpext-mcast-05 (work in progress)

   [RFC2365]      Meyer, D., ôAdministratively Scoped IP Multicastö, RFC
   2365, July 1998.

   [RFC2330]      Paxson, V. et al., "Framework for IP Performance
   Metrics", RFC 2330, May 1998.

   [RFC2475]      Blake, S., et al., ôAn Architecture for Differentiated
   Serviceö, RFC 2475, December 1998.

Morin et al.       Informational - Expires August 2005         [Page 18]


Internet Draft  Requirements for multicast in L3 PPVPNs    February 2005



   [PPVPN-TERM]   L. Anderssoo, T. Madsen, "Provider Provisioned VPN
   terminology", draft-ietf-l3vpn-ppvpn-terminology-04, September 2004

   [GRE]

   [IP-in-IP]

   [GLOP]         D. Meyer, P. Lothberg "Addressing in 233/8", RFC2770,
   February 2000

   [SNMP]         J. Case et. al, "A Simple Network Management Protocol
   (SNMP)", RFC1157, May 1990

9. Contributors

   Contributors are listed in alphabetical order.

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

   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

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

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

10. Editor's addresses

   Thomas Morin
   France Telecom R & D
   2, avenue Pierre-Marzin

Morin et al.       Informational - Expires August 2005         [Page 19]


Internet Draft  Requirements for multicast in L3 PPVPNs    February 2005


   22307 Lannion Cedex
   France
   Email: thomas.morin@francetelecom.com

11. Intellectual Property Notice

   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.

Full Copyright Statement

   "Copyright (C) The Internet Society (2004).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist its implementation may be prepared, copied, published and
   distributed, in whole or in part, without restriction of any kind,
   provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.



Morin et al.       Informational - Expires August 2005         [Page 20]


Internet Draft  Requirements for multicast in L3 PPVPNs    February 2005


   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.














































Morin et al.       Informational - Expires August 2005         [Page 21]


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