Framework and Requirements for Virtual Private Multicast Service (VPMS)

This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79.

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

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

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.

Abstract

This document provides a framework and service level requirements for Virtual Private Multicast Service (VPMS). VPMS is defined as a Layer 2 VPN service that provides point-to-multipoint connectivity for a variety of Layer 2 link layers across an IP or MPLS-enabled PSN. This document outlines architectural service models of VPMS and states generic and high level requirements. This is intended to aid in developing protocols and mechanisms to support VPMS.

1. Introduction
    1.1. Problem Statement
    1.2. Scope of This Document
2. Conventions used in this document
3. Terminology
    3.1. Acronyms
4. Use Cases
    4.1. Ethernet Use Case
    4.2. ATM-based Use Case
    4.3. TDM-based Use Case
5. Reference Model
6. Customer Requirements
    6.1. Service Topology
        6.1.1. Point-to-Multipoint Traffic Support
        6.1.2. Reverse Traffic Support
    6.2. Transparency
    6.3. Quality of Service (QoS)
    6.4. High Availability
        6.4.1. Dual-homed Access Support
        6.4.2. Single/Dual Traffic Support in Dual-homed Access
    6.5. Security
    6.6. Reordering Prevention
    6.7. Failure reporting
7. Service Provider Network Requirements
    7.1. Scalability
    7.2. Pseudo Wire Signaling and PSN Tunneling
    7.3. Discovering VPMS Related Information
    7.4. Activation and Deactivation
    7.5. Inter-AS Support
    7.6. Co-existence with Existing L2VPNs
    7.7. Operation, Administration and Maintenance
        7.7.1. Fault Management
        7.7.2. Testing
        7.7.3. Performance Management
    7.8. Security
8. Security Considerations
9. IANA Considerations
10. Acknowledgments
11. References
    11.1. Normative References
    11.2. Informative References
§ Authors' Addresses

1. Introduction

1.1. Problem Statement

[RFC4664] (Andersson, L. and E. Rosen, “Framework for Layer 2 Virtual Private Networks (L2VPNs),” September 2006.) 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 (L2) 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 them based on the existing L2VPN specifications.

In a VPWS, a SP can set up point-to-point connectivity per a pair of CEs but it is not possible to replicate traffic for point-to-multipoint services in the SP's network side. A SP could build multiple Pseudowires (PWs) independently and have the CEs replicate traffic over them, but this is not only inconvenient for the customer, it’s a waste of bandwidth resources.

In a VPLS, SPs can natively offer multipoint connectivity across their backbone. Although it is seemingly applicable for point-to- multipoint service as well, there remains extra complexity for SPs to filter unnecessary traffic between irrelevant sites (i.e., from a receiver PE to another receiver PE) because VPLS provides multipoint-to-multipoint connectivity between CEs. Moreover, VPLS's MAC-based learning/forwarding operation is unnecessary for some scenarios particularly if customers only need 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.

1.2. Scope of This Document

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 class of provider- provisioned Layer 2 Virtual Private Networks (L2VPN).

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 Service Provider's and the Customer's point of view.

2. Conventions used in this document

3. Terminology

3.1. Acronyms

4. Use Cases

4.1. Ethernet Use Case

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 (P2MP native Ethernet) services, for various applications such as IP- based delivery of TV broadcasting, content delivery networks, etc. Moreover, many digital audio/video devices (e.g., MPEG-TS, HD-SDI) that supports Ethernet interfaces are becoming available, which will make Ethernet P2MP service more common. Also there are some applications that naturally suited to 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 PSNs.

Currently VPLS [RFC4761] (Kompella, K. and Y. Rekhter, “Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling,” January 2007.)[RFC4762] (Lasserre, M. and V. Kompella, “Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling,” January 2007.) is able to give P2MP-type replication for Ethernet traffic. Native VPLS already supports this capability via a full mesh of PWs, and an extension to optimize replication is also proposed [I-D.ietf-l2vpn-vpls-mcast] 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 use unidirectional P2MP traffic, but may not always require any added complexity of MAC address management. In addition, VPLS is a service that essentially provides any-to-any connectivity between all CEs in a L2VPN as it emulates a LAN service. However, if only P2MP connectivity is required, the traffic between leaves is not allowed. It might require extra efforts to guarantee this behavior in VPLS. And in some P2MP scenarios there no traffic from leafs to root. In these cases, 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 for multiple multicast groups. All traffic from a particular Attachment Circuit (AC) will be forwarded toward the same remote receivers, even if the destination MAC address is changed. Basically in VPMS, destination MAC addresses are 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.

