idnits 2.17.1 draft-contreras-alto-service-edge-01.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 13, 2020) is 1354 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC8189' is defined on line 308, 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-09 -- No information found for draft-ietf-teas-sf-aware-topo-model - is the name correct? Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). 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 14, 2021 C. Rothenberg 6 Unicamp 7 July 13, 2020 9 Use of ALTO for Determining Service Edge 10 draft-contreras-alto-service-edge-01 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 January 14, 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 . . . . . . . . . 5 65 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 66 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 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). 201 o To extend BGP-LS [RFC7752], already considered as mechanism for 202 feeding topology information in ALTO, to advertise computing 203 capabilities as well. 205 o To combine information from the infrastructure profiles catalogue 206 with topological information by leveraging on the IP prefixes 207 allocated to the gateway providing connectivity to the NFVI PoP. 209 The viability of these options will be explored in future versions of 210 this document. 212 3.3. ALTO architecture for determining serve edge 214 The following logical architecture defines the usage of ALTO for 215 determining service edges. 217 +--------+ Topological +---------+ 218 | | Information | | 219 | |<--------------->| e.g.BGP | 220 ALTO | | | | 221 +--------+ protocol | | +---------+ 222 | Client |<----------->| ALTO | 223 +--------+ | Server | 224 | | Computing +---------+ 225 | | Information | e.g., | 226 | |<--------------->| Infra. | 227 | | |Catalogue| 228 +--------+ +---------+ 230 Figure 1: Service Edge Information Exchange 232 4. Definition of flavors in ALTO property map 234 The ALTO unified property extension [DRAFT-PM] generalizes the 235 concept of endpoint properties to domains of other entities through 236 property maps. In the context of the CNTT domain, an ALTO property 237 map could be used to expose T.I.F.S.A information of potential 238 candidate flavors, i.e., potential NFVI PoPs where an application or 239 service can be deployed. 241 Table 1 below shows an illustrative example of an ALTO property map 242 with property values grouped by flavor name. 244 +----------+-----------+-------------+------------------+-----+-----+ 245 | Flavor | Type of | Interface | Compute flavor | S. | A. | 246 | Name | instance | Option (I) | (F) {CPU, RAM, | | | 247 | | (T) | | disk and | | | 248 | | | | bandwidth} | | | 249 +----------+-----------+-------------+------------------+-----+-----+ 250 | Small-1 | Basic | {1, 2, 3, | {1,512 MB,1 GB,1 | ... | ... | 251 | | | 4, 5, 6, 7, | Gbps} | | | 252 | | | 8, 9 Gbps} | | | | 253 | Small-2 | Network | {1, 2, 3, | {1,512 MB,1 GB,1 | ... | ... | 254 | | Intensive | 4, 5, 6, 7, | Gbps} | | | 255 | | | 8, 9 Gbps} | | | | 256 | Medium-1 | Network | {25, 50, | {2,4 GB,40 GB,1 | ... | ... | 257 | | Intensive | 75, 100, | Gbps} | | | 258 | | | 125, 150 | | | | 259 | | | Gbps} | | | | 260 | Large-1 | Compute | {50, 100, | {4,8 GB,80 GB,1 | ... | ... | 261 | | Intensive | 150, 200, | Gbps} | | | 262 | | | 250, 300 | | | | 263 | | | Gbps} | | | | 264 | Large-2 | Compute | {100, 200, | {8,16 GB,160 | ... | ... | 265 | | Intensive | 300, 400, | GB,1 Gbps} | | | 266 | | | 500, 600 | | | | 267 | | | Gbps} | | | | 268 | ... | ... | ... | ... | ... | ... | 269 +----------+-----------+-------------+------------------+-----+-----+ 271 Table 1: ALTO Property Map 273 5. IANA Considerations 275 This document includes no request to IANA. 277 6. Security Considerations 279 TBD. 281 7. Conclusions 283 Telco networks will increasingly contain a number of interconnected 284 data centers, of different size and characteristics, allowing 285 flexibility in the dynamic deployment of functions and applications 286 for advance services. The overall objective of this document is to 287 begin a discussion in the ALTO WG regarding the suitability of the 288 ALTO protocol for determining where to deploy a function or 289 application in distributed computing environments. The result of 290 such discussions will be reflected in future versions of this draft. 292 8. References 294 8.1. Normative References 296 [RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S., 297 Previdi, S., Roome, W., Shalunov, S., and R. Woundy, 298 "Application-Layer Traffic Optimization (ALTO) Protocol", 299 RFC 7285, DOI 10.17487/RFC7285, September 2014, 300 . 302 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 303 S. Ray, "North-Bound Distribution of Link-State and 304 Traffic Engineering (TE) Information Using BGP", RFC 7752, 305 DOI 10.17487/RFC7752, March 2016, 306 . 308 [RFC8189] Randriamasy, S., Roome, W., and N. Schwan, "Multi-Cost 309 Application-Layer Traffic Optimization (ALTO)", RFC 8189, 310 DOI 10.17487/RFC8189, October 2017, 311 . 313 8.2. Informative References 315 [CNTT] "Common NFVI for Telco Reference Model, Release 3.0", May 316 2020, . 318 [DRAFT-PM] 319 Roome, W., Randriamasy, S., Yang, Y., Zhang, J., and K. 320 Gao, "Unified Properties for the ALTO Protocol", draft- 321 ietf-alto-unified-props-new-09 (work in progress), 322 September 2019. 324 [I-D.ietf-teas-sf-aware-topo-model] 325 Bryskin, I., Liu, X., Lee, Y., Guichard, J., Contreras, 326 L., Ceccarelli, D., and J. Tantsura, "SF Aware TE Topology 327 YANG Model", draft-ietf-teas-sf-aware-topo-model-03 (work 328 in progress), March 2019. 330 Authors' Addresses 332 Luis M. Contreras 333 Telefonica 334 Ronda de la Comunicacion, s/n 335 Madrid 28050 336 Spain 338 Email: luismiguel.contrerasmurillo@telefonica.com 339 URI: http://lmcontreras.com/ 341 Danny Alex Lachos Perez 342 University of Campinas 343 Av. Albert Einstein 400 344 Campinas, Sao Paulo 13083-970 345 Brazil 347 Email: dlachosp@dca.fee.unicamp.br 348 URI: https://intrig.dca.fee.unicamp.br/danny-lachos/ 350 Christian Esteve Rothenberg 351 University of Campinas 352 Av. Albert Einstein 400 353 Campinas, Sao Paulo 13083-970 354 Brazil 356 Email: chesteve@dca.fee.unicamp.br 357 URI: https://intrig.dca.fee.unicamp.br/christian/