idnits 2.17.1 draft-ietf-pce-segment-routing-11.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 == Line 456 has weird spacing: '...L' Flag indic...' == Line 462 has weird spacing: '... Type is th...' == Line 465 has weird spacing: '... Length conta...' == Line 478 has weird spacing: '... Flags is us...' == 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: The 'L' Flag indicates whether the subobject represents a loose-hop in the LSP [RFC3209]. If this flag is unset, a PCC MUST not overwrite the SID value present in the SR-ERO subobject. Otherwise, a PCC MAY expand or replace one or more SID value(s) in the received SR-ERO based on its local policy. -- The document date (November 20, 2017) is 2341 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: 'RFC7420' is defined on line 900, but no explicit reference was found in the text == Outdated reference: A later version (-18) exists of draft-ietf-idr-bgp-ls-segment-routing-msd-01 == Outdated reference: A later version (-25) exists of draft-ietf-isis-segment-routing-extensions-13 == Outdated reference: A later version (-19) exists of draft-ietf-isis-segment-routing-msd-04 == Outdated reference: A later version (-27) exists of draft-ietf-ospf-segment-routing-extensions-21 == Outdated reference: A later version (-25) exists of draft-ietf-ospf-segment-routing-msd-05 == Outdated reference: A later version (-10) exists of draft-ietf-pce-lsp-setup-type-05 == Outdated reference: A later version (-15) exists of draft-ietf-spring-segment-routing-12 Summary: 0 errors (**), 0 flaws (~~), 14 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE S. Sivabalan 3 Internet-Draft C. Filsfils 4 Intended status: Standards Track Cisco Systems, Inc. 5 Expires: May 24, 2018 J. Tantsura 6 Individual 7 W. Henderickx 8 Nokia 9 J. Hardwick 10 Metaswitch Networks 11 November 20, 2017 13 PCEP Extensions for Segment Routing 14 draft-ietf-pce-segment-routing-11 16 Abstract 18 Segment Routing (SR) enables any head-end node to select any path 19 without relying on a hop-by-hop signaling technique (e.g., LDP or 20 RSVP-TE). It depends only on "segments" that are advertised by Link- 21 State Interior Gateway Protocols (IGPs). A Segment Routed Path can 22 be derived from a variety of mechanisms, including an IGP Shortest 23 Path Tree (SPT), explicit configuration, or a Path Computation 24 Element (PCE). This document specifies extensions to the Path 25 Computation Element Protocol (PCEP) that allow a stateful PCE to 26 compute and initiate Traffic Engineering (TE) paths, as well as a PCC 27 to request a path subject to certain constraint(s) and optimization 28 criteria in SR networks. 30 Requirements Language 32 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 33 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 34 document are to be interpreted as described in [RFC2119]. 36 Status of This Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at http://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on May 24, 2018. 53 Copyright Notice 55 Copyright (c) 2017 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (http://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 71 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 3. Overview of PCEP Operation in SR Networks . . . . . . . . . . 5 73 4. SR-Specific PCEP Message Extensions . . . . . . . . . . . . . 6 74 5. Object Formats . . . . . . . . . . . . . . . . . . . . . . . 7 75 5.1. The OPEN Object . . . . . . . . . . . . . . . . . . . . . 7 76 5.1.1. The SR PCE Capability sub-TLV . . . . . . . . . . . . 7 77 5.1.2. Exchanging the SR PCE Capability . . . . . . . . . . 8 78 5.2. The RP/SRP Object . . . . . . . . . . . . . . . . . . . . 9 79 5.3. ERO Object . . . . . . . . . . . . . . . . . . . . . . . 9 80 5.3.1. SR-ERO Subobject . . . . . . . . . . . . . . . . . . 10 81 5.3.2. NAI Associated with SID . . . . . . . . . . . . . . . 12 82 5.3.3. ERO Processing . . . . . . . . . . . . . . . . . . . 13 83 5.4. RRO Object . . . . . . . . . . . . . . . . . . . . . . . 14 84 5.4.1. RRO Processing . . . . . . . . . . . . . . . . . . . 14 85 5.5. METRIC Object . . . . . . . . . . . . . . . . . . . . . . 15 86 6. Backward Compatibility . . . . . . . . . . . . . . . . . . . 15 87 7. Management Considerations . . . . . . . . . . . . . . . . . . 16 88 7.1. Policy . . . . . . . . . . . . . . . . . . . . . . . . . 16 89 7.2. The PCEP Data Model . . . . . . . . . . . . . . . . . . . 16 90 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 91 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 92 9.1. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . 16 93 9.2. PCEP-Error Object . . . . . . . . . . . . . . . . . . . . 17 94 9.3. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 18 95 9.4. New Path Setup Type . . . . . . . . . . . . . . . . . . . 18 96 9.5. New Metric Type . . . . . . . . . . . . . . . . . . . . . 18 97 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 18 98 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 99 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 100 12.1. Normative References . . . . . . . . . . . . . . . . . . 19 101 12.2. Informative References . . . . . . . . . . . . . . . . . 20 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 104 1. Introduction 106 SR technology leverages the source routing and tunneling paradigms. 107 A source node can choose a path without relying on hop-by-hop 108 signaling protocols such as LDP or RSVP-TE. Each path is specified 109 as a set of "segments" advertised by link-state routing protocols 110 (IS-IS or OSPF). [I-D.ietf-spring-segment-routing] provides an 111 introduction to SR architecture. The corresponding IS-IS and OSPF 112 extensions are specified in 113 [I-D.ietf-isis-segment-routing-extensions] and 114 [I-D.ietf-ospf-segment-routing-extensions], respectively. SR 115 architecture defines a "segment" as a piece of information advertised 116 by a link-state routing protocols, e.g. an IGP prefix or an IGP 117 adjacency. Several types of segments are defined. A Node segment 118 represents an ECMP-aware shortest-path computed by IGP to a specific 119 node, and is always global within SR/IGP domain. An Adjacency 120 Segment represents a unidirectional adjacency. An Adjacency Segment 121 is local to the node which advertises it. Both Node segments and 122 Adjacency segments can be used for SR Traffic Engineering (SR-TE). 124 The SR architecture can be applied to the MPLS forwarding plane 125 without any change, in which case an SR path corresponds to an MPLS 126 Label Switching Path (LSP). This document is relevant to the MPLS 127 forwarding plane only. In this document, "Node-SID" and "Adjacency- 128 SID" denote Node Segment Identifier and Adjacency Segment Identifier 129 respectively. 131 A Segment Routed path (SR path) can be derived from an IGP Shortest 132 Path Tree (SPT). SR-TE paths may not follow an IGP SPT. Such paths 133 may be chosen by a suitable network planning tool and provisioned on 134 the ingress node of the SR-TE path. 136 [RFC5440] describes the Path Computation Element Protocol (PCEP) for 137 communication between a Path Computation Client (PCC) and a Path 138 Computation Element (PCE) or between a pair of PCEs. A PCE, or a PCC 139 operating as a PCE (in hierarchical PCE environment), computes paths 140 for MPLS Traffic Engineering LSPs (MPLS-TE LSPs) based on various 141 constraints and optimization criteria. [RFC8231] specifies 142 extensions to PCEP that allow a stateful PCE to compute and recommend 143 network paths in compliance with [RFC4657] and defines objects and 144 TLVs for MPLS-TE LSPs. Stateful PCEP extensions provide 145 synchronization of LSP state between a PCC and a PCE or between a 146 pair of PCEs, delegation of LSP control, reporting of LSP state from 147 a PCC to a PCE, controlling the setup and path routing of an LSP from 148 a PCE to a PCC. Stateful PCEP extensions are intended for an 149 operational model in which LSPs are configured on the PCC, and 150 control over them is delegated to the PCE. 152 A mechanism to dynamically initiate LSPs on a PCC based on the 153 requests from a stateful PCE or a controller using stateful PCE is 154 specified in [I-D.ietf-pce-pce-initiated-lsp]. This mechanism is 155 useful in Software Defined Networking (SDN) applications, such as on- 156 demand engineering, or bandwidth calendaring. 158 It is possible to use a stateful PCE for computing one or more SR-TE 159 paths taking into account various constraints and objective 160 functions. Once a path is chosen, the stateful PCE can initiate an 161 SR-TE path on a PCC using PCEP extensions specified in 162 [I-D.ietf-pce-pce-initiated-lsp] using the SR specific PCEP 163 extensions specified in this document. Additionally, using 164 procedures described in this document, a PCC can request an SR path 165 from either stateful or a stateless PCE. This specification relies 166 on the procedures specified in [I-D.ietf-pce-lsp-setup-type]. 168 2. Terminology 170 The following terminologies are used in this document: 172 ERO: Explicit Route Object 174 IGP: Interior Gateway Protocol 176 IS-IS: Intermediate System to Intermediate System 178 LSR: Label Switching Router 180 MSD: Maximum SID Depth 182 NAI: Node or Adjacency Identifier 184 OSPF: Open Shortest Path First 186 PCC: Path Computation Client 188 PCE: Path Computation Element 190 PCEP: Path Computation Element Protocol 191 RRO: Record Route Object 193 SID: Segment Identifier 195 SR: Segment Routing 197 SR-TE: Segment Routed Traffic Engineering 199 TED: Traffic Engineering Database 201 3. Overview of PCEP Operation in SR Networks 203 In SR networks, an ingress node of an SR path appends all outgoing 204 packets with an SR header consisting of a list of SIDs (or MPLS 205 labels in the context of this document). The header has all 206 necessary information to guide the packets from the ingress node to 207 the egress node of the path, and hence there is no need for any 208 signaling protocol. 210 In a PCEP session, LSP information is carried in the Explicit Route 211 Object (ERO), which consists of a sequence of subobjects. Various 212 types of ERO subobjects have been specified in [RFC3209], [RFC3473], 213 and [RFC3477]. In SR networks, an ingress node of an SR path appends 214 all outgoing packets with an SR header consisting of a list of SIDs 215 (or MPLS labels in the context of this document). SR-TE LSPs 216 computed by a PCE can be represented in one of the following forms: 218 o An ordered set of IP address(es) representing network nodes/links: 219 In this case, the PCC needs to convert the IP address(es) into the 220 corresponding MPLS labels by consulting its Traffic Engineering 221 Database (TED). 223 o An ordered set of SID(s). 225 o An ordered set of both MPLS label(s) and IP address(es): In this 226 case, the PCC needs to convert the IP address(es) into the 227 corresponding SID(s) by consulting its TED. 229 This document defines a new ERO subobject denoted by "SR-ERO 230 subobject" capable of carrying a SID as well as the identity of the 231 node/adjacency represented by the SID. SR-capable PCEP speakers 232 should be able to generate and/or process such ERO subobject. An ERO 233 containing SR-ERO subobjects can be included in the PCEP Path 234 Computation Reply (PCRep) message defined in [RFC5440], the PCEP LSP 235 Initiate Request message (PCInitiate) defined in 236 [I-D.ietf-pce-pce-initiated-lsp], as well as in the PCEP LSP Update 237 Request (PCUpd) and PCEP LSP State Report (PCRpt) messages defined in 238 [RFC8231]. 240 When a PCEP session between a PCC and a PCE is established, both PCEP 241 speakers exchange their capabilites to indicate their ability to 242 support SR-specific functionality. 244 An PCE can update an LSP that is initially established via RSVP-TE 245 signaling to use an SR-TE path, by sending a PCUpd to the PCC that 246 delegated the LSP to it ([RFC8231]). Similarly, an LSP initially 247 created with an SR-TE path can be updated to use RSVP-TE signaling, 248 if necessary. This capability is useful when a network is migrated 249 from RSVP-TE to SR-TE technology. 251 A PCC MAY include an RRO object containing the recorded LSP in PCReq 252 and PCRpt messages as specified in [RFC5440] and [RFC8231], 253 respectively. This document defines a new RRO subobject for SR 254 networks. The methods used by a PCC to record the SR-TE LSP are 255 outside the scope of this document. 257 In summary, this document: 259 o Defines a new ERO subobject, a new RRO subobject and new PCEP 260 error codes. 262 o Specifies how two PCEP speakers can establish a PCEP session that 263 can carry information about SR-TE paths. 265 o Specifies processing rules for the ERO subobject. 267 o Defines a new path setup type to be used in the PATH_SETUP_TYPE 268 and PATH_SETUP_TYPE_CAPABILITY TLVs 269 ([I-D.ietf-pce-lsp-setup-type]). 271 o Defines a new sub-TLV for the PATH_SETUP_TYPE_CAPABILITY TLV. 273 The extensions specified in this document complement the existing 274 PCEP specifications to support SR-TE paths. As such, the PCEP 275 messages (e.g., Path Computation Request, Path Computation Reply, 276 Path Computation Report, Path Computation Update, Path Computation 277 Initiate, etc.,) MUST be formatted according to [RFC5440], [RFC8231], 278 [I-D.ietf-pce-pce-initiated-lsp], and any other applicable PCEP 279 specifications. 281 4. SR-Specific PCEP Message Extensions 283 As defined in [RFC5440], a PCEP message consists of a common header 284 followed by a variable length body made up of mandatory and/or 285 optional objects. This document does not require any changes in the 286 format of the PCReq and PCRep messages specified in [RFC5440], 287 PCInitiate message specified in [I-D.ietf-pce-pce-initiated-lsp], and 288 PCRpt and PCUpd messages specified in [RFC8231]. 290 5. Object Formats 292 5.1. The OPEN Object 294 5.1.1. The SR PCE Capability sub-TLV 296 This document defines a new Path Setup Type (PST) for SR, as follows: 298 o PST = 1: Path is setup using Segment Routing Traffic Engineering. 300 A PCEP speaker SHOULD indicate its support of the function described 301 in this document by sending a PATH-SETUP-TYPE-CAPABILITY TLV in the 302 OPEN object with this new PST included in the PST list. 304 This document also defines the SR-PCE-CAPABILITY sub-TLV. PCEP 305 speakers use this sub-TLV to exchange information about their SR 306 capability. If a PCEP speaker includes PST=1 in the PST List of the 307 PATH-SETUP-TYPE-CAPABILITY TLV then it MUST also include the SR-PCE- 308 CAPABILITY sub-TLV inside the PATH-SETUP-TYPE-CAPABILITY TLV. 310 The format of the SR-PCE-CAPABILITY sub-TLV is shown in the following 311 figure: 313 0 1 2 3 314 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 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 | Type=26 | Length=4 | 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 | Reserved | Flags |L| MSD | 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 Figure 1: SR-PCE-CAPABILITY sub-TLV format 323 The code point for the TLV type is 26. The TLV length is 4 octets. 325 The 32-bit value is formatted as follows. The "Maximum SID Depth" (1 326 octet) field (MSD) specifies the maximum number of SIDs (MPLS label 327 stack depth in the context of this document) that a PCC is capable of 328 imposing on a packet. The "Reserved" (2 octets) field is unused, and 329 MUST be set to zero on transmission and ignored on reception. The 330 "Flags" field is 1 octect long, and this document defines the 331 following flag: 333 o L-flag: A PCC sets this flag to 1 to indicate that it does not 334 impose any limit on the MSD. 336 5.1.2. Exchanging the SR PCE Capability 338 A PCC indicates that it is capable of supporting the head-end 339 functions for SR-TE LSP by including the SR-PCE-CAPABILITY sub-TLV in 340 the Open message that it sends to a PCE. A PCE indicates that it is 341 capable of computing SR-TE paths by including the SR-PCE-CAPABILITY 342 sub-TLV in the Open message that it sends to a PCC. 344 If a PCEP speaker receives a PATH-SETUP-TYPE-CAPABILITY TLV with a 345 PST list containing PST=1, but the SR-PCE-CAPABILITY sub-TLV is 346 absent, then the PCEP speaker MUST send a PCErr message with Error- 347 Type 10 (Reception of an invalid object) and Error-Value TBD1 (to be 348 assigned by IANA) (Missing PCE-SR-CAPABILITY sub-TLV) and MUST then 349 close the PCEP session. If a PCEP speaker receives a PATH-SETUP- 350 TYPE-CAPABILITY TLV with a SR-PCE-CAPABILITY sub-TLV, but the PST 351 list does not contain PST=1, then the PCEP speaker MUST ignore the 352 SR-PCE-CAPABILITY sub-TLV. 354 The number of SIDs that can be imposed on a packet depends on the 355 PCC's data plane's capability. If a PCC sets the L flag to 1 then 356 the MSD is not used and MUST be set to zero. If a PCE receives an 357 SR-PCE-CAPABILITY sub-TLV with the L flag set to 1 then it MUST 358 ignore the MSD field and MUST assume that the sender can impose a SID 359 stack of any depth. If a PCC sets the L flag to zero, then it sets 360 the MSD field to the maximum number of SIDs that it can impose on a 361 packet. If a PCE receives an SR-PCE-CAPABILITY sub-TLV with the L 362 flag and MSD both set to zero then it MUST assume that the PCC is not 363 capable of imposing a SID stack of any depth and hence is not SR-TE 364 capable, unless it learns a non-zero MSD for the PCC through some 365 other means. 367 Note that the MSD value exchanged via the SR-PCE-CAPABILITY sub-TLV 368 indicates the SID/label imposition limit for the PCC node. However, 369 if a PCE learns the MSD value of a PCC node via different means, e.g 370 routing protocols, as specified in: 371 [I-D.ietf-isis-segment-routing-msd]; 372 [I-D.ietf-ospf-segment-routing-msd]; 373 [I-D.ietf-idr-bgp-ls-segment-routing-msd], then it ignores the MSD 374 value in the SR-PCE-CAPABILITY sub-TLV. Furthermore, whenever a PCE 375 learns the MSD for a link via different means, it MUST use that value 376 for that link regardless of the MSD value exchanged in the SR-PCE- 377 CAPABILITY sub-TLV. 379 Once an SR-capable PCEP session is established with a non-zero MSD 380 value, the corresponding PCE MUST NOT send SR-TE paths with a number 381 of SIDs exceeding that MSD value. If a PCC needs to modify the MSD 382 value, it MUST close the PCEP session and re-establish it with the 383 new MSD value. If a PCEP session is established with a non-zero MSD 384 value, and the PCC receives an SR-TE path containing more SIDs than 385 specified in the MSD value, the PCC MUST send a PCErr message with 386 Error-Type 10 (Reception of an invalid object) and Error-Value 3 387 (Unsupported number of Segment ERO subobjects). If a PCEP session is 388 established with an MSD value of zero, then the PCC MAY specify an 389 MSD for each path computation request that it sends to the PCE, by 390 including a "maximum SID depth" metric object on the request, as 391 defined in Section 5.5. 393 The L flag and MSD value inside the SR-PCE-CAPABILITY sub-TLV are 394 meaningful only in the Open message sent from a PCC to a PCE. As 395 such, a PCE MUST set the L flag and MSD value to zero in an outbound 396 message to a PCC. Similarly, a PCC MUST ignore any MSD value 397 received from a PCE. If a PCE receives multiple SR-PCE-CAPABILITY 398 sub-TLVs in an Open message, it processes only the first sub-TLV 399 received. 401 5.2. The RP/SRP Object 403 In order to setup an SR-TE LSP using SR, RP or SRP object MUST 404 include PATH-SETUP-TYPE TLV, specified in 405 [I-D.ietf-pce-lsp-setup-type], with the PST set to 1 (path setup 406 using SR-TE). 408 The LSP-IDENTIFIERS TLV MAY be present for the above PST type. 410 5.3. ERO Object 412 An SR-TE path consists of one or more SID(s) where each SID MAY be 413 associated with the identifier that represents the node or adjacency 414 corresponding to the SID. This identifier is referred to as the 415 'Node or Adjacency Identifier' (NAI). As described later, a NAI can 416 be represented in various formats (e.g., IPv4 address, IPv6 address, 417 etc). Furthermore, a NAI is used for troubleshooting purposes and, 418 if necessary, to derive SID value as described below. 420 The ERO object specified in [RFC5440] is used to carry SR-TE path 421 information. In order to carry SID and/or NAI, this document defines 422 a new ERO subobject referred to as "SR-ERO subobject" whose format is 423 specified in the following section. An ERO object carrying an SR-TE 424 path consists of one or more ERO subobject(s), and MUST carry only 425 SR-ERO subobject(s). Note that an SR-ERO subobject does not need to 426 have both SID and NAI. However, at least one of them MUST be 427 present. 429 When building the MPLS label stack from ERO, a PCC MUST assume that 430 SR-ERO subobjects are organized as a last-in-first-out stack. The 431 first subobject relative to the beginning of ERO contains the 432 information about the topmost label. The last subobject contains 433 information about the bottommost label. 435 5.3.1. SR-ERO Subobject 437 An SR-ERO subobject consists of a 32-bit header followed by the SID 438 and the NAI associated with the SID. The SID is a 32-bit number. 439 The size of the NAI depends on its respective type, as described in 440 the following sections. 442 0 1 2 3 443 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 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 |L| Type | Length | ST | Flags |F|S|C|M| 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 | SID | 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 449 // NAI (variable) // 450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 Figure 2: SR-ERO Subobject format 454 The fields in the SR-ERO Subobject are as follows: 456 The 'L' Flag indicates whether the subobject represents a loose-hop 457 in the LSP [RFC3209]. If this flag is unset, a PCC MUST not 458 overwrite the SID value present in the SR-ERO subobject. 459 Otherwise, a PCC MAY expand or replace one or more SID value(s) in 460 the received SR-ERO based on its local policy. 462 Type is the type of the SR-ERO subobject. This document defines the 463 SR-ERO subobject type, and requests a new codepoint from IANA. 465 Length contains the total length of the subobject in octets, 466 including the L, Type and Length fields. Length MUST be at least 467 8, and MUST be a multiple of 4. As mentioned earlier, an SR-ERO 468 subobject MUST have at least SID or NAI. The length should take 469 into consideration SID or NAI only if they are not null. The 470 flags described below used to indicate whether SID or NAI field is 471 null. 473 SID Type (ST) indicates the type of information associated with the 474 SID contained in the object body. When ST value is 0, SID MUST 475 NOT be null and NAI MUST be null. Other ST values are described 476 later in this document. 478 Flags is used to carry any additional information pertaining to SID. 479 Currently, the following flag bits are defined: 481 * M: When this bit is set, the SID value represents an MPLS label 482 stack entry as specified in [RFC5462] where only the label 483 value is specified by the PCE. Other fields (TC, S, and TTL) 484 fields MUST be considered invalid, and PCC MUST set these 485 fields according to its local policy and MPLS forwarding rules. 487 * C: When this bit as well as the M bit are set, then the SID 488 value represents an MPLS label stack entry as specified in 489 [RFC5462], where all the entry's fields (Label, TC, S, and TTL) 490 are specified by the PCE. However, a PCC MAY choose to 491 override TC, S, and TTL values according its local policy and 492 MPLS forwarding rules. 494 * S: When this bit is set, the SID value in the subobject body is 495 null. In this case, the PCC is responsible for choosing the 496 SID value, e.g., by looking up its TED using the NAI which, in 497 this case, MUST be present in the subobject. 499 * F: When this bit is set, the NAI value in the subobject body is 500 null. 502 SID is the Segment Identifier. 504 NAI contains the NAI associated with the SID. Depending on the 505 value of ST, the NAI can have different format as described in the 506 following section. 508 5.3.2. NAI Associated with SID 510 This document defines the following NAIs: 512 'IPv4 Node ID' is specified as an IPv4 address. In this case, ST 513 value is 1, and the Length is 8 or 12 depending on either SID or 514 NAI or both are included in the subobject. 516 'IPv6 Node ID' is specified as an IPv6 address. In this case, ST 517 and Length are 2, and Length is 8, 20, or 24 depending on either 518 SID or NAI or both are included in the subobject. 520 'IPv4 Adjacency' is specified as a pair of IPv4 addresses. In this 521 case, ST value is 3. The Length is 8, 12, or 16 depending on 522 either SID or NAI or both are included in the subobject, and the 523 format of the NAI is shown in the following figure: 525 0 1 2 3 526 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 527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 528 | Local IPv4 address | 529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 530 | Remote IPv4 address | 531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 533 Figure 3: NAI for IPv4 adjacency 535 'IPv6 Adjacency' is specified as a pair of IPv6 addresses. In this 536 case, ST valie is 4. The Length is 8, 36 or 40 depending on 537 whether SID or NAI or both included in the subobject,and the 538 format of the NAI is shown in the following figure: 540 0 1 2 3 541 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 542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 543 // Local IPv6 address (16 bytes) // 544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 545 // Remote IPv6 address (16 bytes) // 546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 548 Figure 4: NAI for IPv6 adjacency 550 'Unnumbered Adjacency with IPv4 NodeIDs' is specified as a pair of 551 Node ID / Interface ID tuples. In this case, ST value is 5. The 552 Length is 8, 20, or 24 depending on whether SID or NAI or both 553 included in the subobject, and the format of the NAI is shown in 554 the following figure: 556 0 1 2 3 557 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 558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 559 | Local Node-ID | 560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 561 | Local Interface ID | 562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 563 | Remote Node-ID | 564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 565 | Remote Interface ID | 566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 568 Figure 5: NAI for Unnumbered adjacency with IPv4 Node IDs 570 5.3.3. ERO Processing 572 A PCEP speaker that does not recognize the SR-ERO subobject in PCRep, 573 PCInitiate, PCUpd or PCRpt messages MUST reject the entire PCEP 574 message and MUST send a PCErr message with Error-Type=3 ("Unknown 575 Object") and Error-Value=2 ("Unrecognized object Type") or Error- 576 Type=4 ("Not supported object") and Error-Value=2 ("Not supported 577 object Type"), defined in [RFC5440]. 579 When the SID represents an MPLS label (i.e. the M bit is set), its 580 value (20 most significant bits) MUST be larger than 15, unless it is 581 special purpose label, such as an Entropy Label Indicator (ELI). If 582 a PCEP speaker receives an invalid value, it MUST send a PCErr 583 message with Error-Type = 10 ("Reception of an invalid object") and 584 Error Value = 2 ("Bad label value"). If both M and C bits of an SR- 585 ERO subobject are set, and if a PCEP speaker finds erroneous setting 586 in one or more of TC, S, and TTL fields, it MUST send a PCErr message 587 with Error-Type = 10 ("Reception of an invalid object") and Error- 588 Value = 4 ("Bad label format"). 590 If a PCC receives a stack of SR-ERO subobjects, and the number of 591 stack exceeds the maximum number of SIDs that the PCC can impose on 592 the packet, it MAY send a PCErr message with Error-Type = 10 593 ("Reception of an invalid object") and Error-Value = 3 ("Unsupported 594 number of Segment ERO subobjects"). 596 When a PCEP speaker detects that all subobjects of ERO are not 597 identical, and if it does not handle such ERO, it MUST send a PCErr 598 message with Error-Type = 10 ("Reception of an invalid object") and 599 Error-Value = 5 ("Non-identical ERO subobjects"). 601 If a PCEP speaker receives an SR-ERO subobject in which both SID and 602 NAI are absent, it MUST consider the entire ERO object invalid and 603 send a PCErr message with Error-Type = 10 ("Reception of an invalid 604 object") and Error-Value = 6 ("Both SID and NAI are absent in ERO 605 subobject"). 607 When a PCEP speaker receives an SR-ERO subobject in which ST is 0, 608 SID MUST be present and NAI MUST NOT be present(i.e., S-flag MUST be 609 0, F-flag MUST be 1, and the Length MUST be 8). Otherwise, it MUST 610 consider the entire ERO object invalid and send a PCErr message with 611 Error-Type = 10 ("Reception of an invalid object") and Error-Value = 612 11 ("Malformed object"). The PCEP speaker MAY include the malformed 613 SR-ERO object in the PCErr message as well. 615 5.4. RRO Object 617 A PCC can record SR-TE LSP and report the LSP to a PCE via RRO. An 618 RRO object contains one or more subobjects called "SR-RRO subobjects" 619 whose format is shown below: 621 0 1 2 3 622 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 623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 624 | Type | Length | ST | Flags |F|S|C|M| 625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 626 | SID | 627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 628 // NAI (variable) // 629 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 631 Figure 6: SR-RRO Subobject format 633 The format of SR-RRO subobject is the same as that of SR-ERO 634 subobject without L flag. 636 A PCC MUST assume that SR-RRO subobjects are organized such that the 637 first subobject relative to the beginning of RRO contains the 638 information about the topmost label, and the last subobject contains 639 information about the bottommost label of the SR-TE LSP. 641 5.4.1. RRO Processing 643 Processing rules of SR-RRO subobject are identical to those of SR-ERO 644 subobject. 646 If a PCEP speaker receives an SR-RRO subobject in which both SID and 647 NAI are absent, it MUST consider the entire RRO object invalid and 648 send a PCErr message with Error-Type = 10 ("Reception of an invalid 649 object") and Error-Value = 7 ("Both SID and NAI are absent in RRO 650 subobject"). 652 If a PCE detects that all subobjects of RRO are not identical, and if 653 it does not handle such RRO, it MUST send a PCErr message with Error- 654 Type = 10 ("Reception of an invalid object") and Error-Value = 10 655 ("Non-identical RRO subobjects"). 657 5.5. METRIC Object 659 If a PCEP session is established with an MSD value of zero, then the 660 PCC MAY specify the MSD for an individual path computation request 661 using the METRIC object defined in [RFC5440]. This document defines 662 a new type for the METRIC object to be used for this purpose as 663 follows: 665 o T = 11: Maximum SID Depth of the requested path. 667 The PCC sets the metric-value to the MSD for this path. The PCC MUST 668 set the B (bound) bit to 1 in the METRIC object, which specifies that 669 the SID depth for the computed path MUST NOT exceed the metric-value. 671 If a PCEP session is established with a non-zero MSD value, then the 672 PCC MUST NOT send an MSD METRIC object. If the PCE receives a path 673 computation request with an MSD METRIC object on a session with a 674 non-zero MSD value then it MUST consider the request invalid and send 675 a PCErr with Error-Type = 10 ("Reception of an invalid object") and 676 Error-Value 9 ("Default MSD is specified for the PCEP session"). 678 6. Backward Compatibility 680 A PCEP speaker that does not support the SR PCEP capability cannot 681 recognize the SR-ERO or SR-RRO subobjects. As such, it MUST send a 682 PCEP error with Error-Type = 4 (Not supported object) and Error-Value 683 = 2 (Not supported object Type) as per [RFC5440]. 685 Some implementations, which are compliant with an earlier version of 686 this specification, do not send the PATH-SETUP-TYPE-CAPABILITY TLV in 687 their OPEN objects. Instead, to indicate that they support SR, these 688 implementations include the SR-CAPABILITY-TLV as a top-level TLV in 689 the OPEN object. Unfortunately, some of these implementations made 690 it into the field before this document was published in its final 691 form. Therefore, if a PCEP speaker receives an OPEN object in which 692 the SR-CAPABILITY-TLV appears as a top-level TLV, then it MUST 693 interpret this as though the sender had sent a PATH-SETUP-TYPE- 694 CAPABILITY TLV with a PST list of (0, 1) (that is, both RSVP-TE and 695 SR-TE PSTs are supported) and with the SR-CAPABILITY-TLV as a sub- 696 TLV. If a PCEP speaker receives an OPEN object in which both the SR- 697 CAPABILITY-TLV and PATH-SETUP-TYPE-CAPABILITY TLV appear as top-level 698 TLVs, then it MUST ignore the top-level SR-CAPABILITY-TLV and process 699 only the PATH-SETUP-TYPE-CAPABILITY TLV. 701 7. Management Considerations 703 7.1. Policy 705 PCEP implementation: 707 o Can enable SR PCEP capability either by default or via explicit 708 configuration. 710 o May generate PCEP error due to unsupported number of SR-ERO or SR- 711 RRO subobjects either by default or via explicit configuration. 713 7.2. The PCEP Data Model 715 A PCEP MIB module is defined in [RFC7420]n eeds be extended to cover 716 additional functionality provided by [RFC5440] and 717 [I-D.ietf-pce-pce-initiated-lsp]. Such extension will cover the new 718 functionality specified in this document. 720 8. Security Considerations 722 The security considerations described in [RFC5440] and 723 [I-D.ietf-pce-pce-initiated-lsp] are applicable to this 724 specification. No additional security measure is required. 726 9. IANA Considerations 728 9.1. PCEP Objects 730 This document defines a new sub-object type for the PCEP explicit 731 route object (ERO), and a new sub-object type for the PCEP record 732 route object (RRO). The code points for sub-object types of these 733 objects is maintained in the RSVP parameters registry, under the 734 EXPLICIT_ROUTE and ROUTE_RECORD objects. IANA is requested to 735 confirm the early allocation of the following code points in the RSVP 736 Parameters registry for each of the new sub-object types defined in 737 this document. 739 Object Sub-Object Sub-Object Type 740 --------------------- -------------------------- ------------------ 741 EXPLICIT_ROUTE SR-ERO (PCEP-specific) 36 742 ROUTE_RECORD SR-RRO (PCEP-specific) 36 744 9.2. PCEP-Error Object 746 IANA is requested to confirm the early allocation of the code-points 747 in the PCEP-ERROR Object Error Types and Values registry for the 748 following new error-values: 750 Error-Type Meaning 751 ---------- ------- 752 10 Reception of an invalid object. 754 Error-value = 2: Bad label value 755 Error-value = 3: Unsupported number 756 of Segment ERO 757 subobjects 758 Error-value = 4: Bad label format 759 Error-value = 5: Non-identical ERO 760 subobjects 761 Error-value = 6: Both SID and NAI 762 are absent in ERO 763 subobject 764 Error-value = 7: Both SID and NAI 765 are absent in RRO 766 subobject 767 Error-value = 9: Default MSD is 768 specified for the 769 PCEP session 770 Error-value = 10: Non-identical RRO 771 subobjects 772 Error-value = TBD1: Missing PCE-SR- 773 CAPABILITY sub-TLV 775 Note to IANA: this draft originally had an early allocation for 776 Error-value=11 (Malformed object) in the above list. However, we 777 have since moved the definition of that code point to draft-ietf-pce- 778 lsp-setup-type and we included an instruction in that draft for you 779 to update the reference in the indicated registry. Please ensure 780 that this has happened when you process the present draft. 782 Note to IANA: the final Error-value (Missing PCE-SR-CAPABILITY sub- 783 TLV) in the above list was defined after the early allocation took 784 place, and so does not currently have a code point assigned. Please 785 assign a code point from the indicated registry and replace each 786 instance of "TBD1" in this document with the allocated code point. 788 9.3. PCEP TLV Type Indicators 790 IANA is requested to confirm the early allocation of the following 791 code point in the PCEP TLV Type Indicators registry. 793 Value Meaning Reference 794 ------------------------- ---------------------------- -------------- 795 26 SR-PCE-CAPABILITY This document 797 9.4. New Path Setup Type 799 [I-D.ietf-pce-lsp-setup-type] requests that IANA creates a sub- 800 registry within the "Path Computation Element Protocol (PCEP) 801 Numbers" registry called "PCEP Path Setup Types". IANA is requested 802 to allocate a new code point within this registry, as follows: 804 Value Description Reference 805 ------------------------- ---------------------------- -------------- 806 1 Traffic engineering path is This document 807 setup using Segment Routing. 809 9.5. New Metric Type 811 IANA is requested to confirm the early allocation of the following 812 code point in the PCEP METRIC object T field registry: 814 Value Description Reference 815 ------------------------- ---------------------------- -------------- 816 11 Segment-ID (SID) Depth. This document 818 10. Contributors 820 The following people contributed to this document: 822 - Lakshmi Sharma 823 - Jan Medved 824 - Edward Crabbe 825 - Robert Raszuk 826 - Victor Lopez 828 11. Acknowledgements 830 We thank Ina Minei, George Swallow, Marek Zavodsky, Dhruv Dhody, Ing- 831 Wher Chen and Tomas Janciga for the valuable comments. 833 12. References 835 12.1. Normative References 837 [I-D.ietf-idr-bgp-ls-segment-routing-msd] 838 Tantsura, J., Chunduri, U., Mirsky, G., and S. Sivabalan, 839 "Signaling Maximum SID Depth using Border Gateway Protocol 840 Link-State", draft-ietf-idr-bgp-ls-segment-routing-msd-01 841 (work in progress), October 2017. 843 [I-D.ietf-isis-segment-routing-extensions] 844 Previdi, S., Filsfils, C., Bashandy, A., Gredler, H., 845 Litkowski, S., Decraene, B., and j. jefftant@gmail.com, 846 "IS-IS Extensions for Segment Routing", draft-ietf-isis- 847 segment-routing-extensions-13 (work in progress), June 848 2017. 850 [I-D.ietf-isis-segment-routing-msd] 851 Tantsura, J., Chunduri, U., Aldrin, S., and L. Ginsberg, 852 "Signaling MSD (Maximum SID Depth) using IS-IS", draft- 853 ietf-isis-segment-routing-msd-04 (work in progress), June 854 2017. 856 [I-D.ietf-ospf-segment-routing-extensions] 857 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 858 Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 859 Extensions for Segment Routing", draft-ietf-ospf-segment- 860 routing-extensions-21 (work in progress), October 2017. 862 [I-D.ietf-ospf-segment-routing-msd] 863 Tantsura, J., Chunduri, U., Aldrin, S., and P. Psenak, 864 "Signaling MSD (Maximum SID Depth) using OSPF", draft- 865 ietf-ospf-segment-routing-msd-05 (work in progress), June 866 2017. 868 [I-D.ietf-pce-lsp-setup-type] 869 Sivabalan, S., Tantsura, J., Minei, I., Varga, R., and J. 870 Hardwick, "Conveying path setup type in PCEP messages", 871 draft-ietf-pce-lsp-setup-type-05 (work in progress), 872 October 2017. 874 [I-D.ietf-pce-pce-initiated-lsp] 875 Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP 876 Extensions for PCE-initiated LSP Setup in a Stateful PCE 877 Model", draft-ietf-pce-pce-initiated-lsp-11 (work in 878 progress), October 2017. 880 [I-D.ietf-spring-segment-routing] 881 Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., 882 and R. Shakir, "Segment Routing Architecture", draft-ietf- 883 spring-segment-routing-12 (work in progress), June 2017. 885 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 886 Requirement Levels", BCP 14, RFC 2119, 887 DOI 10.17487/RFC2119, March 1997, . 890 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 891 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 892 DOI 10.17487/RFC5440, March 2009, . 895 [RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching 896 (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic 897 Class" Field", RFC 5462, DOI 10.17487/RFC5462, February 898 2009, . 900 [RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J. 901 Hardwick, "Path Computation Element Communication Protocol 902 (PCEP) Management Information Base (MIB) Module", 903 RFC 7420, DOI 10.17487/RFC7420, December 2014, 904 . 906 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 907 Computation Element Communication Protocol (PCEP) 908 Extensions for Stateful PCE", RFC 8231, 909 DOI 10.17487/RFC8231, September 2017, . 912 12.2. Informative References 914 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 915 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 916 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 917 . 919 [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label 920 Switching (GMPLS) Signaling Resource ReserVation Protocol- 921 Traffic Engineering (RSVP-TE) Extensions", RFC 3473, 922 DOI 10.17487/RFC3473, January 2003, . 925 [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links 926 in Resource ReSerVation Protocol - Traffic Engineering 927 (RSVP-TE)", RFC 3477, DOI 10.17487/RFC3477, January 2003, 928 . 930 [RFC4657] Ash, J., Ed. and J. Le Roux, Ed., "Path Computation 931 Element (PCE) Communication Protocol Generic 932 Requirements", RFC 4657, DOI 10.17487/RFC4657, September 933 2006, . 935 Authors' Addresses 937 Siva Sivabalan 938 Cisco Systems, Inc. 939 2000 Innovation Drive 940 Kanata, Ontario K2K 3E8 941 Canada 943 Email: msiva@cisco.com 945 Clarence Filsfils 946 Cisco Systems, Inc. 947 Pegasus Parc 948 De kleetlaan 6a, DIEGEM BRABANT 1831 949 BELGIUM 951 Email: cfilsfil@cisco.com 953 Jeff Tantsura 954 Individual 955 444 San Antonio Rd, 10A 956 Palo Alto, CA 94306 957 USA 959 Email: jefftant.ietf@gmail.com 961 Wim Henderickx 962 Nokia 963 Copernicuslaan 50 964 Antwerp 2018, CA 95134 965 BELGIUM 967 Email: wim.henderickx@alcatel-lucent.com 968 Jon Hardwick 969 Metaswitch Networks 970 100 Church Street 971 Enfield, Middlesex 972 UK 974 Email: jonathan.hardwick@metaswitch.com