France Telecom R&D

2, avenue Pierre Marzin 22307 Lannion France thomas.morin@orange-ftgroup.com

l3vpn Working Group 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.

Virtual Private Network (VPN) services satisfying the requirements defined in 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: because P routers (Provider Routers) need not be aware of VPN service details 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 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.

Although the reader is assumed to be familiar with the terminology defined in , , , and , 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. 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. 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. Provider-Provisioned Virtual Private Network. "Provider Edge", "Customer Edge" (as defined in ). As suggested in , 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. 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 , and "VR" to "Virtual Router" as defined in terminology. 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. Denotes a multicast source. Denotes a multicast group. In the multicast SSM model , a "multicast channel" designates traffic from a specific source S to a multicast group G. Also denominated as "(S,G)". Service provider. 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. Rendezvous Point ( Protocol Independent Multicast - Sparse Mode (PIM-SM)). Designate "Point-to-Multipoint" and "Multipoint-to-Multipoint" replication trees. 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 for details about terminology specifically relevant to VPN aspects, and to for multicast performance or quality of service (QoS)-related terms.

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 .

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.

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

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 . Consequently, any deployment will require a trade-off to be made. This document will express some requirements related to this trade-off.

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.

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.

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: one or few sources to many receivers sources are often in known locations; receivers are in less predictable locations (this latter point may depend on applications) in some cases, it is expected that the regularity of audience patterns may help improve how the bandwidth/state trade-off is handled the number of streams can be as high as hundreds, or even thousands, of streams 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. QoS requirements include, in many cases, a low multicast group join delay 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 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) 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

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: small groups, and low predictability of the location of participants ("sparse groups") 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.

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

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

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.

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.

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.

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

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.

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

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.

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

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

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.

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.

Consequently to , multicast-related protocol exchanges between a CE and its directly connected PE SHOULD happen via existing multicast protocols. Such protocols include: PIM-SM, bidirectional-PIM, PIM - Dense Mode (DM), and IGMPv3 (this version implicitly supports hosts that only implement IGMPv1 or IGMPv2). 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) (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.

Firstly, general considerations regarding QoS in L3VPNs expressed in Section 5.5 of 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 environment SHALL benefit from Diffserv 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. e Also, considering that multicast reception is receiver-triggered, group join delay (as defined in ) 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 ) 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.

The requirements and definitions for operations and management (OAM) of L3VPNs that are defined in 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. 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) or IPFIX . 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 , 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, ) that is relevant to the multicast traffic usage: such information includes the one-way packet delay, the inter-packet delay variation, etc. See . A generic discussion of SLAs is provided in . 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 , 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 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).

Security is a key point for a customer who uses a VPN service. For instance, the model offers some guarantees concerning the security level of data transmission within the VPN. A multicast VPN solution MUST provide an architecture with the same level of security for both unicast and multicast traffic. Moreover, the activation of multicast features SHOULD be possible: per VRF / per VR per CE interface (when multiple CEs of a VPN are connected to a common VRF/VR) per multicast group and/or per channel with a distinction between multicast reception and emission A multicast VPN solution may choose to make the optimality/scalability trade-off stated in 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).

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: receivers behind attached CEs can receive multicast traffic sourced in the configured set of extranet VPNs sources behind attached CEs can reach multicast traffic receivers located in the configured set of extranet VPNs multicast reception and emission can be independently enabled for each of the extranet VPNs Moreover, a solution MUST allow service providers to control an extranet's multicast connectivity independently from the extranet's unicast connectivity. More specifically: enabling unicast connectivity to another VPN MUST be possible without activating multicast connectivity with that VPN 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 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.

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.

Many L3 PPVPN solutions, such as 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 and SHOULD include some of the protocols listed in , such as for instance P2MP MPLS signaling protocols. In the context of MPLS-based L3VPN deployments, such as BGP/MPLS VPNs , 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.

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.

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.

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.

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 or anycast-RP ( Multicast Source Discovery Protocol (MSDP)-based or PIM-based). 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: 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 maintain ASM multicast service within any site that loses connectivity to the service provider

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.

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 ) for services that are to be used only inside the VPN, and of either SSM-range addresses (232/8 as defined by ) or globally assigned group addresses (e.g., GLOP, 233/8) for services for which traffic may be transmitted outside the VPN.

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: 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 a multicast VPN solution SHOULD enable the service provider to commit to a minimum path MTU usable by multicast VPN customers a multicast VPN solution SHOULD be compatible with path MTU discovery mechanisms (see and ), 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.

