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

Versions: 00 01 02

Internet Engineering Task Force                                  H. Chen
Internet-Draft                                       Huawei Technologies
Intended status: Standards Track                                  M. Toy
Expires: January 21, 2018                                        Verizon
                                                                  V. Liu
                                                            China Mobile
                                                                  L. Liu
                                                                 Fijitsu
                                                           July 20, 2017


                  Extensions to MPLS for Temporal LSP
                    draft-chen-teas-rsvp-tts-02.txt

Abstract

   This document specifies extensions to RSVP-TE for creating and
   maintaining a Traffic Engineering (TE) Label Switched Path (LSP) in a
   time interval or a sequence of time intervals.

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 January 21, 2018.

Copyright Notice

   Copyright (c) 2017 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



Chen, et al.            Expires January 21, 2018                [Page 1]


Internet-Draft              MPLS Temporal LSP                  July 2017


   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 . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Conventions Used in This Document  . . . . . . . . . . . . . .  3
   4.  Temporal LSP Overview  . . . . . . . . . . . . . . . . . . . .  4
     4.1.  Architecture Overview  . . . . . . . . . . . . . . . . . .  4
     4.2.  Operations Overview  . . . . . . . . . . . . . . . . . . .  4
   5.  TIME INTERVAL Object . . . . . . . . . . . . . . . . . . . . .  5
     5.1.  Absolute TIME INTERVAL Object  . . . . . . . . . . . . . .  5
     5.2.  Relative TIME INTERVAL Object  . . . . . . . . . . . . . .  6
     5.3.  Recurrent Absolute TIME INTERVAL Object  . . . . . . . . .  7
     5.4.  Recurrent Relative TIME INTERVAL Object  . . . . . . . . .  8
   6.  Path Message . . . . . . . . . . . . . . . . . . . . . . . . .  9
   7.  Behaviors for Temporal LSP . . . . . . . . . . . . . . . . . . 10
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
   10. Acknowledgement  . . . . . . . . . . . . . . . . . . . . . . . 10
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 10
     11.2. Informative References . . . . . . . . . . . . . . . . . . 11
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
























Chen, et al.            Expires January 21, 2018                [Page 2]


Internet-Draft              MPLS Temporal LSP                  July 2017


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 that the LSP consumes its reserved
   network resources forever even though the LSP may only use network
   resources during some period of time.  As a result, the network
   resources are not used efficiently.  Moreover, a tunnel service can
   not be reserved or booked in advance in a period of time.

   This document specifies extensions to RSVP-TE for creating and
   maintaining an MPLS TE LSP in a period of time called a time interval
   or a sequence of time intervals.  It is assumed that the LSP carries
   traffic during this time interval or each of these time intervals.
   Thus the network resources are efficiently used.  More importantly,
   some new services can be provided.  For example, a consumer can book
   a tunnel service in advance for a given time interval.  Tunnel
   services may be scheduled as requested.


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-multipoiint) LSP.

   LSP in a time interval: LSP that carries traffic in the time
   interval.

   LSP in a sequence of time intervals: LSP that carries traffic in each
   of the time intervals.

   Temporal LSP: LSP in a time interval or LSP in a sequence of time
   intervals.

   TEDB: Traffic Engineering Database.

   This document uses terminologies defined in RFC3209 and RFC4875.


3.  Conventions Used in This Document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC2119.




Chen, et al.            Expires January 21, 2018                [Page 3]


Internet-Draft              MPLS Temporal LSP                  July 2017


4.  Temporal LSP Overview

   This section briefs the architecture for supporting temporal LSPs and
   some operations on temporal LSPs.

4.1.  Architecture Overview

   Based on the existing architecture for supporting TE LSPs, we can
   extend a few of components to support temporal LSPs.  These
   components include OSPF, CSPF and RSVP-TE.

   OSPF is extended to distribute and maintain TE inforamtion for a link
   in a sequence of time intervals.  CSPF is extended to compute a path
   for a temporal LSP based on the TEDB containing TE information for
   every link in a sequence of time intervals.  RSVP-TE is extended to
   create a temporal LSP and maintain the status of the temporal LSP.

4.2.  Operations Overview

   On the ingress of a temporal LSP, a user configures it with a time
   interval or a sequence of time intervals.  A simple time interval is
   a time interval from start time Ta to end 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
   Ta to Tb.

   For time interval from start time Ta to infinite as end time, it may
   be represented as [Ta, INFINITE].

   In addition to simple time intervals, there are recurrent time
   intervals and elastic time intervals.

   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).

   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", a path



Chen, et al.            Expires January 21, 2018                [Page 4]


