Network Working Group                                          Y. Kamite
Internet-Draft                                        NTT Communications
Intended status: Informational                                 F. Jounay
Expires: July 23, 2009 January 14, 2010                                 France Telecom
                                                        B. Niven-Jenkins
                                                                      BT
                                                             D. Brungard
                                                                    AT&T
                                                                  L. Jin
                                                  Nokia Siemens Networks
                                                            Jan 19,
                                                           July 13, 2009

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

Status of this Memo

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

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on July 23, 2009. January 14, 2010.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document. 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.

Table of Contents

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

1.  Introduction

1.1.  Problem Statement

   [RFC4664] describes different types of Provider Provisioned Layer 2
   VPNs (L2 PPVPNs, or L2VPNs); 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 PWs 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).

   This document introduces a new service framework, reference model and
   functional requirements for VPMS by extending the existing framework
   [RFC4664] and requirements [RFC4665] for L2VPNs.

   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

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119] .

3.  Terminology

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

3.1.  Acronyms

   P2P:  Point-to-Point

   P2MP:  Point-to-Multipoint

   PW:  Pseudowire

   VPMS:  Virtual Private Multicast Service

   PE/CE:  Provider/Customer Edge

   P: Provider Router

   AC:  Attachment Circuit

   PSN:  Packet Switched Network

   SP:  Service Provider

   VPMS instance:  A service entity manageable in a VPMS that provides
      isolated service reachability domain to each CE.  It corresponds
      to a so-called "VPN" as a specific set of sites that allows
      communication.

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

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][RFC4762] 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 different receivers leaves is not always needed, and allowed.
   It might require extra efforts to guarantee this behavior in VPLS.
   And in some P2MP scenarios there no traffic from receiver leafs to sender is not always
   needed, either. 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).  Therefore VPWSes  VPWS (P2P services) are service) can be used between each Base
   Station and their corresponding controller and controller, nothing more is required.

   As far as synchronization in a PSN environment is concerned,
   different mechanisms can be are being considered to provide frequency and
   phase
   clock synchronization required in the 2G/3G Mobile environment to
   guarantee mobile handover and strict QoS.  One of them 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.  Consequently, with  With the current methods, the PE
   connected to the Master must setup and maintain as many VPWS (P2P) as their
   there are Slave elements, and the Master has to replicate the
   traffic.  A
   better more efficient solution to deliver the clock frequency
   would be to use a VPMS which supports P2MP traffic.  This may 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) but (P2P), only a single copy needs to be sent on
   the AC associated to the VPMS (P2MP).  It  Also, it may ease the
   provisioning process since only one source endpoint must needs to be
   configured at the Ingress PE.  This alleviated provisioning process would
   simplify the introduction of new Base Stations.  The main most significant
   gain of using VPMS would be to avoid that it avoids replication on the Master
   and hence save saves bandwidth
   consumed consumption by the synchronization traffic
   which typically requires the highest level of QoS.  This kind type of
   traffic will be competing with equivalent QOS QoS traffic like VoIP,
   which is why it is significant critical to be able to
   save efficiently use the slightest
   bandwidth.