Note: To avoid repetition and confusion with terms used in solution specifications, we introduced in 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.

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.

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 and Virtual Router 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. 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: the number of PEs the number of customer VPNs (total and per PE) the number of PEs and sites in any VPN the number of client multicast channels (groups or source-groups) Please consult Section 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: 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 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 routers to add or 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 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. 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.

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

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

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

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 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: Generic Routing Encapsulation (GRE) (including GRE in multicast IP trees), MPLS (including P2P or MP2P tunnels, and multipoint tunnels signaled with MPLS P2MP extensions to the Resource Reservation Protocol (RSVP) or Label Distribution Protocol (LDP) ), Layer-2 Tunneling Protocol (L2TP) (including L2TP for multicast), IPsec , IP-in-IP, 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.

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: fragmentation inside the MDTunnel does not happen, even when allowed by the underlying tunneling technology proper troubleshooting can be performed if packets that are too big for the MDTunnel happen to be encapsulated in the MDTunnel

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

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

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.

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 and ). 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 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 are also to be considered from this infrastructure security point of view.

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

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 . Most notably, the provider SHOULD have access to: Multicast traffic statistics (incoming/outgoing/dropped/total traffic conveyed, by period of time) Information about client multicast resource usage (multicast routing state and bandwidth usage) Alarms when limits are reached on such resources The IPPM (IP Performance Metrics)-related information that is relevant to the multicast traffic usage: such information includes the one-way packet delay, the inter-packet delay variation, etc. 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") Statistics on parameters that could help the provider to evaluate its optimality/state trade-off This information SHOULD be made available through standardized SMIv2 Management Information Base (MIB) modules to be used with SNMP, or through IPFIX . For instance, in the context of BGP/MPLS VPNs , multicast extensions to MIBs defined in SHOULD be proposed, with proper integration with , , , and when applicable. Mechanisms similar to those described in 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 . 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).

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

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 , such as LSP Ping ). Depending on the implementation, such verification could be initiated by a source-PE or a receiver-PE.

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

The main contributors to this document are listed below, in alphabetical order: Christian JacquenetFrance Telecom3, avenue Francois ChateauCS 36901 35069 RENNES Cedex, FranceEmail: christian.jacquenet@orange-ftgroup.com Yuji KamiteNTT Communications CorporationTokyo Opera City Tower 3-20-2 Nishi Shinjuku, Shinjuku-kuTokyo 163-1421, JapanEmail: y.kamite@ntt.com Jean-Louis Le RouxFrance Telecom R&D 2, avenue Pierre-Marzin22307 Lannion Cedex, FranceEmail: jeanlouis.leroux@orange-ftgroup.com Nicolai LeymannDeutsch TelecomEngineering Networks, Products & ServicesGoslarer Ufer 3510589 Berlin, GermanyEmail: nicolai.leymann@t-systems.com Renaud MoignardFrance Telecom R&D 2, avenue Pierre-Marzin22307 Lannion Cedex, FranceEmail: renaud.moignard@orange-ftgroup.com Thomas MorinFrance Telecom R&D 2, avenue Pierre-Marzin22307 Lannion Cedex, FranceEmail: thomas.morin@orange-ftgroup.com

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

Harvard University

1350 Mass. Ave. Cambridge MA 02138 - +1 617 495 3864 sob@harvard.edu