Internet-Draft              MPLS Temporal LSP                  July 2017


   satisfying the constraints for the LSP in each of the simple time
   intervals (such as 11 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.

   An elastic time interval represents a time period with an elastic
   range.  It has a simple time interval such as [Ta, Tb] with an
   elastic range such as within -P and Q.

   Elastic time interval "[Ta, Tb] within -P and Q" means a time period
   from (Ta+X) to (Tb+X), where -P <= X <= Q, P and Q is an amount of
   time such as 600 seconds.

   When an LSP is configured with an elastic time interval such as "[Ta,
   Tb] within -P and Q", a path is computed such that the path satisfies
   the constraints for the LSP in the time period from (Ta+X) to (Tb+X)
   and |X| is the minimum value from -P to Q. That is that [Ta+X, Tb+X]
   is the time interval closest to [Ta, Tb] within the elastic range.
   The LSP along the path is set up to carry traffic in the time period
   from (Ta+X) to (Tb+X).


5.  TIME INTERVAL Object

   This section presents a few of TIME-INTERVAL objects, which are the
   internal representations of time intervals.  A Class-Num for the
   objects is TBD, which is to be assigned by IANA.

5.1.  Absolute TIME INTERVAL Object

   The format of an absolute TIME-INTERVAL object body is illustrated
   below.

        Class-Name: TIME-INTERVAL,   Class-Num: TBD,   C-Type = 1
      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                          Start-time                           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                           End-time                            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     o Start-time: The time LSP starts to carry traffic
     o End-time:   The time LSP ends carrying traffic


   An absolute TIME-INTERVAL object contains a Start-time and an End-
   time, representing time interval [Start-time, End-time].  All bits in



Chen, et al.            Expires January 21, 2018                [Page 5]


Internet-Draft              MPLS Temporal LSP                  July 2017


   End-time field set to one represents INFINITE.  Both of these two
   times are the times that are synchronized among all network nodes.

   Thus the clocks on all the nodes MUST be synchronized if an absolute
   TIME-INTERVAL object is used.  The time period represented in an
   absolute TIME-INTERVAL object is more accurate.

5.2.  Relative TIME INTERVAL Object

   The format of a relative TIME-INTERVAL object body is shown below.

        Class-Name: TIME-INTERVAL,   Class-Num: TBD,   C-Type = 2
      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                        Start-time-length                      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                         End-time-length                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     o Start-time-length: The time length in seconds from current time
                          to the time LSP starts to carry traffic
     o End-time-length:   The time length in seconds from current time
                          to the time LSP ends carrying traffic


   A relative TIME-INTERVAL object contains a Start-time-length and an
   End-time-length, which represents time interval below:

    [current-time + Start-time-length, current-time + End-time-length]


   where current-time is the current local time on a node.  All bits in
   End-time-length field set to one represents INFINITE.

   When a time interval from time Ta to time Tb is configured on a node,
   these two time lengths are the time lengths that are computed on the
   node using the current local time as follows.

     Start-time-length = Ta - current-time;
     End-time-length   = Tb - current-time;


   For a relative TIME-INTERVAL object, the clocks/times on all the
   nodes can be different.






Chen, et al.            Expires January 21, 2018                [Page 6]


Internet-Draft              MPLS Temporal LSP                  July 2017


5.3.  Recurrent Absolute TIME INTERVAL Object

   For a recurrent absolute TIME-INTERVAL object, its body contains a
   Start-time, an End-time, a Repeat-time-length, a Options field and a
   Number-repeats field.  The format of its body is illustrated below:

   The Start-time and End-time represents time interval [Start-time,
   End-time].  The Repeat-time-length represents a repeat cycle/time,
   which is valid if the Options field is set to indicate the way to
   repeat is "repeat every Repeat-time-length".  The Options field
   indicates a way to repeat.  The Number-repeats indicates the number
   of repeats of time interval [Start-time, End-time].

        Class-Name: TIME-INTERVAL,   Class-Num: TBD,   C-Type = 3
      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                          Start-time                           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                           End-time                            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                      Repeat-time-length                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Options |         Number-repeats          |    Reserved(0)    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Start-time:   The time LSP starts to carry traffic.

   End-time:   The time LSP ends carrying traffic.

   Repeat-time-length:   The time length in seconds after which LSP
      starts to carry traffic again for (End-time - Start-time).

   Options:   Indicates a way to repeat.

         Options = 1: repeat every day;

         Options = 2: repeat every week;

         Options = 3: repeat every month;

         Options = 4: repeat every year;

         Options = 5: repeat every Repeat-time-length.






Chen, et al.            Expires January 21, 2018                [Page 7]


Internet-Draft              MPLS Temporal LSP                  July 2017


   Number-repeats:   The number of repeats.  In each of repeats, LSP
      carries traffic.

