idnits 2.17.1 draft-ietf-pce-segment-routing-02.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 414 has weird spacing: '...L' Flag indic...' == Line 420 has weird spacing: '... Type is th...' == Line 423 has weird spacing: '... Length conta...' == Line 435 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: As defined in [RFC5440], a PCEP message consists of a common header followed by a variable length body made up of mandatory and/or optional objects. This document does not require any changes in the format of PCReq and PCRep messages specified in [RFC5440], PCInitiate message specified in [I-D.ietf-pce-pce-initiated-lsp], and PCRpt and PCUpd messages specified in [I-D.ietf-pce-stateful-pce]. However, PCEP messages pertaining to SR-TE LSP MUST include PATH-SETUP-TYPE TLV in the RP or SRP object to clearly identify that SR-TE LSP is intended. In other words, a PCEP speaker MUST not infer whether or not a PCEP message pertains to SR-TE LSP from any other object or TLV. == 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 (April 20, 2015) is 3294 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) == Outdated reference: A later version (-25) exists of draft-ietf-isis-segment-routing-extensions-00 == Outdated reference: A later version (-27) exists of draft-ietf-ospf-segment-routing-extensions-00 == Outdated reference: A later version (-10) exists of draft-ietf-pce-lsp-setup-type-00 == Outdated reference: A later version (-11) exists of draft-ietf-pce-pce-initiated-lsp-01 == Outdated reference: A later version (-11) exists of draft-ietf-pce-pcep-mib-04 == Outdated reference: A later version (-21) exists of draft-ietf-pce-stateful-pce-05 Summary: 0 errors (**), 0 flaws (~~), 13 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Sivabalan 3 Internet-Draft J. Medved 4 Intended status: Standards Track C. Filsfils 5 Expires: October 22, 2015 Cisco Systems, Inc. 6 E. Crabbe 8 R. Raszuk 9 Mirantis Inc. 10 V. Lopez 11 Telefonica I+D 12 J. Tantsura 13 Ericsson 14 W. Henderickx 15 Alcatel Lucent 16 J. Hardwick 17 Metaswitch Networks 18 April 20, 2015 20 PCEP Extensions for Segment Routing 21 draft-ietf-pce-segment-routing-02.txt 23 Abstract 25 Segment Routing (SR) enables any head-end node to select any path 26 without relying on a hop-by-hop signaling technique (e.g., LDP or 27 RSVP-TE). It depends only on "segments" that are advertised by Link- 28 State Interior Gateway Protocols (IGPs). A Segment Routed Path can 29 be derived from a variety of mechanisms, including an IGP Shortest 30 Path Tree (SPT), explicit configuration, or a Path Computation 31 Element (PCE). This document specifies extensions to the Path 32 Computation Element Protocol (PCEP) that allow a stateful PCE to 33 compute and initiate Traffic Engineering (TE) paths, as well as a PCC 34 to request a path subject to certain constraint(s) and optimization 35 criteria in SR networks. 37 Requirements Language 39 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 40 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 41 document are to be interpreted as described in [RFC2119]. 43 Status of this Memo 45 This Internet-Draft is submitted in full conformance with the 46 provisions of BCP 78 and BCP 79. 48 Internet-Drafts are working documents of the Internet Engineering 49 Task Force (IETF). Note that other groups may also distribute 50 working documents as Internet-Drafts. The list of current Internet- 51 Drafts is at http://datatracker.ietf.org/drafts/current/. 53 Internet-Drafts are draft documents valid for a maximum of six months 54 and may be updated, replaced, or obsoleted by other documents at any 55 time. It is inappropriate to use Internet-Drafts as reference 56 material or to cite them other than as "work in progress." 58 This Internet-Draft will expire on October 22, 2015. 60 Copyright Notice 62 Copyright (c) 2015 IETF Trust and the persons identified as the 63 document authors. All rights reserved. 65 This document is subject to BCP 78 and the IETF Trust's Legal 66 Provisions Relating to IETF Documents 67 (http://trustee.ietf.org/license-info) in effect on the date of 68 publication of this document. Please review these documents 69 carefully, as they describe your rights and restrictions with respect 70 to this document. Code Components extracted from this document must 71 include Simplified BSD License text as described in Section 4.e of 72 the Trust Legal Provisions and are provided without warranty as 73 described in the Simplified BSD License. 75 Table of Contents 77 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 78 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 79 3. Overview of PCEP Operation in SR Networks . . . . . . . . . . 6 80 4. SR-Specific PCEP Message Extensions . . . . . . . . . . . . . 7 81 5. Object Formats . . . . . . . . . . . . . . . . . . . . . . . . 8 82 5.1. The OPEN Object . . . . . . . . . . . . . . . . . . . . . 8 83 5.1.1. The SR PCE Capability TLV . . . . . . . . . . . . . . 8 84 5.2. The RP/SRP Object . . . . . . . . . . . . . . . . . . . . 9 85 5.3. ERO Object . . . . . . . . . . . . . . . . . . . . . . . . 9 86 5.3.1. SR-ERO Subobject . . . . . . . . . . . . . . . . . . . 10 87 5.3.2. NAI Associated with SID . . . . . . . . . . . . . . . 11 88 5.3.3. ERO Processing . . . . . . . . . . . . . . . . . . . . 13 89 5.4. RRO Object . . . . . . . . . . . . . . . . . . . . . . . . 14 90 5.4.1. RRO Processing . . . . . . . . . . . . . . . . . . . . 14 91 5.5. METRIC Object . . . . . . . . . . . . . . . . . . . . . . 15 92 6. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 15 93 7. Management Considerations . . . . . . . . . . . . . . . . . . 15 94 7.1. Policy . . . . . . . . . . . . . . . . . . . . . . . . . . 15 95 7.2. The PCEP Data Model . . . . . . . . . . . . . . . . . . . 15 96 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 97 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 98 9.1. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . . 16 99 9.2. PCEP-Error Object . . . . . . . . . . . . . . . . . . . . 16 100 9.3. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . . 17 101 9.4. New Path Setup Type . . . . . . . . . . . . . . . . . . . 17 102 9.5. New Metric Type . . . . . . . . . . . . . . . . . . . . . 17 103 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 17 104 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 105 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 106 12.1. Normative References . . . . . . . . . . . . . . . . . . . 18 107 12.2. Informative References . . . . . . . . . . . . . . . . . . 19 108 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 110 1. Introduction 112 SR technology leverages the source routing and tunneling paradigms. 113 A source node can choose a path without relying on hop-by-hop 114 signaling protocols such as LDP or RSVP-TE. Each path is specified 115 as a set of "segments" advertised by link-state routing protocols 116 (IS-IS or OSPF). [I-D.filsfils-rtgwg-segment-routing] provides an 117 introduction to SR architecture. The corresponding IS-IS and OSPF 118 extensions are specified in 119 [I-D.ietf-isis-segment-routing-extensions] and 120 [I-D.ietf-ospf-segment-routing-extensions], respectively. SR 121 architecture defines a "segment" as a piece of information advertised 122 by a link-state routing protocols, e.g. an IGP prefix or an IGP 123 adjacency. Several types of segments are defined. A Node segment 124 represents an ECMP-aware shortest-path computed by IGP to a specific 125 node, and is always global within SR/IGP domain. An Adjacency 126 Segment represents unidirectional adjacency. An Adjacency Segment is 127 local to the node which advertises it. Both Node segments and 128 Adjacency segments can be used for SR Traffic Engineering (SR-TE). 130 The SR architecture can be applied to the MPLS forwarding plane 131 without any change, in which case an SR path corresponds to an MPLS 132 Label Switching Path (LSP). This document is relevant to only MPLS 133 forwarding plane, and assumes that a 32-bit Segment Identifier (SID) 134 represents an absolute value of MPLS label entry. In this document, 135 "Node-SID" and "Adjacency-SID" denote Node Segment Identifier and 136 Adjacency Segment Identifier respectively. 138 A Segment Routed path (SR path) can be derived from an IGP Shortest 139 Path Tree (SPT). SR-TE paths may not follow IGP SPT. Such paths may 140 be chosen by a suitable network planning tool and provisioned on the 141 source node of the SR-TE path. 143 [RFC5440] describes Path Computation Element Protocol (PCEP) for 144 communication between a Path Computation Client (PCC) and a Path 145 Computation Element (PCE) or between one a pair of PCEs. A PCE or a 146 PCC operating as a PCE (in hierarchical PCE environment) computes 147 paths for MPLS Traffic Engineering LSPs (MPLS-TE LSPs) based on 148 various constraints and optimization criteria. 149 [I-D.ietf-pce-stateful-pce] specifies extensions to PCEP that allow a 150 stateful PCE to compute and recommend network paths in compliance 151 with [RFC4657] and defines objects and TLVs for MPLS-TE LSPs. 152 Stateful PCEP extensions provide synchronization of LSP state between 153 a PCC and a PCE or between a pair of PCEs, delegation of LSP control, 154 reporting of LSP state from a PCC to a PCE, controlling the setup and 155 path routing of an LSP from a PCE to a PCC. Stateful PCEP extensions 156 are intended for an operational model in which LSPs are configured on 157 the PCC, and control over them is delegated to the PCE. 159 A mechanism to dynamically initiate LSPs on a PCC based on the 160 requests from a stateful PCE or a controller using stateful PCE is 161 specified in [I-D.ietf-pce-pce-initiated-lsp]. Such mechanism is 162 useful in Software Driven Networks (SDN) applications, such as demand 163 engineering, or bandwidth calendaring. 165 It is possible to use a stateful PCE for computing one or more SR-TE 166 paths taking into account various constraints and objective 167 functions. Once a path is chosen, the stateful PCE can initiate an 168 SR-TE path on a PCC using PCEP extensions specified in 169 [I-D.ietf-pce-pce-initiated-lsp] using the SR specific PCEP 170 extensions described in this document. Additionally, using 171 procedures described in this document, a PCC can request an SR path 172 from either stateful or a stateless PCE. This specification relies 173 on the PATH-SETUP-TYPE TLV and procedures specified in 174 [I-D.ietf-pce-lsp-setup-type]. 176 2. Terminology 178 The following terminologies are used in this document: 180 ERO: Explicit Route Object 182 IGP: Interior Gateway Protocol 184 IS-IS: Intermediate System to Intermediate System 186 LSR: Label Switching Router 188 MSD: Maximum SID Depth 190 NAI: Node or Adjacency Identifier 192 OSPF: Open Shortest Path First 194 PCC: Path Computation Client 196 PCE: Path Computation Element 198 PCEP: Path Computation Element Protocol 200 RRO: Record Route Object 202 SID: Segment Identifier 203 SR: Segment Routing 205 SR-TE: Segment Routed Traffic Engineering 207 TED: Traffic Engineering Database 209 3. Overview of PCEP Operation in SR Networks 211 In SR networks, an ingress node of an SR path appends all outgoing 212 packets with an SR header consisting of a list of SIDs (or MPLS 213 labels in the context of this document). The header has all 214 necessary information to guide the packets from the ingress node to 215 the egress node of the path, and hence there is no need for any 216 signaling protocol. 218 In a PCEP session, LSP information is carried in the Explicit Route 219 Object (ERO), which consists of a sequence of subobjects. Various 220 types of ERO subobjects have been specified in [RFC3209], [RFC3473], 221 and [RFC3477]. In SR networks, an ingress node of an SR path appends 222 all outgoing packets with an SR header consisting of a list of SIDs 223 (or MPLS labels in the context of this document). SR-TE LSPs 224 computed by a PCE can be represented in one of the following forms: 226 o An ordered set of IP address(es) representing network nodes/links: 227 In this case, the PCC needs to convert the IP address(es) into the 228 corresponding MPLS labels by consulting its Traffic Engineering 229 Database (TED). 231 o An ordered set of SID(s). 233 o An ordered set of both MPLS label(s) and IP address(es): In this 234 case, the PCC needs to convert the IP address(es) into the 235 corresponding SID(s) by consulting its TED. 237 This document defines a new ERO subobject denoted by "SR-ERO 238 subobject" capable of carrying a SID as well as the identity of the 239 node/adjacency represented by the SID. SR-capable PCEP speakers 240 should be able to generate and/or process such ERO subobject. An ERO 241 containing SR-ERO subobjects can be included in the PCEP Path 242 Computation Reply (PCRep) message defined in [RFC5440], the PCEP LSP 243 Initiate Request message (PCInitiate) defined in 244 [I-D.ietf-pce-pce-initiated-lsp], as well as in the PCEP LSP Update 245 Request (PCUpd) and PCEP LSP State Report (PCRpt) messages defined in 246 defined in [I-D.ietf-pce-stateful-pce]. 248 When a PCEP session between a PCC and a PCE is established, both PCEP 249 speakers exchange information to indicate their ability to support 250 SR-specific functionality. Furthermore, an LSP initially established 251 via RSVP-TE signaling can be updated with SR-TE path. This 252 capability is useful when a network is migrated from RSVP-TE to SR-TE 253 technology. Similarly, an LSP initially created with SR-TE path can 254 updated to signal the LSP using RSVP-TE if necessary. 256 A PCC MAY include an RRO object containing the recorded LSP in PCReq 257 and PCRpt messages as specified in [RFC5440] and 258 [I-D.ietf-pce-stateful-pce] respectively. This document defines a 259 new RRO subobject for SR networks. Methods used by a PCC to record 260 SR-TE LSP are outside the scope of this document. 262 In summary, this document: 264 o Defines a new PCEP capability, new ERO subobject, new RRO 265 subobject, a new TLV, and new PCEP error codes. 267 o Specifies how two PCEP speakers can establish a PCEP session that 268 can carry information about SR-TE paths. 270 o Specifies processing rules of ERO subobject. 272 o Defines a new path setup type carried in the PATH-SETUP-TYPE TLV 273 for SR-TE LSP. 275 The extensions specified in this document complement the existing 276 PCEP specifications to support SR-TE path. As such, the PCEP 277 messages (e.g., Path Computation Request, Path Computation Reply, 278 Path Computation Report, Path Computation Update, Path Computation 279 Initiate, etc.,) MUST be formatted according to [RFC5440], 280 [I-D.ietf-pce-stateful-pce], [I-D.ietf-pce-pce-initiated-lsp], and 281 any other applicable PCEP specifications. 283 4. SR-Specific PCEP Message Extensions 285 As defined in [RFC5440], a PCEP message consists of a common header 286 followed by a variable length body made up of mandatory and/or 287 optional objects. This document does not require any changes in the 288 format of PCReq and PCRep messages specified in [RFC5440], PCInitiate 289 message specified in [I-D.ietf-pce-pce-initiated-lsp], and PCRpt and 290 PCUpd messages specified in [I-D.ietf-pce-stateful-pce]. However, 291 PCEP messages pertaining to SR-TE LSP MUST include PATH-SETUP-TYPE 292 TLV in the RP or SRP object to clearly identify that SR-TE LSP is 293 intended. In other words, a PCEP speaker MUST not infer whether or 294 not a PCEP message pertains to SR-TE LSP from any other object or 295 TLV. 297 5. Object Formats 299 5.1. The OPEN Object 301 This document defines a new optional TLV for use in the OPEN Object. 303 5.1.1. The SR PCE Capability TLV 305 The SR-PCE-CAPABILITY TLV is an optional TLV associated with the OPEN 306 Object to exchange SR capability of PCEP speakers. The format of the 307 SR-PCE-CAPABILITY TLV is shown in the following figure: 309 0 1 2 3 310 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 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 | Type=TBD | Length=4 | 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 | Reserved | Flags | MSD | 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 Figure 1: SR-PCE-CAPABILITY TLV format 319 The code point for the TLV type is to be defined by IANA. The TLV 320 length is 4 octets. 322 The 32-bit value is formatted as follows. The "Maximum SID Depth" (1 323 octet) field (MSD) specifies the maximum number of SIDs that a PCC is 324 capable of imposing on a packet. The "Flags" (1 octet) and 325 "Reserved" (2 octets) fields are currently unused, and MUST be set to 326 zero on transmission and ignored on reception. 328 5.1.1.1. Exchanging SR Capability 330 By including the SR-PCE-CAPABILITY TLV in the OPEN message destined 331 to a PCE, a PCC indicates that it is capable of supporting the head- 332 end functions for SR-TE LSP. By including the TLV in the OPEN 333 message destined to a PCC, a PCE indicates that it is capable of 334 computing SR-TE paths. 336 The number of SIDs that can be imposed on a packet depends on PCC's 337 data plane's capability. An MSD value of zero means that a PCC does 338 not impose any default limitation on the number of SIDs included in 339 any SR-TE path coming from PCE. Once an SR-capable PCEP session is 340 established with a non-zero MSD value, the corresponding PCE MUST NOT 341 send SR-TE paths with SIDs exceeding that MSD value. If a PCC needs 342 to modify the MSD value, the PCEP session MUST be closed and re- 343 established with the new MSD value. If a PCEP session is established 344 with a non-zero MSD value, and the PCC receives an SR-TE path 345 containing more SIDs than specified in the MSD value, the PCC MUST 346 send a PCErr message with Error-Type 10 (Reception of an invalid 347 object) and Error-Value 3 (Unsupported number of Segment ERO). If a 348 PCEP session is established with an MSD value of zero, then the PCC 349 MAY specify an MSD for each path computation request that it sends to 350 the PCE. 352 The SR Capability TLV is meaningful only in the OPEN message sent 353 from a PCC to a PCE. As such, a PCE does not need to set MSD value 354 in outbound message to a PCC. Similarly, a PCC ignores any MSD value 355 received from a PCE. If a PCE receives multiple SR-PCE-CAPABILITY 356 TLVs in an OPEN message, it processes only the first TLV is 357 processed. 359 5.2. The RP/SRP Object 361 In order to setup an SR-TE LSP using SR, RP or SRP object MUST PATH- 362 SETUP-TYPE TLV specified in [I-D.ietf-pce-lsp-setup-type]. This 363 document defines a new Path Setup Type (PST) for SR as follows: 365 o PST = 1: Path is setup using Segment Routing Traffic Engineering 366 technique. 368 5.3. ERO Object 370 An SR-TE path consists of one or more SID(s) where each SID MAY be 371 associated with the identifier that represents the node or adjacency 372 corresponding to the SID. This identifier is referred to as the 373 'Node or Adjacency Identifier' (NAI). As described later, a NAI can 374 be represented in various formats (e.g., IPv4 address, IPv6 address, 375 etc). Furthermore, a NAI is used for troubleshooting purposes and, 376 if necessary, to derive SID value as described below. 378 The ERO object specified in [RFC5440] is used to carry SR-TE path 379 information. In order to carry SID and/or NAI, this document defines 380 a new ERO subobject referred to as "SR-ERO subobject" whose format is 381 specified in the following section. An ERO object carrying an SR-TE 382 path consists of one or more ERO subobject(s), and MUST carry only 383 SR-ERO subobject. Note that an SR-ERO subobject does not need to 384 have both SID and NAI. However, at least one of them MUST be 385 present. 387 When building the MPLS label stack from ERO, a PCC MUST assume that 388 SR-ERO subobjects are organized as a last-in-first-out stack. The 389 first subobject relative to the beginning of ERO contains the 390 information about the topmost label. The last subobject contains 391 information about the bottommost label. 393 5.3.1. SR-ERO Subobject 395 An SR-ERO subobject consists of a 32-bit header followed by the SID 396 and the NAI associated with the SID. The SID is a 32-bit number. 397 The size of the NAI depends on its respective type, as described in 398 the following sections. 400 0 1 2 3 401 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 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 |L| Type | Length | ST | Flags |F|S|C|M| 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 | SID | 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 // NAI (variable) // 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 Figure 2: SR-ERO Subobject format 412 The fields in the SR-ERO Subobject are as follows: 414 The 'L' Flag indicates whether the subobject represents a loose-hop 415 in the LSP [RFC3209]. If this flag is unset, a PCC MUST not 416 overwrite the SID value present in the SR-ERO subobject. 417 Otherwise, a PCC MAY expand or replace one or more SID value(s) in 418 the received SR-ERO based on its local policy. 420 Type is the type of the SR-ERO subobject. This document defines the 421 SR-ERO subobject type, and requests a new codepoint from IANA. 423 Length contains the total length of the subobject in octets, 424 including the L, Type and Length fields. Length MUST be at least 425 8, and MUST be a multiple of 4. As mentioned earlier, an SR-ERO 426 subobject MUST have at least SID or NAI. The length should take 427 into consideration SID or NAI only if they are not null. The 428 flags described below used to indicate whether SID or NAI field is 429 null. 431 SID Type (ST) indicates the type of information associated with the 432 SID contained in the object body. The SID-Type values are 433 described later in this document. 435 Flags is used to carry any additional information pertaining to SID. 436 Currently, the following flag bits are defined: 438 * M: When this bit is set, the SID value represents an MPLS label 439 stack entry as specified in [RFC5462] where only the label 440 value is specified by the PCE. Other fields (TC, S, and TTL) 441 fields MUST be considered invalid, and PCC MUST set these 442 fields according to its local policy and MPLS forwarding rules. 444 * C: When this bit as well as the M bit are set, then the SID 445 value represents an MPLS label stack entry as specified in 446 [RFC5462], where all the entry's fields (Label, TC, S, and TTL) 447 are specified by the PCE. However, a PCC MAY choose to 448 override TC, S, and TTL values according its local policy and 449 MPLS forwarding rules. 451 * S: When this bit is set, the SID value in the subobject body is 452 null. In this case, the PCC is responsible for choosing the 453 SID value, e.g., by looking up its TED using the NAI which, in 454 this case, MUST be present in the subobject. 456 * F: When this bit is set, the NAI value in the subobject body is 457 null. 459 Editorial Note: we need to decide how to treat an SR-ERO subobject 460 in which both NAI and SID are null. 462 SID is the Segment Identifier. 464 NAI contains the NAI associated with the SID. Depending on the 465 value of ST, the NAI can have different format as described in the 466 following section. 468 5.3.2. NAI Associated with SID 470 This document defines the following NAIs: 472 'IPv4 Node ID' is specified as an IPv4 address. In this case, ST 473 value is 1, and the Length is 8 or 12 depending on either SID or 474 NAI or both are included in the subobject. 476 'IPv6 Node ID' is specified as an IPv6 address. In this case, ST 477 and Length are 2, and Length is 8, 20, or 24 depending on either 478 SID or NAI or both are included in the subobject. 480 'IPv4 Adjacency' is specified as a pair of IPv4 addresses. In this 481 case, ST value is 3. The Length is 8, 12, or 16 depending on 482 either SID or NAI or both are included in the subobject, and the 483 format of the NAI is shown in the following figure: 485 0 1 2 3 486 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 487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 | Local IPv4 address | 489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 490 | Remote IPv4 address | 491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 493 Figure 3: NAI for IPv4 Adjacency 495 'IPv6 Adjacency' is specified as a pair of IPv6 addresses. In this 496 case, ST valie is 4. The Length is 8, 36 or 40 depending on 497 whether SID or NAI or both included in the subobject,and the 498 format of the NAI is shown in the following figure: 500 0 1 2 3 501 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 502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 503 // Local IPv6 address (16 bytes) // 504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 505 // Remote IPv6 address (16 bytes) // 506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 Figure 4: NAI for IPv6 adjacenc y 510 'Unnumbered Adjacency with IPv4 NodeIDs' is specified as a pair of 511 Node ID / Interface ID tuples. In this case, ST value is 5. The 512 Length is 8, 20, or 24 depending on whether SID or NAI or both 513 included in the subobject, and the format of the NAI is shown in 514 the following figure: 516 0 1 2 3 517 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 518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 519 | Local Node-ID | 520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 521 | Local Interface ID | 522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 523 | Remote Node-ID | 524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 525 | Remote Interface ID | 526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 528 Figure 5: NAI for Unnumbered adjacency with IPv4 Node IDs 530 Editorial Note: We are yet to decide if another SID subobject is 531 required for unnumbered adjacency with 128 bit node ID. 533 5.3.3. ERO Processing 535 A PCEP speaker that does not recognize the SR-ERO subobject in PCRep, 536 PCInitiate, PCUpd or PCRpt messages MUST reject the entire PCEP 537 message and MUST send a PCE error message with Error-Type=3 ("Unknown 538 Object") and Error-Value=2 ("Unrecognized object Type") or Error- 539 Type=4 ("Not supported object") and Error-Value=2 ("Not supported 540 object Type"), defined in [RFC5440]. 542 When the SID represents an MPLS label (i.e. the M bit is set), its 543 value (20 most significant bits) MUST be larger than 15, unless it is 544 special purpose label, such as an Entropy Label Indicator (ELI). If 545 a PCEP speaker receives a label ERO subobject with an invalid value, 546 it MUST send the PCE error message with Error-Type = 10 ("Reception 547 of an invalid object") and Error Value = TBD ("Bad label value"). If 548 both M and C bits of an ERO subobject are set, and if a PCEP speaker 549 finds erroneous setting in one or more of TC, S, and TTL fields, it 550 MUST send a PCE error with Error-Type = 10 ("Reception of an invalid 551 object") and Error-Value = TBD ("Bad label format"). 553 If a PCC receives a stack of SR-ERO subobjects, and the number of 554 stack exceeds the maximum number of SIDs that the PCC can impose on 555 the packet, it MAY send a PCE error with Error-Type = 10 ("Reception 556 of an invalid object") and Error-Value = TBD ("Unsupported number of 557 Segment ERO subobjects"). 559 When a PCEP speaker detects that all subobjects of ERO are not 560 identical, and if it does not handle such ERO, it MUST send PCE error 561 with Error-Type = 10 ("Reception of an invalid object") and Error- 562 Value = TBD ("Non-identical ERO subobjects"). 564 If a PCEP speaker receives an SR-ERO subobject in which both SID and 565 NAI are absent, it MUST consider the entire ERO object invalid and 566 send a PCE error with Error-Type = 10 ("Reception of an invalid 567 object") and Error-Value = TBD ("Both SID and NAI are absent in ERO 568 subobject"). 570 5.4. RRO Object 572 A PCC can record SR-TE LSP and report the LSP to a PCE via RRO. An 573 RRO object contains one or more subobjects called "SR-RRO subobjects" 574 whose format is shown below: 576 0 1 2 3 577 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 578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 579 | Type | Length | ST | Flags |F|S|C|M| 580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 581 | SID | 582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 583 // NAI (variable) // 584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 586 Figure 6: SR-RRO Subobject format 588 The format of SR-RRO subobject is the same as that of SR-ERO 589 subobject without L flag. 591 A PCC MUST assume that SR-RRO subobjects are organized such that the 592 first subobject relative to the beginning of RRO contains the 593 information about the topmost label, and the last subobject contains 594 information about the bottommost label of the SR-TE LSP. 596 5.4.1. RRO Processing 598 Processing rules of SR-RRO subobject are identical to those of SR-ERO 599 subobject. 601 If a PCEP speaker receives an SR-RRO subobject in which both SID and 602 NAI are absent, it MUST consider the entire RRO object invalid and 603 send a PCE error with Error-Type = 10 ("Reception of an invalid 604 object") and Error-Value = TBD ("Both SID and NAI are absent in RRO 605 subobject"). 607 If a PCE detects that all subobjects of RRO are not identical, and if 608 it does not handle such RRO, it MUST send PCE error with Error-Type = 609 10 ("Reception of an invalid object") and Error-Value = TBD ("Non- 610 identical RRO subobjects"). 612 5.5. METRIC Object 614 If a PCEP session is established with an MSD value of zero, then the 615 PCC MAY specify the MSD for an individual path computation request 616 using the METRIC object defined in [RFC5440]. This document defines 617 a new type for the METRIC object to be used for this purpose as 618 follows: 620 o T = TBD (suggested value 11): Maximum SID Depth of the requested 621 path. 623 The PCC sets the metric-value to the MSD for this path. The PCC MUST 624 set the B (bound) bit to 1 in the METRIC object, which specifies that 625 the SID depth for the computed path MUST NOT exceed the metric-value. 627 If a PCEP session is established with a non-zero MSD value, then the 628 PCC MUST NOT send an MSD METRIC object. If the PCE receives a path 629 computation request with an MSD METRIC object on a session with a 630 non-zero MSD value then it MUST consider the request invalid and send 631 a PCErr with Error-Type = 10 ("Reception of an invalid object") and 632 Error-Value TBD ("Default MSD is specified for the PCEP session"). 634 6. Backward Compatibility 636 A PCEP speaker that does not support the SR PCEP capability cannot 637 recognize the SR-ERO or SR-RRO subobjects. As such, it MUST send a 638 PCEP error with Error-Type = 4 (Not supported object) and Error-Value 639 = 2 (Not supported object Type) as per [RFC5440]. 641 7. Management Considerations 643 7.1. Policy 645 PCEP implementation: 647 o Can enable SR PCEP capability either by default or via explicit 648 configuration. 650 o May generate PCEP error due to unsupported number of SR-ERO or SR- 651 RRO subobjects either by default or via explicit configuration. 653 7.2. The PCEP Data Model 655 A PCEP MIB module is defined in [I-D.ietf-pce-pcep-mib] needs be 656 extended to cover additional functionality provided by [RFC5440] and 657 [I-D.ietf-pce-pce-initiated-lsp]. Such extension will cover the new 658 functionality specified in this document. 660 8. Security Considerations 662 The security considerations described in [RFC5440] and 663 [I-D.ietf-pce-pce-initiated-lsp] are applicable to this 664 specification. No additional security measure is required. 666 9. IANA Considerations 668 9.1. PCEP Objects 670 This document defines a new sub-object type for the PCEP explicit 671 route object (ERO), and a new sub-object type for the PCEP record 672 route object (RRO). The code points for sub-object types of these 673 objects is maintained in the RSVP parameters registry, under the 674 EXPLICIT_ROUTE and ROUTE_RECORD objects. IANA is requested to 675 allocate code points in the RSVP Parameters registry for each of the 676 new sub-object types defined in this document, as follows: 678 Object Sub-Object Sub-Object Type 679 --------------------- -------------------------- ------------------ 680 EXPLICIT_ROUTE SR-ERO TBD (recommended 5) 681 ROUTE_RECORD SR-RRO TBD (recommended 6) 683 9.2. PCEP-Error Object 685 IANA is requested to allocate code-points in the PCEP-ERROR Object 686 Error Types and Values registry for the following new error-values: 688 Error-Type Meaning 689 ---------- ------- 690 10 Reception of an invalid object. 691 Error-value = TBD (recommended 2): Bad label value 692 Error-value = TBD (recommended 3): Unsupported number 693 of Segment ERO 694 subobjects 695 Error-value = TBD (recommended 4): Bad label format 696 Error-value = TBD (recommended 5): Non-identical ERO 697 subobjects 698 Error-value = TBD (recommended 6): Both SID and NAI 699 are absent in ERO 700 subobject 702 Error-value = TBD (recommended 7): Both SID and NAI 703 are absent in RRO 704 subobject 705 Error-value = TBD (recommended 8): Non-identical RRO 706 subobjects 707 Error-value = TBD (recommended 9): Default MSD is 708 specified for the 709 PCEP session 711 9.3. PCEP TLV Type Indicators 713 IANA is requested to allocate a new code point in the PCEP TLV Type 714 Indicators registry, as follows: 716 Value Meaning Reference 717 ------------------------- ---------------------------- -------------- 718 TBD (recommended 26) SR-PCE-CAPABILITY This document 720 9.4. New Path Setup Type 722 [I-D.ietf-pce-lsp-setup-type] defines the PATH-SETUP-TYPE TLV and 723 requests that IANA creates a registry to manage the value of the 724 PATH_SETUP_TYPE TLV's PST field. IANA is requested to allocate a new 725 code point in the PCEP PATH_SETUP_TYPE TLV PST field registry, as 726 follows: 728 Value Description Reference 729 ------------------------- ---------------------------- -------------- 730 1 Traffic engineering path is This document 731 setup using Segment Routing 732 technique. 734 9.5. New Metric Type 736 IANA is requested to allocate a new code point in the PCEP METRIC 737 object T field registry, as follows: 739 Value Description Reference 740 ------------------------- ---------------------------- -------------- 741 TBD (recommended 11) Segment-ID (SID) Depth. This document 743 10. Contributors 745 The following people contributed to this document: 746 - Lakshmi Sharma (Cisco Systems) 748 11. Acknowledgements 750 We like to thank Ina Minei, George Swallow, Marek Zavodsky and Tomas 751 Janciga for the valuable comments. 753 12. References 755 12.1. Normative References 757 [I-D.filsfils-rtgwg-segment-routing] 758 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 759 Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., 760 Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe, 761 "Segment Routing Architecture", 762 draft-filsfils-rtgwg-segment-routing-01 (work in 763 progress), October 2013. 765 [I-D.ietf-isis-segment-routing-extensions] 766 Previdi, S., Filsfils, C., Bashandy, A., Gredler, H., 767 Litkowski, S., and J. Tantsura, "IS-IS Extensions for 768 Segment Routing", 769 draft-ietf-isis-segment-routing-extensions-00 (work in 770 progress), April 2014. 772 [I-D.ietf-ospf-segment-routing-extensions] 773 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 774 Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 775 Extensions for Segment Routing", 776 draft-ietf-ospf-segment-routing-extensions-00 (work in 777 progress), June 2014. 779 [I-D.ietf-pce-lsp-setup-type] 780 Sivabalan, S., Medved, J., Minei, I., Crabbe, E., and R. 781 Varga, "Conveying path setup type in PCEP messages", 782 draft-ietf-pce-lsp-setup-type-00 (work in progress), 783 October 2014. 785 [I-D.ietf-pce-pce-initiated-lsp] 786 Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP 787 Extensions for PCE-initiated LSP Setup in a Stateful PCE 788 Model", draft-ietf-pce-pce-initiated-lsp-01 (work in 789 progress), June 2014. 791 [I-D.ietf-pce-pcep-mib] 792 Koushik, K., Stephan, E., Zhao, Q., King, D., and J. 793 Hardwick, "PCE communication protocol (PCEP) Management 794 Information Base", draft-ietf-pce-pcep-mib-04 (work in 795 progress), February 2013. 797 [I-D.ietf-pce-stateful-pce] 798 Crabbe, E., Medved, J., Minei, I., and R. Varga, "PCEP 799 Extensions for Stateful PCE", 800 draft-ietf-pce-stateful-pce-05 (work in progress), 801 July 2013. 803 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 804 Requirement Levels", BCP 14, RFC 2119, March 1997. 806 [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element 807 (PCE) Communication Protocol (PCEP)", RFC 5440, 808 March 2009. 810 [RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching 811 (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic 812 Class" Field", RFC 5462, February 2009. 814 12.2. Informative References 816 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 817 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 818 Tunnels", RFC 3209, December 2001. 820 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 821 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 822 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 824 [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links 825 in Resource ReSerVation Protocol - Traffic Engineering 826 (RSVP-TE)", RFC 3477, January 2003. 828 [RFC4657] Ash, J. and J. Le Roux, "Path Computation Element (PCE) 829 Communication Protocol Generic Requirements", RFC 4657, 830 September 2006. 832 Authors' Addresses 834 Siva Sivabalan 835 Cisco Systems, Inc. 836 2000 Innovation Drive 837 Kanata, Ontario K2K 3E8 838 Canada 840 Email: msiva@cisco.com 841 Jan Medved 842 Cisco Systems, Inc. 843 170 West Tasman Dr. 844 San Jose, CA 95134 845 US 847 Email: jmedved@cisco.com 849 Clarence Filsfils 850 Cisco Systems, Inc. 851 Pegasus Parc 852 De kleetlaan 6a, DIEGEM BRABANT 1831 853 BELGIUM 855 Email: cfilsfil@cisco.com 857 Edward Crabbe 859 Robert Raszuk 860 Mirantis Inc. 861 100-615 National Ave. 862 Mountain View, CA 94043 863 US 865 Email: robert@raszuk.net 867 Victor Lopez 868 Telefonica I+D 869 Don Ramon de la Cruz 82-84 870 Madrid 28045 871 Spain 873 Email: vlopez@tid.es 875 Jeff Tantsura 876 Ericsson 877 300 Holger Way 878 San Jose, CA 95134 879 USA 881 Email: jeff.tantsura@ericsson.com 882 Wim Henderickx 883 Alcatel Lucent 884 Copernicuslaan 50 885 Antwerp 2018, CA 95134 886 BELGIUM 888 Email: wim.henderickx@alcatel-lucent.com 890 Jon Hardwick 891 Metaswitch Networks 892 100 Church Street 893 Enfield, Middlesex 894 UK 896 Email: jon.hardwick@metaswitch.com