ALTO Extension: Flow-based Cost Query
draft-gao-alto-fcs-03
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-07-03 | ||
| 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-03
ALTO WG K. Gao
Internet-Draft Tsinghua University
Intended status: Standards Track J. Zhang
Expires: January 5, 2018 J. Wang
Tongji University
Q. Xiang
Tongji/Yale University
Y. Yang
Yale University
July 4, 2017
ALTO Extension: Flow-based Cost Query
draft-gao-alto-fcs-03.txt
Abstract
The Endpoint Cost Service maps a source-destination pair into a cost
value, which provides an abstract network view based on a subset of
the 2-dimension address space. Given that the emergence of new
networking datapath capabilities has substantially increased the
routing flexibility, such a query space is not sufficient to uniquely
identify a flow. To address the limitations of the network
information query space provided by the legacy ALTO protocol, this
document takes two approaches: extending the existing ALTO cost query
services with fine-grained semantics, and enabling a new flow-based
query service named Flow Cost Service. These extensions move ALTO to
a more flexible and expressive network information query space.
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
Gao, et al. Expires January 5, 2018 [Page 1]
Internet-Draft Flow Cost Service July 2017
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 5, 2018.
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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview of Approaches . . . . . . . . . . . . . . . . . . . 5
3.1. Backward Compatible Flow-based Filter . . . . . . . . . . 5
3.2. Extended Endpoint Address . . . . . . . . . . . . . . . . 5
3.3. Flow Cost Service for Advanced Query . . . . . . . . . . 5
4. Changes Since Version -01 . . . . . . . . . . . . . . . . . . 6
5. ALTO Flow Cost Specification: Basic Flow-based Query . . . . 6
5.1. Flow-based Filtered Cost Map . . . . . . . . . . . . . . 6
5.1.1. Capabilities . . . . . . . . . . . . . . . . . . . . 6
5.1.2. Accept Input Parameters . . . . . . . . . . . . . . . 7
5.1.3. Response . . . . . . . . . . . . . . . . . . . . . . 8
5.2. Extended Endpoint Address Encoding . . . . . . . . . . . 8
5.2.1. Address Type . . . . . . . . . . . . . . . . . . . . 8
5.2.2. Endpoint Address . . . . . . . . . . . . . . . . . . 8
5.2.3. Extended Endpoint Address Examples . . . . . . . . . 9
5.3. Flow-based Endpoint Cost Service . . . . . . . . . . . . 9
5.3.1. Capabilities . . . . . . . . . . . . . . . . . . . . 9
5.3.2. Accept Input Parameters . . . . . . . . . . . . . . . 10
5.3.3. Response . . . . . . . . . . . . . . . . . . . . . . 11
5.4. Examples . . . . . . . . . . . . . . . . . . . . . . . . 11
5.4.1. IRD Example . . . . . . . . . . . . . . . . . . . . . 11
5.4.2. Flow-based Filtered Cost Map Service Example . . . . 12
5.4.3. Flow-based Endpoint Cost Service Example . . . . . . 13
6. ALTO Flow Cost Specification: Advanced Flow-based Query . . . 14
6.1. Basic Data Types . . . . . . . . . . . . . . . . . . . . 15
Gao, et al. Expires January 5, 2018 [Page 2]
Internet-Draft Flow Cost Service July 2017
6.1.1. Flow ID . . . . . . . . . . . . . . . . . . . . . . . 15
6.1.2. Typed Header Field . . . . . . . . . . . . . . . . . 15
6.1.3. Cost Statistics . . . . . . . . . . . . . . . . . . . 15
6.2. Flow Cost Service . . . . . . . . . . . . . . . . . . . . 16
6.2.1. Media Type . . . . . . . . . . . . . . . . . . . . . 16
6.2.2. HTTP Method . . . . . . . . . . . . . . . . . . . . . 16
6.2.3. Accept Input Parameters . . . . . . . . . . . . . . . 16
6.2.4. Capabilities . . . . . . . . . . . . . . . . . . . . 17
6.2.5. Response . . . . . . . . . . . . . . . . . . . . . . 17
6.2.6. Errors . . . . . . . . . . . . . . . . . . . . . . . 18
6.3. Flow Cost Service Example . . . . . . . . . . . . . . . . 19
7. Security Considerations . . . . . . . . . . . . . . . . . . . 21
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
8.1. ALTO Address Type Registry . . . . . . . . . . . . . . . 21
8.2. Media Types . . . . . . . . . . . . . . . . . . . . . . . 22
8.3. Header Field . . . . . . . . . . . . . . . . . . . . . . 23
9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 23
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
10.1. Normative References . . . . . . . . . . . . . . . . . . 23
10.2. Informative References . . . . . . . . . . . . . . . . . 24
Appendix A. Tables . . . . . . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
1. Introduction
The nature of ALTO Endpoint Cost Service can be regarded as a
function transforming a given subset of a specific query space into
an abstract network view. For the legacy ALTO protocol defined in
[RFC7285], the query space is the 2-dimension address space where
each flow can be uniquely identified using a source-destination pair.
ALTO clients can send a query with source-destination pairs to an
ALTO server and receive a view containing the end-to-end cost for
each pair.
Such a query schema might be sufficient for peer-to-peer (P2P)
applications to determine the preferred peer selection in a
traditional network. However, as networks are becoming more and more
flexible in the coming networking evolution, the limited 2-dimension
address space is no longer sufficient as the query space to end-to-
end connections. To make ALTO more accurate and efficient, the
following additional requirements must be fulfilled:
Req. FAR-1: ALTO servers SHOULD provide a view for a more flexible
flow set query space.
New network architectures such as Software Defined Networking
(SDN) collect a global network view that enables more complex
control functions, e.g., access control list, flow-level traffic
Gao, et al. Expires January 5, 2018 [Page 3]
Internet-Draft Flow Cost Service July 2017
scheduling, etc. In order to adapt to such architectures, ALTO
servers need to support flow space queries.
Req. FAR-2: ALTO servers SHOULD provide a view for a more expressive
packet header space.
With the emerging data plane technologies, multiple header fields
can be used to determine the forwarding path. As a consequence,
networks are moving to more flexible routing mechanisms beyond the
simple destination-based routing. Thus, the source-destination
query space is no longer sufficient to provide accurate cost
information. ALTO servers need to support queries of network
information in an extended packet header space.
This document addresses the following issues in providing fine-
grained flow-based cost query services in a more flexible query
space: (1) the compatibility with the legacy ALTO services; (2) the
support for emerging network architectures such as Software Defined
Networking; and 3) the redundancy trade-off between query and
response.
In this document, we describe two extensions of ALTO to provide the
flow-based cost query. The rest of this document is organized as
follows. Section 5 describes the extended schema on Filtered Cost
Map (FCM) and Endpoint Cost Service (ECS) to support cost queries of
arbitrary source-destination combinations. For networks using a more
generic flow concept such as Software-Defined Networks, Section 6
defines a flow-based novel ALTO service named the Flow Cost Service
(FCS), which supports the query of any fine-grained routing cost and
satisfies the growing demand of obtaining accurate costs in a network
using flow-based routing. Section 7 and Section 8 discuss security
and IANA considerations.
2. Terminology
This document uses the same terms as defined in [RFC7285] and
[I-D.ietf-alto-multi-cost] with the following additional terms:
o Protocol: In this document, a protocol means a network protocol in
the OSI model.
o Application-layer protocol: In this document, an application-layer
protocol indicates a network protocol above layer 4 in the OSI
model.
o Port: A port means a valid TCP or UDP port number in this
document.
Gao, et al. Expires January 5, 2018 [Page 4]
Internet-Draft Flow Cost Service July 2017
o Flow: A flow indicates a set of packets with similar attributes.
A typical definition of a flow is by a 5-tuple (protocol, source/
destination addresses and ports). In this document, a flow MAY be
a set of packets matching a given packet header pattern.
3. Overview of Approaches
This section presents a non-normative overview of flow-based query
extensions. It assumes the readers are familiar with Filtered Cost
Map and Endpoint Cost Service defined in [RFC7285] and their
extensions defined in [I-D.ietf-alto-multi-cost].
3.1. Backward Compatible Flow-based Filter
The legacy ALTO server based on [RFC7285] can provide two types of
flow cost query services: Filtered Cost Map and Endpoint Cost
Service. But both of them only support the query space in the mesh
shape. It can not satisfy the requirement of providing the view for
the flexible flow set query space.
This document extends the filter schema of Filtered Cost Map and
Endpoint Cost Service. The extended filter allows ALTO clients to
send multiple source-destination cross products in the same query.
In this way, the ALTO client can query any combinations of flow sets.
Also, the responses of such extended services are backward compatible
with legacy ALTO services.
3.2. Extended Endpoint Address
In order to support the requirement of providing the view for the
expressive packet header space, this document defines more types of
endpoint addresses to represent a flow. These extended address types
indicate the protocol information of flows besides encoding formats
of endpoint addresses.
Since the address types of both the source and the destination
specify a flow protocol, they MUST NOT conflict. This document
defines an address type dependency table to identify conflicts. If
the source and destination address types are different but do no
conflict, ALTO servers MUST specify the more accurate one as the flow
protocol.
3.3. Flow Cost Service for Advanced Query
In the emerging software-defined networks, the network control tends
to be based on more fine-grained flow attributes. Some advanced
requirements, such as the cost query for flows with endpoint-
independent attributes, are proposed by such use cases. However,
Gao, et al. Expires January 5, 2018 [Page 5]
Internet-Draft Flow Cost Service July 2017
those requirements cannot be fulfilled by the extension above. To
support the flow-based cost query in more flexible network
information space, this document defines Flow Cost Service, which
enables ALTO clients to customize flows by specifying OpenFlow packet
header match fields.
4. Changes Since Version -01
Note to Editor: Please remove this section prior to publication.
This section records the change logs of the draft updates.
o Change "EndpointURI" to "AddressType::EndpointAddr" for
consistency.
o Replace "Cost Confidence" by "Cost Statistics" for compatibility.
Changes since older versions:
Since -01 revision:
o Change the schema of "pid-flows" and "endpoint-flows" fields from
pair list to pair mesh list.
Since -02 revision:
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.
5. ALTO Flow Cost Specification: Basic Flow-based Query
This section describes backward compatible extensions for Filtered
Cost Map and Endpoint Cost Service to support flow-based query.
5.1. Flow-based Filtered Cost Map
5.1.1. Capabilities
The Filtered Cost Map capabilities are extended with a new member:
flow-based-filter.
Gao, et al. Expires January 5, 2018 [Page 6]
Internet-Draft Flow Cost Service July 2017
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:
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, a ALTO Server allows pid-flows to be
included in the requests. If not present, this field MUST be
interpreted as if it is specified false.
5.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<1..*><1..*>;]
[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 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. An ALTO client MUST include either "pids" or "pid-
flows" in a query but MUST NOT include them both at the same time.
Gao, et al. Expires January 5, 2018 [Page 7]
Internet-Draft Flow Cost Service July 2017
5.1.3. Response
The response is the same as defined in Section 4.1.3 of
[I-D.ietf-alto-multi-cost].
5.2. Extended Endpoint Address Encoding
This section extends the encoding format of endpoint addresses,
TypedEndpointAddr, which is defined in Section 10.4 of [RFC7285].
The type TypedEndpointAddr is made up of two components: AddressType
and EndpointAddr. [RFC7285] only defines two address types, "ipv4"
and "ipv6"", which represent IPv4 and IPv6 addresses respectively.
However, the flow-based ECS requires a more expressive endpoint
address encoding, which means more address types are required. This
document registers new address types and defines new formats of
endpoint addresses to support flow-based ECS query.
5.2.1. Address Type
This document defines three new categories of address type values for
AddressType:
Layer 2 (L2) protocol: The value of AddressType can be a layer 2
protocol, e.g. "eth", which refers to MAC addresses.
Layer 4 (L4) protocol: The value of AddressType can be a layer 4
protocol, e.g. "tcp" and "udp", which can refer to IPv4/IPv6
addresses and host names, with optional tcp/udp ports.
Application-layer protocol: The value of AddressType can be an
application-layer protocol, e.g. "ftp", "http", etc., which can
refer to IPv4/IPv6 addresses and host names, with optional tcp/udp
ports.
See Table 1 in Section 8.1 for a list of new AddressType identifiers
to be registered in the "ALTO Address Type Registry".
Because protocols in different layers conform some type-length-value
(TLV) dependencies, the AddressType identifiers missing the
dependencies MUST NOT appear in associated source and destination
endpoint addresses. The AddressType identifier dependencies defined
in this document are also defined in Section 8.1.
5.2.2. Endpoint Address
This document defines new formats of EndpointAddr as follows for the
new AddressType registered in Section 8.1.
Gao, et al. Expires January 5, 2018 [Page 8]
Internet-Draft Flow Cost Service July 2017
5.2.2.1. MAC Address
When AddressType is "eth", the EndpointAddr MUST be a MAC address,
which are encoded as specified by one of format EUI-48 in [EUI48] and
EUI-64 in [EUI64].
5.2.2.2. Host Name
Host names are encoded as specified in Section 11 of [RFC2181].
5.2.2.3. Address with Port
When AddressType is a layer 4 or application-layer protocol, the
EndpointAddr MUST be one of an IPv4/IPv6 address, a host name or an
address with port. An address with port is encoded as a string of
the format Addr:Port, with the ':' character as a separator. The
Addr component of EndpointAddr MUST be an IPv4/IPv6 address or a host
name. The Port component of EndpointAddr MUST be an integer between
1 and 65535. If the Addr component of EndpontAddr is an IPv6
address, the address MUST be enclosed in "[" and "]" characters, as
recommended in [RFC2732].
When AddressType is an application-layer protocol and the
EndpointAddr is not an address with port, ALTO servers MUST use the
default port. The default ports of some well-known AddressType
identifiers are defined in Table 1 in Section 8.1.
5.2.3. Extended Endpoint Address Examples
Some valid endpoint addresses based on the above extension look like
follows:
"eth:98-e0-d9-9c-df-81"
"http:www.example.com"
"ftp:198.51.100.34:5123"
"tcp:[2000::1:2345:6789:abcd]:8080"
5.3. Flow-based Endpoint Cost Service
5.3.1. Capabilities
The extensions of EndpointCostCapabilities are based on
FilteredCostMapCapabilities in Section 5.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
Gao, et al. Expires January 5, 2018 [Page 9]
Internet-Draft Flow Cost Service July 2017
"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
AddressType identifiers of TypedEndpointAddr in the request. The
ALTO server SHOULD NOT claim "ipv4" and "ipv6" in this field
explicitly, because they are supported by default. If not
present, this field MUST be interpreted as if it specifies the
default supported AddressType "ipv4" and "ipv6".
flow-based-filter: If true, 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.
5.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<1..*><1..*>;]
[EndpointFilter endpoints;]
[EndpointFilter endpoint-flows<1..*>;]
} ReqEndpointCostMap;
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.
If the AddressType of the source and destination in the same
EndpointFilter do not conform the dependencies defined in Table 1 of
Gao, et al. Expires January 5, 2018 [Page 10]
Internet-Draft Flow Cost Service July 2017
Section 8.1, the ALTO server MUST return an ALTO error response with
the error code "E_INVALID_FIELD_VALUE".
The additional requirement is that the ALTO client MUST specify
either "endpoints" or "endpoint-flows", but MUST NOT specify both.
5.3.3. Response
The response is the same as defined in Section 4.2.3 of
[I-D.ietf-alto-multi-cost].
5.4. Examples
5.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-type" : "application/alto-costmap+json",
"accepts" : "application/alto-costmapfilter+json",
"uses" : [ "my-default-network-map" ],
"capabilities" : {
Gao, et al. Expires January 5, 2018 [Page 11]
Internet-Draft Flow Cost Service July 2017
"max-cost-types" : 2,
"flow-based-filter" : true,
"cost-type-names" : [ "ord-routingcost" , "num-routingcost" ]
}
},
"basic-flow-based-endpoint-cost" : {
"uri" : "http://alto.example.com/endpointcost/lookup",
"media-type" : "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" ]
}
}
}
}
5.4.2. Flow-based Filtered Cost Map Service Example
Gao, et al. Expires January 5, 2018 [Page 12]
Internet-Draft Flow Cost Service July 2017
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 }
}
}
5.4.3. Flow-based Endpoint Cost Service Example
Gao, et al. Expires January 5, 2018 [Page 13]
Internet-Draft Flow Cost Service July 2017
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
}
}
}
6. 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 (host name, IP address or MAC address) and ports. In the
Gao, et al. Expires January 5, 2018 [Page 14]
Internet-Draft Flow Cost Service July 2017
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 cost query service, which is called
Flow Cost Service, to support the flow-based cost queries for such a
generic context of flows.
6.1. Basic Data Types
The Flow Cost Service introduces some new basic data types, as
defined below.
6.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.
6.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 3 for a list of proposed typed header fields.
6.1.3. Cost Statistics
This document defines a new cost mode, "statistical", for those
frequently updated cost metrics. This cost mode indicates that the
cost values represent statistics of the actual costs in some
duration. The values are specified as the CostStatistics object,
which is defined as follows:
object {
JSONNumber value;
[JSONNumber min;]
[JSONNumber max;]
[JSONNumber average;]
[JSONNumber variance;]
[JSONNumber duration;]
} CostStatistics;
value: The current value of the cost estimation.
Gao, et al. Expires January 5, 2018 [Page 15]
Internet-Draft Flow Cost Service July 2017
min: The minimum cost value in the estimated duration.
max: The maximum cost value in the estimated duration.
avarage: The average cost value in the estimated duration.
variance: The variance of the historical cost values in the
estimated duration.
duration: The length of the estimated duration.
6.2. Flow Cost Service
The Flow Cost Service provides cost information for each individual
flow specified in a request.
6.2.1. Media Type
The media type of the flow cost service is "application/alto-
flowcost+json".
6.2.2. HTTP Method
The flow cost service is requested using the HTTP POST method.
6.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;
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;
Gao, et al. Expires January 5, 2018 [Page 16]
Internet-Draft Flow Cost Service July 2017
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 6.1.1. The value type of a field is protocol-
specific, see Table 4 for the value type associated with typed
header fields in Table 3.
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].
6.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.
optional: A list of optional typed header fields. The ALTO server
MAY leverage the values of the optional fields to find more
accurate costs.
6.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:
Gao, et al. Expires January 5, 2018 [Page 17]
Internet-Draft Flow Cost Service July 2017
object {
FlowCostMap flow-cost-map;
} 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].
6.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..*>;]
[TypedHeaderField missing<2..*>;]
[TypedHeaderField unsupported<1..*>;]
} FlowFilterError;
conflicts: A list of conflicting typed header fields. See
Section 6.2.6.1 for details.
missing: A list of missing typed header fields. See Section 6.2.6.2
for details.
unsupported: A list of unsupported typed header fields. See
Section 6.2.6.3 for details.
6.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
Gao, et al. Expires January 5, 2018 [Page 18]
Internet-Draft Flow Cost Service July 2017
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.
6.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.
6.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 6.2.6.1, the ALTO servers can report unsupported
typed header fields in the "unsupported" field associated with the
corresponding flow ID.
6.3. Flow Cost Service Example
Gao, et al. Expires January 5, 2018 [Page 19]
Internet-Draft Flow Cost Service July 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": "statistical",
"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"
}
}
}
HTTP/1.1 200 OK
Content-Length: 312
Content-Type: application/alto-flowcost+json
{
"meta": {
"cost-type": {
"cost-mode": "statistical",
"cost-metric": "routingcost"
}
},
"flow-cost-map": {
"l3-flow": {"value": 10, "average": 15},
"l3-flow-aggr": {"value": 50, "average": 45},
"optional-l3-flow": {"value": 5, "average": 5}
}
}
Gao, et al. Expires January 5, 2018 [Page 20]
Internet-Draft Flow Cost Service July 2017
7. Security Considerations
An ALTO client can send flow-based queries to the Flow Cost Service.
However, the ALTO server or a third party who is able to intercept
such messages can store and process obtained information in order to
analyze user behaviors and communication patterns, which has been
discussed in Section 15.4 of [RFC7285]. Since the fine-grained flow-
based query provides more information, an ALTO client should be
cognizant about the trade-off between redundancy and privacy.
8. IANA Considerations
This document defines two new entries to be registered to
application/alto-* media types.
8.1. ALTO Address Type Registry
This document defines five new address types as follows to be
registered to "ALTO Address Type Registry".
The AddressType dependencies are defined as a equivalence relation.
The dependencies shown in Table 1 only contain a part of the
AddressType dependencies. The complete dependencies SHOULD be
inferred by properties of the equivalence relation.
Gao, et al. Expires January 5, 2018 [Page 21]
Internet-Draft Flow Cost Service July 2017
+------------+-------------+--------------+----------+--------------+
| Identifier | Category | Address | Default | Dependencies |
| | | Encoding | Port | |
+------------+-------------+--------------+----------+--------------+
| eth | Layer 2 | See Section | None | ipv4, ipv6 |
| | | 5.2.2.1 | | |
| tcp | Layer 4 | See Section | None | ipv4, ipv6 |
| | | 5.2.2.2 and | | |
| | | Section 5.2. | | |
| | | 2.3 | | |
| udp | Layer 4 | See Section | None | ipv4, ipv6 |
| | | 5.2.2.2 and | | |
| | | Section 5.2. | | |
| | | 2.3 | | |
| ftp | Application | See Section | 21 | tcp |
| | Layer | 5.2.2.2 and | | |
| | | Section 5.2. | | |
| | | 2.3 | | |
| http | Application | See Section | 80 | tcp |
| | Layer | 5.2.2.2 and | | |
| | | Section 5.2. | | |
| | | 2.3 | | |
+------------+-------------+--------------+----------+--------------+
Table 1: ALTO Address Type Registry
8.2. Media Types
This document registers two media types listed in Table 2.
+--------------+--------------------------+----------------+
| Type | Subtype | Specification |
+--------------+--------------------------+----------------+
| application | alto-flowcost+json | Section 5.1.3 |
| application | alto-flowcostparam+json | Section 5.3.2 |
+--------------+--------------------------+----------------+
Table 2: ALTO FCS Media Types
Type name: application
Subtype name: This document registers two subtypes, as listed in
Table 2.
Required parameters: n/a
Optional parameters: n/a
Gao, et al. Expires January 5, 2018 [Page 22]
Internet-Draft Flow Cost Service July 2017
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 2 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.
8.3. Header Field
TBD: Create the "ALTO Header Field Name Registry".
9. 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.
10. References
10.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>.
Gao, et al. Expires January 5, 2018 [Page 23]
Internet-Draft Flow Cost Service July 2017
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997,
<http://www.rfc-editor.org/info/rfc2181>.
[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>.
10.2. Informative References
[EUI48] IEEE, , "Guidelines for use of a 48-bit Extended Unique
Identifier (EUI-48)", 2012,
<http://standards.ieee.org/develop/regauth/tut/eui48.pdf>.
[EUI64] IEEE, , "Guidelines for use of a 64-bit Extended Unique
Identifier (EUI-64)", November 2012,
<http://standards.ieee.org/develop/regauth/tut/eui64.pdf>.
[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 January 5, 2018 [Page 24]
Internet-Draft Flow Cost Service July 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 3: 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 4: Value Types for Typed Header Fields
Gao, et al. Expires January 5, 2018 [Page 25]
Internet-Draft Flow Cost Service July 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 January 5, 2018 [Page 26]