[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01 02 draft-ietf-l2vpn-vpms-frmwk-requirements

Network Working Group                                          Y. Kamite
Internet-Draft                                        NTT Communications
Intended status: Informational                                 F. Jounay
Expires: January 5, 2009                                  France Telecom
                                                            July 4, 2008


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

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of 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 January 5, 2009.

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.







Kamite & Jounay          Expires January 5, 2009                [Page 1]


Internet-Draft       VPMS Framework and Requirements           July 2008


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Problem Statement  . . . . . . . . . . . . . . . . . . . .  3
     1.2.  Scope of This Document . . . . . . . . . . . . . . . . . .  3
   2.  Conventions used in this document  . . . . . . . . . . . . . .  4
   3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
     3.1.  Acronyms . . . . . . . . . . . . . . . . . . . . . . . . .  4
   4.  Use Cases  . . . . . . . . . . . . . . . . . . . . . . . . . .  4
     4.1.  Ethernet Use Case  . . . . . . . . . . . . . . . . . . . .  5
     4.2.  ATM-based Use Case . . . . . . . . . . . . . . . . . . . .  5
     4.3.  TDM-based Use Case . . . . . . . . . . . . . . . . . . . .  6
   5.  Reference Model  . . . . . . . . . . . . . . . . . . . . . . .  7
   6.  Customer Requirements  . . . . . . . . . . . . . . . . . . . .  9
     6.1.  Service Topology . . . . . . . . . . . . . . . . . . . . .  9
       6.1.1.  Point-to-Multipoint Support  . . . . . . . . . . . . .  9
       6.1.2.  Multiple Source Support  . . . . . . . . . . . . . . .  9
       6.1.3.  Reverse Traffic Support  . . . . . . . . . . . . . . . 10
     6.2.  Transparency . . . . . . . . . . . . . . . . . . . . . . . 12
     6.3.  Quality of Service (QoS) . . . . . . . . . . . . . . . . . 12
     6.4.  Protection and Restoration . . . . . . . . . . . . . . . . 13
     6.5.  Security . . . . . . . . . . . . . . . . . . . . . . . . . 14
     6.6.  Reordering Prevention  . . . . . . . . . . . . . . . . . . 14
     6.7.  Failure reporting  . . . . . . . . . . . . . . . . . . . . 15
   7.  Service Provider Network Requirements  . . . . . . . . . . . . 15
     7.1.  Scalability  . . . . . . . . . . . . . . . . . . . . . . . 15
     7.2.  Pseudo Wire Signaling and PSN Tunneling  . . . . . . . . . 15
     7.3.  Discovering VPMS Related Information . . . . . . . . . . . 16
     7.4.  Activation and Deactivation  . . . . . . . . . . . . . . . 16
     7.5.  Inter-AS support . . . . . . . . . . . . . . . . . . . . . 18
     7.6.  Operation, Administration and Maintenance  . . . . . . . . 18
     7.7.  Security . . . . . . . . . . . . . . . . . . . . . . . . . 19
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 19
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 19
   10. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 19
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 19
     11.2. Informative References . . . . . . . . . . . . . . . . . . 19
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
   Intellectual Property and Copyright Statements . . . . . . . . . . 21











Kamite & Jounay          Expires January 5, 2009                [Page 2]


Internet-Draft       VPMS Framework and Requirements           July 2008


1.  Introduction

1.1.  Problem Statement

   [RFC4664] describes different types of Provider Provisioned Layer 2
   VPNs (L2 PPVPNs, or L2VPNs); Some of them are widely deployed today,
   such as Virtual Private Wire Service (VPWS) and Virtual Private LAN
   Service (VPLS).  A VPWS is a VPN service that supplies a Layer 2
   point-to-point service.  A VPLS is an L2 service that emulates
   Ethernet LAN service across a Wide Area Network (WAN).

   For some use cases described hereafter, there are P2MP (point-to-
   multipoint) type services for Layer 2 traffic.  However, there is no
   straightforward way to realize it based on the existing L2VPN.

   In a VPWS, a SP can set up point-to-point connectivity per a pair of
   CEs but it is impossible to replicate traffic for point-to-multipoint
   in SP's network side.  Even though a SP builds multiple PWs
   independently and make CEs to replicate traffic over them, it is
   considered an inconvenient way for the customer and a waste of
   bandwidth resources.

   In a VPLS, SPs can naturally offer multipoint connectivity across
   backbone.  Although it is seemingly applicable for point-to-
   multipoint service as well, there remains extra work for SPs to
   filter unnecessary traffic between irrelevant sites (i.e., from a
   receiver PE to another receiver PE) because VPLS provides full-mesh
   multipoint-to-multipoint connectivity between CEs.  Moreover, VPLS's
   MAC-based learning/forwarding operation is considered unnecessary for
   some scenarios particularly if customers just want to have simple
   unidirectional point-to-multipoint service, or if they require non-
   Ethernet Layer 2 connectivity.

   Consequently, There is a real need for a solution that natively
   provides point-to-multipoint service in L2VPN.

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

   This document provides service definition and reference model, as
   well as functional requirements for VPMS.  It is intended to show a
   proper reference to introduce VPMS and a checklist of requirements
   that will provide a consistent way to evaluate how well each solution
   satisfies the requirements.



Kamite & Jounay          Expires January 5, 2009                [Page 3]


Internet-Draft       VPMS Framework and Requirements           July 2008


   This document introduces new service framework and requirements for
   VPMS within the context of L2VPN, on top of the existing framework
   [RFC4664] and requirements [RFC4665].

   The technical specifications are outside the scope of this document.
   There is no intent to specify solution-specific details.

   This document provides requirements from both the Provider's and the
   Customer's point of view.


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


4.  Use Cases





Kamite & Jounay          Expires January 5, 2009                [Page 4]


Internet-Draft       VPMS Framework and Requirements           July 2008


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 service which supports
   Ethernet traffic duplication, for various applications such as IP-TV
   broadcasting, contents delivery network, etc.  Moreover, many digital
   audio/video devices (e.g., MPEG-TS, HD-SDI) that supports Ethernet
   interfaces are getting available these days, which will make Ethernet
   P2MP service more common.  Also there are some applications that
   would prefer static transport of VPMS.  For example, MPEG-TS/IP/
   Ethernet in DVB-H is typically static broadcast without any signaling
   in the upstream direction.  VPMS could be a possible solution to
   provide these kinds of networking connectivity over PSN backbone.

   Currently VPLS [RFC4761][RFC4762] is able to give P2MP-type
   replication for Ethernet traffic.  Native VPLS already supports this
   capability with full mesh of PWs, and the extension to optimize
   replication is also proposed [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 require
   a unidirectional P2MP traffic, but may not always require any added
   expenses of MAC address management.  In addition, VPLS is a service
   that essentially provides any-to-any connectivity between all CEs in
   a VPN as it emulates a LAN service; however, if you want just P2MP
   connectivity, the traffic between different receivers is not always
   needed, and traffic from receiver to sender is not always needed,
   either.  In contrast, VPMS is a service that provides much simpler
   operation.

   Note that VPMS provides single coverage of receiver membership; that
   is, there is no distinct differentiation about multiple multicast
   groups.  Every traffic from a particular Attachment Circuit (AC) will
   flow toward the same remote receivers, even if the destination MAC
   address is changed.  Basically in VPMS, destination MAC addresses is
   not used for forwarding, which is significantly different from VPLS.
   If MAC-based forwarding is preferred (i.e., multicast/unicast
   differentiation of MAC address), VPLS should be chosen rather than
   VPMS.

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.



Kamite & Jounay          Expires January 5, 2009                [Page 5]


Internet-Draft       VPMS Framework and Requirements           July 2008


   Another use case of VPMS for ATM is for audio/video stream
   applications.  Today many digital TV broadcasting networks adopt ATM-
   based distribution system with point-to-multipoint PVP/PVCs.  Their
   transport network supports replicating ATM cells in transit nodes to
   efficently deliver programs to multiple terminals.  For migrating
   such ATM-based network onto IP/MPLS-based network, VPMS will be
   considered a candidate solution.

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

   In a PSN environment, the existing VPWS allows supporting 2G/3G
   mobile backhauling (e.g.  TDM traffic for GSM's Abis interface, ATM
   traffic for Release 99 UMTS's Iub interface).  At the time being, the
   Mobile backhauling architecture is always built as a star topology
   between the 2G/3G controller (e.g.  BSC or RNC) and the 2G/3G Base
   Stations (BTS or NodeB).  Therefore VPWSes (P2P service) are used
   between each Base Station and their corresponding controller and
   nothing more is required.

   As far as synchronization in a PSN environment is concerned,
   different mechanisms can be considered to provide frequency and phase
   clock required in the 2G/3G Mobile environment to guarantee mobile
   handover and strict QoS.  One of them consists in using Adaptive
   Clock Distribution and Recovery.  With this method a Master element
   distributes a reference clock at protocol level by regularly sending
   TDM PW packets (SAToP, CESoPSN or TDMoIP) to Slave elements.  This
   process is based on the fact that the volume of transmitted data
   arrival is considered as an indication of the source frequency that
   could be used by the Slave element to recover the source clock
   frequency.  Consequently, with the current methods, the PE connected
   to the Master must setup and maintain as many VPWS (P2P) as we have
   Slave elements, and the Master has to replicate the traffic.  A
   better solution to deliver the clock frequency would be to use a VPMS
   which supports P2MP traffic.  This may scale much more than P2P
   services (VPWS) with regards to the forwarding plane at the Master
   since the traffic is no more replicated to individual VPWSes (P2P)
   but only to the AC associated to the VPMS (P2MP).  It may ease the
   provisioning process since only one source endpoint must be
   configured at the Ingress PE.  This alleviated provisioning process
   would be particularly appreciated for the introduction of new Base
   Stations.  The main gain would be to avoid replication on the Master



Kamite & Jounay          Expires January 5, 2009                [Page 6]


Internet-Draft       VPMS Framework and Requirements           July 2008


   and hence save bandwidth consumed by the synchronization traffic
   which typically requires the highest level of QoS.  This kind of
   traffic will be competing with equivalent QOS traffic like VoIP, that
   is why it is significant to save the slightest bandwidth.


5.  Reference Model

   The VPMS reference model is shown in Figure 1.



         +-----+ AC1                                  AC2    +-----+
         | CE1 |>---+     ------------------------      +--->| CE2 |
         +-----+    |    |                        |     |    +-----+
          VPMS A    |  +------+ VPMS A        +------+  |    VPMS A
          Sender    +->|......>...+.......... >......|>-+    Receiver
                       | VPMS |   .           | VPMS |
                       | PE1  |   .    VPMS B | PE2  |
                    +-<|......<.. . ....+.....<......|<-+
                    |  +------+   .     .     +------+  |
         +-----+    |    |        .     .         |     |   +-----+
         | CE4 |<---+    |Routed  .     .         |     +---| CE3 |
         +-----+ AC4     |Backbone.     .         |     AC3 +-----+
          VPMS B         |        .     .         |          VPMS B
          Receiver       |      +-v-----v-+       |          Sender
                          ------| .     . |-------
                                | . VPMS. |
                                | . PE3 . |
                                +---------+
                                  v     v
                                  |     |
                               AC5|     |AC6
                                  v     v
                             +-----+   +-----+
                             | CE5 |   | CE6 |
                             +-----+   +-----+
                             VPMS A     VPMS B
                             Receiver   Receiver

                       Figure 1: Reference Model for VPMS

   A single VPMS unit provides isolated service reachability domains to
   each customer.  This unit is called a VPMS instance.  One VPMS
   instance corresponds to a unique unidirectional point-to-multipoint
   reachability.  In Figure 1, there are two VPMS instances shown, VPMS
   A and VPMS B. In principle, there are no traffic exchange allowed
   between these different instances.



Kamite & Jounay          Expires January 5, 2009                [Page 7]


Internet-Draft       VPMS Framework and Requirements           July 2008


   In a VPMS, a single CE-PE connection is used for transmitting frames
   to deliver multiple remote CEs, with point-to-multipoint duplication.
   SP's network (PE as well as P) has a role to duplicate frames so that
   source side does not need to send multiple frames to individual
   directions.

   In a VPMS, there are two types of CE.  One is sender, and the other
   is receiver.  A sender CE can send out traffic as a source into a
   VPMS instance.  A receiver CE can receive traffic from a sender site,
   but cannot receive from other receiver CEs.  A sender CE itself does
   not have capability of receiving traffic.

   Like VPWS, an Attachment Circuit (AC) is provided to accommodate CEs
   in a VPMS.  In a VPMS, an AC attached to VPMS MUST be configured as
   "sender" or "receiver" not both.  That is, any AC is associated with
   the role of either sending side (Tx) or receiving side (Rx) from the
   view of CE.  Thus every AC deals with unidirectional traffic flow.
   In Figure 1, AC1 and AC3 are configured as sending sides while AC2,
   AC4, AC5 and AC6 are as receiving sides.  CE1 could send traffic to
   VPMS A via AC1, but it could also receive traffic from VPMS B if
   another AC is connected to CE1.

   Basically there is one-to-one mapping between an attachment circuit
   and each customer's P2MP topology.  A unique VPMS instance
   corresponds to each topology.  For example, every traffic from CE1 to
   PE1 (thorough AC1) is mapped to VPMS A's topology (to CE2 and CE5).

   In the context of VPMS, one "VPN" as a specific set of sites that
   have been configured to allow communication, can be composed by one
   or more sets of VPMS instances.  By customer's administrative
   policies, sender and receiver CEs might be overlapped by multiple
   VPMS instances (for details, see Section 6.1. as an example).  A VPN
   will be finally defined by those VPMS instance sets.  In short, VPMS
   is defined just as a common point-to-multipoint (P2MP) delivery
   topology, and customer's administrative policy will determine the
   real VPN domain in the broad sense by picking up one or more VPMS
   instances.

   In a VPMS, PEs will be connected using PW technology which may
   include P2MP traffic optimization.  Such expected technique will
   benefit from the traffic replication for high bandwidth efficiency.
   Sender CE has only to transmit one stream toward PE, not duplicated
   traffic.  The backbone side is a IP or MPLS-enabled routed PSN.

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





Kamite & Jounay          Expires January 5, 2009                [Page 8]


Internet-Draft       VPMS Framework and Requirements           July 2008


6.  Customer Requirements

6.1.  Service Topology

6.1.1.  Point-to-Multipoint Support

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

6.1.2.  Multiple Source Support

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






















Kamite & Jounay          Expires January 5, 2009                [Page 9]


Internet-Draft       VPMS Framework and Requirements           July 2008


     +-----+ AC1                                         AC2+-----+
     | CE1 |>-+      ----------------------------        +-<| CE2 |
     +-----+  |     |                            |       |  +-----+
      VPMS A  |  +------+                      +------+  |    VPMS A
     Sender   +->|......>..    .............+..<......|<-+    Sender
              Tx | VPMS | .    .            .  | VPMS | Tx
                 | PE 1 | .    .            .  | PE 2 |
                 |      | .    .            .  |      |
                 +------+ .    .            .  +------+
                    |     .    .            .    |
                    |     +..  .  ......    .    |
                    |     .    .       .    .    |
                    |     .    .       .    .    |
                    |   +-v----v-+   +-v----v-+  |
                     ---| .   .  |---| .   .  |---
                    VPMS|  . .   |   |  . .   |VPMS
                    PE 3|   .    |   |   .    |PE 4
                        +--------+   +--------+
                            v            v
                         AC3|            |AC4
                            v            v
                        +-----+       +-----+
                        | CE3 |       | CE4 |
                        +-----+       +-----+
                        VPMS A         VPMS A
                        Receiver       Receiver


                       Figure 2: Multiple source support

6.1.3.  Reverse Traffic Support

   There is a case that reverse traffic flow is necessary.  A sender CE
   might sometimes want to receive traffic from a remote receiver CE.
   There are some usage scenarios about them, stream monitoring with a
   loopback manner, control channel which needs feedback communication
   etc.  The simplest way to accomplish this is to provide different
   VPMS instances for reverse traffic: a sender CE behaves as a receiver
   of another instance.

   Figure 3 is illustrating this kind of a reverse traffic scenario,
   where CE1 is configured as a sender in VPMS A and a receiver in VPMS
   B. VPMS B is used for reverse traffic.  Note that a closed single
   network here is composed of two VPMS instances.  In operational
   perspective, CE1 and CE4 belong to the same closed "VPN" (e.g., CE1,
   CE2, CE3 and CE4 are the devices in one enterprise's intranet
   network) by administrative policy.




Kamite & Jounay          Expires January 5, 2009               [Page 10]


Internet-Draft       VPMS Framework and Requirements           July 2008


   Such two directions' instances can be easily created if two distinct
   ACs are provisioned for sending and receiving exclusively (e.g., if
   VLAN id in dot1Q tagged frame is a service delimiter, different VLAN
   ids are uniquely allocated for Tx and Rx).  This approach is
   acceptable if a receiver CE device can change Layer 2 interface
   appropriately in data transmitting and receiving.

   Meanwhile it is also true that this might be considered a limitation
   in some deployment scenarios.  If a CE is an IP router or Ethernet
   bridge, reverse traffic is normally supposed to come back from the
   same interface of the receiver CE. (i.e., the same VLAN id is to be
   used for reverse traffic if the AC supports dot1Q tagged frame.)

   Therefore, in a VPMS solution, both of the two type of ACs, sending
   (Tx) and receiving (Rx), SHOULD be allowed to be placed in the same
   physical/virtual circuit.  In Figure 3, suppose AC5 of VPMS A is
   provisioned as {VLAN id = 100, direction= Rx}.  It is expected that
   operators can provision AC6 of VPMS B in the same physical port as
   {VLAN id = 100, direction = Tx} or as {VLAN id = 101, direction =
   Tx}.  That is, the combination between VLAN id and the flow direction
   is now considered to be a service delimiter.

   Note, in today's most implementations of VPWS, every AC is always
   considered bidirectional and a unique Layer 2 header/circuit (ATM
   VPI/VCI, an Ethernet port, a VLAN etc.) is considered service
   delimiter.  In contrast in VPMS, every AC is considered
   unidirectional and traffic direction is an additional element to
   identify a unique AC.























Kamite & Jounay          Expires January 5, 2009               [Page 11]


Internet-Draft       VPMS Framework and Requirements           July 2008


          +-----+   <-- Rx VPMS B
          + CE1 +<----------------+
          +-----+--------------+  |
    VPMS A Sender --> Tx VPMS A|  |
     VPMS B Receiver       AC1 v  ^ AC2
                             +----------+ VPMS
                             | .  .     | PE1
                             | .   ...  |
                      -------| .      . |--------
                     |       +-v------^-+        |
                     |         .      .          |
                     |         +      .          |
                   +------+  . . .    .        +------+
                +-<|......<..  .  ..  .  ......>..... |>-+
                |  | VPMS |    .      .        | VPMS |  |
             AC3|  | PE2  |    .      .        | PE3  |  |AC4
                |  +------+    .      .        +------+  |
      +-----+   |    |         .      .          |       |   +-----+
      | CE2 |<--+    | Routed  .      .          |       +-->| CE3 |
      +-----+ <--    | Backbone.      .          |       --> +-----+
     VPMS A     Rx   |       +-v------^-+        |        Rx VPMS A
     Receiver         -------| .      . |--------            Receiver
                             | .   ...  |
                             | .  .     | VPMS
                             +----------+ PE4
                            AC5v  ^AC6
                               |  |  <-- Tx VPMS B  +-----+
                               |  +----------------<| CE4 |
                               +------------------->+-----+
                                --> Rx VPMS A      VPMS A Receiver
                                                   VPMS B Sender

                       Figure 3: Reverse traffic support

6.2.  Transparency

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

6.3.  Quality of Service (QoS)

   A customer requires that the VPMS service provide the QoS guaranteed.
   In particular, for real time application which is considered common
   in point-to-multipoint delivery, delay and loss sensitive traffic
   MUST be supported.  The solution SHOULD provide native QoS technique



Kamite & Jounay          Expires January 5, 2009               [Page 12]


Internet-Draft       VPMS Framework and Requirements           July 2008


   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.

   A solution MUST allow dual-homed redundant access from a local CE to
   multiple sender PEs.  Additionally, a solution SHOULD provide
   protection mechanism between different sender PEs.  This is because
   when an ingress PE node fails whole traffic delivery will fail unless
   backup sender PE is provided, even in case of dual-homed access.
   Similarly, if an egress PE node fails, traffic toward that CE never
   comes unless backup egress PE is provided.  Consequently, a solution
   SHOULD provide protection mechanism between different receiver PEs
   too.  Figure 4 is an example for this access topology.

   When dual-homed access to sender PEs is provided, a sender CE MAY
   transmit just one single traffic to either one of two sender PEs, or
   transmit dual traffic to the both PEs simultaneously.  The latter
   scenario is usually applicable when a source device has only simple
   forwarding capability without any switchover functionality.  Note
   that it consumes more resources at CE-PE than single case.  In the
   dual traffic case, the backup side of ingress PE SHOULD be able to
   filter unnecessary traffic in normal condition.  Also in either case,
   single traffic or dual traffic, the protection mechanism of ingress
   PEs described in the previous paragraph will be necessary to handle
   traffic appropriately.

   In case of dual-homed access to receiver PEs, a receiver CE MAY
   receive single traffic from either one of two sender PEs, or receive
   dual traffic from both PEs simultaneously.  It might be needed to
   support switchover mechanism between egress PEs in failure.  Dual
   traffic approach is applicable if CE has fast switchover capability
   as a receiver, but note that additional traffic resources are always
   consumed at PE-CE.










Kamite & Jounay          Expires January 5, 2009               [Page 13]


Internet-Draft       VPMS Framework and Requirements           July 2008


              +-----+
              + 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 support

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 site inside a VPMS instance (for
   example, In Figure 1, filtering can be added on such that traffic
   from CE1 to CE4 and CE5 is allowed but traffic from CE1 to CE6 is
   filtered.)

6.6.  Reordering Prevention

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




Kamite & Jounay          Expires January 5, 2009               [Page 14]


Internet-Draft       VPMS Framework and Requirements           July 2008


6.7.  Failure reporting

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


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

   A VPMS solution SHALL document its scalability characteristics in
   quantitative terms.  A solution SHOULD quantify the amount of state
   that a PE and a P device has to support.

   The scalability characteristics SHOULD include:

   -  the processing resources required by the control plane in managing
      PWs (neighborhood or session maintenance messages, keepalives,
      timers, etc.)
   -  the processing resources required by the control plane in managing
      PSN tunnels
   -  the memory resources needed for the control plane
   -  other particular elements inherent to each solution that impact
      scalability

7.2.  Pseudo Wire Signaling and PSN Tunneling

   A VPMS solution SHOULD provide an efficient replication that can
   contribute to save the bandwidth resource of SP's network.  For
   supporting optimized replication, it is expected to take advantage of
   PW mechanisms that is capable of P2MP traffic.  However, the detailed
   discussion of this type of PW is out of scope of this document.
   Specific requirements for such a PW extension is discussed in
   [I-D.jounay-pwe3-p2mp-pw-requirements].

   This document does not raise any specific requirements for particular
   PSN tunneling scheme (point-to-point, point-to-multipoint and
   multipoint-to-multipoint) that is applied only to VPMS.  Requirements
   for PSN tunnel that is used by P2MP PW is discussed in



Kamite & Jounay          Expires January 5, 2009               [Page 15]


Internet-Draft       VPMS Framework and Requirements           July 2008


   [I-D.jounay-pwe3-p2mp-pw-requirements].  In any case which type of
   PSN tunnel is used is dependent on individual deployment scenarios
   (e.g., which PSN protocol is available now in the core and how much
   network resources operators will want to optimize).

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

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

   (Needs discussion, including showing example scenario.)

7.4.  Activation and Deactivation

   This section raises generic requirements for handling related
   information about remote sites after initial provisioning, for easing
   total operation in VPMS.

   A solution SHOULD provide a way to activate/deactivate administrative
   status of each CE/AC.  After initial provisioning, SP might change
   connectivity configuration between particular CEs inside a single
   VPMS instance for operational reasons.  This feature will be
   beneficial to help such a scenario.

   For example, in Figure 5, CE1, CE2, CE3, CE4 and CE5 (and their ACs)
   are initially provisioned for VPMS A. CE1 is a sender and CE2-CE5 are
   receivers.  Traffic will usually flow from CE1 to all receivers, CE2,
   CE3, CE4 and CE5.  For maintenance operation, application's request
   (e.g., stream program has changed) or some other reasons, suppose CE5
   comes to need to be set administratively down.  Then it becomes



Kamite & Jounay          Expires January 5, 2009               [Page 16]


Internet-Draft       VPMS Framework and Requirements           July 2008


   necessary to turn off traffic from PE1 to PE4 in the core as well as
   egress AC (PE4 to CE5).  This operation must be appropriately
   distinguished from failure cases.

   When deactivating particular site backbone PSN/PW resources (e.g.,
   admission control of PSN tunnel) MAY be released for that particular
   direction in order to provide bandwidth left to other services.  In
   Figure 5, if CE3 comes to be administratively deactivated, and if
   RSVP-TE (including P2P and/or P2MP) is used for backbone PSN, then TE
   reserved resources from PE1 to PE3 is to be released.

   In addition, a solution SHOULD allow single-sided activating
   operation at a sender PE.  In some scenarios, operators prefer
   centralized operation.  This is often considered natural for one-way
   digital audio/video distribution application: SPs often want to
   complete their service delivery by a single operation at one source
   PE, not by multiple operations at many receiver PEs.  Figure 5
   illustrates this scenario, where SP has only to do single-sided
   operation at PE1 (source) to administratively activate/deactivate
   various connections from AC1 to AC3, AC4 and/or AC5.  It is not
   needed to to operate PE3 and PE4 directly.






























Kamite & Jounay          Expires January 5, 2009               [Page 17]


Internet-Draft       VPMS Framework and Requirements           July 2008


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

                               CE1/AC1: Administratively activated
                               CE2/AC2: No VPMS provisioned
                               CE3/AC3: Administratively activated
                               CE4/AC4: Administratively deactivated
                               CE5/AC5: Administratively activated

                       Figure 5: Site activation and deactivation

7.5.  Inter-AS support

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

7.6.  Operation, Administration and Maintenance

   TBD (for further study for next revision)






Kamite & Jounay          Expires January 5, 2009               [Page 18]


Internet-Draft       VPMS Framework and Requirements           July 2008


7.7.  Security

   TBD (for further study for next revision)


8.  Security Considerations

   Security consideration will be covered by section 6.5. and section
   7.7.  (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 valuable reviews and feedbacks.


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-03 (work
              in progress), November 2007.

   [I-D.jounay-pwe3-p2mp-pw-requirements]
              JOUNAY, F., "Use Cases and signaling requirements for
              Point-to-Multipoint PW",
              draft-jounay-pwe3-p2mp-pw-requirements-01 (work in
              progress), November 2007.

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




Kamite & Jounay          Expires January 5, 2009               [Page 19]


Internet-Draft       VPMS Framework and Requirements           July 2008


   [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
   Tokyo Opera City Tower
   3-20-2 Nishi Shinjuku, Shinjuku-ku
   Tokyo  163-1421
   Japan

   Email: y.kamite@ntt.com


   Frederic Jounay
   France Telecom
   2, avenue Pierre-Marzin
   22307 Lannion Cedex
   France

   Email: frederic.jounay@orange-ftgroup.com



















Kamite & Jounay          Expires January 5, 2009               [Page 20]


Internet-Draft       VPMS Framework and Requirements           July 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.











Kamite & Jounay          Expires January 5, 2009               [Page 21]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/