idnits 2.17.1 draft-lasserre-vkompella-ppvpn-vpls-02.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: ---------------------------------------------------------------------------- == There is 1 instance 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 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 4 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. ** 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 304: '... Each PE MUST create a rooted tree t...' RFC 2119 keyword, line 305: '... L2 VPN. Each PE MUST support a "split...' RFC 2119 keyword, line 306: '...s, that is, a PE MUST NOT forward traf...' RFC 2119 keyword, line 441: '... It MAY be desirable to remove or re...' RFC 2119 keyword, line 448: '...ge with MAC TLVs MAY be supported in o...' (8 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'VPLS-REQ' is mentioned on line 1164, but not defined == Missing Reference: 'BGP-VPN' is mentioned on line 1162, but not defined -- Looks like a reference, but probably isn't: '8' on line 353 == Missing Reference: 'FINN-BRIDGING' is mentioned on line 1180, but not defined == Missing Reference: 'VPLS' is mentioned on line 731, but not defined == Missing Reference: 'SINGLE-SIDED' is mentioned on line 1170, but not defined == Missing Reference: 'Martini-Encap' is mentioned on line 815, but not defined == Missing Reference: 'RFC3036' is mentioned on line 1167, but not defined ** Obsolete undefined reference: RFC 3036 (Obsoleted by RFC 5036) == Missing Reference: 'DIR-AUTO' is mentioned on line 1173, but not defined == Missing Reference: 'BGP-AUTO' is mentioned on line 1176, but not defined == Outdated reference: A later version (-01) exists of draft-martini-ethernet-encap-mpls-00 -- Possible downref: Normative reference to a draft: ref. 'MARTINI-ENCAP' == Outdated reference: A later version (-19) exists of draft-martini-l2circuit-trans-mpls-09 ** Downref: Normative reference to an Historic draft: draft-martini-l2circuit-trans-mpls (ref. 'MARTINI-SIG') Summary: 7 errors (**), 0 flaws (~~), 15 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft Document Marc Lasserre 3 Provider Provisioned VPN Working Group Riverstone Networks 4 draft-lasserre-vkompella-ppvpn-vpls-02.txt Vach Kompella 5 Nick Tingle 6 Sunil Khandekar 7 Timetra Networks 9 Ali Sajassi 10 Cisco Systems 12 Pascal Menezes Loa Andersson 13 Terabeam Utfors 15 Andrew Smith Pierre Lin 16 Consultant Yipes Communication 18 Juha Heinanen Giles Heron 19 Song Networks PacketExchange Ltd. 21 Ron Haberman Tom S.C. Soon 22 Masergy, Inc. Yetik Serbest 23 Eric Puetz 24 Nick Slabakov SBC Communications 25 Rob Nath 26 Riverstone Networks 27 Luca Martini 28 Vasile Radaoca Level 3 29 Nortel Networks Communications 31 Expires: January 2003 June 2002 33 Virtual Private LAN Services over MPLS 34 draft-lasserre-vkompella-ppvpn-vpls-02.txt 36 1. Status of this Memo 38 This document is an Internet-Draft and is in full conformance 39 with all provisions of Section 10 of RFC2026. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF), its areas, and its working groups. Note that 43 other groups may also distribute working documents as Internet- 44 Drafts. 46 Internet-Drafts are draft documents valid for a maximum of six 47 months and may be updated, replaced, or obsoleted by other documents 48 at any time. It is inappropriate to use Internet-Drafts as 49 reference material or to cite them other than as "work in progress." 50 The list of current Internet-Drafts can be accessed at 51 http://www.ietf.org/ietf/1id-abstracts.txt 52 The list of Internet-Draft Shadow Directories can be accessed at 53 http://www.ietf.org/shadow.html. 55 2. Abstract 57 This document describes a virtual private LAN service (VPLS) 58 solution over MPLS, also known as Transparent LAN Services (TLS). 59 VPLS simulates an Ethernet virtual 802.1D bridge [802.1D-ORIG] 60 [802.1D-REV] for a given set of users. It delivers a layer 2 61 broadcast domain that is fully capable of learning and forwarding on 62 Ethernet MAC addresses that is closed to a given set of users. Many 63 VLS services can be supported from a single PE node. 65 3. Conventions 67 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 68 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 69 document are to be interpreted as described in RFC 2119 71 Placement of this Memo in Sub-IP Area 73 RELATED DOCUMENTS 75 http:// search.ietf.org/internet-drafts/draft-martini-l2circuit- 76 trans-mpls-06.txt 78 http://search.ietf.org/internet-drafts/draft-martini-l2circuit- 79 encap-mpls-02.txt 81 http://search.ietf.org/internet-drafts/draft-augustyn-ppvpn-vpls- 82 reqmts-00.txt 84 WHERE DOES THIS FIT IN THE PICTURE OF THE SUB-IP WORK 86 PPVPN 88 WHY IS IT TARGETTED AT THIS WG 90 The charter of the PPVPN WG includes L2 VPN services and this draft 91 specifies a model for Ethernet L2 VPN services over MPLS. 93 JUSTIFICATION 95 Existing Internet drafts specify how to provide point-to-point 96 Ethernet L2 VPN services over MPLS. This draft defines how 97 multipoint Ethernet services can be provided. 99 4. Table of Contents 101 1. Status of this Memo.............................................1 102 2. Abstract........................................................2 103 3. Conventions.....................................................2 104 4. Table of Contents...............................................3 105 5. Overview........................................................3 106 6. Bridging Model for MPLS.........................................4 107 6.1. Flooding and Forwarding.......................................5 108 6.2. Address Learning..............................................6 109 6.3. LSP Topology..................................................6 110 6.4. Loop free L2 VPN..............................................6 111 6.5. LDP Based Signaling...........................................7 112 6.6. Ethernet VPLS VC Type.........................................8 113 6.6.1. VPLS Encapsulation actions..................................8 114 6.6.2. VPLS Learning actions.......................................9 115 7. MAC Address Withdrawal..........................................9 116 7.1. MAC TLV......................................................10 117 7.2. Address Withdraw Message Containing MAC TLV..................11 118 8. Operation of a VPLS............................................12 119 8.1. MAC Address Aging............................................12 120 9. A Hierarchical VPLS Model......................................13 121 9.1. Hierarchical connectivity....................................13 122 9.1.1. Spoke connectivity for bridging-capable devices............14 123 9.1.2. Advantages of spoke connectivity...........................16 124 9.1.3. Spoke connectivity for non-bridging devices................16 125 9.2. Redundant Spoke Connections..................................18 126 9.2.1. Dual-homed MTU device......................................18 127 9.2.2. Failure detection and recovery.............................19 128 9.3. Multi-domain VPLS service....................................20 129 10. Hierarchical VPLS model using Ethernet Access Network.........20 130 10.1. Port-based v.s. VLAN-based VPLS operation...................22 131 11. Significant Modifications.....................................23 132 12. Acknowledgments...............................................23 133 13. Security Considerations.......................................23 134 14. Intellectual Property Considerations..........................23 135 15. Full Copyright Statement......................................23 136 16. References....................................................24 137 17. Authors' Addresses............................................25 139 5. Overview 141 Ethernet has become the predominant technology for Local Area 142 Networks (LANs) connectivity and is gaining acceptance as an access 143 technology, specifically in Metropolitan and Wide Area Networks (MAN 144 and WAN respectively). An Ethernet port is used to connect a 145 customer to the Provider Edge (PE) router acting as an LER. Customer 146 traffic is subsequently mapped to a specific MPLS L2 VPN by 147 configuring L2 FECs based upon the input port ID and/or VLAN index 148 depending upon the VPLS service. 150 Broadcast and multicast services are available over traditional 151 LANs. MPLS does not support such services currently. Sites that 152 belong to the same broadcast domain and that are connected via an 153 MPLS network expect broadcast, multicast and unicast traffic to be 154 forwarded to the proper location(s). This requires MAC address 155 learning/aging on a per LSP basis, packet replication across LSPs 156 for multicast/broadcast traffic and for flooding of unknown unicast 157 destination traffic. 159 The primary motivation behind Virtual Private LAN Services (VPLS) is 160 to provide connectivity between geographically dispersed customer 161 sites across MAN/WAN network(s), as if they were connected using a 162 LAN. The intended application for the end-user can be divided into 163 the following two categories: 165 - Connectivity between customer routers: LAN routing application 166 - Connectivity between customer Ethernet switches: LAN switching 167 application 169 [MARTINI-ENCAP] defines how to carry L2 PDUs over point-to-point 170 MPLS LSPs, called VC LSPs. Such VC LSPs can be carried across MPLS 171 or GRE tunnels. This document describes extensions to [MARTINI- 172 ENCAP] for transporting Ethernet/802.3 and VLAN [802.1Q] traffic 173 across multiple sites that belong to the same L2 broadcast domain or 174 VPLS. Note that the same model can be applied to other 802.1 175 technologies. It describes a simple and scalable way to offer 176 Virtual LAN services, including the appropriate flooding of 177 Broadcast, Multicast and unknown unicast destination traffic over 178 MPLS, without the need for address resolution servers or other 179 external servers, as discussed in [VPLS-REQ]. 181 The following discussion applies to devices that serve as Label Edge 182 Routers (LERs) on an MPLS network that is VPLS capable. The behavior 183 of transit Label Switch Routers (LSRs) that are considered a part of 184 MPLS network is not discussed. The MPLS network provides a number of 185 Label Switch Paths (LSPs) that form the basis for connections 186 between LERs attached to the same MPLS network. The resulting set of 187 interconnected LERs forms a private MPLS VPN where each LSP is 188 uniquely identified at each MPLS interface by a label. 190 6. Bridging Model for MPLS 192 An MPLS interface acting as a bridge must be able to flood, forward, 193 and filter bridged frames. 195 +----+ +----+ 196 + C1 +---+ ........................... +---| C1 | 197 +----+ | . . | +----+ 198 Site A | +----+ +----+ | Site B 199 +---| PE |---- MPLS Cloud ----| PE |---+ 200 +----+ | +----+ 201 . | . 202 . +----+ . 203 ..........| PE |........... 204 +----+ ^ 205 | | 206 | +-- Logical bridge 207 +----+ 208 | C1 | 209 +----+ 210 Site C 212 The set of PE devices interconnected via transport tunnels appears 213 as a single 802.1D bridge/switch to customer C1. Each PE device will 214 learn remote MAC addresses to VC LSP associations and learns 215 directly attached MAC addresses on customer facing ports. 217 We note here that while this document shows specific examples using 218 MPLS transport tunnels, other tunnels that can be used by pseudo- 219 wires, e.g., GRE, L2TP, IPSEC, etc., can also be used, as long as 220 the originating PE can be identified, since this is used in the MAC 221 learning process. 223 The scope of the VPLS lies within the PEs in the service provider 224 network, highlighting the fact that apart from customer service 225 delineation, the form of access to a customer site is not relevant 226 to the VPLS [VPLS-REQ]. 228 The PE device is typically an edge router capable of running a 229 signaling protocol and/or routing protocols to exchange VC label 230 information. In addition, it is capable of setting up transport 231 tunnels to other PEs to deliver VC LSP traffic. 233 6.1. Flooding and Forwarding 235 One of attributes of an Ethernet service is that all broadcast and 236 destination unknown MAC addresses are flooded to all ports. To 237 achieve flooding within the service provider network, all address 238 unknown unicast, broadcast and multicast frames are flooded over the 239 corresponding pseudowires to all relevant PE nodes participating in 240 the VPLS. In the MPLS environment this means sending the PDU through 241 each relevant VC LSP. 243 Note that multicast frames are a special case and do not necessarily 244 have to be sent to all VPN members. For simplicity, the default 245 approach of broadcasting multicast frames can be used. Extensions 246 explaining how to interact with 802.1 GMRP protocol, IGMP snooping 247 and static MAC multicast filters will be discussed in a future 248 revision if it is needed. 250 To forward a frame, a PE must be able to associate a destination MAC 251 address with a VC LSP. It is unreasonable and perhaps impossible to 252 require PEs to statically configure an association of every possible 253 destination MAC address with a VC LSP. Therefore, VPLS-capable PEs 254 must have the capability to dynamically learn MAC addresses on both 255 physical ports and virtual circuits and to forward and replicate 256 packets across both physical ports and virtual circuits. 258 6.2. Address Learning 260 Unlike BGP VPNs [BGP-VPN], reachability information does not need to 261 be advertised and distributed via a control plane. Reachability is 262 obtained by standard learning bridge functions in the data plane. 264 As discussed previously, a pseudowire consists of a pair of uni- 265 directional VC LSPs. When a new MAC address is learned on an inbound 266 VC LSP, it needs to be associated with the outbound VC LSP that is 267 part of the same pair. The state of this logical link can be 268 considered as up as soon as both incoming and outgoing LSPs are 269 established. Similarly, it can be considered as down as soon as one 270 of these two LSPs is torn down. 271 Standard learning, filtering and forwarding actions, as defined in 272 [802.1D-ORIG], [802.1D-REV] and [802.1Q], are required when a 273 logical link state changes. 275 6.3. LSP Topology 277 PE routers typically run an IGP between them, and are assumed to 278 have the capability to establish MPLS tunnels. Tunnel LSPs are set 279 up between PEs to aggregate traffic. VC LSPs are signaled to 280 demultiplex the L2 encapsulated packets that traverse the tunnel 281 LSPs. 283 In an Ethernet L2VPN, it becomes the responsibility of the service 284 provider to create the loop free topology. For the sake of 285 simplicity, we assume that the topology of a VPLS is a full mesh of 286 tunnel and pseudowires. 288 6.4. Loop free L2 VPN 290 For simplicity, a full mesh of pseudowires is established between 291 PEs. Ethernet bridges, unlike Frame Relay or ATM where the 292 termination point becomes the CE node, has to examine the layer 2 293 fields of the packets to make a switching decision. If the frame is 294 a destination unknown, broadcast or multicast frame the frame must 295 be flooded. 297 Therefore, if the topology isn't a full mesh, the PE devices may 298 need to forward these frames to other PEs. However, this would 299 require the use of spanning tree protocol to form a loop free 300 topology, that may have characteristics that are undesirable to the 301 provider. The use of a full mesh and split-horizon forwarding 302 obviates the need for a spanning tree protocol. 304 Each PE MUST create a rooted tree to every other PE router that 305 serve the same L2 VPN. Each PE MUST support a "split-horizon" scheme 306 in order to prevent loops, that is, a PE MUST NOT forward traffic 307 from one pseudowire to another in the same VPN (since each PE has 308 direct connectivity to all other PEs in the same VPN). 310 Note that customers are allowed to run STP such as when a customer 311 has "back door" links used to provide redundancy in the case of a 312 failure within the VPLS. In such a case, STP BPDUs are simply 313 tunneled through the MPLS cloud. 315 6.5. LDP Based Signaling 317 In order to establish a full mesh of pseudowires, all PEs in a VPLS 318 must have a full mesh of LDP sessions. 320 Once an LDP session has been formed between two PEs, all pseudowires 321 are signaled over this session. 323 In [MARTINI-SIG], the L2 VPN information is carried in a Label 324 Mapping message sent in downstream unsolicited mode, which contains 325 the following VC FEC TLV. VC, C, VC Info Length, Group ID, 326 Interface parameters are as defined in [MARTINI-SIG]. 328 0 1 2 3 329 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 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 | VC tlv |C| VC Type |VC info Length | 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 | Group ID | 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 | VC ID | 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 | Interface parameters | 338 | " | 339 | " | 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 This document defines a new VC type value in addition to the 343 following values already defined in [MARTINI-SIG]: 345 VC Type Description 346 0x0001 Frame Relay DLCI 347 0x0002 ATM AAL5 VCC transport 348 0x0003 ATM transparent cell transport 349 0x0004 Ethernet VLAN 350 0x0005 Ethernet 351 0x0006 HDLC 352 0x0007 PPP 353 0x8008 CEM [8] 354 0x0009 ATM VCC cell transport 355 0x000A ATM VPC cell transport 356 0x000B Ethernet VPLS 358 VC types 0x0004 and 0x0005 identify VC LSPs that carry VLAN tagged 359 and untagged Ethernet traffic respectively, for point-to-point 360 connectivity. 362 We define a new VC type, Ethernet VPLS, with codepoint 0x000B to 363 identify VC LSPs that carry Ethernet traffic for multipoint 364 connectivity. The Ethernet VC Type is described below. 365 For VC types 0x0001 to 0x000A, The VC ID identifies a particular VC. 366 For the VPLS VC type, the VC ID is a VPN identifier globally unique 367 within a service provider domain. 369 Note that the VCID as specified in [MARTINI_SIG] is a service 370 identifier, identifying a service emulating a point-to-point virtual 371 circuit. In a VPLS, the VCID is a single service identifier, 372 identifying an emulated LAN segment. 374 The use of the VCID as the VPN-id creates some challenges for inter- 375 provider VPLS service and this issue will be addressed in the future 376 revision. 378 6.6. Ethernet VPLS VC Type 379 6.6.1. VPLS Encapsulation actions 381 In a VPLS, a customer Ethernet packet without preamble is 382 encapsulated with a header as defined in [MARTINI-ENCAP]. A 383 customer Ethernet packet is defined as follows: 385 - If the packet, as it arrives at the PE, has an encapsulation 386 that is used by the local PE as a service delimiter, then that 387 encapsulation is stripped before the packet is sent into the 388 VPLS. As the packet exits the VPLS, the packet may have a 389 service-delimiting encapsulation inserted. 391 - If the packet, as it arrives at the PE, has an encapsulation 392 that is not service delimiting, then it is a customer packet 393 whose encapsulation should not be modified by the VPLS. This 394 covers, for example, a packet that carries customer specific 395 VLAN-Ids that the service provider neither knows about nor 396 wants to modify. 398 By following the above rules, the Ethernet packet that traverses a 399 VPLS is always a customer Ethernet packet. Note that the two 400 actions, at ingress and egress, of dealing with service delimiters 401 are local actions that neither PE has to signal to the other. They 402 allow, for example, a mix-and-match of VLAN tagged and untagged 403 services at either end, and do not carry across a VPLS a VLAN tag 404 that may have only local significance. The service delimiter may be 405 a VC label also, whereby an Ethernet VC given by [MARTINI-ENCAP] can 406 serve as the access side connection into a PE. An RFC1483 PVC 407 encapsulation could be another service delimiter. By limiting the 408 scope of locally significant encapsulations to the edge, 409 hierarchical VPLS models can be developed that provide the 410 capability to network-engineer VPLS deployments, as described below. 412 6.6.2. VPLS Learning actions 414 Learning is done based on the customer Ethernet packet, as defined 415 above. The Forwarding Information Base (FIB) keeps track of the 416 mapping of customer Ethernet packet addressing and the appropriate 417 pseudowire to use. We define two modes of learning: qualified and 418 unqualified learning. 420 In unqualified learning, all the customer VLANs are handled by a 421 single VPLS, which means they all share a single broadcast domain 422 and a single MAC address space. This means that MAC addresses need 423 to be unique and non-overlapping among customer VLANs or else they 424 cannot be differentiated within the VPLS instance and this can 425 result in loss of customer frames. An application of unqualified 426 learning is port-based VPLS service for a given customer (e.g., 427 customer with non-multiplexed UNI interface where the entire traffic 428 is mapped to a single VPLS instance). 430 In qualified learning, each customer VLAN is assigned to its own 431 VPLS instance, which means each customer VLAN has its own broadcast 432 domain and MAC address space. Therefore, in qualified learning, MAC 433 addresses among customer VLANs may overlap with each other, but they 434 will be handled correctly since each customer VLAN has its own FIB , 435 i.e., each customer VLAN has its own MAC address space. Since VPLS 436 broadcasts multicast frames, qualified learning offers the advantage 437 of limiting the broadcast scope to a given customer VLAN. 439 7. MAC Address Withdrawal 441 It MAY be desirable to remove or relearn MAC addresses that have 442 been dynamically learned for faster convergence. 444 We introduce an optional MAC TLV that is used to specify a list of 445 MAC addresses that can be removed or relearned using the Address 446 Withdraw Message. 448 The Address Withdraw message with MAC TLVs MAY be supported in order 449 to expedite learning of MAC addresses as the result of a topology 450 change (e.g., failure of the primary link for a dual-homed MTU-s). 451 If a notification message is sent on the backup link (blocked link), 452 which has transitioned into an active state (e.g., similar to 453 Topology Change Notification message of 802.1w RSTP), with a list of 454 MAC entries to be relearned, the PE will update the MAC entries in 455 its FIB for that VPLS instance and send the message to other PEs 456 over the corresponding directed LDP sessions. 458 If the notification message contains an empty list, this tells the 459 receiving PE to remove all the MAC addresses learned for the 460 specified VPLS instance except the ones it learned from the sending 461 PE (MAC address removal is required for all VPLS instances that are 462 affected). Note that the definition of such a notification message 463 is outside the scope of the document, unless it happens to come from 464 an MTU connected to the PE as a spoke. In such a scenario, the 465 message will be just an Address Withdraw message as noted above. 467 7.1. MAC TLV 469 MAC addresses to be relearned can be signaled using an LDP Address 470 Withdraw Message that contains a new TLV, the MAC TLV. Its format 471 is described below. The encoding of a MAC TLV address is the 6-byte 472 MAC address specified by IEEE 802 documents [g-ORIG] [802.1D-REV]. 474 0 1 2 3 475 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 476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 477 |U|F| Type | Length | 478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 479 | MAC address #1 | 480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 481 | | MAC address #2 | 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 | MAC address #2 | 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 485 | ... | 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 U bit 489 Unknown bit. This bit MUST be set to 0. If the MAC address 490 format is not understood, then the TLV is not understood, and MUST 491 be ignored. 493 F bit 494 Forward bit. This bit MUST be set to 0. Since the LDP 495 mechanism used here is Targeted, the TLV MUST NOT be forwarded. 497 Type 498 Type field. This field MUST be set to 0x0404 (subject to IANA 499 approval). This identifies the TLV type as MAC TLV. 501 Length 502 Length field. This field specifies the total length of the 503 TLV, including the Type and Length fields. 505 MAC Address 506 The MAC address being removed. 508 The LDP Address Withdraw Message contains a FEC TLV (to identify the 509 VPLS in consideration), a MAC Address TLV and optional parameters. 510 No optional parameters have been defined for the MAC Address 511 Withdraw signaling. 513 7.2. Address Withdraw Message Containing MAC TLV 515 When MAC addresses are being removed or relearned explicitly, e.g., 516 the primary link of a dual-homed MTU-s has failed, an Address 517 Withdraw Message can be sent with the list of MAC addresses to be 518 relearned. 520 The processing for MAC TLVs received in an Address Withdraw Message 521 is: 522 For each MAC address in the TLV: 523 - Relearn the association between the MAC address and the 524 interface/pseudowire over which this message is received 525 - Send the same message to all other PEs over the corresponding 526 directed LDP sessions. 528 For an Address Withdraw message with empty list: 529 - Remove all the MAC addresses associated with the VPLS instance 530 (specified by the FEC TLV) except the MAC addresses learned 531 over this link (over the pseudowire associated with the 532 signaling link over which the message is received) 533 - Send the same message to all other PEs over the corresponding 534 directed LDP sessions. 536 The scope of a MAC TLV is the VPLS specified in the FEC TLV in the 537 Address Withdraw Message. The number of MAC addresses can be 538 deduced from the length field in the TLV. 540 Further descriptions of how to deal with failures expeditiously with 541 different configurations will be described in other documents, such 542 as [FINN-BRIDGING]. 544 8. Operation of a VPLS 546 We show here an example of how a VPLS works. The following 547 discussion uses the figure below, where a VPLS has been set up 548 between PE1, PE2 and PE3. 550 Initially, the VPLS is set up so that PE1, PE2 and PE3 have a full- 551 mesh of tunnels between them for carrying tunneled traffic. The 552 VPLS instance is assigned a VCID (a 32-bit quantity that is unique 553 across the provider network across all VPLSs). (Allocation of 554 domain-wide unique VCIDs is outside the scope of this draft). 556 For the above example, say PE1 signals VC Label 102 to PE2 and 103 557 to PE3, and PE2 signals VC Label 201 to PE1 and 203 to PE3. 559 Assume a packet from A1 is bound for A2. When it leaves CE1, say it 560 has a source MAC address of M1 and a destination MAC of M2. If PE1 561 does not know where M2 is, it will multicast the packet to PE2 and 562 PE3. When PE2 receives the packet, it will have an inner label of 563 201. PE2 can conclude that the source MAC address M1 is behind PE1, 564 since it distributed the label 201 to PE1. It can therefore 565 associate MAC address M1 with VC Label 102. 566 ----- 567 / A1 \ 568 ---- ----CE1 | 569 / \ -------- ------- / | | 570 | A2 CE2- / \ / PE1 \ / 571 \ / \ / \---/ \ ----- 572 ---- ---PE2 | 573 | Service Provider Network | 574 \ / \ / 575 ----- PE3 / \ / 576 |Agg|_/ -------- ------- 577 -| | 578 ---- / ----- ---- 579 / \/ \ / \ CE = Customer Edge Router 580 | A3 CE3 --C4 A4 | PE = Provider Edge Router 581 \ / \ / Agg = Layer 2 Aggregation 582 ---- ---- 584 8.1. MAC Address Aging 586 PEs that learn remote MAC addresses need to have an aging mechanism 587 to remove unused entries associated with a VC Label. This is 588 important both for conservation of memory as well as for 589 administrative purposes. For example, if a customer site A is shut 590 down, eventually, the other PEs should unlearn A's MAC address. 592 As packets arrive, MAC addresses are remembered. The aging timer 593 for MAC address M SHOULD be reset when a packet is received with 594 source MAC address M. 596 9. A Hierarchical VPLS Model 598 The solution described above requires a full mesh of tunnel LSPs 599 between all the PE routers that participate in the VPLS service. 600 For each VPLS service, n*(n-1) VCs must be setup between the PE 601 routers. While this creates signaling overhead, the real detriment 602 to large scale deployment is the packet replication requirements for 603 each provisioned VCs on a PE router. Hierarchical connectivity, 604 described in this document reduces signaling and replication 605 overhead to allow large scale deployment. 607 In many cases, service providers place smaller edge devices in 608 multi-tenant buildings and aggregate them into a PE device in a 609 large Central Office (CO) facility. In some instances, standard IEEE 610 802.1q (Dot 1Q) tagging techniques may be used to facilitate mapping 611 CE interfaces to PE VPLS access points. 613 It is often beneficial to extend the VPLS service tunneling 614 techniques into the MTU domain. This can be accomplished by 615 treating the MTU device as a PE device and provisioning VCs between 616 it and every other edge, as an basic VPLS. An alternative is to 617 utilize [MARTINI-ENCAP] VCs or Q-in-Q VCs between the MTU and 618 selected VPLS enabled PE routers. Q-in-Q encapsulation is another 619 form of L2 tunneling technique, which can be used in conjunction 620 with MPLS signaling as will be described later. This section focuses 621 on this alternative approach. The [VPLS] mesh core tier VCs (Hub) 622 are augmented with access tier VCs (Spoke) to form a two tier 623 hierarchical VPLS (H-VPLS). 625 Spoke VCs may include any L2 tunneling mechanism, expanding the 626 scope of the first tier to include non-bridging VPLS PE routers. The 627 non-bridging PE router would extend a Spoke VC from a Layer-2 switch 628 that connects to it, through the service core network, to a bridging 629 VPLS PE router supporting Hub VCs. We also describe how VPLS- 630 challenged nodes and low-end CEs without MPLS capabilities may 631 participate in a hierarchical VPLS. 633 9.1. Hierarchical connectivity 635 This section describes the hub and spoke connectivity model and 636 describes the requirements of the bridging capable and non-bridging 637 MTU devices for supporting the spoke connections. 639 For rest of this discussion we will refer to a bridging capable MTU 640 device as MTU-s and a non-bridging capable PE device as PE-r. A 641 routing and bridging capable device will be referred to as PE-rs. 643 9.1.1. Spoke connectivity for bridging-capable devices 645 As shown in the figure below, consider the case where an MTU-s 646 device has a single connection to the PE-rs device placed in the CO. 647 The PE-rs devices are connected in a basic VPLS full mesh. To 648 participate in the VPLS service, MTU-s device creates a single 649 point-to-point tunnel LSP to the PE-rs device in the CO. We will 650 call this the spoke connection. For each VPLS service, a single 651 spoke pseudowire is setup between the MTU-s and the PE-rs based on 652 [MARTINI-SIG] or its extension [SINGLE-SIDED]. Unlike traditional 653 pseudowires that terminate on a physical (or a VLAN-tagged logical) 654 port at each end, the spoke VC terminates on a virtual bridge 655 instance on the MTU-s and the PE-rs devices. 656 PE2-rs 657 ------ 658 / \ 659 | -- | 660 | / \ | 661 CE-1 | \B / | 662 \ \ -- / 663 \ /------ 664 \ MTU-s PE1-rs / | 665 \ ------ ------ / | 666 / \ / \ / | 667 | \ -- | VC-1 | -- |---/ | 668 | / \--|- - - - - - - - - - - |--/ \ | | 669 | \B / | | \B / | | 670 \ /-- / \ -- / ---\ | 671 /----- ------ \ | 672 / \ | 673 ---- \ ------ 674 |Agg | / \ 675 ---- | -- | 676 / \ | / \ | 677 CE-2 CE-3 | \B / | 678 \ -- / 679 MTU-s = Bridging capable MTU ------ 680 PE-rs = VPLS capable PE PE3-rs 682 -- 683 / \ 684 \B / = Virtual VPLS(Bridge)Instance 685 -- 686 Agg = Layer-2 Aggregation 688 The MTU-s device and the PE-rs device treat each spoke connection 689 like an access port of the VPLS service. On access ports, the 690 combination of the physical port and/or the VLAN tag is used to 691 associate the traffic to a VPLS instance while the pseudowire tag 692 (e.g., VC label) is used to associate the traffic from the virtual 693 spoke port with a VPLS instance, followed by a standard L2 lookup to 694 identify which customer port the frame needs to be sent to. 696 The signaling and association of the spoke connection to the VPLS 697 service may be done by introducing extensions to the LDP signaling 698 as specified in [MARTINI-SIG]. 700 9.1.1.1. MTU-s Operation 702 MTU-s device is defined as a device that supports layer-2 switching 703 functionality and does all the normal bridging functions of learning 704 and replication on all its ports, including the virtual spoke port. 705 Packets to unknown destination are replicated to all ports in the 706 service including the virtual spoke port. Once the MAC address is 707 learned, traffic between CE1 and CE2 will be switched locally by the 708 MTU-s device saving the link capacity of the connection to the PE- 709 rs. Similarly traffic between CE1 or CE2 and any remote destination 710 is switched directly on to the spoke connection and sent to the PE- 711 rs over the point-to-point pseudowire. 713 Since the MTU-s is bridging capable, only a single pseudowire is 714 required per VPLS instance for any number of access connections in 715 the same VPLS service. This further reduces the signaling overhead 716 between the MTU-s and PE-rs. 718 If the MTU-s is directly connected to the PE-rs, other encapsulation 719 techniques such as Q-in-Q can be used for the spoke connection 720 pseudowire. However, to maintain a uniform end-to-end control plane 721 based on MPLS signaling, [MARTINI-SIG] can be used for distribution 722 of pseudowire tags (e.g., Q-in-Q tags or VC labels) between MTU-s 723 and PE-rs 725 9.1.1.2. PE-rs Operation 727 The PE-rs device is a device that supports all the bridging 728 functions for VPLS service and supports the routing and MPLS 729 encapsulation, i.e. it supports all the functions described in 730 [VPLS]. The operation on the PE-rs node is identical to that 731 described in [VPLS] with one addition. A point-to-point VC 732 associated with the VPLS is regarded as a virtual port (see 733 discussion in Section 5.6.1 on service delimiting). The operation 734 on the virtual spoke port is identical to the operation on an access 735 port as described in the earlier section. As shown in the figure 736 above, each PE-rs device switches traffic between aggregated access 737 VCs that look like virtual ports and the network side VPLS VCs. 739 9.1.2. Advantages of spoke connectivity 741 Spoke connectivity offers several scaling and operational advantages 742 for creating large scale VPLS implementations, while retaining the 743 ability to offer all the functionality of the VPLS service. 745 - Eliminates the need for a full mesh of tunnels and full mesh of 746 VCs per service between all devices participating in the VPLS 747 service. 748 - Minimizes signaling overhead since fewer VC-LSPs are required for 749 the VPLS service. 750 - Segments VPLS nodal discovery. MTU-s needs to be aware of only 751 the PE-rs node although it is participating in the VPLS service 752 that spans multiple devices. On the other hand, every VPLS PE-rs 753 must be aware of every other VPLS PE-rs device and all of it�s 754 locally connected MTU-s and PE-r. 755 - Addition of other sites requires configuration of the new MTU-s 756 device but does not require any provisioning of the existing MTU-s 757 devices on that service. 758 - Hierarchical connections can be used to create VPLS service that 759 spans multiple service provider domains. This is explained in a 760 later section. 762 9.1.3. Spoke connectivity for non-bridging devices 764 In some cases, a bridging PE-rs device may not be deployed in a CO 765 or a multi-tenant building while a PE-r might already be deployed. 766 If there is a need to provide VPLS service from the CO where the PE- 767 rs device is not available, the service provider may prefer to use 768 the PE-r device in the interim. In this section, we explain how a 769 PE-r device that does not support any of the VPLS bridging 770 functionality can participate in the VPLS service. 772 As shown in this figure, the PE-r device creates a point-to-point 773 tunnel LSP to a PE-rs device. Then for every access port that needs 774 to participate in a VPLS service, the PE-r device creates a point- 775 to-point [MARTINI-ENCAP] VC that terminates on the physical port at 776 the PE-r and terminates on the virtual bridge instance of the VPLS 777 service at the PE-rs. 779 PE2-rs 780 ------ 781 / \ 782 | -- | 783 | / \ | 784 CE-1 | \B / | 785 \ \ -- / 786 \ /------ 787 \ PE-r PE1-rs / | 788 \ ------ ------ / | 789 / \ / \ / | 790 | \ | VC-1 | -- |---/ | 791 | ------|- - - - - - - - - - - |--/ \ | | 792 | -----|- - - - - - - - - - - |--\B / | | 793 \ / / \ -- / ---\ | 794 ------ ------ \ | 795 / \ | 796 ---- \------ 797 | Agg| / \ 798 ---- | -- | 799 / \ | / \ | 800 CE-2 CE-3 | \B / | 801 \ -- / 802 PE-r = Non-Bridging PE (router) ------ 803 PE-rs = VPLS capable PE PE3-rs 805 -- 806 / \ 807 \B / = Virtual VPLS(Bridge)Instance 808 -- 809 Agg = Layer-2 Aggregation 811 9.1.3.1. PE-r Operation 813 The PE-r device is defined as a device that supports routing but 814 does not support any bridging functions. However, it is capable of 815 setting up [Martini-Encap] VCs between itself and the PE-rs. For 816 every port that is supported in the VPLS service, a [MARTINI-ENCAP] 817 VC is setup from the PE-r to the PE-rs. Once the VCs are setup, 818 there is no learning or replication function required on part of the 819 PE-r. All traffic received on any of the access ports is 820 transmitted on the VC. Similarly all traffic received on a VC is 821 transmitted to the access port where the VC terminates. Thus 822 traffic from CE1 destined for CE2 is switched at PE-rs and not at 823 PE-r. 825 This approach adds more overhead than the bridging capable (MTU-s) 826 spoke approach since a VC is required for every access port that 827 participates in the service versus a single VC required per service 828 (regardless of access ports) when a MTU-s type device is used. 830 However, this approach offers the advantage of offering a VPLS 831 service in conjunction with a routed internet service without 832 requiring the addition of new MTU device. 834 9.1.3.2. PE-rs Operation 836 The operation of PE-rs is independent of the type of device at the 837 other end of the spoke connection. Whether there is a bridging 838 capable device (MTU-s) at the other end of the spoke connection or 839 there is a non-bridging device (PE-r) at the other end of the spoke 840 connection, the operation of PE-rs is exactly the same. Thus, the 841 spoke connection from the PE-r is treated as a virtual port and the 842 PE-rs device switches traffic between the virtual port, access ports 843 and the network side VPLS VCs once it has learned the MAC addresses. 845 9.2. Redundant Spoke Connections 847 An obvious weakness of the hub and spoke approach described thus far 848 is that the MTU device has a single connection to the PE-rs device. 849 In case of failure of the connection or the PE-rs device, the MTU 850 device suffers total loss of connectivity. 852 In this section we describe how the redundant connections can be 853 provided to avoid total loss of connectivity from the MTU device. 854 The mechanism described is identical for both, MTU-s and PE-r type 855 of devices 857 9.2.1. Dual-homed MTU device 859 To protect from connection failure of the VC or the failure of the 860 PE-rs device, the MTU-s device or the PE-r is dual-homed into two 861 PE-rs devices, as shown in figure-3. The PE-rs devices must be part 862 of the same VPLS service instance. 864 An MTU-s device will setup two [MARTINI-ENCAP] VCs (one each to PE- 865 rs1 and PE-rs2) for each VPLS instance. One of the two VC is 866 designated as primary and is the one that is actively used under 867 normal conditions, while the second VC is designated as secondary 868 and is held in a standby state. The MTU device negotiates the VC- 869 labels for both the primary and secondary VC, but does not use the 870 secondary VC unless the primary VC fails. Since only one link is 871 active at a given time, a loop does not exist and hence 802.1D 872 spanning tree is not required. 874 PE2-rs 875 ------ 876 / \ 877 | -- | 878 | / \ | 879 CE-1 | \B / | 880 \ \ -- / 881 \ /------ 882 \ MTU-s PE1-rs / | 883 \------ ------ / | 884 / \ / \ / | 885 | -- | Primary VC | -- |---/ | 886 | / \--|- - - - - - - - - - - |--/ \ | | 887 | \B / | | \B / | | 888 \ -- \/ \ -- / ---\ | 889 ------\ ------ \ | 890 / \ \ | 891 / \ \ ------ 892 / \ / \ 893 CE-2 \ | -- | 894 \ Secondary VC | / \ | 895 - - - - - - - - - - - - - - - - - |-\B / | 896 \ -- / 897 MTU-s = Bridging capable MTU ------ 898 PE-rs = VPLS capable PE PE3-rs 900 -- 901 / \ 902 \B / = Virtual VPLS(Bridge)Instance 903 -- 905 9.2.2. Failure detection and recovery 907 The MTU-s device controls the usage of the VC links to the PE-rs 908 nodes. Since LDP signaling is used to negotiate the VC-labels, the 909 hello messages used for the LDP session can be used to detect 910 failure of the primary VC. 912 Upon failure of the primary VC, MTU-s device immediately switches to 913 the secondary VC. At this point the PE3-rs device that terminates 914 the secondary VC starts learning MAC addresses on the spoke VC. All 915 other PE-rs nodes in the network think that CE-1 and CE-2 are behind 916 PE1-rs and may continue to send traffic to PE1-rs until they learn 917 that the devices are now behind PE3-rs. The relearning process can 918 take a long time and may adversely affect the connectivity of higher 919 level protocols from CE1 and CE2. To enable faster convergence, the 920 PE3-rs device where the secondary VC got activated may send out a 921 flush message, using the MAC TLV as defined in Section 6, to all 922 other PE-rs devices participating in the VPLS service. Upon 923 receiving the message, all PE-rs flush the MAC addresses associated 924 with that VPLS instance . 926 9.3. Multi-domain VPLS service 928 Hierarchy can also be used to create a large scale VPLS service 929 within a single domain or a service that spans multiple domains 930 without requiring full mesh connectivity between all VPLS capable 931 devices. Two fully meshed VPLS networks are connected together 932 using a single LSP tunnel between the VPLS gateway devices. A 933 single VC is setup per VPLS service to connect the two domains 934 together. The VPLS gateway device joins two VPLS services together 935 to form a single multi-domain VPLS service. . The requirements and 936 functionality required from a VPLS gateway device will be explained 937 in a future version of this document. 939 10. Hierarchical VPLS model using Ethernet Access Network 941 In the previous section, a two-tier hierarchical model that consists 942 of hub-and-spoke topology between MTU-s devices and PE-rs devices and 943 a full-mesh topology among PE-rs devices was discussed. In this 944 section the two-tier hierarchical model is expanded to include an 945 Ethernet access network. This model retains the hierarchical 946 architecture discussed previously in that it includes MTU-s devices 947 and PE-rs devices and also utilized a full-mesh topology among PE-rs 948 devices. The motivation for an Ethernet access network is that 949 Ethernet-based networks are currently deployed by some service 950 providers to offer VPLS services to their customers. Therefore, it is 951 important to provide a mechanism that allows these networks to 952 integrate with an IP or MPLS core to provide scalable VPLS services. 953 One can categorize Ethernet access networks into the following three 954 groups: 956 1. Based on existing 802.1q standard (this is comparable to the 957 situation where the customer comes ino on a VLAN-tagged port) 958 2. Based on an extension to the IEEE 802.1q standard that tunnels 959 802.1q VLANs using a service provider 802.1q tag (referred to as 960 Q-in-Q) 961 3. Based on Q-in-Q tunneling with ability to distribute .1q tags 962 using MPLS control plane 964 For the first category, the MTU-s and all the other nodes in the 965 access network (excluding PE-rs devices) have standard 802.1q 966 Ethernet switch capability. However, the PE-rs device is a VPLS- 967 capable router as described previously. 969 For the second category, in addition to the functionality described 970 in the category above, the MTU-s and the PE-rs are required to 971 support Q-in-Q tunneling capabilities and the Ethernet nodes in 972 between are required to handle larger data frames (to accommodate the 973 additional encapsulation). 975 The third category requires the MTU-s and the PE-rs to support LDP 976 signaling for the distribution of Q-in-Q tags (i.e., MTU-s and PE-rs 977 to have MPLS signaling capability, without MPLS encapsulation) in 978 addition to the functionality described in categories 1 and 2 979 described above. Single-sided signaling [SINGLE-SIDED] may be used to 980 distribute Q-in-Q tags. 982 It should be noted that since the Ethernet access network can have 983 any arbitrary topology, standard 802.1D Spanning Tree Protocol (STP) 984 may be required for loop detection and prevention. However, the use 985 of spanning tree is topology dependent and may or may not be 986 required. 988 The connectivity within the service provider core is unchanged. Thus, 989 a PE-rs may need to run STP on its Ethernet access interfaces and 990 split-horizon on its MPLS/IP network interfaces. In a topology where 991 MTU-s devices are directly connected to PE-rs devices, STP is not 992 required on the access network. 994 The following figure shows a VPLS network and several possible ways 995 of connecting customer CE devices to the network. As it can be seen 996 CEs can be either connected directly to PE-rs (or PE-r) or they can 997 be first aggregated by an MTU-s and then connected to PE-rs or they 998 can be connected via an Ethernet Access network to the PE-rs. 1000 +----+ +------+ +----+ 1001 +CE1 +--+ +---|MTU-s |----|CE2 | 1002 +----+ | ........................ | +------+ +----+ 1003 VPLS A | +------+ +------+ | | VPLS A 1004 +--| PE-rs|-- Service ----|PE-rs |-+ | +----+ 1005 +------+ Provider +------+ +-------|CE2'| 1006 / . Backbone . \ +----+ 1007 / . | . \ +-----+ VPLS B 1008 +----+ / . | . \ / Ether \ 1009 +CE1'+--+ . | . +--| Access | 1010 +----+ . +-----+ . | Network | 1011 VPLS B .........|PE-rs|........ \ / 1012 +-----+ +-----+ 1013 | | 1014 | | 1015 +----+ +------+ +----+ 1016 |CE3 | |MTU-s |---|CE3'| 1017 +----+ +------+ +----+ 1018 VPLS A | VPLS B 1019 | 1020 | +----+ 1021 +------|CE4'| 1022 +----+ 1023 VPLS B 1025 10.1. Port-based v.s. VLAN-based VPLS operation 1027 Where a customer uses a port-based VPLS service, all customer 1028 traffic received from that port, regardless of whether it has vlan 1029 tags or not, is directed to a single VPLS instance. In the MTU-s, 1030 this is done by assigning a service provider VLAN (SP-VLAN) tag to 1031 that customer port. If the customer traffic is already tagged, the 1032 SP-VLAN serves as the outer tag. The SP-VLAN tag serves as a VPLS 1033 identifier which identifies a FIB associated with that particular 1034 VPLS. MAC address learning is done using unqualified learning. The 1035 customer packets are then forwarded through the FIB to the 1036 appropriate pseudowire based on the destination MAC address. In the 1037 reverse direction, the pseudowire tag identifies the VPLS instance 1038 and thus the FIB. The packet is forwarded to the proper Ethernet 1039 port based on the destination MAC address. When the packet leaves 1040 the PE-rs toward the MTU-s, it will be appended with the SP-VLAN tag 1041 associated with that VPLS. 1043 Where a customer uses a VLAN-based VPLS service, if the traffic 1044 within each customer VLAN is to be isolated from each other and each 1045 one has its own broadcast domain, then each customer VLAN is mapped 1046 to a single VPLS instance. If the Service Provider assigns the 1047 customer VLAN tags, then the Service provider can ensure the 1048 uniqueness of these VLAN tags among different customers and a given 1049 customer VLAN tag can be used as a VPLS identifier. However, if 1050 customers assigns their own VLAN tags independently, then the MTU-s 1051 MUST map each customer VLAN into a unique SP-VLAN. Subsequently, the 1052 SP-VLAN will be used as a VPLS identifier to index the proper FIB 1053 and to forward traffic based on destination MAC address. The 1054 operation of PE-rs in this case remains same as before. 1056 The following shows the Q-in-Q tunneling encapsulation which is 1057 applied when Ethernet data plane is used between MTU-s and PE-rs. 1059 0 1 2 3 1060 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 1061 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1062 | MAC Dest. Address | 1063 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1064 | MAC DA cont. | MAC Source Address | 1065 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1066 | MAC SA cont. | 1067 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1068 | Ether Type = 0x8100 | SP-VLAN |SP .1p | 1069 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1070 | Ether Type = 0x8100 | CE-VLAN |CE .1p | 1071 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1072 | Ether Type / Length | Payload | 1073 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1074 | Payload | 1075 | " | 1076 | " | 1077 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1079 11. Significant Modifications 1081 Between rev 01 and this one, the WG mailing comments and merging 1082 with draft-sajassi-vpls-architectures-00.txt led to the following 1083 changes: 1084 o update MAC TLV section to conform to 802.1d bridging 1085 o add Q-in-Q section 1086 o remove qualified learning 1087 o align with L2 framework terminology 1088 o clean up descriptions, typos 1089 o updated references 1091 12. Acknowledgments 1093 We wish to thank Joe Regan, Kireeti Kompella, Anoop Ghanwani, Joel 1094 Halpern, Rick Wilder,Jim Guichard, Steve Phillips, Norm Finn, and 1095 Eric Rosen for their valuable feedback. 1097 13. Security Considerations 1099 Security issues resulting from this draft will be discussed in 1100 greater depth at a later point. It is recommended in [RFC3036] that 1101 LDP security (authentication) methods be applied. This would 1102 prevent unauthorized participation by a PE in a VPLS. Traffic 1103 separation for a VPLS is effected by using VC labels. However, for 1104 additional levels of security, the customer MAY deploy end-to-end 1105 security, which is out of the scope of this draft. 1107 14. Intellectual Property Considerations 1109 This document is being submitted for use in IETF standards 1110 discussions. 1112 15. Full Copyright Statement 1114 Copyright (C) The Internet Society (2001). All Rights Reserved. 1115 This document and translations of it may be copied and furnished to 1116 others, and derivative works that comment on or otherwise explain it 1117 or assist in its implementation may be prepared, copied, published 1118 and distributed, in whole or in part, without restriction of any 1119 kind, provided that the above copyright notice and this paragraph 1120 are included on all such copies and derivative works. However, this 1121 document itself may not be modified in any way, such as by removing 1122 the copyright notice or references to the Internet Society or other 1123 Internet organizations, except as needed for the purpose of 1124 developing Internet standards in which case the procedures for 1125 copyrights defined in the Internet Standards process must be 1126 followed, or as required to translate it into languages other than 1127 English. 1129 The limited permissions granted above are perpetual and will not be 1130 revoked by the Internet Society or its successors or assigns. 1132 This document and the information contained herein is provided on an 1133 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1134 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1135 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1136 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1137 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1139 16. References 1141 [MARTINI-ENCAP] "Encapsulation Methods for Transport of Ethernet 1142 Frames Over IP and MPLS", draft-martini-ethernet-encap-mpls-00.txt, 1143 Work in progress, April 2002. 1145 [MARTINI-SIG] "Transport of Layer 2 Frames Over MPLS", draft- 1146 martini-l2circuit-trans-mpls-09.txt, Work in progress, April 2002. 1148 [802.1D-ORIG] Original 802.1D - ISO/IEC 10038, ANSI/IEEE Std 802.1D- 1149 1993 "MAC Bridges". 1151 [802.1D-REV] 802.1D - "Information technology - Telecommunications 1152 and information exchange between systems - Local and metropolitan 1153 area networks - Common specifications - Part 3: Media Access Control 1154 (MAC) Bridges: Revision. This is a revision of ISO/IEC 10038: 1993, 1155 802.1j-1992 and 802.6k-1992. It incorporates P802.11c, P802.1p and 1156 P802.12e." ISO/IEC 15802-3: 1998. 1158 [802.1Q] 802.1Q - ANSI/IEEE Draft Standard P802.1Q/D11, "IEEE 1159 Standards for Local and Metropolitan Area Networks: Virtual Bridged 1160 Local Area Networks", July 1998. 1162 [BGP-VPN] Rosen and Rekhter, "BGP/MPLS VPNs". RFC 2547, March 1999 1164 [VPLS-REQ] "Requirements for Virtual Private LAN Services (VPLS)", 1165 draft-ietf-ppvpn-vpls-requirements-00.txt Work in progress. 1167 [RFC3036] "LDP Specification", L. Andersson, et al. RFC 3036. 1168 January 2001. 1170 [SINGLE-SIDED] "Single-Sided Signaling for L2VPN", draft-rosen- 1171 ppvpn-l2-signaling-01.txt, Work in Progress, February 2002. 1173 [DIR-AUTO] "DNS/LDP Based VPLS", Juha Heinanen, draft-heinanen-dns- 1174 ldp-vpls-00.txt, Work in Progress, January 2002. 1176 [BGP-AUTO] "Using BGP as an Auto-Discovery Mechanism for Network- 1177 based VPNs", Ould-Brahim, et. al., draft-ietf-ppvpn-bgpvpn-auto- 1178 02.txt, Work in Progress, January 2002. 1180 [FINN-BRIDGING] "Bridging and VPLS", draft-finn-ppvpn-bridging-vpls- 1181 00.txt, Work in Progress, June 2002. 1183 17. Authors' Addresses 1185 Marc Lasserre 1186 Riverstone Networks 1187 5200 Great America Pkwy 1188 Santa Clara, CA 95054 1189 Email: marc@riverstonenet.com 1191 Vach Kompella 1192 TiMetra Networks 1193 274 Ferguson Dr. 1194 Mountain View, CA 94043 1195 Email: vkompella@timetra.com 1197 Sunil Khandekar 1198 TiMetra Networks 1199 274 Ferguson Dr. 1200 Mountain View, CA 94043 1201 Email: sunil@timetra.com 1203 Nick Tingle 1204 TiMetra Networks 1205 274 Ferguson Dr. 1206 Mountain View, CA 94043 1207 Email: ntingle@timetra.com 1209 Ali Sajassi 1210 Cisco Systems, Inc. 1211 170 West Tasman Drive 1212 San Jose, CA 95134 1213 Email: sajassi@cisco.com 1215 Loa Andersson 1216 Utfors Bredband AB 1217 Rasundavagen 12 169 29 Solna 1218 Email: loa.andersson@utfors.se 1220 Pascal Menezes 1221 Terabeam 1222 2300 Seventh Ave 1223 Seattle, WA 98121 1224 Email: Pascal.Menezes@Terabeam.com 1226 Pierre Lin 1227 Andrew Smith 1228 Consultant 1229 Email: ah_smith@acm.org 1231 Giles Heron 1232 PacketExchange Ltd. 1233 The Truman Brewery 1234 91 Brick Lane 1235 LONDON E1 6QL 1236 United Kingdom 1237 Email: giles@packetexchange.net 1239 Juha Heinanen 1240 Song Networks, Inc. 1241 Email: jh@lohi.eng.song.fi 1243 Tom S. C. Soon 1244 SBC Technology Resources Inc. 1245 4698 Willow Road 1246 Pleasanton, CA 94588 1247 Email: sxsoon@tri.sbc.com 1249 Yetik Serbest 1250 SBC Communications 1251 9505 Arboretum Blvd. 1252 Austin TX 78759 1253 serbest@tri.sbc.com 1255 Eric Puetz 1256 SBC Communications 1257 9505 Arboretum Blvd. 1258 Austin TX 78759 1259 puetz@tri.sbc.com 1261 Ron Haberman 1262 Masergy Inc. 1263 2901 Telestar Ct. 1264 Falls Church, VA 22042 1265 Email: ronh@masergy.com 1267 Luca Martini 1268 Level 3 Communications, LLC. 1269 1025 Eldorado Blvd. 1270 Broomfield, CO, 80021 1271 Email: luca@level3.net 1273 Nick Slabakov 1274 Riverstone Networks 1275 5200 Great America Pkwy 1276 Santa Clara, CA 95054 1277 Email: nslabakov@riverstonenet.com 1278 Rob Nath 1279 Riverstone Networks 1280 5200 Great America Pkwy 1281 Santa Clara, CA 95054 1282 Email: rnath@riverstonenet.com 1284 Vasile Radaoca 1285 Nortel Networks 1286 600 Technology Park 1287 Billerica MA 01821 1288 Email: vasile@nortelnetworks.com