ALTO Cost Calendar
draft-randriamasy-alto-cost-calendar-04

quot; : [true],

    "pids" : {
       "srcs" : [ "PID1", "PID2" ],
       "dsts" : [ "PID1", "PID2", "PID3" ]
    }
  }

  HTTP/1.1 200 OK
  Content-Length: [TODO]
  Content-Type: application/alto-costmap+json

  {
    "meta" : {
      "dependent-vtags" : [...],
      "cost-type" : {"cost-mode" : "numerical", "cost-metric" : "Availbandwidth"},
      "calendar-response-attributes" : [
         "calendar-start-time" : Tue, 1 Jul 2014 13:00:00 GMT,
         "time-interval-size" : "2 hour",
         "numb-intervals" : 12
       ]
     },

    "cost-map" : {
       "PID1": { "PID1": [v1,v2,v3,v4,v5,v6,v7,v8,v9,v10,v11,v12],
                 "PID2": [v1,v2,v3,v4,v5,v6,v7,v8,v9,v10,v11,v12],
                 "PID3": [v1,v2,v3,v4,v5,v6,v7,v8,v9,v10,v11,v12] },
       "PID2": { "PID1": [v1,v2,v3,v4,v5,v6,v7,v8,v9,v10,v11,v12],
                 "PID2": [v1,v2,v3,v4,v5,v6,v7,v8,v9,v10,v11,v12],
                 "PID3": [v1,v2,v3,v4,v5,v6,v7,v8,v9,v10,v11,v12] }
    }
  }

Randriamasy, et al.      Expires January 7, 2016               [Page 20]
Internet-Draft             ALTO Cost Calendar                  July 2015

4.2.  Calendar extensions in the Endpoint Cost Map Service

   This document extends the Endpoint Cost Service, as defined in
   {11.5.1} of [RFC7285], by adding new input parameters and
   capabilities, and by returning JSONArrays instead of JSONNumbers as
   the cost values.  The media type (11.5.1.1} and HTTP method
   (11.5.1.2} are unchanged.

4.2.1.  Calendar specific input in Endpoint cost map requests

   The extensions to the requests for calendared Endpoint Cost Maps are
   the same as for the Filtered Cost Map Service, previously specified
   in section XXXX.

   The ReqEndpointCostMap object for a Calendared ECM request will have
   the following format:

   object {
     CostType       cost-type;
     [JSONBoolean    calendared<1..*>;]
     EndpointFilter endpoints;
   } ReqEndpointCostMap;

   object {
     [TypedEndpointAddr srcs<0..*>;]
     [TypedEndpointAddr dsts<0..*>;]
   } EndpointFilter;

4.2.2.  Calendar attributes in the Endpoint Cost Map responses

   The "meta" field of a Calendared Endpoint Cost map response MUST
   include at least:

   o  the "meta" fields specified for these Endpoint Cost service
      responses, as specified in RFC 7285 if the ALTO Client supports
      costs for one Cost Type at a time only,

      *  "cost-type" field.

   o  the "meta" fields specified for these information service
      responses, as specified in RRRR [draft-ietf-multi-cost-alto] if
      the ALTO Client supports Multi-Cost capabilities, that is:

      *  "multi-cost-types" field.

   The "meta" member of a Calendared Endpoint Cost Map response MUST
   include the same addifional member "calendar-response-attributes" as

Randriamasy, et al.      Expires January 7, 2016               [Page 21]
Internet-Draft             ALTO Cost Calendar                  July 2015

   specified for the Filtered Cost Map Service.  If the client request
   does not provide member "calendared" or if it provides it with a
   value equal to 'false', then the ALTO Server response is exactly as
   specified in {11.5.1.6} of [RFC7285].  If the client provides member
   "calendared" with a value equal to 'true' in the input parameters,
   the Server response is changed as follows:

   o  the "meta" member has one additional field
      "CalendarResponseAttributes", as specified for the Filtered Cost
      Map Service,

   o  the calendared costs are JSONArrays instead of JSONNumbers for the
      legacy ALTO implementation.  All arrays have a number of values
      equal to 'number-of-intervals'.

