idnits 2.17.1 draft-ietf-l2vpn-vpls-ldp-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 3667, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.1 on line 41. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1258. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1227. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1234. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1240. ** Found boilerplate matching RFC 3978, Section 5.1 (on line 41), which is fine, but *also* found old RFC 3667, Section 5.1 text on line 14. ** 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 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([PWE3-ETHERNET], [PWE3-CTRL]), 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 -- 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.) -- The document date (July 2005) is 6857 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'PWE-CTRL' is mentioned on line 183, but not defined == Missing Reference: 'RFC-3036' is mentioned on line 1099, but not defined ** Obsolete undefined reference: RFC 3036 (Obsoleted by RFC 5036) == Outdated reference: A later version (-11) exists of draft-ietf-pwe3-ethernet-encap-10 ** Obsolete normative reference: RFC 3036 (Obsoleted by RFC 5036) == Outdated reference: A later version (-15) exists of draft-ietf-pwe3-iana-allocation-08 == Outdated reference: A later version (-02) exists of draft-ietf-l2vpn-radius-pe-discovery-01 == Outdated reference: A later version (-09) exists of draft-ietf-l3vpn-bgpvpn-auto-06 == Outdated reference: A later version (-07) exists of draft-ietf-l2vpn-requirements-04 Summary: 7 errors (**), 0 flaws (~~), 9 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft Document Marc Lasserre 3 L2VPN Working Group Vach Kompella 4 draft-ietf-l2vpn-vpls-ldp-07.txt (Editors) 5 Expires: January 2006 July 2005 7 Virtual Private LAN Services over MPLS 9 Status of this Memo 11 By submitting this Internet-Draft, we certify that any applicable 12 patent or other IPR claims of which we are aware have been 13 disclosed, or will be disclosed, and any of which we become aware 14 will be disclosed, in accordance with RFC 3668. 16 This document is an Internet-Draft and is in full conformance with 17 Sections 5 and 6 of RFC3667 and Section 5 of RFC3668. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six 25 months and may be updated, replaced, or obsoleted by other 26 documents at any time. It is inappropriate to use Internet-Drafts 27 as reference material or to cite them other than as "work in 28 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 IPR Disclosure Acknowledgement 38 By submitting this Internet-Draft, each author represents that any 39 applicable patent or other IPR claims of which he or she is aware 40 have been or will be disclosed, and any of which he or she becomes 41 aware will be disclosed, in accordance with Section 6 of BCP 79. 43 Abstract 45 This document describes a Virtual Private LAN Service (VPLS) 46 solution using pseudo-wires, a service previously implemented over 47 other tunneling technologies and known as Transparent LAN Services 48 (TLS). A VPLS creates an emulated LAN segment for a given set of 49 users, i.e., it creates a Layer 2 broadcast domain that is fully 50 capable of learning and forwarding on Ethernet MAC addresses that 51 is closed to a given set of users. Multiple VPLS services can be 52 supported from a single PE node. 54 This document describes the control plane functions of signaling 55 pseudo-wire labels, extending [PWE3-CTRL]. It is agnostic to 56 discovery protocols. The data plane functions of forwarding are 57 also described, focusing, in particular, on the learning of MAC 58 addresses. The encapsulation of VPLS packets is described by 59 [PWE3-ETHERNET]. 61 1. Conventions 63 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 64 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 65 this document are to be interpreted as described in RFC 2119. 67 2. Table of Contents 69 1. Conventions.....................................................2 70 2. Table of Contents...............................................2 71 3. Introduction....................................................3 72 4. Topological Model for VPLS......................................4 73 4.1. Flooding and Forwarding.......................................4 74 4.2. Address Learning..............................................5 75 4.3. Tunnel Topology...............................................5 76 4.4. Loop free VPLS................................................6 77 5. Discovery.......................................................6 78 6. Control Plane...................................................6 79 6.1. LDP Based Signaling of Demultiplexers.........................6 80 6.1.1. Using the Generalized PWid FEC Element......................7 81 6.2. MAC Address Withdrawal........................................7 82 6.2.1. MAC List TLV................................................8 83 6.2.2. Address Withdraw Message Containing MAC TLV.................9 84 7. Data Forwarding on an Ethernet PW...............................9 85 7.1. VPLS Encapsulation actions....................................9 86 7.2. VPLS Learning actions........................................10 87 8. Data Forwarding on an Ethernet VLAN PW.........................11 88 8.1. VPLS Encapsulation actions...................................11 89 9. Operation of a VPLS............................................12 90 9.1. MAC Address Aging............................................13 91 10. A Hierarchical VPLS Model.....................................13 92 10.1. Hierarchical connectivity...................................14 93 10.1.1. Spoke connectivity for bridging-capable devices...........14 94 10.1.2. Advantages of spoke connectivity..........................15 95 10.1.3. Spoke connectivity for non-bridging devices...............16 96 10.2. Redundant Spoke Connections.................................17 97 10.2.1. Dual-homed MTU............................................17 98 10.2.2. Failure detection and recovery............................18 99 10.3. Multi-domain VPLS service...................................19 100 11. Hierarchical VPLS model using Ethernet Access Network.........19 101 11.1. Scalability.................................................20 102 11.2. Dual Homing and Failure Recovery............................20 103 12. Significant Modifications.....................................21 104 13. Contributors..................................................21 105 14. Acknowledgments...............................................21 106 15. Security Considerations.......................................21 107 16. IANA Considerations...........................................22 108 17. References....................................................22 109 17.1. Normative References........................................22 110 17.2. Informative References......................................23 111 18. Appendix: VPLS Signaling using the PWid FEC Element...........23 112 19. Authors' Addresses............................................24 114 3. Introduction 116 Ethernet has become the predominant technology for Local Area 117 Network (LAN) connectivity and is gaining acceptance as an access 118 technology, specifically in Metropolitan and Wide Area Networks 119 (MAN and WAN, respectively). The primary motivation behind Virtual 120 Private LAN Services (VPLS) is to provide connectivity between 121 geographically dispersed customer sites across MANs and WANs, as if 122 they were connected using a LAN. The intended application for the 123 end-user can be divided into the following two categories: 125 - Connectivity between customer routers: LAN routing application 126 - Connectivity between customer Ethernet switches: LAN switching 127 application 129 Broadcast and multicast services are available over traditional 130 LANs. Sites that belong to the same broadcast domain and that are 131 connected via an MPLS network expect broadcast, multicast and 132 unicast traffic to be forwarded to the proper location(s). This 133 requires MAC address learning/aging on a per pseudo-wire basis, 134 packet replication across pseudo-wires for multicast/broadcast 135 traffic and for flooding of unknown unicast destination traffic. 137 [PWE3-ETHERNET] defines how to carry Layer 2 (L2) frames over 138 point-to-point pseudo-wires (PW). This document describes 139 extensions to [PWE3-CTRL] for transporting Ethernet/802.3 and VLAN 140 [802.1Q] traffic across multiple sites that belong to the same L2 141 broadcast domain or VPLS. Note that the same model can be applied 142 to other 802.1 technologies. It describes a simple and scalable 143 way to offer Virtual LAN services, including the appropriate 144 flooding of broadcast, multicast and unknown unicast destination 145 traffic over MPLS, without the need for address resolution servers 146 or other external servers, as discussed in [L2VPN-REQ]. 148 The following discussion applies to devices that are VPLS capable 149 and have a means of tunneling labeled packets amongst each other. 151 The resulting set of interconnected devices forms a private MPLS 152 VPN. 154 4. Topological Model for VPLS 156 An interface participating in a VPLS must be able to flood, 157 forward, and filter Ethernet frames. The set of PE devices 158 interconnected via PWs appears as a single emulated LAN to customer 159 C1. Each PE will form remote MAC address to PW associations and 160 associate directly attached MAC addresses to local customer facing 161 ports. This is modeled on standard IEEE 802.1 MAC address 162 learning. 164 +----+ +----+ 165 + C1 +---+ ........................... +---| C1 | 166 +----+ | . . | +----+ 167 Site A | +----+ +----+ | Site B 168 +---| PE | Cloud | PE |---+ 169 +----+ +----+ 170 . . 171 . +----+ . 172 ..........| PE |........... 173 +----+ ^ 174 | | 175 | +-- Emulated LAN 176 +----+ 177 | C1 | 178 +----+ 179 Site C 181 We note here again that while this document shows specific examples 182 using MPLS transport tunnels, other tunnels that can be used by PWs 183 (as mentioned in [PWE-CTRL]), e.g., GRE, L2TP, IPSEC, etc., can 184 also be used, as long as the originating PE can be identified, 185 since this is used in the MAC learning process. 187 The scope of the VPLS lies within the PEs in the service provider 188 network, highlighting the fact that apart from customer service 189 delineation, the form of access to a customer site is not relevant 190 to the VPLS [L2VPN-REQ]. In other words, the access circuit (AC) 191 connected to the customer could be a physical Ethernet port, a 192 logical (tagged) Ethernet port, an ATM PVC carrying Ethernet 193 frames, etc., or even an Ethernet PW. 195 The PE is typically an edge router capable of running the LDP 196 signaling protocol and/or routing protocols to set up PWs. In 197 addition, it is capable of setting up transport tunnels to other 198 PEs and delivering traffic over PWs. 200 4.1. Flooding and Forwarding 202 One of attributes of an Ethernet service is that frames sent to 203 broadcast addresses and to unknown destination MAC addresses are 204 flooded to all ports. To achieve flooding within the service 205 provider network, all unknown unicast, broadcast and multicast 206 frames are flooded over the corresponding PWs to all PE nodes 207 participating in the VPLS, as well as to all ACs. 209 Note that multicast frames are a special case and do not 210 necessarily have to be sent to all VPN members. For simplicity, 211 the default approach of broadcasting multicast frames can be used. 212 The use of IGMP snooping and PIM snooping techniques should be used 213 to improve multicast efficiency. A description of these techniques 214 is beyond the scope of this document. 216 To forward a frame, a PE MUST be able to associate a destination 217 MAC address with a PW. It is unreasonable and perhaps impossible 218 to require PEs to statically configure an association of every 219 possible destination MAC address with a PW. Therefore, VPLS- 220 capable PEs SHOULD have the capability to dynamically learn MAC 221 addresses on both ACs and PWs and to forward and replicate packets 222 across both ACs and PWs. 224 4.2. Address Learning 226 Unlike BGP VPNs [BGP-VPN], reachability information is not 227 advertised and distributed via a control plane. Reachability is 228 obtained by standard learning bridge functions in the data plane. 230 When a packet arrives on a PW, if the source MAC address is 231 unknown, it needs to be associated with the PW, so that outbound 232 packets to that MAC address can be delivered over the associated 233 PW. Likewise, when a packet arrives on an AC, if the source MAC 234 address is unknown, it needs to be associated with the AC, so that 235 outbound packets to that MAC address can be delivered over the 236 associated AC. 238 Standard learning, filtering and forwarding actions, as defined in 239 [802.1D-ORIG], [802.1D-REV] and [802.1Q], are required when a PW or 240 AC state changes. 242 4.3. Tunnel Topology 244 PE routers are assumed to have the capability to establish 245 transport tunnels. Tunnels are set up between PEs to aggregate 246 traffic. PWs are signaled to demultiplex encapsulated Ethernet 247 frames from multiple VPLS instances that traverse the transport 248 tunnels. 250 In an Ethernet L2VPN, it becomes the responsibility of the service 251 provider to create the loop free topology. For the sake of 252 simplicity, we define that the topology of a VPLS is a full mesh of 253 PWs. 255 4.4. Loop free VPLS 257 If the topology of the VPLS is not restricted to a full mesh, then 258 it may be that for two PEs not directly connected via PWs, they 259 would have to use an intermediary PE to relay packets. This 260 topology would require the use of some loop-breaking protocol, like 261 a spanning tree protocol. 263 Instead, a full mesh of PWs is established between PEs. Since 264 every PE is now directly connected to every other PE in the VPLS 265 via a PW, there is no longer any need to relay packets, and we can 266 instantiate a simpler loop-breaking rule - the "split horizon" 267 rule: a PE MUST NOT forward traffic from one PW to another in the 268 same VPLS mesh. 270 Note that customers are allowed to run the Spanning Tree Protocol 271 (STP) such as when a customer has "back door" links used to provide 272 redundancy in the case of a failure within the VPLS. In such a 273 case, STP Bridge PDUs (BPDUs) are simply tunneled through the 274 provider cloud. 276 5. Discovery 278 The capability to manually configure the addresses of the remote 279 PEs is REQUIRED. However, the use of manual configuration is not 280 necessary if an auto-discovery procedure is used. A number of 281 auto-discovery procedures are compatible with this document 282 ([RADIUS-DISC], [BGP-DISC]). 284 6. Control Plane 286 This document describes the control plane functions of signaling of 287 PW labels. Some foundational work in the area of support for 288 multi-homing is laid. The extensions to provide multi-homing 289 support should work independently of the basic VPLS operation, and 290 are not described here. 292 6.1. LDP Based Signaling of Demultiplexers 294 A full mesh of LDP sessions is used to establish the mesh of PWs. 295 The requirement for a full mesh of PWs may result in a large number 296 of targeted LDP sessions. Section 8 discusses the option of 297 setting up hierarchical topologies in order to minimize the size of 298 the VPLS full mesh. 300 Once an LDP session has been formed between two PEs, all PWs 301 between these two PEs are signaled over this session. 303 In [PWE3-CTRL], two types of FECs are described, the PWid FEC 304 Element (FEC type 128) and the Generalized PWid FEC Element (FEC 305 type 129). The original FEC element used for VPLS was compatible 306 with the PWid FEC Element. The text for signaling using PWid FEC 307 Element has been moved to Appendix 1. What we describe below 308 replaces that with a more generalized L2VPN descriptor, the 309 Generalized PWid FEC Element. 311 6.1.1. Using the Generalized PWid FEC Element 313 [PWE3-CTRL] describes a generalized FEC structure that is be used 314 for VPLS signaling in the following manner. We describe the 315 assignment of the Generalized PWid FEC Element fields in the 316 context of VPLS signaling. 318 Control bit (C): This bit is used to signal the use of the control 319 word as specified in [PWE3-CTRL]. 321 PW type: The allowed PW types are Ethernet (0x0005) and Ethernet 322 tagged mode (0x004) as specified in [IANA]. 324 VC info length: As specified in [PWE3-CTRL]. 326 AGI, Length, Value: The unique name of this VPLS. The AGI 327 identifies a type of name, Length denotes the length of Value, 328 which is the name of the VPLS. We use the term AGI interchangeably 329 with VPLS identifier. 331 TAII, SAII: These are null because the mesh of PWs in a VPLS 332 terminate on MAC learning tables, rather than on individual 333 attachment circuits. The use of non-null TAII and SAII is reserved 334 for future enhancements. 336 Interface Parameters: The relevant interface parameters are: 338 - MTU: the MTU of the VPLS MUST be the same across all the PWs 339 in the mesh. 341 - Optional Description String: same as [PWE3-CTRL]. 343 - Requested VLAN ID: If the PW type is Ethernet tagged mode, 344 this parameter may be used to signal the insertion of the 345 appropriate VLAN ID as specified in section 6.1. 347 6.2. MAC Address Withdrawal 349 It MAY be desirable to remove or unlearn MAC addresses that have 350 been dynamically learned for faster convergence. This is 351 accomplished by sending a MAC Address Withdraw Message with the 352 list of MAC addresses to be removed to all other PEs over the 353 corresponding LDP sessions. 355 We introduce an optional MAC List TLV that is used to specify a 356 list of MAC addresses that can be removed or unlearned using the 357 Address Withdraw Message. 358 The Address Withdraw message with MAC TLVs MAY be supported in 359 order to expedite removal of MAC addresses as the result of a 360 topology change (e.g., failure of the primary link for a dual-homed 361 MTU-s). 363 In order to minimize the impact on LDP convergence time, when the 364 MAC list TLV contains a large number of MAC addresses, it may be 365 preferable to send a MAC address withdrawal message with an empty 366 list. 368 6.2.1. MAC List TLV 370 MAC addresses to be unlearned can be signaled using an LDP Address 371 Withdraw Message that contains a new TLV, the MAC List TLV. Its 372 format is described below. The encoding of a MAC List TLV address 373 is the 6-byte MAC address specified by IEEE 802 documents [g-ORIG] 374 [802.1D-REV]. 376 0 1 2 3 377 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 |U|F| Type | Length | 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 | MAC address #1 | 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 | MAC address #1 | MAC Address #2 | 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 | MAC address #2 | 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 ~ ... ~ 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 | MAC address #n | 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 | MAC address #n | 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 U bit: Unknown bit. This bit MUST be set to 1. If the MAC address 395 format is not understood, then the TLV is not understood, and MUST 396 be ignored. 398 F bit: Forward bit. This bit MUST be set to 0. Since the LDP 399 mechanism used here is targeted, the TLV MUST NOT be forwarded. 401 Type: Type field. This field MUST be set to 0x0404 (subject to 402 IANA approval). This identifies the TLV type as MAC List TLV. 404 Length: Length field. This field specifies the total length of the 405 MAC addresses in the TLV. 407 MAC Address: The MAC address(es) being removed. 409 The MAC Address Withdraw Message contains a FEC TLV (to identify 410 the VPLS in consideration), a MAC Address TLV and optional 411 parameters. No optional parameters have been defined for the MAC 412 Address Withdraw signaling. Note that if a PE receives a MAC 413 Address Withdraw Message and does not understand it, it MUST ignore 414 the message. In this case, instead of flushing its MAC address 415 table, it will continue to use stale information, unless: 417 - it receives a packet with a known MAC address association, 418 but from a different PW, in which case it replaces the old 419 association, or 420 - it ages out the old association 422 The MAC Address Withdraw message only helps to speed up 423 convergence, so PEs that do not understand the message can continue 424 to participate in the VPLS. 426 6.2.2. Address Withdraw Message Containing MAC TLV 428 The processing for MAC List TLV received in an Address Withdraw 429 Message is: 431 For each MAC address in the TLV: 432 - Remove the association between the MAC address and the AC or 433 PW over which this message is received 435 For a MAC Address Withdraw message with empty list: 436 - Remove all the MAC addresses associated with the VPLS 437 instance (specified by the FEC TLV) except the MAC addresses 438 learned over the PW associated with this signaling session 439 over which the message was received 441 The scope of a MAC List TLV is the VPLS specified in the FEC TLV in 442 the MAC Address Withdraw Message. The number of MAC addresses can 443 be deduced from the length field in the TLV. 445 7. Data Forwarding on an Ethernet PW 447 This section describes the data plane behavior on an Ethernet 448 PW used in a VPLS. While the encapsulation is similar to that 449 described in [PWE3-ETHERNET], the NSP functions of stripping the 450 service-delimiting tag and using a "normalized" Ethernet frame are 451 described. 453 7.1. VPLS Encapsulation actions 455 In a VPLS, a customer Ethernet frame without preamble is 456 encapsulated with a header as defined in [PWE3-ETHERNET]. A 457 customer Ethernet frame is defined as follows: 459 - If the frame, as it arrives at the PE, has an encapsulation 460 that is used by the local PE as a service delimiter, i.e., to 461 identify the customer and/or the particular service of that 462 customer, then that encapsulation may be stripped before the 463 frame is sent into the VPLS. As the frame exits the VPLS, 464 the frame may have a service-delimiting encapsulation 465 inserted. 467 - If the frame, as it arrives at the PE, has an encapsulation 468 that is not service delimiting, then it is a customer frame 469 whose encapsulation should not be modified by the VPLS. This 470 covers, for example, a frame that carries customer-specific 471 VLAN tags that the service provider neither knows about nor 472 wants to modify. 474 As an application of these rules, a customer frame may arrive at a 475 customer-facing port with a VLAN tag that identifies the customer's 476 VPLS instance. That tag would be stripped before it is 477 encapsulated in the VPLS. At egress, the frame may be tagged 478 again, if a service-delimiting tag is used, or it may be untagged 479 if none is used. 481 Likewise, if a customer frame arrives at a customer-facing port 482 over an ATM or Frame Relay VC that identifies the customer's VPLS 483 instance, then the ATM or FR encapsulation is removed before the 484 frame is passed into the VPLS. 486 Contrariwise, if a customer frame arrives at a customer-facing port 487 with a VLAN tag that identifies a VLAN domain in the customer L2 488 network, then the tag is not modified or stripped, as it belongs 489 with the rest of the customer frame. 491 By following the above rules, the Ethernet frame that traverses a 492 VPLS is always a customer Ethernet frame. Note that the two 493 actions, at ingress and egress, of dealing with service delimiters 494 are local actions that neither PE has to signal to the other. They 495 allow, for example, a mix-and-match of VLAN tagged and untagged 496 services at either end, and do not carry across a VPLS a VLAN tag 497 that has local significance only. The service delimiter may be an 498 MPLS label also, whereby an Ethernet PW given by [PWE3-ETHERNET] 499 can serve as the access side connection into a PE. An RFC1483 500 Bridged PVC encapsulation could also serve as a service delimiter. 501 By limiting the scope of locally significant encapsulations to the 502 edge, hierarchical VPLS models can be developed that provide the 503 capability to network-engineer scalable VPLS deployments, as 504 described below. 506 7.2. VPLS Learning actions 508 Learning is done based on the customer Ethernet frame as defined 509 above. The Forwarding Information Base (FIB) keeps track of the 510 mapping of customer Ethernet frame addressing and the appropriate 511 PW to use. We define two modes of learning: qualified and 512 unqualified learning. 514 In unqualified learning, all the VLANs of a single customer are 515 handled by a single VPLS, which means they all share a single 516 broadcast domain and a single MAC address space. This means that 517 MAC addresses need to be unique and non-overlapping among customer 518 VLANs or else they cannot be differentiated within the VPLS 519 instance and this can result in loss of customer frames. An 520 application of unqualified learning is port-based VPLS service for 521 a given customer (e.g., customer with non-multiplexed AC where all 522 the traffic on a physical port, which may include multiple customer 523 VLANs, is mapped to a single VPLS instance). 525 In qualified learning, each customer VLAN is assigned to its own 526 VPLS instance, which means each customer VLAN has its own broadcast 527 domain and MAC address space. Therefore, in qualified learning, 528 MAC addresses among customer VLANs may overlap with each other, but 529 they will be handled correctly since each customer VLAN has its own 530 FIB, i.e., each customer VLAN has its own MAC address space. Since 531 VPLS broadcasts multicast frames by default, qualified learning 532 offers the advantage of limiting the broadcast scope to a given 533 customer VLAN. Qualified learning can result in large FIB table 534 sizes, because the logical MAC address is now a VLAN tag + MAC 535 address. 537 For STP to work in qualified mode, a VPLS PE must be able to 538 forward STP BPDUs over the proper VPLS instance. In a hierarchical 539 VPLS case (see details in Section 10), service delimiting tags (Q- 540 in-Q or [PWE3-ETHERNET]) can be added by MTU-s nodes such that PEs 541 can unambiguously identify all customer traffic, including STP/MSTP 542 BPDUs. In a basic VPLS case, upstream switches must insert such 543 service delimiting tags. When an access port is shared among 544 multiple customers, a reserved VLAN per customer domain must be 545 used to carry STP/MSTP traffic. The STP/MSTP frames are 546 encapsulated with a unique provider tag per customer (as the 547 regular customer traffic), and a PEs looks up the provider tag to 548 send such frames across the proper VPLS instance. 550 8. Data Forwarding on an Ethernet VLAN PW 552 This section describes the data plane behavior on an Ethernet VLAN 553 PW in a VPLS. While the encapsulation is similar to that described 554 in [PWE3-ETHERNET], the NSP functions of imposing tags and using a 555 "normalized" Ethernet frame are described. The learning behavior 556 is the same as for Ethernet PWs. 558 8.1. VPLS Encapsulation actions 560 In a VPLS, a customer Ethernet frame without preamble is 561 encapsulated with a header as defined in [PWE3-ETHERNET]. A 562 customer Ethernet frame is defined as follows: 564 - If the frame, as it arrives at the PE, has an encapsulation 565 that is part of the customer frame, and is also used by the 566 local PE as a service delimiter, i.e., to identify the 567 customer and/or the particular service of that customer, then 568 that encapsulation is preserved as the frame is sent into the 569 VPLS, unless the Requested VLAN ID optional parameter was 570 signaled. In that case, the VLAN tag is overwritten before 571 the frame is sent out on the PW. 573 - If the frame, as it arrives at the PE, has an encapsulation 574 that does not have the required VLAN tag, a null tag is 575 imposed if the Requested VLAN ID optional parameter was not 576 signaled. 578 As an application of these rules, a customer frame may arrive at a 579 customer-facing port with a VLAN tag that identifies the customer's 580 VPLS instance and also identifies a customer VLAN. That tag would 581 be preserved as it is encapsulated in the VPLS. 583 The Ethernet VLAN PW provides a simple way to preserve customer 584 802.1p bits. 586 A VPLS MAY have both Ethernet and Ethernet VLAN PWs. However, if a 587 PE is not able to support both PWs simultaneously, it SHOULD send a 588 Label Release on the PW messages that it cannot support with a 589 status code "Unknown FEC" as given in [RFC3036]. 591 9. Operation of a VPLS 593 We show here an example of how a VPLS works. The following 594 discussion uses the figure below, where a VPLS has been set up 595 between PE1, PE2 and PE3. 597 ----- 598 / A1 \ 599 ---- ----CE1 | 600 / \ -------- ------- / | | 601 | A2 CE2- / \ / PE1 \ / 602 \ / \ / \---/ \ ----- 603 ---- ---PE2 | 604 | Service Provider Network | 605 \ / \ / 606 ----- PE3 / \ / 607 |Agg|_/ -------- ------- 608 -| | 609 ---- / ----- ---- 610 / \/ \ / \ CE = Customer Edge Router 611 | A3 CE3 --C4 A4 | PE = Provider Edge Router 612 \ / \ / Agg = Layer 2 Aggregation 613 ---- ---- 615 Initially, the VPLS is set up so that PE1, PE2 and PE3 have a full 616 mesh of Ethernet PWs. The VPLS instance is assigned a identifier 617 (AGI). For the above example, say PE1 signals PW label 102 to PE2 618 and 103 to PE3, and PE2 signals PW label 201 to PE1 and 203 to PE3. 620 Assume a packet from A1 is bound for A2. When it leaves CE1, say 621 it has a source MAC address of M1 and a destination MAC of M2. If 622 PE1 does not know where M2 is, it will flood the packet, i.e., send 623 it to PE2 and PE3. When PE2 receives the packet, it will have a PW 624 label of 201. PE2 can conclude that the source MAC address M1 is 625 behind PE1, since it distributed the label 201 to PE1. It can 626 therefore associate MAC address M1 with PW label 102. 628 9.1. MAC Address Aging 630 PEs that learn remote MAC addresses SHOULD have an aging mechanism 631 to remove unused entries associated with a PW label. This is 632 important both for conservation of memory as well as for 633 administrative purposes. For example, if a customer site A is shut 634 down, eventually, the other PEs should unlearn A's MAC address. 636 The aging timer for MAC address M SHOULD be reset when a packet 637 with source MAC address M is received. 639 10. A Hierarchical VPLS Model 641 The solution described above requires a full mesh of tunnel LSPs 642 between all the PE routers that participate in the VPLS service. 643 For each VPLS service, n*(n-1)/2 PWs must be setup between the PE 644 routers. While this creates signaling overhead, the real detriment 645 to large scale deployment is the packet replication requirements 646 for each provisioned PWs on a PE router. Hierarchical 647 connectivity, described in this document reduces signaling and 648 replication overhead to allow large scale deployment. 650 In many cases, service providers place smaller edge devices in 651 multi-tenant buildings and aggregate them into a PE in a large 652 Central Office (CO) facility. In some instances, standard IEEE 653 802.1q (Dot 1Q) tagging techniques may be used to facilitate 654 mapping CE interfaces to VPLS access circuits at a PE. 656 It is often beneficial to extend the VPLS service tunneling 657 techniques into the MTU (multi-tenant unit) domain. This can be 658 accomplished by treating the MTU as a PE and provisioning PWs 659 between it and every other edge, as a basic VPLS. An alternative 660 is to utilize [PWE3-ETHERNET] PWs or Q-in-Q logical interfaces 661 between the MTU and selected VPLS enabled PE routers. Q-in-Q 662 encapsulation is another form of L2 tunneling technique, which can 663 be used in conjunction with MPLS signaling as will be described 664 later. The following two sections focus on this alternative 665 approach. The VPLS core PWs (hub) are augmented with access PWs 666 (spoke) to form a two-tier hierarchical VPLS (H-VPLS). 668 Spoke PWs may be implemented using any L2 tunneling mechanism, 669 expanding the scope of the first tier to include non-bridging VPLS 670 PE routers. The non-bridging PE router would extend a spoke PW 671 from a Layer-2 switch that connects to it, through the service core 672 network, to a bridging VPLS PE router supporting hub PWs. We also 673 describe how VPLS-challenged nodes and low-end CEs without MPLS 674 capabilities may participate in a hierarchical VPLS. 676 10.1. Hierarchical connectivity 678 This section describes the hub and spoke connectivity model and 679 describes the requirements of the bridging capable and non-bridging 680 MTU devices for supporting the spoke connections. For rest of this 681 discussion we refer to a bridging capable MTU as MTU-s and a non- 682 bridging capable PE as PE-r. We refer to a routing and bridging 683 capable device as PE-rs. 685 10.1.1. Spoke connectivity for bridging-capable devices 687 PE2-rs 688 ------ 689 / \ 690 | -- | 691 | / \ | 692 CE-1 | \S / | 693 \ \ -- / 694 \ /------ 695 \ MTU-s PE1-rs / | 696 \ ------ ------ / | 697 / \ / \ / | 698 | \ -- | PW-1 | -- |---/ | 699 | / \--|- - - - - - - - - - - |--/ \ | | 700 | \S / | | \S / | | 701 \ /-- / \ -- / ---\ | 702 /----- ------ \ | 703 / \ | 704 ---- \ ------ 705 |Agg | / \ 706 ---- | -- | 707 / \ | / \ | 708 CE-2 CE-3 | \S / | 709 \ -- / 710 MTU-s = Bridging capable MTU ------ 711 PE-rs = VPLS capable PE PE3-rs 712 Agg = Layer-2 Aggregation 713 -- 714 / \ 715 \S / = Virtual Switch Instance 716 -- 718 In the figure above where an MTU-s has a single connection to a PE- 719 rs placed in the CO. The PE-rs devices are connected in a basic 720 VPLS full mesh. For each VPLS service, a single spoke PW is set up 721 between the MTU-s and the PE-rs based on [PWE3-CTRL]. Unlike 722 traditional PWs that terminate on a physical (or a VLAN-tagged 723 logical) port, a spoke PW terminates on a virtual switch instance 724 (VSI, see [L2FRAME]) on the MTU-s and the PE-rs devices. 726 The MTU-s and the PE-rs treat each spoke connection like an AC of 727 the VPLS service. The PW label is used to associate the traffic 728 from the spoke to a VPLS instance. 730 10.1.1.1. MTU-s Operation 732 An MTU-s is defined as a device that supports layer-2 switching 733 functionality and does all the normal bridging functions of 734 learning and replication on all its ports, including the spoke, 735 which is treated as a virtual port. Packets to unknown 736 destinations are replicated to all ports in the service including 737 the spoke. Once the MAC address is learned, traffic between CE1 738 and CE2 will be switched locally by the MTU-s saving the capacity 739 of the spoke to the PE-rs. Similarly traffic between CE1 or CE2 740 and any remote destination is switched directly on to the spoke and 741 sent to the PE-rs over the point-to-point PW. 743 Since the MTU-s is bridging capable, only a single PW is required 744 per VPLS instance for any number of access connections in the same 745 VPLS service. This further reduces the signaling overhead between 746 the MTU-s and PE-rs. 748 If the MTU-s is directly connected to the PE-rs, other 749 encapsulation techniques such as Q-in-Q can be used for the spoke. 751 10.1.1.2. PE-rs Operation 753 A PE-rs is a device that supports all the bridging functions for 754 VPLS service and supports the routing and MPLS encapsulation, i.e., 755 it supports all the functions described for a basic VPLS as 756 described above. 758 The operation of PE-rs is independent of the type of device at the 759 other end of the spoke. Thus, the spoke from the MTU-s is treated 760 as a virtual port and the PE-rs will switch traffic between the 761 spoke PW, hub PWs, and ACs once it has learned the MAC addresses. 763 10.1.2. Advantages of spoke connectivity 765 Spoke connectivity offers several scaling and operational 766 advantages for creating large scale VPLS implementations, while 767 retaining the ability to offer all the functionality of the VPLS 768 service. 769 - Eliminates the need for a full mesh of tunnels and full mesh 770 of PWs per service between all devices participating in the 771 VPLS service. 772 - Minimizes signaling overhead since fewer PWs are required for 773 the VPLS service. 775 - Segments VPLS nodal discovery. MTU-s needs to be aware of 776 only the PE-rs node although it is participating in the VPLS 777 service that spans multiple devices. On the other hand, 778 every VPLS PE-rs must be aware of every other VPLS PE-rs and 779 all of its locally connected MTU-s and PE-r devices. 780 - Addition of other sites requires configuration of the new 781 MTU-s but does not require any provisioning of the existing 782 MTU-s devices on that service. 783 - Hierarchical connections can be used to create VPLS service 784 that spans multiple service provider domains. This is 785 explained in a later section. 787 Note that as more devices participate in the VPLS, there are more 788 devices that require the capability for learning and replication. 790 10.1.3. Spoke connectivity for non-bridging devices 792 In some cases, a bridging PE-rs may not be deployed in a CO or a 793 multi-tenant building, or a PE-r might already be deployed. In 794 this section, we explain how a PE-r that does not support any of 795 the VPLS bridging functionality can participate in the VPLS 796 service. As shown in this figure, the PE-r creates a point-to- 797 point tunnel LSP to a PE-rs. 799 PE2-rs 800 ------ 801 / \ 802 | -- | 803 | / \ | 804 CE-1 | \S / | 805 \ \ -- / 806 \ /------ 807 \ PE-r PE1-rs / | 808 \ ------ ------ / | 809 / \ / \ / | 810 | \ | VC-1 | -- |---/ | 811 | ------|- - - - - - - - - - - |--/ \ | | 812 | -----|- - - - - - - - - - - |--\S / | | 813 \ / / \ -- / ---\ | 814 ------ ------ \ | 815 / \ | 816 ---- \------ 817 | Agg| / \ 818 ---- | -- | 819 / \ | / \ | 820 CE-2 CE-3 | \S / | 821 \ -- / 822 ------ 823 PE3-rs 825 Then for every access port that needs to participate in a VPLS 826 service, the PE-r creates a point-to-point PW that terminates on 827 the physical port at the PE-r and terminates on the VSI of the VPLS 828 service at the PE-rs. 830 The PE-r is defined as a device that supports routing but does not 831 support any bridging functions. However, it is capable of setting 832 up PWs between itself and the PE-rs. For every port that is 833 supported in the VPLS service, a PW is setup from the PE-r to the 834 PE-rs. Once the PWs are setup, there is no learning or replication 835 function required on the part of the PE-r. All traffic received on 836 any of the ACs is transmitted on the PW. Similarly all traffic 837 received on a PW is transmitted to the AC where the PW terminates. 838 Thus traffic from CE1 destined for CE2 is switched at PE1-rs and 839 not at PE-r. 841 Note that in the case where PE-r devices use Provider VLANs (P- 842 VLAN) as demultiplexers instead of PWs, PE1-rs can treat them as 843 such and map these "circuits" into a VPLS domain to provide 844 bridging support between them. 846 This approach adds more overhead than the bridging capable (MTU-s) 847 spoke approach since a PW is required for every AC that 848 participates in the service versus a single PW required per service 849 (regardless of ACs) when an MTU-s is used. However, this approach 850 offers the advantage of offering a VPLS service in conjunction with 851 a routed internet service without requiring the addition of new 852 MTU. 854 10.2. Redundant Spoke Connections 856 An obvious weakness of the hub and spoke approach described thus 857 far is that the MTU has a single connection to the PE-rs. In case 858 of failure of the connection or the PE-rs, the MTU suffers total 859 loss of connectivity. 861 In this section we describe how the redundant connections can be 862 provided to avoid total loss of connectivity from the MTU. The 863 mechanism described is identical for both, MTU-s and PE-r devices. 865 10.2.1. Dual-homed MTU 867 To protect from connection failure of the PW or the failure of the 868 PE-rs, the MTU-s or the PE-r is dual-homed into two PE-rs devices, 869 as shown in figure-3. The PE-rs devices must be part of the same 870 VPLS service instance. 872 An MTU-s can set up two PWs (one each to PE1-rs and PE3-rs) for 873 each VPLS instance. One of the two PWs is designated as primary 874 and is the one that is actively used under normal conditions, while 875 the second PW is designated as secondary and is held in a standby 876 state. The MTU negotiates the PW labels for both the primary and 877 secondary PWs, but does not use the secondary PW unless the primary 878 PW fails. How a spoke is designated primary or secondary is 879 outside of the scope of this document. For example, a spanning 880 tree instance running between only the MTU and the two PE-rs nodes 881 is one possible method. Another method could be configuration. 883 PE2-rs 884 ------ 885 / \ 886 | -- | 887 | / \ | 888 CE-1 | \S / | 889 \ \ -- / 890 \ /------ 891 \ MTU-s PE1-rs / | 892 \------ ------ / | 893 / \ / \ / | 894 | -- | Primary PW | -- |---/ | 895 | / \--|- - - - - - - - - - - |--/ \ | | 896 | \S / | | \S / | | 897 \ -- \/ \ -- / ---\ | 898 ------\ ------ \ | 899 / \ \ | 900 / \ \ ------ 901 / \ / \ 902 CE-2 \ | -- | 903 \ Secondary PW | / \ | 904 - - - - - - - - - - - - - - - - - |-\S / | 905 \ -- / 906 ------ 907 PE3-rs 909 10.2.2. Failure detection and recovery 911 The MTU-s should control the usage of the spokes to the PE-rs 912 devices. If the spokes are PWs, then LDP signaling is used to 913 negotiate the PW labels, and the hello messages used for the LDP 914 session could be used to detect failure of the primary PW. The use 915 of other mechanisms which could provide faster detection failures 916 is outside the scope of this document. 918 Upon failure of the primary PW, MTU-s immediately switches to the 919 secondary PW. At this point the PE3-rs that terminates the 920 secondary PW starts learning MAC addresses on the spoke PW. All 921 other PE-rs nodes in the network think that CE-1 and CE-2 are 922 behind PE1-rs and may continue to send traffic to PE1-rs until they 923 learn that the devices are now behind PE3-rs. The unlearning 924 process can take a long time and may adversely affect the 925 connectivity of higher level protocols from CE1 and CE2. To enable 926 faster convergence, the PE3-rs where the secondary PW got activated 927 may send out a flush message (as explained in section 4.2), using 928 the MAC TLV as defined in Section 6, to all PE-rs nodes. Upon 929 receiving the message, PE-rs nodes flush the MAC addresses 930 associated with that VPLS instance. 932 10.3. Multi-domain VPLS service 934 Hierarchy can also be used to create a large scale VPLS service 935 within a single domain or a service that spans multiple domains 936 without requiring full mesh connectivity between all VPLS capable 937 devices. Two fully meshed VPLS networks are connected together 938 using a single LSP tunnel between the VPLS "border" devices. A 939 single spoke PW per VPLS service is set up to connect the two 940 domains together. 942 When more than two domains need to be connected, a full mesh of 943 inter-domain spokes is created between border PEs. Forwarding 944 rules over this mesh are identical to the rules defined in section 945 5. 947 This creates a three-tier hierarchical model that consists of a 948 hub-and-spoke topology between MTU-s and PE-rs devices, a full-mesh 949 topology between PE-rs, and a full mesh of inter-domain spokes 950 between border PE-rs devices. 952 This document does not specify how redundant border PEs per domain 953 per VPLS instance can be supported. 955 11. Hierarchical VPLS model using Ethernet Access Network 957 In this section the hierarchical model is expanded to include an 958 Ethernet access network. This model retains the hierarchical 959 architecture discussed previously in that it leverages the full- 960 mesh topology among PE-rs devices; however, no restriction is 961 imposed on the topology of the Ethernet access network (e.g., the 962 topology between MTU-s and PE-rs devices is not restricted to hub 963 and spoke). 965 The motivation for an Ethernet access network is that Ethernet- 966 based networks are currently deployed by some service providers to 967 offer VPLS services to their customers. Therefore, it is important 968 to provide a mechanism that allows these networks to integrate with 969 an IP or MPLS core to provide scalable VPLS services. 971 One approach of tunneling a customer's Ethernet traffic via an 972 Ethernet access network is to add an additional VLAN tag to the 973 customer's data (which may be either tagged or untagged). The 974 additional tag is referred to as Provider's VLAN (P-VLAN). Inside 975 the provider's network each P-VLAN designates a customer or more 976 specifically a VPLS instance for that customer. Therefore, there 977 is a one-to-one correspondence between a P-VLAN and a VPLS 978 instance. In this model, the MTU-s needs to have the capability of 979 adding the additional P-VLAN tag to non-multiplexed ACs where 980 customer VLANs are not used as service delimiters. This 981 functionality is described in [802.1ad]. 983 If customer VLANs need to be treated as service delimiters (e.g., 984 the AC is a multiplexed port), then the MTU-s needs to have the 985 additional capability of translating a customer VLAN (C-VLAN) to a 986 P-VLAN, or push an additional P-VLAN tag, in order to resolve 987 overlapping VLAN tags used by different customers. Therefore, the 988 MTU-s in this model can be considered as a typical bridge with this 989 additional capability. This functionality is described in 990 [802.1ad]. 992 The PE-rs needs to be able to perform bridging functionality over 993 the standard Ethernet ports toward the access network as well as 994 over the PWs toward the network core. In this model, the PE-rs may 995 need to run STP towards the access network, in addition to split- 996 horizon over the MPLS core. The PE-rs needs to map a P-VLAN to a 997 VPLS-instance and its associated PWs and vice versa. 999 The details regarding bridge operation for MTU-s and PE-rs (e.g., 1000 encapsulation format for Q-in-Q messages, customer's Ethernet 1001 control protocol handling, etc.) are outside of the scope of this 1002 document and they are covered in [802.1ad]. However, the relevant 1003 part is the interaction between the bridge module and the MPLS/IP 1004 PWs in the PE-rs, which behaves just as in a regular VPLS. 1006 11.1. Scalability 1008 Since each P-VLAN corresponds to a VPLS instance, the total number 1009 of VPLS instances supported is limited to 4K. The P-VLAN serves as 1010 a local service delimiter within the provider's network that is 1011 stripped as it gets mapped to a PW in a VPLS instance. Therefore, 1012 the 4K limit applies only within an Ethernet access network 1013 (Ethernet island) and not to the entire network. The SP network 1014 consists of a core MPLS/IP network that connects many Ethernet 1015 islands. Therefore, the number of VPLS instances can scale 1016 accordingly with the number of Ethernet islands (a metro region can 1017 be represented by one or more islands). 1019 11.2. Dual Homing and Failure Recovery 1021 In this model, an MTU-s can be dual homed to different devices 1022 (aggregators and/or PE-rs devices). The failure protection for 1023 access network nodes and links can be provided through running MSTP 1024 in each island. The MSTP of each island is independent from other 1025 islands and do not interact with each other. If an island has more 1026 than one PE-rs, then a dedicated full-mesh of PWs is used among 1027 these PE-rs devices for carrying the SP BPDU packets for that 1028 island. On a per P-VLAN basis, MSTP will designate a single PE-rs 1029 to be used for carrying the traffic across the core. The loop-free 1030 protection through the core is performed using split-horizon and 1031 the failure protection in the core is performed through standard 1032 IP/MPLS re-routing. 1034 12. Significant Modifications 1036 Between rev 06 and this one, these are the changes: 1038 - Incorporated comments from technical review team 1039 - Clarifications and edits 1040 - Fixed id-nits 1042 13. Contributors 1044 Loa Andersson, TLA 1045 Ron Haberman, Alcatel 1046 Juha Heinanen, Independent 1047 Giles Heron, Tellabs 1048 Sunil Khandekar, Alcatel 1049 Luca Martini, Cisco 1050 Pascal Menezes, Independent 1051 Rob Nath, Riverstone 1052 Eric Puetz, SBC 1053 Vasile Radoaca, Nortel 1054 Ali Sajassi, Cisco 1055 Yetik Serbest, SBC 1056 Nick Slabakov, Riverstone 1057 Andrew Smith, Consultant 1058 Tom Soon, SBC 1059 Nick Tingle, Alcatel 1061 14. Acknowledgments 1063 We wish to thank Joe Regan, Kireeti Kompella, Anoop Ghanwani, Joel 1064 Halpern, Rick Wilder, Jim Guichard, Steve Phillips, Norm Finn, Matt 1065 Squire, Muneyoshi Suzuki, Waldemar Augustyn, Eric Rosen, Yakov 1066 Rekhter, and Sasha Vainshtein for their valuable feedback. 1068 We would also like to thank Rajiv Papneja (ISOCORE), Winston Liu 1069 (Ixia), and Charlie Hundall for identifying issues with the draft 1070 in the course of the interoperability tests. 1072 We would also like to thank Ina Minei, Bob Thomas, Eric Gray and 1073 Dimitri Papadimitriou for their thorough technical review of the 1074 document. 1076 15. Security Considerations 1078 A more comprehensive description of the security issues involved in 1079 L2VPNs is covered in [VPN-SEC]. An unguarded VPLS service is 1080 vulnerable to some security issues which pose risks to the customer 1081 and provider networks. Most of the security issues can be avoided 1082 through implementation of appropriate guards. A couple of them can 1083 be prevented through existing protocols. 1085 - Data plane aspects 1086 - Traffic isolation between VPLS domains is guaranteed by 1087 the use of per VPLS L2 FIB table and the use of per VPLS 1088 PWs 1089 - The customer traffic, which consists of Ethernet frames, 1090 is carried unchanged over VPLS. If security is 1091 required, the customer traffic SHOULD be encrypted 1092 and/or authenticated before entering the service 1093 provider network 1094 - Preventing broadcast storms can be achieved by using 1095 routers as CPE devices or by rate policing the amount of 1096 broadcast traffic that customers can send 1097 - Control plane aspects 1098 - LDP security (authentication) methods as described in 1099 [RFC-3036] SHOULD be applied. This would prevent 1100 unauthenticated messages from disrupting a PE in a VPLS 1101 - Denial of service attacks 1102 - Some means to limit the number of MAC addresses (per site 1103 per VPLS) that a PE can learn SHOULD be implemented 1105 16. IANA Considerations 1107 The type field in the MAC TLV is defined as 0x404 in section 4.2.1 1108 and is subject to IANA approval. 1110 17. References 1112 17.1. Normative References 1114 [PWE3-ETHERNET] "Encapsulation Methods for Transport of Ethernet 1115 Frames Over IP/MPLS Networks", draft-ietf-pwe3-ethernet-encap- 1116 10.txt, Work in progress, June 2005. 1118 [PWE3-CTRL] "Transport of Layer 2 Frames over MPLS", draft-ietf- 1119 pwe3-control-protocol-17.txt, Work in progress, June 2005. 1121 [802.1D-ORIG] Original 802.1D - ISO/IEC 10038, ANSI/IEEE Std 1122 802.1D-1993 "MAC Bridges". 1124 [802.1D-REV] 802.1D - "Information technology - Telecommunications 1125 and information exchange between systems - Local and metropolitan 1126 area networks - Common specifications - Part 3: Media Access 1127 Control (MAC) Bridges: Revision. This is a revision of ISO/IEC 1128 10038: 1993, 802.1j-1992 and 802.6k-1992. It incorporates 1129 P802.11c, P802.1p and P802.12e." ISO/IEC 15802-3: 1998. 1131 [802.1Q] 802.1Q - ANSI/IEEE Draft Standard P802.1Q/D11, "IEEE 1132 Standards for Local and Metropolitan Area Networks: Virtual Bridged 1133 Local Area Networks", July 1998. 1135 [RFC3036] "LDP Specification", L. Andersson, et al., RFC 3036, 1136 January 2001. 1138 [IANA] "IANA Allocations for pseudo Wire Edge to Edge Emulation 1139 (PWE3)" Martini,Townsley, draft-ietf-pwe3-iana-allocation-08.txt, 1140 Work in progress, February 2005. 1142 17.2. Informative References 1144 [BGP-VPN] "BGP/MPLS VPNs", draft-ietf-l3vpn-rfc2547bis-03.txt, Work 1145 in Progress, October 2004. 1147 [RADIUS-DISC] "Using Radius for PE-Based VPN Discovery", draft- 1148 ietf-l2vpn-radius-pe-discovery-01.txt, Work in Progress, February 1149 2005. 1151 [BGP-DISC] "Using BGP as an Auto-Discovery Mechanism for Network- 1152 based VPNs", draft-ietf-l3vpn-bgpvpn-auto-06.txt, Work in Progress, 1153 June 2005. 1155 [L2FRAME] "Framework for Layer 2 Virtual Private Networks 1156 (L2VPNs)", draft-ietf-l2vpn-l2-framework-05, Work in Progress, June 1157 2004. 1159 [L2VPN-REQ] "Service Requirements for Layer-2 Provider Provisioned 1160 Virtual Private Networks", draft-ietf-l2vpn-requirements-04.txt, 1161 Work in Progress, October 2005. 1163 [VPN-SEC] "Security Framework for Provider Provisioned Virtual 1164 Private Networks", draft-ietf-l3vpn-security-framework-03.txt, Work 1165 in Progress, November 2004. 1167 [802.1ad] "IEEE standard for Provider Bridges", Work in Progress, 1168 December 2002. 1170 18. Appendix: VPLS Signaling using the PWid FEC Element 1172 This section is being retained because live deployments use this 1173 version of the signaling for VPLS. 1175 The VPLS signaling information is carried in a Label Mapping 1176 message sent in downstream unsolicited mode, which contains the 1177 following VC FEC TLV. 1179 VC, C, VC Info Length, Group ID, Interface parameters are as 1180 defined in [PWE3-CTRL]. 1182 We use the Ethernet PW type to identify PWs that carry Ethernet 1183 traffic for multipoint connectivity. 1185 0 1 2 3 1186 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1188 | VC TLV |C| PW Type |PW info Length | 1189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1190 | Group ID | 1191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1192 | VCID | 1193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1194 | Interface parameters | 1195 ~ ~ 1196 | | 1197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1199 In a VPLS, we use a VCID (which, when using the PWid FEC, has been 1200 substituted with a more general identifier (AGI), to address 1201 extending the scope of a VPLS) to identify an emulated LAN segment. 1202 Note that the VCID as specified in [PWE3-CTRL] is a service 1203 identifier, identifying a service emulating a point-to-point 1204 virtual circuit. In a VPLS, the VCID is a single service 1205 identifier, so it has global significance across all PEs involved 1206 in the VPLS instance. 1208 19. Authors' Addresses 1210 Marc Lasserre 1211 Riverstone Networks 1212 Email: marc@riverstonenet.com 1214 Vach Kompella 1215 Alcatel 1216 Email: vach.kompella@alcatel.com 1218 IPR Disclosure Acknowledgement 1220 The IETF takes no position regarding the validity or scope of any 1221 Intellectual Property Rights or other rights that might be claimed 1222 to pertain to the implementation or use of the technology described 1223 in this document or the extent to which any license under such 1224 rights might or might not be available; nor does it represent that 1225 it has made any independent effort to identify any such rights. 1226 Information on the procedures with respect to rights in RFC 1227 documents can be found in BCP 78 and BCP 79. 1229 Copies of IPR disclosures made to the IETF Secretariat and any 1230 assurances of licenses to be made available, or the result of an 1231 attempt made to obtain a general license or permission for the use 1232 of such proprietary rights by implementers or users of this 1233 specification can be obtained from the IETF on-line IPR repository 1234 at http://www.ietf.org/ipr. 1236 The IETF invites any interested party to bring to its attention any 1237 copyrights, patents or patent applications, or other proprietary 1238 rights that may cover technology that may be required to implement 1239 this standard. Please address the information to the IETF at ietf- 1240 ipr@ietf.org. 1242 Copyright Notice 1244 Copyright (C) The Internet Society (2005). This document is 1245 subject to the rights, licenses and restrictions contained in BCP 1246 78, and except as set forth therein, the authors retain all their 1247 rights. 1249 Disclaimer 1251 This document and the information contained herein are provided on 1252 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1253 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 1254 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 1255 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 1256 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 1257 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 1258 PARTICULAR PURPOSE.