Internet DRAFT - draft-yang-alto-general-cost-type
draft-yang-alto-general-cost-type
ALTO WG Y. Yang
Internet-Draft Yale University
Intended status: Standards Track October 19, 2015
Expires: April 21, 2016
ALTO Extension: General Cost Types
draft-yang-alto-general-cost-type-00.txt
Abstract
The Application-Layer Traffic Optimization (ALTO) Service has defined
both the endpoint cost service (ECS) and cost maps to provide
information to applications about network path properties (e.g.,
routingcost) from a set of source network points to a set of
destination network points, where each network point can be a single
endpoint (in ECS) or a PID which represents a set of endpoints (in a
cost map). Considering, conceptually, both ECS and cost map as
returning a matrix, indexed by sources and destinations as row and
column, the current ALTO protocol [RFC7285] allows the elements in
the matrix to be only scalar (i.e., numerical or ordinal). This,
however, is limiting in many use cases. This document discuss
multiple use cases where scalar-elements can be limitations. It then
defines new cost types to allow general cost types, such as vectors
to represent use cases such path vectors.
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 RFC 2119 [RFC2119].
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 April 21, 2016.
Yang Expires April 21, 2016 [Page 1]
Internet-Draft ALTO Extension: Path Vector October 2015
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
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
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Generic Cost Types . . . . . . . . . . . . . . . . . . . . . 4
4. Security Considerations . . . . . . . . . . . . . . . . . . . 5
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
7.1. Normative References . . . . . . . . . . . . . . . . . . 5
7.2. Informative References . . . . . . . . . . . . . . . . . 5
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction
Both ECS and cost maps, the two basic services of ALTO, can be
considered as returning a matrix, indexed by sources and destinations
as row and column, where each element in the matrix represents a path
property (called cost) from a source to a destination. Although
[RFC7285] recognizes the need to allow flexible cost values, and
hence defines each element in the cost matrix as the generic
JSONValue type, for the two defined cost modes, 'numerical' and
'ordinal', the type can be only scalars. This, however, can be
limiting.
There are multiple use cases where the elements are not simple
scalars. In [draft-randriamasy-alto-calendar], each element is an
array representing a cost calendar. In a simple case, each element
of the calendar is a scalar, e.g., src1->dst1: [1, 1.5, 1.1]. In a
general case (e.g., representing statistics such as min, max, and
average), the calendar can be: src1->dst1: [ [0.9, 1.1, 1.0], [1.4,
1.5, 1.6], [1.0, 1.1, 1.2]]. In [draft-randriamasy-alto-multi-cost],
each element is a vector, to define a value for each cost metric; in
Yang Expires April 21, 2016 [Page 2]
Internet-Draft ALTO Extension: Path Vector October 2015
[draft-yang-alto-path-vector], each element is a vector representing
the sequence of network elements traversed in the path.
The goal of this extension is to go beyond the scalar-element
limitation to accommodate the preceding use cases.
The organization of this document is organized as follows. Section 2
specifies generic cost types. Sections 4 and 5 discuss security and
IANA considerations.
2. Background
[RFC7285] already introduces the 'cost-type' meta data to indicate
the type of each element in the cost matrix. The specific definition
of cost-type is:
object {
CostMetric cost-metric;
CostMode cost-mode;
[JSONString description;]
} CostType;
Both cost maps and ECS use cost type to parse map data. The
definition of a cost map is:
object {
CostMapData cost-map;
} InfoResourceCostMap : ResponseEntityBase;
object-map {
PIDName -> DstCosts;
} CostMapData;
object-map {
PIDName -> JSONValue;
} DstCosts;
The definition of an endpoint cost map is:
Yang Expires April 21, 2016 [Page 3]
Internet-Draft ALTO Extension: Path Vector October 2015
object {
EndpointCostMapData endpoint-cost-map;
} InfoResourceEndpointCostMap : ResponseEntityBase;
object-map {
TypedEndpointAddr -> EndpointDstCosts;
} EndpointCostMapData;
object-map {
TypedEndpointAddr -> JSONValue;
} EndpointDstCosts;
For both (network) cost map and endpoint cost service map, one can
think of the JSONValue element as value component (<metric-value>) of
a JSON object {'<cost-metric-name>': <metric-value>}. For example,
suppose the cost-metric is 'routingcost', then each element
(JSONValue) is routingcost-value of the JSON object
{'routingcost':routingcost-value}.
3. Generic Cost Types
Given the preceding generalization, we define generic cost-type
values by using 'cost-mode' to indicate the schema type, 'cost-
metric' as a name for the schema, and 'description' providing a link
or inline text to the schema defined. Each element in the cost map
or endpoint cost service map is just JSON encoding of the JSON value.
Specifically, For 'cost-mode' being 'numerical', the schema is JSON
number; For 'cost-mode' being 'ordinal', the schema is JSON integer.
We define a new 'cost-mode' as 'YANG', and hence we can define the
type of elements in the cost map or endpoint cost service map using
YANG. For example, to define 'pathvector', we define
module alto-cost-metric {
namespace "http://example.com/alto-cost-metrics";
prefix alto;
leaf-list pathvector {
type string;
min-elements "1";
}
}
Native JSON encoding of the YANG model is
Yang Expires April 21, 2016 [Page 4]
Internet-Draft ALTO Extension: Path Vector October 2015
{
"pathvector" : []
}
The specification is that each element in a cost map or an endpoint
cost service map uses the value of the attribute (cost-metric name)
defined.
4. Security Considerations
This document has not conducted its security analysis.
5. IANA Considerations
Final version of this document wil require definitions of new cost-
mode such as yang.
6. Acknowledgments
The author thanks his ALTO collaborators that motivated this design.
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
7.2. Informative References
[I-D.amante-i2rs-topology-use-cases]
Medved, J., Previdi, S., Lopez, V., and S. Amante,
"Topology API Use Cases", draft-amante-i2rs-topology-use-
cases-01 (work in progress), October 2013.
[I-D.clemm-i2rs-yang-network-topo]
Clemm, A., Medved, J., Tkacik, T., Varga, R., Bahadur, N.,
and H. Ananthakrishnan, "A YANG Data Model for Network
Topologies", draft-clemm-i2rs-yang-network-topo-01 (work
in progress), October 2014.
Yang Expires April 21, 2016 [Page 5]
Internet-Draft ALTO Extension: Path Vector October 2015
[I-D.lee-alto-app-net-info-exchange]
Lee, Y., Bernstein, G., Choi, T., and D. Dhody, "ALTO
Extensions to Support Application and Network Resource
Information Exchange for High Bandwidth Applications",
draft-lee-alto-app-net-info-exchange-02 (work in
progress), July 2013.
[I-D.roome-alto-unified-props]
Roome, W., "Extensible Property Maps for the ALTO
Protocol", draft-roome-alto-unified-props-00 (work in
progress), July 2015.
[RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S.,
Previdi, S., Roome, W., Shalunov, S., and R. Woundy,
"Application-Layer Traffic Optimization (ALTO) Protocol",
RFC 7285, DOI 10.17487/RFC7285, September 2014,
<http://www.rfc-editor.org/info/rfc7285>.
Author's Address
Y. Richard Yang
Yale University
51 Prospect St
New Haven CT
USA
Email: yry@cs.yale.edu
Yang Expires April 21, 2016 [Page 6]
