idnits 2.17.1 draft-crabbe-pce-stateful-pce-mpls-te-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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([I-D.ietf-pce-stateful-pce]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 8, 2013) is 3998 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) == Missing Reference: 'TBD' is mentioned on line 170, but not defined == Unused Reference: 'RFC2205' is defined on line 360, but no explicit reference was found in the text == Unused Reference: 'RFC3209' is defined on line 364, but no explicit reference was found in the text == Unused Reference: 'RFC4090' is defined on line 368, but no explicit reference was found in the text == Unused Reference: 'RFC5088' is defined on line 372, but no explicit reference was found in the text == Unused Reference: 'RFC5089' is defined on line 376, but no explicit reference was found in the text == Unused Reference: 'RFC5226' is defined on line 380, but no explicit reference was found in the text == Unused Reference: 'RFC2702' is defined on line 394, but no explicit reference was found in the text == Unused Reference: 'RFC3031' is defined on line 398, but no explicit reference was found in the text == Unused Reference: 'RFC3346' is defined on line 401, but no explicit reference was found in the text == Unused Reference: 'RFC3630' is defined on line 405, but no explicit reference was found in the text == Unused Reference: 'RFC4655' is defined on line 409, but no explicit reference was found in the text == Unused Reference: 'RFC4657' is defined on line 412, but no explicit reference was found in the text == Unused Reference: 'RFC5305' is defined on line 416, but no explicit reference was found in the text == Unused Reference: 'RFC5394' is defined on line 419, but no explicit reference was found in the text == Unused Reference: 'RFC5557' is defined on line 423, but no explicit reference was found in the text == Outdated reference: A later version (-21) exists of draft-ietf-pce-stateful-pce-03 ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 2 errors (**), 0 flaws (~~), 18 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Crabbe 3 Internet-Draft Google, Inc. 4 Intended status: Standards Track J. Medved 5 Expires: November 9, 2013 Cisco Systems, Inc. 6 I. Minei 7 Juniper Networks, Inc. 8 R. Varga 9 Pantheon Technologies SRO 10 May 8, 2013 12 Stateful PCE extensions for MPLS-TE LSPs 13 draft-crabbe-pce-stateful-pce-mpls-te-01 15 Abstract 17 The Path Computation Element Communication Protocol (PCEP) provides 18 mechanisms for Path Computation Elements (PCEs) to perform path 19 computations in response to Path Computation Clients (PCCs) requests. 21 [I-D.ietf-pce-stateful-pce] describes a set of extensions to PCEP to 22 provide stateful control. This document describes the objects and 23 TLVs to be used with these PCEP extensions to control Multiprotocol 24 Label Switching (MPLS) Traffic Engineering Label Switched Paths (TE 25 LSP) via a stateful PCE. 27 Requirements Language 29 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 30 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 31 document are to be interpreted as described in [RFC2119]. 33 Status of this Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on November 9, 2013. 50 Copyright Notice 52 Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 69 3. MPLS-TE specific descriptors used in PCEP Messages . . . . . . 3 70 3.1. MPLS-TE specific descriptors for the PCRpt Message . . . . 3 71 3.2. MPLS-TE specific descriptors for the PCUpd Message . . . . 4 72 3.3. MPLS-TE specific encoding for the PCReq Message for 73 stateful PCE . . . . . . . . . . . . . . . . . . . . . . . 6 74 3.4. MPLS-TE specific encoding for the PCRep Message for 75 stateful PCE . . . . . . . . . . . . . . . . . . . . . . . 7 76 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 77 4.1. PCEP-Error Object . . . . . . . . . . . . . . . . . . . . 8 78 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 79 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 80 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 81 7.1. Normative References . . . . . . . . . . . . . . . . . . . 9 82 7.2. Informative References . . . . . . . . . . . . . . . . . . 10 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 85 1. Introduction 87 The Path Computation Element Communication Protocol (PCEP) provides 88 mechanisms for Path Computation Elements (PCEs) to perform path 89 computations in response to Path Computation Clients (PCCs) requests. 91 [I-D.ietf-pce-stateful-pce] describes a set of extensions to PCEP to 92 provide stateful control. This document describes the objects and 93 TLVs to be used with these PCEP extensions to control Multiprotocol 94 Label Switching (MPLS) Traffic Engineering Label Switched Paths (TE 95 LSP) via a stateful PCE. 97 2. Terminology 99 This document uses the following terms defined in [RFC5440]: PCC, 100 PCE, PCEP Peer. 102 This document uses the following terms defined in 103 [I-D.ietf-pce-stateful-pce] : Passive Stateful PCE, Active Stateful 104 PCE, Delegation, Delegation Timeout Interval, LSP State Report, LSP 105 Update Request, LSP Priority, LSP State Database, Revocation. 107 Within this document, when describing PCE-PCE communications, the 108 requesting PCE fills the role of a PCC. This provides a saving in 109 documentation without loss of function. 111 The message formats in this document are specified using Routing 112 Backus-Naur Format (RBNF) encoding as specified in [RFC5511]. 114 3. MPLS-TE specific descriptors used in PCEP Messages 116 As defined in [RFC5440], a PCEP message consists of a common header 117 followed by a variable-length body made of a set of objects that can 118 be either mandatory or optional. [I-D.ietf-pce-stateful-pce] 119 describes the messages and objects needed in support of stateful PCE. 120 The following sections contain MPLS-TE specific descriptors used in 121 some of these messages. 123 3.1. MPLS-TE specific descriptors for the PCRpt Message 125 The format of the PCRpt message is defined in 126 [I-D.ietf-pce-stateful-pce] as follows, and included here for easy 127 reference: 129 ::= 130 131 Where: 133 ::= [] 135 ::= 136 [] 138 Where: 140 ::=[] 142 For MPLS-TE LSPs, the path descriptor is defined as follows: 144 ::= 146 Where: 148 ::= [] 149 [] 150 [] 151 [] 153 ::= [] 155 The LSP State Report MAY contain a path descriptor for the primary 156 path and one or more path descriptors for backup paths. A path 157 descriptor MUST contain an ERO object as it was specified by a PCE or 158 an operator. A path descriptor MUST contain the RRO object if a 159 primary or secondary LSP is set up along the path in the network. A 160 path descriptor MAY contain the LSPA, BANDWIDTH, and METRIC objects. 161 The ERO,LSPA, BANDWIDTH, METRIC, and RRO objects are defined 162 in[RFC5440]. 164 3.2. MPLS-TE specific descriptors for the PCUpd Message 166 A Path Computation LSP Update Request message (also referred to as 167 PCUpd message) is a PCEP message sent by a PCE to a PCC to update 168 attributes of an LSP. A PCUpd message can carry more than one LSP 169 Update Request. The Message-Type field of the PCEP common header for 170 the PCUpd message is set to [TBD]. 172 The format of the PCUpd message is defined in 173 [I-D.ietf-pce-stateful-pce] and included here for easy reference: 175 ::= 176 177 Where: 179 ::= [] 181 ::= 182 [] 184 Where: 186 ::=[] 188 For MPLS-TE LSPs, the endoding of path descriptor is defined as 189 follows: 191 ::= 193 Where: 194 ::= 196 Where: 198 ::= [] 199 [] 200 [] 202 ::= [] 204 There is one mandatory object that MUST be included within each LSP 205 Update Request in the PCUpd message: the LSP object (see 206 [I-D.ietf-pce-stateful-pce]). If the LSP object is missing, the 207 receiving PCE MUST send a PCErr message with Error-type=6 (Mandatory 208 Object missing) and Error-value=[TBD] (LSP object missing). 210 The LSP Update Request MUST contain a path descriptor for the primary 211 path, and MAY contain one or more path descriptors for backup paths. 212 A path descriptor MUST contain an ERO object. A path descriptor MAY 213 further contain the BANDWIDTH, IRO, and METRIC objects. The ERO, 214 LSPA, BANDWIDTH, METRIC, and IRO objects are defined in [RFC5440]. 216 Each LSP Update Request results in a separate LSP setup operation at 217 a PCC. An LSP Update Request MUST contain all LSP parameters that a 218 PCC wishes to set for the LSP. A PCC MAY set missing parameters from 219 locally configured defaults. If the LSP specified the Update Request 220 is already up, it will be re-signaled. The PCC will use make-before- 221 break whenever possible in the re-signaling operation. 223 A PCC MUST respond with an LSP State Report to each LSP Update 224 Request to indicate the resulting state of the LSP in the network. A 225 PCC MAY respond with multiple LSP State Reports to report LSP setup 226 progress of a single LSP. 228 If the rate of PCUpd messages sent to a PCC for the same target LSP 229 exceeds the rate at which the PCC can signal LSPs into the network, 230 the PCC MAY perform state compression and only re-signal the last 231 modification in its queue. 233 Note that a PCC MUST process all LSP Update Requests - for example, 234 an LSP Update Request is sent when a PCE returns delegation or puts 235 an LSP into non-operational state. The protocol relies on TCP for 236 message-level flow control. 238 Note also that it's up to the PCE to handle inter-LSP dependencies; 239 for example, if ordering of LSP set-ups is required, the PCE has to 240 wait for an LSP State Report for a previous LSP before triggering the 241 LSP setup of a next LSP. 243 3.3. MPLS-TE specific encoding for the PCReq Message for stateful PCE 245 A PCC MAY include the LSP object defined in 246 [I-D.ietf-pce-stateful-pce] in the PCReq message if the stateful PCE 247 capability has been negotiated on a PCEP session between the PCC and 248 a PCE. The definition of the PCReq message (see [RFC5440], Section 249 6.4) is then extended as follows: 251 ::= 252 [] 253 255 Where: 257 ::=[] 258 ::=[] 260 ::= 261 262 [] <--- New Object 263 [] 264 [] 265 [] 266 [[]] 267 [] 268 [] 270 Where: 272 ::=[] 274 3.4. MPLS-TE specific encoding for the PCRep Message for stateful PCE 276 A PCE MAY include the LSP object defined in 277 [I-D.ietf-pce-stateful-pce] in the PCRep message if the stateful PCE 278 capability has been negotiated on a PCEP session between the PCC and 279 the PCE and the LSP object was included in the corresponding PCReq 280 message from the PCC. The definition of the PCRep message (see 281 [RFC5440], Section 6.5) is then extended as follows 282 ::= 283 285 Where: 287 ::=[] 289 ::= 290 [] <--- New Object 291 [] 292 [] 293 [] 295 ::=[] 297 ::= 299 Where: 301 ::=[] 302 [] 303 [] 304 [] 306 ::=[] 308 4. IANA Considerations 310 This document requests IANA actions to allocate code points for the 311 protocol elements defined in this document. Values shown here are 312 suggested for use by IANA. 314 4.1. PCEP-Error Object 316 This document defines new Error-Type and Error-Value for the 317 following new error conditions: 319 Error-Type Meaning 320 6 Mandatory Object missing 321 Error-value=9: ERO Object missing for a path in an LSP 322 Update Request where TE-LSP setup is 323 requested 324 Error-value=10: BANDWIDTH Object missing for a path in 325 an LSP Update Request where TE-LSP 326 setup is requested 328 Error-value=11: LSPA Object missing for a path in an 329 LSP Update Request where TE-LSP setup 330 is requested 332 5. Security Considerations 334 The security considerations listed in [I-D.ietf-pce-stateful-pce] 335 apply to this document as well. 337 6. Acknowledgements 339 We would like to thank Adrian Farrel, Cyril Margaria and Ramon 340 Casellas for their contributions to this document. 342 We would like to thank Shane Amante,Julien Meuric, Kohei Shiomoto, 343 Paul Schultz and Raveendra Torvi for their comments and suggestions. 344 Thanks also to Dhruv Dhoddy, Oscar Gonzales de Dios, Tomas Janciga, 345 Stefan Kobza and Kexin Tang for helpful discussions. 347 7. References 349 7.1. Normative References 351 [I-D.ietf-pce-stateful-pce] 352 Crabbe, E., Medved, J., Minei, I., and R. Varga, "PCEP 353 Extensions for Stateful PCE", 354 draft-ietf-pce-stateful-pce-03 (work in progress), 355 March 2013. 357 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 358 Requirement Levels", BCP 14, RFC 2119, March 1997. 360 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 361 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 362 Functional Specification", RFC 2205, September 1997. 364 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 365 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 366 Tunnels", RFC 3209, December 2001. 368 [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute 369 Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 370 May 2005. 372 [RFC5088] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, 373 "OSPF Protocol Extensions for Path Computation Element 374 (PCE) Discovery", RFC 5088, January 2008. 376 [RFC5089] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, 377 "IS-IS Protocol Extensions for Path Computation Element 378 (PCE) Discovery", RFC 5089, January 2008. 380 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 381 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 382 May 2008. 384 [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element 385 (PCE) Communication Protocol (PCEP)", RFC 5440, 386 March 2009. 388 [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax 389 Used to Form Encoding Rules in Various Routing Protocol 390 Specifications", RFC 5511, April 2009. 392 7.2. Informative References 394 [RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. 395 McManus, "Requirements for Traffic Engineering Over MPLS", 396 RFC 2702, September 1999. 398 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 399 Label Switching Architecture", RFC 3031, January 2001. 401 [RFC3346] Boyle, J., Gill, V., Hannan, A., Cooper, D., Awduche, D., 402 Christian, B., and W. Lai, "Applicability Statement for 403 Traffic Engineering with MPLS", RFC 3346, August 2002. 405 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 406 (TE) Extensions to OSPF Version 2", RFC 3630, 407 September 2003. 409 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 410 Element (PCE)-Based Architecture", RFC 4655, August 2006. 412 [RFC4657] Ash, J. and J. Le Roux, "Path Computation Element (PCE) 413 Communication Protocol Generic Requirements", RFC 4657, 414 September 2006. 416 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 417 Engineering", RFC 5305, October 2008. 419 [RFC5394] Bryskin, I., Papadimitriou, D., Berger, L., and J. Ash, 420 "Policy-Enabled Path Computation Framework", RFC 5394, 421 December 2008. 423 [RFC5557] Lee, Y., Le Roux, JL., King, D., and E. Oki, "Path 424 Computation Element Communication Protocol (PCEP) 425 Requirements and Protocol Extensions in Support of Global 426 Concurrent Optimization", RFC 5557, July 2009. 428 Authors' Addresses 430 Edward Crabbe 431 Google, Inc. 432 1600 Amphitheatre Parkway 433 Mountain View, CA 94043 434 US 436 Email: edc@google.com 438 Jan Medved 439 Cisco Systems, Inc. 440 170 West Tasman Dr. 441 San Jose, CA 95134 442 US 444 Email: jmedved@cisco.com 446 Ina Minei 447 Juniper Networks, Inc. 448 1194 N. Mathilda Ave. 449 Sunnyvale, CA 94089 450 US 452 Email: ina@juniper.net 454 Robert Varga 455 Pantheon Technologies SRO 456 Mlynske Nivy 56 457 Bratislava 821 05 458 Slovakia 460 Email: robert.varga@pantheon.sk