idnits 2.17.1 draft-jamieson-mpls-vpn-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-03-29) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 15 longer pages, the longest (page 2) being 59 lines 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. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 1998) is 9358 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) == Outdated reference: A later version (-07) exists of draft-ietf-mpls-arch-01 -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- No information found for draft-mpls-ldp - is the name correct? -- Possible downref: Normative reference to a draft: ref. '3' Summary: 8 errors (**), 0 flaws (~~), 3 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS Working Group D. Jamieson 3 Internet Draft B. Jamoussi 4 Expiration Date: January 1999 G. Wright 5 P. Beaubien 6 Nortel (Northern Telecom) Ltd. 7 August 1998 9 MPLS VPN Architecture 11 13 Status of this Memo 15 This document is an Internet-Draft. Internet-Drafts are working 16 documents of the Internet Engineering Task Force (IETF), its areas, 17 and its working groups. Note that other groups may also distribute 18 working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 To learn the current status of any Internet-Draft, please check the 26 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 27 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 28 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 29 ftp.isi.edu (US West Coast). 31 Abstract 33 This Internet Draft defines an architectural model for building 34 Virtual Private Networks (VPNs) in an MPLS domain. The proposed model 35 takes advantage of both network layer peering and packet switching, 36 and link layer circuits and per-stream switching. The model provides 37 a set of simple mechanisms for controlling VPN membership, including 38 registration, propagation, discovery, and dynamic creation of Label 39 Switch Paths to provide connectivity. 41 The architectural constructs described in this document, when 42 combined with the MPLS architecture [1], provide a flexible and 43 scaleable basis for building VPNs. 45 Table of Contents 47 1 Introduction ............................................ 2 48 2 Architectural Overview .................................. 3 49 2.1 Building Blocks ......................................... 3 50 2.2 MPLS-VPN Architecture Summary ........................... 5 51 2.3 Emulated LAN Model ...................................... 7 52 2.4 Elements of a LAN Model ................................. 7 53 2.5 Other Models ............................................ 8 54 3 Architectural Details ................................... 8 55 3.1 Registration of VPN and VPN subnet Information on a PEL . 8 56 3.2 Distribution of VPN Information ......................... 9 57 3.2.1 Static Provisioning ..................................... 10 58 3.2.2 OSPF Opaque LSAs Option ................................. 10 59 3.2.3 TCP Connection/BGP Options .............................. 10 60 3.2.4 Withdrawal of VPN Subnet Information .................... 10 61 3.3 Establishment of VPN Subnet LSPs ........................ 10 62 3.3.1 Creation of Unicast LSPs ................................ 10 63 3.4 Creation of Multicast LSPs .............................. 11 64 3.5 Layer 3 Modeling of VSI ................................. 12 65 3.6 Layer 3 to Layer 2 Address Mapping ...................... 13 66 3.7 PNL Routing & Forwarding ................................ 13 67 4 Extending MPLS into the VPN Member Network .............. 13 68 5 Summary ................................................. 14 69 6 Security Considerations ................................. 14 70 6.1 User Data Privacy and User Address Privacy .............. 14 71 6.2 Service Provider Security ............................... 14 72 7 Intellectual Property Considerations .................... 14 73 8 Acknowledgement ......................................... 14 74 9 References .............................................. 15 75 10 Authors' Addresses ...................................... 15 77 1. Introduction 79 Virtual Private Networks (VPNs) enable private restricted 80 communications of distinct, closed networks over a common shared 81 network infrastructure. Supporting VPNs with MPLS or other 82 connectionless and connection-oriented layers requires three basic 83 functions. 85 - Discovery of VPN members. 87 It is assumed that VPN members connect to a provider network and 88 those members need to find out what other members there are in the 89 VPN. Members may join and leave the service network and those 90 changes need to be known by all remaining members. Mechanisms to 91 support discovery include manual configuration, client-server 92 approaches, and notification provided by the provider network 93 (i.e., auto-discovery). The discovery of membership in one VPN 94 must not allow members of other VPNs to be discovered. That is, 95 discovery within a VPN is kept separate from discovery in another 96 VPN in the same provider network. 98 - Exchanging reachability and control traffic between VPN members. 100 Members in the same VPN need to exchange reachability information 101 about their network layer addresses. These addresses may be in a 102 different space from the provider network and may in fact overlap 103 with other VPN address spaces. Control traffic could include 104 topology information specific to that VPN. As with the discovery 105 mechanism, the exchange of reachability and control traffic must 106 be kept separate between VPNs sharing the same provider network. 108 - Carrying data traffic between VPN members. 110 This mechanism enables data traffic to be carried between users 111 within a VPN. Data traffic from different VPNs is kept separate. 113 In [2] the discovery mechanism involves local configuration (VPNid) 114 and then propagation in LDP, OSPF, or BGP. The reachability exchange 115 is also accomplished by LDP, OSPF, or BGP. Topology information is 116 not propagated between VPN member subnets over the MPLS network 117 providing the VPN service. Data traffic is carried on LSPs which are 118 created to connect all members of the same VPN. 120 This Internet-Draft proposes the use of OSPF, BGP-4, or TCP 121 connections for the discovery mechanism. Reachability and control 122 traffic (topology information) are exchanged over LSPs which are 123 setup between members in the same VPN. Data traffic is carried on 124 LSPs which are created to connect all members of the same VPN. 126 This internet draft is different from [2] and is proposed as an 127 alternative. 129 In Section 2, an architectural overview of building VPNs in an MPLS 130 domain is presented. Section 3 presents the details of the proposed 131 architecture. Extending MPLS into the VPN member network is 132 highlighted in Section 4. Section 5 summarizes the draft. 134 2. Architectural Overview 136 2.1 Building Blocks 138 The building blocks of the MPLS VPN architecture proposed in this 139 draft are shown in Figure 1 and described in this section. 141 Private Network LSR (PNL): 143 The PNL is a device that runs standards based layer 3 (OSPF, BGP, 144 RIP, static routes, etc.) protocols to distribute and calculate 145 reachability information for the private network. It also runs an 146 LDP [3] process for the purpose of establishing Label Switched 147 Paths (LSP) between itself and other members of the same VPN 148 connected over the provider network. The PNL may be a physical 149 device that resides in either the private or provider's premise. 150 It could also be a logical device embedded in some other device, 151 such as a Provider Edge LSR (PEL). 153 PNL PEL Core LSRs PEL PNL 154 +------+ SAL +----+ +--+ +--+ +----+ SAL +------+ 155 | A |-------| |--| 1|--| 2|-----| |---------| B | 156 +------+ | Y | +--+ +--+ / | X | +------+ 157 +----+ \ | / +----+ 158 \ | / 159 \ | / +----+ SAL +------+ 160 \ +--+ | |---------| C | 161 \| 3|----| Z | +------+ 162 +--+ +----+ PNL 163 PEL 165 Figure 1. MPLS VPN Architecture 167 Provider Edge LSR (PEL): 169 The Provider Edge LSR (PEL) is an LSR in the provider domain. It 170 has one or more Shared Access Links (SALs) connecting it to one or 171 more PNLs. LDP peering is established over these SALs which is 172 used to setup end to end (PNL to PNL) LSPs. 174 PELs dynamically discover other PELs supporting the same VPN and 175 VPN subnets. LSPs are then established between those PELs to 176 transport VPN traffic. 178 Core LSR: 180 Core LSRs provide transport across the provider network. They run 181 a layer 3 protocol and MPLS. Core LSRs don't attach directly to 182 PNLs. 184 Shared Access Link (SAL): 186 The SAL is a IP capable physical or logical link that connects the 187 PNL to the PEL. 189 VPN Subnets: 191 A VPN subnet connects an IP subnet between 2 or more PNLs. A VPN 192 subnet is uniquely identified within the provider network by a VPN 193 Id, an IP address and prefix. 195 VPN Subnet Interface (VSI): 197 The IP interface on a PNL for an VPN subnet. A SAL supports 1 or 198 more VSIs. 200 The PNL device has a Shared Access Link (SAL) to a PEL. A VPN Subnet 201 Interface (VSI) is established over the SAL. The VSI is viewed as a 202 broadcast emulated LAN interface by the IP process running on the 203 PNL. IP routing information can be exchanged between all PNLs of the 204 same VPN subnet. The emulated LAN connectivity is achieved using a 205 set of LSPs. 207 2.2 MPLS-VPN Architecture Summary 209 - The provider network provides LSPs that are used by PNLs of the 210 same VPN subnet to exchange VPN routing information and to carry 211 datagrams across the provider network. 213 - The exchange of routing information across provider network is 214 dynamic. This property eases network management and removes the need 215 for static routing requiring operator intervention. 217 - No routing information is exchanged between PNLs and PELs. PNLs 218 form peering relationships across the provider network. Eliminating 219 the routing exchange between the PNL and the PEL provides several 220 benefits: 222 - Topology changes (route flapping) in the private network are 223 transparent to the provider network. Routing engines in the LSRs 224 inside the provider network are not affected by route flaps. 226 - Topology changes in provider network are transparent to private 227 network. When routes change in the provider network, new LSPs are 228 created to re-route the VPN traffic without involving the PNLs. 230 - Private routes are never mixed with provider routes. This 231 eliminates possible address conflicts between VPNs. 233 - The provider network emulates a LAN for each VPN subnet. A 234 particular PNL can send a unicast datagram to any other PNL in the 235 same VPN subnet, or multicast a datagram to all other PNLs in the VPN 236 subnet. 238 - The ELAN requires multicast capability. This functionality can be 239 accomplished three ways: multipoint-to-multipoint LSPs, a set of 240 point-to-multipoint LSPs, or by PNL copy and send broadcast over 241 existing unicast LSPs. 243 - Three types of LSPs are used to interconnect PNLs: 245 - Multipoint-to-point LSP. 247 Each PNL has a multipoint-to-point LSP directed to it. It is used 248 by all other PNLs within the VPN subnet for unicast sends. 250 - Multipoint-to-multipoint LSP (option 1). 252 All PNLs are also interconnected using a bi-directional 253 multipoint-to-multipoint LSP. It is used for sending multicast 254 datagrams. There is one such LSP per VPN subnet. 256 - Point-to-multipoint LSP (option 2). 258 If multipoint-to-multipoint LSPs are not supported by the 259 underlying infrastructure, then point-to-multipoint LSP going from 260 each PNL to all other PNL in a VPN subnet is necessary. 262 - LSP scaling within a SAL. 264 N is defined as the number of PNLs in a VPN subnet. Each PNL 265 therefore uses (assuming the single multipoint-to-point LSP 266 model): 268 - 1 label for the incoming unicast datagram traffic from all 269 other PNLs in the subnet, 271 - N-1 labels to send unicast datagrams to any other PNL in the 272 subnet, 274 - 1 label to send and receive multicast traffic on the subnet 275 using multicast option 1. 277 - N-1 labels to send and receive multicast traffic on the 278 subnet using multicast option 2. 280 - MAC addresses are represented as labels. For a particular PNL, say 281 PNL A, the MAC address of another PNL, say PNL B, is the label that 282 must be used by PNL A to send unicast datagrams to PNL B. Because 283 labels have local significance only, the MAC address used to reach a 284 particular PNL is usually different for different senders. 286 - Layer 2 to layer 3 address mapping is achieved through one of 2 287 methods; propagating the information from the PEL to the PNL or a 288 modified ARP procedure 290 - When the PNL is an LSR in its own right, label stacking can be used 291 to label-switch datagrams in that PNL (instead of doing layer-3 292 forwarding). 294 2.3 Emulated LAN Model 296 To provide maximum flexibility to the VPN members, the provider 297 network appears as a Local Area Network (LAN) to the various VPN 298 member sites as shown in Figure 2. 300 The MPLS architecture with architectural constructs described in this 301 document provide for a flexible model to construct an emulated LAN in 302 an efficient manner. There are several advantages to adopting an 303 emulated LAN model as explained in this section: 305 PNL | 306 +------+ | PNL 307 | A |-----------| +------+ 308 +------+ |----| B | 309 | +------+ 310 | 311 | +------+ 312 Logical View of |----| C | 313 Provider Network ->| +------+ 314 | PNL 316 Figure 2. Emulated LAN in an MPLS Domain 318 - The emulated LAN model provides IP address space conservation. IP 319 address pace conservation occurs two ways. First by eliminating the 320 double addressing requirement for IP tunneling and by decreasing the 321 subnet requirements for equivalent connectivity with current ATM or 322 FR services 324 - The emulated LAN model simplifies the configuration of the VPN 325 within the shared network. Adding or deleting a site from VPS only 326 requires a change only on the interface being added or deleted. 328 2.4 Elements of a LAN model 330 Each node is identified by a MAC address. A MAC address is equivalent 331 to a Label on a VSI port. 333 Each node on a LAN must be able to send a unicast packet to any other 334 node on the LAN. This unicast traffic would include both control and 335 user traffic between any two given PNLs. 337 Each node on a LAN must be able to transmit a single packet onto the 338 LAN and have it delivered to all other nodes on the LAN (multicast). 339 These packets are sent to a multicast MAC address. Multicast traffic 340 includes Hello packets, LSAs, ARP, etc. 342 2.5 Other models 344 This architecture does not rule out other models such as a star or 345 point to point model. The details of other models are left for 346 further study. 348 3. Architectural Details 350 This sections describes the following architectural components of the 351 proposal: 353 - The provisioning of an SAL and the registration of VPN and VPN 354 subnet information on a PEL 356 - The distribution of the VPN information across in the provider 357 network 359 - The establishment of VPN subnet LSPs based on learned VPN subnet 360 information 362 - The modeling of the VPN subnet LSPs into a LAN like broadcast media 363 on the PNL 365 3.1 Registration of VPN and VPN subnet information on a PEL 367 The first step in adding a new site to a VPN subnet is to establish 368 an SAL between the PEL and PNL. The SAL is the link over which LDP 369 runs between the PEL and PNL. Only one SAL needs to be provisioned 370 for all VPN subnets on a PNL, so if the SAL already existed this step 371 can be skipped. 373 Once the SAL has been provisioned on the PEL, a VPN Identifier is 374 assigned to the SAL. There is a one to one mapping between VPN Id and 375 SAL. Again, if the SAL was already provisioned then the VPN Id will 376 also have been provisioned. 378 The next step is to provision the VPN subnet information. This 379 requires an IP address and prefix. The IP address and prefix are the 380 same as the PNL's VSI to which this SAL is linked. The VPN Id 381 together with the IP address and prefix define the VPN Subnet. The IP 382 address itself defines an instance of the subnet. If the same PEL has 383 another SAL to another PNL that supports the same VPN Id and subnet 384 then the IP address distinguishes between the two instances. 386 A protocol could be used to dynamically learn the IP address and 387 prefix from the PNL. Because the learning of this information causes 388 the consumption of resources in the provider network, appropriate 389 control mechanism would have to be part of the protocol. The details 390 of such a protocol are left for further study. 392 Once all of the VPN subnet information has been provisioned or 393 learned on the PEL, LDP is triggered on the PEL to establish an LSP 394 for the VPN subnet that goes from the PEL to the PNL. This LSP does 395 not go any further at this point. It will be spliced onto a 396 multipoint to point LSP later after other PELs supporting the same 397 VPN subnet learn of the existence of this instance of the VPN subnet. 399 The successful establishment of this first LSP also signals to the 400 PEL that the PNL has provisioned the associated VSI port and that 401 port is enabled. 403 3.2 Distribution of VPN information 405 This section describes the distribution of the VPN subnet information 406 within the provider network. 408 All PELs in the network, at least those that have links to the same 409 VPN Subnet, must be made aware of the other PELs that support the 410 same VPN Subnet. This is required to establish LSPs across the 411 provider network for the VPN Subnet. 413 There are several ways to accomplish the distribution of the VPN 414 information: 416 - Static provisioning 417 - OSPF opaque LSAs; 418 - TCP connections; 419 - BGP-4 421 Regardless of the distribution mechanism, the information that is 422 distributed is the PEL provider IP address and a list of VPN records. 423 Each VPN record is a VPN Id followed by a list of IP address/prefix 424 pairs. This information is referred to as the VPN subnet information. 426 Other information that may be part of the VPN subnet information is a 427 QOS value and a status flag. The status flag would indicate if the 428 subnet is being added or withdrawn. 430 3.2.1 Static provisioning 431 Each PEL that has a connection to a VPN subnet can be provisioned 432 with VPN subnet information from other PELs that have a connection to 433 the same subnet. 435 3.2.2 OSPF Opaque LSAs Option 437 With opaque LSAs, the VPN subnet information is put into an opaque 438 LSA and flooded throughout the OSPF AS. This information is 439 delivered, reliably, to every other node via the normal LSA flooding 440 mechanisms. The amount of information distributed in a single LSA 441 (all, for a single VPN Id, for a single VPN subnet) is left for 442 further study. 444 3.2.3 TCP connections/BGP Options 446 The TCP connection option allows for a TCP connection to be 447 established between a PEL and all other PELs that support the same 448 set of VPN subnets. The VPN information would be transmitted 449 reliably across the TCP connections to the PEL peers. This option 450 would require that the IP address of each PEL peer be provisioned, 451 however, it provides an option that is independent of the layer 3 452 routing protocol(s) running in the provider network. 454 BGP-4, could also be modified to carry the VPN information. BGP-4 455 would require a new opaque update type in which it would carry the 456 VPN information. 458 3.2.4 Withdrawal of VPN subnet information. 460 If an instance of a VPN subnet on a PEL is operationally or 461 administratively disabled or deleted, the withdrawal of the VPN 462 subnet information is distributed through the provider network using 463 the same mechanism used to distribute new VPN subnet information. The 464 format of a withdrawal message is left for further study. The 465 withdrawal of an instance of VPN subnet information from a PEL will 466 cause the removal of the LSPs that go to that VPN subnet instance on 467 that PEL. 469 3.3 Establishment of VPN Subnet LSPs 471 VPN subnet LSPs are created when a PEL learns, via one of the 472 distribution mechanism described in 3.2, that it has a VPN subnet in 473 common with some other PEL in the provider network. Two types of LSPs 474 are created; unicast LSPs and multicast LSPs. 476 3.3.1 Creation of Unicast LSPs 478 When a PEL receives new VPN information, it determines if any LSPs 479 need to be established. 481 First, the PEL determines if it has any VPNs in common with the new 482 list. If so, it checks to see if it has any VPN subnets in common. If 483 there are, LSPs are triggered for each of the IP addresses that are 484 members of the subnets. 486 In Figure 3, the creation of LSPs is triggered when PEL X learns 487 that PEL Y supports a common VPN subnet. 489 Using the example below, an LSP will be established from PNL B to PEL 490 X. LDP then continues to establish the LSP from X to Y. At Y, the 491 LSP is spliced onto the LSP that was created when the VPN subnet for 492 PNL A was provisioned. 494 --------------------------------- 495 | | 496 PNL | PEL Core LSRs PEL | PNL 497 +------+ | +----+ +--+ +--+ +----+ | +------+ 498 | A |---| |<-| 1|--| 2|---| |-------| B | 499 +------+ | | Y | +--+ +--+ | X | | +------+ 500 | +----+ ^ | /+----+ | 501 | \ | / | 502 | \ | \/ +----+ | +------+ 503 | \ +--+ | |-------| C | 504 | \| 3|<--| Z | | +------+ 505 | +--+ +----+ | PNL 506 | | 507 | Provider domain | 508 --------------------------------- 510 Figure 3. Unicast LSP Setup 512 Downstream label allocation is used from the PELs (leafs of the 513 multi-point to point tree) to the PNL. Upstream on demand label 514 allocation is used by the PEL (root of the mpt-to-pt tree) and its 515 connected PNL. 517 The LSP that is created is a unidirectional LSP that carries data 518 from PNL B to PNL A. Within the provider network, the LSP can be 519 established along the best hop route or an explicitly provisioned 520 route. If during the establishment of a best hop LSP, another LSP is 521 encountered that goes to the same destination for the same VPN 522 subnet, the LSPs can be merged. For example, when Z tries to 523 establish an LSP to Y, an existing LSP to Y for the given VPN subnet 524 will be encountered on core router 3. The LSP will be merged at that 525 point. 527 3.5 Creation of Multicast LSPs 529 An emulated LAN must be able to multicast certain packets (Hellos, 530 Routing Updates) across the LAN. This draft describes three options 531 for providing this capability. 533 1> A single bi-directional multi-point to multi-point LSP 535 2> A set of unidirectional point to multi-point LSPs 537 3> No multicast LSP is established. VSI interface is responsible 538 for copying and sending multicast packets on all outgoing unicast 539 LSPs. 541 With option 1, when a PEL (e.g. X) learns of the existence of another 542 PEL (e.g. Y) which supports a VPN subnet which it supports, the 543 creation of both unicast and multicast LSPs are initiated. The 544 multicast LSP is a bi-directional LSP that can follow either the next 545 best hop route or an explicit route. If, during the creation of a 546 next best hop multicast LSP, an existing multicast LSP is encountered 547 for the same VPN, the LSP may be merged. 549 Even though a merge point is encountered during the creation of a 550 multi-point to multi-point LSP, LDP must continue through to the 551 destination PNL in case the multicast LSP requires a new branch to 552 reach the destination. 554 Option 2 is simply a less efficient version of option one, at least 555 in terms of label consumption. In this case a point to multi-point 556 LSP is established from each PNL to all other PNLs for the VPN 557 subnet. Again, they are established at the same time as the unicast 558 LSPs. 560 Option 3 is the least expensive in terms of label consumption and 561 most expensive in terms of bandwidth and PNL/PEL resources. When the 562 VSI media has a multicast packet to send it copies and sends the 563 packet on each outgoing label for the VSI. 565 Changes required to LDP to support multicast LSPs is left for further 566 study. 568 3.6 Layer 3 Modeling of VSI 570 For each VSI on a PNL there will be one multicast LSP, one incoming 571 LSP and N-1 outgoing LSPs where N is the number of PNLs in the VPN 572 subnet. The incoming label will be viewed by layer 3 as the MAC 573 address for the interface. The outgoing labels will be viewed as 574 destination MAC addresses for all of the peer routers on the VSI. The 575 multicast LSP will be viewed as the viewed as the multicast MAC 576 address. 578 3.7 Layer 3 to Layer 2 address mapping 580 Two methods of mapping layer 3 to layer 2 addresses for a VSI 581 interface are proposed. The first is the distribution of the layer 3 582 information learned on a PEL for a given VPN subnet into the PNL. 583 This information is injected into the ARP table on the PNL. The 584 second is a modified ARP protocol run between the PNLs on the VPN 585 subnet. 587 When a PEL learns VPN information from other PELs, it learns the VSI 588 IP addresses that belong to VPN subnets. The PEL then triggers LDP to 589 establish an LSP form the PNL to the PEL to reach that peer IP 590 address. Once the LSP is established, the mapping, IP address to 591 label is known. This information is then propagated into the PNL 592 where it can be injected into the ARP table. It may be possible to 593 use LDP on the PNL side to learn the mapping. The details of this 594 mechanism are left for further study. 596 The other option is to use a modified ARP that runs across the VPN 597 subnet. This would be similar to Inverse ARP in that when a new 598 outgoing MAC label is enabled an ARP request is sent across that 599 label. The receiver of the ARP request would put their own VSI IP 600 address in the ARP response packet and send the packet. 602 The local significance of labels and multipoint to point LSPs provide 603 an additional twist. The ARP response packet may need to be sent on 604 the multicast path. An ARP request has the sender's IP address in the 605 packet. If the receiver of an ARP request had already resolved the 606 mapping of the sender's IP address to MAC label, the response can be 607 sent on that unicast LSP, otherwise the response must be sent on the 608 multicast LSP. 610 3.8 PNL Routing and Forwarding 612 Once the mapping for next hop IP address to MAC label is established, 613 normal IP routing and forwarding can take place between the PNLs For 614 each destination IP address that a PNL can send to, its forwarding 615 table will contain an entry which contains the exit port, the next 616 hop IP address to which the packet is to be sent and the MAC 617 address/label for that next hop IP address. 619 4. Extending MPLS into the VPN Member's Network 621 The private network could run MPLS across the VPN by forming LDP 622 peers with other PNLs on the logical LAN and using a shim in the 623 packet header to identify MPLS flows. 625 5. Summary 627 This internet draft presents a VPN architecture over MPLS networks. 628 It addresses the three basic functions required to establish VPNs 629 over MPLS. Using an emulated LAN model for connectivity across the 630 provider network, simplifies the configuration and management 631 coordination effort between the service provider and the VPN. 633 6. Security Considerations 635 One of the major functions of VPN is being able to provide both data 636 privacy and addressing privacy for users [2]. The architecture 637 proposed in this draft comes with built-in security which is robust 638 under dynamic environment. 640 6.1 User Data Privacy and User Address Privacy 642 Both user data privacy and user address privacy are achieved by 643 assigning different VPN identifier to different VPN and building a 644 separate logical network for each VPN. These logical networks may 645 share the same physical connections. But as far as users are 646 concerned, they won't see each other at all. The exceptional case 647 will be one user participate in multiple VPNs. But that would be a 648 configuration issue. 650 6.2 Service Provider Security 652 Due to the emulated LAN model adopted in this architecture, each user 653 won't see the service provider's network at all. i.e. the service 654 provider's network is transparent to users. The latter case indicates 655 that users can even have the same address space as the service 656 provider's. 658 6.3 IP SEC 660 Since the original VPN IP addresses can be transported across the 661 provider network IP SEC functionality is not impacted. One benefit 662 provided by this mode is IP SEC can run in transport as opposed to 663 tunnel mode reducing bandwidth consumption across the provider 664 network. 666 7. Intellectual Property Considerations 668 Nortel may seek patent or other intellectual property protection for 669 some of all of the technologies disclosed in this document. If any 670 standards arising from this document are or become protected by one 671 or more patents assigned to Nortel, Nortel intends to disclose those 672 patents and license them on reasonable and non-discriminatory terms. 674 8. Acknowledgment 676 The authors would like to acknowledge the valuable review and 677 comments of Jerry Wu, Stephen Shew, Ian Duncan, and Scott Pegrum. 679 9. References 681 [1] Rosen et al, "Multiprotocol Label Switching Architecture", 682 draft-ietf-mpls-arch-01.txt, March 1998. 684 [2] J. Heinanen, et. al, "VPN support with MPLS", , March 1998. 687 [3] Anderson, et. al., "Label Distribution Protocol", draft-mpls- 688 ldp-00.txt, March 1998. 690 10. Authors' Addresses 692 Dwight Jamieson 693 Nortel (Northern Telecom), Ltd. 694 PO Box 3511 Station C 695 Ottawa ON K1Y 4H7 696 Canada 698 EMail: djamies@Nortel.ca 700 Bilel Jamoussi 701 Nortel (Northern Telecom), Ltd. 702 PO Box 3511 Station C 703 Ottawa ON K1Y 4H7 704 Canada 706 EMail: jamoussi@Nortel.ca 708 Gregory Wright 709 Nortel (Northern Telecom), Ltd. 710 PO Box 3511 Station C 711 Ottawa ON K1Y 4H7 712 Canada 714 EMail: gwright@Nortel.ca 716 Paul Beaubien 717 Nortel (Northern Telecom), Ltd. 719 PO Box 3511 Station C 720 Ottawa ON K1Y 4H7 721 Canada 723 EMail: beaubien@Nortel.ca