idnits 2.17.1 draft-ietf-pce-segment-routing-01.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 407 has weird spacing: '...L' Flag indic...' == Line 413 has weird spacing: '... Type is th...' == Line 416 has weird spacing: '... Length conta...' == Line 428 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 (March 9, 2015) is 3336 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: September 10, 2015 Cisco Systems, Inc. 6 R. Raszuk 7 Mirantis Inc. 8 V. Lopez 9 Telefonica I+D 10 J. Tantsura 11 Ericsson 12 W. Henderickx 13 Alcatel Lucent 14 E. Crabbe 15 March 9, 2015 17 PCEP Extensions for Segment Routing 18 draft-ietf-pce-segment-routing-01.txt 20 Abstract 22 Segment Routing (SR) enables any head-end node to select any path 23 without relying on a hop-by-hop signaling technique (e.g., LDP or 24 RSVP-TE). It depends only on "segments" that are advertised by Link- 25 State Interior Gateway Protocols (IGPs). A Segment Routed Path can 26 be derived from a variety of mechanisms, including an IGP Shortest 27 Path Tree (SPT), explicit configuration, or a Path Computation 28 Element (PCE). This document specifies extensions to the Path 29 Computation Element Protocol (PCEP) that allow a stateful PCE to 30 compute and initiate Traffic Engineering (TE) paths, as well as a PCC 31 to request a path subject to certain constraint(s) and optimization 32 criteria in SR networks. 34 Requirements Language 36 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 37 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 38 document are to be interpreted as described in [RFC2119]. 40 Status of This Memo 42 This Internet-Draft is submitted in full conformance with the 43 provisions of BCP 78 and BCP 79. 45 Internet-Drafts are working documents of the Internet Engineering 46 Task Force (IETF). Note that other groups may also distribute 47 working documents as Internet-Drafts. The list of current Internet- 48 Drafts is at http://datatracker.ietf.org/drafts/current/. 50 Internet-Drafts are draft documents valid for a maximum of six months 51 and may be updated, replaced, or obsoleted by other documents at any 52 time. It is inappropriate to use Internet-Drafts as reference 53 material or to cite them other than as "work in progress." 55 This Internet-Draft will expire on September 10, 2015. 57 Copyright Notice 59 Copyright (c) 2015 IETF Trust and the persons identified as the 60 document authors. All rights reserved. 62 This document is subject to BCP 78 and the IETF Trust's Legal 63 Provisions Relating to IETF Documents 64 (http://trustee.ietf.org/license-info) in effect on the date of 65 publication of this document. Please review these documents 66 carefully, as they describe your rights and restrictions with respect 67 to this document. Code Components extracted from this document must 68 include Simplified BSD License text as described in Section 4.e of 69 the Trust Legal Provisions and are provided without warranty as 70 described in the Simplified BSD License. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 75 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 76 3. Overview of PCEP Operation in SR Networks . . . . . . . . . . 5 77 4. SR-Specific PCEP Message Extensions . . . . . . . . . . . . . 6 78 5. Object Formats . . . . . . . . . . . . . . . . . . . . . . . 7 79 5.1. The OPEN Object . . . . . . . . . . . . . . . . . . . . . 7 80 5.1.1. The SR PCE Capability TLV . . . . . . . . . . . . . . 7 81 5.2. The RP/SRP Object . . . . . . . . . . . . . . . . . . . . 8 82 5.3. ERO Object . . . . . . . . . . . . . . . . . . . . . . . 8 83 5.3.1. SR-ERO Subobject . . . . . . . . . . . . . . . . . . 9 84 5.3.2. NAI Associated with SID . . . . . . . . . . . . . . . 10 85 5.3.3. ERO Processing . . . . . . . . . . . . . . . . . . . 12 86 5.4. RRO Object . . . . . . . . . . . . . . . . . . . . . . . 13 87 5.4.1. RRO Processing . . . . . . . . . . . . . . . . . . . 13 88 6. Backward Compatibility . . . . . . . . . . . . . . . . . . . 14 89 7. Management Considerations . . . . . . . . . . . . . . . . . . 14 90 7.1. Policy . . . . . . . . . . . . . . . . . . . . . . . . . 14 91 7.2. The PCEP Data Model . . . . . . . . . . . . . . . . . . . 14 92 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 93 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 94 9.1. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . 14 95 9.2. PCEP-Error Object . . . . . . . . . . . . . . . . . . . . 14 96 9.3. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 15 97 9.4. New Path Setup Type . . . . . . . . . . . . . . . . . . . 15 99 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 15 100 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 101 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 102 12.1. Normative References . . . . . . . . . . . . . . . . . . 16 103 12.2. Informative References . . . . . . . . . . . . . . . . . 17 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 106 1. Introduction 108 SR technology leverages the source routing and tunneling paradigms. 109 A source node can choose a path without relying on hop-by-hop 110 signaling protocols such as LDP or RSVP-TE. Each path is specified 111 as a set of "segments" advertised by link-state routing protocols 112 (IS-IS or OSPF). [I-D.filsfils-rtgwg-segment-routing] provides an 113 introduction to SR architecture. The corresponding IS-IS and OSPF 114 extensions are specified in 115 [I-D.ietf-isis-segment-routing-extensions] and 116 [I-D.ietf-ospf-segment-routing-extensions], respectively. SR 117 architecture defines a "segment" as a piece of information advertised 118 by a link-state routing protocols, e.g. an IGP prefix or an IGP 119 adjacency. Several types of segments are defined. A Node segment 120 represents an ECMP-aware shortest-path computed by IGP to a specific 121 node, and is always global within SR/IGP domain. An Adjacency 122 Segment represents unidirectional adjacency. An Adjacency Segment is 123 local to the node which advertises it. Both Node segments and 124 Adjacency segments can be used for SR Traffic Engineering (SR-TE). 126 The SR architecture can be applied to the MPLS forwarding plane 127 without any change, in which case an SR path corresponds to an MPLS 128 Label Switching Path (LSP). This document is relevant to only MPLS 129 forwarding plane, and assumes that a 32-bit Segment Identifier (SID) 130 represents an absolute value of MPLS label entry. In this document, 131 "Node-SID" and "Adjacency-SID" denote Node Segment Identifier and 132 Adjacency Segment Identifier respectively. 134 A Segment Routed path (SR path) can be derived from an IGP Shortest 135 Path Tree (SPT). SR-TE paths may not follow IGP SPT. Such paths may 136 be chosen by a suitable network planning tool and provisioned on the 137 source node of the SR-TE path. 139 [RFC5440] describes Path Computation Element Protocol (PCEP) for 140 communication between a Path Computation Client (PCC) and a Path 141 Computation Element (PCE) or between one a pair of PCEs. A PCE or a 142 PCC operating as a PCE (in hierarchical PCE environment) computes 143 paths for MPLS Traffic Engineering LSPs (MPLS-TE LSPs) based on 144 various constraints and optimization criteria. 145 [I-D.ietf-pce-stateful-pce] specifies extensions to PCEP that allow a 146 stateful PCE to compute and recommend network paths in compliance 147 with [RFC4657] and defines objects and TLVs for MPLS-TE LSPs. 148 Stateful PCEP extensions provide synchronization of LSP state between 149 a PCC and a PCE or between a pair of PCEs, delegation of LSP control, 150 reporting of LSP state from a PCC to a PCE, controlling the setup and 151 path routing of an LSP from a PCE to a PCC. Stateful PCEP extensions 152 are intended for an operational model in which LSPs are configured on 153 the PCC, and control over them is delegated to the PCE. 155 A mechanism to dynamically initiate LSPs on a PCC based on the 156 requests from a stateful PCE or a controller using stateful PCE is 157 specified in [I-D.ietf-pce-pce-initiated-lsp]. Such mechanism is 158 useful in Software Driven Networks (SDN) applications, such as demand 159 engineering, or bandwidth calendaring. 161 It is possible to use a stateful PCE for computing one or more SR-TE 162 paths taking into account various constraints and objective 163 functions. Once a path is chosen, the stateful PCE can initiate an 164 SR-TE path on a PCC using PCEP extensions specified in 165 [I-D.ietf-pce-pce-initiated-lsp] using the SR specific PCEP 166 extensions described in this document. Additionally, using 167 procedures described in this document, a PCC can request an SR path 168 from either stateful or a stateless PCE. This specification relies 169 on the PATH-SETUP-TYPE TLV and procedures specified in 170 [I-D.ietf-pce-lsp-setup-type]. 172 2. Terminology 174 The following terminologies are used in this document: 176 ERO: Explicit Route Object 178 IGP: Interior Gateway Protocol 180 IS-IS: Intermediate System to Intermediate System 182 LSR: Label Switching Router 184 MSD: Maximum SID Depth 186 NAI: Node or Adjacency Identifier 188 OSPF: Open Shortest Path First 190 PCC: Path Computation Client 192 PCE: Path Computation Element 194 PCEP: Path Computation Element Protocol 195 RRO: Record Route Object 197 SID: Segment Identifier 199 SR: Segment Routing 201 SR-TE: Segment Routed Traffic Engineering 203 TED: Traffic Engineering Database 205 3. Overview of PCEP Operation in SR Networks 207 In SR networks, an ingress node of an SR path appends all outgoing 208 packets with an SR header consisting of a list of SIDs (or MPLS 209 labels in the context of this document). The header has all 210 necessary information to guide the packets from the ingress node to 211 the egress node of the path, and hence there is no need for any 212 signaling protocol. 214 In a PCEP session, LSP information is carried in the Explicit Route 215 Object (ERO), which consists of a sequence of subobjects. Various 216 types of ERO subobjects have been specified in [RFC3209], [RFC3473], 217 and [RFC3477]. In SR networks, an ingress node of an SR path appends 218 all outgoing packets with an SR header consisting of a list of SIDs 219 (or MPLS labels in the context of this document). SR-TE LSPs 220 computed by a PCE can be represented in one of the following forms: 222 o An ordered set of IP address(es) representing network nodes/links: 223 In this case, the PCC needs to convert the IP address(es) into the 224 corresponding MPLS labels by consulting its Traffic Engineering 225 Database (TED). 227 o An ordered set of SID(s). 229 o An ordered set of both MPLS label(s) and IP address(es): In this 230 case, the PCC needs to convert the IP address(es) into the 231 corresponding SID(s) by consulting its TED. 233 This document defines a new ERO subobject denoted by "SR-ERO 234 subobject" capable of carrying a SID as well as the identity of the 235 node/adjacency represented by the SID. SR-capable PCEP speakers 236 should be able to generate and/or process such ERO subobject. An ERO 237 containing SR-ERO subobjects can be included in the PCEP Path 238 Computation Reply (PCRep) message defined in [RFC5440], the PCEP LSP 239 Initiate Request message (PCInitiate) defined in 240 [I-D.ietf-pce-pce-initiated-lsp], as well as in the PCEP LSP Update 241 Request (PCUpd) and PCEP LSP State Report (PCRpt) messages defined in 242 defined in [I-D.ietf-pce-stateful-pce]. 244 When a PCEP session between a PCC and a PCE is established, both PCEP 245 speakers exchange information to indicate their ability to support 246 SR-specific functionality. Furthermore, an LSP initially established 247 via RSVP-TE signaling can be updated with SR-TE path. This 248 capability is useful when a network is migrated from RSVP-TE to SR-TE 249 technology. Similarly, an LSP initially created with SR-TE path can 250 updated to signal the LSP using RSVP-TE if necessary. 252 A PCC MAY include an RRO object containing the recorded LSP in PCReq 253 and PCRpt messages as specified in [RFC5440] and 254 [I-D.ietf-pce-stateful-pce] respectively. This document defines a 255 new RRO subobject for SR networks. Methods used by a PCC to record 256 SR-TE LSP are outside the scope of this document. 258 In summary, this document: 260 o Defines a new PCEP capability, new ERO subobject, new RRO 261 subobject, a new TLV, and new PCEP error codes. 263 o Specifies how two PCEP speakers can establish a PCEP session that 264 can carry information about SR-TE paths. 266 o Specifies processing rules of ERO subobject. 268 o Defines a new path setup type carried in the PATH-SETUP-TYPE TLV 269 for SR-TE LSP. 271 The extensions specified in this document complement the existing 272 PCEP specifications to support SR-TE path. As such, the PCEP 273 messages (e.g., Path Computation Request, Path Computation Reply, 274 Path Computation Report, Path Computation Update, Path Computation 275 Initiate, etc.,) MUST be formatted according to [RFC5440], 276 [I-D.ietf-pce-stateful-pce], [I-D.ietf-pce-pce-initiated-lsp], and 277 any other applicable PCEP specifications. 279 4. SR-Specific PCEP Message Extensions 281 As defined in [RFC5440], a PCEP message consists of a common header 282 followed by a variable length body made up of mandatory and/or 283 optional objects. This document does not require any changes in the 284 format of PCReq and PCRep messages specified in [RFC5440], PCInitiate 285 message specified in [I-D.ietf-pce-pce-initiated-lsp], and PCRpt and 286 PCUpd messages specified in [I-D.ietf-pce-stateful-pce]. However, 287 PCEP messages pertaining to SR-TE LSP MUST include PATH-SETUP-TYPE 288 TLV in the RP or SRP object to clearly identify that SR-TE LSP is 289 intended. In other words, a PCEP speaker MUST not infer whether or 290 not a PCEP message pertains to SR-TE LSP from any other object or 291 TLV. 293 5. Object Formats 295 5.1. The OPEN Object 297 This document defines a new optional TLV for use in the OPEN Object. 299 5.1.1. The SR PCE Capability TLV 301 The SR-PCE-CAPABILITY TLV is an optional TLV associated with the OPEN 302 Object to exchange SR capability of PCEP speakers. The format of the 303 SR-PCE-CAPABILITY TLV is shown in the following figure: 305 0 1 2 3 306 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 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 | Type=TBD | Length=4 | 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 | Reserved | Flags | MSD | 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 Figure 1: SR-PCE-CAPABILITY TLV format 315 The code point for the TLV type is to be defined by IANA. The TLV 316 length is 4 octets. 318 The 32-bit value is formatted as follows. The "Maximum SID Depth" (1 319 octet) field (MSD) specifies the maximum number of SIDs that a PCC is 320 capable of imposing on a packet. The "Flags" (1 octet) and 321 "Reserved" (2 octets) fields are currently unused, and MUST be set to 322 zero on transmission and ignored on reception. 324 5.1.1.1. Exchanging SR Capability 326 By including the SR-PCE-CAPABILITY TLV in the OPEN message destined 327 to a PCE, a PCC indicates that it is capable of supporting the head- 328 end functions for SR-TE LSP. By including the TLV in the OPEN 329 message destined to a PCC, a PCE indicates that it is capable of 330 computing SR-TE paths. 332 The number of SIDs that can be imposed on a packet depends on PCC's 333 data plane's capability. The default value of MSD is 0 meaning that 334 a PCC does not impose any limitation on the number of SIDs included 335 in any SR-TE path coming from PCE. Once an SR-capable PCEP session 336 is established with a non-default MSD value, the corresponding PCE 337 cannot send SR-TE paths with SIDs exceeding that MSD value. If a PCC 338 needs to modify the MSD value, the PCEP session MUST be closed and 339 re-established with the new MSD value. If a PCEP session is 340 established with a non-default MSD value, and the PCC receives an SR- 341 TE path containing more SIDs than specified in the MSD value, the PCC 342 MUST send a PCErr message with Error-Type 10 (Reception of an invalid 343 object) and Error-value 3 (Unsupported number of Segment ERO). 345 The SR Capability TLV is meaningful only in the OPEN message sent 346 from a PCC to a PCE. As such, a PCE does not need to set MSD value 347 in outbound message to a PCC. Similarly, a PCC ignores any MSD value 348 received from a PCE. If a PCE receives multiple SR-PCE-CAPABILITY 349 TLVs in an OPEN message, it processes only the first TLV is 350 processed. 352 5.2. The RP/SRP Object 354 In order to setup an SR-TE LSP using SR, RP or SRP object MUST PATH- 355 SETUP-TYPE TLV specified in [I-D.ietf-pce-lsp-setup-type]. This 356 document defines a new Path Setup Type (PST) for SR as follows: 358 o PST = 1: Path is setup using Segment Routing Traffic Engineering 359 technique. 361 5.3. ERO Object 363 An SR-TE path consists of one or more SID(s) where each SID MAY be 364 associated with the identifier that represents the node or adjacency 365 corresponding to the SID. This identifier is referred to as the 366 'Node or Adjacency Identifier' (NAI). As described later, a NAI can 367 be represented in various formats (e.g., IPv4 address, IPv6 address, 368 etc). Furthermore, a NAI is used for troubleshooting purposes and, 369 if necessary, to derive SID value as described below. 371 The ERO object specified in [RFC5440] is used to carry SR-TE path 372 information. In order to carry SID and/or NAI, this document defines 373 a new ERO subobject referred to as "SR-ERO subobject" whose format is 374 specified in the following section. An ERO object carrying an SR-TE 375 path consists of one or more ERO subobject(s), and MUST carry only 376 SR-ERO subobject. Note that an SR-ERO subobject does not need to 377 have both SID and NAI. However, at least one of them MUST be 378 present. 380 When building the MPLS label stack from ERO, a PCC MUST assume that 381 SR-ERO subobjects are organized as a last-in-first-out stack. The 382 first subobject relative to the beginning of ERO contains the 383 information about the topmost label. The last subobject contains 384 information about the bottommost label. 386 5.3.1. SR-ERO Subobject 388 An SR-ERO subobject consists of a 32-bit header followed by the SID 389 and the NAI associated with the SID. The SID is a 32-bit number. 390 The size of the NAI depends on its respective type, as described in 391 the following sections. 393 0 1 2 3 394 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 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 |L| Type | Length | ST | Flags |F|S|C|M| 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 | SID | 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 // NAI (variable) // 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 Figure 2: SR-ERO Subobject format 405 The fields in the SR-ERO Subobject are as follows: 407 The 'L' Flag indicates whether the subobject represents a loose-hop 408 in the LSP [RFC3209]. If this flag is unset, a PCC MUST not 409 overwrite the SID value present in the SR-ERO subobject. 410 Otherwise, a PCC MAY expand or replace one or more SID value(s) in 411 the received SR-ERO based on its local policy. 413 Type is the type of the SR-ERO subobject. This document defines the 414 SR-ERO subobject type, and requests a new codepoint from IANA. 416 Length contains the total length of the subobject in octets, 417 including the L, Type and Length fields. Length MUST be at least 418 8, and MUST be a multiple of 4. As mentioned earlier, an SR-ERO 419 subobject MUST have at least SID or NAI. The length should take 420 into consideration SID or NAI only if they are not null. The 421 flags described below used to indicate whether SID or NAI field is 422 null. 424 SID Type (ST) indicates the type of information associated with the 425 SID contained in the object body. The SID-Type values are 426 described later in this document. 428 Flags is used to carry any additional information pertaining to SID. 429 Currently, the following flag bits are defined: 431 * M: When this bit is set, the SID value represents an MPLS label 432 stack entry as specified in [RFC5462] where only the label 433 value is specified by the PCE. Other fields (TC, S, and TTL) 434 fields MUST be considered invalid, and PCC MUST set these 435 fields according to its local policy and MPLS forwarding rules. 437 * C: When this bit as well as the M bit are set, then the SID 438 value represents an MPLS label stack entry as specified in 439 [RFC5462], where all the entry's fields (Label, TC, S, and TTL) 440 are specified by the PCE. However, a PCC MAY choose to 441 override TC, S, and TTL values according its local policy and 442 MPLS forwarding rules. 444 * S: When this bit is set, the SID value in the subobject body is 445 null. In this case, the PCC is responsible for choosing the 446 SID value, e.g., by looking up its TED using the NAI which, in 447 this case, MUST be present in the subobject. 449 * F: When this bit is set, the NAI value in the subobject body is 450 null. 452 Editorial Note: we need to decide how to treat an SR-ERO subobject 453 in which both NAI and SID are null. 455 SID is the Segment Identifier. 457 NAI contains the NAI associated with the SID. Depending on the 458 value of ST, the NAI can have different format as described in the 459 following section. 461 5.3.2. NAI Associated with SID 463 This document defines the following NAIs: 465 'IPv4 Node ID' is specified as an IPv4 address. In this case, ST 466 value is 1, and the Length is 8 or 12 depending on either SID or 467 NAI or both are included in the subobject. 469 'IPv6 Node ID' is specified as an IPv6 address. In this case, ST 470 and Length are 2, and Length is 8, 20, or 24 depending on either 471 SID or NAI or both are included in the subobject. 473 'IPv4 Adjacency' is specified as a pair of IPv4 addresses. In this 474 case, ST value is 3. The Length is 8, 12, or 16 depending on 475 either SID or NAI or both are included in the subobject, and the 476 format of the NAI is shown in the following figure: 478 0 1 2 3 479 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 480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 481 | Local IPv4 address | 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 | Remote IPv4 address | 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 Figure 3: NAI for IPv4 Adjacency 488 'IPv6 Adjacency' is specified as a pair of IPv6 addresses. In this 489 case, ST valie is 4. The Length is 8, 36 or 40 depending on 490 whether SID or NAI or both included in the subobject,and the 491 format of the NAI is shown in the following figure: 493 0 1 2 3 494 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 495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 496 // Local IPv6 address (16 bytes) // 497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 498 // Remote IPv6 address (16 bytes) // 499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 501 Figure 4: NAI for IPv6 adjacenc y 503 'Unnumbered Adjacency with IPv4 NodeIDs' is specified as a pair of 504 Node ID / Interface ID tuples. In this case, ST value is 5. The 505 Length is 8, 20, or 24 depending on whether SID or NAI or both 506 included in the subobject, and the format of the NAI is shown in 507 the following figure: 509 0 1 2 3 510 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 511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 512 | Local Node-ID | 513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 514 | Local Interface ID | 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 | Remote Node-ID | 517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 518 | Remote Interface ID | 519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 521 Figure 5: NAI for Unnumbered adjacency with IPv4 Node IDs 523 Editorial Note: We are yet to decide if another SID subobject is 524 required for unnumbered adjacency with 128 bit node ID. 526 5.3.3. ERO Processing 528 A PCEP speaker that does not recognize the SR-ERO subobject in PCRep, 529 PCInitiate, PCUpd or PCRpt messages MUST reject the entire PCEP 530 message and MUST send a PCE error message with Error-Type=3 ("Unknown 531 Object") and Error-Value=2 ("Unrecognized object Type") or Error- 532 Type=4 ("Not supported object") and Error-Value=2 ("Not supported 533 object Type"), defined in [RFC5440]. 535 When the SID represents an MPLS label (i.e. the M bit is set), its 536 value (20 most significant bits) MUST be larger than 15, unless it is 537 special purpose label, such as an Entropy Label Indicator (ELI). If 538 a PCEP speaker receives a label ERO subobject with an invalid value, 539 it MUST send the PCE error message with Error-Type = 10 ("Reception 540 of an invalid object") and Error Value = TBD ("Bad label value"). If 541 both M and C bits of an ERO subobject are set, and if a PCEP speaker 542 finds erroneous setting in one or more of TC, S, and TTL fields, it 543 MUST send a PCE error with Error-Type = 10 ("Reception of an invalid 544 object") and Error-Value = TBD ("Bad label format"). 546 If a PCC receives a stack of SR-ERO subobjects, and the number of 547 stack exceeds the maximum number of SIDs that the PCC can impose on 548 the packet, it MAY send a PCE error with Error-Type = 10 ("Reception 549 of an invalid object") and Error-Value = TBD ("Unsupported number of 550 Segment ERO subobjects"). 552 When a PCEP speaker detects that all subobjects of ERO are not 553 identical, and if it does not handle such ERO, it MUST send PCE error 554 with Error-Type = 10 ("Reception of an invalid object") and Error- 555 Value = TBD ("Non-identical ERO subobjects"). 557 If a PCEP speaker receives an SR-ERO subobject in which both SID and 558 NAI are absent, it MUST consider the entire ERO object invalid and 559 send a PCE error with Error-Type = 10 ("Reception of an invalid 560 object") and Error-Value = TBD ("Both SID and NAI are absent in ERO 561 subobject"). 563 5.4. RRO Object 565 A PCC can record SR-TE LSP and report the LSP to a PCE via RRO. An 566 RRO object contains one or more subobjects called "SR-RRO subobjects" 567 whose format is shown below: 569 0 1 2 3 570 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 571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 572 | Type | Length | ST | Flags |F|S|C|M| 573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 574 | SID | 575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 576 // NAI (variable) // 577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 579 Figure 6: SR-RRO Subobject format 581 The format of SR-RRO subobject is the same as that of SR-ERO 582 subobject without L flag. 584 A PCC MUST assume that SR-RRO subobjects are organized such that the 585 first subobject relative to the beginning of RRO contains the 586 information about the topmost label, and the last subobject contains 587 information about the bottommost label of the SR-TE LSP. 589 5.4.1. RRO Processing 591 Processing rules of SR-RRO subobject are identical to those of SR-ERO 592 subobject. 594 If a PCEP speaker receives an SR-RRO subobject in which both SID and 595 NAI are absent, it MUST consider the entire RRO object invalid and 596 send a PCE error with Error-Type = 10 ("Reception of an invalid 597 object") and Error-Value = TBD ("Both SID and NAI are absent in RRO 598 subobject"). 600 If a PCE detects that all subobjects of RRO are not identical, and if 601 it does not handle such RRO, it MUST send PCE error with Error-Type = 602 10 ("Reception of an invalid object") and Error-Value = TBD ("Non- 603 identical RRO subobjects"). 605 6. Backward Compatibility 607 A PCEP speaker that does not support the SR PCEP capability cannot 608 recognize the SR-ERO or SR-RRO subobjects. As such, it MUST send a 609 PCEP error with Error-Type = 4 (Not supported object) and Error-Value 610 = 2 (Not supported object Type) as per [RFC5440]. 612 7. Management Considerations 614 7.1. Policy 616 PCEP implementation: 618 o Can enable SR PCEP capability either by default or via explicit 619 configuration. 621 o May generate PCEP error due to unsupported number of SR-ERO or SR- 622 RRO subobjects either by default or via explicit configuration. 624 7.2. The PCEP Data Model 626 A PCEP MIB module is defined in [I-D.ietf-pce-pcep-mib] needs be 627 extended to cover additional functionality provided by [RFC5440] and 628 [I-D.ietf-pce-pce-initiated-lsp]. Such extension will cover the new 629 functionality specified in this document. 631 8. Security Considerations 633 The security considerations described in [RFC5440] and 634 [I-D.ietf-pce-pce-initiated-lsp] are applicable to this 635 specification. No additional security measure is required. 637 9. IANA Considerations 639 9.1. PCEP Objects 641 IANA is requested to allocate a new ERO subobject and a new RRO 642 subobject types (recommended values = 5 and 6 respectively). 644 9.2. PCEP-Error Object 646 This document defines new Error-Type and Error-Value for the 647 following new conditions: 649 Error-Type Meaning 650 10 Reception of an invalid object. 652 Error-value=2: Bad label value. 653 Error-value=3: Unsupported number of Segment ERO 654 subobjects. 655 Error-value=4: Bad label format. 656 Error-value=5: Non-identical ERO subobjects. 657 Error-value=6: Both SID and NAI are absent in ERO 658 subobject. 659 Error-value=7: Both SID and NAI are absent in RRO 660 subobject. 661 Error-value=8: Non-identical RRO subobjects. 663 9.3. PCEP TLV Type Indicators 665 This document defines the following new PCEP TLVs: 667 Value Meaning Reference 668 -------- ------------------------------------ ----------------- 669 26 SR-PCE-CAPABILITY This document 671 9.4. New Path Setup Type 673 This document defines a new setup type for the PATH-SETUP-TYPE TLV as 674 follows: 676 Value Description Reference 678 1 Traffic engineering This document 679 path is setup using 680 Segment Routing 681 technique. 683 10. Contributors 685 The following people contributed to this document: 687 - Lakshmi Sharma (Cisco Systems) 689 11. Acknowledgements 691 We like to thank Ina Minei, George Swallow, Marek Zavodsky and Tomas 692 Janciga for the valuable comments. 694 12. References 695 12.1. Normative References 697 [I-D.filsfils-rtgwg-segment-routing] 698 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 699 Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., 700 Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe, 701 "Segment Routing Architecture", draft-filsfils-rtgwg- 702 segment-routing-01 (work in progress), October 2013. 704 [I-D.ietf-isis-segment-routing-extensions] 705 Previdi, S., Filsfils, C., Bashandy, A., Gredler, H., 706 Litkowski, S., and J. Tantsura, "IS-IS Extensions for 707 Segment Routing", draft-ietf-isis-segment-routing- 708 extensions-00 (work in progress), April 2014. 710 [I-D.ietf-ospf-segment-routing-extensions] 711 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 712 Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 713 Extensions for Segment Routing", draft-ietf-ospf-segment- 714 routing-extensions-00 (work in progress), June 2014. 716 [I-D.ietf-pce-lsp-setup-type] 717 Sivabalan, S., Medved, J., Minei, I., Crabbe, E., and R. 718 Varga, "Conveying path setup type in PCEP messages", 719 draft-ietf-pce-lsp-setup-type-00 (work in progress), 720 October 2014. 722 [I-D.ietf-pce-pce-initiated-lsp] 723 Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP 724 Extensions for PCE-initiated LSP Setup in a Stateful PCE 725 Model", draft-ietf-pce-pce-initiated-lsp-01 (work in 726 progress), June 2014. 728 [I-D.ietf-pce-pcep-mib] 729 Koushik, K., Stephan, E., Zhao, Q., King, D., and J. 730 Hardwick, "PCE communication protocol (PCEP) Management 731 Information Base", draft-ietf-pce-pcep-mib-04 (work in 732 progress), February 2013. 734 [I-D.ietf-pce-stateful-pce] 735 Crabbe, E., Medved, J., Minei, I., and R. Varga, "PCEP 736 Extensions for Stateful PCE", draft-ietf-pce-stateful- 737 pce-05 (work in progress), July 2013. 739 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 740 Requirement Levels", BCP 14, RFC 2119, March 1997. 742 [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element 743 (PCE) Communication Protocol (PCEP)", RFC 5440, March 744 2009. 746 [RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching 747 (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic 748 Class" Field", RFC 5462, February 2009. 750 12.2. Informative References 752 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 753 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 754 Tunnels", RFC 3209, December 2001. 756 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 757 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 758 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 760 [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links 761 in Resource ReSerVation Protocol - Traffic Engineering 762 (RSVP-TE)", RFC 3477, January 2003. 764 [RFC4657] Ash, J. and J. Le Roux, "Path Computation Element (PCE) 765 Communication Protocol Generic Requirements", RFC 4657, 766 September 2006. 768 Authors' Addresses 770 Siva Sivabalan 771 Cisco Systems, Inc. 772 2000 Innovation Drive 773 Kanata, Ontario K2K 3E8 774 Canada 776 Email: msiva@cisco.com 778 Jan Medved 779 Cisco Systems, Inc. 780 170 West Tasman Dr. 781 San Jose, CA 95134 782 US 784 Email: jmedved@cisco.com 785 Clarence Filsfils 786 Cisco Systems, Inc. 787 Pegasus Parc 788 De kleetlaan 6a, DIEGEM BRABANT 1831 789 BELGIUM 791 Email: cfilsfil@cisco.com 793 Robert Raszuk 794 Mirantis Inc. 795 100-615 National Ave. 796 Mountain View, CA 94043 797 US 799 Email: robert@raszuk.net 801 Victor Lopez 802 Telefonica I+D 803 Don Ramon de la Cruz 82-84 804 Madrid 28045 805 Spain 807 Email: vlopez@tid.es 809 Jeff Tantsura 810 Ericsson 811 300 Holger Way 812 San Jose, CA 95134 813 USA 815 Email: jeff.tantsura@ericsson.com 817 Wim Henderickx 818 Alcatel Lucent 819 Copernicuslaan 50 820 Antwerp 2018, CA 95134 821 BELGIUM 823 Email: wim.henderickx@alcatel-lucent.com 825 Edward Crabbe