idnits 2.17.1 draft-ietf-l3vpn-vpn-vr-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1213. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1190. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1197. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1203. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** 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? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 142 has weird spacing: '...andards which...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 6, 2006) is 6620 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) ** Downref: Normative reference to an Informational RFC: RFC 3809 ** Downref: Normative reference to an Informational RFC: RFC 4031 ** Downref: Normative reference to an Informational RFC: RFC 4110 ** Downref: Normative reference to an Informational RFC: RFC 4111 == Outdated reference: A later version (-09) exists of draft-ietf-l3vpn-bgpvpn-auto-06 Summary: 8 errors (**), 0 flaws (~~), 5 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Paul Knight (Editor) 3 Internet Draft Hamid Ould-Brahim 4 draft-ietf-l3vpn-vpn-vr-03.txt Nortel Networks 5 Expires: September 6, 2006 6 Bryan Gleeson 7 Nokia 9 March 6, 2006 11 Network based IP VPN Architecture 12 Using Virtual Routers 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six 27 months and may be updated, replaced, or obsoleted by other documents 28 at any time. It is inappropriate to use Internet- Drafts as 29 reference material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on September 7, 2006. 39 Copyright Notice 41 Copyright (C) The Internet Society (2006). 43 Abstract 45 This document describes a network-based Virtual Private Network 46 (VPN) architecture using the virtual router (VR) concept. Multiple 47 VRs can exist in a single physical device. A VR emulates all the 48 functionality of a physical router, and therefore inherits all 49 existing mechanisms and tools for configuration, operation, 50 accounting, and maintenance. Any routing protocol can be used to 51 distribute VPN reachability information among VRs, and no VPN- 52 related modifications or extensions are needed to the routing 53 protocol for achieving VPN reachability. Direct VR-to-VR 54 connectivity may be configured through layer-2 links or through IP- 55 or MPLS-based tunnels. Traffic from VRs belonging to different VPNs 56 may be aggregated over a "backbone VR" network, which greatly 57 simplifies VPN provisioning. This architecture accommodates various 58 backbone deployment scenarios, both where the VPN service provider 59 owns the backbone, and where the VPN service provider obtains 60 backbone service from one or more other service providers. 62 Table of Contents 64 1 Introduction ........................................ 3 65 2 Virtual Router VPN Architecture Guidelines ........... 4 66 2.1 Membership .......................................... 5 67 2.2 Scalability .......................................... 5 68 2.3 Quality of Service ................................... 5 69 2.4 Auto-Discovery ....................................... 5 70 2.5 Routing .............................................. 6 71 2.5.1 Routing between CE and PE ............................ 6 72 2.5.2 Routing in the Service Provider Network .............. 6 73 2.5.3 Routing between PEs................................... 6 74 2.5.4 Multicast routing using VRs .......................... 6 75 2.6 Security ............................................. 6 76 2.7 Topology ............................................. 7 77 2.8 Tunneling ............................................ 7 78 2.9 Management ........................................... 7 79 2.10 Additional Characteristics ........................... 7 80 3 Network Reference Model .............................. 8 81 3.1 Backbone ............................................ 8 82 4 Virtual Router Definition ............................ 9 83 5 How VPNs are Built and Deployed using VRs ............ 9 84 5.1 VR to VR Connectivity over layer-2 Connections........ 10 85 5.2 VR to VR Connectivity through IP or MPLS Tunnels...... 10 86 5.3 Virtual Router Backbone Aggregation .................. 11 87 5.3.1 Tunneling ............................................ 12 88 5.3.1.1 MPLS Tunnels ...................................... 13 89 5.3.1.2 IPsec Tunnels ..................................... 13 90 5.3.2 Routing .............................................. 13 91 5.3.3 Relationship between the VRs and the Backbone VR ..... 13 92 5.3.4 Multiple Backbones Connected to a Single PE .......... 14 93 6 VPN Membership and Topology Auto-Discovery ........... 14 94 7 VRs and Extranets .................................... 15 95 8 VPNs across Domains .................................. 16 96 9 Internet Access ...................................... 16 97 10 Carrier's Carrier Case................................ 17 98 11 Operations and Management ............................ 17 99 11.1 Backbone Migration ................................... 18 100 11.2 Troubleshooting ...................................... 18 101 12 Quality of Service .................................. 18 102 13 Scalability .......................................... 18 103 14 Interoperability ..................................... 19 104 15 Security Considerations .............................. 20 105 16 IANA Considerations .................................. 21 106 17 Normative References ................................. 21 107 18 Informative References ............................... 22 108 19 Contributors and Acknowledgments ..................... 23 109 20 Authors' Addresses .................................. 23 111 1. Introduction 113 This document describes a network-based VPN architecture using 114 virtual routers. The objective is to provide per-VPN routing, 115 forwarding, quality of service, and service management capabilities. 116 The VPN service is based on the virtual router concept. The VR VPN 117 architecture is compatible with the Layer 3 PPVPN framework 118 described in [RFC-4110], as well as the generic PPVPN requirements 119 [RFC-3809] and the service requirements for Layer 3 PPVPNs [RFC- 120 4031]. 122 A virtual router (VR) has exactly the same mechanisms as a physical 123 router, and therefore can inherit all existing mechanisms and tools 124 for configuration, deployment, operation, troubleshooting, 125 monitoring, and accounting. Multiple VRs can exist in a single 126 physical device. Virtual routers can be deployed in various VPN 127 configurations. Direct VR to VR connectivity may be configured 128 through layer-2 links or through a variety of tunnel mechanisms, 129 using IP- or MPLS-based tunnels. Multiple VRs may be aggregated over 130 a "backbone VR." This architecture accommodates various backbone 131 deployment scenarios, including where the VPN service provider owns 132 the backbone, and where the VPN service provider obtains backbone 133 service from one or more other service providers. 135 This informational document does not specify a protocol, and 136 therefore does not specify the manner in which VRs interoperate. 137 Instead, VRs are interconnected using existing IETF specifications 138 for tunneling mechanisms such as IPsec [RFC-4301], GRE [RFC-2784] 139 (optionally with key and sequence number extensions [RFC-2890]), IP- 140 in-IP [RFC-2003], and MPLS [RFC-3031] [RFC-3035] tunnels. 141 Interaction between VRs across these tunnels make use of the same 142 mechanisms and routing protocol standards which would normally be 143 used for interoperation between physical routers [RFC-1812], such as 144 BGP [RFC-4271], OSPF [STD-54], IS-IS [RFC-1195] [RFC-3787], as well 145 as others. 147 There are several ways of implementing the VR architecture. 148 Although this document does not guarantee interoperability by 149 specifying explicit requirements, the nature of the VR approach 150 makes it likely that interoperability can be achieved among various 151 VR implementations, just as interoperability of VRs with normal 152 routers is straightforward. Section 14, "Interoperability," 153 addresses this in more detail. 155 In the VR architecture, an instance of routing is used to distribute 156 VPN reachability information among the VRs supporting each VPN. Any 157 routing protocol can be used, and no VPN-related modifications or 158 extensions are needed to the routing protocol for achieving VPN 159 reachability. VPN reachability information to and from customer 160 sites can be dynamically learned from the CE using standard routing 161 protocols, or it can be statically provisioned on the VR. The 162 routing protocol between the virtual routers and CEs is independent 163 of the routing used in the VPN backbone, between the VRs. That is, 164 the routing protocol between the VRs may be the same or it might be 165 different than the routing mechanism used between the CE and VR, or 166 it may be a different instance of the same protocol. Likewise, since 167 the VR-to-VR connectivity can use tunnels, the inter-VR routing 168 protocol can be independent of the routing used in the backbone 169 network(s) over which the VR-based VPN runs. 171 There are two fundamental architectures for implementing network- 172 based IP VPNs: virtual routers (VR) and aggregated routing. The main 173 difference between the two architectures resides in the model used 174 to achieve VPN reachability and membership functions. 176 In the VR model, each VR in the VPN domain is running an instance of 177 routing protocol responsible for disseminating VPN reachability 178 information between VRs. Therefore, VPN membership and VPN 179 reachability are treated as separate functions, and separate 180 mechanisms are used to implement these functions. In [RFC-4110], 181 this is referred to as using per-VPN routing. VPN reachability is 182 carried out by a per-VPN instance of routing, and a range of 183 mechanisms is possible for determining membership (see section 6.0). 185 In the aggregated routing model [RFC-4110], the VPN site's routing 186 protocol is terminated at the edge of the backbone, and a backbone 187 routing protocol (i.e., extended BGP-4) is responsible for 188 disseminating the VPN membership and reachability information 189 between provider edge routers (PE) for all the VPNs configured on 190 the PE. "BGP/MPLS VPNs" [RFC-4364] describes an example of an 191 aggregated routing VPN architecture. 193 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 194 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 195 document are to be interpreted as described in [RFC-2119]. 197 2. Virtual Router VPN Architecture Guidelines 199 The following guidelines are intended for designers of VR 200 implementations. Since this document does not describe a specific 201 interoperable protocol, there may be alternative ways to achieve 202 these guidelines. 204 2.1 Membership 206 The VR Architecture requires a way to determine VPN membership. 207 This can be accomplished by configuration, by the use of an 208 autodiscovery mechanism such as [VPN-BGP], or by other means. This 209 is discussed in detail in Section 6, "VPN Membership and Topology 210 Auto-Discovery". 212 The use of a VPN identifier (VPN-ID) provides a way to simplify most 213 VPN configuration and operational tasks. All virtual routers that 214 are members of a specific VPN should share the same VPN-ID. This may 215 be the VPN-ID format defined in [RFC-2685]. 217 2.2 Scalability 219 In this architecture, the backbone internal nodes (e.g., P routers 220 [RFC-4110]) are not VPN- or VR-aware, and therefore they don't keep 221 any VPN state within the backbone. Thus the VR architecture avoids 222 any significant contribution to problems of backbone scalability. 224 The PE on which the VRs run (and the VRs themselves) should be able 225 to accommodate rapid growth in the number of routes per VR, since 226 this number can change suddenly as membership changes. The PE should 227 be able to accommodate substantial growth in the number of VRs and 228 CEs supported, to avoid reconfiguration that could disrupt existing 229 connectivity. 231 The optional use of the "backbone VR" improves the scalability of 232 the VR approach, since multiple VRs on a PE may share a single 233 backbone VR connection to their peer VRs on another PE, rather than 234 establishing multiple separate per-VR or per-VPN connections between 235 PEs. The backbone VR is described in more detail in section 5.3. 237 2.3 Quality of Service 239 Existing quality of service mechanisms developed for physical 240 routers should all be available to be used on a per-VR basis. 241 Therefore, quality of service (policing, shaping, classification, 242 and scheduling) should be configurable on a per-VPN basis. 244 2.4 Auto-discovery 246 It should be possible for the VRs to automatically discover each 247 other, set up tunnels to each other, and exchange private routing 248 information across the backbone. The auto-discovery mechanism must 249 take into consideration the case where the VPNs are implemented 250 across administrative domains. We assume in this document that an 251 auto-discovery mechanism which provides services similar to BGP (as 252 described in [VPN-BGP]) is used as the mechanism to distribute 253 membership, topology, and tunnel information among VRs which are 254 members of the same VPN. 256 2.5 Routing 258 2.5.1 Routing between CE and PE 260 Any existing routing protocol may be used between the CE and the VR 261 running on the PE. Typically, the routing protocol of the specific 262 VPN site will be used. Static routes may be used. The routing 263 protocol between the CE and the VR running on the PE may be 264 independent of the PE-to-PE routing. That is, they may be different 265 routing protocols, or different instances of the same routing 266 protocol. 268 2.5.2 Routing in the Service Provider Network (Backbone) 270 The choice of the backbone routing protocol should not be 271 constrained by the VPNs. This is one of the key attractions of the 272 VR model, since it does not require VPN service providers to run and 273 manage any specific backbone protocol or technology. 275 2.5.3 Routing between VRs in a VPN 277 Any existing routing protocol may be used between VRs in a VPN. The 278 routing protocol between the VRs may be independent of the CE-to-PE 279 routing. 281 VRs belonging to the same VPN may construct tunnels providing 282 connections to each other, using information from the backbone 283 routing protocol. They may then exchange routing information and VPN 284 traffic over these tunnels. 286 A backbone VR network may be constructed among some or all PEs. VRs 287 of customer VPNs may use the backbone VR for routing across the 288 backbone. 290 It is strongly recommended that care be taken when multiple routing 291 protocols are used, due to differences in metrics, detail of 292 information, etc. 294 2.5.4 Multicast routing using VRs 296 VR-based VPNs should provide the same mechanisms for IP multicast 297 routing as ordinary routers. The processes of multicast tree 298 construction and packet replication should be configurable in the 299 same way as for ordinary routers. In addition, VR-based VPNs may be 300 able to employ mechanisms to optimize multicast, depending on the 301 specific VPN configuration. 303 2.6 Security 305 The VR architecture accommodates a variety of approaches to ensure 306 security for VPN data, routing, and other control information. 308 Different levels of security are possible, using the security 309 features of routing and tunneling protocols. The architecture should 310 provide authentication and encryption services for VPNs requiring 311 strong security capabilities. VR-based VPN implementations should 312 support the VPN Security Framework [RFC-4111]. 314 2.7 Topology 316 VPN topologies such as a hub and spoke, and full mesh can be 317 supported by the VR architecture. It is also possible to build 318 arbitrary VPN topologies. 320 For example, a PE device with VRs supporting certain VPNs may be 321 able to act as a P (Provider backbone) device with respect to other 322 VPNs. This increases provisioning flexibility in many topologies. 324 2.8 Tunneling 326 The VR architecture should not be limited to a single tunneling 327 mechanism. It may allow the use of IPsec [RFC-4301], GRE [RFC-2784], 328 IP in IP [RFC-2003], and MPLS [RFC-3031], [RFC-3035] tunnels. It 329 should also allow multiple VPNs to share a tunnel across a backbone. 330 Within a single VPN, different types of tunnels should be allowed. 332 2.9 Management 334 The VR architecture should provide mechanisms to make it easy to 335 configure, deploy, operate and troubleshoot each VPN independently, 336 using existing mechanisms and tools. Tools commonly used for 337 operating, managing and debugging IP networks should be able to be 338 used without any modification. 340 Most aspects of the management of the multiple VRs on the PE by the 341 Service Provider are implementation-specific, and beyond the scope 342 of this document. 344 2.10 Additional Characteristics 346 The following are some additional general characteristics of the VR 347 architecture: 348 1) The architecture accommodates different sizes of VPNs, and one 349 VPN should not impact other VPNs on the PE. 350 2) The architecture supports overlapping VPN address spaces in 351 separate VPNs. 352 3) The architecture supports direct paths between VPN sites that 353 bypass the service provider backbone (backdoor links). Traffic can 354 be directed to the backdoor link, or injected to the backbone with 355 the flexibility of using both the backbone access, and the 356 backdoor link as internal or external paths. 357 4) The architecture works over different deployment scenarios, e.g. 358 where the service provider owns its own backbone, and where the 359 service provider obtains backbone service from one or more other 360 service providers. 362 3. Network Reference Model 364 A VPN customer site is connected to the provider backbone by means 365 of a connection between a Customer Edge (CE) device, (which can be 366 one or more hosts and/or routers) and a virtual router (VR). CE 367 devices are preconfigured to connect to one or more VRs. Multiple VRs 368 may coexist on the same service provider edge device (PE). 370 CE devices can be attached to VRs over any type of access link (e.g. 371 ATM, frame relay, Ethernet, PPP [STD-51], L2TP [RFC-2661] or IP 372 tunneling mechanisms such as IPsec or GRE tunnels). 374 +---+ +---+ 375 | P |....| P | 376 +---+ +---+ 377 PE / \ PE 378 +----+ +------+ +------+ +---+ 379 | CEs|--|-{VRs}| |{VRs}-|--|CEs| 380 +----+ +------+ +------+ +---+ 381 \ / 382 +---+ +---+ 383 | P |....| P | 384 +---+ +---+ 386 Figure 1: Network Reference Model 388 CE sites can be statically connected to the provider network via 389 dedicated circuits, or can use dial-up links. Routing tables 390 associated with each virtual router define the site-to-site 391 reachability for each VPN. The internal backbone provider routers 392 (P) are not VPN aware and do not keep VPN state. 394 3.1 Backbone 396 In general the backbone is a shared network infrastructure, which 397 represents either: 398 1) A layer-2 ATM or frame relay network. 399 2) An IP network. 400 3) An MPLS network. 402 Not all VPNs existing on the same PE are necessarily connected via 403 the same backbone. A single PE can be connected to multiple 404 backbones. Individual VRs on the PE may also connect to multiple 405 backbones. Thus a single VPN can be built from multiple transport 406 technologies in the VR architecture. 408 4. Virtual Router Definition 410 A virtual router (VR) is an emulation of a physical router at the 411 software and/or hardware levels. Virtual routers have independent IP 412 routing and forwarding tables, and they are isolated from each 413 other. This means that two VRs on a PE can serve two different VPNs 414 which may have overlapping address space. The addresses need only be 415 unique within a VPN domain. 417 A virtual router has two main functions: 418 1) Constructing routing tables for the paths between VPN sites using 419 any routing technologies (e.g., static, OSPF, RIP, or BGP). 420 2) Forwarding packets to the next hops within the VPN domain. 422 From the VPN user point of view, a virtual router provides the same 423 functionality as a physical router. Separate routing, and forwarding 424 capabilities provide each VR with the appearance of a dedicated 425 router that guarantees isolation from the traffic of other VPNs, 426 while running on shared forwarding and transmission resources. 428 Virtual routers belonging to the same VPN domain should have the 429 same Virtual Private Network Identifier (VPN-ID). The VPN-ID may use 430 the format described in [RFC-2685]. As noted in [VPN-BGP], when the 431 VRs in a given VPN use BGP as the backbone routing protocol, the 432 VPN-ID can be carried in the NLRI to make the addresses of VRs 433 globally unique. Since globally unique addresses are necessary if 434 BGP is used for auto-discovery, the use of a consistent VPN-ID is a 435 key element in supporting auto-discovery and improving scalability 436 of VR-based VPN services. 438 To the CE access device, the virtual router appears as a neighbor 439 router in the CE based network. The CE sends all traffic for non- 440 local VPN destinations to the VR, unless the specific VPN topology 441 provides alternate routes. Each CE access device must learn the set 442 of destinations reachable through its connection to the virtual 443 router; this may be as simple as a default route. Virtual routers 444 participating in a single VPN domain are responsible for learning 445 and disseminating VPN reachability information among themselves. A 446 given VR holds the routes only for the specific VPN of which that VR 447 is a member. Any routing protocol can be used between the VRs and 448 the CEs. 450 5. How VPNs are Built and Deployed using VRs 452 Three main VR deployment scenarios can be used for building VPNs: 453 1) VR to VR connectivity over a layer 2 connection. 454 2) VR to VR connectivity tunneled over an IP or MPLS network. 455 3) Aggregating multiple virtual routers over a "backbone virtual 456 router," which will provide connectivity over a layer 2, IP, or 457 MPLS network. 459 These VR deployment scenarios can coexist on a single PE or within a 460 single VPN. 462 5.1 VR to VR Connectivity over Layer 2 Connections 464 As illustrated in Figure 2, virtual routers can be deployed over 465 direct layer-2 frame relay or ATM connections or other layer-2 466 transport technology. 468 PE PE 469 +---------------+ +---------------+ 470 +-----+ | | | | +-----+ 471 |VPN-A| | +----+ Layer-2 connections +----+ | |VPN-A| 472 |sites|-|-|VR-A|<---------------------------->|VR-A|-|-|sites| 473 +-----+ | +----+ | -------- | +----+ | +-----+ 474 | |-( Layer-2)-| | 475 +-----+ | +----+ | (Backbone) | +----+ | +-----+ 476 |VPN-B|-|-|VR-B| | -------- | |VR-B|-|-|VPN-B| 477 |sites| | +----+<--------------------|------->+----+ | |sites| 478 +-----+ | | | | +-----+ 479 +---------------+ +---------------+ 481 Figure 2: VR to VR connectivity over a layer-2 backbone 483 This type of VR deployment allows direct quality of service 484 engineering on a per-VPN connection basis. The connections can be 485 statically configured or dynamically established. 487 5.2 VR to VR Connectivity through IP or MPLS tunnels 489 In addition to connecting via layer-2 transport technologies, 490 virtual routers can connect over an IP or MPLS backbone. In a manner 491 analogous to layer-2 transport, they can use the backbone to support 492 tunneled connections among the VRs. The topology can be described 493 similar to that for layer-2 transport, as in figure 2. 495 VPN data and routing information is tunneled through the use of IP 496 or MPLS based tunnels (e.g., IPsec, GRE, IP in IP, MPLS). The use of 497 tunnels between VRs is addressed in more detail in the discussion of 498 backbone VRs in the following section of this document. 500 Although it is clearly possible to use a topology similar to the 501 layer-2 model over an IP or MPLS backbone, the VR capability also 502 provides a highly scalable alternative to the use of individual 503 tunnels between VRs. This alternative is the creation (on each 504 participating PE) of another VR facing into the backbone network, 505 which is used to build a kind of backbone VPN that may be shared 506 among multiple customer VPNs. This is described below as the 507 "backbone VR." 509 5.3 Virtual Router Backbone Aggregation 511 Another typical VPN configuration consists of connecting multiple 512 virtual routers to the backbone through the use of a single virtual 513 router in each PE (figure 3). In the following sections we call this 514 single virtual router "the backbone virtual router" or "the backbone 515 VR." The backbone VR is a mechanism to enhance scalability. The use 516 of backbone VRs is optional in VR-based VPNs. When backbone VRs are 517 used, they should be configured on all PEs which participate in VPNs 518 carried over the backbone VRs. 520 The backbone virtual router is not functionally different than other 521 virtual routers. It is only a virtual router that is configured and 522 deployed in a special configuration. 524 The backbone VR connects each PE to a shared backbone 525 infrastructure. Backbone VRs can be deployed over ATM, FR, IP, or 526 MPLS networks. Since the backbone VR allows the aggregation of VRs 527 from multiple VPNs, backbone configuration can remain unaffected as 528 new VPNs or VPN sites are added. The relationship between the VRs 529 and the backbone VR is an overlay relationship. 531 PE-1 PE-2 532 +---------------+ +---------------+ 533 | | | | 534 +-----+ | +----+ MPLS/IP based Tunnels +----+ | +-----+ 535 |VPN-A| | |VR-A|........|<---------->|........|VR-A| | |VPN-A| 536 |sites|-|-|(1) | | | |(2) |-|-|sites| 537 +-----+ | +----+\+----+ | --------- | +----+/+----+ | +-----+ 538 | |VR-1|-|-(IP/MPLS )-|-|VR-2| | 539 +-----+ | +----+/+----+ |(Backbones) | +----+\+----+ | +-----+ 540 |VPN-B|-|-|VR-B| | --------- | |VR-B|-|-|VPN-B| 541 |sites| | |(1) | | | |(2) | | |sites| 542 +-----+ | +----+........|<---------->|........+----+ | +-----+ 543 | | | | 544 +---------------+ +---------------+ 546 Figure 3: VR-1 and VR-2 used as backbone VRs 548 The relationship between the "ordinary" VPN VRs and the backbone VRs 549 is conceptually similar to the relationship between separate 550 routers, even though they coexist in the same device. The individual 551 VRs in a PE, representing different VPNs, can relate to the backbone 552 VR as if they were the CEs of a single VPN, with the backbone VR 553 acting as a PE to them. Thus the VPNs can be multiplexed in a 554 hierarchical fashion, using IP encapsulation or stacked labels, 555 depending on the tunnel technology used between the backbone VRs. 557 The use of the backbone VR provides multiplexing across the backbone 558 for multiple VPNs, while still allowing individually-engineered 559 connections where desired. Note that Figure 3 depicts both a 560 backbone connection between backbone VRs (VR-1 to VR-2) and also 561 connections between the customer VPN VRs (VR-A(1) to VR-A(2) and VR- 562 B(1) to VR-B(2) ) which do not pass through the backbone VRs. Both 563 types of connections may be used simultaneously, e.g., to provide 564 differentiated services to different classes of traffic. Best- 565 effort traffic between VR-A(1) and VR-A(2) may be routed through the 566 shared backbone VRs, while high-priority traffic between these same 567 VRs might be routed through the direct connection, which could be 568 engineered with higher Quality-of-Service parameters. This 569 illustrates how a service provider can trade off greater scalability 570 offered by the backbone VR against higher value "personalized 571 service" for VPN customers. 573 Note that although the backbone VR concept is described above using 574 a single backbone VR per PE, there may be multiple backbone VRs per 575 PE. 577 5.3.1 Tunneling 579 VPN data and routing information is tunneled through the use of IP 580 or MPLS based tunnels (e.g., IPsec, GRE, IP in IP, MPLS). Depending 581 on the tunnel technology used, the tunnels can be statically 582 configured or dynamically established. The tunnel appears to VRs as 583 a point-to-point link. Traffic sent through the tunnel and forwarded 584 by the backbone VR is opaque to the underlying backbone technology 585 used. 587 A tunnel can be established per VPN or shared among many VPNs (VRs). 588 The tunnel can originate from the backbone virtual router or from 589 the VRs. This can provide an opportunity for service 590 differentiation, in which a service provider can offer a higher 591 level of service (at a higher price point) for individually mapped 592 VPN connections among a customer's VRs. 594 The backbone VR makes it appear as if each VR within a VPN is 595 directly connected. It supports both full and partial mesh 596 configurations. Each VR within the VPN exchanges routing information 597 directly with the adjacent VRs in the VPN. Note that adjacency in 598 this case is determined by the overlay topology of the particular 599 VPN, as determined by configuration or discovery. 601 A single VR-based VPN may use different type of tunnels for inter-VR 602 connectivity. Some sites may use MPLS, while other sites (which 603 transit through non-secure domains) may choose to use IPsec to 604 encrypt their data. 606 The scalability and security of dynamic tunnel establishment between 607 VRs is enhanced by the ability to exchange a VPN-ID. [VPN-BGP] 608 supports auto-discovery of the VPN-ID within BGP-based networks. 609 Further work beyond the scope of this document is needed to 610 determine the requirements and usage of the VPN-ID exchange within 611 most tunneling scenarios. 613 5.3.1.1 MPLS Tunnels 615 The VR architecture can use MPLS tunneling in various forwarding 616 scenarios. Individual VRs of some VPNs may be configured to 617 participate in BGP/MPLS IP VPNs as described in [RFC-4364]. 619 In some scenarios, a hierarchy of two labels can be used. One simple 620 forwarding scenario is where the inner label identifies the VR 621 intended to receive the private packet (to be forwarded to the CE). 623 Another forwarding scenario is to distribute the inner label on a 624 per-VPN basis across the tunnels, after the tunnel endpoints (VRs) 625 have been discovered. The label and reachability distribution is 626 done through the tunnels. In this case the inner label distribution 627 process can be achieved using BGP or an existing label distribution 628 protocol on a per-VPN basis. The inner label relates to the private 629 VPN prefixes. On the egress side traffic will be directed to the 630 egress interface by looking up the inner label. 632 5.3.1.2 IPsec Tunnels 634 IPsec [RFC-4301] is needed when there is a requirement for strong 635 encryption or strong authentication. It also supports multiplexing 636 and a signaling protocol - IKE. IPsec tunnels can be established 637 between two VPN sites across the backbone (originating from the 638 backbone VRs). 640 5.3.2 Routing 642 The backbone VR exchanges backbone routing information with other 643 backbone entities (P routers and possibly other backbone VRs). The 644 backbone routing is separated from the customer VPN routing. 646 Virtual routers can run any routing protocol on their local VPN 647 domain. Both static routes and dynamic routing protocols such as 648 RIP, OSPF, and BGP-4 can be used. The VRs of a given VPN exchange 649 routing information with adjacent VRs through the tunnels over the 650 backbone. 652 If a backdoor link is used between VPN sites running any IGP, then 653 by adjusting the backdoor link costs appropriately, the backbone 654 link can be favored for forwarding VPN traffic. By lowering the 655 weight, the backdoor link can be used as a backup link in case the 656 backbone path fails. 658 5.3.3 Relationship between the VRs and the Backbone VR 660 The routing domain of a set of VRs participating in a single VPN has 661 no relation to the routing domain of the backbone VR. The backbone 662 VR is not necessarily aware of the routing instances running on each 663 private virtual router. However, because the backbone VR is also a 664 virtual router, it can build routing relationships with other VRs if 665 needed. 667 5.3.4 Multiple Backbones Connected to a Single PE 669 Figure 4 illustrates an example where multiple backbones are 670 connected to the same PE. This type of configuration can be used 671 when the PE is connected to multiple service provider backbones, or 672 when the service provider offers different VPN services for 673 different types of backbones. 675 PE PE 676 +---------------+ +---------------+ 677 +-----+ | | | | +-----+ 678 |VPN-A|-|-+----+ | | +----+-|-|VPN-A| 679 |sites| | |VR-A|\ | | |VR-A| | |sites| 680 +-----+ | +----+ +----+ | --------- | +----+/+----+ | +-----+ 681 | |VR-1|-|-(Backbone )|-|VR-2| | 682 +-----+ | +----+/+----+ | ( 1 )| +----+\+----+ | +-----+ 683 |VPN-B|-|-|VR-B| | --------- | |VR-B|-|-|VPN-B| 684 |sites| | +----+ | | +----+ | |sites| 685 +-----+ | | | | +-----+ 686 | | | | 687 +-----+ | | | | +-----+ 688 |VPN-C| | +----+ | | +----+ | |VPN-C| 689 |sites|-|-|VR-C|\ | | |VR-C|-|-|sites| 690 +-----+ | +----+ +----+ | -------- | +----+/+----+ | +-----+ 691 | |VR-3|-|-(Backbone)-|-|VR-4| | 692 +-----+ | +----+/+----+ | ( 2 & 3 ) | +----+\+----+ | +-----+ 693 |VPN-D|-|-|VR-D| | -------- | |VR-D|-|-|VPN-D| 694 |sites| | +----+ | | +----+ | |sites| 695 +-----+ | | | | +-----+ 696 +---------------+ +---------------+ 698 Figure 4: Multiple Backbones Connected to a Single PE 700 6. VPN Membership and Topology Auto-Discovery 702 The virtual router approach explicitly separates the mechanisms used 703 for distributing reachability information from mechanisms used for 704 distributing VPN topology and membership information. VPN membership 705 information refers to the set of PEs (and the VRs on those PEs) that 706 have customers in a particular VPN. VPN topology represents the set 707 of VRs configured on PEs and their interconnectivity within the VPN. 708 The topology can be a full-mesh of VRs, a hub and spoke, or anything 709 in between. Dynamic topology due to on-demand VPN customers can also 710 be handled. 712 VPN discovery can be achieved through a variety of different 713 mechanisms, for example: 715 - Directory server approach, in which VRs query a server to 716 determine their neighbors. 717 - Explicit configuration via a management platform. 718 - Piggybacking VPN membership and topology information using 719 existing routing protocols (e.g., BGP) [VPN-BGP]. 720 - Other VPN membership and topology auto-discovery approaches. 722 The above mechanisms can be combined on a single PE, with different 723 mechanisms used on a per-VPN basis. As an example, for some VPNs 724 topology discovery is done only through a management platform. For 725 others, dynamic topology discovery is achieved using existing 726 routing protocols. 728 In this document it is assumed that a mechanism that provides 729 services similar to BGP is used to achieve auto-discovery of VPN 730 members. A robust auto-discovery mechanism provides the scalability 731 needed in large provider-provisioned VPNs. In the approach described 732 in [VPN-BGP], VR addresses are exchanged, along with the information 733 needed to enable the PEs to determine which VRs are in the same VPN 734 ("membership"), and which of those VRs are to have VPN connectivity 735 ("topology"). Once the VRs are reachable through the tunnels, routes 736 ("reachability") are then exchanged by running existing routing 737 protocols on a per-VPN basis across the tunnels. 739 It is important to note that, for the VR architecture, the auto- 740 discovery mechanism is only used to automatically exchange VPN 741 control information between VRs and/or PEs. It is not intended for 742 piggybacking VPN private reachability information onto the backbone 743 routing instance, as is done in [RFC-4364], for example. 745 7. VRs and Extranets 747 Extranets are commonly used to refer to a scenario whereby a company 748 has network access to a limited part of another company's corporate 749 network. An important feature of extranets is the control of who can 750 access what data, and this is essentially a policy decision. Policy 751 decisions are enforced at the interconnection points between 752 different domains. The enforcement may be done via a firewall, a 753 router with access list functionality, or any device capable of 754 applying policy decisions to transit traffic. 756 In the VR architecture, policy can be enforced between two VPNs, or 757 between a VPN and the Internet, in exactly the same manner as is 758 done today without VPNs. For example, two VRs (of different VPNs) 759 could be interconnected, with each VR locally imposing its own 760 policy controls via a firewall or other enforcement mechanism on all 761 traffic that enters its VPN from the outside (whether from another 762 VR or from the Internet). Combining firewalls and exchanging private 763 routes between VRs (members of different VPNs) provide a flexible 764 mechanism to build different flavors of extranets. 766 8. VPNs across Domains 768 It is possible that a VPN may cross multiple domains administered by 769 different service providers. In the VR model, tunnels are used to 770 provide intra-VPN connectivity across the backbones. The main 771 requirement for the service provider in order to achieve end-to-end 772 cross-domain VPN connectivity is the ability for both domains to 773 support a common tunnel technology, plus the ability to support a 774 common membership and topology discovery technology. Once the tunnel 775 is established, private data (e.g., routing information, and private 776 customer data) can flow from one domain to the other with the same 777 level of security or isolation as that tunnel mechanism provides 778 when used within a single service provider network. 780 Another scenario for supporting VPNs with multiple service providers 781 is to use two virtual routers configured on PEs at the 782 interconnection points. Each VR will use policy decisions and 783 firewalling to control VPN traffic transiting from one domain to the 784 other. The two "gateway VRs" have some similarities to the "backbone 785 VRs," specifically with respect to being able to handle multiple 786 VPNs. The individual VPN traffic is not terminated on these 787 "gateway VRs". They provide ingress/egress filtering for any or all 788 the bidirectional tunneled VPN traffic crossing the boundary. The 789 VPN traffic will normally be opaque at the boundary, and typical 790 inter-provider agreements apply to all traffic within individual 791 VPNs, so the inter-provider VPN traffic is typically filtered all- 792 or-nothing (by VPN) based on the visible packet identifiers or 793 labels. 795 When there are VPN links crossing intervening domains which are not 796 VPN-aware, tunnels should be configured across the intervening 797 domains, and the "gateway VR" approach can be employed at the tunnel 798 endpoints to provide security services appropriate to the 799 circumstances. Some aspects of this are discussed in more detail in 800 the "Carrier's Carrier" section. 802 The ability to use a standard, globally-unique VPN-ID format also 803 supports the implementation of unambiguous VPN traffic 804 identification mechanisms across domains. 806 9. Internet Access 808 The same link attaching the CE to the VR can be used to provide 809 Internet access to the VPN sites. The VR operations can be decoupled 810 from the mechanisms used by the customer sites to access the 811 Internet. 813 There are a number of ways to provide Internet access to a VPN using 814 the VR model. One way of providing VPN Internet access is to 815 configure a "backbone VR" to steer private traffic to the VPN VR, 816 and Internet traffic to the normal backbone/Internet forwarding 817 table. The backbone VR can hold the Internet routes (so it will not 818 be necessary for the VPN VRs to handle them). Firewall functionality 819 should be used to secure the Internet backbone VR access. Network 820 address translation services can also be configured on the backbone 821 VR or on VPN VRs where needed for Internet access. 823 There are a number of other options, since the VR architecture 824 reflects the flexibility of normal router architecture. An 825 additional approach is to configure a particular VR to handle 826 Internet access only (rather than going to the backbone VR). Another 827 approach is to use a default route to an Internet gateway (which 828 could be a VR). 830 10. Carrier's Carrier Case 832 In some cases, the customer of a VPN is a service provider or 833 carrier offering VPN services for its own customers. We can 834 describe this as a VPN hierarchy, with the "carrier's carrier" 835 providing backbone services to a "sub-carrier." This is sometimes 836 called "VPN wholesaling." The carrier's carrier may support multiple 837 sub-carriers within a single PE device. The VR model provides 838 several approaches to implement this VPN hierarchy. 840 In one approach, tunnels are built from the VRs of the carrier's 841 carrier to the CEs of the customers of the sub-carrier ("remote 842 CEs"). In this case, the VRs of the carrier's carrier provide VPN 843 service to the remote CEs. The sub-carrier provides transport but 844 does not participate in the VPN services. This can be particularly 845 useful in cases where the sub-carrier's PE or P devices are 846 themselves VRs (which may be instantiated within the same device as 847 the VRs of the carrier's carrier, handling the connections from the 848 remote CEs) and where the sub-carrier is outsourcing the management 849 of its customers' VPN services. 851 Another approach is where the sub-carrier's VPN services are 852 completely transparent to the VRs of the carrier's carrier. This is 853 the default case. It is up to the sub-carrier's VPN service to 854 distribute VPN reachability among the CEs of its customers. 856 11. Operations and Management 858 Each VR operates independently, and can be individually reconfigured 859 without affecting other VRs on the same PE. In some 860 implementations, it may be possible for a VR to be "rebooted" 861 without affecting other VRs. In case of PE failure (e.g., migration, 862 upgrades, etc.), the service provider may want to control and decide 863 what VPN services get reestablished first. This particular point is 864 important when a large number of VPNs is supported on the PE where 865 each VPN service has different service availability requirements. 867 Since each VR operates as an independent router, it is possible for 868 the management of the VRs to be outsourced. VPN customers may 869 choose to configure (or perhaps only to monitor) the VRs that make 870 up their VPN. It is also possible that the backbone VRs could be 871 managed by a separate entity. 873 11.1 Backbone Migration 875 One benefit in using multiple backbone virtual routers is the 876 ability for the backbone network administrator to migrate its 877 backbone from one core technology to another with minimal disruption 878 to VPN services. Conversely, a VPN configuration change or a VPN- 879 software upgrade is totally transparent to the backbone protocol and 880 policies (this is due to decoupling the VPN routing protocol from 881 the provider backbone routing protocol). 883 11.2 Troubleshooting 885 The service provider or the VPN customer can use all existing 886 troubleshooting tools on a per-VPN basis (e.g. ping and traceroute). 887 As an example, a VPN customer may be able to perform some 888 troubleshooting operations on its own VR. In this particular case, 889 the service provider can configure restricted privileges for each 890 VPN customer over the VR associated with the customer's VPN network. 891 This access may provide only the privilege to monitor (with no 892 privilege to change) the layer 3 status of the customer's VPN, as 893 seen by the VR. The service provider may be able to offer VPN 894 customers an SNMP-based method for read-only access to information 895 about their own VPN. However, backbone topology information is 896 completely hidden to the VPN VR, and therefore to the service 897 provider's customer. 899 12. Quality of Service 901 This architecture can utilize a variety of Quality of Service 902 mechanisms. QoS mechanisms developed for physical routers can be 903 used with VRs, on a per-VR basis, including classification, 904 policing, drop policies, traffic shaping and scheduling/bandwidth 905 reservation. The architecture allows separate quality of service 906 engineering of the VPNs and the backbone. 908 13. Scalability 910 The VR VPN architecture shares the scalability advantages of other 911 provider-provisioned VPN architectures. Only the PEs need to handle 912 the VPN type information. The internal backbone routers (the P 913 routers) are not VPN aware. Virtual routers allow multiple private 914 CE-based networks to connect to a single PE. 916 One advantage of the ability to contain the VPN address space and 917 VPN routing and forwarding capabilities within the virtual router 918 entity is the possibility to distribute PE system resources on a 919 per-VPN basis. Indeed, as an example, different scheduling 920 mechanisms can be used for processing each VPN activity within the 921 PE. This type of per-VPN resource management contributes to 922 establishing a wide range of priority schemes among the VPNs within 923 the PE, and contributes to the ability to support a wide range of 924 VPN scales (high traffic and/or many member sites) in the VR 925 architecture. 927 As noted earlier in this document, the use of the "backbone VR" 928 provides significant scalability advantages, allowing very 929 straightforward multiplexing of multiple VPNs across PE-PE tunnels 930 or connections. The individual VPNs and their VRs need not 931 participate in the discovery and maintenance of the topology of the 932 backbone network, essentially seeing the backbone as a single large 933 router to which they are all connected. 935 14. Interoperability 937 There are several ways of implementing the VR architecture. 938 Although this document does not guarantee interoperability by 939 specifying explicit requirements, the nature of the VR approach 940 makes it likely that interoperability can be achieved among various 941 VR implementations, just as interoperability of VRs with normal 942 routers is straightforward. 944 The VR architecture doesn't specify any protocol. Rather it defines 945 how one physical device (a router) can support multiple logical 946 devices (virtual routers), where each virtual router is 947 interconnected with other normal routers or virtual routers either 948 via physical links or by tunnels (of pretty much any kind defined by 949 other IETF standards). Thus interoperation between a virtual router 950 and other routers (whether virtual or logical) makes use of the same 951 IETF standards (and proposed standards) that are used to allow 952 interoperation between normal routers. 954 VR implementations will either interoperate or not interoperate 955 depending upon their implementation of other IETF standards. In 956 particular, for two VR implementations to interoperate, they simply 957 need a common data link or tunnel technology to link them together 958 and common routing protocols. If they are using MPLS, then MPLS has 959 to work over the common link or tunnels, and they need compatible 960 MPLS signaling. 962 Given that normal physical links terminating on a physical router 963 can be assigned to a specific VR, and given that routers can in 964 general interoperate at the data link level, then finding a common 965 link to hook VRs with VRs, or VRs with routers, is straightforward. 966 Also, there is a short list of relatively well known tunneling 967 techniques (MPLS, IPsec, IP-in-IP tunnels, GRE, etc.) which are 968 commonly used in multi-vendor networks. 970 Naturally VRs will also interoperate with normal physical routers in 971 almost any case. Even the "backbone VR" mechanism can be terminated 972 at the other end on normal routers. This would involve one remote 973 "backbone router" which would be the last node of a tunnel, inside 974 of which multiple other tunnels are multiplexed, with these multiple 975 tunnels terminating on multiple real routers, each of which 976 terminates a tunnel which it treats as a normal link. These real 977 routers can run routing protocols over the tunnel, with the VR on 978 the other end of the tunnel being the peer router for the routing 979 protocol. 981 15. Security Considerations 983 From a security viewpoint, the virtual router VPN architecture is an 984 extension of existing router architectures in which multiple VRs, 985 each with the same mechanisms of a physical router, can be 986 configured in a PE device. Thus the VRs inherit the security 987 concerns and security capabilities of individual routers, which are 988 largely beyond the scope of this document. Many of those elements 989 are discussed in some detail in the routing protocol security 990 document [RP-SEC]. The provider-provisioned VPN framework in general 991 also has a number of security considerations due to the shared 992 infrastructure, which are addressed in the PPVPN security framework 993 document [RFC-4111]. This section addresses security considerations 994 which are more specific to the VR architecture. 996 The VR architecture provides an inherently high level of security 997 against many types of attacks against individual VPNs, since 998 individual VPN routing information does not propagate throughout the 999 backbone network. The VRs usually do not exchange routing 1000 information directly through the backbone routing protocol, but 1001 through tunnels, through layer 2 connections, or (in the case of 1002 backbone VRs supporting ordinary VRs) through communication internal 1003 to the PE device. The tunnels can use the security mechanisms 1004 available to the backbone network, such as IPsec in an IP backbone 1005 network, to protect both the routing exchange and the VPN data. 1007 Since the VR architecture concentrates multiple VRs in a single 1008 device, there is a potential for disruption of one VR to affect 1009 other VRs within the same device. It is highly desirable for 1010 implementations to provide mechanisms to isolate problems to a 1011 single VR within a PE, or to a single VPN. 1013 If physical or logical network links are shared among VRs, it is 1014 possible that bandwidth depletion attacks against one VPN may affect 1015 other VPNs. VR implementations should provide mechanisms to mitigate 1016 the effect of excessive traffic being received for individual VPNs 1017 on shared links. In addition, VR implementations should provide 1018 mechanisms to control the bandwidth usage on a per-VPN basis for 1019 traffic transmitted by the PE device. The VPN service provider 1020 should ensure that both access networks and backbone networks are 1021 engineered to reduce the likelihood of this kind of attack. 1023 Since the backbone VR(s) may carry traffic from multiple VPNs, the 1024 implementation of backbone VR mechanisms should provide redundancy 1025 mechanisms. They should provide protection against hostile or 1026 inadvertent resource exhaustion attacks, originating either within 1027 or outside the VPNs. 1029 If the auto-discovery mechanism used in determining membership to 1030 the VPN is subverted, it could potentially be possible for an 1031 attacker to join a VPN without authorization. Likewise, if the VPN- 1032 ID of a VR is erroneously configured, a VPN site could potentially 1033 be joined to the wrong VPN. These issues can both be addressed by 1034 the use of tunnel mechanisms between VRs which include other means 1035 of authentication, such as a shared secret. Other proposals for VPN 1036 membership verification, such as [MPLSVPN-AUTH], offer mechanisms 1037 which may also be useful to mitigate this potential issue. 1039 Various levels of data, routing and configuration security can be 1040 implemented in the VR architecture. Any existing security-related 1041 mechanisms supported by existing routing protocols (e.g. 1042 authentication) can be used unmodified. If IPsec tunneling is used 1043 as the tunneling protocol, then both the control and data traffic 1044 that travels over the tunnel can be secured; so that routing 1045 specific security enhancements are not needed. Any private routing, 1046 forwarding and addressing manipulation is done within the virtual 1047 router context. Direct layer-2 connections (ATM, FR), or specific 1048 tunneling mechanisms can also provide various levels of data 1049 security. 1051 16. IANA Considerations 1053 This document has no actions for IANA. 1055 17. Normative References 1057 [RFC-1812] F. Baker, Ed., "Requirements for IP Version 4 Routers", 1058 RFC 1812, June 1995. 1060 [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate 1061 Requirement Levels", RFC 2119, BCP 14, March 1997. 1063 [RFC-3031] E. Rosen, A. Viswanathan, R. Callon, "Multiprotocol Label 1064 Switching Architecture", RFC 3031, January 2001. 1066 [RFC-3035] B. Davie, J. Lawrence, K. McCloghrie, E. Rosen, G. 1067 Swallow, Y. Rekhter, P. Doolan, "MPLS using LDP and ATM VC 1068 Switching", RFC 3035, January 2001. 1070 [RFC-3809] Nagarajan, A., Ed., "Generic Requirements for Provider 1071 Provisioned Virtual Private Networks (PPVPN)", RFC 3809, June 1072 2004. 1074 [RFC-4031] Carugi, M., Ed. and D. McDysan, Ed., "Service 1075 Requirements for Layer 3 Provider Provisioned Virtual Private 1076 Networks (PPVPNs)", RFC 4031, April 2005. 1078 [RFC-4110] R. Callon, M. Suzuki, "A Framework for Layer 3 Provider- 1079 Provisioned Virtual Private Networks (PPVPNs)", RFC 4110, July 1080 2005. 1082 [RFC-4111] Fang, L., Ed., "Security Framework for Provider 1083 Provisioned Virtual Private Networks", RFC 4111, July 2005. 1085 [RFC-4271] Y. Rekhter, Ed., T. Li, Ed., S. Hares, Ed., "A Border 1086 Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006. 1088 [RFC-4301] Kent, S., Seo, K., "Security Architecture for the 1089 Internet Protocol", RFC 4301, December 2005. 1091 [RFC-4364] Rosen, E., et al, "BGP/MPLS IP Virtual Private networks 1092 (VPNs)", RFC 4364, February, 2006. 1094 [STD-54] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 1096 18. Informative References 1098 [MPLSVPN-AUTH] Behringer, M., Guichard, J., Marques, P. R., "Layer-3 1099 VPN Import/Export Verification" (draft-ietf-l3vpn-vpn- 1100 verification-00.txt), work in progress. 1102 [RFC-1195] Callon, R., "OSI IS-IS for IP and Dual Environment," RFC 1103 1195, December 1990. 1105 [RFC-2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, 1106 October 1996. 1108 [RFC-2661] Townsley, W., et al, "Layer Two Tunneling Protocol L2TP", 1109 RFC 2661, August 1999. 1111 [RFC-2685] Fox, B., et al, "Virtual Private Networks Identifier", 1112 RFC 2685, September 1999. 1114 [RFC-2784] Hanks, S., Li, T., Farinacci, D. and P. Traina, "Generic 1115 Routing Encapsulation (GRE)", RFC 2784, March 2000. 1117 [RFC-2890] Dommety, G., "Key and Sequence Number Extensions to GRE", 1118 RFC 2890, September 2000. 1120 [RFC-3787] Parker, J., Ed., "Interoperable IP Networks using IS-IS", 1121 RFC 3787, May 2004 1123 [RP-SEC] Barbir, A., Murphy, S., and Yang, Y., "Generic Threats to 1124 Routing Protocols" (draft-ietf-rpsec-routing-threats-07.txt), 1125 work in progress. 1127 [STD-51] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, 1128 RFC 1661, July 1994. 1130 [VPN-BGP] Ould-Brahim, H., et al., "Using BGP as an Auto-Discovery 1131 Mechanism for Layer-3 and Layer-2 VPNs" (draft-ietf-l3vpn-bgpvpn- 1132 auto-06.txt), work in progress. 1134 19. Contributors and Acknowledgments 1136 The authors would like to acknowledge the active contributions of 1137 the following individuals, all of whom would be included as authors 1138 if allowed by IETF processes: 1139 Rainer Bach 1140 Rick Bubenik 1141 Luyuan Fang 1142 Isaac Negusse 1143 Chandru Sargor 1144 Timon Sloan 1145 Dr. Christian Weber 1146 Gregory Wright 1147 Abraham Young 1148 Jieyun Jessica Yu 1150 The authors would also like to acknowledge the following individuals 1151 for their helpful comments and suggestions: Peter Ashwood-Smith, Ron 1152 Bonica, Ross Callon, David Drynan, Mark Duffy, Don Fedyk, David 1153 Hudson, Bilel Jamoussi, Ahmad Khalid, Scott Larrigan, Keerti 1154 Melkote, Martin Pepin, Benson Schliesser, Jerry Sydir, and Ru 1155 Wadasinghe. 1157 20. Authors' Addresses 1159 (change /at/ to @ for email) 1161 Paul Knight (Editor) 1162 Nortel Networks 1163 600 Technology Park Drive 1164 Billerica, MA 01821 USA 1165 paul.knight/at/nortel.com 1166 Phone: +1 (978) 288 6414 1168 Hamid Ould-Brahim 1169 Nortel Networks 1170 P O Box 3511 Station C 1171 Ottawa, ON K1Y 4H7 Canada 1172 Phone: +1 (613) 765 3418 1173 Email: hbrahim/at/nortel.com 1175 Bryan Gleeson 1176 Nokia 1177 313 Fairchild Drive 1178 Mountain View CA 94043 USA 1179 bryan.gleeson/at/nokia.com 1181 Intellectual Property Statement 1183 The IETF takes no position regarding the validity or scope of any 1184 Intellectual Property Rights or other rights that might be claimed 1185 to pertain to the implementation or use of the technology described 1186 in this document or the extent to which any license under such 1187 rights might or might not be available; nor does it represent that 1188 it has made any independent effort to identify any such rights. 1189 Information on the procedures with respect to rights in RFC 1190 documents can be found in BCP 78 and BCP 79. 1192 Copies of IPR disclosures made to the IETF Secretariat and any 1193 assurances of licenses to be made available, or the result of an 1194 attempt made to obtain a general license or permission for the use 1195 of such proprietary rights by implementers or users of this 1196 specification can be obtained from the IETF on-line IPR repository 1197 at http://www.ietf.org/ipr. 1199 The IETF invites any interested party to bring to its attention any 1200 copyrights, patents or patent applications, or other proprietary 1201 rights that may cover technology that may be required to implement 1202 this standard. Please address the information to the IETF at ietf- 1203 ipr@ietf.org. 1205 Disclaimer of Validity 1207 This document and the information contained herein are provided on 1208 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1209 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 1210 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 1211 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1212 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1213 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1215 Copyright Statement 1217 Copyright (C) The Internet Society (2006). This document is subject 1218 to the rights, licenses and restrictions contained in BCP 78, and 1219 except as set forth therein, the authors retain all their rights. 1221 Acknowledgment 1223 Funding for the RFC Editor function is currently provided by the 1224 Internet Society.