[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

ALTO                                                      S. Randriamasy
Internet-Draft                                            Alcatel-Lucent
Intended status: Experimental                              July 16, 2013
Expires: January 17, 2014

                          ALTO Cost Value Name


   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",
   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": [
   "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": [
   "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

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

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-06", February 2013.

Appendix A.  An Appendix

Author's Address

   Sabine Randriamasy
   Route de Villejust
   Nozay  91460

   Email: Sabine.Randriamasy@alcatel-lucent.com

Randriamasy             Expires January 17, 2014                [Page 6]

Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/