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