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