Internet DRAFT - draft-andersson-ppvpn-l2-framework

draft-andersson-ppvpn-l2-framework



PPVPN Working Group                                     Loa Andersson 
Internet-Draft                                             Utfors AB 
                                                  Design team editor 
                                                                      
Expiration Date: December 2002                                        
                                                                      
                                                        26 June, 2002 
                                    
                         PPVPN L2 Framework 
           <draft-andersson-ppvpn-l2-framework-01.txt> 

Status of this Memo  

This document is an Internet-Draft and is in full conformance with all 
provisions of Section 10 of RFC2026 [RFC2026].   

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.  

For potential updates to the above required-text see: 
http://www.ietf.org/ietf/1id-guidelines.txt   

Summary for Sub-IP related Internet Drafts  

RELATED DOCUMENTS:   

This being a Layer 2 vpn framework document, almost every document that 
has been sent to the ppvpn working group is related, at least in that 
they address provider provisioned vpn's. Even more closely related are 
the documents that address L2 vpn's. The reference section includes a 
list of the document we found that most useful to illustrate the issues 
we discuss in this document.   

WHERE DOES IT FIT IN THE PICTURE OF THE SUB-IP WORK   

This ID is intended for the PPVPN WG.  



INTERNET-DRAFT     draft-andersson-ppvpn-l2-framework-01.txt    26.06.02 



Andersson                Expires Dec 2002                   [Page 2] 

WHY IS IT TARGETED AT THIS WG(s)   

PPVPN deals with provider provisioned VPNs. This document provides and a 
framework and architecture for Layer 2 Provider Provisioned Virtual 
Private Network services, a class of Provider Provisioned Virtual 
Private Networks services.      

JUSTIFICATION   

This document is a framework for Layer 2 VPNs, one of the main topics on 
the PPVPN WG charter, and is considered instrumental in progressing the 
standards work within the PPVPN group. 

Abstract  

This document provides a framework for Layer 2 Provider Provisioned 
Virtual Private Networks (PPVPNs). This framework is intended to aid in 
standardizing protocols and mechanisms to support interoperable Layer 2 
PPVPNs. 

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 RFC-2119 [RFC2119].  

Contents 

1.  Introduction........................................................ 4 
  1.1  Objectives and Scope of the Document ............................ 4 
  1.2  Layer 2 Virtual Private Networks ................................ 5 
  1.3  Terminology ..................................................... 5 

2.  Models.............................................................. 6 
  2.1  Reference Model for VPWS ........................................ 6 
  2.2  Reference Model for VPLS ........................................ 6 
  2.3  Reference Model for distributed  VPLS-PE or VPWS-PE.............. 7 
  2.4  VPWS-PE and VPLS-PE ............................................. 8 

3.  Functional Components of L2 VPN .................................... 8 
  3.1  Types of L2VPN................................................... 8 
  3.2  Generic L2VPN Transport Functional Components................... 10 
  3.3  VPWS............................................................ 20 
  3.4  VPLS............................................................ 26 
  3.5  IP-only LAN-like Service (IPLS) ................................ 32 

4.  Security Considerations ........................................... 33 
  4.1  System security ................................................ 33 
  4.2  Access Control.................................................. 33 


INTERNET-DRAFT   draft-andersson-ppvpn-l2-framework-01.txt      26.06.02 



Andersson                Expires Dec 2002                   [Page 3] 

     4.3  Endpoint authentication ..................................... 33 
     4.4  Data Integrity............................................... 33 
     4.5  Confidentiality ............................................. 33 
     4.6  User data and Control data .................................. 33 

5.  References......................................................... 33 

6.  Acknowledgements .................................................. 36 

7.  Authors Contact ................................................... 37 

 

 
































INTERNET-DRAFT   draft-andersson-ppvpn-l2-framework-01.txt      26.06.02 



Andersson                Expires Dec 2002                   [Page 4] 


 

1.  Introduction 

1.1  Objectives and Scope of the Document 

This document provides a framework for Layer 2 Provider Provisioned 
Virtual Private Networks (PPVPNs).  This framework is intended to aid in 
standardizing protocols and mechanisms to support interoperable Layer2 
PPVPNs. 

The PPVPN WG group works with both Layer 3 PPVPNs and Layer 2 PPVPNs. A 
framework for L3 VPNs is found in [L3VPN-FW]. This document provides the 
same type of framework for Layer 2 PPVPNs as the Layer 3 framework does 
for Layer 3 PPVPNs.   

The term "provider provisioned VPNs" refers to Virtual Private Networks 
(VPNs) for which the Service Provider (SP) participates in management 
and provisioning of the VPN. 

There are multiple ways in which a provider can participate in a VPN, 
and there are therefore multiple different types of PPVPNs.  The 
framework document discusses Layer2 VPNs (as defined in section 1.2).  
It also describes technical issues related to VPNs in which the provider 
participates in provisioning for provider edge and customer edge 
devices. 

First, this document discusses reference models for Layer 2 PPVPNs. Then 
the functional components of Layer2 PPVPN operations are discussed. 

Specifically, this includes discussion of the technical issues, which 
are important in the design of standards and mechanisms for support of 
Layer 2 PPVPNs.  Furthermore, technical aspects of Layer2 PPVPNs 
interworking is clarified.  Finally, security issues as they apply to 
Layer2 PPVPNs are addressed. 

Requirements for Layer 3 VPNs are found in [L3VPN-REQ] and for Layer 2 
VPNs, for VPLS and VPWS, in [L2VPN-REQ]. 

This document has "inherited" a substantial content from "An 
Architecture for L2VPNs" [L2VPN-ARCH]. 

This document does not make choices, and does not select any particular 
approach to support VPNs.  




INTERNET-DRAFT   draft-andersson-ppvpn-l2-framework-01.txt      26.06.02 



Andersson                Expires Dec 2002                   [Page 5] 

1.2  Layer 2 Virtual Private Networks 

As Layer 2 provider provisioned VPN solutions has attracted more and 
more interest, several solutions has been proposed to the PPVPN WG. This 
document addresses the generic components relevant for every Layer 2 VPN 
but will not make any recommendations on the relative merits of how the 
different components are implemented. 

In [ANDERSSON-METRICS] parameters and metrics that could be used to 
compare different Layer 2 VPN solutions and how they could be evaluated 
when a L2 VPN has to meet different set of requirements is discussed. 
The parameters to be considered in evaluating L2 VPN implementations in 
different environments are e.g. scaling, cost, inter-domain 
reachability, provisioning, flexibility, integration and migration from 
existing infrastructure and services, value-added services, cost, etc. 

Currently we see two kinds of services that a service provider could 
offer to a customer by means of Layer 2 VPNs. Virtual Private Wire 
Service(VPWS)and a Virtual Private LAN Service (VPLS). The possibility 
of an IP-only LAN-like Service (IPLS) is opened up, but is very much for 
future study. 

A VPWS is a VPN service that supplies a L2 point-to-point service. Being 
a point-to-point service where there are very few scaling issues with 
the service as such. Scaling issues might arise from the number of end-
points that can be supported on a particular PE. 

A VPLS is an L2 service that in all respects emulates LAN across a Wide 
Area Network (WAN). Thus it also has all the scaling characteristics of 
a LAN. Other scaling issues might arise from the number of end-points 
that can be supported on a particular PE.  

1.3   Terminology 

This document list some terms and concepts that are specific to the L2 
VPN framework, terms and concepts generally applicable to the PPVPN area 
will be found in [ANDERSSON-TERM].  












INTERNET-DRAFT   draft-andersson-ppvpn-l2-framework-01.txt      26.06.02 



Andersson                Expires Dec 2002                   [Page 6] 

2.  Models 

2.1   Reference Model for VPWS 
                   Attachment        PSN           Attachment 
                Circuits        tunnel          Circuits 
                                  +  
        +-----+                 pseudo                    +----- + 
        |     |                  wire                     |     | 
        | CE1 |--+                                     +--| CE2 | 
        |     |  |    +-----+   +-----+     +-----+    |  |     | 
        +-----+  +----|---- |   |  P  |     | ----+----+  +----- + 
                      |VPWS\|---|-----|-----|/VPWS| 
                      | PE1 |===|=====|=====| PE2 | 
                      |    /|---|-----|-----|\    | 
        +-----+  +----|---- |   |     |     | ----|----+  +----- + 
        |     |  |    +-----+   +-----+     +-----+    |  |     | 
        | CE3 |--+                                     +--| CE4 | 
        |     |                                           |     | 
        +-----+                                           +----- + 

 

2.1.1 Entities in the VPWS reference model 

The P, PE (VPWS-PE) and CE devices and the PSN tunnel as defined in 
[ANDERSSON-TERM]. Attachment circuit and pseudo wire as discussed in 
section 3. The PE does a simple mapping between the PW and attachment 
circuit based on local information, i.e. the PW de-multiplexor and 
incoming/outgoing logical/physical port. 

2.2  Reference Model for VPLS 

The following diagram shows a VPLS reference model where PE devices that 
are VPLS-capable provide a logical interconnect such that CE devices 
belonging to a specific VPLS appear to be connected by a single logical 
Ethernet bridge. A VPLS can contain a single VLAN or multiple, tagged 
VLANs. 

 






