PPVPN Working Group Loa Andersson Internet-Draft Utfors AB Design team editor Expiration Date: Sep 2002 March 2002 PPVPN L2 Framework 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-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: See the reference section. For this document this not just "an easy way out", we actually intend to list all the documents that we are aware of and that has an impact on this framework. WHERE DOES IT FIT IN THE PICTURE OF THE SUB-IP WORK This ID is intended for the PPVPN WG. WHY IS IT TARGETED AT THIS WG(s) INTERNET-DRAFT draft-andersson-ppvpn-l2-framework-00.txt Mar 2002 Andersson Expires Sep 2002 [Page 2] 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 [2]. Contents 1. Introduction...................................................... 5 1.1 Objectives and Scope of the Document.......................... 5 1.2 Layer 2 Virtual Private Networks.............................. 6 1.3 Terminology................................................... 6 2. Models............................................................ 7 2.1 Reference Model for VPWS...................................... 7 2.1.1 Entities in the VPWS reference model................ 7 2.2 Reference Model for VPLS...................................... 7 2.2.1 Entities in the VPLS reference model................ 8 2.3 Reference Model for de-coupled VPLS........................... 8 2.3.1 Entities in the de-coupled VPLS reference model..... 8 3. Functional Components of L2 VPN................................... 8 3.1 Attachment Circuits........................................... 8 3.2 VPN Forwarding and Switching (VFS)............................ 9 3.3 Point-to-Point Pseudowires (PWs).............................. 9 3.4 Multipoint Pseudowires....................................... 10 3.5 Tunnels...................................................... 11 3.6 Provisioning and Discovery................................... 12 3.6.1 Attachment Circuit Provisioning.................... 12 3.6.2 Provisioning of VPWS Arbitrary Overlay Topologies.. 12 3.6.3 Provisioning of VPWS via "Colored Pools"........... 13 INTERNET-DRAFT draft-andersson-ppvpn-l2-framework-00.txt Mar 2002 Andersson Expires Sep 2002 [Page 3] 3.6.4 Provisioning of VPLS................................... 14 3.6.5 Requirements on Discovery Procedures................... 15 3.6.6 Inter-AS Considerations................................ 16 3.7 Pseudowire Signaling......................................... 16 3.7.1 Point-to-Point Signaling............................... 17 3.7.2 Point-to-Multipoint Signaling.......................... 18 3.7.3 Comparison of P2P and P2MP Signaling................... 19 3.7.4 Inter-AS Considerations................................ 21 3.8 Encapsulation................................................ 21 3.9 Special Cases................................................ 21 3.9.1 VPWS: Like-to-like vs. Any-to-Any...................... 21 3.9.2 VPLS: IP Interworking Only............................. 22 3.9.3 VPLS: Decoupling....................................... 23 3.10 Quality of Service.......................................... 24 3.11 Redundancy.................................................. 24 3.12 Multihoming................................................. 24 4. Customer facing Interfaces....................................... 25 4.1 VPN Establishment at the Customer Interface.................. 25 4.1.1 VPWS................................................... 25 4.1.2 VPLS................................................... 25 4.1.3 Decoupled VPLS......................................... 25 4.2 Data Forwarding at the Customer Interface.................... 26 4.2.1 VPWS................................................... 26 4.2.2 VPLS................................................... 26 4.2.3 Decoupled VPLS......................................... 26 5. Core Network facing Interface.................................... 26 5.1 Network Management of L2 VPNs................................ 26 5.1.1 VPWS................................................... 26 5.1.2 VPLS................................................... 26 5.1.3 De-coupled VPLS........................................ 27 6. Security Considerations.......................................... 27 6.1 System security.............................................. 27 6.2 Access Control............................................... 27 6.3 Endpoint authentication...................................... 27 6.4 Data Integrity............................................... 27 6.5 Confidentiality.............................................. 27 6.6 User data and Control data................................... 27 7. List of Layer 2 VPN drafts....................................... 27 8. Summary and recommendations...................................... 32 8.1 Documents for VPLS type of services.......................... 32 8.2 Document for VPWS type of services:.......................... 32 8.3 Protocol extensions.......................................... 32 8.4 Architecture and Framework................................... 32 INTERNET-DRAFT draft-andersson-ppvpn-l2-framework-00.txt Mar 2002 Andersson Expires Sep 2002 [Page 4] 9. References....................................................... 32 10. Acknowledgements................................................ 36 11. Authors Contact................................................. 36 INTERNET-DRAFT draft-andersson-ppvpn-l2-framework-00.txt Mar 2002 Andersson Expires Sep 2002 [Page 5] 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 layer 2 PPVPNs. The PPVPN WG group works with both Layer 3 PPVPNs and Layer 2 PPVPNs. A framework for L3 VPNs is found in [19]. 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 layer 2 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 technical aspects of layer 2 PPVPN operations from the customer's point of view are discussed. Next, technical aspects of Layer 2 PPVPNs from the providers point of view 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 layer 2 PPVPNs interworking are clarified. Finally, security issues as they apply to layer 2 PPVPNs are addressed. Requirements for Layer 3 VPNs are found in [24] and for Layer 2 VPNs (currently only for VPLS, but plan is to extend it to VPWS also) in [21]. This document has "inherited" a substantial content from "An Architecture for L2VPNs" [42]. INTERNET-DRAFT draft-andersson-ppvpn-l2-framework-00.txt Mar 2002 Andersson Expires Sep 2002 [Page 6] This document does not make choices, and does not select any particular approach to support VPNs. 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 L2 but will not make any recommendations on the relative merits of how the different components are implemented. In [23] 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-add 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). 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 [18]. INTERNET-DRAFT draft-andersson-ppvpn-l2-framework-00.txt Mar 2002 Andersson Expires Sep 2002 [Page 7] 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 [18]. 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-00.txt Mar 2002 Andersson Expires Sep 2002 [Page 8] +-----+ +-----+ + CE1 +--+ +---| CE2 | +-----+ | ................... | +-----+ VPLS A | +----+ +----+ | VPLS A | |VPLS| |VPLS| | +--| PE |--Service--| PE |-+ +----+ Provider +----+ / . Backbone . \ - /\-_ +-----+ / . | . \ / \ / \ +-----+ + CE4 +--+ . | . +--\ Access \----| CE5 | +-----+ . +----+ . | Network | +-----+ VPLS B .....|VPLS|........ \ / VPLS B | PE | ^ ------- +----+ | | | +-----+ | | CE3 | +-- Logical bridge +-----+ VPLS A This reference model is adapted from [21] 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 [18]. 2.3 Reference Model for de-coupled VPLS This is for a future version of this document. 2.3.1 Entities in the de-coupled VPLS reference model This is for a future version of this document. 3. Functional Components of L2 VPN 3.1 Attachment Circuits A Customer Edge (CE) device attaches to a Provider Edge (PE) device via some sort of circuit or virtual circuit. We will call this an "Attachment Circuit". 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 INTERNET-DRAFT draft-andersson-ppvpn-l2-framework-00.txt Mar 2002 Andersson Expires Sep 2002 [Page 9] L2TP tunnel, an MPLS LSP, etc. In general, the CE device may be a router, a switch, a host, or just about anything which the customer needs hooked up to the VPN. Procedures for setting up and maintaining the Attachment Circuits are out of scope of this architecture. These procedures are generally specified as part of the specification of the particular Attachment Circuit technology. 3.2 VPN Forwarding and Switching (VFS) When a PE provides a VPLS, it must have one VFS for each VPL (Virtual Private LAN) that it is supporting. A VFS may be thought of as a sort of virtual LAN switch that performs the LAN switching functions for a particular VPL. For a VPLS service, an Attachment Circuit can be thought of as connecting a CE to a VFS. Multiple CEs may be connected to a single VFS. The payload on these Attachment Circuits must be Ethernet frames, with or without VLAN headers. The Attachment Circuit may run over any medium, which can carry Ethernet frames, either natively or in some encapsulation. The VFS does MAC address learning as well as switching of Ethernet frames. The VFS construct does not appear in the VPWS, but only in the VPLS. 3.3 Point-to-Point Pseudowires (PWs) To provide VPWS connectivity between CE1 and CE2, where CE1 attaches to PE1 and CE2 attaches to PE2, and where PE1 is another device than PE2, a point-to-point "Pseudowire" ("PW")[9] must be carried across the IP backbone from PE1 to PE2. At each of PE1 and PE2, the PW is associated with an Attachment Circuit. In effect, the ordered triple functions as a virtual circuit between CE1 and CE2, thus providing layer 2 connectivity between the CEs. The mapping between a PW and a pair of Attachment Circuits is one-to-one. In a VPWS, once a packet arrives on a particular Attachment Circuit, the PW over which it is sent is determined, and vice versa. To provide VPLS connectivity among a set of CEs, each CE in the set must be connected via Attachment Circuit to a VFS, which is part of that VPLS. The VPLS is created by creating an overlay topology of PWs connecting the set of VFSs that belong to that VPLS. That is, each point-to-point PW binds together two VFS, rather than two Attachment Circuits. INTERNET-DRAFT draft-andersson-ppvpn-l2-framework-00.txt Mar 2002 Andersson Expires Sep 2002 [Page 10] In a VPLS, once a packet arrives on a particular Attachment Circuit, the VFS must determine the PW (or Attachment Circuit) to send the packet on. Similarly, once a packet arrives on a particular PW, the VFS must determine the Attachment Circuit (or PW) to send the packet on. A VPLS emulates a LAN, in that all frame forwarding decisions are based on the frames MAC Destination Address (DA) and its "incoming port". For this purpose, both PWs and Attachment Circuits are considered to be ports. The VFS forwarding decision maps a MAC DA and incoming port to an outgoing port. The VFS forwarding will be populated using MAC address learning as specified by IEEE 802.something. It is important to understand that in order to support the "MAC address learning" functionality of IEEE 802.something, the VFSs must be connected by point-to-point pseudowires. Although a VPLS provides a LAN-like service to the CEs, the VFSs themselves are connected via point-to-point PWs, NOT the multipoint PWs of section 3.4. The VFS forwarding decisions must be coordinated so that loop-free forwarding over the overlay topology is ensured. It is assumed that frames are never sent back over their incoming ports. 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). Procedures for setting up and maintaining the PWs are within the scope of the architecture. Point-to-point PWs are considered to be bidirectional. This does not rule out their being implemented as pairs of unidirectional entities. When a PW relates two Attachment Circuits of like kind, it is necessary to specify the relation between Attachment Circuit state and PW state, as well as the relation between various Attachment Circuit events and various PW events. However, this specification is outside the scope of the current architecture. This is deferred, where applicable, to the PWE3 Working Group. 3.4 Multipoint Pseudowires It is useful to have the notion of a unidirectional multipoint pseudowire. In a p2p PW, anything which is put in either end comes out the other. In a unidirectional multipoint PW, there is a single egress INTERNET-DRAFT draft-andersson-ppvpn-l2-framework-00.txt Mar 2002 Andersson Expires Sep 2002 [Page 11] point, but multiple ingress points. Anything put in at one of the ingress points will come out the egress point. Multipoint PWs may be used to support an "IP Connectivity VPLS", see section 3.9.2. 3.5 Tunnels A PW is carried in a "tunnel" from PE1 to PE2. In general, the number of PWs that may be carried in a single tunnel is arbitrary; the only requirement is that the PWs all terminate at PE2. It is not required that all the PWs in the tunnel originate at the same PE; the tunnels may be multipoint-to-point tunnels. Nor is it required that all PWs between the same pair of PEs travel in the same tunnel. It is required that when a frame traveling through such a tunnel arrives at PE2, PE2 will be able to associate it with a particular PW. In a VPWS, this determines the Attachment Circuit on which the frame will be transmitted from PE2 to the appropriate CE; in a VPLS this determines the VFS to which the packet must be delivered. It is desired to allow a variety of different tunneling technologies to be used for the PE-PE Tunnels, and it is a goal of the architecture to accommodate any tunneling protocol, which allows 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, which contains a Demultiplexor field, where the Demultiplexor field is used to identify a particular PW. It is very important not to confuse the PWs with the tunnels through which they travel. Procedures for setting up and maintaining the tunnels are out of scope of this architecture. 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 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 architecture. Although point-to-point PWs are inherently bidirectional, there is no need for the tunnels through which they travel to be bidirectional. INTERNET-DRAFT draft-andersson-ppvpn-l2-framework-00.txt Mar 2002 Andersson Expires Sep 2002 [Page 12] 3.6 Provisioning and Discovery Provisioning a VPWS is a matter of: 1. Provisioning the Attachment Circuits 2. Telling the PEs which Attachment Circuits (in the case of VPWS) or which VFSs (in the case of VPLS) need to be connected via which kinds of PWs 3. Configuring the PWs with any necessary characteristics The set of PWs creates an "overlay topology", which is in effect the "virtual backbone" of the layer 2 VPN. 3.6.1 Attachment Circuit Provisioning In many cases, the CE-PE Attachment Circuits 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 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 Attachment Circuits might not have to be individually provisioned. E.g., if an Attachment Circuit 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 CE-PE Attachment is an SVC of any sort, though in this case, various policy controls might need to be provisioned, e.g., limiting the number of Attachment Circuits that can be set up between a given CE and a given PE. Whether the Attachment Circuits need to be individually provisioned or not, whether an SVC or a PVC model is used, and what sorts of policy controls may be applied, are implementation and deployment issues, and are not further discussed here. 3.6.2 Provisioning of VPWS Arbitrary Overlay Topologies In order to support arbitrary overlay topologies, it is necessary to allow the provisioning of individual PWs. There are basically two variations of this: - Two-sided provisioning. INTERNET-DRAFT draft-andersson-ppvpn-l2-framework-00.txt Mar 2002 Andersson Expires Sep 2002 [Page 13] With two-sided provisioning, each PE which is at the end of a PW is provisioned with the following information: * Local Attachment Circuit * Pseudowire type and parameters * IP address of PE at remote end of pseudowire * Identifier which is meaningful to PE at remote end of wire, and can be used by that PE to bind the PW to the proper Attachment Circuit. This can be an identifier of the pseudowire (as in [7]), or an identifier of the remote Attachment Circuit (as in [10]). The identifier needs to be unique relative to the pair of PEs. This provisioning method does not use a discovery scheme. - Single-Sided Manual Provisioning. With single sided provisioning, a PE at one end of a PW is provisioned with the following information: * Local Attachment Circuit * Pseudowire type and parameters * Globally unique identifier of remote Attachment Circuit. This provisioning method requires the use of a discovery scheme, which maps the globally unique identifier of the remote Attachment Circuit to the IP address of the remote PE, along with an identifier (unique only at the latter PE) for an Attachment Circuit at that PE. (See, for example, [10].) This provisioning method requires provisioning of the pseudowire at only one PE, but does not eliminate the need (if there is a need) to provision the Attachment Circuits at both PEs. 3.6.3 Provisioning of VPWS via "Colored Pools" Suppose that at each PE, sets of Attachment Circuits are gathered together into "pools", and that each such pool is assigned a color. (For example, a pool might contain all and only the Attachment Circuits 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 Attachment Circuit from that pool, and at PE2 to an arbitrarily chosen Attachment Circuit from that pool. INTERNET-DRAFT draft-andersson-ppvpn-l2-framework-00.txt Mar 2002 Andersson Expires Sep 2002 [Page 14] (We do not rule out the case where a single PE has multiple pools of a given color.) As long as: - There is no need to provision different characteristics for the different PWs, and - It makes no difference which pairs of Attachment Circuits are bound together by PWs, as long as both Attachment Circuits in the pair come from like-colored pools, and - It is possible to construct the necessary overlay topology simply by setting up the colored pools, then this technique provides a very simple and scalable way to provision the L2VPN overlay topology. Certainly it is more scalable (in terms of the amount of provisioning data that must be entered) than provisioning theindividual pseudowires, even if the single-sided model is used. (Note, however, that much or all of this advantage is lost if it is necessary to provision the individual Attachment Circuits.) This provisioning method requires the use of a discovery scheme which maps a color into the set of PE which have pools of that color. This technique is first described in [5], and also discussed in [10]. The colored pools technique may be useful if one wants a VPWS overlay topology which is a full CE-CE mesh of virtual circuits. Then at each PE, one creates one such pool per CE, containing all and only the Attachment Circuits which connect to that CE. Across the network, the set of pools that correspond to a particular VPN are given the same color. In this case, the "color" really corresponds to a "VPN-id". More generally, one might want to control the topology of a VPN by giving it pools of several different colors, and even by allowing single pools to have multiple colors. So in general there might be multiple colors corresponding to a single VPN-id. The colors of course are really globally unique values. The colored pools technique also works well for "hub and spoke" overlay topologies. However, in that topology it does not provide a scaling advantage over the single-sided provisioning model. 3.6.4 Provisioning of VPLS Each VPLS must be assigned a globally unique identifier. Each VFS must be provisioned with the identifier of the VPLS to which it belongs. A INTERNET-DRAFT draft-andersson-ppvpn-l2-framework-00.txt Mar 2002 Andersson Expires Sep 2002 [Page 15] discovery scheme is used to map from a VPLS identifier to the set of PEs containing VFSs in that VPLS. If there is no need to provision different characteristics for different PWS, then this is all that is needed to provision a VPLS, other than the provisioning of the Attachment Circuits. If there is a need to provision different characteristics for different PWs, then the individual pseudowire provisioning of section 3.6.2 may be used; single- sided provisioning with a globally unique identifier that identifies a particular VPLS should be used. 3.6.5 Requirements on Discovery Procedures To support the single-sided provisioning model, the discovery procedure must be able to map a globally unique identifier (of a PW or of an Attachment Circuit) to a PE IP address. To support the colored pools provisioning model, the discovery procedure must enable a PE to determine the set of other PEs which contain pools of the same color. To support the VPLS provisioning model, the discovery procedure must enable a PE supporting a particular VPLS to determine the set of other PEs which contain VFSs in the same VPLS. Examples of suitable auto-discovery procedures can be found in [5], [3], and [12]. There are additional requirements on the auto-discovery procedures which 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 automatically 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, which piggyback the auto-discovery information on the backbone's IGP. INTERNET-DRAFT draft-andersson-ppvpn-l2-framework-00.txt Mar 2002 Andersson Expires Sep 2002 [Page 16] 3.6.6 Inter-AS Considerations Within a single L2VPN, some PEs may attach to one Service Provider's network, while other PEs attach to another Service Provider's network. Discovery procedures must enable a PE to discovery other PEs in the same L2VPN, even when those other PEs are attach to a different Provider's network. The DNS-based and BGP-based discovery procedures both have this property, though in both cases some additional complexity is introduced. 3.7 Pseudowire Signaling 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 Demultplexor 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 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. - Binding of PW to Attachment Circuit or VFS. The signaling protocol must contain enough information to enable the remote PE to determine proper Attachment Circuit or VFS to which the PW must be bound. - In some cases, this will require that a specific individual Attachment Circuit be identified by the signaling protocol. In other cases, one may not care which Attachment Circuit a PW is bound to, as long as that Attachment Circuit has some specific property. In this case, that property needs to be identified by the signaling protocol. An example of such a property is "an Attachment Circuit that comes from a particular colored pool." To identify a particular VFS, the VPLS dentifier should be used. - Distribution of State Changes. Changes in the state of an Attachment Circuit may need to be reflected in changes to the state of the PW to which the Attachment Circuit is bound, and INTERNET-DRAFT draft-andersson-ppvpn-l2-framework-00.txt Mar 2002 Andersson Expires Sep 2002 [Page 17] vice versa. These changes must then be distributed to the remote endpoint of the PW. - Establish pseudowire characteristics. To the extent that one or more characteristics of a PW must be agreed upon by both endpoints, the signaling must allow for the necessary interaction. - Support pseudowire emulations. To the extent that a particular PW must emulate the signaling of a particular layer 2 technology, the PW signaling must provide the necessary functions. Specification of the use of existing protocols for pseudowire signalling needs to be done by the PPVPN WG. To the extent that the protocols need to be extended to support the necessary signaling, the extensions must be done by the WG responsible for the signaling protocol, and the PPVPN WG must set the requirements. (Extensions which can be made merely by assigning new parameter values, where IANA has been instructed to assign values for those parameters on a first come, first served, basis, can be specified entirely by th PPVPN WG without need for the approval of another WG. Pseudowire signaling procedures tend to fall into two classes: point-to-point signaling and point-to-multipoint signaling, which are discussed in the remainder of this section. It is important to understand that point-to-multipoint signaling may be used for setting up point-to-point pseudowires. The distinction is whether the signaling is point-to-point or point-to-multipoint, not whether the resulting pseudowires are point-to-point or multipoint. 3.7.1 Point-to-Point Signaling There are several ways to do the necessary point-to-point signaling: - LDP. LDP extensions can be defined for pseudowire 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. See [7] and [10]. - L2TP. L2TP extensions can be defined for pseudowire signaling. This form of signaling can be used for pseudowires that are to be carried a sessions in L2TP tunnels. See [4]. - If it is desired to tunnel pseudowires through IPsec, one may use the MPLS-in-IPsec technique defined in [35], or one may use INTERNET-DRAFT draft-andersson-ppvpn-l2-framework-00.txt Mar 2002 Andersson Expires Sep 2002 [Page 18] the L2TP-in-IPsec defined in [???]. No IPsec extensions are required. 3.7.2 Point-to-Multipoint Signaling Consider the case where we want to set up a set of PWs, but rather than binding them to specific Attachment Circuits, we only want to ensure that they get bound to Attachment Circuits with a specific property. Suppose further that all the PWs in the set are to have uniform characteristics, and that we do not desire to reflect changes in Attachment Circuit state as changes in pseudowire state. Suppose further that all the Attachment Circuits are alike (i.e., of the same technology), so that no special interworking or header translation needs to be done. 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. Then an egress PE would not necessarily need to assign a particular Demultiplexor to each pseudowire, it could merely specify the range that is to be associated with a particular set of PWs, and allow each ingress PE to choose, from the range, the demultiplexor that belongs to it. Call this the DEMULTIPLEXOR CONDITION. Suppose alternatively that there is no need for point-to-point PWs, but that multipoint-to-point PWs would be satisfactory. Call this the MULTIPOINT CONDITION. If: - The Environmental Conditions hold, and - either * the Demultiplexor Condition holds, or * 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 of each pseudowire in the set is exactly the same. Rather than connecting to each ingress PE and replicating the same information, it may make sense to send the information once to a "reflector", which will then take responsibility for distributing the information to the other PEs. INTERNET-DRAFT draft-andersson-ppvpn-l2-framework-00.txt Mar 2002 Andersson Expires Sep 2002 [Page 19] We refer to this sort of technique as "point-to-multipoint" signaling. One could, for example, 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 is proposed in [5]. When BGP-based signaling is proposed, it is usually assumed that it will be used for point-to-multipoint signaling, with route reflectors. A full mesh of individual PE-to-PE BGP connections could of course be used, but in that case using BGP is little different than using LDP or L2TP, and BGP has no particular advantages. (Note that this is very different than the more usual case in which BGP is used for distributing routing information. One could not use LDP or L2TP to distribute routing information, as they have no routing decision process, and no procedures for preventing the formation of routing loops. But pseudowire signaling is a very different application than the distribution of routing information, and BGP has no particular advantage for it, other that the possibility of using a route reflector to improve scalability (see next section)). 3.7.3 Comparison of P2P and P2MP Signaling 1. Scaling of control connections In point-to-multipoint signaling using a reflector, each PE only needs one control connection; all signaling, for all PWs, is done via this single connection. In point-to-point signaling, a given PE needs one control connection for each remote PE that is that the other end of one of the given PE's PWs. Thus there is a savings in terms of control connection state. 2. Scaling of control information If the appropriate conditions hold (as described in the previous section), then point-to-multipoint signaling results in a PE sending less signaling information than it would have to send with point-to-point signaling. Information that the PE would have to send multiple times with point-to-point signaling just gets sent once, to the reflector. The reflector duplicates this information and sends it to all the PEs that need to see it. Note however that there is no reduction on the amount of information received, only in the amount sent. This differs considerably from the more usual use of BGP route reflectors for distributing routing information. In that case, the route reflector does not simply pass on all the information it receives, INTERNET-DRAFT draft-andersson-ppvpn-l2-framework-00.txt Mar 2002 Andersson Expires Sep 2002 [Page 20] it winnows the information down by running its decision process. In the case of point-to-multipoint signaling, there is no such "winnowing down" process. Hence the use of BGP route reflectors does not have quite the same advantage as it does when used for distributing routing information. 3. The Demultiplexor Condition The Demultiplexor Condition is not something that holds naturally, it is something that must be made to hold by means of provisioning. It requires that each PE be provisioned with a Demultiplexor Range that is assigned to a particular set of Attachment Circuits. (This provisioning can be eliminated if it is desired to make the range equal to the number of Attachment Circuits in the set, but then the Demultiplexor Condition will likely fail if additional Attachment Circuits are later provisioned.) It also requires that at each PE, each set of PWs needs to be assigned a unique identifier (unique relative to the set of PEs supporting that set of PWs) which it can use, together with the Demultiplexor Range, to deterministically select a unique Demultiplexor value. This means that the identifiers must be (or be algorithmically mappable to) a sequence of numbers beginning with 1. See [5] for the details of one particular mechanism for this. 4. The Multipoint Condition In general, this condition does not hold in L2VPNs. But see section 3.9.2 for a discussion of when it does. 5. The Environmental Conditions In general, it is not clear that the environmental conditions hold. In traditional L2VPNs built over Frame Relay or ATM VCs, the individual VCs may have different characteristics with respect to, e.g., QoS, and they are really expected to provide a particular set of signals at the User/Network interface, as defined by the FR or ATM specifications. The use of point-to- multipoint signaling is awkward for passing information that applies to only a single point-to-point pseudowire, as it tends to pass the information to many more entities than need to know it. 6. Relation to Auto-Discovery If a BGP-based autodiscovery scheme is used, then the use of BGP- based point-to-multipoint signaling allows the signaling phase and the auto-discovery phase to take place simultaneously; if BGP- INTERNET-DRAFT draft-andersson-ppvpn-l2-framework-00.txt Mar 2002 Andersson Expires Sep 2002 [Page 21] based autodiscovery is used together with point-to-point signaling (as suggested in [10], then two separate phases are then required. The combination of DNS-based discovery with point-to-multipoint signaling does not appear feasible. 3.7.4 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. 3.8 Encapsulation As L2VPN packets are sent on pseudowires, the encapsulations of draft- so-pwe3-ethernet-00.txt, draft-kamapabhava-fr-pwe3-00.txt, or draft- brayley-pwe3-atm-service-01.txt should be used, depending on the L2 technology being emulated by the PW. See also sections 3.9.1 and 3.9.2. 3.9 Special Cases 3.9.1 VPWS: Like-to-like vs. Any-to-Any In VPWS, a PW connects two Attachment Circuits. If these two circuits are of like type, then the necessary emulation procedures from PWE3 should be used. If the two circuits are of unlike type, and there is a defined interworking procedure (such as the ATM/FR service interworking procedure), then we model this as, e.g., an ATM-to-ATM pseudowire, with the FR interworking function logically between the pseudowire endpoint and the FR Attachment Circuit. The interworking function is therefore transparent to the pseudowire signaling. If the two Attachment Circuits are of unlike type, and it is known that the circuits are part of a VPN which only supports IP traffic, then one can use "IP interworking", as suggested in [5]. An IP interworking pseudowire is a special type of pseudowire which can be bound at its endpoints to two different types of point-to- point Attachment Circuits. Only the IP payload is carried across the network in the pseudowire; a PWE3 encapsulation is not used. This method of interworking is transparent to the CE devices. INTERNET-DRAFT draft-andersson-ppvpn-l2-framework-00.txt Mar 2002 Andersson Expires Sep 2002 [Page 22] This is discussed more fully in [26]. Yet another way to do any-to-any interworking is by requiring the CE devices to transmit Ethernet frames on their point-to-point Attachment Circuits, using the "bridged frame" encapsulation. This also enables interworking with CE devices that attach via Ethernet interfaces to PE devices, as long as the Attachment Circuit is treated by the CE as a point-to-point Attachment Circuit, rather than as a shared LAN. 3.9.2 VPLS: IP Interworking Only 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 makecertain 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 standard IEEE 802.something address learning in the data plane to learn the MAC addresses, the PE can use the control plane to learn the MAC address. (See [26] for a discussion of this.) To eliminate the need for MAC address learning on the PWs as well as on the Attachment Circuits, 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. By eliminating the need to do MAC address learning on the PWs, we eliminate the need for the PWs to be point-to-point. Instead, multipoint PWs can be used. Hence the multipoint condition of section 3.7.2 holds. The environmental conditions of section 3.7.2 are also like to hold in this case, since the service being provided is IP connectivity, rather than Ethernet emulation. Hence this situation is a good match for point-to-multipoint signaling. Since the PWs being signaled are multipoint-to-point, there is no need for provisioning label ranges or unique identifiers. The advantage of an IP Connectivity VPLS is that it allows one to use PE devices that cannot do MAC address learning in the data plane. However, these devices would still need to be able to do packet replication onto multiple PWs in order to support layer 2 broadcast frames such as IGP Hellos. As there are no unknown DAs, multicast data would only need to be supported if IP multicast is supported. A fuller discussion of the advantages and disadvantages may be found in [26]. INTERNET-DRAFT draft-andersson-ppvpn-l2-framework-00.txt Mar 2002 Andersson Expires Sep 2002 [Page 23] 3.9.3 VPLS: Decoupling In VPLS, a PE device must perform functions, which are traditionally associated with Ethernet bridges (MAC address learning, multicast replication), as well as functions, which are usually associated with routers (e.g., routing, LDP or L2TP or BGP signaling, BGP for autodiscovery perhaps). It is worth asking whether a VPLS service can be implemented more efficiently by splitting the PE into two pieces: a user-facing piece mainly doing data plane forwarding (Forwarding-PE, F- PE) and a network-facing piece that apart form data plane forwarding also is the control part of the PE (Control-PE, C-PE). Then one could use as the C-PE a router, which doesn't have bridging capability (can't do SA learning, isn't very good at multicast replication), and use as a F-PE a switch, which does the bridging but doesn't participate in the backbone routing at all. Since multicast replication is to be done by the F-PE, if a F-PE is in a given VPLS, it must maintain state for every other F-PE, which is in the same VPLS. That is, the F-PE must have a unique pseudowire for each of the other F-PEs in the same VPLS. Hence the amount of state maintained by the F-PE is proportional to the number of F-PEs in the VPLS. Different proposals for the decoupled VPLS differ in the way they approach auto-discovery and signaling. 3.9.3.1 Auto-discovery If the auto-discovery technique is simple to implement, then there is little reason why the F-PE should not do the auto-discovery itself. E.g., if DNS-based auto-discovery is used, the F-PE can do the necessary DNS lookups, there is no reason for the C-PE to get involved in this at all. On the other hand, if BGP-based auto-discovery is used, perhaps the F-PE devices don't have BGP, and hence the C-PEs need to get involved. In this model, the F-PE needs to somehow share its configuration with its C-PE, the C-PEs do the distributed auto- discovery, and then share the discovered information somehow with the F-PE devices. This sort of model is discussed (though in a different context) in [8]. It requires that some protocol be used between F-PE and C-PE to pass the necessary configuration and discovery information. 3.9.3.2 Signaling There are two different signaling models for decoupled VPLS. In Model 1, the F-PE devices signal each to set up the necessary PWs among INTERNET-DRAFT draft-andersson-ppvpn-l2-framework-00.txt Mar 2002 Andersson Expires Sep 2002 [Page 24] themselves, using whatever pseudowire signaling protocol is appropriate. The F-PEs also create tunnels among themselves. In this model, the C- PEs have no per-VPLS state whatsoever, no pseudowire state, no tunnel state, etc. In Model 2, a C-PE figures out (most likely via a discovery procedure) which of its attached F-PE devices needs a pseudowire to which other F- PE devices. The C-PE devices then set up all the necessary PWs, by C-PE- to-C-PE signaling. In this model, when a F-PE sends a packet to an C-PE, the F-PE must tell the C-PE which pseudowire the packet needs to traverse. This requires an additional protocol between the F-PE and C-PE. The F-PE must still maintain state for each other F-PE in the same VPLS. The C-PE also maintains state for each remote F-PE, as it participates in the pseudowire and tunnel setup. Thus Model 2 reduces the number of control connections that the F-PE needs to support, at the cost of increasing the state maintained by the C-PE. Model 2 does not however eliminate the need for per-pseudowire state at the F-PE. 3.10 Quality of Service QoS parameters used in the customer network has to be transported by the PSN transparently between CEs and honoured in the PSN. 3.11 Redundancy The service infrastructure typically provides redundant paths to assure high availability. In case of L2 network service built with the help of IP or MPLS infrastructure, care is taken to provide fast recovery times approximating typical recovery times of l2 networks. In cases where the provider knows a priori about impending changes in network topology, the infrastructure is typically capable of reconfiguring the service operations without the loss of customer packets. 3.12 Multihoming In many configurations, a CE has only one link to the provider. However, high availability configurations provide for multiple accesses from the same CE to the service provider though different physical paths. In effect, the Layer 2 service becomes multihomed. INTERNET-DRAFT draft-andersson-ppvpn-l2-framework-00.txt Mar 2002 Andersson Expires Sep 2002 [Page 25] 4. Customer facing Interfaces This is for a future version of this document. 4.1 VPN Establishment at the Customer Interface This is for a future version of this document. 4.1.1 VPWS This is for a future version of this document. 4.1.1.1 Static binding This is for a future version of this document. 4.1.1.2 Dynamic binding This is for a future version of this document. 4.1.2 VPLS An attachment circuit, or a set of attachment circuits from the same customer, needs to be bound to a VSF. Such mapping can be user provisioned or can be dynamically performed as described in [32]. In the case where a single attachment circuit is provided, there is no need to perform any specific bridging function on the attachment circuit. However, in the case where multiple attachment circuits from different locations terminate within a single PE, such circuits have to be treated as virtual ports. In this latter case, typical learning and filtering functions are required on such attachment circuits. In the case of dual homing, one of the attachment circuits has to be disabled. This can be achieved either dynamically or administratively. 4.1.3 Decoupled VPLS This is for a future version of this document. 4.1.3.1 Static binding This is for a future version of this document. INTERNET-DRAFT draft-andersson-ppvpn-l2-framework-00.txt Mar 2002 Andersson Expires Sep 2002 [Page 26] 4.1.3.2 Dynamic binding This is for a future version of this document. 4.2 Data Forwarding at the Customer Interface This is for a future version of this document. 4.2.1 VPWS This is for a future version of this document. 4.2.2 VPLS This is for a future version of this document. 4.2.3 Decoupled VPLS This is for a future version of this document. 5. Core Network facing Interface This is for a future version of this document. 5.1 Network Management of L2 VPNs This is for a future version of this document. 5.1.1 VPWS This is for a future version of this document. 5.1.2 VPLS The management of a VPLS imposes specific requirements on top of the VPWS. In addition to the ability to be able monitor and administer each individual pseudo wires that constitute a VPLS instance, it is necessary to be able to monitor the VPLS service as a whole. When connectivity to a specific site is broken, an alarm may have to be generated and depending upon the user configuration or pseudo-wire attributes, the whole VPLS service might be brought down or might be preserved between the other sites. INTERNET-DRAFT draft-andersson-ppvpn-l2-framework-00.txt Mar 2002 Andersson Expires Sep 2002 [Page 27] 5.1.3 De-coupled VPLS This is for a future version of this document. 6. Security Considerations Security considerations will be addressed in a future version of this document. 6.1 System security This is for a future version of this document. 6.2 Access Control This is for a future version of this document. 6.3 Endpoint authentication This is for a future version of this document. 6.4 Data Integrity This is for a future version of this document. 6.5 Confidentiality This is for a future version of this document. 6.6 User data and Control data This is for a future version of this document. 7. List of Layer 2 VPN drafts draft-ietf-ppvpn-bgpvpn-auto-02.txt This draft defines a BGP based auto-discovery mechanism for both layer-2 VPNs and and layer-3 VPNs. This mechanism is based on the approach used by RFC2547-bis for distributing VPN routing information within the service provider(s). Each VPN scheme uses the mechanism to automatically discover the information needed by that particular scheme. INTERNET-DRAFT draft-andersson-ppvpn-l2-framework-00.txt Mar 2002 Andersson Expires Sep 2002 [Page 28] draft-ietf-ppvpn-l2vpn-00.txt This document discusses the signaling, encapsulation, and configuration issues that arise. Its purpose is to provide an architecture which allows different kinds of point-to-point virtual circuits to be provided through different kinds of IP tunnels. draft-augustyn-vpls-arch-00.txt This document describes the architecture and model for Virtual Private LAN Services (VPLS) and discusses the signaling, encapsulation, and configuration issues that arise. draft-augustyn-vpls-bw-00.txt This document describes a method for controlling customer traffic for L2 VPN services which support broadcast, multicast or implied broadcast such as e.g. VPLS. draft-augustyn-vpls-requirements-02.txt This document specifies requirements for a VPLS, the intention is to extend it to comprise all types of Layer 2 VPNs. draft-cai-ppvpn-vc-rsvp-te-00.txt This draft discusses the use of RSVP-TE as a VC setup mechanism. draft-chen-ppvpn-dvpls-compare-00.txt This draft compares different solutions for decouple PE functionality in a VPLS. It advocates a merging of existing drafts. draft-elwin-l2tpext-ppvpn-00.txt PPVPNs need a tunneling mechanism and a means to automatically discover VPN membership and signal these tunnels. This draft elaborates the use of L2TP as the tunneling mechanism, and defines extensions to L2TP to handle VPN membership discovery to leverage PPVPNs. draft-elwin-ppvpn-l2tp-arch-00.txt This document discusses the use of L2TP for establishing PPVPNs. It proposes to use L2TP for VPN membership, topology discovery, and as a tunneling mechanism. INTERNET-DRAFT draft-andersson-ppvpn-l2-framework-00.txt Mar 2002 Andersson Expires Sep 2002 [Page 29] draft-heinanen-dirldp-uni-vc-vpns-01.txt This document describes how provider based unidirectional Virtual Circuit VPNs can be implemented using a directory (such as DNS) and LDP for PE discovery and label distribution. draft-heinanen-dns-ldp-vpls-00.txt This document describes how provider provisioned Virtual Private LAN Service (VPLS) can be implemented using DNS and LDP for PE discovery and label distribution. draft-heinanen-inarp-uni-01.txt This document describes operation of an Inverse Address Resolution Protocol (InARP) over unidirectional virtual circuits such as MPLS LSPs. draft-khandekar-ppvpn-hvpls-mpls-00.txt This document proposes extensions to draft-lasserre-vkompella- ppvpn-tls-00.txt, by introducing hierarchical connectivity. This document also describes support for participation of non-bridging PE devices in a VPLS solution. draft-knight-l2vpn-lpe-ad-00.txt This document describes a lightweight protocol for VPLS information exchange between Logical PE components, consisting of the PE-Edge (i.e. in the terminology of [18]the Forwarding-PE) and PE-Core (i.e. in the terminology [18] of the Control-PE). draft-kompella-ppvpn-dtls-01.txt In a VPLS a common scenario is when Service Provider in a metro area places a simple, low-cost box (MTU, i.e. in the terminology of [18] the Forwarding-PE)) in each building; these MTUs have uplinks to some box (PE, i.e. in the terminology of [18] the Control-PE) in one or more Offices. This document describes decoupling the functions needed to offer the VPLS across the MTU and PE. draft-kompella-ppvpn-l2vpn-01.txt This document present a Layer 2 VPN solution where from the customer's point of view, the VPN is based on Layer 2 circuits, but the Service Provider maintains and manages a single network for IP, IP VPNs, and Layer 2 VPNs. INTERNET-DRAFT draft-andersson-ppvpn-l2-framework-00.txt Mar 2002 Andersson Expires Sep 2002 [Page 30] draft-kompella-ppvpn-vpls-00.txt In the case of a VPLS, a point to multipoint network connects the customers in the VPN. This document describes the functions needed to offer a VPLS, and propose a mechanism for signaling a VPLS, and a mechanism for transport of VPLS frames over tunnels across a packet switched network. draft-lasserre-vkompella-ppvpn-tls-00.txt This document describes a VPLS solution over MPLS. VPLS simulates an Ethernet virtual 802.1d bridge for a given set of users. It deliver a layer 2 broadcast domain that is fully capable of learning and forwarding on Ethernet MAC addresses that is closed to a given set of users. draft-lau-ppvpn-qos-tls-mpls-00.txt draft-lasserre-vkompella-ppvpn-vpls-00.txt describes a solution to support point-to-multipoint VPLSs over MPLS. This document describes two extensions to facilitate the provisioning and support of QoS in VPLS over MPLS. The use of the VCID field in the VC-FEC is extended to identify a VPN endpoint. One VC-label per source/destination VPN endpoint pair is used. draft-luciani-ppvpn-vpn-discovery-01.txt This document describes the use of DNS to discovery VPN endpoints. draft-martini-l2circuit-encap-mpls-04.txt This document describes methods for encapsulating the Protocol Data Units (PDUs) of layer 2 protocols such as Frame Relay, ATM, or Ethernet for transport across an MPLS or IP network. draft-martini-l2circuit-trans-mpls-08.txt This document describes methods for transporting the Protocol Data Units (PDUs) of layer 2 protocols such as Frame Relay, ATM AAL5, Ethernet, and providing a SONET circuit emulation service across an MPLS network. draft-menezes-inter-city-man-mpls-00.txt This document describes a network service model for high-speed Metropolitan Area Network (MAN) service providers to services between cities. It simplifies MAN operation and improves the scalability of a traditional standard overlay model by allowing INTERNET-DRAFT draft-andersson-ppvpn-l2-framework-00.txt Mar 2002 Andersson Expires Sep 2002 [Page 31] the MAN provider to peer to the NSP for both Internet transit and inter-city MAN services (e.g. a VPLS). draft-ouldbrahim-bgpgmpls-ovpn-02.txt This document describes a method for how a service provider network that offers Optical/TDM Virtual Private Network service. draft-ouldbrahim-l2vpn-lpe-01.txt In a VPLS a common scenario is when Service Provider in a metro area places a simple, low-cost box Edge-PE (i.e. in the terminology of [18] the Forwarding-PE) in each building; these Edge-PEs have uplinks to some box Core-PE (i.e. in the terminology of [18] the Control-PE) in one or more Offices. This document describes decoupling the functions needed to offer the VPLS across the Edge-PEs and Core-PE. draft-rosen-ppvpn-l2-signaling-01.txt This draft describes a signaling technique that eliminates the requirement for a priori knowledge of a common VC identifier, and to eliminate the requirement that each endpoint be known to the other. draft-sajassi-vpls-architectures-00.txt In this document a reference architecture for VPLS systems is defined. It describes possible VPLS architectures based on this reference architecture and the logical components of each. draft-senevirathne-vmi-frame-02.txt This document we present framework for a VPLS and a point-to-point Layer 2 VPN service. draft-shah-ppvpn-arp-mediation-00.txt This draft specifies the procedures, which the Provider Edge routers should perform in order to allow correct operation of address resolution across heterogeneous point-to-point links. draft-shah-ppvpn-vpls-pe-mtu-signaling-00.txt draft-kompella-ppvpn-dtls-01.txt identifies the need for an information exchange mechanism between a PE device (i.e. in the terminology of [18] the Control-PE) and its adjunct L2PE devices (i.e. in the terminology of [18] the Forwarding-PE) in the INTERNET-DRAFT draft-andersson-ppvpn-l2-framework-00.txt Mar 2002 Andersson Expires Sep 2002 [Page 32] decoupled VPLS. This draft proposes an LDP based approach for such exchange mechanisms. draft-tsenevir-gre-vpls-00.txt In this document a VPLS solution that use GRE and IP tunnels is described. 8. Summary and recommendations >From the number of Internet draft on requirements, architectures and solutions seen in the Layer 2 VPN area it is possible to draw the conclusion that there is a high degree on commonalties and a great interest in this area. Within the PPVPN WG it is a common understanding that the existing set of solutions need to be limited to a more manageable set of unified solutions. 8.1 Documents for VPLS type of services This for a future version of this document. 8.2 Document for VPWS type of services: This for a future version of this document. 8.3 Protocol extensions To the extent extensions are needed for protocol that originates from other working groups than PPVPN they should be handled in separate documents. 8.4 Architecture and Framework Architecture and framework issues on a general level for L2 PPVPNs should be consolidated and incorporated in this document. 9. References [1] Bradner, S. "The Internet Standards Process -- Revision 3", RFC 2026, October 1996. INTERNET-DRAFT draft-andersson-ppvpn-l2-framework-00.txt Mar 2002 Andersson Expires Sep 2002 [Page 33] [2] Bradner, S. "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [3] Hamid Ould-Brahim et al, "Using BGP as an Auto-Discovery Mechanism for Network- based VPNs", draft-ietf-ppvpn-bgpvpn- auto-02.txt Work in Progress, Internet Draft, Nov 2001 [4] Elwin Stelzer et al, "L2TP Extensions for PPVPN", 11/01, draft- elwin-l2tpext-ppvpn-00.txt [5] Kompella, K et.al. "Layer 2 VPNs Over Tunnels", draft-kompella- ppvpn-l2vpn-01.txt1, Work in Progress, Internet Draft Nov 2001 [6] Martini, L et.al. "Encapsulation Methods for Transport of Layer 2Frames Over IP and MPLS Networks", draft-martini-l2circuit- encap-mpls-04.txt, Work in Progress, Internet Draft, Nov 2001 [7] Martini, L. et.al. "Transport of Layer 2 Frames Over MPLS", draft-martini-l2circuit-trans-mpls-08.txt, Work in Progress, Internet Draft, 2001 [8] Ould-Brahim, H et.al. "BGP/GMPLS Optical/TDM VPNs", draft- ouldbrahim-bgpgmpls-ovpn-02.txt, Work in progress, Internet Draft Nov 2001, [9] Pate, P, editor, "Framework for Pseudo Wire Emulation Edge-to- Edge", draft-ietf-pwe3-framework-00.txt, Work in Progress, Internet draft Feb 2002 [10] Rosen, E "Single-Sided Signaling for L2VPNs", draft-rosen-ppvpn- l2-signaling-01.txt, Work in Progress, Internet Draft Feb 2002. [11] Rosen, E et.al. "Use of PE-PE IPsec in RFC2547 VPNs", draft- rosen-ppvpn-ipsec-2547-00.txt, Work in Progress, Internet Draft Jun 2001. [12] Heinanen, J "DNS/LDP Based VPLS", draft-heinanen-dns-ldp-vpls- 00.txt, Work in Progress, Internet Draft Jan 2002. [13] Kompella, K. et.al. "Virtual Private LAN Service", draft- kompella-ppvpn-vpls-00.txt, Work in Progress, Internet Draft Nov 2001. [14] Kompella, K. et.al. "Decoupled Virtual Private LAN Services" draft-kompella-ppvpn-dtls-01.txt, Work in Progress, Internet Draft Nov 2001. INTERNET-DRAFT draft-andersson-ppvpn-l2-framework-00.txt Mar 2002 Andersson Expires Sep 2002 [Page 34] [15] Khandekar, S. et.al. "Hierarchical Virtual Private LAN Service" draft-khandekar-ppvpn-hvpls-mpls-00.txt, Work in Progress, Internet Draft Nov 2001. [16] Lasserre, M. et.al. "Transparent VLAN Services over MPLS", draft-lasserre-vkompella-ppvpn-tls-00.txt, Work in Progress, Internet Draft Nov 2001. [17] Menezes, P. et.al. "Inter-City MAN Services Using MPLS", draft- menezes-inter-city-man-mpls-00.txt, Work in Progress, Internet Draft Nov 2001. [18] Andersson, L. and Madsen T. "VPN Terminology", draft-andersson- ppvpn-terminology-00.txt", Work in Progress, Internet Draft, February 2002. [19] Callon, R. et.al. "A Framework for Layer 3 Provider Provisioned Virtual Private Networks", draft-ietf-ppvpn-framework-04.txt, Work in Progress, Internet Draft, February 2002. [20] Ould-Brahim, H et.al "VPLS/LPE L2VPNs: Virtual Private LAN Services using Logical PE Architecture" draft-ouldbrahim-l2vpn- lpe-01.txt, Work in Progress, Internet Draft, November 2001. [21] Augustyn, W. et al. "Requirements for Virtual Private LAN Services (VPLS)", draft-augustyn-vpls-requirements-02.txt, Work in progress, Internet Draft, February 2002. This reference will be changed when a combined VPWS and VPLS requirement draft is available. [22] Sumimoto, J. et al "draft-sumimoto-ppvpn-applicability- guidelines-02.txt" Work in progress, Internet Draft, February 2002. [23] 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. [24] 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. [25] Rosen, E. "An Architecture for L2VPNs", draft-ietf-ppvpn-l2vpn- 00.txt, Work in Progress, Internet Draft July 2001. INTERNET-DRAFT draft-andersson-ppvpn-l2-framework-00.txt Mar 2002 Andersson Expires Sep 2002 [Page 35] [26] Shah, H. et.al. "ARP Mediation for IP interworking of Layer 2 VPN", draft-shah-ppvpn-arp-mediation-00.txt, Work in Progress, Internet Draft, Feb 2002. [27] Heinanen, J. "Inverse ARP over Unidirectional Virtual Circuits", draft-heinanen-inarp-uni-01.txt, Work in Progress, Internet Draft, March 2001. [28] Heinanen, J. "Directory/LDP Based Unidirectional Virtual Circuit VPNs", draft-heinanen-dirldp-uni-vc-vpns-01.txt, Work in Progress, Internet Draft, Nov 2001. [29] Sajassi, A. "VPLS Architectures", draft-sajassi-vpls- architectures-00.txt, Work in Progress, Internet Draft, Feb 2002. [30] Augustyn, W et.al. "Architecture and Model for Virtual Private LAN Services (VPLS)", draft-augustyn-vpls-arch-00.txt, Work in Progress, Internet Draft, Nov 2001. [31] Augustyn, W. "Bandwidth Management in VPLS Networks", draft- augustyn-vpls-bw-00.txt, Work in Progress, Internet Draft, Nov 2001. [32] 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. [33] Chen, M et.al. "Decoupled/Hierarchical VPLS: Commonalities and Differences", draft-chen-ppvpn-dvpls-compare-00.txt, Work in Progressm Internet Draft, Feb 2002. [34] Luciani, J. et.al. "Using DNS for VPN Discovery", draft-luciani- ppvpn-vpn-discovery-01.txt, Work in Progress, Internet Draft, Sep 2001. [35] Rosen. E. et.al. "Use of PE-PE IPsec in RFC2547 VPNs", draft- ietf-ppvpn-ipsec-2547-01.txt, Work in Progress, Internet Draft February 2002. [36] Senevirathne, T. et.al. "A Framework for Virtual Metropolitan Internetworks (VMI)", draft-senevirathne-vmi-frame-02.txt, Work in Progress, Internet Draft Feb 2002. [37] Knight, P. et.al. "Logical PE Auto-Discovery Mechanism", draft- knight-l2vpn-lpe-ad-00.txt, Work in Progress, Internet Draft Nov 2001. INTERNET-DRAFT draft-andersson-ppvpn-l2-framework-00.txt Mar 2002 Andersson Expires Sep 2002 [Page 36] [38] Eliazer, E. et.al. "PPVPN Architecture using L2TP", draft-elwin- ppvpn-l2tp-arch-00.txt, Work in Progress, Internet Draft Feb 2002. [39] Lau, WC. Et.al. "Extensions of for QoS Support in Transparent VLAN Services over MPLS", draft-lau-ppvpn-qos-tls-mpls-00.txt, Work in Progress, Internet Draft Mar 2001. [40] Senevirathne, T. "Virtual Private LAN Service (VPLS) Solution Using GRE Based IP Tunnels", draft-tsenevir-gre-vpls-00.txt, Work in Progress, Internet Draft Feb 2002. [41] Cai, T. et.al. "Signaling Virtual Circuit Label Using RSVP-TE", draft-cai-ppvpn-vc-rsvp-te-00.txt, Work in Progress, Internet Draft Nov 2001. [42] Rosen, E. et.al. "An Architecture for L2VPNs", draft-ietf-ppvpn- l2vpn-00.txt, Work in Progress, Internet Draft Jul 2001. 10. 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, Hamid Ould- Brahim, Juha Heinanen, Kireeti Kompella, Loa Andersson, Marc Lasserre, Marty Borden, Pascal Menezes, Vach Kompella and Waldemar Augustyn. The team would like to thank Marco Carugi for cooperation in setting up context and working directions in this space. 11. 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-00.txt Mar 2002