<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-ietf-pce-lsp-setup-type-04" ipr="trust200902">
  <front>
    <title abbrev="PCE path setup type">
    Conveying path setup type in PCEP messages</title>

    <author fullname="Siva Sivabalan" initials="S." surname="Sivabalan">
      <organization>Cisco Systems, Inc.</organization>
      <address>
        <postal>
          <street>2000 Innovation Drive</street>
          <city>Kanata</city>
          <region>Ontario</region>
          <code>K2K 3E8</code>
          <country>Canada</country>
        </postal>
        <email>msiva@cisco.com</email>
      </address>
    </author>

     <author fullname="Jeff Tantsura" initials="J." surname="Tantsura">
      <organization>Individual</organization>
      <address>
      <email>jefftant.ietf@gmail.com</email>
      </address>
    </author>

   
   <author fullname="Ina Minei" initials="I." surname="Minei">
      <organization>Google, Inc.</organization>
      <address>
        <postal>
          <street>1600 Amphitheatre Parkway</street>
          <city>Mountain View</city>
          <region>CA</region>
          <code>94043</code>
          <country>USA</country>
        </postal>
        <email>inaminei@google.com</email>
      </address>
    </author>

    <author fullname="Robert Varga" initials="R." surname="Varga">
      <organization>Pantheon Technologies SRO</organization>
      <address>
        <postal>
          <street>Mlynske Nivy 56</street>
          <city>Bratislava</city>
          <region>821 05</region>
          <country>Slovakia</country>
        </postal>
        <email>robert.varga@pantheon.sk</email>
      </address>
    </author>


 <author fullname="Jon Hardwick" initials="J." surname="Hardwick">
   <organization>Metaswitch Networks</organization>
      <address>
        <postal>
          <street>100 Church Street</street>
          <city>Enfield</city>
          <region>Middlesex</region>
          <country>UK</country>
        </postal>
        <email>jon.hardwick@metaswitch.com</email>
      </address>
    </author>

    <date day="25" month="April" year="2017" />

    <workgroup>PCE Working Group</workgroup>

<abstract>

<t>A Path Computation Element can compute traffic engineering paths (TE paths) through a network that are subject to various constraints. Currently, TE paths are label switched paths (LSPs) which are set up using the RSVP-TE signaling protocol. However, other TE path setup methods are possible within the PCE architecture. This document proposes an extension to PCEP to allow support for different path setup methods over a given PCEP session.</t> 

</abstract> 

<note title="Requirements Language">

<t>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 <xref target="RFC2119"/>.
</t>
</note>
</front>

<middle>

<section anchor="Introduction" title="Introduction">

<t><xref target="RFC5440"/> describes the Path Computation Element Protocol (PCEP) for communication between a Path Computation Client (PCC) and a Path Control Element (PCE) or between one a pair of PCEs. A PCC requests a path subject to various constraints and optimization criteria from a PCE. The PCE responds to the PCC with a hop-by-hop path in an Explicit Route Object (ERO). The PCC uses the ERO to set up the path in the network.</t>
      
<t><xref target="I-D.ietf-pce-stateful-pce"/> specifies extensions to PCEP that allow a PCC to delegate its LSPs to a PCE. The PCE can then update the state of LSPs delegated to it. In particular, the PCE may modify the path of an LSP by sending a new ERO. The PCC uses this ERO to re-route the LSP in a make-before-break fashion. <xref target="I-D.ietf-pce-pce-initiated-lsp"/> specifies a mechanism allowing a PCE to dynamically instantiate an LSP on a PCC by sending the ERO and characteristics of the LSP. The PCC signals the LSP using the ERO and other attributes sent by the PCE.</t>

<t>So far, the PCEP protocol and its extensions implicitly assume that the TE paths are label switched, and are established via the RSVP-TE protocol. However, other methods of LSP setup are not precluded. When a new path setup method (other than RSVP-TE) is introduced for setting up a path, a new capability TLV pertaining to the new path setup method MAY be advertised when the PCEP session is established. Such capability TLV MUST be defined in the specification of the new path setup type. When multiple path setup methods are deployed in a network, a given PCEP session may have to simultaneously support more than one path setup types. In this case, the intended path setup method needs to be either explicitly indicated or implied in the appropriate PCEP messages (when necessary) so that both the PCC and the PCE can take the necessary steps to set up the path. This document introduces a generic TLV called "PATH-SETUP-TYPE TLV" and specifies the base procedures to facilitate such operational model.</t>

      
</section> <!-- Introduction -->

