idnits 2.17.1 draft-lasserre-vkompella-ppvpn-vpls-01.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == 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 a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 10. Security Considerations' ) ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. == 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 230: '...earning, a bridged PDU MUST conform to...' RFC 2119 keyword, line 269: '... Each PE MUST create a rooted tree t...' RFC 2119 keyword, line 270: '... L2 VPN. Each PE MUST support a "split...' RFC 2119 keyword, line 271: '...s, that is, a PE MUST NOT forward traf...' RFC 2119 keyword, line 423: '... It MAY be desirable to remove MAC a...' (17 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 (March 2002) is 8078 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? 'MARTINI-ENCAP' on line 950 looks like a reference -- Missing reference section? 'VPLS-REQ' on line 973 looks like a reference -- Missing reference section? 'BGP-VPN' on line 971 looks like a reference -- Missing reference section? 'MARTINI-SIG' on line 954 looks like a reference -- Missing reference section? '8' on line 318 looks like a reference -- Missing reference section? 'VPLS' on line 737 looks like a reference -- Missing reference section? 'SHAH-PECE' on line 979 looks like a reference -- Missing reference section? 'Martini-Encap' on line 782 looks like a reference -- Missing reference section? 'RFC3036' on line 976 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft Document Marc Lasserre 3 draft-lasserre-vkompella-ppvpn-vpls-01.txt Riverstone Networks 4 Vach Kompella 5 Nick Tingle 6 Sunil Khandekar 7 Timetra Networks 9 Pascal Menezes Loa Andersson 10 Terabeam Networks Utfors 12 Andrew Smith Pierre Lin 13 Consultant Yipes Communication 15 Juha Heinanen Giles Heron 16 Song Networks PacketExchange Ltd. 18 Ron Haberman Tom S.C. Soon 19 Masergy, Inc. SBC Communications 21 Nick Slabakov Luca Martini 22 Rob Nath Level 3 23 Riverstone Networks Communications 25 Expires: September 2002 March 2002 27 Virtual Private LAN Services over MPLS 28 draft-lasserre-vkompella-ppvpn-vpls-01.txt 30 1. Status of this Memo 32 This document is an Internet-Draft and is in full conformance 33 with all provisions of Section 10 of RFC2026. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF), its areas, and its working groups. Note that 37 other groups may also distribute working documents as Internet- 38 Drafts. 40 Internet-Drafts are draft documents valid for a maximum of six 41 months and may be updated, replaced, or obsoleted by other documents 42 at any time. It is inappropriate to use Internet-Drafts as 43 reference material or to cite them other than as "work in progress." 45 The list of current Internet-Drafts can be accessed at 46 http://www.ietf.org/ietf/1id-abstracts.txt 47 The list of Internet-Draft Shadow Directories can be accessed at 48 http://www.ietf.org/shadow.html. 50 2. Abstract 52 This document describes a virtual private LAN service (VPLS) 53 solution over MPLS, also known as Transparent LAN Services (TLS). 54 VPLS simulates an Ethernet virtual 802.1D bridge [802.1D-ORIG] 55 [802.1D-REV] for a given set of users. It delivers a layer 2 56 broadcast domain that is fully capable of learning and forwarding on 57 Ethernet MAC addresses that is closed to a given set of users. Many 58 VLS services can be supported from a single PE node. 60 3. Conventions 62 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 63 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 64 document are to be interpreted as described in RFC 2119 66 Placement of this Memo in Sub-IP Area 68 RELATED DOCUMENTS 70 http:// search.ietf.org/internet-drafts/draft-martini-l2circuit- 71 trans-mpls-06.txt 73 http://search.ietf.org/internet-drafts/draft-martini-l2circuit- 74 encap-mpls-02.txt 76 http://search.ietf.org/internet-drafts/draft-augustyn-ppvpn-vpls- 77 reqmts-00.txt 79 WHERE DOES THIS FIT IN THE PICTURE OF THE SUB-IP WORK 81 PPVPN 83 WHY IS IT TARGETTED AT THIS WG 85 The charter of the PPVPN WG includes L2 VPN services and this draft 86 specifies a model for Ethernet L2 VPN services over MPLS. 88 JUSTIFICATION 90 Existing Internet drafts specify how to provide point-to-point 91 Ethernet L2 VPN services over MPLS. This draft defines how 92 multipoint Ethernet services can be provided. 94 Table of Contents 96 1. Status of this Memo.............................................1 97 2. Abstract........................................................2 98 3. Conventions.....................................................2 99 4. Overview........................................................3 100 5. Bridging Model for MPLS.........................................4 101 5.1. Flooding and Forwarding.......................................5 102 5.2. Address Learning..............................................5 103 5.3. LSP Topology..................................................6 104 5.4. Loop free L2 VPN..............................................6 105 5.5. LDP Based Signaling...........................................6 106 5.6. Ethernet VPLS VC Type.........................................8 107 5.6.1. VPLS Encapsulation actions..................................8 108 5.6.2. VPLS Learning actions.......................................8 109 5.6.3. VPLS Forwarding actions.....................................9 110 6. MAC Address Withdrawal..........................................9 111 6.1. MAC TLV......................................................10 112 6.2. Address Withdraw Message Containing MAC TLV..................11 113 7. Operation of a VPLS............................................11 114 7.1. MAC Address Aging............................................12 115 8. A Hierarchical VPLS Model......................................12 116 8.1. Hierarchical connectivity....................................13 117 8.1.1. Spoke connectivity for bridging-capable devices............13 118 8.1.2. Advantages of spoke connectivity...........................15 119 8.1.3. Spoke connectivity for non-bridging devices................16 120 8.2. Redundant Spoke Connections..................................17 121 8.2.1. Dual-homed MTU device......................................17 122 8.2.2. Failure detection and recovery.............................18 123 8.3. Multi-domain VPLS service....................................19 124 9. Acknowledgments................................................19 125 10. Security Considerations.......................................19 126 11. Intellectual Property Considerations..........................19 127 12. Full Copyright Statement......................................19 128 13. References....................................................20 129 14. Authors' Addresses............................................21 131 4. Overview 133 Ethernet has become a predominant technology initially for Local 134 Area Networks (LANs) and now as an access technology, specifically 135 in metropolitan networks. Ethernet ports or IEEE VLANs are dedicated 136 to customers on Provider Edge (PE) routers acting as LERs. Customer 137 traffic gets mapped to a specific MPLS L2 VPN by configuring L2 FECs 138 based upon the input port and/or VLAN. 140 Broadcast and multicast services are available over traditional 141 LANs. MPLS does not support such services currently. Sites that 142 belong to the same broadcast domain and that are connected via an 143 MPLS network expect broadcast, multicast and unicast traffic to be 144 forwarded to the proper location(s). This requires MAC address 145 learning/aging on a per LSP basis, packet replication across LSPs 146 for multicast/broadcast traffic and for flooding of unknown unicast 147 destination traffic. 149 [MARTINI-ENCAP] defines how to carry L2 PDUs over point-to-point 150 MPLS LSPs, called VC LSPs. Such VC LSPs can be carried across MPLS 151 or GRE tunnels. This document describes extensions to [MARTINI- 152 ENCAP] for transporting Ethernet/802.3 and VLAN [802.1Q] traffic 153 across multiple sites that belong to the same L2 broadcast domain. 154 Note that the same model can be applied to other 802.1 technologies. 155 It describes a simple and scalable way to offer Virtual LAN 156 services, including the appropriate flooding of Broadcast, Multicast 157 and unknown unicast destination traffic over MPLS, without the need 158 for address resolution servers or other external servers, as 159 discussed in [VPLS-REQ]. 161 The following discussion applies to devices that serve as Label Edge 162 Routers (LERs) on an MPLS network that is VPLS capable. It will not 163 discuss the behavior of transit Label Switch Routers (LSRs) that are 164 considered a part of MPLS network. The MPLS network provides a 165 number of Label Switch Paths (LSPs) that form the basis for 166 connections between LERs attached to the same MPLS network. The 167 resulting set of interconnected LERs forms a private MPLS VPN where 168 each LSP is uniquely identified at each MPLS interface by a label. 170 5. Bridging Model for MPLS 172 An MPLS interface acting as a bridge must be able to flood, forward, 173 and filter bridged frames. 175 +----+ +----+ 176 + C1 +---+ ........................... +---| C1 | 177 +----+ | . . | +----+ 178 Site A | +----+ +----+ | Site B 179 +---| PE |---- MPLS Cloud ----| PE |---+ 180 +----+ | +----+ 181 . | . 182 . +----+ . 183 ..........| PE |........... 184 +----+ ^ 185 | | 186 | +-- Logical bridge 187 +----+ 188 | C1 | 189 +----+ 190 Site C 192 The set of PE devices interconnected via transport tunnels appears 193 as a single 802.1D bridge/switch to customer C1. Each PE device will 194 learn remote MAC addresses on LSPs (and keeps learning directly 195 attached MAC addresses on customer facing ports). We note here that 196 while this document shows specific examples using MPLS transport 197 tunnels, other tunnels that can be used by pseudo-wires, e.g., GRE, 198 L2TP, IPSEC, etc., can also be used, as long as the sender PE can be 199 identified, since this is used in the learning algorithm. 201 The scope of the VPLS lies within the PEs in the service provider 202 network, highlighting the fact that apart from customer service 203 delineation, the form of access to a customer site is not relevant 204 to the VPLS [VPLS-REQ]. 206 The PE device is typically an edge router capable of running a 207 signaling protocol and/or routing protocols to exchange VC label 208 information. In addition, it is capable of setting up transport 209 tunnels to other PEs to deliver VC LSP traffic. 211 5.1. Flooding and Forwarding 213 Flooding within the service provider network is performed by sending 214 unknown unicast and multicast frames to all relevant PE nodes 215 participating in the VPLS. In the MPLS environment this means 216 sending the PDU through each relevant VC LSP. 218 Note that multicast frames do not necessarily have to be sent to all 219 VPN members. For simplicity, the default approach of broadcasting 220 multicast frames can be used. Extensions explaining how to interact 221 with 802.1 GMRP protocol, IGMP snooping and static MAC multicast 222 filters will be discussed in a future revision. 224 To forward a frame, a bridge must be able to associate a destination 225 MAC address with a VC LSP. It is unreasonable and perhaps impossible 226 to require bridges to statically configure an association of every 227 possible destination MAC address with a VC LSP. Therefore, VPLS 228 bridges must provide enough information to allow an MPLS interface 229 to dynamically learn about foreign destinations beyond the set of 230 LSRs. To accomplish dynamic learning, a bridged PDU MUST conform to 231 the encapsulation described within [MARTINI-ENCAP]. 233 5.2. Address Learning 235 Unlike BGP VPNs [BGP-VPN], reachability information does not need to 236 be advertised and distributed via a control plane. Reachability is 237 obtained by standard learning bridge functions in the data plane. 239 Since VC LSPs are uni-directional, two LSPs of opposite directions 240 are required to form a logical bi-directional link. When a new MAC 241 address is learned on an inbound LSP, it needs to be associated with 242 the outbound LSP that is part of the same pair. The state of this 243 logical link can be considered as up as soon as both incoming and 244 outgoing LSPs are established. Similarly, it can be considered as 245 down as soon as one of these two LSPs is torn down. 246 Standard learning, filtering and forwarding actions, as defined in 247 [802.1D-ORIG], [802.1D-REV] and [802.1Q], are required when a 248 logical link state changes. 250 5.3. LSP Topology 252 PE routers typically run an IGP between them, and are assumed to 253 have the capability to establish MPLS tunnels. Tunnel LSPs are set 254 up between PEs to aggregate traffic. VC LSPs are signaled to 255 demultiplex the L2 encapsulated packets that traverse the tunnel 256 LSPs. 258 In this Ethernet L2VPN, it becomes the responsibility of the service 259 provider to create the loop free topology, since the PEs have to 260 examine the Layer 2 fields of the packets, unlike Frame Relay or 261 ATM, where the termination point becomes the CE node. Therefore, 262 for the sake of simplicity, we assume that the topology of a VPLS is 263 a full mesh of tunnel and VC LSPs. 265 5.4. Loop free L2 VPN 267 For simplicity, a full mesh of LSPs is established between PEs. 269 Each PE MUST create a rooted tree to every other PE router that 270 serve the same L2 VPN. Each PE MUST support a "split-horizon" scheme 271 in order to prevent loops, that is, a PE MUST NOT forward traffic 272 from one VC LSP to another in the same VPN (since each PE has direct 273 connectivity to all other PEs in the same VPN). 275 Note that customers are allowed to run STP such as when a customer 276 has a back door link used for backup. In such a case STP BPDUs are 277 simply tunneled through the MPLS cloud. 279 5.5. LDP Based Signaling 281 In order to establish a full mesh of VC LSPs, all PEs in a VPLS must 282 have a full mesh of LDP sessions. 284 Once an LDP session has been formed between two PEs, all VC LSPs are 285 signaled over this session. 287 In [MARTINI-SIG], the L2 VPN information is carried in a Label 288 Mapping message sent in downstream unsolicited mode, which contains 289 the following VC FEC TLV. VC, C, VC Info Length, Group ID, 290 Interface parameters are as defined in [MARTINI-SIG]. 292 0 1 2 3 293 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 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | VC tlv |C| VC Type |VC info Length | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | Group ID | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 | VC ID | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 | Interface parameters | 302 | " | 303 | " | 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 This document defines a new VC type value in addition to the 307 following values already defined in [MARTINI-SIG]: 309 VC Type Description 311 0x0001 Frame Relay DLCI 312 0x0002 ATM AAL5 VCC transport 313 0x0003 ATM transparent cell transport 314 0x0004 Ethernet VLAN 315 0x0005 Ethernet 316 0x0006 HDLC 317 0x0007 PPP 318 0x8008 CEM [8] 319 0x0009 ATM VCC cell transport 320 0x000A ATM VPC cell transport 321 0x000B Ethernet VPLS 323 VC types 0x0004 and 0x0005 identify VC LSPs that carry VLAN tagged 324 and untagged Ethernet traffic respectively, for point-to-point 325 connectivity. 327 We define a new VC type, Ethernet VPLS, with codepoint 0x000B to 328 identify VC LSPs that carry Ethernet traffic for multipoint 329 connectivity. The Ethernet VC Type is described below. 331 For VC types 0x0001 to 0x000A, The VC ID identifies a particular VC. 332 For the VPLS VC type, the VC ID is a VPN identifier globally unique 333 within a service provider domain. 335 Note that the VCID as specified in [MARTINI_SIG] is a service 336 identifier, identifying a service emulating a point-to-point virtual 337 circuit. In a VPLS, the VCID is a single service identifier, 338 identifying an emulated LAN segment. 340 5.6. Ethernet VPLS VC Type 341 5.6.1. VPLS Encapsulation actions 343 In a VPLS, a customer Ethernet packet without preamble is 344 encapsulated with a header as defined in [MARTINI-ENCAP]. A 345 customer Ethernet packet is defined as follows: 347 - If the packet, as it arrives at the PE, has an encapsulation 348 that is used by the local PE as a service delimiter, then that 349 encapsulation is stripped before the packet is sent into the 350 VPLS. As the packet exits the VPLS, the packet may have a 351 service-delimiting encapsulation inserted. 353 - If the packet, as it arrives at the PE, has an encapsulation 354 that is not service delimiting, then it is a customer packet 355 whose encapsulation should not be modified by the VPLS. This 356 covers, for example, a packet that carries customer specific 357 VLAN-Ids that the service provider neither knows about nor 358 wants to modify. 360 By following the above rules, the Ethernet packet that traverses a 361 VPLS is always a customer Ethernet packet. Note that the two 362 actions, at ingress and egress, of dealing with service delimiters 363 are local actions that neither PE has to signal to the other. They 364 allow, for example, a mix-and-match of VLAN tagged and untagged 365 services at either end, and do not carry across a VPLS a VLAN tag 366 that may have only local significance. The service delimiter may be 367 a VC label also, whereby an Ethernet VC given by [MARTINI-ENCAP] can 368 serve as the access side connection into a PE. An RFC1483 PVC 369 encapsulation could be another service delimiter. By limiting the 370 scope of locally significant encapsulations to the edge, 371 hierarchical VPLS models can be developed that provide the 372 capability to network-engineer VPLS deployments, as described below. 374 5.6.2. VPLS Learning actions 376 Learning is done based on the customer Ethernet packet, as defined 377 above. The Forwarding Information Base (FIB) keeps track of the 378 mapping of customer Ethernet packet addressing and the appropriate 379 VC label to use. We define two modes of learning: qualified and 380 unqualified learning. 382 In qualified learning, the learning decisions at the PE are based on 383 the customer Ethernet packet's MAC address and VLAN tag, if one 384 exists. If no VLAN tag exists, the default VLAN is assumed. 386 Effectively, within one VPLS, there are multiple logical FIBs, one 387 for each customer VLAN tag identified in a customer packet. 389 In unqualified learning, learning is based on a customer Ethernet 390 packet's MAC address only. In other words, at any PE, there is only 391 one FIB per VPLS, which maps the MAC address in a customer Ethernet 392 packet to a VC label. 394 5.6.3. VPLS Forwarding actions 396 The forwarding decisions taken at a PE couple with the learning 397 mode. When using unqualified learning, unknown destination packets 398 are flooded to the entire VPLS. When using qualified learning, the 399 scope of the flooding domain may be reduced (to the scope of the 400 customer VLAN). How this may be achieved is outside the scope of 401 this draft. 403 It is important to ensure that the above learning and forwarding 404 modes are used consistently across the VPLS. For example, when the 405 intention is to use qualified learning, duplicate MAC addresses with 406 different VLAN tags should not trigger re-learn events, which will 407 lead to incorrect forwarding decisions. We propose that signaling 408 an optional parameter in the VC FEC will provide an adequate guard 409 against such misconfigurations. By default, the behavior is 410 unqualified learning. 412 In order to signal the learning mode, we introduce a new interface 413 parameter [MARTINI-SIG]. 415 Optional Interface Parameter 416 0x06 VPLS Learning Mode 417 Length: 1 byte. 418 Value: 0 - unqualified learning 419 1 - qualified learning 421 6. MAC Address Withdrawal 423 It MAY be desirable to remove MAC addresses that have been 424 dynamically learned for faster convergence. 426 We introduce an optional MAC TLV that is used to specify a list of 427 MAC addresses that can be removed using the Address Withdraw 428 Message. 430 The Address Withdraw message with MAC TLVs MAY be supported in order 431 to uninstall learned MAC addresses that have moved or gone away more 432 quickly. Once a MAC address is unlearned, re-learning occurs 433 through flooding. 435 6.1. MAC TLV 437 MAC addresses to be unlearned can be signaled using an LDP Address 438 Withdraw Message. We define a new TLV, the MAC TLV. Its format is 439 described below. The encoding of a MAC TLV address is a 2-byte 440 802.1Q tag, followed by the 6-byte MAC address encoding specified by 441 IEEE 802 documents [g-ORIG] [802.1D-REV]. The 802.1Q tag and the 442 MAC address MUST appear in pairs. If no tag is required, the value 443 of the tag field MUST be zero. 445 0 1 2 3 446 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 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 |U|F| Type | Length | 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 | Reserved | 802.1Q Tag #1 | 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 | MAC address #1 | 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 | ... | 802.1Q Tag #n | 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 | MAC address #n | 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 U bit 460 Unknown bit. This bit MUST be set to 0. If the MAC address 461 format is not understood, then the TLV is not understood, and MUST 462 be ignored. 464 F bit 465 Forward bit. This bit MUST be set to 0. Since the LDP 466 mechanism used here is Targeted, the TLV MUST NOT be forwarded. 468 Type 469 Type field. This field MUST be set to 0x0404 (subject to IANA 470 approval). This identifies the TLV type as MAC TLV. 472 Length 473 Length field. This field specifies the total length of the 474 TLV, including the Type and Length fields. 476 Reserved 477 Reserved bits. They MUST NOT be interpreted at the receiver, 478 and MUST be set to zero by the sender. 480 802.1Q Tag 481 The 802.1Q Tag. The value MUST be zero if the Ethernet VLAN 482 encapsulation is used. If the Ethernet encapsulation is used, and 483 the Ethernet address is associated with a VLAN, it MUST be set to 484 the VLAN tag. If the Ethernet encapsulation is used, and the MAC 485 address is not associated with a VLAN, it MUST be set to zero. 486 Since an 802.1Q tag is 12-bits, the high 4 bits of the field MUST be 487 set to zero. 489 MAC Address 490 The MAC address being removed. 492 The LDP Address Withdraw Message contains a FEC TLV (to identify the 493 VPLS in consideration), a MAC Address TLV and optional parameters. 494 No optional parameters have been defined for the MAC Address 495 Withdraw signaling. 497 6.2. Address Withdraw Message Containing MAC TLV 499 When MAC addresses are being removed explicitly, e.g., an adjacent 500 CE router has been disconnected, an Address Withdraw Message can be 501 sent with the list of MAC addresses to be withdrawn. 503 The processing for MAC TLVs received in an Address Withdraw Message 504 is: 505 For each (VLAN tag, MAC address) pair in the TLV: 506 - Remove the association between the (VLAN tag, MAC address) pair 507 and VC label. It does not matter whether the MAC address was 508 installed as a static or dynamic address. 510 The scope of a MAC TLV is the VPLS specified in the FEC TLV in the 511 Address Withdraw Message. 513 The number of MAC addresses can be deduced from the length field in 514 the TLV. The address list MAY be empty. This tells the receiving 515 LSR to delete any MAC addresses learned from the sending LSR for the 516 VPLS specified by the FEC TLV. 518 7. Operation of a VPLS 520 We show here an example of how a VPLS works. The following 521 discussion uses the figure below, where a VPLS has been set up 522 between PE1, PE2 and PE3. 524 Initially, the VPLS is set up so that PE1, PE2 and PE3 have a full- 525 mesh of tunnels between them for carrying tunneled traffic. The 526 VPLS service is assigned a VCID (a 32-bit quantity that is unique 527 across the provider network across all VPLSs). (Allocation of 528 domain-wide unique VCIDs is outside the scope of this draft.) 530 For the above example, say PE1 signals VC Label 102 to PE2 and 103 531 to PE3, and PE2 signals VC Label 201 to PE1 and 203 to PE3. 533 Assume a packet from A1 is bound for A2. When it leaves CE1, say it 534 has a source MAC address of M1 and a destination MAC of M2. If PE1 535 does not know where M2 is, it will multicast the packet to PE2 and 536 PE3. When PE2 receives the packet, it will have an inner label of 537 201. PE2 can conclude that the source MAC address M1 is behind PE1, 538 since it distributed the label 201 to PE1. It can therefore 539 associate MAC address M1 with VC Label 102. 540 ----- 541 / A1 \ 542 ---- ----CE1 | 543 / \ -------- ------- / | | 544 | A2 CE2- / \ / PE1 \ / 545 \ / \ / \---/ \ ----- 546 ---- ---PE2 | 547 | Service Provider Network | 548 \ / \ / 549 ----- PE3 / \ / 550 |Agg|_/ -------- ------- 551 -| | 552 ---- / ----- ---- 553 / \/ \ / \ CE = Customer Edge Router 554 | A3 CE3 --C4 A4 | PE = Provider Edge Router 555 \ / \ / Agg = Layer 2 Aggregation 556 ---- ---- 558 7.1. MAC Address Aging 560 PEs that learn remote MAC addresses need to have an aging mechanism 561 to remove unused entries associated with a VC Label. This is 562 important both for conservation of memory as well as for 563 administrative purposes. For example, if a customer site A is shut 564 down, eventually, the other PEs should unlearn A's MAC address. 566 As packets arrive, MAC addresses are remembered. The aging timer 567 for MAC address M SHOULD be reset when a packet is received with 568 source MAC address M. 570 8. A Hierarchical VPLS Model 572 The solution described above requires a full mesh of tunnel LSPs 573 between all the PE routers that participate in the VPLS service. 574 For each VPLS service, n*(n-1) VCs must be setup between the PE 575 routers. While this creates signaling overhead, the real detriment 576 to large scale deployment is the packet replication requirements for 577 each provisioned VCs on a PE router. Hierarchical connectivity, 578 described in this document reduces signaling and replication 579 overhead to allow large scale deployment. 581 In many cases, service providers place smaller edge devices in 582 multi-tenant buildings and aggregate them into a PE device in a 583 large Central Office (CO) facility. In some instances, standard IEEE 584 802.1q (Dot 1Q) tagging techniques may be used to facilitate mapping 585 CE interfaces to PE VPLS access points. When this is done, a 586 hierarchical architecture is created outside the context of VPLS; no 587 service level signaling is present between the PE router and the MTU 588 bridge. 590 It is often beneficial to extend the VPLS service tunneling 591 techniques into the MTU domain. This can be accomplished by 592 treating the MTU device as a PE device and provisioning VCs between 593 it and every other edge, as an basic VPLS. An alternative is to 594 utilize [MARTINI-ENCAP] VCs between the MTU and selected VPLS 595 enabled PE routers. This section focuses on this alternative 596 approach. The [VPLS] mesh core tier VCs (Hub) are augmented with 597 access tier VCs (Spoke) to form a two tier hierarchical VPLS (H- 598 VPLS). 600 Spoke VCs may be expanded to include any L2 tunneling mechanism, 601 expanding the scope of the first tier to include non-bridging VPLS 602 PE routers. The non-bridging PE router would extend a Spoke VC from 603 a Layer-2 switch that connects to it, through the service core 604 network, to a bridging VPLS PE router supporting Hub VCs. We also 605 describe how VPLS-challenged nodes and low-end CEs without MPLS 606 capabilities may participate in a hierarchical VPLS. 608 8.1. Hierarchical connectivity 610 This section describes the hub and spoke connectivity model and 611 describes the requirements of the bridging capable and non-bridging 612 MTU devices for supporting the spoke connections. 614 For rest of this discussion we will refer to a bridging capable MTU 615 device as MTU-s and a non-bridging capable PE device as PE-r. A 616 routing and bridging capable device will be referred to as PE-rs. 618 8.1.1. Spoke connectivity for bridging-capable devices 620 As shown in the figure below, consider the case where an MTU-s 621 device has a single connection to the PE-rs device placed in the CO. 622 The PE-rs devices are connected in a basic VPLS full mesh. To 623 participate in the VPLS service, MTU-s device creates a single 624 point-to-point tunnel LSP to the PE-rs device in the CO. We will 625 call this the spoke connection. For each VPLS service, a single 626 spoke VC is setup between the MTU-s and the PE-rs based on [MARTINI- 627 SIG] and [MARTINI-ENCAP]. Unlike traditional [MARTINI-ENCAP] VCs 628 that terminate on a physical (or a VLAN-tagged logical) port at each 629 end, the spoke VC terminates on a virtual bridge instance on the 630 MTU-s and the PE-rs devices. The MTU-s device and the PE-rs device 631 treat each spoke connection like an access port of the VPLS service. 632 On access ports, the combination of the physical port and the VLAN 633 tag is used to associate the traffic to a VPLS instance while the VC 634 label is used to associate the traffic from the virtual spoke port 635 with a VPLS instance, followed by a standard L2 lookup to identify 636 which customer port the frame needs to be sent to. 638 The signaling and association of the spoke connection to the VPLS 639 service may be done by introducing extensions to the LDP signaling 640 as specified in [SHAH-PECE]. 641 PE2-rs 642 ------ 643 / \ 644 | -- | 645 | / \ | 646 CE-1 | \B / | 647 \ \ -- / 648 \ /------ 649 \ MTU-s PE1-rs / | 650 \ ------ ------ / | 651 / \ / \ / | 652 | \ -- | VC-1 | -- |---/ | 653 | / \--|- - - - - - - - - - - |--/ \ | | 654 | \B / | | \B / | | 655 \ /-- / \ -- / ---\ | 656 /----- ------ \ | 657 / \ | 658 ---- \ ------ 659 |Agg | / \ 660 ---- | -- | 661 / \ | / \ | 662 CE-2 CE-3 | \B / | 663 \ -- / 664 MTU-s = Bridging capable MTU ------ 665 PE-rs = VPLS capable PE PE3-rs 667 -- 668 / \ 669 \B / = Virtual VPLS(Bridge)Instance 670 -- 671 Agg = Layer-2 Aggregation 673 8.1.1.1. MTU-s Operation 675 MTU-s device is defined as a device that supports layer-2 switching 676 functionality and does all the normal bridging functions of learning 677 and replication on all its ports, including the virtual spoke port. 678 Packets to unknown destination are replicated to all ports in the 679 service including the virtual spoke port. Once the MAC address is 680 learned, traffic between CE1 and CE2 will be switched locally by the 681 MTU-s device saving the link capacity of the connection to the PE- 682 rs. Similarly traffic between CE1 or CE2 and any remote destination 683 is switched directly on to the spoke connection and sent to the PE- 684 rs over the point-to-point VC LSP. 686 Since the MTU-s is bridging capable, only a single VC is required 687 per VPLS instance for any number of access connections in the same 688 VPLS service. This further reduces the signaling overhead between 689 the MTU-s and PE-rs. 691 8.1.1.2. PE-rs Operation 693 The PE-rs device is a device that supports all the bridging 694 functions for VPLS service and supports the routing and MPLS 695 encapsulation, i.e. it supports all the functions described in 696 [VPLS]. The operation on the PE-rs node is identical to that 697 described in [VPLS] with one addition. A point-to-point VC 698 associated with the VPLS is regarded as a virtual port (see 699 discussion in Section 5.6.1 on service delimiting). The operation 700 on the virtual spoke port is identical to the operation on an access 701 port as described in the earlier section. As shown in the figure 702 above, each PE-rs device switches traffic between aggregated 703 [MARTINI-ENCAP] VCs that look like virtual ports and the network 704 side VPLS VCs. 706 8.1.2. Advantages of spoke connectivity 708 Spoke connectivity offers several scaling and operational advantages 709 for creating large scale VPLS implementations, while retaining the 710 ability to offer all the functionality of the VPLS service. 712 - Eliminates the need for a full mesh of tunnels and full mesh of 713 VCs per service between all devices participating in the VPLS 714 service. 715 - Minimizes signaling overhead since fewer VC-LSPs are required for 716 the VPLS service. 717 - Segments VPLS nodal discovery. MTU-s needs to be aware of only 718 the PE-rs node although it is participating in the VPLS service 719 that spans multiple devices. On the other hand, every VPLS PE-rs 720 must be aware of every other VPLS PE-rs device and all of it�s 721 locally connected MTU-s and PE-r. 722 - Addition of other sites requires configuration of the new MTU-s 723 device but does not require any provisioning of the existing MTU-s 724 devices on that service. 725 - Hierarchical connections can be used to create VPLS service that 726 spans multiple service provider domains. This is explained in a 727 later section. 729 8.1.3. Spoke connectivity for non-bridging devices 731 In some cases, a bridging PE-rs device may not be deployed in some 732 CO while a PE-r might already be deployed. If there is a need to 733 provide VPLS service from the CO where the PE-rs device is not 734 available, the service provider may prefer to use the PE-r device in 735 the interim. In this section, we explain how a PE-r device that 736 does not support any of the bridging functionality as described in 737 [VPLS] can participate in the VPLS service. 739 PE2-rs 740 ------ 741 / \ 742 | -- | 743 | / \ | 744 CE-1 | \B / | 745 \ \ -- / 746 \ /------ 747 \ PE-r PE1-rs / | 748 \ ------ ------ / | 749 / \ / \ / | 750 | \ | VC-1 | -- |---/ | 751 | ------|- - - - - - - - - - - |--/ \ | | 752 | -----|- - - - - - - - - - - |--\B / | | 753 \ / / \ -- / ---\ | 754 ------ ------ \ | 755 / \ | 756 ---- \------ 757 | Agg| / \ 758 ---- | -- | 759 / \ | / \ | 760 CE-2 CE-3 | \B / | 761 \ -- / 762 PE-r = Non-Bridging PE (router) ------ 763 PE-rs = VPLS capable PE PE3-rs 765 -- 766 / \ 767 \B / = Virtual VPLS(Bridge)Instance 768 -- 769 Agg = Layer-2 Aggregation 771 As shown in this figure, the PE-r device creates a point-to-point 772 tunnel LSP to a PE-rs device. Then for every access port that needs 773 to participate in a VPLS service, the PE-r device creates a point- 774 to-point [MARTINI-ENCAP] VC that terminates on the physical port at 775 the PE-r and terminates on the virtual bridge instance of the VPLS 776 service at the PE-rs. 778 8.1.3.1. PE-r Operation 780 The PE-r device is defined as a device that supports routing but 781 does not support any bridging functions. However, it is capable of 782 setting up [Martini-Encap] VCs between itself and the PE-rs. For 783 every port that is supported in the VPLS service, a [MARTINI-ENCAP] 784 VC is setup from the PE-r to the PE-rs. Once the VCs are setup, 785 there is no learning or replication function required on part of the 786 PE-r. All traffic received on any of the access ports is 787 transmitted on the VC. Similarly all traffic received on a VC is 788 transmitted to the access port where the VC terminates. Thus 789 traffic from CE1 destined for CE2 is switched at PE-rs and not at 790 PE-r. 792 This approach adds more overhead than the bridging capable (MTU-s) 793 spoke approach since a VC is required for every access port that 794 participates in the service versus a single VC required per service 795 (regardless of access ports) when a MTU-s type device is used. 796 However, this approach offers the advantage of offering a VPLS 797 service in conjunction with a routed internet service without 798 requiring the addition of new MTU device. 800 8.1.3.2. PE-rs Operation 802 The operation of PE-rs is independent of the type of device at the 803 other end of the spoke connection. Whether there is a bridging 804 capable device (MTU-s) at the other end of the spoke connection or 805 there is a non-bridging device (PE-r) at the other end of the spoke 806 connection, the operation of PE-rs is exactly the same. Thus, the 807 spoke connection from the PE-r is treated as a virtual port and the 808 PE-rs device switches traffic between the virtual port, access ports 809 and the network side VPLS VCs once it has learned the MAC addresses. 811 8.2. Redundant Spoke Connections 813 An obvious weakness of the hub and spoke approach described thus far 814 is that the MTU device has a single connection to the PE-rs device. 815 In case of failure of the connection or the PE-rs device, the MTU 816 device suffers total loss of connectivity. 818 In this section we describe how the redundant connections can be 819 provided to avoid total loss of connectivity from the MTU device. 820 The mechanism described is identical for both, MTU-s and PE-r type 821 of devices 823 8.2.1. Dual-homed MTU device 825 To protect from connection failure of the VC or the failure of the 826 PE-rs device, the MTU-s device or the PE-r is dual-homed into two 827 PE-rs devices, as shown in figure-3. The PE-rs devices must be part 828 of the same VPLS service instance. 830 An MTU-s device will setup two [MARTINI-ENCAP] VCs (one each to PE- 831 rs1 and PE-rs2) for each VPLS instances. One of the two VC is 832 designated as primary and is the one that is actively used under 833 normal conditions, while the second VC is designated as secondary 834 and is held in a standby state. The MTU device negotiates the VC- 835 labels for both the primary and secondary VC, but does not use the 836 secondary VC unless the primary VC fails. Since only one link is 837 active at a given time, a loop does not exist and hence 802.1D 838 spanning tree is not required. 840 PE2-rs 841 ------ 842 / \ 843 | -- | 844 | / \ | 845 CE-1 | \B / | 846 \ \ -- / 847 \ /------ 848 \ MTU-s PE1-rs / | 849 \------ ------ / | 850 / \ / \ / | 851 | -- | Primary VC | -- |---/ | 852 | / \--|- - - - - - - - - - - |--/ \ | | 853 | \B / | | \B / | | 854 \ -- \/ \ -- / ---\ | 855 ------\ ------ \ | 856 / \ \ | 857 / \ \ ------ 858 / \ / \ 859 CE-2 \ | -- | 860 \ Secondary VC | / \ | 861 - - - - - - - - - - - - - - - - - |-\B / | 862 \ -- / 863 MTU-s = Bridging capable MTU ------ 864 PE-rs = VPLS capable PE PE3-rs 866 -- 867 / \ 868 \B / = Virtual VPLS(Bridge)Instance 869 -- 871 8.2.2. Failure detection and recovery 873 The MTU-s device controls the usage of the VC links to the PE-rs 874 nodes. Since LDP signaling is used to negotiate the VC-labels, the 875 hello messages used for the LDP session are used to detect failure 876 of the primary VC. 878 Upon failure of the primary VC, MTU-s device immediately switches to 879 the secondary VC. At this point the PE3-rs device that terminates 880 the secondary VC starts learning MAC addresses on the spoke VC. All 881 other PE-rs nodes in the network think that CE-1 and CE-2 are behind 882 PE1-rs and may continue to send traffic to PE1-rs until they learn 883 that the devices are now behind PE3-rs. The relearning process can 884 take a long time and may adversely affect the connectivity of higher 885 level protocols from CE1 and CE2. To enable faster convergence, the 886 PE1-rs device where the primary VC failed sends out a flush message, 887 using the MAC TLV as defined in Section 6, to all other PE-rs 888 devices participating in the VPLS service. Upon receiving the 889 message, all PE-rs flush the MAC addresses learned from PE1-rs. 890 8.3. Multi-domain VPLS service 892 Hierarchy can also be used to create a large scale VPLS service 893 within a single domain or a service that spans multiple domains 894 without requiring full mesh connectivity between all VPLS capable 895 devices. Two fully meshed VPLS networks are connected together 896 using a single LSP tunnel between the VPLS gateway devices. A 897 single VC is setup per VPLS service to connect the two domains 898 together. The VPLS gateway device joins two VPLS services together 899 to form a single multi-domain VPLS service. 901 9. Acknowledgments 903 We wish to thank Joe Regan, Kireeti Kompella, Anoop Ghanwani, Joel 904 Halpern, Rick Wilder and Eric Rosen for their valuable feedback. 906 10. Security Considerations 908 Security issues resulting from this draft will be discussed in 909 greater depth at a later point. It is recommended in [RFC3036] that 910 LDP security (authentication) methods be applied. This would 911 prevent unauthorized participation by a PE in a VPLS. Traffic 912 separation for a VPLS is effected by using VC labels. However, for 913 additional levels of security, the customer MAY deploy end-to-end 914 security, which is out of the scope of this draft. 916 11. Intellectual Property Considerations 918 This document is being submitted for use in IETF standards 919 discussions. 921 12. Full Copyright Statement 923 Copyright (C) The Internet Society (2001). All Rights Reserved. 924 This document and translations of it may be copied and furnished to 925 others, and derivative works that comment on or otherwise explain it 926 or assist in its implementation may be prepared, copied, published 927 and distributed, in whole or in part, without restriction of any 928 kind, provided that the above copyright notice and this paragraph 929 are included on all such copies and derivative works. However, this 930 document itself may not be modified in any way, such as by removing 931 the copyright notice or references to the Internet Society or other 932 Internet organizations, except as needed for the purpose of 933 developing Internet standards in which case the procedures for 934 copyrights defined in the Internet Standards process must be 935 followed, or as required to translate it into languages other than 936 English. 938 The limited permissions granted above are perpetual and will not be 939 revoked by the Internet Society or its successors or assigns. 941 This document and the information contained herein is provided on an 942 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 943 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 944 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 945 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 946 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 948 13. References 950 [MARTINI-ENCAP] "Encapsulation Methods for Transport of Layer 2 951 Frames Over MPLS", draft-martini-l2circuit-encap-mpls-04.txt (Work 952 in progress) 954 [MARTINI-SIG] "Transport of Layer 2 Frames Over MPLS", draft- 955 martini-l2circuit-trans-mpls-08.txt (Work in progress) 957 [802.1D-ORIG] Original 802.1D - ISO/IEC 10038, ANSI/IEEE Std 802.1D- 958 1993 "MAC Bridges". 960 [802.1D-REV] 802.1D - "Information technology - Telecommunications 961 and information exchange between systems - Local and metropolitan 962 area networks - Common specifications - Part 3: Media Access Control 963 (MAC) Bridges: Revision. This is a revision of ISO/IEC 10038: 1993, 964 802.1j-1992 and 802.6k-1992. It incorporates P802.11c, P802.1p and 965 P802.12e." ISO/IEC 15802-3: 1998. 967 [802.1Q] 802.1Q - ANSI/IEEE Draft Standard P802.1Q/D11, "IEEE 968 Standards for Local and Metropolitan Area Networks: Virtual Bridged 969 Local Area Networks", July 1998. 971 [BGP-VPN] Rosen and Rekhter, "BGP/MPLS VPNs". RFC 2547, March 1999 973 [VPLS-REQ] "Requirements for Virtual Private LAN Services (VPLS)", 974 draft-augustyn-vpls-requirements-00.txt (Work in progress). 976 [RFC3036] "LDP Specification", L. Andersson, et al. RFC 3036. 977 January 2001. 979 [SHAH-PECE] " Signaling between PE and L2PE/MTU for Decoupled VPLS 980 and Hierarchical VPLS ", draft-shah-ppvpn-vpls-pe-mtu-signaling- 981 00.txt, February, 2002. (Work in progress) 983 14. Authors' Addresses 985 Marc Lasserre 986 Riverstone Networks 987 5200 Great America Pkwy 988 Santa Clara, CA 95054 989 Email: marc@riverstonenet.com 991 Vach Kompella 992 TiMetra Networks 993 274 Ferguson Dr. 994 Mountain View, CA 94043 995 Email: vkompella@timetra.com 997 Sunil Khandekar 998 TiMetra Networks 999 274 Ferguson Dr. 1000 Mountain View, CA 94043 1001 Email: sunil@timetra.com 1003 Nick Tingle 1004 TiMetra Networks 1005 274 Ferguson Dr. 1006 Mountain View, CA 94043 1007 Email: ntingle@timetra.com 1009 Loa Andersson 1010 Utfors Bredband AB 1011 Rasundavagen 12 169 29 Solna 1012 Email: loa.andersson@utfors.se 1014 Pascal Menezes 1015 TeraBeam Networks 1016 2300 Seventh Ave 1017 Seattle, WA 98121 1018 Email: Pascal.Menezes@Terabeam.com 1020 Pierre Lin 1021 Yipes Communication 1022 114 Sansome St 1023 San Francisco, CA 94104 1024 Email: pierre.lin@yipes.com 1026 Andrew Smith 1027 Consultant 1028 Email: ah_smith@pacbell.net 1029 Giles Heron 1030 PacketExchange Ltd. 1031 The Truman Brewery 1032 91 Brick Lane 1033 LONDON E1 6QL 1034 United Kingdom 1035 Email: giles@packetexchange.net 1037 Juha Heinanen 1038 Song Networks, Inc. 1039 Email: jh@lohi.eng.song.fi 1041 Tom S. C. Soon 1042 SBC Technology Resources Inc. 1043 4698 Willow Road 1044 Pleasanton, CA 94588 1045 Email: sxsoon@tri.sbc.com 1047 Ron Haberman 1048 Masergy Inc. 1049 2901 Telestar Ct. 1050 Falls Church, VA 22042 1051 Email: ronh@masergy.com 1053 Luca Martini 1054 Level 3 Communications, LLC. 1055 1025 Eldorado Blvd. 1056 Broomfield, CO, 80021 1057 Email: luca@level3.net 1059 Nick Slabakov 1060 Riverstone Networks 1061 5200 Great America Pkwy 1062 Santa Clara, CA 95054 1063 Email: nslabakov@riverstonenet.com 1065 Rob Nath 1066 Riverstone Networks 1067 5200 Great America Pkwy 1068 Santa Clara, CA 95054 1069 Email: rnath@riverstonenet.com