idnits 2.17.1 draft-ietf-pce-lsp-setup-type-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 9, 2015) is 3335 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 (-11) exists of draft-ietf-pce-pce-initiated-lsp-03 == Outdated reference: A later version (-21) exists of draft-ietf-pce-stateful-pce-10 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE Working Group S. Sivabalan 3 Internet-Draft J. Medved 4 Intended status: Standards Track Cisco Systems, Inc. 5 Expires: September 10, 2015 I. Minei 6 Google, Inc. 7 E. Crabbe 9 R. Varga 10 Pantheon Technologies SRO 11 J. Tantsura 12 Ericsson 13 March 9, 2015 15 Conveying path setup type in PCEP messages 16 draft-ietf-pce-lsp-setup-type-01.txt 18 Abstract 20 A Path Computation Element can compute traffic engineering paths (TE 21 paths) through a network that are subject to various constraints. 22 Currently, TE paths are label switched paths (LSPs) which are set up 23 using the RSVP-TE signaling protocol. However, other TE path setup 24 methods are possible within the PCE architecture. This document 25 proposes an extension to PCEP to allow support for different path 26 setup methods over a given PCEP session. 28 Requirements Language 30 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 31 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 32 document are to be interpreted as described in [RFC2119]. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at http://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on September 10, 2015. 50 Copyright Notice 52 Copyright (c) 2015 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 69 3. Path Setup Type TLV . . . . . . . . . . . . . . . . . . . . . 3 70 4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 72 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 73 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 74 8. Normative References . . . . . . . . . . . . . . . . . . . . 6 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 77 1. Introduction 79 [RFC5440] describes the Path Computation Element Protocol (PCEP) for 80 communication between a Path Computation Client (PCC) and a Path 81 Control Element (PCE) or between one a pair of PCEs. A PCC requests 82 a path subject to various constraints and optimization criteria from 83 a PCE. The PCE responds to the PCC with a hop-by-hop path in an 84 Explicit Route Object (ERO). The PCC uses the ERO to set up the path 85 in the network. 87 [I-D.ietf-pce-stateful-pce] specifies extensions to PCEP that allow a 88 PCC to delegate its LSPs to a PCE. The PCE can then update the state 89 of LSPs delegated to it. In particular, the PCE may modify the path 90 of an LSP by sending a new ERO. The PCC uses this ERO to re-route 91 the LSP in a make-before-break fashion. 92 [I-D.ietf-pce-pce-initiated-lsp] specifies a mechanism allowing a PCE 93 to dynamically instantiate an LSP on a PCC by sending the ERO and 94 characteristics of the LSP. The PCC signals the LSP using the ERO 95 and other attributes sent by the PCE. 97 So far, the PCEP protocol and its extensions implicitly assume that 98 the TE paths are label switched, and are established via the RSVP-TE 99 protocol. However, other methods of LSP setup are not precluded. 100 When a new path setup method (other than RSVP-TE) is introduced for 101 setting up a path, a new capability TLV pertaining to the new path 102 setup method MAY be advertised when the PCEP session is established. 103 Such capability TLV MUST be defined in the specification of the new 104 path setup type. When multiple path setup methods are deployed in a 105 network, a given PCEP session may have to simultaneously support more 106 than one path setup types. In this case, the intended path setup 107 method needs to be either explicitly indicated or implied in the 108 appropriate PCEP messages (when necessary) so that both the PCC and 109 the PCE can take the necessary steps to set up the path. This 110 document introduces a generic TLV called "PATH-SETUP-TYPE TLV" and 111 specifies the base procedures to facilitate such operational model. 113 2. Terminology 115 The following terminologies are used in this document: 117 ERO: Explicit Route Object. 118 LSR: Label Switching Router. 119 PCC: Path Computation Client. 120 PCE: Path Computation Element 121 PCEP: Path Computation Element Protocol. 122 TLV: Type, Length, and Value. 124 3. Path Setup Type TLV 126 When a PCEP session is used to set up TE paths using different 127 methods, the corresponding PCE and PCC must be aware of the path 128 setup method used. That means, a PCE must be able to specify paths 129 in the correct format and a PCC must be able take control and take 130 forwarding plane actions appropriate to the path setup type. 132 0 1 2 3 133 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 134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 135 | Type | Length | 136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 137 | Reserved | PST | 138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 140 Figure 1: PATH-SETUP-TYPE TLV 142 PATH-SETUP-TYPE TLV is an optional TLV associated with the RP 143 ([RFC5440]) and the SRP ([I-D.ietf-pce-stateful-pce]) objects. Its 144 format is shown in the above figure. The type of the TLV is to be 145 defined by IANA. The one octet value contains the Path Setup Type 146 (PST). This document specifies the following PST value: 148 o PST = 0: Path is setup via RSVP-TE signaling protocol(default). 150 The absence of the PATH-SETUP-TYPE TLV is equivalent to an PATH- 151 SETUP-TYPE TLV with an PST value of 0. It is recommended to omit the 152 TLV in the default case. If the RP or SRP object contains more than 153 one PATH-SETUP-TYPE TLVs, only the first TLV MUST be processed and 154 the rest MUST be ignored. 156 If a PCEP speaker does not recognize the PATH-SETUP-TYPE TLV, it MUST 157 ignore the TLV in accordance with ([RFC5440]). If a PCEP speaker 158 recognizes the TLV but does not support the TLV, it MUST send PCErr 159 with Error-Type = 2 (Capability not supported). 161 4. Operation 163 When requesting a path from a PCE using a PCReq message ([RFC5440]), 164 a PCC MAY include the PATH-SETUP-TYPE TLV in the RP object. If the 165 PCE is capable of expressing the path in a format appropriate to the 166 setup method used, it MUST use the appropriate ERO format in the 167 PCRep message. If the path setup type cannot be inferred from the 168 ERO or any other object or TLV in the PCRep message, PATH-SETUP-TYPE 169 TLV may be included in the RP object of the PCRep message. 170 Regardless of whether PATH-SETUP-TYPE TLV is used or not, if the PCE 171 does not support the intended path setup type it MUST send PCErr with 172 Error-Type = TBD (Traffic engineering path setup error) (recommended 173 value is 21) and Error-Value = 1 (Unsupported path setup type) and 174 close the PCEP session. If the path setup types corresponding to the 175 PCReq and PCRep messages do not match, the PCC MUST send a PCErr with 176 Error-Type = 21 (Traffic engineering path setup error) and Error- 177 Value = 2 (Mismatched path setup type) and close the PCEP session. 179 In the case of stateful PCE, if the path setup type cannot be 180 unambiguously inferred from ERO or any other object or TLV, PATH- 181 SETUP-TYPE TLV MAY be used in PCRpt and PCUpd messages. If PATH- 182 SETUP-TYPE TLV is used in PCRpt message, the SRP object MUST be 183 present even in cases when the SRP-ID-number is the reserved value of 184 0x00000000. Regardless of whether PATH-SETUP-TYPE TLV is used or 185 not, if a PCRpt message is triggered due to a PCUpd message (in this 186 case SRP-ID-number is not equal to 0x00000000), the path setup types 187 corresponding to the PCRpt and PCUpd messages should match. 188 Otherwise, the PCE MUST send PCErr with Error-Type = 21 (Traffic 189 engineering path setup error) and Error-Value = 2 (Mismatched path 190 setup type) and close the connection. 192 In the case of PCE initiated LSPs, a PCE MAY include PATH-SETUP-TYPE 193 TLV in PCInitiate message if the message does not have any other 194 means of indicating path setup type. If a PCC does not support the 195 path setup type associated with the PCInitiate message, the PCC MUST 196 send PCErr with Error-Type = 21 (Traffic engineering path setup 197 error) and Error-Value = 1 (Unsupported path setup type) and close 198 the PCEP session. Similarly, as mentioned above, if the path setup 199 type cannot be unambiguously inferred from ERO or any other object or 200 TLV, the PATH-SETUP-TYPE TLV MAY be included in PCRpt messages 201 triggered by PCInitiate message. Regardless of whether PATH-SETUP- 202 TYPE TLV is used or not, if a PCRpt message is triggered by a 203 PCInitiate message, the path setup types corresponding to the PCRpt 204 and the PCInitiate messages should match. Otherwise, the PCE MUST 205 send PCErr message with Error-Type = 21 (Traffic engineering path 206 setup error) and Error-Value = 2 (Mismatched path setup type). 208 5. Security Considerations 210 No additional security measure is required. 212 6. IANA Considerations 214 IANA is requested to allocate a new TLV type (recommended value is 215 TBD)for PATH-SETUP-TYPE TLV specified in this document. 217 This document requests that a registry is created to manage the value 218 of the path Setup Type field in the PATH-SETUP-TYPE TLV. 220 Value Description Reference 222 0 Traffic engineering This document 223 path is setup using 224 RSVP signaling 225 protocol 227 This document also defines a new Error-Type (recommended 21) and new 228 Error-Values for the following new error conditions: 230 Error-Type Meaning 231 21 Invalid traffic engineering path setup type 233 Error-value=1: Unsupported path setup type 234 Error-value=2: Mismatched path setup type 236 7. Acknowledgements 238 We like to thank Marek Zavodsky for valuable comments. 240 8. Normative References 242 [I-D.ietf-pce-pce-initiated-lsp] 243 Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP 244 Extensions for PCE-initiated LSP Setup in a Stateful PCE 245 Model", draft-ietf-pce-pce-initiated-lsp-03 (work in 246 progress), March 2015. 248 [I-D.ietf-pce-stateful-pce] 249 Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP 250 Extensions for Stateful PCE", draft-ietf-pce-stateful- 251 pce-10 (work in progress), October 2014. 253 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 254 Requirement Levels", BCP 14, RFC 2119, March 1997. 256 [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element 257 (PCE) Communication Protocol (PCEP)", RFC 5440, March 258 2009. 260 Authors' Addresses 262 Siva Sivabalan 263 Cisco Systems, Inc. 264 2000 Innovation Drive 265 Kanata, Ontario K2K 3E8 266 Canada 268 Email: msiva@cisco.com 270 Jan Medved 271 Cisco Systems, Inc. 272 170 West Tasman Dr. 273 San Jose, CA 95134 274 USA 276 Email: jmedved@cisco.com 277 Ina Minei 278 Google, Inc. 279 1600 Amphitheatre Parkway 280 Mountain View, CA 94043 281 USA 283 Email: inaminei@google.com 285 Edward Crabbe 287 Robert Varga 288 Pantheon Technologies SRO 289 Mlynske Nivy 56 290 Bratislava, 821 05 291 Slovakia 293 Email: robert.vargad@pantheon.sk 295 Jeff Tantsura 296 Ericsson 297 300 Holger Way 298 San Jose, CA 95134 299 USA 301 Email: jeff.tantsura@ericsson.com