4.2.3.  Example transaction for the ECS with a "periodic" routingcost
        Calendar

   Let us assume an Application Client located in an end sytem with
   limited resources and having an access to the network that is either
   intermittent or provides an acceptable quality in limited but
   possibly predictable time periods.  Therefore, it needs to both
   schedule its resources demanding networking activities and minimize
   its ALTO transactions.

   The Application Client has the choice to trade content or resources
   with a set of Endpoints of moderate 'routingcost', and needs to
   decide with which Endpoint it will trade at what time.  For instance,
   one may assume that the Endpoints are spread on different time-zones,
   or have intermittent access.  In this example, the 'routingcost' is
   assumed to be the time sentitive decision metric, with values
   provided in the ALTO Calendar Mode.

   The ALTO Client embedded in the Application Client queries an ALTO
   Calendar on 'routingcost' and will get the Calendar covering the 24
   hours time period "containing" the date and time of the ALTO client
   request.

   For Cost Type 'calendar-routing', this example ALTO Server has
   defined 3 different daily patterns each represented by a Calendar, to
   cover the week of Monday June 30th at 00:00 to Sunday July 6th 23:59:

   - C1 for Monday, Tuesday, Wednesday, Thursday, (week days)

   - C2 for Saturday, Sunday, (week end)

   - C3 for Friday (maintenance outage on July 4, 2014 from 02:00:00 GMT
   to 04:00:00 GMT, or big holiday such as New Year evening).

Randriamasy, et al.      Expires January 7, 2016               [Page 22]
Internet-Draft             ALTO Cost Calendar                  July 2015

   The presence of attributes "repeated" and "calendar-start-time"
   allows an ALTO client to fetch 3 Calendars instead of 7 and thus to
   reduce the volume of on-the-wire data exchange,

   In the following example transaction, the ALTO Client sends its
   request on Tuesday July 1st 2014 at 13:15.  It will this get the
   value pattern "C1" , valid from Monday at 00:00:00 until Thursday at
   23:59:59, thus repeated 4 times.

Randriamasy, et al.      Expires January 7, 2016               [Page 23]
Internet-Draft             ALTO Cost Calendar                  July 2015

POST /calendar/endpointcost/lookup HTTP/1.1
  Host: alto.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"},
    "calendared" : [true],
    "endpoints" : {
      "srcs": [ "ipv4:192.0.2.2" ],
      "dsts": [
        "ipv4:192.0.2.89",
        "ipv4:198.51.100.34",
        "ipv4:203.0.113.45"
      ]
    }
  }

  HTTP/1.1 200 OK
  Content-Length: [TODO]
  Content-Type: application/alto-endpointcost+json

  {
    "meta" : {
      "cost-type" : {"cost-mode" : "numerical", "cost-metric" : "routingcost"},
      "calendar-response-attributes" : [
         { "calendar-start-time" : Mon, 30 Jun 2014 00:00:00 GMT,
           "time-interval-size" : "1 hour",
           "numb-intervals" : 24,
           "repeated": 4 }
        ],
      } // end meta

      "endpoint-cost-map" : {
        "ipv4:192.0.2.2": {
          "ipv4:192.0.2.89"    : [v1, v2, ... v24],
          "ipv4:198.51.100.34" : [v1, v2, ... v24],
          "ipv4:203.0.113.45"  : [v1, v2, ... v24]
        }
      }
  }

Randriamasy, et al.      Expires January 7, 2016               [Page 24]
Internet-Draft             ALTO Cost Calendar                  July 2015

