idnits 2.17.1 draft-muthukrishnan-corevpn-arch-00.txt: ** The Abstract section seems to be numbered -(145): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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-04-26) 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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. == There is 1 instance of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 2 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** The abstract seems to contain references ([Heinanen]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 68 has weird spacing: '... of an em...' == Line 144 has weird spacing: '...tors of the s...' == Line 175 has weird spacing: '...r, they repre...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'Heinanen' on line 391 looks like a reference -- Missing reference section? 'Jamieson' on line 394 looks like a reference -- Missing reference section? 'Meyer' on line 397 looks like a reference -- Missing reference section? 'TBD' on line 325 looks like a reference -- Missing reference section? 'Callon' on line 385 looks like a reference -- Missing reference section? 'Rosen' on line 388 looks like a reference Summary: 12 errors (**), 0 flaws (~~), 5 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Karthik Muthukrishnan 3 INTERNET-DRAFT Andrew Malis 4 Expires April 5, 1999 Ascend Communications 5 October 5 1998 7 Core IP VPN Architecture 9 1. Status of this Memo 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, 13 and its working groups. Note that other groups may also distribute 14 working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet-Drafts as reference 19 material or to cite them other than as ``work in progress.'' 21 To learn the current status of any Internet-Draft, please check the 22 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 23 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 24 munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or 25 ftp.isi.edu (US West Coast). 27 2. Acronyms 29 LSP Label Switched Path 30 PNA Private Network Administrator 31 SP Service Provider 32 SPED Service Provider Edge Device 33 SPNA SP Network Administrator 34 VMA VPN Multicast Address 35 VPNID VPN Identifier 36 VR Virtual Router 37 VRC Virtual Router Console 39 3. Abstract 41 This draft presents an approach for building core VPN services in 42 the service provider backbone, as described in [Heinanen]. This 43 approach does not depend on MPLS running in the backbone but will 44 benefit from it. The central vision is for the service provider to 45 provide a virtual router service to their customers. Ease of 46 configuration, dynamic neighbor discovery, scaling and the use of 47 existing routing protocols as they exist today without any 48 modifications are the keystones of this architecture. 50 4. Introduction 52 This draft describes how VPN services in the backbone of the SP's 53 network could be built. The predominant emphasis is on providing a 54 virtual router service and every effort has been made to make the 55 virtual router as equivalent to a physical router as possible. The 56 aspects of a router that a virtual router needs to emulate are 57 configuration of any combination of routing protocols, monitoring 58 of the network and troubleshooting. Providing a logically 59 independent routing domain to every VPN enhances the SP's ability 60 to offer a fully flexible virtual router service that can fully 61 serve the SP's customer without requiring physical per-VPN 62 routers. 64 The approach presented here meets most of the requirements set 65 forth in [Heinanen] but differs significantly in that we have 66 strived to not require or depend on any modifications of any 67 existing routing protocols. Neighbor discovery is aided by the use 68 of an emulated LAN and is achieved by the use of ARP. This draft 69 has made a concerted effort to draw the line between the SP and 70 the PNA: layer 1 and layer 2 services belong and are managed by 71 the SP while layer 3 services belong to and are managed by the 72 PNA. By the provisioning of fully logically independent routing 73 domains the PNA has been given the flexibility to use private and 74 unregistered addresses. Data security is not an issue given the 75 use of private LSPs and the use of VPNID encapsulation when 76 forwarding on shared LSPs. 78 The approach espoused in this draft differs from that described in 79 [Jamieson] in the following ways: No routing protocol is modified 80 or used to aid in the neighbor discovery mechanism. No VPN subnet 81 from the SP's address space is required to be allocated. No PNL to 82 PNL direct peering is used. It is not required for the CPE gear to 83 be also MPLS compliant, thus allowing existing enterprise routers 84 to not have to be upgraded. 86 5. Objectives 88 1. Easy, scalable configuration of VPN endpoints in the service 89 provider network. 91 2. No use of globally unique SP IP resources such as IP subnets. 93 3. Dynamic discovery of VRs (Virtual Routers) in the SP's cloud. 95 4. Virtual Routers fully configured and monitored by network 96 administrator of the VPN. 98 5. Forwarding quality fully configurable; at the lowest end best 99 effort internet LSP. 101 6. Differentiated services on a VPN by VPN basis based on private 102 LSPs. 104 7. Security of internet routers extended to Virtual Routers. 106 8. Specific routing protocols not mandated between Virtual 107 Routers. 109 9. No special extensions to existing routing protocols such as 110 BGP, RIP, OSPF, ISIS etc. 112 6. Requirements 114 The service provider network must run some form of multicast 115 routing to all nodes that will have VPN connections and to nodes 116 that have to forward Virtual Router discovery multicast datagrams. 118 7. Architectural Outline 120 1. Every VPN is assigned a 16 bit VPNID which is unique within the 121 SP's network. The choice of 16 bits for VPNID (rather than 32 122 bits) allows 65k VPNs to be built in a SP's network and 123 simultaneously keeps this ID small enough to be transmitted in 124 encapsulation headers. 126 2. The VPN service is offered in the form of a Virtual Router 127 service. These VRs reside in the SPED and are as such confined to 128 the edge of the SP's cloud. The VRs will use the SP's network for 129 data and control packet forwarding but are otherwise invisible 130 outside the SPEDs. 132 3. The "size" of the VR contracted to the VPN in a given SPED is 133 the quantity of IP resources such as routing interfaces, route 134 filters, routing entries etc. This is entirely under the control 135 of the SP and provides the fine granularity required to empower 136 the SP to offer virtually infinite grades of VR service on a per- 137 SPED level. [Example: one SPED may be the aggregating point (say 138 headquarters of the corporation) for a given VPN and a number of 139 other SPEDs may be access points (branch offices). In this case, 140 the SPED connected to the headquarters may be contracted to 141 provide a large VR while the SPEDs connected to the branch offices 142 may house small, perhaps stub VRs]. 144 4. One of the indicators of the size of the VPN is the number of 145 SPEDs in the SP�s network that have connections to CPE routers. As 146 globally unique IP resources do not have to be dedicated/assigned 147 to VPNs, the number of SPEDs is not limited by any artificial 148 configuration limits. 150 5. Layer 1 and Layer 2 entities belong to and are managed by the 151 SP. To be specific, physical switches/routers, physical links, 152 logical layer 2 connections (such as DLCI in Frame Relay and 153 VPI/VCI in ATM) and LSPs (and their assignment to specific VPNs) 154 are under the control of the SP. In the context of VPNs, it is the 155 SP's responsibility to contract and assign layer 2 entities to 156 specific VPNs. 158 6. Layer 3 entities belong to and are managed by the PNA. Examples 159 of these entities include IP interfaces, choice of dynamic routing 160 protocols or static routes, and routing interfaces. This provides 161 a virtual routing domain to the PNA and empowers the PNA to design 162 the network to achieve intranet, extranet and traffic engineering 163 goals. 165 7. The PNA can manage and monitor the VPN using the methods that 166 would have been used if physical routers rather than VRs were 167 used. Therefore, management may be performed using SNMP or other 168 similar methods or directly at the console, the VR console (VRC). 169 Monitoring and troubleshooting may be performed using SNMP or 170 similar, but may also include the use of standard tools such as 171 ping, traceroute etc. Again, the VRC may be used for these 172 purposes just like any physical router. 174 8. The VRs in the SPEDs form the VPN in the SP's network. 175 Together, they represent a virtual routing domain. They 176 dynamically discover each other by utilizing an emulated LAN 177 resident in the SP's network. Each VPN in the SP's network is 178 assigned a multicast address. Subscription to this multicast 179 address allows a VR to discover and be discovered by other VRs. 181 9. Data forwarding may be done in one of several ways: hop-by-hop 182 using some form of tunneling SPED-to-SPED, a public LSP with 183 best-effort characteristics or a traffic engineered private LSP 184 with differentiated characteristics. The choice of which LSP is 185 configurable by the SP. The default is the public LSP with best- 186 effort characteristics. The hop-by-hop mechanism is available to 187 route packets during periods of LSP establishment and failure. 189 8. Scalable Configuration 191 A VPN is expected to have 100s to 1000s of endpoints within the SP 192 cloud. Configuration should therefore scale at most linearly with 193 the number of end points. Anything worse will make this task too 194 daunting for the service provider. To this end, all that the 195 service provider needs to allocate/assign are physical/logical 196 links from the private network to the service provider edge 197 device. 199 9. Dynamic Neighbor Discovery 201 The VRs in a given VPN reside in a number of SPEDs in the network. 202 The problem is that these VRs need to be connected together. One 203 way to do this is to require the configuration of tunnels between 204 these VRs in a fully meshed fashion. This is obviously not 205 scalable from a configuration and network resource standpoint. 206 Hence the need arises to allow these VRs to dynamically discover 207 each other. Neighbor discovery is facilitated as follows: each 208 VPN is given a limited emulated LAN. This emulated LAN is used in 209 several ways: 211 1. Address resolution uses this LAN to resolve next-hop (private) 212 IP addresses associated with the other VRs. 214 2. Routing protocols such as RIP and OSPF use this limited 215 emulated LAN for neighbor discovery and to send routing updates. 217 The per-VPN LAN is emulated using an IP multicast address. In the 218 interest of conserving public address space and because this 219 multicast address needs to be visible only in the SP network 220 space, we would use an address from the Organizationally scoped 221 multicast addresses (239.192/14) as described in [Meyer]. Each VPN 222 is allocated an address from this range. To completely eliminate 223 configuration in this regard, this address could be computed given 224 the VPNID. 226 10. Virtual Router Configuration 227 172.150/18 172.150.128/18 228 ----------------------- ---------------------------| 229 | | | 230 | | 172.150.128.1 231 | | Parts DB 232 | --------------- | 233 | OSPF | | OSPF | 234 ------------| VR - A |-------------- 235 |-------------| 236 ) ( RIP 237 RIP ) ( 238 ) ( 239 |--------------| -----------------| 240 | | | | 241 | VR - B | | VR - C | 242 |--------------- |----------------- 243 | | Extranet 244 ------------------------- | 245 172.150.64/18 V 246 Vendors 248 Figure 1 250 Each Virtual Router is configurable by the PNA as though it were a 251 private physical router. The resources that this Virtual Router may 252 consume is of course limited by the bounds set by the SP on a SPED by 253 SPED basis. Each VPN has a number of physical connections (to CPE 254 routers) and a number of logical connections (to the emulated LAN). 255 Each of these connections is IP capable and can be configured to 256 utilize any combination of the standard routing protocols and routing 257 policies to achieve specific corporate network goals. 259 To illustrate, in Figure 1, there are 3 VRs on 3 SPEDs. VR-C and VR-B 260 have a physical connection each to CPE equipment while VR-A has 2 261 physical connections. Each of the VRs has a fully IP capable logical 262 connection to the emulated LAN. VR-A has the (physical) connections 263 to the headquarters of the company and runs OSPF over those 264 connections. It can therefore route packets to 172.150/18 and 265 172.150.128/18. VR-B runs RIP in the branch office(over the physical 266 connection) and uses RIP (over the logical connection) to export 267 172.150.64/18 to VR-A. VR-A advertises a default route to VR-B over 268 the logical connection. VR-C is the extranet connection for vendors 269 to use to connect to the parts database at 172.150.128.1. Hence VR-C 270 advertises a default route to VR-A over the logical connection. VR-A 271 exports only 175.150.128.1 to VR-C. This keeps the rest of the 272 corporate network from being subjected to a security problem. 274 The network administrator will configure the following: 276 1. OSPF connections to the 172.150/18 and 172.150.128/18 network in 277 VR-A. 279 2. RIP connections to VR-B and VR-C on VR-A. 281 3. Route policies on VR-A to advertise only the default route to VR- 282 B. 284 4. Route policies on VR-A to advertise only 172.159.128.1 to VR-C. 286 5. RIP on VR-B to VR-A. 288 6. RIP on VR-C to advertise a default route to VR-A. 290 11. Forwarding 292 As mentioned in the architectural outline, data forwarding may be 293 done in one of four ways. The actual method in all but the first 294 outlined here is configurable. At the high end the private LSP is 295 preferred for data forwarding and at the other end hop-by-hop 296 forwarding is used. The order of forwarding preference is therefore: 297 optionally configured private LSP, best effort public LSP and lastly, 298 hop-by-hop. 300 11.1 Private LSP 302 This LSP is optionally configured on a per-VPN basis. This LSP is 303 usually associated with non-zero bandwidth reservation and/or a 304 specific differentiated service or QOS class. If this LSP is 305 available it is used for user data and for VPN private control data 306 forwarding. 308 11.2 Best Effort Public LSP 310 VPN data packets are forwarded using this LSP if a private LSP with 311 specified bandwidth and/or QOS characteristics is either not 312 configured or not presently available. The LSP that is used is that 313 destined for the egress router in VPN 0. The VPNID in the shim header 314 is used to de-multiplex data packets from various VPNs at the egress 315 router. 317 11.3 Hop-by-hop 319 This method of forwarding is used when no LSP is currently available 320 to carry the traffic. This could happen when the LSP is going through 321 a down transient. To confine the VPN routing tables to the edges of 322 the SP network, the VPNID and the egress SPED's ID need to carried 323 all the way. An approach is to tunnel the packet to the egress SPED 324 with the IP protocol set to IPVPN (protocol number to be allocated 325 by IANA) and with a label pushed to represent the VPNID [TBD]. 327 12. Differentiated Services 329 The configuration of private LSPs for VPNs allows the SP to offer 330 differentiated services to paying customers. These private LSPs could 331 be associated with any available QOS class. Multiple private LSPs 332 with different QOS classes could be configured in a VPN with flow 333 profiles used to sort the packets among the LSPs. This feature 334 together with the ability to size the virtual routers allows the SP 335 to offer truly differentiated services to the VPN customer. 337 13. Virtual Router Security Considerations 339 13.1 Data Security 341 This allows the SP to assure the VPN customer that data packets in 342 one VPN never has the opportunity wander into another. From a routing 343 standpoint, this is achieved by maintaining separate instances of 344 routing protocols and routing tables for each virtual router. From a 345 data forwarding standpoint, the use of VPN encapsulation headers (in 346 the case of shared LSPs or hop-by-hop forwarding) or the use of 347 private LSPs guarantees data privacy. 349 13.2 Configuration Security 351 Virtual routers appear as real routers to the PNA. This means that 352 they may be configured by the PNA to achieve connectivity between 353 offices of a corporation. Obviously, the SP has to guarantee that the 354 PNA and the PNA's designees are the only ones to have access to the 355 VRs on the SPEDs the private network has connections to. Since the 356 virtual router console is functionally equivalent to a physical 357 router, all of the authentication methods available on a physical 358 console such as password, RADIUS, etc. are available to the PNA. By 359 allowing only authenticated PNAs to access the VR console, the SP 360 guarantees that the VPN is in full control of its destiny. 362 14. Physical Network Security 364 When a PNA logs in to a SPED to configure or monitor the VPN, the PNA 365 is logged into the VR for the VPN. The PNA has layer 3 configuration 366 and monitoring privileges for the VR. Specifically the PNA has no 367 configuration privileges for the physical network. This provides the 368 guarantee to the SP that a VPN administrator will not be able to 369 inadvertently or otherwise adversely affect the SP's network. 371 15. Virtual Router Monitoring 373 All of the router monitoring features available on a physical router 374 is available on the virtual router. This includes utilities such as 375 "ping" and "traceroute". In addition, the ability to display private 376 routing tables, link state databases, etc. are available. 378 16. Acknowledgements 380 Thanks to Sridhar Komandur and Peter Fetterolf of Ascend 381 Communications for their helpful review and feedback. 383 17. References 385 [Callon] Callon R., et al, "A framework for Multiprotocol Label 386 Switching, draft-ietf-mpls-framework-02.txt". 388 [Rosen] Rosen E., et al, "Multiprotocol Label Switching 389 Architecture", draft-ietf-mpls-arch-02.txt. 391 [Heinanen] Heinanen J., et al, "MPLS Mappings of generic VPN 392 mechanisms", draft-heinanen-generic-vpn-mpls-00.txt. 394 [Jamieson] Jamieson D., et al, "MPLS VPN Architecture", draft- 395 jamieson-mpls-vpn-00.txt. 397 [Meyer] Meyer D., "Administratively Scoped IP Multicast". RFC 2365. 399 18. Authors' addresses 401 Karthik Muthukrishnan 402 Ascend Communications 403 1 Robbins Road 404 Phone: (978) 952-1368 405 Westford, MA 01886 406 Email: karthikm@ascend.com 408 Andrew Malis 409 Ascend Communications 410 1 Robbins Road 411 Westford, MA 01886 412 Phone: (978)-952-7414 413 Email: malis@ascend.com