idnits 2.17.1 draft-sivabalan-pce-segment-routing-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 475 has weird spacing: '...L' Flag indic...' == Line 481 has weird spacing: '... Type is th...' == Line 485 has weird spacing: '... Length conta...' == Line 493 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: An SR-TE path consists of one or more SID(s) where each SID is associated with the identifier that represents the node or adjacency corresponding to the SID. This identifier is referred to as the 'Node or Adjacency Identifier' (NAI). As described later, a NAI can be represented in various formats (e.g., IPv4 address, IPv6 address, etc). Furthermore, a NAI is used only for troubleshooting purposes, and MUST not be used to replace or modify any fields in a data packet header. An SR-ERO object consists of one or more ERO subobjects described in the following section. Also, all subobjects within an SR-ERO MUST be of the SR-ERO subobject type. == 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 explicit route [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 (October 16, 2013) is 3844 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 (-03) exists of draft-crabbe-pce-pce-initiated-lsp-01 == Outdated reference: A later version (-01) exists of draft-filsfils-rtgwg-segment-routing-00 == 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 (-05) exists of draft-previdi-isis-segment-routing-extensions-01 == Outdated reference: A later version (-05) exists of draft-psenak-ospf-segment-routing-extensions-01 == Outdated reference: A later version (-02) exists of draft-sivabalan-pce-lsp-setup-type-00 Summary: 0 errors (**), 0 flaws (~~), 14 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: April 19, 2014 Cisco Systems, Inc. 6 E. Crabbe 7 Google, Inc. 8 R. Raszuk 9 NTT I3 10 October 16, 2013 12 PCEP Extensions for Segment Routing 13 draft-sivabalan-pce-segment-routing-02.txt 15 Abstract 17 Segment Routing (SR) enables any head-end node to select any path 18 without relying on a hop-by-hop signaling technique (e.g., LDP or 19 RSVP-TE). It depends only on "segments" that are advertised by Link- 20 State Interior Gateway Protocols (IGPs). A Segment Routed Path can 21 be derived from a variety of mechanisms, including an IGP Shortest 22 Path Tree (SPT), explicit configuration, or a Path Computation 23 Element (PCE). This document specifies extensions to the Path 24 Computation Element Protocol (PCEP) that allow a stateful PCE to 25 compute and instantiate Traffic Engineering paths, as well as a PCC 26 to request a path subject to certain constraint(s) and optimization 27 criteria in SR networks. 29 Requirements Language 31 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 32 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 33 document are to be interpreted as described in [RFC2119]. 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at http://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on April 19, 2014. 51 Copyright Notice 53 Copyright (c) 2013 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 69 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 3. Overview of PCEP Operation in SR Networks . . . . . . . . . . 5 71 4. SR-Specific PCEP Message Extensions . . . . . . . . . . . . . 6 72 4.1. The PCReq Message . . . . . . . . . . . . . . . . . . . . 6 73 4.2. The PCRep Message . . . . . . . . . . . . . . . . . . . . 6 74 4.3. The PCInitiate Message . . . . . . . . . . . . . . . . . 7 75 4.4. The PCRpt Message . . . . . . . . . . . . . . . . . . . . 7 76 4.5. The PCUpd Message . . . . . . . . . . . . . . . . . . . . 8 77 5. Object Formats . . . . . . . . . . . . . . . . . . . . . . . 8 78 5.1. The OPEN Object . . . . . . . . . . . . . . . . . . . . . 8 79 5.1.1. The SR PCE Capability TLV . . . . . . . . . . . . . . 8 80 5.2. The RP/SRP Object . . . . . . . . . . . . . . . . . . . . 10 81 5.3. The SR-ERO Object . . . . . . . . . . . . . . . . . . . . 10 82 5.3.1. The SR-ERO Subobject . . . . . . . . . . . . . . . . 10 83 5.3.2. NAI Associated with SID . . . . . . . . . . . . . . . 12 84 5.3.3. SR-ERO Processing . . . . . . . . . . . . . . . . . . 13 85 6. Backward Compatibility . . . . . . . . . . . . . . . . . . . 14 86 7. Management Considerations . . . . . . . . . . . . . . . . . . 14 87 7.1. Policy . . . . . . . . . . . . . . . . . . . . . . . . . 14 88 7.2. The PCEP Data Model . . . . . . . . . . . . . . . . . . . 14 89 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 90 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 91 9.1. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . 15 92 9.2. PCEP-Error Object . . . . . . . . . . . . . . . . . . . . 15 93 9.3. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 15 94 9.4. New Path Setup Type . . . . . . . . . . . . . . . . . . . 15 95 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 15 96 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 97 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 98 12.1. Normative References . . . . . . . . . . . . . . . . . . 16 99 12.2. Informative References . . . . . . . . . . . . . . . . . 17 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 102 1. Introduction 104 SR technology leverages the source routing and tunneling paradigms. 105 A source node can choose a path without relying on hop-by-hop 106 signaling protocols such as LDP or RSVP-TE. Each path is specified 107 as a set of "segments" advertised by link-state routing protocols 108 (IS-IS or OSPF). [I-D.filsfils-rtgwg-segment-routing] provides an 109 introduction to SR technology. The corresponding IS-IS and OSPF 110 extensions are specified in 111 [I-D.previdi-isis-segment-routing-extensions] and 112 [I-D.psenak-ospf-segment-routing-extensions], respectively. Two 113 types of segments have been defined; nodal and adjacency segments. A 114 nodal segment represents a path to a node, whereas an adjacency 115 segment represents a specific adjacency to a node. The SR 116 architecture can be applied to the MPLS forwarding plane without any 117 change, as well as to the IPv6 forwarding plane with a new type of 118 routing extension header. A Segment Identifier (SID) is a 32-bit 119 value. In the case of the MPLS data plane, an SR path corresponds to 120 an MPLS Label Switching Path (LSP) 122 A Segment Routed path (SR path) can be derived from an IGP Shortest 123 Path Tree (SPT). Segment Routed Traffic Engineering paths (SR-TE 124 paths) may not follow IGP SPT. Such paths may be chosen by a 125 suitable network planning tool and provisioned on the source node of 126 the SR-TE path. 128 [RFC5440] describes Path Computation Element Protocol (PCEP) for 129 communication between a Path Computation Client (PCC) and a Path 130 Control Element (PCE) or between one a pair of PCEs. A PCE computes 131 paths for MPLS Traffic Engineering LSPs (MPLS-TE LSPs) based on 132 various constraints and optimization criteria. 133 [I-D.ietf-pce-stateful-pce] specifies extensions to PCEP that allow a 134 stateful PCE to compute and recommend network paths in compliance 135 with [RFC4657] and defines objects and TLVs for MPLS-TE LSPs. 136 Stateful PCEP extensions provide synchronization of LSP state between 137 a PCC and a PCE or between a pair of PCEs, delegation of LSP control, 138 reporting of LSP state from a PCC to a PCE, controlling the setup and 139 path routing of an LSP from a PCE to a PCC. Stateful PCEP extensions 140 are intended for an operational model in which LSPs are configured on 141 the PCC, and control over them is delegated to the PCE. 143 A mechanism to dynamically instantiate LSPs on a PCC based on the 144 requests from a stateful PCE or a controller using stateful PCE is 145 specified in [I-D.crabbe-pce-pce-initiated-lsp]. Such mechanism is 146 useful in Software Driven Networks (SDN) applications, such as demand 147 engineering, or bandwidth calendaring. 149 It is possible to use a stateful PCE for computing one or more SR-TE 150 paths taking into account various constraints and objective 151 functions. Once a path is chosen, the stateful PCE can instantiate 152 an SR-TE path on a PCC using PCEP extensions specified in 153 [I-D.crabbe-pce-pce-initiated-lsp] using the SR specific PCEP 154 extensions described in this document. Additionally, using 155 procedures described in this document, a PCC can request an SR path 156 from either stateful or a stateless PCE. This specification uses the 157 PATH-SETUP-TYPE TLV and procedures specified in 158 [I-D.sivabalan-pce-lsp-setup-type]. 160 2. Terminology 162 The following terminologies are used in this document: 164 ERO: Explicit Route Object 166 IGP: Interior Gateway Protocol 168 IS-IS: Intermediate System to Intermediate System 170 LSR: Label Switching Router 172 MSD: Maximum SID Depth 174 NAI: Node or Adjacency Identifier 176 OSPF: Open Shortest Path First 178 PCC: Path Computation Client 180 PCE: Path Computation Element 182 PCEP: Path Computation Element Protocol 184 RRO: Record Route Object 186 SID: Segment Identifier 188 SR: Segment Routing 190 SR-ERO: Segment Routed Explicit Route Object 192 SR Path: Segment Routed Path 193 SR-RRO: Segment Routed Record Route Object 195 SR-TE: Segment Routed Traffic Engineering 197 3. Overview of PCEP Operation in SR Networks 199 In SR networks, an ingress node of an SR path appends all outgoing 200 packets with an SR header consisting of a list of Segment IDs (SIDs). 201 The header has all necessary information to guide the packets from 202 the ingress node to the egress node of the path, and hence there is 203 no need for any signaling protocol. A SID can represent a nodal 204 segment representing a path to a node or adjacency segment 205 representing path over a specific adjacency. 207 In a PCEP session, path information is carried in the Explicit Route 208 Object (ERO), which consists of a sequence of subobjects. Various 209 types of ERO subobjects have been specified in [RFC3209], [RFC3473], 210 and [RFC3477]. In SR networks, a PCE needs to specify EROs 211 containing SIDs (denoted as SR-EROs in this document), and a PCC 212 needs to be capable of processing such EROs. An SR-ERO can be 213 included in the Path Computation LSP Initiate Request message 214 (PCInitiate) defined in [I-D.crabbe-pce-pce-initiated-lsp], as well 215 as in the Path Computation LSP Update Request (PCUpd) and Path 216 Computation LSP State Report (PCRpt) messages defined in Report 217 (PCRpt) messages defined in [I-D.ietf-pce-stateful-pce]. 219 When a PCEP session between a PCC and a PCE is established, both PCEP 220 Speakers exchange information to indicate their ability to support 221 SR-specific functionality. This document does not preclude a PCEP 222 message from containing different ERO types. However, each subobject 223 within an SR-ERO MUST represent an SID. Furthermore, an LSP 224 initially established using RSVP-TE can be updated using SR-ERO. 225 This capability is useful when a network is migrated from RSVP-TE to 226 SR technology. Similarly, an LSP initially established using SR-ERO 227 can updated to signal the LSP using RSVP-TE if necessary. 229 A PCC MAY include an ERO object in a PCRpt message. In SR networks, 230 a PCC MAY learn the SR path actually taken by data packets and report 231 that path to a PCE. Methods used by a PCC to learn SR-TE paths are 232 outside the scope of this document. 234 In summary, this document: 236 o Defines a new PCEP capability, new subobjects, a new TLV, and new 237 PCEP error codes. 239 o Specifies how two PCEP Speakers can establish a PCEP session that 240 can carry SR-TE paths. 242 o Defines the formats of SR-specific PCEP messages in Backus-Naur 243 Format (BNF). 245 This document specifies SR extensions for the stateless PCE model 246 defined in [RFC5440], as well as for the active stateful and passive 247 stateful PCE models defined in [I-D.ietf-pce-stateful-pce]. 249 4. SR-Specific PCEP Message Extensions 251 As defined in [RFC5440], a PCEP message consists of a common header 252 followed by a variable length body made up of mandatory and/or 253 optional objects. PCEP messages an their formats for stateless PCE 254 are defined in [RFC5440]. PCEP messages and their formats for 255 stateful PCE are defined in [I-D.ietf-pce-stateful-pce]. PCEP 256 messages and their formats for PCE-initiated LSP instantiation are 257 defined in [I-D.crabbe-pce-pce-initiated-lsp]. 259 This document defines changes to PCEP messages and their formats 260 required to carry SR-specific information. 262 4.1. The PCReq Message 264 This document does not specify any changes to the PCReq message 265 format. This document requires the PATH-SETUP-TYPE TLV to be carried 266 in the RP Object in order for a PCC to request SR-TE paths. 268 4.2. The PCRep Message 270 This document defines the format of the PCRep message carrying SR-TE 271 paths. The message is sent by a PCE to a PCC in response to a 272 previously received PCReq message, where the PCC requested SR TE 273 path. The format of the SR-specific PCRep message is as follows: 275 ::= 276 277 Where: 279 ::=[] 281 ::= 282 [] 283 [] 285 Where: 286 ::=[] 288 The RP and NO-PATH Objects are defined in [RFC5440]. The 289 object contains the SR-TE path and is defined in Section 5.3. 291 4.3. The PCInitiate Message 293 The format of the PCInitiate message is as follows: 295 ::= 296 297 Where: 299 ::= 300 [] 302 ::= 303 304 [] 306 The object in the Common Header MUST include the SYMBOLIC-PATH- 307 NAME TLV. The message MAY contain an object containing 308 subobjects defining the SR-TE path as defined in Section 5.3. 310 4.4. The PCRpt Message 312 An SR-specific PCRpt message is sent by a PCC to a PCE to report the 313 current state of an SR-TE Path. A PCRpt message can carry more than 314 one LSP State Report, but all LSP State reports in the SR-Specific 315 PCRpt message MUST be for SR TE Paths. A PCC can send an LSP State 316 Report either in response to an LSP Update Request from a PCE, or 317 asynchronously when the state of an SR-TE Path changes. 319 The format of the SR-specific PCRpt message is as follows: 321 ::= 322 323 Where: 325 ::= [] 327 ::= 328 329 331 Where: 332 ::= 334 The object contains the actual SR-TE path used by the PCC 335 and is defined in Section 5.3. The actual SR-TE Path may be 336 different from the programmed SR-TE Path, for example, when the 337 latter contains loose hops and the PCC must compute the path between 338 loose hops locally. 340 The and objects are defined in 341 [I-D.ietf-pce-stateful-pce]. The object MUST include the 342 SYMBOLIC-PATH-NAME TLV. 344 4.5. The PCUpd Message 346 An SR-Specific PCUpd message is sent by a PCE to a PCC to update an 347 SR-TE Path. A PCUpd message can carry more than one LSP Update 348 Request. 350 The format of the SR-specific PCUpd message is as follows: 352 ::= 353 354 Where: 356 ::= [] 358 ::= 359 360 361 Where: 362 ::= 364 The object contains the SR-TE path computed by the PCE, and 365 is defined in Section 5.3. The and objects are defined 366 in [I-D.ietf-pce-stateful-pce]. The LSP object MUST include the 367 SYMBOLIC-PATH-NAME TLV. Note that unlike the RSVP-TE specific PCUpd 368 message defined in [I-D.ietf-pce-stateful-pce], the path in the SR- 369 specific PCUpd message does not have attributes - only hops specified 370 in the object. 372 5. Object Formats 374 5.1. The OPEN Object 376 This document defines a new optional TLV for use in the OPEN Object. 378 5.1.1. The SR PCE Capability TLV 379 The SR-PCE-CAPABILITY TLV is an optional TLV for use in the OPEN 380 Object to negotiate Segment Routing capability on the PCEP session. 381 The format of the SR-PCE-CAPABILITY TLV is shown in the following 382 figure: 384 0 1 2 3 385 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 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 | Type=TBD | Length=4 | 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 | Reserved | Flags | MSD | 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 Figure 1: SR-PCE-CAPABILITY TLV format 394 The code point for the TLV type is to be defined by IANA. The TLV 395 length is 4 octets. 397 The 32-bit value is formatted as follows. The "Maximum SID Depth" (1 398 octet) field (MSD) specifies the maximum number of SIDs that a PCC is 399 capable of imposing on a packet. The "Flags" (1 octet) and 400 "Reserved" (2 octets) fields are currently unused, and MUST be set to 401 zero and ignored on receipt. 403 5.1.1.1. Negotiating SR Capability 405 The SR capability TLV is contained in the OPEN object. By including 406 the TLV in the OPEN message to a PCE, a PCC indicates its support for 407 SR-TE Paths. By including the TLV in the OPEN message to a PCC, a 408 PCE indicates that it is capable of computing SR-TE paths. 410 The number of SIDs that can be imposed on a packet depends on PCC's 411 data plane's capability. The default value of MSD is 0 meaning that 412 a PCC does not impose any limitation on the number of SIDs included 413 in any SR-TE path coming from PCE. Once an SR-capable PCEP session 414 is established with a non-default MSD value, the corresponding PCE 415 cannot send SR-TE paths with SIDs exceeding the MSD value. If a PCC 416 needs to modify the MSD value, the PCEP session must be closed and 417 re-established with the new MSD value. If a PCEP session is 418 established with a non-default MSD value, and the PCC receives an SR- 419 TE path containing more SIDs than specified in the MSD value, the PCC 420 MUST send out a PCErr message with Error-Type 10 (Reception of an 421 invalid object) and Error-value 3 (Unsupported number of Segment 422 ERO). 424 The SR Capability TLV is meaningful only in the OPEN message sent 425 from a PCC to a PCE. As such, a PCE does not need to set MSD value 426 in outbound message to a PCC. Similarly, an MSD value received by a 427 PCC is ignored. If there are multiple SR capability TLVs, only the 428 first TLV is processed. 430 All bits in the Reserved and Flags fields SHOULD be set to 0 on 431 outbound OPEN messages, and MUST be ignored on inbound OPEN messages. 433 5.2. The RP/SRP Object 435 In order to setup an LSP using SR, RP or SRP object may carry PATH- 436 SETUP-TYPE TLV specified in [I-D.sivabalan-pce-lsp-setup-type]. This 437 document defines a new Path Setup Type (PST) for SR as follows: 439 o PST = 1: Path is setup using Segment Routing technique. 441 5.3. The SR-ERO Object 443 An SR-TE path consists of one or more SID(s) where each SID is 444 associated with the identifier that represents the node or adjacency 445 corresponding to the SID. This identifier is referred to as the 446 'Node or Adjacency Identifier' (NAI). As described later, a NAI can 447 be represented in various formats (e.g., IPv4 address, IPv6 address, 448 etc). Furthermore, a NAI is used only for troubleshooting purposes, 449 and MUST not be used to replace or modify any fields in a data packet 450 header. An SR-ERO object consists of one or more ERO subobjects 451 described in the following section. Also, all subobjects within an 452 SR-ERO MUST be of the SR-ERO subobject type. 454 5.3.1. The SR-ERO Subobject 456 An SR-ERO subobject consists of a 32-bit header followed by the SID 457 and the NAI associated with the SID. The SID is a 32-bit number. 458 The size of the NAI depends on its respective type, as described in 459 the following sections. 461 0 1 2 3 462 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 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 |L| Type | Length | ST | Flags |F|S|C|M| 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 | SID | 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 468 // NAI (variable) // 469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 471 Figure 2: SR-ERO Subobject format 473 The fields in the ERO Subobject are as follows: 475 The 'L' Flag indicates whether the subobject represents a loose-hop 476 in the explicit route [RFC3209]. If this flag is unset, a PCC 477 MUST not overwrite the SID value present in the SR-ERO subobject. 478 Otherwise, a PCC MAY expand or replace one or more SID value(s) in 479 the received SR-ERO based on its local policy. 481 Type is the type of the SR-ERO Subobject. This document defines the 482 SR-ERO Subobject type. A new code point will be requested for the 483 SR-ERO Subobject from IANA. 485 Length contains the total length of the subobject in octets, 486 including the L, Type and Length fields. Length MUST be at least 487 4, and MUST be a multiple of 4. 489 SID Type (ST) indicates the type of information associated with the 490 SID contained in the object body. The SID-Type values are 491 described later in this document. 493 Flags is used to carry any additional information pertaining to SID. 494 Currently, the following flag bits are defined: 496 * M: When this bit is set, the SID value represents an MPLS label 497 stack entry as specified in [RFC5462] where only the label 498 value is specified by the PCE. Other fields (TC, S, and TTL) 499 fields MUST be considered invalid, and PCC MUST set these 500 fields according to its local policy and MPLS forwarding rules. 502 * C: When this bit as well as the M bit are set, then the SID 503 value represents an MPLS label stack entry as specified in 504 [RFC5462], where all the entry's fields (Label, TC, S, and TTL) 505 are specified by the PCE. However, a PCC MAY choose to 506 override TC, S, and TTL values according its local policy and 507 MPLS forwarding rules. 509 * S: When this bit is set, the SID value in the subobject body is 510 null. In this case, the PCC is responsible for choosing the 511 SID value, e.g., by looking up its Traffic Engineering Database 512 (TED) using node/adjacency identifier in the subobject body. 514 * F: When this bit is set, the NAI value in the subobject body is 515 null. 517 SID is the Segment Identifier. 519 NAI contains the NAI associated with the SID. Depending on the 520 value of ST, the NAI can have different format as described in the 521 following section. 523 5.3.2. NAI Associated with SID 525 This document defines the following NAIs: 527 'IPv4 Node ID' is specified as an IPv4 address. In this case, ST 528 and Length are 1 and 12 respectively. 530 'IPv6 Node ID' is specified as an IPv6 address. In this case, ST 531 and Length are 2 and 24 respectively. 533 'IPv4 Adjacency' is specified as a pair of IPv4 addresses. In this 534 case, ST and Length are 3 and 16, respectively, and the format of 535 the NAI is shown in the following figure: 537 0 1 2 3 538 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 539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 540 | Local IPv4 address | 541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 542 | Remote IPv4 address | 543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 545 Figure 3: NAI for IPv4 Adjacency 547 'IPv6 Adjacency' is specified as a pair of IPv6 addresses. In this 548 case, ST and Length are 4 and 40 respectively, and the format of 549 the NAI is shown in the following figure: 551 0 1 2 3 552 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 553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 554 // Local IPv6 address (16 bytes) // 555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 556 // Remote IPv6 address (16 bytes) // 557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 559 Figure 4: NAI for IPv6 adjacency 561 'Unnumbered Adjacency with IPv4 NodeIDs' is specified as a pair of 562 Node ID / Interface ID tuples. In this case, ST and Length are 5 563 and 24 respectively, and the format of the NAI is shown in the 564 following figure: 566 0 1 2 3 567 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 568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 569 | Local Node-ID | 570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 571 | Local Interface ID | 572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 573 | Remote Node-ID | 574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 575 | Remote Interface ID | 576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 578 Figure 5: NAI for Unnumbered adjacency with IPv4 Node IDs 580 We are yet to decide if another SID subobject is required for 581 unnumbered adjacency with 128 bit node ID. 583 5.3.3. SR-ERO Processing 585 A PCEP Speaker that does not recognize the new ERO subobject in the 586 PCCreate, PCUpd or PCRpt message MUST reject the entire PCEP message 587 and MUST send a PCE error message with Error-Type=3 ("Unknown 588 Object") and Error-Value=2 ("Unrecognized object Type") or Error- 589 Type=4 ("Not supported object") and Error-Value=2 ("Not supported 590 object Type"), defined in [RFC5440]. 592 When the SID represents an MPLS label (i.e. the M bit is set), its 593 value (20 most significant bits) MUST be larger than 15, unless it is 594 special purpose label, such as an Entropy Label Indicator (ELI) or an 595 Entropy Label (EL). If a PCEP Speaker receives a label ERO subobject 596 with an invalid value, it MUST send the PCE error message with Error- 597 Type = "Reception of an invalid object" and Error-Value = "Bad label 598 value". If both M and C bits of an ERO subobject are set, and if a 599 PCEP Speaker finds erroneous setting in one or more of TC, S, and TTL 600 fields, it MUST send a PCE error with Error-Type = "Reception of an 601 invalid object" and Error-Value = "Bad label format". 603 If a PCC receives a stack of SR-ERO subobjects, and the number of 604 stack exceeds the maximum number of SIDs that the PCC can impose on 605 the packet, it MAY send a PCE error with Error-Type = "Reception of 606 an invalid object" and Error-Value = "Unsupported number of Segment 607 ERO subobjects". 609 When a PCEP speaker detects that all subobjects of SR-ERO are not 610 identical, it MUST send PCE error with Error-Type = "Reception of an 611 invalid object" and Error-Value = "Non-identical ERO subobjects" and 612 close the PCEP session. 614 6. Backward Compatibility 616 An LSR that does not support the SR PCEP capability negotiation 617 cannot recognize the SR-ERO subobjects. As such, it shall send a 618 PCEP error with Error-Type = 4 (Not supported object) and Error-Value 619 = 2 (Not supported object Type) as per [RFC5440]. 621 7. Management Considerations 623 7.1. Policy 625 PCEP implementation: 627 o Can enable SR-PCEP capability either by default or via explicit 628 configuration. 630 o May generate PCEP error due to unsupported number of SR-ERO 631 subobjects either by default or via explicit configuration. 633 7.2. The PCEP Data Model 635 A PCEP MIB module is defined in [I-D.ietf-pce-pcep-mib] needs be 636 extended to cover additional functionality provided by [RFC5440] and 637 [I-D.crabbe-pce-pce-initiated-lsp]. Such extension will cover the 638 new functionality specified in this document. 640 8. Security Considerations 642 The security considerations described in [RFC5440] and 643 [I-D.crabbe-pce-pce-initiated-lsp] are applicable to this 644 specification. No additional security measure is required. 646 9. IANA Considerations 648 9.1. PCEP Objects 650 IANA is requested to allocate a ERO subobject type (recommended value 651 = 5) for the SR-ERO subobject. 653 9.2. PCEP-Error Object 655 This document defines new Error-Type and Error-Value for the 656 following new conditions: 658 Error-Type Meaning 659 10 Reception of an invalid object 661 Error-value=2: Bad label value 662 Error-value=3: Unsupported number of Segment ERO 663 subobjects 664 Error-value=4: Bad label format 665 Error-value=5: Non-identical ERO subobjects 667 9.3. PCEP TLV Type Indicators 669 This document defines the following new PCEP TLVs: 671 Value Meaning Reference 672 -------- ------------------------------------ ----------------- 673 26 SR-PCE-CAPABILITY This document 675 Table 1 677 9.4. New Path Setup Type 679 This document defines a new setup type for the PATH-SETUP-TYPE TLV as 680 follows: 682 Value Description Reference 684 1 Traffic engineering path is setup using This document 685 Segment Routing technique. 687 Table 2 689 10. Contributors 691 The following people contributed to this document: 693 - Lakshmi Sharma (Cisco Systems) 695 11. Acknowledgements 697 We like to thank Ina Minei, George Swallow, and Marek Zavodsky for 698 the valuable comments. 700 12. References 702 12.1. Normative References 704 [I-D.crabbe-pce-pce-initiated-lsp] 705 Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP 706 Extensions for PCE-initiated LSP Setup in a Stateful PCE 707 Model", draft-crabbe-pce-pce-initiated-lsp-01 (work in 708 progress), April 2013. 710 [I-D.filsfils-rtgwg-segment-routing] 711 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 712 Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., 713 Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe, 714 "Segment Routing Architecture", draft-filsfils-rtgwg- 715 segment-routing-00 (work in progress), June 2013. 717 [I-D.ietf-pce-pcep-mib] 718 Koushik, K., Stephan, E., Zhao, Q., King, D., and J. 719 Hardwick, "PCE communication protocol (PCEP) Management 720 Information Base", draft-ietf-pce-pcep-mib-04 (work in 721 progress), February 2013. 723 [I-D.ietf-pce-stateful-pce] 724 Crabbe, E., Medved, J., Minei, I., and R. Varga, "PCEP 725 Extensions for Stateful PCE", draft-ietf-pce-stateful- 726 pce-05 (work in progress), July 2013. 728 [I-D.previdi-isis-segment-routing-extensions] 729 Previdi, S., Filsfils, C., Bashandy, A., Gredler, H., 730 Decraene, B., Litkowski, S., Geib, R., Milojevic, I., 731 Shakir, R., Ytti, S., Henderickx, W., and J. Tantsura, 732 "IS-IS Extensions for Segment Routing", draft-previdi- 733 isis-segment-routing-extensions-01 (work in progress), 734 July 2013. 736 [I-D.psenak-ospf-segment-routing-extensions] 737 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., and R. 738 Shakir, "OSPF Extensions for Segment Routing", draft- 739 psenak-ospf-segment-routing-extensions-01 (work in 740 progress), July 2013. 742 [I-D.sivabalan-pce-lsp-setup-type] 743 Sivabalan, S., Medved, J., Minei, I., Varga, R., and E. 744 Crabbe, "LSP setup method in PCEP messages", draft- 745 sivabalan-pce-lsp-setup-type-00 (work in progress), 746 October 2013. 748 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 749 Requirement Levels", BCP 14, RFC 2119, March 1997. 751 [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element 752 (PCE) Communication Protocol (PCEP)", RFC 5440, March 753 2009. 755 [RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching 756 (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic 757 Class" Field", RFC 5462, February 2009. 759 12.2. Informative References 761 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 762 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 763 Tunnels", RFC 3209, December 2001. 765 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 766 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 767 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 769 [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links 770 in Resource ReSerVation Protocol - Traffic Engineering 771 (RSVP-TE)", RFC 3477, January 2003. 773 [RFC4657] Ash, J. and J. Le Roux, "Path Computation Element (PCE) 774 Communication Protocol Generic Requirements", RFC 4657, 775 September 2006. 777 Authors' Addresses 779 Siva Sivabalan 780 Cisco Systems, Inc. 781 2000 Innovation Drive 782 Kanata, Ontario K2K 3E8 783 Canada 785 Email: msiva@cisco.com 786 Jan Medved 787 Cisco Systems, Inc. 788 170 West Tasman Dr. 789 San Jose, CA 95134 790 US 792 Email: jmedved@cisco.com 794 Clarence Filsfils 795 Cisco Systems, Inc. 796 Pegasus Parc 797 De kleetlaan 6a, DIEGEM BRABANT 1831 798 BELGIUM 800 Email: cfilsfil@cisco.com 802 Edward Crabbe 803 Google, Inc. 804 1600 Amphitheatre Parkway 805 Mountain View, CA 94043 806 US 808 Email: edward.crabbe@gmail.com 810 Robert Raszuk 811 NTT I3 812 101 S. Ellsworth Ave 813 San Mateo, CA 94401 814 US 816 Email: robert@raszuk.net