ALTO Extension: Flow-based Cost Query
draft-gao-alto-fcs-02
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Kai Gao , Jingxuan Zhang , Junzhuo Austin Wang , Qiao Xiang , Y. Richard Yang | ||
| Last updated | 2017-06-26 | ||
| RFC stream | (None) | ||
| Formats | |||
| Additional resources | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-gao-alto-fcs-02
ALTO WG K. Gao
Internet-Draft Tsinghua University
Intended status: Standards Track J. Zhang
Expires: December 27, 2017 J. Wang
Tongji University
Q. Xiang
Tongji/Yale University
Y. Yang
Yale University
June 25, 2017
ALTO Extension: Flow-based Cost Query
draft-gao-alto-fcs-02.txt
Abstract
The emergence of new networking datapath capabilities has
substantially increased the flexibility of networking. For example,
OpenFlow has emerged as a major southbound protocol for Software-
Defined Networking, and OpenFlow allows flexible routing beyond
simple destination-based routing. In this document, we define a new
extention to ALTO, namely the Flow Cost Service, for ALTO clients in
an OpenFlow-enabled network to query ALTO network information.
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 December 27, 2017.
Gao, et al. Expires December 27, 2017 [Page 1]
Internet-Draft Flow Cost Service June 2017
Copyright Notice
Copyright (c) 2017 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 . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Changes Since Version -01 . . . . . . . . . . . . . . . . . . 4
3. ALTO Flow Cost Specification: Basic Flow-based Query . . . . 4
3.1. Flow-based Filtered Cost Map . . . . . . . . . . . . . . 4
3.1.1. Capabilities . . . . . . . . . . . . . . . . . . . . 4
3.1.2. Accept Input Parameters . . . . . . . . . . . . . . . 5
3.1.3. Response . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Extend Endpoint Encoding . . . . . . . . . . . . . . . . 6
3.2.1. Protocol . . . . . . . . . . . . . . . . . . . . . . 6
3.2.2. EndpointName . . . . . . . . . . . . . . . . . . . . 6
3.2.3. Port . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2.4. EndpointURI Example . . . . . . . . . . . . . . . . . 7
3.3. Flow-based Endpoint Cost Service . . . . . . . . . . . . 7
3.3.1. Capabilities . . . . . . . . . . . . . . . . . . . . 7
3.3.2. Accept Input Parameters . . . . . . . . . . . . . . . 8
3.3.3. Response . . . . . . . . . . . . . . . . . . . . . . 8
3.4. Example . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.4.1. IRD Example . . . . . . . . . . . . . . . . . . . . . 9
3.4.2. Flow-based Filtered Cost Map Service Example . . . . 10
3.4.3. Flow-based Endpoint Cost Service Example . . . . . . 11
4. ALTO Flow Cost Specification: Advanced Flow-based Query . . . 12
4.1. Basic Data Types . . . . . . . . . . . . . . . . . . . . 12
4.1.1. Flow ID . . . . . . . . . . . . . . . . . . . . . . . 12
4.1.2. Typed Header Field . . . . . . . . . . . . . . . . . 12
4.1.3. Cost Confidence . . . . . . . . . . . . . . . . . . . 12
4.2. Flow Cost Service . . . . . . . . . . . . . . . . . . . . 13
4.2.1. Media Type . . . . . . . . . . . . . . . . . . . . . 13
4.2.2. HTTP Method . . . . . . . . . . . . . . . . . . . . . 13
4.2.3. Accept Input Parameters . . . . . . . . . . . . . . . 13
4.2.4. Capabilities . . . . . . . . . . . . . . . . . . . . 14
4.2.5. Response . . . . . . . . . . . . . . . . . . . . . . 15
Gao, et al. Expires December 27, 2017 [Page 2]
Internet-Draft Flow Cost Service June 2017
4.2.6. Errors . . . . . . . . . . . . . . . . . . . . . . . 16
4.3. Advanced Flow-based Query Example . . . . . . . . . . . . 17
5. Security Considerations . . . . . . . . . . . . . . . . . . . 19
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
6.1. Media Types . . . . . . . . . . . . . . . . . . . . . . . 19
6.2. Header Field . . . . . . . . . . . . . . . . . . . . . . 20
7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 20
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
8.1. Normative References . . . . . . . . . . . . . . . . . . 21
8.2. Informative References . . . . . . . . . . . . . . . . . 21
Appendix A. Tables . . . . . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction
ALTO is now being considered as a solution for more flexible network
scenario. The legacy ALTO services defined in [RFC7285] only provide
the cost information for peer selection. It is enough for the P2P
application. However, the network is becoming more and more flexible
nowadays. There are two major changes in the coming network
evolution:
o Some new network architectures, such as Software Defined
Networking (SDN), are adopting the logically central control
solution, which makes the network optimization toward the higher-
level view. The traffic optimizer can not only decide the source
or the destination of the data transferring, but also make the
flow-level traffic scheduling. To solve the flow-level scheduling
problem, the cross-product query schema will be redundant.
o With the emerging technologies in the data plane, where multiple
header fields can be used to determine the forwarding path,
networks are moving to more flexible routing mechanisms beyond the
simple destination-based routing. As a consequence, the endpoint
cost service (ECS), which depends on only source and destination
IP addresses as currently defined, is no longer sufficient to
provide accurate cost information.
This document addresses the following issues in providing fine-
grained flow-based endpoint cost query services: 1) The compatibility
with the legacy ALTO ECS service; 2) The support for emerging network
architectures such as Software Defined Networking; 3) The trade-off
between fine-grained queries and query/response redundancy.
In this document, we consider the extensions of ALTO service which
provide the flow-based cost query. The basic solution is to extend
the legacy ALTO services to support flow-based query schema.
Section 3 describes the extended schema on Filtered Cost Map (FCM)
Gao, et al. Expires December 27, 2017 [Page 3]
Internet-Draft Flow Cost Service June 2017
and Endpoint Cost Service (ECS) to support endpoint cost queries of
flows defined by the 5-tuple of protocol, src/dst name/address and
ports. For networks using a more generic flow concept such as
Software-Defined Networks, Section 4 defines a novel ALTO service
named the Flow Cost Service (FCS) with the flow-oriented query
schema. It SHOULD support the query of any fine-grained routing cost
to satisfy the growing demand of obtaining accurate costs in a
network using flow-based routing. Section 5 and Section 6 discuss
security and IANA considerations.
2. Changes Since Version -01
Note to Editor: Please remove this section prior to publication.
This section records the change log of the draft updates.
o Change the schema of "pid-flows" and "endpoint-flows" fields from
pair list to pair mesh list.
Changes since older versions:
o Define the basic flow-based query extensions for Filtered Cost Map
and Endpoint Cost service. The basic flow-based query is downward
compatible with the legacy ALTO service. It does not introduce
any new media types.
o Move the service of media-type "application/alto-flowcost+json" to
the advanced flow-based query extension. It will ask ALTO server
to support the new media type.
3. ALTO Flow Cost Specification: Basic Flow-based Query
This section describes a downward compatible extension for Filtered
Cost Map and Endpoint Cost Service to support flow-based query.
3.1. Flow-based Filtered Cost Map
3.1.1. Capabilities
The Filtered Cost Map capabilities are extended with a new member:
flow-based-filter.
The capability "flow-based-filter" indicates whether this resource
supports flow-based query. The FilteredCostMapCapabilities object in
Section 4.1.1 of [I-D.ietf-alto-multi-cost] is extended as follows:
Gao, et al. Expires December 27, 2017 [Page 4]
Internet-Draft Flow Cost Service June 2017
object {
JSONString cost-type-names<1..*>;
[JSONBool cost-constraints;]
[JSONNumber max-cost-types;]
[JSONString testable-cost-type-names<1..*>;]
[JSONBool flow-based-filter;]
} FilteredCostMapCapabilities;
cost-type-names and cost-constraints: As defined in Section 11.3.2.4
of [RFC7285].
max-cost-types and testable-cost-type-names: As defined in
Section 4.1.1 of [I-D.ietf-alto-multi-cost].
flow-based-filter: If true, then the ALTO Server allows pid-flows to
be queried in the requests. If not present, this field MUST be
interpreted as if it is specified false.
3.1.2. Accept Input Parameters
The ReqFilteredCostMap object in Section 4.1.2 of
[I-D.ietf-alto-multi-cost] is extended as follows:
object {
[CostType cost-type;]
[CostType multi-cost-types<1..*>;]
[CostType testable-cost-types<1..*>;]
[JSONString constraints<0..*>;]
[JSONString or-constraints<0..*><0..*>;]
[PIDFilter pids;]
[PIDFilter pid-flows<1..*>;]
} ReqFilteredCostMap;
cost-type, multi-cost-types, testable-cost-types, constraints, or-
constraints: As defined in Section 4.1.2 of
[I-D.ietf-alto-multi-cost].
pids: As defined in Section 11.3.2.3 of [RFC7285].
pid-flows: Defined as a list of PIDFilter objects in which each
object is as defined in Section 11.3.2.3 of [RFC7285]. The ALTO
server MUST interpret PID pairs appearing in all objects multiple
times as if they appeared only once. If the "pids" field is
present, the "pid-flows" field MUST NOT be specified.
Gao, et al. Expires December 27, 2017 [Page 5]
Internet-Draft Flow Cost Service June 2017
3.1.3. Response
The response is exactly as defined in Section 4.1.3 of
[I-D.ietf-alto-multi-cost].
3.2. Extend Endpoint Encoding
The legacy endpoint encoding is TypedEndpointAddr, which is defined
in Section 10.4 of [RFC7285]. This encoding only defines two address
types: ipv4 and ipv6 to express IPv4 addresses and IPv6 addresses
respectively. However, the flow-extended ECS may contain MAC
addresses, domain names and port numbers to give a cost between
hosts.
Therefore, this document extends the endpoint encoding from
TypedEndpointAddr to EndpointURI to measure the cost more precisely.
The syntax of EndpointURI SHOULD be compatible with the definition of
URI in [RFC3986]. The string encoded as type EndpointURI MUST be one
of the following format:
Protocol:EndpointName
Protocol:EndpointName:Port
This definition is downward compatible with the definition of
TypedEndpointAddr . When the Protocol field only supports "ipv4" and
"ipv6", EndpointURI is equivalent to TypedEndpointAddr.
3.2.1. Protocol
The Protocol field is REQUIRED. The available values contain
different protocols including layer two protocols (e.g. "eth") and
layer three protocols (e.g. "ipv4", "ipv6"). It can also be
specified upper-layer protocols (e.g. "udp", "tcp", "ssh", "http" and
"ftp"). The source and destination protocols MUST NOT be conflict.
In every EndpointFilter object of either "endpoints" field or
"endpoint-flows" field, if the source protocol is conflict with the
destination protocol, this endpoint pair is invalid. For different
protocols, some additional constraints are defined in Section 3.2.3.
3.2.2. EndpointName
The EndpointName field is REQUIRED. The value can be a MAC address,
an IP address or a host/domain name. If the IP address type is
"ipv6" and the Port field is specified, the address MUST be enclosed
in "[" and "]" characters, as recommended in [RFC2732].
Gao, et al. Expires December 27, 2017 [Page 6]
Internet-Draft Flow Cost Service June 2017
3.2.3. Port
The Port field is OPTIONAL. It is introduced for more fine-gained
requests when the protocol is upper-layer. It MUST be forbidden when
the Protocol field is specified layer three (like "ipv4" and "ipv6")
or layer two protocol (like "eth"). For some classic application-
layer protocols, if the port is not specified, the ALTO server will
use the default port. For example, the default port of "ssh" is 22,
"ftp" is 21 and "http" is 80.
3.2.4. EndpointURI Example
Some valid EndpointURI values look like follows:
"eth:98:e0:d9:9c:df:81"
"http:www.example.com"
"ipv4:198.51.100.34"
"telnet:198.51.100.34:23"
"tcp:[2000::1:2345:6789:abcd]:8080"
3.3. Flow-based Endpoint Cost Service
3.3.1. Capabilities
The extensions of EndpointCostCapabilities are based on
FilteredCostMapCapabilities in Section 3.1.1 but with a new member:
protocols.
The capability "protocols" indicates which protocols are supported to
be queried by this resource. For the capability "flow-based-filter",
the true value means the ALTO server allows requests to have
"endpoint-flows" field. If not present, this field MUST be
interpreted as if it is specified false.
object {
[JSONString protocols<0..*>;]
[JSONBool flow-based-filter;]
} EndpointCostCapabilities : FilteredCostMapCapabilities;
protocols: Defines a list of JSONString indicating the supported
Protocol values of the EndpointURI in the request. The ALTO
server does not have to claim "ipv4" and "ipv6" in this field
explictly, because they are supported by default. If not present,
this field MUST be interpreted as if it is specified the default
supported protocols "ipv4" and "ipv6".
Gao, et al. Expires December 27, 2017 [Page 7]
Internet-Draft Flow Cost Service June 2017
flow-based-filter: If true, then the ALTO Server allows endpoint-
flows to be queried in the requests. If not present, this field
MUST be interpreted as if it is specified false.
3.3.2. Accept Input Parameters
The ReqEndpointCostMap object in Section 4.2.2 of
[I-D.ietf-alto-multi-cost] is extended as follows:
object {
[CostType cost-type;]
[CostType multi-cost-types<1..*>;]
[CostType testable-cost-types<1..*>;]
[JSONString constraints<0..*>;]
[JSONString or-constraints<0..*><0..*>;]
[EndpointFilter endpoints;]
[EndpointFilter endpoint-flows<1..*>;]
} ReqEndpointCostMap;
object {
EndpointURI srcs<0..*>;
EndpointURI dsts<0..*>;
} EndpointFilter;
cost-type, multi-cost-types, testable-cost-types, constraints, or-
constraints:
As defined in Section 4.1.2 of [I-D.ietf-alto-multi-cost].
endpoints: As defined in Section 11.5.1.3 of [RFC7285].
endpoint-flows: Defined as a list of EndpointFilter objects in which
each object is as defined in Section 11.5.1.3 of [RFC7285]. The
ALTO server MUST interpret endpoint pairs appearing multiple times
in all EndpointFilter objects as if they appeared only once.
The additional requirement is that the ALTO client MUST specify
either "endpoints" or "endpoint-flows", but MUST NOT specify both.
3.3.3. Response
The response is exactly as defined in Section 4.2.3 of
[I-D.ietf-alto-multi-cost].
3.4. Example
Gao, et al. Expires December 27, 2017 [Page 8]
Internet-Draft Flow Cost Service June 2017
3.4.1. IRD Example
GET /directory HTTP/1.1
Host: alto.example.com
Accept: application/alto-directory+json,application/alto-error+json
HTTP/1.1 200 OK
Content-Length: [TODO]
Content-Type: application/alto-directory+json
{
"meta" : {
"default-alto-network-map" : "my-default-network-map",
"cost-types" : {
"num-routingcost" : {
"cost-mode" : "numerial",
"cost-metric" : "routingcost"},
"ord-routingcost" : {
"cost-mode" : "ordinal",
"cost-metric" : "routingcost"}
},
.....
Other ALTO cost types as described in RFC7285
.....
},
"resources" : {
"my-default-network-map" : {
"uri" : "http://alto.example.com/networkmap",
"media-type" : "application/alto-networkmap+json"
},
"basic-flow-based-cost-map" : {
"uri" : "http://alto.example.com/costmap/multi/filtered",
"media-types" : [ "application/alto-costmap+json" ],
"accepts" : [ "application/alto-costmapfilter+json" ],
"uses" : [ "my-default-network-map" ],
"capabilities" : {
"flow-based-filter" : true,
"cost-type-names" : [ "ord-routingcost" , "num-routingcost" ]
}
},
"basic-flow-based-endpoint-cost" : {
"uri" : "http://alto.example.com/endpointcost/lookup",
"media-types" : [ "application/alto-endpointcost+json" ],
"accepts" : [ "application/alto-endpointcostparams+json" ],
"uses" : [ "my-default-network-map" ],
"capabilities" : {
"protocols": ["tcp", "http"],
"flow-based-filter" : true,
"cost-type-names" : [ "ord-routingcost" , "num-routingcost" ]
Gao, et al. Expires December 27, 2017 [Page 9]
Internet-Draft Flow Cost Service June 2017
}
}
}
}
3.4.2. Flow-based Filtered Cost Map Service Example
POST /costmap/multi/filtered HTTP/1.1
Host: alto.example.com
Accept: application/alto-costmap+json,application/alto-error+json
Content-Length: [TBD]
Content-Type: application/alto-costmapfilter+json
{
"cost-type": {
"cost-mode": "numerical",
"cost-metric": "routingcost"
},
"pid-flows": [
{ "srcs": ["PID1"], "dsts": ["PID2", "PID3"] },
{ "srcs": ["PID3"], "dsts": ["PID4"] }
]
}
HTTP/1.1 200 OK
Content-Length: [TBD]
Content-Type: application/alto-costmap+json
{
"meta": {
"dependent-vtags": [
{
"resource-id": "my-default-network-map",
"tag": "75ed013b3cb58f896e839582504f622838ce670f"
},
],
"cost-type": {
"cost-mode": "numerical",
"cost-metric": "routingcost"
}
},
"cost-map": {
"PID1": { "PID2": 100 },
"PID1": { "PID3": 20 },
"PID3": { "PID4": 80 }
}
}
Gao, et al. Expires December 27, 2017 [Page 10]
Internet-Draft Flow Cost Service June 2017
3.4.3. Flow-based Endpoint Cost Service Example
POST /endpointcost/lookup HTTP/1.1
Host: alto.example.com
Accept: application/alto-endpointcost+json,application/alto-error+json
Content-Length: [TBD]
Content-Type: application/alto-endpointcostparams+json
{
"cost-type": {
"cost-mode": "numerical",
"cost-metric": "hopcount"
},
"endpoint-flows": [
{ "srcs": ["ipv4:192.0.2.2"],
"dsts": ["ipv4:192.0.2.89", "http:cdn1.example.com"] },
{ "srcs": ["tcp:203.0.113.45:54321"],
"dsts": ["http:cdn1.example.com"] }
]
}
HTTP/1.1 200 OK
Content-Length: [TBD]
Content-Type: application/alto-endpointcost+json
{
"meta": {
"cost-type": {
"cost-mode": "numerical",
"cost-metric": "hopcount"
}
},
"endpoint-cost-map": {
"ipv4:192.0.2.2": {
"ipv4:192.0.2.89": 3,
"http:cdn1.example.com": 6
},
"tcp:203.0.113.45:54321": {
"http:cdn1.example.com": 10
}
}
}
Gao, et al. Expires December 27, 2017 [Page 11]
Internet-Draft Flow Cost Service June 2017
4. ALTO Flow Cost Specification: Advanced Flow-based Query
The basic flow-based query extends the ECS service to support
querying the cost of flows. However, it only supports the cost query
of flows defined by the 5-tuple of protocol, source/destination
address (hostname, IP address, domain name or MAC address) and ports.
However, in the emerging software-defined networking, the concept of
flow is not confined by this 5-tuple anymore. Instead, [OF15] has
defined 38 header match fields that could define a flow. This
document next introduces an advanced flow-based query to support the
flow-based cost queries for such a generic context of flows.
4.1. Basic Data Types
The flow cost service introduces some new basic data types, as
defined below.
4.1.1. Flow ID
A flow ID has the same format as a PIDName, as defined in
Section 10.1 of [RFC7285]. It is used to uniquely identify a flow in
a flow cost service request.
4.1.2. Typed Header Field
A typed header field represents a particular field in a network
protocol that can be obtained at the application layer. It is
represented by the protocol name and the field name, concatenated by
the colon (':', U+003A). The typed header fields are case
insensitive.
For example, "ipv4:source" and "IPv4:source" both represent the
source address field used in IPv4 and "tcp:destination" represents
the destination port for a TCP connection.
See Table 2 for a list of proposed typed header fields.
4.1.3. Cost Confidence
A cost confidence is defined as a JSON integer within the range of
[0, 100]. It represents the ALTO servers' estimation on the accuracy
of the returned costs. The larger the cost confidence is, the more
accurate the path cost SHOULD be. If the cost value is very
accurate, for example, a unique path can be identified for a flow
with the provided information, the ALTO server SHOULD provide a cost
confidence of 100.
Gao, et al. Expires December 27, 2017 [Page 12]
Internet-Draft Flow Cost Service June 2017
The cost confidence CAN be used as an evidence of ambiguous paths,
which is often associated with insufficient information in a query.
If an ALTO client finds that the associated cost confidence value is
low, it can narrow down the flow header space in the query, e.g., by
adding optional fields or use IP addresses instead of prefixes.
The cost confidence value can be computed in several ways. For
example, an ALTO server MAY use the following formula for some cost
metrics:
c = 100 * (1 - |deviation / mean|)
0 if c <= 0
confidence =
round(c) if c > 0
where mean and deviation are computed from the cost values of all
possible paths.
4.2. Flow Cost Service
A flow cost service provides information about costs for each
individual flow specified in a request.
4.2.1. Media Type
The media type of the flow cost service is "application/alto-
flowcost+json".
4.2.2. HTTP Method
The flow cost service is requested using the HTTP POST method.
4.2.3. Accept Input Parameters
The input parameters of the flow cost service MUST be encoded as a
JSON object of type FlowCostRequest in the body of an HTTP POST
request. The media type of the request MUST be "application/alto-
flowcostparams+json".
object {
FlowFilterMap flows;
} FlowCostRequest : MultiCostRequestBase;
Gao, et al. Expires December 27, 2017 [Page 13]
Internet-Draft Flow Cost Service June 2017
object {
[CostType cost-type;]
[CostType multi-cost-types<1..*>;]
[CostType testable-cost-types<1..*>;]
[JSONString constraints<0..*>;]
[JSONString or-constraints<0..*><0..*>;]
} MultiCostRequestBase;
object-map {
FlowId -> FlowFilter;
} FlowFilterMap;
object-map {
TypedHeaderField -> JSONValue;
} FlowFilter;
flows: A map of flow filters for which path costs are to be
returned. Each flow filter is identified by a unique FlowId, as
defined in Section 4.1.1. The value types of a field is protocol-
specific, see Table 3 for the value types associated with typed
header fields in Table 2.
cost-type: The same as defined in Section 4.2.2 of
[I-D.ietf-alto-multi-cost].
multi-cost-types: The same as defined in Section 4.2.2 of
[I-D.ietf-alto-multi-cost].
testable-cost-types, constraints, or-constraints: The same as
defined in Section 4.2.2 of [I-D.ietf-alto-multi-cost].
4.2.4. Capabilities
The capabilities of the flow cost service is a JSON object of type
FlowCostCapabilities:
object {
TypedHeaderField required<1..*>;
[TypedHeaderField optional<1..*>;]
} FlowCostCapabilities : FilteredCostMapCapabilities;
with fields:
required: A list of required typed header fields. These fields are
essential to find the path cost for a given flow and MUST be
provided in a flow filter.
Gao, et al. Expires December 27, 2017 [Page 14]
Internet-Draft Flow Cost Service June 2017
optional: A list of optional typed header fields. The ALTO server
MAY leverage the values of the optional fields to find more
accurate costs.
4.2.5. Response
The "meta" field of a flow cost response MUST contain the same cost
type information as defined in Section 4.2.3 of
[I-D.ietf-alto-multi-cost].
The data component of a flow cost service is named "flow-cost-map",
which is a JSON object of type FlowCostMap:
object {
FlowCostMap flow-cost-map;
[FlowCostMap flow-cost-confidences;]
} FlowCostResponse : ResponseEntityBase;
object-map {
FlowId -> JSONValue;
} FlowCostMap;
flow-cost-map: A dictionary map with each key (flow ID) representing
a flow specified in the request. For each flow, the cost MUST
follow the format defined in Section 4.2.3 of
[I-D.ietf-alto-multi-cost].
flow-cost-confidences: A dictionary map with each key (flow ID)
representing a flow specified in the request. For a single cost,
the cost confidence for each flow MUST follow the specification in
Section 4.1.3. If the query is using multiple costs where the
costs are returned as a JSONArray, the cost confidence MUST also
be a JSONArray where each element represents the cost confidence
value computed for the corresponding cost type.
4.2.5.1. Ambiguous Paths
Since new forwarding abstractions support fine-grained routing, for
example, OpenFlow 1.5 [OF15] has defined 38 header match fields, it
is possible that the ALTO server cannot determine the path using the
provided header fields. The computation for costs with ambiguous
paths is implementation-specific, the servers can choose to return an
integrated result of all possible paths, or simply use the cost of a
random path. The ALTO servers SHOULD provide cost confidences to
justify the accuracy of the provided cost values.
Gao, et al. Expires December 27, 2017 [Page 15]
Internet-Draft Flow Cost Service June 2017
The ALTO server SHOULD be able to determine a unique path when all
the optional typed header fields are provided without masks for a
flow, however, the client SHOULD NOT assume this always holds.
4.2.6. Errors
The ALTO servers can provide more information to the clients when
requests have errors. The FlowCostErrorMap below can provide basic
information about two most common errors for the flow cost service.
The ALTO servers MAY include it as the data component of an ALTO
error response. If multiple errors are identified, the ALTO server
MUST return exactly one error code according to Section 8.5.2 of
[RFC7285] .
object-map {
FlowId -> FlowCostError;
} FlowCostErrorMap;
object {
[TypedHeaderField conflicts<2..*>;]
[TypedHeadreField missing<2..*>;]
[TypedHeaderField unsupported<1..*>;]
} FlowFilterError;
conflicts: A list of conflicting typed header fields. See
Section 4.2.6.1 for details.
missing: A list of missing typed header fields. See Section 4.2.6.2
for details.
unsupported: A list of unsupported typed header fields. See
Section 4.2.6.3 for details.
4.2.6.1. Conflicts
Some header fields may have conflicts. For example, IPv4 fields and
IPv6 fields can never appear in the same packet, nor can TCP and UDP
ports. These header fields MUST not be included in the same flow
filter, otherwise the ALTO server MUST return an ALTO error response,
with the error code "E_INVALID_FIELD_VALUE". As specified in
Section 8.5.2 of [RFC7285], the ALTO server MAY include the "field"
and the "value" in the "meta" field. In this case, the ALTO server
MUST use the flow ID as the "field" and the flow filter as the
"value". However, the recommended approach is to use the
FlowCostErrorMap, where the server CAN provide the conflicting typed
header fields in the "conflicts" field of the FlowFilterError
associated with the corresponding flow ID.
Gao, et al. Expires December 27, 2017 [Page 16]
Internet-Draft Flow Cost Service June 2017
4.2.6.2. Missing Fields
The "E_MISSING_FIELD" error code is originally designed to report the
absence of required JSON fields. In the flow cost service, the
required typed header fields are implementation-specific and the ALTO
servers MUST declare the required fields in the capabilities. If any
required header field is missing, the ALTO server MUST return an ALTO
error response, with the error code "E_MISSING_FIELD". The ALTO
server CAN follow the steps defined in Section 8.5.2 of [RFC7285] to
indicate the location of the missing field. An alternative approach
which is also recommended, is that the server provide the missing
typed header fields in the "missing" field of the FlowFilterError
associated with the corresponding flow ID.
4.2.6.3. Unsupported Fields
If a query contains unsupported typed header fields, e.g., those not
in the "required" nor the "optional" capabilities, the ALTO server
MUST return an ALTO error response, with the error code
"E_INVALID_FIELD_VALUE". Like how the conflicting header fields are
handled in Section 4.2.6.1, the ALTO servers CAN report unsupported
typed header fields in the "unsupported" field associated with the
corresponding flow ID.
4.3. Advanced Flow-based Query Example
Gao, et al. Expires December 27, 2017 [Page 17]
Internet-Draft Flow Cost Service June 2017
POST /flowcost/lookup HTTP/1.1
HOST: alto.example.com
Content-Length: 521
Content-Type: application/alto-flowcostparams+json
Accept: application/alto-flowcost+json,application/alto-error+json
{
"cost-type": {
"cost-mode": "numerical",
"cost-metric": "routingcost"
},
"flows": {
"l3-flow": {
"ipv4:source": "192.168.1.1",
"ipv4:destination": "192.168.1.2"
},
"optional-l2-flow": {
"ethernet:source": "12:34:56:78:00:01",
"ethernet:destination": "12:34:56:78:00:02"
},
"l3-flow-aggr": {
"ipv4:source": "192.168.1.0/24",
"ipv4:destination": "192.168.2.0/24"
}
}
}
Gao, et al. Expires December 27, 2017 [Page 18]
Internet-Draft Flow Cost Service June 2017
HTTP/1.1 200 OK
Content-Length: 312
Content-Type: application/alto-flowcost+json
{
"meta": {
"cost-type": {
"cost-mode": "numerical",
"cost-metric": "routingcost"
},
},
"flow-cost-map": {
"l3-flow": 10,
"l3-flow-aggr": 50
"optional-l3-flow": 5,
},
"flow-cost-confidences": {
"l3-flow": 70,
"l3-flow-aggr": 40,
"optional-l2-flow": 90
}
}
5. Security Considerations
This document has not conducted its security analysis.
6. IANA Considerations
This document defines two new entries to be registered to
application/alto-* media types.
6.1. Media Types
This document registers two media types listed in Table 1.
+--------------+--------------------------+----------------+
| Type | Subtype | Specification |
+--------------+--------------------------+----------------+
| application | alto-flowcost+json | Section 3.1.3 |
| application | alto-flowcostparam+json | Section 3.3.2 |
+--------------+--------------------------+----------------+
Table 1: ALTO FCS Media Types
Type name: application
Gao, et al. Expires December 27, 2017 [Page 19]
Internet-Draft Flow Cost Service June 2017
Subtype name: This document registers two subtypes, as listed in
Table 1.
Required parameters: n/a
Optional parameters: n/a
Encoding considerations: Encoding considerations are identical to
those specified for the "applicatoin/json" media type. See
[RFC7159].
Security considerations: Security considerations are identical to
those specified in Section 15 of [RFC7285] .
Interoperability considerations: n/a
Published specification: This document is the specification for
these media types. See Table 1 for the section documenting each
media type.
Applications that use this media type: ALTO servers and ALTO clients
with the extension to support the flow cost service, either
standalone or embedded within other applications.
Additional information: n/a
Person & email address to contact for further information: See
Authors' Addresses.
Intended usage: COMMON
Restrictions on usage: n/a
Author: See Authors' Addresses.
6.2. Header Field
TBD: Create the "ALTO Header Field Name Registry".
7. Acknowledgement
The authors would like to thank Dawn Chen, Haizhou Du, Sabine
Randriamasy and Wendy Roome for fruitful discussions and feedback on
this document. Shawn Lin provided substantial review feedback and
suggestions to the protocol design.
Gao, et al. Expires December 27, 2017 [Page 20]
Internet-Draft Flow Cost Service June 2017
8. References
8.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>.
[RFC2732] Hinden, R., Carpenter, B., and L. Masinter, "Format for
Literal IPv6 Addresses in URL's", RFC 2732,
DOI 10.17487/RFC2732, December 1999,
<http://www.rfc-editor.org/info/rfc2732>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005,
<http://www.rfc-editor.org/info/rfc3986>.
8.2. Informative References
[I-D.ietf-alto-multi-cost]
Randriamasy, S., Roome, W., and N. Schwan, "Multi-Cost
ALTO", draft-ietf-alto-multi-cost-05 (work in progress),
February 2017.
[I-D.wang-alto-ecs-flows]
Shen, X., Zhang, J., Wang, J., and Q. Xiang, "ALTO
Extension: Endpoint Cost Service for Flows", draft-wang-
alto-ecs-flows-01 (work in progress), April 2016.
[OF15] Foundation, O., "Openflow switch specification v1. 5.0",
2014,
<https://www.opennetworking.org/images/stories/downloads/
sdn-resources/onf-specifications/openflow/openflow-switch-
v1.5.0.noipr.pdf>.
[openflow]
McKeown, N., Anderson, T., Balakrishnan, H., Parulkar, G.,
Peterson, L., Rexford, J., Shenker, S., and J. Turner,
"Openflow: enabling innovation in campus networks", 2008.
[RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March
2014, <http://www.rfc-editor.org/info/rfc7159>.
Gao, et al. Expires December 27, 2017 [Page 21]
Internet-Draft Flow Cost Service June 2017
[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>.
Appendix A. Tables
+------------+--------------+------------------------------+
| Protocol | Field Name | Description |
+------------+--------------+------------------------------+
| Ethernet | source | The source MAC address |
| | destination | The destination MAC address |
| | vlan-id | VLAN-ID from 802.1Q header |
| IPv4 | source | IPv4 source address |
| | destination | IPv4 destination address |
| IPv6 | source | IPv6 source address |
| | destination | IPv6 destination address |
| TCP | source | TCP source port |
| | destination | TCP destination port |
| UDP | source | UDP source port |
| | destination | UDP destination port |
+------------+--------------+------------------------------+
Table 2: Protocols and Field Names.
+-----------------------+-------------------------------------------+
| Typed Header Field | Acceptable Value Type |
+-----------------------+-------------------------------------------+
| ethernet:source | JSONString as MAC address |
| ethernet:destination | |
| ethernet:vlan-id | JSONNumber in the range of [1, 4094] |
| ipv4:source | JSONString as IPv4 address or IPv4 prefix |
| ipv4:destination | |
| ipv6:source | JSONString as IPv6 address or IPv6 prefix |
| ipv6:destination | |
| tcp:source | JSONNumber in the range of [0, 65535] |
| tcp:destination | 0 serves as a wildcard value |
| udp:source | |
| udp:destination | |
+-----------------------+-------------------------------------------+
Table 3: Value Types for Typed Header Fields
Gao, et al. Expires December 27, 2017 [Page 22]
Internet-Draft Flow Cost Service June 2017
Authors' Addresses
Kai Gao
Tsinghua University
30 Shuangqinglu Street
Beijing 100084
China
Email: gaok12@mails.tsinghua.edu.cn
Jingxuan Jensen Zhang
Tongji University
4800 Cao'an Hwy
Shanghai 201804
China
Email: jingxuan.n.zhang@gmail.com
Junzhuo Austin Wang
Tongji University
4800 Cao'an Hwy, Jiading District
Shanghai
China
Email: wangjunzhuo200@gmail.com
Qiao Xiang
Tongji/Yale University
51 Prospect Street
New Haven, CT
USA
Email: qiao.xiang@cs.yale.edu
Y. Richard Yang
Yale University
51 Prospect St
New Haven CT
USA
Email: yry@cs.yale.edu
Gao, et al. Expires December 27, 2017 [Page 23]