Internet DRAFT - draft-randriamasy-alto-cost-value-name
draft-randriamasy-alto-cost-value-name
ALTO S. Randriamasy
Internet-Draft Alcatel-Lucent
Intended status: Experimental July 16, 2013
Expires: January 17, 2014
ALTO Cost Value Name
draft-randriamasy-alto-cost-value-name-00
Abstract
The IETF ALTO protocol provides guidance to content delivery
applications such as P2P or Content Delivery Networks (CDN), which
have to select one or several hosts or endpoints from a set of
candidates that are able to provide a desired data resource. This
guidance shall be based on parameters that affect performance and
efficiency of the data transmission between the hosts, for instance
the topological distance or the routing cost between them. To this
end, ALTO Servers deployed by Network Operators (NO), provide
requesting ALTO Clients with information, currently such as the NO-
centric view on the network topology, the candidate application
endpoints with attributes such as their connectivity type.
The present draft proposes to extend the cost information provided by
the ALTO protocol 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 given that their routing cost
values may depend on criteria suh as the access technology of the end
system consuming the resources or the policy applied for the client
requesting ALTO information.
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/.
Randriamasy Expires January 17, 2014 [Page 1]
Internet-Draft Abbreviated-Title July 2013
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 January 17, 2014.
Copyright Notice
Copyright (c) 2013 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. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Use Case for the EP Cost Service . . . . . . . . . . . . 3
1.2. Use case for the Cost Map Service . . . . . . . . . . . . 4
2. Applicable deployments for the ECS use case . . . . . . . . . 5
2.1. Cascaded ALTO Servers with one network map each . . . . . 5
2.2. One ALTO server with multi-level Network Maps . . . . . . 5
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
4. Security Considerations . . . . . . . . . . . . . . . . . . . 6
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
6.1. Normative References . . . . . . . . . . . . . . . . . . 6
6.2. Informative References . . . . . . . . . . . . . . . . . 6
Appendix A. An Appendix . . . . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6
1. Problem Statement
This draft brings a use case where providing different values for a
same cost type can help optimizing the Endpoint (EP) choice.
Typically when the path to this endpoint starts from a multi-
technology access network and the Endpoint Cost is impacted by which
access technology is used for the first hop from the terminal using
the EP resource.
Randriamasy Expires January 17, 2014 [Page 2]
Internet-Draft Abbreviated-Title July 2013
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 and cost mode to a
single network map." One goal was to provide, for a given Cost Type
and Mode, multiple cost maps depending on qualitative conditions that
named "circumstance". Where a circumstance reflects a given policy.
For applications such as video download or streaming, a user
equipment (UE) may use the IETF ALTO protocol, currently under
specification in [draft-ietf-alto-protocol] and whose design goal can
help it to choose the best possible application resource location.
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 among others for scalability reasons. 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-05] 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 3G or trusted Wifi can make a huge difference in the QoE and
routing cost. MNOs also seek to optimize their network load balance.
For both parties there is a need to push access technology (AT)
awareness of ALTO information one step ahead, in particular to enable
Radio AT aware Endpoint selection for Users located in wireless
network. One way to achieve this is that ALTO provides cost values
depending on the access technology used at the first hop. This
requires that the ALTO request is made with the awareness of the
applicable cost value category.
1.1. Use Case for the EP Cost Service
Let's assume a terminal sitting in a LTE network uses the Endpoint
Cost Service in an ALTO deployment scenario such as the Cascaded ALTO
Service described in section 6.1 of [draft-ietf-alto-deployments-06].
We may have a local ALTO Server reporting e.g. 'routingcost' to the
PDN Gateway with values depending on qualitative "circumstances" such
as cellular, trusted wifi access, SLA... and likely to significantly
Randriamasy Expires January 17, 2014 [Page 3]
Internet-Draft Abbreviated-Title July 2013
impact the QoE. The remaining cost from the PDN GW to the EP can be
calculated by a regular ALTO Server.
One way to support this is to introduce some cost attribute called
e.g. "value name". In an IRD it could be represented with an array
of 1 or more elements taking value "circumstanceN" of type "string".
In the IRD we may have something as follows (and modulo syntax
errors), with "circumstanceN" taking values such as "cellular",
"trusted-wifi", "policyX", "SLAtype"...
The IRD could publish a multi-valued routing cost as follows:
...
"capabilities" {
"cost-types" : ["routingcost"],
"value-name" : ["circumstance1", "circumstance2"], },
"media-types": [
"application/alto-endpointcost+json"
],
"uri": "http://custom.alto.ietf.org/endpointcost/rc-num/circumstance"
...
1.2. Use case for the Cost Map Service
For the Cost map Service: the IRD could publish multiple Cost Maps
for cost type 'routingcost' as follows.
...
"capabilities" {
"cost-types" : ["routingcost"],
"value-name" : ["circumstance1", "circumstance2"], },
"media-types": [
"application/alto-costmap+json"
],
"uri": "http://alto.ietf.org/costmap/routingcost/numerical/circumstance"
...
Randriamasy Expires January 17, 2014 [Page 4]
Internet-Draft Abbreviated-Title July 2013
2. Applicable deployments for the ECS use case
To maintain scalability, the initial assumption was that the ALTO
coverage network zone is decomposed in one '"local" part covering the
first hop range and the other part, the rest of the ISP network view,
similarly to what is proposed in [draft-ietf-alto-deployments]
"Therefore, the ALTO server at the university has also to include the
guidance given by the ISP1 ALTO server in its replies to the ALTO
clients. This can be called cascaded ALTO servers."
Recent ALTO WG discussions open the possibility for one IRD to
support multiple network maps having different levels of detail.
2.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 of in the network.
1. A Local Serving ALTO Server (LAOS)
* Hosts the information on the local EPS network, covering the
paths between the UEs and the PGWs,
* Hosts an ALTO Client that sends an ALTO request to a "general"
ALTO Server, covering the zone beyond the PGW. It can
possibly get the requested information from a local cache if
still valid.
* receives the ALTO request issued by the ALTO Client Serving
the UE.
2. a "core" or "regular" ALTO Server covers the whole ISP network
view, as it would if the "local ALTO Service" is not available or
deactivated.
2.2. One ALTO server with multi-level Network Maps
This section will be completed as the discussion on Cost Maps
dependency progresses.
Randriamasy Expires January 17, 2014 [Page 5]
Internet-Draft Abbreviated-Title July 2013
3. IANA Considerations
This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an
RFC.
4. Security Considerations
5. Acknowledgements
6. References
6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
6.2. Informative References
[draft-ietf-alto-deployment]
, , , "draft-ietf-alto-deployment-06", February 2013.
Appendix A. An Appendix
Author's Address
Sabine Randriamasy
Alcatel-Lucent
Route de Villejust
Nozay 91460
FRANCE
Email: Sabine.Randriamasy@alcatel-lucent.com
Randriamasy Expires January 17, 2014 [Page 6]