5.4.  Recurrent Relative TIME INTERVAL Object

   For a recurrent relative TIME-INTERVAL object, the format of its body
   is illustrated below. it contains a Start-time-length, an End-time-
   length, a Repeat-time-length, a Options field and a Number-repeats
   field.

   The Start-time-length and End-time-length represents time interval

     [current-time + Start-time-length, current-time + End-time-length]


   where current-time is a current local time.

   The Repeat-time-length represents a repeat cycle/time, which is valid
   if the Options field is set to indicate the way to repeat is "repeat
   every Repeat-time-length".  The Options field indicates a way to
   repeat.  The Number-repeats indicates the number of repeats of the
   time interval above.

        Class-Name: TIME-INTERVAL,   Class-Num: TBD,   C-Type = 4
      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                       Start-time-length                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                        End-time-length                        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                      Repeat-time-length                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Options |         Number-repeats          |    Reserved (0)   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Start-time-length:   The time length in seconds from a current local
      time to the time LSP starts to carry traffic.

   End-time-length:   The time length in seconds from a current local
      time to the time LSP ends carrying traffic.

   Repeat-time-length:   The time length in seconds after which LSP
      starts to carry traffic again for (End-time-length - Start-time-
      length).





Chen, et al.            Expires January 21, 2018                [Page 8]


Internet-Draft              MPLS Temporal LSP                  July 2017


   Options:   Indicates a way to repeat.

         Options = 1: repeat every day;

         Options = 2: repeat every week;

         Options = 3: repeat every month;

         Options = 4: repeat every year;

         Options = 5: repeat every Repeat-time-length.

   Number-repeats:   The number of repeats.  In each of repeats, LSP
      carries traffic.


6.  Path Message

   A Path message is enhanced to carry the information about a time
   interval or a sequence of time intervals through including a time
   interval list.  The format of the message is illustrated below.

  <Path Message> ::= <Common Header> [ <INTEGRITY> ]
                     [ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ...]
                     [ <MESSAGE_ID> ]<SESSION> <RSVP_HOP> <TIME_VALUES>
                     [ <EXPLICIT_ROUTE> ]
                     <LABEL_REQUEST> [ <PROTECTION> ] [ <LABEL_SET> ...]
                     [ <SESSION_ATTRIBUTE> ] [ <NOTIFY_REQUEST> ]
                     [ <ADMIN_STATUS> ] [ <POLICY_DATA> ... ]
                     <sender descriptor> [<S2L sub-LSP descriptor list>]
                     [<time interval list>]


   The time interval list in the message is defined below.  It is a
   sequence of TIME-INTERVAL objects, each of which describes a time
   interval or a series of time intervals.

      <time interval list> ::=
                        <time interval descriptor>
                        [ <time interval list> ]

      <time interval descriptor> ::= <TIME-INTERVAL>









Chen, et al.            Expires January 21, 2018                [Page 9]


Internet-Draft              MPLS Temporal LSP                  July 2017


7.  Behaviors for Temporal LSP

   To set up a temporal LSP, the ingress of the LSP MUST include the
   TIME-INTERVAL objects representing the time intervals configured for
   the LSP in the PATH message for the LSP.

   In addition, the ingress computes a shortest path satisfying the
   constraints for the LSP in each of the time intervals. it MUST
   include the ERO for the path in the PATH message for the LSP.

   For every node along the path for the LSP, when receiving a PATH
   message with TIME-INTERVAL objects, it obtains the time intervals
   represented by the objects in the message received and MUST forward
   the objects unchanged to the next hop if there is one.

   It adds the time intervals into the state for the LSP and checks
   whether there is enough bandwidth in each of the time intervals.  If
   there is, it reserved the bandwidth on the link to the next hop (if
   there is a next hop) in each of the time intervals.  If there is not,
   a PathErr message is returned.


8.  Security Considerations

   The mechanism described in this document does not raise any new
   security issues for the RSVP-TE protocols.


9.  IANA Considerations

   This section specifies requests for IANA allocation.


10.  Acknowledgement

   The author would like to thank people for their valuable comments on
   this draft.


11.  References

11.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>.




Chen, et al.            Expires January 21, 2018               [Page 10]


Internet-Draft              MPLS Temporal LSP                  July 2017


   [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>.

   [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>.

   [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>.

11.2.  Informative References

   [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>.


Authors' Addresses

   Huaimo Chen
   Huawei Technologies
   Boston, MA
   US

   Email: huaimo.chen@huawei.com


   Mehmet Toy
   Verizon
   USA

   Email: mehmet.toy@verizon.com











Chen, et al.            Expires January 21, 2018               [Page 11]


Internet-Draft              MPLS Temporal LSP                  July 2017


   Vic Liu
   China Mobile
   No.32 Xuanwumen West Street, Xicheng District
   Beijing,   100053
   China

   Email: liu.cmri@gmail.com


   Lei Liu
   Fijitsu
   USA

   Email: lliu@us.fujitsu.com





































Chen, et al.            Expires January 21, 2018               [Page 12]


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