[Docs] [txt|pdf] [Tracker] [Email] [Nits] [IPR]

Versions: 00

PCE                                                    Arijit Paul
Internet-Draft                                         Juniper Networks
Intended status: Standards Track                       November 20, 2018
Expires: May 20, 2019



PCEP extension to support reporting of dynamic tunnels
                draft-paul-pce-dynamic-tunnel-00

Abstract


   In a SDN environment, path computation element protocol(PCEP)
   (RFC 5440) is used between a controller and the network devices,
   using which controller can setup and tear down Resource ReserVation
   Protocol (RSVP) based label switched paths(LSPs) in the network
   having Path Computation Client (PCC) as Label Switched Router (LSR).
   In an environment where dynamic tunnels are used to provide MPLS based
   customer services instead of a Label Switched Path, the specifications
   lacks a method to report the Dynamic tunnels over PCEP session to PCE.
   This draft defines a method to advertise the dynamic tunnels via PCEP
   session to PCE.

   This document proposes new object TLV that can be used to report
   dynamic tunnels to the PCE.

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 March 8, 2018




Paul            Expires May 20, 2019             [Page 1]


Internet-Draft       Reporting dynamic tunnel for PCEP        November 2018


Copyright Notice

   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  . . . . . . . . . . . . . . . . . . . . . . . .   1
   2.  Conventions used in this document . . . . . . . . . . . . . .   2
   3.  Motivation  . . . . . . . . . . . . . . . . . . . . . . . . .   2
   4.  Overview of Protocol Extensions . . . . . . . . . . . . . . .   2
     4.1.  Capability Advertisement  . . . . . . . . . . . . . . . .   2
     4.2.  Dynamic-Tunnel Object   . . . . . . . . . . . . . . . . .   3
       4.2.1  IPV4-TUNNEL-IDENTIFIERS TLV  . . . . . . . . . . . . .   5
     4.3.  Metric Object   . . . . . . . . . . . . . . . . . . . . .   6
   5.  Backward Compatibility Consideration  . . . . . . . . . . . .   6
   6.  Management Considerations . . . . . . . . . . . . . . . . . .   6
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
     9.2.  Informative References  . . . . . . . . . . . . . . . . .   7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction

   As described in [RFC5440], PCEP can be used to create, modify or
   delete LSPs between PCCs. PCEP can be used to create, modify and
   delete RSVP and segment routing LSPs between PCCs. This document
   specifies the way to report the dynamic nexthop based tunnels from PCC
   to PCE server. This is helpful for PCE to have complete visibility
   of the network and help take intelligent decisions based on the
   information available to it.





Paul            Expires May 20, 2019             [Page 2]


Internet-Draft       Reporting dynamic tunnel for PCEP        November 2018


   In this draft a method to report dynamic tunnels from PCC via PCEP is
   outlined.

   This document proposes one new pcep objects to carry the tunnels attributes
   for individual dynamic tunnels. Since only reporting of dynamic tunnels
   is outlined here, only dynamic tunnel object and well-known metric objects
  are being carried in PCRpt [RFC8231] of PCEP message in order to report
  the dynamic tunnel to PCE.

2.  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 [RFC2119].

3.  Motivation

    PCEP protocol lacks the capability to report dynamic-tunnels e,g,
    MPLS over UDP and MPLS over GRE to the PCE. In the SDN scenario
    where a controller uses the information provided by PCEP to gain
    network visibility, adding the report capability of dynamic-tunnel
    via PCEP helps controller gain additional insights about network
    tunnels.


4.  Overview of Protocol Extensions


4.1.  Capability Advertisement

   During the PCEP session initialization phase, PCEP speakers (PCE or PCC)
   advertise their support of dynamic tunnel report capability.  A PCEP
   speaker includes the "STATEFUL-PCE-CAPABILITY TLV", described in
   Section 7.1.1, in the OPEN object to advertise its support for PCEP



Paul            Expires May 20, 2019             [Page 3]


Internet-Draft       Reporting dynamic tunnel for PCEP        November 2018


   Stateful PCE extensions.  The STATEFUL-PCE-CAPABILITY TLV includes
   the 'Dynamic Tunnel Report' flag that indicates whether the PCEP speaker
   supports Dynamic Tunnel report capability.

   One new flag is added in this document:

      D (DYNAMIC-TUNNEL-REPORT bit - TBD):  if set to 1 by a PCC, the D Flag
      indicates that the PCC is willing to send Dynamic Tunnel State Reports
      whenever dynamic tunnel state changes.; if
      set to 1 by a PCE, the D Flag indicates that the PCE is interested
      in receiving Dynamic Tunnel State Reports whenever dynamic tunnel state changes.
      The DYNAMIC-TUNNEL-REPORT Flag must be
      advertised by both a PCC and a PCE for PCRpt messages DYNAMIC-TUNNEL-REPORT
      extension to be allowed on a PCEP session.


4.2  Dynamic-Tunnel Object

     Path Computation State Report (PCRpt):  a PCEP message sent by a PCC
      to a PCE to report the status of one or more LSPs.  Each LSP State
      Report in a PCRpt message MAY contain the actual LSP's path,
      bandwidth, operational and administrative status, etc.  An LSP
      Status Report carried on a PCRpt message is also used in
      delegation or revocation of control of an LSP to/from a PCE.  The
      PCRpt message is described in Section 6.1.

     One new object is defined in order to report dynamic tunnels to PCE.


   The Dynamic-Tunnel object MUST be present within PCRpt messages while
   reporting dynamic tunnel. The LSP
   object contains a set of fields used to specify the target LSP, the
   operation to be performed on the LSP, and LSP delegation.  It also
   contains a flag indicating to a PCE that the LSP State
   Synchronization is in progress.  This document focuses on MPLS Tunnels that
   run over UDP or GRE.


   Dynamic tunnel Object-Class is TBD.

   Dynamic tunnel Object-Type is TBD.




