idnits 2.17.1 draft-cho-pce-initiated-auto-path-00.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 : ---------------------------------------------------------------------------- ** There are 21 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** There are 8 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 31, 2016) is 2732 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: 'RFC2119' is mentioned on line 22, but not defined == Missing Reference: 'RFC4657' is mentioned on line 83, but not defined == Unused Reference: 'RFC5921' is defined on line 407, but no explicit reference was found in the text == Unused Reference: 'I-D.palle-pce-controller-labeldb-sync' is defined on line 418, but no explicit reference was found in the text == Outdated reference: A later version (-21) exists of draft-ietf-pce-stateful-pce-14 == Outdated reference: A later version (-10) exists of draft-ietf-pce-stateful-sync-optimizations-05 ** Downref: Normative reference to an Informational RFC: RFC 5921 == Outdated reference: A later version (-11) exists of draft-ietf-pce-pce-initiated-lsp-05 == Outdated reference: A later version (-03) exists of draft-palle-pce-controller-labeldb-sync-00 Summary: 3 errors (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 PCE Working Group E. Cho 2 Internet-Draft T. Kwon 3 Intended status: Standards Track ETRI 4 Expires: April 30, 2017 October 31, 2016 6 PCEP Extensions for PCE-initiated Automatic Path Setup 7 in a Stateful PCE Model 8 draft-cho-pce-initiated-auto-path-00 10 Abstract 12 This document introduces an automatic setup and maintenance mechanism 13 to compute, create, update and delete for a packet and/or optical layer 14 path and pseudowire paths(PWs) via an extension to the Path Computation 15 Element Communication Protocol(PCEP) and DB Synchronization procedures. 17 Requirements Language 19 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 20 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 21 document are to be interpreted as described in [RFC2119]. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on April 30, 2017. 39 Copyright Notice 41 Copyright (c) 2016 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 4. Support of PCE-initiated Automatic Path . . . . . . . . . . . 4 60 4.1. Stateful PCE Capability TLV . . . . . . . . . . . . . . . 4 61 4.2. PW-LABEL-DB Synchronization . . . . . . . . . . . . . . . 4 62 4.3. OAM-DB Synchronization . . .. . . . . . . . . . . . . . . 5 63 5. PCE-initiated LSP and PW instantiation and deletion . . . . . 6 64 5.1. The LSP and PW Initiate Message . . . .. . . . . . . . . 6 65 5.2. The D flag in the SRP Object . . . . . . . . . . . . . . 6 66 5.3. LSP and PW instantiation . . . . . . . . . . . . . . . . 7 67 5.4. LSP and PW deletion . . . . .. . . . . . . . . . . . . . 8 68 5.5. Automatic Restoration and Cascade Update . . . . . . . . 8 69 6. LSP and PW delegation and cleanup . . . . . . . . . . . . . 8 70 7. Manageability Considerations . . . . . . . . . . . . . . . . 9 71 8. IANA considerations . . . . . . . . . . . . . . . . . . . . . 9 72 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9 73 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 74 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 75 11.1. Normative References . . . . . . . . . . . . . . . . . . 9 76 11.2. Informative References . . . . . . . . . . . . . . . . . 9 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 79 1. Introduction 81 Stateful pce [I-D.ietf-pce-stateful-pce] specifies a set of 82 extensions to PCEP to enable stateful control of TE LSPs between and 83 across PCEP sessions in compliance with [RFC4657]. It includes 84 mechanisms to effect LSP state synchronization between PCCs and PCEs, 85 delegation of control of LSPs to PCEs, and PCE control of timing and 86 sequence of path computations within and across PCEP sessions 88 This document describes the setup, maintenance and teardown of PCE- 89 initiated LSPs and/or Pseudowires under the stateful PCE model 90 allowing for automatic setup of an transport paths. 92 2. Terminology 94 This document uses the following terms defined in [RFC5440]: PCC, 95 PCE, PCEP Peer. 97 This document uses the following terms defined in 98 [I-D.ietf-pce-stateful-pce]: Stateful PCE, Delegation, Redelegation 99 Timeout, State Timeout Interval Path State Report, Path Update 100 Request. 102 The following terms are defined in this document: 104 PCE-initiated Automatic Path: Pseudowire and/or LSP that is 105 instantiated as a result of a request from the PCE. 107 3. Motivation 109 An active stateful PCE is able to provide an automated and optimized 110 path as the role of central controller or NMS. In addition to PCE- 111 initiated LSP, PCE may initiate pseudowire service automatically over LSP 112 with extension of information and protocol. With OAM information, PCE 113 would be able to trigger path restoration upon alarm notification. 114 Therefore, this document introduces an automatic path management method 115 with PCE-initiated paths setup using their pseudowire label and OAM 116 database. It is a useful mechanism in multi-domain and multi-layer SDN 117 and ACTN. 119 Different setup of automatic paths may be offered: 121 o LSP only: setup the label switched path in one request 123 o PW only: setup the pseudowire paths in one request 125 o LSP+PW: setup the LSP with the associated PWs in one request 127 4. Support of PCE-initiated Automatic Path 129 A PCEP speaker indicates its ability to support PCE provisioned 130 dynamic LSPs and/or PWs during the PCEP Initialization phase. The 131 Open Object in the Open message contains the "Stateful PCE Capability" 132 TLV, defined in [I-D.ietf-pce-stateful-pce]. A new flag, the P (PW- 133 INSTANTIATION-CAPABILITY) flag is introduced to indicate support for 134 instantiation of PCE-initiated LSPs. A PCE can initiate LSPs 135 with/without PWs for PCCs that advertised this capability and a PCC will 136 follow the procedures described in this document only on sessions where 137 the PCE advertised the P flag. 139 4.1. Stateful PCE Capability TLV 141 The format of the STATEFUL-PCE-CAPABILITY TLV is shown in the 142 following figure: 144 0 1 2 3 145 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 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 | Type | Length=4 | 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 | Flags |P|I|S|U| 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+ 152 Figure 1: STATEFUL-PCE-CAPABILITY TLV format 154 The type of the TLV is defined in [I-D.ietf-pce-stateful-pce] and it 155 has a fixed length of 4 octets. 157 The value comprises a single field - Flags (32 bits). 158 The I, U and S bits are defined in [I-D.ietf-pce-pce-initiated-lsp], 159 [I-D.ietf-pce-stateful-pce] and [I-D.ietf-pce-stateful-sync- 160 optimizations] respectively. 162 P (PW-INSTANTIATION-CAPABILITY - 1 bit): If set to 1 by a PCC, the 163 I Flag indicates that the PCC allows instantiation of an LSP by a 164 PCE. If set to 1 by a PCE, the P flag indicates that the PCE may 165 attempt to instantiate PWs over LSPs. 166 The PW-INSTANTIATION-CAPABILITY flag must be set by both PCC and 167 PCE in order to support PCE-initiated LSP instantiation. 169 4.2. PW-LABEL-DB Synchronization 171 PCECC or NMS MUST maintain the PW-LABEL-DB for each PCEP session 172 separately. 174 The purpose of PW-LABEL-DB synchronization is to make sure that the 175 PCE's view of PW-LABEL-DB matches with the PCC's PW-LABEL-DB. The 176 PW-LABEL-DB synchronization MUST be performed from PCC to PCE immediately 177 after the LSP state synchronization. [I-D.ietf-pce-stateful-pce] 178 describes the basic mechanism for LSP state synchronization. 180 +-+-+ +-+-+ 181 |PCC| |PCE| 182 +-+-+ +-+-+ 183 | | 184 |-PCLabelUpd, SYNC=1----->| (Sync start) 185 | | 186 |-PCLabelUpd, SYNC=1----->| 187 | . | 188 | . | 189 | . | 190 |-PCLabelUpd, SYNC=0----->| (End of sync marker 191 | | Label Update 192 | | PW LABEL=0) 193 | | (Sync done) 195 Figure 2: PW-LABEL-DB synchronization 197 Further synchronization procedures and protocol definitions will be 198 added after consensus on this necessity in this or a separate document. 200 4.3. OAM-DB Synchronization 202 PCECC or NMS MUST maintain the OAM-DB for each PCEP session 203 separately. 204 The purpose of OAM-DB synchronization is to make sure that the 205 PCE's view of OAM-DB matches with the PCC's OAM-DB. The OAM- 206 DB synchronization MUST be performed from PCC to PCE immediately 207 after the LSP state synchronization. [I-D.ietf-pce-stateful-pce] 208 describes the basic mechanism for LSP state synchronization. 210 +-+-+ +-+-+ 211 |PCC| |PCE| 212 +-+-+ +-+-+ 213 | | 214 |---PCOAMUpd, SYNC=1----->| (Sync start) 215 | | 216 |---PCOAMUpd, SYNC=1----->| 217 | . | 218 | . | 219 | . | 220 |---PCOAMUpd, SYNC=0----->| (End of sync marker 221 | | Label Update 222 | | OAM =0) 223 | | (Sync done) 225 Figure 3: OAM-DB synchronization 227 Upon alarm notification on link or path, PCE can compute and initiate 228 restoration path. For this active control, PCE may keep OAM information 229 such as identifiers of Maintenance Entity Group(MEP), MEG End Point(MEG), 230 Trail Trace Identifier(TTI). This information is maintained for each path 231 and has an important role in automatic and dynamic path control 232 environment. 233 For highly automated services, Attachment Circuit(AC) database also is 234 Additional synchronization procedures and protocol definitions will be 235 added after consensus on this necessity in this or a separate document. 237 5. PCE-initiated LSP and PW instantiation and deletion 239 To initiate an LSP, a PCE sends a PCInitiate message to a PCC. The 240 message format, objects and TLVs are discussed separately below for 241 the creation and the deletion cases. 243 5.1. The LSP and PW Initiate Message 245 A Pseudowire Path Initiate Message (also referred to as PCInitiate 246 message) is a PCEP message sent by a PCE to a PCC to 247 trigger LSP instantiation or deletion. A PCInitiate message for LSP 248 instantiation is defined in [I-D.ietf-pce-pce-initiated-lsp]. 250 5.2. The D flag in the SRP Object 252 The format of the SRP object is shown Figure 2: 254 0 1 2 3 255 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 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 | Flags |C|D|R| 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 | SRP-ID-number | 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 | | 262 // Optional TLVs // 263 | | 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 Figure 4: The SRP Object format 268 The type object is defined in [I-D.ietf-pce-stateful-pce]. The R 269 bits are defined in [I-D.ietf-pce-pce-initiated-lsp]. 271 A new flag is defined to indicate a delete operation initiated by the 272 PCE: 274 C (ML-CASCADE-DELETE - 1 bit): If set to 1, it indicates a cascade 275 LSP removal request initiated by the PCE. 276 D (PW-DELETE - 1 bit): If set to 1, it indicates a removal request 277 initiated by the PCE. If both R and D set to 1, it indicates a 278 removal request of LSP and PW initiated by the PCE. 280 5.3. LSP and PW instantiation 282 LSP instantiation is done by sending an LSP Initiate Message with an 283 LSP object with the reserved PLSP-ID 0. The LSP is set up using 284 RSVP-TE, extensions for other setup methods are outside the scope of 285 this draft. 287 The END-POINTS, ERO, and LSP Object is defined in [ietf-pce-pce- 288 initiated-lsp]. 290 The symbolic name used for provisioning PCE-initiated Automatic Path must 291 not have conflict with the LSP name of any existing LSP in the PCC. 292 (Existing LSPs may 293 be either statically configured, or initiated by another PCE). 295 A PCC SHOULD be able to place a limit on the number of LSPs, PWs and 296 OAMs the percentage of resources that are allocated to honor PCE- 297 initiated LSP requests. 299 Similarly, the PCE SHOULD be able to place a limit on the number of 300 LSP or PW initiation requests pending for a particular PCC, or on the 301 time it waits for a response (positive or negative) to a PCInitiate 302 request from a PCC and MAY take further action (such as closing the 303 session or removing all its LSPs or PWs) if this limit is reached. 305 On succesful completion of the LSP and PW instantiation, The PCRpt 306 MUST include the SRP-ID-number of the PCInitiate request that triggered 307 its creation. PCE-initiated LSPs are identified with the Create flag in 308 the LSP Object. 310 The LSP object is defined in [I-D.ietf-pce-stateful-pce] and included 311 here for easy reference. 313 0 1 2 3 314 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 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 | PLSP-ID |Flags |C|P| O|A|R|S|D| 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 // TLVs // 319 | | 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 Figure 5: The LSP Object format 324 A new flag, the PW Create (P) flag is introduced. On a PCRpt message, 325 the P Flag set to 1 indicates that this LSP was created via a 326 PCInitiate message. The P Flag MUST be set to 1 on each PCRpt 327 message for the duration of existence of the LSP. The Create flag 328 allows PCEs to be aware of which LSPs were PCE-initiated (a state 329 that would otherwise only be known by the PCC and the PCE that 330 initiated them). 332 The optional SPEAKER-IDENTITY-ID TLV defined in 333 [I-D.ietf-pce-stateful-sync-optimizations] MAY be included in the LSP 334 and/or PW object in a PCRpt message, as an optional TLV for LSPs for 335 which the C-flag is 1. The SPEAKER-IDENTITY-ID TLV identifies the PCE 336 that initiated the creation of the LSP and/or PW on all PCEP sessions, a 337 state that would otherwise only be known by the PCC and the PCE that 338 initiated the LSP. If the TLV appears in a PCRpt for an LSP for which 339 the C flag is 0, the TLV MUST be ignored. 341 5.4. LSP and PW deletion 343 PCE-initiated removal of a PCE-initiated Automatic Path and/or PWs is 344 done by setting the R(LSP remove) and/or D (PW remove) flag in the SRP 345 Object in the PCInitiate message from the PCE. The LSP is identified by 346 the PLSP-ID in the LSP object. 347 Following the removal of the LSP and/or PW, the PCC MUST send a PCRpt 348 as described in [I-D.ietf-pce-stateful-pce]. The SRP object in the PCRpt 349 MUST include the SRP-ID-number from the PCInitiate message that triggered 350 the removal. The R and/or D flag in the SRP object SHOULD be set. 352 5.5. Automatic Restoration and Cascade Update 354 Upon PCNotify on link failure or CCM Error, PCE would compute and 355 initiate a new path. At this moment, PCE can apply the LSP policy on 356 mono-layer or inter-layer path. For instance, lower layer LSP may update 357 or delete by the policy flag on PCE-initiated deletion request. The 358 format will be described upon PCE WG discussion. 360 6. LSP and PW delegation and cleanup 362 PCE-initiated automatic paths are automatically delegated by the PCC 363 to the PCE upon instantiation. 364 To obtain control of a PCE-initiated LSP and PW, a PCE (either the 365 original or one of its backups) sends a PCInitiate message, including 366 just the SRP and LSP objects, and carrying the PLSP-ID. 367 PCE-initiated LSPs and PWs are cleaned up on the expiration of State 368 Timeout timer. 370 7. Manageability Considerations 371 TBD 373 8. IANA considerations 374 TBD 376 9. Security Considerations 377 TBD 379 10. Acknowledgements 381 This document borrows some of the structure and text from [I-D. draft- 382 ietf-pce-pce-initiated-lsp] and [I-D. draft-palle-pce-controller-labeldb- 383 sync], and would like to thanks the authors and contributors of the 384 document. 386 11. References 388 11.1. Normative References 390 [I-D.ietf-pce-stateful-pce] 391 Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP 392 Extensions for Stateful PCE", draft-ietf-pce-stateful- 393 pce-14 (work in progress), March 2016. 395 [I-D.ietf-pce-stateful-sync-optimizations] 396 Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X., 397 and D. Dhody, "Optimizations of Label Switched Path State 398 Synchronization Procedures for a Stateful PCE", draft- 399 ietf-pce-stateful-sync-optimizations-05 (work in 400 progress), April 2016. 402 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 403 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 404 DOI 10.17487/RFC5440, March 2009, 405 . 407 [RFC5921] Bocci, M., Bryant, S., Frost, D., Levrau, L., and L. 408 Berger, "A Framework for MPLS in Transport Networks", RFC 409 5921, July 2010. 410 11.2. Informative References 412 [I-D.ietf-pce-pce-initiated-lsp] 413 Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP 414 Extensions for PCE-initiated LSP Setup in a Stateful PCE 415 Model", draft-ietf-pce-pce-initiated-lsp-05 (work in 416 progress), October 2015. 418 [I-D.palle-pce-controller-labeldb-sync] 419 Palle, U. and D. Dhody, "LABEL-DB Synchronization 420 Procedures for a PCE as a central controller(PCECC)", 421 draft-palle-pce-controller-labeldb-sync-00 (work in 422 progress), May 2016. 424 Authors' Addresses 426 Eunyoung Cho 427 ETRI 428 218 Gajeongno, Yuseonggu, Daejeon, 34129 429 Korea (the Republic of) 431 Email: eycho@etri.re.kr 433 Taehyun Kwon 434 ETRI 435 218 Gajeongno, Yuseonggu, Daejeon, 34129 436 Korea (the Republic of) 438 Email: thkwon@etri.re.kr