5.  Reference Model

   The VPMS reference model is shown in Figure 1.

       +-----+ AC1                                     AC2 +-----+
       | CE1 |>---+     ------------------------      +--->| CE2 |
       +-----+    |    |      VPMS A's P2MP     |     |    +-----+
        VPMS A    |  +------+ VPMS A Connection    +------+  |    VPMS A
        Sender    +->|......>...+.......... >......|>-+    Receiver
                     | VPMS |   .           | VPMS |
                     | PE1  |   .    VPMS B           | 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 that allows communication. sites.  A
   single VPMS instance provides a unique unidirectional 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
   duplicate
   replicate frames so that the traffic source 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
   "sender"
   "root" (sender) or "receiver" "leaf" (receiver) not both.  That is, any  Any AC is associated
   with the role of either sending side (Tx) or receiving side (Rx) from
   the view of the CE.  Thus every  These will be named the root (sender) AC deals with unidirectional and
   leaf (receiver) AC respectively.  Unless reverse traffic
   flows.  A sender is
   optionally supported, a root AC does not have a capability of transmitting the transmit traffic back to a
   CE at upstream side.  Likewise side, likewise a receiver leaf AC does not have a capability of receive the traffic from
   a CE at downstream side.  In Figure 1, AC1 and AC3 are configured as senders
   root ACs while AC2, AC4, AC5 and AC6 are configured as receivers. leaf ACs.  In
   VPMS A, CE1 could send traffic via AC1, but and CE2 and CE5 could not send back receive
   the traffic.

   A CE which is locally connected to a sender root AC is called a sender root
   (sender) CE.  Also a CE which is locally connected to a receiver leaf AC is
   called a
   receiver leaf (receiver) CE.  However, such CEs's roles will not be
   managed directly in VPMS because the configured AC's role (sender (root or receiver)
   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, PEs P2MP tree-shaped reachability is given from a single root
   AC to several leaf ACs.  This will be connected 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 which may include 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.  The  That
   is, the sender CE has only to transmit one stream towards the PE and
   it does not have to replicate traffic.
   Also routed backbone provides IP or MPLS-enabled PSN tunnels for
   transporting the PW traffic.

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

   VPMS can support various Layer 2 protocol services such as Ethernet,
   ATM, etc.

6.  Customer Requirements

6.1.  Service Topology

6.1.1.  Point-to-Multipoint Traffic Support

   A solution MUST support unidirectional point-to-multipoint
   connectivity traffic
   from a sender CE to multiple receivers. receiver CEs.  A sender root CE is
   assured to can send
   traffic to one or more receiver leaf CEs.  Receiver  Leaf 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 root PE.  If there is only one receiver in the
   instance, it is considered equivalent to unidirectional point-to-point point-to-
   point traffic.