4.2.4.  Example transaction for the ECS with a calendar on both
        routingcost and latency

   In this example, it is assumed that the ALTO Server implements multi-
   cost capabilities, as specified in [draft-ietf-alto-multi-cost] .
   That is, an ALTO client can request and receive values for several
   cost types in one single transaction.  An illustrating use case is a
   path selection done on the basis of 2 metrics: routing cost and
   latency.

   The assumptions on the routing cost calendars are the same as in the
   previous example.

   For metric "latency", the calendar attributes in the IRD indicate
   that the values are updated every hour and each one applies to an
   interval of 5 minutes.  The Server response provides value 1 for
   attribute 'repeated' it is assumed that the current calendar values
   are repeated 1 time, that is, in the next hour the calendar will have
   different values.

   In the following example transaction, the ALTO Client sends its
   request on Tuesday July 1st 2014 at 13:15.  It is assumed that it
   does this multi-cost request for the first time.

   When receiving the response, the client sees that the calendar for
   latency will change in the next hour where as the calendar values for
   routing cost will be the same for the next 3 days.  Therefore, in its
   next requests until the routing cost calendar is expected to change,
   the client will only need to request a calendar for 1 single metric
   which is latency.

   Without the ALTO Calendar extensions, the ALTO client would have no
   clue on the dynamicity of the metric value change and would spend
   needless time requesting values at an inappropriate pace.  In
   addition, without the Multi-Cost ALTO capabilities, the ALTO client
   would duplicate this waste of time as it would need to send one
   request per cost metric.

POST calendar/endpointcost/lookup HTTP/1.1
  Host: alto.example.com
  Content-Length: [TODO]
  Content-Type: application/alto-endpointcostparams+json
  Accept: application/alto-endpointcost+json,application/alto-error+json

  {
    "multi-cost-types" : [
        {"cost-mode" : "numerical", "cost-metric" : "routingcost"},
        {"cost-mode" : "numerical", "cost-metric" : "latency"}

Randriamasy, et al.      Expires January 7, 2016               [Page 25]
Internet-Draft             ALTO Cost Calendar                  July 2015

    ],
    "calendared" : [true, true],
    "endpoints" : {
      "srcs": [ "ipv4:192.0.2.2" ],
      "dsts": [
        "ipv4:192.0.2.89",
        "ipv4:198.51.100.34",
        "ipv4:203.0.113.45"
      ]
    }
  }

  HTTP/1.1 200 OK
  Content-Length: [TODO]
  Content-Type: application/alto-endpointcost+json

  {
    "meta" : {
      "multi-cost-types" : [
        {"cost-mode" : "numerical", "cost-metric" : "routingcost"},
        {"cost-mode" : "numerical", "cost-metric" : "latency"}
       ],
      "calendar-response-attributes" : [
         { "cost-type-name : num-routingcost"
           "calendar-start-time" : Mon, 30 Jun 2014 00:00:00 GMT,
           "time-interval-size" : "1 hour",
           "numb-intervals" : 24,
           "repeated": 4 },
         { "cost-type-name : num-latency"
           "calendar-start-time" : Tue, 1 Jul 2014 13:00:00 GMT,
           "time-interval-size" : "5 minute",
           "numb-intervals" : 12,
           "repeated": 1 }
       ],
      } // end meta

      "endpoint-cost-map" : {
        "ipv4:192.0.2.2": {
          "ipv4:192.0.2.89"    : [[r1, r2, ... r24], [l1, l2, ... l12]],
          "ipv4:198.51.100.34" : [[r1, r2, ... r24], [l1, l2, ... l12]],
          "ipv4:203.0.113.45"  : [[r1, r2, ... r24], [l1, l2, ... l12]]
        }
      }
  }

Randriamasy, et al.      Expires January 7, 2016               [Page 26]
Internet-Draft             ALTO Cost Calendar                  July 2015

