Internet DRAFT - draft-gao-alto-info-extension
draft-gao-alto-info-extension
ALTO WG K. Gao
Internet-Draft Tsinghua University
Expires: January 7, 2016 Y. Yang
Yale University
July 6, 2015
ALTO Extensions for Multi-Source Information Collection
draft-gao-alto-info-extension-01
Abstract
The Application-Layer Traffic Optimization (ALTO) protocol enables
the distribution of certain network information to applications.
Hence, a fundamental functionality of an ALTO server is to collect
general network information, especially from multiple "information
sources". In this document, we propose a preliminary solution to
standardize the process of information collection for ALTO servers by
extending the ALTO protocol with some new services, which can also
serve as a unified approach of network information distribution.
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 January 7, 2016.
Copyright Notice
Copyright (c) 2015 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
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
Gao & Yang Expires January 7, 2016 [Page 1]
Internet-Draft ALTO Extensions July 2015
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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
1.2. Terminology and Notation . . . . . . . . . . . . . . . . 4
2. ALTO Servers and Information Sources . . . . . . . . . . . . 4
2.1. Information Sources . . . . . . . . . . . . . . . . . . . 4
2.2. Relationship Analysis . . . . . . . . . . . . . . . . . . 5
3. Protocol Design . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Common ALTO Information Bases . . . . . . . . . . . . . . 7
3.2. Overview of Extended ALTO Services . . . . . . . . . . . 8
3.3. Extended Network Map . . . . . . . . . . . . . . . . . . 8
3.4. Information Map . . . . . . . . . . . . . . . . . . . . . 12
3.5. Endpoint Information Service . . . . . . . . . . . . . . 16
4. Future Improvement . . . . . . . . . . . . . . . . . . . . . 20
4.1. Deriving ALTO Services from the Extensions . . . . . . . 20
4.2. Information Aggregation Services . . . . . . . . . . . . 21
4.3. Scope for Extended ALTO Services . . . . . . . . . . . . 22
4.4. The Regulation of Property Specifications . . . . . . . . 22
4.5. Fetching Filtered Topological Information . . . . . . . . 23
5. Security Considerations . . . . . . . . . . . . . . . . . . . 23
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
6.1. Media Types . . . . . . . . . . . . . . . . . . . . . . . 23
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
7.1. Normative References . . . . . . . . . . . . . . . . . . 24
7.2. Informative References . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction
The "Application-Layer Traffic Optimization" protocol proposed in
[RFC7285] defines several "maps" to publish network information to
applications so that both the network providers and the application
users can make better decisions on traffic steering and eventually
achieve better performance. However by specifying the protocol
between ALTO clients and servers, [RFC7285] only describes part of
the service model. In this document we focus on the service model of
ALTO servers.
A fundamental functionality of the ALTO server is to collect
information from what we call "information sources". It is not
surprising that there are many different information sources and thus
we can describe a more complete service model for the server's side
Gao & Yang Expires January 7, 2016 [Page 2]
Internet-Draft ALTO Extensions July 2015
in Figure 1, where the arrows indicate the direction of information
flow.
+--------+ Method #1 +---------------+
ALTO | | <----------+ Information |
+----------+ Protocol | | | Source #1 |
| ALTO | <--------- | | +---------------+
| Client | | |
+----------+ | | Method #2 +---------------+
| | <----------+ Information |
... ... | ALTO | | Source #2 |
| Server | +---------------+
+----------+ ALTO | |
| ALTO | Protocol | | ... ...
| Client | <--------- | |
+----------+ | | Method #N +---------------+
| | <----------+ Information |
| | | Source #N |
+--------+ +---------------+
Figure 1: Service Model for an ALTO server
Since the relationships between ALTO servers and information sources
can be very complex, as discussed in Section 2.2, the communication
between them can hardly be unified. Nevertheless, it is still
possible and beneficial to design a generic protocol to collect
statistics for servers implemented with certain patterns of ALTO
information bases.
With a standard protocol, the implementation of ALTO servers can be
decoupled from the implementations of information sources, making it
much easier to support the feature of fetching information from
multiple sources and to be compatible with new information sources.
Section 3 introduces the proposed protocol format in details.
Despite the initial motivation to help ALTO server implementations
gather necessary information, the protocol can also be applied as a
unified information distribution method.
1.1. Requirements Language
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].
Gao & Yang Expires January 7, 2016 [Page 3]
Internet-Draft ALTO Extensions July 2015
1.2. Terminology and Notation
This document uses the following terms: Application, ALTO Server,
ALTO Client and ALTO Response defined in [RFC5693]; Endpoint, ALTO
Information and ALTO Information Base defined in [RFC7285].
This document uses the same notations of describing JSON objects in
[RFC7285], which are specified in [RFC7159].
This document uses the following additional terms: Information
Source.
o Information Source
An information source is an entity that provides basic information
for ALTO servers, see more detailed description in Section 2.1.
2. ALTO Servers and Information Sources
This section introduces the concept of "information sources" and
discusses the possible relationships between an ALTO server and an
information source.
2.1. Information Sources
An "information source" can be roughly described as any entity that
is capable of providing information on the network but the exact
meaning depends on the server implementation. For example, in
Software Defined Networking (SDN), for an ALTO server calculating the
hop counts by calling the corresponding northbound API of a SDN
controller, the controller is an information source. Meanwhile, for
an ALTO server using round trip time (RTT) as the routing cost
metric, P2P clients submitting the statistics of a connection are
regarded as information sources. In this document we identify four
major kinds of information sources:
o Human Input
It is possible that the administrators of an ALTO server want to
modify the output to meet the need of certain demands such as
policy changes, so they may compose some data accordingly and
input them into the server. Also in the early stages of ALTO
server development, human interference is inevitable to detect
abnormal behavior.
o Network Measurement Tools
Gao & Yang Expires January 7, 2016 [Page 4]
Internet-Draft ALTO Extensions July 2015
Due to financial, technical and security reasons it has been hard
to fetch the required data directly from ISPs, thus many efforts
have been made to measure different metrics using endpoint-based
tools. Since most of these tools require little support from the
network infrastructure, lots of them can still work even if the
Internet architecture evolves. These measurement techniques can
be valuable sources to ALTO services as the measured results often
reflect the actual performance of the network.
o Network Operating Systems
With the progress in opening up the network in recent years,
especially with the development of SDN, the networking system
itself has become an important source of network information.
Using "northbound" APIs provided by SDN controllers, one can get
both the configurations and the accurate running states of a
network.
o Information Aggregators
While information sources discussed above are capable to provide
the "raw" data, these data can be aggregated, by a third-party
aggregator or by a higher-level network OS as in some hierarchical
SDN controller designs. It is notable that an ALTO server itself
can also be regarded as a source of aggregated information.
2.2. Relationship Analysis
The complexity of the relationships between ALTO servers and
information sources comes from the following aspects:
o How to identify the boundary;
o How ALTO servers and information sources are coupled;
o The capabilities of information sources.
2.2.1. Identification of Boundaries
When we discuss the relationship between an ALTO server and the
information source, it is important to identify the boundary first.
As it is shown in Figure 2, we can see with different boundaries,
different pairs of ALTO servers and information sources can be
identified and their relationships are not quite the same.
Gao & Yang Expires January 7, 2016 [Page 5]
Internet-Draft ALTO Extensions July 2015
+------------------+-----------------------------------------------+
| ALTO Server #A | Information Source #A |
+---------------------------------------+
+--------+ | +---------+ |
| | | | | Information |
| Host +------------+ Agent | Source #0 |
| | | | | |
+--------+ | +---------+ |
+---------------------------------------+
| ALTO SERVER #B | Information Source #B |
+--------------------------------------+---------------------------+
Figure 2: Different Ways to Identify the Boundary
2.2.2. Types of Coupling
We identify three types of coupling ALTO servers and information
sources.
o The ALTO server is deeply embedded into the information source,
which is either a network OS or an information aggregator. For
example, our group has participated in a project to provide ALTO
services in [OpenDaylight], an industrial SDN controller.
o The ALTO server is loosely coupled with the information source.
One example is the ALTO server #A in Figure 2 if the host and
agents are still coupled by some private protocol.
o The ALTO server is decoupled from the information sources by a
standard protocol. For example, an ALTO server which calculates
its own costs by merging the routing costs from some other ALTO
servers is decoupled from the its information sources as long as
they can provide standard ALTO cost map service with the
corresponding cost type.
2.2.3. Capabilities of Information Sources
The capabilities of an information source, which declare the types of
available information, are determined by the type of the information
source and the limitation of the targeted network, both of which can
vary significantly. However, many capabilities are attached to a
certain network element such as a router, a link, an attachment
point, etc., which can significantly reduce the complexity.
Gao & Yang Expires January 7, 2016 [Page 6]
Internet-Draft ALTO Extensions July 2015
3. Protocol Design
As described above it is difficult to define a unified protocol to
cover the need of ALL ALTO server implementations. However, we can
narrow down the demands by establishing clear boundaries and focus on
the most general and most commonly used requirements.
An observation is made that as mentioned in Section 2.1, the ALTO
servers are actually one kind of information source and the ALTO
protocol is designed to publish certain network information. Hence,
instead of designing a new protocol for data collection, which would
result in functionality overlap with ALTO and introduce complexity
from an implementation perspective, the solution proposed in this
document is based on the ALTO protocol to avoid these drawbacks. In
this case, information sources can also take advantages of the ALTO
framework such as the service discovery mechanism, and current ALTO
implementations don't have to change anything if they want to serve
as information sources too.
To clarify the boundaries of the targeted information and to exploit
the limitation of the current ALTO specification, especially for the
network map service, two internal representations of an ALTO
information service are introduced. We derive our design based on
these two representations and discuss how to extend the ALTO
specification so that the extensions can fit in the framework.
3.1. Common ALTO Information Bases
Two typical internal representations of ALTO server implementations,
as known as ALTO information bases, are identified for ALTO services
as discussed below. It can be seen that both structures are highly
related to and can reflect the information sources they use.
o End-to-End
In an end-to-end implementation, the network is represented as a
full-mesh graph where the links are implicit and can be ignored.
This can happen when the corresponding information source collects
the information either by conducting end-to-end measurement
methods or by making requests to other end-to-end information
resources, whether as an intentional choice or being forced to do
so because of the limitations of conditions or priorities to get
topological information.
o Topological
In this case the server is using a graph with explicit nodes and
links to represent a network. The graph is usually sparse and may
Gao & Yang Expires January 7, 2016 [Page 7]
Internet-Draft ALTO Extensions July 2015
have internal nodes that are transparent to the ALTO clients.
Such examples are servers retrieving topology information from a
SDN controller, from a data aggregator such as CAIDA, or simply
from a configuration parser.
3.2. Overview of Extended ALTO Services
It can be seen that the current ALTO specifications only publish end-
to-end information to the clients. That is probably good enough for
end users to choose from different destinations, however, it cannot
satisfy the needs of an implementation with a topological ALTO
information base because the original ALTO protocol is not capable of
publishing topological information.
To support this feature, the following extensions are proposed for
ALTO protocol:
o Section 3.3 introduces an extension of network maps which enables
the distribution of topologies;
o Section 3.4 introduces the extension to publish information for
all elements defined in the extended network map.
o Section 3.5 introduces the extension to support querying
information between two endpoints.
3.3. Extended Network Map
The extended network map can publish topological information such as
links between different endpoints. The data component in the
response uses the classic vertex-edge representation to describe the
topology.
Just as with the network map, filtering is also possible for the
extended network map but due to timing issues it is not discussed in
this document.
3.3.1. Media Type
The media types for extended network map is defined in Section 6.1.
3.3.2. HTTP Method
The extended network map is requested using the HTTP GET method.
Gao & Yang Expires January 7, 2016 [Page 8]
Internet-Draft ALTO Extensions July 2015
3.3.3. Accept Input Parameters
None
3.3.4. Capabilities
The capabilities of an extended network map are described using a
JSON object of type ExtNetworkMapCapabilities:
object {
JSONString type<1..1>;
} ExtNetworkMapCapabilities;
with fields:
o type: the type of information that is published. Currently the
only valid options are "end-to-end" and "topological".
3.3.5. Uses
None.
3.3.6. Response
The "meta" field of the response is the same as of network map
responses.
The data component of an extended network map service is named
"extended-network-map", which is a JSON object of type
ExtNetworkMapData, where
object {
ExtNetworkMapData extended-network-map;
} InfoResourceExtNetworkMap : ResponseEntityBase;
object {
NodeData nodes;
[LinkData links;]
} ExtNetworkMapData;
object-map {
NodeName -> NodeDesc;
} EndpointData;
object {
[JSONBool internal;]
} NodeDesc : EndpointAddrGroup;
Gao & Yang Expires January 7, 2016 [Page 9]
Internet-Draft ALTO Extensions July 2015
object-map {
LinkName -> LinkDesc;
} LinkData;
object {
JSONString pid<2..2>;
JSONString direction;
} LinkDesc;
If the "type" field in the capabilities is "end-to-end", there MUST
be no "links" field in the data component and no "internal" field in
any node description. At the same time, ALTO clients MUST ignore
these fields if they are mistakenly provided.
If the "type" field in the capabilities is "topological", the "links"
field and the "internal" field MUST be provided.
The "direction" field indicates the allowed direction of traffic.
The optional values are "both", "ltr" and "rtl". If the value is not
"both", the pid MUST be sorted to represent the correct direction
where "ltr" indicates the direction of pid_0 --> pid_1 while "rtl"
indicates pid_0 <-- pid_0.
3.3.7. Example
Figure 3 demonstrates a simple topology.
+-----------+ +-----------+
| Node #1 |----\ | Node #4 |
+-----------+ | +-----------+
| | |
| | /
\ | /
\ +-----------+ +-----------+
-------| Node #3 |______| node #6 |
+-----------+ +-----------+
| |
/ \
/ \
+-----------+ +-----------+
| Node #2 | | Node #5 |
+-----------+ +-----------+
Figure 3: Example Topology
The example request and the corresponding response for the extended
network map based on this topology is given below.
Gao & Yang Expires January 7, 2016 [Page 10]
Internet-Draft ALTO Extensions July 2015
GET /extnetworkmap HTTP/1.1
Host: alto.example.org
Accept: application/alto-extnetworkmap+json,
application/alto-error+json
HTTP/1.1 200 OK
Content-Length: 1252
Content-type: application/alto-extnetworkmap+json
{
"meta" : {
"vtag": {
"resource-id": "extended-network-map-example",
"tag": "67e6183c00fe467a960f174b93f23cf7"
}
},
"extended-network-map": {
"nodes": {
"node#1": {
"internal": "false",
"ipv4": [ "192.168.1.0/28" ]
},
"node#2": {
"internal": "false",
"ipv4": [ "192.168.1.128/28" ]
},
"node#3": {
"internal": "true"
},
"node#4": {
"internal": "false",
"ipv4": [ "192.168.2.0/28" ]
},
"node#5": {
"internal": "false",
"ipv4": [ "192.168.2.128/28" ]
},
"node#6": {
"internal": "true"
}
},
"links": {
"link#1": {
"pid": ["node#1", "node#3"],
"direction": "both"
},
"link#2": {
"pid": ["node#1", "node#3"],
Gao & Yang Expires January 7, 2016 [Page 11]
Internet-Draft ALTO Extensions July 2015
"direction": "both"
},
"link#3": {
"pid": ["node#2", "node#3"],
"direction": "both"
},
"link#4": {
"pid": ["node#4", "node#6"],
"direction": "both"
},
"link#5": {
"pid": ["node#5", "node#6"],
"direction": "both"
},
"link#6": {
"pid": ["node#3", "node#6"],
"direction": "both"
}
}
}
}
3.4. Information Map
The information map has many similarities with the cost map. Instead
of providing only the "cost" between endpoints, it is extended to
publish generic network information for both endpoint/node pairs and
links. It is notable that there are no explicit distinctions between
attributes and statistics, where the former represent the essence and
configurations of the object that should seldom change while the
latter represent the dynamic running state of a network. However, an
ALTO server can provide such indications in the corresponding
specifications.
Due to timing issues, the filtering on the information map is not
described in this document but it is worthy pointing out that the
filtered information map is quite essential to enhance the
performance of fetching data for the interested nodes or links.
3.4.1. Media Type
The media types for information map is defined in Section 6.1.
3.4.2. HTTP Method
The information map is requested using the HTTP GET method.
Gao & Yang Expires January 7, 2016 [Page 12]
Internet-Draft ALTO Extensions July 2015
3.4.3. Accept Input Parameters
None
3.4.4. Capabilities
The capabilities of an information map are described using a JSON
object of type InfoMapCapabilities:
object {
JSONString properties<0..*>;
} InfoMapCapabilities;
with fields:
o properties: the list containing the property names of paths and
links. The names SHOULD indicate the exact target using prefixes
such as "path-" or "link-". The properties here CAN contain both
characteristic attributes and statistics for a given path/link.
3.4.5. Uses
The resource ID of the network map or the extended network map based
on which the information map will be defined.
3.4.6. Response
The "meta" field of the response is described using the following
JSON object:
object {
VersionTag dependent-vtags<1..1>;
VersionTag vtag;
[PropertyName -> PropertySpec;]
} InfoMapMetaData;
object {
JSONString type;
[PropertyAttrName -> JSONValue;]
} PropertySpec;
with fields:
o vtag: the same as the "vtag" in the network map;
o dependent-vtags: the same as the "dependent-vtags" in the cost
map, with the addition that resource ID can point to an extended
network map;
Gao & Yang Expires January 7, 2016 [Page 13]
Internet-Draft ALTO Extensions July 2015
o PropertyName: the name listed in the capabilities.
The "type" field in PropertySpec is either "path" or "link".
The data component of an information map service is named
"information-map", which is a JSON object of type InfoMapData, where:
object {
InfoMapData information-map;
} InfoResourceInfoMap : ResponseEntityBase;
object-map {
PropertyName -> PropertyMapData;
} InfoMapData;
object-map {
NodeName -> { NodeName -> JSONValue };
} PathPropertyData : PropertyMapData;
object-map {
LinkName -> JSONValue;
} LinkPropertyData : PropertyMapData;
If the "type" field in the corresponding PropertySpec is "path", the
type of the PropertyMapData MUST be PathPropertyData and the same
restriction rule applies to "link" and LinkPropertyData.
3.4.7. Example
The example of getting the hop counts between nodes, link cost and
the link capacities is given below, using the topology in Figure 3.
GET /example-infomap HTTP/1.1
Host: alto.example.org
Accept: application/alto-infomap+json,
application/alto-error+json
HTTP/1.1 200 OK
Content-Length: 1434
Content-type: application/alto-infomap+json
{
"meta": {
"vtag": {
"resource-id": "infomap-example",
"tag": "e7822fdd03814561bdb955667ca06534"
},
"dependent-vtags": [
Gao & Yang Expires January 7, 2016 [Page 14]
Internet-Draft ALTO Extensions July 2015
{
"resource-id": "extended-network-map-example",
"tag": "67e6183c00fe467a960f174b93f23cf7"
}
],
"path-hop-count-cost": {
"type": "path",
"mode": "numerical",
"metric": "hopcount"
},
"link-cost": {
"type": "link",
"mode": "numerical",
"metric": "routingcost"
},
"link-capacity": {
"type": "link",
"format": "text"
}
},
"information-map": {
"path-hop-count-cost": {
"node#1": {
"node#1": 0, "node#2": 2, "node#3": 1,
"node#4": 3, "node#5": 3, "node#6": 2
},
"node#2": {
"node#1": 2, "node#2": 0, "node#3": 1,
"node#4": 3, "node#5": 3, "node#6": 2
},
"node#3": {
"node#1": 1, "node#2": 1, "node#3": 0,
"node#4": 2, "node#5": 2, "node#6": 1
},
"node#4": {
"node#1": 3, "node#2": 3, "node#3": 2,
"node#4": 0, "node#5": 2, "node#6": 1
},
"node#5": {
"node#1": 3, "node#2": 3, "node#3": 2,
"node#4": 2, "node#5": 0, "node#6": 1
},
"node#6": {
"node#1": 2, "node#2": 2, "node#3": 1,
"node#4": 1, "node#5": 1, "node#6": 0
}
},
"link-cost": {
Gao & Yang Expires January 7, 2016 [Page 15]
Internet-Draft ALTO Extensions July 2015
"link#1": 2,
"link#2": 1,
"link#3": 1,
"link#4": 1,
"link#5": 1,
"link#6": 1
},
"link-capacity": {
"link#1": "10Gbps",
"link#2": "5Gbps",
"link#3": "10Gbps",
"link#4": "10Gbps",
"link#5": "10Gbps",
"link#6": "20Gbps"
}
}
}
3.5. Endpoint Information Service
The endpoint information service to the information map is just as
the endpoint cost service to the cost map. It provides only the
requested information for paths specified by given pairs of
addresses.
3.5.1. Media Type
The media types for endpoint information service is defined in
Section 6.1.
3.5.2. HTTP Method
The endpoint information service is requested using the HTTP POST
method.
3.5.3. Accept Input Parameters
The input parameters for the endpoint information service is
described using the following JSON object:
object {
EndpointFilter endpoints;
[PropertySpecName -> PropertySpec;]
[JSONString constraints<0..*>;]
} EndpointInfoReq;
Gao & Yang Expires January 7, 2016 [Page 16]
Internet-Draft ALTO Extensions July 2015
The EndpointFilter is the same as defined in [RFC7285]. The
PropertySpec is the same as defined in Section 3.4. The
"constraints" have the following three components:
o A property name that indicates the property to filter. The
corresponding property MUST be declared in the capabilities
otherwise it MUST be ignored.
o An operator as defined in [RFC7285]
o A constant or a symbolic property to be compared to.
3.5.4. Capabilities
The capabilities of the endpoint information service are described
using a JSON object of type EndpointInfoCapabilities:
object {
JSONString properties<0..*>;
} EndpointInfoCapabilities;
with fields:
o properties: the list containing the property names between
endpoints.
3.5.5. Uses
The resource ID of the network map, information map or the extended
network map based on which the endpoint information service will be
defined.
3.5.6. Response
The "meta" field of the response is described using the following
JSON object:
object {
VersionTag dependent-vtags<1..1>;
VersionTag vtag;
[PropertyName -> PropertySpec;]
} EISMetaData;
object {
JSONString type;
[PropertyAttrName -> JSONValue;]
} PropertySpec;
Gao & Yang Expires January 7, 2016 [Page 17]
Internet-Draft ALTO Extensions July 2015
with fields:
o dependent-vtags: the same as the "dependent-vtags" in the cost
map, with the addition that resource ID can point to an extended
network map;
o vtag: the same as in the network map;
o PropertyName: the name listed in the request.
The data component of an endpoint information service is named
"endpoint-information", which is a JSON object of type EISData,
where:
object {
EISData endpoint-information;
} InfoResourceEISData : ResponseEntityBase;
object-map {
PropertyName -> EISPropertyMapData;
} EISData;
object-map {
TypedNodeAddr -> { TypedNodeAddr -> JSONValue };
} EISPropertyMapData;
3.5.7. Example
The example of getting the routing cost is given below, using the
same topology and routing cost information as in Section 3.4.7.
Gao & Yang Expires January 7, 2016 [Page 18]
Internet-Draft ALTO Extensions July 2015
POST /eis-example HTTP/1.1
Host: alto.example.org
Content-Length: 329
Content-type: application/alto-endpointinfoparam+json
Accept: application/alto-endpointinfo+json,
application/alto-error+json
{
"endpoints": {
"srcs": [ "ipv4:192.168.1.12", "node:node#1" ],
"dsts": [
"ipv4:192.168.1.13",
"ipv4:192.168.2.34",
"node:node#2"
]
},
"path-routingcost": {
"type": "path",
"mode": "numerical",
"metric": "routingcost"
},
"constraints": ["link-capacity > 8Gbps"]
}
HTTP/1.1 200 OK
Content-length: 601
Content-type: application/alto-endpointinfo+json
{
"meta": {
"vtag": {
"resource-id": "eis-example",
"tag": "5ffb08265da64136a13978055f3affb6"
},
"dependent-vtags": [
{
"resource-id": "extended-network-map-example",
"tag": "67e6183c00fe467a960f174b93f23cf7"
},
{
"resource-id": "infomap-example",
"tag": "e7822fdd03814561bdb955667ca06534"
}
]
},
Gao & Yang Expires January 7, 2016 [Page 19]
Internet-Draft ALTO Extensions July 2015
"endpoint-information": {
"path-cost": {
"ipv4:192.168.1.12": {
"ipv4:192.168.1.13": 0,
"ipv4:192.168.2.34": 4
},
"node:node#1": {
"node:node#2": 3
}
}
}
}
With the constraint of "link-capacity > 8Gbps" in the request, link#2
should be filtered so the routing cost between node#1 and node#4 is 4
instead of 3.
It is notable that the endpoint information is only provided between
endpoints with the same address type.
4. Future Improvement
In the preceding sections three new ALTO services are introduced,
however, they only provide basic functionalities to distribute
general network information. In this section we discuss some
advanced topics about the extensions for enhancements in
functionalities and performance.
4.1. Deriving ALTO Services from the Extensions
Even though the extended network map is capable to provide
topological information, sometimes applications would still only
request for end-to-end information. Also, due to backward-
compatibility considerations, a network map derived from the extended
network map is desired.
One simple implementation is to crop the "links" field from the data
component in an extended network map response, ignore all internal
nodes and rename the "nodes" field to "network-map".
At the same time, new information maps and an endpoint information
services can be derived from the corresponding ones for the base
extended network map. For example, consider the hop count as the
targeted information, the hop counts between two endpoints can be
derived by summing up the hop counts (which all have the value of 1)
on all the links on the path. That example also demonstrate how the
cost map can be derived from certain information maps.
Gao & Yang Expires January 7, 2016 [Page 20]
Internet-Draft ALTO Extensions July 2015
4.2. Information Aggregation Services
With the extensions introduced in Section 3, an generic ALTO server
implementation can collect information by querying other ALTO servers
providing these information. However, question still remains that
how the original data can be collected.
One possible way is to use customized ALTO servers, for example, one
embedded into a SDN controller.
Another approach is to enable passive data collection in an ALTO
server where the ALTO server declares a new kind of ALTO
"aggregation" service. The aggregation service defines the format of
information it can resolve so that information sources, whether they
are ALTO servers, ALTO clients or third-party agents, can push the
data to the server.
The Internet Draft [I-D.ietf-alto-incr-update-sse], which uses
Server-Sent Events (SSE) to push incremental updates to the ALTO
clients, can also be used as a passive data collection method. Both
methods can transport partial data to the aggregator ALTO server,
however, the information sources using the "aggregation" service
don't have to launch an ALTO server instance, thus this approach
allows more lightweight publishers and can apply in more general
scenarios.
A comparison between the methods mentioned above is listed in
Table 1. In "Ext-ALTO with SSE" and "Ext-ALTO", the aggregator ALTO
server acts as a client to the publisher ALTO servers which provide
the extended ALTO services introduced in this document with and
without the SSE mechanism respectively. In "ALTO Aggregation", the
aggregator ALTO server is providing the "aggregation" service and
there is no demand on the publisher other than following the
protocol.
+--------------------+--------------+--------------+---------------+
| Description | Aggregator | Publisher | Partial Data |
+--------------------+--------------+--------------+---------------+
| Ext-ALTO | ALTO Server | ALTO Server | No |
| | Active | Passive | |
| Ext-ALTO with SSE | ALTO Server | ALTO Server | Yes |
| | Active | Active | |
| ALTO Aggregation | ALTO Server | Any | Yes |
| | Passive | Active | |
+--------------------+--------------+--------------+---------------+
Table 1: Comparison between Different Ways to Collect Data
Gao & Yang Expires January 7, 2016 [Page 21]
Internet-Draft ALTO Extensions July 2015
4.3. Scope for Extended ALTO Services
With the approaches in Section 3 and the ones discussed in sections
above, we represent how ALTO protocol can be used to distribute
network information to the applications in Figure 4 where the normal
paths represent ALTO protocol and the starred path represents some
private protocol.
+---------------------+ +--------------------+
| | ********+ |
| | * | Private |
| v v | Information Source |
| +--+-------+--+ | |
+------+------+ | | +--------------------+
| +<----------+ Generic |
| ALTO Client | | ALTO Server | +-------------+
| | +--------+ +<----------+ |
+-------------+ | +--+----------+ | Third-Party |
| ^ | Aggregator |
v | +-------------+ | |
+---------+---+ +-----+ | +-------------+
| | | Customized |
| ALTO Client | | ALTO Server |
| +<------------+ |
+-------------+ +-------------+
Figure 4: AN ALTO Deployment Scenario
4.4. The Regulation of Property Specifications
In the specifications for the information map and endpoint
information service, the information to be published is identified by
so-called property specifications. However, there are no standard
providing the specifications of other properties at the moment. Even
though the specification for "cost-type" proposed in [RFC7285] can be
seen as an example, it can still lead to confusions if two ALTO
servers happen to use the same mode-metric combination but use
different measure units.
Just like the cost types in [RFC7285], a registry for the information
specification used by the information map and the endpoint
information service MUST be created and maintained by IANA in the
future. To get started, future proposals SHOULD designate some
initial values by providing the specifications for some commonly used
information, such as the link capacity, available bandwidth, etc.
Another approach is to design a management system where new
specifications can be validated and registered with an "exp:" prefix,
Gao & Yang Expires January 7, 2016 [Page 22]
Internet-Draft ALTO Extensions July 2015
which indicates that they are experimental properties, before they
are standardized.
4.5. Fetching Filtered Topological Information
One way to fetch filtered topological information, as the name
suggests, is to use the filtered information map which returns only
the requested data of the requested nodes/links. The filtered
information map has not been specified in this document yet but is
planned to be included in future updates.
Another approach can be achieved in the following way: First use a
special type of TypedNodeAddr, the "NodeName", to identify the
targeted nodes, and then implement an endpoint information service
that returns the links between two requested nodes with all the
requested data attached. This particular service can be useful to
merge the given sequence of links to a single "virtual" link, which
may help reduce the size of network view and encapsulate details of
the original topology.
5. Security Considerations
This document has not conducted its security analysis.
6. IANA Considerations
This document defines registries for application/alto-* media types.
6.1. Media Types
The media types for the three ALTO extensions are listed below:
+--------------+------------------------------+----------------+
| Type | Subtype | Specification |
+--------------+------------------------------+----------------+
| application | alto-extnetworkmap+json | Section 3.3.6 |
| application | alto-infomap+json | Section 3.4.6 |
| application | alto-endpointinfo+json | Section 3.5.6 |
| application | alto-endpointinfoparam+json | Section 3.5.3 |
+--------------+------------------------------+----------------+
Table 2: Media Types
The media types defined in this document have the same constraints
and properties as those defined in [RFC7285], except the authors'
information.
Gao & Yang Expires January 7, 2016 [Page 23]
Internet-Draft ALTO Extensions July 2015
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
7.2. Informative References
[I-D.ietf-alto-incr-update-sse]
Roome, W. and Y. Yang, "ALTO Incremental Updates Using
Server-Sent Events (SSE)", draft-ietf-alto-incr-update-
sse-00 (work in progress), May 2015.
[OpenDaylight]
Medved, J., Varga, R., Tkacik, A., and K. Gray,
"Opendaylight: towards a model-driven sdn controller
architecture", 2014.
[RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic
Optimization (ALTO) Problem Statement", RFC 5693, October
2009.
[RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data
Interchange Format", RFC 7159, March 2014.
[RFC7285] Alimi, R., Penno, R., Yang, Y., Kiesel, S., Previdi, S.,
Roome, W., Shalunov, S., and R. Woundy, "Application-Layer
Traffic Optimization (ALTO) Protocol", RFC 7285, September
2014.
Authors' Addresses
Kai Gao
Tsinghua University
30 Shuangqinglu Street, Haidian District
Beijing 100084
China
Email: gaok12@mails.tsinghua.edu.cn
Gao & Yang Expires January 7, 2016 [Page 24]
Internet-Draft ALTO Extensions July 2015
Y. Richard Yang
Yale University
51 Prospect St
New Haven CT
USA
Email: yry@cs.yale.edu
Gao & Yang Expires January 7, 2016 [Page 25]
