draft-ietf-teas-scheduled-resources-04.txt   draft-ietf-teas-scheduled-resources-05.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: June 5, 2018 Huawei Expires: July 20, 2018 Huawei
A. Farrel A. Farrel
Juniper Networks Juniper Networks
December 2, 2017 January 16, 2018
Architecture for Scheduled Use of Resources Architecture for Scheduled Use of Resources
draft-ietf-teas-scheduled-resources-04 draft-ietf-teas-scheduled-resources-05
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 into the future. This document efficiency of network resource usage into the future. This document
provides a framework that describes and discusses the architecture provides a framework that describes and discusses the architecture
for the scheduled reservation of TE resources. This document does for the scheduled reservation of TE resources. This document does
not describe specific protocols or protocol extensions needed to not describe specific protocols or protocol extensions needed to
skipping to change at page 1, line 40 skipping to change at page 1, line 40
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 June 5, 2018. This Internet-Draft will expire on July 20, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 25 skipping to change at page 2, line 25
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 . . . . . . . . . . . . . . . . . . 4 2.3. Planning Future LSPs . . . . . . . . . . . . . . . . . . 4
2.4. Looking at Future Demands on TE Resources . . . . . . . . 5 2.4. Looking at Future Demands on TE Resources . . . . . . . . 5
2.5. Requisite State Information . . . . . . . . . . . . . . . 5 2.5. Requisite State Information . . . . . . . . . . . . . . . 5
3. Architectural Concepts . . . . . . . . . . . . . . . . . . . 6 3. Architectural Concepts . . . . . . . . . . . . . . . . . . . 6
3.1. Where is Scheduling State Held? . . . . . . . . . . . . . 6 3.1. Where is Scheduling State Held? . . . . . . . . . . . . . 6
3.2. What State is Held? . . . . . . . . . . . . . . . . . . . 8 3.2. What State is Held? . . . . . . . . . . . . . . . . . . . 8
4. Architecture Overview . . . . . . . . . . . . . . . . . . . . 10 4. Architecture Overview . . . . . . . . . . . . . . . . . . . . 10
4.1. Service Request . . . . . . . . . . . . . . . . . . . . . 10 4.1. Service Request . . . . . . . . . . . . . . . . . . . . . 10
4.2. Initialization and Recovery . . . . . . . . . . . . . . . 11 4.1.1. Reoptimization After TED Updates . . . . . . . . . . 11
4.2. Initialization and Recovery . . . . . . . . . . . . . . . 12
4.3. Synchronization Between PCEs . . . . . . . . . . . . . . 12 4.3. Synchronization Between PCEs . . . . . . . . . . . . . . 12
5. Multi-Domain Considerations . . . . . . . . . . . . . . . . . 13 5. Multi-Domain Considerations . . . . . . . . . . . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 16 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 16
10. Informative References . . . . . . . . . . . . . . . . . . . 16 10. Informative References . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
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 11 skipping to change at page 6, line 11
The resource that is scheduled can be link capacity, physical The resource that is scheduled can be link capacity, physical
resources on a link, CPU utilization, memory, buffers on an resources on a link, CPU utilization, memory, buffers on an
interfaces, etc. The resource might also be the maximal unreserved interfaces, etc. The resource might also be the maximal unreserved
bandwidth of the link over a time interval. For any one resource bandwidth of the link over a time interval. For any one resource
there could be multiple pieces of scheduling state, and for any one there could be multiple pieces of scheduling state, and for any one
link, the timing windows might overlap. link, the timing windows might overlap.
There are multiple ways to realize this information model and There are multiple ways to realize this information model and
different ways to store the data. The resource state could be different ways to store the data. The resource state could be
expressed as a start time and an end time as shown above, or could be expressed as a start time and an end time as shown above, or could be
expressed as a start time and a duration. Multiple periods, possibly expressed as a start time and a duration. Multiple reservation
of different lengths, may be associated with one reservation request, periods, possibly of different lengths, may be need to be recorded
and a reservation might repeat on a regular cycle. Furthermore, the for each resource. Furthermore, the current state of network
current state of network reservation could be kept separate from the reservation could be kept separate from the scheduled usage, or
scheduled usage, or everything could be merged into a single TS everything could be merged into a single TS database.
database.
This scheduling state information can be used by applications to book An application may make a reservation request for immediate resource
resources for future or now, so as to maximize chance of services usage, or to book resources for future use so as to maximize the
being delivered. Also, it can avoid contention for resources of chance of services being delivered and to avoid contention for
LSPs. resources in the future. A single reservation request may book
resources for multiple periods and might request a reservation that
repeats on a regular cycle.
A computation engine (that is, a PCE) may use the scheduling state
information to help optimize the use of resources into the future and
reduce contention or blocking when the resources are actually needed.
Note that it is also necessary to store the information about future Note that it is also necessary to store the information about future
LSPs. This information is held to allow the LSPs to be instantiated LSPs as distinct from the specific resource scheduling. This
when they are due and using the paths/resources that have been information is held to allow the LSPs to be instantiated when they
computed for them, but also to provide correlation with the TS-TE are due and using the paths/resources that have been computed for
resource reservations so that it is clear why resources were reserved them, but also to provide correlation with the TS-TE resource
allowing pre-emption and handling release of reserved resources in reservations so that it is clear why resources were reserved allowing
the event of cancellation of future LSPs. pre-emption and handling release of reserved resources in the event
of cancellation of future LSPs. See Section 3.2 for further
discussion of the distinction between scheduled resource state and
scheduled LSP state.
3. Architectural Concepts 3. Architectural Concepts
This section examines several important architectural concepts that This section examines several important architectural concepts that
lead to design decisions that will influence how networks can achieve lead to design decisions that will influence how networks can achieve
TS-TE in a scalable and robust manner. TS-TE in a scalable and robust manner.
3.1. Where is Scheduling State Held? 3.1. Where is Scheduling State Held?
The scheduling state information described in Section 2.5 has to be The scheduling state information described in Section 2.5 has to be
skipping to change at page 8, line 13 skipping to change at page 8, line 20
contention. contention.
o If other sources of immediate LSPs are allowed (for example, other o If other sources of immediate LSPs are allowed (for example, other
controllers or autonomous action by head-end LSRs) then the controllers or autonomous action by head-end LSRs) then the
changes in resource availability caused by the setup or tear down changes in resource availability caused by the setup or tear down
of these LSPs must be reflected in the TED (by use of the IGP as of these LSPs must be reflected in the TED (by use of the IGP as
currently) and may have an impact of planned future LSPs. This currently) and may have an impact of planned future LSPs. This
impact can be mitigated by re-planning future LSPs or through LSP impact can be mitigated by re-planning future LSPs or through LSP
preemption. preemption.
o If other sources of planned LSPs are allowed, they can request
path computation and resource reservation from the centralized PCE
using PCEP [RFC5440].
o If the scheduling state is held centrally at a PCE, the state must o If the scheduling state is held centrally at a PCE, the state must
be held and restored after a system restart. This is relatively be held and restored after a system restart. This is relatively
easy to achieve on a central server that can have access to non- easy to achieve on a central server that can have access to non-
volatile storage. The PCE could also synchronize the scheduling volatile storage. The PCE could also synchronize the scheduling
state with other PCEs after restart. See Section 4.2 for details. state with other PCEs after restart. See Section 4.2 for details.
o Of course, a centralized system must store information about all o Of course, a centralized system must store information about all
of the resources in the network. In a busy network with a high of the resources in the network. In a busy network with a high
arrival rate of new LSPs and a low hold time for each LSP, this arrival rate of new LSPs and a low hold time for each LSP, this
could be a lot of state. This is multiplied by the size of the could be a lot of state. This is multiplied by the size of the
network measured both by the number of links and nodes, and by the network measured both by the number of links and nodes, and by the
number of trackable resources on each link or at each node. The number of trackable resources on each link or at each node. This
challenge may be mitigated by the centralized server being challenge may be mitigated by the centralized server being
dedicated hardware, but the problem of collecting the information dedicated hardware, but there remains the problem of collecting
from the network is only solved if the central server has full the information from the network in a timely way when there is
control of the booking of resources and the establishment of new potentially a very large amount of information to be collected and
LSPs. when the rate of change of that information is high. This latter
challenge is only solved if the central server has full control of
the booking of resources and the establishment of new LSPs so that
the information from the network only serves to confirm what the
central server expected.
Thus the architectural conclusion is that scheduling state should be Thus the architectural conclusion is that scheduling state should be
held centrally at the point of use and not in the network devices. held centrally at the point of use and not in the network devices.
3.2. What State is Held? 3.2. What State is Held?
As already described, the PCE needs access to an enhanced, time-based As already described, the PCE needs access to an enhanced, time-based
TED. It stores the traffic engineering (TE) information such as TED. It stores the traffic engineering (TE) information such as
bandwidth for every link for a series of time intervals. There are a bandwidth for every link for a series of time intervals. There are a
few ways to store the TE information in the TED. For example, few ways to store the TE information in the TED. For example,
skipping to change at page 9, line 36 skipping to change at page 9, line 38
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 reserved on a link for the LSP is B from time T2 to
T3 and the unreserved bandwidth on the link is B2 from T2 to T3, B is T3 and the unreserved bandwidth on the link is B2 from T2 to T3, B is
added to the link for the time interval from T2 to T3 and the added to the link for the time interval from T2 to T3 and the
unreserved bandwidth on the link from T2 to T3 will be B2 + B. unreserved bandwidth on the link from T2 to T3 will be B2 + B.
This suggests that the PCE needs an LSP Database (LSP-DB) This suggests that the PCE needs an LSP Database (LSP-DB) [RFC8231]
[I-D.ietf-pce-stateful-pce] that contains information not only about that contains information not only about LSPs that are active in the
LSPs that are active in the network, but also those that are planned. network, but also those that are planned. The information for an LSP
The information for an LSP stored in the LSP-DB includes for each stored in the LSP-DB includes for each time interval that applies to
time interval that applies to the LSP: the time interval, the paths the LSP: the time interval, the paths computed for the LSP satisfying
computed for the LSP satisfying the constraints in the time interval, the constraints in the time interval, and the resources such as
and the resources such as bandwidth reserved for the LSP in the time bandwidth reserved for the LSP in the time interval. See also
interval. See also Section 2.3 Section 2.3
It is an implementation choice how the TED and LSP-DB are stored both It is an implementation choice how the TED and LSP-DB are stored both
for dynamic use and for recovery after failure or restart, but it may for dynamic use and for recovery after failure or restart, but it may
be noted that all of the information in the scheduled TED can be be noted that all of the information in the scheduled TED can be
recovered from the active network state and from the scheduled LSP- recovered from the active network state and from the scheduled LSP-
DB. DB.
4. Architecture Overview 4. Architecture Overview
The architectural considerations and conclusions described in the The architectural considerations and conclusions described in the
skipping to change at page 11, line 38 skipping to change at page 11, line 41
status of the LSP in the LSP-DB according to the report. status of the LSP in the LSP-DB according to the report.
When an LSP is no longer required (either because the Service When an LSP is no longer required (either because the Service
Requester has cancelled the request, or because the LSP's scheduled Requester has cancelled the request, or because the LSP's scheduled
lifetime has expired) the PCE can remove it. If the LSP is currently lifetime has expired) the PCE can remove it. If the LSP is currently
active, the PCE instructs the head-end LSR to tear it down (d), and active, the PCE instructs the head-end LSR to tear it down (d), and
the network resource usage will be updated by the IGP and advertised the network resource usage will be updated by the IGP and advertised
back to the PCE through the IGP or BGP-LS (e). Once the LSP is no back to the PCE through the IGP or BGP-LS (e). Once the LSP is no
longer active, the PCE can remove it from the LSP-DB (b). longer active, the PCE can remove it from the LSP-DB (b).
4.1.1. Reoptimization After TED Updates
When the TED is updated as indicated in Section 4.1, the PCE may
perform reoptimization of the LSPs for which it has computed paths.
These LSPs may be already provisioned in which case the PCE issues
PCEP Update request messages for the LSPs that should be adjusted.
Additionally, the LSPs being reoptimized may be scheduled LSPs that
have not yet been provisioned, in which case reoptimization involves
updating the store of scheduled LSPs and resources.
In all cases, the purpose of reoptimization is to take account of the
resource usage and availability in the network and to compute paths
for the current and future LSPs that best satisfy the objectives of
those LSPs while keeping the network as clear as possible to support
further LSPs.
4.2. Initialization and Recovery 4.2. Initialization and Recovery
When a PCE in the architecture shown in Figure 2 is initialized, it When a PCE in the architecture shown in Figure 2 is initialized, it
must learn state from the network, from its stored databases, and must learn state from the network, from its stored databases, and
potentially from other PCEs in the network. potentially from other PCEs in the network.
The first step is to get an accurate view of the topology and The first step is to get an accurate view of the topology and
resource availability in the network. This would normally involve resource availability in the network. This would normally involve
reading the state direct from the network via the IGP or BGP-LS (e), reading the state direct from the network via the IGP or BGP-LS (e),
but might include receiving a copy of the TED from another PCE. Note but might include receiving a copy of the TED from another PCE. Note
skipping to change at page 13, line 12 skipping to change at page 13, line 31
utilize some synchronization optimization techniques for efficiency. utilize some synchronization optimization techniques for efficiency.
Another variation would be to request information from other PCEs for Another variation would be to request information from other PCEs for
a particular time slice, but this might have impact on the a particular time slice, but this might have impact on the
optimization algorithm. optimization algorithm.
5. Multi-Domain Considerations 5. Multi-Domain Considerations
Multi-domain path computation usually requires some form of Multi-domain path computation usually requires some form of
cooperation between PCEs each of which has responsibility for cooperation between PCEs each of which has responsibility for
determining a segment of the end-to-end path in the domain for which determining a segment of the end-to-end path in the domain for which
it has computationonal responsiblity. When computing a scheduled it has computational responsibility. When computing a scheduled
path, resources need to be booked in all of the domains that the path path, resources need to be booked in all of the domains that the path
will cross so that they are available when the LSP is finlly will cross so that they are available when the LSP is finally
signalled. signalled.
Per-domain path computation [RFC5152] is not an appropriate mechanism Per-domain path computation [RFC5152] is not an appropriate mechanism
when a scheduled LSP is being computed because the computation when a scheduled LSP is being computed because the computation
requests at downstream PCEs are only triggered by signaling. requests at downstream PCEs are only triggered by signaling.
However, a similar mechanism could be used where cooperating PCEs However, a similar mechanism could be used where cooperating PCEs
exchange PCReq messages for a scheduled LSP as shown in Figure 3. In exchange PCReq messages for a scheduled LSP as shown in Figure 3. In
this case the service requester asks for a scheduled LSP that will this case the service requester asks for a scheduled LSP that will
span two domains (a). PCE1 computes a path across Domain 1 and span two domains (a). PCE1 computes a path across Domain 1 and
reserves the resources, and also asks PCE2 to compute and reserve in reserves the resources, and also asks PCE2 to compute and reserve in
skipping to change at page 14, line 40 skipping to change at page 14, line 40
Another mechanism for PCE cooperation in multi-domain LSP setup is Another mechanism for PCE cooperation in multi-domain LSP setup is
Backward- Recursive Path Computation (BRPC) [RFC5441]. This approach Backward- Recursive Path Computation (BRPC) [RFC5441]. This approach
relies on the downstream domain supply a variety of potential paths relies on the downstream domain supply a variety of potential paths
to the upstream domain. Although BRPC can arrive at a more optimal to the upstream domain. Although BRPC can arrive at a more optimal
end-to-end path than per-domain path computation, it is not well end-to-end path than per-domain path computation, it is not well
suited to LSP scheduling because the downstream PCE would need to suited to LSP scheduling because the downstream PCE would need to
reserve resources on all of the potential paths and then release reserve resources on all of the potential paths and then release
those that the upstream PCE announced it did not plan to use. those that the upstream PCE announced it did not plan to use.
Finally we should consider hierarchical PCE (H-PCE) [RFC6805]. This Finally we should consider hierarchical PCE (H-PCE) [RFC6805]. This
mode of operatation is similar to that shown in Figure 3, but a mode of operation is similar to that shown in Figure 3, but a parent
parent PCE is used to coordinate the requests to the child PCEs PCE is used to coordinate the requests to the child PCEs resulting in
resulting in better visibility of the end-to-end path and better better visibility of the end-to-end path and better coordination of
coordination of the resource booking. The sequenced flow of control the resource booking. The sequenced flow of control is shown in
is shown in Figure 4. Figure 4.
------------------- -------------------
| Service Requester | | Service Requester |
------------------- -------------------
^ ^
a| a|
v v
-------- --------
| | | |
| Parent | | Parent |
skipping to change at page 15, line 45 skipping to change at page 15, line 45
| ----- ----- | | ----- ----- | | ----- ----- | | ----- ----- |
---------------------- ---------------------- ---------------------- ----------------------
Figure 4: Hierarchical PCE for Path Computation for Scheduled LSPs Figure 4: Hierarchical PCE for Path Computation for Scheduled LSPs
6. Security Considerations 6. Security Considerations
The protocol implications of scheduled resources are unchanged from The protocol implications of scheduled resources are unchanged from
"on-demand" LSP computation and setup. A discussion of securing PCEP "on-demand" LSP computation and setup. A discussion of securing PCEP
is found in [RFC5440] and work to extend that security is provided in is found in [RFC5440] and work to extend that security is provided in
[I-D.ietf-pce-pceps]. Furthermore, the path key mechanism described [RFC8253]. Furthermore, the path key mechanism described in
in [RFC5520] can be used to enhance privacy and security. [RFC5520] can be used to enhance privacy and security.
Similarly, there is no change to the security implications for the Similarly, there is no change to the security implications for the
signaling of scheduled LSPs. A discussion of the security of the signaling of scheduled LSPs. A discussion of the security of the
signaling protocols that would be used is found in [RFC5920]. signaling protocols that would be used is found in [RFC5920].
However, the use of scheduled LSPs extends the attack surface for a However, the use of scheduled LSPs extends the attack surface for a
PCE-enabled TE system by providing a larger (logically infinte) PCE-enabled TE system by providing a larger (logically infinite)
window during which an attack can be initiated or planned. That is, window during which an attack can be initiated or planned. That is,
if bogus scheduled LSPs can be requested, they can be entered into if bogus scheduled LSPs can be requested, they can be entered into
the LSP-DB, then a large number of LSPs could be launched, or the LSP-DB, then a large number of LSPs could be launched, or
significant network resources could be blocked. Of course, significant network resources could be blocked. Of course,
additional authorization could be applied for access to LSP additional authorization could be applied for access to LSP
scheduling, and diagnostic tools could inspect the LSP DB to spot scheduling, and diagnostic tools could inspect the LSP DB to spot
attacks. attacks.
7. IANA Considerations 7. IANA Considerations
skipping to change at page 16, line 33 skipping to change at page 16, line 33
[I-D.yong-ccamp-ason-gmpls-autobw-service] both of which provide [I-D.yong-ccamp-ason-gmpls-autobw-service] both of which provide
approaches to auto-bandwidth services in GMPLS networks. approaches to auto-bandwidth services in GMPLS networks.
Mehmet Toy, Lei Liu, and Khuzema Pithewan contributed the earlier Mehmet Toy, Lei Liu, and Khuzema Pithewan contributed the 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. authors of that draft on Temporal Tunnel Services.
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.
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
[DRAGON] National Science Foundation, "http://www.maxgigapop.net/ [DRAGON] National Science Foundation, "http://www.maxgigapop.net/
wp-content/uploads/The-DRAGON-Project.pdf". wp-content/uploads/The-DRAGON-Project.pdf".
[I-D.chen-teas-frmwk-tts] [I-D.chen-teas-frmwk-tts]
Chen, H., Toy, M., Liu, L., and K. Pithewan, "Framework Chen, H., Toy, M., Liu, L., and K. Pithewan, "Framework
for Temporal Tunnel Services", draft-chen-teas-frmwk- for Temporal Tunnel Services", draft-chen-teas-frmwk-
tts-01 (work in progress), March 2016. tts-01 (work in progress), March 2016.
[I-D.ietf-pce-pceps]
Lopez, D., Dios, O., Wu, Q., and D. Dhody, "Secure
Transport for PCEP", draft-ietf-pce-pceps-18 (work in
progress), September 2017.
[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-21 (work in progress), June 2017.
[I-D.yong-ccamp-ason-gmpls-autobw-service] [I-D.yong-ccamp-ason-gmpls-autobw-service]
Yong, L. and Y. Lee, "ASON/GMPLS Extension for Reservation Yong, L. and Y. Lee, "ASON/GMPLS Extension for Reservation
and Time Based Automatic Bandwidth Service", draft-yong- and Time Based Automatic Bandwidth Service", draft-yong-
ccamp-ason-gmpls-autobw-service-00 (work in progress), ccamp-ason-gmpls-autobw-service-00 (work in progress),
October 2006. October 2006.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
<https://www.rfc-editor.org/info/rfc3209>. <https://www.rfc-editor.org/info/rfc3209>.
skipping to change at page 18, line 44 skipping to change at page 18, line 39
Computation Element Architecture", RFC 7399, Computation Element Architecture", RFC 7399,
DOI 10.17487/RFC7399, October 2014, DOI 10.17487/RFC7399, October 2014,
<https://www.rfc-editor.org/info/rfc7399>. <https://www.rfc-editor.org/info/rfc7399>.
[RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and
S. Ray, "North-Bound Distribution of Link-State and S. Ray, "North-Bound Distribution of Link-State and
Traffic Engineering (TE) Information Using BGP", RFC 7752, Traffic Engineering (TE) Information Using BGP", RFC 7752,
DOI 10.17487/RFC7752, March 2016, DOI 10.17487/RFC7752, March 2016,
<https://www.rfc-editor.org/info/rfc7752>. <https://www.rfc-editor.org/info/rfc7752>.
[RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path
Computation Element Communication Protocol (PCEP)
Extensions for Stateful PCE", RFC 8231,
DOI 10.17487/RFC8231, September 2017,
<https://www.rfc-editor.org/info/rfc8231>.
[RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody,
"PCEPS: Usage of TLS to Provide a Secure Transport for the
Path Computation Element Communication Protocol (PCEP)",
RFC 8253, DOI 10.17487/RFC8253, October 2017,
<https://www.rfc-editor.org/info/rfc8253>.
Authors' Addresses Authors' Addresses
Yan Zhuang Yan Zhuang
Huawei Huawei
101 Software Avenue, Yuhua District 101 Software Avenue, Yuhua District
Nanjing, Jiangsu 210012 Nanjing, Jiangsu 210012
China China
Email: zhuangyan.zhuang@huawei.com Email: zhuangyan.zhuang@huawei.com
Qin Wu Qin Wu
Huawei Huawei
101 Software Avenue, Yuhua District 101 Software Avenue, Yuhua District
Nanjing, Jiangsu 210012 Nanjing, Jiangsu 210012
China China
Email: bill.wu@huawei.com Email: bill.wu@huawei.com
Huaimo Chen Huaimo Chen
Huawei Huawei
 End of changes. 24 change blocks. 
60 lines changed or deleted 90 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/