4.3.  Recap of rules related to ALTO Cost Calendars

   XXXXX TO BE COMPLETED + MOVED AT THE END OF THE SPECS

   A Calendar-aware ALTO Server MUST implement the base protocol
   specified in RFC7285.

   If no Calendar attributes are defined for a given Cost Type, in a
   given resource entry, the ALTO Server MUST set the value in the
   'calendar-attributes' array to the symbol 'null' .

   When a metric is available as a calendar, it MUST be available as a
   single value.  An ALTO Server aquiring cost values in limited time
   intervals only can construct a single value from the value array.

   Calendared information resources MUST be requested via a POST method.

   If this member "repeat-indication" is not present in the calendar
   attributes indicated in the IRD, it MUST be assumed to have a value
   equal to "false".

5.  Use cases for ALTO Cost Schedule

   This section presents use cases showing the benefits of ALTO Cost
   calendars for applications needing to decide both "where" to connect
   and "when".

5.1.  Bulk Data Transfer scheduling upon bandwidth calendars

   Large Internet Content Providers (ICPs) like Facebook or YouTube, as
   well as CDNs rely on data replication across multiple sites and time
   zones to offload the core site and increase user experience through
   shorter latency from a local site.  Typically the usage pattern of
   these data centers or caches follows a location dependent diurnal
   demand pattern.  In these examples, data replication across the
   various locations of an ICP, leads to bulk data transfers between
   datacenters on a diurnal pattern.

   In the meantime, there is a degree of freedom on when the content is
   transmitted from the origin server to the caching node, or from the
   core site to a local site.  However, scheduling these data transfers
   is a non-trivial task as they should not infer with the user peak
   demand to avoid degradation of user experience and to decrease
   billing costs for the datacenter operator by leveraging off-peak
   hours for the transfer.

   As a result, these ICPs need to have a good knowledge on the link
   utilization patterns between the different datacenters before making

Randriamasy, et al.      Expires January 7, 2016               [Page 27]
Internet-Draft             ALTO Cost Calendar                  July 2015

   an efficient scheduling decision.  While usage data today is already
   gathered and used to schedule data transfers, provisioning these data
   gets increasingly complex with the number of CDN nodes and datacenter
   operators that are involved.  In particular, privacy concerns prevent
   that this kind of data is shared across administrative domains.  The
   ALTO Cost Calendar avoids these problems by presenting an abstracted
   view of time sensitive utilization maps through a dedicated ALTO
   service to allow ICPs a coherent scheduling of data transfers across
   administrative domains and time zones.

   Likewise, bandwidth Calendaring allows network operators to reserve
   resources in advance according to agreements with their customers,
   enabling them to transmit data with specified starting time and
   duration, for example, for a scheduled bulk data replication between
   data centers.  Traditionally, this can be supported by a Network
   Management System operation such as path pre-establishment and
   activation on the agreed starting time.  However, this does not
   provide efficient network usage since the established paths exclude
   the possibility of being used by other services even when they are
   not used for undertaking any service.

   An ALTO Cost calendar for TE metrics on transfer paths can support
   the scheduled bulk data replication with better efficiency since it
   can alleviate the processing burden on network elements.

   Cost calendars for these time-sensitive ALTO TE metrics need to
   consider the network topology and the dynamicity of the traffic.  For
   example, a small topology with low density and low capacity that
   carries inpredictable, heavy and bursty traffic has few chances to
   exhibit stationary TE metric value patterns over large periods and
   would benefit to use the ALTO Calendar over smaller time slots.  Some
   ALTO TE metric values, even aggregated over time may need to be
   updated at a frequency that would require doing ALTO requests at a
   pace that would be overload both the ALTO Client and the Server.
   Large high capacity topologies would benefit from Cost Calendars with
   a coarse time granularity for the filtered cost map service where as
   Calendars of finer time granularity for the Endpoint Cost Service
   would be better suited for small low density and capacity topologies.

5.1.1.  Applicable example transaction

   Assuming a Large high capacity topology, an applicable example
   transaction for this us case is provided by section 4.1.3.  "Example
   transaction for a FCM with a "request-date" bandwidth Calendar".

