ALTO S. Randriamasy Internet-Draft Nokia Bell Labs Intended status: Experimental November 15, 2016 Expires: May 19, 2017 ALTO Contextual Cost Values draft-randriamasy-alto-cost-context-00 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 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 May 19, 2017. Randriamasy Expires May 19, 2017 [Page 1] Internet-Draft Abbreviated-Title November 2016 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 . . . . . . . . . . . . . . . . . . . . . . . . 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 cost context features . . . . . . . . . . . . 7 4.1.1. Applicable ALTO services . . . . . . . . . . . . . . 7 4.2. Example IRD . . . . . . . . . . . . . . . . . . . . . . . 8 4.3. Use case 1: Example scenario for the FCM Service . . . . 10 4.4. Design option1: uniform Network Map with cells as PIDs . 11 4.4.1. Uniform Network Map: FCM Request for contextual 'RFcost' . . . . . . . . . . . . . . . . . . . . . . 11 4.4.2. Uniform Network Map: FCM Response for contextual RFcost . . . . . . . . . . . . . . . . . . . . . . . 12 4.5. Design option2 Mixed Network Map: with cells as PIDs and UE as a dummy PID . . . . . . . . . . . . . . . . . . . . 13 4.5.1. Mixed Network Map: FCM Request for contextual 'RFcost' . . . . . . . . . . . . . . . . . . . . . . 14 4.5.2. FCM Response for contextual RFcost . . . . . . . . . 14 4.6. Use case 2: example ALTO transactions for the ECS . . . . 15 4.6.1. Use case 2: Example IRD . . . . . . . . . . . . . . . 15 4.6.2. Use case 2: example ECS request . . . . . . . . . . . 16 4.6.3. Use case 2: example ECS response . . . . . . . . . . 16 5. Deployment case: local ALTO Server cascaded with global ALTO Server . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 5.1. Cascaded ALTO Servers with one network map each . . . . . 17 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 Randriamasy Expires May 19, 2017 [Page 2] Internet-Draft Abbreviated-Title November 2016 9.1. Normative References . . . . . . . . . . . . . . . . . . 18 9.2. Informative References . . . . . . . . . . . . . . . . . 18 Appendix A. An Appendix . . . . . . . . . . . . . . . . . . . . 19 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19 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 a 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 a 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 to introduce "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 Randriamasy Expires May 19, 2017 [Page 3] Internet-Draft Abbreviated-Title November 2016 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] 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. This example assumes that this cost is a unitless value abstracting a (RF) cost to a cell. Our example however includes 2 additional considerations: - the RF 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 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, Randriamasy Expires May 19, 2017 [Page 4] Internet-Draft Abbreviated-Title November 2016 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 advatageously 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. 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 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 Randriamasy Expires May 19, 2017 [Page 5] Internet-Draft Abbreviated-Title November 2016 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 aforementionned 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: a capability to allow exposing several possible context-dependent values for one metric. - Cost metrics, Network Maps and Cost Maps, PID properties for cellular and wireless networks: these topics would extend current proposals in the WG, - Availability of Filtered Cost Map Service for ALTO Cost Calendars: the FCM Service for ALTO Cost Calendars will have to be specified in next versions of [draft-ietf-alto-cost-calendar] that is in progress. - 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]. - Extensions to section 11.2.2 of [RFC7285] on mapping IP addresses to PIDs : one cellular network map design proposed in this draft requires the possibility to associate a UE to two PIDs . Randriamasy Expires May 19, 2017 [Page 6] Internet-Draft Abbreviated-Title November 2016 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 parameters as values encoded in JSON strings. The idea is that this design simplifies the transactions, as it applies to context attributes that take a limited number of values, say 1 to 5. Context attributes taking numerous or unpredictible values should be handled as values properties or metrics expressed in constraints. 4.1. Overview of cost 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. 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 propeties as specified in [draft-roome-alto-unified-props-01] could be used to indicate the Endpoint type of the PoA, together with other properties. Such an approach is suitable for properties with constant-like values such as access type. However when ALTO is used to indicate connection properties with changing values such as RF Cost congestion, using Filtered Cost Maps is preferable. Randriamasy Expires May 19, 2017 [Page 7] Internet-Draft Abbreviated-Title November 2016 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 explicitely 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 'RFcost' represented by a number between 0 and 100. The values of 'RFcost' are provided as a an ALTO Calendar as specified in [draft-ietf-alto-cost-calendar-00] in shorter time intervals. In addition they differ, depending on the the context values "uda" and "udna". Besides, the IRD provides metric 'routingcost' as a MUST specfied 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 May 19, 2017 [Page 8] Internet-Draft Abbreviated-Title November 2016 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-RFcost": { "cost-mode" : "numerical", "cost-metric": "RFcost", } } ... 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-RFcost"],// ++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-RFcost", // ++NEW "time-interval-size" : "5 minute", "number-of-intervals" : 12} ], "cost-context" : [ // ++NEW {"cost-type-names" : "num-RFcost", "context-params" : ["uda", "udna", "uplink", "downlink"] } ] // ++NEW "uses": [ "my-default-network-map" ] } // end ECM capab ... other resources ... } // end resources } // end IRD Randriamasy Expires May 19, 2017 [Page 9] Internet-Draft Abbreviated-Title November 2016 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, say PID1 and PID2. We assume that the ALTO Client in the UE wants to get calendared values for ALTO metric "RFcost" 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, C1 is limited by its uplink capacity, C2 is limited by its downlink capacity. ALTO can be used to convey the following information: At time interval T1 of the next Calendar: - if C1 indicates "unattended data allowed" the downlink RF cost is 20, and the uplink RF cost is 70 - if C1 indicates "unattended data NOT allowed", the downlink RF cost is 20, and the uplink RF cost is 90 - if C2 indicates "unattended data allowed" the downlink RF cost is 70, and the uplink RF cost is 20 - if C2 indicates "unattended data NOT allowed", the downlink RF cost is 90, in the uplink RF cost is 20. The ALTO Calendar provides values for the other 11 time intervals Ti. Randriamasy Expires May 19, 2017 [Page 10] Internet-Draft Abbreviated-Title November 2016 4.4. Design option1: uniform 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 is requested 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-RFcost", "context-params"[["uda", "uplink"], ["uda", "downlink"], ["udna", "uplink"], ["udna", "downlink"]] // ++NEW } ] This arrangement indicates that for the metric named "num-RFcost", the ALTO Server can provide 4 different values: v1 for ["uda" AND "uplink"], ... v4 for ["udna" AND "downlink"]. 4.4.1. Uniform Network Map: FCM Request for contextual 'RFcost' 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 "cost- context-params" is an array of all the desired combinations. In this example, the ALTO Client wants 4 values corresponding to the combinations. Randriamasy Expires May 19, 2017 [Page 11] Internet-Draft Abbreviated-Title November 2016 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": "RFcost"}, "calendared" : true, "context-params" : [["uda", "uplink"], ["uda", "downlink"], ["udna", "uplink"], ["udna", "downlink"]], // ++NEW "pids" : [ {"srcs" : [ "Cell1"], "dsts" : [ "Cell1", "Cell2"]}, {"srcs" : [ "Cell2"], "dsts" : [ "Cell1", "Cell2"]} ] } 4.4.2. Uniform Network Map: FCM Response for contextual RFcost The ALTO response provides, for each requested ("src", "dest") pair, a calendar of 12 JSON values, where each value corresponds to an arrangement specified in the "meta" of the ALTO response. Randriamasy Expires May 19, 2017 [Page 12] Internet-Draft Abbreviated-Title November 2016 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": "RFcost"}, "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"], ["uda", "downlink"], ["udna", "uplink"], ["udna", "downlink"]] // ++NEW } // end meta "cost-map" : { "Cell1": { "Cell1": [[70, 20, 90, 20], ... ,[50, 20, 70, 20]], // ++NEW "Cell2": { "Cell2": [[20, 70, 20, 90], ... ,[20, 50, 20, 70]] // ++NEW } } 4.5. Design option2 Mixed Network Map: with cells as PIDs and UE as a dummy PID In this design, PIDs represents cells hosting several UEs and one of them is a dummy PID hosting a single UE, namely the one on behalf of which the ALTO Client requests a Calendar. Let's assume this PID is named "UE". The advantage of this design is that PID UE enables distiguishing costs in the uplink and downlink directions and thus spares the usage of the "uplink" and "downlink" context attributes. Indeed, ALTO provides directed path costs, so the values are implicitly provided for both the uplink (UE to Cell-k) and downlink (Cell-k to UE) directions. This design requires to extend section {11.2.2} of [RFC7285] with the possibility single addresses or other Endpoint identifiers to be mapped to several PIDs (2 in our case). Randriamasy Expires May 19, 2017 [Page 13] Internet-Draft Abbreviated-Title November 2016 4.5.1. Mixed Network Map: FCM Request for contextual 'RFcost' It is no more necessary for the ALTO Client to list ALTO cost context parameter "uplink" and "downlink" in the request input. Its input parameter "cost-context-params" is an array of all the desired combinations, where a combination can be a single parameter. In this example, the ALTO Client wants 2 values corresponding to the context parameters "uda" and "udna". 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": "RFcost"}, "calendared" : true, "context-params" : ["uda", "udna"], // ++NEW "pids" : [ {"srcs" : [ "UE"], "dsts" : [ "Cell1", "Cell2"]}, {"srcs" : [ "Cell1"], "dsts" : [ "UE"]}, {"srcs" : [ "Cell2"], "dsts" : [ "UE"]} ] } 4.5.2. FCM Response for contextual RFcost The ALTO response provides for each requested ("src", "dest") pair a calendar or 12 pairs of values, where each value of the pair corresponds to respectively "uda" and "udna". Randriamasy Expires May 19, 2017 [Page 14] Internet-Draft Abbreviated-Title November 2016 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": "RFcost"}, "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", "udna"] // ++NEW } "cost-map" : { "UE": { "Cell1": [[70, 90], ... ,[50, 70]], // ++NEW "Cell2": [[20, 20], ... ,[40, 60]] }, // ++NEW "Cell1": { "UE": [[20, 20], ... ,[20, 20]] }, // ++NEW "Cell2": { "UE": [[70, 90], ... ,[40, 60]] } // ++NEW } } 4.6. 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.6.1. Use case 2: Example IRD In this example the ALTO Server indicates in its IRD to provide endpoint cost maps for metrics "routingcost" and "bandwidthscore". Values for metric "routingcost" are provides w.r.t. contextual attributes. The ALTO Client may query values for metric "routingcost" for either of these parameters or both. In this example, the context dependent values are provided for metrics otherwise provided as single values as specified in [RFC7285] Randriamasy Expires May 19, 2017 [Page 15] Internet-Draft Abbreviated-Title November 2016 "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"] } // ++NEW ] } // end ECM capab ... other resources ... } // end resources 4.6.2. Use case 2: example ECS request Example ECS request between 2 endpoints 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.6.3. Use case 2: example ECS response Randriamasy Expires May 19, 2017 [Page 16] Internet-Draft Abbreviated-Title November 2016 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, "SLA-3"], "ipv6:2000::1:2345:6789:abcd" : [4, 6, "SLA-3"] } } } 5. Deployment case: local ALTO Server cascaded with global ALTO Server To maintain scalability, the initial assumption was that the ALTO coverage network zone is decomposed in one local ALTO Server part covering a restricted local network zone, for instance within the first IP hop range and the other part covering the rest of the ISP network, similarly to what is proposed in [draft-ietf-alto- deployments]. The local ALTO server may thus include the guidance given by the ISP ALTO server and compose both views 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 Randriamasy Expires May 19, 2017 [Page 17] Internet-Draft Abbreviated-Title November 2016 possibly get the global Server updates using the extensions specified in [draft-ietf-alto-incr-update-sse]. * 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 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", August 2016. [draft-ietf-alto-deployment] Stiemerling, M., Kiesel, S., Scharf, M., Seidel, H., and S. Previdi, "draft-ietf-alto-deployments-16", July 2016. Randriamasy Expires May 19, 2017 [Page 18] Internet-Draft Abbreviated-Title November 2016 [draft-ietf-alto-incr-update-sse] Roome, W. and Y. Yang, "ALTO Cost Calendar", Septembre 2016. [draft-rauschenbach-alto-wireless-access] Rauschenbach, U., "ALTO in wireless access networks", October 2014. [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 May 19, 2017 [Page 19]