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