idnits 2.17.00 (12 Aug 2021) /tmp/idnits53186/draft-wang-msv-using-virtual-line-card-02.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 (February 14, 2014) is 3011 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) == Unused Reference: 'ALTO' is defined on line 350, but no explicit reference was found in the text == Unused Reference: 'RFC4655' is defined on line 354, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Q. Wu 3 Internet-Draft D. Wang 4 Intended status: Standards Track Huawei 5 Expires: August 18, 2014 M. Boucadair 6 C. Boucadair 7 France Telecom 8 X. Zhang 9 Y. Shi 10 Huawei 11 February 14, 2014 13 Service Function Chain Control Plane Overview 14 draft-wang-msv-using-virtual-line-card-02 16 Abstract 18 As described in [I.D-boucadair-sfc-framework], the dynamic 19 enforcement of a Service-derived, adequate forwarding policy for 20 packets entering a network that supports such advanced Service 21 Functions has become a key challenge for operators and service 22 providers. 24 This document is based on [I.D-boucadair-sfc-framework] and focusing 25 on discussing how the Service Functions are discovered and 26 provisioned and how Service Function Chaining path is 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 August 18, 2014. 45 Copyright 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 . . . . . . . . . . . . . . 4 64 3. SFC Control Plane Overview . . . . . . . . . . . . . . . . . . 5 65 4. Signaling procedure . . . . . . . . . . . . . . . . . . . . . 7 66 4.1. Building Service Topology . . . . . . . . . . . . . . . . 7 67 4.2. Service Function Discovery . . . . . . . . . . . . . . . . 7 68 4.3. Service Function Map Selection . . . . . . . . . . . . . . 8 69 4.4. Building Service Function Chaining (SFC) Policy Tables . . 8 70 4.5. Service Function Chaining Path Setup and Policy 71 configuration . . . . . . . . . . . . . . . . . . . . . . 8 72 4.6. Service Availability . . . . . . . . . . . . . . . . . . . 9 73 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 74 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 75 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 76 7.1. Normative References . . . . . . . . . . . . . . . . . . . 13 77 7.2. Informative References . . . . . . . . . . . . . . . . . . 13 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 80 1. Introduction 82 Service Function Chaining(SFC) refers to the delivery of added value 83 services by invoking, in a given order, a set of Service Functions 84 along the forwarding path towards a specific destination [I.D-quinn- 85 sfc-problem-statement]. Service functions involved in a given SFC 86 may include advanced Service Functions such as load-balancing, 87 firewalling, intrusion prevention. A given SFC domain may involve 88 several instances of the same Service Functions. Service Function 89 instances can be automatically added or removed to an SFC. Service 90 functions can be co-located on the same physical node or be embedded 91 in distinct physical nodes. 93 As described in [I.D-boucadair-sfc-framework], the dynamic 94 enforcement of a SF-derived, adequate forwarding policy for packets 95 entering a network that supports such advanced Service Functions has 96 become a key challenge for operators and service providers. 98 This document is based on [I.D-boucadair-sfc-framework]and is 99 focusing on discussing how the set of available Service Functions 100 (including several instances of the same Service Function) are 101 discovered and provisioned and how Service Function Chaining path is 102 setup. 104 2. Conventions used in this document 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 108 document are to be interpreted as described in RFC2119 [RFC2119]. 110 3. SFC Control Plane Overview 112 The Service Function Chain Control plane Overview proposed in this 113 document includes a topology server, policy decision point(PDP), and 114 service Function(SF) Nodes, SFC Ingress Node, SFC Egress Node. 115 Service functions can be co-located on one SF Node or physically 116 separated across several SF Nodes with each having one or more 117 Service Functions. The Topology server(Topo Server for short) is 118 used to locate SF Nodes in the network as needed. The PDP is a 119 central control/management plane entity and used to maintain SFC 120 Policy Tables defined in figure 1 of [I.D- boucadair-sfc-framework], 121 and generating and communicating appropriate policies in SF Nodes and 122 SFC Ingress/Egress Nodes. To create SF map in the SFC Policy tables, 123 PDP may interact with the Topo Server using SF node discovery 124 protocol to build SF maps. To communicate policies in SF nodes, 125 either fully centralized approach, or half centralized approach or 126 distributed approach can be used. 128 o In the fully centralized approach, Communication between PDP and 129 Topo Server can be used to return computed path information . 130 I2RS signaling can be used communicate policy between PDP and SF 131 Node or between PDP and SF Ingress/Egress Node. 133 o In the distributed approach, The Topo server communicate with SFC 134 Ingress Node and returns computed path in the Explicit Route 135 Object in the response [I.D-wu-pce-traffic-steering-sfc]. SFC 136 Ingress Node then can use RSVP-TE to initiate signaling and 137 communicate policy with each SF Node and establish the service 138 Function Chaining path. 140 o In the half centralized approach, The Topo server communicate with 141 SFC Ingress Node and return the path computation results to SFC 142 Ingress Node and then SFC Ingress Node uses RSVP-TE to populate 143 the Path profile Identifier in each SF node [I.D-wu-pce-traffic- 144 steering-sfc]. Then each SF node can use Path Profile Identifier 145 to request PDP for SF path profile. 147 +-------------+ 148 +---------------------| | 149 | (e.g.,PCEP, ALTO..) | Topo Server | 150 | +------------------| | 151 | | +----A--------+ 152 | | | | 153 | | | |(e.g.,PCEP, ALTO..) 154 | | Netconf.. +----|-----V--+ 155 | | +--------------> PDP <------------------+ 156 | | | | <---+ | 157 | | | +-A-----------+ | | 158 | | | | | | 159 | | | | | | 160 | | | RSVP-TE.. | | | 161 +-V--V---V--+ +-------V-+ +------V--+ +-----V------+ 162 |SFC Ingress| | SF | | SF | | SFC Egress | 163 | Node |---->| Node1 |----->| Node2 |---->| Node | 164 | |<----| |<---- | |<----| | 165 +-----------+ | SF1 SF2 | | SF3 SF4 | +------------+ 166 +---------+ +---------+ 168 4. Signaling procedure 170 4.1. Building Service Topology 172 Network topology information can be collected from network by using 173 IGP or BGP-LS [I.D-draft-idr-ls-distribution]. 175 Not all SF Nodes can be directly connected. The Service overlay 176 creates a forwarding path between SF Nodes or connected graph for 177 these SF Nodes. SF nodes can be co-located on the same physical node 178 or be embedded in distinct physical nodes. A service specific 179 overlay utilized by SFC creates the service topology. Service 180 topology information includes SF Identifier, SF Locator, Service 181 Function administration information (Packet rate 182 utilization,Bandwidth utilization per CoS,Packet rate utilization per 183 Cos,Memory utilization, RIB utilization per address family, FIB 184 utilization per address family,,available memory,CPU 185 utilization,Available storage)or Service Function capability 186 information(e.g.,supported ACLnumbers, virtual context 187 number,supported-packet-rate) Service topology information can be 188 collected by the Topo server using either I2RS interface or routing 189 protocol. The Topo Server can be collocated with PDP or physically 190 separated from the entity that supports the PDP. 192 Within the service topology, an ordered set of SF nodes will be 193 invoked for each packet that belongs to a given flow for which a SFC 194 will be applied. Adding new Service Functions to SF Node in the 195 Service topology is easily accomplished, and no underlying network 196 changes are required. Furthermore, additional service Functions or 197 Service Function instances, for redundancy or load distribution 198 purpose, can be added or removed to the service topology as required. 200 4.2. Service Function Discovery 202 When service topology is created by a service-specific overlay 203 utilized by Service Function Chaining, each Service Function type is 204 assigned with a unique SF identifier and can be located using SF 205 locator. There are one approache for Service Function Discovery 207 o PDP initiated Service Function Discovery 209 * Upon receiving service request, PDP send path computation 210 request to Topo server. 212 The Service request carries various constraint information or 213 resource requirements(e.g., SF location constraint, SF order 214 constraint, SF capability information) The topo Server looks up 215 service topology information and returns either computed path or path 216 profile Identifier to the PDP. In the centralized approach, the Topo 217 server will return computed path to the PDP. In the distributed 218 approach, the Topo server will send computed path to the SF Ingress 219 Node. In the half centralized approach, the Topo server will only 220 return path profile Identifier to the SF Ingress Node. 222 4.3. Service Function Map Selection 224 In either PDP initiates Service Function Discovery or SF Ingress Node 225 Initiated Service Function Discovery, PDP will compose the Service 226 Function Map based on the returned computed path. If there are 227 multiple Service Functions or Service Function Instances can satisfy 228 service requirements, the PDP will select appropriate Service 229 Function based on Service Functions capability info or local policy 230 to build Service Function Map. 232 4.4. Building Service Function Chaining (SFC) Policy Tables 234 In case of SFC ingress node initiated Service Function Discovery, the 235 SFC ingress node retrieves path profile Identifier in the half 236 centralized approach and retrieves service Function Map and 237 associated Service Function Map index from the Topo server in the 238 distributed approach. The SFC ingress Node can create entries in the 239 Policy Table based on Service Function Map obtained from the Topo 240 server. 242 In case of PDP initiated Service Function Discovery, the PDP retrieve 243 computed path information from topo server and compose service 244 Function Map based on computed path information and create entries in 245 the Policy Table . 247 4.5. Service Function Chaining Path Setup and Policy configuration 249 In case of SFC ingress node initiated Service Function Discovery, SFC 250 ingress node initiate signaling to establish the service chaining 251 path. Path Profile ID can be carried in the RSVP-TE message and 252 populated to each SF Node in the Service Function Chain. When each 253 SF node receives Path Profile ID, it will pull policy table based on 254 Path Profile ID from PDP. 256 In case of PDP initiated Service Function Discovery, PDP will use 257 I2RS interface and communicate policy with each SF node in the 258 Service Function Chain. A set of policy templates can be pre- 259 defined, as shown in Figure 3. By applying policy template, 260 different service chains are pre- provisioned and provided to users. 261 For example, the "DATA_SEC" template defined in Figure 3 implies you 262 can choose random combinations of these services provided in the 263 "Service-chain" list. 265 Policy Template Service-chain list 266 DLP 267 DATA_SEC AV 268 IPS 269 DPI 270 SIP 272 Figure 3 Policy Template 274 4.6. Service Availability 276 In order to check service Function availability for each SF node, the 277 control channel should be setup between service function and 278 monitoring system to keep track of state change or performance issue. 279 The monitoring system can be either collocated with 281 o PDP 283 o or NFVPool Manager 285 o or vswitch as SF node or overlay node in the service overlay. 287 When one service Function is not a mandatory service function(e.g., 288 HTTP optimization service function) in the Service Function Chain and 289 break down, this service function can be bypassed from service 290 Function chain, the service will not be interrupted since other 291 service functions still work well, but service provided by service 292 function chain is in the degraded mode. When the service function is 293 a mandatory service function (e.g., firewall) in the Service Function 294 Chain and break down, the service will be interrupted before this 295 service function recovers from failing. 297 ^ ^ 298 | | 299 +--|----------|--+ 300 ___________________|__| | | 301 | | | | 302 +--------+ Heartbeat | | | 303 | vFW |----------------->| vSwitch | | 304 +--------+ | (SF Node) | | 305 | __________________|__ | | 306 Fail | | | | 307 +--|----------|--+ 308 | | 309 | | 310 | | 311 Security Failure 312 Detection ----> 313 Process Bypass 315 Figure 4 Heartbeat Monitoring Process 317 5. Security Considerations 319 TBD 321 6. Acknowledgements 323 The author would like to thank LAC Chidung for his review and 324 comments that help improvement to this document. 326 7. References 328 7.1. Normative References 330 [I.D-boucadair-sfc-framework] 331 Boucadair, M., "Service Function Chaining: Framework & 332 Architecture", ID draft-boucadair-sfc-framework-00, 333 October 2013. 335 [I.D-quinn-sfc-problem-statement] 336 Quinn, P., "Network Service Chaining Problem Statement", 337 ID draft-quinn-nsc-problem-statement-03, August 2013. 339 [I.D-wu-pce-traffic-steering-sfc] 340 Wu, Q., Dhody, D., Boucadair, M., Boucadair, C., and J. 341 Tantsura, "PCEP Extensions for traffic steering support in 342 Service Function Chaining", 343 ID draft-wu-pce-traffic-steering-sfc-02, Feburary 2014. 345 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 346 Requirement Levels", March 1997. 348 7.2. Informative References 350 [ALTO] Yang, Y., "ALTO Protocol", 351 ID http://tools.ietf.org/html/draft-ietf-alto-protocol-16, 352 May 2013. 354 [RFC4655] Farrel, A., "A Path Computation Element (PCE)-Based 355 Architecture", RFC 4655, August 2006. 357 Authors' Addresses 359 Qin Wu 360 Huawei 361 101 Software Avenue, Yuhua District 362 Nanjing, Jiangsu 210012 363 China 365 Email: bill.wu@huawei.com 367 Danhua Wang 368 Huawei 369 101 Software Avenue, Yuhua District 370 Nanjing, Jiangsu 210012 371 China 373 Email: wangdanhua@huawei.com 375 Mohamed Boucadair 376 France Telecom 377 Rennes 35000 378 France 380 Email: mohamed.boucadair@orange.com 382 Christian Jacquenet 383 France Telecom 384 Rennes 35000 385 France 387 Email: christian.jacquenet@orange.com 389 XianGuo Zhang 390 Huawei 391 Beijing, 100085 392 China 394 Email: zhangxianguo09@huawei.com 395 Yang Shi 396 Huawei 397 Beijing, 100085 398 China 400 Email: shiyang1@huawei.com