Framework and Requirements for Virtual Private Multicast Service (VPMS)

describes different types of Provider Provisioned Layer 2 VPNs (L2 PPVPNs, or L2VPNs); Some of them are widely deployed today, such as Virtual Private Wire Service (VPWS) and Virtual Private LAN Service (VPLS). A VPWS is a VPN service that supplies a Layer 2 point-to-point service. A VPLS is an L2 service that emulates Ethernet LAN service across a Wide Area Network (WAN). For some use cases described hereafter, there are P2MP (point-to-multipoint) type services for Layer 2 traffic. However, there is no straightforward way to realize it based on the existing L2VPN. In a VPWS, a SP can set up point-to-point connectivity per a pair of CEs but it is impossible to replicate traffic for point-to-multipoint in SP's network side. Even though a SP builds multiple PWs independently and make CEs to replicate traffic over them, it is considered an inconvenient way for the customer and a waste of bandwidth resources. In a VPLS, SPs can naturally offer multipoint connectivity across backbone. Although it is seemingly applicable for point-to-multipoint service as well, there remains extra work for SPs to filter unnecessary traffic between irrelevant sites (i.e., from a receiver PE to another receiver PE) because VPLS provides full-mesh multipoint-to-multipoint connectivity between CEs. Moreover, VPLS's MAC-based learning/forwarding operation is considered unnecessary for some scenarios particularly if customers just want to have simple unidirectional point-to-multipoint service, or if they require non-Ethernet Layer 2 connectivity. Consequently, There is a real need for a solution that natively provides point-to-multipoint service in L2VPN.

VPMS is defined as a Layer 2 service that provides point-to-multipoint connectivity for a variety of Layer2 link layers across an IP or MPLS-enabled PSN. VPMS is categorized as a kind of provider-provisioned Layer 2 Virtual Private Networks (L2VPN). This document provides service definition and reference model, as well as functional requirements for VPMS. It is intended to show a proper reference to introduce VPMS and a checklist of requirements that will provide a consistent way to evaluate how well each solution satisfies the requirements. This document introduces new service framework and requirements for VPMS within the context of L2VPN, on top of the existing framework and requirements . The technical specifications are outside the scope of this document. There is no intent to specify solution-specific details. This document provides requirements from both the Provider's and the Customer's point of view.

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 .

The content of this document makes use of the terminology defined in . For readability purposes, we list some of the terms here in addition to some specific terms used in this document.

Point-to-Point Point-to-Multipoint Pseudowire Virtual Private Multicast Service Provider/Customer Edge Provider Router Attachment Circuit Packet Switched Network Service Provider

For multicast traffic delivery, there is a requirement to deliver a unidirectional P2MP service in addition to the existing P2P service. The demand is growing to provide private service which supports Ethernet traffic duplication, for various applications such as IP-TV broadcasting, contents delivery network, etc. Moreover, many digital audio/video devices (e.g., MPEG-TS, HD-SDI) that supports Ethernet interfaces are getting available these days, which will make Ethernet P2MP service more common. Also there are some applications that would prefer static transport of VPMS. For example, MPEG-TS/IP/Ethernet in DVB-H is typically static broadcast without any signaling in the upstream direction. VPMS could be a possible solution to provide these kinds of networking connectivity over PSN backbone. Currently VPLS is able to give P2MP-type replication for Ethernet traffic. Native VPLS already supports this capability with full mesh of PWs, and the extension to optimize replication is also proposed as an additional feature; however, VPLS by nature requires MAC-based learning and forwarding, which might not be needed in some cases by particular users. Generally, video distribution applications require a unidirectional P2MP traffic, but may not always require any added expenses of MAC address management. In addition, VPLS is a service that essentially provides any-to-any connectivity between all CEs in a VPN as it emulates a LAN service; however, if you want just P2MP connectivity, the traffic between different receivers is not always needed, and traffic from receiver to sender is not always needed, either. In contrast, VPMS is a service that provides much simpler operation. Note that VPMS provides single coverage of receiver membership; that is, there is no distinct differentiation about multiple multicast groups. Every traffic from a particular Attachment Circuit (AC) will flow toward the same remote receivers, even if the destination MAC address is changed. Basically in VPMS, destination MAC addresses is not used for forwarding, which is significantly different from VPLS. If MAC-based forwarding is preferred (i.e., multicast/unicast differentiation of MAC address), VPLS should be chosen rather than VPMS.

