idnits 2.17.1 draft-contreras-alto-service-edge-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 1, 2022) is 785 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC8189' is defined on line 335, but no explicit reference was found in the text ** Obsolete normative reference: RFC 7752 (Obsoleted by RFC 9552) == Outdated reference: A later version (-12) exists of draft-ietf-teas-sf-aware-topo-model-09 == Outdated reference: A later version (-03) exists of draft-llc-teas-dc-aware-topo-model-01 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ALTO WG LM. Contreras 3 Internet-Draft Telefonica 4 Intended status: Informational D. Lachos 5 Expires: September 2, 2022 BENOCS 6 C. Rothenberg 7 Unicamp 8 S. Randriamasy 9 Nokia Bell Labs 10 March 1, 2022 12 Use of ALTO for Determining Service Edge 13 draft-contreras-alto-service-edge-04 15 Abstract 17 Service providers are starting to deploy and interconnect computing 18 capabilities across the network for hosting network functions and 19 applications. In distributed computing environments, both computing 20 and topological information are necessary in order to determine the 21 more convenient infrastructure where to deploy such a service or 22 application. This document proposes an initial approach towards the 23 use of ALTO to provide such information and assist the selection of 24 appropriate deployment locations for services and applications. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on September 2, 2022. 43 Copyright Notice 45 Copyright (c) 2022 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Computing needs . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Usage of ALTO for determining where to deploy a function or 63 application . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 3.1. Integrating compute information in ALTO . . . . . . . . . 5 65 3.2. Association of compute capabilities to network topology . 5 66 3.3. ALTO architecture for determining serve edge . . . . . . 6 67 4. Definition of flavors in ALTO property map . . . . . . . . . 6 68 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 69 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 70 7. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 7 71 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 72 8.1. Normative References . . . . . . . . . . . . . . . . . . 8 73 8.2. Informative References . . . . . . . . . . . . . . . . . 8 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 76 1. Introduction 78 The advent of virtualization is enabling the operators with a dynamic 79 instantiation of network functions and applications by using 80 different techniques on top of commoditized computation 81 infrastructures, permitting a flexible and on-demand deployment of 82 services, aligned with the actual needs observed as demanded by the 83 customers. 85 Operators are starting to deploy distributed computing environments 86 in different parts of the network with the objective of addressing 87 the different service needs in terms of latency, bandwidth, 88 processing capabilities, etc. This is translated in the emergence of 89 a number of data centers of different sizes (e.g., large, medium, 90 small) characterized by distinct dimension of CPUs, memory and 91 storage capabilities, as well as bandwidth capacity for forwarding 92 the traffic generated in and out the corresponding data center. 94 The probable future situation, with the generalization and 95 proliferation of the edge computing approach, will increase the 96 potential footprint where a function or application can be deployed. 97 These different dimensioning rules result in a different unitary cost 98 per CPU, memory, and storage in each computing environment because of 99 the scale. 101 All the available distributed computing capabilities can complicate 102 the decision of what infrastructure use for instantiating a given 103 function or application. Such a decision influences not only the 104 resources that are consumed in a given computing environment, but 105 also the network capacity of the path that connects such environment 106 with the rest of the network from traffic source to destination. 108 It is then essential for a network operator to have mechanisms 109 assisting on the decision by considering a number of constraints 110 related to the function or application to be deployed understanding 111 how a given decision on the computing environment for the service 112 edge affects to the transport network substrate. This would allow to 113 integrate network capabilities in the function placement decision and 114 further optimize performance of the deployed application. 116 This document proposes the usage of ALTO [RFC7285] for assisting with 117 such a decision. 119 2. Computing needs 121 A given network function or application typically shows certain 122 requirements in terms of processing capabilities (i.e., CPU), as well 123 as volatile memory (i.e., RAM) and storage capacity. 125 Cloud computing providers, such as Amazon Web Services or Microsoft 126 Azure, typically structure their offerings of computing capabilities 127 by bundling CPU, RAM and storage units as quotas, instances or 128 flavors that can be consumed in an ephemeral or temporal fashion, 129 during the actual lifetime of the required function or application. 131 This same approach is being taken nowadays for characterizing bundles 132 of resources on the so-called Network Function Virtualization 133 Infrastructure (NFVI) Points of Presence (PoPs) being deployed by the 134 telco operators. Specifically, the Common Network Function 135 Virtualisation Infrastructure Telecom Taskforce (CNTT) [CNTT], 136 [GSMA], jointly hosted by GSMA and the Linux Foundation, is intending 137 to harmonize the definition of above-mentioned computing capability 138 instances or flavors for abstracting capabilities of the underlying 139 NFVI facilitating a more efficient utilization of the infrastructure 140 and simplifying the integration and certification of functions, where 141 certification means the assessment of the expected behavior for a 142 given function according to the leverl of resources determined by a 143 given flavor. 145 Focusing on the CNTT ongoing work, the flavors or instances are 146 characterized according to: 148 o Type of instance (T): the types of instances are characterized as 149 B (Basic), or N (Network Intensive). The latter can come with 150 extensions for network acceleration for offloading network 151 intensive operations to hardware. 153 o Interface Option (I): it refers to the associated bandwidth of the 154 network interface. 156 o Compute flavor (F): it refers to a given predefined combination of 157 resources in terms of virtual CPU, RAM, disk, and bandwidth for 158 the management interface. 160 o Optional storage extension (S): allows to request additional 161 storage capacity. 163 o Optional hardware acceleration characteristics (A): to request 164 specific acceleration capabilities for improving the performance 165 of the infrastructure. 167 The naming convention of an instance is thus encoded as T.I.F.S.A. 169 3. Usage of ALTO for determining where to deploy a function or 170 application 172 ALTO can assist the deployment of a service or application on a 173 specific flavor or instance of the computing substrate by taking into 174 consideration network cost metrics. 176 A generic and primary approach is to take into account metrics 177 related to the computing environment, such as availability of 178 resources, unitary cost of those resources, etc. 180 Nevertheless, the function or application to be deployed on top of a 181 given flavor is interconnected outside the computing environment 182 where it is deployed, also requiring to guarantee transport network 183 requirements to ensure the application performance, such as 184 bandwidth, latency, etc. 186 The objective then is to leverage on ALTO to provide information 187 about the more convenient execution environments to deploy 188 virtualized network functions or applications, allowing the operator 189 to get a coordinated service edge and transport network 190 recommendation. 192 3.1. Integrating compute information in ALTO 194 CNTT proposes the existence of a catalogue of compute infrastructure 195 profiles collecting the computing capability instances available to 196 be consumed. Such kind of catalogue could be communicated to ALTO or 197 even incorporated to it. 199 ALTO server queries are required to support T.I.F.S.A encoding in 200 order to retrieve proper maps from ALTO. Additionally, filtered 201 queries for particular characteristics of a flavor could also be 202 supported. 204 3.2. Association of compute capabilities to network topology 206 It is required to associate the location of the available instances 207 with topological information to allow ALTO construct the overall map. 208 The expectation is to manage the network and cloud capabilities by 209 the same entity, handling both network and compute abstractions 210 jointly, producing an integrated map. While this can be 211 straightforward when an ISP own both the network and the cloud 212 infrastructure, it could require multiple administrative domains to 213 interwork for composing the integrated map. Details on potential 214 scenarios will be provided in future versions of the document. 216 At this stage four potential solutions could be considered: 218 o To leverage on (and possibly 219 extend) [I-D.ietf-teas-sf-aware-topo-model] for disseminating 220 topology information together with notion of function location 221 (that would require to be adapted to the existence of available 222 compute capabilities). A recent effort in this direction can be 223 found in [I-D.llc-teas-dc-aware-topo-model]. 225 o To extend BGP-LS [RFC7752], which is already considered as 226 mechanism for feeding topology information in ALTO, in order to 227 also advertise computing capabilities as well. 229 o To combine information from the infrastructure profiles catalogue 230 with topological information by leveraging on the IP prefixes 231 allocated to the gateway providing connectivity to the NFVI PoP. 233 o To integrate with Cloud Infrastructure Managers that could expose 234 cloud infrastructure capabilities as in [CNTT], [GSMA]. 236 The viability of these options will be explored in future versions of 237 this document. 239 3.3. ALTO architecture for determining serve edge 241 The following logical architecture defines the usage of ALTO for 242 determining service edges. 244 +--------+ Topological +---------+ 245 | | Information | | 246 | |<--------------->| e.g.BGP | 247 ALTO | | | | 248 +--------+ protocol | | +---------+ 249 | Client |<----------->| ALTO | 250 +--------+ | Server | 251 | | Computing +---------+ 252 | | Information | e.g., | 253 | |<--------------->| Infra. | 254 | | |Catalogue| 255 +--------+ +---------+ 257 Figure 1: Service Edge Information Exchange 259 4. Definition of flavors in ALTO property map 261 The ALTO unified property extension [DRAFT-PM] generalizes the 262 concept of endpoint properties to domains of other entities through 263 property maps. In the context of the CNTT domain, an ALTO property 264 map could be used to expose T.I.F.S.A information (i.e., potential 265 candidate flavors) of available NFVI PoPs where an application or 266 service can be deployed. 268 Table 1 below shows an illustrative example of an ALTO property map 269 with property values grouped by flavor name. 271 +----------+-----------+-------------+------------------+-----+-----+ 272 | Flavor | Type of | Interface | Compute flavor | S. | A. | 273 | Name | instance | Option (I) | (F) {CPU, RAM, | | | 274 | | (T) | | disk and | | | 275 | | | | bandwidth} | | | 276 +----------+-----------+-------------+------------------+-----+-----+ 277 | Small-1 | Basic | {1, 2, 3, | {1,512 MB,1 GB,1 | ... | ... | 278 | | | 4, 5, 6, 7, | Gbps} | | | 279 | | | 8, 9 Gbps} | | | | 280 | Small-2 | Network | {1, 2, 3, | {1,512 MB,1 GB,1 | ... | ... | 281 | | Intensive | 4, 5, 6, 7, | Gbps} | | | 282 | | | 8, 9 Gbps} | | | | 283 | Medium-1 | Network | {25, 50, | {2,4 GB,40 GB,1 | ... | ... | 284 | | Intensive | 75, 100, | Gbps} | | | 285 | | | 125, 150 | | | | 286 | | | Gbps} | | | | 287 | Large-1 | Compute | {50, 100, | {4,8 GB,80 GB,1 | ... | ... | 288 | | Intensive | 150, 200, | Gbps} | | | 289 | | | 250, 300 | | | | 290 | | | Gbps} | | | | 291 | Large-2 | Compute | {100, 200, | {8,16 GB,160 | ... | ... | 292 | | Intensive | 300, 400, | GB,1 Gbps} | | | 293 | | | 500, 600 | | | | 294 | | | Gbps} | | | | 295 | ... | ... | ... | ... | ... | ... | 296 +----------+-----------+-------------+------------------+-----+-----+ 298 Table 1: ALTO Property Map 300 5. IANA Considerations 302 This document includes no request to IANA. 304 6. Security Considerations 306 TBD. 308 7. Conclusions 310 Telco networks will increasingly contain a number of interconnected 311 data centers, of different size and characteristics, allowing 312 flexibility in the dynamic deployment of functions and applications 313 for advance services. The overall objective of this document is to 314 begin a discussion in the ALTO WG regarding the suitability of the 315 ALTO protocol for determining where to deploy a function or 316 application in distributed computing environments. The result of 317 such discussions will be reflected in future versions of this draft. 319 8. References 321 8.1. Normative References 323 [RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S., 324 Previdi, S., Roome, W., Shalunov, S., and R. Woundy, 325 "Application-Layer Traffic Optimization (ALTO) Protocol", 326 RFC 7285, DOI 10.17487/RFC7285, September 2014, 327 . 329 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 330 S. Ray, "North-Bound Distribution of Link-State and 331 Traffic Engineering (TE) Information Using BGP", RFC 7752, 332 DOI 10.17487/RFC7752, March 2016, 333 . 335 [RFC8189] Randriamasy, S., Roome, W., and N. Schwan, "Multi-Cost 336 Application-Layer Traffic Optimization (ALTO)", RFC 8189, 337 DOI 10.17487/RFC8189, October 2017, 338 . 340 8.2. Informative References 342 [CNTT] "Cloud iNfrastructure Telco Taskforce Reference Model", 343 . 345 [DRAFT-PM] 346 Roome, W., Randriamasy, S., Yang, Y., Zhang, J., and K. 347 Gao, "Unified Properties for the ALTO Protocol", draft- 348 ietf-alto-unified-props-new-24 (work in progress), 349 February 2022. 351 [GSMA] "Cloud Infrastructure Reference Model, Version 2.0", 352 October 2021, . 355 [I-D.ietf-teas-sf-aware-topo-model] 356 Bryskin, I., Liu, X., Lee, Y., Guichard, J., Contreras, 357 L., Ceccarelli, D., Tantsura, J., and D. Shytyi, "SF Aware 358 TE Topology YANG Model", draft-ietf-teas-sf-aware-topo- 359 model-09 (work in progress), February 2022. 361 [I-D.llc-teas-dc-aware-topo-model] 362 Lee, Y., Liu, X., and L. Contreras, "DC aware TE topology 363 model", draft-llc-teas-dc-aware-topo-model-01 (work in 364 progress), July 2021. 366 Authors' Addresses 368 Luis M. Contreras 369 Telefonica 370 Ronda de la Comunicacion, s/n 371 Madrid 28050 372 Spain 374 Email: luismiguel.contrerasmurillo@telefonica.com 375 URI: http://lmcontreras.com/ 377 Danny Alex Lachos Perez 378 BENOCS GmbH 379 Reuchlinstrasse 10 380 Berlin 10553 381 Germany 383 Email: dlachos@benocs.com 385 Christian Esteve Rothenberg 386 University of Campinas 387 Av. Albert Einstein 400 388 Campinas, Sao Paulo 13083-970 389 Brazil 391 Email: chesteve@dca.fee.unicamp.br 392 URI: https://intrig.dca.fee.unicamp.br/christian/ 394 Sabine Randriamasy 395 Nokia Bell Labs 396 Route de Villejust 397 Nozay 91460 398 France 400 Email: sabine.randriamasy@nokia-bell-labs.com