INTERNET-DRAFT   draft-andersson-ppvpn-l2-framework-01.txt      26.06.02 



Andersson                Expires Dec 2002                   [Page 7] 

        +-----+                                  +-----+  
      + CE1 +--+                           +---| CE2 |  
      +-----+  |    ...................    |    +-----+  
       VPLS A  |  +----+           +----+  |    VPLS A 
               |  |VPLS|           |VPLS|  | 
               +--| PE |--Service--| PE |-+  
                  +----+  Provider +----+  
                 /  .      Backbone    .  \      -   /\-_  
      +-----+   /   .       |          .   \   / \ /   \     +-----+  
      + CE   +--+    .       |          .    +-- \ Access \----| CE  |  
      +-----+       .     +----+       .       | Network |    +-----+  
       VPLS B       .....|VPLS|........         \       /     VPLS B  
                         | PE |     ^           -------  
                         +----+     |  
                           |        |  
                           |        | 
                        +-----+     |  
                        | CE3 |     +-- Logical bridge  
                        +-----+  
                         VPLS A 

This reference model is adapted from [L2VPN-REQ].  The only difference 
is that the VPLS-PE is explicitly named. 

2.2.1 Entities in the VPLS reference model 

The PE (VPLS-PE) and CE devices are defined in [ANDERSSON-TERM]. 

2.3  Reference Model for distributed  VPLS-PE or VPWS-PE 
                                    
               VPLS-PE/VPWS-PE       
                Functionality       . . . . . . . 
            . . . . . . . . . . .   .           . 
            .                   .   .           . 
    +----+  .  +----+    +----+ .   .  Service  .  
    | CE | --.--|u-pe| ----|n-pe|-.---.  Provider . 
    +----+  .  +----+    +----+ .   .  Backbone . 
            . . . . . . . . . . .   .           . 
                                    . . . . . . .  

2.3.1 Entities in the distributed VPLS-PE or VPWS-PE reference 
     model 

A VPLS-PE or a VPWS-PE functionality may be distributed to more than one 
device. The device closer to the customer/user is called User facing PE 



INTERNET-DRAFT   draft-andersson-ppvpn-l2-framework-01.txt      26.06.02 



Andersson                Expires Dec 2002                   [Page 8] 

(U-PE) and the device closer to the core network is called Network 
facing PE (N-PE). 

For further discussion see section 3.4.3. 

The U-PE and N-PE are defined in [ANDERSSON-TERM]. 

2.4  VPWS-PE and VPLS-PE 

The VPWS-PE and VPLS-PE are functionally very similar, the they both use 
forwarders to map attachment circuits to pseudo-wires. The only 
differences is that while the forwarder in a VPWS-PE does a one-to-one 
mapping between the attachment circuit and psedo-wire, the forwarder in 
a VPLS-PE is a Virtual Switching Instance (VSI) that maps multiple 
attachment circuits to multiple pseudo-wires (for further discussion see 
section 3.) 

3.  Functional Components of L2 VPN 

This section specifies a functional model for L2VPN, which allows one to 
break an L2VPN architecture down into its functional components.  This 
allows us to exhibit the roles played by the various protocols and 
mechanisms, and thus to make it easier to understand the differences and 
similarities between various proposed L2VPN architectures. 

Section 3.1 contains an overview of some different types of L2VPN.  In 
section 3.2, functional components that are common to the different 
types are discussed. Then there is a section for each of the L2VPN 
service types being considered. The latter sections discuss functional 
components, which may be specific to particular L2VPN types, as well as 
discussing type-specific features of the generic components. 

3.1  Types of L2VPN 

The types of L2VPN are distinguished by the characteristics of the 
service that they offer to the customers of the Service Provider (SP). 

3.1.1 Virtual Private Wire Service (VPWS) 

In a VPWS, each CE device is presented with a set of point-to-point 
virtual circuits.   

The other end of each virtual circuit is another CE device. Frames 
transmitted by a CE on such a virtual circuit are received by the CE 
device at the other end-point of the virtual circuit. Forwarding from 
one CE device to another is not affected by the content of the frame, 



INTERNET-DRAFT   draft-andersson-ppvpn-l2-framework-01.txt      26.06.02 



Andersson                Expires Dec 2002                   [Page 9] 

but is fully determined by the virtual circuit on which the frame is 
transmitted. The PE thus acts as a virtual circuit switch. 

This type of L2VPN has long been available over ATM and Frame Relay 
backbones. Providing this type of L2VPN over MPLS and/or IP backbones is 
the current topic. 

Requirements for this type of L2VPN are specified in [L2VPN-REQ].  

3.1.2 Virtual Private LAN Service (VPLS)  

In a VPLS, each CE device has one or more LAN interfaces that lead to a 
"virtual backbone".   

Two CEs are connected to the same virtual backbone if and only if they 
are members of the same VPLS instance (i.e., same VPN). When a CE 
transmits a frame, the PE that receives it examines the MAC Destination 
Address field in order to determine how to forward the frame.  

This is determined using standard LAN bridging techniques, such as MAC 
Source Address Learning. (Thus unlike VPWS, VPLS allows the use of 
addressing information in a frame's L2 header to determine the CE to 
which a frame should be sent.)  This allows a LAN to be extended 
transparently over an MPLS and/or IP backbone. 

VPLS is like VPWS in that forwarding is done without any consideration 
of the Layer3 header. Unlike VPWS, VPLS allows a single CE/PE connection 
to be used for transmitting frames to multiple remote CEs.  In this 
respect, VPLS is more like L3VPN. 

Requirements for this type of L2VPN are specified in [L2VPN-REQ].  

3.1.3 IP-only LAN-like Service (IPLS) 

An IPLS is very like a VPLS, except that: 

  -  it is assumed that the CE devices are hosts or routers, not 
     switches 

  -  it is assumed that the service will only carry IP packets, and 
     supporting packets such as ICMP and ARP; Layer2 packets which do 
     not contain IP are not supported. 

While this service is a functional subset of the VPLS service, it is 
considered separately because it may be possible to provide it using 
different mechanisms, which may allow it to run on certain hardware 
platforms that cannot support the full VPLS functionality. 



INTERNET-DRAFT   draft-andersson-ppvpn-l2-framework-01.txt      26.06.02 



Andersson                Expires Dec 2002                   [Page 10 ] 

3.2  Generic L2VPN Transport Functional Components 

All L2VPN types must transport "frames" across the core network 
connecting the PE's. In all L2VPN types, a PE (PE1) receives a frame 
from a CE (CE1), then transports the frame to a PE (PE2), which then 
transports the frame to a CE (CE2).  In this section, we discuss the 
functional components, which are necessary to transport L2 frames in any 
type of L2VPN service. 

3.2.1 Attachment Circuits 

In any type of L2VPN, a CE device attaches to a PE device via some sort 
of circuit or virtual circuit. We will call this an "Attachment Circuit" 
(AC). We use this term very generally; an Attachment Circuit may be a 
Frame Relay DLCI, an ATM VPI/VCI, an Ethernet port, a VLAN, a PPP 
connection on a physical interface, a PPP session from an L2TP tunnel, 
an MPLS LSP, etc. The CE device may be a router, a switch, a host, or 
just about anything, which the customer needs hooked up to the VPN.  An 
AC carries a frame between CE and PE, or vice versa. 

Procedures for setting up and maintaining the ACs are out of scope of 
this architecture.  

These procedures are generally specified as part of the specification of 
the particular Attachment Circuit technology. 

Any given frame will traverse an AC from a CE to a PE and then on 
another AC from a PE to a CE.   

We refer to the former AC as the frame's "ingress AC" and to the latter 
AC as the frame's "egress AC".  Note that this notion of "ingress AC" 
and "egress AC" is relative to a specific frame, and denotes nothing 
more than the frame's direction of travel while on that AC. 

3.2.2 Pseudowires 

A "Pseudowire" (PW) is a relation between two PE devices.  Whereas an AC 
is used to carry a frame from CE to PE, a PW is used to carry a frame 
between two PEs.  We use the term "pseudowire" in the sense of [PWE3-
FW]. 

Setting up and maintaining the PWs is the job of the PEs.  State 
information for a particular PW is maintained at the two PEs which are 
its endpoints, but not at other PEs, and not in the backbone routers (P 
routers). 

Pseudowires may be point-to-point, multipoint-to-point, or point-to-
multipoint. In this framework, point-to-point PWs are always considered 


INTERNET-DRAFT   draft-andersson-ppvpn-l2-framework-01.txt      26.06.02 



Andersson                Expires Dec 2002                   [Page 11 ] 

to be bidirectional; multipoint-to-point and point-to-multipoint PWs are 
always considered to be unidirectional. Multipoint-to-point PWs can be 
used only when the PE receiving a frame from the PW does not need to 
know where the frame came from. Point-to-multipoint PWs may be useful 
when frames need to be multicast. 

Procedures for setting up and maintaining point-to-multipoint PWs are 
not considered in this version of this framework. 

Any given frame travels first on its ingress AC, then on a PW, then on 
its egress AC.   

Multicast frames may be replicated by a PE, so of course the information 
carried in multicast frames may travel on more than one PW and more than 
one egress AC.   