Randriamasy, et al.      Expires January 7, 2016               [Page 28]
Internet-Draft             ALTO Cost Calendar                  July 2015

5.2.  Applications with limited connectivity or access to datacenters

   Some applications are limited in their connectivity either in time or
   resources or both.  For example applications running on devices in
   remote locations or in developing countries that need to synchronize
   their state with a data center periodically, in particular if
   sometimes there is no connection at all.  Example applications are
   enterprise database update, remote learning, remote computation
   distributed on several data center endpoints.

   Wireless connections have a variable quality and may even be
   intermittent.  On the other hand, the wireless network conditions are
   often predicable and have a rapid impact on applications.  Non real
   time applications and time-insensitive data transfers such as client
   patching, archive syncing, etc. can benefit from careful scheduling.
   It is thus desirable to provide ALTO clients with routing costs to
   connection nodes (i.e.  Application Endpoints) over different time
   periods.  This would allow end systems using ALTO aware application
   clients to schedule their connections to application endpoints.

   Another challenge arises with applications using data and physical
   resources scattered around the world.  For non-real time
   applications, the interaction with Endpoints can be scheduled at the
   time slots corresponding to the best possible network conditions in
   order to improve the QoE.  For instance, resource Ra downloaded from
   Endpoint EPa at time t1, Resource Rb uploaded to EPb at time t2, some
   batch computation involving Ra and Rb done on EPc at time t3 and
   results R(A,B) downloaded to EPd and EPe at time t4.

Randriamasy, et al.      Expires January 7, 2016               [Page 29]
Internet-Draft             ALTO Cost Calendar                  July 2015

     +-----+                                           +-----+
     | EPa |                                           | EPb | <----- Rb
     +-----+                                           +-----+   (t2=50)
        |                   +-------+                     |
        Ra -------------->  | EPc   |                     |
        (time t1=10)        |       |                     |
                            |t3=100 |  <----------------- Rb
                            +-------+
                                | \
                                |  \
                              R(Ra,Rb)
                             (t4=200)
                                |     \
                                |      -------------------.
                                V                         V
                             +-----+                   +-----+
                             | EPd |                   | EPe |
                             +-----+                   +-----+

5.2.1.  Applicable example transaction

   An applicable example transaction for this us case is provided by
   section 4.2.3.  "Example transaction for the ECS with a "periodic"
   routingcost Calendar".

5.3.  SDN Controller guided traffic scheduling with Calendars

   An ALTO Server can assist an SDN Controller by hosting abstracted
   network information that can be provided to SDN aware applications
   via an ALTO Client.

   Via the Northbound interface (NBI), applications may get QoE
   impacting information such as network provider preferences w.r.t.
   delay and bandwidth on the network paths.  Such information may be
   provided via the ALTO Service if the latter supports the requested
   metrics.

   One key objective of an SDN controller is the ability to balance the
   application traffic whenever possible.  Resources availability may
   often be predicted and strong incentives for applications to time
   shift their traffic may be given by network operators appropriately
   setting routing cost values at different time values, according to
   their policy on network utilization over time.

   To achieve this objective, the SDN controller can:

Randriamasy, et al.      Expires January 7, 2016               [Page 30]
Internet-Draft             ALTO Cost Calendar                  July 2015

   1.  get the network state information from its controlled network
       elements through its southbound API and derive an estimation of
       these values over given time frames

   2.  abstract the network topology and costs on end to end paths and
       store this in an ALTO Server in the form of Network Maps and Cost
       Calendars

   3.  deliver these values to ALTO Clients linked to SDN applications,
       through the NBI.

   This way:

   o  On one hand, the applications get the best possible QoE, as they
      can pick the best time for them to access one or more Endpoints or
      PIDs,

   o  One the other hand the SDN controller achieves load balancing and
      optimizes application traffic as it may guide the application
      traffic so as to better distribute the traffic over time, and thus
      optimize its resources usage.