4.2. ATM-based Use Case

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 systems with point-to-multipoint PVPs/PVCs. The transport network supports replicating ATM cells in transit nodes to efficiently deliver programs to multiple terminals. For migrating such ATM-based networks onto IP/MPLS-based networks, VPMS is considered to be a candidate solution.

4.3. TDM-based Use Case

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 over a SP's network. VPMS is also considered to be a solution for such TDM applications that require point-to-multipoint topology.

One use case is TDM-based multicast video delivery. That is, data duplication is simply provided by Layer 1, without using upper layer's multicast protocols.

A second use case is TDM clock distribution scenario. In a PSN environment, the existing VPWS allows support for 2G/3G mobile backhauling (e.g. TDM traffic for GSM's Abis interface, ATM traffic for Release 99 UMTS's Iub interface). Currently, 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). VPWS (P2P service) can be used between each Base Station and their corresponding controller, nothing more is required.

As far as synchronization in a PSN environment is concerned, different mechanisms are being considered to provide frequency and phase synchronization required in the 2G/3G Mobile environment to guarantee mobile handover and strict QoS. One mechanism consists of using Adaptive Clock Distribution and Recovery. With this method a Master element distributes a reference clock frequency 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. With the current methods, the PE connected to the Master must setup and maintain as many VPWS (P2P) as there are Slave elements, and the Master has to replicate the traffic. A more efficient solution to deliver the clock frequency would be to use a VPMS which supports P2MP traffic. This would scale better than P2P services (VPWS) with regards to the forwarding plane at the Master since the traffic is no longer needs to be replicated to individual VPWSes (P2P), only a single copy needs to be sent on the AC associated to the VPMS (P2MP). Also, it may ease the provisioning process since only one source endpoint needs to be configured at the Ingress PE. This provisioning process would simplify the introduction of new Base Stations. The most significant gain of using VPMS would be that it avoids replication on the Master and hence saves bandwidth consumption by the synchronization traffic which typically requires the highest level of QoS. This type of traffic will be competing with equivalent QoS traffic like VoIP, which is why it is critical to be able to efficiently use the bandwidth.

5. Reference Model



    +-----+ AC1                                     AC2 +-----+
    | CE1 |>---+     ------------------------      +--->| CE2 |
    +-----+    |    |      VPMS A's P2MP     |     |    +-----+
     VPMS A    |  +------+ Connection    +------+  |    VPMS A
     Sender    +->|......>...+.......... >......|>-+    Receiver
                  | VPMS |   .           | VPMS |
                  | PE1  |   .           | PE2  |
               +-<|......<.. . ....+.....<......|<-+
               |  +------+   .     .     +------+  |
    +-----+    |    |        .     .         |     |    +-----+
    | CE4 |<---+    |Routed  .     . VPMS B's P2MP +---<| CE3 |
    +-----+ AC4     |Backbone.     . Connection     AC3 +-----+
     VPMS B         |        .     .         |          VPMS B
     Receiver       |      +-v-----v-+       |          Sender
                     ------| .     . |-------
                           | . VPMS. |
                           | . PE3 . |
                           +---------+
                             v     v       VPMS A:
                             |     |         Root AC  : AC1
                          AC5|     |AC6      Leaf AC  : AC2, AC5
                             v     v       VPMS B:
                        +-----+   +-----+    Root AC  : AC3
                        | CE5 |   | CE6 |    Leaf AC  : AC4, AC6
                        +-----+   +-----+
                        VPMS A     VPMS B
                        Receiver   Receiver

                  Figure 1: Reference Model for VPMS

