Internet DRAFT - draft-scharf-alto-vpn-service

draft-scharf-alto-vpn-service







Internet Engineering Task Force                           M. Scharf, Ed.
Internet-Draft                                           V. Gurbani, Ed.
Intended status: Informational                              G. Soprovich
Expires: August 17, 2014                                         V. Hilt
                                                          Alcatel-Lucent
                                                       February 13, 2014


     The Virtual Private Network (VPN) Service in ALTO: Use Cases,
                      Requirements and Extensions
                    draft-scharf-alto-vpn-service-02

Abstract

   The Application-Layer Traffic Optimization (ALTO) protocol is
   designed to allow entities with knowledge about the network
   infrastructure to export such information to applications that need
   to choose one or more resources from a candidate set.  This document
   provides motivation for using ALTO in a Virtual Private Network (VPN)
   environment.  We discuss use cases, requirements, and possible
   extensions to the base ALTO protocol that will be needed to support
   VPN services.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on August 17, 2014.

Copyright Notice

   Copyright (c) 2014 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of



Scharf, et al.           Expires August 17, 2014                [Page 1]

Internet-Draft              ALTO VPN Service               February 2014


   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Encompassing example  . . . . . . . . . . . . . . . . . . . .   4
     3.1.  A VPN scenario  . . . . . . . . . . . . . . . . . . . . .   4
     3.2.  Exemplary use of ALTO . . . . . . . . . . . . . . . . . .   6
   4.  Use cases . . . . . . . . . . . . . . . . . . . . . . . . . .   9
     4.1.  Use case 1: Application guidance in an L3VPN  . . . . . .  10
     4.2.  Use case 2: Application guidance in an L2VPN  . . . . . .  11
     4.3.  Use case 3: VPN guidance without addresses  . . . . . . .  12
     4.4.  Use case 4: Extending the VPN . . . . . . . . . . . . . .  13
     4.5.  Use case 5: Shrinking the VPN . . . . . . . . . . . . . .  14
     4.6.  Use case 6: VPN selection . . . . . . . . . . . . . . . .  14
     4.7.  Use case 7: Other use cases . . . . . . . . . . . . . . .  14
   5.  Requirements and potential solutions  . . . . . . . . . . . .  15
     5.1.  Requirements  . . . . . . . . . . . . . . . . . . . . . .  15
     5.2.  Potential Solutions . . . . . . . . . . . . . . . . . . .  16
   6.  Security considerations . . . . . . . . . . . . . . . . . . .  17
   7.  IANA considerations . . . . . . . . . . . . . . . . . . . . .  17
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  17
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  18
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  18
   Appendix A.  Acknowledgements . . . . . . . . . . . . . . . . . .  18
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  19

1.  Overview

   Virtual Private Network (VPN) technology is widely used in public and
   private networks to create groups of users that are separated from
   other users of the network and allows these users to communicate
   among them as if they were on a private network.  According to
   [RFC4364], the generic term "Virtual Private Network" is used to
   refer to a specific set of sites as either an intranet or an extranet
   that have been configured to allow communication.  A site is a member
   of at least one VPN and may be a member of many.

   Service providers offer different types of VPNs.  [RFC4026]
   distinguishes between Layer 2 VPN (L2VPN) and Layer 3 VPN (L3VPN)
   using different sub-types.  Virtual Private LAN Service (VPLS) is an
   L2VPN provider service that emulates the full functionality of a



Scharf, et al.           Expires August 17, 2014                [Page 2]

