idnits 2.17.1 draft-ww-sfc-control-plane-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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) 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 8, 2015) is 3336 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'I-D.ietf-sfc-architecture' is mentioned on line 154, but not defined == Missing Reference: 'RFC7297' is mentioned on line 177, but not defined == Outdated reference: A later version (-01) exists of draft-lee-nfvrg-resource-management-service-chain-00 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group H. Li 3 Internet-Draft Q. Wu 4 Intended status: Standards Track O. Huang 5 Expires: September 9, 2015 Huawei 6 M. Boucadair 7 C. Jacquenet 8 France Telecom 9 W. Haeffner 10 Vodafone 11 S. Lee 12 ETRI 13 R. Parker 14 Affirmed Networks 15 March 8, 2015 17 Service Function Chaining (SFC) Control Plane Achitecture 18 draft-ww-sfc-control-plane-04 20 Abstract 22 This document defines the control plane architecture which include 23 control plane components and interface between control plane 24 component and data plane component. This document further describes 25 how Service Functions Chains are structured and how Service Function 26 Chaining path is provisioned and setup. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on September 9, 2015. 45 Copyright Notice 47 Copyright (c) 2015 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. Data plane basic assumption . . . . . . . . . . . . . . . . . 3 65 4. SFC Control Plane: An Overview . . . . . . . . . . . . . . . 4 66 4.1. SFC Control plane . . . . . . . . . . . . . . . . . . . . 7 67 4.2. F interface . . . . . . . . . . . . . . . . . . . . . . . 7 68 4.3. C1 interface . . . . . . . . . . . . . . . . . . . . . . 7 69 4.4. C2 interface . . . . . . . . . . . . . . . . . . . . . . 8 70 5. Signaling procedure . . . . . . . . . . . . . . . . . . . . . 8 71 5.1. Service Topology Building . . . . . . . . . . . . . . . . 8 72 5.2. Service Function Chain Structuring . . . . . . . . . . . 9 73 5.3. Service Function Path Determining . . . . . . . . . . . . 10 74 5.4. Service Function Path Adjustment . . . . . . . . . . . . 10 75 5.5. Service Function Chaining Path Setup and Policy Table 76 configuration . . . . . . . . . . . . . . . . . . . . . . 11 77 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 78 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 79 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 80 8.1. Normative References . . . . . . . . . . . . . . . . . . 12 81 8.2. Informative References . . . . . . . . . . . . . . . . . 12 82 Appendix A. SFC Control Plane Components Deployment 83 Consideration in Mobile Backbone (MBB) Environment . 13 84 Appendix B. SFC Control Plane Components Deployment 85 Consideration in Fixed Backbone (FBB) Environment . 15 86 Appendix C. SFC Control Plane Components Deployment 87 Consideration in Data Center(DC) Environment . . . . 16 88 Appendix D. SFC Control Plane Components Deployment 89 Consideration in Data Center (DC) Environment . . . 18 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 92 1. Introduction 94 The dynamic enforcement of a service-derived, adequate forwarding 95 policy for packets entering a network that supports advanced Service 96 Functions (SFs) has become a key challenge for operators and service 97 providers. 99 Service Function Chaining (SFC) typically observe, alter or even 100 terminate and re-establish session flows between user equipment and 101 application platforms (Web, Video, VoIP etc.) by invoking, in a given 102 order, a set of Service Functions [I.D-ietf-sfc-problem-statement]. 103 Service functions involved in a given SFC may include load-balancing, 104 firewalling, intrusion prevention, etc. 106 A given SFC-enabled domain may involve several instances of the same 107 Service Function. Service function instances can be automatically 108 added to or removed from a given SFC. SFs can be co-located or 109 embedded in distinct physical nodes, or virtualized. 111 This document describes SFC control plane architecture and discusses 112 how the Service Function Chains are structured and how Service 113 Function Chaining path is provisioned and setup. 115 2. Conventions used in this document 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 119 document are to be interpreted as described in RFC2119 [RFC2119]. 121 3. Data plane basic assumption 123 This document defines the control plane architecture while the data 124 plane architecture is defined in [I.D-ietf-sfc-architecture]. 126 The SFC data plane characteristics considered as basic assumptions by 127 the SFC control architecture are summarized below: 129 o Traffic that enters a SFC-enabled domain is classified according 130 to the rules the SFC Control Plane provides to the Classifier. 131 After classification, the traffic is forwarded into the SFC- 132 enabled domain passing a set of Service Functions as defined in 133 the corresponding SFC instructions. SFC-specific forwarding 134 information is used by Service Forwarder Entity (i.e., a node 135 which include service forwarder function (SFF)) to make traffic 136 forwarding decisions and pass the traffic to the next Service 137 Function instance within the chain, through the Service Function 138 Path derived from Control Plane Information and instantiated from 139 the Classifier. 141 o The Service Forwarder Entity forwards packets according to the 142 entries maintained in the SFC Policy rule base. A Service 143 Forwarder Entity can be a virtualized or physical L2/L3 network 144 device that serves Service Functions within a given chain. A 145 Service Forwarder Entity may serve one or more Service Functions 146 (Fig. 1). 148 o When a Service Forwarder Entity needs to forward a packet to an 149 SFC-unware legacy node, the packet is likely to be forwarded by a 150 SFC proxy to SFC-unaware legacy node. 152 4. SFC Control Plane: An Overview 154 As described in [I-D.ietf-sfc-architecture],SFC Control plane is 155 responsible for constructing SFC, translating SFCs to forwarding 156 paths and propagating path information to participating nodes to 157 achieve requisite forwarding behavior and construct the service 158 overlay. For the purpose of defining the SFC control plane 159 architecture, the SFC control plane is broken up into five distinct 160 components: 162 Chain Selection Policy Control 164 Chain Selection Policy Control component maintains SFC-related 165 information models (chain structures, classification rules) 166 derived from business or operational models. These information 167 model can be used to construct service function chain. 169 Chain Management Policy Control 171 This component is responsible for: 173 * Structuring a SFC chain, based upon various inputs that include 174 Service Function information as collected through the 175 management interface (e.g., the outcomes of a negotiation 176 between a customer and a service provider, as documented in 177 [RFC7297], business guidelines, etc.). 179 * Adjusting a chain based on the external policy context or any 180 path change computed by Service Overlay Topology management 181 component. 183 Service Overlay Topology management 184 This is an optional component that is not needed particularly when 185 SFC forwarding is fully distributed. This component is 186 responsible for: 188 * Creating the service topology which consist of Service 189 Function-related information and network topology information. 191 * Helping Chain Mapping and forwarding Control Component 192 determine forwarding path in case the said forwarding path is 193 traffic engineered. 195 Service Function (SF) Management 197 This component allows for the dynamic discovery of locations of 198 Service Functions and is used to help the SFC control plane to 199 gather Service Function-related information from various Service 200 Functions available within a SFC-enabled domain. 202 SFC Mapping and Forwarding Control 204 This is a component that helps the SFC Control plane to 205 dynamically: 207 * Map SFCs to the specific Service Function path. 209 * Populate forwarding rules on the data plane. 211 * Adjusting Service Function paths based on the states or 212 attributes of Service Function instances and overlay links. 214 +-------------------------------------------------+ 215 | SFC Control Plane | 216 | +---------------+ +---------------+ | 217 +-------| |Chain Management |Service Overlay| | 218 | | |Policy Control | |Topo Management| | 219 | | +---------------+ +---------------+ | 220 | | +---------------+ +---------------+ | 221 +---------|Chain Selection| | Chain Mapping | +----------+| 222 | | | Policy Control| | and Forwarding| |External SF| 223 | +---------------+ | Control | |Management|| 224 | | +---------------+ +----------+| 225 C1 +------^-----------^-------------^----------------+ 226 +---------------------|F----------|-------------|-------------+ 227 | | +----+ | | | 228 | | | SF | |C2 |C2 | 229 | +----+ | | | 230 | +----V--- --+ | | | | 231 | | SFC | +----+ +-|--+ +----+ | 232 | |Classifier |---->|SFF |----->|SFF |------->|SFF | | 233 | | Node |<----| |<-----| |<-------| | | 234 | +-----------+ +----+ +----+ +----+ | 235 | | | | | 236 | |C2 ------- | | 237 | | | | +-----------+ F | 238 | V +----+ +----+ | SFC Proxy |--> | 239 | | SF | |SF | +-----------+ | 240 | +----+ +----+ | 241 | |F |F | 242 | SFC Data Plane Components V V | 243 | | 244 +-------------------------------------------------------------+ 246 Figure 1: SFC Control Plane Overview 248 There are three interfaces connected to the SFC control plane. 250 C1 Interface: the interface between the SFC control plane and the 251 SFC Classifiers. Classification rules are installed on the SFC 252 Classifier Node(s) via this interface.In addition, this Interface 253 may be used by the control plane to instantiate of traffic- 254 engineered paths that will be used to forward traffic according to 255 SFC information. 257 C2 Interface: the interface between the SFC control plane and the 258 Service Forwarder Function. SFC-based forwarding entries on 259 Service Function nodes are provided by the SFC Control plane via 260 this interface. 262 F Interface: This interface is used by Service Function to 263 feedback service or application level information of a data flow 264 to the SFC control plane. 266 4.1. SFC Control plane 268 The SFC control plane is in charge of Service Function chain creation 269 and maintenance, service chain path instantiation (in case of the 270 traffic-engineered SFCs), mapping between SFC and Service Function 271 path, SFC Policy Table creation and configuration, including the 272 sequence of Service Functions in a Service Function chain, Service 273 Function information, SFC paths information. 275 The SFC control plane may be fed with Service Function chain 276 information from the Management application. A SFC service template 277 information may look like: 279 {{MBR>1Mbps, RAT='UMTS', protocol='HTTP', QOS='Gold'},goto'sfc1'} 281 The SFC Control plane also creates classification rules and installs 282 them on the classifier nodes. The SFC control plane also assigns SFC 283 identification and installs SFC Policy Tables in the Service 284 forwarder function. 286 4.2. F interface 288 Service Functions, e.g., deep packet inspection (DPI) or firewall may 289 need to output some processing results of packets to the control 290 system. This information can be used by the SFC control plane to 291 update the SFC classification and SFC forwarding entries. 293 The F Interface is used to collect such kind of feedback information 294 from the Service Functions or the SF nodes. 296 The F interface is also used for collecting states of attributes 297 (e.g., availability, workload) of Service Functins to dynamically 298 adjust Service Function paths. 300 4.3. C1 interface 302 This interface is used to install SFC classification rules in Service 303 Classifier nodes. These rules are created by the SFC control Plane. 304 They may be updated by information provided by the Service Function 305 nodes (in case a change of the network topology has occurred, for 306 example). 308 SFC Classifier Node binds incoming traffic to SFCs according to these 309 classification rules. 311 4.4. C2 interface 313 Service forwarder entity make traffic forwarding decisions according 314 to the entries maintained in their SFC Policy Table. Such Table is 315 populated by the SFC control plane through the C2 interface. 317 Each Service Function has a unique Service Function identifier to 318 identify itself in the SFC forwarding plane. The Service Function 319 locator is typically referred to as a network address. In case the 320 Service Function instance is directly connected to a Service 321 forwarder entity, the forwarding entry may also include the port 322 through which the Service Function instance can be reached. 324 Some proxy function may also use the C2 interface to retrieve the 325 mapping between a Service Function Identifier and a Service Function 326 locator from the SFC control plane. 328 The C2 interface is also used for collecting states of attributes 329 (e.g., availability, workload, latency) of Service Functins or 330 overlay links to dynamically adjust Service Function paths. 332 5. Signaling procedure 334 5.1. Service Topology Building 336 When a Service Function is instantiated into the network it is 337 necessary to select the locator of the specific instances of Service 338 Functions that will be used, and to construct the service overlay 339 using Service Function's network locator. The service overlay is 340 built on top of the underlying network. The resulting service 341 overlay is meant to facilitate SFC-enabled domain operation, as it 342 may provide a better, up-to-date, network-wise overview of the 343 Service Functions status and usage. 345 A service specific overlay utilized by SFC then results in the 346 creation of the service topology. Service topology information 347 consists of network topology information collected from the 348 underlying network and Service Function-related information (such as 349 Service Function administration information and Service Function 350 capability information) that may be collected from the management 351 interface. For example, Network topology information can be 352 collected from the network using an IGP or BGP-LS [I.D-draft-idr-ls- 353 distribution]. 355 Service Function-related information includes Service Function 356 Identifier, Service Function Locator, Service Function administration 357 information (e.g., available memory, CPU utilization, available 358 storage capacity, etc.) or Service Function capability information 359 (e.g., supported ACL numbers, virtual context number). This 360 information can be retrieved by various means (e.g., registration 361 mechanism that provides binding between Service Function Identifier 362 and Service Function Locator(s) and allows for the dynamic discovery 363 of locations of Service Functions). 365 Network topology is not required for dynamically structuring service 366 chains, but it may be helpful during service troubleshooting and 367 diagnostics. 369 The creation of the service topology is not conditioned by the 370 creation of the network topology: what is required is the mapping 371 between Service Function-related information and existing network 372 topology information. Additional Service Functions or Service 373 Function instances, for redundancy or load distribution purposes, can 374 be added to or removed from the service topology as required. Means 375 to dynamically discover the location of available Service Function 376 instances may be supported. 378 5.2. Service Function Chain Structuring 380 The chain management component of the SFC control plane is 381 responsible for the dynamic structuring of Service Function chains 382 (i.e., define an ordered list of Service Function identifiers) that 383 can be supported, as a function of the services that can be 384 delivered, among other information that may include subscriber- 385 specific information. For example, a Service Function chain can be 386 structured as follows: 388 service-chain 100 { 389 10 url-filter 390 20 web-cache 391 30 web-optimizer 392 40 firewall 393 } 395 In this Service Function chain, each Service Function needs to be 396 assigned with a unique Service Function identifier and can be located 397 using Service Function locators. A Service Function chain should be 398 assigned an SFC Index. A Service Function identifier does not 399 necessarily hint the service offered by that Service Function; its 400 purpose is to uniquely identify a Service Function among those 401 present in a SFC-enabled domain. 403 5.3. Service Function Path Determining 405 The Chain Mapping and forwarding Control Component of the SFC control 406 plane is a component that is responsible for Service Function path 407 determination based on Service Overlay Topology information 408 maintained in the Service Overlay Topology management component. 409 However, not all SFC deployments may require Service Function path 410 determination (e.g., SFC forwarding is fully distributed ). Service 411 Function path determination is referred to determine an ordered list 412 of locators of each Service Function that belongs to a Service 413 Function chain. 415 The Service Function path determining may be static or pre-determined 416 using specific Service Function instances, or dynamic - choosing 417 explicit Service Function instances at the time of delivering traffic 418 to the Service Function. 420 When there are multiple instances of a given Service Function that 421 belongs to a given SFC, each of these instances is assigned a unique 422 locator. These multiple instances may actually be invoked within the 423 context of a single chain, or within the context of multiple chains 424 depending on how the said chains are structured. The latter case may 425 lead to multiple SFPs. In some other cases, a Service Function path 426 can pre-determined by SFC mapping and forwarding component for 427 traffic engineering purposes by interacting with Service Overlay 428 Topology management component. However Service Function path doesn't 429 need to be pre- determined. The chain management component 430 responsible for structuring the service chains cannot decide in 431 advance the actual path that will be followed by packets. 433 In addition, the SFC mapping and forwarding component also maintains 434 the mapping between Service Function chains and Service Function 435 paths. When Service Function chain structuring is complete, the SFC 436 control plane will use the SFC forwarding and mapping component to 437 determine the locator of each specific Service Function instance in 438 the chain and return a set of Service Function locators associated 439 with a Service Function chain. 441 5.4. Service Function Path Adjustment 443 A Service Function Path (SFP) is determined by composing instances of 444 Service Functions (SFIs) and overlay links among SFFs. Thus the 445 status of a SFP depends on the states or attributes (e.g., 446 availability, topological location, latency, workload, etc.) of its 447 components, i.e., SFIs and overlay links. For example, failure of a 448 single SFI results in failure of the whole SFP which the SFI 449 constitutes. Since these states or attributes of SFP components may 450 vary in time, their changes are monitored and SFPs are dynamically 451 adjusted. 453 Examples of use cases for SFP adjustment are as follows: 455 o SFP fail-over: re-construct a SFP with replacing the failed SFI 456 with new SFI selected 458 o SFP with a low latency: re-construct a SFP with a low stretch 459 considering the changes in topological locations of SFI and 460 latency of overlay links among SFFs 462 o Traffic engineering: re-construct SFPs to localize the traffic in 463 the network considering workload and administrative domains of 464 SFIs and overlay links. 466 o Load balancing: re-construct SFPs to distribute the workload of 467 shared SFIs and overlay links. 469 For more details about the use cases, refer to 470 [I-D.lee-nfvrg-resource-management-service-chain]. 472 The procedures for SFP adjustment are handled by Chain Mapping and 473 Forwarding Control Component as follows: 475 o Collect and monitor states and attributes of SFIs and overlay 476 links via the F interface and the C2 interface 478 o Evaluate SFIs and overlay links based on the monitoring results 480 o Select SFIs to re-determine a SFP according to the evaluation 481 results 483 o Replace target SFIs (e.g., in a failure or overladed) with newly 484 selected ones 486 o Enforce the updated SFP for upcoming SFC traversal to SFFs via the 487 C2 interface; or to the SFC Classifer Node via the C1 interface 489 5.5. Service Function Chaining Path Setup and Policy 490 Table configuration 492 Once a SFC is structured, traffic classification rules are derived 493 and provided to the classifier nodes, along with other information 494 maintained in Policy Tables. The policy table is built based on SFC 495 policy and service information(e.g.,subscriber being mapped into a 496 service class related to a SFC) captured by using policy related 497 components, when a Service Function path is determined. The policy 498 table will be populated at each participating node involved in the 499 application of a Service Function chain and used by them to make 500 their forwarding decisions on a typical hop-by-hop basis. 502 6. Security Considerations 504 The SFC Control and the participating SFC functional elements must be 505 mutually authenticated. Means to protect against an attacker who 506 would install/remove/modify classification rules must be supported. 507 When means to dynamically discover the location of SF instances are 508 in use, they should be designed to avoid illegitimate SFs to belong 509 to the SFC-enabled domain. 511 7. Acknowledgements 513 This documen is the result of merging with draft-lee-sfc-dynamic- 514 instantiation. 516 The author would like to thank Shibi Huang for providing input and 517 LAC Chidung for his review and comments that helped improve this 518 document. 520 8. References 522 8.1. Normative References 524 [I.D-ietf-sfc-architecture] 525 Halpern, J. and C. Pignataro, "Service Function Chaining 526 (SFC) Architecture", ID draft-ietf-sfc-architecture-01, 527 September 2014. 529 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 530 Requirement Levels", March 1997. 532 8.2. Informative References 534 [I-D.lee-nfvrg-resource-management-service-chain] 535 Lee, S., Pack, S., Shin, M., and E. Paik, "Resource 536 Management for Dynamic Service Chain Adaptation", draft- 537 lee-nfvrg-resource-management-service-chain-00 (work in 538 progress), October 2014. 540 [I.D-ietf-sfc-problem-statement] 541 Quinn, P., "Network Service Chaining Problem Statement", 542 ID draft-ietf-sfc-problem-statement-10, August 2014. 544 [I.D-wu-pce-traffic-steering-sfc] 545 Wu, Q., Dhody, D., Boucadair, M., Boucadair, C., and J. 546 Tantsura, "PCEP Extensions for traffic steering support in 547 Service Function Chaining", ID draft-wu-pce-traffic- 548 steering-sfc-05, September 2014. 550 Appendix A. SFC Control Plane Components Deployment Consideration in 551 Mobile Backbone (MBB) Environment 553 +---------------------------------------------------------------+ 554 | SFC Control Plane +----------------------+ | 555 | | +------------+ | | 556 | | | SFC | | | 557 | +----------------|Orchestrator-----------+ | 558 | | | +------------+ | | | 559 | | | SFC Management System| | | 560 | | +----------------------+ | | 561 | | | | 562 | | | | 563 |+------|-------------+ +--------|------------+ | 564 ||+-----|----+ | | +------|---------+ | | 565 |||SFC Policy| | | | SFC Forwarding | | | 566 ||| Control | | |-------| Control -----|----+ 567 ||+-----|----+ | | | +----------------+ | | | 568 || Enhancement in PCRF| | | SFC Controller | | | 569 |+------|-------------+ | | | | | 570 | | | +---------------------+ | | 571 +-------|-------------------------|-----------------------------+ | 572 +-------|-------------------------|------------------------------------+ 573 |+--------------------+ +---------------+ +---------------+ | | 574 ||Enhancement in PCEF | | Enhancement in| | Enhancement in| | | 575 || or TDF | | ToR switch or | | ToR Switch or | | | 576 ||+-----|-------+ | | Router | | Router | | | 577 ||| SFC | | |+----|--+ | |+-------+ | | | 578 ||| Classifier |-----------|| |------------- | | | | | 579 ||| Function | | || SFF1 | | || SFF2 ---------+ | 580 ||+-------------+ | || | | || | | | 581 |+--------------------+ |+---|---+ | |+---|---+ | | 582 | +----|----------+ +----|----------+ | 583 | ------------ -----|------ | 584 | | | | | | 585 | +----+ +---+ +----+ +---+ | 586 | | SF1| |SF2| | SF3| |SF4| | 587 | +----+ +---+ +----+ +---+ | 588 |SFC Data Plane | 589 -----------------------------------------------------------------------+ 591 SFC in MBB 593 In MBB environment, Policy Control component and Chain Management 594 Policy Control component defined in section 4 can be supported using 595 Enhanced PCRF. Service Overlay Topology management defined in 596 section 4 can be supported using SFC Orchestrator. SFC Mapping and 597 Forwarding Control component defined in section 4 can be supported 598 using SFC Controller. Note that 3GPP is considering integrating 599 Chain Selection Policy Control component and Chain Management Policy 600 Control component using PCRF. 602 Appendix B. SFC Control Plane Components Deployment Consideration in 603 Fixed Backbone (FBB) Environment 605 +---------------------------------------------------------------+ 606 | SFC Control Plane +----------------------+ | 607 | | +------------+ | | 608 | | | SFC | | | 609 | +----------------|Orchestrator-----------+ | 610 | | | +------------+ | | | 611 | | | SFC Management System| | | 612 | | +----------------------+ | | 613 | | | | 614 | | | | 615 |+------|-------------+ +--------|------------+ | 616 ||+-----|----+ | | +------|---------+ | | 617 |||SFC Policy| | | | SFC Forwarding | | | 618 ||| Control | | -|-------| Control -----|----+ 619 ||+-----|----+ | | | +----------------+ | | | 620 || Enhancement in RADIUS | | SFC Controller | | | 621 |+------|-------------+ | | | | | 622 | | | +---------------------+ | | 623 +---------------------------------------------------------------+ | 624 +----------------------------------------------------------------------+ 625 |+--------------------+ +---------------+ +---------------+ | | 626 ||Enhancement in BRAS | | Enhancement in| | Enhancement in| | | 627 || or BNG | | ToR switch or | | ToR Switch or | | | 628 ||+-----|-------+ | | Router | | Router | | | 629 ||| SFC | | |+----|--+ | |+-------+ | | | 630 ||| Classifier |-----------|| |------------- | | | | | 631 ||| Function | | || SFF1 | | || SFF2 ---------+ | 632 ||+-------------+ | || | | || | | | 633 |+--------------------+ |+---|---+ | |+---|---+ | | 634 | +----|----------+ +----|----------+ | 635 | ------------ -----|------ | 636 | | | | | | 637 | +----+ +---+ +----+ +---+ | 638 | | SF1| |SF2| | SF3| |SF4| | 639 | +----+ +---+ +----+ +---+ | 640 |SFC Data Plane | 641 -----------------------------------------------------------------------+ 643 SFC in FBB 645 In FBB environment, Policy Control component and Chain Management 646 Policy Control component defined in section 4 can be supported using 647 Enhanced RADIUS. Service Overlay Topology management defined in 648 section 4 can be supported using SFC Orchestrator. SFC Mapping and 649 Forwarding Control component defined in section 4 can be supported 650 using SFC Controller. Note that BBF is considering integrating Chain 651 Selection Policy Control component and Chain Management Policy 652 Control component using RADIUS. 654 Appendix C. SFC Control Plane Components Deployment Consideration in 655 Data Center(DC) Environment 657 +---------------------------------------------------------------+ 658 | SFC Control Plane +----------------------+ | 659 | | +------------+ | | 660 | | | SFC | | | 661 | +----------------|Orchestrator-----------+ | 662 | | | +------------+ | | | 663 | | | SFC Management System| | | 664 | | +----------------------+ | | 665 | | | | 666 | | | | 667 | |Download Classifier +--------|------------+ | 668 | | Rule directly | +------|---------+ | | 669 | | | | SFC Forwarding | | | 670 | | -|-------| Control -----|----+ 671 | | | | +----------------+ | | | 672 | | | | SFC Controller | | | 673 | | | | | | | 674 | | | +---------------------+ | | 675 +-------|-------------------------------------------------------+ | 676 +-------|--------------------------------------------------------------+ 677 |+------|-------------+ +---------------+ +---------------+ | | 678 || Enhancement in DC | | Enhancement in| | Enhancement in| | | 679 || | Gateway | | ToR switch or | | ToR Switch or | | | 680 ||+-----|-------+ | | Router | | Router | | | 681 ||| SFC | | |+----|--+ | |+-------+ | | | 682 ||| Classifier |-----------|| |------------- | | | | | 683 ||| Function | | || SFF1 | | || SFF2 ---------+ | 684 ||+-------------+ | || | | || | | | 685 |+--------------------+ |+---|---+ | |+---|---+ | | 686 | +----|----------+ +----|----------+ | 687 | ------------ -----|------ | 688 | | | | | | 689 | +----+ +---+ +----+ +---+ | 690 | | SF1| |SF2| | SF3| |SF4| | 691 | +----+ +---+ +----+ +---+ | 692 |SFC Data Plane | 693 -----------------------------------------------------------------------+ 695 SFC in DC Environment 697 In DC environment, Policy Control component and Chain Management 698 Policy Control component, Service Overlay Topology management defined 699 in section 4 can be supported using SFC Orchestrator. SFC Mapping 700 and Forwarding Control component defined in section 4 can be 701 supported using SFC Controller. 703 Appendix D. SFC Control Plane Components Deployment Consideration in 704 Data Center (DC) Environment 706 +---------------------------------------------------------------+ 707 | SFC Control Plane | 708 | +------------------------+ | 709 | | stateful PCE | | 710 | +-------------| +-------+ +-------+ | | 711 | | | |Policy | | TE-DB | |<-------| | 712 | | | +-------+ +-------+ | | | 713 | | +------------------------+ | | 714 | | ---------------|-----| | 715 | | SFC Controller | | 716 | | | | | 717 | | +--------------------------- | | 718 | | | | | | 719 | | | +------ ------ --+ | 720 | | | | | SFC Forwarding | | | 721 | | | +-------| Control -----|----+ 722 | | | | | +----------------+ | | | 723 | | | | +---------------------+ | | 724 +-------|-----|-------------------------------------------------+ | 725 +-------|-----|--------------------------------------------------------+ 726 |+------|-----|-------+ +---------------+ +---------------+ | | 727 || Enhancement in DC | | Enhancement in| | Enhancement in| | | 728 || | Gateway | | ToR switch or | | ToR Switch or | | | 729 ||+-----|-------+ | | Router | | Router | | | 730 ||| SFC | | |+----|--+ | |+-------+ | | | 731 ||| Classifier |-----------|| |------------- | | | | | 732 ||| Function | | || SFF1 | | || SFF2 ---------+ | 733 ||+-------------+ | || | | || | | | 734 |+--------------------+ |+---|---+ | |+---|---+ | | 735 | +----|----------+ +----|----------+ | 736 | ------------ -----|------ | 737 | | | | | | 738 | +----+ +---+ +----+ +---+ | 739 | | SF1| |SF2| | SF3| |SF4| | 740 | +----+ +---+ +----+ +---+ | 741 |SFC Data Plane | 742 -----------------------------------------------------------------------+ 744 SFC in DC Environment 746 Alternatively, In DC environment, Policy Control component and Chain 747 Management Policy Control component, Service Overlay Topology 748 management defined in section 4 can be supported, SFC Mapping and 749 Forwarding Control component defined in section 4 can be supported 750 together using SFC Controller. In addtion, SFC Controler operates a 751 stateful PCE and its instantiation mechanism to compute and 752 instantiate Service Function Paths (SFP). 754 The PCE maybe co-located with the SFC Control plane component or an 755 external entity (e.g., [I.D-wu-pce-traffic-steering-sfc]). 757 Authors' Addresses 759 Hongyu Li 760 Huawei 761 Huawei Industrial Base,Bantian,Longgang 762 Shenzhen 763 China 765 Email: hongyu.li@huawei.com 767 Qin Wu 768 Huawei 769 101 Software Avenue, Yuhua District 770 Nanjing, Jiangsu 210012 771 China 773 Email: bill.wu@huawei.com 775 Yong(Oliver) Huang 776 Huawei 777 Huawei Industrial Base,Bantian,Longgang 778 Shenzhen 779 China 781 Email: oliver.huang@huawei.com 783 Mohamed Boucadair 784 France Telecom 785 Rennes 35000 786 France 788 Email: mohamed.boucadair@orange.com 789 Christian Jacquenet 790 France Telecom 791 Rennes 35000 792 France 794 Email: christian.jacquenet@orange.com 796 Walter Haeffner 797 Vodafone D2 GmbH 798 Ferdinand-Braun-Platz 1 799 Duesseldorf 40549 800 DE 802 Email: walter.haeffner@vodafone.com 804 Seungik Lee 805 ETRI 806 218 Gajeong-ro Yuseung-Gu 807 Daejeon 305-700 808 Korea 810 Phone: +82 42 860 1483 811 Email: seungiklee@etri.re.kr 813 Ron Parker 814 Affirmed Networks 815 Acton 816 MA 01720 817 USA 819 Email: ron_parker@affirmednetworks.com