A VPMS instance is defined as a service entity manageable in the VPMS architecture. A single VPMS instance provides an isolated service reachability domain to each CE, so it corresponds to a so-called "VPN" as it allows communication among a specific set of sites. A single VPMS instance provides a unique point-to-multipoint L2VPN service. In Figure 1, there are two VPMS instances shown, VPMS A and VPMS B. In principle, there is no traffic exchange allowed between these different instances, so they are treated as different VPNs.

In a VPMS, a single CE-PE link connection is used for transmitting frames for delivery to multiple remote CEs, with point-to-multipoint duplication. The SP's network (PE as well as P) has a role to replicate frames so that the sender's CE does not need to send multiple frames to individual receivers.

Like VPWS, an Attachment Circuit (AC) is provided to accommodate CEs in a VPMS. In a VPMS, an AC attached to a VPMS MUST be configured as "root" (sender) or "leaf" (receiver) not both. Any AC is associated with the role of either sending side (Tx) or receiving side (Rx) from the view of the CE. These will be named the root (sender) AC and leaf (receiver) AC respectively. Unless reverse traffic is optionally supported, a root AC does not transmit traffic back to a CE at upstream side, likewise a leaf AC does not receive traffic from a CE at downstream side. In Figure 1, AC1 and AC3 are configured as root ACs while AC2, AC4, AC5 and AC6 are configured as leaf ACs. In VPMS A, CE1 could send traffic via AC1, and CE2 and CE5 could receive the traffic.

A CE which is locally connected to a root AC is called a root (sender) CE. Also a CE which is locally connected to a leaf AC is called a leaf (receiver) CE. However, such CEs’s roles will not be managed directly in VPMS because the configured AC’s role (root or leaf) will automatically determine them.

Similarly, a PE which locally accommodates a root AC is called a root (sender) PE. A PE which locally accommodates a leaf AC is called a leaf (receiver) PE.

Basically there is a one-to-one mapping between an attachment circuit and a VPMS instance. For example, all traffic from CE1 to PE1 (thorough AC1) is mapped to VPMS A (to CE2 and CE5).

In a VPMS, P2MP tree-shaped reachability is given from a single root AC to several leaf ACs. This will be named a "P2MP connection" in this VPMS framework. P2MP connection is a logical entity between PE/ACs in a given VPMS instance that transfers unidirectional traffic transparently from one local ingress AC to one or more remote egress ACs.

Similar to other L2VPN mechanisms, the VPMS architecture is based on PWs which may be using through IP or MPLS-enabled PSN tunnels over a routed backbone. That is, every P2MP connection can be instantiated by PW technology that supports P2MP traffic optimization (i.e., P2MP PW. See section 7.2.). P2MP traffic optimization will provide the benefit of traffic replication for high bandwidth efficiency. That is, the sender CE has only to transmit one stream towards the PE and it does not have to replicate traffic.

Regarding end-to-end traffic topology between the ACs, a single VPMS instance (i.e., one VPN) may correspond to a single P2MP connection. In Figure 1, VPMS A (one instance) has one P2MP connection (from AC1 to AC2 and AC5). However, there is also a case that a single VPMS consists of two or more P2MP connections grouped, which is typically used for redundancy. The details are given in section 6.4.

6. Customer Requirements

6.1. Service Topology

6.1.1. Point-to-Multipoint Traffic Support

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

6.1.2. Reverse Traffic Support

There are cases where a reverse traffic flow is needed. A sender CE may need to receive traffic from receiver CEs. There are some usage scenarios for this, such as stream monitoring through a loopback mechanism, control channels which need feedback communication etc. A possible way to accomplish this is to provide different VPMS instances for reverse traffic, i.e. a sender CE is a receiver of another VPMS instance. However, provisioning different VPNs for a particular customer would make its management task more complex. It is desired to have an alternative solution for supporting reverse traffic flow. This section provides additional requirements for this optional capability.

A VPMS solution MAY support reverse traffic from a leaf AC to a root AC. Each reverse path is basically given in a P2P (unicast) manner. In other words, each leaf of the P2MP tree can individually send back traffic to the root. For this purpose a VPMS instance MAY have more than one reverse P2P connections as network entity; However, such network entities MUST have a common field that enables themselves to be managed together in the same VPN. Any PWs used for such connections are expected to be assigned a common VPMS instance ID.