<section title="Terminology">
<t>The following terminologies are used in this document:

	<list style="hanging">
     	<t hangText="ERO:"> Explicit Route Object.</t>
    	<t hangText="LSR:"> Label Switching Router.</t>
    	<t hangText="PCC:"> Path Computation Client.</t>
    	<t hangText="PCE:"> Path Computation Element</t>
    	<t hangText="PCEP:"> Path Computation Element Protocol.</t>
    	<t hangText="TLV:"> Type, Length, and Value.</t>
      </list>
</t>
</section> <!-- Terminology --> 

<section anchor="PATH-SETUP-TYPE-TLV" title="Path Setup Type TLV">

<t>When a PCEP session is used to set up TE paths using different methods, the corresponding PCE and PCC must be aware of the path setup method used. That means, a PCE must be able to specify paths in the correct format and a PCC must be able take control and take forwarding plane actions appropriate to the path setup type. </t>

      <figure anchor="PATH-SETUP-TYPE-TLV-FORMAT" title="PATH-SETUP-TYPE TLV">
        <artwork align="center"><![CDATA[
   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            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                           Reserved            |      PST      |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        ]]></artwork>
      </figure>

<t>PATH-SETUP-TYPE TLV is an optional TLV associated with the RP (<xref target="RFC5440"/>) and the SRP (<xref target="I-D.ietf-pce-stateful-pce"/>) objects. Its format is shown in the above figure. The type of the TLV is to be defined by IANA. The one octet value contains the Path Setup Type (PST). This document specifies the following PST value:

      <list style="symbols">
        <t>PST = 0: Path is setup via RSVP-TE signaling protocol(default).</t>
      </list>
 </t>

<t>The absence of the PATH-SETUP-TYPE TLV is equivalent to an PATH-SETUP-TYPE TLV with an PST value of 0. It is recommended to omit the TLV in the default case. If the RP or SRP object contains more than one PATH-SETUP-TYPE TLVs, only the first TLV MUST be processed and the rest MUST be ignored.</t>

<t>If a PCEP speaker does not recognize the PATH-SETUP-TYPE TLV, it MUST ignore the TLV in accordance with (<xref target="RFC5440"/>). If a PCEP speaker recognizes the TLV but does not support the TLV, it MUST send PCErr with Error-Type = 2 (Capability not supported).</t>

</section> <!-- Path-setup-type-tlv --> 

<section anchor="Operation" title="Operation"> 
      
<t>When requesting a path from a PCE using a PCReq message (<xref target="RFC5440"/>), a PCC MAY include the PATH-SETUP-TYPE TLV in the RP object. If the PCE is capable of expressing the path in a format appropriate to the setup method used, it MUST use the appropriate ERO format in the PCRep message. If the path setup type cannot be inferred from the ERO or any other object or TLV in the PCRep message, PATH-SETUP-TYPE TLV may be included in the RP object of the PCRep message. Regardless of whether PATH-SETUP-TYPE TLV is used or not, if the PCE does not support the intended path setup type it MUST send PCErr with Error-Type = TBD (Traffic engineering path setup error) (recommended value is 21) and Error-Value = 1 (Unsupported path setup type) and close the PCEP session. If the path setup types corresponding to the PCReq and PCRep messages do not match, the PCC MUST send a PCErr with Error-Type = 21 (Traffic engineering path setup error) and Error-Value = 2 (Mismatched path setup type) and close the PCEP session.</t>
      
<t>In the case of stateful PCE, if the path setup type cannot be
unambiguously inferred from ERO or any other object or TLV, PATH-SETUP-TYPE TLV MAY be used in PCRpt and PCUpd messages. If
PATH-SETUP-TYPE TLV is used in PCRpt message, the SRP object MUST be present even in cases when the SRP-ID-number is the reserved value of 0x00000000. Regardless of whether PATH-SETUP-TYPE TLV is used or not, if a PCRpt message is triggered due to a PCUpd message (in this case SRP-ID-number is not equal to 0x00000000), the path setup types corresponding to the PCRpt and PCUpd messages should match. Otherwise, the PCE MUST send PCErr with Error-Type = 21 (Traffic engineering path setup error) and Error-Value = 2 (Mismatched path setup type) and close the connection.
</t>

