ALTO WG                                                    LM. Contreras
Internet-Draft                                                Telefonica
Intended status: Informational                                 D. Lachos
Expires: 27 April 2023                                            BENOCS
                                                           C. Rothenberg
                                                                 Unicamp
                                                          S. Randriamasy
                                                         Nokia Bell Labs
                                                         24 October 2022


                Use of ALTO for Determining Service Edge
                  draft-contreras-alto-service-edge-06

Abstract

   Service providers are starting to deploy and interconnect computing
   capabilities across the network for hosting network functions and
   applications.  In distributed computing environments, both computing
   and topological information are necessary in order to determine the
   more convenient infrastructure where to deploy such a service or
   application.  This document proposes an initial approach towards the
   use of ALTO to provide such information and assist the selection of
   appropriate deployment locations for services and applications.

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 https://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 27 April 2023.

Copyright Notice

   Copyright (c) 2022 IETF Trust and the persons identified as the
   document authors.  All rights reserved.





Contreras, et al.         Expires 27 April 2023                 [Page 1]


Internet-Draft      ALTO for Determining Service Edge       October 2022


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://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 Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Computing needs . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Usage of ALTO for determining where to deploy a function or
           application . . . . . . . . . . . . . . . . . . . . . . .   4
     3.1.  Integrating compute information in ALTO . . . . . . . . .   5
     3.2.  Association of compute capabilities to network
           topology  . . . . . . . . . . . . . . . . . . . . . . . .   5
     3.3.  ALTO architecture for determining serve edge  . . . . . .   6
   4.  ALTO Design considerations for determining service edge . . .   7
     4.1.  Example of entity definition in different domains . . . .   7
     4.2.  Definition of flavors in ALTO property map  . . . . . . .   9
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  12
   7.  Conclusions . . . . . . . . . . . . . . . . . . . . . . . . .  12
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  12
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  12
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  13

1.  Introduction

   The advent of virtualization is enabling the operators with a dynamic
   instantiation of network functions and applications by using
   different techniques on top of commoditized computation
   infrastructures, permitting a flexible and on-demand deployment of
   services, aligned with the actual needs observed as demanded by the
   customers.

   Operators are starting to deploy distributed computing environments
   in different parts of the network with the objective of addressing
   the different service needs in terms of latency, bandwidth,
   processing capabilities, etc.  This is translated in the emergence of
   a number of data centers of different sizes (e.g., large, medium,
   small) characterized by distinct dimension of CPUs, memory and
   storage capabilities, as well as bandwidth capacity for forwarding
   the traffic generated in and out the corresponding data center.




Contreras, et al.         Expires 27 April 2023                 [Page 2]


Internet-Draft      ALTO for Determining Service Edge       October 2022


   The probable future situation, with the generalization and
   proliferation of the edge computing approach, will increase the
   potential footprint where a function or application can be deployed.
   These different dimensioning rules result in a different unitary cost
   per CPU, memory, and storage in each computing environment because of
   the scale.

   All the available distributed computing capabilities can complicate
   the decision of what infrastructure use for instantiating a given
   function or application.  Such a decision influences not only the
   resources that are consumed in a given computing environment, but
   also the network capacity of the path that connects such environment
   with the rest of the network from traffic source to destination.

   It is then essential for a network operator to have mechanisms
   assisting on the decision by considering a number of constraints
   related to the function or application to be deployed understanding
   how a given decision on the computing environment for the service
   edge affects to the transport network substrate.  This would allow to
   integrate network capabilities in the function placement decision and
   further optimize performance of the deployed application.

   This document proposes the usage of ALTO [RFC7285] for assisting with
   such a decision.

2.  Computing needs

   A given network function or application typically shows certain
   requirements in terms of processing capabilities (i.e., CPU), as well
   as volatile memory (i.e., RAM) and storage capacity.

   Cloud computing providers, such as Amazon Web Services or Microsoft
   Azure, typically structure their offerings of computing capabilities
   by bundling CPU, RAM and storage units as quotas, instances or
   flavors that can be consumed in an ephemeral or temporal fashion,
   during the actual lifetime of the required function or application.

   This same approach is being taken nowadays for characterizing bundles
   of resources on the so-called Network Function Virtualization
   Infrastructure (NFVI) Points of Presence (PoPs) being deployed by the
   telco operators.  For instance, the Common Network Function
   Virtualisation Infrastructure Telecom Taskforce (CNTT) [CNTT],
   [GSMA], jointly hosted by GSMA and the Linux Foundation, intended to
   harmonize the definition of above-mentioned computing capability
   instances or flavors for abstracting capabilities of the underlying
   NFVI facilitating a more efficient utilization of the infrastructure
   and simplifying the integration and certification of functions, where
   certification means the assessment of the expected behavior for a