A use case of ATM-based service in VPMS could be to offer the capability for service providers to support IP multicast wholesale services over ATM in case the wholesale customer relies on ATM infrastructure. The P2MP support alleviates the constraint in terms of replication for ATM to support IP multicast services. Another use case of VPMS for ATM is for audio/video stream applications. Today many digital TV broadcasting networks adopt ATM-based distribution system with point-to-multipoint PVP/PVCs. Their transport network supports replicating ATM cells in transit nodes to efficently deliver programs to multiple terminals. For migrating such ATM-based network onto IP/MPLS-based network, VPMS will be considered a candidate solution.

Today the existing VPWS already supports TDM emulation services (SAToP, CESoPSN or TDMoIP). It is a Layer 1 service, not Layer 2 service; however, a common architecture is being used since they are all packet-based emulations by SP's network. VPMS will also be considered as a solution for such TDM applications that require point-to-multipoint topology. In a PSN environment, the existing VPWS allows supporting 2G/3G mobile backhauling (e.g. TDM traffic for GSM's Abis interface, ATM traffic for Release 99 UMTS's Iub interface). At the time being, the Mobile backhauling architecture is always built as a star topology between the 2G/3G controller (e.g. BSC or RNC) and the 2G/3G Base Stations (BTS or NodeB). Therefore VPWSes (P2P service) are used between each Base Station and their corresponding controller and nothing more is required. As far as synchronization in a PSN environment is concerned, different mechanisms can be considered to provide frequency and phase clock required in the 2G/3G Mobile environment to guarantee mobile handover and strict QoS. One of them consists in using Adaptive Clock Distribution and Recovery. With this method a Master element distributes a reference clock at protocol level by regularly sending TDM PW packets (SAToP, CESoPSN or TDMoIP) to Slave elements. This process is based on the fact that the volume of transmitted data arrival is considered as an indication of the source frequency that could be used by the Slave element to recover the source clock frequency. Consequently, with the current methods, the PE connected to the Master must setup and maintain as many VPWS (P2P) as we have Slave elements, and the Master has to replicate the traffic. A better solution to deliver the clock frequency would be to use a VPMS which supports P2MP traffic. This may scale much more than P2P services (VPWS) with regards to the forwarding plane at the Master since the traffic is no more replicated to individual VPWSes (P2P) but only to the AC associated to the VPMS (P2MP). It may ease the provisioning process since only one source endpoint must be configured at the Ingress PE. This alleviated provisioning process would be particularly appreciated for the introduction of new Base Stations. The main gain would be to avoid replication on the Master and hence save bandwidth consumed by the synchronization traffic which typically requires the highest level of QoS. This kind of traffic will be competing with equivalent QOS traffic like VoIP, that is why it is significant to save the slightest bandwidth.

The VPMS reference model is shown in Figure 1.

