idnits 2.17.1 draft-lan-sfp-establishment-09.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 : ---------------------------------------------------------------------------- ** There are 5 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** There are 8 instances of lines with control characters in the document. 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 (March 20, 2020) is 1469 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'I-D.boucadair-sfc-framework' is mentioned on line 123, but not defined == Missing Reference: 'I-D.wu-pce-traffic-steering-sfc' is mentioned on line 321, but not defined == Unused Reference: 'RFC2753' is defined on line 523, but no explicit reference was found in the text == Unused Reference: 'I-D.rijsman-sfc-metadata-considerations' is defined on line 540, but no explicit reference was found in the text == Outdated reference: A later version (-03) exists of draft-zhang-sfc-sch-01 == Outdated reference: A later version (-07) exists of draft-quinn-sfc-nsh-02 Summary: 2 errors (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT J. Lan 2 Intended Status: Experimental Y. Hu 3 Expires: September 20, 2020 G. Cheng 4 P. Wang 5 T. Duan 6 NDSC P.R. China 7 March 20, 2020 9 Service Function Path Establishment 10 draft-lan-sfp-establishment-09 12 Abstract 14 Service Function Chain architecture leads to more adaptive network 15 nodes. It allows splitting the network function into fine-grained 16 build blocks --- service function, and combining the network 17 functions into service function chain to formulate complicated 18 services. Further, the service function chain should be instantiated 19 by selecting the optimal instance from the candidates for each 20 service function in it. This document discusses the required 21 components during the instantiation of service function chain in the 22 network. 24 Status of this Memo 26 This Internet-Draft is submitted to IETF in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that 31 other groups may also distribute working documents as 32 Internet-Drafts. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/1id-abstracts.html 42 The list of Internet-Draft Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html 45 Copyright and License Notice 47 Copyright (c) 2014 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Conventions used in this document . . . . . . . . . . . . . . 3 64 3. Terminology and Abbreviations . . . . . . . . . . . . . . . . 3 65 3.1. The Terminology . . . . . . . . . . . . . . . . . . . . . 3 66 3.2. Acronyms and Abbreviations . . . . . . . . . . . . . . . . 4 67 4. Core components for SFP . . . . . . . . . . . . . . . . . . . 5 68 4.1. Framework . . . . . . . . . . . . . . . . . . . . . . . . 5 69 4.2. SIB structure . . . . . . . . . . . . . . . . . . . . . . 6 70 4.3. TIB structure . . . . . . . . . . . . . . . . . . . . . . 7 71 5. SFP management . . . . . . . . . . . . . . . . . . . . . . . . 7 72 5.1. SFP establishment . . . . . . . . . . . . . . . . . . . . 9 73 5.2. SFP deletion . . . . . . . . . . . . . . . . . . . . . . . 11 74 5.3. SFP update . . . . . . . . . . . . . . . . . . . . . . . . 12 75 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 76 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 77 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 78 8.1. Normative References . . . . . . . . . . . . . . . . . . . 14 79 8.2. Informative References . . . . . . . . . . . . . . . . . . 14 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 82 1. Introduction 84 The end-to-end services delivery often present various demands for 85 different functions including the traditional functions and 86 diversified novel ones such as application-specific features. 87 However, the rigidly fixed model of service function in the legacy 88 network chain lacks in adaptability for that circumstance. It cannot 89 fulfill the current various requirements of end users or 90 applications, such as cross layer in the wireless network. 92 Accordingly, service function chain is provided to enhance the 93 network flexibility and adaptability. It consists of several service 94 functions in a special order that the corresponding packets or flows 95 should drill through them. The network administrative entity could 96 "insert" or "disable" a service function in the service function 97 chain based on the new dynamic demands. 99 Service function chain architecture splits the network functions into 100 finer-grained service functions. It then decouples the service 101 functions from the underlying physical topology, and enables the new 102 placement and combination of service functions viable. In the SFC- 103 enabled domain, many service function instances will co-exist 104 provided by different vendors. Before SFC deploys to delivery packets 105 or flows, it must be instantiated by selecting instances distributed 106 in the network for each service functions. 108 This document outlines the required components regarding to the 109 service function path including the establishment, deletion, 110 modification/update based on the policy. 112 2. Conventions used in this document 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 116 document are to be interpreted as described in RFC 2119 [RFC2119]. 118 3. Terminology and Abbreviations 120 3.1. The Terminology 121 This document uses the terminology defined in the SFC Problem 122 Statement [I-D.quinn-sfc-problem-statement] and the SFC Framework & 123 Architecture [I-D.boucadair-sfc-framework]. Additional terminology is 124 defined below: 126 Service Function Instance: A Service Function Instance locating in a 127 service node deals with the specific packets based on the function 128 logic declared. 130 Service Function Path: The Service Function Path is the instantiation 131 of a service function chain in the network. It consists of the 132 service function instances in the service function chain. 134 Service Information Base: A Service Information Base is a data 135 structure tracking the information about the service functions. It 136 must include the location of service functions, service type (e.g., 137 load balancer, firewall), and managed information such as the load, 138 capacity and current status of service function. SIBs may be 139 configured and managed by the administrative entity that operates the 140 SFC-enabled domain. SIBs also may be automatically updated by the 141 service function discover. In the distributed mode, SIB's replicas 142 could be distributed over the SFC-enabled domain. 144 Topology Information Base: A Topology Information Base stores the 145 Physical network infrastructure topology. Its replicas can be placed 146 in the same network node with SIB, or in a separate one. In the 147 distributed mode, TIB's replicas could be distributed over the SFC- 148 enabled domain. 150 SFP-enabled Management Entity: SFP-enabled Management Entity is 151 responsible for the establishment, deletion, modification/update of 152 SFPs for various SFC. 154 3.2. Acronyms and Abbreviations 156 SFI Service Function Instance 157 SFP Service Function Path 158 SIB Service Information Base 159 TIB Topology Information Base 160 SFP-ME SFP-enabled Management Entity 161 SFPS Service Function Pre-Selection 162 SFPC Service Function Path Calculation 163 SCPB Service Chain-Path Base 165 4. Core components for SFP 167 The establishment of a SFP which consists of multiple service 168 functions (SFs), needs to select one service function instance 169 (SFI) from multiple SFIs distributed in the network for each 170 service function. To make decision, service function (SF) node 171 information and underlying topology information need to be 172 collected automatically and periodily. The following sections 173 describe the framework and data structures to store SF information 174 and topology information for the establishment of SFP. 175 4.1. Framework 177 policy +----------------------------------------+ 178 | | +-------+ +-------+ +-------+ | 179 | | | | | | | | | 180 | |--->| SF1_1 |-->| SF1_2 | ... | SF1_n | | 181 | | | | | | | | | 182 V | +-------+ +-------+ +-------+ | 183 +-------+ | | 184 | | | | 185 +-->| PDP |--->| | 186 | | | | +-------+ +-------+ +-------+ | 187 | +-------+ | | | | | | | | 188 | |--->| SF2_1 |-->| SF2_2 | ... | SF2_m | | 189 +-------+ | | | | | | | | | 190 | | | | +-------+ +-------+ +-------+ | 191 | NIB |-->| +--------+-----------+-------------+-----+ 192 | | | | | | 193 +-------+ | | | | 194 | +-------+ +----------------------------------------+ 195 | | | | +-----------+ +-----+ | 196 |-->|SFP-ME |--->| +-------+ | SN2 | | SNi | | 197 | | | | | SN1 |-->+-----------+ +-----+ | 198 +-------+ | +-------+ | +-------+ |SF1_2 SF1_3| ... |SF1_n| | 199 | | | | | SF1_1 | +-----------+ +-----+ | 200 | TIB |---+ | | SF2_1 |-->+-----------+ +-----+ | 201 | | | +-------+ | SN2 | ... | SNk | | 202 +-------+ | +-----------+ +-----+ | 203 | | SF2_2 | |SF2_m| | 204 | +-----------+ +-----+ | 205 +----------------------------------------+ 206 physical infrastructure 208 Figure 1 Core components for SFP establishment 210 As shown in figure 1, the core components of SFP include PDP, SFP-ME, 211 SF information base (SIB), and topology information base (TIB). As 212 defined in [I.D- boucadair-sfc-framework], the PDP is the central 213 entity which is responsible for maintaining SFC policy Tables, and 214 enforcing appropriate policies in SF nodes and SFC Boundary Nodes. In 215 addition, the PDP in this document is also responsible for creating 216 SFCs according to the requirements of applications or profits of 217 vendors. The SIB stores the SF information which includes SF 218 identity, SF locator, SF type, SF capacity, SF load and SF status. SF 219 information can be collected from SFC-enabled domain by using IGP or 220 BGP-LS [I.D-draft-idr-ls-distribution]. The TIB is used to store 221 underlying physical network infrastructure topology information which 222 can be collected form network by using IGP or BGP-LS [I.D-draft-idr- 223 ls-distribution]. The SFP-ME is responsible for establishing, 224 deleting, and modified SFP according to SFC made by PDP, SF 225 information, and topology information. The SFP-ME is also responsible 226 for SFP management. 227 4.2. SIB structure 229 The SF information stored by SIB is used to establish or update SFP 230 by SFP-ME. The SIB structure is defined in Fig.2. The following 231 entries are defined in the SIB. 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 |Index|SF identity|SF locator|SF type|SF capacity|SF load|SF status| 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 Figure 2 SIB structure 239 Index: denotes the sequence that a SF entry locates in the SIB. The 240 index can be used to lookup the SF entry quickly. 242 SF identity: is used to identify the SF and is unique in SFP-ME 243 enabled domain. Each SF has an unique identity. The service function 244 server is responsible for the SF identity management and allocation. 246 SF locator: represents the SF node where the SF locates. The SF 247 locator is non-exclusive. Multiple SFs could locate in one SF node or 248 multiple different SF nodes. 250 SF type: denotes the type of a SF. SFs can be classified into 251 different classes which include firewall, DPI (Deep Packet 252 Inspection), load balancer, etc. The definition of SF can refer to 253 [I.D- boucadair-sfc-framework]. In this document, the SFs may be 254 service functions in layer 3 or service functions in layer 4-7. 256 SF capacity: represents the capacity to process the traffic. The same 257 service function may have multiple service functions in different 258 capacities. 260 SF load: denotes the current traffic load steering a SF. The SFP-ME 261 can establish or update SFP according to SF load. 263 SF status: denotes the current status of a SF. The SF status includes 264 available, congestion, unavailable, etc. The exact definition of SF 265 status is application-specific. 267 4.3. TIB structure 269 The underlying physical network topology information is used to 270 deploy SFs for establishing or updating SFP according some optimal 271 criterions or the profit of vendors. The TIB is used to store network 272 topology information. The structure of TIB can be defined in 273 different formats, e.g. routing information table etc. Fig. 3 shows a 274 definition of the TIB structure. The following entries are defined in 275 the TIB. 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+--+ +-+-+-+-+-+--+ 278 | SF node | number | Neighbor 1 | Neighbor 1 |...| Neighbor N | 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+--+ +-+-+-+-+-+--+ 281 Figure 3 TIB structure 283 SF node: denotes the SF node which reports the information. The 284 identifier of SF node can be flat identifier or hierarchical 285 identifier, e.g. IP address. 287 Number: denotes the number of neighbor nodes. 289 Neighbor: denotes the neighbor node of the current SF node. A SF node 290 may have multiple neighbor nodes. 292 5. SFP management 294 SFP aims to provide SFC an optimal/near-optimal path on underlying 295 physical network, ensuring network function represented by the 296 specific SFC can be implemented with required or even higher 297 performance. Operations of SPF refer to establishment, deletion and 298 update and are conducted by SFP-ME. 300 The SFP-ME in this document includes a service function pre-selection 301 (SFPS), classifier, service function path calculation (SFPC) and 302 service chain-path base (SCPB), as shown in Figure 4. The SFPS is 303 used to select candidate nodes for SFP establishment. The classifier 304 is used to determine which cost function is taken for SFP 305 establishment and transfer SFP deletion and update information to 306 SFPC. The SFPC is used to fulfill SFP establishment, deletion and 307 update. The SCPB stores service function chain-path mapping 308 information and is used for SFP deletion. 310 A service function path header should be added to encapsulated 311 packets or frames to represent service function paths. The service 312 function path header should be independent of the underlying 313 transport and can be encapsulated inside any transport mechanism. 314 There are several approaches to encapsulate service function path 315 header as described in Metadata Considerations [I-D.rijsman-sfc- 316 metadata-considerations], Service Chain Header [I-D.zhang-sfc-sch], 317 Network Service Header[I-D.quinn-sfc-nsh] and so on. 319 To implement SPF establishment, deletion and update, SFP-ME need to 320 interact with NIB, TIB, PDP by using a variety of protocols, such as 321 NETCONF [RFC6241],PCEP[I-D.wu-pce-traffic-steering-sfc], etc. 323 +------------+ 324 | | 325 | PDP | 326 | | 327 +-----+------+ 328 | 329 +-----------+ +---------------|------------------------+ 330 | | | | | 331 | NIB <----+ | +------+--------+ | 332 | | | | | | | 333 +-----------| | | +---v---+ +-----v------+ | 334 | | | | | | | 335 +---+-+--> SNPS | | CLASSIFIER | | 336 | | | | | | | | 337 +-----------+ | | | +---v---+ +-----v------+ | 338 | | | | | | | | 339 | TIB <----+ | | | | | 340 | | | | +------+--------+ | 341 +---------- + | | | | 342 | | | | 343 | | +---V---+ +------+ | 344 | | | | | | | 345 | +----- -->| SFPC <-------- > SCPB | | 346 | | | | | | 347 | +---+---+ +------+ | 348 | | | 349 +---------------+------------------------+ 350 | 351 V 353 Figure 4 Framework of SFP-ME 355 5.1. SFP establishment 357 SFP establishment refers to determining the optimal/near-optimal 358 service node for each service function on SFC and finding the 359 optimal/near-optimal path for the instantiated service nodes of a 360 given SFC such that the required service functions are executed in 361 sequence required by SFC with minimal costs. 363 The term of cost is user-defined and can be end-to-end delay, 364 resource consumption and so on. There may exist only one cost 365 definition which can be applied to all SFC in the same domain, or may 366 co-exist several different cost definitions with each one targeting 367 at different types of SFC. Cost must be expressed as a function, i.e. 368 cost function. Trying to minimize the cost, several algorithms can be 369 applied based on different cases. 371 When SFC is generated based on policy in PDP, SFP-ME receives SFC 372 information and start to execute SFP establishment. The SFP 373 establishment processes in three steps, as shown in Figure 5. 375 Firstly, SNPS selects several service nodes as candidates, these 376 service nodes must include one or more service function Instance of 377 the given SFC and are currently available. Concurrently, classifier 378 selects the appropriate cost function according to the type of the 379 given SFC, this step can be omitted if there is only one cost 380 function applied to all SFC in the same domain. 382 Secondly, with the aim to minimize cost, SFPC applies algorithms to 383 selects one service node for each service function of the given SFC 384 from the candidates and builds a path making the service functions 385 strictly executed with the ordered sequence. Thus an optimal/near- 386 optimal SFP for SFC is established. 388 Lastly, Information of the established SFP is send to SFC entrance, 389 meanwhile SCPB is updated. 391 +------------+ 392 | | 393 | PDP | 394 | | 395 +------------+ 396 | 397 +---------------|------------------------+ 398 | | | 399 | +------+--------+ | 400 | | 1 | 1 | 401 | +---v---+ +-----v------+ | 402 | | | | | | 403 | | SNPS | | CLASSIFIER | | 404 | | | | | | 405 | +-------+ +------------+ | 406 | | | | 407 | | | | 408 | +------+---------+ | 409 | | 2 | 410 | | | 411 | +---V---+ +------+ | 412 | | | 3 | | | 413 | | SFPC |-------- > SCPB | | 414 | | | | | | 415 | +---+---+ +------+ | 416 | | | 417 +--------------+-------------------------+ 418 | 3 419 V 421 Figure 5 SFP Establishment Process 423 5.2. SFP deletion 425 SFP deletion refers to releasing the overall service function 426 Instantiations of the established SFP, thus the released service 427 function Instantiations can be used for other SFP's establishment. 429 SFP-ME starts to execute SFP deletion once PDP notifies that SFC has 430 been deleted. Information of the to be deleted SFC is send to SFPC 431 through classifier and match against the restored SFC in SCPB to find 432 SFP for the given SFC, then SFPC notify SFC entrance that this 433 specific SFP is invalid, meanwhile update SCPB. The SFP deletion 434 process is shown in Figure 6. 436 +------------+ 437 | | 438 | PDP | 439 | | 440 +------------+ 441 | 442 +----------+---------------------+ 443 | | 1 | 444 | +-----v------+ | 445 | | | | 446 | | CLASSIFIER | | 447 | | | | 448 | +------------+ | 449 | | 2 | 450 | | | 451 | +---V---+ +------+ | 452 | | | 3 | | | 453 | | SFPC <------ > SCPB | | 454 | | | | | | 455 | +---+---+ +------+ | 456 | | | 457 +----------+---------------------+ 458 | 4 459 V 461 Figure 6 SFP deletion process 463 5.3. SFP update 465 SFP update refers to changing partial service function Instantiations 466 or path of the established SFP, due to breakdown of partial service 467 function nodes or physical links. 469 Breakdown of service function nodes or physical links can lead the 470 established SFP to work improperly, re-establishment of SFP can be 471 executed to guarantee function of the corresponding SFC is still 472 implemented with optimal/near-optimal performance. SFP update is an 473 alternative way. The updated SFP may perform worse than the re- 474 establishment one, however, the update process takes up less time 475 which can be very attractive to time-sensitive function. 477 SFP-ME starts to execute SFP update once PDP notifies that SFP need 478 to be updated. Information of the to be updated SFC is send to SFPC 479 through classifier, SFPC selects adjacent service nodes or path to 480 replace the ones which has been breakdown. Thus the given SFP is 481 undated, Information of the undated SFP is send to SFC entrance. The 482 SFP update process is shown in Figure 7. 484 +------------+ 485 | | 486 | PDP | 487 | | 488 +------------+ 489 | 490 +----------+-----------+ 491 | | 1 | 492 | +-----v------+ | 493 | | | | 494 | | CLASSIFIER | | 495 | | | | 496 | +------------+ | 497 | | 2 | 498 | | | 499 | +---V---+ | 500 | | | | 501 | | SFPC | | 502 | | | | 503 | +---+---+ | 504 | | | 505 +----------+-----------+ 506 | 3 507 V 509 Figure 7 SFP update process 511 6. Security Considerations 513 It will be considered in a future revision. 515 7. IANA Considerations 517 No IANA action is needed for this document. 519 8. References 521 8.1. Normative References 523 [RFC2753] Yavatkar, R., Pendarakis, D., and R. Guerin, "A Framework 524 for Policy-based Admission Control", RFC 2753, January 525 2000. 527 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 528 Requirement Levels", BCP 14, RFC 2119, March 1997. 530 8.2. Informative References 532 [I-D.quinn-sfc-problem-statement] Quinn, P., "Service Function 533 Chaining Problem Statement", draft-quinn-sfc-problem- 534 statement-02 (work in progress), December 2013. 536 [I-D. boucadair-sfc-framework] M. Boucadair, "Service Function 537 Chaining: Framework & Architecture",draft-boucadair-sfc- 538 framework-02 (work in progress),February 2014. 540 [I-D.rijsman-sfc-metadata-considerations] B. Rijsman, J. Moisand, 541 "Metadata Considerations", draft-rijsman-sfc-metadata- 542 considerations-00 (work in progress),February 2014. 544 [I-D.zhang-sfc-sch] H. Zhang, L. Fourie, R. Parker, M. Zarny, 545 "Service Chain Header", draft-zhang-sfc-sch-01 (work in 546 progress), May 2014. 548 [I-D.quinn-sfc-nsh] P. Quinn, J. Guichard, R. Fernando, S. Kumar, et 549 al. "Network Service Header",draft-quinn-sfc-nsh-02 (work 550 in progress), February 2014. 552 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A.Bierman, 553 "Network Configuration Protocol (NETCONF)", RFC 6241, June 554 2011. 556 Authors' Addresses 558 Julong Lan 559 National Digital Switching System Engineering and Technological 560 Research Center 561 NDSC 562 Jianxue Ave. No. 7 563 Zhengzhou 450002 564 China 566 EMail: ndscljl@163.com 568 Yuxiang Hu 569 National Digital Switching System Engineering and Technological 570 Research Center 571 NDSC 572 Jianxue Ave. No. 7 573 Zhengzhou 450002 574 China 576 EMail: chxachxa@126.com 578 Guozhen Cheng 579 National Digital Switching System Engineering and Technological 580 Research Center 581 NDSC 582 Jianxue Ave. No. 7 583 Zhengzhou 450002 584 China 586 EMail: chengguozhen1986@163.com 588 Peng Wang 589 National Digital Switching System Engineering and Technological 590 Research Center 591 NDSC 592 Jianxue Ave. No. 7 593 Zhengzhou 450002 594 China 596 EMail: wangpeng.ndsc@gmail.com 597 Tong Duan 598 NDSC 599 Jianxue Ave. No. 7 600 Zhengzhou 450002 601 China 603 EMail: duantong21@126.com