Internet-Draft              ALTO VPN Service               February 2014


   traditional Local Area Network (LAN) [RFC4762].  A VPLS makes it
   possible to interconnect several LAN segments over a packet switched
   network.

   Another solution is an L3VPN, which interconnects sets of hosts and
   routers based on Layer 3 addresses.  In this context, a virtual
   private network is defined in [RFC4364] as follows:

      Consider a set of "sites" that are attached to a common network
      that we call "the backbone".  Now apply some policy to create a
      number of subsets of that set, and impose the following rule: two
      sites may have IP interconnectivity over that backbone only if at
      least one of these subsets contains them both.

      These subsets are Virtual Private Networks (VPNs).  Two sites have
      IP connectivity over the common backbone only if there is some VPN
      that contains them both.  Two sites that have no VPN in common
      have no connectivity over that backbone.

   VPNs can also include "pseudo L1/L2" connectivity, such as pseudowire
   emulation (PWE) carrying legacy TDM or ATM circuits for point to
   point connectivity.  Further examples are integrated optical
   solutions delivering light paths or integrated optical and Ethernet
   transport.  It is instructive to note that point-to-point VPN
   services of this type rarely carry VPN edge addresses within the
   network; e.g., packets are encapsulated and transported without any
   kind of address facing the customer drop side of the network.

   A VPN may also include mechanisms to enhance the level of separation
   (e.g., by end-to-end encryption), but the discussion of such
   mechanisms is outside the scope of this document.  In the following,
   the term "VPN" is used to refer to provider supplied virtual private
   networking.

   The ALTO protocol [I-D.ietf-alto-protocol] is designed to provide
   network information (e.g., basic network location structure,
   preferences of network paths) with the goal of modifying network
   resource consumption patterns while maintaining or improving
   application performance.  The most important use case is providing
   application guidance in the global Internet, so that applications do
   not have to perform excessive measurements on their own.  For the
   very same reason, topology exposure is also very useful in VPNs.  But
   the constraints for using ALTO in L3VPNs or L2VPNs differ from the
   public Internet.  This document presents these use cases and
   discusses requirements and extensions to the base ALTO protocol that
   will be needed to realize the VPN Service in ALTO.





Scharf, et al.           Expires August 17, 2014                [Page 3]

Internet-Draft              ALTO VPN Service               February 2014


2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

3.  Encompassing example

3.1.  A VPN scenario

   Below, we present an example for a VPN scenario that describes an
   environment for an ALTO VPN Service.  This scenario is subsequently
   used to analyze specific use cases.

   We consider the following: there are two distinct entities, one, the
   network service provider (NSP) who owns the network and offers a VPN
   to the second entity, the customer, who has premises in four
   different locations that shall be interconnected by that VPN.  The
   sites could be office branches, data centers, etc.  Throughout this
   document, we assume the following four sites:

   o  Site 1

         Location name: SITE-CHICAGO

         Geography Degree: 41.85 N, 87.65 W

   o  Site 2

         Location name: SITE-OTTAWA

         Geography Degree: 45.24 N, 75.43 W

   o  Site 3

         Location name: SITE-SANFRANCISCO

         Geography Degree: 37.75 N, 122.28 W

   o  Site 4

         Location name: SITE-PARIS

         Geography Degree: 48.86 N, 2.35 E

   It is assumed that these sites are interconnected by a VPN that may
   be identified by the hypothetical name "vpn42".  This document




Scharf, et al.           Expires August 17, 2014                [Page 4]

Internet-Draft              ALTO VPN Service               February 2014


   specifically considers two different VPN types for the
   interconnection:

   o  L3VPN: The local area networks at each site will have a certain IP
      subnet ranges, for instance 10.0.1.0/24 at site 1, 10.0.2.0/24 at
      site 2, etc.

   o  L2VPN: All sites form part for a flat sub-IP network, e.g.  a
      logical Ethernet segment.  Different to a local network, the
      network potentially interconnects geographically remote sites.

   The VPN will not necessarily be static.  The customer could possibly
   modify the VPN and add new VPN sites, e. g., to handle peak-load
   demand or to consolidate VPN sites to account for reduced traffic.
   The service provider could offer a Web portal or other Operation
   Support Systems (OSS) solutions that allow the customer to grow or
   consolidate the VPN.  Details on how the customer can configure VPNs
   are outside the scope of this document.

   Furthermore, we assume that the customer is running at least one
   application that can benefit from application-level traffic
   optimization, e.g., using application-internal routing mechanisms or
   placement functions.  For instance, typical uses cases for VPN
   customers could be:

   o  Enterprise application optimization: Enterprise customers often
      run distributed applications that exchange large amounts of data,
      e.g., for synchronization of replicated data bases.  Both for
      placement of replicas as well as for the scheduling of transfers
      insight into network topology information could be useful.

   o  Private cloud computing solution: An enterprise customer could run
      own data centers at the four sites.  The cloud management system
      could want to understand the network costs between different sites
      for intelligent routing and placement decisions of Virtual
      Machines (VMs) among the VPN sites.

   o  Cloud-bursting: One or more VPN endpoints could be located in a
      public cloud.  If an enterprise customer needs additional
      resources, they could be provided by a public cloud, which is
      accessed through the VPN.  Network topology awareness would help
      to decide in which data center of the public cloud those resources
      should be allocated.

   These examples focus on enterprise customers of NSPs, which are
   typical users of provider-supplied VPNs.  Such VPN customers
   typically have no insight into the network topology that transports
   the VPN.  For instance, the actual delay between two VPN sites may



Scharf, et al.           Expires August 17, 2014                [Page 5]