Note, a VPMS does not assume any-to-any multipoint reachability. Therefore, in principle, every leaf AC does not exchange traffic directly with other leaf ACs even if reverse traffic is supported.

Figure 3 illustrates this kind of scenario, where CE1 is configured as a sender in VPMS A. AC1 is a root AC, and AC2/AC3/AC4 are leaf ACs. P2MP connection is given for forward traffic. Unidirectional P2P connection is also provided for reverse traffic from AC4 to AC1. Other reverse P2P connections can be provided similarly. (from AC2 to AC1 / from AC3 to AC1).

In this case, PEs need to deal with two types of traffic, locally-attached CE's sending (Tx) and receiving (Rx) flows. In Figure 3, they are both passing through the same AC (AC1 and AC4). But it is an implementation matter if Tx and Rx traffic are conveyed on the same physical link or separate links. It is also possible that a root PE multiplexes two ore more reverse traffic from different leaves and transmits it to an upstream CE over the same local link.

Note, in most implementations of VPWS today, every AC is always considered bidirectional. In contrast, in VPMS, every AC can be chosen unidirectional (if it is a totally unidirectional service), or bidirectional (if reverse traffic is supported).



       +-----+ <-- Rx   (bidirectional)
       | CE1 |--------------+
       +-----+ --> Tx       |
 VPMS A Sender              |
                        AC1 |
                          +----------+ VPMS
                          | . .      | PE1
                          | .  ....  |
                   -------| .      . |--------
                  |  P2MP +-v------^-+        |
               Connection   .      .          |
                 (forward)  +      .          |
                  |         .      .          |
                +------+  . . .    .        +------+
             +-<|......<..  .  ..  .  ......>..... |>-+
             |  | VPMS |    .      .        | VPMS |  |
          AC2|  | PE2  |    .      .        | PE3  |  |AC3
             |  +------+    .      .        +------+  |
   +-----+   |    |         .      . P2P      |       |   +-----+
   | CE2 |<--+    | Routed  .      . Connection       +-->| CE3 |
   +-----+ <--    | Backbone.      . (reverse)|       --> +-----+
  VPMS A     Rx   |       +-v------^-+        |        Rx VPMS A
  Receiver         -------| .      . |--------            Receiver
                          | .  ....  |
                          | . .      | VPMS
                          +----------+ PE4
                         AC4|
                            |
                            |           <-- Tx   +-----+
                            +--------------------| CE4 |
                        (bidirectional) --> Rx   +-----+
                                                 VPMS A
                                                 Receiver


                    Figure 3: Reverse traffic support

6.2. Transparency

A solution is intended to provide Layer-2 traffic transparency. Transparency SHOULD be supported per VPMS instance basis. In other words, Layer 2 traffic can be transparently transported from a sender CE to receiver CEs in a given instance. Note, however, if service delimiting fields (VLAN Id in Ethernet, VPI/VCI in ATM, DLCI in FR etc.) are assigned by the SP, the Layer 2 traffic is not necessarily transparent. It will depend on the SP’s choice if they are assigned at each AC. Hence, it could be that some of receiver CEs are getting traffic with different delimiting fields than the other receiver CEs.

The VPMS solution SHOULD NOT require any special packet processing by the end users (CEs).

6.3. Quality of Service (QoS)

A customer may require that the VPMS service provide guaranteed QoS. In particular, for real time applications which are considered common in point-to-multipoint delivery, delay and loss sensitive traffic MUST be supported. The solution SHOULD provide native QoS techniques 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.

6.4. High Availability

A solution MUST provide protection and restoration mechanism for end-to-end services to ensure high availability.

There are multiple parts of the connection that can support protection and restoration: (1) CE to PE, (2) between PEs (3) inside core (PSN backbone). It is expected that (3) is fulfilled by existing PSN protection mechanisms (e.g., RSVP-TE FRR). Following subsections will cover the requirements for redundancy support for (1) and (2).