Contreras, et al.         Expires 27 April 2023                 [Page 3]


Internet-Draft      ALTO for Determining Service Edge       October 2022


   given function according to the level of resources determined by a
   given flavor.  Evolution of this initiative is Anuket [Anuket],
   working on different architectures for well known tools such as
   OpenStack and Kubernetes.

   Taking CNTT as an example, the flavors or instances can be
   characterized according to:

   *  Type of instance (T): the types of instances are characterized as
      B (Basic), or N (Network Intensive).  The latter can come with
      extensions for network acceleration for offloading network
      intensive operations to hardware.

   *  Interface Option (I): it refers to the associated bandwidth of the
      network interface.

   *  Compute flavor (F): it refers to a given predefined combination of
      resources in terms of virtual CPU, RAM, disk, and bandwidth for
      the management interface.

   *  Optional storage extension (S): allows to request additional
      storage capacity.

   *  Optional hardware acceleration characteristics (A): to request
      specific acceleration capabilities for improving the performance
      of the infrastructure.

   The naming convention of an instance is thus encoded as T.I.F.S.A.

3.  Usage of ALTO for determining where to deploy a function or
    application

   ALTO can assist the deployment of a service or application on a
   specific flavor or instance of the computing substrate by taking into
   consideration network cost metrics.

   A generic and primary approach is to take into account metrics
   related to the computing environment, such as availability of
   resources, unitary cost of those resources, etc.

   Nevertheless, the function or application to be deployed on top of a
   given flavor is interconnected outside the computing environment
   where it is deployed, also requiring to guarantee transport network
   requirements to ensure the application performance, such as
   bandwidth, latency, etc.






Contreras, et al.         Expires 27 April 2023                 [Page 4]


Internet-Draft      ALTO for Determining Service Edge       October 2022


   The objective then is to leverage on ALTO to provide information
   about the more convenient execution environments to deploy
   virtualized network functions or applications, allowing the operator
   to get a coordinated service edge and transport network
   recommendation.

3.1.  Integrating compute information in ALTO

   CNTT proposes the existence of a catalogue of compute infrastructure
   profiles collecting the computing capability instances available to
   be consumed.  Such kind of catalogue could be communicated to ALTO or
   even incorporated to it.

   ALTO server queries are required to support T.I.F.S.A encoding in
   order to retrieve proper maps from ALTO.  Additionally, filtered
   queries for particular characteristics of a flavor could also be
   supported.

3.2.  Association of compute capabilities to network topology

   It is required to associate the location of the available instances
   with topological information to allow ALTO construct the overall map.
   The expectation is to manage the network and cloud capabilities by
   the same entity, handling both network and compute abstractions
   jointly, producing an integrated map.  While this can be
   straightforward when an ISP own both the network and the cloud
   infrastructure, it could require multiple administrative domains to
   interwork for composing the integrated map.  Details on potential
   scenarios will be provided in future versions of the document.

   At this stage four potential solutions could be considered:

   *  To leverage on (and possibly
      extend) [I-D.ietf-teas-sf-aware-topo-model] for disseminating
      topology information together with notion of function location
      (that would require to be adapted to the existence of available
      compute capabilities).  A recent effort in this direction can be
      found in  [I-D.llc-teas-dc-aware-topo-model].

   *  To extend BGP-LS [RFC7752], which is already considered as
      mechanism for feeding topology information in ALTO, in order to
      also advertise computing capabilities as well.

   *  To combine information from the infrastructure profiles catalogue
      with topological information by leveraging on the IP prefixes
      allocated to the gateway providing connectivity to the NFVI PoP.





Contreras, et al.         Expires 27 April 2023                 [Page 5]


Internet-Draft      ALTO for Determining Service Edge       October 2022


   *  To integrate with Cloud Infrastructure Managers that could expose
      cloud infrastructure capabilities as in [CNTT], [GSMA].

   The viability of these options will be explored in future versions of
   this document.

