idnits 2.17.1 draft-bernardos-sfc-nsh-distributed-control-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: ---------------------------------------------------------------------------- == There are 11 instances of lines with non-ascii characters in the document. 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 (21 March 2022) is 766 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-06) exists of draft-bernardos-sfc-distributed-control-05 Summary: 0 errors (**), 0 flaws (~~), 3 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: 22 September 2022 InterDigital 6 21 March 2022 8 NSH extensions for local distributed SFC control 9 draft-bernardos-sfc-nsh-distributed-control-04 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. In order to set up and maintain SFC instances, a 16 control plane is required, which typically is centralized. In 17 certain environments, such as fog computing ones, such centralized 18 control might not be feasible, calling for distributed SFC control 19 solutions. This document specifies several NSH extensions to provide 20 in-band SFC control signaling. 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 22 September 2022. 39 Copyright Notice 41 Copyright (c) 2022 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 (https://trustee.ietf.org/ 46 license-info) in effect on the date of publication of this document. 47 Please review these documents carefully, as they describe your rights 48 and restrictions with respect to this document. Code Components 49 extracted from this document must include Revised BSD License text as 50 described in Section 4.e of the Trust Legal Provisions and are 51 provided without warranty as described in the Revised BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 3. Local SFC control signaling extending NSH . . . . . . . . . . 4 58 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 59 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 60 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 61 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 62 7.1. Normative References . . . . . . . . . . . . . . . . . . 8 63 7.2. Informative References . . . . . . . . . . . . . . . . . 8 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 66 1. Introduction 68 Virtualization of functions provides operators with tools to deploy 69 new services much faster, as compared to the traditional use of 70 monolithic and tightly integrated dedicated machinery. As a natural 71 next step, mobile network operators need to re-think how to evolve 72 their existing network infrastructures and how to deploy new ones to 73 address the challenges posed by the increasing customers' demands, as 74 well as by the huge competition among operators. All these changes 75 are triggering the need for a modification in the way operators and 76 infrastructure providers operate their networks, as they need to 77 significantly reduce the costs incurred in deploying a new service 78 and operating it. Some of the mechanisms that are being considered 79 and already adopted by operators include: sharing of network 80 infrastructure to reduce costs, virtualization of core servers 81 running in data centers as a way of supporting their load-aware 82 elastic dimensioning, and dynamic energy policies to reduce the 83 monthly electricity bill. However, this has proved to be tough to 84 put in practice, and not enough. Indeed, it is not easy to deploy 85 new mechanisms in a running operational network due to the high 86 dependency on proprietary (and sometime obscure) protocols and 87 interfaces, which are complex to manage and often require configuring 88 multiple devices in a decentralized way. 90 Service Functions are widely deployed and essential in many networks. 91 These Service Functions provide a range of features such as security, 92 WAN acceleration, and server load balancing. Service Functions may 93 be instantiated at different points in the network infrastructure 94 such as data center, the WAN, the RAN, and even on mobile nodes. 96 Service functions (SFs), also referred to as VNFs, or just functions, 97 are hosted on compute, storage and networking resources. The hosting 98 environment of a function is called Service Function Provider or 99 NFVI-PoP (using ETSI NFV terminology). 101 Services are typically formed as a composition of SFs (VNFs), with 102 each SF providing a specific function of the whole service. Services 103 also referred to as Network Services (NS), according to ETSI 104 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 The concept of fog computing has emerged driven by the Internet of 119 Things (IoT) due to the need of handling the data generated from the 120 end-user devices. The term fog is referred to any networked 121 computational resource in the continuum between things and cloud. A 122 fog node may therefore be an infrastructure network node such as an 123 eNodeB or gNodeB, an edge server, a customer premises equipment 124 (CPE), or even a user equipment (UE) terminal node such as a laptop, 125 a smartphone, or a computing unit on-board a vehicle, robot or drone. 127 In fog computing, the functions composing an SFC are hosted on 128 resources that are inherently heterogeneous, volatile and mobile 129 [I-D.bernardos-sfc-fog-ran]. This means that resources might appear 130 and disappear, and the connectivity characteristics between these 131 resources may also change dynamically. These scenarios call for 132 distributed SFC control solutions, where there are SFC pseudo 133 controllers, enabling autonomous SFC self-orchestration capabilities. 134 The concept of SFC pseudo controller (P-CTRL) is described in 135 [I-D.bernardos-sfc-distributed-control], as well different procedures 136 for their discovery and initialization. 138 This document specifies several NSH extensions to provide in-band SFC 139 control signaling. 141 2. Terminology 143 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 144 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 145 document are to be interpreted as described in [RFC2119]. 147 The following terms used in this document are defined by the IETF in 148 [RFC7665]: 150 Service Function (SF): a function that is responsible for specific 151 treatment of received packets (e.g., firewall, load balancer). 153 Service Function Chain (SFC): for a given service, the abstracted 154 view of the required service functions and the order in which they 155 are to be applied. This is somehow equivalent to the Network 156 Function Forwarding Graph (NF-FG) at ETSI. 158 Service Function Forwarder (SFF): A service function forwarder is 159 responsible for forwarding traffic to one or more connected 160 service functions according to information carried in the SFC 161 encapsulation, as well as handling traffic coming back from the 162 SF. 164 SFI: SF instance. 166 Service Function Path (SFP): the selection of specific service 167 function instances on specific network nodes to form a service 168 graph through which an SFC is instantiated. 170 The following terms are used in this document: 172 SFC Pseudo Controller (P-CTRL): logical entity 173 [I-D.bernardos-sfc-distributed-control], complementing the SFC 174 controller/orchestrator found in current architectures and 175 deployments. It is service specific, meaning that it is defined 176 and meaningful in the context of a given network service. 177 Compared to existing SFC controllers/orchestrators, which manage 178 multiple SFCs instantiated over a common infrastructure, pseudo 179 controllers are constrained to service specific lifecycle 180 management. 182 SFC Central Controller (C-CTRL): central control plane logical 183 entity in charge of configuring and managing the SFC components 184 [RFC7665]. 186 3. Local SFC control signaling extending NSH 187 o 188 node B | 189 +--------|-+ F1+-·-·-+F2+-·-·-+F3 SFC 190 | ········ | 191 | |P-CTRL| | 192 | ········ | 193 +-·-·-+F2 | 194 o / +---+------+ ________ 195 | · · _( )_ 196 +--------|-+ / / _( +--------+ )_ 197 | | · · (_ | C-CTRL | _) 198 | | / / (_+--------+_) 199 | |· | (________) 200 | +-·-·/ · 201 | F1 | | ( (oo) ) 202 +----------+ · o /\ ········ 203 node A | | /\/\ |P-CTRL| 204 +-----·--|-+ /\/\/\········ 205 | | | /\/ \/\ F3 206 | · | node D 207 | | | 208 | + | 209 | | 210 +----------+ 211 node C 213 Figure 1: Example SFC scenario 215 Figure 1 shows an exemplary scenario to show the use of the new NSH 216 extensions. In this scenario, there is no mobility, so nodes are not 217 moving out of radio coverage. In this scenario, at a given point in 218 time the service demands increase, which requires F2 (running at node 219 B) and F3 (running at node D) to have more resources allocated, as 220 otherwise the service would not meet the required SLA. This is 221 detected by the P-CTRL through service-specific local OAM monitoring. 222 Once detected the need of scaling up the resources at nodes B and D, 223 P-CTRL notifies this through in-band signaling in the actual data 224 packets processed by the SFC. This is shown in Figure 2. Note that 225 the use of in-band signaling provides a more efficient way of 226 conveying the signaling, as well as supports multiple NS lifecycle 227 management operations (even addressing different nodes) to be 228 conveyed in a single message. 230 +--------+ +--------+ +--------+ 231 | F1@A | | F2@B | | F3@D | 232 +--------+ +--------+ +--------+ 234 +--------+ +--------+ +--------+ 235 |Transp. | |Transp. | |Transp. | 236 | header | | header | | header | 237 +--------+ +--------+ +--------+ 238 | NSH | | NSH | | NSH | 239 | header | | header | | header | 240 | F3@D | | F3@D | | F3@D | 241 |scale up| |scale up| |scale up| 242 | F2@B | | F2@B | | | 243 |scale up| |scale up| | | 244 +--------+ +--------+ +--------+ +--------+ +--------+ 245 | Packet | | Packet | | Packet | | Packet | | Packet | 246 +--------+ +--------+ +--------+ +--------+ +--------+ 247 ===> ===> ===> ===> ===> 249 Figure 2: In-band NS lifecycle management signaling extending NSH 251 The NS lifecycle management commands conveyed in the NSH are 252 transported as a new NSH metadata (MD) type (e.g., Type 3, as current 253 NSH specifications only support 2 types), as shown next: 255 0 1 2 3 256 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 |Ver|O|U| TTL | Length |U|U|U|U|MD Type| Next Protocol | 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 | Service Path Identifier | Service Index | 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 | | 263 ~ Variable-Length NS lifecycle management commands ~ 264 | | 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 The format of the new variable-length field for NS lifecycle 268 management commands is shown next: 270 0 1 2 3 271 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 | NS lifecycle cmd | Type |U| Length | 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 | Variable-Length Metadata | 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 * NS lifecycle cmd: the NS lifecycle management command. This is a 278 non-limiting list of the commands: 280 - Scale in. 282 - Scale out. 284 - Scale up. 286 - Scale down. 288 - Instantiate function. 290 - Terminate function. 292 - Configure function. 294 - Upgrade function. 296 - Update function. 298 - Update function. 300 - Onboard VNFD. 302 - Onboard OAMD. 304 - Sync state. 306 - Request to overcome CTRL. 308 - CTRL activation. 310 * Type: indicates the explicit type of command carried out. This 311 depends on the orchestration framework implementation. 313 * Unassigned bit: one unassigned bit is available for future use. 314 This bit MUST NOT be set, and it MUST be ignored on receipt. 316 * Unassigned bit: one unassigned bit is available for future use. 317 This bit MUST NOT be set, and it MUST be ignored on receipt. 319 4. IANA Considerations 321 N/A. 323 5. Security Considerations 325 TBD. 327 6. Acknowledgments 329 The work in this draft has been partially supported by the H2020 330 5Growth (Grant 856709) and 5G-DIVE projects (Grant 859881). 332 7. References 334 7.1. Normative References 336 [I-D.bernardos-sfc-distributed-control] 337 Bernardos, C. J. and A. Mourad, "Distributed SFC control 338 for fog environments", Work in Progress, Internet-Draft, 339 draft-bernardos-sfc-distributed-control-05, 27 January 340 2022, . 343 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 344 Requirement Levels", BCP 14, RFC 2119, 345 DOI 10.17487/RFC2119, March 1997, 346 . 348 7.2. Informative References 350 [I-D.bernardos-sfc-fog-ran] 351 Bernardos, C. J. and A. Mourad, "Service Function Chaining 352 Use Cases in Fog RAN", Work in Progress, Internet-Draft, 353 draft-bernardos-sfc-fog-ran-10, 22 October 2021, 354 . 357 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 358 Chaining (SFC) Architecture", RFC 7665, 359 DOI 10.17487/RFC7665, October 2015, 360 . 362 Authors' Addresses 364 Carlos J. Bernardos 365 Universidad Carlos III de Madrid 366 Av. Universidad, 30 367 28911 Leganes, Madrid 368 Spain 369 Phone: +34 91624 6236 370 Email: cjbc@it.uc3m.es 371 URI: http://www.it.uc3m.es/cjbc/ 373 Alain Mourad 374 InterDigital Europe 375 Email: Alain.Mourad@InterDigital.com 376 URI: http://www.InterDigital.com/