Internet-Draft              ALTO VPN Service               February 2014


   significantly depend on the routing in the NSP MPLS/IP network.  If
   better-than-random decisions are required, applications have to rely
   on own measurements.  An alternative would by guidance by an ALTO
   server offered by the NSP.

   It is important to emphasize that other scenarios and use cases exist
   and the examples enunciated so far are merely used to illustrate how
   ALTO can be used in a VPN context.  A common characteristic of these
   use cases is that applications will not necessarily run in the public
   Internet, and they will typically not be accessed by residential
   customers.  The internal use of ALTO by a specific application is not
   considered in this document.

3.2.  Exemplary use of ALTO

   In the example VPN described in the previous section, it would be
   beneficial if an ALTO server would expose cost maps or provide a
   ranking service that represents the costs between different sites, e.
   g., endpoints of the VPN.  Similar to existing use cases of ALTO,
   this enables an application integrating an ALTO client to use this
   information for application-level traffic optimization.  This results
   in the following scenario:





























Scharf, et al.           Expires August 17, 2014                [Page 6]

Internet-Draft              ALTO VPN Service               February 2014


                       +---------------+
                       |  Customer's   |
                       |   management  |
                       |  application  |.
                       | (ALTO client) |  .
                       +---------------+    .  VPN provisioning
                               ^              . (out-of-scope)
                               | ALTO           .
                               V                  .
                    +---------------------+       +----------------+
                    |     ALTO server     |       | VPN portal/OSS |
                    |   provided by NSP   |       | (out-of-scope) |
                    +---------------------+       +----------------+
                               ^ VPN network
                               * and cost maps
                               *
                     /---------*---------\ Network service provider
                     |         *         |
        +-------+   _______________________   +-------+
        | App a | ()_____. .________. .____() | App d |
        +-------+    |   | |        | |  |    +-------+
     San Francisco   \---| |--------| |--/      Paris
                         | |        | |
                         |^|        |^| Customer VPN
                          V          V
                      +-------+  +-------+
                      | App b |  | App c |
                      +-------+  +-------+
                       Chicago    Ottawa

               Figure 1: Overview of an ALTO usage scenario

   The network service provider could operate an ALTO server.  An ALTO
   client in an application could then retrieve an ALTO cost map by
   querying a corresponding URI, such as:

       uri: http://alto.nsp.org/vpn42/costmap

   The NSP can assign PIDs to each of the VPN endpoints; this renders
   computations at the ALTO server to fit in the current model of using
   the protocol.  A corresponding example would be:

      Site 1: PID "pid14"

      Site 2: PID "pid21"

      Site 3: PID "pid11"




Scharf, et al.           Expires August 17, 2014                [Page 7]

Internet-Draft              ALTO VPN Service               February 2014


      Site 4: PID "pid27"

   The example below further expands on the VPN by demonstrating the
   resulting network topology provided to an ALTO server.  The picture
   corresponds to the VPN of the customer and also includes the Provider
   Edge (PE) routers and Customer Edge (CE) devices:

                        ___________________________
   San Francisco       / Network service provider  \           Paris
       Site 3          | Internal MPLS/IP network  |          Site 4
                       |                           |
                    ___|_##_____________________##_|___
                   /\                                 /\
   10.0.3.0/24<-#-(  )          L3VPN "vpn42"        (  )-#->10.0.4.0/24
    "pid11"    CE  \/_________     _____     _________\/  CE   "pid27"
              device   | ##   |   |     |   |   ## |     device
                       | PE   |   |     |   |   PE |
                       |      |   |     |   |      |
                       |  PE #|   |#   #|   |# PE  |
                       \______| _ |_____| _ |______/
                              |/ \|     |/ \|
                               \_/       \_/
                                |         |
                      CE device #         # CE device
                                |         |
                                V         V
                             Site 1     Site 2
                             Chicago    Ottawa
                          10.0.1.0/24 10.0.2.0/24
                            "pid14"     "pid21"

          Figure 2: Example for mapping of VPN sites to ALTO PIDs

   The costs exposed by the ALTO server can be based on routing costs
   inside the service provider network or other network topology
   information, such as delay measurements, traffic engineering (TE)
   data, etc.  As with other use cases of ALTO, the costs can reflect
   the service provider's preference and policies regarding
   communication between the involved VPN endpoints.

   Generally, two different types of applications can consume the
   information provided by the ALTO server.  The first class can be
   composed of discrete application instances executing at the various
   sites that are interconnected by the VPN.  ALTO is used to optimize
   the routing or resource consumption among those application
   instances.  A typical examples is a distributed database, i.e., an
   enterprise backend system.  In Figure 1, these application instances
   are referred to as "App a", "App b", "App c", and "App d".  Generally