3.3.  ALTO architecture for determining serve edge

   The following logical architecture defines the usage of ALTO for
   determining service edges.



                            +--------+   Topological   +---------+
                            |        |   Information   |         |
                            |        |<--------------->| e.g.BGP |
                   ALTO     |        |                 |         |
     +--------+  protocol   |        |                 +---------+
     | Client |<----------->|  ALTO  |
     +--------+             | Server |
                            |        |    Computing    +---------+
                            |        |   Information   |  e.g.,  |
                            |        |<--------------->|  Infra. |
                            |        |                 |Catalogue|
                            +--------+                 +---------+



                Figure 1: Service Edge Information Exchange

   In order to select the optimal edge server from both the network
   perspective (e.g., the one showing better path cost) and cloud
   capabilities (e.g. in terms of processing capabilities, available
   RAM, storage capacity, etc), it is needed to see an edge server as
   both an IP entity (as in [RFC7285]) and an ANE entity (as in
   [RFC9275]).

   Currently there is no way (neither in [RFC9275] nor [RFC9240]) to see
   the same edge server as an entity in both domains.  The design of
   ALTO however is flexible enough to allow extensions to indicate that
   an entity can be defined in several domains.  These different domains
   and their related properties can be specified in extended ALTO
   property maps, as proposed in the next sections.








Contreras, et al.         Expires 27 April 2023                 [Page 6]


Internet-Draft      ALTO for Determining Service Edge       October 2022


4.  ALTO Design considerations for determining service edge

   This section is in progress and gathers the ALTO features that are
   needed to support the exposure of both networking capabilities and
   compute capabilities in ALTO Maps.

   In particular, ALTO Entity Property Maps defined in [RFC9240] can be
   extended.  [RFC9240] generalizes the concept of endpoint properties
   to domains of other entities through property maps.  Entities can be
   defined in a wider set of entity domains such as IPv4, IPv6, PID, AS,
   ISO3166-1 country codes or ANE.  RFC 9240 in addition specifies how
   properties can be defined on entities of each of these domains.

4.1.  Example of entity definition in different domains

   First, as many applications do neot necessarily need both compute and
   networking information, it is fine to keep separate entity domains
   with their related relevant properties.  However, some applications
   need information on both topics and a scalable and flexible solution
   consists in defining an ALTO property type, that:

   *  indicates that an entity can be defined in several domains,

   *  specifies, for an entity, the other domains where this entity is
      defined.

   The following is an example where property "entity domain mapping"
   lists the other domains in which an entity is defined.  This property
   type should be usable in all entity domains types.

   One possible way, for instance, can be to introduce entity properties
   that list other entity domains where an edge server is identified.
   This property type should be usable in all entity domains types.

   Suppose an edge server is identified:

   *  in the IPV4 domain, with an IP address, e.g. ipv4:1.2.3.4

   *  in the ANE domain, with an identifier, e.g. ane:DC10-HOST1

   To get information on this edge server as an entity in the "ipv4"
   entity domain, an ALTO client queries the properties "pid" and
   "entity-domain-mappings" and gets a response as follows.








Contreras, et al.         Expires 27 April 2023                 [Page 7]


Internet-Draft      ALTO for Determining Service Edge       October 2022


   POST /propmap/lookup/dc-ip HTTP/1.1
   Host: alto.example.com
   Accept: application/alto-propmap+json,application/alto-error+json
   Content-Length: TBC
   Content-Type: application/alto-propmapparams+json
   {
   "entities" : ["ipv4:1.2.3.4"],
   "properties" : [ "pid", "entity-domain-mappings"]
   }


   HTTP/1.1 200 OK
   Content-Length: TBC
   Content-Type: application/alto-propmap+json
   {
   "meta" : {},

   "property-map":  {
       "ipv4:1.2.3.4" :
          {"pid" : DC10,
           "entity-domain-mappings" : ["ane"]}
       }
   }

   To get information on this edge server as an entity in the "ane"
   entity domain, an ALTO client queries the properties "entity-domain-
   mappings" and "network-address" and gets a response as follows.
























Contreras, et al.         Expires 27 April 2023                 [Page 8]


Internet-Draft      ALTO for Determining Service Edge       October 2022


   POST /propmap/lookup/dc-ane HTTP/1.1
   Host: alto.example.com
   Accept: application/alto-propmap+json,application/alto-error+json
   Content-Length: TBC
   Content-Type: application/alto-propmapparams+json
   {
   "entities" : ["ane:DC10-HOST1"],
   "properties" : [ "entity-domain-mappings", "network-address"]
   }

   HTTP/1.1 200 OK
   Content-Length: TBC
   Content-Type: application/alto-propmap+json
   {
   "meta" : {},

   "property-map":  {
      "ane:DC10-HOST1"
          {"entity domain mappings :  ["ipv4"]",
           "network-address" :  ipv4:1.2.3.4}
          }
   }

   Thus, if the ALTO Client sees the edge server as an entity with a
   network address, it knows that it can see the server as an ANE on
   which it can query relevant properties.

   Further elaboration will be provided in next versions of this
   document.