Thus with respect to a given frame, a PW may be said to associate a 
number of ACs.  If these ACs are of the same technology (e.g., both ATM, 
both Ethernet, both Frame Relay) the PW is said to provide "homogeneous 
transport"; otherwise it is said to provide "heterogeneous transport".  
Heterogeneous transport requires that some sort of interworking function 
be applied.  There are at least three different approaches to 
interworking: 

  1. One of the CEs may perform the interworking locally.  For example, 
     if CE1 attaches to PE1 via ATM, but CE2 attaches to PE2 via 
     Ethernet, then CE1 may decide to send/receive Ethernet frames over 
     ATM, using the RFC2684 "LLC Encapsulation for Bridged Protocols".  
     In such a case, PE1 would need to know that it is to terminate the 
     ATM VC locally, and only send/receive Ethernet frames over the PW. 

  2. One of the PEs may perform the interworking.  For example, if CE1 
     attaches to PE1 via ATM, but CE2 attaches to PE2 via Frame Relay, 
     PE1 may provide the "ATM/FR Service Interworking" function.  This 
     would be transparent to the CEs, and the PW would carry only Frame 
     Relay frames. 

  3. IPLS could be used.  In this case the "frames" carried by the PW 
     are IP datagrams, and the two PEs need to cooperate in order to 
     spoof various L2-specific procedures used by IP (see section 3.5). 

3.2.3 Forwarders 

In all types of L2VPN, a PE, say PE1, receives a frame over an AC, and 
forwards it over a PW to another PE, say PE2.  PE2 then forwards the 
frame out on another AC. 

The case in which PE1 and PE2 are the same device is an important case 
to handle correctly, in order to provide the L2VPN service properly.  


INTERNET-DRAFT   draft-andersson-ppvpn-l2-framework-01.txt      26.06.02 



Andersson                Expires Dec 2002                   [Page 12 ] 

However, as this case does not require any protocol, we do not further 
address it in this document. 

When PE1 receives a frame on a particular AC, it must determine the PW 
on which the frame must be forwarded.  In general, this is done by 
considering: 

  -  the incoming AC, 

  -  possibly the contents of the frame's Layer2 header, and 

  -  possibly some forwarding information which may be statically or 
     dynamically maintained. 

If dynamic or static forwarding information is considered, the 
information is specific to a particular L2VPN instance (i.e., to a 
particular VPN). 

Similarly, when PE2 receives a frame on a particular PW, it must 
determine the AC on which the frame must be forwarded. This is done by 
considering: 

  -  the incoming PW, 

  -  possibly the contents of the frame's Layer2 header, and 

  -  possibly some forwarding information which may be statically or 
     dynamically maintained. 

If dynamic or static forwarding information is considered, the 
information is specific to a particular L2VPN instance (i.e. to a 
particular VPN). 

The procedures used to make the forwarding decision are known as a 
"forwarder".  We may think of a PW as being "bound", at each of its 
endpoints, to a forwarder.  The forwarder in turn "binds" the PWs to 
ACs. Different types of L2VPN have different types of forwarders.   

For instance, a forwarder may bind a single AC to a single PW, ignoring 
all frame contents and using no other forwarding information.  Or a 
forwarder may bind an AC to a set of PWs and ACs, moving individual 
frames from AC to PW, from a PW to an AC or from AC to AC by comparing 
information from the frame's Layer2 header to information in a 
forwarding database. This is discussed in more detail below, as we 
consider the different L2VPN types. 





INTERNET-DRAFT   draft-andersson-ppvpn-l2-framework-01.txt      26.06.02 



Andersson                Expires Dec 2002                   [Page 13 ] 

3.2.4 Tunnels 

A PW is carried in a "tunnel" from PE1 to PE2.  We assume that an 
arbitrary number of PWs may be carried in a single tunnel; the only 
requirement is that the PWs all terminate at PE2.   

We do not even require that all the PWs in the tunnel originate at PE1; 
the tunnels may be multipoint -to-point tunnels.  Nor do we require that 
all PWs between the same pair of PEs travel in the same tunnel.  All we 
require is that when a frame traveling through such a tunnel arrives at 
PE2, PE2 will be able to associate it with a particular PW. 

(While one can imagine tunneling techniques that only allow one PW per 
tunnel, they have evident scalability problems, and we do not consider 
them further.) 

There are a variety of different tunneling technologies which may be 
used for the PE-PE tunnels.  All that is really required is that the 
tunneling technologies allow the proper demultiplexing of the contained 
PWs.  The tunnels might be MPLS LSPs, L2TP tunnels, IPsec tunnels, MPLS-
in-IP tunnels, etc.  Generally the tunneling technology will require the 
use of an encapsulation that contains a demultiplexor field, where the 
demultiplexor field is used to identify a particular PW. Procedures for 
setting up and maintaining the tunnels are not within the scope of this 
framework. (But see section 3.2.6, "Pseudowire Signaling".) 

If there are multiple tunnels from PE1 to PE2, it may be desirable to 
assign a particular PE1-PE2 PW to a particular tunnel based on some 
particular characteristics of the PW and/or the tunnel. For example, 
perhaps different tunnels are associated with different QoS 
characteristics, and different PWs require different QoS. Procedures for 
specifying how to assign PWs to tunnels are out of scope of the current 
framework. 

Though point-to-point PWs are bidirectional, the tunnels in which they 
travel need not be either bidirectional or point-to-point. For example, 
a point-to-point PW may travel within a unidirectional multipoint -to-
point MPLS LSP. 

3.2.5 Encapsulation 

As L2VPN packets are carried in pseudowires, standard pseudowire 
encapsulation formats and techniques (as specified by the IETF's PWE3 
WG) should be used wherever applicable.   

Generally the PW encapsulations will themselves be encapsulated within a 
tunnel encapsulation, as determined by the specification of the 
tunneling protocol. 


INTERNET-DRAFT   draft-andersson-ppvpn-l2-framework-01.txt      26.06.02 



Andersson                Expires Dec 2002                   [Page 14 ] 

It may be necessary to define additional PW encapsulations to cover  
areas that are of importance for L2VPN, but may not be within the scope 
of PWE3. Heterogeneous transport may be an instance of this. 

3.2.6 Pseudowire Signaling. 

Procedures for setting up and maintaining the PWs themselves are within 
the scope of this framework.  This includes procedures for distributing 
demultiplexor field values, even though the demultiplexor field, 
strictly speaking, belongs to  the tunneling protocol rather than to the 
PW. 

The signaling for a point-to-point pseudowire must perform the following 
functions: 

  -  Distribution of the demultiplexor.  

        Since many PWs may be carried in a single tunnel, the tunneling 
        protocol must assign a demultiplexor value to each PW. These 
        demultiplexors must be unique with respect to a given tunnel (or 
        with some tunneling technologies, unique at the egress PE).  
        Generally, the PE which is the egress of the tunnel will select 
        the demultiplexor values, and will distribute them to the PE(s) 
        which is (are) the ingress(es) of the tunnel. This is the 
        essential part of the PW setup procedure.  

        Note that, as is usually the case in tunneling architectures, 
        the demultiplexor field belongs to the tunneling protocol, not 
        to the protocol being tunneled. For this reason, the PW setup 
        protocols may be extensions of the control protocols for setting 
        up the tunnels. 

  -  Selection of the Forwarder at the Remote PE. 

        The signaling protocol must contain enough information to enable 
        the remote PE to select the proper forwarder to which the PW is 
        to be bound. We can call this information the "Remote Forwarder 
        Selector". The information that is required will depend on the 
        type of L2VPN being provided and on the provisioning model (see 
        sections 3.3.1 and 3.4.1) being used.  The Remote Forwarder 
        Selector may uniquely identify a particular Forwarder, or it may 
        identify an attribute of Forwarders. In the latter case, it 
        would select whichever Forwarder has been provisioned with that 
        attribute. 

  -  Support pseudowire emulations. 




INTERNET-DRAFT   draft-andersson-ppvpn-l2-framework-01.txt      26.06.02 



Andersson                Expires Dec 2002                   [Page 15 ] 

        To the extent that a particular PW must emulate the signaling of 
        a particular Layer2 technology, the PW signaling must provide 
        the necessary functions.  

  -  Distribution of State Changes. 

        Changes in the state of an AC may need  to be reflected in 
        changes to the state of the PW to which the AC is bound, and 
        vice versa.  The specification as to which changes need to be 
        reflected in what way would generally be within the province of 
        the PWE3 WG. 

  -  Establish pseudowire characteristics. 

        To the extent that one or more characteristics of a PW must be 
        known to and/or agreed upon by both endpoints, the signaling 
        must allow for the necessary interaction. 

As specified above, signaling for point-to-point PWs must pass enough 
information to allow a remote PE to properly bind a PW to a Forwarder, 
and to associate a particular demultiplexor value with that PW. Once the 
two PEs have done the proper PW/Forwarder bindings, and have agreed on 
the demultiplexor values, the PW may be considered to have been set up.  
If it is necessary to negotiate further characteristics or parameters of 
a particular PW, or to passing status information for a particular PW, 
the PW may be identified by the demultiplexor value. 

