ALTO S. Randriamasy Internet-Draft Nokia Bell Labs Intended status: Standards Track March 9, 2020 Expires: September 10, 2020 ALTO Contextual Cost Values draft-randriamasy-alto-cost-context-03 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 one JSON value for a requested metric. This document introduces several protocol extensions to allow ALTO clients to support use cases such as context based connection selection in cellular networks and calendaring for unattended data. This document refers to other extension proposals posted in the ALTO WG that can support the present use cases as well. Likewise, some of the proposed extensions may serve other ALTO use cases. 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 https://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 September 10, 2020. Randriamasy Expires September 10, 2020 [Page 1] Internet-Draft Abbreviated-Title March 2020 Copyright Notice Copyright (c) 2020 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 (https://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. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Use Case 1: conditional RF costs in cellular networks . . 4 2.2. Use case 2: access-aware endpoint selection . . . . . . . 5 3. Required ALTO extensions . . . . . . . . . . . . . . . . . . 6 4. Design options and examples . . . . . . . . . . . . . . . . . 7 4.1. Overview of context features . . . . . . . . . . . . . . 7 4.1.1. Applicable ALTO services . . . . . . . . . . . . . . 8 4.2. Example IRD . . . . . . . . . . . . . . . . . . . . . . . 8 4.3. Use case 1: Example scenario for the FCM Service . . . . 10 4.4. Design option: Network Map with cells as PIDs . . . . . . 11 4.4.1. Example: FCM Request for contextual 'ARFcost' . . . . 11 4.4.2. Example: FCM Response for contextual ARFcost . . . . 12 4.5. Use case 2: example ALTO transactions for the ECS . . . . 13 4.5.1. Use case 2: example with logical context parameter combinations . . . . . . . . . . . . . . . . . . . . 13 5. Deployment case: local ALTO Server cascaded with global ALTO Server . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 5.1. Cascaded ALTO Servers with one network map each . . . . . 16 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 9.1. Normative References . . . . . . . . . . . . . . . . . . 17 9.2. Informative References . . . . . . . . . . . . . . . . . 17 Appendix A. An Appendix . . . . . . . . . . . . . . . . . . . . 18 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18 Randriamasy Expires September 10, 2020 [Page 2] Internet-Draft Abbreviated-Title March 2020 1. Introduction The IETF ALTO protocol specified in [RFC7285] provides guidance to over the top applications which have to select one or several hosts or endpoints from a set of candidates that are able to provide a desired data resource, or which need some provider-centric insight on the cost of application paths to these endhosts. The ALTO Service has defined network and cost maps to provide basic network information, where the cost maps allow only one JSON value for a requested metric. This draft brings a use case where providing different values for the same cost metric can help in optimizing the application path selection. Typically, when an end host can connect to the network via multiple technologies or access points, the path performance for a metric may be accordingly impacted. The present draft proposes to extend the cost information specified in [RFC7285] by providing, for the same cost metric, several possible cost values. Which value to provide depends on qualitative criteria as opposed to quantitative criteria such as time. The purpose is to allow a finer grained decision on which application endpoint or sub network to access. Previous ALTO WG discussions have suggested introducing "the ability to "name" cost maps so that a single Information Resource Directory can link multiple cost maps with the same cost type to a single network map." The goal was to provide, for a given cost metric, multiple cost values depending on qualitative conditions named "circumstance", where a circumstance reflects a given policy. For applications such as video download or streaming, a user equipment (UE) may use [RFC7285] to choose the best possible application resource location. Currently, the insight of ALTO information on the path between a UE and a connection node (or say Endpoint) does not provide details below IP hops. However the major QoE challenges of wireless network users arise in the access network, that is, in the first hop between the UE and its one or more serving packet data network gateway (PGW). The path of a UE to its serving PGW(s) impacts the path to the content and thus the related QoE. Therefore, it is necessary to inform the UE, which could take the appropriate decisions w.r.t. the utilized access path. The access technology in current ALTO documents is accounted at the content location (last hop) side by distinguishing whether the requested content is located in a fixed or a wireless access network, as described in [draft-ietf-alto-deployment] Randriamasy Expires September 10, 2020 [Page 3] Internet-Draft Abbreviated-Title March 2020 This document introduces several protocol extensions to allow ALTO clients to support use cases such as context-based connection selection in cellular networks and calendaring for unattended data. This document refers to other extension proposals posted in the ALTO WG that can support the present use cases as well. Likewise, some of the proposed extensions may serve other ALTO use cases. 2. Use cases This section presents motivating use cases for contextual ALTO Costs with a focus on conditional RF costs in cellular networks. In these 2 use cases, a terminal UE is located in a LTE network and associated to a "local" ALTO Server(LAOS) that covers this access network, say up to the Packet Data Network (PDN) Gateway PGW and can itself connect to another ALTO Server having a more global view covering up to the whole ISP network. Such a deployment is proposed in section Section 5 of this draft. 2.1. Use Case 1: conditional RF costs in cellular networks Let's assume a terminal UE located in a cellular network. An ALTO Client (LAOC) associated to the UE queries the local ALTO Server in order to know via which cell it should connect to the network. So in a first place, LAOC will query the connection cost associated to cells C1,.. CK. The present example assumes that the connection cost conveyed by the ALTO Server is a unitless value abstracting a non-real-time metric reflecting traffic conditions, aggregated over time and space. This metric aims at providing guidance to applications. It may integrate abstractions by the network provider, of actual costs impacted by other values such as congestion or available bandwidth are are assumed to be not easily available to UEs or applications otherwise. The ALTO Server does not aim at reporting accurate radio conditions that indeed vary in time and space. Let us call this metric: "ARF cost", standing for Abstracted RF cost. Our example however includes 2 additional considerations: - the ARF cost to a cell may be impacted by its load, - a UE usually transmits a fair amount of "unattended data" (UD). UD is considered in one of the key features for LTE enhancements in Release 13 and defined in 3GPP TS22.101 as follows: "Unattended Data Traffic : Data traffic of which the user is unaware he/she initiated, e.g. based on the screen/keypad lock being activated, length of time Randriamasy Expires September 10, 2020 [Page 4] Internet-Draft Abbreviated-Title March 2020 since the UE last received any input from the user, known type of app (e.g. an application monitoring a user's health "mHealth" may need its data never treated as Unattended Data Traffic.)". UD traffic is often delay tolerant and it would be beneficial for the network if the UE can schedule its transmission. To this end, the UE can use an instant UD Indicator (UDI) sent by the LTE network. The UDI, accepted for LTE Release 13 is a single bit sent to the UE indicating whether UD in a cell is allowed (UDA) or not (UDNA). The status change of a UDI from UDA to UDNA is presumably triggered when the cell load exceeds a given threshold T(udna). The value of T(udna) may change across cells and in time but is not provided to UEs. If the UE had an ALTO calendar for either T(udna) or for the abstracted cell load values, it could appropriately schedule the transmission of its UD, that will have to occur anyway. The UE could combine this calendar with the UDI it receives from the cellular network. The UDI state may change within sub-seconds and impact the data exchange. What is missing in the provided LTE information is: - knowing whether the UDI threshold relates to downlink or uplink congestion. - knowing the level of congestion that triggers a change in UDI and how it may evolve in time. The UE thus can advantageously combine the non-real time ALTO information with the real-time UDI provided by the LTE network. The present draft illustrates how ALTO can fill these gaps with the support of: - ALTO Cost Calendars, - the proposed protocol extension providing context-dependent ALTO Cost values. In this use case: ALTO calendars need to be requested via for the ALTO Filtered Cost Map (FCM) Service, the context parameters impacting the cost values are: "uda" (Unattended Data Allowed), "udna" (Unattended Data Not Allowed), "uplink", "downlink". 2.2. Use case 2: access-aware endpoint selection In a second use case, an end-system called UEP is located in a LTE network and may connect via several access technologies, e.g. Cellular or WiFi. UEP may also benefit from a given Service Level Agreement SLA-m. Other parameters may characterize the UEP generated traffic. Randriamasy Expires September 10, 2020 [Page 5] Internet-Draft Abbreviated-Title March 2020 Currently the insight of ALTO information in the path between a UE and a connection node (or say Endpoint) does not provide details below IP hops. However the major QoE challenges of wireless network users arise in the access network, that is, in the first hop between the UE and its one or more associated packet data network gateway (PGW). The path of a UE to its associated PGW(s) impacts the path to the content and thus the related QoE. Therefore, it is necessary to inform the UE, which could take the appropriate decisions w.r.t. the utilized access path. The access technology in current ALTO proposals is accounted at the content location (last hop) side by distinguishing whether the requested content is located in a fixed or a wireless access network, as described in [draft-ietf-alto- deployments] that states: "For ISPs with mobile network and fixed network, the traffic optimizing problems they focus will be optimizing the mobile traffic, except problems on last hop section." For Mobile Network Operators (MNO) and their users, being connected via e.g. cellular or trusted Wifi can hugely impact the QoE and routing cost. Sometimes a 4G connection is preferable for users than a poor WiFi connection although potentially more expensive. Sometimes, MNOs have spare data resources or offer them for given SLAs. For both parties, access-aware Endpoint selection for Users is thus beneficial. One way to achieve this is that ALTO provides cost values depending on qualitative contextual parameters such as access technology and the access technology and SLA. 3. Required ALTO extensions The aforementioned use cases can be supported with a few simple extensions to the ALTO protocol. A number of them have already been discussed in other WG drafts and use cases. The proposed extensions include: - Cost value context parameters: a capability to allow exposing several possible context-dependent values for one metric, as proposed in the present document, - Entities with associated domain and properties for cellular and wireless networks, that could be added to [draft-roome-alto-unified-props], - Cost metrics for cellular and wireless networks: these features would extend current proposals in the WG, that could be added to [draft-ietf-alto-performance-metrics], - Extended input for the Filtered Cost Map Service: to allow the input to comprise several(source-array, destination-array) pairs, as it has been proposed in [draft-yang-alto-path-vector]. Randriamasy Expires September 10, 2020 [Page 6] Internet-Draft Abbreviated-Title March 2020 4. Design options and examples Similarly to Multi-Cost and Cost Calendar ( [draft-ietf-alto-cost-calendar]), this proposal does not introduce new cost modes or new media-types. It ensures backwards compatibility with legacy ALTO Clients, that is: "A legacy ALTO Client must be able to send legacy requests to a Cost Context aware ALTO Server and get legacy responses as specified in RFC7285". "A Cost Context aware ALTO Server must be able to receive and process requests sent by legacy ALTO Clients, as specified in RFC 7285". Besides, the proposed extension is designed to be compatible with Multi-Cost ALTO and ALTO Cost Calendars ([draft-ietf-alto-cost-calendar]). In the present draft version, the IRD indicates the supported context attributes as values encoded in JSON strings. This design simplifies the transactions, as it allows a limited number of context attributes or their combinations, say 1 to 5. Context attributes taking numerous or unpredictable values should be handled as values properties or metrics expressed in constraints. - A cost context aware ALTO Server MUST provide metric values, as specified in RFC 7285, without any context consideration for all the Cost Types indicated in its "meta". 4.1. Overview of context features Cost context attributes are strings with values such as "wifi", "cellular", "uda". Cost context attributes are indicated in the IRD as capabilities of an information resource. They are associated to cost type names. - A cost context aware ALTO may indicate in its IRD capabilities, whether and how context attributes may be combined in ALTO requests. - A cost context aware ALTO Server MUST return metric values, without any context consideration, as specified in RFC 7285, if the value for a context attribute or a combination of attributes requested by the client is not available. - A cost context aware ALTO may indicate a maximum number of context attributes ot their combinations authorised in context-aware Client requests. Randriamasy Expires September 10, 2020 [Page 7] Internet-Draft Abbreviated-Title March 2020 4.1.1. Applicable ALTO services Draft [draft-bertz-alto-mobilitynets] proposes to identify network points of attachment (PoA) such as cells to PIDs, as PoAs are endpoint types not currently supported in ALTO. The current proposal is to represent cellular PIDs in an ALTO Network Map with no routes. PID properties as specified in [draft-roome-alto-unified-props] could be used to indicate the type of the PoA, together with other properties. ALTO properties are well suited for almost static attributes such as access type. To abstract and convey connection properties with frequently changing values such as ARF Cost, load or congestion, the ALTO Filtered Cost Map service can be used. Connection properties may also be conveyed with the Endpoint property service or its extensions defined in [draft-roome-alto-unified-props]. Costs and properties with the extensions proposed in this document may be conveyed with different values depending on the context parameter. The present version of this draft focuses on context parameters associated to costs. 4.2. Example IRD The purpose of ALTO is to guide the behavior of the end systems or applications without the need for networks to explicitly expose their performance values. In this example, the IRD does not expose the real load percentage of a cell to UE. Instead, it abstracts the cell congestion by a metric called 'ARFcost' represented by a number between 0 and 100, where the optimal value is 0. The values of 'ARFcost' are provided as an ALTO Calendar as specified in [draft- ietf-alto-cost-calendar-00] in shorter time intervals. In addition they differ, depending on the context values "uda" and "udna". Besides, the IRD provides metric 'routingcost' as a MUST specified in [RFC7285], that may represent a more administrative or monetary access cost. The IRD could publish the capability of a resource to provide context dependent 'routingcost' values as expressed for resource "filtered- cost-calendar-map". Randriamasy Expires September 10, 2020 [Page 8] Internet-Draft Abbreviated-Title March 2020 HTTP/1.1 200 OK Content-Length: [TODO] Content-Type: application/alto-directory+json { "meta" : { "cost-types": { "num-routingcost": { "cost-mode" : "numerical", "cost-metric" : "routingcost" }, "num-ARFcost": { "cost-mode" : "numerical", "cost-metric": "ARFcost", } } ... other meta ... }, "resources" : { "filtered-cost-calendar-map" : { "uri" : "http://alto.local.example.com/costmap/filtered/calendar/context", "media-types" : [ "application/alto-endpointcost+json" ], "accepts" : [ "application/alto-endpointcostparams+json" ], "capabilities" : { "cost-constraints" : true, "cost-type-names" : [ "num-routingcost", "num-ARFcost"],// ++NEW "calendar-attributes" : [ {"cost-type-names" : "num-routingcost", "time-interval-size" : "1 hour", "number-of-intervals" : 24}, // MAY ALSO BE SINGLE VALUE {"cost-type-names" : "num-ARFcost", // ++NEW "time-interval-size" : "5 minute", "number-of-intervals" : 12} ], "cost-context" : [ // ++NEW {"cost-type-names" : "num-ARFcost", "context-params" : [["uda", "udna"], ["uplink", "downlink"]] } ], // ++NEW "max-context-attributes" : 10, "uses": [ "my-default-network-map" ] } // end FCM capab ... other resources ... } // end resources } // end IRD Randriamasy Expires September 10, 2020 [Page 9] Internet-Draft Abbreviated-Title March 2020 4.3. Use case 1: Example scenario for the FCM Service We assume an example scenario where a UE has the choice to connect to 2 cells C1 and C2. As suggested in [draft-bertz-alto-mobilitynets], we may represent the cellular topology with an ALTO Network Map comprising PIDs representing the cells and named "Cell1", "Cell2", ... "Celln". A format for a cell identifier has been proposed in [draft-rauschenbach-alto-wireless-access] and is not being discussed here. As a Network Map may cover a large number of cells, the Filtered Cost Map Service can be used to reduce data exchange and get information on a restricted number of cells. We assume that the ALTO Client in the UE wants to get calendared values for ALTO metric "ARFcost" in order to appropriately schedule its unattended data transmission. The ALTO information resource 'ALTO Calendar' provides an array of time-dependent cost values and is being specified in [draft-ietf-alto-cost-calendar]. In addition, the ALTO Client wants these values for both the "uda" and "udna" context. Last, we assume that the UE needs the Cost values for both the uplink (UE to Cell-k) and downlink (Cell-k to UE) directions. We assume that the UE is located in the PID called "Cell1". In this scenario, Cell1 is limited by its uplink capacity and Cell2 is limited by its downlink capacity. ALTO can be used to convey the following information: At time interval T1 of the next Calendar: - if Cell1 indicates "unattended data allowed" the downlink ARF cost is 20, and the uplink ARF cost is 70 - if Cell1 indicates "unattended data NOT allowed", the downlink ARF cost is 20, and the uplink ARF cost is 90 - if Cell2 indicates "unattended data allowed" the downlink ARF cost is 70, and the uplink ARF cost is 20 - if Cell2 indicates "unattended data NOT allowed", the downlink ARF cost is 90, in the uplink ARF cost is 20. The ALTO Calendar provides values for the other 11 time intervals Ti. Randriamasy Expires September 10, 2020 [Page 10] Internet-Draft Abbreviated-Title March 2020 4.4. Design option: Network Map with cells as PIDs In this design, the cellular topology is represented with an ALTO Network Map comprising PIDs named "Cell1", "Cell2", ... "Celln". The UE is located in one of these PIDs. A Cost Map is associated to this Network Map and conveys metrics indicated in the IRD. The Cost Map can be to convey connection costs between firstly the UE to its serving cell (that is the PID to itself) and secondly the UE and neighboring cells (that is the PID to another one) and last, for both uplink and downlink directions. The ALTO Server can regularly update the Cost Map and send filtered information to the ALTO Client. The proposed IRD design announces additional context attributes "uplink", "downlink". In this case and other potential cases, the context parameters need to be arranged w.r.t. their possible combinations (to be further specified in the IRD). For example, the IRD may announce that costs are provided for contexts "uda" and "udna" and this in both contexts "uplink" and "downlink". Or that costs are provided for contexts "uplink" and "downlink" and this in both contexts "udna" and "uda". In such a case, the IRD capability member may list the possible combinations in the capabilities as follows: "cost-context" : [ // ++NEW { "cost-type-names" : "num-ARFcost", "context-params" : [["uda", "uplink"], ["uda", "downlink"], ["udna", "uplink"], ["udna", "downlink"]] // ++NEW } ] This arrangement indicates that for the metric named "num-ARFcost", the ALTO Server can provide 4 different values: v1 for ["uda" AND "uplink"], ... v4 for ["udna" AND "downlink"]. Further versions of this draft will specify more elaborated logical combinations of context attribues, to moderate the length of the ALTO request and support use cases as described in section 4.5.1. 4.4.1. Example: FCM Request for contextual 'ARFcost' The ALTO Client can specify the desired cost value context parameters in the request input. In particular, it can select one or more combinations indicated in the IRD. Its input parameter "context- params" is an array of all the desired combinations. In this Randriamasy Expires September 10, 2020 [Page 11] Internet-Draft Abbreviated-Title March 2020 example, the ALTO Client wants to know the ALTO connection costs within Cell1 and Cell2. For each cell, the Client wants the 4 values, corresponding to all the combinations indicated below. POST /costmap/filtered/calendar/context HTTP/1.1 Host: alto.example.com Accept: application/alto-costmap+json,application/alto-error+json Content-Type: application/alto-costmapfilter+json Content-Length: ### { "cost-type" : { "cost-mode": "numerical", "cost-metric": "ARFcost"}, "calendared" : true, "context-params" : [["uda", "uplink"], // ++NEW ["uda", "downlink"], ["udna", "uplink"], ["udna", "downlink"]], "pids" : [ {"srcs" : [ "Cell1"], "dsts" : [ "Cell1"]}, {"srcs" : [ "Cell2"], "dsts" : [ "Cell2"]} ] } 4.4.2. Example: FCM Response for contextual ARFcost The ALTO response provides, for each requested ("src", "dest") pair, a calendar of 12 JSON values, where each is an array of cost values arranged as specified in the "meta" of the ALTO response. Randriamasy Expires September 10, 2020 [Page 12] Internet-Draft Abbreviated-Title March 2020 HTTP/1.1 200 OK Content-Type: application/alto-costmap+json Content-Length: ### { "meta" : { "dependent-vtags" : [ {"resource-id": "my-default-network-map", "tag": "3ee2cb7e8d63d9fab71b9b34cbf764436315542e" } ], "cost-type" : {"cost-mode": "numerical", "cost-metric": "ARFcost"}, "calendar-response-attributes" : { "calendar-start-time" : Tue, 1 Sept 2016 13:00:00 GMT, "time-interval-size" : "5 minute", "numb-intervals" : 12}, "context-params" : [["uda", "uplink"], // ++NEW ["uda", "downlink"], ["udna", "uplink"], ["udna", "downlink"]] } // end meta "cost-map" : { "Cell1": { "Cell1": [[70, 20, 90, 20], ... ,[50, 20, 70, 20]], "Cell2": { "Cell2": [[20, 70, 20, 90], ... ,[20, 50, 20, 70]] } } 4.5. Use case 2: example ALTO transactions for the ECS In this use case, the UE requests the ECS to a local ALTO server for the routingcost to the PGW and wants the metric values varying w.r.t. the "access-type" and "SLA-id". Note that the "context" related design feature can be easily transposed for the Cost Map Service. 4.5.1. Use case 2: example with logical context parameter combinations This section proposes a design, allowing a Client to arrange input context parameters in logical combinations. The purpose is to show how such combinations of context parameters avoids specifying as many metrics and moderates the amount of exchanged data. In this example the ALTO Server indicates in its IRD that it can provide endpoint cost maps for the example metrics "routingcost" and "bandwidthscore". Values for metric "routingcost" are provided w.r.t. 2 types of context parameters. The ALTO Client may query values for metric "routingcost" for either of these types of parameters or both or none. Randriamasy Expires September 10, 2020 [Page 13] Internet-Draft Abbreviated-Title March 2020 For each type, the parameters are listed in an array. We have 2 arrays: - ["cell", "wifi", "lan"] - ["SLA-1", "SLA-2", "SLA-3"] This indicates that in each array, the client can pick one or more parameters and combine them with one or more parameters in the second array. The ALTO Server will provide costs w.r.t. the AND combination across and within arrays. In the present example, if the Client requests cost values for the combination: [["cell", "wifi"], ["SLA-3"]] The server will provide 2 values: one for ("cell" AND "SLA-3")and the second one for ("wifi" and "SLA"-3"). 4.5.1.1. Example IRD with logical context parameter combinations The IRD below specifies the possibility to combine parameters from the two arrays of the example above. "resources" : { "filtered-cost-calendar-map" : { "uri" : "http://alto.local.example.com/endpointcostmap/lookup/context", "media-types" : [ "application/alto-endpointcost+json" ], "accepts" : [ "application/alto-endpointcostparams+json" ], "capabilities" : { "cost-constraints" : true, "cost-type-names" : [ "num-routingcost", "num-bandwidthscore"], "cost-context" : [// ++NEW {"cost-type-names" : "num-routingcost", "context-params" : [["cell", "wifi", "lan"], ["SLA-1", "SLA-2", "SLA-3"]] } ] } // end ECM capab ... other resources ... } // end resources Randriamasy Expires September 10, 2020 [Page 14] Internet-Draft Abbreviated-Title March 2020 4.5.1.2. Use case 2: example ECS request with logical context parameter combinations The ALTO Client queries the ECS between 2 endpoints for the following combinations: ("cell" AND "SLA-3")and ("wifi" and "SLA"-3") and thus arranges its input context parameters as follows: POST /endpointcost/lookup/context HTTP/1.1 Host: alto.local.example.com Content-Length: [TODO] Content-Type: application/alto-endpointcostparams+json Accept: application/alto-endpointcost+json,application/alto-error+json { "cost-type" : {"cost-mode" : "numerical", "cost-metric" : "routingcost"}, "context-params" : [["cell", "wifi"], ["SLA-3"]], "endpoints" : { "srcs": [ "ipv4:192.0.2.2" ], "dsts": [ "ipv4:192.0.2.89", "ipv6:2000::1:2345:6789:abcd" ] } } 4.5.1.3. Use case 2: example ECS response with logical context parameter combinations Following the ALTO Client request of the above example, The ALTO Server provides a response as follows: Randriamasy Expires September 10, 2020 [Page 15] Internet-Draft Abbreviated-Title March 2020 HTTP/1.1 200 OK Content-Length: [TODO] Content-Type: application/alto-endpointcost+json { "meta" : { "cost-type" : {"cost-mode" : "numerical", "cost-metric" : "routingcost"}, "context-params" : [["cell", "wifi"], ["SLA-3"]] } // end meta "endpoint-cost-map" : { "ipv4:192.0.2.2": { "ipv4:192.0.2.89" : [10, 4], "ipv6:2000::1:2345:6789:abcd" : [4, 6] } } } 5. Deployment case: local ALTO Server cascaded with global ALTO Server To maintain scalability, the ALTO coverage network zone can be decomposed in one "local" ALTO Server part covering a restricted local network zone, for instance within the first IP hop range and another "global" part covering the rest of the ISP network, similarly to what is proposed in [draft-ietf-alto-deployments]. The local ALTO server may include the guidance given by the ISP ALTO server and compose it with the "global" guidance in its replies to its ALTO clients. Recent ALTO WG discussions open the possibility for one IRD to indicate multiple network maps having different levels of detail. 5.1. Cascaded ALTO Servers with one network map each In the "cascaded" use case, the ALTO Service is preferably distributed among two ALTO Servers as follows: The ALTO Client serving the UE is referred to as the LAOC and can be located either in the UE or in the network. 1. A Local ALTO Server (LAOS) * Hosts the information on the local EPS network, covering the paths between e.g. the UEs and the cells or the PGWs, * Hosts an ALTO Client that sends an ALTO request to a "global" ALTO Server, covering the zone beyond the PGW. It can possibly get the global Server updates using the extensions specified in [draft-ietf-alto-incr-update-sse]. Randriamasy Expires September 10, 2020 [Page 16] Internet-Draft Abbreviated-Title March 2020 * receives the ALTO request issued by the ALTO Client associated to the UE. 2. a "core" ALTO Server covers the whole ISP network view, as it would if the "local ALTO Service" is not available or deactivated. 6. IANA Considerations This document makes no request of IANA. Note to RFC Editor: this section may be removed on publication as an RFC. 7. Security Considerations 8. Acknowledgements Many thanks to Dawn Chan, Li Geng, Xin Wan, Yichen Qian for their feedback on this draft. 9. References 9.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, . [RFC7285] Alimi, R., Penno, R., Yang, Y., Kiesel, S., Previdi, S., Roome, W., Shalunov, S., and R. Woundy, "Application-Layer Traffic Optimization (ALTO) Protocol", RFC 7285, September 2014. 9.2. Informative References [draft-bertz-alto-mobilitynets] Bertz, L., "Mobility Network Models in ALTO", October 2015. [draft-ietf-alto-cost-calendar] Randriamasy, S., Yang, Y., Wu, Q., Deng, L., and N. Schwan, "ALTO Cost Calendar", February 2017. [draft-ietf-alto-deployment] Stiemerling, M., Kiesel, S., Scharf, M., Seidel, H., and S. Previdi, "draft-ietf-alto-deployments-16", July 2016. Randriamasy Expires September 10, 2020 [Page 17] Internet-Draft Abbreviated-Title March 2020 [draft-ietf-alto-incr-update-sse] Roome, W. and Y. Yang, "ALTO Incremental Updates Using Server-Sent Events (SSE)", Septembre 2016. [draft-ietf-alto-performance-metrics] Wu, Q., Yang, Y., Lee, Y., Dhody, D., and S. Randriamasy, "ALTO Performance Cost Metrics", March 2017. [draft-rauschenbach-alto-wireless-access] Rauschenbach, U., "ALTO in wireless access networks", October 2014. [draft-roome-alto-unified-props] Roome, W., "Extensible Property Maps for the ALTO Protocol", July 2016. [draft-yang-alto-path-vector] Bernstein, G., Gao, K., Lee, Y., Roome, W., Scharf, M., and Y. Yang, "ALTO Extension: Path Vector Cost Mode", July 2016. Appendix A. An Appendix Author's Address Sabine Randriamasy Nokia Bell Labs Route de Villejust Nozay 91460 FRANCE Email: sabine.randriamasy@nokia-bell-labs.com Randriamasy Expires September 10, 2020 [Page 18]