Internet DRAFT - draft-augustyn-vpls-arch


PPVPN Working Group                                  Waldemar Augustyn 
Internet Draft                                                         
Document: draft-augustyn-vpls-arch-00.txt           Tissa Senevirathne 
Category: Informational                             (Force10 Networks) 
November 2001                                            Himanshu Shah 
Expires: May 2002                                     (Tenor Networks) 
      Architecture and Model for Virtual Private LAN Services (VPLS) 
Status of this Memo 
   This document is an Internet-Draft and is in full conformance with 
   all provisions of Section 10 of RFC2026 [1].  
   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-
   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  
   The list of Internet-Draft Shadow Directories can be accessed at 
   For potential updates to the above required-text see: 
Summary for Sub-IP related Internet Drafts 
   PPPVPN Requirements, VPLS Requirements, See references.  
   This ID is intended for the PPVPN WG. 
Augustyn, et al.           Expires-May 2002                          1 
                   draft-augustyn-vpls-arch-00.txt      November 2001 
   PPVPN deals with provider provisioned VPNs.  This document describes 
   an architecture and model for Virtual Private LAN Services (VPLS), a 
   class of PPVPN. 
   This architecture and model document helps organizing the effort to 
   solve complex issues surrounding L2, broadcast domain network 
   services, such as VPLS.  There are several drafts related to VPLS 
   which describe certain aspects of the solution and which need a 
   common reference model.  There are more drafts that are indirectly 
   applicable to VPLS.  These, too, need a good reference for proper 
   evaluation and placement in the overall solution. 

1. Abstract. 

   This document describes the architecture and model for Virtual 
   Private LAN Services (VPLS), a class of L2 Provider Provisioned 
   Virtual Private Networks (PPVPN).  This model most closely resembles 
   LAN services that are attractive to many providers. It is intended 
   to facilitate the continuing effort to specify the set of protocols 
   and capabilities necessary for implementation of VPLS. 

2. Conventions used in this document. 

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
   this document are to be interpreted as described in RFC-2119 [2]. 

3. Introduction. 

   Layer 2 network services, that resemble behavior of Local Area 
   Networks, LANs, have always been attractive to providers. However, 
   the available technologies proved inadequate for building systems 
   that could support a large number of L2 broadcast domain customer 
   networks. A new approach was needed where technologies would be 
   developed from the grounds up specifically with support for L2, LAN-
   style services in mind. A concept for such system was originally 
   described in the VMI framework document [3], later crystallized and 
   closely scoped in the requirements document for Virtual Private LAN 
   Services (VPLS) [4]. A VPLS service is a class of Provider 
   Provisioned Virtual Private Network (PPVPN) [5]. 

Augustyn, et al.           Expires-May 2002                          2 
                   draft-augustyn-vpls-arch-00.txt      November 2001 
   A number of solutions targeting certain aspects of the VPLS service 
   have been proposed with several more are still remaining to be 
   properly addressed. The presented model is intended to serve as a 
   reference for the development of solutions comprising a full 
   implementation of VPLS. This model can also be useful in designing 
   service capabilities and features, as well as in planning commercial 
   business operations. 
   The focus is placed on the fundamental aspects of the service: 
        o Robust, many to many connectivity 
        o Orderly access to customer VPLS for value added services 
        o Multi-domain VPLS interconnect system 
        o Secure service operations 
        o Full control over customer traffic 

4. Network Reference Model. 

   There are two network reference models. The simpler one is intended 
   for designing core transport solutions.  The more general model 
   helps with developing service operations solutions. 
   All devices depicted in the model represent logical functions, not 
   physical units. An actual implementation may, of course, dedicate 
   several physical units for each particular function. Conversely, it 
   may combine functionality within a single physical device. 

4.1. Local Domain VPN Model. 

   This model is intended for testing basic transport capabilities. The 
   emphasis is placed on redundant configurations.  The solution must 
   work well with, and take full advantage of, the redundant paths in 
   the provider network as well as the mulitpath access to the customer 
   edge devices.  All requirements [4] with respect to unicast, 
   broadcast, multicast and unknown unicast must be met. 
   Figure 1 depicts a typical network scenario.  Starting from the 
   Customer side, there are two most prevalent connectivity styles: a 
   non-redundant single link access (CE2, CE3), and a redundant multi 
   home access (CE1).  In each case, the first node on the Provider 
   side plays a special role.  These are Provider Edge nodes (PE3, PE4, 
   PE5).  The other nodes on the Provider side do not directly attach 
   to Customers.  These are designated as simply Provider nodes (P1, 
   P2).  The connectivity within a Provider is arranged in a redundant 
   manner so that a removal of one node or link does not break 
   connectivity between Customer sites.  Of course, the non-redundant 
   single link to sites CE2 and C3 has a single failure point in PE5. 

