| PCE Working Group | Y. Zhuang |
| Internet-Draft | Q. Wu |
| Intended status: Standards Track | D. Dhody |
| Expires: December 31, 2015 | Huawei |
| June 29, 2015 |
PCEP Extensions for LSP scheduling with stateful PCE
draft-zhuang-pce-stateful-pce-lsp-scheduling-00
This document proposes a set of extensions needed to the stateful Path Computation Element (PCE) communication Protocol (PCEP), so as to enable Labeled Switched Path (LSP) scheduling for path computation and LSP setup/deletion based on the actual network resource usage duration of a traffic service in a centralized network environment. A scheduled LSP can be setup at the its starting time and deleted after its usage duration such that LSPs for the other traffic services can take over these network resources beyond that period.
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."
This Internet-Draft will expire on December 31, 2015.
Copyright (c) 2015 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.
The Path Computation Element Protocol (PCEP) defined in [RFC5440] is used between a Path Computation Element (PCE) and a Path Computation Client (PCC) (or other PCE) to enable computation of Multi-protocol Label Switching (MPLS) for Traffic Engineering Label Switched Path (TE LSP).
Further, in order to support use cases described in [I-D.ietf-pce- stateful-pce-app], [I-D.ietf-pce-stateful-pce] specifies a set of extensions to PCEP to enable stateful control of MPLS-TE and GMPLS LSPs via PCEP.
Traditionally, the network resources, especially bandwidth, usage and allocation can be supported by a Network Management System operation such as path pre-establishment. However, this does not provide efficient network usage since the established paths exclude the possibility of being used by other services even when they are not used for undertaking any service.
With LSP scheduling, it allows network operators to reserve resources in advance according to the agreements with their customers, and allow them to transmit data with specified starting time and duration, for example for a scheduled bulk data replication between data centers. It enables the activation of bandwidth usage at the time the service really being used while letting other services obtain it in spare time. The requirement of scheduled LSP provision is mentioned in [I-D.ietf-pce-stateful-pce-app] and [RFC7399], so as to provide more efficient network resource usage for traffic engineering, which hasn't been solved yet.
This document proposes a set of extensions needed to the stateful PCE, so as to enable LSP scheduling for path computation and LSP setup/deletion based on the actual network resource usage duration of a traffic service. A scheduled LSP can be setup at the its starting time and deleted after its usage duration such that LSPs for the other traffic services can take over these network resources beyond that period.
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 [RFC2119].
The following terminologies are used in this document:
A stateful PCE can support better efficiency by using LSP scheduling described in the use case of [I-D.ietf-pce-stateful-pce]. This requires the PCE to maintain the scheduled LSPs and their associated resource usage, e.g. bandwidth, as well as the ability for PCC to trigger signaling for the LSP setup/tear-down at the correct time.
Note that existing configuration tools can be used for LSP scheduling, but as highlighted in section 3.1.3 of [I-D.ietf-pce-stateful-pce], doing this as a part of PCEP, has obvious advantages.
The objective of this document is to provide a set of extensions to PCEP to enable LSP scheduling for LSPs creation/deletion under the stateful PCE control, according to traffic services from customers, so as to improve the usage of network resources.
The LSP scheduling allows PCEs and PCCs to provide scheduled LSP for customers' traffic services at its actual usage time, so as to improve the network resource efficient utilization.
For stateful PCE supporting LSP scheduling, there are two types of LSP databases used in this document. One is the LSP-DB defined in PCEP [I-D.ietf-pce-stateful-pce], while the other is the scheduled LSP database (SLSP- DB, see section 6). The SLSP-DB records scheduled LSPs and is used as a complementary to the TED and LSP-DB to show the network resource availability for path computation. Note that the two types of LSP databases can be implemented in one physical database or two different databases. This document does not state any preference here.
In case of implementing PCC-initiated scheduled LSPs, at the time of delegation,a PCC can send a path computation LSP State Report message (PCRpt message) with LSP information of its starting time and the duration. Upon receiving the PCRpt message with the scheduled LSP delegation, a stateful PCE SHALL not only check the current network resource availability recorded in the Traffic Engineering Database (TED) and LSP-DB, but also consider scheduled resource reservation for scheduled LSPs in the SLSP-DB and then the stateful PCE sends the path for the scheduled LSP in an LSP Update Request carried in a PCUpd message to the PCC. Note that PCE can either calculate the path for scheduled LSP based on current information and update it later at any time based on network events or PCE MAY chooses to calculate the path closer to the activation time.
In case of implementing PCE-Initiated Scheduling LSP, the stateful PCE can send a path computation LSP Initiate (PCInitiate message) with LSP information at its starting time and duration to reserve a path. In addition, the stateful PCE may send PCUpd message at the time of activation to activate the path.
In case of PCE Initiated LSP, it is recommended that PCE send PCInitiate at creation time so that these scheduled LSP is known at PCC and it can be further syncronized to other PCE as well. . At any time, stateful PCE may change the attribute of a scheduled LSP by sending the PCUpd message.
Based on PCUpd or PCInitiate message, a PCC creates a LSP with scheduled LSP information. This scheduled LSP MUST be added into the SLSP-DB and synchronized among PCEs and PCC via PCRpt message. For a scheduled LSP, a PCC MUST not trigger signaling for LSP setup at its creation time but wait until its starting time.
For setup/activation of scheduled LSPs, PCC MAY activate the LSP at the starting time or PCE MAY control the activation, with active stateful PCE notifies the PCC that the status of the scheduled LSP has been changed and it SHOULD trigger signaling for the LSP setup. When the requested usage duration expires, PCC or active stateful PCE removes the LSP from the data base.
The following terms are used in this document:
After a TCP connection for a PCEP session has been established, the PCE or the PCC can send an Open Message with the B flag in Stateful PCE Capability TLV set to 1 described in [section 4.2] to indicate that it supports LSP scheduling to its peer. The definition of the Open message (see [RFC5440]) is unchanged.
A PCC and a PCE indicates its ability to support LSP scheduling during the PCEP session establishment 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 is defined for the STATEFUL-PCE-CAPABILITY TLV defined in [I-D.ietf-pce-stateful-pce] and updated in [I-D.ietf-pce-pce-initiated-lsp] and [I-D.ietf-pce-stateful-sync-optimizations].
A new bit B (SCHED-LSP-CAPABLITY) flag is added in this document to indicate the support of LSP scheduling.
In order to realize scheduled LSP in a centralized network environment, a PCC has to separate the setup of a LSP into two steps. The first step is to create a LSP but not signal it over the network. The second step is to signal the scheduled LSP over the LSRs (Labeled switched Router) at its starting time.
For PCC Initiated scheduled LSPs, a PCC can send a path computation LSP report (PCRpt) message (see section 4.3.1) including its demanded resources with the starting time and its usage duration and delegation to a stateful PCE.
Upon receiving the delegation via PCRpt message, the stateful PCE computes the path for the scheduled LSP per its starting time and duration based on the network resource availability from traffic engineering database (TED) (defined in [RFC5440]) and LSP-DB (defined in [I-D.ietf-pce-stateful-pce]), as well as scheduled resource reservation in the SLSP-DB (see section 6).
If a resultant path is found, the stateful PCE will send a PCUpd message (see section 5.x) with path information back to the PCC as defined in [I-D.ietf-pce-stateful-pce].
For PCE-Initiated Scheduled LSP, the stateful PCE can send a path computation LSP Initiate (PCInitiate message) with LSP information at its starting time and duration to reserve a path.
Upon receiving the PCInitiate or PCUpd message for scheduled LSP from PCEs, tThe PCC then creates a scheduled LSP including the scheduled LSP information for the traffic but not trigger signaling for the LSP setup on LSRs.
Note that PCE can either calculate the path for scheduled LSP based on current information and update it later at any time based on network events or PCE MAY chooses to calculate the path closer to the activation time. In any case, stateful PCE can update the Sheduled LSP parameters on any network events using the PCUpd message.
After scheduled LSP capability negotiation and for PCC Initiated scheduled LSPs, PCC can send a PCRpt message including the SCHED-LSP-ATTRIBUTE TLV (see section 4.3.3.1) carried in the LSP Object (see section 4.3.3) body to indicate the requested LSP scheduling parameters for a customer's traffic service with the delegation bit set to 1 in LSP Object. The value of requested bandwidth is taken via the existing 'Requested Bandwidth with BANDWIDTH Object- Type as 1' defined in [RFC5440].
The definition of the PCRpt message to carry LSP objects (see [I- D.ietf-pce-stateful-pce]) remains unchanged.
To provide scheduled LSP for TE-LSPs, the stateful PCE SHALL compute the path for the scheduled LSP carried on PCRpt message based on network resource availability recorded in TED, LSP-DB and SLSP-DB.
If the request can be satisfied and an available path is found, the stateful PCE SHALL send a PCUpd Message including the SCHED- LSP-ATTRIBUTE TLV in the LSP Object body.
Note that, the stateful PCE can update the Sheduled LSP parameters later as well based on any network events using the same PCUpd message.
To provide scheduled LSP for TE-LSPs, the stateful PCE SHALL compute the path for the requesting traffic based on network resource availability recorded in TED, LSP-DB and SLSP-DB.
If the request can be satisfied the stateful PCE SHALL send a PCInitiate Message including the SCHED-LSP-ATTRIBUTE TLV in the LSP Object body to request PCC to create a scheduled LSP.
PCE can either calculate the path at initiation and update it later at any time based on network events or PCE MAY chooses to calculate the path closer to the activation time.
The LSP object is defined in [I-D.ietf-pce-stateful-pce]. This document add an optional SCHED-LSP-ATTRIBUTE TLV.
The presence of SCHED-LSP-ATTRIBUTE TLV in the LSP object indicates that this LSP is requesting scheduled parameters. The TLV MUST be present in LSP Object for each scheduled LSP carried in the PCInitiate message, the PCRpt message and the PCUpd message.
The SCHED-LSP-ATTRIBUTE TLV can be included as an optional TLV within the LSP object for LSP scheduling for the requesting traffic service.
This TLV SHOULD be included only if both PCEP peers have set the B (LSP-SCHEDULING-CAPABILITY bit) in STATEFUL-PCE-CAPABILITY TLV carried in open message.
The format of the SCHED-LSP-ATTRIBUTE 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Start Time (minutes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Duration (minutes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The type of the TLV is [TBD] and it has a fixed length of 8 octets.
The fields in the format are:
Note, that the values of start time and duration is from the perspective of the PCEP peer that is sending the message, also note the unit of time is minutes, and thus the time spent on transmission on wire can be easily ignored.
As for a stateful PCE, it maintains a database of LSPs (LSP-DB) that are active in the network, so as to reveal the available network resources and place new LSPs more cleverly.
With the scheduled LSPs, they are not activated while creation, but should be considered when operating future path computation. Hence, a scheduled LSP Database (SLSP-DB) is suggested to maintain all scheduled LSP information.
The information of SLSP-DB MUST be shared and synchronized among all PCEs within the centralized network. In order to synchronize the scheduled LSP information in SLSP-DB among PCEs and PCCs, the PCRpt Message is used as before.
It is the responsibility of PCC to report the scheduled LSPs to all PCEs via a PCRpt message. The message shall include the SCHED-LSP-ATTRIBUTE TLV within the LSP Object.
Since the scheduled LSP is not signaled over the path yet, the mandatory LSP identifiers TLV should be all zero as defined in [I-D.ietf-pce-stateful-pce] but with the PLSP-ID for the LSP specified in the LSP object.
Upon receiving the PCRpt message with scheduled LSP information, the PCE SHALL update the scheduled LSP information with its PLSP-ID into the SLSP-DB for further path computation.
In case of PCC initiated scheduled LSP, the PCC MAY delegate the scheduled LSP to an active stateful PCE via the PCRpt message with the D Flag set to 1 as stated in [I-D.ietf-pce-stateful-pce]. The scheduled LSP is created but not signaled over the LSRs.
The stateful PCE MAY send a PCUpd Message including the SCHED- LSP-ATTRIBUTE TLV in the LSP Object body with the path now or later closer to the setup time.
Note that, the stateful PCE can update the Sheduled LSP parameters at any time based on any network events using the same PCUpd message.
The PCC itself MAY activate the scheduled LSP at the starting time indicated in the SCHED-LSP-ATTRIBUTE TLV carried on PCUpd message or PCInitiate message by signaling the LSP over LSRs. Alternatively, the active stateful PCE MAY activate the scheduled LSP immediately by using PCUpd message with A flag set (see section 4.5.2) to request the PCC to setup/activate the LSP.
After the scheduled duration expires, the PCC itself MAY delete the LSP and release the resources and report the same to the PCEs. Or, the active stateful PCE SHALL notify the PCC to delete the LSP and release the resources immediately via a PCUpd message with the R Flag set to 1 and the A Flag set to zero in the SRP object(see section 4.5.2). Upon receiving this message, the PCC shall trigger tear down to delete the LSP over the network. Moreover, it SHALL notify all PCEs of deletion of this LSP via a PCRpt Message.
Note that, the stateful PCE can update the Sheduled LSP parameters at any time based on any network events using the PCUpd message including SCHED-LSP-ATTRIBUTE TLV in the LSP Object body.
PCC can activate and delete the scheduled LSP on its own based on the parameters in the SCHED-LSP-ATTRIBUTE TLV, but in some case PCE may override it and request PCC to activate or remove the LSP immediately.
When the scheduled LSP needs to be activated, the active stateful PCE MAY send a PCUpd message with the A Flag set to 1 in the SRP object(see section 8.1) as well as ERO of the path for the LSP. Upon receiving this PCUpd message, the PCC MUST trigger signaling to setup the LSP over the network nodes immediately.
When the scheduled LSP needs to be removed, the active stateful PCE SHALL request the PCC to delete the LSP and release the resources for it via a PCUpd message with the R Flag set to 1 and the A Flag set to zero in the SRP object(see section 4.4.2).
The SRP Object is defined in [I-D.ietf-pce-stateful-pce] and a new flag is added to indicate activation of a scheduled LSP:
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 |A|R| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SRP-ID-number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // Optional TLVs // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The R bit in flags field is defined in [I-D. ietf-pce-pce-initiated-lsp].
This document defines LSP-SCHEDULING-CAPABILITY TLV and SCHED- LSP-ATTRIBUTE TLV which does not add any new security concerns beyond those discussed in [RFC5440] and [I-D.ietf-pce-stateful-pce].
The LSP-Scheduling feature MUST BE controlled per tunnel by the active stateful PCE, the values for parameters like starting time, duration SHOULD BE configurable by customer applications and based on the local policy at PCE.
[RFC7420] describes the PCEP MIB, there are no new MIB Objects for this document.
Mechanisms defined in this document do not imply any new liveness detection and monitoring requirements in addition to those already listed in [RFC5440].
Mechanisms defined in this document do not imply any new operation verification requirements in addition to those already listed in [RFC5440].
Mechanisms defined in this document do not imply any new requirements on other protocols.
Mechanisms defined in this document do not have any impact on network operations in addition to those already listed in [RFC5440].
Value Meaning Reference TBD SCHED-LSP-ATTRIBUTE This document
This document defines the following new PCEP TLV; IANA is requested to make the following allocations from this registry.
This document requests that a registry is created to manage the Flags field in the STATEFUL-PCE-CAPABILITY TLV in the OPEN object. New values are to be assigned by Standards Action [RFC5226]. Each bit should be tracked with the following qualities:
Bit Description Reference 28 LSP-SCHEDULING-CAPABILITY (B-bit) This document
The following values are defined in this document:
This document requests that a registry is created to manage the Flags field in the SRP object. New values are to be assigned by Standards Action [RFC5226]. Each bit should be tracked with the following qualities:
Bit Description Reference
30 ACTIVATING-LSP This document
The following values are defined in this document:
| [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", Internet-Draft draft-ietf-pce-pce-initiated-lsp-04, April 2015. |
| [I-D.ietf-pce-stateful-pce] | Crabbe, E., Minei, I., Medved, J. and R. Varga, "PCEP Extensions for Stateful PCE", Internet-Draft draft-ietf-pce-stateful-pce-11, April 2015. |
| [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", Internet-Draft draft-ietf-pce-stateful-sync-optimizations-02, January 2015. |
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |
| [I-D.ietf-pce-stateful-pce-app] | Zhang, X. and I. Minei, "Applicability of a Stateful Path Computation Element (PCE)", Internet-Draft draft-ietf-pce-stateful-pce-app-04, April 2015. |
Zitao Wang Huawei 101 Software Avenue, Yuhua District Nanjing, Jiangsu 210012 China Email: wangzitao@huawei.com Xian Zhang Huawei Technologies Research Area F3-1B, Huawei Industrial Base, Shenzhen, 518129, China Email: zhang.xian@huawei.com