6.4.1. Dual-homed Access Support

A solution MUST allow dual-homed redundant access from a CE to multiple PEs. This if beneficial to support reliable data delivery for customers. Figure 3 provides an example of this access topology. .


           +-----+
           | CE1 |--------------+
           +-----+               \
     VPMS A  |                   |
     Sender  |                   v AC1
 (dual-homed)|                 +----+
             |            -----|VPMS|--------
             |           |     | PE1|        |
             \           |     +----+        |
              \  AC2   +----+             +----+   AC4
               +------>|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 3: Dual-homing support

A solution SHOULD provide a protection mechanism between the redundant PEs to which a CE is dual-homed. This is because when an ingress root PE node fails whole traffic delivery will fail unless a backup root PE is provided, even in case of dual-homed access. Similarly, if an egress leaf PE node fails, traffic toward that CE is never received unless a backup leaf PE is provided.

In some cases, the data source is required to be highly reliable since it is often deployed as a centralized server that provides traffic to many receivers. Therefore, there is an additional requirement specifically about redundancy of root-side: each VPMS instance SHOULD be able to have multiple P2MP connections whose roots are located at separate root ACs. Those root ACs can be located at physically separate root PEs, whereas those trees will share common leaf ACs. This means that each P2MP connection has a single root AC, but several P2MP connections can be managed together inside a common VPN.

For example, in Figure 4, traffic from root AC1 and AC2 both reach receivers CE3 and CE4 while AC1, AC2, AC3 and AC4 all are associated with a single VPMS instance. This topology is reliable since there are redundant root PE/ACs. At the egress side, PE3 and PE4 select traffic from either root, PE1 or PE2. Each leaf PE has one leaf AC only (AC3 attached to PE3, and AC4 attached to PE4). Therefore, PEs will need to support PW protection and restoration mechanism so that two redundant P2MP connections are given among common ACs.





  +-----+ AC2
  | CE1 |>--------------------------------------------+
  +-----+                                             |
  AC1v  VPMS A                                        |
     |  Sender    -----------------------------       |
     |           |           VPMS A's P2MP     |      |
     |        +------+       Connection-2   +------+  |
     +------->|......>..    .............+..<......|<-+
           Tx | VPMS | .    .            .  | VPMS | Tx
              | PE 1 | .    .            .  | PE 2 |
              |      | .    .            .  |      |
              +------+ .    .            .  +------+
                 |     .    .            .     |
        VPMS A's P2MP  +..  .  ......    .     |
        Connection-1   .    .       .    .     |
                 |     .    .       .    .     |
                 |   +-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 4: Multiple P2MP connections in Dual-homed Sender

Note, if the solution supports dual-homed sender scenario by multiple root ACs, it is expected that such a mechanism can also be used in multi-source scenrio. For example, suppose in TV provisioning scenario, a receiver CE has the fixed one interface to the leaf PE, and the CE needs to receive many TV channel traffic from two video servers (the two servers provide different TV channels). The two video servers are in different location. In this case, there need two root ACs and the same number of P2MP connections, which is similar to dual-homed sender case.

6.4.2. Single/Dual Traffic Support in Dual-homed Access

When dual-homed access to root PEs is provided, a solution MAY allow a sender CE to transmit just a single copy of the traffic to either one of the two root (ingress) PEs or to transmit a copy of the traffic to both the PEs simultaneously. The latter scenario consumes more resource of CE-PE link than the single traffic scenario, but it is usually applicable when a source device has only a simple forwarding capability without any switchover functionality. In the dual traffic case, the backup root (ingress) PE SHOULD be able to filter the incoming unnecessary traffic while the other root PE is active. In either case, single traffic or dual traffic, the switchover mechanism between root (ingress) PEs will be necessary to handle traffic appropriately in failure.

In the case of dual-homed access to leaf PEs, a solution MAY allow a receiver CE to receive a single copy of the traffic from either one of the two leaf (egress) PEs, or receive a copy of the traffic from both PEs simultaneously. The dual traffic approach is applicable if CE has fast switchover capability as a receiver by selecting either one of incoming traffic, but note that additional traffic resources are always consumed at PE-CE link of backup side. Specifically in the single traffic case, it might be needed to support switchover mechanism between egress PEs in failure.

