draft-ietf-teas-scheduled-resources-01.txt   draft-ietf-teas-scheduled-resources-02.txt 
TEAS Working Group Y. Zhuang TEAS Working Group Y. Zhuang
Internet-Draft Q. Wu Internet-Draft Q. Wu
Intended status: Standards Track H. Chen Intended status: Standards Track H. Chen
Expires: June 3, 2017 Huawei Expires: July 7, 2017 Huawei
A. Farrel A. Farrel
Juniper Networks Juniper Networks
November 30, 2016 January 3, 2017
Architecture for Scheduled Use of Resources Architecture for Scheduled Use of Resources
draft-ietf-teas-scheduled-resources-01 draft-ietf-teas-scheduled-resources-02
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 3, 2017. This Internet-Draft will expire on July 7, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2017 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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 28 skipping to change at page 2, line 28
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.2. Initialization and Recovery . . . . . . . . . . . . . . . 11
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 . . . . . . . . . . . . . . . . . . . 13 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 13 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 16
10. Informative References . . . . . . . . . . . . . . . . . . . 13 10. Informative References . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
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 13, line 9 skipping to change at page 13, line 9
number of PCEs which support scheduling is small, but as the number number of PCEs which support scheduling is small, but as the number
increases considerable message exchange needs to happen to keep the increases considerable message exchange needs to happen to keep the
scheduled databases synchronized. Future solutions could also scheduled databases synchronized. Future solutions could also
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
TBD Multi-domain path computation usually requires some form of
cooperation between PCEs each of which has responsibility for
determining a segment of the end-to-end path in the domain for which
it has computationonal responsiblity. When computing a scheduled
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
signalled.
Per-domain path computation [RFC5152] is not an appropriate mechanism
when a scheduled LSP is being computed because the computation
requests at downstream PCEs are only triggered by signaling.
However, a similar mechanism could be used where cooperating PCEs
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
span two domains (a). PCE1 computes a path across Domain 1 and
reserves the resources, and also asks PCE2 to compute and reserve in
Domain 2 (b). PCE2 may return a full path, or could return a path
key [RFC5520]. When it is time for LSP setup PCE1 triggers the head-
end LSR (c) and the LSP is signaled (d). If a path key is used, the
entry LSR in Domain 2 will consult PCE2 for the path expansion (e)
before completing signaling (f).
-------------------
| Service Requester |
-------------------
^
a|
v
------ b ------
| |<---------------->| |
| PCE1 | | PCE2 |
| | | |
------ ------
^ ^
| |
c| e|
| |
----+----------------- ----+-----------------
| | Domain 1 | | | Domain 2 |
| v | | v |
| ----- d ----- | | ----- f ----- |
| | LSR |<--->| LSR |<-+--+->| LSR |<--->| LSR | |
| ----- ----- | | ----- ----- |
---------------------- ----------------------
Figure 3: Per-Domain Path Computation for Scheduled LSPs
Another mechanism for PCE cooperation in multi-domain LSP setup is
Backward- Recursive Path Computation (BRPC) [RFC5441]. This approach
relies on the downstream domain supply a variety of potential paths
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
suited to LSP scheduling because the downstream PCE would need to
reserve resources on all of the potential paths and then release
those that the upstream PCE announced it did not plan to use.
Finally we should consider hierarchical PCE (H-PCE) [RFC6805]. This
mode of operatation is similar to that shown in Figure 3, but a
parent PCE is used to coordinate the requests to the child PCEs
resulting in better visibility of the end-to-end path and better
coordination of the resource booking. The sequenced flow of control
is shown in Figure 4.
-------------------
| Service Requester |
-------------------
^
a|
v
--------
| |
| Parent |
| PCE |
| |
--------
^ ^ b
b| |_______________________
| |
v v
------ ------
| | | |
| PCE1 | | PCE2 |
| | | |
------ ------
^ ^
| |
c| e|
| |
----+----------------- ----+-----------------
| | Domain 1 | | | Domain 2 |
| v | | v |
| ----- d ----- | | ----- f ----- |
| | LSR |<--->| LSR |<-+--+->| LSR |<--->| LSR | |
| ----- ----- | | ----- ----- |
---------------------- ----------------------
Figure 4: Hierarchical PCE for Path Computation for Scheduled LSPs
6. Security Considerations 6. Security Considerations
TBD The protocol implications of scheduled resources are unchanged from
"on-demand" LSP computation and setup. A discussion of securing PCEP
is found in [RFC5440] and work to extend that security is provided in
[I-D.ietf-pce-pceps]. Furthermore, the path key mechanism described
in [RFC5520] can be used to enhance privacy and security.
Similarly, there is no change to the security implications for the
signaling of scheduled LSPs. A discussion of the security of the
signaling protocols that would be used is found in [RFC5920].
However, the use of scheduled LSPs extends the attack surface for a
PCE-enabled TE system by providing a larger (logically infinte)
window during which an attack can be initiated or planned. That is,
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
significant network resources could be blocked. Of course,
additional authorization could be applied for access to LSP
scheduling, and diagnostic tools could inspect the LSP DB to spot
attacks.
7. IANA Considerations 7. IANA Considerations
This architecture document makes no request for IANA action. This architecture document makes no request for IANA action.
8. Acknowledgements 8. Acknowledgements
This work has benefited from the discussions of resource scheduling This work has benefited from the discussions of resource scheduling
over the years. In particular the DRAGON project [DRAGON] and over the years. In particular the DRAGON project [DRAGON] and
[I-D.yong-ccamp-ason-gmpls-autobw-service] both of which provide [I-D.yong-ccamp-ason-gmpls-autobw-service] both of which provide
skipping to change at page 14, line 5 skipping to change at page 17, line 5
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, W., and D. Dhody, "Secure
Transport for PCEP", draft-ietf-pce-pceps-11 (work in
progress), January 2017.
[I-D.ietf-pce-stateful-pce] [I-D.ietf-pce-stateful-pce]
Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP
Extensions for Stateful PCE", draft-ietf-pce-stateful- Extensions for Stateful PCE", draft-ietf-pce-stateful-
pce-17 (work in progress), November 2016. pce-18 (work in progress), December 2016.
[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,
skipping to change at page 14, line 42 skipping to change at page 17, line 47
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
Element (PCE)-Based Architecture", RFC 4655, Element (PCE)-Based Architecture", RFC 4655,
DOI 10.17487/RFC4655, August 2006, DOI 10.17487/RFC4655, August 2006,
<http://www.rfc-editor.org/info/rfc4655>. <http://www.rfc-editor.org/info/rfc4655>.
[RFC5063] Satyanarayana, A., Ed. and R. Rahman, Ed., "Extensions to [RFC5063] Satyanarayana, A., Ed. and R. Rahman, Ed., "Extensions to
GMPLS Resource Reservation Protocol (RSVP) Graceful GMPLS Resource Reservation Protocol (RSVP) Graceful
Restart", RFC 5063, DOI 10.17487/RFC5063, October 2007, Restart", RFC 5063, DOI 10.17487/RFC5063, October 2007,
<http://www.rfc-editor.org/info/rfc5063>. <http://www.rfc-editor.org/info/rfc5063>.
[RFC5152] Vasseur, JP., Ed., Ayyangar, A., Ed., and R. Zhang, "A
Per-Domain Path Computation Method for Establishing Inter-
Domain Traffic Engineering (TE) Label Switched Paths
(LSPs)", RFC 5152, DOI 10.17487/RFC5152, February 2008,
<http://www.rfc-editor.org/info/rfc5152>.
[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol (PCEP)", RFC 5440, Element (PCE) Communication Protocol (PCEP)", RFC 5440,
DOI 10.17487/RFC5440, March 2009, DOI 10.17487/RFC5440, March 2009,
<http://www.rfc-editor.org/info/rfc5440>. <http://www.rfc-editor.org/info/rfc5440>.
[RFC5441] Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. Le Roux,
"A Backward-Recursive PCE-Based Computation (BRPC)
Procedure to Compute Shortest Constrained Inter-Domain
Traffic Engineering Label Switched Paths", RFC 5441,
DOI 10.17487/RFC5441, April 2009,
<http://www.rfc-editor.org/info/rfc5441>.
[RFC5520] Bradford, R., Ed., Vasseur, JP., and A. Farrel,
"Preserving Topology Confidentiality in Inter-Domain Path
Computation Using a Path-Key-Based Mechanism", RFC 5520,
DOI 10.17487/RFC5520, April 2009,
<http://www.rfc-editor.org/info/rfc5520>.
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS
Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010,
<http://www.rfc-editor.org/info/rfc5920>.
[RFC6805] King, D., Ed. and A. Farrel, Ed., "The Application of the
Path Computation Element Architecture to the Determination
of a Sequence of Domains in MPLS and GMPLS", RFC 6805,
DOI 10.17487/RFC6805, November 2012,
<http://www.rfc-editor.org/info/rfc6805>.
[RFC7399] Farrel, A. and D. King, "Unanswered Questions in the Path [RFC7399] Farrel, A. and D. King, "Unanswered Questions in the Path
Computation Element Architecture", RFC 7399, Computation Element Architecture", RFC 7399,
DOI 10.17487/RFC7399, October 2014, DOI 10.17487/RFC7399, October 2014,
<http://www.rfc-editor.org/info/rfc7399>. <http://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,
<http://www.rfc-editor.org/info/rfc7752>. <http://www.rfc-editor.org/info/rfc7752>.
 End of changes. 12 change blocks. 
14 lines changed or deleted 162 lines changed or added

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