Extensions to PCEP for Temporal LSP
draft-chen-pce-tts-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 "Expired".
|
|
|---|---|---|---|
| Authors | Huaimo Chen , Mehmet Toy , Vic Liu , Lei Liu | ||
| Last updated | 2015-07-02 | ||
| 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-chen-pce-tts-00
Internet Engineering Task Force H. Chen
Internet-Draft Huawei Technologies
Intended status: Standards Track M. Toy
Expires: January 3, 2016 Comcast
V. Liu
China Mobile
L. Liu
Fijitsu
July 2, 2015
Extensions to PCEP for Temporal LSP
draft-chen-pce-tts-00.txt
Abstract
This document specifies extensions to PCEP for initiating and
maintaining a Traffic Engineering (TE) Label Switched Path (LSP) in a
time interval or a sequence of time intervals, during which the LSP
carries traffic.
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 January 3, 2016.
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
Chen, et al. Expires January 3, 2016 [Page 1]
Internet-Draft PCE Temporal LSP July 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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Conventions Used in This Document . . . . . . . . . . . . . . 3
4. Operations Overview . . . . . . . . . . . . . . . . . . . . . 4
4.1. Simple Time Interval . . . . . . . . . . . . . . . . . . . 4
4.2. Recurrent Time Interval . . . . . . . . . . . . . . . . . 4
4.3. Elastic Time Interval . . . . . . . . . . . . . . . . . . 4
4.4. Changes to Time Interval . . . . . . . . . . . . . . . . . 5
4.5. Graceful Periods . . . . . . . . . . . . . . . . . . . . . 6
5. Extensions to PCEP . . . . . . . . . . . . . . . . . . . . . . 6
5.1. Capability TLV in Existing PCE Discovery Protocol . . . . 6
5.2. Open Message Extension . . . . . . . . . . . . . . . . . . 8
5.3. RP Object Extension . . . . . . . . . . . . . . . . . . . 9
5.4. TIME INTERVAL Object . . . . . . . . . . . . . . . . . . . 9
5.4.1. Absolute Time Interval TLV . . . . . . . . . . . . . . 10
5.4.2. Relative Time Interval TLV . . . . . . . . . . . . . . 11
5.4.3. Recurrent Absolute Time Interval TLV . . . . . . . . . 12
5.4.4. Recurrent Relative Time Interval TLV . . . . . . . . . 14
5.5. Messages for Temporal LSP . . . . . . . . . . . . . . . . 15
5.5.1. Messages between PCE and PCC on Ingress . . . . . . . 16
5.5.2. Messages between two PCEs . . . . . . . . . . . . . . 17
6. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . 18
6.1. Creating a Temporal LSP . . . . . . . . . . . . . . . . . 18
6.2. Deleting a Temporal LSP . . . . . . . . . . . . . . . . . 19
7. Considerations on TEDB . . . . . . . . . . . . . . . . . . . . 19
7.1. TE Representation in Absolute Time . . . . . . . . . . . . 20
7.2. TE Representation in Relative Time . . . . . . . . . . . . 21
8. Security Considerations . . . . . . . . . . . . . . . . . . . 21
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 22
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
11.1. Normative References . . . . . . . . . . . . . . . . . . . 22
11.2. Informative References . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
Chen, et al. Expires January 3, 2016 [Page 2]
Internet-Draft PCE Temporal LSP July 2015
1. Introduction
Once an existing multiprotocol label switching (MPLS) traffic
engineering (TE) label switched path (LSP) is set up, it is assumed
to carry traffic forever until it is down. When an MPLS TE LSP
tunnel is up, it is assumed that the LSP consumes its reserved
network resources forever even though the LSP may only use network
resources during some period of time. As a result, the network
resources are not used efficiently. Moreover, a tunnel service can
not be reserved or booked in advance for a period of time or a
sequence of time periods.
This document specifies extensions to PCEP for initiating and
maintaining an MPLS TE LSP in a period of time called a time interval
or a sequence of time intervals. It is assumed that the LSP carries
traffic during this time interval or each of these time intervals.
Thus the network resources are efficiently used. More importantly,
some new services can be provided. For example, a consumer can book
a tunnel service in advance for a given time interval. Tunnel
services may be scheduled.
2. Terminology
A Time Interval: a time period from time Ta to time Tb.
LSP: Label Switched Path. An LSP is a P2P (point-to-point) LSP or a
P2MP (point-to-multipoiint) LSP.
LSP in a time interval: LSP that carries traffic in the time
interval.
LSP in a sequence of time intervals: LSP that carries traffic in each
of the time intervals.
Temporal LSP: LSP in a time interval or LSP in a sequence of time
intervals.
TEDB: Traffic Engineering Database.
This document uses terminologies defined in RFC5440.
3. 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.
Chen, et al. Expires January 3, 2016 [Page 3]
Internet-Draft PCE Temporal LSP July 2015
4. Operations Overview
This section briefly describes some operations on a temporal LSP.
4.1. Simple Time Interval
For a temporal LSP, a user configures it with a time interval or a
sequence of time intervals. A simple time interval is a time period
from time Ta to time Tb, which may be represented as [Ta, Tb].
When an LSP is configured with time interval [Ta, Tb], a path
satisfying the constraints for the LSP in the time interval is
computed and the LSP along the path is set up to carry traffic from
time Ta to time Tb.
In addition to simple time intervals, there are recurrent time
intervals and elastic time intervals. Sometimes a simple time
interval is called a time interval.
4.2. Recurrent Time Interval
A recurrent time interval represents a series of repeated simple time
intervals. It has a simple time interval such as [Ta, Tb], a number
of repeats such as 10 (repeats 10 times), and a repeat cycle/time
such as a week (repeats every week). The recurrent time interval:
"[Ta, Tb] repeats n times with repeat cycle C" represents n+1 simple
time intervals as follows:
[Ta, Tb], [Ta+C, Tb+C], [Ta+2C, Tb+2C], ..., [Ta+nC, Tb+nC]
When an LSP is configured with a recurrent time interval such as
"[Ta, Tb] repeats 10 times with a repeat cycle a week" (representing
11 simple time intervals), a path satisfying the constraints for the
LSP in each of the simple time intervals represented by the recurrent
time interval is computed and the LSP along the path is set up to
carry traffic in each of the simple time intervals.
4.3. Elastic Time Interval
An elastic time interval is a time interval with an elastic range,
which is represented as within -P and Q, where P and Q is an amount
of time such as 300 seconds. P is called elastic range lower bound
and Q is called elastic range upper bound.
For a simple time interval such as [Ta, Tb] with an elastic range,
elastic time interval: "[Ta, Tb] within -P and Q" means a time period
from (Ta+X) to (Tb+X), where -P <= X <= Q.
Chen, et al. Expires January 3, 2016 [Page 4]
Internet-Draft PCE Temporal LSP July 2015
When an LSP is configured with elastic time interval "[Ta, Tb] within
-P and Q", a path is computed such that the path satisfies the
constraints for the LSP in the time period from (Ta+X) to (Tb+X) and
|X| is the minimum value from -P to Q. That is that [Ta+X, Tb+X] is
the time interval closest to time interval [Ta, Tb] within the
elastic range. The LSP along the path is set up to carry traffic in
the time period from (Ta+X) to (Tb+X).
Similarly, for a recurrent time interval with an elastic range,
elastic time interval: "[Ta, Tb] repeats n times with repeat cycle C
within -P and Q" represents n+1 simple elastic time intervals as
follows:
[Ta+X0, Tb+X0], [Ta+C+X1, Tb+C+X1], ..., [Ta+nC+Xn, Tb+nC+Xn]
where -P <= Xi <= Q, i = 0, 1, 2, ..., n.
If a user wants to keep the same repeat cycle between any two
adjacent time intervals, elastic time interval: "[Ta, Tb] repeats n
times with repeat cycle C within -P and Q SYNC" may be used, which
represents n+1 simple elastic time intervals as follows:
[Ta+X, Tb+X], [Ta+C+X, Tb+C+X], ..., [Ta+nC+X, Tb+nC+X]
where -P <= X <= Q.
4.4. Changes to Time Interval
After a temporal LSP is configured, a user may change its parameters
including some of the time intervals configured. A new time interval
may be added, an existing time interval may be removed or changed.
When a new time interval is added to an existing LSP, a path
satisfying the constraints for the LSP in the time interval is
computed and the LSP along the path is set up to carry traffic in the
time interval.
When an existing time interval is removed from an existing LSP, the
time interval is deleted from the lifetime of the LSP. If the
lifetime is over, the LSP is deleted.
A change to an existing time interval may generate some of four
possible results: 1) The existing time interval is extended for a
time period EA after the existing time period; 2) The existing time
interval is extended for a time period EB before the existing time
period; 3) The existing time interval is shrunk for a time period SA
Chen, et al. Expires January 3, 2016 [Page 5]
Internet-Draft PCE Temporal LSP July 2015
from the end of the existing time period; and 4) The existing time
interval is shrunk for a time period SB from the beginning of the
existing time period.
When an existing time interval for an LSP is extended, a path
satisfying the constraints for the LSP in the extended time interval
is computed and the LSP along the path is set up to carry traffic in
the extended time interval. If the LSP is already up to carry
traffic in the existing time interval, the lifetime of the LSP is
extended for time period EA following the existing time interval.
When an existing time interval for an LSP is shrunk, the shrunk time
periods are removed from the lifetime of the LSP.
4.5. Graceful Periods
For a temporal LSP, a user may want to have some graceful periods for
each or some of the time intervals for the LSP. Two graceful periods
may be configured for a time interval. One is the graceful period
before the time interval, called grace-before, which extends the
lifetime of the LSP for grace-before (such as 30 seconds) before the
time interval. The other is the one after the time interval, called
grace-after, which extends the lifetime of the LSP for grace-after
(such as 60 seconds) after the time interval.
When an LSP is configured with a simple time interval such as [Ta,
Tb] with graceful periods such as grace-before GB and grace-after GA,
a path is computed such that the path satisfies the constraints for
the LSP in the time period from Ta to Tb. The LSP along the path is
set up to carry traffic in the time period from (Ta-GB) to (Tb+GA).
During graceful periods from (Ta-GB) to Ta and from Tb to (Tb+GA),
the LSP is up to carry traffic (maybe in best effort).
5. Extensions to PCEP
This section describes the extensions to PCEP for initiating and
maintaining temporal LSPs.
5.1. Capability TLV in Existing PCE Discovery Protocol
There are a couple of options for advertising a PCE capability for
initiating and maintaining temporal LSPs.
The first option is to define a new flag in the OSPF and ISIS PCE
Capability Flags to indicate the capability that a PCE is capable to
initiate and maintain temporal LSPs. This includes the capability of
computing both a path for a temporal P2MP LSP and a path for a
Chen, et al. Expires January 3, 2016 [Page 6]
Internet-Draft PCE Temporal LSP July 2015
temporal P2P LSP.
The second option is to define three new flags. The first new flag
in the OSPF and ISIS PCE Capability Flags indicates the capability
that a PCE is capable to compute a path for a temporal P2MP LSP; the
second new flag indicates the capability that a PCE is capable to
compute a path for a temporal P2P LSP; and the third new flag
indicates the capability that a PCE is capable to initiate and
maintain a temporal LSP.
The format of the PCE-CAP-FLAGS sub-TLV is as follows:
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 = 5 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ PCE Capability Flags ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 5
Length: Multiple of 4 octets
Value: This contains an array of units of 32-bit flags
numbered from the most significant as bit zero, where
each bit represents one PCE capability.
The following capability bits have been assigned by IANA:
Bit Capabilities
0 Path computation with GMPLS link constraints
1 Bidirectional path computation
2 Diverse path computation
3 Load-balanced path computation
4 Synchronized path computation
5 Support for multiple objective functions
6 Support for additive path constraints
(max hop count, etc.)
7 Support for request prioritization
8 Support for multiple requests per message
9 Global Concurrent Optimization (GCO)
10 P2MP path computation
...
Reserved bits SHOULD be set to zero on transmission and MUST be
ignored on receipt.
Chen, et al. Expires January 3, 2016 [Page 7]
Internet-Draft PCE Temporal LSP July 2015
For the second option, one bit such as bit 16 may be assigned to
indicate that a PCE is capable to compute a path for a temporal P2MP
LSP; another bit such as bit 17 may be assigned to indicate that a
PCE is capable to compute a path for a temporal P2P LSP; and yet
another bit such as bit 18 may be assigned to indicate that a PCE is
capable to initiate and maintain temporal LSPs.
Bit Capabilities
16 Path computation for temporal P2MP LSP
17 Path computation for temporal P2P LSP
18 Initiation and maintenance of temporal LSP
19-31 Reserved for future assignments by IANA.
5.2. Open Message Extension
If a PCE does not advertise its capability related to initiation and
maintenance of a temporal LSP during discovery, PCEP should be used
to allow a PCC to discover, during the Open Message Exchange, which
PCEs are capable of supporting initiation and maintenance of a
temporal LSP.
To achieve this, we extend the PCEP OPEN object by defining a new
optional TLV to indicate the PCE's capability to initiate and
maintain a temporal LSP.
We request IANA to allocate a value such as 10 from the "PCEP TLV
Type Indicators" subregistry, as documented in Section below
("Temporal LSP Capability TLV"). The description is "temporal LSP
capable", and the length value is 2 bytes. The value field is set to
indicate the capability of a PCE for initiation and maintenance of a
temporal LSP in details.
We can use flag bits in the value field in the same way as the PCE
Capability Flags described in the previous section.
The inclusion of this TLV in an OPEN object indicates that the sender
can initiate and maintain a temporal LSP.
The capability TLV is meaningful only for a PCE, so it will typically
appear only in one of the two Open messages during PCE session
establishment. However, in case of PCE cooperation (e.g., inter-
domain), when a PCE behaving as a PCC initiates a PCE session it
SHOULD also indicate its capabilities.
Chen, et al. Expires January 3, 2016 [Page 8]
Internet-Draft PCE Temporal LSP July 2015
5.3. RP Object Extension
The following flags are added into the RP Object:
A T bit is added in the flag bits field of the RP object to tell a
receiver of a message that the message is for (initiating and
maintaining) a temporal LSP.
o T (Temporal LSP bit - 1 bit):
0: This indicates that this is not a message
for a temporal LSP.
1: This indicates that this is a message
for a temporal LSP.
The IANA request is referenced in Section below (Request Parameter
Bit Flags) of this document.
This T bit with the N bit defined in RFC6006 can indicate whether the
message is for a temporal P2P LSP or P2MP LSP.
o T = 1 and N = 0: This indicates that this is a message
for a temporal P2P LSP
o T = 1 and N = 1: This indicates that this is a message
for a temporal P2MP LSP
5.4. TIME INTERVAL Object
For a TIME-INTERVAL object, its Class is to be assigned by IANA, here
we use 18, which may be changed late. Its OT is 1, exact number to
be assigned by IANA. The format of a TIME-INTERVAL object body is
illustrated below, which comprises a number of time interval TLVs.
Object-Class: TBD (18), OT = 1
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (Object Body containing Time Interval TLVs) |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A time interval TLV may be a relative time interval TLV or an
absolute time interval TLV, which are two different representations
Chen, et al. Expires January 3, 2016 [Page 9]
Internet-Draft PCE Temporal LSP July 2015
of a time interval. Their advantages and disadvantages are discussed
below.
5.4.1. Absolute Time Interval TLV
The format of an absolute time interval TLV (Type = 1) for an LSP is
illustrated below. It mainly contains a Start-time and an End-time,
representing time interval [Start-time, End-time]. Both of these two
times are the times that are synchronized among all the elements
involved. Thus the clocks on all the elements MUST be synchronized
if an absolute time interval TLV is used. The time period
represented in an absolute time interval TLV is more accurate.
In addition, it contains an non zero grace-before and grace-after if
graceful periods are configured. It includes an non zero elastic
range lower bound and upper bound if there is an elastic range
configured.
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 (1) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Start-time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| End-time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved (0) | GrB | GrA |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Elastic-Lower-Bound | Elastic-Upper-Bound |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Start-time: The time LSP starts to carry traffic.
o End-time: The time LSP ends carrying traffic.
o GrB (Grace-Before): The graceful period time length in seconds
before time interval [Start-time, End-time].
o GrA (Grace-After): The graceful period time length in seconds
after time interval [Start-time, End-time].
o Elastic-Lower-Bound: The maximum amount of time in seconds that
time interval [Start-time, End-time] can shift to lower/left.
Chen, et al. Expires January 3, 2016 [Page 10]
Internet-Draft PCE Temporal LSP July 2015
o Elastic-Upper-Bound: The maximum amount of time in seconds that
time interval [Start-time, End-time] can shift to upper/right.
Discussions: Optionally, we may define three TLVs: 1) an absolute
time interval TLV containing only a Start-time and an End-time; 2) an
elastic range TLV containing just an elastic range lower bound and
upper bound; and 3) a graceful period TLV containing only a grace-
before and a grace-after. If a time interval is with an elastic
range, an absolute time interval TLV followed by an elastic range TLV
is used. If a time interval is with graceful periods, an absolute
time interval TLV followed by a graceful period TLV is used.
5.4.2. Relative Time Interval TLV
The format of a relative time interval TLV (Type = 2) for an LSP is
shown below. It mainly contains a Start-time-length and an End-time-
length, representing the time interval below for the LSP:
[current-time + Start-time-length, current-time + End-time-length]
where current-time is a current local time. When a time interval
from time Ta to time Tb is configured on a node/element, these two
time lengths are the time lengths that are computed on the node using
a current local time as follows.
Start-time-length = Ta - current-time;
End-time-length = Tb - current-time;
For a relative time interval TLV, the clocks/times on all the
elements involved can be different. But the time period represented
in a relative time interval TLV on one element/node may be shifted a
little bit from another element's point of view since transmitting
the TLV from one element to another takes a little time, which is
hard to be considered accurately.
The TLV also includes an non zero grace-before and grace-after if
graceful periods are configured. It contains an non zero elastic
range lower bound and upper bound if there is an elastic range
configured.
Chen, et al. Expires January 3, 2016 [Page 11]
Internet-Draft PCE Temporal LSP July 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (2) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Start-time-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| End-time-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved (0) | GrB | GrA |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Elastic-Lower-Bound | Elastic-Upper-Bound |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Start-time-length: The time length in seconds from a current
local time to the time LSP starts to carry traffic.
o End-time-length: The time length in seconds from a current local
time to the time LSP ends carrying traffic.
o GrB (Grace-Before): The graceful period time length in seconds
before the time interval above for the LSP.
o GrA (Grace-After): The graceful period time length in seconds
after the time interval above for the LSP.
o Elastic-Lower-Bound: The maximum amount of time in seconds that
the time interval above for the LSP can shift to lower/left.
o Elastic-Upper-Bound: The maximum amount of time in seconds that
the time interval above can shift to upper/right.
5.4.3. Recurrent Absolute Time Interval TLV
The format of a recurrent absolute time interval TLV (Type = 3) for
an LSP is illustrated below. It mainly contains a Start-time, an
End-time, a Repeat-time-length, a Options field and a Number-repeats.
The Start-time and End-time represents time interval [Start-time,
End-time]. The Repeat-time-length represents a repeat cycle/time,
which is valid if the Options field is set to indicate the way to
repeat is "repeat every Repeat-time-length". The Options field
indicates a way to repeat. The Number-repeats indicates the number
of repeats of time interval [Start-time, End-time].
In addition, the TLV includes an non zero grace-before and grace-
after if graceful periods are configured. It contains an non zero
Chen, et al. Expires January 3, 2016 [Page 12]
Internet-Draft PCE Temporal LSP July 2015
elastic range lower bound and upper bound if there is an elastic
range configured.
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 (3) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Start-time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| End-time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Repeat-time-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options | Number-repeats | GrB | GrA |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Elastic-Lower-Bound | Elastic-Upper-Bound |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Start-time: The time LSP starts to carry traffic.
o End-time: The time LSP ends carrying traffic.
o Repeat-time-length: The time length in seconds after which LSP
starts to carry traffic again for (End-time - Start-time).
o Options: Indicates a way to repeat.
Options = 1: repeat every day;
Options = 2: repeat every week;
Options = 3: repeat every month;
Options = 4: repeat every year;
Options = 5: repeat every Repeat-time-length.
o Number-repeats: The number of repeats. In each of repeats, LSP
carries traffic.
o GrB (Grace-Before): The graceful period time length in seconds
before each of the time intervals represented by the recurrent
time interval.
Chen, et al. Expires January 3, 2016 [Page 13]
Internet-Draft PCE Temporal LSP July 2015
o GrA (Grace-After): The graceful period time length in seconds
after each of the time intervals.
o Elastic-Lower-Bound: The maximum amount of time in seconds that
each of the time intervals can shift to lower/left.
o Elastic-Upper-Bound: The maximum amount of time in seconds that
each of the time intervals can shift to upper/right.
5.4.4. Recurrent Relative Time Interval TLV
The format of a recurrent relative time interval TLV (Type = 4) for
an LSP is shown below. It mainly contains a Start-time-length, an
End-time-length, a Repeat-time-length, a Options field and a Number-
repeats.
The Start-time-length and End-time-length represents time interval
[current-time + Start-time-length, current-time + End-time-length]
where current-time is a current local time. The Repeat-time-length
represents a repeat cycle/time, which is valid if the Options field
is set to indicate the way to repeat is "repeat every Repeat-time-
length". The Options field indicates a way to repeat. The Number-
repeats indicates the number of repeats of the time interval above.
In addition, the TLV includes an non zero grace-before and grace-
after if graceful periods are configured. It contains an non zero
elastic range lower bound and upper bound if there is an elastic
range configured.
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 (4) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Start-time-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| End-time-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Repeat-time-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options | Number-repeats | GrB | GrA |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Elastic-Lower-Bound | Elastic-Upper-Bound |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Chen, et al. Expires January 3, 2016 [Page 14]
Internet-Draft PCE Temporal LSP July 2015
o Start-time-length: The time length in seconds from a current
local time to the time LSP starts to carry traffic.
o End-time-length: The time length in seconds from a current local
time to the time LSP ends carrying traffic.
o Repeat-time-length: The time length in seconds after which LSP
starts to carry traffic again for (End-time-length - Start-time-
length).
o Options: Indicates a way to repeat.
Options = 1: repeat every day;
Options = 2: repeat every week;
Options = 3: repeat every month;
Options = 4: repeat every year;
Options = 5: repeat every Repeat-time-length.
o Number-repeats: The number of repeats. In each of repeats, LSP
carries traffic.
o GrB (Grace-Before): The graceful period time length in seconds
before each of the time intervals represented by the recurrent
time interval.
o GrA (Grace-After): The graceful period time length in seconds
after each of the time intervals.
o Elastic-Lower-Bound: The maximum amount of time in seconds that
each of the time intervals can shift to lower/left.
o Elastic-Upper-Bound: The maximum amount of time in seconds that
each of the time intervals can shift to upper/right.
5.5. Messages for Temporal LSP
This section presents and discusses two classes of messages. One
class is the messages between a PCE and a PCC on the ingress of a
temporal LSP for initiating and maintaining the LSP. The other is
the messages between two PCEs, one of which acts as a PCC.
Chen, et al. Expires January 3, 2016 [Page 15]
Internet-Draft PCE Temporal LSP July 2015
5.5.1. Messages between PCE and PCC on Ingress
From function's point of view, there are four groups of messages: 1)
LSP creation request messages, 2) LSP deletion request messages, 3)
LSP creation response messages, and 4) LSP deletion response
messages. A message for an LSP in the first two groups is sent from
a PCE to the PCC on the ingress of the LSP. A message for an LSP in
the last two groups is sent from the PCC on the ingress of the LSP to
a PCE.
A Path Computation LSP Initiate Request (PCInitiate) message with
some extensions can be used for a message in the first two groups. A
Path Computation LSP State Report (PCRpt) message with some
extensions can be used for a message in the last two groups.
For an LSP creation request, a PCInitiate message includes objects:
SRP, LSP, END-POINTS, ERO and TIME-INTERVAL. SRP (Stateful PCE
Request Parameters) object comprises an SRP-ID-number. LSP object
comprises PLSP-ID of 0, and SYMBOLIC-PATH-NAME TLV with path name.
END-POINTS object comprises the source and destination addresses of
the LSP. ERO object comprise the path (i.e., ERO) for the LSP.
TIME-INTERVAL object comprises the time intervals for the LSP (the
path satisfies constraints for the LSP in each of the time
intervals).
For an LSP creation response, a PCRpt message includes objects: SRP,
LSP, ERO and TIME-INTERVAL. SRP object comprises the SRP-ID-number
in the corresponding LSP creation request message. LSP object
comprises a PLSP-ID assigned to the LSP by the PCC, SYMBOLIC-PATH-
NAME TLV with path name, C Flag set to 1 indicates that this LSP is
created by the LSP creation request. ERO object comprise the path
(i.e., ERO) for the LSP. TIME-INTERVAL object comprises the time
intervals for the LSP.
For an LSP deletion request, a PCInitiate message includes objects:
SRP, LSP, and TIME-INTERVAL. SRP object comprises an SRP-ID-number
and R (remove) flag set to 1. LSP object comprises the PLSP-ID for
the LSP created. TIME-INTERVAL object comprises the time intervals
for the LSP.
For an LSP deletion response, a PCRpt message includes objects: SRP,
LSP, and TIME-INTERVAL. SRP object comprises the SRP-ID-number in
the corresponding LSP deletion request message. LSP object comprises
R(Remove) flag set to 1 indicating that the LSP has been removed from
the PCC, and LSP Identifiers TLV.
Note: The PCC on the ingress of an LSP does not use any time
intervals in the TIME-INTERVAL object received for signaling the LSP.
Chen, et al. Expires January 3, 2016 [Page 16]
Internet-Draft PCE Temporal LSP July 2015
For just creating and deleting LSPs, we do not need to include any
TIME-INTERVAL object in a message if the PCE creates the LSP with a
sequence of time intervals at the beginning of each of the time
intervals and deletes the LSP at the end of each of the time
intervals.
Discussions: For an LSP having a time interval TLV with graceful
periods, we may create the LSP in the time period including the
graceful periods and the LSP has the reserved bandwidth during that
period (including the graceful periods).
Another option is that we create the LSP in the time period including
the graceful periods, but do not reserve any bandwidth for the LSP in
the beginning. The desired bandwidth for the LSP is reserved in the
time period without graceful periods.
After the graceful period before the time interval, the bandwidth for
the LSP is reserved through a update message from the PCE to the PCC
on the ingress of the LSP. After the time interval (i.e., just
before the graceful period after the time interval), the bandwidth
for the LSP is released through another update message from the PCE
to the PCC on the ingress of the LSP.
5.5.2. Messages between two PCEs
Figure below illustrates the format of a request message with a
optional TIME-INTERVAL object:
<PCReq Message>::= <Common Header>
[<svec-list>]
<request-list>
<request-list>::=<request>[<request-list>]
<request>::= <RP> <END-POINTS> [<OF>] [<LSPA>] [<BANDWIDTH>]
[<metric-list>] [<RRO>[<BANDWIDTH>]] [<IRO>]
[<LOAD-BALANCING>]
[<TIME-INTERVAL>]
Figure 1: Format for Request Message
Below is the format of a reply message with a optional TIME-INTERVAL
object:
Chen, et al. Expires January 3, 2016 [Page 17]
Internet-Draft PCE Temporal LSP July 2015
<PCReq Message>::= <Common Header>
<response-list>
<response-list>::=<response>[<response-list>]
<response>::= <RP>
[<NO-PATH>]
[<attribute-list>]
[<path-list>]
<path-list>::=<path>[<path-list>]
<path>::= <ERO><attribute-list>[<TIME-INTERVAL>]
Figure 2: Format for Reply Message
6. Procedures
This section focuses on the procedures for creating and deleting a
temporal LSP. When a PCE receives a request for an LSP with a
sequence of time intervals from a user or application, it computes a
path satisfying the constraints for the LSP in each of the time
intervals and reserved the bandwidth for the LSP along the path in
each of the time intervals. And then it initiates the creation of
the LSP in the network to carry traffic in each of the time
intervals.
Ther are a couple of ways for a PCE to create an LSP with a sequence
of time intervals. One way is that the PCE initiates the creation of
the LSP at the beginning of each of the time intervals. At the end
of each of the time intervals or when a deletion request for the LSP
received, the PCE initiates the deletion of the LSP.
6.1. Creating a Temporal LSP
A procedure for creating a temporal LSP is as follows:
Step 1: A PCE receives a request for creating a temporal LSP from
a user or application.
Step 2: The PCE computes a shortest path satisfying constraints
for the LSP in the time intervals given. It reserves the
bandwidth in TEDB on each of the links the LSP traverses for each
of the time intervals and stores the information about the LSP
into an LSP database.
Step 3: At the beginning of each of the time intervals, the PCE
initiates the setup of the LSP in a network through sending an LSP
creation request (e.g., a PCInitiate with LSP object with PLSP-
ID=0) with the path for the LSP to the PCC on the ingress of the
Chen, et al. Expires January 3, 2016 [Page 18]
Internet-Draft PCE Temporal LSP July 2015
LSP, which triggers RSVP-TE to signal the LSP along the path in
the network (Note that the RSVP-TE is not aware of any time
interval for the LSP and just sets up the LSP in a normal way).
The PCC sends an LSP creation response (e.g., a PCRpt) to the PCE
after the LSP is up.
Step 4: The PCE receives the LSP creation response (e.g., the
PCRpt) from the PCC corresponding to the request and updates the
status of the LSP accordingly.
6.2. Deleting a Temporal LSP
Suppose that a temporal LSP has been created to carry traffic in a
sequence of time intervals. A procedure for deleting this temporal
LSP is as follows:
Step 1: A PCE receives a request for deleting the temporal LSP
from an client, or the lifetime for the LSP in a time interval is
over and the LSP needs to be deleted.
Step 2: The PCE finds the LSP in the LSP database and gets the
information about the LSP.
Step 3: The PCE initiates the deletion of the LSP in the network
through sending an LSP deletion request (e.g., a PCInitiate with R
flag set and PLSP ID for the LSP) to the PCC on the ingress of the
LSP, which triggers the RSVP-TE to tear down the LSP in the
network (Note that the RSVP-TE is not aware of any time interval
for the LSP and just tears down the LSP in a normal way). The PCC
generates an LSP deletion response (e.g., a PCRpt with R flag set)
and sends it to the PCE after the LSP is torn down.
Step 4: The PCE receives the LSP deletion response (e.g., the
PCRpt) from the PCC corresponding to the request and updates the
status of the LSP accordingly. For deleting the LSP completely as
requested, it releases the bandwidth reserved for the LSP in TEDB
for each of the time intervals and removes the information about
the LSP from the LSP database after the LSP is deleted.
7. Considerations on TEDB
The existing Traffic Engineering (TE) information in a TEDB
represents an unreserved bandwidth Bi at each of eight priority
levels for a link at one point of time, for example, at the current
time.
Chen, et al. Expires January 3, 2016 [Page 19]
Internet-Draft PCE Temporal LSP July 2015
Bandwidth
^
|
Bi|______________________________________________________
|
|
-+------------------------------------------------------> Time
|
This means that the link has bandwidth Bi at a priority level from
now to forever until there is a change to it. Thus, a TE Label
Switching Path (LSP) tunnel for a given time interval cannot be set
up in advance using the information in the TEDB and the bandwidth
cannot be reserved in advance for the LSP in the time interval given.
TEDB needs to be enhanced for supporting temporal LSPs. Two options
for enhancing TEDB are presented below.
7.1. TE Representation in Absolute Time
Suppose that the amount of the unreserved bandwidth at a priority
level for a link is Bj in a time interval from time Tj to Tk (k =
j+1), where j = 0, 1, 2, .... The unreserved bandwidth for the link
can be represented as
[T0, B0], [T1, B1], [T2, B2], [T3, B3], ....
This is an absolute time representation of bandwidths for a link.
Time Tj (j = 0, 1, 2, ...) MUST be a synchronized time among all the
elements involved.
Bandwidth
^
| B3
| B1 ___________
| __________
|B0 B4
|__________ B2 _________
| ________________
|
-+-------------------------------------------------------> Time
|T0 T1 T2 T3 T4
If an LSP is completely deleted at time T and uses bandwidth B, then
for every time interval/period (after time T) during which bandwidth
Chen, et al. Expires January 3, 2016 [Page 20]
Internet-Draft PCE Temporal LSP July 2015
B is reserved for the LSP on a link, B is added to the link for that
interval/period.
If an LSP is to be up at time T and uses bandwidth B, then for every
time interval/period (after time T) during which bandwidth B is
reserved for the LSP on a link, B is subtracted from the link for
that interval/period.
7.2. TE Representation in Relative Time
Alternatively, a relative time representation of bandwidths for a
link can be used. For example, the amount of the unreserved
bandwidth at a priority level for a link is Bj during a series of
time intervals/periods can be expressed as
[P0, B0], [P1, B1], [P2, B2], [P3, B3], ..., where
Pj = Tk - Tj, k = (j+1) and j = 0, 1, 2, 3, ....
In this representation, every time Tj (j = 0, 1, 2, ...) can be a
local time. A timer may expire for every unit of time (e.g., every
second) and may trigger --P0, which decrements P0. When P0 = 0, P1
becomes P0, P2 becomes P1, and so on.
If an LSP is completely deleted at time T and uses bandwidth B, then
for every time interval/period (after time T) during which bandwidth
B is reserved for the LSP on a link, B is added to the link for that
interval/period.
If an LSP is to be up at time T and uses bandwidth B, then for every
time interval/period (after time T) during which bandwidth B is
reserved for the LSP on a link, B is subtracted from the link for
that interval/period.
An advantage of using relative time representation is that the times
or clocks on all the elements involved can be different.
8. Security Considerations
The mechanism described in this document does not raise any new
security issues for the PCEP protocols.
9. IANA Considerations
This section specifies requests for IANA allocation.
Chen, et al. Expires January 3, 2016 [Page 21]
Internet-Draft PCE Temporal LSP July 2015
10. Acknowledgement
The authors would like to thank Xufeng Liu for his valuable comments
on this draft.
11. References
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element
(PCE) Communication Protocol (PCEP)", RFC 5440,
March 2009.
[RFC6006] Zhao, Q., King, D., Verhaeghe, F., Takeda, T., Ali, Z.,
and J. Meuric, "Extensions to the Path Computation Element
Communication Protocol (PCEP) for Point-to-Multipoint
Traffic Engineering Label Switched Paths", RFC 6006,
September 2010.
[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-pce-initiated-lsp]
Crabbe, E., Minei, I., Medved, J., 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.
11.2. Informative References
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
Element (PCE)-Based Architecture", RFC 4655, August 2006.
[RFC5862] Yasukawa, S. and A. Farrel, "Path Computation Clients
(PCC) - Path Computation Element (PCE) Requirements for
Point-to-Multipoint MPLS-TE", RFC 5862, June 2010.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001.
Chen, et al. Expires January 3, 2016 [Page 22]
Internet-Draft PCE Temporal LSP July 2015
Authors' Addresses
Huaimo Chen
Huawei Technologies
Boston, MA
US
Email: huaimo.chen@huawei.com
Mehmet Toy
Comcast
1800 Bishops Gate Blvd.
Mount Laurel, NJ 08054
USA
Email: mehmet_toy@cable.comcast.com
Vic Liu
China Mobile
No.32 Xuanwumen West Street, Xicheng District
Beijing, 100053
China
Email: liuzhiheng@chinamobile.com
Lei Liu
Fijitsu
USA
Email: lliu@us.fujitsu.com
Chen, et al. Expires January 3, 2016 [Page 23]