draft-ietf-teas-scheduled-resources-06.txt   draft-ietf-teas-scheduled-resources-07.txt 
TEAS Working Group Y. Zhuang TEAS Working Group Y. Zhuang
Internet-Draft Q. Wu Internet-Draft Q. Wu
Intended status: Informational H. Chen Intended status: Informational H. Chen
Expires: August 24, 2018 Huawei Expires: October 12, 2018 Huawei
A. Farrel A. Farrel
Juniper Networks Juniper Networks
February 20, 2018 April 10, 2018
Framework for Scheduled Use of Resources Framework for Scheduled Use of Resources
draft-ietf-teas-scheduled-resources-06 draft-ietf-teas-scheduled-resources-07
Abstract Abstract
Time-scheduled reservation of traffic engineering (TE) resources can Time-scheduled reservation of traffic engineering (TE) resources can
be used to provide resource booking for TE Label Switched Paths so as be used to provide resource booking for TE Label Switched Paths so as
to better guarantee services for customers and to improve the to better guarantee services for customers and to improve the
efficiency of network resource usage at any moment in time including efficiency of network resource usage at any moment in time including
future planned network usage. This document provides a framework future planned network usage. This document provides a framework
that describes and discusses the architecture for supporting that describes and discusses the architecture for supporting
scheduled reservation of TE resources. This document does not scheduled reservation of TE resources. This document does not
skipping to change at page 1, line 41 skipping to change at page 1, line 41
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 24, 2018. This Internet-Draft will expire on October 12, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 20 skipping to change at page 2, line 20
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Provisioning TE-LSPs and TE Resources . . . . . . . . . . 3 2.1. Provisioning TE-LSPs and TE Resources . . . . . . . . . . 3
2.2. Selecting the Path of an LSP . . . . . . . . . . . . . . 4 2.2. Selecting the Path of an LSP . . . . . . . . . . . . . . 4
2.3. Planning Future LSPs . . . . . . . . . . . . . . . . . . 5 2.3. Planning Future LSPs . . . . . . . . . . . . . . . . . . 5
2.4. Looking at Future Demands on TE Resources . . . . . . . . 6 2.4. Looking at Future Demands on TE Resources . . . . . . . . 6
2.4.1. Interaction Between Time-Scheduled and Ad Hoc
Reservations . . . . . . . . . . . . . . . . . . . . 6
2.5. Requisite State Information . . . . . . . . . . . . . . . 6 2.5. Requisite State Information . . . . . . . . . . . . . . . 6
3. Architectural Concepts . . . . . . . . . . . . . . . . . . . 7 3. Architectural Concepts . . . . . . . . . . . . . . . . . . . 8
3.1. Where is Scheduling State Held? . . . . . . . . . . . . . 8 3.1. Where is Scheduling State Held? . . . . . . . . . . . . . 8
3.2. What State is Held? . . . . . . . . . . . . . . . . . . . 10 3.2. What State is Held? . . . . . . . . . . . . . . . . . . . 10
3.3. Enforcement of Operator Policy . . . . . . . . . . . . . 11 3.3. Enforcement of Operator Policy . . . . . . . . . . . . . 11
4. Architecture Overview . . . . . . . . . . . . . . . . . . . . 12 4. Architecture Overview . . . . . . . . . . . . . . . . . . . . 12
4.1. Service Request . . . . . . . . . . . . . . . . . . . . . 13 4.1. Service Request . . . . . . . . . . . . . . . . . . . . . 13
4.1.1. Reoptimization After TED Updates . . . . . . . . . . 14 4.1.1. Reoptimization After TED Updates . . . . . . . . . . 14
4.2. Initialization and Recovery . . . . . . . . . . . . . . . 15 4.2. Initialization and Recovery . . . . . . . . . . . . . . . 15
4.3. Synchronization Between PCEs . . . . . . . . . . . . . . 15 4.3. Synchronization Between PCEs . . . . . . . . . . . . . . 15
5. Multi-Domain Considerations . . . . . . . . . . . . . . . . . 16 5. Multi-Domain Considerations . . . . . . . . . . . . . . . . . 16
6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 19 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 19
10. Informative References . . . . . . . . . . . . . . . . . . . 19 10. Informative References . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction 1. Introduction
Traffic Engineering Label Switched Paths (TE-LSPs) are connection Traffic Engineering Label Switched Paths (TE-LSPs) are connection
oriented tunnels in packet and non-packet networks [RFC3209], oriented tunnels in packet and non-packet networks [RFC3209],
[RFC3945]. TE-LSPs may reserve network resources for use by the [RFC3945]. TE-LSPs may reserve network resources for use by the
traffic they carry, thus providing some guarantees of service traffic they carry, thus providing some guarantees of service
delivery and allowing a network operator to plan the use of the delivery and allowing a network operator to plan the use of the
resources across the whole network. resources across the whole network.
skipping to change at page 6, line 25 skipping to change at page 6, line 28
If, therefore, we were able to know in advance what LSPs were going If, therefore, we were able to know in advance what LSPs were going
to be requested, we could plan for them and ensure resources were to be requested, we could plan for them and ensure resources were
available. Furthermore, such an approach enables a commitment to be available. Furthermore, such an approach enables a commitment to be
made to a service user that an LSP will be set up and available at a made to a service user that an LSP will be set up and available at a
specific time. specific time.
A reservation service can be achieved by tracking the current use of A reservation service can be achieved by tracking the current use of
network resources and also having a future view of the resource network resources and also having a future view of the resource
usage. We call this Time-Scheduled TE (TS-TE) resource reservation. usage. We call this Time-Scheduled TE (TS-TE) resource reservation.
2.4.1. Interaction Between Time-Scheduled and Ad Hoc Reservations
There will, of course, be a mixture of resource uses in a network.
For example, normal unplanned LSPs may be requested alongside TS-TE
LSPs. When an unplanned LSP is requested no prior accommodation can
be made to arrange resource availability, so the LSP can be placed no
better than would be the case without TS-TE. However, the new LSP
can be placed considering the future demands of TS-TE LSPs that have
already been requested. Of course, the unplanned LSP has no known
end time and so any network planning must assume that it will consume
resources for ever.
2.5. Requisite State Information 2.5. Requisite State Information
In order to achieve the TS-TE resource reservation, the use of In order to achieve the TS-TE resource reservation, the use of
resources on the path needs to be scheduled. Scheduling state is resources on the path needs to be scheduled. Scheduling state is
used to indicate when resources are reserved and when they are used to indicate when resources are reserved and when they are
available for use. available for use.
A simple information model for one piece of scheduling state is as A simple information model for one piece of scheduling state is as
follows: follows:
skipping to change at page 10, line 45 skipping to change at page 11, line 10
Figure 1. Figure 1.
But it must be noted that service requests for future LSPs are known But it must be noted that service requests for future LSPs are known
in terms of the LSPs whose paths are computed and for which resources in terms of the LSPs whose paths are computed and for which resources
are scheduled. For example, if the requester of a future LSP decides are scheduled. For example, if the requester of a future LSP decides
to cancel the request or to modify the request, the PCE must be able to cancel the request or to modify the request, the PCE must be able
to map this to the resources that were reserved. When the LSP or the to map this to the resources that were reserved. When the LSP or the
request for the LSP with a number of time intervals is cancelled, the request for the LSP with a number of time intervals is cancelled, the
PCE must release the resources that were reserved on each of the PCE must release the resources that were reserved on each of the
links along the path of the LSP in every time intervals from the TED. links along the path of the LSP in every time intervals from the TED.
If the bandwidth reserved on a link for the LSP is B from time T2 to If the bandwidth that had been reserved for the LSP on a link was B
T3 and the unreserved bandwidth on the link is B2 from T2 to T3, B is from time T2 to T3 and the unreserved bandwidth on the link was B2
added to the link for the time interval from T2 to T3 and the from T2 to T3, then B is added back to the link for the time interval
unreserved bandwidth on the link from T2 to T3 will be B2 + B. from T2 to T3 and the unreserved bandwidth on the link from T2 to T3
will be seen to be B2 + B.
This suggests that the PCE needs an LSP Database (LSP-DB) [RFC8231] This suggests that the PCE needs an LSP Database (LSP-DB) [RFC8231]
that contains information not only about LSPs that are active in the that contains information not only about LSPs that are active in the
network, but also those that are planned. The information for an LSP network, but also those that are planned. The information for an LSP
stored in the LSP-DB includes for each time interval that applies to stored in the LSP-DB includes for each time interval that applies to
the LSP: the time interval, the paths computed for the LSP satisfying the LSP: the time interval, the paths computed for the LSP satisfying
the constraints in the time interval, and the resources such as the constraints in the time interval, and the resources such as
bandwidth reserved for the LSP in the time interval. See also bandwidth reserved for the LSP in the time interval. See also
Section 2.3 Section 2.3
skipping to change at page 19, line 36 skipping to change at page 19, line 36
Mehmet Toy, Lei Liu, and Khuzema Pithewan contributed to an earlier Mehmet Toy, Lei Liu, and Khuzema Pithewan contributed to an earlier
version of [I-D.chen-teas-frmwk-tts]. We would like to thank the version of [I-D.chen-teas-frmwk-tts]. We would like to thank the
authors of that draft on Temporal Tunnel Services for material that authors of that draft on Temporal Tunnel Services for material that
assisted in thinking about this document. assisted in thinking about this document.
Thanks to Michael Scharf and Daniele Ceccarelli for useful comments Thanks to Michael Scharf and Daniele Ceccarelli for useful comments
on this work. on this work.
Jonathan Hardwick provided a helpful Routing Directorate review. Jonathan Hardwick provided a helpful Routing Directorate review.
Deborah Brungard suggested many changes during her AD review. Deborah Brungard, Mirja Kuehlewind, and Benjamin Kaduk suggested many
changes during their Area Director reviews.
9. Contributors 9. Contributors
The following people contributed to discussions that led to the The following people contributed to discussions that led to the
development of this document: development of this document:
Dhruv Dhody Dhruv Dhody
Email: dhruv.dhody@huawei.com Email: dhruv.dhody@huawei.com
10. Informative References 10. Informative References
 End of changes. 10 change blocks. 
11 lines changed or deleted 27 lines changed or added

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/