4.2.  Definition of flavors in ALTO property map

   The ALTO Entity Property Maps  [RFC9240] generalize the concept of
   endpoint properties to domains of other entities through property
   maps.  The term "flavor" or "instance" refers to an abstracted set of
   computing resources, with well specified properties on their
   capabilities.  Capabilities are typically CPU, RAM, Storage.  So a
   flavor can be seen as an ANE, with properties declined in terms for
   example of TIFSA.  A flavor or instance is a group of 1 or more
   elements that can be reached via one or more network addresses.  So
   an instance can be also be seen as a PID that groups 1 or more IP
   addresses.  In a context such as the one defined in CNTT, an ALTO
   property map could be used to expose T.I.F.S.A information of
   potential candidate flavors, i.e., potential NFVI PoPs where an
   application or service can be deployed.

   Figure 2 below shows an illustrative example of an ALTO property map
   with property values grouped by flavor name.



Contreras, et al.         Expires 27 April 2023                 [Page 9]


Internet-Draft      ALTO for Determining Service Edge       October 2022


      +--------+------------+-------+-----+------+------+-----+---+---+
      | flavor |  type (T)  | inter | f-c | f-ra | f-di | f-b | S | A |
      | -name  |            |  face |  pu |  m   |  sk  |  w  |   |   |
      |        |            |  (I)  | (F) | (F)  | (F)  | (F) |   |   |
      +--------+------------+-------+-----+------+------+-----+---+---+
      | small- |   basic    |   1   |  1  | 512  | 1 GB | 1 G |   |   |
      |   1    |            |  Gbps |     |  MB  |      | bps |   |   |
      .................................................................
      | small- |  network-  |   9   |  1  | 512  | 1 GB | 1 G |   |   |
      |   2    | intensive  |  Gbps |     |  MB  |      | bps |   |   |
      .................................................................
      | medium |  network-  |   25  |  2  | 4 GB |  40  | 1 G |   |   |
      |   -1   | intensive  |  Gbps |     |      |  GB  | bps |   |   |
      .................................................................
      | large- |  compute-  |   50  |  4  | 8 GB |  80  | 1 G |   |   |
      |   1    | intensive  |  Gbps |     |      |  GB  | bps |   |   |
      .................................................................
      | large- |  compute-  |  100  |  8  |  16  | 160  | 1 G |   |   |
      |   2    | intensive  |  Gbps |     |  GB  |  GB  | bps |   |   |
      +--------+------------+-------+-----+------+------+-----+---+---+


                        Figure 2: ALTO Property Map

   The following example uses the filtered property map resource to
   request properties "type", "cpu", "ram", and "disk" on on 5 ANE
   flavors named "small-1", "small-2", "medium-1", "large-1", "large-2"
   defined in the example before.























Contreras, et al.         Expires 27 April 2023                [Page 10]


Internet-Draft      ALTO for Determining Service Edge       October 2022


      POST /propmap/lookup/ane-flavor-name HTTP/1.1
      Host: alto.example.com
      Accept: application/alto-propmap+json,application/alto-error+json
      Content-Length: 155
      Content-Type: application/alto-propmapparams+json
      {
        "entities" : ["small-1",
                      "small-2",
                      "medium-1",
                      "large-1"],
                      "large-2"],
        "properties" : [ "type", "cpu", "ram", "disk"]
      }

      HTTP/1.1 200 OK
      Content-Length: 295
      Content-Type: application/alto-propmap+json
      {
        "meta" : {
        },
        "property-map": {
          "small-1":
            {"type" : "basic", "cpu" : 1,
              "ram" : "512MB", "disk" : 1GB},
          "small-2":
            {"type" : "network-intensive", "cpu" : 1,
              "ram" : "512MB", "disk" : 1GB},
          "medium-1":
            {"type" : "compute-intensive", "cpu" : 2,
              "ram" : "4GB", "disk" : 40GB},
          "large-1":
            {"type" : "compute-intensive", "cpu" : 4,
              "ram" : "8GB", "disk" : 80GB},
          "large-2":
            {"type" : "compute-intensive", "cpu" : 8,
              "ram" : "16GB", "disk" : 160GB},
        }
      }

               Figure 3: Filtered Property Map query example

5.  IANA Considerations

   This document includes no request to IANA.







Contreras, et al.         Expires 27 April 2023                [Page 11]


Internet-Draft      ALTO for Determining Service Edge       October 2022


6.  Security Considerations

   TBD.

