PCEP Extensions for LSP scheduling with stateful PCE
draft-zhuang-pce-stateful-pce-lsp-scheduling-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
|
|
|---|---|---|---|
| Authors | Yan Zhuang , Qin Wu , Dhruv Dhody | ||
| Last updated | 2015-06-29 | ||
| Replaced by | draft-ietf-pce-stateful-pce-lsp-scheduling, RFC 8934 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-zhuang-pce-stateful-pce-lsp-scheduling-00
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
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.
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.
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 December 31, 2015.
Copyright Notice
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
Zhuang, et al. Expires December 31, 2015 [Page 1]
Internet-Draft LSP Scheduling June 2015
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. Conventions used in this document . . . . . . . . . . . . . . 3
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
3. Motivation and Objectives . . . . . . . . . . . . . . . . . . 4
4. Architecture Overview . . . . . . . . . . . . . . . . . . . . 5
4.1. LSP scheduling Overview . . . . . . . . . . . . . . . . . 5
4.2. Support of LSP Scheduling . . . . . . . . . . . . . . . . 6
4.2.1. The Open Message . . . . . . . . . . . . . . . . . . 6
4.2.2. Stateful PCE Capability TLV . . . . . . . . . . . . . 6
4.3. Scheduled LSP creation . . . . . . . . . . . . . . . . . 7
4.3.1. The PCRpt Message . . . . . . . . . . . . . . . . . . 8
4.3.2. The PCUpd Message . . . . . . . . . . . . . . . . . . 8
4.3.3. The PCInitiate Message . . . . . . . . . . . . . . . 8
4.3.4. LSP Object . . . . . . . . . . . . . . . . . . . . . 8
4.4. Scheduled LSP information synchronization . . . . . . . . 10
4.4.1. The PCRpt Message . . . . . . . . . . . . . . . . . . 10
4.5. PCC initiated scheduled LSP . . . . . . . . . . . . . . . 10
4.6. Scheduled LSP activation and deletion . . . . . . . . . . 11
4.6.1. The PCUpd Message . . . . . . . . . . . . . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
6. Manageability Consideration . . . . . . . . . . . . . . . . . 12
6.1. Control of Function and Policy . . . . . . . . . . . . . 12
6.2. Information and Data Models . . . . . . . . . . . . . . . 12
6.3. Liveness Detection and Monitoring . . . . . . . . . . . . 12
6.4. Verify Correct Operations . . . . . . . . . . . . . . . . 13
6.5. Requirements On Other Protocols . . . . . . . . . . . . . 13
6.6. Impact On Network Operations . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
7.1. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 13
7.2. LSP-SCHEDULING-CAPABLITY . . . . . . . . . . . . . . . . 13
7.3. ACTIVATING-LSP . . . . . . . . . . . . . . . . . . . . . 14
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
8.1. Normative References . . . . . . . . . . . . . . . . . . 14
8.2. Informative References . . . . . . . . . . . . . . . . . 14
Appendix A. Appendix A. Contributor Addresses . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
Zhuang, et al. Expires December 31, 2015 [Page 2]
Internet-Draft LSP Scheduling June 2015
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).
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.
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 December 31, 2015 [Page 3]
Internet-Draft LSP Scheduling June 2015
2.1. Terminology
The following terminologies are used in this document:
Active Stateful PCE: PCE that uses LSP state information learned
from PCCs to optimize path computations. Additionally, it
actively updates delegated LSP states in those PCCs that delegated
the control.
Delegation: An operation to grant a PCE temporary rights to modify a
subset of LSP parameters on one or more PCC's LSPs. LSPs are
delegated from a PCC to a PCE.
PCC: Path Computation Client: any client application requesting a
path computation to be performed by a Path Computation Element.
PCE: Path Computation Element. An entity (component, application,
or network node) that is capable of computing a network path or
route based on a network graph and applying computational
constraints.
TE LSP: Traffic Engineering Label Switched Path.
Scheduled TE LSP: a LSP that carries traffic flow demand at an
activation time and last for a certain duration. The PCE operates
path computation per LSP availability at the required time and
duration.
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, 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.
Zhuang, et al. Expires December 31, 2015 [Page 4]
Internet-Draft LSP Scheduling June 2015
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
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
Zhuang, et al. Expires December 31, 2015 [Page 5]
Internet-Draft LSP Scheduling June 2015
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:
o Scheduled LSP: A LSP with the scheduling attributes, that is
activated in future and last for a duration. The PCE operates
path computation per resource availability at the required time
and duration.
o Starting time: This value indicates when the scheduled LSP is used
and the corresponding LSP must be setup and active. In other
time, the LSP can be inactive to include the possibility of the
resources being used by other services.
o 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.
4.2. Support of LSP Scheduling
4.2.1. The Open Message
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.
4.2.2. Stateful PCE Capability TLV
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].
Zhuang, et al. Expires December 31, 2015 [Page 6]
Internet-Draft LSP Scheduling June 2015
A new bit B (SCHED-LSP-CAPABLITY) flag is added in this document 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 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.
Zhuang, et al. Expires December 31, 2015 [Page 7]
Internet-Draft LSP Scheduling June 2015
4.3.1. The PCRpt 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.
4.3.2. 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 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.
4.3.3. The PCInitiate 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.
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.
Zhuang, et al. Expires December 31, 2015 [Page 8]
Internet-Draft LSP Scheduling June 2015
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.
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.
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:
Start 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 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.
Zhuang, et al. Expires December 31, 2015 [Page 9]
Internet-Draft LSP Scheduling June 2015
4.4. 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. In order to synchronize the
scheduled LSP information in SLSP-DB among PCEs and PCCs, the PCRpt
Message is used as before.
4.4.1. The PCRpt Message
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.
4.5. PCC initiated scheduled LSP
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.
Zhuang, et al. Expires December 31, 2015 [Page 10]
Internet-Draft LSP Scheduling June 2015
4.6. Scheduled LSP activation and deletion
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.
4.6.1. The PCUpd Message
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).
4.6.1.1. SRP Object
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:
Zhuang, et al. Expires December 31, 2015 [Page 11]
Internet-Draft LSP Scheduling June 2015
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].
A (ACTIVATING-LSP - 1 bit): On a PCUpd message , the A Flag set to 1
indicates that this scheduled LSP SHALL be activated, which means
it shall be up and ready to carry traffic. The A Flag set to zero
indicates no operation for this LSP. For non-scheduled LSPs, this
A flag shall set to zero.
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].
Zhuang, et al. Expires December 31, 2015 [Page 12]
Internet-Draft LSP Scheduling June 2015
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].
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
Zhuang, et al. Expires December 31, 2015 [Page 13]
Internet-Draft LSP Scheduling June 2015
7.3. ACTIVATING-LSP
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:
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
30 ACTIVATING-LSP This document
8. References
8.1. Normative 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-04 (work in
progress), April 2015.
[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-11 (work in progress), 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", draft-
ietf-pce-stateful-sync-optimizations-02 (work in
progress), January 2015.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
8.2. Informative References
Zhuang, et al. Expires December 31, 2015 [Page 14]
Internet-Draft LSP Scheduling June 2015
[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-04 (work in progress), April 2015.
Appendix A. Appendix A. Contributor Addresses
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
Zhuang, et al. Expires December 31, 2015 [Page 15]
Internet-Draft LSP Scheduling June 2015
Dhruv Dhody
Huawei
Divyashree Techno Park, Whitefield
Bangalore, Karnataka 560037
India
Email: dhruv.ietf@gmail.com
Zhuang, et al. Expires December 31, 2015 [Page 16]