Augustyn, et al.           Expires-May 2002                          3 
                   draft-augustyn-vpls-arch-00.txt      November 2001 
               :                                      : 
               : +-----+                              : 
               : | PE3 |            +----+            : 
              ---|     |------------| P2 |            : 
     +-----+ / : +-----+     -------|    |--          : 
     |     |-  :     \      /       +----+  \         : +-----+ 
     | CE1 |   :      ------------    /      \       ---| CE2 | 
     |     |-  :          /       \  /      +-----+ / : +-----+ 
     +-----+ \ :      +-----+    +----+     | PE5 |-  : 
              --------| PE4 |----| P1 |-----|     |-  : 
               :      +-----+    +----+     +-----+ \ : +-----+ 
               :                                     ---| CE3 | 
               :                                      : +-----+ 
   CE - Customer Edge Node 
   PE - Provider Edge Node 
   P  - Provider Node 
                      Fig. 1. Local Domain VPN Model 

4.2. Service Reference Model. 

   The more general Service Reference Model is intended for testing the 
   remaining aspects of the VPLS service: orderly access to customer 
   VPNs for value added services, multi-domain VPLS interconnections,  
   secure service operations, and control over customer traffic. 
   The typical scenario is depicted in Figure 2.  This model builds on 
   the Local Domain VPN by adding other representative elements. 
   A provider has an option to gain access to customer VPLS for the 
   purpose of offering additional services.  These could be L2 services 
   such as bridging between different VPLS segments, or it could be L3 
   and higher services such as DHCP, L3 VPN gateway, etc. One 
   distinctly important case is the access to the public Internet. A 
   provider can offer these services by becoming a virtual node on a 
   customer VPLS. For redundancy, the solution must be able to support 
   at least a pair of physical devices backing up each other. These 
   devices are represented as PS6 and PS7. 
   A complete VPLS solution cannot be limited to a single, closed, 
   local domain. The solution must support interconnection of different 
   VPLS domains, perhaps traversing third party carriers. A pair of 
   peering nodes, PP8 and PP9, represent the interface to another VPLS 
   domain.  As usual, the solution must support redundant connectivity 
   to the peer domains. 
   A VPLS solution must operate in a secure manner providing proper 
   separation of customer traffic and maintaining immunity from 

Augustyn, et al.           Expires-May 2002                          4 
                   draft-augustyn-vpls-arch-00.txt      November 2001 
   malformed or maliciously constructed packets sent by the customer. 
   One common topological complication  is a customer back-door 
   connection between sites that belong to the same VPLS. In Figure 2, 
   the  link between Customer sites CE2 and CE4 represents such a 
   situation.  The link is outside of provider's control. It may appear 
   and disappear at any time without notice.  To cover a more general 
   case, the link is shown to span sites belonging to different VPLS 
   Proper bandwidth management is critical to the stability of VPLS 
   networks.  The service reference model depicted in Figure 2 should 
   be used for evaluation bandwidth control mechanisms. 
               :                                      : 
               :       +-----+           +-----+      : +-----+ 
               :       |PP10 |           |PP11 |    ----| CE4 | 
               :       +-----+           +-----+      : +-----+ 
               :         | |  Peer Domain  | |        :    | 
               :.........|.|...............|.|........:    | 
                         | |               | |             | 
               ..........|.|...............|.|.........    | 
               :         | |               | |        :    | 
               :        +---+              | |        :    | back 
               :      --|PP8|------        | |        :    | door 
               :     /  +---+      \      +---+       :    | link 
               :    /         ------------|PP9|       :    | 
               : +-----+     /       \    +---+       :    | 
               : | PE3 |-----       +----+  /         :    | 
              ---|     |------------| P2 |--          :    | 
     +-----+ / : +-----+     -------|    |--          :    | 
     |     |-  :     \      /       +----+  \         : +-----+ 
     | CE1 |   :      ------------    /      \       ---| CE2 | 
     |     |-  :          /       \  /      +-----+ / : +-----+ 
     +-----+ \ :      +-----+    +----+     | PE5 |-  : 
              --------| PE4 |----| P1 |-----|     |-  : 
               :      +-----+    +----+     +-----+ \ : +-----+ 
               :         \        /  \        /      ---| CE3 | 
               :          \   ----    ----   /        : +-----+ 
               :           \ /            \ /         : 
               :          +---+          +---+        : 
               :          |PS6|          |PS7|        : 
               :          +---+          +---+        : 
   CE - Customer Edge Node 
   PE - Provider Edge Node 
   P  - Provider Node 
   PP - Provider Peering Node 
   PS - Provider Service Access Node 
                      Fig. 2. Service Reference Model 