Signaling procedures for point-to-point pseudowires are most commonly 
point-to-point procedures that are executed by the two PW endpoints.  
There are however proposals to use point-to-multipoint signaling for 
setting up point-to-point pseudowires, so this is included in the 
framework. When PWs are themselves point-to-multipoint, it is also 
possible to use either point-to-point signaling or point-to-multipoint 
signaling to set them up. This is discussed in the remainder of this 
section. 


3.2.6.1 Point-to-Point Signaling 

There are several ways to do the necessary point-to-point signaling.  
Among them are: 

  -  LDP 

        LDP extensions can be defined for pseudowire signaling. See for 
        example [MARTINI-SIGNALING], [ROSEN-L2-SIGNALING].  This form of 
        signaling can be used for pseudowires which are to be carried in 
        MPLS "tunnels", or in MPLS-in-something -else tunnels (e.g., 
        [MPLS-IP], [MPLS-GRE]). 


INTERNET-DRAFT   draft-andersson-ppvpn-l2-framework-01.txt      26.06.02 



Andersson                Expires Dec 2002                   [Page 16 ] 

  -  L2TP 

          L2TP [L2TP-BASE] can be used for pseudowire signaling, resulting 
          in pseudowires that are carried as "sessions" within L2TP 
          tunnels   Pseudowire-specific extensions to L2TP may also be 
          needed, e.g., see [L2TP-FR]. 

Other methods may be possible as well. 

It is possible to have one control connection between a pair of PEs, 
which is used to control many PWs. 

The use of point-to-point signaling for setting up point-to-point PWs is 
straightforward.  Multipoint-to-point PWs can also be set up by point-
to-point signaling, as the remote PEs do not necessarily need to know 
whether the PWs are multipoint-to-point or point-to-point.  In some 
signaling procedures, the same demultiplexor value may be assigned to 
all the remote PEs. 


3.2.6.2 Point-to-Multipoint Signaling 

Consider the following situation: 

  -  It is necessary to set up a set of PWs, all of which have the same 
        characteristics. 

  -  It is not necessary to use the PW signaling protocol to pass PW 
        state changes. 

  -  For each PW in the set, the same value of the Remote Forwarder 
        Selector can be used. 

Call these the "Environmental Conditions". 

Suppose also that there is some mechanism by which, given a range of 
demultiplexor values, each of a set of PEs can make a unique and 
deterministic selection of a single value from within that range.  Call 
this the "Demultiplexor Condition".  Alternatively, suppose that one is 
trying to set up a multipoint -to-point PW rather than a point-to-point 
PW. Call this the "Multipoint Condition". 

If: 

  -  The Environmental Conditions hold, and 

  -  Either 

          *  the Demultiplexor Condition holds, or 


INTERNET-DRAFT   draft-andersson-ppvpn-l2-framework-01.txt      26.06.02 



Andersson                Expires Dec 2002                   [Page 17 ] 

        *  the Multipoint Condition holds, 

then for a given set of PWs which terminate at egress PE1, the 
information which PE1 needs to send to the ingress PE(s) of each 
pseudowire in the set is exactly the same.  All the ingress PE(s) 
receive the same Forwarder Selector value.  They all receive the same 
set of PW parameters (if any). And either they all receive the same 
demultiplexor value (if the PW is multipoint-to-point) or they all 
receive a range of demultiplexor values from which each can choose a 
unique demultiplexor value for itself. 

Rather than connecting to each ingress PE and replicating the same 
information, it may make sense either to multicast the information, or 
to send the information once to a "reflector", which will then take 
responsibility for distributing the information to the other PEs.  

We refer to this sort of technique as "point-to-multipoint" signaling.  
It would, for example, be possible to use BGP to do the signaling, with 
the PEs being BGP peers not of each other, but of one or more BGP route 
reflectors. 

Such a scheme, based Multi-protocol Extensions to BGP, is proposed  
in [KOMPELLA-L2VPN]. 

3.2.6.3 Inter-AS Considerations 

Pseudowires may need to run from a PE in one Service Provider's network 
to a PE in another Service Provider's network. This means that the 
signaling to set up the PEs must be able to cross network boundaries.  
All known proposals for signaling are able to do this. It is especially 
advisable to use some form of authentication between the two PW 
endpoints in this case. 

3.2.7 Service Quality 

Service Quality refers to the ability for the network to deliver a 
Service level Specification (SLS) for service attributes such as 
protection, security and Quality of Service (QoS).  The service quality 
provided depends on the subscriber's requirements, and can be 
characterized by a number of performance metrics.  

The necessary Service Quality must be provided on the ACs as well as on 
the PWs.  Mechanisms for providing Service Quality on the PWs may be PW-
specific or tunnel-specific; in the latter case, the assignment of a PW 
to a tunnel may depend on the Service Quality. 




INTERNET-DRAFT   draft-andersson-ppvpn-l2-framework-01.txt      26.06.02 



Andersson                Expires Dec 2002                   [Page 18 ] 

3.2.7.1 Quality of Service (QoS) 

QoS describes the queuing behavior applied to a particular "flow", in 
order to achieve particular goals of precedence, throughput, delay, 
jitter, etc.  

Based on the customer Service Level Agreement (SLA), traffic from 
customer can be prioritized, policed and shaped for QoS requirements. 
The queuing and forwarding po licies can preserve the packet order and 
QoS parameters of customer traffic.  The class of services can be mapped 
from information in the customer frames, or it can be independent of the 
frame content.  

QoS functions can be listed as follows: 

  -  Customer Traffic Prioritization: L2VPN services could be best 
     effort or QoS guaranteed. Traffic from one customer might need to 
     be prioritized over others when sharing same network resources. 
     This requires capabilities within the L2VPN solution to classify 
     and mark priority to QoS guaranteed customer traffic. 

        Proper queuing behavior would be needed at the egress AC, and 
        possibly within the backbone network as well. If queuing 
        behavior must be controlled within the backbone network, the 
        control might be based on CoS information in the MPLS or IP 
        header, or it might be achieved by nesting particular tunnels 
        within particular traffic engineering tunnels. 

        Policing: This ensures that a user of L2VPN services uses 
        network resources within the limits of the agreed SLA. Any 
        excess L2VPN traffic can be rejected or handled differently 
        based on provider policy. 

        Policing would generally be applied at the ingress AC. 

        Shaping: Under some cases the random nature of L2VPN traffic 
        might lead to sub-optimal utilization of network resources. 
        Through queuing and forwarding mechanisms the traffic can be 
        shaped without altering the packet order. 

        Shaping would generally be applied at the ingress AC. 

3.2.7.2 Resiliency 

Resiliency describes the ability of the L2VPN infrastructure to protect 
a flow from network outage, so that service remains available in the 
presence of failures. 



INTERNET-DRAFT   draft-andersson-ppvpn-l2-framework-01.txt      26.06.02 



Andersson                Expires Dec 2002                   [Page 19 ] 

L2VPN, like any other service, is subject to failures such as link, 
trunk and node failures, both in the SP's core network infrastructure 
and on the ACs. 

It is desirable that the failure be detected "immediately" and 
protection mechanisms allow fast restoration times to make L2VPN service 
almost transparent to these failures to the extent possible, based on 
the level of resiliency.  Restoration should take place before the CEs 
can react to the failure.  Essential aspects of providing resiliency 
are: 

  -  Link/Node failure detection: Mechanisms within the L2VPN service 
         should allow for link or node failures that impact the Service, and 
         should be detected immediately. 

  -  Resiliency policy: The way in which a detected failure is handled 
         will depend upon the restoration policy of the SLA associated with 
         the L2VPN service specification. It may need to be handled 
         immediately, or it may need to be handled only if no other critical 
         failure needs protection resources, or it may be completely ignored 
         if it is within the bounds of the "acceptable downtime" allowed by 
         the L2VPN service. 

  -  Restoration Mechanisms: The L2VPN solutions could allow for 
         physical level protection, logical level protection or both.  For 
         example, by connecting customers over redundant and physically 
         separate ACs to different provider customer-facing devices, one AC 
         can be maintained as active while the other could be marked as a 
         backup; upon the failure detection across the primary AC, the 
         backup could become active. 

To a great extent, resiliency is a matter of having appropriate failure 
and recovery mechanisms in the network core, including "ordinary" 
adaptive routing as well as "fast reroute" [???] capabilities.   The 
ability to support redundant ACs between CEs and PEs also plays a role. 

3.2.8 Management 

An L2VPN solution can provide mechanisms to manage and monitor different 
L2VPN components. From a Service Level Agreement (SLA) perspective, 
L2VPN solutions could allow monitoring of L2VPN service characteristics 
and offer mechanisms used by Service Providers to report such monitored 
statistical data.  Trouble-shooting and verification of operational and 
maintenance activities of L2VPN services are essential requirements for 
Service Providers. 





INTERNET-DRAFT   draft-andersson-ppvpn-l2-framework-01.txt      26.06.02 



Andersson                Expires Dec 2002                   [Page 20 ] 

3.3  VPWS 

A VPWS is an L2VPN service in which each forwarder binds exactly one AC 
to exactly one PW.  Frames received on the AC are transmitted on the PW; 
frames received on the PW are transmitted on the AC.  The content of a 
frame's Layer2 header plays n o role in the forwarding decision, except 
insofar as the Layer2 header contents are used to associate the frame 
with a particular AC (as, e.g., the DLCI field of a Frame Relay frame 
identifies the AC). 

