Internet DRAFT - draft-scharf-alto-topology
draft-scharf-alto-topology
ALTO WG M. Scharf
Internet-Draft Alcatel-Lucent Bell Labs
Intended status: Standards Track July 2, 2014
Expires: January 3, 2015
Path-Vector and Node-Edge Topology Maps in ALTO
draft-scharf-alto-topology-00
Abstract
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.
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 3, 2015.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Scharf Expires January 3, 2015 [Page 1]
Internet-Draft Topology Maps in ALTO July 2014
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Endpoint-Centric Network Topology Models . . . . . . . . . . 3
3.1. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 3
3.2. Topology Models . . . . . . . . . . . . . . . . . . . . . 4
4. Topology Encoding Formats for ALTO . . . . . . . . . . . . . 5
4.1. Map Service Extension . . . . . . . . . . . . . . . . . . 5
4.2. Path-Vector Format . . . . . . . . . . . . . . . . . . . 6
4.3. Node-Edge Format . . . . . . . . . . . . . . . . . . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Normative References . . . . . . . . . . . . . . . . . . 10
8.2. Informative References . . . . . . . . . . . . . . . . . 10
Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction
The Application-Layer Traffic Optimization (ALTO) service
[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.
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.
Topology models for ALTO are also discussed in other related
documents. A full solution to extend ALTO is defined in
[I-D.yang-alto-topology]. An earlier survey of use-cases for
extended network topology information can also be found in
[I-D.bernstein-alto-topo]. Further related work has been published
in [I-D.lee-alto-app-net-info-exchange] and
[I-D.bernstein-alto-large-bandwidth-cases].
Scharf Expires January 3, 2015 [Page 2]
Internet-Draft Topology Maps in ALTO July 2014
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.
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 [I-D.clemm-i2rs-yang-network-topo].
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
3. Endpoint-Centric Network Topology Models
3.1. Use Cases
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
[I-D.ietf-alto-deployments] and [I-D.wu-alto-te-metrics].
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 [I-D.ietf-alto-protocol]. These
uses cases are typically characterized by multiple application
source-destination pairs:
o Shared bottleneck detection: As explained for instance in
[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
Scharf Expires January 3, 2015 [Page 3]
Internet-Draft Topology Maps in ALTO July 2014
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).
o 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.
o 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 [RFC6824].
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
[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.
3.2. Topology Models
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.
There are two different graph representation formats that could be
used to generalize the existing ALTO network and cost maps and reveal
path coupling:
o 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.
Scharf Expires January 3, 2015 [Page 4]
Internet-Draft Topology Maps in ALTO July 2014
o 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.
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.
Both formats can reuse the PID concept that is used in ALTO to
abstract topology details, as explained in [I-D.ietf-alto-protocol]
and [I-D.ietf-alto-deployments].
4. Topology Encoding Formats for ALTO
This section defines an OPTIONAL extension of ALTO for topology
encoding in JSON format [RFC4627]. An ALTO service announces the
support of these formats in the Information Resource Directory (IRD)
[I-D.ietf-alto-protocol].
TODO: Currently, the formats are illustrated by examples only. The
full formal specification is TBD.
4.1. Map Service Extension
The graph encoding uses the existing PID concept and ALTO map service
[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.
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.
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
R1, R2, ... are transit nodes in the topology. The objective of
topology encoding formats is to represent their relations. Yet, the
Scharf Expires January 3, 2015 [Page 5]
Internet-Draft Topology Maps in ALTO July 2014
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.
A corresponding ALTO network map query according to
[I-D.ietf-alto-protocol] would be:
GET /networkmap HTTP/1.1
Host: alto.example.com
Accept: application/alto-networkmap+json,
application/alto-error+json
For the given example, this would return:
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" ]
}
}
}
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.
4.2. Path-Vector Format
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
Scharf Expires January 3, 2015 [Page 6]
Internet-Draft Topology Maps in ALTO July 2014
mechanisms like the base ALTO protocol [I-D.ietf-alto-protocol], an
ALTO query for path-vector information would be:
GET /costmap/pathvector HTTP/1.1
Host: alto.example.com
Accept: application/alto-pathvector+json,
application/alto-error+json
The corresponding response of an ALTO server would be:
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": { ... }
}
}
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.
In general, the cost values between any PIDs can always be determined
using the standard cost map of ALTO [I-D.ietf-alto-protocol]. As an
example, the following query is also possible for the path-vector
cost mode:
GET /costmap/num/routingcost HTTP/1.1
Host: alto.example.com
Accept: application/alto-costmap+json,
application/alto-error+json
Scharf Expires January 3, 2015 [Page 7]
Internet-Draft Topology Maps in ALTO July 2014
A corresponding response of an ALTO server could be, fully using the
syntax and semantics of [I-D.ietf-alto-protocol]:
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 },
...
}
}
In addition to the standard metric "routing cost", also other metrics
for ALTO cost maps could be used, such as the ones described in
[I-D.wu-alto-te-metrics].
4.3. Node-Edge Format
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:
GET /costmap/nodeedge HTTP/1.1
Host: alto.example.com
Accept: application/alto-nodeedge+json,
application/alto-error+json
In the given example, the response in node-edge format would be as
follows:
Scharf Expires January 3, 2015 [Page 8]
Internet-Draft Topology Maps in ALTO July 2014
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"
} ]
},
...
}
}
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.
Scharf Expires January 3, 2015 [Page 9]
Internet-Draft Topology Maps in ALTO July 2014
Within one response, each edge must be uniquely identified by an edge
identifier.
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 [I-D.wu-alto-te-metrics] can be used for edges.
The specification of further edge properties is for further study.
5. IANA Considerations
TBD
6. Security Considerations
TBD
7. Conclusion
TBD
8. References
8.1. Normative References
[I-D.ietf-alto-protocol]
Alimi, R., Penno, R., and Y. Yang, "ALTO Protocol", draft-
ietf-alto-protocol-27 (work in progress), March 2014.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4627] Crockford, D., "The application/json Media Type for
JavaScript Object Notation (JSON)", RFC 4627, July 2006.
8.2. Informative References
[I-D.bernstein-alto-large-bandwidth-cases]
Bernstein, G. and Y. Lee, "Use Cases for High Bandwidth
Query and Control of Core Networks", draft-bernstein-alto-
large-bandwidth-cases-02 (work in progress), July 2012.
[I-D.bernstein-alto-topo]
Bernstein, G., Yang, Y., and Y. Lee, "ALTO Topology
Service: Uses Cases, Requirements, and Framework", draft-
bernstein-alto-topo-00 (work in progress), October 2013.
Scharf Expires January 3, 2015 [Page 10]
Internet-Draft Topology Maps in ALTO July 2014
[I-D.clemm-i2rs-yang-network-topo]
Clemm, A., Ananthakrishnan, H., Medved, J., Tkacik, T.,
Varga, R., and N. Bahadur, "A YANG Data Model for Network
Topologies", draft-clemm-i2rs-yang-network-topo-00 (work
in progress), February 2014.
[I-D.ietf-alto-deployments]
Stiemerling, M., Kiesel, S., Previdi, S., and M. Scharf,
"ALTO Deployment Considerations", draft-ietf-alto-
deployments-09 (work in progress), February 2014.
[I-D.lee-alto-app-net-info-exchange]
Lee, Y., Dhody, D., Wu, Q., Bernstein, G., and T. Choi,
"ALTO Extensions to Support Application and Network
Resource Information Exchange for High Bandwidth
Applications in TE networks", draft-lee-alto-app-net-info-
exchange-04 (work in progress), October 2013.
[I-D.wu-alto-te-metrics]
Wu, W., Yang, Y., Lee, Y., Dhody, D., and S. Randriamasy,
"ALTO Traffic Engineering Cost Metrics", draft-wu-alto-te-
metrics-03 (work in progress), June 2014.
[I-D.yang-alto-topology]
Bernstein, G., Lee, Y., Roome, B., Scharf, M., and Y.
Yang, "ALTO Topology Extensions", draft-yang-alto-
topology-03 (work in progress), July 2014.
[RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure,
"TCP Extensions for Multipath Operation with Multiple
Addresses", RFC 6824, January 2013.
Appendix A. Contributors
This document is an outcome of very valuable discussions with Y.
Richard Yang, Young Lee, and Greg M. Bernstein during IETF 89.
Author's Address
Michael Scharf
Alcatel-Lucent Bell Labs
Lorenzstrasse 10
Stuttgart 70435
Germany
Email: michael.scharf@alcatel-lucent.com
Scharf Expires January 3, 2015 [Page 11]