Augustyn, et al.           Expires-May 2002                          5 
                   draft-augustyn-vpls-arch-00.txt      November 2001 

5. Node Functionality Reference Model. 

   The Service Reference Model designates distinct functionality to 
   certain representative nodes in the network. It useful to analyze 
   each node's function to determine whether standardization is 

5.1. CE Node Functional Model. 

   The VPLS service is transparent to customer edge nodes, CE. It is 
   sometimes referred to as PE-based. The CE is only a node on a VPLS 
   network and does not take any part in the operations of the VPLS 
   itself.  The CE could be a switch, a router, or even an end station.  
   The only function designated to the CE, as far as VPLS is concerned, 
   is the control of the demarcation point for the Customer. 
             v  ingress                        egress  ^ 
             |                                         | 
         +-------+                                 +-------+ 
         | DMRC  |    Demarcation Point Control    | DMRC  | 
         +-------+                                 +-------+ 
             |                                         | 
             +----------> . . . . . . . . . >----------+ 
                     Fig. 3. CE Node Functional Model 

5.1.1. Demarcation Point Control. 

   The Demarcation Point Control monitors, perhaps tests, the physical 
   connectivity to the provider. The details of the functionality and 
   the implementation are a local matter. 

5.2. PE Node Functional Model. 

   The PE node plays a prominent role in the implementation of the vPLS 
   service.  This is the node a customer has direct connectivity to, 
   hence there is always at least one logical PE node per each customer 
   site participating in a VPLS.  Most of the operational functionality 
   of VPLS is designated to this node. 

Augustyn, et al.           Expires-May 2002                          6 
                   draft-augustyn-vpls-arch-00.txt      November 2001 
             v  ingress                        egress  ^ 
             |                                         | 
         +-------+                                 +-------+ 
         | DMRC  |    Demarcation Point Control    | DMRC  | 
         +-------+                                 +-------+ 
             |                                         | 
         +-------+                                 +-------+ 
         | PCLSS |    Packet Classification        | PCLSS | 
         +-------+                                 +-------+ 
             |                                         | 
         +-------+                                 +-------+ 
         | HCONV |    Header Conversion            | HCONV | 
         +-------+                                 +-------+ 
             |                                         | 
         +-------+                                 +-------+ 
         | PDIS  |    Packet Discrimination        | PDIS  | 
         +-------+                                 +-------+ 
             |                                         | 
         +-------+                                 +-------+ 
         | QCTRL |    Quality of Service Control   | QCTRL | 
         +-------+                                 +-------+ 
             |                                         | 
         +-------+                                 +-------+ 
         | VFWD  |    VPLS Forwarding              | VFWD  | 
         +-------+                                 +-------+ 
             |                                         | 
         +-------+                                 +-------+ 
         | TFWD  |    Tunnel Forwarding            | TFWD  | 
         +-------+                                 +-------+ 
             |                                         | 
             +----------> . . . . . . . . . >----------+ 
                     Fig. 4. PE Node Functional Model 

5.2.1. Demarcation Point Control. 

   The demarcation point control function of PE is similar to that of a 
   CE node, i.e. making sure connectivity exists.  Unlike CE, the 
   functionality of the PE demarcation point is not a local matter. The 
   status of the link to the Customer is a critical item in the VPLS 
   operations management.  It is also a trigger for VPLS membership. 
   The demarcation point can be applicable to a single customer or to 
   an aggregate of several customers. 
   The PE demarcation point performs the following: 
   o Customer access monitoring and management  
   o Customer link monitoring 
   o L1 loopbacks 

Augustyn, et al.           Expires-May 2002                          7 
                   draft-augustyn-vpls-arch-00.txt      November 2001 
   The functionality of the PE demarcation point must be agreed upon. 

5.2.2. Packet Classification. 

   The PE deals with allocation of customers' packets to particular 
   VPLS segments.  Several criteria could be used: 
   o Interface number 
   o Layer 2 Classification  (MAC address, VLAN tag, p-bits, etc.) 
   o Layer 3 and above (IP address, port, protocol, TOS byte, etc.) 
   o Other criteria (packet length, time of day, etc.) 
   The type of classification must be agreed upon. 