A particular combination of <AC, PW, AC> forms a "virtual circuit" 
between two CE devices. 

A particular VPN (VPWS instance) may be thought of as a collection of 
such virtual circuits, or as an "overlay" of PWs on the MPLS or IP 
backbone. This creates an overlay topology that is in effect the 
"virtual backbone" of a particular VPN. 

Whether two virtual circuits are said to belong to the same VPN or not 
is an administrative matter, based on the agreements between the SPs and 
their customers.  This may impact the provisioning model (discussed 
below).  It may also affect how particular PWs are assigned to tunnels, 
the way QoS is assigned to particular ACs and PWs, etc. 

Note that VPWS makes use of point-to-point PWs exclusively. 

VPWS solutions are found e.g. in [DIRLDP], [KOMPELLA-L2VPN] and [ROSEN-
L2-SIGNALING]. 

3.3.1 Provisioning and Auto-Discovery 

Provisioning a VPWS is a matter of: 

  1. Provisioning the ACs 

  2. Providing the PEs with the necessary information to enable them to 
      set up PWs between ACs to result in the desired overlay topology. 

  3. Configuring the PWs with any necessary characteristics 

3.3.1.1 Attachment Circuit Provisioning 

In many cases, the ACs must be individually provisioned on the PE and/or 
CE. This will certainly be the case if the CE/PE attachment technology 
is a switched network, such as ATM or FR, and the VCs are PVCs rather 
than SVCs. It is also the case whenever the individual Attachment 



INTERNET-DRAFT   draft-andersson-ppvpn-l2-framework-01.txt      26.06.02 



Andersson                Expires Dec 2002                   [Page 21 ] 

Circuits need to be given specific parameters (e.g., QoS parameters, 
guaranteed bandwidth parameters) that differ from circuit to circuit. 

There are also cases in which ACs might not have to be individually 
provisioned.  E.g., if an AC is just an MPLS LSP running between a CE 
and a PE, it could be set up as the RESULT of a PW being set up, rather 
than having to be provisioned BEFORE the PW can be set up. The same may 
apply whenever the AC is a Switched Virtual Circuit of any sort, though 
in this case, various policy controls might need to be provisioned, 
e.g., limiting the number of ACs that can be set up between a given CE 
and a given PE. 

Issues such as whether the Attachment Circuits need to be individually 
provisioned or not, whether they are Switched VCs or Permanent VCs, and 
what sorts of policy controls may be applied, are implementation and 
deployment issues, and are considered to be out of scope of this 
framework. 

3.3.1.2 PW Provisioning for Arbitrary Overlay Topologies 

In order to support arbitrary overlay topologies, it is necessary to 
allow the provisioning of individual PWs.  In this model, when a PW is 
provisioned on a PE device, it is locally bound to a specific AC.  It is 
also provisioned with information that identifies a specific AC at a 
remote PE. 

There are basically two variations of this provisioning model: 

  -  Two-sided provisioning 

        With two-sided provisioning, each PE that is at the end of a PW 
        is provisioned with the following information: 

        *  Identifier of the Local AC to which the PW is to be bound 

        *  PW type and parameters 

        *  IP address of the remote PE (i.e., the PE which is to be at 
           the remote end of the PW) 

        *  Identifier which is meaningful to the remote PE, and which 
           can be passed in the PW signaling protocol to enable the 
           remote PE to bind the PW to the proper AC.  This can be an 
           identifier of the pseudowire (as in [MARTINI-SIGNALING]), or 
           an identifier of the remote AC (as in [ROSEN-L2-SIGNALING]).  
           If a PW identifier is used, it must be unique at each of the 



INTERNET-DRAFT   draft-andersson-ppvpn-l2-framework-01.txt      26.06.02 



Andersson                Expires Dec 2002                   [Page 22 ] 

             two PEs. If an AC identifier is used, it need only be unique 
             at the remote PE. 

             This identifier is then used as the Remote Forwarder Selector 
             when signaling is done (see 3.2.6.1). 

 

     -  Single-sided Provisioning 

       With single sided provisioning, a PE at one end of a PW is 
       provisioned with the following information: 

          *  Identifier of the Local AC to which the PW is to be bound 

          *  PW type and parameters 

          *  Globally unique identifier of remote AC 

            This identifier is then used as the Forwarder Selector  when 
            signaling is done (see section 3.2.6.1). 

          In this provisioning model, the IP address of the remote PE is 
          not provisioned.  Rather, the assumption is that an auto-
          discovery scheme will be used to map the globally unique 
          identifier to the IP address of the remote PE, along with an 
          identifier (perhaps unique only at the latter PE) for an AC at 
          that PE.  The PW signaling protocol can then make a connection 
          to the remote PE, passing the AC identifier, so that the remote 
          PE binds the PW to the proper AC.  (See, for example, [ROSEN-L2-
          SIGNALING].) 

          This scheme requires provisioning of the PW at only one PE, but 
          does not eliminate the need (if there is a need) to provision 
          the ACs at both PEs. 

These provisioning models fit well with the use of point-to-point 
signaling. When each PW is individually provisioned, as the conditions 
necessary for the use of point-to-multipoint signaling do not hold. 

3.3.1.3 Colored Pools PW Provisioning Model 

Suppose that at each PE, sets of ACs are gathered together into "pools", 
and that each such pool is assigned a "color".  (For example, a pool 
might contain all and only the ACs from this PE to a particular CE.)  
Now suppose we impose the following rule: whenever PE1 and PE2 have a 
pool of the same color, there will be a PW between PE1 and PE2 which is 
bound at PE1 to an arbitrarily chosen AC from that pool, and at PE2 to 


INTERNET-DRAFT   draft-andersson-ppvpn-l2-framework-01.txt      26.06.02 



Andersson                Expires Dec 2002                   [Page 23 ] 

an arbitrarily chosen AC from that pool.  (We do not rule out the case 
where a single PE has multiple pools of a given color.) 

For example, each pool in a particular PE might represent a particular 
CE device, with the ACs in the pool being the ACs connecting that CE to 
that PE.  The color might be a VPN-id.  Application of this provisioning 
model would then lead to a full CE-to-CE mesh within the VPN, where 
every CE in the VPN has a virtual circuit to every other CE within the 
VPN. 

More specifically, to provision VPWS according to this model, one 
provisions a set of pools, and configures each pool with the following 
information: 

     -  The set of ACs that belong to the pool (with no AC belonging to 
         more than one pool) 

     -  The color 

     -  A pool identifier that is unique at least relative to the color. 

An auto-discovery procedure is then used to map each color into a list 
of ordered pairs <IP address of PE, pool id>.  The occurrence of a pair 
<X, Y> on this list means that the PE at IP address X has a pool with 
pool id Y which is of the specified color. 
 

This information can be used to support several different signaling 
techniques.  One possible technique proceeds as follows: 

     -  A PE finds that it has a pool of color C. 

     -  Using auto-discovery, it obtains the set of ordered pairs <X,Y> for 
         color C. 

     -  For each such pair <X,Y>, it: 

           *  removes an AC from the pool 

           *  binds the AC to a particular PW 

           *  signals PE X via point-to-point signaling that the PW is to 
              be bound to an AC from pool Y. 

This sort of technique is discussed in [ROSEN-L2-SIGNALING]. 

Another possible signaling technique is the following: 



INTERNET-DRAFT   draft-andersson-ppvpn-l2-framework-01.txt      26.06.02 



Andersson                Expires Dec 2002                   [Page 24 ] 

  -  A PE finds that it has a pool of color C, containing n ACs. 

  -  It binds each AC to a PW, creating a set of PWs.  This set of PWs 
     is then organized into a sequence.  (For instance, each PW may be 
     associated with a demultiplexor field value, and the PWs may then 
     be sequenced according to the numerical value of their respective 
     demultiplexors.) 

  -  Using auto-discovery, it obtains the list of PE routers that have 
     one or more pools of color C. 

  -  It signals each such PE router, specifying the sequence Q of PWs. 

  -  If PE X receives such a signal, and PE X has a pool Y of the 
     specified color, it: 

            *  removes an AC from the pool 

            *  binds the AC to the PW which is the "Yth" PW in the sequence 
              Q. 

This presumes, of course, that the pool identifiers are or can be 
uniquely mapped into small ordinal numbers; assigning the pool 
identifiers in this way becomes a requirement of the provisioning 
system. 

Note that since this technique signals the same information to all the 
remote PEs, it can be supported via point-to-multipoint signaling.  This 
sort of scheme is discussed in [KOMPELLA-L2VPN]. 

This provisioning model can be applied as long as the following 
conditions hold: 

  -  There is no need to provision different characteristics for the 
     different PWs, and 

  -  It makes no difference which pairs of ACs are bound together by 
     PWs, as long as both ACs in the pair come from like-colored pools, 
     and 

  -  It is possible to construct the desired overlay topology simply by 
     assigning colors to the pools.  (This is certainly simple if a full 
     mesh is desired, or if a hub and spoke configuration is desired; 
     creating arbitrary topologies is less simple, and perhaps not 
     always possible.) 





INTERNET-DRAFT   draft-andersson-ppvpn-l2-framework-01.txt      26.06.02 