---+ ------------------------ +--->| CE2 | +-----+ | | | | +-----+ VPMS A | +------+ VPMS A +------+ | VPMS A Sender +->|......>...+.......... >......|>-+ Receiver | VPMS | . | VPMS | | PE1 | . VPMS B | PE2 | +-<|......<.. . ....+.....<......|<-+ | +------+ . . +------+ | +-----+ | | . . | | +-----+ | CE4 |<---+ |Routed . . | +---| CE3 | +-----+ AC4 |Backbone. . | AC3 +-----+ VPMS B | . . | VPMS B Receiver | +-v-----v-+ | Sender ------| . . |------- | . VPMS. | | . PE3 . | +---------+ v v | | AC5| |AC6 v v +-----+ +-----+ | CE5 | | CE6 | +-----+ +-----+ VPMS A VPMS B Receiver Receiver Figure 1: Reference Model for VPMS ]]> A single VPMS unit provides isolated service reachability domains to each customer. This unit is called a VPMS instance. One VPMS instance corresponds to a unique unidirectional point-to-multipoint reachability. In Figure 1, there are two VPMS instances shown, VPMS A and VPMS B. In principle, there are no traffic exchange allowed between these different instances. In a VPMS, a single CE-PE connection is used for transmitting frames to deliver multiple remote CEs, with point-to-multipoint duplication. SP's network (PE as well as P) has a role to duplicate frames so that source side does not need to send multiple frames to individual directions. In a VPMS, there are two types of CE. One is sender, and the other is receiver. A sender CE can send out traffic as a source into a VPMS instance. A receiver CE can receive traffic from a sender site, but cannot receive from other receiver CEs. A sender CE itself does not have capability of receiving traffic. Like VPWS, an Attachment Circuit (AC) is provided to accommodate CEs in a VPMS. In a VPMS, an AC attached to VPMS MUST be configured as "sender" or "receiver" not both. That is, any AC is associated with the role of either sending side (Tx) or receiving side (Rx) from the view of CE. Thus every AC deals with unidirectional traffic flow. In Figure 1, AC1 and AC3 are configured as sending sides while AC2, AC4, AC5 and AC6 are as receiving sides. CE1 could send traffic to VPMS A via AC1, but it could also receive traffic from VPMS B if another AC is connected to CE1. Basically there is one-to-one mapping between an attachment circuit and each customer's P2MP topology. A unique VPMS instance corresponds to each topology. For example, every traffic from CE1 to PE1 (thorough AC1) is mapped to VPMS A's topology (to CE2 and CE5). In the context of VPMS, one "VPN" as a specific set of sites that have been configured to allow communication, can be composed by one or more sets of VPMS instances. By customer's administrative policies, sender and receiver CEs might be overlapped by multiple VPMS instances (for details, see Section 6.1. as an example). A VPN will be finally defined by those VPMS instance sets. In short, VPMS is defined just as a common point-to-multipoint (P2MP) delivery topology, and customer's administrative policy will determine the real VPN domain in the broad sense by picking up one or more VPMS instances. In a VPMS, PEs will be connected using PW technology which may include P2MP traffic optimization. Such expected technique will benefit from the traffic replication for high bandwidth efficiency. Sender CE has only to transmit one stream toward PE, not duplicated traffic. The backbone side is a IP or MPLS-enabled routed PSN. VPMS is to support various Layer 2 protocol services such as Ethernet, ATM, etc.

A solution MUST support unidirectional point-to-multipoint connectivity from a sender to multiple receivers. A sender CE is assured to send traffic to one or more receiver CEs. Receiver CEs include not only the CEs which are located at remote sites, but also the local CEs which are connected to the same sender-side PE. If there is only one receiver in the instance, it is considered equivalent to unidirectional point-to-point traffic.

A solution MUST support multiple sender topology in one VPMS instance, where a common receiver group is reachable from two or more senders. This means that a solution needs to support having multiple P2MP topologies in the backbone whose roots are located apart in a common service. For example, in Figure 2, traffic from sender CE1 and CE2 both reach receivers CE3 and CE4 while CE1, CE2, CE3 and CE4 all are associated with a single service. This topology is useful for increasing service reliability by redundant sources. Note that every receiver has only to have one AC connected to each PE to receive traffic. (in Figure 2, AC3 and AC4 respectively). Thus a solution will also need to support protection and restoration mechanism combining these multiple P2MP topologies. (See section 6.4 too).

