idnits 2.17.1 draft-ietf-l2vpn-vpls-ldp-01.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == Mismatching filename: the document gives the document name as 'draft-ietf-ppvpn-vpls-ldp-01', but the file name used is 'draft-ietf-l2vpn-vpls-ldp-01' == There are 4 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 25 longer pages, the longest (page 2) being 66 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 26 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 14. Security Considerations' ) ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** The abstract seems to contain references ([PWE3-ETHERNET], [PWE3-CTRL]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? RFC 2119 keyword, line 307: '... Each PE MUST create a rooted tree t...' RFC 2119 keyword, line 308: '...e VPLS. Each PE MUST support a "split...' RFC 2119 keyword, line 309: '...s, that is, a PE MUST NOT forward traf...' RFC 2119 keyword, line 392: '... It MAY be desirable to remove or re...' RFC 2119 keyword, line 399: '...ge with MAC TLVs MAY be supported in o...' (7 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- Couldn't find a document date in the document -- date freshness check skipped. 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 section? 'PWE3-CTRL' on line 1115 looks like a reference -- Missing reference section? 'PWE3-ETHERNET' on line 1111 looks like a reference -- Missing reference section? 'L2VPN-REQ' on line 1159 looks like a reference -- Missing reference section? 'MPLS-GRE' on line 192 looks like a reference -- Missing reference section? 'BGP-VPN' on line 1132 looks like a reference -- Missing reference section? 'BGP-DISC' on line 1142 looks like a reference -- Missing reference section? 'RADIUS-DISC' on line 1138 looks like a reference -- Missing reference section? 'LDP-DISC' on line 1146 looks like a reference -- Missing reference section? 'VPLS-BRIDGING' on line 1150 looks like a reference -- Missing reference section? '8' on line 370 looks like a reference -- Missing reference section? 'VPLS' on line 769 looks like a reference -- Missing reference section? 'RFC3036' on line 1135 looks like a reference -- Missing reference section? 'L2VPN-SIG' on line 1153 looks like a reference -- Missing reference section? 'L2FRAME' on line 1156 looks like a reference Summary: 8 errors (**), 0 flaws (~~), 7 warnings (==), 15 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft Document Marc Lasserre 3 Provider Provisioned VPN Working Group Riverstone Networks 4 draft-ietf-ppvpn-vpls-ldp-01.txt Vach Kompella 5 Nick Tingle 6 Sunil Khandekar 7 Timetra Networks 9 Ali Sajassi 10 Cisco Systems 12 Pascal Menezes Loa Andersson 13 Terabeam Networks Consultant 15 Andrew Smith Pierre Lin 16 Consultant Yipes Communication 18 Juha Heinanen Giles Heron 19 Song Networks PacketExchange Ltd. 21 Ron Haberman Tom S.C. Soon 22 Masergy, Inc. Yetik Serbest 23 Eric Puetz 24 Nick Slabakov SBC Communications 25 Rob Nath 26 Riverstone Networks 27 Luca Martini 28 Vasile Radoaca Level 3 29 Nortel Networks Communications 31 Expires: May 2004 November 2003 33 Virtual Private LAN Services over MPLS 34 draft-ietf-ppvpn-vpls-ldp-01.txt 36 1. Status of this Memo 38 This document is an Internet-Draft and is in full conformance 39 with all provisions of Section 10 of RFC2026. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF), its areas, and its working groups. Note that 43 other groups may also distribute working documents as Internet- 44 Drafts. 46 Internet-Drafts are draft documents valid for a maximum of six 47 months and may be updated, replaced, or obsoleted by other documents 48 at any time. It is inappropriate to use Internet-Drafts as 49 reference material or to cite them other than as "work in progress." 51 The list of current Internet-Drafts can be accessed at 52 http://www.ietf.org/ietf/1id-abstracts.txt 54 The list of Internet-Draft Shadow Directories can be accessed at 55 http://www.ietf.org/shadow.html. 57 2. Abstract 59 This document describes a virtual private LAN service (VPLS) 60 solution over MPLS, also known as Transparent LAN Services (TLS). A 61 VPLS creates an emulated LAN segment for a given set of users. It 62 delivers a layer 2 broadcast domain that is fully capable of 63 learning and forwarding on Ethernet MAC addresses that is closed to 64 a given set of users. Many VPLS services can be supported from a 65 single PE node. 67 This document describes the control plane functions of signaling 68 demultiplexor labels, extending [PWE3-CTRL] and rudimentary support 69 for availability (multi-homing). It is agnostic to discovery 70 protocols. The data plane functions of forwarding are also 71 described, focusing, in particular, on the learning of MAC 72 addresses. The encapsulation of VPLS packets is described by [PWE3- 73 ETHERNET]. 75 3. Conventions 77 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 78 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 79 document are to be interpreted as described in RFC 2119 81 Placement of this Memo in Sub-IP Area 83 RELATED DOCUMENTS 85 www.ietf.org/internet-drafts/draft-ietf-ppvpn-l2vpn-requirements- 86 01.txt 87 www.ietf.org/internet-drafts/draft-ietf-ppvpn-l2-framework-03.txt 88 www.ietf.org/internet-drafts/draft-ietf-pwe3-ethernet-encap-02.txt 89 www.ietf.org/internet-drafts/draft-ietf-pwe3-control-protocol-01.txt 91 WHERE DOES THIS FIT IN THE PICTURE OF THE SUB-IP WORK 93 PPVPN 95 WHY IS IT TARGETED AT THIS WG 97 The charter of the PPVPN WG includes L2 VPN services and this draft 98 specifies a model for Ethernet L2 VPN services over MPLS. 100 JUSTIFICATION 102 Existing Internet drafts specify how to provide point-to-point 103 Ethernet L2 VPN services over MPLS. This draft defines how 104 multipoint Ethernet services can be provided. 106 Table of Contents 108 1. Status of this Memo.............................................1 109 2. Abstract........................................................2 110 3. Conventions.....................................................2 111 4. Overview........................................................4 112 5. Topological Model for VPLS......................................5 113 5.1. Flooding and Forwarding.......................................5 114 5.2. Address Learning..............................................6 115 5.3. LSP Topology..................................................6 116 5.4. Loop free L2 VPN..............................................7 117 6. Discovery.......................................................7 118 7. Control Plane...................................................7 119 7.1. LDP Based Signaling of Demultiplexors.........................7 120 7.2. MAC Address Withdrawal........................................9 121 7.2.1. MAC TLV.....................................................9 122 7.2.2. Address Withdraw Message Containing MAC TLV................10 123 8. Data Forwarding on an Ethernet VC Type.........................11 124 8.1. VPLS Encapsulation actions...................................11 125 8.1.1. VPLS Learning actions......................................12 126 9. Operation of a VPLS............................................13 127 9.1. MAC Address Aging............................................13 128 10. A Hierarchical VPLS Model.....................................14 129 10.1. Hierarchical connectivity...................................14 130 10.1.1. Spoke connectivity for bridging-capable devices...........15 131 10.1.2. Advantages of spoke connectivity..........................16 132 10.1.3. Spoke connectivity for non-bridging devices...............17 133 10.2. Redundant Spoke Connections.................................18 134 10.2.1. Dual-homed MTU device.....................................18 135 10.2.2. Failure detection and recovery............................19 136 10.3. Multi-domain VPLS service...................................20 137 11. Hierarchical VPLS model using Ethernet Access Network.........20 138 11.1. Scalability.................................................21 139 11.2. Dual Homing and Failure Recovery............................22 140 12. Significant Modifications.....................................22 141 13. Acknowledgments...............................................22 142 14. Security Considerations.......................................22 143 15. Intellectual Property Considerations..........................22 144 16. Full Copyright Statement......................................23 145 17. References....................................................23 146 18. Authors' Addresses............................................24 147 4. Overview 149 Ethernet has become the predominant technology for Local Area 150 Networks (LANs) connectivity and is gaining acceptance as an access 151 technology, specifically in Metropolitan and Wide Area Networks (MAN 152 and WAN respectively). An Ethernet port is used to connect a 153 customer to the Provider Edge (PE) router acting as an LER. Customer 154 traffic is subsequently mapped to a specific MPLS L2 VPN by 155 configuring L2 FECs based upon the input port ID and/or VLAN tag 156 depending upon the VPLS service. 158 Broadcast and multicast services are available over traditional 159 LANs. MPLS does not support such services currently. Sites that 160 belong to the same broadcast domain and that are connected via an 161 MPLS network expect broadcast, multicast and unicast traffic to be 162 forwarded to the proper location(s). This requires MAC address 163 learning/aging on a per LSP basis, packet replication across LSPs 164 for multicast/broadcast traffic and for flooding of unknown unicast 165 destination traffic. 167 The primary motivation behind Virtual Private LAN Services (VPLS) is 168 to provide connectivity between geographically dispersed customer 169 sites across MAN/WAN network(s), as if they were connected using a 170 LAN. The intended application for the end-user can be divided into 171 the following two categories: 173 - Connectivity between customer routers � LAN routing application 174 - Connectivity between customer Ethernet switches � LAN switching 175 application 177 [PWE3-ETHERNET] defines how to carry L2 PDUs over point-to-point 178 MPLS LSPs, called pseudowires (PW). Such PWs can be carried over 179 MPLS or GRE tunnels. This document describes extensions to [PWE3- 180 CTRL] for transporting Ethernet/802.3 and VLAN [802.1Q] traffic 181 across multiple sites that belong to the same L2 broadcast domain or 182 VPLS. Note that the same model can be applied to other 802.1 183 technologies. It describes a simple and scalable way to offer 184 Virtual LAN services, including the appropriate flooding of 185 Broadcast, Multicast and unknown unicast destination traffic over 186 MPLS, without the need for address resolution servers or other 187 external servers, as discussed in [L2VPN-REQ]. 189 The following discussion applies to devices that are VPLS capable 190 and have a means of tunneling labeled packets amongst each other. 191 While MPLS LSPs may be used to tunnel these labeled packets, other 192 technologies may be used as well, e.g., GRE [MPLS-GRE]. The 193 resulting set of interconnected devices forms a private MPLS VPN. 195 5. Topological Model for VPLS 197 An interface participating in a VPLS must be able to flood, forward, 198 and filter Ethernet frames. 200 +----+ +----+ 201 + C1 +---+ ........................... +---| C1 | 202 +----+ | . . | +----+ 203 Site A | +----+ +----+ | Site B 204 +---| PE |------ Cloud -------| PE |---+ 205 +----+ | +----+ 206 . | . 207 . +----+ . 208 ..........| PE |........... 209 +----+ ^ 210 | | 211 | +-- Emulated LAN 212 +----+ 213 | C1 | 214 +----+ 215 Site C 217 The set of PE devices interconnected via pseudowires appears as a 218 single emulated LAN to customer C1. Each PE device will learn remote 219 MAC address to pseudowire associations and will also learn directly 220 attached MAC addresses on customer facing ports. 222 We note here again that while this document shows specific examples 223 using MPLS transport tunnels, other tunnels that can be used by 224 pseudo-wires, e.g., GRE, L2TP, IPSEC, etc., can also be used, as 225 long as the originating PE can be identified, since this is used in 226 the MAC learning process. 228 The scope of the VPLS lies within the PEs in the service provider 229 network, highlighting the fact that apart from customer service 230 delineation, the form of access to a customer site is not relevant 231 to the VPLS [L2VPN-REQ]. 233 The PE device is typically an edge router capable of running a 234 signaling protocol and/or routing protocols to set up pseudowires. 235 In addition, it is capable of setting up transport tunnels to other 236 PEs and deliver traffic over a pseudowire. 238 5.1. Flooding and Forwarding 240 One of attributes of an Ethernet service is that all broadcast and 241 destination unknown MAC addresses are flooded to all ports. To 242 achieve flooding within the service provider network, all address 243 unknown unicast, broadcast and multicast frames are flooded over the 244 corresponding pseudowires to all relevant PE nodes participating in 245 the VPLS. 247 Note that multicast frames are a special case and do not necessarily 248 have to be sent to all VPN members. For simplicity, the default 249 approach of broadcasting multicast frames can be used. The use of 250 IGMP snooping and PIM snooping techniques should be used to improve 251 multicast efficiency. 253 To forward a frame, a PE must be able to associate a destination MAC 254 address with a pseudowire. It is unreasonable and perhaps impossible 255 to require PEs to statically configure an association of every 256 possible destination MAC address with a pseudowire. Therefore, VPLS- 257 capable PEs must have the capability to dynamically learn MAC 258 addresses on both physical ports and virtual circuits and to forward 259 and replicate packets across both physical ports and pseudowires. 261 5.2. Address Learning 263 Unlike BGP VPNs [BGP-VPN], reachability information does not need to 264 be advertised and distributed via a control plane. Reachability is 265 obtained by standard learning bridge functions in the data plane. 267 As discussed previously, a pseudowire consists of a pair of uni- 268 directional VC LSPs. When a new MAC address is learned on an 269 inbound VC LSP, it needs to be associated with the outbound VC LSP 270 that is part of the same pair. The state of this pseudowire is 271 considered operationally up when both incoming and outgoing VC LSPs 272 are established. Similarly, it is considered operationally down 273 when one of these two VC LSPs is torn down. 275 Standard learning, filtering and forwarding actions, as defined in 276 [802.1D-ORIG], [802.1D-REV] and [802.1Q], are required when a 277 logical link state changes. 279 5.3. Tunnel Topology 281 PE routers typically run an IGP between them, and are assumed to 282 have the capability to establish transport tunnels. Tunnels are set 283 up between PEs to aggregate traffic. Pseudowires are signaled to 284 demultiplex the L2 encapsulated packets that traverse the tunnels. 286 In an Ethernet L2VPN, it becomes the responsibility of the service 287 provider to create the loop free topology. For the sake of 288 simplicity, we define that the topology of a VPLS is a full mesh of 289 tunnels and pseudowires. 291 5.4. Loop free L2 VPN 293 For simplicity, a full mesh of pseudowires is established between 294 PEs. Ethernet bridges, unlike Frame Relay or ATM where the 295 termination point becomes the CE node, have to examine the layer 2 296 fields of the packets to make a switching decision. If the frame is 297 directed to an unknown destination, or is a broadcast or multicast 298 frame, the frame must be flooded. 300 Therefore, if the topology isn't a full mesh, the PE devices may 301 need to forward these frames to other PEs. However, this would 302 require the use of spanning tree protocol to form a loop free 303 topology, that may have characteristics that are undesirable to the 304 provider. The use of a full mesh and split-horizon forwarding 305 obviates the need for a spanning tree protocol. 307 Each PE MUST create a rooted tree to every other PE router that 308 serve the same VPLS. Each PE MUST support a "split-horizon" scheme 309 in order to prevent loops, that is, a PE MUST NOT forward traffic 310 from one pseudowire to another in the same VPLS (since each PE has 311 direct connectivity to all other PEs in the same VPLS). 313 Note that customers are allowed to run STP such as when a customer 314 has "back door" links used to provide redundancy in the case of a 315 failure within the VPLS. In such a case, STP BPDUs are simply 316 tunneled through the provider cloud. 318 6. Discovery 320 Currently, no discovery mechanism has been prescribed for VPLS. 321 There are three potential candidates, [BGP-DISC], [RADIUS-DISC], 322 [LDP-DISC]. 324 7. Control Plane 326 This document describes the control plane functions of Demultiplexor 327 Exchange (signaling of VC labels). Some foundational work in the 328 area of support for multi-homing is laid, although that work is 329 described in a different document [VPLS-BRIDGING]. 331 7.1. LDP Based Signaling of Demultiplexors 333 In order to establish a full mesh of pseudowires, all PEs in a VPLS 334 must have a full mesh of LDP sessions. 336 Once an LDP session has been formed between two PEs, all pseudowires 337 are signaled over this session. 339 In [PWE3-CTRL], the L2 VPN information is carried in a Label Mapping 340 message sent in downstream unsolicited mode, which contains the 341 following VC FEC TLV. VC, C, VC Info Length, Group ID, Interface 342 parameters are as defined in [PWE3-CTRL]. 344 0 1 2 3 345 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 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 | VC tlv |C| VC Type |VC info Length | 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 | Group ID | 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 | VCID | 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 | Interface parameters | 354 ~ ~ 355 | | 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 This document uses the VC type value for Ethernet as defined in 359 [PWE3-CTRL]: 361 VC Type Description 363 0x0001 Frame Relay DLCI 364 0x0002 ATM AAL5 VCC transport 365 0x0003 ATM transparent cell transport 366 0x0004 Ethernet VLAN 367 0x0005 Ethernet 368 0x0006 HDLC 369 0x0007 PPP 370 0x8008 CEM [8] 371 0x0009 ATM VCC cell transport 372 0x000A ATM VPC cell transport 374 VC types 0x0004 and 0x0005 identify pseudowire types that carry VLAN 375 tagged and untagged Ethernet traffic respectively, for point-to- 376 point connectivity. 378 We use the VC type Ethernet with codepoint 0x0005 to identify 379 pseudowires that carry Ethernet traffic for multipoint connectivity. 380 The Ethernet VC Type described below, conforms to the Ethernet VC 381 Type defined in [PWE3-CTRL]. 383 In a VPLS, we use a VCID (to be substituted with a VPNID TLV later, 384 to address extending the scope of a VPLS) to identify an emulated 385 LAN segment. Note that the VCID as specified in [PWE3-CTRL] is a 386 service identifier, identifying a service emulating a point-to-point 387 virtual circuit. In a VPLS, the VCID is a single service 388 identifier. 390 7.2. MAC Address Withdrawal 392 It MAY be desirable to remove or relearn MAC addresses that have 393 been dynamically learned for faster convergence. 395 We introduce an optional MAC TLV that is used to specify a list of 396 MAC addresses that can be removed or relearned using the Address 397 Withdraw Message. 399 The Address Withdraw message with MAC TLVs MAY be supported in order 400 to expedite removal of MAC addresses as the result of a topology 401 change (e.g., failure of the primary link for a dual-homed MTU-s). 402 If a notification message is sent on the backup link (blocked link), 403 which has transitioned into an active state (e.g., similar to 404 Topology Change Notification message of 802.1w RSTP), with a list of 405 MAC entries to be relearned, the PE will update the MAC entries in 406 its FIB for that VPLS instance and send the message to other PEs 407 over the corresponding directed LDP sessions. 409 If the notification message contains an empty list, this tells the 410 receiving PE to remove all the MAC addresses learned for the 411 specified VPLS instance except the ones it learned from the sending 412 PE (MAC address removal is required for all VPLS instances that are 413 affected). Note that the definition of such a notification message 414 is outside the scope of the document, unless it happens to come from 415 an MTU connected to the PE as a spoke. In such a scenario, the 416 message will be just an Address Withdraw message as noted above. 418 7.2.1. MAC TLV 420 MAC addresses to be relearned can be signaled using an LDP Address 421 Withdraw Message that contains a new TLV, the MAC TLV. Its format 422 is described below. The encoding of a MAC TLV address is the 6-byte 423 MAC address specified by IEEE 802 documents [g-ORIG] [802.1D-REV]. 425 0 1 2 3 426 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 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 |U|F| Type | Length | 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 | MAC address #1 | 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 | MAC address #n | 433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 435 U bit 436 Unknown bit. This bit MUST be set to 0. If the MAC address 437 format is not understood, then the TLV is not understood, and MUST 438 be ignored. 440 F bit 441 Forward bit. This bit MUST be set to 0. Since the LDP 442 mechanism used here is Targeted, the TLV MUST NOT be forwarded. 444 Type 445 Type field. This field MUST be set to 0x0404 (subject to IANA 446 approval). This identifies the TLV type as MAC TLV. 448 Length 449 Length field. This field specifies the total length of the MAC 450 addresses in the TLV. 452 MAC Address 453 The MAC address(es) being removed. 455 The LDP Address Withdraw Message contains a FEC TLV (to identify the 456 VPLS in consideration), a MAC Address TLV and optional parameters. 457 No optional parameters have been defined for the MAC Address 458 Withdraw signaling. 460 7.2.2. Address Withdraw Message Containing MAC TLV 462 When MAC addresses are being removed or relearned explicitly, e.g., 463 the primary link of a dual-homed MTU-s has failed, an Address 464 Withdraw Message with the list of MAC addresses to be relearned can 465 be sent to all other PEs over the corresponding directed LDP 466 sessions. 468 The processing for MAC TLVs received in an Address Withdraw Message 469 is: 470 For each MAC address in the TLV: 471 - Relearn the association between the MAC address and the 472 interface/pseudowire over which this message is received 474 For an Address Withdraw message with empty list: 475 - Remove all the MAC addresses associated with the VPLS instance 476 (specified by the FEC TLV) except the MAC addresses learned 477 over this link (over the pseudowire associated with the 478 signaling link over which the message is received) 480 The scope of a MAC TLV is the VPLS specified in the FEC TLV in the 481 Address Withdraw Message. The number of MAC addresses can be 482 deduced from the length field in the TLV. 484 Further descriptions of how to deal with failures expeditiously with 485 different configurations will be described in other documents, such 486 as [VPLS-BRIDGING]. 488 8. Data Forwarding on an Ethernet VC Type 490 This section describes the dataplane behavior on an Ethernet VPLS 491 pseudowire. While the encapsulation is similar to that described in 492 [PWE3-ETHERNET], the NSP functions of stripping the service- 493 delimiting tag, and using a "normalized" Ethernet packet are 494 described. 496 8.1. VPLS Encapsulation actions 498 In a VPLS, a customer Ethernet packet without preamble is 499 encapsulated with a header as defined in [PWE3-ETHERNET]. A 500 customer Ethernet packet is defined as follows: 502 - If the packet, as it arrives at the PE, has an encapsulation 503 that is used by the local PE as a service delimiter, i.e., to 504 identify the customer and/or the particular service of that 505 customer, then that encapsulation is stripped before the packet 506 is sent into the VPLS. As the packet exits the VPLS, the 507 packet may have a service-delimiting encapsulation inserted. 509 - If the packet, as it arrives at the PE, has an encapsulation 510 that is not service delimiting, then it is a customer packet 511 whose encapsulation should not be modified by the VPLS. This 512 covers, for example, a packet that carries customer specific 513 VLAN-Ids that the service provider neither knows about nor 514 wants to modify. 516 As an application of these rules, a customer packets may arrive at a 517 customer-facing port with a VLAN tag that identifies the customer's 518 VPLS instance. That tag would be stripped before it is encapsulated 519 in the VPLS. At egress, the packet may be tagged again, if a 520 service-delimiting tag is used, or it may be untagged if none is 521 used. 523 Likewise, if a customer packet arrives at a customer-facing port 524 over an ATM VC that identifies the customer's VPLS instance, then 525 the ATM encapsulation is removed before the packet is passed into 526 the VPLS. 528 Contrariwise, if a customer packet arrives at a customer-facing port 529 with a VLAN tag that identifies a VLAN domain in the customer L2 530 network, then the tag is not modified or stripped, as it belongs 531 with the rest of the customer frame. 533 By following the above rules, the Ethernet packet that traverses a 534 VPLS is always a customer Ethernet packet. Note that the two 535 actions, at ingress and egress, of dealing with service delimiters 536 are local actions that neither PE has to signal to the other. They 537 allow, for example, a mix-and-match of VLAN tagged and untagged 538 services at either end, and do not carry across a VPLS a VLAN tag 539 that has local significance only. The service delimiter may be an 540 MPLS label also, whereby an Ethernet pseudowire given by [PWE3- 541 ETHERNET] can serve as the access side connection into a PE. An 542 RFC1483 PVC encapsulation could be another service delimiter. By 543 limiting the scope of locally significant encapsulations to the 544 edge, hierarchical VPLS models can be developed that provide the 545 capability to network-engineer VPLS deployments, as described below. 547 8.1.1. VPLS Learning actions 549 Learning is done based on the customer Ethernet packet, as defined 550 above. The Forwarding Information Base (FIB) keeps track of the 551 mapping of customer Ethernet packet addressing and the appropriate 552 pseudowire to use. We define two modes of learning: qualified and 553 unqualified learning. 555 In unqualified learning, all the customer VLANs are handled by a 556 single VPLS, which means they all share a single broadcast domain 557 and a single MAC address space. This means that MAC addresses need 558 to be unique and non-overlapping among customer VLANs or else they 559 cannot be differentiated within the VPLS instance and this can 560 result in loss of customer frames. An application of unqualified 561 learning is port-based VPLS service for a given customer (e.g., 562 customer with non-multiplexed UNI interface where all the traffic on 563 a physical port, which may include multiple customer VLANs, is 564 mapped to a single VPLS instance). 566 In qualified learning, each customer VLAN is assigned to its own 567 VPLS instance, which means each customer VLAN has its own broadcast 568 domain and MAC address space. Therefore, in qualified learning, MAC 569 addresses among customer VLANs may overlap with each other, but they 570 will be handled correctly since each customer VLAN has its own FIB, 571 i.e., each customer VLAN has its own MAC address space. Since VPLS 572 broadcasts multicast frames by default, qualified learning offers 573 the advantage of limiting the broadcast scope to a given customer 574 VLAN. 576 For STP to work in qualified mode, a VPLS PE must be able to forward 577 STP BPDUs over the proper VPLS instance. In a hierarchical VPLS case 578 (see details in Section 10), service delimiting tags (Q-in-Q or 579 Martini) can be added by MTU-s nodes such that PEs can unambiguously 580 identify all customer traffic, including STP/MSTP BPDUs. In a basic 581 VPLS case, upstream switches must insert such service delimiting 582 tags. When an access port is shared among multiple customers, a 583 reserved VLAN per customer domain must be used to carry STP/MSTP 584 traffic. The STP/MSTP frames are encapsulated with a unique provider 585 tag per customer (as the regular customer traffic), and a PEs looks 586 up the provider tag to send such frames across the proper VPLS 587 instance. 589 9. Operation of a VPLS 591 We show here an example of how a VPLS works. The following 592 discussion uses the figure below, where a VPLS has been set up 593 between PE1, PE2 and PE3. 595 Initially, the VPLS is set up so that PE1, PE2 and PE3 have a full- 596 mesh of Ethernet pseudowires. The VPLS instance is assigned a 597 unique VCID. 599 For the above example, say PE1 signals VC Label 102 to PE2 and 103 600 to PE3, and PE2 signals VC Label 201 to PE1 and 203 to PE3. 602 Assume a packet from A1 is bound for A2. When it leaves CE1, say it 603 has a source MAC address of M1 and a destination MAC of M2. If PE1 604 does not know where M2 is, it will multicast the packet to PE2 and 605 PE3. When PE2 receives the packet, it will have an inner label of 606 201. PE2 can conclude that the source MAC address M1 is behind PE1, 607 since it distributed the label 201 to PE1. It can therefore 608 associate MAC address M1 with VC Label 102. 610 ----- 611 / A1 \ 612 ---- ----CE1 | 613 / \ -------- ------- / | | 614 | A2 CE2- / \ / PE1 \ / 615 \ / \ / \---/ \ ----- 616 ---- ---PE2 | 617 | Service Provider Network | 618 \ / \ / 619 ----- PE3 / \ / 620 |Agg|_/ -------- ------- 621 -| | 622 ---- / ----- ---- 623 / \/ \ / \ CE = Customer Edge Router 624 | A3 CE3 --C4 A4 | PE = Provider Edge Router 625 \ / \ / Agg = Layer 2 Aggregation 626 ---- ---- 628 9.1. MAC Address Aging 630 PEs that learn remote MAC addresses need to have an aging mechanism 631 to remove unused entries associated with a VC Label. This is 632 important both for conservation of memory as well as for 633 administrative purposes. For example, if a customer site A is shut 634 down, eventually, the other PEs should unlearn A's MAC address. 636 As packets arrive, MAC addresses are remembered. The aging timer 637 for MAC address M SHOULD be reset when a packet is received with 638 source MAC address M. 640 10. A Hierarchical VPLS Model 642 The solution described above requires a full mesh of tunnel LSPs 643 between all the PE routers that participate in the VPLS service. 644 For each VPLS service, n*(n-1)/2 pseudowires must be setup between 645 the PE routers. While this creates signaling overhead, the real 646 detriment to large scale deployment is the packet replication 647 requirements for each provisioned VCs on a PE router. Hierarchical 648 connectivity, described in this document reduces signaling and 649 replication overhead to allow large scale deployment. 651 In many cases, service providers place smaller edge devices in 652 multi-tenant buildings and aggregate them into a PE device in a 653 large Central Office (CO) facility. In some instances, standard IEEE 654 802.1q (Dot 1Q) tagging techniques may be used to facilitate mapping 655 CE interfaces to PE VPLS access points. 657 It is often beneficial to extend the VPLS service tunneling 658 techniques into the MTU (multi-tenant unit) domain. This can be 659 accomplished by treating the MTU device as a PE device and 660 provisioning pseudowires between it and every other edge, as an 661 basic VPLS. An alternative is to utilize [PWE3-ETHERNET] 662 pseudowires or Q-in-Q logical interfaces between the MTU and 663 selected VPLS enabled PE routers. Q-in-Q encapsulation is another 664 form of L2 tunneling technique, which can be used in conjunction 665 with MPLS signaling as will be described later. The following two 666 sections focus on this alternative approach. The VPLS core 667 pseudowires (Hub) are augmented with access pseudowires (Spoke) to 668 form a two tier hierarchical VPLS (H-VPLS). 670 Spoke pseudowires may be implemented using any L2 tunneling 671 mechanism, expanding the scope of the first tier to include non- 672 bridging VPLS PE routers. The non-bridging PE router would extend a 673 Spoke pseudowire from a Layer-2 switch that connects to it, through 674 the service core network, to a bridging VPLS PE router supporting 675 Hub pseudowires. We also describe how VPLS-challenged nodes and 676 low-end CEs without MPLS capabilities may participate in a 677 hierarchical VPLS. 679 10.1. Hierarchical connectivity 681 This section describes the hub and spoke connectivity model and 682 describes the requirements of the bridging capable and non-bridging 683 MTU devices for supporting the spoke connections. 685 For rest of this discussion we will refer to a bridging capable MTU 686 device as MTU-s and a non-bridging capable PE device as PE-r. A 687 routing and bridging capable device will be referred to as PE-rs. 689 10.1.1. Spoke connectivity for bridging-capable devices 691 As shown in the figure below, consider the case where an MTU-s 692 device has a single connection to the PE-rs device placed in the CO. 693 The PE-rs devices are connected in a basic VPLS full mesh. For each 694 VPLS service, a single spoke pseudowire is set up between the MTU-s 695 and the PE-rs based on [PWE3-CTRL]. Unlike traditional pseudowires 696 that terminate on a physical (or a VLAN-tagged logical) port at each 697 end, the spoke pseudowire terminates on a virtual bridge instance on 698 the MTU-s and the PE-rs devices. 699 PE2-rs 700 ------ 701 / \ 702 | -- | 703 | / \ | 704 CE-1 | \B / | 705 \ \ -- / 706 \ /------ 707 \ MTU-s PE1-rs / | 708 \ ------ ------ / | 709 / \ / \ / | 710 | \ -- | VC-1 | -- |---/ | 711 | / \--|- - - - - - - - - - - |--/ \ | | 712 | \B / | | \B / | | 713 \ /-- / \ -- / ---\ | 714 /----- ------ \ | 715 / \ | 716 ---- \ ------ 717 |Agg | / \ 718 ---- | -- | 719 / \ | / \ | 720 CE-2 CE-3 | \B / | 721 \ -- / 722 MTU-s = Bridging capable MTU ------ 723 PE-rs = VPLS capable PE PE3-rs 725 -- 726 / \ 727 \B / = Virtual VPLS(Bridge)Instance 728 -- 729 Agg = Layer-2 Aggregation 731 The MTU-s device and the PE-rs device treat each spoke connection 732 like an access port of the VPLS service. On access ports, the 733 combination of the physical port and/or the VLAN tag is used to 734 associate the traffic to a VPLS instance while the pseudowire tag 735 (e.g., VC label) is used to associate the traffic from the virtual 736 spoke port with a VPLS instance, followed by a standard L2 lookup to 737 identify which customer port the frame needs to be sent to. 739 10.1.1.1. MTU-s Operation 741 MTU-s device is defined as a device that supports layer-2 switching 742 functionality and does all the normal bridging functions of learning 743 and replication on all its ports, including the virtual spoke port. 744 Packets to unknown destination are replicated to all ports in the 745 service including the virtual spoke port. Once the MAC address is 746 learned, traffic between CE1 and CE2 will be switched locally by the 747 MTU-s device saving the link capacity of the connection to the PE- 748 rs. Similarly traffic between CE1 or CE2 and any remote destination 749 is switched directly on to the spoke connection and sent to the PE- 750 rs over the point-to-point pseudowire. 752 Since the MTU-s is bridging capable, only a single pseudowire is 753 required per VPLS instance for any number of access connections in 754 the same VPLS service. This further reduces the signaling overhead 755 between the MTU-s and PE-rs. 757 If the MTU-s is directly connected to the PE-rs, other encapsulation 758 techniques such as Q-in-Q can be used for the spoke connection 759 pseudowire. However, to maintain a uniform end-to-end control plane 760 based on MPLS signaling, [PWE3-CTRL] can be used for distribution of 761 pseudowire tags (e.g., Q-in-Q tags or pseudowire labels) between 762 MTU-s and PE-rs. 764 10.1.1.2. PE-rs Operation 766 The PE-rs device is a device that supports all the bridging 767 functions for VPLS service and supports the routing and MPLS 768 encapsulation, i.e. it supports all the functions described in 769 [VPLS]. 771 The operation of PE-rs is independent of the type of device at the 772 other end of the spoke pseudowire. Thus, the spoke pseudowire from 773 the PE-r is treated as a virtual port and the PE-rs device will 774 switch traffic between the spoke pseudowire, hub pseudowires, and 775 access ports once it has learned the MAC addresses. 777 10.1.2. Advantages of spoke connectivity 779 Spoke connectivity offers several scaling and operational advantages 780 for creating large scale VPLS implementations, while retaining the 781 ability to offer all the functionality of the VPLS service. 783 - Eliminates the need for a full mesh of tunnels and full mesh of 784 pseudowires per service between all devices participating in the 785 VPLS service. 787 - Minimizes signaling overhead since fewer pseudowires are required 788 for the VPLS service. 789 - Segments VPLS nodal discovery. MTU-s needs to be aware of only 790 the PE-rs node although it is participating in the VPLS service 791 that spans multiple devices. On the other hand, every VPLS PE-rs 792 must be aware of every other VPLS PE-rs device and all of it�s 793 locally connected MTU-s and PE-r. 794 - Addition of other sites requires configuration of the new MTU-s 795 device but does not require any provisioning of the existing MTU-s 796 devices on that service. 797 - Hierarchical connections can be used to create VPLS service that 798 spans multiple service provider domains. This is explained in a 799 later section. 801 10.1.3. Spoke connectivity for non-bridging devices 803 In some cases, a bridging PE-rs device may not be deployed in a CO 804 or a multi-tenant building while a PE-r might already be deployed. 805 If there is a need to provide VPLS service from the CO where the PE- 806 rs device is not available, the service provider may prefer to use 807 the PE-r device in the interim. In this section, we explain how a 808 PE-r device that does not support any of the VPLS bridging 809 functionality can participate in the VPLS service. 811 As shown in this figure, the PE-r device creates a point-to-point 812 tunnel LSP to a PE-rs device. Then for every access port that needs 814 PE2-rs 815 ------ 816 / \ 817 | -- | 818 | / \ | 819 CE-1 | \B / | 820 \ \ -- / 821 \ /------ 822 \ PE-r PE1-rs / | 823 \ ------ ------ / | 824 / \ / \ / | 825 | \ | VC-1 | -- |---/ | 826 | ------|- - - - - - - - - - - |--/ \ | | 827 | -----|- - - - - - - - - - - |--\B / | | 828 \ / / \ -- / ---\ | 829 ------ ------ \ | 830 / \ | 831 ---- \------ 832 | Agg| / \ 833 ---- | -- | 834 / \ | / \ | 835 CE-2 CE-3 | \B / | 836 \ -- / 837 ------ 838 PE3-rs 840 to participate in a VPLS service, the PE-r device creates a point- 841 to-point [PWE3-ETHERNET] pseudowire that terminates on the physical 842 port at the PE-r and terminates on the virtual bridge instance of 843 the VPLS service at the PE-rs. 845 10.1.3.1. PE-r Operation 847 The PE-r device is defined as a device that supports routing but 848 does not support any bridging functions. However, it is capable of 849 setting up [PWE3-ETHERNET] pseudowires between itself and the PE-rs. 850 For every port that is supported in the VPLS service, a [PWE3- 851 ETHERNET] pseudowire is setup from the PE-r to the PE-rs. Once the 852 pseudowires are setup, there is no learning or replication function 853 required on part of the PE-r. All traffic received on any of the 854 access ports is transmitted on the pseudowire. Similarly all 855 traffic received on a pseudowire is transmitted to the access port 856 where the pseudowire terminates. Thus traffic from CE1 destined for 857 CE2 is switched at PE-rs and not at PE-r. 859 This approach adds more overhead than the bridging capable (MTU-s) 860 spoke approach since a pseudowire is required for every access port 861 that participates in the service versus a single pseudowire required 862 per service (regardless of access ports) when a MTU-s type device is 863 used. However, this approach offers the advantage of offering a 864 VPLS service in conjunction with a routed internet service without 865 requiring the addition of new MTU device. 867 10.2. Redundant Spoke Connections 869 An obvious weakness of the hub and spoke approach described thus far 870 is that the MTU device has a single connection to the PE-rs device. 871 In case of failure of the connection or the PE-rs device, the MTU 872 device suffers total loss of connectivity. 874 In this section we describe how the redundant connections can be 875 provided to avoid total loss of connectivity from the MTU device. 876 The mechanism described is identical for both, MTU-s and PE-r type 877 of devices 879 10.2.1. Dual-homed MTU device 881 To protect from connection failure of the pseudowire or the failure 882 of the PE-rs device, the MTU-s device or the PE-r is dual-homed into 883 two PE-rs devices, as shown in figure-3. The PE-rs devices must be 884 part of the same VPLS service instance. 886 An MTU-s device will setup two [PWE3-ETHERNET] pseudowires (one each 887 to PE-rs1 and PE-rs2) for each VPLS instance. One of the two 888 pseudowires is designated as primary and is the one that is actively 889 used under normal conditions, while the second pseudowire is 890 designated as secondary and is held in a standby state. The MTU 891 device negotiates the pseudowire labels for both the primary and 892 secondary pseudowires, but does not use the secondary pseudowire 893 unless the primary pseudowire fails. Since only one link is active 894 at a given time, a loop does not exist and hence 802.1D spanning 895 tree is not required. 897 PE2-rs 898 ------ 899 / \ 900 | -- | 901 | / \ | 902 CE-1 | \B / | 903 \ \ -- / 904 \ /------ 905 \ MTU-s PE1-rs / | 906 \------ ------ / | 907 / \ / \ / | 908 | -- | Primary PW | -- |---/ | 909 | / \--|- - - - - - - - - - - |--/ \ | | 910 | \B / | | \B / | | 911 \ -- \/ \ -- / ---\ | 912 ------\ ------ \ | 913 / \ \ | 914 / \ \ ------ 915 / \ / \ 916 CE-2 \ | -- | 917 \ Secondary PW | / \ | 918 - - - - - - - - - - - - - - - - - |-\B / | 919 \ -- / 920 ------ 921 PE3-rs 923 10.2.2. Failure detection and recovery 925 The MTU-s device controls the usage of the pseudowires to the PE-rs 926 nodes. Since LDP signaling is used to negotiate the pseudowire 927 labels, the hello messages used for the LDP session can be used to 928 detect failure of the primary pseudowire. 930 Upon failure of the primary pseudowire, MTU-s device immediately 931 switches to the secondary pseudowire. At this point the PE3-rs 932 device that terminates the secondary pseudowire starts learning MAC 933 addresses on the spoke pseudowire. All other PE-rs nodes in the 934 network think that CE-1 and CE-2 are behind PE1-rs and may continue 935 to send traffic to PE1-rs until they learn that the devices are now 936 behind PE3-rs. The relearning process can take a long time and may 937 adversely affect the connectivity of higher level protocols from CE1 938 and CE2. To enable faster convergence, the PE3-rs device where the 939 secondary pseudowire got activated may send out a flush message, 940 using the MAC TLV as defined in Section 6, to all PE-rs nodes. Upon 941 receiving the message, PE-rs nodes flush the MAC addresses 942 associated with that VPLS instance. 944 10.3. Multi-domain VPLS service 946 Hierarchy can also be used to create a large scale VPLS service 947 within a single domain or a service that spans multiple domains 948 without requiring full mesh connectivity between all VPLS capable 949 devices. Two fully meshed VPLS networks are connected together 950 using a single LSP tunnel between the VPLS gateway devices. A 951 single spoke pseudowire is setup per VPLS service to connect the two 952 domains together. The VPLS gateway device joins two VPLS services 953 together to form a single multi-domain VPLS service. The 954 requirements and functionality required from a VPLS gateway device 955 will be explained in a future version of this document. 957 11. Hierarchical VPLS model using Ethernet Access Network 959 In the previous section, a two-tier hierarchical model that consists 960 of hub-and-spoke topology between MTU-s devices and PE-rs devices and 961 a full-mesh topology among PE-rs devices was discussed. In this 962 section the two-tier hierarchical model is expanded to include an 963 Ethernet access network. This model retains the hierarchical 964 architecture discussed previously in that it leverages the full-mesh 965 topology among PE-rs devices; however, no restriction is imposed on 966 the topology of the Ethernet access network (e.g., the topology 967 between MTU-s and PE-rs devices are not restricted to hub and spoke). 969 The motivation for an Ethernet access network is that Ethernet-based 970 networks are currently deployed by some service providers to offer 971 VPLS services to their customers. Therefore, it is important to 972 provide a mechanism that allows these networks to integrate with an 973 IP or MPLS core to provide scalable VPLS services. 975 One approach of tunneling a customer's Ethernet traffic via an 976 Ethernet access network is to add an additional VLAN tag to the 977 customer's data (which may be either tagged or untagged). The 978 additional tag is referred to as Provider's VLAN (P-VLAN). Inside the 979 provider's network each P-VLAN designates a customer or more 980 specifically a VPLS instance for that customer. Therefore, there is a 981 one to one correspondence between a P-VLAN and a VPLS instance. 983 In this model, the MTU-S device needs to have the capability of 984 adding the additional P-VLAN tag for non-multiplexed customer UNI 985 port where customer VLANs are not used as service delimiter. If 986 customer VLANs need to be treated as service delimiter (e.g., 987 customer UNI port is a multiplexed port), then the MTU-s needs to 988 have the additional capability of translating a customer VLAN (C- 989 VLAN) to a P-VLAN in order to resolve overlapping VLAN-ids used by 990 different customers. Therefore, the MTU-s device in this model can be 991 considered as a typical bridge with this additional UNI capability. 993 The PE-rs device needs to be able to perform bridging functionality 994 over the standard Ethernet ports toward the access network as well as 995 over the pseudowires toward the network core. The set of pseudowires 996 that corresponds to a VPLS instance would look just like a P-VLAN to 997 the bridge portion of the PE-rs and that is why sometimes it is 998 referred to as Emulated VLAN. In this model the PE-rs may need to run 999 STP protocol in addition to split-horizon. Split horizon is run over 1000 MPLS-core; whereas, STP is run over the access network to accommodate 1001 any arbitrary access topology. In this model, the PE-rs needs to map 1002 a P-VLAN to a VPLS-instance and its associated pseudowires and vise 1003 versa. 1005 The details regarding bridge operation for MTU-s and PE-rs (e.g., 1006 encapsulation format for QinQ messages, customer�s Ethernet control 1007 protocol handling, etc.) are outside of the scope of this document 1008 and they are covered in [802.1ad]. However, the relevant part is the 1009 interaction between the bridge module and the MPLS/IP pseudowires in 1010 the PE-rs device. 1012 11.1. Scalability 1014 Given that each P-VLAN corresponds to a VPLS instance, one may think 1015 that the total number of VPLS instances supported is limited to 4K. 1016 However, the 4K limit applies only to each Ethernet access network 1017 (Ethernet island) and not to the entire network. The SP network, in 1018 this model, consists of a core MPLS/IP network that connects many 1019 Ethernet islands. Therefore, the number of VPLS instances can scale 1020 accordingly with the number of Ethernet islands (a metro region can 1021 be represented by one or more islands). Each island may consist of 1022 many MTU-s devices, several aggregators, and one or more PE-rs 1023 devices. The PE-rs devices enable a P-VLAN to be extended from one 1024 island to others using a set of pseudowires (associated with that 1025 VPLS instance) and providing a loop free mechanism across the core 1026 network through split-horizon. Since a P-VLAN serves as a service 1027 delimiter within the provider's network, it does not get carried over 1028 the pseudowires and furthermore the mapping between P-VLAN and the 1029 pseudowires is a local matter. This means a VPLS instance can be 1030 represented by different P-VLAN in different Ethernet islands and 1031 furthermore each island can support 4K VPLS instances independent 1032 from one another. 1034 11.2. Dual Homing and Failure Recovery 1036 In this model, an MTU-s can be dual or triple homed to different 1037 devices (aggregators and/or PE-rs devices). The failure protection 1038 for access network nodes and links can be provided through running 1039 MSTP in each island. The MSTP of each island is independent from 1040 other islands and do not interact with each other. If an island has 1041 more than one PE-rs, then a dedicated full-mesh of pseudowires is 1042 used among these PE-rs devices for carrying the SP BPDU packets for 1043 that island. On a per P-VLAN basis, the MSTP will designate a single 1044 PE-rs to be used for carrying the traffic across the core. The loop- 1045 free protection through the core is performed using split-horizon and 1046 the failure protection in the core is performed through standard 1047 IP/MPLS re-routing. 1049 12. Significant Modifications 1051 Between rev 00 and this one, these are the changes: 1053 o minor revisions of text 1054 o briefly explains qualified learning and STP interaction 1056 13. Acknowledgments 1058 We wish to thank Joe Regan, Kireeti Kompella, Anoop Ghanwani, Joel 1059 Halpern, Rick Wilder, Jim Guichard, Steve Phillips, Norm Finn, Matt 1060 Squire, Muneyoshi Suzuki, Waldemar Augustyn, and Eric Rosen for 1061 their valuable feedback. In addition, we would like to thank Rajiv 1062 Papneja (ISOCORE), Winston Liu (ISOCORE), and Charlie Hundall 1063 (Extreme) for identifying issues with the draft in the course of the 1064 interoperability tests. 1066 14. Security Considerations 1068 Security issues resulting from this draft will be discussed in 1069 greater depth at a later point. It is recommended in [RFC3036] that 1070 LDP security (authentication) methods be applied. This would 1071 prevent unauthorized participation by a PE in a VPLS. Traffic 1072 separation for a VPLS is effected by using VC labels. However, for 1073 additional levels of security, the customer MAY deploy end-to-end 1074 security, which is out of the scope of this draft. In addition, the 1075 L2FRAME] document describes security issues in greater depth. 1077 15. Intellectual Property Considerations 1079 This document is being submitted for use in IETF standards 1080 discussions. 1082 16. Full Copyright Statement 1084 Copyright (C) The Internet Society (2001). All Rights Reserved. 1085 This document and translations of it may be copied and furnished to 1086 others, and derivative works that comment on or otherwise explain it 1087 or assist in its implementation may be prepared, copied, published 1088 and distributed, in whole or in part, without restriction of any 1089 kind, provided that the above copyright notice and this paragraph 1090 are included on all such copies and derivative works. However, this 1091 document itself may not be modified in any way, such as by removing 1092 the copyright notice or references to the Internet Society or other 1093 Internet organizations, except as needed for the purpose of 1094 developing Internet standards in which case the procedures for 1095 copyrights defined in the Internet Standards process must be 1096 followed, or as required to translate it into languages other than 1097 English. 1099 The limited permissions granted above are perpetual and will not be 1100 revoked by the Internet Society or its successors or assigns. 1102 This document and the information contained herein is provided on an 1103 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1104 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1105 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1106 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1107 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1109 17. References 1111 [PWE3-ETHERNET] "Encapsulation Methods for Transport of Ethernet 1112 Frames Over IP/MPLS Networks", draft-ietf-pwe3-ethernet-encap- 1113 02.txt, Work in progress, February 2003. 1115 [PWE3-CTRL] "Transport of Layer 2 Frames Over MPLS", draft-ietf- 1116 pwe3-control-protocol-02.txt, Work in progress, February 2003. 1118 [802.1D-ORIG] Original 802.1D - ISO/IEC 10038, ANSI/IEEE Std 802.1D- 1119 1993 "MAC Bridges". 1121 [802.1D-REV] 802.1D - "Information technology - Telecommunications 1122 and information exchange between systems - Local and metropolitan 1123 area networks - Common specifications - Part 3: Media Access Control 1124 (MAC) Bridges: Revision. This is a revision of ISO/IEC 10038: 1993, 1125 802.1j-1992 and 802.6k-1992. It incorporates P802.11c, P802.1p and 1126 P802.12e." ISO/IEC 15802-3: 1998. 1128 [802.1Q] 802.1Q - ANSI/IEEE Draft Standard P802.1Q/D11, "IEEE 1129 Standards for Local and Metropolitan Area Networks: Virtual Bridged 1130 Local Area Networks", July 1998. 1132 [BGP-VPN] Rosen and Rekhter, "BGP/MPLS VPNs". draft-ietf-ppvpn- 1133 rfc2547bis-04.txt, Work in Progress, May 2003. 1135 [RFC3036] "LDP Specification", L. Andersson, et al. RFC 3036. 1136 January 2001. 1138 [RADIUS-DISC] " Using Radius for PE-Based VPN Discovery", Juha 1139 Heinanen, draft-heinanen-radius-pe-discovery-04.txt, Work in 1140 Progress, June 2003. 1142 [BGP-DISC] "Using BGP as an Auto-Discovery Mechanism for Network- 1143 based VPNs", Ould-Brahim, et. al., draft-ietf-ppvpn-bgpvpn-auto- 1144 05.txt, Work in Progress, May 2003. 1146 [LDP-DISC] "Discovering Nodes and Services in a VPLS Network", O. 1147 Stokes et al, draft-stokes-ppvpn-vpls-discover-00.txt, Work in 1148 Progress, June 2002. 1150 [VPLS-BRIDGING] "Bridging and VPLS", draft-finn-ppvpn-bridging-vpls- 1151 00.txt, Work in Progress, June 2002. 1153 [L2VPN-SIG] "LDP-based Signaling for L2VPNs", draft-rosen-ppvpn-l2- 1154 signaling-03.txt, Work in Progress, May 2003. 1156 [L2FRAME] "L2VPN Framework", draft-ietf-ppvpn-l2-framework-03, Work 1157 in Progress, February 2003. 1159 [L2VPN-REQ] "Service Requirements for Layer 2 Provider Provisioned 1160 Virtual Private Networks", draft-ietf-ppvpn-l2vpn-requirements- 1161 00.txt, Work in Progress, May 2003. 1163 [802.1ad] "IEEE standard for Provider Bridges", Work in Progress, 1164 December 2002. 1166 18. Authors' Addresses 1168 Marc Lasserre 1169 Riverstone Networks 1170 Email: marc@riverstonenet.com 1172 Vach Kompella 1173 TiMetra Networks 1174 274 Ferguson Dr. 1175 Mountain View, CA 94043 1176 Email: vkompella@timetra.com 1178 Sunil Khandekar 1179 TiMetra Networks 1180 274 Ferguson Dr. 1181 Mountain View, CA 94043 1182 Email: sunil@timetra.com 1183 Nick Tingle 1184 TiMetra Networks 1185 274 Ferguson Dr. 1186 Mountain View, CA 94043 1187 Email: nick@timetra.com 1189 Ali Sajassi 1190 Cisco Systems, Inc. 1191 170 West Tasman Drive 1192 San Jose, CA 95134 1193 Email: sajassi@cisco.com 1195 Loa Andersson 1196 Email: loa@pi.se 1198 Pascal Menezes 1199 Email: pascalm1@yahoo.com 1201 Andrew Smith 1202 Email: ah_smith@pacbell.net 1204 Giles Heron 1205 PacketExchange Ltd. 1206 Email: giles@packetexchange.net 1208 Juha Heinanen 1209 TutPro 1210 Email: jh@tutpro.com 1212 Tom S. C. Soon 1213 SBC Technology Resources Inc. 1214 Email: sxsoon@tri.sbc.com 1216 Yetik Serbest 1217 SBC Communications 1218 serbest@tri.sbc.com 1220 Eric Puetz 1221 SBC Communications 1222 puetz@tri.sbc.com 1224 Ron Haberman 1225 Masergy Inc. 1226 Email: ronh@masergy.com 1228 Luca Martini 1229 Level 3 Communications, LLC. 1230 Email: luca@level3.net 1232 Rob Nath 1233 Riverstone Networks 1234 Email: rnath@riverstonenet.com