General keyword In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. Authors who follow these guidelines should incorporate this phrase near the beginning of their document: 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. Note that the force of these words is modified by the requirement level of the document in which they are used. <p>This document provides requirements for Layer 3 Virtual Private Networks (L3VPNs). It identifies requirements applicable to a number of individual approaches that a Service Provider may use to provision a Virtual Private Network (VPN) service. This document expresses a service provider perspective, based upon past experience with IP-based service offerings and the ever-evolving needs of the customers of such services. Toward this end, it first defines terminology and states general requirements. Detailed requirements are expressed from a customer perspective as well as that of a service provider. This memo provides information for the Internet community.</p> <p>The widespread interest in provider-provisioned Virtual Private Network (VPN) solutions lead to memos proposing different and overlapping solutions. The IETF working groups (first Provider-Provisioned VPNs and later Layer 2 VPNs and Layer 3 VPNs) have discussed these proposals and documented specifications. This has lead to the development of a partially new set of concepts used to describe the set of VPN services. </p><p> To a certain extent, more than one term covers the same concept, and sometimes the same term covers more than one concept. This document seeks to make the terminology in the area clearer and more intuitive. This memo provides information for the Internet community. </p> <p>This document specifies Protocol Independent Multicast - Sparse Mode (PIM-SM). PIM-SM is a multicast routing protocol that can use the underlying unicast routing information base or a separate multicast-capable routing information base. It builds unidirectional shared trees rooted at a Rendezvous Point (RP) per group, and optionally creates shortest-path trees per source.</p><p> This document obsoletes RFC 2362, an Experimental version of PIM-SM. [STANDARDS TRACK]</p> <p>IP version 4 (IPv4) addresses in the 232/8 (232.0.0.0 to 232.255.255.255) range are designated as source-specific multicast (SSM) destination addresses and are reserved for use by source-specific applications and protocols. For IP version 6 (IPv6), the address prefix FF3x::/32 is reserved for source-specific multicast use. This document defines an extension to the Internet network service that applies to datagrams sent to SSM addresses and defines the host and router requirements to support this extension. [STANDARDS TRACK]</p> <p>This document updates RFC 2710, and it specifies Version 2 of the ulticast Listener Discovery Protocol (MLDv2). MLD is used by an IPv6 router to discover the presence of multicast listeners on directly attached links, and to discover which multicast addresses are of interest to those neighboring nodes. MLDv2 is designed to be interoperable with MLDv1. MLDv2 adds the ability for a node to report interest in listening to packets with a particular multicast address only from specific source addresses or from all sources except for specific source addresses. [STANDARDS TRACK] </p> <p>This document provides a framework for the operation and management of Layer 3 Virtual Private Networks (L3VPNs). This framework intends to produce a coherent description of the significant technical issues that are important in the design of L3VPN management solutions. The selection of specific approaches, and making choices among information models and protocols are outside the scope of this document. This memo provides information for the Internet community.</p> <p>This document specifies Protocol Independent Multicast - Dense Mode (PIM-DM). PIM-DM is a multicast routing protocol that uses the underlying unicast routing information base to flood multicast datagrams to all multicast routers. Prune messages are used to prevent future messages from propagating to routers without group membership information. This memo defines an Experimental Protocol for the Internet community. </p> <p>This document describes a method by which a Service Provider may use an IP backbone to provide IP Virtual Private Networks (VPNs) for its customers. This method uses a "peer model", in which the customers' edge routers (CE routers) send their routes to the Service Provider's edge routers (PE routers); there is no "overlay" visible to the customer's routing algorithm, and CE routers at different sites do not peer with each other. Data packets are tunneled through the backbone, so that the core routers do not need to know the VPN routes. [STANDARDS TRACK]</p> This document describes a network-based Virtual Private Network (VPN) architecture using the virtual router (VR) concept. Multiple VRs can exist in a single physical device. A VR emulates all the functionality of a physical router, and therefore inherits all existing mechanisms and tools for configuration, operation, accounting, and maintenance. Any routing protocol can be used to distribute VPN reachability information among VRs, and no VPN- related modifications or extensions are needed to the routing protocol for achieving VPN reachability. Direct VR-to-VR connectivity may be configured through layer-2 links or through IP- or MPLS-based tunnels. Traffic from VRs belonging to different VPNs may be aggregated over a "backbone VR" network, which greatly simplifies VPN provisioning. This architecture accommodates various backbone deployment scenarios, both where the VPN service provider owns the backbone, and where the VPN service provider obtains backbone service from one or more other service providers. IronBridge Networks

55 Hayden Avenue Lexington MA 02421 USA 781 372 8118 kdubray@ironbridgenetworks.com

Internet multicast The purpose of this document is to define terminology specific to the benchmarking of multicast IP forwarding devices. It builds upon the tenets set forth in RFC 1242, RFC 2285, and other IETF Benchmarking Methodology Working Group (BMWG) efforts. This document seeks to extend these efforts to the multicast paradigm. The BMWG produces two major classes of documents: Benchmarking Terminology documents and Benchmarking Methodology documents. The Terminology documents present the benchmarks and other related terms. The Methodology documents define the procedures required to collect the benchmarks cited in the corresponding Terminology documents. <p>This document specifies the architecture for Multiprotocol Label Switching (MPLS). [STANDARDS TRACK] </p> Stanford University, Computer Science Department

Stanford CA 94305-2140 US +1 415 723 9427 deering@PESCADERO.STANFORD.EDU