-+ ---------------------------- +-<| CE2 | +-----+ | | | | +-----+ VPMS A | +------+ +------+ | VPMS A Sender +->|......>.. .............+..<......|<-+ Sender Tx | VPMS | . . . | VPMS | Tx | PE 1 | . . . | PE 2 | | | . . . | | +------+ . . . +------+ | . . . | | +.. . ...... . | | . . . . | | . . . . | | +-v----v-+ +-v----v-+ | ---| . . |---| . . |--- VPMS| . . | | . . |VPMS PE 3| . | | . |PE 4 +--------+ +--------+ v v AC3| |AC4 v v +-----+ +-----+ | CE3 | | CE4 | +-----+ +-----+ VPMS A VPMS A Receiver Receiver Figure 2: Multiple source support ]]>

There is a case that reverse traffic flow is necessary. A sender CE might sometimes want to receive traffic from a remote receiver CE. There are some usage scenarios about them, stream monitoring with a loopback manner, control channel which needs feedback communication etc. The simplest way to accomplish this is to provide different VPMS instances for reverse traffic: a sender CE behaves as a receiver of another instance. Figure 3 is illustrating this kind of a reverse traffic scenario, where CE1 is configured as a sender in VPMS A and a receiver in VPMS B. VPMS B is used for reverse traffic. Note that a closed single network here is composed of two VPMS instances. In operational perspective, CE1 and CE4 belong to the same closed "VPN" (e.g., CE1, CE2, CE3 and CE4 are the devices in one enterprise's intranet network) by administrative policy. Such two directions' instances can be easily created if two distinct ACs are provisioned for sending and receiving exclusively (e.g., if VLAN id in dot1Q tagged frame is a service delimiter, different VLAN ids are uniquely allocated for Tx and Rx). This approach is acceptable if a receiver CE device can change Layer 2 interface appropriately in data transmitting and receiving. Meanwhile it is also true that this might be considered a limitation in some deployment scenarios. If a CE is an IP router or Ethernet bridge, reverse traffic is normally supposed to come back from the same interface of the receiver CE. (i.e., the same VLAN id is to be used for reverse traffic if the AC supports dot1Q tagged frame.) Therefore, in a VPMS solution, both of the two type of ACs, sending (Tx) and receiving (Rx), SHOULD be allowed to be placed in the same physical/virtual circuit. In Figure 3, suppose AC5 of VPMS A is provisioned as {VLAN id = 100, direction= Rx}. It is expected that operators can provision AC6 of VPMS B in the same physical port as {VLAN id = 100, direction = Tx} or as {VLAN id = 101, direction = Tx}. That is, the combination between VLAN id and the flow direction is now considered to be a service delimiter. Note, in today's most implementations of VPWS, every AC is always considered bidirectional and a unique Layer 2 header/circuit (ATM VPI/VCI, an Ethernet port, a VLAN etc.) is considered service delimiter. In contrast in VPMS, every AC is considered unidirectional and traffic direction is an additional element to identify a unique AC.

Tx VPMS A| | VPMS B Receiver AC1 v ^ AC2 +----------+ VPMS | . . | PE1 | . ... | -------| . . |-------- | +-v------^-+ | | . . | | + . | +------+ . . . . +------+ +-<|......<.. . .. . ......>..... |>-+ | | VPMS | . . | VPMS | | AC3| | PE2 | . . | PE3 | |AC4 | +------+ . . +------+ | +-----+ | | . . | | +-----+ | CE2 |<--+ | Routed . . | +-->| CE3 | +-----+ <-- | Backbone. . | --> +-----+ VPMS A Rx | +-v------^-+ | Rx VPMS A Receiver -------| . . |-------- Receiver | . ... | | . . | VPMS +----------+ PE4 AC5v ^AC6 | | <-- Tx VPMS B +-----+ | +----------------<| CE4 | +------------------->+-----+ --> Rx VPMS A VPMS A Receiver VPMS B Sender Figure 3: Reverse traffic support ]]>

A solution is intended to provide Layer 2 protocol transparency. A VPMS solution SHOULD NOT require any special packet processing by the end users. Note that if VLAN Ids are assigned by the SP, VLAN Ids are not transparent. Transparency does not apply in ATM or other similar service cases, either.

