One document matched: draft-yang-alto-path-vector-03.txt
Differences from draft-yang-alto-path-vector-02.txt
ALTO WG G. Bernstein
Internet-Draft Grotto Networking
Intended status: Standards Track K. Gao
Expires: January 9, 2017 Tsinghua University
Y. Lee
Huawei
W. Roome
M. Scharf
Nokia
Y. Yang
Yale University
July 8, 2016
ALTO Extension: Path Vector Cost Mode
draft-yang-alto-path-vector-03.txt
Abstract
The Application-Layer Traffic Optimization (ALTO) Service has defined
network and cost maps to provide basic network information, where the
cost maps allow only scalar (numerical or ordinal) cost mode values.
This document introduces a new cost mode called path-vector to allow
ALTO clients to support use cases such as capacity regions for
applications. This document starts with a non-normative example
called multi-flow scheduling (or capacity region) to illustrate that
ALTO cost maps without path vectors cannot provide sufficient
information. This document then defines path-vector as a new cost
mode.
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
Bernstein, et al. Expires January 9, 2017 [Page 1]
Internet-Draft ALTO Extension: Path Vector July 2016
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 9, 2017.
Copyright Notice
Copyright (c) 2016 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. Example: Capacity Region for Multi-Flow Scheduling . . . . . 3
3. Path-Vector Query . . . . . . . . . . . . . . . . . . . . . . 5
4. Path-Vector Response . . . . . . . . . . . . . . . . . . . . 5
5. Path-Vector in IRD . . . . . . . . . . . . . . . . . . . . . 7
6. Path-Vector in Incremental Updates . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
10.1. Normative References . . . . . . . . . . . . . . . . . . 8
10.2. Informative References . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction
The ALTO base protocol [RFC7285] is designed for a setting of
exposing network topology using the extreme "my-Internet-view"
representation, which abstracts a whole network as a single node that
has a set of access ports, with each port connects to a set of
endhosts. This "single-node" abstraction is simple and can support a
wide range of applications already.
A problem of this abstraction, however, is that it does not provide
sufficient information for use cases that require exposure of
topology information beyond the single-node abstraction, for example,
Bernstein, et al. Expires January 9, 2017 [Page 2]
Internet-Draft ALTO Extension: Path Vector July 2016
when there is a need to detect sharing of resources in the underlying
topology (see an example in Section 3).
This document goes beyond the single-node topology by introducing
path vector as a new ALTO cost mode, where each path vector specifies
abstracted network elements on the routing paths of a set of flows.
Since the network elements on a path vector are abstract network
elements defined by ALTO servers, the new path-vector cost mode
provides a mechanism to allow a network to control the level of
topology exposure, and at the same time better support application
traffic optimization. The design of path vector is based on the ALTO
WG discussions at IETF 89, with summary slides at
http://tools.ietf.org/agenda/89/slides/slides-89-alto-2.pdf.
The organization of this document is organized as follows. Section 2
gives a non-normative example called multi-flow scheduling to
illustrate the need to introduce path vectors. Sections 3-6 specify
the path vector cost mode for query, response, announcements, and
incremental udpates, respectively. Sections 7 and 8 discuss security
and IANA considerations.
2. Example: Capacity Region for Multi-Flow Scheduling
Consider the case that routing is given. Then what application-layer
traffic optimization will focus on is traffic scheduling among
application-layer paths. Specifically, assume that an application
has control over a set of flows F = {f1, f2, ..., f_|F|}. If routing
is given, what the application can control is x1, x2, ..., x_|F|,
where xi is the amount of traffic for flow i. Let x = [x1, ...,
x_|F|] be the vector of the flow traffic amounts. Due to shared
links, feasible values of x where link capacities are not exceeded
can be a complex polytope.
Specifically, consider a network as shown in Figure 1. The network
has 7 switches (sw1 to sw7) forming a dumb-bell topology. Switches
sw1/sw3 provide access on one side, s2/s4 provide access on the other
side, and sw5-sw7 form the backbone. Endhosts eh1 to eh4 are
connected to access switches sw1 to sw4 respectively. Assume that
the bandwidth of each link is 100 Mbps.
Bernstein, et al. Expires January 9, 2017 [Page 3]
Internet-Draft ALTO Extension: Path Vector July 2016
+------+
| |
--+ sw6 +--
/ | | \
PID1 +-----+ / +------+ \ +-----+ PID2
eh1__| |_ / \ ____| |__eh2
| sw1 | \ +--+---+ +---+--+ / | sw2 |
+-----+ \ | | | |/ +-----+
\_| sw5 +---------+ sw7 |
PID3 +-----+ / | | | |\ +-----+ PID4
eh3__| |__/ +------+ +------+ \____| |__eh4
| sw3 | | sw4 |
+-----+ +-----+
Figure 1: Raw Network Topology.
The single-node ALTO topology abstraction of the network is shown in
Figure 2.
+----------------------+
{eh1} | | {eh2}
PID1 | | PID2
+------+ +------+
| |
| |
{eh3} | | {eh4}
PID3 | | PID4
+------+ +------+
| |
+----------------------+
Figure 2: Base Single-Node Topology Abstraction.
Consider an application overlay (e.g., a large data analysis system)
which needs to schedule the traffic among a set of endhost source-
destination pairs, say eh1 -> eh2, and eh3 -> eh4. The application
can request a cost map providing end-to-end available bandwidth,
using 'available bw' as cost-metric and 'numerical' as cost-mode.
Assume that the application receives from the cost map that both eh1
-> eh2 and eh3 -> eh4 have bandwidth 100 Mbps. It cannot determine
that if it schedules the two flows together, whether it will obtain a
total of 100 Mbps or 200 Mbps. This depends on whether the routing
paths of the two flows share a bottleneck in the underlying topology:
o Case 1: If eh1 -> eh2 and eh3 -> eh4 use different paths, for
example, when the first uses sw1 -> sw5 -> sw7 -> sw2, and the
Bernstein, et al. Expires January 9, 2017 [Page 4]
Internet-Draft ALTO Extension: Path Vector July 2016
second uses sw3 -> sw5 -> sw6 -> sw7 -> sw4. Then the application
will obtain 200 Mbps.
o Case 2: If eh1 -> eh2 and eh3 -> eh4 share a bottleneck, for
example, when both use the direct link sw5 -> sw7, then the
application will obtain only 100 Mbps.
To allow applications to distinguish the two aforementioned cases,
the network needs to provide more details. The path vector extension
defined in this document resolves this issue.
See [I-D.bernstein-alto-topo] for a survey of use-cases where
extended network topology information is needed.
3. Path-Vector Query
Since the key motivation of providing path vectors is for concurrent-
flow settings, due to sharing of network resources, the specification
is for a multi-flow setting. Also, instead of defining such queries
separately for grouping of endhosts (PIDs) and individual endpoints,
we define for generic sources, destinations.
POST /capacityregion/lookup HTTP/1.1
Host: alto.example.com
Content-Length: TBD
Content-Type: application/alto-flowparams+json
Accept: application/alto-costmap+json,application/alto-error+json
{
"cost-type" : {"cost-mode": "path-vector",
"cost-metric": "bw"}
},
"flows" : [
{"src": "ipv4:192.0.1.1", "dst": "ipv4:192.0.1.2"},
{"src": "ipv4:192.0.1.3", "dst": "ipv4:192.0.1.4"},
{"src": "ipv4:192.0.1.1", "dst": "ipv4:192.0.1.4"}
]
}
4. Path-Vector Response
An extension supporting the path-vector cost-mode MUST support the
following extension of Section 11.2.3.6 of [RFC7285]:
Bernstein, et al. Expires January 9, 2017 [Page 5]
Internet-Draft ALTO Extension: Path Vector July 2016
object {
cost-map.DstCosts.JSONValue -> JSONString<0,*>;
meta.cost-mode = "path-vector";
} InfoResourcePVCostMap : InfoResourceCostMap;
Specifically, the preceding specifies that InfoResourcePVCostMap
extends InfoResourceCostMap. The body specifies that the first
extension is achieved by changing the type of JSONValue defined in
DstCosts of cost-map to be an array of JSONString; the second
extension is that the cost-mode of meta MUST be "path-vector".
An example cost map using path-vector is the following:
Bernstein, et al. Expires January 9, 2017 [Page 6]
Internet-Draft ALTO Extension: Path Vector July 2016
HTTP/1.1 200 OK
Content-Length: TBA
Content-Type: application/alto-costmap+json
{
"meta" : {
"vtag" : {
"resource-id": "my-costmap",
"tag": "c0ce023b8678a7b9ec00324673b98e54656d1f6d"
}
"cost-type" : {"cost-mode": "path-vector",
"cost-metric": "bw"
}
}
},
"cost-map" : {
"ipv4:192.0.1.1": {
"ipv4:192.0.1.2": ["ne57"],
"ipv4:192.0.1.4": ["ne57", "ne74"]
},
"ipv4:192.0.1.3": {
"ipv4:192.0.1.4": ["ne56", "ne67"]
}
}
"nep-map" : {
"ne57" : {"bw" : 100},
"ne74" : {"bw" : 100},
"ne56" : {"bw" : 100},
"ne67" : {"bw" : 100}
}
}
To interpret the path vectors in a cost map, an ALTO client will need
access to the properties of the abstract network elements named in
the path vectors. One approach is to use a network element property
service (e.g., the unified properties draft
[I-D.roome-alto-unified-props]). In this design, they are included
as a second map in the same message, for consistency and saving of
round-trips.
5. Path-Vector in IRD
Announcing the support of path vector in IRD is relatively
straightforard: the mode is included as the IRD.
Bernstein, et al. Expires January 9, 2017 [Page 7]
Internet-Draft ALTO Extension: Path Vector July 2016
6. Path-Vector in Incremental Updates
A concern is whether the design allows efficient incremental updates,
on either the path vectors of the element properties. For this
design, the keys along the data path allow such easy encoding.
7. Security Considerations
This document has not conducted its security analysis.
8. IANA Considerations
This document requires the definition of a new cost-mode named path-
vector.
9. Acknowledgments
The author thanks discussions with Xiao Shi, Xin Wang, Erran Li,
Tianyuan Liu, Andreas Voellmy, Haibin Song, and Yan Luo.
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>.
10.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.
[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.
Bernstein, et al. Expires January 9, 2017 [Page 8]
Internet-Draft ALTO Extension: Path Vector July 2016
[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>.
Authors' Addresses
Greg Bernstein
Grotto Networking
Fremont, CA
USA
Email: gregb@grotto-networking.com
Kai Gao
Tsinghua University
Beijing Beijing
China
Email: gaok12@mails.tsinghua.edu.cn
Young Lee
Huawei
TX
USA
Email: leeyoung@huawei.com
Wendy Roome
Nokia/Bell Labs
600 Mountain Ave, Rm 3B-324
Murray Hill, NJ 07974
USA
Phone: +1-908-582-7974
Email: wendy.roome@nokia.com
Bernstein, et al. Expires January 9, 2017 [Page 9]
Internet-Draft ALTO Extension: Path Vector July 2016
Michael Scharf
Nokia
Germany
Email: michael.scharf@nokia.com
Y. Richard Yang
Yale University
51 Prospect St
New Haven CT
USA
Email: yry@cs.yale.edu
Bernstein, et al. Expires January 9, 2017 [Page 10]
| PAFTECH AB 2003-2026 | 2026-04-24 01:09:36 |