idnits 2.17.00 (12 Aug 2021) /tmp/idnits64099/draft-wu-pce-traffic-steering-sfc-05.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 (September 14, 2014) is 2806 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: 'RFC2753' is defined on line 367, but no explicit reference was found in the text == Unused Reference: 'RFC5394' is defined on line 371, but no explicit reference was found in the text == 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: draft-ietf-sfc-architecture has been published as RFC 7665 == Outdated reference: A later version (-06) exists of draft-ww-sfc-control-plane-02 Summary: 0 errors (**), 0 flaws (~~), 7 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: March 18, 2015 M. Boucadair 6 C. Jacquenet 7 France Telecom 8 J. Tantsura 9 Ericsson 10 September 14, 2014 12 PCEP Extensions for traffic steering support in Service Function 13 Chaining 14 draft-wu-pce-traffic-steering-sfc-05 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 This document specifies extensions to the Path Computation Element 26 Protocol (PCEP) that allow a stateful PCE to compute and instantiate 27 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 March 18, 2015. 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 64 2. Conventions used in this document . . . . . . . . . . . . . . 3 65 3. Service Function Paths and PCE . . . . . . . . . . . . . . . 3 66 4. Overview of PCEP Operation in SFC-enabled Networks . . . . . 5 67 4.1. SFP Instantiation . . . . . . . . . . . . . . . . . . . . 5 68 4.2. SFP Withdrawal . . . . . . . . . . . . . . . . . . . . . 5 69 4.3. SFP Delegation and Cleanup . . . . . . . . . . . . . . . 5 70 4.4. SFP State Synchronization . . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . . . . . . . . . 6 75 5.2.1. SFP Identifiers TLV . . . . . . . . . . . . . . . . . 7 76 6. Backward Compatibility . . . . . . . . . . . . . . . . . . . 7 77 7. Relationship to SR . . . . . . . . . . . . . . . . . . . . . 7 78 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 79 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 80 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 81 10.1. Normative References . . . . . . . . . . . . . . . . . . 8 82 10.2. Informative References . . . . . . . . . . . . . . . . . 8 84 1. Introduction 86 Service chaining enables the creation of composite services that 87 consist of an ordered set of Service Functions (SF) that must be 88 applied to packets and/or frames selected as a result of 89 classification as described in [I-D.ietf-sfc-architecture] and 90 referred to as Service Function Chain (SFC). A Service Function Path 91 (SFP) is the instantiation of a SFC in the network. Packets follow a 92 Service Function Path from a classifier through the requisite Service 93 Functions (SF). 95 [RFC5440] describes the Path Computation Element Protocol (PCEP) as 96 the communication between a Path Computation Client (PCC) and a Path 97 Control Element (PCE), or between PCE and PCE, enabling computation 98 of Multiprotocol Label Switching (MPLS) for Traffic Engineering Label 99 Switched Path (TE LSP). 101 [I-D.ietf-pce-stateful-pce] specifies extensions to PCEP to enable 102 stateful control of MPLS TE LSPs. [I-D.ietf-pce-pce-initiated-lsp] 103 provides the fundamental extensions needed for stateful PCE-initiated 104 LSP instantiation. 106 This document specifies extensions to the PCEP that allow a stateful 107 PCE to compute and instantiate Service Function Paths (SFP). 109 2. Conventions used in this document 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in RFC2119 [RFC2119]. 115 The following terminologies are used in this document: 117 PCC: Path Computation Client. 119 PCE: Path Computation Element. 121 PCEP: Path Computation Element Protocol. 123 PDP: Policy Decision Point. 125 SF: Service Function. 127 SFC: Service Function Chain. 129 SFP: Service Function Path. 131 SFF: Service Forwarder Function. 133 UNI: User-Network Interface. 135 3. Service Function Paths and PCE 137 Services are constructed as a sequence of SFs that represent an SFC, 138 where a SF can be a virtual instance or be embedded in a physical 139 network element, and one or more SFs may be supported by the same 140 physical network element. A SFC creates an abstracted view of a 141 service and specifies the set of required SFs as well as the order in 142 which they must be executed. 144 When an SFC is instantiated into the network it is necessary to 145 select the specific instances of SFs that will be used, and to create 146 the service topology for that SFC using SF network locators. Thus, 147 instantiation of the SFC results in the creation of a Service 148 Function Path (SFP) and is used for forwarding packets through the 149 SFC. In other words, an SFP is the instantiation of the defined SFC 150 as described in [I-D.ietf-sfc-architecture]. 152 The selection of SFP can be based on a set of policy attributes 153 (forwarding and routing, QoS, security, etc., or a combination 154 thereof), ranging from simple to more elaborate selection criteria 155 and the use of stateful PCE with extensions to PCEP are one such way 156 to achieve this. 158 Stateful pce [I-D.ietf-pce-stateful-pce] specifies a set of 159 extensions to PCEP to enable stateful control of TE LSPs. 160 [I-D.ietf-pce-pce-initiated-lsp] provides the fundamental motivations 161 and extensions needed for stateful PCE-initiated LSP instantiation. 162 This document specifies extensions that allow a stateful PCE to 163 compute and instantiate Service Function Paths (SFP) via PCEP. 165 +------------------------+ 166 | stateful PCE | 167 | +-------+ +-------+ | 168 | |Policy | | TE-DB | | +-------+ 169 | +-------+ +-------+ | | SFC | 170 +----------| +-------------+ |<---|control| 171 |SFP | |LSP-DB/SFP-DB| | | plane | 172 |Instan- | +-------------+ | +-------+ 173 |tiation +------------------------+ 174 | +-----+ +-----+ +-----+ 175 | |SF-1 | |SF-2 | |SF-3 | 176 | | | | | | | 177 | +---+-+ +-+---+ +--+--+ 178 | | | | 179 | ++-----++ +----+--+ 180 V | | | | 181 +-----+ Signaling | | Signaling | | Signaling 182 | SF |----------->| SFF-1 | --------->| SFF-2 |-----------> 183 Classifier | | | | 184 |Node | | | | | 185 +-----+ +-------+ +-------+ 187 Figure 1: PCE based SFP instantiation 189 SFC Control plane components are responsible for maintaining SFC 190 Policy Tables and enforcing appropriate policies in SF Classifier and 191 SFF Nodes as described in 193 [I-D.ietf-sfc-architecture][I-D.ww-sfc-control-plane]. The SFC 194 Control plane component can be seen as a policy Decision point 195 (PDP,[RFC5394]). Such PDP can then operates a stateful PCE and its 196 instantiation mechanism to compute and instantiate Service Function 197 Paths (SFP). The PCE maybe co-located with the SFC Control plane 198 component or an external entity. 200 4. Overview of PCEP Operation in SFC-enabled Networks 202 A PCEP speaker indicates its ability to support PCE provisioned 203 dynamic SFP paths during the PCEP Initialization phase via a 204 mechanism described in Section 5.1. A PCE can initiate SFPs only for 205 PCCs that advertised this capability and a PCC will follow the 206 procedures described in this document only on sessions where the PCE 207 advertised this capability. . 209 As per section 5.1 of [I-D.ietf-pce-pce-initiated-lsp], the PCE sends 210 a Path Computation LSP Initiate Request (PCInitiate) message to the 211 PCC to instantiate or delete a LSP. This document makes no change to 212 the PCInitiate message format but extends LSP objects described in 213 Section 5.2. 215 4.1. SFP Instantiation 217 The Instantiation operation of a SFP is the same as defined in 218 section 5.3[I-D.ietf-pce-pce-initiated-lsp]. Rules of processing and 219 error codes remain unchanged. 221 4.2. SFP Withdrawal 223 The withdrawal operation of a SFP is the same as defined in section 224 5.4 of [I-D.ietf-pce-pce-initiated-lsp] : the PCE sends an LSP 225 Initiate Message with an LSP object carrying the PLSP-ID of the SFP 226 to be removed and an SRP object with the R flag set (LSP-REMOVE as 227 per section 5.2 of [I-D.ietf-pce-pce-initiated-lsp]). Rules of 228 processing and error codes remain unchanged. 230 4.3. SFP Delegation and Cleanup 232 SFP delegation and cleanup operations are similar to those defined in 233 section 6 of [I-D.ietf-pce-pce-initiated-lsp]. Rules of processing 234 and error codes remains unchanged. 236 4.4. SFP State Synchronization 238 State Synchronization operations described in Section 5.4 of 239 [I-D.ietf-pce-stateful-pce]can be applied for SFP state maintenance 240 as well. 242 4.5. SFP Update and Report 244 A PCE can send an SFP Update request to a PCC to update one or more 245 attributes of an SFP and to re-signal the SFP with the updated 246 attributes. A PCC can send an SFP state report to a PCE, and which 247 contains the SFP State information. The mechanism is described in 248 [I-D.ietf-pce-stateful-pce] and can be applied for SFPs as well. 250 5. Object Formats 252 5.1. The OPEN Object 254 This document defines a new optional TLV for use in the OPEN Object 255 to indicate the PCEP speaker's Service function Chaining capability. 257 The SFC-PCE-CAPABILITY TLV is an optional TLV for use in the OPEN 258 Object to advertise the SFC capability during the PCEP session. The 259 format of the SFC-PCE-CAPABILITY TLV is shown in the 260 followingFigure 2 : 262 0 1 2 3 263 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 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 | Type=TBD | length=4 | 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 | Reserved | Flags | 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 SFC-PCE-CAPABILITY TLV Format 272 The code point for the TLV type is to be defined by IANA. The TLV 273 length is 4 octets. 275 The value is TBD. 277 As per [I-D.ietf-pce-stateful-pce], a PCEP speaker advertises the 278 capability of instantiating PCE-initiated LSPs via the Stateful PCE 279 Capability TLV (LSP-INSTANTIATION-CAPABILITY bit) conveyed in an Open 280 message. The inclusion of the SFC-PCE-CAPABILITY TLV in an OPEN 281 object indicates that the sender is SFC-capable. Both mechanisms 282 indicate the SFP instantiation capability of the PCEP speaker. 284 5.2. The LSP Object 286 The LSP object is defined in [I-D.ietf-pce-pce-initiated-lsp] and 287 included here for reference (Figure 3). 289 0 1 2 3 290 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 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 | PLSP-ID | Flags |F|C| O|A|R|S|D| 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 // TLVs // 295 | | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 LSP Object Format 300 A new flag, called the SFC (F) flag, is introduced. The F Flag set 301 to 1 indicates that this LSP is actually an SFP. The C flag will 302 also be set to indicate it was created via a PCInitiate message. 304 5.2.1. SFP Identifiers TLV 306 The SFP Identifiers TLV MUST be included in the LSP object for 307 Service Function Paths (SFP). 309 The format and operations are TBD. 311 6. Backward Compatibility 313 The SFP instantiation capability PCEP protocol extensions described 314 in this document MUST NOT be used if PCCs or the PCE did not 315 advertise its SFP instantiation stateful capability, as per 316 Section 5.1. If this is not the case and stateful operations on SFPs 317 are attempted, then a PCErr with error-type 19 (Invalid Operation) 318 and error-value TBD needs to be generated. 320 [Editor Note: more information on exact error value is needed] 322 7. Relationship to SR 324 Segment Routing (SR) technology leverages the source routing and 325 tunneling paradigms where a source node can choose a path without 326 relying on hop-by-hop signaling. A stateful PCE can be used for 327 computing one or more SR-TE paths taking into account various 328 constraints and objective functions. Once a path is chosen, the 329 stateful PCE can instantiate an SR-TE path on a PCC using PCEP 330 extensions specified in [I-D.sivabalan-pce-segment-routing]. 332 The SFP instantiation mechanism described in this document is not 333 tightly coupled to any SFP signaling mechanism. Thus, SR-based SFP 334 can also utilize the mechanism described here and does not need any 335 other specific protocol extensions. 337 8. Security Considerations 339 The security considerations described in [RFC5440] and 340 [I-D.ietf-pce-pce-initiated-lsp] are applicable to this 341 specification. No additional security measure is required. 343 9. IANA Considerations 345 TBD 347 10. References 349 10.1. Normative References 351 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 352 Requirement Levels", BCP 14, RFC 2119, March 1997. 354 [I-D.ietf-pce-stateful-pce] 355 Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP 356 Extensions for Stateful PCE", draft-ietf-pce-stateful- 357 pce-09 (work in progress), June 2014. 359 [I-D.ietf-pce-pce-initiated-lsp] 360 Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP 361 Extensions for PCE-initiated LSP Setup in a Stateful PCE 362 Model", draft-ietf-pce-pce-initiated-lsp-01 (work in 363 progress), June 2014. 365 10.2. Informative References 367 [RFC2753] Yavatkar, R., Pendarakis, D., and R. Guerin, "A Framework 368 for Policy-based Admission Control", RFC 2753, January 369 2000. 371 [RFC5394] Bryskin, I., Papadimitriou, D., Berger, L., and J. Ash, 372 "Policy-Enabled Path Computation Framework", RFC 5394, 373 December 2008. 375 [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element 376 (PCE) Communication Protocol (PCEP)", RFC 5440, March 377 2009. 379 [I-D.ietf-sfc-architecture] 380 Halpern, J. and C. Pignataro, "Service Function Chaining 381 (SFC) Architecture", draft-ietf-sfc-architecture-01 (work 382 in progress), September 2014. 384 [I-D.ww-sfc-control-plane] 385 Li, H., Wu, Q., Huang, O., Boucadair, M., Jacquenet, C., 386 and W. Haeffner, "Service Function Chain Control Plane 387 Framework", draft-ww-sfc-control-plane-02 (work in 388 progress), July 2014. 390 [I-D.sivabalan-pce-segment-routing] 391 Sivabalan, S., Medved, J., Filsfils, C., Crabbe, E., 392 Raszuk, R., Lopez, V., and J. Tantsura, "PCEP Extensions 393 for Segment Routing", draft-sivabalan-pce-segment- 394 routing-03 (work in progress), July 2014. 396 Authors' Addresses 398 Qin Wu 399 Huawei 400 101 Software Avenue, Yuhua District 401 Nanjing, Jiangsu 210012 402 China 404 EMail: sunseawq@huawei.com 406 Dhruv Dhody 407 Huawei 408 Leela Palace 409 Bangalore, Karnataka 560008 410 INDIA 412 EMail: dhruv.ietf@gmail.com 414 Mohamed Boucadair 415 France Telecom 416 Rennes 35000 417 France 419 EMail: mohamed.boucadair@orange.com 421 Christian Jacquenet 422 France Telecom 423 Rennes 35000 424 France 426 EMail: christian.jacquenet@orange.com 427 Jeff Tantsura 428 Ericsson 429 300 Holger Way 430 San Jose, CA 95134 431 US 433 EMail: Jeff.Tantsura@ericsson.com