Scharf, et al.           Expires August 17, 2014                [Page 8]

Internet-Draft              ALTO VPN Service               February 2014


   speaking, this usage mirrors the canonical use of ALTO in
   unstructured P2P networks or Content Delivery Networks (CDN) networks
   whereby a rendezvous is desired between a consumer and a plurality of
   producers.  In this document, we label this class of applications by
   the term "user applications".

   The second class represents management applications that typically
   work on VPN level.  In addition to consulting an ALTO server provided
   by the NSP, this type of application possibly has its own
   understanding of what resources are available at different sites, and
   it could possibly even trigger more complex actions such a building
   out VPNs, e. g., by contacting a VPN portal of the NSP.  In Figure 1,
   as well as the rest of this document, uses the term "management
   application" for this use case.  An example would be an orchestration
   solution for cloud computing resources.  It could use the topology
   and cost maps illustrated in Figure 2 to control VPN placement.  In
   principle, management applications have some similarity to
   centralized resource directories in P2P networks (e. g., trackers),
   which are an important existing use case for ALTO.  Yet, unlike
   resource directories in the Internet, a VPN typically interconnects
   mainly sites within one administrative domain.

   There may also be an overlap between both types of applications.
   Furthermore, in particular for the first class of applications, the
   customer could run an own ALTO server, which could expose topology
   map and cost maps with further details only visible to the VPN
   customer (e.g., network segments behind NATs).  Since such
   information is independent of the use of a VPN and typically not
   known to an NSP, these usage scenarios are not further detailed in
   this memo.

4.  Use cases

   Current VPNs provide no clear mechanism to convey information about
   the network infrastructure to management or user applications using
   that VPN, e.g. regarding preferences or topological properties of the
   network service provider network.  Applications thus have to rely on
   other mechanisms such as local measurements to optimize their
   traffic.  The ALTO protocol has been designed to overcome such
   limitations in the Internet.  ALTO, being a well-established,
   generic, and flexible protocol, can be used in VPNs, too.

   We now present various use cases that exhibit the utility of
   considering a VPN extension of ALTO.  Through a series of use cases
   we demonstrate how a VPN customer and the NSP can use ALTO; we also
   highlight similarities and differences when using ALTO in the general
   Internet.




Scharf, et al.           Expires August 17, 2014                [Page 9]

Internet-Draft              ALTO VPN Service               February 2014


4.1.  Use case 1: Application guidance in an L3VPN

   The NSP providing the L3VPN service can offer an ALTO server that
   exposes network and cost information to applications running traffic
   over that VPN.  Since an L3VPN is IP-based, this use case is in
   principle similar to the use cases already addressed by the ALTO base
   protocol.

   Example 1: Consider the customer in Section 3.1 that has four VPN
   sites.  A user application in one site (say Site 1) would now like to
   find out which of the other sites (Site 2 to Site 4) are
   topologically close to Site 1, perhaps to determine where to
   replicate a certain data set.  A corresponding ALTO query would
   return the costs between those sites.  The user application could
   then select a host in the corresponding subnetwork and connect to
   that endpoint.

   Example 2: In addition to network proximity information, the user
   application could also be interested in guidance regarding network
   parameters that cannot be measured directly.  For instance, a
   relevant parameter for a VPN site could be the level of redundancy
   for that VPN site, e.g., whether there is resilience by network
   protection schemes in the NSP network.

   Example 3: It is quite common for VPN Customer Equipment (CE) to be
   multi-homed at the Provider Edge (PE).  A CE may well home into to
   several PE routers and thus may have different network cost
   functions.  For instance, assume that in Site 1 the CE will peer to a
   local PE1 and remote PE2.  The cost to reach Site 2 in the VPN could
   be 1575 for PE1 and 2250 for PE2.  The CE will thus choose to steer
   traffic from Site 1 to Site 2 toward PE1.  While the realization of
   such traffic steering is outside the scope of this document, CE
   multi-homing places an explicit need to expose more than one set of
   network costs for a VPN endpoint.

   In principle, the existing ALTO services such as network and cost map
   can provide such guidance.  However, it is important to note that a
   VPN might not run in a public environment.  The IP address ranges
   inside a VPN might not be globally unique or routable.  Furthermore,
   a provider based VPN service normally maintains a strict separation
   between service provider addressing (such as addresses or Provider
   Edge routers) and customer addressing.  As a result, an ALTO server
   will not expose the internal IP addressing of the network service
   provider, making it difficult to identify services using IP addresses
   in general.  In a BGP L3VPN, the VPRN BGP Route Distinguisher could
   possibly be used as a service identifier, but it is unclear whether
   an application of a customer or the ALTO client will indeed know such
   network-internal information of the NSP and whether the NSP would



