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