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