idnits 2.17.1 draft-scharf-alto-vpn-service-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 3 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (February 13, 2014) is 3724 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-27) exists of draft-ietf-alto-protocol-25 == Outdated reference: A later version (-03) exists of draft-randriamasy-alto-cost-schedule-02 == Outdated reference: A later version (-03) exists of draft-roome-alto-pid-properties-00 == Outdated reference: A later version (-09) exists of draft-wu-alto-te-metrics-00 Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force M. Scharf, Ed. 3 Internet-Draft V. Gurbani, Ed. 4 Intended status: Informational G. Soprovich 5 Expires: August 17, 2014 V. Hilt 6 Alcatel-Lucent 7 February 13, 2014 9 The Virtual Private Network (VPN) Service in ALTO: Use Cases, 10 Requirements and Extensions 11 draft-scharf-alto-vpn-service-02 13 Abstract 15 The Application-Layer Traffic Optimization (ALTO) protocol is 16 designed to allow entities with knowledge about the network 17 infrastructure to export such information to applications that need 18 to choose one or more resources from a candidate set. This document 19 provides motivation for using ALTO in a Virtual Private Network (VPN) 20 environment. We discuss use cases, requirements, and possible 21 extensions to the base ALTO protocol that will be needed to support 22 VPN services. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on August 17, 2014. 41 Copyright Notice 43 Copyright (c) 2014 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3. Encompassing example . . . . . . . . . . . . . . . . . . . . 4 61 3.1. A VPN scenario . . . . . . . . . . . . . . . . . . . . . 4 62 3.2. Exemplary use of ALTO . . . . . . . . . . . . . . . . . . 6 63 4. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 9 64 4.1. Use case 1: Application guidance in an L3VPN . . . . . . 10 65 4.2. Use case 2: Application guidance in an L2VPN . . . . . . 11 66 4.3. Use case 3: VPN guidance without addresses . . . . . . . 12 67 4.4. Use case 4: Extending the VPN . . . . . . . . . . . . . . 13 68 4.5. Use case 5: Shrinking the VPN . . . . . . . . . . . . . . 14 69 4.6. Use case 6: VPN selection . . . . . . . . . . . . . . . . 14 70 4.7. Use case 7: Other use cases . . . . . . . . . . . . . . . 14 71 5. Requirements and potential solutions . . . . . . . . . . . . 15 72 5.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 15 73 5.2. Potential Solutions . . . . . . . . . . . . . . . . . . . 16 74 6. Security considerations . . . . . . . . . . . . . . . . . . . 17 75 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 17 76 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 77 8.1. Normative References . . . . . . . . . . . . . . . . . . 18 78 8.2. Informative References . . . . . . . . . . . . . . . . . 18 79 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 18 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 82 1. Overview 84 Virtual Private Network (VPN) technology is widely used in public and 85 private networks to create groups of users that are separated from 86 other users of the network and allows these users to communicate 87 among them as if they were on a private network. According to 88 [RFC4364], the generic term "Virtual Private Network" is used to 89 refer to a specific set of sites as either an intranet or an extranet 90 that have been configured to allow communication. A site is a member 91 of at least one VPN and may be a member of many. 93 Service providers offer different types of VPNs. [RFC4026] 94 distinguishes between Layer 2 VPN (L2VPN) and Layer 3 VPN (L3VPN) 95 using different sub-types. Virtual Private LAN Service (VPLS) is an 96 L2VPN provider service that emulates the full functionality of a 97 traditional Local Area Network (LAN) [RFC4762]. A VPLS makes it 98 possible to interconnect several LAN segments over a packet switched 99 network. 101 Another solution is an L3VPN, which interconnects sets of hosts and 102 routers based on Layer 3 addresses. In this context, a virtual 103 private network is defined in [RFC4364] as follows: 105 Consider a set of "sites" that are attached to a common network 106 that we call "the backbone". Now apply some policy to create a 107 number of subsets of that set, and impose the following rule: two 108 sites may have IP interconnectivity over that backbone only if at 109 least one of these subsets contains them both. 111 These subsets are Virtual Private Networks (VPNs). Two sites have 112 IP connectivity over the common backbone only if there is some VPN 113 that contains them both. Two sites that have no VPN in common 114 have no connectivity over that backbone. 116 VPNs can also include "pseudo L1/L2" connectivity, such as pseudowire 117 emulation (PWE) carrying legacy TDM or ATM circuits for point to 118 point connectivity. Further examples are integrated optical 119 solutions delivering light paths or integrated optical and Ethernet 120 transport. It is instructive to note that point-to-point VPN 121 services of this type rarely carry VPN edge addresses within the 122 network; e.g., packets are encapsulated and transported without any 123 kind of address facing the customer drop side of the network. 125 A VPN may also include mechanisms to enhance the level of separation 126 (e.g., by end-to-end encryption), but the discussion of such 127 mechanisms is outside the scope of this document. In the following, 128 the term "VPN" is used to refer to provider supplied virtual private 129 networking. 131 The ALTO protocol [I-D.ietf-alto-protocol] is designed to provide 132 network information (e.g., basic network location structure, 133 preferences of network paths) with the goal of modifying network 134 resource consumption patterns while maintaining or improving 135 application performance. The most important use case is providing 136 application guidance in the global Internet, so that applications do 137 not have to perform excessive measurements on their own. For the 138 very same reason, topology exposure is also very useful in VPNs. But 139 the constraints for using ALTO in L3VPNs or L2VPNs differ from the 140 public Internet. This document presents these use cases and 141 discusses requirements and extensions to the base ALTO protocol that 142 will be needed to realize the VPN Service in ALTO. 144 2. Terminology 146 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 147 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 148 document are to be interpreted as described in [RFC2119]. 150 3. Encompassing example 152 3.1. A VPN scenario 154 Below, we present an example for a VPN scenario that describes an 155 environment for an ALTO VPN Service. This scenario is subsequently 156 used to analyze specific use cases. 158 We consider the following: there are two distinct entities, one, the 159 network service provider (NSP) who owns the network and offers a VPN 160 to the second entity, the customer, who has premises in four 161 different locations that shall be interconnected by that VPN. The 162 sites could be office branches, data centers, etc. Throughout this 163 document, we assume the following four sites: 165 o Site 1 167 Location name: SITE-CHICAGO 169 Geography Degree: 41.85 N, 87.65 W 171 o Site 2 173 Location name: SITE-OTTAWA 175 Geography Degree: 45.24 N, 75.43 W 177 o Site 3 179 Location name: SITE-SANFRANCISCO 181 Geography Degree: 37.75 N, 122.28 W 183 o Site 4 185 Location name: SITE-PARIS 187 Geography Degree: 48.86 N, 2.35 E 189 It is assumed that these sites are interconnected by a VPN that may 190 be identified by the hypothetical name "vpn42". This document 191 specifically considers two different VPN types for the 192 interconnection: 194 o L3VPN: The local area networks at each site will have a certain IP 195 subnet ranges, for instance 10.0.1.0/24 at site 1, 10.0.2.0/24 at 196 site 2, etc. 198 o L2VPN: All sites form part for a flat sub-IP network, e.g. a 199 logical Ethernet segment. Different to a local network, the 200 network potentially interconnects geographically remote sites. 202 The VPN will not necessarily be static. The customer could possibly 203 modify the VPN and add new VPN sites, e. g., to handle peak-load 204 demand or to consolidate VPN sites to account for reduced traffic. 205 The service provider could offer a Web portal or other Operation 206 Support Systems (OSS) solutions that allow the customer to grow or 207 consolidate the VPN. Details on how the customer can configure VPNs 208 are outside the scope of this document. 210 Furthermore, we assume that the customer is running at least one 211 application that can benefit from application-level traffic 212 optimization, e.g., using application-internal routing mechanisms or 213 placement functions. For instance, typical uses cases for VPN 214 customers could be: 216 o Enterprise application optimization: Enterprise customers often 217 run distributed applications that exchange large amounts of data, 218 e.g., for synchronization of replicated data bases. Both for 219 placement of replicas as well as for the scheduling of transfers 220 insight into network topology information could be useful. 222 o Private cloud computing solution: An enterprise customer could run 223 own data centers at the four sites. The cloud management system 224 could want to understand the network costs between different sites 225 for intelligent routing and placement decisions of Virtual 226 Machines (VMs) among the VPN sites. 228 o Cloud-bursting: One or more VPN endpoints could be located in a 229 public cloud. If an enterprise customer needs additional 230 resources, they could be provided by a public cloud, which is 231 accessed through the VPN. Network topology awareness would help 232 to decide in which data center of the public cloud those resources 233 should be allocated. 235 These examples focus on enterprise customers of NSPs, which are 236 typical users of provider-supplied VPNs. Such VPN customers 237 typically have no insight into the network topology that transports 238 the VPN. For instance, the actual delay between two VPN sites may 239 significantly depend on the routing in the NSP MPLS/IP network. If 240 better-than-random decisions are required, applications have to rely 241 on own measurements. An alternative would by guidance by an ALTO 242 server offered by the NSP. 244 It is important to emphasize that other scenarios and use cases exist 245 and the examples enunciated so far are merely used to illustrate how 246 ALTO can be used in a VPN context. A common characteristic of these 247 use cases is that applications will not necessarily run in the public 248 Internet, and they will typically not be accessed by residential 249 customers. The internal use of ALTO by a specific application is not 250 considered in this document. 252 3.2. Exemplary use of ALTO 254 In the example VPN described in the previous section, it would be 255 beneficial if an ALTO server would expose cost maps or provide a 256 ranking service that represents the costs between different sites, e. 257 g., endpoints of the VPN. Similar to existing use cases of ALTO, 258 this enables an application integrating an ALTO client to use this 259 information for application-level traffic optimization. This results 260 in the following scenario: 262 +---------------+ 263 | Customer's | 264 | management | 265 | application |. 266 | (ALTO client) | . 267 +---------------+ . VPN provisioning 268 ^ . (out-of-scope) 269 | ALTO . 270 V . 271 +---------------------+ +----------------+ 272 | ALTO server | | VPN portal/OSS | 273 | provided by NSP | | (out-of-scope) | 274 +---------------------+ +----------------+ 275 ^ VPN network 276 * and cost maps 277 * 278 /---------*---------\ Network service provider 279 | * | 280 +-------+ _______________________ +-------+ 281 | App a | ()_____. .________. .____() | App d | 282 +-------+ | | | | | | +-------+ 283 San Francisco \---| |--------| |--/ Paris 284 | | | | 285 |^| |^| Customer VPN 286 V V 287 +-------+ +-------+ 288 | App b | | App c | 289 +-------+ +-------+ 290 Chicago Ottawa 292 Figure 1: Overview of an ALTO usage scenario 294 The network service provider could operate an ALTO server. An ALTO 295 client in an application could then retrieve an ALTO cost map by 296 querying a corresponding URI, such as: 298 uri: http://alto.nsp.org/vpn42/costmap 300 The NSP can assign PIDs to each of the VPN endpoints; this renders 301 computations at the ALTO server to fit in the current model of using 302 the protocol. A corresponding example would be: 304 Site 1: PID "pid14" 306 Site 2: PID "pid21" 308 Site 3: PID "pid11" 309 Site 4: PID "pid27" 311 The example below further expands on the VPN by demonstrating the 312 resulting network topology provided to an ALTO server. The picture 313 corresponds to the VPN of the customer and also includes the Provider 314 Edge (PE) routers and Customer Edge (CE) devices: 316 ___________________________ 317 San Francisco / Network service provider \ Paris 318 Site 3 | Internal MPLS/IP network | Site 4 319 | | 320 ___|_##_____________________##_|___ 321 /\ /\ 322 10.0.3.0/24<-#-( ) L3VPN "vpn42" ( )-#->10.0.4.0/24 323 "pid11" CE \/_________ _____ _________\/ CE "pid27" 324 device | ## | | | | ## | device 325 | PE | | | | PE | 326 | | | | | | 327 | PE #| |# #| |# PE | 328 \______| _ |_____| _ |______/ 329 |/ \| |/ \| 330 \_/ \_/ 331 | | 332 CE device # # CE device 333 | | 334 V V 335 Site 1 Site 2 336 Chicago Ottawa 337 10.0.1.0/24 10.0.2.0/24 338 "pid14" "pid21" 340 Figure 2: Example for mapping of VPN sites to ALTO PIDs 342 The costs exposed by the ALTO server can be based on routing costs 343 inside the service provider network or other network topology 344 information, such as delay measurements, traffic engineering (TE) 345 data, etc. As with other use cases of ALTO, the costs can reflect 346 the service provider's preference and policies regarding 347 communication between the involved VPN endpoints. 349 Generally, two different types of applications can consume the 350 information provided by the ALTO server. The first class can be 351 composed of discrete application instances executing at the various 352 sites that are interconnected by the VPN. ALTO is used to optimize 353 the routing or resource consumption among those application 354 instances. A typical examples is a distributed database, i.e., an 355 enterprise backend system. In Figure 1, these application instances 356 are referred to as "App a", "App b", "App c", and "App d". Generally 357 speaking, this usage mirrors the canonical use of ALTO in 358 unstructured P2P networks or Content Delivery Networks (CDN) networks 359 whereby a rendezvous is desired between a consumer and a plurality of 360 producers. In this document, we label this class of applications by 361 the term "user applications". 363 The second class represents management applications that typically 364 work on VPN level. In addition to consulting an ALTO server provided 365 by the NSP, this type of application possibly has its own 366 understanding of what resources are available at different sites, and 367 it could possibly even trigger more complex actions such a building 368 out VPNs, e. g., by contacting a VPN portal of the NSP. In Figure 1, 369 as well as the rest of this document, uses the term "management 370 application" for this use case. An example would be an orchestration 371 solution for cloud computing resources. It could use the topology 372 and cost maps illustrated in Figure 2 to control VPN placement. In 373 principle, management applications have some similarity to 374 centralized resource directories in P2P networks (e. g., trackers), 375 which are an important existing use case for ALTO. Yet, unlike 376 resource directories in the Internet, a VPN typically interconnects 377 mainly sites within one administrative domain. 379 There may also be an overlap between both types of applications. 380 Furthermore, in particular for the first class of applications, the 381 customer could run an own ALTO server, which could expose topology 382 map and cost maps with further details only visible to the VPN 383 customer (e.g., network segments behind NATs). Since such 384 information is independent of the use of a VPN and typically not 385 known to an NSP, these usage scenarios are not further detailed in 386 this memo. 388 4. Use cases 390 Current VPNs provide no clear mechanism to convey information about 391 the network infrastructure to management or user applications using 392 that VPN, e.g. regarding preferences or topological properties of the 393 network service provider network. Applications thus have to rely on 394 other mechanisms such as local measurements to optimize their 395 traffic. The ALTO protocol has been designed to overcome such 396 limitations in the Internet. ALTO, being a well-established, 397 generic, and flexible protocol, can be used in VPNs, too. 399 We now present various use cases that exhibit the utility of 400 considering a VPN extension of ALTO. Through a series of use cases 401 we demonstrate how a VPN customer and the NSP can use ALTO; we also 402 highlight similarities and differences when using ALTO in the general 403 Internet. 405 4.1. Use case 1: Application guidance in an L3VPN 407 The NSP providing the L3VPN service can offer an ALTO server that 408 exposes network and cost information to applications running traffic 409 over that VPN. Since an L3VPN is IP-based, this use case is in 410 principle similar to the use cases already addressed by the ALTO base 411 protocol. 413 Example 1: Consider the customer in Section 3.1 that has four VPN 414 sites. A user application in one site (say Site 1) would now like to 415 find out which of the other sites (Site 2 to Site 4) are 416 topologically close to Site 1, perhaps to determine where to 417 replicate a certain data set. A corresponding ALTO query would 418 return the costs between those sites. The user application could 419 then select a host in the corresponding subnetwork and connect to 420 that endpoint. 422 Example 2: In addition to network proximity information, the user 423 application could also be interested in guidance regarding network 424 parameters that cannot be measured directly. For instance, a 425 relevant parameter for a VPN site could be the level of redundancy 426 for that VPN site, e.g., whether there is resilience by network 427 protection schemes in the NSP network. 429 Example 3: It is quite common for VPN Customer Equipment (CE) to be 430 multi-homed at the Provider Edge (PE). A CE may well home into to 431 several PE routers and thus may have different network cost 432 functions. For instance, assume that in Site 1 the CE will peer to a 433 local PE1 and remote PE2. The cost to reach Site 2 in the VPN could 434 be 1575 for PE1 and 2250 for PE2. The CE will thus choose to steer 435 traffic from Site 1 to Site 2 toward PE1. While the realization of 436 such traffic steering is outside the scope of this document, CE 437 multi-homing places an explicit need to expose more than one set of 438 network costs for a VPN endpoint. 440 In principle, the existing ALTO services such as network and cost map 441 can provide such guidance. However, it is important to note that a 442 VPN might not run in a public environment. The IP address ranges 443 inside a VPN might not be globally unique or routable. Furthermore, 444 a provider based VPN service normally maintains a strict separation 445 between service provider addressing (such as addresses or Provider 446 Edge routers) and customer addressing. As a result, an ALTO server 447 will not expose the internal IP addressing of the network service 448 provider, making it difficult to identify services using IP addresses 449 in general. In a BGP L3VPN, the VPRN BGP Route Distinguisher could 450 possibly be used as a service identifier, but it is unclear whether 451 an application of a customer or the ALTO client will indeed know such 452 network-internal information of the NSP and whether the NSP would 453 want to expose it. Also, it would make sense to define an ALTO VPN 454 extension independent of a specific VPN technology. 456 The network costs in a VPN depends on VPN topology, which needs to be 457 taken into consideration when calculating ALTO information. Given 458 that VPNs are often offered by a single network service provider, 459 ALTO cost information could include information that may be available 460 for a single autonomous system, but difficult to gather in the 461 Internet as a whole. Examples would be the provisioned bandwidth, 462 network-internal latencies, or the path resilience. In a static VPN 463 environment e.g. with a reserved resources in an MPLS/IP wide area 464 network, these costs can be assumed to be rather stable and e. g. 465 reflect the reserved bandwidth between VPN sites. For an application 466 it is simpler and less intrusive to obtain such information about the 467 VPN from the network instead of performing measurements, which would 468 possibly require special probe instances at the different VPN sites 469 (e. g., data centers). But as the encoding of such costs in ALTO is 470 independent of the usage of a VPN, this document does not mandate any 471 specific way how to build ALTO cost maps. 473 This memo does not argue that ALTO shall be used as a generic data 474 center information exchange protocol. For instance, a general data 475 center resource information model has been suggested in 476 [I-D.lee-alto-ext-dc-resource]. According to that model, the ALTO 477 server also includes data-center information not related at all to 478 the network, such as compute resources, memory, power consumption, 479 etc. While VPNs are an important technology to interconnect data 480 centers, the ALTO VPN service solely focuses on networking cost. 482 4.2. Use case 2: Application guidance in an L2VPN 484 The use case outlined in Example 1 also exists for L2VPNs, which are 485 an important technology to transparently interconnect different LAN 486 segments of enterprise users. Again, applications could benefit from 487 getting insight into topological properties of the wide area network 488 providing the L2VPN service, in order to avoid the overhead of own 489 measurements. 491 Example 4: The user application described in Section 3.1 again wants 492 to find out how well connected (topologically close) Site 1 is to 493 Site 2, 3, or 4. Different from the previous example, all sites are 494 now part of the same Layer 2 subnet. Another example for an 495 application that would benefit from ALTO is a cloud management 496 system. Such a management application could be interested in finding 497 out whether migrating of a Virtual Machine from Site 1 to another 498 site would improve performance, perhaps due to better connectivity or 499 lower latency. 501 While this use case is in principle similar to the previous one, 502 there is a major difference regarding addressing: Unlike the L3VPN, 503 an L2VPN is not necessarily IP-based; it may use MAC addresses 504 instead of IP addresses. While IP addresses can be aggregated easily 505 and represented succinctly using CIDR notation, MAC addresses do not 506 lend themselves to such aggregation and representation. Furthermore, 507 MAC addresses are not useful to applications themselves. And 508 finally, MAC addresses may not readily be known and available to an 509 ALTO server of the network service provider. And even if they are, 510 an ALTO map using MAC addresses will be very large. In summary, use 511 of MAC addresses is not scalable and nor does it denote any hierarchy 512 that can be used for aggregation. Some other means of identifying 513 services and hosts will be required when using ALTO in L2VPNs. 515 4.3. Use case 3: VPN guidance without addresses 517 The VPN interconnects different sites through the network service 518 provider's network. An application might be interested in getting 519 topology information among those sites without knowing actual 520 addresses or identifiers used internally by the VPN. In fact, a VPN 521 site may not even have an address known or visible to applications, 522 e.g., a pseudo-wire VPN. 524 Example 5: A management application might ask for all VPN sites (i. 525 e., corresponding PIDs) that have a delay less than 40ms or a routing 526 cost less than 55, from VPN Site 1. A specific example for such an 527 application might be cloud management system that uses application- 528 level traffic optimization mechanisms. In the scenario introduced in 529 Section 3.1, such an application may have a-priori information, 530 learned from e.g. a VPN portal, about the VPN type and/or VPN 531 identifiers ("vpn42") as well as some unique site identifier such as 532 "SITE-CHICAGO" but no network addresses. The query could also be 533 more complex or include constraints, e. g., limited to a particular 534 TE class. Note that the ATLO protocol does not necessarily have to 535 support the query constraint itself; if corresponding maps are 536 available, the application can analyze the data itself. 538 Example 6: In absence of well-known existing network identifiers, a 539 management application might want to query for VPN sites based on yet 540 other attributes, such as geographical distance. For example, an 541 application might want to find all the VPN sites (i. e., 542 corresponding PIDs) within 50 KM of 45.35N, 75.92W. Such geographic 543 queries would be typical of policies bounding delay by geographic 544 distance or administrative and legal requirements. 546 Such application guidance is obviously similar to existing use of the 547 ALTO cost map or ranking services except that the queries are not 548 based on network addresses. 550 4.4. Use case 4: Extending the VPN 552 The customer can possibly grow the VPN to include new sites that are 553 connected at a later time to the VPN. The actual mechanisms for VPN 554 reconfiguration are outside the scope of this document. 556 Example 7: A management application could be interested in guidance 557 for VPN sites that are currently not part of the VPN, but that would 558 be available e. g. to increase capacity or geographic coverage. 559 Assume that two sites Site 1 and Site 2 are already connected to the 560 VPN. Some time later, scale-out to a third site is required, and the 561 application has to decide whether Site 3 or 4 is better suited for a 562 new application instance. This is an realistic example for a cloud 563 management system that is geographically distributed. Such a system 564 would then have to decide whether Site 3 or Site 4 is topologically 565 closer to the existing VPN endpoints, in order to determine the best 566 location from the network point of view. An ALTO server could 567 provide guidance on the offnet distance of Sites 3 and 4 to the 568 existing VPN sites. 570 Apparently, the question whether to actually extend the VPN in a 571 specific way may also include decisions outside the scope of ALTO, 572 such as price information or other commercial or legal policies. The 573 actual VPN re-configuration and attachment of a new site to the VPN 574 topology requires back-office interaction and provisioning actions by 575 separate, orthogonal mechanisms such as a Path Computation Element 576 (PCE). Actual path setup by a PCE is independent from the selection 577 of a suitable target site. But it makes sense to use the well- 578 established ALTO methods in order to get at an early stage network 579 proximity information as input information for the selection and 580 configuration process. Applications typically cannot measure the 581 network performance to destinations not already part of the VPN. 583 For a network service provider, customer guidance for VPN extension 584 by ALTO offers a new possibility to optimize its internal traffic 585 engineering. For instance, an operator could recommend to customers 586 not to connect to a destination operating in protection mode, e.g., 587 after a fiber cut, because in such a case the network may have less 588 sparse resources. Note that a customer is not able to measure such 589 constraints. ALTO is a simple interface to expose such information 590 to applications. 592 From an ALTO perspective, growing VPN sites possibly results in 593 different types of endpoints, some of which may exist a-priory but 594 not be reachable within the VPN. They could possibly be understood 595 as "shadow" PIDs that become active once the VPN is extended. Once 596 the VPN is modified, new endpoints or PIDs may be created, i. e., the 597 ALTO network and cost maps may have to be updated accordingly after 598 the VPN is re-configured. 600 4.5. Use case 5: Shrinking the VPN 602 Much like a VPN may grow dynamically, it can also shrink when the 603 resources in the VPN are underutilized. Instead of keeping the 604 underutilized resources alive, the VPN operator my decide to 605 consolidate the resources and remove sites from the VPN. 607 Example 8: Once again, consider the customer in Section 3.1 that has 608 four VPN sites. Based on low resource demand, the management 609 application may wonder whether Site 1 (Chicago) and Site 2 (Ottawa) 610 can be consolidated, e. g., by moving resources between them. One 611 important constraint for such a decision could network proximity 612 information. After such a consolidation, the VPN network and cost 613 maps will be updated to reflect the new topology. 615 From an ALTO server perspective, this use case is similar to a 616 general application guidance. Yet, there could be a benefit for the 617 service provider to provide special guidance regarding removal of VPN 618 endpoints if there is a benefit for its internal traffic engineering 619 (e. g., consolidation of network resources used by several VPN 620 customers). 622 4.6. Use case 6: VPN selection 624 In a more advanced use case, ALTO could also be a selection function 625 to choose VPNs based on network cost criteria. 627 Example 9: In a multi-homing environment, ALTO could be used to 628 select one VPN out of several candidates to reach a certain 629 destination, taking into account smaller costs, e. g., according to 630 distance or to preferences of the network service provider network. 632 This use case differs from the previous examples since more than one 633 VPN is involved, i. e., the ALTO guidance is not used to perform 634 application-layer traffic optimization within one VPN, but instead 635 across different VPNs. 637 4.7. Use case 7: Other use cases 639 The aforementioned use cases could be complemented by other use of 640 ALTO information. For instance, if applications using the VPN are 641 flexible regarding the timing of data transfers, an ALTO server could 642 provide guidance when and how to schedule such data transfers, 643 possibly with time-shift enhancements. This scenario is further 644 detailed in [I-D.randriamasy-alto-cost-schedule]. 646 5. Requirements and potential solutions 648 5.1. Requirements 650 Based on the scenarios listed in Section 4, several requirements can 651 be derived for a VPN Service in ALTO: 653 REQ 1: The existing ALTO protocol and RESTful interface should be 654 used as far as possible to enable an NSP to expose properties of a 655 VPN. 657 REQ 2: A VPN Service must not require that network service provider 658 expose internal addressing, such as internal addresses or loopback 659 addresses of the Provider Edge (PE) routers. 661 REQ 3: A VPN Service must use the PID concept of the base ALTO 662 protocol as far as possible, i. e., the VPNs and network entities in 663 the VPNs can be identified by PIDs. This permits use of the existing 664 ALTO services such as the map service for VPNs, as well as the 665 inherent topology abstraction provided by ALTO. 667 REQ 4: A VPN Service must be possible for different VPN types, i. e., 668 it must not be limited to L3VPNs only. 670 REQ 5: The VPN Service must support use cases where IP addresses are 671 not the only form of endpoint identification. 673 REQ 6: If IP addresses are used, a VPN Service must not assume that 674 IP address are globally routable or unique. 676 REQ 7: A VPN Service should include certain attributes that are 677 unique to a VPN and that are not represented by the current set of 678 attributes in the base ALTO protocol. Examples include location name 679 of a site, geography coordinates (degree/digital), role, redundancy, 680 default policy, or geography restriction. 682 REQ 8: The PID must be selectable using standard ALTO filtering. A 683 standard interface query should allow finding resources using, say, 684 the location name attribute or the geography attributes. 686 REQ 9: The PID should be selectable using a filter that computes 687 matching sites within a certain distance of a particular geographic 688 coordinate based on latitude and longitude, in case that no other 689 address information is known in advance. 691 REQ 10: Incremental build out (as well as the shrinking) of resources 692 that are part of the VPN must be supported, i. e., the ALTO VPN 693 service should also be able to expose information about new sites to 694 be attached to the VPN, or provide guidance for removal of sites. 696 REQ 11: A VPN Service requires that an ALTO server can report the 697 (expected) connectivity between VPN sites regarding different 698 metrics, including for example geographical distance, delay, or 699 provisioned bandwidth. 701 REQ 12: Information about a VPN must only be exposed to authorized 702 users of that VPN. 704 5.2. Potential Solutions 706 In the following we analyze how the requirements of a VPN Service can 707 be addressed by ALTO extensions. 709 REQ 1: This is an inherent, general requirement for any new use or 710 extension of ALTO. 712 REQ 2: This requirement can be supported in ALTO today, because it is 713 left to the service provider which information to expose e.g. in ALTO 714 cost maps. 716 REQ 3: The PID concept itself is generic and thus can fulfill this 717 requirement. 719 REQ 4: L3VPNs are rather similar to existing use cases of ALTO in the 720 Internet. Insofar as L2VPNs or pseudo-wire VPNs have the notion of 721 some address, ALTO seems to able to handle these through an extension 722 that extends the definition of an address to include other 723 identifiers besides IP addresses. 725 REQ 5: Use of ALTO with network identifiers that are not IP addresses 726 requires work. There is a need to analyze how to name VPNs and 727 endpoints and how to achieve a mapping to the information stored in 728 the ALTO server. One potential approach would be to characterize an 729 endpoint by any identifier that is unique within a map. 731 REQ 6: ALTO can be used as of now with IP address ranges that are not 732 globally routable. However, it must be emphasized that private VPN 733 environments without uplink to the global Internet may only have 734 connectivity to a limited number of IP subnets, i. e., the ALTO 735 server will not be able to provide any reasonable guidance for most 736 parts of the IP address space. Also, the ALTO server operator must 737 take into account that IP address ranges in different VPNs may 738 overlap, possibly also with the transport network infrastructure (e. 739 g., PE routers). 741 REQ 7: Extensions to ALTO will be needed, in particular assignment of 742 properties to PIDs. [I-D.roome-alto-pid-properties] extends the ALTO 743 protocol by defining PID-based properties in much the same way that 744 the original ALTO protocol defines endpoint-based properties. The 745 VPN use case may also benefit from other extensions to ALTO. 746 Representing the network topology as a graph and using TE metrics 747 (e.g., [I-D.wu-alto-te-metrics]) may allow the VPN operator to be 748 better informed about link-level information to grow (or shrink) a 749 new (or existing) VPN. 751 REQ 8: Assuming extensions in REQ 7, filtering should be fairly easy. 752 If a client has to perform complex queries, it could also download 753 all PID properties and execute complex filter logic itself, if full 754 data retrieval is supported by the ALTO server. There is a tradeoff 755 between the complexity of the server and the client. 757 REQ 9: Extensions to ALTO will be needed. In complex cases, client- 758 side execution of the filtering is an alternative. 760 REQ 10: This requirement will possibly require extensions to ALTO, e. 761 g., to distinguish between endpoints that are already attached to the 762 VPN and sites outside the VPN. This can be achieved e.g. by endpoint 763 and/or PID properties. Changes of the VPN topology are likely to 764 change the ALTO maps, i.e., standard ALTO mechanism for incremental 765 updates and push notifications would be of added value. 767 REQ 11: Registration of corresponding metrics is useful. An subset 768 of metrics is described in [I-D.wu-alto-te-metrics]. Further 769 analysis is needed for additional connectivity aspects, such as 770 resilience parameters, shared risk link group (SRLG), etc. 772 REQ 12: Existing authentication and access control mechanisms for 773 ALTO could be sufficient to meet this requirement, subject to further 774 analysis. 776 6. Security considerations 778 TBD. 780 7. IANA considerations 782 TBD. 784 8. References 785 8.1. Normative References 787 [I-D.ietf-alto-protocol] 788 Alimi, R., Penno, R., and Y. Yang, "ALTO Protocol", draft- 789 ietf-alto-protocol-25 (work in progress), January 2014. 791 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 792 Requirement Levels", BCP 14, RFC 2119, March 1997. 794 [RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual 795 Private Network (VPN) Terminology", RFC 4026, March 2005. 797 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 798 Networks (VPNs)", RFC 4364, February 2006. 800 [RFC4762] Lasserre, M. and V. Kompella, "Virtual Private LAN Service 801 (VPLS) Using Label Distribution Protocol (LDP) Signaling", 802 RFC 4762, January 2007. 804 8.2. Informative References 806 [I-D.lee-alto-ext-dc-resource] 807 Lee, Y., Bernstein, G., Dhody, D., and T. Choi, "ALTO 808 Extensions for Collecting Data Center Resource 809 Information", draft-lee-alto-ext-dc-resource-03 (work in 810 progress), January 2014. 812 [I-D.randriamasy-alto-cost-schedule] 813 Randriamasy, S. and N. Schwan, "ALTO Cost Schedule", 814 draft-randriamasy-alto-cost-schedule-02 (work in 815 progress), October 2012. 817 [I-D.roome-alto-pid-properties] 818 Roome, B. and Y. Yang, "PID Property Extension for ALTO 819 Protocol", draft-roome-alto-pid-properties-00 (work in 820 progress), October 2013. 822 [I-D.wu-alto-te-metrics] 823 Wu, W., Lee, Y., Dhody, D., and S. Randriamasy, "ALTO 824 Traffic Engineering Cost Metrics", draft-wu-alto-te- 825 metrics-00 (work in progress), October 2013. 827 Appendix A. Acknowledgements 829 TBD. 831 Authors' Addresses 833 Michael Scharf (editor) 834 Alcatel-Lucent 836 Email: Michael.Scharf@alcatel-lucent.com 838 Vijay K. Gurbani (editor) 839 Alcatel-Lucent 841 Email: vkg@bell-labs.com 843 Greg Soprovich 844 Alcatel-Lucent 846 Email: Greg.Soprovich@alcatel-lucent.com 848 Volker Hilt 849 Alcatel-Lucent 851 Email: volker.hilt@bell-labs.com