Andersson                Expires Dec 2002                   [Page 25 ] 

3.3.2 Requirements on Auto-Discovery Procedures 

Some of the requirements for auto-discovery procedures can be deduced 
from the above. 

To support the single-sided provisioning model, auto-discovery must be 
able to map a globally unique identifier (of a PW or of an Attachment 
Circuit) to an IP address of a PE. 

To support the colored pools provisioning model, auto-discovery must 
enable a PE to determine the set of other PEs that contain pools of the 
same color. 

Examples of suitable auto-discovery procedures can be found in Examples 
of suitable auto-discovery procedures can be found in [KOMPELLA-L2VPN], 
[BGP-AUTO] and [ROSEN-L2-SIGNALING], and [DNS-LDP-VPLS]. 

These requirements enable the auto-discovery scheme to provide the 
information, which the PEs need to set up the PWs. 

There are additional requirements on the auto-discovery procedures that 
cannot simply be deduced from the provisioning model: 

  -  Particular signaling schemes may require additional information 
     before they can proceed, and hence may impose additional 
     requirements on the auto-discovery procedures. 

  -  A given Service Provider may support several different types of 
     signaling procedures, and thus the PEs may need to learn, via auto-
     discovery, which signaling procedures to use. 

  -  Changes in the configuration of a PE should be reflected by the 
     auto-discovery procedures, within a timely manner, and without the 
     need to explicitly reconfigure any other PE. 

  -  The auto-configuration procedures must work across service provider 
     boundaries. This rules out, e.g., the use of schemes that piggyback 
     the auto-discovery information on the backbone's IGP. 

3.3.3 Heterogeneous Pseudowires 

Under certain circumstances, it may be desirable to have a PW that binds 
two ACs that use different technologies (e.g., one is ATM, one is 
Ethernet). There are a number of different ways, depending on the AC 
types, in which this can be done.  For example: 

  -  If one AC is ATM and one is FR, then standard ATM/FR Network 
     Interworking can be used.  In this case, the PW might be signaled 


INTERNET-DRAFT   draft-andersson-ppvpn-l2-framework-01.txt      26.06.02 



Andersson                Expires Dec 2002                   [Page 26 ] 

     for ATM, with the Interworking function occurring between the PW 
     and the FR AC. 

  -  A common encapsulation can be used on both ACs, e.g., if one AC is 
     Ethernet and one is FR, an "Ethernet over FR" encapsulation can be 
     used on the latter.  In this case, the PW could be signaled for 
     Ethernet, with the processing of the Ethernet over FR encapsulation 
     being local to the PE with the FR AC. 

  -  If it is known that the two ACs attach to IP routers or hosts, and 
     carry only IP traffic, then one could use a PW which carries the IP 
     packets, and the respective Layer2 encapsulations would be local 
     matters for the two PEs.  However, if one of the ACs is a LAN and 
     one is a point-to-point link, care would have to be taken to ensure 
     that such procedures as ARP and Inverse ARP are properly handled; 
     this might require some signaling, and some proxy functions.  
     Further, if the CEs use a routing algorithm that has different 
     procedures for LAN interfaces than for point-to-point interfaces, 
     additional mechanisms may be required to ensure proper 
     interworking.  These issues are discussed in Fel! Hittar inte 
     referensk„lla..  

3.4  VPLS 

A VPLS is an L2VPN service in which: 

  -  The Forwarders bind multiple ACs to multiple PWs 

  -  Each Forwarder behaves as a "Virtual Switch Instance" (VSI), which 
     performs standard LAN (i.e., Ether net) bridging functions. These 
     include maintenance of a forwarding table by means of MAC address 
     learning, and broadcasting of frames with unknown MAC Destination 
     Addresses. 

An AC connects a CE to a VSI.  Multiple CEs may be connected to a single 
VSI.  The payload on the ACs must be Ethernet frames, with or without 
VLAN headers. An AC may run over any medium that can carry Ethernet 
frames, either natively or in some encapsulation. 

The set of VSIs within a single VPLS are connected via PWs; two VSIs 
will have a PW between them only if those two VSIs are part of the same 
VPN. There may be a further restriction that two VSIs have a PW between 
them only if those two VSIs are part of the same VLAN in the same VPN. 

When the CE device is itself a LAN switch, the VSI may or may not be 
visible as a LAN switch to the CE.  That is, it may send and receive 
BPDUs to and from the CE, or it may simply pass a CE's BPDUs to the 



INTERNET-DRAFT   draft-andersson-ppvpn-l2-framework-01.txt      26.06.02 



Andersson                Expires Dec 2002                   [Page 27 ] 

other CEs, without ever sending a BPDU of its own to the CE.  Different 
VPLS solutions may differ in this respect. 

VPLS solutions are found e.g. in [DNS-LDP-VPLS], [LASSERRE-VKOMPELLA-
VPLS] and [KOMPELLA-VPLS]. 

3.4.1 VPLS Overlay Topologies and Forwarding 

A VPLS emulates a LAN, in that all frame forwarding decisions are based 
only on the frame's MAC Destination Address (DA), the frame's "incoming 
port", and the contents of the forwarding table.  For this purpose, both 
PWs and ACs are considered to be ports.  The VSI forwarding decision 
maps a MAC DA and incoming port to an outgoing port. 

In order to use MAC address learning to populate the forwarding table, 
the PWs must be point-to-point or point-to-multipoint PWs. (Point -to-
multipoint PWs may be useful when it is necessary to multicast a frame; 
the alternative would be replication of the frame by the PE, and 
transmission of each replica over a set of point-to-point PWs.)  There 
is no use for multipoint-to-point PWs. 

MAC learning over a point-to-point PW is done via standard techniques, 
considering the PW to be a port.  But MAC addresses learned over a 
point-to-multipoint PW whose root is PE1 would have to be treated as if 
they had been learned over the point-to-point PW which comes from PE1. 

The VSI forwarding decisions must be coordinated so that loop-free 
forwarding over the overlay topology is ensured. 

There are several possible types of overlay topologies: 

  -  Full mesh 

        In a full mesh, every VSI in a given VPLS has exactly one point-
        to-point PW to every other VSI in that same VPLS. 

        In this topology, loop free forwarding of frames is ensured by 
        the following rule: if a frame is received over a PW, do not 
        forward it over ANY other PW. 

        Multicast and unknown DA packets are replicated and sent over 
        all ports other than the one from which they were received.  
        Alternatively, the full mesh of point-to-point PWs may be 
        augmented with point-to-multipoint PWs, where each VSI in a VPLS 
        is the transmitter on a single point-to -multipoint PW, and the 
        receivers on that PW are all the other VSIs in that VPLS. 

  -  Tree Structured 



INTERNET-DRAFT   draft-andersson-ppvpn-l2-framework-01.txt      26.06.02 



Andersson                Expires Dec 2002                   [Page 28 ] 

           

          In a tree structured topology, every VSI in a particular VPLS is 
          provisioned to be at a particular level in the tree.  A given 
          VSI has at most one pseudowire leading to a higher level. The 
          root of the tree is considered to be the highest level. 

          In this topology, loop free forwarding of frames is ensured by 
          the following rule:  if a frame is received over a pseudowire 
          from a higher level, it may not be sent over a pseudowire that 
          leads to a higher level.  

     -  Tree with Meshed Highest Level 

          In this variant of the tree-structured topology, there may be 
          more than one VSI at the highest level, but the set of VSIs 
          which are at the highest level must be fully meshed. To ensure 
          loop free forwarding, we need to impose the rule that a frame 
          can be sent on a pseudowire to the same or higher level only if 
          it arrived over a pseudo wire from a lower level, and frames 
          arriving over PWs from the same level cannot be sent on PWs to 
          the same level. 

 

Other overlay topologies are also possible, e.g., an arbitrary partial 
mesh of PWs among the VSIs of a VPLS.  Loop-freedom could then be 
assured by, for example, running spanning tree on the overlay.  These 
topologies are not further considered in this framework. 

Note that loop freedom in the overlay topology does not necessarily 
ensure loop freedom in the overall customer LAN that contains the VPLS.  
Improper configuration of the customer LAN (outside the limits of the 
VPLS) may cause looping, and frames that fall into such loops may 
transit the overlay topology multiple times. Procedures that enable the 
PE to detect and/or prevent such loops may be advisable. 

3.4.2 Provisioning and Auto-Discovery 

Each VPLS must be assigned a globally unique identifier. This can be 
thought of as a VPN-id. 

The ACs attaching the CEs to the PEs must be provisioned on both the PEs 
and the CEs.  A VSI for that VPLS must be provisioned on the PE, and the 
local ACs of that VPLS must be associated with that VSI. The VSI must be 
provisioned with the identifier of the VPLS to which it belongs. 




INTERNET-DRAFT   draft-andersson-ppvpn-l2-framework-01.txt      26.06.02 



Andersson                Expires Dec 2002                   [Page 29 ] 

An auto-discovery scheme may be used by a PE to map a VPLS identifier 
into the set of remote PEs that have VSIs in that VPLS.  Once this set 
is determined, the PE can use pseudowire signaling to set up a PW to 
each of those VSIs. The VPLS identifier would serve as the signaling 
protocol's Forwarder Selector. This would result in a full mesh of PWs 
among the VSIs in a particular VPLS. 

