idnits 2.17.1 draft-ietf-pce-segment-routing-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- 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 436 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 (May 19, 2015) is 3264 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: November 20, 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 May 19, 2015 20 PCEP Extensions for Segment Routing 21 draft-ietf-pce-segment-routing-04.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 November 20, 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 . . . . . . . . . . . . . . . . . . . 16 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 . . . . . . . . . . . . . . . . . . . . . . . . . 18 104 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 105 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 106 12.1. Normative References . . . . . . . . . . . . . . . . . . . 18 107 12.2. Informative References . . . . . . . . . . . . . . . . . . 19 108 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 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. When ST value is 0, SID MUST 433 NOT be null and NAI MUST be null. Other ST values are described 434 later in this document. 436 Flags is used to carry any additional information pertaining to SID. 437 Currently, the following flag bits are defined: 439 * M: When this bit is set, the SID value represents an MPLS label 440 stack entry as specified in [RFC5462] where only the label 441 value is specified by the PCE. Other fields (TC, S, and TTL) 442 fields MUST be considered invalid, and PCC MUST set these 443 fields according to its local policy and MPLS forwarding rules. 445 * C: When this bit as well as the M bit are set, then the SID 446 value represents an MPLS label stack entry as specified in 447 [RFC5462], where all the entry's fields (Label, TC, S, and TTL) 448 are specified by the PCE. However, a PCC MAY choose to 449 override TC, S, and TTL values according its local policy and 450 MPLS forwarding rules. 452 * S: When this bit is set, the SID value in the subobject body is 453 null. In this case, the PCC is responsible for choosing the 454 SID value, e.g., by looking up its TED using the NAI which, in 455 this case, MUST be present in the subobject. 457 * F: When this bit is set, the NAI value in the subobject body is 458 null. 460 SID is the Segment Identifier. 462 NAI contains the NAI associated with the SID. Depending on the 463 value of ST, the NAI can have different format as described in the 464 following section. 466 5.3.2. NAI Associated with SID 468 This document defines the following NAIs: 470 'IPv4 Node ID' is specified as an IPv4 address. In this case, ST 471 value is 1, and the Length is 8 or 12 depending on either SID or 472 NAI or both are included in the subobject. 474 'IPv6 Node ID' is specified as an IPv6 address. In this case, ST 475 and Length are 2, and Length is 8, 20, or 24 depending on either 476 SID or NAI or both are included in the subobject. 478 'IPv4 Adjacency' is specified as a pair of IPv4 addresses. In this 479 case, ST value is 3. The Length is 8, 12, or 16 depending on 480 either SID or NAI or both are included in the subobject, and the 481 format of the NAI is shown in the following figure: 483 0 1 2 3 484 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 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 | Local IPv4 address | 487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 | Remote IPv4 address | 489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 491 Figure 3: NAI for IPv4 Adjacency 493 'IPv6 Adjacency' is specified as a pair of IPv6 addresses. In this 494 case, ST valie is 4. The Length is 8, 36 or 40 depending on 495 whether SID or NAI or both included in the subobject,and the 496 format of the NAI is shown in the following figure: 498 0 1 2 3 499 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 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 501 // Local IPv6 address (16 bytes) // 502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 503 // Remote IPv6 address (16 bytes) // 504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 506 Figure 4: NAI for IPv6 adjacenc y 508 'Unnumbered Adjacency with IPv4 NodeIDs' is specified as a pair of 509 Node ID / Interface ID tuples. In this case, ST value is 5. The 510 Length is 8, 20, or 24 depending on whether SID or NAI or both 511 included in the subobject, and the format of the NAI is shown in 512 the following figure: 514 0 1 2 3 515 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 516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 517 | Local Node-ID | 518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 519 | Local Interface ID | 520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 521 | Remote Node-ID | 522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 523 | Remote Interface ID | 524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 526 Figure 5: NAI for Unnumbered adjacency with IPv4 Node IDs 528 Editorial Note: We are yet to decide if another SID subobject is 529 required for unnumbered adjacency with 128 bit node ID. 531 5.3.3. ERO Processing 533 A PCEP speaker that does not recognize the SR-ERO subobject in PCRep, 534 PCInitiate, PCUpd or PCRpt messages MUST reject the entire PCEP 535 message and MUST send a PCErr message with Error-Type=3 ("Unknown 536 Object") and Error-Value=2 ("Unrecognized object Type") or Error- 537 Type=4 ("Not supported object") and Error-Value=2 ("Not supported 538 object Type"), defined in [RFC5440]. 540 When the SID represents an MPLS label (i.e. the M bit is set), its 541 value (20 most significant bits) MUST be larger than 15, unless it is 542 special purpose label, such as an Entropy Label Indicator (ELI). If 543 a PCEP speaker receives a label ERO subobject with an invalid value, 544 it MUST send a PCErr message with Error-Type = 10 ("Reception of an 545 invalid object") and Error Value = TBD ("Bad label value"). If both 546 M and C bits of an ERO subobject are set, and if a PCEP speaker finds 547 erroneous setting in one or more of TC, S, and TTL fields, it MUST 548 send a PCErr message with Error-Type = 10 ("Reception of an invalid 549 object") and Error-Value = TBD ("Bad label format"). 551 If a PCC receives a stack of SR-ERO subobjects, and the number of 552 stack exceeds the maximum number of SIDs that the PCC can impose on 553 the packet, it MAY send a PCErr message with Error-Type = 10 554 ("Reception of an invalid object") and Error-Value = TBD 555 ("Unsupported number of Segment ERO subobjects"). 557 When a PCEP speaker detects that all subobjects of ERO are not 558 identical, and if it does not handle such ERO, it MUST send a PCErr 559 message with Error-Type = 10 ("Reception of an invalid object") and 560 Error-Value = TBD ("Non-identical ERO subobjects"). 562 If a PCEP speaker receives an SR-ERO subobject in which both SID and 563 NAI are absent, it MUST consider the entire ERO object invalid and 564 send a PCErr message with Error-Type = 10 ("Reception of an invalid 565 object") and Error-Value = TBD ("Both SID and NAI are absent in ERO 566 subobject"). 568 When a PCEP speaker receives an SR-ERO subobject in which ST is 0, 569 SID MUST be present and NAI MUST NOT be present(i.e., S-flag MUST be 570 0, F-flag MUST be 1, and the Length MUST be 8). Otherwise, it MUST 571 consider the entire ERO object invalid and send a PCErr message with 572 Error-Type = 10 ("Reception of an invalid object") and Error-Value = 573 TBD ("Malformed object"). The PCEP speaker MAY include the malformed 574 SR-ERO object in the PCErr message as well. 576 5.4. RRO Object 578 A PCC can record SR-TE LSP and report the LSP to a PCE via RRO. An 579 RRO object contains one or more subobjects called "SR-RRO subobjects" 580 whose format is shown below: 582 0 1 2 3 583 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 584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 585 | Type | Length | ST | Flags |F|S|C|M| 586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 587 | SID | 588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 589 // NAI (variable) // 590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 592 Figure 6: SR-RRO Subobject format 594 The format of SR-RRO subobject is the same as that of SR-ERO 595 subobject without L flag. 597 A PCC MUST assume that SR-RRO subobjects are organized such that the 598 first subobject relative to the beginning of RRO contains the 599 information about the topmost label, and the last subobject contains 600 information about the bottommost label of the SR-TE LSP. 602 5.4.1. RRO Processing 604 Processing rules of SR-RRO subobject are identical to those of SR-ERO 605 subobject. 607 If a PCEP speaker receives an SR-RRO subobject in which both SID and 608 NAI are absent, it MUST consider the entire RRO object invalid and 609 send a PCErr message with Error-Type = 10 ("Reception of an invalid 610 object") and Error-Value = TBD ("Both SID and NAI are absent in RRO 611 subobject"). 613 If a PCE detects that all subobjects of RRO are not identical, and if 614 it does not handle such RRO, it MUST send a PCErr message with Error- 615 Type = 10 ("Reception of an invalid object") and Error-Value = TBD 616 ("Non-identical RRO subobjects"). 618 5.5. METRIC Object 620 If a PCEP session is established with an MSD value of zero, then the 621 PCC MAY specify the MSD for an individual path computation request 622 using the METRIC object defined in [RFC5440]. This document defines 623 a new type for the METRIC object to be used for this purpose as 624 follows: 626 o T = TBD (suggested value 11): Maximum SID Depth of the requested 627 path. 629 The PCC sets the metric-value to the MSD for this path. The PCC MUST 630 set the B (bound) bit to 1 in the METRIC object, which specifies that 631 the SID depth for the computed path MUST NOT exceed the metric-value. 633 If a PCEP session is established with a non-zero MSD value, then the 634 PCC MUST NOT send an MSD METRIC object. If the PCE receives a path 635 computation request with an MSD METRIC object on a session with a 636 non-zero MSD value then it MUST consider the request invalid and send 637 a PCErr with Error-Type = 10 ("Reception of an invalid object") and 638 Error-Value TBD ("Default MSD is specified for the PCEP session"). 640 6. Backward Compatibility 642 A PCEP speaker that does not support the SR PCEP capability cannot 643 recognize the SR-ERO or SR-RRO subobjects. As such, it MUST send a 644 PCEP error with Error-Type = 4 (Not supported object) and Error-Value 645 = 2 (Not supported object Type) as per [RFC5440]. 647 7. Management Considerations 649 7.1. Policy 651 PCEP implementation: 653 o Can enable SR PCEP capability either by default or via explicit 654 configuration. 656 o May generate PCEP error due to unsupported number of SR-ERO or SR- 657 RRO subobjects either by default or via explicit configuration. 659 7.2. The PCEP Data Model 661 A PCEP MIB module is defined in [I-D.ietf-pce-pcep-mib] needs be 662 extended to cover additional functionality provided by [RFC5440] and 663 [I-D.ietf-pce-pce-initiated-lsp]. Such extension will cover the new 664 functionality specified in this document. 666 8. Security Considerations 668 The security considerations described in [RFC5440] and 669 [I-D.ietf-pce-pce-initiated-lsp] are applicable to this 670 specification. No additional security measure is required. 672 9. IANA Considerations 674 9.1. PCEP Objects 676 This document defines a new sub-object type for the PCEP explicit 677 route object (ERO), and a new sub-object type for the PCEP record 678 route object (RRO). The code points for sub-object types of these 679 objects is maintained in the RSVP parameters registry, under the 680 EXPLICIT_ROUTE and ROUTE_RECORD objects. IANA is requested to 681 allocate code points in the RSVP Parameters registry for each of the 682 new sub-object types defined in this document, as follows: 684 Object Sub-Object Sub-Object Type 685 --------------------- -------------------------- ------------------ 686 EXPLICIT_ROUTE SR-ERO TBD (recommended 5) 687 ROUTE_RECORD SR-RRO TBD (recommended 6) 689 9.2. PCEP-Error Object 691 IANA is requested to allocate code-points in the PCEP-ERROR Object 692 Error Types and Values registry for the following new error-values: 694 Error-Type Meaning 695 ---------- ------- 696 10 Reception of an invalid object. 697 Error-value = TBD (recommended 2): Bad label value 698 Error-value = TBD (recommended 3): Unsupported number 699 of Segment ERO 700 subobjects 701 Error-value = TBD (recommended 4): Bad label format 702 Error-value = TBD (recommended 5): Non-identical ERO 703 subobjects 704 Error-value = TBD (recommended 6): Both SID and NAI 705 are absent in ERO 706 subobject 707 Error-value = TBD (recommended 7): Both SID and NAI 708 are absent in RRO 709 subobject 710 Error-value = TBD (recommended 9): Default MSD is 711 specified for the 712 PCEP session 713 Error-value = TBD (recommended 10): Non-identical RRO 714 subobjects 715 Error-value = TBD (recommended 11): Malformed object 717 9.3. PCEP TLV Type Indicators 719 IANA is requested to allocate a new code point in the PCEP TLV Type 720 Indicators registry, as follows: 722 Value Meaning Reference 723 ------------------------- ---------------------------- -------------- 724 TBD (recommended 26) SR-PCE-CAPABILITY This document 726 9.4. New Path Setup Type 728 [I-D.ietf-pce-lsp-setup-type] defines the PATH-SETUP-TYPE TLV and 729 requests that IANA creates a registry to manage the value of the 730 PATH_SETUP_TYPE TLV's PST field. IANA is requested to allocate a new 731 code point in the PCEP PATH_SETUP_TYPE TLV PST field registry, as 732 follows: 734 Value Description Reference 735 ------------------------- ---------------------------- -------------- 736 1 Traffic engineering path is This document 737 setup using Segment Routing 738 technique. 740 9.5. New Metric Type 742 IANA is requested to allocate a new code point in the PCEP METRIC 743 object T field registry, as follows: 745 Value Description Reference 746 ------------------------- ---------------------------- -------------- 747 TBD (recommended 11) Segment-ID (SID) Depth. This document 749 10. Contributors 751 The following people contributed to this document: 752 - Lakshmi Sharma (Cisco Systems) 754 11. Acknowledgements 756 We like to thank Ina Minei, George Swallow, Marek Zavodsky and Tomas 757 Janciga for the valuable comments. 759 12. References 761 12.1. Normative References 763 [I-D.filsfils-rtgwg-segment-routing] 764 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 765 Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., 766 Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe, 767 "Segment Routing Architecture", 768 draft-filsfils-rtgwg-segment-routing-01 (work in 769 progress), October 2013. 771 [I-D.ietf-isis-segment-routing-extensions] 772 Previdi, S., Filsfils, C., Bashandy, A., Gredler, H., 773 Litkowski, S., and J. Tantsura, "IS-IS Extensions for 774 Segment Routing", 775 draft-ietf-isis-segment-routing-extensions-00 (work in 776 progress), April 2014. 778 [I-D.ietf-ospf-segment-routing-extensions] 779 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 780 Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 781 Extensions for Segment Routing", 782 draft-ietf-ospf-segment-routing-extensions-00 (work in 783 progress), June 2014. 785 [I-D.ietf-pce-lsp-setup-type] 786 Sivabalan, S., Medved, J., Minei, I., Crabbe, E., and R. 787 Varga, "Conveying path setup type in PCEP messages", 788 draft-ietf-pce-lsp-setup-type-00 (work in progress), 789 October 2014. 791 [I-D.ietf-pce-pce-initiated-lsp] 792 Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP 793 Extensions for PCE-initiated LSP Setup in a Stateful PCE 794 Model", draft-ietf-pce-pce-initiated-lsp-01 (work in 795 progress), June 2014. 797 [I-D.ietf-pce-pcep-mib] 798 Koushik, K., Stephan, E., Zhao, Q., King, D., and J. 799 Hardwick, "PCE communication protocol (PCEP) Management 800 Information Base", draft-ietf-pce-pcep-mib-04 (work in 801 progress), February 2013. 803 [I-D.ietf-pce-stateful-pce] 804 Crabbe, E., Medved, J., Minei, I., and R. Varga, "PCEP 805 Extensions for Stateful PCE", 806 draft-ietf-pce-stateful-pce-05 (work in progress), 807 July 2013. 809 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 810 Requirement Levels", BCP 14, RFC 2119, March 1997. 812 [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element 813 (PCE) Communication Protocol (PCEP)", RFC 5440, 814 March 2009. 816 [RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching 817 (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic 818 Class" Field", RFC 5462, February 2009. 820 12.2. Informative References 822 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 823 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 824 Tunnels", RFC 3209, December 2001. 826 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 827 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 828 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 830 [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links 831 in Resource ReSerVation Protocol - Traffic Engineering 832 (RSVP-TE)", RFC 3477, January 2003. 834 [RFC4657] Ash, J. and J. Le Roux, "Path Computation Element (PCE) 835 Communication Protocol Generic Requirements", RFC 4657, 836 September 2006. 838 Authors' Addresses 840 Siva Sivabalan 841 Cisco Systems, Inc. 842 2000 Innovation Drive 843 Kanata, Ontario K2K 3E8 844 Canada 846 Email: msiva@cisco.com 848 Jan Medved 849 Cisco Systems, Inc. 850 170 West Tasman Dr. 851 San Jose, CA 95134 852 US 854 Email: jmedved@cisco.com 856 Clarence Filsfils 857 Cisco Systems, Inc. 858 Pegasus Parc 859 De kleetlaan 6a, DIEGEM BRABANT 1831 860 BELGIUM 862 Email: cfilsfil@cisco.com 864 Edward Crabbe 866 Robert Raszuk 867 Mirantis Inc. 868 100-615 National Ave. 869 Mountain View, CA 94043 870 US 872 Email: robert@raszuk.net 873 Victor Lopez 874 Telefonica I+D 875 Don Ramon de la Cruz 82-84 876 Madrid 28045 877 Spain 879 Email: vlopez@tid.es 881 Jeff Tantsura 882 Ericsson 883 300 Holger Way 884 San Jose, CA 95134 885 USA 887 Email: jeff.tantsura@ericsson.com 889 Wim Henderickx 890 Alcatel Lucent 891 Copernicuslaan 50 892 Antwerp 2018, CA 95134 893 BELGIUM 895 Email: wim.henderickx@alcatel-lucent.com 897 Jon Hardwick 898 Metaswitch Networks 899 100 Church Street 900 Enfield, Middlesex 901 UK 903 Email: jon.hardwick@metaswitch.com