idnits 2.17.00 (12 Aug 2021) /tmp/idnits2562/draft-wu-pce-traffic-steering-sfc-08.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 7, 2016) is 2266 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 419, 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: A later version (-08) exists of draft-ietf-sfc-control-plane-03 == Outdated reference: draft-ietf-pce-segment-routing has been published as RFC 8664 == Outdated reference: draft-ietf-sfc-nsh has been published as RFC 8300 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: September 8, 2016 M. Boucadair 6 C. Jacquenet 7 Orange 8 J. Tantsura 9 Ericsson 10 March 7, 2016 12 PCEP Extensions for Service Function Chaining (SFC) 13 draft-wu-pce-traffic-steering-sfc-08 15 Abstract 17 This document provides an overview of the usage of Path Computation 18 Element (PCE) to dynamically structure service function chains. 19 Service Function Chaining (SFC) is a technique that is meant to 20 facilitate the dynamic enforcement of differentiated traffic 21 forwarding policies within a domain. Service function chains are 22 composed of an ordered set of elementary Service Functions (such as 23 firewalls, load balancers) that need to be invoked according to the 24 design of a given service. Corresponding traffic is thus forwarded 25 along a Service Function Path (SFP) that can be computed by means of 26 PCE. 28 This document specifies extensions to the Path Computation Element 29 Protocol (PCEP) that allow a stateful PCE to compute and instantiate 30 Service Function Paths. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on September 8, 2016. 49 Copyright Notice 51 Copyright (c) 2016 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 2. Conventions used in this document . . . . . . . . . . . . . . 3 68 3. Service Function Paths and PCE . . . . . . . . . . . . . . . 4 69 4. Overview of PCEP Operation in SFC-Enabled Networks . . . . . 5 70 4.1. SFP Instantiation . . . . . . . . . . . . . . . . . . . . 6 71 4.2. SFP Withdrawal . . . . . . . . . . . . . . . . . . . . . 6 72 4.3. SFP Delegation and Cleanup . . . . . . . . . . . . . . . 6 73 4.4. SFP State Synchronization . . . . . . . . . . . . . . . . 6 74 4.5. SFP Update and Report . . . . . . . . . . . . . . . . . . 6 75 5. Object Formats . . . . . . . . . . . . . . . . . . . . . . . 7 76 5.1. The OPEN Object . . . . . . . . . . . . . . . . . . . . . 7 77 5.2. The LSP Object . . . . . . . . . . . . . . . . . . . . . 7 78 5.2.1. SFP Identifiers TLV . . . . . . . . . . . . . . . . . 8 79 6. Backward Compatibility . . . . . . . . . . . . . . . . . . . 9 80 7. SFP Signaling and Forwarding Considerations . . . . . . . . . 9 81 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 82 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 83 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 84 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 85 11.1. Normative References . . . . . . . . . . . . . . . . . . 10 86 11.2. Informative References . . . . . . . . . . . . . . . . . 10 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 89 1. Introduction 91 Service Function Chaining (SFC) enables the creation of composite 92 services that consist of an ordered set of Service Functions (SF) 93 that must be applied to packets and/or frames and/or flows selected 94 as a result of service-inferred traffic classification as described 95 in [RFC7665]. A Service Function Path (SFP) is a path along which 96 traffic that is bound to a specific service function chain will be 97 forwarded. Packets typically follow a Service Function Path from a 98 classifier through the Service Functions (SF) that need to be invoked 99 according to the SFC instructions. Forwarding decisions are made by 100 Service Function Forwarders (SFF) according to such instructions. 102 [RFC5440] describes the Path Computation Element Protocol (PCEP) as 103 the protocol used by a Path Computation Client (PCC) and a Path 104 Control Element (PCE) to exchange information, thereby enabling the 105 computation of Multiprotocol Label Switching (MPLS) for Traffic 106 Engineering Label Switched Path (TE LSP), in particular. 108 [I-D.ietf-pce-stateful-pce] specifies extensions to PCEP to enable a 109 stateful control of MPLS TE LSPs. [I-D.ietf-pce-pce-initiated-lsp] 110 provides the extensions needed for stateful PCE-initiated LSP 111 instantiation. 113 This document specifies PCEP extensions that allow a stateful PCE to 114 compute and instantiate traffic-engineered Service Function Paths 115 (SFP). 117 2. Conventions used in this document 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 121 document are to be interpreted as described in RFC2119 [RFC2119]. 123 This document makes use of these acronyms: 125 PCC: Path Computation Client. 127 PCE: Path Computation Element. 129 PCEP: Path Computation Element Protocol. 131 PDP: Policy Decision Point. 133 SF: Service Function. 135 SFC: Service Function Chain. 137 SFP: Service Function Path. 139 RSP: Rendered Service Path. 141 SFF: Service Function Forwarder. 143 UNI: User-Network Interface. 145 3. Service Function Paths and PCE 147 Service function chains are constructed as a sequence of SFs, where a 148 SF can be virtualized or embedded in a physical network element. One 149 or several SFs may be supported by the same physical network element. 150 A SFC creates an abstracted view of a service and specifies the set 151 of required SFs as well as the order in which they must be executed. 153 When an SFC is created, it is necessary to select the specific 154 instances of SFs that will be used. A service function path for that 155 SFC will then be established (notion of rendered service path) or can 156 be precomputed, based upon the sequence of SFs that need to be 157 invoked by the corresponding traffic, i.e., the traffic that is bound 158 to the corresponding SFC. Note that a SF instance can be serviced by 159 one or multiple SFFs. One or multiple SF instances can be serviced 160 by one SFF. Thus, the instantiation of an SFC results in the 161 establishment of a Service Function Path, either in a hop-by-hop 162 fashion, or by means of traffic-engineering capabilities. In the 163 latter case, the SFP is precomputed, i.e., an SFP is an instantiation 164 of the defined SFC as described in [RFC7665]. 166 The computation, the selection, and the establishment of a traffic- 167 engineered SFP can rely upon a set of (service-specific) policies 168 (forwarding and routing, QoS, security, etc., or a combination 169 thereof). Stateful PCE with appropriate SFC-aware PCEP extensions 170 can be used to compute traffic-engineered SFPs. 172 SFC Control Element 173 +------------------------+ 174 | stateful PCE | 175 | +-------+ +-------+ | 176 | |Policy | | TE-DB | | 177 | +-------+ +-------+ | 178 +----------| +-------------+ | 179 |SFP | |LSP-DB/SFP-DB| | 180 |Instan- | +-------------+ | 181 |tiation +------------------------+ 182 | +-----+ +-----+ +-----+ 183 | |SF-1 | |SF-2 | |SF-3 | 184 | | | | | | | 185 | +---+-+ +-+---+ +--+--+ 186 | | | | 187 | ++-----++ +----+--+ 188 V | | | | 189 +-----+ Signaling | | Signaling | | Signaling 190 | SFC |----------->| SFF-1 | --------->| SFF-2 |-----------> 191 Classifier | | | | 192 | | | | | | 193 +-----+ +-------+ +-------+ 195 Figure 1: PCE-based SFP instantiation 197 The SFC Control Element [I-D.ietf-sfc-control-plane] is responsible 198 for defining service instructions to bind a flow to a service 199 function chain and forward such flow along the corresponding SFP. It 200 is also responsible for defining the appropriate policies (traffic 201 classification, forwarding and routing, etc.) that will be enforced 202 by SFC Classifiers and SFF Nodes as described in [RFC7665]. The SFC 203 Control Element can be seen as a Policy Decision Point (PDP, 204 [RFC5394]). Such PDP can then operate a stateful PCE to compute, 205 select and establish Service Function Paths. The PCE may be co- 206 located with the SFC Control element or enabled in an external 207 entity. 209 4. Overview of PCEP Operation in SFC-Enabled Networks 211 A PCEP speaker indicates its ability to support PCE-computed SFP 212 paths during the PCEP Initialization phase via a mechanism described 213 in Section 5.1. A PCE may initiate SFPs only for PCCs that 214 advertised this capability; a PCC follows the procedures described in 215 this document only for sessions where the PCE advertised this 216 capability. 218 As per Section 5.1 of [I-D.ietf-pce-pce-initiated-lsp], the PCE sends 219 a Path Computation LSP Initiate Request (PCInitiate) message to the 220 PCC to instantiate or delete a LSP. The Explicit Route Object (ERO) 221 is used to encode either a full sequence of SF instances or a 222 specific sequence of SFFs and SFs to establish an SFP. If the said 223 SFFs and SFs are identified with an IP address, the IP sub-object can 224 be used as a SF/SFF identification means. This document makes no 225 change to the PCInitiate message format but extends LSP objects 226 described in Section 5.2. 228 Editor's note: In case a PCE-Initiated signaling mechanism is used to 229 set up the service function path, then does the classifier / PCE- 230 Initiated signaling protocol need to understand if the IP address is 231 for SFF or SF or the signaling protocol is only used to signal IP 232 addresses for SFs? 234 4.1. SFP Instantiation 236 The instantiation of a SFP is the same as defined in Section 5.3 of 237 [I-D.ietf-pce-pce-initiated-lsp]. Rules for processing and error 238 codes remain unchanged. 240 4.2. SFP Withdrawal 242 The withdrawal of an SFP is the same as defined in Section 5.4 of 243 [I-D.ietf-pce-pce-initiated-lsp]: the PCE sends an LSP Initiate 244 Message with an LSP object carrying the PLSP-ID of the SFP and the 245 SFP Identifier to be removed, as well as an SRP object with the R 246 flag set (LSP-REMOVE as per Section 5.2 of 247 [I-D.ietf-pce-pce-initiated-lsp]). Rules for processing and error 248 codes remain unchanged. 250 4.3. SFP Delegation and Cleanup 252 SFP delegation and cleanup operations are similar to those defined in 253 Section 6 of [I-D.ietf-pce-pce-initiated-lsp]. Rules for processing 254 and error codes remain unchanged. 256 4.4. SFP State Synchronization 258 State Synchronization operations described in Section 5.4 of 259 [I-D.ietf-pce-stateful-pce] can be applied to SFP state maintenance 260 as well. 262 4.5. SFP Update and Report 264 A PCE can send an SFP Update request to a PCC to update one or more 265 attributes of an SFP and to re-signal the SFP with the updated 266 attributes. A PCC can send an SFP state report to a PCE, and which 267 contains the SFP State information. The mechanism is described in 268 [I-D.ietf-pce-stateful-pce] and can be applied to SFPs as well. 270 5. Object Formats 272 5.1. The OPEN Object 274 The optional TLV shown in Figure 2 is defined for use in the OPEN 275 Object to indicate the PCEP speaker's Service Function Chaining 276 capability. 278 The SFC-PCE-CAPABILITY TLV is an optional TLV to be carried in the 279 OPEN Object to advertise the SFC capability during the PCEP session. 281 0 1 2 3 282 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 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 | Type=TBD | length=4 | 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 | Reserved | Flags | 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 SFC-PCE-CAPABILITY TLV Format 291 The code point for the TLV type is to be defined by IANA (see 292 Section 9). The TLV length is 4 octets. 294 As per [I-D.ietf-pce-stateful-pce], a PCEP speaker advertises the 295 capability of instantiating PCE-initiated LSPs via the Stateful PCE 296 Capability TLV (LSP-INSTANTIATION-CAPABILITY bit) carried in an Open 297 message. The inclusion of the SFC-PCE-CAPABILITY TLV in an OPEN 298 object indicates that the sender is SFC-capable. Both mechanisms 299 indicate the SFP instantiation capability of the PCEP speaker. 301 5.2. The LSP Object 303 The LSP object is defined in [I-D.ietf-pce-pce-initiated-lsp] and 304 included here for reference (Figure 3). 306 0 1 2 3 307 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 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 | PLSP-ID | Flags |F|C| O|A|R|S|D| 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 // TLVs // 312 | | 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 LSP Object Format 317 A new flag, called the SFC flag (F-bit), is introduced. The F-bit 318 set to "1" indicates that this LSP is actually an SFP. The C flag 319 will also be set to indicate it was created via a PCInitiate message. 321 5.2.1. SFP Identifiers TLV 323 The SFP Identifiers TLV MUST be included in the LSP object for SFPs. 324 The SFP Identifier TLV is used by the classifier to select the SFP 325 along which some traffic will be forwarded, according to the traffic 326 classification rules applied by the classifier [RFC7665]. The SFP 327 Identifier is part of the SFC metadata carried in packets and is used 328 by the SFF to invoke service functions and identify the next SFF. 330 The format of the SFP Identifier TLV is shown in Figure 4. 332 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 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 | Service Path ID | Service Index | 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 Service Path ID (SPI): 24 bits 338 Service Index (SI): 8 bits 340 Figure 4 342 SPI: identifies a service path. The same ID is used by the 343 participating nodes for path setup/selection. An administrator can 344 use the SPI for reporting and troubleshooting packets along a 345 specific path. SPI along with PLSP-ID is used by PCEP to identify 346 the Service Path. 348 SI: provides location within the service path. 350 6. Backward Compatibility 352 The SFP instantiation capability defined as a PCEP extension and 353 documented in this draft MUST NOT be used if PCCs or the PCE did not 354 advertise their stateful SFP instantiation capability,Section 5.1. 355 If this is not the case and stateful operations on SFPs are 356 attempted, then a PCErr message with error-type 19 (Invalid 357 Operation) and error-value TBD needs to be generated. 359 [Editor's note: more information on exact error value is needed] 361 7. SFP Signaling and Forwarding Considerations 363 The SFP instantiation mechanism described in this document is not 364 tightly coupled to any SFP signaling mechanism. For example, Generic 365 SFC Encapsulation [I-D.ietf-sfc-nsh] can be used together with the 366 mechanism described in this document to enable SFP forwarding. SR- 367 based approach [I-D.ietf-pce-segment-routing] can also use the 368 mechanism described here and does not need any other specific 369 protocol extensions. 371 8. Security Considerations 373 The security considerations described in [RFC5440] and 374 [I-D.ietf-pce-pce-initiated-lsp] are applicable to this 375 specification. This document does not raise any additional security 376 issue. 378 9. IANA Considerations 380 IANA is requested to allocate a new code point in the PCEP TLV Type 381 Indicators registry, as follows: 383 Value Meaning Reference 384 ------- ---------------------------- -------------- 385 TBD SFC-PCE-CAPABILITY This document 387 10. Acknowledgements 389 Many thanks to Ron Parker, Hao Wang, Dave Dolson, Jing Huang, and 390 Joel M. Halpern for the discussion in formulating the content for 391 the document. 393 11. References 394 11.1. Normative References 396 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 397 Requirement Levels", BCP 14, RFC 2119, 398 DOI 10.17487/RFC2119, March 1997, 399 . 401 [I-D.ietf-pce-stateful-pce] 402 Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP 403 Extensions for Stateful PCE", draft-ietf-pce-stateful- 404 pce-13 (work in progress), December 2015. 406 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 407 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 408 DOI 10.17487/RFC5440, March 2009, 409 . 411 [I-D.ietf-pce-pce-initiated-lsp] 412 Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP 413 Extensions for PCE-initiated LSP Setup in a Stateful PCE 414 Model", draft-ietf-pce-pce-initiated-lsp-05 (work in 415 progress), October 2015. 417 11.2. Informative References 419 [RFC2753] Yavatkar, R., Pendarakis, D., and R. Guerin, "A Framework 420 for Policy-based Admission Control", RFC 2753, 421 DOI 10.17487/RFC2753, January 2000, 422 . 424 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 425 Chaining (SFC) Architecture", RFC 7665, 426 DOI 10.17487/RFC7665, October 2015, 427 . 429 [RFC5394] Bryskin, I., Papadimitriou, D., Berger, L., and J. Ash, 430 "Policy-Enabled Path Computation Framework", RFC 5394, 431 DOI 10.17487/RFC5394, December 2008, 432 . 434 [I-D.ietf-sfc-control-plane] 435 Li, H., Wu, Q., Huang, O., Boucadair, M., Jacquenet, C., 436 Haeffner, W., Lee, S., Parker, R., Dunbar, L., Malis, A., 437 Halpern, J., Reddy, T., and P. Patil, "Service Function 438 Chaining (SFC) Control Plane Components & Requirements", 439 draft-ietf-sfc-control-plane-03 (work in progress), 440 January 2016. 442 [I-D.ietf-pce-segment-routing] 443 Sivabalan, S., Medved, J., Filsfils, C., Crabbe, E., 444 Lopez, V., Tantsura, J., Henderickx, W., and J. Hardwick, 445 "PCEP Extensions for Segment Routing", draft-ietf-pce- 446 segment-routing-06 (work in progress), August 2015. 448 [I-D.ietf-sfc-nsh] 449 Quinn, P. and U. Elzur, "Network Service Header", draft- 450 ietf-sfc-nsh-02 (work in progress), January 2016. 452 Authors' Addresses 454 Qin Wu 455 Huawei 456 101 Software Avenue, Yuhua District 457 Nanjing, Jiangsu 210012 458 China 460 EMail: bill.wu@huawei.com 462 Dhruv Dhody 463 Huawei 464 Leela Palace 465 Bangalore, Karnataka 560008 466 INDIA 468 EMail: dhruv.ietf@gmail.com 470 Mohamed Boucadair 471 Orange 472 Rennes 35000 473 France 475 EMail: mohamed.boucadair@orange.com 477 Christian Jacquenet 478 Orange 479 Rennes 480 France 482 EMail: christian.jacquenet@orange.com 483 Jeff Tantsura 484 Ericsson 485 300 Holger Way 486 San Jose, CA 95134 487 US 489 EMail: Jeff.Tantsura@ericsson.com