[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

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,
              <http://www.rfc-editor.org/info/rfc2119>.

   [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,
              <http://www.rfc-editor.org/info/rfc3209>.

   [RFC3031]  Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
              Label Switching Architecture", RFC 3031, DOI 10.17487/
              RFC3031, January 2001,
              <http://www.rfc-editor.org/info/rfc3031>.

   [RFC5440]  Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
              Element (PCE) Communication Protocol (PCEP)", RFC 5440,
              DOI 10.17487/RFC5440, March 2009,
              <http://www.rfc-editor.org/info/rfc5440>.

   [RFC2328]  Moy, J., "OSPF Version 2", STD 54, RFC 2328, DOI 10.17487/
              RFC2328, April 1998,
              <http://www.rfc-editor.org/info/rfc2328>.

   [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, <http://www.rfc-editor.org/info/rfc5250>.

   [RFC3630]  Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
              (TE) Extensions to OSPF Version 2", RFC 3630,
              DOI 10.17487/RFC3630, September 2003,
              <http://www.rfc-editor.org/info/rfc3630>.

   [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,
              <http://www.rfc-editor.org/info/rfc4655>.

   [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,
              <http://www.rfc-editor.org/info/rfc5862>.

   [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,
              <http://www.rfc-editor.org/info/rfc6006>.

   [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,
              <http://www.rfc-editor.org/info/rfc4875>.





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]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/