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