Internet DRAFT - draft-cho-pce-initiated-auto-path

draft-cho-pce-initiated-auto-path



PCE Working Group                                                 E. Cho
Internet-Draft                                                   T. Kwon
Intended status: Standards Track                                    ETRI
Expires: April 30, 2017                                 October 31, 2016


            PCEP Extensions for PCE-initiated Automatic Path Setup
            in a Stateful PCE Model
            draft-cho-pce-initiated-auto-path-00

Abstract

   This document introduces an automatic setup and maintenance mechanism 
to compute, create, update and delete for a packet and/or optical layer 
path and pseudowire paths(PWs) via an extension to the Path Computation 
Element Communication Protocol(PCEP) and DB Synchronization procedures.

Requirements Language

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

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












Cho & Kwon              Expires April 30, 2017                [Page 1]

Internet-Draft      PCE-initiated Automatic Path           October 2016


   This Internet-Draft will expire on April 30, 2017.

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  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
     3.  Motivation  . . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Support of PCE-initiated Automatic Path . . . . . . . . . . .   4
     4.1.  Stateful PCE Capability TLV . . . . . . . . . . . . . . .   4
       4.2.  PW-LABEL-DB Synchronization . . . . . . . . . . . . . . .   4
       4.3.  OAM-DB Synchronization . . .. . . . . . . . . . . . . . .   5
   5.  PCE-initiated LSP and PW instantiation and deletion . . . . .   6
     5.1.  The LSP and PW Initiate Message  . . . .. . . . . . . . .   6
     5.2.  The D flag in the SRP Object  . . . . . . . . . . . . . .   6
     5.3.  LSP and PW instantiation .  . . . . . . . . . . . . . . .   7
       5.4.  LSP and PW deletion  . . . . .. . . . . . . . . . . . . .   8
       5.5.  Automatic Restoration and Cascade Update  . . . . . . . .   8
   6.  LSP and PW delegation and cleanup   . . . . . . . . . . . . .   8
     7. Manageability Considerations  . . . . . . . . . . . . . . . .    9
     8.  IANA considerations . . . . . . . . . . . . . . . . . . . . .   9
     9.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
     10. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   9
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     11.1.  Normative References . . . . . . . . . . . . . . . . . .   9
     11.2.  Informative References . . . . . . . . . . . . . . . . .   9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10










Cho & Kwon              Expires April 30, 2017                [Page 2]

Internet-Draft      PCE-initiated Automatic Path           October 2016

1.  Introduction

   Stateful pce [I-D.ietf-pce-stateful-pce]  specifies a set of
   extensions to PCEP to enable stateful control of TE LSPs between and
   across PCEP sessions in compliance with [RFC4657].  It includes
   mechanisms to effect LSP state synchronization between PCCs and PCEs,
   delegation of control of LSPs to PCEs, and PCE control of timing and
   sequence of path computations within and across PCEP sessions

   This document describes the setup, maintenance and teardown of PCE-
   initiated LSPs and/or Pseudowires under the stateful PCE model 
	allowing for automatic setup of an transport paths.

2.  Terminology

   This document uses the following terms defined in [RFC5440]: PCC,
   PCE, PCEP Peer.

   This document uses the following terms defined in
   [I-D.ietf-pce-stateful-pce]: Stateful PCE, Delegation, Redelegation
   Timeout, State Timeout Interval Path State Report, Path Update 
	Request.

   The following terms are defined in this document:

   PCE-initiated Automatic Path:  Pseudowire and/or LSP that is 
	instantiated as a result of a request from the PCE.

3. Motivation

   An active stateful PCE is able to provide an automated and optimized 
path as the role of central controller or NMS. In addition to PCE-
initiated LSP, PCE may initiate pseudowire service automatically over LSP 
with extension of information and protocol. With OAM information, PCE 
would be able to trigger path restoration upon alarm notification. 
Therefore, this document introduces an automatic path management method 
with PCE-initiated paths setup using their pseudowire label and OAM 
database. It is a useful mechanism in multi-domain and multi-layer SDN 
and ACTN. 

   Different setup of automatic paths may be offered:

   o  LSP only: setup the label switched path in one request

   o  PW only: setup the pseudowire paths in one request

   o  LSP+PW: setup the LSP with the associated PWs in one request