Xerox PARC

3333 Coyote Hill Road Palo Alto CA 94304 +1 650 812 4816 fenner@parc.xerox.com

Internet internet group multicast protocol multicast routing This memo documents IGMPv2, used by IP hosts to report their multicast group memberships to routers. It updates STD 5, RFC 1112. IGMPv2 allows group membership termination to be quickly reported to the routing protocol, which is important for high-bandwidth multicast groups and/or subnets with highly volatile group membership. This document is a product of the Inter-Domain Multicast Routing working group within the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at idmr@cs.ucl.ac.uk and/or the author(s). This document describes extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for the set up of Traffic Engineered (TE) point-to-multipoint (P2MP) Label Switched Paths (LSPs) in Multi- Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. The solution relies on RSVP-TE without requiring a multicast routing protocol in the Service Provider core. Protocol elements and procedures for this solution are described. There can be various applications for P2MP TE LSPs such as IP multicast. Specification of how such applications will use a P2MP TE LSP is outside the scope of this document. This document specifies the Bootstrap Router (BSR) mechanism for the class of multicast routing protocols in the PIM (Protocol Independent Multicast) family that use the concept of a Rendezvous Point as a means for receivers to discover the sources that send to a particular multicast group. BSR is one way that a multicast router can learn the set of group-to-RP mappings required in order to function. The mechanism is dynamic, largely self-configuring, and robust to router failure. <p>This specification allows Anycast-RP (Rendezvous Point) to be used inside a domain that runs Protocol Independent Multicast (PIM) only. Other multicast protocols (such as Multicast Source Discovery Protocol (MSDP), which has been used traditionally to solve this problem) are not required to support Anycast-RP. [STANDARDS TRACK]</p> <p>This document describes a mechanism to allow for an arbitrary number of Rendevous Points (RPs) per group in a single shared-tree Protocol Independent Multicast-Sparse Mode (PIM-SM) domain. This memo provides information for the Internet community. </p> This document describes extensions to the Label Distribution Protocol (LDP) for the setup of point to multi-point (P2MP) and multipoint-to- multipoint (MP2MP) Label Switched Paths (LSPs) in Multi-Protocol Label Switching (MPLS) networks. The solution relies on LDP without requiring a multicast routing protocol in the network. Protocol elements and procedures for this solution are described for building such LSPs in a receiver-initiated manner. There can be various applications for P2MP/MP2MP LSPs, for example IP multicast or support for multicast in BGP/MPLS L3VPNs. Specification of how such applications can use a LDP signaled P2MP/MP2MP LSP is outside the scope of this document. This document lists a set of functional requirements for Label Distribution Protocol (LDP) extensions for setting up point-to- multipoint (P2MP) Label Switched Paths (LSP), in order to deliver point-to-multipoint applications over a Multi Protocol Label Switching (MPLS) infrastructure. It is intended that solutions that specify LDP procedures for setting up P2MP LSP satisfy these requirements. <p>Multi-Protocol Label Switching (MPLS) has been extended to encompass point-to-multipoint (P2MP) Label Switched Paths (LSPs). As with point-to-point MPLS LSPs, the requirement to detect, handle, and diagnose control and data plane defects is critical.</p><p> For operators deploying services based on P2MP MPLS LSPs, the detection and specification of how to handle those defects are important because such defects not only may affect the fundamentals of an MPLS network, but also may impact service level specification commitments for customers of their network.</p><p> This document describes requirements for data plane operations and management for P2MP MPLS LSPs. These requirements apply to all forms of P2MP MPLS LSPs, and include P2MP Traffic Engineered (TE) LSPs and multicast LSPs. This memo provides information for the Internet community.</p> This document discusses Bi-directional PIM, a variant of PIM Sparse-Mode that builds bi-directional shared trees connecting multicast sources and receivers. Bi-directional trees are built using a fail-safe Designated Forwarder (DF) election mechanism operating on each link of a multicast topology. With the assistance of the DF, multicast data is natively forwarded from sources to the Rendezvous-Point and hence along the shared tree to receivers without requiring source-specific state. The DF election takes place at RP discovery time and provides the route to the RP thus eliminating the requirement for data-driven protocol events. Room H3-D34

T. J. Watson Research Center IBM Corporation 30 Saw Mill River Rd. Hawthorne NY 10532 +1-914-784-6205 perk@watson.ibm.com

