< draft-scharf-alto-vpn-service-01.txt   draft-scharf-alto-vpn-service-02.txt >
Internet Engineering Task Force M. Scharf, Ed. Internet Engineering Task Force M. Scharf, Ed.
Internet-Draft V. Gurbani, Ed. Internet-Draft V. Gurbani, Ed.
Intended status: Informational G. Soprovich Intended status: Informational G. Soprovich
Expires: January 16, 2014 V. Hilt Expires: August 17, 2014 V. Hilt
Alcatel-Lucent Alcatel-Lucent
July 15, 2013 February 13, 2014
The Virtual Private Network (VPN) Service in ALTO: Use Cases, The Virtual Private Network (VPN) Service in ALTO: Use Cases,
Requirements and Extensions Requirements and Extensions
draft-scharf-alto-vpn-service-01 draft-scharf-alto-vpn-service-02
Abstract Abstract
The Application-Layer Traffic Optimization (ALTO) protocol is The Application-Layer Traffic Optimization (ALTO) protocol is
designed to allow entities with knowledge about the network designed to allow entities with knowledge about the network
infrastructure to export such information to applications that need infrastructure to export such information to applications that need
to choose one or more resources from a candidate set. This document to choose one or more resources from a candidate set. This document
provides motivation for using ALTO in a Virtual Private Network (VPN) provides motivation for using ALTO in a Virtual Private Network (VPN)
environment. We discuss use cases, requirements, and possible environment. We discuss use cases, requirements, and possible
extensions to the base ALTO protocol that will be needed to support extensions to the base ALTO protocol that will be needed to support
VPN services. VPN services.
Status of this Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 16, 2014. This Internet-Draft will expire on August 17, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Encompassing example . . . . . . . . . . . . . . . . . . . . . 4 3. Encompassing example . . . . . . . . . . . . . . . . . . . . 4
3.1. A VPN scenario . . . . . . . . . . . . . . . . . . . . . . 4 3.1. A VPN scenario . . . . . . . . . . . . . . . . . . . . . 4
3.2. Exemplary use of ALTO . . . . . . . . . . . . . . . . . . 6 3.2. Exemplary use of ALTO . . . . . . . . . . . . . . . . . . 6
4. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1. Use case 1: Application guidance in an L3VPN . . . . . . . 10 4.1. Use case 1: Application guidance in an L3VPN . . . . . . 10
4.2. Use case 2: Application guidance in an L2VPN . . . . . . . 11 4.2. Use case 2: Application guidance in an L2VPN . . . . . . 11
4.3. Use case 3: VPN guidance without addresses . . . . . . . . 12 4.3. Use case 3: VPN guidance without addresses . . . . . . . 12
4.4. Use case 4: Extending the VPN . . . . . . . . . . . . . . 12 4.4. Use case 4: Extending the VPN . . . . . . . . . . . . . . 13
4.5. Use case 5: Shrinking the VPN . . . . . . . . . . . . . . 13 4.5. Use case 5: Shrinking the VPN . . . . . . . . . . . . . . 14
4.6. Use case 6: VPN selection . . . . . . . . . . . . . . . . 14 4.6. Use case 6: VPN selection . . . . . . . . . . . . . . . . 14
5. Requirements and gap analysis . . . . . . . . . . . . . . . . 14 4.7. Use case 7: Other use cases . . . . . . . . . . . . . . . 14
5.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 14 5. Requirements and potential solutions . . . . . . . . . . . . 15
5.2. Gap analysis . . . . . . . . . . . . . . . . . . . . . . . 15 5.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 15
5.3. Differences from other proposed ALTO extensions . . . . . 16 5.2. Potential Solutions . . . . . . . . . . . . . . . . . . . 16
6. Security considerations . . . . . . . . . . . . . . . . . . . 18 6. Security considerations . . . . . . . . . . . . . . . . . . . 17
7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 18 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 17
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
8.1. Normative References . . . . . . . . . . . . . . . . . . . 18 8.1. Normative References . . . . . . . . . . . . . . . . . . 18
8.2. Informative References . . . . . . . . . . . . . . . . . . 18 8.2. Informative References . . . . . . . . . . . . . . . . . 18
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 19 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
1. Overview 1. Overview
Virtual Private Network (VPN) technology is widely used in public and Virtual Private Network (VPN) technology is widely used in public and
private networks to create groups of users that are separated from private networks to create groups of users that are separated from
other users of the network and allows these users to communicate other users of the network and allows these users to communicate
among them as if they were on a private network. According to among them as if they were on a private network. According to
[RFC4364], the generic term "Virtual Private Network" is used 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 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 that have been configured to allow communication. A site is a member
skipping to change at page 5, line 26 skipping to change at page 5, line 11
It is assumed that these sites are interconnected by a VPN that may It is assumed that these sites are interconnected by a VPN that may
be identified by the hypothetical name "vpn42". This document be identified by the hypothetical name "vpn42". This document
specifically considers two different VPN types for the specifically considers two different VPN types for the
interconnection: interconnection:
o L3VPN: The local area networks at each site will have a certain IP 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 subnet ranges, for instance 10.0.1.0/24 at site 1, 10.0.2.0/24 at
site 2, etc. site 2, etc.
o L2VPN: All sites form part for a flat sub-IP network, e.g. a o L2VPN: All sites form part for a flat sub-IP network, e.g. a
logical Ethernet segment. Different to a local network, the logical Ethernet segment. Different to a local network, the
network potentially interconnects geographically remote sites. network potentially interconnects geographically remote sites.
The VPN will not necessarily be static. The customer could possibly 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 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. demand or to consolidate VPN sites to account for reduced traffic.
The service provider could offer a Web portal or other Operation The service provider could offer a Web portal or other Operation
Support Systems (OSS) solutions that allow the customer to grow or Support Systems (OSS) solutions that allow the customer to grow or
consolidate the VPN. Details on how the customer can configure VPNs consolidate the VPN. Details on how the customer can configure VPNs
are outside the scope of this document. are outside the scope of this document.
skipping to change at page 8, line 31 skipping to change at page 8, line 31
| | | | | | | | | | | |
| PE #| |# #| |# PE | | PE #| |# #| |# PE |
\______| _ |_____| _ |______/ \______| _ |_____| _ |______/
|/ \| |/ \| |/ \| |/ \|
\_/ \_/ \_/ \_/
| | | |
CE device # # CE device CE device # # CE device
| | | |
V V V V
Site 1 Site 2 Site 1 Site 2
Chicago Ottawa
10.0.1.0/24 10.0.2.0/24 10.0.1.0/24 10.0.2.0/24
"pid14" "pid21" "pid14" "pid21"
Figure 2: Example for mapping of VPN sites to ALTO PIDs Figure 2: Example for mapping of VPN sites to ALTO PIDs
The costs exposed by the ALTO server can be based on routing costs The costs exposed by the ALTO server can be based on routing costs
inside the service provider network or other network topology inside the service provider network or other network topology
information, such as delay measurements, traffic engineering (TE) information, such as delay measurements, traffic engineering (TE)
data, etc. As with other use cases of ALTO, the costs can reflect data, etc. As with other use cases of ALTO, the costs can reflect
the service provider's preference and policies regarding the service provider's preference and policies regarding
skipping to change at page 11, line 24 skipping to change at page 11, line 24
environment e.g. with a reserved resources in an MPLS/IP wide area 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. network, these costs can be assumed to be rather stable and e. g.
reflect the reserved bandwidth between VPN sites. For an application reflect the reserved bandwidth between VPN sites. For an application
it is simpler and less intrusive to obtain such information about the it is simpler and less intrusive to obtain such information about the
VPN from the network instead of performing measurements, which would VPN from the network instead of performing measurements, which would
possibly require special probe instances at the different VPN sites possibly require special probe instances at the different VPN sites
(e. g., data centers). But as the encoding of such costs in ALTO is (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 independent of the usage of a VPN, this document does not mandate any
specific way how to build ALTO cost maps. 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 4.2. Use case 2: Application guidance in an L2VPN
The use case outlined in Example 1 also exists for L2VPNs, which are The use case outlined in Example 1 also exists for L2VPNs, which are
an important technology to transparently interconnect different LAN an important technology to transparently interconnect different LAN
segments of enterprise users. Again, applications could benefit from segments of enterprise users. Again, applications could benefit from
getting insight into topological properties of the wide area network getting insight into topological properties of the wide area network
providing the L2VPN service, in order to avoid the overhead of own providing the L2VPN service, in order to avoid the overhead of own
measurements. measurements.
Example 4: The user application described in Section 3.1 again wants Example 4: The user application described in Section 3.1 again wants
skipping to change at page 12, line 36 skipping to change at page 12, line 46
"SITE-CHICAGO" but no network addresses. The query could also be "SITE-CHICAGO" but no network addresses. The query could also be
more complex or include constraints, e. g., limited to a particular more complex or include constraints, e. g., limited to a particular
TE class. Note that the ATLO protocol does not necessarily have to TE class. Note that the ATLO protocol does not necessarily have to
support the query constraint itself; if corresponding maps are support the query constraint itself; if corresponding maps are
available, the application can analyze the data itself. available, the application can analyze the data itself.
Example 6: In absence of well-known existing network identifiers, a Example 6: In absence of well-known existing network identifiers, a
management application might want to query for VPN sites based on yet management application might want to query for VPN sites based on yet
other attributes, such as geographical distance. For example, an other attributes, such as geographical distance. For example, an
application might want to find all the VPN sites (i. e., application might want to find all the VPN sites (i. e.,
corresponding PIDs) within 50 KM of 45.35N, 75.92W. Such geographic corresponding PIDs) within 50 KM of 45.35N, 75.92W. Such geographic
queries would be typical of policies bounding delay by geographic queries would be typical of policies bounding delay by geographic
distance or administrative and legal requirements. distance or administrative and legal requirements.
Such application guidance is obviously similar to existing use of the Such application guidance is obviously similar to existing use of the
ALTO cost map or ranking services except that the queries are not ALTO cost map or ranking services except that the queries are not
based on network addresses. based on network addresses.
4.4. Use case 4: Extending the VPN 4.4. Use case 4: Extending the VPN
The customer can possibly grow the VPN to include new sites that are The customer can possibly grow the VPN to include new sites that are
skipping to change at page 14, line 35 skipping to change at page 14, line 44
Example 9: In a multi-homing environment, ALTO could be used to Example 9: In a multi-homing environment, ALTO could be used to
select one VPN out of several candidates to reach a certain select one VPN out of several candidates to reach a certain
destination, taking into account smaller costs, e. g., according to destination, taking into account smaller costs, e. g., according to
distance or to preferences of the network service provider network. distance or to preferences of the network service provider network.
This use case differs from the previous examples since more than one 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 VPN is involved, i. e., the ALTO guidance is not used to perform
application-layer traffic optimization within one VPN, but instead application-layer traffic optimization within one VPN, but instead
across different VPNs. across different VPNs.
5. Requirements and gap analysis 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].
5. Requirements and potential solutions
5.1. Requirements 5.1. Requirements
Based on the scenarios listed in Section 4, several requirements can Based on the scenarios listed in Section 4, several requirements can
be derived for a VPN Service in ALTO: be derived for a VPN Service in ALTO:
REQ 1: The existing ALTO protocol and RESTful interface should be 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 used as far as possible to enable an NSP to expose properties of a
VPN. VPN.
skipping to change at page 15, line 12 skipping to change at page 15, line 30
REQ 3: A VPN Service must use the PID concept of the base ALTO 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 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 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 ALTO services such as the map service for VPNs, as well as the
inherent topology abstraction provided by ALTO. inherent topology abstraction provided by ALTO.
REQ 4: A VPN Service must be possible for different VPN types, i. e., REQ 4: A VPN Service must be possible for different VPN types, i. e.,
it must not be limited to L3VPNs only. it must not be limited to L3VPNs only.
REQ 5: The VPN Service must support use cases where IP addresses are REQ 5: The VPN Service must support use cases where IP addresses are
not the only form of network identification. not the only form of endpoint identification.
REQ 6: If IP addresses are used, a VPN Service must not assume that REQ 6: If IP addresses are used, a VPN Service must not assume that
IP address are globally routable or unique. IP address are globally routable or unique.
REQ 7: A VPN Service should include certain attributes that are 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 unique to a VPN and that are not represented by the current set of
attributes in the base ALTO protocol. Examples include location name attributes in the base ALTO protocol. Examples include location name
of a site, geography coordinates (degree/digital), role, default of a site, geography coordinates (degree/digital), role, redundancy,
policy, or geography restriction. default policy, or geography restriction.
REQ 8: The PID must be selectable using standard ALTO filtering. A REQ 8: The PID must be selectable using standard ALTO filtering. A
standard interface query should allow finding resources using, say, standard interface query should allow finding resources using, say,
the location name attribute or the geography attributes. the location name attribute or the geography attributes.
REQ 9: The PID should be selectable using a filter that computes REQ 9: The PID should be selectable using a filter that computes
matching sites within a certain distance of a particular geographic matching sites within a certain distance of a particular geographic
coordinate based on latitude and longitude, in case that no other coordinate based on latitude and longitude, in case that no other
address information is known in advance. address information is known in advance.
REQ 10: Incremental build out (as well as the shrinking) of resources 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 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 service should also be able to expose information about new sites to
be attached to the VPN, or provide guidance for removal of sites. be attached to the VPN, or provide guidance for removal of sites.
REQ 11: Information about a VPN must only be exposed to authorized 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. users of that VPN.
5.2. Gap analysis 5.2. Potential Solutions
In the following we analyze to which extent the requirements of a VPN In the following we analyze how the requirements of a VPN Service can
Service can be met by the existing ALTO protocol. be addressed by ALTO extensions.
REQ 1: This is an inherent, general requirement for any new use or REQ 1: This is an inherent, general requirement for any new use or
extension of ALTO. extension of ALTO.
REQ 2: This requirement can be supported in ALTO today, because it is 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 left to the service provider which information to expose e.g. in ALTO
cost maps. cost maps.
REQ 3: The PID concept itself is generic and thus can fulfill this REQ 3: The PID concept itself is generic and thus can fulfill this
requirement. requirement.
REQ 4: L3VPNs are rather similar to existing use cases of ALTO in the 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 Internet. Insofar as L2VPNs or pseudo-wire VPNs have the notion of
some address, ALTO seems to able to handle these through an extension some address, ALTO seems to able to handle these through an extension
that extends the definition of an address to include other that extends the definition of an address to include other
identifiers besides IP addresses. identifiers besides IP addresses.
REQ 5: Use of ALTO with network identifiers that are not 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 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 endpoints and how to achieve a mapping to the information stored in
the ALTO server. 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 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 globally routable. However, it must be emphasized that private VPN
environments without uplink to the global Internet may only have environments without uplink to the global Internet may only have
connectivity to a limited number of IP subnets, i. e., the ALTO connectivity to a limited number of IP subnets, i. e., the ALTO
server will not be able to provide any reasonable guidance for most server will not be able to provide any reasonable guidance for most
parts of the IP address space. Also, the ALTO server operator must parts of the IP address space. Also, the ALTO server operator must
take into account that IP address ranges in different VPNs may take into account that IP address ranges in different VPNs may
overlap, possibly also with the transport network infrastructure (e. overlap, possibly also with the transport network infrastructure (e.
g., PE routers). g., PE routers).
REQ 7: Extensions to ALTO will be needed. 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. 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, aligned with REQ 6. 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. REQ 10: This requirement will possibly require extensions to ALTO, e.
g., to distinguish between endpoints that are already attached to the g., to distinguish between endpoints that are already attached to the
VPN and sites outside the VPN. Changes of the VPN topology are VPN and sites outside the VPN. This can be achieved e.g. by endpoint
likely to change the ALTO maps, i.e., standard ALTO mechanism for and/or PID properties. Changes of the VPN topology are likely to
incremental updates and push notifications would be of added value. change the ALTO maps, i.e., standard ALTO mechanism for incremental
updates and push notifications would be of added value.
REQ 11: Existing authentication and access control mechanisms for 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 ALTO could be sufficient to meet this requirement, subject to further
analysis. analysis.
5.3. Differences from other proposed ALTO extensions
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.
A use case of ALTO for traffic optimization in high bandwidth core
networks is discussed in [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 [I-D.bernstein-alto-large-bandwidth-cases]
are therefore not required by the use cases summarized in this
document.
A related extension proposal [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 [I-D.lee-alto-app-net-info-exchange] are orthogonal as
well.
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. 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.
[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.
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.
6. Security considerations 6. Security considerations
TBD. TBD.
7. IANA considerations 7. IANA considerations
TBD. TBD.
8. References 8. References
8.1. Normative References 8.1. Normative References
[I-D.ietf-alto-protocol] [I-D.ietf-alto-protocol]
Alimi, R., Penno, R., and Y. Yang, "ALTO Protocol", Alimi, R., Penno, R., and Y. Yang, "ALTO Protocol", draft-
draft-ietf-alto-protocol-17 (work in progress), July 2013. ietf-alto-protocol-25 (work in progress), January 2014.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual [RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual
Private Network (VPN) Terminology", RFC 4026, March 2005. Private Network (VPN) Terminology", RFC 4026, March 2005.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, February 2006. Networks (VPNs)", RFC 4364, February 2006.
[RFC4762] Lasserre, M. and V. Kompella, "Virtual Private LAN Service [RFC4762] Lasserre, M. and V. Kompella, "Virtual Private LAN Service
(VPLS) Using Label Distribution Protocol (LDP) Signaling", (VPLS) Using Label Distribution Protocol (LDP) Signaling",
RFC 4762, January 2007. RFC 4762, January 2007.
8.2. Informative References 8.2. Informative References
[I-D.bernstein-alto-large-bandwidth-cases] [I-D.lee-alto-ext-dc-resource]
Bernstein, G. and Y. Lee, "Use Cases for High Bandwidth Lee, Y., Bernstein, G., Dhody, D., and T. Choi, "ALTO
Query and Control of Core Networks", Extensions for Collecting Data Center Resource
draft-bernstein-alto-large-bandwidth-cases-02 (work in Information", draft-lee-alto-ext-dc-resource-03 (work in
progress), July 2012. progress), January 2014.
[I-D.lee-alto-app-net-info-exchange] [I-D.randriamasy-alto-cost-schedule]
Lee, Y., Bernstein, G., Choi, T., and D. Dhody, "ALTO Randriamasy, S. and N. Schwan, "ALTO Cost Schedule",
Extensions to Support Application and Network Resource draft-randriamasy-alto-cost-schedule-02 (work in
Information Exchange for High Bandwidth Applications", progress), October 2012.
draft-lee-alto-app-net-info-exchange-02 (work in
progress), July 2013.
[I-D.lee-alto-ext-dc-resource] [I-D.roome-alto-pid-properties]
Lee, Y., Bernstein, G., and D. Dhody, "ALTO Extensions for Roome, B. and Y. Yang, "PID Property Extension for ALTO
Collecting Data Center Resource Information", Protocol", draft-roome-alto-pid-properties-00 (work in
draft-lee-alto-ext-dc-resource-02 (work in progress), progress), October 2013.
July 2013.
[I-D.xie-alto-sdn-use-cases] [I-D.wu-alto-te-metrics]
Xie, H., Tsou, T., Lopez, D., and H. Yin, "Use Cases for Wu, W., Lee, Y., Dhody, D., and S. Randriamasy, "ALTO
ALTO with Software Defined Networks", Traffic Engineering Cost Metrics", draft-wu-alto-te-
draft-xie-alto-sdn-use-cases-01 (work in progress), metrics-00 (work in progress), October 2013.
June 2012.
Appendix A. Acknowledgements Appendix A. Acknowledgements
TBD. TBD.
Authors' Addresses Authors' Addresses
Michael Scharf (editor) Michael Scharf (editor)
Alcatel-Lucent Alcatel-Lucent
 End of changes. 30 change blocks. 
132 lines changed or deleted 109 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/