idnits 2.17.1 draft-ietf-l2vpn-vpls-ldp-05.txt: 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: ---------------------------------------------------------------------------- ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard 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: ' 13. 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 159: '...rd a frame, a PE MUST be able to assoc...' RFC 2119 keyword, line 163: '... capable PEs SHOULD have the capabil...' RFC 2119 keyword, line 213: '... Each PE MUST create a rooted tree t...' RFC 2119 keyword, line 214: '...e VPLS. Each PE MUST support a "split...' RFC 2119 keyword, line 215: '...s, that is, a PE MUST NOT forward traf...' (14 more instances...) 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 (September 2004) is 7163 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'PWE3-CTRL' on line 1187 looks like a reference -- Missing reference section? 'PWE3-ETHERNET' on line 1101 looks like a reference -- Missing reference section? 'L2VPN-REQ' on line 1144 looks like a reference -- Missing reference section? 'MPLS-GRE' on line 98 looks like a reference -- Missing reference section? 'BGP-VPN' on line 1127 looks like a reference -- Missing reference section? 'RADIUS-DISC' on line 1130 looks like a reference -- Missing reference section? 'BGP-DISC' on line 1133 looks like a reference -- Missing reference section? 'LDP-DISC' on line 1137 looks like a reference -- Missing reference section? 'RFC3036' on line 1122 looks like a reference -- Missing reference section? 'VPN-SEC' on line 1148 looks like a reference -- Missing reference section? 'RFC-3036' on line 1044 looks like a reference -- Missing reference section? 'L2FRAME' on line 1141 looks like a reference Summary: 8 errors (**), 0 flaws (~~), 2 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Document Marc Lasserre 2 Provider Provisioned VPN Working Group Vach Kompella 3 draft-ietf-l2vpn-vpls-ldp-05.txt (Editors) 4 Expires: February 2005 September 2004 6 Virtual Private LAN Services over MPLS 7 draft-ietf-l2vpn-vpls-ldp-05.txt 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance 12 with all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other documents 21 at any time. It is inappropriate to use Internet-Drafts as 22 reference material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Abstract 31 This document describes a virtual private LAN service (VPLS) 32 solution using pseudo-wires, a service previously implemented over 33 other tunneling technologies and known as Transparent LAN Services 34 (TLS). A VPLS creates an emulated LAN segment for a given set of 35 users. It delivers a layer 2 broadcast domain that is fully capable 36 of learning and forwarding on Ethernet MAC addresses that is closed 37 to a given set of users. Multiple VPLS services can be supported 38 from a single PE node. 40 This document describes the control plane functions of signaling 41 demultiplexor labels, extending [PWE3-CTRL]. It is agnostic to 42 discovery protocols. The data plane functions of forwarding are 43 also described, focusing, in particular, on the learning of MAC 44 addresses. The encapsulation of VPLS packets is described by [PWE3- 45 ETHERNET]. 47 Conventions 49 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 50 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 51 document are to be interpreted as described in RFC 2119 53 RELATED DOCUMENTS 55 www.ietf.org/internet-drafts/draft-ietf-l2vpn-requirements-01.txt 56 www.ietf.org/internet-drafts/draft-ietf-l2vpn-l2-framework-03.txt 57 www.ietf.org/internet-drafts/draft-ietf-pwe3-ethernet-encap-02.txt 58 www.ietf.org/internet-drafts/draft-ietf-pwe3-control-protocol-01.txt 60 1. Introduction 62 Ethernet has become the predominant technology for Local Area 63 Networks (LANs) connectivity and is gaining acceptance as an access 64 technology, specifically in Metropolitan and Wide Area Networks (MAN 65 and WAN respectively). The primary motivation behind Virtual 66 Private LAN Services (VPLS) is to provide connectivity between 67 geographically dispersed customer sites across MAN/WAN network(s), as 68 if they were connected using a LAN. The intended application for the 69 end-user can be divided into the following two categories: 71 - Connectivity between customer routers: LAN routing application 72 - Connectivity between customer Ethernet switches: LAN switching 73 application 75 Broadcast and multicast services are available over traditional 76 LANs. Sites that belong to the same broadcast domain and that are 77 connected via an MPLS network expect broadcast, multicast and 78 unicast traffic to be forwarded to the proper location(s). This 79 requires MAC address learning/aging on a per LSP basis, packet 80 replication across LSPs for multicast/broadcast traffic and for 81 flooding of unknown unicast destination traffic. 83 [PWE3-ETHERNET] defines how to carry L2 PDUs over point-to-point 84 MPLS LSPs, called pseudowires (PW). Such PWs can be carried over 85 MPLS or GRE tunnels. This document describes extensions to [PWE3- 86 CTRL] for transporting Ethernet/802.3 and VLAN [802.1Q] traffic 87 across multiple sites that belong to the same L2 broadcast domain or 88 VPLS. Note that the same model can be applied to other 802.1 89 technologies. It describes a simple and scalable way to offer 90 Virtual LAN services, including the appropriate flooding of 91 broadcast, multicast and unknown unicast destination traffic over 92 MPLS, without the need for address resolution servers or other 93 external servers, as discussed in [L2VPN-REQ]. 95 The following discussion applies to devices that are VPLS capable 96 and have a means of tunneling labeled packets amongst each other. 97 While MPLS LSPs may be used to tunnel these labeled packets, other 98 technologies may be used as well, e.g., GRE [MPLS-GRE]. The 99 resulting set of interconnected devices forms a private MPLS VPN. 101 2. Topological Model for VPLS 103 An interface participating in a VPLS must be able to flood, forward, 104 and filter Ethernet frames. 106 +----+ +----+ 107 + C1 +---+ ........................... +---| C1 | 108 +----+ | . . | +----+ 109 Site A | +----+ +----+ | Site B 110 +---| PE |------ Cloud -------| PE |---+ 111 +----+ | +----+ 112 . | . 113 . +----+ . 114 ..........| PE |........... 115 +----+ ^ 116 | | 117 | +-- Emulated LAN 118 +----+ 119 | C1 | 120 +----+ 121 Site C 123 The set of PE devices interconnected via pseudowires appears as a 124 single emulated LAN to customer C1. Each PE device will learn remote 125 MAC address to pseudowire associations and will also learn directly 126 attached MAC addresses on customer facing ports. 128 We note here again that while this document shows specific examples 129 using MPLS transport tunnels, other tunnels that can be used by 130 pseudo-wires, e.g., GRE, L2TP, IPSEC, etc., can also be used, as 131 long as the originating PE can be identified, since this is used in 132 the MAC learning process. 134 The scope of the VPLS lies within the PEs in the service provider 135 network, highlighting the fact that apart from customer service 136 delineation, the form of access to a customer site is not relevant 137 to the VPLS [L2VPN-REQ]. 139 The PE device is typically an edge router capable of running the LDP 140 signaling protocol and/or routing protocols to set up pseudowires. 141 In addition, it is capable of setting up transport tunnels to other 142 PEs and deliver traffic over a pseudowire. 144 2.1. Flooding and Forwarding 146 One of attributes of an Ethernet service is that packets to 147 broadcast packets and to unknown destination MAC addresses are 148 flooded to all ports. To achieve flooding within the service 149 provider network, all address unknown unicast, broadcast and 150 multicast frames are flooded over the corresponding pseudowires to 151 all relevant PE nodes participating in the VPLS. 153 Note that multicast frames are a special case and do not necessarily 154 have to be sent to all VPN members. For simplicity, the default 155 approach of broadcasting multicast frames can be used. The use of 156 IGMP snooping and PIM snooping techniques should be used to improve 157 multicast efficiency. 159 To forward a frame, a PE MUST be able to associate a destination MAC 160 address with a pseudowire. It is unreasonable and perhaps impossible 161 to require PEs to statically configure an association of every 162 possible destination MAC address with a pseudowire. Therefore, VPLS- 163 capable PEs SHOULD have the capability to dynamically learn MAC 164 addresses on both physical ports and virtual circuits and to forward 165 and replicate packets across both physical ports and pseudowires. 167 2.2. Address Learning 169 Unlike BGP VPNs [BGP-VPN], reachability information does not need to 170 be advertised and distributed via a control plane. Reachability is 171 obtained by standard learning bridge functions in the data plane. 173 A pseudowire consists of a pair of uni-directional VC LSPs. The 174 state of this pseudowire is considered operationally up when both 175 incoming and outgoing VC LSPs are established. Similarly, it is 176 considered operationally down when one of these two VC LSPs is torn 177 down. When a previously unknown MAC address is learned on an 178 inbound VC LSP, it needs to be associated with the its counterpart 179 outbound VC LSP in that pseudowire. 181 Standard learning, filtering and forwarding actions, as defined in 182 [802.1D-ORIG], [802.1D-REV] and [802.1Q], are required when a 183 logical link state changes. 185 2.3. Tunnel Topology 187 PE routers are assumed to have the capability to establish transport 188 tunnels. Tunnels are set up between PEs to aggregate traffic. 189 Pseudowires are signaled to demultiplex the L2 encapsulated packets 190 that traverse the tunnels. 192 In an Ethernet L2VPN, it becomes the responsibility of the service 193 provider to create the loop free topology. For the sake of 194 simplicity, we define that the topology of a VPLS is a full mesh of 195 tunnels and pseudowires. 197 2.4. Loop free L2 VPN 199 For simplicity, a full mesh of pseudowires is established between 200 PEs. Ethernet bridges, unlike Frame Relay or ATM where the 201 termination point becomes the CE node, have to examine the layer 2 202 fields of the packets to make a switching decision. If the frame is 203 directed to an unknown destination, or is a broadcast or multicast 204 frame, the frame must be flooded. 206 Therefore, if the topology isn't a full mesh, the PE devices may 207 need to forward these frames to other PEs. However, this would 208 require the use of spanning tree protocol to form a loop free 209 topology that may have characteristics that are undesirable to the 210 provider. The use of a full mesh and split-horizon forwarding 211 obviates the need for a spanning tree protocol. 213 Each PE MUST create a rooted tree to every other PE router that 214 serves the same VPLS. Each PE MUST support a "split-horizon" scheme 215 in order to prevent loops, that is, a PE MUST NOT forward traffic 216 from one pseudowire to another in the same VPLS mesh (since each PE 217 has direct connectivity to all other PEs in the same VPLS). 219 Note that customers are allowed to run STP such as when a customer 220 has "back door" links used to provide redundancy in the case of a 221 failure within the VPLS. In such a case, STP BPDUs are simply 222 tunneled through the provider cloud. 224 3. Discovery 226 The capability to manually configure the addresses of the remote PEs 227 is REQUIRED. However, the use of manual configuration is not 228 necessary if an auto-discovery procedure is used. A number of 229 auto-discovery procedures are compatible with this document 230 ([RADIUS-DISC], [BGP-DISC], [LDP-DISC]). 232 4. Control Plane 234 This document describes the control plane functions of Demultiplexor 235 Exchange (signaling of VC labels). Some foundational work in the 236 area of support for multi-homing is laid. The extensions to provide 237 multi-homing support should work independently of the basic VPLS 238 operation, and are not described here. 240 4.1. LDP Based Signaling of Demultiplexors 242 In order to establish a full mesh of pseudowires, all PEs in a VPLS 243 must have a full mesh of LDP sessions. 245 Once an LDP session has been formed between two PEs, all pseudowires 246 are signaled over this session. 248 In [PWE3-CTRL], two types of FECs are described, the FEC type 128 249 PWid FEC Element and the FEC type 129 Generalized PWid FEC Element. 250 The original FEC element used for VPLS was compatible with the PWid 251 FEC Element. The text for signaling using PWid FEC Element has been 252 moved to Appendix 1. What we describe below replaces that with a 253 more generalized L2VPN descriptor through the Generalized PWid FEC 254 Element. 256 4.1.1. Using the Generalized PWid FEC Element 258 [PWE3-CTRL] describes a generalized FEC structure that is be used 259 for VPLS signaling in the following manner. The following describes 260 the assignment of the Generalized PWid FEC Element fields in the 261 context of VPLS signaling. 263 Control bit (C): Depending on whether, on that particular 264 pseudowire, the control word is desired or not, the control bit may 265 be specified. 267 PW type: The allowed PW types in this version are Ethernet and 268 Ethernet VLAN. 270 VC info length: Same as in [PWE3-CTRL]. 272 AGI, Length, Value: The unique name of this VPLS. The AGI 273 identifies a type of name, the length denotes the length of Value, 274 which is the name of the VPLS. We will use the term AGI 275 interchangeably with VPLS identifier. 277 TAII, SAII: These are null because the mesh of PWs in a VPLS 278 terminate on MAC learning tables, rather than on individual 279 attachment circuits. 281 Interface Parameters: The relevant interface parameters are: 282 MTU: the MTU of the VPLS MUST be the same across all the PWs in 283 the mesh. 284 Optional Description String: same as [PWE3-CTRL]. 285 Requested VLAN ID: If the PW type is Ethernet VLAN, this 286 parameter may be used to signal the insertion of the 287 appropriate VLAN ID. 289 4.1.2. Address Withdraw Message Containing MAC TLV 291 When MAC addresses are being removed or relearned explicitly, e.g., 292 the primary link of a dual-homed MTU-s (Multi-Tenant Unit switch) 293 has failed, an MAC Address Withdraw Message with the list of MAC 294 addresses to be relearned can be sent to all other PEs over the 295 corresponding directed LDP sessions. 297 The processing for MAC List TLVs received in an Address Withdraw 298 Message is: 299 For each MAC address in the TLV: 300 - Relearn the association between the MAC address and the 301 interface/pseudowire over which this message is received 303 For a MAC Address Withdraw message with empty list: 304 - Remove all the MAC addresses associated with the VPLS instance 305 (specified by the FEC TLV) except the MAC addresses learned 306 over this link (over the pseudowire associated with the 307 signaling link over which the message is received) 309 The scope of a MAC List TLV is the VPLS specified in the FEC TLV in 310 the MAC Address Withdraw Message. The number of MAC addresses can be 311 deduced from the length field in the TLV. 313 4.2. MAC Address Withdrawal 315 It MAY be desirable to remove or relearn MAC addresses that have 316 been dynamically learned for faster convergence. 318 We introduce an optional MAC List TLV that is used to specify a list 319 of MAC addresses that can be removed or relearned using the LDP 320 Address Withdraw Message. 322 The Address Withdraw message with MAC TLVs MAY be supported in order 323 to expedite removal of MAC addresses as the result of a topology 324 change (e.g., failure of the primary link for a dual-homed MTU-s). 325 If a notification message is sent on the backup link (blocked link), 326 which has transitioned into an active state (e.g., similar to 327 Topology Change Notification message of 802.1w RSTP), with a list of 328 MAC entries to be relearned, the PE will update the MAC entries in 329 its FIB for that VPLS instance and send the message to other PEs 330 over the corresponding directed LDP sessions. 332 If the notification message contains an empty list, this tells the 333 receiving PE to remove all the MAC addresses learned for the 334 specified VPLS instance except the ones it learned from the sending 335 PE (MAC address removal is required for all VPLS instances that are 336 affected). Note that the definition of such a notification message 337 is outside the scope of the document, unless it happens to come from 338 an MTU connected to the PE as a spoke. In such a scenario, the 339 message will be just an Address Withdraw message as noted above. 341 4.2.1. MAC List TLV 343 MAC addresses to be relearned can be signaled using an LDP Address 344 Withdraw Message that contains a new TLV, the MAC List TLV. Its 345 format is described below. The encoding of a MAC List TLV address 346 is the 6-byte MAC address specified by IEEE 802 documents [g-ORIG] 347 [802.1D-REV]. 349 0 1 2 3 350 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 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 |U|F| Type | Length | 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 | MAC address #1 | 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 | MAC address #n | 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 U bit 360 Unknown bit. This bit MUST be set to 1. If the MAC address 361 format is not understood, then the TLV is not understood, and MUST 362 be ignored. 364 F bit 365 Forward bit. This bit MUST be set to 0. Since the LDP 366 mechanism used here is Targeted, the TLV MUST NOT be forwarded. 368 Type 369 Type field. This field MUST be set to 0x0404 (subject to IANA 370 approval). This identifies the TLV type as MAC List TLV. 372 Length 373 Length field. This field specifies the total length of the MAC 374 addresses in the TLV. 376 MAC Address 377 The MAC address(es) being removed. 379 The LDP Address Withdraw Message contains a FEC TLV (to identify the 380 VPLS in consideration), a MAC Address TLV and optional parameters. 381 No optional parameters have been defined for the MAC Address 382 Withdraw signaling. 384 5. Data Forwarding on an Ethernet VC Pseudowire 386 This section describes the dataplane behavior on an Ethernet 387 pseudowire used in a VPLS. While the encapsulation is similar to 388 that described in [PWE3-ETHERNET], the NSP functions of stripping 389 the service-delimiting tag and using a "normalized" Ethernet packet 390 are described. 392 5.1. VPLS Encapsulation actions 394 In a VPLS, a customer Ethernet packet without preamble is 395 encapsulated with a header as defined in [PWE3-ETHERNET]. A 396 customer Ethernet packet is defined as follows: 398 - If the packet, as it arrives at the PE, has an encapsulation 399 that is used by the local PE as a service delimiter, i.e., to 400 identify the customer and/or the particular service of that 401 customer, then that encapsulation is stripped before the packet 402 is sent into the VPLS. As the packet exits the VPLS, the 403 packet may have a service-delimiting encapsulation inserted. 405 - If the packet, as it arrives at the PE, has an encapsulation 406 that is not service delimiting, then it is a customer packet 407 whose encapsulation should not be modified by the VPLS. This 408 covers, for example, a packet that carries customer-specific 409 VLAN-Ids that the service provider neither knows about nor 410 wants to modify. 412 As an application of these rules, a customer packet may arrive at a 413 customer-facing port with a VLAN tag that identifies the customer's 414 VPLS instance. That tag would be stripped before it is encapsulated 415 in the VPLS. At egress, the packet may be tagged again, if a 416 service-delimiting tag is used, or it may be untagged if none is 417 used. 419 Likewise, if a customer packet arrives at a customer-facing port 420 over an ATM VC that identifies the customer's VPLS instance, then 421 the ATM encapsulation is removed before the packet is passed into 422 the VPLS. 424 Contrariwise, if a customer packet arrives at a customer-facing port 425 with a VLAN tag that identifies a VLAN domain in the customer L2 426 network, then the tag is not modified or stripped, as it belongs 427 with the rest of the customer frame. 429 By following the above rules, the Ethernet packet that traverses a 430 VPLS is always a customer Ethernet packet. Note that the two 431 actions, at ingress and egress, of dealing with service delimiters 432 are local actions that neither PE has to signal to the other. They 433 allow, for example, a mix-and-match of VLAN tagged and untagged 434 services at either end, and do not carry across a VPLS a VLAN tag 435 that has local significance only. The service delimiter may be an 436 MPLS label also, whereby an Ethernet pseudowire given by [PWE3- 437 ETHERNET] can serve as the access side connection into a PE. An 438 RFC1483 PVC encapsulation could be another service delimiter. By 439 limiting the scope of locally significant encapsulations to the 440 edge, hierarchical VPLS models can be developed that provide the 441 capability to network-engineer VPLS deployments, as described below. 443 5.2 VPLS Learning actions 445 Learning is done based on the customer Ethernet packet, as defined 446 above. The Forwarding Information Base (FIB) keeps track of the 447 mapping of customer Ethernet packet addressing and the appropriate 448 pseudowire to use. We define two modes of learning: qualified and 449 unqualified learning. 451 In unqualified learning, all the customer VLANs are handled by a 452 single VPLS, which means they all share a single broadcast domain 453 and a single MAC address space. This means that MAC addresses need 454 to be unique and non-overlapping among customer VLANs or else they 455 cannot be differentiated within the VPLS instance and this can 456 result in loss of customer frames. An application of unqualified 457 learning is port-based VPLS service for a given customer (e.g., 458 customer with non-multiplexed UNI interface where all the traffic on 459 a physical port, which may include multiple customer VLANs, is 460 mapped to a single VPLS instance). 462 In qualified learning, each customer VLAN is assigned to its own 463 VPLS instance, which means each customer VLAN has its own broadcast 464 domain and MAC address space. Therefore, in qualified learning, MAC 465 addresses among customer VLANs may overlap with each other, but they 466 will be handled correctly since each customer VLAN has its own FIB, 467 i.e., each customer VLAN has its own MAC address space. Since VPLS 468 broadcasts multicast frames by default, qualified learning offers 469 the advantage of limiting the broadcast scope to a given customer 470 VLAN. 472 For STP to work in qualified mode, a VPLS PE must be able to forward 473 STP BPDUs over the proper VPLS instance. In a hierarchical VPLS case 474 (see details in Section 10), service delimiting tags (Q-in-Q or 475 Martini) can be added by MTU-s nodes such that PEs can unambiguously 476 identify all customer traffic, including STP/MSTP BPDUs. In a basic 477 VPLS case, upstream switches must insert such service delimiting 478 tags. When an access port is shared among multiple customers, a 479 reserved VLAN per customer domain must be used to carry STP/MSTP 480 traffic. The STP/MSTP frames are encapsulated with a unique provider 481 tag per customer (as the regular customer traffic), and a PEs looks 482 up the provider tag to send such frames across the proper VPLS 483 instance. 485 6. Data Forwarding on an Ethernet VLAN Pseudowire 487 This section describes the dataplane behavior on an Ethernet VLAN 488 pseudowire in a VPLS. While the encapsulation is similar to that 489 described in [PWE3-ETHERNET], the NSP functions of imposing tags, 490 and using a "normalized" Ethernet packet are described. The 491 learning behavior is the same as for Ethernet pseudowires. 493 6.1. VPLS Encapsulation actions 495 In a VPLS, a customer Ethernet packet without preamble is 496 encapsulated with a header as defined in [PWE3-ETHERNET]. A 497 customer Ethernet packet is defined as follows: 499 - If the packet, as it arrives at the PE, has an encapsulation 500 that is part of the customer frame, and is also used by the 501 local PE as a service delimiter, i.e., to identify the customer 502 and/or the particular service of that customer, then that 503 encapsulation is preserved as the packet is sent into the VPLS, 504 unless the Requested VLAN ID optional parameter was signaled. 505 In that case, the VLAN tag is overwritten before the packet is 506 sent out on the pseudowire. 508 - If the packet, as it arrives at the PE, has an encapsulation 509 that does not have the required VLAN tag, a null tag is imposed 510 if the Requested VLAN ID optional parameter was not signaled. 512 As an application of these rules, a customer packet may arrive at a 513 customer-facing port with a VLAN tag that identifies the customer's 514 VPLS instance and also identifies a customer VLAN. That tag would 515 be preserved as it is encapsulated in the VPLS. 517 The Ethernet VLAN pseudowire is a simple way to preserve customer 518 802.1p bits. 520 A VPLS MAY have both Ethernet and Ethernet VLAN pseudowires. 521 However, if a PE is not able to support both pseudowires 522 simultaneously, it can send a Label Release on the pseudowire 523 messages that it cannot support with a status code "Unknown FEC" as 524 given in [RFC3036]. 526 7. Operation of a VPLS 528 We show here an example of how a VPLS works. The following 529 discussion uses the figure below, where a VPLS has been set up 530 between PE1, PE2 and PE3. 532 Initially, the VPLS is set up so that PE1, PE2 and PE3 have a full 533 mesh of Ethernet pseudowires. The VPLS instance is assigned a 534 unique VCID. 536 For the above example, say PE1 signals VC Label 102 to PE2 and 103 537 to PE3, and PE2 signals VC Label 201 to PE1 and 203 to PE3. 539 Assume a packet from A1 is bound for A2. When it leaves CE1, say it 540 has a source MAC address of M1 and a destination MAC of M2. If PE1 541 does not know where M2 is, it will multicast the packet to PE2 and 542 PE3. When PE2 receives the packet, it will have an inner label of 543 201. PE2 can conclude that the source MAC address M1 is behind PE1, 544 since it distributed the label 201 to PE1. It can therefore 545 associate MAC address M1 with VC Label 102. 547 ----- 548 / A1 \ 549 ---- ----CE1 | 550 / \ -------- ------- / | | 551 | A2 CE2- / \ / PE1 \ / 552 \ / \ / \---/ \ ----- 553 ---- ---PE2 | 554 | Service Provider Network | 555 \ / \ / 556 ----- PE3 / \ / 557 |Agg|_/ -------- ------- 558 -| | 559 ---- / ----- ---- 560 / \/ \ / \ CE = Customer Edge Router 561 | A3 CE3 --C4 A4 | PE = Provider Edge Router 562 \ / \ / Agg = Layer 2 Aggregation 563 ---- ---- 565 7.1. MAC Address Aging 567 PEs that learn remote MAC addresses need to have an aging mechanism 568 to remove unused entries associated with a VC Label. This is 569 important both for conservation of memory as well as for 570 administrative purposes. For example, if a customer site A is shut 571 down, eventually, the other PEs should unlearn A's MAC address. 573 As packets arrive, MAC addresses are remembered. The aging timer 574 for MAC address M SHOULD be reset when a packet is received with 575 source MAC address M. 577 8. A Hierarchical VPLS Model 579 The solution described above requires a full mesh of tunnel LSPs 580 between all the PE routers that participate in the VPLS service. 581 For each VPLS service, n*(n-1)/2 pseudowires must be setup between 582 the PE routers. While this creates signaling overhead, the real 583 detriment to large scale deployment is the packet replication 584 requirements for each provisioned VCs on a PE router. Hierarchical 585 connectivity, described in this document reduces signaling and 586 replication overhead to allow large scale deployment. 588 In many cases, service providers place smaller edge devices in 589 multi-tenant buildings and aggregate them into a PE device in a 590 large Central Office (CO) facility. In some instances, standard IEEE 591 802.1q (Dot 1Q) tagging techniques may be used to facilitate mapping 592 CE interfaces to PE VPLS access points. 594 It is often beneficial to extend the VPLS service tunneling 595 techniques into the MTU (multi-tenant unit) domain. This can be 596 accomplished by treating the MTU device as a PE device and 597 provisioning pseudowires between it and every other edge, as an 598 basic VPLS. An alternative is to utilize [PWE3-ETHERNET] 599 pseudowires or Q-in-Q logical interfaces between the MTU and 600 selected VPLS enabled PE routers. Q-in-Q encapsulation is another 601 form of L2 tunneling technique, which can be used in conjunction 602 with MPLS signaling as will be described later. The following two 603 sections focus on this alternative approach. The VPLS core 604 pseudowires (Hub) are augmented with access pseudowires (Spoke) to 605 form a two-tier hierarchical VPLS (H-VPLS). 607 Spoke pseudowires may be implemented using any L2 tunneling 608 mechanism, expanding the scope of the first tier to include non- 609 bridging VPLS PE routers. The non-bridging PE router would extend a 610 Spoke pseudowire from a Layer-2 switch that connects to it, through 611 the service core network, to a bridging VPLS PE router supporting 612 Hub pseudowires. We also describe how VPLS-challenged nodes and 613 low-end CEs without MPLS capabilities may participate in a 614 hierarchical VPLS. 616 8.1. Hierarchical connectivity 618 This section describes the hub and spoke connectivity model and 619 describes the requirements of the bridging capable and non-bridging 620 MTU devices for supporting the spoke connections. 622 For rest of this discussion we will refer to a bridging capable MTU 623 device as MTU-s and a non-bridging capable PE device as PE-r. A 624 routing and bridging capable device will be referred to as PE-rs. 626 8.1.1. Spoke connectivity for bridging-capable devices 628 As shown in the figure below, consider the case where an MTU-s 629 device has a single connection to the PE-rs device placed in the CO. 630 The PE-rs devices are connected in a basic VPLS full mesh. For each 631 VPLS service, a single spoke pseudowire is set up between the MTU-s 632 and the PE-rs based on [PWE3-CTRL]. Unlike traditional pseudowires 633 that terminate on a physical (or a VLAN-tagged logical) port at each 634 end, the spoke pseudowire terminates on a virtual bridge instance on 635 the MTU-s and the PE-rs devices. 637 PE2-rs 638 ------ 639 / \ 640 | -- | 641 | / \ | 642 CE-1 | \B / | 643 \ \ -- / 644 \ /------ 645 \ MTU-s PE1-rs / | 646 \ ------ ------ / | 647 / \ / \ / | 648 | \ -- | VC-1 | -- |---/ | 649 | / \--|- - - - - - - - - - - |--/ \ | | 650 | \B / | | \B / | | 651 \ /-- / \ -- / ---\ | 652 /----- ------ \ | 653 / \ | 654 ---- \ ------ 655 |Agg | / \ 656 ---- | -- | 657 / \ | / \ | 658 CE-2 CE-3 | \B / | 659 \ -- / 660 MTU-s = Bridging capable MTU ------ 661 PE-rs = VPLS capable PE PE3-rs 663 -- 664 / \ 665 \B / = Virtual VPLS(Bridge)Instance 666 -- 667 Agg = Layer-2 Aggregation 669 The MTU-s device and the PE-rs device treat each spoke connection 670 like an access port of the VPLS service. On access ports, the 671 combination of the physical port and/or the VLAN tag is used to 672 associate the traffic to a VPLS instance while the pseudowire tag 673 (e.g., VC label) is used to associate the traffic from the virtual 674 spoke port with a VPLS instance, followed by a standard L2 lookup to 675 identify which customer port the frame needs to be sent to. 677 8.1.1.1. MTU-s Operation 679 MTU-s device is defined as a device that supports layer-2 switching 680 functionality and does all the normal bridging functions of learning 681 and replication on all its ports, including the virtual spoke port. 682 Packets to unknown destination are replicated to all ports in the 683 service including the virtual spoke port. Once the MAC address is 684 learned, traffic between CE1 and CE2 will be switched locally by the 685 MTU-s device saving the link capacity of the connection to the PE- 686 rs. Similarly traffic between CE1 or CE2 and any remote destination 687 is switched directly on to the spoke connection and sent to the PE- 688 rs over the point-to-point pseudowire. 690 Since the MTU-s is bridging capable, only a single pseudowire is 691 required per VPLS instance for any number of access connections in 692 the same VPLS service. This further reduces the signaling overhead 693 between the MTU-s and PE-rs. 695 If the MTU-s is directly connected to the PE-rs, other encapsulation 696 techniques such as Q-in-Q can be used for the spoke connection 697 pseudowire. 699 8.1.1.2. PE-rs Operation 701 The PE-rs device is a device that supports all the bridging 702 functions for VPLS service and supports the routing and MPLS 703 encapsulation, i.e. it supports all the functions described for a 704 basic VPLS as described above. 706 The operation of PE-rs is independent of the type of device at the 707 other end of the spoke pseudowire. Thus, the spoke pseudowire from 708 the PE-r is treated as a virtual port and the PE-rs device will 709 switch traffic between the spoke pseudowire, hub pseudowires, and 710 access ports once it has learned the MAC addresses. 712 8.1.2. Advantages of spoke connectivity 714 Spoke connectivity offers several scaling and operational advantages 715 for creating large scale VPLS implementations, while retaining the 716 ability to offer all the functionality of the VPLS service. 718 - Eliminates the need for a full mesh of tunnels and full mesh of 719 pseudowires per service between all devices participating in the 720 VPLS service. 721 - Minimizes signaling overhead since fewer pseudowires are required 722 for the VPLS service. 723 - Segments VPLS nodal discovery. MTU-s needs to be aware of only 724 the PE-rs node although it is participating in the VPLS service 725 that spans multiple devices. On the other hand, every VPLS PE-rs 726 must be aware of every other VPLS PE-rs device and all of it's 727 locally connected MTU-s and PE-r. 728 - Addition of other sites requires configuration of the new MTU-s 729 device but does not require any provisioning of the existing MTU-s 730 devices on that service. 731 - Hierarchical connections can be used to create VPLS service that 732 spans multiple service provider domains. This is explained in a 733 later section. 735 8.1.3. Spoke connectivity for non-bridging devices 737 In some cases, a bridging PE-rs device may not be deployed in a CO 738 or a multi-tenant building while a PE-r might already be deployed. 739 If there is a need to provide VPLS service from the CO where the PE- 740 rs device is not available, the service provider may prefer to use 741 the PE-r device in the interim. In this section, we explain how a 742 PE-r device that does not support any of the VPLS bridging 743 functionality can participate in the VPLS service. 745 As shown in this figure, the PE-r device creates a point-to-point 746 tunnel LSP to a PE-rs device. Then for every access port that needs 748 PE2-rs 749 ------ 750 / \ 751 | -- | 752 | / \ | 753 CE-1 | \B / | 754 \ \ -- / 755 \ /------ 756 \ PE-r PE1-rs / | 757 \ ------ ------ / | 758 / \ / \ / | 759 | \ | VC-1 | -- |---/ | 760 | ------|- - - - - - - - - - - |--/ \ | | 761 | -----|- - - - - - - - - - - |--\B / | | 762 \ / / \ -- / ---\ | 763 ------ ------ \ | 764 / \ | 765 ---- \------ 766 | Agg| / \ 767 ---- | -- | 768 / \ | / \ | 769 CE-2 CE-3 | \B / | 770 \ -- / 771 ------ 772 PE3-rs 774 to participate in a VPLS service, the PE-r device creates a point- 775 to-point [PWE3-ETHERNET] pseudowire that terminates on the physical 776 port at the PE-r and terminates on the virtual bridge instance of 777 the VPLS service at the PE-rs. 779 8.1.3.1. PE-r Operation 781 The PE-r device is defined as a device that supports routing but 782 does not support any bridging functions. However, it is capable of 783 setting up [PWE3-ETHERNET] pseudowires between itself and the PE-rs. 784 For every port that is supported in the VPLS service, a [PWE3- 785 ETHERNET] pseudowire is setup from the PE-r to the PE-rs. Once the 786 pseudowires are setup, there is no learning or replication function 787 required on part of the PE-r. All traffic received on any of the 788 access ports is transmitted on the pseudowire. Similarly all 789 traffic received on a pseudowire is transmitted to the access port 790 where the pseudowire terminates. Thus traffic from CE1 destined for 791 CE2 is switched at PE-rs and not at PE-r. 793 This approach adds more overhead than the bridging capable (MTU-s) 794 spoke approach since a pseudowire is required for every access port 795 that participates in the service versus a single pseudowire required 796 per service (regardless of access ports) when a MTU-s type device is 797 used. However, this approach offers the advantage of offering a 798 VPLS service in conjunction with a routed internet service without 799 requiring the addition of new MTU device. 801 8.2. Redundant Spoke Connections 803 An obvious weakness of the hub and spoke approach described thus far 804 is that the MTU device has a single connection to the PE-rs device. 805 In case of failure of the connection or the PE-rs device, the MTU 806 device suffers total loss of connectivity. 808 In this section we describe how the redundant connections can be 809 provided to avoid total loss of connectivity from the MTU device. 810 The mechanism described is identical for both, MTU-s and PE-r type 811 of devices 813 8.2.1. Dual-homed MTU device 815 To protect from connection failure of the pseudowire or the failure 816 of the PE-rs device, the MTU-s device or the PE-r is dual-homed into 817 two PE-rs devices, as shown in figure-3. The PE-rs devices must be 818 part of the same VPLS service instance. 820 An MTU-s device will setup two [PWE3-ETHERNET] pseudowires (one each 821 to PE-rs1 and PE-rs2) for each VPLS instance. One of the two 822 pseudowires is designated as primary and is the one that is actively 823 used under normal conditions, while the second pseudowire is 824 designated as secondary and is held in a standby state. The MTU 825 device negotiates the pseudowire labels for both the primary and 826 secondary pseudowires, but does not use the secondary pseudowire 827 unless the primary pseudowire fails. Since only one link is active 828 at a given time, a loop does not exist and hence 802.1D spanning 829 tree is not required. 831 PE2-rs 832 ------ 833 / \ 834 | -- | 835 | / \ | 836 CE-1 | \B / | 837 \ \ -- / 838 \ /------ 839 \ MTU-s PE1-rs / | 840 \------ ------ / | 841 / \ / \ / | 842 | -- | Primary PW | -- |---/ | 843 | / \--|- - - - - - - - - - - |--/ \ | | 844 | \B / | | \B / | | 845 \ -- \/ \ -- / ---\ | 846 ------\ ------ \ | 847 / \ \ | 848 / \ \ ------ 849 / \ / \ 850 CE-2 \ | -- | 851 \ Secondary PW | / \ | 852 - - - - - - - - - - - - - - - - - |-\B / | 853 \ -- / 854 ------ 855 PE3-rs 857 8.2.2. Failure detection and recovery 859 The MTU-s device controls the usage of the pseudowires to the PE-rs 860 nodes. Since LDP signaling is used to negotiate the pseudowire 861 labels, the hello messages used for the LDP session can be used to 862 detect failure of the primary pseudowire. 864 Upon failure of the primary pseudowire, MTU-s device immediately 865 switches to the secondary pseudowire. At this point the PE3-rs 866 device that terminates the secondary pseudowire starts learning MAC 867 addresses on the spoke pseudowire. All other PE-rs nodes in the 868 network think that CE-1 and CE-2 are behind PE1-rs and may continue 869 to send traffic to PE1-rs until they learn that the devices are now 870 behind PE3-rs. The relearning process can take a long time and may 871 adversely affect the connectivity of higher level protocols from CE1 872 and CE2. To enable faster convergence, the PE3-rs device where the 873 secondary pseudowire got activated may send out a flush message, 874 using the MAC TLV as defined in Section 6, to all PE-rs nodes. Upon 875 receiving the message, PE-rs nodes flush the MAC addresses 876 associated with that VPLS instance. 878 8.3. Multi-domain VPLS service 880 Hierarchy can also be used to create a large scale VPLS service 881 within a single domain or a service that spans multiple domains 882 without requiring full mesh connectivity between all VPLS capable 883 devices. Two fully meshed VPLS networks are connected together using 884 a single LSP tunnel between the VPLS "border" devices. A single 885 spoke pseudowire per VPLS service is set up to connect the two 886 domains together. 888 When more than two domains need to be connected, a full mesh of 889 inter-domain spokes is created between border PEs. Forwarding rules 890 over this mesh are identical to the rules defined in section 5. 892 This creates a three-tier hierarchical model that consists of a hub- 893 and-spoke topology between MTU-s and PE-rs devices, a full-mesh 894 topology between PE-rs, and a full mesh of inter-domain spokes 895 between border PE-rs devices. 897 9. Hierarchical VPLS model using Ethernet Access Network 899 In this section the hierarchical model is expanded to include an 900 Ethernet access network. This model retains the hierarchical 901 architecture discussed previously in that it leverages the full-mesh 902 topology among PE-rs devices; however, no restriction is imposed on 903 the topology of the Ethernet access network (e.g., the topology 904 between MTU-s and PE-rs devices are not restricted to hub and spoke). 906 The motivation for an Ethernet access network is that Ethernet-based 907 networks are currently deployed by some service providers to offer 908 VPLS services to their customers. Therefore, it is important to 909 provide a mechanism that allows these networks to integrate with an 910 IP or MPLS core to provide scalable VPLS services. 912 One approach of tunneling a customer's Ethernet traffic via an 913 Ethernet access network is to add an additional VLAN tag to the 914 customer's data (which may be either tagged or untagged). The 915 additional tag is referred to as Provider's VLAN (P-VLAN). Inside the 916 provider's network each P-VLAN designates a customer or more 917 specifically a VPLS instance for that customer. Therefore, there is a 918 one to one correspondence between a P-VLAN and a VPLS instance. 920 In this model, the MTU-S device needs to have the capability of 921 adding the additional P-VLAN tag for non-multiplexed customer UNI 922 port where customer VLANs are not used as service delimiter. If 923 customer VLANs need to be treated as service delimiter (e.g., 924 customer UNI port is a multiplexed port), then the MTU-s needs to 925 have the additional capability of translating a customer VLAN (C- 926 VLAN) to a P-VLAN in order to resolve overlapping VLAN-ids used by 927 different customers. Therefore, the MTU-s device in this model can be 928 considered as a typical bridge with this additional UNI capability. 930 The PE-rs device needs to be able to perform bridging functionality 931 over the standard Ethernet ports toward the access network as well as 932 over the pseudowires toward the network core. The set of pseudowires 933 that corresponds to a VPLS instance would look just like a P-VLAN to 934 the bridge portion of the PE-rs and that is why sometimes it is 935 referred to as Emulated VLAN. In this model the PE-rs may need to run 936 STP protocol in addition to split-horizon. Split horizon is run over 937 MPLS-core; whereas, STP is run over the access network to accommodate 938 any arbitrary access topology. In this model, the PE-rs needs to map 939 a P-VLAN to a VPLS-instance and its associated pseudowires and vise 940 versa. 942 The details regarding bridge operation for MTU-s and PE-rs (e.g., 943 encapsulation format for QinQ messages, customer's Ethernet control 944 protocol handling, etc.) are outside of the scope of this document 945 and they are covered in [802.1ad]. However, the relevant part is the 946 interaction between the bridge module and the MPLS/IP pseudowires in 947 the PE-rs device. 949 9.1. Scalability 951 Given that each P-VLAN corresponds to a VPLS instance, one may think 952 that the total number of VPLS instances supported is limited to 4K. 953 However, the 4K limit applies only to each Ethernet access network 954 (Ethernet island) and not to the entire network. The SP network, in 955 this model, consists of a core MPLS/IP network that connects many 956 Ethernet islands. Therefore, the number of VPLS instances can scale 957 accordingly with the number of Ethernet islands (a metro region can 958 be represented by one or more islands). Each island may consist of 959 many MTU-s devices, several aggregators, and one or more PE-rs 960 devices. The PE-rs devices enable a P-VLAN to be extended from one 961 island to others using a set of pseudowires (associated with that 962 VPLS instance) and providing a loop free mechanism across the core 963 network through split-horizon. Since a P-VLAN serves as a service 964 delimiter within the provider's network, it does not get carried over 965 the pseudowires and furthermore the mapping between P-VLAN and the 966 pseudowires is a local matter. This means a VPLS instance can be 967 represented by different P-VLAN in different Ethernet islands and 968 furthermore each island can support 4K VPLS instances independent 969 from one another. 971 9.2. Dual Homing and Failure Recovery 973 In this model, an MTU-s can be dual or triple homed to different 974 devices (aggregators and/or PE-rs devices). The failure protection 975 for access network nodes and links can be provided through running 976 MSTP in each island. The MSTP of each island is independent from 977 other islands and do not interact with each other. If an island has 978 more than one PE-rs, then a dedicated full-mesh of pseudowires is 979 used among these PE-rs devices for carrying the SP BPDU packets for 980 that island. On a per P-VLAN basis, the MSTP will designate a single 981 PE-rs to be used for carrying the traffic across the core. The loop- 982 free protection through the core is performed using split-horizon and 983 the failure protection in the core is performed through standard 984 IP/MPLS re-routing. 986 10. Significant Modifications 988 Between rev 04 and this one, these are the changes: 990 o Fixed idnits 992 11. Contributors 994 Loa Andersson, TLA 995 Ron Haberman, Masergy 996 Juha Heinanen, Independent 997 Giles Heron, Tellabs 998 Sunil Khandekar, Alcatel 999 Luca Martini, Cisco 1000 Pascal Menezes, Terabeam 1001 Rob Nath, Riverstone 1002 Eric Puetz, SBC 1003 Vasile Radoaca, Nortel 1004 Ali Sajassi, Cisco 1005 Yetik Serbest, SBC 1006 Nick Slabakov, Riverstone 1007 Andrew Smith, Consultant 1008 Tom Soon, SBC 1009 Nick Tingle, Alcatel 1011 12. Acknowledgments 1013 We wish to thank Joe Regan, Kireeti Kompella, Anoop Ghanwani, Joel 1014 Halpern, Rick Wilder, Jim Guichard, Steve Phillips, Norm Finn, Matt 1015 Squire, Muneyoshi Suzuki, Waldemar Augustyn, Eric Rosen, Yakov 1016 Rekhter, and Sasha Vainshtein for their valuable feedback. 1018 We would also ike to thank Rajiv Papneja (ISOCORE), Winston Liu 1019 (ISOCORE), and Charlie Hundall (Extreme) for identifying issues 1020 with the draft in the course of the interoperability tests. 1022 13. Security Considerations 1024 A more comprehensive description of the security issues involved in 1025 L2VPNs is covered in [VPN-SEC]. An unguarded VPLS service is 1026 vulnerable to some security issues which pose risks to the customer 1027 and provider networks. Most of the security issues can be avoided 1028 through implementation of appropriate guards. A couple of them can 1029 be prevented through existing protocols. 1031 . Data plane aspects 1032 o Traffic isolation between VPLS domains is guaranteed by 1033 the use of per VPLS L2 FIB table and the use of per VPLS 1034 pseudowires 1035 o The customer traffic, which consists of Ethernet frames, 1036 is carried unchanged over VPLS. If security is required, 1037 the customer traffic SHOULD be encrypted and/or 1038 authenticated before entering the service provider network 1039 o Preventing broadcast storms can be achieved by using 1040 routers as CPE devices or by rate policing the amount of 1041 broadcast traffic that customers can send. 1042 . Control plane aspects 1043 o LDP security (authentication) methods as described in 1044 [RFC-3036] SHOULD be applied. This would prevent 1045 unauthorized participation by a PE in a VPLS. 1046 . Denial of service attacks 1047 o Some means to limit the number of MAC addresses (per site 1048 per VPLS) that a PE can learn SHOULD be implemented. 1050 14. Full Copyright Statement 1052 Copyright (C) The Internet Society (2001). All Rights Reserved. 1053 This document and translations of it may be copied and furnished to 1054 others, and derivative works that comment on or otherwise explain it 1055 or assist in its implementation may be prepared, copied, published 1056 and distributed, in whole or in part, without restriction of any 1057 kind, provided that the above copyright notice and this paragraph 1058 are included on all such copies and derivative works. However, this 1059 document itself may not be modified in any way, such as by removing 1060 the copyright notice or references to the Internet Society or other 1061 Internet organizations, except as needed for the purpose of 1062 developing Internet standards in which case the procedures for 1063 copyrights defined in the Internet Standards process must be 1064 followed, or as required to translate it into languages other than 1065 English. 1067 The limited permissions granted above are perpetual and will not be 1068 revoked by the Internet Society or its successors or assigns. 1070 This document and the information contained herein is provided on an 1071 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1072 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1073 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1074 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1075 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1077 15. IPR Notice 1079 The IETF takes no position regarding the validity or scope of any 1080 intellectual property or other rights that might be claimed to 1081 pertain to the implementation or use of the technology described in 1082 this document or the extent to which any license under such rights 1083 might or might not be available; neither does it represent that it 1084 has made any effort to identify any such rights. Information on the 1085 IETF's procedures with respect to rights in standards-track and 1086 standards-related documentation can be found in BCP-11. Copies of 1087 claims of rights made available for publication and any assurances of 1088 licenses to be made available, or the result of an attempt made to 1089 obtain a general license or permission for the use of such 1090 proprietary rights by implementors or users of this specification can 1091 be obtained from the IETF Secretariat. 1093 The IETF invites any interested party to bring to its attention any 1094 copyrights, patents or patent applications, or other proprietary 1095 rights which may cover technology that may be required to practice 1096 this standard. Please address the information to the IETF Executive 1097 Director. 1099 16. Normative References 1101 [PWE3-ETHERNET] "Encapsulation Methods for Transport of Ethernet 1102 Frames Over IP/MPLS Networks", draft-ietf-pwe3-ethernet-encap-06. 1103 txt, Work in progress, April 2004. 1105 [PWE3-CTRL] "Transport of Layer 2 Frames over MPLS", draft-ietf- 1106 pwe3-control-protocol-06.txt, Work in progress, March 2004. 1108 [802.1D-ORIG] Original 802.1D - ISO/IEC 10038, ANSI/IEEE Std 802.1D- 1109 1993 "MAC Bridges". 1111 [802.1D-REV] 802.1D - "Information technology - Telecommunications 1112 and information exchange between systems - Local and metropolitan 1113 area networks - Common specifications - Part 3: Media Access Control 1114 (MAC) Bridges: Revision. This is a revision of ISO/IEC 10038: 1993, 1115 802.1j-1992 and 802.6k-1992. It incorporates P802.11c, P802.1p and 1116 P802.12e." ISO/IEC 15802-3: 1998. 1118 [802.1Q] 802.1Q - ANSI/IEEE Draft Standard P802.1Q/D11, "IEEE 1119 Standards for Local and Metropolitan Area Networks: Virtual Bridged 1120 Local Area Networks", July 1998. 1122 [RFC3036] "LDP Specification", L. Andersson, et al. RFC 3036. 1123 January 2001. 1125 17. Informative References 1127 [BGP-VPN] "BGP/MPLS VPNs". draft-ietf-l3vpn-rfc2547bis-01.txt, Work 1128 in Progress, September 2003. 1130 [RADIUS-DISC] "Using Radius for PE-Based VPN Discovery", draft-ietf- 1131 l2vpn-radius-pe-discovery-00.txt, Work in Progress, February 2004. 1133 [BGP-DISC] "Using BGP as an Auto-Discovery Mechanism for Network- 1134 based VPNs", draft-ietf-l3vpn-bgpvpn-auto-02.txt, Work in Progress, 1135 April 2004. 1137 [LDP-DISC] "Discovering Nodes and Services in a VPLS Network", 1138 draft-stokes-ppvpn-vpls-discover-00.txt, Work in Progress, June 1139 2002. 1141 [L2FRAME] "Framework for Layer 2 Virtual Private Networks (L2VPNs)", 1142 draft-ietf-l2vpn-l2-framework-04, Work in Progress, March 2004. 1144 [L2VPN-REQ] "Service Requirements for Layer-2 Provider Provisioned 1145 Virtual Private Networks", draft-ietf-l2vpn-requirements-01.txt, 1146 Work in Progress, February 2004. 1148 [VPN-SEC] "Security Framework for Provider Provisioned Virtual 1149 Private Networks", draft-ietf-l3vpn-security-framework-01.txt, Work 1150 in Progress, February 2004. 1152 [802.1ad] "IEEE standard for Provider Bridges", Work in Progress, 1153 December 2002. 1155 Appendix 1. Signaling a VPLS Using the PWid FEC Element 1157 This section is being retained because live deployments use this 1158 version of the signaling for VPLS. 1160 The VPLS signaling information is carried in a Label Mapping message 1161 sent in downstream unsolicited mode, which contains the following VC 1162 FEC TLV. 1164 VC, C, VC Info Length, Group ID, Interface parameters are as defined 1165 in [PWE3-CTRL]. 1167 0 1 2 3 1168 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 1169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1170 | VC tlv |C| VC Type |VC info Length | 1171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1172 | Group ID | 1173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1174 | VCID | 1175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1176 | Interface parameters | 1177 ~ ~ 1178 | | 1179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1181 We use the Ethernet pseudowire type to identify pseudowires that 1182 carry Ethernet traffic for multipoint connectivity. 1184 In a VPLS, we use a VCID (which has been substituted with a more 1185 general identifier, to address extending the scope of a VPLS) to 1186 identify an emulated LAN segment. Note that the VCID as specified 1187 in [PWE3-CTRL] is a service identifier, identifying a service 1188 emulating a point-to-point virtual circuit. In a VPLS, the VCID is 1189 a single service identifier. 1191 18. Authors' Addresses 1193 Marc Lasserre 1194 Riverstone Networks 1195 Email: marc@riverstonenet.com 1197 Vach Kompella 1198 Alcatel 1199 Email: vach.kompella@alcatel.com