7.  Conclusions

   Telco networks will increasingly contain a number of interconnected
   data centers, of different size and characteristics, allowing
   flexibility in the dynamic deployment of functions and applications
   for advance services.  The overall objective of this document is to
   begin a discussion in the ALTO WG regarding the suitability of the
   ALTO protocol for determining where to deploy a function or
   application in distributed computing environments.  The result of
   such discussions will be reflected in future versions of this draft.

8.  References

8.1.  Normative References

   [RFC7285]  Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S.,
              Previdi, S., Roome, W., Shalunov, S., and R. Woundy,
              "Application-Layer Traffic Optimization (ALTO) Protocol",
              RFC 7285, DOI 10.17487/RFC7285, September 2014,
              <https://www.rfc-editor.org/info/rfc7285>.

   [RFC7752]  Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and
              S. Ray, "North-Bound Distribution of Link-State and
              Traffic Engineering (TE) Information Using BGP", RFC 7752,
              DOI 10.17487/RFC7752, March 2016,
              <https://www.rfc-editor.org/info/rfc7752>.

   [RFC8189]  Randriamasy, S., Roome, W., and N. Schwan, "Multi-Cost
              Application-Layer Traffic Optimization (ALTO)", RFC 8189,
              DOI 10.17487/RFC8189, October 2017,
              <https://www.rfc-editor.org/info/rfc8189>.

   [RFC9240]  Roome, W., Randriamasy, S., Yang, Y., Zhang, J., and K.
              Gao, "An Extension for Application-Layer Traffic
              Optimization (ALTO): Entity Property Maps", RFC 9240,
              DOI 10.17487/RFC9240, July 2022,
              <https://www.rfc-editor.org/info/rfc9240>.

   [RFC9275]  Gao, K., Lee, Y., Randriamasy, S., Yang, Y., and J. Zhang,
              "An Extension for Application-Layer Traffic Optimization
              (ALTO): Path Vector", RFC 9275, DOI 10.17487/RFC9275,
              September 2022, <https://www.rfc-editor.org/info/rfc9275>.

8.2.  Informative References



Contreras, et al.         Expires 27 April 2023                [Page 12]


Internet-Draft      ALTO for Determining Service Edge       October 2022


   [Anuket]   "Anuket Project", <https://wiki.anuket.io/>.

   [CNTT]     "Cloud iNfrastructure Telco Taskforce Reference Model",
              <https://github.com/cntt-n/CNTT/wiki>.

   [GSMA]     "Cloud Infrastructure Reference Model, Version 2.0",
              October 2021, <https://www.gsma.com/newsroom/wp-content/
              uploads//NG.126-v2.0-1.pdf>.

   [I-D.ietf-teas-sf-aware-topo-model]
              Bryskin, I., Liu, X., Lee, Y., Guichard, J., Contreras,
              L., Ceccarelli, D., Tantsura, J., and D. Shytyi, "SF Aware
              TE Topology YANG Model", Work in Progress, Internet-Draft,
              draft-ietf-teas-sf-aware-topo-model-09, 27 February 2022,
              <http://www.ietf.org/internet-drafts/draft-ietf-teas-sf-
              aware-topo-model-09.txt>.

   [I-D.llc-teas-dc-aware-topo-model]
              Lee, Y., Liu, X., and L. Contreras, "DC aware TE topology
              model", Work in Progress, Internet-Draft, draft-llc-teas-
              dc-aware-topo-model-01, 12 July 2021,
              <https://www.ietf.org/archive/id/draft-llc-teas-dc-aware-
              topo-model-01.txt>.

Authors' Addresses

   Luis M. Contreras
   Telefonica
   Ronda de la Comunicacion, s/n
   28050  Madrid
   Spain
   Email: luismiguel.contrerasmurillo@telefonica.com
   URI:   http://lmcontreras.com/


   Danny Alex Lachos Perez
   BENOCS GmbH
   Reuchlinstra├če 10
   10553 Berlin
   Germany
   Email: dlachos@benocs.com










Contreras, et al.         Expires 27 April 2023                [Page 13]


Internet-Draft      ALTO for Determining Service Edge       October 2022


   Christian Esteve Rothenberg
   University of Campinas
   Av. Albert Einstein 400
   Campinas-Sao Paulo
   13083-970
   Brazil
   Email: chesteve@dca.fee.unicamp.br
   URI:   https://intrig.dca.fee.unicamp.br/christian/


   Sabine Randriamasy
   Nokia Bell Labs
   Route de Villejust
   91460 Nozay
   France
   Email: sabine.randriamasy@nokia-bell-labs.com



































Contreras, et al.         Expires 27 April 2023                [Page 14]