6.5. Security

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 sites inside a VPMS instance. For example, in Figure 1, filtering can be added such that traffic from CE1 to CE4/CE5 is allowed but traffic from CE1 to CE6 is filtered.

6.6. Reordering Prevention

A solution SHOULD prevent Layer 2 frame reordering when delivering customer traffic under normal conditions.

6.7. Failure reporting

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

7. Service Provider Network Requirements

7.1. Scalability

A VPMS solution MUST be designed to scale well with an increase in the number of any of the following metrics:

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.

7.2. Pseudo Wire Signaling and PSN Tunneling

A VPMS solution SHOULD provide an efficient replication that can contribute to optimizing the bandwidth usage required in a SP's network. For supporting efficient replication, it is expected to take advantage of PW and PSN mechanisms that are capable of P2MP traffic.

Regarding PW mechanism, [I‑D.ietf‑pwe3‑p2mp‑pw‑requirements] (JOUNAY, F., Niger, P., Kamite, Y., DeLord, S., and L. Martini, “Requirements for Point-to-Multipoint Pseudowire,” September 2008.) introduces P2MP PW concept and its requirements, showing two basic approaches of providing replication. One is SS (Single Segment)-PW model that provides replication by PSN tunnel such as P2MP LSP (i.e., by outer label layer), and the other is MS (Multi Segment)-PW model that provides replication by multiple interconnected PWs (i.e., by inner label layer). In either case, end-to-end P2MP topology (i.e., P2MP connection) in VPMS is common from the view of ACs. Requirements as a provider service specified in this document will be commonly applied regardless of P2MP PW's signaling model.

It is out of scope of this document how to extend and use PW mechanisms to realize P2MP connections. For example, it is under the scope of the solution work how to support forward/reverse traffic e.g., by a single PW signaling, coupling multiple PWs, or other ways.

This document does not raise any specific requirements for particular PSN tunneling schemes (point-to-point, point-to-multipoint and multipoint-to-multipoint) that is applied to VPMS. The actual type of PSN tunnel used in VPMS will be dependent on individual deployment scenarios (e.g., which PSN protocol is available in the core and how much of the network resources that operators will want to optimize).

7.3. Discovering VPMS Related Information

A solution SHOULD support auto-discovery methods that dynamically allow VPMS information to be discovered by the PEs to minimize the amount of configuration the SP must perform.

Auto-discovery will help operators' initial configuration of adding a new VPN (i.e., VPMS instance), adding/deleting new sender/receiver, and so on.

Following is an example scenario: by default, every PE will have the association among the information described above. Suppose a new PE having an AC is provisioned in the existing VPMS instance and this AC is configured as receiver. This information will be automatically discovered by the other existing remote PEs (i.e., ingress and egress PEs in the same VPMS instance). Once the ingress PE discovers this new PE/AC, it can automatically add it as the new leaf of P2MP topology according to P2MP PW signaling mechanism. This operation does not require any new configuration at the existing PEs.

Note that VPMS instance is created when one root PE and at least one leaf PE are added. In principle VPMS requires such minimum provisioning. Hence in dual-homing case of sender, only backup root PE can be dynamically added/deleted to/from VPMS without destroying the VPN.

