ALTO S. Randriamasy
Internet-Draft Nokia Bell Labs
Intended status: Standards Track March 13, 2017
Expires: September 14, 2017
ALTO Contextual Cost Values
draft-randriamasy-alto-cost-context-01
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 September 14, 2017.
Randriamasy Expires September 14, 2017 [Page 1]
Internet-Draft Abbreviated-Title March 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. 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 . . . . . . . . . . . . . . . . . 6
4.1. Overview of context features . . . . . . . . . . . . . . 7
4.1.1. Applicable ALTO services . . . . . . . . . . . . . . 7
4.2. Example IRD . . . . . . . . . . . . . . . . . . . . . . . 7
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. Network Map: FCM Request for contextual 'RFcost' . . 11
4.4.2. Network Map: FCM Response for contextual RFcost . . . 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 14, 2017 [Page 2]
Internet-Draft Abbreviated-Title March 2017
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
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 14, 2017 [Page 3]
Internet-Draft Abbreviated-Title March 2017
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,
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
Randriamasy Expires September 14, 2017 [Page 4]
Internet-Draft Abbreviated-Title March 2017
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
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
Randriamasy Expires September 14, 2017 [Page 5]
Internet-Draft Abbreviated-Title March 2017
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 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].
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".
Randriamasy Expires September 14, 2017 [Page 6]
Internet-Draft Abbreviated-Title March 2017
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 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 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 indicate connection properties with frequently changing values
such as RF 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
patrameters 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 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
Randriamasy Expires September 14, 2017 [Page 7]
Internet-Draft Abbreviated-Title March 2017
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 September 14, 2017 [Page 8]
Internet-Draft Abbreviated-Title March 2017
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 September 14, 2017 [Page 9]
Internet-Draft Abbreviated-Title March 2017
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 September 14, 2017 [Page 10]
Internet-Draft Abbreviated-Title March 2017
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
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"].
Further versions may specify more elaborated logical combinations of
context parameters.
4.4.1. 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
Randriamasy Expires September 14, 2017 [Page 11]
Internet-Draft Abbreviated-Title March 2017
example, the ALTO Client wants 4 values, corresponding to all the
indicated combinations.
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"], // ++NEW
["uda", "downlink"],
["udna", "uplink"],
["udna", "downlink"]],
"pids" : [
{"srcs" : [ "Cell1"], "dsts" : [ "Cell1", "Cell2"]},
{"srcs" : [ "Cell2"], "dsts" : [ "Cell1", "Cell2"]}
]
}
4.4.2. 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 is an array of cost values
arranged as specified in the "meta" of the ALTO response.
Randriamasy Expires September 14, 2017 [Page 12]
Internet-Draft Abbreviated-Title March 2017
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"], // ++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 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 14, 2017 [Page 13]
Internet-Draft Abbreviated-Title March 2017
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
accross 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 14, 2017 [Page 14]
Internet-Draft Abbreviated-Title March 2017
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 14, 2017 [Page 15]
Internet-Draft Abbreviated-Title March 2017
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 14, 2017 [Page 16]
Internet-Draft Abbreviated-Title March 2017
* 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,
<http://www.rfc-editor.org/info/rfc2119>.
[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 14, 2017 [Page 17]
Internet-Draft Abbreviated-Title March 2017
[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 14, 2017 [Page 18]