Scharf, et al.           Expires August 17, 2014               [Page 10]

Internet-Draft              ALTO VPN Service               February 2014


   want to expose it.  Also, it would make sense to define an ALTO VPN
   extension independent of a specific VPN technology.

   The network costs in a VPN depends on VPN topology, which needs to be
   taken into consideration when calculating ALTO information.  Given
   that VPNs are often offered by a single network service provider,
   ALTO cost information could include information that may be available
   for a single autonomous system, but difficult to gather in the
   Internet as a whole.  Examples would be the provisioned bandwidth,
   network-internal latencies, or the path resilience.  In a static VPN
   environment e.g. with a reserved resources in an MPLS/IP wide area
   network, these costs can be assumed to be rather stable and e. g.
   reflect the reserved bandwidth between VPN sites.  For an application
   it is simpler and less intrusive to obtain such information about the
   VPN from the network instead of performing measurements, which would
   possibly require special probe instances at the different VPN sites
   (e. g., data centers).  But as the encoding of such costs in ALTO is
   independent of the usage of a VPN, this document does not mandate any
   specific way how to build ALTO cost maps.

   This memo does not argue that ALTO shall be used as a generic data
   center information exchange protocol.  For instance, a general data
   center resource information model has been suggested in
   [I-D.lee-alto-ext-dc-resource].  According to that model, the ALTO
   server also includes data-center information not related at all to
   the network, such as compute resources, memory, power consumption,
   etc.  While VPNs are an important technology to interconnect data
   centers, the ALTO VPN service solely focuses on networking cost.

4.2.  Use case 2: Application guidance in an L2VPN

   The use case outlined in Example 1 also exists for L2VPNs, which are
   an important technology to transparently interconnect different LAN
   segments of enterprise users.  Again, applications could benefit from
   getting insight into topological properties of the wide area network
   providing the L2VPN service, in order to avoid the overhead of own
   measurements.

   Example 4: The user application described in Section 3.1 again wants
   to find out how well connected (topologically close) Site 1 is to
   Site 2, 3, or 4.  Different from the previous example, all sites are
   now part of the same Layer 2 subnet.  Another example for an
   application that would benefit from ALTO is a cloud management
   system.  Such a management application could be interested in finding
   out whether migrating of a Virtual Machine from Site 1 to another
   site would improve performance, perhaps due to better connectivity or
   lower latency.




Scharf, et al.           Expires August 17, 2014               [Page 11]

Internet-Draft              ALTO VPN Service               February 2014


   While this use case is in principle similar to the previous one,
   there is a major difference regarding addressing: Unlike the L3VPN,
   an L2VPN is not necessarily IP-based; it may use MAC addresses
   instead of IP addresses.  While IP addresses can be aggregated easily
   and represented succinctly using CIDR notation, MAC addresses do not
   lend themselves to such aggregation and representation.  Furthermore,
   MAC addresses are not useful to applications themselves.  And
   finally, MAC addresses may not readily be known and available to an
   ALTO server of the network service provider.  And even if they are,
   an ALTO map using MAC addresses will be very large.  In summary, use
   of MAC addresses is not scalable and nor does it denote any hierarchy
   that can be used for aggregation.  Some other means of identifying
   services and hosts will be required when using ALTO in L2VPNs.

4.3.  Use case 3: VPN guidance without addresses

   The VPN interconnects different sites through the network service
   provider's network.  An application might be interested in getting
   topology information among those sites without knowing actual
   addresses or identifiers used internally by the VPN.  In fact, a VPN
   site may not even have an address known or visible to applications,
   e.g., a pseudo-wire VPN.

   Example 5: A management application might ask for all VPN sites (i.
   e., corresponding PIDs) that have a delay less than 40ms or a routing
   cost less than 55, from VPN Site 1.  A specific example for such an
   application might be cloud management system that uses application-
   level traffic optimization mechanisms.  In the scenario introduced in
   Section 3.1, such an application may have a-priori information,
   learned from e.g. a VPN portal, about the VPN type and/or VPN
   identifiers ("vpn42") as well as some unique site identifier such as
   "SITE-CHICAGO" but no network addresses.  The query could also be
   more complex or include constraints, e. g., limited to a particular
   TE class.  Note that the ATLO protocol does not necessarily have to
   support the query constraint itself; if corresponding maps are
   available, the application can analyze the data itself.

   Example 6: In absence of well-known existing network identifiers, a
   management application might want to query for VPN sites based on yet
   other attributes, such as geographical distance.  For example, an
   application might want to find all the VPN sites (i. e.,
   corresponding PIDs) within 50 KM of 45.35N, 75.92W.  Such geographic
   queries would be typical of policies bounding delay by geographic
   distance or administrative and legal requirements.

   Such application guidance is obviously similar to existing use of the
   ALTO cost map or ranking services except that the queries are not
   based on network addresses.