( Editor's note: This might be under study, including auto-discovery requirement if any when multiple roots (sender-side PEs) exist.)

7.4. Activation and Deactivation

This section raises generic requirements for handling related information about remote sites after the initial provisioning to ease the total operation of VPMS.

A solution SHOULD provide a way to activate/deactivate the administrative status of each AC. After initial provisioning, a 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, AC1, AC3, AC4 and AC5 are initially provisioned for VPMS A. AC2 is not provisioned for any VPMSes. In VPMS A, CE1 is a sender and CE3, CE4 and CE5 are receivers. Traffic will usually flow from CE1 to all receivers, CE3, CE4 and CE5. However, for maintenance operation, application's request (e.g., stream program has changed) or some other reasons, AC4 needs to be set as administratively deactivated. Then it becomes necessary to turn off traffic from PE4 to CE4. This operation must be appropriately distinguished from failure cases.

When deactivating a particular site, backbone PSN/PW resources (e.g., admission control of PSN tunnel) MAY be released for that particular direction in order to provide that bandwidth to other services. In Figure 5, AC3 is now administratively activated and receiving traffic. However, if AC3 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 may be released.

In addition, a solution SHOULD allow single-sided activation operation at a root (ingress) PE. In some scenarios, operators prefer centralized operation. This is often considered natural for one-way digital audio/video distribution applications: SPs often want to complete their service delivery by a single operation at one source PE, not by multiple operations at many leaf (egress) PEs. Figure 5 illustrates this scenario, where a SP only has 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 perform operations on PE3 and PE4 directly.


           +-----+   AC1
           + CE1 +----------------+
           +-----+                |
     VPMS A Sender                |
           (sending now)          v
                               +----+
                          -----|VPMS|--------
                         |     | PE1|        |
                         |     +----+        |
                       +----+             +----+
                       |VPMS|             |VPMS|
                       | PE2|  Routed     | PE3|
                   AC2 +----+  Backbone   +----+ AC3
    (not provisioned) /  |                   |  \
           +-----+   /   |                   |   \   +-----+
           + CE2 +<-+    |                   |    +->| CE3 |
           +-----+       |    +----+         |       +-----+
        (not receiving)   ----|VPMS|---------    VPMS A Receiver
                              | PE4|              (receiving now)
                              +----+
                           AC5 /  \  AC4
           +-----+            /    \                  +-----+
           + CE5 +<----------+      +---------------->| CE4 |
           +-----+                                    +-----+
       VPMS A Receiver                            VPMS A Receiver
       (receiving now)                             (not receiving)

                                AC1: Administratively activated
                                AC2: No VPMS provisioned
                                AC3: Administratively activated
                                AC4: Administratively deactivated
                                AC5: Administratively activated

                    Figure 5: Site activation and deactivation

7.5. Inter-AS Support

A solution SHOULD support inter-AS scenarios, where there is more than one provider 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.

7.6. Co-existence with Existing L2VPNs

A solution MUST co-exist with the existing L2VPNs (e.g., VPWS, VPLS) across the same SP's network. A solution MUST NOT impede the operation of auto-discovery and signaling mechanism that are already supported by the PEs for those existing L2VPNs.

7.7. Operation, Administration and Maintenance

7.7.1. Fault Management

7.7.1.1. Fault Detection

A solution MUST provide tools that detect reachability failure and traffic looping of data transport in a VPMS instance. If multiple root ACs are supported (i.e., multiple P2MP connections are grouped together into a single VPMS instance), such tools MUST be able to perform distinguishing each P2MP connection.

7.7.1.2. Fault Notification

A solution MUST provide fault notification and trouble tracking mechanisms. (e.g. SNMP-trap and syslog that notify fault to remote NMS.)

In VPMS one point of failure at upstream often affects a number of downstream PEs and ACs that might raise a notification message. Hence notification messages MAY be summarized or compressed for operators' ease of management.

In case of receiver-side failure (leaf PE or its AC), this fault status SHOULD be able to be monitored at root PE. This will help an operator to monitor each leaf PE/AC in a centralized manner; that is, a root PE can collect leaf-side information. How this status is transferred depends on a solution.

In contrast, in case of sender-side failure (root PE or its AC), this fault status SHOULD also be able to be monitored at leaf PEs. This will help an operator to troubleshoot at leaf PEs (i.e., distinguish local AC’s failure from remote root AC’s failure easily).

In any case of failure at SP’s network, fault information MAY be notified to the customer. Specifically, such fault MAY trigger generating customer OAM message toward CEs (e.g., AIS) and/or shutting down leaf ACs.

7.7.1.3. Fault Isolation

A solution MUST provide diagnostic/troubleshooting tools for data transport in a VPMS instance.

7.7.2. Testing

A solution MUST provide a mechanism for testing each data connectivity and verifying the associated information in a VPMS instance. The connectivity is between a root and all leaf ACs (i.e., each P2MP connection can be tested).

Operators will run testing before and after service activation. Testing mechanism SHOULD support end-to-end testing of the data path used by customer's data. End-to-end testing will have CE-to-CE path test and PE-to-PE path test. A solution MUST support PE-to-PE path test and MAY support CE-to-CE path test. In either case the minimum data path unit for each VPMS is unidirectional, hence if loopback testing is supported, additional consideration about reverse-path might also be needed (see section 6.1.3).

If there are multiple P2MP connections for redundancy (active/backup tree) in a common VPMS (like in Figure 4), testing mechanism MUST be able to check the connectivity over not only working P2MP connection but also protecting connection(s). This testing MUST be able to be performed from a root PE. It MAY also be able to be performed from a sender CE.

7.7.3. Performance Management

A solution MUST offer mechanisms to monitor traffic performance parameters and statistics of data traffic in VPMS.

All or part of this information SHOULD be made available through standardized SNMP MIB Modules (Management Information Base).

It is expected that such information can be used for SLA monitoring between sender and receiver, to give the SP a clear picture of current service providing to the customer.

7.8. Security

8. Security Considerations

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

9. IANA Considerations

10. Acknowledgments

Many thanks to Ichiro Fukuda, Kazuhiro Fujihara, Ukyo Yamaguchi and Kensuke Shindome for their ideas and feedback in documentation.

The authors gratefully acknowledge the valuable review and comments provided by Greg Mirsky and Yuji Tochio.

[RFC2119]	Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML).
[RFC4026]	Andersson, L. and T. Madsen, “Provider Provisioned Virtual Private Network (VPN) Terminology,” RFC 4026, March 2005 (TXT).

