| PCE Working Group | Y. Zhuang |
| Internet-Draft | Q. Wu |
| Intended status: Standards Track | D. Dhody |
| Expires: June 25, 2017 | Huawei |
| D. Ceccarelli | |
| Ericsson | |
| December 22, 2016 |
PCEP Extensions for LSP scheduling with stateful PCE
draft-zhuang-pce-stateful-pce-lsp-scheduling-04
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 as stated in [I.D.ietf-teas-scheduled-resources].
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 June 25, 2017.
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.
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 usage and allocation of network resources, especially bandwidth, 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. [I-D.ietf-teas-scheduled-resources] then provides a framework that describes and discusses the problem and propose an appropriate architecture for the scheduled reservation of TE resources.
With the scheduled reservation of TE resources, it allows network operators to reserve resources in advance according to the agreements with their customers, and allow them to transmit data with scheduling such as 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. Also, for deterministic networks, the scheduled LSP can provide a better network resource usage for guaranteed links. This idea can also be applied in segment routing to schedule the network resources over the whole network in a centralized manner as well.
With this in mind, 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 is characterized by a starting time and a duration. When the end of the LSP life is reached, it is deleted to free up the resources for other LSP (scheduled or not).
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 re-used from existing PCE documents.
In addition, this document defines the following terminologies.
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 for Packet-switched network, as well as the ability 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] as well as discussions in [I-D.ietf-teas-scheduled-resources], doing this as a part of PCEP in a centralized manner, 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. 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.
Furthermore, a scheduled TED can be generated from the scheduled LSP DB, LSP DB and TED to indicate the network links and nodes with resource availability information for now and future. The scheduled TED should be maintained by all PCEs within the network environment.
In case of implementing PCC-initiated scheduled LSPs, a PCC can request a path computation with LSP information of its scheduling parameters, including the starting time and the duration. Upon receiving the request with the scheduled LSP delegation, a stateful PCE SHALL check the scheduled TED for the network resource availability on network nodes and computes a path for the LSP with the scheduling information.
For a multiple PCE environment, in order to coordinate the scheduling request of the LSP path over the network, the PCE needs to send a requestmessage with the path information as well as the scheduled resource for the scheduled LSP to other PCEs within the network, so as to coordinate with their scheduled LSP DBs and scheduled TEDs. Once other PCEs receive the request message with the scheduled LSPs information, if not conflicting with their scheduled LSP DBs, they reply to the requesting PCE with a response message carrying the scheduled LSP and update their scheduled LSP DBs and scheduled TEDs. After the requesting PCE confirms with all PCEs, the PCE SHALL add the scheduled LSP into its scheduled LSP Database and update its scheduled TED.
Then the stateful PCE can response to the PCC with the path for the scheduled LSP to notify the result of the computation. However, the PCC should not signal the LSP over the path once receiving these messages since the path is not activated yet until its starting time.
Alternatively, the service can also be initiated by PCE itself. In case of implementing PCE-initiated scheduled LSP, the stateful PCE shall check the network resource availability for the traffic and computes a path for the scheduled LSP per request in the same way as in PCC- Initiated mode and then for a multiple PCE network environment, coordinate the scheduled LSP with other PCEs in the network in the same way as in the PCC-Initiated mode.
In both modes, for activation of scheduled LSPs, the stateful PCE can send a path computation LSP Initiate (PCInitiate message) with LSP information at its starting time to the PCC for signaling the LSP over the network nodes as defined in [I-D.ietf-pce-pce- initiated-lsp]. Also, in the PCC-initiated mode, with scheduling information ,the PCC can activate the LSP itself by triggering over the path at its starting time as well. When the scheduling usage expires, active stateful PCE SHALL remove the LSP from the network , as well as notify other PCEs to delete the scheduled LSP from the scheduled LSP database.
After a TCP connection for a PCEP session has been established, a PCC and a PCE indicates its ability to support LSP scheduling during the PCEP session establishment phase. For a multiple-PCE environment, the PCEs should also establish PCEP session and indicate its ability to support LSP scheduling among PCEP peers. The Open Object in the Open message contains the STATEFUL-PCE-CAPABILITY TLV defined in [I- D.ietf-pce-stateful-pce]. Note that the STATEFUL- PCE-CAPABILITY TLV is 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]. In this document, we define a new flag bit B (SCHED-LSP-CAPABLITY) flag for the STATEFUL- PCE-CAPABILITY TLV to indicate the support of LSP scheduling.
In order to realize PCC-Initiated 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 request and get 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 request (PCReq) message (see section 4.3.1) or a path computation LSP report (PCRpt) message (see section 4.3.1) including its demanded resources with the scheduling information 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 stored in scheduled TED (see section 4.1).
If a resultant path is found, the stateful PCE will send a PCReq message with the path information as well as the scheduled resource information for the scheduled LSP to other PCEs within the network if there is any, so as to keep their scheduling information synchronized.
Once other PCEs receive the PCReq message with the scheduled LSP, if not conflicts with their scheduled LSP DBs, they will reply to the requesting PCE with a PCRep message carrying the scheduled LSP and update their scheduled LSP DBs and scheduled TEDs. After the requesting PCE confirms with all PCEs, the PCE SHALL add the scheduled LSP into its scheduled LSP DB and update its scheduled TED. If conflicts happen or no path available is found, the requesting PCE SHALL return a PCRep message with NO PATH back to the PCC. Otherwise, the stateful PCE will send a PCRep message or PCUpd message (see section 4.3.3) with the path information back to the PCC as confirmation.
For PCE-Initiated Scheduled LSP, the stateful PCE can compute a path for the scheduled LSP per requests from network management systems automatically based on the network resource availability in the scheduled TED and coordinate with other PCEs on the scheduled LSP in the same way as in the PCC- Initiated mode.
In both modes:
After scheduled LSP capability negotiation, for PCC-Initiated mode, a PCC can send a PCReq message or a PCRpt message including the SCHED-LSP- ATTRIBUTE TLV (see section 4.3.4.1) carried in the LSP Object (see section 4.3.4) 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].
Meanwhile, for both modes (PCC-Initiated and PCE-Initiated), the delegated PCE shall distribute the scheduling information to other PCEs in the environment by sending a PCReq message with the SCHED-LSP-ATTRIBUTE TLV, as well as the Bandwith Object and RRO for the found path.
The definition of the PCReq message and 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 PCReq message based on network resource availability recorded in scheduled TED which is generated from the scheduled LSP-DB and TED and also synchronize the scheduling with other PCEs in the environment by using PCReq message with path and resource information for the scheduled LSP.
If no conflict exists, other PCEs SHALL send a PCRep message with the SCHED-LSP-ATTRIBUTE TLV, as well as the Bandwith Object and RRO back to the requesting PCE.
If the LSP request can be satisfied and an available path is found, the stateful PCE SHALL send a PCRep Message including the SCHED- LSP- ATTRIBUTE TLV in the LSP Object body, as well as the Bandwith Object and RRO for the found path back to the PCC as a successful acknowledge.
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 scheduled TED which is generated from the scheduled LSP-DB, LSP DB and TED.
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 to the PCC Note that, the stateful PCE can update the Scheduled LSP parameters later as well based on any network events using the same PCUpd message.
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 PCReq 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Starting 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 starting 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.
Editor Note: As described in [I-D.zhuang-teas-scheduled-resources],the encoding of the resource state information could also be expressed as a start time and and end time. Multiple periods, possibly of different lengths, may be associated with one reservation request, and a reservation might repeat on a regular cycle.
In PCC-Initiated LSP scheduling, the PCC itself MAY activate the scheduled LSP at the starting time. Alternatively, the stateful PCE MAY activate the scheduled LSP at its scheduled time by send a PCInitiated message.
After the scheduled duration expires, the PCE shall send a PCUpd message with R flag set to the PCC to delete the LSP over the path, as well as to other PCEs to remove the scheduled LSP in the databases. Additionally, it shall update its scheduled LSP DB and scheduled TED.
Note that, the stateful PCE can update the Scheduled LSP parameters at any time based on any network events using the PCUpd message including SCHED-LSP-ATTRIBUTE TLV in the LSP Object body.
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 work has benefited from the discussions of resource scheduling on the mailing list and with Huaimo chen, author of [I-D.chen-pce-tts] since Prague meeting. We gratefully acknowledge the contributions of Huaimo Chen. The authors of this document would also like to thank Rafal Szarecki,Adrian Farrel, Cyril Margaria, Xian Zhang for the review and comments.
| [I-D.dhody-pce-stateful-pce-auto-bandwidth] | Dhody, D., Palle, U., Singh, R., Gandhi, R. and L. Fang, "PCEP Extensions for MPLS-TE LSP Automatic Bandwidth Adjustment with Stateful PCE", Internet-Draft draft-dhody-pce-stateful-pce-auto-bandwidth-09, November 2016. |
| [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-07, July 2016. |
| [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-18, December 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", Internet-Draft draft-ietf-pce-stateful-sync-optimizations-07, December 2016. |
| [I-D.ietf-teas-scheduled-resources] | Zhuangyan, Z., Wu, Q., Chen, H. and A. Farrel, "Architecture for Scheduled Use of Resources", Internet-Draft draft-ietf-teas-scheduled-resources-01, November 2016. |
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |
| [RFC5440] | Vasseur, JP. and JL. Le Roux, "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, DOI 10.17487/RFC5440, March 2009. |
| [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-08, October 2016. |
| [RFC5226] | Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008. |
| [RFC7420] | Koushik, A., Stephan, E., Zhao, Q., King, D. and J. Hardwick, "Path Computation Element Communication Protocol (PCEP) Management Information Base (MIB) Module", RFC 7420, DOI 10.17487/RFC7420, December 2014. |
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 by using PCReq message, PCRep message with scheduled LSP information. In order to synchronize the scheduled LSP information in SLSP-DB among PCEs, the PCReq message and PCRep Message is used as described in section 4.3.1 and section 4.3.2.
To achieve the synchronization, the PCE should generate and maintain a scheduled TED based on LSP DB, scheduled LSP DB and TED, which is used to indicate the network resource availability on network nodes for LSP path computation.
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