5.2.3. Header Conversion. 

   Once a packet is classified as belonging to a particular VPLS, the 
   PE may elect to modify the header.  Typical conversions include: 
   o Header extension 
   o Header compression 
   o QTAG mapping 
   The type of conversion and the resulting header formats must be 
   agreed upon. 

5.2.4. Packet Discrimination. 

   The packet discrimination function validates packets and determines 
   whether they should be dropped or processed. It is represented here 
   logically as a single block even though its actions can take place 
   at more than one stage of packet processing.  There could be several 
   reasons for dropping packets. 
   o Duplicate packets 
   o Error packets 
   o Validation, such as Ethernet type, packet length, etc. 
   o Loop prevention and/or control 
   o Multilink control  (such as 802.1ad, etc.) 
   o Multi-homing control 
   o Access List or other policies  
   The discrimination criteria must be agreed upon. In many cases, it 
   is part of a protocol serving a particular objective, such as loop 
   prevention, or multi-homing.  In those cases, the related protocols 
   must be agreed upon as well. 

Augustyn, et al.           Expires-May 2002                          8 
                   draft-augustyn-vpls-arch-00.txt      November 2001 
5.2.5. Quality of Service Control. 

   The quality of service control in question refers to the particular 
   traffic characteristics, or priority mechanisms, committed to the 
   customer by the provider. The quality service control is per VPLS. 
   It includes:  
   o Queue allocation 
   o Policing 
   o Shaping 
   o Packet drop counts 
   o Committed Service Topology 
   o SLA parameters 
   The functionality of the quality service control must be agreed 

5.2.6. VPLS Forwarding. 

   The VPLS forwarding deals with all issues related to the transport 
   of packets within a VPLS. In this model, there are two forwarding 
   systems.  The VPLS forwarding deals only with VPLS specifics such as 
   unicast, unknown unicast, broadcast, multicast, etc.  It assumes the 
   existence of tunnels connecting relevant nodes.  VPLS forwarding is 
   also concerned with meeting SLA parameters such as bandwidth 
   requirements, priorities, etc.  Several important aspect must be 
   o Packet transfer method, data plane 
   o Packet transfer parameters and signaling, control plane 
   o MAC learning 
   o MAC caching 
   o Packet replication for broadcast/multicast 
   o End point discovery mechanisms 
   o End point add/delete 
   o Encryption, proxy encryption 
   In many cases, related protocols are defined.  All details of VPLS 
   forwarding, elected protocols, and packet formats must be agreed 

5.2.7. Tunnel Forwarding. 

   The tunnel forwarding deals with the transport capabilities of the 
   entire VPLS infrastructure. The tunnel forwarding is used by the 
   VPLS forwarding, discussed earlier. The tunnel forwarding is not 
   directly concerned with meeting any particular SLA requirements, 
   rather, it provides the robust infrastructure for VPLS forwarding.  
   Several important aspects must be addressed: 

Augustyn, et al.           Expires-May 2002                          9 
                   draft-augustyn-vpls-arch-00.txt      November 2001 
   o Packet transfer method, data plane 
   o Packet transfer parameters and signaling, control plane 
   o Infrastructure node discovery 
   o Infrastructure node add/delete 
   o Redundancy 
   o Failure restoration 
   o Graceful reconfiguration 
   o Hierarchical VPLS inter domain control 
   o Bandwidth/Resource quota allocation and control 
   o Path encryption 
   The tunnel forwarding may define related protocols.  All details of 
   tunnel forwarding, elected protocols, and packet formats must be 
   agreed upon. 

5.3. P Node Functional Model. 

   The P nodes do not have any specific function in the VPLS networks 
   other than participating in the tunnel forwarding. 
             v  ingress                        egress  ^ 
             |                                         | 
         +-------+                                 +-------+ 
         | TFWD  |    Tunnel Forwarding            | TFWD  | 
         +-------+                                 +-------+ 
             |                                         | 
             +----------> . . . . . . . . . >----------+ 
                      Fig. 5. P Node Functional Model 

5.3.1. Tunnel Forwarding. 

   Same considerations as in 5.2.7 above. 

5.4. PS Functional Model. 

   The Provider Service Access node employs all functionality that is 
   directly related to providing value added services. In many cases, a 
   customer VPLS will have a logical access point on that node. The 
   services range can be quite wide: 
   o Inter-VPLS connectivity 
   o VPLS extranet clearinghouse 
   o Access to public Internet  
   o Network services (DHCP, NAT, DNS, etc.) 
   o Security (Public Key management, Certificate server, etc.) 

