idnits 2.17.1 draft-suzuki-nbvpn-framework-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document is more than 15 pages and seems to lack a Table of Contents. == 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 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. 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 (November 24, 2000) is 8554 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'MPLS-ARC' is mentioned on line 91, but not defined == Missing Reference: 'DIFF-MPLS' is mentioned on line 1004, but not defined == Missing Reference: 'LSP-RSVP' is mentioned on line 1010, but not defined == Missing Reference: 'RFC1583' is mentioned on line 1155, but not defined ** Obsolete undefined reference: RFC 1583 (Obsoleted by RFC 2178) == Missing Reference: 'RFC2283' is mentioned on line 1246, but not defined ** Obsolete undefined reference: RFC 2283 (Obsoleted by RFC 2858) == Unused Reference: 'RFC2547' is defined on line 1330, but no explicit reference was found in the text == Unused Reference: 'VPN-BGP-OSPF' is defined on line 1342, but no explicit reference was found in the text == Unused Reference: 'VPN-BGP-IPSEC' is defined on line 1346, but no explicit reference was found in the text == Unused Reference: 'VPN-IPSEC' is defined on line 1357, but no explicit reference was found in the text == Unused Reference: 'VPN-INTER' is defined on line 1361, but no explicit reference was found in the text == Unused Reference: 'RFC2917' is defined on line 1364, but no explicit reference was found in the text == Unused Reference: 'MPLS-DIFF' is defined on line 1377, but no explicit reference was found in the text == Unused Reference: 'MPLS-GMNCL' is defined on line 1381, but no explicit reference was found in the text == Unused Reference: 'RFC2983' is defined on line 1469, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 2764 ** Obsolete normative reference: RFC 2547 (Obsoleted by RFC 4364) -- Duplicate reference: RFC2547, mentioned in 'VPN-2547BIS', was also mentioned in 'RFC2547'. ** Obsolete normative reference: RFC 2547 (Obsoleted by RFC 4364) -- Possible downref: Non-RFC (?) normative reference: ref. 'VPN-BGP-OSPF' -- Possible downref: Non-RFC (?) normative reference: ref. 'VPN-BGP-IPSEC' -- Possible downref: Non-RFC (?) normative reference: ref. 'VPN-BGP-VR' -- Possible downref: Non-RFC (?) normative reference: ref. 'VPN-VR' -- Possible downref: Non-RFC (?) normative reference: ref. 'VPN-IPSEC' -- Possible downref: Non-RFC (?) normative reference: ref. 'VPN-INTER' ** Downref: Normative reference to an Informational RFC: RFC 2917 -- Possible downref: Non-RFC (?) normative reference: ref. 'MPLS-ARCH' -- Possible downref: Non-RFC (?) normative reference: ref. 'MPLS-FRAME' -- Possible downref: Non-RFC (?) normative reference: ref. 'MPLS-ATM' -- Possible downref: Non-RFC (?) normative reference: ref. 'MPLS-DIFF' -- Possible downref: Non-RFC (?) normative reference: ref. 'MPLS-GMNCL' ** Obsolete normative reference: RFC 2401 (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2402 (Obsoleted by RFC 4302, RFC 4305) ** Obsolete normative reference: RFC 2406 (Obsoleted by RFC 4303, RFC 4305) ** Obsolete normative reference: RFC 2409 (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 1771 (Obsoleted by RFC 4271) ** Obsolete normative reference: RFC 1965 (Obsoleted by RFC 3065) ** Obsolete normative reference: RFC 1966 (Obsoleted by RFC 4456) ** Obsolete normative reference: RFC 2283 (ref. 'RFC2858') (Obsoleted by RFC 2858) -- Possible downref: Non-RFC (?) normative reference: ref. 'BGP-COM' ** Downref: Normative reference to an Informational RFC: RFC 2208 -- Possible downref: Non-RFC (?) normative reference: ref. 'RSVP-LSP' ** Downref: Normative reference to an Informational RFC: RFC 2475 ** Obsolete normative reference: RFC 2598 (Obsoleted by RFC 3246) ** Downref: Normative reference to an Informational RFC: RFC 2983 Summary: 22 errors (**), 0 flaws (~~), 15 warnings (==), 16 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force M. Suzuki and J. Sumimoto (Ed.) 3 INTERNET-DRAFT NTT 4 Expires May 24, 2001 A. Malis 5 Vivace Networks, Inc. 6 K. Muthukrishnan 7 Lucent Technologies 8 November 24, 2000 10 A Framework for Network-based VPNs 11 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Abstract 36 The objective of this draft is to clarify a framework for 37 standardizing the mechanisms supporting interoperable network-based 38 virtual private networks (NBVPNs). These are VPNs using IP 39 facilities whose operating mechanisms are implemented within a 40 network (or networks) and outsourced to one or more service 41 providers. This draft first describes the assumed services of NBVPNs 42 and clarifies the logical architecture model and reference model of 43 an NBVPN. Considering the assumed services, this draft further 44 clarifies the NBVPN requirements for interfaces and MIBs in the 45 reference model. It also surveys and discusses current technologies 46 supporting NBVPNs such as tunneling, VPN identifier, routing, and 47 QoS/SLA. Additionally it will, in future, provide an outline of the 48 interface and MIB specifications and present criteria for achieving 49 interoperability. 51 1. Objective and Scope of this Document 53 The objective of this document is to clarify a framework for 54 standardizing the mechanisms supporting interoperable network-based 55 virtual private networks (NBVPNs). Note that the document uses 56 concepts and discussions in [RFC2764], but does not repeat the 57 discussions therein. 59 This framework includes assumed services of NBVPN for which 60 interoperable solutions need to be developed, a logical architecture 61 model and reference model of NBVPN, requirements for interfaces and 62 MIBs of the NBVPN reference model, an outline of the interface and 63 MIB specifications, overview of related technologies, and criteria 64 for achieving interoperability. 66 A VPN service is defined as a service that provides a network whose 67 logical structure, such as addressing, reachability, and access 68 control, is equivalent to part of or all of a conventional enterprise 69 network using private facilities, it does not affect the logical 70 structure in the rest of the enterprise network, and it is 71 implemented with public network facilities. 73 In particular, a VPN service that uses facilities of the Internet is 74 called an IP VPN service. Since IP VPN services are provided at 75 lower costs and their service provisioning is more flexible than that 76 of VPNs based on other technologies, various IP VPN implementations 77 have been developed. 79 IP VPN implementations are further classified into "network-based 80 VPNs (NBVPNs)" and "customer premises equipment (CPE)-based VPNs." 81 The NBVPN is an IP VPN whose VPN operations mechanisms are 82 implemented within a network (or networks) and outsourced to one or 83 more service providers (SPs) [RFC2764]. Compared with a CPE-based 84 VPN, in which the VPN operations mechanisms are implemented in CPE, 85 the NBVPN has the advantage of reducing the customer's overhead for 86 VPN operations, so it is attracting the attention of Internet users 87 and SPs. 89 Looking at current implementations of NBVPNs, we see that a single 90 technology cannot serve as the base technology, so various 91 technologies such as MPLS [MPLS-ARC] [MPLS-FRAME] and IPsec [RFC2401] 92 have been used. However, there has been no practical and commonly 93 supported way of achieving interworking between an NBVPN of one 94 technology and another NBVPN of another technology even though they 95 have similar mechanisms. Thus, early provision of such a solution is 96 eagerly awaited by Internet users and SPs. 98 In order to support the standardization activity (responding to 99 demands) to provide solutions for NBVPN interworking, this framework 100 is created and serves as the basis for standardization in terms of 101 the architecture and specifications of NBVPNs. 103 This standardization work aims to avoid applying excessive 104 constraints on the mechanisms and specifications of base technologies 105 (e.g., tunneling mechanisms) so that future advances in the base 106 technologies for NBVPN can also be accommodated within this 107 framework. This standardization work does not intend to modify any 108 currently used mechanisms or specifications of the base technologies, 109 either. 111 The NBVPNs targeted by this framework are: 113 o Virtual private routed networks, which are defined as an emulation 114 of a multi-site wide area routed network using IP [RFC2764]. 116 Excluded are: 118 o NBVPNs using VPN native (non-IP) protocols as their base 119 technologies. However, this does not mean to exclude multi- 120 protocol access to the NBVPN by users. 122 o Virtual leased lines, which provide a point-to-point link between 123 two user sites [RFC2764]. 125 o Virtual private dialup networks, which are defined as an emulation 126 of on-demand isolated IP reachability from a remote user to a user 127 site. The remote user is connected via a dial-up PSTN or ISDN link 128 [RFC2764]. 130 o Virtual private LAN segments, which are defined as an emulation of 131 a LAN segment using Internet facilities [RFC2764]. 133 This standardization is expected to lead to the following benefits. 135 o Benefits to SPs 137 It will enable flexible NBVPN implementation over multi-vendor 138 multi-mechanism subnetworks. It will remove the constraint that 139 all user sites of an NBVPN are limited to a specific vendor or 140 mechanism. It will also lead to lower costs than with the uniform 141 NBVPN implementation. 143 o Benefits to customers 144 Customers will have more chance to construct wider area (e.g., 145 international) NBVPNs as a result of the multi-SP multi-vendor 146 environments provided by this technology. They will also get 147 cheaper NBVPN services. 149 In this document, section 2 describes assumed services of NBVPNs, 150 section 3 clarifies the logical architecture model and reference 151 model for NBVPNs, section 4 clarifies requirements for interfaces and 152 MIBs in the NBVPN reference model, and section 5 outlines interface 153 and MIB specifications. Moreover, section 6 surveys current 154 mechanisms and discusses their issues, section 7 discusses criteria 155 for achieving interoperability, and section 8 summarizes security 156 considerations. 158 2. Assumed Services of NBVPNs 160 This section describes assumed services of NBVPNs which are provided 161 to user sites by the networks. The purpose of discussing assumed 162 services is to extract the requirements for mechanisms to be 163 standardized for interoperable NBVPNs. We do not intend to 164 standardize these services for NBVPNs in any way. 166 2.1 Closed User Group (CUG) 168 A closed user group (CUG) service provides communications between 169 various specific user sites through an NBVPN. Other user sites 170 cannot reach them. This is the basic service of an NBVPN. Operation 171 mechanisms are implemented within a network and the operations are 172 performed by an SP. This service prevents packets from being 173 injected into the network without authorization. It also prevents 174 packets from being snooped on, modified in transit, or subjected to 175 traffic analysis by unauthorized parties. Private IP addressing may 176 be used in a CUG. 178 2.2 CUG Interconnection 180 A CUG interconnection service enables communications between specific 181 CUGs or user sites belonging to other CUGs within the networks. 182 Access control (including packet filtering and address translation) 183 may be applied between CUGs according to policy. Interconnection of 184 CUGs performed in user sites is outside the scope of this document. 186 2.3 QoS/SLAs 188 QoS/SLA services provide guaranteed and/or differentiated 189 communications with NBVPN-specific SLAs covering loss rates, jitter, 190 latency, and bandwidth etc. Various classes of QoS are provided, 191 although they may depend on the supporting technologies, e.g., 192 IntServ [RFC2211] [RFC2212], DiffServ [RFC2474] [RFC2475], or L2 193 traffic engineering capabilities [AF-TM-0121.000]. 195 2.4 Dynamic Routing 197 A dynamic routing service enables the exchange of unicast routing 198 information between user sites and an NBVPN using a routing protocol 199 such as Open Shortest Path First (OSPF) [RFC2328] or Border Gateway 200 Protocol 4 (BGP-4) [RFC1771]. Routing information about each user 201 site can be distributed from one user site to another. This service 202 is essential for multihomed user sites, in which the main purpose of 203 multihoming is to improve reliability. 205 2.5 Multiprotocol Transport 207 A multiprotocol transport service supports traffic carried between 208 user sites using various different protocols. 210 2.6 NBVPN over Multiple SPs 212 An NBVPN over multiple SPs service enables a single NBVPN to cover 213 multiple SPs. 215 2.7 Multicast 217 A multicast service replicates multicast packets forwarded from user 218 sites in the networks and forwards them to multiple user sites. 219 Multicast routing information is exchanged between user sites and an 220 NBVPN using a multicast routing protocol. 222 2.8 Note on Data Security Service 224 [RFC2764] discusses data security service which provides stronger 225 security than that of the basic CUG service and which is supported by 226 encryption and authentication. In this framework document, it is not 227 assumed for a NBVPN service for the following reasons. 229 o If a user requires stronger security than that of the NBVPN 230 service, it should be provided by a CPE-based security mechanism. 231 This is because a network-based solution cannot ensure the security 232 of access links between user sites and a network. 234 o If stronger security is provided by a network-based mechanism, it 235 is located at the edge of the SP network providing the NBVPN 236 service. Thus, security and NBVPNs service mechanisms are 237 independent, because the security protocol layer is located on the 238 protocol layer that provides NBVPN service. Therefore, this 239 security mechanism is not discussed in this framework. 241 However, a similar security mechanism may be needed on the SP 242 interworking interface of NBVPNs. See sections 4.4.1 and 8 for 243 details. 245 3. Logical Architecture Model and Reference Model for NBVPN 247 This section describes the logical architecture model and reference 248 model for NBVPN. These will be used in mapping the NBVPN service 249 descriptions in section 2 to interfaces and MIBs requirements 250 described in section 4. 252 3.1 Logical Architecture Model for NBVPN 254 The logical architecture model for NBVPN describes functions and 255 their relationship for implementing NBVPN. Figure 3.1 shows the 256 logical architecture model. The architecture is based on a real 257 routed IP network. 259 +-------------------------------+ 260 | MIBs and Management Framework | 261 +-------------------------------+ 262 | 263 +------+ Access Logical Logical Access +------+ 264 | User | link +----+ link +----+ link +----+ link | User | 265 | site |--------| LR |=========| LR |=========| LR |--------| site | 266 +------+ +----+ +----+ +----+ +------+ 268 LR: Logical router 270 Figure 3.1: Logical architecture model. 272 +----+ Logical link +----+ +----+ 273 | |=============================| LR |-------+ US | 274 +----+ | | +----+ +----+ 275 | US +-------| LR | 276 +----+ | | Logical link +----+ +----+ 277 | |=============================| LR |-------+ US | 278 +----+ +----+ +----+ 280 +----+ +----+ +----+ +----+ +----+ +----+ 281 | US +-------| | | | | |======| LR |-------+ US | 282 +----+ | LR |======| | | | +----+ +----+ 283 +----+ | | | | | | 284 | US +-------| | | LR |=====| LR | 285 +----+ +----+ | | | | 286 +----+ +----+ | | | | +----+ +----+ 287 | US +-------| LR |======| | | |======| LR |-------+ US | 288 +----+ +----+ +----+ +----+ +----+ +----+ 290 US: User site 292 Figure 3.2: Example configurations 293 applying the logical architecture model. 295 Figure 3.1 shows a generalized model. It can represent various NBVPN 296 configurations, as shown in Figure 3.2. The entities in the logical 297 architecture model are described below. 299 o Logical router 301 A logical router supports router functions dedicated to a serving 302 NBVPN. It has the following functions. 304 - Routing function: A logical router creates, modifies, and 305 maintains entries in a routing table of the serving NBVPN using 306 routing protocols. 308 - Forwarding function: A logical router forwards IP packets within 309 the NBVPN by looking up entries in the routing table. 311 - Access control function: A logical router may control access 312 (packet filtering and address translation) from other NBVPNs or 313 from the Internet. 315 o User site 317 A user site is one or more subnetworks that are part of an NBVPN. 319 o Logical link 321 A logical link is a connection (isolated from other NBVPNs and the 322 Internet) between logical routers whose serving NBVPNs are 323 identical. A logical link is terminated by logical routers. 325 o Access link 327 An access link provides a user site with access to services 328 associated with a specific NBVPN. Note that a physical facility 329 may multiplex multiple access lines, but this is outside the scope 330 of this model. 332 o MIBs and management framework 334 These represent MIBs for managing the customer configuration 335 associated with the concerned VPN, MIBs for managing logical 336 routers, and other devices constructing the concerned NBVPN and 337 associated managing functions. 339 3.2 Reference Model 341 In order to clarify possible mapping between the logical architecture 342 model given in section 3.1 and implementation as well as to clarify 343 the targets of the standardization work, this section describes a 344 reference model illustrating the reference configuration of the 345 NBVPN. Figure 3.3 shows the reference model. 347 : +--------------------------------------+ : 348 : | | : +------+ 349 +------+ : | +------+ +------+ : | CE | 350 | CE | : | | | | | : |device| 351 |device| : | | PE | | PE | : | of | 352 | of | : +------+ Tunnel : |router| : Tunnel |router|--:-|NBVPN | 353 |NBVPN |-:--| |========:===| |===:========| | : | A | 354 | A | : | | : +------+ : +------+ : +------+ 355 +------+ : | PE | : : | : 356 +------+ : |router| Network-facing-side interface | : 357 | CE | : | | : +------+ : +------+ 358 |device|-:--| |================:===============| |--:-| CE | 359 | of | : +------+ : | PE | : |device| 360 |NBVPN | : | | | |router| : | of | 361 | B | : | +------+------+ +-----+-----+ | | : |NBVPN | 362 +------+ : | |NMS for | |NMS for | +------+ : | B | 363 : | |customer MIBs| |device MIBs| | : +------+ 364 : | +-------------+ +-----------+ | : 365 : | | : 366 : +--------------------------------------+ : 367 : |<------------ Network(s) ------------>| : 368 : | single or multiple SP domains | : 369 : : 370 Customer-facing- Customer-facing- 371 side interface side interface 373 Figure 3.3: Reference model. 375 o Customer edge (CE) device 377 A CE device is usually a router located at the edge of a user site. 378 It may also be a host or hosts belonging to a subnetwork. A CE 379 device belongs to only one NBVPN, although it can reach other 380 NBVPNs through a CUG interconnection service. It is usually 381 accommodated by a single PE router. However, four types of double- 382 homing arrangements, shown in Figure 3.4, must be supported. 384 +---------------- +--------------- 385 | | 386 +------+ +------+ 387 +---------| PE | +---------| PE | 388 | |router| | |router| Network 389 | +------+ | +------+ 390 +------+ | +------+ | 391 | CE | | | CE | +--------------- 392 |device| | Network |device| +--------------- 393 +------+ | +------+ | 394 | +------+ | +------+ 395 | | PE | | | PE | 396 +---------|router| +---------|router| Network 397 +------+ +------+ 398 | | 399 +---------------- +--------------- 400 This type includes a CE device connected 401 to a PE router via two access lines. 402 (a) (b) 404 +---------------- +--------------- 405 | | 406 +------+ +------+ +------+ +------+ 407 | CE |-----| PE | | CE |-----| PE | 408 |device| |router| |device| |router| Network 409 +------+ +------+ +------+ +------+ 410 | | | | 411 | Backdoor | | Backdoor +--------------- 412 | link | Network | link +--------------- 413 | | | | 414 +------+ +------+ +------+ +------+ 415 | CE | | PE | | CE | | PE | 416 |device|-----|router| |device|-----|router| Network 417 +------+ +------+ +------+ +------+ 418 | | 419 +---------------- +--------------- 421 (c) (d) 423 Figure 3.4: Four types of double-homing arrangements. 425 o Networks 427 NBVPN services are provided by one or more networks to CE devices 428 as members of the concerned NBVPN. These networks support PE 429 routers, tunnels, NMSs for customers and device MIBs. In this 430 document, "a network" means a single domain of an SP. The NBVPN 431 operation in a network is outsourced to an SP, but the whole NBVPN 432 operation may be spread over multiple SPs. 434 o Tunnel 436 A tunnel is a connection between PE routers. Multiple logical 437 links defined in section 3.1 may be multiplexed into a single 438 tunnel. A number of IP tunneling protocols have been proposed, but 439 in this document, three different tunneling mechanisms--that is 440 MPLS, GRE, and IPsec--are considered to support NBVPN. A single 441 NBVPN may make use of a mixture of tunneling mechanisms. 443 When MPLS is used for the tunneling mechanism, LSPs implement 444 tunnels and two multiplexing schemes are supported. The first 445 scheme uses two-layer label stacking of the MPLS. In this scheme, 446 the multiple logical links identified by second labels are 447 multiplexed in the tunnel identified by the top label. The second 448 scheme is applicable when the MPLS network is implemented by ATM, 449 and it uses the CPCS user-to-user field in the AAL5 trailer or the 450 VPN-ID field in the VPN encapsulation header [RFC2684]. In this 451 scheme, the multiple logical links in the tunnel are identified by 452 the CPCS-UU or VPN-ID field respectively. 454 When GRE is used for the tunneling mechanism and the key field 455 extension is supported, the logical links are identified by the key 456 field. Note that if the key field is not present, the tunnel 457 supports only one logical link. When IPsec is used, they are 458 identified by the SPI field. 460 Note that when the tunnel is provided by GRE or IPsec, it may pass 461 through another tunneling mechanism (e.g., an IPsec tunnel over an 462 MPLS network). In this document, a tunnel is identical to the 463 tunnel that directly multiplexes logical links and does not include 464 underlying tunneling mechanisms. 466 Figure 3.5 illustrates logical link multiplexing. Multiple logical 467 links supporting connections for NBVPNs are multiplexed into a 468 tunnel. This arrangement allows multiplexing of logical links of 469 different NBVPNs. 471 +-------------+ +-------------+ 472 | PE router | Tunnel | PE router | 473 | | +----------------------------+ | | 474 | +-------+ | : : | +-------+ | 475 | | LR of |========================================| LR of | | 476 | |NBVPN A| | : Logical link : | |NBVPN A| | 477 | +-------+ | : : | +-------+ | 478 | +-------+ | : : | +-------+ | 479 | | LR of |========================================| LR of | | 480 | |NBVPN B| | : Logical link : | |NBVPN B| | 481 | +-------+ | : : | +-------+ | 482 | +-------+ | : : | +-------+ | 483 | | LR of |========================================| LR of | | 484 | |NBVPN C| | : Logical link : | |NBVPN C| | 485 | +-------+ | : : | +-------+ | 486 | | +----------------------------+ | | 487 +-------------+ +-------------+ 489 Figure 3.5: Logical link multiplexing. 491 o Provider edge (PE) router 493 A PE router implements one or more logical routers. It is usually 494 located at the edge of an SP network. It may terminate access 495 links. In this document, the virtual router (VR) [VPN-VR] and VPN 496 routing and forwarding (VRF) tables [VPN-2547BIS] approaches are 497 considered as methods of implementing logical routers in a PE 498 router. 500 VR is a technology for implementing a router function in a PE 501 router. A PE router may contain more than one VR and a VR supports 502 only one NBVPN. A logical router can be implemented with a VR. A 503 VR forwards user traffic from a CE device or another VR, which 504 belonging to the same NBVPN, to another CE device or VR via an 505 access or logical link respectively. For the dynamic routing 506 service described in section 2.4, a VR also forwards route 507 information inside user sites, which is received from a CE device 508 or another VR, to another CE device or VR as user traffic. 510 The distinctive feature of this approach is that the current 511 routing protocols are applicable between VRs or PE routers without 512 any extensions or modifications. Thus, it can be implemented 513 without difficulty and managed simply. However, an extension for a 514 routing protocol between PE routers has been proposed to support 515 auto-setup of tunnels and auto-discovery of PE router topology and 516 NBVPN membership [VPN-BGP-VR]. 518 A VRF table is a packet routing and forwarding table and a user 519 site corresponds to a VRF table. In a PE router, each logical 520 router can be implemented with an entity of routing protocol 521 between PE routers whose processing is based on VRF tables. Based 522 on the route information of a VRF table in a PE router, user 523 traffic received from a CE device or another PE router is forwarded 524 to another CE device or PE router via an access or logical link 525 respectively. For the dynamic routing service, a PE router 526 distributes route information inside user sites, which is received 527 from a CE device or another PE router, to another CE device or PE 528 router using routing protocol between PE routers. See 529 [VPN-2547BIS] for detail. 531 This approach requires an extension of the route information format 532 to distinguish the same IPv4 addresses belonging to different 533 NBVPNs and an extension of the routing protocol between PE routers 534 to distribute the extended route information. Currently, 535 extensions for BGP-4 protocol have been proposed. Furthermore, for 536 a dynamic routing service, when CE devices and PE routers in an 537 NBVPN exchange route information inside user sites using OSPF, IS- 538 IS, or RIP, and if different CE devices must belong to the same 539 OSPF, IS-IS, or RIP domain, extensions which correspond to these 540 protocols are required for the routing protocol between PE routers. 542 However, in this approach, the number of routing protocol entities 543 in a PE router does not depend on the number of NBVPNs supported by 544 the PE router, so it achieves high scalability. This approach 545 assumes the use of LSP with two-layer label stacking as the 546 tunneling mechanism, and basically, multiple logical links 547 identified by second labels are multiplexed in the tunnel 548 identified by the top label. Therefore, the tunnel enables high- 549 speed packet forwarding, because the forwarding processing does not 550 refer to the second label which reflects the number of NBVPNs 551 supported by the PE router. 553 In this approach, a VRF table can support more than one NBVPNs, so, 554 a user site is able to belong to multiple NBVPNs. However, the 555 overlapping address space between NBVPNs can be allocated only when 556 the NBVPNs have no common user sites. That is, if two NBVPNs have 557 the common address space, a user site can belong to only one NBVPN. 558 And if an NBVPN has a private address space and it is 559 interconnected to the Internet via NAT, the user traffic must be 560 forwarded to a CE device where the NAT is located. Therefore in 561 this case, this approach does not optimize routing paths in the 562 network(s) providing the NBVPN. 564 o NMS for customer MIB 565 An NMS that manages customer MIBs of an NBVPN. 567 o NMS for device MIB 569 An NMS that manages device MIBs of an NBVPN. 571 3.3 Classification of Network-facing-side Interface 573 In this section, the network-facing-side interface shown in Figure 574 3.3 is classified into three specific interfaces. 576 It is not necessary for a single SP's whole network to be constructed 577 with a uniform technology. As shown in Figure 3.6, different 578 subnetworks may be implemented with different technologies. In this 579 case, a PE router must be placed at the edge of a subnetwork 580 interconnecting with another subnetwork that is based on another 581 technology. In this document, it is called a subnetwork edge (SE) 582 router. 584 +-----------------------------------------------------------+ 585 | +-----------------+ +-----------------+ | 586 | | | | +----+ 587 +----+Tunnel: +----+Tunnel: +----+Tunnel: | | 588 | |======:======| |======:======| |======:======| PE | 589 | | : | | : | | : | | 590 | | Intra- | | Subnetwork | | Intra- +----+ 591 | | subnetwork | |interworking | | subnetwork | | 592 | PE | interface | SE | interface | SE | interface | | 593 | | : | | : | | : +----+ 594 | | : | | : | | : | | 595 | |Tunnel: | |Tunnel: | |Tunnel: | PE | 596 | |======:======| |======:======| |======:======| | 597 +----+ : +----+ : +----+ : +----+ 598 | | : | : | : | | 599 | +-----------------+ +-----------------+ | 600 | |<-Subnetwork(s)->| |<-Subnetwork(s)->| | 601 | implemented with implemented with | 602 | a uniform technology a uniform technology | 603 | | 604 +-----------------------------------------------------------+ 605 |<------------------------ Network ------------------------>| 607 Figure 3.6: Intra-subnetwork interface and 608 subnetwork interworking interface. 610 +-----------------------------------------------------------+ 611 | +-----------------+ +-----------------+ | 612 | | | | +----+ 613 +----+ Tunnel +----+Tunnel: +----+ Tunnel | | 614 | |=============| |======:======| |=============| PE | 615 | | | | : | | | | 616 | | | | SP | | +----+ 617 | | | |interworking | | | | 618 | PE | | IE | interface | IE | | | 619 | | | | : | | +----+ 620 | | | | : | | | | 621 | | Tunnel | |Tunnel: | | Tunnel | PE | 622 | |=============| |======:======| |=============| | 623 +----+ +----+ : +----+ +----+ 624 | | | : | | | 625 | +-----------------+ +-----------------+ | 626 | |<----Network---->| |<----Network---->| | 627 | | 628 +-----------------------------------------------------------+ 629 |<------------------------ Networks ----------------------->| 631 Figure 3.7: SP interworking interface. 633 Similarly, when a single NBVPN spans multiple SPs, PE routers should 634 be placed at every SP interconnecting point as shown in Figure 3.7. 635 In this document, they are called inter-provider edge (IE) routers. 637 In the rest of this document, SE and IE routers are also simply 638 called "PE routers" unless they need to be differentiated. 640 The intra-subnetwork interface and subnetwork interworking interface 641 are defined as shown in Figure 3.6. The former interface exists 642 between a pair of PE routers and is restricted to one or more 643 subnetworks implemented with a uniform technology. The latter 644 interface exists between a pair of SE routers and connects two 645 subnetworks implemented with different technologies. The SP 646 interworking interface is defined as shown in Figure 3.7. It exists 647 between a pair of IE routers and connects two SP networks. 649 3.4 Targets of the Standardization Work and Protocol Architecture 651 The targets of the standardization work are the following two 652 interfaces and MIBs illustrated in the reference model given in 653 Figures 3.3, 3.6, and 3.7. 655 o Customer-facing-side interface 657 An interface between a CE device and a PE router. 659 o Network-facing-side interface 661 An interface between PE routers. This interface is further 662 classified into the following three interfaces. 664 - Intra-subnetwork interface 666 - Subnetwork interworking interface 668 - SP interworking interface 670 o Customer MIBs 672 MIBs of NBVPN customer attributes. 674 o Device MIBs 676 MIBs of device attributes, covering PE routers and other devices 677 constructing the concerned NBVPN. 679 To clarify the protocol architecture on the network-facing-side 680 interface, protocols on the interface are classified into the u- and 681 c-planes. 683 The u-plane provides forwarding of user traffic between CE devices 684 belonging to the same NBVPN. For the dynamic routing service 685 implemented with the VR approach, a VR forwards route information 686 inside user sites to another VR as user traffic via a logical link. 687 Therefore, this protocol is included in the u-plane. Tunneling 688 protocols that connect PE routers belong to the u-plane protocols. 689 However, tunnel setup protocols are included in the c-plane. 691 The c-plane provides auto-discovery of PE routers topology and NBVPN 692 membership. It also provides auto-setup of tunnels based on the PE 693 routers topology information. For the dynamic routing service 694 implemented with the VRF approach, it provides distribution of route 695 information inside user sites between PE routers. Routing protocols 696 between PE routers and control protocols for MPLS and IPsec belong to 697 the c-plane. Note that GRE is not equipped with standard ways to set 698 up and maintain GRE tunnels. 700 4. Requirements for Interfaces and MIBs 702 4.1 General Requirements 704 The implementation providing an NBVPN must: 706 o be scalable 707 o be manageable 709 o enable a single NBVPN to span multiple subnetworks implemented with 710 different technologies. For example, a single NBVPN must be able 711 to span IPsec- and MPLS-based-subnetworks. 713 o enable a single NBVPN to span multiple SPs. 715 4.2 Requirements for Identifiers 717 This section clarifies the requirements for the identifiers to 718 describe the requirements for the interfaces and MIBs. Several 719 identifiers are defined, as illustrated in Figure 4.1. 721 Note that not all protocols and MIBs specified in section 3.4 need to 722 support all identifiers described in this section. However, 723 supported identifiers must be the same as, logically equivalent to, 724 or inclusive of identifiers described in this section. 726 TUNNEL-ID TUNNEL-ID 727 LLINK-ID| |LLINK-ID 728 PE-ID | | | | PE-ID 729 | | | | | | 730 LPORT-ID | | | | | | 731 CE-ID | | | | | | | 732 | | V | V Tunnel V | V 733 | | +----+ | +-+---------------------------+-+ | +----+ 734 | | | | V : Logical link : V | | 735 V | | |=+===================================+=| | 736 +----+ V | | : Logical link : | SE | 737 | | | | |=+===================================+=| | 738 | CE +-+--| | : : | | 739 | | | | | +-+---------------------------+-+ +----+ 740 +----+ | | 741 | | Tunnel LPORT-ID 742 +----+ | | PE | +-+---------------------------+-+ +----+ | CE-ID 743 | +-+--| | : Logical link : | | | | 744 | | | | |=+===================================+=| | | V 745 | | | | : Logical link : | | V +----+ 746 | CE | | |=+===================================+=| | | | | 747 | | | | : Logical link : | |--+-+ CE | 748 | | | | |=+===================================+=| | | | | 749 | +-+--| | : : | | +----+ 750 +----+ | | | +-+---------------------------+-+ | PE | 751 +----+ | | 752 Tunnel | | +----+ 753 +----+ +-+---------------------------+-+ | | | | | 754 | | : Logical link : | |--+-+ CE | 755 | |=+===================================+=| | | | | 756 | IE | : Logical link : | | +----+ 757 | |=+===================================+=| | 758 | | : : | | 759 +----+ +-+---------------------------+-+ +----+ 761 Figure 4.1: Identifiers. 763 o SP-ID, which identifies each SP, must be unique at least within all 764 the interconnected networks of SPs. (In practice, it should be 765 globally unique.) This is necessary when a single NBVPN spans 766 multiple SPs. 768 o VPN-ID, which identifies each NBVPN, must be unique at least within 769 each SP's network. 771 o CE-ID, which identifies each CE device, must be unique at least 772 within each SP's network. 774 o PE-ID, which identifies each PE router, must be unique at least 775 within each SP's network. The PE-ID of an IE must be unique at 776 least within all the interconnected SP networks. 778 Note: One of the IP addresses assigned to an edge device is usually 779 used as PE-ID. 781 o LPORT-ID, which identifies a logical port, must be unique at least 782 within each PE router containing the logical port. Here, a logical 783 port represents a terminating point of an access link accommodating 784 a user site. 786 o TUNNEL-ID, which identifies each tunnel, must be unique at least 787 within each PE router supporting the tunnel. 789 o LLINK-ID, which identifies each logical link, must be unique at 790 least within each tunnel supporting the logical link. 792 The scope of the identifiers is summarized in Figure 4.2. It shows 793 that the right-side identifier must be unique at least within the 794 scope of the left-side identifier for each arrow. 796 SP-ID +--> VPN-ID 797 | 798 +--> CE-ID 799 | 800 +--> PE-ID +--> LPORT-ID 801 | 802 +--> TUNNEL-ID ---> LLINK-ID 804 Figure 4.2: Scope of identifiers. 806 When a single NBVPN spans multiple SPs, their identifiers, except for 807 SP-ID, must satisfy one of the following conditions: 1) their 808 mappings are predefined, 2) their mappings are dynamically built by a 809 protocol, or 3) they are linked together with the SP-ID. 811 The association among the identifiers must satisfy the following 812 requirements. 814 o The CE-ID must be mapped to one or more pairs of PE-ID and LPORT-ID 815 to configure the accommodation of CE devices. Note that it is not 816 necessary for the mapping to be built in a one-to-one manner 817 because a CE device may be connected to PE routers through multiple 818 access links as shown in Figures 3.4(a) and (b). In this case, the 819 CE-ID must be mapped to all the concerned pairs of PE-ID and LPORT- 820 ID. 822 o The CE-ID must be uniquely mapped to the VPN-ID to distinguish the 823 NBVPN associated with the CE device. 825 o A pair of PE-ID and LPORT-ID must be uniquely mapped to the VPN-ID 826 to distinguish the NBVPN associated with the logical port. 828 o A set of PE-ID, TUNNEL-ID, and LLINK-ID must be uniquely mapped to 829 the VPN-ID to support a logical link. 831 4.3 Requirements for Customer-facing-side Interface 833 This section describes the requirements for the customer-facing-side 834 interface shown in Figure 3.3. 836 o Packet encapsulation 838 Every packet must have the usual IP packet format without VPN-aware 839 encapsulation, except in the case of providing multiprotocol 840 transport service where every packet must have a protocol-specific 841 packet format without VPN-aware encapsulation. 843 o QoS/SLA 845 For QoS/SLA service, every access link connecting a CE device and a 846 PE router must support the specified QoS/SLA. 848 o Dynamic routing 850 For dynamic routing service, different routing protocols must be 851 supported per access link connecting a CE device and a PE router. 853 4.4 Requirements for Network-facing-side Interface 855 This section describes the requirements for the three specific 856 network-facing-side interfaces shown in Figures 3.3, 3.6, and 3.7. 858 4.4.1 Requirements for protocols on u-plane 860 o Packet encapsulation 862 Every packet must be encapsulated with the LLINK-ID. Multiprotocol 863 transport service requires multiprotocol-over-IP encapsulation. 865 o QoS/SLA 867 For QoS/SLA service, every tunnel or logical link must support the 868 specified QoS/SLA per NBVPN. Note that if QoS/SLA support is per- 869 tunnel based, it can support only one logical link. 871 o Note on security 873 If a tunnel on the SP interworking interface is not implemented 874 with a direct circuit between IE routers and it passes through an 875 unsecure SP, POP, NAP, or IX, then security mechanisms should be 876 located at the edge routers. However, this security and NBVPN 877 service mechanisms are independent, so the detailed specifications 878 of the security mechanism depend on the implementation. See 879 sections 2.8 and 8 for security discussions. 881 4.4.2 Requirements for protocols on c-plane 883 o Tunnel setup and maintenance 885 To set up tunnels between PE routers, every PE router must support 886 static configuration for tunneling and may support a tunnel setup 887 protocol. When PE routers support the protocol, the information 888 exchanged between them includes the VPN-ID, TUNNEL-ID, QoS/SLA 889 information for QoS/SLA service, and multiprotocol-over-IP 890 encapsulation information for multiprotocol transport service. 892 A protocol for monitoring tunnel states must be supported. 894 A protocol for tunnel restoration must be supported. 896 For multicast service, multicast traffic must be forwarded through 897 the created tunnels. 899 o Auto-discovery of PE routers topology and NBVPN membership 901 For auto-discovery of PE routers topology and NBVPN membership, 902 extensions for routing protocol between PE routers may be needed. 904 Routing protocols on the SP interworking interface may support 905 authentication. 907 If policy routing is performed, routing protocols running between 908 IE routers on the SP interworking interface may specify 909 intermediate SPs by SP-ID in route distribution and then routing 910 protocols running between IE routers on the intra-subnetwork and 911 subnetwork interworking interface may also specify intermediate SPs 912 by SP-ID in route distribution. 914 o Dynamic routing 916 For dynamic routing service implemented with the VRF approach, 917 routing protocols running between IE routers must support route 918 control independently per NBVPN. 920 4.5 Requirements for Customer MIB 922 This section describes the requirements for the customer MIB shown in 923 Figure 3.3. 925 o Management information about CE devices and customer attributes of 926 NBVPN must be configured and maintained. The information includes 927 the CE-ID, PE-ID, LPORT-ID, VPN-ID, access control policy 928 information for CUG interconnection service, routing protocols used 929 for dynamic routing or multicast service, and QoS/SLA information 930 for QoS/SLA service. 932 4.6 Requirements for Device MIB 934 This section describes the requirements for the device MIB shown in 935 Figure 3.3. 937 o The configuration and maintenance of PE routers must be supported. 938 Their management information includes IP routing information and 939 access control policy information for CUG interconnection service. 940 For multiprotocol transport service, protocol-specific routing 941 information must be managed instead of IP routing information. 943 o The mappings between the LPORT-ID and VPN-ID must be configured and 944 maintained. For QoS/SLA service, the mappings between LPORT-ID and 945 QoS/SLA information must also be configured and maintained. 947 o Tunnel information must be configured and maintained. It includes 948 the TUNNEL-ID, LLINK-ID, tunnel states, and QoS/SLA information for 949 QoS/SLA service. 951 o Routing protocols running between PE routers and CE devices must be 952 configured and maintained per NBVPN. For multicast service, 953 multicast routing protocols must also be supported. 955 o Routing protocols running between PE routers must be configured and 956 maintained. For multicast service, multicast routing protocols 957 must also be supported. 959 5. Outline of Interface and MIB Specifications 961 (To be written) 963 6. Survey of Available Technologies 965 The technologies surveyed in this section are relevant to NBVPNs. 966 The framework, however, neither compels nor excludes their use. 968 6.1 Tunneling 970 Tunneling mechanisms provide isolated and secure communication 971 between two CE devices. Available tunneling mechanisms include (but 972 are not limited to): MPLS [MPLS-ARCH] [MPLS-FRAME] [MPLS-ATM], GRE 973 [RFC2784] [RFC2890], and IPsec [RFC2401] [RFC2402]. In an NBVPN, a 974 tunnel is a secure communication path within a network. A PE router 975 encapsulates a data packet incoming from a CE device, and injects it 976 into an appropriate tunnel. The data packet traverses the network, 977 and reaches the PE router on the far side. In the course of 978 traversal, the data packet may have transferred to other tunnels, if 979 necessary. The PE router then retrieves the data packet from a 980 tunnel, and passes it to the destination CE device. 982 6.1.1 MPLS [MPLS_ARCH] [MPLS_FRAME] [MPLS-ATM] 984 Multiprotocol Label Switching (MPLS) is a method for forwarding 985 packets through a network. Routers at the edge of a network apply 986 simple labels to packets. A label may be inserted between the data 987 link and network headers, or may be carried in the data link header 988 (e.g., the VPI/VCI field in an ATM header). Routers in the network 989 switch packets according to the labels with minimal lookup overhead. 990 A path, or a tunnel in the NBVPN, is called a "label switched path 991 (LSP)." 993 o Multiplexing 995 LSPs may be multiplexed into another LSP. 997 o Multiprotocol transport 999 MPLS can carry data packets other than IP ones. 1001 o QoS/SLA 1003 MPLS does not have intrinsic QoS or SLA management mechanisms. 1004 Some other techniques such as DiffServ may be used with it [DIFF- 1005 MPLS]. 1007 o Tunnel setup and maintenance 1009 LSPs are set up and maintained by LDP (Label Distribution Protocol) 1010 or RSVP (Resource Reservation Protocol) [LSP-RSVP]. 1012 o Large MTUs, minimization of tunnel overhead, and frame sequencing 1014 MPLS does not restrict the MTU size. The overhead of label 1015 switching should be minimal. MPLS guarantees in-order delivery of 1016 packets. 1018 6.1.2 GRE [RFC2784] [RFC2890] 1020 Generic Routing Encapsulation (GRE) specifies a protocol for 1021 encapsulating an arbitrary payload protocol over an arbitrary 1022 delivery protocol [RFC2784]. In particular, it may encapsulate an IP 1023 payload packet over IP. An endpoint encapsulates and decapsulates 1024 GRE packets. A GRE tunnel is a communication path between two 1025 endpoints established by the use of GRE. 1027 o Multiplexing 1029 The GRE specification [RFC2784] does not support multiplexing. But 1030 the key field extension to GRE is specified in [RFC2890] and it may 1031 be used as a multiplexing field. 1033 o Multiprotocol transport 1035 GRE is assumed to support any type of payload protocol. 1037 o QoS/SLA 1039 These capabilities depend on the delivery protocol. 1041 o Tunnel setup and maintenance 1043 GRE is not equipped with standard ways for setting up and 1044 maintaining GRE tunnels. 1046 o Large MTUs, minimization of tunnel overhead, and frame sequencing 1048 These capabilities depend on the delivery protocol, but the GRE 1049 header overhead is designed to be minimal. The sequence field 1050 proposed in [RFC2890] may be used to achieve in-order delivery. 1052 6.1.3 IPsec [RFC2401] [RFC2402] [RFC2406] [RFC2409] 1054 IP Security (IPsec) provides security services at the IP layer 1055 [RFC2401]. It comprises authentication header (AH) protocol 1056 [RFC2402], encapsulating security payload (ESP) protocol [RFC2406], 1057 and Internet key exchange (IKE) protocol [RFC2409]. AH protocol 1058 provides data integrity, data origin authentication, and an anti- 1059 replay service. ESP protocol provides data confidentiality and 1060 limited traffic flow confidentiality. It may also provide data 1061 integrity, data origin authentication, and an anti-replay service. 1062 AH and ESP may be used in combination. 1064 IPsec may be employed in either transport or tunnel mode. In 1065 transport mode, either an AH or ESP header is inserted between the 1066 IPv4 header and the transport protocol header. In tunnel mode, an IP 1067 packet is encapsulated with an outer IP packet header. Either an AH 1068 or ESP header is inserted between them. AH and ESP establish a 1069 unidirectional secure communication path between two endpoints, which 1070 is called a security association. In tunnel mode, two security 1071 associations compose a tunnel between PE routers. IKE protocol is 1072 used to exchange encryption keys among IPsec endpoints. 1074 o Multiplexing 1076 The SPI field of AH and ESP is used to multiplex security 1077 associations (or tunnels) within a tunnel. 1079 o Multiprotocol transport 1081 IPsec needs extensions to carry packets other than IP ones. 1082 Alternatively, GRE may be used with it. 1084 o QoS/SLA 1086 IPsec itself does not have intrinsic QoS/SLA capabilities. Other 1087 mechanisms such as "RSVP Extensions for IPSEC Data Flows" [RFC2207] 1088 or DiffServ may be used with it. 1090 o Tunnel setup and maintenance 1092 IKE is used for the setup and maintenance of tunnels. 1094 o Large MTUs, minimization of tunnel overhead, and frame sequencing 1096 IPsec does not restrict the MTU size. IPsec may impose its own 1097 overhead. IPsec has a sequence number field that is used by a 1098 receiver to perform an anti-replay check, not to guarantee in-order 1099 delivery of packets. 1101 Note: IPsec is applicable to a CPE-based VPN as well as to an NBVPN. 1102 This document deals with the aspects of IPsec that are relevant to an 1103 NBVPN. 1105 6.2 VPN Identifiers 1107 An NBVPN spanning multiple autonomous systems requires the use of a 1108 globally unique VPN identifier such as "a pair of an autonomous 1109 system-number and a VPN-index local to the autonomous system" and the 1110 "global VPN identifier" as specified in [RFC2685]. A globally unique 1111 VPN identifier may be included in an MIB for the VPN configuration. 1112 It may also be included in an encapsulation header of a data packet 1113 or may be exchanged as a parameter of signaling messages. 1115 The global VPN identifier defined in [RFC2685] consists of a 3-byte 1116 VPN organizationally unique identifier that identifies a VPN 1117 administrative authority, and a 4-byte VPN index that identifies the 1118 VPN within the context of a given VPN administrator. The VPN 1119 encapsulation header defined in [RFC2684] supports the global VPN 1120 identifier. But it must be noted that the global VPN identifier, 1121 which is 56 bits long, does not fit into the 20-bit MPLS label or 1122 into the 32-bit IPsec SPI field. 1124 6.3 Routing 1126 Dynamic routing service as defined in section 2 requires the exchange 1127 of routing information between a network and user sites. A list of 1128 applicable technologies is given in section 6.3.1. The network may 1129 terminate a routing protocol, or it may transfer routing information 1130 between user sites transparently. 1132 The network must maintain its routing configuration with integrity. 1133 The applicable technologies are listed in section 6.3.2. 1135 6.3.1 Exchange of routing information between network and user sites 1137 The following technologies are available for the exchange of routing 1138 information between a network and user sites. 1140 o Static routing 1142 Routing tables may be configured through a management system. 1144 o RIP (Routing Information Protocol) [RFC2453] 1146 RIP is an interior gateway protocol and is used within an 1147 autonomous system. It sends out routing updates at regular 1148 intervals and whenever the network topology changes. Routing 1149 information is then propagated by the adjacent routers to their 1150 neighbors and thus to the entire network. A route from a source to 1151 a destination is the path with the least number of routers. This 1152 number is called the "hop count" and its maximum value is 15. This 1153 implies that RIP is suitable for a small- or medium-sized networks. 1155 o OSPF (Open Shortest Path First) [RFC1583] 1157 OSPF is an interior gateway protocol and is applied to a single 1158 autonomous system. Each router distributes the state of its 1159 interfaces and neighboring routers as a link-state advertisement, 1160 and maintains a database describing the autonomous system's 1161 topology. A link-state is advertised every 30 minutes or when the 1162 topology is reconfigured. 1164 Each router maintains an identical topological database, from which 1165 it constructs a tree of shortest-paths with itself as the root. 1166 The algorithm is known as the Shortest Path First or SPF. The 1167 router generates a routing table from the tree of shortest-paths. 1168 OSPF supports a variable length subnet mask, which enables 1169 effective use of the IP address space. 1171 OSPF allows sets of networks to be grouped together into an area. 1172 Each area has its own topological database. The topology of the 1173 area is invisible from outside its area. The areas are 1174 interconnected via a "backbone" network. The backbone network 1175 distributes routing information between the areas. The area 1176 routing scheme can reduce the routing traffic and compute the 1177 shortest-path trees and is indispensable for larger-scale networks. 1179 Each multi-access network with multiple routers attached has a 1180 designated router. The designated router generates a link state 1181 advertisement for the multi-access network and synchronizes the 1182 topological database with other adjacent routers in the area. The 1183 concept of designated router can thus reduce the routing traffic 1184 and compute shortest-path trees. To achieve high availability, a 1185 backup designated router is used. 1187 o IS-IS (intermediate system to intermediate system) [RFC1195] 1189 IS-IS is a routing protocol designed for the OSI (Open Systems 1190 Interconnection) protocol suites. Integrated IS-IS is derived from 1191 IS-IS in order to support the IP protocol. In the Internet 1192 community, IS-IS means integrated IS-IS. In this, a link-state is 1193 advertised over a connectionless network service. IS-IS has the 1194 same basic features as OSPF. They include: link-state 1195 advertisement and maintenance of a topological database within an 1196 area, calculation of a tree of shortest-paths, generation of a 1197 routing table from a tree of shortest-paths, the area routing 1198 scheme, a designated router, and a variable length subnet mask. 1200 o BGP4 (Border Gateway Protocol version 4) [RFC1771] 1202 BGP4 is an exterior gateway protocol and is applied to the routing 1203 of inter-autonomous systems. A BGP speaker establishes a session 1204 with other BGP speakers and advertises routing information to them. 1205 A session may be an External BGP (EBGP) that connects two BGP 1206 speakers within different autonomous systems, or an internal BGP 1207 (IBGP) that connects two BGP speakers within a single autonomous 1208 system. Routing information is qualified with path attributes, 1209 which differentiate routes for the purpose of selecting an 1210 appropriate one from possible routes. Also, routes are grouped by 1211 the community attribute [RFC1997] [BGP-COM]. 1213 The IBGP mesh size tends to increase dramatically with the number 1214 of BGP speakers in an autonomous system. BGP can reduce the number 1215 of IBGP sessions by dividing the autonomous system into smaller 1216 autonomous systems and grouping them into a single confederation 1217 [RFC1965]. Route reflection is another way to reduce the number of 1218 IBGP sessions [RFC1966]. BGP divides the autonomous system into 1219 clusters. Each cluster establishes the IBGP full-mesh within 1220 itself, and designates one or more BGP speakers as "route 1221 reflectors," which communicate with other clusters via their route 1222 reflectors. Route reflectors in each cluster maintain path and 1223 attribute information across the autonomous system. The autonomous 1224 system still functions like a fully meshed autonomous system. On 1225 the other hand, confederations provide finer control of routing 1226 within the autonomous system by allowing for policy changes across 1227 confederation boundaries, while route reflection requires the use 1228 of identical policies. 1230 6.3.2 Exchange of routing information within a network 1232 The following technologies can be used for exchanging routing 1233 information within a network. 1235 o Static routing (see section 6.3.1) 1237 o RIP (see section 6.3.1) 1239 o OSPF (see section 6.3.1) 1241 o BGP (see section 6.3.1) 1243 o Multiprotocol BGP4 [RFC2858] 1245 BGP4 has been extended to support IPv6, IPX, and others as well as 1246 IPv4 [RFC2283]. Multiprotocol BGP4 carries routes from multiple 1247 "address families." 1249 o Extended BGP4 [VPN-2547BIS] 1251 Extended BGP4 is a specific extension to Multiprotocol BGP4. The 1252 notion of "VPN-IPv4 address family" is introduced in [VPN-2547BIS]. 1253 A VPN-IPv4 address is 12 bytes long and consists of an 8-byte route 1254 distinguisher (RD) and a 4-byte IPv4 address. Overlapping of the 1255 IPv4 address space among multiple NBVPNs is resolved by using 1256 different RDs. Scalable configurations can be achieved by the use 1257 of route reflectors. 1259 6.4 QoS/SLA 1261 The following technologies for QoS/SLA are applicable to an NBVPN. 1263 6.4.1 ATM [AF-TM-0121.000] 1265 Asynchronous transfer mode (ATM) provides several service categories, 1266 such as CBR (constant bit rate) service, VBR (variable bit rate) 1267 service, and GFR (guaranteed frame rate) service. CBR service is 1268 used to guarantee a static amount of bandwidth. VBR service is 1269 designed for a wide range of applications, including real-time and 1270 non-real-time applications. GFR service is designed for applications 1271 that may require a minimum rate guarantee and can benefit from 1272 accessing additional bandwidth. 1274 6.4.2 IntServ/RSVP [RFC2205] [RFC2208] [RFC2210] [RFC2746] [RSVP-LSP] 1276 The integrated service, or IntServ for short, is a mechanism for 1277 providing QoS/SLA by admission control. RSVP is used to reserve 1278 network resources. The network needs to maintain a state for each 1279 reservation. The number of states in the network increases in 1280 proportion to the number of concurrent reservations. 1282 6.4.3 DiffServ [RFC2474] [RFC2475] 1284 The differentiated service, or DiffServ for short, is a mechanism for 1285 providing QoS/SLA by differentiating traffic. Traffic entering a 1286 network is classified into several behavior aggregates at the 1287 network-edge and each is assigned a corresponding DiffServ codepoint. 1288 Within the network, traffic is treated according to its DiffServ 1289 codepoint. Some behavior aggregates have already been defined. 1290 Expedited forwarding behavior [RFC2598] guarantees the QoS, whereas 1291 assured forwarding behavior [RFC2597] differentiates traffic packet 1292 precedence values. 1294 7. Criteria for Achieving Interoperability 1296 (To be written) 1298 8. Security Considerations 1300 As described in section 2.8, if a user requires stronger security 1301 than that of the basic CUG service, it should be provided by a CPE- 1302 based security mechanism. This is because a network-based solution 1303 cannot ensure the security of access links between user sites and 1304 network. 1306 As described in section 4.4.1, if a tunnel on the SP interworking 1307 interface is not implemented with direct circuit between IE routers 1308 and it passes through an unsecure SP, POP, NAP, or IX, then security 1309 mechanisms should be located at the edge routers. However, detailed 1310 specifications of this security mechanism depend on the 1311 implementation, so it is not discussed in this framework. 1313 Acknowledgments 1315 VPNs are a huge technology and without the early work of RFC2764 "A 1316 Framework for IP Based Virtual Private Networks," it would have been 1317 impossible for us to complete this framework document. We would like 1318 to thank the authors of RFC2764, especially Bryan Gleeson of Nortel 1319 Networks. 1321 We would also like to thank Joel Halpern of Longitude Systems, Eric 1322 Rosen of Cisco Systems, and Kazuo Kobayashi for their valuable 1323 comments and suggestions. 1325 References 1327 [RFC2764] Gleeson, B. et al., "A Framework for IP Based Virtual 1328 Private Networks," RFC2764, February 2000. 1330 [RFC2547] Rosen, E. and Rekhter, Y., "BGP/MPLS VPN," RFC2547, March 1331 1999. 1333 [RFC2684] Grossman, D. and Heinanen, J., "Multiprotocol Encapsulation 1334 over ATM Adaptation Layer 5," RFC2684, September 1999. 1336 [RFC2685] Fox B. and Gleeson, B., "Virtual Private Networks 1337 Identifier," RFC2685, September 1999. 1339 [VPN-2547BIS] Rosen, E. et al., "BGP/MPLS VPNs," Internet-draft 1340 , July 2000. 1342 [VPN-BGP-OSPF] Rosen, E., "OSPF as the PE/CE Protocol in BGP/MPLS 1343 VPNs," Internet-draft , July 1344 2000. 1346 [VPN-BGP-IPSEC] De Clercq, J. et al., "BGP/IPsec VPN," Internet-draft 1347 , July 2000. 1349 [VPN-BGP-VR] Ould-Brahim, H. et al., "BGP/VPN: VPN Information 1350 Discovery for Network-based VPNs," Internet-draft , July 2000. 1353 [VPN-VR] Ould-Brahim H. et al., "Network based IP VPN Architecture 1354 Using Virtual Routers," Internet-draft , July 2000. 1357 [VPN-IPSEC] Lordello, C. et al, "VPN-ID-Enhanced IPSec-VPN DOI for 1358 ISAKMP," Internet-draft , August 1359 2000. 1361 [VPN-INTER] Sumimoto, J. et al., "MPLS VPN Interworking" Internet- 1362 Draft ," February 2000. 1364 [RFC2917] Muthukrishnan, K. and Malis, A., "A Core MPLS IP VPN 1365 Architecture," RFC2917, September 2000. 1367 [MPLS-ARCH] Rosen E. et al., "Multiprotocol Label Switching 1368 Architecture," Internet-draft , July 1369 2000. 1371 [MPLS-FRAME] Callon, R. et al., "A Framework for Multiprotocol Label 1372 Switching," , September 1999. 1374 [MPLS-ATM] Davie, B. et al., "MPLS using LDP and ATM VC Switching," 1375 Internet-draft , June 2000. 1377 [MPLS-DIFF] Le Faucheur, F. et al., "MPLS Support of Differentiated 1378 Services," Internet-draft , August 1379 2000. 1381 [MPLS-GMNCL] GMN-CL home page: 1382 http://www.gmncl.ecl.ntt.co.jp/top_e.html 1384 [RFC2784] Farinacci, D. et al., "Generic Routing Encapsulation 1385 (GRE)," RFC2784, March 2000. 1387 [RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE," 1388 RFC2890, September 2000. 1390 [RFC2401] Kent, S. and Atkinson, R., "Security Architecture for the 1391 Internet Protocol," RFC2401, November 1998. 1393 [RFC2402] Kent, S. and Atkinson, R., "IP Authentication Header," 1394 RFC2402, November 1998. 1396 [RFC2406] Kent, S. and Atkinson, R., "IP Encapsulating Security 1397 Payload (ESP)," RFC2406, November 1998. 1399 [RFC2409] Harkins, D. and Carrel, D., "The Internet Key Exchange 1400 (IKE)," RFC2409, November 1998. 1402 [RFC2453] Malkin, G., "RIP Version 2," RFC2453, November 1994. 1404 [RFC2328] Moy, J., "OSPF Version 2," RFC2328, April 1998. 1406 [RFC1195] Callon, R., "Use of OSI IS-IS for Routing in TCP/IP and 1407 Dual Environments," RFC1195, December 1990. 1409 [RFC1771] Rekhter, Y. and Li, T., "A Border Gateway Protocol 4 1410 (BGP-4)," RFC1771, March 1995. 1412 [RFC1965] Traina, P., "Autonomous System Confederations for BGP," 1413 RFC1965, June 1996. 1415 [RFC1966] Bates, T., "BGP Route Reflection: An alternative to full 1416 mesh IBGP," RFC 1966, June 1996. 1418 [RFC1997] Chandra, R., Traina, P., and Li, T., "BGP Communities 1419 Attribute," RFC1997, August 1996. 1421 [RFC2858] Bates, T., Chandra, R., Katz, D., and Rekhter, Y., 1422 "Multiprotocol Extensions for BGP-4," RFC2283, February 1998. 1424 [BGP-COM] Ramachandra, S., "BGP Extended Communities Attribute," 1425 Internet-draft , May 1426 2000. 1428 [AF-TM-0121.000] "Traffic Management Specification Version 4.1," ATM 1429 Forum, March 1999. 1431 [RFC2205] Braden, R. et al., "Resource ReSerVation Protocol (RSVP) -- 1432 Version 1 Functional Specification," RFC2205, September 1997. 1434 [RFC2208] Mankin, A. et al., "Resource ReSerVation Protocol (RSVP) 1435 Version 1 Applicability Statement Some Guidelines on Deployment," 1436 RFC2208, September 1997. 1438 [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated 1439 Services," RFC2210, September 1997. 1441 [RFC2211] Wroclawski, J., "Specification of the Controlled-Load 1442 Network Element Service," RFC2211, September 1997. 1444 [RFC2212] Shenker, S., Partridge, C., and Guerin, R., "Specification 1445 of Guaranteed Quality of Service," RFC2212, September 1997. 1447 [RFC2207] Berger, L. and O'Malley, T., "RSVP Extensions for IPSEC 1448 Data Flows," RFC2207, September 1997. 1450 [RFC2746] Terzis, A. et al., "RSVP Operation Over IP Tunnels," 1451 RFC2746, January 2000. 1453 [RSVP-LSP] Awduche, D. et al., "Extensions to RSVP for LSP Tunnels," 1454 Internet-draft , August 2000. 1456 [RFC2474] Nichols, K. et al., "Definition of the Differentiated 1457 Services Field (DS Field) in the IPv4 and IPv6 Headers," RFC2474, 1458 December 1998. 1460 [RFC2475] Blake S. et al., "An architecture for Differentiated 1461 Services," RFC2475, December 1998. 1463 [RFC2597] Heinanen, J. et al., "Assured Forwarding PHB Group," 1464 RFC2597, June 1999. 1466 [RFC2598] Jacobsen, V. et al., "An Expedited Forwarding PHB," 1467 RFC2598, June 1999. 1469 [RFC2983] Black, D., "Differentiated Services and Tunnels," RFC2983, 1470 October 2000. 1472 10. Authors' addresses 1474 Muneyoshi Suzuki 1475 NTT Information Sharing Platform Labs. 1476 3-9-11, Midori-cho, 1477 Musashino-shi, Tokyo 180-8585, Japan 1478 Email: suzuki.muneyoshi@lab.ntt.co.jp 1480 Junichi Sumimoto 1481 NTT Information Sharing Platform Labs. 1482 3-9-11, Midori-cho, 1483 Musashino-shi, Tokyo 180-8585, Japan 1484 Email: sumimoto.junichi@lab.ntt.co.jp 1485 Andrew G. Malis 1486 Vivace Networks, Inc. 1487 2730 Orchard Parkway 1488 San Jose, CA 95134, USA 1489 Email: Andy.Malis@vivacenetworks.com 1491 Karthik Muthukrishnan 1492 Lucent Technologies 1493 1 Robbins Road 1494 Westford, MA 01886, USA 1495 Email: mkarthik@lucent.com 1497 Kosei Suzuki 1498 NTT Information Sharing Platform Labs. 1499 3-9-11, Midori-cho, 1500 Musashino-shi, Tokyo 180-8585, Japan 1501 Email: suzuki.kosei@lab.ntt.co.jp 1503 Hiroshi Kurakami 1504 NTT Information Sharing Platform Labs. 1505 3-9-11, Midori-cho, 1506 Musashino-shi, Tokyo 180-8585, Japan 1507 Email: kurakami.hiroshi@lab.ntt.co.jp 1509 Takafumi Hamano 1510 NTT Information Sharing Platform Labs. 1511 3-9-11, Midori-cho, 1512 Musashino-shi, Tokyo 180-8585, Japan 1513 Email: hamano.takafumi@lab.ntt.co.jp 1515 Naoto Makinae 1516 NTT Information Sharing Platform Labs. 1517 3-9-11, Midori-cho, 1518 Musashino-shi, Tokyo 180-8585, Japan 1519 Email: makinae.naoto@lab.ntt.co.jp 1521 Kenichi Kitami 1522 NTT Information Sharing Laboratory Group 1523 3-9-11, Midori-cho, 1524 Musashino-shi, Tokyo 180-8585, Japan 1525 Email: kitami.kenichi@lab.ntt.co.jp