Cho & Kwon              Expires April 30, 2017                [Page 3]

Internet-Draft      PCE-initiated Automatic Path           October 2016

4.  Support of PCE-initiated Automatic Path

   A PCEP speaker indicates its ability to support PCE provisioned 
   dynamic LSPs and/or PWs during the PCEP Initialization phase.  The 
Open Object in the Open message contains the "Stateful PCE Capability" 
TLV, defined in [I-D.ietf-pce-stateful-pce].  A new flag, the P (PW-
   INSTANTIATION-CAPABILITY) flag is introduced to indicate support for
   instantiation of PCE-initiated LSPs.  A PCE can initiate LSPs 
with/without PWs for PCCs that advertised this capability and a PCC will 
follow the procedures described in this document only on sessions where 
the PCE advertised the P flag.

4.1.  Stateful PCE Capability TLV

   The format of the STATEFUL-PCE-CAPABILITY 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            |            Length=4           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |              Flags                                    |P|I|S|U|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+

               Figure 1: STATEFUL-PCE-CAPABILITY TLV format

   The type of the TLV is defined in [I-D.ietf-pce-stateful-pce] and it
   has a fixed length of 4 octets.

   The value comprises a single field - Flags (32 bits).  
	The I, U and S bits are defined in [I-D.ietf-pce-pce-initiated-lsp], 
[I-D.ietf-pce-stateful-pce] and [I-D.ietf-pce-stateful-sync-
optimizations] respectively.

   P (PW-INSTANTIATION-CAPABILITY - 1 bit):  If set to 1 by a PCC, the
      I Flag indicates that the PCC allows instantiation of an LSP by a
      PCE.  If set to 1 by a PCE, the P flag indicates that the PCE may
      attempt to instantiate PWs over LSPs.  
	 The PW-INSTANTIATION-CAPABILITY flag must be set by both PCC and 
	PCE in order to support PCE-initiated LSP instantiation.

4.2. PW-LABEL-DB Synchronization 

     PCECC or NMS MUST maintain the PW-LABEL-DB for each PCEP session 
separately.





Cho & Kwon              Expires April 30, 2017                [Page 4]

Internet-Draft      PCE-initiated Automatic Path           October 2016

The purpose of PW-LABEL-DB synchronization is to make sure that the
   PCE's view of PW-LABEL-DB matches with the PCC's PW-LABEL-DB.  The 
PW-LABEL-DB synchronization MUST be performed from PCC to PCE immediately
   after the LSP state synchronization. [I-D.ietf-pce-stateful-pce]
   describes the basic mechanism for LSP state synchronization.

          +-+-+                          +-+-+
          |PCC|                          |PCE|
          +-+-+                          +-+-+
             |                              |
             |-PCLabelUpd, SYNC=1----->| (Sync start)
             |                              |
             |-PCLabelUpd, SYNC=1----->|
             |            .                 |
             |            .                 |
             |            .                 |
             |-PCLabelUpd, SYNC=0----->| (End of sync marker
             |                              |  Label Update
             |                              |  PW LABEL=0)
             |                              | (Sync done)

        Figure 2: PW-LABEL-DB synchronization

Further synchronization procedures and protocol definitions will be 
added after consensus on this necessity in this or a separate document.

4.3. OAM-DB Synchronization

     PCECC or NMS MUST maintain the OAM-DB for each PCEP session 
separately.
   The purpose of OAM-DB synchronization is to make sure that the
   PCE's view of OAM-DB matches with the PCC's OAM-DB.  The OAM-
   DB synchronization MUST be performed from PCC to PCE immediately
   after the LSP state synchronization.  [I-D.ietf-pce-stateful-pce]
   describes the basic mechanism for LSP state synchronization.

          +-+-+                          +-+-+
          |PCC|                          |PCE|
          +-+-+                          +-+-+
             |                              |
             |---PCOAMUpd, SYNC=1----->| (Sync start)
             |                              |
             |---PCOAMUpd, SYNC=1----->|
             |            .                 |
             |            .                 |
             |            .                 |
             |---PCOAMUpd, SYNC=0----->| (End of sync marker
             |                              |  Label Update
             |                              |  OAM =0)
             |                              | (Sync done)

           Figure 3: OAM-DB synchronization