Scharf, et al.           Expires August 17, 2014               [Page 12]

Internet-Draft              ALTO VPN Service               February 2014


4.4.  Use case 4: Extending the VPN

   The customer can possibly grow the VPN to include new sites that are
   connected at a later time to the VPN.  The actual mechanisms for VPN
   reconfiguration are outside the scope of this document.

   Example 7: A management application could be interested in guidance
   for VPN sites that are currently not part of the VPN, but that would
   be available e. g. to increase capacity or geographic coverage.
   Assume that two sites Site 1 and Site 2 are already connected to the
   VPN.  Some time later, scale-out to a third site is required, and the
   application has to decide whether Site 3 or 4 is better suited for a
   new application instance.  This is an realistic example for a cloud
   management system that is geographically distributed.  Such a system
   would then have to decide whether Site 3 or Site 4 is topologically
   closer to the existing VPN endpoints, in order to determine the best
   location from the network point of view.  An ALTO server could
   provide guidance on the offnet distance of Sites 3 and 4 to the
   existing VPN sites.

   Apparently, the question whether to actually extend the VPN in a
   specific way may also include decisions outside the scope of ALTO,
   such as price information or other commercial or legal policies.  The
   actual VPN re-configuration and attachment of a new site to the VPN
   topology requires back-office interaction and provisioning actions by
   separate, orthogonal mechanisms such as a Path Computation Element
   (PCE).  Actual path setup by a PCE is independent from the selection
   of a suitable target site.  But it makes sense to use the well-
   established ALTO methods in order to get at an early stage network
   proximity information as input information for the selection and
   configuration process.  Applications typically cannot measure the
   network performance to destinations not already part of the VPN.

   For a network service provider, customer guidance for VPN extension
   by ALTO offers a new possibility to optimize its internal traffic
   engineering.  For instance, an operator could recommend to customers
   not to connect to a destination operating in protection mode, e.g.,
   after a fiber cut, because in such a case the network may have less
   sparse resources.  Note that a customer is not able to measure such
   constraints.  ALTO is a simple interface to expose such information
   to applications.

   From an ALTO perspective, growing VPN sites possibly results in
   different types of endpoints, some of which may exist a-priory but
   not be reachable within the VPN.  They could possibly be understood
   as "shadow" PIDs that become active once the VPN is extended.  Once
   the VPN is modified, new endpoints or PIDs may be created, i. e., the




Scharf, et al.           Expires August 17, 2014               [Page 13]

Internet-Draft              ALTO VPN Service               February 2014


   ALTO network and cost maps may have to be updated accordingly after
   the VPN is re-configured.

4.5.  Use case 5: Shrinking the VPN

   Much like a VPN may grow dynamically, it can also shrink when the
   resources in the VPN are underutilized.  Instead of keeping the
   underutilized resources alive, the VPN operator my decide to
   consolidate the resources and remove sites from the VPN.

   Example 8: Once again, consider the customer in Section 3.1 that has
   four VPN sites.  Based on low resource demand, the management
   application may wonder whether Site 1 (Chicago) and Site 2 (Ottawa)
   can be consolidated, e. g., by moving resources between them.  One
   important constraint for such a decision could network proximity
   information.  After such a consolidation, the VPN network and cost
   maps will be updated to reflect the new topology.

   From an ALTO server perspective, this use case is similar to a
   general application guidance.  Yet, there could be a benefit for the
   service provider to provide special guidance regarding removal of VPN
   endpoints if there is a benefit for its internal traffic engineering
   (e. g., consolidation of network resources used by several VPN
   customers).

4.6.  Use case 6: VPN selection

   In a more advanced use case, ALTO could also be a selection function
   to choose VPNs based on network cost criteria.

   Example 9: In a multi-homing environment, ALTO could be used to
   select one VPN out of several candidates to reach a certain
   destination, taking into account smaller costs, e. g., according to
   distance or to preferences of the network service provider network.

   This use case differs from the previous examples since more than one
   VPN is involved, i. e., the ALTO guidance is not used to perform
   application-layer traffic optimization within one VPN, but instead
   across different VPNs.

