idnits 2.17.1 draft-lasserre-tls-mpls-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 1. Overview' ) ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 3. Security Considerations' ) ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** The abstract seems to contain references ([2], [3], [4], [5], [6], [7], [8], [9], [10], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? RFC 2119 keyword, line 191: '...earning, a bridged PDU MUST conform to...' RFC 2119 keyword, line 236: '... Each PE MUST create a rooted tree t...' RFC 2119 keyword, line 237: '... L2 VPN. Each PE MUST support a "split...' RFC 2119 keyword, line 238: '...s, that is, a PE MUST NOT forward traf...' RFC 2119 keyword, line 318: '...capable PE nodes MUST use the same VPN...' Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 2001) is 8290 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? '6' on line 344 looks like a reference -- Missing reference section? '7' on line 347 looks like a reference -- Missing reference section? '1' on line 329 looks like a reference -- Missing reference section? '8' on line 354 looks like a reference -- Missing reference section? '10' on line 360 looks like a reference -- Missing reference section? '5' on line 341 looks like a reference -- Missing reference section? '4' on line 338 looks like a reference -- Missing reference section? '2' on line 332 looks like a reference -- Missing reference section? '9' on line 358 looks like a reference -- Missing reference section? '3' on line 335 looks like a reference Summary: 7 errors (**), 0 flaws (~~), 1 warning (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft draft-lasserre-tls-mpls-00.txt August 2001 3 Internet Draft Marc Lasserre 4 Document: draft-lasserre-tls-mpls-00.txt Nick Slabakov 5 Rob Nath 6 Riverstone Networks 8 Pascal Menezes Loa Andersson 9 Terabeam Networks Utfors 11 Andrew Smith Shahid Akhtar 12 Consultant Ciena 14 Tissa Sevenirathne Pierre Lin 15 Force10 Networks Yipes Communication 17 Lewis Eatherton Vasile Radoaca 18 Excite@Home Nortel Networks 20 Ivy Hsu 21 Foundry Networks 23 Expires: February 2002 August 2001 25 Transparent VLAN Services over MPLS 27 Status of this Memo 29 This document is an Internet-Draft and is in full conformance 30 with all provisions of Section 10 of RFC2026. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF), its areas, and its working groups. Note that 34 other groups may also distribute working documents as Internet- 35 Drafts. 37 Internet-Drafts are draft documents valid for a maximum of six 38 months and may be updated, replaced, or obsoleted by other documents 39 at any time. It is inappropriate to use Internet-Drafts as 40 reference material or to cite them other than as "work in progress." 42 The list of current Internet-Drafts can be accessed at 43 http://www.ietf.org/ietf/1id-abstracts.txt 44 The list of Internet-Draft Shadow Directories can be accessed at 45 http://www.ietf.org/shadow.html. 47 Abstract 49 This document describes a transparent virtual LAN service (VLS) 50 solution over MPLS, sometimes known as Transparent LAN Services 51 (TLS). VLS simulates an Ethernet virtual 802.1d bridge [6] [7] for a 52 given set of users. It delivers a layer 2 broadcast domain that is 53 fully capable of learning and forwarding on Ethernet MAC addresses 54 that is closed to a given set of users. Many VLS services can be 55 supported from a single PE node. 57 Conventions 59 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 60 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 61 document are to be interpreted as described in RFC 2119 63 Placement of this Memo in Sub-IP Area 65 RELATED DOCUMENTS 67 http:// search.ietf.org/internet-drafts/draft-martini-l2circuit- 68 trans-mpls-06.txt 70 http://search.ietf.org/internet-drafts/draft-martini-l2circuit- 71 encap-mpls-02.txt 73 WHERE DOES THIS FIT IN THE PICTURE OF THE SUB-IP WORK 75 PPVPN 77 WHY IS IT TARGETTED AT THIS WG 79 The charter of the PPVPN WG includes L2 VPN services and this draft 80 specifies a model for Ethernet L2 VPN services over MPLS. 82 JUSTIFICATION 84 Existing Internet drafts specify how to provide point-to-point 85 Ethernet L2 VPN services over MPLS. This draft defines how 86 multipoint Ethernet services can be provided. 88 Table of Contents 90 Status of this Memo................................................1 91 Abstract...........................................................2 92 Conventions........................................................2 93 Table of Contents..................................................3 95 1. Overview........................................................4 96 2. Bridging Model for MPLS.........................................4 97 2.1 Flooding and Forwarding........................................5 98 2.2 Address Learning...............................................6 99 2.3 LSP Topology...................................................6 100 2.4 Loop free L2 VPN...............................................6 101 2.5 L2 VPN Provisioning............................................7 102 2.6 LDP Based Discovery............................................7 103 3. Security Considerations.........................................8 104 4. References......................................................9 105 5. Author's Addresses.............................................10 106 1. Overview 108 The following discussion applies to devices that serve as Label Edge 109 Routers (LERs) on a MPLS network that is VLS capable. It will not 110 discuss the behavior of transit Label Switch Routers (LSRs) that are 111 considered a part of MPLS network. The MPLS network provides a 112 number of Label Switch Paths (LSPs) that form the basis for 113 connections between LERs attached to the same MPLS network. The 114 resulting set of interconnected LERs forms a private MPLS VPN where 115 each LSP is uniquely identified at each MPLS interface by a label. 117 Ethernet has become a predominant technology initially for Local 118 Area Networks (LANs) and now as an access technology, specifically 119 in metropolitan networks. Ethernet ports or IEEE VLANs are dedicated 120 to customers on Provider Edge (PE) routers acting as LERs. Customer 121 traffic gets mapped to a specific MPLS L2 VPN by configuring L2 FECs 122 based upon the input port and/or VLAN. 124 Broadcast and multicast services are available over traditional 125 LANs. MPLS does not support such services currently. Sites that 126 belong to the same broadcast domain and that are connected via an 127 MPLS network expect broadcast, multicast and unicast traffic to be 128 forwarded to the proper location(s). This requires MAC address 129 learning/aging on a per LSP basis, packet replication across LSPs 130 for multicast/broadcast traffic and for flooding of unknown unicast 131 destination traffic. 133 [1] defines how to carry L2 PDUs over point-to-point MPLS LSPs. This 134 document describes extensions to [1] for transporting Ethernet/802.3 135 and VLAN [8] traffic across multiple sites that belong to the same 136 L2 broadcast domain. Note that the same model can be applied to 137 other 802.1 technologies. It describes a simple and scalable way to 138 offer Virtual LAN services, including the appropriate flooding of 139 Broadcast, Multicast and unknown unicast destination traffic over 140 MPLS, without the need for address resolution servers or other 141 external servers, as discussed in [10]. 143 2. Bridging Model for MPLS 145 An MPLS interface acting as a bridge must be able to flood, forward, 146 and filter bridged frames. 148 +----+ +----+ 149 + C1 +---+ +---| C1 | 150 +----+ | .................................. | +----+ 151 Site A | .+----+ +----+. | Site B 152 +--.| PE |---- MPLS Cloud ----| PE |.--+ 153 .+----+ | +----+. 154 . | . 155 . | . 156 . +----+ . 157 . | PE | . 158 . +----+ . 159 .................................. 160 | ^ 161 +----+ | 162 | C1 | +-- Logical bridge 163 +----+ 164 Site C 166 The set of PE devices interconnected via MPLS appears as a single 167 802.1d bridge/switch to customer C1. Each PE device will learn 168 remote MAC addresses on LSPs (and keeps learning directly attached 169 MAC addresses on customer facing ports). 171 2.1 Flooding and Forwarding 173 Flooding is performed by sending unknown unicast and multicast 174 frames to all possible appropriate destinations. In the MPLS 175 environment this means sending the PDU through each relevant VC LSP. 176 This is accomplished by explicitly copying it to each VC LSP that is 177 part of the corresponding VPN. 179 Note that multicast frames do not necessarily have to be sent to all 180 VPN members. For simplicity, the default approach of broadcasting 181 multicast frames can be used. Extensions explaining how to interact 182 with 802.1 GMRP protocol, IGMP snooping and static MAC multicast 183 filters will be discussed in a future revision. 185 To forward a frame, a bridge must be able to associate a destination 186 MAC address with a VC LSP. It is unreasonable and perhaps impossible 187 to require bridges to statically configure an association of every 188 possible destination MAC address with a VC LSP. Therefore, MPLS 189 bridges must provide enough information to allow an MPLS interface 190 to dynamically learn about foreign destinations beyond the set of 191 LSRs. To accomplish dynamic learning, a bridged PDU MUST conform to 192 the encapsulation described within [1]. 194 2.2 Address Learning 196 Unlike BGP VPNs [8], reachability information does not need to be 197 advertised and distributed via a control plane. Reachability is 198 obtained by standard learning bridge functions in the data plane. 200 Since VC LSPs are uni-directional, two LSPs of opposite directions 201 are required to form a logical bi-directional link. When a new MAC 202 address is learned on an inbound LSP, it needs to be associated with 203 the outbound LSP that is part of the same pair. The state of this 204 logical link can be considered as up as soon as both incoming and 205 outgoing LSPs are established. Similarly, it can be considered as 206 down as soon as one of these two LSPs is torn down. 208 2.3 LSP Topology 210 PE routers run either an IGP or an EGP between them. Tunnel LSPs 211 between PE routers are therefore established along routed paths. 212 Note that tunnel LSPs can also be explicitly routed. Such tunnels 213 form a full mesh. Partial mesh of tunnel LSPs will be discussed in a 214 future revision. VC LSPs are then mapped onto these tunnel LSPs. The 215 resulting VC LSP mesh for the corresponding VPN instance has to be 216 loop free. 218 In a Ethernet based topology, since VC LSPs are not terminated at 219 the CE boundary, unlike Frame Relay or ATM, it is the responsibility 220 of the Service Providers to offer a loop free topology. With Frame 221 Relay or ATM, it is the customers' responsibility to run STP or a 222 routing protocol to prevent loops. With Ethernet as the access 223 medium, a port and/or a VLAN is used per customer. Customer facing 224 ports can be used to tunnel untagged or 802.1q tagged traffic. The 225 VC LSPs connected to each site in the corresponding VPN are only 226 visible to the PE device. 228 2.4 Loop free L2 VPN 230 In order to avoid running a STP instance per VPN, which would not 231 scale, partial mesh configurations of VC LSPs are not allowed. Note 232 that customers are allowed to run STP such as when a customer has a 233 back door link used for backup. In such a case STP BPDUs are simply 234 tunneled through the MPLS cloud. 236 Each PE MUST create a rooted tree to every other PE router that 237 serve the same L2 VPN. Each PE MUST support a "split-horizon" scheme 238 in order to prevent loops, that is, a PE MUST NOT forward traffic 239 from one VC LSP to another in the same VPN (since each PE has direct 240 connectivity to all other PEs in the same VPN). 242 2.5 L2 VPN Provisioning 244 Provisioning of a full mesh can be automatic with a discovery 245 protocol where each PE advertizes which VPN(s) it serves to other 246 PEs in the same domain, reducing the provisioning complexity to O(1) 247 PE to configure when a new site is added, and O(n) new LSPs to be 248 set up. 250 The number of sites per VPN and the number of VPNs per PE router 251 define the total number of VC LSPs to be managed. Let's consider for 252 example that each VPN has an average of 4 sites and that 1000 253 customers are supported in a PE, 4000 VC LSPs need to be established 254 and maintained. Since VC LSPs are set up via LDP, there is no need 255 to refresh LSP states like in the RSVP case. Tunnel LSPs can be 256 either be established via LDP or via RSVP. 258 Since LDP is required for establishing VC LSPs, LDP is a logical 259 choice to exchange VPN membership between PE routers. BGP offers the 260 advantage of being able to set up inter-provider VPNs. However, BGP 261 is typically not enabled on PE routers, but only on core routers. 263 The signaling of VPN membership via BGP will be discussed in a 264 future revision. A possible method for exchanging VPN membership via 265 BGP can be based on [5]. 267 2.6 LDP Based Discovery 269 Once an LDP adjacency has been formed between two PEs, all VC LSPs 270 get established over this single TCP session. 272 Directly connected PEs multicast LDP hellos periodically. Non- 273 directly connected PEs exchanged unicast targeted hellos to each 274 desired peer. Once a hello adjacency is formed, a LDP TCP connection 275 is established. A LDP session is established over this connection by 276 exchanging LDP initialization messages. 278 IGP extensions to automatically discover VLS capable PEs can be 279 used, such as defined in [4]. This will allow a TLS capable PE node 280 to automatically setup a LDP adjacency to the discovered node and 281 automate provisioning for VC LSPs. If LDP is used to create tunnel 282 LSPs, then this will be automated once the newly discovered TLS PE 283 node has an IP entry in the IGP (this assumes that a loopback 284 address is used to represent the newly discovered TLS capable PE 285 node). However if RSVP-TE is used for the tunnel LSP, then it is 286 important that the two PE nodes have a tunnel LSP between them (the 287 means of doing this is beyond the scope of this document). 289 In [2], the L2 VPN information is carried in a Label Mapping message 290 sent in downstream unsolicited mode. This document defines a new 291 parameter id, a 7-byte VPN Id as defined in [9], to the interface 292 parameters field in the VC FEC described in [2]. 294 0 1 2 3 295 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 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | Parameter ID | Length | Variable Length Value | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 | Variable Length Value | 300 | " | 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 The parameter ID is defined as follows: 304 Parameter ID Length Description 306 0x01 4 Interface MTU in octets. 307 0x02 4 Maximum Number of concatenated ATM 308 cells. 309 0x03 up to 82 Optional Interface Description string. 310 0x04 4 CEM [8] Payload Bytes. 311 0x05 4 CEM options. 312 0x06 7 VPN Id. 314 The first five parameters are as described in [2]. 316 The VPN Id field is a unique 7-byte number that identifies a 317 specific L2 VPN instance in a service provider network. All VLS 318 capable PE nodes MUST use the same VPN ID for a given L2 VPN. PE 319 nodes belonging to the same VLS must be capable of mapping Ethernet 320 ports and/or VLANs to the corresponding VPN Id. 322 3. Security Considerations 324 This document does not affect the underlying security issues of 325 MPLS. 327 4. References 329 [1] "Encapsulation Methods for Transport of Layer 2 Frames Over 330 MPLS", draft-martini-l2circuit-encap-mpls-02.txt (Work in progress) 332 [2] "Transport of Layer 2 Frames Over MPLS", draft-martini- 333 l2circuit-trans-mpls-06.txt (Work in progress) 335 [3] "LAN Emulation over ATM version 1.0", af-lane-0021.0000 (ATM 336 Forum) 338 [4] "Distribution of 802.1Q VLAN information using Opaque LSA", 339 draft-tsenevir-8021qospf-00.txt (Work in progress) 341 [5] "Use of BGP-MP for Layer 2 VPN Membership discovery", draft- 342 tsenevir-bgp-l2vpn-00.txt (Work in progress) 344 [6] Original 802.1D - ISO/IEC 10038, ANSI/IEEE Std 802.1D-1993 "MAC 345 Bridges". 347 [7] 802.1D - "Information technology - Telecommunications and 348 information exchange between systems - Local and metropolitan area 349 networks - Common specifications - Part 3: Media Access Control 350 (MAC) Bridges: Revision. This is a revision of ISO/IEC 10038: 1993, 351 802.1j-1992 and 802.6k-1992. It incorporates P802.11c, P802.1p and 352 P802.12e." ISO/IEC 15802-3: 1998. 354 [8] 802.1Q - ANSI/IEEE Draft Standard P802.1Q/D11, "IEEE Standards 355 for Local and Metropolitan Area Networks: Virtual Bridged Local Area 356 Networks", July 1998. 358 [9] Fox, Gleeson, "Virtual Private Networks Identifier", RFC2685 360 [10] "Requirements for Network Based Layer 2 VPN", draft-tsenevir- 361 l2-req-00.txt (Work in progress) 362 5. Author's Addresses 364 Marc Lasserre 365 Riverstone Networks 366 5200 Great America Pkwy Phone: 1-408-878-6550 367 Santa Clara, CA 95054 Email: marc@riverstonenet.com 369 Nick Slabakov 370 Riverstone Networks 371 5200 Great America Pkwy Phone: 1-303-471-6926 372 Santa Clara, CA 95054 Email: nslabakov@riverstonenet.com 374 Rob Nath 375 Riverstone Networks 376 5200 Great America Pkwy Phone: 1-408-878-6742 377 Santa Clara, CA 95054 Email: rnath@riverstonenet.com 379 Loa Andersson 380 Utfors Bredband AB Phone: +46 8 5270 50 38 381 Rasundavagen 12 169 29 Solna Email: loa.andersson@utfors.se 383 Pascal Menezes 384 TeraBeam Networks 385 2300 Seventh Ave 386 Seattle, WA 98121 Email: Pascal.Menezes@Terabeam.com 388 Andrew Smith Fax: +1 415 345 1827 389 Consultant Email: ah_smith@pacbell.net 391 Tissa Senevirathne 392 Force10 Networks 393 1440 McCarthy Blvd Phone: 408-865-5103 394 Milpitas, CA Email: tsenevir@hotmail.com 396 Pierre Lin 397 Yipes Communication 398 114 Sansome St Phone: 415-218-9520 399 San Francisco, CA 94104 Email: pierre.lin@yipes.com 401 Lewis Eatherton 402 Excite@Home 403 450 Broadway Street Phone: 650-556-5022 404 Redwood City, CA 94063 Email: leathert@excitehome.net 406 Vasile Radoaca 407 Nortel Networks 408 600 Technology Park Phone: 978-288-6097 409 Billerica MA 01821 Email: vasile@nortelnetworks.com 411 Ivy Hsu 412 Foundry Networks 413 2100 Gold Street 414 PO Box 649100 Phone: 408-586-1795 415 San Jose, CA 95164 Email: ihsu@foundrynet.com