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