4.7.  Use case 7: Other use cases

   The aforementioned use cases could be complemented by other use of
   ALTO information.  For instance, if applications using the VPN are
   flexible regarding the timing of data transfers, an ALTO server could
   provide guidance when and how to schedule such data transfers,
   possibly with time-shift enhancements.  This scenario is further
   detailed in [I-D.randriamasy-alto-cost-schedule].



Scharf, et al.           Expires August 17, 2014               [Page 14]

Internet-Draft              ALTO VPN Service               February 2014


5.  Requirements and potential solutions

5.1.  Requirements

   Based on the scenarios listed in Section 4, several requirements can
   be derived for a VPN Service in ALTO:

   REQ 1: The existing ALTO protocol and RESTful interface should be
   used as far as possible to enable an NSP to expose properties of a
   VPN.

   REQ 2: A VPN Service must not require that network service provider
   expose internal addressing, such as internal addresses or loopback
   addresses of the Provider Edge (PE) routers.

   REQ 3: A VPN Service must use the PID concept of the base ALTO
   protocol as far as possible, i. e., the VPNs and network entities in
   the VPNs can be identified by PIDs.  This permits use of the existing
   ALTO services such as the map service for VPNs, as well as the
   inherent topology abstraction provided by ALTO.

   REQ 4: A VPN Service must be possible for different VPN types, i. e.,
   it must not be limited to L3VPNs only.

   REQ 5: The VPN Service must support use cases where IP addresses are
   not the only form of endpoint identification.

   REQ 6: If IP addresses are used, a VPN Service must not assume that
   IP address are globally routable or unique.

   REQ 7: A VPN Service should include certain attributes that are
   unique to a VPN and that are not represented by the current set of
   attributes in the base ALTO protocol.  Examples include location name
   of a site, geography coordinates (degree/digital), role, redundancy,
   default policy, or geography restriction.

   REQ 8: The PID must be selectable using standard ALTO filtering.  A
   standard interface query should allow finding resources using, say,
   the location name attribute or the geography attributes.

   REQ 9: The PID should be selectable using a filter that computes
   matching sites within a certain distance of a particular geographic
   coordinate based on latitude and longitude, in case that no other
   address information is known in advance.

   REQ 10: Incremental build out (as well as the shrinking) of resources
   that are part of the VPN must be supported, i. e., the ALTO VPN




Scharf, et al.           Expires August 17, 2014               [Page 15]

Internet-Draft              ALTO VPN Service               February 2014


   service should also be able to expose information about new sites to
   be attached to the VPN, or provide guidance for removal of sites.

   REQ 11: A VPN Service requires that an ALTO server can report the
   (expected) connectivity between VPN sites regarding different
   metrics, including for example geographical distance, delay, or
   provisioned bandwidth.

   REQ 12: Information about a VPN must only be exposed to authorized
   users of that VPN.

5.2.  Potential Solutions

   In the following we analyze how the requirements of a VPN Service can
   be addressed by ALTO extensions.

   REQ 1: This is an inherent, general requirement for any new use or
   extension of ALTO.

   REQ 2: This requirement can be supported in ALTO today, because it is
   left to the service provider which information to expose e.g. in ALTO
   cost maps.

   REQ 3: The PID concept itself is generic and thus can fulfill this
   requirement.

   REQ 4: L3VPNs are rather similar to existing use cases of ALTO in the
   Internet.  Insofar as L2VPNs or pseudo-wire VPNs have the notion of
   some address, ALTO seems to able to handle these through an extension
   that extends the definition of an address to include other
   identifiers besides IP addresses.

   REQ 5: Use of ALTO with network identifiers that are not IP addresses
   requires work.  There is a need to analyze how to name VPNs and
   endpoints and how to achieve a mapping to the information stored in
   the ALTO server.  One potential approach would be to characterize an
   endpoint by any identifier that is unique within a map.

   REQ 6: ALTO can be used as of now with IP address ranges that are not
   globally routable.  However, it must be emphasized that private VPN
   environments without uplink to the global Internet may only have
   connectivity to a limited number of IP subnets, i. e., the ALTO
   server will not be able to provide any reasonable guidance for most
   parts of the IP address space.  Also, the ALTO server operator must
   take into account that IP address ranges in different VPNs may
   overlap, possibly also with the transport network infrastructure (e.
   g., PE routers).




