idnits 2.17.1 draft-xu-pce-sr-sfc-04.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 : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 5 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: 'L' Flag: indicates whether the subobject represents a loose-hop in the explicit route [RFC3209]. If this flag is unset, a PCC MUST not overwrite the SID value present in the SR-SFC-ERO subobject. Otherwise, a PCC MAY expand or replace one or more SID value(s) in the received SR-SFC-ERO based on its local policy. -- The document date (December 29, 2016) is 2673 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) == Missing Reference: 'RFC3209' is mentioned on line 344, but not defined == Missing Reference: 'RFC5462' is mentioned on line 371, but not defined == Unused Reference: 'I-D.ietf-spring-segment-routing-mpls' is defined on line 494, but no explicit reference was found in the text == Outdated reference: A later version (-21) exists of draft-ietf-pce-stateful-pce-18 == Outdated reference: A later version (-10) exists of draft-ietf-pce-lsp-setup-type-03 == Outdated reference: A later version (-16) exists of draft-ietf-pce-segment-routing-08 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-mpls-05 == Outdated reference: A later version (-03) exists of draft-xu-mpls-service-chaining-00 Summary: 1 error (**), 0 flaws (~~), 10 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE Working Group X. Xu 3 Internet-Draft Huawei 4 Intended status: Standards Track J. You 5 Expires: July 2, 2017 6 S. Sivabalan 7 Cisco 8 H. Shah 9 Ciena 10 L. Contreras 11 Telefonica I+D 12 D. Bernier 13 Bell Canada 14 December 29, 2016 16 PCEP Extensions for MPLS Source Routing-based SFC 17 draft-xu-pce-sr-sfc-04 19 Abstract 21 Source Packet Routing in Networking (SPRING) WG is developing an MPLS 22 source routing mechanism. This MPLS source routing mechanism can be 23 leveraged to realize the service path layer functionality of the 24 service function chaining (i.e., steering the selected traffic 25 through a particular service function path) by encoding the service 26 function path information as an MPLS label stack. This document 27 describes extensions to the Path Computation Element Protocol (PCEP) 28 that allow a PCE to compute and instantiate service function paths in 29 the MPLS source routing based service function chaining context. The 30 extensions specified in this document are applicable to both the 31 stateless PCE model and the stateful PCE model. 33 Requirements Language 35 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 36 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 37 document are to be interpreted as described in RFC 2119 [RFC2119]. 39 Status of This Memo 41 This Internet-Draft is submitted in full conformance with the 42 provisions of BCP 78 and BCP 79. 44 Internet-Drafts are working documents of the Internet Engineering 45 Task Force (IETF). Note that other groups may also distribute 46 working documents as Internet-Drafts. The list of current Internet- 47 Drafts is at http://datatracker.ietf.org/drafts/current/. 49 Internet-Drafts are draft documents valid for a maximum of six months 50 and may be updated, replaced, or obsoleted by other documents at any 51 time. It is inappropriate to use Internet-Drafts as reference 52 material or to cite them other than as "work in progress." 54 This Internet-Draft will expire on July 2, 2017. 56 Copyright Notice 58 Copyright (c) 2016 IETF Trust and the persons identified as the 59 document authors. All rights reserved. 61 This document is subject to BCP 78 and the IETF Trust's Legal 62 Provisions Relating to IETF Documents 63 (http://trustee.ietf.org/license-info) in effect on the date of 64 publication of this document. Please review these documents 65 carefully, as they describe your rights and restrictions with respect 66 to this document. Code Components extracted from this document must 67 include Simplified BSD License text as described in Section 4.e of 68 the Trust Legal Provisions and are provided without warranty as 69 described in the Simplified BSD License. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 74 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 75 3. PCEP Message Extensions for MPLS Source Routing-based SFC . . 4 76 3.1. PCReq Message . . . . . . . . . . . . . . . . . . . . . . 4 77 3.2. PCRep Message . . . . . . . . . . . . . . . . . . . . . . 4 78 3.3. PCUpd Message . . . . . . . . . . . . . . . . . . . . . . 5 79 3.4. PCRpt Message . . . . . . . . . . . . . . . . . . . . . . 5 80 4. Object Formats . . . . . . . . . . . . . . . . . . . . . . . 6 81 4.1. OPEN Object . . . . . . . . . . . . . . . . . . . . . . . 6 82 4.1.1. SR-SFC PCE Capability TLV . . . . . . . . . . . . . . 6 83 4.2. RP/SRP Object . . . . . . . . . . . . . . . . . . . . . . 6 84 4.3. Include Route Object . . . . . . . . . . . . . . . . . . 7 85 4.4. SR-SFC-ERO Object . . . . . . . . . . . . . . . . . . . . 7 86 4.4.1. SR-SFC-ERO Subobject . . . . . . . . . . . . . . . . 7 87 4.4.2. NSI Associated with SID . . . . . . . . . . . . . . . 9 88 4.4.3. SR-SFC-ERO Processing . . . . . . . . . . . . . . . . 9 89 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 90 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 91 6.1. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . 9 92 6.2. PCEP-Error Object . . . . . . . . . . . . . . . . . . . . 9 93 6.3. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 10 94 6.4. New Path Setup Type . . . . . . . . . . . . . . . . . . . 10 95 6.5. New IRO Sub-object Type . . . . . . . . . . . . . . . . . 10 96 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 97 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 98 8.1. Normative References . . . . . . . . . . . . . . . . . . 10 99 8.2. Informative References . . . . . . . . . . . . . . . . . 11 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 102 1. Introduction 104 Service Function Chaining [RFC7665] provides a flexible way to 105 construct services. When applying a particular Service Function 106 Chain (SFC) to the traffic classified by the Classifier, the traffic 107 needs to be steered through an ordered set of Service Function 108 Forwarders (SFF) and Service Functions (SF) in the network. This 109 ordered set of SFFs and SFs in the network, referred to as a Service 110 Function Path (SFP), is an instantiation of the SFC in the network. 111 For example, as shown in Figure 1, an SFP corresponding to the SFC of 112 {SF1, SF3} can be expressed as {SFF1, SF1, SFF2, SF3}. 114 +-------+ 115 +--+ PCE | 116 | +-------+ 117 | 118 | 119 | 120 | +-------------------------------------------------+ 121 | | MPLS-SR Netowrks | 122 | | +-----+ +-----+ | 123 | | | SF1 | | SF2 | | 124 | | +--+--+ +--+--+ | 125 | | | | | 126 | | ^ | | | 127 | | (2)| +---+ +---+ | 128 | | +--+ | | | 129 ++---------+ | | | +--------------+ | 130 | +----+| V | | | +-----+ | | 131 | |PCC || (1) +---+-+----+ (3) | | SF3 | | | 132 --> |SFC +----+|----> | SFF1 |---->| +-----+ |----> 133 ----+Classifier+------+ +-----+ SFF2 +-------- 134 +----------+ +----------+ +--------------+ | 135 | | 136 +-------------------------------------------------+ 138 Figure 1: PCE-based Service Function Chaining in MPLS-SR Network 140 Source Packet Routing in Networking (SPRING) WG is developing an MPLS 141 source routing mechanism called MPLS Segment Routing (SR). This MPLS 142 SR mechanism can be leveraged to realize the service path layer 143 functionality of the service function chaining (i.e., steering the 144 selected traffic through a particular service function path) by 145 encoding the service function path information as an MPLS label 146 stack, as described in [I-D.xu-mpls-service-chaining]. 148 This document describes extensions to the Path Computation Element 149 Protocol (PCEP) that allow a PCE to compute and instantiate service 150 function paths in the MPLS source routing based service function 151 chaining context. More specifically, the PCC provides an ordered 152 list of SF IDs to the PCE and indicates to the PCE that what type SFs 153 and paths are requested (e.g., an SFP, or a compact SFP, or an SR- 154 specific SFP, or a compact SR-specific SFP) through the path 155 computation request message, and then the PCE responds with a 156 corresponding path through the path computation response message. 157 The extensions specified in this document are applicable to both the 158 stateless PCE model [RFC5440] and the stateful PCE model 159 [I-D.ietf-pce-stateful-pce]. 161 2. Terminology 163 This memo makes use of the terms defined in [RFC5440], 164 [I-D.ietf-pce-segment-routing] and [I-D.xu-mpls-service-chaining]. 165 In addition, this memo defines the following two additional terms: 167 SR-specific SFP: An ordered list of node SIDs (representing SFFs) 168 and Service Function SIDs. 170 Compact SR-specific SFP: An ordered list of node SIDs 171 (representing SFFs). 173 3. PCEP Message Extensions for MPLS Source Routing-based SFC 175 3.1. PCReq Message 177 This document does not specify any changes to the PCReq message 178 format. This document requires the PATH-SETUP-TYPE TLV 179 [I-D.ietf-pce-lsp-setup-type] to be carried in the RP Object in order 180 for a PCC to request a particular type of path. Four new Path Setup 181 Types need to be defined for MPLS source routing-based SFC (see 182 Section 4.2). This document also requires the Include Route Object 183 (IRO) to be carried in the PCReq message in order for a PCC to 184 specify an SFC. A new IRO sub-object type needs to be defined for SF 185 (see Section 4.3). 187 3.2. PCRep Message 189 This document defines the format of the PCRep message carrying an 190 SFP. The message is sent by a PCE to a PCC in response to a 191 previously received PCReq message, where the PCC requested an SFP. 192 The format of the SFC-specific PCRep message is defined as follows: 194 ::= 195 196 Where: 197 ::=[] 198 ::= 199 [] 200 [] 201 Where: 202 ::=[] 204 The RP and NO-PATH Objects are defined in [RFC5440]. The object contains an SFP and is defined in Section 4.4. 207 3.3. PCUpd Message 209 This document defines the format of the PCUpd message carrying an SFP 210 update. The message is sent forwardly by a PCE to a PCC to update an 211 previously computed SFP. 213 The format of the PCUpd message is defined as follows: 215 ::= 216 217 Where: 218 ::=[] 219 ::= 220 Where: 221 ::=[] 223 3.4. PCRpt Message 225 PCPRpt message sent from a PCC to PCE as a respond to a PCUpd message 226 or in an unsolicited manner (e.g., during state synchronization). 228 The format of the PCUpd message is defined as follows: 230 ::= 231 232 Where: 233 ::=[] 234 ::=[] 235 Where: 236 ::=[] 238 4. Object Formats 240 4.1. OPEN Object 242 This document defines a new optional TLV for use in the OPEN Object. 244 4.1.1. SR-SFC PCE Capability TLV 246 The SR-SFC-PCE-CAPABILITY TLV is an optional TLV for use in the OPEN 247 Object to negotiate SR-SFC capability on the PCEP session. The 248 format of the SR-SFC-PCE-CAPABILITY TLV is shown in the following 249 Figure 2: 251 0 1 2 3 252 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 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 | Type=TBD | Length=4 | 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 | Reserved | Flags | MSD | 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 Figure 2: SR-SFC-PCE-CAPABILITY TLV Format 261 The code point for the TLV type is to be defined by IANA. The TLV 262 length is 4 octets. The 32-bit value is formatted as follows. The 263 "Maximum SID Depth" (1 octet) field (MSD) specifies the maximum 264 number of SIDs that a PCC is capable of imposing on a packet. The 265 "Flags" (1 octet) and "Reserved" (2 octets) fields are currently 266 unused, and MUST be set to zero and ignored on receipt. 268 4.1.1.1. Negotiating SR-SFC Capability 270 The SR-SFC capability TLV is contained in the OPEN object. By 271 including the TLV in the OPEN message to a PCE, a PCC indicates its 272 support for SFPs. By including the TLV in the OPEN message to a PCC, 273 a PCE indicates that it is capable of computing SFPs. 275 4.2. RP/SRP Object 277 In order to setup an SFP, the RP or SRP object MUST carry a PATH- 278 SETUP-TYPE TLV specified in [I-D.ietf-pce-lsp-setup-type]. This 279 document defines four new Path Setup Types (PST) for SR-SFC as 280 follows: 282 PST = 2: The path is an SFP. 284 PST = 3: The path is a compact SFP. 286 PST = 4: The path is an SR-specific SFP. 288 PST = 5: The path is a compact SR-specific SFP. 290 4.3. Include Route Object 292 The IRO (Include Route Object) MUST be carried within PCReq messages 293 to indicate a particular SFC. Furthermore, the IRO MAY be carried in 294 PCRep messages. When carried within a PCRep message with the NO-PATH 295 object, the IRO indicates the set of service functions that cause the 296 PCE to fail to find a path. This document defines a new sub-object 297 type for the SR-SFC as follows: 299 Type Sub-object 301 5 Service Function ID 303 4.4. SR-SFC-ERO Object 305 Generally speaking, an SR-SFC-ERO object consists of one or more ERO 306 subobjects described in the following sub-sections to represent a 307 particular type of service function path. In the ERO subobject, each 308 SID is associated with an identifier that represents either an SFF or 309 an SF. This identifier is referred to as the 'Node or Service 310 Identifier' (NSI). As described later, an NSI can be represented in 311 various formats (e.g., IPv4 address, IPv6 address, SF identifier, 312 etc). Specifically, in the SFP case, the NSI of every ERO subobject 313 contained in the SR-SFC-ERO object represents an SFF or an SF while 314 the SID of each ERO subobject is set to null. In the compact SFP 315 case, the NSI of every ERO subobject contained in the SR-SFC-ERO 316 object only represents an SFF meanwhile the SID of every ERO 317 subobject is set to null. In the SR-specific SFP, the NSI of every 318 ERO subobject contained in the SR-SFC-ERO object represents an SFF or 319 an SF while the SID of every ERO subject MUST NOT be null. In the 320 compact SR-specific SFP, the NSI of every ERO subobject contained in 321 the SR-SFC-ERO object represents an SFF meanwhile the SID of every 322 ERO subobject MUST NOT be null. 324 4.4.1. SR-SFC-ERO Subobject 326 An SR-SFC-ERO subobject (as shown in Figure 3) consists of a 32-bit 327 header followed by the SID and the NSI associated with the SID. The 328 SID is a 32-bit or 128 bit number. The size of the NSI depends on 329 its respective type, as described in the following sub-sections. 331 0 1 2 3 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 |L| Type | Length | NSIT | Flags |P|F|S|C|M| 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 // SID (variable:4 or 16 octets) // 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 // NSI (variable) // 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 Figure 3: SR-SFC-ERO Subobject Format 343 'L' Flag: indicates whether the subobject represents a loose-hop 344 in the explicit route [RFC3209]. If this flag is unset, a PCC 345 MUST not overwrite the SID value present in the SR-SFC-ERO 346 subobject. Otherwise, a PCC MAY expand or replace one or more SID 347 value(s) in the received SR-SFC-ERO based on its local policy. 349 Type: is the type of the SR-SFC-ERO Subobject. This document 350 defines the SR-SFC-ERO Subobject type. A new code point will be 351 requested for the SR-SFC-ERO Subobject from IANA. 353 Length: contains the total length of the subobject in octets, 354 including the L, Type and Length fields. Length MUST be at least 355 4, and MUST be a multiple of 4. 357 NSI Type (NSIT): indicates the type of NSI associated with the 358 SID. The NSI-Type values are described later in this document. 360 Flags: is used to carry any additional information pertaining to 361 SID. Currently, the following flag bits are defined: 363 M: When this bit is set, the SID value represents an MPLS label 364 stack entry as specified in [RFC5462], where only the label 365 value is specified by the PCE. Other fields (TC, S, and TTL) 366 fields MUST be considered invalid, and PCC MUST set these 367 fields according to its local policy and MPLS forwarding rules. 369 C: When this bit as well as the M bit are set, then the SID 370 value represents an MPLS label stack entry as specified in 371 [RFC5462], where all the entry's fields (Label, TC, S, and TTL) 372 are specified by the PCE. However, a PCC MAY choose to 373 override TC, S, and TTL values according its local policy and 374 MPLS forwarding rules. 376 S: When this bit is set, the SID value in the subobject body is 377 null. In this case, the PCC is responsible for choosing the 378 SID value, e.g., by looking up its Traffic Engineering Database 379 (TED) using node/service identifier in the subobject body. 381 F: When this bit is set, the NSI value in the subobject body is 382 null. 384 P: When this bit is set, the SID value represents an IPv6 385 address. 387 SID: is the 4-octect or 16-octect Segment Identifier 389 NSI: contains the NSI associated with the SID. Depending on the 390 value of NSIT, the NSI can have different format as described in 391 the following sub-section. 393 4.4.2. NSI Associated with SID 395 This document defines the following NSIs: 397 'IPv4 Node ID': is specified as an IPv4 address. In this case, 398 NSIT and Length are 1 and 12 respectively. 400 'IPv6 Node ID': is specified as an IPv6 address. In this case, 401 NSIT and Length are 2 and 24 respectively. 403 'Service Function ID': is specified as an SF ID. In this case, 404 NSIT and Length are TBD. 406 4.4.3. SR-SFC-ERO Processing 408 TBD 410 5. Acknowledgements 412 TBD. 414 6. IANA Considerations 416 6.1. PCEP Objects 418 IANA is requested to allocate an ERO subobject type (recommended 419 value= 6) for the SR-SFC-ERO subobject. 421 6.2. PCEP-Error Object 423 TBD 425 6.3. PCEP TLV Type Indicators 427 This document defines the following new PCEP TLV: 429 Value Meaning Reference 431 27 SR-SFC-PCE-CAPABILITY This document 433 6.4. New Path Setup Type 435 This document defines the following four new setup types for the 436 PATH-SETUP-TYPE TLV: 438 Value Description Reference 440 2 The path is an SFP. This document 442 3 The path is a compact SFP. This document 444 4 The path is an SR-specific SFP. This document 446 5 The path is a compact SR-specific SFP. This document 448 6.5. New IRO Sub-object Type 450 This document defines a new IRO sub-object type for SFC as follows: 452 Type Sub-object 454 5 Service Function ID 456 7. Security Considerations 458 This document does not introduce any new security considerations. 460 8. References 462 8.1. Normative References 464 [I-D.ietf-pce-stateful-pce] 465 Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP 466 Extensions for Stateful PCE", draft-ietf-pce-stateful- 467 pce-18 (work in progress), December 2016. 469 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 470 Requirement Levels", BCP 14, RFC 2119, 471 DOI 10.17487/RFC2119, March 1997, 472 . 474 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 475 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 476 DOI 10.17487/RFC5440, March 2009, 477 . 479 8.2. Informative References 481 [I-D.ietf-pce-lsp-setup-type] 482 Sivabalan, S., Medved, J., Minei, I., Crabbe, E., Varga, 483 R., Tantsura, J., and J. Hardwick, "Conveying path setup 484 type in PCEP messages", draft-ietf-pce-lsp-setup-type-03 485 (work in progress), June 2015. 487 [I-D.ietf-pce-segment-routing] 488 Sivabalan, S., Medved, J., Filsfils, C., Crabbe, E., 489 Raszuk, R., Lopez, V., Tantsura, J., Henderickx, W., and 490 J. Hardwick, "PCEP Extensions for Segment Routing", draft- 491 ietf-pce-segment-routing-08 (work in progress), October 492 2016. 494 [I-D.ietf-spring-segment-routing-mpls] 495 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 496 Litkowski, S., Horneffer, M., Shakir, R., 497 jefftant@gmail.com, j., and E. Crabbe, "Segment Routing 498 with MPLS data plane", draft-ietf-spring-segment-routing- 499 mpls-05 (work in progress), July 2016. 501 [I-D.xu-mpls-service-chaining] 502 Xu, X., Bryant, S., Assarpour, H., Shah, H., Contreras, 503 L., and d. daniel.bernier@bell.ca, "Service Chaining using 504 MPLS Source Routing", draft-xu-mpls-service-chaining-00 505 (work in progress), October 2016. 507 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 508 Chaining (SFC) Architecture", RFC 7665, 509 DOI 10.17487/RFC7665, October 2015, 510 . 512 Authors' Addresses 513 Xiaohu Xu 514 Huawei 516 Email: xuxiaohu@huawei.com 518 JIanjie You 520 Email: jianjie.you@gmail.com 522 Siva Sivabalan 523 Cisco 525 Email: msiva@cisco.com 527 Himanshu Shah 528 Ciena 530 Email: hshah@ciena.com 532 Luis M. Contreras 533 Telefonica I+D 534 Ronda de la Comunicacion, s/n 535 Sur-3 building, 3rd floor 536 Madrid, 28050 537 Spain 539 Email: luismiguel.contrerasmurillo@telefonica.com 540 URI: http://people.tid.es/LuisM.Contreras/ 542 Daniel Bernier 543 Bell Canada 545 Email: daniel.bernier@bell.ca