Augustyn, et al.           Expires-May 2002                         10 
                   draft-augustyn-vpls-arch-00.txt      November 2001 
   The PS node, despite its distinguished function, plays a similar 
   role to the PE node. For that reason, all requirements under 5.2 
   above are applicable. 

5.5. PP Node Functional Model. 

   The PP nodes facilitates multi domain VPLS operations. Its primary 
   function is in the tunnel forwarding area.  Additionally, it has 
   demarcation control responsibility due to the direct connectivity to 
   another VPLS domain. 
             v  ingress                              egress  ^ 
             |                                               | 
         +-------+                                       +-------+ 
         | DMRC  |    Peer Demarcation Point Control     |  DMRC | 
         +-------+                                       +-------+ 
             |                                               | 
         +-------+                                       +-------+ 
         | TFWD  |    Tunnel Forwarding                  | TFWD  | 
         +-------+                                       +-------+ 
             |                                               | 
             +----------> . . . . . . . . . . . . >----------+ 
                     Fig. 6. PP Node Functional Model 

5.5.1. Peer Demarcation Point Control. 

   The peer demarcation control point function is similar to that of a 
   PE, i.e. making sure connectivity exists. In case of peer 
   demarcation, the customer could be another provider, or perhaps 
   another domain within the same provider.  In either case, this is an 
   aggregate demarcation point. The functionality incudes: 
   o Peer carrier access monitoring and administration 
   o Peer carrier link monitoring 
   o L1 loopbacks 
   The functionality of peer demarcation must be agreed upon. 

5.5.2. TFWD. Tunnel Forwarding. 

   The PP tunnel forwarding is similar to PE tunnel forwarding but 
   concentrates on exchange of necessary information for inter domain 
   o Hierarchical domain control 
   o Reachability information 
   o Peering method, policies 

Augustyn, et al.           Expires-May 2002                         11 
                   draft-augustyn-vpls-arch-00.txt      November 2001 
   Typically, related protocols are defined.  All details of PP tunnel 
   forwarding, elected protocols, and packet formats must be agreed 

6. Security Considerations. 

   This document does not discuss specific security solutions.  
   Applicable security requirements are presented in [Error! Bookmark 
   not defined.]. 

7. Acknowledgments. 

   The ongoing work at the IETF has greatly influenced the work 
   presented in this document. Authors wish to extend appreciations to 
   their respective employers and various other people who volunteered 
   to review this work and provided comments and feedback. 

8. References. 

   1. Bradner, S., "The Internet Standards Process -- Revision 3", BCP 
      9, RFC 2026, October 1996. 
   2. Bradner, S., "Key words for use in RFCs to Indicate Requirement 
      Levels", BCP 14, RFC 2119, March 1997. 
   3. Senevirathne, T., et. al., "Framework For Virtual Metropolitan 
      Internetworks (VMI)", Work in Progress, July 2001. 
   4. Augustyn, W., et al., "Requirements for Virtual Private LAN 
      Services (VPLS)", Work in Progress, October 2001. 
   5. Carugi, M., et al., "Service requirements for Provider 
      Provisioned Virtual Private Networks", Work in Progress, August 

9. Authors' Addresses. 

   Waldemar Augustyn 
   Tissa Senevirathne 
   Force10 Networks 
   1440 McCarthy Blvd  
   Milpitas, CA 95035 
   Phone: 408-965-5103  

Augustyn, et al.           Expires-May 2002                         12 
                   draft-augustyn-vpls-arch-00.txt      November 2001 
   Himanshu Shah 
   Tenor Networks, Inc. 
   100 Nagog Park 
   Acton, MA 01720 
   Phone 978-264-4900 
Full Copyright Statement 

   "Copyright (C) The Internet Society (2001). All Rights Reserved. 
   This document and translations of it may be copied and furnished to 
   others, and derivative works that comment on or otherwise explain it 
   or assist in its implementation may be prepared, copied, published 
   and distributed, in whole or in part, without restriction of any 
   kind, provided that the above copyright notice and this paragraph 
   are included on all such copies and derivative works. However, this 
   document itself may not be modified in any way, such as by removing 
   the copyright notice or references to the Internet Society or other 
   Internet organizations, except as needed for the purpose of 
   developing Internet standards in which case the procedures for 
   copyrights defined in the Internet Standards process must be 
   followed, or as required to translate it into languages other than 
   The limited permissions granted above are perpetual and will not be 
   revoked by the Internet Society or its successors or assigns. 
   This document and the information contained herein is provided on an 

Augustyn, et al.           Expires-May 2002                         13