idnits 2.17.00 (12 Aug 2021) /tmp/idnits64745/draft-wu-pce-traffic-steering-sfc-01.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 J. Tantsura 6 Ericsson 7 February 13, 2014 9 PCEP Extensions for traffic steering support in Service Function 10 Chaining 11 draft-wu-pce-traffic-steering-sfc-01 13 Abstract 15 This document provides an overview of the usage of Path Computation 16 Element (PCE) with Service Function Chaining (SFC); which is 17 described as the definition and instantiation of an ordered set of 18 such service functions (such as firewalls, load balancers), and the 19 subsequent "steering" of traffic flows through those service 20 functions. 22 Further this document specifies extensions to the Path Computation 23 Element Protocol (PCEP) that allow a stateful PCE to compute and 24 instantiate Service Function Paths (SFP). 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on August 17, 2014. 43 Copyright Notice 45 Copyright (c) 2014 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Conventions used in this document . . . . . . . . . . . . . . . 3 62 3. Service Function Paths and PCE . . . . . . . . . . . . . . . . 4 63 4. Overview of PCEP Operation in SFC enabled Networks . . . . . . 5 64 4.1. SFP Instantiation . . . . . . . . . . . . . . . . . . . . . 5 65 4.2. SFP Deletion . . . . . . . . . . . . . . . . . . . . . . . 6 66 4.3. SFP Delegation and Cleanup . . . . . . . . . . . . . . . . 6 67 4.4. SFP State Synchronization . . . . . . . . . . . . . . . . . 6 68 4.5. SFP Update and Report . . . . . . . . . . . . . . . . . . . 6 69 5. Object Formats . . . . . . . . . . . . . . . . . . . . . . . . 6 70 5.1. The OPEN Object . . . . . . . . . . . . . . . . . . . . . . 6 71 5.2. The LSP Object . . . . . . . . . . . . . . . . . . . . . . 7 72 5.2.1. SFP Identifiers TLV . . . . . . . . . . . . . . . . . . 7 73 6. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 8 74 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 75 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 76 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 77 9.1. Normative References . . . . . . . . . . . . . . . . . . . 8 78 9.2. Informative References . . . . . . . . . . . . . . . . . . 8 80 1. Introduction 82 Service chaining enables creation of composite services that consist 83 of an ordered set of Service Functions (SF) that must be applied to 84 packets and/or frames selected as a result of classification as 85 described in [I-D.quinn-sfc-arch] and referred to as Service Function 86 Chain (SFC). Service Function Path (SFP) is the instantiation of a 87 SFC in the network. Packets follow a Service Function Path from a 88 classifier through the requisite Service Functions (SF). 90 [RFC5440] describes the Path Computation Element Protocol (PCEP) as 91 the communication between a Path Computation Client (PCC) and a Path 92 Control Element (PCE), or between PCE and PCE, enabling computation 93 of Multiprotocol Label Switching (MPLS) for Traffic Engineering Label 94 Switched Path (TE LSP). 96 [I-D.ietf-pce-stateful-pce] specifies extensions to PCEP to enable 97 stateful control of MPLS TE LSPs. [I-D.ietf-pce-pce-initiated-lsp] 98 provides the fundamental extensions needed for stateful PCE-initiated 99 LSP instantiation. 101 This document specifies extensions to the PCEP that allow a stateful 102 PCE to compute and instantiate Service Function Paths (SFP). 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 The following terminologies are used in this document: 112 PCC: Path Computation Client. 114 PCE: Path Computation Element. 116 PCEP: Path Computation Element Protocol. 118 PDP: Policy Decision Point. 120 SF: Service Function. 122 SFC: Service Function Chain. 124 SFP: Service Function Path. 126 UNI: User-Network Interface. 128 3. Service Function Paths and PCE 130 Services are constructed as a sequence of SFs that represent an SFC, 131 where SF can be a virtual instance or be embedded in a physical 132 network element, and one or more SFs may be deployed within the same 133 physical network element. SFC creates an abstracted view of a 134 service and specifies the set of required SFs as well as the order in 135 which they must be executed. 137 When an SFC is instantiated into the network it is necessary to 138 select the specific instances of SFs that will be used, and to create 139 the service topology for that SFC using SF's network locator. Thus, 140 instantiation of the SFC results in the creation of a Service 141 Function Path (SFP) and is used for forwarding packets through the 142 SFC. In other words, an SFP is the instantiation of the defined SFC 143 as described in details in [I-D.quinn-sfc-arch]. 145 The selection of SFP can be based on a range of policy attributes, 146 ranging from simple to more elaborate criteria and stateful PCE with 147 extensions to PCEP are one such way to achieve this. 149 Stateful pce [I-D.ietf-pce-stateful-pce] specifies a set of 150 extensions to PCEP to enable stateful control of TE LSPs. 151 [I-D.ietf-pce-pce-initiated-lsp] provides the fundamental motivations 152 and extensions needed for stateful PCE-initiated LSP instantiation. 153 This document specifies extensions that allow a stateful PCE to 154 compute and instantiate Service Function Paths (SFP) via PCEP. 156 +---------------------------------+ 157 |+------+ +------+ PDP | 158 || | | | | 159 || | | | | 160 ||PCE | |Policy| | 161 |*------+ +------+ | 162 *---------------------------------+ 163 / 164 / 165 / SFP 166 / Instan- 167 / tiation 168 / 169 / 170 V 171 +-----+ Signaling +-----+ Signaling +-----+ Signaling +-----+ 172 |SF-In|------------>|SF-1 |------------>|SF-2 |------------>|SF-E | 173 |gress| | | | | |gress| 174 +-----+ +-----+ +-----+ +-----+ 176 Figure 1: SFP instantiation vis PCE 178 A Policy Decision Point (PDP) [RFC2753] is the central entity which 179 is responsible for maintaining SFC Policy Tables and enforcing 180 appropriate policies in SF Nodes described in detail in 181 [I-D.boucadair-sfc-framework]. A PDP may further use stateful PCE 182 and its instantiation mechanism to compute and instantiate Service 183 Function Paths (SFP). The PCE maybe co-located with the PDP or an 184 external entity. 186 4. Overview of PCEP Operation in SFC enabled Networks 188 A PCEP speaker indicates its ability to support PCE initiated dynamic 189 SFP during the PCEP Initialization Phase via mechanism described in 190 Section 5.1. 192 As per section 5.1 of [I-D.ietf-pce-pce-initiated-lsp], the PCE sends 193 a Path Computation LSP Initiate Request (PCInitiate) message to the 194 PCC to instantiate or delete a LSP. This document makes no change to 195 the PCInitiate message format but extends LSP objects described in 196 Section 5.2. 198 4.1. SFP Instantiation 200 The Instantiation operation of SFP is same as defined in section 5.3 201 of [I-D.ietf-pce-pce-initiated-lsp]. Rules of processing and error 202 codes remains unchanged. 204 4.2. SFP Deletion 206 The deletion operation of SFP is same as defined in section 5.4 of 207 [I-D.ietf-pce-pce-initiated-lsp] by sending an LSP Initiate Message 208 with an LSP object carrying the PLSP-ID of the SFP to be removed and 209 an SRP object with the R flag set (LSP-REMOVE as per section 5.2 of 210 [I-D.ietf-pce-pce-initiated-lsp]). Rules of processing and error 211 codes remains unchanged. 213 4.3. SFP Delegation and Cleanup 215 SFP delegation and cleanup operations are same as defined in section 216 6 of [I-D.ietf-pce-pce-initiated-lsp]. Rules of processing and error 217 codes remains unchanged. 219 4.4. SFP State Synchronization 221 State Synchronization operations described in Section 5.4 of 222 [I-D.ietf-pce-stateful-pce] and can be applied for SFPs as well. 224 4.5. SFP Update and Report 226 PCE can make an SFP Update requests to a PCC to update one or more 227 attributes of an SFP and to re-signal the SFP with updated 228 attributes. PCC can make an SFP state report to a PCE to send SFP 229 state. The mechanism are described in [I-D.ietf-pce-stateful-pce] 230 and can be applied for SFPs as well. 232 5. Object Formats 234 5.1. The OPEN Object 236 This document defines a new optional TLV for use in the OPEN Object 237 to indicate the PCEP speaker's capability for Service function 238 Chaining. 240 The SFC-PCE-CAPABILITY TLV is an optional TLV for use in the OPEN 241 Object to advertise the SFC capability on the PCEP session. The 242 format of the SFC-PCE-CAPABILITY TLV is shown in the following 243 figure: 245 0 1 2 3 246 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 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 | Type=TBD | length=4 | 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 | Reserved | Flags | 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 The code point for the TLV type is to be defined by IANA. The TLV 254 length is 4 octets. 256 The value is TBD. 258 As per [I-D.ietf-pce-stateful-pce], PCEP speaker advertises 259 capability for instantiation of PCE-initiated LSPs via Stateful PCE 260 Capability TLV (LSP-INSTANTIATION-CAPABILITY bit) in open message. 261 The inclusion of SFC-PCE-CAPABILITY TLV in an OPEN object indicates 262 that the sender is SFC capable. These mechanism when used together 263 indicates the instantiation capability for SFP by the PCEP speaker. 265 5.2. The LSP Object 267 The LSP object is defined in [I-D.ietf-pce-pce-initiated-lsp] and 268 included here for easy reference. 270 0 1 2 3 271 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 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 | PLSP-ID | Flags |F|C| O|A|R|S|D| 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 // TLVs // 276 | | 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 A new flag, the SFC (F) flag is introduced. The F Flag set to 1 to 280 indicate that this an SFP. The C flag will also be set to indicate 281 it was created via a PCInitiate message. 283 5.2.1. SFP Identifiers TLV 285 The SFP Identifiers TLV MUST be included in the LSP object for 286 Service Function Paths (SFP). 288 The format and operations are TBD. 290 6. Backward Compatibility 292 The PCEP protocol extensions described in this document for PCEP 293 speaker with instantiation capability for SFPs MUST NOT be used if 294 PCC or PCE has not advertised its stateful capability with 295 Instantiation and SFC capability as per Section 5.1. If this is not 296 the case and Stateful operations on SFPs are attempted, then a PCErr 297 with error-type 19 (Invalid Operation) and error-value TBD needs to 298 be generated. 300 [Editor Note: more information on exact error value is needed] 302 7. Security Considerations 304 The security considerations described in [RFC5440] and 305 [I-D.ietf-pce-pce-initiated-lsp] are applicable to this 306 specification. No additional security measure is required. 308 8. IANA Considerations 310 TBD 312 9. References 314 9.1. Normative References 316 [RFC2119] Bradner, S., "Key words for use in 317 RFCs to Indicate Requirement 318 Levels", BCP 14, RFC 2119, 319 March 1997. 321 [I-D.ietf-pce-stateful-pce] Crabbe, E., Medved, J., Minei, I., 322 and R. Varga, "PCEP Extensions for 323 Stateful PCE", 324 draft-ietf-pce-stateful-pce-07 325 (work in progress), October 2013. 327 [I-D.ietf-pce-pce-initiated-lsp] Crabbe, E., Minei, I., Sivabalan, 328 S., and R. Varga, "PCEP Extensions 329 for PCE-initiated LSP Setup in a 330 Stateful PCE Model", 331 draft-ietf-pce-pce-initiated-lsp-00 332 (work in progress), December 2013. 334 9.2. Informative References 336 [RFC2753] Yavatkar, R., Pendarakis, D., and 337 R. Guerin, "A Framework for Policy- 338 based Admission Control", RFC 2753, 339 January 2000. 341 [RFC5440] Vasseur, JP. and JL. Le Roux, "Path 342 Computation Element (PCE) 343 Communication Protocol (PCEP)", 344 RFC 5440, March 2009. 346 [I-D.quinn-sfc-arch] Quinn, P. and A. Beliveau, "Service 347 Function Chaining (SFC) 348 Architecture", 349 draft-quinn-sfc-arch-04 (work in 350 progress), January 2014. 352 [I-D.boucadair-sfc-framework] Boucadair, M., Jacquenet, C., 353 Parker, R., Lopez, D., Guichard, 354 J., and C. Pignataro, "Service 355 Function Chaining: Framework & 356 Architecture", 357 draft-boucadair-sfc-framework-02 358 (work in progress), February 2014. 360 Authors' Addresses 362 Qin Wu 363 Huawei 364 101 Software Avenue, Yuhua District 365 Nanjing, Jiangsu 210012 366 China 368 EMail: sunseawq@huawei.com 370 Dhruv Dhody 371 Huawei 372 Leela Palace 373 Bangalore, Karnataka 560008 374 INDIA 376 EMail: dhruv.ietf@gmail.com 377 Jeff Tantsura 378 Ericsson 379 300 Holger Way 380 San Jose, CA 95134 381 US 383 EMail: Jeff.Tantsura@ericsson.com