Scharf, et al.           Expires August 17, 2014               [Page 16]

Internet-Draft              ALTO VPN Service               February 2014


   REQ 7: Extensions to ALTO will be needed, in particular assignment of
   properties to PIDs.  [I-D.roome-alto-pid-properties] extends the ALTO
   protocol by defining PID-based properties in much the same way that
   the original ALTO protocol defines endpoint-based properties.  The
   VPN use case may also benefit from other extensions to ALTO.
   Representing the network topology as a graph and using TE metrics
   (e.g., [I-D.wu-alto-te-metrics]) may allow the VPN operator to be
   better informed about link-level information to grow (or shrink) a
   new (or existing) VPN.

   REQ 8: Assuming extensions in REQ 7, filtering should be fairly easy.
   If a client has to perform complex queries, it could also download
   all PID properties and execute complex filter logic itself, if full
   data retrieval is supported by the ALTO server.  There is a tradeoff
   between the complexity of the server and the client.

   REQ 9: Extensions to ALTO will be needed.  In complex cases, client-
   side execution of the filtering is an alternative.

   REQ 10: This requirement will possibly require extensions to ALTO, e.
   g., to distinguish between endpoints that are already attached to the
   VPN and sites outside the VPN.  This can be achieved e.g. by endpoint
   and/or PID properties.  Changes of the VPN topology are likely to
   change the ALTO maps, i.e., standard ALTO mechanism for incremental
   updates and push notifications would be of added value.

   REQ 11: Registration of corresponding metrics is useful.  An subset
   of metrics is described in [I-D.wu-alto-te-metrics].  Further
   analysis is needed for additional connectivity aspects, such as
   resilience parameters, shared risk link group (SRLG), etc.

   REQ 12: Existing authentication and access control mechanisms for
   ALTO could be sufficient to meet this requirement, subject to further
   analysis.

6.  Security considerations

   TBD.

7.  IANA considerations

   TBD.

8.  References







Scharf, et al.           Expires August 17, 2014               [Page 17]

Internet-Draft              ALTO VPN Service               February 2014


8.1.  Normative References

   [I-D.ietf-alto-protocol]
              Alimi, R., Penno, R., and Y. Yang, "ALTO Protocol", draft-
              ietf-alto-protocol-25 (work in progress), January 2014.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC4026]  Andersson, L. and T. Madsen, "Provider Provisioned Virtual
              Private Network (VPN) Terminology", RFC 4026, March 2005.

   [RFC4364]  Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
              Networks (VPNs)", RFC 4364, February 2006.

   [RFC4762]  Lasserre, M. and V. Kompella, "Virtual Private LAN Service
              (VPLS) Using Label Distribution Protocol (LDP) Signaling",
              RFC 4762, January 2007.

8.2.  Informative References

   [I-D.lee-alto-ext-dc-resource]
              Lee, Y., Bernstein, G., Dhody, D., and T. Choi, "ALTO
              Extensions for Collecting Data Center Resource
              Information", draft-lee-alto-ext-dc-resource-03 (work in
              progress), January 2014.

   [I-D.randriamasy-alto-cost-schedule]
              Randriamasy, S. and N. Schwan, "ALTO Cost Schedule",
              draft-randriamasy-alto-cost-schedule-02 (work in
              progress), October 2012.

   [I-D.roome-alto-pid-properties]
              Roome, B. and Y. Yang, "PID Property Extension for ALTO
              Protocol", draft-roome-alto-pid-properties-00 (work in
              progress), October 2013.

   [I-D.wu-alto-te-metrics]
              Wu, W., Lee, Y., Dhody, D., and S. Randriamasy, "ALTO
              Traffic Engineering Cost Metrics", draft-wu-alto-te-
              metrics-00 (work in progress), October 2013.

Appendix A.  Acknowledgements

   TBD.






Scharf, et al.           Expires August 17, 2014               [Page 18]

Internet-Draft              ALTO VPN Service               February 2014


Authors' Addresses

   Michael Scharf (editor)
   Alcatel-Lucent

   Email: Michael.Scharf@alcatel-lucent.com


   Vijay K. Gurbani (editor)
   Alcatel-Lucent

   Email: vkg@bell-labs.com


   Greg Soprovich
   Alcatel-Lucent

   Email: Greg.Soprovich@alcatel-lucent.com


   Volker Hilt
   Alcatel-Lucent

   Email: volker.hilt@bell-labs.com



























Scharf, et al.           Expires August 17, 2014               [Page 19]