idnits 2.17.00 (12 Aug 2021) /tmp/idnits1538/draft-wu-pce-traffic-steering-sfc-06.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 (March 4, 2015) is 2635 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 385, but no explicit reference was found in the text == Unused Reference: 'RFC5394' is defined on line 389, 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-03 == Outdated reference: draft-ietf-pce-segment-routing has been published as RFC 8664 Summary: 0 errors (**), 0 flaws (~~), 8 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: September 5, 2015 M. Boucadair 6 C. Jacquenet 7 France Telecom 8 J. Tantsura 9 Ericsson 10 March 4, 2015 12 PCEP Extensions for traffic steering support in Service Function 13 Chaining 14 draft-wu-pce-traffic-steering-sfc-06 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 September 5, 2015. 46 Copyright Notice 48 Copyright (c) 2015 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 . . . . . . . . . . . . . . . . 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. SFP signaling and forwarding consideration . . . . . . . . . 8 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 . . . . . . . . . . . . . . . . . 9 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 85 1. Introduction 87 Service chaining enables the creation of composite services that 88 consist of an ordered set of Service Functions (SF) that must be 89 applied to packets and/or frames selected as a result of 90 classification as described in [I-D.ietf-sfc-architecture] and 91 referred to as Service Function Chain (SFC). A Service Function Path 92 (SFP) is the instantiation of a SFC in the network. Packets follow a 93 Service Function Path from a classifier through the requisite Service 94 Functions (SF). 96 [RFC5440] describes the Path Computation Element Protocol (PCEP) as 97 the communication between a Path Computation Client (PCC) and a Path 98 Control Element (PCE), or between PCE and PCE, enabling computation 99 of Multiprotocol Label Switching (MPLS) for Traffic Engineering Label 100 Switched Path (TE LSP). 102 [I-D.ietf-pce-stateful-pce] specifies extensions to PCEP to enable 103 stateful control of MPLS TE LSPs. [I-D.ietf-pce-pce-initiated-lsp] 104 provides the fundamental extensions needed for stateful PCE-initiated 105 LSP instantiation. 107 This document specifies extensions to the PCEP that allow a stateful 108 PCE to compute and instantiate Service Function Paths (SFP). 110 2. Conventions used in this document 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 114 document are to be interpreted as described in RFC2119 [RFC2119]. 116 The following terminologies are used in this document: 118 PCC: Path Computation Client. 120 PCE: Path Computation Element. 122 PCEP: Path Computation Element Protocol. 124 PDP: Policy Decision Point. 126 SF: Service Function. 128 SFC: Service Function Chain. 130 SFP: Service Function Path. 132 SFF: Service Forwarder Function. 134 UNI: User-Network Interface. 136 3. Service Function Paths and PCE 138 Services are constructed as a sequence of SFs that represent an SFC, 139 where a SF can be a virtual instance or be embedded in a physical 140 network element, and one or more SFs may be supported by the same 141 physical network element. A SFC creates an abstracted view of a 142 service and specifies the set of required SFs as well as the order in 143 which they must be executed. 145 When an SFC is instantiated into the network it is necessary to 146 select the specific instances of SFs that will be used, and to create 147 the service topology for that SFC using SF network locators. Thus, 148 instantiation of the SFC results in the creation of a Service 149 Function Path (SFP) and is used for forwarding packets through the 150 SFC. In other words, an SFP is the instantiation of the defined SFC 151 as described in [I-D.ietf-sfc-architecture]. 153 The selection of SFP can be based on a set of policy attributes 154 (forwarding and routing, QoS, security, etc., or a combination 155 thereof), ranging from simple to more elaborate selection criteria 156 and the use of stateful PCE with extensions to PCEP are one such way 157 to achieve this. 159 Stateful pce [I-D.ietf-pce-stateful-pce] specifies a set of 160 extensions to PCEP to enable stateful control of TE LSPs. 161 [I-D.ietf-pce-pce-initiated-lsp] provides the fundamental motivations 162 and extensions needed for stateful PCE-initiated LSP instantiation. 163 This document specifies extensions that allow a stateful PCE to 164 compute and instantiate Service Function Paths (SFP) via PCEP. 166 +------------------------+ 167 | stateful PCE | 168 | +-------+ +-------+ | 169 | |Policy | | TE-DB | | +-------+ 170 | +-------+ +-------+ | | SFC | 171 +----------| +-------------+ |<---|control| 172 |SFP | |LSP-DB/SFP-DB| | | plane | 173 |Instan- | +-------------+ | +-------+ 174 |tiation +------------------------+ 175 | +-----+ +-----+ +-----+ 176 | |SF-1 | |SF-2 | |SF-3 | 177 | | | | | | | 178 | +---+-+ +-+---+ +--+--+ 179 | | | | 180 | ++-----++ +----+--+ 181 V | | | | 182 +-----+ Signaling | | Signaling | | Signaling 183 | SF |----------->| SFF-1 | --------->| SFF-2 |-----------> 184 Classifier | | | | 185 |Node | | | | | 186 +-----+ +-------+ +-------+ 188 Figure 1: PCE based SFP instantiation 190 SFC Control plane components are responsible for maintaining SFC 191 Policy Tables and enforcing appropriate policies in SF Classifier and 192 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). The SFP Identifier TLV is used by the 308 classifier to enable SFP selection for the traffic,i.e.,direct 309 traffic to specific SFP[I-D.ietf-sfc-architecture]. The SFP 310 Identifier carried in the SFC encapsulation can be further used by 311 SFF to select service functions and next SFF,e.g., enable a packet 312 that repeatedly arrives at the same SFF to get the correct services 313 provided each time it arrives, and to go to the correct next SFF each 314 time it arrives. 316 The format of SFP Identifier TLV is shown in the following figure. 318 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 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 | Service Path ID | Service Index | 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 Service path ID (SPI): 24 bits 324 Service index (SI): 8 bits 326 SPI: identifies a service path. The same ID is used by the 327 participating nodes for path setup/selection. An administrator can 328 use the SPI for reporting and troubleshooting packets along a 329 specific path. SPI along with PLSP-ID is used in PCEP to identify 330 the Service Path. 332 SI: provides location within the service path. 334 6. Backward Compatibility 336 The SFP instantiation capability PCEP protocol extensions described 337 in this document MUST NOT be used if PCCs or the PCE did not 338 advertise its SFP instantiation stateful capability, as per 339 Section 5.1. If this is not the case and stateful operations on SFPs 340 are attempted, then a PCErr with error-type 19 (Invalid Operation) 341 and error-value TBD needs to be generated. 343 [Editor Note: more information on exact error value is needed] 345 7. SFP signaling and forwarding consideration 347 The SFP instantiation mechanism described in this document is not 348 tightly coupled to any SFP signaling mechanism. For example,SR-based 349 approach [I-D.ietf-pce-segment-routing] can utilize the mechanism 350 described here and does not need any other specific protocol 351 extensions. Generic SFC Encapsulation [I-D.quinn-sfc-nsh] can also 352 be used together with the mechanism described here to enable SFP 353 forwarding. 355 8. Security Considerations 357 The security considerations described in [RFC5440] and 358 [I-D.ietf-pce-pce-initiated-lsp] are applicable to this 359 specification. No additional security measure is required. 361 9. IANA Considerations 363 TBD 365 10. References 367 10.1. Normative References 369 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 370 Requirement Levels", BCP 14, RFC 2119, March 1997. 372 [I-D.ietf-pce-stateful-pce] 373 Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP 374 Extensions for Stateful PCE", draft-ietf-pce-stateful- 375 pce-10 (work in progress), October 2014. 377 [I-D.ietf-pce-pce-initiated-lsp] 378 Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP 379 Extensions for PCE-initiated LSP Setup in a Stateful PCE 380 Model", draft-ietf-pce-pce-initiated-lsp-02 (work in 381 progress), October 2014. 383 10.2. Informative References 385 [RFC2753] Yavatkar, R., Pendarakis, D., and R. Guerin, "A Framework 386 for Policy-based Admission Control", RFC 2753, January 387 2000. 389 [RFC5394] Bryskin, I., Papadimitriou, D., Berger, L., and J. Ash, 390 "Policy-Enabled Path Computation Framework", RFC 5394, 391 December 2008. 393 [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element 394 (PCE) Communication Protocol (PCEP)", RFC 5440, March 395 2009. 397 [I-D.ietf-sfc-architecture] 398 Halpern, J. and C. Pignataro, "Service Function Chaining 399 (SFC) Architecture", draft-ietf-sfc-architecture-05 (work 400 in progress), February 2015. 402 [I-D.ww-sfc-control-plane] 403 Li, H., Wu, Q., Boucadair, M., Jacquenet, C., and W. 404 Haeffner, "Service Function Chaining (SFC) Control Plane 405 Achitecture", draft-ww-sfc-control-plane-03 (work in 406 progress), September 2014. 408 [I-D.ietf-pce-segment-routing] 409 Sivabalan, S., Medved, J., Filsfils, C., Crabbe, E., 410 Raszuk, R., Lopez, V., and J. Tantsura, "PCEP Extensions 411 for Segment Routing", draft-ietf-pce-segment-routing-00 412 (work in progress), October 2014. 414 [I-D.quinn-sfc-nsh] 415 Quinn, P., Guichard, J., Surendra, S., Smith, M., 416 Henderickx, W., Nadeau, T., Agarwal, P., Manur, R., 417 Chauhan, A., Halpern, J., Majee, S., Elzur, U., Melman, 418 D., Garg, P., McConnell, B., Wright, C., and K. Kevin, 419 "Network Service Header", draft-quinn-sfc-nsh-07 (work in 420 progress), February 2015. 422 Authors' Addresses 424 Qin Wu 425 Huawei 426 101 Software Avenue, Yuhua District 427 Nanjing, Jiangsu 210012 428 China 430 EMail: sunseawq@huawei.com 432 Dhruv Dhody 433 Huawei 434 Leela Palace 435 Bangalore, Karnataka 560008 436 INDIA 438 EMail: dhruv.ietf@gmail.com 440 Mohamed Boucadair 441 France Telecom 442 Rennes 35000 443 France 445 EMail: mohamed.boucadair@orange.com 447 Christian Jacquenet 448 France Telecom 449 Rennes 35000 450 France 452 EMail: christian.jacquenet@orange.com 454 Jeff Tantsura 455 Ericsson 456 300 Holger Way 457 San Jose, CA 95134 458 US 460 EMail: Jeff.Tantsura@ericsson.com