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