5.3.1.  Applicable example transaction

   An applicable example transaction for this us case is provided by
   section 4.2.4.  "Example transaction for the ECS with a calendar on
   both routingcost and latency".

6.  IANA Considerations

   Information for the ALTO Endpoint property registry maintained by the
   IANA and related to the new Endpoints supported by the acting ALTO
   server.  These definitions will be formulated according to the syntax
   defined in Section on "ALTO Endpoint Property Registry" of
   [ID-alto-protocol],

   Information for the ALTO Cost Type Registry maintained by the IANA
   and related to the new Cost Types supported by the acting ALTO
   server.  These definitions will be formulated according to the syntax
   defined in Section on "ALTO Cost Type Registry" of [RFC7285],

6.1.  Information for IANA on proposed Cost Types

   When a new ALTO Cost Type is defined, accepted by the ALTO working
   group and requests for IANA registration MUST include the following
   information, detailed in Section 11.2: Identifier, Intended
   Semantics, Security Considerations.

Randriamasy, et al.      Expires January 7, 2016               [Page 31]
Internet-Draft             ALTO Cost Calendar                  July 2015

6.2.  Information for IANA on proposed Endpoint Propeeries

   Likewise, an ALTO Endpoint Property Registry could serve the same
   purposes as the ALTO Cost Type registry.  Application to IANA
   registration for Endpoint Properties would follow a similar process.

7.  Acknowledgements

   Thank you to Diego Lopez, He Peng and Haibin Song and the ALTO WG for
   fruitful discussions.

8.  References

8.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC5693]  Seedorf, J. and E. Burger, "Application-Layer Traffic
              Optimization (ALTO) Problem Statement", RFC 5693, October
              2009.

8.2.  Informative References

   [draft-ietf-alto-multi-cost]
              S. Randriamasy, W. Roome, N. Schwan, , "Multi-Cost ALTO
              (work in progress), draft-ietf-alto-multi-cost", May 2015.

   [draft-wu-alto-te-metrics]
              Q. Wu, Y. Yang, Y. Lee, D. Dhody, S. Randriamasy, , "ALTO
              Traffic Engineering Cost Metrics (work in progress)",
              October 2014.

   [draft-yang-alto-topology]
              Y. Yang, , "ALTO Topology Considerations (work in
              progress)", July 2013.

   [ID-alto-protocol]
              R.Alimi, R. Penno, Y. Yang, Eds., "ALTO Protocol, RFC
              7285", September 2014.

   [RFC7285]  R. Alimi, R. Yang, R. Penno, Eds., "ALTO Protocol",
              September 2014.

   [sdnrg]    "Software Defined Network Research Group,
              http://trac.tools.ietf.org/group/irtf/trac/wiki/sdnrg".

Randriamasy, et al.      Expires January 7, 2016               [Page 32]
Internet-Draft             ALTO Cost Calendar                  July 2015

   [slides-88-alto-5-topology]
              G. Bernstein, Y. Lee, Y. Yang, , , "ALTO Topology Service:
              Use Cases, Requirements and Framework (presentation slides
              IETF88 ALTO WG session),
              http://tools.ietf.org/agenda/88/slides/
              slides-88-alto-5.pdf", November 2013.

Authors' Addresses

   Sabine Randriamasy
   Alcatel-Lucent Bell Labs
   Route de Villejust
   NOZAY  91460
   FRANCE

   Email: Sabine.Randriamasy@alcatel-lucent.com

   Richard Yang
   Yale University
   51 Prospect st
   New Haven, CT  06520
   USA

   Email: yry@cs.yale.edu

   Qin Wu
   Huawei
   101 Software Avenue, Yuhua District
   Nanjing, Jiangsu  210012
   China

   Email: sunseawq@huawei.com

   Lingli Deng
   China Mobile
   China

   Email: denglingli@chinamobile.com

   Nico Schwan
   Thales Deutschland

   Email: nico.schwan@thalesgroup.com

Randriamasy, et al.      Expires January 7, 2016               [Page 33]