<t>In the case of PCE initiated LSPs, a PCE MAY include PATH-SETUP-TYPE TLV in PCInitiate message if the message does not have any other means of indicating path setup type. If a PCC does not support the path setup type associated with the PCInitiate message, the PCC MUST send PCErr with Error-Type = 21 (Traffic engineering path setup error) and Error-Value = 1 (Unsupported path setup type) and close the PCEP session.  Similarly, as mentioned above, if the path setup type cannot be unambiguously inferred from ERO or any other object or TLV, the PATH-SETUP-TYPE TLV MAY be included in PCRpt messages triggered by PCInitiate message. Regardless of whether PATH-SETUP-TYPE TLV is used or not, if a PCRpt message is triggered by a PCInitiate message, the path setup types corresponding to the PCRpt and the PCInitiate messages should match. Otherwise, the PCE MUST send PCErr message with Error-Type = 21 (Traffic engineering path setup error) and Error-Value = 2 (Mismatched path setup type).</t>
      
</section>

<section anchor="Security" title="Security Considerations">

<t>No additional security measure is required.</t>

</section>

<section anchor="IANA" title="IANA Considerations">

<section anchor="PCEP-TLV-Type" title="PCEP TLV Type Indicators">

<t>IANA is requested to allocate a new code point in the PCEP TLV Type Indicators registry, as follows:
</t>

<texttable anchor="PATH-SETUP-TLV-value" style="none" suppress-title="true">
        <ttcol align="left" width='55%'>Value</ttcol>
        <ttcol align="left" width='30%'>Description </ttcol>
        <ttcol align="left" width='55%'>Reference </ttcol>
        <c></c><c>&nbsp;</c><c></c>
        <c>TBD (recommended 28)</c><c>PATH-SETUP-TYPE</c><c>This document</c>
</texttable>

</section>

<section anchor="PCEP-Setup-Type-Registry" title="New Path Setup Type Registry">

<t>IANA is requested to create a new sub-registry within the "Path Computation Element Protocol (PCEP) Numbers" registry called "PATH-SETUP-TYPE TLV PST Field". The allocation policy for this new registry should be by IETF Consensus. The new registry should contain the following value:
</t>

<texttable anchor="New-PATH-SETUP-TYPE-value" style="none" suppress-title="true">
        <ttcol align="left" width='40%'>Value</ttcol>
        <ttcol align="left" width='75%'>Description </ttcol>
        <ttcol align="left" width='55%'>Reference </ttcol>
        <c></c><c>&nbsp;</c><c></c>
        <c>0</c><c>Traffic engineering path is setup using RSVP signaling protocol</c><c>This document</c>
      </texttable>

</section>

<section anchor="PCEP-Error-Object" title="PCEP-Error Object">

<t>IANA is requested to allocate code-points in the PCEP-ERROR Object Error Types and Values registry for a new error-type and the following new error-values:

<vspace blankLines="1" /> 
<?rfc subcompact="yes"?>
<list style="hanging" hangIndent="13">
<t hangText=" Error-Type">Meaning</t>
<t hangText="    21">Invalid traffic engineering path setup type
<list style="hanging" hangIndent="17">
<t hangText=" Error-value=0:">Unassigned</t>
<t hangText=" Error-value=1:">Unsupported path setup type</t>
<t hangText=" Error-value=2:">Mismatched path setup type</t>
</list>
</t>
</list>
</t>

</section>

</section>

<section anchor="Contributors" title="Contributors">

      <?rfc subcompact="yes"?>
      <t>The following people contributed to this document:
      <list style="empty">
	      <t>- Jan Medved</t>
	      <t>- Edward Crabbe</t>
      </list>
      </t>
      <?rfc subcompact="no"?>
    </section>


<section anchor="Acknowledgement" title="Acknowledgements">

<t>We like to thank Marek Zavodsky for valuable comments.</t>

</section>

</middle>

<back>

<references title="Normative References">
      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?>
      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5440.xml"?>
      <?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-pce-stateful-pce-18.xml"?>
      <?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-pce-pce-initiated-lsp-09.xml"?>
</references>

</back>

</rfc>
