idnits 2.17.1 draft-bernardos-sfc-discovery-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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (September 7, 2019) is 1664 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-10) exists of draft-bernardos-sfc-fog-ran-05 == Outdated reference: A later version (-18) exists of draft-ietf-bess-nsh-bgp-control-plane-12 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SFC WG CJ. Bernardos 3 Internet-Draft UC3M 4 Intended status: Experimental A. Mourad 5 Expires: March 10, 2020 InterDigital 6 September 7, 2019 8 Service Function discovery in fog environments 9 draft-bernardos-sfc-discovery-03 11 Abstract 13 Service function chaining (SFC) allows the instantiation of an 14 ordered set of service functions and subsequent "steering" of traffic 15 through them. Service functions provide an specific treatment of 16 received packets, therefore they need to be known so they can be used 17 in a given service composition via SFC. This document discusses the 18 need for service function discovery mechanisms and propose some 19 solutions for sfc-aware nodes to discover available service functions 20 in fog environments. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on March 10, 2020. 39 Copyright Notice 41 Copyright (c) 2019 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Problem statement . . . . . . . . . . . . . . . . . . . . . . 4 59 3.1. Discovery of SF in a multi-provider fog/edge environment 4 60 4. Network-based SF discovery . . . . . . . . . . . . . . . . . 6 61 4.1. ICMPv6-based SF discovery . . . . . . . . . . . . . . . . 8 62 4.2. DHCPv6-based SF discovery . . . . . . . . . . . . . . . . 8 63 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 64 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 65 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 66 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 67 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 68 8.2. Informative References . . . . . . . . . . . . . . . . . 9 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 71 1. Introduction 73 Virtualization of functions provides operators with tools to deploy 74 new services much faster, as compared to the traditional use of 75 monolithic and tightly integrated dedicated machinery. As a natural 76 next step, mobile network operators need to re-think how to evolve 77 their existing network infrastructures and how to deploy new ones to 78 address the challenges posed by the increasing customers' demands, as 79 well as by the huge competition among operators. All these changes 80 are triggering the need for a modification in the way operators and 81 infrastructure providers operate their networks, as they need to 82 significantly reduce the costs incurred in deploying a new service 83 and operating it. Some of the mechanisms that are being considered 84 and already adopted by operators include: sharing of network 85 infrastructure to reduce costs, virtualization of core servers 86 running in data centers as a way of supporting their load-aware 87 elastic dimensioning, and dynamic energy policies to reduce the 88 monthly electricity bill. However, this has proved to be tough to 89 put in practice, and not enough. Indeed, it is not easy to deploy 90 new mechanisms in a running operational network due to the high 91 dependency on proprietary (and sometime obscure) protocols and 92 interfaces, which are complex to manage and often require configuring 93 multiple devices in a decentralized way. 95 Service Functions are widely deployed and essential in many networks. 96 These Service Functions provide a range of features such as security, 97 WAN acceleration, and server load balancing. Service Functions may 98 be instantiated at different points in the network infrastructure 99 such as data center, the WAN, the RAN, and even on mobile nodes. 101 Service functions (SFs), also referred to as VNFs, or just functions, 102 are hosted on compute, storage and networking resources. The hosting 103 environment of a function is called Service Function Provider or 104 NFVI-PoP (using ETSI NFV terminology). 106 With the arrival of virtualization, the deployment model for service 107 function is evolving to one where the traffic is steered through the 108 functions wherever they are deployed (functions do not need to be 109 deployed in the traffic path anymore). For a given service, the 110 abstracted view of the required service functions and the order in 111 which they are to be applied is called a Service Function Chain 112 (SFC). An SFC is instantiated through selection of specific service 113 function instances on specific network nodes to form a service graph: 114 this is called a Service Function Path (SFP). The service functions 115 may be applied at any layer within the network protocol stack 116 (network layer, transport layer, application layer, etc.). 118 A mobile terminal can benefit from using service function chaining at 119 the edge/fog to enhance existing applications or to enable new ones. 120 In order to do so, discovery of available service functions is 121 required. This document focuses on this aspect. 123 2. Terminology 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 127 document are to be interpreted as described in [RFC2119]. 129 While [RFC2119] describes interpretations of these key words in terms 130 of protocol specifications and implementations, they are used in this 131 document to describe requirements for the SFC mechanisms to 132 efficiently enable fog RAN. 134 The following terms used in this document are defined by the IETF in 135 [RFC7665] and [I-D.ietf-bess-nsh-bgp-control-plane]: 137 Service Function (SF): a function that is responsible for specific 138 treatment of received packets (e.g., firewall, load balancer). 140 Service Function Chain (SFC): for a given service, the abstracted 141 view of the required service functions and the order in which they 142 are to be applied. This is somehow equivalent to the Network 143 Function Forwarding Graph (NF-FG) at ETSI. 145 Service Function Forwarder (SFF): A service function forwarder is 146 responsible for forwarding traffic to one or more connected 147 service functions according to information carried in the SFC 148 encapsulation, as well as handling traffic coming back from the 149 SF. 151 SFI: SF instance. 153 Service Function Path (SFP): the selection of specific service 154 function instances on specific network nodes to form a service 155 graph through which an SFC is instantiated. 157 A Service Function Type (SFT) that is the category of Service 158 Function that is provided (such as "firewall"). 160 3. Problem statement 162 [RFC7665] describes an architecture for the specification, creation, 163 and ongoing maintenance of Service Function Chains (SFCs) in a 164 network. It includes architectural concepts, principles, and 165 components used in the construction of composite services through 166 deployment of SFCs. In this architecture, a key element is the 167 service function (SF), which is a function that is responsible for 168 specific treatment of received packets (e.g., a firewall). 170 So far, how the SFs are discovered and composed has been out of the 171 scope of discussions in IETF. There is however a need to define 172 mechanisms that allow SF discovery in fog environments 173 [I-D.bernardos-sfc-fog-ran]. Note that the mechanisms described in 174 this document address fog environments. There are other mechanisms 175 described, like [I-D.ietf-bess-nsh-bgp-control-plane], that cover 176 generic SF discovery in more traditional environments. Some of the 177 solutions described in the present document might be of applicable to 178 other scenarios as well. 180 3.1. Discovery of SF in a multi-provider fog/edge environment 182 The need to provide networking, computing, and storage capabilities 183 closer to the users has recently emerged, due to the demands from 5G 184 applications of very low latency, leading to what is known today as 185 the concept of intelligent edge. ETSI has been the first to address 186 this need recently by developing the framework of mobile edge 187 computing (MEC). Such an intelligent edge could not be envisaged 188 without virtualization. Beyond applications, it raises a clear 189 opportunity for networking functions to execute at the edge 190 benefiting from inherent low latencies. Being in close proximity to 191 the access, the edge becomes an attractive place for hosting 192 different functions, saving bandwidth in their respective domains and 193 offering local breakout options where required. Whilst it is 194 appreciated the particular challenge for the intelligent edge concept 195 in dealing with mobile users, the edge virtualization substrate has 196 been largely assumed to be fixed or stationary. Although little 197 developed, the intelligent edge concept is being extended further to 198 scenarios where for example the edge computing substrate is on the 199 move, e.g., on-board a car or a train, or that it is distributed 200 further down the edge, even integrating resources from different 201 stakeholders, into what is known as the fog. 203 Service composition is a powerful tool which can provide significant 204 benefits when applied in a softwarized network environment. While it 205 is being explored in the core part of networks to compose services 206 using DPIs (Deep Packet Inspections), firewalls, parental control, 207 video accelerators, etc., its applicability to the RAN (Radio Access 208 Network), and in particular to the edge and the fog, has not been 209 explored yet. 211 Running functions (standalone functions or service function chains) 212 at the edge of the network has clear advantages. For example, it 213 enables offloading functions from the end-user terminal so that it 214 can become more efficient in terms of cost and energy consumption. 216 A mobile terminal can benefit from using service function chaining at 217 the edge/fog to enhance existing applications or to enable new ones. 218 Some examples of such applications are: privacy enhancement by local 219 anchoring, opportunistic local breakout, assisted encryption, video 220 transcoding, personal firewalling, etc. The mobile terminal might 221 look for function hosting opportunities at the edge for various 222 reasons such as: 224 o to increase battery life in critical situations by offloading 225 energy demanding operations (e.g., video transcoding, augmented 226 reality) to the edge/cloud; 228 o to reduce communications latency (e.g., by using local breakout at 229 the edge for selected applications demanding low latency); 231 o to enable new functions (e.g., privacy improvements, personal 232 firewalling) which demand additional intelligence/resources at the 233 network; 235 o to benefit from context information available at the edge (e.g., 236 enrich networking decisions by executing functions at the edge 237 using RAN information); 239 Several key challenges need to be addressed to enable controlled 240 service function chaining for a mobile terminal, and one of them is 241 the discovery of the functions available for use at the Fog/Edge/ 242 Cloud. 244 4. Network-based SF discovery 246 In this section we describe several mechanisms for a mobile SFC-aware 247 node to discover what SFs are available in the network. Different 248 alternatives (protocol containers) are considered to enable the 249 mobile node to obtain the following information per SF available: 251 o Service Function Type, identifying the category of SF provided. 253 o SFC-aware: Yes/No. Indicates if the SF is SFC-aware. 255 o Route Distinguisher (RD): IP address indicating the location of 256 the SF(I). 258 o Pricing/costs details. 260 o Migration capabilities of the SF: whether a given function can be 261 moved to another provider (potentially including information about 262 compatible providers topologically close). 264 o Mobility of the device hosting the SF, with e.g. the following 265 sub-options: 267 Level: no, low, high; or a corresponding scale (e.g., 1 to 10). 269 Current geographical area (e.g., GPS coordinates, post code). 271 Target moving area (e.g., GPS coordinates, post code). 273 o Power source of the device hosting the SF, with e.g. the following 274 sub-options: 276 Battery: Yes/No. If Yes, the following sub-options could be 277 defined: 279 Capacity of the battery (e.g., mmWh). 281 Charge status (e.g., %). 283 Lifetime (e.g., minutes). 285 Figure 1 shows the generic mechanism for SF discovery, with network 286 support. In this scenario, SFs (which might belong to different 287 administrative domains) are previously registered at the network, 288 which can then reply to requests sent from mobile nodes that have 289 just attached to the network. A request might optionally include the 290 SFs of interest for the terminal, instead of a request for all known 291 SFs. 293 The network might also send periodic advertisements in addition to 294 responses to solicited requests. These responses/advertisements 295 include the information about known SFs (or only about the ones 296 queried by the terminal), which can then be used by the terminal to 297 decide whether to use (some of) them in a certain SFC. How the 298 mobile terminal then configures this SFC is not covered in this 299 document. 301 ___________ 302 _( )_ 303 _( SF1 SF2 )_ 304 ------------ ----------- _( SF3 )_ 305 | terminal | | network |-(_ SF4 SF5 _) 306 ------------ ----------- (_ SF6 SF7 _) 307 | | (_ SF8 _) 308 XXX (1. attachment) | (___________) 309 | | 310 +---2. Request (optional)------>| 311 | | 312 |<--------3. Response/Advert.---| 313 | (SF1,SF2...,SF8) | 314 | | 316 Figure 1: SF (network) discovery 318 In addition to the discovery of SFs at the infrastructure, mobile 319 terminals can also host SF(I)s, and therefore they also need to be 320 discovered. A similar approach can be followed, as showin in 321 Figure 2. 323 ------------ 324 | SF3 | 325 ------------ | terminal | ------------ 326 | SF1 SF2 | ------------ | SF4 SF5 | 327 | terminal | | | terminal | 328 ------------ | ------------ 329 | | | 330 +--1. Request->+-------------->| 331 | (SF1,SF2) | | 332 |<----------------2. Response--+ 333 | (SF4,SF5) | 334 |<-2. Response-+ | 335 | (SF3) | | 336 | | | 338 Figure 2: SF (mobiles) discovery 340 SFs might belong to different administrative domains. This might 341 require the use of additional security and authentication mechanisms. 342 Policies can be used (both in single and multi-domain scenarios) to 343 adapt/limit the type and number of SFs that are advertised, depending 344 on the relationship of the requester and the advertiser. 346 Next sections describe different protocol alternatives for this SF 347 discovery in fog environments. 349 4.1. ICMPv6-based SF discovery 351 TBD. 353 4.2. DHCPv6-based SF discovery 355 TBD. 357 5. IANA Considerations 359 N/A. 361 6. Security Considerations 363 TBD. 365 7. Acknowledgments 367 The work in this draft will be further developed and explored under 368 the framework of the H2020 5G-CORAL project (Grant 761586). 370 8. References 372 8.1. Normative References 374 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 375 Requirement Levels", BCP 14, RFC 2119, 376 DOI 10.17487/RFC2119, March 1997, 377 . 379 8.2. Informative References 381 [I-D.bernardos-sfc-fog-ran] 382 Bernardos, C., Rahman, A., and A. Mourad, "Service 383 Function Chaining Use Cases in Fog RAN", draft-bernardos- 384 sfc-fog-ran-05 (work in progress), March 2019. 386 [I-D.ietf-bess-nsh-bgp-control-plane] 387 Farrel, A., Drake, J., Rosen, E., Uttaro, J., and L. 388 Jalil, "BGP Control Plane for NSH SFC", draft-ietf-bess- 389 nsh-bgp-control-plane-12 (work in progress), August 2019. 391 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 392 Chaining (SFC) Architecture", RFC 7665, 393 DOI 10.17487/RFC7665, October 2015, 394 . 396 Authors' Addresses 398 Carlos J. Bernardos 399 Universidad Carlos III de Madrid 400 Av. Universidad, 30 401 Leganes, Madrid 28911 402 Spain 404 Phone: +34 91624 6236 405 Email: cjbc@it.uc3m.es 406 URI: http://www.it.uc3m.es/cjbc/ 408 Alain Mourad 409 InterDigital Europe 411 Email: Alain.Mourad@InterDigital.com 412 URI: http://www.InterDigital.com/