Paul            Expires May 20, 2019             [Page 4]


Internet-Draft       Reporting dynamic tunnel for PCEP        November 2018




   The format of the Dynamic-Tunnel object body is shown in Figure 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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                Tunnel-ID                |    Flag |     |O|R|S|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     //                        TLVs                                 //
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     Figure 1: The LSP Object format


   Tunnel-ID (20 bits): A PCEP-specific identifier for the Dynamic Tunnel.  A PCC
   creates a unique Tunnel-ID for each dynamic tunnel that is constant for the
   lifetime of a PCEP session.  The PCC will advertise the same Tunnel-ID
   on all PCEP sessions it maintains at a given time.  There will not be any
   name associated with dynamic-tunnel, so no mapping between Tunnel-ID and
   tunnel name is maintained. If needed PCE can maintain mapping of Tunnel-ID
   with source and destination of dynamic tunnels.



   All subsequent PCEP messages then address the LSP by the Tunnel-ID.  The
   values of 0 and 0xFFFFF are reserved.  Note that the Tunnel-ID is a
   value that is constant for the lifetime of the PCEP session.

   Flags (12 bits), starting from the least significant bit:

   S (SYNC - 1 bit):  The S flag MUST be set to 1 on each PCRpt sent
      from a PCC during State Synchronization.  The S flag MUST be set
      to 0 in other messages sent from the PCC.

   R (Remove - 1 bit):  On PCRpt messages, the R flag indicates that the
      Dynamic tunnel has been removed from the PCC and the PCE SHOULD remove all
      state from its database.  Upon receiving an Dynamic tunnel State Report with
      the R flag set to 1 for a Dynamic tunnel, the PCE SHOULD
      remove all state for the path identified by the IPV4-TUNNEL-IDENTIFIERS



Paul            Expires May 20, 2019             [Page 5]


Internet-Draft       Reporting dynamic tunnel for PCEP        November 2018


      TLV from its database.

   O (Operational - 3 bits):  On PCRpt messages, the O field represents
      the operational status of the LSP.

      The following values are defined:

      0 - DOWN:         not active.

      1 - UP:           signaled.

      2 - ACTIVE:       up and carrying traffic.

      3-7 - Reserved:   these values are reserved for future use.

   Unassigned bits are reserved for future uses.  They MUST be set to 0
   on transmission.

   TLVs that may be included in the Dynamic-Tunnel object are described in the
   following sections.


 4.2.1  IPV4-TUNNEL-IDENTIFIERS TLV




     The format of the IPV4-TUNNEL-IDENTIFIERS TLV is shown in the following
     figure:

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |           Type=[TBD]          |           Length=16           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                   IPv4 Tunnel Source Address                  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                   IPv4 Tunnel Destination Address             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                        Tunnel Type                            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure 2: IPV4-TUNNEL-IDENTIFIERS TLV Format


Paul            Expires May 20, 2019             [Page 6]


Internet-Draft       Reporting dynamic tunnel for PCEP        November 2018



   The type of the TLV is to be assigned by IANA and it has a fixed
   length of 2 octets.


   IPv4 Tunnel Source Address:  contains the tunnel's source IPv4 address

   IPv4 Tunnel Destination Address:  contains the tunnel's destination IPv4
      address

   Tunnel Type:  Defines the tunnel type. This draft assigns MPLSoUDP a
      numeric value of 1 and MPLSoGRE a numeric value of 2.


 4.3  Metric Object

     This object is already defined in [RFC5440]. It can be reused and metric
     type should be set to value 1 which signifies IGP metric.




5.  Backward Compatibility Consideration

   A PCE that does not support the new capability will not bring up the session
   during initialization phase.


6.  Management Considerations

    Not needed.

7.  Security Considerations

   This document raises no new security issues.

8.  IANA Considerations

   IANA is requested to allocate a Type for this new object to
   support dynamic tunnel reporting.




Paul            Expires May 20, 2019             [Page 7]

Internet-Draft       Reporting dynamic tunnel for PCEP        November 2018


9.  References

9.1.  Normative References


   [draft-crabbe-pce-pce-initiated-lsp]  E. Crabbe, "PCEP Extensions
                                         for PCE-initiated LSP Setup
                                         in a Stateful PCE Model"

   [draft-sivabalan-pce-segment-routing] E. Crabbe, "PCEP Extensions
                                         for Stateful PCE"
9.2.  Informative References

   [RFC4657]  Ash, J. and J. Le Roux, "Path Computation Element (PCE)
              Communication Protocol Generic Requirements", RFC 4657,
              September 2006.

   [RFC5440]  Le Roux, JL., "Path Computation Element (PCE)
              Communication Protocol (PCEP)", RFC 5440, March 2009.
   [RFC2119]  S. Bradner, "Key words for use in RFCs to Indicate
              Requirement Levels", RFC 2119, March 1997





Author's Addresses

   Arijit Paul
   10214 Parkwood Dr. Apt 5
   Cupertino, CA - 95014
   USA

   Email: arijitp@juniper.net


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