A customer requires that the VPMS service provide the QoS guaranteed. In particular, for real time application which is considered common in point-to-multipoint delivery, delay and loss sensitive traffic MUST be supported. The solution SHOULD provide native QoS technique for service class differentiation, such as IEEE 802.1p CoS for Ethernet. For bandwidth committed services (e.g., ATM CBR), a solution SHOULD guarantee end-to-end bandwidth. It MAY provide flow admission control mechanisms to achieve that.

A solution MUST provide protection and restoration mechanism for end-to-end services. A solution MUST allow dual-homed redundant access from a local CE to multiple sender PEs. Additionally, a solution SHOULD provide protection mechanism between different sender PEs. This is because when an ingress PE node fails whole traffic delivery will fail unless backup sender PE is provided, even in case of dual-homed access. Similarly, if an egress PE node fails, traffic toward that CE never comes unless backup egress PE is provided. Consequently, a solution SHOULD provide protection mechanism between different receiver PEs too. Figure 4 is an example for this access topology. When dual-homed access to sender PEs is provided, a sender CE MAY transmit just one single traffic to either one of two sender PEs, or transmit dual traffic to the both PEs simultaneously. The latter scenario is usually applicable when a source device has only simple forwarding capability without any switchover functionality. Note that it consumes more resources at CE-PE than single case. In the dual traffic case, the backup side of ingress PE SHOULD be able to filter unnecessary traffic in normal condition. Also in either case, single traffic or dual traffic, the protection mechanism of ingress PEs described in the previous paragraph will be necessary to handle traffic appropriately. In case of dual-homed access to receiver PEs, a receiver CE MAY receive single traffic from either one of two sender PEs, or receive dual traffic from both PEs simultaneously. It might be needed to support switchover mechanism between egress PEs in failure. Dual traffic approach is applicable if CE has fast switchover capability as a receiver, but note that additional traffic resources are always consumed at PE-CE.

|VPMS| |VPMS|------------+ | PE2| Routed | PE3| \ +----+ Backbone +----+\ | AC3 / | | \ AC5 v +-----+ / | | \ +-----+ + CE2 +<-+ | | \ | CE3 | +-----+ | +----+ | \ +-----+ VPMS A ----|VPMS|--------- \ VPMS A Receiver | PE4| | Receiver +----+ | | AC6 v \ +-----+ +--------------->| CE4 | +-----+ VPMS A Receiver (dual-homed) Figure 4: Dual homing support ]]>

The basic security requirement raised in Section 6.5 of also applies to VPMS. In addition, a VPMS solution MAY have the mechanisms to activate the appropriate filtering capabilities (for example, MAC/VLAN filtering etc.), and it MAY be added with the filtering control mechanism between particular sender/receiver site inside a VPMS instance (for example, In Figure 1, filtering can be added on such that traffic from CE1 to CE4 and CE5 is allowed but traffic from CE1 to CE6 is filtered.)

A solution SHOULD prevent Layer 2 frame reordering when delivering customer traffic as much as possible.

A solution MAY provide the information to the customer about failures. For example, if there is a loss of connectivity toward either some of receiver CEs, it is reported to a sender CE.

A VPMS solution MUST be designed to scale well with an increase in the number of any of the following metrics: the number of PEs (per VPMS instance and total in a SP network) the number of VPMS instances (per PE and total) the number of sender CEs (per PE, VPMS instance and total) the number of receiver CEs (per PE, VPMS instance and total) A VPMS solution SHALL document its scalability characteristics in quantitative terms. A solution SHOULD quantify the amount of state that a PE and a P device has to support. The scalability characteristics SHOULD include: the processing resources required by the control plane in managing PWs (neighborhood or session maintenance messages, keepalives, timers, etc.) the processing resources required by the control plane in managing PSN tunnels the memory resources needed for the control plane other particular elements inherent to each solution that impact scalability