6.1.2.  Multiple Source  Reverse Traffic Support

   There are cases where a reverse traffic flow is needed.  A solution MUST support multiple sender topologies in one 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
   instance, where
   instances for reverse traffic, i.e. a common receiver group sender CE is reachable from two or a receiver of
   another VPMS instance.  However, provisioning different VPNs for a
   particular customer would make its management task more
   senders. complex.  It
   is desired to have an alternative solution for supporting reverse
   traffic flow.  This means that a section provides additional requirements for this
   optional capability.

   A VPMS solution needs to MAY support having multiple
   P2MP topologies in the backbone whose roots are located apart reverse traffic from a leaf AC to a root
   AC.  Each reverse path is basically given in a
   common service. P2P (unicast) manner.
   In other words, each leaf of the P2MP topology 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 only have a
   single sender, however multiple P2MP topologies can common field that enables themselves to
   be grouped managed together into in the same VPN.  Any PWs used for such
   connections are expected to be assigned a single common VPMS instance.  For example, instance ID.

   Note, a VPMS does not assume any-to-any multipoint reachability.
   Therefore, in Figure 2, principle, every leaf AC does not exchange traffic from sender CE1 and CE2 both reach receivers CE3 and CE4
   while CE1, CE2, CE3 and CE4 all are associated
   directly with other leaf ACs even if reverse traffic is supported.

   Figure 3 illustrates this kind of scenario, where CE1 is configured
   as a single service.
   This topology sender in VPMS A. AC1 is useful for increasing service reliability by
   redundant sources.  Note that every receiver has only 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 have one AC
   connected AC1.

   Other reverse P2P connections can be provided similarly. (from AC2 to each PE
   AC1 / from AC3 to receive traffic. (in 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 2, AC3 3,
   they are both passing through the same AC (AC1 and AC4
   respectively).  Thus a solution will 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 need to support protection possible that a
   root PE multiplexes two ore more reverse traffic from different
   leaves and restoration mechanism combining these multiple P2MP topologies.
   (See section 6.4 too). 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).

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

                       Figure 2: Multiple source support

6.1.3. 3: Reverse Traffic Support

   There are cases where a reverse traffic flow is necessary. support

6.2.  Transparency

   A sender
   CE might sometimes want to receive traffic from a receiver CE.  There
   are some usage scenarios for this, such as stream monitoring through
   a loopback mechanism, control channels which need feedback
   communication etc.  The simplest way to accomplish this solution is intended to provide
   different Layer-2 traffic transparency.
   Transparency SHOULD be supported per VPMS instances for reverse traffic, i.e. instance basis.  In other
   words, Layer 2 traffic can be transparently transported from a sender
   CE is a to receiver of another VPMS instance.

   Figure 3 illustrates this kind of reverse traffic scenario, where CE1
   is configured as a sender CEs in VPMS A and a receiver given instance.  Note, however, if service
   delimiting fields (VLAN Id 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 terms, CE1 and CE4
   belong to the same closed "VPN" by administrative policy (e.g., CE1,
   CE2, CE3 and CE4 are the devices Ethernet, VPI/VCI in one enterprise's intranet
   network).

   Such bi-directional instances can be easily created if two distinct
   ACs are provisioned for sending and receiving exclusively (e.g., if
   VLAN id ATM, DLCI in dot1Q tagged frame is a service delimiter, different VLAN
   ids FR
   etc.) are uniquely allocated for Tx and Rx).  This approach is
   acceptable if a receiver CE device can change assigned by the SP, the 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 expected to be received not necessarily
   transparent.  It will depend on the
   same interface as forward SP's choice if they are assigned
   at each AC.  Hence, it could be that some of receiver CEs are getting
   traffic on with different delimiting fields than the other receiver CE. (i.e., CEs.

   The VPMS solution SHOULD NOT require any special packet processing by
   the same
   VLAN id is to be used for reverse traffic if end users (CEs).

6.3.  Quality of Service (QoS)

   A customer may require that the AC supports dot1Q
   tagged frames.)

   Therefore, 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 VPMS solution, both 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 two type of ACs, sending
   (Tx) connection that can support
   protection and receiving (Rx), SHOULD be allowed restoration: (1) CE 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}. PE, (2) between PEs (3) inside
   core (PSN backbone).  It is expected that
   operators can provision AC6 of VPMS B in the same physical port as
   {VLAN id = 100, direction = Tx}.  That is, (3) is fulfilled by
   existing PSN protection mechanisms (e.g., RSVP-TE FRR).  Following
   subsections will cover the combination between
   VLAN id requirements for redundancy support for
   (1) and the flow direction is now considered (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 service
   delimiter.

   Note, common
   VPN.

   For example, in most implementations of VPWS today, every AC is always
   considered bidirectional 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 unique Layer 2 header/circuit (ATM
   VPI/VCI, an Ethernet port, a VLAN etc.) single VPMS instance.  This topology is considered reliable since there
   are redundant root PE/ACs.  At the service
   delimiter.  In contrast in VPMS, every AC is considered
   unidirectional egress side, PE3 and PE4 select
   traffic direction is an additional element from either root, PE1 or PE2.  Each leaf PE has one leaf AC
   only (AC3 attached to
   identify a unique AC. 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.

     +-----+   <-- Rx VPMS B AC2
     | CE1 |<----------------+
          +-----+--------------+ |>--------------------------------------------+
     +-----+                                             |
     AC1v  VPMS A                                        |
        |  Sender --> Tx VPMS A|    -----------------------------       |
        |           |           VPMS B Receiver       AC1 v  ^ AC2
                             +----------+ A's P2MP     |      |
        |        +------+       Connection-2   +------+  |
        +------->|......>..    .............+..<......|<-+
              Tx | VPMS | .    .            .  | PE1 VPMS | .   ... Tx
                 | PE 1 |
                      -------| .    . |--------            .  | PE 2 |       +-v------^-+
                 |      | .    .          |
                     |         +            .  |      |
                 +------+ .    .            .    .  +------+
                +-<|......<..
                    |     .    .  ..            .  ......>..... |>-+
                |     |
           VPMS | A's P2MP  +..  .  ......    .     | VPMS |  |
             AC3|  | PE2  |
           Connection-1   .    .        | PE3  |  |AC4
                |  +------+       .    .        +------+  |
      +-----+     |
                    |     .    .          |       |   +-----+
      | CE2 |<--+    | Routed       .    .     |       +-->| CE3
                    |
      +-----+ <--   +-v----v-+   +-v----v-+   | Backbone.
                     ---| .          |       --> +-----+
     VPMS A     Rx   |       +-v------^-+        |        Rx VPMS A
     Receiver         -------|   .  |---| .   .  |---
                    VPMS|  . |--------            Receiver
                             | .   ...   |   |  . .   |VPMS
                    PE 3|   .    | VPMS
                             +----------+ PE4
                            AC5v  ^AC6   |   .    |PE 4
                        +--------+   +--------+
                            v            v
                         AC3|            |AC4
                            v            v
                        +-----+       +-----+
                        | CE3 |  <-- Tx VPMS B  +-----+       |  +----------------<| CE4 |
                               +------------------->+-----+
                                --> Rx
                        +-----+       +-----+
                        VPMS A         VPMS A
                        Receiver
                                                   VPMS B Sender       Receiver

        Figure 3: Reverse traffic support

6.2.  Transparency

   A solution is intended to provide Layer 2 traffic transparency.
   Transparency SHOULD be honoured per VPMS instance basis.  In other
   words, Layer 2 traffic can be transparently transported from a sender
   CE to receiver CEs 4: Multiple P2MP connections in a given instance. Dual-homed Sender

   Note, however, if service
   delimiting fields (VLAN Id in Ethernet, VPI/VCI in ATM, DLCI in FR
   etc.) are assigned by SP, they are not transparent.  It depends on
   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.

   VPMS solution SHOULD NOT require any special packet processing supports dual-homed sender scenario by the
   end users (CEs).

6.3.  Quality of Service (QoS)

   A customer may require multiple
   root ACs, it is expected that the VPMS service provide the 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.  Protection and Restoration

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

6.4.1.  Dual-homed Access Support

   A solution MUST allow dual-homed redundant access from a CE to
   multiple PEs.  Additionally, can also be used in
   multi-source scenrio.  For example, suppose in TV provisioning
   scenario, a solution SHOULD provide protection
   mechanism between receiver CE has the different PEs fixed one interface to which a the leaf PE,
   and the CE is attached.  This
   is because when an ingress PE node fails whole needs to receive many TV channel traffic delivery will
   fail unless a backup sender PE is provided, even from two video
   servers (the two servers provide different TV channels).  The two
   video servers are in case different location.  In this case, there need
   two root ACs and the same number of dual-
   homed access.  Similarly, if an egress PE node fails, traffic toward
   that CE is never received unless a backup egress PE is provided.
   Figure 4 P2MP connections, which is an example for this access topology.
   similar to dual-homed sender case.

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

   When dual-homed access to sender 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 sender PEs, 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 ingress root (ingress) PE SHOULD be able to
   filter the incoming unnecessary traffic while active the other root PE is working.  Also in
   active.  In either case, single traffic or dual traffic, the protection
   switchover mechanism
   of ingress between root (ingress) PEs described in the previous subsection will be necessary to
   handle the traffic appropriately. appropriately in failure.

   In the case of dual-homed access to receiver leaf PEs, a solution MAY allow a
   receiver CE to receive a single copy of the traffic from either one
   of the two egress 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.

              +-----+
              | 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 4: Dual homing backup side.  Specifically in
   the single traffic case, it might be needed to support switchover
   mechanism between egress PEs in failure.

6.5.  Security

   The basic security requirement raised in Section 6.5 of [RFC4665]
   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 sites inside a VPMS instance.  For
   example, in Figure 1, filtering can be added such that traffic from
   CE1 to CE4 and CE5 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:

   -  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 root ACs / sender CEs (per PE, VPMS instance and
      total)
   -  the number of leaf ACs / 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

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]
   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 PEs and 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 only 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 now 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.

   All of the requirements on discovery described in Section 7.3 of
   [RFC4665] 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 to identify the VPMS instance
   -  PE router ID / IP address as location information
   -  Information to identify Attachment Circuits and their associated
      group information to compose a unique service (i.e., VPMS
      instance).
   -  AC role in each VPMS (Sender or Receiver)
   -  SP-related information (AS number, etc. for an inter-provider
      case)

   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 CE/AC. 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, CE1, CE3, CE4 AC1, AC3, AC4 and CE5 (and their ACs) AC5 are initially
   provisioned for VPMS A. CE2 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, CE4 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, CE3 AC3 is now administratively activated and receiving
   traffic.  However, if CE3 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 sender 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 receiver leaf (egress) PEs.
   Figure 5 illustrates this scenario, where a SP only has to do single-sided single-
   sided operation at PE1 (source) to administratively activate/deactivate 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   +----+
                     AC2 AC3
       (not provisioned) /  |                   |  \ AC3
              +-----+   /   |                   |   \   +-----+
              + CE2 +<-+    |                   |    +->| CE3 |
              +-----+       |    +----+         |       +-----+
           (not provisioned) receiving)   ----|VPMS|---------    VPMS A Receiver
                                 | PE4|              (receiving now)
                                 +----+
                              AC5 /  \  AC4
              +-----+            /    \                  +-----+
              + CE5 +<----------+      +---------------->| CE4 |
              +-----+                                    +-----+
          VPMS A Receiver                            VPMS A Receiver
          (receiving now)                             (not receiving)

                               CE1/AC1:

                                   AC1: Administratively activated
                               CE2/AC2:
                                   AC2: No VPMS provisioned
                               CE3/AC3:
                                   AC3: Administratively activated
                               CE4/AC4:
                                   AC4: Administratively deactivated
                               CE5/AC5:
                                   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 signalling 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 P2MP data transport in a VPMS instance.  If multiple
   sources
   root ACs are supported (i.e., multiple P2MP topologies connections are grouped
   together into a single VPMS instance), such tools MUST be able to
   perform distinguishing each P2MP topology. 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 (receiver (leaf PE or its AC), this fault
   status SHOULD be able to be monitored at sender root PE.  This will help an
   operator to monitor each receiver PEs/AC leaf PE/AC in a centralized manner; that is,
   a sender root PE can collect receiver-side leaf-side information.  How this status is
   transferred depends on a solution.

   In contrast, in case of sender-side failure (sender (root PE or its AC), this
   fault status SHOULD also be able to be monitored at receiver leaf PEs.  This
   will help an operator to troubleshoot at receiver leaf PEs (i.e., distinguish
   local AC's failure from remote upstream 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 receiver leaf ACs.

7.7.1.3.  Fault Isolation

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

7.7.2.  Testing

   A solution MUST provide a mechanism for testing each P2MP data
   connectivity and verifying the associated information in a VPMS
   instance.  The connectivity is between sender a root and all receiver ACs. 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 provided 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 each P2MP traffic. VPMS.

   A solution MUST provide access to:

   -  Traffic statistics (total traffic forwarded, incoming, outgoing,
      dropped, etc., by period of time)

   A solution SHOULD provide access to:

   -  Performance information related to traffic usage, e.g., one-way
      delay, one-way jitter, one-way loss, delay variations (the
      difference of various one-way delay from a particular sender root PE to
      multiple receiver leaf PEs) etc.

   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

   TBD (for further study for next revision)

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

   This document has no actions for IANA.

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 feedback. comments
   provided by Greg Mirsky and Yuji Tochio.

11.  References

11.1.  Normative References

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

   [RFC4026]  Andersson, L. and T. Madsen, "Provider Provisioned Virtual
              Private Network (VPN) Terminology", RFC 4026, March 2005.

11.2.  Informative References

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

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

   [RFC4664]  Andersson, L. and E. Rosen, "Framework for Layer 2 Virtual
              Private Networks (L2VPNs)", RFC 4664, September 2006.

   [RFC4665]  Augustyn, W. and Y. Serbest, "Service Requirements for
              Layer 2 Provider-Provisioned Virtual Private Networks",
              RFC 4665, September 2006.

   [RFC4761]  Kompella, K. and Y. Rekhter, "Virtual Private LAN Service
              (VPLS) Using BGP for Auto-Discovery and Signaling",
              RFC 4761, January 2007.

   [RFC4762]  Lasserre, M. and V. Kompella, "Virtual Private LAN Service
              (VPLS) Using Label Distribution Protocol (LDP) Signaling",
              RFC 4762, January 2007.

Authors' Addresses

   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