idnits 2.17.1 draft-augustyn-ppvpn-l2vpn-requirements-02.txt: -(207): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1130): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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: ---------------------------------------------------------------------------- ** Missing revision: the document name given in the document, 'draft-augustyn-ppvpn-l2vpn-requirements-', does not give the document revision number ~~ Missing draftname component: the document name given in the document, 'draft-augustyn-ppvpn-l2vpn-requirements-', does not seem to contain all the document name components required ('draft' prefix, document source, document name, and revision) -- see https://www.ietf.org/id-info/guidelines#naming for more information. == Mismatching filename: the document gives the document name as 'draft-augustyn-ppvpn-l2vpn-requirements-', but the file name used is 'draft-augustyn-ppvpn-l2vpn-requirements-02' == There are 12 instances of lines with non-ascii characters in the document. 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 abstract seems to contain references ([RFC-2119]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 335 has weird spacing: '... in PEs is hi...' -- The exact meaning of the all-uppercase expression 'NOT REQUIRED' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: The internal structure of a L2VPN SHOULD not be advertised nor discoverable from outside that L2VPN. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: 4.6 Addressing A L2VPN solution MUST support overlapping addresses of different L2VPNs. For instance, customers SHOULD not be prevented from using == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Since the IPLS solution aims at transporting encapsulated traffic (rather than L2 frames themselves) the IPLS solution MUST not alter == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The provided mechanisms MUST satisfy the following: the connectivity checking for a given customer MUST enable the end-to-end testing of the data path used by that customer's data packets and the test packets MUST not propagate beyond the boundary of the SP network. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: 8.2 Data Plane Requirements 8.2.1 Encapsulation A L2VPN solution SHOULD utilize the encapsulation techniques defined by PWE3 ([PWE3-FR]), and SHOULD not impose any new requirements on these techniques. == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC-2026' is mentioned on line 18, but not defined == Missing Reference: 'RFC-2119' is mentioned on line 61, but not defined == Missing Reference: 'PPVPN-REQTS' is mentioned on line 960, but not defined == Unused Reference: 'RFC2026' is defined on line 1258, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 1260, but no explicit reference was found in the text == Unused Reference: 'GENERIC-REQTS' is defined on line 1269, but no explicit reference was found in the text Summary: 4 errors (**), 1 flaw (~~), 16 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET DRAFT W. Augustyn 3 Internet Engineering Task Force 4 Document: Y. Serbest 5 draft-augustyn-ppvpn-l2vpn-requirements- SBC 6 02.txt 7 February 2003 (Co-Editors) 8 Category: Informational 9 Expires: August 2003 11 Service Requirements for Layer 2 Provider Provisioned Virtual Private 12 Networks 14 Status of this memo 16 This document is an Internet-Draft and is in full conformance with 17 all provisions of Section 10 of RFC 2026 ([RFC-2026]). 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six 25 months and may be updated, replaced, or obsoleted by other documents 26 at any time. It is inappropriate to use Internet-Drafts as 27 reference material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This document is a product of the IETF's Provider Provisioned 36 Virtual Private Network (ppvpn) working group. Comments SHOULD be 37 addressed to WG's mailing list at ppvpn@ppvpn.francetelecom.com. The 38 charter for ppvpn may be found at 39 http://www.ietf.org/html.charters/ppvpn-charter.html 41 Copyright (C) The Internet Society (2000). All Rights Reserved. 42 Distribution of this memo is unlimited. 44 Abstract 46 This document provides requirements for Layer 2 Provider Provisioned 47 Virtual Private Networks (PPVPNs). It first provides taxonomy and 48 terminology and states generic and general service requirements. It 49 covers point to point VPNs referred to as Virtual Private Wire 50 Service (VPWS), as well as multipoint to multipoint VPNs also known 51 as Virtual Private LAN Service (VPLS). Detailed requirements are 52 expressed from a customer as well as a service provider perspective. 54 Augustyn et al 1 55 Conventions used in this document 57 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 58 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 59 this document are to be interpreted as described in RFC 2119 ([RFC- 60 2119]). 62 Table of Contents 63 1 Contributing Authors..............................................4 64 2 Introduction......................................................4 65 2.1Scope of this document...........................................4 66 2.2Outline..........................................................5 67 3 Definitions and Taxonomy..........................................5 68 3.1Definitions......................................................5 69 3.2Taxonomy of Layer 2 PPVPN Types..................................5 70 3.3VPWS.............................................................6 71 3.4VPLS.............................................................6 72 4 Service Requirements Common to Customers and Service Providers....7 73 4.1Scope of emulation...............................................7 74 4.2Traffic Types....................................................8 75 4.3Topology.........................................................8 76 4.4Isolated Exchange of Data and Forwarding Information.............8 77 4.5Security.........................................................8 78 4.5.1 User data security........................................9 79 4.5.2 Access control............................................9 80 4.6Addressing.......................................................9 81 4.7Quality of Service..............................................10 82 4.7.1 QoS Standards............................................10 83 4.7.2 Service Models...........................................10 84 4.8Service Level Specifications....................................10 85 4.9Protection and Restoration......................................10 86 4.10 CE-to-CE and CE-to-PE link requirements.......................11 87 4.11 Management....................................................11 88 4.12 Interoperability..............................................11 89 4.13 Inter-working.................................................12 90 5 Customer Requirements............................................12 91 5.1Service Provider Independence...................................12 92 5.2Layer 3 Support.................................................12 93 5.3Quality of Service and Traffic Parameters.......................12 94 5.4Service Level Specification.....................................13 95 5.5Security........................................................13 96 5.5.1 Isolation................................................13 97 5.5.2 Access control...........................................13 98 5.5.3 Value added security services............................13 99 5.6Network Access..................................................13 100 5.6.1 Physical/Link Layer Technology...........................13 101 5.6.2 Access Connectivity......................................13 102 5.7Customer traffic................................................15 103 5.7.1 Unicast, Unknown Unicast, Multicast, and Broadcast 104 forwarding.......................................................15 105 5.7.2 Packet Re-ordering.......................................15 106 5.7.3 Minimum MTU..............................................15 108 Augustyn et al Informational - Expires August 2003 2 109 5.7.4 End-point VLAN tag translation...........................15 110 5.7.5 Transparency.............................................15 111 5.8Support for Layer 2 Control Protocols...........................16 112 5.9CE Provisioning.................................................16 113 6 Service Provider Network Requirements............................16 114 6.1Scalability.....................................................16 115 6.1.1 Service Provider Capacity Sizing Projections.............16 116 6.1.2 Solution-Specific Metrics................................17 117 6.2Identifiers.....................................................17 118 6.3Discovering L2VPN Related Information...........................18 119 6.4SLS Support.....................................................18 120 6.5Quality of Service (QoS)........................................18 121 6.6Isolation of Traffic and Forwarding Information.................19 122 6.7Security........................................................19 123 6.8Inter-AS (SP) L2VPNs............................................19 124 6.8.1 Management...............................................19 125 6.8.2 Bandwidth and QoS Brokering..............................20 126 6.9L2VPN Wholesale.................................................20 127 6.10 Tunneling Requirements........................................20 128 6.11 Support for Access Technologies...............................20 129 6.12 Backbone Networks.............................................21 130 6.13 Network Resource Partitioning and Sharing Between L2VPNs......21 131 6.14 Interoperability..............................................21 132 6.15 Testing.......................................................22 133 6.16 Support on Existing PEs.......................................22 134 7 Service Provider Management Requirements.........................22 135 8 Engineering Requirements.........................................22 136 8.1Control Plane Requirements......................................22 137 8.2Data Plane Requirements.........................................23 138 8.2.1 Encapsulation............................................23 139 8.2.2 Responsiveness to Congestion.............................23 140 8.2.3 Broadcast Domain.........................................23 141 8.2.4 Virtual Switching Instance...............................23 142 8.2.5 MAC address learning.....................................24 143 9 Security Considerations..........................................24 144 10 Acknowledgments..................................................24 145 11 References.......................................................24 146 11.1 Normative References..........................................24 147 11.2 Non-normative References......................................25 148 12 Editors' Addresses...............................................25 150 Augustyn et al Informational - Expires August 2003 3 151 1 Contributing Authors 152 This document was the combined effort of several individuals. The 153 following are the authors that contributed to this document: 155 Waldemar Augustyn 156 Marco Carugi 157 Giles Heron 158 Vach Kompella 159 Marc Lasserre 160 Pascal Menezes 161 Hamid Ould-Brahim 162 Tissa Senevirathne 163 Yetik Serbest 165 2 Introduction 166 This section describes the scope and outline of the document. 168 2.1 Scope of this document 169 This document provides requirements for Layer 2 Provider Provisioned 170 Virtual Private Networks (L2-PPVPN). It identifies requirements that 171 MAY apply to one or more individual approaches that a Service 172 Provider MAY use for the provisioning of a Layer 2 VPN service. The 173 content of this document makes use of the terminology defined in 174 [TERMINOLOGY] and common components for deploying Layer 2 PPVPNs 175 (will be referred to as L2VPNs) described in [PPVPN-L2-FR]. 176 The technical specifications to provide L2VPN services are outside 177 the scope of this document. The framework document [PPVPN-L2-FR] and 178 several documents, which explain technical approaches providing 179 Layer 2 PPVPN services, are available to cover this aspect. 181 This document describes requirements for two types of L2VPNs: 1. 182 Virtual Private Wire Service (VPWS), and 2. Virtual Private LAN 183 Service (VPLS). The approach followed in this document distinguishes 184 L2VPN types as to how the connectivity is provided (point-point or 185 multipoint-multipoint) as detailed in [PPVPN-L2-FR]. 187 This document is intended as a "checklist" of requirements that will 188 provide a consistent way to evaluate and document how well each 189 individual approach satisfies specific requirements. The 190 applicability statement documents for each individual approach 191 SHOULD document the results of this evaluation. 193 In the context of provider provisioned VPNs, there are two entities 194 involved in operation of such services, the Provider and the 195 Customer. The Provider engages in a binding agreement with the 196 Customer as to the behavior of the service in normal situation as 197 well as exceptional situations. Such agreement is known as Service 198 Level Specification (SLS) which is part of the Service Level 199 Agreement (SLA) established between the Provider and the Customer. 201 Augustyn et al Informational - Expires August 2003 4 202 A proper design of L2VPNs aids formulation of SLSs in that it 203 provides means for proper separation between CE/PE, allows proper 204 execution of the SLS offer, and supports flexible and rich set of 205 capabilities. 207 This document provides requirements from both the Provider�s and the 208 Customer�s point of view. It begins with common customer�s and 209 service provider�s point of view, followed by a customer�s 210 perspective, and concludes with specific needs of a Service Provider 211 (SP). These requirements provide high-level L2VPN features expected 212 by a SP in provisioning L2VPNs, which include SP requirements for 213 security, privacy, manageability, interoperability and scalability, 214 in addition to service provider projections for number, complexity, 215 and rate of change of customer VPNs over the next several years. 217 2.2 Outline 218 The outline of the rest of this document is as follows. Section 3 219 defines terminology. Section 4 provides common requirements that 220 apply to both customer and service providers respectively. Section 5 221 states requirements from a customer perspective. Section 6 states 222 network requirements from a service provider perspective. Section 7 223 states service provider management requirements. Section 8 describes 224 the engineering requirements, particularly control and data plane 225 requirements. Section 9 provides security considerations. Section 10 226 lists acknowledgements. Section 11 provides a list of references 227 cited herein. Section 12 lists the editors� addresses. 229 3 Definitions and Taxonomy 230 3.1 Definitions 231 The terminology used in this document is defined in [TERMINOLOGY]. 232 The Layer 2 PPVPN framework document [PPVPN-L2-FR] further describes 233 these concepts in the context of a reference model that defines 234 layered service relationships between devices and one or more levels 235 of tunnels. 237 3.2 Taxonomy of Layer 2 PPVPN Types 238 The requirements distinguish two major L2VPNs models, a Virtual 239 Private Wire Service (VPWS), and a Virtual Private LAN Service 240 (VPLS). 242 The following diagram shows a L2VPN reference model. 244 +-----+ +-----+ 245 + CE1 +--+ +---| CE2 | 246 +-----+ | ........................ | +-----+ 247 L2VPN A | +----+ +----+ | L2VPN A 248 +--| PE |--- Service ---| PE |--+ 249 +----+ Provider +----+ 250 / . Backbone . \ - /\-_ 251 +-----+ / . | . \ / \ / \ +-----+ 252 + CE4 +--+ . | . +--\ Access \----| CE5 | 253 +-----+ . +----+ . | Network | +-----+ 255 Augustyn et al Informational - Expires August 2003 5 256 L2VPN B .........| PE |......... \ / L2VPN B 257 +----+ ^ ------- 258 | | 259 | | 260 +-----+ | 261 | CE3 | +-- Logical switching instance 262 +-----+ 263 L2VPN A 265 Figure 1 L2VPN Reference Model 266 3.3 VPWS 267 The PE devices provide a logical interconnect such that a pair of CE 268 devices appear to be connected by a single logical Layer 2 circuit. 269 PE devices act as Layer 2 circuit switches. Layer 2 circuits are 270 then mapped onto tunnels in the service provider network. These 271 tunnels can either be specific to a particular VPWS, or shared among 272 several VPWSs. VPWS applies for all services including Ethernet, 273 ATM, Frame Relay etc. In Figure 1, L2VPN B represents a VPWS case. 275 Each PE device is responsible for allocating customer Layer 2 frames 276 to the appropriate VPWS and for proper forwarding to the intended 277 destinations. 279 3.4 VPLS 280 In case of VPLS, the PE devices provide a logical interconnect such 281 that CE devices belonging to a specific VPLS appear to be connected 282 by a single LAN. End-to-end VPLS consists of a bridge module and a 283 LAN emulation module ([PPVPN-L2-FR]). A VPLS can contain a single 284 VLAN or multiple VLANs. A variation of this service is IPLS, which 285 is limited to supporting only customer IP traffic. 287 In a VPLS, a customer site receives layer 2 service from the SP. The 288 PE is attached via an access connection to one or more CEs. The PE 289 performs forwarding of user data packets based on information in the 290 Layer 2 header, such as a MAC destination address. The CE sees a 291 bridge. 293 In VPLS, the PE can be viewed as containing a Virtual Switching 294 Instance (VSI) for each Layer 2 VPN that it serves. A CE device 295 attaches, possibly through an access network, to a "Bridge" module 296 of a PE. Within the PE, the Bridge module attaches, through an 297 "Emulated LAN Interface" to an Emulated LAN. For each VPLS, there is 298 an Emulated LAN instance. In Figure 1, the top PE routers maintain 299 separate Emulated LAN instances for VPLS A and VPLS B. The Emulated 300 LAN consists of "VPLS Forwarder" module (one per PE per VPLS 301 instance) connected by pseudowires, where the pseudowires may be 302 traveling through Packet Switched Network (PSN) tunnels over a 303 routed backbone. VSI is a logical entity that contains a VPLS 304 forwarder module and part of the bridge module relevant to the VPLS 305 instance [PPVPN-L2-FR]. Hence, the VSI terminates pseudo-wires for 306 interconnection with other VSIs and also terminates attachment 307 circuits for accommodating CEs. A VSI includes the forwarding 309 Augustyn et al Informational - Expires August 2003 6 310 information base for a L2VPN [PPVPN-L2-FR] which is the set of 311 information regarding how to forward Layer 2 frames received over 312 the attachment circuit from the CE to VSIs in other PEs supporting 313 the same L2VPN (and/or to other attachment circuits), and contains 314 information regarding how to forward Layer 2 frames received from 315 pseudowires to attachment circuits. Forwarding information bases 316 can be populated dynamically (such as by source MAC address 317 learning) or statically (e.g., by configuration). Each PE device is 318 responsible for proper forwarding of the customer traffic to the 319 appropriate destination(s) based on the forwarding information base 320 of the corresponding VSI. 322 4 Service Requirements Common to Customers and Service Providers 323 This section contains requirements that apply to both the customer 324 and the provider, or are of an otherwise general nature. 326 4.1 Scope of emulation 327 L2VPN protocols SHOULD NOT interfere with existing Layer 2 protocols 328 and standards of the Layer 2 network the customer is managing. If 329 they may impact customer Layer 2 protocols that are sent over the 330 VPLS, then these impacts MUST be documented. 332 Some possibly salient differences between VPLS and a real LAN are: 333 - The reliability MAY likely be less, i.e., the probability that a 334 message broadcast over the VPLS is not seen by one of the bridge 335 modules in PEs is higher than in a true Ethernet. 336 - If sequencing is not turned on, BPDUs on a pseudowire may get 337 out of order with respect to data packets and with respect to each 338 other. 339 - VPLS frames can get duplicated if the sequencing option isn't 340 turned on. The data frames on the pseudowires are sent in IP 341 datagrams, and under certain failure scenarios, IP networks can 342 duplicate packets. If the pseudowire data transmission protocol 343 does not ensure sequence of data packets, frames can be duplicated 344 or received out of sequence. If the customer�s BPDU frames are 345 sent as data packets, then BPDU frames can be duplicated or mis- 346 sequenced. 347 - Delayed delivery of packets (e.g., more than half a second) 348 rather than dropping them could have adverse effect on the 349 performance of the service. 350 - 802.3x Pause frames will not be transported over a VPLS, as the 351 bridge module ([PPVPN-L2-FR]) in the PE terminates them. 352 - Since the IPLS solution aims at transporting encapsulated 353 traffic (rather than Layer 2 frames themselves), the IPLS solution 354 is NOT REQUIRED to preserve the Layer 2 Header transparently from 355 CE to CE. For example, Source MAC address may not be preserved by 356 the IPLS solution. 358 The interaction between L2VPN and the customer equipment SHOULD 359 comply with existing native protocols and specifications. In case, a 360 L2VPN solution supports only a subset of these specifications, the 361 exceptions MUST be documented. 363 Augustyn et al Informational - Expires August 2003 7 364 4.2 Traffic Types 365 A VPLS MUST support unicast, multicast, and broadcast traffic. It 366 is desirable to support efficient replication of broadcast and 367 multicast traffic. 369 4.3 Topology 370 A SP network MAY be realized using one or more network tunnel 371 topologies to interconnect PEs, ranging from simple point-to-point 372 to distributed hierarchical arrangements. The typical topologies 373 include: 375 o Point-to-point 376 o Point-to-multipoint, a.k.a. hub and spoke 377 o Any-to-any, a.k.a. full mesh 378 o Mixed, a.k.a. partial mesh 379 o Hierarchical 381 Regardless of the SP topology employed, the service to the customers 382 MUST retain the connectivity type implied by the type of L2VPN. For 383 example, a VPLS SHOULD allow multipoint to multipoint connectivity 384 even if implemented with point to point circuits. This requirement 385 does not imply that all traffic characteristics (such as bandwidth, 386 QoS, delay, etc.) be necessarily the same between any two end points 387 of a L2VPN. It is important to note that SLS requirements of a 388 service have a bearing on the type of topology that can be used. 390 To the extent possible, a L2VPN service SHOULD be capable of 391 crossing multiple administrative boundaries. 393 To the extent possible, the L2VPN services SHOULD be independent of 394 access network technology. 396 4.4 Isolated Exchange of Data and Forwarding Information 397 L2VPN solutions SHALL define means that prevent CEs in a L2VPN from 398 interaction with unauthorized entities. 400 L2VPN solutions SHALL avoid introducing undesired forwarding 401 information that could corrupt the L2VPN forwarding information 402 base. 404 A means to constrain, or isolate, the distribution of addressed data 405 to only those VPLS sites determined either by MAC learning and/or 406 configuration MUST be provided. 408 The internal structure of a L2VPN SHOULD not be advertised nor 409 discoverable from outside that L2VPN. 411 4.5 Security 412 A range of security features SHOULD be supported by the suite of 413 L2VPN solutions. Each L2VPN solution SHOULD state which security 415 Augustyn et al Informational - Expires August 2003 8 416 features it supports and how such features can be configured on a 417 per customer basis. 419 A number of security concerns arise in the setup and operation of a 420 L2VPN, ranging from mis-configurations to attacks that may be 421 launched on a L2VPN. This section lists some potential security 422 hazards. There MUST be methods available to protect against the 423 following situations. 425 - Protocol attacks 426 o Excessive protocol adjacency setup/teardown 427 o Excessive protocol signaling/withdrawal 428 - Resource Utilization 429 o Forwarding plane replication (VPLS) 430 o Looping (VPLS primarily) 431 o MAC learning table size limit (VPLS) 432 - Unauthorized access 433 o Unauthorized member of VPN 434 o Incorrect customer interface 435 o Incorrect service delimiting VLAN tag 436 o Unauthorized access to PE 437 - Tampering with signaling 438 o Incorrect FEC signaling 439 o Incorrect label assignment 440 o Incorrect signaled VPN parameters (e.g., QoS, MTU, etc.) 441 - Tampering with data forwarding 442 o Incorrect MAC learning entry 443 o Incorrect label 444 o Incorrect customer facing encapsulation 445 o Incorrect pseudo-wire encapsulation 446 o Hijacking pseudowires using the wrong tunnel 447 o Incorrect tunnel encapsulation 449 4.5.1 User data security 450 L2VPN solution MUST provide traffic separation between different 451 L2VPNs. 453 In case of VPLS, VLAN Ids MAY be used as service delimiters. When 454 used in this manner, they MUST be honored and traffic separation 455 MUST be provided. 457 4.5.2 Access control 458 A L2VPN solution MAY also have the ability to activate the 459 appropriate filtering capabilities upon request of a customer. 461 4.6 Addressing 462 A L2VPN solution MUST support overlapping addresses of different 463 L2VPNs. For instance, customers SHOULD not be prevented from using 465 Augustyn et al Informational - Expires August 2003 9 466 the same MAC addresses and/or the same VLAN Ids when used with 467 different L2VPNs. Actually, for VLANs, there are two cases. First, a 468 L2VPN is oblivious to customer VLANs. In this case, customers can 469 have overlapping VLAN Ids. Second, VLAN Ids MAY be used as service 470 delimiters, in which case it depends on whether the SP assigns the 471 VLANs or not. If it does, then there is no overlapping. If it 472 doesn't, then overlapping VLAN Ids can occur and the SP has to put 473 safeguards in place to avoid this situation. 475 4.7 Quality of Service 476 To the extent possible, L2VPN QoS SHOULD be independent of the 477 access network technology. 479 4.7.1 QoS Standards 480 As provided in [PPVPN-REQTS] a L2PVN SHALL be able to support QoS in 481 one or more of the following already standardized modes: 482 - Best Effort (support mandatory for all PPVPN types) 483 - Aggregate CE Interface Level QoS (i.e., �hose� level) 484 - Site-to-site, or �pipe� level QoS 486 Note that all cases involving QoS MAY require that the CE and/or PE 487 perform shaping and/or policing. 489 Mappings or translations of Layer 2 QoS parameters into Packet 490 Switched Network QoS (e.g., DSCPs or MPLS EXP field) as well as QoS 491 mapping based on VC (e.g., FR/ATM or VLAN) MAY be performed in order 492 to provide QoS transparency. The actual mechanisms for these 493 mappings or translations are outside the scope of this document. In 494 addition, the Diffserv support of underlying tunneling technologies 495 (e.g., [RFC3270] or [RFC3308]) and the Intserv model ([RFC2205]) MAY 496 be used. As such, the L2VPN SLS requirements should be supported by 497 appropriate core mechanisms. 499 4.7.2 Service Models 500 A service provider MUST be able to offer QoS service to a customer 501 for at least the following generic service types: managed access VPN 502 service or an edge-to-edge QoS service. The details of the service 503 models can be found in [PPVPN-REQTS] and in [L3REQTS]. In L2VPN 504 service, both DSCP and 802.1p fields MAY be used for this purpose. 506 4.8 Service Level Specifications 507 For a L2VPN service, the capabilities for Service Level 508 Specification (SLS) monitoring and reporting stated in [PPVPN-REQTS] 509 SHOULD be provided as appropriate. 511 4.9 Protection and Restoration 512 The L2VPN service infrastructure SHOULD provide redundant paths to 513 assure high availability. The reaction to failures SHOULD result in 514 an attempt to restore the service using alternative paths. 516 The intention is to keep the restoration time small. The restoration 517 time MUST be less than the time it takes the CE devices, or customer 519 Augustyn et al Informational - Expires August 2003 10 520 Layer 2 control protocols as well as Layer 3 routing protocols, to 521 detect a failure in the L2VPN. 523 4.10 CE-to-CE and CE-to-PE link requirements 524 The CE-to-PE links MAY either be direct physical links, e.g. 525 100BaseTX, T1/E1 TDM or logical links, e.g. ATM PVC, or RFC2427- 526 encapsulated link, or transport networks carrying Ethernet, or a 527 Layer 2 tunnel that go through a layer 3 network (e.g., L2TP 528 sessions), over which Layer 2 traffic is carried. 530 Layer 2 frames MAY be tunneled through a layer 3 backbone from PE to 531 PE, using one of a variety of tunneling technologies (e.g., IP-in- 532 IP, GRE, MPLS, L2TP, etc.). 534 4.11 Management 535 Standard interfaces to manage L2VPN services MUST be provided 536 (e.g., standard SNMP MIBs). These interfaces SHOULD provide access 537 to configuration, verification and runtime monitoring protocols. 539 Service management MAY include the TMN 'FCAPS' functionalities, as 540 follows: Fault, Configuration, Accounting, Provisioning, and 541 Security, as detailed in [L3REQTS]. 543 The ITU-T Telecommunications Management Network (TMN) model has the 544 following generic requirements structure: 545 o Engineer, deploy and manage the switching, routing and 546 transmission resources supporting the service, from a network 547 perspective (network element management); 548 o Manage the L2VPNs deployed over these resources (network 549 management); 550 o Manage the L2VPN service (service management); 551 o Manage the L2VPN business, mainly provisioning, administrative 552 and accounting information related to the L2VPN service customers 553 (business management). 555 4.12 Interoperability 556 Multi-vendor interoperability at network element, network and 557 service levels among different implementations of the same technical 558 solution SHOULD be guaranteed (that will likely rely on the 559 completeness of the corresponding standard). This is a central 560 requirement for SPs and customers. 562 The technical solution MUST be multi-vendor interoperable not only 563 within the SP network infrastructure, but also with the customer's 564 network equipment and services making usage of the L2VPN service. 566 A L2VPN solution SHOULD NOT preclude different access technologies. 567 For instance, customer access connections to a L2VPN service MAY be 568 different at different CE devices (e.g., Frame Relay, ATM, 802.1d, 569 MPLS). 571 Augustyn et al Informational - Expires August 2003 11 572 4.13 Inter-working 573 Inter-working scenarios among different solutions, providing L2VPN 574 services, are highly desirable. Inter-working SHOULD be supported in 575 a scalable manner. 577 Inter-working scenarios MUST consider at least traffic isolation, 578 security, QoS, access, and management aspects. This requirement is 579 essential in the case of network migration, to ensure service 580 continuity among sites belonging to different portions of the 581 network. 583 5 Customer Requirements 584 This section captures requirements from a customer perspective. 586 5.1 Service Provider Independence 587 Customers MAY require L2VPN service that spans multiple 588 administrative domains or service provider networks. Therefore, a 589 L2VPN service MUST be able to span multiple AS and SP networks, but 590 still to act and to appear as a single, homogenous L2VPN from a 591 customer point of view. 593 A customer might also start with a L2VPN provided in a single AS 594 with a certain SLS but then ask for an expansion of the service 595 spanning multiple ASs/SPs. In this case, as well as for all kinds of 596 multi-AS/SP L2VPNs, L2VPN service SHOULD be able to deliver the same 597 SLS to all sites in a VPN regardless of the AS/SP to which it homes. 599 5.2 Layer 3 Support 600 With the exception of IPLS, a L2VPN service SHOULD be agnostic to 601 customer�s layer 3 traffic (e.g., IP, IPX, Appletalk) encapsulated 602 within Layer 2 frames. 604 IPLS MUST allow transport of IPv4 and IPv6 customer�s traffic 605 encapsulated within Layer 2 frames. IPLS SHOULD also allow CEs to 606 run ISIS and MPLS protocols transparently among them when those are 607 used in conjunction with IP. 609 5.3 Quality of Service and Traffic Parameters 610 QoS is expected to be an important aspect of a L2VPN service for 611 some customers. 613 A customer requires that the L2VPN service provide the QoS 614 applicable to his or her application, which can range from pseudo- 615 wires (e.g., SONET emulation) to voice and interactive video, and 616 multimedia applications. Hence, best-effort as well as delay and 617 loss sensitive traffic MUST be supported over a L2VPN service. 618 A customer application SHOULD experience consistent QoS independent 619 of the access network technology used at different sites connected 620 to the same L2VPN. 622 Augustyn et al Informational - Expires August 2003 12 623 5.4 Service Level Specification 624 Most customers simply want their applications to perform well. A SLS 625 is a vehicle for a customer to measure the quality of the service 626 that SP(s) provide. Therefore, when purchasing a service, a customer 627 requires access to the measures from the SP(s) that support the SLS. 629 Standard interfaces to monitor usage of L2VPN services SHOULD be 630 provided (e.g., standard SNMP MIBs). 632 5.5 Security 633 5.5.1 Isolation 634 A L2VPN solution MUST provide traffic as well as forwarding 635 information base isolation for customers similar to that obtained in 636 private lines, FR, or ATM services. 638 A L2VPN service MAY use customer VLAN identifications as service 639 delimiters. In that case, they MUST be honored and traffic 640 separation MUST be provided. 642 5.5.2 Access control 643 A L2VPN solution MAY have the mechanisms to activate the appropriate 644 filtering capabilities upon request of a customer. For instance, MAC 645 and/or VLAN filtering MAY be considered between CE and PE for a 646 VPLS. 648 5.5.3 Value added security services 649 A L2VPN solution MAY provide value added security services such as 650 encryption and/or authentication of customer packets, certificate 651 management, and similar. 653 Security measures employed by a L2VPN service SHOULD NOT restrict 654 implementation of customer based security add-ons. 656 5.6 Network Access 657 Every packet exchanged between the customer and the SP over the 658 access connection MUST appear as it would on a private network 659 providing an equivalent service to that offered by the L2VPN. 661 5.6.1 Physical/Link Layer Technology 662 L2VPNs SHOULD support a broad range of physical and link layer 663 access technologies, such as PSTN, ISDN, xDSL, cable modem, leased 664 line, Ethernet, Ethernet VLAN, ATM, Frame Relay, Wireless local 665 loop, mobile radio access, etc. The capacity and QoS achievable MAY 666 be dependent on the specific access technology in use. 668 5.6.2 Access Connectivity 669 Various types of physical connectivity scenarios MUST be supported, 670 such as multi-homed sites, backdoor links between customer sites, 671 devices homed to two or more SP networks. In case of VPLS, multi- 672 link access for CE devices SHOULD be supported. L2VPN solutions 673 SHOULD support at least the types of physical or link-layer 674 connectivity arrangements shown in Figure 2 (in addition to the case 676 Augustyn et al Informational - Expires August 2003 13 677 shown in Figure 1). For example, in case (b) a CE MAY connect to two 678 different SPs via diverse access networks. Resiliency MAY be further 679 enhanced as shown in case (d), where CE's, connected via a "back 680 door" connection, connect to different SPs. Furthermore, arbitrary 681 combinations of the above methods, with a few examples shown in 682 cases (e) and (f) SHOULD be supportable by any L2VPN solution. 684 +---------------- +--------------- 685 | | 686 +------+ +------+ 687 +---------| PE | +---------| PE | 688 | |device| | |device| SP network 689 | +------+ | +------+ 690 +------+ | +------+ | 691 | CE | | | CE | +--------------- 692 |device| | SP network |device| +--------------- 693 +------+ | +------+ | 694 | +------+ | +------+ 695 | | PE | | | PE | 696 +---------|device| +---------|device| SP network 697 +------+ +------+ 698 | | 699 +---------------- +--------------- 700 (a) (b) 701 +---------------- +--------------- 702 | | 703 +------+ +------+ +------+ +------+ 704 | CE |-----| PE | | CE |-----| PE | 705 |device| |device| |device| |device| SP network 706 +------+ +------+ +------+ +------+ 707 | | | | 708 | Backdoor | | Backdoor +--------------- 709 | link | SP network | link +--------------- 710 | | | | 711 +------+ +------+ +------+ +------+ 712 | CE | | PE | | CE | | PE | 713 |device|-----|device| |device|-----|device| SP network 714 +------+ +------+ +------+ +------+ 715 | | 716 +---------------- +--------------- 717 (c) (d) 718 +---------------- +--------------- 719 | | 720 +------+ +------+ +------+ +------+ 721 | CE |-----| PE | | CE |-----| PE | 722 |device| |device| |device| |device| SP network 723 +------+\ +------+ +------+\ +------+ 724 | \ | | \ | 725 |Back \ | |Back \ +--------------- 726 |door \ | SP network |door \ +--------------- 727 |link \ | |link \ | 728 +------+ +------+ +------+ +------+ 730 Augustyn et al Informational - Expires August 2003 14 731 | CE | | PE | | CE | | PE | 732 |device|-----|device| |device|-----|device| SP network 733 +------+ +------+ +------+ +------+ 734 | | 735 +---------------- +--------------- 736 (e) (f) 737 Figure 2 Representative types of access arrangements. 739 5.7 Customer traffic 740 5.7.1 Unicast, Unknown Unicast, Multicast, and Broadcast forwarding 741 A VPLS MUST deliver every packet at least to its intended 742 destination(s) within the scope of the VPLS subject to the ingress 743 policing and security policies. 745 5.7.2 Packet Re-ordering 746 The queuing and forwarding policies SHOULD preserve packet order for 747 packets with the same QoS parameters. 749 5.7.3 Minimum MTU 750 A VPLS MUST support the theoretical MTU of the offered service. 752 The committed minimum MTU size MUST be the same for a given VPLS 753 instance. Different L2VPN services MAY have different committed MTU 754 sizes. If the customer VLANs are used as service delimiters, all 755 VLANs within a given VPLS MUST inherit the same MTU size. 757 A VPLS MAY fragment packets as long as it is transparent to the 758 customer. 760 5.7.4 End-point VLAN tag translation 761 The L2VPN service MAY support translation of customers' attachment 762 circuit identifiers (e.g., VLAN tags, if the customer VLANs are used 763 as service delimiters). Such service simplifies connectivity of 764 sites that want to keep their attachment circuit assignments or 765 sites that belong to different administrative domains. In the latter 766 case, the connectivity is sometimes referred to as Layer 2 extranet. 767 On the other hand, it SHOULD be noted that VLAN tag translation 768 affects the support for multiple spanning trees (i.e., 802.1s) and 769 can break the proper operation. 771 5.7.5 Transparency 772 The L2VPN service is intended to be transparent to Layer 2 customer 773 networks. A L2VPN solution SHOULD NOT require any special packet 774 processing by the end users before sending packets to the provider's 775 network. 777 If VLAN-ids are assigned by the SP, then VLANs are not transparent. 778 Transparency does not apply in this case, as it is the same as 779 FR/ATM service model. 781 Since the IPLS solution aims at transporting encapsulated traffic 782 (rather than L2 frames themselves) the IPLS solution MUST not alter 784 Augustyn et al Informational - Expires August 2003 15 785 the packets encapsulated inside Layer 2 frames which are transported 786 by the IPLS. However, the IPLS solution is NOT REQUIRED to preserve 787 the L2 Header transparently from CE to CE. For example, Source MAC 788 address may not be preserved by the IPLS solution. The IPLS solution 789 MAY remove Layer 2 headers for transport over the backbone when 790 those can be reconstructed on egress without compromising transport 791 of encapsulated traffic. 793 5.8 Support for Layer 2 Control Protocols 794 The L2VPN solution SHOULD allow transparent operation of Layer 2 795 control protocols employed by customers. 797 In case of VPLS, the L2VPN service MUST ensure that loops be 798 prevented. This can be accomplished through a loop free topologies 799 or appropriate forwarding rules. Control protocols such as Spanning 800 Tree (STP) or similar could be employed. The L2VPN solution MAY use 801 indications from customer Layer 2 control protocols, e.g. STP BPDU 802 snooping, to improve the operation of a VPLS. 804 5.9 CE Provisioning 805 The L2VPN solution MUST require only minimal or no configuration on 806 the CE devices, depending on the CE device that connects into the 807 infrastructure. 809 6 Service Provider Network Requirements 810 This section describes requirements from a service provider 811 perspective. 813 6.1 Scalability 814 This section contains projections regarding L2VPN sizing projections 815 and scalability requirements and metrics specific to particular 816 solutions. 818 6.1.1 Service Provider Capacity Sizing Projections 819 This section captures projections for scaling requirements over the 820 next several years in terms of number of L2VPNs, number of 821 interfaces per L2VPN, the size of forwarding information base per 822 L2VPN, and the rate of L2VPN configuration changes. The examples are 823 provided in [PPVPN-REQTS]. 825 The numbers provided in this section are examples and MUST be 826 treated as such. A L2VPN solution MAY scale much more than the 827 examples provided here. Each requirement in this section MUST be 828 considered independently. 830 A L2VPN solution SHOULD be scalable to support a very large number 831 of L2VPNs per Service Provider network. The estimate is that a large 832 service provider will require support O(10^5) VPWSs and O(10^4) 833 VPLSs within the next four years. 835 A L2VPN solution SHOULD be scalable to support of a wide range of 836 number of site interfaces per VPLS, depending on the size and/or 838 Augustyn et al Informational - Expires August 2003 16 839 structure of the customer organization. The number of site 840 interfaces SHOULD range from a few site interfaces to O(10^2) site 841 interfaces per VPLS. 843 A L2VPN solution SHOULD be scalable to support a wide range of 844 number of customer addresses (e.g., MAC) per VPLS. The number of 845 customer addresses per VPLS MAY range from just a few (i.e., the 846 number of sites when the CE devices are routers or when the service 847 is IPLS) to a very large number such as 1,000 (i.e., when CE devices 848 are switches). The number of customer addresses would be on the 849 order of addresses supported in a typical native Layer 2 backbone. 851 A L2VPN solution SHOULD support high values of the frequency of 852 configuration setup and change, e.g., for real-time provisioning of 853 an on-demand videoconferencing or addition/deletion of sites. 855 Approaches SHOULD articulate scaling and performance limits for more 856 complex deployment scenarios, such as inter-AS(S) L2VPNs and 857 carriers' carrier. Approaches SHOULD also describe other dimensions 858 of interest, such as capacity requirements or limits, number of 859 inter-working instances supported as well as any scalability 860 implications on management systems. 862 The number of users per VPLS is the combination of servers and hosts 863 connected to the VPLS. It needs to scale from a handful to high 864 numbers. A VPLS MUST scale from 2 users to a few hundred. 866 The number of users per VPLS interface follows the same logic as for 867 users per VPLS. Further, it MUST be possible to have single user 868 sites connected to the same VPLS as very large sites are connected 869 to. VPLSs MUST scale from 1 user to a few hundred per site. 871 The number of sites per VPLS is clearly limited by the number of 872 users for a VPLS. The largest number of sites in a VPLS would be 873 equal to the largest number of users, distributed one per site. 875 The number of L2VPNs SHOULD scale linearly with the size of the 876 access network and with the number of PEs. 878 6.1.2 Solution-Specific Metrics 879 Each L2VPN solution SHALL document its scalability characteristics 880 in quantitative terms. 882 6.2 Identifiers 883 A SP domain MUST be uniquely identified at least within the set of 884 all interconnected SP networks when supporting a L2VPN that spans 885 multiple SPs. Ideally, this identifier SHOULD be globally unique 886 (e.g., an AS number). 888 An identifier for each L2VPN SHOULD be unique, at least within each 889 SP's network, as it MAY be used in auto-discovery, management (e.g, 890 alarm and service correlation, troubleshooting, performance 892 Augustyn et al Informational - Expires August 2003 17 893 statistics collection), and signaling. Ideally, the L2VPN identifier 894 SHOULD be globally unique to support the case, where a L2VPN spans 895 multiple SPs (e.g., [RFC2685]). Globally unique identifiers 896 facilitate the support of inter-AS/SP L2VPNs. 898 6.3 Discovering L2VPN Related Information 899 Configuration of PE devices (i.e., U-PE and N-PE) is a significant 900 task for a service provider. Solutions SHOULD provide methods that 901 dynamically allow L2VPN information to be discovered by the PEs to 902 minimize the configuration steps. 904 Each device in a L2VPN SHOULD be able to determine which other 905 devices belong to the same L2VPN. Such a membership discovery 906 scheme MUST prevent unauthorized access and allows authentication of 907 the source. 909 Distribution of L2VPN information SHOULD be limited to those devices 910 involved in that L2VPN. A L2VPN solution SHOULD employ discovery 911 mechanisms to minimize the amount of operational information 912 maintained by the SPs. For example, if a SP adds or removes a 913 customer port on a given PE, the remaining PEs SHOULD determine the 914 necessary actions to take without the SP having to explicitly 915 reconfigure those PEs. 917 A L2VPN solution SHOULD support the means for attached CEs to 918 authenticate each other and verify that the service provider L2VPN 919 is correctly configured. 921 The mechanism SHOULD respond to L2VPN membership changes in a timely 922 manner. A "timely manner" is no longer than the provisioning 923 timeframe, typically on the order of minutes, and MAY be as short as 924 the timeframe required for "rerouting," typically on the order of 925 seconds. 927 Dynamically creating, changing, and managing multiple L2VPN 928 assignments to sites and/or customers is another aspect of 929 membership that MUST be addressed in a L2VPN solution. 931 6.4 SLS Support 932 Typically, a SP offering a L2VPN service commits to specific Service 933 Level Specifications (SLS) as part of a contract with the customer. 934 Such a Service Level Agreement (SLA) drives the specific SP 935 requirements for measuring Specific Service Level Specifications 936 (SLS) for quality, availability, response time, and configuration 937 intervals. 939 6.5 Quality of Service (QoS) 940 A significant aspect of a PPVPN is support for QoS. A SP has control 941 over the provisioning of resources and configuration of parameters 942 in at least the PE and P devices, and in some cases, the CE devices 943 as well. Therefore, the SP is to provide either managed QoS access 944 service, or edge-to-edge QoS service, as defined in [L3REQTS]. 946 Augustyn et al Informational - Expires August 2003 18 947 6.6 Isolation of Traffic and Forwarding Information 948 From a high level SP perspective, a L2VPN MUST isolate the exchange 949 of traffic and forwarding information to only those sites that are 950 authenticated and authorized members of a L2VPN. 952 A L2VPN solution SHOULD provide a means for meeting PPVPN QoS SLS 953 requirements that isolates L2VPN traffic from the affects of traffic 954 offered by non-VPN customers. Also, L2VPN solutions SHOULD provide a 955 means so that traffic congestion produced by sites as part of one 956 L2VPN does not affect another L2VPN. 958 6.7 Security 959 The security requirements are stated in Section 4.5. The 960 requirements provided in [PPVPN-REQTS] and in [L3REQTS] SHOULD be 961 met as appropriate. 963 In addition, a SP network MUST be immune to malformed or maliciously 964 constructed customer traffic. This includes but not limited to 965 duplicate or invalid Layer 2 addresses, customer side loops, 966 short/long packets, spoofed management packets, spoofed VLAN tags, 967 high volume traffic. 969 The SP network devices MUST NOT be accessible from any L2VPN, unless 970 specifically authorized. The devices in the PPVPN network SHOULD 971 provide some means of reporting intrusion attempts to the SP, if the 972 intrusion is detected. 974 6.8 Inter-AS (SP) L2VPNs 975 All applicable SP requirements, such as traffic and forwarding 976 information isolation, SLS's, management, security, provisioning, 977 etc. MUST be preserved across adjacent AS�s. The solution MUST 978 describe the inter-SP network interface, encapsulation method(s), 979 routing protocol(s), and all applicable parameters [VPN-IW]. 981 A L2VPN solution MUST provide the specifics of offering L2VPN 982 services spanning multiple ASs and/or SPs. 984 A L2VPN solution MUST support proper dissemination of operational 985 parameters to all elements of a L2VPN service in the presence of 986 multiple ASs and/or SPs. A L2VPN solution MUST employ mechanisms for 987 sharing operational parameters between different ASs 989 A L2VPN solution SHOULD support policies for proper selection of 990 operational parameters coming from different ASs. Similarly, a L2VPN 991 solution SHOULD support policies for selecting information to be 992 disseminated to different ASs. 994 6.8.1 Management 995 The general requirements for managing a single AS apply to a 996 concatenation of AS's. A minimum subset of such capabilities is the 997 following: 999 Augustyn et al Informational - Expires August 2003 19 1000 - Diagnostic tools 1001 - Secured access to one AS management system by another 1002 - Configuration request and status query tools 1003 - Fault notification and trouble tracking tools 1005 6.8.2 Bandwidth and QoS Brokering 1006 When a L2VPN spans multiple AS's, there is a need for a brokering 1007 mechanism that requests certain SLS parameters, such as bandwidth 1008 and QoS, from the other domains and/or networks involved in 1009 transferring traffic to various sites. The essential requirement is 1010 that a solution MUST be able to determine whether a set of AS's can 1011 establish and guarantee uniform QoS in support of a PPVPN. 1013 6.9 L2VPN Wholesale 1014 The architecture MUST support the possibility of one SP offering 1015 L2VPN service to another SP. One example is when one SP sells L2VPN 1016 service at wholesale to another SP, who then resells that L2VPN 1017 service to his or her customers. 1019 6.10 Tunneling Requirements 1020 Connectivity between CE sites or PE devices in the backbone SHOULD 1021 be able to use a range of tunneling technologies, such as L2TP, GRE, 1022 IP-in-IP, MPLS, etc. 1024 Every PE MUST support a tunnel setup protocol, if tunneling is used. 1025 A PE MAY support static configuration. If employed, a tunnel 1026 establishment protocol SHOULD be capable of conveying information, 1027 such as the following: 1028 - Relevant identifiers 1029 - QoS/SLS parameters 1030 - Restoration parameters 1031 - Multiplexing identifiers 1032 - Security parameters 1034 There MUST be a means to monitor the following aspects of tunnels: 1035 - Statistics, such as amount of time spent in the up and down 1036 state 1037 - Count of transitions between the up and down state 1038 - Events, such as transitions between the up and down states 1040 The tunneling technology used by the VPN Service Provider and its 1041 associated mechanisms for tunnel establishment, multiplexing, and 1042 maintenance MUST meet the requirements on scaling, isolation, 1043 security, QoS, manageability, etc. 1045 Regardless of the tunneling choice, the existence of the tunnels and 1046 their operations MUST be transparent to the customers. 1048 6.11 Support for Access Technologies 1049 The connectivity between PE and CE devices is referred to as an 1050 Attachment Circuit (AC). ACs MAY span networks of other providers or 1051 public networks. 1053 Augustyn et al Informational - Expires August 2003 20 1054 There are several choices for implementing ACs. Some popular choices 1055 include Ethernet, ATM (DSL), Frame Relay, MPLS-based virtual 1056 circuits etc. 1058 In case of VPLS, the AC MUST use Ethernet frames as the Service 1059 Protocol Data Unit (SPDU). 1061 A CE access connection over an AC MUST be bi-directional in nature. 1063 PE devices MAY support multiple ACs on a single physical interface. 1064 In such cases, PE devices MUST NOT rely on customer controlled 1065 parameters for distinguishing between different access connections. 1066 For example, if VLAN tags were used for that purpose, the provider 1067 would be controlling the assignment of the VLAN tag values and would 1068 strictly enforce compliance by the CEs. 1070 An AC, whether direct or virtual, MUST maintain all committed 1071 characteristics of the customer traffic, such as QoS, priorities 1072 etc. The characteristics of an AC are only applicable to that 1073 connection. 1075 6.12 Backbone Networks 1076 Ideally, the backbone interconnecting SP PE and P devices SHOULD be 1077 independent of physical and link layer technology. Nevertheless, the 1078 characteristics of backbone technology MUST be taken into account 1079 when specifying the QoS aspects of SLSs for VPN service offerings. 1081 6.13 Network Resource Partitioning and Sharing Between L2VPNs 1082 In case network resources such as memory space, FIB table, bandwidth 1083 and CPU processing are shared between L2VPNs, the solution SHOULD 1084 guarantee availability of resources necessary to prevent any 1085 specific L2VPN instance from taking up available network resources 1086 and causing others to fail. The solution SHOULD be able to limit the 1087 resources consumed by a L2VPN instance. The solution SHOULD 1088 guarantee availability of resources necessary to fulfill the 1089 obligation of committed SLSs. 1091 6.14 Interoperability 1092 Service providers are interested in interoperability in at least the 1093 following scenarios: 1094 - To facilitate use of PE and managed CE devices within a single 1095 SP network 1096 - To implement L2VPN services across two or more interconnected SP 1097 networks 1098 - To achieve inter-working or interconnection between customer 1099 sites using different L2VPN solutions or different implementations 1100 of the same approach 1102 Each approach MUST describe whether any of the above objectives can 1103 be met. If an objective can be met, the approach MUST describe how 1104 such interoperability could be achieved. 1106 Augustyn et al Informational - Expires August 2003 21 1107 6.15 Testing 1108 The L2VPN solution SHOULD provide the ability to test and verify 1109 operational and maintenance activities on a per L2VPN service basis, 1110 and in case of VPLS, on a per VLAN basis if customer VLANs are used 1111 as service delimiters. 1113 The L2VPN solution SHOULD provide mechanisms for connectivity 1114 verification, and for detecting/locating faults. 1116 Examples of testing mechanisms are as follows: 1117 o Checking connectivity between "service-aware" network nodes 1118 o Verifying data plane and control plane integrity 1119 o Verifying service membership 1121 The provided mechanisms MUST satisfy the following: the 1122 connectivity checking for a given customer MUST enable the end-to- 1123 end testing of the data path used by that customer's data packets 1124 and the test packets MUST not propagate beyond the boundary of the 1125 SP network. 1127 6.16 Support on Existing PEs 1128 To the extent possible, the IPLS solution SHOULD facilitate support 1129 of IPLS on existing PE devices that may be already deployed by the 1130 Service Provider and may have been designed primarily for �Layer 3� 1131 services. 1133 7 Service Provider Management Requirements 1134 A service provider desires to have a means to view the topology, 1135 operational state, and other parameters associated with each 1136 customer's L2VPN. Furthermore, the service provider requires a means 1137 to view the underlying logical and physical topology, operational 1138 state, provisioning status, and other parameters associated with the 1139 equipment providing the L2VPN service(s) to its customers. 1140 Therefore, the devices SHOULD provide standards-based interfaces 1141 (e.g., L2VPN MIBs) wherever feasible. 1143 The details of service provider management requirements for a 1144 Network Management System (NMS) in the traditional fault, 1145 configuration, accounting, performance, and security (FCAPS) 1146 management categories can be found in [Y.1311.1]. 1148 8 Engineering Requirements 1149 These requirements are driven by implementation characteristics that 1150 make service and SP requirements achievable. 1152 8.1 Control Plane Requirements 1153 A L2VPN service SHOULD be provisioned with minimum number of steps. 1154 Therefore, the control protocols SHOULD provide methods for 1155 signaling between PEs. The signaling SHOULD inform of membership, 1156 tunneling information, and other relevant parameters. 1158 Augustyn et al Informational - Expires August 2003 22 1159 The infrastructure MAY employ manual configuration methods to 1160 provide this type of information. 1162 The infrastructure SHOULD use policies to scope the membership and 1163 reachability advertisements for a particular L2VPN service. A 1164 mechanism for isolating the distribution of reachability information 1165 to only those sites associated with a L2VPN MUST be provided. 1167 The control plane traffic increases with the growth of L2VPN 1168 membership. Similarly, the control plane traffic increases with the 1169 number of supported L2VPN services. The use of control plane 1170 resources MAY increase as the number of hosts connected to a L2VPN 1171 service grows. 1173 A L2VPN solution SHOULD minimize control plane traffic and the 1174 consumption of control plane resources. The control plane MAY offer 1175 means for enforcing a limit on the number of customer hosts attached 1176 to a L2VPN service. 1178 8.2 Data Plane Requirements 1179 8.2.1 Encapsulation 1180 A L2VPN solution SHOULD utilize the encapsulation techniques defined 1181 by PWE3 ([PWE3-FR]), and SHOULD not impose any new requirements on 1182 these techniques. 1184 8.2.2 Responsiveness to Congestion 1185 A L2VPN solution SHOULD utilize the congestion avoidance techniques 1186 defined by PWE3 ([PWE3-FR]). 1188 8.2.3 Broadcast Domain 1189 A separate Broadcast Domain MUST be maintained for each VPLS. 1191 In addition to VPLS Broadcast Domains, a L2VPN service MAY honor 1192 customer VLAN Broadcast Domains, if customer VLANs are used as 1193 service delimiters. In that case, the L2VPN solution SHOULD maintain 1194 a separate VLAN Broadcast Domain for each customer VLAN. 1196 8.2.4 Virtual Switching Instance 1197 L2VPN Provider Edge devices MUST maintain a separate Virtual 1198 Switching Instance (VSI) per each VPLS. Each VSI MUST have 1199 capabilities to forward traffic based on customer's traffic 1200 parameters such as MAC addresses, VLAN tags (if supported), etc. as 1201 well as local policies. 1203 L2VPN Provider Edge devices MUST have capabilities to classify 1204 incoming customer traffic into the appropriate VSI. 1206 Each VSI MUST have flooding capabilities for its Broadcast Domain to 1207 facilitate proper forwarding of Broadcast, Multicast and Unknown 1208 Unicast customer traffic. 1210 Augustyn et al Informational - Expires August 2003 23 1211 8.2.5 MAC address learning 1212 A VPLS SHOULD derive all topology and forwarding information from 1213 packets originating at customer sites. Typically, MAC address 1214 learning mechanisms are used for this purpose. With IPLS, snooping 1215 of particular packets originating at customer sites and signaling 1216 might also be used. 1218 Dynamic population of the Forwarding Information Base (e.g. via MAC 1219 address learning) MUST take place on a per Virtual Switching 1220 Instance (VSI) basis, i.e. in the context of a VPLS and, if 1221 supported, in the context of VLANs therein. 1223 9 Security Considerations 1224 Security considerations occur at several levels and dimensions 1225 within Layer 2 Provider Provisioned VPNs, as detailed within this 1226 document. 1228 The requirements in this document separate the notion of traditional 1229 security requirements, such as integrity, confidentiality, and 1230 authentication as detailed in section 4.5 from that of isolating (or 1231 separating) the exchange of forwarded packets and exchange of 1232 forwarding information between specific sets of sites. Further 1233 details on security requirements are given from the customer and 1234 service provider perspectives in sections 5.5 and 6.7, respectively. 1235 In an analogous manner, further detail on traffic and routing 1236 isolation requirements are given from the customer and service 1237 provider perspectives in sections 4.4 and 6.6, respectively. 1238 Safeguards to protect network resources such as CPU, memory, and 1239 bandwidth are required in section 6.13. 1241 IPSec can be also be applied after tunneling Layer-2 traffic to 1242 provide additional security. 1244 10 Acknowledgments 1245 The authors would like to acknowledge extensive comments and 1246 contributions provided by Loa Andersson, Joel Halpern, Eric Rosen, 1247 Ali Sajassi, Muneyoshi Suzuki, Ananth Nagarajan, Dinesh Mohan, Yakov 1248 Rekhter, Matt Squire, Norm Finn, Scott Bradner, and Francois Le 1249 Faucheur. The authors, also, wish to extend their appreciation�s to 1250 their respective employers and various other people who volunteered 1251 to review this work and provided feedback. This work was done in 1252 consultation with the entire Layer 2 PPVPN design team. A lot of the 1253 text was adapted from the Layer 3 requirements document produced by 1254 Layer 3 requirements design team. 1256 11 References 1257 11.1 Normative References 1258 [RFC2026] Bradner, S., "The Internet Standards Process -- 1259 Revision 3", BCP 9, RFC 2026, October 1996. 1260 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1261 Requirement Levels", BCP 14, RFC 2119, March 1997 1263 Augustyn et al Informational - Expires August 2003 24 1265 [TERMINOLOGY] Andersson, L, Madsen, T. "PPVPN Terminology", work 1266 in progress 1268 11.2 Non-normative References 1269 [GENERIC-REQTS] Nagarajan, A., et al. "Generic Requirements for 1270 Provider Provisioned VPN", work in progress 1271 [PPVPN-L2-FR] Andersson, L, et al. "PPVPN L2 Framework", work in 1272 progress 1273 [RFC3270] Le Faucheur, F., et al. "Multi-Protocol Label Switching 1274 (MPLS) Support of Differentiated Services", RFC 3270, 1275 May 2002. 1276 [RFC3308] Calhoun, P., et al, "Layer 2 Tunneling Protocol (L2TP) 1277 Differentiated Services Extension", RFC 3308, November 1278 2002. 1279 [RFC2205] Braden, R., et al, "Resource ReSerVation Protocol 1280 (RSVP)", RFC 2205, September 1997. 1281 [L3REQTS] Carugi, M., McDysan, D. et. al., "Service Requirements 1282 for Layer 3 Provider Provisioned Virtual Private 1283 Networks", work in progress 1284 [Y.1311.1] Carugi, M. (editor), "Network Based IP VPN over MPLS 1285 architecture",Y.1311.1 ITU-T Recommendation, May 2001 1286 (http://standards.nortelnetworks.com/ppvpn/relateditu.ht 1287 m) 1288 [RFC2685] Fox B., et al, "Virtual Private Networks Identifier", 1289 RFC 2685, September 1999. 1290 [VPN-IW] H. Kurakami et al, "Provider-Provisioned VPNs 1291 Interworking," work in progress. 1292 [PWE3-FR] Pate, P, et al. "Framework for Pseudo Wire Emulation 1293 Edge-to-Edge (PWE3)", work in progress 1295 12 Editors' Addresses 1297 Waldemar Augustyn 1298 Email: waldemar@nxp.com 1300 Yetik Serbest 1301 SBC Technology Resources 1302 9505 Arboretum Blvd. 1303 Austin, TX 78759 1304 Email: serbest@tri.sbc.com 1306 Full copyright statement 1308 Copyright (C) The Internet Society (1999). All Rights Reserved. 1310 This document and translations of it may be copied and furnished to 1311 others, and derivative works that comment on or otherwise explain it 1312 or assist its implementation may be prepared, copied, published and 1313 distributed, in whole or in part, without restriction of any kind, 1314 provided that the above copyright notice and this paragraph are 1316 Augustyn et al Informational - Expires August 2003 25 1317 included on all such copies and derivative works. However, this 1318 document itself may not be modified in any way, such as by removing 1319 the copyright notice or references to the Internet Society or other 1320 Internet organizations, except as needed for the purpose of 1321 developing Internet standards in which case the procedures for 1322 copyrights defined in the Internet Standards process must be 1323 followed, or as required to translate it into languages other than 1324 English. 1326 The limited permissions granted above are perpetual and will not be 1327 revoked by the Internet Society or its successors or assigns. 1329 This document and the information contained herein is provided on an 1330 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1331 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1332 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1333 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1334 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1336 Augustyn et al Informational - Expires August 2003 26