ALTO WG K. Gao Internet-Draft Tsinghua University Intended status: Standards Track X. Wang Expires: December 31, 2017 C. Gu Tongji University Y. Yang Yale University G. Chen Huawei June 29, 2017 Recommendation for Compressing ALTO Path Vector draft-gao-alto-routing-state-abstraction-04.txt Abstract The path vector extension [I-D.ietf-alto-path-vector] has extended the original ALTO protocol [RFC7285] with the ability to represent not only end-to-end metrics but also information about shared link risk groups (SLRG). However, straw man algorithms to compute ALTO path vector can contain redundant information and result in unnecessary communication overhead. The situation gets even worse when certain ALTO extensions are enabled, for example, the incremental extension [I-D.ietf-alto-incr-update-sse] which continuously pushes data changes to ALTO clients. In this document, an algorithm is described which can effectively reduce the communication overhead while still containing the same information as in the original path vector. The algorithm is fully compatible with the path vector extension and has several by-products which can be leveraged by other extensions to achieve better performance. 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. Gao, et al. Expires December 31, 2017 [Page 1] Internet-Draft Routing State Abstraction June 2017 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 31, 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. Compressing Path Vector . . . . . . . . . . . . . . . . . . . 4 3. Equivalent Transformation Algorithm . . . . . . . . . . . . . 6 3.1. Parameters and Variables . . . . . . . . . . . . . . . . 6 3.2. Algorithm Description . . . . . . . . . . . . . . . . . . 7 4. Recommended Redundancy Check Algorithm . . . . . . . . . . . 8 4.1. Parameters and Variables . . . . . . . . . . . . . . . . 8 4.2. Algorithm Description . . . . . . . . . . . . . . . . . . 9 5. Reducing Unnecessary Incremental Updates . . . . . . . . . . 9 6. Extension for Customized Input Parameters . . . . . . . . . . 10 6.1. Parameters and Variables . . . . . . . . . . . . . . . . 10 6.2. Algorithm Description . . . . . . . . . . . . . . . . . . 11 6.3. ALTO Extension for Client Constraint Map . . . . . . . . 11 6.4. Examples . . . . . . . . . . . . . . . . . . . . . . . . 13 6.5. Compatibility . . . . . . . . . . . . . . . . . . . . . . 18 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 Gao, et al. Expires December 31, 2017 [Page 2] Internet-Draft Routing State Abstraction June 2017 10.1. Normative References . . . . . . . . . . . . . . . . . . 19 10.2. Informative References . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 1. Introduction The path vector extension [I-D.ietf-alto-path-vector] has extended the original ALTO protocol [RFC7285] with the ability to present more complex internal structures about the network than the cost map or endpoint cost service. This has enabled ALTO clients to query more sophisticated information such as Shared Link Risk Groups (SLRG), by which ALTO clients can schedule their flows properly to avoid congestion and utilize the network resources. A straw man approach, especially in the context of Software Defined Networking (SDN) where network providers have a global view, can implement the path vector by retrieving the paths for all requested flows and returning the links on those paths. However, this approach has several drawbacks: o The response may lead to privacy leaks. Since the paths constitute a sub-graph of the global topology, returning the information without further processing leaks sensitive information. o The response contains redundant information. Information on Shared Link Risk Groups is primarily used to avoid network bottlenecks. Thus, if a link cannot become the bottleneck, as demonstrated in Section 2, it is considered as redundant. Redundant links not only add to the communication overhead, but also trigger false-positive data change events when incremental update extension is activated. This document describes a reference implementation of the path vector extension. The implementation is based on the straw man approach but the underlying algorithm, namely the "equivalent transformation" algorithm, can be integrated with any path vector implementation as a post-processing step. This extension is fully compatible with the path vector extension and can be optionally turned on and off without effecting the correctness of responses. A crucial part of equivalent transformation is an algorithm to find redundant links. By tuning the redundancy check algorithm, one can make different trade-off decisions between efficiency and privacy. As a by-product, this algorithm can generate filters for incremental updates of path vector queries. It can take some customized parameters from ALTO clients to achieve even better compression results. Gao, et al. Expires December 31, 2017 [Page 3] Internet-Draft Routing State Abstraction June 2017 This document is organized as follows. Section 2 gives a concrete example to demonstrate the essence of compressing the path vector. Section 3 gives the equivalent transformation algorithm and Section 4 introduces two reference implementations of redundancy check algorithm. Section 5 discusses how to generate filters for ALTO incremental update services and Section 6 introduces an optional extension which allows ALTO clients to share information and further improve the performance of equivalent transformation. Section 7 and Section 8 discuss security and IANA considerations. 2. Compressing Path Vector We use an example shown in Figure 1. The network has 6 switches (sw1 to sw6). Switches sw1/sw3 provide access on one side, s2/s4 provide access on the other side, and sw5/sw6 form the backbone. End hosts eh1 to eh4 are connected to access switches sw1 to sw4 respectively. Assume that the bandwidth of each link is 100 Mbps. Assume that the network is abstracted with 4 PIDs, with each representing the host at one access switch. PID1 +-----+ +-----+ PID2 eh1__| |_ ____| |__eh2 | sw1 | \ +------+ +------+ / | sw2 | +-----+ \ | | | |/ +-----+ \_| sw5 +---------+ sw6 | PID3 +-----+ / | | | |\ +-----+ PID4 eh3__| |__/ +------+ +------+ \____| |__eh4 | sw3 | | sw4 | +-----+ +-----+ Figure 1: Raw Network Topology +--------+---------------+ | Link | Description | +--------+---------------+ | link1 | sw1 <==> sw5 | | link2 | sw2 <==> sw6 | | link3 | sw3 <==> sw5 | | link4 | sw4 <==> sw6 | | link5 | sw5 <==> sw6 | +--------+---------------+ Table 1: Description of the Links Consider an application which schedules the traffic between two flows, eh1 -> eh2 and eh3 -> eh4. The application can query the path vector and a straw man implementation will return all 5 links as shown in Figure 2. Gao, et al. Expires December 31, 2017 [Page 4] Internet-Draft Routing State Abstraction June 2017 path-vector: eh1: [ eh2: [ne1, ne5, ne2]], eh3: [ eh4: [ne3, ne4, ne5]] network element property map: ne1: 100 Mbps ne2: 100 Mbps ne3: 100 Mbps ne4: 100 Mbps ne5: 100 Mbps Figure 2: Path Vector Returned by Straw Man Implementation The returned path vector effectively represents the following linear constraints on the available bandwidth of the two flows: bw(eh1->eh2) <= 100 Mbps (ne1) bw(eh1->eh2) <= 100 Mbps (ne2) bw(eh3->eh4) <= 100 Mbps (ne3) bw(eh3->eh4) <= 100 Mbps (ne4) bw(eh1->eh2) + bw(eh3->eh4) <= 100 Mbps (ne5) Figure 3: Linear Constraints Represented by the Path Vector It can be see that the constraints of ne1 and ne2 are exactly the same, so are ne3 and ne4. Intuitively, we can replace ne1 and ne2 with an abstract network element "ane1" as defined in [I-D.ietf-alto-path-vector] while replacing ne3 and ne4 with "ane2". The new path vector is shown as in Figure 4. path-vector: eh1: [ eh2: [ane1, ne5]], eh3: [ eh4: [ane2, ne5]] network element property map: ane1: 100 Mbps ane2: 100 Mbps ne5: 100 Mbps Figure 4: Path Vector after Merging ne1/ne2 and ne3/ne4 Take a deeper look at Figure 3, it can be seen that constraints of ane1 (ne1/ne2) and ane2 (ne3/ne4) can be implicitly derived from that of ne5. Thus, these constraints are considered _redundant_ and the returned path vector can be further reduced. We relabel ne5 with "ane3" and the new path vector is shown as in Figure 5. Gao, et al. Expires December 31, 2017 [Page 5] Internet-Draft Routing State Abstraction June 2017 path-vector: eh1: [ eh2: [ane3]], eh3: [ eh4: [ane3]] network element property map: ane3: 100 Mbps Figure 5: Path Vector after Removing Redundant Elements It can be clearly seen that the new path vector (Figure 5) is much more compact than the original path vector (Figure 2) but they contain just as much information. Meanwhile, the application can hardly infer any thing about the original topology with this compact path vector. Thus, to reduce the communication overhead of the path vector extension and improve privacy protection, an algorithm is described in this document to systematically compute the compact path vector. 3. Equivalent Transformation Algorithm This section describes the path vector compression algorithm, namely "equivalent transformation" algorithm. 3.1. Parameters and Variables The equivalent transformation algorithm accept 3 parameters: the original path vector P, the corresponding network element property map M, and a redundancy check algorithm R(P,M). Original path vector P: The original path vector P MUST have the format of a cost map with the cost being a vector of network element names, as defined in [I-D.ietf-alto-path-vector]. Network element property map M: The network element property map M MUST contain all the network elements whose names are included in the original path vector P. It MUST contain at least one valid ALTO cost type which is supported by the corresponding path vector service, but MUST NOT contain ordinal values. Unless it is specifically defined in another extension, the cost values MUST follow the associative addition rule, e.g. cost(ne1) + cost(ne2) = cost(ne1 o ne2) = cost(ne2) + cost(ne1) where ne1 o ne2 represents a virtual "path" consisting of ne1 and ne2. One exception is bandwidth, where the "addition" is actually a "minimum" function. Redundancy check algorithm R(P,M): The redundancy check R(P,M) MUST accept the two parameters P and M as specified above. It MUST Gao, et al. Expires December 31, 2017 [Page 6] Internet-Draft Routing State Abstraction June 2017 return a list of network element names, representing those whose corresponding bandwidth constraints are redundant. In addition to the parameters mentioned above, the algorithm also maintains the following variables. Temporary path vector P0: The temporary path vector stores the temporary value after each step of equivalent transformation. Temporary network element property map M0: The temporary network element property map M0 stores the temporary value of a network element property map after each step of equivalent transformation. Reverse network element map RM: The reverse network element map RM is a map whose key is a network element name with the value being a set of endpoint/PID pairs. Redundant network element set S: The redundant network element set S contains the result of redundancy check algorithm R(P,M). 3.2. Algorithm Description The equivalent transformation consists of the following steps: 1. When the algorithm starts execution, it sets P0 = P and M0 = M 2. For each network element name "n", find the set of endpoint/PID pairs {(a,b)} where "n" appears in the path vector between a to b in P0. Put the resulted set of endpoint/PID pairs in RM with "n" as the key. 3. Group RM by the value sets, e.g. put all (n,v) which have the same set of endpoint/PID pairs in the same group. It is guaranteed that each network element name only appears once in one group. Now use the groups to construct a partition of all network element names, where each partition contains all the network element names from a single group. Each partition is associated with a unique ID, which follows the format of a network element name as defined in [I-D.ietf-alto-path-vector]. 4. For each endpoint/PID pair in P0, replace the network element names with their group IDs and remove duplicated values. Construct an empty network element property map M1. For each group, create an network element property entry "e" by "adding" the network element properties in M0 of all network elements which belong in the group and put "e" in M1 with the group ID as the key. Replace M0 with M1. Gao, et al. Expires December 31, 2017 [Page 7] Internet-Draft Routing State Abstraction June 2017 5. Pass P0 and M0 to redundancy check algorithm R(P,M), store the result in S. 6. If only bandwidth is contained in M0, go to 7. Otherwise, go to 8. 7. For each endpoint/PID pair, remove the network element names in S from the path vector. Remove the entries in M0 whose key is in S. Go to 10. 8. Construct an empty network element property map M1. For each network element property entry in M0, if the network element name is not in S, put the entry in M1. For each network element name "n" in S, find the corresponding set of endpoint/PID pairs in RM. For each pair, replace "n" in the corresponding path vector to a new unique network element name and put an entry in M1 whose key is the new network element name while the value being the value of "n" in M0. Replace M0 with M1. 9. Repeat steps 2-4 and go to 10. 10. Create a virtual network element "n" with a unique network element name and bandwidth set to a sufficiently large value. For each endpoint/PID pair in P, if the path vector is an empty set (this only happens when only bandwidth is requested), put the name of "n" in the path vector and add "n" to M0. 11. Return P0 as the path vector response and M0 as the corresponding network element property map. The term "adding" is in quotes because the exact meaning depends on the cost types. As stated earlier, the values MUST NOT be ordinal and MUST follow the associative addition rule unless specifically defined in a later extension. This document defines one exception -- bandwidth -- whose addition rule is the "minimum" function. 4. Recommended Redundancy Check Algorithm In this section, an algorithm is described as a reference implementation of redundancy check algorithm R(P,M). 4.1. Parameters and Variables The algorithm takes two parameters: the path vector P and the corresponding network element property map M. Path vector P: As specified in Section 3.1. Gao, et al. Expires December 31, 2017 [Page 8] Internet-Draft Routing State Abstraction June 2017 Network element property map M: As specified in Section 3.1. In addition to the parameters, this algorithm also maintains the following variables. Set of linear constraints C: The set of linear constraints which can be derived from P and M. 4.2. Algorithm Description The algorithm consists of the following steps: 1. If the network element properties in M do not include bandwidth, return the set of all network elements. 2. Construct the set of linear constraints, C. For each endpoint/ PID pair, define a variable "x_i" with a unique ID "i". Construct RM as specified in step 3 of Section 3.2. For each network element "n", find the corresponding set of endpoint/PID pairs "p_n" in RM. Construct a linear constraint "c: ax <= b", whose left hand side is the sum of all the variables associated with the pairs in "p_n", and the right hand side the bandwidth of "n". Put "c" in C. 3. For each "c_i: a_ix <= b_i" in C, construct a new linear programming problem: max c_ix where a_jx <= b_j, j is not equal to i 4. Solve this linear programming problem, let the maximum value be "z". If "z <= b_i", this constraint is redundant. Otherwise the constraint is NOT redundant. 5. Repeat steps 3-4 until the redundancy of all network elements contained in the original path vector has been identified. Return the set of network elements whose corresponding linear constraints are redundant. 5. Reducing Unnecessary Incremental Updates This section describes how an ALTO server implementation can use the results in the redundancy check algorithm described in Section 4 to filter certain incremental updates. Equivalent transformation algorithm can also help reduce unnecessary incremental updates. Consider the example in Section 2 where the bandwidth of link1 (s1<=>s5) has increased from 100 Mbps to 150 Mbps. Gao, et al. Expires December 31, 2017 [Page 9] Internet-Draft Routing State Abstraction June 2017 Straw man approaches may push incremental updates to ALTO clients without considering how the value changes. On the other hand, this link is not included in the path vector after equivalent transformation, and one can conclude from the redundancy check algorithm Section 4.2 that it can only be non-redundant if "b_i < z <= 100 Mbps". Since the new "b_i" is 150 Mbps, this condition does not hold, meaning link1 is still redundant in the updated path vector. In that case, ALTO server MAY NOT push the incremental updates. However, this filter only works for redundant network elements, e.g. "z <= b_i". In all other cases, the path vector has to be recomputed to guarantee equivalence. 6. Extension for Customized Input Parameters This section introduces an optional extension which can be leveraged by ALTO clients to help reduce the communication overhead of path vector services. In order to do so, a revised version of Section 4 must be introduced. 6.1. Parameters and Variables The algorithm takes three parameters: the path vector P, the corresponding network element property map M and client constraint CM. Path vector P: Same as in Section 4.1. Network element property map M: Same as in Section 4.1. Client constraint map CM: Client constraint map CM has the same format as a cost map, where the first key represents the source endpoint address/PID name, the second key represents the destination endpoint address/PID name, and the value is a non- negative float number representing the upper bound bandwidth value for the given endpoint/PID pair. The algorithm also maintains the following variables: Set of linear constraints C: The same as C in Section 4.1. Set of client constraints CC: The set of linear constraints which can be derived from CM. Gao, et al. Expires December 31, 2017 [Page 10] Internet-Draft Routing State Abstraction June 2017 6.2. Algorithm Description The algorithm consists of the following steps: 1. The same as step 1 in Section 4.2. 2. The same as step 2 in Section 4.2. 3. For each endpoint/PID pair in CM, assume the value is a non- negative number "u". If the pair is also in the original path vector, construct a linear constraint "cc: x_i <= u" and add it to CC where "x_i" is the variable associated with the same pair in step 2. 4. For each "c_i: a_ix <= b_i" in C, construct a linear programming problem: max c_ix where a_jx <= b_j in C, j is not equal to i x_j <= u_j in CC 5. The same as step 4 in Section 4.2. 6. The same as step 5 in Section 4.2. 6.3. ALTO Extension for Client Constraint Map This section describes the extensions needed to enable client constraint map. Any ALTO resource/service which supports client constraint map MUST also support the path vector extension and accept cost types whose cost mode is "path-vector" and cost metric "ane". 6.3.1. Capabilities The client constraint map extension requires a new capability field "client-constraint-map" in the IRD entry. object { JSONString cost-type-names<1..*>; [JSONBool client-constraint-map;] ... capabilities defined by other extensions } ClientConstraintMapCapabilities; cost-type-names: As defined in Section 11.3.2.4 of [RFC7285]. Gao, et al. Expires December 31, 2017 [Page 11] Internet-Draft Routing State Abstraction June 2017 client-constraint-map: If present and the value is "true", it means the resource/service accepts client constraint map in the parameters. Otherwise, the client MUST assume the server does not support this extension and SHOULD NOT include client constraint map in input parameters. 6.3.2. Accept Input Parameters For filtered cost map with client constraint map extension, it MUST accept the following parameters: object { [CostType cost-type;] [PIDFilter pids;] [ClientConstraintPIDMap client-constraint-map;] ... input parameters defined by other extensions } ReqFilteredCostMap; object { PIDName -> ClientConstraintPIDGroup; } ClientConstriantPIDMap; object { PIDName -> JSONNumber; } ClientConstraintPIDGroup; cost-type: As defined in Section 11.3.2.3 in [RFC7285]. It MUST have the cost mode "path-vector" and cost metric "ane" if the field "client-constraint-map" is present. Otherwise, the ALTO server MUST return an error with error code "E_INVALID_FIELD_VALUE". pids: As defined in Section 11.3.2.3 in [RFC7285]. client-constraint-map: The client constraint map MUST have the format as a JSON object "ClientConstraintPIDMap". All the PID names in the client constraint map MUST also be included in "pids", otherwise the ALTO server MUST return an error with error code "E_INVALID_FIELD_VALUE". If the value for a given PID pair is 0, ALTO server MUST not included this pair in the path vector. Similarly, the input parameters for endpoint cost services with client constraint map MUST have the following format: Gao, et al. Expires December 31, 2017 [Page 12] Internet-Draft Routing State Abstraction June 2017 object { [CostType cost-type;] EndpointFilter endpoints; [ClientConstraintEndpointMap client-constraint-map;] } ReqEndpointCostMap; object { TypedEndpointAddr -> ClientConstraintEndpointGroup; } ClientConstriantEndpointMap; object { TypedEndpointAddr -> JSONNumber; } ClientConstraintEndpointGroup; cost-type: Same as above. endpoints: As defined in Section 11.5.1.3 of [RFC7285]. client-constraint-map: The client constraint map contained in the parameter MUST have the format of a JSON object "ClientConstriantEndpointMap". All the endpoint addresses MUST also appear in the "endpoints", otherwise the ALTO server MUST return an error with an error code "E_INVALID_FIELD_VALUE". If the value for a given endpoint pair is 0, ALTO server MUST NOT included this pair in the path vector. 6.4. Examples This section contains a series of examples for the client constraint map extension. 6.4.1. Information Resource Directory Examples { "meta": { "cost-types": { "pv-ane": { "cost-mode": "path-vector", "cost-metric": "ane" } } }, "resource": { "default-network-map": { "uri": "http://alto.example.com/networkmap", "media-type": "application/alto-networkmap+json" }, "filtered-multi-cost-map": { Gao, et al. Expires December 31, 2017 [Page 13] Internet-Draft Routing State Abstraction June 2017 "uri": "http://alto.example.com/costmap/filtered", "media-type": "application/alto-costmap+json", "accepts": "application/alto-costmapfilter+json", "uses": ["default-network-map"], "immediate-uses": [{ "media-type": "application/alto-propmap+json", "accepts": "application/alto-propmapparams+json", "capabilities": { "domain-types": ["ane"], "prop-types": ["availbw"] } }], "capabilities": { "max-cost-types": 1, "cost-type-names": ["pv-ane"], "client-constraint-map": true } }, "default-endpoint-cost-map": { "uri": "http://alto.example.com/endpointcost/lookup", "media-type": "application/alto-endpointcostmap+json", "accepts": "application/alto-endpointcostparams+json", "immediate-uses": [{ "media-type": "application/alto-propmap+json", "accepts": "application/alto-propmapparams+json", "capabilities": { "domain-types": ["ane"], "prop-types": ["availbw"] } }], "capabilities": { "max-cost-types": 1, "cost-type-names": ["pv-ane"], "client-constraint-map": true } } } } 6.4.2. Filtered Cost Map Example Assume we use the example in Section 2 and PID1-PID4 are mapped to eh1-eh4 respectively. POST /costmap/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 Gao, et al. Expires December 31, 2017 [Page 14] Internet-Draft Routing State Abstraction June 2017 { "cost-type": { "cost-mode": "path-vector", "cost-metric": "ane" }, "pids": { "srcs": ["PID1", "PID3"], "dsts": ["PID2", "PID4"] }, "client-constraint-map": { "PID1": [ "PID2": 40, "PID4": 0 ], "PID3": [ "PID2": 50, "PID4": 50 ] } } HTTP/1.1 200 OK Content-Length: [TBD] Content-Type: application/alto-costmap+json Gao, et al. Expires December 31, 2017 [Page 15] Internet-Draft Routing State Abstraction June 2017 { "meta": { "dependent-vtags": [ { "resource-id": "my-default-network-map", "tag": "75ed013b3cb58f896e839582504f622838ce670f" } ], "immediate-dependent-vtags": [ { "resource-id": "nep-map-bf74bb", "tag": "2e72381e57e30eff7e607131f0e095057e46aa8f", "time-out": 360 } ] "cost-type": { "cost-mode": "path-vector", "cost-metric": "ane" }, }, "cost-map": { "PID1": { "PID2": [ "ane:1" ] }, "PID3": { "PID2": [ "ane:1" ], "PID4": [ "ane:1" ] } } } Since the bandwidth for all links is 100 Mbps, it can be easily concluded that only link5 can potentially become a bottleneck with the given client constraints. Thus, only one abstract network element is returned. 6.4.3. Endpoint Cost Service Example Assume we use the example in Section 2 and eh1-eh4 are associated with IP addresses 192.0.2.1-192.0.2.4 respectively. 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 Gao, et al. Expires December 31, 2017 [Page 16] Internet-Draft Routing State Abstraction June 2017 { "cost-type": { "cost-mode": "path-vector", "cost-metric": "ane" }, "endpoints": { "srcs": ["ipv4:192.0.2.1", "ipv4:192.0.2.3"], "dsts": ["ipv4:192.0.2.2", "ipv4:192.0.2.4"] }, "client-constraint-map": { "ipv4:192.0.2.1": [ "ipv4:192.0.2.2": 40, "ipv4:192.0.2.4": 0 ], "ipv4:192.0.2.3": [ "ipv4:192.0.2.2": 50, "ipv4:192.0.2.4": 50 ] } } HTTP/1.1 200 OK Content-Length: [TBD] Content-Type: application/alto-endpointcost+json { "meta": { "immediate-dependent-vtags": [ { "resource-id": "nep-map-6a2a22", "tag": "a911354dfd1ef6555bfe7af07d3af0bfebe7c8a9", "time-out": 180 } ] "cost-type": { "cost-mode": "path-vector", "cost-metric": "ane" }, }, "endpoint-cost-map": { "ipv4:192.0.2.1": { "ipv4:192.0.2.2": [ "ane:1" ] }, "ipv4:192.0.2.3": { "ipv4:192.0.2.2": [ "ane:1" ], "ipv4:192.0.2.4": [ "ane:1" ] } } } Since the bandwidth for all links is 100 Mbps, it can be easily concluded that only link5 can potentially become a bottleneck with the given client constraints. Thus, only one abstract network element is returned. Gao, et al. Expires December 31, 2017 [Page 17] Internet-Draft Routing State Abstraction June 2017 6.5. Compatibility The client constraint map is fully compatible with path vector extension. For other extensions such as multi-cost [I-D.ietf-alto-multi-cost] and cost calendar [I-D.ietf-alto-cost-calendar], the input parameters MUST still follow the definition of "client-constraint-map" but can adjust the requirements for other fields. Since the client constraint map extension is fully compatible with the path vector extension, it does not alter the compatibility with other extensions such as multi-cost and cost calendar. 7. Security Considerations This document does not introduce any privacy or security issues on ALTO servers not already present in the ALTO protocol and in the path vector extension. The algorithms specified in this document can even help protect the privacy of network providers and improve the privacy when providing path vector services. The client constraint map extension defined in Section 6.3 can potentially leak client-side information to ALTO servers. ALTO client implementations MUST take information security into consideration when using this extension, for example, only activate this extension when the ALTO server is considered as a trusted party. ALTO clients can also obfuscate the information contained in a request, for example, providing larger values than actual constraints. Such obfuscation will not affect the correctness of the response but can have potentially larger communication overhead. 8. IANA Considerations This document does not define any new media types or introduce any new IANA considerations. 9. Acknowledgments The authors thank Prof. Jun Bi and Dr. Andreas Voellmy for their early engagement and discussions. Gao, et al. Expires December 31, 2017 [Page 18] Internet-Draft Routing State Abstraction June 2017 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, . 10.2. Informative References [I-D.ietf-alto-cost-calendar] Randriamasy, S., Yang, Y., Wu, Q., Lingli, D., and N. Schwan, "ALTO Cost Calendar", draft-ietf-alto-cost- calendar-01 (work in progress), February 2017. [I-D.ietf-alto-incr-update-sse] Roome, W. and Y. Yang, "ALTO Incremental Updates Using Server-Sent Events (SSE)", draft-ietf-alto-incr-update- sse-02 (work in progress), April 2016. [I-D.ietf-alto-multi-cost] Randriamasy, S., Roome, W., and N. Schwan, "Multi-Cost ALTO", draft-ietf-alto-multi-cost-10 (work in progress), April 2017. [I-D.ietf-alto-path-vector] Bernstein, G., Chen, S., Gao, K., Lee, Y., Roome, W., Scharf, M., Yang, Y., and J. Zhang, "ALTO Extension: Path Vector Cost Mode", draft-ietf-alto-path-vector-00 (work in progress), May 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, . Authors' Addresses Kai Gao Tsinghua University 30 Shuangqinglu Street Beijing 100084 China Email: gaok12@mails.tsinghua.edu.cn Gao, et al. Expires December 31, 2017 [Page 19] Internet-Draft Routing State Abstraction June 2017 Xin (Tony) Wang Tongji University 4800 CaoAn Road Shanghai 210000 China Email: xinwang2014@hotmail.com Chen Gu Tongji University 4800 CaoAn Road Shanghai 210000 China Email: gc19931011jy@gmail.com Y. Richard Yang Yale University 51 Prospect St New Haven CT USA Email: yry@cs.yale.edu G. Robert Chen Huawei Nanjing China Email: chenguohai@huawei.com Gao, et al. Expires December 31, 2017 [Page 20]