A VPMS solution SHOULD provide an efficient replication that can contribute to save the bandwidth resource of SP's network. For supporting optimized replication, it is expected to take advantage of PW mechanisms that is capable of P2MP traffic. However, the detailed discussion of this type of PW is out of scope of this document. Specific requirements for such a PW extension is discussed in . This document does not raise any specific requirements for particular PSN tunneling scheme (point-to-point, point-to-multipoint and multipoint-to-multipoint) that is applied only to VPMS. Requirements for PSN tunnel that is used by P2MP PW is discussed in . In any case which type of PSN tunnel is used is dependent on individual deployment scenarios (e.g., which PSN protocol is available now in the core and how much network resources operators will want to optimize).

A solution SHOULD support auto-discovery methods that dynamically allow VPMS information to be discovered by the PEs to minimize the configuration steps. All of the requirements about discovery described in Section 7.3 of SHOULD be satisfied in VPMS as well. Auto-discovery will help operators' initial configuration of adding a new VPN (i.e., VPMS instance), adding/deleting new sender/receiver, and so on. The information related to remote sites will be as follows: Information about identifying VPMS instance PE router ID / IP address as location information Information about identifying Attachment Circuits and their associated group information to compose a unique service (i.e., VPMS instance). CE role in each VPMS (Sender and/or Receiver) SP-related information (AS number, etc. for inter-provider case) (Needs discussion, including showing example scenario.)

This section raises generic requirements for handling related information about remote sites after initial provisioning, for easing total operation in VPMS. A solution SHOULD provide a way to activate/deactivate administrative status of each CE/AC. After initial provisioning, SP might change connectivity configuration between particular CEs inside a single VPMS instance for operational reasons. This feature will be beneficial to help such a scenario. For example, in Figure 5, CE1, CE2, CE3, CE4 and CE5 (and their ACs) are initially provisioned for VPMS A. CE1 is a sender and CE2-CE5 are receivers. Traffic will usually flow from CE1 to all receivers, CE2, CE3, CE4 and CE5. For maintenance operation, application's request (e.g., stream program has changed) or some other reasons, suppose CE5 comes to need to be set administratively down. Then it becomes necessary to turn off traffic from PE1 to PE4 in the core as well as egress AC (PE4 to CE5). This operation must be appropriately distinguished from failure cases. When deactivating particular site backbone PSN/PW resources (e.g., admission control of PSN tunnel) MAY be released for that particular direction in order to provide bandwidth left to other services. In Figure 5, if CE3 comes to be administratively deactivated, and if RSVP-TE (including P2P and/or P2MP) is used for backbone PSN, then TE reserved resources from PE1 to PE3 is to be released. In addition, a solution SHOULD allow single-sided activating operation at a sender PE. In some scenarios, operators prefer centralized operation. This is often considered natural for one-way digital audio/video distribution application: SPs often want to complete their service delivery by a single operation at one source PE, not by multiple operations at many receiver PEs. Figure 5 illustrates this scenario, where SP has only to do single-sided operation at PE1 (source) to administratively activate/deactivate various connections from AC1 to AC3, AC4 and/or AC5. It is not needed to to operate PE3 and PE4 directly.

| CE3 | +-----+ | +----+ | +-----+ (not provisioned) ----|VPMS|--------- VPMS A Receiver | PE4| (receiving now) +----+ AC5 / \ AC4 +-----+ / \ +-----+ + CE5 +<----------+ +---------------->| CE4 | +-----+ +-----+ VPMS A Receiver VPMS A Receiver (receiving now) (not receiving) CE1/AC1: Administratively activated CE2/AC2: No VPMS provisioned CE3/AC3: Administratively activated CE4/AC4: Administratively deactivated CE5/AC5: Administratively activated Figure 5: Site activation and deactivation ]]>

A solution SHOULD support inter-AS scenario, where there are more than one provider is providing a common VPMS instance and VPN. More specifically, it is necessary to consider the case where some of the PEs that compose one VPMS belong to several different ASes.

TBD (for further study for next revision)

Security consideration will be covered by section 6.5. and section 7.7. (This is for further study for next revision.)

This document has no actions for IANA.

Many thanks to Ichiro Fukuda, Kazuhiro Fujihara, Ukyo Yamaguchi and Kensuke Shindome for valuable reviews and feedbacks.