Internet encapsulate mobile ip routing wireless This document specifies a method by which an IP datagram may be encapsulated (carried as payload) within an IP datagram. Encapsulation is suggested as a means to alter the normal IP routing for datagrams, by delivering them to an intermediate destination that would otherwise not be selected by the (network part of the) IP Destination Address field in the original IP header. Encapsulation may serve a variety of purposes, such as delivery of a datagram to a mobile node using Mobile IP. <p>This memo describes the principles of Traffic Engineering (TE) in the Internet. The document is intended to promote better understanding of the issues surrounding traffic engineering in IP networks, and to provide a common basis for the development of traffic engineering capabilities for the Internet. The principles, architectures, and methodologies for performance evaluation and performance optimization of operational IP networks are discussed throughout this document. This memo provides information for the Internet community. </p> Procket Networks

3850 No. First St. Ste. C San Jose CA 95134 US dino@procket.com

Procket Networks

3850 No. First St. Ste. C San Jose CA 95134 US +1 408 954 7903 +1 408 987 6166 tony1@home.net

Enron Communications

stan_hanks@enron.net

Cisco Systems, Inc.

170 Tasman Drive San Jose CA 95134 US dmm@cisco.com

Juniper Networks

pst@juniper.net

This document specifies a protocol for encapsulation of an arbitrary network layer protocol over another arbitrary network layer protocol. This document specifies the IPFIX protocol that serves for transmitting IP traffic flow information over the network. In order to transmit IP traffic flow information from an exporting process to an information collecting process, a common representation of flow data and a standard means of communicating them is required. This document describes how the IPFIX data and templates records are carried over a number of transport protocols from an IPFIX exporting process to an IPFIX collecting process. <p>The Layer Two Tunneling Protocol (L2TP) provides a method for tunneling PPP packets. This document describes an extension to L2TP, to make efficient use of L2TP tunnels within the context of deploying multicast services whose data will have to be conveyed by these tunnels. This memo defines an Experimental Protocol for the Internet community.</p> <p>This document describes generic requirements for Provider-Provisioned Virtual Private Networks (PPVPN). The requirements are categorized into service requirements, provider requirements and engineering requirements. These requirements are not specific to any particular type of PPVPN technology, but rather apply to all PPVPN technologies. All PPVPN technologies are expected to meet the umbrella set of requirements described in this document. This memo provides information for the Internet community. </p> <p>This memo defines a Management Information Base (MIB) module which contains Textual Conventions to represent commonly used Multiprotocol Label Switching (MPLS) management information. The intent is that these TEXTUAL CONVENTIONS (TCs) will be imported and used in MPLS related MIB modules that would otherwise define their own representations. [STANDARDS TRACK] </p> <p>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for Multiprotocol Label Switching (MPLS) based traffic engineering (TE). [STANDARDS TRACK] </p> <p>This memo defines an portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects to configure and/or monitor a Multiprotocol Label Switching (MPLS) Label Switching Router (LSR). [STANDARDS TRACK] </p> <p>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for defining, configuring, and monitoring Forwarding Equivalence Class (FEC) to Next Hop Label Forwarding Entry (NHLFE) mappings and corresponding actions for use with Multiprotocol Label Switching (MPLS). [STANDARDS TRACK] </p> Cisco Systems

San Jose CA dmm@cisco.com

Internet multicast MS 50B/2239

Lawrence Berkeley National Laboratory University of California Berkeley CA 94720 USA +1 510/486-7504 vern@ee.lbl.gov

Advanced Network & Services, Inc.

200 Business Park Drive Armonk NY 10504 USA +1 914/765-1120 almes@advanced.org

Pittsburgh Supercomputing Center

4400 5th Avenue Pittsburgh PA 15213 USA +1 412/268-6282 mahdavi@psc.edu

Pittsburgh Supercomputing Center

4400 5th Avenue Pittsburgh PA 15213 USA +1 412/268-3319 mathis@psc.edu

Internet Operations IP metrics The IETF IP Performance Metrics (IPPM) working group has standardized metrics for measuring end-to-end performance between 2 points. This memo defines 2 sets of metrics to extend these end-to-end ones. It defines spatial metrics for measuring the performance of segments along a path and metrics for measuring the performance of a group of users in multiparty communications. Torrent Networking Technologies

3000 Aerial Center, Suite 140 Morrisville NC 27560 USA +1 919 468 8466 x232 slblake@torrentnet.com

EMC Corporation

