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]