idnits 2.17.00 (12 Aug 2021) /tmp/idnits385/draft-wu-pce-traffic-steering-sfc-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 13, 2014) is 3019 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) == Outdated reference: draft-ietf-pce-stateful-pce has been published as RFC 8231 == Outdated reference: draft-ietf-pce-pce-initiated-lsp has been published as RFC 8281 == Outdated reference: A later version (-05) exists of draft-quinn-sfc-arch-04 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE Working Group Q. Wu 3 Internet-Draft D. Dhody 4 Intended status: Standards Track Huawei 5 Expires: August 17, 2014 M. Boucadair 6 C. Boucadair 7 France Telecom 8 J. Tantsura 9 Ericsson 10 February 13, 2014 12 PCEP Extensions for traffic steering support in Service Function 13 Chaining 14 draft-wu-pce-traffic-steering-sfc-02 16 Abstract 18 This document provides an overview of the usage of Path Computation 19 Element (PCE) with Service Function Chaining (SFC); which is 20 described as the definition and instantiation of an ordered set of 21 such service functions (such as firewalls, load balancers), and the 22 subsequent "steering" of traffic flows through those service 23 functions. 25 Further this document specifies extensions to the Path Computation 26 Element Protocol (PCEP) that allow a stateful PCE to compute and 27 instantiate Service Function Paths (SFP). 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on August 17, 2014. 46 Copyright 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. Service Function Paths and PCE . . . . . . . . . . . . . . . . 4 66 4. Overview of PCEP Operation in SFC enabled Networks . . . . . . 5 67 4.1. SFP Instantiation . . . . . . . . . . . . . . . . . . . . . 5 68 4.2. SFP Deletion . . . . . . . . . . . . . . . . . . . . . . . 6 69 4.3. SFP Delegation and Cleanup . . . . . . . . . . . . . . . . 6 70 4.4. SFP State Synchronization . . . . . . . . . . . . . . . . . 6 71 4.5. SFP Update and Report . . . . . . . . . . . . . . . . . . . 6 72 5. Object Formats . . . . . . . . . . . . . . . . . . . . . . . . 6 73 5.1. The OPEN Object . . . . . . . . . . . . . . . . . . . . . . 6 74 5.2. The LSP Object . . . . . . . . . . . . . . . . . . . . . . 7 75 5.2.1. SFP Identifiers TLV . . . . . . . . . . . . . . . . . . 7 76 6. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 8 77 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 78 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 79 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 80 9.1. Normative References . . . . . . . . . . . . . . . . . . . 8 81 9.2. Informative References . . . . . . . . . . . . . . . . . . 8 83 1. Introduction 85 Service chaining enables creation of composite services that consist 86 of an ordered set of Service Functions (SF) that must be applied to 87 packets and/or frames selected as a result of classification as 88 described in [I-D.boucadair-sfc-framework][I-D.quinn-sfc-arch] and 89 referred to as Service Function Chain (SFC). Service Function Path 90 (SFP) is the instantiation of a SFC in the network. Packets follow a 91 Service Function Path from a classifier through the requisite Service 92 Functions (SF). 94 [RFC5440] describes the Path Computation Element Protocol (PCEP) as 95 the communication between a Path Computation Client (PCC) and a Path 96 Control Element (PCE), or between PCE and PCE, enabling computation 97 of Multiprotocol Label Switching (MPLS) for Traffic Engineering Label 98 Switched Path (TE LSP). 100 [I-D.ietf-pce-stateful-pce] specifies extensions to PCEP to enable 101 stateful control of MPLS TE LSPs. [I-D.ietf-pce-pce-initiated-lsp] 102 provides the fundamental extensions needed for stateful PCE-initiated 103 LSP instantiation. 105 This document specifies extensions to the PCEP that allow a stateful 106 PCE to compute and instantiate Service Function Paths (SFP). 108 2. Conventions used in this document 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 112 document are to be interpreted as described in RFC2119 [RFC2119]. 114 The following terminologies are used in this document: 116 PCC: Path Computation Client. 118 PCE: Path Computation Element. 120 PCEP: Path Computation Element Protocol. 122 PDP: Policy Decision Point. 124 SF: Service Function. 126 SFC: Service Function Chain. 128 SFP: Service Function Path. 130 UNI: User-Network Interface. 132 3. Service Function Paths and PCE 134 Services are constructed as a sequence of SFs that represent an SFC, 135 where SF can be a virtual instance or be embedded in a physical 136 network element, and one or more SFs may be deployed within the same 137 physical network element. SFC creates an abstracted view of a 138 service and specifies the set of required SFs as well as the order in 139 which they must be executed. 141 When an SFC is instantiated into the network it is necessary to 142 select the specific instances of SFs that will be used, and to create 143 the service topology for that SFC using SF's network locator. Thus, 144 instantiation of the SFC results in the creation of a Service 145 Function Path (SFP) and is used for forwarding packets through the 146 SFC. In other words, an SFP is the instantiation of the defined SFC 147 as described in details in 148 [I-D.boucadair-sfc-framework][I-D.quinn-sfc-arch]. 150 The selection of SFP can be based on a range of policy attributes, 151 ranging from simple to more elaborate criteria and stateful PCE with 152 extensions to PCEP are one such way to achieve this. 154 Stateful pce [I-D.ietf-pce-stateful-pce] specifies a set of 155 extensions to PCEP to enable stateful control of TE LSPs. 156 [I-D.ietf-pce-pce-initiated-lsp] provides the fundamental motivations 157 and extensions needed for stateful PCE-initiated LSP instantiation. 158 This document specifies extensions that allow a stateful PCE to 159 compute and instantiate Service Function Paths (SFP) via PCEP. 161 +---------------------------------+ 162 |+------+ +------+ PDP | 163 || | | | | 164 || | | | | 165 ||PCE | |Policy| | 166 |*------+ +------+ | 167 *---------------------------------+ 168 / 169 / 170 / SFP 171 / Instan- 172 / tiation 173 / SF Node1 SF Node2 174 / +-------+ +-------+ 175 V | | | | 176 +-----+ Signaling |+-----+| Signaling |+-----+| Signaling +-----+ 177 |SF-In|----------->||SF-1 || --------->||SF-2 ||----------->|SF-E | 178 |gress| || || || || |gress| 179 +-----+ |+-----+| |+-----+| +-----+ 180 +-------+ +-------+ 182 Figure 1: SFP instantiation vis PCE 184 A Policy Decision Point (PDP) [RFC2753] is the central entity which 185 is responsible for maintaining SFC Policy Tables and enforcing 186 appropriate policies in SF Nodes described in detail in 187 [I-D.boucadair-sfc-framework]. A PDP may further use stateful PCE 188 and its instantiation mechanism to compute and instantiate Service 189 Function Paths (SFP). The PCE maybe co-located with the PDP or an 190 external entity. 192 4. Overview of PCEP Operation in SFC enabled Networks 194 A PCEP speaker indicates its ability to support PCE initiated dynamic 195 SFP during the PCEP Initialization Phase via mechanism described in 196 Section 5.1. 198 As per section 5.1 of [I-D.ietf-pce-pce-initiated-lsp], the PCE sends 199 a Path Computation LSP Initiate Request (PCInitiate) message to the 200 PCC to instantiate or delete a LSP. This document makes no change to 201 the PCInitiate message format but extends LSP objects described in 202 Section 5.2. 204 4.1. SFP Instantiation 206 The Instantiation operation of SFP is same as defined in section 5.3 207 of [I-D.ietf-pce-pce-initiated-lsp]. Rules of processing and error 208 codes remains unchanged. 210 4.2. SFP Deletion 212 The deletion operation of SFP is same as defined in section 5.4 of 213 [I-D.ietf-pce-pce-initiated-lsp] by sending an LSP Initiate Message 214 with an LSP object carrying the PLSP-ID of the SFP to be removed and 215 an SRP object with the R flag set (LSP-REMOVE as per section 5.2 of 216 [I-D.ietf-pce-pce-initiated-lsp]). Rules of processing and error 217 codes remains unchanged. 219 4.3. SFP Delegation and Cleanup 221 SFP delegation and cleanup operations are same as defined in section 222 6 of [I-D.ietf-pce-pce-initiated-lsp]. Rules of processing and error 223 codes remains unchanged. 225 4.4. SFP State Synchronization 227 State Synchronization operations described in Section 5.4 of 228 [I-D.ietf-pce-stateful-pce] and can be applied for SFPs as well. 230 4.5. SFP Update and Report 232 PCE can make an SFP Update requests to a PCC to update one or more 233 attributes of an SFP and to re-signal the SFP with updated 234 attributes. PCC can make an SFP state report to a PCE to send SFP 235 state. The mechanism are described in [I-D.ietf-pce-stateful-pce] 236 and can be applied for SFPs as well. 238 5. Object Formats 240 5.1. The OPEN Object 242 This document defines a new optional TLV for use in the OPEN Object 243 to indicate the PCEP speaker's capability for Service function 244 Chaining. 246 The SFC-PCE-CAPABILITY TLV is an optional TLV for use in the OPEN 247 Object to advertise the SFC capability on the PCEP session. The 248 format of the SFC-PCE-CAPABILITY TLV is shown in the following 249 figure: 251 0 1 2 3 252 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 | Type=TBD | length=4 | 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 | Reserved | Flags | 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 The code point for the TLV type is to be defined by IANA. The TLV 260 length is 4 octets. 262 The value is TBD. 264 As per [I-D.ietf-pce-stateful-pce], PCEP speaker advertises 265 capability for instantiation of PCE-initiated LSPs via Stateful PCE 266 Capability TLV (LSP-INSTANTIATION-CAPABILITY bit) in open message. 267 The inclusion of SFC-PCE-CAPABILITY TLV in an OPEN object indicates 268 that the sender is SFC capable. These mechanism when used together 269 indicates the instantiation capability for SFP by the PCEP speaker. 271 5.2. The LSP Object 273 The LSP object is defined in [I-D.ietf-pce-pce-initiated-lsp] and 274 included here for easy reference. 276 0 1 2 3 277 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 | PLSP-ID | Flags |F|C| O|A|R|S|D| 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 // TLVs // 282 | | 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 A new flag, the SFC (F) flag is introduced. The F Flag set to 1 to 286 indicate that this an SFP. The C flag will also be set to indicate 287 it was created via a PCInitiate message. 289 5.2.1. SFP Identifiers TLV 291 The SFP Identifiers TLV MUST be included in the LSP object for 292 Service Function Paths (SFP). 294 The format and operations are TBD. 296 6. Backward Compatibility 298 The PCEP protocol extensions described in this document for PCEP 299 speaker with instantiation capability for SFPs MUST NOT be used if 300 PCC or PCE has not advertised its stateful capability with 301 Instantiation and SFC capability as per Section 5.1. If this is not 302 the case and Stateful operations on SFPs are attempted, then a PCErr 303 with error-type 19 (Invalid Operation) and error-value TBD needs to 304 be generated. 306 [Editor Note: more information on exact error value is needed] 308 7. Security Considerations 310 The security considerations described in [RFC5440] and 311 [I-D.ietf-pce-pce-initiated-lsp] are applicable to this 312 specification. No additional security measure is required. 314 8. IANA Considerations 316 TBD 318 9. References 320 9.1. Normative References 322 [RFC2119] Bradner, S., "Key words for use in 323 RFCs to Indicate Requirement 324 Levels", BCP 14, RFC 2119, 325 March 1997. 327 [I-D.ietf-pce-stateful-pce] Crabbe, E., Medved, J., Minei, I., 328 and R. Varga, "PCEP Extensions for 329 Stateful PCE", 330 draft-ietf-pce-stateful-pce-07 331 (work in progress), October 2013. 333 [I-D.ietf-pce-pce-initiated-lsp] Crabbe, E., Minei, I., Sivabalan, 334 S., and R. Varga, "PCEP Extensions 335 for PCE-initiated LSP Setup in a 336 Stateful PCE Model", 337 draft-ietf-pce-pce-initiated-lsp-00 338 (work in progress), December 2013. 340 9.2. Informative References 342 [RFC2753] Yavatkar, R., Pendarakis, D., and 343 R. Guerin, "A Framework for Policy- 344 based Admission Control", RFC 2753, 345 January 2000. 347 [RFC5440] Vasseur, JP. and JL. Le Roux, "Path 348 Computation Element (PCE) 349 Communication Protocol (PCEP)", 350 RFC 5440, March 2009. 352 [I-D.quinn-sfc-arch] Quinn, P. and A. Beliveau, "Service 353 Function Chaining (SFC) 354 Architecture", 355 draft-quinn-sfc-arch-04 (work in 356 progress), January 2014. 358 [I-D.boucadair-sfc-framework] Boucadair, M., Jacquenet, C., 359 Parker, R., Lopez, D., Guichard, 360 J., and C. Pignataro, "Service 361 Function Chaining: Framework & 362 Architecture", 363 draft-boucadair-sfc-framework-02 364 (work in progress), February 2014. 366 Authors' Addresses 368 Qin Wu 369 Huawei 370 101 Software Avenue, Yuhua District 371 Nanjing, Jiangsu 210012 372 China 374 EMail: sunseawq@huawei.com 376 Dhruv Dhody 377 Huawei 378 Leela Palace 379 Bangalore, Karnataka 560008 380 INDIA 382 EMail: dhruv.ietf@gmail.com 383 Mohamed Boucadair 384 France Telecom 385 Rennes 35000 386 France 388 EMail: mohamed.boucadair@orange.com 390 Christian Jacquenet 391 France Telecom 392 Rennes 35000 393 France 395 EMail: christian.jacquenet@orange.com 397 Jeff Tantsura 398 Ericsson 399 300 Holger Way 400 San Jose, CA 95134 401 US 403 EMail: Jeff.Tantsura@ericsson.com