35 Parkwood Drive Hopkinton MA 01748 USA +1 508 435 1000 x76140 black_david@emc.com

Sun Microsystems, Inc.

2990 Center Green Court South Boulder CO 80301 USA +1 303 448 0048 x115 mark.carlson@sun.com

Nortel UK

London Road Harlow, Essex CM17 9NA UK +44 1279 405498 elwynd@nortel.co.uk

Bell Labs Lucent Technologies

101 Crawfords Corner Road Holmdel NJ 07733 USA zhwang@bell-labs.com

Lucent Technologies

300 Baker Avenue, Suite 100 Concord MA 01742-2168 USA wweiss@lucent.com

Internet type of service This document defines an architecture for implementing scalable service differentiation in the Internet. This architecture achieves scalability by aggregating traffic classification state which is conveyed by means of IP-layer packet marking using the DS field . Packets are classified and marked to receive a particular per-hop forwarding behavior on nodes along their path. Sophisticated classification, marking, policing, and shaping operations need only be implemented at network boundaries or hosts. Network resources are allocated to traffic streams by service provisioning policies which govern how traffic is marked and conditioned upon entry to a differentiated services-capable network, and how that traffic is forwarded within that network. A wide variety of services can be implemented on top of these building blocks. <p>This document defines the policy for the use of 233/8 for statically e assigned multicast addresses. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. </p> <p>This document describes an architecture for describing Simple Network Management Protocol (SNMP) Management Frameworks. The architecture is designed to be modular to allow the evolution of the SNMP protocol standards over time. The major portions of the architecture are an SNMP engine containing a Message Processing Subsystem, a Security Subsystem and an Access Control Subsystem, and possibly multiple SNMP applications which provide specific functional processing of management data. This document obsoletes RFC 2571. [STANDARDS TRACK] </p> Cisco Systems, Inc.

170 West Tasman Drive San Jose CA 95134-1706 US +1 408 526 5260 kzm@cisco.com

SNMPinfo

3763 Benton Street Santa Clara CA 95051 US +1 408 221 8702 dperkins@snmpinfo.com

TU Braunschweig

Bueltenweg 74/75 38106 Braunschweig DE +49 531 3913283 schoenw@ibr.cs.tu-bs.de

Digital Equipment Corporation (DEC) , Western Research Laboratory

100 Hamilton Avenue Palo Alto CA 94301 US +1 415 853 6643 mogul@decwrl.dec.com

Xerox Palo Alto Research Center

3333 Coyote Hill Road Palo Alto CA 94304 US +1 415 494 4839 deering@xerox.com

This memo describes a technique for dynamically discovering the maximum transmission unit (MTU) of an arbitrary internet path. It specifies a small change to the way routers generate one type of ICMP message. For a path that passes through a router that has not been so changed, this technique might not discover the correct Path MTU, but it will always choose a Path MTU as accurate as, and in many cases more accurate than, the Path MTU that would be chosen by current practice. <p>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects to configure and/or monitor Multiprotocol Label Switching Layer-3 Virtual Private Networks on a Multiprotocol Label Switching (MPLS) Label Switching Router (LSR) supporting this feature. [STANDARDS TRACK]</p> <p>This document describes a simple and efficient mechanism that can be used to detect data plane failures in Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs). There are two parts to this document: information carried in an MPLS "echo request" and "echo reply" for the purposes of fault detection and isolation, and mechanisms for reliably sending the echo reply. [STANDARDS TRACK]</p> Recent proposals have extended the scope of Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) to encompass point-to-multipoint (P2MP) LSPs. The requirement for a simple and efficient mechanism that can be used to detect data plane failures in point-to-point (P2P) MPLS LSPs has been recognised and has led to the development of techniques for fault detection and isolation commonly referred to as "LSP Ping". The scope of this document is fault detection and isolation for P2MP MPLS LSPs. This documents does not replace any of the mechanism of LSP Ping, but clarifies their applicability to MPLS P2MP LSPs, and extends the techniques and mechanisms of LSP Ping to the MPLS P2MP environment. <p>Tunneling techniques such as IP-in-IP when deployed in the middle of the network, typically between routers, have certain issues regarding how large packets can be handled: whether such packets would be fragmented and reassembled (and how), whether Path MTU Discovery would be used, or how this scenario could be operationally avoided. This memo justifies why this is a common, non-trivial problem, and goes on to describe the different solutions and their characteristics at some length. This memo provides information for the Internet community.</p>