One document matched: draft-scharf-alto-vpn-service-01.xml
<?xml version="1.0" encoding="US-ASCII"?> <!-- -*- fill-column: 120; -*- -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC4026 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.4026.xml">
<!ENTITY RFC4364 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.4364.xml">
<!ENTITY RFC4762 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.4762.xml">
<!ENTITY I-D.ietf-alto-protocol SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-alto-protocol.xml">
<!ENTITY I-D.bernstein-alto-large-bandwidth-cases SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.bernstein-alto-large-bandwidth-cases.xml">
<!ENTITY I-D.lee-alto-app-net-info-exchange SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.lee-alto-app-net-info-exchange.xml">
<!ENTITY I-D.lee-alto-ext-dc-resource SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.lee-alto-ext-dc-resource.xml">
<!ENTITY I-D.xie-alto-sdn-use-cases SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.xie-alto-sdn-use-cases.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<rfc category="info" docName="draft-scharf-alto-vpn-service-01" ipr="trust200902">
<front>
<title abbrev="ALTO VPN Service">The Virtual Private Network (VPN) Service
in ALTO: Use Cases, Requirements and Extensions</title>
<author fullname="Michael Scharf" initials="M." surname="Scharf"
role="editor">
<organization>Alcatel-Lucent</organization>
<address>
<email>Michael.Scharf@alcatel-lucent.com</email>
</address>
</author>
<author fullname="Vijay K. Gurbani" initials="V.K." surname="Gurbani"
role="editor">
<organization>Alcatel-Lucent</organization>
<address>
<email>vkg@bell-labs.com</email>
</address>
</author>
<author fullname="Greg Soprovich" initials="G." surname="Soprovich">
<organization>Alcatel-Lucent</organization>
<address>
<email>Greg.Soprovich@alcatel-lucent.com</email>
</address>
</author>
<author fullname="Volker Hilt" initials="V." surname="Hilt">
<organization>Alcatel-Lucent</organization>
<address>
<email>volker.hilt@bell-labs.com</email>
</address>
</author>
<date year="2013" />
<area>Transport</area>
<workgroup>Internet Engineering Task Force</workgroup>
<keyword>alto</keyword>
<keyword>VPN</keyword>
<abstract>
<t>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.</t>
</abstract>
</front>
<middle>
<section title="Overview" anchor="overview">
<t>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
<xref target="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.</t>
<t>Service providers offer different types of VPNs.
<xref target="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 traditional Local Area Network (LAN)
<xref target="RFC4762"/>. A VPLS makes it possible to interconnect
several LAN segments over a packet switched network.</t>
<t>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 <xref target="RFC4364"/> as follows:
<list style="empty">
<t>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.</t>
<t>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.</t>
</list></t>
<t>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.</t>
<t>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.</t>
<t>The ALTO protocol <xref target="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.</t>
</section> <!-- overview -->
<section title="Terminology">
<t>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 <xref target="RFC2119"/>.</t>
</section>
<section title="Encompassing example" anchor="sec:example_all">
<section title="A VPN scenario" anchor="sec:scenario">
<t>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.</t>
<t>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:</t>
<t><list style="symbols">
<t>Site 1<list style="empty">
<t>Location name: SITE-CHICAGO</t>
<t>Geography Degree: 41.85 N, 87.65 W</t>
</list></t>
<t>Site 2<list style="empty">
<t>Location name: SITE-OTTAWA</t>
<t>Geography Degree: 45.24 N, 75.43 W</t>
</list></t>
<t>Site 3<list style="empty">
<t>Location name: SITE-SANFRANCISCO</t>
<t>Geography Degree: 37.75 N, 122.28 W</t>
</list></t>
<t>Site 4<list style="empty">
<t>Location name: SITE-PARIS</t>
<t>Geography Degree: 48.86 N, 2.35 E</t>
</list></t>
</list></t>
<t>It is assumed that these sites are interconnected by a VPN that
may be identified by the hypothetical name
"vpn42". This document specifically considers two different VPN types
for the interconnection:</t>
<t><list style="symbols">
<t>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.</t>
<t>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.</t>
</list></t>
<t>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.</t>
<t>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:</t>
<t><list style="symbols">
<t>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.</t>
<t>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.</t>
<t>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.</t>
</list></t>
<t>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 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.</t>
<t>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.</t>
</section> <!-- scenario -->
<section title="Exemplary use of ALTO" anchor="sec:alto_example">
<t>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:</t>
<figure title="Overview of an ALTO usage scenario"
anchor="fig_overview"><artwork><![CDATA[
+---------------+
| 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
]]></artwork></figure>
<t>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:</t>
<figure><artwork><![CDATA[
uri: http://alto.nsp.org/vpn42/costmap
]]></artwork></figure>
<t>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:</t>
<t><list style="empty">
<t>Site 1: PID "pid14"</t>
<t>Site 2: PID "pid21"</t>
<t>Site 3: PID "pid11"</t>
<t>Site 4: PID "pid27"</t>
</list></t>
<t>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:</t>
<figure title="Example for mapping of VPN sites to ALTO PIDs"
anchor="fig_example"><artwork><![CDATA[
___________________________
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
10.0.1.0/24 10.0.2.0/24
"pid14" "pid21"
]]></artwork></figure>
<t>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.</t>
<t>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 <xref target="fig_overview"/>,
these application instances are referred to as "App a", "App b",
"App c", and "App d".
Generally 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".</t>
<t>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 <xref target="fig_overview"/>,
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 <xref target="fig_example"/> 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.</t>
<t>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.</t>
</section> <!-- sec:alto_example -->
</section> <!-- sec:example-all -->
<section title="Use cases" anchor="sec:use-cases">
<t>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.</t>
<t>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.</t>
<section title="Use case 1: Application guidance in an L3VPN"
anchor="sec:use_l3vpn">
<t>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.</t>
<t>Example 1: Consider the customer in <xref target="sec:scenario"/>
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.</t>
<t>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.</t>
<t>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.</t>
<t>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 want to expose it. Also,
it would make sense to define an ALTO VPN extension independent
of a specific VPN technology.</t>
<t>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.</t>
</section> <!-- use case 1 -->
<section title="Use case 2: Application guidance in an L2VPN"
anchor="sec:use_l2vpn">
<t>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.</t>
<t>Example 4: The user application described
in <xref target="sec:scenario"/> 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.</t>
<t>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.</t>
</section> <!-- use case 2 -->
<section title="Use case 3: VPN guidance without addresses"
anchor="sec:use_lookup">
<t>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.</t>
<t>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
<xref target="sec:scenario"/>, 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.</t>
<t>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.</t>
<!--
<t>The semantics here are thus: a new ALTO endpoint type is
defined called "site" (NOTE: Comment from Greg: You actually
have VPN-SITE (better) and you need to quantify name by VPN type
as attribute you can use might differ. This is true in MTOSI and
SAMO). This type identifies the VPNs
above. For instance, given a query, "Get me the {PID, Location name}
properties of site:site-chicago", an ALTO
server would respond with a map consisting of
"{"pid", SI-22, "locationname", SITE-CHICAGO}".</t>
-->
<t>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.</t>
</section> <!-- use case 3 -->
<section title="Use case 4: Extending the VPN" anchor="sec:vpn-extension">
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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 ALTO
network and cost maps may have to be updated accordingly
after the VPN is re-configured.</t>
<!--
<t>The issue in growing VPN sites is how to integrate them in
the VPN? Do these sites exist a-priori, but in an inactive
form? Or are these sites created "on the fly"? Clearly, the
NSP has to make the customer aware that the VPN can grow to
include a new site at a geographically preferred customer location,
but how does the NSP optimize its resources so that it does
not create many inactive sites? .</t>
-->
<!--
<t>(NOTE: From Greg --- We should likely have a case for on/off
net resources as well. For example, a SP offer an on net MVPN video
conferencing service and we want to know which conferencing pool
so as to be close to customers in Sites 1-5).</t>
-->
</section> <!-- vpn-extension -->
<section title="Use case 5: Shrinking the VPN"
anchor="sec:vpn-shrink">
<t>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.</t>
<t>Example 8: Once again, consider the customer in
<xref target="sec:scenario"/> 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.</t>
<t>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).</t>
</section> <!-- sec:vpn-shrink -->
<section title="Use case 6: VPN selection" anchor="sec:use_selection">
<t>In a more advanced use case, ALTO could also be a selection
function to choose VPNs based on network cost criteria.</t>
<t>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.</t>
<t>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.</t>
</section> <!-- sec:use_selection -->
</section> <!-- sec:use-cases -->
<section title="Requirements and gap analysis" anchor="sec:reqs_gap">
<section title="Requirements" anchor="sec:reqs">
<t>Based on the scenarios listed in <xref target="sec:use-cases"/>,
several requirements can be derived for a VPN Service in ALTO:</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>REQ 4: A VPN Service must be possible for different VPN types,
i. e., it must not be limited to L3VPNs only.</t>
<t>REQ 5: The VPN Service must support use cases where IP addresses
are not the only form of network identification.</t>
<t>REQ 6: If IP addresses are used, a VPN Service must not assume
that IP address are globally routable or unique.</t>
<t>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, default policy, or geography
restriction.</t>
<t>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.</t>
<t>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.</t>
<t>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 service
should also be able to expose information about new sites to be attached
to the VPN, or provide guidance for removal of sites.</t>
<t>REQ 11: Information about a VPN must only be exposed to
authorized users of that VPN.</t>
</section> <!-- sec:reqs -->
<section title="Gap analysis" anchor="sec:gaps">
<t>In the following we analyze to which extent the requirements of a
VPN Service can be met by the existing ALTO protocol.</t>
<t>REQ 1: This is an inherent, general requirement for any
new use or extension of ALTO.</t>
<t>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.</t>
<t>REQ 3: The PID concept itself is generic and thus can fulfill
this requirement.</t>
<t>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.</t>
<t>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.</t>
<t>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).</t>
<t>REQ 7: Extensions to ALTO will be needed.</t>
<t>REQ 8: Assuming extensions in REQ 7, filtering should be
fairly easy.</t>
<t>REQ 9: Extensions to ALTO will be needed, aligned with REQ 6.</t>
<t>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. 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.</t>
<t>REQ 11: Existing authentication and access control mechanisms
for ALTO could be sufficient to meet this requirement, subject
to further analysis.</t>
</section> <!-- sec:gaps -->
<section title="Differences from other proposed ALTO extensions" anchor="sec:differences">
<t>There have been various other proposals for ALTO extensions. In the following, we discuss why none of these
extensions addresses the requirements of using ALTO in VPNs.</t>
<t>A use case of ALTO for traffic optimization in high bandwidth core networks is discussed in <xref
target="I-D.bernstein-alto-large-bandwidth-cases"/>. It is proposed to enhance ALTO by bandwidth constraint
representations, focusing on high-speed circuit switched optical networks that have a fixed capacity. However,
L2VPNs or L3VPNs can be deployed in an MPLS/IP network without any bandwidth guarantees. An encoding of network
parameters such as bandwidth in ALTO is therefore entirely orthogonal to the use of VPNs. The ALTO extensions
suggested by <xref target="I-D.bernstein-alto-large-bandwidth-cases"/> are therefore not required by the use
cases summarized in this document.</t>
<t>A related extension proposal <xref target="I-D.lee-alto-app-net-info-exchange"/> defines enhanced filtering
constraints for ALTO, as well as a constrained cost graph encoding. The objective of the filtering is to
retrieve paths or graphs for given constraints (e.g., bandwidth, latency, hop count, packet loss, etc.). This
proposal basically anhances the way how ALTO can represent the costs in a network. However, the core challenge
in VPNs is the addressing and lookup of VPN endpoints. With the VPN service, ALTO can be used in L2VPNs or
L3VPNs with the existing encodings for cost maps, i. e., the extensions of <xref
target="I-D.lee-alto-app-net-info-exchange"/> are orthogonal as well.</t>
<t>A general data center resource information model has been suggested in <xref
target="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. This
implies a significant extension of the scope of ALTO. While VPNs are an important technology to interconnect
data centers, the ALTO VPN service solely focuses on networking cost, and ALTO extensions are limited to the
minimum set of additional protocol features that are required in a VPN context. This memo does not argue that
ALTO shall be used as a generic data center information exchange protocol.</t>
<t><xref target="I-D.xie-alto-sdn-use-cases"/> presents an architecture how ALTO can be used if data-forwarding
plane and control plane are separated. In such an architecture, ALTO could be used to exchange connectivity
information between controllers in different domains. This proposal is entirely disjoint to the problem
addressed by this document. Since the separation of data-forwarding and control plane is an internal network
design issue, it does not matter for the ALTO VPN service how Network Service Provider control their
infrastructure, and existing management solutions can be applied as well. Even though the realization of network
control and management of VPNs is outside the scope of this document, we note that existing L2VPN and L3VPN
solutions often integrate data-forwarding and control plane.</t>
<t>In summary, this document proposes a small and well-focused extension to enable the use of ALTO in VPN
environments, given that the current address types and information modesl of ALTO is not sufficient in some
cases. This document does explicitly not suggest any non-networking or technology-specific ALTO extension.</t>
</section> <!-- sec:differences -->
</section> <!-- sec:reqs_gap -->
<section title="Security considerations" anchor="sec-cons">
<t>TBD.</t>
</section> <!-- sec-cons -->
<section title="IANA considerations" anchor="iana-cons">
<t>TBD.</t>
</section> <!-- iana-cons -->
</middle>
<back>
<references title="Normative References">
&RFC2119;
&RFC4026;
&RFC4364;
&RFC4762;
&I-D.ietf-alto-protocol;
</references>
<references title="Informative References">
&I-D.bernstein-alto-large-bandwidth-cases;
&I-D.lee-alto-app-net-info-exchange;
&I-D.lee-alto-ext-dc-resource;
&I-D.xie-alto-sdn-use-cases;
</references>
<section title="Acknowledgements">
<t>TBD.</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 03:17:55 |