If a single VPLS contains multiple VLANs, then it may be desirable to 
limit connectivity so that two VSIs are connected only if they have a 
VLAN in common.  

In this case, each VSI would need to be provisioned with one or more 
VLAN ids, and the auto-discovery scheme would need to map a VPLS 
identifier into pairs of <PE, VLAN id>. 

If a fully meshed topology of VSIs is not desired, then each VSI needs 
to be provisioned with additional information specifying its placement 
in the topology. This information would also need to be provided by the 
auto-discovery scheme. 

Examples of suitable auto-discovery procedures can be found in 
[KOMPELLA-L2VPN], [BGP-AUTO] and [ROSEN-L2-SIGNALING], and [DNS-LDP-
VPLS]. 

Alternatively, the single-sided provisioning method discussed in section 
3.3.1.2 could be used. As this is more complicated, it would only be 
used if it were necessary to associate individual PWs with individual 
characteristics. For example, if different guaranteed bandwidths were 
needed between different pairs of sites within a VPLS, the PWs would 
have to be individually provisioned. 

3.4.3 Distributed PE 

Often when a VPLS type of service is provided, the CE devices attach to 
a provider-managed CPE device. This provider-managed CPE device may 
attach to CEs of multiple customers, especially if, e.g., there are 
multiple customers occupying the same building. However, this device is 
really part of the SP's network, hence may be considered to be a PE 
device. 

In some scenarios when a VPLS type of service is provided, the CE 
devices attach to a provider-managed intermediary device. This provider-
managed device may attach to CEs of multiple customers. This may arise 
in a situation there multiple customers occupying the same building. 
This device is really part of the SP's network, and may for that reason 
be considered to be a PE device, however in the simplest case it is only 
performing aggregation and none of the function associated with a VPLS. 




INTERNET-DRAFT   draft-andersson-ppvpn-l2-framework-01.txt      26.06.02 



Andersson                Expires Dec 2002                   [Page 30 ] 

Relative to the VPLS there are three different possibilities to allocate 
functions to a device in such a position in the provider network:  

  -  it can perform aggregation and pure Layer2 service only, in which 
     case it does not really play the role of a PE device in a VPLS 
     service. In this case the intermediary system must connect to 
     devices that perform VPLS PE functionality; the intermediary device 
     itself is not part of the VPLS architecture and has hence not been 
     named in this architecture. 

  -  it can perform all the PE functions relevant for a VPLS, in such a 
     case the device is called VPLS-PE, see [ANDERSSON -TERM]. This type 
     of device will be connected to the core (P) routers. 

The PE functionality for a VPLS may be distributed between two devices, 
one "low-end" closer to the customer that performs e.g. the MAC-address 
learning and forwarding decisions, and one "high-end" that performs the 
control functions, e.g. establishing tunnels, PWs and VCs. We call the 
low-end device User-Facing PE (U-PE) and the high-end device Network-
Facing PE (N-PE).  

It is conceivable that the U-PE may be placed very close to the 
customer, e.g. in a building with more than one customer. In [KOMPELLA-
DTLS], these are referred to as Multi-Tenant Units, but the resulting 
acronym is already used for something else. In [SAJASSI-VPLS] this type 
of device is called PE-CLE. [MOHAN-LPE] introduces another yet another 
naming scheme, the U-PE is called PE-Edge and the N-PE is called PE-
Core. 

The N-PE, in [KOMPELLA-DTLS] called L2PE and in [SAJASSI-VPLS] called 
PE-POP, will presumably be placed on the SP's premises.  

The distributed case is potentially of interest for a number of possible 
reasons: 

  -  The N-PE may be a device that cannot easily implement the VSI 
     functionality described above. E.g., perhaps the N-PE is a router 
     which cannot perform the high speed MAC learning that is needed in 
     order to implement a VSI forwarder. At the same time, the U-PE may 
     need to be a low-cost device that also cannot implement the full 
     set of VPLS functions. 

     This leads one to investigate further if there are sensible ways to 
     split the VPLS PE functionality between the U-PE and the N-PE. 

  -  Generally, in the L2VPN architecture, the PEs are expected to 
     participate as peers in the backbone routing protocol. Since the 
     number of U-PEs is potentially very large relative to the number of 



INTERNET-DRAFT   draft-andersson-ppvpn-l2-framework-01.txt      26.06.02 



Andersson                Expires Dec 2002                   [Page 31 ] 

     N-PEs, this may be undesirable, as a matter of scaling the backbone 
     routing protocol. 

  -  The U-PE may be a relatively inexpensive device that is unable to 
     participate in the full range of signaling and/or auto-discovery 
     procedures that are needed in order to provide the VPLS service. 

The VPLS functionality can be distributed between U-PE and N-PE in a 
number of different ways, and a number of different proposals have been 
made ([KOMPELLA-DTLS], [MOHAN -LPE], [SAJASSI-VPLS]). They all presume 
that the U-PE will maintain a VSI forwarder, connected by PWs to the 
remote VSIs; the N-PE thus does not need to perform the VSI forwarding 
function. The proposals tend to differ with respect to the following 
questions: 

  -  Should the U-PEs perform full PW signaling to set up the PWs to 
     remote VSIs? Or should the N-PEs do this signaling? 

     Since the U-PEs need to be able to send packets on PWs to remote 
     VSIs and receive packets on PWs from remote VSIs, if the PW 
     signaling is done by the N-PE, there would have to be some form of 
     "lightweight" (presumably) signaling between N-PE and U-PE that 
     allows the PWs to be extended from N-PE to U-PE. 

  -  Should the U-PEs do their own auto -discovery, or should this be 
     done by the N-PEs? In the latter case, the U-PEs may need to have 
     some means of telling the N-PEs which VPLS's they are interested 
     in, and the N-PEs must have some means of passing the results of 
     the auto-discovery process to the U-PE. 

     Whether it makes sense to split auto-discovery in this manner may 
     depend on the particular auto-discovery protocol used. One would 
     not expect the U-PE to participate in BGP auto-discovery, e.g., but 
     perhaps they would be expected to participate in DNS auto-
     discovery. 

  -  If a U-PE does not participate in routing, but is redundantly 
     connected to two different N-PEs, can the U-PE still make an 
     intelligent choice of the best N-PE to use as the "next hop" for 
     traffic destined to a particular remote VSI? If not, can this 
     choice be made as the result of some other sort of interaction 
     between N-PE and U-PE? Or does this choice need to be established 
     by provisioning? 

  -  If a U-PE does not participate in routing, but does participate in 
     full PW signaling, and if MPLS is being used, how can the the N-PE 
     send the the U-Pes the labels that the U-PE needs to send traffic 




INTERNET-DRAFT   draft-andersson-ppvpn-l2-framework-01.txt      26.06.02 



Andersson                Expires Dec 2002                   [Page 32 ] 

     to its signaling peers. (If the U-PE did participate in routing, 
     this would happen automatically.) 

  -  When a frame must be multicast, should the replication be done by 
     the N-PE or the U-PE? 

These questions are not all independent; the way one answers some of 
them may influence the way one answers others. 

3.4.4 Scaling issues in VPLS deployment 

In general, the PSN supports a VPLS solution with a tunnel from each 
VPLS-PE every other VPLS-PE participating in the same VPLS instance. 
Strictly, VPLS-PE's with more than one VPLS instance in common only need 
one tunnel, but for resource allocation reasons it might be necessary to 
establish several tunnels. For each VPLS service on a given VPLS-PE it 
needs to establish one pseudowire to every other VPLS-PE participating 
in that VPLS service. In total n*(n-1) pseudowires must be setup between 
the VPLS-PE routers. In large scale deployment this obviously creates 
scaling problems. An solution addressing the scaling problems was 
addressed in an Internet Draft by S Khandekar et.al. called 
"Hierarchical This has been addressed "Hierarchical Virtual Private LAN 
Service", this work has latter been included in [LASSERRE-VKOMPELLA-
VPLS]. 

3.5  IP-only LAN-like Service (IPLS) 

If, instead of providing a general VPLS service, one wishes to provide a 
VPLS that is used only to connect IP routers or hosts (i.e., the CE 
devices are all assumed to be IP routers or hosts), then it is possible 
to make certain simplifications. 

In this environment, all Ethernet frames sent from a particular CE to a 
particular PE on a particular Attachment Circuit will have the same MAC 
Source Address. Thus rather than using address learning in the data 
plane to learn the MAC addresses, the PE can use the control plane to 
learn the MAC address. (See Fel! Hittar inte referensk„lla. for a 
discussion of this.) This allows the PE to be implemented on devices 
that are not capable of doing MAC address learning in the data plane. 

To eliminate the need for MAC address learning on the PWs as well as on 
the ACs, the pseudowire signaling protocol would have to carry the MAC 
address from one pseudowire endpoint to the other. Each PE would perform 
proxy ARP to its directly attached CEs. 

Eliminating the need to do MAC address learning on the PWs eliminates 
the need for the PWs to be point-to-point. Multipoint-to-point PWs could 
be used instead. 


INTERNET-DRAFT   draft-andersson-ppvpn-l2-framework-01.txt      26.06.02 



