idnits 2.17.1 draft-bernardos-dmm-sfc-mobility-00.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 (March 9, 2020) is 1508 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-01 == Outdated reference: A later version (-10) exists of draft-bernardos-sfc-fog-ran-06 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: September 10, 2020 InterDigital 6 March 9, 2020 8 SFC function mobility with Mobile IPv6 9 draft-bernardos-dmm-sfc-mobility-00 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 Mobile IPv6 extensions to enable 20 function migration in SFC. 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 September 10, 2020. 39 Copyright Notice 41 Copyright (c) 2020 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3. Function mobility signaling extending Mobile IPv6 . . . . . . 5 59 4. Mobile IPv6 extensions for SFC function mobility . . . . . . 7 60 4.1. Service Path Update . . . . . . . . . . . . . . . . . . . 7 61 4.2. Service Path Acknowledgement . . . . . . . . . . . . . . 9 62 4.3. New Mobility options . . . . . . . . . . . . . . . . . . 10 63 4.3.1. Network Service ID . . . . . . . . . . . . . . . . . 10 64 4.3.2. SFC node . . . . . . . . . . . . . . . . . . . . . . 11 65 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 66 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 67 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 68 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 69 8.1. Normative References . . . . . . . . . . . . . . . . . . 12 70 8.2. Informative References . . . . . . . . . . . . . . . . . 12 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 73 1. Introduction 75 Virtualization of functions provides operators with tools to deploy 76 new services much faster, as compared to the traditional use of 77 monolithic and tightly integrated dedicated machinery. As a natural 78 next step, mobile network operators need to re-think how to evolve 79 their existing network infrastructures and how to deploy new ones to 80 address the challenges posed by the increasing customers' demands, as 81 well as by the huge competition among operators. All these changes 82 are triggering the need for a modification in the way operators and 83 infrastructure providers operate their networks, as they need to 84 significantly reduce the costs incurred in deploying a new service 85 and operating it. Some of the mechanisms that are being considered 86 and already adopted by operators include: sharing of network 87 infrastructure to reduce costs, virtualization of core servers 88 running in data centers as a way of supporting their load-aware 89 elastic dimensioning, and dynamic energy policies to reduce the 90 monthly electricity bill. However, this has proved to be tough to 91 put in practice, and not enough. Indeed, it is not easy to deploy 92 new mechanisms in a running operational network due to the high 93 dependency on proprietary (and sometime obscure) protocols and 94 interfaces, which are complex to manage and often require configuring 95 multiple devices in a decentralized way. 97 Service Functions are widely deployed and essential in many networks. 98 These Service Functions provide a range of features such as security, 99 WAN acceleration, and server load balancing. Service Functions may 100 be instantiated at different points in the network infrastructure 101 such as data center, the WAN, the RAN, and even on mobile nodes. 103 Service functions (SFs), also referred to as VNFs, or just functions, 104 are hosted on compute, storage and networking resources. The hosting 105 environment of a function is called Service Function Provider or 106 NFVI-PoP (using ETSI NFV terminology). 108 Services are typically formed as a composition of SFs (VNFs), with 109 each SF providing a specific function of the whole service. Services 110 also referred to as Network Services (NS), according to ETSI 111 terminology. 113 With the arrival of virtualization, the deployment model for service 114 function is evolving to one where the traffic is steered through the 115 functions wherever they are deployed (functions do not need to be 116 deployed in the traffic path anymore). For a given service, the 117 abstracted view of the required service functions and the order in 118 which they are to be applied is called a Service Function Chain 119 (SFC). An SFC is instantiated through selection of specific service 120 function instances on specific network nodes to form a service graph: 121 this is called a Service Function Path (SFP). The service functions 122 may be applied at any layer within the network protocol stack 123 (network layer, transport layer, application layer, etc.). 125 The concept of fog computing has emerged driven by the Internet of 126 Things (IoT) due to the need of handling the data generated from the 127 end-user devices. The term fog is referred to any networked 128 computational resource in the continuum between things and cloud. A 129 fog node may therefore be an infrastructure network node such as an 130 eNodeB or gNodeB, an edge server, a customer premises equipment 131 (CPE), or even a user equipment (UE) terminal node such as a laptop, 132 a smartphone, or a computing unit on-board a vehicle, robot or drone. 134 In fog computing, the functions composing an SFC are hosted on 135 resources that are inherently heterogeneous, volatile and mobile 136 [I-D.bernardos-sfc-fog-ran]. This means that resources might appear 137 and disappear, and the connectivity characteristics between these 138 resources may also change dynamically. These scenarios call for 139 distributed SFC control solutions, where there are SFC pseudo 140 controllers, enabling autonomous SFC self-orchestration capabilities. 141 The concept of SFC pseudo controller (P-CTRL) is described in 142 [I-D.bernardos-sfc-distributed-control], as well different procedures 143 for their discovery and initialization. 145 This document specifies Mobile IPv6 extensions to enable function 146 migration in SFC. 148 2. Terminology 150 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 151 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 152 document are to be interpreted as described in [RFC2119]. 154 The following terms used in this document are defined by the IETF in 155 [RFC7665]: 157 Service Function (SF): a function that is responsible for specific 158 treatment of received packets (e.g., firewall, load balancer). 160 Service Function Chain (SFC): for a given service, the abstracted 161 view of the required service functions and the order in which they 162 are to be applied. This is somehow equivalent to the Network 163 Function Forwarding Graph (NF-FG) at ETSI. 165 Service Function Forwarder (SFF): A service function forwarder is 166 responsible for forwarding traffic to one or more connected 167 service functions according to information carried in the SFC 168 encapsulation, as well as handling traffic coming back from the 169 SF. 171 SFI: SF instance. 173 Service Function Path (SFP): the selection of specific service 174 function instances on specific network nodes to form a service 175 graph through which an SFC is instantiated. 177 The following terms are used in this document: 179 SFC Pseudo Controller (P-CTRL): logical entity 180 [I-D.bernardos-sfc-distributed-control], complementing the SFC 181 controller/orchestrator found in current architectures and 182 deployments. It is service specific, meaning that it is defined 183 and meaningful in the context of a given network service. 184 Compared to existing SFC controllers/orchestrators, which manage 185 multiple SFCs instantiated over a common infrastructure, pseudo 186 controllers are constrained to service specific lifecycle 187 management. 189 SFC Central Controller (C-CTRL): central control plane logical 190 entity in charge of configuring and managing the SFC components 191 [RFC7665]. 193 3. Function mobility signaling extending Mobile IPv6 195 This section describes Mobile IPv6 (MIPv6) extensions to perform 196 function migration/mobility. This is an example of NS lifecycle 197 management operation: the update of the location of a given function. 198 We refer to this as function mobility, though it might involve or not 199 the actual migration of the function. 201 +---------+ +----+ +---------+ +---------+ +----------+ +------+ 202 | node A | | C | | node B | | node D | | 3GPP | | SFC | 203 |P-CTRL F1| | F3 | |P-CTRL F2| |P-CTRL F3| |ctrl plane| |C-CTRL| 204 +--+----+-+ +----+ +--+----+-+ +--+----+-+ +----------+ +------+ 205 | | | | | | | | | 206 | F1@A<->F2@B<->F3@D SFC network service | | 207 | |<-.-.-.-.-.-.-.-.-.>|<-.-.-.-.->| | | 208 | | | | | | | | | 209 | | | Node B moves out of | | 210 | | | the coverage of node D | | 211 | | | | | | | | | 212 | 0. Service specific OAM monitoring | | | 213 |<-.>|<-.-.->|<-.-.-.-.-.>| | | | | 214 |<-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.->| | 215 | | | | | | | | | 216 P-CTRL@A detects D disconnection | | | | 217 and decides to place F3 at node C | | | | 218 | | | | | | | | | 219 | 1a. SPU[NS_ID,(F3,C)] | | | | | 220 |-.-.-.-.-.-.-.-.-.-.-.-.>| | | | | 221 | 1b. SPA[NS_ID] | | | | | 222 |<-.-.-.-.-.-.-.-.-.-.-.-.| | | | | 223 | 1c. SPU[NS_ID,(F3,C),(F2,B),(F1,A)] | | | 224 |-.-.-.-.-.->| | | | | | | 225 | 1d. SPA[NS_ID] | | | | | | 226 |<-.-.-.-.-.-| | | | | | | 227 | | | | | | | | | 228 | 2. Updated F1@A<->F2@B<->F3@C SFC network service | 229 | |<-.-.-.-.-.-.-.-.-.>| | | | | 230 | | |<-.-.-.-.-.>| | | | | 231 | | | | | | | | | 232 | 3a. SPU[NS_ID,(F3,C),(F2,B),(F1,A)] | | 233 |-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.->| 234 | | | | | | | 3b. SPA[NS_ID] | 235 |<-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-| 236 | 3c. SPU[NS_ID,(F3,C)] | | | | | 237 |-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.>| | | 238 | | | | 3d. SPA[NS_ID] | | | 239 |<-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-| 240 | | | | | | | | | 242 Figure 1: SFC mobility signaling 244 We next describe the signaling extensions with an example. For the 245 sake of this example we assume that the function which location is 246 updated is already available at the new target node (if not, it has 247 to be previously migrated using any of the solutions available in the 248 state-of-the-art). The different steps are described next: 250 o (The network service F1--F2--F3 is already instantiated and 251 running. The only SFC P-CTRL active at this point is running at 252 node A, and there is a candidate one at node B.) 254 o UE node B is moving out of the coverage of gNB node D. 256 1. This movement is detected by the active (designated) pseudo 257 controller running at node A, thanks to local (service specific 258 OAM) monitoring. 260 2. The active pseudo controller sends mobility signaling to all 261 affected nodes, in this case node B (it has to update the network 262 service path due to the F3 location update) and node C (as it 263 starts being part of the SFC, hosting F3). The signaling 264 messages are new mobility messages: Service Path Update (SPU) and 265 Service Path Acknowledgement (SPA), which contain: (i) the 266 identifier of the network service (NS_ID), and (ii) the updated 267 elements of the network service path: (ID, updated location). 268 The SPA acknowledges that the procedure has been performed 269 correctly. 271 3. The network service F1--F2--F3 is updated so it now runs at A, B 272 and C. 274 4. Whenever connectivity with nodes D and the centralized SFC 275 controller is back, the pseudo controller also informs about the 276 updated SFC path, sending SPU messages, which are acknowledged 277 with SPA messages. 279 Note that this is an example of NS lifecycle management (function 280 mobility) by a SFC pseudo controller, but that other operations are 281 also possible, such as (non-limiting examples): scaling up/down, 282 scaling in/out, termination, etc. 284 4. Mobile IPv6 extensions for SFC function mobility 286 4.1. Service Path Update 288 The Service Path Update (SPU) message is used by a CTRL to notify 289 nodes in an SFC (e.g., SFF) of an update of the service path. 291 The Service Path Update uses the MH Type value TBD. When this value 292 is indicated in the MH Type field, the format of the Message Data 293 field in the Mobility Header is as follows: 295 0 1 2 3 296 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 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 | Sequence # | 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 |A| Reserved | Lifetime | 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 | | 303 . . 304 . Mobility Options . 305 . . 306 | | 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 Sequence # 311 A 16-bit unsigned integer used by the receiving node to sequence 312 Binding Updates and by the sending node to match a returned 313 Service Path Acknowledgement with this Service Path Update. 315 Acknowledge (A) 317 The Acknowledge (A) bit is set by the sending mobile node to 318 request a Service Path Acknowledgement be returned upon receipt of 319 the Service Path Update. 321 Reserved 323 This field is unused for now. The value MUST be initialized to 0 324 by the sender and MUST be ignored by the receiver. 326 Lifetime 328 16-bit unsigned integer. The number of time units remaining 329 before the service path MUST be considered expired. A value of 330 zero indicates that the Service Path MUST be deleted. A value of 331 0xFFFF indicates an infinite lifetime for the Service Path. One 332 time unit is 4 seconds. 334 Mobility Options 336 Variable-length field of such length that the complete Mobility 337 Header is an integer multiple of 8 octets long. This field 338 contains zero or more TLV-encoded mobility options. The receiver 339 MUST ignore and skip any options that it does not understand. 341 The following options are valid in a Service Path Update: 343 Network Service ID. 345 SFC node. 347 4.2. Service Path Acknowledgement 349 The Service Path Acknowledgement (SPA) message is used by a CTRL to 350 acknowledge a received SPU. 352 The Service Path Acknowledge uses the MH Type value TBD. When this 353 value is indicated in the MH Type field, the format of the Message 354 Data field in the Mobility Header is as follows: 356 0 1 2 3 357 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 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 | Sequence # | 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 | Reserved | Lifetime | 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 | | 364 . . 365 . Mobility Options . 366 . . 367 | | 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 Sequence # 372 A 16-bit unsigned integer used to match the returned Service Path 373 Acknowledgement with the Service Path Update. 375 Reserved 377 This field is unused for now. The value MUST be initialized to 0 378 by the sender and MUST be ignored by the receiver. 380 Lifetime 382 16-bit unsigned integer. The number of time units remaining 383 before the service path MUST be considered expired. A value of 384 zero indicates that the Service Path MUST be deleted. A value of 385 0xFFFF indicates an infinite lifetime for the Service Path. One 386 time unit is 4 seconds. 388 Mobility Options 389 Variable-length field of such length that the complete Mobility 390 Header is an integer multiple of 8 octets long. This field 391 contains zero or more TLV-encoded mobility options. The receiver 392 MUST ignore and skip any options that it does not understand. 394 The following options are valid in a Service Path Acknowledgement: 396 Network Service ID. 398 4.3. New Mobility options 400 4.3.1. Network Service ID 402 The Network Service ID option has the following format: 404 0 1 2 3 405 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 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 | Type = TBA | Option Length | 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 | Service Path Identifier (SPI) | Service Index | 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 | | 412 + + 413 | | 414 + Network Service ID + 415 | | 416 + + 417 | | 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 Option Type 422 TBA by IANA. 424 Option Length 426 8-bit unsigned integer. Length of the option, in octets, 427 excluding the Option Type and Option Length fields. 429 Service Path Identifier (SPI) 431 Uniquely identifies a Service Function Path (SFP). Participating 432 nodes MUST use this identifier for SFP selection. The initial 433 Classifier MUST set the appropriate SPI for a given classification 434 result. 436 Service Index (SI) 437 Provides location within the SFP. 439 Network Service ID 441 Variable length field that identifies the network service. 443 4.3.2. SFC node 445 The SFC node option has the following format: 447 0 1 2 3 448 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 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 | Type = TBA | Option Length | 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 | Function ID Length | Node ID Length | 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 | | 455 + + 456 | | 457 + Function ID + 458 | | 459 + + 460 | | 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 | | 463 + + 464 | | 465 + Node ID + 466 | | 467 + + 468 | | 469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 471 Option Type 473 TBA by IANA. 475 Option Length 477 8-bit unsigned integer. Length of the option, in octets, 478 excluding the Option Type and Option Length fields. 480 Function ID Length 482 8-bit unsigned integer. Length of the Function ID field, in 483 octets. 485 Node ID Length 487 8-bit unsigned integer. Length of the Node ID field, in octets. 489 Function ID 491 Variable length field that identifies the function. 493 Node ID 495 Variable length field that identifies the node. 497 There might be multiple SFC node options in a Service Function Update 498 message, following the options the same order of the SFC/NS. 500 5. IANA Considerations 502 TBD. 504 6. Security Considerations 506 TBD. 508 7. Acknowledgments 510 The work in this draft has been partially supported by the H2020 511 5Growth (Grant 856709) and 5G-DIVE projects (Grant 859881). 513 8. References 515 8.1. Normative References 517 [I-D.bernardos-sfc-distributed-control] 518 Bernardos, C. and A. Mourad, "Distributed SFC control for 519 fog environments", draft-bernardos-sfc-distributed- 520 control-01 (work in progress), January 2020. 522 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 523 Requirement Levels", BCP 14, RFC 2119, 524 DOI 10.17487/RFC2119, March 1997, 525 . 527 8.2. Informative References 529 [I-D.bernardos-sfc-fog-ran] 530 Bernardos, C., Rahman, A., and A. Mourad, "Service 531 Function Chaining Use Cases in Fog RAN", draft-bernardos- 532 sfc-fog-ran-06 (work in progress), September 2019. 534 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 535 Chaining (SFC) Architecture", RFC 7665, 536 DOI 10.17487/RFC7665, October 2015, 537 . 539 Authors' Addresses 541 Carlos J. Bernardos 542 Universidad Carlos III de Madrid 543 Av. Universidad, 30 544 Leganes, Madrid 28911 545 Spain 547 Phone: +34 91624 6236 548 Email: cjbc@it.uc3m.es 549 URI: http://www.it.uc3m.es/cjbc/ 551 Alain Mourad 552 InterDigital Europe 554 Email: Alain.Mourad@InterDigital.com 555 URI: http://www.InterDigital.com/