ALTO WG LM. Contreras Internet-Draft Telefonica Intended status: Informational D. Lachos Expires: January 12, 2023 BENOCS C. Rothenberg Unicamp S. Randriamasy Nokia Bell Labs July 11, 2022 Use of ALTO for Determining Service Edge draft-contreras-alto-service-edge-05 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 January 12, 2023. Copyright Notice Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. Contreras, et al. Expires January 12, 2023 [Page 1] Internet-Draft ALTO for Determining Service Edge July 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 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. 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. Definition of flavors in ALTO property map . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 10 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 8.1. Normative References . . . . . . . . . . . . . . . . . . 10 8.2. Informative References . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 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. The probable future situation, with the generalization and proliferation of the edge computing approach, will increase the Contreras, et al. Expires January 12, 2023 [Page 2] Internet-Draft ALTO for Determining Service Edge July 2022 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. Specifically, the Common Network Function Virtualisation Infrastructure Telecom Taskforce (CNTT) [CNTT], [GSMA], jointly hosted by GSMA and the Linux Foundation, is intending 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 given function according to the leverl of resources determined by a given flavor. Contreras, et al. Expires January 12, 2023 [Page 3] Internet-Draft ALTO for Determining Service Edge July 2022 Focusing on the CNTT ongoing work, the flavors or instances are characterized according to: o 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. o Interface Option (I): it refers to the associated bandwidth of the network interface. o 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. o Optional storage extension (S): allows to request additional storage capacity. o 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. 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. Contreras, et al. Expires January 12, 2023 [Page 4] Internet-Draft ALTO for Determining Service Edge July 2022 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: o 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]. o 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. o 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. o 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. Contreras, et al. Expires January 12, 2023 [Page 5] Internet-Draft ALTO for Determining Service Edge July 2022 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 [I-D.ietf-alto-path-vector]). Currently there is no way (neither in [I-D.ietf-alto-path-vector] nor [DRAFT-PM]) to see the same edge server as an entity in both domains. One possible way, for instance, can be to introduce entity properties that list other entity domains where an edge server is identified. Thus, if an edge server is identified by: o in the IPV4 domain, with an IP address, e.g. ipv4:1.2.3.4 o in the ANE domain, with an identifier, e.g. ane:DC10-HOST1 With this, a potential solution can be: Contreras, et al. Expires January 12, 2023 [Page 6] Internet-Draft ALTO for Determining Service Edge July 2022 --- in the IP entity domain ipv4:1.2.3.4 Properties: pid : DC10 entity domain mapping : [<>] --- in the ANE domain ane:DC10-HOST1 Properties: entity domain mapping : : [<>] Name: DC10-HOST1 network-address : ipv4:1.2.3.4 Further elaboration will be provdided in next versions of this document. 4. Definition of flavors in ALTO property map The ALTO unified property extension [DRAFT-PM] generalizes the concept of endpoint properties to domains of other entities through property maps. In the context of the CNTT domain, 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 January 12, 2023 [Page 7] Internet-Draft ALTO for Determining Service Edge July 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 several flavor names defined in the previous property map. Contreras, et al. Expires January 12, 2023 [Page 8] Internet-Draft ALTO for Determining Service Edge July 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-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" : 4, "ram" : "8GB", "disk" : 80GB}, "large-2": {"type" : "compue-intensive", "cpu" : 8, "ram" : "16GB", "disk" : 160GB}, } } Figure 3: Filtered Property Map query example 5. IANA Considerations This document includes no request to IANA. 6. Security Considerations TBD. Contreras, et al. Expires January 12, 2023 [Page 9] Internet-Draft ALTO for Determining Service Edge July 2022 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, . [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, . [RFC8189] Randriamasy, S., Roome, W., and N. Schwan, "Multi-Cost Application-Layer Traffic Optimization (ALTO)", RFC 8189, DOI 10.17487/RFC8189, October 2017, . 8.2. Informative References [CNTT] "Cloud iNfrastructure Telco Taskforce Reference Model", . [DRAFT-PM] Roome, W., Randriamasy, S., Yang, Y., Zhang, J., and K. Gao, "Unified Properties for the ALTO Protocol", draft- ietf-alto-unified-props-new-24 (work in progress), February 2022. [GSMA] "Cloud Infrastructure Reference Model, Version 2.0", October 2021, . Contreras, et al. Expires January 12, 2023 [Page 10] Internet-Draft ALTO for Determining Service Edge July 2022 [I-D.ietf-alto-path-vector] Gao, K., Lee, Y., Randriamasy, S., Yang, Y. R., and J. J. Zhang, "An ALTO Extension: Path Vector", draft-ietf-alto- path-vector-25 (work in progress), March 2022. [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", draft-ietf-teas-sf-aware-topo- model-09 (work in progress), February 2022. [I-D.llc-teas-dc-aware-topo-model] Lee, Y., Liu, X., and L. Contreras, "DC aware TE topology model", draft-llc-teas-dc-aware-topo-model-01 (work in progress), July 2021. Authors' Addresses Luis M. Contreras Telefonica Ronda de la Comunicacion, s/n Madrid 28050 Spain Email: luismiguel.contrerasmurillo@telefonica.com URI: http://lmcontreras.com/ Danny Alex Lachos Perez BENOCS GmbH Reuchlinstrasse 10 Berlin 10553 Germany Email: dlachos@benocs.com 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/ Contreras, et al. Expires January 12, 2023 [Page 11] Internet-Draft ALTO for Determining Service Edge July 2022 Sabine Randriamasy Nokia Bell Labs Route de Villejust Nozay 91460 France Email: sabine.randriamasy@nokia-bell-labs.com Contreras, et al. Expires January 12, 2023 [Page 12]