Andersson                Expires Dec 2002                   [Page 33 ] 

Unlike a VPLS, all the ACs in an IPLS would not necessarily have to 
carry Ethernet frames; only the IP packets would need to be passed 
across the network, not their Layer2 wrappers. However, this might 
require "translation" between "ARP" and "Inverse ARP". The set of 
routing protocols which could be carried across the IPLS might also be 
restricted. A fuller discussion of the advantages, disadvantages, and 
restrictions may be found in  Fel! Hittar inte referensk„lla.. 

4.  Security Considerations 

Security considerations will be addressed in a future version of this 
document. 

4.1   System security 

This is for a future version of this document. 

4.2   Access Control 

This is for a future version of this document. 

4.3   Endpoint authentication 

This is for a future version of this document. 

4.4   Data Integrity 

This is for a future version of this document. 

4.5   Confidentiality 

This is for a future version of this document. 

4.6  User data and Control data 

This is for a future version of this document. 

5.  References 

[rfc2026] 
     Bradner, S. "The Internet Standards Process -- Revision 3", RFC 
     2026, October 1996. 




INTERNET-DRAFT   draft-andersson-ppvpn-l2-framework-01.txt      26.06.02 



Andersson                Expires Dec 2002                   [Page 34 ] 

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

[ANDERSSON-METRICS] 
     Andersson, L. "Parameters and related metrics to compare PPVPN 
     Layer 2 solutions", draft-andersson-ppvpn-metrics -00.txt, Work 
     in Progrss, Internet Draft, Feb 2002.  

[ANDERSSON-TERM] 
     Andersson, L. and Madsen T. "VPN Terminology", draft-andersson-
     ppvpn-terminology-00.txt", Work in Progress, Internet Draft, 
     Feb 2002.  

[BGP-AUTO]  
     Ould-Brahim, H. et.al. "Using BGP as an Auto-Discovery 
     Mechanism for Network-based VPNs", Ould-Brahim et al, draft-
     ietf-ppvpn-bgpvpn-auto-01.txt, Work in Progress, Internet 
     Draft, Nov 2001 

[DIRLDP] 
     Heinanen, J, "Directory/LDP Based Unidirectional Virtual 
     Circuit VPNs" draft-heinanen-dirldp-uni-vc-vpns-01.txt, Work in 
     Progress, Internet Draft, Nov 2001  

[DNS-LDP-VPLS] 
     Heinanen, J, "DNS/LDP Based VPLS", draft-heinanen -dns-ldp-vpls-
     00.txt, Work in Progress, Internet Draft, Jan 2002 

[KOMPELLA-DTLS] 
     Kompella, K et.al. "Decoupled Virtual private LAN Services", 
     draft-kompella-ppvpn-dtls-01.txt, December 2001 

[KOMPELLA-L2VPN] 
     Kompella, K. et.al. "Layer 2 VPNs Over Tunnels", draft-
     kompella-ppvpn-l2vpn-01.txt, Nov 2001 

 [KOMPELLA-VPLS] 
     Kompella, K. "Virtual Private LAN Service", draft -kompella-
     ppvpn-vpls-00.txt, Work in Progress, Internet Draft, Nov 2001  

[L2TP-BASE] 
     Lau, J. "Layer Two Tunneling Protocol (Version 3) L2TPv3" 
     draft-ietf-l2tpext-l2tp-base-02.txt", Work in Progress, 
     Internet Draft, March 2002. 

[L2TP-FR] 
     Townsley, W. M. et.al. ""Frame Relay Pseudowire Extensions for 



INTERNET-DRAFT   draft-andersson-ppvpn-l2-framework-00.txt      26.06.02 



Andersson                Expires Dec 2002                   [Page 35 ] 

     L2TP", draft-ietf-l2tpext-pwe3-fr-00.txt, Work in Progress, 
     Internet Draft, Feb 2002. 

[L2VPN-ARCH] 
     Rosen, E. et.al. "An Architecture for L2VPNs", draft-ietf-
     ppvpn-l2vpn-00.txt, Work in Progress, Internet Draft Jul 2001. 

[L2VPN-REQ] 
     Augustyn, W. et.al "Requirements for Layer 2 Virtual Private 
     Network Services (L2VPN)", draft-augustyn-ppvpn-l2vpn-
     requirements-00.txt, Work in Progress, Internet Draft, June 
     2002.  

[L3VPN-FW]  
     Callon, R. et.al. "A Framework for Layer 3 Provider Provisioned 
     Virtual Private Networks", draft-ietf-ppvpn-framework-05.txt, 
     Work in Progress, Internet Draft, April 2002  

[L3VPN-REQ] 
     Carugi, M. et.al. "Service requirements for Layer 3 Provider 
     Provisioned Virtual Private Networks" draft-ietf-ppvpn-
     requirements-04.txt, Work in Progress, Internet Draft, Feb 
     2002.  

[LASSERRE-VKOMPELLA-VPLS] 
     Lasserre, M. et.al. "Virtual Private LAN Services over MPLS", 
     draft-lasserre-vkompella-ppvpn-vpls-01.txt, Work in progress, 
     Internet Draft, Mar 2002.  

[MARTINI-SIGNALING]  
     Martini, L. et.al. "Transport of Layer 2 Frames Over MPLS", 
     draft-martini-l2circuit-trans-mpls -08.txt, Work in Progress, 
     Internet Draft, Nov 2001 

[MOHAN-LPE]  
     Mohan, D. et.al. "VPLS/LPE L2VPNs: Virtual Private LAN Services 
     using Logical PE Architecture ", draft-ouldbrahim -l2vpn-lpe-
     02.txt, Work in Progress, Internet Draft, Mar 2002  

[MPLS-GRE]  
     Rekhter, Y. "MPLS Label Stack Encapsulation in GRE", Rekhter et 
     al, draft-rekhter-mpls-over-gre-03.txt, Work in Progress, 
     Internet Draft Sep, 2001. 

[MPLS-IP]  
     Worster, T. et.al. "MPLS Label Stack Encapsulation in IP", 
     Worster et al,   draft-worster-mpls-in-ip-05.txt, Work in 
     Progress, Internet Draft, Jul 2001.  



INTERNET-DRAFT   draft-andersson-ppvpn-l2-framework-00.txt      26.06.02 



Andersson                Expires Dec 2002                   [Page 36 ] 

[PWE3-FW]  
     Pate, P. editor, "Framework for Pseudo Wire Emulation Edge-to-
     Edge", Pate, P. editor, draft-ietf -pwe3-framework -00.txt, Work 
     in Progress, Internet draft, Feb 2002 

[ROSEN-L2-SIGNALING]  
     Rosen, E. "Single-Sided Signaling for L2VPNs", draft-rosen-
     ppvpn-l2-signaling-01.txt, Work in Progress, Internet Draft, 
     Feb 2002 

 [SAJASSI-VPLS]  
     Sajassi, A. "VPLS Architectures", draft-sajassi-vpls-
     architectures-00.txt , Work in Progress, Internet Draft, Feb 
     2002. 

[SHAH-INTER]  
     Shah, H. et.al. "IP address resolution for IP interworking of 
     Layer 2 VPN", draft-shah-l2vpn-arp -resolve-00.txt, Work in 
     Progress, Internet Draft, Jan 2002  

[SHAH-SIG] 
     Shah, H. et.al. "Signaling between PE and L2PE/MTU for 
     Decoupled VPLS and Hierarchical VPLS", draft-shah -ppvpn-vpls -
     pe-mtu-signaling-00.txt, Work in Progress, Internet Draft, Feb 
     2002. 

6.  Acknowledgements 

This document is the outcome of discussions within the PPVPN Layer 2 VPN 
design team. The members of the design team are  

Eric Rosen,        Cisco Systems        erosen@cisco.com 
Hamid Ould-Brahim, Nortel Networks      hbrahim@nortelnetworks.com 
Juha Heinanen,     Song Networks        jh@lohi.eng.song.fi 
Kireeti Kompella,  Juniper Networks     kireeti@juniper.net 
Loa Andersson,     Utfors AB,           loa.andersson@utfors.se 
Marc Lasserre,     Riverstone Networks  marc@riverstonenet.com 
Marty Borden,      Atrica               mborden@atrica.com 
Pascal Menezes,    Terrabeam            Pascal.Menezes@Terabeam.com 
Vach Kompella,     Timetra Networks     vkompella@timetra.com 
Vasile Radoaca     Nortel Networks      vasile@nortelnetworks.com 
Waldemar Augustyn,                      waldemar@nxp.com 

The team would like to thank Marco Carugi for cooperation in setting up 
context, working directions and taking time for discussions in this 
space. The team would also like to thank Tove Madsen for valuable input 
and reviews. 



INTERNET-DRAFT   draft-andersson-ppvpn-l2-framework-01.txt      26.06.02 



Andersson                Expires Dec 2002                   [Page 37 ] 

7.  Authors Contact 

Loa Andersson (editor) 
Utfors AB 
P.O Box 525 
SE-169 29 Solna 
tel: +46 8 52 70 50 38 
email: loa.andersson@utfors.se 

 



































INTERNET-DRAFT   draft-andersson-ppvpn-l2-framework-01.txt      26.06.02