idnits 2.17.1 draft-andersson-ppvpn-l2-framework-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 3 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 44 instances of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 595 has weird spacing: '...ongs to the t...' == Line 642 has weird spacing: '...ay need to be...' == Line 1006 has weird spacing: '...elector when...' == Line 1729 has weird spacing: '...etworks marc@...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC2026' is mentioned on line 16, but not defined == Missing Reference: 'RFC2119' is mentioned on line 76, but not defined == Missing Reference: 'ANDERSSON -TERM' is mentioned on line 1401, but not defined == Missing Reference: 'MOHAN -LPE' is mentioned on line 1451, but not defined == Unused Reference: 'SHAH-INTER' is defined on line 1708, but no explicit reference was found in the text == Unused Reference: 'SHAH-SIG' is defined on line 1713, but no explicit reference was found in the text -- Possible downref: Normative reference to a draft: ref. 'ANDERSSON-METRICS' == Outdated reference: A later version (-04) exists of draft-andersson-ppvpn-terminology-00 -- Possible downref: Normative reference to a draft: ref. 'ANDERSSON-TERM' -- No information found for draft-ietf-ppvpn-bgpvpn-auto - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'BGP-AUTO' -- Possible downref: Normative reference to a draft: ref. 'DIRLDP' -- No information found for draft-heinanen - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'DNS-LDP-VPLS' == Outdated reference: A later version (-03) exists of draft-kompella-ppvpn-dtls-01 -- Possible downref: Normative reference to a draft: ref. 'KOMPELLA-DTLS' == Outdated reference: A later version (-03) exists of draft-kompella-ppvpn-l2vpn-01 -- Possible downref: Normative reference to a draft: ref. 'KOMPELLA-L2VPN' -- Possible downref: Non-RFC (?) normative reference: ref. 'KOMPELLA-VPLS' == Outdated reference: A later version (-15) exists of draft-ietf-l2tpext-l2tp-base-02 -- Possible downref: Non-RFC (?) normative reference: ref. 'L2TP-FR' -- Possible downref: Normative reference to a draft: ref. 'L2VPN-ARCH' == Outdated reference: A later version (-02) exists of draft-augustyn-ppvpn-l2vpn-requirements-00 -- Possible downref: Normative reference to a draft: ref. 'L2VPN-REQ' -- No information found for draft-ietf-ppvpn-framework - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'L3VPN-FW' -- No information found for draft-ietf-ppvpn-requirements - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'L3VPN-REQ' == Outdated reference: A later version (-04) exists of draft-lasserre-vkompella-ppvpn-vpls-01 -- Possible downref: Normative reference to a draft: ref. 'LASSERRE-VKOMPELLA-VPLS' ** Downref: Normative reference to an Historic draft: draft-martini-l2circuit-trans-mpls (ref. 'MARTINI-SIGNALING') -- No information found for draft-ouldbrahim - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'MOHAN-LPE' -- Possible downref: Normative reference to a draft: ref. 'MPLS-GRE' -- Possible downref: Normative reference to a draft: ref. 'MPLS-IP' -- No information found for draft-ietf - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'PWE3-FW' == Outdated reference: A later version (-03) exists of draft-rosen-ppvpn-l2-signaling-01 -- Possible downref: Normative reference to a draft: ref. 'ROSEN-L2-SIGNALING' -- Possible downref: Normative reference to a draft: ref. 'SAJASSI-VPLS' -- No information found for draft-shah-l2vpn-arp - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'SHAH-INTER' -- No information found for draft-shah - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'SHAH-SIG' Summary: 6 errors (**), 0 flaws (~~), 20 warnings (==), 32 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 PPVPN Working Group Loa Andersson 2 Internet-Draft Utfors AB 3 Design team editor 5 Expiration Date: December 2002 7 26 June, 2002 9 PPVPN L2 Framework 10 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with all 15 provisions of Section 10 of RFC2026 [RFC2026]. 17 Internet-Drafts are working documents of the Internet Engineering Task 18 Force (IETF), its areas, and its working groups. Note that other groups 19 may also distribute working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference material 24 or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 For potential updates to the above required-text see: 33 http://www.ietf.org/ietf/1id-guidelines.txt 35 Summary for Sub-IP related Internet Drafts 37 RELATED DOCUMENTS: 39 This being a Layer 2 vpn framework document, almost every document that 40 has been sent to the ppvpn working group is related, at least in that 41 they address provider provisioned vpn's. Even more closely related are 42 the documents that address L2 vpn's. The reference section includes a 43 list of the document we found that most useful to illustrate the issues 44 we discuss in this document. 46 WHERE DOES IT FIT IN THE PICTURE OF THE SUB-IP WORK 48 This ID is intended for the PPVPN WG. 50 INTERNET-DRAFT draft-andersson-ppvpn-l2-framework-01.txt 26.06.02 51 WHY IS IT TARGETED AT THIS WG(s) 53 PPVPN deals with provider provisioned VPNs. This document provides and a 54 framework and architecture for Layer 2 Provider Provisioned Virtual 55 Private Network services, a class of Provider Provisioned Virtual 56 Private Networks services. 58 JUSTIFICATION 60 This document is a framework for Layer 2 VPNs, one of the main topics on 61 the PPVPN WG charter, and is considered instrumental in progressing the 62 standards work within the PPVPN group. 64 Abstract 66 This document provides a framework for Layer 2 Provider Provisioned 67 Virtual Private Networks (PPVPNs). This framework is intended to aid in 68 standardizing protocols and mechanisms to support interoperable Layer 2 69 PPVPNs. 71 Conventions used in this document 73 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 74 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 75 document are to be interpreted as described in RFC-2119 [RFC2119]. 77 Contents 79 1. Introduction........................................................ 4 80 1.1 Objectives and Scope of the Document ............................ 4 81 1.2 Layer 2 Virtual Private Networks ................................ 5 82 1.3 Terminology ..................................................... 5 84 2. Models.............................................................. 6 85 2.1 Reference Model for VPWS ........................................ 6 86 2.2 Reference Model for VPLS ........................................ 6 87 2.3 Reference Model for distributed VPLS-PE or VPWS-PE.............. 7 88 2.4 VPWS-PE and VPLS-PE ............................................. 8 90 3. Functional Components of L2 VPN .................................... 8 91 3.1 Types of L2VPN................................................... 8 92 3.2 Generic L2VPN Transport Functional Components................... 10 93 3.3 VPWS............................................................ 20 94 3.4 VPLS............................................................ 26 95 3.5 IP-only LAN-like Service (IPLS) ................................ 32 97 4. Security Considerations ........................................... 33 98 4.1 System security ................................................ 33 99 4.2 Access Control.................................................. 33 101 INTERNET-DRAFT draft-andersson-ppvpn-l2-framework-01.txt 26.06.02 102 4.3 Endpoint authentication ..................................... 33 103 4.4 Data Integrity............................................... 33 104 4.5 Confidentiality ............................................. 33 105 4.6 User data and Control data .................................. 33 107 5. References......................................................... 33 109 6. Acknowledgements .................................................. 36 111 7. Authors Contact ................................................... 37 113 INTERNET-DRAFT draft-andersson-ppvpn-l2-framework-01.txt 26.06.02 114 1. Introduction 116 1.1 Objectives and Scope of the Document 118 This document provides a framework for Layer 2 Provider Provisioned 119 Virtual Private Networks (PPVPNs). This framework is intended to aid in 120 standardizing protocols and mechanisms to support interoperable Layer2 121 PPVPNs. 123 The PPVPN WG group works with both Layer 3 PPVPNs and Layer 2 PPVPNs. A 124 framework for L3 VPNs is found in [L3VPN-FW]. This document provides the 125 same type of framework for Layer 2 PPVPNs as the Layer 3 framework does 126 for Layer 3 PPVPNs. 128 The term "provider provisioned VPNs" refers to Virtual Private Networks 129 (VPNs) for which the Service Provider (SP) participates in management 130 and provisioning of the VPN. 132 There are multiple ways in which a provider can participate in a VPN, 133 and there are therefore multiple different types of PPVPNs. The 134 framework document discusses Layer2 VPNs (as defined in section 1.2). 135 It also describes technical issues related to VPNs in which the provider 136 participates in provisioning for provider edge and customer edge 137 devices. 139 First, this document discusses reference models for Layer 2 PPVPNs. Then 140 the functional components of Layer2 PPVPN operations are discussed. 142 Specifically, this includes discussion of the technical issues, which 143 are important in the design of standards and mechanisms for support of 144 Layer 2 PPVPNs. Furthermore, technical aspects of Layer2 PPVPNs 145 interworking is clarified. Finally, security issues as they apply to 146 Layer2 PPVPNs are addressed. 148 Requirements for Layer 3 VPNs are found in [L3VPN-REQ] and for Layer 2 149 VPNs, for VPLS and VPWS, in [L2VPN-REQ]. 151 This document has "inherited" a substantial content from "An 152 Architecture for L2VPNs" [L2VPN-ARCH]. 154 This document does not make choices, and does not select any particular 155 approach to support VPNs. 157 INTERNET-DRAFT draft-andersson-ppvpn-l2-framework-01.txt 26.06.02 158 1.2 Layer 2 Virtual Private Networks 160 As Layer 2 provider provisioned VPN solutions has attracted more and 161 more interest, several solutions has been proposed to the PPVPN WG. This 162 document addresses the generic components relevant for every Layer 2 VPN 163 but will not make any recommendations on the relative merits of how the 164 different components are implemented. 166 In [ANDERSSON-METRICS] parameters and metrics that could be used to 167 compare different Layer 2 VPN solutions and how they could be evaluated 168 when a L2 VPN has to meet different set of requirements is discussed. 169 The parameters to be considered in evaluating L2 VPN implementations in 170 different environments are e.g. scaling, cost, inter-domain 171 reachability, provisioning, flexibility, integration and migration from 172 existing infrastructure and services, value-added services, cost, etc. 174 Currently we see two kinds of services that a service provider could 175 offer to a customer by means of Layer 2 VPNs. Virtual Private Wire 176 Service(VPWS)and a Virtual Private LAN Service (VPLS). The possibility 177 of an IP-only LAN-like Service (IPLS) is opened up, but is very much for 178 future study. 180 A VPWS is a VPN service that supplies a L2 point-to-point service. Being 181 a point-to-point service where there are very few scaling issues with 182 the service as such. Scaling issues might arise from the number of end- 183 points that can be supported on a particular PE. 185 A VPLS is an L2 service that in all respects emulates LAN across a Wide 186 Area Network (WAN). Thus it also has all the scaling characteristics of 187 a LAN. Other scaling issues might arise from the number of end-points 188 that can be supported on a particular PE. 190 1.3 Terminology 192 This document list some terms and concepts that are specific to the L2 193 VPN framework, terms and concepts generally applicable to the PPVPN area 194 will be found in [ANDERSSON-TERM]. 196 INTERNET-DRAFT draft-andersson-ppvpn-l2-framework-01.txt 26.06.02 197 2. Models 199 2.1 Reference Model for VPWS 200 Attachment PSN Attachment 201 Circuits tunnel Circuits 202 + 203 +-----+ pseudo +----- + 204 | | wire | | 205 | CE1 |--+ +--| CE2 | 206 | | | +-----+ +-----+ +-----+ | | | 207 +-----+ +----|---- | | P | | ----+----+ +----- + 208 |VPWS\|---|-----|-----|/VPWS| 209 | PE1 |===|=====|=====| PE2 | 210 | /|---|-----|-----|\ | 211 +-----+ +----|---- | | | | ----|----+ +----- + 212 | | | +-----+ +-----+ +-----+ | | | 213 | CE3 |--+ +--| CE4 | 214 | | | | 215 +-----+ +----- + 217 2.1.1 Entities in the VPWS reference model 219 The P, PE (VPWS-PE) and CE devices and the PSN tunnel as defined in 220 [ANDERSSON-TERM]. Attachment circuit and pseudo wire as discussed in 221 section 3. The PE does a simple mapping between the PW and attachment 222 circuit based on local information, i.e. the PW de-multiplexor and 223 incoming/outgoing logical/physical port. 225 2.2 Reference Model for VPLS 227 The following diagram shows a VPLS reference model where PE devices that 228 are VPLS-capable provide a logical interconnect such that CE devices 229 belonging to a specific VPLS appear to be connected by a single logical 230 Ethernet bridge. A VPLS can contain a single VLAN or multiple, tagged 231 VLANs. 233 INTERNET-DRAFT draft-andersson-ppvpn-l2-framework-01.txt 26.06.02 234 +-----+ +-----+ 235 + CE1 +--+ +---| CE2 | 236 +-----+ | ................... | +-----+ 237 VPLS A | +----+ +----+ | VPLS A 238 | |VPLS| |VPLS| | 239 +--| PE |--Service--| PE |-+ 240 +----+ Provider +----+ 241 / . Backbone . \ - /\-_ 242 +-----+ / . | . \ / \ / \ +-----+ 243 + CE +--+ . | . +-- \ Access \----| CE | 244 +-----+ . +----+ . | Network | +-----+ 245 VPLS B .....|VPLS|........ \ / VPLS B 246 | PE | ^ ------- 247 +----+ | 248 | | 249 | | 250 +-----+ | 251 | CE3 | +-- Logical bridge 252 +-----+ 253 VPLS A 255 This reference model is adapted from [L2VPN-REQ]. The only difference 256 is that the VPLS-PE is explicitly named. 258 2.2.1 Entities in the VPLS reference model 260 The PE (VPLS-PE) and CE devices are defined in [ANDERSSON-TERM]. 262 2.3 Reference Model for distributed VPLS-PE or VPWS-PE 264 VPLS-PE/VPWS-PE 265 Functionality . . . . . . . 266 . . . . . . . . . . . . . 267 . . . . 268 +----+ . +----+ +----+ . . Service . 269 | CE | --.--|u-pe| ----|n-pe|-.---. Provider . 270 +----+ . +----+ +----+ . . Backbone . 271 . . . . . . . . . . . . . 272 . . . . . . . 274 2.3.1 Entities in the distributed VPLS-PE or VPWS-PE reference 275 model 277 A VPLS-PE or a VPWS-PE functionality may be distributed to more than one 278 device. The device closer to the customer/user is called User facing PE 280 INTERNET-DRAFT draft-andersson-ppvpn-l2-framework-01.txt 26.06.02 281 (U-PE) and the device closer to the core network is called Network 282 facing PE (N-PE). 284 For further discussion see section 3.4.3. 286 The U-PE and N-PE are defined in [ANDERSSON-TERM]. 288 2.4 VPWS-PE and VPLS-PE 290 The VPWS-PE and VPLS-PE are functionally very similar, the they both use 291 forwarders to map attachment circuits to pseudo-wires. The only 292 differences is that while the forwarder in a VPWS-PE does a one-to-one 293 mapping between the attachment circuit and psedo-wire, the forwarder in 294 a VPLS-PE is a Virtual Switching Instance (VSI) that maps multiple 295 attachment circuits to multiple pseudo-wires (for further discussion see 296 section 3.) 298 3. Functional Components of L2 VPN 300 This section specifies a functional model for L2VPN, which allows one to 301 break an L2VPN architecture down into its functional components. This 302 allows us to exhibit the roles played by the various protocols and 303 mechanisms, and thus to make it easier to understand the differences and 304 similarities between various proposed L2VPN architectures. 306 Section 3.1 contains an overview of some different types of L2VPN. In 307 section 3.2, functional components that are common to the different 308 types are discussed. Then there is a section for each of the L2VPN 309 service types being considered. The latter sections discuss functional 310 components, which may be specific to particular L2VPN types, as well as 311 discussing type-specific features of the generic components. 313 3.1 Types of L2VPN 315 The types of L2VPN are distinguished by the characteristics of the 316 service that they offer to the customers of the Service Provider (SP). 318 3.1.1 Virtual Private Wire Service (VPWS) 320 In a VPWS, each CE device is presented with a set of point-to-point 321 virtual circuits. 323 The other end of each virtual circuit is another CE device. Frames 324 transmitted by a CE on such a virtual circuit are received by the CE 325 device at the other end-point of the virtual circuit. Forwarding from 326 one CE device to another is not affected by the content of the frame, 328 INTERNET-DRAFT draft-andersson-ppvpn-l2-framework-01.txt 26.06.02 329 but is fully determined by the virtual circuit on which the frame is 330 transmitted. The PE thus acts as a virtual circuit switch. 332 This type of L2VPN has long been available over ATM and Frame Relay 333 backbones. Providing this type of L2VPN over MPLS and/or IP backbones is 334 the current topic. 336 Requirements for this type of L2VPN are specified in [L2VPN-REQ]. 338 3.1.2 Virtual Private LAN Service (VPLS) 340 In a VPLS, each CE device has one or more LAN interfaces that lead to a 341 "virtual backbone". 343 Two CEs are connected to the same virtual backbone if and only if they 344 are members of the same VPLS instance (i.e., same VPN). When a CE 345 transmits a frame, the PE that receives it examines the MAC Destination 346 Address field in order to determine how to forward the frame. 348 This is determined using standard LAN bridging techniques, such as MAC 349 Source Address Learning. (Thus unlike VPWS, VPLS allows the use of 350 addressing information in a frame's L2 header to determine the CE to 351 which a frame should be sent.) This allows a LAN to be extended 352 transparently over an MPLS and/or IP backbone. 354 VPLS is like VPWS in that forwarding is done without any consideration 355 of the Layer3 header. Unlike VPWS, VPLS allows a single CE/PE connection 356 to be used for transmitting frames to multiple remote CEs. In this 357 respect, VPLS is more like L3VPN. 359 Requirements for this type of L2VPN are specified in [L2VPN-REQ]. 361 3.1.3 IP-only LAN-like Service (IPLS) 363 An IPLS is very like a VPLS, except that: 365 - it is assumed that the CE devices are hosts or routers, not 366 switches 368 - it is assumed that the service will only carry IP packets, and 369 supporting packets such as ICMP and ARP; Layer2 packets which do 370 not contain IP are not supported. 372 While this service is a functional subset of the VPLS service, it is 373 considered separately because it may be possible to provide it using 374 different mechanisms, which may allow it to run on certain hardware 375 platforms that cannot support the full VPLS functionality. 377 INTERNET-DRAFT draft-andersson-ppvpn-l2-framework-01.txt 26.06.02 378 Andersson Expires Dec 2002 [Page 10 ] 380 3.2 Generic L2VPN Transport Functional Components 382 All L2VPN types must transport "frames" across the core network 383 connecting the PE's. In all L2VPN types, a PE (PE1) receives a frame 384 from a CE (CE1), then transports the frame to a PE (PE2), which then 385 transports the frame to a CE (CE2). In this section, we discuss the 386 functional components, which are necessary to transport L2 frames in any 387 type of L2VPN service. 389 3.2.1 Attachment Circuits 391 In any type of L2VPN, a CE device attaches to a PE device via some sort 392 of circuit or virtual circuit. We will call this an "Attachment Circuit" 393 (AC). We use this term very generally; an Attachment Circuit may be a 394 Frame Relay DLCI, an ATM VPI/VCI, an Ethernet port, a VLAN, a PPP 395 connection on a physical interface, a PPP session from an L2TP tunnel, 396 an MPLS LSP, etc. The CE device may be a router, a switch, a host, or 397 just about anything, which the customer needs hooked up to the VPN. An 398 AC carries a frame between CE and PE, or vice versa. 400 Procedures for setting up and maintaining the ACs are out of scope of 401 this architecture. 403 These procedures are generally specified as part of the specification of 404 the particular Attachment Circuit technology. 406 Any given frame will traverse an AC from a CE to a PE and then on 407 another AC from a PE to a CE. 409 We refer to the former AC as the frame's "ingress AC" and to the latter 410 AC as the frame's "egress AC". Note that this notion of "ingress AC" 411 and "egress AC" is relative to a specific frame, and denotes nothing 412 more than the frame's direction of travel while on that AC. 414 3.2.2 Pseudowires 416 A "Pseudowire" (PW) is a relation between two PE devices. Whereas an AC 417 is used to carry a frame from CE to PE, a PW is used to carry a frame 418 between two PEs. We use the term "pseudowire" in the sense of [PWE3- 419 FW]. 421 Setting up and maintaining the PWs is the job of the PEs. State 422 information for a particular PW is maintained at the two PEs which are 423 its endpoints, but not at other PEs, and not in the backbone routers (P 424 routers). 426 Pseudowires may be point-to-point, multipoint-to-point, or point-to- 427 multipoint. In this framework, point-to-point PWs are always considered 429 INTERNET-DRAFT draft-andersson-ppvpn-l2-framework-01.txt 26.06.02 430 Andersson Expires Dec 2002 [Page 11 ] 432 to be bidirectional; multipoint-to-point and point-to-multipoint PWs are 433 always considered to be unidirectional. Multipoint-to-point PWs can be 434 used only when the PE receiving a frame from the PW does not need to 435 know where the frame came from. Point-to-multipoint PWs may be useful 436 when frames need to be multicast. 438 Procedures for setting up and maintaining point-to-multipoint PWs are 439 not considered in this version of this framework. 441 Any given frame travels first on its ingress AC, then on a PW, then on 442 its egress AC. 444 Multicast frames may be replicated by a PE, so of course the information 445 carried in multicast frames may travel on more than one PW and more than 446 one egress AC. 448 Thus with respect to a given frame, a PW may be said to associate a 449 number of ACs. If these ACs are of the same technology (e.g., both ATM, 450 both Ethernet, both Frame Relay) the PW is said to provide "homogeneous 451 transport"; otherwise it is said to provide "heterogeneous transport". 452 Heterogeneous transport requires that some sort of interworking function 453 be applied. There are at least three different approaches to 454 interworking: 456 1. One of the CEs may perform the interworking locally. For example, 457 if CE1 attaches to PE1 via ATM, but CE2 attaches to PE2 via 458 Ethernet, then CE1 may decide to send/receive Ethernet frames over 459 ATM, using the RFC2684 "LLC Encapsulation for Bridged Protocols". 460 In such a case, PE1 would need to know that it is to terminate the 461 ATM VC locally, and only send/receive Ethernet frames over the PW. 463 2. One of the PEs may perform the interworking. For example, if CE1 464 attaches to PE1 via ATM, but CE2 attaches to PE2 via Frame Relay, 465 PE1 may provide the "ATM/FR Service Interworking" function. This 466 would be transparent to the CEs, and the PW would carry only Frame 467 Relay frames. 469 3. IPLS could be used. In this case the "frames" carried by the PW 470 are IP datagrams, and the two PEs need to cooperate in order to 471 spoof various L2-specific procedures used by IP (see section 3.5). 473 3.2.3 Forwarders 475 In all types of L2VPN, a PE, say PE1, receives a frame over an AC, and 476 forwards it over a PW to another PE, say PE2. PE2 then forwards the 477 frame out on another AC. 479 The case in which PE1 and PE2 are the same device is an important case 480 to handle correctly, in order to provide the L2VPN service properly. 482 INTERNET-DRAFT draft-andersson-ppvpn-l2-framework-01.txt 26.06.02 483 Andersson Expires Dec 2002 [Page 12 ] 485 However, as this case does not require any protocol, we do not further 486 address it in this document. 488 When PE1 receives a frame on a particular AC, it must determine the PW 489 on which the frame must be forwarded. In general, this is done by 490 considering: 492 - the incoming AC, 494 - possibly the contents of the frame's Layer2 header, and 496 - possibly some forwarding information which may be statically or 497 dynamically maintained. 499 If dynamic or static forwarding information is considered, the 500 information is specific to a particular L2VPN instance (i.e., to a 501 particular VPN). 503 Similarly, when PE2 receives a frame on a particular PW, it must 504 determine the AC on which the frame must be forwarded. This is done by 505 considering: 507 - the incoming PW, 509 - possibly the contents of the frame's Layer2 header, and 511 - possibly some forwarding information which may be statically or 512 dynamically maintained. 514 If dynamic or static forwarding information is considered, the 515 information is specific to a particular L2VPN instance (i.e. to a 516 particular VPN). 518 The procedures used to make the forwarding decision are known as a 519 "forwarder". We may think of a PW as being "bound", at each of its 520 endpoints, to a forwarder. The forwarder in turn "binds" the PWs to 521 ACs. Different types of L2VPN have different types of forwarders. 523 For instance, a forwarder may bind a single AC to a single PW, ignoring 524 all frame contents and using no other forwarding information. Or a 525 forwarder may bind an AC to a set of PWs and ACs, moving individual 526 frames from AC to PW, from a PW to an AC or from AC to AC by comparing 527 information from the frame's Layer2 header to information in a 528 forwarding database. This is discussed in more detail below, as we 529 consider the different L2VPN types. 531 INTERNET-DRAFT draft-andersson-ppvpn-l2-framework-01.txt 26.06.02 532 Andersson Expires Dec 2002 [Page 13 ] 534 3.2.4 Tunnels 536 A PW is carried in a "tunnel" from PE1 to PE2. We assume that an 537 arbitrary number of PWs may be carried in a single tunnel; the only 538 requirement is that the PWs all terminate at PE2. 540 We do not even require that all the PWs in the tunnel originate at PE1; 541 the tunnels may be multipoint -to-point tunnels. Nor do we require that 542 all PWs between the same pair of PEs travel in the same tunnel. All we 543 require is that when a frame traveling through such a tunnel arrives at 544 PE2, PE2 will be able to associate it with a particular PW. 546 (While one can imagine tunneling techniques that only allow one PW per 547 tunnel, they have evident scalability problems, and we do not consider 548 them further.) 550 There are a variety of different tunneling technologies which may be 551 used for the PE-PE tunnels. All that is really required is that the 552 tunneling technologies allow the proper demultiplexing of the contained 553 PWs. The tunnels might be MPLS LSPs, L2TP tunnels, IPsec tunnels, MPLS- 554 in-IP tunnels, etc. Generally the tunneling technology will require the 555 use of an encapsulation that contains a demultiplexor field, where the 556 demultiplexor field is used to identify a particular PW. Procedures for 557 setting up and maintaining the tunnels are not within the scope of this 558 framework. (But see section 3.2.6, "Pseudowire Signaling".) 560 If there are multiple tunnels from PE1 to PE2, it may be desirable to 561 assign a particular PE1-PE2 PW to a particular tunnel based on some 562 particular characteristics of the PW and/or the tunnel. For example, 563 perhaps different tunnels are associated with different QoS 564 characteristics, and different PWs require different QoS. Procedures for 565 specifying how to assign PWs to tunnels are out of scope of the current 566 framework. 568 Though point-to-point PWs are bidirectional, the tunnels in which they 569 travel need not be either bidirectional or point-to-point. For example, 570 a point-to-point PW may travel within a unidirectional multipoint -to- 571 point MPLS LSP. 573 3.2.5 Encapsulation 575 As L2VPN packets are carried in pseudowires, standard pseudowire 576 encapsulation formats and techniques (as specified by the IETF's PWE3 577 WG) should be used wherever applicable. 579 Generally the PW encapsulations will themselves be encapsulated within a 580 tunnel encapsulation, as determined by the specification of the 581 tunneling protocol. 583 INTERNET-DRAFT draft-andersson-ppvpn-l2-framework-01.txt 26.06.02 584 Andersson Expires Dec 2002 [Page 14 ] 586 It may be necessary to define additional PW encapsulations to cover 587 areas that are of importance for L2VPN, but may not be within the scope 588 of PWE3. Heterogeneous transport may be an instance of this. 590 3.2.6 Pseudowire Signaling. 592 Procedures for setting up and maintaining the PWs themselves are within 593 the scope of this framework. This includes procedures for distributing 594 demultiplexor field values, even though the demultiplexor field, 595 strictly speaking, belongs to the tunneling protocol rather than to the 596 PW. 598 The signaling for a point-to-point pseudowire must perform the following 599 functions: 601 - Distribution of the demultiplexor. 603 Since many PWs may be carried in a single tunnel, the tunneling 604 protocol must assign a demultiplexor value to each PW. These 605 demultiplexors must be unique with respect to a given tunnel (or 606 with some tunneling technologies, unique at the egress PE). 607 Generally, the PE which is the egress of the tunnel will select 608 the demultiplexor values, and will distribute them to the PE(s) 609 which is (are) the ingress(es) of the tunnel. This is the 610 essential part of the PW setup procedure. 612 Note that, as is usually the case in tunneling architectures, 613 the demultiplexor field belongs to the tunneling protocol, not 614 to the protocol being tunneled. For this reason, the PW setup 615 protocols may be extensions of the control protocols for setting 616 up the tunnels. 618 - Selection of the Forwarder at the Remote PE. 620 The signaling protocol must contain enough information to enable 621 the remote PE to select the proper forwarder to which the PW is 622 to be bound. We can call this information the "Remote Forwarder 623 Selector". The information that is required will depend on the 624 type of L2VPN being provided and on the provisioning model (see 625 sections 3.3.1 and 3.4.1) being used. The Remote Forwarder 626 Selector may uniquely identify a particular Forwarder, or it may 627 identify an attribute of Forwarders. In the latter case, it 628 would select whichever Forwarder has been provisioned with that 629 attribute. 631 - Support pseudowire emulations. 633 INTERNET-DRAFT draft-andersson-ppvpn-l2-framework-01.txt 26.06.02 634 Andersson Expires Dec 2002 [Page 15 ] 636 To the extent that a particular PW must emulate the signaling of 637 a particular Layer2 technology, the PW signaling must provide 638 the necessary functions. 640 - Distribution of State Changes. 642 Changes in the state of an AC may need to be reflected in 643 changes to the state of the PW to which the AC is bound, and 644 vice versa. The specification as to which changes need to be 645 reflected in what way would generally be within the province of 646 the PWE3 WG. 648 - Establish pseudowire characteristics. 650 To the extent that one or more characteristics of a PW must be 651 known to and/or agreed upon by both endpoints, the signaling 652 must allow for the necessary interaction. 654 As specified above, signaling for point-to-point PWs must pass enough 655 information to allow a remote PE to properly bind a PW to a Forwarder, 656 and to associate a particular demultiplexor value with that PW. Once the 657 two PEs have done the proper PW/Forwarder bindings, and have agreed on 658 the demultiplexor values, the PW may be considered to have been set up. 659 If it is necessary to negotiate further characteristics or parameters of 660 a particular PW, or to passing status information for a particular PW, 661 the PW may be identified by the demultiplexor value. 663 Signaling procedures for point-to-point pseudowires are most commonly 664 point-to-point procedures that are executed by the two PW endpoints. 665 There are however proposals to use point-to-multipoint signaling for 666 setting up point-to-point pseudowires, so this is included in the 667 framework. When PWs are themselves point-to-multipoint, it is also 668 possible to use either point-to-point signaling or point-to-multipoint 669 signaling to set them up. This is discussed in the remainder of this 670 section. 672 3.2.6.1 Point-to-Point Signaling 674 There are several ways to do the necessary point-to-point signaling. 675 Among them are: 677 - LDP 679 LDP extensions can be defined for pseudowire signaling. See for 680 example [MARTINI-SIGNALING], [ROSEN-L2-SIGNALING]. This form of 681 signaling can be used for pseudowires which are to be carried in 682 MPLS "tunnels", or in MPLS-in-something -else tunnels (e.g., 683 [MPLS-IP], [MPLS-GRE]). 685 INTERNET-DRAFT draft-andersson-ppvpn-l2-framework-01.txt 26.06.02 686 Andersson Expires Dec 2002 [Page 16 ] 688 - L2TP 690 L2TP [L2TP-BASE] can be used for pseudowire signaling, resulting 691 in pseudowires that are carried as "sessions" within L2TP 692 tunnels Pseudowire-specific extensions to L2TP may also be 693 needed, e.g., see [L2TP-FR]. 695 Other methods may be possible as well. 697 It is possible to have one control connection between a pair of PEs, 698 which is used to control many PWs. 700 The use of point-to-point signaling for setting up point-to-point PWs is 701 straightforward. Multipoint-to-point PWs can also be set up by point- 702 to-point signaling, as the remote PEs do not necessarily need to know 703 whether the PWs are multipoint-to-point or point-to-point. In some 704 signaling procedures, the same demultiplexor value may be assigned to 705 all the remote PEs. 707 3.2.6.2 Point-to-Multipoint Signaling 709 Consider the following situation: 711 - It is necessary to set up a set of PWs, all of which have the same 712 characteristics. 714 - It is not necessary to use the PW signaling protocol to pass PW 715 state changes. 717 - For each PW in the set, the same value of the Remote Forwarder 718 Selector can be used. 720 Call these the "Environmental Conditions". 722 Suppose also that there is some mechanism by which, given a range of 723 demultiplexor values, each of a set of PEs can make a unique and 724 deterministic selection of a single value from within that range. Call 725 this the "Demultiplexor Condition". Alternatively, suppose that one is 726 trying to set up a multipoint -to-point PW rather than a point-to-point 727 PW. Call this the "Multipoint Condition". 729 If: 731 - The Environmental Conditions hold, and 733 - Either 735 * the Demultiplexor Condition holds, or 737 INTERNET-DRAFT draft-andersson-ppvpn-l2-framework-01.txt 26.06.02 738 Andersson Expires Dec 2002 [Page 17 ] 740 * the Multipoint Condition holds, 742 then for a given set of PWs which terminate at egress PE1, the 743 information which PE1 needs to send to the ingress PE(s) of each 744 pseudowire in the set is exactly the same. All the ingress PE(s) 745 receive the same Forwarder Selector value. They all receive the same 746 set of PW parameters (if any). And either they all receive the same 747 demultiplexor value (if the PW is multipoint-to-point) or they all 748 receive a range of demultiplexor values from which each can choose a 749 unique demultiplexor value for itself. 751 Rather than connecting to each ingress PE and replicating the same 752 information, it may make sense either to multicast the information, or 753 to send the information once to a "reflector", which will then take 754 responsibility for distributing the information to the other PEs. 756 We refer to this sort of technique as "point-to-multipoint" signaling. 757 It would, for example, be possible to use BGP to do the signaling, with 758 the PEs being BGP peers not of each other, but of one or more BGP route 759 reflectors. 761 Such a scheme, based Multi-protocol Extensions to BGP, is proposed 762 in [KOMPELLA-L2VPN]. 764 3.2.6.3 Inter-AS Considerations 766 Pseudowires may need to run from a PE in one Service Provider's network 767 to a PE in another Service Provider's network. This means that the 768 signaling to set up the PEs must be able to cross network boundaries. 769 All known proposals for signaling are able to do this. It is especially 770 advisable to use some form of authentication between the two PW 771 endpoints in this case. 773 3.2.7 Service Quality 775 Service Quality refers to the ability for the network to deliver a 776 Service level Specification (SLS) for service attributes such as 777 protection, security and Quality of Service (QoS). The service quality 778 provided depends on the subscriber's requirements, and can be 779 characterized by a number of performance metrics. 781 The necessary Service Quality must be provided on the ACs as well as on 782 the PWs. Mechanisms for providing Service Quality on the PWs may be PW- 783 specific or tunnel-specific; in the latter case, the assignment of a PW 784 to a tunnel may depend on the Service Quality. 786 INTERNET-DRAFT draft-andersson-ppvpn-l2-framework-01.txt 26.06.02 787 Andersson Expires Dec 2002 [Page 18 ] 789 3.2.7.1 Quality of Service (QoS) 791 QoS describes the queuing behavior applied to a particular "flow", in 792 order to achieve particular goals of precedence, throughput, delay, 793 jitter, etc. 795 Based on the customer Service Level Agreement (SLA), traffic from 796 customer can be prioritized, policed and shaped for QoS requirements. 797 The queuing and forwarding po licies can preserve the packet order and 798 QoS parameters of customer traffic. The class of services can be mapped 799 from information in the customer frames, or it can be independent of the 800 frame content. 802 QoS functions can be listed as follows: 804 - Customer Traffic Prioritization: L2VPN services could be best 805 effort or QoS guaranteed. Traffic from one customer might need to 806 be prioritized over others when sharing same network resources. 807 This requires capabilities within the L2VPN solution to classify 808 and mark priority to QoS guaranteed customer traffic. 810 Proper queuing behavior would be needed at the egress AC, and 811 possibly within the backbone network as well. If queuing 812 behavior must be controlled within the backbone network, the 813 control might be based on CoS information in the MPLS or IP 814 header, or it might be achieved by nesting particular tunnels 815 within particular traffic engineering tunnels. 817 Policing: This ensures that a user of L2VPN services uses 818 network resources within the limits of the agreed SLA. Any 819 excess L2VPN traffic can be rejected or handled differently 820 based on provider policy. 822 Policing would generally be applied at the ingress AC. 824 Shaping: Under some cases the random nature of L2VPN traffic 825 might lead to sub-optimal utilization of network resources. 826 Through queuing and forwarding mechanisms the traffic can be 827 shaped without altering the packet order. 829 Shaping would generally be applied at the ingress AC. 831 3.2.7.2 Resiliency 833 Resiliency describes the ability of the L2VPN infrastructure to protect 834 a flow from network outage, so that service remains available in the 835 presence of failures. 837 INTERNET-DRAFT draft-andersson-ppvpn-l2-framework-01.txt 26.06.02 838 Andersson Expires Dec 2002 [Page 19 ] 840 L2VPN, like any other service, is subject to failures such as link, 841 trunk and node failures, both in the SP's core network infrastructure 842 and on the ACs. 844 It is desirable that the failure be detected "immediately" and 845 protection mechanisms allow fast restoration times to make L2VPN service 846 almost transparent to these failures to the extent possible, based on 847 the level of resiliency. Restoration should take place before the CEs 848 can react to the failure. Essential aspects of providing resiliency 849 are: 851 - Link/Node failure detection: Mechanisms within the L2VPN service 852 should allow for link or node failures that impact the Service, and 853 should be detected immediately. 855 - Resiliency policy: The way in which a detected failure is handled 856 will depend upon the restoration policy of the SLA associated with 857 the L2VPN service specification. It may need to be handled 858 immediately, or it may need to be handled only if no other critical 859 failure needs protection resources, or it may be completely ignored 860 if it is within the bounds of the "acceptable downtime" allowed by 861 the L2VPN service. 863 - Restoration Mechanisms: The L2VPN solutions could allow for 864 physical level protection, logical level protection or both. For 865 example, by connecting customers over redundant and physically 866 separate ACs to different provider customer-facing devices, one AC 867 can be maintained as active while the other could be marked as a 868 backup; upon the failure detection across the primary AC, the 869 backup could become active. 871 To a great extent, resiliency is a matter of having appropriate failure 872 and recovery mechanisms in the network core, including "ordinary" 873 adaptive routing as well as "fast reroute" [???] capabilities. The 874 ability to support redundant ACs between CEs and PEs also plays a role. 876 3.2.8 Management 878 An L2VPN solution can provide mechanisms to manage and monitor different 879 L2VPN components. From a Service Level Agreement (SLA) perspective, 880 L2VPN solutions could allow monitoring of L2VPN service characteristics 881 and offer mechanisms used by Service Providers to report such monitored 882 statistical data. Trouble-shooting and verification of operational and 883 maintenance activities of L2VPN services are essential requirements for 884 Service Providers. 886 INTERNET-DRAFT draft-andersson-ppvpn-l2-framework-01.txt 26.06.02 887 Andersson Expires Dec 2002 [Page 20 ] 889 3.3 VPWS 891 A VPWS is an L2VPN service in which each forwarder binds exactly one AC 892 to exactly one PW. Frames received on the AC are transmitted on the PW; 893 frames received on the PW are transmitted on the AC. The content of a 894 frame's Layer2 header plays n o role in the forwarding decision, except 895 insofar as the Layer2 header contents are used to associate the frame 896 with a particular AC (as, e.g., the DLCI field of a Frame Relay frame 897 identifies the AC). 899 A particular combination of forms a "virtual circuit" 900 between two CE devices. 902 A particular VPN (VPWS instance) may be thought of as a collection of 903 such virtual circuits, or as an "overlay" of PWs on the MPLS or IP 904 backbone. This creates an overlay topology that is in effect the 905 "virtual backbone" of a particular VPN. 907 Whether two virtual circuits are said to belong to the same VPN or not 908 is an administrative matter, based on the agreements between the SPs and 909 their customers. This may impact the provisioning model (discussed 910 below). It may also affect how particular PWs are assigned to tunnels, 911 the way QoS is assigned to particular ACs and PWs, etc. 913 Note that VPWS makes use of point-to-point PWs exclusively. 915 VPWS solutions are found e.g. in [DIRLDP], [KOMPELLA-L2VPN] and [ROSEN- 916 L2-SIGNALING]. 918 3.3.1 Provisioning and Auto-Discovery 920 Provisioning a VPWS is a matter of: 922 1. Provisioning the ACs 924 2. Providing the PEs with the necessary information to enable them to 925 set up PWs between ACs to result in the desired overlay topology. 927 3. Configuring the PWs with any necessary characteristics 929 3.3.1.1 Attachment Circuit Provisioning 931 In many cases, the ACs must be individually provisioned on the PE and/or 932 CE. This will certainly be the case if the CE/PE attachment technology 933 is a switched network, such as ATM or FR, and the VCs are PVCs rather 934 than SVCs. It is also the case whenever the individual Attachment 936 INTERNET-DRAFT draft-andersson-ppvpn-l2-framework-01.txt 26.06.02 937 Andersson Expires Dec 2002 [Page 21 ] 939 Circuits need to be given specific parameters (e.g., QoS parameters, 940 guaranteed bandwidth parameters) that differ from circuit to circuit. 942 There are also cases in which ACs might not have to be individually 943 provisioned. E.g., if an AC is just an MPLS LSP running between a CE 944 and a PE, it could be set up as the RESULT of a PW being set up, rather 945 than having to be provisioned BEFORE the PW can be set up. The same may 946 apply whenever the AC is a Switched Virtual Circuit of any sort, though 947 in this case, various policy controls might need to be provisioned, 948 e.g., limiting the number of ACs that can be set up between a given CE 949 and a given PE. 951 Issues such as whether the Attachment Circuits need to be individually 952 provisioned or not, whether they are Switched VCs or Permanent VCs, and 953 what sorts of policy controls may be applied, are implementation and 954 deployment issues, and are considered to be out of scope of this 955 framework. 957 3.3.1.2 PW Provisioning for Arbitrary Overlay Topologies 959 In order to support arbitrary overlay topologies, it is necessary to 960 allow the provisioning of individual PWs. In this model, when a PW is 961 provisioned on a PE device, it is locally bound to a specific AC. It is 962 also provisioned with information that identifies a specific AC at a 963 remote PE. 965 There are basically two variations of this provisioning model: 967 - Two-sided provisioning 969 With two-sided provisioning, each PE that is at the end of a PW 970 is provisioned with the following information: 972 * Identifier of the Local AC to which the PW is to be bound 974 * PW type and parameters 976 * IP address of the remote PE (i.e., the PE which is to be at 977 the remote end of the PW) 979 * Identifier which is meaningful to the remote PE, and which 980 can be passed in the PW signaling protocol to enable the 981 remote PE to bind the PW to the proper AC. This can be an 982 identifier of the pseudowire (as in [MARTINI-SIGNALING]), or 983 an identifier of the remote AC (as in [ROSEN-L2-SIGNALING]). 984 If a PW identifier is used, it must be unique at each of the 986 INTERNET-DRAFT draft-andersson-ppvpn-l2-framework-01.txt 26.06.02 987 Andersson Expires Dec 2002 [Page 22 ] 989 two PEs. If an AC identifier is used, it need only be unique 990 at the remote PE. 992 This identifier is then used as the Remote Forwarder Selector 993 when signaling is done (see 3.2.6.1). 995 - Single-sided Provisioning 997 With single sided provisioning, a PE at one end of a PW is 998 provisioned with the following information: 1000 * Identifier of the Local AC to which the PW is to be bound 1002 * PW type and parameters 1004 * Globally unique identifier of remote AC 1006 This identifier is then used as the Forwarder Selector when 1007 signaling is done (see section 3.2.6.1). 1009 In this provisioning model, the IP address of the remote PE is 1010 not provisioned. Rather, the assumption is that an auto- 1011 discovery scheme will be used to map the globally unique 1012 identifier to the IP address of the remote PE, along with an 1013 identifier (perhaps unique only at the latter PE) for an AC at 1014 that PE. The PW signaling protocol can then make a connection 1015 to the remote PE, passing the AC identifier, so that the remote 1016 PE binds the PW to the proper AC. (See, for example, [ROSEN-L2- 1017 SIGNALING].) 1019 This scheme requires provisioning of the PW at only one PE, but 1020 does not eliminate the need (if there is a need) to provision 1021 the ACs at both PEs. 1023 These provisioning models fit well with the use of point-to-point 1024 signaling. When each PW is individually provisioned, as the conditions 1025 necessary for the use of point-to-multipoint signaling do not hold. 1027 3.3.1.3 Colored Pools PW Provisioning Model 1029 Suppose that at each PE, sets of ACs are gathered together into "pools", 1030 and that each such pool is assigned a "color". (For example, a pool 1031 might contain all and only the ACs from this PE to a particular CE.) 1032 Now suppose we impose the following rule: whenever PE1 and PE2 have a 1033 pool of the same color, there will be a PW between PE1 and PE2 which is 1034 bound at PE1 to an arbitrarily chosen AC from that pool, and at PE2 to 1036 INTERNET-DRAFT draft-andersson-ppvpn-l2-framework-01.txt 26.06.02 1037 Andersson Expires Dec 2002 [Page 23 ] 1039 an arbitrarily chosen AC from that pool. (We do not rule out the case 1040 where a single PE has multiple pools of a given color.) 1042 For example, each pool in a particular PE might represent a particular 1043 CE device, with the ACs in the pool being the ACs connecting that CE to 1044 that PE. The color might be a VPN-id. Application of this provisioning 1045 model would then lead to a full CE-to-CE mesh within the VPN, where 1046 every CE in the VPN has a virtual circuit to every other CE within the 1047 VPN. 1049 More specifically, to provision VPWS according to this model, one 1050 provisions a set of pools, and configures each pool with the following 1051 information: 1053 - The set of ACs that belong to the pool (with no AC belonging to 1054 more than one pool) 1056 - The color 1058 - A pool identifier that is unique at least relative to the color. 1060 An auto-discovery procedure is then used to map each color into a list 1061 of ordered pairs . The occurrence of a pair 1062 on this list means that the PE at IP address X has a pool with 1063 pool id Y which is of the specified color. 1065 This information can be used to support several different signaling 1066 techniques. One possible technique proceeds as follows: 1068 - A PE finds that it has a pool of color C. 1070 - Using auto-discovery, it obtains the set of ordered pairs for 1071 color C. 1073 - For each such pair , it: 1075 * removes an AC from the pool 1077 * binds the AC to a particular PW 1079 * signals PE X via point-to-point signaling that the PW is to 1080 be bound to an AC from pool Y. 1082 This sort of technique is discussed in [ROSEN-L2-SIGNALING]. 1084 Another possible signaling technique is the following: 1086 INTERNET-DRAFT draft-andersson-ppvpn-l2-framework-01.txt 26.06.02 1087 Andersson Expires Dec 2002 [Page 24 ] 1089 - A PE finds that it has a pool of color C, containing n ACs. 1091 - It binds each AC to a PW, creating a set of PWs. This set of PWs 1092 is then organized into a sequence. (For instance, each PW may be 1093 associated with a demultiplexor field value, and the PWs may then 1094 be sequenced according to the numerical value of their respective 1095 demultiplexors.) 1097 - Using auto-discovery, it obtains the list of PE routers that have 1098 one or more pools of color C. 1100 - It signals each such PE router, specifying the sequence Q of PWs. 1102 - If PE X receives such a signal, and PE X has a pool Y of the 1103 specified color, it: 1105 * removes an AC from the pool 1107 * binds the AC to the PW which is the "Yth" PW in the sequence 1108 Q. 1110 This presumes, of course, that the pool identifiers are or can be 1111 uniquely mapped into small ordinal numbers; assigning the pool 1112 identifiers in this way becomes a requirement of the provisioning 1113 system. 1115 Note that since this technique signals the same information to all the 1116 remote PEs, it can be supported via point-to-multipoint signaling. This 1117 sort of scheme is discussed in [KOMPELLA-L2VPN]. 1119 This provisioning model can be applied as long as the following 1120 conditions hold: 1122 - There is no need to provision different characteristics for the 1123 different PWs, and 1125 - It makes no difference which pairs of ACs are bound together by 1126 PWs, as long as both ACs in the pair come from like-colored pools, 1127 and 1129 - It is possible to construct the desired overlay topology simply by 1130 assigning colors to the pools. (This is certainly simple if a full 1131 mesh is desired, or if a hub and spoke configuration is desired; 1132 creating arbitrary topologies is less simple, and perhaps not 1133 always possible.) 1135 INTERNET-DRAFT draft-andersson-ppvpn-l2-framework-01.txt 26.06.02 1136 Andersson Expires Dec 2002 [Page 25 ] 1138 3.3.2 Requirements on Auto-Discovery Procedures 1140 Some of the requirements for auto-discovery procedures can be deduced 1141 from the above. 1143 To support the single-sided provisioning model, auto-discovery must be 1144 able to map a globally unique identifier (of a PW or of an Attachment 1145 Circuit) to an IP address of a PE. 1147 To support the colored pools provisioning model, auto-discovery must 1148 enable a PE to determine the set of other PEs that contain pools of the 1149 same color. 1151 Examples of suitable auto-discovery procedures can be found in Examples 1152 of suitable auto-discovery procedures can be found in [KOMPELLA-L2VPN], 1153 [BGP-AUTO] and [ROSEN-L2-SIGNALING], and [DNS-LDP-VPLS]. 1155 These requirements enable the auto-discovery scheme to provide the 1156 information, which the PEs need to set up the PWs. 1158 There are additional requirements on the auto-discovery procedures that 1159 cannot simply be deduced from the provisioning model: 1161 - Particular signaling schemes may require additional information 1162 before they can proceed, and hence may impose additional 1163 requirements on the auto-discovery procedures. 1165 - A given Service Provider may support several different types of 1166 signaling procedures, and thus the PEs may need to learn, via auto- 1167 discovery, which signaling procedures to use. 1169 - Changes in the configuration of a PE should be reflected by the 1170 auto-discovery procedures, within a timely manner, and without the 1171 need to explicitly reconfigure any other PE. 1173 - The auto-configuration procedures must work across service provider 1174 boundaries. This rules out, e.g., the use of schemes that piggyback 1175 the auto-discovery information on the backbone's IGP. 1177 3.3.3 Heterogeneous Pseudowires 1179 Under certain circumstances, it may be desirable to have a PW that binds 1180 two ACs that use different technologies (e.g., one is ATM, one is 1181 Ethernet). There are a number of different ways, depending on the AC 1182 types, in which this can be done. For example: 1184 - If one AC is ATM and one is FR, then standard ATM/FR Network 1185 Interworking can be used. In this case, the PW might be signaled 1187 INTERNET-DRAFT draft-andersson-ppvpn-l2-framework-01.txt 26.06.02 1188 Andersson Expires Dec 2002 [Page 26 ] 1190 for ATM, with the Interworking function occurring between the PW 1191 and the FR AC. 1193 - A common encapsulation can be used on both ACs, e.g., if one AC is 1194 Ethernet and one is FR, an "Ethernet over FR" encapsulation can be 1195 used on the latter. In this case, the PW could be signaled for 1196 Ethernet, with the processing of the Ethernet over FR encapsulation 1197 being local to the PE with the FR AC. 1199 - If it is known that the two ACs attach to IP routers or hosts, and 1200 carry only IP traffic, then one could use a PW which carries the IP 1201 packets, and the respective Layer2 encapsulations would be local 1202 matters for the two PEs. However, if one of the ACs is a LAN and 1203 one is a point-to-point link, care would have to be taken to ensure 1204 that such procedures as ARP and Inverse ARP are properly handled; 1205 this might require some signaling, and some proxy functions. 1206 Further, if the CEs use a routing algorithm that has different 1207 procedures for LAN interfaces than for point-to-point interfaces, 1208 additional mechanisms may be required to ensure proper 1209 interworking. These issues are discussed in Fel! Hittar inte 1210 referensk�lla.. 1212 3.4 VPLS 1214 A VPLS is an L2VPN service in which: 1216 - The Forwarders bind multiple ACs to multiple PWs 1218 - Each Forwarder behaves as a "Virtual Switch Instance" (VSI), which 1219 performs standard LAN (i.e., Ether net) bridging functions. These 1220 include maintenance of a forwarding table by means of MAC address 1221 learning, and broadcasting of frames with unknown MAC Destination 1222 Addresses. 1224 An AC connects a CE to a VSI. Multiple CEs may be connected to a single 1225 VSI. The payload on the ACs must be Ethernet frames, with or without 1226 VLAN headers. An AC may run over any medium that can carry Ethernet 1227 frames, either natively or in some encapsulation. 1229 The set of VSIs within a single VPLS are connected via PWs; two VSIs 1230 will have a PW between them only if those two VSIs are part of the same 1231 VPN. There may be a further restriction that two VSIs have a PW between 1232 them only if those two VSIs are part of the same VLAN in the same VPN. 1234 When the CE device is itself a LAN switch, the VSI may or may not be 1235 visible as a LAN switch to the CE. That is, it may send and receive 1236 BPDUs to and from the CE, or it may simply pass a CE's BPDUs to the 1238 INTERNET-DRAFT draft-andersson-ppvpn-l2-framework-01.txt 26.06.02 1239 Andersson Expires Dec 2002 [Page 27 ] 1241 other CEs, without ever sending a BPDU of its own to the CE. Different 1242 VPLS solutions may differ in this respect. 1244 VPLS solutions are found e.g. in [DNS-LDP-VPLS], [LASSERRE-VKOMPELLA- 1245 VPLS] and [KOMPELLA-VPLS]. 1247 3.4.1 VPLS Overlay Topologies and Forwarding 1249 A VPLS emulates a LAN, in that all frame forwarding decisions are based 1250 only on the frame's MAC Destination Address (DA), the frame's "incoming 1251 port", and the contents of the forwarding table. For this purpose, both 1252 PWs and ACs are considered to be ports. The VSI forwarding decision 1253 maps a MAC DA and incoming port to an outgoing port. 1255 In order to use MAC address learning to populate the forwarding table, 1256 the PWs must be point-to-point or point-to-multipoint PWs. (Point -to- 1257 multipoint PWs may be useful when it is necessary to multicast a frame; 1258 the alternative would be replication of the frame by the PE, and 1259 transmission of each replica over a set of point-to-point PWs.) There 1260 is no use for multipoint-to-point PWs. 1262 MAC learning over a point-to-point PW is done via standard techniques, 1263 considering the PW to be a port. But MAC addresses learned over a 1264 point-to-multipoint PW whose root is PE1 would have to be treated as if 1265 they had been learned over the point-to-point PW which comes from PE1. 1267 The VSI forwarding decisions must be coordinated so that loop-free 1268 forwarding over the overlay topology is ensured. 1270 There are several possible types of overlay topologies: 1272 - Full mesh 1274 In a full mesh, every VSI in a given VPLS has exactly one point- 1275 to-point PW to every other VSI in that same VPLS. 1277 In this topology, loop free forwarding of frames is ensured by 1278 the following rule: if a frame is received over a PW, do not 1279 forward it over ANY other PW. 1281 Multicast and unknown DA packets are replicated and sent over 1282 all ports other than the one from which they were received. 1283 Alternatively, the full mesh of point-to-point PWs may be 1284 augmented with point-to-multipoint PWs, where each VSI in a VPLS 1285 is the transmitter on a single point-to -multipoint PW, and the 1286 receivers on that PW are all the other VSIs in that VPLS. 1288 - Tree Structured 1290 INTERNET-DRAFT draft-andersson-ppvpn-l2-framework-01.txt 26.06.02 1291 Andersson Expires Dec 2002 [Page 28 ] 1293 In a tree structured topology, every VSI in a particular VPLS is 1294 provisioned to be at a particular level in the tree. A given 1295 VSI has at most one pseudowire leading to a higher level. The 1296 root of the tree is considered to be the highest level. 1298 In this topology, loop free forwarding of frames is ensured by 1299 the following rule: if a frame is received over a pseudowire 1300 from a higher level, it may not be sent over a pseudowire that 1301 leads to a higher level. 1303 - Tree with Meshed Highest Level 1305 In this variant of the tree-structured topology, there may be 1306 more than one VSI at the highest level, but the set of VSIs 1307 which are at the highest level must be fully meshed. To ensure 1308 loop free forwarding, we need to impose the rule that a frame 1309 can be sent on a pseudowire to the same or higher level only if 1310 it arrived over a pseudo wire from a lower level, and frames 1311 arriving over PWs from the same level cannot be sent on PWs to 1312 the same level. 1314 Other overlay topologies are also possible, e.g., an arbitrary partial 1315 mesh of PWs among the VSIs of a VPLS. Loop-freedom could then be 1316 assured by, for example, running spanning tree on the overlay. These 1317 topologies are not further considered in this framework. 1319 Note that loop freedom in the overlay topology does not necessarily 1320 ensure loop freedom in the overall customer LAN that contains the VPLS. 1321 Improper configuration of the customer LAN (outside the limits of the 1322 VPLS) may cause looping, and frames that fall into such loops may 1323 transit the overlay topology multiple times. Procedures that enable the 1324 PE to detect and/or prevent such loops may be advisable. 1326 3.4.2 Provisioning and Auto-Discovery 1328 Each VPLS must be assigned a globally unique identifier. This can be 1329 thought of as a VPN-id. 1331 The ACs attaching the CEs to the PEs must be provisioned on both the PEs 1332 and the CEs. A VSI for that VPLS must be provisioned on the PE, and the 1333 local ACs of that VPLS must be associated with that VSI. The VSI must be 1334 provisioned with the identifier of the VPLS to which it belongs. 1336 INTERNET-DRAFT draft-andersson-ppvpn-l2-framework-01.txt 26.06.02 1337 Andersson Expires Dec 2002 [Page 29 ] 1339 An auto-discovery scheme may be used by a PE to map a VPLS identifier 1340 into the set of remote PEs that have VSIs in that VPLS. Once this set 1341 is determined, the PE can use pseudowire signaling to set up a PW to 1342 each of those VSIs. The VPLS identifier would serve as the signaling 1343 protocol's Forwarder Selector. This would result in a full mesh of PWs 1344 among the VSIs in a particular VPLS. 1346 If a single VPLS contains multiple VLANs, then it may be desirable to 1347 limit connectivity so that two VSIs are connected only if they have a 1348 VLAN in common. 1350 In this case, each VSI would need to be provisioned with one or more 1351 VLAN ids, and the auto-discovery scheme would need to map a VPLS 1352 identifier into pairs of . 1354 If a fully meshed topology of VSIs is not desired, then each VSI needs 1355 to be provisioned with additional information specifying its placement 1356 in the topology. This information would also need to be provided by the 1357 auto-discovery scheme. 1359 Examples of suitable auto-discovery procedures can be found in 1360 [KOMPELLA-L2VPN], [BGP-AUTO] and [ROSEN-L2-SIGNALING], and [DNS-LDP- 1361 VPLS]. 1363 Alternatively, the single-sided provisioning method discussed in section 1364 3.3.1.2 could be used. As this is more complicated, it would only be 1365 used if it were necessary to associate individual PWs with individual 1366 characteristics. For example, if different guaranteed bandwidths were 1367 needed between different pairs of sites within a VPLS, the PWs would 1368 have to be individually provisioned. 1370 3.4.3 Distributed PE 1372 Often when a VPLS type of service is provided, the CE devices attach to 1373 a provider-managed CPE device. This provider-managed CPE device may 1374 attach to CEs of multiple customers, especially if, e.g., there are 1375 multiple customers occupying the same building. However, this device is 1376 really part of the SP's network, hence may be considered to be a PE 1377 device. 1379 In some scenarios when a VPLS type of service is provided, the CE 1380 devices attach to a provider-managed intermediary device. This provider- 1381 managed device may attach to CEs of multiple customers. This may arise 1382 in a situation there multiple customers occupying the same building. 1383 This device is really part of the SP's network, and may for that reason 1384 be considered to be a PE device, however in the simplest case it is only 1385 performing aggregation and none of the function associated with a VPLS. 1387 INTERNET-DRAFT draft-andersson-ppvpn-l2-framework-01.txt 26.06.02 1388 Andersson Expires Dec 2002 [Page 30 ] 1390 Relative to the VPLS there are three different possibilities to allocate 1391 functions to a device in such a position in the provider network: 1393 - it can perform aggregation and pure Layer2 service only, in which 1394 case it does not really play the role of a PE device in a VPLS 1395 service. In this case the intermediary system must connect to 1396 devices that perform VPLS PE functionality; the intermediary device 1397 itself is not part of the VPLS architecture and has hence not been 1398 named in this architecture. 1400 - it can perform all the PE functions relevant for a VPLS, in such a 1401 case the device is called VPLS-PE, see [ANDERSSON -TERM]. This type 1402 of device will be connected to the core (P) routers. 1404 The PE functionality for a VPLS may be distributed between two devices, 1405 one "low-end" closer to the customer that performs e.g. the MAC-address 1406 learning and forwarding decisions, and one "high-end" that performs the 1407 control functions, e.g. establishing tunnels, PWs and VCs. We call the 1408 low-end device User-Facing PE (U-PE) and the high-end device Network- 1409 Facing PE (N-PE). 1411 It is conceivable that the U-PE may be placed very close to the 1412 customer, e.g. in a building with more than one customer. In [KOMPELLA- 1413 DTLS], these are referred to as Multi-Tenant Units, but the resulting 1414 acronym is already used for something else. In [SAJASSI-VPLS] this type 1415 of device is called PE-CLE. [MOHAN-LPE] introduces another yet another 1416 naming scheme, the U-PE is called PE-Edge and the N-PE is called PE- 1417 Core. 1419 The N-PE, in [KOMPELLA-DTLS] called L2PE and in [SAJASSI-VPLS] called 1420 PE-POP, will presumably be placed on the SP's premises. 1422 The distributed case is potentially of interest for a number of possible 1423 reasons: 1425 - The N-PE may be a device that cannot easily implement the VSI 1426 functionality described above. E.g., perhaps the N-PE is a router 1427 which cannot perform the high speed MAC learning that is needed in 1428 order to implement a VSI forwarder. At the same time, the U-PE may 1429 need to be a low-cost device that also cannot implement the full 1430 set of VPLS functions. 1432 This leads one to investigate further if there are sensible ways to 1433 split the VPLS PE functionality between the U-PE and the N-PE. 1435 - Generally, in the L2VPN architecture, the PEs are expected to 1436 participate as peers in the backbone routing protocol. Since the 1437 number of U-PEs is potentially very large relative to the number of 1439 INTERNET-DRAFT draft-andersson-ppvpn-l2-framework-01.txt 26.06.02 1440 Andersson Expires Dec 2002 [Page 31 ] 1442 N-PEs, this may be undesirable, as a matter of scaling the backbone 1443 routing protocol. 1445 - The U-PE may be a relatively inexpensive device that is unable to 1446 participate in the full range of signaling and/or auto-discovery 1447 procedures that are needed in order to provide the VPLS service. 1449 The VPLS functionality can be distributed between U-PE and N-PE in a 1450 number of different ways, and a number of different proposals have been 1451 made ([KOMPELLA-DTLS], [MOHAN -LPE], [SAJASSI-VPLS]). They all presume 1452 that the U-PE will maintain a VSI forwarder, connected by PWs to the 1453 remote VSIs; the N-PE thus does not need to perform the VSI forwarding 1454 function. The proposals tend to differ with respect to the following 1455 questions: 1457 - Should the U-PEs perform full PW signaling to set up the PWs to 1458 remote VSIs? Or should the N-PEs do this signaling? 1460 Since the U-PEs need to be able to send packets on PWs to remote 1461 VSIs and receive packets on PWs from remote VSIs, if the PW 1462 signaling is done by the N-PE, there would have to be some form of 1463 "lightweight" (presumably) signaling between N-PE and U-PE that 1464 allows the PWs to be extended from N-PE to U-PE. 1466 - Should the U-PEs do their own auto -discovery, or should this be 1467 done by the N-PEs? In the latter case, the U-PEs may need to have 1468 some means of telling the N-PEs which VPLS's they are interested 1469 in, and the N-PEs must have some means of passing the results of 1470 the auto-discovery process to the U-PE. 1472 Whether it makes sense to split auto-discovery in this manner may 1473 depend on the particular auto-discovery protocol used. One would 1474 not expect the U-PE to participate in BGP auto-discovery, e.g., but 1475 perhaps they would be expected to participate in DNS auto- 1476 discovery. 1478 - If a U-PE does not participate in routing, but is redundantly 1479 connected to two different N-PEs, can the U-PE still make an 1480 intelligent choice of the best N-PE to use as the "next hop" for 1481 traffic destined to a particular remote VSI? If not, can this 1482 choice be made as the result of some other sort of interaction 1483 between N-PE and U-PE? Or does this choice need to be established 1484 by provisioning? 1486 - If a U-PE does not participate in routing, but does participate in 1487 full PW signaling, and if MPLS is being used, how can the the N-PE 1488 send the the U-Pes the labels that the U-PE needs to send traffic 1490 INTERNET-DRAFT draft-andersson-ppvpn-l2-framework-01.txt 26.06.02 1491 Andersson Expires Dec 2002 [Page 32 ] 1493 to its signaling peers. (If the U-PE did participate in routing, 1494 this would happen automatically.) 1496 - When a frame must be multicast, should the replication be done by 1497 the N-PE or the U-PE? 1499 These questions are not all independent; the way one answers some of 1500 them may influence the way one answers others. 1502 3.4.4 Scaling issues in VPLS deployment 1504 In general, the PSN supports a VPLS solution with a tunnel from each 1505 VPLS-PE every other VPLS-PE participating in the same VPLS instance. 1506 Strictly, VPLS-PE's with more than one VPLS instance in common only need 1507 one tunnel, but for resource allocation reasons it might be necessary to 1508 establish several tunnels. For each VPLS service on a given VPLS-PE it 1509 needs to establish one pseudowire to every other VPLS-PE participating 1510 in that VPLS service. In total n*(n-1) pseudowires must be setup between 1511 the VPLS-PE routers. In large scale deployment this obviously creates 1512 scaling problems. An solution addressing the scaling problems was 1513 addressed in an Internet Draft by S Khandekar et.al. called 1514 "Hierarchical This has been addressed "Hierarchical Virtual Private LAN 1515 Service", this work has latter been included in [LASSERRE-VKOMPELLA- 1516 VPLS]. 1518 3.5 IP-only LAN-like Service (IPLS) 1520 If, instead of providing a general VPLS service, one wishes to provide a 1521 VPLS that is used only to connect IP routers or hosts (i.e., the CE 1522 devices are all assumed to be IP routers or hosts), then it is possible 1523 to make certain simplifications. 1525 In this environment, all Ethernet frames sent from a particular CE to a 1526 particular PE on a particular Attachment Circuit will have the same MAC 1527 Source Address. Thus rather than using address learning in the data 1528 plane to learn the MAC addresses, the PE can use the control plane to 1529 learn the MAC address. (See Fel! Hittar inte referensk�lla. for a 1530 discussion of this.) This allows the PE to be implemented on devices 1531 that are not capable of doing MAC address learning in the data plane. 1533 To eliminate the need for MAC address learning on the PWs as well as on 1534 the ACs, the pseudowire signaling protocol would have to carry the MAC 1535 address from one pseudowire endpoint to the other. Each PE would perform 1536 proxy ARP to its directly attached CEs. 1538 Eliminating the need to do MAC address learning on the PWs eliminates 1539 the need for the PWs to be point-to-point. Multipoint-to-point PWs could 1540 be used instead. 1542 INTERNET-DRAFT draft-andersson-ppvpn-l2-framework-01.txt 26.06.02 1543 Andersson Expires Dec 2002 [Page 33 ] 1545 Unlike a VPLS, all the ACs in an IPLS would not necessarily have to 1546 carry Ethernet frames; only the IP packets would need to be passed 1547 across the network, not their Layer2 wrappers. However, this might 1548 require "translation" between "ARP" and "Inverse ARP". The set of 1549 routing protocols which could be carried across the IPLS might also be 1550 restricted. A fuller discussion of the advantages, disadvantages, and 1551 restrictions may be found in Fel! Hittar inte referensk�lla.. 1553 4. Security Considerations 1555 Security considerations will be addressed in a future version of this 1556 document. 1558 4.1 System security 1560 This is for a future version of this document. 1562 4.2 Access Control 1564 This is for a future version of this document. 1566 4.3 Endpoint authentication 1568 This is for a future version of this document. 1570 4.4 Data Integrity 1572 This is for a future version of this document. 1574 4.5 Confidentiality 1576 This is for a future version of this document. 1578 4.6 User data and Control data 1580 This is for a future version of this document. 1582 5. References 1584 [rfc2026] 1585 Bradner, S. "The Internet Standards Process -- Revision 3", RFC 1586 2026, October 1996. 1588 INTERNET-DRAFT draft-andersson-ppvpn-l2-framework-01.txt 26.06.02 1589 Andersson Expires Dec 2002 [Page 34 ] 1591 [rfc2119] 1592 Bradner, S. "Key words for use in RFCs to Indicate Requirement 1593 Levels", RFC 2119, March 1997. 1595 [ANDERSSON-METRICS] 1596 Andersson, L. "Parameters and related metrics to compare PPVPN 1597 Layer 2 solutions", draft-andersson-ppvpn-metrics -00.txt, Work 1598 in Progrss, Internet Draft, Feb 2002. 1600 [ANDERSSON-TERM] 1601 Andersson, L. and Madsen T. "VPN Terminology", draft-andersson- 1602 ppvpn-terminology-00.txt", Work in Progress, Internet Draft, 1603 Feb 2002. 1605 [BGP-AUTO] 1606 Ould-Brahim, H. et.al. "Using BGP as an Auto-Discovery 1607 Mechanism for Network-based VPNs", Ould-Brahim et al, draft- 1608 ietf-ppvpn-bgpvpn-auto-01.txt, Work in Progress, Internet 1609 Draft, Nov 2001 1611 [DIRLDP] 1612 Heinanen, J, "Directory/LDP Based Unidirectional Virtual 1613 Circuit VPNs" draft-heinanen-dirldp-uni-vc-vpns-01.txt, Work in 1614 Progress, Internet Draft, Nov 2001 1616 [DNS-LDP-VPLS] 1617 Heinanen, J, "DNS/LDP Based VPLS", draft-heinanen -dns-ldp-vpls- 1618 00.txt, Work in Progress, Internet Draft, Jan 2002 1620 [KOMPELLA-DTLS] 1621 Kompella, K et.al. "Decoupled Virtual private LAN Services", 1622 draft-kompella-ppvpn-dtls-01.txt, December 2001 1624 [KOMPELLA-L2VPN] 1625 Kompella, K. et.al. "Layer 2 VPNs Over Tunnels", draft- 1626 kompella-ppvpn-l2vpn-01.txt, Nov 2001 1628 [KOMPELLA-VPLS] 1629 Kompella, K. "Virtual Private LAN Service", draft -kompella- 1630 ppvpn-vpls-00.txt, Work in Progress, Internet Draft, Nov 2001 1632 [L2TP-BASE] 1633 Lau, J. "Layer Two Tunneling Protocol (Version 3) L2TPv3" 1634 draft-ietf-l2tpext-l2tp-base-02.txt", Work in Progress, 1635 Internet Draft, March 2002. 1637 [L2TP-FR] 1638 Townsley, W. M. et.al. ""Frame Relay Pseudowire Extensions for 1640 INTERNET-DRAFT draft-andersson-ppvpn-l2-framework-00.txt 26.06.02 1641 Andersson Expires Dec 2002 [Page 35 ] 1643 L2TP", draft-ietf-l2tpext-pwe3-fr-00.txt, Work in Progress, 1644 Internet Draft, Feb 2002. 1646 [L2VPN-ARCH] 1647 Rosen, E. et.al. "An Architecture for L2VPNs", draft-ietf- 1648 ppvpn-l2vpn-00.txt, Work in Progress, Internet Draft Jul 2001. 1650 [L2VPN-REQ] 1651 Augustyn, W. et.al "Requirements for Layer 2 Virtual Private 1652 Network Services (L2VPN)", draft-augustyn-ppvpn-l2vpn- 1653 requirements-00.txt, Work in Progress, Internet Draft, June 1654 2002. 1656 [L3VPN-FW] 1657 Callon, R. et.al. "A Framework for Layer 3 Provider Provisioned 1658 Virtual Private Networks", draft-ietf-ppvpn-framework-05.txt, 1659 Work in Progress, Internet Draft, April 2002 1661 [L3VPN-REQ] 1662 Carugi, M. et.al. "Service requirements for Layer 3 Provider 1663 Provisioned Virtual Private Networks" draft-ietf-ppvpn- 1664 requirements-04.txt, Work in Progress, Internet Draft, Feb 1665 2002. 1667 [LASSERRE-VKOMPELLA-VPLS] 1668 Lasserre, M. et.al. "Virtual Private LAN Services over MPLS", 1669 draft-lasserre-vkompella-ppvpn-vpls-01.txt, Work in progress, 1670 Internet Draft, Mar 2002. 1672 [MARTINI-SIGNALING] 1673 Martini, L. et.al. "Transport of Layer 2 Frames Over MPLS", 1674 draft-martini-l2circuit-trans-mpls -08.txt, Work in Progress, 1675 [MOHAN-LPE] 1676 Mohan, D. et.al. "VPLS/LPE L2VPNs: Virtual Private LAN Services 1677 using Logical PE Architecture ", draft-ouldbrahim -l2vpn-lpe- 1678 02.txt, Work in Progress, Internet Draft, Mar 2002 1680 [MPLS-GRE] 1681 Rekhter, Y. "MPLS Label Stack Encapsulation in GRE", Rekhter et 1682 al, draft-rekhter-mpls-over-gre-03.txt, Work in Progress, 1683 Internet Draft Sep, 2001. 1685 [MPLS-IP] 1686 Worster, T. et.al. "MPLS Label Stack Encapsulation in IP", 1687 Worster et al, draft-worster-mpls-in-ip-05.txt, Work in 1688 Progress, Internet Draft, Jul 2001. 1690 INTERNET-DRAFT draft-andersson-ppvpn-l2-framework-00.txt 26.06.02 1691 Andersson Expires Dec 2002 [Page 36 ] 1693 [PWE3-FW] 1694 Pate, P. editor, "Framework for Pseudo Wire Emulation Edge-to- 1695 Edge", Pate, P. editor, draft-ietf -pwe3-framework -00.txt, Work 1696 in Progress, Internet draft, Feb 2002 1698 [ROSEN-L2-SIGNALING] 1699 Rosen, E. "Single-Sided Signaling for L2VPNs", draft-rosen- 1700 ppvpn-l2-signaling-01.txt, Work in Progress, Internet Draft, 1701 Feb 2002 1703 [SAJASSI-VPLS] 1704 Sajassi, A. "VPLS Architectures", draft-sajassi-vpls- 1705 architectures-00.txt , Work in Progress, Internet Draft, Feb 1706 2002. 1708 [SHAH-INTER] 1709 Shah, H. et.al. "IP address resolution for IP interworking of 1710 Layer 2 VPN", draft-shah-l2vpn-arp -resolve-00.txt, Work in 1711 Progress, Internet Draft, Jan 2002 1713 [SHAH-SIG] 1714 Shah, H. et.al. "Signaling between PE and L2PE/MTU for 1715 Decoupled VPLS and Hierarchical VPLS", draft-shah -ppvpn-vpls - 1716 pe-mtu-signaling-00.txt, Work in Progress, Internet Draft, Feb 1717 2002. 1719 6. Acknowledgements 1721 This document is the outcome of discussions within the PPVPN Layer 2 VPN 1722 design team. The members of the design team are 1724 Eric Rosen, Cisco Systems erosen@cisco.com 1725 Hamid Ould-Brahim, Nortel Networks hbrahim@nortelnetworks.com 1726 Juha Heinanen, Song Networks jh@lohi.eng.song.fi 1727 Kireeti Kompella, Juniper Networks kireeti@juniper.net 1728 Loa Andersson, Utfors AB, loa.andersson@utfors.se 1729 Marc Lasserre, Riverstone Networks marc@riverstonenet.com 1730 Marty Borden, Atrica mborden@atrica.com 1731 Pascal Menezes, Terrabeam Pascal.Menezes@Terabeam.com 1732 Vach Kompella, Timetra Networks vkompella@timetra.com 1733 Vasile Radoaca Nortel Networks vasile@nortelnetworks.com 1734 Waldemar Augustyn, waldemar@nxp.com 1736 The team would like to thank Marco Carugi for cooperation in setting up 1737 context, working directions and taking time for discussions in this 1738 space. The team would also like to thank Tove Madsen for valuable input 1739 and reviews. 1741 INTERNET-DRAFT draft-andersson-ppvpn-l2-framework-01.txt 26.06.02 1742 Andersson Expires Dec 2002 [Page 37 ] 1744 7. Authors Contact 1746 Loa Andersson (editor) 1747 Utfors AB 1748 P.O Box 525 1749 SE-169 29 Solna 1750 tel: +46 8 52 70 50 38 1751 email: loa.andersson@utfors.se 1753 INTERNET-DRAFT draft-andersson-ppvpn-l2-framework-01.txt 26.06.02