Internet Engineering Task Force H. Chen Internet-Draft Huawei Technologies Intended status: Standards Track M. Toy Expires: September 22, 2016 Comcast L. Liu Fujitsu K. Pithewan Infinera March 21, 2016 Framework for Temporal Tunnel Services draft-chen-teas-frmwk-tts-01.txt Abstract For existing MPLS LSP tunnel services, it is hard for LSP tunnels to be booked in advance. In addition, once an LSP tunnel is set up, it is assumed to consume a certain amount of resources such as link bandwidth forever. Temporal LSP tunnel services (TTS) provides an easy way for us to book temporal LSP tunnels in advance. More importantly, a temporal LSP is an LSP with one or more time intervals and it is assumed to consume the resources and carry traffic only in these time intervals. This document specifies a framework for temporal LSP tunnel services and provides a few of reference models along with logical components required to design a solution for TTS. 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 September 22, 2016. Copyright Notice Chen, et al. Expires September 22, 2016 [Page 1] Internet-Draft Framework for TTS March 2016 Copyright (c) 2016 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 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Operations Overview . . . . . . . . . . . . . . . . . . . . . 5 3.1. Simple Time Interval . . . . . . . . . . . . . . . . . . . 5 3.2. Recurrent Time Interval . . . . . . . . . . . . . . . . . 5 3.3. Changes to Time Interval . . . . . . . . . . . . . . . . . 5 4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 6 5. Reference Models . . . . . . . . . . . . . . . . . . . . . . . 7 5.1. Building Blocks . . . . . . . . . . . . . . . . . . . . . 7 5.1.1. Temporal TED . . . . . . . . . . . . . . . . . . . . . 7 5.1.2. Temporal CSPF . . . . . . . . . . . . . . . . . . . . 8 5.1.3. Temporal Label Database . . . . . . . . . . . . . . . 9 5.1.4. Temporal LSP Tunnel Manager . . . . . . . . . . . . . 9 5.1.5. Temporal LSP Database . . . . . . . . . . . . . . . . 10 5.1.6. Temporal PCE . . . . . . . . . . . . . . . . . . . . . 10 5.2. Centralized Model . . . . . . . . . . . . . . . . . . . . 11 5.2.1. Centralized Model for Single Domain . . . . . . . . . 11 5.2.2. Centralized Model for Multiple Domains . . . . . . . . 14 5.2.3. Analysis on Centralized Model . . . . . . . . . . . . 15 5.3. Hybrid Model . . . . . . . . . . . . . . . . . . . . . . . 15 5.3.1. Hybrid Model for Single Domain . . . . . . . . . . . . 15 5.3.2. Hybrid Model for Multiple Domains . . . . . . . . . . 18 5.3.3. Temporal Stateful PCE . . . . . . . . . . . . . . . . 19 5.3.4. Analysis on Hybrid Model . . . . . . . . . . . . . . . 20 5.4. Distributed Model . . . . . . . . . . . . . . . . . . . . 21 5.4.1. Router Distributed Model . . . . . . . . . . . . . . . 21 5.4.2. Analysis on Distributed Model . . . . . . . . . . . . 22 6. Security Considerations . . . . . . . . . . . . . . . . . . . 23 7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 23 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 8.1. Normative References . . . . . . . . . . . . . . . . . . . 23 8.2. Informative References . . . . . . . . . . . . . . . . . . 24 Chen, et al. Expires September 22, 2016 [Page 2] Internet-Draft Framework for TTS March 2016 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 Chen, et al. Expires September 22, 2016 [Page 3] Internet-Draft Framework for TTS March 2016 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 to consume the reserved network resources for it forever even though the LSP may only use the network resources during some period of time. As a result, the entire 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/intervals. Temporal LSP tunnel services (TTS) provides an easy way for us to book temporal LSP tunnels in advance. More importantly, a temporal LSP is an LSP with one or more time intervals/periods and it is assumed to consume the resources and carry traffic only in these time intervals. Thus the entire network resources are efficiently used. Moreover, some new services can be provided easily. For example, a user can book a tunnel service in advance for a given time interval or a sequence of given time intervals. Tunnel services may be easily scheduled. This document specifies a framework for temporal LSP tunnel services and provides a few of reference models along with logical components required to design a solution for TTS. 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-multipoint) LSP. LSP with a time interval: LSP that carries traffic in the time interval. LSP with a sequence of time intervals: LSP that carries traffic in each of the time intervals. Temporal LSP: LSP with a time interval or LSP with a sequence of time intervals. TED: Traffic Engineering Database. CSPF: Constrained Shortest Path First. LER: Label Edge Router. Chen, et al. Expires September 22, 2016 [Page 4] Internet-Draft Framework for TTS March 2016 PCE: Path Computation Element. PCEP: Path Computation Element Communication Protocol. 3. Operations Overview This section briefly describes some operations on a temporal LSP. 3.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. 3.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. 3.3. 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. Chen, et al. Expires September 22, 2016 [Page 5] Internet-Draft Framework for TTS March 2016 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 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. Problem Statement Assume that a set of temporal LSPs have been set up in a network. In other words, the network resources have been reserved in advance for the LSPs in the set. For every LSP configured with a number of time intervals, the network resources have been reserved in advance for each of these time intervals. Initially, there is no LSP set up in the network. For the given state of the network, how to handle/satisfy a set of service requests containing set up a number of temporal LSPs, delete a number of temporal LSPs and update a number of temporal LSPs? Chen, et al. Expires September 22, 2016 [Page 6] Internet-Draft Framework for TTS March 2016 More specifically, based on the current network state, how to compute paths for the temporal LSPs to be set up? how to reserve the network resources in advance along the paths computed for the time intervals configured for the LSPs? how to release the network resources reserved in advance for the LSPs to be deleted and update the network state accordingly? how to change the parameters for the LSPs configured with time intervals and update the network state accordingly? The reference models described in the following section can provide solutions for this. 5. Reference Models This section presents a few of reference models for providing temporal tunnel services (TTS) after introducing some of building blocks. For each of the models, its advantages and disadvantages are listed. 5.1. Building Blocks This section briefly describes some of the components that may be used to build a solution for creating and maintaining temporal LSP tunnels. 5.1.1. Temporal TED The Traffic Engineering (TE) information in a normal TE Database (TED) represents a unreserved bandwidth Bi at each of eight priority levels for a link at one point of time, i.e., at the current time. 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 TED and the bandwidth cannot be reserved in advance for the LSP in the time interval given. Chen, et al. Expires September 22, 2016 [Page 7] Internet-Draft Framework for TTS March 2016 The TED needs to be enhanced for supporting temporal LSPs. The enhanced TED is called Temporal TED (T-TED for short). It maintains the TE information such as bandwidth for every link with a series of time intervals. For example, 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], .... Bandwidth ^ | B3 | B1 ___________ | __________ |B0 B4 |__________ B2 _________ | ________________ | -+-------------------------------------------------------> Time |T0 T1 T2 T3 T4 The unreserved bandwidth information above for the link will be stored in the T-TED. 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 time 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 time interval/period. 5.1.2. Temporal CSPF An existing constrained shortest path first (CSPF) (or say a normal CSPF) computes a path for a normal LSP that satisfies a set of given constraints using a traffic engineering database (TED). A temporal CSPF (T-CSPF for short) computes a path for a temporal LSP (i.e., an LSP with a number of time intervals) that satisfies a set Chen, et al. Expires September 22, 2016 [Page 8] Internet-Draft Framework for TTS March 2016 of given constraints in each of the time intervals through using a temporal TED (T-TED). 5.1.3. Temporal Label Database In a centralized controller, a normal label database (LDB) records and maintains the status of every label for every node (and/or interface) in a network, which the controller controls. The status of a label indicates whether the label is assigned to an LSP. A temporal label database (T-LDB) in a centralized controller records and maintains the status of every label in a series of time intervals for every node (and/or interface) in a network, on which the controller controls. The status of a label in a time interval indicates whether the label is assigned to an LSP in the time interval. If there are enough labels anytime, we do not need any temporal label database and we can just use a normal label database. For example, if we can make sure that at any time the number of LSPs going through any node in the network is less than the number of labels on the node, then there are enough labels anytime. Thus, we can just use a normal label database. 5.1.4. Temporal LSP Tunnel Manager An existing LSP tunnel manager (or say a normal LSP tunnel manager) receives a request for an operation on an MPLS TE LSP from a user or an application. The operation may be a creation of a new MPLS TE LSP tunnel, a deletion of an existing MPLS TE LSP tunnel, or a change to an existing LSP tunnel. A temporal LSP tunnel manager (T-LSP Manager for short) receives a request for an operation on a temporal LSP from a user or an application. The operation may be a creation of a new temporal LSP tunnel, a deletion of an existing temporal LSP tunnel, or a change to an existing temporal LSP tunnel. When receiving a request for creating a new temporal LSP (i.e., an LSP with a sequence of time intervals), the T-LSP manager asks the T-CSPF to compute a path for the LSP that satisfies the constraints given for the LSP in each of the time intervals. After obtaining the path for the LSP from the T-CSPF, the T-LSP manager requests the T-LDB to assign labels along the path for the LSP and asks the T-TED to reserve the resources such as link bandwidth along the path for the LSP in each of the time intervals if it is used in a centralized controller. Chen, et al. Expires September 22, 2016 [Page 9] Internet-Draft Framework for TTS March 2016 The T-LSP manager in a centralized controller really sets up the LSP along the path in the network by writing a forwarding entry on every node along the path through the API to the network in each of the time intervals. The T-LSP manager in a distributed environment initiates the RSVP signaling to set up the LSP along the path. The T-LSP manager records the related information for the LSP into the temporal LSP database (T-LSPDB). The information includes the time intervals for the LSP, the path computed for the LSP, the resources such as bandwidth reserved along the path in each of the time intervals for the LSP (for centralized controller), the labels assigned along the path for the LSP (for centralized controller), and the status of the LSP. 5.1.5. Temporal LSP Database A temporal LSP database (T-LSPDB for short) in a centralized controller stores the related information for every temporal LSP. For each LSP, the following information will be stored in the T-LSPDB: o the time intervals for the LSP, o the paths computed for the LSP, o the resources such as bandwidth reserved along the path in each of the time intervals for the LSP, o the labels assigned along the path for the LSP, and o the status of the LSP. In a distributed environment, a T-LSPDB on a label edge router (LER) stores the following information for every temporal LSP originating from the LER (i.e., the LER is the ingress of the LSP): o the time intervals for the LSP, o the paths computed for the LSP, and o the status of the LSP. 5.1.6. Temporal PCE A temporal PCE (T-PCE for short) is an enhanced version of the existing PCE. It receives a request for computing a path for a temporal LSP crossing multiple domains, computes the path for the LSP and replies to the request with the path computed. For the LSP with Chen, et al. Expires September 22, 2016 [Page 10] Internet-Draft Framework for TTS March 2016 a number of time intervals and some constraints, the path computed satisfies the constraints in each of the time intervals. 5.2. Centralized Model This section presents two centralized reference models. one model is for a single domain, the other for multiple domains. 5.2.1. Centralized Model for Single Domain Figure below illustrates a centralized SDN controller reference model for temporal LSP tunnel services for a network (i.e., a single domain). +--------------------------------------------+ | TS-SDN Controller | | +---------------+ | | /------------| T-LSP Manager | | | / Ia +---------------+ | | +--------+ | | | \ | | | T-CSPF | ________| | | \Id | | +--------+ / Ib /Ic | +---------+ | | \Ie / / | | T-LSPDB | | | +---------+ +-------+ | +---------+ | | | T-TED | | T-LDB | | | | +---------+ +-------+ | | | \ \ |In | +---------------API to Network(PCEP+)--------+ / \ / \____ / \ \____ /\ .---. .---+ \ | \( ' |'.---. | |---\ Network | '+. (o \ | | ) ( | | o) ( | | ) ( o o .-' ' ) '---._.-. ) '---' The temporal SDN (TS-SDN) controller in the reference model controls a network through an API to the network such as PCEP+ (extensions to PCEP for central controller). The TS-SDN controller is responsible for creating and maintaining every temporal LSP in the network. Chen, et al. Expires September 22, 2016 [Page 11] Internet-Draft Framework for TTS March 2016 The TS-SDN controller comprises a number of modules, including a T-LSP manager, a T-CSPF, a T-TED, a T-LDB and a T-LSPDB. The interfaces among these modules are listed as follows: o Interface Ia between the T-LSP manager and the T-CSPF. Through this interface, the T-LSP manager requests the T-CSPF to compute a path for a temporal LSP with a number of time intervals and a set of constraints, and the T-CSPF responses the T-LSP manager with the path computed that satisfies the constraints in each of the time intervals. o Interface Ib between the T-LSP manager and the T-TED. When a temporal LSP with a number of time intervals is to be created, through this interface, the T-LSP manager reserves in the T-TED the TE resources such as link bandwidths on every link in each of the time intervals along the path computed for the LSP. When a temporal LSP with a number of time intervals is deleted, the T-LSP manager releases the TE resources such as link bandwidths on every link in each of the time intervals along the path for the LSP. o Interface Ic between the T-LSP manager and the T-LDB. When a temporal LSP with a number of time intervals is to be created, through this interface, the T-LSP manager reserves in the T-LDB a label for every link in each of the time intervals along the path computed for the LSP. When a temporal LSP with a number of time intervals is deleted, the T-LSP manager releases the label for every link in each of the time intervals along the path for the LSP. o Interface Id between the T-LSP manager and the T-LSPDB. the T-LSP manager updates the information for every LSP in the T-LSPDB through this interface. o Interface Ie between the T-CSPF and the T-TED. Through this interface, the T-CSPF accesses the traffic engineering information such as link bandwidths when it computes a path for a temporal LSP with a number of time intervals. There is an interface In between the TS-SDN controller and the network. In fact, there is a control channel (or interface) between the TS-SDN controller and every node in the network. Initially, the T-TED obtains the original traffic engineering (TE) information such as link bandwidths from the network through the interface In (i.e., API to network) for every link in the network. The T-LDB gets the original label resources from the network through the interface In for every node and link in the network. Chen, et al. Expires September 22, 2016 [Page 12] Internet-Draft Framework for TTS March 2016 Then the TE information in the T-TED is updated mostly by the following events. o When a temporal LSP with a number of time intervals is to be created, the T-LSP manager reserves in the T-TED bandwidths on every link in each of the time intervals along the path for the LSP. o When a temporal LSP with a number of time intervals is deleted, the T-LSP manager releases bandwidths on every link in each of the time intervals along the path for the LSP. o When a link in the network is down, the TE information about the link is removed from the T-TED. o When a link in the network is up, the TE information about the link is added into the T-TED. The label resources in the T-LDB may be updated as follows: o When a temporal LSP with a number of time intervals is to be created, the T-LSP manager reserves in the T-LDB a label for every link in each of the time intervals along the path for the LSP. For a node specific label space, a label on the downstream node is assigned for the link. For a link specific label space, a label on the link is assigned for the link. o When a temporal LSP with a number of time intervals is deleted, the T-LSP manager releases the label for every link in each of the time intervals along the path for the LSP. o When a node in the network is down, the label resources on the node is removed from the T-LDB if a node specific label space is used. When a link in the network is down, the label resources on the link is removed from the T-LDB if a link specific label space is used. o When a node in the network is up, the label resources on the node is added into the T-LDB if a node specific label space is used. When a link in the network is up, the label resources on the link is added into the T-LDB if a link specific label space is used. There are a couple of ways in which the TS-SDN controller sets up a temporal LSP with a number of time intervals in the network. One way is to set up the LSP in the network along the path computed for the LSP at the start of each time interval and to delete the LSP at the end of each time interval. Chen, et al. Expires September 22, 2016 [Page 13] Internet-Draft Framework for TTS March 2016 Another way is to set up the LSP in the network along the path computed for the LSP before or at the start of the first time interval, to update the parameters such as bandwidth for each time interval, and to delete the LSP at the end of last time interval. 5.2.2. Centralized Model for Multiple Domains The centralized model described in the previous section is for temporal LSPs within a single domain, which is called single-domain centralized model. It can be easily extended to support temporal LSPs crossing multiple domains. The extended model is called multi- domain centralized model. Basically, through replacing the T-CSPF module with a T-PCE module in the single-domain centralized model, we obtain a multi-domain centralized model. Figure below illustrates a centralized SDN controller reference model for temporal LSPs crossing multiple domains. +--------------------------------------------+ | TS-SDN Controller | | +---------------+ | | /------------| T-LSP Manager | | | / Ia +---------------+ | Im | +--------+ | | | \ | ----+-+ T-PCE | ________| | | \Id | | +--------+ / Ib /Ic | +---------+ | | \Ie / / | | T-LSPDB | | | +---------+ +-------+ | +---------+ | | | T-TED | | T-LDB | | | | +---------+ +-------+ | | | \ \ |In | +---------------API to Network(PCEP+)--------+ / \ / \____ / \ \____ /\ .---. .---+ \ | \( ' |'.---. | |---\ Network | '+. (o \ | | ) ( | | o) ( | | ) ( o o .-' ' ) '---._.-. ) '---' The T-PCE may be outside of the TS-SDN controller. When receiving a Chen, et al. Expires September 22, 2016 [Page 14] Internet-Draft Framework for TTS March 2016 request for creating a new temporal LSP with a number of time intervals and some constraints, the TS-SDN controller (or say the T-LSP manager) asks the T-PCE to compute a path for the LSP. For computing a path for a temporal LSP crossing multiple domains, the T-PCE communicates with other T-PCEs through interface Im to get an end to end path for the LSP crossing domains. For computing a path for a temporal LSP within the network (one domain), the T-PCE uses a T-CSPF inside it to obtain a path for the LSP. 5.2.3. Analysis on Centralized Model In a centralized model, all the network resources are managed and maintained by a central controller. Thus it has the following advantages: o Efficiently use network resources for providing TTS (i.e., finding paths for LSPs with time intervals, reserving the network resources in these intervals and setting up LSPs in the network). o Optimal paths for the LSPs with time intervals. A centralized model may have the following disadvantages or issues: o Scalability issues since all the work is done in the controller, which include computing all the paths for the LSPs with time intervals, managing all the network resources, controlling the network and so on. o Reliability issues since the failure of the controller will lead to the failure of the whole system. 5.3. Hybrid Model This section presents a couple of hybrid reference models. one model is for a single domain, the other for multiple domains. 5.3.1. Hybrid Model for Single Domain Figure below illustrates a hybrid SDN controller reference model for temporal LSP tunnel services within a single domain. Chen, et al. Expires September 22, 2016 [Page 15] Internet-Draft Framework for TTS March 2016 +--------------------------------------------+ | TS-SDN Controller | | +---------------+ | | /------------| T-LSP Manager | | | / Ia +---------------+ | | +--------+ | | \ | | | T-CSPF | ________| | \Id | | +--------+ / Ib | +---------+ | | \Ie / | | T-LSPDB | | | +---------+ | +---------+ | | | T-TED | | | | +---------+ | | | \ |In | +----------------API to Network(PCEP)--------+ / \ / \____ / \____ / .---. .---, \ | ( ' '.---. | |---' Network '+. (o | ) ( o) ( ) ( o o .-' ' ) '---._.-. ) '---' The temporal SDN (TS-SDN) controller in this hybrid reference model manages some parts of the resources in the network it controls. For example, it may just manage the link bandwidth for every link in the network. The label resources in the network is not managed by the TS-SDN controller. It may still be managed by each node in the network. The TS-SDN controller controls the network through an API to the network such as PCEP. There is a control channel between the TS-SDN controller and each of the LERs in the network. The TS-SDN controller is responsible for creating and maintaining every temporal LSP in the network through the control channel to the ingress node of the LSP. The TS-SDN controller comprises a T-LSP manager, a T-CSPF, a T-TED and a T-LSPDB. The interfaces among these modules are listed as follows: Chen, et al. Expires September 22, 2016 [Page 16] Internet-Draft Framework for TTS March 2016 o Interface Ia between the T-LSP manager and the T-CSPF. This interface is the same as the one between the T-LSP manager and the T-CSPF in the centralized model. o Interface Ib between the T-LSP manager and the T-TED. This interface is the same as the one between the T-LSP manager and the T-TED in the centralized model. o Interface Id between the T-LSP manager and the T-LSPDB. This interface is similar to the one between the T-LSP manager and the T-LSPDB in the centralized model. Most of the information for a temporal LSP stored in the T-LSPDB in the hybrid model is the same as that stored in the T-LSPDB in the centralized model. For example, the time intervals associated with the LSP and the link bandwidths reserved for the LSP in each of the time intervals are the same in both models. The labels assigned to the LSP is stored in the T-LSPDB in the centralized model, but there is not any label information for the LSP stored in the T-LSPDB in the hybrid model. o Interface Ie between the T-CSPF and the T-TED. This interface is the same as the one between the T-CSPF and the T-TED in the centralized model. The TE information in the T-TED in the hybrid model is updated in the same way as that in the T-TED in the centralized model. But the way in which the T-TED in one model obtains the original TE information from the network may be different from the one in another model. For example, the T-TED in the centralized model may obtain the original TE information from the network through polling every node in the network. The T-TED in the hybrid model may get the original TE information from the network through an OSPF or ISIS adjacency between the TS-SDN controller and one of the nodes in the network. There are a few of ways in which the TS-SDN controller sets up a temporal LSP with a number of time intervals in the network. One way is that the TS-SDN controller asks the ingress of the LSP to signal the LSP in the network along the path computed for the LSP at the start of each time interval and to tear down the LSP at the end of each time interval. Another way is that the TS-SDN controller asks the ingress of the LSP to signal the LSP in the network along the path computed for the LSP before or at the start of the first time interval, to update the parameters such as bandwidth for each time interval, and to tear down the LSP at the end of the last time interval. Chen, et al. Expires September 22, 2016 [Page 17] Internet-Draft Framework for TTS March 2016 The third way is that the TS-SDN controller asks the ingress of the LSP to signal the LSP in the network along the path computed for the LSP before or at the start of the first time interval, to reserve bandwidth for each time interval, and to tear down the LSP at the end of the last time interval. 5.3.2. Hybrid Model for Multiple Domains The hybrid model described in the previous section is for temporal LSPs within a single domain, which is called single-domain hybrid model. It can be easily extended to support temporal LSPs crossing multiple domains. The extended model is called multi-domain hybrid model. Basically, through replacing the T-CSPF module with a T-PCE module in the single-domain hybrid model, we obtain a multi-domain hybrid model. Figure below illustrates a hybrid SDN controller reference model for temporal LSPs crossing multiple domains. +--------------------------------------------+ | TS-SDN Controller | | +---------------+ | | /------------| T-LSP Manager | | | / Ia +---------------+ | Im | +--------+ | | \ | ----+-+ T-PCE | ________| | \Id | | +--------+ / Ib | +---------+ | | \Ie / | | T-LSPDB | | | +---------+ | +---------+ | | | T-TED | | | | +---------+ | | | \ |In | +----------------API to Network(PCEP)--------+ / \ / \____ / \____ / .---. .---, \ | ( ' '.---. | |---' Network '+. (o | ) ( o) ( ) ( o o .-' ' ) '---._.-. ) '---' Chen, et al. Expires September 22, 2016 [Page 18] Internet-Draft Framework for TTS March 2016 The T-PCE may be outside of the TS-SDN controller. When receiving a request for creating a new temporal LSP with a number of time intervals and some constraints, the TS-SDN controller (or say the T-LSP manager) asks the T-PCE to compute a path for the LSP. For computing a path for a temporal LSP crossing multiple domains, the T-PCE communicates with other T-PCEs through interface Im to get an end to end path for the LSP crossing domains. For computing a path for a temporal LSP within the network (one domain), the T-PCE uses a T-CSPF inside it to obtain a path for the LSP. 5.3.3. Temporal Stateful PCE From the multi-domain hybrid model described in the previous section, we can get a temporal stateful PCE (controller) if we uses the stateful PCEP as the interface between the temporal stateful PCE (TS- Stateful-PCE for short) controller and the network on which the PCE controls. Figure below illustrates a temporal stateful PCE controller reference model. +--------------------------------------------+ | TS-Stateful-PCE (Controller) | | +---------------+ | | /------------| T-LSP Manager | | | / Ia +---------------+ | Im | +--------+ | \ | ----+-+ T-PCE | ________| \Id | | +--------+ / Ib +---------+ | | \Ie / | T-LSPDB | | | +---------+ +---------+ | | | T-TED | | | +---------+ | | \ | +---------------- Stateful PCEP -------------+ / \ / \____ / \____ / .---. .---, \ | ( ' '.---. | |---' Network '+. (o | ) ( o) ( ) ( o o .-' ' ) '---._.-. ) Chen, et al. Expires September 22, 2016 [Page 19] Internet-Draft Framework for TTS March 2016 '---' The T-PCE may be outside of the TS-Stateful PCE controller. When receiving a request for creating a new temporal LSP with a number of time intervals and some constraints, the TS-Stateful PCE (controller) asks the T-PCE to compute a path for the LSP. For computing a path for a temporal LSP crossing multiple domains, the T-PCE communicates with other T-PCEs through interface Im to get an end to end path for the LSP crossing domains. For computing a path for a temporal LSP within the network (one domain), the T-PCE uses a T-CSPF inside it to obtain a path for the LSP. After obtaining the path for the LSP, the TS-Statefule PCE (controller) reserves in the T-TED the TE resources such as link bandwidths for the LSP along the path in each of the time intervals, updates in the T-LSPDB the information about the LSP, initiates the creation of the LSP at the start of each time interval through sending a Path Computation LSP Initiate Request (PCInitiate) message to the ingress of the LSP, and deletes the LSP at the end of each time interval through sending another PCInitiate message with R (remove) flag set to 1. The TS-Statefule PCE (controller) updates the information about the LSP in the T-LSPDB accordingly after receiving a Path Computation LSP State Report (PCRpt) message from the ingress of the LSP. 5.3.4. Analysis on Hybrid Model In a hybrid model, some of the network resources are managed and maintained by a central controller. Thus it has the following advantages: o Efficiently use network resources for providing TTS (i.e., finding paths for LSPs with time intervals, reserving the network resources in these intervals and setting up LSPs in the network). o Optimal paths for the LSPs with time intervals. A hybrid model may have the following disadvantages or issues: o Reliability issues since the failure of the controller will lead to the failure of the whole system. Chen, et al. Expires September 22, 2016 [Page 20] Internet-Draft Framework for TTS March 2016 5.4. Distributed Model 5.4.1. Router Distributed Model Figure below illustrates a traditional/router distributed reference model for temporal LSP tunnel services. +----------------------------------------------------+ | Router | | +-----------+ +-------------------------------+ | | | T-OSPF | | TS-MPLS | | In | |(ISIS) | | Ia +---------------+ | | ---+--+ | | /----+ T-LSP Manager | | | | | | | / +----+-----+----+ | | | | | | +----+---+ | | | | | +-----+-----+ | | T-CSPF | __|Ir |Id | | | | | +----+---+ / +---+----+ | | | |Ig | | / |T-LSPDB | | | | |_ | Ie/ / +--------+ | | | \ | / +----+-----+ | | In | \ | / |T-RSVP-TE +------------+--+---- | \ | / +----------+ | | | \ +-+-----------------------------+ | | \ / | | +---+-+---+ | | | T-TED | | | +---------+ | +----------------------------------------------------+ In an existing distributed network, the existing MPLS and OSPF/ISIS running on every node in the network need to be enhanced to support temporal LSP tunnel services. The enhanced OSPF is represented by T-OSPF in the distributed model. The T-OSPF running on a router distributes the traffic engineering (TE) information such as bandwidth about every link connected to the router in a series of time intervals. It also receives the TE information about a link in a number of time intervals from a router in the network. It updates the TE information about every link in the network in the T-TED. The T-OSPF distributes and receives the TE information about a link through interface In connecting to another router. The T-TED stores the TE information about every link in the network. It is updated by the T-OSPF through interface Ig when the T-OSPF receives the TE information about a link that is changed or the TE information about a link connected to the router is changed. Chen, et al. Expires September 22, 2016 [Page 21] Internet-Draft Framework for TTS March 2016 The T-CSPF in the distributed model has the same function as the one in the other two models. It computes a path for a temporal LSP using the T-TED. It accesses the T-TED through interface Ie. The enhanced RSVP-TE for supporting temporal LSP tunnel services is represented by T-RSVP-TE. The T-RSVP-TE running on every node along the path for a temporal LSP signals and maintains the LSP with time intervals. The signaling messages for the LSP is sent and received through interface In connecting to another router. The T-LSP manager on an LER receives a request to create, delete or update a temporal LSP with a number of time intervals. When receiving a request for creating a new temporal LSP with a sequence of time intervals and constraints, the T-LSP manager asks the T-CSPF to compute a path for the LSP that satisfies the constraints for the LSP in each of the time intervals. After obtaining the path for the LSP from the T-CSPF, the T-LSP manager requests T-RSVP-TE to signal the LSP along the path with the time intervals. The T-LSP manager records the related information for the LSP into the temporal LSP database (T-LSPDB). The information includes the time intervals for the LSP, the path computed for the LSP, and the status of the LSP. 5.4.2. Analysis on Distributed Model In a distributed model, the network resources are managed and maintained by multiple routers. Thus it has the following advantages: o More reliable. When one router fails, the system continues working. o More scalable for path computations since the path computation load is distributed among the multiple routers. A distributed model may have the following disadvantages or issues: o Sub-optimal paths for the LSPs with time intervals since a controller or router may not have the latest accurate information about the network resources. Chen, et al. Expires September 22, 2016 [Page 22] Internet-Draft Framework for TTS March 2016 o Network resources may not be used efficiently. o Scalability issues for the distribution of link bandwidth with time intervals by IGP in the network, which may consume lots of network resources such as memory and link bandwidth. 6. Security Considerations The mechanism described in this document does not raise any new security issues. 7. Acknowledgement The authors would like to thank every one who gives his valuable comments on this draft. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ RFC2119, March 1997, . [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, . [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, DOI 10.17487/ RFC3031, January 2001, . [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, DOI 10.17487/RFC5440, March 2009, . [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, DOI 10.17487/ RFC2328, April 1998, . [RFC5250] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The Chen, et al. Expires September 22, 2016 [Page 23] Internet-Draft Framework for TTS March 2016 OSPF Opaque LSA Option", RFC 5250, DOI 10.17487/RFC5250, July 2008, . [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, DOI 10.17487/RFC3630, September 2003, . [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. 8.2. Informative References [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, DOI 10.17487/ RFC4655, 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, DOI 10.17487/ RFC5862, June 2010, . [RFC6006] Zhao, Q., Ed., King, D., Ed., 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, DOI 10.17487/RFC6006, September 2010, . [RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S. Yasukawa, Ed., "Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to- Multipoint TE Label Switched Paths (LSPs)", RFC 4875, DOI 10.17487/RFC4875, May 2007, . Chen, et al. Expires September 22, 2016 [Page 24] Internet-Draft Framework for TTS March 2016 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 Lei Liu Fujitsu USA Email: lliu@us.fujitsu.com Khuzema Pithewan Infinera Email: kpithewan@infinera.com Chen, et al. Expires September 22, 2016 [Page 25]