Cho & Kwon              Expires April 30, 2017                [Page 5]

Internet-Draft      PCE-initiated Automatic Path           October 2016

Upon alarm notification on link or path, PCE can compute and initiate 
restoration path. For this active control, PCE may keep OAM information 
such as identifiers of Maintenance Entity Group(MEP), MEG End Point(MEG), 
Trail Trace Identifier(TTI). This information is maintained for each path 
and has an important role in automatic and dynamic path control 
environment. 
For highly automated services, Attachment Circuit(AC) database also is 
Additional synchronization procedures and protocol definitions will be 
added after consensus on this necessity in this or a separate document.

5.  PCE-initiated LSP and PW instantiation and deletion

   To initiate an LSP, a PCE sends a PCInitiate message to a PCC.  The
   message format, objects and TLVs are discussed separately below for
   the creation and the deletion cases.

5.1.  The LSP and PW Initiate Message

   A Pseudowire Path Initiate Message (also referred to as PCInitiate 
message) is a PCEP message sent by a PCE to a PCC to
   trigger LSP instantiation or deletion. A PCInitiate message for LSP 
instantiation is defined in [I-D.ietf-pce-pce-initiated-lsp].

5.2.  The D flag in the SRP Object

   The format of the SRP object is shown Figure 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          Flags                          |C|D|R|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        SRP-ID-number                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      //                      Optional TLVs                           //
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                      Figure 4: The SRP Object format

   The type object is defined in [I-D.ietf-pce-stateful-pce].  The R 
   bits are defined in [I-D.ietf-pce-pce-initiated-lsp].

   A new flag is defined to indicate a delete operation initiated by the
   PCE:

     C (ML-CASCADE-DELETE   - 1 bit):  If set to 1, it indicates a cascade 
	   LSP removal request initiated by the PCE.
     D (PW-DELETE   - 1 bit):  If set to 1, it indicates a removal request
           initiated by the PCE. If both R and D set to 1, it indicates a 
	   removal request of LSP and PW initiated by the PCE.

Cho & Kwon              Expires April 30, 2017               [Page 6]

Internet-Draft      PCE-initiated Automatic Path           October 2016

5.3.  LSP and PW instantiation

   LSP instantiation is done by sending an LSP Initiate Message with an
   LSP object with the reserved PLSP-ID 0.  The LSP is set up using
   RSVP-TE, extensions for other setup methods are outside the scope of
   this draft.

   The END-POINTS, ERO, and LSP Object is defined in [ietf-pce-pce-
initiated-lsp].

The symbolic name used for provisioning PCE-initiated Automatic Path must 
not have conflict with the LSP name of any existing LSP in the PCC.  
(Existing LSPs may
   be either statically configured, or initiated by another PCE).  

   A PCC SHOULD be able to place a limit on the number of LSPs, PWs and 
OAMs the percentage of resources that are allocated to honor PCE-
initiated LSP requests.  

   Similarly, the PCE SHOULD be able to place a limit on the number of 
LSP or PW initiation requests pending for a particular PCC, or on the 
time it waits for a response (positive or negative) to a PCInitiate 
request from a PCC and MAY take further action (such as closing the 
session or removing all its LSPs or PWs) if this limit is reached.

   On succesful completion of the LSP and PW instantiation, The PCRpt 
MUST include the SRP-ID-number of the PCInitiate request that triggered 
its creation.  PCE-initiated LSPs are identified with the Create flag in 
the LSP Object.

   The LSP object is defined in [I-D.ietf-pce-stateful-pce] and included
   here for easy reference.

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                PLSP-ID           |Flags     |C|P|    O|A|R|S|D|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     //                        TLVs                                 //
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                      Figure 5: The LSP Object format

   A new flag, the PW Create (P) flag is introduced.  On a PCRpt message,
   the P Flag set to 1 indicates that this LSP was created via a
   PCInitiate message.  The P Flag MUST be set to 1 on each PCRpt
   message for the duration of existence of the LSP.  The Create flag
   allows PCEs to be aware of which LSPs were PCE-initiated (a state
   that would otherwise only be known by the PCC and the PCE that
   initiated them).

Cho & Kwon              Expires April 30, 2017               [Page 7]

