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
Abstract
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].
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."
This Internet-Draft will expire on June 25, 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
Zhuang, et al. Expires June 25, 2017 [Page 1]
Internet-Draft LSP Scheduling December 2016
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions used in this document . . . . . . . . . . . . . . 3
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
3. Motivation and Objectives . . . . . . . . . . . . . . . . . . 5
4. Architecture Overview . . . . . . . . . . . . . . . . . . . . 5
4.1. LSP scheduling Overview . . . . . . . . . . . . . . . . . 5
4.2. Support of LSP Scheduling . . . . . . . . . . . . . . . . 6
4.2.1. Stateful PCE Capability TLV . . . . . . . . . . . . . 6
4.3. Scheduled LSP creation . . . . . . . . . . . . . . . . . 7
4.3.1. The PCReq message and PCRpt Message . . . . . . . . . 8
4.3.2. The PCRep Message . . . . . . . . . . . . . . . . . . 9
4.3.3. The PCUpd Message . . . . . . . . . . . . . . . . . . 9
4.3.4. LSP Object . . . . . . . . . . . . . . . . . . . . . 9
4.4. Scheduled LSP activation and deletion . . . . . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6. Manageability Consideration . . . . . . . . . . . . . . . . . 11
6.1. Control of Function and Policy . . . . . . . . . . . . . 11
6.2. Information and Data Models . . . . . . . . . . . . . . . 11
6.3. Liveness Detection and Monitoring . . . . . . . . . . . . 11
6.4. Verify Correct Operations . . . . . . . . . . . . . . . . 11
6.5. Requirements On Other Protocols . . . . . . . . . . . . . 12
6.6. Impact On Network Operations . . . . . . . . . . . . . . 12
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
7.1. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 12
7.2. LSP-SCHEDULING-CAPABLITY . . . . . . . . . . . . . . . . 12
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
9.1. Normative References . . . . . . . . . . . . . . . . . . 13
9.2. Informative References . . . . . . . . . . . . . . . . . 14
Appendix A. Scheduled LSP information synchronization . . . . . 14
Appendix B. Contributor Addresses . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction
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).
Zhuang, et al. Expires June 25, 2017 [Page 2]
Internet-Draft LSP Scheduling December 2016
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).
2. Conventions used in this document
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].
Zhuang, et al. Expires June 25, 2017 [Page 3]
Internet-Draft LSP Scheduling December 2016
2.1. Terminology
The following terminologies are re-used from existing PCE documents.
o Active Stateful PCE [I-D.ietf-pce-stateful-pce];
o Delegation [I-D.ietf-pce-pce-initiated-lsp];
o PCC [RFC5440], [I-D.ietf-pce-stateful-pce];
o PCE [RFC5440], [I-D.ietf-pce-stateful-pce];
o TE LSP [RFC5440], [I-D.ietf-pce-stateful-pce];
o TED [RFC5440], [I-D.ietf-pce-stateful-pce];
o LSP DB [RFC5440], [I-D.ietf-pce-stateful-pce];
In addition, this document defines the following terminologies.
Scheduled TE LSP: a LSP with the scheduling attributes,that carries
traffic flow demand at an starting time and last for a certain
duration. The PCE operates path computation per LSP availability
at the required time and duration.
Scheduled LSP DB: a database of scheduled LSPs
Scheduled TED: Traffic engineering database with the awareness of
scheduled resources for TE. This database is generated by the PCE
from the information in TED and scheduled LSP DB and allows
knowing, at any time, the amount of available resources (does not
include failures in the future).
Starting time: This value indicates when the scheduled LSP is used
and the corresponding LSP must be setup and active. In other
time(i.e., before the starting time or after the starting time
plus Duration), the LSP can be inactive to include the possibility
of the resources being used by other services.
Duration: The value indicates the time duration that the LSP is
undertaken by a traffic flow and the corresponding LSP must be
setup and active. At the end of which, the LSP is teardown and
removed from the data base.
Zhuang, et al. Expires June 25, 2017 [Page 4]
Internet-Draft LSP Scheduling December 2016
3. Motivation and Objectives
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.
4. Architecture Overview
4.1. LSP scheduling Overview
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
Zhuang, et al. Expires June 25, 2017 [Page 5]
Internet-Draft LSP Scheduling December 2016
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.
4.2. Support of LSP Scheduling
4.2.1. Stateful PCE Capability TLV
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
Zhuang, et al. Expires June 25, 2017 [Page 6]
Internet-Draft LSP Scheduling December 2016
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.
B (LSP-SCHEDULING-CAPABILITY - 1 bit): If set to 1 by a PCC, the B
Flag indicates that the PCC allows LSP scheduling; if set to 1 by
a PCE, the B Flag indicates that the PCE is capable of LSP
scheduling. The B bit MUST be set by both PECP peers in order to
support LSP scheduling for path computation.
4.3. Scheduled LSP creation
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.
Zhuang, et al. Expires June 25, 2017 [Page 7]
Internet-Draft LSP Scheduling December 2016
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:
o the stateful PCE is required to update its local scheduled LSP DB
and scheduled TED with the scheduled LSP. Besides, it shall send
a PCReq message with the scheduled LSP to other PCEs within the
network, so as to achieve the scheduling traffic engineering
information synchronization.
o Upon receiving the PCRep message or PCUpd message for scheduled
LSP from PCEs with a found path, the PCC knows that it gets a
scheduled path for the LSP but not trigger signaling for the LSP
setup on LSRs.
o In any case, stateful PCE can update the Scheduled LSP parameters
on any network events using the PCUpd message to PCC as well as
other PCEs.
4.3.1. The PCReq message and PCRpt Message
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.
Zhuang, et al. Expires June 25, 2017 [Page 8]
Internet-Draft LSP Scheduling December 2016
4.3.2. The PCRep Message
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.
4.3.3. The PCUpd Message
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.
4.3.4. LSP Object
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.
4.3.4.1. SCHED-LSP-ATTRIBUTE TLV
The SCHED-LSP-ATTRIBUTE TLV can be included as an optional TLV within
the LSP object for LSP scheduling for the requesting traffic service.
Zhuang, et al. Expires June 25, 2017 [Page 9]
Internet-Draft LSP Scheduling December 2016
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:
Starting Time (32 bits): This value in minutes, indicates when the
scheduled LSP is used and the corresponding LSP must be setup and
activated. At the expiry of this time, the LSP is setup.
Otherwise, the LSP is inactive to include the possibility of the
resources to be used by other services. The
Duration (32 bits): The value in minutes, indicates the duration
that the LSP is undertaken by a traffic flow and the corresponding
LSP must be up to carry traffic. At the expiry of this time after
setup, the LSP is tear down and deleted.
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.
Zhuang, et al. Expires June 25, 2017 [Page 10]
Internet-Draft LSP Scheduling December 2016
4.4. Scheduled LSP activation and deletion
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.
5. Security Considerations
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].
6. Manageability Consideration
6.1. Control of Function and Policy
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.
6.2. Information and Data Models
[RFC7420] describes the PCEP MIB, there are no new MIB Objects for
this document.
6.3. Liveness Detection and Monitoring
Mechanisms defined in this document do not imply any new liveness
detection and monitoring requirements in addition to those already
listed in [RFC5440].
6.4. Verify Correct Operations
Mechanisms defined in this document do not imply any new operation
verification requirements in addition to those already listed in
[RFC5440].
Zhuang, et al. Expires June 25, 2017 [Page 11]
Internet-Draft LSP Scheduling December 2016
6.5. Requirements On Other Protocols
Mechanisms defined in this document do not imply any new requirements
on other protocols.
6.6. Impact On Network Operations
Mechanisms defined in this document do not have any impact on network
operations in addition to those already listed in [RFC5440].
7. IANA Considerations
7.1. PCEP TLV Type Indicators
This document defines the following new PCEP TLV; IANA is requested
to make the following allocations from this registry.
Value Meaning Reference
TBD SCHED-LSP-ATTRIBUTE This document
7.2. LSP-SCHEDULING-CAPABLITY
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:
o Bit number (counting from bit 0 as the most significant bit)
o Capability description
o Defining RFC
The following values are defined in this document:
Bit Description Reference
28 LSP-SCHEDULING-CAPABILITY (B-bit) This document
8. Acknowledgments
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.
Zhuang, et al. Expires June 25, 2017 [Page 12]
Internet-Draft LSP Scheduling December 2016
9. References
9.1. Normative References
[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", draft-dhody-pce-stateful-
pce-auto-bandwidth-09 (work in progress), 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", draft-ietf-pce-pce-initiated-lsp-07 (work in
progress), July 2016.
[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-18 (work in progress), 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", draft-
ietf-pce-stateful-sync-optimizations-07 (work in
progress), December 2016.
[I-D.ietf-teas-scheduled-resources]
Zhuangyan, Z., Wu, Q., Chen, H., and A. Farrel,
"Architecture for Scheduled Use of Resources", draft-ietf-
teas-scheduled-resources-01 (work in progress), 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,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol (PCEP)", RFC 5440,
DOI 10.17487/RFC5440, March 2009,
<http://www.rfc-editor.org/info/rfc5440>.
Zhuang, et al. Expires June 25, 2017 [Page 13]
Internet-Draft LSP Scheduling December 2016
9.2. Informative References
[I-D.ietf-pce-stateful-pce-app]
Zhang, X. and I. Minei, "Applicability of a Stateful Path
Computation Element (PCE)", draft-ietf-pce-stateful-pce-
app-08 (work in progress), 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,
<http://www.rfc-editor.org/info/rfc5226>.
[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,
<http://www.rfc-editor.org/info/rfc7420>.
Appendix A. Scheduled LSP information synchronization
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.
Appendix B. Contributor Addresses
Zhuang, et al. Expires June 25, 2017 [Page 14]
Internet-Draft LSP Scheduling December 2016
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
Authors' Addresses
Yan Zhuang
Huawei
101 Software Avenue, Yuhua District
Nanjing, Jiangsu 210012
China
Email: zhuangyan.zhuang@huawei.com
Qin Wu
Huawei
101 Software Avenue, Yuhua District
Nanjing, Jiangsu 210012
China
Email: bill.wu@huawei.com
Dhruv Dhody
Huawei
Divyashree Techno Park, Whitefield
Bangalore, Karnataka 560066
India
Email: dhruv.ietf@gmail.com
Zhuang, et al. Expires June 25, 2017 [Page 15]
Internet-Draft LSP Scheduling December 2016
Daniele Ceccarelli
Ericsson
Via A. Negrone 1/A
Genova - Sestri Ponente
Italy
Email: daniele.ceccarelli@ericsson.com
Zhuang, et al. Expires June 25, 2017 [Page 16]