idnits 2.17.1 draft-ietf-l2vpn-requirements-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1300. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1273. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1280. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1286. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 'MUST not' in this paragraph: Since the IPLS solution aims at transporting encapsulated traffic (rather than Layer 2 frames themselves) the IPLS solution MUST not alter the packets encapsulated inside Layer 2 frames which are transported by the IPLS. However, the IPLS solution is NOT REQUIRED to preserve the Layer 2 header transparently from CE to CE. For example, Source MAC address might not be preserved by the IPLS solution. The IPLS solution MAY remove Layer 2 headers for transport over the backbone when those can be reconstructed on egress without compromising transport of encapsulated traffic. == 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 of 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: 9.2 Data Plane Requirements 9.2.1 Encapsulation A L2VPN solution SHOULD utilize the encapsulation techniques defined by PWE3 ([RFC3985]), 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 ---------------------------------------------------------------------------- No issues found here. Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 8 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-07.txt AT&T 6 June 2006 (Editors) 7 Category: Informational 8 Expires: January 2007 10 Service Requirements for Layer 2 Provider Provisioned Virtual Private 11 Networks 13 Status of this memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 Abstract 38 This document provides requirements for Layer 2 Provider Provisioned 39 Virtual Private Networks (L2VPNs). It first provides taxonomy and 40 terminology and states generic and general service requirements. It 41 covers point-to-point VPNs referred to as Virtual Private Wire 42 Service (VPWS), as well as multipoint-to-multipoint VPNs also known 43 as Virtual Private LAN Service (VPLS). Detailed requirements are 44 expressed from a customer as well as a service provider perspective. 46 Table of Contents 47 1 Conventions used in this document.................................4 48 2 Contributing Authors..............................................4 49 3 Introduction......................................................4 50 3.1 Scope of this document.........................................4 51 3.2 Outline........................................................5 52 4 Definitions and Taxonomy..........................................5 53 4.1 Definitions....................................................5 54 4.2 Taxonomy of L2VPN Types........................................5 55 4.3 VPWS...........................................................6 56 4.4 VPLS...........................................................6 57 5 Service Requirements Common to Customers and Service Providers....7 58 5.1 Scope of emulation.............................................7 59 5.2 Traffic Types..................................................8 60 5.3 Topology.......................................................8 61 5.4 Isolated Exchange of Data and Forwarding Information...........8 62 5.5 Security.......................................................8 63 5.5.1 User data security........................................9 64 5.5.2 Access control............................................9 65 5.6 Addressing....................................................10 66 5.7 Quality of Service............................................10 67 5.7.1 QoS Standards............................................10 68 5.7.2 Service Models...........................................10 69 5.8 Service Level Specifications..................................10 70 5.9 Protection and Restoration....................................11 71 5.10 CE-to-PE and PE-to-PE link requirements.......................11 72 5.11 Management....................................................11 73 5.12 Interoperability..............................................11 74 5.13 Inter-working.................................................11 75 6 Customer Requirements............................................12 76 6.1 Service Provider Independence.................................12 77 6.2 Layer 3 Support...............................................12 78 6.3 Quality of Service and Traffic Parameters.....................12 79 6.4 Service Level Specification...................................13 80 6.5 Security......................................................13 81 6.5.1 Isolation................................................13 82 6.5.2 Access control...........................................13 83 6.5.3 Value added security services............................13 84 6.6 Network Access................................................13 85 6.6.1 Physical/Link Layer Technology...........................13 86 6.6.2 Access Connectivity......................................13 87 6.7 Customer traffic..............................................15 88 6.7.1 Unicast, Unknown Unicast, Multicast, and Broadcast 89 forwarding.......................................................15 90 6.7.2 Packet Re-ordering.......................................15 91 6.7.3 Minimum MTU..............................................15 92 6.7.4 End-point VLAN tag translation...........................15 93 6.7.5 Transparency.............................................16 94 6.8 Support for Layer 2 Control Protocols.........................16 95 6.9 CE Provisioning...............................................16 96 7 Service Provider Network Requirements............................16 97 7.1 Scalability...................................................16 98 7.1.1 Service Provider Capacity Sizing Projections.............16 99 7.1.2 Solution-Specific Metrics................................16 100 7.2 Identifiers...................................................17 101 7.3 Discovering L2VPN Related Information.........................17 102 7.4 Quality of Service (QoS)......................................17 103 7.5 Isolation of Traffic and Forwarding Information...............18 104 7.6 Security......................................................18 105 7.7 Inter-AS/SP L2VPNs............................................19 106 7.7.1 Management...............................................19 107 7.7.2 Bandwidth and QoS Brokering..............................19 108 7.8 L2VPN Wholesale...............................................19 109 7.9 Tunneling Requirements........................................20 110 7.10 Support for Access Technologies...............................20 111 7.11 Backbone Networks.............................................21 112 7.12 Network Resource Partitioning and Sharing Between L2VPNs......21 113 7.13 Interoperability..............................................21 114 7.14 Testing.......................................................21 115 7.15 Support on Existing PEs.......................................22 116 8 Service Provider Management Requirements.........................22 117 9 Engineering Requirements.........................................22 118 9.1 Control Plane Requirements....................................22 119 9.2 Data Plane Requirements.......................................23 120 9.2.1 Encapsulation............................................23 121 9.2.2 Responsiveness to Congestion.............................23 122 9.2.3 Broadcast Domain.........................................23 123 9.2.4 Virtual Switching Instance...............................23 124 9.2.5 MAC address learning.....................................23 125 10 Security Considerations.........................................23 126 11 IANA Considerations.............................................24 127 12 Acknowledgments.................................................24 128 13 References......................................................24 129 13.1 Normative References..........................................24 130 13.2 Informative References........................................24 131 14 Editors' Addresses..............................................25 132 15 Intellectual Property Statement.................................26 133 16 Full copyright statement........................................26 134 1 Conventions used in this document 135 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 136 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 137 document are to be interpreted as described in RFC 2119 [RFC2119]. 139 2 Contributing Authors 140 This document was the combined effort of several individuals. The 141 following are the authors that contributed to this document: 143 Waldemar Augustyn 144 Marco Carugi 145 Giles Heron 146 Vach Kompella 147 Marc Lasserre 148 Pascal Menezes 149 Hamid Ould-Brahim 150 Tissa Senevirathne 151 Yetik Serbest 153 3 Introduction 154 This section describes the scope and outline of the document. 156 3.1 Scope of this document 157 This document provides requirements for provider-provisioned Layer 2 158 Virtual Private Networks (L2VPN). It identifies requirements that 159 MAY apply to one or more individual approaches that a Service 160 Provider (SP) may use for the provisioning of a Layer 2 VPN service. 161 The content of this document makes use of the terminology defined in 162 [RFC4026] and common components for deploying L2VPNs described in 163 [L2VPN_FR]. 165 The technical specifications to provide L2VPN services are outside 166 the scope of this document. The framework document [L2VPN_FR] and 167 several documents, which explain technical approaches providing L2VPN 168 services such as [VPLS_LDP], [VPLS_BGP], and [IPLS], are available to 169 cover this aspect. 171 This document describes requirements for two types of L2VPNs: 1. 172 Virtual Private Wire Service (VPWS), and 2. Virtual Private LAN 173 Service (VPLS). The approach followed in this document distinguishes 174 L2VPN types as to how the connectivity is provided (point-point or 175 multipoint-multipoint) as detailed in [L2VPN_FR]. 177 This document is intended as a "checklist" of requirements that will 178 provide a consistent way to evaluate and document how well each 179 individual approach satisfies specific requirements. The 180 applicability statement document for each individual approach should 181 document the results of this evaluation. 183 In the context of provider-provisioned VPNs, there are two entities 184 involved in operation of such services, the Provider and the 185 Customer. The Provider engages in a binding agreement with the 186 Customer as to the behavior of the service in normal situation as 187 well as exceptional situations. Such agreement is known as Service 188 Level Specification (SLS) which is part of the Service Level 189 Agreement (SLA) established between the Provider and the Customer. 191 A proper design of L2VPNs aids formulation of SLSs in that it 192 provides means for proper separation between CE and PE, allows proper 193 execution of the SLS offer, and supports flexible and rich set of 194 capabilities. 196 This document provides requirements from both the Provider's and the 197 Customer's point of view. It begins with common customer's and 198 service provider's point of view, followed by a customer's 199 perspective, and concludes with specific needs of a SP. These 200 requirements provide high-level L2VPN features expected by a SP in 201 provisioning L2VPNs, which include SP requirements for security, 202 privacy, manageability, interoperability and scalability. 204 3.2 Outline 205 The outline of the rest of this document is as follows. Section 3 206 provides definitions and taxonomy. Section 4 provides common 207 requirements that apply to both customer and SP respectively. 208 Section 5 states requirements from a customer perspective. Section 6 209 states network requirements from a SP perspective. Section 7 states 210 SP management requirements. Section 8 describes the engineering 211 requirements, particularly control and data plane requirements. 212 Section 9 provides security considerations. Section 10 lists 213 acknowledgements. Section 11 provides a list of references cited 214 herein. Section 12 lists the editors' addresses. 216 4 Definitions and Taxonomy 217 4.1 Definitions 218 The terminology used in this document is defined in [RFC4026]. The 219 L2VPN framework document [L2VPN_FR] further describes these concepts 220 in the context of a reference model that defines layered service 221 relationships between devices and one or more levels of tunnels. 223 4.2 Taxonomy of L2VPN Types 224 The requirements distinguish two major L2VPN models, a Virtual 225 Private Wire Service (VPWS), and a Virtual Private LAN Service 226 (VPLS). 228 The following diagram shows a L2VPN reference model. 230 +-----+ +-----+ 231 + CE1 +--+ +---| CE2 | 232 +-----+ | ........................ | +-----+ 233 L2VPN A | +----+ +----+ | L2VPN A 234 +--| PE |--- Service ---| PE |--+ 235 +----+ Provider +----+ 236 / . Backbone . \ - /\-_ 238 +-----+ / . | . \ / \ / \ +-----+ 239 + CE4 +--+ . | . +--\ Access \----| CE5 | 240 +-----+ . +----+ . | Network | +-----+ 241 L2VPN B .........| PE |......... \ / L2VPN B 242 +----+ ^ ------- 243 | | 244 | | 245 +-----+ | 246 | CE3 | +-- Logical switching instance 247 +-----+ 248 L2VPN A 250 Figure 1 L2VPN Reference Model 252 4.3 VPWS 253 The PE devices provide a logical interconnect such that a pair of CE 254 devices appear to be connected by a single logical Layer 2 circuit. 255 PE devices act as Layer 2 circuit switches. Layer 2 circuits are 256 then mapped onto tunnels in the SP network. These tunnels can either 257 be specific to a particular VPWS, or shared among several services. 258 VPWS applies for all services including Ethernet, ATM, Frame Relay 259 etc. In Figure 1, L2VPN B represents a VPWS case. 261 Each PE device is responsible for allocating customer Layer 2 frames 262 to the appropriate VPWS and for proper forwarding to the intended 263 destinations. 265 4.4 VPLS 266 In case of VPLS, the PE devices provide a logical interconnect such 267 that CE devices belonging to a specific VPLS appear to be connected 268 by a single LAN. End-to-end VPLS consists of a bridge module and a 269 LAN emulation module ([L2VPN_FR]). A VPLS can contain a single VLAN 270 or multiple VLANs ([IEEE_802.1Q]). A variation of this service is 271 IPLS ([L2VPN_FR]), which is limited to supporting only customer IP 272 traffic. 274 In a VPLS, a customer site receives Layer 2 service from the SP. The 275 PE is attached via an access connection to one or more CEs. The PE 276 performs forwarding of user data packets based on information in the 277 Layer 2 header, such as a MAC destination address. In Figure 1, 278 L2VPN A represents a VPLS case. 280 The details of VPLS reference model, which we summarize here, can be 281 found in [L2VPN_FR]. In VPLS, the PE can be viewed as containing a 282 Virtual Switching Instance (VSI) for each L2VPN that it serves. A CE 283 device attaches, possibly through an access network, to a bridge 284 module of a PE. Within the PE, the bridge module attaches, through 285 an Emulated LAN Interface to an Emulated LAN. For each VPLS, there 286 is an Emulated LAN instance. The Emulated LAN consists of VPLS 287 Forwarder module (one per PE per VPLS service instance) connected by 288 pseudo wires (PW), where the PWs may be traveling through Packet 289 Switched Network (PSN) tunnels over a routed backbone. VSI is a 290 logical entity that contains a VPLS forwarder module and part of the 291 bridge module relevant to the VPLS service instance [L2VPN_FR]. 292 Hence, the VSI terminates PWs for interconnection with other VSIs and 293 also terminates Attachment Circuits (ACs) (see [RFC3985] for 294 definition) for accommodating CEs. A VSI includes the forwarding 295 information base for a L2VPN [L2VPN_FR] which is the set of 296 information regarding how to forward Layer 2 frames received over the 297 AC from the CE to VSIs in other PEs supporting the same L2VPN service 298 (and/or to other ACs), and contains information regarding how to 299 forward Layer 2 frames received from PWs to ACs. Forwarding 300 information bases can be populated dynamically (such as by source MAC 301 address learning) or statically (e.g., by configuration). Each PE 302 device is responsible for proper forwarding of the customer traffic 303 to the appropriate destination(s) based on the forwarding information 304 base of the corresponding VSI. 306 5 Service Requirements Common to Customers and Service Providers 307 This section contains requirements that apply to both the customer 308 and the provider, or are of an otherwise general nature. 310 5.1 Scope of emulation 311 L2VPN protocols SHOULD NOT interfere with existing Layer 2 protocols 312 and standards of the Layer 2 network the customer is managing. If 313 they impact customer Layer 2 protocols that are sent over the VPLS, 314 then these impacts MUST be documented. 316 Some possibly salient differences between VPLS and a real LAN are: 317 - The reliability may likely be less, i.e., the probability that a 318 message broadcast over the VPLS is not seen by one of the bridge 319 modules in PEs is higher than in a true Ethernet. 320 - VPLS frames can get duplicated if the PW sequencing option isn't 321 turned on. The data frames on the PWs are sent in IP datagrams, 322 and under certain failure scenarios, IP networks can duplicate 323 packets. If the PW data transmission protocol does not ensure 324 sequence of data packets, frames can be duplicated or received out 325 of sequence. If the customer's Bridge Protocol Data Unit (BPDU) 326 frames are sent as data packets, then BPDU frames can be duplicated 327 or mis-sequenced, although this may not create any problems for 328 RSTP. 329 - Delayed delivery of packets (e.g., more than half a second) 330 rather than dropping them could have adverse effect on the 331 performance of the service. 332 - 802.3x Pause frames will not be transported over a VPLS, as the 333 bridge module ([L2VPN_FR]) in the PE terminates them. 334 - Since the IPLS solution aims at transporting encapsulated traffic 335 (rather than Layer 2 frames themselves), the IPLS solution is NOT 336 REQUIRED to preserve the Layer 2 Header transparently from CE to 337 CE. For example, Source MAC address will probably not be preserved 338 by the IPLS solution. 340 5.2 Traffic Types 341 A VPLS MUST support unicast, multicast, and broadcast traffic. 342 Support for efficient replication of broadcast and multicast traffic 343 is highly desirable. 345 5.3 Topology 346 A SP network may be realized using one or more network tunnel 347 topologies to interconnect PEs, ranging from simple point-to-point to 348 distributed hierarchical arrangements. The typical topologies 349 include: 351 - Point-to-point 352 - Point-to-multipoint, a.k.a. hub and spoke 353 - Any-to-any, a.k.a. full mesh 354 - Mixed, a.k.a. partial mesh 355 - Hierarchical 357 Regardless of the SP topology employed, the service to the customers 358 MUST retain the connectivity type implied by the type of L2VPN. For 359 example, a VPLS MUST allow multipoint-to-multipoint connectivity even 360 if implemented with point-to-point circuits. This requirement does 361 not imply that all traffic characteristics (such as bandwidth, QoS, 362 delay, etc.) be necessarily the same between any two end points of a 363 L2VPN. It is important to note that SLS requirements of a service 364 have a bearing on the type of topology that can be used. 366 To the extent possible, a L2VPN service SHOULD be capable of crossing 367 multiple administrative boundaries. 369 To the extent possible, the L2VPN services SHOULD be independent of 370 access network technology. 372 5.4 Isolated Exchange of Data and Forwarding Information 373 L2VPN solutions SHALL define means that prevent CEs in a L2VPN from 374 interaction with unauthorized entities. 376 L2VPN solutions SHALL avoid introducing undesired forwarding 377 information that could corrupt the L2VPN forwarding information base. 379 A means to constrain, or isolate, the distribution of addressed data 380 to only those VPLS sites determined either by MAC learning and/or 381 configuration MUST be provided. 383 The internal structure of a L2VPN SHOULD not be advertised nor 384 discoverable from outside that L2VPN. 386 5.5 Security 387 A range of security features MUST be supported by the suite of L2VPN 388 solutions. Each L2VPN solution MUST state which security features it 389 supports and how such features can be configured on a per customer 390 basis. 392 A number of security concerns arise in the setup and operation of a 393 L2VPN, ranging from mis-configurations to attacks that can be 394 launched on a L2VPN and can strain network resources such as memory 395 space, forwarding information base table, bandwidth and CPU 396 processing. 398 This section lists some potential security hazards that can result 399 due to mis-configurations and/or malicious attacks. There MUST be 400 methods available to protect against the following situations. 402 - Protocol attacks 403 o Excessive protocol adjacency setup/teardown 404 o Excessive protocol signaling/withdrawal 405 - Resource Utilization 406 o Forwarding plane replication (VPLS) 407 o Looping (VPLS primarily) 408 o MAC learning table size limit (VPLS) 409 - Unauthorized access 410 o Unauthorized member of VPN 411 o Incorrect customer interface 412 o Incorrect service delimiting VLAN tag 413 o Unauthorized access to PE 414 - Tampering with signaling 415 o Incorrect FEC signaling 416 o Incorrect PW label assignment 417 o Incorrect signaled VPN parameters (e.g., QoS, MTU, etc.) 418 - Tampering with data forwarding 419 o Incorrect MAC learning entry 420 o Incorrect PW label 421 o Incorrect AC identifier 422 o Incorrect customer facing encapsulation 423 o Incorrect PW encapsulation 424 o Hijacking PWs using the wrong tunnel 425 o Incorrect tunnel encapsulation 427 5.5.1 User data security 428 An L2VPN solution MUST provide traffic separation between different 429 L2VPNs. 431 In case of VPLS, VLAN Ids MAY be used as service delimiters. When 432 used in this manner, they MUST be honored and traffic separation MUST 433 be provided. 435 5.5.2 Access control 436 A L2VPN solution MAY also have the ability to activate the 437 appropriate filtering capabilities upon request of a customer. 439 5.6 Addressing 440 A L2VPN solution MUST support overlapping addresses of different 441 L2VPNs. For instance, customers MUST NOT be prevented from using the 442 same MAC addresses with different L2VPNs. If a service provider uses 443 VLANs as service delimiters, the L2VPN solution MUST ensure that VLAN 444 Ids cannot overlap. If VLANs are not used as service delimiters, 445 L2VPN solutions MAY allow VLAN Ids to overlap. 447 5.7 Quality of Service 448 To the extent possible, L2VPN QoS SHOULD be independent of the access 449 network technology. 451 5.7.1 QoS Standards 452 As provided in [RFC3809] a L2VPN SHALL be able to support QoS in one 453 or more of the following already standardized modes: 454 - Best Effort (support mandatory for all provider-provisioned 455 VPN types) 456 - Aggregate CE Interface Level QoS (i.e., 'hose' level) 457 - Site-to-site, or 'pipe' level QoS 459 Note that all cases involving QoS MAY require that the CE and/or PE 460 perform shaping and/or policing. 462 Mappings or translations of Layer 2 QoS parameters into PSN QoS 463 (e.g., DSCPs or MPLS EXP field) as well as QoS mapping based on VC 464 (e.g., FR/ATM or VLAN) MAY be performed in order to provide QoS 465 transparency. The actual mechanisms for these mappings or 466 translations are outside the scope of this document. In addition, 467 the Diffserv support of underlying tunneling technologies (e.g., 468 [RFC3270] or [RFC3308]) and the Intserv model ([RFC2205]) MAY be 469 used. As such, the L2VPN SLS requirements SHOULD be supported by 470 appropriate core mechanisms. 472 5.7.2 Service Models 473 A service provider may desire to offer QoS service to a customer for 474 at least the following generic service types: managed access VPN 475 service or an edge-to-edge QoS service. The details of the service 476 models can be found in [RFC3809] and in [RFC4031]. 478 In L2VPN service, both DSCP ([RFC2474]) and 802.1p ([IEEE_802.1D]) 479 fields may be used for this purpose. 481 5.8 Service Level Specifications 482 For a L2VPN service, the capabilities for Service Level Specification 483 (SLS) monitoring and reporting stated in [RFC3809] SHOULD be 484 provided. 486 5.9 Protection and Restoration 487 The L2VPN service infrastructure SHOULD provide redundant paths to 488 assure high availability. The reaction to failures SHOULD result in 489 an attempt to restore the service using alternative paths. 491 The intention is to keep the restoration time small. The restoration 492 time MUST be less than the time it takes the CE devices, or customer 493 Layer 2 control protocols as well as Layer 3 routing protocols, to 494 detect a failure in the L2VPN. 496 5.10 CE-to-PE and PE-to-PE link requirements 497 The CE-to-PE links MAY be 498 - direct physical links (e.g., 100BaseTX, and T1/E1 TDM), 499 - logical links (e.g., ATM PVC, and RFC2427-encapsulated link), 500 - transport networks carrying Ethernet, 501 - a Layer 2 tunnel that go through a Layer 3 network (e.g., L2TP 502 sessions). 504 Layer 2 frames MAY be tunneled through a Layer 3 backbone from PE to 505 PE, using one of a variety of tunneling technologies (e.g., IP-in-IP, 506 GRE, MPLS, L2TP, etc.). 508 5.11 Management 509 Standard interfaces to manage L2VPN services MUST be provided 510 (e.g., standard SNMP MIB Modules). These interfaces SHOULD provide 511 access to configuration, verification and runtime monitoring 512 protocols. 514 Service management MAY include the TMN 'FCAPS' functionalities, as 515 follows: Fault, Configuration, Accounting, Performance, and Security, 516 as detailed in [ITU_Y.1311.1]. 518 5.12 Interoperability 519 Multi-vendor interoperability, which corresponds to similar network 520 and service levels among different implementations, at the network 521 element SHOULD be guaranteed. This will likely rely on the 522 completeness of the corresponding standard. 524 The technical solution MUST be multi-vendor interoperable not only 525 within the SP network infrastructure, but also with the customer's 526 network equipment and services making usage of the L2VPN service. 528 A L2VPN solution SHOULD NOT preclude different access technologies. 529 For instance, customer access connections to a L2VPN service MAY be 530 different at different CE devices (e.g., Frame Relay, ATM, 802.1D, 531 MPLS). 533 5.13 Inter-working 534 Inter-working scenarios among different solutions, providing L2VPN 535 services, are highly desirable. It is possible to have cases that 536 require inter-working or interconnection between customer sites, 537 which span network domains with different L2VPN solutions or 538 different implementations of the same approach. Inter-working SHOULD 539 be supported in a scalable manner. 541 Inter-working scenarios MUST consider at least traffic isolation, 542 security, QoS, access, and management aspects. This requirement is 543 essential in the case of network migration, to ensure service 544 continuity among sites belonging to different portions of the 545 network. 547 6 Customer Requirements 548 This section captures requirements from a customer perspective. 550 6.1 Service Provider Independence 551 Customers MAY require L2VPN service that spans multiple 552 administrative domains or SP networks. Therefore, a L2VPN service 553 MUST be able to span multiple AS and SP networks, but still to act 554 and to appear as a single, homogenous L2VPN from a customer point of 555 view. 557 A customer might also start with a L2VPN provided in a single AS with 558 a certain SLS but then ask for an expansion of the service spanning 559 multiple ASs and/or multiple-SPs. In this case, as well as for all 560 kinds of multi-AS and multiple-SP L2VPNs, L2VPN service SHOULD be 561 able to deliver the same SLS to all sites in a VPN regardless of the 562 AS/SP to which it homes. 564 6.2 Layer 3 Support 565 With the exception of IPLS, a L2VPN service SHOULD be agnostic to 566 customer's Layer 3 traffic (e.g., IP, IPX, Appletalk) encapsulated 567 within Layer 2 frames. 569 IPLS MUST allow transport of customer's IPv4 and IPv6 traffic 570 encapsulated within Layer 2 frames. IPLS SHOULD also allow CEs to 571 run ISIS and MPLS protocols transparently among them when those are 572 used in conjunction with IP. 574 6.3 Quality of Service and Traffic Parameters 575 QoS is expected to be an important aspect of a L2VPN service for some 576 customers. 578 A customer requires that the L2VPN service provide the QoS applicable 579 to his or her application, which can range from PWs (e.g., SONET 580 emulation) to voice and interactive video, and multimedia 581 applications. Hence, best-effort as well as delay and loss sensitive 582 traffic MUST be supported over a L2VPN service. 583 A customer application SHOULD experience consistent QoS independent 584 of the access network technology used at different sites connected to 585 the same L2VPN. 587 6.4 Service Level Specification 588 Most customers simply want their applications to perform well. A SLS 589 is a vehicle for a customer to measure the quality of the service 590 that SP(s) provide. Therefore, when purchasing a service, a customer 591 requires access to the measures from the SP(s) that support the SLS. 593 Standard interfaces to monitor usage of L2VPN services SHOULD be 594 provided (e.g., standard SNMP MIB Modules). 596 6.5 Security 597 6.5.1 Isolation 598 A L2VPN solution MUST provide traffic as well as forwarding 599 information base isolation for customers similar to that obtained in 600 private lines, FR, or ATM services. 602 A L2VPN service MAY use customer VLAN Ids as service delimiters. In 603 that case, they MUST be honored and traffic separation MUST be 604 provided. 606 6.5.2 Access control 607 A L2VPN solution MAY have the mechanisms to activate the appropriate 608 filtering capabilities upon request of a customer. For instance, MAC 609 and/or VLAN filtering MAY be considered between CE and PE for a VPLS. 611 6.5.3 Value added security services 612 A L2VPN solution MAY provide value added security services such as 613 encryption and/or authentication of customer packets, certificate 614 management, and similar. 616 L2VPN services MUST NOT interfere with the security mechanisms 617 employed at Layer 3 and higher layers by customers. Layer 2 security 618 mechanisms, such as 802.10b ([IEEE_802.10]) and 802.1AE 619 ([IEEE_802.1AE]), MAY inhibit L2VPN services, when the service 620 delimiting VLAN Ids are encrypted. 622 6.6 Network Access 623 Every packet exchanged between the customer and the SP over the 624 access connection MUST appear as it would on a private network 625 providing an equivalent service to that offered by the L2VPN. 627 6.6.1 Physical/Link Layer Technology 628 L2VPN solutions SHOULD support a broad range of physical and link 629 layer access technologies, such as PSTN, ISDN, xDSL, cable modem, 630 leased line, Ethernet, Ethernet VLAN, ATM, Frame Relay, Wireless 631 local loop, mobile radio access, etc. The capacity and QoS 632 achievable MAY be dependent on the specific access technology in use. 634 6.6.2 Access Connectivity 635 Various types of physical connectivity scenarios MUST be supported, 636 such as multi-homed sites, backdoor links between customer sites, 637 devices homed to two or more SP networks. In case of VPLS, IEEE 638 802.3ad-2000 link aggregation SHOULD be supported. L2VPN solutions 639 SHOULD support at least the types of physical or link-layer 640 connectivity arrangements shown in Figure 2-Figure 4 (in addition to 641 the case shown in Figure 1). As in Figure 2, a CE can be dual-homed 642 to a SP or to two different SPs via diverse access networks. 644 +---------------- +--------------- 645 | | 646 +------+ +------+ 647 +---------| PE | +---------| PE | 648 | |device| | |device| SP network 649 | +------+ | +------+ 650 +------+ | +------+ | 651 | CE | | | CE | +--------------- 652 |device| | SP network |device| +--------------- 653 +------+ | +------+ | 654 | +------+ | +------+ 655 | | PE | | | PE | 656 +---------|device| +---------|device| SP network 657 +------+ +------+ 658 | | 659 +---------------- +--------------- 660 (a) (b) 662 Figure 2 Dual-Homed Access of CE Devices 664 Resiliency of the L2VPN service can be further enhanced as shown in 665 Figure 3, where CE's, connected via a "back door" connection, connect 666 to the same SP or to different SPs. 668 +---------------- +--------------- 669 | | 670 +------+ +------+ +------+ +------+ 671 | CE |-----| PE | | CE |-----| PE | 672 |device| |device| |device| |device| SP network 673 +------+ +------+ +------+ +------+ 674 | | | | 675 | Backdoor | | Backdoor +--------------- 676 | link | SP network | link +--------------- 677 | | | | 678 +------+ +------+ +------+ +------+ 679 | CE | | PE | | CE | | PE | 680 |device|-----|device| |device|-----|device| SP network 681 +------+ +------+ +------+ +------+ 682 | | 683 +---------------- +--------------- 684 (a) (b) 686 Figure 3 Backdoor Links Between CE Devices 688 Arbitrary combinations of the above methods, with a few examples shown 689 in Figure 4 SHOULD be supported by any L2VPN solution. 691 +---------------- +--------------- 692 | | 693 +------+ +------+ +------+ +------+ 694 | CE |-----| PE | | CE |-----| PE | 695 |device| |device| |device| |device| SP network 696 +------+\ +------+ +------+\ +------+ 697 | \ | | \ | 698 |Back \ | |Back \ +--------------- 699 |door \ | SP network |door \ +--------------- 700 |link \ | |link \ | 701 +------+ +------+ +------+ +------+ 702 | CE | | PE | | CE | | PE | 703 |device|-----|device| |device|-----|device| SP network 704 +------+ +------+ +------+ +------+ 705 | | 706 +---------------- +--------------- 707 (a) (b) 709 Figure 4 Combination of Dual-Homing and Backdoor Links for CE Devices 711 6.7 Customer traffic 712 6.7.1 Unicast, Unknown Unicast, Multicast, and Broadcast forwarding 713 A VPLS MUST deliver every packet at least to its intended 714 destination(s) within the scope of the VPLS, subject to the ingress 715 policing and security policies. 717 6.7.2 Packet Re-ordering 718 During normal operation, the queuing and forwarding policies SHOULD 719 preserve packet order for packets with the same QoS parameters. 721 6.7.3 Minimum MTU 722 A VPLS MUST support the theoretical MTU of the offered service. 724 The committed minimum MTU size MUST be the same for a given VPLS 725 instance. Different L2VPN services MAY have different committed MTU 726 sizes. If the customer VLANs are used as service delimiters, all 727 VLANs within a given VPLS MUST inherit the same MTU size. 729 A VPLS MAY use IP fragmentation if it presents reassembled packets at 730 VPLS customer edge devices 732 6.7.4 End-point VLAN tag translation 733 The L2VPN service MAY support translation of customers' AC 734 identifiers (e.g., VLAN tags, if the customer VLANs are used as 735 service delimiters). Such service simplifies connectivity of sites 736 that want to keep their AC assignments or sites that belong to 737 different administrative domains. In the latter case, the 738 connectivity is sometimes referred to as Layer 2 extranet. On the 739 other hand, it should be noted that VLAN tag translation affects the 740 support for multiple spanning trees (i.e., 802.1s [IEEE_802.1s]) and 741 can break the proper operation. 743 6.7.5 Transparency 744 The L2VPN service is intended to be transparent to Layer 2 customer 745 networks. A L2VPN solution SHOULD NOT require any special packet 746 processing by the end users before sending packets to the provider's 747 network. 749 If VLAN Ids are assigned by the SP, then VLANs are not transparent. 750 Transparency does not apply in this case, as it is the same as FR/ATM 751 service model. 753 Since the IPLS solution aims at transporting encapsulated traffic 754 (rather than Layer 2 frames themselves) the IPLS solution MUST not 755 alter the packets encapsulated inside Layer 2 frames which are 756 transported by the IPLS. However, the IPLS solution is NOT REQUIRED 757 to preserve the Layer 2 header transparently from CE to CE. For 758 example, Source MAC address might not be preserved by the IPLS 759 solution. The IPLS solution MAY remove Layer 2 headers for transport 760 over the backbone when those can be reconstructed on egress without 761 compromising transport of encapsulated traffic. 763 6.8 Support for Layer 2 Control Protocols 764 The L2VPN solution SHOULD allow transparent operation of Layer 2 765 control protocols employed by customers. 767 In case of VPLS, the L2VPN service MUST ensure that loops be 768 prevented. This can be accomplished with a loop-free topology or 769 appropriate forwarding rules. Control protocols such as Spanning 770 Tree (STP) or similar could be employed. The L2VPN solution MAY use 771 indications from customer Layer 2 control protocols, e.g., STP BPDU 772 snooping, to improve the operation of a VPLS. 774 6.9 CE Provisioning 775 The L2VPN solution MUST require only minimal or no configuration on 776 the CE devices, depending on the type of CE device that connects into 777 the infrastructure. 779 7 Service Provider Network Requirements 780 This section describes requirements from a SP perspective. 782 7.1 Scalability 783 This section contains projections regarding L2VPN sizing and 784 scalability requirements and metrics specific to particular 785 solutions. 787 7.1.1 Service Provider Capacity Sizing Projections 788 [RFC3809] lists projections regarding L2VPN sizing and scalability 789 requirements and metrics. The examples are provided in [RFC3809]. 791 7.1.2 Solution-Specific Metrics 792 Each L2VPN solution SHALL document its scalability characteristics in 793 quantitative terms. 795 7.2 Identifiers 796 A SP domain MUST be uniquely identified at least within the set of 797 all interconnected SP networks when supporting a L2VPN that spans 798 multiple SPs. Ideally, this identifier SHOULD be globally unique 799 (e.g., an AS number). 801 An identifier for each L2VPN SHOULD be unique, at least within each 802 SP's network, as it MAY be used in auto-discovery, management (e.g., 803 alarm and service correlation, troubleshooting, performance 804 statistics collection), and signaling. Ideally, the L2VPN identifier 805 SHOULD be globally unique to support the case, where a L2VPN spans 806 multiple SPs (e.g., [RFC2685]). Globally unique identifiers 807 facilitate the support of inter-AS/SP L2VPNs. 809 7.3 Discovering L2VPN Related Information 810 Configuration of PE devices (i.e., U-PE and N-PE [L2VPN_FR]) is a 811 significant task for a SP. Solutions SHOULD provide methods that 812 dynamically allow L2VPN information to be discovered by the PEs to 813 minimize the configuration steps. 815 Each device in a L2VPN SHOULD be able to determine which other 816 devices belong to the same L2VPN. Such a membership discovery scheme 817 MUST prevent unauthorized access and allows authentication of the 818 source. 820 Distribution of L2VPN information SHOULD be limited to those devices 821 involved in that L2VPN. A L2VPN solution SHOULD employ discovery 822 mechanisms to minimize the amount of operational information 823 maintained by the SPs. For example, if a SP adds or removes a 824 customer port on a given PE, the remaining PEs SHOULD determine the 825 necessary actions to take without the SP having to explicitly 826 reconfigure those PEs. 828 A L2VPN solution SHOULD support the means for attached CEs to 829 authenticate each other and verify that the SP L2VPN is correctly 830 connected. 832 The mechanism SHOULD respond to L2VPN membership changes in a timely 833 manner. A "timely manner" is no longer than the provisioning 834 timeframe, typically on the order of minutes, and MAY be as short as 835 the timeframe required for "rerouting," typically on the order of 836 seconds. 838 Dynamically creating, changing, and managing multiple L2VPN 839 assignments to sites and/or customers is another aspect of membership 840 that MUST be addressed in a L2VPN solution. 842 7.4 Quality of Service (QoS) 843 A significant aspect of a provider-provisioned VPN is support for 844 QoS. A SP has control over the provisioning of resources and 845 configuration of parameters in at least the PE and P devices, and in 846 some cases, the CE devices as well. Therefore, the SP is to provide 847 either managed QoS access service, or edge-to-edge QoS service, as 848 defined in [RFC4031]. 850 7.5 Isolation of Traffic and Forwarding Information 851 From a high level SP perspective, a L2VPN MUST isolate the exchange 852 of traffic and forwarding information to only those sites that are 853 authenticated and authorized members of a L2VPN. 855 A L2VPN solution SHOULD provide a means for meeting provider- 856 provisioned VPN QoS SLS requirements that isolates L2VPN traffic from 857 the affects of traffic offered by non-VPN customers. Also, L2VPN 858 solutions SHOULD provide a means so that traffic congestion produced 859 by sites as part of one L2VPN does not affect another L2VPN. 861 7.6 Security 862 The security requirements are stated in Section 5.5. The security 863 requirements provided in [RFC3809] SHOULD be met. The security 864 requirements, except Layer 3 and higher layer dependent ones, 865 specified in [RFC4031] SHOULD be met. 867 In addition, a SP network MUST be protected against malformed or 868 maliciously constructed customer traffic. This includes but is not 869 limited to duplicate or invalid Layer 2 addresses, customer side 870 loops, short/long packets, spoofed management packets, spoofed VLAN 871 tags, high volume traffic. 873 The SP network devices MUST NOT be accessible from any L2VPN, unless 874 specifically authorized. The devices in the SP network SHOULD 875 provide some means of reporting intrusion attempts to the SP, if the 876 intrusion is detected. 878 When a L2VPN solution operates over a part of the Internet, it should 879 support a configurable option to support one or more of the following 880 standard IPsec methods for securing a customer's VPN traffic: 882 - Confidentiality, so that only authorized devices can decrypt it 883 - Integrity, to ensure that the data has not been altered 884 - Authentication, to ensure that the sender is indeed who he or 885 she claims to be 886 - Replay attack prevention. 888 The above functions SHOULD be applicable to "data traffic" of the 889 customer, which includes the traffic exchanged between sites. It 890 SHOULD also be possible to apply these functions to "control 891 traffic", such as routing or signaling protocol exchanges, that are 892 not necessarily perceived by the customer but are nevertheless 893 essential to maintain his or her VPN. 895 Furthermore, such security methods MUST be configurable between 896 different end-points, such as PE-PE and PE-MTU, only in the case 897 where L2VPN data traffic is carried over IP [RFC4023]. Methods to 898 secure data flows at the native service layer (Layer-2), from CE-CE, 899 CE-MTU and CE-PE, are outside the scope of this document. It is also 900 desirable to configure security on a per-VPN basis [VPNSEC]. 902 A VPN solution MAY support one or more encryption schemes, including 903 AES, and 3DES. Encryption, decryption, and key management SHOULD be 904 included in profiles as part of the security management system. 906 7.7 Inter-AS/SP L2VPNs 907 All applicable SP requirements, such as traffic and forwarding 908 information isolation, SLS's, management, security, provisioning, 909 etc. MUST be preserved across adjacent AS's. The solution MUST 910 describe the inter-SP network interface, encapsulation method(s), 911 routing protocol(s), and all applicable parameters. 913 A L2VPN solution MUST provide the specifics of offering L2VPN 914 services spanning multiple ASs and/or SPs. 916 A L2VPN solution MUST support proper dissemination of operational 917 parameters to all elements of a L2VPN service in the presence of 918 multiple ASs and/or SPs. A L2VPN solution MUST employ mechanisms for 919 sharing operational parameters between different ASs 921 A L2VPN solution SHOULD support policies for proper selection of 922 operational parameters coming from different ASs. Similarly, a L2VPN 923 solution SHOULD support policies for selecting information to be 924 disseminated to different ASs. 926 7.7.1 Management 927 The general requirements for managing a single AS apply to a 928 concatenation of AS's. A minimum subset of such capabilities is the 929 following: 930 - Diagnostic tools 931 - Secured access to one AS management system by another 932 - Configuration request and status query tools 933 - Fault notification and trouble tracking tools 935 7.7.2 Bandwidth and QoS Brokering 936 When a L2VPN spans multiple AS's, there is a need for a brokering 937 mechanism that requests certain SLS parameters, such as bandwidth and 938 QoS, from the other domains and/or networks involved in transferring 939 traffic to various sites. The essential requirement is that a 940 solution MUST be able to determine whether a set of AS's can 941 establish and guarantee uniform QoS in support of a provider- 942 provisioned VPN. 944 7.8 L2VPN Wholesale 945 The architecture MUST support the possibility of one SP offering 946 L2VPN service to another SP. One example is when one SP sells L2VPN 947 service at wholesale to another SP, who then resells that L2VPN 948 service to his or her customers. 950 7.9 Tunneling Requirements 951 Connectivity between CE sites or PE devices in the backbone SHOULD be 952 able to use a range of tunneling technologies, such as L2TP, GRE, IP- 953 in-IP, MPLS, etc. 955 Every PE MUST support a tunnel setup protocol, if tunneling is used. 956 A PE MAY support static configuration. If employed, a tunnel 957 establishment protocol SHOULD be capable of conveying information, 958 such as the following: 959 - Relevant identifiers 960 - QoS/SLS parameters 961 - Restoration parameters 962 - Multiplexing identifiers 963 - Security parameters 965 There MUST be a means to monitor the following aspects of tunnels: 966 - Statistics, such as amount of time spent in the up and down 967 state 968 - Count of transitions between the up and down state 969 - Events, such as transitions between the up and down states 971 The tunneling technology used by the VPN SP and its associated 972 mechanisms for tunnel establishment, multiplexing, and maintenance 973 MUST meet the requirements on scaling, isolation, security, QoS, 974 manageability, etc. 976 Regardless of the tunneling choice, the existence of the tunnels and 977 their operations MUST be transparent to the customers. 979 7.10 Support for Access Technologies 980 The connectivity between PE and CE devices is referred to as an AC. 981 ACs MAY span networks of other providers or public networks. 983 There are several choices for implementing ACs. Some popular choices 984 include Ethernet, ATM (DSL), Frame Relay, MPLS-based virtual circuits 985 etc. 987 In case of VPLS, the AC MUST use Ethernet frames as the Service 988 Protocol Data Unit (SPDU). 990 A CE access connection over an AC MUST be bi-directional. 992 PE devices MAY support multiple ACs on a single physical interface. 993 In such cases, PE devices MUST NOT rely on customer controlled 994 parameters for distinguishing between different access connections. 995 For example, if VLAN tags were used for that purpose, the provider 996 would be controlling the assignment of the VLAN tag values and would 997 strictly enforce compliance by the CEs. 999 An AC, whether direct or virtual, MUST maintain all committed 1000 characteristics of the customer traffic, such as QoS, priorities etc. 1001 The characteristics of an AC are only applicable to that connection. 1003 7.11 Backbone Networks 1004 Ideally, the backbone, interconnecting SP's PE and P devices, SHOULD 1005 be independent of physical and link layer technology. Nevertheless, 1006 the characteristics of backbone technology MUST be taken into account 1007 when specifying the QoS aspects of SLSs for VPN service offerings. 1009 7.12 Network Resource Partitioning and Sharing Between L2VPNs 1010 In case network resources such as memory space, forwarding 1011 information base table, bandwidth and CPU processing are shared 1012 between L2VPNs, the solution SHOULD guarantee availability of 1013 resources necessary to prevent any specific L2VPN service instance 1014 from taking up available network resources and causing others to 1015 fail. The solution SHOULD be able to limit the resources consumed by 1016 a L2VPN service instance. The solution SHOULD guarantee availability 1017 of resources necessary to fulfill the obligation of committed SLSs. 1019 7.13 Interoperability 1020 Service providers are interested in interoperability in at least the 1021 following scenarios: 1022 - To facilitate use of PE and managed CE devices within a single 1023 SP network 1024 - To implement L2VPN services across two or more interconnected 1025 SP networks 1026 - To achieve inter-working or interconnection between customer 1027 sites using different L2VPN solutions or different 1028 implementations of the same approach 1030 Each approach MUST describe whether any of the above objectives can 1031 be met. If an objective can be met, the approach MUST describe how 1032 such interoperability could be achieved. 1034 7.14 Testing 1035 The L2VPN solution SHOULD provide the ability to test and verify 1036 operational and maintenance activities on a per L2VPN service basis, 1037 and in case of VPLS, on a per VLAN basis if customer VLANs are used 1038 as service delimiters. 1040 The L2VPN solution SHOULD provide mechanisms for connectivity 1041 verification, and for detecting and locating faults. 1043 Examples of testing mechanisms are as follows: 1044 - Checking connectivity between "service-aware" network nodes 1045 - Verifying data plane and control plane integrity 1046 - Verifying service membership 1048 The provided mechanisms MUST satisfy the following: the 1049 connectivity checking for a given customer MUST enable the end-to-end 1050 testing of the data path used by that of customer's data packets and 1051 the test packets MUST not propagate beyond the boundary of the SP 1052 network. 1054 7.15 Support on Existing PEs 1055 To the extent possible, the IPLS solution SHOULD facilitate support 1056 of IPLS on existing PE devices that may be already deployed by the SP 1057 and MAY have been designed primarily for Layer 3 services. 1059 8 Service Provider Management Requirements 1060 A SP desires to have a means to view the topology, operational state, 1061 and other parameters associated with each customer's L2VPN. 1062 Furthermore, the SP requires a means to view the underlying logical 1063 and physical topology, operational state, provisioning status, and 1064 other parameters associated with the equipment providing the L2VPN 1065 service(s) to its customers. Therefore, the devices SHOULD provide 1066 standards-based interfaces (e.g., L2VPN MIB Modules) wherever 1067 feasible. 1069 The details of service provider management requirements for a Network 1070 Management System (NMS) in the traditional fault, configuration, 1071 accounting, performance, and security (FCAPS) management categories 1072 can be found in [ITU_Y.1311.1]. 1074 9 Engineering Requirements 1075 These requirements are driven by implementation characteristics that 1076 make service and SP requirements achievable. 1078 9.1 Control Plane Requirements 1079 A L2VPN service SHOULD be provisioned with minimum number of steps. 1080 Therefore, the control protocols SHOULD provide methods for signaling 1081 between PEs. The signaling SHOULD inform of membership, tunneling 1082 information, and other relevant parameters. 1084 The infrastructure MAY employ manual configuration methods to provide 1085 this type of information. 1087 The infrastructure SHOULD use policies to scope the membership and 1088 reachability advertisements for a particular L2VPN service. A 1089 mechanism for isolating the distribution of reachability information 1090 to only those sites associated with a L2VPN MUST be provided. 1092 The control plane traffic increases with the growth of L2VPN 1093 membership. Similarly, the control plane traffic increases with the 1094 number of supported L2VPN services. The use of control plane 1095 resources MAY increase as the number of hosts connected to a L2VPN 1096 service grows. 1098 A L2VPN solution SHOULD minimize control plane traffic and the 1099 consumption of control plane resources. The control plane MAY offer 1100 means for enforcing a limit on the number of customer hosts attached 1101 to a L2VPN service. 1103 9.2 Data Plane Requirements 1104 9.2.1 Encapsulation 1105 A L2VPN solution SHOULD utilize the encapsulation techniques defined 1106 by PWE3 ([RFC3985]), and SHOULD not impose any new requirements on 1107 these techniques. 1109 9.2.2 Responsiveness to Congestion 1110 A L2VPN solution SHOULD utilize the congestion avoidance techniques 1111 defined by PWE3 ([RFC3985]). 1113 9.2.3 Broadcast Domain 1114 A separate Broadcast Domain MUST be maintained for each VPLS. 1116 In addition to VPLS Broadcast Domains, a L2VPN service MAY honor 1117 customer VLAN Broadcast Domains, if customer VLANs are used as 1118 service delimiters. In that case, the L2VPN solution SHOULD maintain 1119 a separate VLAN Broadcast Domain for each customer VLAN. 1121 9.2.4 Virtual Switching Instance 1122 L2VPN PE devices MUST maintain a separate VSI per VPLS. Each VSI 1123 MUST have capabilities to forward traffic based on customer's traffic 1124 parameters such as MAC addresses, VLAN tags (if supported), etc. as 1125 well as local policies. 1127 L2VPN PE devices MUST have capabilities to classify incoming customer 1128 traffic into the appropriate VSI. 1130 Each VSI MUST have flooding capabilities for its Broadcast Domain to 1131 facilitate proper forwarding of Broadcast, Multicast and Unknown 1132 Unicast customer traffic. 1134 9.2.5 MAC address learning 1135 A VPLS SHOULD derive all topology and forwarding information from 1136 packets originating at customer sites. Typically, MAC address 1137 learning mechanisms are used for this purpose. With IPLS, snooping 1138 of particular packets originating at customer sites and signaling 1139 might also be used. 1141 Dynamic population of the forwarding information base (e.g., via MAC 1142 address learning) MUST take place on a per VSI basis, i.e., in the 1143 context of a VPLS and, if supported, in the context of VLANs therein. 1145 10 Security Considerations 1146 Security considerations occur at several levels and dimensions within 1147 L2VPNs, as detailed within this document. 1149 The requirements based on security concerns and potential security 1150 hazards are detailed in section 5.5.. Further details on security 1151 requirements are given from the customer and service provider 1152 perspectives in sections 6.5 and 7.6, respectively. In an analogous 1153 manner, further detail on traffic and routing isolation requirements 1154 are given from the customer and service provider perspectives in 1155 sections 5.4 and 7.5, respectively. Safeguards to protect network 1156 resources such as CPU, memory, and bandwidth are required in section 1157 7.12. 1159 IPsec can also be applied after tunneling Layer 2 traffic to provide 1160 additional security. 1162 In the case where a L2VPN service is carried over IP [RFC4023], 1163 traverses multiple SP networks and passes through an unsecured SP, 1164 POP, NAP, or IX, then security mechanisms MUST be employed. These 1165 security mechanisms include encryption, authentication, and resource 1166 protection, as described in section 5.5. For example, a provider 1167 should consider using both authentication and encryption for a tunnel 1168 used as part of an L2VPN that traverses another service provider's 1169 network. 1171 11 IANA Considerations 1172 This document creates no new requirements on IANA namespaces. 1174 12 Acknowledgments 1175 The authors would like to acknowledge extensive comments and 1176 contributions provided by Loa Andersson, Joel Halpern, Eric Rosen, 1177 Ali Sajassi, Muneyoshi Suzuki, Ananth Nagarajan, Dinesh Mohan, Yakov 1178 Rekhter, Matt Squire, Norm Finn, Scott Bradner, and Francois Le 1179 Faucheur. The authors, also, wish to extend their appreciations to 1180 their respective employers and various other people who volunteered 1181 to review this work and provided feedback. This work was done in 1182 consultation with the entire Layer 2 PPVPN design team. A lot of the 1183 text was adapted from the Layer 3 VPN requirements document produced 1184 by Layer 3 VPN requirements design team. 1186 13 References 1187 13.1 Normative References 1188 [RFC2119] Bradner, S. "Key words for use in RFCs to Indicate 1189 Requirement Levels", RFC 2119, March 1997. 1190 [RFC4026] Andersson, L., Madsen, T. "Provider Provisioned 1191 Virtual Private Network (VPN) Terminology", RFC 1192 4026, March 2005. 1194 13.2 Informative References 1195 [L2VPN_FR] Andersson, L., Rose, E. "Framework for Layer 2 1196 Virtual Private Networks (L2VPNs)", work in progress 1197 [VPLS_LDP] Lasserre, M., Kompella, V. "Virtual Private LAN 1198 Services over MPLS", work in progress 1199 [VPLS_BGP] Kompella, K., Rekhter, Y. "Virtual Private LAN 1200 Service", work in progress 1201 [IPLS] Shah, H., et al. "IP-Only LAN Service (IPLS)", work 1202 in progress 1204 [IEEE_802.1Q] IEEE Std 802.1Q-1998, "Virtual Bridged Local Area 1205 Networks", 1998 1206 [RFC3809] Nagarajan, A., et al. "Generic Requirements for 1207 Provider-provisioned Virtual Private Networks 1208 (PPVPN)", RFC3809, June 2004. 1209 [RFC3270] Le Faucheur, F., et al. "Multi-Protocol Label 1210 Switching (MPLS) Support of Differentiated 1211 Services", RFC 3270, May 2002. 1212 [RFC3308] Calhoun, P., et al, "Layer 2 Tunneling Protocol 1213 (L2TP) Differentiated Services Extension", RFC 3308, 1214 November 2002. 1215 [RFC2205] Braden, R., et al, "Resource ReSerVation Protocol 1216 (RSVP)", RFC 2205, September 1997. 1217 [RFC4031] Carugi, M., McDysan, D. et. al., "Service 1218 Requirements for Layer 3 Provider Provisioned 1219 Virtual Private Networks (PPVPNs)", RFC 4031, April 1220 2005. 1221 [RFC2474] Nichols, K., Blake, S., Baker, F. and D. Black, 1222 "Definition of the Differentiated Services Field (DS 1223 Field) in the IPv4 and IPv6 Headers", RFC 2474, 1224 December 1998. 1225 [IEEE_802.1D] ISO/IEC 15802-3: 1998 ANSI/IEEE Std 802.1D, 1998 1226 Edition (Revision and redesignation of ISO/IEC 1227 10038:98), "Part 3: Media Access Control (MAC) 1228 Bridges", 1998. 1229 [ITU_Y.1311.1] Carugi, M. (editor), "Network Based IP VPN over MPLS 1230 architecture",Y.1311.1 ITU-T Recommendation, May 1231 2001. 1232 [IEEE_802.10] IEEE Std 802.10-1998 Edition (Revision IEEE Std 1233 802.10-1992, incorporating IEEE Std 802.10b-1992, 1234 802.10e-1993, 802.10f-1993, 802.10g-1995, and 1235 802.10h-1997), "Standard for Interoperable LAN/MAN 1236 Security (SILS)", 1998. 1237 [IEEE_802.1AE] IEEE 802.1AE/D5.1, "Draft Standard for Local and 1238 Metropolitan Area Networks - Media Access Control 1239 (MAC) Security", P802.1AE/D5.1, January 19, 2006. 1240 [IEEE_802.1s] IEEE Std 802.1s-2002, "Virtual Bridged Local Area 1241 Networks- Amendment 3: Multiple Spanning Trees", 1242 2002. 1243 [RFC2685] Fox B., et al, "Virtual Private Networks 1244 Identifier", RFC 2685, September 1999. 1245 [RFC4023] Worster, T., and et. al., "Encapsulating MPLS in IP 1246 or Generic Routing Encapsulation", RFC 4023, March 1247 2005. 1248 [VPNSEC] De Clercq, J., et al., "Considerations about 1249 possiblesecurity extensions to BGP/MPLS VPN", Work 1250 in Progress. 1251 [RFC3985] Bryant, S. "Pseudo Wire Emulation Edge-to-Edge 1252 (PWE3) Architecture", RFC3985, March 2005. 1254 14 Editors' Addresses 1255 Waldemar Augustyn 1256 Email: waldemar@nxp.com 1258 Yetik Serbest 1259 AT&T Labs 1260 9505 Arboretum Blvd. 1261 Austin, TX 78759 1262 Email: yetik_serbest@labs.sbc.com 1264 15 Intellectual Property Statement 1266 The IETF takes no position regarding the validity or scope of any 1267 Intellectual Property Rights or other rights that might be claimed to 1268 pertain to the implementation or use of the technology described in 1269 this document or the extent to which any license under such rights 1270 might or might not be available; nor does it represent that it has 1271 made any independent effort to identify any such rights. Information 1272 on the procedures with respect to rights in RFC documents can be 1273 found in BCP 78 and BCP 79. 1275 Copies of IPR disclosures made to the IETF Secretariat and any 1276 assurances of licenses to be made available, or the result of an 1277 attempt made to obtain a general license or permission for the use of 1278 such proprietary rights by implementers or users of this 1279 specification can be obtained from the IETF on-line IPR repository at 1280 http://www.ietf.org/ipr. 1282 The IETF invites any interested party to bring to its attention any 1283 copyrights, patents or patent applications, or other proprietary 1284 rights that may cover technology that may be required to implement 1285 this standard. Please address the information to the IETF at ietf- 1286 ipr@ietf.org. 1288 16 Full copyright statement 1290 Copyright (C) The Internet Society (2006). This document is subject 1291 to the rights, licenses and restrictions contained in BCP 78, and 1292 except as set forth therein, the authors retain all their rights. 1294 This document and the information contained herein are provided on an 1295 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1296 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1297 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1298 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1299 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1300 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.