summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc4834.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc4834.txt')
-rw-r--r--doc/rfc/rfc4834.txt2075
1 files changed, 2075 insertions, 0 deletions
diff --git a/doc/rfc/rfc4834.txt b/doc/rfc/rfc4834.txt
new file mode 100644
index 0000000..51d91fe
--- /dev/null
+++ b/doc/rfc/rfc4834.txt
@@ -0,0 +1,2075 @@
+
+
+
+
+
+
+Network Working Group T. Morin, Ed.
+Request for Comments: 4834 France Telecom R&D
+Category: Informational April 2007
+
+
+ Requirements for Multicast in Layer 3 Provider-Provisioned Virtual
+ Private Networks (PPVPNs)
+
+Status of This Memo
+
+ This memo provides information for the Internet community. It does
+ not specify an Internet standard of any kind. Distribution of this
+ memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The IETF Trust (2007).
+
+Abstract
+
+ This document presents a set of functional requirements for network
+ solutions that allow the deployment of IP multicast within Layer 3
+ (L3) Provider-Provisioned Virtual Private Networks (PPVPNs). It
+ specifies requirements both from the end user and service provider
+ standpoints. It is intended that potential solutions specifying the
+ support of IP multicast within such VPNs will use these requirements
+ as guidelines.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Morin Informational [Page 1]
+
+RFC 4834 L3VPN Mcast Reqs April 2007
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 2. Conventions Used in This Document . . . . . . . . . . . . . . 5
+ 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
+ 2.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 6
+ 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 7
+ 3.1. Motivations . . . . . . . . . . . . . . . . . . . . . . . 7
+ 3.2. General Requirements . . . . . . . . . . . . . . . . . . . 7
+ 3.3. Scaling vs. Optimizing Resource Utilization . . . . . . . 8
+ 4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 8
+ 4.1. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . 8
+ 4.1.1. Live Content Broadcast . . . . . . . . . . . . . . . . 9
+ 4.1.2. Symmetric Applications . . . . . . . . . . . . . . . . 10
+ 4.1.3. Data Distribution . . . . . . . . . . . . . . . . . . 10
+ 4.1.4. Generic Multicast VPN Offer . . . . . . . . . . . . . 11
+ 4.2. Scalability Orders of Magnitude . . . . . . . . . . . . . 11
+ 4.2.1. Number of VPNs with Multicast Enabled . . . . . . . . 11
+ 4.2.2. Number of Multicast VPNs per PE . . . . . . . . . . . 12
+ 4.2.3. Number of CEs per Multicast VPN per PE . . . . . . . . 12
+ 4.2.4. PEs per Multicast VPN . . . . . . . . . . . . . . . . 12
+ 4.2.5. PEs with Multicast VRFs . . . . . . . . . . . . . . . 13
+ 4.2.6. Number of Streams Sourced . . . . . . . . . . . . . . 13
+ 5. Requirements for Supporting IP Multicast within L3 PPVPNs . . 13
+ 5.1. End User/Customer Standpoint . . . . . . . . . . . . . . . 13
+ 5.1.1. Service Definition . . . . . . . . . . . . . . . . . . 13
+ 5.1.2. CE-PE Multicast Routing and Group Management
+ Protocols . . . . . . . . . . . . . . . . . . . . . . 14
+ 5.1.3. Quality of Service (QoS) . . . . . . . . . . . . . . . 14
+ 5.1.4. Operations and Management . . . . . . . . . . . . . . 15
+ 5.1.5. Security Requirements . . . . . . . . . . . . . . . . 16
+ 5.1.6. Extranet . . . . . . . . . . . . . . . . . . . . . . . 17
+ 5.1.7. Internet Multicast . . . . . . . . . . . . . . . . . . 18
+ 5.1.8. Carrier's Carrier . . . . . . . . . . . . . . . . . . 18
+ 5.1.9. Multi-Homing, Load Balancing, and Resiliency . . . . . 19
+ 5.1.10. RP Engineering . . . . . . . . . . . . . . . . . . . . 19
+ 5.1.11. Addressing . . . . . . . . . . . . . . . . . . . . . . 20
+ 5.1.12. Minimum MTU . . . . . . . . . . . . . . . . . . . . . 20
+ 5.2. Service Provider Standpoint . . . . . . . . . . . . . . . 21
+ 5.2.1. General Requirement . . . . . . . . . . . . . . . . . 21
+ 5.2.2. Scalability . . . . . . . . . . . . . . . . . . . . . 21
+ 5.2.3. Resource Optimization . . . . . . . . . . . . . . . . 23
+ 5.2.4. Tunneling Requirements . . . . . . . . . . . . . . . . 24
+ 5.2.5. Control Mechanisms . . . . . . . . . . . . . . . . . . 26
+ 5.2.6. Support of Inter-AS, Inter-Provider Deployments . . . 26
+ 5.2.7. Quality-of-Service Differentiation . . . . . . . . . . 27
+ 5.2.8. Infrastructure security . . . . . . . . . . . . . . . 27
+ 5.2.9. Robustness . . . . . . . . . . . . . . . . . . . . . . 28
+
+
+
+Morin Informational [Page 2]
+
+RFC 4834 L3VPN Mcast Reqs April 2007
+
+
+ 5.2.10. Operation, Administration, and Maintenance . . . . . . 28
+ 5.2.11. Compatibility and Migration Issues . . . . . . . . . . 29
+ 5.2.12. Troubleshooting . . . . . . . . . . . . . . . . . . . 30
+ 6. Security Considerations . . . . . . . . . . . . . . . . . . . 30
+ 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 31
+ 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31
+ 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
+ 9.1. Normative References . . . . . . . . . . . . . . . . . . . 32
+ 9.2. Informative References . . . . . . . . . . . . . . . . . . 33
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Morin Informational [Page 3]
+
+RFC 4834 L3VPN Mcast Reqs April 2007
+
+
+1. Introduction
+
+ Virtual Private Network (VPN) services satisfying the requirements
+ defined in [RFC4031] are now being offered by many service providers
+ throughout the world. VPN services are popular because customers
+ need not be aware of the VPN technologies deployed in the provider
+ network. They scale well for the following reasons:
+
+ o because P routers (Provider Routers) need not be aware of VPN
+ service details
+
+ o because the addition of a new VPN member requires only limited
+ configuration effort
+
+ There is also a growing need for support of IP multicast-based
+ services. Efforts to provide efficient IP multicast routing
+ protocols and multicast group management have been made in
+ standardization bodies which has led, in particular, to the
+ definition of Protocol Independent Multicast (PIM) and Internet Group
+ Management Protocol (IGMP).
+
+ However, multicast traffic is not natively supported within existing
+ L3 PPVPN solutions. Deploying multicast over an L3VPN today, with
+ only currently standardized solutions, requires designing customized
+ solutions which will be inherently limited in terms of scalability,
+ operational efficiency, and bandwidth usage.
+
+ This document complements the generic L3VPN requirements [RFC4031]
+ document, by specifying additional requirements specific to the
+ deployment within PPVPNs of services based on IP multicast. It
+ clarifies the needs of both VPN clients and providers and formulates
+ the problems that should be addressed by technical solutions with the
+ key objective being to remain solution agnostic. There is no intent
+ in this document to specify either solution-specific details or
+ application-specific requirements. Also, this document does NOT aim
+ at expressing multicast-related requirements that are not specific to
+ L3 PPVPNs.
+
+ It is expected that solutions that specify procedures and protocol
+ extensions for multicast in L3 PPVPNs SHOULD satisfy these
+ requirements.
+
+
+
+
+
+
+
+
+
+
+Morin Informational [Page 4]
+
+RFC 4834 L3VPN Mcast Reqs April 2007
+
+
+2. Conventions Used in This Document
+
+2.1. Terminology
+
+ Although the reader is assumed to be familiar with the terminology
+ defined in [RFC4031], [RFC4364], [RFC4601], and [RFC4607], the
+ following glossary of terms may be worthwhile.
+
+ We also propose here generic terms for concepts that naturally appear
+ when multicast in VPNs is discussed.
+
+ ASM:
+ Any Source Multicast. One of the two multicast service models, in
+ which a terminal subscribes to a multicast group to receive data
+ sent to the group by any source.
+
+ Multicast-enabled VPN, multicast VPN, or mVPN:
+ A VPN that supports IP multicast capabilities, i.e., for which
+ some PE devices (if not all) are multicast-enabled and whose core
+ architecture supports multicast VPN routing and forwarding.
+
+ PPVPN:
+ Provider-Provisioned Virtual Private Network.
+
+ PE, CE:
+ "Provider Edge", "Customer Edge" (as defined in [RFC4026]). As
+ suggested in [RFC4026], we will use these notations to refer to
+ the equipments/routers/devices themselves. Thus, "PE" will refer
+ to the router on the provider's edge, which faces the "CE", the
+ router on the customer's edge.
+
+ VRF or VR:
+ By these terms, we refer to the entity defined in a PE dedicated
+ to a specific VPN instance. "VRF" refers to "VPN Routing and
+ Forwarding table" as defined in [RFC4364], and "VR" to "Virtual
+ Router" as defined in [VRs] terminology.
+
+ MDTunnel:
+ Multicast Distribution Tunnel. The means by which the customer's
+ multicast traffic will be transported across the SP network. This
+ is meant in a generic way: such tunnels can be either point-to-
+ point or point-to-multipoint. Although this definition may seem
+ to assume that distribution tunnels are unidirectional, the
+ wording also encompasses bidirectional tunnels.
+
+
+
+
+
+
+
+Morin Informational [Page 5]
+
+RFC 4834 L3VPN Mcast Reqs April 2007
+
+
+ S:
+ Denotes a multicast source.
+
+ G:
+ Denotes a multicast group.
+
+ Multicast channel:
+ In the multicast SSM model [RFC4607], a "multicast channel"
+ designates traffic from a specific source S to a multicast group
+ G. Also denominated as "(S,G)".
+
+ SP:
+ Service provider.
+
+ SSM:
+ Source Specific Multicast. One of the two multicast service
+ models, where a terminal subscribes to a multicast group to
+ receive data sent to the group by a specific source.
+
+ RP:
+ Rendezvous Point (Protocol Independent Multicast - Sparse Mode
+ (PIM-SM) [RFC4601]).
+
+ P2MP, MP2MP:
+ Designate "Point-to-Multipoint" and "Multipoint-to-Multipoint"
+ replication trees.
+
+ L3VPN, VPN:
+ Throughout this document, "L3VPN" or even just "VPN" will refer to
+ "Provider-Provisioned Layer 3 Virtual Private Network" (PP
+ L3VPNs), and will be preferred for readability.
+
+ Please refer to [RFC4026] for details about terminology specifically
+ relevant to VPN aspects, and to [RFC2432] for multicast performance
+ or quality of service (QoS)-related terms.
+
+2.2. Conventions
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in [RFC2119].
+
+
+
+
+
+
+
+
+
+
+Morin Informational [Page 6]
+
+RFC 4834 L3VPN Mcast Reqs April 2007
+
+
+3. Problem Statement
+
+3.1. Motivations
+
+ More and more L3VPN customers use IP multicast services within their
+ private infrastructures. Naturally, they want to extend these
+ multicast services to remote sites that are connected via a VPN.
+
+ For instance, the customer could be a national TV channel with
+ several geographical locations that wants to broadcast a TV program
+ from a central point to several regional locations within its VPN.
+
+ A solution to support multicast traffic could consist of point-to-
+ point tunnels across the provider network and requires the PEs
+ (Provider Edge routers) to replicate traffic. This would obviously
+ be sub-optimal as it would place the replication burden on the PE and
+ hence would have very poor scaling characteristics. It would also
+ probably waste bandwidth and control plane resources in the
+ provider's network.
+
+ Thus, to provide multicast services for L3VPN networks in an
+ efficient manner (that is, with a scalable impact on signaling and
+ protocol state as well as bandwidth usage), in a large-scale
+ environment, new mechanisms are required to enhance existing L3VPN
+ solutions for proper support of multicast-based services.
+
+3.2. General Requirements
+
+ This document sets out requirements for L3 provider-provisioned VPN
+ solutions designed to carry customers' multicast traffic. The main
+ requirement is that a solution SHOULD first satisfy the requirements
+ documented in [RFC4031]: as far as possible, a multicast service
+ should have the same characteristics as the unicast equivalent,
+ including the same simplicity (technology unaware), the same quality
+ of service (if any), the same management (e.g., performance
+ monitoring), etc.
+
+ Moreover, it also has to be clear that a multicast VPN solution MUST
+ interoperate seamlessly with current unicast VPN solutions. It would
+ also make sense that multicast VPN solutions define themselves as
+ extensions to existing L3 provider-provisioned VPN solutions (such as
+ for instance, [RFC4364] or [VRs]) and retain consistency with those,
+ although this is not a core requirement.
+
+ The requirements in this document are equally applicable to IPv4 and
+ IPv6, for both customer- and provider-related matters.
+
+
+
+
+
+Morin Informational [Page 7]
+
+RFC 4834 L3VPN Mcast Reqs April 2007
+
+
+3.3. Scaling vs. Optimizing Resource Utilization
+
+ When transporting multicast VPN traffic over a service provider
+ network, there intrinsically is tension between scalability and
+ resource optimization, since the latter is likely to require the
+ maintenance of control plane states related to replication trees in
+ the core network [RFC3353].
+
+ Consequently, any deployment will require a trade-off to be made.
+ This document will express some requirements related to this trade-
+ off.
+
+4. Use Cases
+
+ The goal of this section is to highlight how different applications
+ and network contexts may have a different impact on how a multicast
+ VPN solution is designed, deployed, and tuned. For this purpose, we
+ describe some typical use case scenarios and express expectations in
+ terms of deployment orders of magnitude.
+
+ Most of the content of these sections originates from a survey done
+ in summer 2005, among institutions and providers that expect to
+ deploy such solutions. The full survey text and raw results (13
+ responses) were published separately, and we only present here the
+ most relevant facts and expectations that the survey exposed.
+
+ For scalability figures, we considered that it was relevant to
+ highlight the highest expectations, those that are expected to have
+ the greatest impact on solution design. For balance, we do also
+ mention cases where such high expectations were expressed in only a
+ few answers.
+
+4.1. Scenarios
+
+ We don't provide here an exhaustive set of scenarios that a multicast
+ VPN solution is expected to support -- no solution should restrict
+ the scope of multicast applications and deployments that can be done
+ over a multicast VPN.
+
+ Hence, we only give here a short list of scenarios that are expected
+ to have a large impact on the design of a multicast VPN solution.
+
+
+
+
+
+
+
+
+
+
+Morin Informational [Page 8]
+
+RFC 4834 L3VPN Mcast Reqs April 2007
+
+
+4.1.1. Live Content Broadcast
+
+ Under this label, we group all applications that distribute content
+ (audio, video, or other content) with the property that this content
+ is expected to be consulted at once ("live") by the receiver.
+ Typical applications are broadcast TV, production studio
+ connectivity, and distribution of market data feeds.
+
+ The characteristics of such applications are the following:
+
+ o one or few sources to many receivers
+
+ o sources are often in known locations; receivers are in less
+ predictable locations (this latter point may depend on
+ applications)
+
+ o in some cases, it is expected that the regularity of audience
+ patterns may help improve how the bandwidth/state trade-off is
+ handled
+
+ o the number of streams can be as high as hundreds, or even
+ thousands, of streams
+
+ o bandwidth will depend on the application, but may vary between a
+ few tens/hundreds of Kb/s (e.g., audio or low-quality video media)
+ and tens of Mb/s (high-quality video), with some demanding
+ professional applications requiring as much as hundreds of Mb/s.
+
+ o QoS requirements include, in many cases, a low multicast group
+ join delay
+
+ o QoS of these applications is likely to be impacted by packet loss
+ (some applications may be robust to low packet loss) and to have
+ low robustness against jitter
+
+ o delay sensitivity will depend on the application: some
+ applications are not so delay sensitive (e.g., broadcast TV),
+ whereas others may require very low delay (professional studio
+ applications)
+
+ o some of these applications may involve rapid changes in customer
+ multicast memberships as seen by the PE, but this will depend on
+ audience patterns and on the amount of provider equipments
+ deployed close to VPN customers
+
+
+
+
+
+
+
+Morin Informational [Page 9]
+
+RFC 4834 L3VPN Mcast Reqs April 2007
+
+
+4.1.2. Symmetric Applications
+
+ Some use cases exposed by the survey can be grouped under this label,
+ and include many-to-many applications such as conferencing and server
+ cluster monitoring.
+
+ They are characterized by the relatively high number of streams that
+ they can produce, which has a direct impact on scalability
+ expectations.
+
+ A sub-case of this scenario is the case of symmetric applications
+ with small groups, when the number of receivers is low compared to
+ the number of sites in the VPNs (e.g., video conferencing and
+ e-learning applications).
+
+ This latter case is expected to be an important input to solution
+ design, since it may significantly impact how the bandwidth/state is
+ managed.
+
+ Optimizing bandwidth may require introducing dedicated states in the
+ core network (typically as much as the number of groups) for the
+ following reasons:
+
+ o small groups, and low predictability of the location of
+ participants ("sparse groups")
+
+ o possibly significantly high bandwidth (a few Mb/s per participant)
+
+ Lastly, some of these applications may involve real-time interactions
+ and will be highly sensitive to packet loss, jitter, and delay.
+
+4.1.3. Data Distribution
+
+ Some applications that are expected to be deployed on multicast VPNs
+ are non-real-time applications aimed at distributing data from few
+ sources to many receivers.
+
+ Such applications may be considered to have lower expectations than
+ their counterparts proposed in this document, since they would not
+ necessarily involve more data streams and are more likely to adapt to
+ the available bandwidth and to be robust to packet loss, jitter, and
+ delay.
+
+ One important property is that such applications may involve higher
+ bandwidths (hundreds of Mb/s).
+
+
+
+
+
+
+Morin Informational [Page 10]
+
+RFC 4834 L3VPN Mcast Reqs April 2007
+
+
+4.1.4. Generic Multicast VPN Offer
+
+ This ISP scenario is a deployment scenario where IP-multicast
+ connectivity is proposed for every VPN: if a customer requests a VPN,
+ then this VPN will support IP multicast by default. In this case,
+ the number of multicast VPNs equals the number of VPNs. This implies
+ a quite important scalability requirement (e.g., hundreds of PEs,
+ hundreds of VPNs per PE, with a potential increase by one order of
+ magnitude in the future).
+
+ The per-mVPN traffic behavior is not predictable because how the
+ service is used is completely up to the customer. This results in a
+ traffic mix of the scenarios mentioned in Section 4.1. QoS
+ requirements are similar to typical unicast scenarios, with the need
+ for different classes. Also, in such a context, a reasonably large
+ range of protocols should be made available to the customer for use
+ at the PE-CE level.
+
+ Also, in such a scenario, customers may want to deploy multicast
+ connectivity between two or more multicast VPNs as well as access to
+ Internet Multicast.
+
+4.2. Scalability Orders of Magnitude
+
+ This section proposes orders of magnitude for different scalability
+ metrics relevant for multicast VPN issues. It should be noted that
+ the scalability figures proposed here relate to scalability
+ expectations of future deployments of multicast VPN solutions, as the
+ authors chose to not restrict the scope to only currently known
+ deployments.
+
+4.2.1. Number of VPNs with Multicast Enabled
+
+ From the survey results, we see a broad range of expectations. There
+ are extreme answers: from 5 VPNs (1 answer) to 10k VPNs (1 answer),
+ but more typical answers are split between the low range of tens of
+ VPNs (7 answers) and the higher range of hundreds or thousands of
+ VPNs (2 + 4 answers).
+
+ A solution SHOULD support a number of multicast VPNs ranging from one
+ to several thousands.
+
+ A solution SHOULD NOT limit the proportion of multicast VPNs among
+ all (unicast) VPNs.
+
+
+
+
+
+
+
+Morin Informational [Page 11]
+
+RFC 4834 L3VPN Mcast Reqs April 2007
+
+
+4.2.2. Number of Multicast VPNs per PE
+
+ The majority of survey answers express a number of multicast VPNs per
+ PE of around tens (8 responses between 5 and 50); a significant
+ number of them (4) expect deployments with hundreds or thousands (1
+ response) of multicast VPNs per PE.
+
+ A solution SHOULD support a number of multicast VPNs per PE of
+ several hundreds, and may have to scale up to thousands of VPNs per
+ PE.
+
+4.2.3. Number of CEs per Multicast VPN per PE
+
+ Survey responses span from 1 to 2000 CEs per multicast VPN per PE.
+ Most typical responses are between tens (6 answers) and hundreds (4
+ responses).
+
+ A solution SHOULD support a number of CEs per multicast VPN per PE
+ going up to several hundreds (and may target the support of thousands
+ of CEs).
+
+4.2.4. PEs per Multicast VPN
+
+ People who answered the survey typically expect deployments with the
+ number of PEs per multicast VPN in the range of hundreds of PEs (6
+ responses) or tens of PEs (4 responses). Two responses were in the
+ range of thousands (one mentioned a 10k figure).
+
+ A multicast VPN solution SHOULD support several hundreds of PEs per
+ multicast VPN, and MAY usefully scale up to thousands.
+
+4.2.4.1. ... with Sources
+
+ The number of PEs (per VPN) that would be connected to sources seems
+ to be significantly lower than the number of PEs per VPN. This is
+ obviously related to the fact that many respondents mentioned
+ deployments related to content broadcast applications (one to many).
+
+ Typical numbers are tens (6 responses) or hundreds (4 responses) of
+ source-connected PEs. One respondent expected a higher number of
+ several thousands.
+
+ A solution SHOULD support hundreds of source-connected PEs per VPN,
+ and some deployment scenarios involving many-to-many applications may
+ require supporting a number of source-connected PEs equal to the
+ number of PEs (hundreds or thousands).
+
+
+
+
+
+Morin Informational [Page 12]
+
+RFC 4834 L3VPN Mcast Reqs April 2007
+
+
+4.2.4.2. ... with Receivers
+
+ The survey showed that the number of PEs with receivers is expected
+ to be of the same order of magnitude as the number of PEs in a
+ multicast VPN. This is consistent with the intrinsic nature of most
+ multicast applications, which have few source-only participants.
+
+4.2.5. PEs with Multicast VRFs
+
+ A solution SHOULD scale up to thousands of PEs having multicast
+ service enabled.
+
+4.2.6. Number of Streams Sourced
+
+ Survey responses led us to retain the following orders of magnitude
+ for the number of streams that a solution SHOULD support:
+
+ per VPN: hundreds or thousands of streams
+
+ per PE: hundreds of streams
+
+5. Requirements for Supporting IP Multicast within L3 PPVPNs
+
+ Again, the aim of this document is not to specify solutions but to
+ give requirements for supporting IP multicast within L3 PPVPNs.
+
+ In order to list these requirements, we have taken the standpoint of
+ two different important entities: the end user (the customer using
+ the VPN) and the service provider.
+
+ In the rest of the document, by "a solution" or "a multicast VPN
+ solution", we mean a solution that allows multicast in an L3
+ provider-provisioned VPN, and which addresses the requirements listed
+ in this document.
+
+5.1. End User/Customer Standpoint
+
+5.1.1. Service Definition
+
+ As for unicast, the multicast service MUST be provider provisioned
+ and SHALL NOT require customer devices (CEs) to support any extra
+ features compared to those required for multicast in a non-VPN
+ context. Enabling a VPN for multicast support SHOULD be possible
+ with no impact (or very limited impact) on existing multicast
+ protocols possibly already deployed on the CE devices.
+
+
+
+
+
+
+Morin Informational [Page 13]
+
+RFC 4834 L3VPN Mcast Reqs April 2007
+
+
+5.1.2. CE-PE Multicast Routing and Group Management Protocols
+
+ Consequently to Section 5.1.1, multicast-related protocol exchanges
+ between a CE and its directly connected PE SHOULD happen via existing
+ multicast protocols.
+
+ Such protocols include: PIM-SM [RFC4601], bidirectional-PIM
+ [BIDIR-PIM], PIM - Dense Mode (DM) [RFC3973], and IGMPv3 [RFC3376]
+ (this version implicitly supports hosts that only implement IGMPv1
+ [RFC1112] or IGMPv2 [RFC2236]).
+
+ Among those protocols, the support of PIM-SM (which includes the SSM
+ model) and either IGMPv3 (for IPv4 solutions) and/or Multicast
+ Listener Discovery Version 2 (MLDv2) [RFC3810] (for IPv6 solutions)
+ is REQUIRED. Bidir-PIM support at the PE-CE interface is
+ RECOMMENDED. And considering deployments, PIM-DM is considered
+ OPTIONAL.
+
+ When a multicast VPN solution is built on a VPN solution supporting
+ IPv6 unicast, it MUST also support v6 variants of the above
+ protocols, including MLDv2, and PIM-SM IPv6-specific procedures. For
+ a multicast VPN solution built on a unicast VPN solution supporting
+ only IPv4, it is RECOMMENDED that the design favors the definition of
+ procedures and encodings that will provide an easy adaptation to
+ IPv6.
+
+5.1.3. Quality of Service (QoS)
+
+ Firstly, general considerations regarding QoS in L3VPNs expressed in
+ Section 5.5 of [RFC4031] are also relevant to this section.
+
+ QoS is measured in terms of delay, jitter, packet loss, and
+ availability. These metrics are already defined for the current
+ unicast PPVPN services and are included in Service Level Agreements
+ (SLAs). In some cases, the agreed SLA may be different between
+ unicast and multicast, and that will require differentiation
+ mechanisms in order to monitor both SLAs.
+
+ The level of availability for the multicast service SHOULD be on par
+ with what exists for unicast traffic. For instance, comparable
+ traffic protection mechanisms SHOULD be available for customer
+ multicast traffic when it is carried over the service provider's
+ network.
+
+ A multicast VPN solution SHALL allow a service provider to define at
+ least the same level of quality of service as exists for unicast, and
+ as exists for multicast in a non-VPN context. From this perspective,
+ the deployment of multicast-based services within an L3VPN
+
+
+
+Morin Informational [Page 14]
+
+RFC 4834 L3VPN Mcast Reqs April 2007
+
+
+ environment SHALL benefit from Diffserv [RFC2475] mechanisms that
+ include multicast traffic identification, classification, and marking
+ capabilities, as well as multicast traffic policing, scheduling, and
+ conditioning capabilities. Such capabilities MUST therefore be
+ supported by any participating device in the establishment and the
+ maintenance of the multicast distribution tunnel within the VPN.
+
+ As multicast is often used to deliver high-quality services such as
+ TV broadcast, a multicast VPN solution MAY provide additional
+ features to support high QoS such as bandwidth reservation and
+ admission control.
+
+ Also, considering that multicast reception is receiver-triggered,
+ group join delay (as defined in [RFC2432]) is also considered one
+ important QoS parameter. It is thus RECOMMENDED that a multicast VPN
+ solution be designed appropriately in this regard.
+
+ The group leave delay (as defined in [RFC2432]) may also be important
+ on the CE-PE link for some usage scenarios: in cases where the
+ typical bandwidth of multicast streams is close to the bandwidth of a
+ PE-CE link, it will be important to have the ability to stop the
+ emission of a stream on the PE-CE link as soon as it stops being
+ requested by the CE, to allow for fast switching between two
+ different high-throughput multicast streams. This implies that it
+ SHOULD be possible to tune the multicast routing or group management
+ protocols (e.g., IGMP/MLD or PIM) used on the PE-CE adjacency to
+ reduce the group leave delay to the minimum.
+
+ Lastly, a multicast VPN solution SHOULD as much as possible ensure
+ that client multicast traffic packets are neither lost nor
+ duplicated, even when changes occur in the way a client multicast
+ data stream is carried over the provider network. Packet loss issues
+ also have to be considered when a new source starts to send traffic
+ to a group: any receiver interested in receiving such traffic SHOULD
+ be serviced accordingly.
+
+5.1.4. Operations and Management
+
+ The requirements and definitions for operations and management (OAM)
+ of L3VPNs that are defined in [RFC4176] equally apply to multicast,
+ and are not extensively repeated in this document. This sub-section
+ mentions the most important guidelines and details points of
+ particular relevance in the context of multicast in L3VPNs.
+
+ A multicast VPN solution SHOULD allow a multicast VPN customer to
+ manage the capabilities and characteristics of their multicast VPN
+ services.
+
+
+
+
+Morin Informational [Page 15]
+
+RFC 4834 L3VPN Mcast Reqs April 2007
+
+
+ A multicast VPN solution MUST support SLA monitoring capabilities,
+ which SHOULD rely upon techniques similar to those used for the
+ unicast service for the same monitoring purposes. Multicast SLA-
+ related metrics SHOULD be available through means similar to the ones
+ already used for unicast-related monitoring, such as Simple Network
+ Management Protocol (SNMP) [RFC3411] or IPFIX [IPFIX-PROT].
+
+ Multicast-specific characteristics that may be monitored include:
+ multicast statistics per stream, end-to-end delay, and group join/
+ leave delay (time to start/stop receiving a multicast group's traffic
+ across the VPN, as defined in [RFC2432], Section 3).
+
+ The monitoring of multicast-specific parameters and statistics MUST
+ include multicast traffic statistics: total/incoming/outgoing/dropped
+ traffic, by period of time. It MAY include IP Performance Metrics
+ related information (IPPM, [RFC2330]) that is relevant to the
+ multicast traffic usage: such information includes the one-way packet
+ delay, the inter-packet delay variation, etc. See [MULTIMETRICS].
+
+ A generic discussion of SLAs is provided in [RFC3809].
+
+ Apart from statistics on multicast traffic, customers of a multicast
+ VPN will need information concerning the status of their multicast
+ resource usage (multicast routing states and bandwidth). Indeed, as
+ mentioned in Section 5.2.5, for scalability purposes, a service
+ provider may limit the number (and/or throughput) of multicast
+ streams that are received/sent to/from a client site. In such a
+ case, a multicast VPN solution SHOULD allow customers to find out
+ their current resource usage (multicast routing states and
+ throughput), and to receive some kind of feedback if their usage
+ exceeds the agreed bounds. Whether this issue will be better handled
+ at the protocol level at the PE-CE interface or at the Service
+ Management Level interface [RFC4176] is left for further discussion.
+
+ It is RECOMMENDED that any OAM mechanism designed to trigger alarms
+ in relation to performance or resource usage metrics integrate the
+ ability to limit the rate at which such alarms are generated (e.g.,
+ some form of a hysteresis mechanism based on low/high thresholds
+ defined for the metrics).
+
+5.1.5. Security Requirements
+
+ Security is a key point for a customer who uses a VPN service. For
+ instance, the [RFC4364] model offers some guarantees concerning the
+ security level of data transmission within the VPN.
+
+ A multicast VPN solution MUST provide an architecture with the same
+ level of security for both unicast and multicast traffic.
+
+
+
+Morin Informational [Page 16]
+
+RFC 4834 L3VPN Mcast Reqs April 2007
+
+
+ Moreover, the activation of multicast features SHOULD be possible:
+
+ o per VRF / per VR
+
+ o per CE interface (when multiple CEs of a VPN are connected to a
+ common VRF/VR)
+
+ o per multicast group and/or per channel
+
+ o with a distinction between multicast reception and emission
+
+ A multicast VPN solution may choose to make the optimality/
+ scalability trade-off stated in Section 3.3 by sometimes distributing
+ multicast traffic of a client group to a larger set of PE routers
+ that may include PEs that are not part of the VPN. From a security
+ standpoint, this may be a problem for some VPN customers; thus, a
+ multicast VPN solution using such a scheme MAY offer ways to avoid
+ this for specific customers (and/or specific customer multicast
+ streams).
+
+5.1.6. Extranet
+
+ In current PP L3VPN models, a customer site may be set up to be part
+ of multiple VPNs, and this should still be possible when a VPN is
+ multicast-enabled. In practice, it means that a VRF or VR can be
+ part of more than one VPN.
+
+ A multicast VPN solution MUST support such deployments.
+
+ For instance, it must be possible to configure a VRF so that an
+ enterprise site participating in a BGP/MPLS multicast-enabled VPN and
+ connected to that VRF can receive a multicast stream from (or
+ originate a multicast stream towards) another VPN that would be
+ associated to that VRF.
+
+ This means that a multicast VPN solution MUST offer means for a VRF
+ to be configured so that multicast connectivity can be set up for a
+ chosen set of extranet VPNs. More precisely, it MUST be possible to
+ configure a VRF so that:
+
+ o receivers behind attached CEs can receive multicast traffic
+ sourced in the configured set of extranet VPNs
+
+ o sources behind attached CEs can reach multicast traffic receivers
+ located in the configured set of extranet VPNs
+
+ o multicast reception and emission can be independently enabled for
+ each of the extranet VPNs
+
+
+
+Morin Informational [Page 17]
+
+RFC 4834 L3VPN Mcast Reqs April 2007
+
+
+ Moreover, a solution MUST allow service providers to control an
+ extranet's multicast connectivity independently from the extranet's
+ unicast connectivity. More specifically:
+
+ o enabling unicast connectivity to another VPN MUST be possible
+ without activating multicast connectivity with that VPN
+
+ o enabling multicast connectivity with another VPN SHOULD NOT
+ require more than the strict minimal unicast routing. Sending
+ multicast to a VPN SHOULD NOT require having unicast routes to
+ that VPN; receiving multicast from a VPN SHOULD be possible with
+ nothing more than unicast routes to the relevant multicast sources
+ of that VPN
+
+ o when unicast routes from another VPN are imported into a VR/VRF,
+ for multicast Reverse Path Forwarding (RPF) resolution, this
+ SHOULD be possible without making those routes available for
+ unicast routing
+
+ Proper support for this feature SHOULD NOT require replicating
+ multicast traffic on a PE-CE link, whether it is a physical or
+ logical link.
+
+5.1.7. Internet Multicast
+
+ Connectivity with Internet Multicast is a particular case of the
+ previous section, where sites attached to a VR/VRF would need to
+ receive/send multicast traffic from/to the Internet.
+
+ This should be considered OPTIONAL given the additional
+ considerations, such as security, needed to fulfill the requirements
+ for providing Internet Multicast.
+
+5.1.8. Carrier's Carrier
+
+ Many L3 PPVPN solutions, such as [RFC4364] and [VRs], define the
+ "Carrier's Carrier" model, where a "carrier's carrier" service
+ provider supports one or more customer ISPs, or "sub-carriers". A
+ multicast VPN solution SHOULD support the carrier's carrier model in
+ a scalable and efficient manner.
+
+ Ideally, the range of tunneling protocols available for the sub-
+ carrier ISP should be the same as those available for the carrier's
+ carrier ISP. This implies that the protocols that may be used at the
+ PE-CE level SHOULD NOT be restricted to protocols required as per
+ Section 5.1.2 and SHOULD include some of the protocols listed in
+ Section 5.2.4, such as for instance P2MP MPLS signaling protocols.
+
+
+
+
+Morin Informational [Page 18]
+
+RFC 4834 L3VPN Mcast Reqs April 2007
+
+
+ In the context of MPLS-based L3VPN deployments, such as BGP/MPLS VPNs
+ [RFC4364], this means that MPLS label distribution SHOULD happen at
+ the PE-CE level, giving the ability to the sub-carrier to use
+ multipoint LSPs as a tunneling mechanism.
+
+5.1.9. Multi-Homing, Load Balancing, and Resiliency
+
+ A multicast VPN solution SHOULD be compatible with current solutions
+ that aim at improving the service robustness for customers such as
+ multi-homing, CE-PE link load balancing, and fail-over. A multicast
+ VPN solution SHOULD also be able to offer those same features for
+ multicast traffic.
+
+ Any solution SHOULD support redundant topology of CE-PE links. It
+ SHOULD minimize multicast traffic disruption and fail-over.
+
+5.1.10. RP Engineering
+
+ When PIM-SM (or bidir-PIM) is used in ASM mode on the VPN customer
+ side, the RP function (or RP-address in the case of bidir-PIM) has to
+ be associated to a node running PIM, and configured on this node.
+
+5.1.10.1. RP Outsourcing
+
+ In the case of PIM-SM in ASM mode, engineering of the RP function
+ requires the deployment of specific protocols and associated
+ configurations. A service provider may offer to manage customers'
+ multicast protocol operation on their behalf. This implies that it
+ is necessary to consider cases where a customer's RPs are outsourced
+ (e.g., on PEs). Consequently, a VPN solution MAY support the hosting
+ of the RP function in a VR or VRF.
+
+5.1.10.2. RP Availability
+
+ Availability of the RP function (or address) is required for proper
+ operation of PIM-SM (ASM mode) and bidir-PIM. Loss of connectivity
+ to the RP from a receiver or source will impact the multicast
+ service. For this reason, different mechanisms exist, such as BSR
+ [PIM-BSR] or anycast-RP (Multicast Source Discovery Protocol (MSDP)-
+ based [RFC3446] or PIM-based [RFC4610]).
+
+ These protocols and procedures SHOULD work transparently through a
+ multicast VPN, and MAY if relevant, be implemented in a VRF/VR.
+
+ Moreover, a multicast VPN solution MAY improve the robustness of the
+ ASM multicast service regarding loss of connectivity to the RP, by
+ providing specific features that help:
+
+
+
+
+Morin Informational [Page 19]
+
+RFC 4834 L3VPN Mcast Reqs April 2007
+
+
+ a) maintain ASM multicast service among all the sites within an MVPN
+ that maintain connectivity among themselves, even when the site(s)
+ hosting the RP lose their connectivity to the MVPN
+
+ b) maintain ASM multicast service within any site that loses
+ connectivity to the service provider
+
+5.1.10.3. RP Location
+
+ In the case of PIM-SM, when a source starts to emit traffic toward a
+ group (in ASM mode), if sources and receivers are located in VPN
+ sites that are different than that of the RP, then traffic may
+ transiently flow twice through the SP network and the CE-PE link of
+ the RP (from source to RP, and then from RP to receivers). This
+ traffic peak, even short, may not be convenient depending on the
+ traffic and link bandwidth.
+
+ Thus, a VPN solution MAY provide features that solve or help mitigate
+ this potential issue.
+
+5.1.11. Addressing
+
+ A multicast provider-provisioned L3VPN SHOULD NOT impose restrictions
+ on multicast group addresses used by VPN customers.
+
+ In particular, like unicast traffic, an overlap of multicast group
+ address sets used by different VPN customers MUST be supported.
+
+ The use of globally unique means of multicast-based service
+ identification at the scale of the domain where such services are
+ provided SHOULD be recommended. For IPv4 multicast, this implies the
+ use of the multicast administratively scoped range (239/8 as defined
+ by [RFC2365]) for services that are to be used only inside the VPN,
+ and of either SSM-range addresses (232/8 as defined by [RFC4607]) or
+ globally assigned group addresses (e.g., GLOP [RFC3180], 233/8) for
+ services for which traffic may be transmitted outside the VPN.
+
+5.1.12. Minimum MTU
+
+ For customers, it is often a serious issue whether or not transmitted
+ packets will be fragmented. In particular, some multicast
+ applications might have different requirements than those that make
+ use of unicast, and they may expect services that guarantee available
+ packet length not to be fragmented.
+
+ Therefore, a multicast VPN solution SHOULD be designed with these
+ considerations in mind. In practice:
+
+
+
+
+Morin Informational [Page 20]
+
+RFC 4834 L3VPN Mcast Reqs April 2007
+
+
+ o the encapsulation overhead of a multicast VPN solution SHOULD be
+ minimized, so that customer devices can be free of fragmentation
+ and reassembly activity as much as possible
+
+ o a multicast VPN solution SHOULD enable the service provider to
+ commit to a minimum path MTU usable by multicast VPN customers
+
+ o a multicast VPN solution SHOULD be compatible with path MTU
+ discovery mechanisms (see [RFC1191] and [RFC4459]), and particular
+ care SHOULD be given to means to help troubleshoot MTU issues
+
+ Moreover, since Ethernet LAN segments are often located at first and
+ last hops, a multicast VPN solution SHOULD be designed to allow for a
+ minimum 1500-byte IP MTU for VPN customers multicast packet, when the
+ provider backbone design allows it.
+
+5.2. Service Provider Standpoint
+
+ Note: To avoid repetition and confusion with terms used in solution
+ specifications, we introduced in Section 2.1 the term MDTunnel (for
+ Multicast Distribution Tunnel), which designates the data plane means
+ used by the service provider to forward customer multicast traffic
+ over the core network.
+
+5.2.1. General Requirement
+
+ The deployment of a multicast VPN solution SHOULD be possible with no
+ (or very limited) impact on existing deployments of standardized
+ multicast-related protocols on P and PE routers.
+
+5.2.2. Scalability
+
+ Some currently standardized and deployed L3VPN solutions have the
+ major advantage of being scalable in the core regarding the number of
+ customers and the number of customer routes. For instance, in the
+ [RFC4364] and Virtual Router [VRs] models, a P router sees a number
+ of MPLS tunnels that is only linked to the number of PEs and not to
+ the number of VPNs, or customer sites.
+
+ As far as possible, this independence in the core, with respect to
+ the number of customers and to customer activity, is recommended.
+ Yet, it is recognized that in our context scalability and resource
+ usage optimality are competing goals, so this requirement may be
+ reduced to giving the possibility of bounding the quantity of states
+ that the service provider needs to maintain in the core for
+ MDTunnels, with a bound being independent of the multicast activity
+ of VPN customers.
+
+
+
+
+Morin Informational [Page 21]
+
+RFC 4834 L3VPN Mcast Reqs April 2007
+
+
+ It is expected that multicast VPN solutions will use some kind of
+ point-to-multipoint technology to efficiently carry multicast VPN
+ traffic, and because such technologies require maintaining state
+ information, this will use resources in the control plane of P and PE
+ routers (memory and processing, and possibly address space).
+
+ Scalability is a key requirement for multicast VPN solutions.
+ Solutions MUST be designed to scale well with an increase in any of
+ the following:
+
+ o the number of PEs
+
+ o the number of customer VPNs (total and per PE)
+
+ o the number of PEs and sites in any VPN
+
+ o the number of client multicast channels (groups or source-groups)
+
+ Please consult Section 4.2 for typical orders of magnitude up to
+ which a multicast VPN solution is expected to scale.
+
+ Scalability of both performance and operation MUST be considered.
+
+ Key considerations SHOULD include:
+
+ o the processing resources required by the control plane
+ (neighborhood or session maintenance messages, keep-alives,
+ timers, etc.)
+
+ o the memory resources needed for the control plane
+
+ o the amount of protocol information transmitted to manage a
+ multicast VPN (e.g., signaling throughput)
+
+ o the amount of control plane processing required on PE and P
+ routers to add or remove a customer site (or a customer from a
+ multicast session)
+
+ o the number of multicast IP addresses used (if IP multicast in ASM
+ mode is proposed as a multicast distribution tunnel)
+
+ o other particular elements inherent to each solution that impact
+ scalability (e.g., if a solution uses some distribution tree
+ inside the core, topology of the tree and number of leaf nodes may
+ be some of them)
+
+ It is expected that the applicability of each solution will be
+ evaluated with regards to the aforementioned scalability criteria.
+
+
+
+Morin Informational [Page 22]
+
+RFC 4834 L3VPN Mcast Reqs April 2007
+
+
+ These considerations naturally lead us to believe that proposed
+ solutions SHOULD offer the possibility of sharing such resources
+ between different multicast streams (between different VPNs, between
+ different multicast streams of the same or of different VPNs). This
+ means, for instance, if MDTunnels are trees, being able to share an
+ MDTunnel between several customers.
+
+ Those scalability issues are expected to be more significant on P
+ routers, but a multicast VPN solution SHOULD address both P and PE
+ routers as far as scalability is concerned.
+
+5.2.3. Resource Optimization
+
+5.2.3.1. General Goals
+
+ One of the aims of the use of multicast instead of unicast is
+ resource optimization in the network.
+
+ The two obvious suboptimal behaviors that a multicast VPN solution
+ would want to avoid are needless duplication (when the same data
+ travels twice or more on a link, e.g., when doing ingress PE
+ replication) and needless reception (e.g., a PE receiving traffic
+ that it does not need because there are no downstream receivers).
+
+5.2.3.2. Trade-off and Tuning
+
+ As previously stated in this document, designing a scalable solution
+ that makes an optimal use of resources is considered difficult.
+ Thus, what is expected from a multicast VPN solution is that it
+ addresses the resource optimization issue while taking into account
+ the fact that some trade-off has to be made.
+
+ Moreover, it seems that a "one size fits all" trade-off probably does
+ not exist either. Thus, a multicast VPN solution SHOULD offer
+ service providers appropriate configuration settings that let them
+ tune the trade-off according to their particular constraints (network
+ topology, platforms, customer applications, level of service offered
+ etc.).
+
+ As an illustration, here are some example bounds of the trade-off
+ space:
+
+
+
+
+
+
+
+
+
+
+Morin Informational [Page 23]
+
+RFC 4834 L3VPN Mcast Reqs April 2007
+
+
+ Bandwidth optimization: setting up optimized core MDTunnels whose
+ topology (PIM or P2MP LSP trees, etc.) precisely follows a
+ customer's multicast routing changes. This requires managing a
+ large amount of state in the core, and also quick reactions of the
+ core to customer multicast routing changes. This approach can be
+ advantageous in terms of bandwidth, but it is poor in terms of
+ state management.
+
+ State optimization: setting up MDTunnels that aggregate multiple
+ customer multicast streams (all or some of them, across different
+ VPNs or not). This will have better scalability properties, but
+ at the expense of bandwidth since some MDTunnel leaves will very
+ likely receive traffic they don't need, and because increased
+ constraints will make it harder to find optimal MDTunnels.
+
+5.2.3.3. Traffic Engineering
+
+ If the VPN service provides traffic engineering (TE) features for the
+ connection used between PEs for unicast traffic in the VPN service,
+ the solution SHOULD provide equivalent features for multicast
+ traffic.
+
+ A solution SHOULD offer means to support key TE objectives as defined
+ in [RFC3272], for the multicast service.
+
+ A solution MAY also usefully support means to address multicast-
+ specific traffic engineering issues: it is known that bandwidth
+ resource optimization in the point-to-multipoint case is an NP-hard
+ problem, and that techniques used for unicast TE may not be
+ applicable to multicast traffic.
+
+ Also, it has been identified that managing the trade-off between
+ resource usage and scalability may incur uselessly sending traffic to
+ some PEs participating in a multicast VPN. For this reason, a
+ multicast VPN solution MAY permit that the bandwidth/state tuning
+ take into account the relative cost or availability of bandwidth
+ toward each PE.
+
+5.2.4. Tunneling Requirements
+
+5.2.4.1. Tunneling Technologies
+
+ Following the principle of separation between the control plane and
+ the forwarding plane, a multicast VPN solution SHOULD be designed so
+ that control and forwarding planes are not interdependent: the
+ control plane SHALL NOT depend on which forwarding plane is used (and
+ vice versa), and the choice of forwarding plane SHOULD NOT be limited
+
+
+
+
+Morin Informational [Page 24]
+
+RFC 4834 L3VPN Mcast Reqs April 2007
+
+
+ by the design of the solution. Also, the solution SHOULD NOT be tied
+ to a specific tunneling technology.
+
+ In a multicast VPN solution extending a unicast L3 PPVPN solution,
+ consistency in the tunneling technology has to be favored: such a
+ solution SHOULD allow the use of the same tunneling technology for
+ multicast as for unicast. Deployment consistency, ease of operation,
+ and potential migrations are the main motivations behind this
+ requirement.
+
+ For MDTunnels, a solution SHOULD be able to use a range of tunneling
+ technologies, including point-to-point and point-to-multipoint, such
+ as:
+
+ o Generic Routing Encapsulation (GRE) [RFC2784] (including GRE in
+ multicast IP trees),
+
+ o MPLS [RFC3031] (including P2P or MP2P tunnels, and multipoint
+ tunnels signaled with MPLS P2MP extensions to the Resource
+ Reservation Protocol (RSVP) [P2MP-RSVP-TE] or Label Distribution
+ Protocol (LDP) [P2MP-LDP-REQS] [P2MP-LDP]),
+
+ o Layer-2 Tunneling Protocol (L2TP) (including L2TP for multicast
+ [RFC4045]),
+
+ o IPsec [RFC4031]
+
+ o IP-in-IP [RFC2003], etc.
+
+ Naturally, it is RECOMMENDED that a solution is built so that it can
+ leverage the point-to-multipoint variants of these techniques. These
+ variants allow for packet replications to happen along a tree in the
+ provider core network, and they may help improve bandwidth efficiency
+ in a multicast VPN context.
+
+5.2.4.2. MTU and Fragmentation
+
+ A solution SHOULD support a method that provides the minimum MTU of
+ the MDTunnel (e.g., to discover MTU, to communicate MTU via
+ signaling, etc.) so that:
+
+ o fragmentation inside the MDTunnel does not happen, even when
+ allowed by the underlying tunneling technology
+
+ o proper troubleshooting can be performed if packets that are too
+ big for the MDTunnel happen to be encapsulated in the MDTunnel
+
+
+
+
+
+Morin Informational [Page 25]
+
+RFC 4834 L3VPN Mcast Reqs April 2007
+
+
+5.2.5. Control Mechanisms
+
+ The solution MUST provide some mechanisms to control the sources
+ within a VPN. This control includes the number of sources that are
+ entitled to send traffic on the VPN, and/or the total bit rate of all
+ the sources.
+
+ At the reception level, the solution MUST also provide mechanisms to
+ control the number of multicast groups or channels VPN users are
+ entitled to subscribe to and/or the total bit rate represented by the
+ corresponding multicast traffic.
+
+ All these mechanisms MUST be configurable by the service provider in
+ order to control the amount of multicast traffic and state within a
+ VPN.
+
+ Moreover, it MAY be desirable to be able to impose some bound on the
+ quantity of state used by a VPN in the core network for its multicast
+ traffic, whether on each P or PE router, or globally. The motivation
+ is that it may be needed to avoid out-of-resources situations (e.g.,
+ out of memory to maintain PIM state if IP multicast is used in the
+ core for multicast VPN traffic, or out of memory to maintain RSVP
+ state if MPLS P2MP is used, etc.).
+
+5.2.6. Support of Inter-AS, Inter-Provider Deployments
+
+ A solution MUST support inter-AS (Autonomous System) multicast VPNs,
+ and SHOULD support inter-provider multicast VPNs. Considerations
+ about coexistence with unicast inter-AS VPN Options A, B, and C (as
+ described in Section 10 of [RFC4364]) are strongly encouraged.
+
+ A multicast VPN solution SHOULD provide inter-AS mechanisms requiring
+ the least possible coordination between providers, and keep the need
+ for detailed knowledge of providers' networks to a minimum -- all
+ this being in comparison with corresponding unicast VPN options.
+
+ o Within each service provider, the service provider SHOULD be able
+ on its own to pick the most appropriate tunneling mechanism to
+ carry (multicast) traffic among PEs (just like what is done today
+ for unicast)
+
+ o If a solution does require a single tunnel to span P routers in
+ multiple ASs, the solution SHOULD provide mechanisms to ensure
+ that the inter-provider coordination to set up such a tunnel is
+ minimized
+
+
+
+
+
+
+Morin Informational [Page 26]
+
+RFC 4834 L3VPN Mcast Reqs April 2007
+
+
+ Moreover, such support SHOULD be possible without compromising other
+ requirements expressed in this requirement document, and SHALL NOT
+ incur penalties on scalability and bandwidth-related efficiency.
+
+5.2.7. Quality-of-Service Differentiation
+
+ A multicast VPN solution SHOULD give a VPN service provider the
+ ability to offer, guarantee and enforce differentiated levels of QoS
+ for its different customers.
+
+5.2.8. Infrastructure security
+
+ The solution SHOULD provide the same level of security for the
+ service provider as what currently exists for unicast VPNs (for
+ instance, as developed in the Security sections of [RFC4364] and
+ [VRs]). For instance, traffic segregation and intrinsic protection
+ against DoS (Denial of Service) and DDoS (Distributed Denial of
+ Service) attacks of the BGP/MPLS VPN solution must be supported by
+ the multicast solution.
+
+ Moreover, since multicast traffic and routing are intrinsically
+ dynamic (receiver-initiated), some mechanism SHOULD be proposed so
+ that the frequency of changes in the way client traffic is carried
+ over the core can be bounded and not tightly coupled to dynamic
+ changes of multicast traffic in the customer network. For example,
+ multicast route dampening functions would be one possible mechanism.
+
+ Network devices that participate in the deployment and the
+ maintenance of a given L3VPN MAY represent a superset of the
+ participating devices that are also involved in the establishment and
+ maintenance of the multicast distribution tunnels. As such, the
+ activation of IP multicast capabilities within a VPN SHOULD be
+ device-specific, not only to make sure that only the relevant devices
+ will be multicast-enabled, but also to make sure that multicast
+ (routing) information will be disseminated to the multicast-enabled
+ devices only, hence limiting the risk of multicast-inferred DOS
+ attacks.
+
+ Traffic of a multicast channel for which there are no members in a
+ given multicast VPN MUST NOT be propagated within the multicast VPN,
+ most particularly if the traffic comes from another VPN or from the
+ Internet.
+
+ Security considerations are particularly important for inter-AS and
+ inter-provider deployments. In such cases, it is RECOMMENDED that a
+ multicast VPN solution support means to ensure the integrity and
+ authenticity of multicast-related exchanges across inter-AS or inter-
+ provider borders. It is RECOMMENDED that corresponding procedures
+
+
+
+Morin Informational [Page 27]
+
+RFC 4834 L3VPN Mcast Reqs April 2007
+
+
+ require the least possible coordination between providers; more
+ precisely, when specific configurations or cryptographic keys have to
+ be deployed, this shall be limited to ASBRs (Autonomous System Border
+ Routers) or a subset of them, and optionally BGP Route Reflectors (or
+ a subset of them).
+
+ Lastly, control mechanisms described in Section 5.2.5 are also to be
+ considered from this infrastructure security point of view.
+
+5.2.9. Robustness
+
+ Resiliency is also crucial to infrastructure security; thus, a
+ multicast VPN solution SHOULD either avoid single points of failures
+ or propose some technical solution making it possible to implement a
+ fail-over mechanism.
+
+ As an illustration, one can consider the case of a solution that
+ would use PIM-SM as a means to set up MDTunnels. In such a case, the
+ PIM RP might be a single point of failure. Such a solution SHOULD be
+ compatible with a solution implementing RP resiliency, such as
+ anycast-RP [RFC4610] or BSR [PIM-BSR].
+
+5.2.10. Operation, Administration, and Maintenance
+
+ The operation of a multicast VPN solution SHALL be as light as
+ possible, and providing automatic configuration and discovery SHOULD
+ be a priority when designing a multicast VPN solution. Particularly,
+ the operational burden of setting up multicast on a PE or for a VR/
+ VRF SHOULD be as low as possible.
+
+ Also, as far as possible, the design of a solution SHOULD carefully
+ consider the number of protocols within the core network: if any
+ additional protocols are introduced compared with the unicast VPN
+ service, the balance between their advantage and operational burden
+ SHOULD be examined thoroughly.
+
+ Moreover, monitoring of multicast-specific parameters and statistics
+ SHOULD be offered to the service provider, following the requirements
+ expressed in [RFC4176].
+
+ Most notably, the provider SHOULD have access to:
+
+ o Multicast traffic statistics (incoming/outgoing/dropped/total
+ traffic conveyed, by period of time)
+
+ o Information about client multicast resource usage (multicast
+ routing state and bandwidth usage)
+
+
+
+
+Morin Informational [Page 28]
+
+RFC 4834 L3VPN Mcast Reqs April 2007
+
+
+ o Alarms when limits are reached on such resources
+
+ o The IPPM (IP Performance Metrics [RFC2330])-related information
+ that is relevant to the multicast traffic usage: such information
+ includes the one-way packet delay, the inter-packet delay
+ variation, etc.
+
+ o Statistics on decisions related to how client traffic is carried
+ on distribution tunnels (e.g., "traffic switched onto a multicast
+ tree dedicated to such groups or channels")
+
+ o Statistics on parameters that could help the provider to evaluate
+ its optimality/state trade-off
+
+ This information SHOULD be made available through standardized SMIv2
+ [RFC2578] Management Information Base (MIB) modules to be used with
+ SNMP [RFC3411], or through IPFIX [IPFIX-PROT]. For instance, in the
+ context of BGP/MPLS VPNs [RFC4364], multicast extensions to MIBs
+ defined in [RFC4382] SHOULD be proposed, with proper integration with
+ [RFC3811], [RFC3812], [RFC3813], and [RFC3814] when applicable.
+
+ Mechanisms similar to those described in Section 5.2.12 SHOULD also
+ exist for proactive monitoring of the MDTunnels.
+
+ Proposed OAM mechanisms and procedures for multicast VPNs SHOULD be
+ scalable with respect to the parameters mentioned in Section 5.2.2.
+ In particular, it is RECOMMENDED that particular attention is given
+ to the impact of monitoring mechanisms on performances and QoS.
+
+ Moreover, it is RECOMMENDED that any OAM mechanism designed to
+ trigger alarms in relation to performance or resource usage metrics
+ integrate the ability to limit the rate at which such alarms are
+ generated (e.g., some form of a hysteresis mechanism based on low/
+ high thresholds defined for the metrics).
+
+5.2.11. Compatibility and Migration Issues
+
+ It is a requirement that unicast and multicast services MUST be able
+ to coexist within the same VPN.
+
+ Likewise, a multicast VPN solution SHOULD be designed so that its
+ activation in devices that participate in the deployment and
+ maintenance of a multicast VPN SHOULD be as smooth as possible, i.e.,
+ without affecting the overall quality of the services that are
+ already supported by the underlying infrastructure.
+
+ A multicast VPN solution SHOULD prevent compatibility and migration
+ issues, for instance, by focusing on providing mechanisms
+
+
+
+Morin Informational [Page 29]
+
+RFC 4834 L3VPN Mcast Reqs April 2007
+
+
+ facilitating forward compatibility. Most notably, a solution
+ supporting only a subset of the requirements expressed in this
+ document SHOULD be designed to allow compatibility to be introduced
+ in further revisions.
+
+ It SHOULD be an aim of any multicast VPN solution to offer as much
+ backward compatibility as possible. Ideally, a solution would have
+ the ability to offer multicast VPN services across a network
+ containing some legacy routers that do not support any multicast VPN-
+ specific features.
+
+ In any case, a solution SHOULD state a migration policy from possibly
+ existing deployments.
+
+5.2.12. Troubleshooting
+
+ A multicast VPN solution that dynamically adapts the way some client
+ multicast traffic is carried over the provider's network may incur
+ the disadvantage of being hard to troubleshoot. In such a case, to
+ help diagnose multicast network issues, a multicast VPN solution
+ SHOULD provide monitoring information describing how client traffic
+ is carried over the network (e.g., if a solution uses multicast-based
+ MDTunnels, which provider multicast group is used for a given client
+ multicast stream). A solution MAY also provide configuration options
+ to avoid any dynamic changes, for multicast traffic of a particular
+ VPN or a particular multicast stream.
+
+ Moreover, a solution MAY provide mechanisms that allow network
+ operators to check that all VPN sites that advertised interest in a
+ particular customer multicast stream are properly associated with the
+ corresponding MDTunnel. Providing operators with means to check the
+ proper setup and operation of MDTunnels MAY also be provided (e.g.,
+ when P2MP MPLS is used for MDTunnels, troubleshooting functionalities
+ SHOULD integrate mechanisms compliant with [RFC4687], such as LSP
+ Ping [RFC4379][LSP-PING]). Depending on the implementation, such
+ verification could be initiated by a source-PE or a receiver-PE.
+
+6. Security Considerations
+
+ This document does not by itself raise any particular security issue.
+
+ A set of security issues has been identified that MUST be addressed
+ when considering the design and deployment of multicast-enabled L3
+ PPVPNs. Such issues have been described in Section 5.1.5 and
+ Section 5.2.8.
+
+
+
+
+
+
+Morin Informational [Page 30]
+
+RFC 4834 L3VPN Mcast Reqs April 2007
+
+
+7. Contributors
+
+ The main contributors to this document are listed below, in
+ alphabetical order:
+
+ o Christian Jacquenet
+ France Telecom
+ 3, avenue Francois Chateau
+ CS 36901 35069 RENNES Cedex, France
+ Email: christian.jacquenet@orange-ftgroup.com
+
+ o Yuji Kamite
+ NTT Communications Corporation
+ Tokyo Opera City Tower 3-20-2 Nishi Shinjuku, Shinjuku-ku
+ Tokyo 163-1421, Japan
+ Email: y.kamite@ntt.com
+
+ o Jean-Louis Le Roux
+ France Telecom R&D
+ 2, avenue Pierre-Marzin
+ 22307 Lannion Cedex, France
+ Email: jeanlouis.leroux@orange-ftgroup.com
+
+ o Nicolai Leymann
+ Deutsch Telecom
+ Engineering Networks, Products & Services
+ Goslarer Ufer 3510589 Berlin, Germany
+ Email: nicolai.leymann@t-systems.com
+
+ o Renaud Moignard
+ France Telecom R&D
+ 2, avenue Pierre-Marzin
+ 22307 Lannion Cedex, France
+ Email: renaud.moignard@orange-ftgroup.com
+
+ o Thomas Morin
+ France Telecom R&D
+ 2, avenue Pierre-Marzin
+ 22307 Lannion Cedex, France
+ Email: thomas.morin@orange-ftgroup.com
+
+8. Acknowledgments
+
+ The authors would like to thank, in rough chronological order,
+ Vincent Parfait, Zubair Ahmad, Elodie Hemon-Larreur, Sebastien Loye,
+ Rahul Aggarwal, Hitoshi Fukuda, Luyuan Fang, Adrian Farrel, Daniel
+ King, Yiqun Cai, Ronald Bonica, Len Nieman, Satoru Matsushima,
+ Netzahualcoyotl Ornelas, Yakov Rekhter, Marshall Eubanks, Pekka
+
+
+
+Morin Informational [Page 31]
+
+RFC 4834 L3VPN Mcast Reqs April 2007
+
+
+ Savola, Benjamin Niven-Jenkins, and Thomas Nadeau, for their review,
+ valuable input, and feedback.
+
+ We also thank the people who kindly answered the survey, and Daniel
+ King, who took care of gathering and anonymizing its results.
+
+9. References
+
+9.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC4031] Carugi, M. and D. McDysan, "Service Requirements for
+ Layer 3 Provider-Provisioned Virtual Private
+ Networks (PPVPNs)", RFC 4031, April 2005.
+
+ [RFC4026] Andersson, L. and T. Madsen, "Provider-Provisioned
+ Virtual Private Network (VPN) Terminology",
+ RFC 4026, March 2005.
+
+ [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I.
+ Kouvelas, "Protocol Independent Multicast - Sparse
+ Mode (PIM-SM): Protocol Specification (Revised)",
+ RFC 4601, August 2006.
+
+ [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast
+ for IP", RFC 4607, August 2006.
+
+ [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and
+ A. Thyagarajan, "Internet Group Management Protocol,
+ Version 3", RFC 3376, October 2002.
+
+ [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery
+ Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
+
+ [RFC4176] El Mghazli, Y., Nadeau, T., Boucadair, M., Chan, K.,
+ and A. Gonguet, "Framework for Layer 3 Virtual
+ Private Networks (L3VPN) Operations and Management",
+ RFC 4176, October 2005.
+
+ [RFC3973] Adams, A., Nicholas, J., and W. Siadak, "Protocol
+ Independent Multicast - Dense Mode (PIM-DM):
+ Protocol Specification (Revised)", RFC 3973,
+ January 2005.
+
+
+
+
+
+
+Morin Informational [Page 32]
+
+RFC 4834 L3VPN Mcast Reqs April 2007
+
+
+9.2. Informative References
+
+ [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual
+ Private Networks (VPNs)", RFC 4364, February 2006.
+
+ [VRs] Ould-Brahim, H., "Network based IP VPN Architecture
+ Using Virtual Routers", Work in Progress,
+ March 2006.
+
+ [RFC2432] Dubray, K., "Terminology for IP Multicast
+ Benchmarking", RFC 2432, October 1998.
+
+ [RFC3031] Rosen, E., Viswanathan, A., and R. Callon,
+ "Multiprotocol Label Switching Architecture",
+ RFC 3031, January 2001.
+
+ [RFC1112] Deering, S., "Host extensions for IP multicasting",
+ STD 5, RFC 1112, August 1989.
+
+ [RFC2236] Fenner, W., "Internet Group Management Protocol,
+ Version 2", RFC 2236, November 1997.
+
+ [P2MP-RSVP-TE] Aggarwal, R., "Extensions to RSVP-TE for Point-to-
+ Multipoint TE LSPs", Work in Progress, August 2006.
+
+ [PIM-BSR] Bhaskar, N., "Bootstrap Router (BSR) Mechanism for
+ PIM", Work in Progress, June 2006.
+
+ [RFC4610] Farinacci, D. and Y. Cai, "Anycast-RP Using Protocol
+ Independent Multicast (PIM)", RFC 4610, August 2006.
+
+ [RFC3446] Kim, D., Meyer, D., Kilmer, H., and D. Farinacci,
+ "Anycast Rendevous Point (RP) mechanism using
+ Protocol Independent Multicast (PIM) and Multicast
+ Source Discovery Protocol (MSDP)", RFC 3446,
+ January 2003.
+
+ [P2MP-LDP] Minei, I., "Label Distribution Protocol Extensions
+ for Point-to-Multipoint and Multipoint-to-Multipoint
+ Label Switched Paths", Work in Progress,
+ October 2006.
+
+ [P2MP-LDP-REQS] Roux, J., "Requirements for point-to-multipoint
+ extensions to the Label Distribution Protocol",
+ Work in Progress, June 2006.
+
+
+
+
+
+
+Morin Informational [Page 33]
+
+RFC 4834 L3VPN Mcast Reqs April 2007
+
+
+ [RFC4687] Yasukawa, S., Farrel, A., King, D., and T. Nadeau,
+ "Operations and Management (OAM) Requirements for
+ Point-to-Multipoint MPLS Networks", RFC 4687,
+ September 2006.
+
+ [BIDIR-PIM] Handley, M., "Bi-directional Protocol Independent
+ Multicast (BIDIR-PIM)", Work in Progress,
+ October 2005.
+
+ [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003,
+ October 1996.
+
+ [RFC3353] Ooms, D., Sales, B., Livens, W., Acharya, A.,
+ Griffoul, F., and F. Ansari, "Overview of IP
+ Multicast in a Multi-Protocol Label Switching (MPLS)
+ Environment", RFC 3353, August 2002.
+
+ [RFC3272] Awduche, D., Chiu, A., Elwalid, A., Widjaja, I., and
+ X. Xiao, "Overview and Principles of Internet
+ Traffic Engineering", RFC 3272, May 2002.
+
+ [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
+ Traina, "Generic Routing Encapsulation (GRE)",
+ RFC 2784, March 2000.
+
+ [IPFIX-PROT] Claise, B., "Specification of the IPFIX Protocol for
+ the Exchange", Work in Progress, November 2006.
+
+ [RFC4045] Bourdon, G., "Extensions to Support Efficient
+ Carrying of Multicast Traffic in Layer-2 Tunneling
+ Protocol (L2TP)", RFC 4045, April 2005.
+
+ [RFC3809] Nagarajan, A., "Generic Requirements for Provider-
+ Provisioned Virtual Private Networks (PPVPN)",
+ RFC 3809, June 2004.
+
+ [RFC3811] Nadeau, T. and J. Cucchiara, "Definitions of Textual
+ Conventions (TCs) for Multiprotocol Label Switching
+ (MPLS) Management", RFC 3811, June 2004.
+
+ [RFC3812] Srinivasan, C., Viswanathan, A., and T. Nadeau,
+ "Multiprotocol Label Switching (MPLS) Traffic
+ Engineering (TE) Management Information Base (MIB)",
+ RFC 3812, June 2004.
+
+
+
+
+
+
+
+Morin Informational [Page 34]
+
+RFC 4834 L3VPN Mcast Reqs April 2007
+
+
+ [RFC3813] Srinivasan, C., Viswanathan, A., and T. Nadeau,
+ "Multiprotocol Label Switching (MPLS) Label
+ Switching Router (LSR) Management Information Base
+ (MIB)", RFC 3813, June 2004.
+
+ [RFC3814] Nadeau, T., Srinivasan, C., and A. Viswanathan,
+ "Multiprotocol Label Switching (MPLS) Forwarding
+ Equivalence Class To Next Hop Label Forwarding Entry
+ (FEC-To-NHLFE) Management Information Base (MIB)",
+ RFC 3814, June 2004.
+
+ [RFC2365] Meyer, D., "Administratively Scoped IP Multicast",
+ BCP 23, RFC 2365, July 1998.
+
+ [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis,
+ "Framework for IP Performance Metrics", RFC 2330,
+ May 1998.
+
+ [MULTIMETRICS] Stephan, E., "IP Performance Metrics (IPPM) for
+ spatial and multicast", Work in Progress,
+ October 2006.
+
+ [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang,
+ Z., and W. Weiss, "An Architecture for
+ Differentiated Services", RFC 2475, December 1998.
+
+ [RFC3180] Meyer, D. and P. Lothberg, "GLOP Addressing in
+ 233/8", BCP 53, RFC 3180, September 2001.
+
+ [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An
+ Architecture for Describing Simple Network
+ Management Protocol (SNMP) Management Frameworks",
+ STD 62, RFC 3411, December 2002.
+
+ [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J.
+ Schoenwaelder, Ed., "Structure of Management
+ Information Version 2 (SMIv2)", STD 58, RFC 2578,
+ April 1999.
+
+ [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery",
+ RFC 1191, November 1990.
+
+ [RFC4382] Nadeau, T. and H. van der Linde, "MPLS/BGP Layer 3
+ Virtual Private Network (VPN) Management Information
+ Base", RFC 4382, February 2006.
+
+
+
+
+
+
+Morin Informational [Page 35]
+
+RFC 4834 L3VPN Mcast Reqs April 2007
+
+
+ [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-
+ Protocol Label Switched (MPLS) Data Plane Failures",
+ RFC 4379, February 2006.
+
+ [LSP-PING] Farrel, A. and S. Yasukawa, "Detecting Data Plane
+ Failures in Point-to-Multipoint Multiprotocol",
+ Work in Progress, September 2006.
+
+ [RFC4459] Savola, P., "MTU and Fragmentation Issues with In-
+ the-Network Tunneling", RFC 4459, April 2006.
+
+Author's Address
+
+ Thomas Morin (editor)
+ France Telecom R&D
+ 2, avenue Pierre Marzin
+ Lannion 22307
+ France
+
+ EMail: thomas.morin@orange-ftgroup.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Morin Informational [Page 36]
+
+RFC 4834 L3VPN Mcast Reqs April 2007
+
+
+Full Copyright Statement
+
+ Copyright (C) The IETF Trust (2007).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
+ THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
+ OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
+ THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr@ietf.org.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+Morin Informational [Page 37]
+