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