PCE Working Group E. Cho Internet-Draft T. Kwon Intended status: Standards Track ETRI Expires: April 30, 2017 October 31, 2016 PCEP Extensions for PCE-initiated Automatic Path Setup in a Stateful PCE Model draft-cho-pce-initiated-auto-path-00 Abstract This document introduces an automatic setup and maintenance mechanism to compute, create, update and delete for a packet and/or optical layer path and pseudowire paths(PWs) via an extension to the Path Computation Element Communication Protocol(PCEP) and DB Synchronization procedures. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." Cho & Kwon Expires April 30, 2017 [Page 1] Internet-Draft PCE-initiated Automatic Path October 2016 This Internet-Draft will expire on April 30, 2017. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Support of PCE-initiated Automatic Path . . . . . . . . . . . 4 4.1. Stateful PCE Capability TLV . . . . . . . . . . . . . . . 4 4.2. PW-LABEL-DB Synchronization . . . . . . . . . . . . . . . 4 4.3. OAM-DB Synchronization . . .. . . . . . . . . . . . . . . 5 5. PCE-initiated LSP and PW instantiation and deletion . . . . . 6 5.1. The LSP and PW Initiate Message . . . .. . . . . . . . . 6 5.2. The D flag in the SRP Object . . . . . . . . . . . . . . 6 5.3. LSP and PW instantiation . . . . . . . . . . . . . . . . 7 5.4. LSP and PW deletion . . . . .. . . . . . . . . . . . . . 8 5.5. Automatic Restoration and Cascade Update . . . . . . . . 8 6. LSP and PW delegation and cleanup . . . . . . . . . . . . . 8 7. Manageability Considerations . . . . . . . . . . . . . . . . 9 8. IANA considerations . . . . . . . . . . . . . . . . . . . . . 9 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 11.1. Normative References . . . . . . . . . . . . . . . . . . 9 11.2. Informative References . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 Cho & Kwon Expires April 30, 2017 [Page 2] Internet-Draft PCE-initiated Automatic Path October 2016 1. Introduction Stateful pce [I-D.ietf-pce-stateful-pce] specifies a set of extensions to PCEP to enable stateful control of TE LSPs between and across PCEP sessions in compliance with [RFC4657]. It includes mechanisms to effect LSP state synchronization between PCCs and PCEs, delegation of control of LSPs to PCEs, and PCE control of timing and sequence of path computations within and across PCEP sessions This document describes the setup, maintenance and teardown of PCE- initiated LSPs and/or Pseudowires under the stateful PCE model allowing for automatic setup of an transport paths. 2. Terminology This document uses the following terms defined in [RFC5440]: PCC, PCE, PCEP Peer. This document uses the following terms defined in [I-D.ietf-pce-stateful-pce]: Stateful PCE, Delegation, Redelegation Timeout, State Timeout Interval Path State Report, Path Update Request. The following terms are defined in this document: PCE-initiated Automatic Path: Pseudowire and/or LSP that is instantiated as a result of a request from the PCE. 3. Motivation An active stateful PCE is able to provide an automated and optimized path as the role of central controller or NMS. In addition to PCE- initiated LSP, PCE may initiate pseudowire service automatically over LSP with extension of information and protocol. With OAM information, PCE would be able to trigger path restoration upon alarm notification. Therefore, this document introduces an automatic path management method with PCE-initiated paths setup using their pseudowire label and OAM database. It is a useful mechanism in multi-domain and multi-layer SDN and ACTN. Different setup of automatic paths may be offered: o LSP only: setup the label switched path in one request o PW only: setup the pseudowire paths in one request o LSP+PW: setup the LSP with the associated PWs in one request Cho & Kwon Expires April 30, 2017 [Page 3] Internet-Draft PCE-initiated Automatic Path October 2016 4. Support of PCE-initiated Automatic Path A PCEP speaker indicates its ability to support PCE provisioned dynamic LSPs and/or PWs during the PCEP Initialization phase. The Open Object in the Open message contains the "Stateful PCE Capability" TLV, defined in [I-D.ietf-pce-stateful-pce]. A new flag, the P (PW- INSTANTIATION-CAPABILITY) flag is introduced to indicate support for instantiation of PCE-initiated LSPs. A PCE can initiate LSPs with/without PWs for PCCs that advertised this capability and a PCC will follow the procedures described in this document only on sessions where the PCE advertised the P flag. 4.1. Stateful PCE Capability TLV The format of the STATEFUL-PCE-CAPABILITY TLV is shown in the following figure: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length=4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags |P|I|S|U| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+ Figure 1: STATEFUL-PCE-CAPABILITY TLV format The type of the TLV is defined in [I-D.ietf-pce-stateful-pce] and it has a fixed length of 4 octets. The value comprises a single field - Flags (32 bits). The I, U and S bits are defined in [I-D.ietf-pce-pce-initiated-lsp], [I-D.ietf-pce-stateful-pce] and [I-D.ietf-pce-stateful-sync- optimizations] respectively. P (PW-INSTANTIATION-CAPABILITY - 1 bit): If set to 1 by a PCC, the I Flag indicates that the PCC allows instantiation of an LSP by a PCE. If set to 1 by a PCE, the P flag indicates that the PCE may attempt to instantiate PWs over LSPs. The PW-INSTANTIATION-CAPABILITY flag must be set by both PCC and PCE in order to support PCE-initiated LSP instantiation. 4.2. PW-LABEL-DB Synchronization PCECC or NMS MUST maintain the PW-LABEL-DB for each PCEP session separately. Cho & Kwon Expires April 30, 2017 [Page 4] Internet-Draft PCE-initiated Automatic Path October 2016 The purpose of PW-LABEL-DB synchronization is to make sure that the PCE's view of PW-LABEL-DB matches with the PCC's PW-LABEL-DB. The PW-LABEL-DB synchronization MUST be performed from PCC to PCE immediately after the LSP state synchronization. [I-D.ietf-pce-stateful-pce] describes the basic mechanism for LSP state synchronization. +-+-+ +-+-+ |PCC| |PCE| +-+-+ +-+-+ | | |-PCLabelUpd, SYNC=1----->| (Sync start) | | |-PCLabelUpd, SYNC=1----->| | . | | . | | . | |-PCLabelUpd, SYNC=0----->| (End of sync marker | | Label Update | | PW LABEL=0) | | (Sync done) Figure 2: PW-LABEL-DB synchronization Further synchronization procedures and protocol definitions will be added after consensus on this necessity in this or a separate document. 4.3. OAM-DB Synchronization PCECC or NMS MUST maintain the OAM-DB for each PCEP session separately. The purpose of OAM-DB synchronization is to make sure that the PCE's view of OAM-DB matches with the PCC's OAM-DB. The OAM- DB synchronization MUST be performed from PCC to PCE immediately after the LSP state synchronization. [I-D.ietf-pce-stateful-pce] describes the basic mechanism for LSP state synchronization. +-+-+ +-+-+ |PCC| |PCE| +-+-+ +-+-+ | | |---PCOAMUpd, SYNC=1----->| (Sync start) | | |---PCOAMUpd, SYNC=1----->| | . | | . | | . | |---PCOAMUpd, SYNC=0----->| (End of sync marker | | Label Update | | OAM =0) | | (Sync done) Figure 3: OAM-DB synchronization Cho & Kwon Expires April 30, 2017 [Page 5] Internet-Draft PCE-initiated Automatic Path October 2016 Upon alarm notification on link or path, PCE can compute and initiate restoration path. For this active control, PCE may keep OAM information such as identifiers of Maintenance Entity Group(MEP), MEG End Point(MEG), Trail Trace Identifier(TTI). This information is maintained for each path and has an important role in automatic and dynamic path control environment. For highly automated services, Attachment Circuit(AC) database also is Additional synchronization procedures and protocol definitions will be added after consensus on this necessity in this or a separate document. 5. PCE-initiated LSP and PW instantiation and deletion To initiate an LSP, a PCE sends a PCInitiate message to a PCC. The message format, objects and TLVs are discussed separately below for the creation and the deletion cases. 5.1. The LSP and PW Initiate Message A Pseudowire Path Initiate Message (also referred to as PCInitiate message) is a PCEP message sent by a PCE to a PCC to trigger LSP instantiation or deletion. A PCInitiate message for LSP instantiation is defined in [I-D.ietf-pce-pce-initiated-lsp]. 5.2. The D flag in the SRP Object The format of the SRP object is shown Figure 2: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags |C|D|R| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SRP-ID-number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // Optional TLVs // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: The SRP Object format The type object is defined in [I-D.ietf-pce-stateful-pce]. The R bits are defined in [I-D.ietf-pce-pce-initiated-lsp]. A new flag is defined to indicate a delete operation initiated by the PCE: C (ML-CASCADE-DELETE - 1 bit): If set to 1, it indicates a cascade LSP removal request initiated by the PCE. D (PW-DELETE - 1 bit): If set to 1, it indicates a removal request initiated by the PCE. If both R and D set to 1, it indicates a removal request of LSP and PW initiated by the PCE. Cho & Kwon Expires April 30, 2017 [Page 6] Internet-Draft PCE-initiated Automatic Path October 2016 5.3. LSP and PW instantiation LSP instantiation is done by sending an LSP Initiate Message with an LSP object with the reserved PLSP-ID 0. The LSP is set up using RSVP-TE, extensions for other setup methods are outside the scope of this draft. The END-POINTS, ERO, and LSP Object is defined in [ietf-pce-pce- initiated-lsp]. The symbolic name used for provisioning PCE-initiated Automatic Path must not have conflict with the LSP name of any existing LSP in the PCC. (Existing LSPs may be either statically configured, or initiated by another PCE). A PCC SHOULD be able to place a limit on the number of LSPs, PWs and OAMs the percentage of resources that are allocated to honor PCE- initiated LSP requests. Similarly, the PCE SHOULD be able to place a limit on the number of LSP or PW initiation requests pending for a particular PCC, or on the time it waits for a response (positive or negative) to a PCInitiate request from a PCC and MAY take further action (such as closing the session or removing all its LSPs or PWs) if this limit is reached. On succesful completion of the LSP and PW instantiation, The PCRpt MUST include the SRP-ID-number of the PCInitiate request that triggered its creation. PCE-initiated LSPs are identified with the Create flag in the LSP Object. The LSP object is defined in [I-D.ietf-pce-stateful-pce] and included here for easy reference. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PLSP-ID |Flags |C|P| O|A|R|S|D| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // TLVs // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: The LSP Object format A new flag, the PW Create (P) flag is introduced. On a PCRpt message, the P Flag set to 1 indicates that this LSP was created via a PCInitiate message. The P Flag MUST be set to 1 on each PCRpt message for the duration of existence of the LSP. The Create flag allows PCEs to be aware of which LSPs were PCE-initiated (a state that would otherwise only be known by the PCC and the PCE that initiated them). Cho & Kwon Expires April 30, 2017 [Page 7] Internet-Draft PCE-initiated Automatic Path October 2016 The optional SPEAKER-IDENTITY-ID TLV defined in [I-D.ietf-pce-stateful-sync-optimizations] MAY be included in the LSP and/or PW object in a PCRpt message, as an optional TLV for LSPs for which the C-flag is 1. The SPEAKER-IDENTITY-ID TLV identifies the PCE that initiated the creation of the LSP and/or PW on all PCEP sessions, a state that would otherwise only be known by the PCC and the PCE that initiated the LSP. If the TLV appears in a PCRpt for an LSP for which the C flag is 0, the TLV MUST be ignored. 5.4. LSP and PW deletion PCE-initiated removal of a PCE-initiated Automatic Path and/or PWs is done by setting the R(LSP remove) and/or D (PW remove) flag in the SRP Object in the PCInitiate message from the PCE. The LSP is identified by the PLSP-ID in the LSP object. Following the removal of the LSP and/or PW, the PCC MUST send a PCRpt as described in [I-D.ietf-pce-stateful-pce]. The SRP object in the PCRpt MUST include the SRP-ID-number from the PCInitiate message that triggered the removal. The R and/or D flag in the SRP object SHOULD be set. 5.5. Automatic Restoration and Cascade Update Upon PCNotify on link failure or CCM Error, PCE would compute and initiate a new path. At this moment, PCE can apply the LSP policy on mono-layer or inter-layer path. For instance, lower layer LSP may update or delete by the policy flag on PCE-initiated deletion request. The format will be described upon PCE WG discussion. 6. LSP and PW delegation and cleanup PCE-initiated automatic paths are automatically delegated by the PCC to the PCE upon instantiation. To obtain control of a PCE-initiated LSP and PW, a PCE (either the original or one of its backups) sends a PCInitiate message, including just the SRP and LSP objects, and carrying the PLSP-ID. PCE-initiated LSPs and PWs are cleaned up on the expiration of State Timeout timer. Cho & Kwon Expires April 30, 2017 [Page 8] Internet-Draft PCE-initiated Automatic Path October 2016 7. Manageability Considerations TBD 8. IANA considerations TBD 9. Security Considerations TBD 10. Acknowledgements This document borrows some of the structure and text from [I-D. draft- ietf-pce-pce-initiated-lsp] and [I-D. draft-palle-pce-controller-labeldb- sync], and would like to thanks the authors and contributors of the document. 11. References 11.1. Normative References [I-D.ietf-pce-stateful-pce] Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP Extensions for Stateful PCE", draft-ietf-pce-stateful- pce-14 (work in progress), March 2016. [I-D.ietf-pce-stateful-sync-optimizations] Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X., and D. Dhody, "Optimizations of Label Switched Path State Synchronization Procedures for a Stateful PCE", draft- ietf-pce-stateful-sync-optimizations-05 (work in progress), April 2016. [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, DOI 10.17487/RFC5440, March 2009, . [RFC5921] Bocci, M., Bryant, S., Frost, D., Levrau, L., and L. Berger, "A Framework for MPLS in Transport Networks", RFC 5921, July 2010. 11.2. Informative References [I-D.ietf-pce-pce-initiated-lsp] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP Extensions for PCE-initiated LSP Setup in a Stateful PCE Model", draft-ietf-pce-pce-initiated-lsp-05 (work in progress), October 2015. [I-D.palle-pce-controller-labeldb-sync] Palle, U. and D. Dhody, "LABEL-DB Synchronization Procedures for a PCE as a central controller(PCECC)", draft-palle-pce-controller-labeldb-sync-00 (work in progress), May 2016. Cho & Kwon Expires April 30, 2017 [Page 9] Internet-Draft PCE-initiated Automatic Path October 2016 Authors' Addresses Eunyoung Cho ETRI 218 Gajeongno, Yuseonggu, Daejeon, 34129 Korea (the Republic of) Email: eycho@etri.re.kr Taehyun Kwon ETRI 218 Gajeongno, Yuseonggu, Daejeon, 34129 Korea (the Republic of) Email: thkwon@etri.re.kr Cho & Kwon Expires April 30, 2017 [Page 10]