[I-D.ietf-l2vpn-vpls-mcast]	Aggarwal, R., Kamite, Y., Fang, L., and Y. Rekhter, “Multicast in VPLS,” draft-ietf-l2vpn-vpls-mcast-04 (work in progress), June 2008 (TXT).
[I-D.ietf-pwe3-p2mp-pw-requirements]	JOUNAY, F., Niger, P., Kamite, Y., DeLord, S., and L. Martini, “Requirements for Point-to-Multipoint Pseudowire,” draft-ietf-pwe3-p2mp-pw-requirements-00 (work in progress), September 2008 (TXT).
[RFC4664]	Andersson, L. and E. Rosen, “Framework for Layer 2 Virtual Private Networks (L2VPNs),” RFC 4664, September 2006 (TXT).
[RFC4665]	Augustyn, W. and Y. Serbest, “Service Requirements for Layer 2 Provider-Provisioned Virtual Private Networks,” RFC 4665, September 2006 (TXT).
[RFC4761]	Kompella, K. and Y. Rekhter, “Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling,” RFC 4761, January 2007 (TXT).
[RFC4762]	Lasserre, M. and V. Kompella, “Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling,” RFC 4762, January 2007 (TXT).

	Yuji Kamite
	NTT Communications Corporation
	Granpark Tower
	3-4-1 Shibaura, Minato-ku
	Tokyo 108-8118
	Japan
Email:	y.kamite@ntt.com

	Frederic Jounay
	France Telecom
	2, avenue Pierre-Marzin
	22307 Lannion Cedex
	France
Email:	frederic.jounay@orange-ftgroup.com

	Ben Niven-Jenkins
	BT
	208 Callisto House, Adastral Park
	Ipswich, IP5 3RE
	UK
Email:	benjamin.niven-jenkins@bt.com

	Deborah Brungard
	AT&T
	Rm. D1-3C22, 200 S. Laurel Ave.
	Middletown, NJ, 07748
	USA
Email:	dbrungard@att.com

	Lizhong Jin
	Nokia Siemens Networks
	Building 89, 1122 North QinZhou Road,
	Shanghai, 200211
	P.R.China
Email:	lizhong.jin@nsn.com

Framework and Requirements for Virtual Private Multicast Service (VPMS)draft-ietf-l2vpn-vpms-frmwk-requirements-01.txt

Status of this Memo

Copyright Notice