Internet-Draft      PCE-initiated Automatic Path           October 2016

   The optional SPEAKER-IDENTITY-ID TLV defined in
   [I-D.ietf-pce-stateful-sync-optimizations] MAY be included in the LSP 
and/or PW object in a PCRpt message, as an optional TLV for LSPs for 
which the C-flag is 1.  The SPEAKER-IDENTITY-ID TLV identifies the PCE 
that initiated the creation of the LSP and/or PW on all PCEP sessions, a 
state that would otherwise only be known by the PCC and the PCE that 
initiated the LSP.  If the TLV appears in a PCRpt for an LSP for which 
the C flag is 0, the TLV MUST be ignored. 

5.4. LSP and PW deletion

   PCE-initiated removal of a PCE-initiated Automatic Path and/or PWs is 
done by setting the R(LSP remove) and/or D (PW remove) flag in the SRP 
Object in the PCInitiate message from the PCE.  The LSP is identified by 
the PLSP-ID in the LSP object. 
Following the removal of the LSP and/or PW, the PCC MUST send a PCRpt 
as described in [I-D.ietf-pce-stateful-pce].  The SRP object in the PCRpt 
MUST include the SRP-ID-number from the PCInitiate message that triggered 
the removal.  The R and/or D flag in the SRP object SHOULD be set.

5.5.  Automatic Restoration and Cascade Update

Upon PCNotify on link failure or CCM Error, PCE would compute and 
initiate a new path. At this moment, PCE can apply the LSP policy on 
mono-layer or inter-layer path. For instance, lower layer LSP may update 
or delete by the policy flag on PCE-initiated deletion request.  The 
format will be described upon PCE WG discussion. 

6.  LSP and PW delegation and cleanup

   PCE-initiated automatic paths are automatically delegated by the PCC 
to the PCE upon instantiation.  
To obtain control of a PCE-initiated LSP and PW, a PCE (either the 
original or one of its backups) sends a PCInitiate message, including 
just the SRP and LSP objects, and carrying the PLSP-ID.
PCE-initiated LSPs and PWs are cleaned up on the expiration of State 
Timeout timer.










Cho & Kwon              Expires April 30, 2017               [Page 8]

Internet-Draft      PCE-initiated Automatic Path           October 2016

7. Manageability Considerations
     TBD

8.  IANA considerations
     TBD

9.  Security Considerations
   TBD

10.  Acknowledgements

This document borrows some of the structure and text from [I-D. draft-
ietf-pce-pce-initiated-lsp] and [I-D. draft-palle-pce-controller-labeldb-
sync], and would like to thanks the authors and contributors of the 
document.

11.  References

11.1.  Normative References

     [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-14 (work in progress), March 2016.

   [I-D.ietf-pce-stateful-sync-optimizations]
              Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X.,
              and D. Dhody, "Optimizations of Label Switched Path State
              Synchronization Procedures for a Stateful PCE", draft-
              ietf-pce-stateful-sync-optimizations-05 (work in
              progress), April 2016.

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

   [RFC5921] Bocci, M., Bryant, S., Frost, D., Levrau, L., and L.
              Berger, "A Framework for MPLS in Transport Networks", RFC
              5921, July 2010.
11.2.  Informative References

      [I-D.ietf-pce-pce-initiated-lsp]
              Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP
              Extensions for PCE-initiated LSP Setup in a Stateful PCE
              Model", draft-ietf-pce-pce-initiated-lsp-05 (work in
              progress), October 2015.

       [I-D.palle-pce-controller-labeldb-sync]
              Palle, U. and D. Dhody, "LABEL-DB Synchronization
              Procedures for a PCE as a central controller(PCECC)",
              draft-palle-pce-controller-labeldb-sync-00 (work in
              progress), May 2016.

Cho & Kwon              Expires April 30, 2017               [Page 9]

Internet-Draft      PCE-initiated Automatic Path           October 2016

Authors' Addresses

   Eunyoung Cho
   ETRI
   218 Gajeongno, Yuseonggu, Daejeon, 34129
   Korea (the Republic of)

   Email: eycho@etri.re.kr


   Taehyun Kwon
   ETRI
   218 Gajeongno, Yuseonggu, Daejeon, 34129
   Korea (the Republic of)

   Email: thkwon@etri.re.kr


























Cho & Kwon              Expires April 30, 2017               [Page 10]