One document matched: draft-scharf-alto-topology-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt'?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no"?>
<?rfc strict="no"?>
<?rfc compact="no"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-scharf-alto-topology-00" ipr="trust200902">
<front>
<title abbrev="Topology Maps in ALTO">Path-Vector and Node-Edge Topology Maps in ALTO</title>
<author fullname="Michael Scharf" initials="M." surname="Scharf">
<organization abbrev="Alcatel-Lucent Bell Labs">Alcatel-Lucent Bell Labs</organization>
<address>
<postal>
<street>Lorenzstrasse 10</street>
<code>70435</code>
<city>Stuttgart</city>
<country>Germany</country>
</postal>
<email>michael.scharf@alcatel-lucent.com</email>
</address>
</author>
<date year="2014" />
<area>Transport</area>
<workgroup>ALTO WG</workgroup>
<keyword>ALTO</keyword>
<keyword>Topology</keyword>
<abstract>
<t>The Application-Layer Traffic Optimization (ALTO) service
defines network and cost maps to provide basic network
information. This document motivates an optional extension of
ALTO for the definition of additional topology properties. The
ALTO extension supports both path-vector and node-edge topology
maps.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>The Application-Layer Traffic Optimization (ALTO) service
<xref target="I-D.ietf-alto-protocol"/> provides network
information (e.g., basic network location structure and
preferences of network paths) with the goal of modifying network
resource consumption patterns while maintaining or improving
application performance. The basic information of ALTO is based
on abstract maps of a network. These maps provide a simplified
view, yet enough information about a network for applications to
effectively utilize them.</t>
<t>Applications using an ALTO service typically consist of
instances running at endpoints. This is why ALTO maps provide
abstract cost and/or ranking information between network
endpoints. Yet, for selected use cases of ALTO, it is desirable
to have a more detailed representation of the network. For
instance, in settings with multiple application
source-destination pairs with multiple links, such a
representation could help avoid bottleneck or failed links.</t>
<t>Topology models for ALTO are also discussed in other related
documents. A full solution to extend ALTO is defined in <xref
target="I-D.yang-alto-topology"/>. An earlier survey of
use-cases for extended network topology information can also be
found in <xref target="I-D.bernstein-alto-topo"/>. Further
related work has been published in <xref
target="I-D.lee-alto-app-net-info-exchange"/> and <xref
target="I-D.bernstein-alto-large-bandwidth-cases"/>.</t>
<t>This document specifies two graph representation formats that
can be used in ALTO. Both formats are optional, and it is up to
the operator of an ALTO service to decide whether to offer this
data in addition to the standard network and cost maps of an
ALTO service. The graph representation defined in this document
is based on existing ALTO abstraction (e.g., PIDs) and
complements the existing path-based ALTO cost map
representation. Together, they provide a more complete but still
abstract representation of networks for informed traffic
optimization among endpoints.</t>
<t>This document does not intend to model topology internals not
affecting endpoints, such as routing protocol internals. A data
model for network topologies with routing protocol externals can
for instance be found in <xref
target="I-D.clemm-i2rs-yang-network-topo"/>.</t>
</section>
<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="Endpoint-Centric Network Topology Models">
<section title="Use Cases">
<t>This document focuses on exposure of network topology
properties that matter to endpoints. Usually, applications
instances at network endpoints (hosts) only have to care about
end-to-end network properties of the paths between those
endpoints. The basic ALTO services, i.e., either the Network
and Cost Map service or the Endpoint Cost service, can be used
to express end-to-end characteristics of paths between
endpoints, as explained e.g. in <xref
target="I-D.ietf-alto-deployments"/> and <xref
target="I-D.wu-alto-te-metrics"/>.</t>
<t>However, there are a number of use cases in which it is
difficult to expose topological properties to applications
using only the mechanisms in the base ALTO protocol <xref
target="I-D.ietf-alto-protocol"/>. These uses cases are
typically characterized by multiple application
source-destination pairs:</t>
<t><list style="symbols">
<t>Shared bottleneck detection: As explained for instance in
<xref target="I-D.ietf-alto-deployments"/>, ALTO can be used
to avoid excessive use of bottleneck links by recommending
communication with endpoints not using that
bottleneck. However, if multiple application transfers shall
be scheduled, e.g., by a bandwidth calendaring application,
it can be difficult to determine whether the resulting
communication would hit a common bottleneck unless the
applications are aware of links that would be used by
multiple transfers. This would benefit from an ALTO
extension that can return shared parts of paths used by
transfers between different endpoints (e.g., given by IP
addresses).</t>
<t>Resilience improvement: Applications requiring high
reliability can be interested in understanding if there is a
risk of simultaneous failures on multiple path between
application instances. For instance, transport networks can
provide certain shared risk link group (SRLG) information
that provides insight which links are at risk of
simultaneous failures due to fate sharing. Applications
requiring high reliability may then prefer the use
of endpoints with disjoint paths.</t>
<t>Multi-homing and multi-pathing: If endpoints are
multi-homed, i.e., if hosts have more than one IP address,
it can be useful to know if there are multiple paths between
these endpoints. For instance, applications could leverage
such information to decide whether to explictly enable
Multipath TCP <xref target="RFC6824"/>.</t>
</list></t>
<t>None of these use cases requires an application to
understand routing protocol internals, such as the entries in
Routing Information Base (RIB) of routers in the network.
While it may be possible to derive such information from
corresponding models, such as <xref
target="I-D.clemm-i2rs-yang-network-topo"/>, ALTO targets
general-purpose applications that typically have no
understanding of RIB data, different routing protocols, etc.
Therefore, ALTO requires a more abstract solution to express
topology details. An optional ALTO graph representation
solution allows disclosure of such information to ALTO
clients.</t>
</section>
<section title="Topology Models">
<t>This document specifies two optional, abstract graph
representation format for ALTO, which can reveal for instance
coupling of links on a path. This section introduces the
topology model. The formal specification follows in the
next section.</t>
<t>There are two different graph representation formats that
could be used to generalize the existing ALTO network and cost
maps and reveal path coupling:</t>
<t><list style="symbols">
<t>Path-vector format: This format describes the topology
between given endpoints by an enumeration of the path
traversed between the source and destination. The advantage
of this format is that it can consider the outcome of
network-internal routing policies (e.g., preferring paths
other than the shortest path given by routing
metrics). However, for a large network with many paths there
is a large representation overhead.</t>
<t>Node-edge format: A graph encoding with nodes and edges
can be very compact, depending on the average node degree,
and it can also be much smaller than the full mesh of costs
between endpoints that is used by ALTO cost maps. Yet, a
downside is that a single graph may not convey network
routing policies.</t>
</list></t>
<t>Since both formats have advantages and drawbacks, this
document allows the use of both formats, and it is up
to the ALTO service to decide whether to support it.</t>
<t>Both formats can reuse the PID concept that is used in ALTO
to abstract topology details, as explained in <xref
target="I-D.ietf-alto-protocol"/> and <xref
target="I-D.ietf-alto-deployments"/>.</t>
</section>
</section>
<section title="Topology Encoding Formats for ALTO">
<t>This section defines an OPTIONAL extension of ALTO for
topology encoding in JSON format <xref target="RFC4627"/>. An
ALTO service announces the support of these formats in the
Information Resource Directory (IRD) <xref
target="I-D.ietf-alto-protocol"/>.</t>
<t>TODO: Currently, the formats are illustrated by examples
only. The full formal specification is TBD.</t>
<section title="Map Service Extension">
<t>The graph encoding uses the existing PID concept and ALTO
map service <xref
target="I-D.ietf-alto-protocol"/>. Basically, both in the
path-vector and in the node-edge encoding, a PID is generalized
as a node in the topology. If an ALTO server server uses
either format, it MAY return PIDs without an IPv4 or IPv6
address mapping.</t>
<t>For instance, consider the following network topology. For
the sake of simplicity, "H1", "H2", ... as well as "R1", "R2",
... are also used as PID names in the following examples.</t>
<t><figure><artwork><![CDATA[
10.0.1.1/24 10.0.3.1/24
+----+ +----+ +----+
| H1 |----. .----| R3 |------| H3 |
+----+ \+----+ +----+/ +----+ +----+
| R1 |======| R2 |
+----+ /+----+ +----+\ +----+ +----+
| H2 |----' '----| R4 |------| H4 |
+----+ +----+ +----+
10.0.2.1/24 10.0.4.1/24
]]></artwork></figure></t>
<t>R1, R2, ... are transit nodes in the topology. The
objective of topology encoding formats is to represent their
relations. Yet, the addresses of those routers (e.g.,
interface or system IP addresses) may not matter to
applications. Therefore, PIDs representing those nodes may not
have a valid IP address mapping. In ALTO, it is up to an ALTO
server to define what a PID represents. A PID can both refer
to a single node (such as a router), a subnet, a whole
network, etc.</t>
<t>A corresponding ALTO network map query according to <xref
target="I-D.ietf-alto-protocol"/> would be:</t>
<t><figure><artwork><![CDATA[
GET /networkmap HTTP/1.1
Host: alto.example.com
Accept: application/alto-networkmap+json,
application/alto-error+json
]]></artwork></figure></t>
<t>For the given example, this would return:</t>
<t><figure><artwork><![CDATA[
HTTP/1.1 200 OK
Content-Length: TBD
Content-Type: application/alto-networkmap+json
{
"meta": {
...
},
"network-map": {
"H1": { "ipv4": [ "10.0.1.0/24" ] },
"H2": { "ipv4": [ "10.0.2.0/24" ] },
"H3": { "ipv4": [ "10.0.3.0/24" ] },
"H4": { "ipv4": [ "10.0.4.0/24" ] },
"R1": { }, "R2": { }, "R3": { }, "R4": { },
"Default": {
"ipv4": [ "0.0.0.0/0" ], "ipv6": [ "::/0" ]
}
}
}
]]></artwork></figure></t>
<t>R1, R2, R3, and R4 are transient PIDs on the path between
endsystems. If their IP addresses do not matter, they
can be omitted. If an identification of such nodes was
required, one could introduce other identifiers. This
is left for further study.</t>
</section>
<section title="Path-Vector Format">
<t>This extension uses a new media type
"application/alto-pathvector+json". An ALTO service MAY use
the path-vector format as optional extension. In the
path-vector format, an ALTO cost map consists of an ordered
sequence of PIDs. Using the same query mechanisms like the
base ALTO protocol <xref target="I-D.ietf-alto-protocol"/>, an
ALTO query for path-vector information would be:</t>
<t><figure><artwork><![CDATA[
GET /costmap/pathvector HTTP/1.1
Host: alto.example.com
Accept: application/alto-pathvector+json,
application/alto-error+json
]]></artwork></figure></t>
<t>The corresponding response of an ALTO server would be:</t>
<t><figure><artwork><![CDATA[
HTTP/1.1 200 OK
Content-Length: TBA
Content-Type: application/alto-pathvector+json
{
"meta": {
...
"cost-type": {"cost-mode": "pathvector"}
},
"cost-map" : {
"H1": {
"H2": [ "R1" ],
"H3": [ "R1", "R2", "R3" ]
"H4": [ "R1", "R2", "R4" ]
},
"H2": { ... },
"H3": { ... },
"H4": { ... },
"Default": { ... }
}
}
]]></artwork></figure></t>
<t>In the most simple form, a path vector consists of an
ordered sequence of PIDs from a source to a destination. It is
also possible to extend the path vector format by integrating
cost metrics in the vector. A corresponding format is left for
further study in this document.</t>
<t>In general, the cost values between any PIDs can always be
determined using the standard cost map of ALTO <xref
target="I-D.ietf-alto-protocol"/>. As an example, the
following query is also possible for the path-vector cost
mode:</t>
<t><figure><artwork><![CDATA[
GET /costmap/num/routingcost HTTP/1.1
Host: alto.example.com
Accept: application/alto-costmap+json,
application/alto-error+json
]]></artwork></figure></t>
<t>A corresponding response of an ALTO server could be,
fully using the syntax and semantics of <xref
target="I-D.ietf-alto-protocol"/>:</t>
<t><figure><artwork><![CDATA[
HTTP/1.1 200 OK
Content-Length: TBD
Content-Type: application/alto-costmap+json
{
"meta" : {
...
"cost-type": {"cost-mode": "numerical",
"cost-metric": "routingcost"
}
},
"cost-map": {
"H1": { "R1": 1 },
"H2": { "R1": 5 },
"R1": { "H1": 1, "H2": 5, "R2": 9 },
"R2": { "R1": 9, "R3": 4, "R4": 7 },
...
}
}
]]></artwork></figure></t>
<t>In addition to the standard metric "routing cost", also
other metrics for ALTO cost maps could be used, such as the
ones described in <xref target="I-D.wu-alto-te-metrics"/>.</t>
</section>
<section title="Node-Edge Format">
<t>As an alternative representation, an ALTO service MAY also
expose map data in a node-edge format. The node-edge format
basically returns a list of edges between the PIDs given by
the network map. The response SHOULD also include a list of the
nodes, which is identical to the ALTO network map. Adding the
list of nodes enables a client to process the full graph with
a single query. This extension uses the new media type
"application/alto-nodeedge+json". In the following a query for
a node-edge map is shown:</t>
<t><figure><artwork><![CDATA[
GET /costmap/nodeedge HTTP/1.1
Host: alto.example.com
Accept: application/alto-nodeedge+json,
application/alto-error+json
]]></artwork></figure></t>
<t>In the given example, the response in node-edge format
would be as follows:</t>
<t><figure><artwork><![CDATA[
HTTP/1.1 200 OK
Content-Length: TBA
Content-Type: application/alto-nodeedge+json
{
"meta": {
...
"cost-type": {"cost-mode": "nodeedge"}
},
"nodes": {
"H1": { "ipv4": [ "10.0.1.0/24" ] },
"H2": { "ipv4": [ "10.0.2.0/24" ] },
"H3": { "ipv4": [ "10.0.3.0/24" ] },
"H4": { "ipv4": [ "10.0.4.0/24" ] },
"R1": { }, "R2": { }, "R3": { }, "R4": { },
"Default": {
"ipv4": [ "0.0.0.0/0" ], "ipv6": [ "::/0" ]
}
}
"edges": [
"E1": { "src": "H1", "dst": "R1",
"type": "directed",
"cost": [ { "cost-metric": "delay",
"value": "3"
}, {
"cost-metric": "availbw",
"value": "50"
}, {
"cost-metric" : "risk-group",
"value" : ["SLRG3"]
} ]
},
"E2": { "src": "R1", "dst": "R2",
"type": "directed",
"cost": [ { "cost-metric": "delay",
"value": "3"
}, {
"cost-metric": "availbw",
"value": "50"
} ]
},
...
}
}
]]></artwork></figure></t>
<t>The node-edge format re-uses the PID as identifiers for
nodes. It requires a new set of identifiers for the
edges. For those identifies, the same syntax constraints like
for PIDs are used. Within one response, each edge must be
uniquely identified by an edge identifier.</t>
<t>Edges can be characterized by the same attributes like ALTO
cost maps, including one or more cost metrics. For instance,
the cost metrics defined in <xref
target="I-D.wu-alto-te-metrics"/> can be used for edges.
The specification of further edge properties is for further
study.</t>
</section>
</section>
<section title="IANA Considerations">
<t>TBD</t>
</section>
<section title="Security Considerations">
<t>TBD</t>
</section>
<section title="Conclusion">
<t>TBD</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
<?rfc include="reference.RFC.4627"?>
<?rfc include="reference.I-D.ietf-alto-protocol"?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.6824"?>
<?rfc include="reference.I-D.yang-alto-topology"?>
<?rfc include="reference.I-D.bernstein-alto-topo"?>
<?rfc include="reference.I-D.clemm-i2rs-yang-network-topo"?>
<?rfc include="reference.I-D.ietf-alto-deployments"?>
<?rfc include="reference.I-D.wu-alto-te-metrics"?>
<?rfc include="reference.I-D.bernstein-alto-large-bandwidth-cases"?>
<?rfc include="reference.I-D.lee-alto-app-net-info-exchange"?>
</references>
<section title="Contributors">
<t>This document is an outcome of very valuable discussions with
Y. Richard Yang, Young Lee, and Greg M. Bernstein during IETF
89.</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 05:46:14 |